5확장 (E1~E5) 분리 정리
새 프로젝트 시작 시 빠르게 펼치는 Reference
📑 이 부록에서 다룰 내용
이 부록의 목적은 5확장 5개를 한 자리에서 깊이 정리하는 것입니다. 본문 챕터에 흩어진 내용을 "확장별로 모은 reference"로 만들어 새 프로젝트 시작 시 빠른 펼침이 가능하게 합니다.
- 새 프로젝트 시작 시 SPEC.md 작성 직전에 H-1 (E1) 펼침
- PLAN.md 작성 시 H-2 (E2) 펼침
- REVIEW.md 작성 시 H-3 (E3) 펼침
- BUILD 진행 시 H-4 (E4) 펼침
- CLAUDE.md 작성 시 H-5 (E5) 펼침
| 코드 | 명칭 | 본문 위치 | 핵심 메시지 |
|---|---|---|---|
| E1 | 회색지대 결정 | SPEC.md § 회색지대 결정 | 법적·윤리적·시장적 회색지대를 SPEC에 명세적으로 결정 |
| E2 | 1인 12개월 페이스 | PLAN.md (시간 갭·게이트 휴식·R4) | 운영자가 무너지지 않을 페이스를 본문에 박음 |
| E3 | 두 검토자 사각지대 | REVIEW.md + SPEC 진화 단계 | 한 검토자에 의존 금지, 두 모델 사각지대 차이 활용 |
| E4 | LogOnTable 실황 | BUILD.md 일자별 트레이스 | 결정 결과가 아니라 "왜 그 결정인가"의 대화 보존 |
| E5 | 콘텐츠 SSOT | CLAUDE.md §5 Project-Specific Rules | 다중 페르소나가 단일 사실 출처 사용 |
9개 표준 SDD 도구가 모두 다루지 못하는 영역을 본문에 명시적으로 박는 의식입니다. 표준 도구로 옮긴 후에도 운영자 자체 의식으로 영구 남습니다.
정의
법적·윤리적·시장적 "회색지대"에서 "안전하고 솔직한 자기 위치"를 명세적으로 정하는 작업입니다.
표준 9개 도구가 못 다루는 근거
| 도구 | 다루는 영역 | 미점유 영역 |
|---|---|---|
| GSD | /gsd-secure-phase (코드 보안) | 사업 결정의 법적 안전성 |
| Spec-Kit | /speckit.constitution (architectural rules) | 비즈니스 위치 결정 |
| BMAD | Mary (분석가) requirements | 회색지대 변호 논리 |
| 모든 도구 | "비즈니스 요구사항"으로 받음 | 사용자에게 떠넘김 |
4단계 결정 프레임
| 단계 | 작업 | 시간 | 산출물 |
|---|---|---|---|
| ① 영역 식별 | 법적·윤리적·시장적 회색지대 어디인가 | 30분 | 영역 1줄 정의 |
| ② 포함 / 배제 | "포용 5개" + "명확히 배제 5개" | 1시간 | 두 목록 |
| ③ 표현 정제 | 외부 노출 텍스트 (About·약관·콘텐츠 정책) | 1시간 | 외부 노출 텍스트 |
| ④ SPEC 명시 | SPEC.md "§ 회색지대 결정" 섹션 박음 | 30분 | SPEC.md 섹션 |
총 약 3시간입니다.
줍줍 적용 사례 1 — "줍줍" 표현의 정직한 위치
[① 영역 식별] "줍줍"이라는 표현이 정부 지원금 공식 절차와 거리. 사용자 항의 또는 단속 위험. [② 포함 / 배제] 포함: - 정보 격차를 줄임 - 후기 공유로 신청 부담 완화 - 공식 정보 + 집단 경험 데이터 배제: - 무조건 받게 해준다는 약속 - 신청 결과 보장 - 정부 공식 절차 대행 [③ 표현 정제] - 브랜드명: "줍줍" 그대로 (사용자 친근감) - 본문 표현: "신청·수혜" 일관 사용 - About 페이지: 위 결정의 정직한 노출 - 약관: "본 서비스는 정보 제공 목적이며, 신청 결과를 보장하지 않습니다" 명시 [④ SPEC 명시] SPEC.md § 회색지대 결정 섹션에 위 ①~③ 박음. 변호 논리: "줍줍은 정부 공식 정보를 정리하고 사용자 후기를 공유하는 미디어이며, 신청 결과를 보장하거나 대행하지 않는다."
줍줍 적용 사례 2 — 개인정보 최소 수집
[① 영역 식별] 정부 지원금 앱은 사용자의 민감 정보 (소득·가구 형태·업종) 가 가까이 있음. PIPA (개인정보 보호법) 회색지대. [② 포함 / 배제] 포함: - 카카오 로그인 (최소 정보) - 자발적 입력 필터 (소득·가구 정보, 추천용) - 닉네임 자동 부여 (실명 비공개) 배제: - IDFA (광고 식별자) 수집 - 소득·가구 정보 외부 노출 - 개인정보 판매 (Phase 3 B2B 데이터 판매도 익명 집계만) [③ 표현 정제] 약관 + 개인정보처리방침 + About 페이지에 일관: "IDFA 미수집, 익명 닉네임, 카카오 로그인만, 개인정보 판매 없음" [④ SPEC 명시] SPEC.md § 회색지대 결정 섹션에 박음. 변호 논리: "줍줍은 PIPA의 최소 수집 원칙을 적극 준수, 추적 식별자 미수집"
TSV 적용 사례 — Position C (사행행위법)
[① 영역 식별] 한국 사행행위법의 "조장" 두 요건 (인지 + 설계). 베팅 인접 사용자가 가장 active한 시장이지만 직접 연결 시 위반. [② 포함 / 배제] 포함 5개: - 합법 스포츠토토 (정부 발행) 사용자 분석 정보 - 판타지 리그 사용자 - 데이터 마니아 (xG·점유율·슈팅 수치) - 통계 분석 학습 콘텐츠 - 경기 미리보기 + 다관점 큐레이션 명확한 배제 4개: - 베팅 사이트 직접 연결 (외부 URL 금지) - 배당률 → 한국식 배당으로 변환 표시 - 픽 (선택) 추천 형식 (예: "오늘의 픽") - 도박 관련 검색 키워드 SEO [④ SPEC 명시] SPEC.md § Position C 섹션. 변호 논리: "분석 콘텐츠 제공이 목적, 도박 조장 의도와 설계 없었다" 가 사실로 성립.
새 도메인 적용 체크리스트
- ☐ 내 도메인에 회색지대가 있는가? (있다면: 법적/윤리적/시장적 중 어느 것? / 없다면: E1 섹션 없이 SPEC 진행 가능)
- ☐ 회색지대 영역을 1줄로 정의할 수 있는가?
- ☐ 포함 5개 + 배제 5개를 명시할 수 있는가?
- ☐ 외부 노출 텍스트 (About·약관·콘텐츠 정책)가 일관되게 같은 메시지를 전달하는가?
- ☐ SPEC.md § 회색지대 결정 섹션이 본문에 박혔는가?
- ☐ 단속·신고 발생 시 변호 논리가 한 줄로 정리됐는가?
정의
"이 사람이 6~12개월 동안 무너지지 않을 페이스인가"의 메타 결정입니다.
3가지 형태
- (a) 시간 갭 정직 계산 — SPEC 변경의 시간 영향을 산식 + 옵션 A/B/C
- (b) 게이트 + 휴식의 의식 — 게이트 통과 조건에 "운영자 페이스 점검" 항목
- (c) R4 1인 번아웃 리스크 — 리스크 등록부에 일급 객체
줍줍 적용 — 10주
[10주 일정 + 8 게이트] G1 1주차 / G2 4주차 ★페이스 점검 / G3 6주차 / G4 8주차 / G5 10주차 [페이스 의식] - 게이트 통과 시 git tag + 1일 휴식 - 누적 60h/4주 초과 시 1일 휴식 의무 - 토요일 작업 금지 (예외: 게이트 마감 임박 → 일요일로 대체) - 매주 일요일 30분 회고 + 다음 주 목표 1줄 [R4 — 1인 운영 번아웃] 영향: 높음 / 확률: 중 완화책: 6주차+9주차 휴식 의무 / 토요일 금지 / 주간 회고 트리거: 누적 60h+/4주 또는 회고 부재 2주+
TSV 적용 — 33일 (옵션 C 채택 후)
[33일 일정 + 5 게이트] G1 Day 1 / G2 Day 10 / G3 Day 14 ★ CRITICAL / G4 Day 18 / G5 Day 33 ★ FINAL [시간 갭 흡수 옵션 C] PLAN v1 → v2 변환 시 +29h 부담. 가용 120h → 132h (3일 연장). "Phase 1.0의 본질은 '5리그 × 2 페르소나 안정 가동 + 7일 무장애 입증'이지 30일이라는 캘린더가 아니다." [페이스 의식] - 게이트 통과 시 git tag + 1일 휴식 - Day 14 CRITICAL 통과 후 2일 휴식 (가설 검증 부담) - 토요일 오후 자유 시간 의무 - 주간 회고 + 다음 주 목표
새 도메인 적용 체크리스트
- ☐ Phase 길이가 정해졌는가? (30일 / 90일 / 12개월 등)
- ☐ 게이트 통과 조건에 "운영자 페이스 점검" 항목이 있는가?
- ☐ 시간 갭 발생 시 옵션 A/B/C 비교 결정이 본문에 박혔는가?
- ☐ 리스크 등록부에 R4 1인 번아웃이 일급 객체로 등록됐는가? (영향: 높음 / 확률: 중 / 완화책: 휴식 의무 + 작업 금지 일자 + 주간 회고 / 트리거: 누적 시간 + 회고 부재)
- ☐ 매주 일요일 30분 회고 의식이 PLAN.md에 명시됐는가?
정의
"검토자 한 명에 의존하지 말라" — 두 다른 AI 모델 또는 두 사람의 사각지대가 다르므로 통합해야 입체적 검증이 됩니다.
두 단계 작동
| 라운드 | 시점 | 주체 | 발견 |
|---|---|---|---|
| 1라운드 | SPEC v1 → v2 | Gemini 외부 검토 | 5~7건 |
| 2라운드 | SPEC v3 → v4 | Claude 시뮬 + Gemini | 12건 |
12건 4+6+2 패턴 — 데이터 입증
| 영역 | Claude만 | Gemini만 | 둘 다 |
|---|---|---|---|
| TSV (미디어) | 4 | 6 | 2 |
| 줍줍 (B2C) | 4 | 6 | 2 |
같은 패턴이 다른 도메인에서 반복됩니다.
Claude vs Gemini 사각지대 차이
| 영역 | Claude 강점 | Gemini 강점 |
|---|---|---|
| 비즈니스 로직 | ✅ | |
| 사용자 행동 패턴 | ✅ | |
| 측정 가능 임계값 | ✅ | |
| SEO 키워드 | ✅ | |
| 인프라·기술 디테일 | ✅ | |
| Edge case 처리 | ✅ | |
| 외부 의존성 변경 | ✅ | |
| Null·fallback 처리 | ✅ |
새 도메인 적용 체크리스트
- ☐ SPEC v1 작성 후 Gemini 1차 검토를 받았는가? (5~7건 발견 정상)
- ☐ SPEC v2 작성 후 사용자 직관 단계를 거쳤는가?
- ☐ SPEC v3에 대해 두 검토 (Claude 시뮬 + Gemini)를 받았는가?
- ☐ 두 검토자 발견 건이 4+6+2 비율 패턴에 가까운가? (비율은 변형 가능, 패턴 자체는 반복)
- ☐ 12건 (또는 N건) 모두 SPEC v4에 반영됐는가?
- ☐ REVIEW.md 15가지 체크 중 #14 (SPEC v4 두 검토자) + #15 (12건 모두 반영)가 PASS인가?
정의
"왜 그 결정을 내렸는가"의 사용자-AI 대화 트레이스를 보존하는 패턴입니다. 단순 결정 결과가 아니라 결정에 도달하는 과정 자체를 본문에 남깁니다.
BUILD.md 일자별 양식
## Day N (날짜, 시간) [계획] - [PLAN의 해당 일자 항목] [실행] - [실제 산출물 + 양 언급] [LogOnTable 트레이스] ← E4의 자리 > 결정: [핵심 결정 한 줄] > 근거: [왜 그 결정인가] > 대안 비교: [다른 옵션과의 트레이드오프] > 부작용: [결정의 부산물·미래 부담] [이슈] - [발생/해결] [회고 1줄] - [오늘의 메타 교훈]
4 요소 트레이스 형식
| 요소 | 내용 | 비개발자 동업자 가치 |
|---|---|---|
| 결정 | 핵심 한 줄 | "무엇이 결정됐는가" |
| 근거 | 왜 그 결정인가 | "왜 그 결정인가" — 핵심 |
| 대안 비교 | 다른 옵션과 트레이드오프 | "다른 옵션은 왜 안 좋은가" |
| 부작용 | 부산물·미래 부담 | "이 결정의 비용은" |
줍줍 Day 17 사례 (마이페이지 + FCM)
[LogOnTable 트레이스]
> 결정: 마이페이지의 "내가 줍줍한 지원금 총액" 계산을 DB 집계로
> 근거: SPEC §4-4의 "바이럴 훅" 가치는 "실시간 정확성". 캐시는
분 단위 지연 가능 → 사용자 "방금 한 거 안 보여요" 항의 위험
> 대안: 서버 캐시 (5분 갱신) — 부하 적지만 신뢰 손상 가능
> 부작용: jupjups 추가 시 트리거 한 번 더 호출 (성능 미미한 영향)
> FCM 토큰 갱신: 7일 주기. 갱신 실패 시 user.fcm_token = NULLTSV Day 8 사례 (SSOT 메커니즘)
[LogOnTable 트레이스]
> 결정: lib/match_facts.ts의 stats 필드를 optional로
> 근거: NBA·MLB 데이터 부족 시 LLM 환각 방지. SPEC §3-9의
"입력에 없는 사실은 만들지 않는다"
> 대안: required + 기본값 0 — 환각 가능 (0이 진짜 0인지 데이터
부족인지 페르소나가 구별 못함)
> 부작용: 페르소나 system prompt에 "stats 없으면 통계 미공개로
명시" 규칙 추가. 자동 일관성 테스트 5번째 케이스 추가
> cache_control: 페르소나 system prompt 끝, ANTHROPIC_API_BETA
> 자동 테스트: tests/persona_consistency.test.ts. fail 시 cron 정지새 도메인 적용 체크리스트
- ☐ BUILD.md 일자별 양식에 "LogOnTable 트레이스" 섹션이 있는가?
- ☐ 매일 1~3줄 트레이스를 작성하는가?
- ☐ 4 요소 (결정 + 근거 + 대안 + 부작용)가 모두 포함되는가? (매일 4 요소 모두는 어렵다면, 핵심 결정 시점에만 4 요소 모두 적용)
- ☐ 6개월 후 동업자가 펼쳐서 "왜 이 결정인가"를 답할 수 있는가?
- ☐ 33~70일 누적 시 100~200개 트레이스가 모이는가?
정의
"같은 사실을 여러 페르소나가 다른 톤으로 표현"할 때, 사실 자체는 단일 출처에서 받는 패턴입니다. 코드의 SSOT (Single Source of Truth)를 콘텐츠 영역으로 확장합니다.
핵심 문제 — 사실 환각 (factual hallucination)
LLM 시대 고유 문제입니다. 페르소나가 "통계가 있어야 한다"는 압박으로 사실을 추정 → 같은 경기에 대해 페르소나마다 다른 사실 출력이 발생합니다.
삼중 안전장치
모든 페르소나가 단일 입력 인터페이스에서 사실을 받습니다.
"입력에 없는 사실을 만들지 말라"를 명시합니다.
페르소나마다 다른 출력 시 사실 일치를 자동 검증합니다.
줍줍 적용 — 7 규칙
[1] 사실 단일 출처: benefits 테이블
[2] 톤 분리: 소상공인 vs 개인 시민
[3] 닉네임 자동 부여 페르소나 풀 분리 (형용사 풀 20개)
[4] LLM 분류 프롬프트 분리: target_business vs target_age/household
[5] ⚖️ E1 회색지대 일관 노출 ("신청 결과 보장 없음")
[6] 자동 일관성 테스트 (tests/two-tab-consistency.test.ts)
[7] 환각 방지 명세: "JSON 외 출력 금지" + "추정 금지, 누락 null"TSV 적용 — 8 규칙
[1] 활성 페르소나 2종 (STAT + OBSERVER), Phase 1.1에서 +1 (COACH) [2] SSOT 의무: lib/match_facts.ts MatchFacts 인터페이스 [3] 사실 자체 변경 금지: 해석·표현·강조점만 다름 [4] 자동 일관성 테스트 의무: tests/persona_consistency.test.ts [5] prompt caching: cache_control + ANTHROPIC_API_BETA [6] 페르소나별 SEO 키워드 분리 (cannibalization 방지) [7] 익명성: 가상 인물명 부여 금지 [8] ⚖️ E1 Position C 일관 노출
두 사례의 공통 패턴
| 영역 | 줍줍 | TSV |
|---|---|---|
| SSOT 출처 | DB 테이블 | TypeScript 인터페이스 |
| 페르소나 수 | 2 | 2~3 |
| 톤 분리 방식 | 사장님 / 시민 | 통계 / 균형 / 전술 |
| 환각 방지 | LLM 프롬프트 명시 | system prompt + optional 필드 |
| 자동 테스트 | tests/two-tab-consistency | tests/persona_consistency |
| E1 일관 노출 | 모든 곳에 면책 | 모든 곳에 Position C |
| 자동 정지 | cron/sync.ts | cron/publish.ts |
새 도메인 적용 체크리스트
- ☐ 내 시스템에 다중 페르소나 또는 다중 톤 출력이 있는가? (있다면: 콘텐츠 SSOT 적용 / 없다면: E5 섹션 없이 진행 가능)
- ☐ SSOT 출처가 명확히 정의됐는가? (DB 테이블 / TypeScript 인터페이스 / API 응답 등 단일 출처)
- ☐ 페르소나 system prompt에 환각 방지 명세가 있는가? ("입력에 없는 사실은 만들지 말라" / "데이터 부족 시 '통계 미공개' 명시")
- ☐ 자동 일관성 테스트가 있는가? (같은 입력 → 페르소나별 출력 → 사실 일치 검증 / 실패 시 cron 또는 publish 정지 트리거)
- ☐ CLAUDE.md §5 Project-Specific Rules에 E5 규칙들이 박혔는가?
- ☐ 페르소나별 SEO 키워드 분리 (cannibalization 방지)가 있는가?
[1단계 — 도메인 파악] - B2C 앱 / B2B SaaS / 마켓플레이스 / 교육 / 콘텐츠 / 핀테크 / 의료 ... [2단계 — E1 점검] 회색지대가 있는가? YES → SPEC.md § 회색지대 결정 섹션 작성 (4단계 프레임) NO → E1 섹션 없이 진행 [3단계 — E2 점검] 1인 운영 또는 소수 (2~3명) 운영인가? YES → PLAN.md에 시간 갭·휴식 의식·R4 모두 박음 NO (5명+ 팀) → BMAD 또는 Spec-Kit으로 옮김 권장 [4단계 — E3 점검 (필수)] 모든 프로젝트에 적용. SPEC v3 → v4 진화 시 두 검토자 (Claude 시뮬 + Gemini) 동시 가동. [5단계 — E4 점검 (필수)] 모든 프로젝트에 적용. BUILD.md 일자별 양식에 LogOnTable 트레이스 1~3줄 매일 추가. [6단계 — E5 점검] 다중 페르소나 또는 다중 톤 출력이 있는가? YES → CLAUDE.md §5에 SSOT 7~8 규칙 박음 NO → E5 섹션 없이 진행
5확장 적용 매트릭스
| 도메인 | E1 | E2 | E3 | E4 | E5 |
|---|---|---|---|---|---|
| B2C 앱 (단순) | △ | ✅ | ✅ | ✅ | △ |
| B2C 앱 (회색지대 있음, 줍줍) | ✅ | ✅ | ✅ | ✅ | ✅ |
| B2B SaaS | △ | ✅ | ✅ | ✅ | △ |
| 마켓플레이스 | △ | ✅ | ✅ | ✅ | △ |
| 교육 | △ | ✅ | ✅ | ✅ | ✅ (난이도별 다른 톤) |
| 콘텐츠·미디어 (TSV) | ✅ | ✅ | ✅ | ✅ | ✅ |
| 핀테크 | ✅ | ✅ | ✅ | ✅ | △ |
| 의료 정보 앱 | ✅ | ✅ | ✅ | ✅ | △ |
✅ = 적용 / △ = 도메인 특수성 따라. E3·E4는 모든 프로젝트에 필수, E1·E5는 도메인 특수성 따라, E2는 1인·소수 운영자에게 필수입니다.
표준 도구 (GSD·Spec-Kit·BMAD 등)로 옮긴 후에도 5확장 5개는 운영자 자체 의식으로 남습니다.
5확장의 본질
5확장은 단순히 "표준 도구가 못 다루는 자리"가 아닙니다. 인간 운영자만 결정 가능한 자리입니다.
| 확장 | 인간만 가능한 결정 |
|---|---|
| E1 회색지대 | "이 회색지대를 어떻게 항해할 것인가"의 사업적·법적·윤리적 판단 |
| E2 1인 페이스 | "내가 무너지지 않을 페이스인가"의 자기 자각 |
| E3 두 검토자 | "한 검토자에 의존하지 말자"의 메타 의식 |
| E4 LogOnTable | "왜 이 결정인가"의 자기 설명 |
| E5 콘텐츠 SSOT | "같은 사실 다른 톤"의 콘텐츠 시스템 설계 |
3탄 권7 "표준 + 확장 컴패니언"의 제5장이 5확장 일반화의 자리입니다. 새 프로젝트 시작 시 펼치는 reference입니다.
📌 부록 H 정리
- 핵심 한 줄: 5확장 (E1~E5) = 9개 표준 도구가 모두 못 다루는 인간 운영자 자체 의식 영역. 새 도메인에 적용 시 H-6 의사결정 트리.
- 5확장 적용 강도: E1 (도메인 따라) / E2 (1인·소수 필수) / E3 (모두 필수) / E4 (모두 필수) / E5 (콘텐츠 시스템 따라)
- 사용법: SPEC 작성 시 H-1 / PLAN 작성 시 H-2 / REVIEW 작성 시 H-3 / BUILD 진행 시 H-4 / CLAUDE 작성 시 H-5
- 새 도메인 의사결정: H-6 매트릭스 + 6단계 점검.
- 영구성: 표준 도구로 옮긴 후에도 5확장은 운영자 자체 의식으로 남음. 권7 제5장에서 상세히 다룸.