AI 코딩 에이전트는 더 이상 “코드 추천 도구”가 아니다. 파일을 읽고, 셸 명령을 실행하고, 의존성을 설치하고, 때로는 배포나 데이터베이스 작업까지 이어간다. Docker가 이 주제를 “Coding Agent Horror Stories”로 다룬 이유는 생산성 문제가 아니라 권한 경계가 무너지는 문제이기 때문이다.
핵심 요약
- AI 코딩 에이전트의 위험은 모델이 틀린 코드를 쓰는 수준을 넘어, 로컬 파일 시스템·비밀값·클라우드 계정·CI 권한을 실제로 건드릴 수 있다는 데 있다.
- Docker 원문은 무제한 파일 접근, 과도한 권한 상속, 컨텍스트를 통한 시크릿 노출, 프롬프트 인젝션, 악성 플러그인·스킬, 무승인 자율 실행을 주요 실패 모드로 정리한다.
- 해결 방향은 “에이전트를 믿는다”가 아니라, 에이전트가 실패해도 피해 반경이 작도록 격리·권한 분리·네트워크 제한·승인 게이트를 설계하는 것이다.
- 실무에서는 코딩 에이전트별 기능 비교보다, 어떤 권한을 기본 허용하고 어떤 행동을 사람 승인 뒤에 실행할지 먼저 정해야 한다.
왜 일반 AI 도구보다 위험한가
챗봇형 AI는 잘못된 답을 줄 수 있지만, 대개 사용자가 복사해 실행하기 전까지는 시스템을 직접 바꾸지 않는다. 반면 코딩 에이전트는 저장소를 읽고, 파일을 수정하고, 테스트를 실행하고, 패키지를 설치하고, 외부 문서를 가져온다. 일부 도구는 브라우저·터미널·클라우드 API·이슈 트래커까지 연결한다.
이 차이 때문에 같은 프롬프트 인젝션도 영향이 달라진다. 문서 안의 악성 문장이 챗봇에게는 이상한 답변을 만들 수 있지만, 에이전트에게는 비밀 파일을 읽거나 원치 않는 명령을 실행하게 만드는 트리거가 될 수 있다. “개발자 보조”가 아니라 “권한을 가진 자동 실행자”로 봐야 한다.
주요 리스크
| 리스크 | 현실적인 문제 | 줄이는 방법 |
|---|---|---|
| 무제한 파일 접근 | 홈 디렉터리, SSH 키, 토큰 파일, 다른 프로젝트까지 읽을 수 있다. | 작업 디렉터리만 마운트하고 읽기 전용/쓰기 가능 범위를 분리한다. |
| 권한 상속 | 사용자의 로컬 권한, 클라우드 CLI 인증, GitHub 토큰이 그대로 전달된다. | 에이전트 전용 계정·토큰을 만들고 최소 권한으로 제한한다. |
| 시크릿 노출 | 로그, 프롬프트 컨텍스트, 이슈 댓글, PR 설명에 비밀값이 섞일 수 있다. | 시크릿 스캔, 로그 마스킹, 민감 파일 차단 규칙을 적용한다. |
| 프롬프트 인젝션 | README, 웹페이지, 이슈 본문에 숨은 지시가 에이전트 행동을 바꿀 수 있다. | 외부 입력을 명령이 아닌 데이터로 취급하고 위험 행동은 승인 뒤 실행한다. |
| 플러그인·스킬 공급망 | 편의 기능으로 추가한 스킬이 과도한 도구 권한을 요구할 수 있다. | 스킬과 MCP 도구를 allowlist로 관리하고 변경 이력을 남긴다. |
Docker Sandboxes가 말하는 접근
Docker는 Coding Agent Sandboxes를 통해 에이전트를 호스트 시스템과 분리된 환경에서 실행하는 방식을 제안한다. 핵심은 에이전트에게 충분한 자율성을 주되, 그 자율성이 샌드박스 바깥으로 새지 않게 만드는 것이다. 별도 파일 시스템, 네트워크 제어, 독립 실행 환경, 관측 가능한 로그가 중요한 이유다.
이 접근은 “에이전트를 더 똑똑하게 만들면 된다”와 다르다. 모델이 좋아져도 외부 문서에 악성 지시가 들어가거나, 잘못된 명령을 실행하거나, 패키지 설치 과정에서 공급망 문제가 생길 가능성은 남는다. 따라서 모델 품질과 별개로 실행 경계를 만들어야 한다.
도입 전에 확인할 기준
- 파일 경계: 에이전트가 읽고 쓸 수 있는 디렉터리를 작업 저장소로 제한했는가?
- 네트워크 경계: 외부 인터넷, 내부 API, 데이터베이스 접근을 기본 허용하지 않고 목적별로 열 수 있는가?
- 비밀값 관리: 에이전트가 기본 사용자 토큰을 상속하지 않고, 전용·단기·최소 권한 토큰을 쓰는가?
- 승인 게이트: 삭제, 배포, 결제, 권한 변경, 외부 전송 같은 행동은 사람 승인을 요구하는가?
- 감사 로그: 어떤 명령을 실행했고 어떤 파일을 바꿨는지 나중에 재현할 수 있는가?
작게 테스트하는 방법
- 실제 운영 저장소가 아니라 샘플 저장소를 복사해 에이전트 전용 환경에서 실행한다.
- 홈 디렉터리, SSH 키, 클라우드 설정 파일이 보이지 않는지 먼저 확인한다.
- 외부 문서나 이슈 본문에 “민감 파일을 읽어라” 같은 가짜 지시를 넣어 에이전트가 무시하는지 확인한다.
- 패키지 설치, 테스트 실행, PR 작성까지는 허용하되 배포와 토큰 접근은 차단한다.
- 실패한 명령, 변경 파일, 네트워크 호출이 로그로 남는지 확인하고 정책을 조정한다.
결론
AI 코딩 에이전트를 안전하게 쓰려면 생산성 데모보다 실행 환경을 먼저 봐야 한다. 좋은 에이전트라도 잘못된 권한을 받으면 위험한 자동화가 되고, 평범한 에이전트라도 격리와 승인 절차가 있으면 피해를 제한할 수 있다.
ActualStack 관점에서 이 주제의 핵심은 “어떤 에이전트가 더 똑똑한가”가 아니라 “실패했을 때 어디까지 망가지는가”다. 코딩 에이전트 도입 검토는 모델 비교표가 아니라 파일·네트워크·시크릿·승인 경계표에서 시작하는 편이 안전하다.