1. 팀소개(?) + 팀 목표
2. 서비스 소개(머-쓱레터)
   1. 기획 배경
   2. 주요 타켓층
   3. 디자인
3. 깃 브랜치 전략
4. 기술 스택 + 중요한 기술은 사용한 이유 말하기(?)
   1. typescript
   2. react, axios
   3. react-query
   4. react-hook-form
   5. chakra UI
   6. contextAPI
   7. eslint, prettier, husky
   8. express
5. 페이지별 기능 소개
   1. 회원가입
   2. 로그인, 로그아웃, 비밀번호 변경
   3. 검색
      1. 사용자 이름 기준 검색
   4. 마이페이지
      1. 사용자의 머쓱이 한눈에 보기
      2. 프로필 이미지, 자기소개 변경
   5. 머쓱이 생성
      1. 머쓱이 테마 선택
      2. 머쓱이 이름, 소개 작성
   6. 머쓱이 상세페이지 + 편지 보기 모달 1.
   7. 슬랙 알림 인증
6. 시연
7. 앞으로 나아갈 방향

발표의 흐름

1. 팀 소개 및 팀과 개인의 목표
   • 팀의 목표: 실제 사용자가 존재하며 피드백을 받는 경험이 가능하고, 의견 충돌을 눈치 보지 않고 협업하는 방법을 배우며 성장하기
   • 개인의 목표: tanstack-query, chakra-ui 등 새로운 기술의 학습을 하고 잘 활용해보기
2. 서비스 소개
   1. 기획 배경: 평소에 다른 교육생에게 고마운 마음을 부끄러워서 잘 표현하지 못했거나, 피어 리뷰에서 못다한 말이 있는 경우를 발견했음
   2. 주요 타겟층: 데브코스 교육생
3. 주요 기능
   1. 머쓱이 만들기
   2. 머쓱이에 편지 쓰기
   3. 슬랙 DM 연동
4. 협업 방식
   • Jira를 사용하려고 했으나, 프로그래머스 레포지토리에서는 사용하지 못했던 문제로 Github Project를 사용했음.
   • Pull Request 시 반드시 한명의 Approve를 받아야만 Merge가 가능하도록 해서 서로의 코드를 리뷰하며 버그와 같은 문제점을 초기에 예방할 수 있었음.
   • Eslint, Prettier, Husky 를 적용해서 서로의 코딩 컨벤션을 유지할 수 있게끔 했음.
5. 깃 브랜치
   • 처음에는 main, develop, feature 등의 브랜치를 만들었으나 현재 빠르게 작업을 머지하고 확인해야 하는 우리 상황에서는 브랜치 단계가 깊지 않아도 될 것으로 판단했음. 그래서 main, feature, hotfix 브랜치만 놓는 전략을 택함.
6. 기술 스택 (Max: 3분)
   • Tanstack-Query: API 요청을 적극 활용하는 프로젝트인만큼, 서버 상태를 관리해주는 라이브러리를 도입하게 되었음. 실제로 도입해보니 중복된 네트워크 요청을 한 번만 처리한다거나, 쿼리 키와 매핑되는 데이터를 적절하게 캐싱하는 작업을 해주기에 우리는 단순히 선언적으로 서버 상태를 가져와서 사용할 수 있어서 편했음. 또한 서버 상태를 잘 다뤄주다보니 클라이언트에서 따로 공유해야 할 상태 관리 도구는 사용하지 않아도 될 정도였고 로딩과 에러 상태를 선언적으로 관리하기 위해서 Suspense를 도입했는데 처음 사용해보는 방식이라 생소했지만 익숙해지니 컴포넌트 내부에는 반드시 데이터가 있는 상황에 해당하는 로직만 들어있어서 보기에 편리했음.
   • react-hook-form: 폼 데이터와 유효성 검증 상태를 손쉽게 관리할 수 있었으며, 기본적으로 비제어 컴포넌트로 동작하기 때문에 폼의 값이 변화해도 리렌더링이 발생하지 않아서 효율적이라는 생각을 하게 되었음. 또한 zod와 같은 유효성 검사 라이브러리와의 결합도 손쉬운 편이라고 사용하기에 좋았음.
   • chakra-ui:
7. 개발하면서 생겼던 이슈
   • 슬랙 연동 ( Max: 2분)
     • 간단한 API 백엔드 서버가 필요했음. (Express)
       • 슬랙 API의 토큰을 안전하게 숨겨야하기 때문에 슬랙의 처리를 담당해주는 백엔드 서버가 필요했었음.
       • 머쓱레터 가입자가 연동하려는 슬랙 계정이 정말로 본인 계정인지를 확인하는 flow가 필요하다고 판단하여 백엔드 서버가 필요했었음.
       • Serverless로 구현할지, Express로 구현할지 고민했었는데 우리 팀에서 가장 익숙한 기술스택인 Express로 구현하기로 결정했음.
     • 멀티 레포로 구성된 프로젝트를 하나의 레포지토리로 합칠 필요성이 있었음. (yarn berry + yarn workspace)
       • 우선 MVP 기능을 빠르게 구현하기 위해서 새로운 레포에서 Express 로 코드를 작성하였으나, 프로그래머스 레포지토리에서 함께하는 과정이기 때문에 모노레포의 형태로 마이그레이션하는 것이 좋겠다고 판단했음. 그래서 기존에 npm으로 작업하던 것을 yarn berry + yarn workspace로 마이그레이션하였음.
   • 잦은 PR의 중요성
     • 5일 분량의 방대하고 복잡한 코드를 한번에 리뷰해야 했던 적이 있었는데, 리뷰해야 할 부분도 많고 수정 사항을 반영해야 하는 부분도 많아서 리뷰어와 리뷰이 모두가 어려워졌던 상황을 경험했었음. 그래서 잦은 PR의 중요성을 느끼게 되었고, 그 당시에는 코드 리뷰 로만으로는 해결이 어렵다고 판단해 live share라는 도구로 페어 프로그래밍을 하는 방식으로 서로간의 sync를 맞췄음.
8. 시연 영상
9. 앞으로 나아갈 방향
   • 프로그래머스 내에서 지속 가능한 서비스로 유지되길 희망하므로, API 서버가 닫혀도 사용할 수 있도록 백엔드 로직을 추가 작업해야 함.(현재 모노레포로 구성되어 있는 상황이라 비교적 수월하게 작업할 것으로 예상)
   • 현재 슬랙 연동을 프론트엔드 슬랙만 지원하기 때문에 백엔드 슬랙으로도 확장할 수 있다면 좋음.