LLM API의 가장 단순한 형태는 익숙합니다.
Prompt
↓
Model
↓
Response
조금 발전하면 tool calling을 붙입니다.
Model
↓
Tool call
↓
Tool result
↓
Model
그런데 실제 에이전트가 몇 분이 아니라 몇 시간, 며칠 동안 일하려면 문제가 달라집니다.
컨텍스트가 길어지고, 중간 파일이 생기고, 여러 tool을 사용하고, 실패 후 복구해야 합니다.
OpenAI가 2026년 9월 10일 공개한 Agents API는 이 부분을 직접 다루려는 API입니다.
Agents API는 모델 API가 아니라 실행 구조에 가깝습니다
OpenAI는 Agents API를 “Codex를 구동하는 managed harness와 infrastructure를 개발자에게 제공하는 API”로 설명합니다.
즉 핵심은 새로운 모델이 아닙니다.
다음과 같은 실행 환경입니다.
- session orchestration
- context compaction
- recovery
- durable sessions
- tool / MCP 연결
- hosted sandbox
- 파일과 코드 실행 환경
- subagent coordination
이전에는 개발자가 직접 만들어야 했던 agent loop의 일부를 플랫폼이 맡는 구조입니다.
단순 Responses API와 무엇이 다를까?
개념적으로 단순화하면 이렇습니다.
일반 모델 호출
response = client.responses.create(
model="...",
input="분석해줘"
)
한 요청의 시작과 끝이 비교적 명확합니다.
Agent 실행
Goal
↓
Plan
↓
Tool
↓
Observe
↓
Continue
↓
Compact context
↓
Tool
↓
Recover from failure
↓
Finish
여기서는 한 번의 inference보다 작업 전체의 생명주기가 중요합니다.
Agents API는 이 긴 실행 흐름을 관리하는 쪽에 더 가깝습니다.
왜 지금 이런 API가 나왔을까?
모델이 충분히 강해지면서 병목이 바뀌고 있기 때문입니다.
예전에는:
모델이 문제를 못 풀어서 실패
가 많았다면, 장기 agent에서는:
컨텍스트가 엉킴
도구 사용 실패
중간 상태 유실
재시도 과정에서 목표 이탈
파일 환경 불일치
같은 문제가 더 눈에 띕니다.
OpenAI도 Agents API 소개에서 장기 실행 agent에 강력한 harness가 필요하다고 직접 설명합니다.
durable session이 중요한 이유
일반적인 chat loop는 프로세스가 끊기면 상태를 직접 저장하고 복원해야 합니다.
하지만 장기 업무에서는:
Day 1
자료 수집
Day 2
분석 계속
Day 3
결과 수정
처럼 한 세션이 오래 이어질 수 있습니다.
durable session은 이런 작업을 계속 이어갈 수 있도록 상태를 관리하는 개념입니다.
특히 에이전트가:
- 파일을 만들고
- 코드를 실행하고
- 중간 산출물을 저장하고
- 나중에 다시 이어서 작업
해야 할 때 중요합니다.
hosted sandbox는 무엇을 바꿀까?
에이전트가 코드를 실행하려면 안전한 실행 공간이 필요합니다.
직접 만들면 다음을 고려해야 합니다.
container lifecycle
filesystem
network permissions
timeouts
resource limits
cleanup
Agents API는 OpenAI-hosted sandbox를 사용할 수 있고, 필요하면 외부 sandbox 환경과도 연결할 수 있도록 설계되어 있습니다.
즉 개발자는 agent logic에 더 집중하고 infra 일부를 managed service로 넘길 수 있습니다.
CodeBridge Mini Lab: 직접 만든 loop와 managed harness 비교하기
아주 작은 agent를 두 방식으로 만들어보면 차이를 느끼기 쉽습니다.
A. 직접 loop
while not done:
response = call_model(context)
tool_result = run_tool(response.tool_call)
context.append(tool_result)
처음에는 간단합니다.
하지만 곧 이런 코드가 필요해집니다.
retry
context trimming
state save
resume
logging
sandbox
permission
error recovery
B. managed agent
같은 작업을 Agents API로 구현하면서 다음 질문을 비교합니다.
직접 구현해야 하는 상태 관리 코드는 얼마나 줄었는가?
중간 실패 후 복구는 어떻게 처리되는가?
도구 연결은 얼마나 단순해졌는가?
비용과 vendor lock-in은 어떤가?
이 비교는 “어느 쪽이 무조건 낫다”를 정하기 위한 것이 아닙니다.
어떤 책임을 플랫폼에 넘기고 어떤 책임을 직접 가져갈지 결정하기 위한 실험입니다.
managed harness의 장점과 trade-off
장점
- agent loop 구현량 감소
- durable session과 recovery 활용
- sandbox infra 부담 감소
- Codex 계열 harness 기능 활용
고려할 점
- 실행 구조에 대한 세밀한 제어 범위
- 특정 provider에 대한 의존성
- 장기 실행 비용
- observability와 데이터 관리 방식
- 자체 infra와의 연결
즉 Agents API는 “agent 개발이 끝났다”는 의미가 아니라 구현해야 할 레이어의 경계가 이동했다는 의미에 가깝습니다.
기존 Harness Engineering과 어떻게 연결될까?
하네스 엔지니어링은 특정 제품을 뜻하지 않습니다.
AI가 안정적으로 일하도록:
Context
Tools
Rules
Memory
Verification
Execution environment
을 설계하는 관점입니다.
Agents API는 이 중 일부를 managed platform으로 제공하는 하나의 구현 선택지입니다.
그래서 앞으로는:
직접 하네스를 구축할 것인가?
vs
관리형 하네스를 사용할 것인가?
도 중요한 설계 선택이 될 가능성이 큽니다.
결론: 모델 API 다음 경쟁은 Agent Runtime일 수 있습니다
모델 성능이 계속 좋아질수록 차별화 지점은 모델 자체에서 실행 환경으로 이동하고 있습니다.
OpenAI Agents API가 흥미로운 이유도 새로운 chat endpoint 하나가 추가돼서가 아닙니다.
장기 실행 agent에 필요한 하네스와 인프라를 API 제품으로 만들었다는 점
이 중요합니다.
앞으로 agent를 만들 때는 모델 선택뿐 아니라 직접 orchestration할 부분과 managed runtime에 맡길 부분을 함께 설계해야 합니다.