안녕하세요. 글쓰는 개발자 입니다.
약 2년 간 Django 를 사용했던 제가 이번 신규 프로젝트의 프레임워크로 FastAPI를 선택했습니다. 그 과정에서 여러 고민이 있었는데요. 제가 FastAPI 사용 결정을 내리는 동안 Django 와 어떤 것이 다른 지 정리한 것을 소개합니다.
Intro
Django
Dynamic Website 개발을 위한 Fullstack Web Framework 입니다. Fullstack인 만큼 방대한 기능을 보유하고 있습니다. 내장 ORM과 DB migration 덕분에 model을 쉽게 관리 할 수 있습니다. 또한, 높은 보안성 으로부터 cross-site scripting, SQL injecttion 등의 위험으로부터 안전합니다.
Instagram 개발에 사용되었을 정도로 신뢰성 있는 Framework 이며, Python 개발자라면 누구나 들어봤을 정도로 오래됐고, 유명하며, 가장 큰 커뮤니티를 보유하고 있습니다.
본래 Django는 Template을 내장하고 있는 MVT Pattern을 지원하는데 Restful API 통신을 하는 modern Frontend 시대에는 적합하지 않습니다. 또한, RDBMS와의 높은 결합성(highly coupled) 때문에 NoSQL을 적용하기 매우 어렵습니다.
Django REST Framework
Django에서 부족한 Restful API 통신을 위해 만들어졌습니다. Django 를 기반으로 동작하며, Automatic API documentation의 시초라 할 수 있습니다. View 계층에서 get, post, put, delete 로 method 를 작성하면, 같은 이름의 HTTP Method 를 사용하는 Restful API의 Endpoint가 됩니다.
참고로 Django REST Framework의 창시자 Tom Christie는 FastAPI의 base인 Starlette와 Uvicorn을 만들었습니다. 그야말로 Python Web 개발 생태계에 가장 영향력 인물 중 하나라고 볼 수 있을 것 같습니다.
Flask
Django가 Fullstack Framework 라면, Flask는 그야말로 micro 입니다. DB Integration을 비롯해서 Default로 제공되는 것이 상당 수 없습니다. 이러한 simplicity, flexibility 덕분에 NoSQL을 main Storage System으로 쓸 수 있습니다. 주로 Django에서 제공하는 기능이 필요 없는 application을 개발 할 때 많이 쓰이며, 필요한 것은 plugin을 통해 추가 가능합니다.
FastAPI
위에서 언급한 Python 진영의 유서깊은 3개의 프레임워크로 부터 받은 영감에서 출발한 프레임워크 입니다. 최신 Web Framework 중 하나이며, ASGI를 기반으로 만들어졌습니다. 가장 빠른 Python Web Framework인 Starlette를 base로 합니다. 비동기적 방식으로 작동하기 떄문에 처리 속도가 매우 빠르고 덕분에 많은 요청을 동시에 처리 할 수 있도록 해줍니다. Swagger와 같은 API 문서 생성 도구를 자동으로 제공하기 때문에 협업에 큰 도움이 됩니다. FastAPI 창시자에 의하면, FastAPI를 만들 때 "Flask 를 위한 Django REST Framework 를 만드는 것" 을 목표로 했다고 합니다. 확장 가능한 Micro Framework 를 유지하고 편리하고 사용하기 쉬운 routing system을 쓰면서, 필요한 tools와 parts를 mix and match를 통해 만듭니다.
Django VS FastAPI
Intro에서 4개의 Framework 를 간략히 살펴 보았습니다. 이번에는 Django, Django REST Framework 와 FastAPI 를 각각의 장단점으로 비교해보겠습니다.
장점
Django, Django REST Framework
- 완전한 패키지 제공: ORM 등 뿐만 아니라 다국어 지원을 제공하여, 실무에서 큰 도움을 받았음
- 높은 보안성: CSRF, SQL Injection 등을 개발자들이 신경쓰지 않고 비즈니스 로직에 집중 할 수 있음
- 커뮤니티: 가장 오래되었고 가장 유명한 Framework 답게 왠만한 것들은 구글링으로 해결 할 수 있음
- Django Models: Model 기반이기 때문에 탄력있는 개발이 가능하고 CRUD 개발도 가능
- Serializer: 편리한 serializing data source
FastAPI
- 높은 성능: Starlette, uvicorn base로 비동기 방식으로 작동하기 때문에 처리속도가 매우 빠름.
- 편리한 작성: Swagger를 자동으로 제공하기 때문에 API 문서 작성에 들이는 시간을 크게 줄일 수 있음
- 타이핑 제공: FastAPI는 Type Hint를 지원하며, 잘못된 인자를 전달하는 것을 방지
- 공식 문서: 초보자 Tutorial, Advanced 과정 등 공식 문서가 일목요연하게 잘 정리되어 있음
- Validation: Pydantic 과 Type Hint 기반으로 data의 validate, serialize - deserialize 가능
- Concurrency: Python 3.4 이후에 추가된 Async I/O 덕분에 event loop와 async/await 관리를 하지않아도 됨
- Dependency Injection: 의존성 주입 솔루션이 내장되어 Class 간 의존성이 줄어들고 모듈화, 확장이 용이한 상태
단점
Django, Django REST Framework
- 커뮤니티가 크고 공식문서가 잘 되어 있어서 배우기 쉽다고 하지만, 실제로 느껴지기에 기능이 방대한 만큼, 러닝 커브가 낮고 배우기 힘듬
- Django Model과 Django REST Framework 가 제공하는 Serializer는 매우 편리하지만 성능 문제를 야기시킬 수 있음
- Model Serializer를 사용하여 CRUD 를 모두 처리 할 수 있지만 가독성이 떨어짐
- Django REST Framework의 경우, GenericView, APIView 등 사용법이 제각각
- 비동기를 지원하지 않음 (Django Asyncronous)
FastAPI
- 아직 버전 1.0을 찍지 못했기에 불완전한 Framework 라는 생각이 듬
- FastAPI security를 제공하지만 Django의 보안성에 비하면 아직은 부족
- 생긴지 얼마 되지 않은 만큼 커뮤니티가 부족함
- 가벼워서 편리하지만, ORM 사용을 위해 sqlalchemy 사용, db migration을 위해 alembic 설치, validation을 위한 Pydnatic 설치 등 다양한 의존성을 직접 관리해야 함
Why FastAPI?
분명 어느 한 프레임워크가 특별한 우위를 갖는 것이 아니라, 장 단점을 동시에 가지고 있습니다. 그렇다면 저는 왜 신규 프로젝트의 프레임워크로 FastAPI를 선택했을까요? 그 답은 프로젝트의 성격에 있습니다.
저는 MLOps Platform의 아키텍처 설계 중 기술 스택을 선정해야 했습니다. 전체 프로젝트 구조는 MSA 구조이며, 저는 ML Engine 부분을 FastAPI로 결정했습니다. 일반적인 로그인, 회원가입, 게시판 관련 기능을 다루지 않으며, 오직 Machine Learning Pipeline 만을 다룹니다. Java / Spirngboot 기반의 Web Backend와 상호 작용하며, kubeflow를 활용해 Machine Learning Pipeline을 구축합니다. 그렇기 때문에 저는 Django, Django REST Framework의 무엇이 필요 없고, FastAPI의 무엇이 필요한지 도출 할 수 있었습니다.
Async I/O
학습을 위해 방대한 Data를 처리해야 하는 ML Engine 특성 상 Async I/O 를 지원한다는 사실만으로도 Django가 아닌 FastAPI를 선택한 충분한 이유였습니다.
Validation
비동기 처리, 속도와 더불어 가장 큰 이유 입니다. Pydantic, Type Hint 기반으로 알아서 validation 처리가 되고 type hint 덕분에 IDE에서도 강력한 성능을 얻을 수 있습니다.
Performance
Starlette를 제외하면 가장 빠른 Python Framework 입니다. 그리고 FastAPI는 Starlette 기반입니다.
DB
Django의 강력한 ORM과 Serializer, migration이 불필요 했습니다. DataBase와의 상호작용은 Web Backend에서 대부분 담당할 것이기 때문입니다.
또한, 실제로 써보니 Django ORM 보다, sqlalchemy의 문법이 더 직관적이고 문서화가 잘되어 있다고 느꼈으며, db migration의 경우, alembic이 훨씬 편했습니다. 초기 설정의 번거로움이 있지만, migration의 revision hash를 따라 db version control을 upgrad, downgrade 명령만으로 처리 가능기에 훨씬 편리하게 느껴졌습니다.
Pydantic
Django Serializer는 Pydantic이 충분히 대체할 수 있으며, 더 편하게 사용 할 수 있습니다.
결론
FastAPI와 Django는 각각의 장단점을 가지고 있습니다. FastAPI는 높은 성능과 간단한 작성법을 제공합니다. 반면 Django는 완전한 패키지와 커뮤니티, 보안성을 제공합니다. 저희 팀이 Web Backend는 Java/Spring을 선택하고 ML Engine은 FastAPI를 선택한 것 처럼 개발자들은 애플리케이션의 요구 사항과 개발자의 우선순위에 따라 프레임워크를 선택해야 합니다. 제가 ML Engine의 프레임워크를 선택하기위해 조사한 것과 고민의 흐름이 여러분들의 선택에도 도움되셨으면 좋겠습니다.
참고자료
https://docs.djangoproject.com/en/4.1/topics/async/
https://fastapi.tiangolo.com/alternatives/