최근 코틀린과 인프라 그리고 깊이 있는 기술에 대한 관심이 깊어지면서 언어뿐만 아니라 다양한 기술을 직접 경험하기 위한 프로젝틀르 시작했다.
서비스를 만들기 전 가장 먼저 들었던 생각은 어떻게 설계할 것인가? 였다.
사실 언어와 기술을 학습하기 위한 프로젝트인데 설계에서부터 막히면서 시작이 미뤄지고 있었다.
그래서 처음부터 많은 트래픽을 견디는 완벽한 서비스를 설계하기보다는 (그런 서비스를 설계할 역량ㄷ.. 흠) 우선 사용 가능한 서비스를 만들고 개선해 나가는 것이 더 중요하다고 판단했다.
이 글에서는 내가 초기 개발(MVP)을 어떻게 구성했는지, 그리고 왜 그렇게 결정했는지에 대해 기록하려 한다.
추후 트래픽이 늘어감에 따라 프로젝트를 점진적으로 발전해 나가면서 나도 같이 성장할 것이다.
프로젝트 주제
나는 SNS 서비스를 선택했으며, 이유는 아래와 같다.
- 비즈니스 로직이 비교적 단순해서 핵심 기능 구현에 집중할 수 있다.
- 화면 구성도 복잡하지 않기 때문에, 프론트엔드보다는 백엔드 중심으로 학습하기에 적합하다고 판단했다.
그래서 우선 기능은 간단하게 회원가입, 로그인 그리고 게시글/댓글 CRUD 정도만 넣을 생각이다.
나중에는 인기글, 좋아요, 검색 등 부가 기능을 추가할 예정이다.
아키텍처
MVP 개발이기 때문에 우선은 Spring MVC 기반의 단일 서버, 모놀리틱 구조로 개발을 시작했다.
초기에는 트래픽이 거의 없고, 복잡한 기능도 없기 때문이다.
그리고 단일 서버로도 초기 유저 수와 트래픽은 충분히 감당 가능할 것이라 생각했다.
추후 트래픽 증가나 기능 분리의 필요성이 생기면 점진적으로 MSA 구조도 고려할 것이다. (학습 필요함)
인프라
초기 MVP 개발을 마치고, 서비스를 실제로 배포할 인프라로는 GCP(Google Cloud Platform)를 선택했다.
고려했던 클라우드 서비스는 AWS, Render, GCP가 있었다.
1. AWS (Amazon Web Service)
우선 AWS는 전 세계적으로 가장 많이 쓰이는 클라우드 플랫폼인 만큼, 조금만 검색해봐도 관련 레퍼런스가 넘친다.
하지만 실제 써보니 서비스가 종류가 너무 많고, 각각의 설정들이 복잡해서 초기 학습의 런닝커브가 높다고 느꼇다.
예전에 개인 프로젝트로 AWS 프리티어를 사용했었는데, IPv4 주소 관련 비용 정책 변경으로 추가 요금이 부과된 적도 있었다.
그래서 일단 킾..
2. Render
클라우드 서비스를 찾아보던 중 알게 된 서비스인데, 살펴보니 간단하게 배포가 가능한 서비스를 제공하고 있었다.
또한 프리티어만 사용하면 신용카드 등록도 필요 없어서 과금 걱정이 전혀 들지 않아서 관심이 갔지만 ..무료 데이터베이스를 PostgreSQL만 지원하고 있었다.
나는 이번 프로젝트에서 MySQL를 사용하기로 했으니 DB를 별도로 구축해야 해서 패스.
다음 기회에 무조건 써 볼 예정이다.
3. GCP
그래서 최종적으로 선택한 서비스이다.
이번에 처음 살펴본 클라우드 서비스인데, AWS와 비교했을 때 직관적이고 관리하기가 쉬운 인터페이스를 제공한다고 느껴졌다. (물론 주관적인 의견)
그리고 Render 보다는 더 다양한 인프라 구성을 지원하기 때문에 학습 용도로 더 적합하다고 생각했다.
조금 아쉬운 점은, 예전에는 무료 체험판으로 $300 크레딧을 12개월 기간으로 제공했었는데 이번에 가입하려고 보니까 체험 기간이 3개월로 축소된 점이다.
그래도 만족.
사용 기술 스택
Kotlin
앞에서 말했듯이 언어는 Kotlin을 사용했다.
코틀린이 안드로이드 앱 개발을 위한 공식 언어로 채택되기도 했고, 많은 회사에서 백엔드 개발 언어로도 사용하기 때문에 호기심이 생겼다. (특히 null-safety)
러닝 커브도 크지 않을 것 같아서 (큰 오산이었다) 이번 기회에 학습해보기로 했다.
Spring (Spring Boot)
서버 로직은 Spring 프레임워크로 진행한다.
뭐.. 그렇다.
아 Spring Security도 간단하게 사용하는데 Session기반 인증이다.
요즘은 JWT 기반 인증을 많이 사용하지만, 초기 구조에서는 세션으로도 충분하다고 판단했다.
JWT를 도입하면 토큰 저장, 만료 처리, 재발급 등 로직까지 구현해야 하는데 이 단계에서는 사실 Over Engineering이 아닌가 싶다.
SSR (Thymeleaf + HTMX)
화면 렌더링은 Thymeleaf와 HTMX를 사용한다.
사실 React나 Vue 같은 CSR 프레임워크는 고려하지 않았다.
우선은 학습하는 데 많은 시간이 소요될 것이고, 학습을 위한 프로젝트이긴 하지만 백엔드 위주의 학습이 목적이기 때문이다. (React 넘무 어렵..)
또 동적으로 렌더링이 필요한 부분은 최근 발견한 HTMX를 통해 해결할 생각이다.
구글링해보면 국내 블로그나 레퍼런스는 잘 없는 것으로 보인다.
그래서 이참에 공식문서를 보는 식견도 높일 겸 해당 기술을 사용하기로 했다.
MySQL
데이터베이스는 MySQL을 선택했다.
처음에는 지난 팀 프로젝트에서 사용했던 PostgreSQL과 고민했다.
두 DB 모두 성능과 기능에서 장단점이 있지만, 이번 프로젝트에서는 다음과 같은 이유로 MySQL을 선택했다.
- PostgreSQL은 대규모 데이터셋, 복잡한 읽기, 쓰기 작업에 유리하다.
- MySQL은 읽기 전용 쿼리에서 더 가볍고 빠르며 안정적인 처리 속도를 보여준다.
SNS는 게시글, 댓글, 좋아요 등 읽기 비중이 높은 서비스이기 때문에 MySQL이 더 적합하다고 판단했다.
참고
