좋은 에이전트는 똑똑한 답변만 잘하는 존재가 아니다. 실제로는 파일을 읽고, 명령을 실행하고, 외부 시스템과 통신하고, 중간 상태를 남기며 일을 끝낸다. 바로 이때부터 문제가 시작된다. 말로만 똑똑한 모델은 귀엽지만, 셸과 파일시스템과 네트워크를 가진 모델은 갑자기 공구함을 손에 쥔 신입 직원이 된다. 일을 잘할 수도 있지만, 작업장이 정리되지 않았다면 사고도 빠르게 커진다.
실행 환경 설계는 이 작업장을 만드는 일이다. 에이전트에게 무엇을 시킬지보다 먼저, 어디에서 일하게 할지를 정하는 일이다. 이 질문이 빠지면 자동화는 곧 위험이 된다.
실행 환경은 왜 따로 설계해야 하는가
많은 팀이 에이전트를 처음 붙일 때는 모델과 프롬프트, 도구 연결부터 생각한다. 하지만 운영에 들어가면 훨씬 현실적인 질문들이 튀어나온다. 이 에이전트는 어디까지 파일을 읽을 수 있는가. 어떤 명령까지 실행할 수 있는가. 인터넷은 자유롭게 나갈 수 있는가. 세션이 끊기면 이전 상태를 어떻게 이어받는가. 실패했을 때 어떤 흔적이 남는가.
이 질문들은 모두 모델 바깥의 문제다. 다시 말해 실행 환경의 문제다.
실행 환경을 대충 두면 흔히 이런 일이 벌어진다.
작업 디렉터리 바깥의 파일을 건드린다.
필요 없는 네트워크 요청으로 데이터가 새 나간다.
긴 작업 도중 상태가 섞여 다음 실행이 이상해진다.
같은 요청인데 매번 다른 결과가 나온다.
실패 원인을 재현하지 못한다.
프롬프트에 "조심해", "민감한 파일은 읽지 마", "삭제하지 마"라고 써두는 것만으로는 충분하지 않다. 그 문장은 규칙 설명일 뿐, 강제 장치가 아니다. 실제 제품에서는 규칙보다 경계가 먼저다.
에이전트는 무대 위에서 일하고, 실행은 백스테이지에서 일어난다
실행 환경을 이해할 때 유용한 구분이 하나 있다. 오케스트레이션과 실행은 다르다는 점이다. 오케스트레이션은 에이전트가 어떤 순서로 생각하고, 어떤 도구를 고를지 조정하는 층이다. 반면 실행은 그 도구가 실제로 어디서 돌아가고, 어떤 자원에 접근하는지 결정하는 층이다. OpenAI의 샌드박스 가이드도 이 둘을 분리해서 보라고 설명한다.1
이 구분이 중요한 이유는 간단하다. 계획과 행동을 같은 공간에 무방비로 놓으면, 에이전트의 실수가 곧바로 시스템 실수로 번지기 때문이다. 예를 들어 에이전트가 "테스트를 돌려보자"라고 판단하는 것 자체는 오케스트레이션의 일이다. 하지만 그 테스트가 호스트 머신에서 실행되는지, 격리된 샌드박스에서 실행되는지는 실행 환경의 일이다. 후자가 허술하면, 사소한 판단 하나가 예상 밖의 파일 수정이나 네트워크 송신으로 이어질 수 있다.
좋은 하네스는 이 둘을 섞지 않는다. 모델은 일의 순서를 정하되, 실제 행동은 제한된 런타임 안에서만 일어나게 한다. 쉽게 말해 에이전트는 지시를 내리는 감독이고, 실제 망치질은 안전모를 쓴 작업자가 울타리 안에서만 하게 만드는 셈이다.
런타임은 에이전트의 작업장이다
실행 환경 설계에서 가장 먼저 정해야 할 것은 런타임이다. 런타임은 에이전트가 실제로 명령을 실행하고, 파일을 읽고, 코드를 돌리는 작업장이다. 이 작업장은 크게 세 가지 성격으로 나뉜다.
첫째는 로컬 런타임이다. 개발자의 컴퓨터나 내부 서버에서 직접 실행하는 방식이다. 시작이 빠르고 디버깅이 쉽다. 하지만 호스트 환경과 너무 가까우면 사고 반경도 커진다.
둘째는 격리된 컨테이너 런타임이다. Docker나 Kubernetes 기반 샌드박스처럼 작업 공간을 분리해서 실행하는 방식이다. OpenSandbox나 Agent Sandbox 같은 프로젝트는 바로 이런 층을 에이전트용 실행 계층으로 제공한다.23
셋째는 더 강한 격리 런타임이다. gVisor, Kata Containers, Firecracker microVM 같은 기술은 일반 컨테이너보다 한 단계 더 강한 분리를 제공한다. 신뢰할 수 없는 코드나 멀티테넌트 환경에서는 이런 선택이 특히 중요하다.24
여기서 중요한 것은 "무조건 가장 강한 것이 최고"라는 단순한 답이 아니라, 위험도에 맞는 경계를 고르는 것이다. 문서 요약 에이전트와 임의 코드를 생성·실행하는 코딩 에이전트는 같은 작업장을 쓰면 안 된다. 전자는 읽기 중심의 비교적 좁은 환경이면 되지만, 후자는 파일시스템·프로세스·네트워크를 모두 제어할 수 있는 안전장치가 필요하다.
샌드박스는 불편함이 아니라 자유의 조건이다
샌드박스는 에이전트를 불신해서 가두는 감옥이 아니다. 오히려 안심하고 더 많이 자동화하기 위한 울타리다. Anthropic은 Claude Code의 샌드박싱에서 파일시스템 격리와 네트워크 격리가 함께 있어야 의미가 있다고 설명한다. 파일만 막고 네트워크를 열어두면 유출이 가능하고, 네트워크만 막고 파일 경계를 풀어두면 민감한 로컬 자원에 닿을 수 있기 때문이다.5
이 원칙은 아주 실용적이다. 샌드박스가 없으면 모든 행동에 일일이 사람 승인을 걸 수밖에 없다. 그러면 안전은 조금 오를지 몰라도, 승인 피로가 쌓여 결국 아무 버튼이나 누르게 된다. 반대로 샌드박스가 있으면 울타리 안의 반복 작업은 자동으로 돌리고, 울타리 밖으로 나가려는 행동만 멈추게 할 수 있다. 그 순간 자동화는 비로소 쓸 만해진다.
좋은 샌드박스는 보통 다음 네 가지를 함께 갖춘다.
실행 범위가 명확하다.
허용된 파일 경로와 금지된 경로가 구분된다.
네트워크 출구가 통제된다.
위반 시도가 로그로 남는다.
이 네 가지가 빠지면 샌드박스는 이름만 샌드박스가 되기 쉽다. 벽은 있는데 문이 다 열려 있는 창고와 비슷하다.
파일 시스템은 가장 넓고 가장 조용한 권한이다
파일시스템 접근은 많은 팀이 가장 늦게 진지하게 다루는 권한이다. 하지만 실무에서는 대개 제일 먼저 사고를 낸다. 브라우저 자동화나 외부 API 호출은 눈에 잘 띈다. 반면 파일 읽기와 쓰기는 조용하다. 그래서 더 위험하다.
에이전트에게 파일시스템을 열어줄 때는 "읽을 수 있나?"와 "쓸 수 있나?"를 반드시 나눠야 한다. 둘은 완전히 다른 권한이다. 읽기는 정보 노출의 문제이고, 쓰기는 상태 훼손의 문제다. 둘을 한 덩어리로 열면 컨텍스트 오염과 데이터 손상이 동시에 일어난다.
가장 실용적인 기본 구조는 작업별 전용 디렉터리를 주는 것이다. 예를 들어 하나의 작업에 대해 inputs, workspace, outputs, logs, checkpoint를 분리하는 방식이 좋다.6
inputs는 읽기 전용이다. 에이전트가 받은 원본 자료다.workspace는 자유 작업 구역이다. 임시 파일과 실험이 여기서 일어난다.outputs는 최종 결과물 위치다. 중간 산출물과 섞이면 안 된다.logs는 에이전트의 행동 기록이다.checkpoint는 중단 후 이어가기 위한 상태 저장 공간이다.
이 구조의 장점은 단순하다. 사고가 나도 범위가 좁다. 작업이 끝나면 정리가 쉽다. 무엇이 입력이고 무엇이 결과인지 헷갈리지 않는다. 그리고 무엇보다, 에이전트가 스스로의 작업장을 이해하기 쉬워진다. 에이전트도 어질러진 책상에서는 자꾸 엉뚱한 서랍을 연다.
또 하나 중요한 원칙은 입력과 작업 공간을 분리하는 것이다. 입력 파일을 수정 가능하게 두면 같은 작업을 다시 돌렸을 때 재현이 안 된다. 입력은 읽기 전용, 작업은 별도 쓰기 영역. 이 단순한 분리만 지켜도 운영 난도가 크게 내려간다.6
경로 검증은 문자열 검사가 아니라 경계 검증이다
파일 접근을 통제할 때 흔히 하는 실수가 있다. .. 나 / 같은 문자열만 막으면 안전하다고 생각하는 것이다. 실제로는 심볼릭 링크, 상대경로 우회, 대소문자 차이, 마운트 포인트 같은 문제 때문에 경계가 쉽게 뚫린다. 그래서 경로 검증은 "이 문자열이 예뻐 보이느냐"가 아니라, 해석된 실제 경로가 허용된 루트 안에 있느냐를 보는 방식이어야 한다.7
여기서 한 걸음 더 나가면, 아예 원시 파일 명령을 모델에게 직접 주지 않고 read_file, write_output, list_workspace처럼 목적이 분명한 도구 인터페이스로 감싸는 편이 낫다. 그러면 경계 검증과 권한 체크를 도구 층에서 일관되게 처리할 수 있다. 에이전트는 "어떤 파일 경로든 다뤄도 되는 존재"가 아니라, "정해진 작업 공간 안에서만 목적별 도구를 쓰는 존재"가 된다.
네트워크는 기본 허용이 아니라 기본 차단이 맞다
실행 환경에서 파일시스템만큼 중요한 것이 네트워크다. 많은 사고가 "로컬 파일을 읽었다"에서 끝나지 않고 "그 내용을 어딘가로 보냈다"에서 커진다. 그래서 네트워크는 별도 설계 항목이어야 한다.
OpenAI Codex 문서는 기본값으로 네트워크를 막고, 쓰기 권한도 활성 워크스페이스로 제한하는 구성을 설명한다.8 이 기본값은 매우 상식적이다. 에이전트가 처음부터 인터넷 전체를 자유롭게 나갈 이유는 거의 없다. 필요한 경우에만 좁게 열어야 한다.
네트워크 설계에서 유용한 기준은 목적별 allowlist다. 예를 들면 공식 패키지 저장소, 특정 API 호스트, 내부 문서 서버처럼 필요한 목적지만 허용한다. Anthropic의 샌드박스 런타임도 허용 도메인과 차단 도메인을 분리하고, 필요시 프록시를 통해 외부 통신을 통제하는 방식을 제시한다.5
여기서 중요한 것은 두 가지다.
첫째, 네트워크는 단순히 연결 여부만이 아니라 어디로 나가는지의 문제다. 모든 아웃바운드가 같은 위험도를 갖지 않는다.
둘째, 비밀값은 샌드박스 안에 오래 머물게 하지 않는 편이 좋다. 최근 에이전트 런타임 논의에서는 실제 API 키를 샌드박스 안에 넣는 대신, 프록시나 중개 계층이 요청 시점에만 인증 정보를 붙이는 패턴이 강조된다.9 에이전트가 실수하거나 프롬프트 인젝션을 당해도, 가져갈 비밀 자체가 없게 만드는 방식이다.
쉽게 비유하면 이렇다. 열쇠를 작업자 주머니에 넣어주는 대신, 문지기가 문 앞에서 신분을 확인하고 한 번만 열어주는 구조다. 귀찮아 보여도 훨씬 안전하다.
로컬 환경과 클라우드 환경은 무엇이 다른가
실행 환경은 어디에 두느냐에 따라 운영 감각이 달라진다.
로컬 환경은 개발 속도가 빠르다. 디버깅이 쉽고, 현재 작업 중인 저장소와 연결하기도 편하다. 하지만 호스트 파일, SSH 키, 브라우저 세션, 개발용 비밀값이 같은 공간에 있는 경우가 많다. 에이전트에게 가장 위험한 놀이터가 될 수도 있다.
클라우드나 원격 샌드박스는 초기 구성이 조금 번거롭지만, 경계가 더 선명하다. 세션별로 깨끗한 환경을 띄우고, 작업이 끝나면 폐기할 수 있다. OpenSandbox처럼 Docker와 Kubernetes 기반으로 샌드박스를 만들고, 필요하면 강한 격리 런타임을 조합하는 접근은 바로 이 장점을 활용한다.2
그렇다고 무조건 클라우드가 답은 아니다. 개인 개발자나 초기 팀은 로컬에서 시작하는 경우가 많다. 이때 중요한 것은 "로컬이냐 클라우드냐"보다 얼마나 분리했느냐다. 로컬에서도 전용 작업 디렉터리, 네트워크 제한, 민감 경로 차단, 별도 자격증명, 임시 세션 폐기 정책을 갖추면 훨씬 안전해진다. 반대로 클라우드라도 모든 권한이 한 덩어리면 여전히 위험하다.
상태 저장은 편의 기능이 아니라 재현성의 핵심이다
에이전트가 한 번의 짧은 작업만 수행한다면 상태 저장은 대수롭지 않아 보일 수 있다. 하지만 실제 업무에서는 그렇지 않다. 코딩 에이전트는 중간 빌드 산출물과 테스트 결과를 남긴다. 분석 에이전트는 이전 쿼리와 생성 파일을 이어받는다. 리서치 에이전트는 읽은 자료 목록과 근거 메모를 누적한다. 상태는 곧 작업의 맥락이다.
문제는 상태가 잘 저장되지 않거나, 너무 많이 뒤섞여 저장될 때다. 그러면 재현이 안 된다. 어제는 되던 작업이 오늘은 안 된다. 실패한 이유도 찾기 어렵다. 운영에서 이것만큼 사람을 지치게 하는 일이 없다.
상태 저장에서 먼저 구분해야 할 것은 세션 상태와 영속 상태다.
세션 상태는 작업이 진행되는 동안만 필요한 정보다. 임시 파일, 캐시, 작업 중간값, 현재 루프의 계획이 여기에 속한다.
영속 상태는 다음 세션에서도 이어져야 하는 정보다. 체크포인트, 검증된 결과물, 승인된 설정, 장기 메모, 감사 로그가 여기에 속한다.
이 둘을 섞으면 문제가 생긴다. 임시 실패 흔적이 장기 기억처럼 남기도 하고, 반대로 꼭 남겨야 할 결과가 세션 종료와 함께 사라지기도 한다. 그래서 상태 저장 설계는 "무엇을 저장할까"보다 먼저 "무엇이 얼마나 오래 살아야 하나"를 정하는 일이다.
체크포인트는 긴 작업의 안전벨트다
긴 작업일수록 중간 저장 지점이 필요하다. 코드를 수정하던 에이전트가 테스트 12개 중 10개를 통과시킨 상태에서 멈췄다고 해보자. 체크포인트가 없다면 다음 실행은 처음부터 다시 시작한다. 그 과정에서 이미 고친 파일을 다시 건드리고, 이전 상태와 충돌할 수도 있다.
반대로 체크포인트가 있으면 "어디까지 성공했고, 다음에 무엇을 이어야 하는지"가 남는다. 최근 에이전트 상태 관리 패턴들도 실행 컨텍스트와 체크포인트 복구를 별도 관리하는 이유가 여기에 있다.10
물론 모든 것을 다 저장하면 안 된다. 실패한 추론의 흔적, 과도한 로그, 의미 없는 임시 파일까지 무한정 남기면 상태 저장소는 곧 쓰레기 창고가 된다. 좋은 체크포인트는 현재 작업을 이어가는 데 필요한 최소 정보만 남긴다.
예를 들면 이런 것들이다.
현재 작업 ID와 단계
읽은 입력의 버전 정보
생성된 출력 파일 목록
통과/실패한 검증 결과
재시도 가능한 지점과 중단 사유
이 정도면 다시 이어가기 충분하고, 과거의 잡음까지 끌고 오지는 않는다.
재현 가능성은 디버깅의 출발점이다
실행 환경 설계에서 자주 잊히는 덕목이 재현 가능성이다. 하지만 운영에서는 거의 전부라고 해도 과장이 아니다. 문제를 고치려면 같은 조건에서 다시 돌려볼 수 있어야 한다.
재현 가능성을 높이려면 적어도 다음 요소가 기록되어야 한다.
어떤 이미지나 런타임을 썼는가
어떤 파일을 입력으로 받았는가
어떤 네트워크 정책이 적용되었는가
어떤 명령이 어떤 순서로 실행되었는가
어떤 상태 스냅샷에서 시작했는가
Microsoft의 Agent Governance Toolkit이 운영체제 커널, 서비스 메시, SRE의 아이디어를 에이전트 런타임에 가져오려는 이유도 결국 여기에 닿아 있다. 에이전트를 자율성만으로 다루지 말고, 정책과 관측과 복구가 가능한 운영 시스템으로 다루자는 것이다.4
재현 가능성은 멋진 기능이 아니다. 밤 11시에 장애가 났을 때 팀을 살리는 기능이다.
안전한 실행 환경의 기본 원칙
이쯤에서 실행 환경 설계를 한 줄 규칙으로 줄여보자. 에이전트에게 넓은 세상을 주지 말고, 좁고 선명한 작업장을 주라. 이 원칙을 실제로 적용하면 다음과 같은 기본 원칙으로 정리된다.
기본값은 최소 권한이다
처음부터 읽기, 쓰기, 삭제, 네트워크, 외부 도구를 모두 열지 않는다. 읽기 전용에서 시작하고, 필요한 작업에 맞춰 점진적으로 넓힌다. 가장 많이 하는 실수는 "일단 다 열고 막히면 나중에 줄이자"인데, 운영에서는 거의 반대로 가야 한다.
작업 단위로 공간을 나눈다
에이전트마다, 가능하면 작업마다 전용 디렉터리와 세션을 준다. 하나의 넓은 공용 작업장보다 여러 개의 좁은 작업장이 안전하고 디버깅도 쉽다.
입력, 작업, 출력, 로그를 분리한다
원본 자료와 임시 상태와 최종 결과를 섞지 않는다. 이 분리만으로도 재현성과 감사 가능성이 크게 올라간다.6
네트워크는 목적지 기준으로 연다
인터넷 전체 허용이 아니라, 필요한 도메인과 프로토콜만 허용한다. 가능하면 프록시를 거치고, 비밀값은 샌드박스 바깥에서 관리한다.59
위반은 조용히 지나가면 안 된다
차단만 하고 끝내지 말고, 무엇이 왜 거부되었는지 로그를 남겨야 한다. 에이전트도 운영자도 경계를 배워야 한다.
상태는 저장하되, 쓰레기는 기억하지 않는다
다시 시작하는 데 필요한 정보만 저장하고, 노이즈는 버린다. 기억이 많다고 좋은 것이 아니라, 다시 일을 시작할 수 있을 만큼 정확하면 된다.
실행 환경은 성능보다 먼저 설계해야 한다
에이전트 시스템을 만들다 보면 사람들은 금방 이런 질문을 한다. 어떤 모델이 더 잘 코드를 쓰는가. 어느 프레임워크가 더 편한가. 어떤 프롬프트가 덜 흔들리는가. 물론 중요하다. 하지만 실행 환경이 허술하면 이런 차이는 오래 가지 못한다.
작업장이 정리되지 않은 공방에서는 장인이 들어와도 공구를 찾다가 하루를 보낸다. 반대로 작업장이 잘 설계된 곳에서는 아주 뛰어난 장인이 아니어도 꽤 안정적인 결과를 낼 수 있다. 에이전트도 마찬가지다.
안전하고 재현 가능한 실행 공간이 없으면 자동화는 생산성 도구가 아니라 사고 증폭기가 된다. 반대로 실행 환경이 잘 설계되면 에이전트는 더 자유롭게 일할 수 있고, 사람은 더 적게 불안해한다. 그것이 좋은 하네스의 시작이다.
다음 장에서는 이 실행 환경 안에서 에이전트가 실제로 손에 쥐는 것, 즉 도구 인터페이스를 어떻게 설계해야 하는지 더 구체적으로 살펴보자. 작업장이 준비되었다면, 이제는 공구를 어떻게 건네줄 차례다.
참고
2GitHub - alibaba/OpenSandbox: Secure, Fast, and Extensible Sandbox runtime for AI agents. · GitHub
4Introducing the Agent Governance Toolkit: Open-source runtime security for AI agents
5Making Claude Code more secure and autonomous with sandboxing
6Filesystem for AI Agents: Structure, Permissions, and Safety by Design
7How to give AI agent file system access
8Agent approvals & security - Codex | OpenAI Developers
9Advanced Sandboxing Techniques for Secure AI Agent Deployment
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.