AI 요약

9월 중간 프로젝트 진행 후, 개발환경, 목표, API 활용, 역할 배정, 깃허브 브랜치, 컴포넌트 관리, 스크럼 사용 등에 대해 공유. 개발 프로세스와 사용 기술에 대한 경험과 고민을 공유함.

근황
중간 프로젝트에 대해…
잘한 점
아쉬운 점 및 반성
관련 링크

근황

9월에는 데브코스의 중간 팀 프로젝트가 있었다.

이 달 내내 프로젝트만 했으니 내용이 다 관련해서 채워지지 않을까 싶다.

중간 프로젝트에 대해…

환경

231003-165947

중간 프로젝트의 과제명은 API를 활용한 웹 제작이다.

사실 너무 당연한 내용이라 상세 내용 공개 전까지 뭘까 싶었는데 제공되는 API를 대상으로 자유롭게 프로젝트를 진행하는 것이었다.

팀 자원은 프론트만 5명과 API 제작자와의 소통.

API를 추가하거나 수정할 수 없고, 필요 시 JSON에 내용을 추가해 사용하는 식이다.

기한은 9월 1일~27일.

기획

목표

API가 한정되어 있고, 기한이 짧다 보니 상세한 시장 조사 등은 생략되었고, 각자 소기의 목표를 설정해 이루고자 하였다.

나는 사용자 경험 측면에서 완성도 있는 서비스 기능을 제공하고자 했다.

명명

우리 팀은 각종 거래에 대한 평가와 피드백 공유가 가능한 커뮤니티 사이트를 만들기로 했다.

프로젝트 명은 여러 의견을 취합한 끝에 서비스와 직접적으로 연관된 키워드인 꿀매 에 평가와 관련되며 사용자의 관심을 끌 만한 특이한 어감과 적합한 뜻의 키워드인 중국 송나라 시대의 명판관 포청천 을 결합한 꿀매포청천 으로 정했다.

역할

팀에서 NextJS를 사용하기로 했기 때문에 내가 초기 개발 설정을 담당하게 됐다.

또한 이번 프로젝트 진행에서 관련 개발 경험이 상대적으로 많은 나는 일정 배분이나, 공통 사항에 대한 개발 및 리뷰 등을 위주로 역할을 수행하게 됐다.

제공되는 API 외에는 모든 것을 알아서 해야하는 프로젝트이다 보니 초기 역할을 나눌 필요가 있었다.

특히 팀의 전문이 아닌 디자인에 인력을 다수 배정하고, 그 외 문서 담당과 프로젝트 개발 초기 담당을 정했다.

231003-170004

한창 개발이 진행될 때 이전의 역할을 나눈 때에는 당장 필요한 테스크를 두고, 적합성에 문제가 없는 경우는 선호도를 순위 매겨 불만을 최소화 할 수 있도록 노력했다.

개발 프로세스

깃허브 브랜치

위에서 언급한 조건들을 고려해 제안했다.

1안
- 개별 personal develop을 두고 스프린트 종료 시 develop에 합치는 루틴
- 짧은 기간 안에 lean하게 협업하고 공통 컴포넌트를 사용하기 위해 적절치 못한 구조라 생각해 폐기
2안
- 각 이슈 별로 feature를 두고 develop에 지속적으로 통합.
- 각 스프린트 별로 진행사항과 기능 구현을 유지할 release 브랜치를 설정하고 버전 1.0을 위한 main 브랜치를 설정
- 빠른 충돌 해결과 공통 컴포넌트 사용을 위해 깃헙플로우를 약간 변형하여 사용

폴더 구조 및 컴포넌트 관리

간단히 서비스 관련 없는 공통 컴포넌트와 서비스 관련 공통 컴포넌트 그리고 지엽적인 컴포넌트를 관리하는 것을 제안했고, 팀원들도 환경을 고려해 이에 공감했으나 아토믹 디자인 패턴을 경험해보고 싶다는 의견이 더러 있었다.

조금 과하다는 생각은 있었지만 팀에 좋은 경험이 될 것 같아 도입하기로 했다. 기본적인 컨셉을 설명하고, 예시를 작성하여 공유했다.

스크럼 및 스프린트 룰

스크럼

231003-170048

기존 진행하던 데일리 스크럼을 프로젝트 위주의 주제로 사용했다.

일반적으로 스프린트는 2주에서 4주 정도로 진행하는 것이 일반적이나, 짧은 기한에 맞추어 일주일 단위로 설정했다.

231003-170100

일단 기획과 디자인 틀을 잡고 함께 유저 스토리를 작성했다.

231003-170107

그리고 매 스프린트 시작일에 큰 기능을 정의하고, 이에 해당하는 스토리를 부여했다.

회의 때 하나씩 살펴보며 팀원들이 생각하는 예상 작업 일 수를 산정하고 그에 맞추어 각 인원이 가능한 가용 시간에 맞추어 역할을 부여했다.

231003-171231

이전 과정을 통해 정해진 스프린트의 스토리를 기반으로 이슈를 작성하고, 이슈 넘버를 각 브랜치에 포함해 쉽게 협업자 간 개발 현황 또는 목표를 파악하도록 했다.

231003-171242

때문에 pull request 시에 자연스레 이슈와 해당 내용을 연결 지어 코드 변경 사항의 목적을 처음부터 설명할 필요가 없도록 했다. 때문에 코드 리뷰 간 서비스적인 맥락을 쉽게 파악토록 하고자 했다.

신경쓴 내용

이번 프로젝트에서(특히 NextJS를 사용하며) 내가 신경 쓴 부분은 좋은 사용자 경험을 위한 렌더링과 제한된 API를 최대한 커스텀하기 위한 방법이었다.

NextJS 자체 백엔드를 통해 제한된 API에서 클라이언트 처리가 아닌 서버 처리로 더 많은 기능 제작

231003-171256

이번 프로젝트의 조건 한계를 보완하기 위해 기 존재하는 API의 별도 응용을 클라이언트에 부여하지 않고 NextJS 백엔드에 위임함으로써 관심사를 분리하고 쉽게 모듈을 사용하기 위한 노력을 했다.
그 응용 사례의 대표적 예시가 ‘싫어요’ 기능 구현이다.

SSR과 tanstack query prefetch를 통해 주요 화면에 대해 로딩을 노출하지 않고 좋은 사용자 경험 제공

231003-171312

메인 페이지는 보다시피 노출하는 컨텐츠 양이 적지 않다.
그래서 다음과 같이 사용자의 FCP(First Contentful Paint)에 대해 좋은 경험을 부여하기 위해 전략적인 SSR과 CSR의 내용을 선택했다.
최초 사용자의 눈길이 가게 될 내용에 대해 서버사이드 렌더링으로 별도의 로딩 또는 스켈레톤 처리를 하지 않도록 하고, 그 이후에 상세 내용에 대해서 클라이언트 사이드 렌더링으로 전체 내용이 구성될 수 있도록 했다.

프로젝트에 대한 자세한 발표 내용은 아래 링크에서 확인 가능합니다.

꿀매포청천 소개

잘한 점

기술 제안, 일정 산정 및 배분, 개발 프로세스 관리, 전체적인 개발적 간섭(?)을 하게 됐는데 나름 만족스런 결과물이 나온 것 같다.
- 팀 회고에서도 이 부분에서는 다들 만족스럽다고 해서 뿌듯했다.
- 갈등도 딱히 없었고, 최대한 그 소지를 줄이고자 했다.
- 짧은 일정 상 끊을 때 끊는 것을 의도했는데, 안 했으면 일정을 지키지 못 했을 것 같다.
팀원에게 맡긴 부분은 확실히 맡기기
- 팀원에게 각자 challenge가 될 만한 과제를 맡겼다.
- 나도 누군가의, 누군가도 나의 코드가 만족스럽지 않을 수 있다.
- 일정 상 모든 개발의 부분을 딥하게 micromanagement 할 수도 없고, 할 필요도 없다.
- 간섭 대신 자유롭게 어려움을 겪을 때 공유할 수 있는 장소와 시간을 만들고, 리뷰에서 처리할 수 있도록 했다.
- 이를 사용하지 않는 경우에 대해서는 개인의 책임으로 하도록 의무와 책임을 자유롭게 했다.
매 스프린트 종료 시 배포를 통해 버그와 개선 사항을 처리하도록 했다.
공통 사항에 대한 공유가 활발히 이루어 진 것 같아 만족스럽다.
저번 팀에서의 피드백을 바탕으로 내 작업물 등에 대해 설명할 때 간단한 UML 등을 활용해 더 쉽게 이해할 수 있도록 노력했다.

아쉬운 점 및 반성

세심한 일정 공유가 부족했다.
- 최대한 일정을 산정하려 해보지만 테스크에 대해 정확한 예측을 하는게 쉽지 않다.
- 억지로 테스크를 부과하지는 않았지만, 팀원들이 착해서 개인 일정을 고려하지 않고 수용하는 경우가 있던 것 같다.
- 때문에 매 스프린트에 말미에 급하게 개발이 이루어져 잦은 충돌과 문제를 겪었다.
- → 배포 일정을 자주 처리하면 조금 더 lean하게 할 수 있지 않을까
기술 공유가 부족했다.
- 급한 때가 됐을 때나 회의가 진행된 이후 모르는 부분을 공유하는 경우가 있어 총 시간이 더 소요됐다.
- 팀원 분 중에 초기에 NextJS에 대해 간략히 발표회를 연 분이 있는데, 나도 이렇게 했으면 더 원활한 프로젝트가 됐을 것 같다.

→ 위 아쉬움들을 종합해보니 초반에 먼저 상세히 설명회 식으로 열었으면 설명에 대해 집중도 챙기고 한 번에 의문점도 해소하고 갈 수 있지 않았을까 하는 생각이 든다.

초기 세팅에서 프로젝트 외의 문제점도 있었다.
- 기억하기 위해 적자면, 노드 버전이 다르고 안정화 버전이 아닌 최신 버전을 사용해 문제가 생긴 케이스도 있었다. 미리 체크하고 가면 삽질을 조금이나마 줄일 수 있겠다.
기획 단계에서 아쉬움
- 키 포인트를 중심으로 가지를 뻗어나가는 식으로 해야겠다.
- 디자인에 따라 개발 난이도가 달라짐을 인식해야겠다.

꿀매포청천 프로젝트 회고

작성일: 2023.10.03