주니어 PM의 회고 문화 만들기

이 글은 주니어 PM으로써 제품팀에 회고 문화를 어떻게 만들어 나갔는지 공유하기 위해 작성되었습니다. 정답은 아니지만 적어도 저와 비슷한 고민을 하는 주니어 PM 분들이 계실 것 같아서 공유 드립니다:)

첫 번째 시행착오 (2023년 11월)

PM으로 처음 맡은 프로젝트를 맡았고 약 2달동안 작은 기능을 개발하여 배포 하였습니다. 서버 개발자 1명, 클라이언트 개발자 3명, 디자이너 1명, 그리고 PM인 저까지 총 6명으로 구성된 팀이었습니다.

첫 회고를 진행했을 때 팀원들의 반응은 예상보다 부정적이었습니다.

“회고는 푸념의 자리 아닌가?”
“푸념하다 끝나는 게 아닌가?”  
“회고는 책임을 실무자에게 돌리는 자리가 아닌가?”
“회고는 잘잘못을 따지는 자리가 아닌가?”

그래도 포스트잇으로 의견을 수렴해보려 시도했습니다. 실제로 푸념이 많이 나왔지만, 그 속에서도 여러 가지 개선 의견들을 얻어서 액션 아이템을 정할 수 있었습니다.

하지만 구체적인 실행 계획의 부재로 프로젝트 개선으로 이어지지 못했습니다. 당시 회사에 회고 문화가 없다는 현실에 저는 좌절감을 느꼈고, 인터넷에 떠도는 수많은 ‘회고’의 문화를 갖기에 생각보다 쉽지 않았습니다.

개인 회고의 시작 (2024년 4월)

몇 번의 단발적인 프로젝트 이후에 회사에서 신사업으로 투자하고 있는 AI 교육 서비스 제품을 맡게 되었습니다. AI 제품의 첫 프로젝트는 정말 힘들었습니다. 기획 의도와 달리 생성형 AI는 통제되지 않았고, 특히 QA 과정에서 통과 기준을 설정하는 것이 어려웠습니다.

이번엔 참여 인원도 많고 직책이 높은 분들이 함께 참여하다보니 저는 스스로 조금 위축되어서 적극적으로 회고의 자리를 가지려 하지 않았습니다.

프로젝트 마무리 후 개인 회고를 진행하고 이를 제품팀 전체 인원에게 공개했습니다.

하지만 스레드에 이모지 몇 개만 달릴 뿐 별다른 조치가 이어지지 않았습니다. 저 역시 제 행동에 대한 확신이 없어 명확한 계획을 제시하지 못했습니다.

조용한 준비 기간 (2024년 5~6월)

그 후 2번의 프로젝트를 더 진행한 후 혼자서 회고록을 정리했으나 공유하지 않았습니다. 여전히 제게는 효과적으로 커뮤니케이션을 할 자신이 없었고, 제가 맡은 제품의 커뮤니케이션 채널이나 업무 범위가 스스로 생각하기엔 모호하다고 느껴져서 누구를 참여시키고 누구를 배제할지 막막했습니다. 이 시기는 내적으로 회고의 의미와 방법을 고민하는 시간이었습니다.

분위기의 변화 (2024년 8월)

그 다음의 일부 기능 개선 이후 작게나마 회고 세션을 진행했습니다. 참여자는 클라이언트 개발자 3명, 디자이너 1명, PM까지 총 5명이었습니다.

제가 먼저 회고 내용을 공개하고, 각자 생각했던 아쉬움과 좋았던 점을 자유롭게 나눴습니다. 여전히 명확한 액션 아이템은 도출되지 않았지만, 팀의 분위기 자체는 좋았습니다.

서버 개발자, QA 담당자와는 개인 면담식으로 회고를 진행했습니다. 의견이 많이 나오고 좋은 분위기였으나 여전히 액션 플랜은 부재했고, 스스로의 확신 부족으로 실행에 옮기지 못했습니다.

신뢰 쌓기 (2024년 10월~2025년 5월)

이후 5번의 프로젝트를 진행하며 각 개발 파트별로 1:1 회고를 진행했습니다. (웹의 경우 담당자가 2명이라 2:1로 진행)

이 시기의 프로젝트들은 적극적인 기능 개선보다는 내부 프로세스를 다지는 시기였습니다. AI를 활용한 복잡한 구조의 안정적 유지보수를 위해 백오피스 환경과 본체 서버 작업에 집중했습니다.

접근 방식의 변화

거창하게 “우리 회고 합시다!“가 아닌 “우리 앞으로 어떻게 나아질 수 있을까요?“라는 뉘앙스로 조심스럽게 소통했습니다.
반드시 면담 분위기가 아니더라도 점심 식사 시간을 통해 솔직한 이야기를 들었습니다.
잘한 점, 아쉬움, 개선 아이디어를 위주로 듣기에 집중했습니다.

구체적 개선 실행

다행히 이쯤 되니 PM으로서 해결할 수 있는 부분들이 많이 보였습니다. 소통 채널 세분화, 정책 변경 사항의 공개 채널 공지, 기본적인 커뮤니케이션 개선 등 말이죠.

이러한 부분들을 조금씩 해결해나가면서 커뮤니케이션이 쌓이고 쌓여, 드디어 공식적인 회고 세션을 진행할 수 있었습니다.

회고 문화 정착 (2025년 8월)

약 1년 6개월 동안 PM으로서 프로젝트에 대해 묻고 개선해나가는 과정에 모든 멤버가 동기화되었기 때문에, ‘회고’라는 단어에 대한 이미지가 긍정적으로 변했습니다. 그리고 감사하게도 제가 기존에 맡고 있던 백오피스 제품의 오너십을 동료 PM분이 가져가주시면서 저는 한 개의 제품에 더 집중할 수 있었습니다. 그와 동시에 제가 메인으로 맡은 제품의 담당 메이커들과 명확한 바운더리가 형성되었고, 제가 적극적으로 회고를 주최할 수 있는 환경이 만들어 졌습니다.

이번에는 개발자와 QA 담당자, 디자이너 모두가 먼저 전체 회의에서 회고 세션을 하자고 제안해왔습니다. 저는 “이때다!“라는 생각에, 곧바로 회고 세션을 기획하여 실행에 옮겼습니다.

먼저 개인회고와 프로젝트 회고를 진행하고, 스스로 개선 계획을 수립하여 진행했습니다.

어떻게 계획을 세우고 실행 했는지는 다음 포스팅에서 더 자세히 다루도록 하겠습니다.

---

회고 문화를 만들면서 통해 깨달은 것들을 나열해 보았습니다.

회고 문화는 PM이 만듭니다

회사에서 먼저 챙겨주는 경우는 거의 없다고 봅니다. 특히 회사의 성장이 제품 주도가 아닌 경우, 회고라는 개념을 갖기 힘들다고 생각합니다. 따라서 PM이 먼저 솔선수범으로 강한 의지를 갖고 회고를 주도해야 합니다.

PM이 회고 전문가가 되어야 합니다

단순히 회의를 잡는 것이 아니라 스스로 개인 회고와 프로젝트 회고를 객관적으로 정리하고, 해결책까지 미리 생각해 둬야 합니다. 그리고 회고 세션을 치밀하게 계획해야 합니다. 적당히 하면 알아서 잘 하겠지라는 제 안일한 생각때문에 초반에 아무런 소득없이 푸념만 하고 스타트업 느낌만 낸 회의가 되었습니다.

메이커들에게 부담을 주지 않습니다

PM이 깔아준 판에 메이커들이 조화롭게 의견을 나눌 수 있도록 해야합니다. 실제로 제가 진행했던 크고 작은 회고의 경험으로는, 알아서 해주세요 라는 마인드로 진행했던 회고는 모두, 분위기가 싸늘해지거나 소득이 없던 회의가 대부분 이었습니다. 특히나 회고의 문화가 자리잡히지 않은 상태에서는 PM이 주도적으로 회고를 이끌고 메이커들은 따라오는 형태가 가장 바람직 합니다.

신뢰 쌓기가 가장 중요합니다

메이커들의 의견을 경청하고, 그들이 노력해준 리소스를 헛되이 하지 않아야 합니다. 액션 아이템을 도출하고 현실로 가져와 실행해야 합니다. 작은 약속들을 하나씩 지켜나가며 개개인에게 신뢰를 쌓아야 합니다.

솔직한 소통 환경을 만듭니다

메이커들의 솔직한 말을 듣는 것이 핵심이었습니다. 분위기가 불편해지거나 PM이 정성을 보이지 않으면 메이커는 솔직하게 말하지 않기 시작합니다. 환경적인 요인도 말씀드리자면, 솔직한 소통은 실제로 그 업무를 함께 한 사람끼리 해야 합니다. 업무에 관여하지 않은 인물들이 함께 하고 그들의 의견까지 듣게되면 솔직하고 깊은 이야기를 하기 힘들어 집니다. 그렇기 때문에 회고의 멤버는 최대한 실무를 함께한 메이커들로 구성합니다.

그러니 PM이 항상 한 발자국 먼저 다가가고, 먼저 솔선수범을 보여야 합니다. 그리고 그들과의 작은 약속을 하나씩 지켜나가야 합니다.

결론

PM은 일이 되게 하고 성과를 만드는 사람이라고 생각합니다.

1년 6개월 동안 작은 커뮤니케이션 횟수를 늘려나가며, 즉시 메이커들을 모으지 않고 개개인별로 먼저 라포와 신뢰를 쌓는 것을 우선적으로 진행했습니다.

그 결과, 회고는 더 이상 ‘푸념의 자리’가 아닌 ‘성장의 자리’로 인식되게 되었고, 팀원들이 먼저 회고를 요청하는 문화가 만들어졌습니다.

다음 포스팅에서는 실제 회고 세션에서 준비한 구체적인 내용과 방법론을 상세히 공유할 예정입니다.

감사합니다.