[Study] 프로덕트(Product) 프레임워크(Framework) 선정 과정과 데이터베이스(Database) 선택 이유

안녕하세요 성조입니다.

 

이번에는 현재 제작 중인 프로덕트의 프레임워크 선정 과정과 이유에 대해 작성해 보려 합니다.

 

이 포스팅은 주관적인 판단으로 선정했던 과정을 기록한 것입니다. 피드백 사항이나, 의견이 있다면 언제든지 지식을 공유해 주시면 좋을 것 같습니다.

---

내 서비스는 어떤 서비스?

하나의 프로덕트 서비스를 구축하려면 적절한 언어, 프레임워크, 데이터베이스, 그리고 개발 프로세스 등 다양한 요소가 존재한다.

 

하나의 서비스 프로덕트의 프로젝트를 성공시키기 위해서는 CEO, 디자이너, 프런트엔드 개발자, 백엔드 개발자, 마케팅, 인공지능 개발자 등 다양한 분야의 도움이 필요할 수 있다. 여기서 프런트와 백엔드에 상관없이 개발자로 묶어서 개발자의 역할은 올바른 개발 방향성을 추구하여 프로젝트에 필요한 요소들을 선택하고, 구현할 수 있도록 집중하는 것이 중요하다고 생각한다.

 

본인은 국비 교육을 통해 취업을 준비하면서 Spring과 Spring Boot 프로젝트 경험했다. 또한, 사이드 프로젝트에서는 Express.js와 Next.js 그리고 Django, 취업해서는 Flask를 사용했으며, 작은 소규모의 Django 프로젝트를 외주한 경험이 있다.

이런 다양한 경험을 통해 깨달은 중요한 점은 성장을 위해서는 단순히 프레임워크를 프로젝트에 맞춰 종속된 상태로 사용하는 것이 아니라, 프로젝트의 목적과 현재 상황, 사용 가능한 자원을 종합적으로 고려하여 사항에 맞는 프레임워크를 맞춤 선발하고, 프로덕션 개발을 진행하는 것이라 생각하게 됐다.

 

 

 

프레임워크 선정과 그 과정들

 

크로스 플랫폼 앱과 네이티브 앱

크로스 플랫폼 앱은 하나의 코드베이스를 작성하고, 그 코드를 다양한 플랫폼에서 컴파일하거나 재사용하여 여러 운영체제나 디바이스에서 플랫폼이 동작하는 앱을 생성하는 것이다. 

 

네이티브 앱은 특정 운영 체제나 플랫폼에 최적화된 앱을 의미하는데 해당 플랫폼의 고유한 개발 환경, 언어 및 도구를 사용하여 개발된다. 성능에 초점이 잡혀 있다.

 

모바일 앱 개발 환경에서 크로스 플랫폼 앱과 네이티브 앱을 구분하면 다음과 같다.

- React Native와 Flutter

- 안드로이드(Android)와 ios 진영으로 흔히 코틀린(Kotlin)과 스위프트(Swift)가 있다.

 

투자도 받지 못한 예비 창업자가 시작부터 네이티브에 투자하면서 PMF를 검증하는 것은 너무 좋지 못한 방향일 수 있다 생각한다. 예전에는 크로스 플랫폼에서 제작된 앱이 호환이 안 되는 문제가 많이 발생했지만 최근에는 그런 문제들도 점차 줄어들고 있기 때문에 MVP 모델을 만들고, PMF를 검증하기 위해 네이티브 앱 개발은 적합하지 않다고 생각했다. 당연히 크로스 플랫폼을 선택했고, 다음의 고민을 했다. 

 

 

Flutter와 React Native

플러터와 리액트 네이티브를 비교하는데 어느 순간부터 생각보다 사라질 수 있는 것이 너무 치명적인 것 아니냐는 많은 부정 리뷰가 보였다.

 

국내의 경우 React Native 진영에 인력도 더 많고, 당연한 코스라고 생각하는 평들이 많이 보였던 것 같다. 그러나 포스팅을 작성하는 2023년 8월 17일에도 여전히 구글은 플러터를 포기하지 않았고, 꾸준히 국내에도 신규 플러터 개발자가 늘어나고 있다고 판단했다. 또한, 본인이 직접 개발했던 경험에서는 리액트 네이티브 경험보다는 플러터의 개발 경험이 조금 더 긍정적으로 다가왔던 것 덕분에 국내 한 달 1억 트래픽을 견뎠다는 RN보다는 조금 더 빠르게 생산할 수 있는 플러터를 선택하게 됐다.

 

사실 본인이 만든 서비스가 하루 트래픽 20도 안 나올 수 있는 것인데 만약을 대비해서 1억의 트래픽을 고려하는 것보다 빠르게 출시하고 실패하는 것이 더 중요했다.

 

 

프레임워크 선정

앱을 개발하려는 상황에서 웹 프런트는 조금 향후의 일이 됐다.

백엔드 프레임워크로 자주 언급되는 Spring Boot, Express.js, Nest.js, Python(Flask, Fastapi, Django) 중 어떤 것이 좋을지 고민했고, 다음과 같이 생각했다.

 

Spring Boot

국내에서 가장 많은 Java 인력을 보유했고, 경력직을 구하기에도 좋은 프레임워크다. 자바가 유료라는 부분을 제외하고는 숙련도만 있다면 언제든지 충분히 선택하기 좋은 프레임워크이다. 하지만 본인은 국비 교육 이후 자바 관련 공부는 했지만 제대로 된 스프링 부트 프로젝트를 개발하지 않았던 것이 문제였다.

 

스프링 부트의 경우 인력 보충의 장점과 다량의 트래픽을 경험했던 경력직 인원들이 많이 분포하고 있어서 유료 비용을 지불해도 장점이 더 컸지만 프레임워크 레벨에서 본인이 리드할 실력이 아니라고 판단했고, 그런 상태에서 초기 개발하는 것은 부담이 있을 것 같다 생각됐고, 포기하게 됐다.

 

 

Express.js

실시간 비동기 처리에 좋은 Node 진영의 핫한 프레임워크인 Express.js이다.

많은 Node 개발자분들이 사용하고 있을 것 같은 프레임워크이다. 프로덕트 레벨에서는 Express.js에 타입스크립트를 추가하고, ORM으로 prisma를 활용해서 사용하고 있는 것을 몇 차례 보게 됐는데 본인이 자바와 파이썬은 계속 공부하고 있었지만 자바스크립트에 대해 모르는 것(애매하게 아는 것)이 너무 많았고, 실시간 처리를 중점으로 하기보다는 CRUD를 활용해서 데이터에 중점이 들어간 상황이라 Express.js 선택을 하지 않았다.

 

 

Nest.js

긍정적으로 사용하시는 분들은 싫어하실 수 있는 말이지만 Nest.js에 많은 찬사와 칭찬이 있던 것치고 그렇게 큰 호감으로 다가오지는 못했고, Express.js에 스프링 관련 내용이 한 스푼 더해진 것 같다는 느낌이 많이 들었다.

Express.js를 이미 사용하고 있던 기업에서 팀 규모가 커져가는 경우. 컨벤션을 맞추기 좋을 것 같고, Express.js에서 Spring Boot로 굳이 프로그래밍 언어나 설계를 대공사 할 정도로 넘길 필요까지는 없을 때. Nest.js를 도입하면 좋을 것 같다는 생각이 들었다.

 

즉, 비용을 타협할 수 있어도 프레임워크 숙련도 때문에 Spring Boot을 선택하지 않았는데 Nest.js를 선택하는 것은 그냥 모순이었다.

 

 

Python?

모든 프로그래밍 언어를 만능으로 다룰 수 있는 천재가 아닌 이상 본인의 주력 프로그래밍 언어가 있을 것이다.

시니어의 경우도 모든 언어를 완벽하게 100% 아는 것은 쉽지 않다. 본인의 경우 심심해서 파이썬으로 코딩 문제를 풀고, 취업을 Python을 활용해서 했던 부분이 프레임워크를 선정할 때 많은 영향을 줬다. 

 

Django

ORM Model을 기본으로 사용할 정도로 데이터를 많이 다루는 프레임워크 같다. 특히, 장고는 관리자 기능을 지원하는 것이 엄청 큰 장점이라고 말한다.

 

장고는 단순히 API만 제작하면 다른 Flask, FastApi에 비해 밀려나는 프레임워크지만 본인이 생각했을 때 하단에서 설명될 Database인 Postgre와 Django의 조합이라면 데이터를 많이 다룰 때 그리고 글로벌하게 사용하는 상황에서 충분히 사용할 수 있는 프레임워크라 생각됐다. 사실 모든 프로그래밍 언어와 프레임워크는 잘 사용하면 문제없이 사용할 수 있다. 하지만 선례나, 기존에 생각했던 부분에 평가 데이터를 읽고, 고민했을 때 본인이 진행하는 프로덕트를 만들기 위해서는 장고를 선택하는 것이 적합하다 생각하게 됐다.

 

 

Flask

파이썬 진영에서 MSA하는 방향에 최적화된 경량 프레임워크다.

 

본인의 프로젝트에 트래픽이 얼마나 생길지 모르는 것은 위에도 언급된 것처럼. 막상 프로덕트를 만들었는데 하루 5명도 안 볼 수 있는 큰 문제점이 있다.

 

이런 경우 모놀리식 프로젝트가 MSA 프로젝트보다 훨씬 위험 리스크가 적다고 판단하게 됐다. 빠르고, 잘 분산된거면 좋다. 근데 그런 리스크를 가진 상태로 아직 투자도 없고, 법인도 안 만들어진 기업이. 기획과 디자인이 진행되고 있는 상황에서 분산 투자하여 개발하는 것은 문제가 많을 것 같다 판단했다.

 

돈 100억을 여러 은행에 분산해서 맡기는 것과 10만원 여러 은행에 분산해서 맡기는 것은 분명한 차이가 있다.라고 생각한다.

 

 

Fastapi

API를 빠르게 개발하는 부분에 있어서는 '좋다.'라고 말할 수 있다. 하지만 데이터를 운용하는 것을 중요하게 생각하는 본인 프로젝트에 ORM의 지원이 늦게 됐고, 레퍼런스 자료가 부족한 단점은 너무나도 크리티컬 한 부분이라 판단했다. 파이썬 프레임워크에서 빠른 정도로는 Go나 Rust의 속도를 따라가기 어렵고, 스프링 부트만큼 자료나, 인력 풀이 좋거나, 안정성이 높다고 판단하기도 어려웠다.

 

분명 좋은 프레임워크는 분명하지만 완전히 새로운 것을 배우고, 학습하여 적용하는 것은 이미 기존에 대체할 필요 없는 것을 대체하려고 오버 엔지니어링 하는 것과 다름이 없다고 판단했다.

 

 

 

데이터베이스 선택

PostgreSQL과 MYSQL

Postgre와 MySQL로 불리는 두 가지 데이터베이스를 두고 고민하게 됐다.

물론 다양한 데이터베이스 선택할 수 있는 옵션이 존재했다. 하지만 본인이 생각했을 때 프로덕트를 진행하고, 만드는 과정에서 들어갈 사이드 비용이 이미 어느 정도 예상이 됐지만, 분명 예상하지 못한 곳에서도 추가적인 비용이 발생된다 생각했고, 자금 조달이 원활하지 못하면 직접 기획부터 디자인, 개발을 총괄해서 개발하고 있는 본인에게 너무나도 치명적으로 다가올 수 있었다.

 

향후 트래픽이 어떻게 발생될지 모르는 상황에서 무조건 오라클 DB를 지원하것 보다 무료 RBDMS에서 많이 활용되며, 사용 경험이 있는 두 가지 모델을 선정하게 됐다.

 

MySQL의 경우 데이터를 단순 CRUD할 때 PostgreSQL보다 비교적 좋은 성능을 발휘한다.

PostgreSQL의 경우 단순 CRUD의 경우 MySQL에게 성능 측면이 밀리지만 조인된 테이블. 즉, 데이터를 유연하게 다룰 수 있는 장점을 가지고 있었다.

 

본인이 위에도 언급한 것과 같이 단순하게 CRUD를 다루는 것도 중요하지만 Django를 택했던 이유처럼 데이터를 다루는 데 초점이 있고, 추천 시스템 파트가 들어갈 것까지 고려했을 때. 숙련도가 크게 차이 없는 정도라면 약간 더 많이 활용해 본 MySQL보다 PostgreSQL를 사용해도 충분히 긍정적으로 사용할 수 있을 것이라 판단됐다.

 

 

 

최종 결론

언어 : Python

모바일 앱 프레임워크 : Flutter

프론트엔드 프레임워크 : Next.js

백엔드 프레임워크 : Django(DRF)

데이터베이스 : PostgreSQL

 

---

추가적인 피드백이나, 오타가 있는 경우 언제든지 댓글 남겨주시면 감사드리겠습니다.

 

다음 포스팅 때 뵙겠습니다.