AI 코딩 에이전트에게 프로젝트 폴더만 보여 주려면 어떻게 해야 할까요

핵심 요약 (TL;DR)

AI 코딩 에이전트는 코드를 읽고 쓰는 데서 멈추지 않습니다. 패키지를 설치하고, 셸 명령을 실행하며, 설정 파일을 열 수 있습니다. 그래서 작업을 맡길 때 가장 먼저 물어야 할 질문은 “얼마나 똑똑한가”보다 “어디까지 볼 수 있고 무엇을 실행할 수 있는가”입니다. 9월 1일 공개된 dev-sandbox는 Podman 컨테이너와 선택적 krun microVM으로 에이전트와 비신뢰 코드를 격리하고, 현재 프로젝트 디렉터리만 보이게 하려는 스크립트를 공개했습니다. 이 도구가 모든 위험을 없앤다는 뜻은 아닙니다. README도 Git hooks와 영속 볼륨 같은 남은 위험을 별도로 경고합니다. 이 정직한 한계가 오히려 좋은 출발점입니다.

왜 프로젝트 폴더만 보이게 해야 할까요?

개발용 컴퓨터에는 프로젝트와 무관한 정보가 많습니다. SSH 키, 클라우드 설정, 브라우저 데이터, 다른 고객의 저장소, 개인 문서가 한 사용자 계정에 함께 있을 수 있습니다. 에이전트가 현재 기능을 고치기 위해 이런 정보까지 볼 이유는 거의 없습니다.

dev-sandbox는 호스트 홈 디렉터리 대신 현재 프로젝트만 컨테이너에 마운트하는 방식을 설명합니다. 중요한 원칙은 최소 공개입니다. 에이전트에게는 과제에 필요한 파일만 주고, 비밀값이 든 .env나 배포 키는 기본 작업공간에서 빼세요. 필요한 API가 있다면 테스트용 키, 짧은 유효기간, 최소 권한을 우선 고려하는 편이 좋습니다.

격리하면 프롬프트 인젝션도 사라질까요?

사라진다고 말할 수 없습니다. README는 악성 패키지의 설치 스크립트나 파일 안의 지시문이 에이전트를 위험한 명령으로 유도할 수 있다고 짚습니다. 격리는 그 행동이 닿을 수 있는 범위를 줄이는 장치이지, 에이전트가 잘못된 지시를 따르지 않게 만드는 보증은 아닙니다.

따라서 파일 접근, 네트워크, 실행 권한을 따로 정해야 합니다. 처음에는 읽기와 테스트 실행만 허용하고, 외부 네트워크가 필요한 작업은 목적별로 제한하세요. 배포·삭제·결제·메시지 발송은 격리 환경 안에 있더라도 사람이 승인하는 단계로 남겨야 합니다. 로그도 남겨 어떤 명령이 실행됐는지 확인할 수 있어야 합니다.

가장 작은 안전한 시작은 무엇일까요?

컨테이너를 바로 도입하기 어렵다면 전용 테스트 저장소부터 만드세요. 실제 고객 데이터가 없는 샘플 데이터, 새로 만든 테스트 계정, 필요한 파일만 있는 복사본에서 에이전트를 실행합니다. 다음으로 비밀값 스캔, 변경 파일 확인, 테스트 명령 기록을 작업 완료 조건에 넣으세요.

격리는 불편을 늘리기 위한 규칙이 아닙니다. 에이전트가 더 오래, 더 넓은 작업을 하게 될 때 사람과 사업을 보호하는 경계입니다. 작은 프로젝트에서도 이 경계를 먼저 만들면, 나중에 자동화를 늘릴 때 무엇을 열고 무엇을 계속 막아야 하는지 훨씬 선명해집니다.

FAQ: 컨테이너를 쓰면 배포 키를 넣어도 되나요?

권하지 않습니다. 컨테이너는 노출 범위를 줄일 수 있지만 키의 오남용과 유출 위험을 없애지 않습니다. 배포는 별도 승인·최소 권한·짧은 자격증명으로 분리하세요.

FAQ: macOS에서도 같은 원칙을 적용할 수 있나요?

그렇습니다. 이 프로젝트의 README는 Linux와 Podman을 전제로 하지만, 핵심은 운영체제가 아니라 전용 작업공간·최소 파일 공개·비밀값 분리·실행 기록입니다. 사용 환경에 맞는 격리 방법을 공식 문서로 확인해야 합니다.

FAQ: 네트워크를 모두 막으면 에이전트를 쓸 수 없지 않나요?

필요한 작업에는 제한된 네트워크가 필요할 수 있습니다. 중요한 것은 기본적으로 넓게 열지 않고, 패키지 설치나 특정 API처럼 목적과 시간을 정해 허용하는 것입니다.

출처: https://github.com/kosmrljt/dev-sandbox
발표 확인: https://news.ycombinator.com/item?id=49527526
관찰 시점: 2026-09-02 KST