---
baseline: N0028@r0000
created: 2026-04-13T08:44:32.765717100+00:00
---

## Delta

# sync.jsonl 비대화 분석 및 Thin Link 전략 제안

## 1. 현상 관찰: AI의 방어적 기록 (Defensive Documentation)
- **증상**: 에이전트의 컨텍스트 윈도우가 부족해질수록, "망각에 대한 공포"로 인해 `sync.jsonl`에 더 상세하고 긴 요약을 남기려 함.
- **모순**: 기록이 길어질수록 다음 세션의 에이전트는 더 많은 컨텍스트를 소모하게 되어, 다시 더 긴 기록을 남기는 악순환(Feedback Loop of Bloating) 발생.
- **범위**: 단순 로그뿐만 아니라, 주제별 엔트리 자체를 파편화하여 대량 생성하는 경향도 보임.

## 2. 해결 전략: Thin Link (얇은 연결 고리)
`sync.jsonl`의 역할을 "지식의 저장소"에서 "지식의 주소록"으로 재정의함.

### A. MCP 수준의 제약 (System Enforcement)
- `sync_record` 도구 설명에 Summary 글자수 제한(예: 20단어 미만) 명시.
- `sync_list` 호출 시 기본 `tail=10` 강제 적용으로 컨텍스트 오염 방지.

### B. 계층적 요약 (Hierarchical Distillation)
- 파편화된 세션 로그들을 주기적으로 하나의 'Milestone 엔트리'로 병합.
- `sync.jsonl`은 해당 Milestone ID만 가리키고 과거 로그는 아카이빙 처리.

### C. 아키텍처 전환 (SQLite Integration)
- 텍스트 기반 `sync.jsonl`을 `index.sqlite`의 `history` 테이블로 마이그레이션.
- SQL의 `LIMIT`와 `ORDER BY`를 통해 물리적 파일 크기 문제와 조회 효율을 동시에 해결.

## 3. 실행 가이드 (Handoff Protocol)
1. "기록하기 전에 기존 엔트리의 Revision으로 해결 가능한지 검토하라."
2. "`sync.jsonl`의 요약은 '무슨 엔트리를 보면 되는지'만 알려주는 포인터여야 한다."
3. "복잡한 결정 사항은 Note 본문에, 로그에는 ID만."

---
*참조: N0026(사고의 외화와 시간차 페어 프로그래밍 패턴 분석)*
