본문으로 건너뛰기
PromptQuorum인간을 위해 설계. AI를 위해 구조화.
홈/고급 로컬 LLM
Creative & Roleplay

로컬 LLM으로 소설과 시나리오 집필하기: 10만 단어 이상을 위한 워크플로 가이드

·15분 분량Hans Kuepper 저 · PromptQuorum 창립자 · 오픈 웨이트·오픈소스 AI 디스커버리 엔진

로컬 LLM으로 장문 소설을 쓸 때의 핵심 과제는 컨텍스트 관리입니다. 1회 생성당 약 32,000 토큰으로 계획하고, 원고 전체 대신 압축한 "세션 문서"(인물 카드, 챕터 요약, 현재 장면 설정)를 주어 한 번에 한 장면씩 생성하십시오.

핵심 요점

  • 컨텍스트 윈도 계획 기준: 명목상 128K–262,144 토큰, 계획은 약 32K. 모델은 긴 입력의 중간을 덜 안정적으로 활용하므로("Lost in the Middle") 1회 생성당 약 32K 토큰(약 24,000 단어)으로 계획하고, 전체 원고 대신 세션 문서 기법을 사용하십시오.
  • 세션 문서 기법이 핵심 기술입니다. 활성 인물 카드(인물당 150 단어), 챕터 요약(완료된 챕터당 100–200 단어), 현재 장면 설정을 담은 압축 텍스트 파일을 유지하십시오. 매 생성 세션 시작 시 주입하십시오.
  • 한 번에 한 장면을 생성하십시오. 성장하는 문서를 "이어 쓰도록" 요청하는 대신, 세션당 하나의 장면(200–600 단어)을 작성하도록 모델에 요청하십시오. 세션당 한 장면은 컨텍스트 이탈을 줄이고 일관된 목소리를 유지하는 데 도움이 됩니다.
  • 시나리오는 beat sheet 우선으로 시작하십시오. 스크립트 페이지를 생성하기 전에 장면 수준의 beat sheet를 먼저 생성하십시오. 이를 각 페이지 생성의 스캐폴드로 활용하십시오.
  • 실행할 수 있는 모델을 고르고, 본인의 장면으로 시험해 보십시오. 27B–31B급 dense 모델(Qwen3.6 27B, Gemma 4 31B)과 Llama 3.3 70B가 흔한 출발점입니다. PromptQuorum은 이 중 어느 것도 소설용으로 평가하지 않았으며, 공개된 창작 글쓰기 리더보드도 모델 순위가 서로 다릅니다.
  • Ollama + 일반 텍스트 집필 도구는 안정적인 통합입니다. Scrivener, Obsidian, VS Code가 원고를 담을 수 있으며, Ollama는 앱이나 스크립트가 호출할 수 있는 API를 통해 모델을 제공합니다.
  • 거부가 적은 모델(Hermes 4 70B)은 설정 변경 없이 이 워크플로에 적합합니다. 성숙한 소설을 위해 Ollama 모델만 전환하면 되며, 세션 문서 및 장면 생성 기법은 동일합니다. 용도에 맞는지 모델별 라이선스를 확인하십시오.
언어 선택:
🇺🇸en🇩🇪de🇫🇷fr🇯🇵ja🇨🇳zh🇪🇸es🇧🇷pt🇸🇦ar🇰🇷ko

소설이나 시나리오 집필 워크플로에 통합된 로컬 LLM은 인터넷 접속, 클라우드 로그, 사용량 제한 없이 장면 초안, beat sheet, 대화 검토, 수정 라운드를 생성할 수 있습니다. 이 가이드는 모델 선택, 장문 작업을 위한 컨텍스트 윈도 관리, 챕터별 스캐폴딩, 장면 생성, 그리고 로컬 LLM을 집필 소프트웨어와 연결하는 도구들을 포함한 전체 워크플로를 다룹니다.

로컬 LLM으로 소설과 시나리오 집필하기: 10만 단어 이상을 위한 워크플로 가이드

빠른 사실

  • 모델 출발점(모델 카드 기준): Qwen3.6 27B(dense, Apache-2.0, 262,144 토큰 컨텍스트), Gemma 4 31B(dense, Apache-2.0, 256K 컨텍스트), Llama 3.3 70B(dense, 128K 컨텍스트, Llama 3.3 Community License).
  • 컨텍스트 윈도 계획 상한: 1회 생성당 ~32K 토큰(~24,000 단어); 모델은 128K–262,144 토큰을 내세우지만 이는 상한일 뿐 품질 보증이 아닙니다.
  • 세션 문서 크기: 4,000 토큰 미만 목표 (인물 카드 + 챕터 요약 + 현재 장면 설정).
  • 장면 생성 목표: 생성 호출당 200–600 단어; 더 긴 장면은 여러 순차 프롬프트를 통해 생성합니다.
  • 시나리오 형식: Fountain 형식 출력 지시와 함께 Ollama를 사용하면 스크립트 형식의 텍스트를 생성합니다.
  • Ollama와 함께 작동하는 집필 도구: Scrivener (출력 붙여넣기; 문서화된 플러그인 API 없음), Obsidian (로컬 플러그인 또는 스크립트를 통해), VS Code (Continue.dev 또는 직접 API 호출을 통해), 순수 터미널.
  • 거부가 적은 옵션: 성숙한 소설을 위한 Hermes 4 70B(Llama-3.1-70B 기반); 동일한 워크플로, 동일한 세션 문서 기법.

장문 집필을 위한 컨텍스트 윈도 문제

모델이 훨씬 큰 윈도를 내세우더라도 1회 생성당 약 32K 토큰으로 계획하십시오. 이는 PromptQuorum의 보수적인 계획 규칙이며 측정된 한계가 아닙니다. 긴 컨텍스트 연구(Liu 외, "Lost in the Middle")에서는 모델이 긴 입력의 처음과 끝에 있는 정보를 중간에 있는 정보보다 더 안정적으로 활용하고, 입력이 길어질수록 품질이 떨어질 수 있다고 보고되어 있습니다. 새 모델은 훨씬 큰 윈도를 내세우므로 — Qwen3.6 27B는 네이티브 262,144 토큰, Gemma 4 31B는 256K — 사용하는 모델을 직접 시험해야 합니다. 소설의 경우, 지금까지의 원고를 붙여넣고 다음 챕터를 요청하는 방식은 여전히 가장 신뢰하기 어려우며, 긴 컨텍스트는 KV 캐시가 함께 커지기 때문에 메모리도 더 많이 사용합니다.

Moonshot AI의 Kimi-K2.6은 256K 토큰(262,144)의 컨텍스트 윈도를 내세워 위 모델들과 같은 급이지만, 총 파라미터 약 1조 개(활성 320억 개)의 Mixture-of-Experts 모델이며 네이티브 int4 가중치로 제공됩니다. 4비트에서도 가중치만 약 500 GB가 되므로(PromptQuorum 추정: 1조 파라미터 × 0.5바이트) 노트북용이 아니라 서버급 모델입니다. 세션 문서 기법과 장면별 생성은 컨텍스트 크기와 관계없이 로컬에서 실행 가능한 모델에 적용됩니다.

📍 한 문장으로

로컬 LLM에서 컨텍스트 준수의 보수적인 계획 상한은 1회 생성당 약 32,000 토큰(~24,000 단어)입니다 — 이를 초과하면 긴 컨텍스트 연구에서는 이전 콘텐츠의 활용이 덜 안정적이라고 보고되어 있으며, 장편 원고 전체에 걸쳐 목소리 이탈과 줄거리 불일치로 나타날 수 있습니다.

💬 쉽게 말하면

원고 전체가 컨텍스트 윈도에 들어간다고 해서 모델이 챕터 20을 쓰면서 챕터 3에서 무슨 일이 있었는지 기억할 것이라고 기대할 수는 없습니다. 대신, 모델이 알아야 할 것들 — 인물 카드, 챕터 요약, 현재 장면 설정 — 을 4,000 토큰 미만의 "세션 문서"로 압축하고, 매 집필 세션 시작 시 그것을 주입하십시오. 모델은 현재 생성 중인 장면과 관련된 것만 알면 됩니다.

  • 토큰-단어 변환: 1 토큰 ≈ 영어 기준 0.75 단어(경험칙). 32K 토큰 ≈ 24,000 단어. 128K 토큰 ≈ 96,000 단어(소설 한 편 정도); 262,144 토큰 ≈ 196,000 단어.
  • 어텐션 저하: 모델은 긴 컨텍스트 윈도의 초반부 콘텐츠에 대한 신뢰할 수 있는 참조를 잃을 수 있습니다. 이는 인물 이름 오류, 잊혀진 줄거리 포인트, 확립된 어조에서의 목소리 이탈로 나타납니다.
  • 비대칭성: Lost in the Middle 연구에서 모델은 입력의 처음과 끝을 가장 잘 활용했고 중간의 콘텐츠는 가장 덜 안정적으로 활용했습니다. 이 연구는 2023년에 쓸 수 있던 모델을 대상으로 했으므로, 같은 패턴을 가정하지 말고 현재 모델을 직접 시험하십시오.
  • 해결책으로서의 세션 문서: 모델이 필요한 모든 것을 짧은 구조화 문서로 압축하십시오. 시작 시 주입하십시오. 장면을 생성하십시오. 세션을 종료하십시오. 재시작하십시오. 새 장면을 반영하도록 업데이트된 동일한 세션 문서로 다시 시작하십시오.
컨텍스트 계획: 작업 상한 32K 토큰(약 24,000단어), 오픈 모델은 128K–262,144 토큰을 내세움.
컨텍스트 계획: 작업 상한 32K 토큰(약 24,000단어), 오픈 모델은 128K–262,144 토큰을 내세움.

⚠️경고: 전체 원고를 컨텍스트에 붙여넣지 마십시오. 소설이 10,000 단어를 초과한 상태에서 전체 초안을 붙여넣고 다음 챕터를 요청하면 컨텍스트 이탈의 위험이 있습니다 — 모델이 초기 인물 세부 사항을 잊고, 확립된 줄거리 포인트와 모순되며, 일반적인 어조로 돌아갈 수 있습니다. 세션 문서 기법을 사용하십시오.

세션 문서 기법

세션 문서 기법은 위에서 설명한 컨텍스트 한계를 바탕으로 한 PromptQuorum의 워크플로 권장 사항입니다. PromptQuorum은 통제된 시험을 하지 않았으며, 아래 크기(4,000 토큰, 인물 카드당 150 단어, 챕터 요약당 100–150 단어)는 계획용 가이드라인이지 측정된 임계값이 아닙니다.

세션 문서는 원고 옆에 보관하는 일반 텍스트 파일로, 모델이 일관된 콘텐츠를 생성하기 위해 알아야 하는 소설의 압축 상태입니다. 세 섹션으로 구성됩니다: 활성 인물 카드, 챕터 요약, 현재 장면 설정.

세션 문서 템플릿

“# SESSION DOCUMENT — [NOVEL TITLE] ## ACTIVE CHARACTERS [Character Name] Dominant trait: [one trait] Contradicting behaviour: [one behaviour] Speech register: [formal/casual/specific verbal tics] Relationship to [other character]: [brief] [Character Name 2] [same structure] ## CHAPTER SUMMARIES (completed) Chapter 1: [100–150 words — what happened, what changed, where it ended] Chapter 2: [100–150 words] [continue for all completed chapters] ## CURRENT SCENE SETUP Chapter: [N] Scene: [brief description of what this scene needs to accomplish] POV: [character name] Opening state: [where we are at the start of this scene — 1 sentence] Emotional beat to land on: [what the POV character feels at the end — do not state it directly in the scene] Word ceiling: [200–500 words]”
  • 인물 카드 — 활성 인물당 150 단어 목표. 지배적 특성, 모순적 행동, 말하기 방식, 다른 활성 인물들과의 핵심 관계를 포함하십시오. 인물이 활성화되거나 원고에서 떠날 때 추가하거나 제거하십시오.
  • 챕터 요약 — 완료된 챕터당 100–150 단어 목표. 다음에 집중하십시오: 무슨 일이 있었는지, 인물 관계에서 무엇이 변했는지, 독자가 이제 알고 있는 정보, 챕터가 공간적·정서적으로 어디서 끝났는지. 모든 장면을 포함하지 말고 챕터의 순결과를 요약하십시오.
  • 현재 장면 설정 — 구체적이고 간결하게. 시점, 장면의 목적(이야기에서 달성해야 할 것), 도달해야 할 정서적 beat, 단어 상한을 명시하십시오. 이것이 모델이 취하는 행동이며, 인물 카드와 챕터 요약은 모델이 일관되게 수행하기 위해 사용하는 컨텍스트입니다.
  • 세션 문서 크기 — 4,000 토큰(~3,000 단어) 미만 목표. 이를 초과하는 세션 문서는 생성 자체에 사용되어야 할 컨텍스트 공간을 소비하기 시작합니다. 인물 카드와 요약을 적극적으로 압축하십시오.
  • 매 세션 후 업데이트하십시오. 장면을 생성한 후, 관련 챕터 요약에 1–2 문장 업데이트를 추가하고 변경된 인물 카드 항목을 업데이트하십시오. 세션 문서는 살아있는 파일이며, 업데이트 상태를 유지하는 것이 이 기법의 유지 비용입니다.

💡팁: 세션 문서를 원고 옆에 일반 텍스트 파일로 저장하십시오. 각 집필 세션 후, 다음 세션의 시스템 메시지 또는 첫 번째 사용자 턴에 세션 문서를 복사하여 붙여넣으십시오. Ollama에서는 SYSTEM 블록에 세션 문서가 포함된 Modelfile을 생성하고 매 세션 전에 업데이트할 수 있습니다. SillyTavern에서는 각 소설 세션 시작 시 시스템 프롬프트 필드에 붙여넣으십시오.

소설 집필 워크플로

로컬 LLM을 사용한 소설 집필 워크플로는 네 단계로 구성됩니다: 개요 작성, 챕터별 beat sheet, 장면 생성, 수정 검토. 각 단계는 서로 다른 프롬프트 구조를 사용합니다.

  • 1단계 — 개요 작성: 챕터 수준의 개요를 생성합니다 (10–30 챕터, 챕터당 한 문장: 무슨 일이 일어나는지, 무엇이 변하는지). 프롬프트: "장르: [장르]. 주인공: [이름 + 핵심 상처]. 중심 갈등: [한 문장으로]. 20챕터 개요를 작성하라 — 챕터당 한 문장, 각 문장은 장면과 변화를 명시한다." 계속 진행하기 전에 개요를 검토하고 편집하십시오.
  • 2단계 — Beat sheet: 각 챕터 항목을 장면 수준의 beat sheet로 확장합니다 (챕터당 3–8 장면). 챕터별 프롬프트: "챕터 [N] 요약: [개요에서 한 문장 붙여넣기]. 장면 수준의 beat sheet로 확장하라: 4–6 장면, 각각 위치, 참여자, 장면의 단일 변화를 명시하는 한 문장으로 설명한다. 아직 산문은 없음."
  • 3단계 — 장면 생성: 세션 문서 + 현재 장면 beat를 사용하여 한 번에 한 장면을 생성합니다. 아래의 장면 생성 템플릿을 참조하십시오. 생성하고, 검토하고, 원고에 붙여넣고, 세션 문서를 업데이트하십시오. 반복하십시오.
  • 4단계 — 수정 검토: 챕터를 완료한 후, 특정 장면에 대해 구체적인 수정 프롬프트를 실행합니다. 수정 프롬프트 구조는 소설 작가를 위한 로컬 LLM 프롬프트를 참조하십시오. 생성 호출당 두 장면 이상 수정하도록 모델에 요청하지 마십시오.
로컬 LLM 소설 집필 4단계: 개요, beat sheet, 장면 생성, 수정. 세션 문서를 중심으로 진행.
로컬 LLM 소설 집필 4단계: 개요, beat sheet, 장면 생성, 수정. 세션 문서를 중심으로 진행.

💡팁: 개요와 beat sheet를 원고와 별도 파일로 저장하십시오. 개요와 beat sheet는 뼈대이고 원고는 살입니다. 별도로 유지하면 다른 것을 덮어쓰지 않고 어느 부분이든 재생성할 수 있으며, 전체 개요를 포함하지 않고 현재 장면 설정에 관련 beat sheet 항목만 붙여넣을 수 있습니다.

시나리오 워크플로

로컬 LLM을 사용한 시나리오 집필은 소설 집필과 동일한 세션 문서 및 beat sheet 기법을 사용하며, 두 가지가 추가됩니다: 시스템 프롬프트의 형식 지시, 그리고 장면 헤더(slug line)를 페이지 생성과 별도의 단계로 생성하는 것입니다.

시나리오 시스템 프롬프트

“You are a screenplay formatting assistant. All prose you generate is formatted in standard US screenplay format: - Scene headers: INT./EXT. LOCATION — DAY/NIGHT - Action lines: present tense, concrete, maximum 3 lines per block - Character names: ALL CAPS above dialogue - Dialogue: centred, no dialogue tags - Parentheticals: sparingly, only for delivery or action mid-dialogue Generate in Fountain-compatible plain text.”

장면 beat에서 스크립트 페이지로 변환하는 프롬프트

“Beat: [paste the one-sentence scene beat from the beat sheet] POV character: [Name] Page target: [1–3 pages] Generate the script pages for this beat. Use standard screenplay format. Begin with the slug line. No narration — action lines and dialogue only.”
  • 형식은 사용자 턴이 아닌 시스템 프롬프트에 넣으십시오. 시스템 메시지에 시나리오 형식 지시를 배치하면 지시를 반복하지 않고도 세션의 모든 생성이 형식을 따르게 됩니다.
  • Fountain 호환 출력: Fountain은 시나리오용 일반 텍스트 마크업 형식으로, Highland와 Fade In 및 Fountain 앱 목록의 다른 앱이 읽을 수 있습니다. "Fountain 호환 일반 텍스트"를 생성하도록 모델에 요청하면 해당 도구에서 열거나 다른 도구용으로 변환할 수 있는 출력이 생성됩니다(FAQ의 Final Draft 질문 참조).
  • Slug line 먼저: 장면 콘텐츠를 생성하기 전에 slug line(INT./EXT. 위치 — 낮/밤)을 별도의 단일 행 프롬프트로 생성하십시오. 이렇게 하면 모델이 액션을 생성하기 시작하기 전에 물리적 위치가 고정됩니다.
  • 대화 검토: 액션 라인을 생성한 후, 별도의 대화 검토를 실행하십시오: "액션 라인이 설정되었습니다. 이 장면에서 [인물 A]와 [인물 B]의 대화를 작성하라. 인물 A는 [X]를 원한다. 인물 B는 [Y]를 원한다. 대화 태그 없음. 5–8 교환."
  • 페이지 수 관리: 페이지당 단어 수에는 정해진 수치가 없으며, "한 페이지는 1분"은 경험칙일 뿐입니다. 본인 시나리오의 페이지당 평균 단어 수를 세어 그에 맞춰 단어 상한을 정하십시오.

💡팁: Beat sheet 우선 규율은 소설 집필보다 시나리오 집필에서 더 중요합니다. 시나리오 장면은 특정 구조적 기능(설정, 대결, 결정, 전환)과 특정 페이지 목표를 가집니다. Beat sheet 없이 페이지를 생성하면 분량이 늘어나고 구조적 목적을 잃는 장면이 만들어집니다. 페이지를 생성하기 전에 항상 장면이 달성해야 할 것을 파악하십시오.

장문 작업을 위한 장면 생성 템플릿

장문 장면 생성은 세션 문서를 접두사로, 단일 장면 프롬프트를 액션으로 필요로 합니다. 아래 템플릿은 세션 문서가 이미 시스템 메시지 또는 첫 번째 사용자 턴에 있다고 가정합니다.

📍 한 문장으로

장문 소설을 위한 신뢰할 수 있는 생성 패턴은 다음과 같습니다: 시스템 프롬프트의 세션 문서 → 사용자 턴의 단일 장면 프롬프트 → 검토 → 세션 문서 업데이트 → 반복, 세션당 한 장면.

💬 쉽게 말하면

모델이 다음 장면을 일관되게 작성하려면 세 가지를 알아야 합니다: 이 인물들이 누구인지(인물 카드), 이미 무슨 일이 있었는지(챕터 요약), 이 장면이 무엇을 해야 하는지(장면 설정). 정확히 그 세 가지만 주고 그 이상은 주지 마십시오. 그런 다음 장면을 생성하고 원고에 붙여넣고 무엇이 변했는지 반영하여 세션 문서를 업데이트하십시오. 반복하십시오.

소설 장면 생성 프롬프트

“[SESSION DOCUMENT ALREADY IN SYSTEM PROMPT] Current scene: Chapter: [N] Beat: [one sentence from the beat sheet] POV: [character name] Opening: [one sentence — where we are, who is present] Emotional landing: [what the POV character feels at the end — show, don't state] Word ceiling: [300–500 words] Write this scene. No summarising. Every sentence renders a moment.”

연속성 확인 프롬프트

“Before writing the next scene, check for continuity. The session document says: - [Character A] is [trait/state] - The last scene ended with [brief description] The next scene opens with [brief description]. Does this transition make sense? If not, what needs to change in the transition? One paragraph answer only.”

💡팁: 연속성 확인 프롬프트는 모든 장면이 아닌 챕터 전환 시 사용하십시오. 챕터 전환(위치, 시간 또는 시점 인물이 변경되는 곳)은 연속성 단절이 가장 자주 발생하고 확인이 가장 큰 가치를 제공하는 곳입니다.

작가를 위한 도구 통합

Ollama는 로컬호스트에서 OpenAI 호환 API를 노출하며, 점점 더 많은 작가 지향 도구들이 이에 연결됩니다. 아래 통합은 2026년 기준 가장 확립된 옵션을 나타냅니다.

Obsidian

링크:
obsidian.md
통합 방법:
Copilot 플러그인 또는 Smart Connections → Ollama API. 어떤 Obsidian 플러그인이 Ollama와 가장 잘 작동하는지에 대한 상세 가이드는 Obsidian + 로컬 LLM 플러그인을 참조하십시오.
적합한 경우:
이미 노트 + 원고에 Obsidian을 사용하는 작가; 컨텍스트 전환 없이 동일한 앱에서 통합 생성

Scrivener

링크:
literatureandlatte.com/scrivener
통합 방법:
Ollama API를 통한 외부 스크립트 → 문서에 붙여넣기
적합한 경우:
Scrivener에서 소설을 구조화하는 작가; AI 초안을 기존 프로젝트 구조에 붙여넣기

VS Code

링크:
code.visualstudio.com
통합 방법:
Continue.dev 확장 → Ollama 백엔드
적합한 경우:
코드 편집기에 익숙한 기술적 작가와 게임 내러티브 디자이너

SillyTavern

링크:
github.com/SillyTavern/SillyTavern
통합 방법:
OpenAI 호환 API → Ollama
적합한 경우:
롤플레이 유형 소설 및 인물 카드 기반 집필; 지속적인 인물 기억
SillyTavern 관련 문서 (10개)

표시되지 않은 7개 더보기

순수 터미널

링크:
—
통합 방법:
`ollama run [model]` 또는 Ollama API에 curl
적합한 경우:
스크립트 가능한 워크플로; 최소한의 인터페이스 오버헤드로 최대 제어를 원하는 작가

LM Studio

링크:
lmstudio.ai
통합 방법:
내장 채팅 인터페이스 + 로컬 서버 API
적합한 경우:
Ollama를 별도로 설치하지 않고 GUI 모델 관리자를 원하는 작가
LM Studio 관련 문서 (10개)

표시되지 않은 158개 더보기

NovelCrafter

링크:
novelcrafter.com
통합 방법:
내장 AI 통합; 도움말 페이지에 LM Studio, Ollama, OpenAI API 호환 연결이 나열되어 있음
적합한 경우:
단일 소설 중심 앱 내에서 챕터 수준의 AI 지원을 원하는 작가

Plottr

링크:
plottr.com
통합 방법:
수동 워크플로: Plottr에서 소설 구조화, 외부적으로 Ollama에 장면/beat 붙여넣기 (Plottr는 AI 기능을 추가하지 않는다고 밝힘)
적합한 경우:
플롯 집약적 장르 소설(미스터리, 스릴러, 판타지)로 구조적 플롯 매핑이 워크플로의 축인 경우

💡팁: 대부분의 작가에게 작동하는 가장 간단한 통합은 Ollama를 가리키는 Obsidian + Copilot 플러그인입니다. 세션 문서는 Obsidian 노트에 있고, 원고 챕터는 동일한 vault에 있으며, 컨텍스트 전환 없이 동일한 앱에서 직접 생성합니다. Copilot 플러그인은 선택한 텍스트 또는 현재 노트를 Ollama에 전달하고 인라인으로 완성을 반환합니다. 상세 가이드는 Obsidian + 로컬 LLM 플러그인을 참조하십시오.

장문 작업을 위한 모델 추천

장문 집필은 단편 소설과 다른 모델 요구 사항을 가집니다. 컨텍스트 준수, 긴 세션에 걸친 일관된 지시 따르기, 여러 생성 호출에 걸쳐 목소리를 유지하는 능력이 결정적 요소입니다. 아래 행은 각 모델 카드에서 가져온 출발점이며, PromptQuorum은 이 모델들을 소설용으로 평가하지 않았습니다. 공개된 창작 글쓰기 리더보드도 모델 순위가 서로 다르므로, 본인의 장면으로 두 후보를 시험하십시오. Command A+(총 파라미터 2,180억 개, 활성 250억 개, Apache 2.0)와 Mistral Large 3(총 파라미터 6,750억 개, 256K 컨텍스트, Apache 2.0) 같은 서버급 오픈 모델은 소비자용 하드웨어의 범위를 벗어납니다. 모든 사용 사례에 걸친 더 넓은 모델 환경에 대해서는 2026년 최고의 로컬 LLM을 참조하십시오.

소설 집필 (주요)

추천 모델:
Qwen3.6 27B 또는 Gemma 4 31B
이유:
256K 이상의 컨텍스트를 내세우는 Apache 라이선스의 27B–31B dense 모델; 4비트에서 24 GB GPU 또는 32 GB 이상 통합 메모리에 맞는 크기급(추정)

시나리오 집필

추천 모델:
Qwen3.6 27B 또는 Llama 3.3 70B
이유:
형식 준수는 주로 시스템 프롬프트에 달려 있음; Fountain 장면 하나를 두 모델로 시험. Llama 3.3 70B는 dense 모델로 128K 컨텍스트를 내세우며 4비트에서 약 40 GB 필요(추정)

Beat sheet / 개요 생성

추천 모델:
Qwen3.6 35B-A3B
이유:
토큰당 350억 파라미터 중 30억 개가 활성인 Mixture-of-Experts(Apache-2.0)라 토큰당 생성이 빠름; 개요 품질은 PromptQuorum이 평가하지 않음

대화 검토

추천 모델:
샘플이 잘 맞는 모델
이유:
인물의 말하기 방식에 맞는 보정 대사를 내놓는 모델로 대화를 별도 패스로 실행; 대화용 모델의 검증된 순위는 없음

수정 (구조적)

추천 모델:
초안에 사용한 모델
이유:
호출당 구조적 제약 하나를 명시하는 수정 프롬프트는 지시를 따르는 어떤 모델에서도 작동; 호출당 한 장면

성숙한 / 어두운 소설

추천 모델:
Hermes 4 70B
이유:
Llama-3.1-70B 기반; Nous Research는 대체로 중립적인 정렬과 낮은 거부율이라고 설명; Llama 3 라이선스; 하이브리드 추론 모드

흔한 실수

  • 전체 원고를 컨텍스트에 붙여넣기. 모델이 128K–262K 윈도를 내세우더라도 긴 입력은 덜 안정적으로 활용되므로 약 32K 토큰으로 계획하십시오. 세션 문서 기법 — 압축된 인물 카드와 챕터 요약 — 을 사용하십시오.
  • 모델에게 열린 문서를 "계속 쓰도록" 요청하기. "소설을 계속 써라"는 이탈을 만들어 냅니다. "다음 장면을 써라: [특정 설정, 시점, 단어 상한]"은 평가하고 붙여넣을 수 있는 일관되고 경계가 있는 출력을 만들어 냅니다.
  • 시나리오에 beat sheet 없이 진행하기. Beat 없이 시나리오 페이지를 생성하면 분량이 늘어나고 구조적 기능을 잃는 페이지가 만들어집니다. 항상 beat sheet를 먼저 생성하십시오.
  • 세션 문서 업데이트 무시하기. 장면을 생성한 후 챕터 요약을 업데이트하지 않으면 세션 문서가 구식이 됩니다. 구식 세션 문서는 몇 세션 후 불일치를 만들어 냅니다.
  • 세션당 두 장면 이상 생성하기. 단일 컨텍스트 윈도 내에서 여러 장면을 생성하면 첫 번째 장면은 잘 생성되지만 이후 각 장면은 일관성이 낮아집니다. 세션당 한 장면; 재시작하고 다시 주입하십시오.

출처

자주 묻는 질문

로컬 LLM이 완전한 소설을 쓸 수 있습니까?

로컬 LLM은 한 편의 소설 분량의 산문을 생성할 수 있지만, 구조적·편집적 판단은 작가에게서 나와야 합니다. 모델은 구체적인 설정이 주어지면 장면을 생성하지만, 스스로 계획하거나 평가하거나 주제적 결정을 내리지는 않습니다. 이미 쓰는 방법을 아는 장면을 위한 빠른 초안 생성기로 보는 것이 적절합니다. 백지 앞에서의 시간을 아껴 주지만, 중요한 결정은 모두 작가가 내립니다. 투고 전에 출판사와 플랫폼의 AI 정책을 확인하십시오(아래 출판사 관련 질문 참조).

신뢰할 수 있게 사용할 수 있는 최대 컨텍스트 윈도는 얼마입니까?

모델은 128K에서 262,144 토큰을 내세우지만, PromptQuorum은 긴 컨텍스트 연구에서 모델이 긴 입력의 중간을 덜 안정적으로 활용한다고 보고되어 있으므로 1회 생성당 약 32K 토큰(~24,000 단어)으로 계획할 것을 권장합니다. 이는 보수적인 계획 규칙이며 모든 모델에 대해 측정된 한계가 아니므로, 사용하는 모델을 직접 시험하십시오. 세션 문서 기법은 작업 컨텍스트를 4,000–6,000 토큰 미만으로 유지하므로 모든 생성 호출이 이 범위 안에 충분히 들어갑니다.

소설 중간에 모델이 인물의 목소리를 바꾸는 것을 어떻게 방지합니까?

목소리 이탈에는 두 가지 원인이 있습니다: 구식 세션 문서(최근 인물 발전이 없음)와 컨텍스트 희석(인물 카드가 컨텍스트에서 활성 생성과 너무 멀리 있음). 해결책: 인물 카드를 시스템 메시지에 유지하고(긴 사용자 턴 전문에 묻히지 않도록), 인물이 중요한 아크 순간을 가진 후에는 카드를 업데이트하고, 각 세션 컨텍스트의 상단 섹션에 맞도록 카드를 충분히 간결하게 유지하십시오.

로컬 LLM과 함께 Scrivener를 사용할 수 있습니까?

기본 지원은 없습니다 — Scrivener 3에는 문서화된 플러그인 시스템이 없으며, 3.5.2(2025년 12월)까지의 공식 릴리스 노트에도 AI 통합에 대한 언급이 없습니다. 3.4.0 노트에는 "Scrivener itself contains no AI"라고 적혀 있고, macOS 시스템 기능인 Apple의 Writing Tools 지원이 추가되었습니다. 일반적인 워크플로: Ollama에서 생성(터미널 또는 보조 스크립트 사용), 출력을 복사해 해당 Scrivener 문서에 붙여넣습니다. 일부 작가는 Obsidian을 AI 초안 작성 레이어로 사용하고 완성된 챕터를 최종 구조화를 위해 Scrivener로 가져옵니다. Ollama API를 호출해 출력을 클립보드에 복사하는 스크립트가 기본 통합에 가장 가깝습니다.

시나리오 집필에는 Ollama와 클라우드 AI 중 무엇이 더 낫습니까?

성숙한 콘텐츠(폭력, 어두운 심리, 도덕적으로 복잡한 인물)를 생성해야 하는 시나리오 작가에게 로컬 모델은 모델과 거부 동작을 직접 통제할 수 있다는 이점이 있습니다 — 일부 호스팅 모델은 드라마 시나리오에 나오는 내용을 거부하거나 완화하며, 호스팅 서비스의 정책은 시간이 지나며 바뀝니다. Hermes 4 70B 같은 거부가 적은 로컬 모델은 내장된 거부가 적지만, 생성하고 공개하는 콘텐츠에 대한 책임은 여전히 본인에게 있습니다. 형식 일관성은 주로 시스템 프롬프트의 지시에 달려 있으며 둘 다 작동합니다. 선택은 주로 콘텐츠 통제, 프라이버시, 비용의 문제입니다. PromptQuorum은 시나리오 작업에서 호스팅 모델과 로컬 모델의 출력 품질을 비교하지 않았습니다.

특정 인물처럼 들리는 대화를 어떻게 생성합니까?

세 단계 접근법: (1) 세션 문서에 인물의 말하기 방식을 추가하십시오 ("격식체, 축약형 피하기, '제 생각에는...'과 같은 수식어로 문장 시작"). (2) 세션 시작 시 보정 단계로서 중립적인 컨텍스트에서 이 인물의 샘플 대화 3–5 줄을 생성하십시오. (3) 대화 프롬프트에서 해당 샘플 줄을 예시로 사용하십시오: "이 예시들과 동일한 어조로 대화를 작성하라: [샘플 붙여넣기]." 보정 단계가 인물 목소리 일관성을 위한 가장 효과적인 기법입니다.

소설 집필에 로컬 LLM을 사용하려면 GPU가 필요합니까?

GPU는 생성 속도를 크게 높여 주지만 필수는 아닙니다. Apple Silicon에서는 통합 메모리 덕분에 16 GB MacBook Pro도 더 작은 모델(4비트에서 대략 8B–14B급, 추정)을 실행할 수 있습니다 — 24 GB GPU 장비보다 느리지만, 생성 사이에 출력을 읽고 평가하는 집필 워크플로에서는 허용 가능한 수준입니다. 24 GB NVIDIA GPU(RTX 4090, RTX 3090)는 4비트에서 27B–32B급 모델을 담을 수 있습니다(추정). 70B급 모델은 4비트에서 약 40 GB 이상이 필요하므로 GPU 두 장, 48 GB 카드, 64 GB 통합 메모리 또는 속도가 느린 CPU 오프로딩이 필요합니다.

로컬 LLM을 Final Draft 또는 다른 전문 시나리오 소프트웨어와 함께 사용할 수 있습니까?

직접은 안 됩니다. Final Draft 도움말 센터에 따르면 Final Draft는 .fountain 파일을 가져올 수 없습니다. 권장 방법은 텍스트를 일반 .txt로 저장해 그 파일을 스크립트로 가져오거나, FDX를 내보낼 수 있는 앱을 통해 FDX로 가져오는 것입니다. Highland는 Fountain, FDX, PDF 사이를 변환하고, Fade In은 Fountain을 가져오고 내보냅니다(Fountain 앱 목록 기준). 워크플로: Ollama에서 Fountain 형식 텍스트를 생성하고, Highland 또는 Fade In에서 열어 Final Draft용으로 FDX를 내보냅니다.

소설 집필을 위해 로컬에서 Kimi-K2.6을 사용할 수 있습니까?

Kimi-K2.6은 256K 토큰의 컨텍스트 윈도를 내세워 Qwen3.6 27B, Gemma 4 31B와 같은 급이지만, 총 파라미터 약 1조 개(활성 320억 개)의 Mixture-of-Experts 모델이며 네이티브 int4 가중치를 사용합니다. 가중치만 약 500 GB가 되므로(PromptQuorum 추정) 멀티 GPU 서버나 매우 큰 통합 메모리 장비가 필요하며 소비자용 하드웨어에서는 비실용적입니다. 완전한 로컬 워크플로에서는 27B–70B dense 모델과 세션 문서 기법만으로 1조 파라미터 모델 없이도 소설 분량의 작업을 처리할 수 있습니다.

편집자들은 AI 지원 원고에 대해 어떻게 생각합니까?

정책은 출판사와 플랫폼마다 다르며 2026년에도 계속 바뀌고 있으므로 투고 전에 해당 정책을 확인하십시오. Amazon KDP는 텍스트, 이미지, 번역이 AI로 생성된 경우 이를 알리도록 요구하며, AI 도구로 만든 콘텐츠는 크게 편집하더라도 AI 생성으로 취급합니다. 본인이 직접 쓴 글을 AI가 편집이나 다듬기만 도운 경우는 "AI 지원"으로 공개할 필요가 없습니다(2023년 9월 Publishers Weekly가 보도한 Amazon 규정 기준). 일부 잡지는 AI가 관여한 작품을 아예 받지 않습니다 — Clarkesworld는 ChatGPT 같은 ‘AI’ 글쓰기 도구 사용에 관한 성명에서 이러한 도구로 번역·집필·개발·지원된 투고는 일절 검토하지 않겠다고 밝힙니다. 로컬 LLM이 생성한 장면 텍스트는 KDP의 "AI 생성" 정의 같은 기준에 해당하므로, 요구되는 곳에서는 공개하십시오. 이는 일반적인 정보이며 법률 자문이 아닙니다.

100만 토큰 컨텍스트에는 어떤 하드웨어가 필요합니까?

Qwen3.6 27B와 Qwen3.6 35B-A3B는 네이티브 262,144 토큰 컨텍스트를 내세우며, 모델 카드에 따르면 YaRN 스케일링으로 약 1,010,000 토큰까지 확장할 수 있습니다. 긴 컨텍스트는 가중치 외에 KV 캐시용 메모리가 필요하므로 100만 토큰 실행에는 일반적인 소비자 구성보다 훨씬 많은 메모리가 필요합니다. PromptQuorum은 필요량을 측정하지 않았습니다. 이 글의 세션 문서 기법은 바로 이 간극을 위해 설계되었습니다 — 100만 토큰 윈도에 의존하지 않고도 일관된 장문 출력을 얻기 위해서입니다.

← 고급 로컬 LLM으로 돌아가기

MCP