OpenAI Agents API, 에이전트 실행까지 맡긴다
OpenAI의 Agents API는 애플리케이션이 Codex 실행 하네스에 접근하도록 하는 관리형 API다. 애플리케이션이 에이전트의 도구와 실행 환경을 정하면, OpenAI가 세션 운영과 작업 조정, 이전 작업 요약, 복구를 맡는다. 개발자가 모델 호출과 파일 작업, 상태 이어받기를 각각 조립하는 대신 에이전트의 실행 단위를 API로 다루는 구조다.
실행 환경을 먼저 정하고 역할을 나누다
이 구조에서 애플리케이션은 세션을 실행하기 전에 어떤 도구를 노출할지와 에이전트가 파일·명령을 다룰 실행 환경을 선택하고 준비한다. 실행 환경은 OpenAI가 호스팅하는 샌드박스일 수도 있고, 애플리케이션이 준비한 자체 호스팅 환경일 수도 있다. 따라서 API를 사용한다고 해서 모든 실행 자원을 OpenAI 호스팅 환경에 맡겨야 하는 것은 아니다.
환경이 선택되고 준비된 뒤에는 OpenAI가 세션과 작업 조정, 이전 작업 요약, 복구를 관리한다. 반면 실제 에이전트 작업은 선택된 실행 환경에서 이뤄진다. 에이전트는 샌드박스에서 코드를 실행하고 파일을 편집하며, MCP 서버에 연결하고 결과물인 아티팩트를 만들 수 있다. 아래 흐름은 실행 환경의 선택·준비가 세션 실행보다 앞서고, OpenAI가 관리하는 흐름과 실제 실행 영역이 분리되는 구조를 보여준다.
세션은 생성부터 재개까지 이어진다
세션을 만들 때 애플리케이션은 에이전트의 모델, 지시사항, 도구와 MCP 서버를 설정한다. 실행 환경을 선택하고 준비한 뒤 세션을 시작하면, OpenAI 호스팅 환경을 선택한 경우에는 환경이 준비된 뒤 사용자의 입력이 작업을 시작한다. 이후 애플리케이션은 이벤트를 스트리밍하거나 웹훅으로 받아 작업 진행 상황을 확인하고, 완료되었는지 추가 입력이 필요한지 파악한다.
작업이 끝난 뒤에는 같은 세션에 새로운 작업을 보낼 수 있다. 에이전트가 현재 작업을 수행하는 동안에도 방향을 조정할 수 있으며, 중단된 세션을 이어서 실행할 수도 있다. 이 흐름은 단발성 응답보다 지속되는 작업 단위에 맞춰 설계됐다. 다만 세션의 운영과 상태 흐름을 OpenAI가 관리한다는 점과, 파일·명령·외부 시스템에 대한 실제 접근 권한은 선택된 실행 환경의 설정에 달려 있다는 점을 구분해야 한다.
도구를 붙일수록 넓어지는 작업 범위
Agents API는 프로그램 방식 도구 호출, 웹 검색, MCP 연결을 지원한다. 애플리케이션은 필요한 기능만 선택해 에이전트에 제공할 수 있고, 여러 하위 에이전트에 독립적인 조사 작업을 위임하도록 설정할 수도 있다. 예시로는 디렉터리 구조를 만드는 스크립트 실행, 릴리스 노트 비교, 장애 대응, 슬랙 요청 조사, 읽기 전용 SQL을 이용한 데이터 분석, GitHub 이슈 재현, 문서 검토 등이 제시됐다.
이 기능 조합은 에이전트를 단순한 텍스트 응답기가 아니라 도구를 사용해 결과물을 만드는 작업자로 다루게 한다. 다만 어떤 데이터와 명령을 허용할지는 애플리케이션의 설계와 실행 환경 설정에 달려 있다. 같은 API를 사용하더라도 허용된 도구, 연결된 MCP 서버, 파일 시스템의 범위가 다르면 에이전트가 수행할 수 있는 작업과 데이터 접근 경계도 달라진다.
비용은 모델과 실행 자원에 따라 붙는다
모델 사용량은 선택한 모델의 API 요금으로 청구된다. OpenAI 도구는 각 도구의 표준 요금이 적용되고, OpenAI가 호스팅하는 샌드박스는 표준 컨테이너 요금이 적용된다. 따라서 비용은 모델 호출량뿐 아니라 웹 검색이나 기타 도구 사용, 호스팅 샌드박스 이용 여부에 따라서도 달라질 수 있다. 자체 호스팅 환경을 선택할 경우에도 해당 환경을 준비하고 운영하는 부담은 애플리케이션 쪽에 남는다.
개발자들이 본 편의성과 부담
bluesnowmonkey는 에이전트를 제품으로 제공하는 데 적절한 추상화가 아직 정해지지 않았다고 봤다. 특히 자체 하네스를 만드는 일은 매우 크고 깊은 작업이 되기 쉽고, 오픈소스 하네스를 쓰더라도 특정 실행 환경에 결합될 수 있다고 지적했다. 파일 시스템이 없는 Cloudflare Worker 같은 환경에서는 상태를 어디에 저장할지가 별도 문제라는 설명도 덧붙였다. 그의 관점에서 관리형 에이전트 서비스는 도구를 연결하는 일을 단순화하면서 메모리와 작업 관리 같은 어려운 부분을 서비스 제공자가 계속 개선하게 한다.
반면 andrewchambers는 일반 QEMU 가상 머신에서 Codex를 실행하고 휴대전화로 원격 제어하는 방식이 개인 비서로 잘 작동했다고 말했다. 그는 API가 필요한 이유를 이해하면서도 자체 가상 머신을 구성하면 특정 서비스에 묶이지 않을 수 있다고 봤다.
baalimago는 OpenAI Agents SDK로 샌드박스, 슬랙, 지식 저장소 연동을 독립적으로 구성하고 OpenAI에 노출할 기능을 엄격하게 제한해 왔다고 밝혔다. Agents API가 호스팅 부담을 줄여줄 수 있다는 점은 인정했지만, Python 서비스를 직접 호스팅하는 일이 쉬워진 상황에서는 소비자 관점의 이점이 분명하지 않다고 평가했다. 6thbit는 문서에서 자체 호스팅 샌드박스를 선택할 수 있다는 점을 짚으며, 이 선택지가 다른 공급자로 옮겨갈 때의 부담을 낮출 수 있다고 봤다.
원격 데이터와 공급자 종속의 쟁점
zmmmmm는 원격으로 호스팅되는 에이전트가 로컬 데이터와 인프라에 접근하는 방식이 자신에게는 거꾸로 된 해법이라고 지적했다. 로컬 데이터에 접근하려면 보안, 민감도, 관리 문제가 생기는데 에이전트를 원격으로 옮기면 원격 에이전트가 내부 인프라에 접근해야 해 문제가 더 커질 수 있다는 주장이다. 그는 에이전트는 로컬에서 실행하고, 격리와 관리를 위해 원격 호스팅 샌드박스를 제공하는 방향을 선호한다고 말했다.
monneyboi는 공급자 종속을 늘리는 접근보다 사용자가 비용을 지불한 추론 토큰을 제공해야 한다고 비판했다. brap은 일반적인 LLM 엔드포인트와 에이전트 하네스의 경계가 점점 흐려져 결국 의미 없는 구분이 될 수 있다고 봤다. 이 반응들은 API가 단순히 모델 호출을 감싸는 기능인지, 아니면 실행 환경과 도구를 포함한 더 큰 제품 단위인지가 아직 논쟁적임을 보여준다.
편의성 이후의 경쟁
추측하건대, Agents API의 가장 큰 장점은 에이전트 인프라를 처음부터 조립하는 부담을 낮추는 데 있을 가능성이 크다. 세션 재개, 작업 조정, 이전 작업 요약, 복구를 한 번에 다룰 수 있기 때문에 작은 팀도 복잡한 작업 흐름을 빠르게 시험할 수 있을 가능성이 크다. 특히 실행 환경을 직접 선택하면서도 세션 운영에 필요한 기능을 별도로 구축하지 않아도 된다는 점이 관리형 API의 핵심 편의로 보인다.
하지만 장기적으로는 데이터 경계·모델 선택권·환경 이동성이 제품 경쟁력을 가를 가능성이 크다. 자체 호스팅 환경을 지원하면 실행 위치에 대한 선택권은 넓어지지만, 모델과 도구 구성, 세션 운영 방식까지 다른 공급자 사이에서 동일하게 옮길 수 있다는 뜻은 아니다. 반대로 원격 호스팅은 운영 편의를 제공하지만 내부 데이터에 접근하는 경로와 권한 설계를 더 엄격하게 요구할 가능성이 크다.
결국 이 API의 성패는 에이전트를 얼마나 쉽게 실행하느냐뿐 아니라, 사용자가 자신의 데이터와 실행 환경을 얼마나 통제하면서 그 편의를 누릴 수 있느냐에 달려 있을 가능성이 크다. 실행 환경을 먼저 선택·준비하고 관리 영역과 실제 실행 영역을 나눠 볼 수 있어야, 도입 편의성과 통제권 사이의 trade-off도 구체적으로 평가할 수 있다.
