(서평단 리뷰) 가장 빠른 풀스택을 위한 Flask & FastAPI

가장 빠른 풀스택을 위한 Flask & FastAPI - 한 권으로 정리하는 파이썬 백엔드
Dave Lee 지음 / 비제이퍼블릭 / 2024년 5월

왜 Flask & FastAPI인가?

우선 한 가지 질문부터. Flask면 Flask고, FastAPI면 FastAPI지 왜 둘을 한 권에 묶어놓았을까? 서로 장단점이 갈릴 수야 있겠지만, 결국 상호보완적으로 함께 쓰이기보단 둘 중 하나(주로 FastAPI)만 사용하게 되지 않나?

내가 보기에 그 이유는 첫째, 둘이 비슷하다. 하나 배우고 조금 더 보태면 나머지 하나도 배울 수 있다. 둘 다 한 권으로 묶어야 이 책의 8장처럼 함께 본격적으로 비교하는 챕터도 자연스럽게 실릴 수 있다.

둘째, 아마도 Flask와 FastAPI 둘을 비교한 후 이 중에 하나를 선택하고자 하는 독자들이 많을 것이다. 혹시 그런 비교에 관심없고 동전을 던져서 아무거나 하나를 고르려는 사람이 있다고 할지라도, 선택의 이유에 대한 질문을 언젠가는 받게 될 것이다. 월급 받는 직원이 동전 던져서 정했다고 하면 동전처럼 던져질지도 모른다. 즉 이러한 실질적인 수요를 충족시키기 위한 구성이다.

쉽지만은 않은 책이다

처음 "Hello World" 코드를 보았을 때만 해도 쉬운 내용일 줄 알았다. 이를 응용해서 서버와 입출력 값을 주고받는 간단한 덧셈 계산기를 Falsk와 FastAPI로 아래와 같이 뚝딱 만들어보았고, 이 과정에서 특별히 막히지 않았다. 쉽네 쉬워~

──라는 생각은, 하지만 페이지를 넘길수록 점점 바뀌게 되는데 …… ㅋ 아무리 편리하고 간소화된 프레임워크라고 해도 서버에 대해서, 데이터베이스에 대해서 알아야 할 최소한의 지식들을 면제해주진 않는다.

  파이썬 기초 문법만 떼고 넘어온 독자라도 책에 나온대로 코드 치니까 서버도 켜지고 다 되네? 하며 많은 부분을 대충 얼버무리고 떼우는 데 그럭저럭 성공할 수 있을지 모른다. 하지만 아마도 다음 세 가지 허들만큼은 그런 식으로 쉽게 넘어가기 힘들 것이다.

 1. DB/SQL : ORM에 대해 어느 정도 설명하긴 하지만, 그 밑바탕이 되는 데이터베이스 이론부터 이 책이 차근차근 알려주진 않는다. 책에서도 SQL을 사용할 줄 알고 PC에도 이미 설치되어 있다는 전제로 설명한다고 아예 명시하였다. 아무리 CRUD 개념을 직관적으로 단순하게 받아들인다 해도, Transaction과 Rollback의 의미조차 모르면 곤란할 것이다.

 2. HTML/CSS/JavaScript : 역시 알고 와야 한다. 이 책의 웹 코드는 Bootstrap을 사용하는데, 물론 Bootstrap이 별 거 아니긴 하다(ㅋ). 그래도 코드를 읽고 Bootstrap을 써서 스타일을 꾸몄구나 하는 정도는 이해할 수 있어야 한다. 

 3. 비동기 프로그래밍 : 마찬가지로 이 책의 도움을 받기보단 스스로 넘어와야 할 문턱이다. 비동기 프로그래밍의 개념을 이해하고, 구체적으로 async 키워드가 붙은 구문의 흐름을 따라갈 수 있어야 한다.

  즉 "Full Stack"은 결코 동네 강아지 이름이 아니다! 말 그대로 프론트/백엔드 모두를 다룰 준비가 되어 있어야 한다.

  하지만 그럼에도 불구하고, "Hello World"부터 시작하여 agile하게 살을 붙여나가는 구성은 초반의 허들을 낮춰주는 데 큰 역할을 하였다고 생각한다. 예전에 Django를 공부할 적에는 직관적으로 잘 와닿지 않는 MVT 패턴이 뭔지 이해하느라 입구에서부터 분투했었는데, 이 책은 app.py(또는 main.py) 안에 일단 모든 코드를 다 때려넣고 나중에 가서 사실은 이걸 코드가 수행하는 내용에 따라 models.py, controllers.py로 나눠서 작성하면 더 좋다고 알려준다. 이쪽의 설명 흐름이 더 받아들이기 수월하다고 생각한다.

실습 책에 나온 코드를 직접 실행해보자! 아래 깃허브 주소에 들어가면 저자가 본문에 등장하는 모든 코드를 올려두었다. https://github.com/DaveLee-fun

내 경우엔 이 코드를 완전히 똑같이 쓰진 않고, 약간 수정하였다. 왜냐하면 실행환경으로 선택한 Replit에서 MySQL을 지원하지 않아서 대신 SQLite를 써야 했기 때문이다. 바꿔야 할 부분은 놀라울 정도로 많지 않았다. DB URL을 담은 변수의 문자열 값 한 줄만 바꿔주면, 나머지 코드는 DB의 종류에 불문하고 정상적으로 작동하였다. 이는 SQL이 CS의 역사에서 유래없이 성공적으로 표준화된 언어여서이기도 하고, 또한 ORM 라이브러리인 SQLAlchemy가 그만큼 잘 만들어진 탓이기도 할 것이다. 이 SQLAlchemy를 알게 된 것이 중요한 소득 중 하나라고 생각한다.

자동 문서화 : Swagger / Redoc SQLAlchemy 못지 않은 소득이 또 있다. FastAPI는 Swagger와 Redoc이라는 자동 문서화 기능을 기본적으로 제공한다. URL 뒤에 각각 /docs, /redoc을 붙이면 해당 문서로 접속된다. 얼마나 잘 만들어줄까 싶었는데 완성도가 엄청나다.

이러한 자동 문서화 기능을 알게 된 이상, 다시는 직접 손으로 문서를 작성하지 못 할 것 같다.ㅋ

결론 : 나의 선택은 FastAPI

처음에는 Flask가 좀 더 단순하다는 인상이 있었지만, 생각해보니 그 인상의 대부분은 Flask를 동기식 프로그래밍과, FastAPI를 비동기식 프로그래밍과 묶어서 생각한 탓이었던 것 같다. FastAPI가 보다 비동기식 프로그래밍에 친화적이긴 하지만, 그것이 곧 두 프레임워크간의 본질적인 복잡성 차이를 결정짓진 않는다.

Flask는 보안 측면에서 보다 취약하고, FastAPI의 물리적 성능이 더 좋으며, 게다가 FastAPI에는 자동 문서화가 기본 옵션으로 따라온다! Flask가 보안이며 자동 문서화며 부족한 부분을 외부에서 끌어와서 만회하다보면 그만큼 더 복잡성이 커질 것이다. 자, 이제 누가 더 복잡하지? 현업에서도 대체로 Flask에서 FastAPI로 마이그레이션하지 그 반대의 경우는 없다는 것 같다.

Flask & FastAPI는 당장 쓰기 위한 공부였다. 이 책을 읽고 구체적인 근거를 바탕으로 명확한 결정을 내릴 수 있었다.