프로젝트 회고 프롬프트가 푸는 문제는 회고 글을 쓸 때 가장 어려운 부분입니다. 프로젝트는 끝났는데 과정 기록은 채팅, 문서, 회의에 흩어져 있어서 막상 글로 쓰면 성과만 나열하거나 서로 책임을 떠넘기는 흐름 기록이 되기 쉽습니다. 아래 프롬프트는 목표, 실제 결과, 과정 기록을 먼저 AI에 넘긴 뒤 격차, 근본 원인, 개선안 세 층으로 나누어 쓰게 하므로, 복사해 변수를 채우면 곧바로 회고 회의에 가져갈 수 있는 초안이 나옵니다.
어려운 것은 요약이 아니라 격차를 말로 풀어내는 일
회고와 요약의 차이는 하나뿐입니다. 요약은 무엇을 했는지를 쓰고, 회고는 목표와 결과가 어디서 어긋났고, 왜 어긋났고, 다음에 무엇을 바꿀지까지 써야 합니다. 그래서 재료에는 목표와 실제 결과라는 두 기준점이 필요합니다. 과정 기록만 있으면 재배열에 그치고, 결과만 있으면 근본 원인은 추측이 됩니다. 원인을 파고들거나 개선안을 정할 필요가 없는 일반 진척 보고라면 주간 보고식으로 충분하고 회고 구조는 필요 없습니다.
그대로 복사할 수 있는 프롬프트
당신은 프로젝트 회고 회의를 여러 번 진행한 퍼실리테이터입니다. 아래 정보를 바탕으로 이 프로젝트를 곧바로 회고 회의에 가져갈 수 있는 글로 정리해 주세요.
프로젝트 목표와 실제 결과: {{목표와 결과}}
과정 기록: {{과정 기록}}
회고 용도: {{용도}}
개선안 개수: {{개선안 개수}}
출력 조건:
1. 먼저 목표와 실제 결과를 대조해 항목마다 원래 목표, 실제 결과, 격차를 쓰세요. 격차는 쓸 수 있는 곳은 숫자로 쓰고, 기록에 없는 숫자는 지어내지 마세요.
2. 다음으로 문제를 근본 원인에 따라 계획 수립, 협업 방식, 리소스 지원, 외부 변화 네 가지로 분류하세요. 각 문제는 과정 기록의 어떤 일에 해당하는지 밝혀야 하고, 기록에서 확인할 수 없는 원인은 만들지 마세요. 정보가 부족한 곳은 정보 부족이라고 표시하고 무엇이 빠졌는지 쓰세요.
3. 잘된 부분은 별도 단락으로 두되, 기록으로 뒷받침되고 다음에도 이어갈 가치가 있는 방식만 남기세요. 각 항목마다 당시 어떻게 했고 어떤 결과가 나왔는지 쓰세요.
4. 마지막에 개선안 표를 붙이세요. 열은 무엇을 바꿀지, 어떤 역할이 맡을지, 언제 확인할지, 무엇으로 개선됐다고 판단할지로 하세요. 개선안 개수는 지정한 수를 지키고 개수를 채우려고 덧붙이지 마세요. 소통을 강화한다, 더 신경 쓴다처럼 확인할 수 없는 말은 쓰지 마세요.
5. 전체적으로 일에 대해서만 쓰고, 사람을 지목해 비난하거나 책임을 묻는 표현은 쓰지 마세요. 기록 안에서 말이 엇갈리는 곳은 두 가지 설명을 모두 나란히 적고 확인 필요라고 표시하세요.
먼저 대조를 출력하고, 다음으로 문제 분류, 잘된 부분, 개선안 표를 출력하세요. 앞에 긴 설명은 쓰지 마세요.네 가지 변수를 채우는 법
- {{목표와 결과}}: 목표와 결과는 쌍으로 씁니다. 예를 들어 원래 9월 말 출시 예정이었으나 실제로는 10월 12일 출시, 목표 전환율 3%에 실제 출시 2주 뒤 2.1%처럼 씁니다. 프로젝트가 무사히 끝났다고만 쓰면 AI가 나눌 격차가 없습니다.
- {{과정 기록}}: 손에 있는 자료를 시간 순서대로 붙이면 됩니다. 채팅에서 정한 핵심 일정, 늦어졌을 때 보낸 설명, 회의 결론이 모두 쓸 만합니다. 조금 지저분해도 되지만, 나중에 내린 평가를 원래 기록에 섞지는 마세요. 평가는 회고 자리에서 할 일입니다.
- {{용도}}: 이 글을 누가 읽고, 그 자리에서 무엇을 정해야 하는지 씁니다. 예를 들어 팀 내부 회의용이며 다음 버전의 개선안 세 가지를 정해야 한다, 처럼 씁니다. 경영진에게 보내는 판본이라면 격차와 개선 계획만 보고하고 내부 이견의 세부 내용은 다루지 않는다고 변수에 적어 둡니다.
- {{개선안 개수}}: 3개에서 5개 사이의 작은 숫자를 줍니다. 회고에서 가장 흔한 실패는 문제를 못 찾는 것이 아니라 개선안을 스무 개나 나열하고 하나도 지키지 못하는 것입니다. 개수를 줄여야 우선순위가 생깁니다.
초안을 받으면 먼저 세 곳을 확인하세요
첫째는 숫자입니다. 대조표의 모든 숫자는 과정 기록이나 결과 데이터로 거슬러 올라갈 수 있어야 합니다. AI가 어림수를 정확한 값으로 바꾸거나 계획 숫자를 실제 결과에 옮겨 적는 일은 흔한 오류이니, 발견하면 기록에 적힌 숫자로 고칩니다. 둘째는 근본 원인의 깊이입니다. 늦어졌다, 소통이 부족했다는 현상이지 원인이 아닙니다. 왜 늦어졌는지에 답할 수 있어야 합격입니다. 예를 들어 요구사항 확정이 계획보다 2주 늦었다, 테스트 환경이 출시 사흘 전에야 갖춰졌다처럼 씁니다. 셋째는 개선안을 확인할 수 있는지입니다. 각 항목마다 확인 시점과 판단 기준이 모두 있어야 하고, 하나라도 빠지면 AI에 돌려보내 채우게 한 뒤 확정합니다. 회고 회의를 직접 만나서 했다면, 끝난 뒤 회의록 프롬프트를 써서 회의에서 확정한 개선안과 담당자를 실행 목록으로 정리할 수 있습니다.
초안이 빗나가면 이 세 가지 추가 지시로 되돌리세요
- 성과만 가득하고 문제가 흐릿할 때: 과정 기록으로 뒷받침되는 성과만 남기고, 문제 부분을 근본 원인별로 다시 펼치고, 뒷받침 없는 성과는 지우라고 지시합니다.
- 근본 원인이 현상에서 멈출 때: 첫 번째 문제에 대해 왜를 세 번 겹쳐 묻되, 각 단계가 과정 기록의 구체적인 사건이나 날짜에 닿게 하고, 닿지 않는 곳은 정보 부족이라고 쓰라고 지시합니다.
- 개선안이 구호뿐일 때: 각 개선안을 구체적인 행동으로 다시 쓰고 맡는 역할, 확인 시점, 판단 기준을 붙이며, 다시 쓸 수 없는 항목은 개수를 채우지 말고 지우라고 지시합니다.
