Claude Code를 거의 24시간 내내 자율적으로 실행하고 있다. 셸(Shell)과 Git에도 접근할 수 있는 상태로, 내가 잠든 사이에도 세션이 계속 움직인다.

이런 운용을 하다 보면 한 가지 두려운 질문이 남는다. 아무도 보고 있지 않은 시간에, 이 에이전트(Agent)는 내 머신에 대해 무엇을 하려고 하는가.

나는 PreToolUse 후크를 통해 차단된 위험한 명령어를 모두 로그(Log)로 남기고 있다. 이번에 그 로그를 4개월 분량으로 모아서 직접 파헤쳐 세어보았다. 결론부터 말하겠다. 헤드라인이 될 법한 큰 숫자를 그대로 적는다면 그것은 거짓말이 된다. 그리고 거짓을 벗겨낸 뒤에 남은 것이 헤드라인보다 훨씬 유용하다. 이 기사는 타인의 사고를 소개하는 것이 아니라, 자신의 환경에서 실행 중인 에이전트의 로그를 직접 다시 계산한 실측 기록이다.

차단 기록은 99,402건이었다. "AI의 안전 후크가 4개월 동안 약 10만 건의 위험 조작을 막았다"라고 쓰고 싶어진다. 하지만 쓸 수 없다.

생 데이터(99,402건)를 그대로 기사에 쓰면 거짓말이 된다. 내역을 살펴보면 이유를 알 수 있다.

• 유니크(Unique)한 명령어는 337건뿐이다. 나머지는 대부분 같은 명령어를 재시도한 것이다. 에이전트는 차단당하면 같은 조작을 수단을 바꿔가며 몇 번이고 시도한다. 그래서 하나의 조작이 수백~수천 행으로 불어난다.
• 일별로 보면, 2026년 3월 22~30일에 약 87,000건이 집중되어 있었다. 이는 후크 자체를 개발하고 테스트 세트를 수천 번 돌리던 시기로, 실제 운용에서 위험을 포착한 기록이 아니다.
• 3월의 테스트 기간을 제외한 실제 운용기(4~7월)로 한정하면 10,351건이다. 같은 명령어의 재시도를 묶어 유니크하게 만들면 223건까지 떨어진다. 게다가 이 223건 중에도 후크 테스트용 주석 행이나 변수 대입이 차단에 휘말린 것이 수십 건 섞여 있다. 순수한 위험 조작만을 세면 더 적다.

10만이 223이다. 대략 450배의 부풀리기다. 자신의 로그를 기사 소재로 쓸 때 생 데이터를 그대로 사용하면, 이 450배의 수치를 독자에게 팔아넘기는 꼴이 된다.

223건을 더 자세히 살펴보며, 나는 내 기사가 가질 위험성을 깨달았다.

로그에는 rm -rf /나 Remove-Item -Recurse -Force / (WSL2의 Windows 측을 통째로 지우는 형태)가 몇 번이고 나열되어 있다. root나 home을 지우는 형태는 실제 운용기에서만 약 2,000행에 달한다. 숫자만 보면 "무인 AI가 root째로 지우려 했던 흔적이 수천 건"——공포를 조장하기에는 충분한 소재로 보인다.

하지만 한 건씩 내용을 직접 확인하자 손이 멈췄다. 이 약 2,000행은 같은 몇 종류의 형태가 반복해서 기록된 것이었다. 게다가 rm -rf /처럼 공백의 수만큼 다른 버전들이 나열되어 있다. 에이전트가 입력할 리 없는 부자연스러운 형태이며, 게다가 같은 묶음이 4월에도 5월에도 6월에도 나타난다. 실제 기기에서 확인해보니, 이것은 정규 표현식(Regular Expression)이 놓치지 않고 잡아낼 수 있는지 검증하는 나 자신의 회귀 테스트(Regression Test) 흔적이었다. 에이전트가 정말로 root를 지우러 간 것이 아니었다.

만약 여기서 "내 AI는 root를 지우려 한 흔적이 수천 건 있다"라고 썼다면, 그것은 허구였다. 안전을 파는 기사에서 숫자를 지어낸다면, 지키고자 하는 것을 스스로 파괴하는 것이다. 위험할 뻔했다.

자신의 테스트를 제외하고, 에이전트가 실제 운용 중에 정말로 반복해서 시도하다가 차단된 조작은 소박한 것들이었다. 대부분이 force 계열의 Git 조작이다.

git reset --hard origin/main (유니크하게 35건) —— 리포지토리(Repository)를 origin에 맞춘 뒤 작업 브랜치를 만드는 전처리.

git checkout --force / git checkout -f <branch> —— 다른 브랜치로 강제 전환.

git clean -fd —— 추적되지 않는(Untracked) 파일을 일소.

모두 실재하는 브랜치 이름(feat/feature-deprecation-detector-2026-05-27 같은)이나 날짜가 붙어 있어, 에이전트가 실제 업무 흐름 속에서 수행한 조작임을 알 수 있다. 그리고 그 대부분은 해당 문맥에서는 안전했다. 동기화하고 브랜치를 나누는 것뿐이니까.

그럼에도 후크는 이 종류를 통째로 차단한다. 왜일까. 후크에는 "안전한 동기화"와 "커밋되지 않은 3시간 분량의 작업을 덮어쓰는 순간"을 구분할 수 없기 때문이다. git reset --hard는 대개 무해하지만, 가끔 모든 것을 지운다. 구분할 수 없는 이상, 클래스(Class) 전체를 차단할 수밖에 없다.

이 부분이 이번에 가장 전달하고 싶은 내용이다.

정말로 데이터를 잃게 만드는 것은 rm -rf /와 같은 화려한 조작이 아니다. 지루한 조작이다.

내 로그에서 실제 운영 환경에 남았던 것도 화려한 명령어가 아니라 force 계열의 Git 조작이었다. 그리고 공개된 사고 티켓(Issue)들을 봐도, 데이터가 삭제되는 형태는 대부분 수수한 방식이라는 보고가 많다. 서브 에이전트가 git checkout으로 강제적으로 브랜치를 전환하여, 아직 커밋하지 않은 작업을 덮어쓰고 지워버린다. 혹은 mv가 조용히 실패한 뒤, 비어있을 것이라 생각한 디렉토리에 rm -rf가 이어서 실행되어, 방금 옮긴 파일이 아직 원래 위치에 있었음에도 삭제되는 식이다 (GitHub 이슈 #72625에서 이 흐름이 보고되어 있다). 화려함은 없다. 하지만 결과는 같으며, 되돌릴 수 없다.

모두 99번을 수행하면 99번 모두 무사히 끝나는 조작들이다. 100번째, 그곳에 미커밋(uncommitted) 작업이 있었을 때만 조용히 전부 사라진다. 에이전트는 rm -rf /와 같은 알기 쉬운 파멸을 일으키지 않는다. 일으키는 것은 이 지루하고, 대개 안전한 조작들이다. 그렇기에 더 위험하다. 인간도 AI도 '대개 안전함'을 계속 경계하는 데는 서투르기 때문이다.

"모델은 똑똑하니까 그런 짓은 안 할 것이다"라는 생각은 대책이 되지 않는다. 똑똑한 모델이라도 100번째의 미커밋 상황 한 번은 겪게 된다. 매번 확실하게 막을 수 있는 것은, 명령어가 실행되기 전에 결정적으로 판정하는 PreToolUse의 그물뿐이다. "대개 조심하고 있다"는 보장이 아니다. 결정적인 그물만이 보장이 된다.

이것은 유료 서비스를 구매하지 않아도 오늘 바로 시작할 수 있다. 위험 조작을 차단했을 때 한 줄만 남기는 작은 PreToolUse 후크(Hook)면 충분하다.

#!/bin/bash
# 차단된 위험 명령어를 한 줄만 남기는 최소 후크.
# settings.json의 PreToolUse(Bash)에 등록하여 사용.
...

이것을 몇 주간 돌려본 뒤, 자신의 로그를 이번의 나처럼 솔직하게 세어보길 바란다. 생(raw) 건수가 아니라, 테스트와 재시도를 제외한, 정말로 자신의 에이전트가 시도한 조작을 말이다. 아마 화려한 파멸은 거의 없고, 지루한 force 계열의 조작들이 수수하게 나열되어 있을 것이다. 그곳이 당신의 데이터가 실제로 사라질 수 있는 지점이다.

내가 실제 운영에서 쌓아온, 이런 종류의 "지루하지만 정말로 위험한" 조작을 막는 후크 모음과 그 이면에 있는 실제 사고 기록은 사고 방지를 위한 책(¥800)에 정리해 두었다. 오늘부터 바로 사용할 수 있는 후크가 필요한 사람은 그쪽이 빠를 것이다.

• Claude Code 사고 방지 핸드북: https://zenn.dev/yurukusa/books/6076c23b1cb18b