커피챗 05회차

멘토님 Q. 프로젝트 진행은 누구와?

• 2차팀끼리

• API는 데브코스에서

• 작업은 프론트엔드만

멘토님 Q. 팀의 특별한 기능?

• “기술적인 challenge” vs “기능 차별화”? 컨셉은 정해졌는가?
• 안 정하고 넘어갔다.

• 멘토님: 포트폴리오에 녹일 만하게 가져가려면 톡톡 튀는 프로젝트를 하면 좋은 경험이 되지 않을까? 기술이 아무리 좋아도 유저 0명이면 임팩트가 있나? 생각이 든다.

• 최종 프로젝트를 위한 발판으로 쓰려면 그것도 괜찮겠다는 생각이 든다.

멘토님 Q. 프로젝트 평가 보상이 있는가?

• 없다.

재훈 아이디어: ‘내 트리를 꾸며줘’와 유사하게 ‘새해 다짐’을 분기/반기 remind 푸시 알람을 띄워줄 수 있는 웹앱 + 같은 새해 다짐을 가진 커뮤니티 SNS

• 멘토님: 새해와 관련된 서비스인데 웹 푸시 기능이 탑재된 커뮤니티 서비스네요

• 재훈: 프론트를 예쁘게 잘 꾸미면 유저를 잘 모을 수 있겠다는 생각이 들었다.

• 멘토: 기획적으로 재밌는 아이디어 같다.

멘토님 Q. 기술적 challenge로 컨셉을 잡는다면 어떤 기술을 써보려고 했는가?

• 재준: 리액트 숙련도를 올리는 걸 생각

• 재훈: 디자인 시스템, headless 컴포넌트 라이브러리
• 멘토님: 폼이 많이 들어갈 것 같지만 간단한 토큰 정도로 구성해도 괜찮지 않을까

• 재민: tanstack-query를 직접 구현하기, 로그인 깊게 파보기, 정 할 게 없다면 디자인 시스템

멘토님 Q. 요구 사항은 있는가?

• 아직 안 나왔다.

• 재준:
• 4기 팀은 포폴보단 숙련도 향상 위주로 목표를 잡았다.
• 아직 방향성은 못 정해서, git/개발 컨벤션 정하고 있었다.

• 멘토님: git/개발 컨벤션은 어디까지 정했는가?
• 재훈: merge 전략 못 정했는데 당근에선 어떻게 하는지?
• 멘토님: monorepo 상에서 main 브랜치에 커밋하면 (알파/정식) 배포됨
• main 브랜치를 trunk로, feature 브랜치를 JIRA 티켓으로 이름 지어서 작업하고 알파 배포 나갈 때 main에 병합한다.
• 재훈: squash로 history 정리를 하는가?
• 멘토님: 대부분 dev에서 feature를 따는데, git commit이 전부 반영되면 dev, main에서 history를 보기 좋지 않다. dev에 병합할 때 squash해서 병합되고, main에 병합할 때는 merge commit을 둔다. 그렇게 linear하고 깔끔하게 관리한다.
• 재훈: rebase는 안 쓰시는지?
• 멘토님: 나보다 이후의 변경사항이 먼저 dev, main에 반영된 경우 - 충돌 해소를 하기 위해 내 feature 브랜치를 rebase해서 최신화, 충돌 해소하고 dev에 squash 병합한다. merge 전략으로써 rebase를 잘 활용한 경우는 별로 없었다. 아마 rebase merge보단 rebase를 많이 활용하지 않을까 싶다.
• 재훈: squash 때문에 이전 기록을 보기 어려웠던 적은 없었나?
• 멘토님: 그런 적도 있다. feature가 병합되고 문제가 발생했는데, squash된 commit들이 있으니 어떤 변경에서 문제가 발생했는지 확인이 어렵다.
• 재훈: feat→dev는 merge, dev→main은 squash를 하는 방법은 어떻나?
• 멘토님: commit history가 있으니 문제를 찾는데 도움은 되겠지만 dev가 지저분해질 듯. dev를 squash해서 main에 병합하려면 결국은 dev를 특정 단위만큼 잘라서 squash해야 하는데 그런 관리가 필요하다. 실제로 해보진 않아서 얼마나 좋을지는 모르겠다.

멘토님: 이제 좀 정리해볼까요?

머지 전략

• dev, main을 나눠서 운영한 경험이 많지 않으면 main 하나로 운영해보는 것도 좋다고 생각한다.
• 이를 Trunk based development라고 한다.
• 안해봤으면 경험삼아 해보면 좋다.
• 실무에서도 이렇게 쓰고 있다.
• https://trunkbaseddevelopment.com/
• 재훈 Q. TDD를 쓰면 배포가 쉬워지는 장점이 있는 건가요?
• 멘토님 A.
• dev의 알파 배포 과정을 제거하면 같은 코드인데 브랜치가 2개이기 때문에 생기는 자잘한 문제가 있다. 어차피 같은 코드이기 때문에 브랜치는 하나만 써도 충분하다.
• main만 있으면 충돌이 잦아지는데, 이를 역이용해서 빠르게 feature를 쳐내야 해결할 충돌이 없거나 적으므로 빠르게 개발하게 되는 요인이 된다. 숙달되면 충돌 해결은 큰 문제가 되진 않는다.

• 멘토님 A.
• 디자이너가 없으니 최상의 UI UX를 고민해줄 사람이 없다. B급 감성을 역이용해보면 좋지 않을까 생각이 들기도 하다. 약간 허접한 느낌으로 풀어낸다거나.
• 백엔드가 없는 건 한계가 있을 수 있다. 이 부분은 고민이 되는데 하기 나름이다. 재밌는 아이디어가 떠오르다면 어떻게든 하는 방법도 있지만 그만한 기획이 없다 싶으면 기술적인 쪽으로 하는 게 좋겠다고 생각한다.
• 한 번 기획적으로 고민을 많이 해보시고 다른 리소스가 필요하다고 생각하면 요청하시면 도움 드리겠습니다.
• 재훈: 완전 간단한 거라도 유저를 맛보고 싶다.
• 멘토님: 허접해도 킬링 피처 하나 있으면 유저는 쓴다. 물론 그걸 생각해내는 건 조금 어렵다.

개발 컨벤션 리뷰 시작

• import문 4개 제한?
• 성빈 A. import 얘기하다가 나온 건데 함수 길이, indent 제한 같은 맥락에서 캡슐화를 의도하기 위한 컨벤션으로 얘기했다.
• 멘토님 A.
• 의도는 좋은 것 같다. 개수는 해보면서 찾아봐야 할 것 같다. 함수 라인, indent 제한도 좋은 것 같다.
• 개수는 진행하면서 찾아보는 게 좋겠다.

• types 폴더 분리?
• 멘토님 A.
• 성빈=타입 코로케이션 주장
• 좋다고 생각한다. 꼭 별도의 파일로 분리해야 되는 건 아니다. 필요하면 공통화시킬 수 있다고 생각한다.
• 가끔 새로운 module을 정의해야 할 때가 있는데, 어디에 두기 애매한 경우 index.d.ts 내에 다 정의해서 쓸 수 있다.
• API 타입을 어떻게 관리할 것인가?
• api response type을 어떻게 관리할 것인가 보다는…
• typing을 안 할 수 있는 방법에 대한 고민을 해보면 좋지 않을까?
• 재훈 Q. 멘토님 회사에서는?
• Open API 스펙의 codegen으로 Request, Response Type을 자동 생성할 수 있다.
• 요즘은 아예 Open API TypeScript 같은 것도 있다.
• GraphQL을 쓰면 GraphQL Schema가 Open API Spec 이어서 TypeScript codegen해서 type을 만들 수 있다.
• 회사에서는 API Type에 대한 고민은 일체하지 않아도 된다.
• 우리 프로젝트에서는 그것을 할 수 있냐?
• 공개된 API의 Open API Spec이 있다면 Type을 가져오기만 하면 되고, 아니면 일일이 타이핑 해줘야 한다.
• 없으면 제공해달라고 요청해도 좋을 것 같다.
• 재민 Q. 타입이 길어져서 가독성이 떨어져도 같은 파일에 두는 게 좋은가?
• 멘토님 A.
• 길든 짧든 코로케이션 하는 게 좋지 않나 생각한다.
• 그 파일을 참조하는 파일이 여러 군데에 있으면 공통에 빼두는 것도 가능할 것 같다.

• mapping list key 컨벤션
• 멘토님: React key를 자동으로 만들어주는 기능이 있다는 것 알고 계신가요

• barrel export
• 재민 A. 예전엔 index.ts를 쓸 때는 export * 를 썼었는데 성능 문제가 있다고 해서 쓰지 말지 고민을 하게 됨
• 멘토님 A. index 파일이 있어도 barrel로 쓸 수도 아닐 수도 있다.
• 그럼 index 파일에 barrel로 안 쓰면 괜찮지 않나
• barrel 파일에 대한 고민은 크게 안 해도 되지 않을까