코딩 에이전트에게 어디까지 허용할 것인가

2026. 6. 1.

들어가며

명령 몇 줄을 적어두면 여러 디렉터리를 오가며 파일을 수정하고 명령을 실행하는 코딩 에이전트. 그 모습을 보다 보면 내 컴퓨터를 자율주행에 맡긴 듯한 느낌이 들기도 한다.

그렇다면 우리는 모르는 사이에 에이전트에게 지나치게 많은 권한을 부여하고 있는 건 아닐까? 프로젝트를 수정하는 데 필요한 권한과 개인 문서나 인증 정보에 접근하는 권한은 구분해서 살펴봐야 한다.

이 글은 코딩 에이전트를 사용해 본 개발자가 실행 환경의 접근 범위를 점검할 수 있도록 돕기 위한 글이다. Codex와 Claude Code의 권한 설정과 샌드박스를 살펴보고, Container와 VM으로 환경을 분리할 때 어떤 경계가 생기는지 정리한다. 설치 절차보다 무엇을 보호해야 하고 어디까지 격리할 수 있는지 이해하는 데 초점을 둔다.

에이전트에게 어디까지 허용할 것인가

에이전트에게 허용할 권한은 작업에 필요한 범위에서 정해야 한다. 작업 공간(workspace)은 프로젝트를 다루는 디렉터리이고, 자격 증명은 API key나 SSH key처럼 서비스 접근에 사용하는 인증 정보다. 작업 공간과 네트워크 접근을 제한하고, 불필요한 자격 증명을 분리하며, 위험한 작업에 승인을 요구하는 것이 출발점이다.

에이전트는 파일을 읽고 수정하며 명령을 실행한다. 따라서 접근 범위를 판단할 때는 세 가지를 나누어 봐야 한다. 어떤 파일을 읽을 수 있는지, 어디에 쓸 수 있는지, 어떤 외부 서비스에 연결할 수 있는지다.

여기에 승인을 요구하는 시점을 더해야 한다. 샌드박스는 실행 중인 명령이 접근할 수 있는 범위를 제한하고, 승인 정책은 특정 작업을 실행하기 전에 검토할지를 정한다. 승인을 자주 받더라도 실행 환경의 접근 범위가 넓을 수 있고, 승인 없이 실행되는 작업도 좁은 샌드박스 안에 제한될 수 있다. Codex 공식 문서는 이 두 장치를 구분해서 설명한다.

Codex 샌드박스 문서에 따르면, 로컬 실행의 workspace-write는 작업 공간 안의 수정과 일반적인 명령 실행을 허용하는 모드다. 기본적으로 명령의 네트워크 접근은 꺼져 있으며, 범위를 벗어나는 실행에는 승인 정책이 적용된다. 다만 작업 공간 밖의 쓰기 제한을 읽기 제한으로 해석해서는 안 된다. 실제 읽기 범위와 보호 대상은 적용된 권한 설정을 함께 확인해야 한다.

Claude Code에도 명령 실행을 제한하는 샌드박스가 있다. 공식 문서에 따르면 기본적으로 비활성화되어 있으며 /sandbox로 설정할 수 있다. 활성화한 상태에서도 기본 읽기 범위에는 자격 증명 파일이 포함될 수 있고, 환경 변수도 상속된다. 또한 내장 파일 도구와 외부 도구를 연결하는 MCP 서버, 특정 시점에 명령을 실행하는 hooks는 Bash 샌드박스와 적용 범위가 다르다. 따라서 샌드박스를 켰다는 사실만으로 세션 전체가 같은 경계 안에 있다고 판단하기는 어렵다.

이 차이에서 출발하면 설정의 우선순위도 분명해진다. 프로젝트에 필요한 파일만 접근시키고, 불필요한 자격 증명을 실행 환경에서 빼며, 필요한 통신만 허용하는 것이다. 승인 요청이 나타날 때는 명령의 목적과 함께 접근 범위를 얼마나 넓히는지도 살펴봐야 한다.

보호하려는 대상에 따라 점검할 설정도 달라진다.

원본 파일의 의도치 않은 수정이 걱정된다면 쓰기 가능한 경로를 확인한다. 원본 대신 프로젝트 사본에서 작업하고, 변경 사항을 검토한 뒤 반영하는 방법도 있다.
인증 정보에 대한 접근이 걱정된다면 읽을 수 있는 파일과 전달되는 환경 변수를 확인한다. 작업에 필요하지 않은 개인용·운영용 자격 증명은 실행 환경에서 분리한다.
외부로 정보가 전달되는 것이 걱정된다면 허용한 네트워크 연결과 모델 제공자에게 전송되는 내용을 나누어 살펴본다. 아래에서 설명할 실행 환경의 격리만으로 모든 전송이 차단되지는 않는다.

Container와 VM으로 실행 환경을 분리하기

명령별 제한보다 넓은 범위를 격리하려면 에이전트 자체를 별도 환경에서 실행하는 방법을 고려할 수 있다. 에이전트와 그 환경 안에서 실행되는 보조 프로세스가 접근할 파일, 자격 증명, 네트워크를 함께 제한하는 방식이다.

Container는 애플리케이션과 필요한 도구를 격리된 환경에서 실행하는 방식이다. VM(Virtual Machine)은 별도의 운영체제를 실행하는 가상 머신이다. 어느 쪽을 선택하든 호스트, 즉 그 환경을 구동하는 컴퓨터와 무엇을 공유하는지 확인해야 한다.

Container를 활용한 구성 예시는 다음과 같다.

프로젝트 사본과 필요한 개발 도구만 넣는다.
개인 홈 디렉터리와 SSH·클라우드 자격 증명은 공유하지 않는다.
관리자 권한이 없는 사용자로 실행하고, 필요한 경로만 쓰기 가능하게 둔다.
외부 연결은 필요한 목적지로 제한한다.
작업이 끝나면 변경 사항을 검토한 뒤 원본에 반영한다.

여기서 주의할 부분은 호스트와의 연결이다. bind mount는 호스트의 파일이나 디렉터리를 Container 안에서 사용할 수 있도록 연결하는 방식이다. 프로젝트를 쓰기 가능한 bind mount로 연결하면 Container 안에서의 수정이 호스트 파일에도 반영된다. Container에 넣었다는 사실만으로 원본이 보호되는 것은 아니다. Container를 관리하는 서비스인 Docker daemon에 접근할 수 있는 소켓을 공유하는 것 역시 큰 권한을 부여하는 선택이다. Docker 보안 문서에서 이 권한의 영향을 살펴볼 수 있다.

VM은 운영체제의 핵심인 커널을 별도로 가진다. 에이전트를 그 운영체제 안에서 실행하므로 커널 경계를 분리할 수 있다. 신뢰하기 어려운 저장소나 실행 파일을 다루는 경우 고려할 수 있지만, 운영체제와 개발 도구를 준비하고 유지하는 부담이 늘어난다. 공유 폴더와 네트워크, 자격 증명을 넓게 열어두면 그 연결을 통한 위험은 여전히 남는다.

프라이버시도 별도로 살펴봐야 한다. Container나 VM은 로컬 실행의 접근 범위를 제한하지만, 에이전트가 읽은 내용을 모델 제공자에게 전송하는 동작까지 막아주지는 않는다. Claude Code 문서도 격리 여부와 모델에 전송되는 정보는 별개라고 설명한다. Claude Code 공식 문서: 격리의 한계

마치며

에이전트에게 어디까지 허용할지는 작업에 필요한 접근 범위에서 출발해야 한다. 프로젝트 수정 권한이 필요하더라도 개인 문서와 운영 환경의 자격 증명까지 필요하지는 않을 수 있다.

다음 작업을 시작하기 전에 에이전트가 읽을 수 있는 파일, 수정할 수 있는 경로, 연결할 수 있는 외부 서비스를 확인해 보자. 승인 요청에서는 그 범위가 얼마나 넓어지는지 살펴보자. Container나 VM을 사용한다면 호스트와 공유한 폴더와 전달한 자격 증명도 함께 점검해야 한다.

권한 설정으로 접근 범위를 줄이고, 더 넓은 격리가 필요하면 별도 실행 환경을 고려할 수 있다. 그 안에서도 무엇을 공유하고 어떤 통신을 허용했는지 확인해야 한다. 모델 제공자에게 전송되는 정보는 실행 환경의 격리와 별도로 살펴볼 문제다.

참고자료

OpenAI: Agent approvals & security — Codex의 승인 정책과 샌드박스, 로컬 명령의 기본 네트워크 제한.
OpenAI: Sandbox — workspace-write 등 샌드박스 모드와 권한 설정.
Claude Code: Configure the sandboxed Bash tool — 활성화 방법, 기본 접근 범위, 샌드박스 밖에서 실행되는 도구/프로세스.
Claude Code: Choose a sandbox environment — Container/VM의 격리 범위와 모델로 전송되는 정보의 관계.
Docker: Bind mounts — 호스트 디렉터리 공유와 쓰기 권한의 영향.
Docker: Docker Engine security — Docker daemon의 권한과 Container 격리의 한계.