Sliding Window와 차가운 파도 : 에이전트 컨텍스트가 폭발하고 손실 없이 아카이브해야 할 때

wc -l .agents/INDEX.adoc .agents/SESSIONS_HISTORY.adoc \
  .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc

@startuml
skinparam backgroundColor #FEFEFE
skinparam handwritten false

title 컨텍스트 에이전트 성장 — 세션 1에서 48까지
rectangle "세션 1-10" as S10 #E8F5E9
rectangle "세션 11-20" as S20 #C8E6C9
rectangle "세션 21-30" as S30 #A5D6A7
rectangle "세션 31-40" as S40 #81C784
rectangle "세션 41-48" as S48 #66BB6A

note right of S10
  INDEX : ~50 lignes
  SESSIONS : ~10 lignes
  ARCHIVE : ~100 lignes
  **Total : ~300 lignes**
end note

note right of S20
  INDEX : ~100 lignes
  SESSIONS : ~20 lignes
  ARCHIVE : ~400 lignes
  **Total : ~800 lignes**
end note

note right of S30
  INDEX : ~160 lignes
  SESSIONS : ~30 lignes
  ARCHIVE : ~900 lignes
  **Total : ~1800 lignes**
end note

note right of S40
  INDEX : ~220 lignes
  SESSIONS : ~45 lignes
  ARCHIVE : ~1400 lignes
  **Total : ~3200 lignes**
end note

note right of S48
  INDEX : **260 lignes**
  SESSIONS : **55 lignes**
  ARCHIVE : **1756 lignes**
  **Total : 5200 lignes** ⚠️
end note

S10 -[#green]-> S20
S20 -[#green]-> S30
S30 -[#FF9800]-> S40
S40 -[#red]-> S48

@enduml

----
----
.agents/
├── INDEX.adoc                         → Sessions N-9 à N (10 dernières)
├── SESSIONS_HISTORY.adoc              → Sessions N-9 à N
├── SCRIPT_VERIFICATION.adoc           → Dernière vérif (pas d'historique)
├── PROMPT_REPRISE.adoc                → Session N+1 uniquement
├── sessions/                          → Sessions N-1 à N uniquement
└── backup/
    └── Y2026-sessions-001-039/          ← Vague froide, COPIE INTÉGRALE
        ├── INDEX.adoc                  → Sessions 001 à 039 (complet)
        ├── SESSIONS_HISTORY.adoc       → Sessions 001 à 039 (complet)
        ├── COMPLETED_TASKS_ARCHIVE.adoc → Sessions 001 à 039 (complet)
        └── sessions/                   → 001.adoc, 002.adoc...
----

메커니즘의 열쇠 :**백업은 중앙 인덱스가 아니라 과거 파도의 정확히 동일한 복사본이다.**. 활성 세션 10을 초과하면 아무것도 삭제하지 않고, 아무것도 재인덱싱하지 않고, 아무것도 병합하지 않습니다. 우리는 N-10 세션 때의 에이전트 파일 패키지를 그대로 취해서 그것을 안으로 이동합니다`backup/`.

활성화된 파일들은 잘립니다:

* INDEX : 최근 10줄만 (슬라이딩 윈도우)
* SESSIONS_HISTORY : 동일
* COMPLETED_TASKS_ARCHIVE : 현재 기간에 대한 새 파일
* sessions/ : 마지막 2개의 세션만

[plantuml, format=svg, id=diag-hot-warm-cold, alt="Architecture Hot/Warm/Cold du contexte agent — EAGER/LAZY/backup"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title 컨텍스트 에이전트의 핫/웜/콜드 아키텍처
package "HOT (EAGER)
자동으로 충전됨
약 300줄" as HOT #FFCDD2 {
  file "INDEX.adoc\n(10 세션)" as IDX_HOT
  file "PROMPT_REPRISE\n(세션 N+1)" as PRO_HOT
  file "AGENT.adoc
(절대 규칙)" as AG_HOT
}

package "WARM (LAZY)
요청 시 로드
~500 줄" as WARM #FFF9C4 {
  file "SESSIONS_HISTORY
(최근 10개)" as HIS_WARM
  file "SCRIPT_VERIFICATION\n(마지막)" as VER_WARM
  file "PROCEDURES.adoc
(템플릿)" as PRO_WARM
  file "*_REFERENCE.adoc
(기술 문서)" as REF_WARM
}

package "콜드 (backup/)
절대 충전되지 않음
인간 전용 읽기" as COLD #BBDEFB {
  folder "Y2026-001-039/" as WAVE {
    file "색인 (완전)" as IDX_COLD
    file "SESSIONS_HISTORY\n(전체)" as HIS_COLD
    file "COMPLETED_TASKS\n(완료)" as ARCH_COLD
    folder "세션/ (001-039)" as SESS_COLD
  }
  folder "Y2026-040-???
(future)" as FUTURE
}

HOT --> WARM : "에이전트가 다시 올라갑니다
필요하면"
WARM --> COLD : "절대 자동이 아니다
인간만이 그곳으로 간다"

note bottom of COLD
  Règle : COPIE INTÉGRALE
  Pas de transformation
  Pas de réindexation
  Read-only après archivage
end note

@enduml
----

즉시 이익은 엄청납니다 : EAGER 컨텍스트가**~5200줄에서 ~300줄**. 17로 나누기. 역사적 데이터를 한 줄도 잃지 않고.

== 왜 이것이 만능이 아닌가

에이전트는 첫 번째 반복에서 두려워했습니다.`backup/`검은 상자가 되는 — 아무도 다시 보지 않을 파일을 버리는 폴더이다. 이는 정당한 두려움이다. 하지만 이는 오해에 기반한다.

잡동사니는 파일을 버릴 때다**구조도 없고, 관례도 없고, 그룹화 논리도 없이**. 여기서는 백업이 기간별(Y2026-001-039)으로 구성되어 있으며, 각 백업 폴더에는**같은 구조**그 파일`.agents/`활성 : INDEX, SESSIONS_HISTORY, COMPLETED_TASKS_ARCHIVE, sessions/.

이것은 만능 상자가 아닙니다. 이것은**타임스탬프가 찍힌 스냅샷**. 그렇다고 해도 이것이 간소화된 버전 관리 메커니즘이라고 말할 수 있다 — 다만 개별 파일을 버전 관리하는 것이 아니라 특정 시점 T에서의 거버넌스 전체 패키지를 버전 관리한다는 차이점이 있다.

과거 정보를 찾아야 할 때, 중앙 인덱스가 필요하지 않습니다. 두 가지 옵션이 있습니다 :

1. **grep` 목표된**:`grep -r "zsh" backup/Y2026-001-039/`— 그리고 zsh를 언급하는 모든 것을 기간 동안 찾으세요, 어떤 관점이든 (INDEX, SESSIONS_HISTORY, 세션 아카이브).
2. **수동 재통합**: 당신은 백업 폴더를 활성 컨텍스트에 일시적으로 복사하고, 해당 특정 기간을 분석하도록 에이전트에게 요청합니다.

인덱스는 암시적이다. 그것은 파일의 구조 자체에 있다 — 각각은 이미 그 자체의 관점에서 인덱스이다.

== 선반의 은유

기구를 직관적으로 만들기 위해, 저는 그것을 세 개의 선반으로 개념화했습니다 :

* **선반 1 (EAGER)**— 작업 계획. 내가 지금 필요한 것 *지금*. INDEX 최근, PROMPT_REPRISE, absolue적인 규칙. 가벼운, 즉각적인, 중요한.
* **선반 2 (LAZY)**— 상담용 도서관. 요청 시 내가 가져올 수 있는 것. 기술 참조, 최근 기록, 절차. 더 크지만 메모리에 로드되지 않음.
* **동굴 (backup/)**— 차가운 아카이브. 지난 것들이지만 버리기를 원하지 않는 모든 것. 에이전트는 그곳에 들어가지 않는다. 인간은 증류하고 싶을 때 그곳으로 내려간다.

에이전트는 처음에 네 번째 선반 — 하나`index-backup.adoc`그것은 LAZY이면서 전체 백업의 목차를 포함할 것이었습니다. 나는 거절했습니다. 그것은 이미 선형 성장에 시달리는 시스템에 또 하나의 중복이 될 것입니다. 아카이브된 파일의 구조는 이미 인덱스입니다.

== 두 트리거 센서

개념화는 탄탄했지만 여전히 사각지대가 있었다:**정확히 언제 회전을 트리거해야 하나요?**기본 문서는 이를 개방된 질문으로 식별했습니다. 2일 후, 답변은 6개 프로젝트의 거버넌스 파일에 코드화되었습니다: 두 트리거를 가진 센서.

=== 자동 트리거 — `N % 10 == 0

첫 번째 트리거는 수학적입니다. 세션 번호가 10의 배수일 때 — 세션 10, 20, 30, 40 — 백업 로테이션이 세션 종료 절차 내에서 자동으로 실행되며, 이는 단계 6 직후입니다.

왜 10일까? 두 상반된 힘 사이의 타협점이다: 너무 짧은 윈도우(5세션)는 연속성에 필요한 맥락을 잃고; 너무 긴 윈도우(20세션)는 맥락 비대 문제를 해결하지 못한다. 하루에 한두 세션 정도를 유지하면 10세션은 약 일주일分の 작업 시간을 커버한다 — 에이전트가 최근 결정을 기억하기에는 충분하지만, 맥락이 폭주하기에는 부족하다.

=== 임계치 트리거 — 500 라인 EAGER

두 번째 트리거는 동적입니다. 세션 번호에 관계없이 누적된 EAGER 파일이 초과하면**500 줄**, 회전이 시작됩니다.

이 임계값은 세션이 예외적으로 생산적인 시나리오 — 즉, 짧은 세션에 많은 콘텐츠가 작성됨 — 에 대비합니다. 120줄의 편집 콘텐츠를 생성하는 세션은 COMPLETED_TASKS_ARCHIVE를 두 줄을 수정하는 디버그 세션보다 훨씬 빠르게 증가시킵니다. 500줄의 임계값은 측정된 via`wc -l .agents/INDEX.adoc .agents/archives/COMPLETED_TASKS_ARCHIVE_*.adoc PROMPT_REPRISE.adoc`, 이 비대칭을 포착한다.

=== 수동 트리거 — "회전 백업

마침내, 인간이 주도권을 유지한다. 키워드`rotation backup`, `backup rotation` ou `lance la rotation backup`요청에 따라 세션 종료와 무관하게 절차가 시작됩니다. 컨텍스트가 무거워지는 것을 느끼지만 아직 10의 배수가 아닌 경우이거나, 새로운 작업을 시작하기 전에 현재 작업 단계를 보관하고 싶을 때 유용합니다.

[plantuml, format=svg, id=diag-capteur-trigger, alt="Les trois déclencheurs du capteur de rotation backup — automatique, seuil, manuel"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title 백업 회전 센서 — 세 가지 트리거
start

:Procédure de fin de session;
note right: Mots-clés "세션 종료"\nou "여기서 멈추자"

:Étapes 1 à 6\n(archivage standard);
note right
  1. Archive sessions/N.adoc
  2. MAJ PROMPT_REPRISE
  3. MAJ SESSIONS_HISTORY
  4. MAJ INDEX.adoc
  5. MAJ TEST_COVERAGE
  6. MAJ COMPLETED_TASKS
end note

if (N % 10 == 0\nOU\nEAGER cumulé > 500 lignes ?) then (oui)
  :⚙️ Rotation Backup\n(étape 7);
  note right
    1. Créer backup/Y20XX-sessions-X-Y/
    2. Copier intégrale INDEX + HISTORY
       + COMPLETED_TASKS + sessions/
    3. Tronquer actifs à 10 sessions
    4. Ajouter _Localisation active_
  end note
else (non)
  :Pas de rotation;
endif

:Checklist [✅] x 7\n(si applicable);

stop

@enduml
----

이 다이어그램은 세션 종료 절차에서 센서의 정확한 삽입을 보여줍니다. 7단계는 선택적입니다 — 두 조건 중 하나가 참일 때만 실행되지만 — 그러나 항상 *검증*됩니다. 최종 체크리스트에는`[✅] 7. Backup roté (si applicable)`.

=== 폐쇄된 루프

이 센서는 이전 기사에서 열린 루프를 닫습니다. Eager/Lazy 거버넌스는 두 세션 간의 에이전트 메모리 문제를 해결했습니다. Hot/Warm/Cold 메커니즘은 증가하는 메모리 문제를 해결했습니다. 두 트리거가 있는 센서는 *quand* 문제를 해결하여 — 인간이 컨텍스트 크기를 모니터링하는 정신적 부담을 덜어줍니다.

[plantuml, format=svg, id=diag-boucle-fermee, alt="Les trois couches de la gouvernance agent — Eager/Lazy, Hot/Warm/Cold, Capteur"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title 에이전트 거버넌스의 세 계층
left to right direction

package "층 1 — 메모리
(조항 0108)" as C1 #E8F5E9 {
  rectangle "**EAGER**
대시보드
자동 충전" as EAG
  rectangle "**LAZY**\n소유자 매뉴얼\n요청 시 로드" as LAZ
  EAG -[hidden]right-> LAZ
}

package "층 2 — 노화
(제0110조)" as C2 #FFF9C4 {
  rectangle "HOT
10개의 활성 세션
~300줄" as HOT
  rectangle "**WARM**
참조
절차" as WRM
  rectangle "**COLD**
backup/
차가운 파도" as CLD
  HOT -[hidden]right-> WRM
  WRM -[hidden]right-> CLD
}

package "3층 — 트리거
(오늘)" as C3 #BBDEFB {
  rectangle "**자동**
N % 10 == 0" as AUTO
  rectangle "**임계값**
> 500 라인" as SEUIL
  rectangle "**Manuel**
회전 백업" as MAN
  AUTO -[hidden]right-> SEUIL
  SEUIL -[hidden]right-> MAN
}

C1 --> C2 : "메모리 크기가 증가한다\n→ 메커니즘이 필요합니다\n노화"
C2 --> C3 : "노화
→ 트리거가 필요합니다
실행하기 위해"

note bottom of C3
  ✅ Déployé sur 6 projets
  magic-stick · bakery-gradle
  plantuml-gradle · cheroliv.com
  jhipster-gradle-plugins
  quizz-benchmark-gradle
end note

@enduml
----

세 층이 논리적으로 쌓입니다. 첫 번째 층은 에이전트에게 기억을 제공합니다. 두 번째 층은 이 기억이 에이전트를 압도하는 것을 방지합니다. 세 번째 층은 이 기억의 유지 관리를 자동화하여 인간이 그에 대해 생각하지 않아도 되도록 합니다.

=== cheroliv.com에서의 효과적인 마이그레이션

메커니즘은 이론적으로 남아 있지 않았습니다. 위에서`cheroliv.com`, 첫 번째 백업 로테이션은 2026년 4월 29일에 실행되었습니다 — 세션 -6부터 2까지가 이동했습니다.`.agents/backup/Y2026-sessions-neg6-a-002/` :

|===
|파일 |회전 전 |회전 후 |이득 |`.agents/INDEX.adoc` |19개 세션 나열 |10회 (3-12) |-9 항목 |`.agents/SESSIONS_HISTORY.adoc` |18 세션 |10 세션 |-8개 항목 |`COMPLETED_TASKS_ARCHIVE` |161줄 (세션 1-12) |135 라인 (세션 3-12) |-26 줄 |`sessions/` |20개의 파일 |10 파일 |-10 파일 |**백업/** |존재하지 않는 |1차 한파 (보관된 10개 세션) |+1 냉동 팩
|===

라인 수의 증가량은 작았습니다 — 프로젝트는 아직 어리고, 12세션이었습니다 — 중요한 것은 그것이**메커니즘이 마련되어 있습니다.**. 다음 자동 회전은 세션 20에서 트리거되거나, 500개의 EAGER 라인에 도달하면 더 일찍 트리거됩니다.

== 인간-에이전트 수업

이 세션 048은 IA 에이전트와의 협업에서 근본적인 것을 배웠습니다.

에이전트는 자연스러운 편향이 있다: 그것은 시도한다**최적화하다**, à **간소화하다**, à **중복을 제거하다**. 이것은 깨끗하고 간결한 응답을 생성하도록 훈련된 시스템의 편향이다. 데이터셋이 풍부하고 다차원적이면, 그의 첫 번째 반응은 그것을 가장 간단한 형태로 줄이는 것이다.

인간은 그와 달리 다른 직관을 가지고 있다: 그는 구조적 중복이 무언가임을 직감한다**장점**, 그것이 결함이 아닙니다. 같은 현실에서의 다양한 관점이 바로 나중에 품질 높은 증류를 가능하게 할 것입니다.

에이전트가 틀린 것이 아니다.
그의 "optimum"은 내 것이 아니다.
에이전트는 를 위해 최적화한다**현재**— 즉각적인 맥락, 제기된 질문에 대한 빠른 답변. 인간은 이를 위해 최적화한다**미래**— 3개월 혹은 3년 이내에 찾아내고, 교차시키고, 증류하는 능력

____ 내가 원하는 것은 원본 자료야. 너의 생각, 주저함, 그리고 나의 질문에 대한 답변. 네 요약은 아니야. 요약은 내가 너보다 더 잘 만들 수 있어. 내가 원하는 것은 원본 자료야. ____

세션 끝에 내가 그에게 한 이 말이 모든 것을 요약한다. 에이전트는 생산 도구다. 인간은 증류 도구다. 거버넌스는 에이전트가 모든 것을 스스로 이해하도록 하기 위한 것이 아니라 — 인간이 나중에 생산된 물질을 다룰 수 있도록 하기 위한 것이다.

같은 차가운 파도는 이 철학의 건축적 번역이다: 아무것도 버리지 않고, 아무것도 합치지 않고, 아무것도 재인덱스하지 않는다. 패키지를 그대로 이동한다. 증류는 나중에 수작업으로 인간이 수행한다.

== 이전 글의 논리적 연속

읽으셨다면link:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Eager/Lazy 전략에 관한 기사], 당신은 자연스러운 진행을 인식하게 될 것입니다 :

1. **제108조**— Eager/Lazy 거버넌스 : *comment* 에이전트 컨텍스트를 두 가지 가용성 수준으로 구성하는 방법
2. **이 글 0110**— 백업 메커니즘 : *어떻게* 이 컨텍스트를 잃지 않고 오래 보존할 수 있을까, 너무 커질 때

첫 번째 기사는 다음과 같은 질문에 답했습니다: « 에이전트는 두 세션 사이에서 아무것도 기억하지 못합니다. 어떻게 그에게 기억을 줄 수 있을까요?

이것은 첫 번째에서 불가피하게 이어지는 질문에 답한다: « 메모리는 각 세션마다 증가하는데, 이를 지우지 않고 에이전트를 질식시키는 것을 어떻게 막을 수 있을까?

답은 하나의 패턴으로 요약됩니다:**더운/따뜻한/추운**, 거버넌스 파일에 적용된. 그리고 하나의 원칙 :**절대 아무것도 잃지 말고, 항상 모든 것을 재배치하라**.

== 링크

* 이전 글 :link:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[AsciiDoc를 사용해 AI 에이전트 관리하기]
* 내 사이트 : https://cheroliv.com
* 프로젝트`magic-stick`: https://github.com/cheroliv/magic-stick

---

*좋은 거버넌스 시스템은 결코 데이터를 삭제하지 않습니다. 그것을 보관합니다.*
----