7.2 프로젝트 회고와 평가: 경험을 인사이트로 바꾸기

7.2 프로젝트 회고와 평가

실행 단계에서 프로젝트를 잘 운영하는 것도 중요하지만 — 다음 프로젝트를 진짜로 강하게 만드는 건 이번 프로젝트가 끝난 뒤에 일어나는 일입니다. 바로 회고와 평가이죠.

이번 글에서는 결과, 프로세스, 팀, 조직을 함께 돌아보는 법, 그리고 구조화된 방법으로 반복할 만한 성공과 피해야 할 실수를 어떻게 끌어낼지 다룹니다.

왜 회고가 중요한가

프로젝트가 끝나면 대부분의 팀 멤버는 곧장 다음 일로 옮겨갑니다. 회고를 건너뛰면 보통 다음이 남습니다.

• 아무도 정확히 짚어내지 못해 반복할 수 없는 성공 요인
• 조용히 다시 일어나는 실수와 누락
• 한 사람의 머릿속에 갇혀 팀에 닿지 않는 인사이트

회고는 과거를 탓하는 자리가 아닙니다 — 다음 프로젝트의 확률을 높이는 전략적 행동입니다.

프로젝트 리뷰의 네 차원

전체적인 시각을 위해 프로젝트를 네 각도에서 보세요.

1. 결과: 목표를 충족했는가? 품질, 인도, 비용, 만족
2. 프로세스: 계획, 진척 추적, 변경 관리는 효과적이었는가?
3. 팀: 협업, 역할, 커뮤니케이션이 분명했는가?
4. 환경: 외부 요인 — 이해관계자, 구조, 도구 — 가 적절했는가?

네 가지를 모두 보면 대화가 "잘 됐다 / 안 됐다"를 넘어 진짜 깊이 있는 인사이트로 옮겨갑니다.

평가 방법: KPT, 5 Whys, 360도 피드백

KPT (Keep / Problem / Try)

• Keep: 잘됐고 계속해야 할 것
• Problem: 잘되지 않은 것
• Try: 개선 아이디어

5 Whys

"왜?"를 다섯 번 연속으로 물어 문제를 근본까지 추적합니다. 증상을 넘어 실제 원인까지 밀어줍니다.

360도 피드백

관련된 모든 사람으로부터 피드백을 모아 팀이 자신을 여러 각도에서 보게 합니다 — 단일 시점으로는 놓칠 다이내믹스를 드러내 줍니다.

AB로 회고 진행하기

AB는 회고에 발 디딜 곳을 줍니다.

• 태스크 이력과 댓글을 다시 보며 결정이 실제로 어떻게 흘렀는지 확인
• 번다운과 간트 뷰로 페이스와 지연이 발생한 지점 분석
• 회고 템플릿(KPT 형식)을 공통 문서로 공유
• 익명 댓글이나 설문으로 솔직한 피드백 수집

그 결과는 사실 기반의, 대화가 이끄는 리뷰입니다 — 기억력 대결이 아니라요.

회고를 정착시키는 법

회고가 의례로 흘러가지 않게 하려면:

• 종료의 일부로 일정에 잡기 — 옵션이 아니라
• PM뿐 아니라 전체 팀을 참여시키기
• 대화를 책임 추궁이 아니라 앞을 향한 개선으로 틀 잡기
• 나온 결과를 다음 번을 위한 프로젝트 템플릿과 WBS에 반영

요약: 회고가 개선의 불씨를 만듭니다

회고는 과거를 후회하는 일이 아니라 — 더 나은 다음 프로젝트를 설계하는 일입니다. 인사이트를 개인의 교훈이 아니라 팀의 공유 지식으로 바꾸는 것이 학습하는 팀의 표시입니다.

AB에서는 이렇게 동작합니다

AB Project Management에서는 프로젝트 위키의 회고 페이지가 다음 팀이 검색할 수 있는 형태로 KPT를 담습니다. 프로젝트 홈에 핀으로 고정해 두면 누가 나중에 들어와도 가장 먼저 보게 됩니다. Lesson 태그가 달린 태스크가 책임자와 함께 개별 교훈을 담아주고 — MCP를 통해 연결된 AI 어시스턴트에게 프로젝트의 변경 이력을 회고 초안으로 요약해 달라고 요청해 토론의 출발점을 만들 수도 있습니다.

→ 다음으로 7.3 다음 프로젝트를 위한 지식 전달로 가서 배운 것을 어떻게 잡아내고 효과적으로 전달할지 살펴보세요.