훕치치 4차 릴리즈를 마치고.

훕치치(HUFSCHEER) 프로젝트를 좋은 팀원들과 10개월이 넘는 시간 동안 3차, 4차 릴리즈를 함께했습니다. 이 과정에서 느낀 점도 많고 배운 점도 많은데요, 해가 지나기 전에 이를 정리해 보고자 합니다.

훕치치 프로젝트의 자세한 내용은 프로젝트 탭의 훕치치 페이지에 정리되어 있습니다.

제가 합류한 1월은 2차 릴리즈에서 진행된 경기가 모두 종료되고, 기능을 확장하기 위한 3차 릴리즈를 준비하는 시기였습니다. 저와 함께 새로운 기획 팀원과 디자인 팀원이 합류했고 기존의 사이트를 매니저(관리자)와 관객(사용자)으로 분리하고자 했죠.

프론트엔드 팀원들은 합류 이전부터 모노레포(Monorepo) 방식을 도입하려는 계획이 있었습니다만, 저는 ① 코드 제대로 모름 ② 모노레포 사용 경험 없음 ③ TanStack Query 사용 경험 없음 삼연타를 맞고 거의 한 달을 버로우 했습니다.

중간중간 올라오는 팀원의 PR에 yarn workspace, turborepo와 같은 패키지 매니저 관련 용어가 써있는데 뭐라고 하는지 모르겠고.. 코드 리뷰는 해야겠고.. 잠은 오고 눈은 떠 있고.. 그러다가 디자인이 완성되고 코드를 작성하기 시작하니까 재미가 붙긴 했습니다.

코드 리뷰

이번 프로젝트는 처음으로 프론트엔드 개발을 여러 명이 함께 진행하며 협업한 경험이었고, 코드 리뷰도 처음 접해보았습니다. PR에서 30개가 넘는 코멘트가 오가는 상황을 경험하면서, 작성된 코드를 다양한 시선에서 바라보고 개선할 여지가 많다는 것을 느낄 수 있었습니다. 그 과정 자체가 정말 즐거웠습니다.

신기했던 것은 리뷰어 모두가 자신만의 관점으로 리뷰를 한다는 것인데요,

• 성민 형은 본인이 생각하는 개선 방안을 코드로 제시하고 그 이유에 대한 래퍼런스로 뒷받침하는 부분, 개인 취향의 영역은 분명하게 알려주는 부분이 인상 깊었고,
• 민규 형은 와이어프레임과 대조하여 디자인 일관성을 점검하고, 본인이 알던 사실과 코드의 갭을 대화를 통해 채우고자 하는 방식이 돋보였습니다.

이학의 코드 리뷰는 어떤 스타일인가? 라는 질문을 던져보았을 때, 가독성과 디자인에 집중한다고 느낍니다. 여러 사람이 공유하는 코드베이스에서는 코드의 가독성과 패키지 구조가 가장 중요하다고 생각하고, 작성한 코드를 어떻게 더 줄일 수 있을지. 관심사를 분리할 수 있는지에 대해 고민했습니다. 또한, 사이트의 디자인은 사용자와 회사가 대화하는 공간이라고 생각하기 때문에, 요소가 디자인과 일치하는지를 확인했습니다.

제가 남들에게 유의미한 도움을 주는 리뷰어였는지는 잘 모르겠습니다. 하지만 좋은 리뷰어가 되는 것이 저의 지향점이고, 건설적이고 도움이 되는 리뷰어가 되기 위해 어떤 방식으로 일해야 할지 계속해서 고민하고 있습니다.

일정 관리

개인적으로 3차 릴리즈의 가장 큰 사고는 일정 관리가 제대로 되지 않은 부분이라고 생각합니다. 3월 18일 완성을 목표로 진행했으나 대회가 진행 중일 때도 완성하지 못했으니까요. 세 달이라는 기간은 정말 긴데 왜 마지막에 몰아서 진행하게 되었을지 반성해 보았습니다.

1) 고정된 회의 일정

회의를 고정적으로 하는 것은 장점이 분명합니다. 팀원 모두가 같은 진행 상황을 공유할 수 있고 많은 의견이 모입니다.

저희 팀은 매주 금요일에 회의를 진행했는데요, 회의에서 모든 안건을 결정하다 보니 건의할 사항이 생기면 금요일까지 기다려야 했습니다. 어떤 경우에는 일주일 뒤에 결과를 얻을 수 있게 되니 작업 속도가 늦어지는 요인이 되었죠.

이 문제는 3차 릴리즈가 끝난 후 회고에서 언급되었고, 간단하거나 빠르게 처리되어야 하는 안건은 슬랙 대화를 통해 결정하는 것으로 개선했습니다. 이후 진행되는 회의 시간이 점점 짧아지더니 현재는 꼭 필요한 경우가 아니면 회의하지 않습니다. 훕치치 이외에도 팀 프로젝트에서 진행되는 고정적인 회의가 꼭 필요하지 않겠다는 생각이 들기도 하네요.

2) 릴레이식 협업

3차 릴리즈에서는 릴레이식으로 협업하는 경우가 많았습니다. 한 명이 작업을 끝내면 그것을 받아서 다음 작업을 진행하고, 다음 사람은 그다음 작업을 진행하는 방식이었습니다. 물론 1월에는 디자인이 확정되지 않아 새로운 작업보다는 빌드나 프로젝트 환경 설정을 했기 때문에 어쩔 수 없는 결과이기도 합니다.

그렇지만 협업에서 기대하는 병렬 작업이 아니었기 때문에 결국 혼자 개발하는 것과 크게 다르지 않았다고 생각합니다. 이를 어떻게 개선했어야 할까요?

당시에는 이게 잘못이라는 생각을 하지 않았습니다. 프론트엔드 개발로 합류했기에, 당연히 프론트엔드 이외 기획의 업무나 디자인에 관여하지 않는 것이 맞는다고 생각했죠. 매거진 B 조수용 발행인의 『일의 감각』을 읽고 생각이 조금 달라졌는데요, 조수용님은 공감과 주인의식을 강조하며 이는 효과적인 협업과 프로젝트 성공에 필수적이라고 말합니다.

초기 단계에서부터 주인 의식을 가지고 기획과 디자인 단계에서 적극적으로 의견을 제시하고, 프로젝트의 방향성을 잡았더라면. 각 페이지에 들어갈 요소들을 미리 확실하게 정리하고, 기능적인 부분을 우선으로 개발했다면 팀원들이 병렬적으로 조금은 더 빠르게 작업할 수 있었을 것이라는 생각이 듭니다.

3) 코드 품질에 대한 욕심

위의 코드 리뷰 부분에서 작성했던 것과 같이 팀원들의 코드를 리뷰하고 리뷰 받는 과정이 정말 즐거웠습니다. 여러 줄로 작성된 코드를 고차함수 한 줄로 줄였던 것이 생각나는데요, 이처럼 변경된 코드를 자세하게 리뷰하여 성능, 가독성, 스타일 일치 등에서 어떻게 하면 더 개선할 수 있을지 집중했습니다. 그 과정에서 병합까지의 시간이 길어진 것 같습니다.

저희 팀은 일주일 동안 개발할 마일스톤 설정 → 개발 및 Pull Request → 코드 리뷰 및 병합 단계로 개발을 진행했는데, 코드 리뷰가 길어지다 보니 설정한 마일스톤을 다음 주로 넘기는 경우가 많았습니다.

위의 차트는 프론트엔드 리포지터리의 커밋 차트인데요, 3월에 커밋이 몰려있는 것을 볼 수 있습니다(스쿼시 머지로 한 개의 PR이 한 개의 커밋). 결국 마지막에는 마감을 어떻게든 맞추기 위해 코드 리뷰를 거의 생략하듯 진행하였고, 코드 품질은 떨어졌습니다. 저희가 집중했던 코드 리뷰와 품질의 가치도 지키지 못한 것이죠.

코드 품질과 새로운 기술을 공격적으로 도입하는 것 모두 정말 중요하지만, 더 중요한 것은 결국 마감이라는 것을 느꼈습니다. 3차 릴리즈 후 2024 외대 월드컵 대회에서만 6천명 이상의 사용자가 접속(Cloudflare Unique Visitors 기준)했는데, 개발이 더 늦어졌다면 어떤 결과가 나왔을지 상상하기 어렵네요.

아직 이에 대한 결론은 내지 못했습니다. 코드 품질과 마감의 균형을 어떻게 맞출 수 있을지, 작업의 우선순위를 어떻게 설정해야 하는가에 대한 고민과 실험은 더 해보아야 할 것 같습니다.

마치며

훕치치는 매니저 페이지와 일부 사용자 페이지의 디자인을 개선한 4차 릴리즈까지 성공적으로 출시했으며, 누적 1만 명 이상이 방문한 사이트로 성장했습니다. 현재는 사용자가 지속해서 참여할 수 있는 서비스로 나아가기 위해 여러 기능의 도입을 준비 중입니다.

남은 숙제도 있는데요, 과반의 팀원이 취업하면서 최근에는 학부생 위주로 코어 멤버가 구성되었습니다. 멘토 역할을 하는 직장인들과 코어 멤버 간의 역할을 어떻게 하면 균형을 유지하면서 모두가 성장할 수 있을지, 그리고 팀이 지속해서 높은 텐션을 유지할 수 있는 방법에 대해 고민하고 있습니다.

글을 쓰다 보니 결국 팀원들과 많이 소통하는 것이 유일한 해결책이라는 생각이 드네요. 회고 글이 팀과 저에게서 느낀 문제점 위주로 작성된 것 같다는 생각도 들어요. 저 스스로 회고를 retrospect가 아닌 reflection으로 정의했기 때문에 이 방향성이 더 맞는 것 같기도 합니다. 이 프로젝트에 참여하지 않았다면 지금 같은 성장은 없었을 것이라고 생각합니다. 앞으로도 더 좋은 서비스를 만들기 위해 즐겨보려 합니다.