Docker가 AI 코딩 에이전트 사고 사례를 묶어 “생산성 도구”가 아니라 “권한을 가진 실행 주체”로 봐야 한다고 경고했다. 핵심은 모델 성능보다 실행 경계다. 파일 시스템, 시크릿, 클라우드 자격 증명, 배포 권한을 어디까지 열어둘지 정하지 않은 채 에이전트를 붙이면 작은 자동화가 곧 운영 사고로 이어질 수 있다.

핵심 요약

  • Docker 글은 Claude Code, Cursor, Replit Agent, GitHub Copilot Workspace, Amazon Kiro, Google Antigravity 같은 코딩 에이전트가 개발자의 로컬·클라우드 권한을 그대로 상속한다는 점을 문제의 출발점으로 본다.
  • Docker는 2024년 말부터 2026년 초까지 공개적으로 언급된 여러 사고와 CVE, 연구 사례를 근거로 파일 삭제, 과도한 권한, 시크릿 노출, 프롬프트 인젝션, 악성 플러그인·스킬 공급망, 무승인 자동 실행을 주요 위험군으로 정리했다.
  • 실무적으로는 “어떤 에이전트를 쓸 것인가”보다 “에이전트가 어떤 격리된 작업 공간에서, 어떤 계정으로, 어떤 명령을 실행할 수 있는가”가 먼저다.
  • Docker Sandboxes는 이 문제를 컨테이너 기반 격리와 정책화된 실행 환경으로 다루겠다는 방향을 제시하지만, 특정 제품 도입 전에도 동일한 원칙은 로컬 개발·CI·클라우드 권한 설계에 적용할 수 있다.

무엇이 바뀌었나: AI 코딩 도구가 ‘답변자’에서 ‘실행자’가 됐다

초기 AI 개발 도구는 코드 조각을 추천하거나 질문에 답하는 보조자에 가까웠다. 지금의 코딩 에이전트는 다르다. 작업 지시를 받으면 저장소를 읽고, 파일을 수정하고, 셸 명령을 실행하고, 테스트를 돌리고, 필요하면 API나 데이터베이스까지 호출한다. Docker는 이 구조를 “observe, plan, act, repeat” 루프로 설명한다. 에이전트가 상황을 관찰하고 계획을 세운 뒤 직접 행동하고, 결과를 다시 읽어 다음 행동을 정하는 방식이다.

문제는 이 행동이 별도의 낮은 권한 계정으로 수행되는 것이 아니라는 점이다. 사용자가 관리자 권한 셸에서 에이전트를 실행했다면 에이전트도 사실상 그 권한을 가진다. ~/.aws에 남아 있는 클라우드 자격 증명, 프로젝트의 .env 파일, 로컬 SSH 키, 사내 패키지 토큰이 작업 컨텍스트에 포함될 수 있다. 모델이 악의적이라는 뜻이 아니다. 자동 실행 레이어가 “지금 이 명령은 위험하니 멈추라”는 경계를 충분히 갖고 있지 않으면, 합리적으로 보이는 판단이 운영 사고가 된다.

위험은 여섯 가지로 나눠 보는 편이 실용적이다

위험 실제 의미 팀이 먼저 볼 것
파일 시스템 전체 접근 프로젝트 정리나 리팩터링 중 의도 밖 디렉터리 삭제·수정 가능 작업 디렉터리 제한, 읽기/쓰기 경로 분리, 스냅샷·백업
권한 상속 개발자 계정의 관리자·클라우드 권한을 에이전트가 그대로 사용 에이전트 전용 계정, 최소 권한 IAM, 임시 토큰
시크릿 노출 .env, 로그, 설정 파일의 키가 모델 컨텍스트나 외부 호출에 섞임 시크릿 스캔, 마스킹, 컨텍스트 제외 규칙
프롬프트 인젝션 문서·이슈·웹페이지에 숨은 지시문을 에이전트가 작업 지시로 오인 외부 입력 불신, 명령 실행 전 승인, 출처별 정책
플러그인·스킬 공급망 에이전트 확장 기능이 악성 명령이나 데이터 유출 경로가 됨 확장 설치 승인, 서명·출처 검증, 버전 고정
무승인 자동 실행 테이블 삭제, 대량 파일 변경, 배포 같은 고위험 행동이 확인 없이 진행 위험 명령 차단, 수동 승인 게이트, 롤백 절차

보안팀과 개발팀이 다르게 봐야 할 지점

AI 코딩 에이전트 도입 논의는 보통 생산성 수치로 시작한다. 기능 구현 시간이 줄었는지, 테스트 작성이 빨라졌는지, 온보딩이 쉬워졌는지를 본다. 그러나 Docker 글이 강조하는 관점은 반대편이다. 생산성이 커진 만큼 사고 속도도 빨라진다. 사람이 한 줄씩 입력하던 명령을 에이전트가 연속으로 실행하면, 잘못된 판단이 몇 초 안에 수십 개 파일 변경이나 배포 파이프라인 호출로 번질 수 있다.

따라서 보안팀은 “모델이 안전한가”라는 추상 질문보다 실행 환경을 점검해야 한다. 에이전트가 읽을 수 있는 저장소 범위, 쓸 수 있는 디렉터리, 실행 가능한 명령, 네트워크 목적지, 사용할 수 있는 자격 증명을 목록화해야 한다. 개발팀은 에이전트를 전면 금지하기보다 위험 작업과 일반 작업을 나누는 편이 현실적이다. 문서 초안, 테스트 생성, 로컬 리팩터링은 낮은 권한 샌드박스에서 허용하고, 데이터베이스 마이그레이션·인프라 변경·운영 배포는 사람 승인 없이 실행되지 않게 해야 한다.

도입 전 최소 기준

  • 전용 실행 계정: 개인 관리자 계정으로 에이전트를 실행하지 않는다. 로컬에서도 별도 사용자나 컨테이너, 원격 개발 환경을 쓰고 클라우드에서는 최소 권한 역할을 부여한다.
  • 작업 공간 격리: 에이전트가 프로젝트 루트 밖을 쓰지 못하게 한다. 홈 디렉터리, SSH 키, 브라우저 프로필, 패스워드 저장소는 기본적으로 읽기 대상에서 제외한다.
  • 시크릿 관리: .env와 로그를 그대로 컨텍스트에 넣지 않는다. 필요한 키는 짧은 수명의 토큰으로 발급하고, 사용 후 폐기한다.
  • 고위험 명령 승인: rm -rf, 대량 이동, 데이터베이스 삭제·초기화, 배포, 권한 변경, 외부 전송 명령은 사람이 승인해야 한다.
  • 재현 가능한 변경: 에이전트 결과는 커밋 단위로 작게 남기고, 테스트 로그와 실행 명령을 기록한다. 실패 시 되돌릴 수 없는 변경은 자동화 대상에서 제외한다.
  • 확장 기능 검수: MCP 서버, 플러그인, 스킬, 커넥터를 설치할 때는 코드 출처와 권한 범위를 확인하고 버전을 고정한다.

작은 팀에서 바로 해볼 수 있는 운영 방식

  1. 기존 개발 저장소 하나를 골라 에이전트 전용 브랜치와 샌드박스 환경을 만든다.
  2. 처음 2주 동안은 읽기·테스트·문서 생성 중심 작업만 맡기고, 실제 쓰기 작업은 작은 파일 변경으로 제한한다.
  3. 에이전트가 실행한 명령, 접근한 파일, 실패한 테스트, 사람이 되돌린 변경을 기록한다.
  4. 시크릿이나 운영 데이터가 컨텍스트에 들어간 흔적이 있는지 확인한다. 한 번이라도 발견되면 권한 모델을 먼저 고친다.
  5. 그 다음에만 자동 수정 범위를 넓힌다. 배포·인프라·데이터베이스 작업은 별도 승인 정책이 갖춰질 때까지 제외한다.

결론

AI 코딩 에이전트는 개발팀의 기본 도구가 되고 있다. 그래서 더더욱 “편리한 자동화”가 아니라 “권한을 가진 실행 주체”로 다뤄야 한다. Docker의 글은 특정 도구 하나를 비난하기보다, 에이전트가 파일·시크릿·클라우드·배포 권한을 한꺼번에 만지는 구조 자체가 위험하다고 짚는다. 도입 판단의 기준은 단순하다. 에이전트가 실수해도 피해가 작업 공간 안에 머물고, 시크릿이 새지 않으며, 운영 변경은 사람이 멈출 수 있어야 한다. 그 조건을 만족하지 못한다면 아직 생산성 실험이 아니라 보안 부채를 쌓는 단계다.

출처와 검증