AI 코딩 에이전트(AI coding agents)는 문제가 발생하기 전까지는 매우 훌륭합니다.

에이전트는 단순히 텍스트만 작성하는 것이 아니라, 사용자의 권한을 가지고 터미널에서 실제 명령어를 실행합니다. 대부분의 경우 그것이 에이전트를 사용하는 핵심 목적이기도 합니다. 하지만 가끔 에이전트가 오류를 만나면, 해결책이 "상황을 정리하는 것"이라고 판단하고 다음과 같은 명령어를 실행하곤 합니다:

rm -rf .

악의가 있는 것은 아닙니다. 진심으로 돕고 있다고 생각하는 것이죠. 사실 그 점이 에이전트를 위험하게 만듭니다. 사람은 "잠깐, 이건 운영(prod) 폴더잖아"라고 깨닫는 순간 멈칫하겠지만, 에이전트는 그냥 계속 진행해 버립니다.

저는 제 에이전트를 계속 감시하는 것에 지쳐서, 결국 이를 위한 퓨즈(fuse)를 만들게 되었습니다.

"조심해"라고 말하는 것은 효과가 없습니다

가장 먼저 떠오르는 방법은 에이전트에게 제대로 행동하라고 말하는 것입니다: "파괴적인 명령어를 절대 실행하지 마세요."

하지만 그것은 단지 요청일 뿐, 제어(control)가 아닙니다. 모델은 작업 중간에 그 내용을 잊어버리며, 솔직히 문맥상 무엇이 파괴적인지를 모델이 확실히 구분할 수 있다면 애초에 그런 규칙도 필요 없을 것입니다. 실제로 필요한 것은 에이전트의 판단력이나 그날의 기분에 의존하지 않는 무언가입니다.

실행 전 명령어를 확인하는 훅(hook)

Claude Code에는 도구 호출(tool call)이 실제로 실행되기 전에 작동하여 해당 호출을 차단할 수 있는 PreToolUse 훅이 있습니다. 이것이 바로 핵심 비결입니다.

agent-fuse는 해당 훅에 연결된 작은 스크립트입니다. 에이전트가 어떤 셸(shell) 명령어를 실행하기 전에, 퓨즈는 명령어 텍스트를 살펴보고 다음 세 가지 결정 중 하나를 반환합니다:

• deny — 되돌릴 수 없는 손상, 즉시 차단
• ask — 위험하지만 때로는 의도된 것일 수 있으므로, 사람에게 확인을 위해 일시 중지
• allow — 정상적인 작업, 그대로 통과

이 스크립트는 JSON 프로토콜을 사용하여 Claude Code와 통신합니다. stdin에 들어오는 입력은 다음과 같습니다:

{ "tool_name": "Bash", "tool_input": { "command": "rm -rf /" } }

그리고 출력은 다음과 같습니다:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
...

규칙 자체는 단순한 JSON입니다: 패턴(pattern), 심각도(severity), 그리고 메시지(message)로 구성됩니다.

{
  "id": "gcloud-delete-infra",
  "severity": "block",
...

기본 설정 세트는 흔히 발생하는 실수(footguns)들을 다룹니다: /, ~, 또는 $HOME에 대한 rm -rf; DROP/TRUNCATE; WHERE 절이 없는 DELETE/UPDATE; main 브랜치에 대한 git push --force; terraform destroy; gcloud … delete; 재귀적 버킷 삭제(recursive bucket deletes); dd of=/dev/…; mkfs; curl … | bash. AGENT_FUSE_RULES를 특정 파일로 지정하여 자신만의 규칙을 추가할 수 있습니다.

이 시스템은 에이전트의 말투가 얼마나 확신에 차 있는지가 아니라, 명령어 자체를 판단합니다. 따라서 에이전트가 이번에는 괜찮을 것이라고 아무리 확신하더라도 상관없습니다.

미리 솔직하게 밝혀두고 싶은 부분

여러분은 개발자이므로 어차피 5초 안에 이를 알아차리겠지만, 그냥 직접적으로 말씀드리겠습니다. 이 방식은 명령어를 정규 표현식(regex)으로 매칭합니다. 쉘 파서(shell parser)가 아닙니다.

즉, 다음과 같은 의미입니다:

• echo "DROP TABLE"가 SQL 규칙을 트리거할 수 있습니다 (오탐, false positive).
• 의도적으로 난독화된 명령어 — r""m -rf 또는 base64로 디코딩되어 변수를 통해 조합된 명령어 — 는 이를 통과할 수 있습니다 (미탐, false negative).

하지만 이 시스템이 막아주는 것은 훨씬 더 흔한 문제입니다: 선의를 가지고 행동하지만, 명백하게 작성된 파괴적인 명령어를 실행하는 에이전트입니다. 이것을 장갑판(armor plating)이 아닌 안전벨트(seatbelt)라고 생각하세요. 또한 백업을 대체할 수는 없습니다. 만약 결연한 적대자(adversary)가 걱정된다면 이것은 적절한 도구가 아닙니다. 하지만 여러분의 에이전트가 새벽 2시에 열정적으로 무언가를 삭제할까 봐 걱정된다면, 이것이 바로 그 도구입니다.

현재는 Claude Code의 Bash 도구에만 구체적으로 후킹(hook)됩니다. Cursor/Codex 지원 및 파일 쓰기(file-write) 범위 확장이 다음 계획에 있습니다.

직접 만들거나, 아니면 그냥 제 것을 가져다 쓰거나

이것을 직접 만드실 수도 있습니다. 후킹 부분은 어렵지 않습니다.

실제로 시간이 걸리는 부분은 나머지입니다. 생각할 수 있는 모든 파괴적인 패턴을 나열하고, 각 패턴에 대해 차단(block)할지 질문(ask)할지 결정하며, 일반적인 사용 사례를 망가뜨리지 않았는지 테스트하고, 기존 설정을 백업하면서 안전하게 여러 번 실행할 수 있는 설치 프로그램을 작성하는 일입니다. 그것이 기본적으로 제가 이 작업에 보낸 오후 시간입니다.

코드 자체는 읽을 수 있도록 공개되어 있습니다. 단 하나의 Python 파일로 구성되어 있으며 의존성(dependencies)도 없으므로, "네트워크 호출이 없다"는 주장을 직접 확인하실 수 있습니다. 또한, 패키징되고 큐레이션되었으며 지속적으로 업데이트되는 버전을 $8에 판매하고 있습니다: agent-fuse on Gumroad. 만약 아이디어만 가져가서 직접 버전을 만들고 싶으시다면, 그것 또한 아주 좋은 결과입니다.

어떤 방식이든, 에이전트와 되돌릴 수 없는 명령어 사이에 무언가를 배치하십시오. 자율적인 프로세스(autonomous process)에 귀하의 머신에 대한 루트 권한(root access)을 부여하는 것은, 아마도 우리가 가정용 회로 차단기(circuit breaker)에 부여하는 안전 수준만큼의 주의를 기울여야 할 일입니다.

여러분은 이미 에이전트를 어떤 방식으로든 보호하고 계신가요? 허용 목록(allowlists), 샌드박스(sandboxes), 또는 devcontainer인가요? 실제로 사람들에게 무엇이 효과가 있는지 궁금합니다. 댓글로 알려주세요.