📑 이 챕터에서 다룰 내용
새 5장에서 SPEC.md v2 (Gemini 1차 검토 반영 + E1 회색지대 결정)를 완성했습니다. 이제 그 SPEC을 캘린더에 올려놓는 자리입니다. PLAN.md는 "언제 · 어떤 순서로 · 얼마나"의 결정. SPEC이 "무엇"의 자리라면, PLAN은 "언제"의 자리입니다.
| 사전 지식 체크 | 이 장의 목적 | 완료 후 결과물 |
|---|---|---|
| 새 5장 SPEC.md v2 완성 + git commit | SPEC v3/v4 짧은 진화 후 PLAN.md v1 → v2 완성. Phase별 DoD 숫자 + E2 1인 12개월 페이스 본문에 박는다 | PLAN.md v2 (30일 · 10파일 기준 + 게이트 + 리스크 등록부 + E2 시간 갭·휴식·R4) |
XP (익스트림 프로그래밍)와 스크럼의 스프린트 개념: 큰 프로젝트를 2~4주 단위 작은 사이클로 나눠 각 사이클 끝에 동작하는 결과물. PLAN.md의 Phase가 이 개념을 구현합니다. "완성되면 배포"가 아니라 "배포 가능한 것만 Phase에 넣는다"가 원칙입니다.
PLAN.md는 앱 개발의 여행 계획서입니다. Phase 1~N까지 어떤 순서로, 어떤 기능을, 언제까지 만들 것인지 확정합니다. PLAN.md를 만드는 데 1시간이 걸려도, 그 1시간이 나중의 1개월 재작업을 막습니다.
PLAN.md 작성에 들어가기 전에 SPEC을 한 번 더 다듬는 단계가 있습니다. 새 4장 7단계 사이클의 단계 ④ (사용자 직관) + 단계 ⑤ (두 검토자)입니다.
SPEC v2 (Gemini 1차 검토 반영)는 "외부 검토자가 본 SPEC". 그러나 외부 검토자에게 없는 두 가지:
- 사용자의 시장 직관 — "이 사용자 유형이 정말 베팅을 안 할까?" — 사용자만 갖고 있음
- 두 번째 라운드 검토 — v2 → v3에서 새 결정이 추가됐고, 그 새 결정에 또 다른 약점이 있을 수 있음
단계 ④ — 사용자 직관 점검 (30분~1시간)
| 프로젝트 | 사용자 직관 발견 |
|---|---|
| 줍줍 | 후기 받기의 "부담 0 → 부담 낮음 → 선택" 단계적 기여 시스템 필요 |
| 줍줍 | 1순위 커뮤니티 = "아프니까 사장이다" 카페 (마케팅 채널 결정) |
| 줍줍 | 개인 복지 탭의 "수천 건 데이터 과다" — 인구통계 사전 필터 필수 |
| TSV | 운영자 패널에 페르소나 즉시 정지 도구 필요 (변호 도구) |
| TSV | Day 14에 다중 페르소나 가설 검증 게이트 (CRITICAL) |
사용자가 자기 시장을 가장 잘 압니다. 외부 검토자가 아무리 뛰어나도 시장 직관은 사용자 본인의 것입니다.
단계 ⑤ — 두 검토자 (1.5시간)
SPEC v3에 대해:
- Claude 시뮬레이션 검토 — 5건
- 외부 Gemini 검토 — 7건
합계 12건. 패턴: Claude만 4 + Gemini만 6 + 둘 다 2. 5확장 E3의 데이터 입증 모습입니다. 자세한 트레이스는 새 8장 REVIEW에서.
# SPEC v3 → v4 진화 후 git add SPEC.md git commit -m "SPEC.md v4: 사용자 직관 + 두 검토자 12건 반영"
이제 SPEC v4를 손에 들고 PLAN.md 작성에 들어갑니다.
/model claude-opus-4-6 # PLAN 설계도 Opus 사용 SPEC.md를 읽고 PLAN.md를 작성해줘. 아래 기준을 반드시 지켜줘: 1. 각 Phase는 30일 안에 혼자 완성 가능해야 한다 2. Phase 1에 수익화 경로가 반드시 포함돼야 한다 3. 각 Phase의 완료 기준 (DoD) 은 숫자로 명시해야 한다 4. 각 Phase에서 변경될 파일 수를 명시해야 한다 5. Phase 간 의존성을 표시해야 한다 6. 각 Phase 안에 게이트를 두어 측정 가능 통과 조건을 명시해야 한다 7. 리스크 등록부를 포함해야 한다 (영향·확률·완화책·트리거) 총 Phase 수는 3~5개가 적당하다.
v1.0 대비 추가된 6번 (게이트) + 7번 (리스크 등록부)이 E2 페이스의 자리가 박히는 곳입니다.
cat PLAN.md # Phase 수 / DoD 숫자 / 수익화 / 게이트 / 리스크 등록부 모두 확인
| 검증 기준 | 통과 | 실패 → 조치 |
|---|---|---|
| 30일 테스트 | 혼자서 30일 안에 완성 가능한가? | Phase를 두 개로 분리 |
| 10파일 테스트 | 변경 파일이 10개 이하인가? | /clear 시 맥락 손실 위험 |
| 수익화 포함 | Phase 1에 돈 받는 기능 있는가? | Phase 1 재설계 |
| DoD 명확성 | 완료 기준이 숫자로 있는가? | "완성" 불명확 → 무한 확장 |
| 의존성 명시 | Phase 간 순서 명시? | 순서 충돌로 작업 막힘 |
| ★ 게이트 명시 | Phase 안에 측정 가능 게이트? | 진행 중 검증 불가 |
| ★ 리스크 등록부 | R1~RN에 영향·확률·완화·트리거? | 운영 사고 시 대응 부재 |
| ★ E2 1인 페이스 | 누적 시간이 "무너지지 않을 페이스"인가? | 번아웃 → 프로젝트 중단 |
마지막 ★ 항목 (E2)이 1탄 v2의 핵심 추가. 6-4절에서 등장합니다.
이 Phase 1이 30일 기준을 초과할 것 같아. 이것만으로 배포 가능한 최소 버전과 그 다음에 추가할 것으로 두 개로 나눠줘. 각 Phase의 변경 파일 수를 10개 이하로 유지해줘.
여기가 1탄 v2에서 PLAN.md에 추가된 자리입니다.
"이 사람이 6~12개월 동안 무너지지 않을 페이스인가"의 메타 결정. 9개 표준 도구는 작업 분해 (Taskmaster)와 의존성 (GSD wave)을 다루지만, 운영자 자체의 페이스 관리는 사용자 책임으로 떠넘깁니다.
5파일+의 PLAN.md는 이 영역을 본문에 박습니다. 세 가지 형태:
- (a) 시간 갭 정직 계산 — SPEC 변경의 시간 영향을 산식 + 옵션 A/B/C
- (b) 게이트 + 휴식의 의식 — 게이트 통과 조건에 운영자 페이스 점검 항목
- (c) 리스크 등록부의 R4 "1인 번아웃" — 운영자 자체 리스크를 일급 객체로
(a) 시간 갭 정직 계산 — TSV의 +29h 사례
PLAN v1을 작성한 후, SPEC 변경의 시간 영향을 산식으로 계산합니다.
## 시간 갭 흡수 옵션 — Phase 1.0 (Day 1~30 → 33일) PLAN v1 → v2 변환 시 +29h 추가 작업 발생. [발생 원인 — SPEC v3/v4 변경의 시간 영향] - D-3 페르소나 3 → 2개 (Phase 1.0): -4h - D-2 SSOT 메커니즘 + 자동 테스트: +8h - D-1 SEO 키워드 분리: +2h - D-5 프론트엔드 그룹화 UI: +8h - D-4 운영자 패널 페르소나 정지: +2h - D-6 About + 댓글 인프라: +3h - D-12 Day 14 중간 게이트: +2h - D-7 분 단위 스케줄링: +4h - D-8 복합 인덱스: +1h - D-10 API 비용 공격 방어: +2h - D-9 Phase 1.0 실패 신호: +1h - 합계: +29h [가용 시간 점검] - Phase 1.0 PLAN v1 가용: 120h (30일 × 4h/일) - v2 기준 필요: 149h - → 1일 4h 평균이 1일 5h로 늘어나야 함 [흡수 방법 3가지 옵션] 옵션 A — 부가 기능 축소 (-16h) 제외: 그룹화 UI 일부 / 모니터링 일부 단점: SPEC v4 다중 페르소나 가치 약화 옵션 B — 모니터링 축소 (-8h) 제외: Sentry 깊이 통합 일부 단점: 운영 안전망 약화 옵션 C — 일정 3일 연장 (+12h 가용) ← 채택 Phase 1.0: Day 1~30 → Day 1~33 가용: 120h → 132h 부담: 1일 평균 4.5h (기존 4h 대비 +0.5h) 채택 근거: "Phase 1.0의 본질은 '5리그 × 2 페르소나 안정 가동 + 7일 무장애 입증'이지 30일이라는 캘린더가 아니다. 검증이 본질이고 캘린더는 도구다."
6개월 후 동업자가 "왜 33일이지, 30일이 아니라?" 펼쳤을 때 답이 본문에 있습니다. 대화가 아닌 문서에 결정을 박아두는 것 — 이게 5파일+의 본질입니다.
(b) 게이트 + 휴식의 의식 — 줍줍 사례
각 게이트 통과 조건에 "운영자 페이스 점검" 항목 포함합니다.
## G2 — 4주차 게이트 (DB · 인증 완성) [기능 통과 조건] [ ] users / benefits / jupjups / reports 4 테이블 생성 [ ] 집계 트리거 (jupjups 추가 시 benefits 자동 갱신) [ ] 카카오 로그인 + 닉네임 자동 부여 [ ] pg_cron API 호출 매일 03:00 정상 실행 [ ] 어드민 기초 페이지 (LLM 분류 검수용) [★ 운영자 페이스 점검] [ ] 3~4주차 누적 60h 초과 시 5주차 1일 휴식 의무 [ ] 토요일 작업 금지 (예외: 게이트 마감 임박 → 일요일로 대체) [ ] 매주 일요일 30분 회고 + 다음 주 목표 1줄 [★ 게이트 통과 의식] [ ] git tag v0.1-G2-passed [ ] 1일 휴식 (자기 자신과의 약속)
"운영자가 무너지기 전에 멈추는 트리거"가 PLAN의 일부가 됩니다. 프로젝트를 완성하려면 먼저 사람이 무너지지 않아야 합니다.
(c) R4 — 리스크 등록부의 "1인 번아웃"
리스크 등록부에 운영자 자체 리스크를 일급 객체로 포함합니다.
## 리스크 등록부 | # | 리스크 | 영향 | 확률 | 완화책 | 트리거 | |---|------|------|------|--------|--------| | R1 | API 응답 품질 저하 | 중 | 중 | confidence 0.7 미만 NULL 처리 | 1주 누적 fail >5% | | R2 | 정부 유사 서비스 출시 | 높 | 낮 | 커뮤니티+집단 경험 데이터 차별화 | 정부 발표 시 | | R3 | 애플 심사 거절 | 높 | 중 | IDFA 미수집 + 최소 정보 명시 | 심사 1차 거절 | | R4 | 1인 운영 번아웃 | 높 | 중 | 6주차+9주차 휴식 의무 / 토요일 작업 금지 / 주간 회고 | 누적 60h+/4주 또는 회고 부재 2주+ | | R5 | LLM 분류 오류 (신뢰도 추락) | 중 | 중 | 어드민 검수 + 사용자 신고 | 신고 >5건/주 | | R6 | 통계 조작 시도 | 중 | 낮 | UNIQUE 제약 + 1시간 IP 제한 | 한 IP 5회+/시간 |
이 사람이 무너지면 R1~R10 모두 의미 없다는 인식이 5파일+의 본질입니다. 리스크 등록부에 운영자 자체 리스크를 일급 객체로 포함하세요.
줍줍 PLAN.md (요약 발췌)
# PLAN.md — 줍줍 (Jupjup) # 최종 업데이트: SPEC.md v4 기반 ## Phase 1: MVP — 정보 수집 + 기여 시스템 + 무료 사용 기간: 10주 / 변경 파일: 약 25개 가용: 280h (10주 × 28h/주) 기능: - 공공데이터 API 4개 인증 + 연동 (1~2주차) - LLM 분류 파이프라인 + 시딩 20개 (1~2주차) - DB 테이블 4개 + 트리거 + 카카오 로그인 (3~4주차) - 탭별 목록/상세 + 단계적 기여 시스템 (5~6주차) - 통계 시각화 + FCM 알림 (7~8주차) - 약관/방침 + 어드민 + QA (9주차) - 앱스토어 심사 + 커뮤니티 홍보 (10주차) 게이트 5개: G1 — 1주차: API 4개 인증키 + 시딩 20개 G2 — 4주차: DB + 인증 + pg_cron + ★페이스 점검 G3 — 6주차: 탭별 UI + 기여 시스템 (사용자 1명 줍줍 가능) G4 — 8주차: 통계 + 알림 + 공유 카드 G5 — 10주차: 심사 제출 + 첫 사용자 10명 DoD: 앱스토어 심사 통과 + 첫 100 사용자 + 1순위 커뮤니티 게시 의존성: 없음 (첫 Phase) ## Phase 2: 수익화 — 프리미엄 구독 기간: 3개월 (Phase 1 출시 6개월 후 시작) DoD: MAU 5,000 + 유료 구독자 250명 (월 수익 725,000원) 의존성: Phase 1 완성 + 6개월 무수익 신뢰 축적 ## 리스크 등록부 R1~R12 (R4 = 1인 번아웃 일급 객체) ## 1인 페이스 의식 (E2) - 게이트당 git tag + 1일 휴식 - 누적 60h/4주 초과 시 1일 휴식 의무 - 토요일 작업 금지 - 주간 일요일 30분 회고
TSV PLAN.md v2.1 (요약 발췌)
# PLAN.md — TotalSportsView v2.1 # 최종 업데이트: SPEC.md v4 + 시간 갭 옵션 C 채택 ## Phase 1.0: MVP — 5리그 × 2 페르소나 기간: 33일 (Day 1~33, 옵션 C 채택) 변경 파일: 약 30개 가용: 132h (1일 4.5h 평균) 게이트 5개: G1 — Day 1: legal/about/cookie 200 OK + WAF 활성 G2 — Day 10: SSOT 자동 테스트 5/5 통과 G3 — Day 14 ★ CRITICAL: 다관점 클릭률 ≥15% + 일관성 100% + 24h 무인 G4 — Day 18: 30초 내 전체 정지 + 5초 내 글 비공개 + ★페르소나 정지 G5 — Day 33 ★ FINAL: 7일 무장애 + $18 이하 운영비 + 30분 평균 개입 [Day별 일정 — 발췌] Day 1~3: 인프라 + Position C About 외부 노출 Day 4~7: 데이터 수집 + DB 스키마 Day 8~10: SSOT 메커니즘 + 페르소나 + 자동 테스트 Day 11~14: 다관점 가설 검증 (CRITICAL 게이트) Day 15~18: 운영 도구 (페르소나 정지 + Sentry) ... Day 31~33: 회고 + Phase 1.1 PLAN 초안 ## 시간 갭 흡수 옵션 — 옵션 C 채택 (6-4 (a)절 참조) ## 리스크 등록부 R1~R14 R4 = 1인 운영 번아웃 (영향 높음 / 확률 중) ## 외부 의존성 매트릭스 TheSportsDB · API-Sports · Cloudflare · Vultr · Anthropic API 각각 SLA + 자동 재시도 + 대체 정책 ## 1인 페이스 의식 (E2) - 게이트 통과 시 git tag + 1일 휴식 - Day 14 CRITICAL 통과 후 2일 휴식 (다관점 가설 검증 부담) - 토요일 오후 자유 시간 의무 - 주간 회고 + 다음 주 목표
PLAN.md는 한 번 쓰고 끝이 아닙니다. Phase 1을 완성하고 사용자 피드백을 반영해 Phase 2가 바뀔 수 있습니다. 이건 정상입니다.
변경 시 반드시 Claude Code에서 PLAN.md를 직접 수정하고 git commit. 대화로만 방향을 바꾸면 나중에 무엇이 원래 계획이었는지 알 수 없게 됩니다.
# 검증 완료 후 git add PLAN.md git commit -m "PLAN.md v2.1: Phase 확정 + 게이트 + 리스크 + E2 페이스" # 현재 5파일 상태 확인 cat SPEC.md | head -5 # ← 완성 (v4) cat PLAN.md | head -5 # ← 완성 (v2.1) cat REVIEW.md # ← 아직 비어있음 (새 8장) cat BUILD.md # ← 아직 비어있음 (새 9장) cat CLAUDE.md # ← 기본만 (새 11장)
- 1️⃣ PLAN.md = SPEC v4를 캘린더에: 게이트 + 리스크 등록부 + E2 1인 12개월 페이스
- 2️⃣ PLAN 작성 전 짧은 진화: SPEC v2 → 단계 ④ 사용자 직관 → SPEC v3 → 단계 ⑤ 두 검토자 (12건 패턴) → SPEC v4
- 3️⃣ 검증 8가지: 30일 / 10파일 / 수익화 / DoD / 의존성 + ★게이트 / ★리스크 / ★E2 페이스
- 4️⃣ E2 세 형태: (a) 시간 갭 정직 계산 (TSV +29h) / (b) 게이트 + 휴식 의식 / (c) R4 1인 번아웃 등록
- 5️⃣ 두 사례: 줍줍 (10주·5게이트·12리스크) / TSV (33일·5게이트·14리스크·R4 + +29h 갭)
PLAN.md는 "언제·어떤 순서로" + "운영자가 무너지지 않을 페이스"가 한 파일에 박힌 로드맵입니다.
R4 (1인 번아웃)는 기능 리스크와 동등한 일급 객체입니다 — 사람이 먼저 버텨야 프로젝트도 삽니다.