연결 성공과 데이터 보관을 따로 확인하기

Django를 처음 실행했을 때 화면이 뜨는 것과 운영 DB에 연결되는 것은 별도의 단계였습니다. 이 프로젝트는 PostgreSQL을 별도 컨테이너로 실행하고, Django에서 DATABASE_URL을 해석해 접속합니다. 이 글에서는 DB를 지우거나 테스트 글을 운영 사이트에 만들지 않고 접속 경로를 좁히는 방법을 정리합니다.

SQLite가 단순한 연습용이고 PostgreSQL만 운영용이라는 원문의 구분은 지나치게 단순했습니다. 선택은 동시 쓰기, 운영 방식, 백업과 관리 요구에 따라 달라집니다. 여기서는 이미 PostgreSQL을 선택한 win-j의 연결 구성을 다룹니다.

같은 5432라도 접속 위치가 중요하다

명령을 실행하는 곳 개발 DB 접속 대상 이유
개발 PC의 DB 프로그램 localhost:5433 개발 Compose의 호스트 포트
개발 web 컨테이너 db:5432 같은 Compose 네트워크
DB 컨테이너 내부 해당 DB의 로컬 접속 web의 네트워크 접속과 별도

운영 Compose에는 DB의 호스트 포트 매핑이 없습니다. Django는 내부 네트워크로 접근하며, 개발 PC에서 사용한 5433번을 운영 URL에 그대로 넣지 않습니다. web 안의 localhost는 DB가 아니라 web 컨테이너 자신입니다.

현재 settings.py는 dj_database_url로 환경 값을 해석합니다. Python의 os.getenv() 자체가 .env 파일을 읽는 것은 아닙니다. 개발 Compose의 env_file이 docker/dev/.env.dev 값을 컨테이너에 전달하는 단계와 Django가 전달된 값을 읽는 단계를 구분해야 합니다.

Django가 실제 사용하는 연결로 조회하기

다음은 Django shell에서 실행하는 조회 예제입니다. DB 종류와 간단한 쿼리 결과만 출력하며, 비밀번호·사용자명·접속 URL 전체를 노출하지 않습니다.

from django.db import connection

print(connection.vendor)
with connection.cursor() as cursor:
    cursor.execute("SELECT 1")
    print(cursor.fetchone())
    if connection.vendor == "postgresql":
        cursor.execute("SHOW transaction_read_only")
        print(cursor.fetchone()[0])

현재 PostgreSQL 연결이라면 첫 두 결과는 postgresql, (1,)입니다. 마지막은 현재 트랜잭션의 읽기 전용 설정이며 일반적인 쓰기 가능한 연결에서는 off가 나올 수 있습니다. 이것만으로 해당 계정이 모든 테이블에 쓰기 권한을 갖는다고 판단하지 않습니다. 실제 글 저장은 폼 검증, 권한, DB 제약 조건까지 통과해야 합니다.

개발에서는 docker compose -f .\docker\dev\docker-compose.dev.yml exec web python src/manage.py shell로 들어갈 수 있습니다. 실행 중인 web이 필요합니다. NAS의 운영 컨테이너를 확인할 때는 docker exec -it myapp_web python /app/src/manage.py shell처럼 대상과 절대 경로를 명확히 합니다. 이 예제를 위해 운영 DB에 새 글이나 관리자 계정을 만들 필요는 없습니다.

에러 메시지에 따라 다음 확인을 고른다

메시지·증상 우선 확인 피해야 할 추측
호스트 이름을 해석할 수 없음 서비스 이름·네트워크 비밀번호부터 바꾸기
connection refused DB 시작·포트·준비 상태 migration 미적용으로 단정
password authentication failed 실제 DB 계정과 전달된 값 환경 파일 변경만으로 DB 비밀번호도 바뀌었다고 판단
database does not exist 접속 DB명·초기 생성 상태 volume 삭제 후 재생성
relation/column does not exist 접속 DB와 migration 기록 운영에서 무조건 makemigrations 실행

PostgreSQL 공식 이미지의 초기화 환경 변수는 빈 데이터 디렉터리를 처음 준비할 때 적용됩니다. 기존 데이터가 있는 volume을 재사용하면 환경 파일의 POSTGRES_PASSWORD 변경만으로 DB 계정 비밀번호가 바뀌지 않습니다. 이 차이는 공식 이미지 설명에 명시되어 있습니다.

volume과 백업은 다른 역할이다

개발 설정은 pgdata_dev, 운영은 pgdata를 PostgreSQL 16의 /var/lib/postgresql/data에 연결합니다. 컨테이너 재시작 후 데이터가 남았다는 사실은 실행 중 데이터가 있다는 확인일 뿐, 컨테이너 재생성·디스크 장애·실수로 삭제한 뒤 복구할 수 있다는 검증은 아닙니다.

named volume도 삭제되거나 손상될 수 있습니다. 운영 보관 확인은 mount 설정 대조와 별도 백업, 분리된 환경에서의 복원 확인으로 나눕니다. 이 글의 연결 검사에는 volume 삭제나 전체 DB 재생성을 포함하지 않습니다. DB 엔진의 큰 버전을 바꿀 때는 데이터 경로와 업그레이드 절차도 별도 검토해야 합니다.

조회 연결을 확인했다면 모델·migration·삭제 관계로 넘어가 어떤 테이블 변경이 필요한지 살펴봅니다. 접속 성공만 확인한 상태에서 운영 migration까지 완료했다고 기록하지 않는 것이 다음 오류를 추적하는 데 도움이 됩니다.