Python Workers가 Django와 FastAPI를 품었다 — 서버를 하나 덜 세워도 되는 순간

2026.09.09dev

Cloudflare Python Workers가 WSGI/ASGI 웹 프레임워크를 지원하면서 Django, Flask, FastAPI, Starlette 앱을 엣지 Worker로 감쌀 수 있게 됐다. 무엇이 실제로 가능해졌고, 무엇은 아직 서버에 남겨야 하는지 쉽게 정리한다.

파이썬 노트북과 작은 서버 카드들이 엣지 노드 지도 위에 놓인 사실적인 개발 책상 장면

결론부터

Cloudflare Workers에서 Python 웹 프레임워크를 더 자연스럽게 쓸 수 있게 됐다. 2026년 9월 2일 Cloudflare는 Python Workers가 WSGI와 ASGI 웹 프레임워크를 지원한다고 발표했다. 이름만 보면 조용한 런타임 업데이트처럼 보인다. 그런데 Python으로 API를 만들던 사람에게는 꽤 큰 변화다.

이제 “이 작은 FastAPI 앱 때문에 서버 하나 세워야 하나?”라는 질문에, “잠깐, Worker로 감싸볼까?”라는 답이 생겼다.

Django, Flask, FastAPI, Starlette 같은 프레임워크는 원래 서버가 필요했다. Uvicorn, Gunicorn, Nginx, 컨테이너, VM, 로그, 헬스체크, 패치. 작은 API 하나 올리려다 갑자기 미니 인프라 농장을 차리는 순간이 온다. 손바닥만 한 화분을 샀는데 농기계 견적서가 딸려오는 느낌이다.

이번 업데이트의 핵심은 이거다. Cloudflare Workers가 workers 모듈의 wsgi와 asgi 어댑터를 제공해서, 기존 Python 웹앱을 Worker의 fetch 핸들러로 연결할 수 있다. 즉 “Python 함수 하나” 수준을 넘어, 익숙한 웹 프레임워크 앱을 엣지 런타임에 올리는 길이 열렸다.

다만 착각하면 안 된다. 이건 “모든 Django 서비스를 그대로 Lift-and-shift 하세요”가 아니다. 더 정확히는 작고 명확한 Python API, 폼 처리, 내부 도구, 프론트엔드 뒤의 얇은 백엔드를 서버 없이 배포할 선택지가 생긴 것이다.

뭐가 실제로 가능해졌나

Cloudflare 공식 changelog는 간단하다. WSGI 또는 ASGI 규격을 따르는 Python 웹 프레임워크를 Python Workers에서 쓸 수 있고, 프레임워크에 따라 wsgi 또는 asgi를 import해 entrypoint로 감싸면 된다.

FastAPI 예시는 거의 이 정도다.

from fastapi import FastAPI
from workers import asgi

app = FastAPI()

@app.get("/api/hello")
async def api_hello():
    return {"message": "Hello from the edge"}

Default = asgi.entrypoint(app)

Django나 Flask 같은 WSGI 앱은 이렇게 감싼다.

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

app = get_wsgi_application()
Default = wsgi.entrypoint(app)

이 코드가 말하는 변화는 꽤 단순하다.

예전에는 “Python 웹앱”과 “Cloudflare Worker”가 서로 다른 세계처럼 느껴졌다. 하나는 Python 서버 생태계, 하나는 JavaScript/TypeScript 엣지 런타임. 이제는 그 사이에 어댑터가 생겼다. 문을 하나 뚫어둔 셈이다. 신발 벗고 들어가야 하던 집에 현관 매트가 생겼다.

실무적으로는 이런 것들이 쉬워진다.

하고 싶은 일 예전 느낌 이제 가능한 접근
작은 JSON API FastAPI 서버 하나 따로 배포 Python Worker에 FastAPI를 얹어 배포
사내 폼 처리 Flask 앱 + 서버/컨테이너 WSGI 앱을 Worker entrypoint로 감싸기
정적 프론트 + API 프론트 배포처와 API 서버 분리 Workers Static Assets + FastAPI catch-all 조합
가벼운 관리자 도구 VM 하나 만들고 방치 Worker로 배포하고 Cloudflare 대시보드에서 관측
Python 패키지 기반 검증 JS로 다시 짜기 지원되는 Python 패키지를 pywrangler로 번들

가장 와닿는 건 정적 프론트엔드와 API를 한 Worker 안에서 묶는 흐름이다. Cloudflare의 FastAPI 문서는 Workers Static Assets를 ASSETS binding으로 붙이고, /api/hello는 FastAPI가 처리하며, 나머지 경로는 정적 파일로 넘기는 예시를 보여준다. 작은 제품이나 내부 도구라면 프론트와 API 배포가 꽤 단순해진다.

개발자가 작은 API 카드와 정적 프론트엔드 카드를 하나의 배포 상자에 정리하는 사실적인 장면

FastAPI는 왜 잘 맞나

FastAPI는 ASGI 기반이다. Python Workers 문서도 Python Workers가 ASGI 쪽에 최적화되어 있다고 설명한다. 비동기 요청 처리, JSON API, 타입 힌트, Pydantic 기반 검증이 익숙한 팀이라면 가장 먼저 시도하기 좋은 후보가 FastAPI다.

특히 이런 API에 잘 맞는다.

  • 폼 제출을 받아 검증하고 저장하는 API
  • 외부 API를 호출해 결과를 정리하는 얇은 프록시
  • Slack, Discord, GitHub webhook을 받아 큐나 DB로 넘기는 엔드포인트
  • 정적 사이트 뒤에 붙는 작은 검색/추천/문의 API
  • Python 패키지로 간단한 데이터 변환을 하는 내부 도구

여기서 포인트는 “작다”다. 작다는 말은 기능이 하찮다는 뜻이 아니다. Worker에 어울리게 요청 하나의 책임이 분명하다는 뜻이다. 요청을 받고, 검증하고, 필요한 바인딩이나 외부 API를 호출하고, 빠르게 응답한다. 딱 커피 한 잔 사러 편의점 갔다 오는 일이다. 이사짐센터 부르면 이상하다.

Cloudflare Python Workers는 KV, D1, Durable Objects, R2, Queues, Workers AI, Vectorize 같은 바인딩도 사용할 수 있다. Python에서 JavaScript 런타임 API와 바인딩을 다루기 위한 FFI도 제공된다. 그러니 FastAPI는 “요청을 받는 얼굴”이 되고, 저장소와 큐와 AI 호출은 Workers 플랫폼 바인딩이 맡는 구성이 가능해진다.

Django는 어디까지 현실적일까

Django 지원은 반갑다. 하지만 Django라는 이름만 보고 “우리 회사의 7년 된 모놀리스를 내일 Workers로 옮기자”는 결론을 내리면 안 된다. 그런 결론은 회의실 공기를 차갑게 만든다. 누군가 조용히 노트북을 덮을 수 있다.

Django는 보통 많은 것을 한 번에 품는다. ORM, admin, middleware, template, session, auth, migration, static files. 이 중 일부는 Workers에서 다르게 생각해야 한다. Cloudflare 문서는 Django 앱을 ASGI 또는 WSGI로 감싸는 예시와, Cloudflare storage를 Django backend로 쓰는 방향을 보여준다. 길은 있다. 다만 기존 서버의 생활습관을 그대로 가져오면 안 된다.

Django를 Workers에 올릴 때는 이렇게 나눠보는 게 좋다.

Django 사용 방식 Workers 후보인가 이유
작은 admin-less API 예 라우팅과 검증이 단순하면 Worker에 맞다.
기존 Django 앱의 일부 endpoint 조건부 의존성과 DB 접근 패턴을 줄이면 가능하다.
Django admin 중심 백오피스 보통 아님 세션, 파일, 복잡한 DB 작업, 플러그인 의존성이 커질 수 있다.
대형 모놀리스 전체 이전 아니오에 가까움 런타임 제약보다 운영 가정이 다르다.
새 프로젝트의 edge-facing API 예 처음부터 Workers 제약에 맞춰 설계할 수 있다.

Django는 “안 된다”보다 “조각을 잘라 써야 한다”에 가깝다. 기존 앱 전체를 옮기는 프로젝트보다, 새 API나 독립된 작은 기능을 Django/FastAPI 스타일로 만들고 Worker에 올리는 쪽이 훨씬 안전하다.

작은 서랍과 파일 카드들이 정리된 책상 위에서 기존 Django 앱을 기능별로 나누어 보는 듯한 사실적인 장면

pywrangler와 패키지: 파이썬 가방을 어디까지 들고 갈 수 있나

Python Workers는 pywrangler를 통해 로컬 개발, 패키지 설치, 배포를 다룬다. 문서 예시는 uv 기반이다.

uvx --from workers-py pywrangler init
uv run pywrangler dev
uv run pywrangler deploy

패키지는 pyproject.toml에 넣고, 배포 시 Worker bundle에 함께 묶인다. FastAPI 예시는 이렇게 생겼다.

[project]
name = "my-fastapi-app"
version = "0.1.0"
requires-python = ">=3.13"
dependencies = [
    "fastapi"
]

[dependency-groups]
dev = [
    "workers-py",
    "workers-runtime-sdk"
]

여기서 중요한 제한이 있다. Python Workers는 순수 Python 패키지, PyEmscripten wheel, Pyodide에 포함된 패키지를 지원한다. WebAssembly 기반 Python 패키지 지원은 아직 초기 단계라, 모든 PyPI 패키지가 그대로 들어간다고 보면 안 된다.

쉽게 말하면 이렇다.

가벼운 백팩은 들고 비행기 탈 수 있다.
냉장고는 안 된다.

FastAPI, Pydantic처럼 문서에서 언급된 패키지는 좋은 출발점이다. 반대로 시스템 라이브러리에 깊게 기대는 패키지, 큰 바이너리 의존성, 무거운 ML 런타임, 로컬 파일시스템을 많이 만지는 패키지는 먼저 확인해야 한다.

HTTP 클라이언트도 주의해야 한다. 문서에 따르면 비동기 요청이 가능한 HTTP 라이브러리만 지원되며, 현재 aiohttp, httpx가 언급되어 있다. 또는 Python Workers의 FFI를 통해 JavaScript fetch()를 사용할 수 있다.

그래도 서버가 필요한 경우

이 업데이트가 반가운 이유는 “서버가 필요 없는 일이 늘었다”는 데 있다. “서버가 전부 사라졌다”가 아니다. 냉장고를 비행기에 못 들고 타듯, 여전히 서버나 컨테이너가 더 맞는 일이 있다.

Cloudflare Workers의 제약도 같이 봐야 한다.

  • 메모리: isolate당 128MB
  • Worker size: uncompressed 64MiB
  • startup time: 전역 스코프 실행 1초 이내
  • Free plan CPU time: HTTP request당 10ms
  • Paid plan CPU time: 기본 30초, 설정으로 최대 5분
  • 동시에 response header를 기다리는 open connection: invocation당 6개

이 숫자들이 말하는 건 단순하다. 요청을 오래 붙잡고, 메모리에 큰 것을 올리고, 시작할 때 무거운 초기화를 하고, 많은 연결을 동시에 열어두는 앱은 조심해야 한다.

서버에 남기는 편이 좋은 예시는 이렇다.

작업 이유
긴 동영상 인코딩 CPU와 실행 시간이 맞지 않는다.
큰 ML 모델 직접 로딩 메모리와 startup time에 걸릴 가능성이 높다.
대형 Django admin/ERP 세션, DB, 파일, 플러그인 가정이 무겁다.
로컬 디스크를 전제로 한 처리 Worker 런타임과 맞지 않는다.
긴 배치 작업 Queues, Workflows, 별도 서버로 쪼개는 편이 낫다.

반대로 Worker에 잘 맞는 건 요청 단위가 짧고, 상태를 외부 바인딩에 맡기고, 응답이 명확한 일이다.

내가 실제로 설계한다면

작은 제품이나 내부 도구를 만든다면 이렇게 시작할 것 같다.

1. 프론트는 정적 자산, API는 FastAPI

Astro, Vite, React 같은 프론트엔드는 정적으로 빌드한다. Worker에는 Static Assets를 붙인다. /api/*는 FastAPI가 처리하고, 나머지는 정적 자산으로 넘긴다.

이 구조는 단순하다.

  • / → 정적 HTML
  • /assets/* → 정적 파일
  • /api/search → FastAPI
  • /api/contact → FastAPI
  • /api/webhook/github → FastAPI

프론트와 API를 따로 배포하지 않아도 되니 작은 프로젝트에서는 운영 면이 깔끔하다.

2. DB는 앱 안에 숨기지 말고 바인딩으로 본다

D1, KV, R2, Queues 같은 저장소는 Worker의 바인딩으로 붙인다. Django ORM을 그대로 쓰는 꿈은 잠깐 접어두고, 이 API가 어떤 저장소에 어떤 단위로 접근하는지 먼저 정한다.

  • key-value 설정: KV
  • 관계형 작은 데이터: D1
  • 파일: R2
  • 오래 걸리는 후처리: Queues 또는 Workflows
  • 여러 요청의 상태 조율: Durable Objects

이렇게 나누면 Python 코드는 웹 요청의 흐름을 잡고, 플랫폼은 상태와 실행을 맡는다.

3. 전역 스코프를 가볍게 둔다

Worker startup time 제한 때문에 top-level에서 큰 일을 하면 안 된다. 큰 설정 파일 파싱, 거대한 스키마 생성, 무거운 클라이언트 초기화는 배포나 시작 시간을 망칠 수 있다. “앱 켜질 때 다 준비해두자”는 서버식 습관을 줄여야 한다.

Worker에서는 이렇게 생각하는 편이 낫다.

전역 스코프는 현관이다.
현관에 냉장고를 두지 말자.

필요한 초기화는 요청 안에서 늦게 하거나, 빌드 타임으로 옮기거나, 작은 캐시만 둔다.

개발자가 노트북 옆 체크리스트를 보며 작은 Python API를 엣지에 올릴지 판단하는 사실적인 장면

오늘 적용할 한 가지

Python으로 만든 작은 API가 있다면, 오늘 바로 이 기준으로 분류해보면 된다.

질문 예면 Worker 후보
요청 하나가 1~2초 안에 끝나는가? 예
큰 파일을 메모리에 통째로 올리지 않는가? 예
필요한 패키지가 순수 Python/Pyodide/PyEmscripten 쪽인가? 예
상태를 KV/D1/R2/Queues 같은 외부 저장소로 뺄 수 있는가? 예
서버 프로세스나 로컬 디스크에 기대지 않는가? 예

5개 중 4개가 예라면, FastAPI + Python Workers로 실험해볼 만하다. 2개 이하라면 서버가 더 낫다. 도구를 잘 쓰는 건 새 장난감을 모두 꺼내는 게 아니라, 맞는 서랍에 넣는 것이다.

FAQ

Python Workers에서 FastAPI를 진짜 쓸 수 있나?

Cloudflare 공식 문서 기준으로 가능하다. FastAPI는 ASGI 앱이고, Python Workers는 workers.asgi 어댑터를 제공한다. Default = asgi.entrypoint(app) 형태로 Worker entrypoint에 연결한다.

Django 전체를 Cloudflare Workers로 옮겨도 되나?

작은 Django API나 일부 endpoint는 후보가 될 수 있다. 하지만 기존 대형 Django 모놀리스, admin 중심 백오피스, 복잡한 DB/파일 의존성이 있는 앱은 바로 옮기기보다 기능 단위로 잘라서 검토하는 편이 안전하다.

Python 패키지는 전부 설치되나?

아니다. Python Workers는 순수 Python 패키지, PyEmscripten wheel, Pyodide 포함 패키지를 지원한다. WebAssembly 기반 패키지 지원은 아직 초기 단계라, 바이너리 의존성이 큰 패키지는 먼저 확인해야 한다.

기존 Wrangler를 쓰나, pywrangler를 쓰나?

Python Workers 문서는 pywrangler를 안내한다. pywrangler는 Python Workers의 패키지와 배포 환경을 잡아주는 wrapper이며, 내부적으로 Wrangler 명령들도 지원한다. 예시는 uv run pywrangler dev, uv run pywrangler deploy 흐름이다.

언제 Workers보다 서버가 낫나?

긴 CPU 작업, 큰 메모리 사용, 무거운 시작 초기화, 로컬 디스크 의존, 복잡한 Django admin/ERP 같은 경우는 서버나 컨테이너가 더 맞다. Worker는 짧고 명확한 요청 처리, 엣지 가까운 API, 정적 프론트 뒤의 얇은 백엔드에 잘 맞는다.

출처와 기준시점

기준시점: 2026-09-09 KST. 이 글은 아래 공식 문서와 발표를 바탕으로 작성했다.

← 글 목록