최종 KPT회고

분류

개별 주제

• 빠른 의사소통: 특히 Slack
• 슬랙을 통한 피드백에 적극적으로 참여해주셔서, 트러블 슈팅을 빠르게 진행할 수 있었습니다.
• 모르는 것이나 조금이라도 소통할 부분이 있으면 바로바로 슬랙에 연락한 점
• 빠른 답변 및 피드백
• 특히 중간 회고에서 지적된 Slack 소통에 대한 의견이 잘 반영되었음
• 소통의 양 자체가 매우 증가
• 문제점이나 모르는 것, 에러가 발생하면 스스로 해결될 때까지 혼자 검색하고 알아보는 습관이 있는데, 이번 프로젝트 때에는 코드리뷰나, slack, 오프라인 등을 통한 소통의 활용을 잘 했다고 느껴 좋았음

• 팀워크
• 일정 마지막까지 본인에게 할당된 기능 개발을 포기하지 않고 끝까지 책임져주셔서 프로젝트의 완성도를 높일 수 있었습니다. 덕분에 다른 팀들 앞에서 당당하게(!) 보여줄 수 있는 프로젝트가 됐다고 생각합니다.
• 누구의 의견도 무시하거나 감정적인 태도를 보이지 않고, 경청하고 최대한 존중하며, 의견이 다를 때는 설득을 하려고 다들 노력한 점
• 마무리 때 늦은 시간 까지 다들 열정적으로 참여해준 점
• 아이디어나 기술적 구현 사항 제시에 모두 적극적으로 참여 한 것!

• 개발측면
• StoryBook을 통한 컴포넌트 동작 test! 실제 사용시에 참고하기에 좋았음
• CI/CD 슬랙 연동 모든 에러 로그를 확인할 수 있었고, 일부 에러에서 무엇이 원인인지 빠르게 확인할 수 있었습니다.(강추)

• 비즈니스 요구사항을 한 곳에서 정리하려고 노력

• MOSCOW로 must와 should, could를 나누어 놓은 것

• 특이사항 발생 시 빠르게 1:1 대화를 통해 해결했던 점

• API 연결에서 큰 이슈 없이, 트러블 슈팅이 잘 진행되었던 점

• Slack을 이용한 실시간 소통 방식 문제가 발생하면 슬랙에 문제 상황을 공유하고 이모지, 쓰레드 등 즉각적인 반응으로 작업을 편하게 했습니다.

• 서버 API의 변경 내역이 프론트엔드 분들이 참고하는 노션 API 문서에 즉각적으로 반영되지 않아서, 불필요한 시행착오를 겪어야 했습니다.

• Nginx 관련 로깅을 팀원 전체가 빠르게 확인할 수 있는 시스템이 없어서, 관련 이슈를 파악하는 데 개개인의 직관에 의존하는 상황이 발생했습니다. (SSE 알림 등)

• 명세 업데이트가 늦어 프론트측에서 API 연동 작업할 때 추가적인 노력이 필요했음

• 명세의 일관성이 떨어졌음: 필드명 등

• 방어적 검증 로직이 부족함

• 엣지 케이스 테스트 부족

• 에러 메시지의 일관성, 가독성, 응답코드가 부적절하게 나가는 경우 많음

• 후반으로 갈 수록 진행되지 않은 코드 리뷰

• 작업 간 의존성이 존재하는 경우 먼저 수행되어야 하는 작업부터 진행되어야 하는데, 그 순서가 명확하게 지정되지 않음(Must 내부 작업 우선 순위)

• 후반부로 갈 수록 어떤 작업에 참여해야 하는 지 불명확

• 테스트용 통합 서버가 없어 프론트와 백엔드의 통합 테스트가 없어서 힘들었던 점

• 정보가 너무 한페이지에 많이 몰려있어서 정보 찾기가 힘들었던 점

• 나를 포함해서 전체적으로 기한을 아슬아슬하게 맞춘 점

• 시간때문에 코드에 많은 시간을 쏟지 못한 점

• API문서를 작성하지 못한 점

• SRP(단일 책임 원칙)을 중점적으로 두고 개발하려 하였지만, 개발 시간에 쫓겨 제대로 챙기지 못한 점

• 개발 시간에 따른 요구 기능 최적화를 하지 못한것, 이 때문에 마지막쯤에는 거의 크런치 모드로 작업하여야 했던 것 같음

• 막판에 많은 작업을 빠르게 처리했던 것 같은데, 그래서 평소보다 더 사소한 실수를 많이 했다고 느낌. 꼼꼼함 부족

• Must로 할당된 작업은 다 마무리하면서 처음 기획했던 목표는 달성하였지만, 프로젝트 시작 시 저번 프로젝트보다 리팩토링에 힘써보자! 라는 다짐을 하였는데 세부적인 완성도에는 시간을 많이 쓰지 못한 것 같다고 느낌

• 1차회고 때, 이야기 했던 ‘유저스토리, 서비스 Q&A, API 명세서’ 가 유기적으로 Update 되지 않았던 점

• 코어타임 이후, 대체로 각자 개발을 하는 경우가 많아서, 조금 더 스몰토크나 소소하게 이야기 나누며 개발할 기회가 많이 부족했던 점

• 이슈리포트 만들어 두었지만, 사용한 사람이 없었다.
• 문서의 일원화 결국 하지 못했던 점

• 8명이다 보니 소통을 위한 소통의 시간이 부족했고, 그 효과를 모두가 똑같이 인지하기에도 어려웠던 것 같다.

• 쓴소리, 싫은소리, 현재상황에 대한 경각심을 가져오는 소리를 하는 사람이 없었다.. 다들 너무 착했다 ㅠ.ㅠ

• 일정 조율에 있어, 블록처럼 따다닥 들어맞지 않았던 것 같다.
• 다른 것을 하기에는 애매하게 기다리는 시간들이 많았다

• 통일되지 않은 이름 API에서 같은 값을 가지고 있는 field의 명칭이 달랐고 그로 인해 별도의 처리 코드가 필요했다. 와이어 프레임을 통해서 페이지 별로 사용할 데이터를 정할 때 협의하고 하나로 통일하는 과정이 모자랐던 것 같다.

• 너무 큰 issue, pr 단위 한 개발의 단위인 issue를 대부분 하나의 페이지 개발로 할당했는데 이로 인해서 코드 리뷰가 적어지고, 서로 개발의 진행 정도를 확인하는 데에 어려움이 있었다.

• 불필요한 완벽주의 한 이슈의 개발 시간을 정했지만 일부 아쉬운 부분의 개선 때문에 정작 필요한 핵심 기술의 개발이 늦어졌다.

• 마감 시간에 쫓김
• 처음 일정 산출 때, 백엔드와 소통과 프론트가 3명인 점을 고려해서 서비스를 조금 더 작게 가져갔으면 하는 아쉬움
• 예상했던 개발 시간이 , 초기에 위기감 없이 너무 지체되어버림
• PR 단위가 너무너무너무너무너무 커서, 리뷰를 할 수 없는 상황까지 되었고, 나중에는 마감시간에 쫓겨 제대로 리뷰를 할 수 없었다.
• 코드 퀄리티가 너무 낮았다.

• 같은 속성에 대해 통일되지 않는 변수명

• 후반부에 코드리뷰의 효과가 많이 떨어졌다 생각

• 코드(에러코드, 타입 코드 등등 프론트와 백엔드간 약속)를 효과적으로 사용하지못함

• API의 코드 변경 내역을 동기화해서 반영할 수 있는 수단(restdocs, swagger)을 학습하고 API 컨트롤러 코드 작성과 동시에 적용해보겠습니다.

• API 애플리케이션 예외 뿐만 아니라 배포 시스템에서 발생하는 모든 오류 상황를 손쉽게 추적할 수 있는 배포 로그 확인 전용 인터페이스를 갖춘 웹 서버를 구축(kafka?)하거나, 외부에서 제공하는 서비스를 사용해볼 생각입니다.

• 도메인 → 서비스 → 컨트롤러 작업 순서 말고
• 컨트롤러(명세) → … 방식의 작업으로 빠르게 명세부터 뽑아내는 방식

• RestDocs를 적극 이용하여 자동 업데이트 되는 API 명세 문서 작업

• 비즈니스 로직에 대한 명세 작성을 적극적으로 → 테스트 케이스 작성에 도움

• Nullable 필드를 명세 레벨에서 빠르게 규정 공유하고, 기본 @Builder 등 사용을 지양

• 일관성 있는 에러 메시지를 위해 백엔드 내부 코드 리뷰 / E2E 테스트를 통해 검증

• 코드 리뷰에 시간 제한을 두기, 리뷰 해야 하는 사람에게 명확한 책임을 지우는 프로세스 세우기

• 협업 툴의 우선 작업, 작업 순서 기능등을 적극 활용하여 지금 해야 하는 작업이 무엇인지, 어떤 작업이 시급한지 등을 명확하게 표현

• 금전적 제한 때문에 Notion ↔ Github ↔ Slack … 연동 툴을 사용 못 했었는데, 사용한다면 문서 자동화에 도움이 될듯 → 도입해보고 싶음

• 최대한 atomic하게 컴포넌트를 분리하고, 충분한 시간을 가지고 SRP에 대해서 고민 해보는 것

• 개발 시간을 고려해서 must 기능을 다시 생각 해보는 것

• 진짜 코드 리뷰 간단히 코드 내용을 설명하고 approve하는 코드 리뷰가 아닌, 더 꼼꼼하고 더 코드의 질을 개선할 수 있는 코드 리뷰

• 슬랙의 문서화

• 주어진 환경에 맞는 기획, 개발 feature 정하기 (일정 계획 신중하게 세우고, 지켜지도록 서로 주의하기)

Matt!