회고 템플릿: 형식, 예시 — 그리고 액션 아이템이 다음 회고까지 살아남게 하는 방법 (2026)

회고는 팀이 일하는 방식을 돌아보고 무엇을 바꿀지 정하는 회의입니다. 대상은 스프린트, 릴리스, 한 달 같은 기간입니다. 무엇을 만들었는지는 리뷰에서 다룹니다. 회고에서는 어떻게 만들었는지를 봅니다. 무엇이 작업을 늦췄고, 무엇이 작업을 앞으로 나아가게 했는지, 그리고 다음에는 팀이 무엇 한두 가지를 다르게 할지 정합니다. 회고 템플릿은 이 대화를 정해진 순서로 담는 한 페이지이며, 회의가 불만 목록이 아니라 결정을 내놓게 해 줍니다.

이 가이드는 먼저 기본기를 다룹니다. 형식, 복사해서 쓸 수 있는 스프린트 회고 템플릿, 작성된 예시, 대부분의 팀이 돌려가며 쓰는 네 가지 질문 세트가 여기에 들어갑니다. 그다음 구체적인 운영 방식을 다룹니다. 팀이 이미 쓰는 도구 안에서 회고가 어디에 놓이는지, 회의가 끝난 뒤 액션이 어떻게 되는지입니다. 회고의 진짜 시험대는 한 시간이 끝날 때의 보드가 아니기 때문입니다. 다음 회고의 첫 5분, 모두가 합의한 두 가지 변경이 실제로 이루어졌는지 누군가 물을 때가 시험대입니다.

회고란 무엇이고, 무엇이 아닌가

회고와 가까운 회의가 네 가지 있는데, 팀들은 이를 뒤섞었다가 대가를 치르곤 합니다.

네 가지 중 팀 자신에 관한 것이면서, 팀이 자리에 있고, 팀이 결정하는 회의는 회고뿐입니다. 그래서 결과물이 작습니다. 팀이 한 주기에 바꿀 수 있는 습관은 열 가지가 아니라 한두 가지입니다. 목록이 긴 회고는 대개 이름만 회고일 뿐 리뷰나 인시던트 리뷰로 변해 버린 경우입니다. 스프린트 리뷰 안건과 회고 안건이 서로 다른 두 페이지인 데는 이유가 있습니다.

회고는 감정을 곁들인 상황 보고 회의도 아닙니다. "돌아가면서 이번 스프린트가 어땠는지 말해 봅시다"라는 방식은 분위기를 만들 뿐 변화를 만들지 못합니다. 아래 템플릿은 의견보다 데이터를, 말하기보다 쓰기를, 한 시간이 끝나기 전에 결정을 요구합니다.

템플릿에 담기는 것: 형식

쓸 만한 회고 템플릿은 다음 순서로 일곱 부분을 갖춥니다. 온라인의 템플릿 대부분은 이 중 일부만 갖추고 있으며, 가장 자주 빠지는 것이 첫 번째와 마지막입니다.

1. 지난 회고의 액션 점검. 무엇보다 먼저 지난번 액션 하나하나를 담당자와 함께, 세 가지 상태 중 하나로 확인합니다. 완료, 미완료(사유 포함), 폐기입니다. 세 건이면 2분이면 됩니다. 이 순서를 건너뛰는 회고는 자신의 액션이 선택 사항이라고 선언하는 셈이고, 회의실의 모두가 그 메시지를 듣습니다.
2. 사실로 본 기간. 무엇이 출시되었고, 무엇이 밀렸고, 무엇이 고장 났는지를 숫자나 날짜로, 누군가 말하기 전에 보드에 적어 둡니다. 세 줄에서 다섯 줄이면 충분합니다. 같은 사실을 놓고 벌이는 논쟁은 수렴하지만, 서로 다른 기억을 놓고 벌이는 논쟁은 수렴하지 않습니다.
3. 잘된 점. 먼저 글로 적습니다. 한 사람이 항목당 메모 하나씩 쓰고, 그다음 소리 내어 읽습니다. 먼저 쓰는 것은 조용한 절반의 팀원이 목소리를 낼 수 있게 하는 규칙이며, 회고가 흔히 두 사람의 목소리에 지배되는 이유를 막아 줍니다.
4. 잘 안 된 점. 방식은 같습니다. 메모는 사람이 아니라 작업과 일하는 방식에 관한 것이어야 하고, 진행자는 사람을 지목한 메모를 1:1 미팅용 보류함(parking lot)으로 옮깁니다.
5. 묶고 선택하기. 메모를 묶어 클러스터로 만들고, 각자 다루고 싶은 클러스터에 두 표씩 던집니다. 상위 한두 개가 남은 시간의 주제가 되고, 나머지는 다음 회고로 넘기되 미뤄진 목록은 보관합니다.
6. 액션으로 정리한 한두 가지 변경. 선택된 각 클러스터에 대해 팀이 약속하는 변경을 액션 아이템으로 적습니다. 담당자 한 명, 동사 하나, 날짜 하나입니다. "추정을 더 잘하자"는 바람이고, "Lena — 목요일 계획 회의에 15분짜리 추정 점검 추가 — 다음 스프린트부터"는 액션입니다.
7. 담당자, 점검 날짜, 감사 인사. 액션을 담당자와 함께 다시 읽고, 점검할 날짜(보통 다음 회고)를 말하고, 이름을 부르며 감사 인사를 한 바퀴 나누고 마칩니다. 마지막 항목은 장식이 아닙니다. 다음번에 사람들이 4번 항목의 메모를 기꺼이 쓰게 만드는 장치입니다.

빼야 할 것은 리뷰(범위), 인시던트 리뷰(하나의 장애 타임라인), 1:1 미팅(한 사람)에 속하는 모든 내용입니다. 이런 것까지 담으려는 회고는 길어지기만 하고 아무것도 결정하지 못합니다.

진행 방법: 사전, 진행 중, 사후

사전: 시간대를 고정하고 사실을 준비합니다. 회고는 반복 회의이며, 실제로 출시된 것을 바탕으로 진행되도록 리뷰 뒤, 다음 계획 회의 앞에 둡니다. 한 주 안에서 회고가 놓이는 자리는 회의 주기 가이드에서 다룹니다. 하루 전에 진행자는 팀 채널에 해당 기간의 사실(출시 목록, 밀린 목록, 인시던트)과 담당자가 표시된 지난 회고의 액션을 올려서, 1번과 2번 항목을 회의 중에 정리하지 않고 회의 전에 읽도록 합니다. 진행자는 돌아가며 맡습니다. 매번 매니저가 진행하는 회고는 매니저에게 올리는 보고가 됩니다.

진행 중: 말하기 전에 쓰고, 그다음 결정합니다. 액션 점검으로 시작합니다. 각 담당자가 완료 여부와 이유를 한 문장으로 말합니다. 이어서 사실을 1분 동안 소리 내어 읽습니다. 그다음 잘된 점과 잘 안 된 점을 8분간 조용히 적습니다. 모든 메모는 올라오는 즉시 모두에게 보입니다. 보드가 번역을 지원하면 각 멤버의 언어로, 지원하지 않으면 회의실이 합의한 한 가지 언어로 적습니다. 읽기, 클러스터링, 투표에는 15분을 씁니다. 선택된 클러스터가 나머지 시간을 가져가며, 이 구간에서 진행자의 유일한 일은 시계가 끝나기 전에 논의를 이름이 붙은 액션으로 바꾸는 것입니다. 각 액션을 소리 내어 다시 읽어서 담당자가 두 번 동의하게 합니다. 마지막 5분에는 담당자와 점검 날짜가 붙은 액션을 확인하고, 감사 인사를 나눕니다.

사후: 같은 날 페이지를 게시하되, 다음 회고가 열어 볼 곳에 둡니다. 메모가 담긴 보드, 선택된 클러스터, 담당자가 있는 액션, 그리고 상태가 표시된 이전 액션을 한 페이지에 담아 불참자를 포함한 모두에게 보냅니다. 그런 다음 다음 회고가 시작되는 곳에 둡니다. 다음 페이지 맨 위의 액션 점검은 이번 페이지 맨 아래 액션 목록의 사본입니다. 진행자의 노트에만 있는 회고는 팀에게 없는 회고나 마찬가지입니다.

한 시간 자체를 운영하는 방법, 즉 오프닝, 시간 배분, 마지막 5분의 결과 되짚기는 어떤 효과적인 회의와도 같은 기본기입니다. 회고에만 해당하는 것은 먼저 쓰기 규칙과 변경을 두 가지로 제한하는 것입니다.

스프린트 회고 템플릿

[팀] — 회고, 스프린트 [번호] / [기간]
날짜: [날짜] · 시간: [시작]–[종료] · 링크: [회의 링크]
목적: 일하는 방식에서 바꿀 한두 가지를 정하고, 지난번에 정한 것들을 점검합니다.
진행자: [이름, 순환] · 기록: [이름 또는 "recap"]
사전 읽기: 지난 회고 페이지, 이번 기간의 사실

1. 지난 회고의 액션 — 진행자 — 5분 — 정보 공유
– [담당자] — [액션] — 기한 [날짜] — 완료 / 미완료: [사유] / 폐기
– [담당자] — [액션] — 기한 [날짜] — 완료 / 미완료: [사유] / 폐기

2. 사실로 본 기간 — 진행자 — 3분 — 정보 공유
출시: [목록]. 지연: [목록]. 장애: [목록]. [이번 기간에 중요한 숫자 하나.]

3. 잘된 점 — 모두, 먼저 글로 — 8분 — 논의
[메모, 항목당 한 가지씩, 작성 후 소리 내어 읽기.]

4. 잘 안 된 점 — 모두, 먼저 글로 — 8분 — 논의
[작업과 일하는 방식에 관한 메모 — 사람에 관한 것은 제외.]

5. 묶고 투표하기 — 모두 — 10분 — 결정
클러스터: [A], [B], [C]. 각자 두 표. 선택: [한두 개]. 다음으로 미룸: [나머지].

6. 우리가 약속하는 변경 — 팀 — 15분 — 결정
– [담당자] — [동사 + 대상] — [날짜]부터 — [날짜] 회고에서 점검
– [담당자] — [동사 + 대상] — [날짜]부터 — [날짜] 회고에서 점검

7. 담당자, 점검 날짜, 감사 인사 — 5분
담당자와 함께 액션 다시 읽기. 점검 날짜: 다음 회고, [날짜]. 각자 한 번씩, 이름을 부르며 감사 인사.

보류함(Parking lot): [제기되었으나 선택되지 않은 항목 — 다음 회고 페이지로 이월]

이 템플릿은 일반 텍스트이므로 문서, 캔버스, 화이트보드의 포스트잇 열, 채팅 메시지에 서식을 손보지 않고 그대로 붙여 넣을 수 있습니다. 중요한 것은 순서이지 도구가 아닙니다.

작성된 예시: 2주 스프린트를 마친 8인 제품 팀

플랫폼 팀 — 회고, 스프린트 31
목적: 일하는 방식에서 바꿀 한두 가지를 정하고, 지난번에 정한 것들을 점검합니다.
진행자: Mateusz · 기록: recap
사전 읽기: 스프린트 30의 회고 페이지, 어제 채널에 올린 스프린트 31의 사실

1. 지난 회고의 액션 — 5분
– Priya — 리스본 팀원이 실시간으로 참여할 수 있도록 데일리를 09:30으로 이동 — 기한 11월 2일 — 완료
– Kenji — 모바일 트랙의 한 페이지짜리 완료 정의(definition of done) — 기한 11월 6일 — 미완료: QA 리드의 수정을 기다리는 중, 11월 20일로 기한 조정

2. 사실로 본 기간 — 3분
계획한 11건 중 9건 출시. 지연: 내보내기 작업, 온보딩 이메일. 장애: 1건, 40분, 검색 인덱스. 목요일 리뷰가 25분 초과됨.

3. 잘된 점 — 8분
검색 수정을 페어로 작업해서 당일에 마무리했다. 채널에 사실이 남아 있어서 "우리가 뭘 출시했지?"를 두 번 묻는 사람이 없었다. 리스본 팀원이 모든 데일리에 참여했다.

4. 잘 안 된 점 — 8분
스프린트 시작 시점에 명세가 반쯤만 되어 있던 항목이 두 개 있었다. 회의 중에 데모를 세팅하느라 리뷰가 길어졌다. 인시던트 보고서가 사흘 늦게 작성되었다.

5. 묶고 투표하기 — 10분
클러스터: 스프린트 시작 시점의 준비 상태(6표), 리뷰 시간(4), 인시던트 보고서 작성(3), 추정(2). 선택: 준비 상태, 리뷰. 미룸: 인시던트 보고서 작성, 추정.

6. 우리가 약속하는 변경 — 15분
– Lena — 계획 회의 전 화요일에 모든 항목의 준비 상태 점검. 한 줄 명세와 담당자가 없는 항목은 스프린트에 들어가지 않음 — 스프린트 32부터 — 11월 28일 회고에서 점검
– Tomás — 리뷰 당일 정오까지 데모 환경을 준비하고 테스트 완료 — 스프린트 32부터 — 11월 28일 회고에서 점검

7. 담당자, 점검 날짜, 감사 인사 — 5분
다시 읽기. 점검 날짜: 11월 28일. 검색 페어 작업을 해 준 Priya와 이른 시작을 함께해 준 리스본 팀원들에게 감사.

보류함(Parking lot): 인시던트 보고서 작성, 추정 — 스프린트 32 회고의 첫 번째 안건.

이 페이지가 작동하는 이유를 살펴보세요. 첫 번째 항목과 끝에서 두 번째 항목은 2주 간격으로 본 같은 목록입니다. 스프린트 31의 액션은 스프린트 30 페이지의 맨 아래에서 생겨나 이번 페이지의 맨 위에서 평가받았고, 스프린트 32의 액션은 11월 28일에 평가받습니다. 이 순환이 회고의 가치 전부이며, 대부분의 템플릿이 기억에 맡겨 두는 부분입니다.

네 가지 질문 세트와 각각이 맞는 상황

템플릿의 3번과 4번 항목은 한 쌍의 질문이고, 팀은 같은 쌍에 금방 싫증을 냅니다. 잘 알려진 대안 네 가지를 소개합니다. 모두 5번과 6번 항목으로 끝나는 구조는 그대로입니다.

어떤 세트를 쓰든 두 가지 규칙은 유지됩니다. 말하기 전에 쓰는 것, 그리고 결과물이 담당자가 있는 한두 가지 액션이라는 것입니다. 메모의 벽은 풍성해졌지만 결정이 없는 질문 세트는 회의를 더 흥미롭게 만들었을 뿐, 더 유용하게 만들지는 못했습니다.

이미 쓰고 있는 도구에서 회고가 놓이는 곳

주요 플랫폼은 각각 회고에 보드나 문서를 제공하며, 각각 멈추는 지점이 다릅니다. 아래는 각 벤더의 공식 페이지에 문서화된 동작만 정리한 것이고, 사실을 확인한 월을 함께 적었습니다.

모든 행에 똑같은 점이 두 가지 있습니다. 하나는 회고 보드가 회의 옆에 놓인 문서이고, 그 문서가 작성되거나 회의가 진행된 한 가지 언어로 되어 있다는 점입니다. 다른 하나는 지난 회고의 액션이 이행되었는지는 문서가 답해 주지 않으며, 다음 회의에서 사람이 이전 페이지를 열어 회의실에 읽어 준다는 점입니다. 그렇게 해도 괜찮다면 네 가지 중 무엇을 써도 되고, 이 표가 답의 전부입니다. Teams나 Meet 통화의 전사본, 녹화본, 요약이 이후 어디에 저장되고 누가 각각을 열 수 있는지는 Teams와 Meet이 전사본, 녹화본, 요약을 저장하는 곳에 정리되어 있습니다. 각 플랫폼의 실시간 번역이 통화 안에서 어디까지 다루고 어디서 멈추는지는 Teams와 Meet 가이드(Teams, Meet)에 나와 있습니다.

액션이 다음 회고까지 살아남는 방법

InterMIND는 회의가 채널 안에 머무는 커뮤니케이션 공간이므로, 회고에는 자연스러운 자리가 있습니다. 바로 회고만을 위한 채널입니다. 여기에 기간의 사실과 지난 회고의 액션을 전날 올리고, 채널은 모든 세션의 recap을 보관하므로 스프린트 30의 페이지는 스프린트 31의 페이지에서 클릭 한 번이면 닿습니다. 각 멤버는 자신의 언어로 입력하고 다른 사람의 글을 자신의 언어로 읽습니다. 다른 곳에서 작성한 페이지는 이메일로 채널에 들어옵니다. 호스트가 채널에 고유한 주소를 만들어 주면, 그 주소로 보낸 메시지가 발신자 이름이 표시된 일반 메시지로 나타나고 첨부 파일도 그대로 유지됩니다.

통화 중에 보드는 Share to conference로 비디오 타일 옆, 모두의 화면에 띄운 노트입니다. 진행자는 회의실이 의견을 적는 동안 실시간으로 편집하고, 모든 참가자는 이를 자신의 언어로 읽으며 원문은 토글 한 번이면 볼 수 있습니다. 이전 세션의 recap도 같은 방식으로 회의에 공유할 수 있으므로, 1번 항목인 지난 회고의 액션은 누군가의 기억이 아니라 모두의 화면에 있는 실제 기록이 됩니다.

통화가 끝나면 recap이 회의 자체를 바탕으로 작성됩니다. 요약, 합의됨·미결·논쟁 중으로 표시된 사항, 담당자가 있는 액션 아이템이 들어가고, 각 줄은 타임스탬프를 유지합니다. recap은 이메일로, 채널의 메시지로, 캘린더 일정의 링크로 도착하며, 로그인한 모든 멤버가 각자의 언어로 읽습니다. 기록은 회의실에서 우연히 쓰인 언어로 한 번 작성되는 것이 아니라 독자별로 번역됩니다. 어떤 멤버든 편집할 수 있고, 모든 편집에는 작성자와 수정 이력이 남습니다. 호스트는 트래커나 CRM 수신 메일함 같은 임의의 주소에 recap 사본을 추가할 수 있어서, 누구도 전달해 주지 않아도 두 개의 액션이 기록 시스템에 도달합니다. 위에서 본 Teams와 Meet의 문서에 따르면 두 도구는 순간을 번역합니다. 통화 중의 자막, 회의가 진행된 언어로 된 recap이 그것입니다. 여기서는 공간이 번역된 상태로 남습니다.

팀 상태 페이지를 켠 조직에서는 회고의 액션도 점검됩니다. recap에 기록된 모든 액션은 조직의 작업 체인에 합류하고, 다음 recap이 작성될 때 열려 있는 액션들이 회의에서 나온 발언과 대조되어 판정됩니다. 누군가 끝냈다고 보고한 액션은 완료로 표시되고, 논의되었지만 끝나지 않은 액션은 회의에서 나온 표현으로 사유와 함께 미완료로 표시되며, 아무도 언급하지 않은 액션은 열린 상태로 남습니다. 판정은 각각의 근거가 된 recap과 함께 조직의 상태 페이지에 남고, 다음 세션이 시작될 때 Mia가 열린 항목과 담당자를 알려 줍니다. 그래서 아무도 이전 페이지를 열지 않았더라도 템플릿의 1번 항목은 다뤄집니다. 팀 상태 페이지는 프리뷰 기능입니다. 조직의 관리자가 알파 약관에 동의한 뒤 Settings → Advanced에서 켭니다(Preview features 페이지에서 각 기능을 설명합니다).

게스트, 즉 스프린트에 참여한 외주 인력이나 한 번의 회고에 초대된 고객사의 엔지니어는 계정 없이 무료로 링크를 통해 휴대폰이나 브라우저에서 참여하고, 회의를 실시간으로 자신의 언어로 듣습니다. 게스트에게는 이후에 남는 기록이 없습니다. 계정은 무료이며, 기록에 접근할 수 있게 해 주는 것이 계정입니다. 호스트는 공간을 제공하고, 유료 요금제에서는 최근 28일간 활성 상태였던 멤버에 대해서만 비용을 냅니다. 조용해진 멤버는 추가 비용 없이 접근 권한을 유지합니다.

• 전체 recap 열어 보기 — 액션 아이템을 포함해, 여러분의 recap을 작성하는 것과 같은 코드가 렌더링한 실제 기록입니다.
• 라이브 데모 체험하기 — 가입 없이, 말해 보면 회의실이 청자별로 번역되는 것을 들을 수 있습니다.

기본기로서의 회고는 어떤 도구에서도 살아남습니다. 팀에게 무엇을 바꿀지 묻고 그 답을 둘로 제한하는 일은 여전히 누군가가 해야 합니다. 살아남지 않아도 되는 것은 두 번째 일입니다. 통화가 끝난 뒤 한 가지 언어로 보드를 다시 타이핑하는 일, 그리고 지난번에 결정한 것을 누가 했는지 묻는 것으로 다음 회고를 시작하는 일입니다.

FAQ

회고 회의란 무엇인가요?

회고는 팀이 스프린트, 릴리스, 한 달 같은 기간 동안 어떻게 일했는지 돌아보고, 일하는 방식에서 한두 가지 변경을 약속하는 반복 회의입니다. 먼저 지난 회고의 액션을 점검하고, 해당 기간의 사실을 보드에 올리고, 잘된 점과 잘 안 된 점을 글로 모은 다음, 묶고 투표하며, 담당자와 점검 날짜가 있는 액션으로 마칩니다. 무엇을 만들었는지 보는 리뷰나 하나의 장애를 보는 인시던트 리뷰와는 구별됩니다.

스프린트 회고는 어떻게 진행하나요?

리뷰 뒤, 계획 회의 앞으로 시간대를 고정하고, 하루 전에 팀 채널에 해당 기간의 사실과 지난 회고의 액션을 올립니다. 회의에서는 지난번 액션을 점검하고(5분), 사실을 읽고, 아무도 말하기 전에 잘된 점과 잘 안 된 점 메모를 조용히 적고, 소리 내어 읽고, 묶고, 각자 두 표씩 투표한 뒤, 남은 시간 동안 상위 한두 개 클러스터를 담당자 한 명과 날짜 하나가 있는 액션으로 바꿉니다. 액션을 다시 읽고 점검 날짜(보통 다음 회고)를 말한 뒤 감사 인사로 마칩니다. 페이지는 같은 날, 다음 회고가 열어 볼 곳에 게시합니다.

회고의 5단계란 무엇인가요?

널리 쓰이는 5단계 구조는 다음과 같습니다. 분위기 조성(목적, 이전 액션, 규칙), 데이터 수집(기간의 사실과 모두의 메모), 인사이트 도출(메모를 묶고 그 뒤의 패턴 찾기), 실행 결정(담당자가 있는 한두 가지 액션), 마무리(다시 읽기, 점검 날짜, 감사 인사)입니다. 이 가이드의 템플릿은 이 단계에 항목별로 대응됩니다. 1–2번은 분위기 조성과 사실 수집, 3–5번은 수집과 그룹화, 6번은 결정, 7번은 마무리입니다.

스프린트 리뷰와 스프린트 회고의 차이는 무엇인가요?

리뷰는 작업, 즉 무엇을 만들었는지, 의도한 것과 맞는지, 백로그에서 무엇이 바뀌는지를 이해관계자가 참석한 자리에서 봅니다. 회고는 일하는 방식, 즉 무엇이 팀을 늦췄고 무엇을 바꿀지를 팀만 참석한 자리에서 봅니다. 리뷰는 승인된 항목과 백로그 변경을 남기고, 회고는 팀이 일하는 방식에 관한 한두 가지 액션과 완료 여부가 표시된 지난번 액션을 남깁니다. 회고를 리뷰 뒤에 두는 것은 실제로 출시된 것을 바탕으로 진행하기 위해서입니다.

Start, stop, continue란 무엇인가요?

세 개의 열로 이루어진 회고 질문 세트입니다. 팀이 시작해야 할 것, 멈춰야 할 것, 계속해야 할 것입니다. 기본 템플릿의 잘된 점·잘 안 된 점 쌍을 대체하며, 메모에서 곧바로 액션을 얻고 싶은 팀에 적합합니다. "시작" 메모는 이미 절반쯤 액션이기 때문입니다. 묶기, 투표, 약속하는 변경을 한두 가지로 제한하는 규칙은 그대로 적용됩니다.

회고의 4가지 질문은 무엇인가요?

전형적인 회고는 네 가지를 묻습니다. 무엇을 잘했는가, 무엇을 배웠는가, 다음에는 무엇을 다르게 해야 하는가, 아직 무엇이 풀리지 않았는가입니다. 이는 4Ls(Liked, Learned, Lacked, Longed for)의 다른 형태이며, 분기나 프로젝트 종료처럼 수정만큼 배움이 중요한 긴 기간에 가장 잘 맞습니다.

스프린트 회고는 얼마나 길어야 하나요?

2주 스프린트에 510명 규모의 팀이라면 4560분입니다. 이전 액션에 5분, 사실에 3분, 쓰기에 16분, 읽기·클러스터링·투표에 15분, 변경에 15분, 마무리에 5분을 씁니다. 정기적으로 이보다 길어지는 회고는 대개 리뷰나 인시던트 논의가 회의실에 들어온 경우이고, 훨씬 짧은 회고는 대개 쓰기나 액션을 건너뛴 경우입니다.

회고 템플릿에는 무엇이 포함되어야 하나요?

일곱 가지입니다. 상태가 표시된 이전 회고의 액션, 사실로 본 기간, 잘된 점과 잘 안 된 점(둘 다 먼저 글로), 묶기와 투표, 담당자와 날짜가 있는 액션 아이템으로 쓴 한두 가지 변경, 그리고 미뤄진 항목을 위한 보류함과 함께하는 마무리(다시 읽기, 점검 날짜, 감사 인사)입니다. 대부분의 템플릿이 빼먹는 두 부분은 첫 번째와 끝에서 두 번째, 즉 이전 액션의 점검과 새 액션의 담당자·날짜입니다. 이 둘이 한 회고를 다음 회고와 이어 줍니다.

출처: Microsoft — Microsoft Teams에서 회의 노트 작성; Microsoft — Microsoft Teams의 recap; Zoom — AI Companion으로 회의 안건 생성; Zoom — AI Companion의 회의 요약 사용; Google — "Take notes for me"를 위한 Calendar 및 Meet 설정; Google Meet — Google Meet의 "Take notes for me"; Slack — 회의 안건 템플릿; Slack — Slack에서 허들 사용. 표의 각 셀에는 해당 사실을 확인한 월이 적혀 있습니다. Microsoft의 노트 페이지, Zoom의 안건 페이지, Google의 페이지, Slack의 페이지는 2026년 10월에, Microsoft의 recap 페이지와 Zoom의 회의 요약 페이지는 2026년 8월에 확인했습니다. 5단계 구조와 질문 세트는 일반적인 관행이며 벤더의 주장을 담고 있지 않습니다. 벤더는 시간이 지나면서 요금제, 기능, 언어 목록을 변경하므로 최신 상태는 각 벤더의 페이지에서 확인하시기 바랍니다.