Zappa 사용법 2026: Python 웹앱 AWS Lambda 서버리스 배포 가이드

Zappa 사용법을 찾는 사람은 보통 같은 고민에서 출발합니다. Flask나 Django로 만든 작은 웹앱은 있는데, 이것 때문에 서버를 하나 더 운영하기는 애매합니다. 트래픽은 많지 않고, 배포는 간단했으면 좋겠고, 가능하면 요청이 없을 때는 돈도 거의 안 나갔으면 합니다.

Zappa는 그 지점에 놓인 도구입니다. Python 웹앱을 AWS Lambda와 API Gateway 위에 배포해서, 항상 켜진 서버 없이 HTTP 엔드포인트를 만들 수 있게 해줍니다. 이 글에서는 Zappa 사용법을 설치부터 설정, 패키징 검증, 운영 전 체크리스트까지 실제로 따라갈 수 있는 순서로 정리합니다.

검증은 공식 GitHub 저장소, PyPI, 릴리스 정보, 로컬 CLI 실행을 기준으로 했습니다. 임시 Python 가상환경에서 Zappa 0.62.1을 설치했고, Flask 샘플 앱으로 zappa package까지 실행했습니다. 실제 zappa deploy는 AWS 리소스 생성과 과금 가능성이 있어 실행하지 않았습니다.

먼저 결론

• Zappa는 Flask, Django, FastAPI 같은 Python 웹앱을 AWS Lambda와 API Gateway에 배포하는 CLI입니다.
• 기본 흐름은 pip install zappa, zappa init, zappa deploy dev입니다. 설정 파일은 zappa_settings.json입니다.
• 작은 API, 웹훅 처리기, 내부 도구에는 잘 맞습니다. 긴 요청, WebSocket, 큰 정적 파일, 복잡한 VPC가 핵심이면 다른 배포 방식을 같이 비교해야 합니다.

Zappa가 맞는 프로젝트

Zappa를 한 문장으로 줄이면 “Python 웹앱을 Lambda 함수처럼 배포하게 해주는 도구”입니다. 기존 서버 배포처럼 nginx, gunicorn, systemd를 직접 만지는 흐름과는 다릅니다. Zappa가 애플리케이션을 Lambda 실행 패키지로 만들고, API Gateway를 통해 HTTP 요청을 Lambda로 넘기는 구조를 잡아줍니다.

잘 맞는 경우는 꽤 분명합니다.

• 트래픽이 많지 않은 Flask API
• 사내에서만 쓰는 Django 관리자 도구
• FastAPI로 만든 작은 웹훅 수신기
• 슬랙, 결제, 폼, 노션 같은 외부 서비스 이벤트 처리기
• 항상 켜진 서버가 아까운 실험용 Python 웹앱

반대로 “계속 연결되어 있어야 하는 서비스”에는 조심해야 합니다. WebSocket, streaming response, 긴 업로드 처리, 대형 정적 파일 서빙이 중요하다면 Lambda보다 컨테이너 서버가 편할 수 있습니다. Zappa는 서버 운영을 줄여주는 도구이지, AWS의 제약을 없애주는 도구는 아닙니다.

현재 확인한 프로젝트 상태

2026년 기준으로 Zappa는 여전히 배포되고 있습니다. 확인한 수치는 다음과 같습니다.

오래된 이름값만 남은 프로젝트는 아닙니다. 다만 AWS Lambda와 API Gateway 위에 얹는 도구라서, 도입 여부는 “프로젝트가 서버리스에 맞는가”로 판단하는 편이 좋습니다.

돈은 어디서 나가나

Zappa 자체는 무료입니다. MIT 라이선스라 구독료는 없습니다. 비용은 AWS에서 나갑니다. Lambda 실행 시간, API Gateway 요청 수, CloudWatch Logs 저장량, S3 패키지 저장량이 대표적입니다.

초기 실험은 무료 티어 안에서 끝날 수 있습니다. 하지만 운영 서비스라면 비용 구조를 이렇게 봐야 합니다.

• 요청 수가 많으면 API Gateway 비용이 커집니다.
• 응답 시간이 길면 Lambda 실행 시간이 비용으로 이어집니다.
• 로그 보관 기간을 안 줄이면 CloudWatch 비용이 누적될 수 있습니다.
• VPC 안의 데이터베이스를 붙이면 NAT Gateway 비용이 갑자기 커질 수 있습니다.

요청이 적은 도구라면 유리합니다. 항상 트래픽이 있는 서비스라면 컨테이너 호스팅과 비교해야 합니다.

무엇을 해주는가

Zappa를 쓰면 배포 주변 작업을 CLI 명령으로 묶을 수 있습니다. 기능을 나열하면 많지만, 실제로 자주 쓰는 것은 아래 정도입니다.

Zappa 사용법: 가장 짧은 흐름

아래 예시는 Flask 앱을 기준으로 합니다. 실제 배포 전에는 AWS 자격 증명과 S3 버킷을 먼저 준비해야 합니다.

python3 -m venv .venv
source .venv/bin/activate
pip install zappa flask

테스트용 앱을 하나 만듭니다.

# app.py
from flask import Flask

app = Flask(__name__)

@app.get("/")
def index():
    return {"ok": True, "tool": "zappa"}

zappa_settings.json은 이렇게 시작할 수 있습니다. s3_bucket은 실제로 본인이 사용할 고유한 버킷 이름으로 바꾸세요.

{
  "dev": {
    "app_function": "app.app",
    "s3_bucket": "your-unique-zappa-bucket",
    "aws_region": "ap-northeast-2",
    "runtime": "python3.12"
  }
}

AWS 인증이 잡혀 있다면 첫 배포는 다음 명령입니다.

zappa deploy dev

이후 코드만 바뀌었다면 보통 deploy가 아니라 update를 씁니다.

zappa update dev

상태와 로그는 이 두 명령으로 확인합니다.

zappa status dev
zappa tail dev --since 10m

직접 확인한 실행 결과

실제 AWS 배포 대신, 로컬에서 안전하게 확인할 수 있는 부분을 먼저 검증했습니다. 실행 환경은 Ubuntu, Python 3.12.3입니다.

python3 -m venv /tmp/zappa-test/venv
source /tmp/zappa-test/venv/bin/activate
pip install zappa==0.62.1 flask
zappa --version
zappa --help
zappa package dev -o zappa-smoke.zip

확인된 결과입니다.

Python 3.12.3
zappa version: 0.62.1
사용 가능한 주요 명령:
certify, deploy, init, settings, package, template, invoke, manage,
rollback, schedule, status, tail, undeploy, unschedule, update

Package created: zappa-smoke.zip (26.0MiB)

zappa package는 AWS 리소스를 만들지 않고 로컬 zip 파일만 생성합니다. 처음 Zappa 사용법을 익힐 때는 바로 배포하기보다 패키징이 되는지 먼저 보는 편이 안전합니다. 의존성 크기 문제도 여기서 어느 정도 드러납니다.

Zappa 설정 예시: Flask, Django, FastAPI

프레임워크마다 핵심 설정 키가 다릅니다. Flask와 Bottle은 app_function을, Django는 django_settings를 봅니다.

Flask / Bottle

{
  "dev": {
    "app_function": "your_module.app",
    "s3_bucket": "your-s3-bucket"
  }
}

Django

{
  "dev": {
    "django_settings": "your_project.settings",
    "s3_bucket": "your-s3-bucket"
  }
}

FastAPI / Starlette / Quart

{
  "dev": {
    "app_function": "your_module.app",
    "app_type": "asgi",
    "s3_bucket": "your-s3-bucket"
  }
}

FastAPI를 쓴다면 app_type: "asgi"가 중요합니다. 대신 공식 문서의 제약도 같이 봐야 합니다. ASGI라고 해서 WebSocket이나 streaming response까지 일반 서버처럼 처리할 수 있는 것은 아닙니다.

작은 팀에서 쓸 만한 자리

Zappa가 가장 실용적인 곳은 “운영 서버를 새로 만들기엔 작은데, HTTPS API는 필요한” 프로젝트입니다. 예를 들어 이런 것들입니다.

• 결제 성공 웹훅을 받아 내부 DB에 기록하는 Flask API
• 관리자만 보는 Django 내부 페이지
• 슬랙 명령어를 받아 처리하는 FastAPI 엔드포인트
• 매일 한 번 외부 API를 긁어 저장하는 스케줄 작업
• 트래픽이 거의 없는 개인/팀 자동화 도구

비슷한 개발자 도구 글로는 Daily Info Lab의 Davia 사용법과 Ponytail 사용법도 함께 볼 수 있습니다. 그 글들이 AI 코딩 워크플로를 다룬다면, 이 글은 Python 앱을 실제 실행 환경에 올리는 배포 쪽 이야기입니다.

배포 전에 봐야 할 제약

운영 전 체크리스트

1. aws sts get-caller-identity로 현재 AWS 인증을 확인합니다.
2. S3 버킷 이름을 실제 소유 가능한 고유 이름으로 정합니다.
3. zappa package dev로 먼저 로컬 패키징을 확인합니다.
4. CloudWatch Logs 보관 기간을 설정합니다.
5. 환경변수와 비밀값을 코드에 넣지 않습니다.
6. 테스트 배포 후 zappa undeploy dev로 정리하는 절차를 확인합니다.

자주 나는 문제

AWS 자격 증명 오류가 난다

먼저 AWS CLI가 같은 환경에서 동작하는지 확인합니다.

aws sts get-caller-identity

여기서 실패하면 Zappa 문제가 아니라 AWS 인증 문제입니다. AWS_PROFILE, AWS_DEFAULT_REGION, ~/.aws/credentials를 확인하세요.

패키지 크기가 너무 크다

먼저 zappa package로 zip 크기를 확인하세요. 데이터 처리나 ML 관련 의존성이 크다면 Lambda zip 배포보다 컨테이너 기반 배포가 나을 수 있습니다. Zappa 안에서는 exclude, exclude_glob, slim_handler를 검토합니다.

FastAPI WebSocket을 쓰고 싶다

Zappa의 ASGI 지원은 일반적인 HTTP API에 더 잘 맞습니다. WebSocket이 핵심이면 API Gateway WebSocket을 별도로 구성하거나 컨테이너 서버를 검토하는 편이 안전합니다.

Django static 파일이 보이지 않는다

Zappa는 정적 파일 서버가 아닙니다. Django static/media는 S3와 CloudFront로 분리하고, Lambda는 동적 요청만 맡기는 식으로 설계하는 편이 낫습니다.

정리

Zappa는 작은 Python 웹앱을 AWS Lambda로 옮길 때 여전히 쓸 만한 선택지입니다. 설치와 첫 배포 흐름이 단순하고, 로그 확인·업데이트·롤백·Django 관리 명령까지 CLI 안에 들어 있습니다.

다만 서버리스가 맞지 않는 앱도 많습니다. 요청이 길고, 연결이 오래 유지되고, 정적 파일이 크고, VPC 네트워크가 복잡하다면 Zappa보다 컨테이너 배포가 단순할 수 있습니다. 그래서 Zappa 사용법의 첫 단계는 명령어를 외우는 것이 아니라, 내 앱이 Lambda에 맞는지 확인하는 것입니다.

Zappa 사용법 FAQ

Zappa 사용법을 익히려면 AWS를 꼭 알아야 하나요?

처음 테스트할 때는 zappa init, zappa deploy, zappa update만으로도 시작할 수 있습니다. 운영에 쓰려면 IAM, Lambda, API Gateway, S3, CloudWatch Logs는 최소한 확인해야 합니다.

Zappa는 Flask와 Django 중 어디에 더 잘 맞나요?

둘 다 지원합니다. 작은 API나 웹훅 처리기는 Flask와 FastAPI가 단순하고, 기존 Django 내부 도구를 옮길 때는 django_settings 기반 설정이 편합니다.

가장 먼저 실행해볼 명령은 무엇인가요?

바로 배포하지 말고 zappa package dev를 먼저 추천합니다. AWS 리소스를 만들지 않고 로컬에서 Lambda용 zip 패키지를 생성하므로, 패키징 문제를 안전하게 볼 수 있습니다.

Zappa 대신 컨테이너 배포를 써야 하는 경우는 언제인가요?

WebSocket, streaming response, 큰 의존성, 긴 요청 처리, 복잡한 VPC 연결이 핵심이면 ECS, Cloud Run, Fly.io, Render 같은 컨테이너 기반 배포도 같이 비교하세요.

출처

• Zappa GitHub 저장소
• Zappa 공식 README
• Zappa 0.62.1 릴리스
• Zappa PyPI 페이지
• AWS Lambda 공식 문서
• Amazon API Gateway 공식 문서