도구 호출 누락을 감시하기 위해 Claude를 서로 감사하게 만들었더니 74개의 데몬이 돌아가게 된 사연

계기

어느 날, 제가 Claude에게 "지금 몇 시야?"라고 물었을 때, Claude는 자신의 최선의 추측에 기반한 답변을 내놓았습니다.

또 다른 날에는 구성 파일(configuration file)의 내용에 대해 물었을 때, 파일 이름을 바탕으로 한 자신의 추측을 토대로 설명을 제공했습니다. read_file 도구(tool)를 사용할 수 있었음에도 불구하고 사용하지 않았습니다.

처음에는 "Claude가 그냥 피곤한가 보다"라고 생각했지만, 이런 일이 너무 빈번하게 발생했습니다. 프롬프트(prompt)에 "도구를 사용해"라고 적어도 가끔은 잊어버리곤 했습니다.

그때 깨달았습니다: Claude는 자신이 무언가를 모른다는 사실을 스스로 인식할 수 없습니다. 따라서 도구를 가져와야 한다는 사실조차 알지 못합니다.

설령 제가 "도구 호출을 잊지 않도록 주의해"라고 요청하더라도, Claude는 자신이 "이해하지 못했다"는 사실을 모르기 때문에 주의할 방법이 없습니다. 이것은 구조적인 문제였습니다.

시도한 것

그래서, 그냥 감시하는 눈을 하나 더 추가하면 어떨까 생각했습니다.

메인 Claude 외에, 모든 세션에 상주하며 도구 카탈로그(tool catalog)를 완벽하게 숙달하고 있는 감사용 Claude (Haiku 4.5)를 유지하기로 결정했습니다. 이 감사용 Claude는 메인 Claude의 계획된 발화(utterances)와 최종 응답을 병렬로 지켜보며, 도구 호출이 누락되었는지 지적합니다.

상황	메인 Claude의 응답	감사자의 피드백
"오늘 날씨 어때?"	추측하여 응답함	`web_search`를 사용할 수 있습니다
...

핵심은 메인 Claude의 자기 인식(self-awareness)에 의존하지 않는 것입니다. Claude에게 "주의해 주세요"라고 쓰는 대신, 물리적으로 다른 눈을 그곳에 배치했습니다. 판단은 두 단계로 이루어집니다: 사용자가 무언가를 입력하는 순간(요청에 사용되어야 할 도구 목록 나열)과 메인 Claude가 응답을 반환한 직후(사실 관계 주장에 대해 검증 도구를 삽입할 수 있는지 결정)입니다.

저는 이것을 구축하고 claude-spotter라고 이름 붙였습니다.

출시 직후의 실수

저는 이것이 편리한 설계라고 생각했습니다. npm install -g claude-spotter를 실행하면 별도의 설정 없이도 모든 프로젝트에서 자동으로 활성화될 것이었습니다. 완벽하다고 느꼈습니다.

저는 이것을 출시하고 직접 사용하기 시작했습니다.

64분 후, 74개의 데몬 (daemon)이 실행되고 있었습니다.

무슨 일이 일어났는가?

실제 세션 로그를 파헤쳐 보니, 74개 중 51개는 Throughline (저의 또 다른 도구)에 의해 발생한 것이었습니다.

Throughline은 내부적으로 claude -p를 호출합니다. claude -p를 호출하면 SessionStart 훅 (hook)이 트리거됩니다. SessionStart 훅은 Spotter 데몬 (daemon)을 시작합니다. Spotter 데몬은 감사를 위해 다시 claude -p를 호출합니다. 이것은 완전한 무한 재귀 (infinite recursion)는 아니었지만, 재귀적 증식 (recursive proliferation)이었습니다.

postinstall을 통해 ~/.claude/settings.json에 내용을 작성하고 있었기 때문에, 시스템의 모든 Claude Code 세션은 Spotter 훅 (hook)을 로드하도록 구조화되어 있었습니다. 이것이

조사 결과, 이전에 Project B에서 사용했던 MCP 도구 정의들이 글로벌 DB (global DB)에 남아 있었고, 이것이 Project A에서 참조되고 있다는 사실을 발견했습니다. 이는 "사용할 수 없는 도구를 제안하는" 회귀 (regression) 현상이었습니다.

저는 감사자 (auditor)가 사용하는 도구 카탈로그를 **로컬 DB 전용 (local-DB only)**으로 변경했습니다 (v1.2.0). 글로벌 DB는 "다른 프로젝트에서 획득한 경우 설명(description)만 재사용하는 캐시"로 격하되었습니다. 이제 매번 각 프로젝트에서 탐색 (discovery)이 실행되며, 발견되지 않은 도구들은 로컬 DB에서 삭제 (pruned)됩니다.

.cmd로 배포된 MCP가 Windows에서 실행되지 않는 문제

한 가지 문제를 더 발견했습니다. Windows에서 npm-global .cmd로 배포된 MCP를 spawn('claude-mermaid')로 실행하면, 즉시 ENOENT 오류와 함께 실패합니다.

Node.js의 spawn은 Windows에서 CreateProcess를 직접 호출하지만, CreateProcess는 .exe 파일만 해석합니다 (PATHEXT에 있는 .cmd 확장자는 해석하지 않습니다). 이전에 Spotter 자체에서 claude CLI를 실행할 때 cmd.exe /c로 감싸면 작동하는 동일한 패턴을 경험하고 수정했었지만, MCP 서버 실행 경로에는 이 패턴을 적용하는 것을 잊고 있었습니다 (v1.2.2에서 수정됨).

저는 다른 경로를 통해 제가 직접 설정한 함정에 빠졌습니다. 이를 경험하며, 저는 Caveat의 필요성을 강력하게 느꼈습니다. 같은 함정에 두 번 빠지는 것을 방지할 메커니즘이 없다면, 바로 이런 일이 발생합니다.

현재 상태

v1.2.4. Windows, macOS, Linux용 CI가 모두 통과(green)되었습니다.

npm install -g claude-spotter
cd your-project
spotter install

도구 카탈로그는 spotter install 중에 자동으로 수집되며, SessionStart 훅 (hook)이 Claude Code가 시작될 때마다 백그라운드에서 이를 갱신합니다. 수동으로 관리할 필요가 없습니다.

spotter status      # 실행 중인 감사자(auditor) 목록
spotter db list     # 이 프로젝트를 위한 도구 카탈로그
spotter doctor      # 환경 진단
...

여전히 부족한 부분들

Stop 훅(hook)의 수정 작업이 두 번의 연속된 응답을 생성합니다. 메인 Claude가 응답을 반환한 후에 훅이 실행된다는 사양 때문에, 훅이 수정 응답을 발행하면 사용자는 "초기 응답 + 수정 응답"을 연달아 보게 됩니다. 입력 단계(UserPromptSubmit)에서 이를 선제적으로 처리하고, 응답 후 훅(post-response hook)은 보험용으로 사용하는 것이 이상적일 것입니다.
Haiku의 타임아웃으로 인해 사용자 입력이 차단됩니다. 현재는 실패 시 허용(fail-open, 우회하여 통과시킴)할지 여부를 고려 중입니다.

Throughline / Caveat과의 관계

Spotter는 동일한 제작자가 만든 Throughline 및 Caveat과 철학을 공유하는 별개의 제품입니다.

	Throughline	Caveat	Spotter
철학 (Philosophy)	뺄셈 (Subtraction)	누적 (Accumulation)	덧셈 (Addition)
...
이 세 가지의 공통점은 "메인 Claude 엔진에 의존하지 않는 메커니즘"이라는 점입니다. 세 가지 모두 공존할 수 있습니다.

요구 사항

Node.js 22.5 이상
Claude Code 2.0 이상
Claude Max Plan (claude -p로 Haiku 4.5를 실행하기 위함)

Spotter — GitHub

MIT License. 만약 동일한 문제로 어려움을 겪고 계신다면, 관심 있는 분들은 편하게 살펴보시기 바랍니다.