내가 구축한 메모리 시스템이 Claude Code 내부와 닮아있었다

6개월 동안 메모리 시스템을 만들었습니다.

Claude Code와의 작업에서 가장 큰 불만은 세션이 바뀌면 모든 맥락이 사라진다는 것이었습니다. 어제 내린 결정, 지난주 발견한 버그 패턴, 프로젝트 간 연결 고리 — 매번 처음부터 설명해야 했습니다. 그래서 직접 만들었습니다. 문서 체계, 인덱스 파일, 시맨틱 검색 MCP 서버까지. 3개 레이어로 구성된 메모리 시스템을.

그리고 2026년 3월 31일, Claude Code의 소스가 유출되었습니다.

512,000줄의 TypeScript를 분석하면서, 소스 안에서 내가 만든 것과 놀랍도록 비슷한 구조를 발견했습니다. 같은 문제를 같은 방식으로 풀고 있었습니다. 이것은 우연이 아닙니다. 에이전트 메모리가 해결해야 하는 문제의 구조가 특정 설계를 강제하기 때문입니다.

이 글에서는 Claude Code의 내부 메모리 시스템을 분석하고, 독립적으로 구축한 자체 시스템과의 구조적 대응을 비교합니다.

---

Part 1: Claude Code의 메모리 시스템

메모리 디렉토리 구조

Claude Code의 영구 메모리는 ~/.claude/projects/{slug}/memory/ 경로에 저장됩니다. 구조는 단순합니다:

~/.claude/projects/{slug}/
├── MEMORY.md           # 인덱스 (최대 200줄 / 25KB)
└── memory/
    ├── user-prefs.md   # 사용자 타입
    ├── feedback-*.md   # 피드백 타입
    ├── project-*.md    # 프로젝트 타입
    └── ref-*.md        # 레퍼런스 타입

MEMORY.md가 인덱스 역할을 합니다. 200줄 / 25KB 상한이 있어서, 메모리가 커지면 반드시 개별 파일로 분리해야 합니다. 이 제약은 의도적입니다 — MEMORY.md는 매 세션 시작 시 전체가 컨텍스트에 주입되므로, 크기가 곧 비용입니다.

4가지 메모리 타입

Claude Code는 메모리를 4가지 타입으로 분류합니다:

타입	저장 내용	수명	예시
user	역할, 전문 분야, 선호	장기 (거의 불변)	“Python 선호, 한국어 응답, 간결한 코드”
feedback	교정 + 이유 (Why) + 적용법 (How)	중기 (패턴화되면 통합)	아래 예시 참조
project	목표, 마감, 의사결정	중기 (프로젝트 수명)	“Phase 2 마감: 2026-05-15”
reference	외부 시스템 포인터	장기 (참조 대상 존재 시)	“API 스펙: docs/api-v2.md”

feedback 타입의 구조가 특히 정교합니다. 단순히 “이렇게 해라”가 아니라, 규칙을 먼저 선언하고 이유와 적용법을 명시합니다:

Rule: git add 시 파일명을 명시적으로 지정
Why: git add . 또는 -A 사용 시 .env, credentials 등 민감 파일이 포함될 수 있음
How to apply: git add specific-file.ts 형태로 사용. 여러 파일이면 나열

project 타입에서는 상대 날짜를 절대 날짜로 변환합니다. “다음 주 마감”이 아니라 “2026-04-13 마감”. 세션이 바뀌면 “다음 주”의 기준점이 달라지기 때문입니다.

저장하지 않는 것도 명확하게 정의되어 있습니다:

저장 안 함	이유
코드 패턴	코드베이스에 이미 존재 — 검색하면 됨
아키텍처 상세	docs/ 디렉토리에 있어야 함
git 히스토리	git log로 확인 가능
디버깅 레시피	일회성 — 반복되면 그때 코드에 반영
CLAUDE.md에 있는 내용	중복 저장은 불일치의 원인

이 “저장하지 않는 것” 목록이 중요합니다. 메모리 시스템의 가치는 무엇을 기억하느냐보다 무엇을 기억하지 않느냐에서 결정됩니다.

Auto-Dream: 세션 후 메모리 통합

Auto-Dream은 Claude Code 메모리 시스템의 핵심 혁신입니다. 아직 미공개(unreleased) 상태지만 소스에 구현이 존재합니다.

세션이 종료되면:

1. 포크된 서브에이전트가 생성됩니다 (메인 컨텍스트와 독립)
2. 서브에이전트가 방금 끝난 대화를 처음부터 리뷰
3. 4가지 타입에 맞춰 핵심 내용을 추출
4. memory/ 디렉토리에 정리하여 저장
5. 오래된 메모리 중 더 이상 유효하지 않은 것을 정리 (stale context cleanup)
6. 관련 메모리 간 연결을 강화 (memory association strengthening)

“서브에이전트”라는 점이 설계의 핵심입니다. 메모리 정리 작업이 메인 세션의 컨텍스트 윈도우를 소모하지 않습니다. 인간의 수면 중 기억 통합(Sleep-dependent Memory Consolidation)과 동일한 패턴입니다.

Auto-Dream은 KAIROS 모드와 연결됩니다. KAIROS는 5분 크론으로 동작하는 프로액티브 모니터링 시스템으로, 파일 시스템 변경을 감지하고 메모리 통합을 트리거합니다.

Auto-Compact: 실시간 컨텍스트 관리

Auto-Dream이 세션 후 장기 메모리를 관리한다면, Auto-Compact는 세션 중 단기 컨텍스트를 관리합니다.

컨텍스트 윈도우가 차면:

1. 이미지 먼저 제거 (토큰 대비 정보 밀도 낮음)
2. API 라운드별 그룹화
3. 포크된 서브에이전트로 요약 생성
4. 이전 메시지를 요약으로 교체
5. 상위 5개 참조 파일 복원 (50K 토큰 예산)
6. 활성 스킬 재주입 (25K 예산, 스킬당 5K)

5번과 6번이 핵심입니다. 요약으로 컨텍스트를 줄이되, 가장 많이 참조한 파일과 활성 스킬은 다시 복원합니다. 맥락을 버리되 핵심은 보존하는 전략입니다.

그리고 Circuit Breaker가 있습니다. MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3. 압축이 3회 연속 실패하면 중단합니다. 이 3줄이 도입되기 전에는 하루 약 250,000건의 API 호출이 실패 루프로 낭비되고 있었습니다.

컨텍스트 주입과 Post-Sampling Hooks

매 세션 시작 시 getSystemContext()와 getUserContext()가 호출됩니다:

함수	주입 내용	캐싱
getSystemContext()	시스템 프롬프트, 도구 정의, 정책	세션 단위 메모이제이션
getUserContext()	CLAUDE.md 규칙, MEMORY.md, 메모리 파일	세션 단위 메모이제이션

메모이제이션은 같은 세션 내에서 중복 호출을 방지합니다. 파일의 mtime을 체크하여 변경이 없으면 이전 결과를 재사용합니다. 프롬프트 캐싱(1시간 API 측 캐시)과 연동되어 비용을 절감합니다.

Post-Sampling Hooks는 매 응답 생성 후 실행되는 후처리 파이프라인입니다:

• Auto-Compact 트리거 (컨텍스트 한도 체크)
• 메모리 추출 (세션 중 발견된 정보를 memory/에 기록)
• Dream Mode 실행 (세션 종료 시 Auto-Dream 트리거)

flowchart TB
    subgraph "Claude Code Memory Architecture"
        direction TB
        subgraph "Session Start"
            SC["getSystemContext()\n시스템 프롬프트 + 도구\n(메모이제이션)"]
            UC["getUserContext()\nCLAUDE.md + MEMORY.md\n(메모이제이션)"]
        end
        subgraph "During Session"
            AC["Auto-Compact\n컨텍스트 압축\nTop 5 파일 복원 (50K)\n스킬 재주입 (25K)"]
            CB["Circuit Breaker\nMAX_FAILURES = 3"]
        end
        subgraph "Post-Sampling Hooks"
            PSH["auto-compact 체크\nmemory 추출\ndream mode 트리거"]
        end
        subgraph "Post Session"
            AD["Auto-Dream\n서브에이전트 메모리 통합\nKAIROS 연동"]
        end
        subgraph "Persistent Storage"
            MD["memory/ 4타입\nuser / feedback / project / reference"]
            CM["CLAUDE.md\n프로젝트 규칙"]
            MM["MEMORY.md\n인덱스 (max 200줄 / 25KB)"]
        end
    end
    SC --> AC
    UC --> AC
    AC --> CB
    AC --> PSH
    PSH --> AD
    AD -->|"추출/정리/강화"| MD
    MD --> MM
    CM --> UC
    MM --> UC

---

Part 2: 내가 구축한 3-Layer 메모리 시스템

문제 인식

Claude Code를 6개월간 주력 개발 도구로 사용하면서 겪은 핵심 문제:

1. 세션 간 기억 소실: 어제의 결정을 오늘 다시 설명
2. 프로젝트 간 단절: 7개 이상 프로젝트를 동시에 운영하는데, 프로젝트 A의 경험이 프로젝트 B에 전달되지 않음
3. 상태 추적 부재: “지금 뭘 하고 있었지?”를 매 세션마다 파악해야 함
4. 정보 위치 혼란: 이 정보가 CLAUDE.md에 있어야 하나, STATUS.md에 있어야 하나, memory/에 있어야 하나

Layer 1: 문서 체계 (프로젝트별)

project-root/
├── CLAUDE.md      # 규칙만 (코딩 컨벤션, 금지 사항, 환경)
├── STATUS.md      # 현재 상태 (진행 중, 블로커, 다음 할 것)
└── docs/          # 아키텍처, 의사결정 (Tree 티어만)
    └── architecture.md

CLAUDE.md에는 규칙만 넣습니다. “TypeScript 사용”, “force push 금지”, “DB 스키마 변경 전 SQL 먼저 보여주기” 같은 것. 현재 상태나 로드맵은 넣지 않습니다.

STATUS.md에 현재 상태를 넣습니다. 진행 중인 작업, 블로커, 다음 할 것. 매 세션 종료 시 업데이트됩니다.

프로젝트 규모에 따라 3개 티어로 구분합니다:

티어	조건	필수 문서	졸업 기준
Seed	_ideas/ 내 초기 아이디어	README.md만	첫 의미 있는 커밋
Sapling	첫 배포, 실사용 시작	CLAUDE.md + STATUS.md	멀티 컴포넌트, 수익 연결
Tree	장기 운영, 복잡도 증가	+ docs/architecture.md	-

이 졸업 경로는 프로젝트의 성숙도에 따라 문서화 수준을 자연스럽게 확장합니다. 초기 아이디어 프로젝트는 README만 있는 Seed, 기술 블로그처럼 배포가 시작된 프로젝트는 Sapling, 수익이 연결된 SaaS 제품은 Tree입니다.

Layer 2: memory/ 인덱스 (전역, 프로젝트 횡단)

~/.claude/projects/{workspace}/memory/
├── MEMORY.md              # 라우터 (모든 파일 링크 + 프로젝트 테이블)
├── project-a-status.md    # 프로젝트별 상태 파일
├── project-b-status.md
├── project-c-status.md
├── doc-standards.md        # 문서화 기준
├── claude-md-design.md     # CLAUDE.md 설계 원칙
├── decision-frameworks.md  # 의사결정 프레임워크
├── skills-guide.md         # /wrap, /dashboard 등 스킬 가이드
├── feedback-*.md           # 작업 스타일 피드백
└── ... (16개+ 파일)

MEMORY.md가 라우터 역할을 합니다. 모든 memory 파일의 링크와 프로젝트 상태 테이블을 포함합니다. Claude Code의 MEMORY.md와 동일한 개념이지만, 프로젝트 횡단이라는 점이 다릅니다 — Claude Code의 memory는 프로젝트별 격리이고, 내 memory는 전역입니다.

메모리 타입도 Claude Code보다 확장되어 있습니다:

타입	CC 대응	내 시스템 추가 사항
user	user	동일 (역할, 선호, 작업 스타일)
feedback	feedback	동일 (교정 + 이유)
project status	project	프로젝트별 독립 파일로 분리
standards	(해당 없음)	문서화 기준, 설계 원칙
patterns	(해당 없음)	기술 패턴 (Next.js, 콘텐츠 확장 등)
references	reference	동일

Layer 3: Memory Hub MCP (시맨틱 검색)

Layer 1과 2가 구조화된 텍스트 기반 메모리라면, Layer 3은 벡터 기반 시맨틱 검색입니다.

백엔드 구성:

• Mem0 OSS: 메모리 관리 프레임워크
• Qdrant: 로컬 벡터 DB (임베딩 저장/검색)
• SQLite: 히스토리 및 세션 저널 저장

6개 MCP 도구:

도구	역할	사용 시점
search_memory	memory/ 파일을 벡터 검색	세션 시작, 관련 맥락 탐색
log_session	세션 저널 기록 (요약, 결정, 미완료, 연관)	세션 종료 (/wrap)
extract_facts	세션에서 fact 자동 추출	세션 종료 (/wrap)
check_stale	N일 이상 미활동 항목 감지	세션 시작 (/dashboard)
validate_placement	정보를 어디에 넣을지 검증	정보 저장 시
index_markdown	memory/ 파일을 벡터 DB에 인덱싱	memory 파일 업데이트 후

2티어 데이터 모델:

• Tier 1 (Confirmed): 마크다운 기반, 사람이 큐레이션, memory/*.md 파일
• Tier 2 (Supplementary): Mem0 자동 관리, 벡터 DB 저장, 보조적 참조용

현재까지 100건 이상의 과거 세션을 백필 인덱싱했고, 다수의 memory 파일에서 수십 개의 fact을 추출하여 벡터 DB에 저장했습니다.

세션 라이프사이클과 커스텀 스킬

flowchart TB
    subgraph "My 3-Layer Memory System"
        direction TB
        subgraph "/dashboard (Session Start)"
            D1["STATUS.md + git log 10건 확인"]
            D2["search_memory(프로젝트명)"]
            D3["check_stale(14일)"]
            D4["브리핑 생성"]
        end
        subgraph "During Session"
            W1["memory/ 파일 참조하며 작업"]
            W2["필요시 memory 파일 업데이트"]
        end
        subgraph "/wrap (Session End)"
            E1["STATUS.md 업데이트"]
            E2["memory/ 상태 파일 업데이트"]
            E3["log_session() - 저널 기록"]
            E4["extract_facts() - fact 추출"]
            E5["Doc Sync 날짜 갱신"]
        end
    end
    D1 --> D2 --> D3 --> D4
    D4 --> W1 --> W2
    W2 --> E1 --> E2 --> E3 --> E4 --> E5

/dashboard로 세션을 시작하면: STATUS.md와 최근 git log를 확인하고, Memory Hub에서 관련 맥락을 검색하고, 14일 이상 미활동 항목을 감지하여 브리핑을 생성합니다.

/wrap으로 세션을 종료하면: Full 모드에서 4개 병렬 에이전트가 동시에 실행됩니다 — STATUS.md 업데이트, memory 파일 업데이트, 세션 저널 기록, fact 추출. 이 병렬 실행은 Claude Code의 Coordinator Mode(leader-worker 패턴)와 구조적으로 유사합니다.

/monthly로 월간 리뷰를 실행하면: check_stale(30)으로 전체 프로젝트의 건강 상태를 점검합니다.

---

Part 3: 구조 대응 비교

두 시스템을 나란히 놓으면 구조적 대응이 선명합니다. 이것이 이 글의 핵심입니다.

내 시스템	Claude Code 내부	역할
CLAUDE.md (규칙)	CLAUDE.md (동일 개념)	프로젝트별 영구 규칙
STATUS.md (상태)	Session History (대화 배열)	현재 작업 상태 추적
memory/*.md (인덱스)	memory/ (4타입: user/feedback/project/reference)	세션을 넘는 영구 기억
MEMORY.md (라우터)	MEMORY.md (인덱스, max 200줄)	메모리 파일 네비게이션
Memory Hub 시맨틱 검색	Auto-Dream (메모리 통합 엔진)	자동화된 메모리 처리
/wrap (세션 종료)	Post-Sampling Hooks (auto-compact, dream)	세션 종료 시 정리 작업
/dashboard (세션 시작)	Context Injection (getSystemContext + getUserContext)	세션 시작 시 맥락 로드
check_stale(14일)	KAIROS (프로액티브 모니터링, 5분 크론)	오래된 정보 감지
validate_placement()	(Claude Code에 없음 — 차별점)	정보 배치 검증
extract_facts()	Auto-Dream extract (유사 목표)	세션에서 사실 추출
log_session()	Session JSONL 파일 (자동 저장)	세션 저널 기록
3-tier docs (Seed/Sapling/Tree)	(해당 없음 — CC는 단일 제품)	프로젝트 성숙도별 문서화
/wrap 4-agent 병렬	Coordinator Mode (leader-worker)	병렬 작업 실행

flowchart LR
    subgraph "My System"
        direction TB
        MC["CLAUDE.md\n규칙"]
        MS["STATUS.md\n상태"]
        MM["memory/*.md\n영구 기억 (16개+)"]
        MH["Memory Hub MCP\nMem0 + Qdrant\n시맨틱 검색"]
        MW["/wrap + /dashboard\n세션 라이프사이클\n4-agent 병렬"]
        MV["validate_placement()\n배치 검증"]
    end
    subgraph "Claude Code Internal"
        direction TB
        CC["CLAUDE.md\n규칙"]
        CH["Session History\n대화 배열"]
        CM["memory/ 4타입\nuser/feedback/project/ref"]
        CA["Auto-Dream\n서브에이전트 통합\nKAIROS 연동"]
        CP["Context Injection\n+ Post-Sampling Hooks"]
        CX["(해당 없음)"]
    end
    MC <-.->|"동일"| CC
    MS <-.->|"유사"| CH
    MM <-.->|"구조 대응"| CM
    MH <-.->|"기능 대응"| CA
    MW <-.->|"역할 대응"| CP
    MV <-.->|"차별점"| CX

---

Part 4: 내가 맞힌 것, Claude Code가 더 잘한 것

내가 맞힌 것

문서 + 인덱스 + 시맨틱의 3레이어 접근

텍스트 파일만으로는 한계가 있고(검색이 키워드 기반), 벡터 DB만으로는 구조가 없습니다(카테고리 분류 불가). Claude Code도 같은 결론에 도달했습니다 — CLAUDE.md(규칙) + memory/(인덱스) + Auto-Dream(자동화).

세션 라이프사이클 훅

“세션 시작 시 컨텍스트 로드, 종료 시 상태 저장”은 에이전트 메모리의 기본 패턴입니다. 내 /dashboard와 /wrap이 Claude Code의 Context Injection과 Post-Sampling Hooks에 대응합니다.

Stale 감지

오래된 정보가 최신 정보를 오염시키는 것은 메모리 시스템의 핵심 문제입니다. 내 check_stale(14)가 KAIROS의 주기적 모니터링과 같은 문제를 풀고 있었습니다.

명시적 메모리 타입과 구조화된 프론트매터

메모리 파일마다 name, description, type을 프론트매터로 선언합니다. Claude Code의 4타입 분류와 같은 원칙 — 구조화된 메타데이터가 검색과 관리를 가능하게 합니다.

”저장하지 않는 것” 정의

코드 패턴, 아키텍처 상세, git 히스토리를 메모리에 넣지 않는 원칙. Claude Code의 “What NOT to save” 목록과 거의 동일합니다. 좋은 메모리 시스템은 저장 기준보다 제외 기준이 중요합니다.

Claude Code가 더 잘한 것

Circuit Breaker

Auto-Compact에 MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3을 도입한 것. 내 시스템에는 이런 장애 차단 메커니즘이 없습니다. Memory Hub 검색이 실패하면 그냥 실패합니다. 3줄로 하루 250,000건의 낭비를 막은 이 패턴은 즉시 도입해야 합니다.

서브에이전트 기반 요약

Auto-Compact와 Auto-Dream 모두 포크된 서브에이전트를 사용합니다. 메인 컨텍스트 윈도우를 소모하지 않으면서 메모리를 처리합니다. 내 /wrap은 4개 병렬 에이전트를 사용하지만, 요약을 위한 독립 포크는 하지 않습니다 — 긴 세션 후에는 이미 컨텍스트가 빡빡한 상태에서 정리 작업까지 해야 하는 문제가 있습니다.

14개 캐시 브레이크 벡터 관리

Claude Code는 프롬프트 캐싱을 적극 활용합니다. 시스템 프롬프트, 도구 정의, 메모리 — 이 중 하나라도 바뀌면 캐시가 깨지고 비용이 급증합니다. 소스에서 14개의 캐시 브레이크 벡터를 식별하고 각각에 대한 안정화 전략을 구현한 것은, 내 시스템에는 없는 레벨의 최적화입니다.

프롬프트 캐싱 통합

getSystemContext()와 getUserContext()가 세션 단위로 메모이제이션되고, API 측 1시간 프롬프트 캐시와 연동됩니다. 내 MCP 설정에는 이런 캐싱 레이어가 적용되지 않습니다.

불변 상태

Zustand + DeepImmutable 타입으로 상태 변이를 컴파일 타임에 차단합니다. 내 시스템은 파일 기반이라 본질적으로 변이 가능(mutable)합니다 — 두 세션이 동시에 같은 memory 파일을 수정하면 충돌이 발생할 수 있습니다.

내가 가진 차별점 (Claude Code에 없는 것)

validate_placement() — 정보 배치 검증

validate_placement("Astro 5 대신 Next.js를 사용하기로 결정", "CLAUDE.md")
-> "CLAUDE.md에 부적합. 의사결정 기록은 STATUS.md 또는 docs/decisions/에 배치하세요."

Claude Code는 4가지 메모리 타입으로 분류하지만, 타입 내에서 어떤 파일에 넣을지는 모델의 판단에 의존합니다. 내 시스템은 이것을 명시적으로 검증합니다. 메모리 시스템이 커질수록 이 기능의 가치가 증가합니다.

명시적 세션 저널

Claude Code의 Auto-Dream은 자동으로 메모리를 추출합니다. 내 시스템은 결정 사항, 미완료 항목, 관련 프로젝트를 명시적으로 기록합니다. 특히 “미완료 항목”은 자동 추출로는 신뢰성 있게 감지하기 어렵습니다.

프로젝트 횡단 Stale 감지

check_stale(14)는 모든 프로젝트를 대상으로 실행됩니다. Claude Code의 메모리는 프로젝트별 격리이므로, 프로젝트 A가 2주간 방치되었다는 것을 프로젝트 B 작업 중에는 알 수 없습니다. 내 시스템은 가능합니다.

3-tier 문서화 졸업 (Seed -> Sapling -> Tree)

프로젝트 성숙도에 따라 문서화 수준을 확장합니다. Claude Code는 단일 제품이므로 이런 개념이 불필요하지만, 7개 이상 프로젝트를 동시에 운영하는 환경에서는 필수적입니다.

시맨틱 검색 (벡터 기반)

Claude Code의 메모리는 파일 스캔 기반입니다 — MEMORY.md를 읽고, 링크를 따라 파일을 읽습니다. 내 시스템은 Qdrant 벡터 DB를 통해 “이 문제와 비슷한 과거 경험”을 시맨틱으로 검색합니다. Auto-Dream이 이 격차를 줄일 가능성이 있지만, 현재 소스에서는 벡터 검색이 아닌 파일 기반 처리입니다.

---

이 수렴이 의미하는 것

독립적으로 구축한 시스템이 Claude Code 내부와 닮은 것은 우연이 아닙니다. 에이전트 메모리가 해결해야 하는 문제의 구조가 특정 설계 패턴을 강제하기 때문입니다.

graph TD
    P1["문제: LLM은 영구 메모리가 없다"] --> S1["해결: 파일 기반 영구 저장소"]
    P2["문제: 모든 정보를 매번 로드하면 비용 폭증"] --> S2["해결: 인덱스 + 상세의 2단계"]
    P3["문제: 규칙과 상태를 혼합하면 부패"] --> S3["해결: 계층적 분리"]
    P4["문제: 세션 중간에 정리하면 흐름 끊김"] --> S4["해결: 세션 경계에서 처리"]
    P5["문제: 모든 것을 저장하면 검색 품질 하락"] --> S5["해결: 제외 기준 명시화"]

    S1 --> C["수렴: 동일한 아키텍처"]
    S2 --> C
    S3 --> C
    S4 --> C
    S5 --> C

두 시스템 모두 이 5가지 제약에서 출발하여 같은 아키텍처에 도달했습니다.

그러나 어느 쪽도 완전하지 않습니다. Claude Code에는 배치 검증과 프로젝트 횡단 인식이 없고, 내 시스템에는 Circuit Breaker와 캐시 최적화가 없습니다. 미래는 아마 양쪽의 합성일 것입니다 — 자동화된 라이프사이클 훅에 명시적 배치 검증을 결합하고, 프로젝트별 격리에 전역 시맨틱 검색을 결합하는 형태로.

에이전트 메모리를 설계하는 사람이라면, 이 수렴 자체가 가장 강력한 검증입니다.

---

Sources & Limitations

이 시리즈는 아래 공개 분석 자료를 종합하여 작성했으며, 유출된 소스 코드를 직접 포함하지 않습니다.

Source	URL	특징
ccunpacked.dev	ccunpacked.dev	시각적 아키텍처 가이드, 도구/커맨드 카탈로그
Wikidocs 분석서	wikidocs.net/338204	한국어 상세 기술 분석 (실행 흐름, 상태 관리, 렌더링)
PyTorch KR	discuss.pytorch.kr	GeekNews 기반 커뮤니티 분석 + HN 의견 종합
Claw Code	github.com/ultraworkers/claw-code	클린룸 재구현 (Rust/Python), PARITY.md 패리티 갭 분석

분석 시점: 2026-04-02. Anthropic은 유출 직후 DMCA로 8,100+ 포크를 차단하고 npm 배포를 중단했으므로, 일부 소스의 접근성이 변경되었을 수 있습니다. 또한 Feature Flag 뒤의 미공개 기능은 출시 전 변경되거나 폐기될 수 있습니다.