OpenAI 에이전트 API, 관리형 Codex 하니스를 클라우드로 열다

OpenAI가 '에이전트 API(Agents API)'를 공개하며, 그동안 코딩 도구 Codex 안에서 돌아가던 에이전트 실행 엔진을 외부 애플리케이션이 직접 호출할 수 있는 관리형 API 형태로 개방했다. 핵심은 'Codex 하니스(harness)'를 OpenAI가 클라우드에서 운영하고, 개발자는 그 위에 자신의 도구와 실행 환경만 얹으면 되는 구조다. 지금까지 자율 에이전트를 만들려면 세션 관리, 여러 단계에 걸친 작업 조율, 길어지는 대화 맥락의 압축, 중간 실패 시 복구 같은 골치 아픈 문제를 애플리케이션이 스스로 떠안아야 했다. 에이전트 API는 바로 이 부분을 OpenAI가 대신 책임진다는 점에서 성격이 뚜렷하다.

OpenAI가 맡는 것과 개발자가 맡는 것

역할 분담이 이 서비스를 이해하는 열쇠다. OpenAI는 세션, 오케스트레이션, 컨텍스트 압축(compaction), 그리고 복구를 관리한다. 반면 애플리케이션은 에이전트가 사용할 도구를 제공하고, 어떤 실행 환경에서 돌릴지를 고른다. 에이전트는 샌드박스 안에서 코드를 실행하고 파일을 편집하며, MCP(Model Context Protocol) 서버에 연결하고 결과물(artifact)을 만들어낼 수 있다. 즉 단순히 텍스트를 생성하는 모델 호출이 아니라, 실제로 무언가를 '실행하고 만들어내는' 작업 단위를 위임하는 그림에 가깝다.

OpenAI가 호스팅하는 세션을 쓰는 경우 흐름은 더 단순해진다. 애플리케이션은 입력을 보내고 이벤트를 돌려받으며, 에이전트를 돌리고 샌드박스를 프로비저닝·관리하는 일은 OpenAI가 담당한다. 개발자 입장에서는 인프라를 직접 띄우지 않고도 실행형 에이전트를 붙일 수 있다는 뜻이다. 다만 문서는 환경 옵션에 따라 설정 방법과 제약이 달라진다고 명시하고 있어, 실제 도입 시에는 환경별 한계를 먼저 확인해야 한다.

상태 유지와 과금 구조

실무적으로 눈여겨볼 대목은 세션 상태가 유지된다는 점이다. 에이전트 API는 세션 상태를 보존하기 때문에 한 턴이 끝난 뒤 다음 작업으로 넘어갈 때 대화 맥락을 처음부터 다시 쌓을 필요가 없다. 긴 작업을 여러 차례에 나눠 이어가야 하는 시나리오에서 개발 부담을 줄여주는 요소다. 더 이상 필요 없어진 세션과 게시된 결과물은 삭제할 수 있어, 데이터 정리 측면의 통제권도 일정 부분 제공된다.

비용 계산은 여러 항목으로 쪼개진다. 모델 사용료는 선택한 모델의 API 요율로 부과되고, OpenAI가 제공하는 도구는 각각의 표준 요율을, OpenAI가 호스팅하는 샌드박스는 표준 컨테이너 요율을 따른다. 결국 하나의 에이전트 실행에는 모델 토큰 비용, 도구 사용 비용, 샌드박스 실행 비용이 겹쳐서 쌓인다는 의미다. 자율 에이전트는 스스로 여러 번의 도구 호출과 코드 실행을 반복하는 특성이 있어, 실제 운영 비용을 예측하려면 이 세 축을 함께 놓고 봐야 한다.

데이터 거버넌스가 실제 제약

국내 도입을 검토하는 입장에서 가장 민감한 부분은 데이터 통제 조건이다. 에이전트 API는 현재 데이터 레지던시(data residency)를 미국에서만 지원하며, 제로 데이터 보존(ZDR, Zero Data Retention)은 지원하지 않는다. 문서는 나아가 자체 호스팅 샌드박스를 선택하더라도 에이전트 API가 ZDR 대상이 되지는 않는다는 점을 분명히 못 박고 있다. 데이터를 국내에 두어야 하거나 처리 후 즉시 파기를 요구하는 규제·계약 조건이 걸린 조직이라면, 실행 환경을 자체적으로 두는 것만으로는 이 요건을 우회할 수 없다는 뜻이다.

정리하면 에이전트 API는 실행형 에이전트를 만들기 위한 반복적인 인프라 작업을 OpenAI에 넘기고, 개발자는 도구와 실행 환경 선택에 집중하도록 설계된 서비스다. 세션 지속성과 샌드박스 실행이라는 강점이 뚜렷한 만큼, 데이터 레지던시가 미국으로 한정되고 ZDR이 불가능하다는 점은 뒤집기 어려운 전제 조건이다. 파일럿을 계획한다면 기능적 유용성과 별개로, 조직의 데이터 거버넌스 정책이 이 조건과 충돌하지 않는지를 가장 먼저 따져보는 편이 순서에 맞다.