신입 개발자 시절, 리눅스 서버에 처음 접속했을 때 느꼈던 막막함이 아직도 생생합니다. 분명 ls나 cp 같은 명령어는 /bin에 있는데, vim이나 gcc 같은 건 /usr/bin에 있더군요. 게다가 관리자 명령어는 /sbin과 /usr/sbin으로 또 나뉘어 있었습니다. 도대체 기준이 뭘까요? 당시 사수에게 물어봤지만 "시스템 부팅에 필수적인 건 /bin, 아닌 건 /usr/bin이야"라는 교과서적인 답변만 돌아왔습니다. 하지만 솔직히 말해, 요즘 같은 고성능 서버 환경에서 이 구분이 정말 유효한지 의문이 들 때가 한두 번이 아니었습니다. 오늘은 제가 10년 넘게 개발자로 일하며 깨달은, 이 복잡한 디렉터리 구조 뒤에 숨겨진 꽤나 인간적이고 흥미로운 역사 이야기를 들려드리려 합니다.
이 모든 혼란의 시작은 무려 1971년으로 거슬러 올라갑니다. 유닉스(Unix)의 아버지라 불리는 켄 톰슨(Ken Thompson)과 데니스 리치(Dennis Ritchie)가 PDP-11이라는 컴퓨터를 사용하던 시절이었죠. 당시 그들이 사용하던 저장 장치는 RK05라는 디스크 팩이었는데, 용량이 고작 1.5메가바이트였습니다. 믿겨지시나요? 요즘 우리가 찍는 사진 한 장보다도 작은 용량입니다. 운영체제가 점점 발전하면서 덩치가 커지자, 결국 루트 파일시스템이 들어있는 첫 번째 디스크 팩의 용량이 꽉 차버리는 사태가 발생했습니다.
그래서 그들은 두 번째 디스크 팩을 추가했습니다. 이 두 번째 디스크에는 사용자들의 홈 디렉터리가 있었기에 마운트 지점을 /usr라고 이름 지었습니다. 그리고 첫 번째 디스크에 더 이상 공간이 없으니, /bin, /lib 같은 운영체제 디렉터리들을 /usr 아래에 복제해서 사용하기 시작했습니다. 즉, /bin에 자리가 없어서 /usr/bin에 파일을 저장하게 된 것입니다. 아주 단순하고 물리적인 이유였죠. 나중에 세 번째 디스크가 생겼을 때 비로소 사용자 데이터를 /home으로 옮겼지만, 이미 운영체제 파일들은 두 개의 디스크에 쪼개져 저장되고 있었습니다.
여기서 아주 중요한 기술적 제약이 생겼습니다. 시스템을 부팅하려면 두 번째 디스크를 /usr에 마운트해야 하는데, 정작 마운트 명령을 수행하는 mount 실행 파일이 두 번째 디스크(/usr/bin)에 있으면 안 되겠죠? 이것이 바로 전형적인 '닭이 먼저냐 달걀이 먼저냐'의 문제입니다. 그래서 그들은 "시스템 부팅과 디스크 마운트에 필요한 최소한의 명령어는 첫 번째 디스크인 /bin에 남겨두고, 나머지는 /usr/bin으로 보낸다"라는 규칙을 세웠습니다. 이것이 우리가 지금껏 금과옥조처럼 외우고 있는 디렉터리 분할의 진짜 기원입니다.
하지만 30년이 훌쩍 지난 지금, 이 규칙은 사실상 기술적인 의미를 상실했습니다. 현대의 리눅스 시스템은 부팅 과정에서 initrd나 initramfs 같은 임시 파일시스템을 사용하여 초기 구동 문제를 우아하게 해결합니다. 또한 버클리 유닉스 시절 도입된 공유 라이브러리(Shared Library) 개념 때문에, /lib와 /usr/bin은 서로 긴밀하게 의존하게 되어 독립적인 업데이트조차 불가능해졌습니다. 하드디스크 용량이 테라바이트 단위를 넘나드는 지금, 1.5메가바이트 디스크 때문에 생긴 파티션 구분을 유지하는 건 일종의 기술적 관성입니다.
재미있는 점은, 한번 정해진 이 관습이 시간이 지나며 더 복잡한 관료주의적 규칙들을 낳았다는 것입니다. 처음에는 단순히 디스크 용량 문제였던 것이, 나중에는 "/는 AT&T 원본 파일, /usr는 배포판 파일, /usr/local은 로컬 설치 파일"이라는 식의 그럴싸한 명분들이 덧붙여졌습니다. 심지어 /usr/local도 모자라 /opt가 등장하기도 했죠. 롭 랜들리(Rob Landley) 같은 개발자는 이를 두고 "1970년대의 구현 세부 사항이 수십 년 동안 이유도 묻지 않고 계승된 것"이라며 날카롭게 비판하기도 했습니다.
결국 우리가 배우는 기술의 많은 부분은, 당대 엔지니어들이 생존을 위해 선택한 임시변통의 결과물일 때가 많습니다. 지금 여러분이 마주하는 레거시 코드나 이해할 수 없는 아키텍처도 어쩌면 1.5메가바이트 디스크 같은 절박한 사연이 있었을지 모릅니다. 최근의 리눅스 배포판들은 이러한 역사적 부채를 청산하기 위해 /bin을 /usr/bin의 심볼릭 링크(Symbolic Link)로 통합하는 'Usr Merge' 작업을 진행하기도 합니다. 기술은 맹목적인 암기가 아니라, '왜'라는 질문을 던지며 그 맥락을 이해할 때 비로소 내 것이 됩니다. 오늘 커피 한 잔 마시며 여러분의 프로젝트 속에 숨어 있는 1.5메가바이트의 제약은 무엇인지 한번 찾아보는 건 어떨까요?
