언젠가 뉴스 비평 005
최근 한 뉴스레터를 보았다. "실리콘밸리는 왜 PM을 지우기 시작했나"라는 제목의 글은 프로덕트 엔지니어(Product Engineer)의 부상과 YC 스타트업들의 "No PMs" 선언을 전했다. 그러면서 PM의 생존 전략으로 "바이브 코딩을 배워 엔지니어의 손을 훔치라"고 조언했다.
공감되는 지점이 많다. 단순히 요구사항 정의서(PRD)나 쓰고 앉아있는 PM의 입지는 분명 축소되고 있다. 디자이너, 엔지니어, 관리자 사이의 물리적 경계는 무너지고 있다. 이제 모두가 AI 에이전트를 진두지휘하는 '빌더(Builder)'로 융합되는 시대다.
하지만 방향에 대해서는 다르게 생각한다. PM은 코드가 아니라 비즈니스를 배워야 한다. 엔터프라이즈급 코딩은 결국 AI로 무장한 전문 소프트웨어 엔지니어가 더 빠르게 점령할 것이기 때문이다. PM의 고유 영역은 제품의 '진화 경로'를 설계하는 비즈니스 전략가로서의 정체성에 있다. 토스와 당근의 사례가 이를 증명한다.
진화 설계의 핵심은 데이터가 말하지 않는 현상 너머의 가치를 포착하여 문제를 다시 정의하는 것이다.
1.1. 토스(Toss): 간편송금에서 금융 문해력으로의 전환
토스는 2015년 "3초 송금"이라는 명확한 문제 해결로 시작했다. 하지만 PM은 곧 더 본질적인 기회를 포착했다. 사용자들이 송금 화면에서 머뭇거리는 진짜 이유는 '복잡함'이 아니라 '두려움'이었다. "이체", "계좌번호", "수취인" 같은 금융 용어 자체가 장벽이었던 것이다.
제품 관리자의 결단은 여기서 시작되었다. "이체"를 "보내기"로 바꾼 것은 단순한 UX 튜닝이 아니었다. 금융을 전문가의 영역에서 '일상의 언어'로 재정의하는 철학적 전환이었다. 더 대담한 판단은 수익 모델이었다.
송금 수수료를 포기하고 완전 무료로 간 것은, 단기 재무 손실을 감수하고 '금융의 대중화'라는 시장 교육에 투자하는 선택이었다. 이는 명백한 '전략적 불균형' 설계였다. 결과적으로 토스는 송금으로 확보한 사용자 기반을 대출, 투자, 보험으로 연결하며 "금융 슈퍼앱"으로 진화했다.
지금 바로 작가의 멤버십 구독자가 되어
멤버십 특별 연재 콘텐츠를 모두 만나 보세요.
오직 멤버십 구독자만 볼 수 있는,
이 작가의 특별 연재 콘텐츠