What if the network was the sandbox? — Remy Guercio, Tailscale
📺 원본 영상: What if the network was the sandbox? — Remy Guercio, Tailscale
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-06-02
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 강연에서 Tailscale의 Remy Guercio는 AI 에이전트를 위한 샌드박스 환경을 구성할 때, 권한 관리(AuthN/AuthZ)를 컨테이너나 VM 내부가 아닌 네트워크 계층 자체에서 처리하는 접근 방식을 제안한다. 강연자는 이 아이디어를 바탕으로 Tailscale이 직접 구축한 AI 게이트웨이인 Aperture를 소개하고, 라이브 데모를 통해 에이전트 모니터링, 신원 기반 접근 제어, 도구 호출(tool call) 감사가 어떻게 네트워크 수준에서 투명하게 보장되는지 보여준다.
샌드박스란 무엇인가: 가장 기본적인 정의로 돌아가기
AI 에이전트를 안전하게 격리하기 위해 VM을 써야 할지, 컨테이너를 써야 할지, 에이전트를 박스 안에 넣어야 할지 밖에 놓아야 할지에 대한 논쟁은 늘 있어왔다. 강연자는 이 복잡한 논의에서 한 발짝 물러서서, 샌드박스를 가장 원초적인 두 가지 구성 요소로 분해하는 것에서 출발한다. 첫 번째는 **경계(Boundary)**다. 샌드박스 안에 있는 것과 밖에 있는 것을 구분하는 선이다. 두 번째는 **권한 집합(Permission Set)**이다. 정해진 신원(Identity)과 권한이 없으면 샌드박스는 장난감 없는 모래상자에 불과하며, 거기에는 아무것도 의미있는 것이 없다.
이 단순한 틀을 갖고 강연자는 곧바로 핵심 문제를 짚는다. 오늘날 에이전트를 샌드박스 안에 배치할 때 권한을 처리하는 방식은 크게 두 가지다. 하나는 모델 공급업체가 권장하는 API 키 방식이다. 풀 프라이스를 지불하고 키를 받아 사용하는 이 방식은 진정한 의미의 인증(AuthN)과 인가(AuthZ)를 구분하지 못한다. 더 심각한 문제는, 에이전트를 루프로 오래 실행하면 모델이 그 키를 가지고 예상치 못한 행동을 하기 쉽다는 점이다. 다른 하나는 보다 비용 효율적인 OAuth 혹은 OIDC 방식이다. 그러나 이 두 가지 방식 모두 결국 키 혹은 인증 정보가 샌드박스 안에 들어간다는 공통적인 문제를 안고 있다. 에이전트는 자신에게 권한을 부여하는 수단에 직접 접근할 수 있게 되며, 이는 격리의 근본 취지를 흔든다.
네트워크를 샌드박스로: WireGuard와 Tailscale의 접근 방식
강연자가 제시하는 대안의 핵심은 간단하다. 권한 관리를 샌드박스 내부가 아닌 네트워크 계층으로 올리는 것이다. 이 발상의 기술적 토대는 WireGuard 프로토콜이다. WireGuard는 네트워크 상의 모든 노드에 키를 부여하여 암호화된 직접 연결을 가능하게 한다. Tailscale은 이 WireGuard 위에 신원(Identity) 레이어를 추가하며, 그 결과물이 바로 Tailnet이라는 개념이다. 컨테이너든, GPU 서버든, 노트북이든, 스마트폰이든, Tailnet에 참여하는 모든 노드는 그 연결 자체에 신원 정보를 담게 된다.
구체적으로 말하면, Tailscale을 통해 이루어지는 모든 연결에는 다음의 정보가 함께 전달된다. 해당 기기에 로그인한 사용자, SCIM(System for Cross-domain Identity Management) 동기화를 통해 연동된 그룹(예: 엔지니어링 조직 소속 여부), 그리고 특정 에이전트나 서비스에 부여된 태그(Tag)가 그것이다. 예를 들어 GitHub Actions에서 실행되는 PR 리뷰 봇이라면, 그 봇 자체에 pr-review-bot과 같은 태그를 붙일 수 있다. 이 신원 정보는 네트워크 연결 자체에 내포되어 전달되므로, 수신 측에서도 별도의 검증 로직 없이 연결해온 주체가 누구인지 알 수 있다는 점이 결정적 차이다.
이것이 기존의 IP 주소 기반 접근 제어나 API 키 기반 인증과 근본적으로 다른 이유다. IP 주소는 누가 연결하는지 말해주지 않고, API 키는 별도로 관리해야 하며 샌드박스 안에 넣어야 한다. 그러나 Tailscale의 방식에서는 신원과 연결이 하나로 통합되어, 연결이 곧 인증이자 인가가 된다.
Aperture: 네트워크 신원 위에 구축된 AI 게이트웨이
05:40 - Aperture AI 게이트웨이 아키텍처 다이어그램 슬라이드
이 아이디어를 AI 워크플로우에 직접 적용한 것이 Tailscale이 구축한 Aperture다. Aperture는 Tailnet 위의 노드로 배포되는 LLM 게이트웨이로, 작동 방식은 다음과 같다. 먼저 Anthropic, OpenAI, Google Gemini, Vertex AI, AWS Bedrock 등 어떤 제공업체로부터든 단 하나의 API 키를 Aperture에 등록한다. 이후 에이전트가 실행되는 샌드박스(예: GitHub Actions 러너)는 Tailnet에 합류하면서 태그를 부여받는다. 핵심은 이 샌드박스 안에는 어떠한 API 키도 존재하지 않는다는 것이다. 에이전트가 LLM에 요청을 보내려면 반드시 Aperture를 통해야 하고, Aperture는 연결해온 주체의 Tailnet 태그를 확인하여 허용 여부와 허용 범위를 판단한다.
GitHub Actions의 경우, GitHub에서 제공하는 Federated OIDC를 활용하면 러너가 스핀업될 때 Tailnet에 합류하면서 자동으로 태그를 받게 된다. 이렇게 되면 에이전트는 공유하거나 유출할 수 있는 키 자체를 갖고 있지 않다. 강연자의 표현을 빌리자면, “에이전트의 샌드박스에는 자신의 경계를 벗어나는 데 사용할 수 있는 키가 문자 그대로 전혀 없다.” Claude Code를 Aperture를 통해 실행할 때도, 설정 파일(settings.json)의 API 키 항목을 단순히 대시(-) 하나로 채우고 Base URL만 Aperture 노드로 지정하면 된다. API 키 모드를 요구하는 도구가 불평하지 않도록 플레이스홀더를 채워주는 것이지, 실제 키가 존재하는 것이 아니다.
12:14 - API 키를 대시(-)로 설정하고 Aperture를 Base URL로 사용하는 Claude Code 설정 파일
데모: Aperture가 제공하는 완전한 가시성
07:50 - 로그인된 사용자의 신원이 Tailnet을 통해 자동으로 인식되어 표시되는 Aperture 대시보드
강연자가 데모에서 보여주는 Aperture의 핵심 기능은 단순한 프록시를 넘어선 **완전한 감사(audit) 및 관찰가능성(observability)**이다. 강연자 본인이 회사 Tailnet에 노트북으로 로그인한 상태에서 Aperture에 접속하면, 시스템은 그가 누구인지 즉시 식별하고 그에 속한 사용 내역만을 표시한다. 사용한 토큰 수, 사용한 모델 목록, 모델별 지출 금액, 그리고 자신의 신원으로 게이트웨이를 통과한 모든 요청의 상세 내역—요청 헤더, 요청 본문, 응답 본문까지—을 확인할 수 있다. 이 모든 정보는 신원 기반으로 자동 분류되므로, 관리자가 특정 사용자나 에이전트의 행동을 추적하기 위해 별도의 로그 수집 인프라를 구성할 필요가 없다.
08:15 - 모델별 토큰 사용량, 비용 현황 및 요청 목록
데모에서 특히 인상적인 순간은 Claude Code로 단순히 “안녕”이라고 인사하는 요청에도 약 20센트가 과금된다는 사실이 UI에 즉시 표시될 때다. Claude Code가 시작 시점에 보내는 초기 요청에 얼마나 방대한 프롬프트와 컨텍스트가 담겨 있는지를 Aperture의 로그에서 그대로 확인할 수 있었으며, 강연자는 이를 청중에게 직접 보여주었다. 또한 10단어 이야기를 요청했을 때 모델(당시 테스트한 Opus)이 9단어를 생성하여 재요청을 했고, “그 말이 맞다, 9단어였다”는 수정 과정 전체가 세션 로그에 남아있는 것도 확인할 수 있었다.
PR 리뷰 봇과 도구 호출 감사: 컨테이너 밖에서 보장되는 투명성
강연에서 기술적으로 가장 중요한 포인트 중 하나는 도구 호출 감사의 신뢰성이다. 통상적인 모니터링은 에이전트 런타임 내부나 오케스트레이션 레이어에서 이루어지므로, 에이전트가 의도적으로 혹은 비의도적으로 로깅을 우회할 가능성이 있다. 그러나 Aperture는 네트워크 계층에서 동작하기 때문에, LLM으로의 요청이 발생하는 순간—즉, 도구 호출이 LLM에 의해 생성되고 실행 허가를 받는 순간—을 구조적으로 무조건 포착한다.
강연자는 이를 이렇게 표현한다: “에이전트가 어떤 도구 호출이든 하려면 반드시 Aperture를 통해야만 합니다. 이것은 컨테이너 내부에서 일어나는 일이 아니고, 하니스(harness)에서 일어나는 일도 아닙니다.” 데모에서 보여준 PR 리뷰 봇(dogfood 태그)의 로그에서는 MCP 도구를 통한 코드 리뷰 업데이트 요청, bash 명령어 실행, grep 검색, 코드 리뷰 코멘트 재업데이트 등의 전체 시퀀스를 순서대로 확인할 수 있었다. 비용 측면에서도 4센트를 사용하며 세 개의 명령을 동시에 실행했다는 것까지 파악 가능했다.
10:06 - PR 리뷰 봇(dogfood 태그) 지난 30일간의 LLM 요청 로그 및 비용
11:09 - MCP 도구 호출, bash 명령어, grep 실행 내역 전체 목록
더 나아가, 에이전트를 중단시키고 싶을 때도 “키가 더 이상 작동하지 않는다”는 사실을 에이전트가 인식하는 것이 아니라, 네트워크 연결 자체가 차단되는 것이다. 이는 에이전트가 “키가 안 되니 다른 엔드포인트를 시도해보겠다”는 식으로 우회하는 것을 구조적으로 불가능하게 만든다. 중단이 결정되면 그것은 말 그대로 연결의 종료이며, 협상의 여지가 없다.
비용 제어, 웹훅, 그리고 교차 제공업체 쿼터
Aperture가 API 키를 중앙에서 관리한다는 사실은 비용 제어 측면에서도 실용적인 이점을 만들어낸다. 복수의 LLM 제공업체를 사용하는 환경에서도 **단일한 예산 풀(budget pool)**을 설정할 수 있다. Anthropic에 얼마, OpenAI에 얼마를 따로 할당하는 게 아니라, “이 팀 전체의 예산은 1,000달러이며 원하는 방식으로 사용하라”는 식의 교차 제공업체 예산 관리가 가능하다. 팀 단위의 큰 예산과 개인 단위의 작은 예산을 동시에 설정하여 합집합으로 적용하거나, 내부 GPU 엔드포인트는 무제한으로 허용하되 특정 외부 모델은 할당량을 제한하는 세밀한 정책도 구성할 수 있다.
웹훅 기능도 주목할 만하다. Aperture는 각 도구 호출이나 LLM 요청에 대해 서드파티 엔드포인트로 알림을 전송하는 웹훅을 지원하며, 이 웹훅은 **실행이 보장(guaranteed)**된다. 네트워크 계층에서 처리되므로 에이전트가 이를 무시하거나 우회하는 것이 구조적으로 불가능하기 때문이다. 이를 통해 특정 도구 호출이 발생할 때 Slack 알림을 보내거나, 감사 시스템에 기록하거나, 승인 워크플로우를 트리거하는 것도 가능하다.
TSNet: 직접 구축을 위한 오픈소스 기반
Aperture가 Tailscale의 완성된 서비스라면, TSNet은 동일한 철학을 자신의 프로그램에 내재화할 수 있게 해주는 오픈소스 Go 라이브러리다. TSNet을 사용하면 직접 작성한 Go 프로그램을 Tailnet 노드로 등록하고, Aperture와 동일하게 연결 시 전달되는 신원 정보를 읽어 활용할 수 있다. 즉, 별도의 OAuth 설정이나 공개 접근 없이 조직 내부용 MCP 서버나 내부 API 엔드포인트를 구축하면서도, “이 요청을 보낸 주체가 누구인가”를 네트워크 수준에서 확인하는 것이 가능해진다.
실제로 Aperture 자체도 TSNet을 비롯한 Tailscale의 공개 primitives만을 사용하여 구축되었으며, 비공개 내부 API에 의존하지 않는다. 강연자는 이 사실을 명시적으로 언급하며, “이론적으로는 누구든 이것을 직접 만들 수 있다”고 밝혔다. 이는 Tailscale이 자신들의 플랫폼을 단순한 제품이 아니라, 그 위에서 무언가를 구축할 수 있는 기반(foundation)으로 포지셔닝하고 있음을 보여준다.
Q&A 핵심 요약
강연 후 질의응답에서 몇 가지 중요한 논점이 다루어졌다. 각각의 질문과 강연자의 답변을 정리하면 다음과 같다.
권한 설정 방법에 대한 질문에서, 강연자는 두 가지 경로를 설명했다. 하나는 Aperture UI의 그랜트(Grant) 기능을 통해 시각적으로 설정하는 방법으로, 모델 접근, 쿼터, MCP 접근, 웹훅, 역할 등을 세분화하여 설정할 수 있다. 다른 하나는 Tailscale의 정책 파일(ACL 파일)에 “애플리케이션 캐퍼빌리티(Application Capability)“를 직접 삽입하는 방법이다. 이를 사용하면 사용자 신원, 태그, 그룹 정보와 함께 임의의 메타데이터를 Tailscale 컨트롤 플레인이 보증하는 형태로 전달할 수 있다. 대규모 운영 환경을 위한 GitOps 워크플로우 통합 및 API도 제공된다.
투명한 프록시 여부에 대한 질문—즉, 에이전트 코드에 Base URL을 명시적으로 설정하지 않고 네트워크 수준에서 투명하게 가로챌 수 없냐는 질문—에 대해, 강연자는 기술적으로는 가능하지만 그것은 “Tailscale답지 않다”고 답했다. 투명 프록시는 편의성을 주지만, 그 아래에서 무언가가 바뀌거나 이동할 때 혼란을 야기하고 예측 불가능성을 높인다. Tailscale의 철학은 명시적이고 쉬운 설정에 있으며, 이 도구는 AI를 활용해 무언가를 만들고자 하는 개발자와 이를 통제하고 싶은 IT/보안 관리자 모두를 위한 “두 세계의 최선”을 지향한다고 강조했다.
에이전트가 도구 호출 대신 코드를 직접 생성하고 실행하는 경우의 권한 관리에 대해서도 질문이 나왔다. 강연자는 이것이 더 복잡한 문제임을 인정하면서도, 바로 이 이유 때문에 MCP 계층이 아닌 LLM 계층에서 처리하기로 결정했다고 설명했다. 에이전트가 코드를 작성하고 실행하더라도 LLM 호출 자체는 여전히 Aperture를 통해야 하므로, bash 명령어를 포함한 도구 사용 내역이 캡처된다. 내부적으로 살펴본 결과, 에이전트가 실제로 가장 많이 사용하는 것은 MCP가 아닌 bash였다는 점도 공유했다. 물론 코드를 난독화한 후 실행하는 경우처럼 완벽한 통제가 어려운 엣지 케이스는 존재하며, 강연자는 향후 bash 명령어 수준의 가드레일(예: rm -rf / 차단)을 추가할 계획임을 언급했다.
마무리 / 핵심 정리
이 강연의 핵심 통찰은 AI 에이전트 샌드박싱에서 가장 어려운 문제—에이전트가 자신의 권한 부여 수단에 직접 접근할 수 있다는 것—를 해결하는 방법이 반드시 컨테이너나 VM 수준의 더 강한 격리일 필요는 없다는 것이다. 권한 관리 자체를 네트워크로 옮기면, 에이전트 샌드박스 안에는 그 어떤 자격 증명도 존재하지 않게 되고, 네트워크 연결 자체가 신원 증명이 된다. 이 구조는 동시에 모든 LLM 호출과 도구 호출이 반드시 특정 지점을 통과하도록 강제하므로, 가시성(visibility), 감사(audit), 비용 제어(cost control)가 구조적으로 보장된다.
Aperture는 현재 Tailscale의 무료 플랜에서 사용 가능하며, Claude Code, OpenAI Codex CLI, Gemini CLI 등 주요 AI 코딩 도구와 호환된다. TSNet을 통해 동일한 철학을 자체 서비스에 내재화하는 것도 가능하다. 에이전트 시대의 보안 문제가 단순히 “무엇을 차단할 것인가”가 아니라 “무엇이 일어나고 있는지 볼 수 있는가”의 문제임을 이 강연은 명확하게 보여준다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | What if the network was the sandbox? — Remy Guercio, Tailscale |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-06-02 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다.
정확한 내용은 원본 영상을 참조해 주세요.