Chiko IT
DevOps

Linux 서버 관리 명령어 40선 — 프로세스·디스크·네트워크·로그 치트시트

Chiko
11min read

목차

운영 서버에서 자주 쓰는 linux 서버 관리 명령어 40개를 영역별로 묶었다. 신입이 입사 첫 주에 SSH로 접속해서 헤매지 않을 수준만 추렸다. 변경 전/후를 먼저 보면 왜 이걸 알아야 하는지가 명확해진다.

Before / After — 명령어 하나의 차이

같은 상황에서 명령어를 알 때와 모를 때가 어떻게 달라지는지부터 본다. 가짜 상황이 아니라 5년 동안 자주 본 패턴이다.

상황 Before — 모를 때 After — 알 때
CPU가 튀는 프로세스 찾기 모니터링 대시보드 켜고 한참 헤맨다 top -o %CPU 한 줄로 끝난다
디스크 90% 경고 어디서 차는지 막막하다 du -sh /var/* | sort -h로 5초
502 에러 원인 추적 로그 파일 위치부터 물어본다 journalctl -u nginx -n 100
포트 점유 확인 재부팅으로 회피한다 ss -tlnp | grep :80
메모리 누수 의심 "재시작하면 되겠죠?"로 끝낸다 free -h로 swap 상태부터 본다

그러나, 차이는 도구가 아니라 어떤 명령어가 어디에 쓰이는지를 아는가에 있다. 40개를 외울 필요는 없고 영역별로 익혀두면 된다.

왜 굳이 CLI 명령어인가

따라서, 요즘은 Datadog, Grafana, CloudWatch 같은 좋은 도구가 많다. 그런데 5년쯤 운영해보면 알게 되는 패턴이 있다. 정작 장애가 터졌을 때 대시보드는 멈춰 있거나, 메트릭이 1분 지연돼서 도움이 안 되거나, 권한이 없어서 못 본다. 결국 SSH로 들어가 명령어 한 줄로 확인하는 쪽이 빠르다.

그런데, 모니터링 도구가 없는 환경도 여전히 많다. 사내 개발 서버, 외주 받은 서버, 갑자기 책임지게 된 레거시 서버. 이런 곳에서는 첫 30분이 명령어 한 줄로 결정된다.

즉, (자전거 타기처럼 한 번 익혀두면 평생 가는 종류의 기술이라고 본다.)

프로세스 조회 — 누가 CPU를 먹고 있나

가장 자주 쓰는 영역이다. 서버가 느릴 때 첫 번째로 보는 곳.

핵심 명령어

  • top — 실시간 프로세스 모니터링. 실행 후 P로 CPU 정렬, M으로 메모리 정렬
  • top -o %CPU -b -n 1 | head -20 — 스크립트에서 한 번만 찍을 때
  • htop — top의 컬러풀한 친구. 별도 설치 필요 (apt install htop)
  • ps aux — 전체 프로세스 스냅샷
  • ps aux --sort=-%cpu | head -10 — CPU 상위 10개
  • ps -ef --forest — 부모-자식 트리 구조로
  • pgrep -fl nginx — 이름으로 PID 찾기
  • pidof nginx — 더 간단한 버전
  • kill -TERM 1234 — 정상 종료 신호
  • kill -9 1234 — 강제 종료 (마지막 수단)

또한, 손에 익혀두면 좋은 건 top 켜놓고 M 한 번, P 한 번 누르는 흐름이다. htop이 더 보기 좋지만 설치 권한이 없는 서버가 많다. top을 기본기로 두는 편이 안전하다.

kill -9를 너무 빨리 쓰지 마라

신입이 자주 하는 실수다. -9는 프로세스에 종료 신호도 안 주고 즉시 죽인다. DB 커넥션이 끊어진 채로 남고, 파일 핸들이 안 닫히고, 임시 파일이 정리 안 된다. 먼저 kill -TERM(기본값 SIGTERM)을 보내고 30초 정도 기다리는 게 운영 상식이다.

디스크와 메모리 — 용량 차는 곳, 진짜 부족한 곳

/var/log나 /tmp가 차서 서비스가 죽는 경우가 의외로 잦다. 메모리는 리눅스 표시 방식이 헷갈려서 신입이 오해하기 쉽다.

디스크 관련

  • df -h — 마운트별 사용량
  • df -i — inode 사용량 (파일 개수 한계)
  • du -sh /var/* — 1단계 깊이로 폴더 크기
  • du -sh /var/* | sort -h — 정렬해서 크기 순
  • du -h --max-depth=2 /var | sort -h | tail -20 — 2단계까지 큰 폴더 20개
  • ncdu /var — 인터랙티브 디스크 사용량 (별도 설치)
  • find / -size +100M -type f 2>/dev/null — 100MB 이상 파일 검색
  • lsof | grep deleted — 삭제됐는데 파일 핸들이 열려있는 것

마지막의 lsof | grep deleted는 의외로 자주 쓴다. rm으로 로그 파일을 지웠는데 디스크 용량이 그대로면 대부분 이게 원인이다. 프로세스가 파일 핸들을 잡고 있어서 OS가 실제로 못 지운다. 해당 프로세스를 재시작하면 정리된다.

inode도 잘 놓친다. df -h는 여유 있다고 나오는데 파일 생성이 안 될 때, df -i로 보면 inode가 100%인 경우가 있다. 작은 파일이 수백만 개 쌓이면 그렇게 된다.

메모리 관련

  • free -h — 메모리/swap 사용량
  • free -h -s 5 — 5초마다 갱신
  • vmstat 1 — 1초마다 메모리·swap·IO·CPU 한 줄로
  • cat /proc/meminfo — 상세 메모리 정보
  • ps aux --sort=-%mem | head -10 — 메모리 상위 10개
  • dmesg | grep -i "out of memory" — OOM Killer가 죽인 프로세스 기록

그러나, 신입이 가장 자주 하는 오해가 free -h에서 "used"만 보고 "메모리 부족"이라고 판단하는 것이다. 실제로 봐야 하는 컬럼은 "available"이다. 리눅스는 남는 메모리를 디스크 캐시로 쓰기 때문에 "used"는 항상 높게 보인다. "available"이 500MB 이하로 떨어졌을 때 진짜 부족하다.

dmesg | grep -i "out of memory"도 알아두면 좋다. 갑자기 서비스가 죽었다면 OOM Killer가 죽인 건지 확인할 수 있다.

네트워크 — 포트와 연결 상태

그러나, 배포 직후 502가 떴을 때 가장 먼저 보는 영역이다.

핵심 명령어

  • ss -tlnp — 리스닝 중인 TCP 포트와 점유 프로세스
  • ss -tnp — 모든 TCP 연결 상태
  • ss -s — 연결 통계 요약
  • netstat -tlnp — 옛날 명령어, ss가 더 빠르다
  • lsof -i :8080 — 8080 포트 점유 프로세스
  • curl -I https://example.com — HTTP 헤더만 빠르게
  • curl -w "@curl-format.txt" -o /dev/null -s URL — 응답 시간 단계별 측정
  • dig example.com — DNS 조회
  • traceroute example.com — 네트워크 경로 추적

netstat은 오래된 명령어다. 요즘은 ss가 표준이다(iproute2 패키지). 다만 회사 서버가 CentOS 6 같은 레거시면 netstat만 깔려있는 경우가 있어서 둘 다 알아두는 편이 안전하다.

curl의 시간 분해

curl -w 옵션은 잘 안 알려져 있다. curl-format.txt에 다음을 넣으면 응답 시간을 단계별로 보여준다.

     time_namelookup:  %{time_namelookup}s\n
        time_connect:  %{time_connect}s\n
     time_appconnect:  %{time_appconnect}s\n
    time_pretransfer:  %{time_pretransfer}s\n
  time_starttransfer:  %{time_starttransfer}s\n
          time_total:  %{time_total}s\n

그래서, DNS 조회가 느린지, TLS 핸드셰이크가 느린지, 서버 응답이 느린지가 분리된다. 외부 API 응답이 들쭉날쭉할 때 한 번 돌려보면 원인 영역이 잡힌다. (curl 공식 문서에 더 많은 변수가 있다.)

로그 추적 — 어디를 어떻게 볼 것인가

그래서, systemd 환경에서는 거의 journalctl로 통일됐다. 애플리케이션 로그는 여전히 파일이다.

핵심 명령어

  • journalctl -u nginx -n 100 — nginx 서비스 최근 100줄
  • journalctl -u nginx -f — 실시간 팔로우
  • journalctl --since "10 minutes ago" — 10분 전부터
  • journalctl -p err — error 이상 레벨만
  • tail -f /var/log/syslog — 전통적인 방식
  • tail -n 1000 /var/log/app.log | grep ERROR — 최근 1000줄에서 ERROR
  • less +F /var/log/app.log — less의 follow 모드
  • grep -r "exception" /var/log/ 2>/dev/null — 디렉토리 전체 검색

less +F는 덜 알려진 편이다. tail -f처럼 흘러가는 로그를 보다가 Ctrl+C 누르면 less 검색 모드로 빠진다. "방금 그게 뭐였지?" 싶을 때 쓰면 편하다.

따라서, journalctl은 옵션이 많아서 처음엔 외우기 어렵다. -u 서비스명, -n 줄수, -f, --since 4개만 익히면 90%는 커버된다. 나머지는 systemd journalctl 공식 문서를 찾아보면 된다.

자주 같이 쓰는 조합과 운영 서버 주의사항

명령어를 따로 외우려고 하면 어렵다. 실제로 손에 익는 건 조합이다. 대표적으로 다음 정도가 자주 나온다.

# CPU 상위 5개
ps aux --sort=-%cpu | head -6

# 메모리 누수 의심 추적 (5초마다 갱신)
watch -n 5 'ps aux --sort=-%mem | head -5'

# 특정 포트 점유 프로세스 죽이기
kill $(lsof -t -i:8080)

# 디스크 90% 넘으면 알림 메일
df -h | awk '$5+0 > 90 {print $0}' | mail -s "Disk Alert" admin@example.com

watch 명령어는 알아두면 정말 자주 쓴다. 어떤 명령어든 앞에 watch -n 5만 붙이면 5초마다 자동으로 다시 실행한다. top을 켜놓는 것보다 더 좁은 범위만 보고 싶을 때 좋다.

운영 서버에서 절대 하지 말 것

명령어를 알게 되면 자신감이 붙는다. 그 자신감이 사고로 이어지는 패턴이 있다.

rm -rf는 두 번 보고 친다. 특히 변수가 들어가는 스크립트(rm -rf $VAR/*)가 위험하다. $VAR가 비어있으면 rm -rf /*가 된다. 변수 사용 시 항상 ${VAR:?error} 같은 가드를 넣는 습관이 필요하다.

find -exec도 위험하다. find / -name "*.log" -exec rm {} \;는 의도와 다르게 시스템 로그까지 지울 수 있다. 먼저 -exec 대신 -print로 결과를 확인한 다음 실행한다.

결국, dd 명령어. input/output을 헷갈리면 디스크를 통째로 날린다. if=(입력)과 of=(출력)를 절대 헷갈리지 마라.

실제로, chmod 777은 해결책이 아니다. 권한 문제가 생기면 무조건 777로 던지는 신입을 자주 본다. 보안 사고의 출발점이다. 보통 chown이나 그룹 권한 조정으로 풀린다.

또한, rm 대신 mv를 쓰는 습관. 운영 서버에서 뭘 지워야 한다면 일단 /tmp/trash/ 같은 곳으로 옮긴다. 며칠 두고 문제 없으면 그때 진짜 지운다. 이게 5년차의 보수성이다.

외울 필요 없다, 어디 있는지만 알면 된다

특히, 40개를 한 번에 외우려고 하면 실패한다. 영역별로 어떤 명령어가 어디 쓰이는지만 머리에 두면 충분하다. 막상 필요할 때는 tldr이나 cheat 같은 도구가 검색을 도와준다.

apt install tldr
tldr journalctl   # 핵심 사용 예시 5~6개만 보여준다

man 페이지는 너무 길어서 실전에선 잘 안 본다. tldr이 훨씬 실용적이다 (tldr 공식 사이트).

당장 해보면 좋을 것 세 가지:

  1. apt install htop tldr ncdu — 세 가지만 깔아둬도 명령어 검색 시간이 줄어든다
  2. 영역별 대표 명령어 1개씩 손에 익히기 — top, df -h, free -h, ss -tlnp, journalctl -u
  3. 자기 회사 서버에서 df -i와 dmesg | grep -i oom을 한 번씩 돌려보기 — 평소 안 보던 상태가 보인다

개인적으로는 신입에게 40개를 다 외우라고 시키는 것보다, 영역별 대표 명령어 5~6개만 손에 익히고 나머지는 tldr로 검색하는 방향이 훨씬 빨리 는다고 본다.

관련 글

More posts