📑 이 챕터에서 다룰 내용
권1 제6장에서 PLAN v2.1이 완성됐고 ⭐ E2가 본격 등장했습니다. 이제 권1 (Phase 0) 의 마지막 챕터입니다. 이 한 챕터에서 세 가지가 동시에 일어납니다:
15가지 체크 + 3단계 판정 + 75분 WITH-CONDITIONS 패치
200줄 이하의 프로젝트 헌법
Two-Tab 7 규칙 + 삼중 안전장치
5파일+ 체계 완전 가동 + 5확장 5개 모두 본격 등장 + Phase 1.0 BUILD 시작 준비 완료.
| 사전 지식 체크 | 이 장의 목적 | 완료 후 결과물 |
|---|---|---|
| SPEC v4 + PLAN v2.1 / 1탄 v2 새 8·11장 + 부록 H-3·H-5 인지 | REVIEW 15가지 + 3단계 판정 + 75분 패치 + READY: YES + CLAUDE.md 10 섹션 + ⭐ E5 Two-Tab 7 규칙 본격 | REVIEW.md (READY: YES) + CLAUDE.md (10 섹션 200줄) + git commit + Phase 1.0 BUILD 진입 준비 |
/model claude-opus-4-6 /effort high SPEC.md v4 + PLAN.md v2.1을 읽고 REVIEW.md를 작성해줘. 1탄 v2 새 8장 8-1 절의 15가지 항목을 각각 PASS / WITH-CONDITIONS / FAIL 로 판정 + 이유 명시. 판정 기준: - PASS — 명확 통과 - WITH-CONDITIONS — 부분 + 조건 만족 시 PASS 전환 - FAIL — SPEC 또는 PLAN 수정 필요 종합 판정: - FAIL 0건 + WITH-CONDITIONS ≤ 3건 → READY: YES - 그 외 → READY: NO
Claude (Opus) 가 생성한 REVIEW.md 1차 결과
[기본 10가지]
- 1. ⭕ Phase 1 수익화: PASS — 의도적 무수익 + 변호 논리 명시 + Phase 2 시점 명시
- 2. ⭕ Phase 1 배포 가능: PASS — G5 Day 73 심사 제출
- 3. ⭕ DB RLS 설정: PASS — Supabase RLS 명시
- 4. ⭕ API 키 노출 방지: PASS — Edge Function만 (Stripe·Anthropic·카카오)
- 5. ⭕ 기술 스택 일관: PASS — Expo + Supabase + 단일
- 6. ⚠️ N+1 쿼리: WITH-CONDITIONS — benefits + jupjups JOIN 시 cumulative 카운트 N+1 가능성. 복합 인덱스 추가 시 PASS 전환.
- 7. ⭕ Phase 1 변경 파일 10개 이하: PASS — Phase 1.0 (Day 1~28) 약 12개, Phase 1.1 (Day 29~73) 약 13개로 분리 명시
- 8. ⭕ 외부 연동 위치 명확: PASS — pg_cron + Edge Functions
- 9. ⚠️ 에러 처리: WITH-CONDITIONS — Sentry 통합 명시 부재. PLAN G4 (Day 56) 에 Sentry 통합 추가 시 PASS 전환.
- 10. ⭕ 환경변수 분리: PASS — .env.local·EAS Secrets·Supabase Secrets
[1탄 v2 추가 5가지]
- 11. ⭕ 게이트 측정 가능: PASS — 5게이트 모두 숫자 DoD
- 12. ⭕ 리스크 등록부 R1~R12: PASS — 영향·확률·완화·트리거 모두
- 13. ⭕ R4 (1인 번아웃) 일급 객체: PASS — 4 의식 + 4 트리거
- 14. ⭕ SPEC v4 두 검토자: PASS — 권1 제4장 12건 (Claude 시뮬 + Gemini)
- 15. ⚠️ 12건 모두 반영: WITH-CONDITIONS — 9건 SPEC v4 즉시 + 3건 PLAN으로 미룸. PLAN G2·Day 8·G5 모두 명시 시 PASS 전환.
PASS 12건 + WITH-CONDITIONS 3건 + FAIL 0건
WITH-CONDITIONS 한도 = 3건 → 정확히 한도 내. READY: YES (조건부).
조건 75분 패치 후 PASS 전환 가능:
- P1 (15분): 복합 인덱스 (Day 8 작업 추가)
- P2 (5분): Sentry 통합 G4 (Day 56) 명시
- P3 (55분): G-3 + Redis IP rate limit + Apple Privacy Manifest 자동 검증 — PLAN G2·G5에 작업 추가
3건 모두 "BUILD 후 발견 시 50시간 재작업"이 됐을 결함입니다:
- N+1 쿼리 (DB 성능 사고 가능성)
- 에러 처리 누락 (운영 사고 시 대응 못함)
- 12건 일부 미반영 (SPEC↔PLAN 정합성)
REVIEW가 75분 패치로 막은 것 = 결함 비용의 법칙 (배리 봄, 1976) 의 100배 절감. REVIEW의 본질 가치 = 이 75분.
1탄 v2 새 8장 8-4 절의 "PASS 12 + W-C 3" 패턴과 일치. TSV (PASS 12 + W-C 3) 와 줍줍 (PASS 12 + W-C 3) — 두 도메인에서 같은 패턴 데이터 입증.
# P1 — 복합 인덱스 (15분) [Claude Code] PLAN.md Day 8에 작업 추가: "benefits 복합 인덱스 (deadline, is_active) + jupjups (user_id, benefit_id) — 15분" # P2 — Sentry 통합 (5분) PLAN.md G4 (Day 56) 통과 조건에 추가: "[ ] Sentry SDK 통합 + 첫 에러 자동 수집 확인 + 7일 무장애 관측" # P3 — 12건 PLAN 명시 (55분) PLAN.md G2 (Day 28) 통과 조건에 추가: "[ ] is_active 트리거 SQL 정상 (UPDATE benefits SET is_active = false WHERE deadline < NOW(), 매일 새벽 cron)" PLAN.md Day 8 작업에 추가: "IP rate limit Redis 함수 + INSERT trigger jupjups 1h 5+ reject" PLAN.md G5 (Day 73) 통과 조건에 추가: "[ ] EAS Build pre-build hook + xcrun privacy_manifest_check 통과" # 모든 패치 완료 후 git commit git add PLAN.md git commit -m "PLAN v2.2: 75분 W-C 패치 (P1 인덱스 + P2 Sentry + P3 PLAN 3 명시)"
| 항목 | 1차 → 2차 |
|---|---|
| 6. N+1 쿼리 | W-C → PASS (복합 인덱스 명시) |
| 9. 에러 처리 | W-C → PASS (Sentry G4 명시) |
| 15. 12건 모두 반영 | W-C → PASS (G2·Day 8·G5 모두 명시) |
| 그 외 | 변동 없음 |
종합 판정 (2차): PASS 14건 + WITH-CONDITIONS 1건 + FAIL 0건
남은 W-C 1건: "Sentry 통합 후 첫 7일 무장애 관측" — BUILD 진행 중 자연 해결됩니다. READY 진입을 막지 않습니다.
FAIL 0건 + W-C 1건 ≤ 3건 → READY: YES
5파일 상태:
- SPEC.md v4 (16KB) ✅
- PLAN.md v2.2 (16KB) ✅
- REVIEW.md (READY: YES) ✅
- BUILD.md (Day -1~6 entry) ✅
- CLAUDE.md (3 섹션 → 10 섹션 완성 예정, 본 장 7-5 절)
git add REVIEW.md SPEC.md PLAN.md git commit -m "REVIEW.md: READY YES (PASS 14 + W-C 1) + 75분 패치 적용"
/model claude-opus-4-6 /effort high SPEC.md v4 + PLAN.md v2.2 + BUILD.md 6 entry를 읽고 CLAUDE.md를 10 섹션으로 완성해줘. 1탄 v2 새 11장 11-2 절 템플릿 따름. 특히 §5 Project-Specific Rules에는: - ⚖️ E1 회색지대 결정 한 줄 요약 (두 결정) - ⭐ E5 Two-Tab Content SSOT 7 규칙 (1탄 v2 새 11장 11-4·부록 H-5) - E4 LogOnTable 패턴 명시 200줄 이하 유지.
Claude (Opus) 가 생성한 CLAUDE.md — 핵심 섹션 발췌
# 줍줍 (Jupjup) # 기술 스택: Expo 52 + Supabase + Stripe (Phase 2) # 상태: Phase 0 Day 7 완성 / 누적 18.5h / 다음 게이트 G1 D-7 ## 1. Project Overview - 앱 정의: 정부 지원금 정보 + 후기 공유 B2C 앱 - 사용자 A: 자영업자 (소상공인 탭) - 사용자 B: 일반 시민 (개인 복지 탭) - 핵심 가치: ⚖️ "정보 격차를 줄임, 신청 결과 보장 X" (E1) ## 2. Tech Stack - 프론트: Expo 52 + TypeScript + NativeWind + Zustand + TanStack Query - 백엔드: Supabase (PostgreSQL + Auth + Edge Functions + Storage + pg_cron) - LLM: Claude Haiku 4.5 (분류) + Sonnet 4.6 (운영) - 외부 API: 기업마당, 중소벤처24, 복지로 중앙·지자체 (4개) - 인증: 카카오 로그인 (단일) - 알림: FCM - 결제: Stripe (Phase 2) - 배포: EAS Build (iOS·Android) ## 3. Critical Constraints (어떤 상황에서도 지킨다) - StyleSheet 사용 금지 → NativeWind(Tailwind)만 - API 비밀 키 프론트엔드·.env.local 직접 노출 X - 요청하지 않은 기능 임의 추가 X - 요청하지 않은 파일 무단 수정 X - 작업 전 변경할 파일 목록을 먼저 말한다 - ⚖️ E1 회색지대 결정 위반 X: · "신청 결과 보장 / 대행" 표현 X · IDFA·디바이스 식별자·위치 정보 수집 X · 개인 식별 가능 정보 제3자 제공 X
§5 — Two-Tab Content SSOT 7 규칙 (E5 핵심)
원칙: 같은 "지원금 정보"를 두 탭이 다른 톤으로 노출하되, 사실 자체는 단일 출처 (DB의 benefits 테이블) 에서 받습니다.
- 사실 단일 출처: benefits 테이블의 모든 사실 (마감일·금액·자격 요건) 은 두 탭이 동일하게 표시. 변형 X.
- 톤 분리: 🏪 소상공인 탭 "사장님 톤" / 👤 개인 복지 탭 "시민 톤". summary와 key_requirements 텍스트가 톤에 따라 다를 수 있으나, 사실은 동일.
- 닉네임 자동 부여 페르소나 풀 분리: 소상공인 "[시군구] + [업종] + 운영하는 + [형용사] + 줍줍이" / 개인 "[시군구] + [상황] + [형용사] + 줍줍이". 형용사 풀 20개+ (든든한·열정·꼼꼼한·현명한…). 충돌 시 fallback: 다른 형용사 → 숫자 suffix.
- LLM 분류 프롬프트 분리: 소상공인용 target_business_type / 개인 복지용 target_age_min/max. confidence 0.7 미만 필드는 NULL + source_url 보완. JSON parse 실패: confidence 0 + raw_response 보존 + admin 큐.
- ⚖️ E1 회색지대 일관 노출 (외부 노출 4자리): About + 약관 + 개인정보처리방침 + Footer 모두에 "신청 결과 보장 X" + "광고 추적 식별자 미수집" 명시.
- 자동 일관성 테스트:
tests/two-tab-consistency.test.ts— 같은 benefit_id에 대해 두 탭 노출 시 사실 일치 자동 검증. fail 시 cron/sync.ts 자동 정지. - 환각 방지 명세: LLM 분류 프롬프트에 "JSON 외 출력 X" + "추정 X, 누락 null 처리" 명시. 페르소나가 입력에 없는 정보를 만들지 않습니다.
git add CLAUDE.md git commit -m "CLAUDE.md 10 섹션 완성: ⚖️ E1 + ⭐ E5 Two-Tab 7 규칙"
CLAUDE.md §5에 박힌 Two-Tab Content SSOT 7 규칙이 5확장 E5의 본격 등장 자리입니다. 1탄 v2 새 11장 11-4 절 + 부록 H-5의 줍줍 사례가 본문에 직접 박혔습니다.
줍줍 E5의 삼중 안전장치 (1탄 v2 부록 H-5 일치)
| 안전장치 | 구체 |
|---|---|
| ① SSOT 인터페이스 | benefits 테이블 (DB 단일 출처). 두 탭 모두 같은 row 참조. |
| ② 시스템 프롬프트 환각 방지 | LLM 분류 프롬프트: "JSON 외 출력 X, 추정 X, 누락 null" 명시 |
| ③ 자동 일관성 테스트 | tests/two-tab-consistency.test.ts — 같은 benefit_id 두 탭 노출 시 사실 일치 검증 |
환각 방지의 본질
| 잘못된 시나리오 | E5 환각 방지 시나리오 |
|---|---|
| API 응답에 "지원 금액 미정" ↓ LLM이 "일반적으로 1,000만원" 추정 출력 ↓ 사용자에게 잘못된 사실 노출 → 신뢰 붕괴 | API 응답에 "지원 금액 미정" ↓ LLM 프롬프트: "JSON 외 X, 추정 X, 누락 null" ↓ LLM 출력: support_amount null, confidence 0.3 ↓ confidence < 0.7 → NULL + admin 큐 ↓ 사용자: "정보 부족 (원문 링크)" 노출 → 신뢰 보존 |
이게 9개 표준 도구가 다루지 않는 "콘텐츠 사실 환각" 영역입니다. 5확장 E5의 본질이에요.
Agent Teams (1탄 v2 새 23장) 와의 자연 결합 예고
E5 적용 프로젝트는 Agent Teams 적합도 가장 높습니다 (1탄 v2 새 23장 23-5 절). 권2 BUILD 단계에서 줍줍 두 탭은 Agent Teams로 분배됩니다.
/delegate Phase 1 두 탭 UI를 동시에 개발해줘:
에이전트 A (담당 폴더: src/app/(tabs)/business/):
- 소상공인 탭 메인 + 사업단계 필터
- "사장님 톤" 닉네임 페르소나 풀 적용
에이전트 B (담당 폴더: src/app/(tabs)/individual/):
- 개인 복지 탭 메인 + 가구 형태 필터
- "시민 톤" 닉네임 페르소나 풀 적용
CLAUDE.md §5 Two-Tab Content SSOT 7 규칙 준수 필수.
완료 후 자동 일관성 테스트 (E5 ③) 실행.
5파일 점검 (1탄 v2 새 11장 11-5 절 표 적용)
| 파일 | 분량 | 상태 | E1~E5 |
|---|---|---|---|
| SPEC.md | 16KB | ✅ v4 | E1 두 결정 + 측정 메트릭 |
| PLAN.md | 16KB | ✅ v2.2 | E2 3 형태 + R4 일급 |
| REVIEW.md | 5KB | ✅ READY: YES | E3 12건 4+6+2 (1·2차) |
| BUILD.md | 6KB | ✅ Day -1~7 entry | E4 7 트레이스 |
| CLAUDE.md | 7KB (200줄) | ✅ 10 섹션 | E5 Two-Tab 7 규칙 |
| 합계 | 50KB |
5확장 점검 — 5/5 본격 ✅
| 확장 | 본격 등장 챕터 | 핵심 데이터 |
|---|---|---|
| ⚖️ E1 회색지대 | 권1 제3장 | 두 결정 (4단계 풀) + 외부 노출 4자리 |
| ★ E2 1인 페이스 | 권1 제6장 | 옵션 C (3일 연장) + 4 의식 + 4 트리거 |
| ⭐ E3 두 검토자 | 권1 제2·4장 | 12건 4+6+2 패턴 (TSV·줍줍 일관) |
| ⭐ E4 LogOnTable | 권1 제0~7장 매 entry | 7 트레이스 (Day -1~7) |
| ⭐ E5 콘텐츠 SSOT | 권1 제7장 (본 장) | Two-Tab 7 규칙 + 삼중 안전장치 |
Phase 1.0 BUILD 진입 점검 — /clear 검증
/clear SPEC.md, PLAN.md, REVIEW.md, BUILD.md, CLAUDE.md를 읽고 현재 프로젝트 상황을 요약해줘. 그리고 5확장 5개 (E1~E5) 가 각 파일에 어디에 박혔는지 1줄씩 답해줘. # Claude의 즉시 답: "줍줍 (B2C 정부 지원금 정보 앱) Phase 0 완성. Phase 1.0 BUILD 시작 준비 완료. 5확장 위치: - E1 회색지대: SPEC § 회색지대 결정 (두 결정 — 줍줍 표현·개인정보) - E2 1인 페이스: PLAN § 시간 갭 옵션 C (73일) + 게이트 페이스 점검 + R4 - E3 두 검토자: REVIEW.md (1·2차) + SPEC v3→v4 진화 - E4 LogOnTable: BUILD.md Day -1~7 매 entry 트레이스 - E5 콘텐츠 SSOT: CLAUDE.md §5 Two-Tab 7 규칙 다음 단계: PLAN G1 (Day 7) → 공공데이터 API 4개 인증 + 시딩 20개"
누적 시간 점검 — E2 R4 트리거
| Day | 작업 | 시간 |
|---|---|---|
| Day -1 | 이름 결정 + 5파일 빈 껍데기 | 0.5h |
| Day 1 | SPEC v1 | 1.5h |
| Day 2 | Gemini 1차 + SPEC v2 | 2h |
| Day 3 | E1 4단계 + SPEC v3 | 3h |
| Day 4 | 두 검토자 + SPEC v4 | 2.5h |
| Day 5 | PLAN v1 + 시간 갭 | 4h |
| Day 6 | PLAN v2.1 + R4 본격 | 3h |
| Day 7 | REVIEW + 75분 패치 + CLAUDE.md 10섹션 + E5 본격 | 4.5h |
| 권1 (Phase 0) 누적 | 21h |
21h 투자로 만들어진 것:
- SPEC v4 (16KB) — "무엇을 만들 것인가"의 헌법
- PLAN v2.2 (16KB) — "언제 어떻게"의 캘린더
- REVIEW (READY: YES) — BUILD 진입 준비
- BUILD.md (Day -1~7 LogOnTable 7 트레이스)
- CLAUDE.md (10 섹션 200줄 + E5 Two-Tab 7 규칙)
21h가 Phase 1.0 BUILD 70일의 50시간 재작업을 막은 자리 (배리 봄 결함 비용의 법칙).
R4 트리거 60h/4주 여유: 39h 여유. Phase 0 완전 안전 영역.
## Phase 0 Day 7 (권1 마지막)
[계획]
- REVIEW + 75분 패치 + CLAUDE.md 10 섹션 + ⭐ E5 본격
[실행]
- REVIEW 1차: PASS 12 + W-C 3 → 75분 P1·P2·P3 패치 → 2차 PASS 14 + W-C 1
- READY: YES 받음 (FAIL 0 + W-C 1 ≤ 3)
- CLAUDE.md 10 섹션 200줄 완성 — Two-Tab 7 규칙 본격
- /clear 검증: 5파일 + 5확장 위치 즉시 답 ✅
[LogOnTable 트레이스]
> 결정: ⭐ E5 Two-Tab Content SSOT 7 규칙 — CLAUDE.md §5에 본격 박음
> 근거: 줍줍의 두 탭이 같은 사실을 다른 톤으로 노출하는 본질 = E5 적용
대상 (1탄 v2 부록 H-5 매트릭스 일치)
> 대안: SSOT 없이 두 LLM 프롬프트 독립 — "사실 일치" 보장 안됨
> 부작용: tests/two-tab-consistency.test.ts 자동 테스트 5 케이스 추가 의무
(Day 8 작업 +1h 추가)
[권1 (Phase 0) 누적] 21h — R4 60h 트리거 39h 여유
[권1 회고]
- 5확장 5개 모두 본격 등장 완료 ✅
- 5파일+ 체계 완전 가동 ✅
- 1탄 v2의 모든 메타 원칙이 줍줍 사례에서 데이터로 입증됨:
· 의도적 불완전 v1 (1탄 v2 새 5장)
· 정직한 분류 (4 즉시 + 2 미룸)
· 12건 4+6+2 패턴 (TSV와 일관)
· 옵션 C 채택 ("본질 vs 캘린더")
· WITH-CONDITIONS = 그물 작동 (75분 패치)
· E5 삼중 안전장치 (SSOT + 환각 방지 + 자동 테스트)
- 다음 권 (권2 Phase 1.0 BUILD) 진입 준비 완료
git add BUILD.md git commit -m "권1 (Phase 0) 완성: 5파일+ 5확장 5/5 본격 + READY YES" git tag v0.1-phase0-completed
- 핵심: 권1 (Phase 0) 완전 마무리 — REVIEW READY: YES + CLAUDE.md 10 섹션 + ⭐ E5 본격 + 5확장 5/5 ✅
- 75분 WITH-CONDITIONS 패치 (TSV 패턴 일관): 1차 PASS 12 + W-C 3 → P1(15분)·P2(5분)·P3(55분) → 2차 PASS 14 + W-C 1. "REVIEW 75분 vs BUILD 50h" = 40배 절감
- ⭐ E5 Two-Tab 7 규칙: ① 사실 단일 출처 ② 톤 분리 ③ 닉네임 페르소나 풀 분리 ④ LLM 분류 프롬프트 분리 ⑤ E1 일관 노출 4자리 ⑥ 자동 일관성 테스트 ⑦ 환각 방지 명세
- 삼중 안전장치: ① SSOT 인터페이스 / ② 환각 방지 / ③ 자동 테스트
- 권1 (Phase 0) 누적: 21h / R4 트리거 39h 여유
- 5확장 5/5 본격 ✅: E1(제3장) / E2(제6장) / E3(제2·4장) / E4(제0~7장) / E5(제7장)
- 권1 마무리 git tag:
v0.1-phase0-completed - 다음 권: 권2 — Phase 1.0 BUILD (Day 1~28). G1 (Day 7) API 4개 + 시딩 20개부터
권1 (Phase 0) 가 완전히 마무리됐습니다. 5파일+ 체계가 가동되고, 5확장 5개가 모두 본격 등장했고, READY: YES를 받았습니다.
21시간의 투자로 만들어진 자산:
- ⚖️ E1 두 회색지대 결정 (외부 노출 4자리 일관 준비)
- ★ E2 옵션 C (73일) + R4 일급 객체
- ⭐ E3 두 검토자 12건 (4+6+2 패턴 데이터 입증)
- ⭐ E4 7 LogOnTable 트레이스
- ⭐ E5 Two-Tab 7 규칙 (삼중 안전장치)
이게 Phase 1.0 BUILD 70일 (49 가용 영업일) 의 토대입니다. 권2에서 Phase 1.0 BUILD Day 1~28을 만나뵙겠습니다. G1 (Day 7) API 4개 인증부터 G2 (Day 28) DB·인증·pg_cron 완성까지 — 코드가 처음 만들어지는 자리입니다.