서버 운영
서버 에러 메시지를 읽는 순서
서버에서만 에러가 난다면 포트, 로그, 권한을 이 순서대로 확인해야 한다. 추측하지 말고 로그를 본다.
서버에 배포했는데 "연결할 수 없음" 에러만 나고 정확한 원인을 알 수 없었다. 일관된 순서로 디버깅해야 한다는 걸 깨달았다.
첫 번째: 프로세스와 포트 확인
서버가 제대로 켜졌는지, 올바른 포트에서 리스닝 중인지 확인:
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이 없으면 데이터베이스 연결이 실패한다.
하나씩, 순서대로
- 프로세스가 실행 중인가? (ss 명령)
- 시스템 로그에 에러가 있는가? (journalctl)
- 포그라운드에서 직접 실행해보면 뭐라고 하는가?
- 디스크는 충분한가? (df)
- 권한은 충분한가? (ls -la)
이 순서대로 하나씩 확인하면 99%의 배포 에러를 해결할 수 있다.