OpenAI''s Head of ChatGPT: We''re entering a new era of AI (again)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Tibo Sottiaux가 말하는 AI의 새 시대는 ChatGPT가 목표와 기억을 갖춘 상시 에이전트로 발전하며 제품·업무·인터넷의 설계를 함께 바꾸는 전환이다.

📌 핵심 요점

1. 현재 성능을 넘어 제품을 설계해야 한다. Sottiaux는 약 1년 뒤 기술이 대략 10배 좋아진다는 가정을 제시하며, 에이전트가 인터넷 행동의 대부분을 수행할 미래에 맞춰 처리 규모와 비용 구조를 준비해야 한다고 주장한다.
2. 반복 실행 설정에서 목표를 학습하는 상시 에이전트로 이동한다. dots는 사용자의 목표·선호·과거 맥락을 기억하고 피드백을 학습하며 24시간 일하는 방향을 지향한다. 당시 공개한 기본 dot에서 역할별 가상 팀으로 확장하려 하지만, 강한 단일 에이전트의 등장에 따라 팀 규모는 다시 줄어들 수도 있다.
3. 음성·기억·공동 작업을 결합하고 설정 부담을 줄인다. ChatGPT에 Work와 dots의 기능을 통합하고 모델 선택의 복잡성을 낮추려 한다. 빠른 응답과 음성 제어는 몰입을 돕지만, 맥락 전환·고립감·성과 압박까지 줄여야 업무 경험이 개선된다.
4. 생태계 개방은 배포와 수익 배분을 연결한다. 외부 개발자에게 플러그인 확장·발견 기능을 열고, 구독자의 사용량이 외부 제품에서 소비되면 파트너와 수익을 나누는 구조를 계획한다. 추천은 사용자 유지율, 작업 성공 여부, 품질에 따라 조정한다.
5. 자율성이 커질수록 안전 통제와 인간의 판단이 중요해진다. 운영 시스템에 접근하는 dot에는 보호 장치와 모니터링을 적용하고, 주 에이전트와 별도로 위험 행동과 프롬프트 주입을 감시한다. 사람에게는 타이핑 속도보다 사용자 이해, 취향, 결과물을 평가하는 판단력과 빠른 학습을 강조한다.

🧩 배경과 문제 정의

• AI 제품을 현재 성능에 맞춰 설계하면 빠른 모델 개선과 에이전트 중심의 인터넷 사용 확대에 충분히 대응하지 못할 수 있다.
• 여러 에이전트와 반복 실행 구조를 직접 관리하는 방식에는 설정 부담이 있다. 목표와 선호를 기억하고 피드백으로 학습하는 상시 에이전트가 대안으로 제시된다.
• AI로 업무 처리 능력이 커지는 동시에 잦은 맥락 전환, 고립감, 더 많은 성과를 내야 한다는 압박이 생긴다. 생산성뿐 아니라 사람의 협업과 주의력까지 고려해야 한다.
• 장기 실행 에이전트를 확산하려면 안전성과 보안, 자연스러운 인터페이스, 외부 개발자가 참여하고 수익을 얻는 생태계가 함께 필요하다.

🕒 시간순 섹션별 상세정리

1. 현재 성능을 넘어 에이전트 중심의 인터넷을 준비해야 한다

• 1년 뒤 AI가 지금보다 대략 10배 좋아진다고 가정하면 제품을 만드는 방식도 달라져야 한다는 견해다. 현재 가능한 기능만 기준으로 삼으면 앞으로의 개선을 충분히 반영하지 못할 수 있다 [00:04]
• 인터넷 행동의 대다수를 에이전트가 수행하게 될 것으로 전망한다. 에이전트가 사용하는 제품으로 성공하려면 그에 맞는 규모를 감당하도록 설계해야 한다 [00:16]

2. 코딩 위임과 모델 개선에 따라 에이전트 팀 규모가 달라진다

• 업무 추세, 사업, 다음 기능, 이전 출시 성과를 분석하는 코드는 주로 Codex가 작성한다. 직접 코드를 손으로 쓰는 일은 주말에 취미처럼 문제를 푸는 정도로 줄었다 [02:00]
• 초고속 에이전트를 쓰면서 여러 에이전트를 병렬로 돌릴 필요가 줄고 작업에 몰입하는 감각이 돌아왔다. 응답 속도는 업무 방식에 직접적인 영향을 준다 [02:31]

3. 반복 구조를 조정하는 대신 목표를 학습하는 상시 에이전트로 이동한다

• 사용자가 반복 실행 구조를 일일이 설정하고 조정하는 방식이 장기적인 해법이라고 보지 않는다. dots의 방향은 목표와 선호를 이해하고 피드백을 학습하며 24시간 일하는 에이전트다 [03:19]
• 출시한 시스템이 완벽하지는 않으며, Pro 사용자의 실제 이용을 통해 개선할 계획이다. 궁극적으로 사용자는 원하는 결과를 전달하고 시스템이 학습하게 해야 한다 [03:45]

4. 음성·공동 작업·통합 인터페이스가 업무 방식을 다시 바꾼다

• 음성과 멀티모달 입력·출력이 결합되고 있지만 현재 경험은 여전히 어색하다. 자연스러운 대화, 정확한 기억, 사람과 에이전트가 함께 쓰는 화이트보드가 결합되면 기존 대화창과 클라이언트를 넘어서는 변화가 가능하다고 전망한다 [06:41]
• 채팅의 속도와 사용 편의성, Work의 기능을 함께 원하는 피드백에 따라 두 경험을 통합하고 복잡성을 줄일 계획이다. dots의 기능도 결국 ChatGPT에 넣으려 하며, 모델 선택 없이 사용할 수 있는 방식을 긍정적으로 평가한다 [07:39]

5. 실제 사용자와 함께 만들어야 예상하지 못한 효용을 발견한다

• 사용자와 만나면 예상하지 못했던 활용 방식과 삶에 미치는 영향을 발견한다. 이런 경험은 사람에게 유용한 제품을 만드는 데 필수적이며, 커뮤니티 없이 개발하기는 어렵다고 본다 [09:22]
• 완성된 비전을 일방적으로 전달하기보다 출시 후 사람들이 무엇을 하는지 관찰하며 함께 제품을 발전시키는 접근이다. 온라인 커뮤니티도 이러한 교류의 일부다 [09:53]

6. 하나의 개인 에이전트에서 역할별 가상 팀으로 확장한다

• 당시 공개한 것은 앱을 연결하고 사용법을 익힐 수 있는 기본 dot 하나다. 여러 dot으로 구성된 팀 기능은 아직 공개하지 않았으며, 본인은 Twitter 담당 dot을 별도로 사용하고 있다 [10:29]
• 기본 dot이 사용자의 선호를 깊이 학습하도록 먼저 시작한 뒤, 실제 사용을 보며 시스템을 조정할 계획이다. 이후 필요한 만큼 에이전트를 추가하고 각각에 역할을 부여하는 가상 팀을 지원하려 한다 [10:55]

7. 개방형 생태계는 배포·수익 배분·지속 사용을 함께 연결한다

• 상대적으로 주목받지 못한 핵심 변화로 생태계 개방을 꼽는다. ‘ChatGPT로 로그인’은 16개 파트너와 함께 지원하며, 초기의 비공식적인 협력에서 정식 지원 체계로 발전했다 [11:51]
• 플러그인 확장과 발견 기능을 열어 외부 개발자가 약 12억 사용자 규모의 배포 기회를 활용하도록 하려 한다. 플러그인이나 외부 제품에서 구독자의 사용량이 소비되면 파트너와 수익을 나누는 구조도 계획한다 [12:34]

8. 장기 실행과 기억 연구를 결합하면서 안전성을 강화했다

• 약 1년 전 Codex Cloud를 출시했지만, 오래 지속되는 장기 과제 연구는 2년 넘게 진행했다. 일관된 기억 시스템도 대략 같은 기간 연구했으며 상당 부분을 ChatGPT에 적용했다 [14:57]
• 사용자의 과거 대화에서 관련 정보를 기억하는 기능, 실행 체계, 24시간 생산적으로 작동하는 능력을 결합한 결과가 dots다. 제품을 완성하는 데에도 여러 달의 작업이 필요했다 [15:26]

9. 인간의 취향과 협업을 중심에 두고 에이전트 사용의 피로를 줄인다

• AI는 인간의 의지와 취향을 확장하는 도구로 설계해야 한다는 입장이다. 코드를 직접 쓰는 사람이 줄어들 수 있어도 만드는 사람은 더 많아질 수 있으며, 다른 인간의 창작을 보고 배우려는 관심은 오래 남을 것으로 본다 [16:37]
• 엔지니어의 잦은 맥락 전환과 에이전트만 상대하면서 생기는 고립감이 문제로 제기된다. 설정 피로와 혼자 에이전트에게 계속 위임하는 경험을 줄이는 일을 팀이 지속적으로 고민하고 있다 [17:26]

10. 더 많이 처리하는 능력을 주의력과 휴식의 개선으로 연결해야 한다

• 여러 에이전트를 돌릴 수 있다는 이유로 더 많은 결과를 요구받는 압박이 생긴다. AI의 가능성은 경쟁적으로 주의를 끄는 일을 줄이고, 사용자가 원하는 곳에 집중하도록 돕는 데에도 있다고 본다 [18:55]
• 일주일 동안 완전히 연결을 끊고 쉬면 더 창의적으로 생각하게 된다는 경험을 근거로, 회의를 줄이고 더 잘 쉬는 일상이 생산성을 높일 수 있다고 제안한다. 이를 실제 업무에 구현하는 방법은 업계가 풀어야 할 과제로 남아 있다 [19:36]

11. 상황을 연결한 사전 알림과 실제 시스템 접근에는 별도 통제가 필요하다

• dot은 ChatGPT 운영 시스템 장애와 곧 있을 DevDay 시연의 관련성을 파악해, 시연 5분 전에 장애를 알리고 수정을 제안했다. Tibo는 직접 고칠 수준은 아직 아니라고 판단했고, 엔지니어링 팀과 연락해 문제를 살폈다 [20:31]
• 해당 dot은 일부 운영 시스템에 보호 장치가 적용된 상태로 접근한다. 전문 dot에는 추가 보호 장치와 모니터링을 적용하고 별도 하드웨어에서 운영하며, 일부는 Mac mini에서 실행한다 [21:47]

12. 채용에서는 타이핑보다 취향·사용자 이해·제품 판단이 중요해진다

• 빠르게 타이핑하는 능력의 중요성은 낮아지고, 좋은 취향과 사용자 관점, 제품을 사용할 사람들과 연결되는 능력의 중요성은 높아진다 [23:44]
• OpenAI에는 YC 창업자 출신이 120명 넘게 있다고 언급한다. 의미 있는 것을 만들려는 열정과 좋은 결과물을 알아보는 판단력이 어느 때보다 중요하다는 견해다 [23:57]

13. 초고속 응답과 음성 제어가 새로운 창작 몰입을 만든다

• 한동안 그리웠던 엔지니어링의 몰입감이 빠른 응답 속도와 함께 돌아왔다. 이 경험을 널리 제공하고 싶지만, 10억 명이 넘는 사용자에게 보편적으로 제공하기까지는 시간이 걸릴 것으로 본다 [25:01]
• 초고속 기능의 비용이 Astra와 대략 비슷한 수준이라고 설명하며 내부에서도 발전 속도에 놀라고 있다고 드러낸다. 빠른 실행과 음성 제어를 결합하면 창의적인 사고와 지속적인 몰입이 가능해지며, 과거와 다른 형태의 작업 흐름을 얻는다 [25:19]

14. 신입 경력 조언은 함께 일하는 인물의 사례로 시작된다

• 초기 경력자에게 필요한 기술과 진로에 관한 질문에, Tibo는 함께 일하는 Ahmed Ibrahim을 ‘다음 Tibo’로 꼽고 신입 졸업자로 채용됐다고 언급한다. 제공된 구간은 이 사례를 설명하는 도중 끝나므로 구체적인 조언까지 확인할 수는 없다 [26:13]

15. 협업과 빠른 학습이 뒷받침하는 상향식 개발

• Ahmed는 OpenAI의 전체 컴퓨팅 인프라와 응용 부문을 책임진다. 친절하고 협력적이며 자신보다 중요한 문제 해결을 우선하는 태도, 최신 기술을 활용한 빠른 학습이 성장의 강점으로 꼽힌다. 수개월에서 약 1년 사이의 성장으로 어려운 출시도 맡길 수 있는 신뢰를 얻었다. [27:11]
• Decisions API는 Luna 모델에 제약을 적용한 샘플링을 결합해 Responses API와 다른 형태로 제공하려는 아이디어에서 빠르게 만들어졌다. 주말에 네 명이 실험하던 프로젝트가 내부 공유와 참여 확대로 발전했고, 시각 입력 지원 등 가능성이 더해졌다. [28:24]

16. 자율성에는 빠른 복구와 실수에 대한 책임이 따른다

• 구성원이 좋은 판단을 내릴 것이라는 신뢰를 바탕으로 자율성을 부여하며, 문제가 생기면 빠르게 고치거나 실수에서 배워야 한다. 여러 단계의 승인을 거치지 않고 필요할 때 리셋할 수 있는 권한은 커뮤니티와 가까이 소통하는 데도 도움이 된다. [29:57]
• Codex 초기에는 본인이 일으킨 장애가 몇 차례 있었고, OpenAI 입사 사흘째에도 프로덕션 서비스를 중단시켰다. 그 뒤에도 계속 근무하면서 실수에서 교훈을 얻었다. [30:33]

17. 에이전트 중심 인터넷은 제품의 규모와 경제성을 바꾼다

• 인터넷에서 이루어지는 행동의 대부분을 에이전트가 수행하고, 모델은 매우 빠른 속도로 저렴하고 빨라지며, 여러 모달리티가 자연스럽게 통합될 것으로 전망한다. 약 1년 뒤 기술이 지금보다 대략 10배 좋아진다고 가정하면 제품을 만드는 방식도 달라져야 한다는 주장이다. [31:33]
• Notion은 MCP를 구축한 뒤 에이전트가 실제 작업에 이를 사용하면서 대량의 트래픽을 경험했다. 이는 시스템 부담과 경제성 문제로 계속된다. 에이전트용 인터페이스 제공을 미룰 수는 있지만, 에이전트가 사용의 대부분을 차지할 미래에 대비해 처리 규모와 비용 구조를 설계해야 한다고 본다. [32:29]

18. 예상보다 빠른 모델 발전이 사용 습관과 채용 관점을 바꿨다

• 현재 Astra와 같은 모델의 역량에 도달하려면 1~2년이 더 걸릴 것으로 예상했지만, 실제 발전 속도가 빨라 기존 전망을 수정했다. [33:00]
• 음성에 이처럼 많이 의존할 줄은 예상하지 못했다. 받아쓰기와 에이전트에게 직접 말하는 방식을 자주 사용하면서, 음성 기반 작업이 얼마나 편하게 느껴지는지에 대한 생각도 바뀌었다. [33:21]

19. 역량 확대에 앞서 안전 투자와 에이전트 감시를 강화한다

• 최전선 모델의 발전 속도를 관리한다는 것은 정렬·안전성·보안·가드레일에 미리 충분히 투자하는 일이라고 본다. 작업을 수행하는 주 에이전트와 별도로 이를 감시하는 시스템에도 컴퓨팅 자원을 늘려, 위험한 행동이나 프롬프트 주입 징후가 나타나면 개입하도록 한다. [34:57]
• Astra를 넘어서는 다음 단계의 역량은 아직 공개하지 않았으며, 비슷한 지능 수준을 훨씬 효율적으로 제공하는 모델을 출시했다. 안전 투자를 계속 확대할 계획이고, 준비된 모델을 출시하지 않은 결정도 자랑스럽게 여긴다. [35:34]

20. 복잡한 모델 선택을 없애고 앱을 단순하게 만든다

• 모델은 앱의 존재를 거의 의식하지 않아도 될 수준에 가까워졌지만 아직 충분하지 않다. 지향점은 사용 경험을 극도로 단순하게 만드는 것이다. [36:34]
• 모델 선택기, 추론 강도, 멀티에이전트나 ultra 같은 옵션은 본인에게도 피로감을 준다. 각 설정의 의미를 이해하고 고르는 부담을 가능한 한 빨리 없애고 싶어 한다. [36:53]

🧾 결론

• 인터뷰가 제시하는 전환의 중심은 사용자가 실행 절차를 관리하는 부담을 줄이고, 원하는 결과를 전달하면 에이전트가 맥락을 이어서 수행하도록 만드는 데 있다.
• 에이전트의 수를 늘리는 것 자체가 목표는 아니다. 작업의 난도와 모델의 속도·역량에 따라 단일 에이전트와 역할별 팀을 조정하는 접근이다.
• 제품의 완성도는 모델 성능만으로 결정되지 않는다. 자연스러운 인터페이스, 실제 사용자와의 학습, 안전한 시스템 접근이 함께 필요하다.
• 생산성의 성과는 처리량뿐 아니라 사람끼리 협업할 여유, 집중할 시간, 줄일 수 있는 업무에서도 평가해야 한다.

📈 투자·시사 포인트

• 에이전트 트래픽의 경제성을 살펴볼 필요가 있다. Notion의 MCP 활용 사례는 에이전트 사용 확대가 시스템 부담으로 이어질 수 있음을 보여준다. 관련 제품의 기회는 사용 증가와 함께 처리 비용을 감당할 구조에 달려 있다.
• 플러그인 생태계의 가치는 배포 이후의 지속 사용에서 갈릴 수 있다. 인터뷰에서 제시한 대규모 배포 기회와 수익 배분 구상은 매력적이지만, 추천을 유지하려면 작업 성공과 품질을 입증해야 한다.
• 음성·멀티모달·공동 작업 경험에 제품 기회가 있다. Sottiaux는 여러 모달리티를 활용해 사람에게 만족스러운 경험을 제공하는 제품에 투자가 부족하다고 평가한다.
• 안전성과 모니터링은 에이전트 확산에 필요한 투자 요소다. 장기 실행과 실제 시스템 접근이 늘수록 감시 시스템의 컴퓨팅 자원과 보호 장치를 함께 고려해야 한다.
• 인재 평가와 업무 설계도 바뀔 수 있다. 사용자 이해, 제품 판단, 빠른 학습과 협업을 강조하는 발언은 채용과 교육의 평가 기준을 재검토할 근거다. 이 인터뷰만으로 특정 기업의 실적이나 투자 수익을 판단할 수는 없다.

⚠️ 불확실하거나 확인이 필요한 부분

• 약 1년 뒤 기술이 대략 10배 좋아진다는 수치는 제품 설계를 설명하기 위한 가정이다. 개선을 측정할 지표와 달성 여부는 제공된 자료에서 확인되지 않는다.
• dots 팀 기능, ChatGPT 통합, 수익 배분, 여러 기기 제어는 당시의 계획이나 전망을 포함한다. 현재 제공 여부, 출시 일정, 이용 조건은 별도로 확인해야 한다.
• 약 12억 사용자, 로그인 파트너 16개, 초고속 기능의 비용 비교는 인터뷰 발언이다. 산정 기준이나 구체적인 비용 자료는 제시되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 도입하려는 기능을 당시 공개된 기능, 향후 계획, 전망으로 구분하고 현재 이용 조건을 확인한다.
• 반복 업무 하나를 골라 원하는 결과와 선호, 완료 기준을 명시하고 에이전트의 기억·피드백 반영·작업 성공 여부를 관찰한다.
• 단일 에이전트로 시작한 뒤 작업량과 응답 속도를 보고 역할별 분리를 검토한다. 에이전트 수와 함께 설정 부담과 맥락 전환도 기록한다.
• 에이전트용 인터페이스를 제공하는 제품이라면 예상 호출량, 처리 비용, 작업 성공률을 함께 점검한다.

❓ 열린 질문

• 목표와 선호를 기억하는 상시 에이전트는 잘못 학습한 맥락을 어떻게 수정하고, 언제 사용자에게 판단을 돌려줘야 할까?
• 단일 에이전트와 역할별 가상 팀 사이의 적정 규모를 작업 성공률·속도·비용으로 어떻게 판단할 수 있을까?
• 플러그인 수익 배분과 추천 기준은 외부 개발자에게 어떤 조건과 예측 가능성을 제공할까?