AI가 소설을 쓰는 문제의 원인이 컨텍스트 길이 자체가 아니라 메모리 활용 방식에 있을 수 있다

사람들이 AI를 이용해 장편 소설을 쓰는 것에 대해 이야기할 때마다 같은 주장을 듣습니다.

AI는 결국 컨텍스트가 너무 커지고, 세부 사항이 손실되며, 모델이 스스로 모순되는 내용을 쓰기 시작하기 때문에 10만 단어짜리 소설은 실제로 쓸 수 없다.

그리고 저는 우리가 이것을 LLM(대규모 언어 모델)의 문제로 보고 있지만, 실제로는 아키텍처의 문제라고 생각합니다.

제 말을 들어보세요.

저희는 소프트웨어 엔지니어링 분야에서 이미 놀랍도록 유사한 문제를 해결해 왔습니다.

만약 제가 20만 줄 분량의 코드베이스를 작업하고 있다면, 한 기능을 수정할 때마다 전체 코드베이스를 머릿속에 담아둘 필요는 없습니다.

프로젝트에는 파일, 폴더, 문서화 자료(documentation), 의존성(dependencies), 상태(state), 테스트, Git 기록(history), 설정(configuration), 그리고 아키텍처 결정 사항들이 있습니다.

저는 필요한 정보만 가져와서 변경하고, 테스트한 다음, 다음 작업으로 넘어갑니다.

전체 코드베이스는 존재합니다.

하지만 제가 **능동적인 작업 컨텍스트(active working context)**에 전체 코드베이스를 동시에 담아둘 필요는 없습니다.

그렇다면 왜 AI를 이용한 글쓰기는 종종 이런 방식처럼 작동하지 않을까요?

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

• Chapter 47
• Sarah의 현재 캐릭터 상태
• John의 현재 캐릭터 상태
• 활성화된 배신 플롯
• 현재 타임라인
• 12장에서 소개된 편지에 대한 정보
• 관련 세계관 설정
• 확립된 집필 스타일

이것은 훨씬 더 작은 컨텍스트입니다.

하지만 12장의 정보가 사라진 것은 아닙니다.
단지 다른 곳에 저장되어 있다가 관련성이 있을 때 검색되는 것뿐입니다.

이는 문제에 대해 근본적으로 다른 방식으로 생각하는 것입니다.

흥미로운 부분은 아이디어의 처리 방식이다

여기서부터는 훨씬 더 흥미로워진다고 생각합니다.

소설을 쓰다가 갑자기 이런 생각이 든다고 상상해 보세요:

"잠깐... 만약 John의 형제가 사실 악역 측에 협력하고 있는 건 아닐까?"

이것은 정식 설정(canon)이 아닙니다.
단지 아이디어일 뿐입니다.

따라서 시스템은 이를 확립된 사실과는 다르게 취급해야 합니다.

어쩌면 이것은 단순한 원시적인 아이디어로 시작할 수 있습니다.
나중에 제가 발전시키면서:

"사실, 그것이 7장에서 John이 사라진 이유를 설명해 줄 수도 있겠다."

이제 이것은 심각하게 고려되는 가능성이 됩니다.
결국 저는 결정합니다:

"그래. 이건 정식 설정이야(canon)."

그 시점에서 시스템은 관련 캐릭터 관계, 플롯 전개, 타임라인을 업데이트해야 합니다.
이것은 기본적으로 스토리 아이디어에 대한 버전 관리입니다.
그리고 저는 이것이 현재 AI 집필 워크플로우가 놓치고 있는 부분이라고 생각합니다.

모든 정보 조각이 동일한 상태를 가질 필요는 없다

이것이 가장 중요한 부분 중 하나일 수 있습니다.
집필 시스템은 다음 두 진술을 동등하게 취급해서는 안 됩니다:

"어쩌면 Sarah에게 자매가 있을지도 모른다."
과
"Sarah에게 Emily라는 이름의 자매가 있다."

전자는 아이디어입니다.
후자는 확립된 정식 설정(canon)입니다.

이것들 사이에는 아마도 다음과 같은 구분선이 있어야 할 것입니다:

• 아이디어 (Ideas)
• 발전 중인 내용 (Developing)
• 제안된 내용 (Proposed)
• 정식 설정 (Canon)
• 수정된 내용 (Revised)
• 폐기된 내용 (Deprecated)

이것은 AI에게 엄청나게 중요한 것을 제공합니다:
가능성과 사실 사이의 구분.

AI와 장편 프로젝트를 진행할 때 가장 답답한 점 중 하나는, 30장 전에 가볍게 언급했던 아이디어가 갑자기 확립된 사실처럼 취급되는 경우입니다.

인간 작가는 이해합니다:

"저는 단지 브레인스토밍을 하고 있었어요."

하지만 모델은 그렇지 못할 수 있습니다.

구조화된 프로젝트는 이러한 구분을 명시적으로 만들 수 있습니다.

캐릭터 메모리도 다르게 작동할 수 있다

모든 주요 캐릭터에 대해 지속적인 프로필을 가질 수 있습니다.

단순히 다음과 같은 것 이상으로:

"사라는 탐정이다."

훨씬 더 풍부한 무언가:

• 사라의 욕구는 무엇인가?
• 그녀는 무엇을 두려워하는가?
• 존에 대해 어떻게 생각하는가?
• 어떤 비밀을 숨기고 있는가?
• 독자에게 알려지지 않은 것은 무엇을 알고 있는가?
• 절대 하지 않을 행동은 무엇인가?
• 그 규칙을 깨게 만드는 것은 무엇일까?
• 1장 이후로 어떻게 변했는가?

그리고 중요한 점은, 이러한 답변들이 반드시 정적인(static) 상태여야 하는 것은 아니라는 것입니다.

5장의 사라와 50장의 사라는 매우 다를 수 있습니다.

따라서 Claude에게 다음과 같이 말하는 대신:

"사라를 기억해줘."

다음과 같이 제공할 수 있습니다:

"48장 기준으로 사라의 현재 정식 상태(canonical state)는 이렇습니다."

이것이 훨씬 더 유용합니다.

시스템은 모델에게 사라를 영구적으로 기억하도록 하려는 것이 아닙니다.

그것은 사라의 현재 상태를 유지하고 필요할 때 모델에 관련 버전을 제공하는 것입니다.

그리고 연속성(continuity) 문제도 있다

제가 생각하기에 AI 지원 소설 쓰기는 여기서 진정으로 흥미로워질 수 있습니다.

챕터를 확정하기 전에, 시스템은 **테스트 스위트(test suite)**와 유사한 것을 실행할 수 있습니다.

Claude가 48장을 완성하고 시스템이 다음과 같이 확인하는 것을 상상해 보세요:

연속성 검사 (Continuity check)

사라는 파리에 가본 적이 없다고 말한다.

14장에는 사라가 파리에서 3년간 살았다고 되어 있다.

충돌 감지.

존은 살인 사건에 대해 알고 있다.

현재 플롯 상태로는 존이 아직 알면 안 된다.

지식 상태 충돌 감지 (Knowledge-state conflict detected).

사라의 나이가 29세에서 32세로 바뀌었다.

캐릭터 상태 충돌 감지 (Character-state conflict detected).

48장에서 언급된 총은 21장에서 파괴되었다.

사물 연속성 충돌 감지 (Object continuity conflict detected).

이것은 기본적으로 **소설 컴파일러(novel compiler)**라고 할 수 있습니다.

😂

그리고 저는 이것이 엄청나게 유용할 수 있다고 생각합니다.

왜냐하면 더 큰 컨텍스트 창(context window)이 연속성(continuity) 문제를 자동으로 해결해주지 않기 때문입니다.

모델에게 50만 토큰을 제공하고 그 중간 어딘가에 중요한 사실 하나를 숨겨보세요. 모델은 여전히 그것을 올바르게 사용하지 못할 수도 있습니다.

문제는 반드시 다음과 같지는 않습니다:

"AI가 정보에 접근할 수 있는가?"

오히려 다음과 같은 문제일 수 있습니다:

"AI가 지금 당장 어떤 정보가 중요한지 신뢰성 있게 식별할 수 있는가?"

이것은 매우 다른 문제입니다.

컨텍스트, 메모리, 그리고 진실의 출처는 서로 다르다

저는 이 세 가지 개념이 너무 자주 혼동된다고 생각합니다.

**컨텍스트(Context)**는 모델이 현재 보고 있는 정보입니다.

**메모리(Memory)**는 필요할 때 검색될 수 있는 프로젝트에 대한 정보입니다.

**진실의 출처(Source of truth)**는 소설에서 실제로 확립된 내용입니다.

이것들은 같은 것이 아닙니다.

실제 챕터가 진실의 출처일 수 있습니다. 캐릭터 프로필은 그 진실을 구조화하여 표현한 것일 수 있습니다. 검색된 메모리는 프로젝트에서 관련 정보를 제공할 수 있습니다. 그리고 활성 컨텍스트는 모델이 지금 당장 필요한 내용만을 포함할 수 있습니다.

컨텍스트 창 자체에 모든 책임을 지우려고 하는 것보다, 이렇게 분리하는 것이 훨씬 확장성이 높아 보입니다.

삭제된 장면과 대체 버전은 어떨까?

여기서 소프트웨어 비유가 흥미로워지는 또 다른 부분이 있습니다.

작가들은 이야기의 버전을 하나만 가지고 있지 않습니다. 그들은 다음과 같은 것들을 가지고 있습니다:

• 삭제된 장면(Deleted scenes)
• 대체 결말(Alternative endings)
• 이전 초안(Previous drafts)
• 폐기된 플롯라인(Abandoned plotlines)
• 자료조사(Research)
• 노트(Notes)
• 버려진 대화(Scrapped dialogue)
• 최종 책에 들어가지 못한 세계관 구축(Worldbuilding that never made it into the final book)

Claude에게 다음과 같이 질문할 수 있다고 상상해 보세요:

"존의 형제와 관련된 모든 폐기된 플롯 아이디어를 보여줘."

또는:

"왜 사라는 아직 그 편지에 대해 알 수 없다고 결정했지?"

또는:

"현재 결말과 초안 2의 결말을 비교해 줘."

이것이야말로 인간이 대규모 창작 프로젝트를 실제로 진행하는 방식에 훨씬 가깝습니다.

그리고 이것은 우리가 이미 복잡한 소프트웨어 프로젝트를 관리하는 방식과도 훨씬 가깝습니다.

무언가를 바꿀 때마다 이전 코드를 버리지 않습니다.

역사를 유지합니다.

상태(state)를 유지합니다.

진실의 원천(source of truth)을 유지합니다.

필요할 때 브랜치(branch)를 만듭니다.

장편 AI 작문도 왜 똑같이 작동하지 않을까요?

검색은 의도적이어야 한다

제가 제시하고 싶은 또 다른 구분점이 있습니다.

현재 많은 AI 시스템들은 본질적으로 다음과 같이 질문합니다:

"이 프롬프트와 관련성이 높아 보이는 정보는 무엇인가?"

하지만 대규모 창작 프로젝트의 경우, 더 나은 질문은 다음과 같다고 생각합니다:

"이 작업을 올바르게 수행하는 데 필요한 프로젝트 상태(project state)는 무엇인가?"

만약 제가 Claude에게 48장을 쓰라고 요청한다면, 시스템은 아마도 이전 장, 현재 캐릭터의 상태, 활성화된 플롯 전개, 관련 연속성 정보(continuity information), 현재 타임라인, 그리고 확립된 작문 스타일이 필요하다는 것을 알아야 합니다.

그것은 초안 2에서 거절된 플롯 아이디어가 필요하지 않습니다.

삭제된 장면도 필요하지 않습니다.

책의 완전히 다른 부분에서 나온 관련 없는 하위 플롯(subplot)도 필요하지 않습니다.

목표는 더 많은 정보를 검색하는 것이 아닙니다.

올바른 정보를 검색하는 것입니다.

이것은 소설을 넘어 확장될 수 있다

이러한 아키텍처는 거의 모든 대규모 창작 프로젝트에 적용될 수 있습니다.

각본(screenplay).

게임.

만화 세계관(comic universe).

연구 프로젝트.

장기 운영되는 YouTube 채널.

기술 문서 작성 프로젝트.

심지어 소프트웨어 개발 자체에도요.

근본적인 문제는 같습니다:

프로젝트가 모델의 유용한 작업 컨텍스트보다 크다.

따라서 컨텍스트 창(context window)을 끊임없이 늘리는 대신, 그 안에 들어오는 정보를 관리하는 방법을 개선해야 할지도 모릅니다.

어쩌면 미래는 단순히 더 큰 컨텍스트가 아닐 수 있다

이것이 제가 생각하기 시작한 부분입니다.

어쩌면 미래는 단순히 다음과 같지 않을 수도 있습니다:

LLM + 거대한 컨텍스트 창

아마도 다음과 같을 것입니다:

LLM + 프로젝트 상태 + 검색 + 구조화된 메모리 + 검증(validation)

모델이 추론 엔진(reasoning engine)이 되고,
프로젝트 시스템이 영구적인 메모리가 되는 것입니다.

그리고 애플리케이션이 각 작업을 위해 모델이 실제로 어떤 정보가 필요한지 결정합니다.

다시 말해, 모델에게 책 전체를 기억하도록 요청하는 대신, 모델이 책을 탐색할 수 있도록 돕는 시스템을 구축하는 것입니다.

기본적으로...

저는 장편 AI 작문의 해답이 반드시 다음과 같다고 생각하지 않습니다:

"모델에게 500만 토큰 컨텍스트 창(context window)을 제공하라."

왜냐하면 어느 시점에서는 책이 더 커지기 때문입니다.

그러면 속편이 나옵니다.

그리고 캐릭터 노트가 생깁니다.

그리고 리서치가 필요합니다.

그리고 대체 초안들이 있습니다.

그리고 삭제된 장면들도 있고요.

그리고 세계관 구축(worldbuilding)도요.

그리고 새벽 3시에 떠오른 무작위 아이디어 400개도요.

결국 당신은 거대한 텍스트 더미를 갖게 되고 AI에게 이렇게 말하게 됩니다:

"이 모든 것을 기억해라."

그것은 진정한 메모리 시스템이 아닙니다.

아주 비싼 폴더에 가깝습니다.

저는 다음과 같은 것에 더 가까운 것이 좋겠습니다:

소설 → 구조화된 프로젝트 메모리 → 관련 컨텍스트 → Claude → 연속성 확인(continuity check) → 업데이트된 스토리 상태

소설이 진실의 원천(source of truth)으로 남습니다.

메모리 시스템은 무엇이 중요한지 추적합니다.

컨텍스트는 현재 작업에 맞게 조립됩니다.

Claude가 추론과 작문을 수행합니다.

그런 다음 결과로 나온 변경 사항들이 프로젝트 상태로 다시 피드백됩니다.

Git + RAG + 구조화된 메모리 + LLM + 소설.

솔직히 말해서, 이것은 더 이상 임시방편처럼 느껴지지 않고 우리가 실제로 원할 만한 아키텍처처럼 느껴지기 시작합니다.

혹시 누군가 이미 Claude Projects, Claude Code, Obsidian, RAG, 사용자 지정 MCP 서버 또는 완전히 다른 방식으로 이와 유사한 것을 구축하고 있는지 궁금합니다.

왜냐하면 만약 누군가가 이미 **"소설을 위한 Git(Git for novels)"**을 만들었다면, 저는 그것에 대해 간절히 알고 싶기 때문입니다.