대상: 전공자 · 정보처리기사 취득자 | 목적: 인프라 직무 기술 면접 대비 중요도: ★★★ 최빈출 · ★★ 자주 출제 · ★ 기본 개념
답안 디스크 같은 블록 장치 위에 파일과 디렉터리라는 추상화를 제공하는 OS 구성 요소입니다. 핵심 기능은 ① 파일 이름 → 디스크 블록 매핑(할당 관리), ② 디렉터리 계층 구조 관리, ③ 빈 공간 관리, ④ 권한·소유권 등 메타데이터 관리, ⑤ 크래시 일관성 보장(저널링)입니다. 리눅스는 ext4, XFS, Btrfs, 윈도우는 NTFS가 대표적이며, VFS(가상 파일 시스템) 계층이 서로 다른 파일시스템에 동일한 인터페이스(open/read/write)를 제공합니다.
관련 개념 블록 장치, 메타데이터, VFS, ext4/XFS/NTFS, 마운트
답안 유닉스 계열 파일시스템에서 파일 하나의 메타데이터를 담는 자료구조입니다. 파일 크기, 소유자, 권한, 타임스탬프, 링크 수, 그리고 데이터 블록들의 위치(직접/간접 블록 포인터)를 담습니다. 중요한 점은 파일 이름은 아이노드에 없다는 것입니다. 이름은 디렉터리(이름→아이노드 번호 매핑 테이블)가 관리합니다. 운영 관점에서 아이노드 개수는 파일시스템 생성 시 고정되므로, 작은 파일이 수백만 개 쌓이면 디스크 용량이 남아도 아이노드 고갈로 파일 생성이 실패할 수 있습니다(df -i로 확인).
관련 개념 직접/간접 블록 포인터, 디렉터리 엔트리, df -i, 아이노드 고갈 장애
답안 하드 링크는 같은 아이노드를 가리키는 또 다른 이름입니다. 원본과 완전히 동등하며, 아이노드의 링크 수가 0이 될 때(모든 이름 삭제) 실제 데이터가 삭제됩니다. 같은 파일시스템 안에서만 가능하고 디렉터리에는 만들 수 없습니다. 심볼릭 링크는 대상의 경로 문자열을 담은 별도 파일(자체 아이노드 보유)로, 다른 파일시스템·디렉터리도 가리킬 수 있지만 원본이 삭제되면 깨진 링크(dangling)가 됩니다. 참고로 '파일 삭제(rm)'는 실제로는 unlink, 즉 이름-아이노드 연결 제거이며, 삭제된 파일을 프로세스가 열고 있으면 링크 수가 0이어도 닫을 때까지 공간이 반환되지 않습니다. 이는 "지웠는데 df 용량이 안 줄어요" 장애의 원인입니다.
관련 개념 링크 카운트, unlink, 열린 파일과 공간 미반환(lsof +L1), ln vs ln -s
답안 파일 작업 하나(예: 파일 추가)는 아이노드, 디렉터리, 빈 공간 비트맵 등 여러 블록 수정으로 이뤄지는데, 도중에 전원이 나가면 일부만 반영되어 파일시스템이 불일치 상태가 됩니다. 과거에는 부팅 시 fsck로 전체 디스크를 검사해 복구했지만 대용량 디스크에서는 수 시간이 걸립니다. 저널링은 변경 내용을 먼저 저널(로그) 영역에 기록하고 커밋한 뒤 실제 위치에 반영합니다. 크래시가 나면 저널만 재생(redo)하거나 버려서 일관성을 빠르게 복구합니다. DB의 WAL(Write-Ahead Logging)과 같은 원리입니다. ext4는 기본으로 메타데이터만 저널링(ordered 모드)합니다.
관련 개념 크래시 일관성, fsck, 저널 재생, WAL, ext4 저널 모드(journal/ordered/writeback)
답안 연속 할당은 파일을 연속 블록에 저장합니다. 순차·직접 접근 모두 빠르지만 외부 단편화와 파일 확장 곤란이 문제입니다(CD-ROM 등에 적합). 연결 할당은 각 블록이 다음 블록 포인터를 가집니다. 단편화가 없고 확장이 자유롭지만 직접 접근이 O(n)이고 포인터 하나만 깨져도 이후를 잃습니다. FAT는 포인터를 별도 테이블로 모아 이를 개선한 변형입니다. 인덱스 할당은 블록 위치들을 인덱스 블록에 모아 저장해 직접 접근이 빠르며, 유닉스 아이노드의 직접/간접 포인터가 이 방식입니다(대용량은 다중 간접 블록으로 확장). 현대 파일시스템(ext4, XFS)은 연속된 블록 구간을 (시작, 길이)로 표현하는 익스텐트로 인덱스 방식의 메타데이터 부담을 줄입니다.
관련 개념 외부 단편화, FAT, 아이노드 간접 블록, 익스텐트
답안 버퍼드 I/O(기본값)는 페이지 캐시를 경유해 읽기 캐싱과 쓰기 지연(writeback)의 이득을 얻습니다. 다이렉트 I/O(O_DIRECT)는 페이지 캐시를 우회해 사용자 버퍼와 디스크가 직접 데이터를 주고받으며, 자체 캐시를 가진 DB(오라클, MySQL InnoDB)가 이중 캐싱을 피하려 사용합니다. 별개 축으로 동기 I/O는 완료까지 호출 스레드가 대기하고(블로킹), 비동기 I/O는 요청만 걸어두고 완료를 나중에 통지받습니다(리눅스 AIO, 최신 io_uring). 고성능 서버는 논블로킹 소켓+epoll(이벤트 기반) 또는 io_uring으로 적은 스레드로 많은 I/O를 처리합니다.
관련 개념 페이지 캐시, O_DIRECT, fsync(내구성 보장), epoll, io_uring
답안 RAID 0(스트라이핑): 데이터를 여러 디스크에 분산해 성능·용량 최대, 중복성 없음(디스크 1개 고장=전체 손실). RAID 1(미러링): 동일 데이터를 복제해 안정성 높지만 용량 효율 50%. RAID 5: 블록 스트라이핑+분산 패리티로 디스크 1개 고장 허용, 용량 효율 (n−1)/n, 쓰기 시 패리티 계산 오버헤드와 재빌드 중 추가 고장 위험이 단점. RAID 6: 패리티 2중으로 2개 고장 허용, 대용량 디스크 시대에 재빌드 위험 때문에 5보다 선호됨. RAID 10(1+0): 미러 쌍을 스트라이핑. 성능과 안정성이 좋아 DB 서버 정석이지만 용량 효율 50%. 면접에서는 "DB 서버에 어떤 RAID?"(→10 또는 6) 같은 선택 질문이 흔합니다. RAID는 백업이 아니라는 점(삭제·랜섬웨어 못 막음)도 언급하면 좋습니다.
관련 개념 스트라이핑/미러링/패리티, 재빌드 위험, 핫 스페어, RAID는 백업이 아님
답안 HDD는 헤드 이동(seek)이 지배적 비용이므로 요청 순서를 재배열해 이동을 줄입니다. FCFS는 도착 순서대로 처리(공정하지만 비효율). SSTF는 현재 헤드에서 가장 가까운 요청부터 처리(효율적이나 먼 요청 기아 가능). SCAN(엘리베이터)은 헤드가 한쪽 끝까지 이동하며 경로상 요청을 처리하고 방향을 반전합니다. C-SCAN은 한 방향으로만 처리하고 끝에 도달하면 처음으로 복귀해 대기 시간이 더 균등합니다. 계산 문제(총 이동 거리)로 자주 출제됩니다. 참고로 SSD는 seek이 없어 이런 스케줄링이 무의미하며, 리눅스는 SSD에 noop/none 스케줄러를 씁니다.
관련 개념 seek time, 엘리베이터 알고리즘, 이동 거리 계산, SSD와 스케줄러(none/mq-deadline)
답안 SSD는 기계적 이동이 없어 임의 접근이 HDD보다 수백 배 빠르고 순차/임의 성능 격차가 작습니다. 다만 덮어쓰기가 불가능해 블록을 지우고 다시 써야 하며(erase-before-write), 쓰기 수명이 유한합니다. 이에 따라 ① 디스크 스케줄링 단순화(none), ② TRIM 명령으로 삭제된 블록을 SSD에 알려 가비지 컬렉션 효율화, ③ 컨트롤러의 웨어 레벨링으로 쓰기 분산, ④ 임의 I/O 회피를 전제로 한 알고리즘들(B-tree 최적화 등)의 재검토, ⑤ NVMe·io_uring 같은 고속 인터페이스 대응이 이뤄졌습니다. 인프라 관점에서는 IOPS/지연시간 프로파일이 달라 DB 스토리지 설계 기준이 달라집니다.
관련 개념 erase-before-write, TRIM/discard, 웨어 레벨링, NVMe, IOPS
답안 리눅스는 일반 파일뿐 아니라 디렉터리, 장치(/dev/sda), 파이프, 소켓, 커널 정보(/proc, /sys)까지 파일 디스크립터와 read/write 인터페이스로 통일해서 다룬다는 설계 철학입니다. 덕분에 같은 도구(cat, redirect, epoll)로 다양한 자원을 조작할 수 있습니다. 예로 /proc/cpuinfo로 CPU 정보를 읽고, /sys로 커널 파라미터를 조정하며, 소켓도 fd로 select/epoll에 넣습니다. 프로세스당 열 수 있는 fd 수에는 한계(ulimit -n)가 있어, 대량 커넥션 서버에서 "Too many open files" 장애의 원인이 됩니다. 이 역시 인프라 면접 단골입니다.
관련 개념 파일 디스크립터, /proc, /sys, ulimit -n, Too many open files
답안 write()는 데이터를 커널의 페이지 캐시에 복사하면 성공을 반환할 뿐, 그 시점에 디스크에는 아직 없습니다(dirty page). 커널이 나중에 writeback하기 전 전원이 나가면 데이터가 유실됩니다. fsync()는 해당 파일의 더티 페이지와 메타데이터를 실제 저장 장치까지 내려쓰고 완료를 기다려 내구성(durability)을 보장합니다. DB가 트랜잭션 커밋 시 WAL에 fsync하는 이유이며, fsync 빈도는 내구성과 성능의 직접적 트레이드오프입니다(PostgreSQL synchronous_commit, MySQL innodb_flush_log_at_trx_commit). 디스크 자체 캐시까지 고려하면 배리어/FUA 플러시도 관련됩니다.
관련 개념 페이지 캐시와 dirty page, 내구성, WAL+fsync, flush 설정 튜닝