85. 애자일 회고(Retrospective) 제대로 하는 법

애자일 스프린트를 마무리하면 항상 따라오는 시간, 바로 회고(Retrospective)다.
 
하지만 실무에서는 이런 반응이 많다.

“그냥 다들 조용히 앉아만 있어요…”

“칭찬만 하다가 끝나요.”

“문제는 뻔한데, 해결은 늘 다음에.”

 
회고는 단순한 피드백 시간이 아니라, 팀이 성장하는 구조를 설계하는 핵심 루틴이다. 이번 글에서는 애자일 회고의 개념, 목적, 잘하는 방법, 실무 팁까지 모두 정리해본다.

 
1. 회고란 무엇인가?
회고(Retrospective)는 하나의 스프린트(반복 주기)가 끝난 후 “무엇이 잘 되었고, 무엇을 개선할 수 있는가”를 팀이 함께 돌아보는 시간이다.

회고 = 정답을 찾는 시간이 아니라,
다음 스프린트를 더 잘하기 위한 설계 시간이다.

 
 
2. 회고의 핵심 목적

목적	설명
팀 내 정서 확인	일정·협업·개발 흐름 등 문제점 공유
구조적 개선 도출	반복되는 이슈를 ‘프로세스 관점’에서 개선
팀워크 강화	비난이 아닌, ‘함께 해결’하는 분위기 형성

 
3. 회고를 잘 못하는 팀의 특징

• 모든 말이 ‘좋았어요’로 끝남
• 조용히 회의만 하다 아무런 액션 없이 마무리
• 문제 제기는 있는데, 실행계획이 없음
• 특정 팀만 말하고 다른 팀은 침묵
• 담당자 언급 없이 ‘나중에 보죠’로 끝남

4.실무에서 회고 잘하는 방법

• 프레임워크를 도입하자
  • [Keep / Problem / Try]
  • [Liked / Learned / Lacked / Longed for]
  • [Glad / Sad / Mad]

→ 포스트잇 or Miro, FigJam, Notion 보드 등으로 시각화

• 모든 팀원이 말할 수 있게 분위기 조성
  • 질문 예시:
    • “이번 스프린트에서 가장 아쉬웠던 지점은요?”
    • “다음엔 어떤 식으로 바꿔보면 좋을까요?”
• 행동 가능한 개선안으로 끝내기
  • “개발팀 QA 리소스 부족” → QA 체크리스트 만들기로
  • “기획안 공유 시점이 너무 늦음” → 공유 마감일 캘린더화
• 익명 회고도 고민해보기
  • 분위기가 경직된 팀이라면, 익명 수렴 + 공유 구조 활용
• 액션 아이템을 다음 스프린트 백로그에 등록 → 회고 = 끝이 아니라 다음 스프린트의 시작

실무에서 바로 써먹는 회고 템플릿 예시
 
🟢 Keep  

• 매일 데일리 미팅이 빠르게 진행되어 좋았다.  
• 업무 공유용 노션 정리가 유용했다.

🔴 Problem  

• 기획서 전달 시점이 너무 늦었다.  
• QA 리소스 부족으로 릴리즈 전 버그 발견이 늦어졌다.

🟡 Try  

• 다음 스프린트부터 기획서 공유 마감일 사전 조율  
• QA 체크리스트 항목 정리해서 공유

마무리 요약
 
애자일 회고는 업무 비판의 시간이 아니라, 팀이 같이 성장하는 구조를 만드는 시간이다. 분위기, 프레임워크, 액션 정리까지 함께할 때 비로소 의미가 있다. 매 회고마다 단 1가지라도 바뀐다면 그 팀은 이미 애자일하게 성장 중이다.