「상처는 어깨에 있었다 — 아니, 다리였다.」 아서 코난 도일은 그 모순을 끝내 알아차리지 못했습니다. 그로부터 130년이 지난 지금도 셜록 홈스에 관한 거의 모든 책이 이 문제를 거론합니다.
왓슨의 전쟁 부상은 원작 단편들을 거치는 사이 어깨에서 정강이로 이동했습니다. 학자들은 이를 「왓슨의 떠도는 상처(Watson’s Wandering Wound)」라 부르며, 이 결함은 도일이 실제로 풀어낸 미스터리의 절반보다 더 유명해졌습니다. 타임라인 문서가 없었습니다. 인물 데이터베이스도 없었습니다. 점검되지 않은 단 하나의 배경 디테일이 문학사상 가장 사랑받는 시리즈 중 하나에 영원한 흉터를 남겼습니다.
타임라인 오류는 위대한 작품을 무너뜨리지는 않습니다. 그러나 그 흔적은 다른 무엇보다 오래 남습니다.
타임라인 오류의 네 가지 유형
이 문제에는 네 얼굴이 있고, 각각이 다른 방식으로 숨어 있습니다.
절대 시간 오류는 그래도 친절한 편입니다. 2020년이 배경인 이야기에서 등장인물이 2022년에 출시된 휴대전화 기종을 사용합니다. 역사 소설에서 어떤 인물이 알렉산더 그레이엄 벨의 특허가 나오기 수십 년 전에 전화를 겁니다. 그 시대를 아는 독자라면 즉시 알아챕니다. 거의 너무 쉬울 정도입니다.
상대 시간 오류는 한층 교활합니다. 5장에서는 「3년 전 그 여름」이라 합니다. 20장에서는 「5년 전 그 여름」이 됩니다. 같은 사건입니다. 또는 인물이 서른다섯 살로 묘사되지만, 출생 연도와 작중 연도를 계산하면 서른셋이어야 합니다. 이런 오류는 교차 검증을 요구합니다. 꼼꼼한 독자는 반드시 그 계산을 해 봅니다.
인과 시간 오류는 물리 법칙과 논리를 깨뜨립니다. 10장에서 등장인물이 15장에 가서야 일어나는 일을 언급합니다. 어떤 인물이 4시간 걸리는 두 도시 사이를 1시간 만에 자동차로 이동합니다. 독자는 단지 알아차리는 데 그치지 않고 이야기 밖으로 튕겨 나갑니다. 작가와 독자 사이의 계약은 「이 세계는 규칙을 따른다」고 약속했기 때문입니다. 인과 오류는 그 계약서를 찢어 버립니다.
병렬 시간 오류는 다중 POV 소설을 따라다닙니다. 두 줄거리가 동시에 흐르고 있는데, 정작 디테일이 그 일치를 배신합니다. 3장에서 인물 A가 금요일에 인물 B에게 전화를 겁니다. 그러나 B의 챕터를 보면 그날은 수요일입니다. 다중 시점을 다뤄 본 작가라면 거의 누구나 한 번쯤은 여기서 발을 헛디딥니다.
네 가지 모두에 공통점이 있습니다. 초고에는 거의 나타나지 않는다는 점입니다. 이 오류는 개고 단계에서 번식합니다. 날짜 하나를 옮기면서 그 날짜를 가리키는 일곱 군데 본문을 함께 고치는 것을 잊습니다. 장면 하나를 삭제했으면서도 그 장면을 가리키는 대사를 남겨 둡니다. 범인은 부주의가 아니라 개고라는 행위 자체의 성격입니다.
그래서 시스템이 필요합니다. 더 좋은 기억력이 아닙니다.
타임라인 문서 구축하기
Slima의 글쓰기 스튜디오 File Tree에는 “Outlines and Plans” 폴더가 있습니다. timeline.md가 자리할 곳이 바로 거기입니다. 이 파일은 작품 안의 모든 시간 관련 디테일에 대한 단일한 진실의 출처가 됩니다.
세 개의 섹션. 그것이면 충분합니다.
스토리 시간 범위 — 경계선입니다. 시작 날짜, 종료 날짜, 총 기간. 이 매개변수가 모든 곳으로 흘러내립니다. 계절은 무엇인가, 작중 기간에 명절이 들어 있는가, 날씨는 어떠한가, 인물은 무엇을 입고 있는가. 이것을 틀리면 하류의 오류가 곱셈으로 늘어납니다.
핵심 사건 표는 두 부분으로 나뉩니다. 먼저는 작중 시간 이전, 즉 첫 페이지 이전에 인물을 빚어낸 과거의 사건입니다. 다음은 작중 기간 동안의 본편 타임라인입니다. 항목마다 날짜, 일어난 일, 관련된 인물, 그 사건이 언급되는 챕터를 기록합니다. 사건 하나를 조정해야 할 때, 영향을 받는 모든 본문이 한눈에 보입니다.
인물 나이 참조표 — 많은 작가가 건너뛰는, 그러면서도 가장 후회하는 섹션입니다. 인물이 회상을 할 때 그는 몇 살이었는가? 두 인물이 공유된 기억을 이야기할 때 두 사람의 나이가 실제로 들어맞는가? 출생 연도와 주요 시점의 나이를 매핑한 표 하나가 독자보다 먼저 모순을 잡아냅니다.
Split View(Cmd+\ 또는 Ctrl+\)가 이 자리에서 진가를 발휘합니다. 왼쪽에는 타임라인, 오른쪽에는 지금 쓰고 있는 챕터. 시간과 관련된 문장이 등장할 때마다 즉시 교차 확인이 가능합니다. 왼쪽으로 시선만 옮기면 됩니다. 창 전환도, 탭 사냥도 없습니다.
Quick Open(Cmd+P)은 이를 더욱 빠르게 해 줍니다. “timeline”이라고 입력하면 파일로 곧장 이동합니다. 폴더 계층을 클릭으로 헤맬 필요가 없습니다.
AI를 타임라인 수호자로 삼기
10만 단어. 그 안에 흩뿌려진 수십 개의 시간 언급. 이것을 일일이 손으로 교차 확인하는 것은 성실함이 아닙니다. 오류를 놓치고 오후 시간을 통째로 날리는 가장 확실한 방법입니다.
Cmd+Shift+A(Mac) 또는 Ctrl+Shift+A(Windows)로 AI Chat Panel을 엽니다. 기계가 가장 잘하는 일 — 훑고, 비교하고, 계산하는 일 — 을 기계에 맡기십시오.
1단계: 시간 언급 스캔.
AI Assistant에 다음 프롬프트를 보내십시오.
“Drafts” 폴더의 모든 챕터를 훑어, 시간과 관련된 모든 언급을 찾아 주십시오. 다음을 포함해 주십시오.
- 구체적인 날짜나 연도(예: “2024년 3월”, “그 여름”)
- 상대적인 시간 표현(예: “사흘 전”, “다음 달”, “지난 겨울”)
- 계절이나 날씨 묘사(예: “눈이 펑펑 내리고 있었다”, “벚꽃이 만개해 있었다”)
- 인물 나이 언급(예: “그가 서른 살이었을 때”, “그녀는 아직 어렸다”)
- 역사적 사건이나 시대 표지(예: “닷컴 버블 시기”, “팬데믹 이후”)
결과는 표로 정리해, 챕터 위치와 원문 인용을 함께 적어 주십시오.
이 인벤토리가 토대입니다. 이것 없이는 그 뒤의 모든 작업이 추측이 됩니다.
2단계: 일관성 교차 확인.
다음 타임라인 문서와 시간 언급 목록을 토대로 모순을 점검해 주십시오.
[타임라인 파일 참조]
다음에 초점을 맞춰 주십시오.
- 상대 시간이 올바른 절대 시간을 가리키고 있는가
- 시점마다 인물의 나이가 일관되는가
- 사건 순서가 논리적인가
- 계절 묘사가 날짜와 부합하는가
발견된 모든 모순을 위치와 함께 나열해 주십시오.
3단계: 장면 사이 시간 계산.
때로는 질문이 좁고 구체적입니다.
5장의 장면은 금요일 밤에 일어납니다. 8장의 장면은 “사흘 뒤”라고 묘사됩니다.
다음을 계산해 주십시오.
- 8장은 무슨 요일이어야 하는가?
- 6장과 7장은 언제에 해당하는가?
- 다른 시간 단서들과 일관되는가?
모순이 있다면 수정 방향을 제안해 주십시오.
이 모든 작업을 관통하는 원칙은 단순합니다. AI는 계산과 비교를 맡습니다. 판단은 작가가 맡습니다. AI는 “7장의 화요일”이 “8장의 월요일”과 모순된다는 사실을 놓치지 않습니다. 하지만 그것이 진짜 실수인지, 아니면 신뢰할 수 없는 화자가 의도적으로 거짓말을 하고 있는 것인지는 구분하지 못합니다. 「오류인가 의도인가」의 구분은 어디까지나 작가의 몫으로 남습니다.
복합적인 시간 구조 다루기
선형 서사조차 관리하기가 어렵습니다. 비선형이라면 그것은 깊은 물 한가운데입니다.
다중 타임라인 소설 — “지금”과 “30년 전”이 번갈아 교차하는 종류의 작품 — 은 두 개의 독립된 연대기를 동시에 굴립니다. 각자의 사건 순서, 각자의 내적 논리가 있습니다. 그러나 두 흐름 사이의 대응 관계도 그만큼 중요합니다. 어느 “현재” 챕터가 어느 “과거” 시점과 맞물리는가. 그 매핑을 놓치면 두 타임라인이 서서히 어긋나는데, 독자가 지적할 때까지 누구도 모를 수 있습니다.
Slima File Tree 안에 별도의 문서를 만드십시오. timeline-present.md, timeline-past.md, 그리고 두 흐름이 교차하는 지점을 추적할 timeline-crossref.md. 별도 관리, 즉시 교차 참조입니다.
비선형 서사는 다른 짐승을 마주합니다. “읽기 순서”와 “스토리 시간”이 완전히 별개의 두 시퀀스로 존재합니다. 독자는 결말의 한 조각을 먼저 만나고, 그다음 도입을 만나고, 그다음 중간 어딘가를 만납니다. 그러나 이야기에는 객관적인 연대기가 그 아래 깔려 있어야 합니다. 두 시퀀스를 모두 추적해야 합니다. 어느 각도에서 보아도 논리가 무너지지 않아야 합니다.
크리스토퍼 놀란의 《메멘토》가 정전적인 예입니다. 한 갈래는 앞으로 흐르고, 다른 한 갈래는 뒤로 흐릅니다. 제작진은 모든 장면에 “영화 순서”와 “스토리 순서”의 위치를 각각 기록해, 거꾸로 보았을 때조차 인과가 무너지지 않도록 했습니다. 이런 구조로 소설을 쓰는 일은 어쩌면 더 어렵습니다. 산문에는 시간 점프를 신호할 카메라 언어가 없기 때문입니다.
타임라인을 다시 짜야 할 때
15장. 갑자기 깨닫습니다. 이야기는 1년이 아니라 6개월에 걸쳐 펼쳐지는 편이 더 좋겠다고. 또는 핵심 사건을 3개월 앞당겨야겠다고. 또는 — 가장 고통스러운 경우 — 전체 타임라인을 압축해야겠다고.
날짜 하나를 바꾸는 일은 쉽습니다. 그러나 그 날짜를 가리키는 본문이 얼마나 많습니까? 그것을 가리키는 「3개월 전」, 「지난 여름」이 들어 있는 챕터가 몇 개입니까? 원점을 바꾸면 하류의 모든 참조를 함께 갱신해야 합니다. 새로운 오류가 가장 빠르게 번식하는 자리가 여기입니다.
Slima의 Branches 기능은 정확히 이 순간을 위해 존재합니다. 브랜치를 하나 만드십시오. 이름은 timeline-revision 정도로. 모든 변경을 그곳에서 합니다. AI로 전면 일관성 점검을 돌립니다. 모든 것이 맞아떨어지는지 확인합니다. 그런 다음 메인 브랜치로 병합합니다.
안전망은 이렇습니다. 만약 그 개정이 예상치 못한 복잡성으로 휘말려 들어가면, 그 브랜치를 통째로 버리고 떠납니다. 메인 브랜치는 그 자리에 손대지 않은 채, 원래 모습 그대로 남아 있습니다.
Version Control 패널(Cmd+Shift+G)에서는 주요한 타임라인 변경마다 명확한 라벨을 붙인 스냅숏을 남길 가치가 있습니다. 예컨대 “타임라인 압축: 스토리 기간을 1년에서 6개월로 변경.” 석 달 뒤, 그 라벨이 생명선이 됩니다.
타임라인 파일 안에도 변경 로그를 함께 두십시오. 왜 이 사건은 이 날짜에 있는가? 무엇이 언제 수정되었는가? 미래의 자신이 그 30초의 기록에 감사할 것입니다.
구체적 연도가 없는 이야기에도 타임라인이 필요합니다
“내 소설은 막연한 「현대」가 배경입니다. 구체적인 연도가 없습니다. 그러니 타임라인은 필요 없겠지요?”
그렇지 않습니다. 어쩌면 명시적인 날짜가 있는 작품보다 더 위태롭습니다.
구체적인 연도가 없다는 말이 시간이 존재하지 않는다는 뜻은 아닙니다. 사건 사이로 며칠이 지나갔는가? 회상 속에서 인물은 몇 살이었는가? 겨울 장면 다음 챕터에서 갑자기 매미가 울 수는 없습니다. 인물에게 직업이 있다면 요일도 중요합니다.
상대 시간 참조는 사실 절대 시간보다 더 까다롭습니다. 「사흘 전」도 「지난 주」도 어딘가 분명한 지점을 가리켜야 합니다. 그 「어딘가」가 본문에 끝내 드러나지 않더라도 그렇습니다. 모호하다는 것은 부주의해도 된다는 것과 다릅니다.
타임라인은 상대 표지를 써도 됩니다. Day 1, Day 15, Week 3. 「2024년 3월 15일」 같은 표기가 필요 없습니다. 그러나 「사흘 전」, 「지난 달」, 「그 겨울」 같은 모든 표현은 닻을 내릴 기준점을 가져야 합니다.
왓슨의 상처는 어깨에서 다리로 떠돌았고, 코난 도일은 끝내 알지 못했을 것입니다. 130년이 지난 지금, 그 실수는 그가 옳게 적어 둔 디테일 대부분보다 훨씬 자주 인용됩니다.
모든 오류가 백 년 동안 기억되지는 않습니다. 그러나 그것을 막을 도구는 지금 글쓰기 스튜디오 안에 이미 있습니다. 타임라인 문서, AI 기반 일관성 점검, Version Control 스냅숏. 남은 것은 그것들을 세팅하는 데 드는 30분뿐입니다.
다음 글에서는 리서치 자료 정리를 다루겠습니다. 창작 과정에서 끝없이 불어나는 그 모든 참고 자료를, 어떻게 모으고, 관리하고, 단 3초 만에 찾아낼 것인가의 문제입니다.