AI 코딩 에이전트, 그냥 로컬에서 돌리지 말고 컨테이너 감옥에 넣자는 얘기

• AI 코딩 에이전트를 로컬 머신에서 그냥 돌리는 건 편하지만, 보안 관점에선 꽤 아찔한 선택임

  • 소스코드, 빌드 도구, 개발 DB, CLI, MCP, 환경변수, 인증 토큰까지 에이전트가 닿을 수 있는 표면이 너무 넓음
  • 글쓴이는 “하지 마”라고 프롬프트에 적는 건 사람한테도 잘 안 먹히는데 봇한테는 더 기대하기 어렵다고 봄

• 글쓴이가 고른 절충안은 컨테이너 기반 샌드박스임

  • 완전한 독립 가상머신은 더 강한 격리를 줄 수 있지만 무겁고 번거로움
  • GitHub Copilot의 샌드박스 모드처럼 정책으로 제어하는 방식은 더 부드럽지만, 글쓴이의 CLI 중심 워크플로에는 컨테이너가 보안·편의성·리소스 사이 균형이 좋았다고 함

• 구성 방식은 단순함: 작은 컨테이너 이미지를 만들고, 필요한 도구와 설정만 넣고, 허용할 것만 연결함

  • 에이전트 실행 파일과 설정을 컨테이너 안에 넣음
  • 필요한 CLI 도구, 스크립트 러너, 개발 DB 접근, 네트워크만 선별적으로 제공함
  • 환경변수와 볼륨도 필요한 것만 매핑해서, 예를 들어 특정 서비스 토큰은 보이지만 GitHub Copilot 토큰은 안 보이게 만들 수 있음

• 재미있는 지점은, 이 구성이 에디터 사용 경험을 크게 망치지 않는다는 것임

  • pi나 copilot 같은 실행 스크립트를 PATH에 넣어두면 겉으로는 평소처럼 CLI 도구를 실행하는 느낌임
  • 실제로는 현재 디렉터리가 컨테이너 안의 /sandbox로 보이고, 허용된 볼륨만 접근 가능함
  • SSH로 별도 머신에 붙는 식의 번거로움 없이, 에디터 안에서 기존처럼 작업할 수 있다는 게 장점

• 다만 편의성을 위해 열어둔 구멍은 그대로 리스크가 됨

  • 글쓴이는 호스트와 샌드박스가 dotnet 도구 같은 자산을 공유하게 해뒀는데, 중복 다운로드를 줄이는 대신 보안 경계는 약해진다고 인정함
  • 컨테이너 네트워크는 별도 sandbox-network로 분리했지만, 인터넷 접근은 제한하지 않았음
  • 에이전트가 컨테이너 안에서 추가 도구를 설치할 수 있게 해둔 것도 편하지만, 공급망 공격이나 이상한 프로세스 실행 가능성은 남아 있음

• 결론은 “완벽한 감옥”이 아니라 “로컬 머신을 통째로 내주는 것보단 훨씬 낫다”에 가까움

  • 특히 AI 에이전트가 점점 더 많은 로컬 권한을 요구하는 흐름에서는 기본 실행 환경을 샌드박스로 바꾸는 게 꽤 합리적임
  • 개인 개발자뿐 아니라 회사 노트북에서 에이전트를 쓰는 팀도 이 패턴을 참고할 만함

---

기술 맥락

• 이 글의 선택은 컨테이너를 보안 경계로 쓰는 거예요. 이유는 에이전트가 로컬 파일과 토큰을 직접 볼 수 있으면, 프롬프트 규칙을 아무리 잘 써도 실제 권한은 이미 넘어간 상태가 되기 때문이에요.

• 가상머신 대신 컨테이너를 고른 건 워크플로 때문이에요. CLI를 에디터 안에서 한 번에 하나씩 실행하는 방식이라면, 무거운 독립 환경보다 컨테이너가 실행 비용과 사용성을 더 잘 맞춰주거든요.

• 구현 포인트는 볼륨, 환경변수, 네트워크를 각각 따로 제한하는 데 있어요. 소스코드는 보여주되 민감한 토큰은 숨기고, 개발 DB는 같은 컨테이너 네트워크 안에서만 접근하게 만드는 식이에요.

• 다만 컨테이너가 마법의 방패는 아니에요. 호스트 도구 캐시를 공유하거나 인터넷을 열어두면 편의성은 올라가지만, 그만큼 공급망 공격이나 잘못된 도구 실행의 위험도 같이 올라가요.