클로드 코드 메모리 모델, 58개 기사에 꿈꾸는 레이어 적용
Source: Dev.to
나는 한 번의 세션에서 내 서비스 Kotonia(ja/en/zh)의 58개 기술 블로그 글을 하나의 의미 인덱스로 통합하고, 그 인덱스를 이용해 새 글을 채굴할 때 중복을 감지하는 파이프라인을 만들었다. 원본 글 → 의미 인덱스 → TF‑IDF 중복 제거 → 청크 단위 초안 생성 — 전 과정을 로컬 Gemma 4 26B와 Codex CLI가 구동한다. 설계와 구현에 대한 메모는 아래에 정리한다.
동기와 “솔로 개발자가 축적한 자산이 복합적으로 성장하는 방식”에 대한 이야기는 별도 글에서 다룬다: 솔로 개발자의 축적 자산이 드디어 복합적으로 성장하기 시작한 날
이 글은 기술적인 내용만을 담는다.
1. 문제 — 제목만으로 중복 검사가 깨졌을 때
v1 채굴에서는 초안을 만들고 나는 “이 내용이 기존 글과 겹친다”는 것을 눈치챘다. 겹친 대상은 voice-first-local-llm(중요도 = 9, 플래그십)였다.
- 새 초안 논제: “청크당 토큰 수가 음성 채팅 지연의 숨은 원인”
- 기존 글 §3.3: “★ 스트리밍 세분화 — 음성 경험을 좌우하는 구조적 차이”
두 글 모두 같은 수치를 제시한다(로컬 Gemma 1.0 tok/chunk, Haiku 10‑16, Gemini 8‑24). 완전한 중복이다.
채굴 에이전트는 art-done-list(제목 + 설명)를 호출해 중복 검사를 수행했지만, 기존 글의 제목은 “Cutting short‑form LLM latency from 600ms to 22ms”이며, TTFB가 헤드라인 판매 포인트다. §3.3의 스트리밍 세분화는 H2 하위 섹션에 숨겨져 있다. 제목 수준에서는 겹치는 부분이 없었기에 검사는 통과했다.
이것이 본 글의 출발점이다.
2. 설계 — 에피소드 ↔ 의미 ↔ 절차의 3계층
Claude Code의 메모리 시스템이 작동하는 이유를 정리하면:
- 엔트리 크기가 작다(1‑3KB, 하나의 토픽) → 하위 토픽이 묻히지 않는다
- 후크가 검색에 최적화·큐레이션되어 있어 검색어가 후크에 재등장한다
- 스마트 모델이 후크를 반자동으로 작성 → 과거의 나가 미래의 나를 위해 정제한다
반면 우리 글은 5‑15KB 규모이며, 중요한 하위 토픽이 섹션 본문에 파묻혀 있다. 설명은 SEO용 요약이고, 검색에 최적화되지 않았으며, 에이전트에게는 무겁다.
이를 연결해 준 것이 Dreaming 레이어다. 생물학적 은유인 “수면 중 기억이 해마에서 대뇌피질로 통합되는 과정”을 그대로 차용했다.
episodic (raw articles + memory files)
↓ Dreaming agent (주기적 소화)
semantic (concepts_covered_ja[] / importance / data_points / sections)
↓ agent reverse‑lookup (art-concepts-find / TF‑IDF cosine)
procedural (mining / drafting / publishing)의미 엔트리 예시
{
"slug": "voice-first-local-llm",
"locale": "ja",
"thesis_ja": "Ditching API, building voice‑first with self‑hosted local 26B",
"importance": {
"score": 9,
"factors": {
"pv_count_30d": 6,
"avg_scroll": 67.0,
"avg_dwell_sec": 170,
"has_bench_data": true,
"novelty_high": true
}
},
"concepts_covered_ja": [
"TTFB (time‑to‑first‑byte): local vs API",
"Streaming granularity (tokens per chunk)",
"Gemma 4 26B model selection rationale",
"Ditto + LLM co‑residency GPU design"
],
"data_points": [
{"name": "TTFB Local", "value": "17-25ms"},
{"name": "Streaming granularity Local", "value": "1.0 tok/chunk"}
],
"sections": [
{"id": "3.3", "title": "Streaming granularity — the structural difference that decides voice experience"}
]
}핵심은 concepts_covered_ja[]가 일본어 정규화된 명칭이어야 한다는 점이다. 영·중 번역 글도 동일한 JP 개념 문자열을 사용한다. 이 하나의 정규화가 하위 단계에서 중복 판단의 기본이 된다.
3. 도구 — 에이전트가 호출하는 얇은 CLI
Codex CLI가 로컬 Gemma 4 26B를 구동한다. --enable-auto-tool-choice --tool-call-parser gemma4 옵션을 통해 OpenAI와 호환되는 인터페이스를 제공한다. 각 도구는 표준 라이브러리만 사용한 50‑100줄 파이썬 스크립트이며, 이름은 art- 접두사를 갖는다.
| 도구 | 역할 |
|---|---|
art-articles-list --needs-dreaming | DB ∪ FS에 있는 글 + Dreaming 상태 |
art-pv-count --slug X | analytics_events → PV / 스크롤 / 체류시간 |
art-source-pull [--section N] | 글의 H2/H3 섹션 하나만 가져오기 |
art-dream-write | articles_index.jsonl에 의미 엔트리 upsert |
art-concepts-find | 개념 → 글 역검색 (중복 판단 기본) |
art-ideas-check | TF‑IDF 기반 후보 아이디어 평가 (본 글 핵심) |
art-ideas-add | 아이디어 풀에 추가 (내부적으로 art-ideas-check 호출) |
art-draft-append | 초안 본문 청크를 버퍼에 추가 |
art-draft-commit | 버퍼를 최종화 → articles/_drafts/.md |
Dreaming 에이전트는 위 도구들을 이용해 한 번에 하나의 글을 의미적으로 인코딩한다. 중요도 점수는 다음 기준을 적용한다.
+2: PV >= 100 (시그모이드 로그 스케일)
+1: avg_scroll >= 0.7 AND avg_dwell_sec >= 60
+2: 벤