17강. 파일 시스템의 구성과 관리 ① — inode와 하드링크·심볼릭 링크 | 리눅스마스터 2급 완전정복 · 입문~중급 · 리눅스마스터 2급 1·2차 — 누구나패스

🎯 이 강의 학습 목표

이 강부터 2과목 1장 02절 파일 시스템의 구성과 관리로 넘어갑니다. 이 강을 마치면 파일 시스템 내부가 어떤 영역으로 나뉘는지 설명할 수 있고, inode가 무엇을 담고 무엇을 담지 않는지 구분하며, 하드 링크와 심볼릭 링크의 차이를 다섯 가지 기준으로 답할 수 있게 됩니다.

링크는 2차 시험 단골 주제입니다. 출제 형태는 대체로 비교표를 뒤집은 문제입니다. "하드 링크에 대한 설명으로 틀린 것은?" 같은 식이라, 다섯 가지 기준을 양쪽 다 말할 수 있어야 합니다. 이 강에서는 실제 실행 결과로 각 차이를 하나씩 확인합니다.

💡 파일 시스템 내부 구조

8강에서 파일 시스템을 "디스크에 얹는 규칙과 자료구조"라고 했습니다. 그 내부는 네 영역으로 나뉩니다.

영역	담는 내용
부트 블록	부팅에 필요한 정보(부트 섹터). 실제로는 안 쓰일 수도 있음
슈퍼 블록	파일 시스템 전체의 정보 — 블록 크기, 전체·사용 중인 블록 수, inode 총 개수, 마운트 상태
inode 블록	파일 하나당 inode 하나. 파일의 속성과 데이터 위치를 담음
데이터 블록	파일의 실제 내용

슈퍼 블록이 손상되면 파일 시스템 전체를 못 읽습니다. 그래서 파일 시스템은 슈퍼 블록의 백업본을 여러 곳에 복제해 두고, 19강에서 배울 fsck가 복구에 사용합니다.

💡 inode — 파일의 신분증

inode(index node)는 파일 하나의 속성 전체와 데이터 위치를 담은 구조체입니다. 파일을 만들면 inode가 하나 할당되고, 고유한 inode 번호가 붙습니다.

inode가 담는 것	inode가 담지 않는 것
파일 유형(일반·디렉터리·링크…)	파일 이름 (이름은 디렉터리가 갖고 있음)
권한(rwx·특수 권한)
소유자 UID·그룹 GID
파일 크기
시각 3종 — atime·mtime·ctime
링크 수와 데이터 블록 위치

"inode에 파일 이름이 없다"는 것이 이 단원 전체의 열쇠입니다. 그럼 이름은 어디 있을까요? 디렉터리에 있습니다. 디렉터리는 "이름 → inode 번호" 대응표일 뿐입니다.

이 구조에서 이름과 실체가 분리됩니다. 그래서 이름 여러 개가 같은 inode를 가리킬 수 있고, 그것이 바로 하드 링크입니다.

시각 3종도 시험에 나옵니다. atime(access, 마지막 읽은 시각), mtime(modify, 내용이 바뀐 시각), ctime(change, inode 정보가 바뀐 시각)입니다. chmod로 권한만 바꾸면 ctime만 갱신되고 mtime은 그대로입니다. ctime이 "생성 시각(creation)"이 아니라는 점이 대표적 함정입니다.

inode 개수는 파일 시스템을 만들 때 정해지고 나중에 늘릴 수 없습니다. 그래서 디스크 용량이 남아 있어도 inode가 고갈되면 파일을 못 만드는 상황이 생깁니다. 작은 파일을 대량으로 만드는 서버에서 실제로 발생하는 장애이며, df -i로 확인합니다.

💡 하드 링크와 심볼릭 링크

링크를 만드는 명령은 ln입니다. -s를 붙이면 심볼릭 링크, 안 붙이면 하드 링크입니다.

ln  원본 링크이름      # 하드 링크
ln -s 원본 링크이름    # 심볼릭 링크(소프트 링크)

둘의 차이를 다섯 가지 기준으로 정리합니다. 시험은 거의 이 표에서 나옵니다.

기준	하드 링크	심볼릭 링크
inode 번호	원본과 같음	원본과 다름(자기 inode를 가짐)
링크 수	만들 때마다 증가	변화 없음
파일 시스템 경계	넘을 수 없음(같은 파일 시스템만)	넘을 수 있음
디렉터리 대상	불가(일반 사용자)	가능
원본 삭제 시	내용 유지 — 여전히 읽힘	깨짐 — 접근 불가
크기	원본과 동일	경로 문자열 길이만큼
권한 표기	일반 파일과 같음	항상 `lrwxrwxrwx`

왜 하드 링크는 파일 시스템 경계를 못 넘을까요? 하드 링크는 inode 번호를 가리키는데, inode 번호는 파일 시스템 안에서만 고유하기 때문입니다. 다른 파일 시스템의 646664번과 이 파일 시스템의 646664번은 전혀 다른 파일입니다. 반면 심볼릭 링크는 경로 문자열을 저장하므로 어디든 가리킬 수 있습니다.

왜 디렉터리에 하드 링크를 못 걸까요? 디렉터리에 하드 링크를 허용하면 순환 구조가 생겨 파일 시스템 탐색이 무한 루프에 빠질 수 있기 때문입니다. 그래서 커널이 막습니다.

원본 삭제 시 동작 차이는 링크 수로 설명됩니다. 파일의 실제 삭제는 링크 수가 0이 될 때 일어납니다. 하드 링크가 있으면 원본 이름을 지워도 링크 수가 1 남아 데이터가 보존됩니다. 반면 심볼릭 링크는 경로만 적어 둔 이정표라서, 원본이 사라지면 가리킬 곳이 없어 깨진 링크(dangling link)가 됩니다.

💻 실습으로 확인하기

아래는 /tmp/lm17에서 실제 실행한 결과입니다. orig.txt를 만들고 하드 링크와 심볼릭 링크를 하나씩 걸었습니다.

$ echo "original" > orig.txt
$ ln orig.txt hard.txt          # 하드 링크
$ ln -s orig.txt soft.txt       # 심볼릭 링크

$ ls -li
646664 -rw-r--r-- 2 chung chung 9 Sep 12 21:10 hard.txt
646664 -rw-r--r-- 2 chung chung 9 Sep 12 21:10 orig.txt
646666 lrwxrwxrwx 1 chung chung 8 Sep 12 21:10 soft.txt -> orig.txt

세 가지를 한 번에 확인할 수 있습니다.

첫째, inode 번호(맨 앞 숫자)를 보십시오. orig.txt와 hard.txt가 똑같이 646664입니다. 같은 파일에 이름만 두 개인 것입니다. 반면 soft.txt는 646666으로 다릅니다.

둘째, 링크 수(권한 다음의 숫자)를 보십시오. orig.txt와 hard.txt가 2입니다. "이 inode를 가리키는 이름이 두 개"라는 뜻입니다. soft.txt는 1입니다.

셋째, 크기를 보십시오. orig.txt와 hard.txt는 9바이트(original 8글자 + 줄바꿈)인데, soft.txt는 8바이트입니다. 이것은 내용이 아니라 가리키는 경로 문자열 orig.txt의 글자 수입니다. 심볼릭 링크가 경로를 저장할 뿐이라는 사실이 크기에 드러납니다.

$ stat orig.txt
  File: orig.txt
  Size: 9         	Blocks: 8          IO Block: 4096   regular file
Device: 8,48	Inode: 646664      Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/   chung)   Gid: ( 1000/   chung)
Access: 2026-09-12 21:10:18.452010788 +0900
Modify: 2026-09-12 21:10:18.452010788 +0900
Change: 2026-09-12 21:10:18.452010788 +0900

stat은 inode의 내용을 통째로 보여 주는 명령입니다. 앞에서 표로 정리한 항목이 전부 있습니다. Inode: 646664, Links: 2, 권한 0644, 소유자 1000/chung, 그리고 시각 3종(Access=atime, Modify=mtime, Change=ctime)입니다. 그런데 이 출력 어디에도 "이름"이 inode 안에 있다는 표시는 없습니다. 맨 위 File: orig.txt는 stat이 인자로 받은 이름을 그대로 보여 준 것일 뿐입니다.

이제 원본을 지워 보겠습니다. 이 강에서 가장 중요한 실험입니다.

$ rm orig.txt
$ ls -li
646664 -rw-r--r-- 1 chung chung 9 Sep 12 21:10 hard.txt
646666 lrwxrwxrwx 1 chung chung 8 Sep 12 21:10 soft.txt -> orig.txt

$ cat hard.txt
original

$ cat soft.txt
cat: soft.txt: No such file or directory

결과가 극명하게 갈립니다. hard.txt는 그대로 original을 출력합니다. inode 646664와 데이터 블록이 살아 있고, 링크 수만 2에서 1로 줄었습니다. 반면 soft.txt는 No such file or directory 오류가 납니다. soft.txt 자체는 ls에 여전히 보이지만, 가리키는 orig.txt가 사라져 깨진 링크가 된 것입니다.

"원본을 지워도 하드 링크는 살아 있고 심볼릭 링크는 깨진다"는 시험 문장이 이 네 줄로 증명됩니다.

$ mkdir -p dd/sub1 dd/sub2
$ ls -ldi dd
646667 drwxr-xr-x 4 chung chung 4096 Sep 12 21:10 dd

디렉터리의 링크 수가 4입니다. 하위 디렉터리를 두 개 만들었을 뿐인데 왜 4일까요? 디렉터리의 링크 수는 ① 자기 이름 dd + ② 자기 안의 . + ③ sub1 안의 .. + ④ sub2 안의 ..로 계산됩니다. 즉 하위 디렉터리 개수 + 2입니다. 하위 디렉터리가 없으면 2입니다. 이 계산이 시험에 나오기도 합니다.

$ df -i /
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/sdd       67108864 663713 66445151    1% /

df -i는 용량이 아니라 inode 사용량을 보여 줍니다. 총 6,710만 개 중 66만 개를 쓰고 있어 IUse%가 1%입니다. 용량은 남았는데 파일이 안 만들어질 때 가장 먼저 확인해야 할 출력이며, 여기서 IUse%가 100%라면 inode 고갈이 원인입니다.

⚠️ 시험에 나오는 함정

함정	정확한 사실
inode에 파일 이름이 들어 있다	이름은 디렉터리에 있음. inode는 속성과 위치만
하드 링크는 원본과 inode 번호가 다르다	같다. 다른 것은 심볼릭 링크
심볼릭 링크를 만들면 링크 수가 늘어난다	하드 링크만 증가
하드 링크로 디렉터리를 가리킬 수 있다	불가. 순환 구조 방지를 위해 커널이 막음
하드 링크는 다른 파티션에도 걸 수 있다	불가. inode 번호가 파일 시스템 내부에서만 고유
원본을 지우면 하드 링크도 못 읽는다	읽힌다. 링크 수가 0이 될 때만 실제 삭제
`ctime`은 파일 생성 시각이다	inode 정보가 바뀐 시각(change)
디스크 용량이 남으면 파일을 못 만들 일은 없다	inode 고갈 시 생성 실패 — `df -i`로 확인

📝 핵심 요약 — 암기표

항목	핵심
파일 시스템 4영역	부트 블록 · 슈퍼 블록(전체 정보) · inode 블록 · 데이터 블록
inode가 담는 것	유형 · 권한 · UID/GID · 크기 · 시각 3종 · 링크 수 · 블록 위치
inode가 안 담는 것	파일 이름 (디렉터리가 "이름→inode" 표로 보관)
시각 3종	`atime` 읽기 · `mtime` 내용 변경 · `ctime` inode 정보 변경
하드 링크	같은 inode · 링크 수 증가 · 파일 시스템 내부만 · 디렉터리 불가 · 원본 삭제해도 유지
심볼릭 링크	다른 inode · 링크 수 불변 · 파일 시스템 넘음 · 디렉터리 가능 · 원본 삭제하면 깨짐
명령	`ln`(하드) · `ln -s`(심볼릭) · `ls -i` · `stat` · `df -i`
디렉터리 링크 수	하위 디렉터리 개수 + 2
실제 삭제 시점	링크 수가 0이 될 때

다음 18강에서는 만들어진 파일 시스템을 실제로 쓰는 단계인 mkfs·mount·umount와 /etc/fstab을 다룹니다. fstab의 6개 필드는 잘못 쓰면 부팅이 실패하는 지점이라 시험에도 자주 나옵니다.

📋 실전 문제

1. inode가 담고 있는 정보가 아닌 것은?
① 파일의 권한과 소유자 ② 파일의 크기
③ 파일의 이름 ④ 데이터 블록의 위치

2. 하드 링크에 대한 설명으로 틀린 것은?
① 원본 파일과 inode 번호가 동일하다.
② 링크를 만들면 원본의 링크 수가 증가한다.
③ 서로 다른 파일 시스템 사이에도 생성할 수 있다.
④ 원본을 삭제해도 링크를 통해 내용을 읽을 수 있다.

3. 심볼릭 링크에 대한 설명으로 옳은 것은?
① 원본과 같은 inode 번호를 갖는다.
② 디렉터리를 대상으로는 만들 수 없다.
③ 원본 파일을 삭제하면 링크가 깨져 접근할 수 없다.
④ 링크를 만들면 원본의 링크 수가 1 증가한다.

4. 하드 링크가 다른 파일 시스템에는 생성될 수 없는 이유로 가장 적절한 것은?
① 파일 크기 제한 때문에
② inode 번호가 해당 파일 시스템 내부에서만 고유하기 때문에
③ 권한이 서로 달라지기 때문에
④ 심볼릭 링크만 커널이 지원하기 때문에

5. chmod 644 file을 실행했을 때 갱신되는 시각으로 알맞은 것은?
① atime만 ② mtime만
③ ctime만 ④ 세 시각 모두

6. 파일 시스템 전체의 블록 크기, 전체 블록 수, inode 개수 등의 정보를 담고 있는 영역은?
① 부트 블록 ② 슈퍼 블록 ③ inode 블록 ④ 데이터 블록

7. 디스크 용량은 충분히 남아 있는데도 새 파일을 생성할 수 없는 상황의 원인을 확인하는 명령은?
① df -h ② df -i ③ du -sh ④ free -h

8. 하위 디렉터리가 3개인 디렉터리의 링크 수로 알맞은 것은?
① 3 ② 4 ③ 5 ④ 6

✅ 정답과 해설

1. 정답 ③
파일 이름은 inode가 아니라 디렉터리가 갖고 있습니다. 디렉터리는 "이름 → inode 번호" 대응표이며, 이 분리 구조 덕분에 이름 여러 개가 같은 inode를 가리키는 하드 링크가 가능합니다. ①·②·④는 모두 inode에 저장되며 stat으로 확인할 수 있습니다.

2. 정답 ③
하드 링크는 같은 파일 시스템 안에서만 만들 수 있습니다. inode 번호가 파일 시스템 내부에서만 고유하기 때문입니다. 파일 시스템 경계를 넘으려면 심볼릭 링크를 써야 합니다. ①·②·④는 모두 옳습니다.

3. 정답 ③
심볼릭 링크는 경로 문자열만 저장하므로 원본이 사라지면 깨진 링크가 되어 접근할 수 없습니다. ①은 심볼릭 링크가 자기 inode를 따로 가지므로 틀리고, ②는 디렉터리 대상도 가능하므로 틀립니다(불가능한 쪽이 하드 링크). ④의 링크 수 증가는 하드 링크의 특성입니다.

4. 정답 ②
inode 번호는 해당 파일 시스템 안에서만 고유합니다. 다른 파일 시스템의 같은 번호는 전혀 다른 파일이므로, 번호만으로 가리키는 하드 링크는 경계를 넘을 수 없습니다. 반면 심볼릭 링크는 경로 문자열을 저장하므로 제약이 없습니다.

5. 정답 ③
chmod는 권한, 즉 inode의 정보를 바꾸므로 ctime(change time)만 갱신됩니다. 파일 내용은 건드리지 않았으므로 mtime은 그대로이고, 읽지도 않았으므로 atime도 변하지 않습니다. ctime을 "생성 시각"으로 오해하면 이 문제를 틀립니다.

6. 정답 ②
슈퍼 블록이 파일 시스템 전체의 메타 정보를 담습니다. 손상되면 파일 시스템 전체를 읽을 수 없어 백업본을 여러 곳에 복제해 둡니다. ③의 inode 블록은 개별 파일의 정보, ④의 데이터 블록은 실제 내용입니다.

7. 정답 ②
df -i로 inode 사용량을 확인합니다. inode 개수는 파일 시스템 생성 시 고정되므로, 작은 파일을 대량으로 만들면 용량이 남아도 inode가 먼저 고갈될 수 있습니다. ①의 df -h는 용량만 보여 주어 원인을 찾지 못합니다.

8. 정답 ③
디렉터리의 링크 수는 하위 디렉터리 개수 + 2입니다. 자기 이름 1개, 자기 안의 . 1개, 그리고 하위 디렉터리 3개가 각각 갖는 .. 3개를 더해 5가 됩니다. 하위 디렉터리가 없는 빈 디렉터리는 2입니다.

파일 시스템의 구성과 관리 ① — inode와 하드링크·심볼릭 링크