1탄 부록 H — 5확장 분리 정리
부록 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 진화 단계한 검토자에 의존 금지, 두 모델 사각지대 차이 활용
E4LogOnTable 실황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 — LogOnTable 실황 보존 🔗

정의

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

BUILD.md 일자별 양식

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

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

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

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

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

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

4 요소 트레이스 형식

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

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

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

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

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

새 도메인 적용 체크리스트

📘 E4 체크리스트
  • ☐ BUILD.md 일자별 양식에 "LogOnTable 트레이스" 섹션이 있는가?
  • ☐ 매일 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 일자별 양식에 LogOnTable 트레이스
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 LogOnTable"왜 이 결정인가"의 자기 설명
E5 콘텐츠 SSOT"같은 사실 다른 톤"의 콘텐츠 시스템 설계
💡 권7에서 상세히 다룹니다

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