Agents API가 맡는 실행과 애플리케이션의 업무 규칙

공식 문서를 바탕으로 만든 구조 모식도다. 코드·파일 실행 환경은 필요에 따라 선택하며, 애플리케이션의 업무 권한과 결과 검토 기준은 별도로 정해야 한다. 성능 측정 그래프가 아니다.

OpenAI는 2026년 9월 10일 Agents API를 공개 베타로 발표했다. Codex의 에이전트 실행 기반을 개발자 애플리케이션에서 이용하는 API다. 이번 글은 9월 14일 확인한 공식 발표와 개발자 문서를 바탕으로, 어떤 운영 부담을 맡길 수 있고 무엇을 직접 설계해야 하는지 살펴본다. 실제 서비스에 연결한 성능 실험은 하지 않았다. 공식 발표

판단의 출발점은 모델 이름보다 작업의 형태다. 질문 한 번에 답변 하나를 받는 기능과, 파일을 읽고 도구를 사용하다가 다음 요청에서 일을 이어가는 기능은 필요한 운영 구조가 다르다. 기존 서비스에서 어느 부분에 시간이 많이 드는지 먼저 적어 보면 이번 API의 필요성을 더 분명하게 평가할 수 있다.

모델 호출에서 세션 운영으로

공식 개요는 OpenAI가 세션, 작업 조율, 컨텍스트 압축과 복구를 관리하고, 애플리케이션이 도구를 제공하며 실행 환경을 선택한다고 설명한다. 세션은 여러 입력에 걸쳐 일을 이어가는 단위다. 코드나 파일을 다루는 환경은 선택 사항이므로, 모든 요청에 컨테이너가 필수로 붙는다고 이해하면 부정확하다. Agents API 개요

하네스라는 표현은 모델이 다음 행동을 정하고, 도구 결과를 받아 작업을 계속하도록 돕는 실행 체계를 가리킨다. 공식 발표에 나온 컨텍스트 압축, 필요한 도구 정의의 탐색, 서브에이전트 지원이 여기에 포함된다. 이런 기능의 제공을 모든 작업의 정확성이나 결과 취합 성공을 보장한다는 뜻으로 확대할 수는 없다. 관리형 실행 기반 설명

예를 들어 사내 보고서 검토를 만든다고 가정하자. 첫 요청에서 문서를 읽고, 두 번째 요청에서 누락된 표를 보완하며, 마지막 요청에서 수정안을 확정할 수 있다. 이때 검토할 문서의 버전, 사용자가 승인한 수정 범위, 결과 파일의 위치를 업무 규칙으로 정의하는 일이 남는다. API가 세션을 유지하더라도 어떤 결과를 완료로 인정할지는 서비스가 정해야 한다.

실행 환경을 어디에 둘 것인가

OpenAI가 관리하는 샌드박스를 쓰거나 자체 인프라 및 지원되는 외부 제공자의 환경을 연결할 수 있다. 공식 발표는 연산 자원, 저장 방식과 배포 조건에 따라 환경을 선택하도록 설명한다. 따라서 Agents API를 도입하면 기존 사내 실행 환경을 반드시 모두 폐기해야 한다는 주장은 맞지 않는다. 환경 선택 설명

팀 내부에서 비교할 항목은 다음처럼 정리할 수 있다. 이 표는 제품의 추가 기능 목록이 아니라 도입 검토용 질문이다.

검토 항목 먼저 정할 내용 확인할 결과
입력 자료 어떤 문서와 저장소를 읽게 할 것인가 필요한 자료만 제공됐는가
실행 도구 조회와 변경 중 무엇을 허용할 것인가 허용한 행동만 수행했는가
완료 기준 초안 생성과 최종 반영을 어떻게 구분할 것인가 검토한 결과가 실제 반영됐는가
재개 방식 중단된 작업을 어떻게 식별할 것인가 같은 작업이 중복 처리되지 않았는가
운영 비용 어느 작업 단위로 사용량을 모을 것인가 성공 한 건에 든 총비용은 얼마인가

초기 비교 실험에는 입력과 정답 기준이 분명한 업무가 적합하다. 같은 문서 묶음으로 기존 방식과 새 방식을 실행하고, 완성도와 소요 시간, 사람이 수정한 부분을 함께 기록하는 방법이다. 결과가 좋았던 사례만 고르면 실제 운영에서 얼마나 유용한지 판단하기 어렵다. 자료가 빠지거나 도구가 실패한 사례도 평가 대상에 넣는 편이 낫다.

첫 연결에서 확인할 기술적 차이

퀵스타트는 beta.agents.sessions.create로 세션을 만드는 예제를 제공한다. HTTP 진입점은 POST /v1/agents/sessions이며 베타 헤더는 OpenAI-Beta: agents=v1이다. 공식 SDK는 이 헤더를 자동으로 추가하지만 직접 HTTP를 호출하면 명시해야 한다. 예제의 모델은 gpt-6-astra다. 공식 퀵스타트

문서는 환경이 준비된 뒤 작업을 실행하고, 진행 상황과 출력 이벤트를 읽는 흐름을 보여 준다. 그러므로 요청 접수 응답을 받았다는 사실과 작업 결과를 확보했다는 사실을 구분해야 한다. 사용자가 보고 있는 화면에도 시작, 진행, 입력 필요, 완료를 어떻게 보여 줄지 정해 두는 것이 좋다. 연결 예제를 그대로 실행하는 것과 사용자가 신뢰할 수 있는 업무 화면을 만드는 것은 별도의 검증 단계다. 세션 시작 예제

기존 기능을 옮길 때는 한 업무부터 적용하는 편이 비교하기 쉽다. 서비스 전체를 한 번에 바꾸면 모델, 도구 설정, 입력 문서, 실행 환경 중 무엇 때문에 결과가 달라졌는지 분리하기 어렵다. 먼저 기존 출력 형식을 유지한 채 실행 부분을 바꾸고, 차이가 확인된 다음 화면이나 업무 절차를 조정하는 접근을 제안한다.

추가 API 수수료와 총비용은 다르다

공식 발표는 공개 베타의 Agents API 사용에 추가 수수료가 없다고 안내한다. 개요 문서는 선택한 모델의 토큰 요금, 사용한 OpenAI 도구 요금, OpenAI 호스티드 샌드박스의 컨테이너 요금을 각각 설명한다. 전체 작업이 무료라는 의미는 아니다. 자체 인프라나 외부 제공자 비용도 해당 환경을 쓰는 팀이 별도로 확인해야 한다. 발표의 요금 안내 · 자원별 과금 기준

편집팀이 제안하는 비교 단위는 ‘검토를 통과한 작업 한 건’이다. 단순히 첫 답변의 토큰 수만 비교하면 실패 후 재시도나 결과 보완에 든 사용량을 놓칠 수 있다. 같은 품질 기준을 적용한 뒤 전체 실행의 모델 사용량과 도구 사용, 환경 비용을 모아 보는 것이 합리적이다. 이 글에서는 실제 청구서를 확인하지 않았으므로 비용 절감률이나 손익분기점을 제시하지 않는다.

운영 기록에는 성공 여부뿐 아니라 다시 실행한 이유도 남기는 편이 좋다. 원문이 없어서 다시 조사한 경우와 프로그램 오류로 같은 요청을 재전송한 경우는 개선 방법이 다르기 때문이다. 어느 쪽이 많은지 알아야 프롬프트를 고칠지, 자료 제공 방식을 고칠지, 실행 로직을 고칠지 결정할 수 있다.

데이터 조건과 베타 상태

9월 14일 확인한 개요 문서에는 미국 데이터 레지던시만 지원하며 Zero Data Retention, 즉 ZDR은 지원하지 않는다고 적혀 있다. 자체 호스팅 샌드박스를 선택해도 Agents API가 ZDR 대상이 되는 것은 아니다. 코드 실행 장소와 API 세션의 데이터 처리 조건을 따로 확인해야 하는 이유다. 데이터 보존과 레지던시

민감한 자료를 다루는 팀은 기존 데이터 처리 기준과 이 조건이 맞는지 먼저 확인할 필요가 있다. 이 글은 특정 법률이나 기업 내부 규정의 충족 여부를 판단하지 않는다. 도입 검토 단계에서는 실제 민감 자료를 넣기보다 공개 문서나 승인된 시험 자료로 기능과 운영 흐름을 검증하는 방법을 제안한다.

공식 발표는 공개 베타 중 피드백을 받아 서비스를 개선한다고 설명한다. 발표에 포함된 고객 사례의 개선 수치를 우리 업무의 기대 성능으로 그대로 옮기지 않는 편이 좋다. 어떤 입력과 도구, 평가 기준을 사용했는지 확인한 뒤 자기 업무에서도 같은 기준으로 비교해야 한다. 공개 베타와 고객 사례

어떤 팀이 먼저 검토하면 좋은가

여러 단계에 걸친 작업을 이미 운영하며 세션 복구와 도구 연결에 시간을 쓰는 팀이라면 검토할 이유가 있다. 반대로 짧은 응답 생성만 필요하거나, 현재 지원하는 데이터 조건이 조직의 필수 요건과 맞지 않는다면 기존 방식 유지가 합리적일 수 있다. 이는 공식 문서의 기능과 제약을 바탕으로 한 편집 의견이다.

도입 여부는 작은 비교 실험으로 결정하는 편이 명확하다. 완료 품질이 유지되는지, 사람이 개입하는 횟수가 줄어드는지, 실패 후 재개가 이해하기 쉬운지, 검토를 통과한 결과 한 건의 비용이 허용 범위인지 확인하자. Agents API가 맡는 실행 기반과 애플리케이션이 책임지는 업무 규칙을 먼저 나누면, 시도할 가치가 있는 부분과 그대로 둘 부분을 구체적으로 정할 수 있다.

출처