너는 뭘 기획하니?

“너는 거기서 어떤 것을 기획하니?”

부모님께 이직 소식을 전했을 때, “너는 거기서 어떤 것을 기획하니?”라는 질문을 받았다. 친구들과 대화할 때도 유사한 질문이 반복된다. 서비스 PM으로 일한다고 하면 대부분 구체적으로 무엇을 기획하는지 묻곤 한다. 화면을 그리는지, 디자인을 하는지, 마케팅을 하는지. 직무 자체가 한 단어로 떨어지지 않다 보니 질문이 자연스레 따라온다.

그런데 그 안에서도 한 단계 더 들어가는 직무가 있다. 바로 ‘플랫폼 PM’이다. 서비스 PM이라고만 답해도 충분히 설명이 어려운데, 플랫폼 PM이라고 하면 한 번 더 풀어 설명해야 한다. “플랫폼 PM은 어떤 일을 할까?” 이 글은 그 질문에 답해 보려는 글이다.

서비스 개발 시 사용자들은 보통 UX와 UI 중심으로 학습한다. 직관적으로 보이는 영역이기 때문이다. 그러나 사용성이 좋은 서비스를 만들려면 그 뒤의 백엔드 플로우가 잘 구성되어 있어야 한다. 화면이 매끄럽게 동작하는 것처럼 보이려면, 뒤에서 데이터가 정확한 순서로, 정확한 조건으로, 정확한 시점에 움직여야 한다. 플랫폼 PM은 바로 그 뒤의 흐름을 설계하는 사람이다.

이 글에서는 플랫폼 PM이 매일 다루는 일을 세 가지 축으로 정리해 본다. 서비스 PM과의 차이를 같이 짚으면서, 플랫폼 PM이 어떤 종류의 사고를 자주 하는지를 풀어 보겠다.

플랫폼 PM은 서버 개발자와 밀접하게 일을 한다

모든 서비스 PM이 개발자와 협업하지만, 플랫폼 PM은 화면 표시보다 서버 부분에 대한 기획을 하기 때문에 서버 개발자와 훨씬 많은 커뮤니케이션을 한다. 회의 시간의 절반 이상이 서버 쪽 이야기로 흘러간다고 해도 과언이 아니다.

예를 들어 홈 화면 콘텐츠 기획을 한다고 하자. 일반적인 서비스 PM의 관점에서는 어떤 카드 디자인을 쓸지, 몇 줄까지 노출할지, 이미지의 위치는 어디에 둘지가 중심이 된다. 그런데 플랫폼 PM은 다른 질문을 먼저 떠올린다.

• 이 콘텐츠는 어디에서 와야 하는가
• 어떤 조건으로 노출되어야 하는가 (조회수, 공유수, 댓글 순 등)
• 어드민에서 이 콘텐츠를 따로 관리해야 하는가
• 이미지 형식은 어떻게 통일되어야 하는가
• 콘텐츠는 얼마 주기로 재로딩되어야 하는가

이 질문들을 하나씩 정리해 가며, 서버에 과부하가 걸리지 않도록 개발자와 함께 구조를 잡는다. 화면 너머에서 데이터가 어떻게 움직이는지를 머릿속에 그릴 수 있어야 한다.

플랫폼 PM은 화면 설계나 정책 수립 외에도, 전반적인 시스템 아키텍처를 이해하는 역량이 중요하다. 모든 설계를 PM이 직접 하지는 않지만, 개발자의 의견을 정확하게 이해하고 그 의견이 사용자 경험에 어떤 영향을 미치는지를 다시 정책 언어로 풀어낼 수 있어야 한다. 즉, 기술 언어와 기획 언어를 양방향으로 번역할 수 있는 사람이 플랫폼 PM이다.

API 문서를 적극적으로 활용하고 정책을 세운다

화면 설계 시에도 API 문서를 활용하는 경우가 많지만, 플랫폼 PM은 API 문서를 이해하고 그 위에 정책을 세우는 능력이 훨씬 더 중요하다. 수많은 API들이 어떻게 연결되어 있는지를 머릿속에 그릴 수 있어야 한다.

새 기능을 설계할 때 플랫폼 PM이 가장 먼저 떠올리는 질문 중 하나는 이렇다. “기존 API를 활용해도 되는가, 아니면 별도의 API를 새로 구성해야 하는가.” 같은 결과를 화면에서 보여 줄 수 있더라도, 그 결과를 어떤 API로 어떻게 받아 오느냐에 따라 성능, 유지보수성, 장애 가능성이 완전히 달라진다.

이걸 잘 모르는 채로 기획서를 쓰면, 개발 회의에서 거의 반드시 다시 그려야 하는 상황이 생긴다. 그래서 플랫폼 PM은 서버 입장에서의 고민을 자기 머릿속에 항상 두고 기획을 시작한다. “이걸 만들면 서버에는 어떤 부담이 가고, 어떤 종류의 에러 케이스가 생기며, 그 에러 케이스는 사용자에게 어떻게 노출되어야 하는가.” 이런 질문이 자연스럽게 같이 따라온다.

API 문서를 정책의 시작점으로 쓰는 일이 익숙해지면, 기획서의 톤 자체가 달라진다. 단순한 화면 흐름 설명이 아니라, 데이터의 흐름을 설계하는 문서가 된다. 그리고 이런 문서를 받은 개발자는 같은 PM과 일하는 시간이 훨씬 가볍게 느껴진다고 말한다.

User Flow나 화면 설계보다 시퀀스 다이어그램을 많이 그린다

로그인 플로우를 기획한다고 가정해 보자. 화면 기획 관점에서는 일반 로그인, 소셜 로그인, 자동 로그인이라는 세 가지 흐름을 구분해서 그린다. 사용자에게 보여지는 화면 위주로 단계가 잡힌다.

플랫폼 PM의 관점에서는 다르다. 각 로그인 방식은 다른 API 구성을 가지고, 각기 다른 토큰 처리, 다른 인증 흐름, 다른 에러 케이스를 가진다. 자동 로그인의 경우 토큰을 이용해 사용자의 별도 액션 없이 진행되어야 하므로, 호출 순서와 프로세스가 화면 흐름과는 별도로 설계되어야 한다. 어떤 토큰을 언제 발급하고, 어떻게 갱신하고, 만료된 토큰은 어떤 경로로 처리할 것인지가 모두 정책 안에 들어와야 한다.

이런 흐름을 그릴 때 가장 적합한 도구가 시퀀스 다이어그램이다. User Flow는 사용자가 보는 단계의 흐름을 보여 주지만, 시퀀스 다이어그램은 그 단계 뒤에서 서버와 클라이언트가 어떤 순서로 어떤 신호를 주고받는지를 보여 준다. 플랫폼 PM은 화면 와이어프레임만큼이나 시퀀스 다이어그램을 자주 그린다. 어떤 회의에서는 화면 설계 한 장 없이 시퀀스 다이어그램 한 장만으로 한 시간이 흘러가기도 한다.

서비스 PM과 플랫폼 PM의 주요 차이

지금까지의 이야기를 한 번에 정리해 보면, 두 직무의 차이는 크게 세 가지로 좁힐 수 있다.

첫째, 서버 개발자와의 커뮤니케이션 비중이 훨씬 크다. 회의의 결도, 메신저의 결도 자연스럽게 그쪽으로 무게가 실린다.

둘째, API 문서 파악 능력과 시스템 아키텍처에 대한 이해가 핵심 역량이다. 화면을 그리는 능력보다, 데이터 흐름을 설계하는 능력이 평가의 기준이 된다.

셋째, 화면 설계 UI/UX보다 시퀀스 다이어그램을 더 자주 그린다. 작업 도구 자체가 다르다는 것은 결국 매일의 사고가 다르다는 뜻이기도 하다.

이 차이는 우열의 차이가 아니다. 서비스 PM에게 요구되는 사용성 감각, 시각적 일관성, 사용자 흐름에 대한 직관은 플랫폼 PM이 따라가기 어려운 영역이다. 반대로 플랫폼 PM이 익숙하게 다루는 시스템 사고, 데이터 흐름 설계는 서비스 PM이 한 번에 따라잡기 어려운 영역이다. 두 직무는 같은 PM이라는 단어 아래 있지만, 매일 쓰는 근육이 다른 직무다.

어디까지 알아야 하는가의 질문 앞에서

플랫폼 PM으로 일하다 보면 “나는 어디까지 알아야 하는가”라는 질문이 자주 떠오른다. 서버 구조를 어디까지 이해해야 하는지, 코드를 어디까지 읽을 줄 알아야 하는지, 시스템 다이어그램을 어디까지 그릴 수 있어야 하는지.

솔직히 말하면 끝이 없는 질문이다. 알면 알수록 더 알아야 하는 영역이 보인다. 그러나 한 가지 확실한 것은, 이 질문에 답하려는 노력 자체가 플랫폼 PM의 역량을 키운다는 점이다. 모르는 영역을 모르는 채로 두지 않고, 한 번 더 묻고, 한 번 더 정리하는 습관. 그 습관이 결국 더 단단한 기획력을 만든다.

플랫폼 PM의 일은 화려하지 않다. 화면이 직접 바뀌는 것이 보이지 않고, 사용자가 그 변화를 칭찬해 주지도 않는다. 하지만 그 변화 없이는 어떤 화면도 안정적으로 동작하지 않는다. 보이지 않는 곳을 책임지는 일의 무게를 알고 즐길 수 있다면, 플랫폼 PM은 가장 깊이 있는 PM 직무 중 하나라고 생각한다.

“너는 거기서 어떤 것을 기획하니?”라는 질문에 이제는 짧게 답할 수 있다. “사용자가 보는 화면 뒤의 흐름을 기획해요.” 짧지만, 이 한 문장에 매일의 고민이 모두 담겨 있다.