Django 블로그를 직접 만들기 시작한 이유

컴퓨터공학을 전공하고 Java 웹 개발을 약 1년 경험한 뒤 다른 업종에서 10년 넘게 일했다. 취미로 코딩을 이어가다가, 글을 쓰는 공간도 직접 만들어보자는 생각으로 Django 블로그를 시작했다. 처음부터 많은 기능을 넣기보다 글 목록·본문·관리자 글쓰기라는 작은 흐름을 만드는 것이 목표였다.

초기 개발에서는 이미지 업로드가 완성되지 않아 외부 이미지 주소를 본문에 넣었고, 대표 이미지는 별도로 다뤘다. 지금의 편집기와 초기 화면은 다르다. 이 글에서는 시작 당시의 선택을 남기면서, 2026년 9월 21일 저장소에서 확인한 개발 환경과 점검 순서를 함께 정리한다.

Docker로 맞추는 것과 따로 관리할 것

집에서는 데스크톱, 밖에서는 노트북으로 작업하려고 Docker를 사용했다. Python과 PostgreSQL을 PC마다 수동 설치하는 부담을 줄이고, 서비스 구성과 실행 방법을 파일로 공유할 수 있기 때문이다. 다만 같은 Compose 파일을 쓴다고 모든 환경 차이가 사라지지는 않는다.

현재 개발 구성은 web, db, pgadmin 세 서비스다. 웹 컨테이너는 저장소를 /app에 연결하고 Django 개발 서버를 실행한다. DB는 PostgreSQL 16 이미지와 별도 데이터 볼륨을 사용한다. 브라우저로 접속하는 개발 웹 포트는 8000이다.

항목 저장소로 공유하는 내용 별도로 확인할 내용
실행 환경 Dockerfile·Compose·패키지 목록 실제 빌드 이미지와 설치 버전
코드 Python·템플릿·JavaScript 현재 체크아웃과 컨테이너가 읽는 경로
데이터 모델과 migration 파일 DB에 적용된 migration과 실제 레코드
업로드 업로드 처리 코드 미디어 파일과 보관 볼륨
설정 설정을 읽는 코드 환경 변수·도메인·외부 서비스 설정

예를 들어 현재 패키지 목록의 Django 조건은 Django>=5.0이다. 빌드 시점에 따라 설치 버전이 달라질 수 있으므로 이 조건만 보고 “Django 5.0 환경”이라고 단정할 수 없다. 재현이 필요하면 컨테이너에서 실제 버전을 확인해야 한다. Git에 코드가 있다는 사실도 DB와 업로드 파일의 백업을 대신하지 않는다.

DB가 실행 중인 것과 준비된 것은 다르다

웹이 DB보다 먼저 요청을 보내면 연결 오류가 날 수 있다. 개발 Compose는 pg_isready 상태 검사와 depends_on의 service_healthy 조건을 사용해 DB 준비 상태를 기다린다. 이 조건은 시작 순서를 다루며, 이후 발생하는 연결 끊김이나 잘못된 계정 설정까지 해결해주는 것은 아니다. Docker의 시작 순서 설명에서도 실행 상태와 서비스 준비 상태를 구분한다.

개발 웹의 시작 명령에는 migration 적용과 runserver가 포함돼 있다. 따라서 컨테이너를 켜는 과정도 DB에 영향을 줄 수 있다. 상태만 확인하려는 때에는 먼저 아래처럼 조회·검사 명령부터 사용한다.

docker compose -f .\docker\dev\docker-compose.dev.yml config --quiet
docker compose -f .\docker\dev\docker-compose.dev.yml ps
docker compose -f .\docker\dev\docker-compose.dev.yml exec -T web python -m django --version
docker compose -f .\docker\dev\docker-compose.dev.yml exec -T web python src/manage.py check

첫 명령은 Compose 구성이 유효한지 검사한다. 두 번째는 컨테이너 상태를 보여준다. 마지막 check는 Django 설정 문제를 찾는 데 도움이 되지만, 글쓰기·이미지 업로드·실제 방문자의 페이지 사용까지 검증하지는 않는다. 오류가 나면 설정 검사 → DB 상태 → 웹 로그 → 해당 기능 순으로 범위를 좁히는 편이 원인을 찾기 쉽다.

Git 배포와 게시글 데이터 반영을 나누기

초기 구성에서는 NAS에 Git 서버를 두고 push 뒤 서버 코드 갱신과 컨테이너 재시작을 연결했다. 반복 배포를 줄이려는 선택이었다. 운영 훅의 실제 동작은 서버 설정에 달려 있으므로 다른 환경에 그대로 적용할 배포 규칙으로 보기는 어렵다.

블로그를 운영하면서 구분해야 할 것은 코드 배포와 콘텐츠 저장이다. 템플릿 수정은 코드 배포로 반영할 수 있지만, DB에 저장한 기존 글 본문은 별도의 저장 또는 데이터 적용이 필요하다. 파일을 올린 뒤에도 화면이 그대로라면 먼저 바뀐 대상이 코드인지 DB인지 확인해야 한다.

운영 반영 후에는 대표 페이지의 제목·본문·이미지를 확인하고, 변경한 기능을 직접 실행한다. 시작에 성공한 컨테이너와 정상 동작하는 서비스는 서로 다른 확인 단계다. 개발 전용 runserver 구성을 운영 서버 설정으로 그대로 사용하지도 않는다.

다음 구현으로 이어지는 기록

블로그의 첫 단계는 직접 운영할 수 있는 작은 글쓰기 흐름을 만드는 일이었다. 이후 글쓰기 화면의 접근 권한, 방문 통계의 집계 기준, 편집기의 저장 방식을 각각 분리해 점검했다. 환경을 실행하는 방법과 글을 안전하게 보관하는 방법을 함께 기록해야 다음 수정 때 같은 문제를 덜 반복할 수 있다.