Claude Code에 「이제 사용하지 않는다」라고 구두로 전달하는 것만으로는, memory/나 규칙 파일은 업데이트되지 않는다. 이 기사에서는 업데이트가 누락된 파일이 여러 곳에서 일관성을 유지한 채 남아있었던 사례와, 「일관된 문서가 많을수록 AI가 의심하기 어려워진다」는 구조적인 문제에 대해 기술한다.

어느 날, AI에게 「Cowork은 이제 사용하지 않는다」라고 전달했다. 업데이트되었을 것이라고 생각했다.

2026년 4월 29일, 내가 그 착각을 깨달은 것은 AI가 몇 주가 지난 후에 「Cowork 세션으로부터」라는 말을 사용했을 때였다. 하지만 신호는 훨씬 전부터 나오고 있었다. 알고 있었음에도 불구하고 그냥 넘겨버렸던 것이다.

이 기사에서는 「전달함 ≠ 업데이트됨」이라는 구조와, 「일관된 문서가 많을수록 의심하기 어려워진다」는 역설에 대해 기술한다.

Claude Code는 「전달함」만으로는 기억 파일을 업데이트하지 않는다

Claude에게 무언가를 전달했을 때, 인간은 종종 「업데이트가 완료되었다」고 느낀다. 대화를 했으니 상대에게는 전달되었을 것이다 —— 거기까지는 맞다. 하지만 Claude의 동작은 대화 문맥뿐만 아니라, 세션을 넘어 참조되는 기억 파일(memory files)이나 규칙 문서에 의해서도 지탱된다.

나는 Cowork 이용을 중단했을 때, 그 취지를 Claude에게 전달했다. 하지만 실제로는 3개의 파일이 Cowork을 전제로 한 채 남아 있었다:

memory/project_cowork_operation.md
— 「현재도 Cowork과 병용하고 있다」는 기술 -
global-rules.md
— 「Cowork 세션에서 소재를 채굴할 때는 ~를 따른다」는 규칙 -
content/writing/books/series-2/2026-04-26_concept.md
— [cowork-session] 태그의 설명문

Claude는 거짓말을 하고 있었던 것이 아니다. 참조하고 있는 파일에 적혀 있는 내용을 충실히 지키고 있었을 뿐이다. 문제는 내가 그 파일을 업데이트하지 않았다는 데 있다.

Claude Code가 옛날 말을 계속 사용했다 —— 기억 파일의 업데이트 누락이 원인이었다

발각되기 전, Claude가 「Cowork」라는 말을 사용하는 장면이 몇 번 있었다. 그때마다 나는 「아, 그렇구나」라고 생각하며 다음 화제로 넘어갔다.

어떤 때는 Zenn Book 2권째의 소재 노트를 정리하는 세션에서, Claude가 「Cowork 세션에서 채굴한다」는 전제로 제안을 구성해 왔다. 나는 Cowork을 그만둔 상태였으므로, 그 제안의 전제는 애초에 성립하지 않는다. 다른 장면에서는 global-rules.md의 규칙이 Cowork 이용을 전제로 한 채 계속 적용되고 있었다.

멈추지 않았던 이유는 단순하다. **「뭐, 문맥은 이해하고 있겠지」**라는 방심이었다.

생각해 보면, 이 신호는 매우 낮은 비용으로 처리할 수 있었을 것이다. Claude가 옛날 말을 사용했을 때, 「그것은 이제 사용하지 않는다. 어느 파일에 기재되어 있지?」라고 한마디 물어봤으면 좋았을 것이다. 처음 한 번만이라도 멈췄다면 문제는 거기서 끝났을 것이다.

실제로 문제가 발각된 것은, 다른 작업을 하던 도중에 「Cowork 세션」이라는 태그 기술이 우연히 눈에 들어왔을 때였다. 「어라, 이거 이제 사용하지 않는 것일 텐데」라고 생각하며 조사해 보니, 3곳의 파일이 일관되어 있음이 판명되었다.

왜 Claude Code는 오류를 의심하지 않는가 —— 일관된 기억 파일의 함정

이 문제에는 두 가지 층위가 있다.

제1층: 인간의 착각

「전달함 → 업데이트됨」이라는 전제가 자동으로 성립해 버린다. 어떤 파일이 업데이트되었는지 나는 확인하지 않았다. 대화를 통해 전달은 완료되었지만, 파일의 업데이트는 별개의 문제다 —— 이 구분을 의意识하지 못했다.

제2층: AI의 일관성 편향 (Consistency Bias)

한 곳만 옛날 기술이 남아 있다면 「오래된 정보일지도 모른다」고 의심할 계기가 될 수 있다. 하지만 이번에는 3곳이 같은 방향으로 일관되어 있었다.

Claude에게 이것은 사실의 뒷받침으로 보인다. 여러 문서가 같은 말을 하고 있으니, 그것이 현실이라는 인식이 된다. 일관된 문서가 많을수록 AI는 그 전제를 의심하기 어려워진다. 이는 언뜻 반직관적이지만, 생각해 보면 당연한 이야기다. 증거가 쌓일수록 확신은 높아진다 —— 설령 그 증거가 모두 틀렸더라도.

이 문제가 일어나기 쉬운 것은 세션을 넘어 계속 참조되는 파일이다. memory/ 하위의 프로젝트 상황 메모, CLAUDE.md의 운용 규칙, global-rules.md

등이 그 대표적인 사례로, 한 번 작성된 기술이 장기간 그대로 남아있기 쉽다. "그만두었다" 혹은 "바꿨다"는 타이밍에 이러한 영속 참조 파일(permanent reference files)을 의식적으로 확인하는 습관이 유효하다.

memory 파일의 업데이트 누락을 "방치했을" 경우와 "멈췄을" 경우

이전에 다른 기사에서 "AI가 품질 게이트(Quality Gate)를 건너뛴" 사례를 쓴 적이 있다. 그때 나는 "묘하게 빠르다"라는 위화감을 느끼고, "어라? 테스트 실시했어?"라고 한마디 확인했다. 그것만으로 문제를 조기에 발견할 수 있었다.

이번 사례와의 구조적인 차이는 단순하다.

두 사례 모두 시그널 자체는 나오고 있었다. 차이는 "처음 한 번에 멈췄는가"뿐이다.

(품질 게이트 스킵 사례에 대해서는 별도로 기록하고 있다(근시일 내 공개 예정). 본 기사를 그와 대칭되는 사례로 읽어준다면 구조가 더욱 선명해질 것이다.)

CLAUDE.md와 기억 파일의 업데이트 누락을 방지하는 3단계

이 경험을 통해 나는 하나의 규칙을 세웠다.

AI가 "사용하지 않을 법한 단어"를 사용했을 때, 그것을 업데이트 누락의 시그널로 처리한다.

구체적인 대처는 단순하다:

• "그것은 이제 사용하지 않아. 어느 파일에 기재되어 있지?"라고 묻는다.
• 해당 파일을 리스트업하게 한다.
• 불필요한 기술을 삭제하거나 업데이트한다.

이 확인에 필요한 시간은 30초 정도다. 문제를 방치하면 일관성을 유지한 채 잘못된 기술이 축적되어 간다. 반면 처음에 멈춘다면 그것으로 끝난다.

조금 더 구조적으로 접근한다면, "무언가를 그만두었을 때", "도구를 바꿨을 때", "방침을 바꿨을 때"라는 타이밍에 관련 파일을 함께 업데이트하는 습관을 갖는 것이 좋다. 변경을 "구두로 전달"하는 것에서 끝내지 않고, "어느 파일이 영향을 받는가"를 확인하는 단계를 하나 더 거친다.

"전달했다"만으로는 업데이트되지 않는다 —— 문서 관리의 책임은 인간에게 있다

이 문제의 핵심은 "AI가 거짓말을 했다"가 아니다. "인간이 업데이트하지 않은 파일을 AI가 충실히 계속 지켰다"이다.

AI는 문서에 적혀 있는 것을 전제로 움직인다. 그 문서를 올바르게 유지할 책임은 인간 측에 있다. 그리고 일관성을 유지하는 문서가 많을수록 오류를 의심하기 어려워지는 구조상, 오래된 기술의 방치는 조용히 증식한다.

시그널은 나오고 있었다. 처음 한 번에 멈췄다면 끝날 일이었다.

이 기록이, 똑같이 방치하고 있는 사람들에게 "한 번 멈추는" 계기가 된다면 그것으로 충분하다.

관련: Zenn Book 시리즈

본 기사에서 다룬 "규칙 관리", "에이전트 조직의 운용"에 대해 더 자세히 쓴 Zenn Book 시리즈가 있습니다.

• 코드를 쓸 줄 모르는 내가 Claude Code로 "AI 팀"을 만들기까지 (Vol.1)
• 코드를 쓸 줄 모르는 내가 Claude Code로 "AI 팀"을 운영하기까지 (Vol.2)
• 코드를 쓸 줄 모르는 내가 Claude Code로 "AI 팀"과 계속 써 내려가기까지 (Vol.3)

관련 서적

Claude Code의 실천적인 사용법을 더욱 깊게 배우고 싶은 분들에게는 다음 Kindle 도서가 참고가 됩니다.

Claude Code를 이용한 AI 주도 개발 입문 (히라카와 토모히데 저) — Claude Code를 사용한 AI 주도 개발의 전체상을 해설한 입문서. memory 파일이나 CLAUDE.md의 위치를 이해하는 맥락에서도 읽기 쉽다.

이 기사는 はてなブログ(Hatena Blog)로부터의 크로스 포스트입니다.

Discussion