코드잇 첫 프로젝트 회고

 

 

첫 프로젝트를 회고해보려한다.

기간 2주였고 멤버는 총 5명이 진행한 프로젝트이다.

 

중간에 1명이 부트캠프를 포기해서 결국 4명으로 프로젝트를 진행했다.

그 부분이 참 마음을 힘들게 했지만,

남은 4명은 사이가 좋아진 계기가 되었다.

 

그럼 우리의 첫프로젝트를 소개해볼까 한다.

 

fandom-k 시현영상

 

서비스 소개 및 선정 이유

 

우리는 총 4개 의 프로젝트 중 난이도가 상인 프로젝트를 선정하였다.

아이돌이라는 주제가 시각적으로 눈에 확들었고 다른 프로젝트와 차별성이 있어 보였기 때문이다.

어렵더라도 실력으로 남을꺼라 생각 했기 때문에 그렇게 우리 팀은 도전을 해보기로했다.

 

 

서비스 소개

 

'Fandom K'는 아이돌 조공 플랫폼이다.

사용자가 보유한 크레딧을 통해 원하는 아이돌에게 후원을 하여 광고를 걸거나,

이달의 차트 투표로 아이돌의 순위를 올릴 수 있는 팬덤 활동을 지원하는 서비스이다.

 

 

세부계획

7월 10일	상세 기획 후 멘토님께 확인 받기
7월 11일	기본 폴더 구조 및 작업 환경 세팅
7월 13일	1차 구현(UI) 및 멘토님께 확인 받기
7월 15일	중간 점검
7월 17일	2차 구현(기능) 및 멘토님께 확인 받기
7월 18일	오프라인 팀미팅(오류 수정 및 리팩토링)
7월 20일	통합 테스트 및 멘토님께 확인 받기
7월 22일	발표 준비
7월 24일	발표

 

 

R & R

곽민조	헤더/내 크레딧/크레딧 충전하기 모달창 컴포넌트, 리팩토링, PPT 제작, 발표
김주은	swagger 데이터 생성, 후원하기 모달창/크레딧 부족 모달창 컴포넌트, 리팩토링
나윤주	초기 스타일 설정, 랜딩 페이지, 후원을 기다리는 조공/이달의 차트/투표 모달창 컴포넌트, 리팩토링
오정민	마이 페이지(내가 관심 있는 아이돌/관심 있는 아이돌 추가 컴포넌트), 리팩토링

 

주요 결정 사항

 

• ESLint 및 Prettier 사용
  • ESLint는 에어비앤비의 규칙을 따르되 예외로 할 규칙은 팀원과의 상의를 통해 결정
• 일반 CSS만 사용하기(Tailwind CSS는 사용 X)
  • 클래스 네임을 하나로 작성하지 말고
  • 계층으로 선언하기
• 확장자 규칙
  • .jsx: jsx 코드를 리턴하는 파일
  • .js: 일반 자바스크립트 코드를 리턴하는 파일
• 폴더 규칙
  • pages 폴더 안에 각자 페이지 폴더 만들고
  • 그 안에 ~page.jsx 및 ~page.css 파일과 components 폴더를 두고 작업

• 의사소통 방법
  • 코어 타임: 오후 1시~5시
  • 데일리 스크럼: 오후 1시
  • Zep에 모여 실시간으로 소통
• Git 브랜치 전략
  • main: 최종 출시 버전을 관리하는 공용 브랜치
  • develop(dev): 출시할 버전을 위해 개발하는 공용 브랜치
  • feature/: 새로운 기능을 개발하는 개인 브랜치
  • release/: 릴리즈 준비를 하는 브랜치
  • hotfix/: 긴급 버그 수정을 위한 브랜치
• 커밋 메시지 방식
  • 아래 이미지 내용을 기반으로 함
  • 형식: “type_keyword(소문자로 시작): 한글로 세부 내용 적기”

 

 

 

문제점 / 아쉬운 점

 

기능적 측면의 문제점

1. 크레딧 차감 및 추가 부분의 원활하지 않은 동작
   • 각 컴포넌트에서 로컬 스토리지가 통합 관리되지 않아 변화가 반영되지 않았다.
   • 이를 해결하기 위해 로컬 스토리지 관리를 context로 전역 관리하도록 개선하였다.
2. 모달에서 저장한 투표 내용의 반영 문제
   • 투표 내용을 저장한 후 메인 화면에 반영되지 않았다.
   • update 함수를 props로 내려 전역에서 관리하도록 개선할 필요가 있었다.
3. 사용자 경험(UX) 측면의 아쉬움
   • 사용자가 더 편리하게 이용할 수 있도록 토스트 알림 기능을 추가했으면 좋았을 것 같다.

 

전체적인 프로젝트의 아쉬운 점

1. 개발 계획의 부족
   • 처음 개발 계획을 더 꼼꼼하게 세웠더라면 시행착오를 줄일 수 있었을 것 같다.
   • 4명의 개발자가 각각 다른 클래스 네임 규칙을 사용하여 스타일 규칙이 중복되는 문제가 있었다.
   • 처음부터 클래스 네임 규칙을 잘 정했다면 시간을 단축할 수 있었을 것 같다.
2. 컴포넌트 설계의 부족
   • 컴포넌트를 체계적으로 설계하지 않아 중복되는 UI를 그리게 되었다.
   • 첫 프로젝트라 무작정 요구사항을 분배하고 각자 작업한 결과 중복된 부분이 많았다.
   • 나중에 컴포넌트화하려 했으나, 생각보다 더 많은 손이 갔다.

이와 같은 경험을 통해 다음 프로젝트에서는 초기 계획과 소통의 중요성을 더욱 인지하게 되었다.

 

마무리

 

부트캠프 첫 프로젝트를 하면서 개인적으로는 많이 성장 할 수 있었다.

특히 중간 퇴소자가 구현하지 않은채 2차 기능 완료 시점에 퇴소해서 남은 기능을 급하게 구현하면서 몸이 힘들었다.

근데 그것 보다도  '또 안해오겠지' '또 거짓말하겠지'  이 맘으로 사람을 바라보니 모임 때마다 화가 났다.

못하는 건 상관 없지만, 미리 말을 안해주는 그분이 미웠다. 

 

그러면서 다시금 사람이 신뢰를 쌓기 위해서는 '약속'과 '소통'이 잘 이루어져 신뢰가 쌓인다는 생각을 하고 나는 이것에 좀 분노를 많이 내는 스타일이라는 걸 알았다. (좋은 인성의 사람들이랑 일 하고 싶은 마음이 더 커졌다.)

 

이때 나는 그분이 안해올 것 같아 미리 ui를 그려서 붙여넣기 하라고 준적도 있고 계속 체크 하면서 리마인드 시켰지만 결국 '퇴소'를 해버렸고 남은 팀원들끼리 재분배해서 기능을 구현하였다.

덕분에 남은 맴버들끼리 사이가 좋아지는 계기가 되었지 않나 싶기도 하다. 

 

이후 매니저님과 성실 맴버들이랑 다음 프로젝트 하고 싶다고 강력 어필을 했다. 

 

이번에 모르는 것을 해결해 나가겠다는 의지로 프로젝트를 잘 마무리 할 수 있어 돌아보니 아쉽지만 뿌듯한 첫 프로젝트가 아닌가 싶다.

다음 프로젝트는 뭔가 더 재밌게 할 수 있을 것 같다.