Heroku vs AWS 차이는?

Heroku는 간단하지만 비쌈, AWS는 복잡하지만 저렴하고 유연합니다.

Gunicorn은 뭔가요?

Python WSGI HTTP 서버입니다. Flask/Django를 프로덕션에서 실행할 때 사용합니다.

Docker는 왜 사용하나요?

환경 일관성을 보장합니다. 개발/테스트/프로덕션 환경을 동일하게 유지합니다.

Python 웹 배포 | Heroku, AWS, Docker 배포 완벽 정리

2026년 3월 28일 · 22분 읽기 · 수정 2026년 4월 18일 중급 튜토리얼

이 글의 핵심

from dotenv import load_dotenv import os.

들어가며

”개발은 끝, 이제 배포”

배포는 애플리케이션을 실제 사용자에게 제공하는 과정입니다.

실무 활용 사례: 데이터 분석, 웹 개발, 자동화 프로젝트에서 실제로 사용한 패턴과 코드를 바탕으로 정리했습니다. 초보자가 흔히 겪는 오류와 해결법을 포함합니다.

1. 배포 준비

requirements.txt

서버에 올릴 때는 개발 PC에 깔린 패키지 목록을 영수증처럼 고정해 두는 것이 안전합니다. pip freeze로 버전까지 적어 두면, 나중에 같은 조합을 다시 설치하기 쉽습니다.

# 패키지 목록 생성
pip freeze > requirements.txt

Flask==2.3.0
gunicorn==20.1.0
python-dotenv==1.0.0

환경 변수 (.env)

# .env
SECRET_KEY=your-secret-key
DATABASE_URL=postgresql://user:pass@localhost/db
DEBUG=False

# app.py
from dotenv import load_dotenv
import os
load_dotenv()
app.config['SECRET_KEY'] = os.getenv('SECRET_KEY')
app.config['DEBUG'] = os.getenv('DEBUG', 'False') == 'True'

2. Gunicorn 설정

Gunicorn으로 실행

# 설치
pip install gunicorn
# 실행
gunicorn app:app
# 워커 설정
gunicorn -w 4 -b 0.0.0.0:8000 app:app

gunicorn.conf.py

bind = "0.0.0.0:8000"
workers = 4
worker_class = "sync"
timeout = 30
keepalive = 2

3. Docker 배포

Dockerfile

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["gunicorn", "-w", "4", "-b", "0.0.0.0:8000", "app:app"]

docker-compose.yml

version: '3.8'
services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://user:pass@db:5432/mydb
    depends_on:
      - db
  
  db:
    image: postgres:15
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=mydb
    volumes:
      - postgres_data:/var/lib/postgresql/data
volumes:
  postgres_data:

# 실행
docker-compose up -d

4. Heroku 배포

Procfile

web: gunicorn app:app

runtime.txt

python-3.11.0

배포 명령어

# Heroku CLI 설치 후
heroku login
heroku create myapp
# 환경 변수 설정
heroku config:set SECRET_KEY=your-secret-key
# 배포
git push heroku main
# 로그 확인
heroku logs --tail

5. AWS 배포 (EC2)

EC2 설정

# 서버 접속
ssh -i key.pem ubuntu@ec2-instance
# Python 설치
sudo apt update
sudo apt install python3-pip python3-venv
# 프로젝트 클론
git clone https://github.com/user/myapp.git
cd myapp
# 가상환경
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
# Gunicorn 실행
gunicorn -w 4 -b 0.0.0.0:8000 app:app

Nginx 설정

# /etc/nginx/sites-available/myapp
server {
    listen 80;
    server_name example.com;
    
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

# Nginx 활성화
sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

6. 프로덕션 배포 전에 확인할 항목

서버에 올리는 순간 앱은 디버그 모드가 꺼진 채 외부와 연결됩니다. 비밀 키·DB URL은 환경 변수로만 두고, Django라면 ALLOWED_HOSTS와 collectstatic·migrate까지 한 번에 점검하는 습관이 필요합니다. HTTPS는 인증서(예: Let’s Encrypt)나 프록시 뒤에서 종료하는 방식으로 맞춥니다.

# ✅ 환경 변수
# SECRET_KEY, DATABASE_URL 등
# ✅ DEBUG = False
app.config['DEBUG'] = False
# ✅ ALLOWED_HOSTS (Django)
ALLOWED_HOSTS = ['yourdomain.com']
# ✅ 정적 파일
python manage.py collectstatic
# ✅ 데이터베이스 마이그레이션
python manage.py migrate
# ✅ HTTPS 설정
# Let's Encrypt, Cloudflare

실전 심화 보강

실전 예제: Gunicorn + systemd 유닛 (프로덕션 최소 패턴)

애플리케이션은 myapp.wsgi:app이라고 가정합니다. 소켓 활성화 대신 여기서는 127.0.0.1:8000 바인드 예시를 둡니다. /etc/systemd/system/myapp.service:

[Unit]
Description=My Gunicorn App
After=network.target
[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/myapp
Environment="PATH=/var/www/myapp/venv/bin"
EnvironmentFile=/etc/myapp.env
ExecStart=/var/www/myapp/venv/bin/gunicorn -w 4 -b 127.0.0.1:8000 myapp.wsgi:app
Restart=always
[Install]
WantedBy=multi-user.target

배포 후 sudo systemctl daemon-reload && sudo systemctl enable --now myapp으로 기동합니다.

자주 하는 실수

DEBUG=True로 운영에 올려 시크릿·트레이스백이 노출되는 경우.
가상환경 경로를 하드코딩해 배포 스크립트가 깨지는 경우.
헬스체크 없이 로드밸런서만 믿고 프로세스가 죽은 줄 모르는 경우.

주의사항

시크릿은 환경 변수·비밀 저장소에 두고 Git에 넣지 마세요.
ALLOWED_HOSTS·CORS·CSRF는 프로덕션 프로파일에서 재검증합니다.

실무에서는 이렇게

리버스 프록시(Nginx/Caddy) 앞에 두고 TLS 종료를 맡깁니다.
로그는 journald + 중앙 집중(CloudWatch, ELK)으로 보냅니다.
컨테이너라면 읽기 전용 루트fs + non-root 유저를 기본으로 합니다.

비교 및 대안

방식	장점
PaaS(Heroku 등)	운영 단순
VM + systemd	제어·비용 트레이드오프
Kubernetes	대규모·멀티 서비스

추가 리소스

내부 동작과 핵심 메커니즘

이 글의 주제는 「Python 웹 배포 | Heroku, AWS, Docker 배포 완벽 정리」입니다. 여기서는 앞선 설명을 구현·런타임 관점에서 한 번 더 압축합니다. 데이터 흐름과 실패 모드를 기준으로 생각하면, “입력이 어디서 검증되고, 핵심 연산이 어디서 일어나며, 부작용(I/O·네트워크·디스크)이 어디서 터지는가”가 한눈에 드러납니다.

처리 파이프라인(개념도)

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

알고리즘·프로토콜 관점에서의 체크포인트

불변 조건(Invariant): 각 단계가 만족해야 하는 조건(예: 버퍼 경계, 프로토콜 상태, 트랜잭션 격리)을 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
결정성: 동일 입력에 동일 출력이 보장되는 순수한 층과, 시간·네트워크에 의해 달라질 수 있는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
경계 비용: 직렬화/역직렬화, 문자 인코딩, syscall 횟수, 락 경합처럼 “한 번의 호출이 아니라 누적되는 비용”을 의심 목록에 넣습니다.

프로덕션 운영 패턴

실서비스에서는 기능 구현과 함께 관측·배포·보안·비용이 동시에 요구됩니다. 아래는 팀에서 자주 쓰는 최소 체크리스트입니다.

영역	운영 관점에서의 질문
관측성	요청 단위 상관 ID, 에러율/지연 분위수, 주요 의존성 타임아웃이 보이는가
안전성	입력 검증·권한·비밀 관리가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등한 연산에만 적용되는가, 서킷 브레이커·백오프가 있는가
성능	캐시 계층·배치 크기·풀링·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리, 마이그레이션 호환성이 문서화되어 있는가

운영 환경에서는 “개발자 PC에서는 재현되지 않던 문제”가 시간·부하·데이터 크기 때문에 드러납니다. 따라서 스테이징의 데이터 양·네트워크 지연을 가능한 한 현실에 가깝게 맞추는 것이 중요합니다.

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스 컨디션, 타임아웃, 외부 의존성 불안정	최소 재현 스크립트 작성, 분산 트레이스·로그 상관관계 확인
성능 저하	N+1 쿼리, 동기 I/O, 잠금 경합, 과도한 직렬화	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 클로저/이벤트 구독 누수, 대용량 객체의 불필요한 복사	상한·TTL·스냅샷 비교(힙 덤프/트레이스)
빌드·배포만 실패	환경 변수·권한·플랫폼 차이	CI 로그와 로컬 `diff`, 컨테이너/런타임 버전 핀(pin)

권장 디버깅 순서: (1) 최소 재현 만들기 (2) 최근 변경 범위 좁히기 (3) 의존성·환경 변수 차이 확인 (4) 관측 데이터로 가설 검증 (5) 수정 후 회귀·부하 테스트.

정리

핵심 요약

Gunicorn: WSGI 서버
Docker: 환경 일관성
Heroku: 간단한 배포
AWS: 유연하고 저렴
Nginx: 리버스 프록시

다음 단계

Pandas 데이터 분석
웹 스크래핑

자주 묻는 질문 (FAQ)

Q. 이 내용을 실무에서 언제 쓰나요?

A. Python 웹 배포 from dotenv import load_dotenv import os. 실전 예제와 코드로 개념부터 활용까지 정리합니다. Python·배포·Deployment 중심으로 설명합니다. Start… 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.

Q. 선행으로 읽으면 좋은 글은?

A. 각 글 하단의 이전 글 또는 관련 글 링크를 따라가면 순서대로 배울 수 있습니다. Python 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.

Q. 더 깊이 공부하려면?

A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다.

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

이 글에서 다루는 키워드 (관련 검색어)

Python, 배포, Deployment, Heroku, AWS, Docker, Gunicorn 등으로 검색하시면 이 글이 도움이 됩니다.

이 글이 도움이 되셨나요?

여러분의 피드백은 더 나은 콘텐츠를 만드는 데 도움이 됩니다

문제가 있거나 개선 제안이 있으시면 연락처로 알려주세요.