책을 위한 AI 파이프라인을 구축했습니다, 여기 아키텍처가 있습니다

Source: Dev.to

50 K 권의 책에서 배운 점

대부분의 AI‑글쓰기 도구는 단순히 채팅 래퍼에 불과합니다: 프롬프트를 붙여넣고, 텍스트를 받아서, Google Docs에 복사하고, 반복합니다. 전체 책을 쓰려면 수백 번의 왕복이 필요하고 그 사이에 컨텍스트가 완전히 사라집니다.

저는 AI + 출판 분야에서 3년을 보냈습니다—직접 책을 출판하고, 독서 플랫폼(NanoReads, 130 + 권, 341 K 독자)을 구축했으며, 수백 명의 저자와 이야기를 나눴습니다. 같은 불만이 계속해서 나오곤 했습니다:

• AI는 10장 전 일어난 일을 추적하지 못합니다.
• 각 장마다 톤이 다르게 들립니다.
• 대화가 평면적입니다.
• 출력에 “게다가…”, “더욱이…”, “주목할 점은…” 같은 문구가 가득합니다.

이것은 모델 품질 문제는 아닙니다. 우리 플랫폼(AIWriteBook)에서 5만 권 이상의 책을 생성한 후, 병목 현상이 언어 모델이 아니라 사양 파이프라인에 있다는 확신을 갖게 되었습니다.

아키텍처

We treat book creation as a multi‑stage compilation pipeline:

Book Metadata → Character Graph → Chapter Outlines → Chapter Content
     |               |                  |                  |
  (schema)       (schema)           (schema)          (streaming)

Each stage produces schema‑constrained structured output that feeds the next stage. Nothing is free‑form until the final prose generation.

1단계 – 책 메타데이터

사용자는 제목과 짧은 설명을 제공합니다. AI는 이후 구조화된 메타데이터 객체를 생성하며, 이는 이후 모든 작업의 단일 진실 원천이 됩니다.

{
  "title": "The Dragon's Reluctant Mate",
  "genres": ["Fantasy", "Romance"],
  "tone": ["dark", "romantic", "suspenseful"],
  "style": ["dialogue‑heavy", "fast‑paced"],
  "target_audience": "Adult fantasy romance readers",
  "plot_techniques": ["enemies‑to‑lovers", "slow‑burn", "foreshadowing"],
  "writing_style": "..."
}

톤, 스타일, 그리고 대상 독자는 제약조건이며, 제안이 아닙니다.

2단계 – 캐릭터 그래프

각 캐릭터는 음성, 동기, 아크, 내부 갈등을 포함하는 구조화된 노드입니다. 챕터를 생성할 때 실제로 등장하는 캐릭터와 그들의 현재 아크 위치 및 관계 역학만 전달합니다.

{
  "name": "Kira Ashvane",
  "role": "protagonist",
  "voice": "Sharp, clipped sentences. Uses sarcasm as defense.",
  "motivation": "Prove she doesn't need the dragon clan's protection",
  "internal_conflict": "Craves belonging but fears vulnerability",
  "arc": "Isolation → reluctant alliance → trust → sacrifice"
}

모델이 캐릭터별 명시적인 음성 사양을 받기 때문에, 대화가 더 이상 균일하게 들리지 않습니다.

Source: …

Stage 3 – Chapter Outlines

This is the most important stage. Every chapter gets a detailed spec that guides the downstream generation.

{
  "chapter_number": 3,
  "title": "The Binding Ceremony",
  "events": [
    "Kira is forced to attend the bonding ritual",
    "..."
  ],
  "locations": [
    "Dragon temple, obsidian halls lit by bioluminescent moss"
  ],
  "twists": [
    "The ritual reveals Kira has dormant dragon magic"
  ],
  "character_interactions": [
    {
      "characters": ["Kira", "Draethor"],
      "dynamic": "hostile tension with undercurrent of curiosity"
    }
  ],
  "word_count": 2800
}

Internal A/B Test

상세한 개요를 가진 보통 수준의 모델이 흐릿한 개요를 가진 좋은 모델보다 더 뛰어나다. 소프트웨어 엔지니어링에서처럼 입력이 나쁨 → 출력도 나쁨이다.

Stage 4 – 챕터 생성

The only streaming stage. The model receives:

• 책 메타데이터
• 관련 캐릭터와 음성 사양
• 챕터 개요
• 이전 챕터 요약 (연속성을 위해)
• 저자의 글쓰기 스타일 샘플

We use a 두 모델 전략:

1. Gemini Flash – 모든 구조 작업을 처리합니다 (빠르고 저렴하며 스키마 제약 출력에 뛰어납니다).
2. Frontier model – 최종 산문을 생성합니다.

보이스 트레이닝

저자들은 3–5개의 글 샘플을 업로드할 수 있습니다. 우리는 스타일 특징을 추출하고 이를 생성 과정에서 few‑shot 예시로 제공합니다.

우리 데이터의 결과:

• 2.4 × 높은 내보내기 비율을 보이스 트레이닝으로 달성했습니다.
• 41 % 적은 재생성 요청.
• 67 % 감소된 수동 편집.

샘플이 세 개 미만이면 → 미미한 개선.
샘플이 다섯 개 초과이면 → 수익 감소.

보이스 트레이닝 없이 출력은 일반적인 GPT와 같아 보이며, 저자들은 프로젝트를 포기하거나 수시간을 들여 다시 작성합니다. 보이스 트레이닝을 사용하면 모델에 스타일에 대한 구체적인 기준이 생겨 “AI 슬롭” 문제는 크게 사라집니다.

Source: …

소설 vs. 논픽션 파이프라인

소설

위에서 설명한 character graph + plot‑continuity 파이프라인을 사용합니다.

논픽션

참고 자료에서 시작하는 별도의 아키텍처입니다.

Reference Files → Content Extraction → Book Structure Selection
                                   |
                     Chapter Outlines (with assigned references)
                                   |
                     Chapter Content (with citations)

참고 자료의 영향

모델이 구체적인 데이터—예: 명시된 연구, 실제 인용문, 특정 통계—를 갖추면 훨씬 더 신뢰할 수 있고 만족스러운 논픽션을 생성합니다.

주요 내용

1. 사양이 모델 크기보다 더 중요합니다. 자세하고 스키마‑기반 파이프라인이 단순히 LLM을 확장하는 것보다 더 높은 품질을 제공합니다.
2. 캐릭터별 음성 사양이 평범한 대화를 방지합니다.
3. 챕터 개요는 일관성, 연속성 및 저자 만족도를 위한 가장 큰 지렛대입니다.
4. 소수 샷 음성 훈련은 생성 후 편집을 크게 감소시킵니다.
5. 논픽션은 초기 단계에서 인용 및 참고 자료를 삽입하는 데이터 중심 파이프라인이 필요합니다.

책 생성 과정을 컴파일러처럼 다루면—metadata → graph → outline → stream—혼란스러운 “프롬프트‑그리고‑희망” 워크플로우를 예측 가능하고 반복 가능한 생산 라인으로 바꿀 수 있습니다.

5만 권의 책에서 배운 점

챕터 길이 최적 범위는 2,000‑3,500 단어입니다.

• 이보다 짧으면 챕터가 미완성된 느낌을 줍니다.
• 3,500자를 초과하면 모델이 다른 표현으로 반복하고, 탈선적인 내용이나 불필요한 설명을 늘립니다.
• 5,000자를 넘으면 품질이 크게 떨어집니다. 챕터가 길어야 한다면, 하나의 긴 챕터를 만들기보다 나눠서 작성하는 것이 좋습니다.

장르가 크게 영향을 미칩니다

AI는 확립된 관습과 풍부한 학습 데이터를 가진 장르에서 가장 좋은 성능을 보이며, 목소이에 크게 의존하고 매우 창의적인 글쓰기에서는 어려움을 겪습니다.

생성된 책 중 오직 23 %만이 출판을 위해 내보내집니다.

성공적인 책들은 다음과 같은 특징을 공유합니다:

• 개요 편집에 3.2배 더 많은 시간 투자
• 74 %의 경우에 음성 훈련이 활성화됨
• 89 %의 챕터에서 최소 한 번 이상의 수동 편집이 이루어짐

출판에 이르는 책들은 반복적인 작업을 거치며, 한 번의 클릭으로 바로 생성된 것이 아닙니다.

다국어 품질은 다양합니다

• 스페인어, 프랑스어, 독일어는 영어 품질에 근접합니다.
• 폴란드어, 러시아어, 일본어, 한국어는 괜찮지만 눈에 띄게 낮습니다.
• 소규모 언어는 초안 작성에 사용할 수 있습니다.

품질은 학습 데이터 양과 상관관계가 있습니다. 대표성이 낮은 언어의 저자들은 영어로 생성한 뒤 번역하는 것이 원어로 직접 생성하는 것보다 더 좋은 결과를 얻는 경우가 많습니다.

스택

• 프론트엔드: Next.js, Tailwind, Supabase 클라이언트
• 백엔드: Supabase Edge Functions (Deno)
• AI: Gemini Flash (구조적), Frontier 모델 (문장)
• 언어: 30개 이상 지원

마무리

우리가 이 작업을 통해 얻은 가장 큰 교훈: AI‑생성 책의 품질 문제는 사양 문제이며, 모델 문제는 아니다.

• 애매한 프롬프트 + “generate” → 형편없음.
• 상세한 캐릭터 그래프, 구조화된 개요, 음성 샘플, 그리고 적절한 제약조건 → 실제로 좋은 결과물.

시도해 보고 싶다면, 전체 7‑챕터 책을 제공하는 무료 티어가 있습니다.

아키텍처, 데이터, 혹은 AI + 출판에 관한 질문에 기꺼이 답변해 드립니다.

Tags: #ai #writing #books #showdev #webdev #productivity