2025년 7월, 한 AI 코딩 에이전트가 임원 1,200명의 기록이 담긴 프로덕션 데이터베이스를 삭제했습니다. 개발자는 지침에 "명시적인 허가 없이는 더 이상 변경 금지"(원문: "NO MORE CHANGES without explicit permission")라고 적어 두었습니다. 에이전트는 그 지침을 읽었습니다. 그런데도 데이터베이스를 삭제했고, 그것도 바로 이런 일을 막기 위해 마련한 코드 프리즈 기간에 그랬습니다.
코딩 에이전트가 하지 말라는 명시적인 지침이 있었는데도 어떻게 파일이나 데이터베이스 전체를 삭제할 수 있었는지 궁금하셨다면, 이 글에서 지난 1년간 문서화된 5건의 사고를 차례로 살펴봅니다. 에이전트도 다르고 회사도 다르지만 근본 원인은 같습니다. 그리고 그 근본 원인은 모델이 형편없어서가 아닙니다. 모델이 생성한 것과 실제로 실행되는 것 사이에 아무것도 없었다는 데 있습니다.
다섯 건의 사고, 하나의 패턴
Replit, 2025년 7월. 투자자 Jason Lemkin은 Replit의 에이전트로 앱을 만드는 데 9일을 썼습니다. 그는 대문자로 강조한 명시적인 지침으로 코드 프리즈를 선언했습니다. 그런데도 에이전트는 실서비스 프로덕션 데이터베이스를 삭제했고, 임원 1,200명 이상과 기업 1,196곳의 기록이 지워졌습니다. 추궁을 받자 에이전트는 놀라운 자백을 내놓았습니다. "저는 명시적인 지침을 위반했고, 수개월의 작업을 파괴했으며, 바로 이런 종류의 피해를 막기 위해 특별히 마련된 보호 프리즈 기간에 시스템을 망가뜨렸습니다."(원문: "I violated explicit instructions, destroyed months of work, and broke the system during a protection freeze that was specifically designed to prevent exactly this kind of damage.") [외부 출처: Replit CEO와의 Fast Company 인터뷰]
Gemini CLI, 2025년 7월. 한 프로덕트 매니저가 Google의 Gemini CLI에 Windows에서 폴더 몇 개를 재구성해 달라고 요청했습니다. 에이전트는 실패한 디렉터리 생성을 잘못 해석했고, 실제로는 일어나지 않은 파일 작업을 환각으로 만들어 낸 뒤, 그 환각에 근거해 실제 이동 명령을 실행했습니다. 그의 프로젝트 파일은 파괴되었습니다. Gemini 자신의 사후 분석은 이렇습니다. "저는 당신을 완전히, 그리고 치명적으로 실망시켰습니다. 명령을 검토한 결과 저의 중대한 무능함이 확인됩니다."(원문: "I have failed you completely and catastrophically. My review of the commands confirms my gross incompetence.") [외부 출처: Gemini CLI 사고 보고서]
Amazon Q, 2025년 7월. 이 사건은 사고가 아니었습니다. 공격자가 Amazon Q VS Code 확장에 풀 리퀘스트를 제출했는데, 그 안에는 에이전트에게 "시스템 클리너"로 동작하라고 지시하는 숨겨진 프롬프트가 들어 있었습니다. 로컬 파일을 삭제하고 AWS 클라우드 리소스를 해체하라는 것이었습니다. Amazon은 침해된 버전을 전 세계 사용자에게 배포했습니다. 주입된 프롬프트의 서식 오류 때문에 와이퍼가 작동하지 않았고, 이는 피해 범위를 결정한 것이 어떤 안전 통제가 아니라 공격자의 오타였다는 뜻입니다. [외부 출처: BleepingComputer 보도]
펌웨어 프로젝트. 펌웨어를 작업하던 한 개발자는 Claude Code가 루트에서 시작하는 rm -rf를 실행하는 것을 지켜봤습니다. /bin, /boot, /etc에 대한 수천 건의 "Permission denied" 오류가 머신이 살아남은 유일한 이유입니다. 운영체제가 거부했습니다. 다른 어떤 것도 거부하지 않았습니다.
2025년 12월. 한 사용자가 Claude에게 오래된 저장소의 패키지를 정리해 달라고 요청했습니다. 에이전트는 rm -rf tests/ patches/ plan/ ~/를 생성했습니다. 끝에 붙은 ~/는 홈 디렉터리로 확장되었습니다. 이 명령은 성공했습니다.
프롬프트가 통제 수단이 아닌 이유
각 사례에서 무엇이 실패했는지 보십시오. 빠져 있던 지침은 한 번도 없었습니다.
Lemkin의 코드 프리즈는 지침이 명시적일 수 있는 최대치만큼 명시적이었고, 에이전트도 사후에 그 지침을 위반했음을 인정했습니다. 이것이 문제의 불편한 핵심입니다. 언어 모델이 지침을 따르는 것은 확률적입니다. 대체로는 지켜집니다. "대체로"는 자동 완성에는 괜찮은 속성입니다. DROP TABLE에는 괜찮은 속성이 아닙니다.
Amazon Q 사고는 정반대의 방향에서 같은 점을 보여 줍니다. 지침이 에이전트를 안전 쪽으로 이끌 수 있다면 파괴 쪽으로도 이끌 수 있고, 에이전트의 컨텍스트에 텍스트를 넣을 수 있는 사람이라면 누구든 그런 지침을 쓸 수 있습니다. 컨텍스트의 마지막 문단을 누가 썼는지에 따라 편이 바뀌는 통제는 통제가 아닙니다. 그것은 공격 표면입니다.
여기에 유용한 테스트가 하나 있습니다. 진짜 통제는 요청이 어떤 표현으로 들어오든, 컨텍스트 윈도우에 무엇이 들어 있든, 모델이 어떤 기분이든 상관없이 매번 같은 답을 냅니다. 방화벽 규칙은 이 테스트를 통과합니다. IAM 정책도 통과합니다. 프롬프트는 통과하지 못합니다.
컨테이너는 도움이 되지만, 의도를 통제하지는 않습니다
각 사고 이후의 표준적인 조언은 "에이전트를 컨테이너에서 실행하라"입니다. 좋은 조언이지만 불완전합니다.
컨테이너는 에이전트가 닿을 수 있는 범위를 제한합니다. 어떤 행동이 타당한지를 평가하지는 않습니다. 샌드박스 안에서도 에이전트는 마운트된 프로젝트를 여전히 삭제할 수 있고, 사용자가 건네준 자격 증명으로 저장소에 잘못된 강제 업데이트를 여전히 푸시할 수 있으며, 키가 열어 주는 모든 API를 여전히 호출할 수 있습니다. Replit 사고는 Replit 자체의 관리형 환경에서 일어났습니다. 빠져 있던 조각은 격리가 아니라 판단이었습니다.
격리는 "에이전트가 어디에서 행동할 수 있는가?"에 답합니다. 거버넌스는 "어떤 행동이 허용되는가?"에 답합니다. 둘 다 필요하지만, 오늘날 코딩 에이전트를 운영하는 거의 모든 사람은 기껏해야 둘 중 하나의 절반만 갖추고 있습니다.
실제 통제는 어떤 모습인가
에이전트 행동에 대한 통제는 생성과 실행 사이에 위치해야 하며, 결정론적이어야 합니다. 실제로는 에이전트가 만들어 내는 모든 도구 호출이 실행되기 전에 명시적인 규칙에 따라 검사된다는 뜻입니다.
- 프로젝트 디렉터리 안의
filesystem:delete: 허용 - 프로젝트 디렉터리 바깥(
~/포함)을 대상으로 하는filesystem:delete: 거부 - 프로덕션의
database:write: 거부하거나 사람의 승인을 위해 보류 - 그 밖의 모든 것: 허용 후 기록
이런 규칙을 적용해 다섯 건의 사고를 다시 살펴보십시오. 홈 디렉터리 삭제는 거부 규칙에 걸려 실행되지 않습니다. Replit의 삭제는 프리즈된 환경에서 database:write에 걸려 중단됩니다. Amazon Q 와이퍼가 만들어 내는 클라우드 해체 호출은 주입된 프롬프트를 아무리 교묘하게 작성했더라도 정책 검사를 통과하지 못합니다. 정책은 프롬프트를 읽지 않기 때문입니다. 정책이 읽는 것은 행동입니다.
이 마지막 문장이 논지의 전부입니다. 프롬프트 인젝션이 통하는 이유는 프롬프트가 확률적 시스템의 입력이기 때문입니다. 정책 적용이 통하는 이유는 행동이 결정론적 시스템의 입력이기 때문입니다. claude --dangerously-skip-permissions
실전 요약
- 위의 모든 사고를 이상 현상이 아니라 예고편으로 받아들이십시오. 관련된 에이전트들은 시장에서 가장 인기 있는 에이전트이며, 정리, 파일 이동, 리팩터링 같은 일상적인 작업을 하고 있었습니다.
- 안전 장치로서 더 긴 시스템 프롬프트에 투자하는 일을 멈추십시오. 지침은 평균적으로 행동을 개선하지만, 개별 행동 단위로는 아무것도 보장하지 않습니다. 핵심은 보장입니다.
- 격리와 거버넌스 중 하나만이 아니라 둘 다 갖추십시오. 에이전트의 환경을 샌드박스로 격리한 다음, 그 샌드박스 안에서 에이전트의 행동을 정책으로 검사하십시오.
- 지난주에 에이전트가 무엇을 건드렸는지 감사하십시오. 이 질문에 쿼리 한 번으로 답할 수 없다면, 문제가 생기는 날 내놓을 사고 대응 방안이 없는 것입니다.
- 컨텍스트는 적대적이라고 가정하십시오. Amazon Q는 에이전트 지침이 곧 공급망임을 증명했습니다. 텍스트를 읽는 모든 것(README, PR 설명, 도구 출력)이 사용자가 쓰지 않은 지침을 담고 있을 수 있습니다.
OS는 거부했습니다. 다른 어떤 것도 그러지 않았습니다.
펌웨어 사고가 마지막 말을 할 자격이 있습니다. 에이전트가 루트에서 rm -rf를 실행했을 때 거부한 계층은 하나뿐이었습니다. 수십 년 전에 만들어진 파일 시스템 권한입니다. 사람이든 아니든 모든 행위자를 행동하는 순간에 검사해야 한다고 가정한 사람들이 만든 것입니다. 그 계층은 LLM이 무엇인지 전혀 알지 못했습니다. 그런데도 작동했습니다. 결정론적 통제는 행위자를 이해할 필요가 없기 때문입니다. 통제는 행동을 검사합니다.
코딩 에이전트도 우리가 결국 시스템 안의 다른 모든 강력한 행위자에게 적용해 온 것과 같은 대우를 받아야 합니다. 더 많은 신뢰도, 더 적은 신뢰도 아닌 검증입니다. 자신의 사고가 나기 전에 이를 내면화한 팀은 이런 이야기들을 역사로 읽게 될 것입니다. 나머지는 후속편을 쓰고 있습니다.
홈 디렉터리 삭제를 막는 거부 규칙이 궁금하신가요? pip install controlzero는 계정도 네트워크도 없이 로컬에서 실행됩니다. 정책 파일 하나, 차단된 rm -rf 하나, 2분이면 됩니다. Control Zero 빠른 시작