스프린트 회고가 매번 같은 말로 끝나는 이유

스프린트 회고가 매번 같은 말로 끝난다면, 팀이 성의가 없어서가 아닙니다. 회고라는 구조가 세 지점에서 새고 있어서입니다. 기억은 스프린트 마지막 사흘에 쏠리고, 논의는 팀이 스스로 바꿀 수 있는 범위 안에 갇히며, 어렵게 합의한 개선안은 스프린트 백로그 밖에 남습니다. 이 셋을 그대로 둔 채 회고 형식을 KPT에서 4Ls로 바꾸면, 칸의 이름만 바뀌고 붙는 문장은 그대로입니다.

12년 동안 여러 팀에서 회고를 진행하고 또 참여하면서 배운 것이 하나 있습니다. 진행 기법을 다듬는 것보다 이 세 개의 누수를 막는 쪽이 훨씬 큰 차이를 만듭니다. 같이 한 지점씩 짚어보겠습니다.

스프린트 회고는 효과가 없는 게 아니라 조건부입니다

먼저 전제를 하나 정리하고 시작하겠습니다. 회고 자체는 작동합니다.

태넌바움과 세라솔리는 팀 및 개인 디브리프를 다룬 46개 표본, 참여자 2,136명의 연구를 메타분석했습니다. 결과는 디브리프를 수행한 쪽이 통제 집단보다 평균 25퍼센트 높은 성과를 냈다는 것이었습니다. 감을 잡기 쉽게 바꿔 말하면, 회고를 제대로 하는 팀의 평균 성과가 하지 않는 팀들 가운데 상위 4분의 1 언저리에 놓인다는 뜻입니다. 이 차이는 팀이든 개인이든, 시뮬레이션이든 실제 현장이든, 의료든 비의료든 비슷하게 나타났습니다. 미군이 수십 년간 사후 검토를 운영해온 이유이기도 합니다.

여기서 눈여겨볼 대목은 결론 문장에 붙은 단서입니다. 연구진은 제대로 수행된 디브리프라는 조건을 달았고, 효과를 키우는 요인으로 참여자와 초점과 측정 수준의 정렬, 그리고 구조와 퍼실리테이션을 지목했습니다. 회고를 하느냐 마느냐의 문제가 아니라, 어떤 조건을 갖춘 회고냐의 문제라는 뜻입니다.

정렬, 구조, 퍼실리테이션. 이 세 단어를 실무 언어로 풀면 아래 세 개의 누수가 됩니다.

첫 번째 누수, 팀은 스프린트 전체가 아니라 마지막 사흘을 회고합니다

2주 스프린트를 끝내고 회고에 들어가면, 보드에 붙는 이야기의 무게중심은 대체로 마지막 며칠에 쏠립니다. 첫째 주 화요일에 무슨 일이 있었는지 정확히 기억하는 사람은 거의 없습니다.

이건 팀의 기억력 문제가 아니라 기억이 작동하는 방식입니다. 레델마이어와 카너먼은 실제 의료 시술을 받은 환자들의 기억을 추적해, 사람이 경험 전체를 합산해 기억하지 않는다는 것을 보였습니다. 기억은 정점과 마지막 순간으로 요약됩니다. 카너먼이 경험하는 자아와 기억하는 자아를 구분한 것도 같은 맥락입니다. 회고 테이블에 앉은 것은 경험하는 자아가 아니라 기억하는 자아입니다.

그래서 실제로는 스프린트 초반에 시작된 지연이 후반의 배포 소동으로만 기록됩니다. 원인은 앞에 있는데 증상만 회고되니, 같은 증상이 다음 스프린트에도 올라옵니다.

몇 년 전 모바일 인증 퍼널을 개선하던 때가 정확히 그랬습니다. 팀에서 모은 문제 목록은 대부분 마지막 제출 화면에 몰려 있었습니다. 민원이 그 화면에서 터졌으니 모두의 기억도 그쪽에 남아 있었습니다. 그런데 유저 문의 기록과 행동 로그를 퍼널 순서대로 펼쳐놓고 보니 이탈이 시작되는 지점은 훨씬 앞단이었습니다. 인증 버튼이 활성화되기까지 사용자가 기다려야 하는 시간이었습니다. 병목을 다섯 구간으로 쪼개 다시 정의하고 그중 대기 시간부터 하루짜리 스프린트로 처리했더니 최종 제출 완료율이 5퍼센트포인트 가까이 올라갔습니다. 회의실의 기억은 끝 장면을 가리켰고, 기록은 시작 지점을 가리켰습니다.

처방은 회고의 앞부분을 의견이 아니라 기록에 쓰는 것입니다. 에스더 더비와 다이애나 라슨은 회고를 다섯 단계로 정리하면서 자료 수집을 의견 형성보다 앞에 두었는데, 많은 팀이 이 단계를 5분짜리 형식으로 축소합니다. 티켓 상태 변경 시각, PR 머지 시각, 알림 채널의 사고 기록처럼 이미 남아 있는 흔적으로 스프린트 타임라인을 복원한 뒤에 감상을 얹으세요. 기억에만 의존하면 회고는 스프린트의 마지막 사흘을 반복해서 다루게 됩니다.

두 번째 누수, 팀은 자기가 바꿀 수 있는 것만 말합니다

같은 문장이 세 번 넘게 반복되는 항목이 있다면, 그 항목은 대개 팀 권한 밖에 있습니다.

크리스 아지리스는 조직의 학습을 두 종류로 나눴습니다. 단일 루프 학습은 온도조절기와 같습니다. 설정된 기준 안에서 행동만 조정합니다. 이중 루프 학습은 그 기준과 전제 자체를 의심합니다. 아지리스가 함께 지적한 것이 방어적 루틴인데, 당혹이나 위협을 피하려는 관행이 탐구를 미리 차단해버리는 현상입니다. 모두가 알지만 아무도 이름 붙이지 않는 주제가 조직마다 있고, 그 주제는 논의 불가 영역으로 남습니다.

회고에서 커뮤니케이션을 더 잘하자, 일정을 더 현실적으로 잡자 같은 문장이 되풀이되는 것은 이 때문입니다. 진짜 원인으로 한 걸음 더 들어가면 스프린트 길이, 요구사항이 들어오는 경로, 인력 배치처럼 그 방에서 결론 낼 수 없는 것들이 나옵니다. 팀은 무의식적으로 그 앞에서 멈추고, 자기 손으로 고칠 수 있는 범위 안에서 Try를 만듭니다. 단일 루프만 계속 도는 것입니다.

전사 인사 시스템을 새로 구축하던 프로젝트에서 저는 팀장을 맡았습니다. 요구사항은 거의 모든 부서에서 들어왔고 개발은 외주 팀과 함께 진행했습니다. 회고 때마다 Problem 칸에는 요구사항이 스프린트 중간에 들어온다는 문장이 붙었습니다. 매번의 대응은 변경 요청 시 사전에 공유하기였고, 매번 지켜지지 않았습니다. 팀이 약속을 어겨서가 아닙니다. 요청을 넣는 부서 담당자들이 그 회고 자리에 없었기 때문입니다.

그래서 보드에 네 번째 칸을 만들었습니다. 이름은 우리가 정할 수 없는 것이었습니다. 이 칸에 붙은 항목은 팀이 해결하지 않습니다. 누가 어디로 가져갈지만 정합니다. 저 문장은 제 이름으로 옮겨 적혔고, 부서별 요청 창구를 스프린트 계획 시점 하나로 좁히는 논의는 회고 밖에서 시작됐습니다. Problem 칸에서 그 문장이 사라지는 데 두 스프린트가 걸렸습니다.

논의 불가 항목을 없애는 것이 목표가 아닙니다. 주소를 붙이는 것이 목표입니다. 에이미 에드먼슨이 팀 학습 행동을 연구하며 보인 것처럼, 대인 관계의 위험이 감지되는 팀에서는 질문하고 오류를 꺼내는 행동 자체가 줄어듭니다. 어떤 주제에서만 반복적으로 침묵이 흐른다면 그것은 개인 성향이 아니라 팀이 입을 닫는 조건이 갖춰졌다는 신호입니다.

세 번째 누수, 개선안이 스프린트 백로그 밖에 있습니다

액션 아이템이 실행되지 않는 이유를 담당자와 기한이 없어서라고 진단하는 글이 많습니다. 담당자를 붙여도 대부분 실행되지 않습니다. 진짜 이유는 그 항목이 팀의 작업 목록 안에 없기 때문입니다.

스크럼 가이드는 이 지점을 이미 명시하고 있습니다. 회고에서 식별한 가장 임팩트 있는 개선사항은 가능한 한 빨리 다루며, 다음 스프린트의 스프린트 백로그에 추가될 수도 있다고 적혀 있습니다. 그리고 스프린트 백로그는 스프린트 목표와 선택된 항목, 인크리먼트를 전달하기 위한 실행 계획으로 정의됩니다. 회고 문서에만 적힌 개선안은 스프린트 계획 회의에서 존재하지 않는 항목입니다. 용량 계산에 들어가지 않으니 언제나 뒤로 밀립니다.

권하는 방식은 회고당 개선 항목을 하나로 제한하고, 그것을 백로그에 넣으면서 무엇을 뺄지 함께 정하는 것입니다. 개선 작업도 사람의 시간을 씁니다. 이 트레이드오프를 공개적으로 다루지 않으면 그 항목은 스프린트 중반에 조용히 밀려납니다. 무엇을 넣을지보다 무엇을 버릴지 정하는 일이 여기서도 먼저입니다.

한 가지 덧붙이면, 개선 항목을 쓸 때도 산출물이 아니라 변화로 적는 편이 낫습니다. 문서를 작성한다가 아니라 스프린트 중 스펙 변경이 발생한 티켓 수를 다음 스프린트에 확인한다처럼 씁니다. Key Result가 한 일의 목록이 아니어야 하는 것과 같은 이유입니다.

다음 회고에서 시간 배분부터 바꿔보세요

세 개의 누수는 사실 시간 배분에 그대로 드러납니다. 60분 회고를 기준으로 흔한 배분과 권하는 배분을 비교하면 이렇습니다.

의견 수집에서 20분을 떼어 타임라인 복원과 원인 해석에 나눠 붙이는 것이 핵심입니다. 대부분의 회고는 무엇이 있었는지를 말하는 데 시간을 다 쓰고, 왜 그랬는지를 해석하는 단계를 건너뛴 채 결정으로 넘어갑니다. 해석이 빠지면 결정은 증상에 붙습니다.

시작 5분에는 노먼 커스가 제안한 기본 규칙을 소리 내어 읽는 것을 권합니다. 참여자 모두가 그때 알고 있던 것, 가진 기술과 자원, 처한 상황 안에서 최선을 다했다고 전제한다는 문장입니다. 이 전제를 매번 확인하는 팀과 그렇지 않은 팀은 원인을 파고드는 깊이가 다릅니다. 장애를 다룰 때도 범인을 찾는 순간 학습이 멈추는 것과 같은 원리입니다.

흔히 빠지는 세 가지 함정

형식 교체로 해결하려는 것. KPT가 지겨워져서 4Ls로, 4Ls가 지겨워져서 돛단배 회고로 바꾸는 순환에 빠진 팀을 여러 번 봤습니다. 새 형식은 두 번쯤 신선하고 세 번째부터 원래대로 돌아갑니다. 칸 이름이 아니라 기억, 논의 범위, 실행 경로를 손대야 합니다.

액션 아이템을 여러 개 만드는 것. 다섯 개를 정하면 다섯 개 모두 실행되지 않습니다. 하나만 정하고 그 하나를 백로그에 넣는 편이 낫습니다. 회고의 성과는 도출한 개선안의 개수가 아니라 다음 스프린트에 실제로 들어간 항목의 개수로 봐야 합니다.

회고를 이슈 점검 회의로 바꾸는 것. 미해결 티켓을 하나씩 훑는 자리가 되면 해석 단계가 통째로 사라집니다. 티켓 점검은 다른 자리에서 하고, 회고에서는 그 티켓들이 왜 그 상태가 됐는지를 다루세요.

결론

회고에서 반복되는 문장은 팀의 한계가 아닙니다. 회고가 무엇을 기억하게 하고, 무엇을 논의 가능하게 하며, 결론을 어디에 두는지가 만들어낸 결과입니다. 질문을 어떻게 설계하느냐에 따라 답이 달라지는 것은 사용자 인터뷰만의 이야기가 아닙니다.

다음 회고에서 딱 하나만 바꾼다면 저는 마지막 것을 권합니다. 개선 항목 하나를 스프린트 백로그에 넣고, 그 자리를 만들기 위해 무엇을 뺄지 팀과 함께 정해보세요. 두 스프린트만 지나도 Problem 칸에 붙는 문장이 달라지기 시작합니다. 작은 실험 하나로는 충분합니다.

참고 자료

• Tannenbaum, S. I. & Cerasoli, C. P. (2013). Do Team and Individual Debriefs Enhance Performance? A Meta-Analysis. Human Factors, 55(2), 231–245.
• Argyris, C. & Schön, D. A. (1978). Organizational Learning: A Theory of Action Perspective. Addison-Wesley.
• Argyris, C. (1991). Teaching Smart People How to Learn. Harvard Business Review, 69(3).
• Redelmeier, D. A. & Kahneman, D. (1996). Patients’ Memories of Painful Medical Treatments. Pain, 66(1).
• Schwaber, K. & Sutherland, J. (2020). The Scrum Guide.
• Esther Derby & Diana Larsen, 『Agile Retrospectives: Making Good Teams Great』 (2006).
• Norman L. Kerth, 『Project Retrospectives: A Handbook for Team Reviews』 (2001).
• Edmondson, A. C. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, 44(2).