💡 핵심 인사이트
스프린트 회고는 2주간의 개발 주기가 끝난 후, 제품의 결과물을 평가하는 '리뷰'와 달리 개발팀 내부적으로 "우리들의 일하는 방식(프로세스, 팀워크)에 문제가 없었는가?"를 반성하고 개선점을 찾는 비공개 성찰의 시간입니다.
애자일이 끊임없이 진화하는 학습 조직을 만들어내는 가장 강력한 엔진입니다.

Ⅰ. 스프린트 회고의 목적 (지속적 개선, KAIZEN)

"바쁘니까 이번 회고는 건너뛰고 바로 다음 개발 시작합시다." ➔ 애자일이 망하는 지름길입니다. 도끼로 나무를 베다가 도끼날이 무뎌졌는데, 시간 없다고 무뎌진 도끼로 계속 나무를 치는 것과 같습니다. 회고는 잠시 멈춰 서서 팀의 **'도끼날을 가는 시간'**입니다.

• 대상: 철저히 팀 내부의 문제 (도구의 불편함, 커뮤니케이션 오류, 그라운드 룰 위반 등).
• 참석자: 스크럼 마스터(SM), 제품 책임자(PO), 개발팀. (외부 임원이나 고객은 절대 참석 금지).
• 결과물: 다음 스프린트에 당장 적용할 수 있는 **1~2개의 구체적이고 실천 가능한 개선 액션 아이템(Action Item)**을 도출합니다.

Ⅱ. 회고의 3가지 핵심 질문 (KPT / 4L 기법)

회고를 진행할 때 화이트보드에 포스트잇을 붙이며 팀원들의 솔직한 의견을 끌어냅니다. 가장 널리 쓰이는 프레임워크는 KPT입니다.

1. Keep (유지할 점): 이번 스프린트에서 우리가 잘한 점, 다음에도 계속 이렇게 했으면 좋겠는 점.
   • "코드 리뷰를 당일 오후 4시에 다 같이 모여서 하니까 버그가 줄고 너무 좋았어요!"
2. Problem (문제점): 아쉬웠던 점, 팀을 힘들게 했던 장벽이나 실수.
   • "DB 스키마가 중간에 자꾸 바뀌어서 프론트엔드 작업이 3번이나 엎어졌어요."
3. Try (시도할 점 / 해결책): Problem을 해결하기 위해 다음 스프린트에서 새롭게 도입해 볼 구체적인 행동.
   • "다음 스프린트부터는 무조건 첫날 오전에 DB 설계부터 완벽히 픽스(Fix)하고 넘어가기로 룰을 정합시다!"

(이 외에도 Liked(좋았던 것), Learned(배운 것), Lacked(부족했던 것), Longed for(바라는 것)를 적는 4L 기법도 있습니다.)

Ⅲ. 회고의 절대 룰: 노 블레임 문화 (No Blame Culture)

회고 시간이 누군가를 공개 처형하고 마녀 사냥하는 질책의 자리가 되는 순간, 팀원들은 입을 닫고 방어적으로 변합니다.

노만 커스(Norman Kerth)의 회고 프라임 디렉티브 (Prime Directive)

• "우리가 어떤 문제점을 발견하든, 그 당시에는 각자가 가진 지식과 기술, 그리고 주어진 상황 속에서 최선을 다해 결정을 내렸음을 우리는 진심으로 믿는다."
• 즉, 사람을 공격하지 말고 시스템(프로세스)을 공격하라는 뜻입니다. "철수가 게을러서 코딩을 늦게 했어"가 아니라, "테스트 환경 구축 절차가 복잡해서 개발 시간이 뺏겼다, 이를 자동화하자"로 결론이 나야 합니다.

📢 섹션 요약 비유: 스프린트 회고는 군대의 **'작전 후 디브리핑(AAR)'**입니다. 전투(스프린트)가 끝나면 지휘관과 병사들이 계급장을 떼고 모여 앉아, "이등병 네가 수류탄을 늦게 던졌어!"라고 싸우는 게 아니라, "무전기가 안 터져서 신호가 늦었으니, 내일 전투부터는 무전기 배터리를 2개씩 챙겨 나가자"라고 시스템의 결함을 보수하는 시간입니다.