클라우드플레어 파이썬 워커스 정식 출시 — FastAPI·Django가 엣지에서 그대로 돈다

WHAT HAPPENED무슨 일이 있었나

클라우드플레어는 이번 발표에서 "GA가 무엇을 뜻하느냐"를 직접 설명했다. 파이썬이 클라우드플레어 개발자 플랫폼에서 완전히 지원되는 1급 언어가 됐고, 이미 알고 있는 파이썬 코드·라이브러리·설계 패턴을 그대로 가져와 Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, Workflows 등에 연결할 수 있다는 것이다. 다른 워커 안에서 파이썬 워커를 만드는 Dynamic Workers도 지원한다고 밝혔다.

글은 Gyeongjae Choi, Dominik Picheta, Hood Chatham 세 사람이 썼다. 이 중 Hood Chatham은 이번에 채택된 PEP 783의 저자이기도 하다. 클라우드플레어는 2018년부터 워커스에서 웹어셈블리를 지원해 왔고, 그 위에서 웹어셈블리로 컴파일한 파이썬 인터프리터인 Pyodide를 돌리는 방식으로 파이썬 워커스를 만들어 왔다. 이번 GA는 그 다년간 작업을 "모두가 프로덕션에서 쓸 수 있는 상태"로 묶어 낸 것이라고 설명한다.

KEY CHANGES핵심 변화 네 가지

가장 체감이 큰 부분은 바인딩이다. 베타 시절에는 큐에 딕셔너리 하나를 보내려 해도 to_js(..., dict_converter=js.Object.fromEntries) 같은 접착 코드가 필요했다. 클라우드플레어는 이것이 "사람과 AI 에이전트 모두에게 흔한 오류 원인"이었다고 인정하고, 타입 변환 전체를 런타임과 파이썬 SDK 안으로 숨겼다.

from fastapi import FastAPI
from workers import asgi, WorkerEntrypoint

app = FastAPI()

@app.get("/")
async def root():
    return {"message": "Hello, world!"}

# uvicorn 대신 이 한 줄로 워커 진입점이 된다
Default = asgi.entrypoint(app)

웹 프레임워크 지원은 ASGI·WSGI라는 파이썬 표준 인터페이스를 활용한다. 일반 배포에서는 uvicorn이나 gunicorn 같은 웹 서버가 동시 연결과 스레드를 관리하지만, 워커스에서는 플랫폼 자체가 웹 서버 역할을 한다. 커넥터는 들어온 JS 요청을 ASGI·WSGI 구조로 번역하고 응답을 다시 내보내는 얇은 다리일 뿐이라는 설명이다. 그래서 FastAPI·Django·Flask뿐 아니라 이 인터페이스를 따르는 다른 프레임워크도 쓸 수 있다.

UNDER THE HOOD기술적으로 어려웠던 지점: 소켓과 패키지

데이터베이스 지원이 늦었던 이유는 웹어셈블리 샌드박스의 구조에 있다. asyncpg나 aiomysql 같은 드라이버는 표준 라이브러리의 socket 모듈을 쓰고, socket 모듈은 운영체제에 POSIX 시스템콜을 던진다. 그런데 웹어셈블리 샌드박스 안에서 이런 네트워킹 시스템콜은 항상 실패하는 빈 껍데기다. 클라우드플레어는 이 시스템콜 자체를 Workers의 connect API로 구현해, 드라이버가 아무것도 모른 채 TCP 연결을 열 수 있게 했다. 이 "소켓 다리"가 Hyperdrive 연동의 토대다.

같은 문제가 AI 라이브러리에도 걸려 있었다. openai나 langchain은 requests·httpx 같은 HTTP 클라이언트에 기대는데, 저수준 소켓이 없으니 제대로 동작하지 않았다. 클라우드플레어는 이 HTTP 클라이언트들이 웹어셈블리 환경에서 JS fetch API로 요청을 보낼 수 있도록 업스트림에 기여했고, 그 결과 openai, langchain, mcp 패키지를 파이썬 워커스에서 그대로 쓸 수 있게 됐다고 밝혔다.

패키지 생태계는 이번 발표에서 장기적으로 가장 중요한 대목이다. C·C++·러스트 확장이 들어 있는 패키지는 웹어셈블리로 교차 컴파일해야 하는데, 지금까지는 표준 방법이 없어 클라우드플레어 팀이 손으로 빌드해 올려 둔 패키지만 쓸 수 있었다. 클라우드플레어는 브라우저 계열 런타임에서 파이썬을 돌리는 플랫폼을 PyEmscripten으로 표준화하는 PEP 783을 제안했고, 1년 넘는 논의 끝에 채택됐다. PEP 페이지 기준으로 상태는 Accepted, 결정일은 2026년 4월 6일이다. 여기에 Pyodide 빌드 도구를 안정화하고 cibuildwheel에 PyEmscripten 지원을 넣어, 패키지 메인테이너가 직접 휠을 만들 수 있게 했다.

IMPACT개발자에게 미치는 영향

파이썬으로 서버리스를 하던 사람들의 선택지는 대체로 AWS 람다 같은 컨테이너·프로세스 기반 함수였다. 파이썬 워커스는 V8 아이솔레이트 위의 웹어셈블리라는 전혀 다른 실행 모델이고, 그 차이가 이번 GA로 많이 메워졌다. 다만 모든 것이 그대로 옮겨진다는 뜻은 아니다. 네이티브 확장 패키지는 PyEmscripten 빌드가 있어야 하고, DB 연결은 Hyperdrive라는 클라우드플레어 서비스를 거친다. 도입 전에 쓰는 의존성 목록부터 확인하는 것이 순서다.

클라우드플레어는 다음 과제로 파이썬 워커스의 성능과 메모리 효율 개선, 더 많은 패키지 지원을 꼽았다. 개발자 문서 전반에 타입스크립트 예제가 있는 곳 대부분에 파이썬 예제도 추가했다고 밝혔다. 실제로 이 런타임이 파이썬 서버리스의 주류 선택지가 될지는 패키지 호환성이 얼마나 빨리 넓어지느냐에 달려 있다.

자주 묻는 질문

클라우드플레어 파이썬 워커스는 언제 정식 출시됐나?

클라우드플레어는 2026년 9월 21일(현지시간) 공식 블로그에서 파이썬 워커스의 정식 출시(GA)를 발표했다. 처음 공개된 것은 약 2년 전이며, 이번 GA로 파이썬이 타입스크립트와 같은 1급 지원 언어가 됐다.

파이썬 워커스에서 FastAPI나 Django를 쓸 수 있나?

쓸 수 있다. FastAPI처럼 ASGI 앱은 workers.asgi, Django처럼 WSGI 앱은 workers.wsgi 커넥터로 연결한다. 커넥터는 워커 요청을 ASGI·WSGI 구조로 번역하는 얇은 계층이라 앱 코드는 거의 바꾸지 않아도 된다.

파이썬 워커스에서 PostgreSQL이나 MySQL에 연결할 수 있나?

Hyperdrive를 거치면 가능하다. 클라우드플레어가 웹어셈블리 안의 소켓 시스템콜을 Workers connect API로 구현해 aiomysql 같은 드라이버가 TCP 연결을 열 수 있게 됐다. 지원 패키지 목록은 Hyperdrive 파이썬 문서에서 확인해야 한다.

PEP 783은 무엇이고 왜 중요한가?

PEP 783은 브라우저 계열 런타임에서 파이썬을 실행하는 PyEmscripten 플랫폼을 표준화한 제안으로, 2026년 4월 채택됐다. 패키지 메인테이너가 네이티브 확장을 웹어셈블리용 휠로 직접 빌드·배포할 수 있게 해, 파이썬 워커스뿐 아니라 Pyodide 생태계 전체의 패키지 폭을 넓힌다.

참고 자료

• Cloudflare Blog — Python Workers are now generally available
• PEP 783 – Emscripten Packaging