[회고] ‘오운완’ 팀프로젝트 진행과정

📌 시작하며

프로그래머스 데브코스에서 진행한 2차 팀 프로젝트 회고를 진행해 보려 한다

처음 경험하는 규모의 프로젝트는 처음이기도 했고 2024년 마지막 프로젝트였기 때문에 더 욕심이 났다.

그리하여 우리 팀이 만든 서비스는 두둥
🔗깃허브 주소

서비스 소개

!O운완?O운완 서비스는 현대인의 건강한 라이프스타일을 위한 사진 기반 운동 인증 커뮤니티로, 사용자들에게 동기부여와 정보를 제공하는 것을 목표로 삼았다.

주요기능

• 4가지 주요 채널 제공 : 오운완 인증, 프로틴 추천, 식단 공유, 헬스장 리뷰
  • 게시글 작성으로 건강 및 운동 정보를 공유
  • 좋아요, 댓글, 팔로우 기능으로 활발한 커뮤니티 형성
• 운동 동기 부여 기능:
  • BMI 계산기
  • 운동 인증 캘린더 및 운동 달성도 그래프

프로젝트 명세서

주제: 제공되는 api를 이용한 회원 인증 기반 커뮤니티
기간: 2024.12.05 ~ 2024.12.23

기본 요구사항

• 사용자는 회원가입과 로그인을 할 수 있습니다.
• 사용자는 채널에 올라온 글을 볼 수 있습니다.
• 사용자는 가입자 목록을 볼 수 있습니다.
• 사용자는 가입자를 이름으로 검색을 할 수 있습니다.
• 사용자는 가입자의 정보를 볼 수 있습니다.
• 사용자는 포스트 혹은 가입자를 검색할 수 있습니다.
• 인증된 사용자는 자신의 정보를 변경할 수 있습니다.
• 인증된 사용자는 채널에 올라온 글을 볼 수 있습니다.
• 인증된 사용자는 채널에 포스트를 남길 수 있습니다.
• 인증된 사용자는 포스트를 좋아요 할 수 있습니다.
• 인증된 사용자는 포스트에 댓글을 남길 수 있습니다.
• 인증된 사용자는 자신의 알림 목록을 확인 할 수 있습니다.
• SPA 형태로 만들어주세요.
• 엉뚱한 페이지에 접속하면 404 페이지를 보여주세요.

보너스 요구사항

• 사용자는 현재 접속 중인 사용자를 볼 수 있습니다.
• 인증된 사용자는 다른 가입자에게 메시지를 보낼 수 있습니다.
• 인증된 사용자는 자신에게 온 메시지 목록을 확인 할 수 있습니다.
• 인증된 사용자는 특정 사용자와의 메시지 대화 내역을 확인 할 수 있습니다.
• 인증된 사용자는 프로필 이미지 변경
• 인증된 사용자는 포스트를 작성할 때 이미지를 첨부할 수 있습니다. 파일 업로드를 구현해보세요.
• 다크 모드를 적용해보세요.

📅 프로젝트 진행 과정

기획

주제 선정

주제는 요구사항에 맞춰서 팀원들이 각자 의견을 던지고 투표를 진행하였다

투표 결과 top3 주제들로 요구사항에 충족시킬 수 있는지 확인 후 특이사항을 점검하고 투표로 진행되었다

그 결과 최종적으로 내가 제안한 오운완이 선정됐다 🎉

🗣️ 오운완 제안 이유

• 운동인이라는 구체적인 타겟층을 설정하여 그들의 니즈(운동 성과 공유, 경험과 노하우 공유)에 효과적으로 대응할 수 있다
• 인스타그램이나 핀터레스트같은 사진 기반 커뮤니티 서비스를 구현하고자 했다 ⇒ 운동인증이라는 주제는 시각적 콘텐츠와 어울린다
  
• 제공된 API를 활용해 주요 기능을 구현하는 데 있어 현실적인 접근이 가능하다

유저플로우

디자인에 들어가기 전 유저플로우를 작성했다

유저플로우를 작성함으로써 다음과 같은 이점을 얻을 수 있었다

• 서비스의 전체적인 흐름을 시각화하여 팀원들과 효과적으로 소통할 수 있었다
• 사용자 관점에서 서비스를 바라보며 불필요한 단계나 개선이 필요한 부분을 미리 파악할 수 있었다
• 기능 개발의 우선순위를 정하고 작업 범위를 명확히 할 수 있었다
• 인증/비인증 사용자의 접근 권한을 명확히 구분하여 보안 설계에 도움이 되었다
  

디자인

디자인은 피그마를 통해 진행되었다. 반응형 웹을 전제로 디자인을 진행했으며, 피그마에서 공통 컴포넌트들은 별도 분리해 관리하며 디자인 시스템을 효율적으로 구축하고자 했다. 이를 통해 디자인의 일관성을 유지하고 수정 사항 발생 시 빠른 대응이 가능했다.

• 메인 컬러로 포카리스웨트를 연상시키는 #3B6CB4를 선택했다.
  ⇒ 운동과 관련된 서비스의 정체성을 잘 표현할 수 있는 색상이라 생각했다.
  
• 폰트는 다국어 지원이 우수한 프리텐다드를 사용했다.
• 이미지가 주요 콘텐츠인 만큼, 불필요한 디자인 요소를 최소화하고 시각적 콘텐츠를 돋보이게 하는 미니멀한 디자인을 추구했다.
• 사용자의 집중도를 높이기 위해 게시물에는 최소한의 정보(프로필 이미지, 닉네임)만 표시하고, 호버 시 제목과 내용 일부를 보여주는 인터랙션으로 클릭을 유도했다.
• 디자인의 일관성을 위해 버튼과 같은 상호작용 요소에는 메인 컬러를 적용하여 시각적 통일감을 주었다.

기능명세서

프로젝트 초기에는 기능명세서를 어떻게 정리해야 할지 막막했지만, 여러 블로그 글을 참고하며 페이지별로 나누어 작성하는 방식을 선택했다. 그 결과 다음과 같은 이점이 있었다.

1. 기능 가시성 향상

• 각 페이지마다 필요한 기능을 한눈에 확인할 수 있어 중복 기능을 쉽게 식별할 수 있었다
• 구현해야 할 기능들이 명확히 정리되어 개발 방향이 분명해졌다

2. 효율적인 역할 분담

• 기능별로 나눠서 팀원들과의 역할 분담이 수월해졌다
• 각자 담당 기능이 명확히 정해지면서 책임감이 상승했다

3. 실시간 진행 상황 공유

• 진행 상황을 실시간으로 업데이트하여, 완료되지 않은 기능들을 파악하고 우선순위에 따라 작업을 조율할 수 있었다.
• 작업이 완료된 팀원들이 다른 팀원들을 도와주며 협업할 수 있었다.
  
  🤔 다만 컴포넌트별로 분리가 되어 있지 않아서, 디자인 단계에서 중복된 컴포넌트가 많았는데도 개발 시에는 개별 컴포넌트로 나누어 작업하게 되었다. 초반에 중복되는 요소들은 한 명이 전담해서 진행했다면 더 효율적이지 않았을까 싶다!

💻 개발문화

1. 깃허브 이슈와 PR 활용

깃허브에서는 이슈와 PR 템플릿을 활용하여 일관된 형식을 유지할 수 있었다.

라벨을 통하여 작업 내용을 한눈에 파악할 수 있었고, 각 PR에서는 구현한 로직에 대한 간단한 설명을 포함하여, 다른 팀원들이 코드를 리뷰하고 이해하는데 도움이 되도록 했다.

2. 브랜치 관리

브랜치와 이슈를 연동하여 PR 머지 시 해당 이슈가 자동으로 closed 되도록 설정했다. 이를 통해 작업 진행 상황을 효율적으로 추적할 수 있었다.

브랜치 네이밍 규칙은 'devtask#issuenumber' 형식을 따랐다. (예: featheader#2)

각 팀원이 한 번에 1개의 태스크만 담당하도록 하여 코드 병합 과정에서 발생할 수 있는 문제를 사전에 방지할 수 있었다.

🔥 그럼에도 발생한 충돌… 원인은 개인 개발에 몰두하여 pull을 받지 않고 작업을 진행하는 경우가 있었기 때문.

이를 해결하기 위해 Zoom 채팅과 카카오톡 등 모든 연락망으로 PR과 머지 상황을 실시간 공유했고, 이를 통해 팀원들이 즉시 pull을 받아 충돌을 최소화하며 작업을 이어갈 수 있었다! 👍

👥 협업방식

• 슬랙을 통한 일일 스크럼: 매일 아침 팀원들과 컨디션을 공유하고 진행 상황을 점검했다
• 노션을 활용한 일정 관리: 프로젝트 전체 일정과 개인 일정을 공유하고 관리했다
• 깃허브 기반 협업: 이슈와 PR 활용했다
• 피그마를 통한 디자인 협업: 유저플로우와 디자인 작업을 실시간으로 공유하고 피드백을 주고받았다

💫 트러블슈팅 QA

개발시 지속적으로 테스트를 진행했다. 발견된 버그들은 즉시 수정하거나 노션에 기록하여 추후 해결할 수 있도록 했다. 이런 방식으로 모든 팀원이 버그 발견과 수정에 적극적으로 참여하여 서비스의 안정성을 높일 수 있었다.

테스트와 품질 관리를 위해 다음과 같은 방식으로 진행했다

• 실시간 버그 트래킹: 발견된 모든 오류사항을 즉시 기록하고 담당자를 지정했다
• 체계적인 이슈 관리: 각 버그에 대해 완료 여부를 체크리스트로 관리하여 진행 상황을 명확히 했다
• 우선순위 기반 해결: 사용자 경험에 직접적인 영향을 미치는 문제부터 우선적으로 해결했다
  

🔥 개발하는 시간보다 오류를 잡는 데 더 많은 시간을 할애했던 것 같다. 기능 구현이 끝났다고 생각했지만 QA를 진행할수록 계속해서 예상치 못한 오류들이 발견되었고, 이를 해결하기 위해 많은 시간과 노력을 들였다. 다음 프로젝트에서는 QA 시간을 충분히 확보해야겠다.

⌛️마치며

이번 프로젝트의 1차 스프린트에서는 보너스 요구사항을 제외한 모든 기능 구현을 목표로 삼고, 수업 시간뿐 아니라 주말과 저녁 시간까지 팀원들이 함께 슬랙 허들에 모여 개발에 매진했다. 팀원 모두 적극적인 참여로 기한 내에 보너스 요구사항까지 도전할 수 있었고, 결과적으로 전체 21개 중 메시지 기능을 제외한 18개의 요구사항을 성공적으로 구현했다!

팀내 에이스 분들(양대산맥)이 화면을 공유하며 어려운 부분을 설명해 주신 덕에 수업 시간에 완벽히 이해하지 못했던 axios나 zustand와 같은 기술들도 프로젝트에서 활용해 볼 수 있었다.

개발 과정에 집중하다보니 나머지 버그 수정과 QA에 충분히 시간을 할애하지 못한 점이 아쉽지만, 3주라는 짧은 시간동안 정말 열심히 했다는 점에서 만족한다! 중간에 어려운 부분도 있었지만 팀원들의 응원 덕분에 프로젝트를 끝까지 마무리할 수 있었다. 굿굿 👍