세미 프로젝트 시작

약 2주의 온라인 강의를 진행한 후에 자유롭게 PR을 올려 자기 어필을 통해 팀을 구성하게 했고 나는 운이 좋게 원하는 팀원들과 아주 빠른 시기에 함께하게 되었다.

 

그렇게 첫 오프라인이자 세미프로젝트를 시작하는 날이 되었다.

프로그래머스에서 세미프로젝트 명세서를 제공했는데 내용은 다음과 같았다.

 

세미 프로젝트 명세서

 

MSA 설계를 목표로 했지만, 프로젝트 환경상 하나의 레포와 하나의 DB를 사용해야 했다.

아마도 인프라 비용이나 운영 측면의 제약 때문에 완전한 MSA 환경을 제공하기는 어려웠던 것 같다.
결과적으로 완전한 MSA 구조보다는 멀티 모듈 아키텍처에 가까운 형태로 프로젝트를 진행하게 되었다.

그러나 개발하는 것에 있어서는 끊임 없이 MSA 설계를 지향했고 MSA 환경에서 발생할 수 있는 문제를 고려하며 개발했다.

 

다시 세미 프로젝트 시작 시점으로 돌아가겠다.

 

팀원들과 가장 먼저 한 것은 주제 정하기였다.

자유 주제는 아니고 이커머스 서비스 플랫폼으로 한정되어 있었다.

주제가 한정되어 있지 않았더라도 프로젝트 요구사항을 읽어보면 이커머스 플랫폼을 만들어야 했을 것 같다.

회의를 하면서 팀원 모두가 공통적으로 동의했던 내용이 있다.

 

주제는 좁고 뾰족하게 가져가자.

 

이게 무슨 말인지 설명하기에 앞서 내가 경험한 것들에 대해 먼저 말해보겠다.

작년 한화시스템에서 경험했던 프로젝트들을 생각해보면 주제에 대한 고민을 정말 많이 했었다. 주어진 프로젝트 기간은 엄청 촉박한데

기획, 설계에 투자한 시간이 정말 정말 길었다.

이때까지만 해도 내 태도는 한결 같았다. 기억에 의하면 주제 회의 때 내가 실제로 한 말이기도 하다.

"우리가 실제 서비스를 운영하는 것은 아니지만 실제 서비스를 운영한다는 생각을 갖고 기획, 설계를 해야 서비스 완성도도 올라가고 사용자 입장에서 생각하며 개발하자"

그때 당시에 팀원들이 동의를 했고 사소한 부분 하나하나 신경 쓰면서 서비스 개발을 했다.

개발을 할 때는 뭔가 엄청난 걸 만들고 있다는 생각이 들었지만 포트폴리오에 내가 뭘 개발했는지 어떤 고민을 했는지 + Trouble Shooting을 적으려고 하면 막상 적을만한 것들이 없었다.

정말 기본적인 API들이 많았고 그 API들을 개발함에 있어서 백엔드 개발자로서 어필할 만한 부분이 없었다.

(물론 틀린 생각이라고 할 수는 없다. 그렇지만 취준생의 관점에서는 정답은 아닐 수 있다는 생각이다.)

이런 후회들을 하지 않고자 새로 시작할 프로젝트는 실제 서비스 운영관점이 아니라 백엔드 개발자로서 우리가 어떤 것을 어필할지에 대해 생각하고 이에 맞게 가져가자. 기존 서비스와의 차이점이 없더라도 기술적으로 얻어가자. 라는 것이 내가 속한 팀원들의 공통적인 의견이었다. "주제는 좁고 뾰족하게 가져가자" 라는 말이 바로 이 뜻이다.

 

주제는 '원데이 클래스 예약 플랫폼' 으로 정했다.

Kafka를 사용해야 했기에 대용량 트래픽을 처리해야 하는 서비스임을 베이스로 깔고 가야했기에 단순 원데이 클래스를 넘어서 연예인이 이벤트성으로 주체하는 클래스가 있다고 가정 했다.

ex) 에스파 윈터와 함께하는 두쫀쿠 쿠킹 클래스

 

주제를 정한 뒤에는 바로 DB 모델링 작업에 들어갔다.

이전 프로젝트에서 약 60개의 테이블을 설계하고 운영했던 경험이 있었기에 모델링에 대해서는 어느 정도 자신이 있었다. 다른 팀원들 역시 이해도가 높았기 때문에 작업은 빠르게 진행되었다.
이렇게 모델링을 마친 뒤에는 각 도메인을 어떤 기준으로 분리할지에 대한 논의를 시작했다.

그리고 이 과정에서 우리는 처음으로 MSA의 복잡함을 체감하게 되었다.