Step 27. 디렉토리 구조 탐구 — 리눅스 지도를 손에 넣다
Level 0 — 컴퓨터 조작과 구조의 이해 | 난이도 ★★☆☆☆ | 예상 소요 시간 3시간
전제: Step 18~26까지의 리눅스 기본기(명령, 권한, 프로세스)를 끝냈어야 합니다. 우분투 가상머신(또는 WSL 우분투)이 필요합니다.
- 준비물: 우분투 터미널. 새로 설치하는 것은 없습니다.
- 주의: 오늘 실습은 100% 조회입니다.
ls,cat,df,du로 보기만 합니다./etc같은 시스템 영역의 파일을 수정하는 일은 오늘 없습니다.
윈도우를 오래 쓴 사람은 폴더 구조가 제멋대로라고 느끼곤 합니다. 프로그램은 Program Files에도 AppData에도 있고, 설정은 레지스트리에도 ini 파일에도 있죠. 리눅스는 다릅니다. 수십 년 된 표준 배치표가 있어서 "설정은 여기, 로그는 여기, 명령어는 여기"가 약속되어 있습니다. 보안 실무에서 서버에 접속하면 처음 하는 일이 "뭐가 어디 있지?"를 파악하는 것 — 오늘은 그 지도를 완성하고, 디스크에 존재하지 않으면서 존재하는 신비한 폴더 /proc도 만납니다.
1. 학습 목표
이 챕터를 끝내면 다음을 할 수 있습니다:
- 리눅스 최상위 폴더(
/etc,/var,/bin등)의 역할을 설명한다 - 임의의 경로를 보고 "이건 어떤 종류의 파일이겠구나"를 추측한다
/proc이 디스크가 아니라 커널이 실시간으로 만들어 내는 가상 폴더임을 설명한다df로 디스크 여유를,du로 폴더별 크기를 확인한다- "리눅스에서는 모든 것이 파일"이라는 설계 철학을
/proc실습으로 확인한다
2. 배경 지식 — 오늘의 도구와 개념
오늘의 도구 한눈에 보기
| 구분 | 내용 |
|---|---|
| 언어·환경 | bash — 우분투 터미널 (가상머신 또는 WSL) |
| 오늘의 명령어 | ls /(최상위 보기), cat /proc/...(가상 파일 읽기), df -h(디스크 여유), du -sh(폴더 크기), which(명령어의 실제 위치) |
| 필요한 개념 | FHS(파일시스템 계층 표준), 루트(/)와 마운트, 가상 파일시스템, /proc과 /dev |
2-1. 뿌리 하나 — /에서 시작하는 나무
리눅스의 모든 경로는 /(루트, root) 하나에서 시작합니다. 윈도우처럼 C: 드라이브, D: 드라이브가 나뉘어 있지 않습니다. USB를 꽂아도, 다른 디스크를 붙여도, 전부 이 나무 어딘가의 가지로 들어옵니다 — 이것을 마운트(mount), "나무에 매단다"고 합니다.
나무가 하나라는 것은, 어떤 파일이든 /부터 따라가면 도달할 수 있다는 뜻입니다.
2-2. 최상위 폴더 지도 — FHS
이 약속의 이름이 FHS(Filesystem Hierarchy Standard, 파일시스템 계층 표준)입니다. 핵심 폴더들:
| 폴더 | 역할 | 비유 |
|---|---|---|
/bin, /sbin |
기본 명령어·시스템 명령어의 실행 파일 | 공구함 |
/etc |
설정 파일들 | 건물 관리실의 서류함 |
/home |
사용자들의 홈 폴더 | 각자의 방 |
/var |
로그 등 "변하는 데이터" | 일기장·장부 |
/tmp |
임시 파일 (재부팅하면 지워짐) | 작업대 위 스크래치 종이 |
/usr |
설치된 프로그램과 라이브러리 | 창고 |
/proc |
커널이 실시간으로 만드는 가상 폴더 | 컴퓨터의 속마음 |
/dev |
장치(디스크, 터미널 등)를 파일처럼 보여 줌 | 장비 접속구 |
/root |
root의 홈 폴더 (일반 사용자 출입 금지) | 관리자실 |
외우려 하지 마세요. 오늘 손으로 돌아다니면 자연스럽게 남습니다. 기억할 한 줄: "설정은 /etc, 로그는 /var, 내 물건은 /home".
2-3. /proc — 살아 있는 가상 폴더
오늘의 하이라이트입니다. /proc 안의 파일들은 디스크 어디에도 저장되어 있지 않습니다. ls /proc을 하는 순간, 커널(kernel, 운영체제의 심장)이 "지금 이 시각의 상태"를 파일 모양으로 즉석에서 만들어 보여 줍니다.
- 숫자 이름의 폴더들: 지금 실행 중인 프로세스들의 PID(Step 26의 그 번호!).
/proc/652/는 PID 652 프로세스의 정보 폴더입니다. /proc/cpuinfo: CPU 정보./proc/meminfo: 메모리 정보.
그래서 /proc 파일들은 ls -l로 보면 크기가 0입니다. 내용이 없어서가 아니라, "읽는 순간 생성"되기 때문에 미리 크기를 알 수 없는 것입니다. cat으로 읽으면 내용이 술술 나옵니다. "리눅스에서는 모든 것이 파일"이라는 철학의 극치 — 심지어 커널의 속마음도 파일입니다.
3. 따라 하기
3-1. 최상위 폴더 둘러보기
ls /
bin dev home lib64 mnt proc run srv tmp var
boot etc lib media opt root sbin sys usr
(실측 출력은 환경에 따라 이보다 항목이 더 많습니다 — 2026-09-09 실측한 WSL 우분투에는 init, snap, lost+found, bin.usr-is-merged 같은 추가 항목이 있었습니다. 지도의 핵심 폴더들은 전부 그 안에 그대로 있습니다.)
읽는 법: 2-2절 지도의 폴더들이 실제로 보입니다. 각각의 역할을 소리 내어 추측해 본 뒤 지도와 대조하세요.
ls /etc | head -10
NetworkManager
PackageKit
X11
adduser.conf
alternatives
apache2
apparmor
apparmor.d
apport
apt
(2026-09-09 WSL 우분투 24.04에서 실측. 여러분 환경의 목록은 설치된 프로그램에 따라 다릅니다.)
읽는 법: 전부 설정 파일 또는 설정 폴더입니다. adduser.conf는 계정을 만들 때 쓴 adduser의 설정이네요. 이름을 보면 "아, 이 프로그램의 설정이구나"가 보이기 시작합니다.
3-2. /proc 탐험
ls /proc | head -6
1
114
115
183
...
(2026-09-09 실측.)
읽는 법: 숫자 이름들 = 지금 살아 있는 프로세스의 PID입니다. Step 26에서 ps aux로 본 세계가 폴더 모양으로 펼쳐져 있습니다.
cat /proc/cpuinfo | head -13
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 197
model name : Intel(R) Core(TM) Ultra 7 255H
stepping : 2
microcode : 0xffffffff
cpu MHz : 3686.397
cache size : 24576 KB
...
(2026-09-09 실측. 여러분 컴퓨터의 CPU 모델과 클럭으로 다르게 나옵니다.)
읽는 법: 방금 전까지 존재하지 않다가, cat이 읽는 순간 커널이 만들어 준 내용입니다.
예측해 보기:
ls -l /proc/cpuinfo로 이 파일의 크기를 보면 얼마로 나올까요? ① CPU 정보니까 몇 KB ② 0바이트. 예측하고 확인해 보세요. (정답: 0바이트 — 실측 결과-r--r--r-- 1 root root 0 ... /proc/cpuinfo로, 크기 칸이 0입니다. 가상 파일이라 읽기 전엔 크기가 정해져 있지 않습니다. 2026-09-09 실측.)
cat /proc/meminfo | head -5
MemTotal: 7839388 kB
MemFree: 6374836 kB
MemAvailable: 7065700 kB
Buffers: 51784 kB
Cached: 769476 kB
(2026-09-09 실측.)
읽는 법: 전체 메모리, 빈 메모리, 실질 사용 가능 메모리입니다. 서버가 느릴 때 여길 봅니다.
cat /proc/1/cmdline; echo
/sbin/init
(2026-09-09 실측.)
읽는 법: PID 1 — Step 26에서 배운 "모든 프로세스의 조상"의 실행 명령입니다. (끝의 echo는 줄바꿈용입니다. cmdline은 마지막에 줄바꿈이 없어서 프롬프트가 붙어 보입니다.)
왜: 프로세스, 하드웨어, 커널 상태가 전부 "파일 읽기"로 조회됩니다. 복잡한 API가 아니라 cat이면 됩니다 — 이것이 리눅스의 세계관입니다.
3-3. 디스크 용량 보기 — df와 du
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdd 1007G 2.6G 954G 1% /
...
(2026-09-09 실측 — WSL의 /에 마운트된 디스크 줄입니다. 여러분 가상머신에서는 보통 /dev/sda1 40G ...처럼 보이고, 실측 화면에는 이밖에 tmpfs 등 가상 파일시스템 줄이 여러 개 함께 나옵니다 — 벽 4에서 다룹니다.)
읽는 법: df는 "disk free(디스크 여유)". -h는 사람이 읽기 좋은 단위(G, M)로 보여 달라는 뜻입니다. 실측 첫 줄을 읽으면: 전체 1007G 중 2.6G 사용, 954G 여유, 사용률 1%, /에 마운트됨.
du -sh ~
8.4M /root
(2026-09-09 실측 — 실측 환경은 관리자 계정이라 홈이 /root였습니다. 여러분은 1.2G /home/여러분계정 같은 식으로 나옵니다.)
읽는 법: du는 "disk usage(디스크 사용량)". -s는 합계만, -h는 사람 단위. ~는 "내 홈 폴더"의 약자입니다.
왜: df는 "디스크 전체가 얼마나 찼나", du는 "이 폴더가 얼마나 먹나"입니다. 서버 운영에서 디스크 가득 참은 장애의 단골 원인이고, 이 두 명령이 진단의 시작입니다. 로그가 쌓여 /var가 터지는 사고는 결코 드물지 않습니다.
3-4. 로그의 고향 /var 구경
ls /var/log | head -12
README
alternatives.log
apt
auth.log
bootstrap.log
btmp
dist-upgrade
dmesg
...
(2026-09-09 실측.)
읽는 법: Step 24에서 본 auth.log(sudo와 로그인 기록)가 여기 살고 있습니다. 시스템의 일기들이 모인 곳입니다.
sudo tail -5 /var/log/syslog
(출력은 생략합니다 — 시스템 전체 로그의 최근 다섯 줄이 나옵니다. 무슨 일들이 적히는지 분위기만 느끼면 됩니다. syslog가 없는 최신 환경에서는 sudo journalctl -n 5가 같은 역할을 합니다.)
왜: 앞으로 "문제가 생기면 로그를 본다"는 습관의 목적지가 바로 이 폴더입니다. 지도에 별표를 쳐 두세요.
3-5. 명령어의 실제 주소 — which
which date ls grep bash
/usr/bin/date
/usr/bin/ls
/usr/bin/grep
/usr/bin/bash
(2026-09-09 실측.)
읽는 법: 우리가 매일 치던 명령어들의 실제 파일 위치입니다. 2-2절 지도의 /bin이 보통 /usr/bin으로 연결(심볼릭 링크)되어 있어서 이렇게 나옵니다. "명령어도 결국 어딘가에 있는 파일"이라는 사실이 확인됐습니다.
4. 미션과 연습문제
미션 — 내 리눅스의 파일시스템 지도 그리기
- 오늘 배운 최상위 폴더 아홉 개를 나무 그림으로 그리고 각각 한 줄 설명을 달아
filesystem-map.txt로 저장하세요 sleep 300 &으로 프로세스를 하나 만들고, 나온 PID로/proc/PID/폴더를ls로 구경하세요 —cat /proc/PID/cmdline; echo로 "내 프로세스"임을 확인합니다df -h /의 Use%를 지도 한구석에 메모하고,du -sh ~/* 2>/dev/null | sort -h | tail -3으로 내 홈에서 가장 큰 것 세 개도 적으세요/proc아래 파일 두 개(cpuinfo, meminfo 외 아무거나)를 더cat으로 읽고,ls -l로 크기가 0인 것을 함께 확인하세요- 마쳤으면 Step 26에서 배운 대로
kill로 sleep을 정리하세요
연습문제
문제 1. 다음 파일이 어느 폴더에 있을지 FHS 지도로 추측해 보세요 — ① nginx 웹서버의 설정 ② 시스템 로그인 기록 ③ grep 명령어의 실행 파일 ④ 공격자가 몰래 풀어 놓기 좋아하는 임시 실행 파일.
문제 2. /proc/cpuinfo는 ls -l로 보면 0바이트인데 cat으로 읽으면 내용이 나옵니다. 깨진 파일인가요? 왜 이런 일이 생기나요?
문제 3. df -h와 du -sh ~는 둘 다 "용량"을 보는 명령입니다. 각각 무엇을 재는 것이며, "서버가 디스크 부족으로 죽었다"는 신고를 받으면 어떤 순서로 쓰나요?
문제 4. 리눅스에는 C:, D: 같은 드라이브 문자가 없습니다. USB를 꽂으면 그 파일들은 어떻게 / 나무 안에 들어오나요? 이 방식의 이름을 말해 보세요.
5. 모범 답안과 완료 기준
미션 모범 답안
nano filesystem-map.txt # 아래 내용을 참고해 직접 작성
/ (루트 — 모든 것의 시작)
├─ /etc : 설정 파일 (서류함)
├─ /var : 로그·변하는 데이터 (일기장) — /var/log가 로그의 고향
├─ /home : 사용자 홈 (각자의 방)
├─ /bin, /sbin : 명령어 실행 파일 (공구함)
├─ /usr : 설치된 프로그램 (창고)
├─ /tmp : 임시 파일 (재부팅 시 삭제)
├─ /proc : 커널이 실시간으로 만드는 가상 폴더 (속마음)
└─ /dev : 장치를 파일처럼 보여 주는 곳 (접속구)
디스크 현황: / 사용률 1% (df -h, 2026-09-09 실측 기준)
검증하는 법: ① 지도에 아홉 폴더가 전부 있고 설명이 내 말로 되어 있는가. ② 2번에서 /proc/PID/cmdline이 sleep 300을 보여 줬는가 — 그랬다면 Step 26의 프로세스 세계와 오늘의 파일 세계가 하나로 연결된 것입니다. ③ ls -l /proc/...의 크기 칸이 0이었는가. ④ 마지막에 jobs가 비어 있는가(정리 확인).
연습문제 해답
문제 1 해답. ① /etc/nginx — 설정은 /etc. ② /var/log/auth.log — 로그는 /var. ③ /bin 또는 /usr/bin — which grep으로 확인 가능 (2026-09-09 실측: /usr/bin/grep). ④ /tmp나 /dev/shm — 재부팅하면 지워지고 의심을 덜 받는 임시 공간이라 공격자가 도구를 풀기 좋아하는 곳입니다.
문제 2 해답. 깨진 것이 아니라 가상 파일의 정상 동작입니다. /proc의 파일은 디스크에 저장된 내용이 없고, 읽는 순간 커널이 "지금 상태"를 즉석에서 생성합니다. 읽기 전에는 크기가 정해져 있지 않으므로 0으로 표시됩니다 (2026-09-09 실측으로 크기 0 확인). 규칙: /proc과 /sys의 파일은 "크기는 무시하고 cat으로만 본다".
문제 3 해답. df -h는 디스크(파일시스템) 전체가 얼마나 찼는지를, du -sh 폴더는 그 폴더가 얼마를 먹는지를 잽니다. 신고를 받으면 ① df -h로 어느 디스크가 찼는지 확인 → ② 그 안에서 du -sh /var/* | sort -h | tail 같은 식으로 범인 폴더를 좁혀 갑니다. 대표 범인은 쌓인 로그입니다.
문제 4 해답. 마운트(mount) — 나무의 한 지점(보통 /media/계정명/아무개)에 USB의 내용을 "매달아" 붙입니다. 그래서 모든 저장 장치가 / 하나로 시작하는 단일 나무 안에 들어옵니다. df -h 출력 맨 오른쪽의 "Mounted on" 컬럼이 그 매달린 지점들입니다.
완료 기준 체크리스트
- [ ] 최상위 폴더 아홉 개의 역할을 말할 수 있다
- [ ] "설정은 /etc, 로그는 /var, 내 물건은 /home"을 기억하고 활용할 수 있다
- [ ] /proc이 가상 폴더인 이유와 0바이트의 의미를 설명할 수 있다
- [ ] df -h와 du -sh의 차이를 설명할 수 있다
- [ ] 마운트가 무엇인지 한 문장으로 말할 수 있다
- [ ]
which로 명령어의 실제 위치를 찾을 수 있다 - [ ] 미션: filesystem-map.txt와 /proc 탐험을 완료했다
6. 흔한 실수와 해결
벽 1. "/proc 파일이 0바이트인데 왜 내용이 나오죠? 깨진 건가요?"
증상: ls -l로 보면 크기가 0인데 cat으로 읽으면 내용이 나옵니다 (2026-09-09 실측으로 그대로 재현).
원인: 고장이 아니라 가상 파일의 정상 동작입니다. 읽는 순간 커널이 생성하므로 미리 크기가 없습니다.
해결: /proc과 /sys의 파일은 "크기는 무시하고 cat으로만 본다"가 규칙입니다. nano로 열거나 cp로 복사해도 어색하게 동작하니, 읽기 전용으로만 대하세요.
벽 2. "/etc 파일을 고쳤는데 저장이 안 돼요"
증상: nano로 /etc 안의 파일을 열어 수정했는데 저장 시 Permission denied.
원인: /etc는 시스템 영역이라 일반 사용자는 읽기만 됩니다. Step 24의 "공공시설의 열쇠"가 필요한 곳입니다.
해결: sudo nano /etc/파일명으로 엽니다. 단, 고치기 전에 원본을 sudo cp 파일명 파일명.bak으로 백업하는 습관을 붙이세요. 설정 파일 사고의 90%는 백업이 구해 줍니다. (오늘 챕터의 범위는 조회까지입니다.)
벽 3. "폴더 이름이 비슷비슷해서 헷갈려요. /bin, /sbin, /usr/bin…"
증상: 명령어가 어디 있는지, 왜 비슷한 폴더가 여러 개인지 혼란스럽습니다.
원인: 역사적 이유로 계층이 겹쳐 있습니다. sbin은 시스템 관리자용, /usr 아래는 설치된 프로그램용이라는 식의 구분이고, 최신 우분투는 /bin이 /usr/bin으로 연결돼 있습니다.
해결: 지금은 전부 외우지 마세요. which 명령어가 실제 위치를 알려 줍니다 (3-5절 실측처럼).
벽 4. "df -h를 쳤는데 tmpfs라는 게 여러 개 나와요. 디스크가 여러 개인가요?"
증상: df 출력에 /dev/… 외에 tmpfs가 여러 줄 보입니다.
원인: tmpfs는 디스크가 아니라 메모리 위에 만든 가상 파일시스템입니다. /dev/shm처럼 "빠른 임시 공간" 용도입니다.
해결: /dev로 시작하는 진짜 디스크 줄만 보면 됩니다. /에 마운트된 것이 여러분의 주 디스크입니다.
벽 5. "/proc/숫자 폴더에 들어갔더니 파일이 잔뜩인데 뭘 봐야 할지 모르겠어요"
증상: /proc/1/ 같은 곳을 ls로 열었더니 수십 개의 파일이 나옵니다.
원인: 프로세스 하나의 상태가 전부 파일로 펼쳐져 있기 때문입니다. 전부 이해할 필요는 없습니다.
해결: 초보 단계에서 볼 것은 셋입니다. cmdline(무슨 명령으로 시작했나), status(상태 요약), cwd(현재 작업 폴더 — 심볼릭 링크라 ls -l로 봅니다).
7. 정리
오늘의 개념
| 개념 | 한 줄 설명 |
|---|---|
| FHS | 리눅스 폴더 배치의 표준 약속 |
루트(/) |
모든 경로가 시작하는 단 하나의 뿌리 |
| 마운트 | 저장 장치를 / 나무의 한 지점에 매달기 |
| /proc | 커널이 실시간으로 생성하는 가상 폴더 — 크기 0이 정상 |
| tmpfs | 메모리 위의 가상 파일시스템 (/dev/shm 등) |
오늘의 명령어
| 명령 | 하는 일 |
|---|---|
ls / |
최상위 폴더 목록 |
cat /proc/cpuinfo, cat /proc/meminfo |
커널이 만드는 하드웨어 정보 읽기 |
cat /proc/1/cmdline |
PID 1(조상 프로세스)의 실행 명령 |
df -h |
디스크 전체 여유 (사람 단위) |
du -sh 폴더 |
그 폴더의 크기 합계 |
which 명령어 |
명령어 실행 파일의 실제 위치 |
명령어보다 중요한 감각
침해 사고 현장에 접속한 조사관의 첫 30분을 상상해 봅시다. 그는 오늘 여러분이 걸은 코스를 그대로 걷습니다. /var/log에서 로그인 기록(auth.log)을 펼치고, /tmp와 /dev/shm을 뒤져 낯선 실행 파일을 찾고, /etc에서 최근 바뀐 설정을 확인합니다. 전문가의 수사 동선과 오늘 초보의 산책 코스가 같습니다 — 차이는 속도와 해석력이지 지도가 아닙니다. 지도는 이미 여러분 손에 있습니다. 공격자도 이 지도를 보고 움직이니, 방어자가 모르면 공격자만 길을 아는 셈입니다.
두 가지를 더 기억해 두세요. 첫째, "모든 것은 파일이다"는 유닉스의 설계 철학 — 디스크도 파일(/dev/sda), 난수 발생기도 파일(/dev/urandom), 프로세스 정보도 파일(/proc)입니다. 오늘 cat으로 직접 확인한 그 사실이 리눅스의 힘입니다. 둘째, 나중에 포렌식(디스크 증거 분석)을 배우면 "읽기 전용으로 마운트해 원본을 보호한다"는 절차가 나옵니다. 그 기초가 오늘의 마운트 개념입니다.
리눅스 파일시스템은 처음엔 미로 같지만, 사실은 표지판이 잘 달린 도시입니다. 오늘 이후로 어떤 경로를 마주쳐도 "이건 어느 동네지?"를 추측할 수 있습니다. 길을 아는 사람은 두렵지 않습니다.
전부 체크되면 Step 27 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.