NemoClaw 아키텍처 심층 분석
NemoClaw는 단일 제품이 아니다 — 자율형 AI 에이전트를 프로덕션 환경에서 안전하게 배포하기 위해 설계된 다층 보안 아키텍처이다. 이 글에서는 각 레이어를 살펴보고, 이들이 어떻게 상호작용하는지 설명하며, 자체 인프라에서 NemoClaw를 평가하는 데 필요한 기술적 맥락을 제공한다.
아키텍처 개요
NemoClaw 스택은 에이전트 보안의 서로 다른 측면을 다루는 4개의 주요 레이어로 구성된다:
┌─────────────────────────────────────────────┐
│ Agent Application │
│ (OpenClaw Agent Framework) │
├─────────────────────────────────────────────┤
│ Privacy Router │
│ (Local vs. Cloud Model Routing) │
├─────────────────────────────────────────────┤
│ Nemotron Policy Engine │
│ (120B MoE Intent Classification) │
├─────────────────────────────────────────────┤
│ OpenShell Runtime │
│ (Kernel-Level Sandbox + Isolation) │
├─────────────────────────────────────────────┤
│ Host OS / Hardware (DGX) │
└─────────────────────────────────────────────┘
각 레이어는 독립적으로 작동하며 단독 배포가 가능하지만, 풀 스택은 단일 레이어만으로는 달성할 수 없는 심층 방어 보안을 제공한다.
레이어 1: OpenShell 보안 런타임
OpenShell은 NemoClaw 보안 모델의 기반이다. 에이전트 실행을 위한 커널 수준의 샌드박싱을 제공하여, 침해된 에이전트라도 보안 경계를 벗어날 수 없도록 보장한다.
OpenShell의 작동 원리
OpenShell은 Linux 커널 네임스페이스, seccomp-BPF 필터, NVIDIA의 커스텀 eBPF 프로그램을 결합하여 각 에이전트 작업에 대한 격리된 실행 환경을 생성한다:
# openshell-policy.yaml
apiVersion: openshell.nvidia.com/v1
kind: SandboxPolicy
metadata:
name: customer-support-agent
spec:
isolation:
network: restricted
filesystem: read-only
syscalls: minimal
resources:
maxMemory: 4Gi
maxCPU: 2
gpuAccess: inference-only
permissions:
allowedAPIs:
- crm.read
- crm.update
- ticket.create
- ticket.resolve
deniedAPIs:
- admin.*
- billing.*
- user.delete
auditLog:
enabled: true
destination: siem://security-events
에이전트가 수행하는 모든 시스템 콜은 OpenShell의 eBPF 레이어에서 가로채지며, 정책에 따라 분류되어 허용, 거부, 또는 사람의 승인을 위한 에스컬레이션이 결정된다. 전체 결정 파이프라인은 커널 공간에서 실행되어, 시스템 콜당 50마이크로초 미만의 레이턴시만 추가한다.
운영자 승인 워크플로
고위험 작업 — 데이터 삭제, 인프라 변경, 외부 통신 전송 — 에 대해 OpenShell은 에이전트 실행을 일시 정지하고 작업을 사람 운영자에게 라우팅하여 승인을 요청할 수 있다:
// Approval workflow configuration
const approvalPolicy = {
triggers: [
{ action: 'data.delete', threshold: 'always' },
{ action: 'infra.modify', threshold: 'always' },
{ action: 'email.send', threshold: 'external-only' },
{ action: 'payment.process', threshold: 'above-100-usd' },
],
channels: ['slack', 'teams', 'pagerduty'],
timeout: '15m',
defaultAction: 'deny',
};
이를 통해 에이전트는 일상적인 작업을 자율적으로 처리하면서도 중요한 동작에 대해서는 사람의 감독을 유지할 수 있다.
레이어 2: Nemotron 120B MoE 정책 엔진
Nemotron 120B Mixture-of-Experts 모델은 NemoClaw의 지능형 정책 평가 엔진으로 기능한다. 전통적인 규칙 기반 보안 시스템과 달리, Nemotron은 에이전트 동작 뒤에 있는 의도를 이해하고 자연어 보안 정책에 따라 평가할 수 있다.
의도 분류
에이전트가 동작을 요청하면, Nemotron은 여러 차원에서 의도를 분류한다:
- •민감도: 관련 데이터는 얼마나 민감한가? (공개, 내부, 기밀, 제한)
- •가역성: 이 동작을 되돌릴 수 있는가? (완전 가역, 부분 가역, 비가역)
- •범위: 영향을 받는 시스템 또는 사용자 수는? (개인, 팀, 조직, 외부)
- •컴플라이언스: 이 동작이 규제 프레임워크에 해당하는가? (GDPR, HIPAA, SOC 2, PCI-DSS)
분류 처리는 단일 A100 GPU에서 200ms 미만, 양자화 모델 변형을 사용한 DGX Spark에서는 50ms 미만으로 실행된다.
자연어 정책
보안 팀은 평이한 영어로 정책을 정의할 수 있으며, Nemotron이 이를 해석하고 적용한다:
Policy: "Customer support agents may access customer records for active tickets only.
They may not access financial data, modify account settings, or communicate
with customers outside of the ticketing system. All PII must be redacted
from internal logs."
Nemotron은 이러한 자연어 정책을 실행 가능한 보안 규칙으로 변환하여, 보안 팀의 의도와 기술적 적용 사이의 격차를 해소한다.
레이어 3: Privacy Router
Privacy Router는 NemoClaw의 지능형 모델 라우팅 레이어이다. 데이터 민감도 분류에 기반하여 각 에이전트 작업을 로컬 모델(온프레미스에서 실행되는 Nemotron)로 처리할지 클라우드 모델 엔드포인트로 라우팅할지 결정한다.
라우팅 로직
# Simplified Privacy Router logic
def route_request(request: AgentRequest) -> ModelEndpoint:
sensitivity = classify_sensitivity(request.context)
if sensitivity in ['restricted', 'confidential']:
# Highly sensitive data stays local
return local_nemotron_endpoint
if sensitivity == 'internal':
# Internal data can use cloud with encryption
return cloud_endpoint_with_e2e_encryption
if sensitivity == 'public':
# Public data can use any endpoint for best performance
return optimal_cloud_endpoint
# Default: local processing
return local_nemotron_endpoint
Privacy Router는 실시간 분류 캐시를 유지하므로, 유사한 컨텍스트의 반복 요청은 재평가 없이 라우팅된다. 벤치마크에서 라우터는 요청 파이프라인에 5ms 미만의 레이턴시만 추가한다.
데이터 거주지 컴플라이언스
데이터 거주지 요구 사항(EU GDPR, 중국의 PIPL 등)에 따라 운영하는 조직을 위해, Privacy Router는 지리적 라우팅 제약을 적용할 수 있다:
privacyRouter:
residencyRules:
- region: EU
dataTypes: [personalData, financialData]
allowedEndpoints: [eu-west-1-local, eu-central-1-local]
- region: CN
dataTypes: [all]
allowedEndpoints: [cn-north-1-local]
fallback: local-only
레이어 4: 네트워크 정책 엔진
네트워크 정책 엔진은 에이전트가 접근할 수 있는 외부 리소스를 제어한다. 투명 프록시로 작동하며, 에이전트 샌드박스에서 나가는 모든 아웃바운드 네트워크 요청을 검사하고 필터링한다.
정책 정의
networkPolicy:
name: sales-ops-agent
egress:
allow:
- domain: "*.salesforce.com"
methods: [GET, POST, PATCH]
- domain: "api.hubspot.com"
methods: [GET]
- domain: "smtp.company.com"
ports: [587]
deny:
- domain: "*" # deny all other outbound traffic
ingress:
allow:
- source: "webhook.salesforce.com"
path: "/api/v1/events"
inspection:
tlsDecrypt: true
logPayloads: false
scanForPII: true
네트워크 정책 엔진은 아웃바운드 요청에 대한 TLS 가로채기(적절한 인증서 관리 포함)를 지원하여, 요청 페이로드에서 의도치 않은 PII 유출을 스캔할 수 있다.
모두 통합하기
OpenClaw 에이전트가 작업을 수신하면, 요청은 다음과 같이 NemoClaw 스택을 통해 처리된다:
- 1.OpenClaw가 작업을 수신하고 실행 계획을 구성한다
- 2.Privacy Router가 데이터 민감도를 분류하고 적절한 모델 엔드포인트를 선택한다
- 3.Nemotron이 실행 계획을 보안 정책에 대해 평가하고 의도를 분류한다
- 4.OpenShell이 작업 실행을 위한 격리된 샌드박스를 생성한다
- 5.네트워크 정책 엔진이 에이전트의 역할에 따라 샌드박스의 네트워크 접근을 구성한다
- 6.에이전트가 샌드박스 내에서 실행되며, 모든 동작이 감사된다
- 7.고위험 동작은 사람 운영자에게 에스컬레이션되어 승인을 받는다
- 8.결과가 Privacy Router를 통해 반환되며, 로그에서 PII가 마스킹된다
이 전체 파이프라인은 세션의 첫 번째 요청에 약 300ms의 레이턴시를 추가하고, 후속 요청에는 캐싱으로 인해 100ms 미만만 추가한다. 대부분의 엔터프라이즈 워크로드에서 이 오버헤드는 모델 추론 시간에 비해 무시할 수 있는 수준이다.
성능 벤치마크
단일 DGX Spark 기준:
| 메트릭 | 값 |
|---|---|
| 정책 평가 레이턴시 (p50) | 45ms |
| 정책 평가 레이턴시 (p99) | 180ms |
| 샌드박스 생성 시간 | 120ms |
| 네트워크 정책 적용 | 15ms |
| 처리량 (동시 에이전트 수) | 64 |
| 샌드박스당 메모리 오버헤드 | 256MB |
DGX H100 클러스터 (8 GPU) 기준:
| 메트릭 | 값 |
|---|---|
| 정책 평가 레이턴시 (p50) | 12ms |
| 정책 평가 레이턴시 (p99) | 45ms |
| 처리량 (동시 에이전트 수) | 512 |
시작하기
NemoClaw 아키텍처 문서는 GitHub의 nvidia/nemoclaw에서 확인할 수 있다. 각 레이어는 독립적으로 배포할 수 있으므로, OpenShell 샌드박싱부터 시작하여 보안 요구 사항이 발전함에 따라 다른 레이어를 추가하는 방식으로 NemoClaw를 점진적으로 도입할 수 있다.
다음 글에서는 DGX Spark에 전체 NemoClaw 스택을 배포하는 실습 튜토리얼을 다룬다.
