올해 첫 사이드 프로젝트를 끝내며

들어가면서

2023년 취업 시즌이 돌아오기 전에 Spring 학습을 할지 고민하다가 좋은 타이밍에 프로젝트를 같이 하자는 제안을 받아, 1월이 되자마자 프로젝트를 시작하게 되었다.

개인적으로 전력을 다할 수 있는 날이 1월 말까지였고, 2월 부터는 회사 복귀를 해야해서 혹시나 민폐가 되지않을까 했지만 팀원들이 다들 괜찮다고 해주셔서 잘 마무리할 수 있었다.

또 제 몫을 못하면 스스로 스트레스 받는 스타일이기 때문에 2월부터는 퇴근 후에 스터디 카페에 가서 프로젝트 끝날 때 까지 단 하루도 빼놓지않고 새벽 2시까진 하다가 집가서 쓰러져 자곤했다.

아무튼 또 시간이 지날 수록 결과만 남고 과정들이 흐릿해지기때문에 회고를 남겨본다.

KPT

Keep

지속할 것

공부 한 내용을 개념, 동작원리, 문법 으로 나누어 정리하기

부스트 캠프를 하면서 배운 큰 자산 중 하나가 꾸준한 학습정리였다. 편하게 정리하고자 블로그에는 쓰지 않았지만 Notion을 통해 Spring 관련 학습정리를 꼼꼼하게 했다. 이전에 부스트 캠프를 할 때는 새로 알게되는 웹 도메인 지식 별로 하다보니 정작 Nest JS에 대한 부분을 상세하게 못했다는 아쉬움이 들었고 Spring은 관련 한국어 레퍼런스가 김영한님의 강의 중심으로 엄청나게 많기 때문에 도움을 받은 자료들을 잘 정리해나아갔다. 회고를 쓰면서 Nest JS 학습 정리를 다시 살펴봤는데 그래도 많이 했다.

Spring 핵심원리와 MVC를 아마 김영한님 강의를 1년전에 사두고 못본게 있어서 프로젝트 시작하기 전에 1~2주간 잠-식사-학습 만 하면서 학습에 투자를 했다.

개념, 동작원리, 문법으로 나누어 정리를 하는 것은 이번에 처음 해봤는데 나중에 모르는 것을 바로 찾기에 편해서 좋았다.

설계, 고민한 사항 글로 남기기

프로젝트는 주2~3회 온라인 스크럼, 주 1회 오프라인 모임을 하면서 진행했었다. 주 1회 오프라인 모임이 있긴 했지만 아무튼 매일 같이 모여서 하는 것은 아니다보니, 초반에 설계를 확실히 한 다음 업무 배분을 하는 것이 다음 일을 정할 때 붕 뜨는 것 없이 좋았다.

같이 작성한 것도 있고 따로 맡아서 작성한 것도 있는데, 거의 반반씩 작성한 것 같다. (백엔드 2명) 이 중 kakfa는 처음 학습하면서 애를 많이 먹어서 공유하면 누군가에게 도움이 되지 않을까 하는 마음과 query 개선기는 꼭 지금 프로젝트가 아니더라도 좀 범용적이면서도 실용적인 이야기인 것같아 블로그에도 남겨두었다.

아무튼 이전에는 개발을 다 하고 글을 쓰다보니 기억이 많이 휘발되어 아쉬웠는데 이번에는 개발이 좀 지체되더라도 최대한 글을 같이 작성하다보니 그 당시에 우리가 왜 그렇게 생각했는지를 잘 알 수 있어서 좋았다.

이 외에도 백로그 작성, 스크럼/주간 계획을 세우는 등 모든 프로젝트 활동은 팀 Notion workspace를 활용했는데 이건 부스트 캠프를 하면서 했던 내용이므로 길게 적지는 않겠다.

Problem

문제가 된 것

이부분은 사실 면접에서 자신의 단점이 뭔가요?라고 물었을 때 진짜 치명적으로 다가올 수 있는 단점을 이야기하는 것 처럼 썩 좋지는 않을 수 있지만 그대로 좀 솔직하게 작성해보려고 한다.

PR 리뷰 시 검증 여부 check

나는 뭐 내가 실수하면 스스로 용납을 잘 안하는 스타일이기도 하고 검증을 일로 하던 사람이기 때문에 Input, Output 이 정확한지 Side effect은 없는지, Input case를 여러개 넣어보면서 자체 검증을 많이 했다. 검증병임 사실 근데 문제는 다른 팀원이었는데 우리는 대부분의 코드를 PR 승인을 해야 Merge를 하는 규칙을 가지고 있어서 상대방의 코드를 거의 다 리뷰했었다.

아무래도 Code만 확인하고 실제로 이 branch를 당겨서 내가 실행해보지 않았기 때문에 신뢰성이 좀 떨어졌지만, 내가 일일히 왈가왈부하기엔 좀 조심스러워서 Code level에서 확인했을 때 눈에 띄는 hole이 없으면 Code 자체의 개선점이나 질문을 위주로 comment를 남겼다. Code만 확인해서는 사소한 버그를 찾는게 좀 어려운 것 같다.

아무튼 이렇다 보니, 가끔은 PR 설명이 너무 없고 Code가 이거 검증 된거 맞나? 하고 진짜 의심될 때가 있었다. 여기다가 이제 Frontend에서 버그 신고가 들어왔다. 그때가 되서야 검증했냐고 물어보니 데이터가 부족해서 안했단다. (OMG) 그래서 최대한 기분이 덜 상하게끔 현재 데이터가 좀 부족하더라도 데이터를 강제로 넣어서 검증해보고 Output도 좀 첨부해주면 PR 리뷰하는데 도움이 될 것 같다고 조심스럽게 요청드렸더니 그때부터는 Test code 작성이나 검증 내용을 첨부해주셨다.

PR을 최소단위로 올려서 Code 자체가 하나의 관심사를 가지고 있도록 하는 것도 중요하지만, 이때 나도 상대방이 이해하기 편한 PR에 대한 고민들을 좀 했고, 상대방의 PR을 보면서 내가 검증도 다 해보고 리뷰 해야할까에 대한 고민을 하게되었다.

복잡한 비지니스 로직을 분담해서 작성하는 것

이번 프로젝트에서 가장 긴 비지니스 로직만 140 line 이었다. 주식 매도/매수 요청이 들어왔을 때 이를 처리하는 과정인데, 내가 매수 기능을 우선 맡아서 진행하고, 이후에 다른 팀원이 매도 기능을 작성하는 것으로 역할을 분담했었다.

매수, 매도가 반대의 상황이지만 Code level에서 보면 어느정도 겹치는 사항이 있기 때문에 나도 코드를 작성하면서 최대한 공통 로직으로 사용할 수 있는 부분들을 함수화했었다.

매수기능을 완성하고 2~3주 후에 매도 기능 구현을 위해 다른 팀원이 PR 리뷰를 하긴 했었지만 코드를 다시 확인하면서 Kafka에 대한 부분이 서로 생각을 다르게 한 부분이 있었다. 이때 서로 띠용 상태가 되어서 카톡으로만 이야기하기엔 무리가 있는 것 같아 페어 프로그래밍을 제안하셔서 토요일 오전부터 날을 잡고 진행했다.

서론이 길었는데, 요지는 비지니스 로직이 길다보니 서로 이해하기가 좀 힘들어 꼭 하나의 로직이더라도 PR을 좀 더 세분화 하면 이해하기 쉬웠겠다는 생각을 했고, 페어 프로그래밍을 하면서 같이 작성하고 리팩토링 하면서 상호간에 생각한 것을 맞춰보는 시간이 의미있었다.

페어 프로그래밍을 했던 이야기로도 글 하나는 작성할 수 있을 것 같은데 무슨 오전 11시에 시작해서 저녁 7시반에 끝났다. 방식은 한명이 주석이나 피피티로 설명을 적으면 다른 한 사람이 그에 맞게 작성했고, 의도와 다르면 같이 이야기하면서 다시 작성했다. 이전에 부스트 캠프 학습 스프린트 마지막 주차에 리액트를 배우면서 할 때는 뭐라고 작성해야할지 잘 몰라서 어.. 잠시만요 하고 찾아보는 시간이 길었지만, 이번에는 그래도 코드 작성은 익숙해서 한번에 생각나는대로는 바로 작성할 수 있어서 좋았다.

Try

다음에 시도할 것

상용화를 고민해보기

이번 프로젝트는 나에게 Spring 학습의 모터를 달기위해 시작했다고 해도 과언이 아니다. 사실 나는 참신한 프로젝트 주제를 잘 못내는 타입이고 처음 팀을 제안해준 팀원이 기획을 어느정도 하고와서 기획에 대한 것은 가상의 거래 플랫폼이여서 실제 사용자가 없었다.

그러다보니 버그 확인도 전부 팀원들끼리 크로스체크로 Postman에서 잘 동작하는지, 배포 사이트에 직접 들어가 확인해본 것에 그쳤다.

그래서 다음에 또 사이드 프로젝트를 하게 된다면 실 사용자를 모을 수 있는 프로젝트를 하면서 우리 외에도 다른 사람들의 의견을 들어보고 지금의 프리티어 서버에서 얼마나 많은 트래픽을 실제로 감당할 수 있는지 좀 느껴보고 싶다.

DB Query 작성 연습을 더 해보기

JSON 상하차를 하면서 Query 작성하는데 시간을 제일 많이 사용한 것 같다. 전보다 Table도 많고 JOIN이 많이 엮여있던 점과 QueryDSL이 좀 어려워서 많이 해맸던 것 같다. 그래서 요즘 프로그래머스에서 SQL 문제를 하루에 하나 씩 풀고있는데 실력이 좀 더 늘었으면 좋겠다.

이것저것 붙인다고 다 좋은게 아니다

프로젝트 MVP 기능을 마무리하고 개선할 수 있는 부분들을 찾으면서 캐싱에 대한 부분들을 검토했었다. 캐싱이 가능한 부분들을 몇 군데 찾아 기존 코드에서 어떻게 수정하면 될지까지 재설계를 다 해둔 상태였는데, 최근 면접을 보면서 좋다고 다 캐시에 저장하면 실제 상용화 한다고 가정했을 때 Redis의 비용적인 측면을 고려하더라도 유용한 캐싱이냐는 질문을 받았다. 사실 캐싱하면 응답 속도를 개선 시킬 수 있으니 좋지! 까지만 생각했던 내 자신이 조금 부끄럽게 느껴졌다. 물론 검토를 하면서 Update가 이후에 일어나지 않을 것으로 예상되는 부분에 대해서 고려하긴 했지만, 그 보다 더 깊게까지 생각을 해보지 않았다는 것을 깨우쳤다.

마무리

KPT 위주로 작성하다보니 트러블 슈팅과 관련된 부분은 거의 안적은 것 같..지만 막히는 부분이 있을 때 마다 따로 멘토도 없고 현업을 하지않다보니 물어볼 곳이 없던게 좀 힘들었다. 새로운 팀원들을 만나 인사이트도 넓힐 수 있었고, 부스트 캠프를 하면서 했던 6주간의 프로젝트보다 더 긴 기간동안 진행했기 때문인지 TO-DO 리스트 수준에서 벗어난 다른 프로젝트를 해보고 싶다는 고민에서 좀 벗어날 수 있었던 것 같아, 같이 고생한 팀원들도 고맙고 나에게 의미있는 프로젝트였다.