1차 커피챗

MAU & DAU

• MAU: 월간 사용자 횟수.

• DAU: 일간 사용자 횟수.

인원이 많아서 의사 결정이 어려움

• 회사도 마찬가지로 어려움을 겪음. 그래서 보통 결정권자 리더가 존재함.
• Disagree & Commit

• 회사마다 원칙을 세우기도 함.
• ex) 이미 결정된 사안이라면, 이후에 마음에 들지 않더라도 번복하지 않는다.
• ex) AB 테스트를 진행해보기도 함.
• 특정 기간을 정해놓고, A행동도 해보고, B행동도 해보는 것. 그 이후에 결과 데이터에 기반해서 처리.
• 예시로, 쿠팡 팝업에 이상한 팝업이 많은데, AB테스트를 엄청 많이 하는 예시임..
• 멜론 해지를 들어가면 쿠폰을 주는 것도 그 것의 예시임.

• Time Keeper 역할을 두는 것도 좋음.
• 회의 시작 전 아젠다를 정해 놓고, 정해진 시간안에 결정이 되지 않으면 그냥 가위바위보로 결정하든 나중에 추가 논의 회의 일정을 잡든 해서 넘어감.

이력서에 어필할 챌린지 요소를 떠올리기 어려움

• 우선, 팀원 각각이 프로젝트를 통해 얻으려는 목적이나, 목표를 논의하고 맞춰야 함.

• 예전에는 이력서에 프로젝트가 꽤 어필이 되었는데, 최근에는 생각보다 프로젝트의 임팩트가 안 들어옴..

• 이제는 단순히 취업을 위해서 프로젝트를 한다기 보다, 프로젝트를 얼마나 재미있게 하고 뭔갈 배우는 과정이 더 중요할 수 있음.

PWA도 챌린지 요소로 어필 할만 한 포인트일지?

• PWA 자체가 이력서에서 큰 임팩트가 될 것 같진 않음.

• 다만, 공부하는 과정에서 배우거나 얻어갈 건 분명히 많을 것이고, 흔하지 않은 내용이기도 함.
• ex) Service Worker에 대해서도 알게 될 것임.

• 테스트 과정에서 안드로이드 폰이 필요할텐데, 팀원 모두가 안드로이드 폰이 아니면 좀 어려울수도.

• 가장 좋은 건 단순히 기술이 유행한다고 해서 선택하기보다는, 그 기술을 도입했을 때 우리 프로젝트에서 해결하려는 문제가 명확하게 해결되는 경우가 베스트 시나리오.

Next.js 도입했을 때 에러를 만났을 때 프로젝트 완성도가 떨어질 것 같은 걱정

• 실력적인 부분이 중요한데, 실력이 아직 부족한 팀원이 있으면 그 사람은 희생 당할 가능성이 높음.
• ex) 누구는 앞서 나가고 싶은데, 누구는 따라가기 벅차다면 Next.js 공식 문서만 읽다가 정작 개발 경험은 많이 못할 수도.
• Next.js 썼을 때 BFF가 생겨서 사실 FE 개발자가 관리해야 할 WAS가 추가되는 느낌인데, 이걸 관리하고 배포하는 등 파이프 라인을 전담할 수 있는 사람이 있어야 함. 즉, 서버 지식을 아는 사람이 필요함.
• 간단하게 S3 + Cloundfront 로 끝나냐, 아니면 EC2 인스턴스를 생성해서 인프라를 관리하냐 등등.. 선택지는 다양함.
• 이런 부분은 FE 개발자에게도 충분히 배울 가치가 있는 내용이지만, 만약 당장 FE 앞단을 구현하는 것만으로도 벅찬 상황이라면 어려울 수 있음.
• Next.js 에서 export 하면 기본적으로 SSG가 됨. (이 내용이 아직 어렵다면 Next.js 사용하면 안됨!!)
• 네이버 페이지 → F12 개발자 도구 → Network → Doc → Preview

일반 React 만으로도 SEO가 가능한지?

• Next.js 만큼의 SEO 성능을 보여주기엔 부족함.

• SEO 최적화를 한다고 해도 실제 트래픽이 있어야 해서 당장 적용해보기에 어려울 것임.

• 다만, Open Graph 정도는 당장 시도해볼 수 있음.

Drag & Drop, Swipe 등의 인터랙션을 라이브러리 없이 구현하는 경험이 도움될지?

• 욕심나면 하면 좋음. 실제로 멋있게 구현하는 사람도 있음.

• 다만 일정에 지장을 줄 수 있는 경우 팀원과의 협의가 필요함.

• 해보면 재밌는 과제가 되긴 할 것임.. npm 패키지로 직접 만들어 본다거나..

UI 및 스타일링 관련 라이브러리 선택

• 팀원의 숙련도가 가장 중요함. 만약 어떤 기술에 욕심이 나서 도입해 보려는데 모두가 새롭게 느끼는 기술이라면 개발이 진도가 안나갈 수 있음.
• ex) MUI도 학습 비용이 들음.

• 우선 큰 갈래로 나누고 결정하면 편할 것.
• 디자인 요소가 포함된 Framework(MUI, Bootstrap) VS 미포함된 Framework(emotion, styled-components) 등
• CSS(Sass) vs CSS-in-JS(emotion, styled-components, panda-css)
• 컴포넌트 제공(Chakra, radix) VS 컴포넌트 미제공

• 그런데 이 부분은 Next.js를 쓰냐 안쓰냐에 따라서도 달라질 것임. 몇몇은 못쓰게 될 수 있음.

• Chakra-ui 보다는 radix-ui 추천.

상태 관리 도구가 필요할지?

• 요새는 Super App 이어서 상태 관리 라이브러리를 안쓰는 서비스도 꽤 있긴 함.

• Tanstack-Query는 상태관리 라이브러리는 아니고, GraphQL, Apollo Client랑 비교해야 할 라이브러리임.

• redux는 이제 사용할 필요 없음. rtk를 쓰면 됨.

• rtk는 zustand와 같은 계열이고, recoil은 jotai와 같은 계열임.

eslint, prettier 등 컨벤션 정하는 방법

• eslint, prettier, vscode 설정까지 맞추는 걸 추천.

• PR하면서 맞출 수도 있고, 사실 어느 정도 시간이 들어가는 작업이긴 함.

• 그래도 시간을 쏟아서 우리가 결정하고 기계가 알아서 작동하게 끔 해주는 게 좋음.