KPT 회고: 실제로 변화를 만드는 회고 운영법 (방법, 템플릿, 예시)
대부분의 회고 미팅은 같은 방식으로 조용히 실패합니다. 스프린트나 프로젝트가 끝나면 팀이 모여 잘된 일을 나누고, 불만을 몇 개 나열하고, 뭔가 생산적이었던 것 같은 기분으로 흩어집니다. 2주 뒤에 같은 문제가 다시 나타납니다. 그날 말해진 것 중 무엇도 변화로 이어지지 않았기 때문입니다.
KPT는 바로 그것을 막기 위해 만들어진 회고 프레임워크입니다. 대화를 세 개의 버킷으로 구조화합니다. Keep(잘돼서 계속할 것), Problem(방해가 된 것), Try(다음에 바꿀 것). 일본의 애자일 커뮤니티에서 오랫동안 표준 회고 포맷으로 쓰이며 널리 퍼졌고, 어떤 팀이든 도입할 가치가 있는 결정적인 특징이 하나 있습니다. 회의의 산출물이 토론이 아니라, 구체적인 실험의 짧은 목록이라는 점입니다.
이 가이드는 KPT가 무엇인지, 회의를 단계별로 어떻게 진행하는지, 오늘 바로 복사해 쓸 수 있는 템플릿, 회고를 형식적인 연극으로 만드는 실패 패턴, 다른 회고 포맷과의 비교, 그리고 회고가 매번 리셋되지 않고 차곡차곡 쌓이도록 기록을 자동화하는 방법을 다룹니다.
⚠️ 이 글은 2026년 7월 기준으로 공개된 정보와 사용자 피드백을 바탕으로 독자적으로 정리한 것입니다.
목차
- KPT 회고란?
- KPT 미팅 진행법: 5단계
- 복사해서 쓰는 KPT 템플릿
- 실제 팀의 KPT 예시
- KPT 회고가 매너리즘에 빠지는 5가지 경우와 해법
- KPT vs. 다른 회고 포맷
- 첫 KPT 회고를 위한 체크리스트
- AI로 회고 노트 자동화하기
- FAQ
- 결론
KPT 회고란?
KPT는 팀이 논의하는 모든 것을 세 가지 질문으로 분류하는 회고 포맷입니다.
- Keep: 무엇이 잘됐고, 계속할 가치가 있는가?
- Problem: 무엇이 잘 안 됐거나 우리를 느리게 만들었는가?
- Try: 다음 기간에는 무엇을 다르게 할 것인가?
이 프레임워크는 자유 형식 스프린트 회고의 가벼운 대안으로 애자일과 스크럼 팀을 통해 퍼졌고, 엔지니어링 밖에서도 똑같이 잘 통합니다. 영업팀은 월간 리뷰에, 프로젝트 팀은 마일스톤 사후 분석에, 개인은 주간 자기 점검에 사용합니다.
KPT의 핵심은 세 개의 칼럼 자체가 아닙니다. 이 포맷이 대화를 반성에서 행동으로 밀어붙인다는 점입니다. Keep과 Problem은 원재료이고, Try가 산출물입니다. 담당자가 붙은 작은 Try 목록 없이 끝난 회고는, 토론이 아무리 만족스러웠어도 끝난 것이 아닙니다. 이 원칙만 기억해도 뒤에서 다룰 실패 모드 대부분을 예방할 수 있습니다.
KPT vs. 일반적인 스프린트 회고
이미 스프린트 회고를 운영하는 팀이라면, KPT는 대체 의식이 아니라 같은 회의를 위한 더 날카로운 아젠다입니다.
| 자유 형식 회고 | KPT 회고 | |
|---|---|---|
| 구조 | 열린 토론, 진행자에 따라 제각각 | 고정된 세 버킷: Keep, Problem, Try |
| 일반적인 산출물 | 메모, 감상, 약간의 액션 아이템 | 담당자가 붙고 확인 가능한 Try 2~3개 |
| 리스크 | 결정 없는 푸념, 큰 목소리가 지배 | 기계적으로 적용하면 경직됨 |
| 적합한 팀 | 진행 역량이 뛰어난 성숙한 팀 | 일관되고 비교 가능한 회고를 원하는 모든 팀 |
고정된 구조에는 복리 효과가 있습니다. 매 회고가 같은 형태의 산출물을 내기 때문에, 시간에 따라 회고를 비교하면서 같은 Problem이 계속 재등장하는지 볼 수 있습니다. 자유 형식 회고가 잃어버리는 것이 바로 이 가시성입니다.
KPT 미팅 진행법: 5단계
6명 이하 팀 기준으로 30~60분을 잡으세요.
1단계: 프레임 설정 (5분). 돌아볼 기간과 범위를 명시합니다. 예를 들어 "지난 2주, 릴리스 작업 중심으로." 그리고 기본 원칙을 소리 내어 반복합니다. 회고는 팀이 일하는 방식을 살펴보는 자리이지, 개인을 살펴보는 자리가 아니라고요. 회고가 비난으로 변하는 순간, 정보 생산은 멈춥니다.
2단계: Keep 수집 (10분). 각자 조용히 먼저 씁니다. 스티커나 공유 문서에 적은 뒤 한 명씩 공유합니다. 말하기 전에 쓰는 것이 중요합니다. 자유 토론으로 시작하면 가장 큰 목소리가 분위기를 고정해 버리고, 조용한 관찰은 영영 수면 위로 올라오지 못합니다.
3단계: Problem 수집 (15분). 같은 침묵 작성 방식입니다. 여기서 결정적인 습관은 Problem을 판단이 아니라 사실로 쓰는 것입니다. "커뮤니케이션이 나빴다"는 어디로도 이어지지 않습니다. "구현 시작 후 스펙이 두 번 바뀌었다"는 곧바로 해법을 가리킵니다.
4단계: Try 결정 (15분). 영향이 가장 큰 Problem 두세 개를 골라 각각에 대한 Try를 설계합니다. "더 조심하자", "더 신경 쓰자"라는 표현은 금지하세요. 좋은 Try는 나중에 검증할 수 있는 행동입니다. "스펙 변경은 반드시 티켓으로 만들고, 스프린트 중간에 온 변경은 다음 스프린트로 넘긴다"는 지켜졌는지 아닌지가 분명합니다.
5단계: 담당자 지정과 마무리 (5분). 모든 Try에 담당자와 확인 시점을 붙이고, 다음 회고는 이 Try들을 리뷰하는 것으로 시작한다고 선언합니다. 이 오프닝 리뷰가 KPT를 복리로 만드는 엔진입니다.
복사해서 쓰는 KPT 템플릿
공유 문서나 화이트보드 도구에 붙여 넣고 오늘부터 시작하세요.
# KPT 회고 - [팀/프로젝트] - [날짜]
돌아볼 기간: [YYYY/MM/DD - YYYY/MM/DD]
참가자: [이름]
## 지난 회고의 Try 리뷰
- [ ] [이전 Try] - 결과: [효과 있음 / 계속 / 폐기]
## Keep (잘된 것)
- [계속할 가치가 있는 것과, 왜 잘됐는지]
## Problem (방해가 된 것)
- [사실로: 언제, 무엇이, 어떻게 문제가 됐는지]
## Try (바꿀 것) - 최대 2~3개
- [ ] [구체적이고 검증 가능한 Try] - 담당: [이름] - 확인: [다음 회고]
## 다음 회고: [날짜]
세 가지 사용 팁:
- "지난 회고의 Try 리뷰"가 맨 위에 있는 것은 의도입니다. 포맷 자체가 회고를 고립된 이벤트가 아니라 연속된 시리즈로 보장합니다.
- Try는 2~3개로 제한하세요. Try가 10개면 Try가 0개인 것과 같습니다. 작고 확실한 변화가 아무도 실행하지 않는 야심 찬 목록보다 빠르게 복리로 쌓입니다.
- 모든 Problem에 "언제, 무엇이"를 강제하세요. 팀이 Problem을 사실로 쓰기 시작하면 Try의 품질이 한 단계 뛰어오릅니다.
실제 팀의 KPT 예시
엔지니어링 팀의 스프린트 회고 (2주 스프린트)
- Keep: 스탠드업 15분 상한이 자리를 잡았고, 오전이 깊은 작업을 위해 조용해졌다. 리뷰 요청에 "맥락" 항목을 추가하니 리뷰 왕복이 줄었다.
- Problem: 3일 차에 스펙 변경이 구두로만 전달되어 엔지니어 두 명이 옛 스펙대로 개발했다. 릴리스 전날 스테이징이 다른 팀과 충돌했다.
- Try: 스펙 변경은 티켓화 전까지 구현하지 않는다(담당: PM, 다음 회고에서 확인). 스테이징 슬롯은 캘린더로 예약한다(담당: 인프라, 다음 회고에서 확인).
영업팀의 월간 회고
- Keep: 미팅 다음 날 회의록을 보내니 답장률이 눈에 띄게 올랐다. 데모를 첫 15분으로 옮긴 것이 잠재 고객에게 잘 통했다.
- Problem: 실주 사유가 "가격"으로 기록됐지만 실제로는 타이밍 문제인 건이 여럿 있었다. 담당자마다 노트 품질 편차가 커서 인수인계에 몇 시간씩 걸렸다.
- Try: 실주 사유를 드롭다운과 코멘트 한 줄로 바꾼다(담당: 세일즈 옵스, 다음 회고에서 확인). 상담 노트용 공유 템플릿을 하나로 통일한다(담당: 팀 리드, 다음 회고에서 확인).
두 예시 모두 Problem이 사실로 기록됐기 때문에, 모든 Try가 "더 잘하겠다"는 다짐이 아니라 시스템에 대한 변경이라는 점에 주목하세요.
KPT 회고가 매너리즘에 빠지는 5가지 경우와 해법
- Try가 실행되지 않는다. 가장 흔한 실패이고, 거의 언제나 Try에 담당자와 확인 시점이 없기 때문입니다. 템플릿 맨 위 섹션이 이를 고치기 위해 존재합니다. 모든 회고가 지난 회고의 Try를 채점하는 것으로 시작됩니다.
- Problem이 사람에 대한 불만으로 변한다. "OO님 답장이 너무 느리다"는 Problem이 아니라 공격입니다. 진행자의 역할은 번역입니다. "리뷰 대기가 평균 이틀이었다." 주어는 언제나 프로세스이지 사람이 아닙니다.
- Keep이 잡담이 된다. Keep은 칭찬 릴레이가 아니라 반복할 가치가 있는 행동을 식별하는 자리입니다. 왜 잘됐는지 한 문장을 덧붙이면 훈훈한 순간이 재사용 가능한 자산으로 바뀝니다.
- 같은 Problem이 두 번 연속 나타난다. 이전 Try가 너무 얕았다는 신호입니다. 대개 "더 열심히" 류의 Try였을 것입니다. 그 Problem에 대해서는 노력 기반 Try를 금지하고, 프로세스나 도구를 바꾸는 것으로 대응하세요.
- 아무것도 기록되지 않아 아무것도 쌓이지 않는다. 서기를 지정하면 그 사람이 토론에서 빠집니다. 기록을 아예 생략하면 다음 회고가 지난 Try를 리뷰할 수 없어 매번 제로에서 시작합니다. 아래의 AI 워크플로가 참가자를 희생시키지 않고 이 문제를 해결합니다.
KPT vs. 다른 회고 포맷
KPT는 든든한 기본값이지만 선반 위의 유일한 도구는 아닙니다.
| 포맷 | 구조 | 적합한 상황 |
|---|---|---|
| KPT | Keep / Problem / Try | 정기 팀 회고의 믿을 수 있는 기본값 |
| KPTA | KPT에 명시적인 Action 플랜 추가 | Try가 추상적으로 머무는 팀 |
| YWT | 한 것 / 배운 것 / 다음에 할 것 | 학습이 많은 상황: 온보딩, 신규 사업 |
| 4Ls | 좋았던 것 / 배운 것 / 부족했던 것 / 바랐던 것 | 프로세스만이 아니라 감정의 결까지 보고 싶을 때 |
| Start / Stop / Continue | 시작할 것 / 멈출 것 / 계속할 것 | 팀에게 무언가를 그만둘 허락이 필요할 때 |
| 타임라인 회고 | 사건을 시간순으로 배열 | 긴 프로젝트, 장애 사후 분석 |
실용적인 로테이션은 이렇습니다. 정기 회고의 상설 포맷으로 KPT를 쓰고, 분기 리뷰나 장애 이후에는 타임라인 회고로 전환하세요. 매 회의마다 포맷을 바꾸는 것은 규칙을 다시 배우는 부담만 팀에 지웁니다.
첫 KPT 회고를 위한 체크리스트
KPT 도입이 실패한다면 대개 첫 회의에서 실패합니다. 팀의 첫 경험이 "또 하나의 지루한 회의"로 읽히면 두 번째는 없습니다. 첫 세션 전에 이 여덟 가지를 점검하세요.
- 돌아볼 기간이 2주 이하인가? (더 길면 기억이 흐려져 인상 비평이 된다.)
- 참가자가 6명 이하인가? (더 큰 그룹은 팀별로 나눈다.)
- 침묵 작성 단계를 위한 공유 문서나 화이트보드가 준비되어 있는가?
- 오프닝 멘트가 준비되어 있는가: "우리는 사람이 아니라 프로세스를 본다"?
- 진행자가 먼저 쓰고 나중에 말하는 흐름을 이해하고 있는가?
- Try 2~3개 제한이 공유되어 있는가?
- 템플릿에 Try마다 담당자와 확인 항목이 있는가?
- 첫 회고가 끝나기 전에 다음 회고 날짜를 캘린더에 올릴 준비가 되어 있는가?
초기 단계 팁 하나 더. 처음 두 번의 회고에서는 Problem보다 Keep에 더 무게를 두세요. 회고가 처음인 팀은 회의가 문제로 시작되면 방어적으로 변합니다. 성공에도 구조가 있다는 경험을 먼저 주면, 세 번째 회고쯤에는 Problem 논의가 놀랄 만큼 솔직해집니다.
또한 KPT는 팀 전용 도구가 아닙니다. 매주 말 15분, 혼자서 자신의 Keep, Problem, Try를 쓰는 솔로 버전도 잘 통합니다. 팀에 도입하기 전에 한두 주 직접 해 보면 진행 감각을 몸으로 익힐 수 있습니다.
AI로 회고 노트 자동화하기
어떤 회고 문화에서든 마지막까지 남는 고질적인 문제는 기록입니다. 화이트보드 사진은 검색이 안 됩니다. 지정된 서기는 토론의 절반을 놓칩니다. 그리고 믿을 수 있는 기록이 없으면, 시스템 전체의 엔진인 "지난 회고의 Try 리뷰" 단계가 조용히 죽어 버립니다.
여기에 실시간 AI 회의 어시스턴트가 들어맞습니다. SuperIntern은 기기 오디오에서 직접 회의를 캡처하는 봇 없는 데스크톱 앱(Mac, Windows)입니다. 통화에 봇이 들어가지 않으므로, 회고가 Zoom, Google Meet, Microsoft Teams, Webex에서 열리든, 노트북이 듣고 있는 실제 화이트보드 앞에서 열리든 똑같이 동작합니다.
KPT에 특화해 보면:
- AI Canvas에 포맷을 한 번만 가르치세요. 평범한 말로 설명하면 됩니다. "이건 KPT 회고입니다. 논의를 Keep, Problem, Try로 분류하고, 모든 Try에 담당자를 붙이고, 지난 회고 Try의 리뷰도 기록해 주세요." 그 이후의 모든 회고가 그 구조로 실시간 채워집니다.
- 아무도 서기를 맡지 않습니다. 노트가 회의 중에 자라나므로, 스티커를 문서로 옮겨 적는 회고 후 정리 작업이 그냥 사라집니다.
- Try가 말해지는 순간 기록됩니다. "다음 스프린트부터 티켓화를 의무로 하죠"가 실시간으로 담당자가 붙은 Try로 노트에 남습니다.
- 지난 회고의 Try 리뷰가 몇 초면 끝납니다. 이전 회고 노트를 열면 담당자가 붙은 Try가 바로 거기 있습니다. 회의를 가로지르는 AI 채팅에 물어볼 수도 있습니다. "지난 세 번의 회고에서 나온 Try와 계속 재발하는 Problem을 정리해 줘."
- 다국어 팀도 싱크를 유지합니다. 50개 이상 언어의 실시간 번역으로 해외 지사와의 회고도 문제없고, 각자 자신의 언어로 요약을 받습니다.
솔직한 단서 하나. SuperIntern은 라이브 회의와 그 노트에 집중한 데스크톱 앱입니다. 스티커 화이트보드나 태스크 관리자가 아닙니다. 많은 팀이 SuperIntern MCP를 통해 Claude 같은 에이전트와 연결해, 확정된 Try를 Linear나 Jira에 티켓으로 보냅니다. 무료 플랜이 있으니 다음 회고에서 시도해 보는 데 비용은 들지 않습니다.
FAQ
KPT는 무엇의 약자인가요?
Keep, Problem, Try입니다. Keep은 잘돼서 계속할 것, Problem은 방해가 된 것, Try는 다음에 시도할 구체적인 변화입니다.
KPT는 어디서 왔나요?
KPT는 일본의 애자일과 소프트웨어 커뮤니티에서 스프린트 회고의 표준 포맷으로 인기를 얻었고, 이후 온갖 비즈니스 팀으로 퍼졌습니다. Start/Stop/Continue 같은 포맷과 가깝지만, 실험으로 더 직접적으로 이어진다는 차이가 있습니다.
KPT 회고는 얼마나 자주 해야 하나요?
스프린트 기반 팀이라면 스프린트마다(1~2주에 한 번). 그 외의 팀은 격주나 월 1회. 주기보다 중요한 것은 연속성입니다. 다음 회고는 반드시 이전 Try의 리뷰로 시작해야 합니다. 분기에 한 번 몰아서 하는 긴 회고는 대개 실패합니다. 기억이 흐려져 논의가 사실에서 인상으로 흘러가기 때문입니다.
회의는 얼마나 길어야 하나요?
6명 이하라면 30~60분입니다. 매번 1시간을 넘긴다면 돌아보는 기간이 너무 길거나, Problem 논의가 Try 설계가 아니라 근본 원인 발굴 고고학으로 빠지고 있는 것입니다.
KPT는 원격 팀에서도 통하나요?
네, 오히려 대면보다 낫다고 할 수도 있습니다. 침묵 작성 단계는 공유 문서로 자연스럽게 옮겨지고, 회의가 이미 컴퓨터 위에서 진행되므로 봇 없는 AI 노트가 아무도 회의록을 쓰지 않아도 논의와 Try를 기록할 수 있습니다.
KPT는 스프린트 회고와 같은 것인가요?
스프린트 회고는 회의이고, KPT는 그 회의를 진행하는 하나의 포맷입니다. 회고가 산만하게 느껴지거나 후속 실행으로 이어지지 않는다면, 기존 회고 슬롯 안에 KPT를 도입하는 것이 대개 가장 저렴한 해법입니다.
결론
KPT가 인기를 얻는 이유는, 회고가 변화를 만들어 내도록 강제하는 가장 작은 구조이기 때문입니다. 성공 조건은 몇 가지 안 됩니다. Problem을 사실로 쓰고, Try를 2~3개로 제한해 검증 가능한 행동으로 표현하고, 모든 Try에 담당자를 붙이고, 모든 회고를 지난 Try의 채점으로 시작하는 것. 이 네 가지만 하면 회고가 복리로 쌓이기 시작합니다.
이 모든 것을 지탱하는 기록에는 이제 인간 서기가 필요 없습니다. 봇 없는 AI 어시스턴트에게 KPT 포맷을 한 번만 가르치면, 모든 회고가 구조화되고 검색 가능한 노트를 남기고, 팀은 회의 시간에 본연의 일, 즉 무엇을 바꿀지 결정하는 데 집중할 수 있습니다.
SuperIntern 무료 체험하기 : 회의에 봇이 없고, KPT 포맷 그대로 실시간 노트가 만들어지며, 모든 Try가 다음 회고로 확실하게 이어집니다.
