PM이 팀에게 전달하는 것의 본질은 컨텍스트다

기획서가 아니라 맥락을 쓴다

PM이 만드는 산출물의 이름은 회사마다 다르다. 어떤 조직은 PRD라 부르고, 어떤 조직은 기획서라 부르고, 어떤 조직은 그냥 노션 페이지라 부른다. 형식도 다르다. 와이어프레임이 붙기도 하고, 유저 스토리로 쓰기도 하고, 슬랙 스레드 하나로 끝내기도 한다. 나는 이 다양한 형식들이 결국 하나의 질문에 답하기 위한 수단이라고 생각한다. "왜 이걸 만드는가?"

이 질문에 제대로 답하는 것이 PM의 핵심 역할이다. 개발자는 어떤 기능을 어떻게 구현할지 판단하기 위해 기획서를 읽는 게 아니다. 이 기능이 왜 필요한지, 사용자가 어떤 상황에 놓여 있는지, 비즈니스가 이 시점에 무엇을 원하는지를 파악하기 위해 읽는다. 디자이너도 마찬가지다. 화면을 어떻게 그릴지는 디자이너가 더 잘 안다. 다만 그 화면이 어떤 맥락 위에 놓여야 하는지는 PM이 먼저 정리해야 한다. 형식이 무엇이든, PM이 팀에게 전달하는 것의 본질은 컨텍스트다.

형식은 달라도 전달하는 것은 하나다

기획서를 잘 쓰는 PM과 컨텍스트를 잘 전달하는 PM은 다르다. 전자는 문서 작성 능력의 문제고, 후자는 사고의 문제다. 나는 초기에 이 둘을 혼동했다. 문서를 정교하게 쓰면 팀이 잘 이해할 거라고 믿었다. 실제로는 그렇지 않았다. 문서가 길고 정밀할수록 팀은 오히려 "그래서 왜 이걸 해야 하는 거죠?"라는 질문을 더 자주 했다.

이러한 경험이 쌓이면서 깨달은 것이 있다. 팀이 원하는 건 완성도 높은 문서가 아니라, 판단의 근거가 되는 맥락이다. 개발자가 구현 방식을 결정할 때, 디자이너가 인터랙션을 선택할 때, QA가 테스트 케이스를 설계할 때, 이들은 모두 "이 결정이 맞는가"를 스스로 판단해야 한다. 그 판단의 재료가 컨텍스트다. 사용자가 어떤 불편을 겪고 있는지, 이 기능이 어떤 비즈니스 목표와 연결되는지, 지금 이 시점에 왜 이 문제를 풀어야 하는지. 이것들이 명확하면 팀은 PM이 예상하지 못한 상황에서도 올바른 방향으로 판단한다.

물론 형식이 아예 무관하다는 말은 아니다. 팀의 규모, 개발 방식, 조직 문화에 따라 적합한 형식은 달라진다. 다만 어떤 형식을 선택하든, 그 안에 컨텍스트가 없으면 문서는 그냥 할 일 목록이 된다. 할 일 목록은 팀을 움직이지 못한다.

문제 정의는 가장 높은 수준의 컨텍스트 설계다

PM이 하는 일 중 가장 어렵고 가장 중요한 것은 문제 정의다. 솔루션을 설계하는 것보다 어렵다. 솔루션은 문제가 명확하면 여러 사람이 함께 만들 수 있다. 하지만 문제 정의는 PM이 먼저 해야 한다. 그리고 이 문제 정의가 곧 팀 전체가 공유하는 최상위 컨텍스트가 된다.

문제 정의가 잘못되면 팀 전체가 잘못된 방향으로 달린다. 나는 이것을 직접 경험했다. 사용자 불만이 많다는 데이터를 보고 UX 개선 프로젝트를 시작했는데, 나중에 보니 그 불만의 원인은 UX가 아니라 가격 정책이었다. 화면을 아무리 다듬어도 문제가 해결되지 않았던 이유가 거기 있었다. 문제를 잘못 정의했기 때문에, 팀이 공유한 컨텍스트 자체가 틀려 있었던 것이다.

이러한 실패를 겪고 나서 문제 정의를 대하는 방식이 바뀌었다. 지금은 문제 정의를 쓸 때 세 가지를 반드시 포함한다. 사용자가 어떤 상황에서 어떤 불편을 겪는지, 그 불편이 비즈니스에 어떤 영향을 미치는지, 그리고 지금 이 문제를 풀어야 하는 이유가 무엇인지. 이 세 가지가 명확하면 팀은 솔루션 방향을 스스로 좁혀 나간다. 반대로 이 중 하나라도 빠지면, 팀은 각자의 해석으로 움직이기 시작한다.

컨텍스트의 품질이 결과를 결정한다

AI 도구가 일상화되면서 이 원칙이 더 선명하게 드러나고 있다. 팀원이 AI를 써서 코드를 짜거나 디자인 시안을 만들 때, AI가 내놓는 결과물의 품질은 입력된 컨텍스트의 품질에 정비례한다. "로그인 화면 만들어줘"와 "신규 가입자가 첫 로그인 시 느끼는 불안감을 줄이는 방향으로, 소셜 로그인을 기본으로 하되 이메일 옵션도 명확히 보이는 로그인 화면 만들어줘"는 완전히 다른 결과를 낳는다. 이 차이를 만드는 것이 컨텍스트다.

이것은 AI에만 해당하는 이야기가 아니다. 사람도 마찬가지다. 컨텍스트가 풍부한 팀원은 PM이 자리를 비워도 올바른 판단을 내린다. 컨텍스트가 빈약한 팀원은 PM이 모든 결정에 개입해야 한다. 결국 PM의 생산성은 자신이 얼마나 많은 일을 직접 하느냐가 아니라, 팀이 얼마나 좋은 컨텍스트를 가지고 스스로 움직이느냐에 달려 있다. 컨텍스트를 잘 설계하는 PM은 팀의 판단력을 높인다. 그것이 PM이 팀에게 줄 수 있는 가장 실질적인 기여다.

PM의 글쓰기는 맥락을 설계하는 일이다

PM이 문서를 잘 써야 한다는 말은 맞다. 다만 그 이유가 중요하다. 문서를 잘 써야 하는 이유는 형식적 완성도 때문이 아니라, 컨텍스트를 정확하게 전달하기 위해서다. 기획서든 PRD든 슬랙 메시지든, 그 안에 "왜"가 없으면 팀은 방향을 잃는다. 반대로 "왜"가 명확하면 팀은 형식이 불완전해도 움직인다.

나는 PM의 글쓰기 역량을 평가할 때 문서의 완성도보다 컨텍스트의 밀도를 본다. 이 문서를 읽은 팀원이 PM 없이도 올바른 판단을 내릴 수 있는가. 그것이 기준이다. 형식은 수단이고, 컨텍스트가 목적이다.