OpenAI Agents API 공개: Codex식 장기 실행 에이전트를 제품에 붙이는 법

OpenAI가 2026년 9월 10일 Agents API 공개 베타를 발표했다. 핵심은 단순한 채팅 API가 아니라 Codex를 움직이던 하네스, 샌드박스, 장기 실행 인프라를 개발자가 제품 안에서 호출할 수 있게 만든 점이다. 기존에는 에이전트 제품을 만들려면 모델 호출, 파일 작업, 도구 호출, 컨텍스트 압축, 작업 재시도, 실행 환경 격리를 팀이 직접 붙여야 했다. Agents API는 이 중 상당 부분을 API 레벨로 올린다.

공식 발표에서 OpenAI는 “task, model, tools, environment”를 지정하는 한 번의 API 호출로 클라우드 에이전트를 만들 수 있다고 설명했다. OpenAI 관리 샌드박스뿐 아니라 자체 인프라, VPC 배포, Cloudflare·Daytona·E2B·Modal·Vercel 같은 파트너 샌드박스도 선택할 수 있다. 실무 개발자 관점에서 중요한 변화는 모델 성능보다 운영 단위가 바뀐다는 점이다. 이제 질문-응답 API를 감싸는 수준이 아니라, 파일을 읽고 코드를 실행하고 중간 결과를 저장하는 “작업자”를 서비스에 넣는 선택지가 생겼다.

왜 이번 발표가 중요한가

검색 의도는 분명하다. “OpenAI Agents API”를 찾는 사람은 새 기능 이름만 알고 싶은 게 아니다. 실제로 기존 Assistants API나 직접 만든 LangChain 워커를 대체할 수 있는지, 비용 구조가 어떻게 되는지, 장기 실행 작업이 끊기지 않는지, 보안 경계를 어디에 둬야 하는지를 알고 싶어 한다.

Agents API가 중요한 이유는 세 가지다. 첫째, 장기 세션을 전제로 한다. OpenAI는 세션이 컨텍스트 한계에 가까워지면 필요한 정보를 유지하면서 이전 내용을 자동으로 compact한다고 밝혔다. 긴 리팩터링, 리서치, 데이터 정리처럼 한 번에 끝나지 않는 작업에서 이 기능은 직접 구현하기 어렵다. 둘째, 도구 검색과 programmatic tool calling을 지원한다. 모든 도구 정의를 매번 프롬프트에 넣지 않고 필요한 도구를 찾아 로드하면 토큰 비용을 줄일 수 있다. 셋째, subagent 병렬 실행을 공식 기능으로 제공한다. 복잡한 업무를 작은 단위로 나누고 각 에이전트가 별도 컨텍스트를 유지한 뒤 메인 에이전트가 취합하는 구조다.

기존 에이전트 구현에서 자주 터지는 문제

직접 에이전트 하네스를 만든 팀은 비슷한 문제를 겪는다. 처음에는 모델에 도구 목록을 주고 함수 호출만 붙이면 될 것처럼 보인다. 그러나 운영으로 가면 다음 문제가 바로 나온다.

• 파일 시스템 접근 권한을 어디까지 열지 정해야 한다.
• 실행 중인 작업이 20분, 2시간, 하루를 넘어갈 때 상태를 보존해야 한다.
• 모델이 같은 로그를 반복해서 읽거나 같은 명령을 다시 실행하면 비용이 튄다.
• 도구 정의가 많아질수록 프롬프트가 비대해진다.
• 병렬 작업 결과를 합치는 과정에서 충돌이 난다.
• 실패한 작업을 다시 실행할 때 어떤 중간 산출물을 믿을지 판단해야 한다.

Agents API는 이 문제를 모두 자동 해결한다고 말할 수는 없다. 하지만 최소한 “하네스가 제품의 핵심 병목이 되는 문제”를 플랫폼 쪽으로 일부 넘긴다. 특히 Codex에서 검증된 구조를 공개 API로 가져온 점은 의미가 있다. 개발팀은 이제 모델 래퍼보다 업무 도메인, 권한 모델, 검증 로직에 더 많은 시간을 쓸 수 있다.

제품에 붙일 때 먼저 설계해야 할 것

바로 붙이면 안 된다. 에이전트는 편하지만, 잘못 붙이면 장애 반경도 커진다. 먼저 작업 유형을 세 단계로 나눠야 한다.

1. 읽기 전용 작업: 리서치, 로그 분석, 문서 요약, 코드베이스 탐색.
2. 제한된 쓰기 작업: 초안 생성, 브랜치 안에서 코드 수정, 테스트 파일 생성.
3. 외부 영향 작업: 배포, 결제, 이메일 발송, 고객 데이터 수정.

첫 도입은 1번이나 2번에서 시작하는 게 안전하다. 예를 들어 고객사별 리포트를 만드는 SaaS라면 에이전트가 데이터 소스를 읽고 초안을 만들되, 최종 발송은 사람이 승인하게 둔다. 개발 도구라면 에이전트가 브랜치에서 테스트를 추가하고 PR을 만들 수는 있어도 main 브랜치 배포는 막는다.

샌드박스 선택도 중요하다. OpenAI hosted sandbox는 시작이 빠르다. 반면 회사 내부 데이터, VPC 접근, 특수 패키지, GPU 환경이 필요하다면 자체 인프라나 파트너 샌드박스를 검토해야 한다. 선택 기준은 “누가 실행 환경을 관리하느냐”가 아니라 “실패했을 때 어떤 데이터와 시스템이 영향을 받느냐”다.

비용은 토큰보다 작업 단위로 봐야 한다

OpenAI는 Agents API 사용 자체에는 추가 요금이 없고, 토큰과 도구 사용량에 따라 과금한다고 설명했다. 그래서 겉으로는 기존 API와 비슷해 보일 수 있다. 하지만 에이전트 비용은 단일 호출 비용보다 완료 비용으로 봐야 한다.

예를 들어 단순 요약 API는 입력 1회, 출력 1회로 끝난다. 반면 에이전트는 파일을 찾고, 명령을 실행하고, 실패 로그를 읽고, 다시 수정하고, 테스트를 반복한다. 한 작업이 15번의 모델 턴과 8번의 도구 호출을 만들 수 있다. 따라서 비용 추적 단위는 “요청 1회”가 아니라 “성공한 작업 1건”이어야 한다.

실무에서는 다음 지표를 대시보드에 넣는 편이 낫다.

• 작업당 평균 모델 턴 수
• 작업당 도구 호출 수
• 작업당 재시도 횟수
• 사람이 개입한 비율
• 실패 후 중단된 작업 비율
• 최종 승인까지 걸린 시간

이 지표가 없으면 “에이전트가 느린지”, “프롬프트가 나쁜지”, “도구 출력이 부족한지”, “작업 범위가 너무 큰지”를 구분할 수 없다.

바로 써볼 만한 적용 사례

가장 현실적인 첫 적용처는 반복적이지만 검증 가능한 업무다. 예를 들어 릴리즈 노트 작성, 의존성 업데이트 영향 분석, 고객 문의 로그 분류, 데이터 품질 점검, 내부 문서 최신화, 테스트 실패 원인 요약이 있다. 공통점은 결과를 사람이 빠르게 검토할 수 있고, 실패해도 되돌릴 수 있으며, 작업 범위가 비교적 명확하다는 점이다.

반대로 결제 환불, 계정 정지, 법무 문서 발송, 프로덕션 DB 수정은 초기 적용처로 좋지 않다. 이런 작업은 모델 성능보다 권한 분리, 감사 로그, 승인 흐름이 더 중요하다. Agents API를 쓰더라도 사람 승인과 정책 엔진이 앞단에 있어야 한다.

실행 체크리스트

• OpenAI Agents API를 기존 챗봇 대체가 아니라 장기 실행 작업자 API로 분류한다.
• 첫 도입 작업은 읽기 전용 또는 제한된 쓰기 작업으로 고른다.
• 샌드박스는 데이터 민감도, 네트워크 접근, 패키지 요구사항 기준으로 선택한다.
• 작업당 모델 턴 수, 도구 호출 수, 재시도 횟수, 승인률을 로그로 남긴다.
• 외부 영향 작업에는 사람 승인, 감사 로그, 롤백 경로를 반드시 둔다.
• 도구 정의가 많다면 tool search와 권한 그룹을 함께 설계한다.
• subagent 병렬 실행은 빠르지만 충돌도 늘 수 있으므로 결과 병합 규칙을 먼저 만든다.

Agents API의 핵심은 “모델이 더 똑똑해졌다”가 아니다. 에이전트 운영에 필요한 하네스가 점점 플랫폼 기능이 되고 있다는 신호다. 제품팀이 지금 할 일은 데모를 하나 더 만드는 것이 아니라, 에이전트가 맡아도 되는 작업과 절대 맡기면 안 되는 작업을 분리하는 것이다.