배경 및 맥락

2025년까지 에이전트 개발은 대체로 두 갈래였다. 하나는 model-agnostic framework로 빠르게 orchestration을 짜는 방식이고, 다른 하나는 특정 모델 벤더의 API 위에 얇은 루프를 얹는 방식이다. 전자는 유연했지만 frontier model의 강점을 충분히 활용하기 어려웠고, 후자는 모델 친화적이지만 실행 환경과 보안, 상태 관리가 빈약한 경우가 많았다.

이번 OpenAI 발표는 이 병목을 정면으로 겨냥한다. 문서 작업, 코드 편집, shell 실행, 파일 시스템 조작처럼 실제 업무형 에이전트에 필요한 동작을 model-native harness 안에 묶고, 그 아래 실행 계층을 sandbox로 분리했다. 이는 에이전트 시스템의 중심이 프롬프트 설계에서 실행 인프라 설계로 이동하고 있음을 보여준다.

핵심 내용

공식 발표에 따르면 새 Agents SDK는 configurable memory, sandbox-aware orchestration, Codex-like filesystem tools를 포함한 더 강한 harness를 제공한다. 특히 MCP, skills, AGENTS.md, shell tool, apply patch tool 같은 agent primitive를 표준 구성요소로 흡수해 개발자가 반복적으로 붙여야 하던 인프라 코드를 줄이려 한다.

동시에 native sandbox execution이 추가됐다. 개발자는 Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, Vercel 같은 제공자를 쓰거나 자체 sandbox를 연결할 수 있고, Manifest 추상화로 로컬 파일과 출력 디렉터리, S3·GCS·Azure Blob·Cloudflare R2 같은 스토리지 입력을 일관된 방식으로 기술할 수 있다. OpenAI는 harness와 compute를 분리해 credential이 모델 생성 코드가 실행되는 환경에 직접 노출되지 않도록 하고, snapshotting·rehydration으로 컨테이너가 사라져도 실행 상태를 복원할 수 있다고 설명했다.

경쟁 구도 / 비교

기존 agent framework 상당수는 orchestration flexibility는 높지만, sandbox portability나 durable execution은 개발자 몫으로 남겨두는 경우가 많았다. 반대로 managed agent API는 배포는 쉽지만 민감한 데이터 경계와 커스텀 실행 환경 제어가 제한적이었다. OpenAI는 이 틈을 model-native harness와 sandbox ecosystem 결합으로 메우려 한다.

이 접근은 단순 SDK 업데이트라기보다 agent runtime 표준화 시도에 가깝다. 특히 MCP, skills, AGENTS.md를 기본 primitive로 받아들인 점은 에이전트 생태계가 벤더 고유 인터페이스보다 공유 가능한 실행 계약으로 수렴하고 있음을 시사한다. 장기적으로는 어떤 모델을 쓰느냐보다, 어떤 harness가 더 안전하게 장기 작업을 지속하고 외부 도구를 연결하느냐가 경쟁 포인트가 될 가능성이 높다.

의미

이 발표의 산업적 의미는 에이전트 제품의 가치가 응답 품질 자체보다 실행 신뢰성과 운영 가능성으로 옮겨갔다는 데 있다. prompt injection, 데이터 유출, 컨테이너 만료, 장기 작업 중단 같은 현실 문제를 제품 레벨 기능으로 흡수하지 못하면 엔터프라이즈 도입이 어렵다는 점을 OpenAI도 사실상 인정한 셈이다.

실무적으로는 agent PoC를 운영 환경으로 올릴 때 하네스 아키텍처를 별도 레이어로 설계해야 한다. 툴 호출 표면, 상태 스냅샷, 격리 경계, 감사 로그, 재시작 복구를 초기에 정해두지 않으면 모델을 바꿔도 시스템 안정성은 확보되지 않는다.