지난 9월 10일, OpenAI는 Agents API 퍼블릭 베타를 출시하며 "Codex를 구동하는 바로 그 하네스(harness)와 인프라를 단순하고 유연한 API를 통해 개발자에게 제공한다"고 밝혔습니다. 이어 9월 29일 DevDay에서는 컴퓨터 사용(computer use) 기능, AWS 네이티브 버전, 그리고 새로운 동료가 추가되었습니다. ChatGPT의 새로운 상시 가동형 닷(dots) 역시 동일한 Codex 하네스 위에서 구동됩니다.
에이전트 제품을 만드는 개발자의 관점에서 본다면 이는 분명 희소식입니다. 어설프게 직접 만들 뻔했던 하네스를 이제 남의 손에 맡길 수 있게 되었기 때문입니다. 하지만 실제 코드베이스에서 팀원들과 함께 Claude Code와 Codex를 이미 운영 중인 엔지니어의 관점에서 본다면 질문이 달라집니다. 이 API는 "어떻게 에이전트를 몇 시간 동안 계속 실행시킬 것인가?"에는 답을 주지만, "에이전트 6개가 각각 무엇을 작업했는지 팀에서 어떻게 파악할 것인가?", "그중 하나가 방금 로그인한 웹사이트를 승인한 사람은 누구인가?"라는 질문에는 답하지 못합니다. 바로 이 두 번째 질문이 Sharkly가 존재하는 이유입니다.
핵심 요약 (TL;DR)
Agents API는 영속적 세션(durable sessions), 컨텍스트 압축(compaction), 도구 검색, 서브에이전트, 그리고 OpenAI 자체 인프라나 자체 서버 또는 9개 파트너사의 샌드박스를 아우르는 Codex 하네스를 호스팅합니다. 토큰, 도구, 컨테이너 사용 시간 외에 별도 추가 비용은 없습니다. DevDay에서는 애플리케이션이 새로운 웹사이트 오리진(origin) 및 모든 로그인을 개별 승인하는(단, 오리진 승인이 개별 동작에 대한 확인은 아님) 컴퓨터 사용 기능과, AWS 환경 내에서 핵심 기능을 실행하는 Bedrock Managed Agents가 추가되었습니다. 하지만 그 어떤 것도 '팀 레이어'를 호스팅하지는 않습니다. 즉, 누가 작업을 할당했는지, 어떤 에이전트가 이를 담당하는지, 무엇이 완료되고 실패했는지, 그리고 그 결과를 누가 최종 승인하는지는 해결해주지 않습니다.
Agents API의 정의와 OpenAI가 관리하는 영역
OpenAI의 개요에 따르면 이 API는 네 가지 핵심 구성 요소로 정리됩니다. Agent는 "에이전트가 사용할 수 있는 모델, 지침(instructions), 도구, MCP 서버"입니다. Environment는 "에이전트가 파일에 접근하고, 스킬을 로드하며, 명령어를 실행하는 선택적 샌드박스 또는 컴퓨터"입니다. Session은 "작업을 수행하고 입력에 응답하는 에이전트의 영속적 인스턴스"입니다. Events and items는 사용자가 보내는 입력과 반환되는 출력입니다.
에이전트 설정을 통해 세션을 생성하고, 환경이 준비되면 작업을 부여한 뒤, 스트리밍이나 웹훅으로 진행 과정을 추적하며, 동일한 세션에 추가 작업이나 방향 제어(steering) 지시를 보낼 수 있습니다. 공식 문서의 예제를 간추리면 다음과 같습니다.
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions: "Use the docs MCP and web search. Delegate independent research to subagents when useful.",
tools: [
{ type: "programmatic_tool_calling" },
{ type: "mcp", server_label: "openai_docs", transport: { type: "http", server_url: "https://developers.openai.com/mcp" } },
{ type: "web_search" },
],
multi_agent: { enabled: true, max_concurrent_subagents: 4 },
},
environment: { type: "self_hosted", workspace_directory: "/workspace" },
input: [{ role: "user", content: [{ type: "input_text", text: "Research how to connect an MCP server to an OpenAI agent and summarize the setup." }] }],
});
여기서 핵심적인 내용은 두 줄에 담겨 있습니다. multi_agent는 동시 실행 수 제한(concurrency cap)을 두고 서브에이전트 팬아웃(fan-out)을 활성화하며, environment.type은 코드가 실행될 위치를 결정합니다(openai_hosted, self_hosted, 또는 Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel 등 파트너사 샌드박스 중 선택 가능).
공식 문서에서는 역할 분담을 한 문장으로 명시하고 있습니다. "OpenAI는 세션, 오케스트레이션, 컨텍스트 압축 및 복구를 관리하며, 애플리케이션은 도구를 제공하고 실행 환경을 선택합니다."
| OpenAI가 관리하는 영역 | 직접 제공해야 하는 영역 |
|---|---|
| 에이전트 루프: 모델 호출, 도구 사용, 재시도 | 작업(Task) 및 완료의 정의(Definition of Done) |
| 세션 한도 도달 시 컨텍스트 압축 | 도구: MCP 서버, 함수, 내장 도구 |
| 도구 검색 및 로딩 | Vault ID를 통한 자격 증명 |
| 서브에이전트 분해 및 조율 | 실행 환경 선택 및 구성 |
| 세션 재개 및 방향 제어(Steering) | 세션 종료 후 발생하는 모든 후속 작업 |
모델 사용량은 해당 모델의 API 요금으로, 도구는 표준 요금으로, OpenAI 호스팅 샌드박스는 컨테이너 요금으로 청구됩니다. 출시 안내 글에 따르면 "Agents API 사용에 따른 추가 수수료는 없습니다." 하지만 공식 문서에는 두 가지 명확한 제약 사항이 명시되어 있습니다. 이 API는 "현재 미국 내 데이터 레지던시만 지원하며 ZDR(Zero Data Retention, 제로 데이터 보존)을 지원하지 않는다"는 점과, 자체 호스팅(self-hosted) 샌드박스를 선택하더라도 ZDR 대상이 되지 않는다는 점입니다. 만약 컴플라이언스 측면에서 이 부분이 중요하다면, 샌드박스를 사내 환경으로 옮긴다고 해도 해결되지 않습니다.
DevDay에서 새롭게 추가된 기능
컴퓨터 사용(Computer use). computer_use 도구를 추가하고 OpenAI 호스팅 환경에서 데스크톱을 활성화하면, 에이전트가 호스팅된 브라우저를 제어합니다. 컴퓨터 사용 가이드는 승인 이벤트(approval events)를 중심으로 플로우를 구성합니다. 브라우저는 공개 웹사이트를 포함해 새로운 웹사이트 오리진에 접근하기 전에 매번 사용자의 승인을 요청합니다. 로그인은 이메일, 비밀번호, 인증 코드 필드를 위해 애플리케이션이 렌더링하는 별도의 요청으로 전달됩니다. 패스키와 QR 로그인은 지원되지 않으며, 서브에이전트가 아닌 메인 에이전트만 자격 증명을 요청할 수 있습니다. 여기서 특히 주의 깊게 봐야 할 문장이 있습니다. "오리진 승인이 개별 동작 전의 확인을 강제하지는 않습니다." 결제나 파괴적인 변경 작업의 경우, 공식 문서에서는 호스팅된 브라우저가 해당 작업을 수행할 수 없는 리소스에만 접근하도록 제한하거나 사용자가 직접 제어하는 브라우저 런타임을 사용할 것을 권장합니다. DevDay 요약에 따르면 컴퓨터 사용은 "API를 통해서뿐만 아니라 Pro 500 및 Enterprise 요금제의 Codex와 ChatGPT Work에서도" 지원됩니다.
OpenAI 기반 Bedrock Managed Agents. OpenAI와 Amazon은 "Agents API의 핵심 역량"을 기반으로 AWS에서 네이티브하게 작동하도록 맞춤화했습니다. AWS 제품 페이지에는 프리뷰로 표시되어 있으며, 에이전트 런타임과 모델 추론이 AWS 내부에서 유지되고 각 에이전트가 자체 AWS ID 및 권한을 갖는다고 명시되어 있습니다.
동일한 하네스 기반의 닷(Dots). Decrypt의 보도에 따르면 Codex 하네스는 "이제 닷(dots)을 구동하며 오픈소스로 공개"되었습니다. 닷은 각자의 클라우드 컴퓨터를 갖춘 ChatGPT의 상시 가동형 에이전트이며, 이들이 잘 수행하는 작업에 대해서는 당사의 닷 해설서에서 자세히 다루고 있습니다.
결과적으로 단 하나의 루프가 코딩 에이전트, API 세션, AWS 에이전트, 그리고 상시 가동형 어시스턴트를 모두 구동하게 된 셈입니다. 하네스가 하나로 수렴하고 있는 것입니다. 하지만 승인 이벤트는 고스란히 팀의 몫으로 남습니다. 각각의 승인 요청은 단일 세션 내부의 질문이며, 해당 스트림을 열어두고 있는 사람이 답변해야 합니다. 만약 5개의 세션에서 동시에 요청이 들어온다면, 누가 어떤 오리진을 승인할 권한이 있는지, 그 결정이 어디에 기록되는지를 누군가는 판단해야 합니다. 이것이 바로 승인 게이트(approval gate) 문제이며, 이에 대한 컴퓨터 제어 관점의 해결 방안은 GPT-6 Astra 컴퓨터 사용 가드레일에서 심도 있게 다룬 바 있습니다.
API가 다루지 않는 영역: 팀 레이어
하나의 세션은 오직 자기 자신만 알고 있습니다. 다른 3개의 세션이 동일한 리포지토리를 수정하고 있는지, 아니면 4번째 세션의 작업 결과가 화요일부터 확인되지 않은 채 방치되어 있는지는 알지 못합니다. 이는 협업 및 관리의 문제이며, 둘 이상의 사람이 둘 이상의 에이전트를 가동하는 순간 필연적으로 마주하게 됩니다.
설계상 API가 미해결 상태로 남겨두는 5가지 질문은 다음과 같습니다.
- 누가 이 작업을 어떤 티켓에 기반해 할당했는가? 세션에는 ID와 코드에서 직접 입력한 메타데이터만 존재합니다. 담당자, 스프린트, 원본 이슈 링크 등은 개발자가 직접 명시하지 않는 한 존재하지 않습니다.
- 어떤 리포지토리와 브랜치를 변경했는가? 코드 변경 사항(diff)을 리뷰어가 확인할 수 있는 곳으로 직접 가져와야 합니다.
- 무엇이 완료되었고, 무엇이 실패했으며, 무엇이 대기 중인가? 이벤트는 수신 대기 중일 때 스트리밍되거나 웹훅으로 전달될 뿐입니다. 사람의 확인을 기다리는 작업 결과 큐에 자동으로 쌓이지 않습니다.
- 그 결과를 최종 승인하는 주체는 누구인가? 승인 이벤트는 웹사이트 접근이나 로그인에 관한 것일 뿐, 작업 결과물 자체에 대한 것이 아닙니다. 별도로 구축하지 않는 한 "세션이 종료되었다"는 것과 "사람이 근거 자료를 검토하고 승인했다"는 것은 같은 상태로 취급됩니다.
- OpenAI 제품이 아닌 다른 에이전트는 어떻게 관리하는가? 특정 작업에는 Claude Code를, 다른 작업에는 Codex를 사용한다면 세션 모델도 2개이고 확인해야 할 위치도 2곳으로 나뉩니다.
이벤트 데이터를 기반으로 보드, 웹훅, 상태 필드, 리뷰 칼럼 등 5가지 요소를 모두 직접 구축할 수도 있습니다. 하지만 그러다 보면 누군가 "내보내기 기능 수정 건 배포됐나요?"라고 물었을 때, 아무도 저장해 두지 않은 터미널 스크롤 속에만 답이 남아 있는 상황이 벌어집니다. 이를 직접 구축하는 방식에 대해서는 AI 에이전트 작업 관리에서 자세히 다룹니다.
세션 내 서브에이전트인가, 보드 위의 태스크인가?
max_concurrent_subagents 설정값은 병렬 처리에 대한 API 측의 해법이며, 적절한 성격의 작업에는 매우 훌륭한 방식입니다. 이는 Codex가 서브에이전트 한도를 64개로 상향했을 때 다루었던 트레이드오프이기도 합니다. 즉, 서브에이전트들은 부모 에이전트를 공유하고 하나의 취합된 응답으로 보고하며, 하나의 결과물로서 일괄 검토됩니다.
각 세부 작업이 읽기 중심(read-heavy)이고 독립적이며 통합된 결과만이 중요한 경우라면 세션 내부의 서브에이전트를 활용하세요. 예를 들어 4개의 API 조사하기, 코드베이스에서 특정 패턴 스캔하기, 인시던트 관련 증거 수집하기 등이 이에 해당합니다.
반면, 각각의 작업이 코드를 작성(write)하여 개별적으로 사람의 코드 리뷰를 거쳐야 하는 경우에는 개별 태스크(Tasks)로 분리해 관리해야 합니다. 데이터베이스 마이그레이션, 단일 모듈의 기능 개발, 공용 파일을 수정하는 버그 픽스 등이 대표적입니다. Sharkly에서는 각 실행마다 사용자 소유의 Computer 위에 격리된 git worktree가 할당되며, 각각의 결과는 diff, 실행 로그, 리뷰어 정보와 함께 자체 태스크로 반환됩니다. 쓰기 중심(write-heavy)의 변경 사항 4개를 단 하나의 서브에이전트 요약으로 압축해 버리는 것은, 4개의 의사결정을 하나 속에 은폐하는 것과 같습니다.
자주 묻는 질문 (FAQ)
컴퓨터 사용 기능은 어떤 모델에서 구동되나요? 공식 문서의 예제에서는 gpt-6-astra를 사용합니다. 다른 모델이 computer_use 도구를 지원할 것으로 단정하기 전에 반드시 공식 가이드를 확인하시기 바랍니다.
Sharkly는 Agents API 세션을 직접 실행하나요? Sharkly는 사용자의 Computers에 설치된 Codex 및 Claude Code와 같은 CLI 코딩 에이전트를 런타임(Runtimes)으로 구동합니다. Agents API 세션은 설치형 런타임이 아니라 호스팅 서비스이므로, 별도의 실행 경로로 보아야 합니다.
사람의 검토(Human Review)는 어디서 이루어지나요? Agents API의 경우 직접 구현한 위치 어디에서든 이루어집니다. API의 승인 이벤트는 웹사이트 접근 및 로그인만 다룰 뿐 결과물의 최종 수락을 다루지 않습니다. 반면 Sharkly에서는 에이전트가 자신의 태스크를 '사람 검토 대기' 상태로 둘 수 있으며, 이 요청은 담당자의 인박스(Inbox)로 전달됩니다. 담당자는 에이전트의 응답, 실행 로그, diff를 확인한 뒤 작업 상태를 직접 변경합니다.
각 계층이 위치해야 할 적절한 자리
OpenAI 인프라에서 제공하는 영속적 세션은 이번 출시에서 가장 편리하면서도, 고객을 가장 강하게 묶어두는(stickiest) 요소입니다. 이는 엔지니어링 팀에게 매우 중요한 문제입니다. 가장 뛰어난 코딩 에이전트는 계속해서 바뀌는데, 리뷰 상태와 작업 할당 규칙이 특정 벤더의 세션 저장소에 종속되어 있다면 업계 선두가 바뀔 때마다 워크플로우 전체를 다시 구축해야 하기 때문입니다.
에이전트 기반 제품이나 백엔드 서비스를 구축하고 있다면 Agents API가 적합한 계층이며, AWS 내부 환경이 필요한 팀에게는 Bedrock Managed Agents가 동일한 역할을 수행합니다. 하네스를 직접 유지보수할 필요가 없고, 샌드박스를 직접 프로비저닝하지 않아도 됩니다. 이 경우 별도의 태스크 보드가 전혀 필요 없을 수도 있습니다. 애플리케이션 자체가 곧 보드 역할을 하기 때문입니다.
하지만 에이전트가 자체 코드베이스 위에서 팀원처럼 협업하고, 사람이 실행하며, 사람이 검토하고, 기존 리포지토리와 이슈 트래커를 통해 배포되는 환경이라면 이야기가 달라집니다. 실행 자체는 Codex와 Claude Code가 담당합니다. Sharkly는 이러한 도구 전반에 걸쳐 팀 단위 작업 할당, 연결된 Computers, 태스크 컨텍스트, 진행 상황, 차단 요소(blockers), 결과물 및 사람의 검토 과정을 관리합니다. Sharkly는 개별 런타임이나 Agents API를 대체하는 것이 아닙니다. 이러한 위치 선정에 대한 고민은 Codex 자체에도 동일하게 적용되며, 이에 대해서는 Codex 클라우드 vs 자체 컴퓨터 비교에서 다루고 있습니다.
에이전트를 직접 개발하고 있다면 하네스를 임대해 사용하세요. 하지만 에이전트를 관리하고 통제하는 입장이라면 관리 레이어만큼은 특정 공급업체에 종속되지 않는 자체 소유로 유지해야 합니다.
이미 여러 에이전트를 운영 중이라면 Sharkly를 통해 에이전트들의 작업과 결과를 한곳에서 관리할 수 있습니다. Sharkly는 토큰을 판매하지 않습니다. 모델 사용 요금은 연결된 도구에 설정된 구독 또는 API 키를 통해 그대로 청구됩니다.
