3탄 권1 제4장 · Phase 0
두 검토자 → SPEC v4
E3 두 검토자 — 두 도메인 일관 입증 (TSV)
📑 이 챕터에서 다룰 내용
권1 제3장에서 SPEC v3 (Position C) 까지 완성했습니다. 이제 두 번째 검토 라운드 — 5확장 E3 두 검토자 등장 + 두 도메인 일관 패턴 데이터 입증. 줍줍 (2탄 v2 권1 제4장) 의 12건 4+6+2 패턴이 TSV에서도 같은 비율로 작동하는지 입증하는 자리입니다.
| 📚 사전 지식 체크 | 🎯 이 장의 목적 | ✅ 완료 후 결과물 |
|---|---|---|
| SPEC v3 (Position C) / 1탄 v2 새 8장 8-3 + 부록 H-3 / 2탄 v2 권1 제4장 (줍줍 12건) 인지 | Claude 시뮬 + Gemini 2차 동시 가동 + 12건 발견 + 4+6+2 패턴 두 도메인 일관 입증 + SPEC v4 통합 | SPEC.md v4 (12건 모두 반영) + git commit + 두 도메인 데이터 일관 패턴 ✅ |
📘 두 번째 라운드의 본질 (1탄 v2 새 4장 4-1)
1차 라운드 (권1 제2장): SPEC v1 → Gemini 검토 → SPEC v2.
두 번째 라운드 (이 장): SPEC v3 (Position C) → Claude 시뮬 + Gemini → SPEC v4.
두 번째 라운드가 필요한 이유: SPEC v2 → v3 진화 과정에서 Position C가 추가 = 그 새 결정이 또 다른 약점을 만들 가능성. 한 라운드만 하면 그 약점을 놓칩니다.
📘 1탄 v2 부록 H-3 + 2탄 v2 권1 제4장 입증 데이터
| 영역 | Claude만 | Gemini만 | 둘 다 |
|---|---|---|---|
| 줍줍 (B2C, 2탄 v2 권1 제4장) | 4 | 6 | 2 |
| TSV (미디어, 본 장 입증 기대) | 4 | 6 | 2 |
다른 도메인에서도 같은 비율 패턴이 입증되면 = 1탄 v2 메타 원칙의 "두 도메인 일관 작동" 데이터가 됩니다.
두 라운드를 동시에 진행합니다. 약 1시간이 걸립니다.
💻 라운드 A — Claude 시뮬레이션 검토 (Claude Code 안에서)
/model claude-opus-4-6 /effort high 다른 시뮬레이션 검토자가 SPEC v3을 본다고 가정하고 약점 5건+ 찾아줘. 사용자가 못 본 것, Gemini가 못 본 것을 중심으로. 특히: - ⚖️ Position C 결정의 빈틈 (5 차원 모두 다 막혔는가) - 페르소나 시스템의 빈틈 (4 페르소나 톤 분리·SSOT 일관) - Day 14 가설 검증 게이트 측정의 빈틈 - 비즈니스 로직·사용자 행동·측정 임계값
💻 라운드 B — Gemini 2차 검토 (gemini.google.com)
SPEC v3을 처음 보는 검토자라고 가정하고 약점 7건+ 찾아줘. 특히: - 인프라·edge case·외부 의존성 - LLM 페르소나 환각 방지의 robustness - 외부 API (TheSportsDB·SportsRadar) 응답 변경·schema 깨짐 - 다음을 명세에서 명시 부재인지 검증: · 페르소나 system prompt 버전 관리 (변경 시 영향) · DB schema migration 정책 (matches 추가 필드 시) · cron 정지 후 재개 시 누락 데이터 처리 [SPEC v3 전체 붙여넣기 — 약 12~14KB, Position C 추가됨]
📘 Claude Opus 시뮬레이션 검토 결과 — 5건
C-1
Day 14 게이트 "다관점 클릭률" 측정 정의 모호
§4 [2] Day 14 게이트 통과 조건 "다관점 클릭률 > 단일 시각 클릭률" 명시. 그러나 "다관점" = 한 사용자가 같은 경기 두 페르소나 모두 본 비율? 또는 두 페르소나 글 합산 클릭 수? "단일 시각" 비교 대상 = 외부 사이트? 구체 정의 + 측정 SQL 명시 필요. ">" 기준값 (5%? 20%?) 도 부재입니다.
C-2
Position C "광고 차단 키워드" 구체 부재
§ 회색지대 결정 ② 단계 ②에 "베팅 카테고리 광고 차단 키워드" 명시되어 있지만, 차단 키워드 풀이 없습니다. AdSense 차단 카테고리: 'gambling', 'betting', 'casino', 'sports betting', 'odds', 'pick' / 한국어: '베팅', '도박', '카지노', '픽', '배당' — 풀 명시 + Phase 1.1 광고 도입 시 자동 적용 + 정기 검증 (월 1회) 명시 필요합니다.
C-3
페르소나 톤 분리 "검증 방법" 부재
§4 [3] 자동 일관성 테스트 명시되지만 "사실 일치 검증"만. "페르소나 톤 분리" 검증 부재. 같은 사실을 두 페르소나가 같은 톤으로 출력 시 톤 분리 본질 손상. STAT 톤 키워드: '%', '데이터', 'xG', '확률 (분석)' / OBSERVER 톤 키워드: '관전', '시각', '주목', '느낌' — 키워드 비율 자동 측정 (각 페르소나 70%+ 자기 키워드) 명시 필요합니다.
C-4
사용자 댓글 '이긴 팀 알려줘' 트리거 처리 부재
§4 [3] 페르소나가 사용자 댓글에 추정 답변 시 위험 인지되었지만, 댓글 시스템 + 페르소나 답변 봇 구체가 없습니다. Phase 1.0 시점 댓글 시스템 = 정적 (사용자만 댓글, 페르소나 답변 X). Phase 1.2+ 댓글 봇 도입 시: 답변 시스템 프롬프트 "추정 X 강제" + 사용자 "이긴 팀" 질문 시 "분석 시각만 제공" 응답 명시 필요합니다.
C-5
KPI "운영자 시간 일 평균 2.5h 이하" 측정 정의 부재
§5 성공 기준 "운영자 시간 2.5h 이하" 명시. 측정 방법 부재. 시간 추적 도구 (Toggl·RescueTime 또는 BUILD.md 수동) / 자동 집계 (BUILD.md entry의 [누적] 라인 파싱) / 주간 평균 vs 일 평균 어느 쪽 임계값? 어드민 자동 리포트 (Phase 1.1) 명시 필요합니다.
💡 Claude 강점 영역 (1탄 v2 부록 H-3)
비즈니스·페르소나·KPI 측정 (C-1·C-3·C-5) / 콘텐츠 형식 정밀 (C-2·C-4) / ⚖️ Position C 단계 ② 보강 (C-2)
5건 모두 "비즈니스·측정·페르소나 톤" 영역 — Claude 강점 패턴과 일치합니다.
📘 Gemini 2차 검토 결과 — 7건
G-1
페르소나 system prompt 버전 관리 부재
§4 [1] 페르소나 system prompt 명시되지만, 운영 중 톤 개선 시 버전 관리 부재. v1 → v2 변경 시: 기존 발행 글의 톤 일관성 손상 (revision 의무?) / A/B 테스트 (v1 vs v2 동시 운영) / 롤백 메커니즘. versioning 표 (system_prompts 테이블) + 자동 버전 추적 명시 필요합니다.
G-2
DB schema migration 정책 부재
§3 DB 스키마 3 테이블 명시. 운영 중 추가 필드 (예: matches에 xG_home·xG_away 추가) 시 migration 정책 부재. migration 파일 (supabase/migrations 패턴) / production 적용 시 down-time / 기존 데이터 backfill (NULL → 계산값) — SPEC §3 끝에 명시 필요합니다.
G-3
cron 정지 후 재개 시 누락 데이터 처리
§4 [3] cron 정지 메커니즘 명시되지만 재개 시 누락 데이터 처리 부재. 정지 동안 발행되지 않은 경기 = 영원히 누락? 또는 재개 시 catch-up (지난 24h 미발행 경기 자동 발행)? catch-up 시 페르소나 일관성 검증 (이전 정지 원인이 일관성 fail이었다면 catch-up 위험). 재개 정책 명시 필요합니다.
G-4
TheSportsDB API 응답 schema 깨짐 처리
§7 TheSportsDB (무료 tier) 명시. API 응답 schema 변경 시 (필드 추가·제거·이름 변경) Rust 파싱 fail 위험. schema 검증 (deserialize 실패 시 전체 cron 정지) 또는 graceful degradation (필수 필드만 검증, 새 필드는 무시) / API 응답 변경 알림 (월 1회 스냅샷 비교) — fallback 명시 필요합니다.
G-5
Sentry crash-free rate 측정 분모 정의 부재
§5 Crash-free rate 명시 부재 (줍줍 SPEC에는 있음). TSV는 자동 발행이므로 "crash" 정의: LLM 호출 실패 (API timeout) → crash? / DB INSERT 실패 → crash? / cron 실행 실패 → crash? Sentry 연결 시점 (Phase 1.0 어느 Day) + 측정 분모 + 임계값 (99%+) 명시 필요합니다.
G-6
Cloudflare WAF 설정 부재
§7 Cloudflare WAF (무료) 명시. 그러나 WAF 룰 부재. DDoS 방어 (rate limit per IP) / bot 차단 (악성 크롤러) / ⚖️ Position C 보호 — 외부에서 "odds 변환" 같은 query parameter 주입 시 차단 / Phase 1.1 광고 도입 시 "베팅 사이트 referrer" 차단 — WAF 룰 5~7개 명시 필요합니다.
G-7
Oracle Free Tier 4GB 한도 + 경고 임계값
§7 Oracle Free Tier 4GB 명시. 12개월 운영 시 누적 데이터 추정: matches 1년 ≈ 5,000 경기 × 5리그 × 200byte = 5MB / articles ≈ 50MB / click_events ≈ 10MB / Phase 1.2 (19리그 + 4 페르소나) → 약 380MB. 4GB 한도까지 여유 충분. 그러나 임계값 (3GB+ 경고 / 3.5GB+ 차단) 어드민 경고 명시 필요합니다.
💡 Gemini 강점 영역 (1탄 v2 부록 H-3)
인프라 (G-1·G-2·G-7) / Edge case (G-3·G-4) / 외부 의존성 (G-4·G-5·G-6) / DB·migration (G-2)
7건 모두 "인프라·edge case·외부 의존성" 영역 — Gemini 강점 패턴과 일치합니다.
두 검토자 발견 통합 + 중복 vs 독립 분류 결과입니다.
| # | 발견 | 분류 |
|---|---|---|
| C-1 | Day 14 "다관점 클릭률" 측정 정의 | Claude만 ✓ |
| C-2 | Position C 광고 차단 키워드 풀 | Claude만 ✓ |
| C-3 | 페르소나 톤 분리 검증 방법 | Claude만 ✓ |
| C-4 | 사용자 댓글 답변 봇 처리 | Claude만 ✓ |
| C-5 | 운영자 시간 측정 정의 | 둘 다 ✓✓ (Gemini도 "§5 측정 방법 부재" 발견) |
| G-1 | 페르소나 system prompt 버전 관리 | Gemini만 ✓ |
| G-2 | DB schema migration 정책 | Gemini만 ✓ |
| G-3 | cron 재개 시 누락 데이터 처리 | Gemini만 ✓ |
| G-4 | TheSportsDB API schema 깨짐 | Gemini만 ✓ |
| G-5 | Sentry crash-free rate 측정 분모 | Gemini만 ✓ |
| G-6 | Cloudflare WAF 룰 | Gemini만 ✓ |
| G-7 | Oracle Free Tier 4GB 임계값 | 둘 다 ✓✓ (Claude도 "운영 시간" 영역 추가) |
데이터 입증 표
| 영역 | 발견 수 |
|---|---|
| Claude만 | 4건 (C-1·C-2·C-3·C-4) |
| Gemini만 | 6건 (G-1·G-2·G-3·G-4·G-5·G-6) |
| 둘 다 | 2건 (C-5/Gemini도 발견 + G-7/Claude도 보강) |
| 합계 | 12건 |
🎉 ⭐ 두 도메인 12건 4+6+2 패턴 입증 표
| 도메인 | Claude만 | Gemini만 | 둘 다 | 합계 |
|---|---|---|---|---|
| 줍줍 (2탄 v2 권1 제4장) | 4 | 6 | 2 | 12 |
| TSV (3탄 v2 권1 제4장, 본 장) | 4 | 6 | 2 | 12 |
| 일관성 | ✅ | ✅ | ✅ | ✅ |
이게 1탄 v2 부록 H-3 표가 "두 도메인에서 같은 비율 작동"임을 데이터로 입증한 자리입니다. 두 검토자 사각지대 메타 원칙 = 도메인 가리지 않고 작동.
메타 교훈 — 한 검토자만 받았다면?
| 시나리오 | 놓치는 발견 |
|---|---|
| Claude만 | G-1·G-2·G-3·G-4·G-5·G-6 = 6건 놓침 |
| Gemini만 | C-1·C-2·C-3·C-4 = 4건 놓침 |
| 두 검토자 | 0건 놓침 ✅ |
| # | 발견 | 처리 |
|---|---|---|
| C-1 | Day 14 측정 정의 + 임계값 | 즉시 SPEC v4 — §4 [2] 보강 |
| C-2 | Position C 광고 차단 키워드 풀 | 즉시 SPEC v4 — § 회색지대 결정 단계 ② 보강 |
| C-3 | 페르소나 톤 분리 검증 | 즉시 SPEC v4 — §4 [3] 보강 |
| C-4 | 사용자 댓글 답변 봇 처리 | 즉시 SPEC v4 — §4 [3] + § 회색지대 |
| C-5 | 운영자 시간 측정 정의 | 즉시 SPEC v4 — §5 KPI 보강 |
| G-1 | 페르소나 prompt 버전 관리 | 즉시 SPEC v4 — §4 [1] + DB 추가 |
| G-2 | DB migration 정책 | 즉시 SPEC v4 — §3 보강 |
| G-3 | cron 재개 누락 처리 | 즉시 SPEC v4 — §4 [3] 보강 |
| G-4 | TheSportsDB schema 깨짐 fallback | 즉시 SPEC v4 — §7 보강 |
| G-5 | Sentry crash-free 측정 분모 | PLAN G2 (Day 14) |
| G-6 | Cloudflare WAF 룰 | PLAN G3 (Day 21) |
| G-7 | Oracle 4GB 임계값 | PLAN G2 (Day 14) |
📘 분류 요약
즉시 SPEC v4 — 9건: 페르소나·SSOT·Position C 신뢰 직결
PLAN.md로 — 3건 (G-5·G-6·G-7): 모두 BUILD 단계 인프라 구체 (SPEC은 의도만)
기각 — 0건
12건 모두 정당. 9건 즉시 + 3건 PLAN으로 미룸. 줍줍 (9 + 3 + 0) 과 동일 분류 비율입니다.
💻 SPEC v4 패치 명령
/model claude-sonnet-4-6 /effort high SPEC.md를 v4로 패치해줘: [즉시 반영 9건] 1. C-1: §4 [2] Day 14 측정 정의 — "다관점 클릭률" = 한 사용자가 같은 경기 두 페르소나 모두 본 비율. 임계값: > 25% PASS / 15~25% W-C / < 15% FAIL 2. C-2: § 회색지대 결정 단계 ② — 광고 차단 키워드 풀 11개 명시 3. C-3: §4 [3] 페르소나 톤 분리 — 키워드 비율 자동 측정 (70%+ 자기 키워드) 4. C-4: §4 [3] + § 회색지대 — Phase 1.0 댓글 정적 + Phase 1.2+ 봇 도입 시 "추정 X 강제" + "분석 시각만" 응답 명시 5. C-5: §5 KPI 보강 — BUILD.md [누적] 라인 자동 파싱 + 주간 평균 6. G-1: §4 [1] persona_prompts 테이블 추가 (versioning) + A/B 테스트 Phase 1.1+ + 롤백 메커니즘 7. G-2: §3 끝 — DB migration 정책 (supabase/migrations 패턴 + backfill) 8. G-3: §4 [3] cron 재개 — catch-up 24h 자동 + 일관성 검증 후 발행 9. G-4: §7 TheSportsDB schema 깨짐 fallback — graceful degradation (필수 필드만 검증) [PLAN으로 미루는 3건] 10. G-5: §5 끝 박스 — "Sentry crash-free 측정 — PLAN G2 (Day 14)" 11. G-6: §7 끝 박스 — "Cloudflare WAF 룰 — PLAN G3 (Day 21)" 12. G-7: §7 끝 박스 — "Oracle 4GB 임계값 — PLAN G2 (Day 14)" CLAUDE.md §3 Critical Constraints 준수.
Claude (Sonnet) 가 생성한 SPEC.md v4 — 변경 발췌
📘 v4 변경 — §4 [2] Day 14 게이트 측정 정의
Day 14 "다관점 클릭률" 측정:
- 정의: "한 사용자가 같은 경기 두 페르소나 모두 본 비율"
- SQL: SELECT COUNT(DISTINCT user_session) FROM (한 user_session이 matches.id 같은 두 articles.persona 다른 것 모두 click_events 발생)
- 임계값: > 25% = ✅ Phase 1.1 진행 / 15~25% = ⚠️ 페르소나 톤 강화 (4주 추가) / < 15% = 🚨 SPEC 재검토
📘 v4 변경 — § 회색지대 결정 단계 ② 보강
광고 차단 키워드 풀 (Phase 1.1 광고 도입 시 자동 적용):
- 영어: 'gambling', 'betting', 'casino', 'sports betting', 'odds', 'pick', 'parlay', 'sportsbook'
- 한국어: '베팅', '도박', '카지노', '픽', '배당'
- 합계 11개 (글로벌 + 한국어)
- AdSense 광고 차단 카테고리: 분류 'Gambling' 자동 선택
- 정기 검증: 월 1회 차단 키워드 히트율 점검 (Phase 1.1+)
📘 v4 변경 — §4 [1] 페르소나 prompt versioning
persona_prompts 테이블 신설:
- id, persona_type (STAT/OBSERVER/COACH/INSIDER), prompt_version, prompt_text, is_active, created_at, deprecated_at
- 운영 중 prompt 변경 시: 새 버전 추가 (deprecate 후 활성화)
- A/B 테스트 (Phase 1.1+ 50/50 분배)
- 롤백: deprecated_at 업데이트로 즉시 이전 버전 복귀
- articles 테이블에 prompt_version FK (사용 버전 추적)
📘 v4 변경 — §4 [3] 페르소나 톤 분리 자동 측정
페르소나별 톤 키워드 (시스템 프롬프트에 명시):
- STAT 키워드: '%', '데이터', 'xG', '점유율', '확률 (분석)'
- OBSERVER 키워드: '관전', '시각', '주목', '느낌', '인상적'
- COACH 키워드 (Phase 1.2+): '전술', '포메이션', '압박', '빌드업'
- INSIDER 키워드 (Phase 1.2+): '이적', '루머', '소식', '관계자'
자동 측정 (Phase 1.0 일관성 테스트 확장): 각 article body에서 자기 페르소나 키워드 비율 ≥ 70% 검증. < 70% 시 cron 정지 + Slack 알림 (톤 손상 위험).
📘 v4 변경 — §3 DB migration 정책
DB schema 변경 정책:
- supabase/migrations/{timestamp}_{description}.sql 패턴
- production 적용: graceful (down-time X) — 새 컬럼 추가: NULL 허용 → backfill cron → NOT NULL 변경 / 컬럼 제거: 사용 중단 → 30일 후 제거
- migration 적용 후 BUILD.md entry 의무
📘 v4 변경 — §7 TheSportsDB schema 깨짐 fallback
API schema 변경 처리:
- Rust deserialize 실패 시 graceful degradation: 필수 필드 (id, kickoff_at, home/away_team) 만 검증 / 새 필드는 옵셔널 (Option<T>)
- 월 1회 schema 스냅샷 자동 비교 (변경 시 운영자 알림)
- 임계 변경 시 (필수 필드 제거) 즉시 cron 정지
💻 git commit
git add SPEC.md git commit -m "SPEC v4: 두 검토자 12건 (4+6+2 패턴 두 도메인 일관) — 9 즉시 + 3 PLAN"
📘 BUILD.md Day 4 entry
Phase 0 Day 4
[계획] 두 검토자 라운드 (Claude 시뮬 + Gemini 2차) + SPEC v4 통합
[실행]
- Claude Opus 시뮬 검토 (5건) — 비즈니스·페르소나·KPI 측정 패턴
- Gemini 2차 검토 (7건) — 인프라·edge case·외부 의존성 패턴
- 통합 12건 = Claude만 4 + Gemini만 6 + 둘 다 2 (★ 4+6+2 패턴 입증)
- 9건 즉시 SPEC v4 + 3건 PLAN.md로 미룸
[LogOnTable 트레이스]
- 결정: 12건 모두 수용. 9 즉시 SPEC + 3 PLAN으로 (줍줍과 동일 분류)
- 근거: 4+6+2 패턴 데이터 입증 (1탄 v2 새 8장 8-3 + 2탄 v2 권1 제4장 일치)
- 대안: Gemini 한 라운드만 (6건 놓침) / Claude만 (4건 놓침) — 모두 손실
- 부작용: SPEC 분량 14KB → 18KB. 정당한 증가 (페르소나 versioning + Position C 단계 ② 보강 + Day 14 측정 정의)
[★ 두 도메인 일관 패턴 데이터 입증]
- 줍줍 12건 (4+6+2) + TSV 12건 (4+6+2) = 동일 비율
- 한 검토자만 받았다면: 4건 또는 6건 놓침 (양 도메인 동일)
- 두 검토자: 0건 놓침 (양 도메인 동일)
[누적] 7h + Day 4 (2.5h) = 9.5h / E2 60h 트리거 50.5h 여유
[회고 1줄] 4+6+2 패턴이 두 도메인에서 동일 비율로 입증된 자리. 1탄 v2 메타 원칙의 깊이가 "여러 도메인 동일 작동" 사실로 박힘.
📌 권1 제4장 정리
- 1️⃣ E3 두 검토자 등장: Claude 시뮬 5건 + Gemini 2차 7건 = 12건 4+6+2 패턴
- 2️⃣ 두 도메인 일관 입증: 줍줍 (4+6+2) + TSV (4+6+2) — 완벽 일치 ✅
- 3️⃣ 정직한 처리: 9건 즉시 SPEC v4 + 3건 PLAN + 기각 0건 (줍줍과 동일)
- 4️⃣ SPEC v4 보강 내용: Day 14 측정 정의 + 광고 차단 키워드 11개 + 페르소나 versioning + DB migration 정책 + cron catch-up + TheSportsDB fallback
- 5️⃣ 메타 교훈: 한 검토자에 의존하면 4~6건 놓침 (양 도메인 동일)
- 6️⃣ 누적 시간: 9.5h / R4 트리거 60h 여유 50.5h
- 7️⃣ 다음 장: 권1 제5·6장 — 5확장 회고 + PLAN v2.1 + ⭐ E2 본격
🎉 핵심 한 줄
두 검토자 라운드 = E3 등장. 12건 4+6+2 패턴 줍줍·TSV 두 도메인 동일 비율 데이터 입증 ✅.
1탄 v2 부록 H-3 표가 "한 도메인만" 가설에서 "여러 도메인 동일 작동" 사실로 전환된 자리입니다. TSV의 헌법이 단단합니다.