AI IDE List: Agents API 심층 분석

핵심 주장

OpenAI의 Agents API 출시는 단순히 또 하나의 에이전트 프레임워크 출시가 아니다. OpenAI는 Codex를 구동하는 관리형 하네스를 클라우드 서비스로 제공하고 있으며, OpenAI가 세션, 오케스트레이션, 컨텍스트 압축, 복구를 담당하고 개발자는 작업, 도구, 데이터, 실행 환경을 제공한다.

이 구분이 중요하다. 모델 API는 요청에 응답하고, 에이전트 SDK는 개발자가 오케스트레이션 코드를 작성하도록 돕고, 관리형 에이전트 하네스는 모델 주변의 지속적인 제어 루프를 책임진다: 세션 유지, 도구 호출 시점 결정, 유용한 컨텍스트 보존, 중단으로부터의 복구, 서브 에이전트 조율, 실행이 다른 곳에서 일어나는 동안 작업 유지.

OpenAI의 공식 문서는 이 분할을 직접 기술한다: Agents API는 애플리케이션에 Codex 하네스 접근 권한을 제공하고, OpenAI는 세션, 오케스트레이션, 컨텍스트 압축, 복구를 관리한다. 애플리케이션은 도구를 제공하고 실행 환경을 선택한다.

이것이 Agents API를 기존의 LLM 엔드포인트보다 에이전트 런타임 as a Service에 더 가깝게 만든다.

하네스가 중요한 이유

현대 에이전트는 단순히 모델 주변의 프롬프트가 아니다. 프로덕션 에이전트는 보통 여러 인프라 문제를 해결해야 한다:

여러 턴에 걸쳐 상태 유지
어떤 도구가 관련 있는지 결정
도구를 안전하게 실행
가능한 경우 큰 도구 출력을 모델 컨텍스트에서 제외
모델이 한계에 도달하기 전에 컨텍스트 압축
일시적 실패 후 재시도/복구
병렬 워커 조율
파일 시스템/작업 공간 유지
자격증명 관리
애플리케이션에 진행 상황 및 트레이스 노출
브라우저 탭, 클라이언트, 네트워크 연결이 사라져도 계속 실행

Codex는 코딩 작업이 여러 단계에 걸치고, 파일과 셸을 포함하며, 충분히 오래 실행되어 단순한 요청-응답 아키텍처가 붕괴되기 때문에 이미 이런 기계 장치가 필요했다.

Agents API vs Responses API vs Agents SDK vs Codex App Server

누가 루프를 소유하는지의 문제다:

옵션	누가 에이전트 루프를 실행하는가	세션/컨텍스트 책임	실행 환경	최적 활용
Responses API	당신의 애플리케이션	대부분 당신의 애플리케이션	당신의 인프라/도구	짧은 또는 커스텀 모델 워크플로
Agents SDK	당신의 애플리케이션	SDK + 당신의 런타임	당신의 인프라	코드 수준 오케스트레이션 제어가 필요한 팀
Codex App Server	당신이 Codex 하네스를 실행	당신의 환경에서의 Codex 하네스	보통 로컬 또는 당신의 컴퓨트	Codex를 제품/IDE에 직접 내장
Agents API	OpenAI	OpenAI 관리 내구성 하네스	OpenAI 호스팅, 셀프 호스팅, 파트너 샌드박스	장기 실행 관리형 클라우드 에이전트

중요한 경계선은 네 가지 모두 모델을 호출할 수 있다는 점이 아니다. 개발팀이 에이전트 제어 평면(agent control plane) 자체를 운영하고 싶은지 여부다.

새로운 아키텍처: 하네스와 샌드박스가 분리됨

가장 중요한 설계 결정 중 하나는 하네스(제어 평면)와 샌드박스(실행 환경)의 분리다.

Your product
  v
Agents API  +-- 내구성 세션
            +-- 에이전트 루프
            +-- 컨텍스트 관리
            +-- 도구 오케스트레이션
            +-- 서브 에이전트 조율
            +-- 복구
  v
실행 환경   +-- OpenAI 호스팅 샌드박스
            +-- 당신의 서버 / VPC
            +-- Cloudflare
            +-- E2B
            +-- Modal
            +-- Vercel
            +-- 기타 지원 제공자

OpenAI가 하네스를 호스팅하고 발전시킨다. 개발자는 코드가 실행되고 파일이 저장되는 위치를 여전히 결정할 수 있다. OpenAI의 출시 발표에는 Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel이 샌드박스 생태계 파트너로 나열된다.

이것이 전략적으로 중요한 이유다. OpenAI가 모든 에이전트 워크로드가 OpenAI VM 내에서 실행되어야 한다고 요구하지 않는다. 대신 Codex 하네스를 교체 가능한 실행 제공자 위에 위치할 수 있는 제어 평면으로 포지셔닝한다.

이는 친숙한 클라우드 패턴과 유사하다: 한 회사가 오케스트레이션을 소유하고 컴퓨트는 이식 가능하게 유지.

장기 세션과 자동 컨텍스트 압축

컨텍스트 창은 역사적으로 자율 에이전트에서 가장 덜 보이면서도 가장 중요한 제약 중 하나였다.

순진한 장기 실행 에이전트는 보통 두 가지 방식 중 하나로 실패한다:

모든 이벤트를 계속 추가하여 컨텍스트가 너무 커진다.
중요한 요구사항, 파일 경로, 결정, 중간 결과를 결국 잃어버리는 자체 요약 전략을 구현한다.

Agents API는 이 책임을 관리형 하네스로 이동시킨다. OpenAI는 하네스가 컨텍스트 압축을 관리하며 개발자가 자체 압축 로직을 구현하지 않고도 에이전트가 여러 컨텍스트 창에서 작동할 수 있다고 설명한다.

개념적으로 런타임은 이렇게 작동할 수 있다:

컨텍스트 창 A
  v
관리형 압축
  +-- 보존된 목표
  +-- 핵심 결정
  +-- 중요 도구 상태
  +-- 관련 산출물
  v
컨텍스트 창 B
  v
관리형 압축
  v
컨텍스트 창 C

그렇다고 컨텍스트 관리가 마법처럼 완벽해지는 것은 아니다. 압축은 여전히 유용한 세부 정보를 잃을 수 있으며, 장기 작업은 중요한 상태를 파일, 데이터베이스, 구조화된 산출물에 지속해야 한다.

하지만 일반적인 메커니즘을 누가 소유하는지가 바뀐다. 많은 팀에게 이는 구축, 벤치마크, 유지해야 할 인프라 계층이 하나 줄어든다는 의미다.

내구성 세션이 실패 모델을 바꾼다

내구성 에이전트 세션은 단순한 대화 기록 이상이다.

애플리케이션이 에이전트 작업을 단일 HTTP 응답이 아닌 계속 진행 중인 작업으로 취급할 수 있게 한다. OpenAI의 문서는 세션 상태가 유지되어 대화 컨텍스트를 재구성하지 않고도 여러 턴에 걸쳐 작업을 계속할 수 있다고 설명한다.

이로 인해 다음과 같은 워크플로가 가능해진다:

로그가 도착하는 동안 계속되는 사고 조사
여러 파일에 걸친 코드 마이그레이션
여러 독립 조사로 확장되는 리서치
승인을 위해 일시 중지하는 문서 검토
중간 산출물을 생성하는 데이터 분석
환경 재연결 후 재개되는 운영 에이전트

아키텍처적 함의가 중요하다: 클라이언트가 더 이상 에이전트 진행 상황의 신뢰성 책임자(source of truth)가 아니다. 이것은 OpenAI가 Codex Web을 설명할 때 문서화한 것과 동일한 교훈이다. 브라우저 탭이 사라지고, 네트워크가 끊기고, 사용자가 나중에 다시 연결할 수 있으므로 장기 실행 작업 상태는 서버 측에 살아야 한다.

네이티브 멀티 에이전트 오케스트레이션

멀티 에이전트 시스템은 종종 애플리케이션 수준의 접착제 코드로 구현되어 왔다:

메인 에이전트 -> 작업 A 생성 -> 작업 B 생성 -> 작업 C 생성
-> 워커 실행 -> 워커 폴링 -> 출력 수집 -> 실패 해결 -> 답변 합성

Agents API는 위임을 일급 기능으로 만든다. 개발자는 멀티 에이전트 동작을 활성화하고 max_concurrent_subagents를 설정할 수 있다. OpenAI는 조정자를 제외하고 최대 6개의 동시 서브 에이전트를 기본 제한으로 문서화한다.

{
  "multi_agent": {
    "enabled": true,
    "max_concurrent_subagents": 3
  }
}

각 서브 에이전트는 자체 컨텍스트를 유지하는데, 이는 병렬 워커들이 모든 중간 세부 정보로 서로를 오염시킬 필요가 없기 때문에 중요하다. 조정자는 전체 작업과 최종 합성에 대한 책임을 유지한다.

실행 환경이 첨부되면 조정자와 서브 에이전트는 자동으로 별도 샌드박스를 받는 대신 그 환경의 파일 시스템을 공유한다. OpenAI는 서브 에이전트 생성이 다른 환경을 생성하지 않는다고 명시적으로 문서화한다.

이것은 유용하면서도 위험하다. 유용함은 워커들이 큰 작업 공간을 복제하지 않고 공유 파일을 통해 협업할 수 있다는 점이다. 위험한 점은 병렬 에이전트들이 동일한 파일이나 리소스를 수정할 수 있다는 점이다. 따라서 프로덕션 시스템은 동시 쓰기가 가능할 때 명확한 파일 소유권, 작업 디렉터리, 잠금, 또는 작업 분할을 설계해야 한다.

도구 검색이 멀티 에이전트만큼 중요할 수 있다

도구 검색(Tool Search)은 에이전트가 등록된 모든 도구 정의를 매번 로드하지 않고 필요한 도구만 가져온다. 도구 수가 늘어날수록 컨텍스트 팽창을 억제하는 데 도움이 된다.

샌드박스 옵션 상세

OpenAI 호스팅 샌드박스

Linux 환경 제공, Python, Node.js, 파일, 패키지 설치, 명령줄 도구 포함. 작업 디렉터리는 /workspace. 패키지, 초기화 명령, 입력 파일, 환경 변수, 스킬, 플러그인으로 구성 가능. 각 세션은 자체 독립 작업 공간을 가지며, 샌드박스가 존재하는 동안 파일이 턴 간에 지속된다. /workspace/outputs에 배치된 산출물은 턴 완료 시 불변 출력물로 게시되며, 샌드박스가 만료된 후에도 검색 가능하다.

아웃바운드 네트워크: enabled(기본), disabled(완전 차단), restricted(정확한 일치 호스트명 1~100개 허용) 중 선택. 프로덕션 설계에서는 허용 대상 목적지를 사전에 제한해야 한다.

셀프 호스팅

자체 환경에서 codex exec-server 실행. 제한 키로 등록하고 WebSocket으로 연결. 모든 연결은 아웃바운드. 세션 상태는 API 측에 유지된다.

파트너 샌드박스

Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel이 1차 통합 제공. Cloudflare 예시: Cloudflare Worker가 서명된 OpenAI 웹훅을 수신하고, Durable Object를 통해 세션별 Container에 연결. Container 내에서 codex exec-server와 생성된 코드가 실행되고, 작업 공간은 Cloudflare 계정 측에 유지된다.

비용 구조 (3계층)

OpenAI는 Agents API 자체에 대한 추가 서비스 요금이 없다고 발표했다. 이는 API 사용에 대한 마크업이 없다는 뜻이지, 전체 실행 비용이 토큰 비용으로만 제한된다는 뜻은 아니다.

청구 계층	대상	공식 문서상 처리
모델	입출력 또는 캐시된 토큰	선택한 모델의 API 가격
OpenAI 도구	웹 검색 등	도구별 표준 가격
호스팅 샌드박스	Shell, Code Interpreter용 컨테이너	용량 및 런타임 기준 표준 컨테이너 가격

2026년 9월 11일 기준 공식 가격 페이지:

호스팅 Shell 및 Code Interpreter 컨테이너 요금 (20분 세션 컨테이너당): 1GB $0.03, 4 GB$ 0.12, 16GB $0.48, 64 GB$ 1.92
적용 가능한 세션은 분당 청구, 5분 최저 요금 명시
웹 검색: 1,000쿼리당 $10, 검색 콘텐츠 관련 토큰에 모델 요금 추가

즉, 총비용은 선택한 모델, 호출된 도구, 컨테이너 용량, 실행 시간에 따라 달라진다. 장기 세션이나 서브 에이전트가 성공률을 높이더라도 처리량이 증가하면 청구액이 늘어날 수 있다. 반대로 도구 결과를 좁히거나 적절히 노동을 분담하여 재시도를 줄이면 총비용이 감소할 수 있다. 비교해야 할 것은 토큰 단위당 가격이 아니라 성공률, 작업 완료 시간, 모델/도구/환경 비용의 결합 총합이다. 자체 인프라나 파트너에서 실행하는 경우 해당 환경에 대한 별도 요금도 적용된다.

데이터 거주지와 보안 책임

Agents API의 세션 상태는 실행 환경을 자체 인프라에 배치해도 API 측에 유지된다. OpenAI 개요 문서에 따르면 2026년 9월 11일 기준 데이터 거주지(data residency)는 미국으로만 제한되며 Zero Data Retention(ZDR)을 지원하지 않는다. 사용자는 세션과 게시된 산출물을 삭제할 수 있지만, 규제 지역이나 저장 금지 요구사항이 있는 조직은 실행 환경을 셀프 호스팅하는 것만으로 요구사항을 충족한다고 가정할 수 없다.

또 다른 경계는 에이전트가 생성하고 실행하는 코드에 관한 것이다. 그 코드는 실행 환경에 배치된 파일, 자격증명, 허용된 모든 네트워크에 접근할 수 있다. OpenAI 호스팅 환경에서 템플릿 정책을 상속하지 않으면 아웃바운드 네트워크 접근이 enabled로 시작된다. disabled(완전 차단), restricted(정확한 일치 호스트명 1~100개 허용) 중 선택 가능 — 프로덕션 설계에서는 허용 대상 목적지를 사전에 제한해야 한다.

자격증명도 목적별로 분리해야 한다. OpenAI는 애플리케이션의 API 키를 실행 환경 외부에 유지하고, 환경 연결에 사용되는 제한 키를 분리할 것을 권고한다. 서드파티 서비스 자격증명 가능하면 브로커를 통해 주입해야 한다. Cloudflare 예시에서도 모델 읽기와 환경 연결만 허용하는 실행 키가 세션 상태를 읽는 애플리케이션 키와 분리된다.

공공 베타 동안 확인할 운영 조건

공개 자료에서 확인되지 않는 항목:

일반 출시(GA) 일정
공식 SLA 보장
실패 시 복구 보장
세션 최대 수명
미국 외 데이터 거주지 또는 ZDR 제공 시기

따라서 도입 결정은 확인해야 할 제공자 조건과 자체 워크로드에 대해 직접 측정할 수 있는 성능 지표를 구분해야 한다.

시험 실행에서 측정 가능한 항목:

장기 실행 세션 완료율
압축 후 조건 보존율
연결 끊김 또는 도구 실패 후 재개 성공률
멀티 에이전트 구성: 단일 에이전트 대비 지연 시간, 총 토큰, 도구 사용량, 공유 파일 충돌 횟수 기록

OpenAI의 고객 사례 연구는 개선된 평가 점수와 감소된 지연 시간을 언급하지만 비교 조건과 샘플 크기가 공개되지 않아 이 수치를 자체 기대치에 직접 적용할 수 없다.

반면 공식 SLA, 데이터 거주지 지역, 삭제/감사 조건은 실험으로 확인할 수 없다. 조직은 먼저 필수 요구사항을 정의한 다음, 현재 공공 베타가 제공하지 않는 조건에 해당하는 사용 사례를 식별해야 한다.

출처: AI IDE List (2026-09-12) — raw/articles/2026-09-13-aiidelist-agents-api-deep-dive.md

description	Codex 하네스가 관리형 클라우드 인프라가 된 의미, 하네스-샌드박스 분리 아키텍처, 비용 3계층, 데이터 거주지/ZDR 제약, 운영 조건 확인 방법을 심층 분석한 2026년 9월 12일 기사 요약.
tags	ai-agents, summary, openai, agents-api, harness, sandbox, architecture, cost, data-residency, zdr

LLM Wiki

탐색기

AI IDE List: Agents API 심층 분석 — 요약