[오픈마인드] 팀프로젝트 회고

어느덧 코드잇 부트캠프도 11주 차를 보내고 있다. 9주 차부터는 기초 프로젝트를 진행하면서 약 2주간에 걸쳐 팀프로젝트를 완성했다. part2에서 만난 팀원분들과 함께 리액트를 공부하며 3주를 보내고, 이후 프로젝트를 진행하고 발표까지 하면서 정신없는 시간을 보냈던 것 같다. 

 

이 포스팅에서는 코드잇 처음 팀프로젝트인 만큼 전체적인 팀프로젝트 진행과정에 대한 회고를 작성해 보려 한다.

🔮 프로젝트 소개

기초프로젝트인 만큼 피그마와 API 명세서, 기본 요구사항이 주어진 상태에서 UI와 기능을 구현하는 프로젝트이다. 우리가 선택한 프로젝트는 [💌 오픈마인드]로 질문과 답변을 통해 마음을 열고 대화 나누는 소통 플랫폼이다. 질문 대상을 선택해서 원하는 질문을 남기고, 질문을 받은 사람은 답변을 하면서 소통해 나가는 목적을 가진 웹 어플리케이션이다.

🗺️ 진행 과정

프로젝트 셋팅과 역할 분담

part2에서 팀장 역할을 맡다 보니 이번 팀프로젝트를 진행하면서 이것저것 신경 써야 할 부분이 많았다. 우선 개발을 위해 깃헙 오가니제이션 레포를 처음 만들어보았는데 이 과정도 복잡한 만큼 시간이 오래 걸렸다. 프로젝트 초기셋팅을 진행하면서 기본적인 폴더구조와 프리티어, 린트 등의 설정을 해보았다. 이전에 이미 코드컨벤션을 논의하면서 얘기했던 부분이어서 금방 끝낼 수 있다고 생각했는데 실제 프로젝트를 셋팅하면서 논의했던 코드컨벤션 부분을 다르게 이해하고 있다는 점도 발견했다. 덕분에 본격적인 개발에 들어가기 전에 규칙들을 다시 확인할 수 있는 계기가 되었다.

 

프로젝트 기간이 길지 않고 규모가 크지 않은 만큼 담당 기능을 명확하게 분배하기가 어려웠다. 그래서 우리 팀은 우선 각 페이지를 나눠서 UI를 구현하고 다시 기능을 나누는 방법을 선택했다. 결과적으로 처음에 담당했던 페이지가 익숙해져 버려서 해당 페이지 기능까지 담당하는 것으로 이어졌다. 또, 담당 페이지가 겹치는 부분도 상당히 많았었는데 기능을 더 세분화하여 분리할 수 있는 컴포넌트 단위로 역할 분담을 나눴다. 

코드컨벤션

과거 팀프로젝트를 진행하면서 정했던 코드컨벤션 방식들을 노션으로 정리해서 팀미팅 시간에 공유하면서 상세 규칙들을 다시 점검하는 시간을 가졌다. General Rules, JavaScript Rules, React.js Rules (컴포넌트 내부 작성 순서), CSS Rules, File Rules, Git Rules로 분리하여 각각 상세하게 규칙을 만들었다. 

협업 방법

이번 프로젝트를 시작하면서 두가지 목표를 세웠다. 첫 번째는 팀프로젝트인 만큼 좋은 경험을 쌓으며 마무리하고 싶은 것과 두 번째는 그 과정 속에서 개인마다 목표하는 바를 두고 챌린지하듯 목표달성을 했는지를 체크해보는 것이었다.

 

첫 번째 목표에서 좋은 프로젝트 경험이란 협업 관점에서의 경험이고, 두 번째는 개인별로 다르겠지만 예를 들면, 평소 본인이 한 기능을 구현하는데 얼마큼 시간이 걸리는지 체크해 보는 시간이 될 수도 있고, 기능을 구현만 하는 것이 아닌 컴포넌트를 분리해 보는 과정이 될 수도 있다. 나의 경우에는 약 6개월 전 처음 팀프로젝트를 경험했던 것과 비교하면서 나에게 맞는 협업 방법을 고민해 보고, 그 당시 구현했던 양보다 더 많이 담당하면서 다시 한번 리소스를 체크해 보는 과정을 목표로 삼았다. 

 

- 팀미팅 시간을 활용한 데일리 스크럼

데일리 스크럼 시간에 각자가 한 작업과 오늘 할 작업을 공유하는 시간을 가졌고, 논의가 필요한 부분이 있다면 함께 의논하여 결정하였다. 또한 기능 구현시 최대 고민 시간을 4시간으로 정하고, 4시간 이후에도 해결되지 않는 문제가 있다면 디스코드로 공유하는 규칙을 정했다.

 

- 디스코드 웹 훅과 깃헙 이슈생성으로 태스크 관리

각자가 작업한 결과물을 PR을 올리면 디스코드 알림이 오도록 웹 훅 연결을 해놓아서 바로바로 확인하면서 각자가 개발한 부분을 확인해 보는 방식으로 협업을 진행했다. 또, 모든 작업은 깃헙 이슈생성으로 진행했으며 PR시 이슈를 연동하여 어떤 이슈에 대한 PR인지 확인가능하도록 정했다.  

 

- 코어 타임 설정

정규시간 내에 작업하는 게 제일 좋지만 일정이 안 맞는 부분도 있다 보니 팀미팅 시간인 1시부터 4시간은 코어타임으로 정해서 무조건 디스코드 음성채널에 모여서 작업하는 규칙을 설정했다. 온라인으로 팀프로젝트를 진행하다 보니 코어타임처럼 의견을 바로바로 공유할 수 있는 시간이 정말 필요했었고, 프로젝트 끝까지 잘 지켜졌다.

🏠 개발 과정

유저플로우 그리기

기본 요구사항과 API 명세서가 잘 정리된 상태이지만, 사용자가 실제로 서비스를 사용할 때 flow가 어떻게 되는지 먼저 생각하는 단계가 필요했다. 유저플로우를 그리는데 시간이 필요하지만 시각화를 통해 한눈에 전체적인 서비스를 파악할 수 있고, UX 관점에서 개발하는 기능에 대해 명확히 이해할 수 있기 때문에 결과적으로 개발 속도를 빠르게 진행할 수 있게 해준다.

 

또, 팀프로젝트인만큼 같은 요구사항도 각자가 이해하는 부분이 달랐기 때문에 협업을 위해서도 유저플로우를 그리는 과정이 필요하다고 생각한다. 다만, 너무 상세하게 모든 사항을 고려하기 보다는 초기에 서비스 파악 목적으로 그리는 것이므로 개발에 도움을 주는 수단으로 생각해야 한다는 점을 잊지 말아야 한다.

 

🎨그리다보면 재밌기도하다

중간 회고

PR을 통해 각자가 개발한 부분을 확인하고 있지만 본인이 개발한 부분이 아니면 바로바로 이해하기 어려운 부분이 있다는 생각이 들어서 중간회고를 도입하였다. 중간 회고는 멘토님께서 추천해 주신 방법으로 각자 그동안 무엇을 개발했고, 어떤 부분이 어려웠고, 어떻게 해결했는지를 데일리 스크럼때보다 자세하게 설명하는 시간으로 중간회고 의미처럼 총 개발 기간 중 1번 진행했다. 중간회고의 목적은 기능 공유 인지 목적과 전반적인 프로세스를 이해하는데 있다. 이를 통해 서로가 작업하지 않은 폴더, 파일도 코드를 보며 이해할 수 있었다.

QA 테스트

본격적으로 개발을 하며 1주일정도의 시간을 보낸 뒤 1차 QA 테스트를 진행해 보았다. 1차 QA 테스트의 목적은 앞으로 남은 개발을 하는데 미리 체크할 수 있는 부분은 해결하고 가자는 중간 점검 느낌으로 진행했다. 막상 해보니 완벽하다고 생각한 기능도 콘솔에 경고가 출력되는 점을 발견할 수 있었고, 조금씩 수정이 필요한 점을 미리 보완해 갈 수 있었다.

💫 개발 기능

오픈마인드의 주요 개발 기능은 사용자가 아이디를 생성할 수 있고, 소통 플랫폼인 만큼 다른 사용자에게 질문을 할 수 있고, 나에게 보낸 질문에 답변할 수 있다. 포스팅에서는 기본적인 요구사항 외에 우리 팀이 고려한 부분은 사용자 입장에서 조금 불편한 부분을 개선해 보면 어떨까 하는 생각을 바탕으로 기본 기능을 보완한 추가 기능을 개발한 부분에 대해 소개해 보려고 한다.

 

- 사용자에 따른 답변페이지 이동

아직 로그인 기능을 배우지 않은 상태여서 API를 사용하여 토큰으로 로그인을 적용할 수 없었다. 그래서 대안으로 사용자는 여러 아이디를 만들 수 있고, 생성한 아이디를 로컬스토리지에 저장했다. 그리고 그 정보를 이용하여 사용자가 생성한 아이디의 답변페이지로 이동할 수 있도록 적용했다. 즉, 사용자는 본인이 생성한 아이디 중 질문을 받은 아이디를 선택하여 답변하러 이동할 수 있도록 개선시켜 보았다.

 

- 질문 페이지에서 사용자가 한 번에 볼 수 있는 질문피드 개수 선택 옵션

이 기능은 사용자가 한 번에 볼 수 있는 피드를 인지하고, 개수를 선택할 수 있었으면 좋겠다는 생각으로 적용해 본 부분이다. 질문 페이지에서는 무한스크롤 방법으로 피드를 볼 수 있는데, 질문 피드 개수에 따라 무한스크롤 시 불러오는 피드도 다르게 적용해 보았다. 해당 기능을 만들면서 조금씩 시행착오를 반복했었는데 다음 포스팅에서 무한스크롤 구현 과정에 대해 다뤄볼 예정이다.

 

- 여러 방식으로 답변을 달 수 있도록 유튜브 임베드 기능

이 기능은 답변을 달 수 있는 방법이 글로만 전달할 수 있어서 영상으로 답변을 달 수 있다면 더 좋지 않을까라는 생각으로 적용해 보았다. 예를 들면, 어떤 음악을 좋아하시나요?라는 질문에 대해 사용자가 글 또는 즐겨 듣는 음악을 유튜브 링크를 첨부하여 영상으로 답변할 수 있도록 개선해 보았다.

🤔 프로젝트를 마치며

프로젝트를 완료하고 진행한 발표 세션에서 우리 팀은 팀원 전체가 각자 담당한 기능에 대한 설명과 시연, 마주한 문제와 해결법을 순서대로 발표하였다. 팀원 전체가 발표하는 방법도 신선하고 좋은 경험이었다. 이후 팀미팅 시간에 이번 프로젝트에 대한 KPT 방법으로 회고하는 시간을 가졌다.

 

프로젝트를 돌아보면서 각자의 K(keep), P(problem), T(try)에 대해서 의견을 공유하면서 만족스럽고 잘한 부분도 많지만 그만큼 아쉬움이 남는 부분도 많다는 것을 깨달았다. 특히 다른 팀의 발표와 시연영상을 보면서 우리가 생각하지 못한 부분을 고려하여 기능을 구현한 팀도 있었고, UX 관점에서 섬세하게 적용한 팀도 있어서 그런 생각이 들었던 것 같다. 

 

스스로의 KPT를 돌아보면 K는 요구사항에 대한 구현과 최소한의 라이브러리를 사용했다는 점, 또 무한스크롤 부분을 커스텀 훅으로 만들어서 로직을 분리했다는 점, 재사용성 가능한 공통 컴포넌트를 만들었다는 점이 잘한 부분이며 동시에 지속적으로 유지해 나갈 부분이라고 생각한다. 반면에 P는 프로젝트 초기에 기본적인 요구사항에 대해 충분히 이해하는 시간이 필요하다는 점을 깨달았고, 팀워크나 협업 측면에서 명확한 의사소통과 체계적인 스케줄 관리가 다소 미흡하지 않았나 하는 아쉬움이 있다.

이를 바탕으로 T는 향후 진행할 프로젝트에서는 UX 관점에서 와우포인트가 될 만한 점을 고려하며 좋은 아이디어가 있다면 시도해 보기, 협업툴을 적극 이용하여 업무 분배와 스케줄 관리를 쳬계적으로 세우고 팀원들과 공유하기로 정해보았다. 깃헙의 마일드스톤으로 리소스 관리를 하거나 팀 내 노션페이지로 그날그날 목표를 세우고 체크하며 다 같이 공유하는 방법 등을 다음 프로젝트 때 적용해 보면 좋을 것 같다.

 

6개월 전에 처음 팀프로젝트를 할 때는 1인 몫을 겨우 하는 팀원이었는데 지금은 프로젝트를 리딩할 만큼 스스로 또 많이 성장했다고 느껴 뿌듯한 마음이 든다. 또 동시에 그만큼 더 잘 해낼 수 있었는데 하는 아쉬움도 같이 든다. 이번 팀프로젝트를 마무리하며 프로젝트를 통해 경험한 모든 부분들이 나에게 자양분이 되어 다음 팀프로젝트를 할 때 시행착오를 더 줄일 수 있고, 스스로 더 만족하는 결과물로 이어질 수 있는 과정이 되어줄 거라 생각한다.