Cloudflare Python Workers GA, FastAPI가 된다고 서버가 그대로 옮겨지는 것은 아니다
Python Workers는 FastAPI·Django·Flask와 Cloudflare 바인딩을 정식 지원하지만 실행 환경은 일반 리눅스 서버가 아니라 Pyodide 기반 WebAssembly 격리 환경이다. 패키지 호환성, 상태 저장, CPU·메모리와 비용을 기준으로 적용 범위를 판단한다.
FastAPI 애플리케이션을 Uvicorn이나 컨테이너 없이 엣지에 배포할 수 있다면 선택지가 달라진다. Cloudflare는 Python Workers를 정식 출시하며 FastAPI, Django, Flask와 데이터베이스 드라이버까지 지원 범위를 넓혔다. 다만 기존 Python 서버를 그대로 옮길 수 있다고 보면 실행 환경의 차이를 놓치게 된다.
공식 발표는 2026년 9월 21일 게시됐고, GeekNews 항목은 9월 22일 오전 7시 36분(한국 시각)에 등록됐다. 이 글에서는 발표일과 피드 등록일을 구분해 읽었다.
정식 지원의 핵심은 웹 서버가 아니라 실행 경로다
Python Workers는 CPython을 WebAssembly로 컴파일한 Pyodide를 V8 격리 환경 안에서 실행한다. 요청을 받으면 별도의 Uvicorn이나 Gunicorn 프로세스를 띄우는 대신 Workers 플랫폼이 웹 서버 역할을 맡는다. workers.asgi와 workers.wsgi가 Workers의 요청과 응답을 Python 프레임워크의 ASGI·WSGI 규격으로 변환한다. 공식 실행 구조 문서와 GA 발표에서 확인할 수 있다.
이 구조 덕분에 FastAPI의 라우팅이나 Pydantic 모델 같은 애플리케이션 코드를 재사용할 여지가 생긴다. Queue, R2, D1, Durable Objects 같은 바인딩에 Python 객체를 넘길 때 필요했던 JavaScript 변환도 런타임과 SDK가 처리한다. 데이터베이스 드라이버의 소켓 호출은 Workers의 connect API로 이어지고, 공식 예제는 Hyperdrive를 통해 PostgreSQL과 MySQL에 연결한다.
내가 주목한 부분은 “Python도 실행된다”보다 경계 코드가 줄었다는 점이다. 반대로 이 연결이 Cloudflare의 런타임과 바인딩에 묶인다는 점은 이식성 비용으로 남는다.
같은 Python이어도 리눅스 프로세스는 아니다
가장 먼저 확인할 것은 의존성이다. 현재 패키지 문서는 순수 Python 패키지, PyEmscripten 휠이 배포된 패키지, Pyodide에 포함된 패키지를 지원한다고 설명한다. C·C++·Rust 확장을 사용하는 패키지는 일반적인 리눅스 휠만으로는 부족하고 WebAssembly용 빌드가 필요하다. 패키지 이름이 PyPI에 있다는 사실만으로 호환된다고 판단할 수 없다.
표준 라이브러리도 운영체제와 같은 조건이 아니다. 파일을 읽고 쓸 수 있지만 파일 시스템은 격리 인스턴스가 사라지면 함께 없어지는 메모리 영역이다. 여러 인스턴스가 공유하지도 않는다. 업로드 파일의 임시 변환에는 쓸 수 있어도 SQLite 파일이나 사용자 첨부물을 영구 보관하는 용도로는 맞지 않는다. 지속성이 필요하면 R2, KV, Durable Objects 같은 별도 저장소를 선택해야 한다.
Python 버전도 로컬 설치가 아니라 compatibility_date에 맞는 Pyodide 버전으로 정해진다. Cloudflare는 새 Pyodide를 호환성 날짜 뒤에 활성화해 기존 배포의 동작을 보존한다. 이는 예측 가능성을 높이지만, 로컬 Python만 올렸다고 운영 런타임도 같은 버전이 되는 구조는 아니다. 배포 설정과 잠금 파일을 함께 검토해야 한다.
작은 API에는 맞지만 계산 작업은 따로 봐야 한다
Workers의 제약은 Python에도 적용된다. 공식 제한은 격리 환경당 메모리 128MB이며 JavaScript 힙과 WebAssembly 할당을 합산한다. 무료 요금제의 HTTP 요청당 CPU 시간은 10ms다. 유료 요금제는 기본 30초이고 설정으로 최대 5분까지 늘릴 수 있다. 네트워크 응답을 기다리는 시간과 실제 CPU 실행 시간은 구분되지만, 데이터 프레임 처리나 이미지 변환처럼 메모리와 CPU를 많이 쓰는 작업은 작은 API와 조건이 다르다. Workers 제한 문서의 수치를 자체 요청으로 다시 측정해야 한다.
비용도 요청 수만 보면 부족하다. 공식 가격 문서 기준 유료 플랜은 계정당 월 최소 5달러이며 월 1,000만 요청과 CPU 3,000만 ms가 포함된다. 초과분은 요청 100만 건당 0.30달러, CPU 100만 ms당 0.02달러다. 여기에 R2, D1, Hyperdrive, Queues 같은 연결 서비스의 사용량을 더해야 실제 비용이 나온다.
따라서 짧은 인증 확인, 외부 API 조합, 웹훅 처리처럼 I/O 비중이 높은 API는 우선 검토할 만하다. 반면 네이티브 확장에 의존하는 분석 코드, 큰 파일을 한 번에 메모리에 올리는 처리, 로컬 디스크와 백그라운드 프로세스를 전제로 한 서비스는 컨테이너나 일반 서버가 더 단순할 수 있다.
전환은 프레임워크보다 의존성 표에서 시작한다
기존 서비스를 옮기기 전에는 엔드포인트 하나를 골라 다음 항목을 확인하는 편이 좋다.
- 직접·간접 의존성에 PyEmscripten 휠이나 Pyodide 빌드가 있는가
- 파일 시스템, 프로세스, 스레드, 소켓을 어떤 코드가 가정하는가
- 실제 입력 크기에서 CPU 시간과 최대 메모리가 얼마인가
- 데이터베이스 위치와 Hyperdrive 사용 여부에 따라 지연이 어떻게 달라지는가
- 요청, CPU, 저장소, 큐를 합친 월 비용이 현재 운영 방식보다 나은가
Python Workers GA는 Python 생태계와 엣지 런타임 사이의 간격을 줄였다. 그러나 도입 판단의 단위는 “FastAPI를 지원하는가”가 아니라 “이 엔드포인트의 의존성과 상태가 WebAssembly 격리 환경에 맞는가”여야 한다. 나는 새 API 전체를 한 번에 옮기기보다, 외부 요청을 조합하고 상태를 별도 저장소에 두는 작은 경로부터 비교하는 것이 합리적이라고 본다.
참고 자료
이 이야기가 도움이 되었나요?