클로드 코드의 빌드-체크 로직 디버깅: 이름 검색 실패 원인과 구조적 풋프린트 검색의 해결책

r/ClaudeAI의 한 개발자가 클로드 코드가 기존 기능을 반복적으로 감지하지 못해 'X가 구현되었나요?'라는 질문에 한 세션에서 네 번 모두 '아니요'라고 답했으며, 매번 해당 기능이 이미 존재했다고 보고했습니다. 근본 원인: 에이전트가 구조적 발자국(라우트, 스키마, 등록된 도구, 예약된 작업, 문서화된 결정) 대신 이름(키워드, 동의어)으로 검색했기 때문입니다. 이름은 변하지만 아키텍처 아티팩트는 변하지 않습니다.

패턴

'이 기능이 이미 구축되었나요?'라는 질문에 기능이 부분적으로 구현되었음에도 '아니요, 이렇게 구축하면 됩니다'라는 확신에 찬 답변이 나왔습니다. 매번 사용자가 반박하여 실제 답변을 이끌어내야 했습니다. 개발자는 에이전트가 검색은 하지만 다른 명명 규칙을 가진 코드를 놓치는 어휘 기반 쿼리를 사용한다고 진단했습니다.

규칙 (구조적 발자국 검색)

종합된 규칙은 에이전트가 이름이 아닌 형태로 검색하도록 강제합니다. 예를 들어, '기능 X 찾기' 대신 '어떤 플러그인 도구가 존재하나요?' 또는 '이 기능과 일치하는 라우트, 스키마, 등록된 작업은 무엇인가요?'라고 묻습니다. 이렇게 하면 이름 검색으로는 절대 찾지 못했을 이전 코드를 포착할 수 있습니다.

핵심 전환: '더 나은 동의어로 검색하는 것은 여전히 이름으로 검색하는 것입니다. 발자국 버전은 이를 포착합니다(이전 코드가 플러그인 도구를 등록했고, '어떤 플러그인 도구가 있나요?'는 신호가 강한 좁은 검색입니다).'

커뮤니티에 요청한 피드백

• 구조적 발자국 검색이 잡지 못할 환각 형태
• 형식은 갖췄지만 내용이 없는 감사-극장 패턴
• 실제 부재 주장이 아닌 질문에 과도하게 반응
• 확신 증폭: 감사 후 에이전트가 결론에 더 확신을 가지게 되어 잘못된 온톨로지 오류를 잡기 더 어려워짐
• 잘못된 온톨로지의 엄격함: 에이전트가 REST 시스템에서 GraphQL 패턴을 검색하고 아무것도 찾지 못해 부재를 확인함

개발자는 별도의 프로젝트에서 2-3주간 이 규칙을 테스트한 후 전역 설정을 고려할 예정입니다. 다른 사람들이 '엄격함을 동반한 환각'(단순한 환각이 아닌)을 해결한 규칙을 공유해 주기를 초대합니다.