모임 서비스를 개발하며 (모두 모여라 개발기)

 

2022 . 06 . 22 ~ 2022 . 10 . 22

우아한테크코스 레벨 3 ~ 4에 거쳐 진행된 팀 프로젝트가 21일 데모데이를 끝으로 마무리 되었습니다. 제가 참여한 팀에서는 "모두 모여라"라는 모임 생성 & 참여 서비스를 개발하게 되었는데, 지난 네 달간의 개발 과정을 정리해보는 시간을 가지려고 합니다.

 

팀 규칙 정하기

팀 문화 관련 규칙

모두 모여라(이하 모모) 팀은 백엔드 크루 4명과 프론트엔드 크루 2명, 총 6명으로 구성된 팀입니다. 여러 명이 함께 개발을 해야하다보니 앞으로의 원활한 진행을 위해 일관성 있는 규칙이 필요했습니다.

간단한 시간 약속부터 회의나 코드 리뷰 방식까지 공통적인 팀 규칙을 정하고, 각 분야별로 구체적으로 필요한 규칙이 있으면 정하였습니다. 정했던 규칙들 중 4번 나만 알지 않기, 나만 모르지 않기 덕분에 많이 공부하게 되었고, 특히 미니 테코톡이라는 이름으로 서브 모듈이나 OAuth와 같은 특정 주제에 대해 기술 공유 시간을 갖고 지식을 나누는 시간을 가진게 큰 도움이 되었습니다.

 

현재 인프라 구조에 대해 설명하는 백엔드 크루 이프

특히 함께 코딩을 한다면 컨벤션 또한 중요한 요소입니다. 네이밍 규칙부터 스타일 속성의 순서까지 일관적으로 관리 될 수 있도록 지정해주었습니다. 그 덕분인지 팀원이 짠 코드여도 마치 내가 짠 코드처럼 알아보기 편하다는 느낌을 받았습니다.

 

프론트 코드들은 이런 컨벤션 위에서 작성되었습니다.

지금 생각해도, 컨벤션을 가장 먼저 정한건 정말 잘한 결정이었다고 생각합니다.

 

 

회의와 문서화

노션으로 정리했던 회의 내용과 API 명세

회의를 통해 모임에 대한 명세나 프로젝트의 정책 방향등을 정한 뒤 노션을 통해 정리해두었더니 나중에 찾아보기도 쉬웠습니다. 이 글을 쓰는 지금도 이 때 논의했던 자료들을 쉽게 찾아서 첨부하고 있네요.

 

Rest docs를 이용해 정리한 API 문서

노션으로 API에 대한 논의를 끝냈다면 실제로 API를 개발하며 구체적인 스펙을 문서화를 통해 정리해주었습니다. 기존에 이런 문서가 없을 때에는 노션만 참고하여 개발을 진행했었는데, 이런 경우 제때 문서를 최신화 하지 않으면 예상한 응답값이 넘어오지 않아 오류가 발생하는 일이 종종 있었습니다. 이렇게 실제 코드와 연동된 살아있는 API 문서를 통해 작업하니 위와 같은 문제 상황을 막을 수 있어 프론트를 개발하는 입장에서 굉장히 만족스러웠습니다.

여담으로 저는 백엔드에서 사용하는 API 문서라고 하면 Swagger 밖에 몰랐었습니다. 그런데 이번에 Rest docs를 사용하기로 한 결정에 대해 어떤 이유에선지 궁금했었는데 팀원들이 Swagger의 단점과 Rest docs의 장점 등을 이해할 수 있도록 쉽게 설명해주어 궁금증을 해결할 수 있었습니다. 분야를 가리지 않고 적극적으로 지식을 공유하는 모습이 참 좋은 팀이라는 생각이 들었네요.

 

 

본격적인 개발과 코드 리뷰

나중에야 알게 된 사실이지만, 모임이라는 도메인은 생각보다 쉽지 않은 주제였습니다. 제목, 작성자, 카테고리, 설명 같은 기본적인 게시글에 들어가야 할 정보는 물론이고 장소, 일정, 모집 인원, 기간, 마감일 등등 다양한 정보들이 서로 영향을 미치며 복잡하게 얽혀 있었습니다. 백이며 프론트며 가리지 않고 갖은 버그들이 터져나왔고 이는 최종 데모데이 당일까지도 끊이지 않았습니다.

그럼에도 어떻게든 돌아가는 서비스를 만들었다는데에는 팀의 코드 리뷰 문화가 크게 작용했다고 생각합니다.

 

코드 리뷰가 가득 담긴 PR들

 

간단한 실수부터 구조에 대한 논의까지 코드 리뷰를 한 번 거치고 나니 이전보다 훨씬 견고하고 퀄리티 있는 코드로 변모했습니다. 이런 개선들은 곧 이후에 발생할 수도 있는 버그들을 큰 폭으로 줄여주는 역할을 했습니다. 프로젝트 전체에 대한 이해를 높일 수 있는 기회가 되기도 하고, 기술적으로 잘 모르는 내용에 대해 알게되는 장점도 있어 코드를 리뷰하고 다시 리뷰받는 일련의 과정들은 빠질 수 없는 문화가 되었습니다. 혹시나 코드리뷰 없이 개발 서버에 머지되는 불상사를 미연에 방지하고자 각 분야의 다른 크루들(백엔드는 자신 이외의 3명, 프론트엔드는 1명)이 approve 해주지 않으면 아예 머지가 불가능하도록 설정해두었습니다.

 

스프린트와 데모데이

두 레벨을 거쳐 총 다섯 번의 스프린트와 데모데이를 진행했습니다. 각 데모데이마다 스프린트 기간동안 프로젝트를 어떻게 해왔었는지 진행상황을 공유하는 자리였는데, 다른 팀들이 모두 함께하니 최소한 부끄럽지는 않을 정도로 기능들을 구현하고 싶은 욕심이 생겨 팀원들 모두 열정적으로 스프린트에 참여했습니다.

 

3차 데모데이 녹화 영상

기획부터 설계, 제작까지 각 스프린트에서 할 단위를 나누고 개발하는 과정을 직접 겪어보니 실제로 생기는 문제들을 경험할 수 있었습니다. 그 스프린트 기간동안 지혜롭게 극복했던 문제들도 있었고, 그렇지 못해서 구현하지 못하거나 기획을 뒤엎는등 여러가지 실패들도 경험했습니다. 이때의 실패를 거울삼아 다음 스프린트때는 최선의 방법으로 접근해서 해결했습니다.

대표적으로는 모바일 화면 대응 이슈가 있었습니다. 초기의 기획으로는 우선 PC에서 사용할 수 있는 화면을 만들고, 이후에 모바일 화면을 대응하는 방향으로 가자고 결정했는데 지금에서 돌아보면 큰 실수였습니다. 한 번 모바일을 고려하지 않은 데스크톱 기준의 UI는 뜯어 고치지 않는 이상 수정하기 어렵다는걸 모르고 내린 결정이었습니다.

총 다섯 번의 스프린트 중 기본적인 기능이 모두 구현된 네 번째 스프린트가 되어서야 모바일 화면으로의 전환이 어렵다는걸 깨닫고, 해당 스프린트내에 완료하겠다는 원래 계획은 실패했습니다. 이런 실패를 바탕으로, 마지막 스프린트에서 내린 결정은 바닥부터 UI를 뜯어고치되, 초기에 데스크톱 화면부터 대응하기로 한 원인이자 문제가 되었던 부분인 단순한 크기 조절을 통해 모바일와 데스크톱의 두 화면을 대응하기 어려운 경우들은 반-적응형(half-adaptive) 디자인을 통해 기획 단계의 공수를 줄이는 방법을 채택하게 되었습니다.

 

반-적응형은 제가 임의로 만든 단어인데, 일반적으로 화면상의 크기에 따라 UI 디자인을 동적으로 변경시키는 반응형 디자인과 모바일과 데스크톱의 정적인 두 가지 화면을 각각 따로 만들어서 보여주는 적응형 디자인의 특징을 합친 방법을 의미합니다.

 

모모에 적용된 반-적응형 디자인은 기본적으로 화면상에 크기에 맞는 디자인으로 동적으로 변경되지만, 특정 breakpoint를 기점으로 화면 요소 배치가 바뀌게 됩니다. 이렇게 번거로운 방식을 사용하게 된 큰 이유는 사용자 경험 때문인데, 사용하는 기기가 바뀌면 화면에 표시되는 요소의 위치나 크기만 조정해주는것으로는 사용하기 편리하다고 느끼기엔 충분하지 않기 때문에 이러한 결정을 내리게 되었습니다.

이러한 반-적응형 디자인은 모임 상세 페이지에 적용되어 있습니다.

 

모모의 상세 페이지 (왼쪽부터 데스크톱 화면과 모바일 화면)

이러한 경험 외에도 스프린트 중간중간 여러가지 미션들이 주어져서 재밌고, 서로의 영역을 잘 이해할 수 있는 시간도 있었습니다. 가령 백엔드가 화면을 구현하고, 프론트엔드가 백엔드의 테스트 코드를 짜는 식입니다. 키보드를 잡은 한 명이 드라이버가 되고, 나머지 모든 팀원이 네비게이터가 되어 함께 코딩을 하니 페어 프로그래밍과는 또 다른 매력이 있어서 즐거웠습니다.

 

단체 프로그래밍에 빠진 팀원들

 

 

아쉬운 점을 하나 꼽자면

프로젝트에서 아쉬운 점이 있다면 시간상의 이유로 테스트 코드를 꽤 많이 생략했었는데 몇 번 버그를 겪고 난 뒤로 테스트의 필요를 뼈저리게 느끼고 난 후로는 기능에 대한 단위 테스트는 꼭 적어주게 됐습니다. 만약 다른 프로젝트를 또 진행하게 된다면 촘촘한 테스트 코드를 통해 견고한 프로젝트를 만들 생각입니다.

실제로 프로젝트 규모가 일정 수준을 넘어가게 된 뒤로는 코드를 직접 짠 본인조차 코드가 어떻게 동작하는지 확실하지 않을 때가 많아졌습니다. 이런 경우 문제가 생기면 바로 해결하기가 어려워지는데, 테스트 코드를 적는 시간이 오류를 수정하는 시간보다는 훨씬 작기 때문에 장기적으로 보면 훨씬 좋은 점이 많다고 느꼈습니다. 이런 상황이라면 TDD가 굉장히 효율적일 수 있겠다는 생각이 들었고 이제야 테스트의 중요성이 조금은 와닿는 시간이었습니다.

지금은 단위 테스트만 작성이 되었지만, 이에 더하여 cypress등을 이용한 E2E 테스트를 추가하거나 storybook을 통해 UI Docs를 만들어줘도 좋겠다는 생각이 들었습니다. 그동안 스프린트 일정에 쫒겨 해보지 못했던 것들도 이제 여유가 생겼으니 하나씩 해 볼 생각에 설레는 요즘입니다.

마무리

짧지 않은 시간동안 찐하게 협업했고, 팀 프로젝트의 처음 의도였다는 그 경험을 제대로 느낀 것 같습니다. 개인 미션에서는 얻지 못했던 소프트 스킬들도 계속해서 대화하고 설득하고, 논의하는 과정을 거치며 확실히 성장했다는 생각이 들었습니다. 좋은 팀원들과 좋은 프로젝트를 진행할 수 있어서 정말 행복했고 가능하다면 모모를 앞으로도 토이 프로젝트 삼아 조금씩 업데이트 해나갈 수 있으면 좋겠습니다.


😊 모모 서비스 바로가기
😊 모모 레포지토리 바로가기

😊 모모 기술 블로그 바로가기
😊 모모 소개 페이지 바로가기
😊 데모데이 영상 바로가기 : 1차 / 2차 / 3차 / 4차

🔥 우아한테크코스 레벨 3 후기
🔥 우아한테크코스 레벨 4 절반 회고