소프트웨어 공학 100 주제 시리즈의 68번째 글이다. (카테고리: 프로세스와 방법론)

한 줄 요약

회고는 “좋았던 점·아쉬운 점” 을 적는 회의가 아니라 팀이 자기 일하는 방식을 실험 대상으로 다루는 정기 절차다. 산출물은 포스트잇 더미가 아니라 다음 주기에 실제로 해 볼 작은 실험 한두 개와, 지난번 실험의 결과다.

왜 필요한가

다른 프로세스 실천은 대부분 제품을 개선한다. 테스트는 코드를, 리뷰는 설계를, 데모는 기능 방향을 고친다. 그런데 프로세스 자체는 누가 고치는가?

회고가 없거나 형식만 남은 팀에서는 이런 일이 생긴다.

  • 같은 문제가 분기마다 반복된다. “리뷰가 너무 오래 걸린다” 는 말이 세 번째 회고에도 나온다.
  • 개선 아이디어가 나오지만 아무도 맡지 않는다. 회고가 불만 해소 시간이 된다.
  • 반대로 관리자가 프로세스를 위에서 바꾸고, 팀은 왜 바뀌는지 모른 채 따른다. 맞지 않는 규칙이 쌓인다.

애자일 선언의 원칙 열두 번째는 이것을 정면으로 다룬다. “팀은 정기적으로 어떻게 하면 더 효과적일 수 있을지 돌아보고, 그에 따라 자기 행동을 조율하고 조정한다.” 프로세스를 고치는 주체가 팀 자신이고, 그것이 정기적이라는 두 가지가 핵심이다.

핵심 개념

계보

Agile Alliance 용어집은 회고의 역사를 이렇게 정리한다.

시기 사건
1993~1997 Alistair Cockburn 이 초기 프로젝트에서 이 실천을 비공식적으로 기록 (“증분으로 일하고, 매 증분 뒤에 초점을 맞춰라”)
2001 Norm Kerth 의 책 Project Retrospectives 가 “디브리핑”, “포스트모템” 같은 덜 긍정적인 말 대신 “회고” 라는 용어를 널리 알림
2001 애자일 선언 원칙에 정기적 성찰이 들어감
2006 Esther Derby 와 Diana Larsen 의 Agile Retrospectives 가 구조화된 형식을 정립

용어집은 이렇게 반복 주기마다 여는 회고를 “하트비트 회고(heartbeat retrospective)” 라 부르고, 대개 진행자가 이끄는 1~3시간짜리 회의로 설명한다. 프로젝트 끝에 한 번 하는 회고와 구분하는 말이다. 한 번의 큰 회고는 다음 프로젝트에야 쓸모가 있지만, 하트비트 회고는 같은 프로젝트 안에서 바로 효과를 본다.

스크럼에서의 위치

스크럼 가이드(2020)의 스프린트 회고 절은 짧지만 정확하다.

  • 목적: 품질과 효과성을 높일 방법을 계획한다.
  • 범위: 개인, 상호작용, 프로세스, 도구, 그리고 완료의 정의(Definition of Done).
  • 질문: 무엇이 잘됐는지, 어떤 문제를 만났는지, 그 문제가 어떻게 해결됐는지(혹은 안 됐는지). 그리고 팀을 엇나가게 한 가정을 찾아 그 기원을 살핀다.
  • 결과: 가장 영향이 큰 개선은 최대한 빨리 다루며, 다음 스프린트 백로그에 넣을 수도 있다.
  • 타임박스: 한 달 스프린트에 최대 3시간, 더 짧은 스프린트면 대개 더 짧다.

“완료의 정의” 가 점검 대상이라는 점이 중요하다. 회고는 팀의 품질 기준을 스스로 올리는 자리이기도 하다.

다섯 단계 구조

Derby 와 Larsen 의 틀은 2024년 2판(Agile Retrospectives, Second Edition, Derby·Larsen·Horowitz)에서도 그대로 다섯 단계다.

 1. 무대 만들기    ─ 목적·시간 확인, 모두가 한마디씩 (발언의 문을 연다)
 (Set the Stage)
 2. 데이터 모으기  ─ 사실과 느낌을 모은다: 타임라인, 지표, 사건
 (Gather Data)
 3. 통찰 만들기    ─ 왜 그랬나: 패턴, 근본 원인, 연결
 (Generate Insights)
 4. 할 일 정하기   ─ 다음 주기에 해 볼 실험 1~2개, 담당자와 확인 방법
 (Decide What to Do)
 5. 마무리       ─ 결정 요약, 회고 자체에 대한 짧은 피드백
 (Close the Retrospective)

형식이 망가지는 곳은 대개 2와 3이다. 데이터 없이 바로 원인을 논하면 목소리 큰 사람의 기억이 사실이 된다. 통찰 없이 바로 할 일로 가면 증상만 치료한다.

프라임 디렉티브

Kerth 의 Project Retrospectives: A Handbook for Team Reviews(Dorset House, 2001)에 나오는 이 문장은 많은 회고의 첫머리에 낭독된다.

무엇을 발견하든, 우리는 모든 사람이 그때 알고 있던 것, 자신의 기술과 능력, 사용할 수 있던 자원, 그리고 주어진 상황에서 할 수 있는 최선을 다했다는 것을 이해하고 진심으로 믿는다.

이것은 “아무도 잘못하지 않았다” 는 면죄가 아니다. 탐구의 초점을 사람에서 조건으로 옮기라는 지시다. Google SRE 책의 비난 없는 사후 검토가 “사고에 관련된 모든 사람이 좋은 의도를 갖고, 가진 정보로 옳은 일을 했다고 가정한다” 고 쓰는 것과 같은 사고방식이다.

회고와 사후 검토

  정기 회고 사고 사후 검토
계기 시간 (매 반복) 사건 (장애, 데이터 손실 등)
범위 팀의 일하는 방식 전반 특정 사고의 원인과 대응
산출물 다음 주기 실험 1~2개 문서화된 사고 기록, 후속 조치
공통 원칙 비난 없음, 사실 기반, 조치 추적 같음

Google SRE 책은 사후 검토를 “사고, 영향, 완화·해결 조치, 근본 원인, 재발 방지 후속 조치를 담은 기록” 으로 정의한다. 정기 회고에서 “이번 스프린트의 장애 사후 검토 후속 조치가 실제로 끝났는가” 를 확인하면 두 장치가 연결된다.

실무 적용

60분 회고 진행안 (2주 스프린트)

 0:00  무대 만들기 (5분)
       - 프라임 디렉티브 읽기
       - 한 단어 체크인: "이번 스프린트를 날씨로 표현하면?"
 0:05  지난 실험 확인 (5분)
       - 지난 회고의 실험 2개: 했나? 결과는? 유지/폐기/수정?
 0:10  데이터 모으기 (15분)
       - 스프린트 타임라인에 사건 붙이기 (배포, 장애, 요구 변경, 휴가)
       - 지표 한 장: 사이클 타임, 리뷰 대기 시간, 이월된 항목 수
 0:25  통찰 만들기 (15분)
       - 점 투표로 주제 1~2개 선택
       - 선택한 주제에 "왜?" 를 여러 번 (사람이 아니라 조건을 향해)
 0:40  할 일 정하기 (15분)
       - 실험 형식으로: "우리는 ___ 를 해 볼 것이다.
         ___ 가 ___ 만큼 바뀌면 성공으로 본다. 담당: ___"
 0:55  마무리 (5분)
       - 이 회고는 쓸모 있었나? (1~5점)

실험 카드 템플릿

experiment:
  problem: "PR 리뷰 대기가 길어 항목이 리뷰 열에 평균 2일 머문다"
  hypothesis: "오전 스탠드업 직후 30분을 리뷰 시간으로 고정하면 대기가 준다"
  action: "다음 스프린트 동안 매일 10:00-10:30 리뷰 블록"
  measure: "리뷰 열 체류 시간 중앙값"
  success: "1일 미만"
  owner: "팀 전체, 확인 담당 민지"
  review_at: "다음 회고 첫 5분"

실험이라는 틀이 중요하다. 결과가 나쁘면 되돌리면 된다. “규칙” 으로 정하면 실패해도 아무도 되돌리지 않는다.

형식을 바꿔 가며

같은 형식을 반복하면 답도 반복된다. 주제에 맞게 고른다.

상황 형식
일상적 스프린트 계속/중단/시작 (Start·Stop·Continue)
큰 사건이 있었던 주기 타임라인 + 감정 곡선
같은 문제가 반복 근본 원인 분석 (5 Whys, 인과 다이어그램)
분기·릴리스 단위 지표 추세 + 목표 대비 점검
팀 분위기 저하 익명 사전 설문 + 소그룹 토의

흔한 오해와 함정

  • 조치 항목이 너무 많다. 열 개를 정하면 하나도 안 된다. Agile Alliance 용어집도 “조치 항목이 너무 많거나 너무 적은 것” 을 흔한 함정으로 꼽는다. 한두 개가 적당하다.
  • 지난 실험을 확인하지 않는다. 용어집이 꼽는 또 다른 함정이 “같은 문제가 눈에 띄는 진전 없이 반복되는 것” 이다. 회고의 첫 5분은 지난 실험의 결과를 보는 데 쓴다.
  • 불평 대회가 된다. 데이터 모으기와 통찰 단계 없이 감정만 쏟으면 생산적인 분석이 아니라 하소연으로 끝난다. 사실(타임라인, 지표)을 먼저 깔고 이야기한다.
  • 관리자가 진행하고 평가한다. 회고 내용이 평가에 쓰인다고 느끼면 아무도 진짜 문제를 말하지 않는다. 진행은 팀원이 돌아가며 하거나 외부 진행자가 맡는다. 안전감의 조건은 SE100 #097 에서 다룬다.
  • 팀 밖의 문제만 말한다. “인프라 팀이 느려서” 로 끝나면 할 수 있는 게 없다. 통제 범위 안의 행동(요청을 더 일찍, 더 작게 보내기)과 밖의 문제(에스컬레이션)를 나눈다.

확인 문제

  1. 애자일 선언 열두 번째 원칙에서 회고의 핵심 두 요소는 무엇인가?
  2. 스크럼 가이드 2020 이 회고의 점검 대상에 포함한, 산출물과 관련된 항목은?
  3. Derby·Larsen 의 다섯 단계 중 생략하면 “목소리 큰 사람의 기억이 사실이 되는” 단계는?
  4. 프라임 디렉티브가 “아무도 잘못하지 않았다” 는 뜻이 아니라면 무엇을 요구하는가?
  5. 회고의 결과를 “규칙” 대신 “실험” 으로 정하는 이점은?

풀이

  1. 팀 스스로 돌아보고 조정한다는 것(주체), 그리고 정기적으로 한다는 것(주기).
  2. 완료의 정의(Definition of Done).
  3. 데이터 모으기. 사실을 먼저 모으지 않으면 해석이 기억과 인상에 좌우된다.
  4. 문제의 원인을 개인의 결함이 아니라 그 행동을 합리적으로 보이게 한 조건(정보, 자원, 상황)에서 찾으라는 것이다.
  5. 성공 기준과 확인 시점이 정해져 있어 효과를 측정할 수 있고, 효과가 없으면 부담 없이 되돌릴 수 있다. 규칙은 효과가 없어도 남아서 쌓인다.

더 읽을거리 (References)