간결한 하네스와 코드를 실행하는 에이전트는 개방형 작업에 더 적합합니다. 지나치게 경직된 오케스트레이션은 모델의 성능을 제한할 수 있기 때문입니다.
이에 따라 코드 실행과 샌드박싱은 이제 에이전트 시스템의 핵심 아키텍처 고려 사항이 되었습니다.
Agents SDK는 코드 실행 에이전트를 구축하는 데 필요한 복잡성과 코드의 양을 줄여주며, 테스트에서는 최대 6배까지 감소했습니다.
오랫동안 에이전트 시스템의 발전은 더 나은 프롬프트 작성, 도구 인터페이스, 컨텍스트 관리, 정교한 제어 흐름 등 오케스트레이션 개선에서 비롯되었습니다. 하지만 코딩 에이전트의 역량이 향상되면서 이러한 균형이 달라지기 시작했습니다.
많은 개방형 워크플로에서 병목 지점은 더 이상 에이전트 루프 자체가 아니라 실행 계층입니다. 바로 모델이 코드를 작성하고 명령을 실행하며 출력을 검토하고 반복 작업을 수행하는 샌드박스입니다. 작업 수준의 추론이 이 환경으로 더 많이 이동함에 따라 모델이 역량을 온전히 발휘할 수 있도록 주변 오케스트레이션은 더 단순해져야 합니다.
새 버전의 Agents SDK가 지원하는 것이 바로 이러한 변화입니다. 얼리 액세스 기간의 테스트 결과, 이 SDK는 프레임워크 로직을 한 겹 더 추가하는 대신 실행 계층을 더욱 모듈화하고 조합 가능하게 만들어 나머지 시스템을 간결하게 유지할 수 있었습니다.
최근 하네스 엔지니어링에서는 하네스를 효과를 발휘하는 최소한의 형태로 줄이는 방식이 주목받고 있습니다. 개괄적으로 말해 하네스는 모델을 둘러싼 소프트웨어입니다. 모델이 안정적으로 작업할 수 있도록 컨텍스트, 도구, 제어 흐름, 피드백 루프를 관리하는 계층입니다.
지난 몇 년간 에이전트 성능의 많은 개선은 이 계층을 강화한 결과였습니다. 더 나은 도구, 메모리와 검색 기능, 더 명시적인 작업 분해, 정교한 오케스트레이션은 시스템의 안정성과 역량을 높이는 경우가 많았습니다. 이러한 패러다임에서 발전이란 대체로 모델을 둘러싼 소프트웨어에 더 많은 작업 로직을 구현하는 것을 의미했습니다.
이제 적어도 일부 개방형 작업에서는 이러한 패턴이 약해지고 있습니다. 점점 더 많은 프로젝트와 논문에서 하네스의 규정성이 강해진다고 해서 성능이 항상 향상되는 것은 아니라고 지적합니다. 코딩 지원, 장기 실행 작업, 브라우저 사용, 긴 컨텍스트 작업에서 같은 패턴이 반복해서 나타납니다. 모델이 충분한 지능을 갖추면 주변 소프트웨어에 지나치게 많은 작업 구조를 강제하는 방식은 이점이 아니라 제약이 될 수 있습니다.
이에 따라 하네스의 역할도 달라지고 있습니다. 하네스는 경직된 오케스트레이션을 통해 작업을 미리 예측하려 하기보다 깔끔한 실행 기반을 제공하는 역할을 점점 더 많이 맡고 있습니다. 즉, 시스템의 인터페이스와 안전장치가 정한 범위 안에서 모델이 상태를 점검하고, 코드를 실행하고, 오류를 복구하며, 접근 방식을 스스로 조정할 수 있는 샌드박스를 제공합니다. 이는 Andrej Karpathy가 Software Engineer 3.0에서 설명한 변화와 유사합니다. 이전에 소프트웨어에 있던 로직의 일부가 상위 계층인 ‘프롬프트’로 이동하는 것입니다.
그렇다고 에이전트 시스템의 모든 구조를 없애야 한다는 뜻은 아닙니다. 특히 범위가 좁거나 처리량이 많거나 성공 기준이 명확한 작업에는 여전히 명시적인 워크플로, 휴리스틱, 결정론적 가드레일이 유용합니다. 앞서 에이전트 시스템 설계를 위한 휴리스틱 게시물에서 설명했듯이, 신뢰할 수 있는 로직 흐름을 구현할 수 있고 그렇게 하는 것이 바람직한 경우에는 강력한 오케스트레이션이 여전히 중요합니다.
개방형 작업에서는 초점이 달라지고 있습니다. 이제 과제는 더욱 정교한 오케스트레이션 계층을 설계하는 것보다 모델이 내부에서 효과적으로 작업할 수 있도록 단순하고 관찰 가능하며 충분히 모듈화된 실행 환경을 구축하는 데 있습니다.
에이전트가 파일을 읽고, 코드를 작성하고, 셸 명령을 실행하며, 장기 실행 작업을 시작할 수 있게 되면 엔지니어링 과제도 달라집니다. 이제 어려운 부분은 단순히 프롬프트 최적화나 도구 라우팅에만 있지 않습니다. 에이전트가 실제 시스템에서 작동하게 되면서 그 역량은 크게 강화되지만, 안전 및 보안과 관련된 영역도 넓어져 훨씬 더 세심한 주의가 필요합니다. 예를 들어 코드를 실행할 수 있는 에이전트는 환경이 제대로 격리되지 않으면 유해한 작업을 수행할 수 있습니다(AISI의 Sandbox Bench 참조).
따라서 샌드박싱은 에이전트 프레임워크에서 핵심적인 고려 사항이 되고 있습니다. 초기 시스템에서는 실행 기능을 하네스에 덧붙인 도구, 즉 부가 기능으로 취급하는 경우가 많았습니다. 하지만 실행에 상태 유지, 장기 실행 또는 원격 작업이 필요해지면 이러한 접근 방식은 한계를 드러냅니다. 샌드박스 자체와 그 수명 주기, 상태, 인터페이스를 관리하고 에이전트 루프와 연동하는 일은 금세 별도의 시스템 설계 문제가 됩니다. 이러한 이유로 OpenAI의 Container API와 셸 도구, Modal, Cloudflare, Daytona, E2B 등 코드 실행을 위한 관리형 환경을 제공하는 업체가 늘고 있습니다.
코드 실행에는 하네스의 나머지 부분보다 더 강력한 격리와 엄격한 런타임 제어가 필요하므로 이러한 경계가 중요합니다. 실제로 코드 실행 에이전트를 잘못 구현하면 컴퓨팅 비용 통제 실패, 내부 시스템을 파괴하는 작업, 민감한 정보 노출이라는 세 가지 중대한 비즈니스 위험이 발생할 수 있습니다. 적절한 컨테이너화, 격리, 런타임 안전장치를 적용하면 이러한 위험을 실제 배포에 허용할 수 있는 수준으로 억제할 수 있습니다.
이를 이해하는 한 가지 방법은 에이전트에게 사무실 전체의 열쇠를 주는 대신 밀폐된 전용 작업 공간을 제공한다고 생각하는 것입니다. 에이전트는 그 공간 안에서 여전히 유용한 작업을 수행할 수 있지만, 명확히 규정된 범위를 벗어날 수는 없습니다. 에이전트가 사용할 수 있는 컴퓨팅 자원의 양을 제한하고, 접근 가능한 시스템과 파일을 지정하며, 처음부터 어떤 정보를 제공할지도 통제할 수 있습니다.
이렇게 해도 위험이 완전히 사라지지는 않지만, 문제의 성격은 ‘인프라 안을 제약 없이 돌아다니는 에이전트’에서 ‘통제된 환경 안에서 작동하는 에이전트’로 바뀝니다. 이 계층이 에이전트 시스템의 표준 구성 요소가 되려면 프레임워크 자체에서 핵심 기능으로 지원해야 합니다. 그러면 샌드박스는 개발자가 빠르게 도입하고 제공업체 간에 교체할 수 있으며, 에이전트 로직을 계속 수정하지 않고도 확장 가능한 이식성 높은 기본 요소를 갖춘 모듈식 실행 계층이 됩니다.
에이전트가 코드를 실행하면 샌드박스 자체에도 오케스트레이션이 필요합니다. 로컬 개념 증명에서 원격 실행, 여러 백엔드 또는 장기 실행 세션으로 확장하면 운영 부담이 기하급수적으로 증가합니다. 환경을 생성하고 중지하거나 일시 중지 후 재개하고, 상태를 스냅샷으로 저장하고, 나중에 다시 연결하는 모든 작업을 여러 제공업체에서 일관되게 관리할 방법이 필요합니다.
개념적으로 화려한 기능은 아니지만 실무에서는 중요합니다. 특히 에이전트 프레임워크에 통합되어 있지 않다면, 팀마다 에이전트 파이프라인을 처음부터 다시 구축할 때 바로 이런 인프라가 큰 부담이 됩니다…
이 지점에서 더 나은 프레임워크 지원이 중요해집니다. 저희는 새로운 OpenAI Agents SDK를 얼리 액세스로 이용해 직접 샌드박스형 에이전트를 구축했습니다. 특히 눈에 띈 점은 아키텍처의 중심이 달라졌다는 것입니다. 이 SDK는 실행을 주변적인 도구가 아니라 핵심 계층으로 취급합니다. 실제로 더 적은 코드로 샌드박스형 에이전트를 시작하고, 샌드박스의 스냅샷을 만들거나 실행을 재개할 수 있으며(일부 테스트에서는 약 6배 감소), 주변 에이전트 로직을 다시 작성하지 않고도 백엔드를 전환할 수 있습니다.
이처럼 역할을 명확히 분리하면 하네스는 추론, 컨텍스트, 워크플로에 집중할 수 있습니다. 실행 계층은 격리, 이식성, 런타임 상태에 집중할 수 있습니다. 이러한 추상화 덕분에 역량이 뛰어나면서도 발전시키기 쉬운 코딩 에이전트를 구축할 수 있습니다. 로컬 실행과 원격 실행 사이를 오가고, 더 오래 실행되는 작업을 지원하며, 전체 시스템을 재설계하지 않고도 실행 백엔드를 변경할 수 있습니다.
더 많은 작업 수준의 로직이 하네스에서 모델로 이동하면서 시스템 복잡성의 일부도 실행 계층으로 함께 이동합니다. 코드 실행과 샌드박싱은 이제 에이전트 시스템의 핵심 아키텍처 고려 사항이며, 코딩 비중이 높거나 개방형인 작업에서 특히 중요합니다. 이제 에이전트 파이프라인을 설계하는 것만큼 에이전트가 장기간 안전하고 안정적으로 작업할 수 있는 환경을 설계하는 일도 중요합니다.
샌드박스형 실행을 위한 상위 수준의 추상화가 중요한 이유가 바로 여기에 있습니다. 새로운 OpenAI Agents SDK는 실행을 시스템의 모듈식 계층으로 취급함으로써 이러한 방향으로 나아갑니다. 여러 백엔드로 이전할 수 있고, 장기 실행 작업에서도 상태를 유지하며, 새로운 구성마다 동일한 인프라를 다시 구축하지 않고도 간편하게 사용할 수 있습니다.
더 넓게 보면 차세대 에이전트 프레임워크를 결정하는 요인은 추가하는 오케스트레이션 로직의 양보다 에이전트가 점점 더 의존하게 될 실행 환경을 얼마나 잘 구조화하는지가 될 가능성이 큽니다.