[회고] 대학생 미팅 서비스 - weave 프로젝트 회고

Intro.

어느덧 3학년의 하반기가 모두 끝나고, 겨울방학이 되었을 시점에 나는 무척이나 성장이 간절했던 것 같다.

학교 내에서의 우물 안 개구리로 남고 싶지 않아 무작정 사람들을 모아 팀을 만들고 향수 리뷰 서비스를 시작하게 되었다.

 

PM, 디자이너, FE, BE까지 총 8명이서 팀을 꾸려 회의를 가졌는데, 아이디에이션 단계부터 삐걱댔다.

각자가 프로젝트를 통해 얻고자 하는 것과 추구하는 방향성이 너무나도 달랐고, 온라인으로 쉽게 모인 사람들인 만큼 나가는 것도 쉬운 일이었다.

 

그러던 중 현직에 계신 대학교 동기 형님께서 사이드 프로젝트에 서버 팀원을 찾는다는 소식을 듣고

2024년 2월 초, weave 팀에 중도 합류하게 되었다.

 

합류한 팀의 구성원분들은 디자이너 1분, AOS 1분, iOS 2분, 나를 제외하고도 두 분의 서버 개발자가 계셨다.

다른 서버 개발자분과도 인사를 나누면서 정말 대단하신 분들과 함께 하게 되었다는 것을 실감할 수 있었다!

 

3일 내로 PR 올려주길 기대하고 있어!

처음 팀에 합류하고 나서, 동기 형님께서 나에게 3일 정도면 충분하지? 라고 말씀하셨던게 아직도 기억이 생생하다.

동기 형님이 직장 일이 바쁜 시기여서 리소스가 부족했고

이를 채우기 위해 급하게 투입된 터라 반드시 성과를 내야 하는 상황이었다.

 

하지만 해당 사이드 프로젝트에서는 코프링, 헥사고날 아키텍처, 멀티모듈 구조로 설계가 되어 있었는데

당시 자바에 mvc패턴밖에 모르던 나로써는 몹시 당황스러운 주문이었던 것 같다.

 

살짝 멘붕이 왔었지만, 지금 내가 해야 할 일들을 리스트업 한 뒤, 하나씩 차분히 진행해보기로 했다.

 

우선 합류 후에 가장 먼저 했던 것은, 팀 내 문서와 피그마를 살펴보는 일이었다.

팀에 기획자가 없어 기획 문서가 제대로 정리되어 있지는 않았지만,

피그마에서 화면별 요구사항과 제약 조건이 기재되어 있어 서비스 흐름을 잡는 데에는 큰 무리가 없었다.

나 역시 대학생이기도 하고 도메인 자체의 진입장벽이 낮아 다행이라는 생각이 들었다.

 

팀 전체 문서 말고도, 서버팀 내부에서 코드 컨벤션, 깃 브랜치 관리 전략, 기술 스택 선정 과정에서의 고민 등 필요한 내용들이 모두 잘 문서화 되어 있어 적용하기 수월했다! 이를 보면서 어느 때보다 문서화의 중요성을 체감한 순간이었고, 이후 프로젝트에서도 아무리 바빠도 문서로 기록하는 일을 절대 게을리하지 않게 되었다.

 

코틀린, 헥사고날 아키텍처 어떻게 하지..?

사실 가장 걱정이 많았던 부분이기도 하다. 그나마 자바와 코틀린이 크게 다르지 않았으므로 Getting Started부터 빠르게 답습했던 것 같다. 시간이 없어 빠르게 속독한 후 현재까지 작업되어 있는 프로덕션 코드를 보며 data class, object 등등 모르는 부분만 찾아 그때그때 해소하는 식으로 문서를 참고했다.

 

이어 헥사고날 아키텍처의 경우 처음 접했을 때에는 굉장히 신선했고, 평소에 사용하던 MVC에서 느끼고 있던 아쉬움을 시원하게 긁어준다는 생각이 들었다.

팀원분들이 <만들면서 배우는 클린 아키텍처> 책을 추천해 주셔서 날이 밝자마자 서점에 뛰어가서 책을 사서 읽어보았다. 쿡북 형태로 되어 있어서 가볍게 읽고 적용해 볼 수 있어서 굉장히 좋았다.

이후 막히는 부분이 생길 때마다 반복해서 책을 보게 되었는데 고민 끝에 책을 썼다는 게 느껴질 정도로 밀도 있는 내용들로 구성되어 있다는 것을 깨닫고 새삼 놀랐다.

 

이렇게 빠르게 훑어 보고 나니 어느 정도 프로덕션 코드가 읽히기 시작했고 그때부터는 코드 파악하는 데에만 많은 시간을 투자했다.

 

저 시간 없는데.. 이슈 문서를 작성해 달라고요?

처음 받은 티켓은 애플 소셜 로그인 구현이었다.

기존에 카카오 로그인 코드가 이미 작업되어 있어 사실상 공통 로직은 모두 작성이 되어 있었고, 애플 OAuth 처리 방식에 의존적인 부분들만 새롭게 코드를 작성하면 되는 상황이었다.

 

공식 문서를 읽던 중 동기 형님께서 애플 소셜 로그인 이슈 문서화를 제안하셨다.

우선 구두로 협의하고 추후 문서로 기록하는 것이 더 나을 것 같다고 생각했었는데, 문서는 단순히 기록 용도가 아니라 여러 이슈를 팀 내에 빠르게 전파할 수 있는 효과적인 수단이 될 수 있다는 것을 배웠다.

 

형식이 정해져 있는 것은 아니었지만 최대한 가독성 있는 형태로 적기 위해 노력했다.

애플 공식 문서를 꼼꼼히 읽던 중, 카카오 로그인과 달리

애플 로그인의 경우 email과 name 속성을 사용자 동의 하에 선택적으로 제공한다는 사실을 파악하게 되었고,

이를 iOS 개발자분들과 디자이너분들께 전달하여 관련 변경사항을 빠르게 align 할 수 있었던 것 같다.

 

이를 계기로 설계 뿐만 아니라, 팀 내에 공유해야 하는 이슈가 생겼을 때에도 가급적 문서 형태로 작성해서 공유하는 습관이 생기게 되었다!

기존에 있던 문서에 살짝 덧대어 작성한 나의 첫 이슈 문서..ㅎ

 

좋은 코드 리뷰를 통해 성장하기

3일만에 무사히 애플 소셜 로그인 PR을 올리고 서버 팀 내에서 코드 리뷰를 진행했었는데, 50개 이상의 코멘트를 받았다..🤣

내 코드가 이 정도였나..? 싶으면서 주신 피드백 하나하나를 꼼꼼히 살펴보고 고치고, 또 고쳤던 것 같다.

 

이렇게 한번 코멘트 폭격을 받고 나니 처음에는 약간 의기소침해졌던 것 같다.

후속 작업을 진행할 때에는 혹여 같은 지적을 받거나 잘못된 부분이 없을지,

작업 속도를 낮추면서도 고심 끝에 코드를 작성하고 또 살펴보았다.

 

초기에 주로 받았던 피드백이 너무 많아 한번 정리하는 시간을 가졌는데, 크게 두 가지였다.

 

1.  코드 컨벤션(린트 설정) 및 kotlin style의 코드 작성법(trailing commas, scope function, 예외 처리 등)

2. 코드 및 로직 작성의 근거

 

우선 코드 컨벤션의 경우 팀에서 채택하고 있는 기본 code style, lint가 제대로 작동했는지 체크하는 것과 더불어 EOF같은 컨벤션도 처음 알게 되었다!

또한, trailing commas 같은 경우 코틀린 공식 문서 초장에서 강조하던 내용이었는데 문서를 속독하다 보니 놓쳤다는 생각이 들었고, 작업 중간에 짬이 날 때마다 공식 문서를 살펴보았다.

 

나중에 안드로이드 개발자분께 여쭤봐서 알게 된 내용이지만 scope function의 경우 의외로 취향껏 사용하시는 분들이 많다고 하셨다..!

 

하지만 2번의 경우 코드 작성 근거를 100% 명확히 설명하지 못하는 경우가 종종 있었고, 그때마다 코드 리뷰의 티키타카가 원활하게 되지 못했다. 그때마다 리뷰어가 제시한 대안을 일방적으로 수용하는 형태에 가까웠다.

 

처음에는 단지 나보다 실력이 뛰어난 분들 의견을 적극적으로 수용하면서 많이 배우자! 라고 생각했었는데, 지금 돌아보면 안일한 생각이었던 것 같다.

 

여러 스프린트가 끝나고 서버 리드분과의 1on1 기회가 있었는데, 감사하게도 거기서 원준씨와 코드 리뷰 티키타카를 좀 더 잘 해보고 싶다는 피드백을 주셨던 터라 이후부터는 항상 작성하는 코드마다 명확한 작성 근거를 제시할 수 있도록 꾸준히 연습했던 것 같다.

처음에는 좋은 생각이네요!, 반영하겠습니다! 와 같은 답글이 주였지만

프로젝트 마무리 단계에서는 저는 A라고 생각해서 이렇게 작성했는데, 주신 B 의견도 너무 좋은 것 같아요~ 와 같이 근거를 함께 제시할 수 있었고 팀원들과 함께 논의하며 최선의 방법에 더욱 가까워질 수 있었다.

 

추가적으로 코드 리뷰 관련해서도 뱅크셀러드 코드 리뷰 문화(https://blog.banksalad.com/tech/banksalad-code-review-culture/) 글을 읽고 팀 내에 적용하였더니 많은 도움이 되었다! 혹시 이 포스트가 처음이라면 반드시 읽어보면 좋을 것 같다!

 

밀도 있는 협업을 위한 데일리 스크럼

보통 협업을 하다 보면, 일정관리에 실패하여 MVP 출시 일정이 뒤로 밀리는 경우가 다반사이다.

결과적으로 우리 팀은 앱 심사 기간 전까지 큰 일정 조정 없이 기한 내에 마무리 할 수 있었다.

이때, 데일리 스크럼이 큰 도움이 되었다고 생각한다.

 

우리 팀의 경우 격일 단위(월, 수, 금)에는 데일리 스크럼을 진행하고 일요일에 스크럼 및 정기 회의를 함께 진행하였다.

스크럼 시에는 Jira 칸반 보드를 이용하여 각 포지션별 진행 척도를 함께 파악하고 공유하였으며, 관련하여 각자가 작업한 내용이나 작업 중에 문제가 발생한 경우 그 즉시 공유가 빠르게 이루어졌다. 

 

또한 단순히 작업 내용 공유에서 그치지 않고, 전체 계획한 진도에서 어느 정도 위치에 와 있는지를 함께 리캡하여 최대한 기한 내에 성과를 거둘 수 있도록 팀의 목표를 잘 설정했던 것이 좋은 결과로 이어졌던 것 같다. 

 

이와 더불어, 우리 팀은 소통 채널로 디스코드를 활용했는데

디스코드 멘션을 보내면 짧게는 수분 내에, 길어도 1~2시간 내에 response를 기대할 수 있었다.

나도 요청사항이 왔을 때 최대한 즉각적으로 답변하려고 노력했고

추후 팀 KPT 회고를 진행했을 때 우리 팀의 Keep에는 빠른 응답 시간에 대한 언급이 항상 있었다.

 

헥사고날 아키텍처의 필요성에 대해

습관적으로 사용해 오던 레이어드 아키텍처에서 벗어나, 클린 아키텍처의 대표적인 모델인 헥사고날 아키텍처를 적용했다. 

 

가장 크게 느꼈던 장점으로는, 우선 의존성 변경사항이 발생 시 adapter 이후로만 갈아끼워 주면 된다는 점에서 굉장히 편리했다.

 

A의존성을 B의존성으로 변경해야 하는 경우, 만약 mvc 패턴을 사용했다면 service layer 전반에 변경사항이 전파되는 반면 헥사고날 아키텍처에서는 outbound port를 인터페이스 형태로 구현하여 결합도를 느슨하게 유지하니, 변경사항이 서비스 로직 내부로 전파되지 않는다. 또한, 도메인 객체와 JPA 엔티티를 분리하고 나니 외부 dependency 없이 순수 비즈니스 로직에 대한 구현을 고민하고 격리성 있는 테스트가 가능해졌다는 점도 좋았다.

 

하지만, 장점이 있으면 단점도 있다. 우선 weave 서비스의 경우 mvp 단계에서 주어진 요구사항으로는 외부 dependency를 연쇄적으로 호출하거나, 변경이 잦은 도메인은 아니었던 것 같다. 물론 개개인의 숙련도에 따라 편차는 있겠지만 일반적인 레이어드 아키텍처보다는 많은 개발 리소스를 필요로 한다는 점에서 필요성에 대해 의구심이 생겼던 것 같다.

 

모든 개발 방법론이나 설계에는 장단점이 있고, 상황에 맞게 적절한 아키텍처를 선택하는 것 역시 정말 중요한 일임을 다시 한번 생각해 보게 되었다.

 

Outro.

weave 팀에서 두 달간의 작업 후 MVP 출시 준비가 된 시점에, 나는 소프트웨어 마에스트로 15기에 선발되어 운영 단계에는 참여하지 못하게 되었다. 이후에 들었던 이야기지만, 서비스가 유저 확보에 어려움을 겪어 런칭까지는 가지 못했다고 한다.

 

사실 내가 이 프로젝트에 참여 했을 때에는, 이미 기획과 hi-fi GUI 디자인까지 모두 완성되어 있던 시점이었던 점도 있었지만 

기획 단계에서도 사용자 관점에서 정말 필요로 하는 서비스인지, 타겟을 명확히 이해하고 그들의 문제점을 해결할 수 있는 기획이 있어야 사용자들을 사로잡을 수 있다는 생각이 들었다.

 

또한 사이드 프로젝트 특성상 홍보 루트가 한정적이라는 점도 아쉬웠다. 별도의 마케팅 비용을 투자하기가 어려우므로, 기획 단계에서 위와 같은 사항들도 함께 고려했으면 더욱 좋았을 것 같다.

 

때문에 이후에 진행하고 있는 2개 프로젝트에서는 모두 PO 역할을 맡아 기획 부분에서 적극적으로 아이디어를 제시하고 고도화하였고, 지금까지도 두 서비스를 꾸준하게 운영하고 있다 :)

 

돌이켜보면 두 달동안 뛰어난 팀원들과 함께 프로젝트를 하면서

개발 실력은 물론, 일을 잘 하는 방법과 좋은 협업문화를 경험할 수 있어서 정말 많이 배우고 성장했다.

앞으로도 이러한 기억과 경험을 살려 좋은 팀원, 함께 일하고 싶은 사람이 되기 위해 끊임없이 노력하고자 한다.