리눅스의 디렉토리 구조와 역할

리눅스의 각 디렉토리 구조는 커널버전과 제품군에 따라 조금씩 다르지만 기본적인 맥락은 거의 비슷하다. 개인적으로 장문의 글로 장황하게 설명하는 걸 싫어하니 아래 트리와 주석을 보도록 하자.

~           

├── bin/    

├── lib/    

├── include/

├── src/    

├── etc/    

├── var/    

└── tmp/    

• ~
• 유저의 홈 디렉토리
• 유저 디렉토리의 모든 시작지점
• bin/
• 실행 바이너리 및 쉘 스크립트들이 있음
• binary file, .sh, .java 등
• lib/
• 라이브러리 파일들이 있음
• .a, .so, .jar 등
• include/
• 헤더 및 전처리 파일들이 있음
• 주로 lib/에서 필요한 헤더들이 있음
• .h, .hh, .hpp, .py 등
• src/
• 작업중이거나 빌드 전의 소스코드들이 있음
• etc/ 
• 설정값이나 정보와 같이 고정적인 값들을 저장한 파일들이 있음
• 주로 바이너리 이름 뒤에 확장자를 붙여 사용함
• .conf, .nfo, .info 등
• var/ 
• 로그나 상태값과 같은 수시로 변하는 의미있는 정보들을 저장한 파일들이 있음
• 주로 바이너리 이름을 가지는 디렉토리 내에 저장됨
• .log, .stat, .queue, .pool 등
• tmp/ 
• 작업 중 임시로 사용되거나 수시로 생성/삭제되는 파일들이 있음
• 주로 바이너리 이름을 가지는 디렉토리 내에 저장됨
• .dummy, .buffer, 작업중인 파일 등

물론 모든 리눅스 시스템과 프로젝트들이 위 규칙을 따르는 건 아니지만 적어도 몇십년동안 많은 개발자와 관리자들에게 사랑을 받아온 구조에는 그만한 이유가 있다. 필자 또한 처음에는 이런저런 구조를 도입해보려 했었지만 결국 종착역은 위 구조였다. 그 이유는 아래와 같다.

• 한 솔루션 내 여러 프로젝트 사이에서 일어나는 사이드 이펙트를 빠르고 직접적(?)으로 파악할 수 있음(이 얘기에 대해서는 추후 리눅스의 이상적인 솔루션(프로젝트) 구조에서 다루도록 하겠음)
• 프로젝트의 유지보수 및 패치작업이 수월함
• 관리자와 개발자 간 의사소통이 원활해짐

일단 이번 포스트는 이쯤에서 마무리 지으려고 한다. 쓰다보면 끝이 없을 것 같다.

이번 포스트의 핵심은 '몇십년동안 사랑을 받아온 구조에는 그만한 이유가 있다'