스프린트 회고(Sprint Retrospective)란 무엇인가: 실행 항목 절반만 끝나는 이유와 KPT·4Ls 실전 가이드

스프린트 회고는 왜 매번 하는데도 팀이 바뀌지 않을까

결론부터 말하면, 스프린트 회고(Sprint Retrospective)의 문제는 회의 자체가 아니라 회의 이후에 있습니다. 2026년 State of Team Alignment 조사에서 엔지니어·PM 419명 중 61%는 회고가 개선점을 찾는 데 효과적이라고 답했지만, 그 자리에서 정한 실행 항목이 다음 회고 전에 완료되는 비율의 중앙값은 50%에 그쳤습니다. 절반은 늘 남습니다. 회고의 성패는 KPT나 4Ls 같은 포맷을 얼마나 잘 고르느냐보다 실행 항목에 소유자·기한·추적 수단이 붙어 있느냐로 갈리는데요. 이 글은 스크럼 가이드가 정의한 회고의 목적부터 포맷 비교, 실행 격차의 원인 5가지, 그리고 회고를 팀의 실제 변화로 연결하는 4단계를 정리합니다.

금요일 오후 4시, 회고를 12번 돌려본 이야기
스프린트 회고란 무엇인가: 스크럼 가이드의 정의와 타임박스
회고는 다들 하는데 왜 절반만 실행될까: 데이터가 보여주는 격차
KPT·4Ls·세일보트: 회고 포맷 4가지 비교와 고르는 기준
실행 항목을 끝까지 가져가는 법: 소유자·기한·추적
실전 가이드: 회고를 처음 도입하는 팀의 4단계
FAQ
같이 읽으면 좋은 것들

금요일 오후 4시, 회고를 12번 돌려본 이야기

2년 전 자문을 맡았던 한 커머스 회사의 주문 플랫폼 팀 이야기입니다. 개발자 7명, 기획자 2명, 디자이너 1명이 2주 스프린트를 돌린지 반년쯤 된 팀이었습니다. 격주 금요일 오후 4시 회고를 처음 참관했을 때 화이트보드에는 지난 회고의 Try 항목이 그대로 남아 있었습니다. "배포 전 체크리스트 만들기", "QA 요청은 수요일까지". 두 항목 모두 6주째 그대로였습니다.

회고 자체는 나쁘지 않았습니다. 다들 솔직했고 분위기도 좋았습니다. 문제는 회고가 끝나는 순간 모든 것이 끝난다는 점이었습니다. 실행 항목의 소유자가 없었고, 지라(Jira)에도 올라가지 않았고, 다음 회고에서 지난 항목을 확인하는 순서도 없었습니다. 팀장 한 분의 말이 기억납니다. "회고는 잘 하는데, 그래서 뭐가 달라졌는지 물으면 대답을 못 하겠어요."

그래서 세 가지만 바꿨습니다. 첫째, Try는 투표로 최대 2개만 고른다. 둘째, 각 항목에 이름과 완료 기준을 적고 스프린트 백로그에 티켓으로 넣는다. 셋째, 다음 회고의 첫 10분은 반드시 지난 항목의 상태 확인으로 시작한다. 12번째 회고를 마쳤을 때 이 팀의 실행 항목 완료율은 처음 3번 평균 33%에서 마지막 3번 평균 83%로 올라갔고, 배포 사고는 스프린트당 1.4건에서 0.5건으로 줄었습니다. 새 도구도, 새 포맷도 없었습니다. 회고 뒤의 빈 구간을 채웠을뿐입니다. 회고를 어떻게 진행하느냐에 관한 자료는 많지만, 회고와 다음 회고 사이의 2주를 어떻게 설계하느냐를 다루는 자료는 드뭅니다.

스프린트 회고란 무엇인가: 스크럼 가이드의 정의와 타임박스

한 줄로 요약하면, 스프린트 회고는 제품이 아니라 일하는 방식을 점검하는 스크럼의 마지막 이벤트입니다.

스크럼 가이드(Scrum Guide)는 회고의 목적을 "품질과 효과성을 높일 방법을 계획하는 것"이라고 정의합니다. 점검 대상은 다섯 가지로 명시돼 있는데요. 개인, 상호작용, 프로세스, 도구, 그리고 완료의 정의(Definition of Done)입니다. 팀은 지난 스프린트에서 무엇이 잘됐고 어떤 문제가 있었으며 그 문제가 어떻게 해결됐는지(혹은 해결되지 않았는지)를 이야기하고, 가장 영향력이 큰 개선안을 가능한 한 빨리, 필요하면 다음 스프린트 백로그에 넣어 실행합니다.

타임박스는 1개월 스프린트 기준 최대 3시간, 2주 스프린트라면 보통 60~90분입니다. 시간이 길다고 좋은 회고가 되지는 않고, 90분을 넘기면 후반부 논의의 밀도가 눈에 띄게 떨어집니다.

스프린트 리뷰와 회고의 차이

리뷰는 "무엇을 만들었는가"를 이해관계자와 확인하는 자리고, 회고는 "어떻게 만들었는가"를 팀끼리 돌아보는 자리입니다.

구분	스프린트 리뷰	스프린트 회고
점검 대상	인크리먼트(산출물)	개인·상호작용·프로세스·도구·완료의 정의
참석자	스크럼 팀 + 이해관계자	스크럼 팀만
질문	목표에 얼마나 다가갔는가	다음엔 무엇을 다르게 할 것인가
결과물	조정된 프로덕트 백로그	실행 항목(다음 스프린트 백로그에 반영)
순서	스프린트 후반	리뷰 직후, 스프린트의 마지막

심리적 안전이 전제 조건인 이유

노먼 커스(Norm Kerth)의 최우선 지침(Prime Directive)은 "당시 알고 있던 것과 가진 자원, 상황을 고려할 때 모두가 최선을 다했다고 믿는다"는 문장으로 시작합니다. 회고가 책임 추궁의 자리가 되면 사람들은 문제를 말하지 않고, 말하지 않는 문제는 고칠 수 없습니다. 2025년 Milani 등의 연구도 실무자 19명을 조사해 회고에서 데이터 활용을 가로막는 첫 번째 장벽으로 심리적 안전 문제를 꼽았습니다.

회고는 다들 하는데 왜 절반만 실행될까: 데이터가 보여주는 격차

핵심은 이것입니다. 회고의 병목은 "찾기"가 아니라 "끝내기"에 있습니다.

Parabol이 정리한 애자일 통계에 따르면 스크럼 알라이언스(Scrum Alliance) 조사에서 스크럼 팀의 81%가 매 스프린트 후 회고를 진행합니다. 같은 자료에 인용된 CA Technologies 분석에서는 정기적으로 회고를 하는 팀이 대응성(responsiveness)이 24%, 품질은 42% 높았습니다.

그런데 2026년 State of Team Alignment 조사를 보면 그림이 달라집니다.

지표	수치
회고가 개선점 발굴에 "매우·극도로" 효과적이라는 응답	61%
다음 회고 전 실행 항목 완료율(중앙값)	50%
발굴한 개선안의 60% 미만만 실행하는 팀	70%
팀 통제 범위 밖의 변경이 필요한 항목	29%
스프린트 계획에서 끝내 우선순위를 못 받은 항목	21%
책임자가 지정되지 않은 항목	17%
너무 모호해 실행할 수 없는 항목	15%
추적 수단이 전혀 없는 항목	13%

개선점은 잘 찾는데(61%) 실행은 절반(50%)에서 멈춥니다. 원인 분포가 흥미로운데요. 가장 큰 29%는 다른 부서 협조나 예산처럼 팀이 혼자 바꿀 수 없는 문제입니다. 나머지 21%·17%·15%·13%는 우선순위, 소유자, 구체성, 추적이라는 팀 안의 운영 문제이고 합치면 66%입니다. 실행 격차의 3분의 2는 회고 설계만 바꿔도 줄일 수 있다는 뜻입니다.

Easy Agile이 인용한 PMI 커뮤니티 조사는 더 극단적입니다. 응답자의 거의 3분의 2가 회고 아이디어의 25% 미만만 실행했고, 75%를 넘긴 응답자는 없었습니다.

데이터 없는 회고의 한계

Milani 등의 연구는 또 다른 격차를 지적합니다. 팀들은 사이클 타임, 배포 빈도, 버그 수를 늘 수집하면서도 회고에서는 거의 쓰지 않고 기억과 인상에 의존한다는 것입니다. "이번 스프린트는 유난히 힘들었다"는 느낌과 "리드 타임이 1.8일 늘었다"는 사실은 대화의 방향을 완전히 다르게 만듭니다. 이 부분은 데이터 기반 의사결정(DDDM) 글에서 다룬 HiPPO 문제와 정확히 같은 구조입니다. 목소리 큰 사람의 인상이 데이터를 이깁니다.

KPT·4Ls·세일보트: 회고 포맷 4가지 비교와 고르는 기준

한 줄로 요약하면, 포맷은 대화를 여는 열쇠일 뿐이고 어떤 포맷이든 마지막은 실행 항목으로 닫혀야 합니다.

포맷	질문 구조	잘 맞는 상황	주의점
KPT	Keep · Problem · Try	국내 개발팀 표준, 격주 정기 회고	Try가 추상적으로 흐르기 쉬움
4Ls	Liked · Learned · Lacked · Longed for	장기 프로젝트 중간, 학습 공유	감정 공유가 많아 실행 항목 도출에 별도 시간 필요
Start/Stop/Continue	시작할 것 · 멈출 것 · 계속할 것	신규 팀, 회고 입문	단순해서 깊은 원인 분석은 약함
세일보트	바람(추진력) · 닻(방해) · 암초(위험) · 섬(목표)	분기 단위 큰 회고, 리스크 점검	준비 시간이 길고 퍼실리테이터 필요

우아한형제들의 KPT 운영 방식

국내 사례로는 우아한형제들 기술블로그에 소개된 팀이 좋은 참고가 됩니다. 이 팀은 2주 스프린트를 돌리며 월요일에 플래닝, 금요일에 회고를 하고, 스프린트 마지막 날 KPT를 진행합니다. 눈여겨볼 지점은 두 가지입니다. 첫째, Try를 전부 실행하지 않고 투표로 2~3개만 Action Item으로 선정합니다. 둘째, "소통을 잘하자" 같은 추상적 Try는 금지하고 실행 가능한 수단까지 적어야 합니다.

그 결과로 만들어진 문화가 구체적입니다. 반복되는 질문을 줄이려고 가격 변수명을 명확히 하고 "왜"를 코드 주석과 테스트에 남겼고, 재택근무 중 소통 문제는 쓰레드 첫 문장에 대화 목적을 밝히는 규칙으로 풀었습니다. 커버리지가 떨어지면 빌드가 실패하도록 젠킨스와 소나큐브를 연동한 것도 회고에서 나온 Try였습니다. 모두 "무엇을, 어떻게"까지 내려간 항목들입니다.

포맷을 고르는 기준

포맷은 팀 상태에 맞춰 바꾸는편이 낫습니다. 같은 KPT를 20번 반복하면 답변이 패턴화되고 회고 피로가 옵니다. 다만 어떤 포맷이든 마지막 15분은 같아야 합니다. 후보를 모으고, 투표로 1~2개를 고르고, 소유자와 완료 기준을 붙이는 것입니다.

실행 항목을 끝까지 가져가는 법: 소유자·기한·추적

한 줄로 요약하면, 실행 항목은 회고의 산출물이 아니라 다음 스프린트의 업무로 취급해야 끝납니다.

Easy Agile은 실행 항목이 죽는 원인을 다섯 가지로 정리합니다. 소유자가 없다, 기한이 없다, 결과가 모호하다("소통 개선"), 항목이 너무 많다, 눈에 보이지 않는다. 앞서 본 2026년 조사의 21%·17%·15%·13%와 겹치는 목록입니다.

실행 항목 작성 규칙

좋은 실행 항목은 티켓과 같은 형태를 갖춥니다.

한 사람의 이름: "백엔드 팀"이 아니라 "김OO". 팀 단위 소유자는 소유자가 없는 것과 같습니다.
완료 기준: "배포 프로세스 개선"이 아니라 "체크리스트 8개 항목을 위키에 올리고 다음 배포 2회에 적용".
기한: 기본값은 다음 회고 전. 못 끝내면 항목을 쪼개거나 팀 밖 의존성으로 뺍니다.
위치: 팀이 매일 보는 스프린트 보드에 다른 티켓과 나란히 놓습니다.

Easy Agile의 자체 사용 데이터에서는 실행 항목 추적 기능을 도입한 뒤 완료율이 40~50%에서 65%로 올라갔습니다. 앞서 소개한 커머스 팀의 33%에서 83%로의 변화도 같은 원리였습니다. 항목을 어디에 두느냐가 항목이 끝나느냐를 결정합니다.

팀 밖 의존성 항목의 처리

29%를 차지하는 팀 통제 밖 항목은 팀 실행 항목과 섞어두면 완료율이 구조적으로 낮아지고, 팀은 "해도 안 되네"라는 학습을 하게 됩니다. 저는 이 항목들을 별도 열에 모아 팀장이 조직 차원으로 올리는 "에스컬레이션 목록"으로 관리하도록 권합니다. 분기에 한 번 경영진과 검토하면 회고가 조직 개선의 입력값이 됩니다.

회고의 건강을 재는 지표 4가지

Easy Agile이 권하는 지표는 실행 항목 완료율(목표 80~100%), 반복 이슈 비율, 미완료 항목의 평균 나이, 회고 참여율입니다. 이 중 반복 이슈 비율이 특히 유용한데요. 같은 Problem이 세 번 연속 올라온다면 실행 항목 설계가 잘못됐거나 팀 밖 문제를 팀 안에서 풀려 하고 있다는 신호입니다.

실전 가이드: 회고를 처음 도입하는 팀의 4단계

한 줄로 요약하면, 첫 회고부터 완벽할 필요는 없지만 첫 회고부터 지난 항목 확인 순서는 있어야 합니다.

1단계: 첫 10분을 지난 항목 확인에 고정한다

가장 먼저 넣을 것은 새 포맷이 아니라 지난 실행 항목의 상태 점검입니다. 완료·진행·미착수를 소유자가 직접 말하고, 미착수 항목은 다시 가져갈지, 버릴지, 팀 밖 목록으로 보낼지를 결정합니다. 이 10분이 회고를 일회성 대화에서 연속된 개선 루프로 바꿉니다.

2단계: 데이터 한 장을 준비한다

퍼실리테이러는 회고 전에 계획 대비 완료 스토리 수, 이월 티켓 수, 배포와 롤백 횟수, 사이클 타임을 한 장으로 정리합니다. 2026년 조사에서 80%의 팀이 미완료 작업을 정기적으로 다음 스프린트로 넘긴다고 답했는데요. 이월이 습관이 된 팀일수록 숫자로 시작하는 회고가 필요합니다. 남 탓이 줄고 원인 분석이 빨라집니다.

3단계: 포맷으로 발산하고 투표로 수렴한다

KPT든 4Ls든 15~25분 동안 각자 적고, 비슷한 것끼리 묶고, 3표씩 투표해 상위 1~2개만 후보로 올립니다. 항목이 3개를 넘으면 완료율이 떨어집니다. 처음 도입하는 팀은 Start/Stop/Continue로 시작해 3~4회 뒤 KPT로 넘어가는 편이 부담이 적습니다.

4단계: 티켓으로 만들고 스프린트 보드에 올린다

선정된 항목은 그 자리에서 이름, 완료 기준, 기한을 붙여 스프린트 백로그에 티켓으로 등록합니다. "나중에 정리해서 올리겠다"는 말이 나오는 순간 그 항목은 절반의 확률로 사라집니다. 스크럼 가이드가 개선안을 다음 스프린트 백로그에 넣을수 있다고 명시한 이유가 여기에 있습니다. 회고의 산출물은 회의록이 아니라 백로그 아이템입니다.

이 4단계는 애자일 경영 개론에서 다룬 스크럼 도입 가이드의 마지막 조각입니다. 분기 단위로 목표를 관리하는 팀이라면 OKR 운영 가이드의 체크인 리듬과 회고 주기를 맞추면 실행 항목이 핵심 결과와 연결되어 우선순위를 받기 쉬워집니다.

FAQ

스프린트 회고는 몇 분이 적당한가요?

스크럼 가이드 기준 1개월 스프린트는 최대 3시간, 2주 스프린트는 통상 60\~90분입니다. 처음 도입하는 팀은 45분으로 시작해 지난 항목 확인 10분, 발산 20분, 투표 10분, 실행 항목 작성 5분으로 배분하는 것을 권합니다.

회고에서 나온 실행 항목은 몇 개가 적당한가요?

1\~2개, 많아도 3개입니다. 우아한형제들 팀은 투표로 2\~3개만 Action Item으로 선정하고, Easy Agile도 영향·노력 매트릭스로 1\~2개를 고르라고 권합니다. 2026년 조사에서 실행 항목 완료율 중앙값이 50%였던 배경에는 항목 과다도 있습니다. 적게 골라 확실히 끝내는 편이 낫습니다.

개발팀이 아닌 마케팅·CS·기획 팀도 스프린트 회고를 할 수 있나요?

가능합니다. 회고의 점검 대상은 코드가 아니라 개인·상호작용·프로세스·도구입니다. 캠페인 단위나 월간 리포트 주기를 스프린트로 삼으면 되고, 사이클 타임 대신 처리 건수·응답 시간·재작업 횟수를 "데이터 한 장"으로 쓰면 됩니다.

회고를 하면 실제로 성과가 좋아지나요?

CA Technologies 분석에서 정기적으로 회고를 하는 팀은 대응성이 24%, 품질이 42% 높았습니다. 다만 이 효과는 실행 항목이 완료될 때 나타납니다. 항목을 끝내지 않는 팀은 "회고는 시간 낭비"라는 냉소를 얻게 되므로 회고 도입과 실행 항목 추적은 함께 설계해야 합니다.

팀 밖에서 해결해야 하는 문제가 회고에 계속 올라옵니다. 어떻게 하나요?

2026년 조사에서 실행 항목의 29%가 팀 통제 밖의 변경을 필요로 했습니다. 이런 항목은 팀 실행 항목과 분리해 에스컬레이션 목록으로 관리하고, 스크럼 마스터나 팀장이 조직 차원에 올리는 것이 맞습니다.