팀 회고보드 (KPT 방식)

KPT 회고를 쓰는 때

KPT는 Keep(앞으로도 유지할 것), Problem(문제였던 것), Try(다음에 시도할 것) 세 칸으로 지난 기간을 정리하는 회고 방식입니다. 일본의 개발 현장에서 널리 퍼진 방식으로 알려져 있고, 구조가 단순해서 처음 회고를 도입하는 팀이나 짧은 시간에 끝내야 하는 스프린트 회고에 잘 맞습니다. 질문이 "잘한 것, 못한 것, 그래서 무엇을 바꿀 것"이어서 감정 토로로 흐르지 않고 마지막에 행동 항목이 남도록 설계되어 있습니다. 프로젝트 마무리, 릴리스 직후, 장애 대응이 끝난 뒤처럼 "방금 겪은 일"이 기억에 남아 있을 때 가장 좋습니다.

단계별 작성 순서 (60분 기준 예시)

1. 규칙 확인 (5분): 사람이 아닌 상황과 사실에 대해서만 말하고, 여기서 나온 이야기는 평가에 쓰지 않는다는 점을 먼저 합의합니다.
2. Keep과 Problem을 각자 조용히 작성 (10분): 말하기 전에 각자 적게 해야 말이 많은 사람의 의견만 남는 일을 줄일 수 있습니다. 한 항목에 한 가지 사실만 적습니다.
3. 공유와 묶기 (10분): 같은 내용은 합치고 투표나 대화로 이야기할 순서를 정합니다. 항목이 많을 때는 닷보팅 도구로 다룰 항목을 추립니다.
4. Problem의 원인 짚기 (15분): 가장 영향이 큰 문제 1~3개만 골라 "왜 그랬나"를 두세 번 되물어 구조적 원인을 찾습니다.
5. Try 확정 (15분): 원인에 대응하는 행동을 정하고 담당자와 기한을 붙입니다. 이 부분은 SMART 목표 설정 도구의 기준으로 다듬으면 구체화됩니다.
6. 정리 (5분): 회고 내용을 복사해 위키나 채널에 남기고, Try는 액션아이템 트래커로 옮겨 진행 여부를 추적합니다.

시간 배분은 어디까지나 예시입니다. 20~30분짜리 짧은 회고라면 2~4단계를 줄이고 Try 확정에 시간을 더 쓰는 편이 좋습니다.

작성 예시: 결제 모듈 개편을 마친 백엔드 5인 팀

아래는 가상의 팀이 2주 스프린트를 마치고 작성한 보드입니다. 항목이 모두 구체적인 사실이고, Try가 Problem 하나하나에 대응한다는 점을 눈여겨보세요.

이 보드에서 Problem은 3개, Try는 3개이며 Try마다 실행 방법이 구체적이고 대응하는 Problem이 분명합니다. 반대로 Keep은 "분위기가 좋았다" 같은 막연한 칭찬이 아니라 다음에도 일부러 지킬 수 있는 행동이어야 의미가 있습니다. 위 예에서 "PR 첫 리뷰는 반나절 안에"는 약속이므로 유지하자고 말할 수 있지만, "협업이 좋았다"는 무엇을 유지할지 알 수 없습니다.

모호한 Try를 행동으로 바꾸기

회고가 흐지부지되는 가장 흔한 이유는 Try가 다짐에서 끝나기 때문입니다. 같은 문제를 어떻게 바꿔 적는지 보여 주는 예입니다.

다른 상황의 예시: 고객지원팀과 디자인팀

위 예시는 개발 팀이라 PR이나 배포 같은 말이 나왔습니다. KPT는 개발 밖에서도 같은 구조로 쓸 수 있습니다. 아래는 직군이 다른 가상의 팀 두 곳이 적은 항목 일부입니다.

고객지원팀(6인, 한 달 운영 회고). Keep: "환불 문의는 접수 당일 안에 첫 답변을 보낸다는 규칙". Problem: "같은 질문에 담당자마다 다른 안내가 나감", "야간 문의가 월요일 오전에 한꺼번에 몰림". Try: "자주 오는 질문 10개를 팀 위키에 표준 답변으로 정리하고 금요일마다 1개씩 갱신(담당: 번갈아 가며)". 여기서 눈여겨볼 점은 Problem을 "응대 품질이 들쭉날쭉"처럼 평가어로 쓰지 않고 "같은 질문에 다른 안내"라는 관찰된 사실로 적었다는 것입니다.

디자인팀(4인, 앱 리뉴얼 프로젝트 종료 회고). Keep: "시안을 확정하기 전에 개발 담당과 15분 검토를 하는 습관". Problem: "최종 파일 이름 규칙이 없어 버전이 섞임", "피드백이 메신저·메일·회의에 흩어져 있었음". Try: "피드백은 한 도구의 한 스레드에만 모으고, 이름 규칙(날짜_화면명_버전)을 첫 주에 팀이 합의". 이처럼 프로젝트 단위 회고는 기간이 길어 항목이 많아지므로 Problem을 시기별(기획, 제작, 전달)로 나누어 적으면 정리하기 쉽습니다.

회고 시간별 단계 배분표

위 60분 예시의 비율(5·10·10·15·15·5분)을 그대로 두고 총 시간만 바꿔 환산한 표입니다. 반올림 때문에 합이 총 시간과 1~2분 다를 수 있으며, 권장 시간이라기보다 짧은 회고에서 어느 단계를 먼저 줄일지 가늠하는 참고입니다.

30분 회고에서는 비율대로 줄이면 "원인 짚기"와 "Try 확정"이 각각 8분과 8분이 됩니다. 시간이 이만큼 부족하다면 문제를 한 개만 골라 깊게 다루고 나머지는 보드에 남겨 다음 회고로 넘기는 편이 낫습니다.

인원수에 따라 보드에 쌓이는 양

각자 Keep 2개, Problem 2개를 적는다고 가정하면 인원이 늘수록 항목은 곱으로 늘어납니다. 원인을 짚는 15분을 문제 3개에 나누면 한 문제당 5분 안팎이므로, 인원이 많을수록 "묶기" 단계에서 비슷한 항목을 합치는 일이 중요해집니다.

12명이 모두 같은 보드에서 회고하면 Problem만 24개가 올라올 수 있습니다. 이 규모에서는 팀을 둘로 나누어 각자 회고한 뒤 Try만 합치는 방식도 고려해 보세요. 이 도구는 한 화면에서 한 사람이 입력하는 보드이므로, 항목이 많을 때 진행자가 화면을 공유하며 비슷한 항목을 구두로 합친 뒤 입력하는 것이 현실적입니다.

Try 이행률로 회고의 효과를 점검하기

회고가 효과가 있었는지는 새 Try가 얼마나 나왔느냐가 아니라 지난 Try가 얼마나 실행됐느냐로 가늠합니다. 아래는 가상 팀이 4번의 스프린트 동안 기록한 예시이며 실제 통계가 아닙니다. 다음 회고를 시작할 때 지난 Try를 "완료 / 진행 중 / 중단"으로 표시해 보세요.

이 예시에서는 스프린트 1에서 Try 3개 중 1개만 실행됐지만 스프린트 3부터 개수를 2개로 줄이자 모두 실행됐습니다. 이행률이 낮으면 Try를 더 늘리지 말고 담당자와 기한이 빠졌는지, 크기가 너무 크지 않은지부터 살펴보세요. 이 도구에는 이행 여부를 표시하는 기능이 없으므로 복사한 Try를 액션아이템 트래커에 옮겨 추적하는 방법이 있습니다.

좋은 Problem 한 줄을 쓰는 기준

• 관찰된 사실인가. "커뮤니케이션이 부족했다"보다 "스펙 변경이 개발 중간에야 공유됐다"가 낫습니다. 다른 사람이 같은 장면을 떠올릴 수 있어야 합니다.
• 상황이나 절차를 가리키는가. 사람을 주어로 쓰면 방어적인 대답을 부릅니다. "누가"보다 "어떤 절차가 없었는지"를 적습니다.
• 영향이 한 줄로 드러나는가. "리뷰가 밀려 배포가 하루 늦어짐"처럼 결과가 붙으면 우선순위를 정하기 쉽습니다. 다만 하루 같은 수치는 실제 겪은 것만 적으세요.
• 한 줄에 하나인가. 한 항목에 문제 두 개를 적으면 Try도 둘이 필요해지고 투표할 때도 섞입니다. 이 도구는 항목을 따로 추가하도록 만들어져 있으니 나누어 입력하세요.

원인이 분명하지 않은 Problem은 바로 Try로 넘어가지 말고 5 Whys 근본 원인 도구로 "왜"를 몇 번 되물어 본 뒤에 대응 행동을 정하세요.

보드를 읽는 법

• Problem은 많은데 Try가 적다: 문제를 나열만 하고 대응을 정하지 않았을 수 있습니다. 다 해결하려 하지 말고 영향이 가장 큰 1~3개에 Try를 붙이는 쪽이 현실적입니다.
• Try가 Problem보다 많다: 한 번에 너무 많이 바꾸려는 신호일 수 있습니다. 다음 스프린트에서 실제로 해낼 수 있는 개수(대개 2~3개)로 줄이세요.
• Keep이 비어 있다: 잘 되는 것을 말하지 않으면 개선하다 잘 되던 것까지 바꿔 버릴 수 있습니다. 한두 개라도 적어 두세요.
• 같은 Problem이 회고마다 반복된다: 이전 Try가 실행되지 않았거나 원인이 틀렸다는 뜻입니다. 새 Try를 늘리기 전에 지난 Try의 실행 여부부터 확인하세요.

흔한 실수

• Problem에 사람 이름을 적어 책임 추궁의 장이 되는 것. 상황과 구조로 바꿔 적으세요("A가 늦게 공유" 대신 "변경 공유 절차가 없음").
• 회고 후 Try를 아무도 추적하지 않는 것. 다음 회고 시작 때 지난 Try의 결과를 먼저 확인하는 것만으로도 효과가 달라집니다.
• 매번 같은 형식으로만 해서 지루해지는 것. 팀이 익숙해지면 Start/Stop/Continue 같은 다른 틀로 바꿔 보는 것도 방법입니다.
• 팀 리더가 먼저 길게 말하는 것. 적게 하고 마지막에 말하도록 하세요.

한계

KPT는 단순한 대신 문제의 근본 원인을 깊이 파고드는 장치가 없습니다. 장애처럼 원인 분석이 중요한 사건은 별도의 사후 분석 절차를 병행하는 것이 좋고, 팀 내 심리적 안전감이 낮으면 Problem 칸이 비어 형식적으로 끝날 수 있습니다. 이 도구는 항목을 쌓는 보드일 뿐 투표·담당자 지정·알림 기능이 없으며, 실시간 공동 편집도 지원하지 않습니다.

입력과 복사가 동작하는 방식

• 각 항목은 최대 200자까지 입력되고, 앞뒤 공백은 제거됩니다. 빈 입력은 추가되지 않고 안내 문구가 나옵니다.
• 같은 칸에 글자가 완전히 같은 항목이 이미 있으면 추가되지 않습니다. 다른 칸에는 같은 문장을 넣을 수 있습니다. 영문 대소문자나 공백 한 칸이 달라도 다른 항목으로 취급됩니다.
• 입력창에서 Enter 키를 누르면 해당 칸의 "추가" 버튼을 누른 것과 같습니다.
• 항목은 추가한 순서대로 쌓이며 순서를 바꾸거나 수정하는 기능은 없습니다. 고치려면 삭제(✕) 후 다시 추가하세요.
• "회고 내용 복사"는 ## Keep, ## Problem, ## Try 제목 아래에 항목을 - 목록으로 붙인 텍스트를 클립보드로 보냅니다. 비어 있는 칸은 "(없음)"으로 표시됩니다. 위키나 마크다운을 지원하는 문서에 붙여 넣으면 제목과 목록으로 보입니다.
• 항목이 하나라도 있어야 복사·초기화 버튼이 나타납니다. 조언 문구(Hint)는 Problem과 Try의 개수, Keep 유무를 비교해 자동으로 바뀌며 판단 기준은 이 페이지의 "보드를 읽는 법"과 같습니다.

입력한 데이터는 어디에 저장되나요?

보드의 모든 항목은 서버로 전송되지 않고 이 브라우저의 localStorage에만 저장됩니다. 다른 기기, 다른 브라우저, 팀원의 화면과는 동기화되지 않으니 회의에서는 진행자가 화면을 공유하며 입력하세요. 브라우저의 사이트 데이터를 지우거나 "보드 전체 초기화"를 누르면 삭제되므로, 남겨야 하는 회고는 "회고 내용 복사" 버튼으로 텍스트를 저장해 두세요.

함께 쓰면 좋은 도구

스프린트 속도를 돌아보려면 스프린트 벨로시티 계산기를, Try의 우선순위 정리는 아이젠하워 매트릭스를, 매일의 짧은 공유는 데일리 스탠드업 노트를 이용할 수 있습니다.

자주 묻는 질문