Claude Code가 메모리 폴더를 계속 다시 읽으며 컨텍스트를 낭비해서, 대신 데이터베이스처럼 쿼리하도록 바꿨습니다.

마크다운 메모는 Claude Code랑 쓸 때까진 좋은데, 양이 많아지면 답이 없음. CLAUDE.md 하나가 노트 폴더가 되고, 그 폴더가 수백 개 파일로 불어나면, 매 세션마다 Claude가 절반을 다시 읽느라 컨텍스트 윈도우 다 잡아먹거나, 아니면 grep으로 대충 찾다가 중요한 거 다 놓치게 됨. grep은 뭐가 결정 사항이고, 뭐가 할 일이고, 뭐가 그냥 단어만 포함된 글인지 구분 못 하니까. 보통 그다음 단계로 임베딩을 쓴 메모 MCP를 도입하는데, 그럼 이제 내 메모는 열어볼 수도, 수정할 수도, diff를 뜰 수도 없는 벡터 인덱스 덩어리가 돼버림.

난 다른 방식을 택했음. 폴더는 그대로 두고, 쿼리 언어를 추가한 거임. Claude가 내 노트에서 진짜로 필요한 건 대부분 구조화된 정보거든. 뭐가 아직 안 끝났는지, X에 대해 뭘 결정했는지, 어떤 노트가 이 서비스를 언급하는지 같은 거. 이런 게 다 WHERE 절임:

iwe find --included-by decisions \ --references services/payments \ --filter 'status: accepted'

이게 뭔 뜻이냐면: payments 서비스를 언급하는 'accepted' 상태의 결정 사항을 찾으라는 거임. 노트 간의 링크는 JOIN이 되고, 프론트매터(frontmatter)는 스키마가 되고, 파일 경로는 기본 키(primary key)가 되는 식임. 처음부터 끝까지 그냥 평범한 마크다운이야. 에디터에서 원래 하던 대로 파일을 수정하면 되고, git diff로 Claude가 뭘 바꿨는지 정확히 볼 수 있음.

Claude Code랑 쓸 때 특히 좋았던 점들:

• Rust로 만든 바이너리 하나라 Claude가 그냥 bash에서 바로 실행함. 원하면 MCP 서버를 쓸 수도 있지만, 굳이 그럴 필요도 없음.
• CLAUDE.md에 딱 한 줄만 넣으면 문서 덤프는 끝임: "노트는 iwe로 쿼리 가능함, iwe docs query를 실행해서 문법을 익혀라". 바이너리가 자기 참조 문서를 출력하니까, 내가 매뉴얼을 프롬프트에 복붙할 필요 없이 Claude가 필요할 때마다 알아서 학습함.
• 읽기 작업이 토큰 예산에 딱 맞음. --max-tokens로 쿼리 결과값을 제한하고, 너무 큰 문서는 명시적인 마커와 함께 잘라버림. 다시 읽는 것보다 쿼리하는 게 훨씬 싸게 먹히는데, 이게 핵심임.
• 쓰기 작업은 안전장치가 있음. --expect 1 옵션을 쓰면 딱 하나의 노트만 매칭될 때만 업데이트를 수행하고, 스키마 검증이 잘못된 프론트매터를 걸러내니까 Claude가 긴 세션 동안 형식을 멋대로 망가뜨릴 일이 없음.

솔직히 말하는 한계점: 이건 시맨틱 검색이 아님. BM25 풀텍스트 검색은 내장돼 있지만, "이거랑 비슷한 느낌의 노트를 찾아줘" 같은 건 여전히 임베딩이 압승임. 그리고 메모가 CLAUDE.md 하나에 다 들어간다면, 이런 거 필요 없음. 폴더가 너무 커져서 다시 읽는 게 감당 안 될 때부터 진가를 발휘하는 거임. 속도도 문제없음(문서 2만 개 불러오는 데 0.7초 정도 걸림).

공개: 이거 내가 만든 거임. IWE는 오픈소스 마크다운 지식 그래프 CLI(Rust, MIT, 로컬 우선)고, 위에 적은 에이전트용 기능들은 Claude Code에서 쓰려고 특별히 만든 거임. 나도 매일 내 Claude Code 세팅에 이거 돌리고 있고. 완전 무료고, 유료 결제 같은 거 없음: https://github.com/iwe-org/iwe

다들 파일 하나 넘어가는 단계에서 메모 관리 어떻게 하는지 궁금함. .claude 폴더가 어떻게 커지고 있는지, Claude가 노트 뒤질 때 시맨틱 검색을 쓰는지, 아니면 나처럼 구조화된 쿼리를 쓰는지 다들 어떰?