Django 애플리케이션을 production에 어떻게 배포하나요?

Question

Accepted Answer

Django를 production에 배포하는 것은 적절한 **WSGI/ASGI 서버**와 **웹 서버** 뒤에서 실행하고, 정적 파일을 올바르게 제공하고, 설정을 보호하고, 데이터베이스를 관리하는 것을 포함합니다—내장 개발 서버(production용이 **아님**)와는 상당히 다릅니다.

## production 스택

```text
Client → NGINX(웹 서버) → GUNICORN(WSGI 앱 서버) → DJANGO
           │                      (Python 앱을 실행, 여러 워커)
           └─ 정적/미디어 파일을 직접 제공(효율적)

❌ production에서 `python manage.py runserver`를 절대 사용하지 말 것 — 단일 스레드,
   안전하지 않고, 부하용으로 만들어지지 않음. Gunicorn(WSGI) 또는 Uvicorn(비동기용 ASGI) 사용.
```

개발 서버는 production에 부적합합니다. 표준 스택: **애플리케이션 서버**(WSGI용 Gunicorn/uWSGI, ASGI/비동기용 Uvicorn)가 여러 워커로 Django를 실행하고, 들어오는 연결, TLS, 정적 파일을 처리하는 **웹 서버**(nginx) 뒤에 위치합니다.

## production 설정(보안에 중요)

```python
DEBUG = False                            # ❗ 반드시 False — DEBUG=True는 민감한 정보 노출
ALLOWED_HOSTS = ["example.com"]          # DEBUG=False일 때 필수
SECRET_KEY = os.environ["SECRET_KEY"]    # 환경에서, 커밋하지 않음
SECURE_SSL_REDIRECT = True               # HTTPS 강제
SESSION_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000
```

## 정적 파일

```bash
python manage.py collectstatic           # 정적 파일을 STATIC_ROOT로 수집
# 그 다음 nginx나 CDN으로 제공 — 또는 WhiteNoise로 앱에서 제공
# (Django는 production에서 정적 파일을 직접 제공하지 않음)
```

## 데이터베이스와 migration

```bash
python manage.py migrate                  # production DB에 migration 적용
# 실제 데이터베이스(PostgreSQL), 연결 풀링, 정기 백업 사용
```

## 전형적인 배포 체크리스트

```text
1. production 환경 변수 설정(SECRET_KEY, DB 자격 증명, DEBUG=False)
2. migration 실행(manage.py migrate)
3. 정적 파일 수집(collectstatic) → nginx/CDN/WhiteNoise로 제공
4. Gunicorn/Uvicorn으로 앱 실행(여러 워커, nginx 뒤)
5. HTTPS 활성화(TLS 인증서, 예: Let's Encrypt)
6. 로깅, 오류 모니터링(Sentry), 헬스 체크 설정
7. 프로세스 관리자(systemd/supervisor) 추가 또는 컨테이너(Docker) + 오케스트레이션 사용
8. 보안 설정 감사를 위해 `manage.py check --deploy` 실행
```

## 현대적 배포 접근

```text
✓ 컨테이너(Docker) + 오케스트레이션(Kubernetes) 또는 플랫폼(Heroku, Railway, Render)
✓ 관리형 데이터베이스, 별도 정적/미디어 스토리지(S3 + CDN)
✓ 백그라운드 워커(Celery) + broker(Redis)를 별도 서비스로
✓ 수평 확장: 로드 밸런서 뒤 여러 앱 인스턴스(앱을 STATELESS로 유지)
```

## 왜 중요한가

Django를 production에 올바르게 배포하는 것은 애플리케이션을 개발에서 실세계 사용으로 가져가는 데 필수적인 지식이며, 로컬 개발과 근본적으로 다른 중요한 고려사항을 포함합니다—잘못하면 보안 취약점, 낮은 성능, 또는 깨진 애플리케이션으로 이어집니다.

**production 스택**을 이해하는 것이 기초입니다: 내장 개발 서버(`runserver`)는 명시적으로 production용이 아니므로(단일 스레드, 안전하지 않고, 부하를 처리할 수 없음), Django를 여러 워커를 가진 적절한 **애플리케이션 서버**(WSGI용 Gunicorn/uWSGI, 또는 ASGI/비동기용 Uvicorn) 뒤에서 실행하고, 연결, TLS, 정적 파일 제공을 처리하는 **웹 서버**(nginx)를 앞에 두어야 합니다.

여러 측면이 보안과 정확성에 중요합니다: **production 설정**(특히 `DEBUG=False`, `DEBUG=True`는 민감한 트레이스백과 구성을 공격자에게 노출하므로 필수, 그리고 `ALLOWED_HOSTS`, 환경에서 오는 비밀 `SECRET_KEY`, HTTPS 강제), **정적 파일 처리**(`collectstatic` 실행 및 nginx/CDN/WhiteNoise로 파일 제공, Django가 production에서 직접 제공하지 않으므로—흔한 배포 실패), **데이터베이스 관리**(PostgreSQL 같은 실제 데이터베이스, migration 적용, 백업).

배포 체크리스트, 현대적 접근(Docker/컨테이너, 관리형 플랫폼, 미디어용 클라우드 스토리지, 별도 서비스로서의 Celery 워커, stateless 앱을 통한 수평 확장), 운영 관심사(로깅, Sentry를 통한 모니터링, 헬스 체크, 프로세스 관리)를 아는 것이 동작하는 production 배포와 취약하거나 안전하지 않은 배포를 구분합니다.

모든 실제 Django 애플리케이션은 결국 배포되어야 하고, 배포 실수(`DEBUG=True`로 두기, 정적 파일 잘못 처리, 비밀 정보 노출, 개발 서버 사용)가 실제 보안과 신뢰성 문제를 일으키므로, Django를 적절히 배포하는 방법—스택, 보안에 중요한 설정, 정적/미디어 처리, 현대적 배포 관행—을 이해하는 것은 production 준비된 애플리케이션을 출시하는 능력을 반영하는 중요하고 위험도가 높은 지식이며, 라이브 시스템을 책임지는 모든 Django 개발자에게 자주 관련되고 전문적으로 필수적인 주제입니다.