Claude Code에게 "이걸 커밋해도 될까?"라고 물어본 상태에서 잠시 자리를 비웠더니, 돌아왔을 때 파일이 멋대로 수정되어 있었다 —— 그러한 보고가 2026년 7월 3일 GitHub 이슈 #73891로 올라왔다. 아직 아무도 답변하지 않은 새로운 보고다.

이 기사는 비엔지니어로서 Claude Code를 사용하기 시작한 사람들을 위해, 무엇이 일어났는지, 왜 무서운지, 그리고 수동으로 어떻게 방지할 수 있는지를 순서대로 설명한다. 사고 자체는 보고자의 환경에서 발생한 것이며, 나는 해당 이슈를 읽고 구조를 정리했다. 방지법인 hook은 내 환경에서 실제로 작동하는지 확인했다. 전해 들은 부분과 직접 확인한 부분을 명확히 나누어 작성한다.

보고자는 Claude Code에게 커밋 작업을 요청했다. 그러자 Claude Code는 아직 스테이징(staging)되지 않은 변경 사항의 일부에 대해 "이것은 어떻게 할까요?"라고 물었다. 여기까지는 일반적이고, 오히려 친절한 동작이다.

문제는 그 이후다. 보고자는 그 질문에 즉시 답변하지 않았다. 잠시 자리를 비웠던 것으로 보인다. 그리고 돌아왔을 때, Claude Code는 답변을 기다리지 않고 다음과 같이 동작하고 있었다.

• 변경 사항의 일부를 되돌림
• 삭제했을 터인 파일을 복원함
• 코드의 일부를 수정함

모두 보고자가 원하지 않는 조작이었으며, 일부는 수작업으로 되돌려야 했다고 한다.

왜 답변을 기다리지 않고 진행했는지 보고자가 묻자, Claude Code는 다음과 같이 답했다 (이슈 내용의 번역).

타임아웃은 어디서 왔는가. 내가 AskUserQuestion을 호출했을 때, 툴 스스로가 60초의 무응답 후에 시스템 메시지를 반환했다. "No response after 60s — the user may be away from keyboard. Proceed using your best judgment ... (60초 동안 응답이 없음. 사용자가 자리를 비웠을 수 있음. 지금까지의 문맥을 바탕으로 최선의 판단하에 진행해도 좋음. 필요하다면 이 질문은 나중에 다시 물어볼 수 있음)". 이는 이 하네스(harness)에 내장된 동작으로, 내가 설정한 것이 아니며, 새로운 것인지 이전부터 있었던 것인지도 나로서는 알 수 없다. 그 부분은 확인할 수 없다.

즉, 판단을 묻기 위한 메커니즘(AskUserQuestion이라는 툴)에 "일정 시간 답변이 없으면 멋대로 진행해도 좋다"라는 타임아웃이 붙어 있었다는 보고다.

사용자에게 판단을 묻는 동작은 본래 되돌릴 수 없는 조작 앞에서 멈추기 위한 안전장치다. 그런데 그 안전장치에 "답변이 없으면 진행한다"라는 지름길이 있다면 의미가 반전된다.

특히 이번 사고에서 실제로 일어난 "삭제한 파일의 복원"이나 "코드의 수정"은 나중에 보았을 때 무엇이 변했는지 알아차리기 어렵다. 파일이 사라지는 것은 알아차리기 쉽지만, 삭제했을 터인 것이 돌아와 있거나 일부만 수정되어 있는 것은 육안으로 놓치기 쉽다. "질문을 받았다 = 멈춰 주었다"라고 믿고 자리를 비우면, 실제로는 멈춰 있지 않았다는 괴리가 발생한다.

참고로 보고자의 환경은 Platform이 darwin(macOS)이었고, 버전은 2.1.198이었다. 이 60초 만에 진행되는 동작이 모든 환경과 버전에서 동일하게 발생하는지 여부는 이슈 안에서도 "확인할 수 없다"라고 솔직하게 적혀 있다. 내 환경에서도 이 자동 진행 자체를 엄밀하게 재현하지는 않았다 (의도적으로 자신을 60초 동안 방치해야 하며, 대화의 성격상 그 부분은 단정하기 어렵다). 따라서 이 부분은 전해 들은 이야기로 취급한다. 아래의 방지법은 이러한 동작이 일어날 수 있다는 전제하의 대비책이다.

세 가지가 있다. 효과가 확실한 순서가 아니라, 조합해서 사용하는 것이 좋다.

1. 되돌릴 수 없는 조작(커밋, 파일 삭제나 복원, 브랜치 조작 등)을 요청한 후에는 답변을 보류한 채 자리를 비우지 않는다. 이것이 가장 단순하고 확실하다. 자리를 비워야 한다면, 그 전에 위험한 조작이 일단락되는 것을 확인한다.

2. Claude Code는 프로젝트의 CLAUDE.md에 적힌 지시를 읽는다. 여기에 예를 들어 다음과 같이 명시해 둔다.

판단을 물은 후, 답변 타임아웃으로 인해 자율적으로 진행해서는 안 된다.
되돌릴 수 없는 조작은 반드시 사용자의 명시적인 답변을 기다릴 것.

이것은 Claude 측의 판단에 영향을 주는 부탁이며, 후술할 hook과 같은 기계적인 강제는 아니다. 하지만 적어둘 가치는 있다.

Claude Code에는 hook이라는 메커니즘이 있어, 도구가 작동한 후 등에 직접 작성한 스크립트를 삽입할 수 있다. 여기서는 AskUserQuestion의 응답에 "60초간 응답이 없으면 진행해도 좋다"라는 취지의 문구가 포함되어 있다면, 그 이후의 자율 진행을 중단하는 hook을 만든다.

내가 작성하여 직접 실행해 본 것이 다음의 post-askuserquestion-timeout-autoproceed-guard.sh이다.

#!/usr/bin/env bash
# AskUserQuestion이 타임아웃 자동 진행 지시를 반환하면, 그 이후를 중단한다.
set -euo pipefail
...

이것을 settings.json의 hooks 내 PostToolUse에, matcher를 AskUserQuestion으로 설정하여 등록한다. exit 2로 중단하고, 그 이유를 Claude에게 다시 전달한다.

이 스크립트에 상황을 모사한 입력을 표준 입력(stdin)으로 흘려보내어, 기대한 대로 작동하는지 확인했다.

• 타임아웃 자동 진행 응답("No response after 60s ..."를 포함)을 흘려보내면, 종료 코드(exit code) 2로 중단되며 경고를 출력했다.
• 사용자가 평범하게 "Yes"라고 답한 응답을 흘려보내면, 종료 코드 0으로 통과시켰다.
• AskUserQuestion 이외의 도구(Bash) 응답을 흘려보내면, 종료 코드 0으로 통과시켰다.

즉, 중단하고 싶은 장면에서만 중단하며, 일반적인 상호작용이나 다른 도구의 작동을 방해하지 않는다.

이것은 다층 방어(Defense in Depth)의 한 층일 뿐, 완전한 안전밸브는 아니다. 다음 사항들은 감수하고 사용해야 한다.

• 타임아웃 문구나 초 단위 시간은 하네스(harness)나 버전에 따라 변할 수 있다. 문구가 바뀌면 grep 매칭에서 벗어나게 된다.
• 응답 구조가 내 예상과 다른 형태라면, 놓치는 경우가 있을 수 있다.
• 애초에 자동 진행이 일어나지 않는 환경에서는 이 hook은 아무것도 하지 않는다 (그것으로 충분하다).

따라서 위의 "1. 운영" 및 "2. CLAUDE.md"와 병행하여 사용하는 것을 전제로 한다. 기계적 방어는 놓치는 부분이 생길 수 있으므로, 운영과 지시 계층에서 이중으로 방어한다.

• Claude Code의 판단을 묻는 질문(AskUserQuestion)에 60초간 무응답 시 자율 진행하는 타임아웃이 있다는 보고가 이슈 #73891로 올라왔다 (darwin / v2.1.198 · 전언).
• 실제로 삭제한 파일의 복원이나 코드 재작성이 답변을 기다리지 않고 진행되었다는 보고가 있다.
• 방지 방법은 (1) 위험한 작업 후 답변을 보류한 채 자리를 비우지 않는 운영, (2) CLAUDE.md에 "타임아웃 시 자율 진행하지 말 것"을 명시, (3) PostToolUse의 hook으로 타임아웃 문구를 감지하여 중단하는 것, 이렇게 세 가지다. hook은 직접 실행하여 중단하고 싶은 장면에서만 정확히 멈추는 것을 확인했다.

질문을 받았다고 해서 반드시 멈춰준다는 뜻은 아니다. 되돌릴 수 없는 작업 전에는 기계와 운영 양측 모두에 이중의 제동 장치를 걸어두는 것이 좋다.