AI 에이전트 · 실행 환경 보안
모델이 생각하고 실행 환경이 권한을 통제합니다
엔비디아가 10월 21일 OpenShell 참조 아키텍처를 공개했습니다. 기존 보안 런타임에 모델 추론·도구 실행·독립 감시를 결합하되, 파트너 통합과 실제 도입 조건은 구분해야 합니다.
이 글에서 다룰 내용
참조 아키텍처 발표, 추론·실행·통제의 역할, OpenShell 네 구성요소, 선택적 하드웨어 보호, 기업 도입 검토 기준
오늘 공개한 것은 새로운 런타임이 아닙니다
엔비디아가 2026년 10월 21일 GTC Berlin에서 엔비디아 OpenShell 참조 아키텍처를 발표했습니다. 기존 오픈소스 OpenShell 보안 런타임을 바탕으로 기업 인프라와 엣지 환경까지 범위를 넓힌 전체 스택 설계입니다.
이번 발표를 OpenShell 소프트웨어의 첫 출시로 이해하면 정확하지 않습니다. 핵심은 이미 있던 보안 런타임을 중심으로 에이전트를 어디에서 실행하고 누가 통제할지까지 연결했다는 점입니다.
AI 에이전트가 문서를 읽는 데서 그치지 않고 파일을 수정하거나 외부 도구를 호출한다면 답변 품질과 별개로 실행 권한을 관리해야 합니다. 이번 참조 아키텍처는 에이전트의 실행과 통제를 분리하는 구조에 초점을 맞춥니다.
모델 추론과 도구 실행, 감시를 나눕니다
Vera Rubin 인프라는 모델 추론을 담당하고 Vera CPU는 에이전트 하네스와 도구 사용, 실행을 맡습니다. 하네스는 모델이 도구를 호출하고 작업을 이어 가도록 연결하는 실행 틀로 이해하면 쉽습니다.
별도의 통제 역할은 BlueField-4 DPU에서 동작하는 NVIDIA Sentry가 담당합니다. 에이전트를 실행하는 쪽과 독립된 위치에서 활동을 감시하고 실리콘 수준의 정책 집행을 맡는 구조입니다.
여기서 Sentry는 에이전트를 지켜보는 또 다른 AI 모델이 아닙니다. DOCA 기반 보안 소프트웨어 프레임워크이며 모델 추론이나 에이전트의 업무 수행과 구분해야 합니다.
OpenShell은 실행 중에도 계속 경계를 둡니다
OpenShell의 출발점은 단순합니다. 에이전트를 한 번 승인했다고 계속 믿는 대신, 실행 내내 신뢰하지 않는 대상으로 취급하고 필요한 순간에 필요한 접근만 부여합니다.
에이전트가 스스로 “이 행동은 안전하다”고 판단하도록 맡기는 방식과는 다릅니다. 파일, 프로세스, 외부 요청, 자격증명에 대한 통제를 실행 환경 쪽에 두는 접근입니다.
AI 에이전트 보안에서 중요한 질문도 달라집니다. 모델이 지시를 잘 따르는지만 볼 것이 아니라 잘못된 요청을 하더라도 실행 환경이 어디까지 허용하고 어디에서 막는지 살펴봐야 합니다.
네 구성요소는 서로 다른 경계를 맡습니다
Gateway는 샌드박스의 생성부터 종료까지 수명주기와 정책을 관리하는 제어면입니다. 개별 작업이 실행되는 공간과, 그 공간에 적용할 규칙을 관리하는 역할을 구분합니다.
Supervisor는 샌드박스와 별도로 실행됩니다. 외부로 나가는 요청을 정책과 대조하고 자격증명에 접근하는 과정도 중개합니다.
Sandbox는 파일시스템과 프로세스 접근을 격리하는 실행 공간입니다. 에이전트가 작업한다고 해서 주변 시스템 전체에 자유롭게 접근하도록 두지 않는 경계입니다.
Policy prover는 부여되는 권한이 조직에서 정한 상한 안에 있는지 형식적으로 검사합니다. 다만 이를 에이전트의 모든 행동이나 답변 정확성을 수학적으로 보증하는 기능으로 확대해서는 안 됩니다.
독립 하드웨어 감시는 선택적 보호 장치입니다
기술 글은 추가 보호가 필요한 배치에서 BlueField-4와 Sentry를 선택적 하드웨어 보호 장치로 설명합니다. OpenShell 소프트웨어를 사용하는 모든 환경에 DPU가 필수라는 의미는 아닙니다.
소프트웨어 경계가 에이전트의 접근과 실행을 제한한다면 독립 하드웨어 감시는 별도 위치에서 활동을 살피고 정책을 집행하는 역할입니다. 두 계층은 같은 기능을 반복한다기보다 서로 다른 지점에서 통제를 맡습니다.
엔비디아 설명에 따르면 Sentry는 요청과 응답, 네트워크와 파일 활동을 관찰하고 정체성과 위임 권한을 확인합니다. 선택된 호스트 메모리 분석과 위협·정책 위반 탐지 시 격리도 설명하지만, 모든 내부 추론을 보거나 모든 공격을 차단한다는 뜻은 아닙니다.
지금 공개된 범위와 파트너 계획은 다릅니다
공식 발표는 참조 아키텍처가 현재 제공된다고 안내합니다. 하지만 참조 아키텍처 공개와 모든 파트너 통합 완료는 다른 이야기입니다.
데이터센터뿐 아니라 RTX Spark, DGX Spark, DGX Station으로의 엣지 확장도 명시했습니다. Linux·Kubernetes와 Microsoft Windows·MXC 등의 환경 설명 역시 포함되지만 모든 PC나 클라우드에 즉시 설치할 수 있다는 보장은 아닙니다.
기업 소프트웨어·모델·보안 업체와의 협력도 진행 중입니다. 따라서 도입을 검토할 때는 발표에 이름이 등장하는지보다 실제 사용할 환경에서 어떤 구성과 통합이 제공되는지 구분해서 읽는 편이 정확합니다.
도입 검토는 권한과 회수 기준부터 시작합니다
다음은 제품의 특정 설정 화면을 설명하는 것이 아니라 일반적인 도입 검토 항목입니다. 먼저 에이전트가 읽어도 되는 데이터와 수정해도 되는 데이터, 호출 가능한 도구의 범위를 나눠야 합니다.
다음으로 누가 권한을 승인하고 회수할지 정해야 합니다. 작업이 끝났거나 담당자가 바뀌었을 때도 접근 권한이 남지 않도록 운영 책임을 명확히 하는 것이 기업 AI 거버넌스의 중요한 출발점입니다.
감사 로그와 격리 동작은 실제 환경에서 시험할 대상입니다. 허용되지 않은 도구 호출이나 파일 접근을 시도했을 때 무엇이 기록되고 어떤 작업이 중단되는지 확인해야 합니다.
이번 발표의 의미는 보안이 완전히 해결됐다는 데 있지 않습니다. 일을 수행하는 에이전트와 그 권한을 통제하는 환경을 분리한다는 설계 방향을 구체화했다는 데 있습니다.
한 줄 요약: 엔비디아 OpenShell 참조 아키텍처는 AI 에이전트가 일을 수행하는 실행 계층과 그 행동의 허용 범위를 정하고 감시하는 통제 계층을 분리합니다.
감자나라 AI 강의보기 5,000 
