OpenAI Agents API 출시: Codex 하네스를 API 한 번으로 빌리는 시대

결론부터 말하자. OpenAI는 이번에 새로운 에이전트 프레임워크를 하나 더 내놓은 것이 아니다.

에이전트가 며칠 동안 일하고, 도구를 고르고, 실패에서 복구하고, 다른 에이전트에게 일을 나누는 운영체제를 클라우드 서비스로 만들었다.

2026년 9월 10일 공개된 OpenAI Agents API의 설명은 짧다. Codex를 움직이는 하네스와 인프라를 API로 제공한다는 것이다. 그런데 이 문장을 개발자의 언어로 번역하면 꽤 많은 서버와 상태 관리 코드가 사라진다. 모델 호출 반복문, 장기 세션 저장, 컨텍스트 압축, 샌드박스 준비, 작업 재개, 도구 검색, 서브에이전트 조율을 OpenAI가 관리하기 때문이다.

그래서 이번 발표에서 가장 중요한 질문은 “에이전트를 얼마나 쉽게 만들 수 있나?”가 아니다.

API 한 번으로 편해진 만큼, 우리 시스템의 어느 부분을 OpenAI에 맡기게 되는가?

한 번의 호출 안에 사라진 서버들

공식 예제의 핵심을 줄이면 대략 이런 모양이다.

1
2
3
4
5
6
7
8
9
10
11
const session = await client.beta.agents.sessions.c
![exec-f1bccb0f-b77c-4eef-8781-2a3dfac1d141.png](https://res.cloudinary.com/dcfqahfbr/image/upload/v1789195934/cvlog/posts/mknxyof4anzkjsp7db62.png)
reate({
  agent: {
    model: "gpt-6-astra",
    tools: [observabilityMcp],
    multi_agent: { enabled: true, max_concurrent_subagents: 3 },
  },
  environment: { type: "openai_hosted" },
  input: "최근 30분간 5xx 오류 상승 원인을 조사해 줘.",
});

코드만 보면 모델, 도구, 실행 환경과 작업을 넘긴 것이 전부다. 하지만 sessions.create() 뒤에서는 네 종류의 상태가 움직인다.

Agent는 모델과 지시사항, 도구, MCP 서버를 묶는다. Environment는 에이전트가 파일을 읽고 명령을 실행하는 작업 공간이다. Session은 한 번 답하고 사라지는 요청이 아니라, 다음 입력을 받아 계속 일할 수 있는 장기 실행 단위다. Events와 items는 진행 상황과 결과, 사용자 개입이 필요한 순간을 애플리케이션으로 전달한다.

기존에는 팀이 이 네 요소를 직접 접착했다. 모델이 낸 도구 호출을 파싱하고, 작업 큐에 넣고, 컨테이너를 깨우고, 중간 결과를 데이터베이스에 저장한 뒤, 타임아웃이 발생하면 어디서 재개할지 결정했다. 컨텍스트가 길어지면 무엇을 버리고 무엇을 요약할지도 구현해야 했다.

Agents API는 그 접착층을 관리형 Codex 하네스로 가져간다. OpenAI 문서에 따르면 이 하네스는 샌드박스 명령 실행, 스킬과 지시사항 적용, MCP 연결, 실행 중 방향 수정, 컨텍스트 압축, 서브에이전트 위임, 중단된 세션 재개를 담당한다.

하네스 엔지니어링이 왜 중요해졌는지를 설명하던 단계에서, 이제는 그 하네스 자체가 구매 가능한 클라우드 제품이 된 셈이다.

OpenAI가 맡는 것과 끝까지 우리가 맡는 것

관리형 서비스가 등장하면 경계가 흐려지기 쉽다. “OpenAI가 에이전트를 운영해 준다”는 말이 “OpenAI가 업무 결과까지 책임진다”는 뜻은 아니다.

OpenAI가 맡는 쪽은 실행의 연속성이다. 세션을 유지하고, 필요한 도구 정의를 불러오며, 긴 작업의 컨텍스트를 압축하고, 여러 서브에이전트의 실행을 조율한다. OpenAI 호스팅 샌드박스를 고르면 코드 실행과 파일 작업을 위한 환경도 준비한다.

개발자에게 남는 쪽은 업무의 의미와 권한이다. 어떤 MCP 서버를 연결할지, 도구가 무엇을 읽고 변경할 수 있는지, 어느 행동에서 사람의 승인을 받을지, 결과를 무엇으로 검증할지는 애플리케이션이 정해야 한다. 잘못된 환불, 배포, 데이터 삭제를 막는 규칙은 sessions.create()가 대신 발명해 주지 않는다.

이 경계는 에이전트 제품의 경쟁력을 바꾼다. 모두가 비슷한 하네스를 사용할 수 있다면 차별화는 반복문이 아니라 다음 네 곳으로 이동한다.

도구가 반환하는 데이터의 품질. 조직의 업무 규칙을 담은 스킬. 실패를 잡아내는 평가. 사용자가 안심하고 개입할 수 있는 승인 화면.

모델과 하네스가 범용화될수록, 회사 내부에만 존재하는 업무 맥락과 검증 기준이 더 비싼 자산이 된다.

샌드박스를 직접 운영해도 모든 것이 내 서버에 남는 것은 아니다

Agents API는 실행 환경을 고를 수 있다. 빠르게 시작하려면 OpenAI 호스팅 샌드박스를 쓰고, 자체 인프라나 파트너 샌드박스를 연결할 수도 있다. 공식 발표에는 Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel 등이 통합 파트너로 제시됐다.

여기서 쉽게 생기는 오해가 있다.

자체 샌드박스를 연결하면 에이전트 전체가 자체 호스팅되는 것 아닐까?

그렇지 않다. 자체 샌드박스는 에이전트가 코드를 실행하고 파일을 다루는 실행 장소를 선택하는 것이다. 세션, 오케스트레이션, 컨텍스트 관리와 복구를 수행하는 관리형 하네스는 여전히 Agents API의 영역이다.

데이터 정책에서도 이 차이는 중요하다. 현재 공식 문서는 Agents API가 미국 데이터 레지던시만 지원하며 Zero Data Retention, 즉 ZDR을 지원하지 않는다고 명시한다. 자체 호스팅 샌드박스를 선택해도 Agents API 전체가 ZDR 대상이 되지는 않는다.

따라서 소스 코드나 고객 문서를 다루는 팀은 “컨테이너가 어디서 실행되는가”만 물어서는 안 된다. 어떤 입력과 이벤트가 세션 상태에 저장되는지, 산출물은 어디에 남는지, 삭제 정책은 무엇인지, 연결한 MCP 도구가 데이터를 어디로 보내는지까지 나눠서 검토해야 한다.

이것은 작은 주석이 아니다. 편의성을 위해 관리형 하네스를 선택할지, 데이터 통제를 위해 더 많은 실행 계층을 직접 운영할지 결정하는 핵심 조건이다.

무료 API라는 문장 뒤에 숨어 있는 비용

OpenAI는 Agents API 자체에 별도 사용료가 없다고 설명한다. 대신 선택한 모델의 토큰, 사용한 OpenAI 도구, OpenAI 호스팅 샌드박스의 컨테이너 비용을 지불한다.

“추가 비용 없음”과 “에이전트 실행이 저렴함”은 전혀 다른 문장이다.

서브에이전트 세 개가 병렬로 저장소를 조사하면 대기 시간은 짧아질 수 있지만 모델 호출량은 늘 수 있다. 세션이 며칠 동안 유지되면 재시작 비용은 줄어도 샌드박스 수명과 저장 비용을 관리해야 한다. Tool search와 컨텍스트 압축은 불필요한 토큰을 줄일 수 있지만, 잘못 설계된 도구가 큰 응답을 계속 반환하면 절약분은 금세 사라진다.

비용은 요청 한 번이 아니라 검증을 통과한 업무 한 건으로 계산해야 한다.

1
2
완료된 업무의 비용 =
모델 + 도구 + 샌드박스 + 재시도 + 사람의 검수 시간

출시 페이지의 고객 사례에는 평가 점수 상승, 지연시간 감소, 케이스당 비용 절감 같은 수치가 등장한다. 참고할 만한 신호지만 공급사가 고른 초기 고객의 결과다. 내 워크로드에서도 같은 개선이 일어난다고 가정하면 안 된다. 기존 하네스와 Agents API에 동일한 작업·도구·시간 제한·승인 규칙을 주고, 성공률과 총비용을 함께 비교해야 한다.

이 API가 위협하는 것은 LangChain이 아니라 사내 접착 코드다

Agents API를 보면 곧바로 “이제 어떤 에이전트 프레임워크가 필요 없어지는가?”라는 질문이 나온다. 하지만 더 직접적인 경쟁 상대는 유명 오픈소스 이름이 아니다.

각 회사가 지난 1~2년 동안 임시로 쌓아 올린 작업 큐, 도구 라우터, 세션 테이블, 요약 프롬프트, 컨테이너 관리 스크립트다.

그 코드가 회사의 고유한 업무 규칙을 담고 있다면 유지할 가치가 있다. 반대로 모델 호출을 다시 시도하고 긴 대화를 잘라 저장하는 범용 접착제라면, 관리형 하네스와 계속 경쟁해야 할 이유가 약해진다. Agents API의 진짜 판매 문구는 “에이전트를 만들기 쉽다”가 아니라 **“범용 운영 문제를 다시 만들지 않아도 된다”**에 가깝다.

그렇다고 당장 전부 이전할 필요는 없다. 아직 public beta이고 API와 지원 기능이 바뀔 수 있다. 먼저 되돌릴 수 있는 내부 업무 하나를 고르는 편이 낫다. 읽기 전용 도구만 연결하고, 기존 시스템과 같은 평가 세트를 실행한다. 성공률뿐 아니라 재개 정확도, 컨텍스트 손실, 승인 대기, 도구 호출 수, 작업 한 건당 비용을 비교한다.

Assistants API에서 Responses API로 이동할 때 객체 이름만 바꾸는 것으로 충분하지 않았던 것처럼, 이번에도 핵심은 새 엔드포인트가 아니다. 우리 팀이 더 이상 직접 운영하지 않을 상태가 무엇인지 결정하는 일이다.

처음의 짧은 API 호출로 돌아가 보자. 몇 줄의 코드가 인상적인 이유는 적어서가 아니다. 그 뒤에 있던 수많은 접착 코드와 운영 책임이 보이지 않게 됐기 때문이다.

OpenAI Agents API는 에이전트를 하나 더 만드는 도구가 아니다. 에이전트가 계속 일하게 만드는 방법을 서비스로 파는 제품이다. 이제 개발자가 내려야 할 결정은 모델을 고르는 것보다 더 어렵다.

어디까지 빌리고, 어디부터 직접 책임질 것인가.