0. Starting Point
0. 2024년 1월. 나는 새 회사로 옮겼다. 옮기게 된 사연도 여러가지 이야기가 있지만 이번에는 오로지 기술적인 이야기만 해볼 작정이다.
새로 옮긴 회사에서 담당하게 된 프로젝트는 공장, 즉 생산분야에서 쓰이기 위한 서비스를 만드는 일이다. 고객에게 서비스를 제공하기 위해 모바일 앱과 관리자를 위한 웹 페이지가 단말로써 필요하며, 백엔드는 앱과 웹 페이지에 필요한 RestAPI를 제공한다.
아, 추가로 서비스 운영자가 사용할 인하우스용 툴까지 만들어야 하는 상황.
1. 파이썬을 처음해보는 입장에서 RestAPI를 만들기 위한 웹 프레임워크를 뭘 쓰냐..라는 고민이 있었는데, 사실 이 고민은 답정너로 FastAPI로 정해져 있는 상태였다. 왜냐면, 회사에서 이미 사내 기본 프로젝트로 선택되어 있는 상태였으니까. 다만 이전에 살짝 써본 Flask나, 아님 어짜피 인하우스 툴도 만들거면 Django도 좋은 선택일거 같았다.
하지만 개발팀 규모가 매우 작고, 이런상황에서 거대한 프레임워크를 쓴다면 나도 마찬가지고 새로 들어올 누군가도 마찬가지로 분명히 학습곡선이 발목을 잡을것이 뻔한 상황이었다. 또한 팀 규모는 작았지만 F/E 작업을 전담해줄수 있는 사람이 있다는 것도 결정에 영향을 주었다. 어짜피 F/E를 React로 만들어서 처리해줄 사람이 있다면 B/E는 B/E의 일-RestAPI를 제공하는 일-에 집중하는게 낫다. 그런 차원에서 보면 FastAPI는 NodeJS 코딩하는 느낌으로 빨리빨리 치고 나갈수 있었다. 6개월이 지난 지금와서 돌아보면 괜찮은 선택이라 할수 있을듯.
2. 그래서 FastAPI로 개발하기로 결정한 후 내가 목표로 삼은것은 어느정도 코드 베이스에 대한 이해가 있다면 가장 기본적인 CRUD를 만드는데 최소 4시간, 빠르면 2시간 안으로 끊을수 있도록 하자는 것이었다. 프로젝트 초창기에는 당연히 삽질도 많고 변경도 많다. 타사대비 동일하게 가진거라고는 시간밖에 없는 작은 회사에서는 시간싸움에서 이기지 못하면 살아남을수 없다.(이건 내가 이전에 일하던 회사에서 느낀거다) 그래서, 초짜 주제에 말도 안되는 기준같기도 하고, 빠른지 느린지 모르겠지만 그래도 뭔가 새로운거 추가하는데 반나절이면 충분한 구조라면 "느려터졌다"라는 소리는 안들을거 같았다.
해서, 나는 아래와 같은 구조로 프로젝트의 기반을 만들었다.
FastAPI에서 권장하는 구조는 router service model 구조인데, 엉뚱하게 controller service model로 만든것에 대해서는 나역시 이게 맞나 싶었다. 그래서 ChatGPT와 상담도 해보고 그랬는데(...) 결론적으로 어플리케이션 단에서 router라는 단어를 쓰면 네트워크 구축할때 웬지 단어가 헷갈릴거 같은 느낌적인 느낌이 들어서 controller라는 말을 쓰기로 했다.
지금와서는 맞는 선택인지 옳은 선택인지 알수 없으나, 나중에 이것도 바꿀 필요가 있다면 IDE이용해서 후닥닥 바꾸면 되니 너무 끙끙 앓지 말고 해보자라는 생각이 강했다.
3. 그리하야, 기초적인 프로젝트 기틀을 잡고 가장 간단한 DB 조회 코드를 만들어 정상 동작하는 것을 보며 쾌재를 불렀......으나. 파이썬 초짜의 한심함이 나중에 큰 후회를 불렀을줄이야 누가 알았으랴.
- 계속 -