📑 이 챕터에서 다룰 내용
새 11장에서 E5 콘텐츠 SSOT를 만들었고, 새 14·15장에서 MCP·예외 흐름과 결합했습니다. 이제 "시간"의 차원입니다 — SSOT가 6개월·1년·3년 후 어떻게 변하는가.
콘텐츠 SSOT는 "한 번 만들고 끝"이 아닙니다. 100개에서 1000개·10000개로 누적되고, 페르소나가 추가되고, 채널이 늘어나고, DB 스키마가 변경됩니다. 이 진화를 의식하지 않고 운영하면 6개월 후 SSOT가 깨집니다.
사전 지식: 새 11장 CLAUDE.md §5 + E5 7~8 규칙 / 줍줍·TSV 사례 인지
이 장의 목적: SSOT의 6개월·1년·3년 누적 진화 + 자동 발행 흐름 + 백업·복원 의식 + 운영 시간 분포
완료 후 결과물: 장기 운영 가능한 SSOT 흐름 + 깨짐 방지 4 의식
정원을 한 번 만들고 "끝"으로 두면 6개월 후 잡초가 자랍니다. SSOT도 같습니다. 매주 30분·매월 2시간 가꾸지 않으면 6개월 후 SSOT가 "진실의 출처"가 아니라 "애매한 자료 더미"가 됩니다.
SSOT 운영의 가장 큰 변수는 "콘텐츠 개수"입니다. 개수에 따라 운영 흐름이 완전히 달라집니다.
100개 — 첫 6개월
[규모 100개 — 첫 6개월] - DB 행: 약 100개 - 페르소나 출력: 200~400개 (페르소나 2~4 × 100) - 운영 부담: 매주 30분 (검수·갱신) - 깨짐 빈도: 매월 1~2건 - 도구: 단순 SQL + 간단 검수 화면 [적용 흐름] - 매주 일요일 검수 큐 30분 - 새 페르소나 추가 시 모든 100개 재검토 (1회 2시간) - DB 스키마 변경 시 손 마이그레이션 가능
1000개 — 6개월 ~ 1년
[규모 1000개 — 6개월~1년] - DB 행: 약 1000개 - 페르소나 출력: 2000~4000개 - 운영 부담: 매주 1~2시간 - 깨짐 빈도: 매월 5~10건 - 도구: 검수 큐 + 자동 일관성 테스트 + 알림 [적용 흐름] - 매주 검수 큐 1~2시간 - 새 페르소나 추가 시 샘플 50개만 재검토 (배치 LLM) - DB 스키마 변경 시 마이그레이션 스크립트 의무 - 자동 일관성 테스트 통과율 모니터링 (목표 99%+)
10000개 — 1년 ~ 3년
[규모 10000개 — 1~3년] - DB 행: 약 10000개 - 페르소나 출력: 20000~40000개 - 운영 부담: 매주 3~5시간 - 깨짐 빈도: 매주 5~10건 - 도구: 검수 + 자동 일관성 + 정기 batch 점검 + 외주 큐 [적용 흐름] - 매일 검수 큐 30분 (자동 일관성 fail 1순위) - 매주 3~5시간 종합 점검 - 새 페르소나 추가 = 큰 결정 (전체 SSOT 영향 검토 8시간) - DB 스키마 변경 = 분기 단위 결정 (마이그레이션 + 검증 16시간)
운영 부담의 비선형 증가
| 규모 | 매주 부담 | 시간/콘텐츠 |
|---|---|---|
| 100개 | 30분 | 0.3분/개 |
| 1000개 | 1~2시간 | 0.1분/개 |
| 10000개 | 3~5시간 | 0.03분/개 |
콘텐츠 개수가 100배 증가해도 부담은 6~10배만 증가합니다. 자동화 ROI가 폭증하는 흐름이에요.
SSOT는 살아있는 시스템이므로 인터페이스가 변합니다. 필드 추가·변경·삭제 흐름입니다.
필드 추가 — 가장 흔한 변경
// SSOT 인터페이스 v1 (Day 8 — 새 11장 시점)
interface MatchFacts {
match_id: string;
league_code: string;
home_team: string;
away_team: string;
kickoff_kst: string;
}
// SSOT 인터페이스 v2 (Day 90 — Phase 1.1)
interface MatchFacts {
match_id: string;
league_code: string;
home_team: string;
away_team: string;
kickoff_kst: string;
stats?: { // ★ 추가
xg_home?: number;
xg_away?: number;
possession_home?: number;
possession_away?: number;
};
}[1] optional (?)으로 추가 — 기존 콘텐츠 영향 X
[2] CLAUDE.md §5 7~8 규칙 갱신 의무
[3] 자동 일관성 테스트에 새 필드 검증 추가
[4] BUILD.md LogOnTable 1줄 — "왜 이 필드 추가"
필드 변경 — 가장 위험한 변경
이미 사용 중인 필드의 의미·형식 변경. 6개월 누적 콘텐츠를 깨뜨릴 수 있습니다.
// ❌ 함정: 기존 필드 의미 변경
interface MatchFacts {
kickoff_kst: string; // v1: "YYYY-MM-DD HH:mm"
// → v2: ISO 8601 변경 시 6000개 콘텐츠 깨짐
}
// ✅ 권장: 새 필드 추가 + 기존 필드 점진 마이그레이션
interface MatchFacts {
kickoff_kst: string; // 기존 (deprecated)
kickoff_iso?: string; // 새 필드
}[1] 기존 필드는 "deprecated" 표시 후 새 필드 추가
[2] 6개월 점진 마이그레이션 (한 번에 변경 X)
[3] 새 필드 사용률 90%+ 후 기존 필드 삭제
[4] CLAUDE.md §5 마이그레이션 규칙 명시
[5] LogOnTable에 마이그레이션 일자별 진행률 트레이스
필드 삭제 — 마지막 단계
[1] 6개월 deprecated 표시
[2] 마지막 1개월 사용률 0% 확인
[3] DB migration으로 컬럼 삭제 + 인덱스 정리
[4] 자동 일관성 테스트에서 필드 검증 제거
[5] CLAUDE.md §5 규칙에서 해당 필드 언급 제거
SSOT가 "한 사실 → 여러 채널" 흐름이 되면 채널마다 다른 형식이 필요합니다.
4 채널의 형식 차이
| 채널 | 길이 | 톤 | 갱신 빈도 | SEO 비중 |
|---|---|---|---|---|
| 블로그 | 1500~3000자 | 친근·정보 | 매주 1~2개 | ◎ 핵심 |
| 강의 | 30분 영상 | 강의 톤·시각 | 분기 1개 | ○ |
| 이북 | 50~200쪽 | 종합 흐름 | 연 1~2개 | △ |
| SNS | 100~300자 | 짧고 즉시 | 매일 1~3개 | × |
한 사실 → 4 채널 흐름
[SSOT — 한 사실] "2026년 청년 창업 지원금이 1500억 원 규모로 운영됩니다. 신청 기간은 3월 1일~5월 31일이며, 만 39세 이하 + 창업 3년 이내 사업자가 대상입니다." [채널별 변환] 블로그 (2500자): - "2026년 청년 창업 지원금 신청 가이드" - 배경 설명 + 신청 단계 + 함정 + 후기 사례 강의 (30분 영상): - 1분 후킹 + 5분 배경 + 15분 신청 단계 시연 + 5분 함정 + 4분 Q&A 이북 (50쪽): - 1쪽 SSOT 인용 + 49쪽 종합 가이드 (다른 지원금 결합) SNS (200자): - "3/1 시작! 만 39세·창업 3년 이내 청년 창업 지원금 1500억" - 해시태그 + 자세한 내용 → 블로그 링크
자동 발행 흐름
[Cron — 매일 자정] 1. SSOT DB 갱신 확인 2. 새 사실 발견 시: - 블로그 자동 초안 생성 (Sonnet, ~2500자) - SNS 즉시 발행 (Haiku, 짧고 빠름) 3. 매주 일요일 — 강의 outline 생성 (Opus, 분기 1개) 4. 매월 — 이북 1쪽 추가 자동 작성 (연 1~2 이북 누적) [운영자 손 작업] - 자동 초안 검토 (블로그 5분/개) - 강의 시각 자료 추가 (분기 4시간) - 이북 종합 흐름 정리 (연 1~2회)
자동 발행은 "사실 자동, 표현 운영자 검토" 흐름이 안전합니다. 표현까지 자동이면 채널별 톤 차이가 무너집니다.
SSOT는 "단일 출처"이므로 깨지면 모든 채널이 깨집니다. 백업·복원이 핵심입니다.
백업 흐름 4 단계
복원 흐름 — 3 시나리오
[증상] 페르소나 출력에서 "마감일이 1970-01-01" 같은 비정상
[발견] 자동 일관성 테스트 fail
[복원 흐름]
- 손상된 행 ID 식별
- 어제 백업에서 해당 행 복구
- 변경 로그 검토 (누가 변경)
- CLAUDE.md §5 보호 규칙 강화
[증상] 6개월 누적 콘텐츠 1000개가 페르소나 출력 X
[발견] 모니터링 알림 (Sentry)
[복원 흐름]
- 인터페이스 변경 commit revert
- 자동 일관성 테스트 재실행
- CLAUDE.md §5 갱신 의식 강화
[증상] 페르소나가 "입력에 없는 사실"을 누적 출력
[발견] 외부 사용자 항의 또는 정기 점검
[복원 흐름]
- 영향 콘텐츠 식별 (자동 일관성 테스트 fail history)
- 페르소나 시스템 프롬프트 강화 (cache_control 갱신)
- 영향 콘텐츠 재생성
- CLAUDE.md §5 환각 방지 규칙 보강
SSOT의 가장 큰 위험: "단일 출처"가 핵심 가치인 동시에 "단일 실패점 (Single Point of Failure)"이 됩니다.
깨짐 4 패턴
손상된 1행이 페르소나 4명의 출력에 동시 영향 → 4 채널 모두 비정상.
방지: 자동 일관성 테스트 + 검수 큐 의식 + 매일 30분 점검.
kickoff_kst 형식 변경 → 6개월 누적 6000개 콘텐츠 깨짐 → 100% 콘텐츠 영향.
방지: 16-2의 "필드 변경 5 의식" 적용.
페르소나가 "통계 추정"을 6개월 누적 → 사용자가 "이 데이터 신뢰 X" 결정.
방지: 자동 일관성 테스트 + cache_control + system prompt "추정 금지".
Phase 2에서 새 페르소나 추가 시 CLAUDE.md §5 규칙 미의식 → 새 페르소나만 SSOT 무시 → 일관성 깨짐.
방지: 새 페르소나 추가 시 CLAUDE.md §5 7~8 규칙 의식 의무.
SSOT 장기 운영의 시간 분포입니다.
시간 분포 표
| 빈도 | 시간 | 작업 |
|---|---|---|
| 매일 | 5분 | 검수 큐 fail 0건 확인 + LogOnTable 1줄 |
| 매주 | 30분~5시간 | 검수 큐 종합 검토 (규모 따라) |
| 매월 | 2시간 | SSOT 인터페이스 점검 + CLAUDE.md §5 갱신 |
| 분기 | 8시간 | 새 페르소나 또는 새 채널 추가 결정 |
| 연 1회 | 16시간 | DB 스키마 종합 점검 + 마이그레이션 |
1년 누적 운영 시간
[규모 1000개 콘텐츠 1년 운영] - 매일 5분 × 365일 = 30시간 - 매주 1시간 × 52주 = 52시간 - 매월 2시간 × 12개월 = 24시간 - 분기 8시간 × 4분기 = 32시간 - 연 16시간 = 16시간 - 합계: 154시간 / 1년 = 약 3시간/주 [★ 1인 운영자 인지] - 1주 작업 시간 15h 중 약 20%가 SSOT 운영 - E2 1인 페이스의 핵심 부담
자동화 적용 후 시간 절감
[자동화 4개 적용] 1. 자동 일관성 테스트 (E5 [4]) — 매일 5분 → 1분 2. 자동 검수 큐 분류 (LLM batch) — 매주 1시간 → 20분 3. CLAUDE.md §5 자동 갱신 알림 — 매월 2시간 → 30분 4. DB 자동 백업 + 복원 스크립트 — 연 16시간 → 4시간 [효과] - 154시간 → 약 60시간 (-60%) - 1주 3시간 → 1주 1.2시간 - ★ R4 트리거 감소 흐름
- 핵심 한 줄: SSOT는 살아있는 시스템. 100개 → 10000개로 100배 증가해도 자동화 ROI 폭증으로 부담은 6~10배만 증가
- 콘텐츠 누적 흐름: 100개 (6개월): 매주 30분 / 1000개 (1년): 매주 1~2시간 / 10000개 (3년): 매주 3~5시간
- 인터페이스 변경 의식: 필드 추가 4 의식 (optional·CLAUDE.md 갱신·테스트 추가·LogOnTable) / 필드 변경 5 의식 (deprecated 표시·6개월 점진·90% 후 삭제·마이그레이션 규칙·트레이스) / 필드 삭제: 6개월 deprecated → 사용률 0% 확인 → migration
- 4 채널 형식: 블로그 (2500자) / 강의 (30분) / 이북 (50쪽) / SNS (200자). 한 SSOT → 자동 발행 (사실 자동, 표현 운영자 검토)
- 백업 4 단계: DB 스냅샷 매일 / 변경 로그 실시간 / CLAUDE.md §5 git / 페르소나 프롬프트 git
- 복원 3 시나리오: DB 행 손상 5분 / 인터페이스 실수 30분~2시간 / 페르소나 환각 1주~1개월
- 깨짐 4 패턴: 행 손상 / 인터페이스 변경 / 환각 누적 / 규칙 미의식
- 운영 시간 (1년 누적): 154시간 (자동화 적용 후 60시간, -60%)
- 다음 장: 새 17장 — 비용·자원 종합 가이드. Anthropic API + 호스팅 + VPS Phase별 비용