2인 1조 PM 체제로 일하는 법
보통의 IT 조직, 특히 애자일(Agile)을 지향하는 스쿼드 팀의 구성은 명확합니다. 다수의 개발자와 디자이너, 그리고 그 중심을 잡는 '단 한 명'의 PM입니다. "사공이 많으면 배가 산으로 간다"는 옛말처럼, 의사결정권자인 PM이 둘일 경우 방향성이 흔들릴 수 있다는 우려 때문에 '1팀 1PM'은 일종의 불문율처럼 여겨져 왔습니다. 하지만 사이드 프로젝트나 주니어 육성을 목표로 하는 조직, 혹은 업무 강도가 극도로 높은 프로젝트에서는 이 공식이 오히려 독이 되기도 합니다. 혼자 감당해야 하는 기획의 무게와 결정의 외로움이 PM을 번아웃으로 몰고 가기 때문입니다.
그래서 우리는 과감한 실험을 하기로 했습니다. 개발자가 짝을 이뤄 코드를 짜는 '페어 프로그래밍'처럼, 기획자도 둘이서 하나의 프로덕트를 책임지는 '2인 PM 체제'를 도입한 것입니다. 오늘은 우리가 정립한 2인 PM 체제의 업무 방식과 그 효용에 대해 이야기해 보려 합니다.
두 명의 PM이 함께 일할 때 가장 경계해야 할 것은 기계적인 업무 배분입니다. 단순히 기능 명세서를 5페이지씩 나눠서 쓴다거나, 화면을 절반씩 맡아서 기획하는 방식은 필연적으로 제품의 통일성을 해치게 됩니다. 그래서 우리는 업무의 '양'이 아니라 '관점'을 나누는 방식을 택했습니다.
한 명은 '메인 PM(Lead PM)'으로서 프로젝트의 전체적인 숲을 봅니다. 일정 관리, 팀원들의 리소스 체크, 이해관계자와의 커뮤니케이션, 그리고 최종 의사결정을 담당하며 프로젝트가 올바른 방향으로 가고 있는지 끊임없이 확인하는 역할입니다. 다른 한 명은 '실무 PM(Action PM)'으로서 디테일한 나무를 봅니다. 구체적인 화면 설계(Wireframe), 정책 정의, 엣지 케이스 발굴, 그리고 QA 단계에서의 꼼꼼한 테스트를 주도합니다. 이렇게 역할을 나누면 메인 PM은 실무의 늪에 빠지지 않고 큰 그림을 그릴 수 있고, 실무 PM은 행정적인 업무 부담 없이 제품의 퀄리티에만 집중할 수 있는 환경이 만들어집니다.
혼자 기획할 때 가장 무서운 적은 '자기 확신'이라는 함정입니다. 내 머릿속에서는 완벽한 로직이지만, 제3자가 보기에는 구멍 투성이인 경우가 많습니다. 2인 체제의 가장 큰 장점은 기획서가 개발자에게 넘어가기 전에 강력한 '1차 필터'를 거친다는 점입니다. 내가 쓴 기획서를 동료 PM이 크로스 체크해주면서, 혼자라면 놓쳤을 논리적 오류나 정책의 빈틈을 찾아냅니다.
이 과정은 단순한 검수를 넘어 치열한 토론의 장이 되기도 합니다. "이 버튼은 왜 여기에 두었어?", "유저가 여기서 뒤로 가기를 누르면 데이터는 저장돼?"와 같은 날카로운 질문을 서로 주고받으며 기획의 밀도는 비약적으로 높아집니다. 개발자에게 "이거 정책이 뭐예요?"라는 질문을 듣기 전에, 우리끼리 먼저 매를 맞고 맷집을 키우는 셈입니다. 덕분에 개발팀에 전달되는 문서의 퀄리티는 훨씬 정교해지고, 커뮤니케이션 비용은 획기적으로 줄어들게 됩니다.
물론 두 사람의 의견이 항상 일치할 수는 없습니다. 오히려 건강한 충돌은 환영할 일입니다. 하지만 논쟁이 길어져 프로젝트 속도를 늦추는 것은 경계해야 합니다. 그래서 우리는 '최종 의사결정권'에 대한 원칙을 미리 세워두어야 합니다. 충분히 토론하되, 합의되지 않는 사안에 대해서는 리드 역할을 맡은 PM이 최종 결정을 내리고, 나머지 한 명은 그 결정에 전적으로 따르는 'Disagree and Commit'의 원칙을 지키는 것입니다. 이는 자존심 싸움이 아니라, 배가 산으로 가지 않게 하기 위한 최소한의 안전장치입니다.
결국 2인 PM 체제의 핵심은 '완벽한 한 명'이 되려 애쓰는 대신, '서로를 보완하는 두 명'이 되는 것입니다. 혹시 혼자 감당하기 벅찬 프로젝트 앞에서 망설이고 있다면, 혹은 주니어 PM의 성장을 고민하고 있다면, 2인 PM 체제라는 실험을 시작해 보는 건 어떨까요? 때로는 둘이 걷는 길이 혼자 뛰는 길보다 더 빠르고 멀리 갈 수 있습니다.