2027년을 계획하지 말라: OpenAI가 90일 단위로 제품을 만드는 법

URL: https://www.youtube.com/watch?v=-ciSTkEVy30
날짜: 2026-09-30
채널: Lenny's Podcast
원문 제목: Stop planning for 2027: how OpenAI builds product 90 days at a time | Tara Sesha and Nan Yu (OpenAI)

📌 핵심 질문

==모델 능력과 사용자의 기대가 몇 주 단위로 변하는 환경에서, 제품팀은 어떻게 완벽주의와 장기 예측을 버리고 안전한 실험·학습·제품 진화를 반복할 것인가?==

• 완벽한 설계를 먼저 만드는 대신 불완전하더라도 실제 사용자의 손에 기능을 넣고 경험적 증거로 빠르게 고친다.
• 제품의 미래를 수년 단위로 단정하지 않고, 대략 2~3개월 뒤의 모델 능력에 맞춰 제품을 설계한다.
• 사용자 공감(user empathy), 시스템 사고(systems thinking), 끈질긴 반복(relentless iteration)을 함께 사용한다.
• 플랫폼의 기본 기능, 서드파티 확장, MCP, Computer Use를 계층으로 묶어 첫 경로가 실패해도 사용자가 목표를 달성하게 만든다.

빠르게 변하는 AI 제품에서 좋은 판단은 ‘현재의 완성도’와 ‘미래의 환상’ 중 하나를 고르는 일이 아니다. 사용자가 실제로 가치를 얻는 작고 이해 가능한 변화를 출시하고, 사용자가 그 변화를 흡수하는 속도와 모델이 도달할 가능성이 높은 가까운 미래를 관찰하면서 다음 90일을 결정하는 일이다.

1. 완벽주의에서 불완전한 출시로

완벽한 제품을 사전에 증명하려는 태도보다, 실제 사용에서 얻는 경험적 증거를 빠르게 확보하는 태도가 AI 시대의 제품 개발에 더 적합하다.

1.1. ‘토글(toggle)’을 둘러싼 불완전한 출시

1. AI 제품에는 양면이 있다는 도입

   1. Claire는 모든 AI 제품에 ‘왼쪽 토글과 오른쪽 토글’이 있는 것처럼, 어떤 상태를 선택해야 할지 사용자가 고민하는 표면이 생긴다고 농담한다.
   2. 반복적 제품 개발(iterative product development)과 불완전한 기능의 출시가 논의되는 상황에서, 완벽하지 않은 것을 세상에 내놓는 판단 기준이 핵심 질문이 된다.

2. Tara Sesha가 완벽주의를 버린 계기

   1. Tara는 아시아계 부모 밑에서 자라 매번 완벽한 결과물을 내야 한다는 압박에 익숙했으며, 불완전한 결과를 내놓는 방식이 처음부터 편하지 않았다고 말한다.
   2. Stripe에서 약 7년을 일하며 모든 것이 깊이 다듬어지고, 결정 하나를 100번 검토하고, enum 이름까지 정확한지 확인하는 문화를 경험했다.
   3. AI 시대에는 기능을 내놓는 긴급성(urgency) 자체가 중요해졌다. 출시 전 이론화와 토론을 아무리 많이 해도 사용자가 실제로 써보는 경험적 증거(empirical evidence)를 대체할 수 없다.

3. 사전 완성도보다 출시 후 학습 속도

   1. 핵심 사고방식은 “처음부터 완벽하게 만드는가(a priori), 아니면 출시한 뒤 가능한 한 빠르고 효과적으로 반복하는가”의 전환이다.
   2. 토글은 이상적인 해결책이 아니며 불완전하다. 그럼에도 ChatGPT를 사용하는 10억 명이 넘는 사용자에게 에이전트가 일을 수행하는 **에이전틱 하네스(agentic harness)**를 전달하려면, 개발자 워크플로를 깨뜨리지 않는 형태로 먼저 출시할 필요가 있었다.
   3. 기능의 최종 형태보다 중요한 것은 새로운 에이전트 능력을 대규모 사용자에게 실제로 노출하고, 그 사용에서 다음 설계의 근거를 얻는 일이다.

1.2. 폐기와 진화를 사용자의 여정으로 만들기

1. 제품과 코드를 만들고 버리는 시대

   1. 현재는 코드든 제품이든 만들었다가 버려야 하는 양이 많다. 따라서 무엇을 폐기(deprecate)하고 무엇을 유지할지에 대한 판단이 제품 리더의 일상적인 문제가 된다.
   2. 토글의 자연스러운 다음 단계는 사용자가 더 이상 토글을 보지 않아도 되는 상태다. 단계 A에서 단계 B로 넘어가는 진화의 서사가 이미 제품 안에 들어 있다.

2. 변화에 대한 사용자의 수용성을 높이는 조건

   1. 사용자가 단계 A에서 단계 B로 가는 여정을 따라갈 수 있으면, 제품이 바뀌거나 방향을 전환해도 훨씬 잘 받아들인다.
   2. 무엇이 내부에서 일어나고 있는지 어느 정도 이해하고 투명성을 느끼면 변화가 갑작스러운 배신으로 보이지 않는다.
   3. 사용자가 실제로 주의를 기울이는 정도를 고려해도, 일관된 이야기(coherent story)를 제공하면 상당한 변화를 일으키면서도 신뢰를 잃거나 다리를 불태우지 않을 수 있다.

1.3. 빠른 제품에서 품질 기준을 지키는 법

1. 사용자 가치가 실제로 더해지는가

   1. 기능이 사용자에게 부가적인 가치(additive value)를 열어 주는지, 단순히 새로워 보이는 것이 아니라 실제로 유용한지를 먼저 본다.
   2. 새로운 기능이 모델의 새로운 사용 사례를 열거나, 기존 경험에 놀랍고 기쁜 순간을 더하는지 확인한다.

2. 내부 사용을 품질 게이트로 삼기

   1. 제품을 출시하기 전에 내부에 배포해 모두가 사용하게 하고, 내부에서 실제 채택과 유지(retention)가 나타나는지 확인한다.
   2. 내부 사용량에 고정된 숫자 기준을 두기보다는, 사람들이 계속 쓰는지, 놀랍도록 좋은 점을 발견하는지, 새로운 모델 능력을 체감하는지를 종합적으로 판단한다.

3. 모델 능력보다 앞서가되 너무 멀리 가지 않기

   1. 제품은 현재 모델에 과도하게 묶이지 않으면서도, 수년 뒤의 공상적인 능력을 전제로 해 unusable한 제품이 되어서도 안 된다.
   2. 이상적인 지점은 모델이 도달할 가능성이 높은 2~3개월 뒤다. Tara는 이를 현재보다 충분히 ‘AGI에 가까운(AGI pill)’ 모델의 능력을 겨냥하는 구간으로 표현한다.
   3. 품질 기준은 결국 “가치가 있는가, 사용자가 신경 쓰는가, 놀랍도록 좋은가, 모델 능력의 방향과 맞는가, 모델이 잘 일하는 데 방해되지 않는가”로 요약된다.

4. 사용자가 변화 자체를 흡수할 수 있는가

   1. Nan Yu가 꼽은 가장 큰 제약은 팀의 상상력이나 모델의 능력이 아니라 사용자가 주어진 변화를 이해하고 흡수하는 능력이다.
   2. **능력 과잉(capability overhang)**은 모델이 할 수 있는 일과 사용자가 실제로 활용하는 일 사이의 격차를 뜻한다. 모델에 아무리 많은 기능을 넣어도 사용자가 그 능력을 흡수하지 못하면 제품 가치는 확장되지 않는다.

2. 기업 고객과 에이전트 전환의 속도

기업이 변화를 흡수하기 어렵다는 통념은 여전히 일부 사실이지만, 최전선의 변화를 전달하지 않으면 기업 자체가 경쟁 제품에 뒤처질 수 있다.

2.1. ‘기업은 변화를 흡수하지 못한다’는 통념

1. AI의 변화 속도는 기업 입장에서 ‘초과속’이다

   1. 현재 속도는 많은 기업에게 단순히 빠른 정도를 넘어 ‘브레이크넥(breakneck)을 넘어선’ 속도처럼 느껴진다.
   2. 기능과 발전이 한꺼번에 쏟아지는 모습은 “라팔루자(Lollapalooza) 같은 기능 축제”라는 농담으로 표현될 만큼 압도적일 수 있다.

2. 그러나 최신 변화의 지연도 위험하다

   1. 최전선의 기능을 기업에 전달하지 않으면 고객이 다른 제품으로 넘어가며 시장에서 추월당한다.
   2. OpenAI의 많은 기업 고객은 처음에 ChatGPT를 질문하고 답을 받는 채팅 도구로만 사용하고 있었다.
   3. 그 사이 에이전트 혁명이 진행됐고, 기업이 더 큰 가치를 얻으려면 에이전트를 가능한 한 빨리 전달해야 했다.

2.2. 사용자가 말하는 요구보다 실제로 필요한 것을 전달하기

1. 기존 프로세스를 깨뜨리는 변화의 필요성

   1. 기업이 일상적으로 변화를 흡수하는 속도에 맞추기만 하면, 질문·답변 중심의 기존 사용 방식에 머물게 된다.
   2. 에이전트를 도입하려면 기업의 프로세스와 ‘기업은 업데이트를 이렇게 받아야 한다’는 관념을 크게 깨뜨리는 변화가 필요했다.

2. 제품 개발의 오래된 원칙이 더 강하게 적용된다

   1. “사용자가 말하는 것이 아니라 사용자가 필요로 하는 것을 하라”는 제품 개발의 격언이 AI 시대에는 더 중요해진다.
   2. 기업 고객이 변화가 어렵다고 말하더라도, 실제로 필요한 혁신이 있다면 그 가치를 열어 주는 방향으로 속도를 내야 한다.

3. 하나의 에이전트인가, 여러 전문 에이전트인가

에이전트의 정체성은 철학적 선택처럼 보이지만, 실제 제품 설계에서는 메모리·권한·자격 증명·사용 사례를 구체적으로 결정해야 하는 시스템 문제다.

3.1. 중앙 에이전트와 마이크로 에이전트의 긴장

1. 두 가지 설계 방향

   1. 하나의 범용 에이전트 정체성에 집중해 무엇이든 처리하게 하고, 모델이 자연스럽게 능력을 발휘하도록 제품이 방해하지 않는 방향이 있다.
   2. 반대로 특정 업무를 위해 세밀하게 설계한 프롬프트·지침을 가진 작은 전문 에이전트들을 여럿 두는 방향이 있다.
   3. Claire는 자신의 컴퓨터에 상주하며 하루 종일 대화하는 단일 Codex와, 사업의 여러 부분을 지탱하는 40개의 Grok 봇을 대비해 질문한다.

2. 인간의 작업 기억에 맞추는 설계

   1. Nan은 가장 성공적인 설계가 인간 본성에 맞춰진다고 본다. 사람은 수백만 년의 진화를 통해 머릿속에 여러 일을 담고 관리하는 방식이 형성되어 있다.
   2. 에이전트 40개는 대부분의 사람에게 지나치게 많다. 40명의 직원을 직접 관리할 수 있겠느냐는 질문에 Jensen Huang 정도라면 가능할지 몰라도, 많은 사람은 계속 이어지는 40개의 업무 흐름을 따라가기 어렵다고 느낄 것이다.
   3. 따라서 에이전트를 활동 묶음(bundle of activity)으로 그룹화해야 한다.

3. Chief of Staff 에이전트라는 ‘관리의 우회’

   1. 여러 에이전트를 관리하는 사용자에게 실제로 어떻게 하느냐고 물으면, 다른 모든 에이전트를 관리하는 Chief of Staff 에이전트를 먼저 둔다고 답하는 경우가 많다.
   2. Nan은 이를 “7개를 관리하는 대신 팀을 운영하는 1개를 관리하는 셈”이라고 농담한다. 복잡성을 없앤 것이 아니라 상위 에이전트 아래로 묶은 것이다.

3.2. 정체성 논쟁을 실제 제품 문제로 바꾸기

1. 데이터 접근과 권한

   1. 단일 에이전트가 서비스 계정과 사용자의 개인 계정 사이를 어떻게 전환할지 정해야 한다.
   2. 그 권한 변화가 사용자에게 이해하기 쉬운 방식으로 표시되어야 한다.

2. 메모리의 분절과 맥락

   1. 단일 에이전트가 Slack의 비공개 채널에 들어갈 때마다 별도의 에이전트처럼 분리된 기억을 가져야 하는지 결정해야 한다.
   2. Claire는 이를 영화 Severance처럼 채널마다 기억이 단절되는가라는 비유로 묻는다.

3. 자격 증명과 사용자별 대화

   1. 에이전트가 각 사람의 자격 증명을 사용할지, 보편적인 자격 증명 집합을 사용할지에 따라 보안과 책임 모델이 달라진다.
   2. 에이전트가 누구와 대화하는지, 어떤 데이터에 접근하는지, 어떤 메모리를 이어 가는지는 철학보다 구체적인 사용 사례와 에지 케이스가 결정한다.

4. 에이전트 제품을 만드는 세 가지 역량

사용자 공감과 시스템 사고는 새로운 원칙이 아니라 기존 제품 관리 원칙의 재등장이다. AI 시대에는 여기에 빠른 실험과 반복을 견디는 끈기가 더해진다.

4.1. 인간적인 설계와 시스템 설계

1. 사용자 공감(user empathy)

   1. 사용자의 머릿속에 들어가 그들이 무엇을 정신 모델(mental model)로 갖고 있는지 파악해야 한다.
   2. 사람들이 세상과 상호작용하는 방식에 맞춰 제품이 문제를 만지고 해결하는 가장 자연스러운 접점을 찾아야 한다.

2. 시스템 사고(systems thinking)

   1. 사용자에게 아이디어를 현실적인 제품으로 전달하려면 플랫폼 구성 요소, 시스템, 에지 케이스를 모두 고려해야 한다.
   2. 제품이 실제 세계에서 일관되고 sensible하게 작동하도록 아키텍처와 운영 경로를 설계해야 한다.

3. Inception과 Severance 비유

   1. Claire는 사용자 마음속에 들어가는 일을 Inception의 ‘침투’에, 정체성과 기억이 분리되는 문제를 Severance에 빗대며 제품 작업의 양면을 설명한다.
   2. 좋은 에이전트 경험은 이 두 측면을 동시에 해결해야 한다. 사용자가 자연스럽게 이해하는 경험과 그것을 뒷받침하는 복합 시스템이 함께 필요하다.

4.2. 끈질긴 반복과 학습 속도

1. 기존 원칙을 새로운 기술에 적용하기

   1. 시스템 사고와 사용자 공감은 고전적인 제품 관리 원칙이다. 기술 세계가 달라졌어도 원칙 자체는 사라지지 않고 새로운 형태로 다시 적용된다.
   2. 추상적으로 생각하는 습관만으로는 부족하며, 실제 에이전트를 계속 사용해 보며 원칙을 구체적인 동작으로 검증해야 한다.

2. 반복을 버티는 끈기

   1. Nan은 사용자 공감과 시스템 사고에 더해, “시도하고 계속 반복하는 끈질김”이 반드시 필요하다고 말한다.
   2. 무엇이 작동하는지 알아내려면 고통을 감수하면서도 같은 시도를 계속하고, 실패와 성공을 모두 다음 시도의 재료로 삼아야 한다.

3. 피드백 루프의 시계 속도

   1. 피드백 루프에서 배우는 능력은 예전에도 필요했지만, AI 제품에서는 루프의 시계 속도(clock speed)가 훨씬 빨라졌다.
   2. Claire는 이를 “항상 많은 스파게티를 많은 벽에 던지는 일”이라고 표현한다. Chief of Staff 에이전트가 다른 에이전트들에게 스파게티를 벽에 던지라고 시키는 장면도 농담으로 이어진다.

5. 플랫폼과 생태계: 계층형 도구와 Computer Use

좋은 플랫폼은 하나의 도구로 모든 일을 강제하지 않는다. 기본 기능·확장 기능·화면 조작을 계층으로 연결해 사용자의 목표가 끝까지 완료되게 한다.

5.1. ChatGPT를 플랫폼으로 설계하기

1. 플랫폼 안에 무엇을 넣을 것인가

   1. ChatGPT에 기본적으로 들어갈 네이티브 기능과, 일방·타사 플러그인 또는 추가 인터페이스로 확장할 기능을 구분해야 한다.
   2. 구분을 이분법으로 고정하기보다, 제3자 회의 앱 같은 도구가 ChatGPT·Codex·Computer Use와 효과적으로 연결될 수 있도록 적절한 훅(hook)을 노출해야 한다.

2. 계층(layer)으로 된 능력

   1. 회의 앱 플러그인이 회의 데이터를 읽고 다음 행동을 파악하게 하는 경로를 제공할 수 있다.
   2. 사전 구축 도구나 생태계 도구가 연결되지 않으면 Computer Use가 다음 계층 또는 대체 경로가 된다.
   3. 첫 번째 경로가 실패해도 사용자가 원하는 일을 끝낼 수 있도록 기능을 겹겹이 배치한다.

3. 조합 가능한 생태계

   1. 일·타사 개발자가 연결할 수 있는 훅과, 여러 경험을 함께 조합할 수 있는 시스템이 필요하다.
   2. 플랫폼의 모든 기능은 개별 도구의 존재 자체가 아니라 사용자가 목표를 달성하는 데 봉사해야 한다.

5.2. MCP보다 Computer Use를 선호하는 이유

1. 기존 도구와 새 도구의 교차점

   1. Claire는 무대 뒤에서 Computer Use를 좋아하며 “MCP를 주지 말고 UI를 Computer Use로 가리키게 해 달라”고 말한다.
   2. 토큰 비용은 괜찮다며 “토큰을 팔아 나를 설득한 것을 축하한다”고 농담할 만큼, 비용보다 실제 완료 여부를 중요하게 본다.

2. 99% 완료보다 100% 완료

   1. Nan은 일을 전부 끝내는 것과 마지막 한 단계만 남기는 것은 큰 차이라고 말한다.
   2. 아예 시작하지 못하면 사용자가 직접 하거나 다른 경로를 찾을 수 있지만, 99%까지 진행한 뒤 마지막에 실패하면 이루어지지 않은 약속이 되어 오히려 더 나쁘다.
   3. Computer Use는 조금 느리거나 토큰을 많이 쓸 수 있어도 작업을 끝까지 수행하는 경우가 많다. 생태계가 올바른 훅과 MCP를 제공할 때까지 기다리는 동안에도 사용자의 일을 100% 완료하는 fallback이 된다.

3. Charles Eames의 ‘집에 온 손님’ 원칙

   1. 모델·도구·인터페이스·서드파티 생태계가 모두 바뀌고 예측 불가능하더라도 사용자는 그 복잡성을 떠안아서는 안 된다.
   2. 사용자는 필요한 일을 미리 예상하고 준비해 둔 집에 온 손님처럼 느껴야 한다는 Charles Eames의 인용이 이상적인 제품 경험의 기준이 된다.
   3. 모델이 사용자의 필요를 점점 더 미리 예측하고 준비하는 방향으로 발전할수록, 복잡한 내부 구조가 부드러운 경험으로 변환된다.

4. 업데이트 농담이 드러낸 현실

   1. Claire는 실제로 상대의 집에 갈 때마다 업데이트하라는 안내를 받는다고 말한다.
   2. 상대는 “최신 빌드를 받아라”가 환영 인사인 것처럼 말하며, 손님에게도 계속 업데이트를 요구하는 현실을 웃음으로 꼬집는다.

6. 연구 조직과 함께 만드는 제품

제품 관리자는 연구팀에 막연한 제품 아이디어를 넘기는 사람이 아니라, 구체적인 사용 사례·세션·평가를 제공해 모델 능력의 개선 루프를 만드는 사람이 되어야 한다.

6.1. 연구팀과 엔지니어링팀은 다르게 협업해야 한다

1. OpenAI에서 처음 마주한 협업 방식

   1. Tara에게 연구팀과 일하는 것은 OpenAI에 오기 전까지 전혀 익숙하지 않았고, 연구와 엔지니어링이 다르다는 사실부터 새롭게 배워야 했다.
   2. 연구팀과 협업하려면 “사용자가 무엇을 하려는가”를 구체적으로 제시해야 하며, 추상적인 요구나 막연한 “더 똑똑하게 해 달라”는 요청으로는 충분하지 않다.

2. 구체적인 사용자 증거를 가져오기

   1. 명확한 사용자 목표와 실제 사용 사례를 제시해야 한다.
   2. 한 세션에서 사용자가 무엇을 했고, 모델이 어떤 응답을 했으며, 왜 필요한 결과를 내지 못했는지 샘플을 읽고 분석해야 한다.
   3. 실패의 맥락이 구체적일수록 연구팀이 문제를 모델 능력의 문제로 재현하고 개선할 수 있다.

6.2. 평가(evals)가 제품 리더의 핵심 도구가 되다

1. 좋은 eval 작성

   1. Tara는 가능하다면 직접 좋은 평가(evaluation)를 작성하는 일이 가장 중요하다고 말한다.
   2. 어떤 프롬프트와 어떤 스킬 조합으로 원하는 결과를 얻었는지 기록하면, 무엇이 성공을 만드는지 비교할 수 있다.

2. 포스트 트레이닝으로 연결하기

   1. 특정 프롬프트와 스킬로 가능해진 결과를 연구팀에 가져가면, 그 능력을 모델이 처음부터 수행하도록 포스트 트레이닝(post-training)할 수 있는지 검토할 수 있다.
   2. 사용자 데이터 → 재현 가능한 eval → 모델 개선이라는 루프가 제품 개발과 연구 개발을 연결한다.

7. 90일 앞을 보는 제품 리더십

AI 제품 리더는 현재만 보아서도 안 되고 수년 뒤를 상상해서도 안 된다. 예측이 비교적 가능한 가까운 미래와 시장의 변화 속도를 기준으로 계획 주기를 정해야 한다.

7.1. 2~3개월이라는 실용적 시간 지평

1. 현재에만 머물면 뒤처진다

   1. 눈앞의 버그와 문제를 고치는 일은 필요하지만, 오늘의 모델 능력만 전제로 제품을 만들면 곧바로 뒤처진다.
   2. 모델이 다음 해에 무엇을 할지 너무 먼 미래를 상정해 설계하면 잘못된 전제 위에 제품을 쌓게 된다.

2. 수년 뒤의 예측을 경계하기

   1. Tara는 몇 년 뒤를 잘못 예측했던 기록을 모아 둔 개인 문서를 갖고 있다. 그 문서는 자신이 미래를 예측하는 데 얼마나 자주 실패하는지 잊지 않게 해 준다.
   2. ‘미래에 무엇이 될 것인가’를 장담하는 대신, 지금부터 2~3개월 안에 모델이 도달할 가능성이 높은 능력을 기준으로 제품을 세운다.
   3. 이 원칙이 제목의 “2027년을 계획하지 말라”는 메시지와 연결된다. 연간 계획보다 90일 단위의 관찰·출시·학습·재계획이 적합하다.

7.2. 사업의 변화 속도에 따라 계획 주기를 바꾸기

1. Stripe와 OpenAI의 차이

   1. Stripe의 결제 시장은 상당히 가속되더라도 시장을 움직이는 힘이 이전과 크게 다르지 않다.
   2. 따라서 강세·약세·기준 시나리오를 세우고 여러 달 앞의 레버와 결과를 모델링하기가 상대적으로 쉽다.
   3. 반면 OpenAI의 사업은 시장의 핵심 역학과 모델 능력이 동시에 빠르게 변해 같은 방식으로 예측하기 어렵다.

2. 연간 계획이 틀렸다는 뜻은 아니다

   1. 모든 사업이 90일 계획만 세워야 하는 것은 아니다. 시장의 속도와 역학을 이해한 뒤, 그에 맞는 미래 계획 주기를 정해야 한다.
   2. Stripe의 PM은 연간 계획을 계속해야 하며, Claire는 연간 계획을 해야 하는 사람들에게 “행운을 빈다”고 웃으며 말한다.
   3. 핵심은 연간 계획 자체를 금지하는 것이 아니라, 시장 변동성이 큰 AI 제품에 오래된 계획 주기를 기계적으로 적용하지 않는 것이다.

8. 고전적인 PM 역량과 새롭게 필수가 된 역량

기존 제품 관리의 기본기는 그대로지만, 온보딩·프라이버시·예측 가능성·직접적인 사용자 관계의 중요도가 크게 높아졌다.

8.1. 온보딩이 가장 중요한 첫 경험이 되다

1. 능력 과잉과 초기 경험의 간극

   1. 모델이 할 수 있는 일은 매우 많지만 사용자가 그 능력을 활용하지 못하는 능력 과잉이 존재한다.
   2. 초기 사용자가 제품의 제공 가치를 이해하지 못하면 강력한 모델도 빈 기능처럼 느껴진다.

2. 새로운 온보딩의 역할

   1. 온보딩(onboarding)은 예전에도 중요했지만 엔지니어가 선호하지 않는 작업으로 취급되는 경우가 있었다.
   2. 이제는 첫 경험에서 무엇을 제공하는지 지속적으로 이해시키고, 사용자가 곧바로 유용한 행동을 하도록 만드는 일이 성공의 전제다.

8.2. 프라이버시와 에이전트 행동의 예측 가능성

1. 사용자가 데이터의 규칙을 알아야 한다

   1. 사용자가 자신의 프라이버시와 데이터가 어떻게 사용되는지 이해하는 일은 과거보다 훨씬 중요해졌다.
   2. 제품이 어떤 규범과 권한 모델을 갖는지 사용자가 이해하지 못하면 에이전트의 자율성이 불안으로 바뀐다.

2. 반자율적 행동의 예측 가능성

   1. 예전에는 예측 불가능한 동작이 나와도 설정 메뉴나 팝업으로 보완할 수 있었다.
   2. 에이전트가 반자율적으로 일을 수행하는 지금은, 사용자가 언제든 기능이나 기본 단위(primitives)가 다음에 무엇을 할지 예상할 수 있어야 한다.
   3. 자율성이 높아질수록 제품은 ‘무엇이 가능한가’뿐 아니라 ‘다음에 무엇이 일어날 것인가’를 설명해야 한다.

8.3. 기본기는 그대로, 실행 속도는 더 빨라져야 한다

1. 높은 수준과 낮은 수준을 동시에 보기

   1. 제품의 큰 방향을 이해하면서도 디자인과 세부 동작까지 직접 파고드는 고전적인 PM 작업은 여전히 유효하다.
   2. 다만 같은 작업을 더 빠르게 수행하고, 실제 사용자에게 더 자주 테스트해야 한다.

2. 경험적 테스트의 우선순위 상승

   1. 사용자 테스트와 실증적 검증은 예전보다 훨씬 중요해졌다.
   2. AI 제품의 동작이 빠르게 바뀌므로, 가설을 오래 보존하기보다 실제 사용에서 배우고 다음 반복에 반영해야 한다.

8.4. DM 가능한 제품 리더와 깊은 사용자 관계

1. 직접 연락 가능한 PM의 의미

   1. Tara는 개발자·엔터프라이즈 배경이라 고객이 기능을 요청할 수 있도록 늘 DM 가능한 PM이었다.
   2. 새롭게 느껴지는 점은 대규모 소비자 제품에서도 같은 수준의 접근성을 기대하게 됐다는 것이다.
   3. 사용자가 원하는 것과 사용 사례를 연구팀에 전달하는 것이 PM의 가치라면, 사용자와 직접 연결될수록 그 가치가 커진다.

2. 피드백의 두 번째·세 번째 질문

   1. 개발자는 매우 까다롭고 세부 사항에 민감해 처음부터 좋은 피드백을 주지 않을 수 있다.
   2. 두 번째나 세 번째 후속 질문을 해야 실제 문제가 드러나는 경우가 많다.
   3. 자연어 인터페이스의 에이전트 경험에서는 문제가 더 미묘하다. Astra가 ‘태도가 나빴다’고 느껴졌다면, 정확히 어떤 말을 어떤 맥락에서 했는지, 사용자가 모델을 화나게 했는지까지 물어야 한다.

3. 실제 사용자 관계가 연구 자산이 되다

   1. Claire가 Astra의 응답이 마음에 들지 않았다고 말하자 Tara는 그 출력물을 보내 달라고 한다. 그런 사례가 실제로 모델을 개선하는 중요한 재료이기 때문이다.
   2. Claire는 아직 두 사람의 DM에 답을 받지 못했다며 90일 동안 그룹 채팅을 만들겠다고 농담한다. 직접적인 접근성은 친근한 문화이면서 동시에 강한 피드백 책임을 뜻한다.

9. 2027년의 제품 표면에 나타날 가능성이 높은 것

새로운 폼팩터가 매주 등장하는 상황에서 확실한 장기 예측은 어렵지만, 인간의 자연스러운 상호작용과 빈 입력창의 문제를 해결하는 방향은 비교적 선명하다.

9.1. Tara의 예측: 음성(voice)

1. 말하기가 가장 자연스러운 인터페이스다

   1. Tara는 2027년에 큰 변화가 될 것으로 음성을 꼽고, GPT Live를 사용해 보라고 권한다.
   2. 스스로를 ‘말이 많은 사람들(yappers)’이라고 부르는 농담과 API 천재에 대한 언급이 이어지지만, 핵심은 말하기가 타이핑보다 자연스럽다는 경험이다.

2. 가족의 기술 지원을 줄이는 음성

   1. 많은 사람이 부모의 기술 지원 역할을 해 왔지만, 음성이 등장하면서 Tara가 가족에게 해 줘야 할 기술 지원이 놀라울 정도로 줄었다.
   2. OpenAI의 People 팀이 새 제품을 익히는 과정에서도 음성이 게임을 바꿨다. 음성은 많은 사람에게 직관적인 인터페이스가 된다.

3. 모델이 자연스러운 상호작용을 따라잡고 있다

   1. 인간은 수천 년 동안 다른 사람과 말로 상호작용해 왔기 때문에, 음성은 인간 본성에 맞는 진입점이다.
   2. 모델의 음성 이해와 생성 품질이 좋아지고 속도가 빨라지면서, Tara는 음성에 매우 낙관적이다.

9.2. Nan의 예측: 셀프 드라이빙 제품

1. 빈 입력창(empty input box)의 문제

   1. ChatGPT 같은 범용 도구를 쓰든 산업별 특화 도구를 쓰든, 사용자는 “제품은 있는데 이제 무엇을 하지?”라는 빈 입력창 문제에 부딪힌다.
   2. 제품을 갖는 것과 제품을 어떻게 사용해야 하는지 아는 것은 서로 다른 문제다.

2. 제품이 스스로 사용법을 안내하는 온램프

   1. 제품이 이미 지능적이라면 사용자가 모든 사용법을 먼저 배워야 하는 대신, 제품이 스스로 작동하며 사용자를 도와야 한다.
   2. 사용자를 아주 부드럽게 온보딩하는 셀프 드라이빙(self-driving) 경험이 다음 해에 훨씬 중요해질 가능성이 있다.
   3. 이런 경험이 보편화되면 사람들은 “왜 처음부터 항상 이렇게 작동하지 않았을까?”라고 생각하게 될 것이다.

9.3. Claire의 예측: 노트북을 열어 두지 않는 하드웨어

1. 세 가지 2027 후보

   1. Claire는 음성, 셀프 드라이빙, 그리고 노트북을 계속 열어 들고 다니지 않아도 되는 하드웨어를 차례로 정리한다.
   2. 작은 ‘베이비 봇’ 또는 상자 속 Codex처럼, 화면 앞에서 직접 조작하지 않아도 일을 처리하는 기기를 원한다고 말한다.

2. 예측을 검증할 책임

   1. Claire는 현장의 노트테이커들에게 세 사람의 예측을 기록해 달라고 요청한다.
   2. 2027년의 ‘올해의 핫 제품’이 음성인지, 셀프 드라이빙인지, 하드웨어인지 나중에 확인하자는 말로 대화를 마무리한다.

주요 발언 모음

“How do you get it perfect a priori versus how do you ship something and iterate on it as quickly and effectively as possible?”

“Nothing compares to the actual empirical evidence of seeing users try it, use it, and then iterating from there.”

“The ideal is two to three months.”

“Forty agents is quite a lot.”

“If it gets 99% there and then it just barfs, then this is actually a worse sort of unfulfilled promise.”

“Your user should almost feel like a guest in your home.”

“I live in the now.”

“Why didn't it always work that way?”

핵심 데이터 & 수치

• 10억 명 이상: ChatGPT 사용자 규모를 고려하면, 에이전트 하네스를 실제 사용자에게 전달하는 일 자체가 거대한 학습 기회가 된다.
• 약 7년: Tara가 Stripe에서 일하며 깊이 다듬어진 제품 개발 문화를 경험한 기간이다.
• 100번: Stripe에서 enum 이름 하나까지 정확한지 반복 검토하는 완벽주의를 강조하기 위해 언급된 횟수다.
• 2~3개월: 모델이 도달할 가능성이 높은 가까운 미래를 기준으로 제품을 설계하는 권장 시간 지평이다.
• 40개: Claire가 사업 여러 부분을 지탱하는 Grok 봇의 수로 언급한 규모이며, 인간이 직접 관리하기에는 많은 수다.
• 99%: Computer Use가 아닌 도구가 마지막 단계에서 실패할 때 발생하는 ‘거의 다 됐지만 완료되지 않은’ 경험을 상징한다.
• 90일: 빠른 출시·사용자 피드백·평가·재계획을 반복하는 실질적인 제품 개발 주기다.
• 2027년: 음성, 셀프 드라이빙, 전용 AI 하드웨어가 제품의 주요 표면이 될지 검증할 시점이다.

결론 및 시사점

1. 불완전함을 출시 허가증으로 오해하지 말아야 한다: 토글 같은 임시 표면도 사용자 가치, 내부 사용성, 모델 능력과의 정합성, 개발자 워크플로 보호라는 품질 기준을 통과해야 한다.
2. 제품 변화에는 서사가 필요하다: 폐기와 교체를 숨기기보다 단계 A에서 B로 가는 이유와 사용자가 얻는 가치를 보여 주면 제품 진화가 신뢰를 유지한다.
3. 90일 계획은 예측 포기가 아니다: 가까운 모델 능력을 구체적인 사용자 데이터와 eval로 검증하고, 다음 주기를 다시 설계하는 방식이다.
4. 에이전트의 UX는 권한·메모리·자격 증명에서 결정된다: 단일 에이전트냐 다중 에이전트냐의 철학적 선택보다 누가 무엇을 보고 기억하고 실행하는지가 중요하다.
5. 플랫폼은 계층형 실패 복구를 제공해야 한다: 네이티브 기능, 플러그인·MCP, Computer Use를 연결해 사전 통합이 없는 도구도 마지막까지 완료하게 해야 한다.
6. 에이전트 제품의 핵심 역량은 공감·시스템·끈기다: 사용자의 정신 모델을 이해하고, 이를 실현할 구조를 만들고, 반복의 고통을 견디며 빠른 피드백 루프를 돌려야 한다.
7. 연구 협업은 구체성에서 시작된다: 세션 기록, 실패 맥락, 프롬프트·스킬 조합, 재현 가능한 eval이 모델 개선으로 이어진다.
8. AI 제품의 새 필수 역량은 온보딩과 예측 가능성이다: 자율성이 높아질수록 데이터 사용, 프라이버시, 다음 행동을 사용자가 이해할 수 있어야 한다.
9. 직접적인 사용자 관계가 품질 도구가 된다: DM과 후속 질문으로만 드러나는 미묘한 실패를 제품·연구팀의 개선 자료로 전환해야 한다.
10. 2027년의 승자는 인간의 입력 부담을 줄이는 제품일 가능성이 크다: 음성은 자연스러운 진입점을, 셀프 드라이빙은 빈 입력창의 해결책을, 전용 하드웨어는 화면 조작 없는 실행을 제공한다.

핵심 요약 (20줄)

OpenAI의 제품 개발은 수년 뒤를 정밀하게 예측하기보다 다음 90일의 모델 능력과 사용자 문제에 맞춘다. 완벽한 사전 설계보다 실제 사용자의 행동에서 얻는 경험적 증거가 더 강한 제품 판단 근거가 된다. Tara Sesha는 아시아계 가정과 Stripe의 문화에서 익힌 완벽주의를 AI 시대의 긴급성에 맞게 바꾸고 있다. 토글은 이상적인 표면이 아니어도 10억 명이 넘는 ChatGPT 사용자에게 에이전트 하네스를 전달하는 임시 경로가 됐다. 제품을 폐기할 때는 단계 A에서 단계 B로 이어지는 일관된 이야기와 변화의 투명성을 사용자에게 제공해야 한다. 빠른 출시도 사용자 가치, 내부 채택, 새로운 모델 사용 사례, 가까운 미래의 능력이라는 품질 기준을 통과해야 한다. 모델이 할 수 있는 일과 사용자가 실제로 흡수하는 일 사이의 능력 과잉이 AI 제품의 큰 제약이다. 기업은 변화를 어려워하지만 최전선의 에이전트 기능을 늦게 받으면 경쟁 제품에 추월당할 수 있다. 에이전트 40개를 직접 관리하기 어렵기 때문에 활동을 묶거나 Chief of Staff 에이전트로 조율하는 방식이 필요하다. 단일 에이전트와 다중 에이전트의 선택은 메모리, 데이터 권한, 자격 증명, 구체적인 사용 사례에 달려 있다. 에이전트 제품에는 사용자 공감과 시스템 사고라는 고전적 PM 역량에 끈질긴 반복 능력이 더해져야 한다. AI 제품의 피드백 루프는 훨씬 빨라졌고, 많은 가설을 실제 사용자에게 던져 보며 학습해야 한다. 플랫폼은 네이티브 기능, 플러그인과 MCP, Computer Use를 연결하는 계층형 도구 구조를 가져야 한다. 99%까지 진행한 뒤 마지막 단계에서 실패하는 경험은 처음부터 시작하지 못하는 것보다 더 큰 불신을 만든다. Computer Use는 느리고 토큰을 많이 사용해도 사용자의 일을 끝까지 완료하는 강력한 fallback이 된다. 제품은 사용자가 복잡한 내부 구조를 몰라도 필요한 것을 미리 준비한 집의 손님처럼 느끼게 해야 한다. 연구팀과의 협업은 구체적인 세션 사례와 재현 가능한 eval을 통해 모델의 포스트 트레이닝으로 연결된다. 대규모 AI 제품의 리더는 온보딩, 데이터 사용, 프라이버시, 에이전트 행동의 예측 가능성을 특히 강화해야 한다. DM 가능한 PM과 엔지니어는 후속 질문으로만 드러나는 자연어 에이전트의 미묘한 실패를 발견할 수 있다. 2027년에는 자연스러운 음성, 빈 입력창을 없애는 셀프 드라이빙, 화면을 대체하는 AI 하드웨어가 유력한 제품 방향이다.