20일: 우리가 만든 것

종합 회고 시간이다. What If Classics를 만든 20일 동안 무슨 일이 있었는지 정리해봤다.

출시한 것:

  • 3개의 완성된 스토리팩 (지킬 앤 하이드, 프랑켄슈타인, 오만과 편견)
  • 완전한 한영 지원 (네이티브 품질의 한국어 산문)
  • 267개 페이지 생성 (스토리 + 블로그 + 라이브러리)
  • 109개 최적화된 이미지 (70-85% 크기 감소)
  • 23분 자동화 생성 파이프라인
  • 20개의 공개 개발 블로그 포스트

원래 100일 계획과 비교:

  • MVP는 Day 30 계획 → Day 14에 완성 (16일 앞서)
  • 1개 스토리팩 예상 → 3개 제작 (목표 대비 300%)
  • 한국어 지원은 Day 50-58 계획 → Day 16에 완료
  • 이미지 최적화는 Day 66-72 계획 → Day 20에 완료

속도: 모든 게 “일정보다 며칠 앞서”로 측정됐다.

핵심 학습 (Days 1-20)

이 속도로 개발하면서 몇 가지 귀중한 교훈을 얻었다.

1. AI 프롬프트 엔지니어링 “엔딩 8개 만들어줘” → 3개 생성됨. “최소 12개 엔딩 (타협 불가)” → 12개 생성됨. 교훈: AI는 정중한 제안이 아니라 명시적 제약이 필요하다.

2. 네이티브 콘텐츠 > 번역 한국어 API 번역은 돈이 들고 기계적인 텍스트를 만들어냈다. Claude Code를 통한 네이티브 생성은 $0이고 자연스러운 산문을 만들어냈다. 교훈: 문화적 콘텐츠는 네이티브 생성에 투자하라.

3. 개발자 맹점 몇 주 동안 만들었지만 명백한 UX 문제를 못 봤다 (읽을 수 없는 코드 블록, 사라진 버튼). 교훈: 자신의 UX 문제는 볼 수 없다.

4. Windows UTF-8 지옥 한국어 Windows는 cp949 인코딩이 기본이다. 5개 이상의 Python 스크립트에서 이 버그를 고쳤다. 교훈: Windows에서는 항상 인코딩을 명시적으로 지정하라.

5. 성능은 선택이 아니다 Day 20까지 215MB의 최적화되지 않은 PNG를 서빙했다. Astro의 Image 컴포넌트가 3줄의 코드로 ~50MB로 줄여줬다. 교훈: 이미지 최적화는 첫날부터 구현하라.

그리고 숫자를 확인했다

대시보드에서는 모든 게 훌륭해 보였다. 하지만 회고를 하면서 제품을 비판적인 시각으로 실제로 테스트해봤다.

스토리 경로 분석 스크립트를 돌렸다.

선택지 1개로 하는 성격 테스트

우리의 핵심 기능은 스토리 선택을 기반으로 한 MBTI 성격 분석이다. 사람들이 소셜미디어에 공유할 바이럴 요소가 될 거라고 생각했다.

프랑켄슈타인 스토리를 분석 스크립트로 돌려봤다:

경로당 선택지 수:
  최소: 1개
  최대: 6개
  평균: 3.7개

문제: 12개 경로 중 9개가 5개 미만의 선택지

선택지 1개.

누군가에게 “이 한 가지 결정으로 당신은 INTJ입니다”라고 말한다고 상상해보라. 비웃을 것이다. 나도 그럴 거다.

왜 문제인가

MBTI는 4개의 차원(E/I, S/N, T/F, J/P)이 있다. 최소한의 신뢰성을 갖추려면 각 차원당 최소 2-3번의 측정이 필요하다. 즉 최소 8-12개의 선택지가 필요하다.

우리는 경로당 1-6개의 선택지를 가지고 있다. 수학적으로 부족한 정도가 아니라 창피한 수준이다.

스토리 경로의 75%가 최소 신뢰성 기준을 통과하지 못한다.

무엇이 잘못됐나

우리는 잘못된 지표를 최적화했다:

  • ✅ “스토리당 12개 이상의 엔딩” - 달성!
  • ✅ “수렴하지 않는 분기” - 달성!
  • ✅ “3-5분 플레이 타임” - 달성!
  • ❌ “신뢰할 수 있는 성격 분석을 위한 충분한 선택지” - 완전히 놓침

속도가 품질을 가렸다. 계획했던 1개 스토리를 만드는 시간에 3개를 만들었지만, 그 어느 것도 원래 목적대로 작동하지 않는다.

해결책

경로당 최소 10개의 선택지. 타협 불가.

이것의 의미:

  1. 엄격한 검증 로직을 갖춘 스토리 생성기 재작성
  2. 기존 3개 스토리 전체 재생성
  3. 플레이 타임을 5-7분으로 확장
  4. 런칭 전 실제 사용자 테스트

일정: 모든 것을 제대로 고치는 데 11일.

마케팅 지연: Day 21에서 Day 33으로.

왜 이걸 공유하나

공개적으로 만들기(Building in Public)는 성공만이 아니라 실패도 공유하는 것이다.

배운 것:

  • 품질 검증 없는 속도는 무가치하다
  • 지표가 근본적인 문제를 숨길 수 있다
  • 사용자 테스트는 대시보드가 보여주지 못하는 것을 드러낸다
  • 마케팅 후보다 지금 발견하는 게 낫다

공개 개발이 막아준 것: 말 그대로 하루만 지나면 소셜미디어 계정을 만들고 망가진 제품을 홍보하기 시작할 뻔했다. 회고 작업이 실제로 데이터를 보도록 강제했다.

지금 품질을 고치는 데 11일을 쓰는 것이, 아무도 진지하게 받아들이지 않을 제품을 마케팅하는 데 몇 달을 낭비하는 것보다 낫다.

20일이 실제로 증명한 것

기술적 역량 (검증됨 ✅):

  • 빠른 콘텐츠 생성 (스토리당 23분)
  • 품질 관리가 있는 자동화 파이프라인
  • 네이티브 품질의 한영 경험
  • 대규모 성능 최적화

제품 품질 (실패 ❌):

  • 핵심 MBTI 기능이 제대로 작동하지 않음
  • 지표는 성공을 보여줬지만, 현실은 실패를 보여줌
  • 속도가 근본적인 품질 문제를 가렸음

수정된 계획

Days 1-20: 빠른 인프라 구축 Days 21-32: 핵심 제품 품질 수정 (11일 지연) Days 33+: 확신을 갖고 마케팅

사람들이 비웃을 제품을 일찍 런칭하는 것보다 품질 있는 제품을 늦게 런칭하는 게 낫다.

공개 개발은 승리와 실패를 모두 보여주는 것이다.