OpenClaw를 안전하게 운영하는 AI 에이전트 보안 스택, 설치부터 활용까지
핵심 키워드: NemoClaw, NVIDIA OpenShell, OpenClaw 보안, AI 에이전트 샌드박스, Nemotron, 네트워크 정책, Claw 가드레일, 로컬 AI 추론
AI 에이전트가 파일을 읽고, 코드를 실행하고, API를 호출하며, 심지어 브라우저까지 제어하는 시대가 열렸습니다. OpenClaw는 이러한 자율 에이전트의 가능성을 보여주는 대표적인 오픈소스 프로젝트로, 출시 이후 GitHub에서 가장 빠르게 성장한 프로젝트 중 하나가 되었습니다. 하지만 이처럼 강력한 권한을 가진 AI 에이전트를 아무런 제약 없이 실행하는 것은 마치 관리자 권한을 가진 프로그램을 검증 없이 돌리는 것과 같습니다.
실제로 보안 연구자가 OpenClaw 에이전트를 2시간 만에 하이재킹하는 데 성공했다는 사례가 보고되면서, 에이전트 보안의 중요성이 크게 부각되었습니다. NVIDIA는 GTC 2026에서 이 문제에 대한 해답으로 NemoClaw를 발표했습니다. 이 글에서는 NemoClaw의 개념부터 설치, 네트워크 정책 설정, 추론 모델 구성, 그리고 실전 활용까지 단계별로 안내해 드리겠습니다.
목 차
1. NemoClaw란 무엇인가enClaw의 보안 문제와 NemoClaw의 등장
OpenClaw는 Telegram, Discord 같은 메시징 앱을 통해 명령을 내리면 파일 관리, 코드 실행, 웹 검색, API 호출 등을 자율적으로 수행하는 AI 에이전트입니다. 그러나 이 강력한 능력은 동시에 심각한 보안 위험을 내포합니다. OpenClaw 에이전트는 기본적으로 호스트 시스템의 파일 시스템에 접근할 수 있고, 임의의 셸 명령을 실행할 수 있으며, 네트워크를 통해 어떤 서버와도 통신할 수 있습니다. 기존의 안전장치는 프롬프트 수준의 행동 지침(behavioral prompt)에 의존하고 있어서, 에이전트 프로세스 내부에 가드레일이 존재하는 구조였습니다. 이는 에이전트가 손상되면 가드레일도 함께 무력화될 수 있다는 근본적인 취약점을 가지고 있었습니다.
NemoClaw는 NVIDIA가 GTC 2026(2026년 3월)에서 발표한 오픈소스 보안 스택으로, OpenClaw 위에 인프라 수준의 보안 계층을 추가합니다. 핵심 아이디어는 "가드레일을 에이전트 바깥으로 이동시키는 것"입니다. 에이전트가 스스로 안전하게 행동하기를 기대하는 대신, 에이전트가 실행되는 환경 자체를 격리하고 제한하는 방식입니다. 이를 위해 NVIDIA Agent Toolkit의 핵심 구성 요소인 OpenShell 런타임을 활용하며, NVIDIA의 오픈소스 LLM인 Nemotron 모델을 로컬에서 실행하여 데이터 프라이버시까지 강화합니다.
[i] 참고: NemoClaw는 2026년 3월 기준 Early Preview(알파) 상태입니다. 프로덕션 환경에서의 사용은 권장되지 않으며, API와 CLI 인터페이스가 변경될 수 있습니다.
OpenClaw vs NemoClaw 핵심 비교
OpenClaw와 NemoClaw의 차이를 이해하려면, 비유를 통해 설명하는 것이 가장 직관적입니다. OpenClaw가 "자유롭게 돌아다니는 로봇 비서"라면, NemoClaw는 그 로봇 비서를 "보안 구역 안에서만 활동하게 하고, 출입구에서 모든 행동을 검사하는 시스템"이라고 할 수 있습니다. 로봇의 능력 자체를 제한하는 것이 아니라, 로봇이 활동할 수 있는 공간과 접근할 수 있는 자원을 인프라 수준에서 통제하는 것입니다.
| 구분 | OpenClaw(단독) | NemoClaw(OpenClaw + OpenShell) |
| 보안 방식 | 프롬프트 기반 행동 지침 (에이전트 내부) | 인프라 기반 정책 강제 (에이전트 외부) |
| 실행 환경 | 호스트 시스템에서 직접 실행 | Landlock + seccomp + netns 격리 샌드박스 |
| 네트워크 제어 | 제한 없음 (모든 엔드포인트 접근 가능) | 화이트리스트 기반 (허용된 엔드포인트만 접근) |
| 파일 시스템 접근 | 호스트 전체 파일 시스템 접근 가능 | /sandbox, /tmp만 읽기-쓰기, 나머지 읽기 전용 또는 차단 |
| 추론 모델 | Anthropic Claude 등 클라우드 API 사용 | NVIDIA Nemotron 로컬 실행 + 클라우드 라우팅 선택 가능 |
| 추론 경로 | 에이전트가 직접 API 호출 | OpenShell 게이트웨이를 통한 프록시 라우팅 |
| 설치 방식 | npm install -g @anthropic-ai/openclaw | curl -fsSL https://nvidia.com/nemoclaw.sh | bash |
| 운영자 개입 | 없음 (에이전트가 자율적으로 판단) | 미승인 네트워크 요청 시 운영자 승인/거부 TUI |
| 라이선스 | MIT | Apache 2.0 |
2. NemoClaw 아키텍처 이해하기
전체 아키텍처 개요
NemoClaw의 아키텍처는 크게 세 가지 계층으로 구성됩니다.
- 가장 바깥의 호스트 계층에서는 NemoClaw CLI와 OpenShell 게이트웨이가 실행
- 중간의 격리 계층에서는 커널 수준의 보안 메커니즘(Landlock LSM, seccomp, 네트워크 네임스페이스)이 샌드박스를 설정
- 가장 안쪽의 에이전트 계층에서는 OpenClaw 에이전트와 NemoClaw 플러그인이 실행
이 구조에서 핵심적인 원칙은 "에이전트의 모든 외부 통신이 OpenShell 게이트웨이를 거쳐야 한다"는 것입니다. 에이전트가 직접 인터넷에 접근하거나 호스트 파일 시스템에 쓰기를 시도하면, OpenShell이 이를 차단하거나 운영자의 승인을 요구합니다.
flowchart TB
subgraph HOST["호스트 시스템 (Linux)"]
direction TB
CLI["nemoclaw CLI<br/>(TypeScript Plugin)"]
GW["OpenShell Gateway<br/>(정책 강제 + 추론 라우팅)"]
TUI["openshell term<br/>(모니터링 TUI)"]
subgraph SANDBOX["샌드박스 (Landlock + seccomp + netns)"]
direction TB
OC["OpenClaw Agent<br/>(NemoClaw Plugin 포함)"]
FS["/sandbox (rw)<br/>/tmp (rw)<br/>/usr, /lib, /etc (ro)"]
end
end
subgraph INFERENCE["추론 서비스"]
CLOUD["NVIDIA Cloud API<br/>(build.nvidia.com)"]
LOCAL["Local NIM / vLLM<br/>(Nemotron 모델)"]
end
CLI -->|"launch / connect / status"| GW
TUI -->|"네트워크 승인/거부"| GW
GW -->|"정책 기반 필터링"| SANDBOX
OC -->|"추론 요청"| GW
GW -->|"라우팅"| CLOUD
GW -->|"라우팅"| LOCAL
OC --> FS핵심 구성 요소 상세
NemoClaw를 이루는 핵심 구성 요소는 다음 네 가지입니다. 각각의 역할과 상호 작용을 이해하면 전체 시스템의 동작 방식을 명확하게 파악할 수 있습니다.
- NemoClaw Plugin (TypeScript)은 OpenClaw CLI에 openclaw nemoclaw 네임스페이스로 명령어를 등록하는 얇은 플러그인입니다. 사용자가 openclaw nemoclaw launch, status, logs 같은 명령을 실행하면 이 플러그인이 처리합니다. 플러그인의 핵심 역할은 NemoClaw Blueprint를 다운로드하고, 무결성을 검증한 뒤, 서브프로세스로 실행하는 것입니다.
- NemoClaw Blueprint (Python)는 버전이 관리되는 Python 아티팩트로, 별도의 릴리스 스트림을 가집니다. Blueprint는 OpenShell CLI를 호출하여 게이트웨이 생성, 추론 프로바이더 등록, 샌드박스 생성, 네트워크 정책 적용 등의 작업을 수행합니다. Blueprint의 라이프사이클은 resolve(버전 확인) -> verify(무결성 검증) -> plan(리소스 계획) -> apply(적용) -> status(상태 보고)의 5단계로 구성됩니다.
- OpenShell Runtime은 NemoClaw의 보안 인프라를 실질적으로 담당하는 런타임입니다. 커널 수준의 격리(Landlock LSM으로 파일 시스템 접근 제어, seccomp으로 시스템 콜 필터링, 네트워크 네임스페이스로 네트워크 격리)를 제공하며, 추론 요청을 프록시하는 게이트웨이 역할도 수행합니다. OpenShell은 NVIDIA Agent Toolkit의 일부로, Apache 2.0 라이선스의 오픈소스 프로젝트입니다.
- Sandbox Container Image는 ghcr.io/nvidia/openshell-community/sandboxes/openclaw 이미지를 기반으로 실행되며, 내부에는 OpenClaw와 NemoClaw 플러그인이 미리 설치되어 있습니다. 이 컨테이너 내부에서 에이전트의 모든 작업이 수행되며, 외부와의 통신은 반드시 OpenShell 게이트웨이를 경유해야 합니다.
추론 라우팅 구조
NemoClaw에서 가장 특징적인 아키텍처 패턴 중 하나가 추론 라우팅(Inference Routing)입니다. 기존 OpenClaw에서는 에이전트가 Anthropic Claude API 같은 클라우드 서비스에 직접 요청을 보냈지만, NemoClaw에서는 모든 추론 요청이 OpenShell 게이트웨이를 거쳐 라우팅됩니다. 이 구조의 장점은 크게 두 가지입니다.
- 첫째, 에이전트가 민감한 API 키를 직접 보유하지 않아도 되므로 키 유출 위험이 줄어듭니다.
- 둘째, 운영자가 추론 대상을 클라우드 API에서 로컬 모델로 자유롭게 전환할 수 있어 프라이버시와 비용을 상황에 맞게 조절할 수 있습니다.
에이전트 (샌드박스 내부) --[추론 요청]--> OpenShell 게이트웨이 --[라우팅]--> NVIDIA Cloud API
--> 로컬 NIM 서비스
--> 로컬 vLLM 서버3. 설치 전 준비사항
하드웨어 요구사항
NemoClaw를 설치하기 전에 시스템이 최소 요구사항을 충족하는지 확인해야 합니다. 샌드박스 이미지 크기가 압축 상태에서 약 2.4GB이며, 이미지 빌드 및 푸시 과정에서 Docker 데몬, k3s, OpenShell 게이트웨이가 동시에 실행되면서 상당한 메모리를 소비합니다. 메모리가 8GB 미만인 시스템에서는 OOM(Out of Memory) 킬러가 발동하여 설치가 실패할 수 있으므로, 최소 8GB의 스왑 공간을 설정하는 것이 권장됩니다.
| 리소스 | 최소사양 | 권장사양 | 비고 |
| CPU | 4 vCPU | 4+ vCPU | 로컬 추론 시 GPU 별도 필요 |
| RAM | 8 GB | 16 GB | 8GB 미만 시 스왑 8GB 이상 설정 필요 |
| 디스크 | 20 GB 여유 | 40 GB 여유 | 샌드박스 이미지 약 2.4GB 압축 기준 |
| GPU | 없어도 가능 | NVIDIA RTX GPU | NVIDIA Cloud API 사용 시 GPU 불필요 |
[i] 참고: GPU는 로컬 추론(vLLM, NIM)을 사용하는 경우에만 필요합니다. NVIDIA Cloud API(build.nvidia.com)를 통한 추론을 사용하면 GPU가 없는 시스템에서도 NemoClaw를 실행할 수 있습니다.
소프트웨어 요구사항
NemoClaw는 현재 Linux 환경만 공식 지원합니다. macOS나 Windows는 직접 지원되지 않으며, Mac Mini 같은 환경에서 사용하려면 별도의 Linux VM 또는 원격 Linux 서버가 필요합니다. 이 점은 기존 OpenClaw가 macOS를 포함한 다양한 플랫폼을 지원하는 것과 중요한 차이입니다.
| 소프트웨어 버전 | 요구사항 | 설치 확인 명령 |
| Linux | Ubuntu 22.04 LTS 이상 | cat /etc/os-release |
| Node.js | 20 이상 | node --version |
| npm | 10 이상 | npm --version |
| Docker | 설치 및 실행 중 | docker info |
| OpenShell | 설치 필요 | openshell --version |
[!] 주의: macOS는 현재 NemoClaw를 직접 지원하지 않습니다. Mac Mini에서 사용하려면 Ubuntu Server VM을 실행하거나, 별도의 Linux 서버(VPS, DGX Spark 등)에 원격 배포하는 방식을 고려해야 합니다. WSL2 환경은 실험적 지원 상태이며 안정성이 보장되지 않습니다.
Docker 사전 설정
NemoClaw의 설치 과정에서 Docker는 핵심 인프라로 사용됩니다. 특히 Ubuntu 24.04이나 DGX Spark처럼 cgroup v2를 사용하는 시스템에서는 Docker 데몬의 설정을 사전에 조정해야 합니다. NemoClaw의 onboard 명령은 사전 점검(preflight check)을 수행하여 이 설정이 누락된 경우 오류와 함께 안내 메시지를 출력합니다.
cgroup v2 환경에서는 /etc/docker/daemon.json 파일에 다음 설정을 추가해야 합니다.
{
"default-cgroupns-mode": "host"
}
설정 파일을 수정한 후에는 Docker 서비스를 재시작해야 변경 사항이 적용됩니다.
# Docker 데몬 설정 변경 후 재시작
sudo systemctl restart docker
# 설정 확인
docker info | grep "Cgroup"
DGX Spark 사용자라면 NemoClaw가 제공하는 전용 설정 스크립트를 사용할 수 있습니다.
# DGX Spark 전용 설정 (sudo 필요)
sudo nemoclaw setup-spark
4. NemoClaw 설치하기
원클릭 설치
NemoClaw의 설치는 단 하나의 명령으로 시작됩니다. 이 설치 스크립트는 Node.js가 설치되어 있지 않으면 자동으로 설치하고, 이후 대화형 온보드 마법사(onboard wizard)를 실행하여 샌드박스 생성, 추론 설정, 보안 정책 적용까지 한 번에 처리합니다. docker-compose로 여러 컨테이너를 직접 구성하는 방식이 아니라, CLI가 내부적으로 OpenShell과 k3s 단일 컨테이너를 자동 생성하는 구조라는 점을 이해하는 것이 중요합니다.
# NemoClaw 설치 및 온보드 마법사 실행
curl -fsSL https://nvidia.com/nemoclaw.sh | bash
설치가 완료되면 다음과 같은 요약 정보가 출력됩니다. 이 정보에는 생성된 샌드박스의 이름, 적용된 보안 메커니즘, 사용 중인 추론 모델, 그리고 주요 관리 명령어가 포함됩니다.
──────────────────────────────────────────────────
Sandbox my-assistant (Landlock + seccomp + netns)
Model nvidia/nemotron-3-super-120b-a12b (NVIDIA Cloud API)
──────────────────────────────────────────────────
Run: nemoclaw my-assistant connect
Status: nemoclaw my-assistant status
Logs: nemoclaw my-assistant logs --follow
──────────────────────────────────────────────────[i] 참고: 설치 과정에서 NVIDIA API 키를 입력하라는 프롬프트가 나타납니다. build.nvidia.com에서 무료로 API 키를 발급받을 수 있으며, 입력된 키는 ~/.nemoclaw/credentials.json에 안전하게 저장됩니다. 로컬 추론만 사용할 계획이라면 이 단계를 건너뛸 수 있지만, 기본 프로필(NVIDIA Cloud)을 사용하려면 필수입니다.
설치 스크립트가 내부적으로 수행하는 작업
nemoclaw onboard 명령이 실행되면 내부적으로 여러 단계의 작업이 순차적으로 진행됩니다. 이 과정을 이해하면 문제가 발생했을 때 어느 단계에서 실패했는지 파악하기 쉽습니다.
flowchart LR
A["preflight check<br/>(Docker, cgroup, 권한)"] --> B["OpenShell Gateway<br/>생성"]
B --> C["추론 Provider<br/>등록"]
C --> D["Blueprint<br/>다운로드 + 검증"]
D --> E["Sandbox Image<br/>빌드 + 푸시"]
E --> F["Sandbox<br/>생성 + 정책 적용"]
F --> G["상태 확인<br/>+ 완료 보고"]
- 첫 번째 단계인 preflight check에서는 Docker 실행 상태, cgroup v2 설정, 현재 사용자의 docker 그룹 소속 여부, 디스크 여유 공간 등을 확인합니다. 이 단계에서 실패하면 구체적인 해결 방법과 함께 오류 메시지가 출력됩니다.
- 두 번째 단계에서는 OpenShell 게이트웨이를 생성하고,
- 세 번째 단계에서는 선택한 추론 프로바이더(NVIDIA Cloud, NIM, vLLM 등)를 등록합니다.
- 네 번째 단계에서 Blueprint를 다운로드하고 무결성을 검증한 뒤,
- 다섯 번째 단계에서 샌드박스 이미지를 빌드합니다.
- 마지막으로 샌드박스를 생성하고 네트워크 정책을 적용하면 설치가 완료됩니다.
에이전트에 접속하기
설치가 완료되면 샌드박스에 접속하여 에이전트와 대화를 시작할 수 있습니다. 접속 방법은 크게 두 가지입니다. TUI(Text User Interface)는 대화형 채팅 인터페이스를 제공하며, CLI는 단일 메시지를 전송하고 응답을 받는 용도로 적합합니다.
# 샌드박스에 접속
nemoclaw my-assistant connect
# TUI 모드로 채팅 시작 (대화형 인터페이스)
sandbox@my-assistant:~$ openclaw tui
# CLI 모드로 단일 메시지 전송
sandbox@my-assistant:~$ openclaw agent --agent main --local -m "hello" --session-id test
TUI 모드에서는 일반적인 채팅 앱처럼 메시지를 입력하고 Enter를 누르면 에이전트가 응답합니다. CLI 모드는 스크립트나 자동화 파이프라인에서 에이전트를 호출할 때 유용합니다. 두 가지 모드 모두 동일한 에이전트와 통신하며, 샌드박스 내부에서 실행되므로 모든 보안 정책이 동일하게 적용됩니다.
5. 샌드박스 환경 이해하기
커널 수준 격리 메커니즘
NemoClaw 샌드박스의 보안은 Linux 커널의 세 가지 보안 메커니즘을 조합하여 구현됩니다. 이 메커니즘들은 에이전트 프로세스 외부에서 작동하므로, 에이전트가 손상되더라도 우회할 수 없다는 것이 핵심적인 장점입니다. 기존 OpenClaw의 Sandbox가 Docker 컨테이너 수준의 격리를 제공했다면, NemoClaw의 OpenShell은 커널 수준의 더 깊은 격리를 제공합니다.
| 메커니즘 | 역할 | 적용 범위 |
| Landlock LSM | 파일 시스템 접근 제어 | /sandbox, /tmp만 rw 허용, 나머지 ro 또는 차단 |
| seccomp | 시스템 콜 필터링 | 위험한 시스템 콜(mount, reboot 등) 차단 |
| Network Namespace (netns) | 네트워크 격리 | 허용된 엔드포인트만 접근 가능, 나머지 차단 |
[i] 참고: Landlock LSM은 Linux 커널 5.13 이상에서 지원되며, 프로세스별로 파일 시스템 접근 규칙을 정의할 수 있는 보안 모듈입니다. 기존의 AppArmor나 SELinux보다 설정이 간단하면서도 유사한 수준의 파일 접근 제어를 제공합니다.
파일 시스템 접근 정책
샌드박스 내부의 파일 시스템 접근은 엄격하게 제한됩니다. 에이전트가 작업에 필요한 최소한의 경로만 읽기-쓰기가 허용되며, 시스템 바이너리와 라이브러리 경로는 읽기 전용으로 마운트됩니다. 이 정책은 nemoclaw-blueprint/policies/openclaw-sandbox.yaml 파일에 정의되어 있으며, 샌드박스 프로세스는 전용 sandbox 사용자와 그룹으로 실행됩니다.
경로 접근 권한 용도
| 경로 | 접근권한 | 용도 |
| /sandbox | 읽기-쓰기 | 에이전트의 작업 디렉토리 |
| /tmp | 읽기-쓰기 | 임시 파일 저장 |
| /dev/null | 읽기-쓰기 | 표준 출력 리디렉션 |
| /usr | 읽기 전용 | 시스템 바이너리 |
| /lib | 읽기 전용 | 공유 라이브러리 |
| /proc | 읽기 전용 | 프로세스 정보 |
| /dev/urandom | 읽기 전용 | 난수 생성 |
| /app | 읽기 전용 | 애플리케이션 코드 |
| /etc | 읽기 전용 | 시스템 설정 파일 |
| /var/log | 읽기 전용 | 로그 파일 |
이 구조에서 에이전트가 악의적인 명령을 실행하더라도 피해 범위가 /sandbox와 /tmp으로 한정됩니다. 호스트 시스템의 사용자 파일, 설정 파일, 시스템 바이너리 등은 변조될 수 없습니다.
6. 네트워크 정책 설정과 커스터마이징
기본 네트워크 정책의 이해
NemoClaw는 "기본 차단, 명시적 허용(deny-by-default, explicit-allow)" 원칙으로 네트워크를 제어합니다. 샌드박스 내부의 에이전트는 정책에 명시적으로 등록된 엔드포인트에만 접근할 수 있으며, 등록되지 않은 모든 목적지는 OpenShell에 의해 차단됩니다. 이는 기존 OpenClaw에서 에이전트가 어떤 서버와도 자유롭게 통신할 수 있었던 것과 근본적으로 다른 접근 방식입니다.
기본 정책에 포함된 허용 엔드포인트는 다음과 같습니다. 각 정책은 엔드포인트, 허용된 바이너리, 그리고 허용된 HTTP 메서드를 함께 정의하여 세밀한 접근 제어를 구현합니다.
정책 이름 엔드포인트 허용 바이너리 허용 메서드
| 정책이름 | 엔드포인트 | 허용 바이너리 | 허용 메서드 |
| claude_code | api.anthropic.com:443, statsig.anthropic.com:443, sentry.io:443 | /usr/local/bin/claude | 전체 |
| nvidia | integrate.api.nvidia.com:443, inference-api.nvidia.com:443 | claude, openclaw | 전체 |
| github | github.com:443 | /usr/bin/gh, /usr/bin/git | 전체 |
| github_rest_api | api.github.com:443 | /usr/bin/gh | GET, POST, PATCH, PUT, DELETE |
| clawhub | clawhub.com:443 | openclaw | GET, POST |
| openclaw_api | openclaw.ai:443 | openclaw | GET, POST |
| openclaw_docs | docs.openclaw.ai:443 | openclaw | GET 전용 |
| npm_registry | registry.npmjs.org:443 | openclaw, npm | GET 전용 |
| telegram | api.telegram.org:443 | 모든 바이너리 | GET, POST (/bot*/** 경로) |
위 표에서 주목할 점은 모든 엔드포인트가 포트 443(TLS)만을 사용한다는 것입니다. 평문 HTTP 통신은 기본적으로 허용되지 않으며, 이는 전송 중 데이터 노출을 방지하기 위한 설계입니다. 또한 npm_registry와 openclaw_docs 정책은 GET 메서드만 허용하여 읽기 전용 접근을 강제합니다.
운영자 승인 플로우
에이전트가 정책에 등록되지 않은 엔드포인트에 접근을 시도하면, OpenShell이 요청을 차단하고 운영자에게 승인을 요청합니다. 이 과정은 TUI(Text User Interface)를 통해 실시간으로 이루어지며, 운영자가 승인한 엔드포인트는 현재 세션에 한해 임시로 추가됩니다. 이 메커니즘은 에이전트의 유연성을 유지하면서도 예상치 못한 네트워크 접근을 통제할 수 있게 해줍니다.
# 호스트에서 OpenShell TUI를 실행하여 모니터링
openshell term
TUI 화면에서는 차단된 요청의 호스트, 포트, 요청한 바이너리 정보가 표시되며, 운영자는 이를 확인하고 승인 또는 거부를 결정합니다. 예를 들어 에이전트가 새로운 npm 패키지를 설치하기 위해 unpkg.com:443에 접근하려고 하면, TUI에 해당 요청이 표시되고 운영자가 허용 여부를 결정할 수 있습니다.
sequenceDiagram
participant Agent as 에이전트 (샌드박스)
participant OS as OpenShell Gateway
participant TUI as 운영자 TUI
Agent->>OS: requests.get("https://unknown-api.com/data")
OS-->>OS: 정책 확인 -> 미등록 엔드포인트
OS->>TUI: [차단] unknown-api.com:443 (curl)
TUI->>OS: 운영자 승인
OS->>Agent: 연결 허용 (현재 세션 한정)정책 커스터마이징
기본 정책 외에 추가적인 엔드포인트를 허용해야 하는 경우, 두 가지 방법으로 정책을 수정할 수 있습니다. 첫 번째는 정적 변경(Static Changes)으로, YAML 정책 파일을 직접 편집한 뒤 온보드 마법사를 다시 실행하는 방식입니다. 두 번째는 동적 변경(Dynamic Changes)으로, 실행 중인 샌드박스에 재시작 없이 정책을 적용하는 방식입니다.
# 방법 1: 정적 변경 - YAML 파일 편집 후 재온보드
vi nemoclaw-blueprint/policies/openclaw-sandbox.yaml
nemoclaw onboard
# 방법 2: 동적 변경 - 실행 중 정책 업데이트 (재시작 불필요)
openshell policy set <policy-file>
# 방법 3: 프리셋 추가 - 미리 정의된 정책 프리셋 적용
nemoclaw my-assistant policy-add
# 현재 적용된 정책 확인
nemoclaw my-assistant policy-list
정책 프리셋 기능을 사용하면 자주 사용하는 서비스 그룹(예: AWS, Google Cloud, Slack 등)에 대한 엔드포인트를 한 번에 추가할 수 있습니다. policy-add 명령은 대화형으로 사용 가능한 프리셋 목록을 표시하고, 선택한 프리셋의 엔드포인트를 기존 정책에 병합합니다.
7. 추론 모델 프로필 설정
세 가지 추론 프로필
NemoClaw는 blueprint.yaml에 정의된 세 가지 추론 프로필을 제공합니다. 각 프로필은 서로 다른 OpenShell 추론 프로바이더와 모델 경로를 설정하며, 운영 환경과 요구사항에 따라 선택할 수 있습니다. 프로필 간 전환은 런타임에 즉시 가능하며, 샌드박스를 재시작할 필요가 없습니다.
| 프로필 | 프로바이더 | 모델 | 엔드포인트 | 사용 살계 |
| default | NVIDIA Cloud | nvidia/nemotron-3-super-120b-a12b | integrate.api.nvidia.com | 프로덕션. NVIDIA API 키 필요 |
| nim-local | 로컬 NIM 서비스 | nvidia/nemotron-3-super-120b-a12b | nim-service.local:8000 | 온프레미스. NIM 컨테이너 로컬 배포 |
| vllm | vLLM | nvidia/nemotron-3-nano-30b-a3b | host.openshell.internal:8000 | 로컬 개발. 호스트에서 vLLM 실행 |
사용 가능한 Nemotron 모델
NVIDIA NIM 프로바이더를 통해 사용할 수 있는 Nemotron 모델 목록입니다. 모든 모델은 build.nvidia.com에서 제공되며, 로컬 NIM 또는 vLLM을 통해서도 동일한 모델을 실행할 수 있습니다. 모델 선택 시 컨텍스트 윈도우 크기와 최대 출력 토큰 수를 고려하여 작업 유형에 적합한 모델을 선택하는 것이 좋습니다.
| 모델 ID | 라벨 | 컨텍스트 | 최대출력 | 특징 |
| nvidia/nemotron-3-super-120b-a12b | Nemotron 3 Super 120B | 131,072 | 8,192 | 기본 프로필 모델, 최대 출력 토큰 |
| nvidia/llama-3.1-nemotron-ultra-253b-v1 | Nemotron Ultra 253B | 131,072 | 4,096 | 최대 규모, 복잡한 추론 |
| nvidia/llama-3.3-nemotron-super-49b-v1.5 | Nemotron Super 49B v1.5 | 131,072 | 4,096 | 중간 규모, 균형잡힌 성능 |
| nvidia/nemotron-3-nano-30b-a3b | Nemotron 3 Nano 30B | 131,072 | 4,096 | vLLM 프로필 기본 모델, 로컬 실행에 적합 |
프로필 전환 방법
추론 프로필은 두 가지 시점에서 전환할 수 있습니다. 첫 번째는 샌드박스 시작 시 --profile 옵션으로 지정하는 방법이고, 두 번째는 실행 중인 샌드박스에서 OpenShell CLI로 즉시 전환하는 방법입니다. 두 번째 방법을 사용하면 샌드박스를 재시작하지 않고도 추론 대상을 변경할 수 있어, 프라이버시가 필요한 작업에서는 로컬 모델을, 높은 성능이 필요한 작업에서는 클라우드 모델을 상황에 따라 전환할 수 있습니다.
# 방법 1: 시작 시 프로필 지정
openclaw nemoclaw launch --profile vllm
# 방법 2: 실행 중 프로바이더 전환 (재시작 불필요)
openshell inference set --provider nvidia-nim --model nvidia/nemotron-3-super-120b-a12b
# vLLM 로컬 모델로 전환
openshell inference set --provider vllm-local --model nvidia/nemotron-3-nano-30b-a3b
# NIM 로컬 서비스로 전환
openshell inference set --provider nim-local --model nvidia/nemotron-3-super-120b-a12b[i] 참고: NVIDIA Cloud(default) 프로필을 사용하려면 NVIDIA_API_KEY 환경 변수가 필요합니다. build.nvidia.com에서 무료 계정을 생성하고 API 키를 발급받을 수 있습니다. nemoclaw onboard 실행 시 이 키를 입력하면 ~/.nemoclaw/credentials.json에 저장됩니다.
8. Telegram 브릿지와 원격 배포
Telegram 브릿지 설정
NemoClaw는 OpenClaw의 Telegram 연동 기능을 그대로 활용할 수 있으며, nemoclaw start 명령으로 Telegram 브릿지를 포함한 보조 서비스를 일괄 시작할 수 있습니다. Telegram 브릿지를 사용하면 스마트폰에서 Telegram 앱을 통해 NemoClaw 에이전트와 대화할 수 있어, 24시간 상시 운영 환경에서 편리하게 에이전트에 접근할 수 있습니다.
# Telegram 봇 토큰 환경 변수 설정
export TELEGRAM_BOT_TOKEN="your-bot-token-here"
# 보조 서비스 시작 (Telegram 브릿지 포함)
nemoclaw start
# 서비스 상태 확인
nemoclaw status
# 보조 서비스 중지
nemoclaw stop
Telegram 봇 토큰은 BotFather(@BotFather)를 통해 생성할 수 있으며, 기존 OpenClaw에서 사용하던 봇 토큰을 그대로 사용할 수 있습니다. Telegram 브릿지는 네트워크 정책에서 api.telegram.org:443이 기본적으로 허용되어 있으므로 추가 정책 설정이 필요 없습니다.
원격 GPU 인스턴스 배포
NemoClaw는 Brev 플랫폼을 통한 원격 GPU 인스턴스 배포를 실험적으로 지원합니다. nemoclaw deploy 명령은 원격 VM에 Docker, NVIDIA Container Toolkit(GPU 존재 시), OpenShell을 자동으로 설치하고, NemoClaw 설정을 완료한 뒤 샌드박스에 연결합니다.
# Brev를 통한 원격 배포 (실험적 기능)
nemoclaw deploy my-remote-assistant
[!] 주의: nemoclaw deploy 명령은 실험적 기능(experimental)으로, 예상대로 동작하지 않을 수 있습니다. 프로덕션 환경에서는 수동으로 Linux 서버를 설정하고 nemoclaw onboard를 직접 실행하는 방식이 더 안정적입니다.
9. 모니터링과 운영
상태 확인 명령어
NemoClaw는 샌드박스, 추론 설정, 네트워크 정책의 상태를 확인할 수 있는 여러 명령어를 제공합니다. 일상적인 운영에서 가장 자주 사용하게 되는 명령어들을 정리하면 다음과 같습니다.
| 명령어 | 설명 | 사용위치 |
| nemoclaw list | 등록된 모든 샌드박스 목록 조회 | 호스트 |
| nemoclaw my-assistant status | 특정 샌드박스의 상태, 추론 설정 확인 | 호스트 |
| nemoclaw my-assistant logs --follow | 실시간 로그 스트리밍 | 호스트 |
| nemoclaw status | 샌드박스 목록 + 보조 서비스 상태 | 호스트 |
| openclaw nemoclaw status | 플러그인 수준 상태 (Blueprint, 추론) | 샌드박스 내부 |
| openclaw nemoclaw status --json | JSON 형식 출력 (자동화용) | 샌드박스 내부 |
| openshell term | OpenShell TUI (네트워크 승인/거부) | 호스트 |
| /nemoclaw status | 슬래시 명령 (OpenClaw 채팅 내부) | 샌드박스 내부 |
[i] 참고: openclaw nemoclaw status 명령은 샌드박스 내부에서 실행해야 합니다. 샌드박스 내부에서는 openshell sandbox status 같은 호스트 수준 명령을 사용할 수 없으며, status 명령이 이를 자동으로 감지하여 샌드박스 컨텍스트 기준의 정보를 보고합니다.
로그 관리
NemoClaw의 로그는 Blueprint 실행 로그와 샌드박스 로그를 통합하여 보여줍니다. --follow 옵션을 사용하면 tail -f처럼 실시간으로 로그를 모니터링할 수 있으며, --run-id 옵션으로 특정 Blueprint 실행의 로그만 필터링할 수도 있습니다.
# 최근 50줄 로그 확인 (기본값)
nemoclaw my-assistant logs
# 최근 200줄 로그 확인
nemoclaw my-assistant logs -n 200
# 실시간 로그 스트리밍
nemoclaw my-assistant logs --follow
# 특정 Blueprint 실행의 로그만 확인
openclaw nemoclaw logs --run-id abc123샌드박스 관리
샌드박스의 생명주기를 관리하는 명령어도 중요합니다. 문제가 발생하여 샌드박스를 완전히 삭제하고 재생성해야 하는 경우나, 더 이상 사용하지 않는 샌드박스를 정리해야 하는 경우에 사용합니다.
# 샌드박스 삭제 (NIM 컨테이너 중지 + 샌드박스 레지스트리에서 제거)
nemoclaw my-assistant destroy
# 삭제 후 새로운 샌드박스 생성
nemoclaw onboard[!] 주의: destroy 명령은 NIM 컨테이너를 중지하고 샌드박스를 레지스트리에서 완전히 제거합니다. 이 작업은 되돌릴 수 없으므로, 중요한 데이터가 /sandbox 디렉토리에 있다면 사전에 백업해야 합니다.
10. OpenClaw vs NemoClaw 비교
어떤 경우에 NemoClaw를 선택해야 하는가
OpenClaw 단독으로도 강력한 AI 에이전트를 운영할 수 있지만, 다음과 같은 상황에서는 NemoClaw를 선택하는 것이 바람직합니다.
- 첫째, 에이전트가 민감한 데이터(업무 문서, 개인 정보, API 키 등)를 다루는 환경에서는 인프라 수준의 격리가 필수적입니다.
- 둘째, 24시간 상시 운영 환경에서 에이전트가 자율적으로 동작할 때, 예상치 못한 네트워크 접근이나 파일 시스템 변조를 차단할 수 있어야 합니다.
- 셋째, 데이터가 외부로 유출되지 않아야 하는 규제 환경에서는 로컬 추론(Nemotron 모델)을 사용하여 모든 데이터를 온프레미스에서 처리할 수 있습니다.
반면, 다음과 같은 경우에는 OpenClaw 단독 사용이 더 적합할 수 있습니다.
macOS 환경에서 직접 실행해야 하는 경우(NemoClaw는 Linux만 지원), 빠른 프로토타이핑이나 실험적 사용, 또는 Docker/Linux에 익숙하지 않은 사용자의 경우에는 OpenClaw의 간편한 설치와 운영이 장점이 됩니다.
| 비교항목 | OpenClaw 단독 권장 | NemoClaw 권장 |
| 운영 플랫폼 | macOS, Windows, Linux | Linux (Ubuntu 22.04+) |
| 보안 요구 수준 | 개인 실험, 비민감 작업 | 민감 데이터 처리, 상시 운영 |
| 추론 프라이버시 | 클라우드 API 사용 허용 | 로컬 추론 필수 또는 선택적 사용 |
| 네트워크 통제 | 자유로운 네트워크 접근 허용 | 화이트리스트 기반 엄격한 통제 필요 |
| 운영 복잡도 | 간단 (npm install) | 중간 (Docker + Linux + OpenShell) |
| 사용자 수준 | 초보자 ~ 중급자 | 중급자 ~ 고급자 (Linux/Docker 경험 필요) |
11. 트러블슈팅 가이드
설치 관련 문제
NemoClaw 설치 과정에서 가장 흔하게 발생하는 문제와 해결 방법을 정리합니다. 대부분의 문제는 사전 요구사항 미충족이나 Docker 설정 관련 이슈입니다.
OOM(Out of Memory) 킬러 발동으로 설치 실패
설치 과정에서 시스템이 멈추거나 프로세스가 강제 종료되는 경우, 메모리 부족이 원인일 수 있습니다. 시스템 로그(dmesg | grep -i oom)를 확인하고, RAM이 8GB 미만이라면 스왑 공간을 추가합니다.
# 8GB 스왑 파일 생성
sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# 영구 적용 (/etc/fstab에 추가)
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
cgroup v2 관련 오류
nemoclaw onboard 실행 시 Docker의 cgroup 설정 관련 오류가 발생하면, /etc/docker/daemon.json에 "default-cgroupns-mode": "host" 설정을 추가하고 Docker를 재시작합니다. DGX Spark 환경이라면 sudo nemoclaw setup-spark 명령으로 자동 설정할 수 있습니다.
Docker 권한 오류
현재 사용자가 docker 그룹에 속하지 않은 경우 권한 오류가 발생합니다. sudo usermod -aG docker $USER 실행 후 로그아웃/로그인하여 그룹 변경을 적용합니다.
네트워크 관련 문제
에이전트가 필요한 서비스에 접근하지 못하는 경우
기본 네트워크 정책이 너무 엄격하여 에이전트의 작업에 필요한 서비스가 차단되는 경우가 있습니다. 먼저 openshell term으로 TUI를 열어 차단된 요청 목록을 확인하고, 필요한 엔드포인트를 정책에 추가합니다. 임시로 승인하려면 TUI에서 직접 승인하고, 영구적으로 추가하려면 정책 파일을 수정합니다.
추론 요청이 타임아웃되는 경우
NVIDIA Cloud API를 사용할 때 응답이 느리거나 타임아웃이 발생하면, API 키가 유효한지 확인하고 네트워크 연결 상태를 점검합니다. 로컬 NIM이나 vLLM으로 전환하면 네트워크 지연 문제를 해결할 수 있습니다.
CLI 명령어 빠른 참조
일상적인 운영에서 자주 사용하는 CLI 명령어를 한눈에 볼 수 있도록 정리합니다.
| 작업 | 명령어 |
| 설치/재설정 | nemoclaw onboard |
| 샌드박스 접속 | nemoclaw my-assistant connect |
| 채팅 시작 (TUI) | openclaw tui (샌드박스 내부) |
| 단일 메시지 전송 | openclaw agent --agent main --local -m "메시지" --session-id test |
| 상태 확인 | nemoclaw my-assistant status |
| 로그 확인 | nemoclaw my-assistant logs --follow |
| 네트워크 모니터링 | openshell term |
| 추론 모델 전환 | openshell inference set --provider <name> --model <model> |
| 정책 프리셋 추가 | nemoclaw my-assistant policy-add |
| 정책 목록 확인 | nemoclaw my-assistant policy-list |
| 동적 정책 적용 | openshell policy set <policy-file> |
| Telegram 시작 | nemoclaw start |
| 서비스 중지 | nemoclaw stop |
| 샌드박스 삭제 | nemoclaw my-assistant destroy |
| 샌드박스 목록 | nemoclaw list |
| DGX Spark 설정 | sudo nemoclaw setup-spark |
| 원격 배포 | nemoclaw deploy <instance-name> (실험적) |
12. 마무리
NemoClaw는 AI 에이전트 보안의 패러다임을 "에이전트에게 안전하게 행동하라고 요청하는 것"에서 "에이전트가 안전한 환경에서만 활동할 수 있게 강제하는 것"으로 전환시킨 프로젝트입니다. Landlock, seccomp, 네트워크 네임스페이스를 활용한 커널 수준의 격리, 화이트리스트 기반의 네트워크 정책, 운영자 승인 플로우, 그리고 NVIDIA Nemotron 모델을 통한 로컬 추론 지원까지 --- AI 에이전트를 안전하게 운영하기 위한 인프라 계층의 모범 사례를 보여줍니다.
다만 NemoClaw는 2026년 3월 현재 Early Preview(알파) 상태이며, Linux만 지원하고 API/CLI가 변경될 수 있다는 점을 유의해야 합니다. 프로덕션 환경에서의 사용은 아직 권장되지 않지만, AI 에이전트 보안의 방향성을 이해하고 미래를 준비하는 차원에서 충분히 탐구해 볼 가치가 있습니다. 특히 기존에 OpenClaw를 활용하고 있는 사용자라면, NemoClaw가 제공하는 보안 계층이 어떻게 기존 워크플로우에 통합되는지 직접 경험해 보는 것을 권장합니다.
참고 자료
- NVIDIA NemoClaw 공식 문서: https://docs.nvidia.com/nemoclaw/latest/
- NVIDIA NemoClaw 공식 페이지: https://www.nvidia.com/en-us/ai/nemoclaw/
- NVIDIA OpenShell GitHub: https://github.com/NVIDIA/OpenShell
- NVIDIA NemoClaw GitHub: https://github.com/NVIDIA/NemoClaw
- NVIDIA Build (API 키 발급): https://build.nvidia.com
- OpenClaw 공식 사이트: https://openclaw.ai/
- OpenClaw 공식 문서: https://docs.openclaw.ai/
'AI 활용' 카테고리의 다른 글
| NemoClaw를 라즈베리파이 5에 설치하고 운영하기 (0) | 2026.03.24 |
|---|---|
| 중소기업 AI 도입 심화 분석 - 핵심 성공사례와 업종별 전략 (0) | 2026.03.09 |
| 중소기업을 위한 제조업 AI 도입 사례 - 작은 투자로 큰 변화를 만드는 법 (0) | 2026.03.09 |
| 글로벌 제조업 AI 활용 사례 - 세계를 선도하는 혁신 기업들 (0) | 2026.03.09 |
| 국내 제조업 AI 활용 사례 - 생산성 혁신의 선도주자들 (2) | 2026.03.09 |
