9월 29일 Agents API에 추가된 컴퓨터 사용
OpenAI는 2026년 9월 29일 API 변경 기록(changelog)에 'Added computer use to the Agents API.'라고 적고, 에이전트가 OpenAI가 호스팅하는 브라우저에서 작업을 끝낼 수 있으며 웹사이트 접근 승인과 로그인은 개발자의 애플리케이션이 처리한다고 밝혔습니다. 같은 날 올라온 DevDay 2026 정리 글도 Agents API가 컴퓨터 사용을 지원해 소프트웨어를 조작하는 에이전트를 만들 수 있고, 기반 인프라는 OpenAI가 운영한다고 설명합니다.
Agents API는 같은 변경 기록의 9월 10일 항목에서 공개 베타로 나왔고, 공식 문서의 SDK 호출도 client.beta.agents.sessions 형태입니다. 컴퓨터 사용 요금, 세션 수명과 동시 실행 한도, 지원 지역과 데이터 보존 조건은 변경 기록과 DevDay 글에 적혀 있지 않아 확인하지 못했습니다.
작성자 해석으로는, 브라우저 실행 환경은 OpenAI가 운영하고 어느 사이트에 들어갈지와 로그인을 누가 처리할지는 개발팀이 설계해야 합니다. 아래에서는 이 설계에 필요한 공식 문서 내용을 정리합니다.
네트워크 허용과 사이트 접근 승인은 따로 정합니다
공식 컴퓨터 사용 가이드(날짜 표시 없음)에 따르면 에이전트가 새 웹사이트 출처(origin, 도메인 단위의 사이트 주소)에 들어가려 할 때마다 사용자 승인이 필요하고, 네트워크 접근을 허용했다고 이 요청이 승인되지는 않습니다('Enabling network access does not approve these requests.'). 가이드는 출처 승인이 별도의 사용자 결정이며 네트워크 정책을 무시하지 않는다고도 적었습니다.
가이드는 다음 순서로 사용 방법을 설명합니다. 세션을 만들 때 tools에 computer_use를 넣고 environment.type을 openai_hosted로, desktop.enabled를 true로 지정합니다. 이벤트 스트림을 구독하다가 agent.session.requires_action 이벤트가 오면 세션을 다시 조회해 required_actions에 있는 computer_use_approval_request를 처리합니다. 요청 종류에는 사이트 접근용 browser_origin_access와 로그인용 browser_authentication이 있습니다. 결과를 확인한 뒤에는 세션을 삭제합니다.
작성자 해석으로는, 앱에서는 네트워크 정책으로 아예 막을 사이트를 먼저 정하고, 허용한 범위 안에서 새 출처가 나왔을 때 누가 승인할지를 따로 정해야 합니다. 두 결정이 서로를 대신하지 않기 때문입니다.
출처 승인이 개별 동작 확인을 대신하지 않습니다
가이드는 'Origin approval does not enforce confirmation before individual actions'라고 적었습니다. 사이트 접근을 승인한 뒤에는 그 사이트 안의 클릭이나 입력마다 확인을 받도록 강제하는 장치가 없다는 뜻입니다. 가이드는 구매나 데이터 삭제처럼 결과가 큰 동작 전에 반드시 확인을 받아야 하는 앱이라면, 호스팅 브라우저가 그런 동작을 할 수 없는 리소스에만 접근하게 제한하거나 직접 제어하는 브라우저 런타임을 쓰라고 안내합니다. 함수 도구로 확인을 묻는 방식은 에이전트가 그 함수를 호출해야만 동작한다는 점도 적었습니다.
승인 요청을 취소해도 작업 자체는 취소되지 않습니다('Cancelling an approval request does not cancel the task.'). 가이드는 작업을 멈추려면 턴(turn, 에이전트가 요청 하나를 처리하는 단위)을 취소하라고 안내합니다. 작성자 해석으로는, 첫 시험에서는 결제·발송·삭제 기능이 있는 사이트를 접근 대상에서 빼 두는 편이 안전합니다. 사용자가 승인을 거절하거나 취소했을 때 앱이 턴 취소까지 함께 처리할지도 미리 정해 두십시오.
로그인은 메인 에이전트만 요청할 수 있습니다
가이드는 브라우저 로그인을 요청할 수 있는 것은 메인 에이전트뿐이고 하위 에이전트(subagent)는 요청할 수 없다고 밝혔습니다('Only the main agent can request browser authentication; subagents cannot.'). 지원하는 로그인 방식은 이메일 주소, 비밀번호, 인증 코드이며 패스키와 QR 코드 로그인은 지원하지 않습니다. 문서는 로그인 값을 전용 이벤트로만 보내고, 이 값이 모델 입력과 세션 기록에서 빠진다고 설명합니다. 자격 증명을 보낼 때 HTTP나 SDK의 자동 재시도를 끄라는 안내('Disable automatic HTTP or SDK retries for credential submissions.')도 있고, 제출이 받아들여졌는지 확실하지 않으면 세션을 다시 조회한 뒤 진행하라고 적었습니다. 로그인 요청은 5분이 지나면 만료됩니다.
작성자 해석으로는, 사내 시스템이 패스키나 QR 코드 로그인만 허용한다면 이 기능으로는 로그인 단계를 넘길 수 없습니다. 하위 에이전트에게 일을 나눠 줄 때도 로그인이 필요한 작업은 메인 에이전트 쪽에 두도록 설계해야 합니다. 로그인 값을 입력할 사람이 요청을 받고 5분 안에 응답할 수 있는지도 업무 흐름에서 확인하십시오.
| 요청·설정 | 공식 가이드 내용 | 앱이 정할 일 |
|---|---|---|
| 네트워크 정책 | 출처 승인이 네트워크 정책을 무시하지 않음 | 아예 막을 사이트 목록 |
| browser_origin_access | 새 출처마다 사용자 승인 필요 | 승인할 사람과 승인 기록 위치 |
| 사이트 안의 개별 동작 | 출처 승인이 개별 동작 전 확인을 강제하지 않음. 확인이 꼭 필요하면 그런 동작을 할 수 없는 리소스로 제한하라고 안내 | 결제·삭제 기능이 있는 사이트를 접근 대상에서 뺄지 |
| browser_authentication | 메인 에이전트만 요청 가능, 패스키·QR 코드 로그인 미지원, 요청은 5분 뒤 만료 | 로그인 값을 입력할 사람 |
| 자격 증명 전송 | HTTP·SDK 자동 재시도 끄기 | 앱의 재시도 설정 확인 |
| 세션 종료 | 결과 확인 뒤 세션 삭제 | 세션을 삭제할 시점 |
이번 주에 해 볼 첫 단계
브라우저 에이전트에 맡기고 싶은 업무 1건을 골라, 그 업무가 거치는 사이트 출처를 모두 적어 보십시오. 출처마다 로그인 방식(비밀번호, 인증 코드, 패스키)과 결제·삭제처럼 되돌리기 어려운 동작이 있는지 표시하면, 패스키 사이트와 되돌리기 어려운 동작이 있는 사이트는 첫 시험에서 뺄 후보로 정리됩니다. 나머지 출처에 대해 승인할 사람과 승인 기록 위치를 정한 다음, 공식 가이드의 예제로 세션을 만들어 보면 됩니다.
이 글은 OpenAI API 변경 기록, DevDay 2026 정리 글, 컴퓨터 사용 가이드를 읽고 정리했으며 직접 실행해 확인하지는 않았습니다.