OpenAI DevDay: 초인적 컴퓨터 사용과 Decisions API, AI 클라우드

URL: https://www.youtube.com/watch?v=z9OkBD2-MDU
날짜: 2026-10-01
채널: Latent Space
원문 제목: Inside OpenAI DevDay: Superhuman Computer Use, Decisions API, and the AI Cloud — Ari & Nikunj
영상 길이: 40분 24초
영상 ID: z9OkBD2-MDU
출연: Ari(Computer Use Agents 제품·엔지니어링 책임자), Nikunj(OpenAI API 제품 책임자)
자막: 영어 자동 자막을 바탕으로 한국어로 재구성함

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

==컴퓨터 사용(computer use)은 이제 평균적인 사람보다 빠르게 작업을 끝내는 단계에 들어섰고, 다음 목표는 숙련된 사용자보다 빠른 ‘초인적(superhuman)’ 소프트웨어 조작이다.== OpenAI DevDay에서 발표된 Dots, 새 컴퓨터 사용 모델, Agents API, Decisions API, 초고속 추론, 캐싱과 컨텍스트 압축은 모두 이 목표를 제품과 플랫폼 차원에서 구현하려는 서로 다른 층이다.

• 컴퓨터 사용 에이전트는 스크린샷만 보고 한 번에 한 동작을 흉내 내는 도구에서, 접근성 트리·DOM·Playwright·코드 실행을 조합해 여러 동작을 한꺼번에 수행하고 실패를 디버깅하는 시스템으로 발전했다.
• Decisions API는 같은 계열의 모델 가중치를 바탕으로 추론을 끄고 구조화된 출력을 강제하며 여러 질문을 병렬 처리해, 장기 추론보다 속도와 분류에 최적화한 별도 경로다.
• Agents API와 Responses API는 비동기 툴 호출, 중간 조종, WebSocket, 캐시 프리워밍, 자동·수동 압축을 제공해 개발자가 ‘AI 클라우드’ 위에 장기 실행 에이전트를 만들 수 있게 하는 기반을 지향한다.

이 대화에서 Ari는 실제 컴퓨터를 움직이는 모델과 하네스의 발전, Dots의 개인 Linux 컴퓨터, 안전과 신뢰의 문제를 설명한다. 이어 Nikunj은 API가 노출하는 비동기 실행·초고속 추론·결정 모델·캐싱·압축을 설명하며, 낮은 수준의 원시 기능과 메모리·저장소 같은 높은 수준의 추상화를 어디까지 API에 넣을지가 아직 열린 설계 문제라고 말한다.

1. DevDay 발표의 전체 그림

DevDay의 발표들은 하나의 기능 출시라기보다 컴퓨터 사용을 개인 제품, 개발자 API, 추론 인프라의 각 층으로 확장하는 묶음으로 제시된다.

1.1. 발표된 제품과 모델

1. Dots라는 개인 비서 제품

   1. Dots는 각 인스턴스가 자체 Linux 가상 컴퓨터를 클라우드에 가진다.
   2. 기존 제품처럼 브라우저만 빌리거나 사용자의 개인 컴퓨터에 접속하는 것이 아니라, 데스크톱 애플리케이션과 웹 브라우저를 모두 실행할 수 있는 완전한 환경이다.

2. 컴퓨터 사용에 유리한 새 모델

   1. 대화에서 모델명은 자막상 “GPT 6.1 Soul”로 언급되며, Ari는 기존 Astra 대비 전체 비용이 5분의 1, 컴퓨터 사용만 보면 7분의 1 수준이라고 설명한다.
   2. 속도와 비용이 좋아서 컴퓨터 사용처럼 툴 호출이 많고 짧은 지연이 중요한 작업에 특히 적합하다는 평가다.

3. Agents API에 컴퓨터 사용 내장

   1. 개발자는 Codex와 ChatGPT 제품에서 사용하는 것과 같은 컴퓨터 사용 구현을 API 위에서 활용할 수 있다.
   2. 자신만의 하네스를 만들 수도 있지만, OpenAI 모델이 해당 하네스에서 학습되므로 기본 하네스를 사용하면 속도·비용·정확도에서 유리할 가능성이 있다.

4. 기존 컴퓨터 사용 기능의 제품화

   1. Appshot은 사용자가 작업 중인 앱의 맥락을 Codex나 ChatGPT로 빠르게 가져온다.
   2. Mac 네이티브 컴퓨터 사용은 앱의 스크린샷을 자동으로 수집하며, 사용자가 다른 일을 하는 동안 에이전트가 애플리케이션을 조작할 수 있다.

1.2. Decisions API가 맡는 자리

1. 빠른 판단을 위한 별도 경로

   1. Decisions API는 컴퓨터 사용 모델과 완전히 같은 모델을 단순히 다른 이름으로 제공하는 것이 아니다.
   2. 더 작은 모델이고 reasoning이 없으며, 추론을 병렬로 수행한다. 그 결과 매우 빠르지만 긴 시간 범위의 복잡하고 정교한 작업에는 덜 적합하다.

2. 컴퓨터 사용과의 관계

   1. Astra가 JavaScript를 작성해 컴퓨터를 여러 동작으로 조작하는 방식과 달리, Decisions API의 모델인 Luna는 한 번에 한 동작을 선택하는 식으로 사용될 수 있다.
   2. 따라서 지능 수준은 같지 않지만, 충분히 단순한 컴퓨터 사용 작업에서는 훨씬 빠른 선택기가 될 수 있다.

3. 아직 결합 방식은 연구 과제

   1. 장기 작업을 수행하는 모델과 초고속 결정을 내리는 모델을 언제 어떻게 함께 사용할지는 아직 열린 연구 영역이다.
   2. Nikunj은 Decisions API가 이제 막 시작된 반복적 출시이며, 사용자 피드백과 모델 개선을 통해 발전시킬 것이라고 말한다.

2. Dots와 ‘무엇이든 위임할 수 있는’ 컴퓨터

Dots의 핵심은 특정 API를 호출하는 비서가 아니라, 사람이 화면에서 할 수 있는 모든 일을 같은 소프트웨어 표면 위에서 위임받는 지속형 에이전트라는 점이다.

2.1. 개인 Linux 컴퓨터가 만드는 지속성

1. 브라우저를 넘어선 환경

   1. 각 Dot은 클라우드의 자기 Linux 가상 컴퓨터에 접근한다.
   2. 이 컴퓨터에서는 완전한 데스크톱 앱을 실행할 수 있고 웹 브라우저도 사용할 수 있다.

2. 범용성이 곧 제품의 가치

   1. 세상의 소프트웨어 대부분은 사람을 위해 만들어졌기 때문에, 에이전트가 같은 소프트웨어를 조작하면 별도 API가 없는 서비스도 사용할 수 있다.
   2. 항공권 예약, 쇼핑, 고객센터 문의, 게임처럼 사용자가 컴퓨터에서 하는 일을 그대로 요청할 수 있다.

3. 사용자별 가치 발견 방식

   1. 어떤 작업이 유용한지는 최종 사용자의 삶에서 무엇이 시간을 잡아먹는지에 따라 달라진다.
   2. Ari는 “내가 컴퓨터 앞에서 시간을 쓰는 일 중 무엇을 에이전트에 위임할 수 있는가”라는 질문으로 시작하라고 권한다.

2.2. 실제 사례와 창작자 사례

1. 맞춤형 식사 주문

   1. Ari는 건강한 식사를 위해 식사 준비 서비스를 구독했는데, 닭고기와 쌀의 그램 수를 세밀하게 지정할 수 있는 대신 주문 화면이 매우 복잡했다고 설명한다.
   2. 직접 주문하면 2시간이 걸렸지만 컴퓨터 사용 에이전트는 약 15분 만에 처리했다.
   3. 그는 GPT 6.1 Soul이 자신보다 약 8배 빠르게 작업해 두 시간을 절약했다고 말한다.

2. YouTube 운영 자동화

   1. 진행자는 자신의 가장 큰 사용 사례로 YouTube를 꼽는다.
   2. YouTube는 A/B 테스트와 커뮤니티 게시물처럼 API로 노출하지 않는 기능이 많아서, VM 안에서 실제 사이트를 조작해야 한다.
   3. Ari는 OpenAI의 개발자 경험 팀도 YouTube에 컴퓨터 사용을 많이 활용한다고 확인한다.

3. 작업의 기본 단위 변화

   1. 이전에는 “에이전트가 할 수 있는 API 작업”을 찾았다면, 이제는 사용자가 직접 할 수 있는 컴퓨터 작업 전체를 위임 후보로 볼 수 있다.
   2. 이 범용성은 특정 서비스가 API를 제공하는지 여부와 무관하게 자동화를 가능하게 한다.

3. 컴퓨터 사용이 지난 1년 동안 달라진 방식

Ari는 Apple의 Shortcuts, 자신이 만든 Sky, OpenAI에서의 컴퓨터 자동화 작업을 하나의 흐름으로 설명한다. 목표는 사람이 컴퓨터를 세밀하게 조작하는 시간을 줄이고 더 중요한 일에 집중하게 하는 것이다.

3.1. 시작은 같지만 실패 이후가 달라졌다

1. 과거의 모델

   1. 예전 모델은 작업을 안정적으로 시작할 수는 있었다.
   2. 하지만 중간에 문제가 생기면 멈추거나 회복하지 못했다.

2. 현재의 모델

   1. 최근 1년 동안 모델의 컴퓨터 사용 능력이 크게 향상되었다.
   2. 지금은 무엇이 작동하고 무엇이 작동하지 않았는지 스스로 살피고, 디버깅하고, 다시 시도하는 능력이 좋아졌다.

3. Ari의 경력에서 이어지는 동기

   1. Apple에서는 자동화 제품을 만들었고, 이후 Sky에서 컴퓨터 사용을 연구했으며, 그 팀은 OpenAI에 합류했다.
   2. Apple 안에서 직접 만들기 전에는 Apple을 우회해 자동화를 해킹해야 했다는 진행자의 농담이 나온다.

3.2. 모델만이 아니라 컴퓨터 사용 스택 전체의 발전

1. 코드 실행으로 여러 동작을 묶기

   1. Codex에서 툴 호출을 펼쳐 보면 에이전트가 매번 마우스 동작 하나만 수행하는 것이 아니다.
   2. JavaScript를 작성해 컴퓨터가 여러 동작을 한 번에 실행하게 하므로 지연과 실패 가능성을 줄인다.

2. 여러 표현 방식을 작업에 맞게 조합하기

   1. 모델은 스크린샷만 사용할 수도 있고 접근성 트리, DOM, Playwright를 사용할 수도 있다.
   2. 작업에 따라 시각 정보, 구조화된 UI 정보, 브라우저 자동화 명령 중 더 적합한 경로를 선택한다.

3. 7배 속도 향상과 측정

   1. DevDay 키노트에서는 컴퓨터 사용 속도가 7배 향상되었다고 소개된다.
   2. 내부 평가는 하네스의 여러 설정과 순열, 실제 제품에 필요한 안전 검사를 조합해 측정한다.
   3. 개선은 모델이나 포스트 트레이닝 한 요소만의 결과가 아니라 하네스·추론·표현 방식의 조합으로 나타난다.

4. 작은 불편의 누적도 중요하다

   1. 큰 돌파구 외에도 한 번의 지연, 불필요한 스크롤, 부정확한 표현 등 작은 ‘paper cut’을 찾아 고치는 일이 실제 속도를 만든다.
   2. Ari는 생산 환경에는 작업에 맞춘 안전 검사가 추가되므로, 단일 벤치마크 숫자만으로 제품 성능을 판단하기 어렵다고 덧붙인다.

4. Appshot과 접근성 표현의 의미

Appshot은 겉으로는 스크린샷처럼 보이지만, 실제로는 언어 모델이 앱을 조작하기 위한 풍부한 구조적 맥락을 함께 전달하는 기능이다.

4.1. Appshot의 사용법과 내부 표현

1. 빠른 캡처

   1. Mac에서 Command 키를 두 번 누르면 현재 작업 중인 앱의 맥락을 가져올 수 있다.
   2. Codex나 ChatGPT의 첨부 파일처럼 보이지만 단순한 픽셀 이미지가 아니다.

2. 원시 접근성 표현 확인

   1. 첨부 파일을 클릭한 뒤 오른쪽 위의 작은 버튼을 누르면 원시 텍스트와 접근성 표현을 확인할 수 있다.
   2. 팀은 이 데이터를 많이 덤프하면서도 토큰 효율적으로 만드는 작업에 상당한 노력을 들였다.

3. 스크린샷보다 많은 맥락

   1. 웹 페이지의 스크린샷에는 링크가 어디로 향하는지 나타나지 않을 수 있다.
   2. 캘린더의 스크린샷에서는 긴 이벤트 제목이 잘리지만, Appshot은 링크 목적지와 전체 이벤트 정보 같은 맥락을 전달한다.

4.2. 사람을 위한 접근성이 에이전트에도 유용한 이유

1. 공통 기반

   1. 접근성 기술은 스크린 리더 사용자가 컴퓨터를 조작할 수 있도록 만들어졌다.
   2. 같은 구조화 표현이 언어 모델이 컴퓨터를 이해하고 조작할 때도 유용하다.

2. 구조와 시각의 결합

   1. 모델은 화면을 보는 동시에 요소의 이름·역할·상태를 얻을 수 있다.
   2. 그 결과 화면을 계속 스크롤하며 다음 스크린샷을 찍는 대신 전체 페이지나 앱을 한 번에 파악하고 여러 단계를 코드로 처리할 수 있다.

5. 다음 전선: 전문가보다 빠른 초인적 컴퓨터 사용

현재의 컴퓨터 사용은 평균적인 사람보다 많은 작업에서 빠르지만, Ari가 말하는 다음 단계는 전문가 수준의 컴퓨터 사용자보다도 빠른 시스템이다.

5.1. 더 빠른 에이전트가 바꾸는 제품 경험

1. 성능의 목표

   1. 에이전트가 일반 사용자보다 빠른 것에서 멈추지 않고, 소프트웨어를 다루는 숙련자보다 빠르게 동작해야 한다.
   2. 이는 단순한 벤치마크 개선이 아니라 실시간성이 강한 제품을 만들 수 있는 기준 변화다.

2. 활성화 에너지의 하락

   1. 에이전트를 한 번 실행하는 데 드는 마찰이 줄면, 사람들은 지금까지 수동으로 해온 일을 기본적으로 에이전트에게 맡기기 시작한다.
   2. 자동화를 특별한 프로젝트로 시작하지 않고 일상적인 기본값으로 만들 수 있으며, 그만큼 시간을 절약한다.

3. 병목의 이동

   1. 모델이 빨라질수록 모델 자체보다 추론 지연, 하네스, 표현 방식, 실제 소프트웨어의 반응 시간이 병목이 된다.
   2. 예를 들어 DoorDash 같은 사이트를 자동화할 때 벤치마크 시간의 상당 부분은 모델이 아니라 사이트가 로드되기를 기다리는 시간이다.

5.2. 이벤트 기반 실행과 현실의 대기 시간

1. 고정 대기의 한계

   1. 단순히 일정 시간 wait를 넣으면 사이트가 빨리 로드됐을 때 낭비되고, 늦게 로드됐을 때는 다음 동작이 실패할 수 있다.
   2. 로드가 끝난 순간과 다음 모델 호출 사이의 지연을 최소화하는 것이 중요하다.

2. 이벤트 기반 접근

   1. 브라우저와 JavaScript에는 페이지 로드나 탐색 완료 이벤트가 있으므로, 가능한 작업은 이벤트 기반으로 이어야 한다.
   2. 하지만 모든 작업이 이벤트로 표현되는 것은 아니다.

3. 예측하기 어려운 상호작용

   1. 고객센터 채팅 답변은 30초가 걸릴 수도 있고 3분이 걸릴 수도 있다.
   2. 에이전트는 그동안 기다리기만 하지 않고 서브에이전트로 더 나은 해결책을 조사할 수 있다.
   3. 진행자는 상대방이 봇인지 알 수 없을 정도로 완전한 문장과 정확한 대문자·참조 번호를 사용한다고 농담하며, 봇과 봇이 대화하는 상황도 언급한다.

6. 안전, 신뢰, 그리고 개발자에게 주는 조언

컴퓨터 사용이 실제 비용과 권한을 가진 작업을 수행하기 시작한 만큼, 성능만큼 신뢰 형성이 중요하다는 것이 Ari의 핵심 경고다.

6.1. 이미 가능한 고위험 작업

1. 개인의 과감한 사용 사례

   1. 진행자는 몇 년 전만 해도 웹과 기기에 모델을 연결하는 것을 두려워했지만, 이제는 Codex로 DNS를 설정하고 청구서를 결제한다고 말한다.
   2. 그는 수만 달러 규모의 작업도 컴퓨터 사용에 넘기며 “최악의 일이 무엇일까”라는 식으로 밀어붙이고 있다고 농담한다.

2. 이 사례가 의미하는 것

   1. 컴퓨터 사용은 데모용 클릭 자동화를 넘어 외부 시스템의 상태를 실제로 변경할 수 있다.
   2. 따라서 모델의 평균 성공률만큼이나 잘못된 결제·설정·권한 변경을 막는 경계가 중요하다.

6.2. Agents API를 사용할 때의 원칙

1. 기본 구현을 활용할 이유

   1. 자체 하네스를 만들면 제어권은 커지지만, 모델이 학습한 분포와 달라질 수 있어 정확도·속도·비용에서 불리할 수 있다.
   2. OpenAI의 배포 하네스는 컴퓨터 사용 모델과 함께 조정되어 있으므로 먼저 기본 경로를 시험하는 것이 합리적이다.

2. 신뢰를 쌓는 안전장치

   1. 결제처럼 결과가 큰 행동은 사용자의 명시적 동의를 먼저 받는다.
   2. 애플리케이션이 실제 작업에 필요한 웹사이트와 프로그램만 접근하도록 제한한다.
   3. 신뢰할 수 있는 결과를 만들기 위해 안정성 검사를 제품 흐름에 포함한다.

3. 개발자의 역할

   1. 새 Agents API를 사용해 다양한 애플리케이션을 만들되, 실패 유형과 사용자가 개입해야 하는 지점을 OpenAI에 피드백해야 한다.
   2. 신뢰는 한 번의 모델 출시로 얻는 것이 아니라 반복적인 안정성 개선과 적절한 동의 흐름으로 쌓인다.

7. 컴퓨터 사용이 소프트웨어 개발을 완결하는 방식

Ari가 가장 좋아하는 사용 사례는 에이전트가 자신이 만든 소프트웨어를 직접 테스트하는 것이다. 이는 코드를 생성하는 데서 끝나지 않고 개발·검증 사이클 전체를 자동화한다.

7.1. 에이전트를 에이전트의 QA로 사용하기

1. 기존 흐름

   1. Codex가 코드를 작성하면 사람은 결과물을 받아 테스트해야 했다.
   2. 이때 사람은 에이전트가 만든 소프트웨어의 QA 담당자가 된다.

2. 새 흐름

   1. 컴퓨터 사용을 연결하면 에이전트가 소프트웨어를 만들고 실제 화면에서 테스트할 수 있다.
   2. 사람이 확인하기 전에 이미 동작하는 상태로 가져오므로 개발 생명주기가 이어진다.

3. 중첩된 자동화

   1. Ari는 컴퓨터 사용 자체를 개발할 때, 컴퓨터 사용 에이전트가 다른 컴퓨터 사용 에이전트를 조작하게 된다고 설명한다.
   2. 이는 한 에이전트가 도구를 호출하는 수준을 넘어, 에이전트가 에이전트의 실행 환경을 검증하는 재귀적 구조다.

7.2. 시각적 플레이 테스트와 앱 복제

1. 코드만으로 놓치는 문제

   1. 진행자는 자신이 만든 시각적 플레이 테스트 스킬이 코드만 봐서는 발견하기 어려운 디자인 문제를 찾아낸다고 말한다.
   2. 화면의 흐름, 버튼 배치, 실제 사용감처럼 실행 중에만 드러나는 결함을 잡을 수 있다.

2. SaaS 복제

   1. 마음에 들지 않는 SaaS를 없애고 싶다면 컴퓨터 사용으로 화면을 하나씩 관찰하고 스크린샷과 구조를 기록할 수 있다.
   2. 그 결과를 Codex에 넘겨 화면 단위로 기능과 인터페이스를 복제하는 작업도 가능하다.

8. API 플랫폼: 비동기 실행과 초고속 추론

Nikunj은 API 팀의 관점에서 GPT-6 계열의 핵심 변화가 긴 툴 호출을 기다리는 동안 모델을 멈추지 않게 하는 것이라고 설명한다. 자막에는 일부 모델명이 혼동되어 표기되지만, 대화의 API 개념은 일관되게 비동기 실행·중간 조종·WebSocket으로 연결된다.

8.1. Async tool calling과 mid-turn steering

1. 비동기 함수 호출

   1. 툴 호출이 오래 걸릴 때 모델의 실행을 일시 정지할 필요가 없다.
   2. 모델은 툴 호출을 시작한 뒤 계속 추론하고, 나중에 툴의 결과를 확인할 수 있다.

2. 중간 턴 조종

   1. 모델이 추론 중일 때도 메시지를 주입해 방향을 바꿀 수 있다.
   2. 사용자는 툴 호출이 끝난 시점에 새로운 지시를 넣거나 실행 중인 계획을 조정할 수 있다.

3. 모델 학습과 API 노출의 시점

   1. 앱에서는 중간 조종을 먼저 지원할 수 있지만, API에는 모델이 해당 상호작용을 충분히 학습하고 하네스에서 안정적으로 작동할 때 노출한다.
   2. 이 기능은 단순한 프로토콜이 아니라 모델 정렬과 실행 능력의 문제이기도 하다.

8.2. WebSocket과 UltraFast

1. 양방향 통신

   1. WebSocket은 모델과 애플리케이션 사이에 지속적인 양방향 연결을 제공한다.
   2. 비동기 툴 호출, 비동기 추론, 중간 메시지 주입을 하나의 상호작용 흐름으로 묶는다.

2. UltraFast의 의미

   1. UltraFast는 프런티어 수준의 지능을 가능한 한 빠른 속도로 제공하려는 경로다.
   2. 추론 팀은 지속적으로 에이전트를 실행해 성능을 조이고, 한동안은 비용 효율화에 집중해 Luna 가격을 약 80% 낮췄으며 이후 속도 최적화로 초점을 옮겼다.

3. 인프라와의 관계

   1. WebSocket은 처음 GPT-5.3 Codex Spark에 적용되었고 툴 왕복 오버헤드를 줄이는 데 특히 유용했다.
   2. Spark가 Cerebras와 명시적으로 연결되어 있다는 점은 언급되지만, UltraFast가 Cerebras와 관련 있는지는 확인하지 않는다.

9. Decisions API의 구현과 사용처

Decisions API는 단순히 “낮은 온도와 구조화 출력”을 붙인 일반 모델이 아니다. 같은 Luna 가중치 위에 제약, 추론 스택 최적화, 병렬 처리를 얹은 초기 구현이다.

9.1. 속도를 만드는 구성

1. 새 모델을 처음부터 학습한 것이 아님

   1. 첫 버전은 새로운 모델을 별도로 학습하지 않고 기존 Luna 가중치 위에서 구축한다.
   2. 이후 반복 배포에서 필요한 모델 개선을 추가할 수 있도록 열어둔 접근이다.

2. 구조화 출력과 제약

   1. 가능한 출력 형식을 구조화해 모델이 자유로운 장문 답변 대신 결정 가능한 형식으로 답하게 한다.
   2. 이 제약은 분류와 라우팅처럼 결과 공간이 제한된 작업에서 특히 효과적이다.

3. 병렬 배치 추론

   1. 여러 질문을 한 번에 받아 병렬로 실행한다.
   2. 결과적으로 단일 질문을 순차적으로 처리하는 일반적인 긴 추론보다 낮은 지연으로 많은 판단을 반환한다.

4. 비전의 장점

   1. Luna의 가중치를 활용하기 때문에 비전 능력은 별도 체계로 추가하지 않고 함께 얻을 수 있다.
   2. 다만 Decision 모델이 컴퓨터 사용의 장기 계획 능력까지 같은 수준으로 제공한다는 뜻은 아니다.

9.2. 경쟁 제품, 캘리브레이션, 내부 사용 사례

1. 시장 자극

   1. 진행자는 업계의 ‘Jev’ 계열 결정 모델이 시장 전체를 자극했고, OpenAI 내부 팀도 약 4주 만에 빠른 분류기를 만들기 시작했다고 설명한다.
   2. OpenAI의 강한 해커 문화 덕분에 인퍼런스 팀과 인프라 팀의 구성원이 프로토타입을 빠르게 만들었고, 현재는 목표 지연 시간까지 계속 줄이는 중이다.

2. API 모양과 실제 난제의 구분

   1. 구조화 출력을 제공하는 API 자체는 누구나 만들 수 있으며, 짧은 시간 동안 많은 유사 제품이 등장했다.
   2. 진짜 차이는 속도만이 아니라 정확도, 확신도(calibration), 일관성, 비전과의 결합에 있다.

3. 캘리브레이션 문제

   1. RLHF는 사용자가 듣고 싶어 하는 방향으로 답변을 밀 수 있지만, 모델이 실제로 얼마나 확신하는지를 그대로 보장하지는 않는다.
   2. 결정 모델이 확률과 확신을 얼마나 잘 보정하는지는 향후 모델에서 더 개선해야 할 핵심 영역으로 남는다.

4. 내부 사례

   1. User Operations 팀은 지원 티켓을 빠르게 분류하기 위해 Decisions API를 바로 시험했다.
   2. LLM-as-a-judge 평가에서 낮은 지연이 중요하므로 평가 시스템에도 적용할 가능성이 있다.

9.3. 실시간 음성·컴퓨터 사용 조합

1. 전면 모델과 후면 모델

   1. GPT Live는 빠르게 듣고 말하며 위임하는 전면 모델로 쓰고, Astra 같은 모델을 후면의 깊은 실행 모델로 둘 수 있다.
   2. 기존에는 Live에서 툴 호출이 느리게 느껴졌지만, Decisions API의 Luna가 컴퓨터 조작 결정을 맡으면 상호작용이 훨씬 즉각적이고 자연스러워진다.

2. 제품화 가능성

   1. Dots의 빠른 기능들은 Decisions API 위에 구축될 수 있다.
   2. 아직 출시된 지 일주일 남짓인 초기 단계이므로, 실제 사용자와 개발자가 어떤 조합을 만드는지가 다음 설계를 결정한다.

10. Agents API, Responses API, 캐시와 컨텍스트

OpenAI는 저수준 모델 호출만 제공하는 단계에서 벗어나, 장기 실행 에이전트를 운영하는 하네스와 성능 도구를 API에 함께 넣으려 한다.

10.1. Agents API가 실제 제품의 기반이 되는 방식

1. OpenAI 자체 제품

   1. 보안 관련 Codex 기능은 Agents API 위에 완전히 구축되었다.
   2. 회의 관련 기능과 캘린더에서 회의 노트를 Granola 같은 공간으로 보내는 플러그인·확장 시연도 같은 기반에서 작동한다.

2. 빠른 아이디어-실행 사이클

   1. 공간·페이지를 편집하고 협업하며 Dot을 추가하는 기능이 모두 같은 컴퓨터 사용·에이전트 기반에서 이어진다.
   2. Astra 같은 모델과 하네스를 이용하면 아이디어에서 실행까지의 시간이 급격히 짧아진다.

3. 개발자 피드백

   1. Agents API와 Decisions API는 가장 새로운 제품이므로 어떤 기능을 추가하거나 어떤 추상화를 제공해야 할지 모든 피드백을 원한다.
   2. API 팀은 사용자에게 사실상 로드맵을 함께 정의해 달라고 요청한다.

10.2. Responses API의 성능과 캐시

1. 두 가지 성능 축

   1. 첫째는 지연 시간이며, 팀은 Responses API의 경로를 다시 작성해 시간-첫-토큰과 전체 왕복 성능을 개선하고 있다.
   2. 둘째는 개인 에이전트처럼 하나의 스레드가 오래 지속될 때 프롬프트 캐시를 최대한 활용하는 것이다.

2. 캐시 보장

   1. 기본적으로 약 30분 안에 캐시 적중을 보장하는 경로가 있다.
   2. 일부 사용자에게는 더 긴 12시간 캐시 보장을 미리보기 형태로 제공하며, 더 긴 캐시를 위해 추가 비용을 지불하는 구조다.
   3. 몇 시간 뒤 같은 에이전트 스레드로 돌아와도 캐시 성능을 유지할 수 있다.

3. 프리워밍

   1. 곧 사용할 프롬프트를 알고 있다면 캐시 비용을 먼저 지불해 미리 준비할 수 있다.
   2. 이후 30분 동안 준비된 캐시를 활용하고 동일한 스레드의 여러 인스턴스를 만들 수도 있다.

4. 개발자 실천

   1. 애플리케이션을 캐시 친화적으로 설계하고 프롬프트·캐시 진단 도구로 어디에서 적중이 끊기는지 확인해야 한다.
   2. 새 모델의 낮은 캐시 읽기 비용까지 활용하면 장기 실행 앱의 비용을 크게 줄일 수 있다.

10.3. 백만 토큰 컨텍스트와 압축

1. 캐시만으로는 부족한 이유

   1. 장기 실행 에이전트는 여전히 백만 토큰 컨텍스트 한계에 부딪힌다.
   2. 캐시는 반복 입력 비용을 낮출 뿐, 대화가 무한히 커지는 문제를 해결하지 않으므로 좋은 압축이 필요하다.

2. 서버 측 자동 압축

   1. Agents API 하네스에는 압축 기능이 내장되어 있다.
   2. Responses API에서는 토큰 임계값에 도달하면 서버가 자동으로 컨텍스트를 줄이도록 설정할 수 있다.

3. 수동 /compact

   1. 개발자가 압축 시점을 직접 통제하고 싶다면 /compact를 호출해 자체 로직에 맞게 줄일 수 있다.
   2. Codex 오픈소스 하네스도 이 수동 경로를 사용하며, 대형 코딩 에이전트들이 선호하는 방식이다.

4. 파일 기반 실험

   1. 팀은 Codex 하네스에 이미 들어간 파일 기반 압축 기법을 실험하고 있다.
   2. 긴 실행의 상태를 파일에 외부화하면 모델 컨텍스트와 영구적인 작업 기억을 분리할 수 있다는 방향이다.

11. AI 클라우드로서의 API 설계

영상의 마지막 논점은 특정 기능의 출시가 아니라 OpenAI가 AI에 특화된 클라우드의 기본 서비스를 어떤 추상화로 제공할 것인가이다.

11.1. 저수준 원시 기능과 고수준 제품 사이

1. Stripe에서 얻은 비유

   1. Nikunj은 Stripe에서 결제 원시 기능 위에 고수준 프리미티브와 제품을 쌓는 일을 했다고 말한다.
   2. AI에서도 모델 호출·툴 호출 같은 저수준 기능 위에 에이전트·메모리·저장소를 어디까지 제공할지 같은 문제가 반복된다.

2. Assistants API의 교훈

   1. 과거 Assistants API는 높은 수준의 경험을 제공하려 했지만 모든 사용 사례에 맞는 추상화는 아니었다.
   2. 현재 Agents API는 실행 하네스를 제공하면서도 적절한 유연성을 어디까지 남길지 계속 탐색한다.

3. 미래의 API 객체

   1. 메모리 볼트, 장기 저장소, 에이전트 스레드 같은 객체를 API가 직접 제공할 수 있다.
   2. 반대로 개발자가 저수준 원시 기능과 예시 하네스를 받아 자신의 코딩 에이전트로 필요한 부분을 구현하도록 둘 수도 있다.

11.2. AWS의 AI 네이티브 대응물

1. 진행자는 이 방향을 “AI 클라우드”라고 부른다.

   1. AWS가 EC2, S3 같은 인프라 원시 기능을 나눴다면, AI 클라우드는 추론·툴 실행·메모리·캐시·에이전트 실행을 AI 네이티브한 방식으로 나눌 수 있다.
   2. Dots처럼 지속형 컴퓨터를 가진 에이전트는 이 여러 층을 실제 제품으로 묶는 사례다.

2. 아직 정답은 정해지지 않았다

   1. 너무 높은 수준으로 추상화하면 개발자의 통제력과 새로운 조합의 자유를 제한할 수 있다.
   2. 너무 낮은 수준으로 두면 모든 개발자가 캐시·압축·안전·재시도 하네스를 직접 만들어야 한다.
   3. 따라서 OpenAI가 어떤 기능을 원시 API에 넣고 어떤 기능을 예시 하네스나 제품에 맡길지가 계속되는 설계 질문이다.

주요 발언 모음

“컴퓨터 사용은 이제 대부분의 경우 평균적인 사람보다 작업을 빠르게 끝낸다.”

“다음 전선은 전문가 컴퓨터 사용자만큼, 또는 그보다 빠르게 소프트웨어를 사용하는 것이다.”

“세상의 모든 소프트웨어는 사람을 위해 설계되었고, 이제 에이전트가 같은 소프트웨어를 사용할 수 있다.”

“예전에는 작업을 안정적으로 시작했지만 문제가 생기면 멈췄고, 지금은 디버깅하고 다시 시도하며 무엇이 작동하는지 살핀다.”

“컴퓨터 사용은 소프트웨어를 만들 뿐 아니라 그 소프트웨어를 직접 테스트해 개발 생명주기를 완성한다.”

“신뢰를 쌓으려면 결과가 큰 행동 전에 사용자의 동의를 받고, 실제로 필요한 사이트와 앱만 접근하게 해야 한다.”

“낮은 수준의 API 원시 기능과 메모리·저장소 같은 높은 수준의 추상화를 어디까지 넣을지는 계속되는 질문이다.”

핵심 데이터 & 수치

• 영상 길이: 40분 24초.
• 컴퓨터 사용 사례: 식사 주문은 사람이 2시간 걸리던 일을 약 15분에 처리했으며, Ari는 약 8배 빠르다고 설명했다.
• 모델 비용: 대화에서 GPT 6.1 Soul은 Astra 대비 전체 비용 5분의 1, 컴퓨터 사용 기준 7분의 1로 언급된다.
• 속도 향상: 키노트에서는 컴퓨터 사용 속도 7배 향상이 제시된다.
• 실제 서비스 대기: 웹사이트 로딩, 고객센터 답변은 각각 모델 추론 외에 큰 지연을 만들며, 고객센터 답변은 30초에서 3분까지 걸릴 수 있다.
• Luna 비용 개선: 추론 최적화로 가격을 약 80% 낮춘 사례가 언급된다.
• 캐시: 일반적인 캐시 적중 보장은 약 30분이며, 일부 사용자에게 12시간 보장을 미리보기로 제공한다.
• 컨텍스트: 장기 실행 에이전트는 백만 토큰 컨텍스트 한계와 압축 문제를 함께 다뤄야 한다.
• 출시 속도: Decisions API 프로토타입은 대화 시점 기준 약 4주 전에는 없었고, 실제 제품화는 초기 반복 배포 단계다.

결론 및 시사점

1. 컴퓨터 사용의 경쟁력은 모델 단독 지능이 아니다. 모델, 하네스, 접근성·DOM 표현, 코드 실행, 브라우저 이벤트, 추론 인프라를 함께 최적화해야 실제 속도가 올라간다.
2. 가장 빠른 초기 사용 사례는 API가 없는 소프트웨어의 자동화다. YouTube 운영, 고객센터, 맞춤 주문처럼 사람이 화면에서 할 수 있지만 API로는 접근하기 어려운 작업이 범용 컴퓨터 사용의 이점을 즉시 보여준다.
3. 초인적 속도는 실시간 제품을 가능하게 한다. 평균 사용자보다 빠른 현재 단계에서 전문가보다 빠른 단계로 넘어가면, 에이전트 호출 자체가 특별한 이벤트가 아니라 소프트웨어의 기본 상호작용이 된다.
4. Decisions API는 깊은 추론의 대체재가 아니라 초고속 라우터다. 구조화 출력, 병렬 추론, 낮은 지연을 활용해 분류·선택·간단한 컴퓨터 조작을 담당하고, 복잡한 장기 작업은 더 큰 모델에 맡기는 구성이 자연스럽다.
5. 에이전트 제품은 build-test 루프를 닫는다. 컴퓨터 사용이 생성된 앱을 직접 조작하고 시각적으로 테스트하면 사람이 QA 병목이 되는 문제를 줄일 수 있다.
6. 안전은 나중에 붙이는 기능이 아니다. 결제·DNS·권한 변경처럼 실제 상태를 바꾸는 작업은 명시적 동의, 접근 범위 제한, 재현 가능한 검증을 기본 경로로 포함해야 한다.
7. 장기 실행에는 캐시와 압축이 함께 필요하다. 캐시는 반복 비용을 줄이고, 자동·수동 컴팩션과 파일 기반 상태 외부화는 컨텍스트 한계를 관리한다.
8. AI 클라우드의 승부처는 추상화 경계다. OpenAI가 어느 수준까지 메모리·저장소·에이전트 실행을 제품화하고 어느 수준을 개발자에게 남길지가 플랫폼의 사용성을 결정한다.
9. 개발자는 새 API를 단순 호출하기보다 운영 피드백을 제공해야 한다. 실제 작업에서 발생하는 지연, 실패, 캘리브레이션 오류, 사용자 승인 시점을 모아야 다음 모델과 하네스의 방향이 정해진다.
10. 가장 큰 변화는 ‘컴퓨터로 할 수 있는 일’의 정의가 바뀌는 것이다. API 목록에 있는 일만 자동화하는 것이 아니라 사람이 쓰는 모든 소프트웨어 표면을 에이전트의 작업 공간으로 전환하는 것이 DevDay 발표들의 공통 방향이다.

핵심 요약 (20줄)

1. OpenAI DevDay의 컴퓨터 사용 발표들은 개인 제품, 개발자 API, 추론 인프라를 하나의 에이전트 스택으로 묶는다.
2. Dots는 각 인스턴스에 자체 Linux 가상 컴퓨터를 제공해 데스크톱 앱과 웹 브라우저를 모두 조작한다.
3. 컴퓨터 사용의 범용성은 사람이 사용할 수 있는 기존 소프트웨어를 별도 API 없이 에이전트가 활용하게 한다.
4. Ari는 맞춤 식사 주문을 사람이 두 시간 하던 일을 에이전트가 15분에 처리한 사례를 소개한다.
5. 진행자는 YouTube의 A/B 테스트와 커뮤니티 게시물 자동화를 가장 중요한 사용 사례로 꼽는다.
6. 예전 모델은 작업을 시작했지만 실패하면 멈췄고, 최근 모델은 디버깅과 재시도에 강해졌다.
7. 최신 컴퓨터 사용 하네스는 JavaScript, 접근성 트리, DOM, Playwright, 스크린샷을 작업별로 조합한다.
8. Appshot은 단순한 이미지가 아니라 링크, 전체 텍스트, 앱 구조를 포함한 토큰 효율적 표현이다.
9. 접근성 기술이 사람의 스크린 리더를 돕듯이 같은 구조가 언어 모델의 컴퓨터 조작을 돕는다.
10. Ari가 말하는 다음 목표는 평균 사용자보다 빠른 수준을 넘어 전문가보다 빠른 초인적 컴퓨터 사용이다.
11. 실제 속도의 병목은 모델뿐 아니라 웹사이트 로딩, 이벤트 감지, 하네스와 표현 방식에도 있다.
12. Agents API는 OpenAI 제품과 같은 컴퓨터 사용 구현을 개발자에게 제공하며 자체 하네스보다 안정적일 수 있다.
13. 개발자는 결제 같은 결과가 큰 행동 전에 동의를 받고 필요한 사이트와 앱만 허용해야 한다.
14. 컴퓨터 사용은 에이전트가 자신이 만든 소프트웨어를 직접 테스트하는 개발·QA 루프를 완성한다.
15. Nikunj은 async function calling과 mid-turn steering으로 툴 실행 중에도 추론과 지시 주입을 계속하게 한다.
16. WebSocket은 모델과 애플리케이션의 양방향 통신을 제공해 긴 툴 호출의 왕복 지연을 줄인다.
17. Decisions API는 Luna 계열 가중치에 구조화 출력과 병렬 추론을 적용한 빠른 판단 경로다.
18. Decisions API는 장기 추론보다 분류, 라우팅, 간단한 컴퓨터 조작과 실시간 음성 결합에 적합하다.
19. Responses API의 장기 실행 전략은 낮은 지연, 캐시 보장과 프리워밍, 자동·수동 컨텍스트 압축을 포함한다.
20. OpenAI는 추론·툴·메모리·캐시를 AI 네이티브한 AWS처럼 제공하는 AI 클라우드의 추상화 경계를 탐색하고 있다.