요즘은 매뉴얼이 잘 정리된 프레임워크나 라이브러리를 활용하는 개발 업무의 경우 AI 덕분에 진입 장벽이 현저히 낮아진 느낌입니다. 단순히 코드를 작성하는 것을 넘어 각 기술의 이점과 트레이드오프를 판단하는 컴퓨터 기초 지식 그리고 문제를 해결하는 데 필요한 소프트웨어 공학이 더욱 개발자에게 중요해지는 것 같습니다.
이러한 흐름에 발맞춰 회고 문화가 전무했던 저희 회사에 회고 문화를 도입했던 경험을 공유하고자 합니다.
회고문화가 없던 회사에 회고문화를 도입해야겠다고 생각했던 부분은 개발을 담당하는 팀, 기획을 담당하는 팀, 사업을 담당하는 팀들 간에 사일로 현상이 보였기 때문입니다. 팀 간의 소통이 너무 부족해 보였기에 서로 이야기할 수 있는 하나의 통로로 회고를 진행해야겠다는 생각이 들었습니다.
시작은 정말 "대충하기" 저만 그런지는 모르겠지만 예를 들어 뒷산을 등산한다 해도 등산복을 사고 등산화를 사고 모든 걸 갖추고 해야 할 것 같은 느낌이 항상 있었습니다. 준비하다 제풀에 지쳐 시작조차 못하는 경우가 많았는데 대충 엉망으로 시작하세요 라는 영상을 보고 나서 처음 멍청함을 인정하고 시작해보자라는 마인드를 갖게 되었습니다. 그래서 이번 회고 또한 정말 대충 정말 간단하게 시도하게 되었습니다.
우리에게는 정말 시작이 중요하기 때문이죠.
동료분들이 회고문화에 대해 인지는 하고있지만 경험이 없는 분들이 많았기에 저에게 익숙하고 어깨너머로 보았던 KPT회고 방법으로 진행하기로 동료분들께 말씀드렸습니다.
회고를 시작하기전 준비
1. KPT 회고에 대한 간략한 래퍼런스 공유
2. KPT 회고를 진행 방법과 우리만의 그라운드룰 정의
KPT 회고 방법과 룰
🎯 회고 시작 전, 우리 팀의 규칙 (Ground Rules)
성공적인 회고는 '심리적 안정감'을 바탕으로 합니다. 아래 규칙들을 회고 시작 전에 모두 함께 읽고 동의하는 시간을 가지면 좋습니다. 스크린에 띄워두고 시작해 보세요.
- 비난이 아닌 개선을 위한 시간임을 인지합니다.
- 회고의 목적은 잘잘못을 따지는 것이 아니라, '팀'으로서 더 나은 방향으로 나아가기 위함임을 모두가 기억합니다.
- "그때 왜 그랬어요?"가 아닌 "우리가 어떻게 하면 더 잘할 수 있을까요?"에 집중합니다.
- 모든 팀원은 주어진 상황 속에서 최선을 다했음을 믿습니다.
- 결과가 좋지 않았더라도, 그 누구도 일부러 일을 망치려고 하지는 않았을 겁니다. 서로의 선한 의도를 믿고 존중하는 마음으로 대화에 임합니다.
- '나(I-Message)'를 주어로 솔직하게 이야기합니다.
- 나쁜 예시: "OO님이 문서를 늦게 줘서 힘들었어요"
- 좋은 예시: "저는 문서가 조금 더 일찍 공유되었다면, 업무를 더 원활하게 진행할 수 있었을 것 같아요"
- 한 사람이 이야기할 땐 경청하고, 말을 끊지 않습니다.
- 모든 팀원에게 동등한 발언 기회를 보장하고, 다른 사람의 의견을 끝까지 듣는 자세가 중요합니다.
- 문제를 제기하는 것에서 끝나지 않고, 해결책을 함께 고민합니다.
- 'Problem'을 이야기했다면, 그에 대한 'Try(시도할 것)'까지 적극적으로 제안하며 논의를 발전시킵니다.
🚀 KPT 회고 상세 진행 방법 (약 60분 소요)
KPT는 **Keep(유지할 점), Problem(개선할 점), Try(새롭게 시도할 점)**의 약자입니다.
- Keep: 현재 잘하고 있어서 앞으로도 계속 유지하고 싶은 긍정적인 요소들
- Problem: 아쉬웠거나 개선이 필요하다고 느끼는 문제점들
- Try: Problem을 해결하거나, 더 좋은 방향으로 나아가기 위해 새롭게 시도해 볼 액션 아이템
1단계: 준비 및 KPT 설명 (5분)
- 준비물:
- 화이트보드, 세 가지 색상의 포스트잇, 펜
- **진행자(Facilitator)**가 오늘 회고의 목적과 위에서 정한 그라운드 룰, 그리고 KPT가 각각 무엇을 의미하는지 간단히 설명합니다.
2단계: 아이디어 작성 (10~15분)
- 정해진 시간 동안 각자 조용히 포스트잇에 K, P, T에 대한 생각들을 적습니다.
- Tip!: 이때는 다른 사람의 눈치를 보지 않고 자유롭게 자신의 생각을 적는 것이 중요합니다.
- 포스트잇 하나에는 하나의 내용만 적도록 안내합니다.
3단계: 작성 내용 공유 및 그룹핑 (15분)
- 한 명씩 돌아가며 자신이 작성한 포스트잇을 보드에 붙이고, 어떤 내용인지 간단하게(10~20초 내외) 설명합니다.
- 진행자는 비슷한 내용의 포스트잇이 나오면 함께 묶어서 **그룹핑(Grouping)**합니다. 이렇게 하면 팀이 중요하게 생각하는 핵심 이슈들이 시각적으로 잘 드러납니다.
4단계: 핵심 문제(Problem) 논의 및 우선순위 정하기 (15분)
- 모든 Problem을 한 번에 해결할 수는 없습니다. 이번 스프린트(혹은 특정 기간)에서 가장 중요하게 해결하고 싶은 Problem에 투표를 진행합니다. (1인당 2~3개의 투표권 부여, Dot Voting)
- 가장 많은 표를 받은 1~2개의 Problem을 중심으로 "왜 이런 문제가 발생했을까?"에 대해 깊이 있게 이야기 나눕니다.
- Tip!: 이때 '5 Whys' 기법을 활용하여 근본적인 원인을 찾아보는 것이 좋습니다. (예: "왜 배포가 지연되었나요?" -> "테스트가 늦어져서요." -> "왜 테스트가 늦어졌나요?" -> ... )
5단계: 실행 계획(Action Items) 도출 (10분)
- 우선순위로 선정된 Problem을 해결하기 위한 **Try(시도할 것)**를 구체화합니다.
- 단순히 "소통을 잘하자" 같은 추상적인 목표가 아니라, 실행 가능한 Action Item을 만들어야 합니다.
- 중요!: 도출된 Action Item은 반드시 **담당자(Owner)**와 **기한(Due date)**을 정해야 합니다.
- 나쁜 예시: "기획 공유를 더 잘하기"
- 좋은 예시: "(누가) 기획 담당자가, (무엇을) 다음 주 수요일까지, (어떻게) 개발 시작 전 최종 기획안에 대해 개발팀 전체 리뷰 미팅을 소집한다."
👍 회고 이후 (Follow-up)
- 결과물 공유: 회고에서 결정된 Action Item들을 팀 전체가 볼 수 있는 채널(슬랙, 노션, 지라 등)에 공유하여 잊지 않도록 합니다.
- 실행 추적: 다음 회고 시작 시, 지난번에 정했던 Action Item들이 잘 실행되었는지 간단히 리뷰하는 시간을 가지며 회고의 연속성을 확보합니다.
제가 요즘 즐겨 사용하는 Gemini에게 KPT회고 방법과 그라운드룰을 어떻게할지 설명하니 이렇게 잘 정리해 주었습니다.
KPT회고 방법과 그라운드룰을 준수하며 전체 KPT회고 시간이 60분을 넘지 않도록 타이머로 체크하며 진행하였습니다. 각자 생각했던 Keep, Problem, Try를 포스트잇에 작성하고 핵심 문제 중 가장 처음 해소하고 시도해 볼 수 있는 액션아이템을 도출하였습니다. (회사 보안상 모든 내용은 모자이크 처리하거나 블랙박스 처리하였습니다.)
요즘 많이 이야기하는 MBTI 중 내향적인 I다 보니 회고를 주도적으로 진행하는데 많은 용기가 필요하긴 했지만 회고문화가 없던 회사에서 처음 회고를 진행했다는 점이 참 뜻깊은 시간이었던 것 같습니다.
동료분들도 이런 회고 문화를 시작해 보았다는 점에서 가장 뜻깊었다는 이야기를 많이 해주셨습니다.
그리고 무엇보다 중요했던 각 부서 간 이야기를 들을 수 있었고 본질적인 문제를 해결하는 액션 아이템을 도출할 수 있는 유익한 시간이였습니다.
자 이제 우리는 우리가 계획한 액션아이템이 잘 지켜지는지 모니터링하고 또 다음 회고시간에 이를 평가하고 다시 우리가 해야 할 새로운 액션아이템을 선정하는 선순환 구조를 잘 지켜나가는 게 무엇보다 중요할 것 같습니다.