리눅스 /usr 디렉터리는 User의 약자가 아니다?

50년 전 '하드웨어 사고'가 만든 나비효과

리눅스나 유닉스 시스템을 쓰다 보면 한 번쯤 이런 생각 해보신 적 있을 겁니다.

"도대체 /usr은 뭐의 약자일까?"

딱 봐도 User에서 e만 뺀 느낌입니다. 근데 그럴 거면 그냥 /user라고 쓰지, 왜 굳이 /usr일까요?

  • 타자 치기 귀찮아서?
  • 글자 수 제한이라도 있었나?
  • 그런데 /boot, /home, /proc 같은 네 글자 디렉터리는 또 잘만 존재합니다.

만약 진짜로 “사용자(user)”라면 그냥 /user라고 썼겠죠. 굳이 애매하게 /usr이라고 한 데에는, 우리가 모르는 역사가 하나 숨겨져 있습니다.

오늘은 이 /usr 디렉터리에 얽힌, 개발자라면 한 번쯤 “아… 그랬겠네” 하고 무릎을 탁 칠 만한 50년 전의 ‘웃픈’ 하드웨어 이야기를 풀어봅니다.

image

1. 결론부터: 지금의 /usr는 “User”가 아니다

Commandbox 광고

현재 리눅스 파일 시스템 표준(FHS, Filesystem Hierarchy Standard)에서 /usr는 이렇게 정의됩니다.

시스템 전역에서 쓰이는, (대체로) 읽기 전용의 프로그램·라이브러리·공유 데이터가 들어가는 영역

그래서 우리가 흔히 보는 구조가 이렇죠.

  • /usr/bin – 대부분의 사용자용 실행 파일
  • /usr/sbin – 시스템 관리용 실행 파일
  • /usr/lib* – 그 실행 파일들이 사용하는 라이브러리
  • /usr/share – 매뉴얼, 아이콘, 로케일 등 아키텍처 독립 데이터

어디를 봐도 “사용자의 개인 파일”과는 거리가 있습니다. 홈 디렉터리(~/...)나 문서, 사진 같은 건 전부 /home 아래에 있죠.

그래서 오늘날의 관점에서 /usr를 한 줄로 정의하자면:

/usr = “User가 아니라, OS와 앱의 ‘공용 시스템 리소스 창고”

입니다.

그럼 질문이 하나 남습니다.

“그래도 애초에 usr는 user 줄임말 아니었냐?”

여기서부터가 재미있는 부분입니다. 태생은 ‘User’가 맞았습니다. 다만 그 후 50년 동안 쓰임새가 완전히 뒤집힌 거죠.

2. 초창기 유닉스: /usr/계정명이 홈 디렉터리였다

시간을 1970년대 초반, 초기 유닉스 시절로 돌려보겠습니다.

당시 유닉스 시스템에서:

  • 사용자의 홈 디렉터리는 지금처럼 /home/alice가 아니라
  • /usr/alice 같은 형태로 /usr 아래에 직접 놓여 있었습니다.

즉, 그때의 /usr는 정말로:

“user 관련 것들이 들어가는 디렉터리”

라는 이름 그대로의 역할을 하고 있었던 셈입니다.

당시 컴퓨터는 PDP-11 같은 장비였고, 디스크는 오늘날 기준으로는 믿을 수 없을 만큼 작았습니다. “용량 몇십 KB/MB 가지고 난리 치던 시절”이었으니까요.

  • 루트 디스크(/) – OS의 핵심 파일들만 겨우 들어가는 좁은 공간
  • 두 번째 디스크(/usr) – 상대적으로 넉넉한 공간, 여기에 사용자 홈 디렉터리를 배치

이 구조 자체는 합리적이었습니다. 문제는… 유닉스(와 개발자들의 욕심)가 너무 빨리 커졌다는 거죠.

3. “디스크가 꽉 찼다” → 시스템 파일을 /usr로 쫓아내다

Commandbox 광고

유닉스는 계속 커지고, 새로운 명령과 기능들이 추가됩니다. 문제는 루트 디스크(/) 용량은 그대로라는 것이었죠.

결국 어느 날 이런 상황이 옵니다.

“더 이상 /에 프로그램을 넣을 곳이 없다…”

그러자 개발자들은 현실적인 선택을 합니다.

“어차피 두 번째 디스크(/usr)는 널널한데, 부팅에 꼭 필요하지 않은 프로그램들은 그냥 거기로 옮기자.”

그렇게 해서 처음엔 “user 홈 디렉터리”였던 /usr에, 조금씩 프로그램·라이브러리·데이터들이 슬금슬금 밀려 들어오기 시작합니다.

그 결과가 우리가 지금 알고 있는 이 구조입니다.

  • /bin – 부팅에 꼭 필요한 “최소한의” 명령어들 (원래 루트 디스크)
  • /usr/bin – 나머지 일반적인 명령어들 (두 번째 디스크로 피신한 친구들)
  • /lib vs /usr/lib도 비슷한 논리

즉,

원래는 사용자 집이었던 /usr에 “공간이 남는다는 이유 하나로” 시스템 파일이 이삿짐처럼 들어오기 시작한 것

입니다. 말 그대로 “하드 디스크 용량 부족이 만든 편법”이죠.

그 후로 유닉스가 계속 발전하면서:

  • 사용자 홈 디렉터리는 /home 같은 더 직관적인 디렉터리로 이동했고
  • /usr는 이제 완전히 “공유 프로그램/라이브러리 영역”으로 정착하게 됩니다.

이쯤 되면 상황이 꽤 웃깁니다.

  • 이름: usr (user)
  • 실제 내용: 시스템·앱 전용 파일들

주인은 이사 나갔는데, 그 집에 시스템 파일만 가득한 꼴이 되어버린 거죠.

4. “Unix System Resources”? 그건 나중에 만든 말이다

이 모순적인 상황이 오래 지속되다 보니, 후대의 누군가가 이렇게 말하기 시작합니다.

“그래, 이제 /usr는 Unix System Resources의 약자라고 하자.”

어디 문서에서 “/usr = Unix System Resources”라고 쓰여 있는 걸 보신 적 있을 겁니다. 하지만 중요한 포인트가 하나 있습니다.

이건 나중에 끼워 맞춘(backronym) 해석이지, 초기 유닉스 설계 당시의 공식 의미가 아닙니다.

초기 유닉스 문서와 증언들을 보면:

  • /usr는 원래 user의 줄임말
  • /usr/계정명 형태로 홈 디렉터리를 두기 위한 공간
  • 이후 디스크 용량 문제 때문에 “user 관련 모든 것” → “user가 쓰는 프로그램까지” → “프로그램·라이브러리 전반”으로 의미가 확장·변질

이라는 흐름이 더 잘 맞습니다.

그런데 시간이 흐르면서 사람들은 현실을 이렇게 정리해 버린 겁니다.

“어차피 지금은 시스템 리소스 넣는 곳이니까 Unix System Resources라고 부르면 되지 뭐.”

이런 걸 전문 용어로 백크로님(backronym)이라고 부릅니다. 원래 줄임말이 있고, 그 의미를 나중에 “역으로” 제정하는 방식이죠.

개발자 세계에서 꽤 자주 보는 풍경입니다.

  • 임시로 때운 이름·구조가
  • 문서에 적히고
  • 표준이 되고
  • 나중에는 “애초에 그런 의도였던 것처럼” 설명되는…

5. 50년 전의 구조가 지금까지: Usr Merge 이야기

여기까지 들으면 이런 생각이 들 수 있습니다.

“아니, 디스크도 넉넉한데 이제 와서 /bin, /usr/bin 따로 둘 필요 있나?”

실제로 요즘 리눅스 배포판(Ubuntu, Fedora, Debian 등)은 이 역사적 유산을 정리하는 중입니다. 이 작업이 바로 /usr merge(UsrMerge)입니다.

최근 배포판에서 다음을 한 번 실행해 보세요.

$ ls -l /
lrwxrwxrwx 1 root root    7  ...  bin  -> usr/bin
lrwxrwxrwx 1 root root    7  ...  sbin -> usr/sbin
lrwxrwxrwx 1 root root    7  ...  lib  -> usr/lib

대부분 이렇게 되어 있을 겁니다.

  • /bin은 실제 디렉터리가 아니라 /usr/bin을 가리키는 심볼릭 링크
  • /sbin, /lib도 마찬가지

즉, 오늘날의 실질적인 구조는:

“프로그램, 라이브러리 대부분은 전부 /usr 아래에 있다”

는 형태로 되돌아가는 중입니다.([wiki.debian.org][6])

왜 이렇게 합칠까요? 이유는 여러 가지가 있지만, 대표적으로:

  • 패키지 관리/포팅이 단순해짐
  • 컨테이너/이미지 기반 배포에서 /usr를 하나의 “시스템 이미지”처럼 다루기 쉬움([freedesktop.org][7])
  • 옛날 하드웨어 제약 때문에 나눴던 구조를 더 이상 유지할 이유가 없음

재미있는 건, 이 모든 출발점이:

“1970년대, 디스크가 너무 작아서 프로그램을 /usr로 몰아넣었던 그 선택”

이었다는 점입니다. 정말로 “임시방편만큼 영원한 것은 없다”는 말이 잘 어울리는 사례입니다.

6. 그렇다면 오늘날 우리는 /usr를 어떻게 이해하면 좋을까?

실제 리눅스 시스템을 다룰 때, /usr에 대해 이렇게 생각하면 편합니다.

“이 시스템에서 공용으로 사용하는 프로그램과 라이브러리, 공유 데이터가 들어있는 영역”

반대로:

  • 개인 파일 / 설정 → /home/내계정
  • 자주 변경되는 데이터 (로그, 캐시, DB 등) → /var
  • 배포판 패키지가 아닌, 별도로 설치한 앱 → 보통 /opt 또는 /usr/local 아래([Ask Ubuntu][1])

즉:

  • /usr는 OS와 앱의 세계
  • /home은 사용자 개인의 세계

라고 나눠서 보면 헷갈릴 일이 많이 줄어듭니다.

마치며: 디렉터리 이름 하나에 담긴 개발자의 타협

/usr라는 디렉터리 안에는:

  • “용량 부족에 시달리던 초창기 유닉스 개발자들”의 현실적인 고민
  • “일단 이렇게 해 두고 나중에 정리하자”라는 익숙한 임시방편
  • 그리고 수십 년 후, 이를 둘러싼 표준화와 정리 작업(UsrMerge)

까지, 꽤 긴 서사가 담겨 있습니다.

단순히:

  • “/usr = Unix System Resources”
  • “/usr는 사용자 디렉터리가 아니다”

라고 외우는 것보다, 이런 배경을 알고 나면 터미널에서 /usr/bin, /usr/lib를 보는 느낌이 조금 달라집니다.

“아, 저건 50년 전에 누가 디스크 꽉 차서 어쩔 수 없이 옮겨 놓은 그 결과물이구나.”

검은 화면 속 디렉터리 하나에도, 그 시대 하드웨어의 한계와 개발자들의 타협이 고스란히 남아 있다는 사실이 꽤 재미있지 않나요?