OpenAI Agents API 공개 베타와 실행 계약 설계

1. 이번 발표가 바꾸는 것은 모델이 아니라 실행의 기본 단위다

OpenAI는 2026년 9월 10일 Agents API를 공개 베타로 발표했다. 발표에서 말하는 핵심은 개발자가 작업, 모델, 도구, 환경을 지정해 클라우드 에이전트 세션을 만들 수 있다는 점이다. OpenAI는 Codex에 쓰이는 하니스와 인프라를 운영하고, 개발자는 OpenAI 호스팅 샌드박스·자체 인프라·파트너 샌드박스 가운데 실행 환경을 고를 수 있다. 여기서 하니스(harness)는 모델 호출, 문맥, 도구 사용, 작업 조율을 연결하는 실행 제어층을 뜻한다.

이 변화는 프롬프트 체인을 조금 더 편하게 만드는 수준으로만 읽으면 놓치는 부분이 있다. 이전에는 팀이 장기 작업을 만들 때 모델 호출 외에도 세션 보존, 파일 보관, 명령 실행, 도구 호출 순서, 실패 뒤 재개 방식을 각자 조합해야 했다. 새 API는 그 조합의 일부를 관리형 기반으로 제공한다. 그러나 관리형이라는 표현이 업무 책임까지 외부 서비스로 옮겨 준다는 뜻은 아니다. 어떤 저장소를 읽을 수 있는지, 어떤 도구가 변경을 실행할 수 있는지, 산출물을 누가 승인하는지는 여전히 제품 팀과 보안 팀이 정해야 한다.

따라서 도입 질문은 “에이전트를 만들 수 있는가”보다 “한 실행이 끝났을 때 어떤 기록을 남겨야 다음 사람이 결과를 신뢰할 수 있는가”가 되어야 한다. 모델의 답변만 남는 흐름은 작업이 길어질수록 재현하기 어렵다. 반대로 입력 범위, 사용한 도구, 생성 파일, 사람의 승인 지점을 남기면 실패한 실행도 다음 설계의 근거가 된다. 이 글에서는 이를 실행 계약이라고 부른다. 이는 OpenAI의 공식 용어가 아니라, 공개 베타를 좁은 범위에서 운영하기 위한 편집부의 설계 제안이다.

2. 하니스·환경·도구를 한 덩어리로 취급하면 생기는 공백

Agents API 발표는 하니스와 실행 환경을 분리해 설명한다. 하니스는 장기 세션, 도구 사용, 하위 에이전트 조율처럼 작업 흐름에 관여한다. 환경은 파일·패키지·실행 자원을 제공하는 장소다. 공식 발표에 따르면 OpenAI 호스팅 샌드박스는 코드 실행, 파일 작업, 산출물 생성을 위한 환경을 제공하며 파일·패키지·스킬·플러그인으로 구성할 수 있다. 반면 자체 인프라나 파트너 환경을 고르면 네트워크, 비밀값 저장 방식, CPU·GPU·메모리 조건을 조직이 더 직접 통제하게 된다. 환경 선택 항목에는 이런 차이가 분명히 적혀 있다.

이 분리를 실제 설계에 옮기면, 같은 에이전트 정의라도 환경마다 다른 위험을 가진다는 점이 드러난다. 예를 들어 읽기 전용 문서 조사 작업은 제한된 문서 볼트와 웹 검색만으로도 충분할 수 있다. 그러나 저장소의 브랜치 생성, 고객 데이터 조회, 배포 작업은 각각 다른 인증·감사·승인 정책을 요구한다. “도구를 연결했다”는 사실은 권한 범위를 설명하지 못한다. 도구가 갖는 실질적 행동과, 세션이 그 도구를 쓸 수 있는 조건을 따로 적어야 한다.

특히 산출물 경로는 종종 빠진다. 에이전트가 파일을 만들 수 있다는 사실과, 그 파일이 팀의 기록으로 보존될 수 있다는 사실은 다르다. 누가 읽을 수 있는 위치에 어떤 이름으로 저장되는지, 임시 파일은 언제 지워지는지, 검토 뒤 어떤 결과만 다음 자동화에 전달되는지를 환경 계약에 넣어야 한다. 이 정보가 없으면 작업이 성공했다는 답변은 남아도, 운영자가 나중에 확인할 수 있는 증거는 남지 않을 수 있다.

아래 흐름도는 API의 실제 내부 구현을 재현한 그림이 아니라, 책임을 단계별로 나누어 검토하기 위한 제안 도식이다.

이 도식에서 중요한 것은 가운데 칸의 이름이 아니라 경계다. 하니스가 작업 흐름을 관리한다 해도, 환경에 둔 파일이 민감한지와 도구 호출이 되돌릴 수 있는지는 별개다. 배포 초기에 이 셋을 하나의 설정 파일에 섞어 두면, 사고가 났을 때 “모델이 잘못했는지, 권한이 넓었는지, 검토가 없었는지”를 분리해 보기 어렵다.

3. 긴 세션을 가능하게 하는 기능과, 여전히 남는 운영 책임

공식 발표은 세션이 문맥 한도에 가까워질 때 이전 문맥을 자동으로 압축해 필요한 정보를 이어 갈 수 있다고 설명한다. 또한 도구 검색은 필요한 도구 정의를 필요 시 불러오도록 하고, 프로그래밍 방식 도구 호출은 관련 작업을 병렬로 실행하거나 결과를 코드에서 합칠 수 있게 한다. 멀티 에이전트 지원에서는 주 에이전트가 독립적인 조각을 하위 에이전트에 나누고 결과를 모을 수 있으며, 각 하위 에이전트는 자신만의 문맥을 유지한다. 문맥·도구·하위 작업 관련 공식 설명은 이 세 기능을 함께 제시한다.

이 기능들은 오래 걸리는 조사, 대규모 파일 분석, 여러 검증 단계처럼 서로 독립적인 작업이 있는 경우에 특히 의미가 있다. 하지만 “문맥을 압축한다”는 말은 모든 이전 판단이 완전하게 보존된다는 보증이 아니다. “필요한 도구를 검색한다”는 말도 도구가 안전하거나 적절한 결과를 낸다는 보증이 아니다. 하위 에이전트의 문맥이 분리된다는 사실 역시, 주 에이전트가 합친 결론이 맞다는 검증을 대신하지 않는다.

그래서 팀은 기능별로 한 문장을 더 적어 두는 편이 좋다. 문맥 압축에는 무엇을 잃어도 되는지, 도구 검색에는 어떤 도구가 후보가 될 수 있는지, 하위 작업에는 어떤 결과가 사람 검토 없이 다음 단계로 넘어갈 수 없는지를 붙인다. 이는 제품의 부족함을 지적하려는 규칙이 아니다. 자동화 범위가 넓어질수록, 모델 능력과 무관하게 조직이 유지해야 하는 업무 규칙을 문서로 꺼내는 방법이다.

▲ 이 이미지는 세션 문맥, 도구 검색, 하위 작업이 한 흐름에서 만나는 방식을 설명하기 위한 AI 개념도입니다. 실제 API 호출 순서나 처리량을 측정한 화면이 아닙니다.

4. 첫 번째 적용에는 ‘실행 계약’ 한 장이면 충분하다

처음부터 복잡한 다중 에이전트 업무를 자동화할 필요는 없다. 이 글의 제안은 읽기 전용의 단일 업무부터 시작하는 것이다. 예를 들면 장애 보고서에서 반복되는 오류 범주를 추려 조사 메모를 만드는 일, 배포 변경 목록을 비교해 검토 초안을 만드는 일이 있다. 이 단계에서는 외부 시스템을 변경하지 않고도 하니스·환경·도구의 분리가 실제로 이해되는지 확인할 수 있다.

다음 템플릿은 특정 API의 필수 설정이 아니라, 팀이 첫 실행 전에 합의할 수 있는 운영 문서 예시다. 설명을 위한 제안이며 실제 측정 결과가 아닙니다.

# 에이전트 실행 계약

- 업무 목적: 오류 보고서에서 반복되는 원인 후보를 정리한다.
- 입력 범위: 지정된 날짜의 읽기 전용 보고서와 런북
- 실행 환경: 네트워크 정책과 파일 보존 기간을 확인한 샌드박스
- 허용 도구: 문서 검색, 읽기 전용 로그 조회, 결과 파일 저장
- 금지 행동: 배포·설정 변경, 고객 데이터 내보내기, 권한 추가
- 산출물: 근거 링크가 달린 원인 후보 목록과 미확인 항목
- 사람 검토: 담당자가 근거와 누락 항목을 확인한 뒤에만 후속 티켓 생성
- 중단 조건: 권한 오류, 민감 정보 노출 가능성, 근거 없는 결론 생성

이 문서의 장점은 성공을 장담하는 데 있지 않다. 실패했을 때도 무엇이 실패했는지 좁힐 수 있다는 데 있다. 산출물이 부정확했다면 프롬프트만 다시 쓰기 전에 입력 범위와 근거 링크를 살핀다. 도구가 과도하게 호출됐다면 모델을 탓하기 전에 도구 후보와 허용 조건을 줄인다. 결과 파일이 남지 않았다면 하니스 문제가 아니라 환경의 저장 정책을 확인한다. 같은 현상을 다른 계층의 결함으로 오인하는 일을 줄이는 것이 첫 도입의 실질적 성과다.

5. 공개 베타에서 확장 여부를 판단하는 네 가지 질문

Agents API는 현재 공개 베타이며, OpenAI는 피드백을 바탕으로 빠르게 반복한 뒤 정식 출시를 향해 간다고 밝혔다. 따라서 팀의 도입 판단도 한 번의 데모가 아니라 반복 가능한 관찰을 기반으로 해야 한다. 공개 베타 상태와 제공 조건을 확인한 뒤, 다음 질문에 답할 수 있을 때만 쓰기 권한이나 더 넓은 도구 세트로 확장하는 편이 낫다.

1. 실행마다 입력 범위와 산출물이 남아, 다른 사람이 같은 결과를 검토할 수 있는가?
2. 환경에 둔 파일·패키지·비밀값의 범위가 업무 목적에 비해 과도하지 않은가?
3. 도구마다 읽기·쓰기·외부 전송 권한과 사람 승인 지점이 분리되어 있는가?
4. 하위 작업 결과가 합쳐질 때, 근거 없는 추론이나 누락을 찾는 검토 단계가 있는가?

네 가지가 모두 완벽해야만 실험을 시작할 수 있다는 뜻은 아니다. 오히려 답하지 못한 항목을 실행 계약의 미확인 사항으로 남기고, 읽기 전용 범위에서 먼저 확인하자는 뜻이다. 공개 베타 제품의 변화 속도와 조직의 보안 기준은 다르다. 따라서 업데이트 노트를 읽어 기능을 빠르게 붙이는 것보다, 어느 경계가 바뀌면 계약을 다시 검토할지 정해 두는 편이 장기적으로 더 안정적이다.

예를 들어 새 도구가 추가되거나 샌드박스의 파일 보존 정책이 바뀌면, 모델을 바꾸지 않더라도 실행 계약을 다시 읽어야 한다. 변경의 단위가 프롬프트가 아니라 권한과 기록의 경계이기 때문이다.

마무리: 편리한 하니스보다 먼저 확인할 것

이번 발표는 에이전트 애플리케이션을 만들 때 반복되던 실행 제어와 인프라 구성의 부담을 줄일 수 있는 새로운 선택지다. 다만 장기 실행 에이전트의 품질은 모델 이름이나 하위 에이전트 수만으로 결정되지 않는다. 하니스에는 작업 흐름, 환경에는 실행 자원, 도구에는 행동 권한, 사람에게는 최종 판단을 맡기는 경계가 선명해야 한다.

첫 실행 계약을 작게 쓰고, 읽기 전용 업무에서 산출물과 실패 기록을 쌓아 보자. 그 기록이 있어야만 어떤 기능을 더 맡길지, 어떤 권한을 끝까지 사람에게 남길지 근거를 가지고 결정할 수 있다.