FastAPI는 Starlette(경량 ASGI 프레임워크) 위에 구축되어 async 네이티브이므로, 많은 동시 I/O 바운드 요청을 효율적으로 처리하여 가장 빠른 Python 프레임워크 중 하나입니다. 하지만 그 속도를 유지하려면 async를 올바르게 사용해야 합니다. 가장 흔한 실수는 이벤트 루프를 막는 것입니다.
✓ ASGI + Starlette — 현대적 async 기반 (오래된 WSGI 동기 프레임워크 대비)
✓ async 네이티브 — 하나의 프로세스가 대기 시간을 겹쳐서 수천 개의 동시
I/O 바운드 요청을 한 번에 하나씩이 아니라 처리
✓ Pydantic v2 — validation/직렬화 코어가 이제 Rust로 작성됨 (매우 빠름)
✓ 요청당 최소한의 오버헤드
async 모델이 핵심입니다: 한 요청이 데이터베이스 쿼리나 API 호출을 기다리는 동안 서버는 다른 요청을 처리합니다. I/O 바운드 워크로드에 높은 처리량을 제공합니다.
# ❌ async def 내부의 블로킹 호출 → 이벤트 루프를 멈춰 모든 요청을 직렬화
@app.get("/bad")
async def bad():
return requests.get(url).json() # 동기/블로킹 → 동시성을 무력화
# ✅ async 클라이언트를 사용하고 await
@app.get("/good")
async def good():
async with httpx.AsyncClient() as c:
return (await c.get(url)).json() # 논블로킹
# ✅ 또는 일반 def 사용 — FastAPI가 스레드 풀에서 실행 (블로킹 코드에 안전)
@app.get("/also-good")
def also_good():
return requests.get(url).json()
이것이 가장 중요한 성능 규칙입니다: async def 안의 블로킹 호출은 전체 이벤트 루프를 막아, 요청이 한 번에 하나씩 실행되도록 강제합니다. async 라이브러리를 await와 함께 사용하거나, 일반 def(스레드 풀에서 실행)를 사용하세요.
✓ async 엔드포인트에서 async DB 드라이버 / async 라이브러리(httpx, asyncpg) 사용
✓ 블로킹 코드는 일반 def(스레드 풀)에서 또는 run_in_executor로 실행
✓ 무거운 CPU 작업을 이벤트 루프에서 피함 → 워커/프로세스로 오프로드
✓ 비싼 반복 작업에 캐싱(Redis) 추가
✓ 데이터베이스 최적화 (N+1 수정, 인덱스 추가) — 흔히 진짜 병목
✓ 여러 워커 프로세스 실행 (uvicorn/gunicorn 워커)으로 모든 CPU 코어 활용
✓ 커넥션 풀링 사용; 큰 결과는 페이지네이션
✓ 먼저 측정 (프로파일링, 부하 테스트) — 실제 병목을 수정
FastAPI의 속도는 팀이 이를 선택하는 주된 이유이지만, 실제로 그 속도를 달성하는 것은 async를 올바르게 사용하는 것에 달려 있으며, 가장 중요하고 자주 위반되는 규칙은 절대 이벤트 루프를 막지 않는 것입니다.
FastAPI가 왜 빠른지(async 네이티브 ASGI 기반, 효율적인 I/O 동시성, 빠른 Pydantic v2 코어)를 이해하면, 그 성능 우위가 동시적으로 처리되는 I/O 바운드 워크로드에 적용된다는 점이 분명해집니다.
속도를 유지하는 방법을 아는 것이 핵심 실용 기술입니다: async def에 블로킹 호출을 넣는 치명적 실수(멈춘 이벤트 루프 뒤에서 모든 요청을 직렬화)를 피하고, async 엔드포인트에서 async 라이브러리를 사용하며(또는 블로킹 코드에는 일반 def), CPU 작업을 오프로드하고, 캐싱하며, 데이터베이스를 최적화하고(흔히 진짜 병목), 여러 코어를 위해 여러 워커를 실행하는 것.
이 조합—async를 제대로 활용하고 측정으로 진짜 병목을 찾는 것—이 FastAPI의 성능 잠재력을 실현하게 합니다. async처럼 보이지만 블로킹 코드처럼 동작하는 API가 아니라 진정으로 빠르고 확장 가능한 API를 구축하기 위한 중요한 시니어 수준 지식입니다.