에이전트를 직접 만들다 보면 모델 호출 자체보다 그 다음 일이 오래 남는다. 도구 결과를 다시 맥락에 넣고, 긴 작업의 상태를 유지하고, 실패한 명령을 어떻게 처리할지 정해야 한다. OpenAI가 9월 10일 공개 베타로 선보인 Agents API는 이 주변 작업의 일부를 관리형 서비스로 가져온다. Codex 하네스를 OpenAI가 운영하고, 세션과 맥락 압축, 하위 에이전트 조율을 제공하는 방식이다.
이번 변화는 새 모델 발표와는 성격이 다르다. 모델을 바꾸지 않아도 에이전트의 실행 루프를 누가 운영하는지가 달라진다. 그래서 도입 판단도 벤치마크 점수보다 먼저, 우리 팀이 더 이상 맡지 않아도 되는 일과 계속 맡아야 하는 일을 나눠 보는 편이 낫다.
Agents API가 관리하는 범위
공식 문서는 Agents API를 장기 작업용 관리형 Codex 하네스라고 설명한다. 하네스는 모델의 다음 답변을 받는 데서 멈추지 않고, 도구 호출과 결과 재입력, 작업 단계, 맥락 관리를 이어 주는 실행 루프다. 이 API에서는 OpenAI가 해당 루프와 세션 인프라를 관리한다.
문서에 따르면 자동 맥락 압축, 다중 에이전트 조율, 프로그램 방식의 도구 호출, MCP 서버 지원이 포함된다. 긴 조사 작업에서 이전 대화를 압축하거나, 여러 독립 점검을 나눠 실행하거나, 너무 큰 도구 목록을 필요한 때만 불러오는 문제를 서비스 기능으로 다루겠다는 뜻이다.
다만 이는 애플리케이션이 알아서 완성된다는 의미는 아니다. Agents API의 세션에는 에이전트 구성과 대화 턴, 입출력 항목이 저장되지만, 업무의 정답 기준과 승인 절차까지 대신 정해 주지는 않는다. 예를 들어 장애 조사 에이전트가 여러 로그를 모아도, 배포 중단 권한을 줄지와 어느 증거가 있어야 사람에게 넘길지는 사용자가 설계해야 한다.
관리형 하네스와 샌드박스는 다른 선택이다
처음 볼 때 가장 헷갈리기 쉬운 부분은 하네스와 실행 환경이다. Agents API를 선택하면 하네스는 OpenAI가 관리한다. 반면 명령과 파일, 패키지가 있는 실행 환경은 OpenAI 호스팅 샌드박스, 직접 운영하는 환경, 파트너 샌드박스 가운데 고를 수 있고, 샌드박스 없이 원격 도구만 쓰는 구성도 가능하다.
즉 자체 서버에서 명령을 실행한다고 에이전트 전체가 자체 운영으로 바뀌는 것은 아니다. OpenAI가 세션과 모델·도구 루프를 운영하는 구조는 남는다. 반대로 OpenAI 호스팅 샌드박스를 쓴다고 해서 파일의 장기 보존이나 외부 시스템의 변경 책임까지 서비스가 가져가는 것도 아니다.
독립 분석들은 이 구분을 꽤 구체적으로 짚는다. 자체 호스팅 환경이 작업 중 끊기면 도구 실행이 실패할 수 있고, 다시 연결했다고 중단된 명령이 자동으로 이어지지는 않는다. 교체된 컴퓨팅 환경에 이전 파일이 복구된다고 가정할 수도 없다. 장기 작업이라면 세션 ID와 별개로 결과물·중간 산출물·재시도 근거를 어디에 남길지 정해야 하는 이유다.
비용과 데이터 경계도 ‘관리형’이라는 말로 묶지 말 것
공개 베타에는 별도의 Agents API 이용료가 없다고 안내된다. 그렇다고 비용이 없다는 뜻은 아니다. 모델 토큰, 사용한 도구, 호스팅 컨테이너와 외부 실행 환경의 비용이 합쳐진다. 하위 에이전트를 병렬로 쓰면 완료 시간은 줄어들 수 있지만, 총 토큰과 도구 호출은 오히려 늘 수 있다.
따라서 월간 토큰 예산만 보는 방식은 부족하다. 한 건의 업무가 승인 가능한 결과에 도달할 때까지 든 비용을 재야 한다. 조정 에이전트와 하위 에이전트의 토큰, 도구 호출, 실패 재시도, 샌드박스가 살아 있던 시간을 한 묶음으로 기록하면 비교가 쉬워진다.
데이터도 같은 방식으로 분해해야 한다. 조사 대상 문서가 어느 환경에 놓이는지, 도구가 어떤 외부 API에 전달하는지, 출력과 로그를 누가 보관하는지를 따로 적는다. MarkTechPost의 정리는 출시 시점에서 US 데이터 레지던시와 Zero Data Retention 미지원이 규제 환경의 제약이 될 수 있다고 지적한다. 이 내용은 서비스 정책이 바뀔 수 있으므로 실제 도입 전 최신 약관과 지역·계정 조건을 다시 확인해야 한다.
작게 검증할 작업을 고르는 기준
처음부터 고객 데이터와 쓰기 권한을 연결할 이유는 없다. 읽기 전용으로 끝나고, 사람이 결과를 판정할 수 있으며, 중간 실패가 큰 손실로 이어지지 않는 일을 하나 고르는 편이 좋다. 예를 들면 여러 운영 문서에서 변경 사항을 찾아 출처와 함께 보고서 초안을 만드는 작업이 적합하다.
여기서 확인할 것은 모델의 말솜씨만이 아니다. 세션을 이어 갔을 때 이전 판단의 근거가 필요한 만큼 남는지, 맥락 압축 뒤에 필수 제약이 사라지지 않는지, 하위 에이전트가 같은 파일을 건드릴 때 충돌이 없는지 살핀다. 하위 에이전트는 각자 맥락을 가질 수 있어도 환경의 파일시스템까지 자동으로 분리되는 것은 아니라는 분석도 있다.
작게 해볼 수 있는 세 가지
- 읽기 전용 과제 하나를 고른다. 문서 비교, 장애 징후 요약, 변경 이력 확인처럼 외부 시스템을 바꾸지 않는 과제로 시작한다.
- 완료 조건을 문장으로 먼저 쓴다. 결과에 포함할 출처, 확인하지 못한 항목의 표시, 사람 검토가 필요한 조건을 정한 뒤 같은 과제를 기존 방식과 비교한다.
- 세션 밖의 기록을 남긴다. 입력, 사용 도구, 생성된 파일 위치, 실패와 재시도 사유, 최종 승인 여부를 별도 저장소에 기록한다. 세션 지속 기능을 감사 기록으로 착각하지 않기 위해서다.
도입 판단은 ‘얼마나 덜 만들게 됐나’에서 시작한다
Agents API의 실용성은 에이전트를 한 번의 API 호출로 시작할 수 있다는 데만 있지 않다. 팀이 직접 만들던 세션 관리와 도구 조율의 일부를 줄이면서도, 실행 환경과 업무 권한은 필요한 만큼 통제할 수 있다는 데 있다.
하지만 관리형 하네스는 운영 책임의 이동이지 소멸이 아니다. 권한을 가진 도구, 파일의 지속성, 결과 검토, 비용 상한은 애플리케이션의 경계에 남는다. 그래서 이 API를 도입할 때는 ‘에이전트를 더 쉽게 만들 수 있는가’보다 ‘우리의 실패 기록과 승인 흐름이 이 실행 방식에서도 유지되는가’를 먼저 확인하는 편이 안전하다.
공개 베타 단계인 만큼 성능·비용·정책을 일반화하기는 이르다. 작은 읽기 전용 과제에서 완료율, 사람 검토 시간, 총비용, 재실행 가능성을 함께 기록해 보면 관리형 런타임이 실제 병목을 줄이는지 판단할 수 있다.