Destructive Command Guard: 코딩 에이전트 시대의 안전장치는 프롬프트가 아니라 실행 훅이다

핵심 키워드: Destructive Command Guard · 코딩 에이전트 안전 · 실행 전 훅 정책

코딩 에이전트의 안전을 아직도 “모델에게 조심하라고 말하기”로만 생각하면 부족하다. Claude Code, Codex CLI, Gemini CLI, Copilot CLI, Cursor 같은 도구는 이제 답변을 쓰는 수준을 넘어 실제 터미널 명령을 실행한다. 이때 위험은 추상적인 hallucination보다 훨씬 구체적이다. git reset --hard, rm -rf ./src, docker system prune, kubectl delete namespace, DROP TABLE users 같은 명령은 한 번 실행되면 리뷰할 시간이 거의 없다.

2026년 7월 14일 GitHub Trending에서 포착된 Dicklesworthstone/destructive_command_guard, 줄여서 dcg는 이 문제를 정면으로 다룬다. README는 dcg를 “AI coding agents that blocks destructive commands before they execute”라고 설명한다. 즉 에이전트가 위험한 shell/git 명령을 실행하기 전에 훅에서 가로채고, 차단 이유와 더 안전한 대안을 보여주는 도구다.

이 글의 결론부터 말하면 이렇다. 코딩 에이전트 운영의 다음 안전장치는 프롬프트가 아니라 실행면의 정책 훅이다. 모델이 더 똑똑해질수록, “말로 설득하는 안전”은 한계가 있고, 실제 행동 직전에 작동하는 기계적 게이트가 필요해진다.

기준 시점: 이 글은 2026-07-14에 확인한 destructive_command_guard README, GitHub API 메타데이터, docs/codex-integration.md, docs/agents.md, docs/packs/README.md, CHANGELOG.md를 바탕으로 작성했다. 훅 프로토콜과 지원 에이전트는 빠르게 바뀔 수 있으니 실제 도입 전 최신 문서를 다시 확인해야 한다.

왜 지금 이 주제가 중요한가: 에이전트는 “추천자”가 아니라 “행위자”가 됐다

예전 코딩 보조 도구의 위험은 주로 잘못된 코드를 제안하는 것이었다. 개발자가 복사해 붙이고, 테스트를 돌리고, 리뷰하면서 걸러낼 여지가 있었다. 하지만 터미널 기반 에이전트는 다르다. 사용자가 “이거 고쳐줘”라고 맡기면 에이전트는 파일을 읽고, 패치를 만들고, 테스트를 실행하고, 때로는 git 명령이나 설치 명령까지 수행한다.

이 변화는 안전 모델을 바꾼다.

• 잘못된 답변은 되돌릴 수 있지만, 잘못된 삭제 명령은 작업물을 날릴 수 있다.
• 모델 정책은 의도를 해석하지만, 실제 피해는 셸·git·DB·클라우드 CLI에서 발생한다.
• 승인 UX가 있더라도 피로가 쌓이면 사용자는 위험한 명령을 대충 허용할 수 있다.

dcg가 흥미로운 이유는 여기 있다. 이 도구는 모델의 머릿속을 고치려 하지 않는다. 대신 에이전트가 실행하려는 명령이 시스템 경계에 닿는 순간을 잡는다.

README의 TL;DR은 꽤 직설적이다. 문제는 AI 코딩 에이전트가 git reset --hard, rm -rf ./src, DROP TABLE users 같은 재앙적 명령을 실행할 수 있다는 것이고, 해결책은 그 명령이 실행되기 전에 intercept해서 차단하는 것이다. 이건 “AI가 안전하게 말하게 하기”가 아니라 “AI가 안전하게 행동하게 하기”에 가깝다.

dcg는 단순한 금칙어 필터가 아니다

이런 도구를 처음 보면 “그냥 위험한 문자열 목록으로 막는 것 아닌가?”라고 볼 수 있다. 하지만 README와 문서를 보면 방향은 훨씬 운영적이다.

dcg는 고성능 훅으로 동작하며, 기본적으로 가장 파괴적인 git/filesystem/system disk 계열을 막고, 필요하면 pack을 켜서 데이터베이스·컨테이너·쿠버네티스·클라우드·Terraform·S3·Redis·Supabase 같은 영역까지 확장한다. docs/packs/README.md 기준 카테고리는 core, database, containers, kubernetes, cloud, infrastructure, storage, secrets, monitoring, platform, windows 등으로 나뉜다.

중요한 건 이 구조가 “모든 위험을 한 덩어리로 막는다”가 아니라는 점이다. 실제 팀 운영에서는 프로젝트마다 위험 프로필이 다르다.

• 프론트엔드 저장소에서는 rm -rf node_modules와 git reset --hard가 주된 위험일 수 있다.
• 데이터 플랫폼 저장소에서는 DROP DATABASE, TRUNCATE, redis FLUSHALL 같은 명령이 더 치명적이다.
• 쿠버네티스 운영 저장소에서는 kubectl delete namespace, helm uninstall, terraform destroy가 핵심 위험이다.
• Windows 개발 환경에서는 rd /s, Remove-Item -Recurse -Force, vssadmin delete shadows 같은 native 명령도 봐야 한다.

그래서 pack 기반 구조는 꽤 현실적이다. 팀은 “AI 에이전트를 쓸까 말까”가 아니라, 어떤 작업 영역에서 어떤 파괴적 액션을 차단할 것인가를 정책으로 정해야 한다.

README가 강조하는 기능 중 실무적으로 눈에 띄는 것도 이 맥락이다. heredoc/inline script scanning은 python -c "os.remove(...)" 같은 우회성 실행을 보려는 시도이고, smart context detection은 grep "rm -rf"처럼 데이터를 검색하는 경우와 실제 삭제 명령을 구분하려는 시도다. rich terminal output과 agent-safe stream 분리도 중요하다. 사람에게는 stderr로 설명을 보여주고, 에이전트 프로토콜에는 stdout JSON으로 차단 결정을 전달해야 하기 때문이다.

Codex 통합 문서가 보여주는 진짜 어려움: “차단”보다 “프로토콜 호환”이다

특히 흥미로운 부분은 Codex Integration 문서다. 이 문서는 dcg가 Codex CLI 0.125.0+의 훅 페이로드를 어떻게 식별하고, 왜 Codex용 denial 출력은 최소 JSON 형태여야 하는지 설명한다.

핵심은 이렇다. Codex와 Claude 계열 훅은 비슷한 형태의 payload를 보내지만, Codex는 turn_id 필드로 구분한다. 그리고 Codex의 hook output parser는 더 엄격해서 dcg 전용 메타데이터를 많이 넣으면 “차단된 명령”이 아니라 “PreToolUse Failed”로 해석될 수 있다. 문서에 따르면 dcg는 Codex에 대해 hookSpecificOutput 안에 hookEventName, permissionDecision, permissionDecisionReason만 담는 최소 JSON denial을 stdout으로 내보내고, 프로세스는 exit 0으로 끝낸다.

이 디테일은 작아 보이지만 중요하다. 훅이 실패로 해석되면 일부 환경에서는 fail-open이 발생할 수 있다. 즉 안전장치가 막는 척하다가 오히려 통과시킬 수 있다. 2026-07-13의 CHANGELOG.md도 이 문제를 직접 언급한다. v0.6.6은 Codex CLI 0.144.x native Windows에서 이전 exit-code-2 계약이 hook failure로 분류되어 fail-open될 수 있던 문제를 minimal JSON denial로 고쳤다고 설명한다.

여기서 교훈은 분명하다. AI 에이전트 안전 도구는 “위험한 명령을 아는가”만으로 충분하지 않다. 각 에이전트 호스트의 훅 프로토콜, stdout/stderr 의미, exit code 해석, 신뢰 승인 UX까지 맞춰야 한다. 모델 시대의 보안 도구가 점점 프로토콜 호환성 제품이 되는 이유다.

에이전트별 신뢰 수준은 라벨이고, 실제 정책은 별도 노브다

docs/agents.md도 실무적으로 좋다. dcg는 Claude Code, Augment Code, Aider, Continue, Codex CLI, Gemini CLI, Copilot CLI, VS Code Copilot Chat, Cursor, Hermes Agent, Grok, Pi 등을 감지할 수 있다고 문서화한다. 감지 방식은 환경 변수, hook payload, 부모 프로세스 검사 등으로 나뉜다.

하지만 더 중요한 문장은 trust level 설명이다. 문서는 high, medium, low 같은 trust level이 advisory label이라고 못 박는다. 즉 trust_level = "high"라고 썼다고 규칙이 자동으로 느슨해지지 않는다. 실제 행동 차이는 disabled_packs, extra_packs, additional_allowlist, disabled_allowlist 같은 옵션에서 나온다.

이 설계는 꽤 좋은 선택이다. 많은 보안 설정은 “high trust” 같은 추상 라벨이 실제 동작을 몰래 바꾸면서 사고를 만든다. dcg의 방식은 다르다.

여기서 한국 개발팀이 가져갈 포인트는 명확하다. “우리 팀은 Claude Code를 믿는다”와 “Claude Code가 terraform destroy를 실행해도 된다”는 완전히 다른 말이다. 신뢰는 라벨이고, 권한은 구체적 명령·팩·경로·상황으로 쪼개야 한다.

실무 해석: “승인 버튼”만으로는 부족하다

많은 코딩 에이전트는 이미 명령 실행 전에 사용자 승인을 요구한다. 그렇다면 dcg 같은 훅이 왜 필요할까? 이유는 세 가지다.

첫째, 사람의 승인은 피로해진다. 하루 종일 테스트, 빌드, 패키지 설치, git 명령을 승인하다 보면 위험한 명령도 관성적으로 누를 수 있다. 이때 기계적 차단 규칙은 마지막 안전망이 된다.

둘째, 팀 정책은 개인의 주의력에 맡기기 어렵다. 한 명은 git reset --hard를 절대 허용하지 말자고 생각하고, 다른 한 명은 “가끔 필요하다”고 생각할 수 있다. 훅 설정은 이 차이를 저장소·사용자·프로젝트 단위 정책으로 바꾼다.

셋째, 에이전트 생태계는 다중 호스트가 됐다. 팀 안에서 Claude Code, Codex CLI, Cursor, Copilot Chat, Gemini CLI를 섞어 쓰는 상황이 흔해진다. 각 도구의 승인 UX가 다르면 운영 기준도 흔들린다. dcg 같은 공통 훅은 에이전트별 UX 위에 한 겹 더 낮은 실행 정책을 깐다.

내가 팀에 도입한다면 순서는 이렇게 잡겠다.

1. 기본 보호부터 켠다. core filesystem, core git, system disk 계열은 거의 모든 저장소에 유효하다.
2. 도메인별 pack을 좁게 추가한다. DB 저장소에는 database, 인프라 저장소에는 kubernetes/cloud/infrastructure를 추가한다.
3. allowlist는 넓게 열지 않는다. npm test, cargo test, npm run build 같은 반복 안전 명령부터 시작한다.
4. unknown agent는 더 빡세게 둔다. 새 CLI나 플러그인은 검증 전까지 extra packs와 disabled_allowlist로 묶는다.
5. 차단 로그를 리뷰한다. false positive는 무시하지 말고 정책을 조정한다. 안전장치가 시끄러우면 결국 꺼진다.

SEO 관점에서 봐도 이 주제는 “AI 에이전트 보안”의 구체 키워드다

“AI 에이전트 보안”은 너무 넓다. 검색 의도도 흩어진다. 누군가는 모델 alignment를 찾고, 누군가는 prompt injection을 찾고, 누군가는 MCP 보안을 찾는다. 반면 dcg가 건드리는 키워드는 더 선명하다.

• 코딩 에이전트 위험한 명령 차단
• Claude Code hook 안전 설정
• Codex CLI PreToolUse hook
• AI agent terminal safety
• git reset hard 방지
• rm rf 방지 도구
• 에이전트 실행 권한 관리

한국 개발자와 빌더에게도 이 영역은 점점 중요해질 가능성이 높다. AI 코딩 도구는 이미 개인 실험 단계를 넘어 팀 워크플로에 들어오고 있다. 그런데 팀 도입 문서가 “어떤 모델을 쓸 것인가”에서 멈추면 사고가 난다. 이제는 “어떤 명령을 막을 것인가”, “어떤 에이전트에 어떤 allowlist를 줄 것인가”, “fail-open을 어떻게 피할 것인가”까지 같이 설계해야 한다.

한 줄 결론

Destructive Command Guard는 작은 CLI 유틸처럼 보이지만, 그 신호는 작지 않다. 코딩 에이전트가 실제 명령을 실행하는 시대에는 안전을 프롬프트와 승인 버튼에만 맡길 수 없다. AI 에이전트 운영의 안전 경계는 실행 직전 훅, pack 기반 정책, 에이전트별 프로토콜 호환성, allowlist 거버넌스의 조합으로 내려오고 있다.

참고한 primary source

• Dicklesworthstone/destructive_command_guard README
• Codex Integration 문서
• Agent-Specific Profiles 문서
• Pack Reference Documentation
• CHANGELOG.md v0.6.6
• GitHub API metadata: Dicklesworthstone/destructive_command_guard