왜 나는 FastAPI가 아니라 Django + Pydantic + HTMX를 택했는가

한 줄 결론

내가 FastAPI를 기본값으로 두지 않는 이유는 속도 때문이 아니라 제품 전체를 이루는 구조가 Django 쪽에서 더 자연스럽게 닫히기 때문이다.

FastAPI가 잘하는 것

먼저 분명히 하자. FastAPI는 좋은 도구다.

• JSON API 중심 설계에 잘 맞는다
• 타입 힌트와 문서화 경험이 좋다
• 작은 서비스나 독립 API를 빠르게 만드는 데 유리하다

문제는 내가 만드는 제품이 대개 거기서 끝나지 않는다는 점이다.

내가 실제로 필요한 것

내가 자주 만드는 것은 단순 API가 아니라 제품이다. 그러면 보통 이런 것들이 같이 따라온다.

• 관리자 화면
• 인증과 세션
• 폼과 서버 렌더링
• 배경 작업
• ORM과 마이그레이션
• 템플릿과 페이지 조각
• 도메인 단위로 묶인 기능 개발

이때 Django는 단순히 오래된 프레임워크가 아니라, 제품을 만드는 데 필요한 기본 부품을 이미 충분히 갖춘 프레임워크다.

Pydantic은 왜 같이 쓰나

여기서 중요한 건 “Django를 쓰니까 Pydantic이 필요 없다”가 아니라는 점이다. 오히려 반대다.

나는 Django 위에서 Pydantic을 쓴다. 이유는 명확하다.

• 요청과 응답 계약을 명시할 수 있다
• 도메인 간 통신 포맷을 고정할 수 있다
• AI 출력도 같은 방식으로 검증할 수 있다
• 타입 힌트만으로는 부족한 제약을 코드에 선언할 수 있다

즉 Django는 제품의 뼈대를 맡고, Pydantic은 계약의 선을 또렷하게 그린다.

HTMX를 같이 두는 이유

프론트엔드까지 생각하면 더 분명해진다.

React 같은 SPA는 분명 강력하지만, Django 기반 제품에서 항상 가장 자연스러운 선택은 아니다. 내가 원하는 것은 종종 이런 것이다.

• 서버가 상태를 더 많이 책임진다
• 페이지 일부만 교체하면 된다
• 템플릿과 비즈니스 흐름이 가까이 붙어 있다
• 팀 규모가 작아도 빠르게 움직일 수 있다

이 조건에서는 HTMX가 매우 실용적이다. HTMX는 프론트엔드를 없애는 도구가 아니라, 프론트엔드의 복잡도를 서버와 다시 균형 있게 나누는 도구에 가깝다.

결국 내가 택하는 조합

내 기준에서 이 조합은 역할이 분명하다.

• Django: 제품의 운영 뼈대
• Pydantic: 계약과 검증
• HTMX: 과도한 프론트엔드 복잡도 없이 상호작용 추가

FastAPI는 여전히 좋은 선택지다. 하지만 내가 자주 만드는 구조에서는 API만 잘 만드는 프레임워크보다, 페이지와 데이터와 운영 흐름이 함께 닫히는 프레임워크가 더 중요하다.

그래서 내 기본값은 FastAPI가 아니라 Django + Pydantic + HTMX다.