월간·분기 회고 작성 규칙
감상문 나열을 막고 사실-원인-다음 행동으로 이어지는 회고를 쓰게 하는 규칙.
내 환경에 맞게 만들기
무엇을 하는 규칙인가
이 규칙을 쓰는 이유
회고를 AI에게 맡기면 대개 **감상문**이 나온다. "좋았던 점: 팀워크가 좋았다", "아쉬운 점: 소통이 부족했다" 같은 문장은 쓰는 사람도 다음에 뭘 할지 모른다. 회고의 목적은 반성이 아니라 **다음에 다르게 할 행동**을 찾는 것이다. 아래 규칙은 감상에서 멈추지 않고 행동까지 이어지게 만드는 것이 목적이다.
섹션 순서
이 순서를 바꾸지 않는다. 1. **있었던 일** (사실) 2. **왜 그렇게 됐는지** (원인) 3. **다음에 다르게 할 것** (행동) 한 항목은 반드시 이 세 단계를 거친다. 사실만 쓰고 원인·행동 없이 끝내지 않는다.
사실과 판단을 섞지 않는다
1단계(있었던 일)에는 이미 해석된 문장을 쓰지 않는다. **관찰 가능한 사실**만 쓴다. - 이렇게 쓰지 않는다: `일정 관리가 부족했다.` - 이렇게 쓴다: `3개 스프린트 중 2개가 마감일을 넘겼다.` 첫 번째 문장은 이미 원인을 판단해버려서, 진짜 원인을 찾는 2단계가 생략된다.
원인은 2단계에서 별도로 쓴다
1단계의 사실에 대해 **왜 그런 일이 일어났는지**를 쓴다. 여기서도 사람 탓이 아니라 절차·구조로 쓴다. - 이렇게 쓰지 않는다: `담당자가 일정을 잘못 잡았다.` - 이렇게 쓴다: `착수 시점에 외부 팀 의존 작업의 일정을 확인하는 절차가 없었다. 두 스프린트 모두 이 확인이 빠져 있었다.`
행동은 다짐이 아니라 검증 가능한 절차로 쓴다
"더 열심히 하겠다", "꼼꼼히 확인하겠다" 같은 다짐은 다음 회고 때 확인할 방법이 없다. **누가 무엇을 언제까지, 어떻게 확인할지**를 쓴다. - 이렇게 쓰지 않는다: `다음 분기엔 더 꼼꼼히 확인하겠다.` - 이렇게 쓴다: `스프린트 착수 전 외부 의존 작업 목록을 체크리스트로 만든다. 다음 회고 때 이 체크리스트를 실제로 썼는지 확인한다.`
좋았던 일도 재현 가능하게 쓴다
좋았던 일을 칭찬으로 끝내지 않는다. **무엇을 했길래 좋아졌는지**를 남겨야 다음에도 반복할 수 있다. - 이렇게 쓰지 않는다: `팀워크가 좋았다.` - 이렇게 쓴다: `매주 수요일 15분 스탠드업을 도입한 뒤 블로커 공유가 빨라졌다. 다음 분기도 유지한다.`
분량과 톤
- 항목 수를 늘리지 않는다. 이번 기간에 가장 크게 배운 것 3~5개면 충분하다. 항목이 많으면 다음 행동도 흩어져서 아무것도 실행되지 않는다. - 평서체로 쓴다. 자책이나 자랑의 어조를 섞지 않는다. - 확실하지 않은 원인은 확실하지 않다고 쓴다. "아마 그래서였을 것이다"는 "정확한 원인은 확인하지 못했다. 다음에 비슷한 일이 생기면 이 부분을 먼저 본다"로 쓴다.
쓰기 전에 확인할 것
- 각 항목이 사실 → 원인 → 행동 세 단계를 모두 거치는가 - 사실 문장에 이미 판단이 섞여 있지 않은가 - 행동 항목이 다짐이 아니라 검증 가능한 절차인가 (누가/무엇을/언제) - 좋았던 일도 재현 가능한 이유가 함께 쓰였는가 - 항목 수가 3~5개를 넘지 않는가 흔히 나오는 실패 예시는 `bad-examples.md`에 정리해 두었다. 처음 몇 번은 그것과 비교해 보면 빠르다.
원문 전문
넣기 전에 전부 읽어보실 수 있습니다. 이 파일은 AI에게 지시를 주는 문서입니다. 내용을 확인하고 넣으세요.
item.md
## 이 규칙을 쓰는 이유 회고를 AI에게 맡기면 대개 **감상문**이 나온다. "좋았던 점: 팀워크가 좋았다", "아쉬운 점: 소통이 부족했다" 같은 문장은 쓰는 사람도 다음에 뭘 할지 모른다. 회고의 목적은 반성이 아니라 **다음에 다르게 할 행동**을 찾는 것이다. 아래 규칙은 감상에서 멈추지 않고 행동까지 이어지게 만드는 것이 목적이다. ## 섹션 순서 이 순서를 바꾸지 않는다. 1. **있었던 일** (사실) 2. **왜 그렇게 됐는지** (원인) 3. **다음에 다르게 할 것** (행동) 한 항목은 반드시 이 세 단계를 거친다. 사실만 쓰고 원인·행동 없이 끝내지 않는다. ## 사실과 판단을 섞지 않는다 1단계(있었던 일)에는 이미 해석된 문장을 쓰지 않는다. **관찰 가능한 사실**만 쓴다. - 이렇게 쓰지 않는다: `일정 관리가 부족했다.` - 이렇게 쓴다: `3개 스프린트 중 2개가 마감일을 넘겼다.` 첫 번째 문장은 이미 원인을 판단해버려서, 진짜 원인을 찾는 2단계가 생략된다. ## 원인은 2단계에서 별도로 쓴다 1단계의 사실에 대해 **왜 그런 일이 일어났는지**를 쓴다. 여기서도 사람 탓이 아니라 절차·구조로 쓴다. - 이렇게 쓰지 않는다: `담당자가 일정을 잘못 잡았다.` - 이렇게 쓴다: `착수 시점에 외부 팀 의존 작업의 일정을 확인하는 절차가 없었다. 두 스프린트 모두 이 확인이 빠져 있었다.` ## 행동은 다짐이 아니라 검증 가능한 절차로 쓴다 "더 열심히 하겠다", "꼼꼼히 확인하겠다" 같은 다짐은 다음 회고 때 확인할 방법이 없다. **누가 무엇을 언제까지, 어떻게 확인할지**를 쓴다. - 이렇게 쓰지 않는다: `다음 분기엔 더 꼼꼼히 확인하겠다.` - 이렇게 쓴다: `스프린트 착수 전 외부 의존 작업 목록을 체크리스트로 만든다. 다음 회고 때 이 체크리스트를 실제로 썼는지 확인한다.` ## 좋았던 일도 재현 가능하게 쓴다 좋았던 일을 칭찬으로 끝내지 않는다. **무엇을 했길래 좋아졌는지**를 남겨야 다음에도 반복할 수 있다. - 이렇게 쓰지 않는다: `팀워크가 좋았다.` - 이렇게 쓴다: `매주 수요일 15분 스탠드업을 도입한 뒤 블로커 공유가 빨라졌다. 다음 분기도 유지한다.` ## 분량과 톤 - 항목 수를 늘리지 않는다. 이번 기간에 가장 크게 배운 것 3~5개면 충분하다. 항목이 많으면 다음 행동도 흩어져서 아무것도 실행되지 않는다. - 평서체로 쓴다. 자책이나 자랑의 어조를 섞지 않는다. - 확실하지 않은 원인은 확실하지 않다고 쓴다. "아마 그래서였을 것이다"는 "정확한 원인은 확인하지 못했다. 다음에 비슷한 일이 생기면 이 부분을 먼저 본다"로 쓴다. ## 쓰기 전에 확인할 것 - 각 항목이 사실 → 원인 → 행동 세 단계를 모두 거치는가 - 사실 문장에 이미 판단이 섞여 있지 않은가 - 행동 항목이 다짐이 아니라 검증 가능한 절차인가 (누가/무엇을/언제) - 좋았던 일도 재현 가능한 이유가 함께 쓰였는가 - 항목 수가 3~5개를 넘지 않는가 흔히 나오는 실패 예시는 `bad-examples.md`에 정리해 두었다. 처음 몇 번은 그것과 비교해 보면 빠르다.
references/bad-examples.md
# 흔한 실패 예시와 교정 회고에서 반복적으로 나오는 세 가지 패턴이다. 왼쪽이 자주 나오는 문장, 오른쪽이 교정이다. ## 1. 감상문으로 끝나는 항목 **자주 나오는 것** > 좋았던 점: 팀워크가 좋았다. > 아쉬운 점: 소통이 부족했다. 읽는 사람도, 쓴 사람도 다음에 뭘 할지 알 수 없다. 사실도, 원인도, 행동도 없다. **교정** > 매주 수요일 15분 스탠드업을 도입한 뒤 블로커 공유가 빨라졌다. 다음 분기도 유지한다. > 신규 기능 3건 중 2건에서 API 계약이 착수 후에 바뀌었다. 원인은 설계 리뷰 없이 바로 구현을 시작한 것이다. 다음 분기부터 착수 전 계약을 문서로 먼저 합의한다. ## 2. 검증 불가능한 다짐 **자주 나오는 것** > 다음 분기엔 더 꼼꼼히 확인하고 소통도 자주 하겠습니다. "꼼꼼히", "자주"는 다음 회고 때 했는지 안 했는지 판단할 기준이 없다. **교정** > 배포 전 체크리스트를 만들어 PR 템플릿에 넣는다. 다음 회고 때 이 체크리스트를 실제로 쓴 PR 비율을 본다. ## 3. 사람 탓으로 원인을 끝내는 항목 **자주 나오는 것** > 일정이 밀린 건 담당자가 늦게 시작해서다. 원인이 사람에서 멈추면 담당자가 바뀌어도 같은 일이 반복된다. **교정** > 착수 시점에 외부 팀 의존 작업 일정을 확인하는 절차가 없었다. 두 건 모두 이 확인이 빠져 있었다. 다음 분기부터 착수 체크리스트에 이 항목을 넣는다. ## 확인 순서 작성 후 위에서부터 훑으며 세 가지를 본다. 1. 사실 → 원인 → 행동 중 빠진 단계가 있는가 2. 행동 항목이 다짐(부사)만으로 이루어져 있는가 3. 원인이 사람 이름·직책에서 멈춰 있는가 하나라도 걸리면 그 항목만 다시 쓴다. 전체를 다시 쓸 필요는 없다.