FastAPI 도입 후 Django REST Framework와 비교

배경

기존 Django REST Framework로 운영 중인 API 서버가 있었지만, 새로운 마이크로서비스는 FastAPI로 작성하기로 결정했다. 비동기 처리가 필요한 외부 API 호출이 많고, 타입 힌트 기반의 자동 문서화가 매력적으로 느껴졌기 때문이다.

개발 경험

타입 힌트와 Pydantic

FastAPI의 가장 큰 장점은 Pydantic 기반의 타입 검증이었다. 요청/응답 스키마를 정의하면 자동으로 검증과 문서화가 이루어졌다.

from pydantic import BaseModel
from fastapi import FastAPI

app = FastAPI()

class UserCreate(BaseModel):
    email: str
    name: str
    age: int

@app.post("/users/")
async def create_user(user: UserCreate):
    return {"email": user.email, "name": user.name}

DRF에서는 Serializer를 별도로 작성하고 is_valid() 체크를 해야 했는데, FastAPI는 이 과정이 자동화되어 있었다.

비동기 처리

외부 API를 호출하는 엔드포인트가 많았는데, async/await 문법을 자연스럽게 사용할 수 있었다.

import httpx

@app.get("/external-data/{item_id}")
async def get_external_data(item_id: int):
    async with httpx.AsyncClient() as client:
        response = await client.get(f"https://api.example.com/items/{item_id}")
    return response.json()

Django 3.1에서 비동기 뷰가 추가되긴 했지만, ORM과의 통합이 완벽하지 않아 실제로 사용하기 애매했다.

성능

간단한 부하 테스트 결과, 동일한 로직에서 FastAPI가 약 2~3배 빠른 응답 속도를 보였다. ASGI 기반이라 동시 요청 처리에서 특히 차이가 났다.

아쉬운 점

Django의 강력한 ORM과 Admin 패널은 여전히 매력적이다. FastAPI는 가볍고 빠르지만, 인증/권한, DB 마이그레이션 등은 직접 구성해야 했다. SQLAlchemy와 Alembic을 함께 사용했지만 Django ORM만큼 편하진 않았다.

결론

API 전용 서비스라면 FastAPI가 충분히 좋은 선택이었다. 타입 안정성과 성능, 자동 문서화는 확실한 장점이다. 하지만 풀스택 프레임워크가 필요하거나 빠른 프로토타이핑이 목적이라면 여전히 Django가 유리하다고 생각한다.