왜 디렉터리 구조를 표준으로 정했는가

Windows에서는 프로그램을 설치하면 보통 C:\Program Files에 실행 파일이, 사용자 문서는 C:\Users\사용자이름에 쌓인다. 이것도 일종의 관례지만, 배포사마다 조금씩 다르게 지켜도 큰 문제가 없다.

리눅스는 사정이 다르다. 레드햇(Red Hat) 계열, 데비안(Debian) 계열, 그 밖의 수많은 배포판(distribution, 커널에 여러 소프트웨어를 묶어 배포하는 하나의 패키지 — 자세한 내용은 03편)이 전 세계에서 독립적으로 만들어진다. 만약 배포판마다 “설정 파일은 여기, 로그는 저기”를 제멋대로 정한다면, 한 배포판에서 익힌 지식이 다른 배포판에서는 쓸모없어진다. 소프트웨어를 만드는 회사 입장에서도 “이 프로그램의 설정 파일은 반드시 /etc 아래 둔다”는 약속이 없으면, 배포판마다 설치 스크립트를 따로 짜야 한다.

이 문제를 풀기 위해 리눅스 재단(Linux Foundation)이 이어받아 관리하는 FHS(Filesystem Hierarchy Standard, 파일시스템 계층 표준)라는 규격이 있다. FHS는 “이런 종류의 파일은 이 디렉터리에 두어야 한다”는 규칙을 정해 둔 문서다. 모든 배포판이 FHS를 100퍼센트 그대로 따르지는 않지만, 핵심 디렉터리(/etc, /var, /usr, /home 등)의 용도는 사실상 모든 주요 배포판이 동일하게 지킨다. 그래서 우분투에서 배운 “설정 파일은 /etc에 있다”는 지식이 CentOS에서도 그대로 통한다.

쉽게 말하면: FHS는 “리눅스라면 이 폴더에는 이런 파일을 넣자”는 전 세계 공통 약속이다.

루트(/)에서 시작하는 트리 구조

리눅스는 Windows처럼 C:, D: 같은 드라이브 문자를 여러 개 쓰지 않는다. 대신 모든 파일과 디렉터리가 루트(root, 뿌리라는 뜻으로 트리 구조의 맨 꼭대기)라는 단 하나의 최상위 디렉터리 아래 하나의 나무처럼 연결된다. 이 최상위 디렉터리는 슬래시(/) 기호 하나로 표기한다.

USB 메모리를 꽂거나 새 하드디스크를 추가해도 Windows처럼 E: 같은 새 드라이브 문자가 생기지 않는다. 대신 그 저장장치는 트리 안의 특정 디렉터리에 “연결”(마운트, mount — 자세한 계산과 명령어는 10편에서 다룬다)되어, 마치 원래부터 그 자리에 있던 폴더처럼 보이게 된다. 예를 들어 USB를 /media/usb라는 디렉터리에 마운트하면, /media/usb 안으로 들어가는 것이 곧 USB 안으로 들어가는 것이다.

이 구조를 그림으로 보면 다음과 같다.

쉽게 말하면: Windows의 여러 드라이브(C:, D:)와 달리, 리눅스는 / 하나의 뿌리에서 모든 것이 가지처럼 뻗어 나간다. 새 저장장치도 새 드라이브 문자가 아니라 이 나무의 한 가지(디렉터리)로 끼워 넣는다.

경로를 표기하는 방법도 두 가지다. /etc/passwd처럼 루트부터 시작해 전체 경로를 다 쓰는 것을 절대경로(absolute path)라 하고, 지금 있는 위치를 기준으로 ../etc/passwd처럼 쓰는 것을 상대경로(relative path)라 한다(자세한 사용법은 07편). 이 편에서는 각 디렉터리를 항상 루트부터 시작하는 절대경로로 표기한다.

FHS가 정한 핵심 디렉터리들

/etc — 시스템 전체의 설정 파일

/etc는 “et cetera(기타 등등)“에서 왔다는 설이 널리 알려져 있지만, 현재 FHS의 공식 정의는 “호스트별로 고유한 시스템 설정 파일을 담는 곳”이다. 여기서 “호스트별로 고유하다”는 말은, 같은 프로그램이라도 이 컴퓨터에서는 A라는 설정으로, 저 컴퓨터에서는 B라는 설정으로 동작하게 만드는 값이 여기 저장된다는 뜻이다.

/etc 안에는 실행 파일이 없다. 오직 텍스트로 된 설정 파일만 있다. 예를 들면 다음과 같다.

/etc의 파일들은 대부분 관리자(root)만 수정할 수 있다. 시스템 전체의 동작 방식을 바꾸는 파일이므로, 일반 사용자가 함부로 고치면 시스템 전체가 오동작할 수 있기 때문이다.

/var — 시간이 지나며 계속 변하는 데이터

/var는 “variable(가변적인)“의 줄임말이다. /etc가 “관리자가 설정해 두면 잘 안 바뀌는 파일”을 담는다면, /var는 정반대로 시스템이 돌아가는 동안 계속 내용이 늘어나거나 바뀌는 파일을 담는다.

시스템에 문제가 생겼을 때 가장 먼저 들여다보는 곳이 /var/log다. 예를 들어 로그인이 계속 실패한 기록, 어떤 서비스가 언제 멈췄는지 같은 정보가 시간 순서대로 여기 쌓인다.

/usr — 배포판이 설치해 준 프로그램들

/usr는 “user”의 줄임말처럼 보이지만, 실제로는 사용자 개인 파일과 무관하다. 역사적으로는 “Unix System Resources”에 가까운 의미로 굳어졌다. 이 안에는 배포판의 패키지 관리자(rpm, dnf, apt 등 — 17편)를 통해 설치된 프로그램들의 실행 파일, 라이브러리, 문서, 아이콘 등이 들어간다.

헷갈리기 쉬운 것이 /bin과 /usr/bin의 관계다. 과거에는 “시스템을 부팅하는 데 반드시 필요한 최소한의 명령어”는 루트 파일시스템 바로 아래 /bin에, “부팅 이후 추가로 쓰는 명령어”는 /usr/bin에 나누어 두었다. 이는 /usr가 별도의 파티션에 있어 아직 마운트되지 않은 상태에서도 시스템이 부팅될 수 있게 하려는 설계였다. 하지만 최근 배포판(RHEL 7 이후, 우분투 최신 버전 등)은 이 구분을 없애고 /bin을 /usr/bin을 가리키는 심볼릭 링크(07편에서 다룬 바로가기 파일)로 통합했다. 시험에서는 “/bin과 /usr/bin이 최신 배포판에서 통합되는 추세”라는 사실 정도를 알아 두면 충분하다.

/home과 /root — 사용자의 개인 공간

/home은 일반 사용자 각자의 개인 파일이 저장되는 디렉터리다. 사용자 ihduser를 새로 만들면 보통 /home/ihduser라는 디렉터리가 그 사용자의 개인 공간(홈 디렉터리, home directory)으로 자동 생성된다. 이 안에 바탕화면 설정, 다운로드한 파일, 개인 설정 파일(.bashrc 등 — 19편)이 쌓인다.

주의할 점은 관리자 계정 root의 홈 디렉터리는 /home 안에 있지 않고 /root라는 별도의 디렉터리라는 점이다. 이렇게 분리해 둔 이유는, 시스템이 정상적으로 부팅되지 않아 /home이 마운트되지 않는 응급 상황에서도, root는 자기 홈 디렉터리(/root)에 접근해 시스템을 복구할 수 있어야 하기 때문이다. /home이 별도 파티션인 경우가 흔한데, 그 파티션이 고장 나도 관리자 작업 공간만은 살아 있게 하려는 설계다.

쉽게 말하면: /home은 일반 손님방들이 모인 층이고, /root는 그 층과 분리된 관리인 전용 방이다.

그 밖에 자주 나오는 디렉터리

가상 파일시스템: /proc과 /dev

지금까지 본 디렉터리들은 모두 디스크 위에 실제로 저장된 파일이다. 그런데 /proc과 /dev는 성격이 완전히 다르다. 이 둘은 가상 파일시스템(virtual filesystem)이다.

쉽게 말하면: /proc과 /dev는 디스크에 저장된 파일이 아니라, 커널이 메모리 위에서 “파일처럼 보이게” 실시간으로 만들어 내는 창구다.

/proc — 커널과 프로세스의 실시간 정보 창구

/proc은 “process(프로세스)“의 줄임말이다. 리눅스 커널(kernel, 하드웨어와 소프트웨어 사이에서 자원을 관리하는 운영체제의 핵심 부분)은 현재 실행 중인 모든 프로세스(program이 실행되어 메모리에 올라간 상태 — 자세한 개념은 13편)의 정보와, CPU·메모리 같은 시스템 자원의 현재 상태를 /proc 아래에 마치 파일처럼 보여 준다.

예를 들어 /proc/cpuinfo를 열어 보면 이 컴퓨터의 CPU 정보가 텍스트로 나온다. 하지만 이 파일은 하드디스크 어딘가에 저장되어 있는 게 아니다. 이 파일을 읽는 순간, 커널이 “지금 이 순간의 CPU 정보”를 그 자리에서 만들어 응답으로 돌려준다. 그래서 /proc/cpuinfo의 파일 크기를 확인해 보면 0바이트로 나오는 경우가 많다 — 디스크에 저장된 실체가 없기 때문이다.

/dev — 하드웨어 장치를 파일처럼 다루는 창구

리눅스의 근본 철학 중 하나가 “모든 것은 파일이다(everything is a file)“이다. 하드디스크, USB, 키보드, 마우스 같은 물리적 장치조차 /dev 아래에 파일처럼 표현해, 프로그램이 일반 파일을 읽고 쓰는 것과 똑같은 방식(cat, > 같은 명령)으로 장치에 접근할 수 있게 한다.

/dev 역시 디스크에 실체 파일이 저장된 게 아니라, 커널이 인식한 장치 목록을 기반으로 실시간으로 채워지는 가상 파일시스템이다(정확히는 devtmpfs라는 방식으로 관리된다). 장치 설정에 대한 더 자세한 내용은 18편에서 다룬다.

직접 해보기

ls로 최상위 구조와 /etc·/var 안을 직접 눈으로 확인하고, /proc이 디스크에 없는 가상 파일시스템이라는 것을 체감한다.

ls /
ls /etc | head
ls /var
cat /proc/cpuinfo | head
cat /proc/meminfo | head

무엇을 보아야 하나: ls /에서 이 편에서 배운 etc·var·usr·home·proc·dev 등이 실제로 나열되는지 본다. /proc/cpuinfo·/proc/meminfo가 마치 텍스트 파일처럼 읽히는지, 그런데도 이 파일이 디스크 어딘가에 저장된 실체가 아니라는 점을 떠올려 본다.

왜 이걸 해보나: “/proc은 디스크에 저장된 설정 파일이다”는 기출 단골 오답이다. 직접 읽어 보면 진짜처럼 보이는 이 파일이 사실 커널이 그 순간 만들어 낸 정보라는 게 와닿는다.

자주 틀리는 점

reference 기출·모의고사 자료를 분석하면, 이 단원은 단순 암기형(“이 디렉터리는 무슨 용도인가”)보다 여러 디렉터리를 동시에 제시하고 그중 틀린 설명을 고르는 형식이 자주 나온다. 특히 다음 세 가지 착각을 노린 오답이 반복된다.

1. /etc와 /var를 바꿔치기한 오답. “/etc에는 로그 파일이 저장된다” 같은 문장은 틀렸다. 로그는 /var/log다. /etc는 “설정”(고정), /var는 “가변 데이터”(계속 변함)라는 대비로 기억해야 헷갈리지 않는다.
2. /root와 /home을 혼동. “관리자(root)의 홈 디렉터리는 /home/root다”는 틀린 설명이다. 관리자 홈은 /home과 별개인 /root다.
3. /proc, /dev를 일반 디렉터리처럼 서술. “/proc/cpuinfo는 디스크에 저장된 설정 파일이다” 같은 문장은 틀렸다. 가상 파일시스템이라는 성격 — 커널이 실시간으로 만들어 내는 정보라는 점 — 을 묻는 문항이 반복된다.

핵심 정리

• 리눅스는 /(루트) 하나의 트리 구조로 모든 파일시스템을 통합하며, 새 저장장치는 드라이브 문자가 아니라 트리의 한 지점에 마운트된다.
• FHS는 배포판이 달라도 /etc(설정)·/var(가변 데이터)·/usr(설치된 프로그램)·/home(사용자 개인 공간)의 역할이 같도록 정한 표준이다.
• 관리자(root)의 홈 디렉터리는 /home이 아니라 별도의 /root이며, 이는 /home 파티션 장애 시에도 복구 작업을 할 수 있게 하려는 설계다.
• /proc과 /dev는 디스크 파일이 아니라 커널이 실시간으로 만들어 내는 가상 파일시스템이다.

마무리 복습

참고 자료

• Filesystem Hierarchy Standard (FHS) 
• The Linux Documentation Project