빌딩 인 퍼블릭: 22일차 - 품질 개선이 찾아낸 보물

계획: 스토리 품질 개선

Day 21에서 발견한 문제: 스토리 경로마다 선택지가 1-6개밖에 없었다. MBTI 분석의 신뢰도를 위해서는 최소 10개가 필요하다.

해결 계획은 명확했다:

Phase 1: 스토리 생성기 업데이트

경로당 최소 10개 선택지 강제
자동 검증 시스템 추가
이미지 최적화 통합
새 스토리로 테스트

간단하지 않은가? 프롬프트 몇 줄 수정하고, 검증 돌리고, 끝.

실제로 일어난 일: 그것도 다 했고, 게다가 예상치 못한 75% 컨텐츠 감소까지 달성했다. 우리가 몰랐던 문제들까지 해결하면서.

Part 1: 구현

오전 작업: 검증 시스템 구축

첫 번째 단계: 이제 잘못된 스토리를 생성하는 게 불가능하게 만들자.

AI 프롬프트 업데이트 (generate_story_json.py):

절대 요구사항 (협상 불가):
- 경로당 최소 10개 선택 노드
- MBTI 4개 차원 모두 경로당 2-3회 테스트
- 구조: 초반 4개 + 중반 4개 + 후반 3개 = 경로당 11개

이제 “부탁합니다”나 “가능하면” 같은 표현은 없다. 그냥 하드 요구사항.

검증 도구 제작 (validate_story_paths.py):

스토리의 모든 가능한 경로를 추적
각 경로의 선택지 개수 카운트
MBTI 차원 커버리지 검증
결과 리포트: ✅ 통과 또는 ❌ 실패 + 구체적 이슈

프랑켄슈타인으로 테스트:

📊 결과:
- 전체 경로: 10개
- 실패한 경로: 10/10 (100%)
- 경로당 선택지: 최소=1, 최대=6, 평균=3.5

❌ 검증 실패 - 스토리 재생성 필요

검증 시스템은 완벽하게 작동했다. Day 21에서 찾아낸 문제를 정확히 잡아냈다.

이미지 최적화 추가:

이미지 생성 후 자동 WebP 변환
95% 이상 용량 감소 (2MB PNG → 0.1MB WebP)
수동 최적화 필요 없음

정오쯤: 세 가지 개선사항 모두 구현 및 테스트 완료. Phase 1.4 준비 끝.

Part 2: 테스트 스토리

오후 작업: 위대한 개츠비 생성

업데이트된 생성기가 실제로 작동하는지 증명이 필요했다. 완전히 새로운 스토리를 처음부터 생성:

“위대한 개츠비” - F. Scott Fitzgerald

49개 노드 (선택 노드 16개, 엔딩 17개, 일반 노드 16개)
비수렴 트리 구조
완전한 MBTI 추적

검증 실행:

✅ 1,408개의 완전한 경로 발견

경로당 선택지:
  최소: 10 ✓
  최대: 10
  평균: 10.0

MBTI 커버리지 (경로당):
  E/I: 10회 측정 ✓
  S/N: 10회 측정 ✓
  T/F: 10회 측정 ✓
  J/P: 10회 측정 ✓

✅ 검증 통과

완벽하다. 생성기 작동한다. Phase 1.4 완료.

이제 변경사항 문서화하고 Phase 2로—

모든 걸 바꾼 사용자의 질문

그때 문서 작성을 위해 개츠비 JSON을 리뷰했다.

각 엔딩 노드에 이런 구조가 있었다:

"ending_warning_attempt": {
  "likelyPersonalities": ["ESFJ", "ENFJ", "ISFJ"],
  "personalityDescriptions": {
    "ISTJ": "**체계적 관찰자**: ...",
    "ISFJ": "**헌신적 수호자**: ...",
    "INFJ": "...",
    "INTJ": "...",
    // ... 13개 더 ...
  }
}

사용자가 물었다: “16개 성격 유형 설명이 다 필요한가요? ‘가능성 있는 성격’에는 세 가지만 있는데요.”

잠깐.

likelyPersonalities는 이 엔딩에 도달할 가능성이 높은 유형이 3개뿐이라고 말한다.

그런데 우리는 16개 유형 전부의 설명을 포함하고 있다.

그러니까 사용되지 않는 설명이 13개… 엔딩마다… 17개 엔딩이니까…

계산

현재 방식:

엔딩당 16개 MBTI 유형
개츠비에 17개 엔딩
총 272개 성격 설명
실제 사용되는 건 ~51개 (엔딩당 3개)
완전히 낭비되는 설명 221개

3개 스토리팩 전체로 보면:

프랑켄슈타인: 12 엔딩 × 16 유형 = 192 설명
오만과 편견: 12 엔딩 × 16 유형 = 192 설명
지킬 박사와 하이드: 비슷한 구조
총: ~560개 설명
실제 사용: ~140개 설명
낭비: ~420개 미사용 설명 (75%)

그리고 이 낭비는 연쇄 반응을 일으킨다:

75% 더 많은 컨텐츠 생성 필요
75% 더 많은 한국어 번역 작업
75% 더 큰 JSON 파일 크기
75% 더 많은 유지보수 및 업데이트 작업

이게 Gemini API가 계속 토큰 한도에 걸린 이유였다. 파일이 너무 비대했던 것.

해결책

간단한 변경:

// 새로운 방식
"ending_warning_attempt": {
  "likelyPersonalities": ["ESFJ", "ENFJ", "ISFJ"],
  "personalityDescriptions": {
    "ESFJ": "**충성스러운 보호자**: 당신의 즉각적인 본능...",
    "ENFJ": "**자비로운 영웅**: 구하려는 시도...",
    "ISFJ": "**헌신적 수호자**: 조용한 충성심...",
    "GENERIC": "**용감한 마음**: 경고하려는 본능..."
  }
}

포함하는 것:

likelyPersonalities에 있는 유형들의 설명 (3-4개)
엣지 케이스를 위한 GENERIC 대체 설명 1개

JavaScript가 대체 처리:

const description = descriptions[userType] ||
                    descriptions['GENERIC'] ||
                    `**${userType}**: 당신의 독특한 선택...`;

누군가 가능성 낮은 유형을 받으면, 일반 설명을 보게 된다. 깨진 경험 없음.

영향

컨텐츠 감소:

개츠비: 272 설명 → 68 설명 (75% 감소)
전체 스토리: ~560 → ~140 설명 (75% 감소)

해제된 혜택:

✅ Gemini API가 이제 완전한 스토리 생성 가능 (토큰 한도 없음)
✅ 더 빠른 페이지 로딩 (작은 JSON 파일)
✅ 75% 적은 한국어 번역 작업
✅ 더 쉬운 유지보수 (업데이트할 설명 감소)
✅ 더 나은 UX (사용자가 타겟팅된 설명 보게 됨, 일반적인 것 아니라)

문서 업데이트:

CLAUDE_StoryPack.md에 최적화된 접근법 명시
personality-calculator.js에 대체 체인 추가
향후 스토리는 자동으로 간결한 구조 사용

배운 것

우리는 하나의 문제를 고치려 했다: 경로당 선택지 부족.

얻은 것:

✅ 선택지 개수 문제 해결 (경로당 10개 이상 강제)
✅ 자동 검증 추가 (배포 전 이슈 감지)
✅ 이미지 최적화 통합 (95% 크기 감소)
✅ 75% 컨텐츠 최적화 발견 (4가지 다른 문제 해결)

때로는 최고의 최적화가 계획이 아니라 사용자 질문에서 나온다.

나는 며칠 동안 컨텐츠 생성 파이프라인을 만들면서, 엔딩마다 16개 유형이 전부 필요한지 의문을 가져본 적이 없었다. “더 완전한” 게 더 나은 것처럼 보였으니까.

사용자가 간단한 질문 하나 했다. 엄청난 낭비가 드러났다.

다음 단계

Phase 1: 완료 ✅

프롬프트 엔지니어링 강화 ✓
경로 검증 로직 ✓
이미지 최적화 ✓
테스트 전략 ✓
성격 최적화 ✓

Phase 2: 기존 스토리 재생성 (다음)

10개 이상 선택지 + 최적화된 성격으로 지킬 박사와 하이드
10개 이상 선택지 + 최적화된 성격으로 프랑켄슈타인
10개 이상 선택지 + 최적화된 성격으로 오만과 편견
한국어 번역 업데이트 (이제 작업량 75% 줄었다!)
모든 스토리 검증

타임라인: Phase 2에 ~5시간, Day 33 마케팅 준비 완료.

빌딩 인 퍼블릭: 가치

Day 21이 가르쳐준 것: 빌딩 인 퍼블릭은 망가진 제품 출시를 막는다.

Day 22가 가르쳐준 것: 사용자 피드백은 당신이 절대 못 볼 최적화를 찾아낸다.

공개적으로 작업을 공유하지 않았다면, 나는:

계속 비대한 JSON을 생성했을 것
Gemini 토큰 한도와 씨름했을 것
75% 더 많은 번역 작업을 했을 것
16개 유형 접근법을 의심하지 않았을 것

사용자 질문 하나가 금을 찾아냈다.

이것이 우리가 빌딩 인 퍼블릭을 하는 이유다.

진행도: Day 22/100 상태: Phase 1 완료, Phase 2 다음 다음 포스트: 품질 개선으로 3개 스토리팩 전부 재생성

GitHub에서 전체 스토리 보기