"자동 생성" 대신 "이어 쓰기"를 택한 이유 — 창작 보조 도구 설계 기록

이전에 이 주제로 관점을 한 번 정리한 적이 있습니다. 자동 생성이 아니라 이어 쓰기여야 한다는 이야기였는데, 그때는 문제 제기에 가까웠습니다. 이번 글은 그 뒤의 기록입니다. 실제로 메리톡톡을 만들면서 어디서 멈출지, 무엇을 포기할지를 코드 단위로 정해야 했고, 그 결정들을 남겨둡니다.

가장 먼저 확인한 것은 제 자신의 반응이었습니다. 초기 버전에서 문단 하나를 통째로 생성해 화면에 띄워봤는데, 문장은 꽤 그럴듯했는데도 손이 멈췄습니다. 고쳐 쓸지 지울지를 판단하는 동안, 원래 쓰려던 문장이 머릿속에서 사라졌습니다. 잘 쓰인 남의 문장이 내 문장을 덮어쓴 셈입니다.

그때 알았습니다. 창작 보조 도구에서 진짜 위험한 것은 품질이 낮은 결과물이 아니라, 품질이 적당히 높아서 판단을 대신해버리는 결과물입니다. 아래는 그 판단을 작가 쪽에 남기기 위해 내린 결정들입니다.

기준선은 하나였습니다

기능을 정할 때마다 같은 질문을 던졌습니다. "이 기능은 작가의 판단을 돕는가, 대신하는가." 돕는 쪽이면 넣고, 대신하는 쪽이면 빼거나 한 단계 뒤로 물렸습니다.

이 기준은 생각보다 많은 것을 결정합니다. 예를 들어 "다음 문장 추천"은 돕는 쪽에 가깝지만 "다음 화 자동 집필"은 대신하는 쪽입니다. "이 인물의 말투가 앞 화와 다릅니다"라는 지적은 돕는 쪽이고, "말투를 고쳐서 반영했습니다"는 대신하는 쪽입니다. 경계는 결과물의 길이가 아니라 결정권이 어디에 남는가에 있었습니다.

다만 이 기준을 지키면 도구가 덜 화려해집니다. 버튼 하나로 한 화가 나오는 화면이 더 강한 인상을 주는 건 분명합니다. 그럼에도 이 쪽을 택한 이유는, 제가 웹소설을 연재해본 사람으로서 계속 쓰게 만드는 도구가 필요했지 대신 써주는 도구가 필요하지 않았기 때문입니다.

네 가지 설계 결정

기준선은 방향만 알려줄 뿐, 실제로는 화면과 코드에서 하나씩 정해야 합니다. 제안의 길이를 몇 문장으로 할지, 제안을 화면 어디에 놓을지, 무엇을 참조하고 무엇을 참조하지 않을지, 되돌릴 때 무엇을 되돌릴지. 네 가지 모두 "돕는가, 대신하는가"에서 출발했지만 답은 각각 달랐습니다.

어디까지 제안하고 어디서 멈추는가

제안 길이의 상한을 정하는 데 시간이 가장 오래 걸렸습니다. 여러 길이를 놓고 직접 써본 결과, 저는 한 문장에서 두 문장 사이에서 멈추는 쪽을 택했습니다. 그보다 짧으면 다음 단어를 고르는 수준이라 도움이 되지 않고, 문단 단위로 넘어가면 앞서 말한 덮어쓰기가 일어납니다.

더 중요한 건 멈추는 위치입니다. 문장이 완결된 지점이 아니라 다음 선택지가 갈리는 지점에서 멈추게 했습니다. 인물이 대답하기 직전, 장면이 전환되기 직전처럼 작가가 방향을 정해야 하는 자리입니다. 완결된 문단을 내놓으면 작가는 검수자가 되지만, 갈림길에서 멈추면 작가는 여전히 결정자입니다.

제안을 본문에 바로 넣지 않는 이유

많은 편집기가 제안을 회색 글씨로 본문 안에 미리 그려줍니다. 편리하지만 창작에는 맞지 않는다고 판단했습니다. 제안이 본문 자리에 들어가 있으면 거절하는 데 비용이 듭니다. 이미 거기 있는 문장을 지우는 일과, 옆에 있는 문장을 가져오지 않는 일은 심리적으로 전혀 다릅니다.

그래서 제안은 본문 옆 영역에 카드 형태로 둡니다. 작가가 명시적으로 가져오기를 눌렀을 때만 본문에 들어갑니다. 기본 상태가 "들어오지 않음"이 되도록 한 것이 핵심입니다. 대신 가져온 뒤에는 곧바로 수정할 수 있게 커서를 그 문장 끝에 둡니다. 받아들이는 순간에도 그대로 두지 말고 고치라는 신호입니다.

설정집은 참조하되 문체는 건드리지 않습니다

인물 설정과 세계관을 정리해두면 제안이 훨씬 정확해집니다. 다만 여기서 선을 그었습니다. 설정집은 사실 관계를 맞추는 데만 씁니다. 인물의 나이, 관계, 이미 벌어진 사건, 지명 같은 것들입니다.

반대로 문체는 참조하지 않습니다. 과거 원고를 학습해 비슷한 문장을 만들어내는 방향은 기술적으로 가능하지만, 그렇게 되면 작가가 자기 문체 안에 갇힙니다. 연재 중반에 문체를 바꾸고 싶어질 때 도구가 계속 예전 문체로 끌어당기는 상황이 생깁니다. 그래서 문체 관련 기능은 제안이 아니라 지적으로만 만들었습니다. "이 대사는 3화의 말투와 다릅니다" 정도까지 알려주고, 고치는 것은 작가가 합니다.

되돌리기와 이력을 남깁니다

제안을 가져온 문장은 내부적으로 표시를 남깁니다. 나중에 "이 문단에서 도구가 개입한 부분이 어디였는지" 확인할 수 있게 하기 위해서입니다. 이 표시는 화면에 상시로 보여주지 않습니다. 쓰는 동안 눈에 띄면 신경이 쓰이고, 그것 자체가 문장에 영향을 줍니다.

되돌리기는 편집기 기본 기능에 맡기지 않고 별도로 만들었습니다. 제안을 가져온 동작 하나가 여러 번의 입력으로 기록되면, 일반적인 실행 취소로는 한 번에 걷어내기가 어렵기 때문입니다. 가져오기는 하나의 되돌릴 수 있는 단위로 묶습니다.

이력을 남기기로 하면서 저장 구조도 바뀌었습니다. 원고 본문만 저장하면 되던 것이, 문단마다 개입 구간과 시각을 함께 들고 다녀야 하는 구조가 됐습니다. 용량이 늘고 마이그레이션도 한 번 필요했지만, 이 정보가 있어야 나중에 "이 도구가 내 원고를 얼마나 바꿨는가"라는 질문에 답할 수 있습니다. 작가가 그 질문을 던질 권리는 남겨두고 싶었습니다.

포기한 것들

이 결정들에는 대가가 있었습니다. 정직하게 적어두는 편이 나중에 판단을 다시 할 때 도움이 됩니다.

결정얻은 것포기한 것

한두 문장에서 멈춤작가가 방향을 잡을 여지"막힌 화를 한 번에 뚫어준다"는 체감
제안을 본문 밖에 배치거절 비용이 거의 없음흐름이 한 번 끊기는 조작 단계
문체는 참조하지 않음문체 변화의 자유즉각적인 어울림, 손댈 곳이 늘어남
개입 이력을 남김되돌리기와 사후 확인저장 구조가 복잡해지고 용량이 늚

가장 아쉬운 칸은 두 번째입니다. 제안을 옆에 두면 한 번 더 눈을 옮기고 한 번 더 클릭해야 합니다. 이 마찰을 없애달라는 의견이 나올 것도 예상하고 있습니다. 다만 이 마찰이 곧 판단하는 시간이기도 해서, 지금은 유지하기로 했습니다. 나중에 바꾸더라도 설정으로 열어주는 방식일 것 같습니다.

마치며

기준은 하나였습니다. 판단을 돕는가, 대신하는가. 그 기준에서 제안은 갈림길에서 멈추고, 본문 밖에 놓이고, 설정집만 참조하고, 개입 흔적을 남깁니다. 네 결정 모두 도구를 덜 화려하게 만들었지만 계속 쓰게는 만들었습니다.

비슷한 도구를 만들고 계시다면, 오늘 해볼 만한 한 가지는 이겁니다. 자기 도구가 내놓은 결과를 작가 입장에서 거절해보는 것입니다. 거절하는 데 몇 번의 조작이 필요한지 세어보면, 그 도구가 통제권을 누구에게 두고 있는지가 바로 드러납니다.