공식적으로 프로젝트 하기로 한 6주가 지나갔다.
빠듯한 기간동안 좋았던 점도 많았고, 보완해야할 부분도 많았다.
팀원 한분이 KPT회고라는걸 알려줬다. 이 회고를 통해 교훈을 얻으며 끝 매듭을 짓고, 새로운 시작을 준비할 수 있었다.

📌 KPT 회고란?

Keep, Problem, Try의 약자로 Keep은 잘 한 것, Problem은 아쉬운 것, Try는 K와 P 기반으로 실행가능하고, 측정가능한 Action을 도출.

회고의 목적

지금보다 더 나은 협업을 위해 실행할 action item을 2~3가지 정도 도출해내기.

회고의 시기

kpt회고를 해보면서, 이 회고방식을 도입하는 시기가 중요하다고 느꼈다. 6주동안의 빠듯한 프로젝트가 끝나고, 새로운 시작을 준비해야했기 때문에 지금 한번 잡고 가는건 좋은 것 같았다.

회고의 구성
1. Keep (유지할 것)

• 이번 스프린트(또는 프로젝트)에서 잘된 점
• 효과적이었던 방법이나 프로세스
• 계속 유지하고 싶은 팀의 문화나 협업 방식

2. Problem (문제점)

• 비효율적이었던 점이나 개선이 필요한 요소
• 업무 진행 중 겪은 어려움
• 팀 내 의사소통이나 도구 사용의 문제

3. Try (시도할 것)

• Problem에서 도출된 개선안을 구체적으로 실천할 방법
• 다음 스프린트나 프로젝트에서 적용할 변화
• 새로운 도구나 프로세스를 도입할 아이디어

📌 진행 방식

1. KEEP/PROBLEM은 각자 미리 작성해오기
2. 회고 미팅에서 동료들에게 내용 공유
   • 회고 미팅에서는 노션을 활용해 함께 브레인 스토밍하며 진행했다. Keep, Problem을 이야기 하면서 Try부분을 함께 적었다.
3. 다같이 TRY와 Action Item을 추출하기
   • 도출된 Try항목 중에서 우선순위를 정했다.
   • Try에서 적었던 내용들을 구체적이고 실행가능한 Action Item으로 정리했다.
   • 다음 회고 때는 이 Action Item들이 잘 적용됐는지 점검하자.

📌 작성 시 고려할 것들

• 기획, 디자인, 개발 협업관계
• 서버 ↔ 클라이언트간 협업관계
• 스스로 깨달은점
• 다른사람에게 주고 싶은 피드백
• Problem은 특정 사람을 탓하고, 비난하기 위한 항목이 아님. 대상이 사람이 아닌 현상이면 좋아요!
  • 발생했던 문제가 왜 발생했는지를 파악하고, 앞으로 일어나지 않도록 개선해나가기 위한 과정이라고 생각해주세요!

📌 뽀또픽 KPT회고

📌 K - Keep

📌 1. 주기적인 회의, 기획 단계부터 전원이 적극적으로 참여

• 주기적인 회의를 통해 기획, 디자인, 개발 모두가 기획 단계부터 함께 참여.
• 이로 인해 팀원 모두가 서비스의 전반적인 흐름과 방향성을 명확히 이해할 수 있었고, 서비스에 대한 오너십이 자연스럽게 생겼다.
• 지금과 같이 기획에 적극적으로 참여하려는 마인드를 가지고 이어가면 될 것 같습니다.

📌 2. 2차 MVP 때부터 Technical Document를 작성하여 개발 간 싱크를 맞췄던 것

• 개발 전에 문서화를 통해 싱크를 맞추어 개발 기간 동안의 소통 비용이 확실하게 줄었다.
• 스펙이 이미 논의되어서, MSW를 통해 api 개발에 병목 없이 클라이언트 개발이 가능했다.
  • 특히, 2차 MVP 몇몇 기능은 서버 개발 이전에 클라이언트 개발이 끝났었음
• 앞으로도 개발 이전에 Technical Document를 통한 싱크를 컨벤션으로 가져간다!

📌 3. 의견 있으면 숨김 없이 제안했던 것

• 개발이나 디자인이나 생각한 것과 다른 부분이 있으면 의견을 제안한 것
• 그 제안을 통해서 내용이 바뀌는 것을 떠나서 이런 과정을 통해 서로의 의견을 맞추는 것이 좋았다
• 지금처럼만 해도 의견을 모으는데 부족함 없을 것 같다

📌 4. 팀 구성원의 목표와 상황을 인지하고 있던 것

• 프로젝트 시작 전에 목표를 공유하여, 프로젝트 중에 목표에 어긋나지 않도록 동기부여할 수 있었음
• 개인적인 하루일과를 알고 있어서, 감안하여 일정을 조율할 수 있어 좋았음
• 좀 더 친해지면 좋을 것 같다(너무 친하면 안되지만…)

📌 5. MVP를 쪼개어 진행한 것(피드백)

• MVP 작게 만들고 사용자 피드백을 받아, 우선순위를 정할 수 있었다.
• 의견이 분분할 때, 사용자 피드백은 가불기였다
• 이를 바탕으로 개선해나가는 작업이 결국 프로덕트를 만드는 궁극적인 이유와도 같았다.
• 피드백 받은 것을 문서화 하여 깔끔하게 정리해야 된다. (피드백에 대한 서로의 생각 공유)
• 피드백은 아주 소중하고 두고두고 봐줘야할 요소인데, 피드백 공유에 참여한 인원이 없어 그냥 넘어갔다.
• 만약에 문서화를 한다면 같이 보면서 기획의 시간을 가졌으면 좋겠다.

📌 6. 자발적인 개발과 디자인

• 문제가 될 수 있는 부분을 자발적으로 캐치하여 개발해주신 덕분에 좋았다.
• 서버문제, 확장자 문제, UI, 캐릭터, 기능 예외 등등
• 문제가 될 부분을 미리 알려주고 진행하면 더 좋을 것같다.
• 그리고 문제가 될 부분을 알게 되면 문서화 하여 팀 전체에 공유 해야겠다. → 일정파악 / 우선순위 파악

📌 7. 매주 만나고, 매주 2회씩 회의

• 회의 참석률이 너무 높아서 좋았다. 의견공유 활발

P - Problem

📌 1. 1차 MVP 배포된 이후에 디자이너가 원하는 디자인이 적용되지 않음을 알았다.

• QA를 위해 1차 MVP 배포를 했는데, 그때서야 디자인이 의도한대로 나오지 않았음을 알았음
• 1차적으로는 프론트엔드 팀에서 디자이너에게 결과물을 미리미리 공유하지 못한 점이 아쉬웠다.
• Preview를 통해 미리 보여드렸다면 진작에 소통해서 해결할 수 있는 문제라 더욱 아쉬웠다.
• 가이드를 잘못줬다.
• PR (개발) 커밋 → 리뷰 → Dev Deploy (기획, 디쟌)

📌 2. 게스트 로그인 개발이 예상한 시간보다 오래 걸렸다.

• 게스트 로그인 개발 시간을 하루 미만으로 예상했는데, 2~3일이 지나도 해결되지 않았다.
• 2~3일이 밀렸는데, 팀에게 상황이 공유되지 않았다.
• 프론트 내에서 내가 맡은 작업은 개인적으로 책임감을 가지고 충분히 고민하여 해결하면 된다고 생각했지만, 이를 팀에게 충분히 공유하지 않고 스스로 고민하고 해결하려다 보니 결국 시간이 지체됨. 조직 전체 일정과 협업에 영향을 미친다는 점을 간과함.
• 작업 상황을 공유하며 백엔드 팀과 정리하고 공유드린 부분들을 이해하셨다고 생각했지만, 이후 보니 내 설명이 충분히 전달되지 않았고, 정확히 이해하지 못하신 부분이 있었음.
• 작업 상황과 문제를 설명할 때, 배경과 맥락을 구체적으로 전달하지 못함.

📌 3. 기능명세가 나온 이후에 의견들을 제시하여 두 번 일하게 되었다.

• 기능명세가 이미 완성되었는데, 그 이후에 개발자들이 개발을 진행하면서 기획 쪽에 의견들을 계속 제시했다.
• N차 MVP 범위가 정해졌는데 새로운 기능(버그 픽스 x)을 추가하여 범위가 늘어났다
• 명세 완성 이후 팀 전체가 싱크 맞추는 기회가 없었음
• 당연히 개발자들이 명세를 보면서 미리미리 의견을 제시하면 좋겠지만, 개발을 시작할 때 명세를 보기 시작한 것도 문제라고 생각

📌 4. 개발자들의 개발 진행 상황 트래킹이 잘 안 되었다.

• 개발자들의 개발 진행 상황 트래킹이 잘 되지 않았음
• 데일리 스크럼, 기획자 분께서 개인 연락으로 트래킹을 열심히 시도해주셨으나, 팀에게 잘 공유는 안되었음
• 1차적으로는 개발자 개인이 매일매일 진행상황을 공유했으면 해결됐을 문제
• 회사가 아니니 어쩔 수 없는 것은 인지하고 있다.

📌 5. 일부 팀원들이 논의한 상황이 팀 전체에게 공유되지 않고 반영된 경우들이 있었다.

• 정기회의 이외에 일부 팀원들의 논의를 통해 결정된 사항들이 팀 전체에 공유가 잘 되지 않았음
• 일부 팀원들의 논의를 통해 결정된 사항들을 피그마에 잘 기술해주셨으나, diff를 파악하기 어려워서 개발자 입장에서 어느 순간 반영된 것처럼 느껴질 수 있을 것 같음
• 개발자들이 개발을 시작한 이후에나 왜 바뀌었는지에 대한 히스토리를 파악하게 됨

📌 6. 개개인의 회의 준비 부족 → 회의 지연

• 회의 시작 전 어떤 내용을 논의해야 할지 파악되지 않아, 회의 자리에서 문제를 인식하고 바로 해결법을 찾는 형식으로 회의 진행.
• 논의에 대한 의견이 생각나지 않은 경우엔 의견을 피력하지 못하거나 고민하는 시간이 길어져 회의 시간이 불필요하게 지체됨.
• 회의 안건이 사전에 명확히 공유되지 않았음.
• 프로젝트 데드라인으로 인해 팀원들이 회의 전에 충분히 고민할 시간적 여유가 부족했음.

📌 7. 디자인 수정이 빈번히 발생함.

• UI 작업을 완료 했으나, 이후 추가 수정 요청이 발생해 동일한 작업을 여러 번 반복해야 했음.
  → 시간 지체
• 예상 가능한 수정 사항에 대한 사전 협의 부족.

📌 8. 기획 변경 사항 공유 부족 (+ 피그마 반영)

• 마감 기한을 맞추기 위해 최소 기능으로 조정한 내용이 피그마에 반영되지 않음. (피그마에는 2차 MVP 수정 사항이 반영되지 않은 채로 초기 디자인 작성 후 업데이트 되지 않아 업데이트 된 점을 인지 하지 못한 상태로 UI 반영, 추후 다시 롤백)
• 개발 중 기획 변경 사항 파악이 어려워 혼란 발생.
• 소수 인원 회의로 결정된 내용이 전체 팀원에게 충분히 공유되지 않음.
• 피그마/노션 등 협업 툴에 변경 사항 기록 미흡.

📌 9. 공통 컴포넌트 정의와 소통 부족

• 1차에서 투표 상세 페이지에만 있던 vertical Ellipsis가 2차에서 홈에도 추가.
• 초기 공통 컴포넌트로 지정하지 못한 채 기존에 사용하던 것들을 리팩토링 하다보니 시간 지체.
• 재사용 시도 실패 → 개발 시간이 불필요하게 지연. 홈에서는 결국 vertical Ellipsis 없는 상태로 배포.
• 디자인 단계에서 해당 컴포넌트의 재사용 가능성, 공통화 여부에 대한 논의 부족.
• 컴포넌트가 추가되는 시점에서 개발자-디자이너 간 협의 없이 바로 적용 시도.

📌 10. 케이스별 화면 UI 부족

• 기능 명세서 및 피그마 UI가 케이스별 흐름, 예외 상황이 충분히 명확하게 정리되지 않아 UI를 구현할 때 예상하여 구현하거나 재차 확인해야 하는 상황 발생.
• 초기 기획에서 케이스별로 깊게 고민해볼 시간 부족.
• 케이스 별 UI가 피그마에 명확하게 정리되어있지 않은 경우가 있었음.

📌 11. UX 완성도 미흡

• 1차 MVP 이후 UX/UI 피드백 다수
• 초기 ux 설계가 미흡했음

📌 12. 협업 툴 사용 어려움

• 개발 체크리스트를 놓치는 경우가 많음

📌 13. 이유를 말하지 않고 주장을 어필했다.

• 건 주고 받을 때, ~~했음 좋겠다. 이거 있어야된다. ~~왜하냐, ~~굳이 해야되냐?라고 하니 생각을 알 수 없어 답답했다.

📌 14. 체크리스트의 부재

• 명세만 있고, 완료여부를 모르겠음
• 할일 목록이 없음

📌 15. 그라운드 룰 안지킴

• 그라운드룰을 잘 안보고 잘 안지키게 됨(전원)
• 그라운드룰이 실상 막 중요한 느낌은 아닌데, 지나고보면 좀 중요한듯.
• 추가할만한 룰이 있는데, 어차피 안보니까 잘안하게됨

📌 16. 답답할때, 빠르게 의견공유 안함

• 생각 달라서 지연됨
• 생각이 다른데, 말을 안했음
• 사람한테 싫은소리하게 될까봐 싫어서 안함

📌 17. 연락 및 트래킹 시간 축소 필요

• 명세나 문서화, 추후 기획과 정의작업이 연락하고 트래킹하는데 시간 다써서 넘 힘들었음
• 그러다 보니 나중엔 명세에 있었는지, 얘기가 정확히 됐는지 잘 모르겠음
• 아주 보잘 것 없는 질문이어도 답변을 해줘야될 것 같음.
• 확인 하라는 공지에 확인 후 피드백이 적었다.
• 완료건, 진행 건 혹은 답답하고 이해안되는 건 등등 서로 미루지 않고 바로 말하기

📌 18. 기획 방향이 명확하지 못했음

• 기획과 결과의 차이 발생

📌 19. api 설계를 다같이 안 해서 수정이 자주 일어남

• api 개발을 다같이 안 해서 계속 수정이 발생함
• 백에서 임의로 만들고 프런트에서 보면서 부족한 부분 수정 요청하는 방식으로 개발됨
• 백에서 프런트가 어떤 데이터를 필요로 하는지 완벽하게 알기가 힘듬

📌 20. 기능 구현 기간을 애매하게 정함

• 기능 구현을 할 때, 정확한 기간을 정하지 않아서 기획/개발자 간의 싱크가 맞지 않았음
• 그래서 누구는 언제까지 구현되어야 한다 하고, 누구는 더 우선인 기능을 구현하고 나서 작업해야한다는 등
• 기능 별로 완료 기간을 정확하게 정하지 않고, 각자 생각하는 방향과 그림이 다름

📌 21. 성능이 너무 안나옴

• 돈이 듦

📌 T - Try

📌 ✅ 1. Trello 사용방법 리서치 및 발표

📌 ✅ 2. 기능명세서 완성 후 팀원들과 공유하는 시간을 갖자

📌 ✅ 3. 기획 + 프론트 + 백엔드가 설계를 같이해본다

📌 4. 더 많은 피드백을 얻기 위한 방안을 마련한다.

📌 5. 피그마에 변경내역만 있는 명세 추가

📌 6. 케이스 별로 화면 구성하기

📌 7. 피드백 받은 것을 문서화 및 리뷰

📌 8. 개발에서 마주한 문제를 팀에게 공유하자

📌 9. Preview Deploy 도입 검토

📌 10. 그라운드 룰 다시 작성 후 상기하는 시간

📌 11. 성능 개선

📌 회고의 장점

📌 간단하고 직관적

• Keep, Problem, Try라는 3가지 요소로 구성되어 있어 누구나 쉽게 적용할 수 있었습니다.
• 팀원 간 피드백을 자연스럽게 유도하여 그동안의 답답한 부분을 해소할 수 있었습니다.

📌 팀 성장

• 회고를 통해 문제점을 파악하고, 해결 방안을 함께 고민할 수 있다.
• 지속적인 개선이 가능
• Try에서 나온 개선 사항을 실천하고, 이후 회고에서 점검하는 방식으로 지속적인 개선이 가능하다.
• 긍정적인 팀 문화 형성에 기여합니다.
• 단순히 문제를 지적하는 것이 아니라 잘된 점(Keep)을 공유하며 동기부여할 수 있다.

📌 KPT회고가 필요했던 이유

📌 적극성 부여

팀의 성장 때문에 필요했다. 팀이 성장한다는 것은 팀원들 간의 긍정적인 상호작용이 일어나고 있다는 뜻이다. 우리 팀에서 가장 부족했던 것은 적극성이다.
찔러야 나오는 것이 아쉬웠다. 찌르기 전에, 문제가 있으면 이야기하고 소통할 수 있어야 했는데 그렇지 못했다. 그러다가 서로의 입장이 쌓인 뒤, 유야무야 푸시해서 진행된 적도 몇 차례 있었다. 그래서 회고가 어찌보면 늦은 감이 있었나? 싶을 정도로 필요 했다.

📌 발언의 기회 부여

각 팀원들에게는 일부는 쌓아두는게 어쩔 수 없는 선택이기도 하다. 왜냐하면 어떤 직책 혹은 책임을 지지 않고 동등한 레벨의 멤버에게 어필하기란 쉽지 않다. 게다가 전달하고자 하는 내용이 상처가 될 수도 있기 때문에 문제와 해결책을 알면서도 마음 속에 쥐고 있을 수 밖에 없다고 생각한다.
KPT회고는 팀원들에게 의사를 말할 수 있는 기회를 제공하고, 다른 팀원들의 상황을 이해하게 만든다. 이후에는 종합적인 상황안에서 모두가 동의하는 해결방안을 마련할 기회를 제공한다.