Django로 웹사이트를 만드는 것과 실제 서비스를 안정적으로 운영하는 것은 생각보다 큰 차이가 있습니다.
저 역시 win-j.com을 운영하면서 Docker, Nginx, Gunicorn, PostgreSQL, Synology NAS 운영 그리고 운영중인 웹이 포털 사이트에 노출 될 수 있도록 하는 Google Search Console, bing Webmaster, Naver 서치 어드바이저 등록 그리고 애드센스 심사까지 직접 경험 하면서 수많은 시행착오를 겪고 있습니다.
특히 개발 단계에서는 아무 문제 없이 작동하던 사이트가 배포 후에는 CSS가 적용되지 않거나, 500 오류가 발생하거나, robots.tst 태문에 검색엔진이 사이트를 제대로 읽지 못하는 등 예상하지 못한 문제들이 계속 발생했습니다.
이번 글에서는 실제 운영하면서 가장 많이 막혔던 부분들을 중심으로 배포 후 반드시 확인해야 하는 12가지 체크리스트를 정리해보겠습니다.
개발 완료와 운영 준비는 완전히 다르다.
실제로 로컬에서 정상적으로 실행되면 프로젝트 완성! 그리고 본격 운영 서버에서 실제로 운영하려고 개발과 다르게 운영 환경에서는 코드보다 인프라에서 발생하는 문제가 훨씬 많습니다.
실제 서비스는 다음과 같은 환경에서 동작합니다.
Docker
Gunicorn
Nginx
HTTPS
Reverse Proxy
Search Console
robots.txt
Sitemap
SSL 인증서
1. DEBUS=False 설정 확인
가장 먼저 확인해야 하는 항목입니다. 운영 환경에서는 반드시 DEBUG = false로 설정해야 합니다.
개발 환경에서의 .evn 화면
저는 개발용PC나 노트북에서는 각각 .env.dev 까지 git 업로드로 공용으로 사용하고 서버용 .env 파일은 서버에서만 관리하도록 업로드하고 개발 용에서는 True로 서버용은 DEBUG=False로 설정했습니다.
그리고 SECRET_KEY는 코드 안에서 작성하지 않고 환경변수에서 읽는 것이 좋습니다.
예시
python
SECRET_KEY = os.getenv("SECRET_KEY")
위에 개발용 .env 처럼 운영서버에서
DEBUG
SECRET_KEY
ALLOWED_HOSTS
CSRF_TRUSTED_ORIGINS
모두 환경변수로 분리하여 관리하도록 변경했습니다.
TIP
운영 서버에서는 settings.py보다 .env 관리가 훨씬 중요합니다.
2.PostgreSQL 연결과 마이그레이션 확인
운영 중 가장 자주 발생하는 오류 중 하나입니다.
새 서버를 올렸는데 관리자 페이지가 500 오류가 발생한다면 대부분 아래 둘 중 하나였습니다.
migrate 안 함
환경변수(DB 정보) 오류
배포 후 반드시 실행해야 합니다.
python
python manage.py migrate
그리고
python
python manage.py createsuperuser
까지 정상적으로 되는지 확인합니다.
win-j.com의 사이트외에 house 프로젝트를 만들고 배포하려고 했었을 때 슈퍼유저는 정상 생성되었지만, 업체 권한을 추가하는 순간 500오류가 발생했습니다. 원인을 찾아보니 마이그레이션 파일 하나가 서버에 정상적으로 반영되지 않았던 것이 원인이었습니다.
운영에서는 "코드보다 마이그레이션 누락"이 훨씬 자주 발생했습니다.
win-j.com의 블로그의 경우 시놀로지 NAS에서 git 에서 hook 설정을 통해 git push가 될 때 docker의 실행과 makemigrations 와 migrate를 자동으로 진행했기에 마이그레이션 오류가 적었지만 house 프로젝트 hook설정이 없어서 계속해서 마이그레이션을 해야 하기에 종종 오류가 발생하기도 했습니다.
3. Docker 컨테이너 상태 확인
Docker를 사용한다면 가장 먼저 보는 명령입니다 .
docker ps
그리고
docker compose ps
정상적으로 web, db, nginx 가 실행 중인지 확인합니다.
문제가 있다면
docker compose logs web 또는 docker compose logs nginx
를 먼저 확인합니다.
지인으로 부터 회사를 소개하는 홈페이지를 하나 만들고 싶다고 하셔서 한동안 블로그 보다는 다른 웹 사이트를 만드는데 집중하면서 시간을 보내느라 블로그 관리가 늦어지게 되었지만 해당 사이트는 Vultr 에서 서버를 처음 구축해보고 다양한 경험을 해보면서 시놀로지 NAS의 운영에서의 오류보다 다른 오류들을 다양하게 경험하게 되었습니다.
특히 웹은 정상인데 CSS모두 깨져있는 Django 원인이 아닌 정적 파일 collectstatic 되지 않아 발생하는 오류가 발생되었는데 운영에서는 확실히 로그를 먼저 보는 습관이 중요하다고 생각됩니다.
4. Static과 Media 파일 확인
배포 후 CSS가 깨지는 가장 흔한 원인입니다.
반드시 python manage.py collectstatic 를 실행해야 합니다.
그리고 Nginx에서 location /static/ 설정도 확인해야 합니다.
위에 Docker 컨테이너 확인을 하게 되면 바로 원인을 확인이 가능한 부분이기도 합니다. 그래서 항상 배포용으로 Hooks 설정에서 마이그레이션과 빼놓을 수 없는 부분이 바로 collectstatic 입니다.
5. HTTPS와 HTTP 리디렉션
요즘은 HTTPS가 기본입니다. 따라서 아래 4가지는 반드시 확인해야 합니다.
http 접속
https 접속
www 접속
비 www 접속
모두 정상적으로 하나의 URL로 연결되는지 확인합니다.
시놀로지 NAS 역방향 프록시 설정
특히 시놀로지 NAS를 사용해 운영중이라면 역방향 프록시 설정에서 www, https 모두 설정해 주어야 합니다.
6. robots.txt와 Sitemap 확인
검색 유입에서 매우 중요한 부분인 robots.txt와 sitemap 입니다. 확인해야 하는 주소
/robots.txt
/sitemap.xml
그리고 Search Console에서도 정상적으로 읽히는지 확인합니다.
실제로 애드센스 심사에서 ads.txt를 인식하지 못하는 문제가 발생했고 307 Redirect 때문에 정상적으로 확인하지 못하고 있었고 Nginx 설정을 수정한 뒤 정상적으로 접근이 가능해졌습니다. 이 처럼 파일이 있는 것과 검색엔진이 읽는 것은 전혀 다른 문제입니다.
특히 지금 제 사이트의 문제점은 블로그 보다는 유틸리티 성향이 강해 애드센스 승인 심사에서 계속해서 컨텐츠 부족의 문제로 거절되고 있어 현재는 작업했던 유틸리티 페이지들의 noindex 처리와 sitemap 제외 처리 작업을 진행하고 있고 재심사를 위한 준비작업을 진행하고 있습니다.
7. Canonical과 SEO 메타 확인
배포 후 반드시 확인해야 합니다.
게시글 PDF Word 변호나 방법 페이지 소스 코드
브라우저에서 페이지 소스를 열고 (Ctrl + U) <link rel="canonical">를 확인합니다. 또 description , og, og, robots도 함께 확인합니다.
유틸리티 페이지를 다국어 구조로 변경하면서 Canonical이 잘못 설정되어 검색엔진이 중복 페이지로 인식할 가능성이 있었고 결국 Utility 전용 메타 생성 구조를 다시 설계했습니다.
8. 404와 내부 링크 확인
생각보다 검색 품질에 큰 영항을 주는 404 오류 특히 URL 구조를 변경했다면 반드시 확인해야 합니다 .
초기에 언더바(_)기반의 URL을 하이픈(-)구조로 변경하면서 Google Search Console에서 대량의 404오류가 발생했고 결국 리디렉션, Sitemap 재생성, 재색인 요청 까지 진행해야 했고 여기에 생각보다 많은 시간이 소요되었습니다.
서치콘솔 404 오류 페이지 목록
9. 로그 확인 습관 만들기
운영에서는 오류보다 로그가 먼저 알려줍니다.
혼자서 테스트 할때에는 몰랐던 오류들이 운영서버에 올라와서 다수의 사용자가 사용하게 되면 테스트 하면서 놓쳤던 부분들의 오류가 발생하기도 합니다. 그래서 특정 오류에 대한 피드백을 받고 있고 해당 피드백을 통해서 오류를 수정할 때 해당 방향으로 실행해보거나 로그를 통해서 어떤 문제가 있는지 빠르게 확인이 가능합니다.
10. 백업 시스템 만들기
운영하면서 가장 중요한 부분입니다. 최소한 PostgreSQL, Media, .env, Docker Compose는 백업해야 합니다.
저는 시놀로지 NAS를 사용하면서 프로젝트와 데이터베이스를 별도로 관리하도록 구성했습니다. 또 데이터베이스의 경우에는 시놀로지가 아닌 로컬PC로 데이터 베이스 백업 데이터를 저장하고 있습니다.
시놀로지 NAS 장비의 문제 또는 서버 하드의 문제가 발생 될때 복구 할 수 없다면 소스코드는 개발용 소스코드로 어느정도 복원은 가능하겠지만 그동안 작성한 글, 이미지 등은 복구 할 수 없게 되니 그동안의 노력이 모두 사라지게 되는 일이 발생하고 이게 개인 블로그인 경우에는 아쉽다는 정도로 끝나지만 실제로 운영중인 서비스에서 이런 데이터가 모두 사라지게 된다면 엄청난 피해를 입게 되기 때문에 백업은 선택이 아니라 필수입니다.
11. 모바일 화면과 성능 확인
PC에서는 정상인데 모바일에서는 깨지는 경우가 많습니다.
확인할 항목
반응형
이미지 크기
Lighthouse
Core Web Vitals
특히 Google은 모바일 기준으로 평가하는 항목이 많다는 이야기가 많고 실제로 운영중인 win-j 사이트의 방문자 통계에서 bots 영역으로 나눠서 통계를 볼 때 Google에서 테블릿으로 들어오는 크롤러가 상당히 자주 보여집니다.
12. 개인정보처리방침, 문의, 소개 페이지
검색엔진과 광고 플랫폼은 사이트의 신뢰도를 중요하게 평가하고 최소 아래 페이지는 준비하는 것을 추천합니다.
소개
문의
개인정보처리방침
이용약관(필요 시)
Django Docker 운영 명령어 모음
컨테이너 확인
docker ps
서비스 상태
docker compose ps
로그 확인
docker compose logs web
Nginx 로그
docker compose logs nginx
마이그레이션
python manage.py migrate
정적 파일
python manage.py collectstatic
재시작
docker compose restart
이전 Django 운영 시리즈와 함께 읽으면 좋은 글
이 글은 운영 단계를 중심으로 정리했지만, 처음부터 서버를 구축하고 배포하는 과정을 함께 보면 전체 흐름을 이해하기 쉽습니다.
첫 댓글을 남겨보세요.