OpenAI's Vision for the AI Super App — Akshay Nathan, OpenAI

URL: https://www.youtube.com/watch?v=gKhW6vL4V9A 날짜: 2026-07-29 채널: Latent Space (latentspacepod)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

OpenAI의 Productivity 팀을 이끄는 Akshay Nathan은, ChatGPT/Codex/ChatGPT Work를 하나의 "슈퍼앱"으로 통합하는 것이 ==개발자에게만 머물던 에이전트의 힘을 지식노동자와 모든 사람에게로 확장하는 시퀀싱 전략==이라고 설명한다.

• Codex 출시 후 OpenAI 내부 비개발자들이 자발적으로 Codex를 쓰기 시작했고, 이들이 그것을 "슈퍼파워"처럼 자랑스러워한 게 결정적 계기가 됨
• ChatGPT Work는 Codex와 동일한 하니스(harness)를 공유하며, UI/UX 차이(diff 뷰, 샌드박싱)만 다름 — 사용자가 어떤 모드에 있는지 선택할 필요가 없어야 한다는 원칙
• "developers → general knowledge work → everyone(개인 삶 전체)"라는 3단계 시퀀싱으로 배포 전략을 짜고 있으며, 10 million 유저 돌파를 발표

10분기 넘게 진행된 이 인터뷰에서 Akshay는 ChatGPT Work의 탄생 배경, Codex와의 하니스 통일, Sites/Artifacts 같은 신규 기능, 메모리(Memory V3, Chronicle), 서브에이전트/Ultra 모드 설계 철학, 그리고 AI 시대의 생산성 측정 문제까지 폭넓게 다룬다.

---

1. Akshay Nathan의 배경과 OpenAI 합류 과정

이 섹션은 그가 어떻게 "코드의 힘을 모두에게" 라는 개인적 테제를 좇아 커리어를 쌓았고, 그것이 결국 ChatGPT Work로 귀결되는 과정을 다룬다.

1.1. 커리어 궤적: 핀테크 → No-code 스타트업 → Airtable → OpenAI(2023)

1. 소비자 핀테크에서 시작
   1. 초기 커리어: 커리어 초반 소비자 핀테크(consumer fintech) 분야에서 일함
2. No-code/Low-code 스타트업 (Walrus)
   1. 핵심 가설: 엔지니어가 코드로 할 수 있는 일을 더 많은 사람에게 더 접근 가능한 방식으로 가져다주면 "진짜 마법"이 될 것이라는 가설을 갖고 스타트업을 창업
   2. 비전 LLM 이전의 자동화 테스트: LLM도, 비전 LLM도 없던 시절에 AI로 자동화 테스트(automated testing)를 하는 방법을 스스로 찾아냄. "당시엔 좀 조잡(jank)했지만" 할 수 있는 걸 했다고 회고
3. Airtable 재직
   1. 동일한 테제의 연장: 데이터베이스(혹은 데이터베이스 뒤의 파라미터들)를 사람들에게 가져다주면 정말 유용할 것이라는 같은 테제로 Airtable에서 일함
4. LLM 등장과 OpenAI 합류(2023)
   1. 누락된 퍼즐 조각: LLM이 등장하면서 "이것이 바로 코드의 마법을 모두에게 가져다줄 누락된 기술(missing technology)"이라는 확신이 생김 — 사용자가 내부에서 무슨 일이 일어나는지 몰라도 되는 방식으로
   2. ChatGPT Work는 그 테제의 구현체: 지금 하고 있는 ChatGPT Work 등 모든 작업이 이 오랜 테제의 결과물(manifestation)이라고 설명

1.2. 2023년 합류 당시 OpenAI와 지금의 차이 — "변하지 않은 것"이 더 흥미롭다

1. 합류 당시 우려와 반전
   1. 500명 규모에 대한 우려: 합류 시점 OpenAI는 이미 약 500명 규모였고, 더 초기 단계 회사를 찾고 있었기에 "스타트업스럽지 않으면 어쩌지" 걱정했음
   2. 예상보다 더 스타트업스러웠음: 실제로 합류해보니 상상 이상으로 스타트업 같았고, 이 느낌은 지금까지도 변하지 않았다고 강조 — 바텀업(bottoms-up) 야망과 누구든 아이디어를 내고 실행(ship)할 수 있는 자유가 여전함
2. 미션의 일관성
   1. AGI를 모두에게: "프론티어 지능을 모두에게 가져다주고 AGI를 만들어 모두에게 전달한다"는 미션이 합류 당시부터 지금까지 가장 매력적인 부분이었다고 함
   2. 비선형적 진행에 대한 인정: 이 비전이 선형적으로 진행되지 않을 것이며, 여러 제품을 시도하다 성공/실패가 갈릴 것임을 처음부터 인지하고 있었음. 지금은 그 조각들이 맞춰지기 시작(fall together)하는 단계라고 평가

1.3. Enterprise 재직 경험에서 배운 것 — "만능 해법은 없다"

1. ChatGPT Enterprise 초창기 관찰
   1. 거대 예산의 AI 배포팀: ChatGPT 출시 1년 후, 기업들이 앞다퉈 "AI 배포팀(AI deployment team)"을 거대한 예산과 함께 신설하던 시기를 회고
   2. 질문에 따라 답이 극단적으로 갈림: "무엇에 신났나"라고 물으면 처음엔 "데이터가 많다" 같은 원론적 답변만 나오지만, "구체적으로 어떤 유스케이스를 원하나"라고 물으면 완전히 다른, 다양성 폭발(variance explosion) 수준의 답변이 나옴
2. "박스"의 양면성
   1. 무엇이든 될 수 있다는 것의 함정: 사용자가 모델에게 "무엇이든" 말할 수 있다는 것이 마법이면서 동시에, 정확히 무엇을 해야 할지 모르게 만드는 문제이기도 함
   2. 사용자가 있는 곳에서 만나기: 엔터프라이즈에서 중요한 건 사용자가 풀려는 유스케이스를 파악하고, AI로 레버리지를 얻는 법을 실제로 가르치는 것이라고 강조
3. FDE(Forward Deployed Engineering)와 프로덕트의 구분
   1. Go-to-market vs 프로덕트: FDE 모션이 아무리 좋아져도, 결국 사용자가 컴퓨터/폰을 보고 있을 때 그들을 인도하는 건 프로덕트의 역할이라는 원칙을 강조

---

2. ChatGPT Work의 탄생 — "머지(merge)"의 배경

2.1. 결정적 계기: Codex의 비개발자 채택 폭발

1. 내부 UX 리서치에서 발견한 신호
   1. 비개발자들의 자발적 채택: Codex 출시(내부 사용 포함) 직후, 전략기획(strategic finance)이나 마케팅 등 비개발 직군 직원들이 자신들의 유스케이스에 Codex를 쓰기 시작한 것을 UX 세션에서 발견
   2. "자랑스러워하는" 태도가 핵심 신호: 단순히 사용한다는 사실보다, 사람들이 "이걸 쓰고 있다는 걸" 자랑스러워했다는 점(마치 슈퍼파워를 가진 것처럼 느낌)이 진짜 인사이트였다고 설명. 공동 진행자는 이를 "나 이거 쓰면 안 되는데 쓰고 있어" 같은 느낌이라고 표현
2. 배포 기반의 재발견
   1. 거대한 기존 배포망 활용: ChatGPT를 이미 사랑하는 거대한 사용자 기반이 있으니, Codex/에이전트의 힘을 그들에게 어떻게 보여줄지가 관건이 됨 — 이것이 "머지(merge)"와 "슈퍼앱" 개념의 출발점
   2. 개발자보다 훨씬 이른 확산: 에이전트의 힘이 개발자 전유물이 아니라 훨씬 더 일찍, 모두에게 확장 가능하다는 것을 이 시점에 깨달음

2.2. 포지셔닝: "Work"가 아니라 "Productivity"

1. 팀 이름이 "Productivity"인 이유
   1. 개인 생산성 포함: "엔터프라이즈"나 "워크"라는 단어 대신 "Productivity"를 쓰는 이유는 개인적 삶의 생산성도 포함하기 때문
   2. 실제 사례 — 분실 택배 찾기: 사내 Slack에 올라온 사례로, 한 직원이 아마존에서 온 사진만으로 ChatGPT Work에게 분실된 택배를 찾아달라고 요청했고, 에이전트가 주변 매물 목록들을 뒤져 정확한 아파트 단지를 찾아냄 — "일(work)"로 분류하기 애매하지만 "워키(worky)"한 사례의 전형
2. Codex 브랜드는 계속 유지
   1. 탭에 갇히지 않는 원칙: Codex 버전(데스크톱)에서 할 수 있는 모든 것을 ChatGPT Work에서도 할 수 있고 그 반대도 성립해야 한다는 원칙 — 사용자가 어느 경험에 있어야 하는지 "선택"할 필요가 없어야 함
   2. 의도적으로 다르게 만든 부분: Git 상태를 최종 사용자에게 얼마나 노출할지, diff 중심 UI를 얼마나 강조할지, 샌드박싱과 기본 안전 설정을 어떻게 다르게 둘지는 의도적인 프로덕트 결정으로 남겨둠

2.3. 하니스는 동일 — UX만 다르다

1. 공유되는 코어 하니스
   1. 플러그인/컴퓨터유즈/아티팩트 공통 개선: Codex와 ChatGPT Work 양쪽 모두 지식노동에 맞게 하니스가 개선되었고(플러그인, 컴퓨터 사용, 아티팩트 관련), 어느 쪽에 있든 동일한 힘을 얻음
   2. UX만 다름: Codex 모드에서의 UX(레포 기반 diff 표시 등)와 Work 모드에서의 UX(diff 미노출)만 의도적으로 다르게 설계됨
2. 라이브 데모 — 은퇴 계산기 스프레드시트
   1. 동일 프롬프트, 다른 표시 방식: "은퇴 계산기 스프레드시트를 만들어줘"를 Codex 모드와 Work 모드 양쪽에 동일하게 입력해 비교
   2. Codex 모드: 레포 안에 있어야 하며 시트 변경사항의 diff와 파일 편집 내역이 노출됨
   3. Work 모드: 같은 diff가 사용자에게 노출되지 않음 — 결과물(스프레드시트)은 동일하지만 과정 노출 방식이 다름

2.4. 라우터가 판단하는 모드 전환

1. 모델이 스스로 판단
   1. 자동 유도: 사용자가 일반 채팅에서 스프레드시트를 만들려고 하면, 모델이 이를 감지해 Work 모드로 유도하려는 라우팅 결정을 내림 (사용자가 명시적으로 스위치를 조작하지 않아도 됨)
2. 기존 ChatGPT 채팅 하니스는 그대로 존재
   1. "클래식"은 남아있다: 새 채팅을 시작하고 Work로 들어가지 않으면 여전히 기존 ChatGPT 채팅 하니스로 대화하게 됨 — 인라인이며 샌드박스에 있지 않음

---

3. 채팅 하니스 vs Codex 하니스 — "구술사(oral history)"

3.1. 발산과 수렴의 반복

1. 끊임없는 사이클
   1. Divergence-Convergence 반복: 하니스 진화는 발산(divergence)과 수렴(convergence)이 반복되는 상시적 과정이라고 설명
2. 채팅 하니스가 최적화해온 것
   1. 레이턴시와 퍼스낼리티: 검색·학습 같은 유스케이스가 많은 채팅 하니스는 레이턴시(latency)와 퍼스낼리티(personality) 최적화에 오래 집중해왔고, 이것이 사람들이 ChatGPT를 사랑하는 이유라고 설명
3. Codex가 알려준 것
   1. 무한히 유연한 컴퓨터 환경: 에이전트에게 "컴퓨터"라는 무한히 유연한 환경에 대한 접근을 주면 정말 강력한 일을 할 수 있다는 것을 Codex를 통해 배움
   2. 지식노동으로의 확장: 지식노동을 위해서는 이 "컴퓨터 환경" 방식을 자연스럽게 가져오되, 컴퓨터의 세부사항을 사용자로부터 일부 추상화하는 방향으로 감. 궁극적으로는 모든 곳에서 동일한 힘을 원한다고 밝힘

3.2. 모델 선택 가이드 — 기본값이 최선이어야 한다

1. 32개 옵션의 복잡성
   1. 선택지 과잉 인정: 현재 모델/reasoning 옵션이 너무 많을 수 있다는 걸 인정하며 단순화 작업 중이라고 밝힘
2. 기본 원칙
   1. Default가 최고여야 한다: OpenAI의 원칙은 "기본값이 모두에게 최선이어야 한다"는 것 — 파워유저를 위한 세부 옵션(reasoning 레벨, 모델 클래스 변경)은 존재하지만, 일반 사용자에게는 기본값 고수를 권장
   2. 비용/품질 불만족 시에만 조정: 효율(비용) 측면이나 지능(품질) 측면에서 만족스럽지 않을 때만 기본값에서 벗어나 다른 설정을 시도하라고 조언
3. "Goal + 낮은 reasoning" vs "Ultra/Extra-high" 논의
   1. 호스트의 워크플로우 질문: 공동 진행자가 "Soul light + Goal(더 많은 턴/터미네이션으로 reasoning effort를 보강)"이 Ultra나 Extra-high의 대안이 될 수 있는지 질문
   2. 상호작용 효과라 단정 어려움: Akshay는 이것이 상호작용 효과(interaction effect)라 단정하기 어렵다고 답하며, 사용자가 모델과 얼마나 자주 "조종(steer)"하고 싶은지에 대한 개인 취향의 문제라고 설명
   3. Ultra/멀티에이전트가 적합한 경우: 매우 복잡한 오픈 탐색(open exploration)이나 고도로 병렬화 가능한 작업에 적합
   4. Goal이 적합한 경우: 검증 가능한 방식으로 꾸준히 진전을 만들 수 있는 작업에 적합
   5. 대부분의 작업은 둘 다 아님: 대부분의 작업은 이 두 범주 어디에도 속하지 않으므로, 우선 기본 설정으로 시도해본 뒤 필요하면 조정하라고 권장

3.3. 모델 슬라이더 UI — 다차원을 1차원으로 투영

1. 단순화된 UI 철학
   1. 하나의 축으로 압축: 여러 차원(속도/효율 vs 품질/철저함)이 존재하지만 사용자에게는 이를 단일 슬라이더로 투영해서 보여줌
2. 모바일 등에서의 반응
   1. "패닉을 줄여주는" 슬라이더: 공동 진행자는 이 슬라이더가 (어떤 모델/설정을 써야 할지 모르는) 패닉을 줄여준다고 긍정 평가
   2. Advanced view: 고급 보기(advanced view)로 들어가면 더 세밀한 사다리(ladder) 형태 컨트롤이 있음
3. Turbo(Terra) vs Soul 용량 이슈
   1. Terra가 저평가되고 있음: 더 많은 사람이 Turbo(Terra)를 써야 한다고 언급 — Soul이 용량 부족(running out of capacity)을 자주 겪기 때문
   2. 자기 자신이 원인이라는 농담: 자신이 최근 은퇴 계산기 예제를 10분 넘게 돌리며 Soul 용량을 소모하고 있다고 웃으며 인정

---

4. Artifacts와 Sites — "일하는 방식" 자체의 변화

4.1. Artifacts: 에이전틱 엑셀

1. 모델 + 프로덕트 동시 개선
   1. 모델 측 개선: 5.4/5.5와 비교했을 때 아티팩트 품질이 극적으로 개선되었다고 설명
   2. 프로덕트 측 개선: 모델 개선과 함께 프로덕트 측에서도 아티팩트 경험을 강화
2. "엑셀 라이선스 없이 엑셀 같은 것"
   1. 동료(OpenAI Safety팀 Gabriel Chua)의 데모 일화: 공동 진행자가 OpenAI 세이프티팀의 Gabriel Chua로부터 엑셀 파일을 편집하는 에이전틱 엑셀 데모를 보고 충격받았다는 일화를 소개
   2. 엑셀 파일을 실제로 편집: 엑셀 라이선스 없이도 워커블(workable)한 에이전틱 엑셀이 가능해짐
3. "이건 아직 1단계일 뿐"
   1. 반복(iterate) 가능한 도구로서의 아티팩트: 지금 보이는 결과가 사용자가 처음 원했던 정확한 형태가 아닐 수 있으며, 고피델리티(high fidelity)로 반영되고 이터레이션이 쉬워야 신뢰가 쌓인다고 설명
   2. 동료에게 보낼 수 있는 수준: 동료(예시 속 "Sean")에게 보내도 통할 만큼의 결과물 수준을 목표로 함

4.2. Sites: 지식노동을 위한 아티팩트 + 프로토타이핑 도구

1. 두 가지 축의 Sites 활용
   1. 프로토타이핑 도구로서의 Sites (X/Twitter에서 많이 이야기되는 축): 이번 런칭에 쓰인 모델 슬라이더 UI 자체가 사이트에서 거의 완전히 개발됨 — 디자인/엔지니어링/프로덕트 협업이 사이트 위에서 이뤄짐
   2. 지식노동 아티팩트로서의 Sites (덜 이야기되는 축): 사내 재무팀(corporate finance team) 사례 — 과거엔 슬라이드/스프레드시트로 만들던 월간 리포트가 이제 팀 협업 매커니즘 자체로 "사이트"가 되었음. 이유는 사이트가 상대적으로 더 높은 대역폭(bandwidth)을 가지기 때문 — PowerPoint/Excel은 무한히 유연하지만 인간의 사용 능력이나 제품 자체의 한계에 부딪히는 반면, 사이트는 "무엇이든 요청하면 얻을 수 있다"
2. 호스트의 사례 — 보드게임 "Strata" 자율 연구
   1. 30장 사진으로 3D 플레이 가능한 사이트 생성: 물리적 블록으로 하는 보드게임 "Strata"를 주말에 30장 촬영해 ChatGPT에 던졌고, 1.7억(1.7 billion) 토큰을 소모해 3D 블록 배치가 가능한 완전 플레이 가능 사이트가 생성됨
   2. AI 간 셀프 플레이 학습: 게임을 학습할 친구가 필요했던 문제를 AI 두 개를 붙여 셀프 플레이(self-play)시키는 방식으로 우회 — 고전적인 RL(강화학습) 문제인 셀프 플레이 부트스트래핑
   3. 자율 연구(auto research)로 벤치마크 생성: 컨퍼런스 참석 중 직접 감독할 수 없어 파라미터가 너무 많은 상황에서, 사이트에게 "연구 대시보드(랩 패널)"를 요청해 자동으로 벤치마크와 스케일링 로우(scaling laws) 분석을 만들어냄
   4. 마크다운의 한계 → 사이트로 전환: 마크다운은 사람이 읽기에 최적이 아니며(정보가 너무 장황해짐), 사이트로 전환하니 정보를 커스터마이징하고 "이 부분은 필요 없다"는 식으로 이터레이션이 쉬워졌다고 소개. 이후 이 프로젝트는 사이트보다 더 강력한 데이터베이스/인프라가 필요해 사이트 밖으로 옮김
3. 공동 진행자의 유사 사례
   1. Goal 모드로 18분 53초 만에 유사 게임 재현: 사진 없이 규칙만 입력해 비슷한 결과를 만듦(단, auto research는 없음)
   2. GPT 이미지로 아바타 생성: 게임 디자이너들 사이에서 GPT 이미지 생성이 인기가 많다는 언급
4. Sites의 조직적 활용 패턴
   1. "덱(deck)"의 대체재: 팀 전반에서 예전에 덱이었던 캐노니컬 아티팩트가 이제 사이트로 대체되는 워크플로우가 관찰됨
   2. HTML 기반의 무한 유연성: 사이트가 순수 HTML이기 때문에 특정 요소를 강조하거나 히어로 이미지처럼 부각하는 등, 슬라이드 덱에서는 "무례(braid)"하게 느껴질 커스터마이징도 자유롭게 가능
   3. 장황함(verbosity) 문제 인지: 사이트 결과물이 너무 길고 장황할 수 있다는 피드백을 인정하며, 이를 개선할 여지가 있다고 언급

4.3. UX 철학 — "제품을 만드는 제품"의 균형

1. 단순함(simplicity) vs 능력(capability)의 균형
   1. 메타 프로덕트의 어려움: ChatGPT Work는 "제품을 만드는 제품"이라, 사용자가 만들 수 있는 것이 너무 많아서 전부 UI에 노출하면 압도된다는 근본적 긴장이 있음
   2. 충분한 UI 서피스 + 적절히 물러남: 사용자가 에이전트에게 표현하고, 검증(도구가 맞는지, 올바른 소스에서 가져오는지)할 수 있는 만큼의 UI는 주되, 그 이후엔 UI가 방해되지 않도록 물러나야 한다는 원칙
2. "Show, not tell"
   1. 텔레그램의 성장 전략과 연결: 온보딩/문서로 가르치기보다, 사람들이 실제로 뭘 할 수 있는지 "보여주는" 것이 핵심 채택 전략이라고 강조
   2. 공동 진행자의 개인적 리스크 고백: 과거 Developer Relations 업무를 했던 경험을 들며, "제품이 충분히 직관적이면 당신이 필요 없다"는 딜레마를 농담조로 언급
   3. 개인화된 telling/showing: 모델의 마법은 사용자가 과거에 뭘 했는지, 채택 여정 어디에 있는지에 맞춰 telling과 showing을 맞춤화(tailor)할 수 있다는 데 있다고 설명

---

5. 배포 시퀀싱 — 개발자 → 지식노동자 → 모두

5.1. 3단계 시퀀싱 전략

1. 1단계: 개발자 (Codex 시작점)
   1. 초기 채택자로서의 개발자: 개발자는 역사적으로 얼리어답터이며, 마찰(friction)을 감수할 의향이 더 높기 때문에 Codex가 여기서 시작됨
2. 2단계: 일반 지식노동 (General Knowledge Work)
   1. 새로운 도전 과제: 개발자에서 이 세그먼트로 넘어갈 때 "show not tell" 문제, 제품 이해도 문제, 아티팩트/컴퓨터 유즈 같은 이 코호트에 더 중요한 신규 역량 필요성이 대두됨
3. 3단계: 모두 (삶 전체로 확장)
   1. 경계의 흐릿함 이미 관찰됨: 보드게임 사례처럼 재미/개인 삶과 업무 사이 경계에 있는 사례가 이미 나타나고 있음
   2. 개인 사례 — 식단 계획: Akshay 본인도 집에서 "밀 플랜(meal plan)"을 짜는 데 ChatGPT를 사용하고, 컴퓨터 환경에 저장해 계속 참조한다고 소개
   3. "ChatGPT life / ChatGPT cooking": 공동 진행자가 이를 "ChatGPT life"라 명명, Akshay는 "ChatGPT cooking"으로 화답하며 기회가 크다고 인정

5.2. 파워유저와 캐주얼 유저 사이의 간극 좁히기

1. 조언 1 — 상상력을 넓혀라
   1. 3개월 전엔 불가능했던 것: 기술 발전 속도가 너무 빨라, 3개월 전엔 "절대 불가능"했던 것이 지금은 가능해지는 경우가 많다고 함
   2. 사내 리뷰 사이클 사례: 사내 성과 리뷰(review cycle) 작업에서 예전엔 모델이 "슬랍(slop)" 수준이라 별로 유용하지 않았지만, 지금은 코드/리뷰/Slack 등 모든 컨텍스트에 접근해 인간보다 더 나은 컨텍스트 취합(pulling contacts on wins/achievements)을 해낸다고 평가. 6개월 전 같은 사이클에서는 전혀 도움이 안 됐던 것과 극명히 대비
2. 조언 2 — 더 많은 컨텍스트를 줄수록 가치가 커진다
   1. 아티팩트/라이브러리 축적: 모델이 시간에 걸쳐 아티팩트를 라이브러리에 저장하고 계속 접근하게 하면, 예상치 못한 방식으로 프로액티브하게 컨텍스트를 끌어와 가치를 만들어낼 수 있음
3. 리뷰에서의 AI 활용 윤리 — 명확한 선
   1. "AI로만 작성한 리뷰"는 절대 안 됨: 공동 진행자(관리자 경험자)가 사람 평가에 LLM 결과물을 그대로 쓰는 것에 회의적이라고 문제 제기하자, Akshay는 "AI만으로 작성해서 리뷰로 제시하는 일은 절대 없다"고 명확히 선을 그음
   2. "컨텍스트 수집"일 뿐: 자신이 말한 건 순전히 컨텍스트를 모으는 것(agentic search)이지, 리뷰 자체를 대필하는 게 아니라고 구분
   3. 놓치는 것에 대한 인정: 대규모 조직(OpenAI 규모)의 Slack 메시지 양을 감안하면 AI도 뭔가는 놓칠 수 있지만, "나도 놓친다"며 인간 수준(human level)에 상대적으로(relative) 비교해야 한다고 답함
4. 공동 진행자의 개인 워크플로우 — 프로젝트별 노트 MD
   1. Codex 시스템 프롬프트 구조: 프로젝트마다 별도의 "secret notes.md"에 학습(learning) 내용을 기록하고, 글로벌 노트가 여기서 끌어오는 구조를 소개
   2. "초인간적"으로 느껴지는 순간: "4개월 전 이 프로젝트에서 이런 노트가 있었다"며 예상치 못하게 다시 꺼내주는 경험을 "quite superhuman"이라 표현
5. 팀 내 밈(meme) 자동화 일화
   1. 팀원이 만든 스케줄드 태스크: 런칭 준비 중 팀원 한 명이 Slack/Docs의 모든 대화를 훑어 최고의 밈을 만들어 공유 채널에 자동 게시하는 스케줄드 태스크(자동화)를 만듦
   2. 의미 있는 두 가지: (1) 모델이 실제로 "웃긴" 수준까지 발전했다는 점(1년 전엔 불가능), (2) 사용자가 생각지 못했던 연결(connections)을 찾아내는 능력이 밈 생성에 큰 도움이 된다는 점

---

6. 10 Million 유저와 5.6 런칭

6.1. 성공의 의미

1. "가장 성공적인 런칭"
   1. 5.0보다도 개인적으로 더 성공적: 이번 ChatGPT Work + 5.6 런칭이 오랜만에 가장 성공적인 런칭이며, 개인적으로는 5.0보다도 더 성공적으로 느껴진다고 평가
2. 문화적 결산(culmination)이자 새로운 시작
   1. 비전의 결실: Codex 내부 마법을 목격한 뒤 더 많은 사람에게 가져다주고 싶었던 오랜 비전이 실제로 작동하는 것을 보게 된 것이 "culmination"으로 느껴짐
   2. 여전히 갈 길이 멀다: ChatGPT 전체는 이미 수억(hundreds of millions) 유저를 보유하고 있어, 1000만은 시작에 불과하며 "모두가 이 마법을 느껴야 한다"는 다음 단계가 남아있다고 강조

6.2. Codex와 ChatGPT Work의 사용자 수 집계

1. 집계가 별도로 안 됨
   1. 동일 하니스 = 통합 집계: Codex 유저와 ChatGPT Work 유저를 별도로 언급할 수 없는 이유는 동일한 하니스를 공유하기 때문
2. ChatGPT Work는 유료 사용자 전용, 기본값 아님
   1. Free 티어에는 기본 제공 안 함: ChatGPT Free 사용자에게 ChatGPT Work가 기본값으로 제공되지 않으며, 현재는 유료 사용자만 이용 가능
   2. 점진적 교육 과정: 사용자에게 이 제품의 가치를 교육하고, 써보게 하고, 피드백을 받아 개선하는 여정(journey)이 될 것이라고 설명
3. Codex 브랜드는 계속 유지, 오히려 강화
   1. 개발자 시장에 대한 지속적 투자: 개발자는 오랫동안 핵심 시장이었고, 소프트웨어 개발 특화 기능을 계속 발전시킬 것이며, 이번 통합이 이를 저해하지 않는다고 강조
   2. 오히려 유틸리티 증가: 코드 작성에서 아티팩트 생성, 코드 검색으로 매끄럽게 넘나들 수 있어 Codex의 유용성이 오히려 증가할 것이라 전망
4. "Artifacts"라는 용어는 내부 전용
   1. 외부에는 노출 안 됨: 팀 내부에서는 "아티팩트"라고 부르지만 외부 사용자는 이 단어를 쓰지 않으며, 사람들은 익숙한 표현("ChatGPT Work가 슬라이드를 잘 만든다")으로 묘사한다고 소개 — 이것이 오히려 바람직한 현상이라고 평가

---

7. Open Claw와의 관계

7.1. Akshay 본인의 "Open Claw 모먼트"

1. 아내와 함께 가정 관리 자동화 시도
   1. 캘린더 자동 생성 등: 아내와 함께 Open Claw를 설정해 집안일을 관리하려 했고, 캘린더 이벤트를 자동 생성하는 등 꽤 유용했다고 회고
   2. 랩탑 고장으로 중단: 돌리던 노트북이 고장 나면서 다시 이어가지 못했지만, 여기서 얻은 영감이 많다고 언급
2. 팀 내부 전환 사례
   1. 운동 계획/식단 트래킹: 팀원 한 명이 예전에 Open Claw로 하던 일(운동 계획, 식사 기록)을 이제는 완전히 ChatGPT Work로 전환해서 쓰고 있다고 소개 — "일은 아니지만 개인 생산성" 영역
   2. 동일한 프리미티브: 스케줄드 태스크, 파일 시스템 저장, 시간에 걸친 참조 능력 등 Open Claw와 동일한 프리미티브가 ChatGPT Work에도 있음을 강조

7.2. ChatGPT Work가 Open Claw를 완전히 대체할 것인가

1. "아니다"라는 명확한 답
   1. 로드맵을 모르므로 단정은 어려움: Open Claw 로드맵에 관여하지 않아 확답은 못하지만, 완전 대체는 아닐 것이라고 답함
   2. 오픈소스만의 필요성은 지속: Open Claw 팀이 만든 것 같은 오픈소스 기술에 대한 니즈는 항상 있을 것이며, 거기서 영감을 얻어 ChatGPT로 가져오는 것이 성공이라고 봄
   3. 인지도 격차: ChatGPT를 들어보고 써본 사람이 Open Claw를 써본 사람보다 훨씬 많으므로, Open Claw의 마법을 가져와 더 많은 사람에게 전달하는 게 목표
2. 핵심 경험 철학: "한 곳(one place)"
   1. 버튼을 누르거나 다른 곳으로 갈 필요 없음: 사용자가 대화(세션)를 시작하는 순간, 그 자리에서 무엇이든 할 수 있는 것이 프로덕트의 마법이라는 원칙
   2. 확장 가능한 플러그인 시스템: 재무 앱이든 과학 작업(코드 작성 능력)이든, 필요한 도구에 연결할 수 있는 확장형 시스템을 지향. 각 영역 최고의 전문 제품은 항상 존재하겠지만, 핵심 경험 안에 최대한 많은 마법을 담고 싶다는 목표

7.3. 재무 관리 사례

1. 자산 커스터디는 아직 불가
   1. 현금/자산 보관은 미지원: ChatGPT가 아직 현금이나 자산을 직접 보관(custody)하지는 않음
2. 재무 계획/예산은 이미 가능
   1. 파이낸스 플러그인으로 대체 가능: 은퇴 계획, 재무 계획, 예산 관리(budgeting) 등은 파이낸스 플러그인으로 이미 가능해졌고, 본인이 과거 쓰던 도구의 해당 기능은 이제 대체됐다고 평가
   2. 공동 진행자는 아직 안 써봄: 건강/재무 데이터를 확인하는 게 "무섭다"며 아직 연동해보지 않았다고 고백 (공통된 회피 심리로 공감대 형성)
3. 에이전틱 서치의 UX 이점
   1. 버튼/필터의 시대가 저물다: 기존 재무/예산 앱은 파워를 주려면 노브(knob)와 필터를 계속 추가해야 했지만, 올바른 데이터 연결만 있으면 어떤 질문이든 던져서 바로 답을 얻을 수 있는 시대가 됐다고 설명
   2. 중앙집중화의 가치: 스마트 스케일, 워치 등 여러 건강 앱을 한 곳에 모으는 것 자체가 가치라고 공동 진행자가 언급 — Open Claw의 "퍼스널 OS" 개념과 연결됨

7.4. 데이터 웨어하우스/시맨틱 레이어 질문

1. 접근 패턴에 따라 다르다
   1. 즉시 응답이 필요하면 어려움: MCP/CLI/API를 통한 즉시(just-in-time) 데이터 풀링만으로는 실시간 응답이 어려울 수 있다고 인정
   2. 대부분의 유스케이스는 즉시성이 필요 없음: ChatGPT Work에서 원하는 유스케이스 대부분은 "에이전트가 가서 처리해올 태스크"이지 즉각 응답이 필요한 게 아니라는 점을 강조
2. 프로그래매틱 툴콜링과 서브에이전트로 시간 단축
   1. 병렬화 가능성 상승: 프로그래매틱 툴 콜링과 서브에이전트 덕분에 시간 소요의 일부가 병렬화 가능해짐
   2. MCP 기반 접근의 한계선 상향: 서드파티 서비스 호출(MCP 등)로 할 수 있는 일의 천장(ceiling)이 실질적으로 크게 올라갔다고 평가

---

8. 서브에이전트와 Ultra 모드 설계 철학

8.1. 서브에이전트를 보여주는 이유

1. 병렬/복잡 작업의 신호
   1. "이 프로덕트는 당신을 위한 것"이라는 신호: 다수의 병렬 트랙이 있거나 서브에이전트가 다룰 만큼 복잡한 태스크를 사용자가 인지하게 하려고 서브에이전트를 보여주기로 결정
2. 정보 과잉과의 균형
   1. 더 상세한 표시는 압도적일 수 있음: 서브에이전트가 정확히 뭘 하고 있는지 다 보여주는 것도 가능하지만, 이는 정보 과잉(overwhelming)으로 이어질 수 있어 현재는 "이중 트레이드오프(double edged trade off)"를 감안한 절충안이라고 설명

8.2. 사용자별 니즈의 다양성

1. 일부 사용자는 서브에이전트를 항상 켜둠
   1. 공동 진행자의 습관: 거의 모든 Goal 작업에 "서브에이전트를 쓰라"고 매번 지시하며, 시간 효율성과 비용(작은/저렴한 모델로 오프로드) 두 가지 이유로 이렇게 한다고 소개
   2. 반복 작업엔 세밀한 제어를 원함: 매일 반복하는 작업이라면 서브에이전트별로 세밀하게 튜닝하고 싶어하는 사용자도 있음
2. 모델 지정 가능 여부
   1. 프롬프트로 지정: 서브에이전트가 사용할 모델(Sonnet/Opus 등 Anthropic Claude Code 사례처럼)을 토글이 아니라 채팅으로 "지시"해서 스티어링한다고 설명 — 반복 작업을 위해 구축한 게 아니라면 이런 세부는 추상화됨
3. 5.6 런칭 당시의 부작용
   1. 서브에이전트 과다 사용으로 앱 크래시 논란: 5.6 런칭 당시 모델이 서브에이전트를 지나치게 많이 사용해 ChatGPT 앱이 프로세서 과부하로 크래시되는 현상이 회자됨. 본인들은 크래시를 겪지 못했지만(큰 노트북 사용), "vibe eval"의 일종으로 인지하고 있음

8.3. Ultra 모드 접근성 제한 조정

1. 초기엔 덜 오피니언化(opinionated)했음
   1. 누구에게나 노출: 처음 런칭 시엔 누가 Ultra를 써야 하는지에 대해 덜 명확한 입장이었음
2. 고급 설정 뒤로 이동
   1. 파워유저 대상 옵트인으로 변경: 사용 한도(limits)를 더 많이 소모할 수 있다는 점 때문에, 이해하고 쓰는 파워유저를 위해 "고급 설정"에서 켜야 하도록 변경함 — 이것이 관련 피드백의 주된 원인이었다고 설명

---

9. 메모리 — Memory V3와 Chronicle

9.1. Memory V3와 ChatGPT Work의 메모리 상속

1. ChatGPT를 "내 것"으로 느끼게 하는 핵심 요소
   1. 가장 많이 언급되는 애정 포인트: 친구/가족에게 ChatGPT의 어떤 점이 좋은지 물으면 "나를 안다"는 점이 1순위로 자주 나온다고 소개
2. 모든 대화가 메모리를 상속
   1. ChatGPT Work도 기본으로 상속: ChatGPT Work의 모든 대화는 기본적으로 ChatGPT 메모리를 상속받아 사용자를 알고 있고, 이 메모리에 다시 써넣을(write back) 수도 있음
   2. "Memory V3" 시스템의 일부: 이는 단순 텍스트 메모가 아니라 이전에 출시한 동일한 "Memory V3" 시스템의 일부라고 명시
3. 연속성의 가치
   1. 여러 해에 걸친 확장: ChatGPT에서 이미 몇 년간 쌓아온 것의 연장선처럼 느껴지는 게 강점이라고 평가

9.2. 메모리의 근본적 난제 — 검색(retrieval) 문제

1. "검색 문제"라는 진단
   1. 두 가지 측면: (1) 사용자에 대해 정확히 아는 것, (2) 그것을 적절한 타이밍에 EQ 있게 꺼내는 것(proactive하게, 긍정적인 방식으로 서프라이즈 주는 것) — 이 두 축의 난제라고 설명
2. 직접 담당은 아니라는 겸손함
   1. 불확실성 인정: 메모리를 직접 담당하지 않아 "더 큰 문제가 무엇인지" 확답은 어렵다고 밝히면서도, 방향성에는 공감을 표함

9.3. Chronicle — 실험적 "슈퍼 메모리"

1. 컴퓨터 사용 이력을 학습하는 입력 소스
   1. 또 다른 메모리 입력 채널: Chronicle은 사용자가 컴퓨터를 어떻게 사용하는지로부터 학습하는, 메모리로 들어가는 또 다른 입력 소스라고 설명
   2. 실험적 기능, 기본 꺼짐 아님: 현재 실험적(experimental) 단계이며 기본으로 꺼져 있지 않지만(off-default가 아니라 명시적으로 켜야 함을 시사), 시도해보길 권장
2. 놓치는 것과 찾아내는 것 사이의 트레이드오프
   1. Slack 검색과 동일한 딜레마: 방대한 양의 정보를 다 파악하지는 못하지만, 사용자가 몰랐던 것을 찾아내 적절한 순간에 표면화(surface)하는 데 유용하다고 설명
   2. 인사이트와 장기 컨텍스트 구축용: "주로 인사이트와 장기적 컨텍스트 구축용"이라는 질문에 "정확히 그렇다"고 확인
3. 메모리 생성 자체의 스킬화
   1. "내 로그를 훑고 스킬을 추가하라"는 활용법: 공동 진행자는 Chronicle이 자동화(크론잡)와 결합해 "내 메모리/로그를 검토하고 스킬을 만들어라"는 식으로 쓸 수 있다며 저평가된 기능이라고 언급
   2. Chronicle이 메모리 생성 자체를 다르게 만든다: 단순히 메모리를 참조하는 게 아니라, Chronicle을 켜두면 훨씬 더 깊은 메모리가 "생성"된다는 점이 차별점이라고 강조

---

10. AI 이전/이후 프로덕트 개발과 팀의 미래

10.1. 아이디어 → 실제 구현 속도의 극적 변화

1. 속도의 비약
   1. 5-10년 전 대비: 예전엔 스크래피(scrappy)하고 MVP를 만들 의지가 있어야 빨랐지만, 지금은 만들 수 있는 범위 자체가 훨씬 넓어졌다고 평가
2. 검증 루프의 단축
   1. 더 빠른 사용자 검증: 아이디어를 더 빨리 검증하고, 사용자·내부 닥터(doctor)와 대화하며 방향을 맞출 기회가 많아짐 — 이 루프가 그 어느 때보다 촘촘해졌다(closed)고 표현
   2. 소비자에게도 이득: 이는 제품 개발의 승리이자, 더 나은 제품이 초기부터 나오게 되므로 소비자/사용자에게도 승리라고 설명

10.2. 팀 규모와 역할의 변화

1. 팀이 작아지는가?
   1. "할 일이 더 많아졌다": 개인/소규모 팀이 예전보다 더 많은 걸 해낼 수 있게 됐지만, 동시에 해야 할 일 자체도 늘어나 팀이 더 야심차진다(ambitious)고 평가
2. 직무 경계의 흐릿함
   1. EM/PM/엔지니어/디자이너 경계 붕괴: 전형적 프로덕트 개발 직군(EM, PM, 엔지니어, 디자이너 등) 사이의 경계가 흐릿해지는 걸 목격했다고 설명
3. "미래엔 4가지 직업만 남는다"는 밈에 대한 반응
   1. 밈 내용: 공동 진행자가 "AI 슬랍 캐논(대량으로 토큰만 태우는 사람), SRE(책임지는 사람), 물건 파는 어른들, 인기 있는 사람들" 4직업만 남는다는 밈을 소개
   2. T자형 인재론으로 반박/보완: Akshay는 모두가 T자형(T-shaped)이 될 것이라 전망 — AI 덕분에 누구나 제너럴리스트가 될 수 있고(디자인 감각이 없어도 AI 도움으로 반복 개선 가능), 동시에 자신만의 전문성(T의 세로선)을 AI 도움으로 더 깊이 팔 수 있다고 설명. 이 조합으로 개인이 성취할 수 있는 범위가 "거의 무한(almost limitless)"해진다고 평가

10.3. 병목: 아이디어와 취향

1. 바텀업 야망의 시대
   1. 누구나 만들 수 있는 시대: 이제 누구나 만들 수 있으므로, 아이디어를 낼 권한이 밑에서부터 올라오는(bottoms-up) 야망의 시대라고 규정
2. 아이디어/취향이 진짜 병목
   1. "아이디어를 자동화해달라"는 요청은 실패: 공동 진행자가 "새로운 아이디어를 가져다 달라"는 자동화만큼은 LLM이 아직 잘 못한다고 지적
   2. 아이디어는 진공 상태에서 오지 않는다: 아이디어는 사용자와의 대화, 관찰한 마찰(friction)이나 피드백, 기존에 계획해둔 기반 위에서 나온다고 설명 — 그래서 "제너럴리스트"가 계속 가치 있는 이유는 이런 피드백 루프를 닫고(close the loop) 아이디어를 실제 근거 위에 세우는 역할이기 때문

---

11. 생산성의 정의와 측정 — "동작(motion)과 진전(progress)"

11.1. Productivity 팀의 미션

1. 불가능했던 일을 가능하게
   1. 핵심 미션 정의: "사람들이 예전엔 할 수 없던 일을 할 수 있게 만드는 것"이 팀의 미션이며, 지금은 지식노동(knowledge work) 관점에서 이를 바라보고 있다고 설명
2. 역할/배경의 사일로 해체
   1. 직군 무관 접근 가능: 어떤 직군에 있든 갑자기 무언가를 만들고, 이전엔 해석 못 했을 데이터에 접근할 수 있게 된다는 게 지식노동의 변화
3. 개인 삶으로의 확장
   1. 레버리지 제공이 목표: 결국 사람들에게 자신을 위한 시간을 만들어줄 수 있도록 레버리지를 주는 것이 목표라고 정리

11.2. 생산성 측정의 미해결 난제

1. "아직 알아내지 못했다"
   1. 목표의 다양성: 모든 사람의 목표가 너무 다르기 때문에, 진짜 측정 기준은 "그 목표를 달성했는가"인데 목표 자체를 사전에 알기 어렵고 개인별로 맞춰야 해서 매우 어렵다고 인정
2. 좋아요/싫어요(thumbs up/down)의 한계
   1. 무엇에 대한 반응인지 불명확: 사용자가 답변의 내용, 답변의 어투(vibe), 혹은 실제 목표 달성 여부 중 무엇에 반응해 thumbs down을 눌렀는지 알 수 없다는 한계를 지적
   2. 업계 전체의 숙제: 이는 OpenAI뿐 아니라 업계 전체가 풀어야 할 문제라고 규정 — 성공을 측정하는 근거이기 때문
3. 과거 프록시(proxy) 지표의 붕괴
   1. 코드 커밋, 라인 수, 스토리 포인트: 예전엔 이런 프록시 지표로 생산성을 가늠했지만, AI 시대엔 이 프록시들이 실제 목표 달성과의 상관관계를 잃어가고 있다고 지적 (토큰 수, PR 개수 등도 마찬가지)
   2. 새로운 측정법 필요성 인정: 업계가 새로운 측정 방법을 찾아야 한다고 인정

11.3. 관리자를 위한 조언 — "At-bats"의 질과 양

1. 핵심 프레임: At-bats
   1. 양보다 질이 핵심: 단순히 시도(at-bats)의 "양"이 아니라, 아이디어 생성 → 구현 → 피드백 수집 → 가설 검증/반증 → 다음 아이디어로 넘어가는 전체 사이클을 효율적으로 반복하는 "질"이 중요하다고 강조
   2. 문화적 요소도 포함: 코드/디자인/스펙 같은 산출물뿐 아니라, 팀이 겸손함(humility)을 갖고 이 과정을 여러 번 반복하면서도 동기부여를 유지할 수 있는 문화가 중요하다고 설명
2. 프론티어 기술 시대의 최우선 가치
   1. 가장 중요하게 보는 지표: 기술 프론티어에 있고 만들 것이 아주 많은 지금, 이 "at-bats 근육"이 팀에서 가장 중요하게 지켜보는 것이라고 정리

11.4. 가장 흔한 함정 — "동작과 진전의 혼동"

1. 핵심 인용구
   1. "동작과 진전을 혼동하는 것(conflating motion and progress)"이 함정: 도구 덕분에 동작(motion)은 그 어느 때보다 쉬워졌지만, 진전(progress)은 무엇을 성취하려는지에 대해 매우 구체적이고 의도적(prescriptive and deliberate)이어야 한다고 강조
2. 팀 차원의 처방
   1. 명확한 진전의 정의 필요: OpenAI가 전체 사용자에 대한 생산성 측정법을 찾기는 매우 어렵지만, 개별 팀 차원에서는 "우리 팀에게 진전이 무엇인지"에 대해 명확하고 의도적인 관점을 가져야 하며, 그렇지 않으면 동작과 진전을 쉽게 혼동하게 된다고 결론

---

주요 발언 모음

"Anyone can build now. I think um it's really is the era of like bottoms-up ambition." (누구나 이제 만들 수 있다. 이건 정말 바텀업 야망의 시대다.)

"The power was not only for developers... it could be extended to everyone." (그 힘은 개발자만을 위한 게 아니었다... 모두에게 확장될 수 있었다.)

"We don't want the user to need to choose which experience they're in." (사용자가 어떤 경험에 있어야 하는지 선택할 필요가 없기를 바란다.)

"I would never write something via only via AI and present it as a review for someone." (나는 절대 AI로만 무언가를 작성해서 누군가에 대한 리뷰로 제시하지 않을 것이다.)

"It's it doesn't matter, right? Like it's it needs to be human level... relative." (AI도 놓칠 수 있다. 하지만 그건 인간 수준과 상대적으로 비교해야 한다.)

"I think maybe the trap is like conflating motion and progress." (아마 함정은 동작(motion)과 진전(progress)을 혼동하는 것일 거다.)

"Motion is much easier now than ever before because of the tooling that we have. But progress requires you to be like very prescriptive and deliberate about what you're actually trying to achieve." (도구 덕분에 동작은 그 어느 때보다 쉬워졌다. 하지만 진전은 실제로 무엇을 성취하려는지에 대해 매우 구체적이고 의도적이어야 한다.)

핵심 데이터 및 수치

• 500명 → 현재: Akshay가 2023년 합류 당시 OpenAI 인원은 약 500명 규모였음
• 10 million 사용자: ChatGPT Work가 이번 인터뷰 시점 기준 1000만 사용자를 발표
• 1.7 billion 토큰: 호스트가 보드게임 "Strata"의 3D 플레이 가능 사이트를 만드는 데 소모한 토큰 수
• 18분 53초: 공동 진행자가 Goal 모드로 동일 보드게임의 유사 버전을 만드는 데 걸린 시간
• 5.4 → 5.5 → 5.6: 아티팩트 품질이 극적으로 개선된 모델 버전 흐름, 5.6이 ChatGPT Work와 같은 날 출시됨
• 32개 옵션: 현재 사용자에게 노출된 모델/reasoning 설정 옵션 수(공동 진행자의 표현, 단순화 필요성 인정)

결론 및 시사점

1. 하나의 하니스, 여러 개의 문: ChatGPT/Codex/ChatGPT Work는 동일한 코어 하니스를 공유하며, 사용자가 "어떤 모드"에 있는지 신경 쓰지 않도록 만드는 것이 제품 철학의 핵심이다. 이는 프로덕트 설계 시 사용자에게 선택을 강요하지 않는 것이 왜 중요한지 보여주는 사례다.
2. 개발자 → 지식노동자 → 모두라는 배포 시퀀싱은 의도된 전략이며, 각 단계마다 필요한 새로운 역량(show not tell, 아티팩트, 컴퓨터 유즈)이 다르다는 점을 명확히 인식하고 있다.
3. 아이디어와 취향이 새로운 병목이라는 진단은, AI로 실행(execution) 비용이 급감한 시대에 오히려 "무엇을 만들지 판단하는 능력"이 희소해진다는 시사점을 준다.
4. AI를 사람 평가(리뷰)에 활용할 때는 "컨텍스트 수집"과 "최종 산출물 작성"을 명확히 구분해야 한다는 원칙은, 조직에서 AI를 인사평가에 도입할 때 참고할 만한 윤리적 가이드라인이다.
5. 생산성 측정의 프록시(코드 커밋, 스토리 포인트 등)가 AI 시대에 무의미해지고 있다는 진단은 관리자들에게 중요한 경고다. 대안으로 제시된 "At-bats의 질(퀄리티)"과 "동작과 진전을 혼동하지 말라"는 원칙은 실무에 바로 적용 가능한 프레임워크다.
6. 메모리(Memory V3)와 Chronicle은 검색(retrieval) 문제로 요약되며, 정확성과 EQ(적절한 타이밍에 표면화)라는 두 축에서 여전히 미해결 난제로 남아있다.