안전한 기업 AI환경을 위한 엔비디아 OpenShell과 AX Foundry는 무엇이 다를까

엔비디아가 9월 28일 Open Agent Safety Platform을 공개하면서 젠슨 황 CEO가 CNBC 인터뷰에서 남긴 말은 짧았습니다. 에이전트가 회사 안을 이리저리 떠돌게 둘 수 없으니 가둘 방법을 찾아야 한다는 것이었는데, 이 한 문장에는 성격이 전혀 다른 두 가지 문제가 붙어 있습니다. 회사에 어떤 에이전트가 몇 개 돌고 있는지 모르는 문제와 그 에이전트의 손이 어디까지 닿는지 정해두지 않은 문제인데, 엔비디아 OpenShell과 AX Foundry가 둘 다 AI 에이전트 보안을 내걸고도 서로 다른 일을 하는 까닭이 여기에 있습니다. 두 제품이 각각 무엇을 하는 물건인지 먼저 보고 한 줄씩 맞대어 보면 어디가 같고 어디가 갈라지는지가 분명해집니다.

젠슨 황이 남긴 숙제는 둘인데 답은 한쪽뿐입니다

떠돈다는 말과 가둬야 한다는 말은 한 문장에 나란히 놓여 있지만 가리키는 곳이 다릅니다. 앞의 떠돈다는 회사 안에 어떤 에이전트가 몇 개 돌고 있고 누가 만들어 무슨 데이터를 만지는지 아무도 모르는 상태를 말하고, 뒤의 가둬야 한다는 이미 알고 있는 에이전트의 손이 어디까지 닿는지를 기술로 좁혀두는 일을 말하죠. 하나는 조직이 자기 모습을 모르는 문제이고 다른 하나는 담장을 세우는 문제여서, 담장을 아무리 두텁게 쌓아 올려도 앞쪽 문제는 그 자리에 그대로 남습니다.

엔비디아의 답은 뒤쪽을 향해 있습니다. 황이 새 플랫폼을 에이전트용 브라우저라고 부르며 에이전트가 일하는 데 필요한 것에만 손이 닿게 하는 격리 장치라고 설명한 것도, 엔비디아 기업 AI 부문 부사장 저스틴 보이타노가 최근 사고들이 모델 수준의 안전장치만으로는 에이전트가 무엇을 만지고 무엇을 하는지 다스릴 수 없다는 한계를 드러냈다고 말한 것도 담장을 어떻게 세울지에 관한 얘기입니다. 발표 배경에도 OpenAI와 앤트로픽, 메타, 구글의 모델이 격리 환경을 벗어나 다른 회사 시스템을 해킹하려 한 사고들이 깔려 있는데, 엔비디아 측은 자사 플랫폼이 7월 OpenAI의 Hugging Face 침해 사고를 막을 수 있었을 것이라고 밝혔고 보이타노는 Hugging Face가 보고한 바로는 1만 7,000개가 넘는 에이전트가 수일에서 수주에 걸쳐 인프라를 공격했다고 전했습니다.

황이 발표 닷새 전인 9월 23일 뉴욕타임스 에즈라 클라인의 팟캐스트에서 한 말을 보면 남은 숙제가 더 또렷해집니다. 사고가 나면 무엇을 할 수 있었는지 따져보고 절차를 고쳐 재발을 막아야 한다는 것이었는데, 따져볼 기록과 고칠 절차가 조직 안에 이미 갖춰져 있어야 성립하는 얘기죠. 담장은 엔비디아가 깔아주지만 명부와 절차는 각 회사의 몫으로 남는다는 점이, 두 제품을 맞대어 볼 때의 출발점입니다.

엔비디아 OpenShell은 무엇을 하는 제품인가요?

엔비디아 OpenShell(NVIDIA OpenShell, 오픈셸)은 AI 에이전트를 하나씩 따로 격리된 공간에 넣어 돌리는 오픈소스 실행 환경입니다. 에이전트마다 작업실을 따로 내주고 그 방 밖으로는 손이 나가지 못하게 문을 잠가두는 방식인데, 엔비디아 공식 문서는 이를 커널 수준의 격리와 YAML 파일로 적는 정책을 묶은 런타임이라고 소개합니다. 엔비디아 자신은 이 구조를 브라우저 탭에 빗대어 설명하는데, 탭마다 세션이 나뉘고 쓸 수 있는 자원이 정해져 있으며 무슨 일을 하기 전에 권한을 먼저 확인받는 모습을 떠올리면 됩니다.

엔비디아 블로그는 이 런타임이 세 부분으로 돌아간다고 적었습니다. 에이전트마다 하나씩 주어지는 샌드박스가 첫 번째로 에이전트가 안에서 무엇을 망가뜨려도 바깥 컴퓨터에는 닿지 않게 막아주고, 두 번째인 정책 집행 엔진이 파일과 네트워크와 프로세스 층에서 모든 행동을 실행 파일과 목적지와 방식과 경로 수준까지 따져 검증된 기능은 설치하게 하되 검토되지 않은 프로그램은 실행하지 못하게 합니다. 세 번째인 게이트웨이는 에이전트의 행동이 실제 컴퓨터에 닿기 전에 판정이 내려지는 지점이고, 정책을 한곳에서 관리하면서 허용과 차단 판정 하나하나를 기록으로 남깁니다.

무엇을 어떻게 잠그는지는 공식 문서의 위협 목록에 그대로 적혀 있습니다. 사내 파일을 허가되지 않은 곳으로 올려보내는 일은 승인된 주소만 열어둔 네트워크 정책이 끊고, SSH 키나 클라우드 자격증명을 읽어가는 일은 리눅스가 원래 갖고 있는 Landlock이라는 잠금 기능으로 정해둔 경로만 열어줘서 막고, 관리자 권한을 가로채려는 시도는 seccomp라는 제한 장치가 걸러냅니다. 폴더와 주소와 프로세스, 그러니까 컴퓨터 안의 길목을 좁히는 데 초점이 맞춰져 있는 셈입니다.

누가 쓰는 물건인지는 활용 사례에서 드러납니다. 공식 문서가 대표 사례로 꼽은 것은 Claude Code나 OpenCode, Codex, GitHub Copilot CLI처럼 개발자가 쓰는 코딩 에이전트에 파일과 네트워크 권한을 좁혀서 돌리는 경우이고 정책은 YAML 파일로 적으며, 블로그는 우분투와 윈도우, 레드햇 오픈시프트 같은 주요 기업용 운영체제에서 돌아가도록 만들고 있다고 밝혔습니다. 설치하고 정책 파일을 손보고 사고가 났을 때 들여다보는 사람이 모두 개발 조직에 몰려 있다는 뜻이죠.

지금 어떤 상태인지도 함께 봐야 합니다. CNBC 보도에 따르면 이번 플랫폼에서 OpenShell은 CPU 위에서 돌며 에이전트가 할 수 있는 일에 한도를 정하고 함께 발표된 Sentry는 CPU나 GPU가 아닌 네트워크 칩에서 돌며 에이전트를 지켜보는데, 엔비디아는 이 플랫폼을 참조 설계라고 부르면서 일부 소프트웨어만 오픈소스로 풀고 Cisco와 Microsoft, Oracle, CoreWeave, Dell, HPE, Lenovo, ARM, Intel이 그 위에 제품을 얹어 시장에 내놓도록 했습니다. 앤트로픽과는 클라우드 관리형 에이전트를 OpenShell에 통합하는 작업을 진행 중이고 SAP와 ServiceNow의 기업용 플랫폼에도 들어갈 예정이지만, 블로그는 OpenShell의 상태를 초기 프리뷰라고 적었고 공식 문서의 버전도 0.1대에 머물러 있습니다. 도입을 검토하는 기업이 지금 손에 쥐는 것은 완성된 관제 제품이라기보다 누군가 제품으로 만들어 주기를 기다려야 하는 바닥입니다.

AX Foundry는 무엇을 하는 제품인가요?

AX Foundry는 사내에서 만들어지고 쓰이는 AI 에이전트를 한곳에 모아 등록하고, 에이전트마다 책임자를 붙이고, 위험한 실행을 결재에 거는 관제 플랫폼입니다. 직원에게 사원증을 발급해 명부에 올리고 금액이 큰 지출은 결재를 받게 하는 체계를 에이전트에 적용한 것이라고 보면 이해가 빠릅니다. 통제의 기준이 컴퓨터 안의 길목이 아니라 회사의 조직도와 업무 규칙 쪽에 서 있다는 점이 OpenShell과 갈리는 출발점입니다.

AX Foundry의 하는 일은 네 단계로 볼 수 있습니다. 새 에이전트가 생기는 즉시 중앙 카탈로그에 자동으로 올리고 관리자 승인 없이 도는 미등록 에이전트는 따로 잡아내 담당자에게 알리는 것이 첫 단계이고, 모든 에이전트에 담당 부서와 책임자를 매핑해 누구 것인지 분명히 하는 것이 두 번째입니다. 부서와 자료 등급을 기준으로 삼아 범위를 벗어난 실행을 미리 멈춰 세우는 것이 세 번째이고, 송금이나 발주처럼 한도를 넘는 중요한 실행은 책임자 결재를 거치게 하는 것이 네 번째입니다.

기록과 비용도 같은 콘솔에서 다룹니다. 요청부터 정책 판정, 도구 호출, 근거 문서, 최종 답변까지를 단계별로 전수 기록해두기 때문에 사고가 났을 때 원본 로그를 헤집는 대신 시각화된 이력을 따라가면 되고, 모델과 부서별로 쓴 비용에 절감된 업무 시간까지 함께 집계되니 어느 에이전트에 예산을 더 붙일지도 같은 화면에서 판단하게 됩니다. 소개 페이지의 예시 화면에는 1억 원 송금과 1,200만 원짜리 발주서 생성이 재무팀장의 결재 대기 목록에 올라와 있고, 원장 행 삭제와 급여 조회는 실행 전에 차단된 상태로 찍혀 있습니다.

설치 환경은 국내 사정에 맞춰져 있습니다. Dify나 n8n, LangChain으로 만든 에이전트든 사내에서 직접 짠 에이전트든 등록되는 순간 하나의 기준으로 묶이고, 인터넷이 끊긴 온프레미스 폐쇄망에 완전한 패키지 형태로 설치할 수 있으며 특정 LLM에 묶이지 않아 사내 sLLM부터 국내 상용 모델까지 바꿔 쓸 수 있습니다. 클라우드 종속성이 강한 해외 플랫폼을 그대로 들이기 어려운 금융권과 공공기관이 온프레미스 거버넌스 대안을 찾을 때 이 조건이 먼저 걸립니다.

두 제품은 어디까지 같고 어떤게 다른가요?

같은 것은 세 가지입니다. 첫째로 둘 다 AI를 안전하게 쓰는 문제를 모델을 잘 가르치는 일로 풀지 않고 모델 바깥에 판정하는 층을 따로 세우며, 둘째로 탐지에서 멈추지 않고 실행 전에 판정해 OpenShell은 에이전트의 모든 바깥 연결을 정책 엔진이 가로채고 AX Foundry는 에이전트의 호출을 회사 정책과 대조해 서버에 닿기 전에 멈춥니다. 셋째로 그 판정을 기록으로 남기는데, 엔비디아 블로그가 허용과 차단 판정 하나하나에 감사 추적을 남긴다고 적은 것과 AX Foundry가 호출 기록을 변경 불가 처리해 보관한다고 적은 것이 같은 생각에서 나왔고, 특정 모델이나 특정 개발 도구에 묶이지 않는다는 점까지 겹칩니다.

다른 점 첫번째는 통제하는 대상입니다. OpenShell이 통제할 수 있는 것은 누군가 OpenShell 안에 넣어서 돌린 에이전트뿐이어서 그 바깥에서 도는 에이전트는 애초에 사정권에 들어오지 않는데, AX Foundry는 사내에 흩어진 에이전트를 찾아내 명부에 올리는 일에서 시작하기 때문에 관리자가 모르는 채 돌아가던 에이전트가 콘솔에 빨간 표시로 잡히는 것이 첫 성과가 됩니다. 정책을 적는 말도 다른데, OpenShell의 규칙은 파일 경로와 외부 주소와 프로세스 이름으로 적히고 AX Foundry의 규칙은 부서와 자료 등급, 금액 한도와 열람 범위로 적혀서 파일 경로로 적힌 규칙을 재무팀장이 읽고 고칠 수는 없지만 발주 한도로 적힌 규칙은 읽고 고칠 수 있습니다.

멈춘 다음도 다릅니다. OpenShell에서 정책에 걸린 실행은 차단되고 그 판정이 기록에 남는 반면, AX Foundry에서는 한도를 넘는 실행이 책임자의 승인 대기 목록으로 올라가 재무팀장이 사유를 보고 승인하면 실행되고 반려하면 막히죠. 사람이 판단에 끼어들 자리가 흐름 안에 들어 있다는 점이 결재 체계를 가진 조직에 맞고, 그래서 콘솔을 들여다보는 사람도 개발자에서 부서 책임자로 바뀝니다.

손에 쥐는 물건의 완성도도 다릅니다. 엔비디아가 내놓은 것은 파트너들이 제품으로 만들어 팔도록 열어둔 참조 설계이고 OpenShell 자체는 초기 프리뷰인데, 파트너 중 하나인 TrendAI도 연동을 설명한 글에서 OpenShell을 완성된 보안 솔루션이라기보다 파트너가 기업용으로 확장하도록 열어둔 기반이라고 적으면서 거버넌스와 위험 가시성을 자사가 얹는다고 밝혔습니다. AX Foundry는 현황 진단 2주짜리 Discovery Pack부터 부서 검증과 전사 확산까지 단계가 짜인 완성 패키지로 공급되니, 검토 단계에서 받아보는 것이 설계도인지 제품인지가 갈립니다.

명단이 없으면 담장은 어디에 세우나요?

담장은 세울 대상이 명부에 올라와 있어야 제힘을 씁니다. 현업 부서가 Dify나 n8n으로 월말 정산 보조나 계약서 검토 에이전트를 하나둘 만들어 쓰기 시작한 회사라면 그 에이전트들은 개발팀을 거치지 않고 업무 도구 안에서 바로 돌아가고, 그렇게 늘어난 에이전트는 몇 개가 어디서 무슨 데이터를 만지는지 누구도 한눈에 보지 못하는 상태로 쌓여갑니다. 사내에 흩어진 에이전트를 찾아 명단으로 만드는 일은 OpenShell이 다루는 범위에 들어 있지 않아서, 담장을 아무리 두텁게 세워도 명부에 없는 에이전트는 그 담장 밖에 남습니다.

사고를 겪은 기업들이 비워두고 있던 자리도 이쪽이었습니다. IBM이 올해 내놓은 Cost of a Data Breach Report 2025을 분석한 로펌 존스워커의 정리에 따르면 AI 관련 보안 사고를 겪은 기업의 97%가 제대로 된 AI 권한 통제를 갖추지 못한 상태였고, 침해를 당한 기업의 63%는 AI를 관리하거나 무단 사용을 탐지할 거버넌스 정책 자체가 없었습니다. 격리 기술이 얕아서 생긴 사고보다 누가 무엇을 쓰는지 관리하는 체계가 비어서 생긴 사고가 그만큼 많았다는 뜻이죠.

비용 계산도 이 순서를 따라갑니다. 에이전트 명단과 책임자 지정, 금액 한도에 따른 결재, 부서별 비용 집계처럼 전사 운영에 필요한 기능은 엔비디아가 처음부터 파트너 몫으로 열어둔 영역이어서 OpenShell만 들인 회사는 그 부분을 직접 만들거나 다른 제품으로 채워야 하고, 개발 인력을 붙여 직접 만들기로 하면 그 순간부터 그것은 사내 개발 과제로 바뀝니다. 라이선스 비용이 없다는 것과 운영 체계를 갖추는 데 돈이 들지 않는다는 것은 별개의 문제입니다.

C레벨이 답해야 하는 질문은 한쪽에만 있습니다

AI가 일으킨 사고의 책임은 이미 회사로 향하고 있습니다. 2024년 2월 캐나다 브리티시컬럼비아주 민사해결심판소는 항공권 안내를 잘못한 챗봇을 두고 에어캐나다에 손해배상 책임이 있다고 판단했는데, 챗봇은 별개의 주체이니 회사에 책임을 물을 수 없다는 항공사 주장을 받아들이지 않고 홈페이지에 실린 정보라면 정적인 페이지든 챗봇이 한 말이든 회사가 책임진다고 못 박았습니다. 규제 쪽도 같은 것을 묻는데, 금융위원회의 금융분야 AI 가이드라인이 시행되면서 검증의 초점이 AI를 도입했는지에서 어떻게 운영하고 통제하고 있는지로 옮겨갔습니다.

이 프로세스가 이 경로의 파일을 읽어도 되는지는 정책 파일을 쥔 개발자가 답하면 됩니다. 반면 지금 사내에 에이전트가 몇 개 돌고 있고 1억 원 송금을 누가 승인했으며 그 근거가 어디 남아 있는지는 감사와 규제와 법원이 회사에 직접 묻는 질문이고, 답하는 자리에 앉는 사람은 경영진입니다. 뒤쪽 질문에 답이 바로 나오지 않는 상태라면 격리 기술을 아무리 깊게 깔아도 책임의 자리는 비어 있는 채로 남습니다.

황의 문장을 회사 안으로 옮겨 적으면 우리 에이전트는 어디를 떠돌고 있으며 우리는 그걸 볼 수 있는가가 됩니다. 회사마다 다른 조직도와 결재 라인과 자료 등급을 아는 쪽은 칩을 만드는 회사가 아니라 그 회사 안에 있는 사람들이니, 엔비디아가 실행 환경 쪽 바닥만 깔고 그 위를 파트너들에게 열어둔 것도 그래서일 겁니다. 흩어진 에이전트를 명부에 올리고 책임자를 붙이고 위험한 실행을 결재에 걸어 기록으로 남기는 일에서 AI 거버넌스가 시작되고, 담장을 어디에 세울지는 그 명부가 서고 나서 정해도 늦지 않습니다.