Day 4 - 파일시스템 구조와 파일의 종류: 모든 것은 파일이다

FHS — 디렉터리 구조의 약속

Day 1에서 만난 "모든 것은 파일이다"라는 철학이 실제로 어떻게 구현되는지, 그 첫 축인 공간적 구조부터 본다.

• /bin, /etc, /var 같은 배치는 무작위가 아니라 FHS(Filesystem Hierarchy Standard, 파일시스템 계층 표준)라는 공식 규약을 따른다.
• 덕분에 어떤 배포판을 쓰든 "설정 파일은 /etc에, 로그는 /var/log에 있다"는 약속이 지켜진다. 이 표준이 없다면 배포판마다 위치가 제각각이라 관리가 불가능했을 것이다.
• 윈도우와 근본적으로 다르다. 윈도우는 드라이브마다 C:, D:처럼 별도의 루트가 있지만, 리눅스는 단 하나의 루트(/)에서 뻗어나가는 단일 계층 트리다.
• 다른 디스크나 USB는 이 트리의 특정 디렉터리에 "마운트(mount)"되어 가지로 합쳐진다.

/bin과 /sbin은 쓰임이 다르다. /bin은 모든 사용자가 쓰는 일반 명령(ls, cp), /sbin은 주로 관리자(root)가 쓰는 시스템 관리 명령(fdisk, reboot)이다. "s"는 system 또는 superuser를 뜻한다. 마찬가지로 /usr/bin, /usr/sbin도 같은 구분을 따른다. 최근 배포판은 /bin을 /usr/bin의 심볼릭링크로 통합(usrmerge)하는 추세다.

가상 파일시스템 — /proc와 /sys

• /proc와 /sys는 디스크에 실제로 존재하는 파일이 아니라, 커널이 메모리상에서 실시간으로 만들어내는 가상 파일시스템(virtual filesystem)이다.
• "모든 것은 파일"이라는 철학이 가장 극적으로 드러나는 곳이다.
• 프로세스 정보, CPU 정보, 메모리 사용량 같은 커널 내부 상태를 파일을 읽듯이 확인할 수 있다.

# /proc - 커널과 프로세스 정보를 파일처럼 읽기
cat /proc/cpuinfo           # CPU 상세 정보
cat /proc/meminfo           # 메모리 사용 현황
cat /proc/version           # 커널 버전
ls /proc/1/                 # PID 1번 프로세스의 정보 디렉터리
 
# /sys - 하드웨어와 드라이버 정보
cat /sys/class/net/eth0/address    # 네트워크 인터페이스 MAC 주소
 
# 직접 쳐보기: 자신의 CPU 코어 수를 파일에서 세어보기
grep -c processor /proc/cpuinfo

/proc의 각 숫자 디렉터리(/proc/1234)는 PID 1234 프로세스에 대응한다. 그 안의 status, cmdline, fd/를 읽으면 그 프로세스가 어떤 명령으로 실행됐고 어떤 파일을 열고 있는지 알 수 있다. top, ps 같은 도구들도 사실 내부적으로 /proc를 읽어 정보를 보여주는 것이다. 가상 파일시스템은 0바이트 크기로 보이지만 읽으면 실시간 데이터가 나온다.

파일의 7가지 종류

ls -l 명령의 맨 앞 글자 하나가 그 파일의 종류를 알려준다. 이 식별 문자는 1급 시험에서 묻는 포인트다.

# ls -l의 첫 글자로 파일 종류 확인
ls -l /dev/sda              # b로 시작 → 블록 장치
ls -l /dev/tty             # c로 시작 → 문자 장치
ls -l /etc/passwd          # -로 시작 → 일반 파일
ls -ld /etc                # d로 시작 → 디렉터리
 
# file 명령으로 내용 기반 파일 종류 판별
file /etc/passwd           # ASCII text
file /bin/ls               # ELF 실행 바이너리

• 블록 장치(b): 데이터를 정해진 크기의 블록 단위로 읽고 쓰며 버퍼링과 임의 접근이 가능하다. 디스크, SSD, USB.
• 문자 장치(c): 데이터를 한 글자씩 순차적으로 흘려보낸다. 키보드, 마우스, 시리얼 포트, 터미널.
• 소켓(s)과 파이프(p): 프로세스 간 통신(IPC) 수단. 파이프(FIFO, named pipe)는 한 방향으로만 흐르고, 소켓은 양방향이며 네트워크 통신에도 쓰인다.

⚠️ 함정: 시험에서 "디스크 /dev/sda는 어떤 종류의 장치 파일인가?"라고 물으면 답은 블록 장치(b)다. "키보드나 터미널은?"이라고 물으면 문자 장치(c)다. 블록(랜덤 접근, 버퍼링)과 문자(순차, 스트림)의 구분을 혼동하기 쉽다. /dev/sda의 's'는 SCSI/SATA를 뜻하지 socket의 's'가 아니다.

inode — 파일의 진짜 정체

링크를 이해하려면 먼저 inode(아이노드, index node)를 알아야 한다. 리눅스 파일시스템의 가장 근본적인 개념이다.

• 흔히 "파일 = 이름 + 내용"이라고 생각하지만, 리눅스에서 파일의 본질은 inode다. inode는 파일에 대한 모든 메타데이터를 담은 자료구조다.
  • 파일 종류와 접근 권한(rwx)
  • 소유자(UID)와 그룹(GID)
  • 파일 크기
  • 타임스탬프(수정·접근·변경 시각)
  • 링크 수(이 inode를 가리키는 이름의 개수)
  • 실제 데이터가 저장된 디스크 블록의 주소
• 핵심은 파일 이름은 inode에 포함되지 않는다는 점이다. 파일 이름은 디렉터리 안에 "이름 → inode 번호" 매핑으로 저장될 뿐이다.
• 즉 디렉터리는 사실 "이름과 inode 번호의 짝을 담은 표"다.

# inode 번호 확인
ls -i file.txt             # 파일의 inode 번호 표시
stat file.txt              # inode 번호, 크기, 권한, 타임스탬프 등 상세
df -i                      # 파일시스템별 inode 사용량

파일시스템을 만들 때 inode 개수가 정해진다. 디스크 용량이 남아도 inode가 고갈되면 더 이상 파일을 만들 수 없다(df -i로 확인). 작은 파일을 무수히 만드는 메일 서버 등에서 "용량은 남았는데 No space left on device" 오류가 나는 것이 바로 inode 고갈 때문이다. 이것이 inode가 실무에서 중요한 이유다.

하드링크 vs 심볼릭링크 — 핵심 비교

1급 시험 범위에 드는 핵심 주제다.

• 하드링크(hard link) = 같은 inode를 가리키는 또 다른 이름.
  • 새 inode를 만들지 않고, 기존 inode를 가리키는 이름(디렉터리 엔트리)만 하나 더 추가한다.
  • 원본과 하드링크는 inode 번호가 완전히 같고 사실상 동등하다. 둘 중 어느 것이 "원본"인지 구분할 수 없다.
  • inode의 링크 수가 1 증가하며, 모든 이름을 지워 링크 수가 0이 되어야 실제 데이터가 삭제된다.
• 심볼릭링크(symbolic link, soft link) = 다른 파일의 경로(이름)를 담고 있는 별도의 파일. 윈도우의 "바로가기"와 같다.
  • 자기만의 새 inode를 가지며, 그 안에 "가리키는 대상의 경로"가 문자열로 저장된다.
  • 원본을 찾아갈 때는 그 경로를 따라간다.

# 하드링크 생성 (ln, 옵션 없음)
ln original.txt hardlink.txt
ls -li original.txt hardlink.txt   # inode 번호가 동일함을 확인
 
# 심볼릭링크 생성 (ln -s)
ln -s original.txt symlink.txt
ls -li original.txt symlink.txt    # inode 번호가 다름, l로 표시
 
# 직접 쳐보기: 원본을 지운 뒤 차이를 관찰
echo "hello" > orig.txt
ln orig.txt hard.txt
ln -s orig.txt soft.txt
rm orig.txt
cat hard.txt               # 정상 출력 (데이터 유지)
cat soft.txt               # No such file (깨진 링크)

• 위 실습이 두 링크의 본질적 차이를 가장 잘 보여준다.
• 원본 orig.txt를 삭제해도 하드링크 hard.txt는 같은 inode를 직접 가리키므로 데이터가 살아있다(링크 수가 2→1로 줄었을 뿐).
• 반면 심볼릭링크 soft.txt는 "orig.txt라는 경로"를 저장하고 있는데 그 경로가 사라졌으므로 깨진 링크가 된다.

⚠️ 함정: "심볼릭링크는 다른 파일시스템(파티션)과 디렉터리를 가리킬 수 있지만, 하드링크는 둘 다 불가능하다"가 핵심 출제 포인트다. 이유는 명확하다. 하드링크는 inode 번호를 공유하는데, inode 번호는 각 파일시스템 안에서만 유일하므로 파티션을 넘을 수 없다. 디렉터리 하드링크를 금지하는 이유는 파일시스템 트리에 순환(loop)이 생겨 find 같은 도구가 무한 반복에 빠지는 것을 막기 위함이다.

ls -l로 디렉터리를 보면 권한 옆에 숫자가 있다(예: drwxr-xr-x 2). 이 숫자가 바로 inode의 링크 수다. 새 디렉터리를 만들면 링크 수가 기본 2다. 자기 자신을 가리키는 .과 부모가 자식을 가리키는 이름, 이렇게 2개의 하드링크가 자동 생성되기 때문이다. 하위 디렉터리를 하나 만들 때마다 그 안의 ..이 부모를 가리키므로 부모의 링크 수가 1씩 늘어난다.

"inode"라는 이름의 유래는 데니스 리치도 정확히 기억하지 못한다고 밝힌 바 있다. 가장 유력한 설은 "index node"의 줄임말로, 파일의 정보를 색인(index)하는 노드라는 의미다. 1970년대 초 유닉스 초기 파일시스템 설계에서 탄생한 이 개념은 50년이 지난 지금도 ext4, XFS 등 리눅스 파일시스템의 근간으로 살아있다.

절대경로와 상대경로

• 절대경로(absolute path): 루트(/)에서 시작하는 완전한 경로. 항상 /로 시작하며, 현재 위치와 무관하게 동일한 파일을 가리킨다. 예: /home/user/docs/file.txt.
• 상대경로(relative path): 현재 작업 디렉터리(pwd)를 기준으로 한 경로. /로 시작하지 않는다.
• 특수 기호: .(현재 디렉터리), ..(부모 디렉터리), ~(홈 디렉터리).

pwd                        # 현재 작업 디렉터리(절대경로) 확인
cd /etc                    # 절대경로로 이동
cd ../var                  # 상대경로: 부모로 올라간 뒤 var로
cd ~                       # 홈 디렉터리로
cd -                       # 직전 디렉터리로 토글

.과 ..은 단순한 기호가 아니라 모든 디렉터리에 실제로 존재하는 하드링크다. ls -a로 보면 어떤 디렉터리에든 .(자기 자신)과 ..(부모)가 보인다. 이것이 디렉터리의 기본 링크 수가 2인 이유와 연결된다.

다음 시간에는 이번 주에 배운 운영체제 개념·라이선스·부팅·파일시스템을 종합 복습하고, 시험 유형의 문제로 실력을 점검한다.

📖 용어

• FHS : 리눅스 디렉터리를 어디에 무엇을 둘지 정한 표준. 배포판이 달라도 위치가 같은 이유다.
• 마운트(mount) : 별도의 디스크나 파티션을 트리의 특정 디렉터리에 붙여 하나의 나무로 합치는 것.
• 가상 파일시스템 : /proc·/sys처럼 디스크가 아니라 커널이 메모리에서 실시간으로 만들어내는 파일들.
• inode : 파일의 메타데이터(권한·소유자·크기·데이터 블록 주소)를 담는 자료구조. 파일명은 여기 없다.
• inode 고갈 : 용량은 남았는데 inode를 다 써서 파일을 못 만드는 상태. df -i로 확인한다.
• 링크 수 : 한 inode를 가리키는 이름의 개수. 0이 되어야 실제 데이터가 지워진다.
• 하드링크 : 같은 inode를 가리키는 또 하나의 이름. 파티션을 넘을 수 없고 디렉터리에는 못 건다.
• 심볼릭링크 : 대상의 경로 문자열을 담은 별도 파일. 원본이 사라지면 깨진 링크가 된다.
• 블록 장치 / 문자 장치 : 블록 단위로 임의 접근하는 장치(디스크)와 한 글자씩 흘려보내는 장치(키보드·터미널).
• FIFO(named pipe) : 파일처럼 생긴 단방향 프로세스 간 통신 통로. ls -l에서 p로 보인다.
• 절대경로 / 상대경로 : /에서 시작하는 완전한 주소와, 현재 위치를 기준으로 한 주소.