[보관] 27. Deep Study 시리즈 작성 — `study/` 14장 + 위키 sync 확장

시각: 2026-04-28 12:30 KST (추정)

무엇이 있었나

사용자 요청: “하나하나를 자세하게 공부하고 싶어. astro 위키 셋업 중인데 거기에 내용을 추가할 수 있어? 10장이 넘어가도 괜찮아. 나는 완벽하게 이해를 하고 싶은거야.”

24-eval-research.md (사전 리서치) 의 항목 하나하나를 깊이 학습 가능한 챕터 시리즈로 확장. 위치는 새 디렉토리 study/, Starlight 사이드바에 새 섹션으로 노출.

변경 파일

1. 신규 디렉토리 /Users/hamsters/hamster-lab/study/ 생성

2. 신규 파일 (15개):

   • study/00-index.md — 시리즈 인덱스 + 학습 로드맵
   • study/01-trajectory-vs-outcome.md — Trajectory vs Outcome 평가
   • study/02-llm-as-judge.md — LLM-as-Judge (편향·Cronbach α·Spearman ρ)
   • study/03-agent-as-judge.md — Agent-as-Judge
   • study/04-rubric-design.md — 다층 Rubric (7-25-130)
   • study/05-tau-bench.md — τ-bench와 pass^k
   • study/06-gaia-agentbench.md — GAIA · AgentBench
   • study/07-swe-bench.md — SWE-bench 계열
   • study/08-osworld-webarena.md — OSWorld · WebArena · Mind2Web
   • study/09-memory-benchmarks.md — Memory Benchmarks (H2 핵심)
   • study/10-tool-use-benchmarks.md — BFCL · ToolBench · ComplexFuncBench
   • study/11-eval-platforms.md — LangSmith · Braintrust · Langfuse · Phoenix · Galileo
   • study/12-eval-pipeline.md — Offline · Online · Monitoring
   • study/13-benchmark-pitfalls.md — Berkeley RDI 익스플로잇 + Goodhart
   • study/14-applying-to-our-experiment.md — 종합 적용 (1순위 4 지표 선정)

3. 인프라 변경:

   • wiki/scripts/sync.mjs — syncStudyDocs() 함수 추가, clean() 에 study/ 디렉토리 mkdir, main() 에 호출 + 카운트 로그
   • wiki/astro.config.mjs — sidebar 에 “평가 연구 (Deep Study)” 섹션 추가 (autogenerate: { directory: 'study' }, collapsed: false)

각 챕터 구조 (통일)

1. 정의 — 한 줄 요약
2. 핵심 메커니즘 — 수식·예시
3. 강점과 약점
4. 대안과의 비교
5. 우리 실험에의 적용 — H1·H2·H3 매핑
6. 더 읽을거리 — 1차 출처
7. 다음 장 미리보기
8. 이 장에서 확실히 알아야 하는 것 (체크리스트)

14장의 결정성

마지막 14장은 학습 노트지만 결정 commit의 입력값. 13개 후보 지표 (A–M) 를 비용·기대값·H 매핑으로 정렬하여 1순위 4개 (4-rubric / pass^3 / trajectory 분석 / 정책 위반 카운트) 도출. CSV 양식 최종안과 결정 매트릭스(§9) 정량화안 포함.

왜 그렇게 갔나

디렉토리 분리 이유

history/ 와 study/ 는 다른 종류의 문서다.

• history/ = 결정·실행 commit 로그. 시간순. 짧고 specific.
• study/ = 학습 노트. 토픽순. 길고 deep.

같은 폴더에 섞으면 둘 다 약해진다. Starlight sidebar에서도 “히스토리 (커밋 로그)” 와 “평가 연구 (Deep Study)” 가 분리 노출되는 게 맞다.

sync.mjs 확장 방식

기존 syncRootDocs(), syncHistoryDocs() 패턴을 그대로 따라 syncStudyDocs() 추가. 같은 frontmatter 주입 로직 재사용. 이게 최소 변경 + 일관성 둘 다 만족.

clean() 에서 study/ 디렉토리도 mkdir 하지 않으면 syncStudyDocs() 첫 실행에서 ENOENT — 그래서 clean() 에 한 줄 추가가 필요했다.

14장 구성 — 왜 14인가

10+ 장 OK라는 사용자 명시. 다음 흐름이 자연스러웠다:

• 방법론 (4장: 01–04) — 평가의 어휘
• 벤치마크 카탈로그 (6장: 05–10) — 학술 좌표
• 현장 운영 (2장: 11–12) — 산업 도구·파이프라인
• 비판·적용 (2장: 13–14) — Goodhart + 우리 실험에 매핑

이 4 블록이 완벽히 이해 의 윤곽. 더 적으면 깊이 부족, 더 많으면 중복.

LLM-as-judge 한계 명시

각 장의 “강점·약점” 과 13장 전체에서 벤치/평가의 한계 를 일부러 강조. 사용자가 “완벽하게 이해” 를 원했으므로, 맹신 금지 가 평가 학습의 핵심 페이로드.

무엇이 남았나

본 시리즈가 가능하게 한 것

• 사용자가 임의의 평가 어휘를 만나도 어느 장 어느 절 인지 매핑 가능
• 14장의 1순위 4 지표 (4-rubric / pass^3 / trajectory 분석 / 정책 위반 카운트) 가 다음 결정 commit 의 입력값으로 준비됨

다음 단계 — 결정 commit (예정)

14장의 권장이 §6 정식 편입으로 가려면, 별도 history 엔트리에서 결정 으로 분리:

• history/28-eval-redesign.md (또는 다음 비어있는 번호) — §6 갱신 + CSV 양식 변경 + 분석 스크립트 신설
• 동시에 01-experiment-design.md 의 §6 텍스트 갱신
• runs/runs.csv 헤더 갱신
• scripts/parse-trajectory.py, policy-check.py, llm-judge.py 신설

이 결정 commit 은 사용자 확인 후 실행. 본 엔트리는 학습 자산 추가 까지만.

sync 검증 필요

wiki/ 에서 npm run sync 또는 npm run dev 시 study/ 가 정상 노출되는지 한 번 검증 필요. 본 엔트리 작성 시점엔 소스만 추가, 빌드·서빙 미검증.

참고 — 24장 (사전 리서치) 와의 관계

history/24-eval-research.md 는 지형도. study/ 시리즈는 각 지점의 깊이 탐사. 24가 한 페이지 요약이라면 study는 14페이지 풀 가이드. 둘 다 유지 — 24는 빠른 참조, study는 학습.