지난번에는 몇몇 프로젝트의 AI 기억 라이브러리를 체계적으로 '제초(weeding)'하며, 기억이 열화되는 여섯 종류의 '잡초'를 정리했습니다. 하지만 제초를 진행할수록 확신이 강해졌습니다——수작업 제초는 대증요법에 불과하다는 것을 말입니다. 기억 시스템 자체에 '자기 점검' 메커니즘이 없는 한, 잡초는 뽑아도 다시 자라납니다. 그래서 지난번 마지막에 스스로에게 숙제를 남겼습니다——'자동으로 건강검진을 해주는 기억 도구를 만든다'. 이 기사는 그 숙제의 제출물입니다.

먼저, 이 도구가 무엇을 하는 것인지 말씀드리겠습니다. 이야기은 거기서부터 시작됩니다.

기억 라이브러리 전속 의사라고 상상해 보세요. 특정 프로젝트의 기억 라이브러리를 지정하면, 처음부터 끝까지 스캔하여 발견한 문제를 하나씩 눈앞에 나열합니다——이 링크는 끊어져 있다, 그 기억은 폴더를 잘못 지정했다, 이 두 개는 모순되어 보인다……. 그리고 거기서 멈춰, 건별로 '어떻게 할지'를 당신이 결정하기를 기다립니다.

이 '당신이 결정하기를 기다린다'를 가장 먼저 배치한 데에는 이유가 있습니다. 그것이 도구 전체의 성격을 결정하기 때문입니다——보는 것과 전달하는 것만을 담당하며, 손은 대지 않습니다.

🩺 '보기'만 할 뿐——당신을 대신해 손을 대지 않는다

왜 이렇게 설계했는가. 지난번의 가장 뼈아픈 교훈으로 돌아가겠습니다——기억을 삭제하는 것과 같은 일은 AI에게 통째로 맡겨서는 안 됩니다. 어떤 것을 깎아낼지, 어떤 것을 통합할지 제안하는 것은 괜찮지만, 마지막에 도장을 찍는 것은 사람이어야 합니다. 깎여 나가는 것은 대개 이력 기록이며, AI는 기세에 밀려 중요한 것까지 함께 지워버리기 쉽습니다.

그래서 도구를 만들 때, 이 교훈을 하나의 절대 규칙으로 삼았습니다——프로그램 어디에도 기억 파일을 스스로 수정하거나 삭제하는 코드 패스(code path)는 존재하지 않습니다. 스캔하고, 문제마다 가중치를 매기고, 해결 방법까지 준비하여 나열할 수는 있습니다. 하지만 실제로 '변경'이나 '삭제'를 누르는 한 수는 당신 자신의 것입니다.

이렇게 말하면 손해처럼 들립니다——도구를 만들어 놓고 가장 일할 수 있는 부분을 잘라냈으니까요. 하지만 바로 이 억제력이 있기에 매일 켜놓고 사용할 수 있는 것입니다. 멋대로 기억에 손을 대는 도구였다면, 저는 한 번도 사용할 엄두를 내지 못했을 것입니다.

ツールはスキャン・重みづけ・提案だけ。変更や削除の一手は、いつもあなたが押す

🔍 기계는 '명백한 상처'를, Claude는 '의미'를 읽는다

손을 대지 않는다는 이야기를 했으니, 다음은 무엇을 찾아낼 수 있는가입니다. 도구가 잡아내는 문제는 사실 두 종류이며, 다루는 방식이 완전히 다릅니다.

하나는 기계가 한눈에 판정할 수 있는 명백한 상처입니다——링크가 가리키는 파일이 존재하지 않음, 기억이 폴더를 잘못 지정함, 명명 규칙이 규약에 어긋남……. 이것들은 내용의 이해를 필요로 하지 않으며, 규칙 대조로 결판이 나고 오판하지 않습니다.

다른 하나는 훨씬 까다롭습니다. 예를 들어 '이 두 기억이 서로 모순되는가'는 표면적인 글자만으로는 판정할 수 없으며, 각각이 무엇을 말하고 있는지 정말로 읽어야 합니다. 이런 종류의 작업에는 언어를 이해할 수 있는 모델이 필수적입니다. 다행스럽게도 이 도구는 원래 Claude Code의 플러그인입니다. 실행 시에는 바로 옆에 Claude가 있습니다——의미를 읽을 수 있는, 완성된 모델이 그곳에 있는 것입니다. 굳이 다른 것을 외장으로 추가할 필요가 없습니다.

따라서 명백한 상처는 로컬의 작은 엔진으로——인터넷에 연결하지 않고, 어떤 모델도 호출하지 않으며, 동일한 라이브러리라면 매번 완전히 동일한 결과를 반환합니다. 의미 이해를 요하는 판단은 호스트인 Claude——바로 지금 당신과 함께 작업하고 있는 모델에게 넘깁니다. 이렇게 나누면 도구는 API key를 일절 필요로 하지 않고, 외부 서비스에도 의존하지 않으며, 기억 내용은 단 한 글자도 단말기 밖으로 나가지 않습니다.

明白な傷はローカルエンジンへ、意味の判断はホストの Claude へ——二層がそれぞれの担当を持つ

이 사고방식에 따라 체크를 세 단계로 나열했습니다. 가장 확실한 것부터 가장 머리를 쓰는 것으로.

• 정적 체크 (Static Check, 명백한 상처): 엔진의 주력이며, 빠르고 정확합니다. 데드 링크 (Dead Link, 명명 규칙이 하이픈에서 언더스코어로 바뀌어 링크가 조용히 끊어짐), 공중에 뜬 인덱스 (Index, 인덱스에는 등록되어 있으나 파일이 없음), 고립된 기억 (파일은 있으나 인덱스에 등록되지 않음), 필드 누락, 명명 불비, 폴더 오류 등이 해당합니다. 모두 기계가 한눈에 파악할 수 있으며 오판하지 않는 상처들입니다.
• 추측 (Clue, 단서): 예를 들어 「개발 중」 「승인 대기」라고 적힌 채 오랫동안 업데이트되지 않은 기억은, 대개 용건이 이미 끝났음에도 상태(Status)만 얼어붙어 있는 경우입니다. 이 단계에서 나오는 것은 단서이지 단정이 아닙니다.
• 의미 읽기 (Semantics): 지난번 가장 까다로웠던 두 가지 「잡초」——프로젝트가 글로벌 규칙을 다시 복사한 「고스트 카피 (Ghost Copy)」와, 반대로 보이지만 실제로는 각각 다른 장면을 담당하고 있는 「가짜 모순」——은 내용을 읽어 들이지 않으면 판정할 수 없습니다. 이 단계는 호스트인 Claude에게 맡깁니다. Claude가 읽고 제안하면, 판단은 제가 내립니다.

세 단계를 모두 거치면, 툴은 문제를 빨강·노랑·초록으로 가중치를 두어 분류하고, 하나씩 함께 확인해 나갑니다. "이 데드 링크를 고칠까요?" "이 고립된 기억을 인덱스에 추가할까요?" "이 얼어붙은 상태는 이미 종료된 것인가요?" 당신이 「고친다」라고 말한 것만 고치며, 건너뛴 것에는 일절 손대지 않습니다.

⏰ 때가 되면 알려준다——하지만, 시끄럽게 하지는 않는다

건강검진만으로는 부족합니다. 기억 유지보수의 최대 적은 「고치는 방법을 모르는 것」이 아니라, 애초에 고치는 것을 잊어버리는 것이기 때문입니다. 지난번에 기억은 정기적인 관리가 필요하다고 썼지만, 「정기적」이라는 것을 의지(기합)에 맡기면 실질적으로는 제로가 됩니다.

그래서 툴에 리마인드(Remind) 기능을 추가했습니다. 작업을 시작할 때마다, 현재 프로젝트의 기억 라이브러리가 오랫동안 점검되지 않았다면, 살며시 한마디 「🩺 마지막 점검으로부터 N일 경과」라고 알려줍니다.

하지만 리마인드는 너무 많으면 노이즈가 되고, 노이즈는 무시됩니다. 그래서 두 가지 제약을 걸었습니다. 하루에 기껏해야 한 번, 세션마다 튀어나오지 않도록 말이죠. 그리고 정말 번거롭다면 명령어 하나로 멈출 수 있습니다.

点検リマインドは一日に一度、限られた枠でだけ現れる。煩わしければコマンド一つで止められる

📌 지금 할 수 있는 것, 할 수 없는 것

솔직히 말씀드리겠습니다.

할 수 있는 것: 6개의 탐지기, 구형 포맷 기억의 이행 제안, 일-영 바이링구얼 (Bilingual) 출력——지금은 모두 작동합니다. 저의 9개 프로젝트 기억 라이브러리를 하나씩 점검하여, 데드 링크·오래된 명명·얼어붙은 상태를 한꺼번에 정리했습니다.

할 수 없는 것 (이 또한 의도적으로 그어둔 선입니다):

• 의미 이해를 요하는 판단은 마지막에 사람의 끄덕임(동의)이 필요합니다. 툴은 조언할 뿐입니다.
• 당신을 대신하여 멋대로 무언가를 다시 쓰는 일은 결코 하지 않습니다.
• 작은 라이브러리나 새로운 라이브러리에서는 효과가 제한적입니다. 정말로 본전을 뽑을 수 있는 것은 오랫동안 쌓아 올린 큰 라이브러리입니다.

기억을 다루는 툴이 가장 하지 말아야 할 일은 독단적으로 움직이는 것입니다.

툴 자체는 현재 개인용이지만, 첫 줄부터 오픈 소스 (Open Source) 기준으로 작성하고 있습니다. 테스트 완비, 깨끗한 히스토리, 일어와 영어 양쪽의 문서화까지 말이죠. 언제 어떻게 공개할지는 제가 충분히 사용해 보고 신뢰할 수 있게 되었을 때 결정하겠습니다. 따라서 이 글에는 링크를 올리지 않습니다. 클릭했는데 헛수고하게 만들고 싶지 않기 때문입니다.

💡 되돌아보며 얻은 세 가지 배움

• 「손을 대는」 툴에는 먼저 경계를 정해야 한다. 조작이 되돌릴 수 없을 정도로 유능한 툴은 위험해집니다. 「결코 독단적으로 움직이지 않는다」를 절대 규칙으로 삼았기에 안심하고 사용할 수 있는 것입니다.
• 리마인드나 알림을 만든다면, 「멈출 수 있는 스위치」를 남겨두는 것을 잊지 마라. 메시지를 어떻게 사용자에게 전달할지만 생각하다가 자칫 잊곤 합니다. 끈질긴 리마인드는 결국 무시됩니다. 멈출 수 있는 리마인드야말로 정말로 읽히는 법입니다.
• 자신이 만든 툴은 자신이 먼저 엄격한 첫 번째 사용자가 되어야 한다. 형태만 갖춰서 끝내지 않고, 정말로 업무에 사용해야만 오판이나 간과한 부분이 하나씩 드러나게 됩니다.

다음 회차: loop에 대해 이야기하자

기억에 대해서는——구축부터 잡초 제거, 그리고 이번 건강검진 툴까지——여기서 일단락입니다. 다음 회차는 화제를 바꿔서, loop에 대해 이야기하겠습니다. AI를 일정한 리듬으로 스스로 달리게 하여, 반복되는 일을 제가 감시하지 않아도 계속하게 만드는 방법에 대해서입니다.

만약 여러분도 AI의 기억 라이브러리 (memory library)를 키우고 있거나, 혹은 자신의 도구에 "이 선은 넘지 않는다"라는 규칙을 몇 가지 설정하려 한다면, 이 글이 조금이라도 도움이 되기를 바랍니다. 유익했다고 느끼신다면, '좋아요'를 누르거나 AI 기억에 대해 똑같이 고민하고 있는 누군가에게 공유해 주시는 것이 무엇보다 큰 격려가 됩니다. 여러분의 공유 한 번이 글을 계속 써 내려갈 힘이 됩니다.

Discussion