팀에는 백엔드가 4명, 나 혼자 프론트엔드일 때 어떻게 해야 프론트엔드에 대해서 협업을 할 수 있을까?

• 구현을 어떻게 하면 팀원들이 빠르게 파악을 하고 프론트엔드 파트에 대해서 의견을 낼 수 있을까?
• 내가 할 수 있는 가장 좋은 방법은? → 문서화를 잘 하는 것
• 지난 FE 3,4주차 학습 스프린트 때 윤해수 멘토님께 추천 받았던 tsdoc을 비롯해 스토리북을 잘 적용해보자
• 컴포넌트, 함수에 대해서 확실하게 문서화를 해나간다면? → 백엔드 팀원이 그 문서화 된 부분만을 보고도 컴포넌트를 조합해 기능을 만든다거나, 구현을 하는 과정에서 4명의 팀원들에게 내가 없더라도 문서만 보고 이해를 할 수 있을 것이라고 생각
• 실제로 현업에서도 이러한 문서를 바탕으로 내가 근무 하기 이전의 분들이 작업한 내용에 대해서 인수인계를 받고, 내용을 찾아보며 개발을 하기 때문에 이 과정을 디테일 하게 잡아가는 게 도움이 될 거라고 생각

프론트엔드가 나 혼자인데 누구한테 코드 리뷰를 받지?

• 물론 팀원분들에게 코드의 가독성, 구조에 대한 부분은 받을 수 있지만, 저희 팀의 경우에 리액트를 써보신 분이 없다는 문제 점이 있습니다. 이 부분에 대해서 고민이 되게 많았고, 이전에 프론트엔드 학습 스프린트 때 같이 했던 분들과도 의견을 많이 나눴습니다.
• 제 생각으로는 저랑 비슷한 고민을 하고 계신 분들이 많을거라고 생각을 했고, 일종의 품앗이 형태로 의견을 받아볼 수 있으면 좋을 거 같다고 생각을 했습니다.
• 그래서 이걸 토대로 이번 주에 마클을 들으면서, 관련해서 크롱님께 질문을 남겼고 괜찮을 거 같다는 의견을 주셔서 “코드리뷰품앗이연대” 채널을 파봤습니다. 아마 피어세션 같이 하시는 분들도 몇 분 계시는 걸로 아는데 의견이나 말씀 많이 나눠보고 싶습니다 ㅎㅎ
• 사실 이것 외에도 몇 가지 방법을 고민을 해봤는데요, 다음과 같은 방법 정도가 있다고 생각을 합니다.
  1. SonarLint나 SonarQube 적용하기
  2. GPT와 같은 도구를 활용하여 코드에 대해서 셀프 리뷰할 수 있도록 하기
  3. 깃허브 코파일럿 리뷰 기능을 응용하기
  4. 리뷰에 대한 기준을 세워두고 스스로 체크리스트를 채워보기
  5. 팀원에게 리액트에 대한 지식을 밀어넣어서 리뷰를 통해서 빠르게 경험을 쌓을 수 있도록 하기

팀원들과 같은 이해와 생각을 할 수 있도록 노력하기

• 네이버 부스트캠프 이전에도 다른 대외활동이나 교내 강의를 통해서 프로젝트를 진행했었습니다. 항상 프로젝트를 진행 할 때 마다 어려웠던 점이 있다면 모두가 같은 생각이나 이해도를 가질 수 있도록 하는 것이지 않나 싶습니다.

• 이것도 어떻게 보면 위의 방식과 같은 해결 방법이지만, 결국 잘 기록해두고 잘 정리해두는 게 가장 좋은 방법이 아닐까 생각을 했습니다.

• 팀에서 그렇다면 제가 가장 잘할 수 있는게 기록이라고 생각을 했고, 이번 팀원 분들과도 회의를 진행하거나, 이야기를 나눌 때 꼭 노션에 기록을 할 수 있도록 하고 있습니다. 많은 내용을 담아둬야 프로젝트를 하면서도, 끝나고도 돌아볼 수 있을 거라고 생각을 했습니다.

• 그리고 특히 기획에 관한 부분에 대해서는 확실히 같은 기능을 상상하고 있어야 된다고 생각을 했습니다. 저희가 인터미션 때 기획에 대해서 아이디어 레벨 정도만 내고 이번 주에 처음 진행한 회의에서 구체적인 기능과 컨셉을 구상 해봤었습니다. 이걸 할 때 제 생각엔 결국 UI로 표현이 되야 확실하게 이해가 올라갈 거라고 생각을 해서 회의를 진행하기 전에 아래 그림과 같이 제가 생각한 의견을 확실하게 적어가려 했습니다.

  

• 이런 식으로 그림을 먼저 제안을 드린 덕분인 지 다른 팀원 분들도 제가 낸 의견을 수정하거나 피드백을 활발하게 나누면서 다같이 보드 앞에 서서 전체적인 기획과 아이디어를 확실하게 잡아나갈 수 있었던 것 같습니다.

  

• 이런 기록과 제안이 팀원분들께도 충분히 도움이 되었는 지, 그 이후에 항상 기록을 만들고 작성하는 과정에서는 다들 적극적으로 참여를 해주셔서 뿌듯했던 것 같습니다. 이런 부분이 가장 잘 나왔던 게 에픽-스토리-태스크를 작성하는 부분이라고 생각을 합니다.

  0순위 스토리 태스크 정리 링크를 들어가보시면 저희가 이번 캠프 기간 동안 할 수 있지 않을까를 기준으로 1순위를 매겼고, 그 내용들에 대해서 스토리와 태스크를 분리해내고 구체적으로 작성을 해본 내용입니다. 다 같이 큰 모니터에 전체 스토리, 태스크를 적어두고 하나씩 읽어나가면서 스토리는 적합한 지, 백엔드와 프론트엔드에서 작업을 하는 것을 고려했을 때 어떤 태스크가 필요한 지를 정리해나가면서 깃허브 프로젝트에 동기화 작업 까지 잘 마무리 할 수 있었습니다.

  이런 내용을 바탕으로 목요일에도 현실적으로 개발 기간을 4주라고 보고, 위에서 작성한 태스크를 어떤 기준으로 주차 단위에서 개발을 할 지에 대해서 애자일 하게 접근을 해봤고, 모두가 같은 목표와 이해를 가지고 개발 기간으로 돌입할 수 있게 된 것 같습니다.

이번 프로젝트 동안 프론트엔드 개발자로 성장하려면 나는 뭘 해야 될까?

• 스프린트를 하면서도 여전히 많이 부족 하구나를 느꼈던 것 같습니다. 단순히 리액트를 사용하는 것에 그치지 않고 사용하는 이유와 방식에 대해서 확실하게 이해도를 올리는 과정이 필요하다고 생각이 많이 들었던 것 같습니다.
• 백엔드가 4분이 있는 팀에서 그렇다면 제가 프론트엔드 개발자로 성장하려면 뭘 할 수 있을 지 생각을 많이 해봤던 것 같습니다.
• 위에서도 나왔던 이야기와 겹치는 내용이지만, 먼저 구현을 하는 과정에 대해서 확실하게 이해를 하고 그걸 문서화를 잘 하는 것입니다. 이번 프로젝트를 하면서 해보고 싶은 것이 custom hook을 잘 만드는 것, 리액트 내부 상태관리를 응용해서 최대한 외부 라이브러리에 의존 없이 먼저 개발 해보는 것입니다. custom hook의 경우에 가장 먼저 생각나는 것이 세션 스토리지를 잘 사용할 수 있도록 해주는 것 그리고 퀴즈 생성/퀴즈존 진행을 위한 퍼널에 대한 custom hook 인것 같습니다.
• 실제로 개발에 들어가봐야 알겠지만, 백엔드 4분도 프론트엔드 개발에 참여하고 싶다는 의견을 내비쳐 주셨기 때문에 그걸 좀 더 잘 함께 하려면 제가 custom hook을 만들었을 때 리액트를 처음 써보는 4분이 잘 쓸 수 있도록 하는게 도움이 될 거라고 생각합니다. 마치 저희가 스프린트 때 프레임워크를 사용하는 것이 얼마나 편한 지 이해할 수 있었던 것 처럼요.
• 그래서 tsdoc과 같은 도구를 응용해서 그런 부분을 최대한 잘 녹여내려고 노력할 거고 거기에 당연히 코드도 잘 짜야겠죠?
• 그리고 글을 많이 써보려고 합니다. 이걸 하려고 하는 이유는 제가 잘 이해를 했다는 반증은 결국 다른 사람도 쉽게 이해를 할 수 있도록 돕는 것이라고 생각을 해서 입니다. 그래서 글을 많이 쓰는 게 목표이고 이걸 팀원 분들과 함께 하기 위해서 개발 위키를 파서 회의 중에 혹은 저희끼리 얘기하다 나오는 주제들에 대해서 키워드든 질문이든 기록하고 이걸 이해할 수 있도록 글로 적어보려고 합니다. 그리고 개발 과정에서 학습 하는 내용들에 대해서도 왜 사용을 했는지에 대해서 확실하게 기록으로 남겨 보려고 합니다.
• 그리고 이런 내용의 연장선으로 일단 프론트엔드에 관련된 기술 스펙이나 방식, 라이브러리 등을 저를 기준으로 결정하게 될 것 같아, 그 과정에 대한 부분도 깃허브 위키에 확실하게 적어보려고 합니다. 당장에 생각하는 것 만 적어봐도 정말 많아서, 팀원분들이 이건 왜 사용한 거죠? 라고 질문을 던져 주셨을 때 그 문서만 읽어도 이런 이유로 선택했구나를 확실하게 파악하실 수 있으면 좋겠습니다.
  • 정해야 되는거
    • react vs next.js → react 사용 예정
    • tailwind css vs styled-components vs … → tailwind css + shadcn ui 사용예정
    • cra vs vite vs … → vite 사용예정 → vitest의 병렬 테스트를 써보기 위해서