팀을 하나로 묶는 KPT 회고 가이드
어느덧 2025년의 마지막 달인 12월입니다. PM에게 12월은 단순히 한 해를 마무리하는 시기가 아니라, 지난 1년의 러닝을 발판 삼아 내년의 도약을 준비해야 하는 가장 중요한 '회고(Retrospective)'의 시즌입니다. 하지만 많은 팀에서 회고는 "그때 왜 그랬어?"라는 식의 잘잘못을 따지는 청문회가 되거나, "내년엔 잘하자"라는 영양가 없는 다짐으로 끝나는 경우가 많습니다. 오늘은 우리 팀이 서로를 비난하지 않고, 건강하게 문제를 직면하며 구체적인 액션 아이템을 도출할 수 있는 가장 직관적이고 강력한 도구, 'KPT 회고'를 제대로 진행하는 방법에 대해 이야기해 보겠습니다.
KPT 회고는 Keep(유지할 점), Problem(문제점), Try(시도할 점)의 세 가지 관점으로 지난 시간을 돌아보는 방법론입니다. 이 방식이 강력한 이유는 회고의 균형을 잡아주기 때문입니다. Keep은 우리가 잘해온 것들을 칭찬하며 성취감을 확인하는 시간이고, Problem은 아쉬웠던 점을 객관적으로 직면하는 단계이며, Try는 그래서 앞으로 무엇을 다르게 할 것인지 해결책을 찾는 과정입니다.
PM이 회고를 진행할 때 가장 먼저 챙겨야 할 것은 '심리적 안전감(Psychological Safety)'입니다. 팀원들이 Problem을 이야기할 때 "이거 김 대리님이 실수해서 터진 거잖아요"라고 사람을 공격하는 순간, 회고는 그 즉시 실패로 돌아갑니다. PM은 시작 전에 "우리는 범인을 찾는 게 아니라, 문제의 원인이 된 시스템을 찾아서 고칠 것입니다"라고 명확히 선언해야 합니다. Problem은 '사람'이 아닌 '프로세스'를 향해야 하며, 그래야만 팀원들이 방어 기제를 내려놓고 솔직한 이야기를 꺼낼 수 있습니다.
KPT 회고의 핵심은 Problem을 나열하는 데 그치지 않고, 반드시 Try(시도할 점)로 이어져야 한다는 점입니다. 많은 팀이 실수하는 부분이 Try를 "다음엔 더 꼼꼼히 확인하자", "소통을 잘하자" 같은 막연한 다짐으로 채우는 것입니다. 이는 기도가 될지언정 전략이 될 수는 없습니다. Try는 당장 내일부터 실행할 수 있는 '구체적인 행동(Action Item)'이어야 합니다.
예를 들어, "배포 후 버그가 많았다(Problem)"에 대한 Try는 "배포 전 체크리스트를 만들고, QA 기간을 2일 확보한다"가 되어야 합니다. "기획 의도가 잘 전달되지 않았다(Problem)"에 대한 Try는 "기획 리뷰 회의 때 개발자가 역으로 기획 내용을 설명해보는 시간을 5분 갖는다"처럼 명확해야 합니다. PM은 퍼실리테이터로서 팀원들의 추상적인 다짐을 구체적인 프로세스로 통역해주고, 그것이 실제로 2026년 업무 방식에 반영되도록 챙겨야 합니다.
성공적인 회고는 회의실 문을 나서는 팀원들의 표정에서 드러납니다. 지난 1년간의 노생을 서로 인정받아 뿌듯하고(Keep), 묵혀왔던 문제들을 속 시원하게 털어놓았으며(Problem), 내년에는 더 잘할 수 있다는 구체적인 희망(Try)을 가질 때 팀은 다시 달릴 힘을 얻습니다. 바쁘다는 핑계로 회고를 건너뛰지 마세요. 잠깐 멈춰 서서 나침반을 다시 맞추는 이 시간이, 2026년 여러분의 팀이 엉뚱한 방향으로 전력 질주하는 것을 막아줄 가장 확실한 투자가 될 것입니다. 따뜻한 커피 한 잔과 함께, 우리 팀만의 KPT 보드를 채워보는 것으로 한 해를 마무리해 보시길 추천합니다.