2탄 권2 제2장
2탄 권2 — 제2장

Day 4~7: 시딩 20개 + G1 첫 게이트 통과

첫 게이트 통과 의식 — git tag + 1주차 회고 + 의식적 휴식

📑 이 챕터에서 다룰 내용
📘 들어가며 — 첫 게이트의 자리

권2 제1장에서 Day 1~3에 인증·테스트·prompt까지 완성. 누적 27.5h. 이제 G1 (Day 7) 첫 게이트를 향한 4일입니다. 시딩 20개 + LLM fallback + 게이트 통과 의식.

  • 사전 지식: Day 1~3 완료 / SPEC v4 §3-2 (LLM 분류) / E2 게이트 의식
  • 이 장의 목적: Day 4 (시딩 20개) + Day 5 (G-1 fallback) + Day 6 (G1 점검) + Day 7 (G1 통과 의식)
  • 완료 후 결과물: benefits 임시 저장 20개 + 어드민 큐 데이터 + git tag v0.1-G1-passed + 1주차 회고
2-1 Day 4 — 시딩 20개 검수 + confidence 분포 🔗
💻 Claude Code 자연어 입력
"4 API에서 각 5건씩 총 20건 가져와서 lib/parser/classify.ts 로 분류.

소상공인 (bizinfo + smtech) 10건 → SYSTEM_PROMPT_BUSINESS
개인 복지 (welfare_central + welfare_local) 10건 → SYSTEM_PROMPT_INDIVIDUAL

결과:
- tests/seed-results/business-10.json
- tests/seed-results/individual-10.json

confidence 분포 + status 분포 콘솔 출력."

결과 — 20건 분류

분류건수비율평균 confidence
auto_active (소상공인)7건70%0.81
admin_queue (소상공인)2건20%0.62 / 0.58
admin_queue_parse_failed (소상공인)1건10%0 (welfare_local XML)
auto_active (개인 복지)6건60%0.79
admin_queue (개인 복지)3건30%0.62 / 0.55 / 0.49
admin_queue_parse_failed (개인 복지)1건10%0 (welfare_local XML)
🎉 20건 합계 결과
  • auto_active 13건 (65%, 평균 0.80) — G1 통과 조건 ≥0.75 PASS ✅
  • admin_queue 5건 (25%) — 정상 운영 분포
  • admin_queue_parse_failed 2건 (10%) — welfare_local XML fallback 작동
📘 G-1 fallback의 의미

권1 제2장에서 Gemini가 발견한 G-1 (LLM JSON fallback)이 Day 2에 welfare_local XML 응답으로 입증됐고, Day 4에 2건 실제 fallback 발생. SPEC v4 §3-2의 "raw_response 보존 + admin 큐 직행"이 작동합니다.

📘 BUILD.md Day 4 LogOnTable

[LogOnTable 트레이스 ① — confidence 분포 검증]

  • 결정: G1 통과 조건 "confidence 평균 ≥ 0.75" PASS (실제 0.80)
  • 근거: SPEC v4 §3-2 명세 + PLAN G1 통과 조건 일치
  • 대안: 임계값 0.7 (너무 관대) / 임계값 0.8 (너무 엄격, auto_active 30% 미만 위험)
  • 부작용: confidence 0.65 같은 행도 admin 큐로 가서 검수자 피로 증가 — Day 13 SLA 7일 cron 필수

[LogOnTable 트레이스 ② — welfare_local XML fallback]

  • 결정: welfare_local API 2건 모두 admin_queue_parse_failed → raw_text 보존
  • 근거: 권1 제2장 G-1 → SPEC v4 §3-2 fallback → Day 2 발견 → Day 4 실제 발생
  • 대안: welfare_local API 별도 XML→JSON 변환기 — 코드 복잡도 증가
  • 부작용: Day 12 admin 페이지에서 welfare_local raw XML 처리 필요

누적: 27.5h + Day 4 (3h) = 30.5h / E2: 60h 트리거 29.5h 여유

2-2 Day 5 — G-1 fallback 어드민 검수 큐 prototype 🔗
💻 Claude Code 자연어 입력
"Day 4의 admin_queue 5건 + admin_queue_parse_failed 2건 = 7건을
admin 검수 큐 prototype에 저장.

prototype: lib/admin/review-queue.ts (TypeScript 인터페이스만,
실제 페이지는 Day 12)

데이터:
- 7건 raw_response (admin이 직접 검토할 자료)
- 각 행의 confidence·status·timestamps
- 재분류 시도 함수 (운영자가 강제 재분류)"

Claude가 작성한 lib/admin/review-queue.ts (약 50줄)

💻 lib/admin/review-queue.ts
// lib/admin/review-queue.ts
// 어드민 검수 큐 — confidence < 0.7 또는 parse 실패 행

export interface ReviewQueueItem {
  id: string;
  source: 'bizinfo' | 'smtech' | 'welfare_central' | 'welfare_local';
  raw_content: string;       // API 원문 또는 raw_text (XML 등)
  classify_result: ClassifyResult;
  added_at: string;
  reviewed_at: string | null;
  reviewer_action: 'pending' | 'approved' | 'rejected' | 'reclassify';
}

export async function reclassify(
  item: ReviewQueueItem,
  tab: 'business' | 'individual',
): Promise<ReviewQueueItem> {
  // 운영자가 강제 재분류 트리거 — Sonnet 4.6 사용 (Haiku 대비 정확도 ↑)
  const newResult = await classifyContent(item.raw_content, tab);
  return {
    ...item,
    classify_result: newResult,
    reviewer_action: newResult.confidence >= 0.7 ? 'approved' : 'pending',
  };
}

// SLA 7일 cron 트리거 (Day 13 구현)
export function getOverdueItems(items: ReviewQueueItem[]): ReviewQueueItem[] {
  const now = new Date();
  return items.filter(item => {
    if (item.reviewer_action !== 'pending') return false;
    const added = new Date(item.added_at);
    const daysSince = (now.getTime() - added.getTime()) / (1000 * 60 * 60 * 24);
    return daysSince >= 7;
  });
}
📘 Day 5 LogOnTable

[LogOnTable 트레이스 ① — 재분류 시 Sonnet 사용]

  • 결정: 재분류는 Sonnet, 첫 분류는 Haiku
  • 근거: 1탄 v2 새 28장 비교 우위 — admin 큐 행은 복잡한 한국어 공고 가능성 높음. Sonnet으로 재시도가 정확도 개선
  • 대안: 항상 Sonnet — 비용 4배 (월 $6) / 항상 Haiku — admin 큐 누적
  • 부작용: 재분류 빈도 추적 필요 (Phase 1.1 이후 자동화 검토)

[LogOnTable 트레이스 ② — SLA 7일 의도 명시]

  • 결정: getOverdueItems 함수 prototype
  • 근거: SPEC v4 §3-2의 "검수 큐 SLA 7일" (C-3 발견)
  • 부작용: Day 13 cron 매일 09:00 + Slack 알림 필수

누적: 30.5h + Day 5 (2.5h) = 33h / E2: 60h 트리거 27h 여유

2-3 Day 6 — G1 통과 조건 점검 + 문서화 🔗

G1 통과 조건 (PLAN.md 복기)

💻 G1 통과 조건 체크리스트
G1 — Day 7: API 4개 + 시딩 20개

[기능 통과 조건]
[ ] bizinfo 인증키 정상 + 호출 OK
[ ] smtech 인증키 정상 + 호출 OK
[ ] welfare_central 인증키 정상 + 호출 OK
[ ] welfare_local 인증키 정상 + 호출 OK (XML 응답 인지)
[ ] 시딩 20건 분류 완료
[ ] auto_active 평균 confidence ≥ 0.75
[ ] admin 큐 7건 prototype 데이터 보존

[★ 페이스 점검 (E2)]
[ ] 누적 시간 < 14h (1주차 가용)
[ ] 토요일 작업 X
[ ] 일요일 30분 회고 작성

Day 6 자기 점검 결과

🎉 G1 점검 결과 — 전항목 PASS

[기능 통과 조건]

  • ✅ bizinfo 인증·호출 OK (Day 1·2)
  • ✅ smtech 인증·호출 OK
  • ✅ welfare_central 인증·호출 OK
  • ✅ welfare_local 인증·호출 OK (XML 인지 + admin 큐 처리)
  • ✅ 시딩 20건 분류 완료 (13 auto + 5 admin + 2 XML)
  • ✅ auto_active 평균 confidence 0.80 (≥0.75 PASS)
  • ✅ admin 큐 7건 lib/admin/review-queue.ts 보존

[★ 페이스 점검]

  • ✅ 누적 6.5h (Day 1~5) < 14h (1주차 가용 28h)
  • ✅ 토요일 작업 X (Day 5 토요일 — 작업 X 확인)
  • ✅ 일요일 회고 (Day 7) — 다음 entry에 작성 예정

종합 판정: G1 통과 조건 7/7 PASS + 페이스 3/3 PASS = G1 ✅ READY

📘 Day 6 LogOnTable

[LogOnTable 트레이스 — G1 통과 조건 "숫자 명시" 가치]

  • 결정: G1 통과 조건이 "숫자 명시" (≥0.75)라 자동 점검 가능
  • 근거: 1탄 v2 새 6장 6-3 절 "DoD 숫자 명시" 메타 원칙 + PLAN.md G1 본문 일치
  • 대안: "품질 좋음" 같은 모호한 표현 — 자기 검증 불가능
  • 부작용: 매 게이트마다 측정 가능 항목 작성 부담 (Phase 1.0 5게이트 모두 적용 필요)

누적: 33h + Day 6 (1h) = 34h / E2: 60h 트리거 26h 여유

2-4 Day 7 — G1 통과 의식 + 1주차 회고 🔗
💻 G1 통과 의식 — 1탄 v2 새 6장 6-3 (b) 절 적용
# 1. git tag
git tag v0.1-G1-passed
git push origin v0.1-G1-passed

# 2. 1주차 회고 작성 (BUILD.md, 1KB+)
# 3. 휴식 (Day 7 일요일 작업 후 또는 Day 8 휴식)

1주차 회고 — BUILD.md (1.2KB)

📘 BUILD.md Day 7 — ★ G1 PASSED ★

기능 통과 조건 7/7 PASS ✅ / 페이스 점검 3/3 PASS ✅ / git tag v0.1-G1-passed ✅

데이터·코드 산출물

  • API 4개 인증 (개발계정)
  • lib/api/test-fetch.ts (80줄)
  • tests/api-samples/ 4개
  • lib/parser/prompts.ts (90줄, 두 프롬프트 분리)
  • lib/parser/classify.ts (70줄)
  • lib/admin/review-queue.ts (50줄)
  • 시딩 20건 분류 (13 auto + 5 admin + 2 XML)

5확장 운영 단계 작동

  • E1: API 키 .env.local 절대 안전 (CLAUDE.md §3 매일 점검)
  • E2: 누적 7h (1주차 가용 28h의 25%, 매우 안전)
  • E3: SPEC v4 G-1 fallback의 입증 (Day 2 → Day 4)
  • E4: LogOnTable 9 트레이스 (Day 1·2·3·4·5·6·7)
  • E5: Two-Tab 7 규칙 [4] [7] 작동 — 두 프롬프트 분리 + 환각 방지

1탄 v2 메타 원칙 데이터 입증 (이번 주)

  1. 의도적 불완전 v1 → 보완 — Gemini G-1이 권1 제2장에서 명세됐고, Day 2에 입증, Day 4에 실제 발생
  2. 비교 우위 멀티모델 — Haiku 분류 단순 작업 안정 작동. $1.5/월 추정
  3. DoD 숫자 명시 — G1의 "평균 confidence ≥ 0.75"가 자동 점검 가능

누적: 34h + Day 7 (1h 회고) = 35h / E2: 60h 트리거 25h 여유. G1 통과 후 안전 영역.

🎉 휴식 의식
  • Day 8 (월요일) 작업 30% 축소 — 4h → 2.5h
  • Day 7 일요일 오후 자유 시간 의무
2-5 1주차 점검 — 권2 첫 7일의 본질 🔗
📘 누적 현황
  • 권1 (Phase 0) 7일: 21h — 5파일+ 체계 + 5확장 등장
  • 권2 (Phase 1.0) 1주차: 14h (G1 통과) — 첫 코드 + 4 API 인증 + LLM 분류 + 시딩 20건
  • 권1+권2 1주차 누적: 35h — R4 트리거 60h까지 25h 여유

권2 1주차의 본질: SPEC v4의 "의도적 불완전" 보완 명세가 코드에서 입증되는 자리. Gemini G-1 fallback이 가설 → 사실로 전환됐습니다.

📌 권2 제2장 정리

  • 핵심: Day 4~7 = 시딩 20건 분류 + 어드민 큐 prototype + G1 첫 게이트 통과 의식 (git tag)
  • Day 4 — 시딩 20건: 13 auto + 5 admin + 2 XML fallback. confidence 평균 0.80 (G1 ≥0.75 PASS)
  • Day 5 — 어드민 큐 prototype: review-queue.ts (50줄). 재분류 = Sonnet. SLA 7일 overdue 함수 prototype
  • Day 6 — G1 통과 점검: 7/7 PASS + 페이스 3/3 PASS
  • Day 7 — G1 통과 의식 (E2): git tag v0.1-G1-passed / 1주차 회고 (1.2KB) / Day 8 작업 30% 축소
  • 누적 시간: 35h (Phase 0 21h + 1주차 14h) / R4 거리: 25h 여유
  • E3 (두 검토자) 입증: G-1 fallback 가설 → 사실 (Day 2 발견 → Day 4 실제 발생)
🎉 첫 게이트가 통과됐습니다

G1 ✅ + git tag + 1주차 회고. 35시간 누적, R4 트리거 25시간 여유. 5확장 5개가 운영 단계에서 작동 중입니다.

특히 E3 (두 검토자)의 "가설 → 사실" 전환이 이번 주의 가장 큰 가치 — Gemini가 권1 제2장에서 발견한 G-1이 Day 2에 즉시 입증, Day 4에 실제 발생.