Sprint 152 — 블로그 [기술 챌린지] — 슬라이딩 윈도우로 agent 컨텍스트 최적화 글 작성

영향도높음
  • 상태: 완료 ✅
  • 기간: 2026-05-13 (단일 일자)
  • 트리거: 사용자 요청 (블로그 글 작성)
  • start_commit: 4313561 (Sprint 151 hotfix end)
  • end_commit: 3873f6d (Sprint 152 영문판 end)
  • 머지된 PR: 3건 (squash merge)

1. 배경 / 사용자 요청

AlgoSu의 agent 협업 워크플로우에서 누적된 운영 경험 — 특히 유지보수 관점의 문서화 필요성 + 슬라이딩 윈도우 시스템 도입을 통한 컨텍스트 최적화를 [기술 챌린지] 카테고리 블로그 글로 정리. Sprint 145~151 누적된 회귀 0건 운영 사례를 실증으로 활용.

2. 결정 사항

2.1 글 컨셉

  • 카테고리: challenge (기존 3편: toward-model-agnostic-harness / baekjoon-gone / session-policy-sync 와 동일 카테고리, order: 10 — 직전 max=9)
  • 3단 핵심 논리 (사용자 직접 제시):
    1. 기억의 휘발성 → 문서화 필수 (특히 agent 협업)
    2. 모든 문서 매 세션 참조 = "꽉 찬 물통에 물을 계속 부어 넣는 행위" (역설)
    3. 슬라이딩 윈도우 알고리즘에 착안 → 도입 (해결)
  • 제목: "기억은 휘발되고 문서는 무한히 쌓인다 — 슬라이딩 윈도우로 agent 컨텍스트를 최적화하다"

2.2 i18n 정책

  • 기존 9편 모두 KR (blog/content/posts/) + EN (blog/content/posts-en/) 양면 보유
  • 신규 글도 양면 작성 의무 — 본 스프린트에서 누락 후 사용자 지적으로 즉시 보정 (PR #235)
  • 영문판 톤 일치 기준: toward-model-agnostic-harness.mdx (1인칭, dash 강조, bold 패턴)

2.3 본문 형식

  • mdx 컴포넌트: MetricGrid/MetricCard × 2, Callout × 1
  • mermaid × 2 (상태머신 + 4계층 저장 구조)
  • ASCII 다이어그램 × 2 (컨텍스트 누적 + 슬라이딩 윈도우 원리)
  • GitHub URL 7곳 본문 직접 노출 (각주 X) — ADR 디렉토리 / sprint-145·151 ADR / CLAUDE.md / .claude/commands/agents/

2.4 Plan 가정 즉시 재라우팅 (Sprint 147 교훈 직접 적용)

  • 사용자 plan에 "librarian 디스패치" 명시되어 있었으나 페르소나 cross-check 결과 librarian = DB 영속성/마이그레이션 전담 (자료 수집/문서 큐레이션 외 도메인)
  • Scribe 단독 처리로 즉시 재라우팅 — Scribe가 "프로젝트의 모든 기억·문서·프롬프트의 정확성과 최신성을 전담"하는 정확한 도메인
  • 블로그 작업은 사용자 리뷰 사이클 빠름 → tmux dispatch 대신 Oracle이 scribe 페르소나로 직접 진행

3. 구현 흐름

3.1 PR #233 — 한국어판 신규 (9034a66)

1 commit, 1 file, +297

  • blog/content/posts/sliding-window-agent-context.mdx 신규
  • frontmatter: title / date(2026-05-13) / category(challenge) / order(10) / tags 5종(agent, documentation, sliding-window, context-optimization, claude-code)
  • 본문 10 섹션:
    1. 152번째 스프린트, 그리고 152개의 ADR (도입)
    2. 기억의 휘발성 — 사람도 agent도 잊는다
    3. 문서화는 진짜로 효과가 있었습니다 — Sprint 145~151 회귀 차단 8 차원 누적 실증
    4. 그런데 — 문서 자체가 적이 되기 시작했어요
    5. 꽉 찬 물통 비유 — lost-in-the-middle, attention 분산
    6. 슬라이딩 윈도우 알고리즘 — 알고리즘 시간으로 돌아가다
    7. sprint-window.md 크기 2 + status idle/active 상태머신
    8. 4계층 저장 구조 — "잊는 곳"과 "기억하는 곳"의 분리
    9. 운영 결과 — 7 스프린트 회귀 0건 + Auto-Critic 한 세트 철학
    10. 잊는 법을 배우는 것이 기억하는 법이었어요 (마무리)

3.2 PR #234 — 사실 정정 hotfix (9c8caa3)

1 commit, 1 file, +4 -4

  • 머지 직후 사용자 fact-check 지적: sprint별 ADR은 Sprint 62부터 도입됐고 현재 90개 가까이 쌓인 상태인데, 초안에 4곳 부정확 표현
  • 정정 4곳:
    • H2: "152번째 스프린트, 그리고 152개의 ADR" → "차곡차곡 쌓인 ADR들"
    • 도입부: "sprint-001부터 sprint-151까지" → Sprint 62 도입 배경 + "sprint-62부터 sprint-151까지 90개 가까이"
    • 본문 중반: "ADR이 100개를 넘어가던 시점부터" → "sprint별 ADR이 40개 가까이 쌓이던 시점부터"
    • 마무리: "ADR은 152개에서 200개, 300개로" → "sprint별 ADR은 90개에서 100개, 200개로"
  • 사실 근거: git ls-tree -r main --name-only | grep "docs/adr/sprints/" → sprint-62.md ~ sprint-148.md, 85개 tracked (sprint-149/150/151 untracked 별도)

3.3 PR #235 — 영문판 추가 (3873f6d)

1 commit, 1 file, +297

  • 머지 직후 사용자 i18n 누락 지적
  • blog/content/posts-en/sliding-window-agent-context.mdx 신규
  • 영문 제목: "Memory Fades, Documents Pile Up — A Sliding Window for Agent Context"
  • 한국어판 PR #234 사실 정정사항 모두 동시 반영 (Sprint 62 도입 / 90개 가까이 / 40개 누적 시점 / 90~200개 전망)
  • 톤 일치: toward-model-agnostic-harness.mdx 기준 1인칭 + dash 강조 + bold 패턴
  • mdx 컴포넌트 / mermaid / ASCII / GitHub URL 7곳 모두 한국어판과 1:1 동일

4. 검증

PRCImergeStateStatus비고
#23328 SUCCESS / 0 FAIL / 11 SKIPPEDBEHIND → CLEANupdate-branch 후 merge
#23428 SUCCESS / 0 FAIL / 11 SKIPPEDCLEANhotfix 즉시 통과
#23528 SUCCESS / 0 FAIL / 11 SKIPPEDCLEAN영문판 즉시 통과
  • i18n 검증: KR (blog/content/posts/) 10편 = EN (blog/content/posts-en/) 10편 ✅
  • mdx 컴포넌트 실재 검증: MetricGrid/MetricCard (blog/src/components/blog/metric-grid.tsx), Callout (blog/src/components/blog/callout.tsx)
  • 브랜치 규율 ✅: 3 PR 모두 신규 브랜치 + Squash merge — 18 스프린트 연속 준수 (Sprint 134 위반 이후), main 직접 commit 0건

5. 신규 패턴

  • Plan 가정 깨짐 즉시 재라우팅 (Sprint 147 교훈 직접 재적용): 사용자 plan에 "librarian 디스패치" 명시되었으나 페르소나 cross-check 결과 도메인 불일치 → 즉시 scribe 단독 처리로 재라우팅, cycle 영향 0. 5 스프린트 만에 재현된 동일 패턴
  • 블로그 작업 dispatch 우회 패턴: 코드 변경 0 + 사용자 리뷰 사이클 빠름 → tmux dispatch 대신 Oracle 직접 페르소나 채택. 단일 글 단위 (플랜→보완→작성) 사이클(feedback-blog-workflow)에 적합
  • 사용자 직접 fact-check가 글의 마지막 안전망: Auto-Critic이나 CI는 사실 정합성을 잡지 못함. 도메인 사실(ADR 시작 시점 / 누적 갯수 등)은 글 머지 직전 grep cross-check 절차가 필요 — 자동화 후보
  • i18n 누락 즉시 hotfix 패턴: 신규 블로그 글은 KR + EN 양면 작성이 의무이나 본 스프린트에서 누락 → 사용자 지적 후 즉시 보정 PR. plan 단계 i18n 의무 명시 절차 필요 — 자동화 후보
  • 단일 일자 3 PR 묶음 응답 패턴 (Sprint 150/151 hotfix 패턴 직접 계승): 사용자 지적 → 새 PR → CI green → Squash merge 평균 ~5분 cycle. 사실 정정 / i18n 누락 모두 별도 hotfix PR로 빠르게 응답 (대기/연기 X)

8. 산출물 링크