스토리의 연속성을 잃지 않고 AI 세계관 바이블을 구축하는 방법

AI 세계관 바이블에는 무엇이 포함되어야 할까요?

집필 과정의 실질적인 질문에 답할 수 있는 소규모 레퍼런스 시스템부터 시작하세요. 이 캐릭터가 일몰 전에 천문대에 도착할 수 있는가? 천문대 문이 어떻게 열리는지 알아냈는가? 다른 스토리 분기에서는 그 답이 달라지는가?

바이블을 서로 연결된 6개의 섹션으로 구성하세요.

스프레드시트, 연결된 문서 또는 편하게 관리할 수 있는 데이터베이스를 사용하세요. LOC-01, CHAR-02와 같이 엔터티에 고유 ID를 부여하고, 표시 이름과 별칭은 별도의 필드에 보관하세요. "유리 천문대"의 이름을 바꾼다고 해서 해당 장소 레코드에 대한 모든 참조가 깨져서는 안 됩니다.

서사적 요약은 원장을 편리하게 보기 위한 뷰(view)로 취급하세요. 요약이 기본 레코드와 일치하지 않는 경우, 두 버전 중 어느 하나를 기반으로 집필을 진행하기 전에 출처를 확인하고 충돌을 해결해야 합니다.

사실의 소유권은 누구에게 있으며, 무엇이 그것을 공식 설정으로 만들까요?

이 워크플로에서 사실 소유권은 두 부분으로 나뉩니다. 하나의 신뢰할 수 있는 권위 있는 레코드가 진술을 보유하고, 한 사람이 변경 사항 승인을 담당합니다. 1인 작가는 이 역할을 혼자 수행합니다. 팀 단위라면 장소 관련 결정은 월드 디자이너에게, 캐릭터의 사실 인지 관련 결정은 내러티브 리드에게 할당하고, 결정 사항이 겹칠 때를 대비해 한 명의 최종 해결자를 지정할 수 있습니다.

소유권과 함께 출처(provenance)를 기록하세요. W3C의 PROV 개요(https://www.w3.org/TR/prov-overview/)에서는 출처를 무언가를 제작하는 데 관여한 엔터티, 활동, 사람에 대한 정보로 설명합니다. 이를 스토리 바이블에 적용하면 진술이 어디에서 비롯되었는지, 어떻게 변경되었는지, 누가 승인했는지를 보존하는 것을 의미합니다. 여기서 다루는 원장은 공식적인 PROV 구현체가 아니라 해당 원칙을 차용한 것입니다.

각 레코드에 명시적인 상태를 부여하세요.

기존 원고를 가져올 때 AI가 정확한 씬 참조 및 이를 뒷받침하는 짧은 인용구와 함께 후보 사실들을 추출하도록 하세요. 참조 내용은 직접 확인해야 합니다. 어떤 캐릭터가 "천문대는 항상 잠겨 있다"고 말한 것은 그 말이 나왔다는 사실만 확립할 뿐, 객관적인 규칙을 자동으로 확립하지는 않습니다.

프로젝트의 권한 정책을 문서화하세요. 예를 들어, 수용된 설정 변경(retcon) 결정은 이전의 공식 설정을 덮어쓰며, 수용된 원본 씬은 사실을 확립하고, 작업 초안과 브레인스토밍은 잠정적인 상태로 유지됩니다. 승인된 두 씬이 충돌하는 경우, 어느 쪽을 변경할지 결정할 때까지 해당 충돌을 미해결로 표시하세요.

타임라인과 장소를 어떻게 함께 추적하나요?

스토리 시간과 수정 시간을 분리하여 기록하세요. "다리는 6일 차에 닫힌다"는 사건을 설명합니다. "작가가 4차 수정본에서 다리가 닫히는 날짜를 변경했다"는 편집 결정을 설명합니다. 이 둘을 혼용하면 세계관이 바뀐 것인지, 세계관에 대한 설명이 수정된 것인지 모호해집니다.

각 사건에 대해 가능한 가장 빠른 시간과 가장 늦은 시간, 장소, 참여자, 전제 조건, 결과 상태를 파악하세요. 정확성이 필요하지 않을 때는 범위를 사용하세요. "아침 배달 후, 일몰 전"이 임의로 지어낸 시간(분 단위)보다 더 유용할 수 있습니다. 배경 설정에서 생소한 날짜나 계절 체계를 사용하는 경우 역법 단위를 정의해 두세요.

각 이동 경로에 대해 출발지, 목적지, 이동 수단, 소요 시간 또는 범위, 이용 가능 조건을 기록하세요. 양방향 이동이 가능한지도 명시하세요. 지도상에서는 두 장소가 가까워 보이더라도 확립된 경로상으로는 크게 우회해야 할 수도 있습니다.

명확한 예시를 위한 다음 연속성 점검 사례를 살펴보세요. 한 배달원이 09:00에 과수원을 출발하여 천문대까지 가는 데 3시간이 걸리고, 렌즈를 수령하는 데 30분을 추가로 소비합니다. 가장 빠른 도착 시간은 12:30입니다. 수용된 예외 사항이 적용되지 않는 한, 이 배달원이 정오에 그곳에 있는 것으로 묘사된 씬은 이러한 입력값과 충돌합니다.

출발 시간, 이동 경로, 지연 시간, 만나는 시간 등 근거가 있는 입력값을 변경하여 충돌을 해결하세요. 이동 시간이 2~4시간 걸린다면 도착 시간은 특정 시점이 아닌 범위가 됩니다. 확정적인 모순으로 단정하기보다 이러한 불확실성을 그대로 보존하세요.

세계관의 진실과 캐릭터의 지식을 어떻게 분리하나요?

지식 레코드를 객관적 사실과 분리하여 보관하세요. 중요한 사실 인지가 일어날 때마다 캐릭터, 사실 또는 믿음, 습득 사건, 시간, 분기 조건을 기록하세요. "알고 있음", "의심함", "잘못 믿고 있음", "배우지 못함"을 구분하세요. 레코드가 없다는 것은 지식이 기록되지 않았다는 뜻이지, 모른다는 것을 증명하지는 않습니다.

이는 인터랙티브 서사에서도 그대로 대응되는 개념입니다. Inkle의 공식 ink 튜토리얼(https://www.inklestudios.com/ink/web-tutorial/)에서는 이전에 방문한 스토리 섹션을 기반으로 하는 조건부 텍스트와 선택지를 보여줍니다. 또한 커스텀 변수에 대해서도 설명합니다. 이러한 메커니즘은 정보에 대한 접근성을 표현할 수 있지만, 특정 씬을 방문하는 것이 실제로 캐릭터에게 특정 사실을 알게 해주는지는 작가가 결정해야 합니다.

예를 들어 천문대 문은 구리 원반이 표시선과 정렬될 때 열릴 수 있습니다. 이것은 세계관의 사실입니다. 미라가 시연 중에 그 절차를 배우는 것은 별개의 사건입니다. 불완전한 쪽지를 읽은 다른 캐릭터는 작동 방식만 짐작할 뿐일 수 있습니다.

분기형 게임의 경우 습득 사건을 관련 경로 또는 상태 조건에 연결하세요. 캐릭터가 절차를 배운 경로와 건너뛴 경로를 둘 다 테스트하세요. 소설의 경우 챕터가 시간순으로 배치되지 않더라도 스토리 시간상 설명과 대화가 습득 사건 이후에 발생하는지 확인하세요.

재사용 가능한 연속성 원장

다음 필드들을 스프레드시트의 열로 사용하거나 노트에서 반복 가능한 레코드 형태로 사용하세요. 레코드당 독립적으로 수정 가능한 하나의 주장만 유지하세요. 예시들은 오직 워크플로를 보여주기 위해 만들어진 것입니다.

다음은 서로 연결된 세 개의 레코드를 간략히 나타낸 뷰입니다. 전체 원장에서는 각 행마다 위의 근거 및 소유권 필드가 유지됩니다.

"미해결" 상태가 암묵적으로 "불가(no)"가 되지 않도록 하세요. 질문 Q-003은 대체 원반 옵션을 미결정 상태로 둡니다. 이는 허용하지도 금지하지도 않는 상태입니다. 답변이 필요한 씬이 있다면 결정 요청이 트리거되어야 합니다.

각 미해결 질문에 담당자와 결정 시점을 부여하세요. 예: "S-15 초안 작성 전 해결할 것." 독자에게 의도적으로 숨기는 답변이라면 작가가 이미 답을 알고 있는지 여부를 기록하세요. 작가가 알고 있는 답과 아직 결정되지 않은 디자인 선택은 다르게 다루어야 합니다.

초안 작성 중에 AI는 바이블을 어떻게 활용해야 할까요?

대상 씬의 시간, 장소, 시점, 분기, 관련 공식 설정 레코드, 미해결 의존성을 담은 '씬 패킷(scene packet)'을 준비하세요. 단순히 씬의 키워드를 공유하는 항목뿐만 아니라 연결된 전제 조건도 포함해야 합니다. 문이 나오는 씬은 다른 장소에서 진행된 이전 시연에 의존할 수 있습니다.

다음과 같은 재사용 가능한 지침 프롬프트를 활용하세요.

제공된 씬을 첨부된 연속성 레코드 및 해당 리비전과 대조하여 검토해 주세요. 잠재적인 충돌이 있을 때마다 씬의 구절을 인용하고 관련 레코드 ID를 명시하세요. 충돌을 모순, 정보 누락, 제안된 추가 사항 중 하나로 분류하세요. 시간 순서, 이동, 장소 접근 권한, 캐릭터 지식, 분기 조건을 점검하세요. 미해결 질문은 그대로 유지하세요. 수정 방안은 별도로 제안하되, 공식 설정을 임의로 변경하거나 출처 참조를 지어내지 마세요. 제공된 자료만으로는 완료할 수 없었던 점검 항목이 있다면 명시하세요.

생성 작업의 경우 명시적인 제약 조건 내에서 대안을 요청하세요. "F-014를 변경하거나 E-008 이전에 미라에게 지식을 부여하지 않고 미라를 지연시킬 수 있는 방법 3가지를 제안해 줘." 원하는 분위기, 속도감, 배경의 특징은 본인의 언어로 직접 묘사하세요.

결과물을 두 단계로 나누어 검토하세요. 먼저 인용된 레코드가 그 분석 결과를 뒷받침하는지 확인합니다. 그런 다음 어떤 제안이 스토리에 도움이 될지 결정합니다. 승인된 변경 사항만 원장에 입력됩니다. 필요한 출처가 누락된 경우 이를 찾아보거나 해당 결과를 미해결 상태로 남겨두세요.

이전 설정을 지우지 않고 설정 변경(retcon)을 처리하려면 어떻게 해야 할까요?

일반적인 사건과 설정 변경을 구분하세요. 문에 11일 차에 새로운 메커니즘이 장착되는 것이라면 전환 사건과 시간 제한이 있는 새로운 규칙을 추가하면 됩니다. 만약 문이 원래부터 항상 다른 메커니즘을 사용했던 것으로 바꾸기로 결정했다면, 이전 공식 설정을 수정하고 의존성이 있는 모든 씬을 검토해야 합니다.

버전 히스토리를 관리하면 이전 상태를 복구할 수 있습니다. Git 공식 서적의 버전 관리 소개(https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control)에서는 버전 관리가 어떻게 변경 사항을 기록하고 비교를 지원하며 이전 버전을 불러올 수 있게 하는지 설명합니다. Git도 하나의 선택지이며, 작업 방식에 더 잘 맞는다면 유용한 히스토리 기능이 있는 문서 시스템을 선택해도 좋습니다. 서사적 결정이 변경된 이유는 별도로 기록하세요.

설정 변경을 제안할 때마다 다음 단계를 따르세요.

재사용 가능한 변경 로그 항목에는 변경 ID, 수정 날짜, 결정권자, 이유, 이전 레코드, 대체 레코드, 영향을 받는 자료, 검증 상태가 포함되어야 합니다. 예를 들면 다음과 같습니다. "CH-006: 정렬된 두 개의 원반을 요구하도록 제안함. F-014, E-008, K-009, S-12에 영향 미침. 결정 대기 중." 승인이 되었다고 해서 의존하는 씬들이 이미 수정되었다는 뜻은 아닙니다.

씬을 최종 승인하기 전에 무엇을 확인해야 할까요?

창작적 수정이 끝난 후 연속성 검토를 위해 씬을 한 번 정독하세요. 필요한 사건이 실제로 일어났는지, 이동 및 접근 조건이 부합하는지, 캐릭터가 자신이 사용하는 정보를 알고 있는지, 분기 전용 사실이 해당 분기 내에만 머물러 있는지 확인하세요. 새로운 세부 사항이 공식 설정으로 수용되었거나 명백히 잠정적인 상태로 남아 있는지 점검하세요.

해당 점검에 사용된 바이블의 리비전을 기록하세요. 추후 변경 사항이 해당 씬의 의존성 중 하나에 영향을 미치면 씬을 다시 열어 재검토해야 합니다. 장소 하나, 캐릭터 한 명, 다음 씬에 필요한 필수 사실들로 작게 시작하여, 나중에 일어날 일에 제약을 거는 새로운 세부 사항이 생길 때마다 원장을 확장해 나가면 됩니다.

이 주제 더 살펴보기