엔비디아가 9월 28일 AI 에이전트용 안전 플랫폼을 내놓았다는 뉴스를 보고 가장 먼저 든 생각은 “나도 이걸 깔아야 하나”였다. 매일 Claude Code로 옵시디언 볼트와 블로그 자동화를 돌리고 있으니, 최근 사고들에서 에이전트가 애플리케이션 계층의 보안 통제를 우회했다는 엔비디아의 설명이 남 일 같지 않았다.
그래서 설치보다 먼저 내 설정 파일부터 열어봤다. 정확히는 AI 에이전트에게 볼트의 Claude Code 권한 파일을 읽고 규칙 개수를 분류하게 했다. 결과는 허용 규칙 234개(중복 5개 포함), 차단 규칙 0개, 확인 요청 규칙 0개, 샌드박스 설정 없음이었다. 결론부터 말하면, 대부분의 개인과 소규모 팀에게 필요한 건 OpenShell이 아니라 이미 손에 있는 내장 샌드박스를 켜는 일이었다.
30초 판단표: 어디까지 필요한가
| 상황 | 먼저 할 일 | OpenShell | Sentry |
|---|---|---|---|
| 혼자 Claude Code 하나만 쓴다 | 내장 샌드박스 켜기 + 인터프리터 규칙 정리 | 불필요 | 불가능(하드웨어 없음) |
| 에이전트가 실제 repo·클라우드 계정을 만진다 | 내장 샌드박스 + 네트워크 도메인 명시 | 스크래치 repo에서 시험 | 불필요 |
| 팀에서 Claude Code·Codex 등 여러 에이전트를 돌린다 | 공통 정책 문서화 | 도입 검토 가치 큼 | 불필요 |
| 감사 로그가 규정상 필요하다 | 로그 보존 기준 확정 | OCSF 감사 로그 때문에 유력 | 데이터센터 보유 시 검토 |
| Vera·BlueField-4 인프라를 운영한다 | 보안팀과 위협 모델 정리 | 기본 | 검토 대상 |
아래는 이 표가 어떻게 나왔는지에 대한 이야기다.
OpenShell과 Sentry는 정확히 뭘 하나
엔비디아 발표에 따르면 Open Agent Safety Platform은 두 층으로 되어 있다. 하나는 OpenShell이라는 오픈소스 런타임이고, 다른 하나는 Sentry라는 하드웨어 기반 감시자다. Anthropic, Microsoft, JPMorganChase, SpaceXAI 등 100곳이 넘는 조직이 파트너로 이름을 올렸다.
OpenShell은 에이전트를 격리된 샌드박스 안에서 실행하는 런타임이다. README 설명을 보면 커널 수준에서 파일 접근, 시스템콜, 네트워크 연결을 제한하고, 정책을 바꿀 때 위험한 새 권한이 생기는지 먼저 검증한다. 라이선스는 Apache 2.0이고 Linux, 애플실리콘 맥, WSL2(실험적)에서 Docker·Podman 또는 호스트 가상화 위에서 돌아간다. 설치는 스크립트 한 줄과 openshell sandbox create 한 줄이면 된다고 안내한다.
엔비디아 기술 블로그의 예시가 성격을 잘 보여준다. 샌드박스는 기본적으로 바깥 네트워크가 막혀 있고, 허용할 대상은 YAML 정책에 호스트, 포트, 읽기 전용 여부, 그리고 어떤 실행 파일이 그 연결을 쓸 수 있는지까지 적는다. 막힌 요청은 OCSF라는 보안 로그 형식으로 기록되어 운영자나 승인용 에이전트가 나중에 검토할 수 있다.
Sentry는 결이 완전히 다르다. BlueField-4라는 데이터센터용 DPU 위에서 에이전트 소프트웨어와 분리된 채 실제 행동을 지켜보다가, 정책을 벗어나면 밀리초 단위로 격리한다. 호스트가 뚫려도 감시자는 건드릴 수 없게 하려는 설계다. 엔비디아는 기존 Vera와 BlueField-4 설치 환경이라면 소프트웨어 업데이트로 켤 수 있다고 했지만, 일반 가용 일정은 밝히지 않았다.
정리하면 OpenShell은 “무엇을 할 수 있는지 미리 정하는 작업실”이고, Sentry는 “작업실 밖에서 지켜보는 감시 카메라”다. 이 둘을 같은 무게로 고민할 일은 거의 없다. Sentry는 전용 칩이 있는 데이터센터 이야기라 개인이나 스타트업이 당장 도입할 수 있는 물건이 아니다.
내 허용 목록 234개를 분류해 보니
그렇다면 OpenShell이 막아준다는 파일, 네트워크, 프로세스 경계를 지금 내 설정은 얼마나 대신하고 있을까. 에이전트에게 규칙을 도구와 명령 기준으로 나눠 세게 했다. 값은 출력하지 않고 개수만 봤다.
| 범주 | 규칙 수 | 메모 |
|---|---|---|
| Bash 명령 | 173 | 그중 명령 이름으로 등록된 인자 제한 없는 인터프리터 5개(bash, python, python3, node, curl), 절대경로 형태 2개 별도 |
| MCP 도구 | 27 | 노션, 브라우저 자동화 등 |
| WebFetch | 18 | 도메인 단위 허용 |
| Skill | 8 | 슬래시 명령·스킬 실행 |
| 파일(Read·Write) | 7 | 공유 설정에 Write 전체 허용 포함 |
| WebSearch | 1 | 검색 도구 전체 허용 |
| 합계 | 234 | 중복 5개 제외 시 229 |
| 차단(deny)·확인(ask) | 0 | 한 번도 만들지 않음 |
표를 받아 들고 처음엔 “생각보다 촘촘하네”라고 생각했다. 도메인을 하나씩 허용한 WebFetch 규칙이 18개나 있으니 네트워크는 꽤 관리되고 있다고 믿었다. 그런데 Bash 줄 안에 숨은 다섯 줄을 같이 놓고 보니 이야기가 달라졌다.
python3와 curl이 인자 제한 없이 허용되어 있으면, 에이전트가 파이썬 스크립트 한 줄로 아무 호스트에나 접속해도 Claude Code 허용 목록은 그걸 따로 묻지 않는다. 허용 목록은 명령 문자열을 보고 판단하는 앱 수준 규칙이라, 스크립트 안에서 무슨 일이 벌어지는지는 모른다. 도메인 18개는 네트워크 정책처럼 보였지만 실제로는 WebFetch라는 한 도구에만 걸린 규칙이었다.
이 규칙들은 대부분 작업 중에 “이번만 허용”이 귀찮아서 “항상 허용”을 누르며 쌓였다. 234개는 설계된 보안 경계가 아니라 승인 피로가 남긴 흔적이었다. 에이전트가 분류하는 과정에서 비밀값 일부가 명령 문자열째로 허용 규칙에 들어간 줄도 몇 개 나왔다. 그 자체로 별도의 정리 대상이다.
여기서 이해가 바뀌었다. 문제는 OpenShell이 없다는 게 아니라, 운영체제 수준의 경계가 아예 없다는 점이었다. 그렇다면 첫 번째 해법은 새 런타임이 아니라 이미 있는 도구에서 찾아야 한다.
OpenShell 전에 켜야 할 것: 내장 샌드박스
Claude Code에는 이미 Bash 샌드박스가 들어 있다. 공식 문서에 따르면 맥에서는 운영체제에 내장된 Seatbelt를 써서 별도 설치가 필요 없고, 샌드박스 안에서 실행되는 명령과 그 자식 프로세스까지 파일과 네트워크 경계를 운영체제가 강제한다. 설정 파일의 sandbox 항목에서 켜고, 접근할 수 있는 경로와 네트워크 도메인을 지정하는 방식이다.
이게 앞의 문제와 맞물린다. 앱 수준 허용 목록이 못 보던 “파이썬 스크립트 안의 네트워크 호출”을 운영체제 경계로 막을 수 있다. 단, 조건이 있다. 공식 문서상 샌드박스 안에서 실패한 명령은 샌드박스 밖에서 다시 시도될 수 있고, 그때는 일반 허용 규칙으로 판정된다. python3:* 같은 줄이 남아 있으면 그 재시도가 묻지 않고 통과할 수 있다. 그래서 샌드박스 밖 실행을 막는 설정(allowUnsandboxedCommands: false)과 인터프리터 규칙 정리를 함께 해야 한다. 또 이 샌드박스는 Bash 계열 명령에 적용되고 MCP 도구까지 감싸지는 않는다. 이 조건을 지키면 에이전트 하나만 쓰는 사람은 OpenShell이 하려는 일의 상당 부분을 추가 설치 없이 얻는다. 내가 아직 이걸 켜지 않았다는 사실이 이번 점검에서 가장 부끄러운 대목이었다.
그렇다고 OpenShell이 필요 없다는 뜻은 아니다. Claude Code 샌드박스는 Claude Code 안에서만 동작한다. 팀이 Claude Code, Codex, 다른 에이전트 프레임워크를 섞어 쓰면 도구마다 권한 문법과 로그 위치가 달라진다. OpenShell은 에이전트 종류와 상관없이 같은 YAML 정책과 같은 감사 로그 형식으로 묶는다는 점에서 가치가 생긴다.
반대 의견과 아직 모르는 것
공정하게 짚을 부분도 있다. OpenShell은 발표 시점 기준 0.1.x 버전이고, 윈도우 지원은 실험 단계다. 실제 운영에서 기존 권한 체계보다 확실히 낫다는 사례는 아직 쌓이지 않았다. 나 역시 이 글을 쓰는 시점까지 OpenShell을 설치해 돌려보지 않았고, 위의 설명은 공식 문서와 발표 자료에 근거한다.
또 샌드박스는 공짜가 아니다. 네트워크를 기본 차단하면 패키지 설치나 API 호출이 막혀 처음엔 작업이 자주 멈춘다. 허용 도메인을 정리하는 데 시간이 들고, 너무 넓게 열면 다시 허용 목록 234개와 같은 상태로 돌아간다. 샌드박스를 켜는 일보다 무엇을 열어둘지 정하는 일이 더 어렵다.
Sentry에 대해서는 판단할 재료가 더 적다. 가격과 일반 공급 일정이 공개되지 않았고, 전제 하드웨어가 데이터센터급이다. 규제 산업의 대형 조직이 아니라면 “그런 층이 생겼다” 정도로 알아두면 충분하다.
오늘 할 수 있는 순서
첫째, 내 설정 파일에서 인자 제한 없는 인터프리터 규칙과 비밀값이 들어간 규칙부터 찾는다. bash, python3, node, curl처럼 무엇이든 실행할 수 있는 명령이 인자 제한 없이 열려 있다면 그 줄이 사실상 전체 허용이다.
둘째, Claude Code 내장 샌드박스를 켜고 샌드박스 밖 실행을 막은 뒤 네트워크 허용 도메인을 명시한다. 처음 며칠은 막히는 요청을 보면서 필요한 도메인만 추가하는 편이 안전하다.
셋째, 에이전트를 두 종류 이상 쓰거나 감사 로그를 남겨야 하는 팀이라면 OpenShell을 스크래치 저장소에서 시험한다. 실제 계정 대신 버려도 되는 저장소와 권한이 좁은 토큰으로 시작하는 게 기본이다. Sentry는 인프라 팀이 BlueField-4 계획을 이야기할 때 다시 보면 된다.
샌드박스가 필요하냐는 질문에 대한 내 답은 “필요하다, 다만 가장 가까운 것부터”다. 엔비디아 발표가 준 가장 큰 쓸모는 새 제품이 아니라, 내 허용 목록이 경계가 아니라 기록에 불과했다는 걸 확인하게 해준 계기였다.
FAQ
OpenShell은 무료인가요? Apache 2.0 오픈소스라 무료로 쓸 수 있습니다. 다만 Docker·Podman 같은 컨테이너 환경이나 호스트 가상화가 필요합니다.
맥에서도 OpenShell을 쓸 수 있나요? 애플실리콘 맥은 지원 대상입니다. 인텔 맥은 README 지원 목록에 없습니다.
Sentry를 개인이 쓸 수 있나요? 어렵습니다. BlueField-4 DPU가 있는 데이터센터 환경을 전제로 하며 일반 공급 일정도 공개되지 않았습니다.
Claude Code 샌드박스만으로 충분한가요? Claude Code 하나만 쓰는 개인이라면 샌드박스 밖 실행을 막고 인터프리터 규칙을 정리한다는 전제에서 충분한 출발점입니다. MCP 도구는 샌드박스 대상이 아니라 별도로 점검해야 합니다. 여러 에이전트를 같은 정책으로 묶어야 할 때 OpenShell을 검토하면 됩니다.
관련 글
- Claude Code 오래 쓸수록 먼저 고쳐야 할 설정 2026 — hooks·permissions·subagents
- Claude Code 권한 설계 체크리스트 2026 — hooks·subagents·세션 분리 어디서부터 막아야 하나
- OpenAI Agents SDK sandbox는 언제 쓰고 언제 과한가 2026