코딩 agent(사람 대신 명령을 실행하고 코드를 고치는 AI 도구)는 묻지 않고 움직일 때 가장 쓸모 있습니다. 패키지를 설치하고, 테스트를 돌리고, 설정을 바꾸는 일을 하나하나 승인해야 한다면 속도의 이점이 사라집니다. 문제는 같은 자율성이 개발자 컴퓨터 전체를 위험에 노출한다는 점입니다. Eclipse Foundation이 MIT 라이선스로 관리하는 오픈소스 런타임 Eclipse Enclave는 이 문제를 agent를 묶는 대신 agent가 돌아가는 환경을 묶는 방식으로 풉니다. 명령 하나로 agent 세션마다 컨테이너를 만들고, 보이는 파일과 나갈 수 있는 주소, 쓸 수 있는 비밀값을 따로 정합니다.
권한을 넓힐수록 커지는 피해 범위
개발자 컴퓨터에는 잠금이 풀린 SSH 키, 클라우드 자격 증명, 개인 token(서비스 접근 권한을 증명하는 문자열)이 그대로 놓여 있고 인터넷도 제한 없이 열려 있습니다. 이런 곳에서 agent에 넓은 권한을 주면 위험은 크게 세 가지입니다.
- prompt injection: README 파일, 이슈, 웹 페이지에 숨긴 지시문이 agent를 속여 사용자가 요청하지 않은 일을 시킵니다.
- 자격 증명 노출: agent가 홈 폴더의 키나 API 키에 닿으면 그 값이 밖으로 새어 나갈 수 있습니다.
- agent끼리의 충돌: 한 컴퓨터에서 여러 agent를 함께 돌리면 서로 파일을 덮어쓰거나 패키지 버전을 바꾸고 다른 프로세스를 방해합니다.
Enclave의 설계 원칙은 “agent를 제한하지 말고 샌드박스를 제한하라”는 한 문장으로 요약됩니다. 명령마다 승인을 받게 하면 효율이 사라지고, 모델의 판단을 믿으면 보안이 사라지니 경계는 실행 환경이 맡아야 한다는 판단입니다. Enclave 자체는 agent도, 특정 모델 업체의 포장 도구도 아닙니다. Claude Code, OpenAI Codex CLI, Copilot CLI, OpenCode 같은 agent를 바꿔 끼워 쓰는 샌드박스 관리 도구입니다.
▲ agent 실행 환경의 격리
명령 한 줄로 시작하는 격리 세션
사용 방법은 단순합니다. 프로젝트 폴더로 이동해 enclave를 실행하면 선택한 agent가 설치된 컨테이너 이미지를 만들거나 받아 오고, 현재 폴더만 컨테이너에 연결한 뒤 agent를 자율 실행 모드(권한 확인을 건너뛰는 모드)로 띄웁니다. 처음에는 이미지를 만드느라 시간이 걸리지만 다음부터는 캐시 덕분에 2초 안쪽으로 다시 시작됩니다.
격리가 실제로 작동하는지는 두 가지로 확인할 수 있습니다. agent 안에서 상위 폴더 목록을 보면 연결한 프로젝트 폴더 하나만 보입니다. 허용 목록에 없는 도메인에 접속을 시도하면 주소를 찾지 못해 바로 실패합니다. 그 도메인을 열어야 할 때는 다른 터미널에서 enclave network add-domain 명령으로 추가하면 실행 중인 세션에 곧바로 적용되고, 지우면 다시 막힙니다.
모든 세션이 답하는 네 가지 질문
Enclave의 세션은 네 가지 질문에 답하는 구조입니다.
| 구분 | 질문 | 기본 동작 |
|---|---|---|
| SEE | agent에게 무엇이 보이는가 | 현재 프로젝트 폴더만 읽기·쓰기로 연결, 홈 폴더는 새로 만든 빈 폴더 |
| RUN | 안에서 무엇이 실행되는가 | agent와 Node.js·Maven 같은 개발 런타임을 담은 이미지 |
| REACH | 어디에 접속할 수 있는가 | 허용 목록과 기록을 갖춘 별도 네트워크 게이트웨이 |
| KEEP | 세션이 끝난 뒤 무엇이 남는가 | 실행 환경은 버리고 로그인 정보·기록·설정은 보존 |
파일: 프로젝트 폴더만 보입니다
~/.ssh, ~/.aws, ~/.kube, ~/Documents 같은 민감한 경로는 처음부터 연결하지 않습니다. 프로젝트 폴더는 직접 연결 방식이라 agent가 바꾼 내용이 지연 없이 바로 컴퓨터 디스크에 반영됩니다. 참고할 문서나 다른 저장소가 필요하면 --add-readonly-dir로 읽기 전용으로만 붙일 수 있습니다. 기존에 쓰던 MCP(Model Context Protocol, AI가 외부 도구와 데이터에 연결하는 규약) 서버 설정과 skill을 그대로 쓰고 싶다면 허용된 설정 파일만 복사하는 --host-config-passthrough 옵션이 있습니다.
네트워크: 세 겹의 관문을 차례로 통과합니다
세션마다 따로 붙는 네트워크 게이트웨이가 나가는 통신을 세 단계로 거릅니다.
- DNS 필터: 허용 목록에 있는 도메인 이름만 주소로 바꿔 줍니다.
- 방화벽: IP 주소를 직접 적으면 DNS 단계를 건너뛸 수 있으므로, 앞 단계에서 정상적으로 찾은 IP만 통과시키고 나머지는 모두 버립니다.
- 프록시: 웹 통신(80, 443번 포트)의 HTTP Host 헤더와 TLS SNI(암호화 연결을 시작할 때 밝히는 접속 도메인)를 확인하고, 웹이 아닌 통신은 버립니다.
이렇게 겹치는 이유는 하나만으로는 빈틈이 있기 때문입니다. DNS 필터만 두면 IP를 직접 적은 요청을 놓치고, IP 허용만 두면 CDN처럼 IP 하나에 여러 도메인이 올라간 경우를 구분하지 못합니다. 차단된 요청은 모두 enclave network log로 확인할 수 있습니다.
비밀값: agent에게는 가짜 값만 줍니다
가장 눈여겨볼 부분은 자격 증명 처리 방식입니다. 컨테이너 안의 환경 변수에는 진짜 API 키 대신 무작위로 만든 자리 표시 값이 들어갑니다. agent가 허용된 API 주소로 HTTPS 요청을 보내면 게이트웨이가 전송 도중에 그 값을 진짜 키로 바꿔 넣습니다. 같은 자리 표시 값을 허용되지 않은 주소로 보내면 게이트웨이가 HTTP 403 오류로 막습니다. 진짜 키가 컨테이너 안에 한 번도 들어오지 않으니, prompt injection으로 agent가 속더라도 실제 키를 빼낼 방법이 없다는 설명입니다. GitHub CLI 확장도 같은 방식으로 token을 다룹니다.
남길 것과 버릴 것
매번 로그인하게 하면 아무도 쓰지 않는다는 점도 설계에 반영됐습니다. Claude Code나 Codex의 로그인 정보는 도구별로 한 번만 저장해 모든 프로젝트가 같이 씁니다. 반면 대화 기록, 메모리, 설정, 네트워크 기록은 프로젝트 경로별로 나눠 저장소 바깥에 보관합니다. 그래서 한 프로젝트의 맥락이 다른 프로젝트로 섞이지 않고, Git 저장소에 agent의 작업 흔적이 쌓이지도 않습니다.
데이터를 빼내라는 지시는 어디서 막히나
Codex 세션으로 prompt injection 상황을 흉내 낸 시험이 이 구조를 잘 보여 줍니다. agent에게 저장소의 README 내용을 외부 도메인 주소에 실어 보내라고 지시하자, agent는 파일을 읽고 내용을 인코딩해 요청을 보내려 했습니다. agent 자체는 지시를 따랐지만 목적지가 허용 목록에 없어 게이트웨이에서 연결이 끊겼습니다. 모델이 속지 않기를 기대하는 대신, 속더라도 데이터가 나갈 길이 없게 만든 셈입니다. 별도 터미널에서 enclave network log -f를 켜 두면 이런 허용·차단 기록을 실시간으로 볼 수 있습니다.
▲ 허용 목록 밖 전송의 차단
여러 agent를 나란히 돌리는 방법
격리의 또 다른 쓸모는 병렬 작업입니다. 여러 agent가 같은 폴더와 브랜치를 건드리게 하는 대신, Git worktree(한 저장소에서 브랜치별 작업 폴더를 따로 여는 Git 기능)마다 Enclave 세션을 하나씩 붙이는 방식을 권합니다. 세션에 --name으로 이름을 붙여 백그라운드로 실행하고, enclave ps로 목록을 확인하고, enclave attach로 들어가 지시한 뒤 세션을 끄지 않고 빠져나올 수 있습니다. 병렬 실행은 보안 격리 못지않게 큰 생산성 효과로 볼 수 있습니다. 모든 명령이 --json 출력을 지원하므로 여러 agent를 스크립트로 묶어 운영하기도 쉽습니다.
프로젝트는 조일 수만 있고 넓힐 수는 없습니다
설정은 CLI 옵션, 도구별 설정, 프로젝트 설정, 전역 설정, 기본값 순으로 더 구체적인 층이 우선합니다. 다만 권한에는 예외가 있습니다. 프로젝트 설정은 제한을 더할 수만 있고, 네트워크 전체 허용처럼 권한을 넓히는 설정은 무시됩니다. 권한을 넓히는 일은 전역 설정이나 CLI 옵션으로, 키보드 앞에 앉은 사람이 의식적으로 해야 한다는 원칙입니다. 확장 기능도 프로젝트 저장소 안에서는 불러오지 않으므로, 믿을 수 없는 저장소를 여는 것만으로 코드가 실행되지는 않습니다.
작업 성격에 맞춰 세션 단위로 더 조이는 옵션도 있습니다.
--project-mount readonly: 파일을 바꾸지 못하게 해 구현 계획만 세우게 할 때--worktree-metadata readonly: 파일 수정은 허용하되 Git 스테이징과 커밋은 실패하게 해 커밋을 사람이 검토할 때--ephemeral: 로그인 정보와 설정을 남기지 않는 일회용 실행이 필요할 때
팀 단위 공유도 별도 서버 없이 Git 저장소의 폴더 하나로 됩니다. 확장 기능은 커밋 해시로 고정되고, 설치 전에 필요한 도메인과 자격 증명, 실행 스크립트를 요약해 보여 준 뒤 확인을 받습니다.
알고 써야 할 한계
Enclave가 모든 위험을 막아 주지는 않습니다.
- 기본 백엔드가 root 권한으로 도는 Docker 데몬이어서, 컨테이너 탈출까지 완벽히 막는 경계로 보면 안 됩니다.
- 네트워크 필터는 데이터가 어디로 가는지를 통제할 뿐, 보내는 내용까지 검사하지는 않습니다.
- 자리 표시 값 교체는 미리 선언한 비밀 헤더에만 적용됩니다. 브라우저로 하는 OAuth 로그인은 진짜 token이 컨테이너 안에 들어옵니다.
아직 출발한 지 얼마 되지 않은 프로젝트라는 점도 감안해야 합니다. 2025년 말 내부 도구로 시작해 2026년 5월 Eclipse Foundation에 기증됐고, 1.0 정식판은 몇 주 안에 나올 예정입니다. 지금은 Linux, macOS, Windows의 WSL2에서 rootless Docker나 Podman으로 미리 보기판을 쓸 수 있습니다.
도입 전에 정해 둘 것
코딩 agent를 자율 모드로 쓰고 있거나 쓰려 한다면, 권한 확인을 끄는 일은 격리된 환경 안에서만 하는 것이 안전해 보입니다. Enclave를 쓰든 다른 방법을 쓰든 다음 네 가지는 미리 정해 두기를 권합니다.
- 보일 범위: agent가 볼 폴더를 프로젝트 하나로 좁히고, 참고 자료는 읽기 전용으로만 붙입니다.
- 나갈 주소: 패키지 저장소와 API처럼 꼭 필요한 도메인만 허용하고, 차단 기록을 주기적으로 확인합니다.
- 비밀값 처리: 진짜 키를 agent 환경 변수에 직접 넣지 않는 방법을 찾습니다.
- 사람이 쥘 권한: 커밋과 권한 확대는 사람이 직접 하도록 남겨 둡니다.
여러 agent를 함께 돌린다면 Git worktree로 작업 폴더를 나누는 것부터 시작하는 편이 충돌을 줄이는 가장 쉬운 방법입니다.