OpenAI Agents SDK sandbox는 언제 쓰나 2026, Manifest·격리실행·복구성 분기표

2026년 4월 15일 OpenAI는 Agents SDK에 model-native harness와 native sandbox execution 기능을 추가했다고 발표했다.

같은 공식 문서는 Sandbox agents를 Python Agents SDK에서 사용할 수 있고, 파일, 명령, 패키지, 포트, 스냅샷, 메모리가 필요한 컨테이너 기반 작업에 쓰라고 설명한다.

이 문장만 보면 바로 이런 생각이 든다.

이제 에이전트는 전부 sandbox에 넣어야 하나.

저도 처음엔 그쪽으로 마음이 갔다.

파일을 만지고, 명령을 실행하고, 복구 가능한 상태까지 남긴다니 꽤 반짝인다.

근데 실제 운영자로 보면 반짝이는 기능은 늘 두 번째 문제다.

첫 번째 문제는 따로 있다.

그 실행 환경을 누가 만들고, 누가 비용을 내고, 누가 사고가 났을 때 설명하느냐다.

그래서 이 글은 OpenAI Agents SDK 업데이트 요약이 아니다.

공식 발표와 Sandbox agents 문서를 기준으로, 이 샌드박스를 언제 쓰면 값이 나고 언제는 과한지 운영자 언어로 바꾸는 글이다.

정확히는 Manifest, 격리 실행, snapshot, session_state, memory, hosted provider를 한 번에 보고 결정하는 분기표다.

내가 기존에 Codex, Claude Code, Obsidian 발행 파이프라인, 에이전트 하네스 글들을 쓰면서 계속 부딪힌 기준도 같이 넣었다.

이건 장기 운영 후기라기보다는 도입 전 설계 메모에 가깝다.

그래도 실무에서 제일 필요한 건 보통 이쪽이다.

기능 목록보다 먼저 봐야 하는 선 긋기 말이다.

먼저 답

OpenAI Agents SDK sandbox는 에이전트가 파일과 명령을 실제로 다뤄야 할 때 값이 난다.
단순 질의응답, API 호출 몇 개, 읽기 전용 요약 작업에는 자주 과하다.
Manifest는 모델에게 “작업실 구조”를 알려주는 운영 계약서처럼 봐야 한다.
보안의 핵심은 sandbox 자체보다 harness와 compute를 분리하는 설계다.
복구성의 핵심은 RunState, session_state, snapshot을 같은 말로 뭉개지 않는 것이다.
로컬 실험은 Unix-local이나 Docker로 충분한 경우가 많고, hosted provider는 스케일, 격리, 프리뷰, 저장소 마운트가 필요할 때 넘어가면 된다.
내 기준으로는 “agent가 shell을 써야 하는가”와 “실패 후 이어달려야 하는가”가 첫 번째 분기점이다.

한 줄로 줄이면 이렇다.

OpenAI Agents SDK sandbox는 똑똑한 챗봇을 만드는 기능이라기보다, 작업 공간을 가진 에이전트를 제품 안에 넣기 위한 실행 계층이다.

이 차이를 못 잡으면 샌드박스는 안전장치가 아니라 운영비 증폭기가 된다.

이번 업데이트에서 실제로 바뀐 것

OpenAI 공식 발표는 이번 Agents SDK 업데이트를 크게 세 덩어리로 설명한다.

첫째는 agent loop를 위한 더 강한 harness다.

둘째는 native sandbox execution이다.

셋째는 security, durability, scale을 위해 harness와 compute를 분리하는 구조다.

여기서 중요한 건 단어보다 방향이다.

OpenAI는 Agents SDK를 단순한 “모델 호출 래퍼”로 밀고 있지 않다.

에이전트가 파일을 읽고, 명령을 실행하고, 코드를 수정하고, 긴 작업을 이어가는 런타임 쪽으로 끌고 간다.

공식 발표의 예시 코드도 그쪽이다.

SandboxAgent를 만들고, Manifest로 로컬 디렉터리를 data에 마운트하고, UnixLocalSandboxClient로 실행한다.

즉 모델에게 문서 내용을 프롬프트로 길게 붙이는 방식이 아니라, 모델이 예측 가능한 작업 공간 안에서 파일을 보고 답하게 만드는 흐름이다.

이게 꽤 큰 차이다.

프롬프트에 파일 내용을 다 때려 넣는 방식은 단순하고 빠르다.

하지만 파일이 많아지고, 중간 산출물이 생기고, 명령 실행이 필요해지면 금방 지저분해진다.

그때 sandbox가 등장한다.

작업 공간을 만들고, 입력을 마운트하고, 출력 위치를 정하고, 필요하면 패키지를 설치하고, 실패하면 상태를 이어받게 한다.

이건 챗봇 UX라기보다 작업자 런타임에 가깝다.

그래서 TECHTAEK 관점에서 볼 포인트는 신기능 자체가 아니다.

내 서비스나 내부 자동화가 정말 작업자 런타임을 필요로 하는지부터 봐야 한다.

Manifest는 작업실 계약서다

공식 발표는 Manifest를 agent workspace를 설명하기 위한 abstraction이라고 부른다.

로컬 파일을 마운트하고, output directory를 정의하고, AWS S3, Google Cloud Storage, Azure Blob Storage, Cloudflare R2 같은 storage provider에서 데이터를 가져올 수 있다고 설명한다.

이걸 개발자 관점으로 번역하면 이렇다.

Manifest는 모델에게 “여기가 네 작업실이고, 여기에 입력이 있고, 결과물은 여기로 내라”라고 알려주는 구조다.

좋은 Manifest는 화려하지 않다.

오히려 좁고 뻔해야 한다.

에이전트가 들어가자마자 어디를 읽고, 어디에 쓰고, 어디는 건드리면 안 되는지 알 수 있어야 한다.

내가 팀 도구로 설계한다면 최소한 아래 네 칸은 나눌 것이다.

영역	예시	운영 의미
입력	`data/`, `docs/`, `tickets/`	읽어야 할 근거를 모아둔다
작업	`scratch/`, `tmp/`	중간 계산과 실험을 허용한다
출력	`outputs/`, `artifacts/`	사람이 검토할 결과물만 모은다
상태	`sessions/`, `memories/`, `snapshots/`	이어달리기와 회고의 근거를 남긴다

이렇게 나눠두면 모델 지시문도 짧아진다.

data/만 근거로 쓰고, outputs/에 결과를 남기고, 임시 작업은 scratch/에서 하라고 말하면 된다.

반대로 Manifest가 대충 열려 있으면 지시문이 길어진다.

어느 파일을 보라는 말부터, 어디에 쓰지 말라는 말, 이전 산출물은 무시하라는 말까지 계속 붙는다.

이러면 sandbox를 썼는데도 프롬프트가 다시 운영 매뉴얼이 된다.

그건 좀 슬프다.

도구가 있는데 사람이 계속 교통정리하고 있는 셈이다.

샌드박스를 써야 하는 경우

내 기준으로 OpenAI Agents SDK sandbox가 값이 나는 경우는 다섯 가지다.

첫째, 에이전트가 파일 시스템을 실제로 탐색해야 할 때다.

예를 들어 데이터룸 Q&A, 레포지토리 리뷰, 로그 묶음 분석, 계약서 묶음 비교처럼 파일 수가 많고 근거 위치가 중요한 작업이다.

이런 작업은 파일 내용을 프롬프트에 붙이는 순간 한계가 빨리 온다.

어떤 파일을 봤는지, 어떤 파일을 근거로 답했는지, 중간 산출물을 어디에 남겼는지 추적하기 어렵다.

둘째, 명령 실행이 작업의 일부일 때다.

테스트를 돌리고, 패키지를 설치하고, 스크립트를 실행하고, 변환 파일을 만드는 작업은 sandbox 쪽이 자연스럽다.

물론 명령 실행은 위험하다.

그래서 더더욱 host process와 실행 compute를 분리해야 한다.

셋째, 실패 후 복구가 필요한 장기 작업이다.

공식 문서는 sandbox container를 잃어도 agent state를 외부화하면 fresh container에서 복원해 이어갈 수 있다고 설명한다.

이 말은 “길게 돌려도 무조건 안전하다”가 아니다.

상태를 어디에 남기고, 어느 시점에서 checkpoint를 만들고, 실패하면 무엇을 기준으로 재개할지 설계할 수 있다는 뜻이다.

넷째, subagent마다 다른 작업실이 필요할 때다.

한 에이전트는 문서를 읽고, 다른 에이전트는 코드 생성만 하고, 또 다른 에이전트는 테스트만 돌리는 구조라면 같은 작업실을 공유하는 게 오히려 위험할 수 있다.

공식 문서도 sandbox agent를 handoff나 agent.as_tool()과 함께 조합할 수 있다고 설명한다.

이때 각 sandbox tool-agent가 자기 RunConfig, sandbox client, manifest, provider options를 가질 수 있다는 점이 중요하다.

다섯째, 로컬 prototype에서 production provider로 옮길 가능성이 있을 때다.

OpenAI 발표는 Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, Vercel 같은 provider를 언급한다.

공식 문서는 fast local iteration에는 Unix-local, local container isolation에는 Docker, managed execution과 storage mount, snapshot, scaling 등이 필요하면 hosted provider로 가라고 설명한다.

이 경로가 보이면 Manifest 추상화가 의미를 갖는다.

처음부터 대단한 클라우드 격리를 쓰겠다는 뜻이 아니다.

나중에 작업실을 옮겨도 agent contract를 크게 흔들지 않기 위한 준비에 가깝다.

샌드박스가 과한 경우

반대로 샌드박스가 과한 경우도 꽤 많다.

첫째, 작업이 읽기 전용 질의응답일 때다.

한두 개 문서에서 답을 찾고 끝나는 작업이면 그냥 검색, retrieval, function calling으로 충분할 수 있다.

파일을 마운트하고 컨테이너를 띄우고 snapshot을 관리하는 순간 일이 커진다.

둘째, 외부 API 호출만 필요한 workflow다.

예를 들어 CRM에서 고객 정보를 가져오고, 결제 상태를 확인하고, support ticket에 답을 남기는 정도라면 sandbox보다 tool permission과 audit log가 더 중요하다.

이때 shell이 없어도 된다면 shell을 넣지 않는 편이 낫다.

셋째, 결과물이 단일 텍스트 답변뿐일 때다.

출력 파일, 중간 산출물, 테스트 로그, 재실행 근거가 없다면 sandbox의 장점이 줄어든다.

모든 작업에 작업실이 필요한 건 아니다.

넷째, 팀에 운영자가 없을 때다.

sandbox provider, snapshot 저장, memory 정리, credential boundary, 로그 보존, cleanup 정책을 볼 사람이 없다면 기능은 빨리 빚이 된다.

처음엔 멋있지만 다음 달에 누가 비용과 실패를 설명할지 애매해진다.

다섯째, 위험한 일을 “샌드박스니까 괜찮다”로 밀어붙일 때다.

이건 제일 피해야 한다.

sandbox는 blast radius를 줄이는 장치지, 판단을 없애는 장치가 아니다.

위험한 외부 write, credential 접근, destructive command는 여전히 별도 승인과 로그가 필요하다.

로컬, Docker, Hosted Provider 분기표

공식 Sandbox agents 문서는 provider 선택을 꽤 현실적으로 나눠둔다.

빠른 로컬 반복에는 Unix-local.

로컬 컨테이너 격리가 필요하면 Docker.

관리형 실행, provider-specific isolation, scaling, previews, storage mounts, snapshots, credentials가 필요하면 hosted provider.

이걸 내 식으로 더 거칠게 바꾸면 아래 표다.

선택지	먼저 쓰는 상황	좋은 점	조심할 점
Unix-local	내 노트북에서 빠르게 동작 확인	설정이 가볍고 디버깅이 쉽다	격리 강도가 약하고 로컬 환경에 기대기 쉽다
Docker	로컬에서도 컨테이너 경계를 보고 싶을 때	dependency와 실행 환경을 고정하기 좋다	이미지 관리와 볼륨 정책이 필요하다
Hosted provider	여러 사용자, 긴 작업, preview, snapshot, storage mount가 필요할 때	운영 기능을 provider에 맡길 수 있다	비용, 권한, 데이터 위치, 장애 대응을 따져야 한다

처음부터 hosted provider로 달리는 게 항상 답은 아니다.

로컬에서 Manifest 구조와 출력 계약이 엉망이면 cloud로 가도 엉망이다.

오히려 더 비싼 엉망이 된다.

그래서 나는 보통 이런 순서를 선호한다.

Unix-local로 agent contract를 잡는다.
Docker로 dependency와 격리 경계를 확인한다.
output artifact와 snapshot 정책을 만든다.
그다음 hosted provider가 필요한지 본다.

이 순서가 느려 보일 수 있다.

근데 운영 사고는 대개 “느리게 확인한 사람”보다 “빨리 올린 사람”에게 더 친절하지 않다.

보안 분기: harness와 compute를 분리하는 이유

OpenAI 발표에서 제일 중요한 문장 중 하나는 harness와 compute 분리다.

공식 발표는 agent system이 prompt injection과 exfiltration attempts를 가정하고 설계되어야 한다고 적는다.

그리고 harness와 compute를 분리하면 model-generated code가 실행되는 환경에서 credential을 멀리 둘 수 있다고 설명한다.

이건 운영자에게 꽤 직접적인 메시지다.

모델이 만든 코드가 돌아가는 곳과, 우리 서비스의 비밀값이 있는 곳을 같은 방으로 두지 말라는 뜻이다.

여기서 sandbox가 보안 기능으로만 보이면 반쪽이다.

진짜 구조는 아래처럼 봐야 한다.

층	맡는 일	대표 리스크
Application server	사용자 인증, 비즈니스 로직, billing, secret 관리	credential 노출
Agent harness	모델 호출, run state, tool orchestration, tracing	잘못된 도구 라우팅
Sandbox compute	파일 작업, shell, code execution, artifact 생성	prompt injection, exfiltration, destructive command

이 세 층을 섞으면 편하다.

편한데 위험하다.

개인 프로젝트에서는 한 프로세스에 다 몰아도 버틸 때가 있다.

팀 제품에서는 이야기가 달라진다.

특히 model-generated code가 실행되는 compute 안에 장기 credential이 들어가면, sandbox를 썼다는 말이 별로 위로가 안 된다.

그래서 외부 write나 비밀값 접근이 필요한 작업은 샌드박스 안에서 직접 처리하게 두지 말고, harness 쪽 승인 흐름이나 별도 service tool로 빼는 편이 낫다.

쉽게 말해, 에이전트에게 열쇠를 통째로 주지 말고 문 앞에서 필요한 만큼만 열어주는 구조다.

이 표현은 멋은 없지만, 운영에는 꽤 잘 먹힌다.

복구성 분기: RunState, session_state, snapshot을 나눠라

Sandbox agents 문서에서 특히 마음에 드는 부분은 state를 세 가지로 나눠 설명하는 대목이다.

RunState, session_state, snapshot.

이 셋을 뭉개면 복구 설계가 바로 흐려진다.

개념	복원하는 것	쓰는 상황
`RunState`	model items, tool state, approvals, active agent position 같은 harness-side state	runner가 중단된 workflow를 이어가야 할 때
`session_state`	sandbox provider가 재연결할 수 있는 serialized sandbox session	앱이나 job system이 provider session state를 직접 저장할 때
`snapshot`	저장된 workspace contents	새 sandbox를 빈 작업실이 아니라 저장된 파일과 산출물에서 시작해야 할 때

이 표는 실무에서 꽤 중요하다.

대화만 이어진다고 작업이 이어지는 게 아니다.

작업실 파일만 남아 있다고 승인 상태가 이어지는 것도 아니다.

컨테이너 세션을 다시 잡는다고 모델이 왜 거기까지 왔는지 자동으로 아는 것도 아니다.

그래서 복구성은 하나의 버튼이 아니다.

어떤 상태를 보존할지 나누는 설계다.

예를 들어 코드 리뷰 에이전트를 만든다고 해보자.

리뷰 대상 repo checkout과 중간 분석 파일은 snapshot 쪽이다.

어떤 tool call을 했고 어떤 approval을 받았는지는 RunState 쪽이다.

provider의 live sandbox session을 다시 잡아야 한다면 session_state 쪽이다.

셋을 분리해두면 장애가 나도 설명이 된다.

반대로 전부 “resume”이라고 부르면 장애가 났을 때 누구를 탓해야 할지부터 헷갈린다.

resume이라는 단어는 예쁘지만, 운영 문서에는 조금 더 못생긴 이름이 필요하다.

memory는 세션 연장이 아니다

공식 문서는 sandbox memory도 따로 설명한다.

여기서 헷갈리기 쉬운 점이 있다.

memory는 SDK-managed conversational Session memory와 별개라고 되어 있다.

Sessions는 message history를 보존한다.

sandbox memory는 prior workspace runs에서 얻은 재사용 가능한 lesson을 파일로 남기는 쪽이다.

이 차이를 놓치면 memory가 만능 저장소처럼 보인다.

그러면 금방 지저분해진다.

내가 추천하는 운영 기준은 단순하다.

대화 이어가기에는 Session.

작업실 복원에는 snapshot.

provider session 재연결에는 session_state.

반복 작업의 교훈 보존에는 sandbox memory.

이 네 가지를 한 파일에 몰아넣으면 나중에 아무도 안 읽는다.

그리고 안 읽히는 memory는 사실상 부채다.

특히 팀에서 여러 agent가 같은 workspace를 쓰면 memory layout을 분리해야 한다.

문서 리뷰 agent의 기억과 코드 수정 agent의 기억이 섞이면 다음 실행에서 이상한 확신이 생길 수 있다.

이럴 때 “모델이 왜 저렇게 답했지”라고 묻기 전에, 기억 저장소부터 봐야 한다.

실제로 붙인다면 최소 설계는 이렇다

내가 이걸 내부 문서 분석 agent에 붙인다고 치면, 처음 설계는 아주 작게 시작할 것이다.

먼저 agent가 할 일을 하나로 제한한다.

예를 들어 “업로드된 자료 묶음을 보고 리스크와 다음 액션을 정리한다” 정도다.

처음부터 코드 실행, 메모리 생성, provider 전환, subagent 조합을 다 넣지 않는다.

작업실 구조는 이렇게 둔다.

workspace/
  data/
    source files only
  scratch/
    temporary notes and extracted tables
  outputs/
    final_summary.md
    evidence_index.md
  state/
    snapshots/
    run_notes/

그리고 instruction은 길게 쓰지 않는다.

data/ 안의 파일만 근거로 쓰고, 중간 표는 scratch/에 만들고, 최종 결과는 outputs/final_summary.md에 남기라고 한다.

출처 파일명은 반드시 남기게 한다.

외부 API 호출이나 credential 접근은 agent shell에서 하지 못하게 한다.

이 정도가 첫 번째 버전이다.

여기서 통과해야 하는 체크는 세 가지다.

agent가 근거 파일명을 안정적으로 남기는가.
output artifact가 사람이 리뷰하기 좋은 형태인가.
실패 후 같은 입력으로 다시 실행해도 설명 가능한 결과가 나오는가.

이 세 가지가 안 되면 provider를 바꿔도 별 소용이 없다.

Cloudflare든 Vercel이든 Docker든, 구조가 흐리면 그냥 실행 장소만 바뀐다.

작업 방식은 그대로 흐리다.

비용은 토큰만 보면 안 된다

OpenAI 발표는 새 Agents SDK capabilities가 API 고객에게 generally available이고, 표준 API pricing 기준으로 token과 tool use에 따라 과금된다고 설명한다.

여기서 많은 사람이 token만 본다.

근데 샌드박스형 agent의 비용은 token만으로 끝나지 않는다.

아래 비용이 같이 붙는다.

비용 종류	예시	놓치면 생기는 일
compute	container runtime, hosted provider 사용량	agent 하나가 아니라 실행 환경 비용이 늘어난다
storage	snapshots, artifacts, mounted data	오래된 작업실이 계속 쌓인다
review	사람 검토 시간, approval flow	자동화했는데 사람이 더 바빠질 수 있다
cleanup	stale session, temp file, memory 정리	다음 실행이 이전 실행에 오염된다
observability	trace, log, replay 데이터	사고 후 복원은 되는데 평소 비용이 늘어난다

그래서 도입 전 질문은 “모델 비용이 얼마인가” 하나로 끝나면 안 된다.

더 중요한 질문은 이쪽이다.

이 agent가 실패했을 때 사람이 몇 분 안에 원인을 재구성할 수 있나.

이 agent가 만든 output을 검토하는 데 몇 분이 드나.

이 workspace와 snapshot을 몇 일 동안 보관할 것인가.

provider 장애가 나면 어떤 상태부터 복구할 것인가.

이 질문에 답이 없으면 아직 sandbox 도입이 빠를 수 있다.

기능은 준비됐는데 운영자가 준비 안 된 상태다.

그럴 때는 작은 function tool부터 시작하는 게 낫다.

내가 쓰는 분기표

아래 표는 내가 실제로 도입 판단할 때 쓸 기준이다.

최종 정답표는 아니지만, 첫 회의에서 꽤 유용하다.

상황	sandbox 필요도	이유
단일 문서 요약	낮음	prompt나 retrieval로 충분한 경우가 많다
여러 파일 근거 비교	중간	파일 구조와 citation이 중요해진다
repo clone 후 코드 리뷰	높음	파일 탐색, 명령 실행, artifact 생성이 필요하다
테스트 실행과 패치 생성	높음	shell, filesystem, output diff가 핵심이다
고객지원 답변 생성	낮음~중간	외부 tool 권한과 audit가 더 중요할 수 있다
데이터룸 Q&A	높음	mounted data와 근거 파일 추적이 중요하다
반복 리서치 메모 작성	중간	snapshot보다 memory와 source hygiene이 중요할 수 있다
장기 실행 multi-agent 작업	높음	RunState, session_state, snapshot 분리가 필요하다

내가 제일 먼저 보는 질문은 두 개다.

agent가 shell을 써야 하나.

agent가 실패 후 이어달려야 하나.

둘 다 아니면 sandbox는 보류한다.

둘 중 하나가 맞으면 작게 실험한다.

둘 다 맞으면 sandbox를 진지하게 검토한다.

이 기준이 단순해서 좋다.

복잡한 기능일수록 첫 분기표는 단순해야 한다.

실수 TOP 7

1. sandbox를 보안 전체로 착각한다

sandbox는 중요하지만 보안 전체가 아니다.

credential boundary, approval, audit log, cleanup policy가 따로 있어야 한다.

2. Manifest를 대충 열어둔다

모든 디렉터리를 넓게 마운트하면 agent가 편해지는 게 아니라 운영자가 불편해진다.

입력, 작업, 출력, 상태 영역을 좁게 나눠야 한다.

3. 로컬 실험 없이 hosted provider부터 간다

provider를 바꾸기 전에 agent contract가 먼저 안정적이어야 한다.

로컬에서 흐린 구조는 클라우드에서도 흐리다.

4. memory를 대화 로그 창고처럼 쓴다

memory는 재사용 가능한 교훈이어야 한다.

모든 실행 로그를 memory로 넣으면 다음 실행이 과거 소음에 끌려간다.

5. snapshot을 백업으로만 본다

snapshot은 backup이기도 하지만 다음 실행의 seed이기도 하다.

무엇을 snapshot에 남길지 정하지 않으면 재개가 지저분해진다.

6. shell 권한을 너무 빨리 연다

shell은 agent가 작업자가 되는 순간이다.

편의 기능이 아니라 권한 등급 상승으로 봐야 한다.

7. “나중에 로그 보자”를 계획이라고 믿는다

로그는 남기는 것보다 읽히는 게 중요하다.

사람이 10분 안에 작업 흐름을 재구성할 수 없으면 운영 로그로는 부족하다.

도입 전 체크리스트

agent가 반드시 파일 시스템을 탐색해야 하는가.
agent가 shell이나 code execution을 실제로 써야 하는가.
입력 파일과 출력 artifact의 위치가 명확한가.
Manifest에서 read, scratch, output, state 영역이 분리되어 있는가.
credential은 sandbox compute 밖에 있는가.
외부 write는 별도 승인 흐름으로 빠져 있는가.
실패 후 이어달리기 기준이 RunState, session_state, snapshot 중 무엇인지 정했는가.
memory에 저장할 것과 저장하지 않을 것을 나눴는가.
provider를 바꿔도 agent instruction이 크게 바뀌지 않는가.
오래된 sandbox session과 snapshot cleanup 정책이 있는가.
사람이 output을 검토하는 시간이 automation 절감 시간보다 작게 유지되는가.
비용을 token, tool use, compute, storage, review time으로 나눠 봤는가.

체크가 절반도 안 되면 아직 이르다.

그럴 때는 sandbox를 붙이기보다 agent가 진짜 해야 할 일을 더 작게 자르는 편이 낫다.

내 운영 기준으로 보는 최종 판단

OpenAI Agents SDK sandbox는 방향이 좋다.

특히 Agents SDK가 model call wrapper를 넘어 작업 공간과 실행 복구성을 다루기 시작했다는 점은 꽤 중요하다.

Manifest로 workspace를 설명하고, provider를 run configuration에서 바꾸고, snapshot과 session state를 분리하는 흐름은 실무형 agent에 필요한 재료다.

하지만 바로 그 이유 때문에 아무 작업에나 붙이면 안 된다.

작업 공간이 생긴다는 건 책임 공간도 생긴다는 뜻이다.

파일을 읽고 쓰고, 명령을 실행하고, 상태를 남기고, memory를 이어받는 순간 agent는 더 이상 답변 생성기가 아니다.

작업자가 된다.

작업자는 자리, 도구, 기록, 관리자, 퇴근 정리가 필요하다.

여기서 퇴근 정리가 제일 덜 멋있는데 제일 중요하다.

내가 개인 프로젝트나 작은 팀에 권한다면 순서는 이렇다.

먼저 function tool과 retrieval로 가능한 일을 끝까지 줄인다.

그래도 파일, 명령, artifact, 복구성이 남으면 sandbox를 본다.

처음은 Unix-local이나 Docker로 Manifest와 output contract를 검증한다.

그다음 hosted provider가 필요한 이유를 한 문장으로 쓴다.

그 한 문장이 안 나오면 아직 아니다.

반대로 그 문장이 명확하면 이제 sandbox는 좋은 선택이 될 수 있다.

예를 들어 이런 문장이다.

우리 agent는 고객별 자료 묶음을 안전한 작업실에 마운트하고, 중간 표를 만들고, 검토 가능한 artifact를 남기며, 실패 후 snapshot에서 이어가야 한다.

이 정도면 샌드박스가 일한다.

그보다 약하면 그냥 신기능 구경값이 될 가능성이 크다.

신기능 구경은 재미있다.

하지만 운영비 청구서는 생각보다 농담을 잘 안 한다.

FAQ

OpenAI Agents SDK sandbox는 모든 agent에 기본으로 넣어야 하나?

아니다.

파일, 명령, 패키지, 포트, snapshot, memory가 필요한 작업이면 검토할 만하다.

단순 답변 생성, 작은 API orchestration, 읽기 전용 요약이면 먼저 더 작은 구조로 끝나는지 보는 편이 낫다.

Manifest는 보안 설정인가?

Manifest는 공식 문서상 agent workspace를 설명하는 abstraction에 가깝다.

로컬 파일 마운트, 출력 디렉터리, storage provider 입력 같은 작업실 구성을 표현한다.

보안에 도움은 되지만, credential boundary나 approval policy를 대체하지는 않는다.

Docker와 hosted provider 중 어디서 시작해야 하나?

대부분은 로컬에서 시작하는 편이 낫다.

빠른 반복은 Unix-local, 로컬 컨테이너 격리는 Docker가 좋다.

managed execution, scaling, preview, storage mount, snapshot, provider-specific isolation이 필요해질 때 hosted provider를 검토하면 된다.

snapshot과 session_state는 뭐가 다른가?

공식 문서 기준으로 snapshot은 저장된 workspace contents를 새 sandbox 시작점으로 쓰는 쪽이다.

session_state는 sandbox provider가 재연결할 수 있는 serialized sandbox session에 가깝다.

둘 다 resume과 관련 있지만, 복원하는 대상이 다르다.

sandbox memory를 켜면 장기 기억 문제가 해결되나?

그렇게 단순하지 않다.

sandbox memory는 prior workspace runs에서 얻은 lesson을 파일로 남기는 쪽이고, SDK conversational Session memory와 다르다.

무엇을 기억하고 무엇을 버릴지 정책이 없으면 memory는 금방 소음 저장소가 된다.

보안상 제일 먼저 봐야 하는 건 뭔가?

agent가 생성한 코드나 명령이 실행되는 compute와, 서비스 credential이 있는 application server를 분리하는 것이다.

OpenAI 발표도 prompt injection과 exfiltration attempts를 가정하고 설계해야 한다고 말한다.

sandbox는 이 분리를 돕는 실행 계층으로 봐야지, 모든 판단을 대신하는 버튼으로 보면 안 된다.

개인 자동화에도 쓸 만한가?

쓸 수는 있다.

다만 개인 자동화에서는 운영비와 복잡도가 더 빨리 체감된다.

내 기준으로는 “실패 후 이어달리기”와 “파일 기반 artifact”가 둘 다 있을 때 개인 프로젝트에서도 sandbox를 고려한다.

OpenAI Agents SDK sandbox는 언제 쓰고 언제 과한가 2026 — Manifest·격리실행·복구성 분기표