Agents SDK 차세대 진화 2026 sandbox harness memory 운영 경계표

Agents SDK 이야기는 자칫하면 또 하나의 SDK 업데이트 요약으로 끝난다.

새 기능이 나왔다.

sandbox가 붙었다.

memory가 좋아졌다.

filesystem을 다룬다.

MCP도 붙일 수 있다.

여기까지만 쓰면 개발자 입장에서는 별로 남는 게 없다.

그래서 이 글은 “Agents SDK가 좋아졌다”가 아니라 “에이전트 운영 경계가 어디로 이동했나”를 보는 글이다.

OpenAI 공식 changelog의 2026년 4월 항목은 Agents SDK 업데이트를 세 가지로 요약한다.

controlled sandbox에서 agent를 실행하는 것.

open-source harness를 inspect하고 customize하는 것.

memory가 언제 만들어지고 어디 저장되는지 제어하는 것.

이 세 줄을 운영자 언어로 바꾸면 질문은 꽤 선명해진다.

모델에게 일을 맡기는 게 아니라 일하는 공간과 감독 체계를 같이 설계해야 한다는 뜻이다.

예전에는 agent를 만들 때 프롬프트, tools, model만 보면 되는 것처럼 보였다.

하지만 파일을 읽고, 명령을 실행하고, 결과물을 만들고, 중간 상태를 이어가고, 나중에 기억까지 남긴다면 더 이상 프롬프트 문제가 아니다.

작은 런타임 문제다.

말하자면 에이전트가 이제 책상, 서랍, 작업기록, 출입증을 갖기 시작한 셈이다.

이쯤 되면 “똑똑한가”보다 “어디까지 만지게 할 것인가”가 먼저다.

TECHTAEK식으로 한 줄만 먼저 쓰면 이렇다.

Agents SDK 차세대 진화의 핵심은 모델이 아니라 경계 설계다.

결론 먼저

Agents SDK의 2026년 4월 업데이트는 다음 다섯 경계로 읽는 게 좋다.

경계	질문	운영 결론
model vs harness	모델이 판단하고, 누가 실행을 감독하나	harness는 신뢰 영역에 남겨야 한다
harness vs compute	승인, tracing, billing, recovery를 어디에 둘까	sandbox는 실행 환경이고 harness는 통제실이다
prompt vs filesystem	문서를 prompt에 붙일까, workspace로 줄까	파일 묶음과 산출물이 있으면 filesystem이 낫다
session vs memory	대화 이력과 장기 교훈을 같은 것으로 볼까	session, RunState, sandbox memory를 분리해야 한다
built-in vs custom tools	기본 capability로 충분한가	Shell, Filesystem, Compaction부터 쓰고 부족할 때 확장한다

내 기준으로는 아래 조건 중 셋 이상이면 Agents SDK sandbox와 memory 설계를 진지하게 볼 만하다.

파일을 읽거나 써야 한다.

shell command가 필요하다.

산출물이 Markdown, CSV, JSONL, screenshot, 작은 web preview처럼 남는다.

작업이 한 번에 끝나지 않고 중간 승인 뒤 이어져야 한다.

에이전트가 이전 작업에서 배운 규칙을 다음 실행에도 써야 한다.

MCP나 내부 API를 붙이되 credential과 audit을 분리해야 한다.

반대로 짧은 답변, 단순 요약, 한두 번의 API 호출, 사람이 바로 읽고 끝내는 작업이라면 Responses API나 기본 Agents SDK runtime이 더 단순하다.

기능이 생겼다고 전부 sandbox에 넣으면 운영은 좋아지는 게 아니라 비용과 책임 소재만 두꺼워진다.

이게 오늘의 핵심이다.

왜 지금 Agents SDK를 다시 봐야 하나

2025년의 에이전트 글은 대부분 “tool calling을 어떻게 붙이나”에 가까웠다.

함수를 등록하고, 모델이 tool call을 고르고, 결과를 다시 모델에게 넣는다.

이 구조만으로도 검색, 요약, 일정 생성, 간단한 리포트 작성은 된다.

문제는 그 다음부터다.

코드를 고쳐야 한다.

repo를 읽어야 한다.

파일 여러 개를 비교해야 한다.

명령을 실행해 테스트해야 한다.

결과물을 저장해야 한다.

사용자가 중간에 승인하고, 다음 날 이어서 작업해야 한다.

여기서는 tool calling만으로는 부족하다.

모델이 접근할 수 있는 작업공간, 그 작업공간에서 실행되는 명령, 산출물 저장 위치, 복구 가능한 상태, 감사 가능한 로그가 필요하다.

OpenAI의 sandbox agents 문서는 이 방향을 꽤 직접적으로 말한다.

sandbox는 agent에게 격리된 Unix-like 실행 환경을 제공한다.

filesystem, shell, installed packages, mounted data, exposed ports, snapshots, controlled access가 있는 환경이다.

중요한 건 이 기능 목록이 아니다.

공식 문서가 harness와 compute를 분리해서 설명한다는 점이다.

이 구분이 실무에서 제일 비싸게 배운다.

처음에는 “컨테이너 하나 띄우면 되지 않나”라고 생각하기 쉽다.

하지만 승인, 결제, 로그, 사용자 권한, human review, recovery state까지 그 컨테이너 안에 몰아넣으면 agent가 실행하는 작업과 agent를 통제하는 시스템이 같은 경계 안에 섞인다.

그때부터 사고가 난다.

그리고 사고는 늘 문서보다 빠르다.

harness는 통제실이고 sandbox는 작업실이다

이 글에서 가장 중요한 문장은 이거다.

harness는 통제실이고 sandbox는 작업실이다.

작업실에는 도구가 있어야 한다.

파일도 있어야 하고, 명령도 있어야 하고, 필요한 패키지도 있어야 한다.

하지만 통제실에는 다른 것이 있어야 한다.

누가 이 작업을 시켰는가.

어떤 모델 호출이 일어났는가.

어떤 tool이 어떤 입력으로 호출됐는가.

어디서 승인을 받았는가.

무슨 비용이 발생했는가.

실패하면 어디서 재개할 것인가.

사용자가 이 결과물을 볼 수 있는가.

이걸 sandbox 안에 다 넣으면 프로토타입은 빨라질 수 있다.

하지만 운영은 흐려진다.

작은 팀이 잡아야 할 기본 구조는 이쪽이다.

영역	sandbox에 두기	harness에 두기
파일 편집	작업 repo, input docs, output directory	최종 반영 권한, diff review
명령 실행	test, build, parser, report generator	command allowlist, timeout, retry 정책
credential	좁은 scope의 runtime token	원본 secret store, 사용자 권한
memory	workspace memory artifact	memory 생성 정책, 보존 정책
로그	실행 결과, stdout, 산출물	model call, tool routing, approval, billing
복구	snapshot, session state	RunState, job queue, human handoff

이 구조가 번거로워 보이면 아직 sandbox agent가 필요 없는 작업일 가능성이 높다.

좋은 기준이다.

복잡한 도구는 복잡한 문제에만 붙이는 게 장기적으로 제일 싸다.

filesystem은 긴 prompt의 대체재가 아니다

많은 팀이 처음 agent workflow를 만들 때 문서를 prompt에 때려 넣는다.

한두 파일이면 괜찮다.

문제가 생기는 건 파일이 늘어난 다음이다.

문서가 열 개가 되고, CSV가 붙고, screenshots가 붙고, 중간 산출물이 나오고, 검증 스크립트가 붙으면 prompt는 금방 작업실이 아니라 창고가 된다.

이때 filesystem을 쓰는 이유는 context window를 아끼기 위해서만이 아니다.

더 중요한 이유는 작업의 증거가 남기 때문이다.

agent가 어떤 파일을 읽었는지, 어떤 파일을 만들었는지, 어떤 diff를 냈는지, 어떤 command를 돌렸는지 볼 수 있다.

이건 TECHTAEK에서 계속 말하는 하네스 엔지니어링의 핵심과 같다.

AI에게 일을 시킬수록 말의 품질보다 증거의 품질이 중요해진다.

prompt는 지나가지만 파일과 로그는 남는다.

그래서 filesystem이 필요한 작업은 보통 이런 모양이다.

작업	prompt만으로 충분한가	filesystem이 필요한 이유
짧은 정책 요약	대체로 충분	출처가 적고 산출물이 짧다
repo code review	부족	여러 파일과 diff가 필요하다
data room 요약	부족	문서 묶음과 citation evidence가 필요하다
마이그레이션 패치	부족	수정 파일, 테스트 로그, rollback 근거가 필요하다
블로그 발행 파이프라인	부족	draft, review, preflight, publish contract가 남아야 한다
단순 FAQ 답변	충분	실행 state가 거의 없다

여기서 중요한 건 filesystem을 붙였다고 품질이 자동으로 좋아지지 않는다는 점이다.

workspace 구조가 지저분하면 agent도 지저분하게 일한다.

좋은 workspace는 작고 명확하다.

입력은 input/.

작업은 work/.

산출물은 output/.

검증 로그는 logs/.

이 정도만 나눠도 agent의 실수는 꽤 줄어든다.

반대로 host의 전체 home directory를 통째로 보여주는 식은 피해야 한다.

그건 자동화가 아니라 운영 사고 초대장에 가깝다.

memory는 대화 저장소가 아니다

Agents SDK의 memory 이야기도 조금 조심해서 봐야 한다.

memory라는 단어가 나오면 많은 사람이 대화 이력을 떠올린다.

하지만 sandbox agent 관점에서는 memory를 더 좁게 보는 편이 안전하다.

대화 전체를 계속 들고 가는 것이 아니라 다음 작업에 재사용할 만한 교훈, 사용자 선호, 프로젝트 규칙, 수정된 판단 기준을 정리해 남기는 것이다.

공식 sandbox 문서도 session memory와 sandbox memory를 구분한다.

session은 대화 흐름을 보존한다.

sandbox memory는 workspace run에서 얻은 재사용 가능한 guidance를 파일로 남긴다.

이 둘을 섞으면 두 가지 문제가 생긴다.

첫째, 불필요한 과거 대화가 계속 들어와서 현재 판단을 흐린다.

둘째, 잊어야 할 정보가 memory로 굳어질 수 있다.

그래서 memory를 켤 때는 반드시 네 가지 질문을 먼저 해야 한다.

질문	운영 기준
무엇을 기억할까	사용자 취향보다 작업 규칙과 검증 기준부터
언제 만들까	성공한 run 후, 사람이 승인한 correction 후
어디 저장할까	workspace, persistent mount, 별도 memory store를 구분
언제 읽지 않을까	보안 민감 작업, 일회성 실험, 오염 가능성이 큰 run

내가 작은 팀에서 설정한다면 처음부터 live memory update를 크게 열지 않을 것이다.

먼저 read-only memory로 시작한다.

그 다음 사람이 승인한 correction만 memory 생성 후보로 넣는다.

마지막으로 memory diff를 review하는 작은 절차를 둔다.

약간 귀찮지만 이 귀찮음이 나중에 팀을 살린다.

에이전트 memory는 기억력 좋은 동료가 아니라 잘못 적으면 오래 남는 운영 문서다.

문서 관리하듯 다뤄야 한다.

capabilities는 기본값부터 의심 없이 쓰지 말자

OpenAI sandbox 문서에서 SandboxAgent는 capability를 붙여 sandbox-native behavior를 제공한다.

기본 capability에는 Filesystem, Shell, Compaction이 포함된다.

필요하면 Skills, Memory 같은 capability를 더 붙일 수 있다.

이 구조는 편하다.

하지만 운영자는 편한 기본값도 한 번은 체크해야 한다.

기본값이 나쁘다는 뜻이 아니다.

기본값이 모든 제품의 위험 모델과 맞지는 않는다는 뜻이다.

예를 들어 내부 문서 요약 agent가 shell이 꼭 필요할까.

파일 생성은 필요한데 shell command는 막아야 하지 않을까.

Memory는 읽기만 하고 생성은 막는 게 낫지 않을까.

Skills는 lazy loading이 낫나, 작은 bundle을 upfront로 넣는 게 낫나.

이 질문을 하지 않으면 agent는 점점 만능 작업자가 된다.

그리고 만능 작업자는 디버깅하기 제일 어렵다.

작은 팀용 capability 체크는 이렇게 시작하면 된다.

capability	처음 켤 때 기준	꺼야 하는 신호
Shell	test/build/parser 실행이 필수다	단순 읽기 작업인데 command가 열린다
Filesystem	patch, report, image inspect가 필요하다	결과가 final answer 하나면 충분하다
Compaction	긴 workflow가 자주 생긴다	짧은 요청인데 context 정책이 과하다
Skills	반복 가능한 절차와 scripts가 있다	prompt 한 장으로 충분한 작업이다
Memory	후속 run에서 배운 규칙이 필요하다	일회성, 민감정보, 불확실한 실험이다

여기서 핵심은 기능을 많이 켜는 것이 아니라 필요한 권한만 남기는 것이다.

에이전트 운영의 절반은 무엇을 할 수 있게 할지 정하는 일이고, 나머지 절반은 무엇을 못 하게 할지 정하는 일이다.

재미는 전자에 있고, 사고 예방은 후자에 있다.

둘 다 먹어야 배탈이 덜 난다.

MCP는 tool 목록이 아니라 권한 경계다

Agents SDK와 MCP를 같이 볼 때도 같은 기준이 필요하다.

MCP 서버를 붙이면 agent가 외부 시스템과 말할 수 있다.

문서 검색, 데이터베이스 조회, GitHub 작업, 브라우저 자동화, 사내 API 호출까지 가능해진다.

여기서 중요한 질문은 “몇 개의 MCP 서버를 붙일까”가 아니다.

“각 MCP 서버가 누구 권한으로, 어느 범위까지, 어떤 로그를 남기며 호출되는가”다.

MCP는 기능 확장이 아니라 권한 확장이다.

그래서 sandbox와 MCP를 섞을 때는 credential 경계를 특히 조심해야 한다.

내 기준은 이렇다.

credential 원본은 harness 쪽에 둔다.

sandbox에는 작업에 필요한 좁은 token이나 mount만 넘긴다.

MCP call은 호출 로그와 결과 요약을 남긴다.

위험 tool은 allowlist와 승인 단계를 둔다.

작업 완료 후 산출물을 사람이 확인한 뒤 외부 반영한다.

이걸 지나치게 엄격하다고 볼 수도 있다.

하지만 에이전트가 파일도 만지고, 명령도 실행하고, MCP로 외부 도구까지 부를 수 있다면 그때부터는 “편한 자동화”가 아니라 작은 운영자다.

작은 운영자에게는 작은 사번, 작은 권한표, 작은 로그가 필요하다.

거창한 IAM 시스템부터 사라는 뜻은 아니다.

agent_name, owner, allowed_tools, approval_required, log_path, rollback_plan.

이 여섯 칸짜리 표만 있어도 시작은 된다.

도입 판단표

이제 실전 판단표로 정리해보자.

상황	추천	이유
Q&A, 짧은 요약, 단일 응답	기본 모델 호출	workspace가 필요 없다
tool call 몇 개로 끝나는 업무	기본 Agents SDK	sandbox 복잡도가 과하다
repo를 읽고 patch를 만든다	SandboxAgent	filesystem, shell, artifact가 필요하다
문서 묶음을 읽고 citation report를 만든다	SandboxAgent 또는 data room flow	prompt보다 mounted files가 낫다
사람이 승인 후 다음 단계로 이어간다	RunState + sandbox session_state	harness state와 workspace state가 모두 필요하다
과거 run의 교훈을 재사용한다	Memory capability	session history와 별도 설계가 필요하다
사내 API와 MCP를 함께 쓴다	harness 중심 권한 설계	credential과 audit을 밖에 둬야 한다
빠른 개인 실험	Unix-local 또는 Docker	hosted provider 전 비용을 낮춘다
팀 제품 기능	hosted sandbox 후보 검토	isolation, preview, storage, scale이 필요할 수 있다

이 표에서 제일 많이 틀리는 지점은 세 번째와 네 번째다.

파일을 다루는 순간부터 agent는 answer generator가 아니라 artifact producer가 된다.

artifact producer에게는 작업공간, 출력 규칙, 검증 루틴이 필요하다.

이걸 빼먹으면 결과물은 빨리 나오는데 믿을 수 있는지는 아무도 모르는 상태가 된다.

그 상태로 자동 발행이나 자동 반영까지 가면 나중에 사람이 더 많은 시간을 쓴다.

AI 자동화에서 흔한 역설이다.

빨라졌는데 더 바빠지는 그 맛.

별미라고 하기엔 좀 쓰다.

작은 팀용 운영 체크리스트

Agents SDK 차세대 구조를 바로 제품에 넣고 싶다면 아래 체크리스트부터 채우는 게 좋다.

agent의 목적을 한 문장으로 쓴다.
입력 파일과 출력 파일 위치를 나눈다.
shell command가 꼭 필요한지 결정한다.
command timeout과 allowlist를 정한다.
sandbox에서 볼 수 있는 mount 범위를 좁힌다.
credential 원본은 harness 쪽에 둔다.
sandbox에는 좁은 scope의 runtime credential만 넘긴다.
final answer보다 artifact path를 먼저 설계한다.
사람이 review할 diff 또는 report format을 정한다.
RunState, session_state, snapshot을 같은 말로 쓰지 않는다.
memory는 read, generate, live update를 따로 결정한다.
memory 생성은 승인된 correction부터 시작한다.
MCP server마다 owner와 allowed action을 적는다.
외부 반영 tool은 approval_required로 둔다.
publish, deploy, transfer 같은 tool은 dry-run을 먼저 만든다.
성공 로그보다 실패 로그 위치를 먼저 정한다.
비용 로그를 model call, tool call, sandbox runtime으로 분리한다.
sandbox snapshot을 언제 보존하고 언제 삭제할지 정한다.
장기 실행 job은 queue와 retry 정책을 둔다.
운영 중단 버튼을 만든다.

20번이 웃겨 보일 수 있는데 진짜 중요하다.

자동화에서 가장 좋은 버튼은 가끔 멈추는 버튼이다.

계속 달리는 시스템보다 안전하게 멈출 수 있는 시스템이 오래 간다.

기존 sandbox 글과 다른 점

나는 이미 TECHTAEK에서 OpenAI Agents SDK sandbox를 언제 쓰고 언제 과한지 다룬 적이 있다.

그 글은 Manifest, 격리 실행, snapshot, provider 선택 중심이었다.

이번 글은 관점이 조금 다르다.

이번에는 2026년 4월 Agents SDK 업데이트를 운영 경계의 변화로 본다.

sandbox 자체보다 harness와 compute를 나누는 기준.

filesystem이 prompt를 대체하는 순간.

memory가 session과 분리되어야 하는 이유.

MCP가 tool 목록이 아니라 권한 경계가 되는 순간.

이 네 가지가 핵심이다.

그래서 두 글은 겹치기보다 앞뒤로 붙는 편이 좋다.

도입 여부를 먼저 판단하려면 기존 sandbox 글을 보면 된다.

도입하기로 마음먹었다면 이번 글의 경계표를 보면 된다.

실무 예시 1: 코드 리뷰 agent

코드 리뷰 agent를 만든다고 해보자.

이 agent는 repo를 읽고, 테스트를 돌리고, 의심되는 diff를 찾고, 리뷰 코멘트를 산출해야 한다.

이 작업은 prompt만으로는 불안하다.

파일이 많고, 테스트 로그가 필요하고, artifact가 남아야 한다.

따라서 sandbox가 맞다.

하지만 harness는 sandbox 밖에 두는 편이 낫다.

사용자 인증, repo 접근 권한, GitHub comment 반영, 승인 단계, 비용 로그는 trusted infrastructure가 맡아야 한다.

sandbox는 repo copy와 test command를 다루면 된다.

최종 반영은 harness가 diff와 report를 검사한 뒤 결정한다.

이 구조면 agent가 테스트를 잘못 돌리거나 불필요한 파일을 수정해도 최종 반영 전에 막을 수 있다.

실무 예시 2: 리서치 보고서 agent

리서치 보고서 agent는 조금 다르다.

웹 검색, 문서 묶음, 출처, 요약, 표 생성이 필요하다.

여기서는 shell보다 filesystem과 citation evidence가 더 중요할 수 있다.

input에는 source docs를 넣고, output에는 report와 evidence table을 만들게 한다.

memory는 조심해야 한다.

이전 리서치에서 배운 형식은 재사용해도 되지만 이전 리서치의 사실 판단이 다음 리서치에 섞이면 위험하다.

따라서 memory에는 “보고서 형식”, “검증 루틴”, “금지 표현” 같은 운영 규칙만 남기는 게 낫다.

사실 데이터는 매번 source에서 다시 확인한다.

이건 귀찮아도 리서치 자동화의 생명줄이다.

실무 예시 3: 블로그 발행 agent

블로그 발행 agent는 내 작업흐름과도 직접 닿는다.

draft를 만들고, review report를 만들고, preflight를 통과시키고, publisher를 실행하고, published_url을 다시 frontmatter와 sheet에 반영한다.

이런 작업은 완전히 filesystem형이다.

최종 결과는 글 본문 하나가 아니라 draft, review, preflight log, publish contract, sheet status까지 이어진다.

여기서 harness가 해야 할 일은 분명하다.

어떤 idea_id를 처리했는지 기록한다.

채널 규칙을 적용한다.

preflight 실패를 막는다.

publisher 결과를 확인한다.

발행 후 sheet와 frontmatter를 맞춘다.

sandbox가 있다면 글 작성과 검증 스크립트 실행까지는 맡길 수 있다.

하지만 실제 발행 버튼은 여전히 review와 contract를 통과한 뒤 눌러야 한다.

자동화가 잘될수록 마지막 게이트는 더 중요해진다.

바로 쓰는 설계 템플릿

작은 팀에서 Agents SDK 기반 agent를 만들기 전에 아래 템플릿을 채워보면 좋다.

항목	작성 예시
agent_name	repo-reviewer
owner	platform team
job_type	code review report
input_mounts	repo/, task.md
output_paths	output/report.md, output/patch.diff
allowed_commands	pytest, npm test, rg
forbidden_commands	deploy, push, rm -rf
mcp_servers	github-readonly, docs-search
approval_required	github-comment, branch-write
memory_mode	read-only first, generate after approved correction
state_policy	RunState for workflow, snapshot for workspace
retention	output 30 days, sandbox 24 hours
rollback	no external write before human review

이 표를 채우는 데 10분 이상 걸린다면 그 agent는 아직 설계가 덜 된 것이다.

반대로 표가 잘 채워지면 프롬프트는 생각보다 짧아도 된다.

agent instructions는 운영 경계를 대신할 수 없다.

경계가 먼저고, 프롬프트는 그 안에서 일하는 규칙이다.

FAQ

Agents SDK sandbox는 모든 agent에 붙여야 하나?

아니다.

파일, command, artifact, resume, memory가 필요하지 않으면 오히려 과하다.

짧은 답변이나 단순 tool call에는 기본 runtime이 더 낫다.

harness를 sandbox 안에 넣으면 안 되나?

프로토타입에서는 가능하다.

하지만 운영에서는 조심해야 한다.

harness는 model call, tool routing, approval, tracing, billing, recovery를 담당한다.

이 통제 영역을 model-directed execution과 같은 compute boundary에 넣으면 권한과 감사 로그가 흐려질 수 있다.

memory를 켜면 agent가 자동으로 좋아지나?

아니다.

memory는 좋은 기억도 남기지만 나쁜 습관도 남길 수 있다.

처음에는 read-only 또는 승인된 correction 기반 generation부터 시작하는 편이 안전하다.

filesystem을 쓰면 hallucination이 줄어드나?

일부 줄어들 수 있다.

하지만 filesystem 자체가 검증은 아니다.

파일 경로, source evidence, command log, output diff를 함께 남겨야 한다.

증거가 없는 filesystem 사용은 긴 prompt와 크게 다르지 않다.

MCP는 sandbox 안에서 돌리는 게 맞나?

항상 그렇지는 않다.

credential과 audit이 중요한 MCP는 harness 쪽에서 통제하고, sandbox에는 좁은 runtime input만 넘기는 편이 안전하다.

핵심은 MCP server의 위치보다 권한과 로그 경계를 명확히 하는 것이다.

기존 OpenAI Agents SDK sandbox 글과 뭐가 다른가?

기존 글은 sandbox 도입 여부와 Manifest, provider, snapshot 판단에 가깝다.

이번 글은 2026년 4월 Agents SDK 업데이트를 harness, compute, memory, filesystem, MCP 경계로 재정리한 운영표다.

도입 전에는 기존 글, 도입 설계 단계에서는 이 글을 보면 된다.

참고 자료

마무리

Agents SDK 차세대 진화를 모델 성능 업데이트로만 보면 핵심을 놓친다.

이번 흐름은 agent가 더 똑똑해지는 이야기이기도 하지만 더 현실적인 작업자가 되는 이야기다.

작업자는 작업실이 필요하다.

작업자는 기록이 필요하다.

작업자는 권한표가 필요하다.

그리고 작업자를 감독하는 통제실도 필요하다.

그래서 내 결론은 단순하다.

Agents SDK를 도입할 때 모델 이름보다 먼저 봐야 할 것은 harness와 sandbox의 경계다.

그 경계가 선명하면 filesystem, memory, MCP는 꽤 강력한 도구가 된다.

그 경계가 흐리면 같은 도구가 운영비와 리스크를 키운다.

AI agent 시대의 좋은 설계는 마법처럼 보이는 기능을 많이 켜는 일이 아니다.

누가 판단하고, 누가 실행하고, 누가 승인하고, 무엇이 남는지 끝까지 구분하는 일이다.

이 재미없는 표가 결국 제일 재미있는 자동화를 만든다.

Agents SDK 차세대 진화 2026 – sandbox·harness·memory·filesystem 운영 경계표