OpenAI가 모든 것을 출시했다, 실제로 쓸 만한 것은 무엇인가?

메타데이터

• 원문 제목: High Taste Testers: OpenAI Shipped Everything. What Actually Works?
• 영상 URL: https://www.youtube.com/watch?v=ZOH8Q401vt0
• 날짜: 2026-10-16 (실제 게시일)
• 채널: Latent Space (latentspacepod)
• 저장 날짜: 2026-10-17
• 길이: 75분 21초

📌 핵심 질문 / 실제로 작동하는 AI 제품은 무엇인가

AI 제품의 성패는 신기능을 많이 발표하는 데 있지 않다. 사용자가 믿고 연결할 수 있고, 맥락과 실행 상태를 이어받으며, 유지보수 부담을 늘리지 않고 실제 시간을 돌려주는 개인 비서가 핵심이다. 모델 쪽에서는 판단 전용 모델과 새 프런티어 모델이 비용·속도·신뢰도를 바꾸고 있지만, 불완전한 제품 UX와 실행 위치의 혼란, 권한 문제는 여전히 해결되지 않았다.

• Dev Day의 기능 다수는 숨겨져 있고, Codex·ChatGPT·Dots 사이의 정보 구조와 실행 위치가 혼란스럽다.
• 이메일 연결과 자율 실행은 신뢰가 확보된 최신 모델에서야 현실적인 선택지가 됐지만, 읽기와 쓰기 권한은 구분해야 한다.
• Decision 모델은 기존 분류 작업을 더 빠르고 싸게 만들며, 낮은 지연 시간으로 AI를 UX 곳곳에 심을 수 있게 한다.
• 강력한 코딩 모델은 밤새 작업을 병렬 수행할 수 있지만, 검토·소비할 수 있는 코드보다 더 많이 생성할 위험이 있다.
• 일상 사용자에게 중요한 것은 에이전트라는 이름이 아니라 일정 확인, 예약, 검색 같은 반복 업무를 대신해 주는 결과다.

녹화는 OpenAI Dev Day 직후 진행됐다. 패널은 신제품 공개 자체보다 실제 써 본 모델과 비서 제품의 경험을 비교하고, 음식 코스에 맞춰 개인 비서·코딩 에이전트·모델 선택·안전·하드웨어 이야기를 이어 간다. 오프닝에는 스쿼시 크로켓, 바삭하게 튀긴 치킨, 장터에서 가져온 빵이 나오고, 메인 코스로는 수맥(sumac) 소고기 타다키와 팬에 구운 넙치, 크리미 레몬 리소토가 언급된다. 디저트는 레몬 블루베리 케이크와 다크 초콜릿 크렘 무스다.

1. Dev Day의 제품들: 발표보다 중요한 발견 가능성, 일관성, 실행 위치

새 기능이 있어도 사용자가 발견하지 못하거나 일하는 흐름을 끊으면 실질적인 제품 가치는 낮다.

1.1. 새 기능은 많지만 제품 안에 숨겨져 있다

1. Dots와 공유 작업 공간의 모호한 위치

   1. Dev Day에서 Dots, 6.1 Soul, Ultra Fast, Notion 경쟁 제품에 가까운 협업 기능 등이 공개돼 흥미를 끌었다.
   2. 협업 기능은 Markdown을 쓰고 그림을 그리는 공유 화이트보드처럼 보이지만, 앱 깊숙이 감춰져 있다. Codex 채팅에서 시각화를 요청할 수 있어도 그 기능을 아는 사람이 적은 것과 같은 발견성 문제가 있다.
   3. Dots도 독립 앱으로 나올 것이라는 기대와 달리 기존 앱 안에 들어갔다. 여러 Codex·Astra 작업이 동시에 돌아갈 때 알림을 분리해서 보고 싶다는 요구와 맞지 않는다.
   4. 패널 중 한 명은 별도 앱 대신 별도 기기 형태로 나올 가능성을 추측했지만, 다른 참석자는 연말 공개 예고를 고려하면 AI 업계에서 3~6개월은 이미 긴 시간이라고 반응했다.

2. 제품을 넓히면서 기존 경험을 흐리는 문제

   1. Codex 데스크톱 앱은 처음 출시됐을 때 방향이 선명했지만, Dev Day 업데이트에서 두 번째 사이드바, 과도한 아이콘, 성능 저하, 멈춤 현상 등이 더해졌다는 평가가 나왔다.
   2. 인터넷 연결이 끊기면 입력 칸까지 멈추는 사례가 있어, 보조자를 별도 앱으로 두고 싶다는 요구가 나왔다.
   3. ChatGPT와 Codex를 합친 초기 인터페이스에서는 모델 선택기와 모드 외에 무엇이 바뀌었는지 불분명했고, ChatGPT 모드로 잘못 들어가거나 기존 대화 목록을 찾기 어려웠다.
   4. 개발자용 용어인 fork chat을 비개발자도 이해하도록 바꾸는 과정에서 정작 개발자 사용자가 익숙한 개념을 잃는 사례가 나왔다. 소비자와 기업을 한 제품에 넣으면 서로 다른 요구를 동시에 맞추기 어렵다는 우려도 이어졌다.
   5. Google Maps를 닮은 ChatGPT 지도 기능처럼 실제 기능이 존재해도 여러 메뉴 아래 숨으면 사용자는 없는 기능처럼 여긴다. 패널은 “그동안 계속 있었다고요?”라는 식으로 뒤늦게 발견한 경험을 나눴다.

3. AI로 제품을 빠르게 만들수록 방향과 일관성이 중요하다

   1. 개발자들은 AI가 코드를 쓰는 시대에 Codex 앱의 기능과 UI가 자주 바뀌고, 무엇이 어디에 있는지 모호해지는 현상을 체감한다고 했다.
   2. 복잡한 앱의 큰 구조 변경이 때로는 “AI가 쓴 글처럼” 앞뒤가 잘 맞지 않거나, 제품의 방향이 없는 것처럼 느껴진다는 비판이 나왔다.
   3. Grokbot은 전문적인 개인 비서에, Muse는 일반 소비자에 맞춰 각자 초점을 정한 제품으로 호평받았다. 반면 Codex는 일반 사용자에게 맞추는 과정에서 개발자 제품의 선명함을 잃고, ChatGPT는 복잡해졌다는 진단이다.
   4. 기업용과 소비자용 Dots를 한 발표 안에 함께 넣는 것 역시 두 시장의 제품 요구가 다르다는 문제를 드러낸다.

1.2. 개인 비서와 코딩 에이전트 사이, 같은 도구만으로 충분한가

1. 항상 켜져 있고 먼저 움직이는 보조자는 올바른 방향이다

   1. 에이전트는 개발자가 코드를 작성할 때 쓰는 도구로 인식되지만, 일반 사용자가 원하는 것은 이메일을 훑어 중요한 항목을 골라 주고, 약속과 예약을 처리해 부담을 줄이는 보조자다.
   2. ‘에이전트’는 무섭고 기술적인 말이지만, ‘개인 비서’는 부유한 사람이 일정을 맡기는 역할로 익숙하다. 이름을 보조자로 바꾸자는 주장은 역할의 차이를 분명히 하려는 것이다.
   3. 알림을 먼저 보내고, 필요한 일을 시작하고, 다른 서비스에 메시지를 보내는 지속형 보조자가 맞는 제품 형태라는 데 패널이 동의했다.
   4. 오픈소스 진영은 Hermes나 OpenClaw 같은 도구로 개인화와 지속성을 실험해 왔지만, 실험을 감당하는 사용자와 일반 소비자가 원하는 ‘그냥 작동하는’ 제품은 다르다. 기억 시스템이나 설정을 직접 구성하지 않아도 되는 다듬어진 앱이 필요하다.

2. 개발자 도구를 비서처럼 쓸 수는 있지만 운영 부담이 생긴다

   1. 한 참석자는 Pi에 Gmail, 신용카드, 알림, 크론 작업을 붙여 ChatGPT·Codex 복제판처럼 사용한다. 다른 참석자도 Codex에 개인 스크립트와 Google Drive를 연결해 일상 업무를 처리한다.
   2. Git 저장소의 Markdown 문서·스크립트로 회사 운영을 관리하는 사용자는 Codex에 컴퓨터 사용(computer use)을 시켜 새 Dots를 밤새 설정해 보려 했지만, 기존 Mercury 은행 연동 스크립트나 각종 도구가 그대로 연결되지 않았다.
   3. Mac Mini에서 오픈소스 에이전트를 운영하면 장비가 끊기거나 꺼져 보조자가 오프라인이 될 수 있다. 인프라를 관리하는 일이 하나 더 생기면 비서가 오히려 부담을 늘린다.
   4. “문제 하나를 해결하려고 보조자를 데려왔는데, 이제 문제가 세 개가 됐다”는 말이 나왔다. 원하는 것은 어디서든 일을 맡길 수 있는 간단한 원격 서비스이지, 또 하나의 서버 상자 관리가 아니다.
   5. Codex와 ChatGPT의 통합은 장기적으로 한 하네스(harness)·도구·학습 경로로 수렴시키려는 전략일 수 있지만, 현재 사용자가 느끼는 제품 혼란은 그 미래가 완성되지 않았음을 보여 준다.

3. 클라우드와 로컬 사이의 작업 이어받기는 상태 저장 문제다

   1. 노트북을 닫아도 작업이 계속된다는 약속은 실제 설정이 복잡하거나, 노트북을 닫으면 에이전트가 멈추는 경험 때문에 체감되지 않는다.
   2. Pi Durable은 에이전트의 상태를 메모리에만 두지 않고 외부화해 로컬과 클라우드 사이에서 옮길 수 있게 하는 접근으로 소개됐다.
   3. 기본 아이디어는 이벤트를 append-only 로그 파일에 계속 쓰고, 다른 실행 환경에서 그 로그를 읽어 마지막 상태부터 이어 가는 것이다. Cloud Code와 Codex도 내부적으로 큰 JSONL 기록을 사용한다고 언급된다.
   4. 문제는 OpenAI나 Cloud Code가 그 내부 표현을 안정적인 공개 API로 보장하지 않았다는 점이다. 한 회사는 변경 보장이 없는 API에 의존하지 않으려고 append-only 로그 특성을 가진 자체 코딩 하네스를 만들었다.
   5. 에이전트 실행·기록을 포장하는 추적 표준은 연구와 벤치마크용으로 일부 존재하지만, 제품 간 호환 표준은 아직 정착하지 않았다. 에이전트 기록 표준을 제안하는 움직임도 언급됐으나 주요 모델 제공자가 채택해야 확산될 수 있다.

2. Decision 모델: 분류를 값싸고 빠르게, 제품 경험을 새롭게

판단 전용 모델의 새로움은 분류라는 개념 자체보다 가격과 지연 시간을 낮춰 이전에는 비경제적이던 UX를 만들 수 있다는 데 있다.

2.1. 기술적 신기능보다 비용·속도·확률 신호가 실제 가치다

1. 구조화 출력은 이미 가능했지만 신뢰할 확률값을 얻기 어려웠다

   1. Decision API는 입력을 정해진 구조에 맞춰 분류·판단하게 하는 접근으로 소개된다. 발표 당시 OpenAI의 구현은 기존 모델에 구조화 출력 래퍼를 씌운 초기 형태로 보였고, 멀티모달 기능은 뒤따를 것으로 기대됐다.
   2. 구조화 출력과 파이프라인은 오래전부터 구현할 수 있었지만, 모델에 “0에서 1 사이 점수를 줘”라고 시켜도 실제 확률이 아니라 0·0.5·1 같은 값에 뭉치기 쉽고 보정(calibration)이 부족했다.
   3. 일부 제공자는 토큰별 로그 확률(log probability)을 없앴다. 판단 모델이 결정 단위의 확률 신호를 제공하면 답뿐 아니라 모델의 확신 수준을 활용할 수 있다는 점이 차별점으로 꼽혔다.
   4. 이미 라벨이 많은 조직은 기존 라벨을 평가 데이터로 쓰면 새롭고 10배 저렴한 모델로 쉽게 옮길 수 있다. 과거 라벨과 새 모델의 답이 일정 비율 이상 일치하면, 다른 사례만 사람이 검토하면 된다.
   5. 실패 사례를 평가 세트에 넣고 프롬프트를 반복 개선하는 ‘가난한 사람의 GEPA’ 방식도 가능하다. 결정 모델이 새로운 기술적 문제를 처음 가능하게 했다기보다, 충분히 싸고 빨라져 넓은 작업에 적용 가능한 것이 핵심이라는 평가다.

2. 낮은 지연 시간이 새로운 인터페이스를 연다

   1. 웹사이트의 Cmd+K 검색 메뉴는 자주 부정확하거나 불편하다. 사용자가 몇 글자를 입력하면 가능한 페이지 20개 중 의도를 가장 잘 반영하는 목적지를 모델이 순위화하게 할 수 있다.
   2. 기존 방식은 JavaScript에서 목록을 즉시 검색할지, 큰 생성 모델에 물어보고 토큰을 기다릴지 선택해야 했다. 빠른 Decision 모델은 후보 순위를 거의 즉시 계산해 양쪽의 장점을 취하게 한다.
   3. 승인(approve) 같은 버튼이나 상황에 따라 변하는 UI도 판단 결과에 맞춰 만들 수 있다. 단순 텍스트 응답만 내놓는 Dots를 보며, 에이전트가 제품 인터페이스의 형태 자체를 바꿀 여지가 더 크다는 아쉬움이 나왔다.
   4. 온디바이스 실행도 전망으로 언급됐다. WebGPU에서 유사한 판단 모델을 실행할 수 있고, 전용 API 키 없이 기존 모델 게이트웨이를 통해 서비스에 접근할 수도 있다.

3. ‘분류는 쉽다’는 착각을 경계해야 한다

   1. 이진 분류는 출력이 0 또는 1 하나뿐이라 단순해 보이지만, 참·거짓을 정확히 가르는 일은 매우 어렵다. 환각(hallucination)을 이진 분류로 해결할 수 있다는 과거 주장이 거론됐지만, 이진 문제라는 사실이 난도를 낮추지는 않는다.
   2. 범용성이 강점인 판단 모델과, 특정 업무 데이터에 과적합한 분류기를 같은 벤치마크로 공정하게 비교하기 어렵다. 반복 가능하고 제약이 큰 업무라면 과적합도 실용적으로 괜찮을 수 있다.
   3. Cloudflare가 더 작은 분류 모델로 비슷한 성능과 더 높은 속도를 보였다는 비교 사례가 나오지만, 깨끗한 자체 데이터로 2년간 학습한 모델과 폭넓은 업무에 쓰이는 범용 모델의 우열을 단일 점수로 판단하기는 어렵다.
   4. TypeSafe가 100억 달러 규모 투자 라운드를 마쳤다는 소문도 언급되지만, 대화의 질문은 OpenAI·Anthropic 등이 같은 기능을 내놓을 때 별도 전문 API를 계속 구매할 가치가 있느냐는 것이다. 참석자는 Vercel AI Gateway로 이미 사용하므로 전용 키를 따로 만들 필요를 크게 느끼지 않는다고 답한다.
   5. 전문 기업의 장점은 모델뿐 아니라 올바른 사용법과 하네스에 대한 지식이다. 모델 창업자가 판단 모델을 잘못 쓰는 방식을 공개적으로 지적하고, 하네스 적용법을 오픈소스로 제공하는 태도도 높게 평가된다.

3. 모델 선택과 코딩 에이전트 운영: 신뢰가 용량을 키운다

새 프런티어 모델은 단순히 더 많은 코드를 쓰는 수준을 넘어, 작업을 나누고 오래 실행해도 결과를 맡길 만하다는 신뢰를 높인다. 그만큼 검토 체계가 뒤따라야 한다.

3.1. 무엇을 쓰는가: 작가성, 속도, 비용, 제품 맥락

1. 모델마다 잘하는 일과 ‘영혼’에 대한 체감이 다르다

   1. 코딩에는 Astra Ultra를 가장 빠른 모드로 사용한다는 답이 나온다. 주간 한도 전체를 20분 만에 소진할 정도로 토큰을 빠르게 쓸 수 있지만, 어려운 작업을 끝내는 가치가 있다고 본다.
   2. Opus와 Fable은 문장에 ‘영혼’이 있고 글쓰기나 글쓰기와 가까운 작업에 강하다는 평을 받는다. 반대로 GPT 계열은 뛰어난 엔지니어처럼 느껴지지만 글의 감각은 부족하다는 농담이 나온다.
   3. OpenAI 측도 자사 모델의 글쓰기 약점을 공개적으로 인정하고 개선 중이라고 했다는 이야기가 나온다. Opus 4.8에서 고객이 요약 문장을 읽기 어렵다는 불만을 보낸 뒤 Opus 5.5가 글쓰기와 코드 능력을 회복했다는 사용 경험도 공유된다.
   4. 참가자들은 기본 작업에는 5.5와 6.1 Soul이면 충분할 때가 많고, 대규모 리팩터링이나 어려운 문제를 빠르게 끝내려면 Astra·Fable·Opus 같은 최상위 모델을 찾는다고 했다.
   5. Fireworks의 작은 모델 ‘Sonic’은 Opus의 서브에이전트로 쓰기 좋고 어느 정도 문장 감각도 있지만, 글쓰기 성능은 Opus가 훨씬 낫다는 비교가 나온다.

2. Muse Spark·Gemini·Grok은 작업 맥락으로 평가한다

   1. Muse Spark는 100만 토큰 컨텍스트와 멀티모달 입력이 강점이라 큰 문서 묶음이나 영상에서 특정 발언·박수 같은 소리를 찾는 일에 활용된다. 코딩에는 적합하지 않다는 반응이다.
   2. Gemini도 영상·음성 이해 기능을 제공하지만, 참석자는 Muse Spark가 더 저렴하고 유용하다고 본다. Muse의 개인 비서 기능을 구동하는 모델로도 충분한 성능을 낸다는 평가가 있다.
   3. Grok 4.7은 가격과 토큰 효율 면에서 실망스럽다는 의견이 나왔다. 컨텍스트 20만 토큰을 넘기거나 Fast 모드를 켜면 각각 가격이 두 배가 되고 둘을 함께 쓰면 거의 세 배가 되며, 추론 단계도 지나치게 많다는 설명이다.
   4. Grokbot 제품 안에서는 Grokbot에 맞춰 강화학습(RL)된 모델의 효용이 있고, X의 실시간 데이터 접근 덕분에 Grok은 검색·조사 작업에 강하다는 반론이 있다. X 내부 통합이 사용자 이름을 모르는 버그를 한 달 반가량 겪었지만, Grok.com에서는 정상 동작했다고 한다.
   5. Grok Build CLI를 다른 에이전트의 서브에이전트로 불러 X 게시물을 검색하게 하는 방식도 언급된다. X API 사용료를 아끼는 편리한 경로라는 주장과, 호출 한도가 실제로 무제한인지는 확실하지 않다는 주의가 함께 나왔다.

3. 오픈 모델과 프런티어 모델 사이의 격차가 다시 벌어졌다

   1. 참석자 한 명은 DGX Spark 네 대를 마련하고 GLM 5.3 Flash 및 V4.1 Flash 계열을 실험했다. 검증으로 성능을 확인할 수 있는 언덕 오르기(hill-climbing) 문제에서는 재미있고 유용하지만, 일상 업무에서는 OpenAI·Anthropic 프런티어 모델과 큰 격차가 있다고 평한다.
   2. 오픈 모델이 프런티어 모델을 6개월 정도 뒤쫓던 시기가 있었지만 Opus 5.5와 6.1 출시 이후 격차가 다시 커져, 약 1년 뒤처질 수 있다는 전망이 나온다.
   3. Slop Code Bench의 일부 문제에서 Opus 5.5는 이전 세대 모델이 작성한 약 1만 줄보다 세 배 많은 약 3만 줄을 썼고, 그중 51% 이상이 테스트 코드였다. 이전 모델의 테스트 비중은 약 10~15%였다는 비교다.
   4. 모델 성능은 능력의 천장을 향해 함께 올라가다가, 장기 작업·서브에이전트 조율·판단력을 새로운 단계로 끌어올리는 돌파구가 나온 뒤 다음 고원(plateau)에서 따라잡는 식으로 보인다는 설명이 나온다.
   5. 현재 세대의 특성은 좋은 스워밍(swarming)과 작업 위임, 그리고 ‘맡겨도 된다’는 신뢰다. 이메일 계정 연결이나 개인 일정 관리도 과거 모델에서는 상상하기 어려웠지만, 새 모델에서는 감당 가능한 위험으로 느껴지기 시작했다.

3.2. 밤샘 에이전트, 서브에이전트, 컨텍스트 압축의 실제 운용

1. 밤새 실행은 생산량을 늘리지만 검토 병목을 키운다

   1. 프로덕션 소프트웨어를 만들 때 모델을 밤새 쉬지 않고 돌리면 사람이 안정적으로 읽고 검토할 수 있는 양보다 더 많은 코드를 만들 수 있다는 우려가 제기된다.
   2. Opus 5.5가 좋아진 뒤 한 개발자는 열 개의 프로토타입을 동시에 진행하고, 밤 10시에 작업을 시작해 다음 날 아침 결과를 확인하는 방식으로 바꿨다.
   3. 한 번의 거대한 무제한 루프 대신 5~10개 지시를 순서대로 예약하는 ‘가난한 사람의 Ralph loop’를 쓴다. “이걸 해라, 더 나은 구성을 만들어라, 계획을 읽어라, 계속 개선하라”처럼 다음 단계를 미리 넣고 범위를 제한한다.
   4. 분리(detach) 모드 스킬로 CLI 에이전트를 백그라운드에서 수십 개 실행하고 로그를 감시한 뒤, 멈추거나 방향이 흐트러진 작업을 중단·수정·재실행하는 방식도 공유된다.
   5. Codex의 여러 독립 세션보다 내장 서브에이전트가 캐시 최적화와 모델의 처리 방식 때문에 더 빠르고 효율적일 수 있다는 설명이 나온다. 반면 설정에 서브에이전트 48개를 넣었더니 Astra가 두 시간 만에 사용 한도를 소진해 기본값으로 낮춘 경험도 있다. 15개 정도를 쓰는 사례도 언급된다.

2. 메인 에이전트는 관리자일까, 직접 실행자일까

   1. 한 접근은 메인 스레드가 직접 도구를 쓰지 않고 하위 에이전트만 배정·감독하며, 대화 맥락은 사용자와의 상호작용에 남기는 것이다. 실행 결과는 별도 스레드에서 받고 메인 에이전트가 검토한다.
   2. 반대 접근은 직접 작업을 수행하면서 옆 스레드에서 작업 자체를 논의하는 것이다. 장시간 루프에는 메인 에이전트를 “밀어붙이는 기계”로 두고, 서브에이전트를 멈추지 않게 독려하는 패턴이 효과적이었다.
   3. 코딩을 계속하는 동시에 팀을 관리하게 하는 전통적인 개발자 승진과 반대되는 운영 방식이 화제에 올랐다. Dots가 지향하는 제품 형태도 사용자가 지시하고 다른 에이전트들이 실행하는 개인 비서에 가깝다는 해석이 나온다.
   4. 그러나 에이전트가 언제 어떤 Codex 스레드를 실행하는지 비결정적이고, 로컬·클라우드 중 어디서 일이 일어나는지 불분명하면 신뢰하기 어렵다. 실행 위치의 혼란은 Codex와 Dots가 함께 풀어야 할 문제다.

3. 컨텍스트 압축은 정보를 요약하기 전에 불필요한 부피를 걷어내야 한다

   1. 일부 사용자는 Codex의 자동 압축 한도를 40만 토큰으로 올렸고, 기본값이 약 27만 5천이라는 대화가 나온다. 다른 참석자는 압축을 끌 수 있기를 바란다.
   2. 이미지나 큰 도구 출력이 컨텍스트를 차지했다면 내용을 요약하기보다 오래된 도구 결과나 큰 항목을 제거하는 편이 낫다는 요구가 나왔다. 요약 과정에서 모델이 과거 작업을 잊거나 사용자를 처음 만난 사람처럼 대하는 경험이 반복됐다는 것이다.
   3. OpenAI의 압축은 최근 몇 주 동안 사용해 보니 만족스럽지만 느리며, 동시에 스무 작업을 돌리면 압축 지연이 실제 비용이 된다는 의견도 있다.
   4. 개발자들은 에이전트의 궤적(trajectory)과 사고 흐름을 살펴보다가 작업이 잘못된 방향으로 가는 순간 바로잡는다. 메인 스레드의 추론을 감시하는 별도 스레드를 두거나, 한 프로젝트를 관리하는 책임자 에이전트가 하위 작업을 분배하는 패턴도 쓰인다.

3.3. 안전과 신뢰: 프롬프트 인젝션만으로 설명되지 않는 위험

1. 연결 권한이 커질수록 누가 접근할 수 있는지가 제품 기준이 된다

   1. Dots는 패널 한 명이 개인 이메일을 연결한 첫 보조자였다. 다른 참석자는 Apple, Google, OpenAI 정도만 개인 이메일을 맡길 수 있고, Amazon과 Meta에는 맡기지 않겠다고 했다.
   2. Meta Muse 미리보기에서 이메일 연결을 요청했지만 거부한 사례는 비밀번호를 직접 입력하도록 요구한 탓이었다. OAuth 연동이 없던 시점이라 안전한 권한 위임을 기대하기 어려웠다.
   3. OpenAI가 이미 사용자의 생각과 개인정보를 많이 갖고 있다는 판단, 데이터 보존 설정을 이미 구성했다는 이유로 이메일 연동을 받아들이는 사례가 나왔다. 다만 이를 신뢰의 객관적 증거라기보다 개인의 체감과 위험 선호로 제시한다.
   4. 한 사용자는 이메일 읽기와 쓰기를 다르게 취급한다. 일정과 메일을 읽게 하는 것은 허용할 수 있어도, 메일을 보내려면 실제 초안을 확인한 뒤 명시적으로 승인해야 한다.
   5. 은행·결제 권한에 대해서는 더 조심스럽다. 벤더마다 가상 카드를 만들어 쓰는 방식이 언급됐지만, 에이전트가 발급한 카드의 개별 한도와 만료일이 어떻게 설정되는지 불분명하고, 신용카드 접근 자체를 맡기고 싶지 않다는 반응도 나왔다.

2. 프롬프트 인젝션 방어가 좋아져도 ‘도움이 되려는 실수’가 남는다

   1. 최신 모델은 시스템 지시와 외부 콘텐츠의 우선순위를 구분하고 이메일 같은 입력을 경계하도록 학습돼, 악의적인 프롬프트 인젝션을 막는 벤치마크에서 강해졌다는 주장이 나온다.
   2. 반론은 공격자가 탈옥을 시도하지 않아도 모델이 정상 업무 중 비밀을 잘못 공유할 수 있다는 것이다. 친구의 새 Hermes 에이전트를 다섯 번 공격해 뚫지 못했다는 실험만으로 실생활의 우발적 공개 위험까지 없어진 것은 아니다.
   3. Muse가 Facebook Marketplace에서 물건을 팔려던 사용자의 상대방에게 개인 정보를 알려 줬다는 사례가 소개된다. 상사에게 이직 의사를 알리거나 인터뷰 일정의 민감한 맥락을 잘못 전달하는 것도 가능한 피해다.
   4. Netflix 2단계 인증 코드(2FA)를 이메일에서 찾아 친구에게 건넨 사례도 거론된다. 편리하게 답하려는 모델이 어떤 정보를 어느 사람에게 공개해도 되는지 오분류할 수 있다.
   5. Grokbot은 이메일로 초안을 만들더라도 사용자가 실제 내용을 확인하고 전송 버튼을 누르기 전까지는 보내지 못하게 설정할 수 있다. 다만 전송 전 미리보기를 보여 주는 UI가 화면 오른쪽에 숨어 있어 검토 자체가 불편할 수 있다는 지적이 나왔다.

4. 개인 비서의 현재: 도구 통합, 사용 사례, 하드웨어

일반 사용자에게 유용한 개인 비서는 범용 모델 하나를 더하는 것이 아니라, 신뢰 가능한 권한과 연결을 한 번 설정하고 작은 업무를 실제로 끝내는 시스템이다.

4.1. 도구 연결을 중앙화하되 권한은 최소화한다

1. MCP 게이트웨이가 여러 비서의 연결 설정을 한곳에 모은다

   1. Executor라는 프로젝트는 Gmail·Google Drive·Notion 등의 연결을 집의 Linux 서버에 둔 중앙 MCP 게이트웨이로 제공한다. Cloudflare DNS 프록시로 외부에서도 접근한다.
   2. 개인 비서마다 각 서비스를 다시 연결하는 대신 MCP 하나에 로그인하면 도구, 사용법 스킬, 프롬프트, 설정을 함께 가져온다. 한 곳에서 연결을 바꾸면 기기와 보조자마다 반복 설정할 필요가 줄어든다.
   3. 일부 기능은 제품 고유 연결을 유지하는 편이 낫다. 예를 들어 Grokbot의 금융 커넥터는 직접 MCP로 대체할 생각이 없다는 사례가 나온다.
   4. 핵심 원칙은 읽기 전용(read-only)으로 시작하고, 쓰기(write)는 실행 직전에 명시적 승인을 받는 것이다.

2. 여러 개인 비서를 병행하면 기억과 주의력이 분산된다

   1. 한 참석자는 Instinct, Poke, Lindy를 동시에 써 “지옥” 같다고 했고, Slack 연결은 편리하다고 덧붙였다. 여러 도구의 대화를 어디서 했는지 잊어버리는 주의 비용도 문제다.
   2. 보조자마다 기억이 조금씩 달라지고 서로 다른 경험을 쌓으므로, 한쪽에서 다른 쪽으로 기억을 가져와도 동일한 관계와 맥락이 복원되지 않는다. “업무는 Grok, 개인 관리는 Muse”처럼 역할을 나누려 해도 항상 깔끔하지 않다.
   3. 한 패널은 Grokbot을 회사 관리용으로 약 30개 운영하고, Chief of Staff·PM 역할을 나눠 Linear 티켓으로 서로 연결한다. Muse는 음성으로 호텔 위치나 이동 시간을 즉시 물어보는 일회성 비서로 쓴다.
   4. 피해가 적고 독립적인 작업은 여러 비서에게 복사해 보내 누가 더 빠르고 나은지 비교하기도 한다. 다만 이렇게 여러 제품을 시험하는 것은 최적화된 일상 경험이라기보다 고급 사용자가 비교 실험을 하기 위한 방식이다.

3. 제품별 조합은 사용자마다 다르다

   1. 어떤 사람은 이메일·개인 데이터를 연결하지 않는 Instinct로 업체에 연락하고 행사 예약을 돕게 하며, 개인 비서는 스크립트와 Markdown 기억이 담긴 Git 저장소에서 직접 Codex CLI로 실행한다.
   2. 다른 사람은 업무 행정에 Grokbot, 코드·도구 실행에 Codex와 자체 하네스, 장난감·쇼핑·Marketplace 검색에 Muse를 쓴다. Muse의 브라우저 사용 능력이 예상보다 좋다는 평가도 있다.
   3. Grokbot에서 Cursor 클라우드 에이전트를 호출해 Opus 5.5로 코드를 작성시키면 Grok 4.7 자체보다 훨씬 나은 작업이 가능하다는 설명이 나온다. 그러나 프로젝트마다 클라우드 환경, 환경 변수, 스크립트를 맞추는 과정은 큰 설정 부담이다.
   4. Cursor는 코드를 바꾸고 PR을 만들고 싶어 하는 반면, 사용자는 단순한 답이나 샌드박스에서의 실험을 원할 수 있다. Devon은 하나의 컴퓨터처럼 새 저장소·기존 저장소·여러 저장소를 자유롭게 다뤄서, 아이디어만 시험하고 싶을 때 유연하다는 평을 받는다.
   5. 코딩 에이전트는 차이를 찾아 코드와 문서를 수정하는 방식으로 훈련돼 있다. “오늘 무엇을 코딩할까요?”라는 시스템 지시를 받는 제품은 코드를 쓰지 않고 질문에 답하거나 모델을 평가해 달라는 요청과 맞지 않는다.

4.2. 일반 사용자의 시간 절약과 새 하드웨어 접점

1. 비서의 실질적 가치는 놓친 일정을 막고 계획을 대신 세우는 데 있다

   1. 한 사용자는 주말 아침 아이들을 태권도 수업에 데려갔다가 휴관이라 화가 났다. 일정만 기록하는 데서 끝나지 않고, 장소가 실제로 여는지 알려 주는 비서가 필요하다고 느꼈다.
   2. 이에 주말이 가까워지면 아이들과 배우자를 위한 지역 활동을 검색하는 봇을 만들었다. 저렴하고 빠른 선택지와 더 비싸지만 좋은 선택지를 제안하고, 일정에 넣어 둔 장소가 닫혔다는 사실도 함께 알려 준다.
   3. 개인 보조자는 바쁜 임원에게 이미 존재하는 인간 비서의 역할을 더 많은 사람에게 열어 줄 수 있다. 사람들이 뉴스에서 듣는 AI 위험만이 아니라, 실제로 머리 손질 예약을 해 주고 몇 분을 절약하는 경험을 해 보면 효용을 체감한다는 주장이다.
   4. 모델이 이메일을 읽고 예약할 수 있다는 기능 목록보다 “무엇을 맡겨 시간을 아꼈는가”라는 사용 사례를 중심에 둬야 한다.

2. 짧은 답에는 검색, 긴 작업에는 대화형 보조자를 쓴다

   1. Google AI 검색 요약은 빠른 답변에 저평가된 도구라는 의견이 나온다. 검색 결과 페이지가 뜰 때쯤 답을 볼 수 있고, ChatGPT의 최대 추론 모드처럼 10~30초씩 기다릴 필요가 없다.
   2. Mac용 Recast는 단축키 ⌘+Enter로 질문을 입력하고 원하는 모델로 보내 결과를 클립보드에 복사하는 흐름을 제공한다. 모델을 직접 선택할 수 있다는 점이 장점이다.
   3. 여행 중 자정에 암스테르담 기차역에서 내린 사용자는 Instinct에 가까운 역과 비접촉식 카드 결제 가능 여부를 물었다. Google보다 빠르지는 않을 수 있어도, 짧은 예·아니오 답을 얻기 위해 검색 결과 전체를 보는 것보다 덜 부담스러웠다.
   4. 검색을 여러 비서에 분산하는 것은 최적의 경험이 아니다. 그렇지만 고급 사용자는 여러 제품을 직접 시험해 차이를 알아야 한다는 현실도 함께 인정된다.

3. 차량·안경·작은 기기가 보조자를 현실 세계에 붙인다

   1. Tesla 안에서 음성으로 Grok에 말하고, 이어서 특정 봇에 업무를 보내 답변을 받는 사용 경험이 소개된다. 음성 입력과 차량의 자율 주행 기능이 결합되면 이동 중에도 실제 업무를 맡기는 미래가 가까워진다.
   2. Meta의 Muse 안경과 작은 Tamagotchi 같은 Charm 기기도 대화에 오른다. 한 참석자는 에이전트들이 새 기기를 각각 사도록 설정할 정도로 Charm이 출시되면 바로 품절될 것이라 예측하며, 크리스마스 선물로도 완벽하다고 농담한다.
   3. 반면 Apple Watch를 쓰지 않는 이유는 충전을 잊기 때문이다. 보조 배터리를 여러 개 사서 여기저기 둬도 충전해야 할 물건이 늘어나는 문제는 해결되지 않는다는 반박이 이어진다.
   4. 하드웨어 보조자의 성공에는 기능뿐 아니라 충전·휴대·알림 피로도 같은 생활 습관과의 적합성이 필요하다.

4.3. 마무리 발언과 패널이 알린 일

1. AI 공포를 반박하려면 체감되는 도움을 보여 줘야 한다
   1. 한 참석자는 사람들에게 AI 시스템으로 가능한 일을 상상해 보라고 요청한다. 뉴스에서 AI가 위협이라고 듣는 경험과, 실제로 예약을 대신해 시간을 아끼는 경험은 다르며, 후자가 널리 알려져야 한다고 말한다.
   2. 그 참석자는 매주 목요일 진행하는 팟캐스트, 향후 공개될 오픈 모델과 하네스 작업을 알리고 X 계정 @Allisonology를 소개한다.
   3. 다른 패널은 Fortune 100 의료기관·Fortune 500 기업·성장 중인 AI 스타트업을 위해 에이전트 신뢰성을 높이는 Raindrop을 운영한다고 소개한다. 하루 1,000회 미만 실행하는 대부분의 사용자는 무료로 쓸 수 있다고 설명하며 자신을 CTO라고 밝힌다.
   4. Ben Davis는 YouTube 채널과 팟캐스트를 Nerd Snipe라는 이름으로 소개한다.
   5. Dexory는 Human Layer의 창업자로서 ‘소프트웨어 공장(software factory)’ 대신 ‘소프트웨어 대장간(software forge)’이라는 표현을 쓰기 시작했다고 말한다. 공장이 실패할 조건을 설명한 발표가 “공장을 싫어하는 사람”으로 오해돼 바이럴이 됐지만, 실제 의도는 실패 요인을 피하는 방법을 말하려던 것이었다고 해명한다.
   6. 마크다운 스킬을 잘 쓰는 사람을 믿는다는 추천이 오가고, 다음 게스트 후보 Maya가 언급된다. 마지막에는 첫 High Taste Testers 방송에 참여해 줘서 고맙다는 인사와 좋아요·구독 요청으로 끝난다.

주요 발언 모음

“프로덕션 소프트웨어를 만든다면 모델을 밤새 쉬지 않고 돌렸을 때, 안정적으로 읽고 소화할 수 있는 양보다 더 많은 코드를 만들게 된다.”

“문제 하나를 해결하려고 보조자를 데려왔는데, 이제 문제가 세 개가 됐다. 인프라를 유지해야 하고, 서버가 끊기면 그 문제도 내가 관리해야 한다.”

“읽기는 괜찮지만, 쓰기는 명시적인 허가를 받는 것이 내 기준이다.”

“분류는 정말 어렵다. 0이나 1만 내놓는 이진 분류가 세상에서 가장 어려운 문제 중 하나일 수도 있다.”

“에이전트라는 말보다 보조자라고 부르자. 사람들은 이미 개인 비서가 무슨 일을 하는지 알고 있다.”

“라우팅은 좋지 않다. 검색을 여기저기로 보내기보다, 검색이 전부 한곳에 있어야 한다.”

핵심 데이터 & 수치

• 영상 게시일·길이: 2026-10-16 게시, 약 75분 21초.
• Pi Durable: append-only 로그로 에이전트 상태를 외부화해 로컬·클라우드 사이에서 이어 가는 설계가 소개됐다.
• Decision 모델 비용 절감 예: 에이전트 추적에서 기억을 추출하는 파이프라인에 판단 모델을 넣어 비용을 10~20배 줄였다는 실험이 언급됐다. 정확도는 Opus 5.5와 잘 맞았다는 내부 평가지만, 일반화된 공개 벤치마크 결과는 아니다.
• Grok 4.7 가격: 컨텍스트 20만 토큰 초과와 Fast 모드가 각각 가격을 두 배로 만들고, 둘 다 적용하면 대략 세 배에 가까워진다는 사용자 설명이다.
• Slop Code Bench: 일부 10개 문제 실험에서 Opus 5.5는 약 3만 줄을 작성했으며, 51% 이상이 테스트였다. 이전 비교 모델은 약 1만 줄, 테스트 비중 약 10~15%였다.
• 서브에이전트 운용: 설정 48개는 Astra 사용 한도를 약 2시간 만에 소진한 반면, 다른 사용자는 약 15개를 유지했다. 40개를 병렬 실행한 경험도 소개됐다.
• 프로토타입: 강한 모델을 얻은 뒤 한 사용자가 약 10개 프로토타입을 병렬로 진행하고 밤새 에이전트를 돌리는 방식으로 전환했다.
• MCP 게이트웨이: Gmail·Drive·Notion 연결을 단일 MCP 접점으로 중앙화하는 Executor 프로젝트 사례가 제시됐다.
• 제품 채널 규모: 한 참석자는 업무별 Grokbot 약 30개를 운용한다고 했으며, 별도의 한도 예시로 무료 사용 기준 하루 1,000회 미만 실행이 소개됐다.
• 시장 소문: TypeSafe의 100억 달러 라운드는 확인된 사실이 아니라 패널이 언급한 소문이다.

결론 및 시사점

1. 개인 비서의 제품 기준은 ‘기능 수’가 아니라 맡길 수 있는 부담의 감소다. 일정·예약·검색·이메일처럼 실제 시간을 돌려주는 업무를 완수해야 한다.
2. 실행 위치와 상태 이전을 제품에서 숨기고 해결해야 한다. 로컬·클라우드·Mac Mini가 어디서 돌아가는지 사용자가 관리하게 두면 항상 켜져 있는 비서가 되지 못한다.
3. 읽기 권한과 쓰기 권한을 분리하고 승인 UX를 분명히 해야 한다. 이메일과 결제 정보에 접근하더라도 실제 전송·구매는 사람이 검토하고 승인할 수 있어야 한다.
4. Decision 모델의 경제성은 초저지연 UX와 기존 라벨 재사용에 있다. 모든 인터랙션에 큰 생성 모델을 쓰지 않아도 된다.
5. 모델 평가에서는 범용 능력, 특정 데이터 과적합, 실제 운영 비용을 구분해야 한다. 단일 벤치마크로 전문 모델과 범용 모델의 우열을 쉽게 단정하지 않는다.
6. 밤샘 병렬 코딩은 검토 용량에 맞춰 제한해야 한다. 정해진 작업 수, 로그 감시, 실패 시 재지시, 사람의 코드 검토가 생산량 증가보다 앞서야 한다.
7. 다수의 보조자를 동시에 쓰는 경험은 기억·검색·주의력 비용을 만든다. 표준화된 연결과 신뢰 가능한 하나의 인터페이스가 생태계의 중요한 과제다.
8. 하드웨어 비서는 충전과 휴대까지 포함해 생활에 자연스럽게 들어와야 한다. 음성·차량·안경이라는 새 접점은 유망하지만, 또 다른 관리 대상을 더하는 순간 장점이 사라진다.

핵심 요약 (20줄)

1. Dev Day 직후 공개된 Dots와 협업 기능은 흥미롭지만 앱 안에 깊이 숨겨져 있어 사용자가 발견하기 어렵다.

2. Codex와 ChatGPT를 합친 인터페이스는 사이드바와 모드가 늘고 성능이 흔들려 개발자와 일반 사용자 모두에게 혼란을 줬다.

3. 개인 비서의 핵심은 이메일을 읽고 중요한 일을 골라내며 예약과 일정을 대신 처리해 사용자의 부담을 줄이는 데 있다.

4. 기존 코딩 에이전트를 개인 비서처럼 구성할 수는 있지만 서버와 스크립트를 직접 관리해야 하면 보조자가 오히려 일을 늘린다.

5. Pi Durable은 append-only 로그로 에이전트 상태를 저장해 로컬과 클라우드 사이에서 작업을 이어 가려는 접근이다.

6. 공개된 안정적 상태 이전 표준과 API가 부족해 각 회사와 사용자가 서로 호환되지 않는 실행 하네스를 만들고 있다.

7. Decision 모델은 기존 구조화 분류를 더 낮은 비용과 지연 시간으로 처리해 검색 메뉴 같은 UX에 AI를 넣을 수 있다.

8. 라벨이 충분한 조직은 과거 판단과 새 모델의 답을 비교해 불일치 사례만 검토함으로써 모델 전환 비용을 낮출 수 있다.

9. 이진 분류는 단순해 보여도 정답과 오답을 가르는 일이 어려우므로 모델의 확률과 벤치마크를 그대로 믿어서는 안 된다.

10. 판단 전용 모델은 범용 프런티어 모델과 특정 데이터에 맞춘 전문 분류 모델을 공정하게 비교하기 어렵다.

11. 참석자들은 Opus와 Fable의 글쓰기 감각, Astra Ultra의 코딩 성능, Muse Spark의 긴 멀티모달 입력을 각기 다른 강점으로 평가했다.

12. Grok 4.7은 긴 컨텍스트와 Fast 모드에서 가격이 크게 뛰고 토큰을 비효율적으로 쓰지만 X 실시간 검색은 유용하다는 평가를 받았다.

13. 오픈 모델은 검증 가능한 실험에 쓸 수 있지만 최신 프런티어 모델과 일상 업무 능력의 격차가 다시 커졌다는 의견이 나왔다.

14. 일부 Slop Code Bench 문제에서 Opus 5.5는 약 3만 줄을 작성했고 그중 절반 이상이 테스트였으며, 이전 모델은 약 1만 줄을 썼다.

15. 강한 코딩 모델은 밤새 여러 프로토타입을 만들 수 있지만 사람이 검토하고 이해할 수 있는 코드보다 더 많이 생산할 위험이 있다.

16. 제한된 5~10개 단계의 밤샘 루프와 감시되는 서브에이전트가 무제한 병렬 실행보다 현실적인 운영 방식으로 제시됐다.

17. 최신 모델의 프롬프트 인젝션 방어가 좋아져도 이메일을 잘못 공유하거나 인증 코드를 전달하는 우발적 실수는 남아 있다.

18. 개인 데이터는 읽기 전용으로 시작하고 이메일 전송이나 결제처럼 쓰기가 발생할 때 명시적인 사람 승인을 받아야 한다.

19. 아이들 주말 활동과 휴관 확인, 여행지의 간단한 질문 같은 구체적 업무가 개인 비서의 시간 절약 가치를 보여 준다.

20. 성공적인 AI 비서는 숨겨진 기능을 늘리는 대신 연결과 실행을 단순화하고 신뢰와 생활의 편의성을 실제로 높여야 한다.