Deno Sandbox 소개: 30분짜리 클라우드 실험실, 시크릿은 못 훔칩니다
Deno 팀이 ‘Deno Sandbox’라는 새 호스팅 샌드박스 제품을 공개했습니다. 이름에 Deno가 들어가지만 “Deno 런타임” 자체의 기능이라기보다, Deno Deploy(SaaS) 안에서 제공되는 별도 서비스에 가깝습니다.1 한마디로 정리하면, API 토큰으로 잠깐짜리 격리된 머신을 띄워서 코드 실행·파일 작업·네트워크 호출을 시키되, 특히 API 키(시크릿)를 샌드박스 안에서 훔쳐갈 수 없게 설계한 점이 눈에 띄는 제품입니다.1
이 글에서는 Deno Sandbox가 정확히 무엇인지, 어떤 일을 할 수 있는지, 그리고 왜 “시크릿 관리 방식”이 중요한지까지 쉬운 말로 풀어보겠습니다.
Deno Sandbox란? “Deno가 없어도 쓰는” Deno 팀 서비스
많은 분이 처음에 이렇게 오해합니다. “오, Deno에서 로컬 샌드박스를 제공하나 보다?” 그런데 Deno Sandbox는 로컬 기능이 아니라 Deno 클라우드 위에서 돌아가는 원격 샌드박스입니다. 즉, 내 노트북에 컨테이너가 뜨는 게 아니라, Deno Deploy 쪽에서 격리된 인스턴스를 잠깐 빌려 쓰는 형태죠.1
그래서 재미있는 포인트가 하나 생깁니다. 샌드박스에 넣어 돌리는 코드가 꼭 JavaScript일 필요가 없습니다. “접근”만 하면 되니까요. 실제로 Deno 팀은 Python에서 쓰는 deno-sandbox 라이브러리도 제공합니다.1
정리하면, Deno Sandbox는 “Deno 생태계의 클라우드 도구함”에 더 가깝고, 언어보다는 격리 실행 환경 + 제어 API에 초점이 맞춰져 있습니다.
Python/JavaScript에서 샌드박스 다루기: API 토큰만 있으면 됨
Deno Sandbox의 사용 흐름은 꽤 직관적입니다. API 토큰으로 인증하고, 샌드박스를 하나 만들고, 그 안에서 명령을 실행하거나 파일을 읽고 쓰는 식입니다.1
Python 예시가 특히 이해가 빠릅니다. 샌드박스 내부에서 echo 같은 셸 명령을 실행할 수 있고, /tmp 같은 경로에 텍스트 파일을 저장했다가 다시 읽을 수도 있습니다.1 “테스트용으로 잠깐 VM 하나 빌려서 스크립트 굴리는 느낌”을 떠올리면 가장 가깝습니다.
JavaScript 클라이언트도 제공되는데, 흥미롭게도 기반 API는 아직 공식 문서가 빵빵하진 않고, 관찰상 WebSocket 기반으로 동작한다고 알려져 있습니다.1 (이 말은 곧, 대화형 세션/스트리밍 제어에 최적화된 형태일 가능성이 높다는 뜻이기도 합니다.)
성능 스펙과 제약: 4GB RAM, 2 vCPU, 그리고 “30분 타이머”
샌드박스라고 해서 장난감 수준은 아닙니다. 인스턴스 하나에 최대 4GB RAM, 2 vCPU, 10GB 임시 스토리지를 제공한다고 공개되어 있습니다.1 데이터 분석 실험, 패키지 설치 후 실행, 빌드/테스트 같은 작업도 “짧고 굵게”는 충분히 가능해 보입니다.
다만 성격이 명확합니다. 이건 장기 운영 서버가 아니라 “실험실”입니다. 세션은 최대 30분까지만 지속됩니다.1 대신 필요하다면 영구 볼륨을 마운트하거나, 스냅샷으로 미리 꾸려둔 상태에서 빠르게 부팅하는 방식도 지원합니다.1 매번 처음부터 세팅하지 않도록 “재사용 가능한 실험 환경”을 만들어 주는 옵션인 셈이죠.
과금은 “시간당 고정 요금” 느낌보다는 사용량 기반에 가깝습니다. CPU 사용시간, 메모리 사용량(GB-h), 볼륨 스토리지 사용량 기준으로 책정된다고 합니다.1
네트워크 접근 통제: “갈 수 있는 도메인”을 직접 지정
LLM 에이전트나 자동화 코드에서 가장 껄끄러운 순간은, 코드가 의도치 않게 여기저기 외부로 통신할 때입니다. Deno Sandbox는 샌드박스를 만들 때 접근 허용 도메인을 직접 지정할 수 있습니다.1
이게 왜 중요하냐면, 샌드박스를 아무리 격리해도 네트워크가 뚫려 있으면 데이터가 새 나가기 쉬워집니다. 반대로 “이 샌드박스는 api.openai.com만 나가도록”처럼 제한해 두면, 설령 내부 코드가 삐끗해도 사고 범위를 줄이기가 훨씬 쉬워집니다.
즉, Deno Sandbox는 “실행 격리”뿐 아니라 “통신 격리”를 기본 설계로 끌고 온 제품이라고 볼 수 있습니다.
핵심 차별점: 시크릿을 ‘환경변수로 안 주는’ 샌드박스
여기부터가 Deno Sandbox가 사람들 눈길을 끄는 이유입니다. 일반적인 샌드박스/컨테이너에서 API 키를 쓰려면 보통 환경변수로 OPENAI_API_KEY=...를 주입합니다. 그런데 그러면 내부 코드가 마음만 먹으면 키를 읽어 외부로 빼돌릴 수 있죠. 특히 LLM 도구 연결이 많아진 요즘, 프롬프트 인젝션 같은 형태로 “키를 출력해” 같은 유도가 섞이면 더 골치 아픕니다.
Deno Sandbox는 이 문제를 정면으로 피합니다. 시크릿을 등록하더라도, 샌드박스 내부에서는 “진짜 값”이 아니라 플레이스홀더(가짜 토큰)만 보이게 합니다.1 그리고 허용된 호스트로 나가는 요청에 한해, 프록시가 그 플레이스홀더를 실제 시크릿으로 치환해 줍니다.1
결과적으로 샌드박스 안의 코드가 볼 수 있는 건 “쓸 수는 있지만 읽을 수는 없는 키”입니다. 누군가 플레이스홀더를 통째로 빼가도, 다른 곳에서는 쓸모가 없어지는 구조죠.1
이 접근은 Fly.io의 tokenizer 프로젝트가 고민해온 패턴과도 닮아 있고, 실제로 커뮤니티에서도 비슷한 아이디어라는 언급이 나옵니다.2 시크릿을 애플리케이션에 주지 않고, “시크릿을 다루는 작은 중개자(프록시)”가 책임지게 만드는 방식은 샌드박스 보안을 한 단계 올리는 데 꽤 유효한 선택지입니다.
시사점: “샌드박스”의 다음 경쟁 포인트는 보안 UX다
Deno Sandbox를 한 문장으로 요약하면 이렇습니다. “30분짜리 고성능 원격 실험실을 API로 빌려 쓰되, 네트워크와 시크릿을 기본값부터 조심스럽게 설계한 서비스.”1
개인적으로는, 앞으로 샌드박스 시장에서 진짜 차이를 만드는 건 CPU나 RAM 숫자보다 “보안을 개발 경험으로 녹이는 방식”이라고 봅니다. 도메인 allowlist, 시크릿 비노출(프록시 치환) 같은 기능은 보안팀만 좋아하는 옵션이 아니라, LLM 시대의 앱 개발자라면 누구나 체감하는 ‘필수 안전장치’가 되고 있으니까요.
실용 팁을 하나만 남기자면, Deno Sandbox 같은 환경을 쓸 때는 처음부터 “허용 도메인 최소화”로 시작하는 게 좋습니다. 기능이 늘어날수록 allowlist를 넓히는 건 쉽지만, 반대로 넓게 열어둔 걸 나중에 조이는 건 늘 어렵거든요.