마지막 3편에서는 프로젝트 최종 회고 위주로 글을 풀어낼 예정이다.

이번 최종 회고에는 같은 프론트 팀 동료인 K님이 Lacked, Learned, Longed for 이 명시되어 아쉬웠던 점, 배운 점에서 Longed For을 이끌어나갈 수 있는 방향, 특히나 배운 점이 따로 명시되어 있으므로, 학습에 큰 비중을 둔 우리 프로젝트 성격과 어울릴 거 라는 이유로 4L 회고를 제안해주셨고 주관적인 생각이 담긴 4L 회고를 진행할 예정이다.

🫶 좋았던 점(Liked)

• 우리 팀(1조 최고!)
• 프론트 엔드 팀에 내가 속한 것
• DND 운영진 분들의 현실적인 조언들 & 여러 도움들(가이드라인, 여러 세션, 숙박 & 교통비 해결)

🥲 아쉬웠던 점(Liked)

기능 요구사항

기능 요구사항을 확정 낼 때 프론트 - 백 - 디자이너 간 소통이 부족했다고 생각했고 그로 인해 기능 요구사항 확정까지 예정보다 길어지게 되었다. 기능 요구사항 확정까지 처음 생각했던 프로세스는 다음과 같다.

기능 요구사항 관련 1차 회의 → 프론트 팀에서 페이지 별 요구사항 & API 요구사항 정리 → 각 팀에서 정리 요구사항 정리 → 기능 요구사항 확정에 대한 회의 진행

다음과 같은 프로세스를 생각했던 이유는 최종적으로 가장 먼저 유저를 만나는 쪽은 프론트엔드 이기에 페이지 별 요구사항을 먼저 정리할 필요가 있었고, 먼저 정리하는 김에 프론트에서 정리한 요구사항을 기반으로 개발 팀에서 요구사항을 정리한 후 2차 회의 때 확정 낼 계획이었다.

하지만 계획대로 되지 않았고, 약간의 의견 충돌이 발생했다. 돌이켜보면 각 팀의 사정이 존재한다는 걸 고려하지 못했던 거 같다. 운영진 분들의 의견을 고려했을 때 다음과 같은 프로세스를 지켰으면 좋았을 거 같다는 생각이 들었다.

기능 요구사항 관련 1차 회의 → 각 팀에서 필요한 기능 요구 사항 추가 정리 → 기능 요구사항 확정에 대한 회의 진행 → 개발 팀은 따로 API 요구사항 정리

이러한 프로세스 대로 진행되었다면, 빠트리는 기능 요구사항도 최소한으로 줄였을 거고, 각 팀에서 필요한 기능 요구사항들을 정리 했을 것이기에 의견 충돌도 나지 않았을 거 같다.

촉박한 일정

프론트 팀의 경우 첫 스프린트 시작이 2/6 이었다. 즉, 실 개발 기간이 1달도 되지 않았다. 그로 인해 스프린트 기간도 2일 이었고, 매일 데일리 스크럼과 5시간의 코어 타임, 그 이후에도 끊임 없는 회의와 개발로 인해 거의 매일 10시간 넘게(사실 스스로 요령이 없던 탓도 있었다.) DND 일정에 몰두 했던거 같다. 그로 인해 스스로 예민해질 수 밖에 없었고, 약간의 감정을 드러냈던 거 같아 팀원 분들에게 죄송 스러웠다.

또한, 개발 막판 코드 리뷰와 스프린트 회고, 전반적인 문서화 과정을 스스로 제대로 하지 못했던 거 같다. (일정 탓을 하면 안되지만 정말 너무 힘들었다.)

8기 프론트 분의 회고 중 특정 구절이 인상 깊었는데, 그 구절은 다음과 같다.

'나를 갈아 넣으면 될 것 같은데' 라는 일정보다는 좋은 팀워크를 유지하며 끝까지 마무리할 수 있는 여유롭고 탄탄한 일정이 되었으면 좋겠어요.

되돌아 봤을 때 이번 프로젝트는 정말 나를 갈아 넣어서 만들었던 프로젝트 였던거 같지만 찝찝한 감정을 참을 수 없는 내 성격 + K님의 개발 열정으로 인해 다시 프로젝트를 진행해도 최선을 다하려고 노력했을 거 같다.

하지만 다음 프로젝트를 진행한다면, 팀을 위해서라도 굳이 8주에 얽매이지 않고, 발표 할 수 있는 선에서 어떻게 개발을 진행할 지 좀 더 고민해보고 생각해서 회의 때 스스로 제안할 수 있는 사람이 될 거 같다.

회고

우리 1조의 경우 KPT 회고를 중간 발표 이후 도입하게 되었는데, 지극히 개인적인 생각이지만 매 주 KPT 회고를 했으면 어땠을까 라는 생각이 들었다. KPT 회고를 하면서 개인적으로 느꼈던 건 스크럼에선 잡을 수 없던 지난 일 들에 대한 문제들에 대해 즉각적인 피드백이 가능하다고 느꼈기 때문이다.

우리 팀 KPT 회고 중 Problem의 한 부분인데, 실제로 문제 해결을 위해 1:1 DM을 많이 하게 되어 다른 동료들이 해당 문제에 대해 제대로 인식하지 못했던 문제들이 존재했고, 8-1 ui(디자이너 - 프론트) 채널, 8-1 dev(프론트 - 백엔드) 채널을 추가하여 각 직군 간 소통을 강화하려 했고 완벽히 해결하지는 못했지만(내 스스로의 문제도 조금 있었다) 어느정도 해결할 수 있었다.

그 밖에도 msw 사용 포기 등의 아쉬움이 존재 했다.

📖 배웠던 점 (Learned For)

📝 데일리 스크럼 & 스프린트 도입

데일리 스크럼과 스프린트의 경우 프로젝트 중간 발표 이후 같은 팀 동료 K님의 제안으로 프론트엔드 팀에서 데일리 스크럼과 스프린트를 동시에 진행하였다.

🥰 프론트 팀의 데일리 스크럼과 스프린트

개발 기간이 매우 짧은 일정을 고려해서 웬만하면 스프린트는 2일에 1번으로 고정하였으며 데일리 스크럼의 경우 특별한 이슈가 발생하지 않으면 매일 진행되었다.

우리 팀의 스프린트 & 데일리 스크럼 순서는 다음과 같았다.

스프린트 순서

스프린트 목표 → 목표와 관련된 회의 주제 선정 및 회의 진행 → 업무 분담 → 스프린트 회고 → 다음 스프린트 계획

데일리 스크럼 순서

스타트 스크럼(전날 안건 논의) → TO DO → 에로 사항 → 클로즈 스크럼(추가 논의 사항 및 내일 TO DO)

평소 애자일을 실천해보고 싶다는 생각만 가지고 있었고, 학교 프로젝트에서 시도했다 처참히 실패하고 생각도 하지 않았는데, K님의 제안으로 하고 싶었던 스프린트와 데일리 스크럼을 꽤나 체계적으로 실천할 수 있었다.

개발 후반으로 들어서면서 번아웃과 스트레스로 인해 양질의 스크럼을 스스로 못했던 거 같지만, 마지막 스프린트 & 데일리 스크럼까지 무사히 마무리할 수 있도록 열심히 불태워주셔서 마지막까지 진행할 수 있었다.

개발할 컴포넌트들과 페이지들이 정말 많았기에 스프린트 & 데일리 스크럼이 아니었다면 정말 프로젝트 완성을 하지 못했을 거 같단 생각이 들었고 정말 하길 잘했던 체계 중 하나였다.

💻 코드 리뷰

코드 리뷰 중 일부 발췌한 내용

코드 리뷰 in 뱅크샐러드 개발 문화

프론트 팀의 경우 뱅크 샐러드의 코드 리뷰 방식을 채택하여 개발 기간 동안 코드 리뷰를 진행했다. 개인적으로 p1은 자제하고 p2~p5를 주로 사용하며 코드 리뷰를 진행했다.

p1. 꼭 반영해주세요 (Request changes)

p1은 코드 리뷰 시 존재하지 않았는데 암묵적으로 p1의 경우 필수적으로 수정을 강제한다고 생각되어 같은 팀 동료의 감정을 상하게 할 수 있다고 생각했다. 그래서 p1은 최대한 사용을 자제 하게 되었다.

p2. 적극적으로 고려해주세요 (Request changes)

p1의 실질적인 역할을 p2로 진행하게 되었다. 실질적으로 문제가 발생한다고 확신한 경우 p2를 사용하여 코드 리뷰를 진행하게 되었고, 대부분의 경우 실제로 문제가 있었어서 코드 수정이 진행되었다.

p3. 웬만하면 반영해 주세요 (Comment)

p3의 경우 문제가 있을 거라고 스스로 생각되지만 확신이 들지 않아 토론이 필요 할 경우 p3를 사용하여 코드 리뷰를 진행하려고 했다. 실제로 토론을 거치면서 왜 이런 코드를 사용했고, 그 코드 사용으로 인해 어떤 결과를 예상했을지에 대해 알 수 있었으며, 문제 해결에도 도움이 되는 코드 리뷰가 될 수 있었다.

p4. 반영해도 좋고 넘어가도 좋습니다 (Approve)

p4의 경우 중요하진 않지만 바뀌면 좋을거 같은 부분들을 p4를 사용하여 코드 리뷰를 진행하려고 노력했다.

p5. 그냥 사소한 의견입니다 (Approve)

p5의 경우 사소한 생각들과 코드에 대한 감탄 등을 코드 리뷰에 반영했다.

뱅크 샐러드의 코드 리뷰 방식으로 진행하며 코드에 대한 확실한 근거들과 생각들을 p로 구분지어 동료에게 전달할 수 있는 방식이 마음에 들었고 무엇보다 코드에 문제가 있다고 생각되는 부분과 사소한 문제의 코드를 완벽히 분리할 수 있었던 점이 가장 좋았던 거 같다. 아마 다음 프로젝트를 진행해도 해당 방식의 코드 리뷰를 유지할 거 같다.

🔥 다양한 기술 스택 적용

이번 프로젝트의 기술 스택은 협의 된 부분이 있지만 스스로 공부하며 사용하고 싶었던 기술들을 사용할 수 있었던 점이 좋았다. 이번 프로젝트를 진행하며 새롭게 적용했던 기술들은 다음과 같다.

Yarn Berry

기존 프로젝트에선 npm, yarn을 주로 사용했었는데, 프로젝트 세팅기간이 꽤 길었어서 Yarn에서 Yarn berry로의 마이그레이션을 제안했다.

Yarn berry를 사용하며 많은 장점들이 존재하겠지만 가장 좋았던 점은 디스크 용량 감소 였다. node_modules를 사용할 경우 3.2기가(최적화를 통해 용량을 더 줄일 예정이다.)정도 차지하였지만 Yarn berry를 사용함으로써 절반이 넘는 디스크 용량을 줄일 수 있었다.

또한, 정확한 속도 측정은 어려웠겠지만 기존 Yarn 보다 install 속도가 확연히 차이 났던거 같다. 그 밖에 ci/cd 시간 단축 및 zero-install의 장점들이 존재하지만 이번 프로젝트에서 그 차이를 비교하기가 어려워 패스하겠다.

Storybook

Storybook을 이번 프로젝트에서 좀 더 제대로 써보려고 노력했다. 그 전에는 Storybook을 컴포넌트 기능, UI 모습에 대한 문서화 정도로 사용했었는데, 이번 프로젝트에선 제대로 사용해보려고 노력했다.

컴포넌트의 다양한 상태들에 대해 여러 스토리로 나눠 상황에 따른 컴포넌트 변화에 대해 스토리북으로 관찰하려고 했으며, Controls를 적극 활용하여 다양한 값에 따른 다양한 컴포넌트를 확인할 수 있었다.

무엇보다 독립된 환경에서 컴포넌트 개발을 할 수 있었기에 로컬에서 굳이 테스트를 하지 않고 스토리북으로 확인이 가능했고, 그 점이 코드 리뷰 할 때에도 굳이 로컬에서 코드 쳐가며 확인하는 것 보다 편하게 느껴졌다.

React Query

리액트 쿼리를 주로 CSR 환경에서 사용했었는데, 이번 프로젝트를 통해 리액트 쿼리를 SSR 환경에서 사용해볼 수 있었다.

export const getServerSideProps: GetServerSideProps = async () => {
  const queryClient = new QueryClient()
  await Promise.all([
    queryClient.prefetchQuery(
      [...performanceKeys.all, '', '', '', '', '', 0, 6],
      () =>
        getAllPerformance({
          pageNumber: 0,
          pageSize: 6,
        }),
    ),
    queryClient.prefetchQuery(mainKeys.comment, getLatestReviews),
    queryClient.prefetchQuery(mainKeys.profile, getProfile),
  ])
  return {
    props: {
      dehydratedState: dehydrate(queryClient),
    },
  }
}

프로젝트 코드 중 일부인데, 서버 사이드 환경(getServerSideProps)에서 해당 쿼리 키의 값을 prefetch 후, queryClient를 dehydrate 하여 page props에 dehydratedState로 내려주면 브라우저에서 자바스크립트를 사용하지 않아도 자동으로 패칭하는 것을 확인할 수 있었다.

🙇‍♀️ Longed For (앞으로 바라는 점)

디자이너 팀

프로토 타이핑

이것도 지극히 개인적인 생각이지만, 피그마에 "프로토타입 기능을 통해 ui의 flow를 확인할 수 있었으면 어땠을까" 라는 아쉬움이 있었다. 프론트 팀에선 항상 flow 확인을 위해 ui를 만들고 디자이너 팀에게 슬랙으로 여쭤본 후 답변을 듣는 방식이었는데, 항상 답변을 기다려야하는 입장이다보니 ui 구현 까지의 시간이 오래걸렸다고 생각했다.

하지만 디자이너 팀 분들도 최종 발표 PPT 준비 + 디자인 수정 등 바쁜 일정을 소화하고 계셨어서 따로 말씀은 드리지 못했다. 그래서 바라는 점에 추가하게 되었다.

백엔드 팀

Swagger

Swagger 문서 내 Request body에 다음과 같이 명시되어 있어 슬랙에 정확한 데이터 형식에 대해 몇 번 질문한 적이 있었다. 개인적인 생각이지만, Swagger에 정확한 데이터 형식이 명시 되어있었다면 서로 효율적으로 일할 수 있을 거 같았다는 생각이 들었다.

물론, 백엔드 팀도 다른 작업이 많았을 것이기에 신경쓰지 못했을 수도 있고, 미리 Swagger에 정확한 데이터 형식에 맞게 json 형식을 구성해달라는 부탁을 못했던 내 잘못도 존재했다. 그렇기에 바라는 점에 추가하게 되었다.

끝으로

공식 적인 DND 8기 활동이 모두 마무리 되었다. 하지만 아직 프론트엔드 팀은 Readme, 회고 작성, Release note & github wiki 작성, 코드 리팩토링, 모바일 반응형 작업, og 태그 적용 등 아직 해야할 일이 많이 남아있기에 당분간은 1조의 프론트엔드 팀 활동은 지속될 예정이다.

첫 사이드 프로젝트여서 부족한 점도 많았고, 서툰 점도 많았지만 DND 운영진 분들의 가이드, 1조 분들의 너그러운 이해로 무사히 마칠 수 있었던 거 같다. 다시 한번 1조 분들과 DND 운영진 분, 우리팀 멘토 다영님에게 감사드리고 싶다. 🫶