AI에게 ‘하지 마세요’라고 쓰는 것과 실제로 막는 것은 어떻게 다를까요?

핵심 요약 (TL;DR)

9월 28일 NVIDIA는 Open Agent Safety Platform을 발표했습니다. 핵심은 모델에 주의를 주는 문장을 더 넣는 것이 아니라, 에이전트가 실행되는 환경 바깥에서 행동 범위를 통제하겠다는 접근입니다. 공식 발표는 실행 경계를 제공하는 OpenShell 소프트웨어와, 별도 하드웨어에서 감시하는 Sentry 참조 설계를 구분합니다. 바이브코딩으로 자동화를 만드는 사람에게도 이 구분은 유용합니다. 실수해도 특정 행동은 할 수 없게 만들어야 하기 때문입니다.

프롬프트에 금지 사항을 적으면 충분하지 않을까요?

‘고객에게 메시지를 보내지 마세요’라는 문장은 작업 의도를 알려 줍니다. 하지만 같은 에이전트에 실제 발송 도구와 권한까지 연결돼 있다면, 문장 자체가 그 권한을 제거하지는 않습니다. 프롬프트는 무엇을 해야 하는지 전달하고, 실행 환경은 무엇을 할 수 있는지 결정합니다.

NVIDIA는 모델과 에이전트 실행 틀의 바깥에 강제 가능한 경계가 필요하다고 설명합니다. OpenShell은 샌드박스 실행과 정책 통제를 통해 에이전트의 접근을 관리하는 소프트웨어로 소개됐습니다. 이 발표를 모든 공격을 막는 보증으로 읽을 필요는 없습니다. 다만 사람이 쓴 규칙과 시스템이 실제로 차단하는 규칙을 구별하라는 문제의식은 분명합니다.

OpenShell과 Sentry는 같은 프로그램인가요?

아닙니다. 공식 발표에서 OpenShell은 CPU에서 에이전트가 작업할 때 실행 경계를 제공하는 오픈소스 소프트웨어입니다. Sentry는 BlueField-4 DPU에서 에이전트 활동을 별도로 감시하고 보안 정책을 집행하는 참조 시스템 설계입니다. 소프트웨어 층과 하드웨어 층이 맡는 역할이 다릅니다.

따라서 개인 노트북에 소프트웨어를 설치하는 것과, 기업용 참조 설계의 보호 수준을 갖추는 것은 같은 일이 아닙니다. 도입을 검토한다면 이름보다 지원 환경, 연결할 데이터, 별도 장비가 필요한 기능을 먼저 살펴보세요.

작은 MVP에서는 어떤 경계부터 만들면 좋을까요?

예를 들어 문의 메일 초안을 만드는 앱이라면, 첫 버전에는 실제 발송 기능을 연결하지 않는 방법이 있습니다. 샘플 문의를 읽어 초안을 저장하는 흐름만 완성하면 됩니다. 이후 발송 기능을 추가할 때도 검토 화면과 승인 절차를 별도로 두세요. 이는 NVIDIA 제품을 설치한 결과가 아니라, 발표의 원칙을 작은 앱에 적용하는 설계 제안입니다.

파일 접근도 같은 방식으로 생각할 수 있습니다. 프로젝트 전체를 정리하라고 맡기기 전에 테스트용 복사본과 필요한 폴더만 제공하세요. ‘삭제하지 마세요’라는 요청에 더해 삭제 권한 자체를 줄일 수 있는지 확인하는 것입니다. 비밀값과 실제 고객 데이터는 테스트 입력과 분리하세요.

마지막으로 성공한 작업만 시험하지 마세요. 허용하지 않은 폴더나 외부 주소에 접근하려 할 때 정말 멈추는지를 무해한 테스트 대상으로 확인해야 합니다. 안전장치는 켰다는 표시보다, 막아야 할 행동을 실제로 막았다는 관찰이 중요합니다.

FAQ: 개인 개발자도 새 장비를 사야 하나요?

그렇게 결론 내릴 수는 없습니다. 필요한 통제 수준과 지원 환경부터 확인하세요. 지금은 테스트 데이터 분리와 최소 권한만으로도 시작할 수 있으며, Sentry의 하드웨어 설계를 개인의 필수 구매 목록으로 읽을 이유는 없습니다.

FAQ: 이 플랫폼을 쓰면 AI 코드를 검토하지 않아도 되나요?

아닙니다. 실행 권한을 제한해도 기능 오류나 잘못된 요구 해석은 남습니다. 코드 검토, 사용자 흐름 확인, 배포 승인은 별도로 필요합니다. 이 글은 공식 발표 분석이며 설치·침투 시험 결과가 아닙니다.

출처: https://www.nvidia.com/en-us/solutions/ai/agent-safety/
기술 근거: https://developer.nvidia.com/blog/add-runtime-controls-to-ai-agents-with-nvidia-openshell
관찰 시점: 2026-09-30 KST