Trip Track - 데브코스 프론트엔드 1기 2차 팀 프로젝트 회고 (feat. ChatGPT)

Projects

Trip Track - 데브코스 프론트엔드 1기 2차 팀 프로젝트 회고 (feat. ChatGPT)

Developer Builter 2024. 10. 8. 20:54

이번 Trip Track 프로젝트는 많은 배움을 준 소중한 경험이었습니다.
여러 도전과 실수를 통해 개선해야 할 부분도 발견하게 되었고, 프로젝트를 계획대로 마치지 못하거나
일부 기능을 제대로 구현하지 못한 점도 있었습니다.
이번 포스트에서는 팀원간의 회고를 통해 얻은 교훈을 기록하고, 앞으로의 발전을 도모하고자 합니다.

팀 작업의 어려움

1. 팀원 간 어색한 침묵

프로젝트 초반에 팀원 간 소통이 원활하지 않아 의사소통 지연과 불필요한 침묵 시간이 발생하면서
팀의 생산성에 부정적인 영향을 미쳤습니다. 서로 의견을 나누고 적극적으로 대화하지 않아 프로젝트 전반에 걸쳐
소통의 비효율성이 존재했습니다. 만약 소통이 원활했다면 문제 해결 속도와 팀의 결속력이 훨씬 높아질 수 있었을 것입니다.

2. 짧은 스크럼 진행

노션에 작성된 스크럼 내용을 단순히 읽고 끝내는 형식적인 스크럼이 진행되었습니다. 이는 팀원 간의 유대감을
충분히 형성하지 못하게 했고, 프로젝트 진행 외에도 팀원 간 신뢰와 친밀감을 형성할 기회가 부족했습니다.
이러한 대화는 팀의 사기를 높이고 문제를 원활히 해결하는 데 큰 도움이 될 수 있었을 것입니다.

3. 불명확한 역할과 책임 분배 (R&R)

각자의 역할을 명확하게 정의하지 않아 책임에 대한 모호함이 발생했습니다. 처음 기획 단계에서부터 각자의 역할을 명확히 하고,
각자가 맡은 영역에 책임을 지는 문화를 조성했어야 했습니다. 불분명한 역할 분담은 프로젝트의 지연과 혼란을 초래하며
팀의 생산성을 저하시켰습니다.

4. 팀장과 팀원의 역할 관련 어려움

프로젝트 진행 과정에서 팀장과 팀원 모두가 일정 및 역할 분배, 회의 주재 및 기록에 대해 개선이 필요한 부분들이 있었습니다.
프로젝트 방향을 설정하고 각자의 역할을 원활히 수행할 수 있도록 지원하는 것은 팀 전체의 노력으로 이루어져야 했습니다.
이번 프로젝트에서는 이러한 부분에서 충분한 협력이 이루어지지 않아 일부 어려움이 있었습니다.

기술적 부족함

1. 첫 리액트 프로젝트와 생소한 백엔드 경험

팀원들이 리액트와 백엔드에 대한 경험이 부족해 프로젝트 진행 속도가 느려졌습니다. 프론트엔드와 백엔드 간의
상호작용에 대한 이해 부족으로 인해 많은 시행착오를 겪었으며, 이로 인해 기능 구현에 지연이 발생했습니다.
특히 리액트의 상태 관리나 백엔드 API 호출에 대한 이해 부족은 여러 번의 수정을 초래했습니다.

2. 테스트의 부재

테스트가 충분히 이루어지지 않아 코드 품질과 안정성을 확보하는 데 어려움이 있었습니다.
자동화된 테스트나 단위 테스트를 도입하지 않아 기능 추가나 수정 시 다른 기능에 문제가 발생하는 경우를
사전에 방지하지 못했습니다. 테스트는 코드 신뢰성을 높이는중요한 요소임에도 이를 간과한 점이 큰 아쉬움으로 남습니다.

3. 백엔드 설계의 소홀함

리액트 프로젝트에 집중하면서 백엔드 설계가 소홀히 이루어졌고, 이로 인해 기능 구현의 비효율성과
유지보수의 어려움을 초래했습니다. 백엔드 구조가 명확하지 않아서 데이터 흐름이 복잡해졌고,
클라이언트와의 통신에서도 일관성을 유지하기 어려웠습니다. 그 결과 프론트엔드와 백엔드의 조화로운 동작이 저해되었습니다.

4. 커밋 습관 부족

팀원들이 빈번하게 커밋하지 않아 코드 변경 사항 추적이 어렵고, 통합 과정에서 충돌이 빈번히 발생했습니다.
작은 변경 사항이라도 자주 커밋하여 팀 전체가 동일한 상태를 유지하도록 했어야 했습니다.

협업 툴 사용과 문서화 문제

1. 낯선 툴 사용

피그마와 같은 디자인 툴이 익숙하지 않아 사용에 어려움을 겪었고, 기획과 디자인 작업의 속도도 느려졌습니다.
툴 사용에 대한 기본 교육이나 학습 시간이 필요했으며, 디자인 작업의 지연은 기획의 지연으로 이어졌습니다.

2. 기록의 비효율성

많은 문서가 생성되었지만 세세한 부분이 기록되지 않아 기억에 의존해 문제를 해결하는 경우가 많았습니다.
기록이 일관되고 체계적으로 관리되지 않아 정보 누락과 오해가 발생했고, 이는 팀 전체의 이해도를 저하시키는 결과를 초래했습니다.

3. API 문서의 불친절함

API 문서가 구체적이지 않았고, 일부 내용에 잘못된 정보나 오타가 있어 개발이 어려웠습니다.
문서의 정확성과 구체성은 개발 속도와 품질에 직접적인 영향을 미치므로, 이를 개선할 필요가 있습니다.

개발 과정의 문제점

1. 기획의 중요성 인지와 기획 시간 부족

기획 단계에서 충분한 시간을 들이지 못해 컴포넌트 설계가 미흡했고, 프로젝트 막바지에 급하게 개발을 시작하게 되었습니다.
기획은 프로젝트의 성공을 좌우하는 중요한 단계이므로 충분한 시간을 투자해야 합니다.

2. 중복된 컴포넌트 구현

화면별로 개발 역할을 분배한 것이 오히려 중복된 컴포넌트 구현을 초래했습니다. 공통 컴포넌트를 먼저 설계하고
재사용하는 방식으로 개발했어야 했습니다.

3. 코드 스타일의 불일치

인라인 CSS 사용과 서로 다른 마크업 및 컴포넌트 구조로 인해 코드 병합이 지연되었고, 유지보수에도 어려움이 있었습니다.
코드 스타일을 통일하여 협업 효율성을 높이고 코드 가독성을 향상시켜야 했습니다.

4. 깃허브 기능 미사용

깃허브의 풀 리퀘스트나 프로젝트 기능을 충분히 활용하지 못해 협업이 원활하게 이루어지지 않았고,
시간 제약으로 코드 리뷰를 진행하지 못한 점도 아쉬웠습니다.

회고 및 개선 방향

1. 기획과 역할 분담의 철저함

각자의 역할과 책임을 명확히 정의하고, 기획 단계에서 충분한 시간을 투자해 명확한 방향성을 설정해야 합니다.
기획 단계에서의 충분한 논의와 역할 분담은 팀 전체의 효율성을 높이는 데 중요한 요소입니다.

2. 툴과 기술 숙달

낯선 툴 사용에 대한 학습 시간을 확보하고, 기술적 부족함을 보완하기 위한 연습이 필요합니다.
특히, 백엔드 설계와 테스트 코드 작성에 더 집중해야 합니다.

3. 기록과 소통의 개선

세세한 기록을 통해 모든 팀원이 동일한 정보를 공유하고, 기록이 효과적인 의사소통 수단이 되도록 개선해야 합니다.
기록의 체계적인 관리와 공유는 팀의 투명성과 효율성을 높이는 중요한 요소입니다.

4. 깃허브와 협업 도구의 적극적인 활용

깃허브의 풀 리퀘스트를 통한 코드 리뷰와 프로젝트 기능을 활용해 협업 효율성을 높이고 코드 품질을 향상시켜야 합니다.

5. 시각적 소통의 중요성

프로젝트 초반에 같은 말을 하더라도 각자가 떠올리는 이미지가 달라 서로의 생각을 일치시키거나
이해하는 데 많은 시간이 소요되었습니다. 피그마와 같은 도구를 통해 시각적으로 생각을 표현하는 것이 중요하다는 것을 느꼈습니다.
각자의 생각을 시각적으로 표현하고, 그 이미지에서 장점을 모아 수정하고 추가하는 과정이 매우 유익했습니다.

개인적으로 좋았던 점

1. 피그마 사용 경험

피그마를 깊게 사용해 볼 수 있는 기회가 되었습니다. 유료 기능이 잠겨 있어 제한적인 부분도 있었지만,
프로젝트 덕분에 피그마를 자세히 사용할 수 있는 기회가 되었고, 이를 통해 디자인 툴에 대한 이해와 활용 능력을 높일 수 있었습니다.

2. 팀 프로젝트 경험

이번 프로젝트는 팀 프로젝트를 제대로 경험한 기회였습니다. 이전에는 한 사람에게 모든 짐이 지워지거나
도메인 지식 없이 진행해 팀원 간 불화가 발생한 경우도 있었지만, 이번 Trip Track 프로젝트에서는 팀원 간의 불화 없이
소통이 잘 이루어졌고, 참여율도 높아 긍정적인 팀워크를 경험할 수 있었습니다.

3. 프로젝트 규모에 대한 인식

다음번에는 프로젝트 규모를 MVP를 고려하여 적절하게 설정하고 구현해야겠다는 교훈을 얻었습니다.
최소 기능을 먼저 구현하고 점진적으로 확장하는 방식이 효율적임을 깨달았습니다.

4. 협업의 가치 인식

함께하면 느리더라도 결과를 만들어낼 수 있다는 점을 깨달았습니다. 개인적으로 빠르게 처리할 수 있는 일이라도
팀과 함께하면 더 많은 아이디어와 다양한 시각을 반영할 수 있으며, 결과적으로 더 나은 결과를 얻을 수 있다는 점을 배웠습니다.

이번 프로젝트를 통해 우리는 많은 어려움을 겪었지만, 이러한 어려움 속에서 많은 것을 배웠습니다.
팀원 모두가 각자의 역할을 명확히 하고, 기획과 설계 단계에서 더 많은 시간을 투자하며, 소통을 원활하게 한다면
앞으로 더 나은 결과를 도출할 수 있을 것입니다. 이번 경험을 바탕으로 우리는 앞으로의 프로젝트에서 더 나은 성과를 내기 위해
각자의 부족함을 보완하고, 협업의 중요성을 깊이 인식하며, 기술적 역량을 더욱 발전시켜 나갈 것입니다.

ChatGPT-4o with canvas 가 작성한 프로젝트 회고

프로젝트 동안 작성한 문서와 실제 구현한 코드를 통해 ChatGPT에게 회고하도록 요청한 결과를 함께 첨부합니다.

Trip Track 프로젝트 회고

코드 리뷰 분석

React 컴포넌트 구조

PostList.jsx와 Map.jsx는 각각 포스트 목록과 지도 관련 기능을 독립적으로 관리하여 코드의 가독성을 높였습니다.
이러한 컴포넌트 분리는 유지보수성과 재사용성을 크게 향상시켰습니다.
특히, 각 기능을 독립적인 모듈로 구분함으로써 코드를 이해하고 수정하기 쉽게 만들었습니다.
그러나 prop drilling 문제가 일부 컴포넌트에서 발생했습니다.
여러 계층에 걸쳐 props를 전달하면서 코드를 복잡하게 만들었고, 컴포넌트 간의 결합도를 높였습니다.
이를 해결하기 위해 Context API나 Recoil 상태 관리를 활용해
전역 상태로 공유할 수 있는 값들을 한 곳에서 관리하는 방식이 더 적합했을 것입니다.

전역 상태 관리

Recoil을 사용하여 전역 상태를 관리한 점이 매우 인상적이었습니다.
이를 통해 여러 컴포넌트 간의 데이터 공유가 간편해졌고, 코드의 복잡성을 줄이는 데 큰 도움이 되었습니다.
하지만 전역 상태의 범위를 너무 넓게 설정할 경우 코드의 복잡성이 오히려 증가할 수 있습니다.
예를 들어, 전역 상태에 너무 많은 데이터를 포함시키는 경우 상태 변경에 따라 불필요한 재렌더링이 발생할 수 있습니다.
따라서 컴포넌트별로 적절한 상태 범위를 설정하고, 필요한 경우 Recoil Atom을 작게 나누어 관리하는 것이 좋습니다.

테스트 코드 작성

Post.test.js와 같은 단위 테스트가 잘 작성되어 있어 개별 기능의 테스트가 가능했습니다.
단위 테스트는 각 기능이 독립적으로 잘 동작하는지를 확인하는 데 매우 중요한 역할을 했습니다.
하지만 통합 테스트와 백엔드 연동 테스트가 부족하여, 제공된 프로그래머스 API와의
실제 연동 테스트를 충분히 진행하지 못한 점이 아쉬웠습니다. Cypress와 같은 E2E 테스트 도구를 사용해
사용자 시나리오 기반의 테스트를 추가하는 것이 필요합니다. 이를 통해 실제 사용자가 시스템을 사용하는 방식대로
테스트할 수 있으며, 연동 과정에서 발생할 수 있는 오류를 조기에 발견하고 수정할 수 있을 것입니다.

코드 병합 및 브랜치 관리

코드 충돌 문제는 각자의 브랜치를 로컬에서 임의로 합치는 과정에서 발생한 것으로 보입니다.
Pull Request(PR)를 사용하지 않고 직접 병합하는 방식은 코드 품질을 저하시키고, 충돌을 발생시키기 쉽습니다.
각자의 로컬 환경에서 수동으로 합치는 과정에서 코드 충돌이 빈번하게 발생했고, 이로 인해 디버깅 시간이 증가했습니다.
이러한 문제를 방지하기 위해 Git Flow와 같은 브랜치 전략을 도입하고, 모든 병합을 PR을 통해 이루어지도록 하는 것이 필요합니다. 이를 통해 팀원 간 코드 리뷰를 통해 잠재적인 버그를 조기에 발견하고 수정할 수 있으며, 코드의 품질을 향상시킬 수 있습니다.

데이터베이스 및 API 연동

처음에는 MongoDB와 직접 서버를 구현하려 했으나, 급하게 제공된 프로그래머스 API로 변경하면서
MongoDB 연동이 이루어지지 않았습니다. 이 과정에서 데이터 스키마를 간소화하고
API와의 연동을 위해 모델을 재설계한 점은 긍정적인 접근이었습니다.
그러나 초기 계획 단계에서 충분한 검토가 부족하여 중간에 구조를 변경해야 했던 것은 아쉬운 부분이었습니다.
API를 사용할 때와 직접 DB를 사용할 때의 차이를 미리 예측하고, 각각의 장단점을 검토했더라면
더 원활한 전환이 가능했을 것입니다. 또한, 데이터 모델의 변경에 따른 영향도를 충분히 파악하고,
변경 사항을 체계적으로 관리하는 것이 중요합니다.
이를 통해 데이터베이스 설계의 중요성을 다시금 인식하게 되었습니다.

잘한 점

명확한 목표 설정과 주제 선정
- Trip Track 프로젝트는 여행 관련 경험을 공유하는 커뮤니티 플랫폼으로, 사용자가 지도에 여행 일정을
  시각적으로 기록하고 다른 사용자들과 공유할 수 있는 독창적인 기능을 포함했습니다. 이러한 프로젝트 주제와 목표는
  기존 SNS의 단점을 해결하고, 사용자들이 여행의 흐름을 쉽게 파악할 수 있도록 해주었습니다.
  프로젝트 초기부터 명확한 목표를 설정함으로써 팀원들이 방향성을 잃지 않고 각자의 역할을 수행할 수 있었습니다.
- 참조 문서: 프로젝트의 목표와 방향 설정은 개발 보고서와 유스케이스 명세에 잘 나타나 있습니다.
  이 문서들은 팀원들에게 명확한 개발 방향을 제공하며, 기능별 요구사항을 체계적으로 기록했습니다.
팀원의 적극적인 참여와 협업
- 프로젝트 기간 동안 팀원들은 각자 맡은 컴포넌트와 기능을 책임감 있게 개발했고, 줌과 디스코드 등을 통해
  원활한 협업을 이루었습니다. 일일 보고서에 나타난 회의 기록 및 활동 내역을 보면, 각 팀원이 주요 기능 개발을 책임지며
  효율적으로 진행했음을 알 수 있습니다. 특히 화면별 책임 분담을 통해 개발이 체계적으로 이루어졌습니다.
- 참조 문서: 일일 회의 보고서에서 팀원들이 각자 맡은 기능을 어떻게 개발했는지,
  어떤 이슈들을 해결했는지가 잘 기록되어 있습니다. 이를 통해 팀원들의 협업 상황을 파악할 수 있었습니다.
기술 스택의 적절한 활용
- React, Google Maps API, Recoil 등 다양한 라이브러리와 API를 효과적으로 활용하여 UI와 기능을 구현했습니다.
  이를 통해 사용자들이 지도에서 여행 경로를 직관적으로 확인하고 포스트를 통해 여행 경험을 시각적으로 나눌 수 있었습니다.
  이러한 기술 활용은 프로젝트의 독창성을 높이고 사용자의 경험을 풍부하게 만들어주었습니다.
- 참조 코드: 유스케이스 명세, 시퀀스 다이어그램, DB 설계 문서, 개발 보고서에서 기술 스택 사용 방식이 잘 드러나 있으며,
  프론트엔드와 백엔드가 어떻게 효율적으로 연결되었는지를 명확하게 설명하고 있습니다.
  특히 Google Maps API를 사용해 지도 상에서 사용자 경험을 강화한 부분이 돋보였습니다.
테스트와 피드백 기반의 개선 노력
- 매일 팀 회의를 통해 기능별 진행 상황을 공유하고, 각종 오류 수정 및 기능 개선 작업을 지속적으로 수행했습니다.
  특히 더미 데이터를 생성해 테스트를 진행하며 예상치 못한 문제를 조기에 발견하고
  해결하는 과정을 통해 프로젝트의 완성도를 높였습니다.
- 참조 문서: 테스트 과정은 일일 보고서와 유스케이스 명세에 구체적으로 기록되어 있으며,
  더미 데이터 생성과 테스트 시나리오가 어떻게 구현되었는지 확인할 수 있었습니다.

부족했던 점

구현 범위의 과도함
- 초기 계획에서 기능 구현 범위가 다소 넓게 설정되어 있었고, 그로 인해 프로젝트의 일부 기능이 축소되었습니다.
  예를 들어, 여행 경로 교통수단 입력, 이메일 인증 등의 기능은 계획 단계에서 삭제되었으며,
  이는 초기 요구사항의 명확한 우선순위 설정의 중요성을 시사합니다. 각 기능의 중요도와 필요성을 조기에 평가하여
  개발 범위를 현실적으로 설정하는 것이 필요했습니다.
- 참조 문서: DB 설계 문서에서 삭제된 기능들의 목록과 이유가 명확하게 설명되어 있습니다.
  이를 통해 계획 단계에서의 과도한 범위 설정과 실제 구현 가능성 간의 괴리를 파악할 수 있었습니다.
커뮤니케이션의 효율성
- 원격 협업 도구(줌, 디스코드)를 통해 팀원들이 소통했으나, 일부 회의에서는 의사소통의 비효율이 발생하기도 했습니다.
  예를 들어, 코드 합치기와 충돌 해결 과정에서 시간 소요가 컸으며, 팀원 간의 명확한 역할 분담과 사전 합의가 더 필요했습니다. 효율적인 원격 협업을 위해 코드 리뷰 절차와 브랜치 관리 방식을 더 체계적으로 마련할 필요가 있습니다.
- 참조 문서: 9월 19일 회의록에서는 코드 충돌 문제와 관련한 논의가 기록되어 있습니다.
  특히 브랜치 전략과 역할 분담의 중요성이 이슈로 제기되었습니다.
DB 설계 및 백엔드 연동의 어려움
- 백엔드와 데이터베이스 설계 과정에서 몇 차례 어려움이 있었고, 처음에는 MongoDB와 직접 서버를 구현하려 했으나
  급하게 제공된 프로그래머스 API로 연동하는 것으로 변경되었습니다. 제공된 API를 사용할 때는 MongoDB를
  사용하지 않았으며, 기능 축소와 재설계가 필요했습니다. 초기 단계에서 백엔드와 데이터베이스 구조에 대한
  충분한 검토와 실험이 있었다면 개발 중간의 혼란을 줄일 수 있었을 것입니다.
  데이터 모델링과 API 설계는 프론트엔드와의 연계성을 충분히 고려하여 좀 더 일관성 있게 진행할 필요가 있었습니다.
- 참조 코드: DB 설계 문서에는 MongoDB와 API 연동 과정에서의 어려움과 수정된 구조가 기록되어 있습니다.
  초기 데이터 모델링의 부족함이 중간에 수정된 사례로 볼 수 있습니다.

개선 방안 및 제언

명확한 우선순위 설정
- 프로젝트 초기에 요구사항을 명확히 하고, 기능별 우선순위를 설정하는 것이 필요합니다.
  우선순위가 명확하면 자원의 한정된 상황에서도 핵심 기능을 먼저 구현하여 프로젝트의 주요 가치를
  사용자에게 전달할 수 있습니다.
- 참조 문서: 유스케이스 명세에 각 기능의 우선순위와 필수/선택 여부를 명시함으로써,
  보다 명확한 개발 방향을 설정할 수 있을 것입니다.
협업 도구 활용 극대화
- Git의 브랜치 전략과 코드 리뷰 문화를 강화하여 코드 합치는 과정에서 발생하는 충돌을 줄일 필요가 있습니다.
  또한 Notion이나 Jira 같은 프로젝트 관리 도구를 좀 더 적극적으로 활용하여 업무의 진행 상황과
  책임 소재를 명확히 하면 협업의 효율성을 높일 수 있을 것입니다.
- 참조 문서: 개발 보고서와 일일 회의록에 따르면, 코드 충돌과 역할 분담 이슈가 지속적으로 발생했습니다.
  이러한 문제를 해결하기 위해 브랜치 전략과 코드 리뷰 문화를 강화하는 것이 필요합니다.
테스트 자동화 및 백엔드 안정성 확보
- 프로젝트의 안정성을 위해 테스트 자동화를 도입하고, 백엔드와의 연동 테스트를 충분히 진행하는 것이 필요합니다.
  특히 백엔드와의 데이터 연동 과정에서 발생하는 오류를 조기에 발견하고 수정하기 위해
  통합 테스트를 자동화하는 방안을 고려할 수 있습니다.
- 참조 문서: DB 설계 문서에서 백엔드와의 연동 시 발생한 이슈와 이에 대한 해결 방안이 기록되어 있습니다.
  이를 통해 자동화된 테스트의 필요성을 느낄 수 있었습니다.

마무리

Trip Track 프로젝트는 여행 경험 공유라는 명확한 목표를 중심으로, 지도 기반의 독창적인 기능을 성공적으로 구현한 사례입니다.
팀원들의 적극적인 참여와 협업 덕분에 많은 부분에서 의미 있는 결과를 도출할 수 있었으며, 이러한 경험을 바탕으로
향후 더 나은 프로젝트를 만들 수 있는 기반이 마련되었습니다. 이번 회고를 통해 도출된 개선점들을 바탕으로,
다음 프로젝트에서는 더욱 효율적이고 완성도 높은 결과물을 기대할 수 있을 것입니다.

참조 문서: 개발 보고서, 유스케이스 명세, DB 설계 문서, 와이어프레임, 압축 파일 내 코드 분석.
이러한 문서들은 프로젝트의 전체적인 진행 상황을 체계적으로 기록하고, 개선점을 파악하는 데 큰 도움을 주었습니다.

대표이미지는 프로젝트 때 사용했던 로고를 수정하여 사용했습니다