16장 — 콘텐츠 SSOT 장기 운영
CHAPTER 16
콘텐츠 SSOT 장기 운영
100개 → 1000개 → 10000개 누적
📑 이 챕터에서 다룰 내용

새 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 의식

💡 SSOT는 정원과 같습니다

정원을 한 번 만들고 "끝"으로 두면 6개월 후 잡초가 자랍니다. SSOT도 같습니다. 매주 30분·매월 2시간 가꾸지 않으면 6개월 후 SSOT가 "진실의 출처"가 아니라 "애매한 자료 더미"가 됩니다.

16-1 콘텐츠 자산 누적 — 100개·1000개·10000개 🔗

SSOT 운영의 가장 큰 변수는 "콘텐츠 개수"입니다. 개수에 따라 운영 흐름이 완전히 달라집니다.

100개 — 첫 6개월

💻 규모 100개 운영 흐름
[규모 100개 — 첫 6개월]
- DB 행: 약 100개
- 페르소나 출력: 200~400개 (페르소나 2~4 × 100)
- 운영 부담: 매주 30분 (검수·갱신)
- 깨짐 빈도: 매월 1~2건
- 도구: 단순 SQL + 간단 검수 화면

[적용 흐름]
- 매주 일요일 검수 큐 30분
- 새 페르소나 추가 시 모든 100개 재검토 (1회 2시간)
- DB 스키마 변경 시 손 마이그레이션 가능

1000개 — 6개월 ~ 1년

💻 규모 1000개 운영 흐름
[규모 1000개 — 6개월~1년]
- DB 행: 약 1000개
- 페르소나 출력: 2000~4000개
- 운영 부담: 매주 1~2시간
- 깨짐 빈도: 매월 5~10건
- 도구: 검수 큐 + 자동 일관성 테스트 + 알림

[적용 흐름]
- 매주 검수 큐 1~2시간
- 새 페르소나 추가 시 샘플 50개만 재검토 (배치 LLM)
- DB 스키마 변경 시 마이그레이션 스크립트 의무
- 자동 일관성 테스트 통과율 모니터링 (목표 99%+)

10000개 — 1년 ~ 3년

💻 규모 10000개 운영 흐름
[규모 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분/개
🎉 자동화 ROI가 폭증하는 흐름

콘텐츠 개수가 100배 증가해도 부담은 6~10배만 증가합니다. 자동화 ROI가 폭증하는 흐름이에요.

16-2 SSOT 인터페이스 변경·필드 추가 🔗

SSOT는 살아있는 시스템이므로 인터페이스가 변합니다. 필드 추가·변경·삭제 흐름입니다.

필드 추가 — 가장 흔한 변경

💻 SSOT 인터페이스 v1 → v2 진화
// 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;
  };
}
📘 필드 추가 4 의식

[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;      // 새 필드
}
📘 필드 변경 5 의식

[1] 기존 필드는 "deprecated" 표시 후 새 필드 추가

[2] 6개월 점진 마이그레이션 (한 번에 변경 X)

[3] 새 필드 사용률 90%+ 후 기존 필드 삭제

[4] CLAUDE.md §5 마이그레이션 규칙 명시

[5] LogOnTable에 마이그레이션 일자별 진행률 트레이스

필드 삭제 — 마지막 단계

📘 필드 삭제 5 단계

[1] 6개월 deprecated 표시

[2] 마지막 1개월 사용률 0% 확인

[3] DB migration으로 컬럼 삭제 + 인덱스 정리

[4] 자동 일관성 테스트에서 필드 검증 제거

[5] CLAUDE.md §5 규칙에서 해당 필드 언급 제거

16-3 콘텐츠 종류 — 블로그·강의·이북·SNS 🔗

SSOT가 "한 사실 → 여러 채널" 흐름이 되면 채널마다 다른 형식이 필요합니다.

4 채널의 형식 차이

채널길이갱신 빈도SEO 비중
블로그1500~3000자친근·정보매주 1~2개◎ 핵심
강의30분 영상강의 톤·시각분기 1개
이북50~200쪽종합 흐름연 1~2개
SNS100~300자짧고 즉시매일 1~3개×

한 사실 → 4 채널 흐름

💻 SSOT 한 사실 → 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 흐름
[Cron — 매일 자정]
1. SSOT DB 갱신 확인
2. 새 사실 발견 시:
   - 블로그 자동 초안 생성 (Sonnet, ~2500자)
   - SNS 즉시 발행 (Haiku, 짧고 빠름)
3. 매주 일요일 — 강의 outline 생성 (Opus, 분기 1개)
4. 매월 — 이북 1쪽 추가 자동 작성 (연 1~2 이북 누적)

[운영자 손 작업]
- 자동 초안 검토 (블로그 5분/개)
- 강의 시각 자료 추가 (분기 4시간)
- 이북 종합 흐름 정리 (연 1~2회)
💡 자동 발행 = 사실 자동, 표현 검토

자동 발행은 "사실 자동, 표현 운영자 검토" 흐름이 안전합니다. 표현까지 자동이면 채널별 톤 차이가 무너집니다.

16-4 백업·복원 의식 🔗

SSOT는 "단일 출처"이므로 깨지면 모든 채널이 깨집니다. 백업·복원이 핵심입니다.

백업 흐름 4 단계

1
DB 스냅샷 — 매일 자동
Supabase: pg_dump 자동 (매일 03:00 KST). 30일 보관. 가장 기본적인 백업.
2
DB 행 단위 변경 로그 — 실시간
Supabase: pgaudit 또는 trigger. 누가·언제·무엇을 변경했는지 보존. 복원 시 근거가 됩니다.
3
CLAUDE.md §5 SSOT 규칙 백업 — git
매 SSOT 규칙 변경 시 git commit. 6개월 변경 흐름 git log로 검증 가능.
4
페르소나 시스템 프롬프트 백업 — git
매 프롬프트 변경 시 git commit + tag. 어떤 시점의 프롬프트가 어떤 결과를 만들었는지 검증 가능.

복원 흐름 — 3 시나리오

📘 시나리오 1: DB 단일 행 손상 (가장 흔함) — 복원 5분

[증상] 페르소나 출력에서 "마감일이 1970-01-01" 같은 비정상

[발견] 자동 일관성 테스트 fail

[복원 흐름]

  1. 손상된 행 ID 식별
  2. 어제 백업에서 해당 행 복구
  3. 변경 로그 검토 (누가 변경)
  4. CLAUDE.md §5 보호 규칙 강화
📘 시나리오 2: SSOT 인터페이스 변경 실수 — 복원 30분~2시간

[증상] 6개월 누적 콘텐츠 1000개가 페르소나 출력 X

[발견] 모니터링 알림 (Sentry)

[복원 흐름]

  1. 인터페이스 변경 commit revert
  2. 자동 일관성 테스트 재실행
  3. CLAUDE.md §5 갱신 의식 강화
📘 시나리오 3: 페르소나 환각 누적 — 복원 1주~1개월

[증상] 페르소나가 "입력에 없는 사실"을 누적 출력

[발견] 외부 사용자 항의 또는 정기 점검

[복원 흐름]

  1. 영향 콘텐츠 식별 (자동 일관성 테스트 fail history)
  2. 페르소나 시스템 프롬프트 강화 (cache_control 갱신)
  3. 영향 콘텐츠 재생성
  4. CLAUDE.md §5 환각 방지 규칙 보강
16-5 SSOT 깨짐 함정 — 단일 실패점 위험 🔗

SSOT의 가장 큰 위험: "단일 출처"가 핵심 가치인 동시에 "단일 실패점 (Single Point of Failure)"이 됩니다.

깨짐 4 패턴

⚠️ 패턴 1: SSOT 행 손상 → 모든 페르소나 동시 깨짐

손상된 1행이 페르소나 4명의 출력에 동시 영향 → 4 채널 모두 비정상.

방지: 자동 일관성 테스트 + 검수 큐 의식 + 매일 30분 점검.

⚠️ 패턴 2: SSOT 인터페이스 변경 → 6개월 누적 콘텐츠 깨짐

kickoff_kst 형식 변경 → 6개월 누적 6000개 콘텐츠 깨짐 → 100% 콘텐츠 영향.

방지: 16-2의 "필드 변경 5 의식" 적용.

⚠️ 패턴 3: 페르소나 환각 누적 → SSOT 신뢰 깨짐

페르소나가 "통계 추정"을 6개월 누적 → 사용자가 "이 데이터 신뢰 X" 결정.

방지: 자동 일관성 테스트 + cache_control + system prompt "추정 금지".

⚠️ 패턴 4: SSOT 규칙 미의식 → 새 페르소나가 규칙 무시

Phase 2에서 새 페르소나 추가 시 CLAUDE.md §5 규칙 미의식 → 새 페르소나만 SSOT 무시 → 일관성 깨짐.

방지: 새 페르소나 추가 시 CLAUDE.md §5 7~8 규칙 의식 의무.

16-6 운영 시간 — 매일 5분·매주 30분·매월 2시간 🔗

SSOT 장기 운영의 시간 분포입니다.

시간 분포 표

빈도시간작업
매일5분검수 큐 fail 0건 확인 + LogOnTable 1줄
매주30분~5시간검수 큐 종합 검토 (규모 따라)
매월2시간SSOT 인터페이스 점검 + CLAUDE.md §5 갱신
분기8시간새 페르소나 또는 새 채널 추가 결정
연 1회16시간DB 스키마 종합 점검 + 마이그레이션

1년 누적 운영 시간

💻 규모 1000개 콘텐츠 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개 적용 효과
[자동화 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 트리거 감소 흐름
📌 새 16장 정리
  • 핵심 한 줄: 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별 비용
🤖
1탄 학습 도우미
질문하기 OK
안녕하세요! SSOT 장기 운영에 대해 무엇이든 물어보세요. 본문에서 찾아 답변해드릴게요. 👇