← 전체 글로 돌아가기

서버 운영

서버 에러 메시지를 읽는 순서

서버에서만 에러가 난다면 포트, 로그, 권한을 이 순서대로 확인해야 한다. 추측하지 말고 로그를 본다.

서버에 배포했는데 "연결할 수 없음" 에러만 나고 정확한 원인을 알 수 없었다. 일관된 순서로 디버깅해야 한다는 걸 깨달았다.

첫 번째: 프로세스와 포트 확인

서버가 제대로 켜졌는지, 올바른 포트에서 리스닝 중인지 확인:

sudo ss -lntp | grep 3000

앱이 포트 3000에서 리스닝 중이면 라인이 하나 나온다. 없으면 프로세스가 시작되지 않았다는 뜻이다.

두 번째: 시스템 로그 확인

프로세스가 시작되지 않았다면 왜 실패했는지 로그에 있을 것이다:

sudo journalctl -n 80

최근 80줄을 보면 "Permission denied", "Out of memory", "Address already in use" 같은 에러가 있을 것이다.

세 번째: 앱 로그 직접 보기

sudo로 실행해서 즉시 나오는 로그를 보자:

cd /app
sudo npm start  # 또는 node app.js

백그라운드에서 실행하는 것보다 포그라운드에서 직접 실행하면 에러 메시지가 즉시 보인다.

네 번째: 디스크 상태

빌드나 시작 과정에서 파일을 쓸 때 디스크가 가득 찼을 수 있다:

df -h

사용률이 90% 이상이면 로그, 임시 파일, 이전 빌드 파일 등을 정리하자.

다섯 번째: 권한 확인

앱이 필요한 파일이나 디렉토리에 접근할 권한이 있는지:

ls -la /app
ls -la /var/log

만약 node_modules 디렉토리가 root 소유라면 일반 사용자로 실행하는 앱이 쓰기 권한이 없을 수 있다.

환경 변수 확인

환경 변수가 제대로 설정되었는지도 중요하다:

env | grep DATABASE

DATABASE_URL이 없으면 데이터베이스 연결이 실패한다.

하나씩, 순서대로

  1. 프로세스가 실행 중인가? (ss 명령)
  2. 시스템 로그에 에러가 있는가? (journalctl)
  3. 포그라운드에서 직접 실행해보면 뭐라고 하는가?
  4. 디스크는 충분한가? (df)
  5. 권한은 충분한가? (ls -la)

이 순서대로 하나씩 확인하면 99%의 배포 에러를 해결할 수 있다.