OpenAI Agents SDK의 다음 진화 — Sandbox Agents와 모델 네이티브 하네스가 바꾸는 것
OpenAI Agents SDK의 다음 진화 — Sandbox Agents와 모델 네이티브 하네스가 바꾸는 것
2026년 4월 15일, OpenAI가 Agents SDK의 "다음 진화"를 발표했다. 동시에 openai-agents-python v0.14.0과 v0.14.1을 릴리스하며 Sandbox Agents와 **모델 네이티브 하네스(model-native harness)**를 일반 가용(GA)으로 열었다.
발표문 한 줄을 옮기면 이렇다. "에이전트는 이제 파일을 읽고 쓰고, 의존성을 설치하고, 코드를 실행하고, 도구를 사용할 수 있다 — 모두 안전한 격리 환경에서." 문장만 보면 평범하지만, 이게 무엇이 바뀌었는지, 왜 중요한지, 어떻게 쓸지를 정리해보면 생각보다 큰 변화다.
왜 이 진화가 필요했나 — 세 가지 트레이드오프
이번 발표의 맥락을 이해하려면 기존 AI 에이전트 빌딩 방식의 트레이드오프를 짚어야 한다. OpenAI는 자사 블로그에서 세 갈래를 명확히 정리했다.
1) 모델 비독립 프레임워크 (LangChain, LlamaIndex 등)
유연성은 높다. 모든 모델과 연동할 수 있다. 하지만 프론티어 모델의 능력을 완전히 활용하지 못한다. "최신 모델이 할 줄 아는 것"과 "프레임워크가 노출하는 인터페이스" 사이에 항상 간극이 있다.
2) 모델 공급자 SDK
OpenAI, Anthropic의 자사 SDK는 모델에 가장 가까운 통합을 제공한다. 대신 하네스(에이전트 실행 인프라) 가시성이 부족했다. 프로덕션 레벨에서 "지금 이 에이전트가 뭘 하고 있나"를 보기 어려웠다.
3) 관리형 에이전트 API
배포는 단순하다. 하지만 실행 위치와 데이터 접근에 제약이 있다. 1인 기업이나 스타트업 입장에서는 "내가 원하는 곳에서 내 데이터로 돌리는" 유연성이 아쉬웠다.
OpenAI는 이 세 가지를 모두 "충분히 만족스럽지 않다"고 판단했다. 그래서 하네스와 컴퓨팅을 분리한다는 아키텍처 결정을 내렸다.
핵심 설계 — 하네스 + 컴퓨팅 분리
"하네스와 컴퓨팅을 왜 분리하나?"라는 질문에 OpenAI는 보안 관점에서 답한다.
모델이 생성한 코드가 실행되는 환경에 자격증명을 그대로 노출하면 안 된다. 프롬프트 인젝션(prompt injection)과 데이터 엑스필트레이션(exfiltration) 공격의 직접 표적이 되기 때문이다. 또한 장시간 실행되는 에이전트는 환경 손실이나 만료에서 복구되어야 한다.
해답은 둘을 분리하는 것이다.
- 하네스: 에이전트 루프, 메모리, 오케스트레이션, 관찰 가능성을 책임
- 샌드박스: 실제 코드 실행, 파일시스템, 네트워크, 도구 호출을 책임
이 분리가 이번 발표의 모든 기능을 관통하는 설계 철학이다.
무엇이 새로워졌나 — 하네스 쪽
Configurable memory
에이전트가 이전 실행의 교훈을 다음 실행에 재사용할 수 있다. Progressive disclosure 방식으로, 모든 것을 컨텍스트에 밀어넣지 않고 필요할 때 불러온다.
Sandbox-aware orchestration
서브에이전트를 격리된 샌드박스로 라우팅할 수 있다. 메인 에이전트는 오케스트레이션만 담당하고, 실제 위험한 작업은 격리 환경에서 수행된다.
Codex-like filesystem tools
OpenAI Codex에서 쓰던 파일시스템 도구(read, write, edit)가 표준으로 들어왔다. AI가 IDE를 쓰는 것처럼 파일을 다룬다.
MCP (Model Context Protocol) 표준 지원
Anthropic이 오픈소스화한 MCP를 OpenAI Agents SDK가 네이티브로 지원한다. 이는 업계 표준화 신호로 읽힌다. 어떤 모델 제공자든 MCP 호환 도구라면 재사용 가능한 생태계다.
Skills와 AGENTS.md
두 개념이 유난히 눈에 띈다.
Skills는 에이전트에게 특정 도메인 능력을 progressive하게 공개하는 추상화다. 모든 것을 시스템 프롬프트에 박아넣는 방식이 아니라, 필요할 때 해당 Skill을 로드한다.
AGENTS.md는 프로젝트별 커스텀 지시사항을 담는 파일이다. Claude Code를 써본 개발자라면 이게 무엇인지 바로 알 것이다 — CLAUDE.md와 거의 동일한 컨셉이다. 네이밍만 다를 뿐, "프로젝트 루트에 AI 지시사항 파일을 두는 관례"가 OpenAI 쪽에도 정식으로 들어온 것이다.
Shell tool / Apply patch tool
셸 명령 실행과 파일 패치 적용이 1급 도구로 제공된다. 에이전트가 진짜로 "터미널을 쓰는 존재"가 됐다는 뜻이다.
무엇이 새로워졌나 — 샌드박스 쪽
기본 제공자 7곳
OpenAI는 "바로 쓸 수 있는" 샌드박스 제공자 7곳을 발표했다. Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, Vercel. 각각 장단이 있고, 개발자가 선택할 수 있다. 자체 인프라에 샌드박스를 구축하는 BYO(Bring Your Own) 옵션도 열려 있다.
Manifest 추상화
가장 인상적인 설계 중 하나다. Manifest는 에이전트 워크스페이스를 기술하는 이식 가능한 포맷이다. 담기는 내용은 다음과 같다.
- 로컬 파일 마운트 정의
- 출력 디렉토리 정의
- 스토리지 통합 (AWS S3, Google Cloud Storage, Azure Blob Storage, Cloudflare R2)
- Git 리포지토리 클론 설정
샌드박스 컨테이너가 종료되어도 Manifest만 있으면 동일한 환경을 재구성할 수 있다. "무상태(stateless) 에이전트 워크스페이스"가 가능해진 것이다.
Durable execution
에이전트 상태를 외부화한다. 샌드박스 컨테이너가 손실되어도 에이전트 실행은 유지된다. Snapshotting과 rehydration이 내장되어, 기존 환경이 실패하거나 만료되면 새 컨테이너에서 마지막 체크포인트부터 재개한다.
장시간 에이전트 작업 — 예를 들면 대용량 리서치나 코드베이스 리팩토링 — 을 안심하고 돌릴 수 있는 기반이다.
Permissions
Manifest 엔트리별로 파일 권한을 설정한다. Unix 파일시스템 권한에 매핑되는 방식이다.
예시를 들면 이렇다.
dataroom/→ 읽기 전용 (에이전트가 원본을 실수로 수정하지 못함)output/→ 쓰기 가능 (결과물만 여기로 나옴)config/→ 접근 불가
이는 단순한 편의 기능이 아니라, 프롬프트 인젝션 공격에서 에이전트가 할 수 있는 피해를 구조적으로 제한하는 보안 계층이다.
확장성
에이전트 실행 하나에 샌드박스 하나 또는 다수를 쓸 수 있다. 필요할 때만 샌드박스를 호출하고, 서브에이전트를 격리 환경으로 라우팅하며, 컨테이너 병렬화로 빠르게 실행한다. 비용과 성능을 동시에 잡는 구조다.
가용성과 가격
- 일반 가용(GA): 모든 OpenAI API 고객 대상
- 가격: 표준 API 가격 (토큰 + 도구 사용 기반). 별도 요금제 없음
- 언어 지원: Python 우선 (v0.14.0부터). TypeScript는 향후 단계
- 로드맵: Code mode와 Subagents를 Python과 TypeScript 양쪽에 확대 예정
현 시점 기준 OpenAI Agents SDK는 월간 Python 약 1,470만 다운로드, TypeScript 약 150만 다운로드, GitHub 스타 19,000+, 기여자 250+의 생태계를 이미 확보한 상태다. 이 위에 Sandbox Agents가 얹혔다는 의미를 가볍게 보기 어렵다.
해석 — Claude Code가 열고 OpenAI가 정리한 방향
개인적인 해석을 붙이자면, 이번 발표는 Anthropic의 Claude Code가 1-2년간 보여준 방향 — "AI에게 셸과 파일시스템을 주면 개발 작업이 비약한다" — 을 OpenAI가 모델 제공자 관점에서 표준화한 것으로 보인다.
네이밍만 봐도 힌트가 많다.
| OpenAI Agents SDK | Anthropic Claude Code |
|---|---|
| AGENTS.md | CLAUDE.md |
| Skills | Skills |
| Shell tool | Bash tool |
| Apply patch tool | Edit tool |
두 회사가 같은 결론에 도달했다는 건, "AI 에이전트 = 채팅하는 모델"이라는 정의가 공식적으로 깨지고 있다는 뜻이다. 새 정의는 "에이전트 = 파일 읽고 쓰고, 코드 돌리고, 도구를 사용하는 반자율 개체"에 가깝다.
MCP를 양사가 모두 지원한다는 것도 중요하다. 도구 표준화가 일어나면 에이전트 생태계의 진입 장벽이 크게 낮아진다.
실전 활용 — 1인 기업과 소규모 팀 관점
현업 관점에서 이 업데이트가 당장 어떤 차이를 만드는지 짚어보자.
1) Supabase/S3 연결로 "진짜 백엔드 에이전트" 만들기
Manifest에 S3나 Cloudflare R2 연결을 기술하면, 에이전트가 직접 데이터를 읽고 결과물을 저장한다. 기존에는 에이전트 실행 전후로 "데이터 준비 → 실행 → 결과 저장"을 사람이 래퍼로 감싸야 했다. 이제는 Manifest 하나로 해결된다.
2) 야간 자동화 작업
Durable execution 덕분에 장시간 에이전트 작업이 안전해졌다. 예를 들어 "밤사이 50개 블로그 포스트를 다국어로 번역하고, 카테고리별 요약을 만들어 Supabase에 저장"하는 작업을 걸어두고 잠들 수 있다. 도중에 컨테이너가 죽어도 체크포인트에서 재개된다.
3) 보안 경계가 있는 코드 생성
Permissions 덕분에 "에이전트가 src/만 쓰고 .env는 못 보게" 하는 게 구조적으로 보장된다. 개인 개발자가 흔히 하는 실수 — "에이전트에게 풀 액세스 주고 자격증명 노출" — 이 구조적으로 막힌다.
4) 서브에이전트 격리
복잡한 작업을 서브에이전트로 쪼개고, 각각 다른 샌드박스에서 병렬 실행한다. 이 패턴이 프로덕션 레디로 정리됐다.
남은 과제와 고려사항
완전히 장밋빛인 건 아니다. 몇 가지는 계속 관찰할 지점이다.
TypeScript 지원 지연: 프론트엔드/풀스택 개발자 기준으로 Python 우선 정책은 아쉽다. 로드맵에 TS가 있긴 하지만 시점은 미정이다.
샌드박스 제공자 록인: 7개 제공자 중 어느 하나에 깊게 맞추면 다른 곳으로 옮기기 어려울 수 있다. Manifest가 이식성을 약속하긴 하지만, 실제 서비스별 차이가 얼마나 잘 흡수되는지는 써봐야 안다.
비용 모델 예측 어려움: 샌드박스 컴퓨팅 비용 + 토큰 비용 + 도구 사용 비용이 섞이면 청구서 예측이 까다로워진다. 초기 단계에서 비용 모니터링을 꼼꼼히 해야 한다.
프롬프트 인젝션 100% 해결은 아님: 하네스/컴퓨팅 분리는 피해를 제한할 뿐, 인젝션 자체를 막지 못한다. 입력 검증, 권한 최소화, 감사 로그는 여전히 개발자 책임이다.
결론 — "AI 에이전트"의 기본값이 바뀌었다
이번 Agents SDK 진화를 한 마디로 요약하면 이렇다. "AI 에이전트"의 기본값이 채팅하는 모델에서 컴퓨터를 쓰는 동료로 이동했다.
Claude Code가 개발자 에디터 쪽에서 보여준 방향을, OpenAI가 범용 SDK로 정리했다. MCP라는 공통 표준이 그 위에 얹힌다. 이제는 "에이전트에게 컴퓨팅 자원을 줄 것인가 말 것인가"의 논쟁이 아니라, "어떤 권한으로, 어떤 격리 수준으로, 어떤 스토리지와 연결해 줄 것인가"의 실전 설계 문제가 됐다.
1인 기업과 소규모 팀 입장에서 이 변화는 기회다. Durable execution과 Manifest가 제공하는 "밤사이 돌려놓을 수 있는 에이전트"는 작은 팀의 레버리지 그 자체다. 지금 바로 익혀야 할 스택이 하나 더 늘었다.
