← 블로그
DAEMON Backend 01 · ·KO

Django DRF vs Django Ninja vs FastAPI — 내가 무엇을 언제 고르는가

djangodrfdjango-ninjafastapiarchitecture

한 줄 결론

내 기준은 단순하다.

  • DRF는 이미 Django 기반 CRUD와 권한 체계가 무거운 프로젝트에서 좋다.
  • Django Ninja는 Django 생태계를 유지하면서 더 가볍고 빠르게 API를 만들고 싶을 때 가장 균형이 좋다.
  • FastAPI는 처음부터 API 중심 시스템으로 설계하고, Django의 ORM/관리자/생태계를 크게 필요로 하지 않을 때 선택할 수 있다.

즉, 나는 기본적으로 Django Ninja를 우선 보고, 특정 조건에서만 DRF나 FastAPI로 간다.

이 비교가 중요한 이유

많은 글이 세 프레임워크를 벤치마크 숫자로만 비교한다. 하지만 실제 제품을 만들 때 더 중요한 것은 다음이다.

  • 내가 이미 가진 코드베이스와 얼마나 잘 맞는가
  • 운영 복잡도를 얼마나 늘리는가
  • 팀이 얼마나 빨리 이해하고 유지보수할 수 있는가
  • 인증, 권한, 관리자 화면, ORM, 배포 구조까지 포함해서 전체 시스템이 얼마나 자연스럽게 이어지는가

프레임워크는 성능 숫자 하나로 고르는 것이 아니라, 제품 전체의 마찰 비용으로 고르는 것이다.

Django DRF

DRF는 강력하다. 특히 이런 상황에서 강하다.

  • Django 모델이 이미 많다
  • 관리자 화면과 권한 체계를 이미 쓰고 있다
  • serializer, permission, viewset 패턴에 익숙한 팀이다
  • 조직이 “정석 Django 방식”을 선호한다

장점은 분명하다.

  • 생태계가 매우 넓다
  • 조직 내에서 설명하기 쉽다
  • 인증/권한/serializer 체계가 명확하다

하지만 내가 DRF를 자주 기본 선택으로 두지 않는 이유도 분명하다.

  • serializer, viewset, router 구조가 생각보다 무겁다
  • 작은 API에도 보일러플레이트가 늘어난다
  • AI-assisted coding 환경에서 파일 간 분산이 커져 응집도가 떨어지기 쉽다

즉 DRF는 좋은 도구지만, 작고 빠른 제품을 반복적으로 만들 때는 과할 수 있다.

Django Ninja

Django Ninja는 내가 가장 자주 고르는 지점에 있다.

좋은 이유는 다음이다.

  • Django ORM과 관리자 화면을 그대로 쓸 수 있다
  • 타입 힌트와 Pydantic 기반으로 입력/출력 구조가 명확하다
  • API 정의가 비교적 짧고 읽기 쉽다
  • DRF보다 훨씬 가볍게 API를 열 수 있다

특히 AI 제품을 만들 때 중요했던 점은 응답 구조를 명확히 다룰 수 있다는 것이다.

Pydantic 기반 스키마는 단순히 개발자 취향 문제가 아니다.

  • AI 출력 검증
  • 명시적인 request/response 모델
  • 타입 기반 유지보수

이 세 가지가 합쳐지면 운영 안정성이 올라간다.

내가 DAEMON 계열 프로젝트에서 Django Ninja를 선호하는 이유는, Django의 장점은 유지하면서도 API 레이어를 훨씬 덜 무겁게 만들 수 있기 때문이다.

FastAPI

FastAPI는 분명 좋은 프레임워크다.

다만 내가 보는 FastAPI의 좋은 조건은 이렇다.

  • 처음부터 API-only 제품이다
  • Django 관리자 화면이 필요 없다
  • Django ORM과 기존 Django 자산이 중요하지 않다
  • 비동기 흐름, 서비스 분리, 독립 API 레이어가 더 중요하다

FastAPI는 빠르고, 문서화가 좋고, 구조가 명확하다. 하지만 한국에서 많은 개인/소규모 제품 개발은 생각보다 Django가 더 편하다.

왜냐하면 현실에서는 API 프레임워크만 필요한 것이 아니라,

  • 관리자 화면
  • ORM
  • 인증
  • 마이그레이션
  • 배포 편의성

까지 다 필요하기 때문이다.

FastAPI만 고르면 API는 예뻐질 수 있지만, 주변 기능을 다시 조합하는 비용이 생긴다.

내 선택 기준

DRF를 고를 때

  • 이미 DRF 코드베이스가 있다
  • 복잡한 권한 체계와 익숙한 조직 패턴이 중요하다
  • 팀 전체가 DRF 관성 위에서 움직인다

Django Ninja를 고를 때

  • Django 생태계를 유지하고 싶다
  • 하지만 DRF보다는 더 가볍고 명확한 API 레이어가 필요하다
  • Pydantic 기반 입력/출력 검증이 중요하다
  • 혼자 혹은 작은 팀이 빠르게 제품을 만들어야 한다

FastAPI를 고를 때

  • Django 관리자/ORM에 크게 의존하지 않는다
  • API 중심 시스템으로 시작한다
  • 향후 독립 서비스화 가능성이 높다
  • 프레임워크보다 API 레이어 자체를 중심으로 설계한다

내 현재 결론

나는 대부분의 제품 개발에서 다음 순서로 생각한다.

  1. Django Ninja로 충분한가?
  2. 아니면 이미 DRF 구조를 유지해야 하는가?
  3. 처음부터 FastAPI가 더 자연스러운 서비스인가?

그리고 대부분의 경우 1번에서 끝난다.

DRF는 나쁘지 않다. FastAPI도 나쁘지 않다. 하지만 내 작업 방식, 제품 성격, 운영 현실을 모두 고려하면 Django Ninja가 가장 높은 균형점에 있다.

마무리

프레임워크 선택은 “무엇이 더 힙한가”의 문제가 아니다.

  • 무엇이 내 제품에 맞는가
  • 무엇이 유지보수 가능한가
  • 무엇이 운영 마찰을 줄이는가

이 기준으로 봐야 한다.

내 기준에서 Django Ninja는 Django의 실용성과 타입 기반 API 설계 사이를 가장 잘 잇는 선택이다.