AIREITER파일을 수정하고 패키지를 설치하며 API까지 호출하는 코딩 에이전트라면 시스템 프롬프트에 적어둔 경고만으로는 부족합니다. NVIDIA OpenShell은 이런 권한을 에이전트 바깥의 정책 기반 샌드박스에서 통제합니다. 다만 어떤 상황에서도 빠짐없이 작동하는 정책을 직접 작성하고, 실제 배포 환경에서 검증해야 하는 부담은 여전히 사용자에게 남습니다.
한줄 결론: OpenShell은 에이전트 프레임워크가 아니라 실행 경계다
NVIDIA OpenShell은 자율 에이전트를 위한 오픈소스 런타임입니다. 0.1.x 문서에는 게이트웨이, 샌드박스별 Supervisor, 커널 수준에서 적용되는 파일 시스템·프로세스 제어, 중재형 네트워크, 자격 증명 연결, 정책 검토 도구가 설명돼 있습니다. NVIDIA가 2026년 9월 28일 공개한 기술 블로그에 따르면 Codex와 Claude Code 같은 에이전트를 다시 작성하지 않고 감싸는 방식으로 사용할 수 있습니다(NVIDIA Technical Blog).
핵심은 에이전트의 지능과 실행 범위를 분리하는 데 있습니다. OpenShell은 허가받지 않은 파일 쓰기나 네트워크 요청을 차단할 수 있지만, 불완전한 정책이 같은 비즈니스 작업으로 이어지는 모든 우회 경로까지 이해해 주지는 않습니다. 따라서 통제된 코딩 환경이나 에이전트 인프라에는 파일럿 도입을 고려할 만하지만, 샌드박스를 운영 환경 에이전트의 안전성을 보장하는 증거로 받아들여서는 안 됩니다.
OpenShell이 실제로 통제하는 범위
OpenShell은 에이전트가 실행되는 작업 영역과 전체 환경 관리를 분리합니다. 게이트웨이는 샌드박스와 정책을 관리하고, Supervisor는 작업 영역 밖으로 나가는 요청을 중재하며, 샌드박스는 운영체제 수준의 제한 아래에서 에이전트를 실행합니다(NVIDIA Technical Blog).
| 계층 | 보호 대상 | 실행 중 변경 가능 여부 |
|---|---|---|
| 파일 시스템 | 파일과 디렉터리 | 불가; 샌드박스를 다시 만들어야 함 |
| 프로세스 | 권한과 시스템 콜 동작 | 불가; 샌드박스를 다시 만들어야 함 |
| 네트워크 | 호스트, 포트, 바이너리, 특정 API 작업 | 가능 |
| 프로바이더 자격 증명 | 허가된 엔드포인트에서 사용하는 비밀 정보 | 가능 |
OpenShell은 애플리케이션 계층보다 낮은 위치에서 정책을 적용하고, 재사용 가능한 자격 증명을 에이전트 외부에 보관합니다. 이후 허가된 요청에만 자격 증명을 연결합니다(OpenShell README).
“OpenShell은 자율 AI 에이전트 플릿을 위한 안전하고 비공개적인 런타임입니다.” — NVIDIA OpenShell README (출처)
보안 모델의 강점은 실행 경계, 약점은 정책 설계다
OpenShell에 문서화된 제어 기능은 여러 인프라 경계에서 기본적으로 차단하는 방식으로 작동하기 때문에 유용합니다. 하지만 에이전트가 서로 조합해 실행할 수 있는 작업까지 모델링해 주는 것은 아닙니다.
파일 시스템·프로세스·네트워크 제어를 한눈에 보기
최신 보안 가이드에 따르면 파일 시스템 접근에는 Landlock, 프로세스 제한에는 seccomp와 권한 강등, 외부 트래픽에는 OPA 정책 평가를 거치는 CONNECT 프록시가 사용됩니다(OpenShell Security Best Practices). 목록에 없는 파일 시스템 경로는 접근할 수 없고, 외부 네트워크 트래픽은 기본적으로 차단됩니다. 네트워크 규칙은 특정 바이너리의 식별 정보에 접근 권한을 묶을 수도 있습니다.
네트워크 규칙은 단순히 호스트와 포트만 확인하는 수준을 넘어섭니다. REST 정책은 메서드와 경로를, GraphQL 정책은 오퍼레이션과 루트 필드를, WebSocket 정책은 핸드셰이크와 메시지를 검사할 수 있습니다. 대신 운영 측면에서는 선택이 필요합니다. 광범위한 규칙은 계속 작동시키기 쉽고, 좁은 규칙은 방어하기 쉽습니다.
파일 시스템과 프로세스 제한은 샌드박스가 시작될 때 고정됩니다. 실행 중인 샌드박스의 네트워크 권한은 업데이트할 수 있지만, 승인된 변경은 해당 샌드박스 인스턴스에 지속되는 정책 개정으로 남습니다. 정책을 빠르게 조정할 수 있으면서도 모든 제어 항목이 자유롭게 바뀌는 구조는 아닌 셈입니다.
자격 증명을 중재할 뿐, 위험을 자동으로 없애지는 않는다
자격 증명 중재는 노출 범위를 줄여 주지만, 권한이 과도한 엔드포인트 자체를 안전하게 바꿔 주지는 않습니다. 읽기 전용 API 정책은 기술적으로 쓰기 권한을 가진 자격 증명의 사용 범위를 좁힐 수 있지만, 이미 파괴적인 작업을 허용하는 정책을 고쳐 주지는 못합니다.
보안 가이드는 L7 규칙을 먼저 audit 모드로 시작하고, 실제 요청을 검토한 뒤 enforce로 전환할 것을 권장합니다. 감사 모드는 위반을 기록하지만 요청을 그대로 전달하므로, 운영 환경에서 차단하는 기능이 아니라 동작을 파악하는 단계입니다.
데모를 보안 결과로 착각하지 않고 OpenShell 평가하기
NVIDIA의 공식 튜토리얼은 curl과 인증이 필요 없는 GitHub REST API를 사용해 접근 거부, 읽기 전용 규칙, 실행 중 정책 교체를 보여 줍니다. 다만 이는 독립적인 벤치마크가 아니라 학습을 위한 경로입니다(NVIDIA Technical Blog).
튜토리얼을 통해 다음 세 가지 설정 질문에 답해 보세요.
- 에이전트를 네트워크 접근 없이 시작한 뒤 꼭 필요한 엔드포인트만 제공할 수 있는가?
- API에서 읽기와 쓰기 작업의 중요한 차이를 정책으로 표현할 수 있는가?
- 에이전트에게 자신의 요청을 스스로 승인할 권한을 주지 않고도 운영팀이 거부 요청과 정책 변경을 검토할 수 있는가?
실제 파일럿에서는 공격적인 테스트도 추가해야 합니다. 심볼릭 링크와 경로 순회 시도, 패키지 설치, 셸 자식 프로세스, 대체 바이너리, 잘못된 호스트로 전송되는 자격 증명 플레이스홀더, 개별적으로는 허용되지만 조합하면 문제가 되는 작업을 점검하세요. 공개 자료에는 지연 시간, 시작 오버헤드, 독립적인 탈출 성공률 측정치가 없습니다. 제품의 아키텍처 설명을 테스트 결과로 간주하지 말고, 자신의 환경에서 직접 수치를 수집해야 합니다.
운영 환경 도입을 막을 수 있는 요소
운영 환경 도입 여부를 결정할 때는 다음 세 가지 제약을 고려해야 합니다.
- 성숙도와 호환성. 저장소에는 Linux, Apple Silicon macOS, 실험 단계인 WSL 2를 통한 Windows가 지원 환경으로 나와 있으며, 실행 옵션으로 Docker, Podman 또는 호스트 가상화가 제시돼 있습니다. Kubernetes에서는
NetworkPolicy를 적용하는 CNI가 필요합니다. Kubernetes 사용자 네임스페이스 역시 최신 커널·Kubernetes·런타임 버전이 필요하고, 이 조합에서 GPU 호환성은 검증되지 않았습니다(OpenShell README; Security Best Practices). - 정책 조합. @liyun0016의 실제 사용자 테스트에서는 명시적인 거부 테스트가 통과했지만, 저장소 수정과 CI 변경, CI 실행이 결합되면서 승인되지 않은 운영 환경 경로가 만들어질 수 있다는 결과가 보고됐습니다(게시물). OpenShell은 사용자가 작성한 규칙을 적용할 뿐, 빠진 비즈니스 수준의 규칙까지 정의해 주지는 않습니다.
- 근거의 품질. NVIDIA는 장시간에 걸친 적대적 실험에서 보호된 저장소에 대한 쓰기가 발생하지 않았다고 보고했지만, 인용된 기술 자료에는 모델 수, 기준선, 오탐률, 독립적인 재현 결과가 공개돼 있지 않습니다. 이를 인증이 아니라 벤더가 제시한 근거로 받아들여야 합니다.
“OpenShell은 사용자가 부여한 규칙을 적용하는 데는 분명히 뛰어납니다. 하지만 ... 실제 병목은 정책 계층인 것 같습니다.” — @liyun0016 (출처)
지금 NVIDIA OpenShell을 도입할 만한 곳은?
| 상황 | 판단 |
|---|---|
| 민감한 파일을 다루는 로컬 코딩 에이전트 | Linux/macOS 런타임 요구사항이 맞고 정책을 좁게 시작할 수 있다면 파일럿 도입 가치가 있음 |
| 여러 작업 공간을 사용하는 팀 단위 에이전트 플릿 | 격리된 작업 공간, 중앙화된 정책 검토, 자격 증명 중재가 필요하다면 적합 |
| GPU 중심의 Kubernetes 배포 | 신중하게 파일럿 진행; 사용자 네임스페이스와 GPU 호환성을 별도로 검증해야 함 |
| 비즈니스 권한이 넓은 무인 운영 에이전트 | OpenShell에만 의존하지 말 것; 비즈니스 승인, 작업 단위 제어, 로깅, 롤백을 추가해야 함 |
| 간단한 Python 코드 샌드박스만 필요한 경우 | 목적에 맞는 전용 샌드박스와 비교할 것; OpenShell은 필요한 수준보다 제어 플레인 기능이 클 수 있음 |
제 권고는 전면적인 마이그레이션이 아니라 범위를 제한한 파일럿입니다. 에이전트 하나, 작업 공간 하나, 기본 차단 네트워크 정책, 되돌릴 수 있는 소규모 작업만으로 시작하세요. 차단 요청 중 정상 요청의 비율, 시작 시간, 정책 유지보수 부담, 허용된 작업의 연속 실행이 비즈니스 경계를 넘을 수 있는지를 측정해야 합니다.
NVIDIA OpenShell FAQ
NVIDIA OpenShell을 사용하려면 NVIDIA GPU가 필요한가요?
README에는 CPU와 GPU 실행 경로가 모두 설명돼 있으며 Docker, Podman, 호스트 가상화도 지원 옵션으로 나와 있습니다. 런타임이 NVIDIA GPU를 필수로 요구한다고 명시돼 있지는 않지만, 필요한 드라이버와 배포 조합은 직접 검증해야 합니다.
OpenShell은 운영 환경에서 사용할 준비가 됐나요?
OpenShell 0.1.x에는 문서화된 릴리스 라인이 있지만, 공식 자료에는 독립적인 보안 인증이나 광범위한 성능 벤치마크가 없습니다. 보편적인 운영 보장으로 받아들이기보다, 자신의 위협 모델에 맞춰 검증해야 하는 인프라로 보는 편이 타당합니다. 저장소에는 Apache License 2.0이 적용돼 있습니다. 자체 컴퓨팅 자원, 게이트웨이 운영, 정책 유지보수, 보안 테스트에 필요한 비용도 예산에 포함해야 합니다(OpenShell README).
종합 평가: 통과.
OpenShell에서 Claude Code나 Codex를 실행할 수 있나요?
NVIDIA의 기술 블로그는 호환 가능한 에이전트로 Claude Code와 Codex를 언급합니다. 런타임은 기존 에이전트 작업을 다시 작성하게 하기보다 그대로 감싸서 실행하는 것을 목표로 합니다.
샌드박스를 다시 만들지 않고 파일 시스템 규칙을 변경할 수 있나요?
아니요. 보안 가이드에서는 파일 시스템과 프로세스 제어를 정적 설정으로 분류합니다. 반면 네트워크 정책과 프로바이더 연결은 샌드박스가 실행 중인 상태에서도 변경할 수 있습니다.
OpenShell과 Docker의 차이는 무엇인가요?
Docker는 컨테이너화 기능을 제공합니다. OpenShell은 여기에 에이전트 중심의 정책 계층을 더해 파일 시스템, 프로세스, 네트워크, API 작업, 자격 증명, 정책 검토를 통제합니다. 두 기술은 하나의 배포 환경에서 함께 사용할 수도 있습니다.