서버에서 DB 파일을 못 열 때 디버깅 흐름

서버에서 DB 파일을 못 열 때는 단순히 화면의 에러 메시지만 봐서는 안 된다. 로컬에서는 잘 돌던 것이 운영 환경에서 터지는 이유를 파악하려면, 환경 차이와 로그, 권한을 함께 살펴야 한다.

먼저 확인할 값들

문제가 발생했을 때 가장 먼저 디스크와 포트, 프로세스를 한 번에 본다.

sudo ss -lntp
df -h
sudo journalctl -n 80

ss -lntp로 현재 열린 포트를 확인하고, df -h로 디스크 용량을 본다. 자주 놓치는 부분은 디스크가 가득 찼을 때인데, DB 파일을 만들 수 없어서 생기는 에러다. journalctl은 시스템 로그를 보여주니 권한 거부나 리소스 부족을 파악하는 데 도움이 된다.

로컬과 운영의 환경 차이

같은 코드를 배포해도 환경에서 비롯된 차이가 숨어 있다. 특히 이런 세 가지를 자주 헷갈린다.

• 파일 시스템 권한: 로컬에서는 사용자가 쓰기 권한이 있지만, 서버의 데몬은 다른 사용자로 실행될 수 있다.
• 워킹 디렉토리: 애플리케이션이 상대 경로로 DB 파일을 찾으려 하면, 실제 실행 위치에 따라 다르다.
• 시스템 자원: 메모리나 스왑 공간이 부족하면 파일 시스템 작업이 실패한다.

권한과 소유권 확인

DB 파일 디렉토리 권한을 먼저 본다.

ls -la /path/to/db/
stat /path/to/db/file.db

파일 소유자와 그룹을 확인해서, 실행 중인 프로세스가 읽고 쓸 권한이 있는지 확인한다. 디렉토리 권한도 중요한데, 쓰기 권한이 없으면 새 파일을 만들 수 없다.

단계별 확인 흐름

1. 원래 에러가 같은 조건에서 다시 나는지 재현한다. 한두 번만 나는 경우와 항상 나는 경우는 원인이 다르다.
2. 로그와 응답 메시지에서 바뀐 부분을 짧게 설명해본다. 예를 들어 "데이터베이스 파일을 만들 수 없음"이면 디스크 용량이나 권한일 가능성이 높다.
3. 공개 서비스 화면과 실제 서버 상태를 함께 확인한다. 사용자가 볼 수 있는 에러 페이지와 서버 로그가 일치하지 않을 수 있다.

마무리

작은 확인들을 기록해두면 다음 번에 비슷한 문제가 나올 때 훨씬 빨리 처리할 수 있다. 특히 운영 환경은 조건이 자주 바뀌므로, 현재 상태를 스냅샷처럼 남겨두는 습관이 도움이 된다.