[fandom-k - 4] 기초 프로젝트 회고

이번 스프린트 기초 프로젝트를 진행하면서 시행착오가 많았고, 그만큼 팀 프로젝트에서 기본기가 얼마나 중요한지 제대로 느꼈다.

이번 경험을 5F로 정리했다.

5F는 다음을 의미한다.

• 사실(Fact)
• 느낌(Feeling)
• 교훈(Finding)
• 향후 행동(Future action)
• 피드백(Feedback)

사실(Facts)

1. 프로젝트 초기에 명확한 개발 컨벤션을 정의하지 않았다.
   그 결과 코드 스타일, 네이밍, 파일 구조가 모두 제각각이었다.

2. 색상, 폰트, 공통 컴포넌트 등 재사용 가능한 요소를 사전에 정리해두지 않았다.
   팀원마다 스타일 적용 방식이 달라 중복 코드가 많아졌고 유지보수가 어려웠다.

3. 진행 상황 공유가 원활하지 않았다.
   사전에 이야기한 방식과 다르게 구현되는 경우가 생겼고, 파편화된 방식으로 개발이 진행됐다.

느낌(Feelings)

1. 팀장으로서 초기 셋업을 제대로 챙기지 못한 점이 아쉬웠다.
   내가 준비했어야 할 부분을 놓쳤다는 생각이 들었다.

2. 리팩토링을 진행하면서 처음부터 제대로 셋업하고 시작했으면 훨씬 수월했겠다는 생각이 강하게 들었다.

3. 문제를 발견했을 때 어디서부터 손을 대야 할지 막막해서 잠시 멘붕도 왔다.

교훈(Learnings)

1. 개발 컨벤션은 반드시 프로젝트 시작 전에 정의해야 한다.
   혹은 중간중간 소통을 하며 컨벤션을 정의해 나가야 한다.
   그렇게 하지 않으면 소통의 부채로 해결 비용이 커진다.

2. 공통 스타일(색상·폰트·spacing 등)을 사전에 정해두지 않으면 결국 전체 코드가 난잡해진다.

3. 일정 관리는 생각 이상으로 중요하다.
   예기치 못한 변수(예: 컨디션, 일정 변화)가 생기면 전체 흐름이 금방 흔들린다.

향후 행동(Actions)

1. 프로젝트 기초 설정 단계에 컨벤션을 문서화해 둔다.

   • 코드 스타일
   • 파일 구조
   • 린트/포맷팅
   • API 구조
   • 배포 전략 등

2. 공통 스타일 시스템을 초기에 구성한다.
   컴포넌트까지는 아니더라도 색상, 폰트, spacing, shadow 등은 최소한으로 정의한다.

3. 프로젝트 마감 2~3일 전에 끝낸다고 가정하고 일정 잡기.
   버퍼가 없으면 결국 마지막에 몰리는 문제가 반복된다.

개인 피드백(Feedback)

1. 라이브러리에 의존하지 않고 모든 로직을 직접 구현한 점은 좋았다.
   기초 팀 프로젝트에서 이 정도 실험을 해본 건 분명 성장 포인트였다.

2. 하지만 일정은 더 명확하게 관리해야 한다. 감기 같은 예기치 못한 변수가 생기면 일정이 한 번에 무너지기 때문에 다음 프로젝트에서는 위험 요소를 감안해서 여유 있게 계획을 잡아야 한다.

3. 다음엔 적절한 라이브러리를 적극적으로 사용하는 것도 중요하다.

   • 개발 시간 단축
   • 코드 리뷰 수월
   • 유지보수 용이
   • 프로젝트 완성도 향상