2주차 팀회고

🏃‍♂️ J103_박무성

• 오늘은 피어세션에서 Turborepo 관련한 모노 레포 이야기와 서버 구현에 있어서 NCP 크레딧을 아끼기 위해 Nginx를 빼는 건 어떻냐, Nginx를 사용하는 구체적인 이유가 있는가, 실시간에 있어서 WebSocket을 꼭 사용해야 하는가 이런 이야기들이 나왔습니다.

  ⇒ 우리 프로젝트에서는 해당 사항이 크게 없는 듯 합니다.

☄️ J152_안성윤

• 다른팀에서 기술 도입이나 아직 확정되지 않은 부분을 결정할때 프로토타입을 어느수준까지 적용해보냐? 라는 질문이 나왔습니다. 저희는 어떻게 하고 있나 생각을 해봤는데, 아직 사실 제가 맡은 부분 말고는 이런 문제를 고민해볼만한 부분이 없었던 것 같아요. 추후 기술적으로 몇가지 선택안들에 고착되면 프로토타입 도입시 어디까지 해볼지 대략적으로 기준을 미리 정해놓는것도 좋을 것 같아요.

⇒ 나중에 기술 프로토타입울 시도하게 되면 정해도 좋을듯?

🐟 J222_정명기

• tailwindest 라이브러리에 대해서 듣고 왔는데 저희 프로젝트에 적용하면 좀 편할거 같아요

🍎 J235_조민석

• 레퍼런스 삼을 만한 사이트: https://www.surfit.io/
• 저희가 신청 받은 걸 승인 해줘야 하는 시스템인데 이것 또한 인공지능으로 그 블로그가 기술 개발 블로그인지 판단하고 승인 하는 건 어떻겠냐는 피드백을 받았습니다.
• 메세지 Broker로 Redis를 쓴다는데, 이건 잘 모르겠네요 왜 Message Broker로 쓰는지.
• 다른 조에서는 테스트 환경 구축을 안 하고 사용자 테스트만 하는 조도 있었고, 저희처럼 테스트 환경 구축을 하지만 DB 때문에 고민하시는 분들이 계시더라고요. 이분들 임시 DB 만든다고 매번 docker 컨테이너 생성하고 지우게 해놨다는데, 이것보다는 InMemory DB 쓰는게 훨 좋은 것 같네요. 설정 코드가 어무마무시 하던데… 저희는 sqlite로 딸깍… 이분들이 docker를 사용하신 이유는 운영체제, 환경에 의존되지 않게 구현하셨다는데, SQLITE InMemory DB도 SQLITE를 로컬에 설치할 필요가 없고 진짜 InMemory DB로 돌아가는 거라 이게 더 좋다고 생각했습니다.
• web09 조 같은 경우 갈등 일지 라는 걸 만들어 놨더라고요. 사용하지는 않았지만. 갈등 일어났을 때 왜 일어났는지, 어떻게 해결했는지 적어둬서 나중에 면접볼 때 기록용으로 사용하신다는데, 저희도 페이지만 만들어둬도 괜찮을 것 같아요. 갈등 일어나면 화해하고 적기용으로
• 로그 에러를 잡으면 WARN 같은 경우 20개 이상, ERROR 뜰 경우 알림 전송 이런 식으로 기준치를 잡아놨더라고요 신기했어요. 저희도 만약 클라우드 모니터링 알림 시스템 도입하면 알림 기준을 잡는 것도 좋을 것 같네요.

🌱 J249_채준혁

• 제가 디자인 시스템을 조금 더 명확하게 하고 명기님한테 공유했어야 했는데, 소통을 열심히 못 한 탓에 디자인적인 느낌이 많이 달랐어요

• 명기님 컴포넌트 구현해주신 것을 봤는데 잘 해주셨지만 제가 머릿속으로 생각한 디자인과 조금 달라서 이 부분들을 이야기해보았으면 좋겠어요

• 제 머릿속에 있는 걸 밖으로 꺼내서 명기님한테 보여드려야 했는데 이런게 많이 부족했어요

• shadcn/ui를 도입해서 컴포넌트 별 디자인을 어느 정도 통일해나가는건 어떠실까요

• storybook으로 프론트, 백 개발자 모두 다 알 수 있게 도입해도 좋아보여요

  • 이런 내용들은 제가 주말에 다시 디자인 시스템 잘 다듬어서 보여드릴 수 있도록 해볼게요 ..

---

공유 결과

---

KPT 회고

✍🏻

• Keep
  • 이런거 좋음
• Problem
  • 이거 아쉽네요
• Try
  • 이런거 해보죠

• 🏃‍♂️ J103_박무성✅

  Keep

  Problem

  • 그라운드 룰 지켜야 하는데 새벽 3시 4시까지도 깨있고, 2~3시간 풀 스트레이트로 하시는 분들이 있는 것 같습니다.
  • (저 자신 반성) 다음 날 뭐할지 생각하고 어느 정도 공부를 하고 시작해야 하는데, 그런게 부족하네요. → 저 자신 대상

  Try

• ☄️ J152_안성윤 ✅

  다음주부터 본격적으로 API개발 들어가면 좀 나올 것 같은데,,, 아직은 뭐 이렇다 할만큼 느낀게 별로 없는 것 같아요. (+ 스프린트 리뷰 제대로 진행해보면?)

  Keep

  • 이번주 태스크 진행률 저는 아주 좋다고 생각해요. 다들 너무 열심히 해주셔서 고맙습니다 🙂

  Problem

  • Github Project 상황판 관리? 조금 더 잘 신경써주시면 좋을 것 같아요. 이틀 전엔가 슥 봤는데 어떤건 작업이 끝난 것 같은데도 In Progress에 있고, 어떤 작업은 아직 진행중인데 Done에 가있는게 있더라구요.
  • 시간 & 업무 분배를 스스로 잘 못하고 있는 것 같아요. 오늘 A작업 끝내야지! 하면 A작업만 해야되는데, A를 하다가 필수가 아닌데도 B, C, D 작업을 만지고 있는 제 자신을 마주치게 됩니다.

  Try

  • 스스로 기록좀 잘 해보고 싶습니다. (트러블 슈팅이나 팀원들과 논의를 진행하면서 주옥같은 순간들이 많이 나오는데 할게 많다는 핑계로 다 흘려보내는 것 같아 너무 아쉽습니다.)

• 🐟 J222_정명기 ✅

  Keep

  • 지금까지 막힘없이? 잘 진행되고 있는거 같아서 좋습니다

  Problem

  • 백엔드쪽에서 계속해서 이런문제가 있더라 이게 안되고 있었다더라 하는데 저는 무슨 이야기인지 하나도 몰라서 끼고싶은데 낄수가 없네요..
  • 프론트엔드끼리도 소통이 좀 덜 되고있다고 생각이 들어요

  Try

  • 소통에 조금 더 시간을 가졌으면 좋을것 같습니다. 주1회 회고시간이 있긴하지만 하루만 하기는 생각보다 양이 많을거 같아서 상대적으로 덜 바쁜 목요일쯤에 한번 모여서 이슈토킹시간 한번 가져보면 어떨까용?

• 🍎 J235_조민석 ✅

  Keep

  • 휴식 그라운드 룰을 점차 지키고 있는 것 같아서 상당히 만족스럽습니다. 삶이 윤택해지고 있는 느낌이네요.
  • 이번 주에 설계 관련해서 프론트분들도 알아보기 쉽게 하려고 CI/CD, 전체 설계도 등을 만들었는데, 막상 안 알려드렸네요 ㅎ; 혼자서 알고 있었는데, 혼자서 다시 그려보면서 설계를 확실하게 이해할 수 있었던 것 같습니다. 계속 적고 공유할게요.

  Problem

  • 작업 하고 나서 Project 보드 관리를 제가 제대로 했어야 했는데 못 했습니다 ㅠ.ㅠ
  • 개인적인 문제는 꼼꼼하게 다 검증하고 PR 올리기… 긴급 PR 올리고도 몇 번의 수정 PR을 올리다 보니 한 이슈에 환경 구축만 1개, 버그 수정만 3개 PR을 올려버렸네요.. 죄송합니다 ㅠ.ㅠ 너무 덤벙대면서 개발한 것 같아요.

  Try

  • 코드 리뷰 Pn 룰 도입을 해보던지, PR에 봐줬으면 하는 소스 파일, 코드 부분을 적던지 해놓으면 좋을 것 같아요. → 코드 리뷰 문화 발전시키기
  • PR 올라오면 알림 보내는 봇 같은 걸 만들까요? 오늘 지후님 조 만드신 거 보고 확인해보니까 저희 네부캠 slack에 추가하셨더라고요. 그럼 저희도 만들 수 있지 않을까 싶네요. 매번 PR 올렸다고 채팅 치려니 좀 번거로운 듯 하네요.

• 🌱 J249_채준혁 ✅

  Keep

  • 저와 명기님이 어느 정도 컴포넌트 구현을 잘 수행해주고 계셔서 너무 좋았어요

  Problem

  • 백엔드 진행 상황이 너무 궁금해요~~
    • 프론트엔드 진행 상황은 별로 궁금해하지 않으실 수 있지만.. 저희는 알고 싶어요
    • 제안)) 그룹 리뷰를 하나 만들까요?? 학습 스프린트 8주차에 오프라인으로 만나는 날만 진행했었는데 이 때 다 같이 1시간동안 각자 뭐 구현했는지 이야기했어요. 생각보다 진행 상황 공유하기 좋았어요!
  • 제가 디자인 시스템을 조금 더 명확하게 하고 명기님한테 공유했어야 했는데, 소통을 열심히 못 한 탓에 디자인적인 느낌이 많이 달랐어요
  • 제 머릿속에 있는 걸 밖으로 꺼내서 명기님한테 보여드려야 했는데 이런게 많이 부족했어요

  Try

  • PR 코드 리뷰를 성실하게 하자
    • 준일님 한 PR에 코멘트가 100+개가 넘더라고요.. 놀랐습니다 (아마 팀원들 다 합쳐서 이렇게 나왔겠죠??? 혼자 하신건 아니었을거에요.. 아마도..)
    • 평균적으로 6-70개 하시는 것 같습니다
    • 아직 프로젝트 구현이 많이 안되어서 저희는 이렇게 많이 할 수는 없겠지만, 그래도 최선을 다 해볼게요
  • 명기님 컴포넌트 구현해주신 것을 봤는데 잘 해주셨지만 제가 머릿속으로 생각한 디자인과 조금 달라서 이 부분들을 이야기해보았으면 좋겠어요
  • shadcn/ui를 도입해서 컴포넌트 별 디자인을 어느 정도 통일해나가는건 어떠실까요 (명기님 대찬성)
    • https://ui.shadcn.com/
  • storybook으로 프론트, 백 개발자 모두 다 알 수 있게 도입해도 좋아보여요
    • 이런 내용들은 제가 주말에 다시 디자인 시스템 잘 다듬어서 보여드릴 수 있도록 해볼게요 ..
    • storybook 까지는 아니더라도 figma는 다시 구성해놓겠습니다.
    • [J074_2주차 성장 일지](https://www.notion.so/J074_2-5932263d1b194cef82ee932dc9ed3946?pvs=21)

---

회고 결과

Keep
Problem	- Project Task 관리 잘 하기
Try	그라운드 룰 코어 수면시간 단위로 바꾸기 + 휴식시간 단위로 무조건 쉬기가 아니라 휴식 투표 진행하기, 목요일 중간 공유 회의 스크럼 끝나고 잠깐 휴식후 ~ 점심시간 ,코드리뷰 문화 개선 - Pn룰 도입 후 3주차 작업해보고 다시 이야기 합시다, figma 보완

---

메모

• TODO

슬랙 PR notification bot 만들기 - 성윤

3주차 스프린트 리뷰때 코드리뷰 문화 개선 결과 확인해보기

추가 질문 있어요

• 저희가 지금 commit lint랑 lefthook이랑 commitizen이 프로젝트 자체에 설정이 되어 있어서 대부분 작업 자체는 server나 client 디렉토리 내에서 하는데 좀 불편하지 않나요? commitizen 같은 경우 프로젝트 디렉토리로 올라가야해요. 그래서 이걸 그냥 server, client 각각한테 줘야하나 고민되네요. 의견 받습니다.
• 지금 저희 방식이 모노 레포 방식이 맞는지 궁금하네영 패키지 하나로 관리하는 게 아닌 것 싶은데. npm에 workspace라는 거 써서 하나의 package를 공유해야 하는 게 아닌가요? 혹시 모노 레포 관리 해보신분