서버 운영

서버에서만 에러가 나는 문제를 찾는 법

서버에서만 문제가 발생하면 로컬과 운영 환경의 상태를 정확히 비교해서 차이점을 찾는 것이 가장 효율적이다.

2026년 6월 24일·2분 읽기

로컬에서는 아무 문제가 없는데 서버에 배포한 후에만 에러가 나는 경우가 있다. 이런 상황은 처음부터 정답을 맞히려고 하면 오히려 확인 시간이 길어진다. 체계적으로 접근하면 훨씬 빠르게 찾을 수 있다.

가장 먼저 서버의 현재 상태를 기록한다

문제가 발생하고 있는 정확한 시각, 에러가 나타나는 특정 시간대가 있는지를 확인한다.

date
sudo journalctl --since "2 hours ago" -u service-name

특정 시간대에만 문제가 나타난다면 그 시간의 서버 부하나 외부 요청 패턴과 관련이 있을 수 있다.

애플리케이션이 실행되는 포트가 실제로 열려있는지 확인한다.

sudo ss -lntp

예상하는 포트가 LISTEN 상태인지, 다른 프로세스가 같은 포트를 사용하고 있지 않은지를 확인한다.

디스크가 꽉 차있으면 로그 기록이나 파일 쓰기 작업이 실패할 수 있다.

df -h

루트 파일시스템과 애플리케이션이 사용하는 디렉토리의 공간을 확인한다. 용량이 90% 이상이면 즉시 정리가 필요하다.

메모리 부족으로 인한 문제도 자주 발생한다.

free -h
top -b -n 1 | head -20

특정 프로세스가 메모리를 과도하게 사용하고 있지 않은지 확인한다.

서버의 애플리케이션 로그를 본다. 매우 가까운 시간에 에러 메시지가 기록되어 있을 것이다.

sudo tail -100 /var/log/app.log
grep -i error /var/log/app.log | tail -20

에러 메시지를 복사해서 정확히 어떤 부분에서 문제가 발생했는지 파악한다.

애플리케이션 프로세스가 실행 중인지 확인한다.

ps aux | grep app-name
sudo systemctl status app-name

프로세스가 없거나 중지 상태라면 먼저 다시 시작해야 한다.

애플리케이션 실행 사용자의 권한이 필요한 파일에 접근할 수 있는지 확인한다.

ls -la /path/to/config
sudo -u app-user cat /path/to/config

권한이 없으면 파일을 읽지 못해 에러가 발생한다.

로컬에서는 .env 파일이 있지만 서버에서는 환경변수가 다르게 설정되어 있을 수 있다.

env | grep APP_

필수 환경변수가 설정되어 있는지, 값이 올바른지를 확인한다.

로컬과 서버 환경의 로그를 비교한다. 응답 코드, 에러 메시지, 실행 시간 등의 차이를 한 줄로 기록한다. 이것이 원인으로 연결되는 실마리가 된다.

발견한 문제를 한 가지씩 수정한다. 모든 것을 동시에 수정하면 어느 것이 실제 원인인지 알 수 없다.

마지막으로, 이런 확인 순서와 발견한 차이점들을 간단히 기록해두면 다음 서버 문제가 나왔을 때 빠르게 대응할 수 있다.