이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
수업 과제에서 저장 장치 프로토콜을 비교하면서 SCSI 계열 프로토콜에 대해 처음 체계적으로 공부했습니다. SATA는 소비자용 드라이브에 주로 쓰이고, SAS는 엔터프라이즈 환경에서 듀얼 포트와 높은 내구성을 제공하는 차이가 인상적이었습니다. 직접 다뤄본 경험으로는 리눅스 환경에서 저장 장치 식별과 파티셔닝을 직접 수행하면서 디바이스 경로 관리와 마운트 옵션 설정을 익혔습니다.
fio 벤치마크로 블록 디바이스의 읽기·쓰기 성능이 프로토콜과 컨트롤러 설정에 따라 크게 달라진다는 점을 확인했습니다. 지금은 펌웨어나 드라이버 레벨에서 이 프로토콜들을 더 깊이 다루는 경험을 쌓고 싶은 관심이 있습니다.
리눅스에서 저장 장치 성능을 측정하다가 쓰기 순서가 보장될 것으로 예상했는데 실제로는 다른 순서로 디스크에 기록되는 현상을 발견했습니다. 원인을 찾아보니 NCQ(Native Command Queuing)가 여러 I/O 요청을 디스크 회전 순서에 맞게 재배열하는 메커니즘 때문이었습니다.
쓰기 순서 보장이 필요한 경우에는 파일시스템의 fsync 호출이나 배리어를 명시적으로 사용해야 한다는 것을 이때 이해했습니다. 막혔을 때는 리눅스 커널 문서와 커뮤니티 포럼을 참고했는데, 혼자 디버깅하는 것보다 유사한 이슈가 어떻게 다뤄졌는지를 먼저 찾는 것이 빠르다는 것을 배웠습니다. 이 경험 이후 저장 장치 관련 실습에서는 순서 보장이 필요한지 여부를 먼저 확인하는 체크리스트를 만들었습니다.
저장 장치 프로토콜을 이해하면 성능과 안정성 사이의 트레이드오프를 의식적으로 선택할 수 있다는 것을 이 경험에서 얻었습니다.
SAS와 SATA 성능 차이를 직접 측정하는 실험을 설계했는데, 단순히 순차 읽기 속도만 비교해서는 실제 차이를 파악하기 어렵다는 것을 먼저 깨달았습니다. 무작위 읽기·쓰기, 큐 깊이, 블록 크기를 변수로 잡아서 fio로 조건별 IOPS와 지연 시간을 체계적으로 측정하는 방식으로 접근했습니다. 처음에는 어떤 파라미터를 조합해야 의미 있는 비교가 되는지 몰랐는데, 지도 교수에게 측정 설계를 검토받고 큐 깊이(Queue Depth)가 핵심 변수라는 것을 이해했습니다. SAS가 듀얼 포트를 지원해 멀티패스(MPIO)로 이중화가 가능하다는 것도 이때 배웠는데, 단순 성능보다 가용성 요구사항에 따라 프로토콜 선택이 달라진다는 것이 인상적이었습니다. 이 실험 과정을 문서로 남겨서 다음 팀원이 같은 실험을 할 때 측정 방법론을 재사용할 수 있게 했습니다.
저장 장치 비교는 단일 지표가 아니라 워크로드 특성에 맞게 측정 조건을 설계하는 것이 핵심이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 임베디드·펌웨어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.