작은 이상 신호는 로그에 먼저 보인다

로그부터 읽는 습관

서버가 느려지거나 갑자기 요청이 실패하기 시작하면 먼저 로그를 본다. 화면의 에러 메시지는 증상일 뿐 원인이 아니기 때문이다.

Systemd 저널은 가장 가까운 현장이다.

# 최근 80줄 로그 확인
sudo journalctl -n 80

# 실시간 모니터링
sudo journalctl -f

# 특정 시간대 로그
sudo journalctl --since "2026-06-28 14:00:00" --until "2026-06-28 15:00:00"

디스크 확인을 먼저 한다

의외로 많은 문제가 디스크 부족에서 시작된다.

df -h

백분율 80% 이상이면 이미 위험하다. 로그나 캐시가 차지하는 공간을 확인하고, 필요하면 즉시 정리한다. 디스크가 꽉 차면 새로운 로그도 못 쓰고, 임시 파일도 생성할 수 없다.

권한과 프로세스 상태

# 포트별 프로세스 확인
sudo ss -lntp

# 메모리 사용 현황
free -h

# CPU 사용률
top -b -n 1 | head -15

예상과 다른 프로세스가 포트를 점유하고 있거나, 메모리가 비정상적으로 증가했다면 그것이 시작점이다.

응답 코드 추적

API 서버라면 상태 코드 분포를 본다.

# 마지막 1000개 요청의 상태 코드 집계 (Nginx 예)
sudo tail -1000 /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -rn

5xx 에러가 갑자기 늘었다면 서버 상태를 재확인해야 한다. 4xx가 비정상적으로 많다면 클라이언트 요청 형식을 점검한다.

작은 확인이 쌓인다

이렇게 작은 확인들을 차곡차곡 기록하면 원인 후보가 자연스럽게 줄어든다.

• 시간대: 언제부터 이상했는가
• 범위: 모든 요청인가, 특정 사용자만인가
• 패턴: 반복되는가, 일회성인가

이 정도만 정리해도 다음에 비슷한 상황이 오면 훨씬 빠르게 대응할 수 있다.