📑 이 챕터에서 다룰 내용
권1 제0~4장에서 SPEC.md가 v1 → v2 → v3 → v4까지 진화했습니다. 5파일+ 사이클 단계 ①~⑤가 본문에 박혔어요. 이 짧은 회고 챕터에서 5확장 등장 점검 + 두 도메인 일관 패턴 누적 정리를 마칩니다.
| 📚 사전 지식 체크 | 🎯 이 장의 목적 | ✅ 완료 후 결과물 |
|---|---|---|
| 권1 제0~4장 정독 + 2탄 v2 권1 제5장 (줍줍 회고) 인지 | Phase 0 Day 1~4의 5확장 등장 점검 + 두 도메인 일관 패턴 4 자리 정리 + 권1 제6장 (PLAN) 진입 준비 | 5확장 점검표 + 5파일 상태 + 누적 시간 (E2 트리거 거리) + 두 도메인 일관 패턴 |
| 확장 | 본격 등장 챕터 | 상태 | 핵심 데이터 |
|---|---|---|---|
| ⚖️ E1 회색지대 | 권1 제3장 | ✅ 본격 | Position C 단일 결정 4단계 풀 (5 차원) |
| ★ E2 1인 페이스 | 권1 제6장 (PLAN) | ⏳ 다음 챕터 | 누적 시간 9.5h |
| ⭐ E3 두 검토자 | 권1 제2·4장 | ✅ 본격 | 12건 4+6+2 패턴 두 도메인 일관 입증 |
| ⭐ E4 LogOnTable | 권1 제0~4장 매 entry | ✅ 본격 | BUILD.md 5 트레이스 |
| ⭐ E5 콘텐츠 SSOT | 권1 제7장 (CLAUDE) | ⏳ 권1 마지막 | § 측정 메트릭 일부만 (Day 4) |
3개 본격 ✅ + 2개 ⏳ 예정. 권1 제6~7장에서 E2·E5 본격 등장 → 권1 끝 = 5확장 5/5 모두 등장 완성.
tsv/ ├── SPEC.md (18KB) ✅ v4 — 7항목 + ⚖️ Position C + § 측정 메트릭 + 9건 보강 ├── PLAN.md ( 0KB) ⏳ 권1 제6장 ├── REVIEW.md ( 0KB) ⏳ 권1 제7장 ├── BUILD.md ( 4KB) ✅ Day -1~4 entry + 5 LogOnTable 트레이스 ├── CLAUDE.md ( 1KB) ⏳ 3 섹션 — 권1 제7장 10 섹션 완성 ├── .gitignore └── (BUILD 단계 전 — 코드 없음)
5파일+ 사이클 단계 ①~⑤ 진행 완료. 단계 ⑥ (PLAN) → 단계 ⑦ (REVIEW + READY)가 권1 마지막 두 챕터입니다.
| Day | 작업 | 시간 |
|---|---|---|
| Day -1 | 이름 결정 + 5파일 빈 껍데기 + Position C 인식 | 0.5h |
| Day 1 | SPEC v1 작성 (Opus + high) | 1.5h |
| Day 2 | Gemini 1차 + SPEC v2 | 2h |
| Day 3 | E1 Position C 4단계 + SPEC v3 | 3h |
| Day 4 | 두 검토자 + SPEC v4 | 2.5h |
| 누적 | 9.5h |
R4 (1인 번아웃) 트리거 60h/4주 까지의 거리: 50.5h 여유.
줍줍 권1 제5장 시점 누적 9.5h (정확히 동일). 두 도메인의 Phase 0 작업 부담이 동일 = 5파일+ 사이클 7단계가 도메인 가리지 않고 같은 시간 패턴으로 작동합니다.
권1 제0~4장 동안 줍줍 (2탄 v2) 와 TSV (3탄 v2) 의 4 자리 일관 패턴이 박힌 데이터입니다.
| 자리 | 줍줍 | TSV |
|---|---|---|
| 권1 제0장 — 이름 + 회색지대 인식 | 4 요소 트레이스 + 표현·개인정보 (2건) | 4 요소 트레이스 + Position C (1건, 5 차원) |
| 권1 제1장 — SPEC v1 | Opus + high + 7항목 + 4 테이블 + 의도적 불완전 6 | Opus + high + 7항목 + 3 테이블 + 의도적 불완전 6 |
| 권1 제2장 — Gemini 1차 | 6건 발견 (5 인프라 + 1 비즈니스), 4+2+0 분류 | 6건 발견 (5 인프라 + 1 비즈니스), 4+2+0 분류 |
| 권1 제4장 — 두 검토자 | 12건 (4+6+2), 9 즉시 + 3 PLAN | 12건 (4+6+2), 9 즉시 + 3 PLAN |
1탄 v2 메타 원칙이 "두 도메인에서 같은 비율로 작동"의 사실 입증이 누적되고 있습니다.
차이의 의미 — 형식만 다름: 줍줍은 회색지대 분리 (표현 + 개인정보) → 4 테이블 → 6건 → 12건 / TSV는 회색지대 통합 (Position C 5 차원) → 3 테이블 → 6건 → 12건. 메타 원칙 (4단계 프레임·12건 4+6+2 패턴·정직한 분류 4+2+0) 100% 동일. 형식 차이만 도메인 본질에 따라 다를 뿐입니다.
권1 제5장 회고에서 SPEC v4 완성 + 5파일+ 사이클 단계 ①~⑤ 끝. 이제 단계 ⑥ — PLAN v1 → v2.1. 5확장 E2 (1인 12개월 페이스) 의 등장 자리입니다.
| 📚 사전 지식 체크 | 🎯 이 장의 목적 | ✅ 완료 후 결과물 |
|---|---|---|
| SPEC v4 / 1탄 v2 새 6장 + 부록 H-2 / 2탄 v2 권1 제6장 (줍줍 PLAN v2.2) 인지 | PLAN v1 → v2.1 (33일 + 5 게이트 + 12 리스크 + ⭐ E2 3 형태) | PLAN.md v2.1 + git commit |
| SPEC.md ✅ (제1~4장) | PLAN.md ◀ 지금 여기 | REVIEW.md (제7장) | BUILD.md ✅ Day -1~4 | CLAUDE.md (제7장) |
|---|---|---|---|---|
| 완성 | 진행 중 | 대기 | 완성 | 대기 |
"이 사람이 12개월 동안 무너지지 않을 페이스인가"의 메타 결정. 9개 표준 도구 미점유 영역.
3 형태: (a) 시간 갭 정직 계산 (옵션 A/B/C) / (b) 게이트 + 휴식의 의식 / (c) R4 1인 번아웃 리스크 등록부
/model claude-opus-4-6 /effort high SPEC.md v4를 읽고 PLAN.md를 작성해줘. TSV는 Phase 1.0 = 33일 일정. 기준: 1. Phase 1.0 = 33일 안에 일 10글 자동 발행 + Day 14 가설 검증 통과 2. Phase 1.0 의도적 무수익 (SPEC §6 명시) 3. 각 게이트의 DoD 숫자 명시 4. 변경 파일 약 30개 (Rust 백엔드 + Next.js + DB migration) 5. ⭐ Day 14 CRITICAL 게이트 — 다관점 가설 검증 (PASS/W-C/FAIL 분기) 6. 의존성 명시 7. 리스크 등록부 R1~R12 (영향·확률·완화책·트리거) 8. ⭐ E2 1인 페이스 의식 (게이트 휴식 + R4 1인 번아웃) Phase 1.1+ (Day 34~) 는 SPEC §6 의도만 명시 (PLAN에 상세 X — 권3 권4 권5 자리).
Claude (Opus) 가 생성한 PLAN v1 — 발췌
Phase 1.0: MVP — 5리그 자동 발행 + Day 14 가설 검증
- 기간: 33일 (Day 1~33)
- 변경 파일: 약 30개 (Rust 약 18 + Next.js 약 8 + DB migration 약 4)
- 가용: 132h (33일 × 4h/일)
- DoD: 일 10글 7일 무장애 + Day 14 가설 PASS + SEO 100+ 유입
주차별 핵심
| 주차 | Day | 핵심 |
|---|---|---|
| 1 | 1~7 | TheSportsDB API 인증 + 5리그 fetch + DB 시드 (G1) |
| 2 | 8~14 | LLM 페르소나 시스템 + Day 14 ★ CRITICAL (G2) |
| 3 | 15~21 | 페르소나 prompt 안정 + Cloudflare WAF (G3) |
| 4 | 22~28 | SEO 구조 + 자동 일관성 테스트 + Sentry (G4) |
| 5 | 29~33 | Phase 1.0 종료 점검 + Phase 1.1 진입 결정 (G5) |
게이트 5개
리스크 등록부 R1~R12
| # | 리스크 | 영향 | 확률 | 완화책 | 트리거 |
|---|---|---|---|---|---|
| R1 | 페르소나 환각 (사실 추정) | 높 | 중 | E5 [7] 환각 방지 명세 | 일관성 fail >5%/주 |
| R2 | TheSportsDB API 한도/장애 | 중 | 낮 | 24h 캐시 fallback | 호출 실패 >5%/일 |
| R3 | ⚖️ Position C 위반 (콘텐츠) | 높 | 낮 | 광고 차단 키워드 + 페르소나 prompt | 사용자 신고 1건+ |
| R4 | 1인 운영 번아웃 | 높 | 중 | ★ 5 의식 (게이트 휴식·페이스 점검·토요일 X·회고·트리거 4) | 누적 60h+/4주 |
| R5 | LLM 비용 폭증 | 중 | 낮 | cache_control + Haiku 일부 | 월 비용 > $50 |
| R6 | SEO 카니발리제이션 | 중 | 중 | 페르소나별 키워드 분리 | 같은 키워드 두 페이지 |
| R7 | 외부 API schema 변경 | 중 | 낮 | graceful degradation | deserialize fail |
| R8 | DB 4GB 한도 도달 | 낮 | 낮 | 임계값 경고 (3GB+) | 사용량 모니터 |
| R9 | cron 정지 후 재개 누락 | 중 | 낮 | catch-up 24h 자동 | cron 정지 발생 |
| R10 | Cloudflare WAF 오차단 | 낮 | 중 | WAF 룰 정기 검토 (월 1회) | 정상 사용자 차단 |
| R11 | 페르소나 prompt 버전 충돌 | 중 | 낮 | versioning + A/B + 롤백 | prompt 변경 후 일관성 fail |
| R12 | Phase 1.1 광고 도입 시 베팅 광고 | 높 | 중 | 차단 키워드 풀 11 + AdSense 카테고리 | Phase 1.1 시작 시 |
가용: 132h / 필요 (v1 추정): 약 150h — 33일 빠듯, 시간 갭 +18h 발생
→ v2 진화 시 옵션 A·B·C 검토 필요합니다.
PLAN v1 작성 후 SPEC v4의 9개 보강이 PLAN에 미치는 시간 영향 산식을 계산합니다.
추가 작업 — 9건 즉시 SPEC
- C-1 Day 14 측정 SQL + 어드민 분석: +4h (G2)
- C-2 Position C 광고 차단 키워드 풀 적용: +2h (G3)
- C-3 페르소나 톤 분리 자동 측정: +3h (G3·G4)
- C-4 댓글 봇 처리 (Phase 1.0 정적 + Phase 1.2+ 의도): +1h (G3)
- C-5 운영자 시간 측정 (BUILD.md 자동 파싱): +2h (G4)
- G-1 persona_prompts 테이블 + versioning: +3h (G2)
- G-2 DB migration 정책 (graceful): +2h (G1)
- G-3 cron 재개 catch-up: +2h (G2)
- G-4 TheSportsDB schema fallback: +2h (G1)
- 합계: +21h
가용 시간 점검: PLAN v1 가용 132h / v2 기준 필요 132h + 21h = 153h → 1일 평균 4h가 4.64h로 늘어나야 함
⭐ E2 시간 갭 흡수 옵션 A·B·C
| 옵션 | 방법 | 단점 | 장점 |
|---|---|---|---|
| A | 부가 기능 축소 (-12h): Cloudflare WAF 룰 일부 (5 → 3개) + persona_prompts versioning A/B 테스트 Phase 1.1로 이연 | SPEC v4 9건 보강 일부 약화 | 일정 그대로 (33일) |
| B | Day 14 게이트 단순화 (-8h): 어드민 분석 페이지 일부 (수동 SQL만 유지) | Day 14 가설 검증 본질 약화 위험 | 일정 그대로 |
| C ← 채택 | 일정 3일 연장 (+12h 가용): Phase 1.0 Day 1~33 → Day 1~36 / 가용 132h → 144h / 1일 평균 4h → 4.36h (+0.36h) | 일 10글 발행 시작 3일 지연 | SPEC v4 9건 보강 모두 적용 + Day 14 가설 검증 |
"Phase 1.0의 본질은 'Day 14 가설 검증 통과 + 일 10글 7일 무장애'이지 33일이라는 캘린더가 아닙니다. 가설 검증과 안정 발행이 본질이고 캘린더는 도구입니다."
★ 줍줍의 +32h 갭 → 73일 (옵션 C) 와 정확히 같은 의사결정 프레임 — 1탄 v2 새 6장 6-4 (a) 절 두 도메인 사례 일관.
두 도메인 시간 갭 옵션 C 일관 패턴
| 도메인 | SPEC 보강 | 시간 갭 | 선택 옵션 | 근거 |
|---|---|---|---|---|
| 줍줍 (2탄) | 9건 | +32h | C (3일 연장 70→73일) | "본질은 심사·신뢰, 캘린더는 도구" |
| TSV (3탄) | 9건 | +21h | C (3일 연장 33→36일) | "본질은 가설 검증·안정 발행, 캘린더는 도구" |
같은 의사결정 프레임. 1탄 v2 부록 H-2 시간 갭 옵션 사례가 두 도메인에서 동일하게 작동함을 입증합니다.
(a) 시간 갭 정직 계산 — 옵션 C 채택 (위 6-2절)
이미 본문에 박혔습니다.
(b) 게이트 + 휴식의 의식 — G2 사례 (★ Day 14 CRITICAL)
[기능 통과 조건]
- [ ] 다관점 클릭률 측정 SQL + 어드민 분석 페이지
- [ ] persona_prompts 테이블 + versioning + 첫 prompt v1 적용
- [ ] cron 재개 catch-up 함수 + 7일 동안 cron 정지 0건
- [ ] Day 8~13 일 10글 자동 발행 + click_events 누적
[★ 가설 검증 결과 (PASS/W-C/FAIL)]
- [ ] 다관점 클릭률 > 25% = ✅ Phase 1.1 진행
- [ ] 15~25% = ⚠️ 페르소나 톤 강화 (Phase 1.0 +30일 추가)
- [ ] < 15% = 🚨 SPEC 재검토 (큰 변경 — 본질 재고)
[★ 운영자 페이스 점검 (E2)]
- [ ] 누적 시간 30h 초과 X (G2 시점 추정 누적 약 30h, 안전)
- [ ] 토요일 작업 X (G2 직전 1주에 토요일 1번 위반 시 다음 주 회복)
- [ ] 매주 일요일 30분 회고 + 다음 주 목표 1줄 (2주 모두 작성)
[★ 게이트 통과 의식 (E2)]
- [ ] git tag v0.1-G2-passed (가설 검증 결과 명시)
- [ ] 1일 휴식 (Day 15)
- [ ] 회고 1.5KB+ BUILD.md (가설 결과 + 다음 분기 결정 본문)
(c) R4 — 리스크 등록부의 "1인 번아웃" 일급 객체
[정의]
운영자 (Junho 1인) 의 신체적·정신적 한계로 인한 프로젝트 중단 위험. TSV는 12개월 운영 = 줍줍 (73일) 의 5배 기간 → R4 위험 극대화.
[완화책 — 5 의식]
- 게이트 통과 시 git tag + 1일 휴식 의무 (G1·G2·G3·G4·G5)
- 주차별 누적 시간 60h 초과 시 다음 주 1일 추가 휴식
- 토요일 작업 금지 (예외: 게이트 마감 임박 → 일요일 대체)
- 매주 일요일 30분 회고 (BUILD.md 명시 작성, 부재 = R4 신호)
- ⭐ 12개월 운영 추가: 매월 마지막 주 1일 추가 휴식 (장기 보호)
[트리거 — 다음 4가지 중 하나라도 발생 시]
- 누적 시간 60h+/4주
- 회고 부재 2주+ 누적
- 토요일 작업 4주 연속
- "피곤하다" 명시 표현 BUILD.md 회고에 등장
트리거 발생 시 즉시 1일 휴식 + 다음 주 목표 25% 축소 (자동).
[★ 12개월 운영 R4 강화]: 줍줍 (73일) R4 = 5 의식 / TSV (12개월) R4 = 5 의식 + 매월 1일 추가 휴식 (장기 보호). 12개월 = 줍줍의 5배 → R4 의식 1개 추가.
/model claude-sonnet-4-6
/effort high
PLAN.md를 v2.1로 패치해줘:
1. 일정: Day 1~33 → Day 1~36 (3일 연장)
2. 가용: 132h → 144h (1일 평균 4.36h)
3. § 시간 갭 흡수 — 옵션 C 채택 + 산식 + 채택 근거 본문 명시
4. 게이트 G1~G5 모두 +α 작업 일자별 분배:
- G1 (Day 7): G-2 (DB migration +2h) + G-4 (schema fallback +2h)
- G2 (Day 14): C-1 (Day 14 측정 +4h) + G-1 (persona_prompts +3h) +
G-3 (cron 재개 +2h) = +9h
- G3 (Day 21): C-2 (광고 차단 키워드 +2h) + C-3 (톤 분리 +3h) +
C-4 (댓글 정적 +1h) = +6h
- G4 (Day 28): C-3 보강 + C-5 (시간 측정 +2h) = 일부
- G5 (Day 36): 종합 점검
5. ⭐ 게이트 통과 조건에 운영자 페이스 점검 항목 추가 (E2)
6. R4 (1인 번아웃) 리스크 본문 보강
git add PLAN.md
git commit -m "PLAN v2.1: 36일 (옵션 C) + 5게이트 + 12리스크 + ⭐ E2 3형태 + ★ Day 14 CRITICAL"
Phase 0 Day 5
[계획] PLAN v1 작성 (Opus + high) + 시간 산식 점검
[실행]
- 33일 일정 + 5게이트 + 12리스크 + ★ Day 14 CRITICAL 본문 명시
- 시간 갭 +21h 발견 (SPEC v4의 9건 보강 영향)
- 옵션 A·B·C 비교 → 옵션 C 채택 (3일 연장, 1일 4.36h)
[LogOnTable 트레이스]
- 결정: 옵션 C 채택 — Day 1~33 → Day 1~36 (3일 연장)
- 근거: "Phase 1.0의 본질은 가설 검증 + 안정 발행, 33일 캘린더는 도구"
- 대안 A: 부가 기능 축소 (-12h, SPEC v4 9건 보강 약화) / 대안 B: Day 14 게이트 단순화 (-8h, 가설 검증 본질 약화)
- 부작용: 일 10글 발행 시작 3일 지연
[누적 시간] 9.5h + Day 5 (4h) = 13.5h
Phase 0 Day 6
[계획] PLAN v1 → v2.1 패치 + 12 리스크 본문 보강
[실행]
- /model claude-sonnet-4-6 + /effort high
- 5 게이트 모두 +α 작업 분배 (G2 +9h / G3 +6h 등)
- R4 본문 5 의식 + 4 트리거 명시 + 12개월 강화 1 의식 추가
- E2 3형태 모두 PLAN.md 본문에 박음
[누적 시간] 13.5h + Day 6 (3h) = 16.5h
[회고 1줄] E2의 3 형태가 등장. "운영자 자체"가 R1~R12 안에 일급 객체 + 12개월 운영 R4 강화. 12개월 후 동업자가 "왜 R4가 5 의식?"이라고 펼치면 답이 본문에 있습니다.
- 1️⃣ 5확장 점검: E1·E3·E4 ✅ / E2·E5 ⏳ 권1 제6~7장에서 완성
- 2️⃣ 두 도메인 일관 패턴 4 자리: 권1 제0·1·2·4장 — 줍줍·TSV 완벽 일치
- 3️⃣ PLAN v2.1: 36일 (옵션 C) + 5 게이트 + 12 리스크 + ⭐ E2 3 형태
- 4️⃣ 시간 갭 옵션 C: +21h 갭 → 33일 → 36일 (줍줍 +32h → 73일과 같은 의사결정 프레임)
- 5️⃣ R4 일급 객체: 5 의식 + 4 트리거 + 12개월 강화 1 의식 추가
- 6️⃣ 누적 시간: 16.5h / R4 트리거 60h 여유 43.5h
- 7️⃣ 다음 장: 권1 제7장 — REVIEW READY + CLAUDE.md 10 섹션 + ⭐ E5 콘텐츠 SSOT
PLAN v2.1 = 36일 (옵션 C) + 5 게이트 + 12 리스크 + ⭐ E2 3 형태 + ★ Day 14 CRITICAL.
E2 (1인 12개월 페이스) 가 등장했습니다. 시간 갭 옵션 C·게이트 통과 페이스 점검·R4 1인 번아웃 일급 객체 + ★ Day 14 CRITICAL 게이트. 운영자 자체가 PLAN.md의 본문에 박혔고, 12개월 운영을 위해 R4 의식 1개가 추가됐습니다.
★ 두 도메인 시간 갭 옵션 C 일관 — 줍줍 (+32h → 73일) + TSV (+21h → 36일) 같은 의사결정 프레임. 메타 원칙이 도메인 가리지 않고 작동합니다.