TODO
- 기술 스택 분류 보고 각자 의견, 경험 정리해오기
- 멘토님께 여쭤볼 것
- PR에 배운 점, 어려웠던 점, 느낀 점, 고민한 점, 결정한 점 적기
팀 문화
논의
성빈)
- 방향 설정 시에 논의-결정 라운드 분리하기
- 논의 사항은 동시에 작성하고,
- 기술 논의 예시
- 얘기는 순서대로 하고,
- 라운드에서 결정이 안 되면 1, 2번 더 라운드 진행 후 결정
- 기술 공유하기
- 사용법, 동작 원리 같은 거 공부하고 공유하기
- 기술 블로그 써보기
- 결정 사항 논리 과정 (논의 과정),
- 하면서 느낀 점, 배운 점
호민)
- 10시~12시 엑스트라 코어타임
- 오후에 강제성 부여 차원에서 하면 좋을 것 같다.
- 정보 공유, 잡담 스레드에서 대화
- 슬랙 워크플로우로 셀프 일정 트래킹
- DailyBot 같은 거네용?
- 데일리 스크럼 체계화
- 형식적인 스크럼에서 벗어나서
- 매일 했던 일을 쭉 적는 것은 어떨까?
- 개발 일기
- 성빈 추가) 판단해야 하는 것들이 있으면 적어 보는 것 좋을 듯?
- PR에 배운 점, 어려웠던 점, 느낀 점, 고민한 점, 결정한 점 적기?
- e.g. 컴포넌트 분리 1안, 2안이 있는데 고민 중
진아)
- 15분 이상 자리 비울 때는 알려준다.
- 캘린더에 Todolist checklist로 공유한다.
- 후반에 잘 안지켜졌지만 할 일을 정리할 수 있어서 좋았다.
- 적는 것 동의한다.
희라)
- 호민님 의견에 동의
- 알림 키지 않은 사람들을 위해 멘션을 한다.
- 저녁 코어타임한다.
- 적는 것 동의한다.
의견
호민)
- 호
- 라운드 분리
- 기술 공유하기
- 기술 블로그 쓰기 (공유 내용 쓰기)
- 어떤 결정을 했고
- 어떤 문제가 있어서 해결했고 등
- 10-12시 추가 코어타임
- 있으면 좋겠다
- 개인적으로는 8시-12시
- 추가) 개인 작업할 때는 디코에 있으면 좋을 듯
- PR에 추가로 내용을 적는 것 좋은 듯
- 상태 파악에 유리할 듯
- Checklist 한다면 스크럼 얘기와 연동하면 좋을 듯
- 개발 일기 페이지가 있다면 거기에서 하는 것도
- 얼마나 엄격하게 체크리스트 할지?
- 멘션은 꼭 해주면 좋겠다.
- 애매함
- 15분 얘기했음
- 밥 먹으러 간다고 얘기하면 들킴
진아)
- 호
- 라운드 분리하는 것
- 공유하기 하면 사용법, 동작 원리 공부할 수 있을 것 같다
- 기술 블로그를 언제 어떤 주제로 쓰는가?
- ex) React vs Next
- 왜 Next를 쓰기로 했는지
- 팀 내에서 쓰기로 한 이유?
- 성빈) 옳은 결정을 했다 어필보다는 (물론 그러면 베스트지만) 우리가 어떤 경험을 했는지 공개하는 것
- 10시-12시 추가 코어타임 → 나에게 꼭 필요하다고 생각
- 스레드 분리 → 얘기가 안 섞이게 돼서 좋을 것 같다
- 슬랙 워크플로우 OK
- 적는 시점?
- 오전에는 체크리스트, 워크플로우는 밤 10시에 작성
- 애프터스크럼은 오후에
- (TODO: 체크리스트 운영방식 구체화가 필요할 듯)
- 개발 일기와 좀 겹친다
- 호민) 의도: 어느 시점에 얼마나 했는지 기록
- checklist
- 15분 알림 → 하면 좋을 것 같다
- Todolist 하면 좋을 것 같다
- 멘션 하는 것 좋다
- 애매함
- 배운 점, 어려웠던 점, 느낀 점, 고민한 점, 결정한 점 → PR에?
- PR에 올리는 부분은 이상하다.
- 이상했던 점:
- 원래 PR에 쓴 내용:
- 개발한 내용을 상세하게 적고,
- 리뷰 받고 싶은 내용을 적고
- 블로그에 올릴 내용을 적는 것 같아 어색하다는 느낌.
- 다른 팀원 분들 의견)
- 호민) PR에 위치시키는 건 좀 어색한데?
- 공유해야 된다고 생각
- 왜 코드를 그렇게 짰는지 이해하는 데이터라고 생각
- 왜 이렇게 짰는지 고민하는 시간을 PR 작성자가 줄여줄 수 있다.
- 희라) 좀 어색한데?
- 쓰는 건 어렵다
- 개인적으로 하면 좋을 것 같다
- 고민한 부분만 공개
- <일단 넘어감>
- 불호
희라)
- 호
- 논의-결정 라운드 분리
- 공유 좋음
- 기술 블로그 → GitHub Wiki 좋을 듯
- 저녁 코어타임
- 스레드 만들기
- 워크플로우
- 15분 이상 자리 비울 때 남기고 가면 좋을 듯
- 애매함
- PR
- todolist checklist → 갈수록 안 하게 돼서 좋아하는데 잘 지켜질 수 있는 방법이 필요하다
성빈)
- 다 좋은데, 구체화 필요한 것 같다:
- 워크플로우 운영
- Checklist 운영
- 호민) 내일 해와서 다시 얘기해보면 좋을 것 같다
결정
호민) 5가지 내용
- 팀에 공유하는 게 좋을지 물어보기
- 적는 곳의 위치를 물어보기
호민) 기술 정리해오기
성빈) 빠릿빠릿하게 시작하려면 기술 결정을 한다면 이번 주 내로 하는 게?
- 학습해야 할 내용이 많다.
- 제안:
- 최선의 방법: 2차 팀플 프로젝트 받아와서 수정하기
- 괜찮은 방법: CRUD Example, Simple Example 해보기
- 이 정도만 해봐도 결정하는데는 충분한 듯
- 이건 제가 찾아서 공유해볼게요!
- 차선: 비교 표 정도 읽고 validation 역할을 하기
- 시간이 없다면 일단 도입하고 써보고 교체하는 것도 좋다
- 사실 이게 베스트인 것 같다
희라) 빨리 정하고 학습하는 것도 좋을 것 같다
호민) 리스트업
기술 스택 분류 (26일에 정하기)
아예 사용하지 않음의 의견도 가능하지만 기존 도구를 모르면 빈틈이 있을 수도 있을 것 같아요
일단 관심 있는 것들은 리스트업을 다하고, 유사한 것 중에서는 하나씩만 추리고(ex: react-query / swr) 학습하는 쪽으로 가시죵
선택지가 없는 것
- TypeScript, React.js
- 린트 도구: ESLint, Prettier
기본편
스타일링 라이브러리 (Tailwind 등)
UI Framework (Material-UI, Bootstrap 등)
전역 상태 관리 (Redux, RTK, Zustand, Recoil 등)
서버 상태 관리 (React-query / swr / 미사용 등)
메타 프레임워크 (Next / Remix / 미사용)
약간 고급편
컴포넌트 문서화 도구 (Storybook 등)
번들러 (Vite, Webpack 등)
패키지 매니저 (npm, pnpm, yarn legacy, yarn berry 등)
테스트 도구 (react-testing-library, playwright, Storybook 등)
테스트 러너 (jest / vitest 등)
고급편
배포 방식 (Vercel, AWS S3, OpenNext 등)
코드 통합 도구 (GitHub Actions 등)
성빈) 호민님 지적하신 것처럼 Next + Vite는 어려운 것 같아요.
- Next가 마법이 많아서 그런지, Webpack 기반으로 이것 저것 많이 하나봅니다
- 대신 Webpack이 dev server 키는 거나 빌드가 원체 느려서
- Vercel에서 Turbopack이란 걸 beta(?)로 제공하는데, 아직 beta여서…
- 일단은 Webpack으로 시작해서 나중에 속도 향상을 체감해보면 매우 좋을 것 같아요
