장애가 나면 가장 먼저 로그를 봐야 합니다. 그런데 서버에 처음 들어간 신입이 로그 파일을 찾으려면 어디를 봐야 할까요? Nginx 설정은 어디 있고, 애플리케이션 데이터는 어느 디렉토리에 쌓이는지 — 이걸 모르면 서버 안에서 길을 잃습니다. Linux는 어디에 무엇을 두는지 FHS(Filesystem Hierarchy Standard)라는 규칙으로 정해두었고, 모든 배포판이 이 규칙을 따릅니다. /etc에는 설정, /var/log에는 로그, /home에는 사용자 데이터 — 이 구조를 알면 낯선 서버에 들어가도 5분 안에 원하는 파일을 찾을 수 있습니다.

확대

Linux의 모든 파일은 / (루트)에서 시작하는 하나의 트리 구조에 위치합니다. Windows의 C:, D:\ 같은 드라이브 구분 없이 단일 계층입니다. Filesystem Hierarchy Standard(FHS)가 어디에 무엇을 두는지 규칙을 정합니다.

# 루트 디렉토리 구조 한눈에 보기
ls /

bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

실무에서 자주 가는 경로들입니다.

# Nginx 설정 파일 빠르게 찾기
ls /etc/nginx/

conf.d  nginx.conf  sites-available  sites-enabled

확대

쉘 스크립트를 처음 작성할 때 흔히 저지르는 실수 중 하나가 상대 경로를 그대로 쓰는 겁니다. 터미널에서 직접 실행할 때는 잘 되다가, cron으로 자동 실행하거나 다른 디렉토리에서 스크립트를 호출하면 갑자기 "파일을 찾을 수 없다"는 오류가 납니다. 실행 위치가 달라지면 상대 경로의 기준점도 달라지기 때문입니다. 언제 절대 경로를 써야 하고 언제 상대 경로가 편한지 — 이 구분을 머릿속에 새겨두면 이런 실수를 예방할 수 있습니다.

절대 경로 (Absolute Path): 루트(/)부터 시작. 현재 위치와 무관하게 항상 같은 파일을 가리킵니다.

cd /etc/nginx          # 어디서 실행해도 /etc/nginx 로 이동
cat /etc/hosts         # 호스트 파일 읽기

상대 경로 (Relative Path): 현재 위치(pwd)를 기준으로 합니다.

# 현재 위치가 /home/ubuntu 라고 가정
cd lab/filesystem      # /home/ubuntu/lab/filesystem 으로 이동
cd ..                  # 한 단계 위 → /home/ubuntu/lab
cd ../../etc           # 두 단계 위 후 etc → /etc
cd ~                   # 홈 디렉토리로 이동 (어디서든)
cd -                   # 이전 디렉토리로 토글

스크립트나 cron 작업에서는 상대 경로 대신 절대 경로를 사용하세요. 실행 위치가 달라도 항상 같은 파일을 가리킵니다.

확대

ls -la를 처음 보면 drwxr-xr-x 2 root root 4096 같은 문자열이 나열되고 무슨 뜻인지 알기 어렵습니다. 하지만 이 한 줄에는 파일 타입, 읽기/쓰기/실행 권한, 소유자, 크기, 수정 시각이 모두 들어 있습니다. Permission denied 오류가 나거나 "왜 이 파일이 실행이 안 되지?" 싶을 때 — 해답이 이 출력 안에 있습니다.

ls -la /etc/nginx/

total 24
drwxr-xr-x  6 root root 4096 Sep 15 10:23 .
drwxr-xr-x 97 root root 4096 Sep 15 10:23 ..
drwxr-xr-x  2 root root 4096 Sep 15 10:23 conf.d
-rw-r--r--  1 root root 1490 Sep 15 10:23 nginx.conf
lrwxrwxrwx  1 root root   34 Sep 15 10:23 sites-enabled -> /etc/nginx/sites-available

첫 글자가 파일 타입입니다: d=디렉토리, -=일반 파일, l=심볼릭 링크. 그 뒤 9자리(rwxr-xr-x)는 소유자/그룹/그 외 순서로 읽기(r=4)·쓰기(w=2)·실행(x=1) 권한입니다.

실무에서 자주 쓰는 ls 조합입니다.

ls -lath /var/log/nginx/    # 최신 파일이 맨 위, 사람이 읽기 좋은 용량
ls -lS /var/log/ | head -10 # 가장 큰 파일 순서로 정렬
ls /etc/*.conf              # 특정 확장자만 보기
du -sh /var/log/nginx/      # 디렉토리 전체 용량 요약

앞에서 cd ../..로 상대 경로를 한 토막씩 계산했습니다. 그 계산은 경로가 평범한 디렉토리로만 이어질 때 정확합니다. 그런데 경로 중간에 심볼릭 링크가 끼면 ..가 '보이는 경로'를 따라가는지 '실제 디렉토리'를 따라가는지가 갈리고, 이 차이가 배포·정리 스크립트에서 엉뚱한 곳을 건드리는 사고로 이어집니다.

• 셸은 경로를 두 가지로 봅니다. 하나는 논리 경로(logical) — 사용자가 cd로 밟아온 문자열 그대로. 다른 하나는 물리 경로(physical) — 심볼릭 링크를 전부 푼 실제 디렉토리. 기본 cd와 pwd는 논리 경로를 유지합니다.
• 그래서 심볼릭 링크 디렉토리로 들어간 뒤 cd ..는 물리 부모가 아니라 논리 부모로 갑니다. 예를 들어 /var/www/current가 /releases/v2를 가리킬 때, cd /var/www/current 다음의 cd ..는 /releases가 아니라 /var/www로 이동합니다. 눈에 보이던 경로(/var/www/current)의 부모로 돌아가는 것입니다.
• 실제 위치를 알려면 pwd -P, 물리 기준으로 올라가려면 cd -P .. 를 씁니다. 스크립트에서 진짜 경로가 필요하면 realpath나 readlink -f로 링크를 먼저 풀어야 합니다.

ln -s /releases/v2 /var/www/current
cd /var/www/current
pwd        # /var/www/current   (논리 경로 — 밟아온 문자열)
pwd -P     # /releases/v2        (물리 경로 — 링크를 푼 실제 위치)
cd ..
pwd        # /var/www            (논리 부모 — /releases 아님!)

• 왜 위험한가: 무중단 배포는 current를 심볼릭 링크로 두고 새 릴리스로 갈아끼우는 구조가 표준입니다. 이때 cd $APP/current; cd ..; rm -rf 오래된것 같은 상대 정리 스크립트는 논리 부모(공유 디렉토리)에서 동작해, 지우려던 릴리스가 아니라 엉뚱한 상위를 건드릴 수 있습니다. 상대 경로와 심볼릭 링크가 만나면 반드시 절대 경로로 못박거나 물리 경로를 먼저 풀어야 안전합니다.

정리하면, "..는 한 단계 위"라는 규칙은 참이지만 그 '위'가 논리 경로 기준이라는 단서가 붙습니다. 심볼릭 링크가 보이면 pwd와 pwd -P를 함께 확인하는 습관이 사고를 막습니다.