우리는 모든 AI 에이전트를 샌드박스(Sandbox) 처리했습니다. 우리가 배운 점과 여러분이 배워야 할 점

어느 날 아침, 나의 AI 에이전트가 나에게 피쉬 오일 영양제를 챙겨 먹으라는 알림을 보냈습니다. 특정 브랜드, 정확한 복용량, 그리고 복용해야 할 시간까지 상세했습니다. 문제는 내가 에이전트에게 그런 말을 한 적이 전혀 없다는 것입니다. 그것은 다른 누군가의 영양제였습니다.

우리는 오픈 소스 에이전트 프레임워크인 OpenClaw를 사용하여 제품을 구축하던 초기 단계였습니다. 우리는 단일 OpenClaw 인스턴스를 설정하고, 팀을 위해 약 10개의 에이전트를 생성하여 동료들에게 배포했습니다. 모두가 자신의 에이전트와 대화하고, 워크플로우 (Workflow)를 테스트하며 즐거운 시간을 보냈습니다. 무언가 진정으로 새로운 것이 작동할 때 느껴지는 그런 에너지 말이죠.

그러다 영양제 알림이 나타났습니다. 조사를 시작했고, 근본 원인은 코믹할 정도로 단순했습니다. 모든 에이전트가 하나의 공유된 인스턴스에서 실행되고 있었던 것입니다. 한 에이전트가 소유자에게 메시지를 전달하지 못하자, 시도할 수 있는 모든 가용 채널을 사용했습니다. 여기에는 다른 사람들의 대화도 포함되었습니다. 개인 건강 데이터가 잘못된 채팅창에 나타난 것입니다.

다른 동료들도 같은 현상을 보고했습니다. 잡히지도 않은 약속에 대한 알림, 설정하지 않은 작업들이 나타났습니다. 기본 시스템이 모든 에이전트를 연결된 것으로 취급했기 때문에, 한 에이전트의 컨텍스트 (Context)가 다른 에이전트의 대화로 유출되고 있었습니다.

그것은 우리에게 경종을 울렸습니다. 이론적인 보안 논문도, 컴플라이언스 (Compliance) 요구 사항도 아니었습니다. 첫 주에 친구들 사이에서 발생한 실제 데이터 유출 사건이었습니다.

샌드박싱 (Sandboxing)을 시도하기 전에 우리가 했던 것들

우리의 첫 번째 본능은 커뮤니케이션이었습니다. 우리는 MD 설정 파일에 에이전트가 할 수 있는 일과 할 수 없는 일을 상세한 지침으로 작성했습니다. 아이에게 긴 집안 규칙 목록을 주는 것과 같다고 생각하면 됩니다. 다른 사람의 방에 들어가지 마라. 개인 정보를 공유하지 마라. 네가 만들지 않은 것은 아무것도 건드리지 마라.

어느 정도는 효과가 있었습니다. 한동안은 말이죠. 에이전트들은 대체로 규칙을 따랐습니다. 하지만 컨텍스트 윈도우 (Context Window)는 시간이 지남에 따라 압축되고, 세션 (Session)은 재시작되며, 규칙은 희미해집니다. 월요일에는 경계를 존중하던 에이전트가 목요일에는 경계를 넘을 수도 있습니다. 지침이 작업 메모리 (Working Memory)에서 밀려났기 때문입니다.

우리는 또한 규칙 기반 접근 방식으로는 해결할 수 없는 두 번째 문제도 깨달았습니다. 바로 사용자가 자신의 에이전트를 망가뜨릴 수 있다는 점입니다. 파일 시스템 접근 권한과 코드 수정 능력을 가진 AI와 대화할 때, 단 한 번의 무심한 요청만으로도 전체 시스템을 구동하는 설정을 실수로 손상시킬 수 있습니다. 고객이 메시지 하나로 자신의 에이전트를 벽돌(brick)로 만들 수 있는 SaaS 제품은 아무도 계속 사용하지 않을 것입니다.

MD 파일과 양호한 행동 지침만으로는 충분하지 않았습니다. 우리에게는 제안이 아닌 실제적인 벽이 필요했습니다.

VM이 아닌 컨테이너를 선택한 이유

우리는 각 클라이언트에게 개별적인 가상 머신 (VM)을 제공하는 방안을 잠시 고려했습니다. 완전한 격리와 완전한 분리 말입니다. 하지만 계산을 해보니 금방 포기해야 했습니다. 수천 개의 VM을 개별적으로 유지 관리, 패치 및 모니터링하는 것은 완전히 다른 차원의 비즈니스입니다. 우리는 클라이언트 100명당 전담 운영 (Ops) 팀이 필요하지 않으면서도 확장 가능한 격리 방식이 필요했습니다.

전환점은 OpenClaw의 제작자인 Peter의 한마디였습니다. 그는 간단하게 말했습니다. "OpenClaw는 다양한 승객을 태운 버스가 아닙니다. 격리와 다중 소유권이 필요하다면, 도커화 (dockerize) 하세요." 이 말로 우리의 논쟁은 종결되었습니다.

컨테이너가 정답이었습니다. 클라이언트당 하나의 격리된 Docker 컨테이너를 할당하고, 각 컨테이너는 자신만의 파일 시스템, 프로세스 공간, 리소스 제한을 갖도록 했습니다. 에이전트는 /workspace만을 볼 수 있으며 그 외에는 아무것도 볼 수 없습니다. /home도, API 키가 포함된 환경 변수도, 호스트에 대한 접근 권한도 없습니다. 에이전트에게 루트 디렉토리에 무엇이 있는지 물으면, 에이전트는 빈 워크스페이스를 보여줍니다. 그것이 에이전트의 관점에서는 세상의 전부입니다.

하지만 컨테이너만으로는 충분하지 않았습니다. 결국 우리는 총 7단계의 격리 계층을 구축하게 되었습니다. 컨테이너는 가장 눈에 보이는 계층이지만, 나머지 계층은 자격 증명 분리, 네트워크 경계, 미디어 접근 제어 등을 처리합니다. 여기서 모든 계층을 상세히 설명하지는 않겠지만, 핵심은 단 하나의 계층이 실패하더라도 나머지 계층이 여전히 방어 역할을 수행한다는 점입니다.

특정한 OpenClaw 설정 하나가 샌드박스(Sandbox)와 단순한 장식 사이의 차이를 만들었습니다: 바로 tools.elevated.enabled입니다. OpenClaw는 기본적으로 에이전트가 호스트 머신에서 코드를 실행할 수 있도록 허용합니다 (true). 이는 개발에는 강력한 기능이지만, 멀티 테넌트 (multi-tenant) 환경에서는 재앙적입니다. 우리는 모든 클라이언트 컨테이너에 대해 이 설정을 false로 설정했습니다. 이 단 하나의 플래그(flag)가 없다면, 다른 어떤 격리 조치도 의미가 없습니다.

에이전트는 절대로 실제 키(key)를 보유해서는 안 됩니다

제가 가장 옳았다고 확신하는 아키텍처 결정은 다음과 같습니다: 우리의 에이전트는 외부 API 호출을 수행하지 않습니다. 언어 모델 (language model) 제공업체도, 미디어 생성 서비스도, 메시징 플랫폼도 아닙니다. 그 어떤 것도 마찬가지입니다.

샌드박스 외부에 별도의 서비스가 위치하여 모든 외부 통신을 처리합니다. 에이전트가 텔레그램(Telegram) 메시지를 보내거나 이미지를 생성해야 할 때, 에이전트는 내부 엔드포인트 (endpoint)와 통신합니다. 해당 엔드포인트가 요청을 검증하고, 실제 자격 증명 (credentials)을 주입하며, 실제 API 호출을 수행한 뒤 결과를 반환합니다. 에이전트는 단 하나의 API 키도 볼 수 없습니다.

우리는 이를 토큰화된 경로 (tokenized routes)라고 부릅니다. 에이전트는 그것을 가능하게 하는 자격 증명을 받지 않고도 특정 능력 (capability, 예: 메시지 전송, 미디어 생성)을 부여받습니다. 설령 누군가가 에이전트의 전체 환경을 덤프 (dump)하도록 만드는 데 성공하더라도, 그곳에는 유용한 것이 아무것도 없습니다.

우리도 이 교훈을 아주 힘들게 얻었습니다. 초기 단계에 한 테스터가 에이전트에게 언어 모델 API 키를 요청했습니다. 에이전트는 기쁘게 그것을 공유했습니다. 에이전트에게 권한이 있었고, 이를 금지하는 규칙이 없었기에 그대로 수행한 것입니다. 그 사건 이후, 우리는 비밀 정보 (secrets)가 애초에 샌드박스로 들어오지 않도록 전체 접근 방식을 재설계했습니다.

비교를 위해: 저는 AI 에이전트를 제공하는 다른 플랫폼에 가입하여 에이전트를 생성한 뒤, API 키를 요청해 보았습니다. 에이전트는 요청을 거절했으며, 이는 좋은 결과였습니다. 그다음 저는 에이전트에게 루트 디렉토리 (root directory)에 보이는 모든 것을 아카이브(archive)하여 저에게 파일을 보내달라고 요청했습니다. 몇 초 만에 ZIP 파일이 도착했습니다. 그 안에는 작동 가능한 OpenRouter API 키들이 들어 있었습니다. 해당 플랫폼의 에이전트는 직접적으로 키를 공유하지 말라는 지침은 따랐지만, 파일 시스템을 압축하여 아카이브를 보내는 행위가 그 제한 사항을 완전히 우회한다는 사실은 이해하지 못했습니다. 키들은 에이전트가 읽고 패키징할 수 있는 평문 (plaintext) 설정 파일에 그대로 놓여 있었습니다.

이것이 규칙 (rules)과 아키텍처 (architecture)의 차이입니다. 규칙은 창의적인 문구 표현을 통해 우회될 수 있지만, 아키텍처는 그럴 수 없습니다.

모든 것이 망가졌지만, 괜찮았습니다

우리가 처음 컨테이너 (containers)를 배포했을 때, 아무것도 작동하지 않았습니다. 에이전트는 완전히 응답을 멈췄습니다. 기본적인 문제들을 해결한 후에는 다시 대화할 수는 있었지만, 장기 기억 (long-term memory)에 접근할 수 없었고, 기술 (skills)을 실행할 수 없었으며, 음성 메시지를 처리할 수도 없었습니다. OpenClaw의 모든 개별 기능은 컨테이너 내부에서 더 이상 존재하지 않는 경로를 통해 연결되어 있었기 때문입니다.

우리는 모든 것을 다시 연결해야 했습니다. 모든 파일 경로, 모든 서비스 연결, 모든 도구 통합 (tool integration)을 말입니다. 몇 주가 걸렸습니다. 단순히 이전 설정으로 되돌리고 싶은 유혹이 강하게 드는 아침들도 있었습니다.

하지만 그런 순간에 여러분을 계속 나아가게 하는 것은 이것입니다. 이전 설정은 데이터가 유출된다는 사실을 여러분은 알고 있습니다. 규칙 기반 (rules-based) 접근 방식은 시간이 지남에 따라 퇴보한다는 것도 알고 있습니다. 퇴각할 수 있는 편안한 중간 지대는 없습니다. 유일한 방법은 뚫고 지나가는 것뿐입니다.

작업이 완료되자 예상치 못한 일이 일어났습니다. 샌드박스 (sandbox)는 단순히 클라이언트들로부터 서로를 보호하는 것에 그치지 않았습니다. 그것은 각 클라이언트를 클라이언트 자신으로부터 보호했습니다. 사용자들은 자신의 에이전트로 자유롭게 실험하고, 이것저것 시도하고, 실수하고, 한계를 시험할 수 있었으며, 발생할 수 있는 최악의 상황은 깨끗한 상태에서 재시작하는 것뿐이었습니다. 진정한 격리 (isolation)는 제약인 동시에 촉진제 (enabler)라는 사실이 밝혀졌습니다.

제대로 수행하는 데 드는 비용

오버헤드(overhead)에 대해 솔직하게 말씀드리겠습니다. 모든 프록시 계층(proxy layers)과 7개의 격리 경계(isolation boundaries)를 갖춘 개별 격리 컨테이너(isolated container)에서 각 에이전트를 실행하는 것은, 공유 인프라(shared infrastructure)에서 에이전트를 실행하는 것보다 세션당 비용이 대략 2.5배 더 많이 듭니다. 이는 실제 비용 문제입니다.

하지만 저는 이것이 작은 대가라고 생각합니다. 멀티 테넌트(multi-tenant) AI 시스템에서의 단 한 번의 데이터 유출은 단순히 관련된 사용자들에게만 영향을 미치는 것이 아닙니다. 그것은 제품 카테고리 전체에 대한 신뢰를 무너뜨립니다. 우리는 다른 유형의 SaaS에서도 그런 일이 발생하는 것을 보았습니다. 개인 데이터, 캘린더, 이메일, 음성 메시지를 처리하는 AI 에이전트의 경우, 기준은 더 높아야 합니다.

우리는 샌드박스(sandbox)가 안정화된 이후에 품질 점수(quality scores)를 도입했습니다. 에이전트의 행동, 응답 품질, 도구 사용 패턴(tool usage patterns), 그리고 경계 준수(boundary compliance)를 추적하는 20개 이상의 지표를 사용했습니다. 샌드박스는 우리가 이러한 요소들을 실제로 신뢰할 수 있게 측정할 수 있는 통제된 환경을 제공해 주었습니다.

다른 팀에게 해주고 싶은 말

만약 AI 에이전트가 사용자 데이터와 상호작용하는 무언가를 구축하고 있다면, 첫날부터 샌드박스 처리를 하십시오. 첫 번째 사고가 발생한 후나, 특정 규모에 도달한 후가 아닙니다. 처음부터 시작하십시오.

리팩터링(refactoring) 비용은 시간이 지날수록 커지기만 합니다. 공유 인프라 위에서 구축하는 모든 기능은 나중에 격리를 위해 다시 설계(re-architect)해야 하는 기능이 됩니다. 우리는 비교적 일찍 이 작업을 수행했지만, 그럼에도 모든 것이 망가진 채로 몇 주를 보냈습니다. 더 오래 기다리는 팀은 훨씬 더 큰 어려움을 겪게 될 것입니다.

규칙(rules)과 프롬프트(prompts)는 보안이 아닙니다. 그것들은 컨텍스트 윈도우(context windows)의 길이에 따라 유효 기간이 결정되는 제안 사항일 뿐입니다. 진정한 격리(isolation)란 누군가가 에이전트에게 무엇을 요청하든 상관없이, 에이전트가 물리적으로 접근해서는 안 되는 것에 접근할 수 없음을 의미합니다.

이것이 바로 우리가 Amplify에서 구축하고 있는 것입니다. 사용자의 메신저 내에서 상주하며 이메일 및 캘린더 관리부터 음성 메모 및 미디어 생성에 이르기까지 실제 업무를 처리하는 개인용 AI 비서입니다. 모든 클라이언트는 7개의 보호 계층을 갖춘 자신만의 격리된 환경을 할당받습니다. 에이전트는 당신의 업무, 선호도, 연락처를 알고 있지만, 다른 사람의 정보는 알지 못합니다.

우리는 OpenClaw를 기반으로 Amplify를 구축했습니다. 만약 에이전트 격리 (agent isolation) 또는 멀티 테넌트 AI 아키텍처 (multi-tenant AI architecture)를 연구 중이라면, 이 프레임워크와 우리의 접근 방식이 좋은 시작점이 될 것입니다.

Yevhen Fychak은 Amplify의 CTO이자 공동 창립자입니다. 그는 AI 제품 구축과 그 이면에 담긴 엔지니어링 결정에 대해 글을 씁니다.