만들기 쉬워진 시대, PM은 무엇을 판단해야 할까
AI로 프로토타입을 만들기 쉬워지면 제품 관리자(PM)의 일은 줄어들까요? Gemini를 비롯한 Google의 프런티어 모델 제품 책임자 Tulsee Doshi는 오히려 무엇을 만들지 고르고, 좋은 결과의 기준을 세우며, 사람들을 같은 방향으로 모으는 역할이 더 중요해진다고 말합니다.
2026년 11월 8일 Lenny's Podcast 인터뷰에서 나온 이 주장은 PM 채용 시장의 통계가 아닙니다. 구현 속도가 빨라진 팀에서 어떤 판단이 필요한지에 대한 Doshi의 설명입니다. 그 설명은 모델의 가능성을 발견하는 일에서 시작해 평가와 제품 투자로 이어집니다.
모델의 목표를 정하는 일과 강점을 발견하는 일
Doshi는 모델 개발을 재료를 넣어도 예상하지 못한 결과가 나오는 마법약 수업에 비유합니다. 그렇다고 연구가 무작위라는 뜻은 아닙니다. 모델 개발에 관한 대화에서 그는 연구자들이 학습을 지속해서 관찰하고, 지표를 추적하며, 개입할 시점을 판단한다고 설명합니다.
PM의 일은 학습 전에 원하는 능력과 목표를 정하는 데서 끝나지 않습니다. 나온 모델을 직접 써 보면서 어떤 작업에서 예상 밖의 강점이 드러나는지, 그 강점을 사용자에게 어떤 경험으로 제공할지 찾아야 합니다. 계획한 기능이 구현됐는지만 확인하는 것과 달리, 결과를 관찰하면서 제품의 가능성도 다시 해석하는 일입니다.
Google의 전략을 설명하는 구간에서도 같은 관점이 나옵니다. Doshi는 하드웨어에서 모델, 최종 사용자 제품까지 이어지는 구조와 비용, 품질의 여러 지점에 있는 모델을 함께 이야기합니다. 가장 높은 성능을 추구하는 일과 다양한 사용자의 작업에 맞는 경험을 제공하는 일을 별개의 목표로 버리지 않는다는 설명입니다.
화면뿐 아니라 모델의 응답에도 UX가 있습니다
Doshi가 말하는 모델의 사용자 경험은 모델이 얼마나 투명하게 설명하는지, 사용자와 어떻게 소통하는지, 어떤 질문을 되묻는지까지 포함합니다. 버튼과 메뉴를 잘 배치해도 모델의 행동이 사용자에게 맞지 않으면 경험 전체가 달라집니다.
그는 사용자 피드백과 Gemini에 바라는 행동을 명세로 정하고, 이를 평가 기준인 루브릭으로 옮기는 과정을 설명합니다. 그 기준은 다시 모델에 활용할 데이터와 보상 모델링으로 연결됩니다. PM의 판단이 연구와 만나는 지점은 막연히 답변을 더 좋게 해 달라고 요청하는 데 있지 않고, 무엇을 좋은 행동으로 볼지 구체화하는 데 있습니다.
이 관점에서 PM의 가치는 생산량보다 방향에 가깝습니다. PM의 역할을 다룬 대화에서 Doshi는 좋은 경험을 만드는 통찰과 합의 형성을 강조합니다. 빠르게 만들 수 있어도 방향을 정리하지 못하면 속도가 혼란을 키울 수 있다는 것입니다.
첫 평가는 프롬프트 5개로도 시작할 수 있습니다
첫 평가를 만드는 방법에 대한 Doshi의 조언은 대규모 벤치마크부터 만들지 말라는 것입니다. 프롬프트 5개로 시작하고, 직접 응답을 읽어 좋고 나쁨을 판단할 수 있습니다. 특정 능력을 시험하는 프롬프트 20개 정도만 있어도 모델 사이의 차이를 발견하는 데 도움이 된다고 설명합니다.
작은 평가의 목적은 적은 표본으로 보편적인 성능 순위를 확정하는 것이 아닙니다. 여러 단계를 거치는 긴 작업에서 무엇을 좋은 결과로 보는지 평가자 자신부터 명확히 하는 데 있습니다. 좋은 예시가 모이면 그다음에 평가를 확장할 수 있습니다.
모델을 써 보며 느끼는 감각과 체계적인 평가도 서로를 대체하지 않습니다. Doshi는 자신이 관심 있고 판단할 수 있는 작업으로 모델을 시험하라고 제안합니다. 이미 가능성이 보이지만 아직 완벽하지 않은 작업이라면, 모델마다 문제를 어떻게 다르게 다루는지 관찰하기 쉽다는 설명입니다.
평가 대상은 모델 하나가 아니라 사용자가 겪는 전체 경험입니다
평가 질문을 잘 골라도 평가 환경이 어긋날 수 있습니다. Doshi는 평가하는 모델뿐 아니라 판정자 자체의 품질, 운영 환경의 필터와 안전장치, 모델을 제공하는 방식까지 살펴야 한다고 말합니다. 사용자에게 도달하기 전에 거치는 단계가 결과에 영향을 줄 수 있기 때문입니다.
그가 든 예는 음성 모델입니다. 말의 내용뿐 아니라 목소리의 자연스러움과 억양도 경험을 구성하며, 모델을 제공하는 방식이 여기에 영향을 줄 수 있습니다. 따라서 텍스트 답변만 비교한 결과를 그대로 음성 제품 전체의 평가로 옮길 수는 없습니다.
60-20-20은 미래 출시일을 맞히는 공식이 아닙니다
Doshi의 60-20-20 제안은 현재 작동하는 기능과 모델이 나아졌을 때 열릴 가능성을 함께 담는 방식입니다. 그는 숫자 자체는 바꿀 수 있다고 전제합니다. 핵심은 지금 사용할 수 있는 제품을 유지하면서 미래의 성능 향상을 받아들일 여지를 두는 데 있습니다.
| 비중 | 현재 상태 | 제품에서 맡는 역할 |
|---|---|---|
| 60% | 지금 작동함 | 프로토타입이 실제로 기능하는 기반 |
| 20% | 완벽하지 않지만 어느 정도 작동함 | 가까운 시기에 모델이 더 잘할 가능성을 보는 영역 |
| 20% | 가능성의 단서가 보임 | 해결되면 새로운 경험을 만들 수 있는 탐색 영역 |
이 비중은 모델의 성공률이나 팀의 근무시간 배분을 뜻하지 않습니다. Doshi가 말한 대상은 만들고 있는 제품의 기능 구성입니다. 그 자신도 모델이 3개월 뒤 어디까지 발전할지 정확히 말하기 어렵다고 설명하며, 달력 대신 자기 제품에서 관찰한 가능성을 기준으로 삼습니다.
제품을 모델 개선에 맞춰 바꿀 수 있어야 한다는 조건도 붙습니다. 그는 기존 모델에 맞춘 경직된 구조가 새 모델의 능력을 가로막을 수 있다며 재평가를 권합니다. 시스템 지시, 도구, 스킬, 컨텍스트로 구성된 실행 환경인 하네스도 모델과 함께 다시 검토할 대상입니다.
문서의 양 대신 판단의 근거를 남깁니다
인터뷰 후반의 AI 문서에 관한 대화에서 Doshi는 출시 후 사용 현황과 피드백을 모으는 일을 AI가 도울 수 있는 예로 듭니다. 반면 데이터에서 어떤 통찰을 얻을지는 사람이 맡아야 한다고 구분합니다. AI가 문서를 만들 수 있다는 사실과, 그 문서에 제품 판단이 담겼다는 사실은 다릅니다.
PM 역할의 변화에 대한 설명도 여기에 닿습니다. 요구사항을 적고 다른 직군이 구체화하기를 기다리는 데서 한 단계 더 나아가, 프로토타입이든 평가든 데이터든 요구사항을 뒷받침하는 근거를 가져와야 한다는 것입니다.
이 인터뷰에서 PM의 가치는 직함만으로 보장되지 않습니다. 모델이 잘하는 일을 발견하고, 좋은 결과의 기준을 만들고, 지금 작동하는 기능과 아직 불확실한 가능성을 구분하는 판단에 있습니다. 구현이 빨라져도 무엇을 왜 만들지 설명하는 일은 남습니다.