패스트캠퍼스 데브캠프_김민태의 프론트엔드 개발 1기_파이널 프로젝트

이번에는 1개월간 진행된 패스트캠퍼스 파이널 프로젝트에 대해 글을 써보려고한다.

간단하게 이번 프로젝트에 대해 소개를 하고 어떻게 기획을 했고 어떻게 다른 직군들과 협업을 했는지 써보겠다.

그리고 마지막으로 프로젝트를 진행하면서 아쉬웠던점들을 회고를 통해서 풀어내보겠다.

목차

• 파이널 프로젝트 개요
• 프로젝트 진행 과정
  1.기획
  2.협업
• 파이널 프로젝트 회고

파이널 프로젝트 개요

• 패스트 캠퍼스 김민태 부트캠프에서 진행한 프로젝트이다.
• 지난 프로젝트와 다르게 패캠 백엔드 부트캠프 수강생과 디자이너님과 같이 협업 하는 프로젝트이다.
• 이번 프로젝트는 기업 연계 프로젝트이다. 기업에서 준 RFP(프로젝트 제안 요청서)를 바탕으로 프로젝트를 진행한다.
• 프로젝트 주제들은 기업 연계 프로젝트에 참여한 기업이 어떤 기업이냐에 따라서 달라진다.
• 프로젝트 주제를 선택할 수 있다. 이번에 파이널 프로젝트에는 2기업이 참여했고 각 기업 마다 한가지 주제를 가져왔다.(이번에는 총 2가지 프로젝트 주제 중에 하나를 선택할 수 있다.) 나는 이 중에서 '오디오 생성 플랫폼' 주제를 선택했다.

프로젝트 진행 과정

1. 기획

제일 먼저 FE, 디자이너들이 모여서 기능정의서, 와이어프레임을 먼저 작성을 했다.

다만 바로 기능정의서를 먼저 작성하려고 하니 몇가지 문제가 발생했다.

문제
1. RFP(프로젝트 제안 요청서)에서 정의한 기능들이 이해가 안되서 기능정의서를 제대로 작성하기 어려움.
2. 이 플랫폼을 사용하는 유저가 누군지 모르기 때문에 어떻게 개발을 해야될지 감이 잡히지 않았음.

이 문제들은 이렇게 해결했다.

1. 다행히 패캠 매니저님들 해당 프로젝트 주제를 제안해주신 기업 담당자님들과 질답을 할 수 있는 시간을 마련해주셨다. 이 질답 시간에 RFP에서 모호했던 내용들을 해결할 수 있었다.
2. 해당 기업 사이트에 방문해서 어떤 유저들이 이 서비스를 이용하는지 확인하고, 나름대로 서비스 사용자가 도대체 어떤 사람인지 사용자를 정의를 했다.

우리가 만들 오디오 서비스의 사용자는 두 종류라고 생각해서 이렇게 간단하게라도 사용자를 정의했다.

2. 협업

전체회의(+스크럼)를 진행하는 방식으로 프론트엔드팀은 백엔드와 디자이너님과 협업을 진행했다.

협업 방식

• 매주 월/목 백엔드, 프론트엔드, 디자이너 팀장 회의
• 평일 10시 BE/FE(+디자이너) 나눠서 회의후, 정리된 회의록을 공유
• 매일 스크럼
• FE BE 회의록 공유

스크럼

매일 아침에 BE, FE를 나눠서 스크럼 회의를 진행하고 회의 내용을 Geekbot에 넣어서 공유하는 방식으로 진행했다.

프론트엔드팀 작업 프로세스

지난 프로젝트들에서 느꼈던 문제들(기능 개발 때문에 코드퀄리티 악화, 시간부족)을 해결하고자 몇가지 목표를 먼저 선정하고 작업 프로세스를 만들었다.

• 목표1: 문서화보다는 동작하는 소프트웨어
• 목표2: 빠른 개발 동시에 코드 퀄리티 유지하기

실제 작업은 다음과 같은 프로세스로 이루어졌다.

작업 흐름도
1. 디자인 시안(색상지정X, 폰트X, 크기X)이 나오면 바로 작업 진행
2. 작업을 각 작은 작업으로 나눠서 이슈 작성
3. 담당자 지정 후 개발 진행
4. 각 담당자가 코드를 작성하고 통합 브랜치(develop)에 Pull Request를 보냄.
5. Pull Request에 대해 AI코드 리뷰와 다른 프론트엔드 팀원들의 리뷰를 진행하고
6. develop 브랜치에 merge된 후 먼저 스테이이징 배포(실제 메인 배포서버는 백엔드 검수후 진행)가 이루어짐. CI/CD

디자인 시안-> 페이지 작업 -> 상세 디자인 -> 페이지 수정 -> 스테이징 배포(파이어베이스)

요런식으로 실제 PR이 올라오면 바로 배포된 사이트 주소가 표시가 된다.
리뷰어가 코드 리뷰를 위해 직접 자기 컴퓨터에서 코드를 실행해서 확인하지 않고 저 코맨트에 남겨준 링크를 확인하기만 하면 되서 편했다.

그리고 SonarQube(코드 정적 검사기)가 통해 웹접근성이 낮은 코드들을 자동으로 알려줘서 어떤 코드를 고치면 될지 바로 알수 있었다.

그리고 이번 프로젝트는 공통 컴포넌트들을 먼저 만들고 시작해서 중복코드를 줄이고 조금 더 효율적인 개발을 할 수 있었다.

파이널 프로젝트 회고

이번 프로젝트를 통해 배운 점들도 많지만 아쉬운 점들도 많았던 프로젝트였다.

그러니 회고를 통해 이번 프로젝트를 정리하면서 어떻게 하면 더 나아질 수 있을지 고민해볼 것 이다.

Keep (잘한점들, 배운점들)

1. CI/CD를 나름대로 구축을함.
2. 스크럼 회의를 매일 진행하여 협업을 진행함.
3. API를 요청하는 코드에 문제가 발생시 어떻게 디버깅하면 좋을지 알게됨.
4. 나름대로 스토리북과 Openapi generator등 새로운 기술들을 프로젝트에 도입해봄.

Problem ( 부족했던 점들, 아쉬운 점들)

1. 위 글에서는 언급하지는 않았지만 백엔드와 협업이 순탄치 않았다.
   1-1. 백엔드팀에서 생각보다 백엔드 API를 만들기가 어려워서 백엔드 팀 작업이 오래걸렸다.
   1-2. 그리고 만들어진 백엔드 API가 조금 이해하기 어려운 점들이 많았다. 백엔드 팀에서 고맙게도 문서화를 해두긴했지만, 숨겨진 기능들?이 많았고, 나의 직관과 다르게 동작하는 API들이 많았던 것 같다.
   1-3. 그래서 API를 사용하고 프론트엔 코드에 작성하는데 까지 너무 많은 시간이 소요되었다.
2. ai에 의존도가 더 높아진 느낌이다. 다만 프롬프트를 작성하는 방법이 늘긴했다.

Practice

1. API 명세서를 백엔드 개발전에 먼저 프론트엔드 팀과 협의를 통해 같이 만들고 그 다음에 백엔드 API 작업을 진행하도록 해봐야겠다.
2. API 관련해서 협의를 많이 진행해야 될 것 같다.
3. 백엔드 작업이 완료 되기 전에 미리 목서버를 만들어서 프론트엔드 작업을 할 수 있도록 해봐야겠다.