1탄 1탄 — 부록 H — 5확장 분리 정리
1탄 — 부록 H

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) 펼침
H-0 5확장 한 페이지 개요 🔗
코드명칭본문 위치핵심 메시지
E1회색지대 결정SPEC.md § 회색지대 결정법적·윤리적·시장적 회색지대를 SPEC에 명세적으로 결정
E21인 12개월 페이스PLAN.md (시간 갭·게이트 휴식·R4)운영자가 무너지지 않을 페이스를 본문에 박음
E3두 검토자 사각지대REVIEW.md + SPEC 진화 단계한 검토자에 의존 금지, 두 모델 사각지대 차이 활용
E4결정 실황BUILD.md 일자별 트레이스결정 결과가 아니라 "왜 그 결정인가"의 대화 보존
E5콘텐츠 SSOTCLAUDE.md §5 Project-Specific Rules다중 페르소나가 단일 사실 출처 사용
📘 5확장의 공통 정체성

9개 표준 SDD 도구가 모두 다루지 못하는 영역을 본문에 명시적으로 박는 의식입니다. 표준 도구로 옮긴 후에도 운영자 자체 의식으로 영구 남습니다.

H-1 E1 — 회색지대 결정 프레임 🔗

정의

법적·윤리적·시장적 "회색지대"에서 "안전하고 솔직한 자기 위치"를 명세적으로 정하는 작업입니다.

표준 9개 도구가 못 다루는 근거

도구다루는 영역미점유 영역
GSD/gsd-secure-phase (코드 보안)사업 결정의 법적 안전성
Spec-Kit/speckit.constitution (architectural rules)비즈니스 위치 결정
BMADMary (분석가) requirements회색지대 변호 논리
모든 도구"비즈니스 요구사항"으로 받음사용자에게 떠넘김

4단계 결정 프레임

단계작업시간산출물
① 영역 식별법적·윤리적·시장적 회색지대 어디인가30분영역 1줄 정의
② 포함 / 배제"포용 5개" + "명확히 배제 5개"1시간두 목록
③ 표현 정제외부 노출 텍스트 (About·약관·콘텐츠 정책)1시간외부 노출 텍스트
④ SPEC 명시SPEC.md "§ 회색지대 결정" 섹션 박음30분SPEC.md 섹션

총 약 3시간입니다.

줍줍 적용 사례 1 — "줍줍" 표현의 정직한 위치

💻 E1 적용 예시 — 줍줍 브랜드명
[① 영역 식별]
"줍줍"이라는 표현이 정부 지원금 공식 절차와 거리. 사용자 항의
또는 단속 위험.

[② 포함 / 배제]
포함:
- 정보 격차를 줄임
- 후기 공유로 신청 부담 완화
- 공식 정보 + 집단 경험 데이터

배제:
- 무조건 받게 해준다는 약속
- 신청 결과 보장
- 정부 공식 절차 대행

[③ 표현 정제]
- 브랜드명: "줍줍" 그대로 (사용자 친근감)
- 본문 표현: "신청·수혜" 일관 사용
- About 페이지: 위 결정의 정직한 노출
- 약관: "본 서비스는 정보 제공 목적이며, 신청 결과를 보장하지
  않습니다" 명시

[④ SPEC 명시]
SPEC.md § 회색지대 결정 섹션에 위 ①~③ 박음. 변호 논리:
"줍줍은 정부 공식 정보를 정리하고 사용자 후기를 공유하는
미디어이며, 신청 결과를 보장하거나 대행하지 않는다."

줍줍 적용 사례 2 — 개인정보 최소 수집

💻 E1 적용 예시 — PIPA 회색지대
[① 영역 식별]
정부 지원금 앱은 사용자의 민감 정보 (소득·가구 형태·업종)
가 가까이 있음. PIPA (개인정보 보호법) 회색지대.

[② 포함 / 배제]
포함:
- 카카오 로그인 (최소 정보)
- 자발적 입력 필터 (소득·가구 정보, 추천용)
- 닉네임 자동 부여 (실명 비공개)

배제:
- IDFA (광고 식별자) 수집
- 소득·가구 정보 외부 노출
- 개인정보 판매 (Phase 3 B2B 데이터 판매도 익명 집계만)

[③ 표현 정제]
약관 + 개인정보처리방침 + About 페이지에 일관:
"IDFA 미수집, 익명 닉네임, 카카오 로그인만, 개인정보 판매 없음"

[④ SPEC 명시]
SPEC.md § 회색지대 결정 섹션에 박음. 변호 논리:
"줍줍은 PIPA의 최소 수집 원칙을 적극 준수, 추적 식별자 미수집"

TSV 적용 사례 — Position C (사행행위법)

💻 E1 적용 예시 — TSV Position C
[① 영역 식별]
한국 사행행위법의 "조장" 두 요건 (인지 + 설계). 베팅 인접
사용자가 가장 active한 시장이지만 직접 연결 시 위반.

[② 포함 / 배제]
포함 5개:
- 합법 스포츠토토 (정부 발행) 사용자 분석 정보
- 판타지 리그 사용자
- 데이터 마니아 (xG·점유율·슈팅 수치)
- 통계 분석 학습 콘텐츠
- 경기 미리보기 + 다관점 큐레이션

명확한 배제 4개:
- 베팅 사이트 직접 연결 (외부 URL 금지)
- 배당률 → 한국식 배당으로 변환 표시
- 픽 (선택) 추천 형식 (예: "오늘의 픽")
- 도박 관련 검색 키워드 SEO

[④ SPEC 명시]
SPEC.md § Position C 섹션. 변호 논리:
"분석 콘텐츠 제공이 목적, 도박 조장 의도와 설계 없었다"
가 사실로 성립.

새 도메인 적용 체크리스트

📘 E1 체크리스트
  • ☐ 내 도메인에 회색지대가 있는가? (있다면: 법적/윤리적/시장적 중 어느 것? / 없다면: E1 섹션 없이 SPEC 진행 가능)
  • ☐ 회색지대 영역을 1줄로 정의할 수 있는가?
  • ☐ 포함 5개 + 배제 5개를 명시할 수 있는가?
  • ☐ 외부 노출 텍스트 (About·약관·콘텐츠 정책)가 일관되게 같은 메시지를 전달하는가?
  • ☐ SPEC.md § 회색지대 결정 섹션이 본문에 박혔는가?
  • ☐ 단속·신고 발생 시 변호 논리가 한 줄로 정리됐는가?
H-2 E2 — 1인 12개월 페이스 🔗

정의

"이 사람이 6~12개월 동안 무너지지 않을 페이스인가"의 메타 결정입니다.

3가지 형태

  • (a) 시간 갭 정직 계산 — SPEC 변경의 시간 영향을 산식 + 옵션 A/B/C
  • (b) 게이트 + 휴식의 의식 — 게이트 통과 조건에 "운영자 페이스 점검" 항목
  • (c) R4 1인 번아웃 리스크 — 리스크 등록부에 일급 객체

줍줍 적용 — 10주

💻 줍줍 E2 적용 예시
[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 채택 후)

💻 TSV E2 적용 예시
[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일 휴식 (가설 검증 부담)
- 토요일 오후 자유 시간 의무
- 주간 회고 + 다음 주 목표

새 도메인 적용 체크리스트

📘 E2 체크리스트
  • ☐ Phase 길이가 정해졌는가? (30일 / 90일 / 12개월 등)
  • ☐ 게이트 통과 조건에 "운영자 페이스 점검" 항목이 있는가?
  • ☐ 시간 갭 발생 시 옵션 A/B/C 비교 결정이 본문에 박혔는가?
  • ☐ 리스크 등록부에 R4 1인 번아웃이 일급 객체로 등록됐는가? (영향: 높음 / 확률: 중 / 완화책: 휴식 의무 + 작업 금지 일자 + 주간 회고 / 트리거: 누적 시간 + 회고 부재)
  • ☐ 매주 일요일 30분 회고 의식이 PLAN.md에 명시됐는가?
H-3 E3 — 두 검토자 사각지대 🔗

정의

"검토자 한 명에 의존하지 말라" — 두 다른 AI 모델 또는 두 사람의 사각지대가 다르므로 통합해야 입체적 검증이 됩니다.

두 단계 작동

라운드시점주체발견
1라운드SPEC v1 → v2Gemini 외부 검토5~7건
2라운드SPEC v3 → v4Claude 시뮬 + Gemini12건

12건 4+6+2 패턴 — 데이터 입증

영역Claude만Gemini만둘 다
TSV (미디어)462
줍줍 (B2C)462

같은 패턴이 다른 도메인에서 반복됩니다.

Claude vs Gemini 사각지대 차이

영역Claude 강점Gemini 강점
비즈니스 로직✅
사용자 행동 패턴✅
측정 가능 임계값✅
SEO 키워드✅
인프라·기술 디테일✅
Edge case 처리✅
외부 의존성 변경✅
Null·fallback 처리✅

새 도메인 적용 체크리스트

📘 E3 체크리스트
  • ☐ 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인가?
H-4 E4 — 결정 실황 보존 🔗

정의

"왜 그 결정을 내렸는가"의 사용자-AI 대화 트레이스를 보존하는 패턴입니다. 단순 결정 결과가 아니라 결정에 도달하는 과정 자체를 본문에 남깁니다.

BUILD.md 일자별 양식

💻 BUILD.md 일자별 양식
## Day N (날짜, 시간)

[계획]
- [PLAN의 해당 일자 항목]

[실행]
- [실제 산출물 + 양 언급]

[결정 트레이스]  ← E4의 자리
> 결정: [핵심 결정 한 줄]
> 근거: [왜 그 결정인가]
> 대안 비교: [다른 옵션과의 트레이드오프]
> 부작용: [결정의 부산물·미래 부담]

[이슈]
- [발생/해결]

[회고 1줄]
- [오늘의 메타 교훈]

4 요소 트레이스 형식

요소내용비개발자 동업자 가치
결정핵심 한 줄"무엇이 결정됐는가"
근거왜 그 결정인가"왜 그 결정인가" — 핵심
대안 비교다른 옵션과 트레이드오프"다른 옵션은 왜 안 좋은가"
부작용부산물·미래 부담"이 결정의 비용은"

줍줍 Day 17 사례 (마이페이지 + FCM)

💻 E4 트레이스 예시 — 줍줍 Day 17
[결정 트레이스]
> 결정: 마이페이지의 "내가 줍줍한 지원금 총액" 계산을 DB 집계로
> 근거: SPEC §4-4의 "바이럴 훅" 가치는 "실시간 정확성". 캐시는
       분 단위 지연 가능 → 사용자 "방금 한 거 안 보여요" 항의 위험
> 대안: 서버 캐시 (5분 갱신) — 부하 적지만 신뢰 손상 가능
> 부작용: jupjups 추가 시 트리거 한 번 더 호출 (성능 미미한 영향)
> FCM 토큰 갱신: 7일 주기. 갱신 실패 시 user.fcm_token = NULL

TSV Day 8 사례 (SSOT 메커니즘)

💻 E4 트레이스 예시 — TSV Day 8
[결정 트레이스]
> 결정: 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 정지

새 도메인 적용 체크리스트

📘 E4 체크리스트
  • ☐ BUILD.md 일자별 양식에 "결정 트레이스" 섹션이 있는가?
  • ☐ 매일 1~3줄 트레이스를 작성하는가?
  • ☐ 4 요소 (결정 + 근거 + 대안 + 부작용)가 모두 포함되는가? (매일 4 요소 모두는 어렵다면, 핵심 결정 시점에만 4 요소 모두 적용)
  • ☐ 6개월 후 동업자가 펼쳐서 "왜 이 결정인가"를 답할 수 있는가?
  • ☐ 33~70일 누적 시 100~200개 트레이스가 모이는가?
H-5 E5 — 콘텐츠 SSOT (코드 외 다중 페르소나) 🔗

정의

"같은 사실을 여러 페르소나가 다른 톤으로 표현"할 때, 사실 자체는 단일 출처에서 받는 패턴입니다. 코드의 SSOT (Single Source of Truth)를 콘텐츠 영역으로 확장합니다.

핵심 문제 — 사실 환각 (factual hallucination)

LLM 시대 고유 문제입니다. 페르소나가 "통계가 있어야 한다"는 압박으로 사실을 추정 → 같은 경기에 대해 페르소나마다 다른 사실 출력이 발생합니다.

삼중 안전장치

1
SSOT 인터페이스

모든 페르소나가 단일 입력 인터페이스에서 사실을 받습니다.

2
시스템 프롬프트 환각 방지

"입력에 없는 사실을 만들지 말라"를 명시합니다.

3
자동 일관성 테스트

페르소나마다 다른 출력 시 사실 일치를 자동 검증합니다.

줍줍 적용 — 7 규칙

💻 줍줍 SSOT 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 규칙

💻 TSV SSOT 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 인터페이스
페르소나 수22~3
톤 분리 방식사장님 / 시민통계 / 균형 / 전술
환각 방지LLM 프롬프트 명시system prompt + optional 필드
자동 테스트tests/two-tab-consistencytests/persona_consistency
E1 일관 노출모든 곳에 면책모든 곳에 Position C
자동 정지cron/sync.tscron/publish.ts

새 도메인 적용 체크리스트

📘 E5 체크리스트
  • ☐ 내 시스템에 다중 페르소나 또는 다중 톤 출력이 있는가? (있다면: 콘텐츠 SSOT 적용 / 없다면: E5 섹션 없이 진행 가능)
  • ☐ SSOT 출처가 명확히 정의됐는가? (DB 테이블 / TypeScript 인터페이스 / API 응답 등 단일 출처)
  • ☐ 페르소나 system prompt에 환각 방지 명세가 있는가? ("입력에 없는 사실은 만들지 말라" / "데이터 부족 시 '통계 미공개' 명시")
  • ☐ 자동 일관성 테스트가 있는가? (같은 입력 → 페르소나별 출력 → 사실 일치 검증 / 실패 시 cron 또는 publish 정지 트리거)
  • ☐ CLAUDE.md §5 Project-Specific Rules에 E5 규칙들이 박혔는가?
  • ☐ 페르소나별 SEO 키워드 분리 (cannibalization 방지)가 있는가?
H-6 5확장 새 도메인 적용 의사결정 🔗
💻 5확장 6단계 점검
[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 일자별 양식에 결정 트레이스
1~3줄 매일 추가.

[6단계 — E5 점검]
다중 페르소나 또는 다중 톤 출력이 있는가?
  YES → CLAUDE.md §5에 SSOT 7~8 규칙 박음
  NO → E5 섹션 없이 진행

5확장 적용 매트릭스

도메인E1E2E3E4E5
B2C 앱 (단순)△✅✅✅△
B2C 앱 (회색지대 있음, 줍줍)✅✅✅✅✅
B2B SaaS△✅✅✅△
마켓플레이스△✅✅✅△
교육△✅✅✅✅ (난이도별 다른 톤)
콘텐츠·미디어 (TSV)✅✅✅✅✅
핀테크✅✅✅✅△
의료 정보 앱✅✅✅✅△

✅ = 적용 / △ = 도메인 특수성 따라. E3·E4는 모든 프로젝트에 필수, E1·E5는 도메인 특수성 따라, E2는 1인·소수 운영자에게 필수입니다.

H-7 5확장이 영구 남는 이유 🔗

표준 도구 (GSD·Spec-Kit·BMAD 등)로 옮긴 후에도 5확장 5개는 운영자 자체 의식으로 남습니다.

5확장의 본질

5확장은 단순히 "표준 도구가 못 다루는 자리"가 아닙니다. 인간 운영자만 결정 가능한 자리입니다.

확장인간만 가능한 결정
E1 회색지대"이 회색지대를 어떻게 항해할 것인가"의 사업적·법적·윤리적 판단
E2 1인 페이스"내가 무너지지 않을 페이스인가"의 자기 자각
E3 두 검토자"한 검토자에 의존하지 말자"의 메타 의식
E4 결정"왜 이 결정인가"의 자기 설명
E5 콘텐츠 SSOT"같은 사실 다른 톤"의 콘텐츠 시스템 설계
💡 권7에서 상세히 다룹니다

3탄 권7 "표준 + 확장 컴패니언"의 제5장이 5확장 일반화의 단계입니다. 새 프로젝트 시작 시 펼치는 reference입니다.

📌 1탄 — 부록 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장에서 상세히 다룸.
📘
1탄 도우미
질문하기 OK
안녕하세요! 5확장 (E1~E5)에 대해 무엇이든 물어보세요. 본문에서 찾아 답변해드릴게요. 👇