들어가며

우리 회사 구매팀이 거래처 스무 곳에서 받은 단가표 엑셀 파일과 계약서 초안을 모아 AI 에이전트에게 비교 분석을 맡겼다고 가정해봅시다. 사내 규정을 찾아 답해주던 챗봇과 달리, 이 에이전트는 직접 파이썬 코드를 짜서 시트를 합치고 수식을 검증한 뒤 요약 차트와 보고서 파일을 만들어냅니다. 사람 손으로 이틀 걸리던 취합 업무가 몇 분 만에 끝나니 현업 반응도 무척 좋습니다.

하지만 적용 범위를 넓히려는 순간 현실적인 걱정이 뒤따릅니다. 에이전트가 코드를 돌리는 컴퓨터 안에 다른 부서 자료가 함께 들어 있지는 않은지, 생성된 스크립트가 원본 폴더를 덮어쓰거나 외부로 단가표를 보내버릴 가능성은 없는지 따져 봐야 합니다. 개발팀이나 공급사가 “샌드박스 환경에서 돌아가니 안전하다”고 설명하더라도, 그 말만으로는 무엇이 막혀 있고 무엇이 열려 있는지 판단하기 어렵습니다.

외부 문서에 숨은 악성 지시를 경계하거나 화면 조작 도구에 결재 단계를 두더라도, 직접 코드를 실행하는 에이전트의 위험은 다 다루기 어렵습니다. 이번 글에서는 에이전트가 실제로 일하는 실행 환경으로 시선을 옮깁니다. 런타임과 샌드박스의 차이부터 격리 방식의 선택, 파일·네트워크·자격증명·작업 수명 경계까지 경영진이 챙겨야 할 기준을 짚어보겠습니다.

작업실과 출입 통제는 다릅니다: 런타임, 승인, 샌드박스 구분하기

보고서에서 흔히 섞여 쓰이는 런타임, 도구 권한, 샌드박스는 외부 실무자에게 회사 일을 맡기는 상황에 비유하면 구분하기 쉽습니다. 런타임은 책상과 컴퓨터를 갖춰 놓은 작업실 자체입니다. 에이전트는 이곳에서 파이썬이나 셸 같은 프로그램을 돌릴 수 있습니다. 작업실이 있어야 계산을 하고 문서를 만들 수 있지만 방을 배정하는 일과 출입을 통제하는 일은 다릅니다. 문이 열려 있고 사내 서류함 열쇠가 놓여 있다면 작업실 안에서도 회사 어디든 손을 뻗을 수 있습니다.

작업실 안의 행동을 제어하는 장치는 작동 방식에 따라 세 가지로 나뉩니다. 프롬프트에 “지정된 폴더만 열람하라”고 적는 것은 모델의 협조에 기대는 업무 지침이라, 모델이 문맥을 오해하거나 외부 문서의 문구에 속으면 깨질 수 있습니다. 에이전트 애플리케이션이 집행하는 도구 권한과 결재 승인은 다릅니다. 모델의 뜻과 상관없이 도구 호출 전에 대상과 인자를 검사해 실행을 막거나 사람에게 묻는 실제 통제 장치입니다. 다만 업무 효율을 위해 자동 승인을 켜두거나 범위가 넓은 셸 명령 실행을 한 번 허가하고 나면, 그 명령이 실행된 뒤 안에서 다른 파일을 읽고 하위 프로그램을 깨우는 과정까지 결재 단계가 따라가기는 어렵습니다. 이때는 운영체제나 하이퍼바이저가 강제하는 샌드박스가 필요합니다. OpenAI Codex의 샌드박스 문서 와 Anthropic의 샌드박스 환경 가이드 도 권한 승인과 격리를 서로 보완하는 통제로 설명합니다. 권한 승인은 도구 실행 여부와 사전 확인을 결정하고 격리는 일단 실행된 명령이 접근할 수 있는 범위를 제한합니다.

샌드박스를 적용해도 작업 폴더 밖 접근이 모두 저절로 차단되지는 않습니다. 에이전트의 구성 요소가 전부 같은 경계 안에 들어가는 것도 아닙니다. 샌드박스는 관리자가 금지하도록 설정한 파일·네트워크·프로세스 접근만 거부합니다. 접속 시점 기준 Claude Code의 샌드박스 문서 를 보면, 운영체제 경계는 셸 명령과 그 명령이 시작한 하위 프로세스에 적용됩니다. 내장 파일·웹 도구는 별도의 권한 규칙을 따릅니다. 로컬 MCP 서버나 훅 같은 별도 프로세스는 경계 밖에서 사용자 권한으로 실행됩니다.

에이전트의 핵심 프로세스를 가상 머신이나 컨테이너 안에 넣었더라도, 외부 도구나 사내 연결 서버가 그 밖의 다른 환경에서 돌아간다면 전체 애플리케이션이 하나로 격리되었다고 볼 수 없습니다. 도입을 검토할 때는 샌드박스를 쓰는지만 묻지 말고 모델 루프와 셸, 파일 도구, 외부 연결 서버가 각각 어느 환경에서 누구의 권한으로 실행되는지부터 물어야 합니다.

칸막이 방부터 별채까지: 컨테이너와 가상 머신은 무엇을 막아줄까

코드가 돌아갈 실행 공간을 격리할 때 기술팀은 보통 일반 컨테이너, 사용자 공간 커널, 가상 머신(VM) 또는 마이크로VM 중에서 선택지를 검토합니다. Docker 같은 일반 리눅스 컨테이너 는 한 건물 안에 가벽을 세워 만든 칸막이 방과 같습니다. 프로세스가 보는 시야와 자원 한도를 나누어 빠르게 독립된 작업 환경을 만들 수 있고 기존 개발 도구와의 호환성도 높습니다. 다만 건물 바닥의 핵심 설비에 해당하는 호스트 운영체제 커널을 여러 방이 공유하므로, 호스트 폴더를 넓게 연결하거나 과도한 관리 권한을 부여하면 격리 효과가 약해집니다.

gVisor 같은 사용자 공간 커널 방식 은 이 칸막이 방 앞에 전담 통역사를 세우는 구조입니다. 사용자 공간의 애플리케이션 커널이 중간에서 시스템 요청을 받아 처리합니다. 에이전트가 실행한 프로그램이 호스트 커널에 직접 요청을 보내지 못하게 해 호스트 커널이 직접 노출되는 면적을 줄이는 겁니다. 일반 가상 머신보다 가볍게 경계를 강화할 수 있지만 따로 구현되지 않은 일부 커널 기능은 쓸 수 없으니, 업무용 라이브러리가 정상 작동하는지 미리 점검해야 합니다.

가상 머신과 Firecracker 같은 마이크로VM 은 작업 공간마다 별도의 게스트 커널을 두어 본관 옆에 작은 별채를 따로 지어주는 방식입니다. 커널 수준까지 분리하면서도 마이크로VM은 불필요한 장치 에뮬레이션을 줄여 기동 속도와 자원 효율을 높이는 데 초점을 맞췄습니다. 대신 게스트 이미지 관리와 패치, 네트워크와 저장소 연결, 내부 로그 가시성까지 운영팀이 챙겨야 할 관리 요소가 늘어납니다.

이 세 가지를 절대적인 보안 등급표로 삼아 컨테이너는 무조건 위험하고 가상 머신은 무조건 안전하다고 단정해서는 안 됩니다. Firecracker 문서도 가상화 경계가 침해될 가능성에 대비해 2차 방어 계층을 두며 자체 네트워크 트래픽 필터링은 수행하지 않는다고 밝힙니다. gVisor 보안 가이드 역시 샌드박스가 허용된 네트워크 서비스나 API 경로의 보안 설계를 대신해 주지 않는다고 명시합니다. 실무에서는 호환성과 시작 지연, 동시 실행 규모, 운영 인력 여건을 따져 격리 방식을 고릅니다. 어느 방식을 쓰든 방 안에 넣어준 자료와 열어둔 연결 통로는 따로 통제해야 합니다.

벽 안에서 벌어지는 일: 파일 읽기, 통신 출구, 그리고 작업 수명

격리된 작업 공간을 만들었다면 그 안에서 허용할 파일, 네트워크, 수명 규칙을 구체적으로 정해야 합니다. 파일 통제에서는 쓰기 제한과 읽기 제한을 따로 결정해야 합니다. 작업 폴더 밖으로 쓰기를 막으면 원본 문서 훼손이나 설정 변조는 줄일 수 있습니다. 하지만 읽기 범위가 넓게 열려 있거나 환경변수가 그대로 상속되면, 에이전트가 다른 부서 자료나 설정 파일 속 인증 정보를 읽을 수 있습니다. 에이전트가 실행한 스크립트가 내부에서 또 다른 하위 프로그램을 잇달아 깨울 수 있으므로, 최초 명령 호출뿐 아니라 그 하위 프로세스들에도 같은 파일·네트워크 제한이 이어지는지 살펴야 합니다. 원본 저장소를 넓게 연결하기보다, 해당 업무에 필요한 입력 파일 사본만 넣어주고 원본 수정이 필요 없다면 읽기 전용으로 두며 임시 작업 경로와 반출용 폴더를 분리하는 편이 안전합니다.

네트워크 출구도 기본 차단 여부부터 봐야 합니다. 다만 특정 도메인만 허용 목록에 넣었다고 해서 반출 위험이 끝나는 것은 아닙니다. Anthropic이 2026년 5월 공개한 제품별 격리 사례 를 보면 도메인 허용과 계정·기능 통제가 왜 다른지 알 수 있습니다. 공급사 설명에 따르면 Cowork 환경은 가상 머신 안에서 허용된 도메인으로만 통신하도록 제한되어 있었습니다. 그런데 필수 연결 대상인 자사 API 도메인의 파일 업로드 기능과 외부 공격자 계정이 악용되면서 가상 머신을 탈출하지 않고도 자료가 외부 계정으로 넘어갈 수 있었습니다. Anthropic은 이후 프록시가 현재 세션에 맞는 인증 토큰인지 함께 검사하도록 수정했다고 밝혔습니다.

목적지 주소를 열어둘 때는 어느 계정으로 어떤 API 기능까지 호출할 수 있는지도 함께 살펴야 합니다. 반대로 샌드박스의 외부 인터넷을 완전히 차단해도 데이터가 방 밖으로 나가는 통로는 남습니다. 외부 모델 API를 쓰는 구성에서는 에이전트가 읽은 파일 내용과 도구 실행 결과가 모델 입력으로 전송될 수 있습니다. 작업 끝에 만든 결과 파일도 반출 통로를 거쳐 밖으로 나갈 여지가 있습니다. 이 두 경로는 샌드박스의 네트워크 제한만으로 자동 차단되지 않기 때문입니다.

작업이 끝난 뒤의 공간 분리와 수명 관리도 중요합니다. 앞선 업무에서 풀어놓은 파일이나 메모리가 다음 사용자나 다른 거래처 작업에 섞이지 않으려면 작업 단위로 실행 공간을 나눠야 합니다. E2B가 공개한 ClickUp의 도입 사례 에서 실제 운영 흐름을 볼 수 있습니다. 공급사에 게재된 이 사례에서 ClickUp의 Brain²는 데이터 분석이나 파일 처리 요청이 들어올 때, 사전 템플릿 기반의 개별 마이크로VM 샌드박스를 띄웁니다. 거기에 파일을 올리고 생성된 코드를 실행해 차트나 문서를 만든 뒤 대화창으로 결과를 돌려줍니다. 짧은 작업은 종료 후 즉시 정리하고 일부 긴 작업만 일시정지했다가 재개하는 구조입니다.

작업별 환경을 운영할 때는 무한 루프나 과도한 연산으로 비용이 새지 않도록 CPU·메모리·실행 시간 상한을 걸어야 합니다. 스크립트가 깨운 하위 프로세스까지 종료 시 함께 회수되는지도 봐야 합니다. 대화가 끝났다는 사실과 컴퓨트 종료, 그리고 산출물 삭제는 서로 다른 절차입니다. OpenAI Agents API의 수명 주기 문서 와 파일·산출물 문서 가 구분하듯, 자체 호스팅 환경에서는 세션 삭제와 별개로 컴퓨트 자원을 직접 정지해야 합니다. 호스팅 환경에서 생성된 산출물 사본은 실행 환경이 만료된 뒤에도 남을 수 있어 보관 기간과 삭제 책임을 따로 정해야 합니다.

방 밖의 열쇠와 반출 문턱: 자격증명 중계와 업무 시스템 권한

에이전트가 파일 분석을 넘어 사내 데이터베이스를 조회하거나 코드 저장소와 ERP에 접근하려면 인증 키가 필요합니다. 이때 마스터 API 키를 샌드박스 안 환경변수나 설정 파일에 그대로 넣어두면, 방 안에서 실행되는 생성 코드가 그 키를 직접 읽을 수도 있습니다. 그래서 OpenAI Agents API의 샌드박스 보안 가이드 는 애플리케이션 키를 실행 환경 밖에 두라고 안내합니다. 호스팅 환경에서는 비밀 대체값과 프록시를 쓰거나 샌드박스 바깥에서 원격 MCP 도구를 연결하는 방식입니다. 자체 호스팅 환경이라면 비밀값을 중계하는 계층을 따로 둡니다. Anthropic의 샌드박스 엔지니어링 설명 에서도 웹 세션의 git 인증 키를 샌드박스 밖에 두고 프록시가 지정된 브랜치로만 푸시되는지 검사한 뒤 실제 토큰을 붙인다고 밝힙니다.

비밀 키 원문을 중계 계층 뒤에 숨기는 것과 에이전트에게 허용할 업무 행위를 제한하는 것은 별개의 문제입니다. 중계 계층에 구매팀 공용 계정을 연결해 두고 구매팀이 할 수 있는 모든 ERP 발주 등록이나 데이터 수정 요청을 그대로 통과시킨다고 해 봅시다. 에이전트가 잘못된 판단을 내리면 샌드박스를 탈출하지 않고도 정상 인증을 거쳐 실제 거래가 반영됩니다. 실행 환경을 닫아도 이미 외부 업무 시스템에 기록된 변경은 저절로 되돌아가지 않습니다.

따라서 도입 초기의 구매팀 단가 비교 업무라면 입력 사본을 분석해 비교표를 만드는 샌드박스와, 승인된 발주 초안을 ERP에 등록하는 API 기능을 분리해 설계할 수 있습니다. 전자에는 필요한 파일과 계산 도구만 주고 후자는 중계 시스템이 거래처·금액·문서 버전을 확인한 뒤 담당자 승인을 거치도록 제한하는 식입니다. 샌드박스 안에서 보고서나 코드를 에러 없이 만들었더라도 반출은 또 다른 승인 사안입니다. 예를 들어 Anthropic의 서버 측 코드 실행 도구 가 지정된 출력 폴더에 놓인 파일만 밖으로 캡처해 돌려주듯, 반출 통로를 명시적으로 좁혀야 합니다. 나온 보고서나 코드 변경안을 고객에게 전달하거나 운영 환경에 반영하기 전에는, 민감 정보 혼입 여부와 변경 범위를 사람이 검토하는 절차도 두어야 합니다.

나가며

AI 에이전트에게 업무를 맡기는 일은 결국 우리 회사의 작업 공간과 사내 시스템 연결 통로를 어디까지 내어줄지 정하는 일입니다. 무인 실행이나 적용 확대를 결정하기 전에는 네 가지 경계를 실무진과 함께 짚어 봐야 합니다. 모델 루프와 셸, 파일 도구, 외부 연결 서버 중 무엇이 샌드박스 안에 있고 무엇이 밖에 있는지, 파일 쓰기뿐 아니라 읽기 범위와 허용된 도메인의 계정·기능까지 통제되는지, 외부 API 자격증명을 환경 밖 중계 계층에 두고 실제 업무 변경 권한을 좁혔는지, 그리고 작업 종료 후 컴퓨트 자원과 산출물 사본을 누가 정리하고 검토하는지가 명확해야 합니다.

겉으로 매끄럽게 돌아가는 데모 화면만 보고 전사 확대를 결정하기보다, 입력과 출력이 뚜렷한 좁은 업무 한 구간을 골라 시험용 파일과 계정으로 먼저 검증해 보시기를 권합니다. 정상 업무가 끝나는지에 더해, 허용하지 않은 파일 읽기나 외부 통신이 실제로 거부되는지, 하위 프로세스에도 같은 경계가 적용되는지, 시간 초과나 취소 뒤에 잔여 자원이 남지 않는지도 실행 기록으로 확인하면 유지보수 인력과 운영 비용까지 현실적으로 가늠할 수 있습니다.

우리 조직의 업무 흐름에 맞춰 에이전트에게 어떤 작업 공간을 배정하고 권한과 운영 책임을 어떻게 나눌지 고민하고 계신다면, 언제든 엡실론델타(contact@epsilondelta.ai )로 문의해 주세요. 현업에 필요한 에이전트 설계부터 실행 환경 경계와 운영 기준을 정립하는 과정까지 함께 검토하고 도와드리겠습니다.