[FastAPI] 0. 프로젝트 개요

 

 회사에서 Django를 사용해 Backend 개발을 한 지도 거의 2년이 되어가고 있습니다. 그 2년 중에서 제대로 써 본 것은 최근 5개월 정도 되는 것 같습니다. 많은 개발자들이 특정 기술을 사용할 때 반드시 적합한 이유가 있어야 한다고 말합니다. 그런 점에서 저는 이전 까지 '왜 Django여야 하는가?' 에 대한 고민을 단 한번도 하지 않았습니다. 회사에서 쓰고 있는 Backend 프레임워크에 대해 그 어떤 비판적 사고도 하지 않았습니다.

 

Django가 불편하다

 비판적 사고는 Django가 불편하게 느껴지면서 처음 시작 되었습니다. 사실 Django가 가지는 강력함은 정말 많습니다. 보안을 신경 쓸 부분이 줄어 들고 Admin 페이지를 자동으로 제공하며, 이미 완성된 수많은 기능은 개발을 편리하게 합니다. 하지만 그럼에도 불구하고 몇 가지 불편함이 쌓이면서 다른 방법을 찾아야겠다 결심했습니다.

1. 불편한 Django RestFramework

  Admin 페이지와 Template 기능 까지 제공하는 Django는 과거에는 굉장히 강력한 프레임워크였을 것 같습니다. 그러나 Frontend / Backend가 Restful하게 개발하기 위해 Django RestFramework를 별도로 설치해서 사용했습니다. 문제는 방대한 기능 때문에 무엇을 사용해야 할 지 정하기 힘들다는 문제가 있었습니다. ListView, GenericView, APIView 등등 여러가지를 고민하고 적용하면서 code의 통일성을 해쳤습니다. (물론, 저희들으 소통 부재와 개발 체계 또한 부족했음을 인정합니다.)

2. 부족한 공식문서

  간단한 CRUD를 만드는 방법도 어떤 것을 추천하기 보다는 여러가지 View를 모두 직접 쓰면서 확인해야했고, ORM의 경우에도 복잡한 Query에 대한 공식문서의 설명이 부족해서 Django Orm Qookbook를 찾아서 적용해야만 했습니다.

3. 어려운 문서화 (Swagger)

  Swagger를 적용하고 익숙해지면서 금방 만들 수 있게 되었지만 '더 편한 방법은 없을까?' 하는 고민 또한 동시에 생겼습니다.

 

결론은 FastAPI

 이러한 비판적 사고의 결과물로 저는 향후 사내 프로젝트에서 FastAPI로 Backend 개발을 하고자 했습니다. Django에 비해 가볍고 빠르며, 공식문서가 깔끔하게 잘 정리되어있고, API 문서화도 편한 FastAPI를 업무에 적용하려면 적합한 근거와 함께 회사의 상급자와 동료 개발자들을 설득해야 합니다. FastAPI가 적합한가 확인하기 가장 좋은 방법이 직접 무언가 만들어 보는 것이라 생각했습니다. 한창 맨몸 운동 (푸쉬업, 턱걸이)를 하던 때라 '운동을 기록하고 성장과정을 통계로 보여주는 어플리케이션'을 만들어 보았습니다. 시리즈로 어떻게 개발이 진행되었는지 천천히 연재해 보겠습니다.