AI 에이전트 샌드박스 운영 모델: 권한, 네트워크, 워크트리를 나누는 법

AI 에이전트를 팀에 도입할 때 가장 흔한 실패 패턴은 "모델이 똑똑해졌으니 더 많은 권한을 주자"입니다. 초기에는 빠릅니다. 그런데 어느 순간부터 로컬 파일, 시크릿, 배포 스크립트, 외부 API, Git 히스토리가 한 작업 공간에 섞이고, 팀은 에이전트가 무엇을 바꿨는지 설명하기 어려워집니다.

AIAx, 즉 AI Transformation에서 중요한 질문은 "어떤 모델을 쓰는가"보다 "에이전트가 어느 경계 안에서 일하는가"입니다. 좋은 샌드박스는 에이전트를 느리게 만드는 장치가 아닙니다. 사람이 매번 감시하지 않아도 더 많은 일을 안전하게 위임하게 해주는 운영 계층입니다.

이 글은 개발팀이 바로 적용할 수 있는 AI 에이전트 샌드박스 운영 모델을 정리합니다.

샌드박스를 보안 기능 하나로 보지 말자

샌드박스는 보통 "격리된 실행 환경"으로 이해됩니다. 하지만 코딩 에이전트 운영에서는 네 가지 경계가 함께 작동해야 합니다.

1. 파일 경계: 에이전트가 읽고 쓸 수 있는 디렉터리
2. 명령 경계: 실행 가능한 셸 명령과 금지 명령
3. 네트워크 경계: 외부 인터넷, 내부 API, 패키지 레지스트리 접근 범위
4. 변경 경계: Git 브랜치, 워크트리, 커밋, 리뷰, CI 게이트

Anthropic의 Claude Code 보안 문서는 에이전트 시스템의 위험을 줄이기 위해 파일 시스템과 네트워크 격리를 갖춘 sandboxed bash tool, 쓰기 접근 제한, 명령 승인 흐름 같은 보호 장치를 설명합니다. 또한 Bash 명령 실행 전 사용자 승인을 요구하는 권한 기반 구조를 강조합니다. 참고: Claude Code Security.

핵심은 "에이전트가 위험하다"가 아니라 "에이전트에게도 사람과 같은 작업 구획이 필요하다"입니다.

1단계: 작업 단위마다 독립 워크트리를 만든다

가장 실용적인 첫 단계는 Git worktree 또는 임시 클론을 쓰는 것입니다. 에이전트가 메인 개발 디렉터리에서 직접 작업하지 않게 하세요.

git fetch origin develop
git worktree add ../agent-worktrees/refactor-checkout-flow -b agent/refactor-checkout-flow origin/develop
cd ../agent-worktrees/refactor-checkout-flow

이 방식의 장점은 단순합니다.

• 에이전트가 만든 파일과 기존 로컬 변경을 섞지 않습니다.
• 실패한 작업은 worktree를 삭제하면 됩니다.
• 여러 에이전트가 서로 다른 브랜치에서 병렬 작업할 수 있습니다.
• 리뷰할 변경 범위가 git diff origin/develop...HEAD로 명확해집니다.

운영 규칙은 더 중요합니다.

에이전트는 항상 전용 브랜치와 전용 worktree에서 시작한다.
에이전트는 기존 사용자 변경이 있는 디렉터리에서 작업하지 않는다.
에이전트는 커밋 전 diff 요약과 검증 결과를 남긴다.

이 규칙만 지켜도 "에이전트가 내 작업을 망쳤다"는 사고의 대부분을 줄일 수 있습니다.

2단계: 권한을 역할이 아니라 작업에 맞춘다

많은 팀이 권한을 사람 기준으로 설계합니다. "시니어 개발자는 배포 가능", "주니어는 리뷰 필요" 같은 방식입니다. 에이전트에는 이 방식이 잘 맞지 않습니다. 같은 에이전트라도 어떤 날은 문서만 고치고, 어떤 날은 DB 마이그레이션을 만집니다.

권한은 작업 유형에 맞춰야 합니다.

Claude Code의 hooks 문서는 도구 실행 전후에 훅을 연결할 수 있고, PreToolUse 훅으로 실행 전 판단을 할 수 있다고 설명합니다. 변경 후에 출력을 바꾸는 것보다 실행 전에 금지하거나 지연시키는 편이 안전합니다. 참고: Claude Code Hooks Reference.

실무에서는 다음 같은 정책 파일을 둘 수 있습니다.

{
  "taskType": "content_publish",
  "allowWrite": ["src/content/posts/"],
  "allowCommands": ["npm run lint", "npm run build", "git diff", "git status"],
  "denyCommands": ["rm -rf", "git reset --hard", "git push --force"],
  "requiresHumanApproval": ["package.json", "next.config.ts", ".github/workflows/"]
}

완벽한 정책 엔진이 없어도 괜찮습니다. 처음에는 체크리스트와 래퍼 스크립트만으로도 충분합니다.

3단계: 네트워크를 기본 차단으로 시작한다

코딩 에이전트에게 네트워크 접근을 열어두면 편합니다. 문서를 검색하고, 패키지를 설치하고, API를 호출할 수 있습니다. 하지만 네트워크는 프롬프트 인젝션, 데이터 유출, 공급망 리스크가 만나는 지점입니다.

권장 기본값은 다음입니다.

문서 작성/리팩터링: 인터넷 조회 허용, 내부 API 차단, 시크릿 미주입
테스트 실행: 필요한 로컬 서비스만 허용, 외부 네트워크 차단
패키지 변경: lockfile 변경을 별도 승인 대상으로 분리
배포 작업: 사람 승인 전 클라우드 쓰기 API 차단

에이전트가 최신 사실을 확인해야 할 때는 공식 문서와 신뢰 가능한 출처를 지정하세요. 예를 들어 OpenAI Codex CLI 문서는 CLI, 승인, 보안, 비대화형 모드 같은 운영 주제를 제공합니다. 참고: OpenAI Codex CLI documentation.

네트워크 정책은 개발 속도를 늦추는 것이 아니라 "실패했을 때 어디까지 영향을 받는가"를 제한합니다.

4단계: CI를 마지막 방어선이 아니라 작업 계약으로 만든다

에이전트 작업의 품질은 프롬프트보다 검증 루프에 더 크게 좌우됩니다. 좋은 위임 프롬프트는 이렇게 끝나야 합니다.

완료 조건:
- 변경 파일은 src/content/posts/*.mdx 두 개뿐이어야 한다.
- metadata export 형식이 기존 parser와 호환되어야 한다.
- npm run lint가 통과해야 한다.
- npm run build가 통과해야 한다.
- 실패하면 원인과 재현 명령을 보고하고 커밋하지 않는다.

CI는 "나중에 확인하는 자동화"가 아니라 에이전트에게 주는 작업 계약입니다. 에이전트가 스스로 통과 조건을 실행하고, 실패 로그를 읽고, 수정하고, 다시 실행하게 해야 합니다.

작은 팀이라면 다음 세 개만 먼저 표준화해도 충분합니다.

npm run lint
npm run build
git diff --check

백엔드 서비스라면 여기에 migration dry-run, contract test, smoke test를 추가합니다. 중요한 것은 테스트의 개수가 아니라 에이전트가 임의로 생략할 수 없는 게이트를 만드는 것입니다.

5단계: 샌드박스 로그를 운영 자산으로 남긴다

에이전트가 성공했는지만 보면 학습이 느립니다. 다음 정보를 작업마다 남기면 팀의 운영 능력이 빨리 좋아집니다.

• 입력된 작업 설명
• 허용된 권한 범위
• 변경 파일 목록
• 실행한 명령과 결과
• 실패와 재시도 횟수
• 사람이 개입한 지점
• 최종 커밋 SHA 또는 PR 링크

이 로그는 감시용이 아니라 개선용입니다. 한 달만 쌓아도 반복되는 병목이 보입니다.

예를 들면:

반복 병목: 에이전트가 build 실패 원인을 package lock 문제로 오판한다.
개선: build 실패 시 node_modules 존재 여부와 npm ci 필요 여부를 먼저 확인하는 runbook 추가.

이것이 AIAx에서 말하는 운영 전환입니다. AI를 도입하는 것이 아니라, AI가 일할 수 있는 업무 시스템을 바꾸는 것입니다.

바로 적용하는 샌드박스 체크리스트

다음 체크리스트를 팀의 에이전트 작업 템플릿에 넣어보세요.

[ ] 이 작업은 전용 브랜치와 전용 worktree에서 실행되는가?
[ ] 에이전트가 쓸 수 있는 디렉터리가 명시되어 있는가?
[ ] 금지 명령과 승인 필요 명령이 분리되어 있는가?
[ ] 네트워크 접근 범위가 정해져 있는가?
[ ] 시크릿이 에이전트 환경에 주입되지 않았는가?
[ ] 완료 조건이 명령어 단위로 적혀 있는가?
[ ] 실패 시 커밋/푸시를 멈추는 규칙이 있는가?
[ ] 변경 로그, 검증 결과, 커밋 SHA가 남는가?

트레이드오프

샌드박스 운영 모델에도 비용은 있습니다.

• 초기 설정 시간이 필요합니다.
• 너무 좁은 권한은 에이전트의 자율성을 낮춥니다.
• 정책 파일이 실제 작업과 어긋나면 팀이 우회하기 시작합니다.
• 모든 것을 자동화하려 하면 오히려 운영 복잡도가 커집니다.

그래서 처음부터 완벽한 플랫폼을 만들 필요는 없습니다. 전용 worktree, 명령 allowlist, 네트워크 기본 차단, CI 게이트, 작업 로그부터 시작하세요. 이 다섯 가지는 대부분의 팀에서 오늘 바로 적용할 수 있습니다.

결론: 에이전트 생산성은 경계 설계에서 나온다

AI 에이전트를 잘 쓰는 팀은 에이전트에게 무제한 권한을 주지 않습니다. 대신 일을 작게 나누고, 권한을 작업에 맞추고, 실패해도 회수 가능한 경계를 만듭니다.

AIAx의 핵심은 "AI를 많이 쓰는 회사"가 되는 것이 아닙니다. 사람이 안심하고 더 많은 일을 에이전트에게 맡길 수 있는 구조를 만드는 것입니다. 그 구조의 출발점이 바로 샌드박스 운영 모델입니다.