NVIDIA OpenShell 참조 아키텍처, 에이전트 집행을 인프라로 옮기다
NVIDIA는 10월 21일 NVIDIA OpenShell Reference Architecture를 출시하며, 작업을 수행하는 소프트웨어의 통제 범위를 넘어 에이전트 권한을 관리하는 방안을 제시했다. GTC Berlin에서 발표된 이 설계는 모델 연산, 에이전트 실행, 독립적인 보안 집행을 연결한다. 핵심 제안은 실용적이다. 에이전트는 자율적으로 계속 작업하되, 자신의 제한을 다시 쓰는 권한까지 얻어서는 안 된다.
이는 더 뛰어난 모델을 선택하는 것과는 다른 구매 결정으로 이어진다. 기업은 권한이 어디에 존재하는지, 어떤 인프라가 이를 집행하는지, 문제가 발생한 뒤 누가 에이전트를 중단시킬 수 있는지를 결정해야 한다. 핵심 긴장은 유용한 자율성과 정당한 작업을 막지 않으면서 무단 행위를 방지할 만큼 정밀한 제한 사이에 있다.
Anthropic의 Claude Code도 운영 환경을 통해 에이전트를 제한한다는 점에서 유용한 비교 대상이다. NVIDIA는 이 논의를 엔터프라이즈 인프라와 선택적 하드웨어 집행으로 확장한다. 이제 개발자, 보안팀, 비즈니스 소프트웨어 공급업체는 공통된 질문에 직면한다. 조직은 비즈니스 규칙을 실행 중에도 계속 유효한 경계로 어떻게 전환할 수 있을까?
NVIDIA OpenShell Reference Architecture, 실행과 집행을 연결하다
이번 발표는 작업 수행과 통제를 위한 구성 요소를 분리해 에이전트 격리를 인프라의 책임으로 제시한다.
참조 아키텍처는 조직과 파트너가 배포 환경을 구축할 때 활용할 수 있는 문서화된 시스템 설계다. 명시된 모든 통합 기능이 동일한 역량을 갖춘 완성 제품으로 제공된다는 뜻은 아니다. 프로세서, 운영 체제, 보안 공급업체, 엔터프라이즈 애플리케이션을 아우르는 발표를 평가할 때 이 구분은 중요하다.
NVIDIA의 OpenShell reference architecture에 따르면 Vera Rubin 인프라는 모델을 실행하고, Vera CPU는 모델 호출과 도구를 조정하는 소프트웨어인 에이전트 하니스를 운영한다. 특수 인프라 프로세서인 BlueField-4 데이터 처리 장치는 독립적인 모니터링과 집행을 위한 Sentry 보안 소프트웨어를 실행한다.
이 분리는 서로 다른 운영 문제를 반영한다. 계획을 생성하려면 연산 능력이 필요하다. 이를 실행하려면 파일, 서비스, 도구에 대한 접근이 필요하다. 이러한 행위를 승인하려면 실행 중인 에이전트가 제한이 자신의 업무를 방해한다는 이유만으로 변경할 수 없는 규칙이 필요하다.
이번 발표는 사용자나 장비와 더 가까운 곳에서 작동하는 로컬 및 엣지 배포 환경으로도 설계를 확장한다. NVIDIA는 RTX Spark, DGX Spark, DGX Station을 언급했다. 구매자는 로컬 워크스테이션이 대규모 인프라 배포를 위해 설명된 모든 보호 기능을 제공한다고 가정하지 말고, 각 환경을 개별적으로 평가해야 한다.
중요한 변화는 이러한 구성 요소 사이에 제안된 관계다. 이 아키텍처는 보안을 개발 후 덧붙이는 애플리케이션 기능으로 다루는 대신, 집행을 애플리케이션 아래에 배치한다. 에이전트의 요청은 그럴듯한 설명을 생성했다는 이유로 수용되는 것이 아니라 인프라가 평가하는 대상이 된다.
예를 들어 설명할 수 있는 엔지니어링 작업을 생각해 보자. 에이전트가 장애가 난 서비스를 조사하고 수정을 제안한다. 진단 파일 읽기, 종속성 설치, 구성 변경, 수정 사항 배포는 서로 다른 권한을 의미한다. 서비스를 복구하라는 단일 지시가 가능한 모든 단계에 권한이 부여됐음을 뜻하지는 않는다.
이 사례는 이 아키텍처가 보안 전문가를 넘어 중요한 이유를 설명한다. 자율 실행을 약속하는 제품팀도 그 실행의 경계를 설명해야 한다. 그렇지 않으면 고객은 그에 상응하는 통제 설명 없이 기능 설명만 받게 된다.
가용성 역시 신중하게 해석해야 한다. NVIDIA는 참조 아키텍처가 제공된다고 말하지만, 이것이 모든 파트너 조합에서 프로덕션 준비가 완료됐다는 뜻은 아니다. 문서화된 설계, 지원되는 배포, 검증된 고객 설치는 서로 다른 질문에 답한다.
따라서 출시를 평가하는 독자가 먼저 물어야 할 질문은 구체적이다. 제안된 실행 및 집행 체인 가운데 제공되는 구성에 실제로 존재하는 부분은 무엇인가? 답에 따라 구매자가 소프트웨어 제어, 추가 하드웨어 보호 또는 둘을 결합한 로드맵 중 무엇을 평가하는지가 결정된다.
엔터프라이즈 팀이 권한 문제를 떠안게 되다
집행을 인프라로 옮기면 기업의 통제력은 커지지만, 정책 결정을 암묵적으로 남겨두기는 더 어려워진다.
즉각적인 부담은 비즈니스 권한을 기술적 권한으로 전환하는 팀에 돌아간다. 보안팀은 제한된 리소스를 정의할 수 있지만, 비즈니스 책임자는 어떤 행위가 특정 작업에 속하는지 설명해야 한다. 이후 인프라팀은 에이전트가 접하는 시스템 전반에서 이러한 결정을 집행 가능하게 만들어야 한다.
“고객 갱신을 준비하라”는 지시에는 상당한 모호성이 담겨 있다. 이는 계정 이력을 읽고 제안서를 작성하는 일은 정당화할 수 있다. 그러나 계약 조건 변경, 고객 기록 내보내기, 검토 없이 제안서 발송까지 자동으로 정당화하지는 않는다.
이는 보고된 OpenShell 배포 결과가 아니라 설명을 위한 구분이다. 에이전트 보안이 모델을 식별하거나 직원이 요청을 시작했는지 확인하는 것 이상을 요구하는 이유를 보여 준다. 권한은 행위, 대상, 상황에 따라 달라진다.
NVIDIA의 agent runtime controls는 게이트웨이, 감독자, 샌드박스, 정책 검증자에 책임을 나눈다. 게이트웨이는 정책과 샌드박스 수명 주기를 관리한다. 감독자는 격리된 실행 환경인 샌드박스 외부에서 요청을 확인하고 자격 증명을 중재한다. 정책 검증자는 조직이 정의한 상한선에 따라 권한을 확인한다.
이 분리는 집행 위치를 제공하지만, 조직은 여전히 각 위치가 무엇을 허용해야 하는지 결정해야 한다. 형식적으로 확인된 상한선은 정책 간 관계를 확인할 수 있다. 그러나 비즈니스 부서가 처음부터 과도한 접근 권한을 부여했는지는 독립적으로 판단할 수 없다.
이는 애플리케이션 개발자와 보안 검토자 사이의 논의를 바꾼다. 에이전트가 전반적으로 신뢰할 수 있는지를 묻는 대신, 무엇을 읽고, 수정하고, 호출하고, 전송할 수 있는지 검토할 수 있다. 이 질문들은 더 실행 가능한 답을 만들지만, 더 상세한 준비도 요구한다.
개발자에게도 관련된 설계 제약이 있다. 광범위한 권한이 주어져야만 성공하는 워크플로는 명시적이고 제한된 요구사항을 지닌 워크플로보다 승인받기 어렵다. 도구 인터페이스와 작업 설명은 권한을 얼마나 정밀하게 표현할 수 있는지를 결정하므로 보안 설계의 일부가 된다.
지식 근로자에게 이 구분은 정보 접근에서 시작된다. 검색 가능한 지식 기반은 유용한 자료가 어디에 있는지 파악하는 데 도움이 된다. 행동을 수행하는 에이전트는 또 다른 결정을 요구한다. 정보를 찾을 권한이 이를 공유하거나 해당 정보를 포함한 시스템을 변경할 권한까지 부여하는가?
조직의 부담은 계속된다. 직원은 역할을 바꾸고, 프로젝트는 종료되며, 자격 증명은 만료되고, 애플리케이션에는 새로운 기능이 추가된다. 에이전트의 권한은 첫 시연을 성공시킨 접근 권한을 그대로 유지하는 것이 아니라 이러한 변화를 반영해야 한다.
이 때문에 거버넌스는 승인 문서로 끝날 수 없다. 기업에는 작업을 승인하는 사람, 그 권한을 나타내는 정책, 이를 집행하는 인프라 사이의 연결이 필요하다. 이 연결이 없다면 독립적으로 집행되는 규칙도 오래되었거나 지나치게 광범위한 결정을 그대로 보존할 수 있다.
따라서 이번 출시는 인프라 구매자만큼이나 소프트웨어 공급업체에도 압박을 가한다. 공급업체는 고객이 에이전트 행위를 관리할 수 있도록 충분한 세부 정보를 제공해야 한다. 모든 작업을 구분할 수 없는 요청으로 제시하는 시스템은 고객에게 광범위한 접근과 업무 중단 사이의 거친 선택만 남긴다.
하드웨어 격리가 경계가 유지되는 위치를 바꾸다
NVIDIA의 하드웨어 제안은 독립적인 집행 위치를 추가한다. 그 가치는 관련 행위가 실제로 그 위치를 통과하는지에 달려 있다.
소프트웨어 제한에는 정의된 범위가 있다. 그 보호 효과는 이를 집행하는 구성 요소와 해당 구성 요소가 전제하는 가정에 달려 있다. 별도의 하드웨어 보안 계층을 추가하면 에이전트의 실행 환경 밖에 제어 기능을 배치함으로써 이러한 가정 일부가 바뀐다.
NVIDIA는 Sentry를 OpenShell의 소프트웨어 경계와 함께 사용하는 선택적 추가 보호 기능으로 설명한다. 이 구분은 흔한 오해를 막는다. OpenShell을 사용한다고 해서 배포 환경에 BlueField-4 집행 기능이 자동으로 포함되는 것은 아니다. 구매자는 보안 주장을 비교하기 전에 실제 구성을 확인해야 한다.
NVIDIA의 Sentry runtime security 설계에서 BlueField-4는 모델 및 외부 시스템으로 향하는 노드의 통신 경로에 위치한다. Sentry는 트래픽 검사와 선택적인 호스트 메모리 분석을 결합한다. NVIDIA는 에이전트나 호스트 소프트웨어의 협조 없이도 수 밀리초 안에 에이전트를 격리할 수 있다고 말한다.
아키텍처의 논리는 간단하다. 침해된 워크로드가 이를 비활성화할 수 없다면, 그 워크로드에 대한 제어의 유용성은 커진다. 그러나 독립성만으로 완전한 적용 범위가 입증되지는 않는다. 집행 지점은 평가 대상 행위를 확인할 수 있어야 하며, 이를 차단할 권한도 유지해야 한다.
이는 배포 검토에서 구체적인 질문을 만든다. 구성이 관련된 모든 외부 연결을 제어된 경로로 라우팅하는가? 어떤 로컬 행위에 별도 제한이 적용되는가? 도구가 승인된 요청을 받은 뒤 다른 서비스에서 작업을 수행하면 어떻게 되는가?
이 질문들은 발견된 실패를 기록하는 것이 아니라 설계에서 비롯된다. 에이전트의 워크플로는 여러 관리 경계를 넘을 수 있으므로 중요하다. 다음 연결을 차단한다고 해서 다른 애플리케이션이 이미 수락한 행위를 반드시 되돌릴 수 있는 것은 아니다.
암호화된 트래픽은 또 다른 구성 결정을 요구한다. NVIDIA는 복호화 및 검사가 구성된 연결에 대한 검사를 설명한다. 따라서 기업은 검사가 어디에 적용되는지, 어떤 정보가 노출되는지, 그러한 가시성이 기밀성 요구사항과 어떻게 부합하는지 이해해야 한다.
Anthropic과의 비교는 설계 선택을 명확히 하는 데 도움이 된다. Anthropic의 Claude Code sandboxing은 운영 체제 메커니즘을 사용해 파일 시스템 및 네트워크 접근을 제한한다. Anthropic이 밝힌 접근 방식은 미리 정의된 경계 안에서는 에이전트에 자유를 부여하면서 그 밖의 접근은 통제한다.
두 접근 방식 모두 모델이 생성한 지시문 외부에 제한을 둔다. 차이는 제한 없는 소프트웨어와 보안 하드웨어의 단순한 경쟁이 아니다. 구매자는 강제 적용 방식, 배포 요건, 실패에 대한 가정을 비교하고 있다.
Anthropic의 사례는 개발자 실행 환경을 다룬다. NVIDIA의 발표는 에이전트 실행을 선택 가능한 독립 하드웨어 계층을 포함한 더 폭넓은 인프라 설계와 연결한다. 어느 설명도 그 자체만으로 특정 기업 워크로드에 어떤 방식이 가장 적합한지를 확정하지는 않는다.
범위가 좁은 개발 작업을 수행하는 조직이라면 기존 환경 제어를 그 자체의 장점에 따라 평가할 필요가 있다. 호스트 소프트웨어로부터의 추가 독립성이 필요한 민감한 배포 환경에서는 NVIDIA의 하드웨어 접근 방식이 다른 선택지가 된다. 결정은 해결하려는 위협을 기준으로 내려야 한다.
핵심 절충안은 더 강력한 분리와 더 높은 배포 복잡성 사이에 있다. 추가 강제 적용 계층은 안전하지 않은 활동을 차단할 수 있는 지점을 하나 더 만든다. 동시에 정책, 가시성, 업데이트, 운영 책임이 시스템의 나머지 부분과 일관성을 유지해야 하는 구성 요소도 하나 더 늘어난다.
파트너 발표가 드러내는 서로 다른 준비 단계
가장 유용한 파트너 세부 정보는 현재 이용 가능한 기능과 아직 계획 단계에 머물러 있는 통합을 구분한다.
ServiceNow는 이 아키텍처가 엔터프라이즈 제품 논의로 진입하는 구체적인 사례를 제공한다. 엔터프라이즈 에이전트 거버넌스 발표에 따르면 장기 작업을 위해 설계된 개인 에이전트 Arc는 정식으로 제공되고 있다. ServiceNow는 OpenShell 강제 적용을 Arc의 거버넌스 적용 실행 환경의 일부로 설명한다.
같은 발표는 OpenShell 및 BlueField 강제 적용과의 AI Passport 통합을 향후 릴리스에 배치한다. AI Passport는 에이전트의 권한을 전달하기 위한 권한 기록이다. 현재 애플리케이션 출시가 제안된 거버넌스 체인 전체의 이용 가능성을 입증하지는 않기 때문에, 계획 단계라는 점이 중요하다.
이 구분은 구매자에게 다른 출시 자료를 읽는 유용한 기준을 제공한다. 현재 시제의 이용 가능성은 의도된 통합, 파트너 협업, 향후 기능과 별도로 평가해야 한다. 이를 하나의 준비 상태라는 인상으로 합치면 여전히 필요한 작업이 가려진다.
ServiceNow의 사례는 비즈니스 문제도 구체적으로 보여 준다. 지속적으로 작동하는 업무용 에이전트는 변화하는 할당 업무와 권한 전반에서 작동해야 한다. 특히 작업이 사용자의 즉각적인 주의 범위를 넘어 계속될 때, 거버넌스는 최초 요청 이후에도 유효하게 유지되어야 한다.
예를 들어 직원이 에이전트에게 프로젝트 인수인계를 조율하도록 맡기는 경우를 생각해 볼 수 있다. 프로젝트 문서 읽기, 미완료 작업 식별, 메시지 초안 작성, 접근 권한 변경에는 서로 다른 권한이 필요하다. 유용한 시스템은 작업이 진행됨에 따라 이러한 구분을 유지해야 한다.
보안 파트너는 또 다른 차별화 계층을 도입한다. F5는 런타임 권한을 지원되는 프롬프트, 응답, 도구 호출 검사로 보완하는 AI 트래픽 검사를 설명한다. 또한 발표에서는 제품 검증을 전제로 한 제안된 배포 토폴로지를 구분한다.
이는 사소한 각주가 아니라 중요한 조건이다. 파트너는 아키텍처의 방향을 지지하면서도 특정 구성에는 여전히 검증이 필요할 수 있다. 고객은 어떤 배포가, 어떤 검사 기능을 활성화한 상태에서, 어떤 워크로드를 대상으로 테스트되었는지 물어야 한다.
F5의 설명은 권한 부여와 콘텐츠 평가도 분리한다. 요청이 승인된 서비스를 대상으로 하면서도 민감한 정보나 악의적인 지시를 포함할 수 있다. 연결 권한과 전송되는 콘텐츠에 대한 판단은 서로 다른 위험을 다룬다.
이것이 출시 발표가 인프라 강제 적용을 기존의 모든 방어 수단을 대체하는 방식으로 제시하지 않고 보안 파트너를 포함하는 이유를 설명한다. 제안된 경계에는 신원, 권한 부여, 의심스러운 활동에 관한 입력이 필요하다. 무언가가 차단된 뒤의 운영 대응도 필요하다.
상업적 관건은 이러한 계층을 함께 더 쉽게 운영할 수 있게 되는지다. 구매자는 일관된 정책과 이해하기 쉬운 사고 기록을 찾아야 한다. 결정 간 관계가 명확하지 않은 별도 콘솔을 추가하면 조사자는 연결되지 않은 시스템 전반에서 발생한 일을 재구성해야 한다.
폭넓은 파트너 구성은 관심을 보여 주지만, 배포 세부 사항이 더 큰 비중을 갖는다. 고객은 지원되는 구성, 문서화된 제한 사항, 또는 제공된 통합을 평가할 수 있다. 출시 목록에 회사 이름이 있다는 사실만으로는 그 고객이 오늘 안전하게 운영할 수 있는 것에 관한 증거가 부족하다.
안전한 경계는 여전히 올바른 규칙에 달려 있다
NVIDIA OpenShell Reference Architecture는 승인된 행동과 좋은 판단 사이의 구분을 없애지 않는다.
에이전트는 권한 범위 안에 머물면서도 잘못된 결과를 낼 수 있다. 문서를 잘못 해석하거나, 잘못된 기록을 선택하거나, 부적절한 권고를 할 수 있다. 인프라 격리는 행동의 범위를 다루지만, 모든 결론의 진실성을 보장하지는 않는다.
이 구분은 조직이 “안전”이라는 단어를 해석하는 방식에 영향을 주어야 한다. 안전은 폭넓은 결과인 반면, 런타임 강제 적용은 특정한 제어를 제공한다. 의미 있는 평가는 방지하려는 실패와 그 방지가 성립하는 가정을 식별한다.
일정 관리 시스템을 업데이트할 권한이 있는 에이전트를 생각해 보자. 제한은 해당 에이전트가 급여 데이터에 접근하지 못하도록 성공적으로 막을 수 있다. 그러나 같은 에이전트는 허용된 애플리케이션 내에서 여전히 잘못된 약속을 잡을 수 있다. 두 결과 모두 중요하지만, 서로 다른 안전장치가 필요하다.
지나치게 넓은 권한도 또 다른 한계를 만든다. 에이전트가 전체 데이터세트를 내보내도록 허용하는 규칙이 완벽하게 강제 적용되더라도, 승인된 내보내기로부터 그 데이터세트를 보호하지는 못한다. 강제 적용이 설계대로 정확히 작동하더라도 비즈니스 판단의 질은 여전히 핵심이다.
지나치게 좁은 권한은 반대의 문제를 만든다. 일상 업무가 반복적으로 중단되면 사용자는 더 넓은 접근 권한을 요청할 유인을 갖게 된다. 그러면 보안 팀은 어떤 차단이 피해를 예방하고 어떤 차단이 적법한 작업에 부적절하게 맞춰진 정책을 반영하는지에 관한 증거가 필요하다.
이는 분석상의 우려이지 OpenShell이 불필요한 중단을 유발한다는 결론이 아니다. 이는 자율성의 절충안을 평가하는 데 필요한 측정을 식별한다. 성공적인 격리는 유용한 작업 완료, 개입 빈도, 거부된 작업의 결과와 함께 고려해야 한다.
탐지 시점에도 맥락이 필요하다. 신속한 격리 주장은 관련 조건이 탐지된 뒤의 대응을 설명한다. 구매자는 여전히 어떤 이벤트가 탐지를 촉발하는지, 격리가 시작되기 전에 외부 시스템이 이미 조치를 취했는지를 이해해야 한다.
현재 제공되는 공급업체 설명은 엔터프라이즈 워크플로 전반에 걸친 독립적으로 검증된 보편적 보장을 확립하지 않는다. 이는 의도된 메커니즘과 통합 지점을 설명한다. 운영 환경의 보안 결론에는 권한과 활성화된 보호 기능을 포함해 배포된 구성에 연계된 증거가 필요하다.
확장된 관찰 가능성에는 개인정보 보호 측면도 있다. 통신과 실행 맥락을 검사하면 조사를 개선할 수 있지만, 민감한 자료가 추가 보안 구성 요소에 노출될 수 있다. 조직은 검사 범위, 기록 접근, 보존에 대해 명확한 결정을 내려야 한다.
운영 책임도 같은 수준의 주의를 받아야 한다. 누군가는 정책을 유지하고, 거부를 조사하고, 예외를 승인하고, 격리 후 에이전트를 복구해야 한다. 이러한 책임이 불분명하게 남아 있으면 기술적으로 효과적인 경계도 장기간의 중단이나 안전하지 않은 우회책을 낳을 수 있다.
NVIDIA의 접근 방식은 규칙을 독립적으로 강제 적용할 수 있는 지점을 식별하기 때문에 이러한 질문을 더 구체적으로 만든다. 이는 시스템 설계에서 유용한 진전이다. 그렇다고 규칙 자체나 보안 결정 주변의 워크플로를 평가할 필요성이 사라지는 것은 아니다.
따라서 적절한 기준은 제한된 주장이다. 특정 제어는 명시된 조건에서 특정한 무단 행동을 방지한다. 구매자는 이 진술을 에이전트가 해를 끼칠 수 없다는 일반적 약속으로 바꾸지 않아야 한다.
제공된 통합, 보안 증거, 운영 적합성을 주시하라
다음으로 의미 있는 신호는 제공된 기능, 재현 가능한 검증, 그리고 조직이 그에 따른 제어를 유지할 수 있다는 증거다.
향후 몇 달간 첫 번째 신호는 향후 작업으로 설명된 통합의 제공이다. ServiceNow가 계획한 AI Passport 강제 적용은 구체적인 사례를 제공한다. 지원 범위와 제한 사항이 문서화된 릴리스가 나오면 비즈니스 권한과 인프라 강제 적용 사이의 제안된 연결을 더 쉽게 평가할 수 있다.
이는 기업이 실행 계층 전반에 걸쳐 거버넌스 결정을 이어갈 수 있다는 근거를 강화할 것이다. 로드맵 언어가 계속된다면 제안의 해당 부분은 덜 확립된 상태로 남는다. 구매자는 제품 이용 가능성과 시연 또는 협업 발표를 구분해야 한다.
두 번째 신호는 완전한 배포 환경에 연계된 보안 검증이다. 유용한 증거는 워크로드, 정책 구성, 활성화된 검사, 시도된 무단 행동, 관찰된 결과를 설명할 것이다. 또한 어떤 적법한 작업이 계속 가능했는지도 설명해야 한다.
에이전트가 차단되는 모습을 보여 주는 시연은 왜 차단되었는지에 대한 재현 가능한 설명보다 적은 것을 입증한다. 후자는 고객이 동일한 제어가 자신의 애플리케이션에 적용되는지 판단하는 데 도움을 준다. 또한 프레젠테이션이 명시하지 않을 수 있는 가정도 드러낸다.
검증에는 공격뿐 아니라 허용된 워크플로도 포함되어야 한다. 예상된 작업을 허용하면서 무단 활동을 차단하는 경계는 아키텍처의 핵심 절충안을 뒷받침한다. 광범위한 예외에 반복적으로 의존한다면 기업이 자율성과 정밀한 제어를 결합할 수 있다는 주장은 약화될 것이다.
세 번째 신호는 실제 엔터프라이즈 환경 전반에서의 운영 적합성이다. 조직은 애플리케이션, 신원, 도구가 변해도 정책이 일관되게 유지되는지 알아야 한다. 또한 요청된 행동과 강제 적용 결정의 관계를 설명하는 사고 기록도 필요하다.
관리 가능한 정책 업데이트와 이해하기 쉬운 조사의 증거는 배포 근거를 강화할 것이다. 일관되지 않은 규칙이나 불분명한 책임 소재의 증거는 다른 병목을 드러낼 것이다. 그 경우 추가 강제 적용 역량만으로는 거버넌스 문제를 해결하지 못한다.
이러한 운영 평가에서는 로컬 및 엣지 배포 환경이 특히 주목받아야 한다. 독자는 배포되는 특정 시스템의 문서화된 기능을 확인해야 한다. 공유된 제품군이나 아키텍처 명칭만으로는 강제 적용 범위에 관한 모든 질문에 답할 수 없다.
개발자에게 실질적인 결과는 더 명확한 권한 요건에 대한 요구다. 엔터프라이즈 구매자에게는 구성별 증거에 대한 요구다. 지식 근로자에게는 에이전트에 정보 접근 권한을 부여하는 것과 행동 권한을 위임하는 것의 구분이다.
배포를 승인하기 전에 에이전트가 완료해야 할 정확한 워크플로와 그 권한 밖에 남겨야 할 조치를 식별해야 합니다. 공급업체에 제안된 구성에서 두 가지 결과를 모두 보여 달라고 요청하세요. 즉, 정당한 작업은 계속 진행되고 권한이 없는 조치는 중단되는 결과입니다. এরপর 누가 정책을 관리하는지, 접근 권한 변경이 어떻게 적용되는지, 조사관이 사후에 무엇을 재구성할 수 있는지 살펴보세요. 특히 소프트웨어와 하드웨어 출시 일정이 서로 다를 때는 현재 제공되는 기능과 향후 통합 계획을 분리해 판단해야 합니다. NVIDIA OpenShell Reference Architecture는 이러한 평가에서 검토할 수 있는 구체적인 인프라 설계를 제시합니다. 이를 활용해 실무적인 질문에 대한 명확한 답을 요구하세요. 에이전트가 독립적으로 작업하는 동안에도 어떤 결정이 조직의 통제 아래 남아 있는가?
