PRD와 디자인이 나왔다고 해서 모든 게 자동으로 흘러가지는 않는다.
개발이 시작된 후에도 PM은 일정, 리소스, 우선순위 사이에서 끊임없이 결정을 내리고, 조율해야 한다.
특히 다음과 같은 순간에는 교통정리가 반드시 필요하다.
디자이너는 한 명이고, 동시에 수정 요청이 들어올 때, 스프린트 내에 끝내야 하는 기능이 있는데 VoC가 들어올 때. 모두 바쁘지만, 아무도 어떤 일이 먼저인지 정확히 모를 때 PM이 개입해야 한다. 이럴 때는 일정과 리소스를 다시 나열하고, 지금 당장 중요한 것이 무엇인지 다시 정리해야 한다.
우선순위를 명확하게 정하고, 그 순서에 따라 각 역할의 타이밍을 조정하는 것이 교통정리의 시작이다.
회의 없이도 일이 진행되는 환경은 이상적이지만, 그만큼 정보의 흐름이 분산되기 쉽다. 디자이너와 개발자가 슬랙이나 피그마 댓글로 결정한 내용이 PM에게 전달되지 않을 때, 결과적으로 기획과 다르게 구현되거나, QA 단계에서 놓치는 일이 생긴다.
PM은 모든 대화를 직접 들을 수는 없지만, 중요한 결정이 어떻게 흘렀는지는 반드시 확인하고 정리해야 한다. 결정의 맥락이 누락되지 않도록 슬랙 메시지를 스레드로 묶거나, 피그마 내에서 달린 댓글을 주기적으로 체크하는 습관이 필요하다.
기획 중간에 마케팅팀이나 고객센터에서 긴급 요청이 들어오는 경우도 있다. PM이 이 요청의 중요도를 판단하지 않고 무작정 우선 적용을 지시하면, 기존 일정이 흔들리고, 팀 전체의 리듬이 무너진다.
교통정리는 단순한 요청 정리가 아니라, 기존 흐름에 이 요청을 어떻게 넣을 것인지, 혹은 넣지 않을 것인지를 정하는 과정이다. PM은 요청의 목적과 필요성을 파악하고, 기존 우선순위와 비교해 내부적으로 조율한 뒤 팀에 전달해야 한다.
관찰력 : 지금 어디가 막히고 있는지 확인하기
우선순위 : 부딪치지 않게 순서 매기기
커뮤니케이션 : 빠르고 명확하게 조율하고 싱크 맞추기
결정력 : 모두의 합의보다 일단 교차로를 통제하는 힘
교통정리는 통제의 기술이 아니라, 흐름을 만드는 일이다. 누구도 멈추지 않게 하고, 서로가 부딪히지 않게 하며, 각자의 일이 팀 전체 안에서 자연스럽게 흘러가도록 만드는 일이다.
이 역할은 눈에 잘 띄지 않는다. 좋은 교통정리는 오히려 아무 일도 없는 것처럼 보인다.
그래서 때로는 PM으로서 내가 뭘 하고 있는 건지 모호하게 느껴지기도 한다. 하지만 일정이 무리 없이 끝나고, 누군가 혼란 없이 다음 작업을 이어갈 수 있었다면 그건 누군가 조용히 교통정리를 잘 해냈다는 증거라고 생각한다.