나는 개발자처럼 장편소설을 썼다 (1/7)
나는 개발자처럼 장편소설을 썼다
장편소설을 쓰다 보면 누구나 한 번쯤 손이 멈춘다. 초반에 나온 인물의 눈동자가 무슨 색이었는지 갑자기 기억나지 않는 순간 같은 것이다. 분명 앞쪽 어딘가에 썼는데 어디였는지 모르겠고, 검색해 봐도 비슷한 단어가 수십 군데여서, 어떤 날은 그 한 줄을 찾다가 새벽 두 시를 넘긴다. 눈동자 색이면 그나마 다행이다. 어떤 날은 조연의 말투가 초반과 후반에서 딴사람이 되어 있고, 어떤 날은 분명히 죽인 인물이 한참 뒤에서 멀쩡히 걸어 다닌다. 이건 재능의 문제가 아니라 분량의 문제다. 글이 길어지면 누구나 자기가 만든 세계를 조금씩 놓친다.
이 글은 바로 그 문제를 다루는 이야기다.
![인물·설정·사건이 하나의 거대한 그물로 얽힌 설정집 그래프 뷰]
한 편의 장편은 인물·설정·사건이 이렇게 거대한 그물로 얽힌 하나의 세계다. 머릿속에서는 흩어져 부서지지만, 잘 정리해 두면 그 전체를 한 장으로 붙들 수 있다. 이 연재가 만들려는 것이 바로 이런 '정리된 세계'다. (실제 설정집을 그래프 뷰로 본 모습)
왜 '개발자처럼'인가
내가 처음 소설을 쓰겠다고 마음먹었을 때 - 왜 글을 쓰고 싶었는지는 모르겠다. 그냥, 이라고밖에는 - 가장 먼저 한 일은 '소설 쓰는 법'을 검색하는 것이었다. 개요를 짜고, 인물 카드를 만들고, 3막 구조를 지키라고들 했다. 하나씩 따라 해 봤지만 어쩐지 남의 옷을 입은 기분이었다. 나는 글쟁이가 아니라 개발자였으니까.
오랫동안 나는 소프트웨어를 만들어 왔다. 그러다 어느 날 SF 장편 「그녀, 내남편」을 쓰기 시작했고, 41화, 27만 자를 앞서 말한 것처럼 자꾸 멈춰 가며 작업을 했다. 멈출 때마다 같은 생각이 떠나지 않았다. 개발할 때는 이런 걸 머리로 외우지 않는데. 소프트웨어 개발자는 수십만 줄짜리 코드를 다루지만 그걸 통째로 기억하는 사람은 없다. 대신 우리는 기록하고, 검색하고, 누가 언제 무엇을 왜 바꿨는지 버전을 남긴다. 그래야 거대한 프로젝트가 무너지지 않는다. 어느 저녁 문득 생각했다. 소설도 이만큼 거대하다면, 내가 매일 쓰던 그 방법이 통하지 않을 이유가 없지 않을까. 이 글은 그렇게, 개발자가 거대한 코드를 다루는 방식을 소설 쓰기에 그대로 옮겨 본 기록이다.
미리 안심할 것이 하나 있다. 이 방법을 쓰는 데 개발 지식은 필요 없다. 개발자였던 건 나지, 이 글을 읽는 당신이 아니어도 된다.
그런 프로그램은 이미 있었다
어느 날 개발자 친구가 내가 소설을 쓴다는 말을 듣고 이렇게 권했다. "글 쓰는 프로그램을 하나 만들어 보지 그래. 인물이며 배경이며 연표를 데이터베이스에 넣어 두고, 써 둔 글이랑 맞춰 가며 쓰면 설정이 어긋날 일이 없잖아. 잘 만들면 팔 수도 있고." 개발자에게는 솔깃한 제안이었다. 하지만 세상일이 늘 그렇듯, 그런 프로그램은 이미 수두룩했다. 인물 카드를 채우고 연표를 입력하면 설정을 항목별로 정리해 주는 집필 도구들 말이다.
그런데 나는 그중 어느 것에도 정착하지 못했다. 이유는 늘 같았다. 그런 프로그램은 하나같이 내게 먼저 '입력'을 요구했다. 인물의 키와 눈동자 색을 칸마다 적어 넣고, 사건을 날짜 칸에 끼워 넣고, 세계를 표로 미리 쪼개 두어야 했다. 그렇게 정형화해 둔 것만 프로그램은 찾아 주고 비교해 줬다. 정작 내 소설은 칸이 아니라 문장으로 쓰여 있는데, 그 문장을 일일이 표로 옮기는 일이 글쓰기보다 더 큰 짐이었다. 게다가 그런 도구는 내가 적어 둔 '갈색 눈동자'와 본문의 '검은 눈동자'가 다르다는 건 알아도, 한 인물의 말투가 어느새 달라졌다거나 깔아 둔 복선이 아직 안 풀렸다는, 칼로 자르듯 떨어지지 않는 것은 짚어 내지 못했다.
LLM이 바꾼 것이 바로 이 지점이다. LLM은 글자를, 그러니까 내가 쓴 문장 그 자체를 읽는다. 세계를 표로 미리 쪼개 입력할 필요가 없다. 그냥 평소처럼 소설을 쓰면, LLM이 그 본문을 읽어 인물과 설정을 알아서 추려 낸다. 칸을 채워야 돌아가던 빳빳한 검색이, 사람처럼 어림잡아 헤아리는 판단으로 바뀐 것이다. "이 인물, 앞에서랑 말투가 좀 달라지지 않았어?" 같은, 데이터베이스로는 결코 물을 수 없던 질문에도 LLM은 답을 내놓는다. 내가 LLM에 기대기로 한 건 그것이 요즘 유행하는 인공지능이어서가 아니라, 바로 이 때문이다. 다만 LLM 하나로 끝나는 이야기는 아니었다. 장편에는 맞서야 할 적이 둘 있었고, 그 둘은 서로 다른 손을 필요로 했다.
장편을 쓰는 사람의 두 적
앞에서 본 그 막막한 순간들에는 이름이 있다. 장편을 쓰는 사람을 괴롭히는 첫 번째 적, 기억이다. 세계가 넓어질수록 머리는 자기가 만든 디테일을 소리 없이 잃어버리고, 한 번 어긋난 설정은 대개 작가보다 독자가 먼저 알아차린다.
그런데 적은 하나가 더 있다. 두 번째는 버전이다. 최종, 진짜최종, 진짜진짜최종으로 끝없이 불어나는 원고 파일들, 그리고 결말을 통째로 갈아엎고 싶지만 되돌릴 자신이 없어 결국 한 줄도 손대지 못하는 마음이다. 고치는 일이 무서워지면 글은 거기서 멈춘다.
LLM과 Git에게 맡기다
그래서 나는 기억의 문제를 LLM에게, 버전의 문제를 Git이라는 도구에게 맡기기로 했다. LLM은 내 원고를 읽고 인물과 세계관과 사건의 흐름을 담은 설정집을 대신 정리하고 꾸준히 갱신해 준다. Git은 원고의 모든 변화를 기록해, 무엇을 어떻게 고치든 언제든 며칠 전 상태로 통째로 되돌릴 수 있게 해 준다. 되돌릴 수 있다는 확신이 생기고 나서야, 비로소 겁 없이 고칠 수 있다. 낯선 이름이 나왔다고 겁먹을 필요는 없다. 둘 다 다음 편들에서 그림과 함께 천천히 풀어 나갈 것이다.
다만 시작하기 전에 혹시 생길지 모르는 오해를 풀고가자. 이건 LLM에게 소설을 대신 쓰게 하는 방법이 아니다. 문장도 인물도 결말도 작가가 쓴다. LLM이 하는 일은 따로 있다. 작가가 잊은 설정을 정리하고, 이 인물의 눈동자가 3화에서는 갈색이었는데 38화에서는 검은색이라고 조용히 짚어 주는, 지루하지만 누군가는 반드시 해야 하는 기록과 정리다. 물론 LLM도 틀린다. 엉뚱하게 읽기도 하고 없는 사실을 그럴듯하게 지어내기도 한다. 그래서 마지막에 확인하고 결정하는 사람은 늘 작가여야 한다. 운전대는 작가가 잡고 LLM은 옆자리에서 지도를 든다. 이 원칙은 이 연재 내내 되풀이될 것이다.
앞으로의 이야기
그러니 코딩을 몰라도, Git이라는 말을 난생처음 들어도 괜찮다. 워드나 한글로 써 둔 원고가 있어도 걱정할 것 없다. 그것을 가져오는 방법부터 다룰 것이다. 정말로 필요한 것은 무료 프로그램 몇 개를 깔아 볼 약간의 의지뿐이다.
앞으로 이 연재는 LLM과 설정집과 Git이 각각 무엇인지 짧게 짚는 데서 출발해, 프로그램을 깔고 기존 원고를 가져오고, 원고를 넣으면 인물 사전이 저절로 만들어지는 과정을 지나, 매일 쓰고 정리하고 저장하는 작업의 리듬과, 깔아 둔 복선을 점검하고 설정 충돌을 잡아내고 겁 없이 결말을 뜯어고치는 단계까지 천천히 따라갈 것이다. 한 편을 읽을 때마다 당신의 원고 폴더는 조금씩 살아 있는 설정집으로 바뀌어 갈 것이다.
다음 편에서는 앞에 말한 LLM, Git에 대해 조금 더 자세히 들여다보려 한다. 장편소설이라는 거대한 행성에서, 왜 하필 기억과 버전이 그토록 집요하게 작가의 발목을 잡는지부터.
3막 구조 : 이야기를 설정·대립·해결의 세 부분으로 나누는 고전적 서사 구조. 주로 시나리오 작법에서 쓰이며, 1막(발단과 인물·세계 소개), 2막(갈등의 전개), 3막(절정과 결말)으로 진행된다.
LLM : 거대 언어 모델(Large Language Model). 방대한 텍스트를 학습하여 사람의 언어를 이해하고 생성하는 인공지능 모델을 말한다. ChatGPT(OpenAI), Claude(Anthropic), Gemini(Google) 등이 대표적이다.
Git : 파일의 변경 이력을 시점 단위로 기록·관리하는 분산 버전 관리 시스템(Distributed Version Control System). 2005년 리누스 토발스가 개발했으며, 임의의 과거 시점으로 복원·비교·병합할 수 있어 오늘날 소프트웨어 개발의 표준 도구로 자리 잡았다.