코딩 에이전트를 샌드박스에서 실행하려면 범위가 지정된 저장소 워크스페이스, 제어된 터미널 실행 경로, 명시적인 파일 권한, 네트워크 및 패키지 설치 정책, 격리된 시크릿, 명령 로그, 아티팩트, 그리고 병합 또는 배포 전 고위험 변경 사항에 대한 명확한 승인 경로를 제공하세요. 이 패턴은 에이전트가 Codex 스타일이든, IDE에 연결되어 있든, CI에서 트리거되었든, 또는 자체 개발자 플랫폼에 포함되어 있든 관계없이 작동합니다. 모델은 계획하고 편집할 수 있지만, 샌드박스는 무엇을 건드릴 수 있는지, 무엇을 실행할 수 있는지, 무엇을 가져올 수 있는지, 그리고 리뷰어가 어떤 증거를 받을지 결정합니다.
코딩 에이전트 샌드박스란 무엇인가요?
코딩 에이전트 샌드박스는 AI 시스템이 코드를 검사하고, 파일을 편집하고, 터미널 명령어를 실행하고, 정책이 허용할 때 종속성을 설치하고, 테스트를 수행하고, 미리보기 서버를 시작하고, 검토 가능한 diff를 반환할 수 있는 격리된 런타임으로, 개발자의 머신이나 프로덕션 환경에 대한 광범위한 액세스 권한을 부여하지 않습니다.
중요한 변화는 샌드박스가 단순히 모델을 감싸는 채팅 래퍼가 아니라는 점입니다. 이는 작업을 위한 운영 경계입니다. 모델은 작업을 제안하고, 샌드박스는 워크스페이스, 도구, 권한 및 증거 추적을 적용합니다.
간단한 코드 어시스턴트의 경우 로컬 체크아웃과 수동 복사-붙여넣기로 충분할 수 있습니다. 명령을 실행하거나 여러 단계를 지속할 수 있는 에이전트의 경우 더 강력한 경계가 필요합니다:
- 각 작업 또는 세션을 위한 전용 워크스페이스.
- 알려진 저장소 상태 및 브랜치.
- 위험한 작업에 대한 승인이 있는 명령 실행 인터페이스.
npm,pip,cargo,apt및 유사한 도구에 대한 패키지 설치 정책.- 레지스트리, 문서, API 및 미리보기 액세스에 대한 네트워크 이그레스 규칙.
- 작업 범위로 지정되고 가능한 경우 로그에서 숨겨진 시크릿.
- 캡처된 stdout, stderr, 종료 코드, 파일 변경 사항, 생성된 아티팩트 및 미리보기 URL.
- 병합, 배포 또는 외부 릴리스 전의 검토 게이트.
이것이 바로 'Codex를 샌드박스에서 실행’이라는 것이 단일 CLI 플래그나 한 공급업체 통합이 아닌 인프라 패턴으로 이해되어야 하는 이유입니다. Codex CLI 자체는 사용자 컴퓨터에서 로컬로 실행되는 코딩 에이전트로 문서화되어 있으며, OpenAI의 Codex 문서는 터미널 중심의 워크플로를 설명합니다. 팀, CI 시스템 또는 제품 워크플로를 위해 해당 종류의 에이전트를 운영하는 경우, 주변 실행 환경이 제어 평면이 됩니다.
코딩 에이전트 샌드박스 아키텍처
가장 깔끔한 아키텍처는 모델 루프를 실행 경계와 분리합니다:
| 계층 | 책임 | 답변해야 할 질문 |
|---|---|---|
| 에이전트 인터페이스 | 사용자 의도를 계획, 파일 편집, 도구 호출 및 검토 요약으로 변환 | 어떤 모델 또는 코딩 에이전트가 사용됩니까? 프롬프트, 컨텍스트 및 도구 스키마는 어떻게 관리됩니까? |
| 워크스페이스 관리자 | 샌드박스를 생성하고, 저장소를 체크아웃하며, 브랜치를 설정하고, 허용된 파일을 마운트 | 각 작업이 격리되어 있습니까? 기본 커밋이 알려져 있습니까? 워크스페이스를 재설정할 수 있습니까? |
| 터미널 실행기 | 승인된 명령을 실행하고 결과를 에이전트에 스트리밍 | 어떤 명령이 자동으로 허용되고, 승인이 필요하며, 차단됩니까? |
| 정책 계층 | 파일 시스템 범위, 시크릿, 네트워크 이그레스, 패키지 설치, 런타임 제한 및 정리를 제어 | 에이전트가 패키지를 가져올 수 있습니까? 공용 인터넷에 호출할 수 있습니까? 자격 증명을 읽을 수 있습니까? |
| 증거 계층 | 로그, diff, 테스트 결과, 미리보기 및 아티팩트 저장 | 리뷰어가 모델의 요약을 신뢰하지 않고 무슨 일이 있었는지 재구성할 수 있습니까? |
| 검토 게이트 | 병합, 게시 또는 배포 전에 인간 또는 신뢰할 수 있는 자동화 단계 필요 | 누가 위험한 변경 사항을 승인합니까? 먼저 통과해야 하는 검사는 무엇입니까? |
실제로 단일 플랫폼이 여러 계층을 결합할 수 있습니다. 아키텍처는 여전히 중요합니다. 제품 선택을 정직하게 유지하기 때문입니다. 도구가 에이전트에 터미널을 제공하지만 명령 로그, 파일 diff 또는 이그레스 정책을 표시할 수 없다면 프로토타이핑에는 편리할 수 있지만 프로덕션 검토에는 부족할 수 있습니다.
코딩 에이전트 샌드박스에서 터미널 액세스는 어떻게 작동해야 하나요?
터미널은 코딩 에이전트가 운영상 유용해지고 동시에 위험해지는 곳입니다. 테스트를 실행하고, 자산을 빌드하고, 생성된 파일을 검사하고, 로컬 서버를 시작하고, 실패를 진단할 수 있습니다. 또한 파일을 삭제하고, 환경 변수를 유출하고, 예상치 못한 설치 스크립트를 실행하거나, 많은 컴퓨팅 리소스를 소비할 수 있습니다.
좋은 터미널 모델은 세 부분으로 구성됩니다.
첫째, 명령 클래스를 정의합니다. ls, sed, rg, git diff 및 테스트 상태 명령과 같은 안전한 읽기 전용 명령은 자동으로 실행될 수 있습니다. npm test, pytest, cargo test 및 npm run build와 같은 빌드 및 테스트 명령은 시간 제한과 함께 허용될 수 있습니다. rm -rf, git push, gh pr merge, 배포 CLI, 패키지 게시, 데이터베이스 마이그레이션 또는 클라우드 리소스 변형과 같은 파괴적이거나 외부 영향을 미치는 명령은 명시적 승인이 필요하거나 완전히 차단되어야 합니다.
둘째, 구조화된 결과를 스트리밍합니다. 에이전트와 리뷰어는 명령어, 작업 디렉터리, 시작 시간, 종료 코드, stdout, stderr, 시간 초과 상태 및 출력 잘림 정책을 볼 수 있어야 합니다. 터미널 스크린샷만으로는 충분하지 않습니다. 시스템은 기계가 읽을 수 있는 로그를 보존해야 합니다.
셋째, 장기 실행 세션을 의도적으로 처리합니다. 코딩 에이전트는 종종 백그라운드 개발 서버, 감시자, 브라우저 자동화 프로세스 또는 통합 테스트 스택이 필요합니다. 장기 실행 프로세스를 핸들이 있는 리소스로 취급합니다: 시작하고, 로그를 스트리밍하고, 필요한 미리보기 포트만 노출하고, 정리 중에 중지합니다. 백그라운드 프로세스가 채팅 세션의 추적되지 않는 부작용이 되지 않도록 합니다.
에이전트 변경 사항을 위한 저장소 격리 및 브랜치 제어
저장소 상태는 검토 가능한 코딩 에이전트 워크플로의 핵심입니다. 사용자가 명시적으로 해당 모드를 선택하지 않는 한, 에이전트는 알 수 없는 로컬 편집 내용이 있는 모호한 폴더에서 작업해서는 안 됩니다.
팀 워크플로의 경우, 알려진 저장소 URL, 기본 브랜치 및 커밋 SHA에서 각 작업을 시작합니다. 작업 브랜치 또는 분리된 워크스페이스를 만듭니다. 사용자 변경 사항과 에이전트 변경 사항을 분리하고, 검토 전에 정확한 diff를 캡처합니다. 샌드박스가 영구 세션을 지원하는 경우 의도적으로 워크스페이스를 유지합니다. 우연한 프로세스 상태에 의존하지 마십시오.
기본 패턴은 다음과 같습니다:
1. Create isolated workspace for task-123.
2. Check out repository at main@<base_sha>.
3. Create branch agent/task-123.
4. Run dependency install according to policy.
5. Let the agent inspect, edit, test, and iterate.
6. Capture git diff, test output, generated artifacts, and preview URL.
7. Open a pull request or hand the patch to a human reviewer.
8. Tear down or archive the workspace according to retention policy.
핵심 세부 사항은 6단계입니다. 유용한 코딩 에이전트는 단순히 '수정했습니다’라고 말하지 않습니다. 변경된 파일, 각 변경 이유, 실행된 검증, 실패한 내용, 그리고 아직 검증되지 않은 내용을 반환합니다.
샌드박스 처리된 코딩 에이전트를 위한 명령, 패키지 및 네트워크 정책
패키지 설치는 코딩 에이전트 샌드박싱의 가장 어려운 부분 중 하나입니다. 많은 실제 작업에 종속성이 필요합니다. 많은 공급망 사고도 종속성 가져오기, 설치 후 스크립트 또는 불투명한 바이너리에서 시작됩니다.
실용적인 정책은 '절대 패키지를 설치하지 마십시오’가 아닙니다. '알려진 경로를 통해서만 로깅 및 범위와 함께 패키지를 설치하십시오’입니다.
| 제어 | 실용적인 구현 |
|---|---|
| 패키지 관리자 | 언어 및 저장소 유형에 따라 사용 가능한 패키지 관리자를 결정합니다. |
| 레지스트리 액세스 | 승인된 레지스트리를 허용합니다. 작업에 필요하지 않은 경우 임의의 패키지 소스를 차단합니다. |
| Lockfiles | 기존 lockfiles 및 재현 가능한 설치 명령을 선호합니다. |
| 설치 후 스크립트 | 수명 주기 스크립트가 자동으로 실행될 수 있는지 또는 승인이 필요한지 결정합니다. |
| 시스템 패키지 | apt, brew 및 OS 패키지 설치는 프로젝트 종속성 설치보다 더 높은 위험으로 처리합니다. |
| 캐시 | 속도와 재현성이 필요한 경우 제어된 패키지 캐시를 사용합니다. |
| 로깅 | 패키지 이름, 버전, 레지스트리 URL, 사용 가능한 체크섬 및 설치 출력을 저장합니다. |
네트워크 정책도 마찬가지로 명시적이어야 합니다. 코딩 에이전트는 공개 문서를 읽거나, 스테이징 API를 호출하거나, 패키지를 다운로드하거나, 로컬 미리보기를 노출해야 할 수 있습니다. 이는 무제한 인터넷 액세스와 다릅니다. 아웃바운드 패키지 가져오기, 웹 브라우징, API 호출, 웹후크 전달 및 미리보기 수신을 분리하세요. 제품이 민감한 코드나 데이터를 처리하는 경우 DNS, 프록시 로그 및 레지스트리 미러가 HTTP 트래픽과 동일한 정책으로 적용되는지 확인하세요.
에이전트 워크스페이스를 위한 시크릿, 로그 및 감사 추적
시크릿은 가장 작은 유용한 표면으로 범위를 지정해야 합니다. 코딩 에이전트는 일반적으로 프로덕션 자격 증명이 필요하지 않습니다. 읽기 전용 Git 토큰, 패키지 레지스트리 토큰, 스테이징 API 키 또는 미리보기 배포 토큰이 필요할 수 있습니다. 각각은 작업 범위로 지정되고, 가능한 경우 시간 제한이 있으며, 이를 필요로 하지 않는 명령에는 사용할 수 없어야 합니다.
작업이 실제로 필요하지 않는 한 에이전트가 읽을 수 있는 파일에 시크릿을 배치하지 마십시오. 브로커된 액세스를 선호하세요: 샌드박스가 작업을 수행할 수 있지만 모델은 원시 자격 증명을 보지 않습니다. 환경 변수가 필요한 경우 로그는 알려진 시크릿 패턴을 편집해야 하며, 리뷰어 아티팩트에는 전체 환경 덤프가 포함되어서는 안 됩니다.
감사 추적을 위해 최종 패치 이상을 저장하세요:
- 사용자 요청 및 작업 메타데이터.
- 저장소 URL, 기본 커밋, 브랜치 및 최종 커밋 또는 diff.
- 요청, 승인, 차단 및 실행된 명령.
- 명령 출력, 종료 코드 및 시간 초과.
- 플랫폼이 캡처할 수 있는 파일 읽기 및 쓰기.
- 정책이 지원하는 수준의 네트워크 및 패키지 가져오기 기록.
- 미리보기 URL 및 생성된 아티팩트 경로.
- 인간 승인 및 병합 결정.
이는 관료주의가 아닙니다. 리뷰어가 실제 수정을 그럴듯한 이야기와 구별하는 방법입니다.
병합 전 diff, 미리보기 및 검토 게이트
코딩 에이전트의 가장 유용한 출력은 검토 가능한 변경 집합입니다. 즉, 샌드박스는 신중한 엔지니어가 풀 리퀘스트에서 기대하는 것과 동일한 아티팩트를 생성해야 합니다:
- 집중된 diff.
- 실행된 테스트 또는 빌드 명령.
- 남아 있는 실패.
- UI 또는 생성된 자산이 변경된 경우 스크린샷, 미리보기 URL 또는 다운로드 가능한 파일.
- 의도된 동작 변경에 대한 간략한 설명.
조직이 해당 특정 저장소 및 위험 수준에 대해 별도의 신뢰할 수 있는 자동화 정책을 구축하지 않은 경우 최종 병합 또는 배포를 인간이 제어하는 게이트 뒤에 유지하세요. 변경 사항이 인증, 청구, 데이터 액세스, 네트워크 호출, 인프라, 종속성 버전, 생성된 마이그레이션 또는 사용자에게 표시되는 콘텐츠에 영향을 미치는 경우 인간 검토가 특히 중요합니다.
미리보기 처리는 자체 규칙이 필요합니다: 검토에 필요한 서비스와 포트만 노출하세요. 웹 앱을 시작하는 샌드박스는 리뷰어에게 범위가 지정된 미리보기 URL을 제공해야 하며, 워크스페이스에 대한 광범위한 네트워크 액세스를 제공해서는 안 됩니다.
장기 실행 에이전트 세션을 위한 정리 및 재설정 전략
모든 샌드박스에는 수명 주기가 필요합니다. 수명 주기가 없으면 장기 실행 코딩 에이전트 인프라는 오래된 워크스페이스, 유출된 로그 및 계속 실행 중인 프로세스의 더미가 됩니다.
짧은 작업의 경우 임시 모델이 잘 작동합니다: 샌드박스를 만들고, 작업을 실행하고, 아티팩트를 추출한 다음, 삭제합니다. 더 큰 작업의 경우 지속성이 유용할 수 있습니다: 에이전트가 일시 중지하고, 검토를 기다리고, 동일한 브랜치에서 재개하거나, 검토 세션 중에 개발 서버를 계속 실행해야 할 수도 있습니다. 지속성은 만료, 소유자 및 보존 규칙이 있는 명시적인 제품 기능이어야 합니다.
다음에 대한 정리를 정의하세요:
- 백그라운드 프로세스 및 열린 포트.
- 임시 파일 및 빌드 출력.
- 패키지 캐시 및 다운로드된 아카이브.
- 작업 범위의 시크릿.
- 로그 및 아티팩트.
- 대체된 브랜치 또는 워크트리.
재설정도 마찬가지로 중요합니다. 리뷰어는 기본 커밋 또는 최종 브랜치에서 에이전트의 검증을 다시 실행할 수 있어야 합니다. 결과가 장기 세션 내부의 보이지 않는 상태 때문에만 작동한다면 워크플로를 신뢰하기 어렵습니다.
이 워크플로에서 Novita Agent Sandbox의 위치
Novita Agent Sandbox는 코드 실행, 브라우저 자동화, 컴퓨터 사용 스타일 워크플로, 데이터 분석, 평가 및 장기 실행 에이전트 워크플로에 격리된 런타임이 필요한 에이전트 인프라를 위해 설계되었습니다. Novita Agent Sandbox 문서는 이 제품을 샌드박스 수명 주기, 파일, 명령, 브라우저 세션 및 관련 워크플로 기본 요소와 함께 작업하기 위한 SDK 및 CLI 경로를 갖춘 에이전트 워크로드 실행을 위한 상태 저장 환경으로 설명합니다.
이미 Novita AI 모델 API를 사용하고 있는 팀의 경우 샌드박스 계층은 모델 추론과 작업 실행 사이의 격차를 줄일 수 있습니다. 모델은 추론하고, 도구를 호출하고, 코드 변경을 계획할 수 있습니다. 샌드박스는 이러한 작업이 실행, 기록, 미리보기 및 검토되는 격리된 워크스페이스를 제공할 수 있습니다.
워크플로를 설계할 때 보수적인 제품 경계를 사용하세요:
- Novita Agent Sandbox를 포괄적인 보안 보장이 아닌 실행 환경으로 취급하세요.
- 시크릿, 패키지 설치, 이그레스 및 게시 작업을 자체 정책 뒤에 유지하세요.
- 프로덕션 자동화에 하드코딩하기 전에 Novita 문서에서 현재 SDK, CLI, 가격 및 계정 제한 세부 정보를 확인하세요.
- 프로덕션에서 샌드박스에 의존하기 전에 격리 경계, 타사 에이전트 호환성 및 규정 준수 요구 사항을 자체 정책과 비교하여 평가하세요.
이러한 분리는 에이전트 계층이 변경되더라도 구현 지침을 유용하게 유지합니다. 동일한 샌드박스 제어 질문을 유지하면서 Codex 스타일 에이전트, 내부 코딩 에이전트, 브라우저 에이전트 또는 평가 작업자를 사용할 수 있습니다.
코딩 에이전트 샌드박스 구현 체크리스트
코딩 에이전트 샌드박스를 프로토타입 이상으로 옮기기 전에 이 체크리스트를 사용하세요.
| 영역 | 최소 프로덕션 질문 |
|---|---|
| 워크스페이스 | 각 작업에 범위가 지정된 파일 시스템과 알려진 저장소 기본 커밋이 제공됩니까? |
| 브랜칭 | 에이전트 변경 사항이 리뷰어가 검사할 수 있는 브랜치 또는 패치에 격리되어 있습니까? |
| 터미널 | 명령이 작업 디렉터리, 출력, 종료 코드 및 시간 초과와 함께 기록됩니까? |
| 승인 | 어떤 명령이 자동으로 실행되고, 승인이 필요하며, 차단됩니까? |
| 패키지 | 종속성 설치가 재현 가능하고 기록됩니까? |
| 네트워크 | 이그레스가 패키지 가져오기, 문서 브라우징, API 호출 및 미리보기 액세스로 구분됩니까? |
| 시크릿 | 자격 증명이 작업 범위로 지정되고 로그에서 편집됩니까? |
| 미리보기 | 미리보기 포트가 명시적이고 쉽게 종료할 수 있습니까? |
| 아티팩트 | 생성된 파일, 스크린샷, 보고서 및 로그가 검토에 첨부됩니까? |
| 지속성 | 세션 일시 중지/재개가 소유자 및 만료와 함께 의도적입니까? |
| 정리 | 프로세스, 포트, 임시 파일, 시크릿 및 오래된 워크스페이스가 제거됩니까? |
| 검토 | 인간이 위험한 변경 사항에 대한 병합, 게시 또는 배포를 승인합니까? |
현재 설정이 이러한 질문 중 여러 개에 답할 수 없는 경우 워크플로를 프로토타입 트랙에 유지하세요. 에이전트는 여전히 유용할 수 있지만, 광범위한 저장소, 네트워크 또는 자격 증명 액세스 권한을 받아서는 안 됩니다.
자주 묻는 질문
Codex 자체를 클라우드 샌드박스 내에서 실행할 수 있나요?
개념적으로는 그렇습니다. 터미널 코딩 에이전트는 환경이 에이전트가 필요로 하는 운영 체제, 인증 경로, 터미널 I/O, 파일 시스템 액세스 및 네트워크 액세스를 지원하는 경우 격리된 워크스페이스 내에서 실행될 수 있습니다. 샌드박스 제공자와 에이전트 제공자가 정확한 설정에 대해 문서화하지 않는 한 공식 통합 또는 완전한 호환성을 가정하지 마십시오.
Docker가 코딩 에이전트 샌드박스에 충분한가요?
Docker는 로컬 개발, CI 작업 및 반복 가능한 환경에 유용할 수 있지만, '충분한지’는 위협 모델에 따라 다릅니다. 커널을 공유하는 것, 파일 마운트가 있는 것, 네트워크 이그레스가 제어되는 방법, 시크릿이 컨테이너에 노출되는지, 그리고 이스케이프 또는 종속성 손상이 처리되는 방법을 질문하세요. 민감한 워크로드의 경우 보안 팀은 종종 더 강력한 격리 경계와 더 엄격한 이그레스 제어를 평가합니다.
코딩 에이전트가 인터넷에 액세스할 수 있어야 하나요?
작업에 필요한 경우에만, 그리고 설명할 수 있는 정책을 통해서만 가능합니다. 문서 조회, 패키지 레지스트리 액세스, 스테이징 API 호출 및 임의 브라우징은 서로 다른 권한입니다. 에이전트가 가져온 것을 기록하고, 패키지 설치를 재현 가능하게 유지하며, 범용 코딩 세션에 프로덕션 네트워크 액세스 권한을 부여하지 마십시오.
에이전트가 생성한 코드를 병합하기 전에 리뷰어는 무엇을 확인해야 하나요?
diff, 실행된 명령, 테스트/빌드 출력, 종속성 변경, 생성된 아티팩트, 미리보기 동작 및 건너뛴 검증을 검토하세요. 인증, 권한, 데이터 처리, 네트워크 호출, 마이그레이션, 설치 스크립트 및 시크릿에 특히 주의하세요.
Novita는 코딩 에이전트 샌드박스에 어떻게 도움이 되나요?
Novita Agent Sandbox는 코드 실행, 브라우저 자동화, 컴퓨터 사용 스타일 작업, 데이터 분석, 평가 및 장기 실행 워크플로와 같은 워크로드를 위한 격리된 에이전트 런타임을 제공합니다. 코딩 에이전트 워크플로를 구축할 때 명시적인 저장소, 명령, 패키지, 네트워크, 시크릿 및 검토 정책과 함께 사용하세요.
추천 문서
