Shipping Products When You Don't Know What they Can Do - Ben Stein, Teammates

영상 링크: Shipping Products When You Don’t Know What they Can Do — Ben Stein, Teammates
채널명: AI Engineer

무엇을 할 수 있는지 모르는 제품을 출시하는 방법 — Ben Stein, Teammates 핵심 요약

• 해당 영상은 AI 기반 에이전트 플랫폼인 ‘Teammates’의 공동 창업자 Ben Stein이, LLM 기반 제품 개발에서 “우리조차 제품이 정확히 무엇을 할 수 있는지 알 수 없는” 현상에 대해 논하는 발표임
• Ben은 자신들의 AI 에이전트 ‘Stacy’ 사례를 소개하며, 실제 사용자가 생소한 질문(예: 구글 문서 댓글에서 @태그)이 들어올 때 제품의 실제 동작을 예상조차 하기 어려웠던 경험을 공유
• LLM 기반 제품에서는 모델의 작동 원리와 범위를 완전히 이해할 수 없고, 사용자 요구는 ‘무한한 표면적’을 지님
• 기존 PM(제품 관리) 방식의 ‘기능 명세서’ 작성에서 벗어나, 에이전트가 수행할 수 있는 ‘행위의 잠재적 가능성(affordance)’에 초점을 맞추는 패러다임 전환이 요구됨
• 제품의 행동이 우발적(emergent)으로 나타나기 때문에, 실제 기능 및 예측 불가능한 사례를 ‘탐구(discovery)’하는 것이 PM의 새로운 역할이 됨
• LLM/AI 제품의 특성상 deterministic(결정론) 테스트 대신 ‘eval(모델 평가)’ 프레임워크가 기능 명세/품질 기준의 새로운 표준이 됨
• 프로토타이핑과 ‘vibe coding(느낌 맞추기 코딩)’을 반복하며 제품의 실제 감각·경험을 검증하고, 기대와 실제의 차이를 지속적으로 실험해야 함
• 사용자 질문이나 피드백, 오류 기준 등도 모호해지기에, 문제/결함의 정의, 버그 트래킹 방식이 근본적으로 변화함
• 세일즈나 고객 미팅에서 ‘비전 제시자’나 ‘솔직한 중개자’ 역할이 한계에 부딪히며, 현실적으로는 고객과 함께 미래를 탐구하고 만들어가는 ‘공동 창조자’ 모드로 접근해야 함
• 제품·PM·엔지니어링, 고객협업 등 각 측면에서 기존 개발의 상식·관행을 되짚고 본질적으로 새롭게 접근할 것을 강조하며 마무리

세부 요약 - 주제별 정리

Ben Stein은 자신의 제품인 Teammates의 내부 에이전트 ‘Stacy’ 사례로 논의를 시작함

• Ben Stein은 ‘Teammates’의 공동 창업자이자 오늘은 제품관리자의 관점에서 발표를 시작
• Teammates는 “디지털 워크포스 관리”를 위한 플랫폼으로, AI 에이전트 시스템을 만든다고 설명
• 모든 고객은 자신만의 에이전트를 만들어 개별 아바타, 성격, 이름까지 지정함
• 대표적 에이전트인 ‘Stacy’를 소개: 구글 워크스페이스와 슬랙 등 협업 툴 계정을 갖춘, 팀의 인상적인 L3 엔지니어
• 실제로 Stacy는 이메일 송수신, 슬랙 채널 활동, 구글 문서·시트 공유 등 다양한 협업을 수행함
• 사용자는 이 에이전트에게 구글 문서 댓글에서 ‘@태그’할 수 있냐고 질문했고, 이는 Ben이 예측하지 못한 질문이었음
• 질문이 나왔을 때 다양한 논리적 케이스를 머릿속에서 고려했으나, 실제로 무슨 일이 일어날지 전혀 확신할 수 없었음

LLM 기반 제품에서 ‘제품이 무엇을 할 수 있는지’ PM조차 알 수 없게 되는 현상이 발생함

• 예기치 못한 고객 질문이 “제품이 실제로 어떤 기능을 제공하는가?”라는 가장 근본적인 고민을 촉진
• 기존 PM 역량 부족이나 제품이 너무 선진적이어서 생기는 문제가 아님을 강조
• 문제의 근본 원인은 2가지로 제시
  • 1. LLM 위에 제품이 구축되어 있어, LLM(대형 언어 모델) 내부 동작 방식을 근본적으로 완전히 이해하거나 예측할 수 없음
  • 2. 사용자의 입력/행동 면적이 사실상 ‘무한’: 텍스트박스에서 무엇이든 입력할 수 있기 때문에, 전통적인 명확한 범위 정의 불가
• 따라서 ‘정해진 인터페이스+명확한 기능 사양’이라는 과거의 소프트웨어 마인드는 더이상 통하지 않음

기존 제품관리 방식에서는 대응할 수 없는 무한대의 케이스와 표면적이 문제임

• 구글 문서 댓글 예시에서, PM 입장에서는 “댓글 읽고 응답” 기능의 경우
  • 에이전트의 권한/접근성, 누가 누구에게 댓글을 남겼는지, 어떤 경우에 응답해야 하는지 등 수많은 경우의 수가 존재
  • 실제 핵심 기능이 이것이 아님에도, 각 케이스를 모두 명세화하는 것은 비효율적이고 비현실적
• ‘만약 마우스에게 쿠키를 준다면(If You Give a Mouse a Cookie)’ 비유처럼, 댓글 태깅이 가능하면 ‘Linear’, ‘Figma’, ‘LinkedIn’ 등 어디에서든 태깅/댓글 요구가 이어질 수 있음
• Teammates는 범용 댓글·커뮤니케이션 에이전트가 아니기 때문에, 더더욱 이런 요구의 무한 확장을 다룰 수 없음
• 오늘날 PM은 ‘기능’ 스펙을 정의하는 것이 아니라, 무엇을 할 수 있게 허락(affordance)할지 설계해야 한다고 강조

‘Affordance(가능적 행위)’ 중심 및 우발적(Emergent) 행동 발견이 새로운 제품관리의 초점임

• 전통적인 PM은 ‘요구 사항’과 ‘기능 명세’를 세밀하게 정의하였으나, 새로운 LLM 기반 환경에서는 ‘affordance(사용자·에이전트가 할 수 있도록 허락하는 능력)’로 마인드셋을 전환해야 함
• 각 에이전트가 어떤 행동을 할 수 있도록 할 것인지 (댓글 작성/답변, 협업, 이메일 등) 중심으로 사고
• LLM을 신뢰하며 에이전트 워크플로우, 작업 실행계획 등은 시스템과 모델 특성에 위임
• 행동(Behavior)은 명시적 프로그램 규칙이 아닌, 시스템/모델이 조합하며 스스로 ‘우발적(emergent)’으로 나타남
• 따라서 PM의 역할은 스펙대로 만드는 것이 아니라, ‘어떤 블록(레고 조각)’을 제공할지, 그리고 실제로 우리 제품이 무엇을 할 수 있는지 발견하는 ‘탐구(discovery)’가 됨

LLM/에이전트의 기능을 정의하는 수단으로 ‘eval(모델 평가)’이 명세서 역할로 부상함

• Eval(이벨; 평가)는 기존 테스팅과 달리, 확률론적·비결정론적 AI 시스템의 ‘테스트 프레임워크’
  • 예: “ATM에서 $100 출금 시 계좌 잔고가 반드시 $100 줄어야 한다“는 식의 결정론적 로직이 아님
  • “슬랙에서 적당히 익살스럽고 재치있으면서 불쾌하지 않아야 한다”와 같은 조건 등
• 실제 평가에서는 또 다른 LLM이 결과(예: 에이전트의 답변)가 우리가 원한 속성을 얼마나 충족했는지 채점
• 통상 ‘80%, 90% 만족’이 기준이 되고, 완벽(100%)할 필요는 없음
• Eval이 곧 “이 제품이 무엇을 할 수 있느냐”를 명세로 보여주기 때문에, PM은 엔지니어들처럼 eval을 직접 들여다보고 관리하는 것이 중요해짐
• 행위 주도 개발(BDD; Behavior-Driven Development)으로의 비유도 등장하나, 과거와 다르게 이번에는 실제로 ‘평가 기준 = 명세서’로 작동할 수 있음

‘Vibe coding(바이브 코딩, 느낌 맞추기 코딩)’과 빠른 프로토타이핑이 실제 제품 경험에 결정적 역할을 함

• 전통적 PRD, Figma 프로토타입 방식으론 LLM/에이전트 경험의 ‘실제 느낌’을 정의할 수 없음을 강조
• 실제 사용자 인터랙션, 에이전트의 대화의 ‘감각/느낌(feel)’을 직접 경험하기 전까지는 예측이나 명세가 어렵고, 사용성 문제도 발견 불가
  • 예: 처음에는 명확한 답변을 위해 에이전트가 질문을 많이 하는 스펙을 넣었으나, 실제 사용자는 “질문이 너무 많아 성가시다”는 피드백이 나옴
• 이런 점에서 바이브 코딩(prototype을 바로 만들어 느낌을 테스트) 및 빠른 반복적 검증이 신규 PM 도구로 자리매김함
• 단, 이를 핑계로 “회의 중에 잠깐 만져봤더니 2주 작업을 끝냈다”류의 무책임한 접근은 경계 필요
• 실제 기능 출시는 신중해야 하나, 바이브 코딩은 감각적 경험·초기 피드백 수집의 훌륭한 수단임
• “클로드(Claude) LLM의 ‘certainly’ 반복 답변”과 같이, 반복 실사용에서만 드러나는 불편함(버그)이 많음

출시 이후에도 ‘이게 정말 동작하는가?’라는 근본적 테스트 및 디스커버리(탐구)가 필요함

• 출시 후, 모델이 제대로 동작하는지, 예상하지 못한 문제가 있는지 실험적 접근이 계속 요구됨
• “QA 엔지니어 농담(바에 들어가 여러 번 주문해도 문제 없다가, 첫 손님이 화장실 물으면 폭발)”처럼, 엉뚱한 입력/행동 조합에서 예기치 못한 현상이 나타남
• LLM/AI 제품에선 실제 사용자 시나리오, 다양한 조합을 실험하며 ‘emergent’ 행동/버그/새로운 기능이 생성됨
• 요구사항을 미리 100% 정리하는 것이 불가능하며, 빠른 실험과 사용자 피드백, 기능 탐구 중심의 개발 문화 필요

버그 정의와 –에러 처리 기준이 근본적으로 모호해지고, 버그 관리 프랙티스도 바뀜

• LLM의 ‘확률적’ 결과 특성상, “80%면 OK”, “90% 이하로 떨어지면 NG”와 같이 임계치 기반 크리덴셜 필요
• 예: 에이전트가 이모지를 너무 많이 썼을 때, 기존 PRD/스펙에 없으면 이게 버그인가 아닌가가 불명확함
• 버그 트래킹 툴(예: Linear)에서 ‘Closed/Done’뿐 아니라, “LLM은 근본적으로 예측 불가함(‘closed: LLMs be crazy, yo’)” 등 새로운 상태 필요
• “감각/느낌” 기반 이슈와, 실제 체계적 기능/명세 위반 케이스 분리 필요
• 사용자 요구가 어느 정도까지 ‘제품의 실제 동작’ “버그”로 간주되어야 하는지 경계가 모호해짐

고객 미팅/세일즈에서 제품의 미래와 현재에 대해 명확히 설명할 수 없는 상황이 발생함

• 세일즈 콜에서 PM은 보통 ‘비전 제시자(미래 로드맵 설명)’와 ‘솔직한 중재자(현실적 한계 설명)’ 역할을 맡았음
• 그러나 LLM 제품에선 미래 비전(로드맵)이 ‘마법 혹은 공수표’로 보이고, 현재 상황조차 “실제로 어떻게 동작할지 확신할 수 없다”고밖에 말할 수 없음
• 이러한 한계 때문에, 고객과 함께 미래를 ‘공동 창조(We’re inventing the future together)’하며 상호 실험자로 협력하는 관계로의 전환 필요
• ‘큰 회사와의 대형 딜’이 아니라, AI·에이전트 기반 디지털 트랜스포메이션에 관심 많은 ‘미래 지향 고객’이 지금은 진정한 타겟임

제품, PM, 엔지니어, 고객 모두가 급속하게 변하는 ‘포스트 LLM 시대 제품개발’에 적응해야 함을 강조하며 마무리함

• Ben Stein은 연구자, PM, 엔지니어, 고객 모두가 기존 규범·상식을 되짚어 보고, 도구·테크닉에 변화를 받아들여야 함을 역설
• 특히 PM들은 고객의 요구 경청, 진짜 문제 해결이란 본질은 유지하되, 설계· 개발·배포에 관한 관행은 완전히 새롭게 이해해야 함을 강조
• LLM 모델 업그레이드만으로 에이전트 행동과 제품 가능성이 연쇄적으로 변하는 시대이기 때문에, 이전과 달리 빠른 적응력이 핵심임
• “엔지니어와 제품 담당자, 미래지향적 고객이 모두 함께 배우고 실험하며, 활기찬 AI/에이전트 신세계를 열자”는 메시지로 발표를 마침