파이썬 웹 프레임워크 비교: Cloudflare Workers에서 Django vs FastAPI

파이썬 웹 프레임워크 비교: Cloudflare Workers에서는 무엇을 골라야 할까?

이미 Django 애플리케이션을 운영 중이거나 완전한 제품 백엔드가 필요하다면 Django를 선택합니다. 타입이 지정된 API, 웹훅 서비스, I/O 중심 엣지 엔드포인트를 처음부터 만든다면 FastAPI가 알맞습니다. 필수 패키지나 프로세스 모델, 상태 저장 워크로드가 Workers 런타임에 맞지 않는다면 어떤 앱이든 현재 오리진에 유지해야 합니다.

Cloudflare는 2026년 9월 2일 전제를 바꿨습니다. 이제 Python Workers는 workers 모듈의 어댑터를 통해 WSGI와 ASGI 애플리케이션을 직접 호스팅할 수 있습니다. WSGI는 전통적인 동기식 Python 웹 규약입니다. 그 후속 규격인 ASGI는 비동기 방식으로, I/O 중첩 처리와 스트리밍, 장시간 연결을 염두에 두고 설계됐습니다. Django는 두 프로토콜을 모두 사용할 수 있지만, Cloudflare의 공개 예제는 Django를 WSGI와, FastAPI를 ASGI와 명시적으로 짝지어 소개합니다.

통합된 제품 기능이 이미 비즈니스 가치를 만들어 내고 있다면 Django가 더 안전한 마이그레이션 선택입니다. Cloudflare는 이제 WSGI와 ASGI 엔트리포인트를 모두 문서화했으며, D1과 Durable Objects를 위한 django-cf 경로도 제공합니다.

결과물이 관리자 기반 웹 제품이 아니라 API라면 새 프로젝트에는 FastAPI가 더 깔끔합니다. Cloudflare가 ASGI 서버 계층을 제공하므로 Worker에서 Uvicorn을 실행하거나 소켓을 관리할 필요가 없습니다.

CPU 시간이 벌어지기 전까지 가격은 동률입니다

프레임워크 가격에는 차이가 없습니다. 2026년 9월 5일 공식 최신 페이지를 기준으로 가격을 확인했습니다. Django는 무료 오픈 소스이며 BSD 라이선스를 사용하고, FastAPI는 MIT 라이선스를 사용합니다. Workers Paid는 계정당 월 $5부터 시작합니다.

이 $5에는 월 10 million건의 요청과 30 million CPU milliseconds가 포함됩니다. 추가 요청 요금은 million건당 $0.30, 추가 CPU 요금은 million CPU milliseconds당 $0.02입니다. Static Asset 요청은 무료이며 제한이 없습니다. Workers Free는 하루 100,000건의 요청을 제공하지만 호출당 CPU 허용량이 10 ms에 불과해, 단순하지 않은 프레임워크 애플리케이션을 비교할 기준으로는 적합하지 않습니다.

두 프레임워크에 같은 워크로드를 적용하면 결과는 예상대로 단순합니다. 월 15 million건의 동적 요청과 요청당 평균 7 ms CPU를 기준으로 어느 프레임워크든 월 $8입니다. 기본요금 $5에 요청 초과분 $1.50, CPU 초과분 $1.50을 더한 값입니다. 같은 평균 7 ms에서 요청이 100 million건이면 어느 쪽이든 월 $45.40입니다.

임의로 만든 프레임워크 벤치마크보다 민감도 계산이 더 유용합니다. 두 애플리케이션 모두 포함된 CPU 풀을 소진한 뒤에는 평균 CPU가 1 ms 차이 날 때마다 15 million건에서 요금이 $0.30, 100 million건에서 $2 달라집니다. 따라서 측정된 격차가 5 ms라면 해당 트래픽 수준에서 각각 월 $1.50 또는 $10의 차이입니다. 컴퓨팅 비용만을 이유로 프레임워크를 다시 작성하기에는 턱없이 작은 금액입니다.

공급업체 요금만으로 선택이 뒤집히는 지점은 없습니다. 실제 측정한 CPU 시간이나 보조 서비스, 유지보수 부담이 달라져야 한쪽이 더 저렴해집니다. 느린 데이터베이스 호출을 빠른 프레임워크로 감싼다고 아키텍처가 살아나지는 않습니다. 반대로 통합 프레임워크가 몇 주 분량의 대체 작업을 없애 준다면, 마이크로벤치마크에서 다른 쪽이 앞서더라도 전체 시스템 비용은 더 낮을 수 있습니다.

마이그레이션: 기존 시스템은 Django, 신규 API는 FastAPI

어댑터 변경은 작지만 애플리케이션 마이그레이션은 작지 않습니다. 두 프레임워크 모두 얇은 엔트리포인트만 있으면 되지만, 그 뒤에 있는 모든 요소가 Cloudflare의 패키지, 스토리지, 파일시스템, 수명 주기 모델과 맞아야 합니다.

Django의 Cloudflare Workers 마이그레이션: 어댑터가 가장 쉬운 부분입니다

Django는 표준 WSGI 애플리케이션 객체를 그대로 유지한 채 Cloudflare 어댑터에 전달할 수 있습니다.

import os

from django.core.wsgi import get_wsgi_application
from workers import wsgi

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
app = get_wsgi_application()
Default = wsgi.entrypoint(app)

이 코드만으로 Workers에 들어온 요청을 Django의 WSGI 호출 가능 객체에 연결할 수 있습니다. 그러나 데이터베이스, 영구 파일, 예약 작업, 세션 전략이나 모든 서드파티 Django 패키지까지 옮겨 주는 것은 아닙니다.

Cloudflare의 새로운 Django 패키지 가이드는 프레임워크에 실질적인 네이티브 스토리지 경로를 제공합니다. django-cf 패키지는 D1과 Durable Objects용 SQLite 호환 백엔드를 지원합니다. 둘 다 Django의 동기식 ORM을 구동하므로 Cloudflare는 이 구성을 WSGI로 서비스하라고 안내합니다. 모델, 폼, 인증, 관리자에 이미 의존하는 CRUD 제품이라면 이 계층들을 보존하는 편이 프레임워크를 바꿔 런타임 비용에서 얻을 수 있는 절감분보다 훨씬 많은 작업을 줄여 줍니다.

기존 시스템이 전통적인 서버를 전제로 할 때 한계에 부딪힙니다. 데이터베이스 드라이버가 Workers에서 불러올 수 없는 네이티브 wheel을 요구할 수 있습니다. 사용자 업로드는 격리 환경의 파일시스템에 둘 수 없습니다. 프로세스 로컬 스케줄러나 스레드 풀도 그대로 옮길 수 없습니다. Django 지원은 요청 프로토콜이 작동한다는 뜻이지, 설치된 애플리케이션 전체가 호환된다는 보증은 아닙니다.

FastAPI의 Cloudflare Workers 마이그레이션: 범위가 좁은 서비스에 최적입니다

FastAPI는 이미 ASGI를 사용하므로 직접 연결하는 어댑터 코드가 더 짧습니다.

from fastapi import FastAPI
from workers import asgi

app = FastAPI()
Default = asgi.entrypoint(app)

일반적으로 Uvicorn이 맡는 ASGI 서버 역할을 Cloudflare가 제공합니다. FastAPI는 라우트 선언, Pydantic 검증, 의존성 주입, 자동 생성되는 OpenAPI 문서를 그대로 유지합니다. 따라서 새로운 웹훅 수신기, 타입 기반 JSON API, 바인딩 기반 서비스는 Django보다 적은 애플리케이션 구성 요소로 시작할 수 있습니다.

그 대신 조립할 부분이 생깁니다. FastAPI는 데이터베이스나 데이터 모델을 규정하지 않습니다. Django의 콘텐츠 관리자도 포함하지 않습니다. 각 요소를 직접 고르고, 모든 패키지가 Workers 환경과 맞는지 검사하고, 통합까지 책임져야 합니다. 집중된 서비스에는 장점이지만, 운영자가 첫날부터 백오피스를 써야 하는 제품에는 비용이 됩니다.

마이그레이션 승자: 이미 Django인 애플리케이션에는 Django, 새 API에는 FastAPI입니다. 둘 다 엣지에서 실행된다는 이유만으로 잘 작동하는 Django 시스템을 FastAPI로 다시 만드는 것은 잘못된 프로젝트입니다.

Cloudflare의 WSGI vs ASGI: 동시성은 FastAPI, 선택지는 Django

새로운 I/O 중심 서비스에는 ASGI가 더 강력한 요청 모델이지만, Django와 Cloudflare ORM을 통합하는 공식 경로는 WSGI입니다. 프로토콜은 비동기가 언제나 빠르다는 일반론이 아니라 워크로드에 맞춰 선택해야 합니다.

WSGI는 애플리케이션을 동기식 호출 가능 객체로 제시합니다. Cloudflare의 현재 WSGI 어댑터는 Worker의 비동기 fetch 핸들러 안에서 이 객체를 실행하고, JavaScript ReadableStream에서 요청 본문을 연결한 뒤 애플리케이션의 응답 이터러블을 클라이언트로 스트리밍합니다. 이는 성숙한 동기식 애플리케이션을 위한 호환 경로이지, 격리 환경 안에서 두 번째 웹 서버를 실행하는 방식이 아닙니다.

ASGI를 사용하면 요청 경로를 동기 호출에 묶어 두지 않고 네트워크와 스토리지 작업을 기다릴 수 있습니다. Cloudflare 어댑터는 ASGI WebSocket 이벤트를 Workers WebSockets에도 매핑합니다. FastAPI는 이 모델을 기반으로 합니다. Django 역시 사용할 수 있으므로 "Django"와 "WSGI"는 동의어가 아닙니다.

스토리지 선택에 따라 프로토콜 판단이 뒤집힐 수 있습니다. Cloudflare에 따르면 Django용 D1과 Durable Objects 백엔드는 모두 동기식 ORM을 구동하므로 WSGI로 서비스해야 합니다. Django를 선택한 이유가 ORM이라면, 동기식 데이터 계층에 억지로 ASGI라는 이름표를 붙이는 것보다 문서화된 WSGI 경로를 따르는 편이 일관됩니다.

FastAPI에서도 작업을 겹쳐 처리할 수 있을 때만 비동기의 장점이 살아납니다. 엔드포인트가 대부분의 시간을 순차 검증이나 CPU 집약적인 Python 작업에 쓴다면 여전히 CPU를 소비합니다. 서로 독립적인 여러 HTTP 또는 Cloudflare 바인딩 작업을 기다리는 엔드포인트라면 ASGI를 선택할 이유가 더 분명합니다.

시작 동작: FastAPI lifespan의 예상 밖 함정

현재 Workers에서는 WSGI 기반 Django의 시작 모델이 더 예측하기 쉽습니다. FastAPI도 작동하지만, lifespan 훅은 장시간 실행되는 Uvicorn 프로세스에서와 다르게 동작합니다.

Cloudflare는 배포 스냅샷을 통해 Python 콜드 스타트 작업을 줄입니다. 배포 중 플랫폼은 V8 격리 환경을 만들고 Pyodide를 주입한 뒤 Worker 엔트리 모듈과 최상위 import를 실행하고 WebAssembly 메모리의 스냅샷을 생성합니다. 요청 시 Python 환경을 처음부터 다시 만드는 대신 이 스냅샷을 불러올 수 있습니다. 그래도 전역 범위 코드는 플랫폼의 1-second 시작 제한 안에 파싱되고 실행돼야 합니다. Cloudflare는 이 수명 주기를 직접 문서화합니다.

FastAPI의 일반적인 lifespan 규약은 프로세스를 전제로 합니다. 애플리케이션이 요청을 받기 전에 시작 코드가 한 번 실행되고, 종료된 뒤에 종료 코드가 한 번 실행됩니다. 현재 Cloudflare ASGI 어댑터 소스의 동작은 실질적으로 다릅니다. fetch 함수가 ASGI 애플리케이션을 시작하고 lifespan 시작 이벤트를 보낸 뒤 요청 하나를 처리하고 종료 이벤트를 전송합니다. 소스 주석도 요청 전후로 한 번씩 시작과 종료 주기를 수행한다고 설명합니다.

즉, 현재 어댑터에서 lifespan 코드는 요청 단위로 실행됩니다. 모델 로드, 연결 풀 구성, 스키마 워밍업, 원격 설정 조회를 이곳에 넣으면 격리 환경 전반에 걸쳐 비용을 분산하는 대신 반복 실행될 수 있습니다. 그렇다고 FastAPI를 배제할 이유는 아닙니다. lifespan 작업을 가볍고 멱등하게 만들고, 안전하고 결정적인 초기화는 Cloudflare의 배포 스냅샷을 활용할 수 있는 코드로 옮겨야 한다는 뜻입니다.

Cloudflare 예제에서 Django의 WSGI 애플리케이션은 모듈 범위에서 생성되며 ASGI lifespan 주기가 없습니다. 따라서 초기화가 전역 시작 경로에 포함되고, 이때는 1-second 상한이 제약이 됩니다. Django의 ASGI 엔트리포인트를 선택하고 lifespan 인식 구성 요소를 사용한다면 같은 어댑터 동작을 기준으로 검사해야 합니다.

Python Workers 프레임워크가 함께 마주하는 패키지 장벽

이 항목은 동률이며, 두 프레임워크 모두 탈락시킬 수 있습니다. Django와 FastAPI는 V8 내부의 동일한 Pyodide 환경에서 실행되므로 패키지, 메모리, 파일시스템, 시작 제한을 어느 쪽도 피할 수 없습니다.

Cloudflare 패키지 문서에 따르면 pywrangler는 pyproject.toml에 선언된 의존성을 번들로 묶습니다. 지원되는 소스에는 PyPI의 순수 Python 및 PyEmscripten 패키지와 Pyodide에 포함된 패키지가 있습니다. PyEmscripten은 WebAssembly를 대상으로 한 wheel 형식입니다. Cloudflare 역시 아직 이 생태계가 초기 단계라고 설명하며, 일부 패키지는 호환 wheel이 없습니다.

반드시 확인해야 할 플랫폼 제약은 명확합니다.

• 압축을 풀었을 때 Worker 번들은 Free나 Paid 모두 64 MiB를 넘을 수 없습니다.
• 각 격리 환경의 메모리는 128 MB입니다.
• 전역 범위 시작 작업은 1 second 안에 끝나야 합니다.
• Python 파일시스템은 일시적이며 격리 환경별로 분리됩니다.
• threading과 multiprocessing은 import할 수 있지만 WebAssembly VM에서 작동하지 않습니다.

파일시스템 제약은 어댑터 시그니처만 봐서는 드러나지 않는 수많은 마이그레이션 문제를 일으킵니다. 임시 파일은 괜찮습니다. 영구 업로드, 생성된 보고서, 영속 상태로 쓰는 SQLite 파일, 공유 온디스크 캐시는 사용할 수 없습니다. 영구 객체는 접근 패턴에 따라 D1, Durable Objects, KV 또는 R2에 두어야 하며, 격리 환경과 함께 사라지는 디렉터리에 저장해서는 안 됩니다. 정확한 제한은 Cloudflare의 Python 표준 라이브러리 가이드에 나와 있습니다.

성능을 따지기 전에 패키지 호환성부터 통과해야 합니다. hello-world 일부가 아닌 실제 의존성 그래프를 빌드합니다. 데스크톱 CPython에서 import에 성공했다고 해서 Pyodide에서 네이티브 확장을 사용할 수 있다는 뜻은 아닙니다.

운영 적합성: 제품은 Django, 서비스는 FastAPI

작업 단위가 제품이면 Django가, 서비스면 FastAPI가 우세합니다. 이 구분은 합성 라우트에서 측정한 프레임워크 처리량보다 오래 유효합니다.

관리자 기반 제품의 승자: Django

Django에는 사용자 인증, 콘텐츠 관리, ORM, 템플릿, 미들웨어를 비롯해 웹 제품에서 흔히 필요한 기능이 함께 제공됩니다. 공식 개요도 인증과 콘텐츠 관리를 명시적으로 강조합니다. 소규모 운영팀이 고객, 주문, 권한, 편집 기록을 관리해야 한다면 내장 관리자가 프레임워크 오버헤드 몇 milliseconds를 줄이는 것보다 더 큰 가치를 제공할 수 있습니다.

Workers에서 django-cf는 이 통합 모델을 D1 또는 Durable Objects와 연결합니다. 그 대가로 동기식 ORM과 더 긴밀하게 결합되며, 더 큰 프레임워크 구성 전체를 런타임 제한 안에 맞춰야 합니다.

타입 기반 API 서비스의 승자: FastAPI

FastAPI는 OpenAPI, JSON Schema, Pydantic 검증, 의존성 주입을 중심으로 설계됐습니다. 기능 문서도 데이터베이스와 데이터 모델 선택이 열려 있다는 트레이드오프를 분명히 밝힙니다. 바인딩과 원격 API를 호출하는 API 게이트웨이, 웹훅 수신기, 모델 엔드포인트, 소규모 서비스에 맞는 구조입니다.

서비스에 필요 없다면 통합 관리자와 ORM의 부재는 단점이 아닙니다. 비기술 운영자에게 백오피스가 필요해지는 순간부터 제공 비용이 됩니다.

순수 속도의 승자: Workers에서는 입증되지 않았습니다

FastAPI 벤치마크 페이지에 따르면 TechEmpower의 독립 테스트에서 Uvicorn 기반 FastAPI는 전통적으로 가장 빠른 Python 프레임워크 그룹에 속했습니다. TechEmpower는 표준화된 JSON, 데이터베이스, ORM, 템플릿 및 관련 워크로드를 측정했습니다. 그러나 Cloudflare의 Pyodide 어댑터를 측정한 것은 아니며, 프로젝트는 2026년 3월 24일 종료됐습니다. 따라서 이 결과는 출처가 있는 과거 지표일 뿐, Workers 배포 성능을 예측하는 자료는 아닙니다.

Cloudflare는 이 어댑터를 통한 Django와 FastAPI 비교 벤치마크를 공개하지 않았습니다. 검증, 바인딩, 데이터베이스 호출, 응답 형태, 시작 동작, Workers CPU 지표가 포함된 대표 라우트를 측정하기 전까지 Workers의 순수 속도는 입증되지 않은 상태입니다.

실제 전환 비용과 전환하면 안 되는 경우

Cloudflare 지원을 얻기 위해서만 프레임워크를 바꾸지 마세요. 이제 둘 다 지원됩니다. 대상 프레임워크가 줄여 주는 애플리케이션 작업이 마이그레이션으로 생기는 작업보다 많을 때만 전환합니다.

Django에서 FastAPI로 다시 작성하려면 모델, 마이그레이션, 관리자 화면, 인증 흐름, 미들웨어, 템플릿과 Django의 요청 수명 주기를 전제로 하는 모든 패키지를 교체하거나 분리해야 합니다. 범위가 좁은 API에는 훌륭한 결과를 낼 수 있지만 배포 설정 하나를 바꾸는 일이 아닙니다. 관리자와 ORM 활용도가 높다면 전환은 새로운 효율을 만들기 전에 기존 이점을 없애 버립니다.

FastAPI에서 Django로 옮길 이유는 서비스형 아키텍처로 감당하기 어려울 만큼 제품이 성장해 Django의 통합 운영 기능이 필요해졌을 때뿐입니다. 그렇지 않으면 소규모 API에 필요 없는 규칙과 구성 요소만 추가됩니다.

FastAPI는 a2wsgi.WSGIMiddleware를 통해 경로 아래에 Django WSGI 애플리케이션을 마운트할 수 있습니다. 일반 서버에서는 이를 활용해 단계적으로 시스템을 분리할 수 있습니다. Workers에서는 패키지와 프로토콜 경계가 하나씩 더 늘어나며, Cloudflare 시작 가이드는 각 프레임워크를 별도로 설명합니다. 결합된 Worker는 기본 지름길이 아니라 검증이 필요한 사용자 정의 통합으로 봐야 합니다.

어느 방향이든 다음 마이그레이션 영역의 비용을 계산합니다.

• 데이터: 스키마 호환성, 마이그레이션, 트랜잭션 동작, D1·Durable Objects 또는 접근 가능한 다른 스토리지로의 이전.
• 파일: 정적 애셋은 Workers Static Assets를 사용할 수 있지만, 영구 사용자 미디어에는 R2 같은 내구성 있는 객체 스토리지가 필요합니다.
• 백그라운드 작업: 프로세스 로컬 스케줄러, 스레드 풀, 자식 프로세스를 플랫폼 네이티브 비동기 작업으로 대체합니다.
• 의존성: 전체 lockfile을 Python Workers 환경에서 해석한 뒤 64 MiB 번들 크기와 1-second 시작 결과를 확인합니다.
• 운영: 로그, 오류 알림, 배포 롤백, 시크릿, 라우트별 성능 기준선을 다시 구축합니다.

전환하지 말아야 할 대상도 분명합니다. 데이터베이스가 안정적으로 작동하고 관리자 워크플로를 광범위하게 활용하는 Django 모놀리스라면 유행만 좇아 FastAPI로 바꾸지 않아야 합니다. 사용할 수 없는 네이티브 wheel에 의존하는 FastAPI 서비스도 프레임워크 문서 페이지가 생겼다는 이유만으로 Workers로 옮겨서는 안 됩니다. 지연 시간 대부분이 멀리 떨어진 데이터베이스에서 발생하는 팀이라면 요청 프레임워크보다 데이터 배치를 먼저 고쳐야 합니다.

다음 주 월요일에 할 일

다음 주에는 애플리케이션 전체가 아니라 대표 라우트 하나를 검증합니다. 프로덕션 시스템의 패키지, 상태, 지연 시간 특성을 담은 라우트를 고른 뒤, 이를 이용해 맞지 않는 선택지를 빠르게 제거합니다.

Cloudflare Workers의 Django와 FastAPI FAQ