들어가며
23년도에 카카오 클라우드 스쿨에서 열심히 개발하던 때에 사라마라(Saramara) 라는 아이디어를 기획하고 팀원들을 모집하여 개발을 시작했어요. 최종 프로젝트도 아니고 단순 과제 제출용으로 시작했던 프로젝트였지만, 조금씩 조금씩 꾸준히 개발하는 습관을 들일 수 있었던 프로젝트가 되어주었고, 앞으로도 그럴 예정이에요. 아직도 많이 부족하고 대단한 퀄리티의 결과물이 나오진 않았지만, 협업을 통한 성장이라는 목적을 위해 점진적으로 개발해나갈 예정입니다.
동료들과 팀 프로젝트를 진행하며 무엇을 얻었고, 어떤 것이 부족했는지 리뷰하며 보다 명확한 메타인지를 할 수 있었네요. 그래서 이번 글에서는 팀 프로젝트를 시작해서 지금까지를 돌아보며, 질문지를 작성해보았어요. 이 질문에 답변하는 방식의 글로써 후기를 남겨보려 해요.
아래 5가지 질문에 대한 답변을 고민하면서 다시 한번 도전을 받았고, 또 다른 성장의 기회를 잡기 위해 부단히 노력하자는 동기부여를 얻을 수 있었습니다.
Q1. 담당한 업무는 무엇인가요?
Q2. 프로젝트를 개발하며 어려웠던 점은 무엇이었나요?
Q3. 부족하거나 아쉬웠던 점이 있다면 알려주세요.
Q4. 아직 개발 일정이 남아있는데, 앞으로 개선 사항은 무엇이라고 생각하시나요?
Q5. 개발하면서 느끼셨던 총평을 한~두마디 정도로 요약해서 이야기해주세요.
Q1. 담당한 업무는 무엇인가요?
진행한 팀 프로젝트는 평범한 게시글 기반 커뮤니티의 형태로 기획했는데요. 백엔드 기준으로 제가 담당했던 비즈니스 요구사항은 다음과 같았어요.
- 투표 기능 요구사항 구체화
- 게시글을 관리할 수 있는 API 개발
- AWS S3 버킷에 이미지 파일을 저장하는 API 개발
이와 더불어, 주도적으로 도입을 이끌거나 품질 향상에 많은 관심을 두었던 주제나 이슈는 아래와 같아요.
- 코드 리뷰
- 테스트 코드
코드 리뷰와 더불어 비즈니스별로 테스트 코드를 작성하는 데 거의 대부분의 시간을 쏟아부었던 것 같아요. 코드 리뷰를 어떤 방식으로 진행했고 또, 테스트 코드는 어떻게 작성했는지에 대한 내용은 이후 질문에서 구체적으로 이야기 해볼게요.
Q2. 프로젝트를 진행하며 만족스러웠던 점은 무엇이었나요?
꾸준한 코드 리뷰
보통 사이드 프로젝트나 팀 프로젝트를 한다고 하면, 데드라인을 정해두고 제품화를 목표로 진행하거나 수익 창출을 목표로 개발하기도 하는데요. 저희가 원하고 지향했던 프로젝트의 목적은 "동료와 협업하기" 였어요. 기술적인 내용을 반영하는 것도 중요하지만, 팀 구성원 각자가 가진 생각와 아이디어를 어떻게 팀원들에게 제안하고, 설득시킬 것인지부터 시작해서 팀원들의 오랜 시간 고생이 담긴 코드를 담백하게 피드백하는데 초점을 두고 개발하고 싶었어요. 비록 화면 기획과 티켓 관리는 조금 소홀했을 수도 있지만, 소스 코드 리뷰에 대해서는 진심으로 진행했다고 말할 수 있어요!
모든 커밋이 생산성과 직접적으로 연관된 커밋이라고 할 수는 없지만, 특정 이슈나 티켓에 대한 개발내역 반영을 위해 커밋을 어떻게 잘게 쪼개야 할지 조금은 알 수 있었어요. 그리고 3명의 팀원들과 대략 70개의 PR을 진행하여 Merge시킬 수 있었네요.
비록 Request Changes를 적극 활용하진 않았지만, 리뷰이가 리뷰를 요청할 때 특별히 피드백받고 싶은 부분에 코멘트를 미리 남기어 리뷰어의 소중한 시간을 아낄 수 있었답니다.
테스트 코드 익숙해지기
프로젝트의 기술적 난이도가 그리 높지 않아, 코드 품질과 더불어 테스트 코드를 작성하는 데 많은 시행착오를 겪었어요. 특히나 팀원들 모두 테스트 코드를 작성하는 것이 익숙하지 않다보니, 불필요한 테스트 케이스를 만들어내거나 실패하는 테스트 코드를 성공으로 돌려놓기 위해 오랜 시간을 투자하는 등 많은 삽질이 동반되었어요. 그런데 이 삽질 하나하나가 테스트를 작성하는 안목을 기르는데 너무나 귀중한 경험들이 되었어요.
작성한 테스트 코드의 중복을 줄이고 가독성을 늘리기 위해 Describe-Context-It 패턴을 활용하여 계층 구조의 테스트 케이스를 짜보기도 하고, 테스트 케이스마다 사전에 요구되는 given절의 테스트 픽스처를 어떻게 제공할지 고민하다 Object-Mother 패턴을 기반으로 Enum 타입의 픽스처를 구성하기도 했어요. 그리고 전체 테스트가 수행될 때 통합 테스트를 위해 실행되는 테스트 컨텍스트 실행 빈도를 줄이기 위한 캐싱 방식도 고민해보고, 도커 컨테이너를 통해 테스트를 수행할 수 있는 테스트 컨테이너도 도입해보기도 했네요. 이렇게 테스트 코드를 작성하는 데 몰입하고 재미를 붙이다 보니 시리즈로 5개의 글을 작성할 수도 있었어요.
아직도 모든 케이스마다 적절한 테스트 케이스를 작성하는 데는 시간이 좀 걸리겠지만, 왜 테스트 코드를 작성해야 하는지, 또 테스트 코드가 가져다주는 이점은 얼마나 큰지 명확하게 인지하고 동료와 의견을 주고받을 수 있는 자신이 생겼답니다.
동료와의 라포 형성
해당 팀 프로젝트는 카카오 클라우드 스쿨에서 만난 동료들과 시작했고, 카카오 클라우드 스쿨 수료 이후에도 쭉 이어져오고 있는데요. 덕분에, 반년정도 잠깐 스쳐 지나가는 관계 정도에서 끝날 수 있었던 인연을 더 깊은 관계로 발전시킬 수 있었어요. 함께 개발 이야기도 하고, 일상 이야기도 하고 맛있는 음식 이야기도 하며 서로의 커리어 영역뿐만아니라 라이프 사이클의 영역까지 공유를 하게 되는 사이로 발전하게 되었는데요. (여자친구도 아니고) 동료들과 서로 구체적인 피드백과 인정, 감사, 독려를 아끼지 않았던 것이 각자의 강점을 강화시켜 프로젝트 완성도를 높이는데 큰 영향을 주었던 것 같아요.
지금 생각해보면, 만남의 목적이 프로젝트 완수가 아닌 관계를 형성하는데 초점을 두고 지내왔기에 지금까지 선한 영향력을 줄 수 있는 모임으로 확장되지 않았나 생각이 듭니다. 물론, 프로젝트 개발을 위해 모였다가 열심히 떠들기만 하고 일정을 미룰 때도 있었어요. 그래도 지인과 친구의 사이에서 줄다리기하는 관계가 되다보니 솔직하고 담백하게 모임을 이끌어갈 수 있었다고 느낍니다.
💡 간단 3줄 요약
- 코드 리뷰를 통해 프로젝트 전반적인 코드의 품질에 신경쓸 수 있었다.
- 핵심 비즈니스 도메인에 대한 계층별 테스트 코드를 작성하는데 몰입했다.
- 프로젝트가 끝나도, 언제든 연락하고 만나 편하게 이야기를 나눌 수 있는 동료를 만들었다.
Q3. 부족하거나 어려웠고, 아쉬웠던 점이 있다면 알려주세요.
비즈니스 요구사항 도출
저를 포함한 3명의 팀원 모두 개발에만 집중하다보니, 기획적인 요소에서 많은 러닝커브가 있었어요. 오프라인 미팅을 통해 결정한 요구사항을 제대로 리뷰하지 않거나, 핵심 도메인 기획을 위해 중복되는 내용을 몇 주에 걸쳐서 이야기하다보니 충돌이 되는 부분이 생겨서 다시 원점으로 돌아와야 했던 적도 있었네요. 비즈니스 요구사항을 추려내면서 개발을 하는데 기획 요소가 정말 중요하고 잘 설계되어야 하는구나 느낄 수 있었어요.
이후에는 미팅을 진행하며 대두되는 즉각적인 이슈들은 깃허브 프로젝트로 관리하였으며, 피그마를 이용해 의사결정한 내용이 온전히 머릿속에 남아있을 때 화면 기획까지 그려두는 작업을 추가적으로 진행하며 서로가 가지는 도메인 지식을 팀원 모두가 온전히 이해할 수 있도록 노력했어요.
그리고 번뜩이는 아이디어나 인사이트를 발견했을 때면, 슬랙 채널에 공유하여 의견을 주고 받는 등 팀원들과 소통 채널을 확장하고 유지하니 각자가 맡은 티켓 내용에 대한 맥락을 모든 팀원이 어느 정도 이해한 채로 개발할 수 있는 수준으로 끌어올릴 수 있었어요.
겸손하지 못한 협업 자세
지금 생각해보니 정말 부끄럽지만, 팀원들의 코드를 보며 리뷰를 진행할 때면 확증편향을 겪게되어 오만한 자세로 피드백을 전달할 때가 있었어요. 하나의 예시로 제가 이전에 동료의 PR에 코멘트했던 내용을 가져와 보았는데요. Green Case와 Red Case에 대한 테스트 코드를 분리하여 작성해본 팀원의 아이디어를 공감을 못할지언정, 제대로 된 논리없이 부정하는 듯한 코멘트를 작성했다고 느껴집니다. 이 오만한 피드백에 대해서 분명히 해명할 이유가 전혀 없었는데 해당 팀원분은 리코멘트로 너무나도 친절하게 해명 아닌 해명을 해주었고, 긍정적인 반응으로 저를 더 부끄럽게 만들었답니다. 이후 팀원에게는 개인적으로 사과했고, 이후에는 최대한 객관적으로 코멘트를 하려고 노력했어요.
💡 간단 2줄 요약
- 비즈니스 요구사항을 도출하는데 소통에 많은 어려움을 겪었다.
- 코드 리뷰를 하는데, 팀원의 의도와 목적을 이해하지 못한 채 오만한 마음으로 피드백을 남겨버렸다.
Q4. 아직 개발 일정이 남아있는데, 앞으로 개선 사항은 무엇이라고 생각하시나요?
서비스 제품화 및 내부 구조 개선
앞으로 해야할 일정은 뻔한 이야기지만 제품화와 코드 품질 유지보수를 위한 리팩토링의 반복이 이어질 것 같아요. 가장 먼저로는 좀 더 새로운 동기부여를 받고, 사용자 피드백을 받기 위한 준비로 제품화를 위한 개발을 진행하고 있어요. 조악한 형태라도 프론트엔드와 백엔드 개발을 통해 프로토타입 도출을 목표하고 있답니다.
백로그에 쌓인 티켓이 아직도 많아요. 테스트 케이스를 추가하고 시스템 정책 구체화 및 매직넘버 관리 등과 같은 기술적인 개선점뿐만 아니라 Swagger와 Rest Docs를 섞어 프로덕션 코드를 줄이고 문서화 기능은 강화할 수 있는 문서화로서의 구조로 확장하는데도 꽤나 신경을 쓸 에정입니다.
Q5. 개발하면서 느끼셨던 총평을 한~두마디 정도로 요약해서 이야기해주세요.
프로젝트를 진행하고 개발하며 몸소 느끼고, 고민했던 순간들을 한 두마디로 줄일 수 없겠지만, 굳이 줄여보자면.
🤝 완벽하지 않아도, 조금 부족한 상황이어도 일단, 개발을 시작할 수 있도록 선한 자극과 동기부여를 제공해준 프로젝트인 것 같아요.
마치며
사실 정해진 개발 일정을 모두 마쳤거나, 서비스를 런칭한 프로젝트도 아니기에 후기를 작성할 정도로 대단한 일이 아닐지도 모르겠어요. 만약 개인 프로젝트로 개발했다면, 의사결정하는데 많은 비용을 줄일 수 있고 생각했던 방향성대로 개발할 수 있었을 것 같기도 해요. 하지만 위에서도 언급했듯이 조금 느리더라도 팀원들과 협업하는데 몰입하는 경험이 중요하다고 판단되어 일시적으로 타이트하게 개발하고 끝내는 프로젝트가 아닌 지속 개발 가능한 팀 프로젝트를 꾸리고 싶었어요.
올해 남은 3, 4분기에도 조금씩 점진적으로 개발해가며 실무에서 차올랐던 니즈를 채우거나 팀원들과 사용해보고팠던 기술들을 도입해보는 등 장난감으로서의 역할을 다해주는 프로젝트로 유지해나갈 예정입니다!
참고 자료
🙏 이번 글에서 소개한 팀 프로젝트는 사라마라 프로젝트입니다. 혹시나 개선점이 있으시다면 댓글로 표현해주시면 좋습니다. 이슈나 PR은 언제든 너무나 환영입니다.
