Beerlot 프로젝트 첫 번째 회고
Beerlot v0.5.0-alpha release를 기념하며 작성하는 회고
개요
올해 8월부터 새로운 토이 프로젝트를 시작했다. 서비스명은 Beerlot(비어랏)으로, 이름에서 알 수 있듯이 맥주를 테마로 하는 일종의 커뮤니티 서비스이다. ‘맥주가 많다(Beer가 lot하다)’와 ‘맥주(잔)을 비어랏!’의 두 가지 의미를 가지고 있다. 나의 취향을 아주 제대로 저격한 프로젝트라고 말할 수 있겠다.🤩
🔽 내가 2년 동안 독일에서 마셔본 맥주 병뚜껑 모음 
프론트엔드 개발자님이 제안해주신 Agile 회고 방식 중 하나인 KPT 회고를 따라 작성해보려고 한다.
K(Keep)
K1: 팀원들의 동일한 목표
팀 단위의 토이 프로젝트에서 가장 중요한 것은 각자 프로젝트에 대해 가지고 있는 목표&기대라고 생각한다. 팀원은 총 3명으로 각각 프론트엔드 개발자 1명, 백엔드 개발자(나) 1명, 기획 및 디자이너 1명이다. Beerlot 프로젝트를 시작하면서 내 개인적인 목표는 크게 두 가지였다.
- 회사에서 사용 중인 Google Cloud Platform 연습하기
- 실사용 유저가 있는 서비스 운영하기
특히 두 번째 목표에 덧붙여, 유저의 피드백을 받아 다음 버전 업데이트에 반영하면서 확장해나가는 형태의 서비스를 구축하고 싶었다. 프로젝트가 중/장기적일 수 밖에 없다. 만약 팀원 중 하나가 포트폴리오 목적으로 2달 안에 뚝딱 만들어야하는 프로젝트를 기대했다면 모두가 만족하는 결과물을 얻기 힘들 것이다.
K2: 체계적인 프로젝트 관리
프로젝트 관리는 노션을, 소통은 슬랙을 이용해서 하고 있다. 노션이라는 툴이 자유도가 높은 만큼 서로가 이해하고 편하게 쓸 수 있는 보드와 템플릿을 만들기 위해 초반에 시간을 좀 들였다. 결과는 대만족!
🔽 Beerlot의 칸반 보드 
🔽 Beerlot의 아이디에이션 보드 
v1.0.0 릴리즈에 해당되지 않는 아이디어들이 많다. 나중에 하나씩 다 구현해나갈 수 있으면 좋겠다.🙃
🔽 Beerlot의 마일스톤 
K3: v0.5.0-alpha 버전 배포
v1.0.0 배포를 하기 전에 internal용으로 중간 버전인 v0.5.0-alpha를 배포하기로 했다. 이건 예전에 했던 토이 프로젝트에서 경험한건데, 중간 버전을 배포하면 단기적인 목표에 좀 더 집중할 수 있고, v1.0.0을 배포하기 전에 한 번 더 점검할 기회가 생긴다. 수능 치기 전에 여러 번 모의고사를 치는 것과 같은 느낌이랄까… 정말 최소한의 기능만 계획해서 v0.5.0-alpha의 마감 기한을 정했다. 도달하지 못한 목표도 있었고 버그 투성이지만 어찌됐건 2달 만에 Beerlot앱이 탄생하게 되었다.
K4: 적당히 쉬는 것도 기술
v0.5.0-alpha 배포를 준비하면서 꽤나 달렸다. 마지막 일주일은 마침(?) 비가 쏟아져서 재택 끝나고 집에서 콕 박혀 작업만 했다. 배포하는 날 회의에서 프론트엔드 개발자님이 1주일의 휴가를 제안했다. ‘지쳤으면 -> 쉰다’ 당연한건데 쉴 생각을 못했다. KPT 회고를 쓰는 것도 그 분의 제안인데 그 동안의 시간을 정리하면서 앞으로의 더 보람찬 시간을 기대해본다.
P(Problem)
P1: 코드 품질
테스트 코드를 작성하다가 마감 기한에 임박하면서 테스트 코드 작성을 리펙토링 바로 앞으로 미뤄버렸다. 코드 품질을 보장하는 유일하면서 최소한의 장치였는데 API를 넘겨주는 게 우선이라는 생각에 그랬던 것 같다. 반성한다 나 자신…
P2: 일정 관리
프론트엔드 개발자와 디자이너는 화면 단위로 일정을 맞추어 나갔다. 이 화면 단위의 일정이 백엔드인 내 입장에서는 좀 애매하게 느껴졌다. 작업의 복잡도가 화면의 복잡도와 상관이 없어서일까… 예를 들어, 메인 화면을 제일 먼저 만든다고 가정해본다. 메인 화면에는 사용자가 남긴 리뷰의 별점을 기준으로 인기 맥주를 보여준다. 아무것도 없는 제로 코드에서 이 API 하나를 만들기 위해서는 생각보다 고려해야할 것이 많다. 연관된 엔티티가 많기 때문이다. 인기 맥주 관점에서 보면 맥주, 사용자, 리뷰가 연관되어 있고 맥주 정보 카드 관점에서 보면 맥주, 카테고리, 태그 등이 연관되어 있다. 즉, 인기 맥주 10개를 뽑기 위해서 맥주 엔티티뿐 만 아니라 사용자, 리뷰, 카테고리, 태그 등을 고려해야한다.
T(Try)
T1: Code Coverage 측정 & Quality Gate 제한
Code coverage 측정하는 JaCoCo, Quality gate를 설정하는 SonarQube와 같은 툴을 이용해서 GitHub에서 merge하기 전 Quality gate 통과 못했을 때 merge를 제한하는 방식으로 약간은 반강제적이지만 코드 품질을 상승시켜 유지할 수 있는 방법을 도입해야겠다.
T2: Swagger 적극 활용 & 기능 위주의 일정 조율
이 부분은 팀원들이랑 한 번 얘기해봐야겠지만 내가 생각하는 방안은 Swagger를 적극 활용해서 내가 당장 만들기 어려운 API는 API 명세를 우선 작성해 Mock 응답을 참고해달라고 프론트엔드 개발자님에게 양해를 구한다.
두 번째 방안은 이상적인 API 개발 순서를 정해 프론트엔드 개발자님의 작업 순서와 비교해 조율하는 것이다.
추가로 KPT에 해당되지는 않지만 그동안 어려웠던 점을 정리해보려고 한다.
어려웠던 점
결정도 혼자, 책임도 혼자
기획 및 디자인, 백엔드, 프론트엔드 각 분야 당 1명이 맡고 있기 때문에 백엔드 내 결정해야할 것들은 나 혼자의 몫이 되었다. 초반에 프로젝트 셋업하는 과정에 시간을 많이 썼다. ‘JPA를 쓸까? MyBatis를 써볼까?’ ‘좀 더 깔끔한 API 문서 없나?’ 백엔드 기술 스택을 결정하는 것조차 쉽지는 않았다. 심지어 OpenAPI Generator는 포함시켜 개발하다가 우리 프로젝트에는 효율적이지 않은 것 같아서 뺐다가 결국엔 욕심이 나서 해결방법을 모색해 다시 넣었다. 꽤나 울고 싶었다…🥲
CI/CD = Heaven beyond Hell
Beerlot의 백엔드 서버는 Github Actions를 이용한 CI/CD를 통해 GCP Cloud Run으로 배포된다. 테스트 -> 빌드 -> 도커 이미지 생성 -> Artifact Registry에 도커 이미지 배포 -> Cloud Run의 과정을 거치는데 CD 워크플로우만 64번 시도 끝에 성공했다. 빨간색을 좋아하는 개발자도 있을까…? 
CI/CD 파이프라인을 구축해두니 하루에 여러 번 배포를 해도 작업량에 부담이 없기는 하다.
마치며
열정적인 팀원들과 앞으로가 기대되는 프로젝트이다. v1.0.0 release는 나에게 주는 2023년 새해 선물이 될 예정이다!🎁