OpenAI가 개발자 행사 DevDay에서 내놓은 agent 기능들은 한 방향을 가리킵니다. AI agent가 사람이 쓰는 화면과 앱을 그대로 다루게 하는 것입니다. OpenAI에서 computer use(AI가 화면을 보고 마우스와 키보드를 조작해 소프트웨어를 다루는 기능) 제품과 엔지니어링을 이끄는 담당자는 이 기능이 흔한 작업에서 이미 평균적인 사람보다 빠르게 일을 끝내는 수준에 왔다고 봅니다. 다음 목표는 숙련된 사용자보다도 빠른 속도이고, 그 속도에 이르면 실시간으로 반응하는 제품이 가능해진다는 설명입니다. 새 개인 비서 Dot, 새 모델 GPT-6.1 Sol, Agents API와 Decisions API가 이 구조에서 각각 어떤 역할을 맡는지, 개발자가 지금 무엇을 확인하면 되는지 정리합니다.

Dot은 agent마다 컴퓨터 한 대를 준다

Dot은 OpenAI가 새로 내놓은 개인 비서이며 computer use 기능을 갖췄습니다. 이전 도구들은 격리된 브라우저나 사용자의 컴퓨터 안에서만 움직였습니다. Dot은 agent마다 클라우드의 Linux 가상 머신 한 대를 통째로 배정하고, 그 작업 환경이 계속 유지됩니다.

이 설계의 장점은 다룰 수 있는 범위입니다. agent가 웹 브라우저와 데스크톱 프로그램을 함께 쓸 수 있고, 사람이 쓰는 소프트웨어는 모두 화면으로 조작하도록 만들어져 있으니 사람이 컴퓨터로 하는 일은 대부분 agent도 할 수 있다는 논리입니다. 개발자용 API가 없는 서비스도 화면 그대로 다룹니다.

  • 닭고기와 밥의 그램 수까지 정한 맞춤 식단 정기 주문은 사람이 직접 설정하는 데 2시간이 걸렸지만, GPT-6.1 Sol에 맡기자 15분에 끝났습니다. 8배 빠른 셈입니다.
  • 공개 API가 없는 YouTube 관리 작업, 예를 들어 커뮤니티 게시물 올리기와 썸네일 A/B 테스트 설정도 agent에 맡기기 좋은 일로 꼽힙니다. OpenAI 사내 개발자 경험 팀도 YouTube 운영에 computer use agent를 많이 씁니다.
  • 고객센터의 로그인, 본인 확인, 계정 문제 해결 같은 번거로운 절차와 DNS 레코드 설정, 금액이 큰 청구서 결제를 agent에게 맡긴 사례도 있습니다.

반복 화면 캡처와 구조화된 화면 정보를 나란히 비교한 그림

▲ 화면 캡처에서 구조 읽기로

화면을 찍던 방식에서 구조를 읽는 방식으로

예전의 computer use는 화면 캡처에만 기대어 움직였습니다. 화면을 찍고, 아래로 내리고, 다시 찍은 뒤 그 장면들을 이어 붙이는 식이었습니다. 지난 1년 사이 방식이 크게 바뀌었습니다.

구분 예전 방식 지금 방식
화면 파악 화면 캡처를 조각조각 보며 스크롤 DOM(웹 페이지의 구조 정보)과 운영체제의 접근성 트리로 화면 전체를 한 번에 파악
동작 클릭 한 번마다 응답을 기다림 여러 동작을 묶은 JavaScript 코드를 써서 한 번에 실행
예상 밖 상황 오류나 팝업이 나오면 그대로 실패 실패한 단계를 살펴 원인을 찾고 스스로 고쳐 다시 시도
입력 수단 화면 이미지 접근성 트리, Playwright 브라우저 자동화, 화면 캡처 가운데 작업에 맞는 것

접근성 트리는 원래 화면 낭독기를 위해 만든 기술인데, 이 덕분에 언어 모델이 버튼, 라벨, 입력 칸을 token(모델이 처리하는 글 조각 단위)을 아끼는 형태로 읽을 수 있습니다. 화면 전체 구조를 한 번에 받으니 여러 단계를 한 번에 처리하는 코드를 짤 수 있습니다.

DevDay에서 공개한 Appshots가 이 방식을 사용자 쪽에서 쓰는 기능입니다. Codex나 ChatGPT에서 Command 키를 두 번 누르면 앱 화면을 이미지가 아니라 구조 정보와 글, 접근성 트리째로 담아 넘깁니다. 일반 화면 캡처는 링크가 가리키는 주소나 잘린 일정 제목 같은 정보를 잃지만, Appshots는 이런 정보까지 모델에 전합니다. Codex에서 첨부물을 누르면 실제로 넘어간 접근성 정보와 글을 확인할 수 있고, 도구 실행 기록을 펼치면 agent가 여러 동작을 묶어 쓴 JavaScript 코드도 볼 수 있습니다.

속도를 잡아먹는 것은 모델 밖에 있다

DevDay 기조연설에서는 computer use 속도가 7배 빨라졌다는 수치가 나왔습니다. 이 향상은 모델과 harness(모델이 도구를 쓰도록 감싸는 실행 환경)가 함께 좋아진 결과입니다. 하루하루의 개선은 작아 보여도 몇 달이 쌓이면 신뢰성과 속도가 크게 달라진다는 설명입니다. 비용도 내려갔습니다. GPT-6.1 Sol의 비용은 일반 작업에서 Astra의 5분의 1, computer use 작업에서는 7분의 1 수준입니다.

모델이 빨라지자 이제는 외부 서비스가 병목입니다. DoorDash에서 주문을 자동화하면 실행 시간 대부분이 웹 페이지가 다 뜨기를 기다리는 데 쓰입니다. 정해진 시간만큼 기다리게 하면 그만큼 시간을 버리므로, 화면이 다 그려진 순간과 agent가 다음 동작을 하는 순간 사이의 틈을 줄이는 것이 과제입니다. 브라우저의 페이지 로드 이벤트처럼 신호를 받아 움직이는 방식이 낫지만, 화면 요소가 바뀌어도 깔끔한 신호를 보내지 않는 웹 서비스가 아직 많습니다. 고객센터 채팅처럼 답이 오기까지 30초에서 3분이 걸리는 일도 agent가 기다리며 처리합니다.

직접 만든 harness보다 Agents API를 권하는 이유

OpenAI는 computer use를 Agents API에 넣어, 외부 개발자도 Codex와 ChatGPT가 쓰는 도구 실행 환경을 그대로 쓰게 했습니다. harness를 직접 만들 수도 있지만, 모델은 OpenAI 자체 harness로 학습했기 때문에 공식 harness를 쓰면 정확도, 속도, 비용에서 유리하다는 것이 OpenAI의 설명입니다.

신뢰를 쌓는 장치도 함께 강조됩니다. 중요한 일을 agent에게 맡기는 쪽은 아직 일부 초기 사용자에 머물러 있어, 많은 사람이 쓰게 하려면 안전장치로 신뢰부터 쌓아야 한다는 판단입니다.

  • 결제처럼 되돌리기 어려운 동작 전에는 사용자의 명시적인 확인을 받습니다.
  • agent가 그 작업에 필요한 도메인과 앱에만 접근하도록 범위를 제한합니다.

개발 과정도 바뀝니다. agent가 코드를 고친 뒤 직접 빌드하고 앱을 실행해 화면과 기능을 시험하므로, 지금까지 사람이 맡던 품질 확인 단계를 agent가 대신합니다. 화면을 보며 점검하는 시험은 레이아웃이 망가진 곳을 찾아내고, 기존 앱을 화면 단위로 복제하는 데도 쓰입니다.

agent가 만든 앱을 직접 띄워 화면 오류를 점검하는 장면

▲ agent의 화면 점검과 사용자 확인

빠른 판단은 Decisions API, 긴 작업은 큰 모델

Decisions API는 빠른 분류와 판단에 맞춘 API입니다. 긴 추론을 빼고 작은 모델로 여러 요청을 동시에 처리해 지연을 크게 줄였습니다. OpenAI API 제품 책임자의 설명에 따르면 새로 학습한 모델이 아니라 기존 Luna 가중치를 그대로 쓰고, 첫 응답까지의 시간을 줄이도록 추론 환경을 손보고 정해진 형식의 답을 한꺼번에 처리합니다. 첫 버전은 별도 학습 없이 내놓아 의견을 모은 뒤 전용 학습을 더하는 방식이고, Luna의 이미지 인식 기능도 따로 연동할 필요 없이 그대로 씁니다.

쓰임은 두 가지입니다. 하나는 대량 분류입니다. OpenAI 사내 고객 지원 조직은 들어오는 문의를 분류하는 데 이 API를 바로 썼습니다. 다른 하나는 computer use 흐름 안의 짧은 결정입니다. 여러 단계를 담은 JavaScript 코드를 통째로 짜는 일은 Astra 같은 큰 모델이 맡고, Luna 기반의 Decisions API는 다음 클릭 하나 같은 작은 결정을 빠르게 고릅니다. 음성 대화 모델 GPT Live가 사용자와 이야기하며 일을 넘기고, Decisions API가 대화를 멈추지 않고 곧바로 도구를 실행하는 구성도 OpenAI 안에서 시험하고 있습니다.

한계도 분명합니다. Decisions API는 추론을 하지 않아 길고 모호한 작업에는 맞지 않고, 빠른 실행과 깊은 추론을 하나로 잇는 방법은 아직 연구 과제입니다.

API의 변화: 기다리지 않는 도구 호출과 캐시 보장

API에도 agent에 필요한 기능이 더해졌습니다.

  • 비동기 도구 호출: GPT-6와 함께 나온 기능으로, 오래 걸리는 도구를 실행해 두고 모델은 멈추지 않고 생성과 추론을 이어 가다가, 도구가 끝나면 결과를 받습니다.
  • 추론 중 지시: 모델이 추론하는 도중에 새 지시를 넣어 방향을 바꿉니다.
  • WebSocket 연결: 앱과 모델이 연결을 유지한 채 양방향으로 주고받아, 도구를 여러 번 호출할 때의 지연을 줄입니다.
  • 응답 속도: 가장 많이 쓰는 Responses API의 서버 구조를 새로 짜, 첫 token이 나오기까지의 시간과 token 사이의 간격을 줄이고 있습니다.
  • 캐시 보장: 30분 안의 캐시 적중을 보장하고, 기업 사용자용 12시간 보장은 아직 미리보기 단계입니다. 캐시 쓰기 요금을 미리 내고 캐시를 채워 두는 기능, 캐시가 어디서 끊기는지 찾는 진단 도구도 생겼습니다.
  • 대화 압축: Agents API는 harness가 알아서 압축하고, Responses API에서는 정한 token 수에 이르면 서버가 자동으로 압축하거나 개발자가 compact 명령으로 직접 시점을 정할 수 있습니다.

추론 속도를 이론상 최고치까지 끌어올린 Ultrafast 모드도 공개됐습니다. 그 전에 추론 효율을 높이는 과정에서 Luna의 가격은 약 80% 내려갔습니다.

개발자가 지금 확인할 점

이번 발표는 agent를 하나의 큰 기능으로 묶기보다, 컴퓨터, 판단, 캐시 같은 기본 요소를 제공하는 쪽에 무게를 둔 것으로 보입니다. OpenAI API 제품 책임자는 낮은 수준의 기본 기능과 쓰기 편한 상위 기능 사이의 균형을, 결제 기본 기능 위에 여러 서비스가 자라난 Stripe에서의 경험에 빗대어 설명합니다. 바로 해 볼 만한 일은 다음과 같습니다.

  1. 공개 API가 없고 여러 단계를 거치는 반복 작업을 골라 computer use agent에 맡겨 봅니다.
  2. agent가 웹 서비스를 다룰 때는 정해진 시간만큼 기다리는 코드 대신 페이지 로드 같은 신호를 쓰게 합니다.
  3. 결제 같은 되돌리기 어려운 동작 앞에 사용자 확인을 두고, 접근할 수 있는 도메인을 작업에 필요한 범위로 묶습니다.
  4. 빠른 분류나 한 단계 판단은 Decisions API에, 여러 단계를 짜는 일은 큰 모델에 나눠 맡기도록 설계합니다.
  5. 시스템 지시와 앞부분 입력을 일정하게 유지해 캐시 적중률을 높이고, 진단 도구로 캐시가 끊기는 곳을 확인합니다.