원고를 기억하는 LLM, 되돌리는 Git (2/7)
원고를 기억하는 LLM, 되돌리는 Git
지난 편에서 장편을 쓰는 사람의 두 적, 기억과 버전을 이야기했다. 그리고 그 둘을 각각 LLM과 Git에게 맡기겠다고 했다. 이번 편에서는 그 두 조력자가 소설을 쓰는 동안 정확히 무엇을 해줄 수 있는지, 그리고 왜 하필 그 둘인지를 제대로 들여다보자.
LLM이 소설가에게 해줄 수 있는 일
LLM은 챗GPT나 클로드처럼 사람의 말로 묻고 답하는 도구다. 그런데 '대화하는 AI'라는 한 줄로는 소설가에게 무슨 쓸모인지 와닿지 않는다. 구체적으로 풀어 보자.
첫째는 기억이다. 다만 한 가지 오해는 먼저 풀어야 한다. 27만 자를 통째로 LLM에게 던져 놓고 그때그때 묻는 방식은 사실 현실적이지 않다. 아무리 긴 글을 읽는 모델이라도 한 번에 다룰 수 있는 분량에는 한계가 있고, 설령 전부 집어넣더라도 그 방대한 텍스트에서 한 줄을 매번 정확히 짚어 내리란 보장이 없으며, 그렇게 할 때마다 드는 비용과 시간도 만만치 않다. 그래서 실제로는 LLM이 원고를 미리 읽어 '설정집'이라는 압축된 자료를 따로 만들어 두고, "이 인물의 눈동자 색이 어디서 처음 나오지?" 같은 질문에는 원고 전체 대신 그 설정집만 펼쳐 본다. 설정집은 원고보다 훨씬 짧아 매번 빠르게 훑을 수 있다. LLM과 설정집이 한 쌍이 되어 작가의 외장 기억 노릇을 하는 것이다. 설정집이 정확히 무엇인지는 바로 다음 장에서 설명한다.
둘째는 정리다. 방금 첫째에서 말한 그 설정집을 만드는 일이 바로 이것이다. "방금 쓴 화를 읽고 인물 설정을 정리해 줘"라고 하면, LLM이 그 화에 흩어진 묘사를 그러모아 인물 사전에 채워 넣는다. 한 번에 수십만 자를 삼키는 게 아니라, 화 단위로 조금씩 쌓아 가는 방식이다. 세계관의 규칙도, 사건의 연표도, 장소 목록도 그렇게 자란다. 머릿속에만 떠다니던 설정이 비로소 문서의 모습을 갖춘다.
셋째는 모순을 잡아내는 일이다. "설정이 어긋난 곳을 찾아 줘"라고 하면, 한 인물의 말투가 초반과 후반에서 딴사람처럼 달라졌다거나, 9화에서 죽은 인물이 30화에 멀쩡히 등장한다거나 하는 충돌을 짚어 준다. 글이 길어질수록 작가 혼자서는 놓치게 되는 것들이다.
넷째는 물어보면 분석해 주는 일이다. "이 복선은 회수됐나?", "여기까지 누가 무엇을 알고 있지?", "두 인물의 관계를 정리해 줘". 원고라는 거대한 자료를 상대로, LLM은 즉석에서 답을 만들어 낸다.
분명히 해 둘 것이 하나 있다. 이 중 어디에도 '소설을 대신 써 준다'는 항목은 없다. LLM이 맡는 일은 기억하고, 정리하고, 점검하고, 찾아 주는 것까지다. 쓰는 사람은 끝까지 작가다.
![설정집을 펼쳐 인물의 사고 원인과 결과를 정리해 답하는 LLM]
한 인물의 사고 원인과 결과를 묻자, LLM이 설정집을 펼쳐 원인·결과를 정리해 답한다. 각 항목 뒤에 근거가 된 화 번호와 🔑 복선까지 달려, LLM과 설정집이 한 쌍으로 작가의 외장 기억이 되어 준다. (실제 작업 화면)
설정집 — 원고가 스스로 자라게 만드는 장치
방금 LLM이 만들어 준 인물 사전과 연표, 세계관 정리를 한데 묶은 것을 이 글에서는 설정집이라 부르겠다. 인공지능 연구자 안드레이 카파시가 'LLM-Wiki'라는 이름으로 정리한 방식이다.
설정집의 구조는 단순하다. 작가가 쓴 원고가 있고, 그것과는 별개로 LLM이 만든 설정 문서 묶음이 따로 있다. 핵심 규칙은 하나, 원고는 건드리지 않는다는 것이다. 작가의 본문은 원본 그대로 두고, 그 본문을 읽어 만든 2차 자료가 소설과 함께 성장한다.
왜 이것이 장편에 그토록 잘 맞을까. 장편은 정보량이 인간의 기억 한계를 넘어서는 글이기 때문이다. 단편이라면 설정이 머릿속에 다 들어오지만, 27만 자의 세계를 통째로 붙들 수 있는 사람은 없다. 설정집은 바로 그 한계를 메우는 외장 기억이다.
게다가 설정집은 멈춰 있지 않는다. 새 화를 쓸 때마다 "방금 쓴 12화를 반영해 줘"라고 하면, LLM이 인물 사전과 연표를 갱신한다. 사람이 손으로 설정집을 관리하면 몇 화 못 가 방치되지만, 지치지 않는 LLM은 매번 최신 상태로 고쳐 쓴다. 무언가 궁금할 때 27만 자를 처음부터 다시 뒤질 필요 없이, 잘 정리된 설정집부터 펼치면 된다.
그래서 한 권을 끝낼 무렵이면, 머릿속에서 흘러내리던 모든 디테일이 이 설정집 안에 차곡차곡 쌓여 있다. 다음 권을 시작할 때 1권의 세계를 통째로 다시 떠올릴 필요가 없다는 뜻이다. 나는 첫 장편을 이 방식으로 정리했고, 41화의 세계를 30여 개의 설정집 페이지로 압축해 두었다.
Git — 개발자들이 20년 넘게 신뢰해 온 도구
Git을 만든 사람은 리누스 토발스다. 운영체제 리눅스를 세상에 내놓은 바로 그 사람으로, 2005년에 리눅스 커널 개발자 수천 명이 서로 충돌 없이 협업할 방법이 필요해지자 며칠 만에 Git의 뼈대를 만들었다.
개발자들이 Git을 그토록 오래, 그토록 널리 써 온 데에는 분명한 이유가 있다. Git은 파일이 바뀐 모든 순간을 기록하고, 그중 어느 시점으로든 정확히 되돌아갈 수 있게 한다. 본래의 줄기에서 여러 갈래로 가지를 쳐 실험하다가, 마음에 들면 합치고 아니면 통째로 버릴 수 있다. 누가 언제 무엇을 왜 바꿨는지가 빠짐없이 남는다. 그래서 오늘날 거의 모든 소프트웨어가 Git 위에서 만들어지고, 그 작업물을 모아 두는 GitHub 같은 곳이 전 세계 개발자의 공용 작업장이 되었다.
![Git이 변화를 기록하고 가지를 쳤다 합치는 방식을 그린 개념도]
Git이 변화를 기록하는 방식을 그린 그림이다. 동그라미 하나하나가 저장된 시점이고, 가로로 이어진 초록 줄기가 원고의 본 흐름이다. 곁가지로 갈라진 선은 따로 실험해 보는 갈래이고, 화살표가 다시 본 줄기로 모이는 곳이 '합치기'다. 영어 이름표(Feature·Hotfix 등)는 개발자들이 쓰는 구분일 뿐, 작가는 커밋과 되돌리기 둘만 알면 된다.
이 모든 쓸모가 소설에도 그대로 옮겨진다. 원고 역시 시간에 따라 끝없이 바뀌는 텍스트, 코드와 다르지 않은 거대한 글이기 때문이다. Git을 쓰면 '최종, 진짜최종, 진짜진짜최종'으로 파일을 복제할 일이 없다. 3화를 통째로 갈아엎었다가 어제저녁의 원고로 한 번에 돌아올 수 있고, "결말을 이렇게 바꾸면 어떨까" 하는 생각을 따로 가지를 쳐 실험한 뒤 조용히 버리거나 본 줄기에 합칠 수 있다. 원고를 통째로 잃어버릴 걱정도, 편집자에게 보낸 사본이 어느 버전이었는지 헷갈릴 일도 사라진다.
되돌릴 수 있다는 사실을 알고 나면, 비로소 겁 없이 고치게 된다. 개발자들이 거대한 코드 앞에서 누려 온 그 자유를, 소설가도 거대한 원고 앞에서 똑같이 누리게 되는 것이다.
두 조력자, 하나의 리듬
정리하면 이렇다. 작가가 새 화를 쓰면, LLM이 그것을 읽어 설정집을 갱신하고, 그 변화를 Git이 한 시점으로 저장한다. 쓰기, 정리하기, 저장하기. 이 세 박자가 매일 돌아가는 동안, 원고 폴더는 그냥 원고가 아니라 스스로 기억하고 스스로 되돌아갈 줄 아는 작업실이 된다.
다음 편에서는 말 대신 손이다. LLM과 Git을 실제로 내 컴퓨터에 들이고, 첫 폴더를 만드는 데까지 — 무료 프로그램 두어 개를 깔아 본다.
LLM-Wiki(설정집) : 원고(원본)와 별개로, LLM이 원고를 읽어 만들고 유지하는 2차 문서 묶음. 인물·세계관 사전과 사건 연표 등으로 구성되며 새 원고가 나올 때마다 갱신된다. 'LLM-Wiki'는 이 방식을 정리한 안드레이 카파시(Andrej Karpathy)의 글에서 온 이름이다.