[한이음-이전] 아키텍쳐의 고민

글 작성에 앞서, 현재 다른 프로젝트에 참여하게 되어 해당 프로젝트는 아키텍처의 고민에서 끝나게 되었습니다. 

 

한이음 공모전의 본격적인 개발에 앞서, 팀 빌딩 직후부터 걱정이 정말 많이 앞서기 시작했다. 그러나 걱정만 하고 있을수는 없기에, 스터디에 앞서 사전에 멘토님께서 제안해주신 아키텍처에 대한 조사를 진행해보기 시작했다.

 

그 전에, 나는 Django를 통한 개발을 진행했었기에, 파이썬은 아주 조금..? 익숙한 언어였다. 또, 아주 조금이지만 Spring을 이용한 프로젝트에서도 백을 담당했고 다시 공부하는 중이었기에 백엔드를 아주아주아주아주 조금은 알았다. 하지만 함께 하는 팀원들은 파이썬 사용 경험이 없고, 팀프로젝트도 제대로 참여해보지 못한 분들이었다. 그래서 이러한 팀의 특성도 고려할 필요가 있었다.

FastAPI, 너는 누구? 

멘토님께서는 FastAPI 백엔드 프레임워크와 MySQL을 제안해주셨다. 그러나 나는 FastAPI에 대해 들어본 적이 없었다. 그래서 바로 조사에 나섰다.

 

열심히 구글링을 해보았지만, FastAPI와 관련된 강좌나 기술블로그가 너무 적었다. 공식 문서를 무작정 보는 공부법은 나하고 잘 안맞았기 때문에 우선은 위키 페이지(https://wikidocs.net/book/8531) 를 통해 FastAPI에 대해 직접 알아보고자 하였다. 

위키의 문제점

그러나 위 위키에는 문제점이 있었다. 아무래도 CRUD를 다루다 보니, 프론트에 대한 내용도 상당히 많았다는 점이다. Svelte를 이용하여 프론트 개발을 진행하는 것으로 보였는데, 사실 입문 스터디를 그렇게 길게 할 시간적 여유가 없기 때문에 이 위키를 통해 공부하는 것이 비효율적일 것이라는 생각이 들었다. 또, 번역문의 특성상 한글임에도 그렇게 눈에 잘 들어오지는 않아서 학기중에 멤버들이 병행할 참조 도서로서는 좋은 것 같지는 않았다.

 

다른 프레임워크를 찾아보자

이렇게 많은 생각을 하며 잠시 FastAPI에 대한 조사를 멈추었다. 이에 가장 결정적이었던 것은 구글링을 하던 와중에 접한 FastAPI의 여러 단점들 때문이었다. 그리고 내가 (잠깐이지만) 공부해 본 것으로는 전반적으로 래퍼런스가 너무 부족했다. 개발을 잘하는 사람들이라면 상관 없겠지만, 우리 팀은 모두 초보 개발자에 제대로 된 팀플 경험은 나만 있었(그마저도 중요한 역할을 수행한적이 단 한번도 없기 때문에 나도 비슷한 수준일 것이다)다. 그런 상황에서 너무나도 부족한 래퍼런스는 초보 개발자에게 적절치 않아보였다. 우리팀은 파이썬도 모르는 팀원도 있었기 때문에 너무 어려운 상황이 될 것 같았다.

 

챗 GPT의 사용

그래서 ChatGPT에게 도움을 요청해보았다. 개발해야하는 프로젝트의 상황을 가능한 구체적으로 적고, 프레임워크를 추천해달라고 했다. 처음에 gpt는 FastAPI를 추천했다. 

이건 아닌거 같은데,,

그래서 나는 팀원들 모두가 초보 개발자라는 팀의 상황도 덧붙였고, 이때 gpt는 Flask를 추천했다. 

어쩌면 유도 심문같았을지도 모르겠다.

그리고 FastAPI 도입을 주장하는 멤버에게 어떻게 플라스크를 설득시킬 수 있을지 두 프레임워크를 비교하여 설명해달라고 요청하였다. 그 외에도 유니티와의 연동성, MySQL DB와의 연동, MSA 프로젝트의 고려 등 다양한 조건을 물어보았다. 그리고 ORM으로 사용하게 될 SQLArchemy에 대한 두려움이 있어 파이썬 ORM에 대해 추천을 받기도 하였다.

 

결론적으로 다양한 답변, 그리고 내가 경험해 본 장고와 FastAPI의 특성을 고려했을때 Flask를 사용하는 것이 더 적절해보였다. 그래서 추후 멘토님께 Flask를 고려해볼 수 있는지 근거와 함께 여쭤보고자 한다.

 

* 해당 프로젝트는 여러 이유로 인해 아키텍처 고민에서 마무리되었으며, 새롭게 참여하게 된 프로젝트에 대한 내용은 다음 글부터 작성하였습니다.