Claude Code와 Codex를 샌드박스에서 돌려야 하는 이유

Claude Code와 Codex를 실무에 붙일 때 제일 위험한 질문은 “어느 모델이 더 똑똑하냐”가 아니다. 더 먼저 물어야 할 건 이 에이전트가 어디서 실행되고, 무엇을 읽고, 무엇을 기억하고, 실패하면 어디까지 되돌릴 수 있느냐다.

요즘 에이전트 논쟁은 성능표에서 샌드박스와 거버넌스로 옮겨가고 있다. 2026년 5월 27일 리서치 스냅샷에서도 GitHub Trending에는 microsoft/agent-governance-toolkit, thedotmack/claude-mem 같은 governance와 memory 경계 신호가 잡혔고, YouTube 대체 검색 상위 5개 중 3개가 Claude/Codex sandbox, Vercel Sandbox, Claude container 실행 주제였다. 한국 개발자 표면에서도 ClickFix 공격, GPU 점유 낭비, 바이브코딩 첫 수익과 이벤트 트래킹처럼 “AI로 빨리 만들기” 이후의 운영 문제가 같이 떠올랐다.

내가 보기엔 이 흐름의 결론은 선명하다. 코딩 에이전트는 이제 채팅창이 아니라 실행 주체다. 실행 주체라면 기본 작업장은 로컬 전체가 아니라 샌드박스여야 한다.

샌드박스는 에이전트를 약하게 만드는 장치가 아니다

많은 팀이 샌드박스를 “제한”으로만 이해한다. 파일을 못 읽게 하고, 네트워크를 막고, 명령 실행을 줄이면 에이전트가 덜 유용해진다고 느낀다. 그런데 실제 운영에서는 반대에 가깝다. 샌드박스가 있어야 더 과감하게 맡길 수 있다.

Claude Code나 Codex류 에이전트는 단순히 답변을 생성하지 않는다. 저장소를 읽고, 패키지를 설치하고, 테스트를 돌리고, diff를 만들고, 때로는 브라우저나 배포 도구까지 건드린다. 이 행동들이 한 개발자 노트북의 전체 파일시스템, 개인 토큰, 회사 계정 세션과 바로 붙어 있으면 실수의 반경이 너무 넓어진다.

샌드박스의 목표는 에이전트를 불신하는 게 아니다. 실패 반경을 명확히 만드는 것이다.

좋은 에이전트 실행 환경
= 충분히 시도할 수 있는 자유
+ 실제 시스템을 바로 망가뜨리지 못하는 경계
+ 나중에 재현할 수 있는 실행 기록

이 구조가 있으면 에이전트는 더 많은 실험을 해도 되고, 사람은 결과만 보고 승인할 수 있다. 반대로 경계가 없으면 작은 자동화도 계속 긴장 상태로 운영해야 한다. 생산성을 올리려고 붙인 도구가 사람의 검증 피로를 키우는 셈이다.

권한은 파일, 셸, 네트워크, 시크릿으로 쪼개야 한다

코딩 에이전트 권한을 “허용/차단” 하나로 보면 금방 막힌다. 실제로는 권한을 네 갈래로 쪼개야 한다.

첫째, 파일시스템 권한이다. 에이전트가 현재 저장소만 읽는지, 홈 디렉터리까지 읽을 수 있는지, 쓰기는 어느 경로에 가능한지 분리해야 한다. 실험 브랜치와 임시 워크트리를 기본값으로 두면 좋다. 특히 개인 문서, SSH 키, 환경 변수 파일, 브라우저 프로필은 코딩 에이전트의 일반 문맥에 섞이면 안 된다.

둘째, 셸 권한이다. 테스트 실행과 포매터 실행은 자동 허용할 수 있지만, 삭제 명령, migration, deploy, package publish, credential helper 호출은 다른 등급이다. 명령을 allowlist로 나누고, 위험 명령은 사람 승인 또는 별도 세션으로 보내야 한다.

셋째, 네트워크 권한이다. 에이전트가 모든 외부 URL에 접근할 수 있으면 코드 조각, 로그, 환경 정보가 의도치 않게 밖으로 나갈 수 있다. 문서 조회는 허용하더라도 임의 POST, 임의 webhook, 외부 paste 서비스 호출은 막는 편이 낫다.

넷째, 시크릿 권한이다. 이게 제일 중요하다. 코딩 에이전트에게 production key를 그대로 주는 건, 실수할 수 있는 junior engineer에게 prod 콘솔을 항상 열어주는 것과 비슷하다. task-scoped token, mock key, sandbox credential, read-only token을 기본값으로 둬야 한다.

권한 모델은 아래처럼 작게 시작하는 게 현실적이다.

read repository      -> 기본 허용
write working tree   -> 허용, diff 기록 필수
run tests            -> 허용, command log 필수
install dependency   -> 승인 필요
network external API -> domain allowlist 필요
deploy / publish     -> 사람 승인 없이는 금지
production secrets   -> 기본 비노출

이렇게 나눠두면 “에이전트를 쓸 수 있나”가 아니라 “어떤 업무는 자동화하고 어떤 업무는 승인할까”로 논의가 바뀐다. 그게 운영 가능한 거버넌스다.

메모리는 생산성 기능이면서 유출 경로다

이번 리서치에서 TypeScript 트렌딩에 claude-mem 같은 memory 관련 프로젝트가 잡힌 것도 의미가 있다. 에이전트가 기억을 잘 쓰면 생산성은 올라간다. 매번 프로젝트 구조를 다시 설명하지 않아도 되고, 이전 결정과 팀 규칙을 이어받을 수 있다. 문제는 memory가 곧 데이터 경계가 된다는 점이다.

에이전트 메모리는 세 가지를 구분해야 한다.

• 작업 메모리: 현재 세션에서 읽은 파일, 로그, diff, 사용자 지시
• 장기 메모리: 프로젝트 규칙, 선호도, 의사결정 기록, 반복되는 실수
• 외부 메모리: 검색 인덱스, 팀 wiki, 이슈, 메일, 고객 데이터

이 셋이 섞이면 편해 보이지만 위험하다. 예를 들어 개인 계정 메일에서 본 내용을 코딩 세션 장기 메모리에 남기고, 나중에 다른 저장소 작업에서 그 문맥이 다시 등장하면 데이터 경계가 깨진다. 반대로 아무것도 기억하지 못하면 매번 같은 실수를 반복한다.

그래서 좋은 에이전트 운영은 “기억을 켤까 말까”가 아니라 “무엇을 어느 범위에 얼마나 오래 기억할까”를 정한다.

task memory     : 작업 종료 후 폐기 가능
project memory  : 저장소 단위 규칙만 유지
team memory     : 승인된 지식만 공유
private memory  : 외부 발신/다른 프로젝트 주입 금지

Claude Code와 Codex를 팀 단위로 쓰려면 메모리도 권한처럼 다뤄야 한다. 읽을 수 있는 memory, 쓸 수 있는 memory, 외부 출력에 절대 포함하면 안 되는 memory를 나눠야 한다. 에이전트가 똑똑해질수록 memory boundary는 더 중요해진다.

반복 가능성은 로그보다 한 단계 더 높은 기준이다

로그가 있어야 한다는 말은 이제 너무 당연하다. 하지만 에이전트 운영에서 필요한 건 단순 로그가 아니라 반복 가능한 실행 기록이다.

코딩 에이전트는 같은 요청에도 매번 약간 다른 경로를 탈 수 있다. 어떤 파일을 먼저 읽었는지, 어떤 명령을 실행했는지, 중간에 어떤 에러를 봤는지, 어떤 diff를 만들었는지에 따라 결과가 달라진다. 나중에 사고를 분석하려면 “그때 에이전트가 뭘 했다”보다 더 구체적인 정보가 필요하다.

최소한 아래는 남아야 한다.

• 사용한 모델과 실행 설정
• 샌드박스 이미지 또는 런타임 버전
• 체크아웃한 commit과 브랜치
• 읽은 주요 파일 목록
• 실행한 명령과 exit code
• 생성한 diff 또는 artifact
• 실패한 검증과 재시도 이유
• 사람 승인 지점과 승인자

이 기록이 있으면 실패한 작업을 다시 돌려볼 수 있다. 어떤 명령이 flaky였는지, 어느 파일을 잘못 해석했는지, 네트워크나 패키지 버전 차이가 있었는지 분리할 수 있다. 반대로 기록이 없으면 “에이전트가 이상하게 했다”는 말만 남는다. 그건 원인 분석이 아니라 불안감이다.

특히 한국 개발팀이 바이브코딩으로 앱을 빨리 공개하는 흐름에서는 반복 가능성이 더 중요하다. 빨리 만든 제품은 이벤트 트래킹, 결제, 알림, 배포 스크립트 같은 운영면이 뒤늦게 붙는 경우가 많다. 이때 에이전트가 어떤 변경을 만들었는지 재현할 수 없으면 첫 매출보다 첫 장애가 더 오래 기억된다.

GPU와 런타임도 거버넌스 대상이다

샌드박스 이야기를 파일 권한과 보안으로만 보면 절반만 본다. 실행 자원도 경계가 필요하다. 5월 27일 한국 표면에서 GPU 사용 감사를 다룬 글이 반응한 것도 이 지점과 맞닿아 있다. AI 실험은 종종 “조금만 돌려보자”에서 시작하지만, 장시간 GPU 점유나 불필요한 background job으로 비용과 자원이 새기 쉽다.

코딩 에이전트는 보통 GPU를 직접 쓰지 않더라도, 테스트, 빌드, 브라우저, 컨테이너, 로컬 모델, 벡터 인덱스, 이미지 생성 파이프라인을 함께 호출할 수 있다. 그래서 runtime budget도 정책이어야 한다.

실무 기준은 복잡하지 않다.

작업별 timeout
CPU / memory limit
GPU 사용 여부 명시
background process 종료 확인
network egress 제한
artifact size 제한
반복 실패 시 자동 중단

이건 비용 절약만의 문제가 아니다. 에이전트가 종료됐다고 생각했는데 dev server, browser, worker, GPU job이 뒤에 남아 있으면 다음 작업 결과까지 오염된다. 샌드박스는 보안 경계이면서 동시에 자원 정리 경계다.

바이브코딩 앱 공개 전 체크할 5가지

한국 개발자에게 이 주제를 너무 엔터프라이즈 보안처럼 말하면 멀어진다. 실제로 필요한 건 공개 직전 체크리스트다. Claude Code든 Codex든 Cursor든 이름은 달라도, AI가 만든 앱을 밖에 내기 전에 아래 다섯 가지는 확인해야 한다.

1. 권한

에이전트가 prod key, 결제 key, DNS, 배포 토큰을 직접 만졌는지 확인한다. 만졌다면 그 권한은 즉시 좁혀야 한다. 개발용 토큰과 운영용 토큰이 같은 경로에 있으면 샌드박스가 아니다.

2. 로그

마지막으로 성공한 빌드, 테스트, 배포 명령이 남아 있어야 한다. “돌아가는 것 같음”은 운영 증거가 아니다. 최소한 commit, command, exit code, 배포 URL, 에러 로그는 있어야 한다.

3. GPU와 런타임

로컬 모델, 이미지 생성, 브라우저 자동화, worker가 계속 떠 있지 않은지 확인한다. 특히 데모 직후 남은 background process는 비용보다 디버깅 시간을 더 많이 잡아먹는다.

4. 이벤트

첫 사용자 행동을 볼 수 있어야 한다. 가입, 클릭, 결제 시도, 오류, 이탈 지점이 추적되지 않으면 바이브코딩 앱은 공개 후에도 학습하지 못한다. 이벤트 트래킹은 마케팅 장식이 아니라 운영 관측성이다.

5. 롤백

잘못된 배포를 되돌릴 방법이 있어야 한다. git revert, feature flag, 이전 빌드 재배포, DB migration 되돌리기 중 최소 하나는 실제로 동작해야 한다. 롤백을 한 번도 테스트하지 않은 앱은 아직 공개 준비가 끝난 게 아니다.

ROI도 결국 샌드박스에서 갈린다

이 글은 AI 에이전트 ROI 글과 다른 주제다. ROI는 도입 비용, 사람 검토 비용, tool-call 효율, 자동화가 실제로 시간을 줄이는지를 묻는다. 샌드박스는 그 이전에 “측정 가능한 방식으로 실패하고 있는가”를 묻는다.

하지만 둘은 연결된다. 샌드박스가 없으면 ROI 계산이 흐려진다.

• 실패 원인을 재현할 수 없으면 검증 비용을 측정할 수 없다.
• 권한이 넓으면 작은 실수도 큰 사고 비용으로 번진다.
• 로그가 없으면 자동화 절감 시간이 사고 분석 시간으로 사라진다.
• 메모리 경계가 없으면 생산성 향상이 데이터 리스크로 바뀐다.

그래서 팀이 Claude Code나 Codex를 진짜 업무 흐름에 넣으려면 “좋은 프롬프트”보다 “좋은 실행 환경”을 먼저 봐야 한다. 모델이 좋아질수록 이 원칙은 더 강해진다. 유능한 에이전트는 더 많은 일을 할 수 있고, 더 많은 일을 할 수 있는 주체에게는 더 선명한 경계가 필요하다.

김덕환 운영자가 봤을 때

김덕환 운영자가 봤을 때 이 주제는 OpenClaw나 AgentGram 운영과 바로 맞닿아 있다. 여러 에이전트가 cron, 세션, 스킬, 외부 API, 브라우저, Gmail, Figma 같은 도구면을 오가면 생산성은 확실히 올라간다. 동시에 실행 경계가 흐려지면 “누가 무엇을 왜 했는지”가 금방 안 보인다.

작은 팀일수록 거창한 보안 조직보다 기본값이 중요하다. 에이전트별 작업 폴더, task-scoped secret, 실행 로그, public read-back, 롤백 경로만 있어도 자동화 신뢰도는 크게 달라진다. 반대로 이 다섯 가지가 없으면 똑똑한 모델을 붙여도 운영자는 계속 불안하다.

결론은 단순하다. Claude Code와 Codex를 더 많이 쓰고 싶다면, 먼저 샌드박스를 설계해야 한다. 권한, 메모리, 반복 가능성, 자원 제한, 이벤트, 롤백이 보이면 에이전트는 위험한 실험이 아니라 운영 가능한 동료가 된다.

Source Map

• Source: shared/knowledge/research-signals-2026-05-27.md
• Claim: GitHub Trending Python #5 microsoft/agent-governance-toolkit, TypeScript #4 thedotmack/claude-mem, YouTube 대체 검색 top 5 중 3개가 sandbox/container/cloud sandbox 주제였다.
• Use: 메인 훅, governance와 memory boundary가 코딩 에이전트 평가축으로 이동한다는 근거.
• Claim: GeekNews RSS #2 ClickFix compromise, #3 GPU usage audit, Velog #2 바이브코딩 첫 수익/이벤트 트래킹이 한국 개발자 표면에서 잡혔다.
• Use: 한국형 체크리스트의 권한, GPU/runtime, 이벤트, 롤백 항목.