에이전트 시대 PM의 일은 결정이다: 로비 스타인의 3단계

AI 에이전트가 웬만한 것은 다 만들어 주는 시대에, PM의 가치는 일을 관리하는 데서 "무엇을 만들지 정하는 판단"으로 옮겨 갑니다. 그 판단은 사람을 깊이 이해하고, 안 되는 이유의 뿌리를 찾고, 품질을 끝까지 다듬는 세 단계로 훈련할 수 있고, 세 단계 모두 AI로 규모를 키울 수 있습니다.

요약

인스타그램 스토리와 릴스를 만든 팀을 이끌었고 지금은 구글에서 검색 제품을 맡고 있는 부사장 로비 스타인(Robby Stein)이 2026년 9월 Lenny and Friends Summit에서 한 강연을, 유튜브 채널 AgentOS가 한국어로 해설한 영상입니다. 스타인은 PM의 일을 한마디로 결정이라고 봅니다. 그리고 좋은 결정을 세 단계로 나눕니다. 첫째, 사람을 깊이 이해합니다. 사람들이 어떤 “일”을 해내려고 제품을 고용하는지 보는 JTBD(Jobs to be Done) 관점으로 사용자의 이야기를 듣습니다. 둘째, 근본 원인을 진단합니다. 일단 내놓고, 쓰지 않는 사람에게 이유를 묻고, 답을 주제별로 묶고, 대규모 설문으로 주제마다 비중을 매긴 뒤 가장 큰 원인 하나를 고치고 다시 돌립니다. 그는 이 반복을 모델 학습의 에폭(같은 데이터를 한 바퀴 돌며 고쳐 가는 단위)에 빗댑니다. 셋째, 크래프트입니다. 안 되는 기능은 과감히 걷어 내고, 되는 것은 더 단순한 형태로 다시 내놓고, 작은 즐거움(delight)까지 챙깁니다.

사례도 이 순서를 따릅니다. 인스타그램 스토리는 사람들이 왜 올리지 않는지 알아내고 고치는 데 2년 가까이 걸렸고, 메인 피드에서 완전히 떼어 낸 뒤에야 자리를 잡았습니다. 친한 친구(Close Friends) 기능도 피드나 즐겨찾기로 둘 때는 헷갈렸지만 스토리 안의 경험으로 옮기자 제대로 작동했습니다. 릴스는 브라질에서 먼저 내놓은 사례로 소개되는데, 팀은 콘텐츠가 사라지는 형식이어야 한다고 봤지만 크리에이터들은 오래 남아 사업이 되고 널리 퍼지는 콘텐츠를 원했고, 이를 행동 데이터에 맞춘 대규모 개편으로 바로잡았습니다. AI 쪽으로는 구글 검색의 멀티모달 입력과 AI 모드, 대규모 사용자 피드백 수집, 그리고 스타인이 직접 만든 평가 에이전트가 나옵니다. 이 에이전트는 루브릭(채점 기준표)에 따라 검색 답변을 검사해 수식이나 LaTeX가 깨졌는지, 시각 요소가 빠졌는지를 잡아내고, 점점 스스로 고치기까지 합니다. 즐거움의 예로는 검색창의 그라데이션 커서, 로딩 링, 햅틱 피드백을 듭니다. 아래 두 절은 이 3단계를 실제 팀에서 돌릴 때 필요한 기술 설정과 실행 계획입니다.

기술 디테일: 세 단계를 AI로 넓히려면

1단계는 인터뷰를 “JTBD 문장”으로 바꾸는 파이프라인으로 만듭니다. 사용자 인터뷰 녹취를 전사한 뒤, LLM에게 아래처럼 정해진 필드로 뽑게 하면 인터뷰 20건이 비교 가능한 표가 됩니다. 사용자가 보여 준 사진이나 화면 캡처도 함께 넣으면(멀티모달 입력) 말로는 설명하지 못한 상황이 드러납니다. 인용 위치(quote_ref)를 필수로 두면 AI가 지어낸 동기를 걸러 낼 수 있습니다.

{
  "interview_id": "U07",
  "situation": "주간 회의 직전, 지난주 불량 건을 정리해야 할 때",
  "motivation": "팀장에게 원인을 한 장으로 설명하고 싶다",
  "desired_outcome": "10분 안에 원인별 건수와 대표 사례를 뽑는다",
  "current_solution": "엑셀 필터 + 사진 폴더 수동 확인",
  "pain": "사진과 기록이 따로 있어 맞추는 데 1시간",
  "quote_ref": "00:14:32-00:15:10"
}

인터뷰 에이전트는 진행보다 기록에 먼저 씁니다. AI가 인터뷰를 직접 진행하게 할 수도 있지만, 처음에는 사람이 진행하고 AI는 실시간 전사, 다음 질문 제안(“그때 실제로 무엇을 했나요?”처럼 행동을 묻는 후속 질문), 인터뷰 직후 위 JSON 정리를 맡게 하는 편이 안전합니다. 사람이 진행한 10건과 AI가 정리한 결과를 비교해 빠뜨린 항목이 없을 때 AI 진행으로 넓힙니다.

2단계는 “왜 안 쓰나”를 열린 질문 하나로 대량 수집하고 군집으로 묶습니다. 제품 안 설문이나 이탈 시점 팝업으로 “이번에 쓰지 않은 가장 큰 이유는 무엇인가요?”를 묻고 응답 500건 이상을 모읍니다. 응답을 임베딩해 8~12개 군집으로 묶고, LLM이 군집마다 이름과 대표 응답 3개를 붙이게 합니다. 군집 이름은 사람이 대표 응답을 읽고 확정합니다. LLM이 붙인 이름만 보고 결정하면 해석이 한 번 더 비틀립니다.

주제의 비중은 두 번째 설문으로 잽니다. 확정한 상위 주제 6~8개를 선택지로 만든 객관식 설문을 300명 이상에게 돌려 비율을 구합니다. 첫 설문의 군집 크기는 “말이 많은 주제”일 뿐이라, 실제 비중은 선택지 설문으로 따로 확인해야 합니다. 가장 큰 원인 하나만 고치고, 같은 두 설문을 다시 돌려 비율이 줄었는지 봅니다. 이것이 한 번의 에폭입니다.

3단계 크래프트는 평가 에이전트를 출시 전 관문으로 둡니다. 대표 사용 시나리오 200개를 회귀 세트로 만들고, 루브릭 항목마다 통과·실패와 근거를 받는 LLM 평가자(LLM-as-judge)를 배포 전마다 돌립니다. 항목은 “수식이 깨지지 않았나”, “필요한 표나 그림이 빠지지 않았나”, “질문에 직접 답했나”처럼 예·아니오로 판정할 수 있게 씁니다.

{
  "case_id": "Q-0142",
  "checks": [
    { "rule": "수식·LaTeX가 정상 렌더링", "pass": false, "evidence": "3번째 줄 \\frac 닫힘 누락" },
    { "rule": "요청한 표가 포함됨", "pass": true },
    { "rule": "첫 문장에서 질문에 직접 답함", "pass": true }
  ],
  "auto_fix_suggested": true
}

평가자도 평가합니다. 매주 평가 결과 50건을 사람이 다시 채점해 사람과 평가자의 판정 일치율을 봅니다. 일치율이 90% 아래로 떨어지는 항목은 루브릭 문구를 고칩니다. 자동 수정은 처음에는 제안만 받고, 사람이 승인한 수정이 쌓여 같은 유형이 반복되면 그 유형만 자동 적용으로 넓힙니다.

현업 실행 디테일: 누가, 언제, 무엇을

네 사람이 한 사이클을 돕니다.

역할	누가	맡는 일
결정 오너	PM	사이클 목표 설정, 원인 하나 선택, 걷어 낼 기능 결정, 결정 기록
사람 이해	UX 리서처 (없으면 PM)	인터뷰 진행, JTBD 표 검토, 군집 이름 확정
원인 측정	데이터 분석가	두 설문 설계·배포, 비율 계산, 핵심 행동 지표 추적
품질 관문	엔지니어 1명	회귀 세트·평가 에이전트 운영, 일치율 점검

시작 전에 정할 것. 이번 사이클에서 늘리려는 핵심 행동 하나(예: 첫 게시, 첫 리포트 생성), 그 행동의 현재 전환율, 인터뷰 대상 12명 명단, 설문을 띄울 위치와 시점입니다.

기간	할 일	산출물
1주차	사용자 12명 인터뷰, JTBD 표 작성	JTBD 표, 상위 “일” 3개
2주차	“왜 안 쓰나” 열린 설문 500건 → 군집 → 선택지 설문 300건	원인별 비율표
3주차	가장 큰 원인 하나 수정, 반응 없는 기능 1개 걷어 내기	변경 명세, 걷어 낸 기능 목록
4주차	평가 에이전트 통과 후 출시, 두 설문과 핵심 지표 재측정	결정 기록 1장, 다음 사이클 원인 후보

결정 기록은 한 장으로 남깁니다. 무엇을 결정했나, 근거가 된 데이터(JTBD 표의 어느 줄, 원인 비율 몇 %), 버린 대안과 버린 이유, 다시 볼 날짜 네 칸이면 됩니다. 에이전트가 만드는 속도가 빨라질수록 “왜 이걸 만들었나”가 기록으로 남아 있어야 다음 결정이 빨라집니다.

다음 사이클로 넘어갈 기준을 미리 정합니다. 예를 들어 고친 원인의 응답 비율이 절반 이하로 줄고 핵심 행동 전환율이 2%p 이상 오르면 다음 원인으로 넘어가고, 둘 다 움직이지 않으면 같은 원인을 다른 방식으로 한 번 더 고칩니다. 기준은 사이클을 시작하기 전에 적어 둬야 결과를 보고 끼워 맞추지 않습니다.

AX 프로젝트에 쓸 때. 기업에 AI 도구를 들였는데 현업이 쓰지 않는다면, 이 3단계가 그대로 도입 진단 방법이 됩니다. 품질팀이 불량 판정 AI를 왜 안 쓰는지 JTBD로 듣고(회의 전 보고서를 빨리 만드는 게 진짜 “일”일 수 있습니다), 이유를 비율로 재고(판정 근거가 안 보여서인지, 기존 시스템과 따로 놀아서인지), 가장 큰 원인 하나를 고친 뒤 평가 에이전트로 판정 품질을 관문으로 지킵니다. 이때 결정 오너는 FDE(현장에 배치된 엔지니어)와 현업 스폰서가 함께 맡는 것이 좋습니다.

원문 사례

항목	내용
강연자	로비 스타인(Robby Stein). 인스타그램 스토리·릴스를 만든 팀을 이끌었고, 현재 구글 검색 제품 부사장
강연	Lenny and Friends Summit 2026(2026년 9월), “What it takes to be a top PM today”
영상	AgentOS 채널의 한국어 해설, 2026년 10월 13일 공개, 약 21분
핵심 주장	에이전트가 무엇이든 만드는 시대에 PM의 가치는 판단이며, PM의 일은 결정이다
결정 3단계	① 사람 이해(JTBD) ② 근본 원인 진단(묻기 → 주제 군집 → 설문으로 비중 → 가장 큰 원인 수정 → 반복) ③ 크래프트(걷어 내기, 단순하게 다시 내기, 즐거움)
스토리 사례	사람들이 올리지 않는 이유를 찾고 고치는 데 2년 가까이 걸림. 메인 피드에서 떼어 낸 뒤 정착. 친한 친구 기능은 스토리 안으로 옮기자 작동
릴스 사례	브라질 선출시 사례로 소개. 사라지는 콘텐츠를 가정했으나 크리에이터는 오래 남고 퍼지는 콘텐츠를 원함 → 대규모 개편
AI 활용	멀티모달 입력·AI 모드(구글 검색), 대규모 피드백 수집, 루브릭으로 검색 답변을 검사하고 고치는 자체 평가 에이전트
즐거움 예시	검색창의 그라데이션 커서, 로딩 링, 햅틱 피드백

핵심 개념

JTBD

Jobs to be Done. 사람은 제품을 사는 게 아니라 어떤 "일"을 해내려고 제품을 고용한다는 관점. 기능 요청보다 그 사람이 처한 상황과 원하는 결과를 묻습니다.

근본 원인 진단

쓰지 않는 이유를 모아 주제로 묶고, 주제마다 비중을 잰 뒤 가장 큰 것 하나부터 고치는 반복.

에폭

모델 학습에서 데이터를 한 바퀴 돌며 고쳐 가는 단위. 여기서는 "묻고, 재고, 고치고, 다시 재는" 한 사이클을 뜻합니다.

크래프트

만듦새. 안 되는 것을 걷어 내고 되는 것을 단순하게 다듬어, 작은 디테일까지 신경 쓴 제품을 만드는 일.

평가 에이전트

정해진 채점 기준(루브릭)으로 AI의 결과물을 자동 검사하는 에이전트. 사람이 다 볼 수 없는 양의 품질을 지키는 관문 역할을 합니다.

내 메모

TODO: 내 생각 추가

원문은 로비 스타인의 Lenny and Friends Summit 2026 강연과 이를 해설한 AgentOS의 유튜브 영상입니다. 요약은 영상과 공개된 강연 요약을 바탕으로 AX Review가 다시 정리한 것이고, 기술·현업 실행 디테일, JSON 예시, 일정표, 도식은 새로 작성했습니다. 강연 전체는 원문 영상에서 볼 수 있습니다.