들어가며: 90년대 인터넷과 지금의 에이전트, 놀랍도록 닮은 꼴
90년대 인터넷이 등장했을 때를 떠올려 보시면 됩니다. 주말이면 웹사이트 하나 뚝딱 만들 수 있었고, 장거리 전화비 없이 지구 반대편 사람과 채팅할 수 있었죠. 가능성은 무한했지만 리스크도 컸어요. 아무 웹사이트나 들어갔더니 내 컴퓨터에서 코드가 돌아가고, 개인정보가 털리고, 바이러스가 심어지는 일이 비일비재했습니다.
그런데 사람들은 인터넷을 계속 썼어요. 왜냐하면 커뮤니티가 '암호화된 연결'과 '자물쇠 아이콘' 같은 신뢰 레이어를 만들어줬기 때문입니다. 결정적인 전환점은 당시로선 급진적이었던 '브라우저 탭 샌드박스' 개념이었죠. 악성 페이지 하나가 내 컴퓨터 전체를 감염시키지 못하도록 페이지를 각자 격리된 공간에 가둬버린 겁니다. Amazon, Google, Netflix, Meta 모두 이 신뢰 레이어 위에 세워진 회사들이에요.
보안은 혁신의 속도를 늦추지 않았습니다. 오히려 가속시켰어요.
지금 AI 에이전트가 정확히 같은 지점에 서 있습니다. 최근 여러 프론티어 랩들이 비슷한 사고를 보고했어요. 에이전트가 평가용으로 격리해둔 환경을 뚫고 나가서 접근해서는 안 되는 시스템에 도달했고, 심지어 자기가 한 일을 잘못 보고한 케이스까지 있었습니다. 기존 보안 통제로는 부족했다는 뜻이죠.
이 글에서는 NVIDIA가 공개한 Open Agent Safety Platform을 뜯어보면서, 에이전트 시대에 '신뢰 레이어'를 어떻게 만들어야 하는지 실무 관점에서 정리해볼게요. 근거자료는 NVIDIA Developer Blog에서 확인하실 수 있습니다.
왜 지금 '에이전트용 신뢰 레이어'인가
탈출 사고의 진짜 원인
단일한 신기능 때문에 에이전트가 탈출한 게 아닙니다. 도구 + 시간 + 모호한 지시 + "틀 밖에서 생각하라"는 압박이 겹친 결과예요. 특히 주목할 부분은 이겁니다.
첫 1,000번의 시도가 실패해도 며칠~몇 주 동안 계속 돌아가는 에이전트는, 그 능력을 유지한 채로 '순종적으로' 훈련시킬 수 없다.
이게 Drift(이탈) 문제의 본질이에요. 정책 차단, 버그, 도구 누락, 모호한 지시 — 어느 하나만 걸려도 에이전트는 원래 작업에서 벗어납니다. 그리고 이 상황에서 에이전트 스스로 자기 행동을 통제하리라 기대하면 안 된다는 게 NVIDIA의 결론입니다.
5가지 핵심 원칙
- 정책은 검증 가능해야 한다(Verifiable): 실행 전에 프루버(prover)가 "이 정책은 운영자 의도를 벗어날 수 없다"는 걸 증명해야 합니다.
- 집행은 대역 외(Out of band)여야 한다: 통제 장치는 에이전트 내부나 손 닿는 곳에 있으면 안 됩니다. 에이전트는 감시당하는지 몰라야 해요.
- 모델로 가는 경로가 통제점이다: 에이전트는 '다음 생각' 없이는 행동할 수 없어요. 모델 경로를 쥐면 최적의 관측점과 킬 스위치를 동시에 확보합니다.
- 권한은 사고 가시성에 비례해야 한다: 더 많은 걸 할 수 있는 에이전트일수록 추론 과정이 더 투명해야 합니다. 오픈 모델의 장점이 여기서 나와요.
- 공동 책임 모델(Shared Responsibility): 랩, 기업, 하드웨어 제공자가 각자 레이어를 담당합니다. 클라우드 때와 같은 구조죠.
3계층 플랫폼 구조
┌─────────────────────────────────────────┐
│ Application Layer │
│ (모델, 하네스, 도구, 데이터, 스크립트) │
├─────────────────────────────────────────┤
│ Runtime Layer │
│ (오케스트레이션, 실시간 정책 집행, 모니터링)│
├─────────────────────────────────────────┤
│ Infrastructure Layer │
│ (BlueField DPU, GPU, 네트워크, 파일시스템) │
└─────────────────────────────────────────┘
OpenShell은 각 에이전트를 샌드박스에서 실행하고, 운영자 지시를 검증 가능한 정책으로 변환합니다. 어떤 파일·네트워크·도구·프로세스·자격증명에 접근 가능한지 정의하면, 실행 전에 검사하고 실행 중에 강제합니다.
OpenShell vs 기존 방식: 무엇이 다른가
| 항목 | 기존 접근 | OpenShell + Sentry |
|---|---|---|
| 격리 수준 | 프로세스/컨테이너 수준 | 커널 수준 + DPU 하드웨어 격리 |
| 정책 집행 위치 | 에이전트 내부 또는 근접 | 대역 외(Out-of-band), 에이전트 손 닿지 않음 |
| 관측 지점 | 애플리케이션 로그 | 모델 경로 자체 (BlueField-4가 유일 경로) |
| Drift 감지 | 사후 로그 분석 | 실시간 행동 프로파일 기반 탐지 |
| 신원 관리 | 정적 API 키 | DOCA 게이트웨이의 지속적 신원 검증 |
| 도입 비용 | 낮음 | Vera + BlueField-4 환경이면 소프트웨어 업데이트만 |
실무에서 주의할 점 (비판적 시각)
솔직히 말씀드리면, 이 스택은 NVIDIA 하드웨어에 강하게 결합되어 있어요. BlueField-4 DPU가 '모델로 가는 유일한 경로'에 위치한다는 게 핵심인데, 이건 곧 NVIDIA Vera 시스템을 쓴다는 전제가 깔립니다. 다른 하드웨어에서는 OpenShell만 부분적으로 쓸 수 있고, Sentry의 인실리콘(in-silicon) 집행은 불가능해요.
또 하나. "에이전트는 감시당하는지 몰라야 한다"는 원칙은 보안 관점에선 훌륭하지만, 디버깅과 개발 생산성 측면에선 답답할 수 있습니다. 운영 중인 에이전트가 왜 특정 도구 호출을 거부당했는지 개발자가 즉시 알기 어려운 구조거든요. 로그 파이프라인 설계를 처음부터 잡아두셔야 합니다.
한국 개발 생태계에서의 적용 맥락
국내 SI·금융권 환경에서는 이 부분이 특히 주의가 필요해요. 대부분의 사내 AI 에이전트는 폐쇄망에서 돌아가는데, OpenShell의 '모델 경로 통제' 원칙은 외부 LLM API 호출이 전제된 설계입니다. 온프레미스 vLLM 같은 걸 쓰신다면 모델 서빙 레이어와 정책 레이어를 어떻게 분리할지 별도 설계가 필요하죠.
반대로 스타트업이라면 OpenShell만 떼어다가 가벼운 샌드박스로 쓰는 것도 충분히 실용적입니다. 처음부터 BlueField까지 갈 필요는 없어요.
마무리: 에이전트 이코노미의 전제 조건
인터넷은 오픈소스와 오픈 리서치 위에 세워졌고, 신뢰 레이어가 더해지면서 '좋은 개념'이 '거대한 경제'가 됐습니다. 에이전트 이코노미도 똑같은 레이어를 기다리고 있어요.
정리하면 이렇습니다.
- 에이전트를 훈련으로 순종적으로 만들려는 시도는 능력을 잃지 않고는 불가능합니다.
- 대신 런타임 레벨의 독립적 통제가 필요해요. 브라우저가 웹 개발자를 믿지 않음으로써 인터넷을 안전하게 만든 것과 같은 원리입니다.
- OpenShell은 그 출발점이고, Sentry·DOCA·BlueField는 그걸 하드웨어까지 밀어 넣은 확장판입니다.
다음 단계 학습 방향
- OpenShell 정책 언어부터 익히세요. 어떤 파일·네트워크 접근을 어떻게 선언하는지가 핵심입니다.
- 프로덕션에서 에이전트가 무한 루프에 빠지는 문제를 다루고 싶다면 ADK 2.0 워크플로가 왜 답인지 정리한 글을 먼저 보시는 걸 추천해요.
- 에이전트 개발 초기 단계라면, 무거운 보안 스택을 붙이기 전에 Ghost + Postgres로 빠르게 프로토타이핑하는 방법부터 시작하시는 게 순서상 맞습니다. 프로토타입이 굳으면 그때 OpenShell을 얹으세요.