LLM을 대필자가 아니라 교정자로 쓰는 두 가지 규칙

LLM을 글쓰기에 활용하는 방법을 정리한 에세이 하나가 개발자 커뮤니티에서 공유됐다. 결론은 단순하다. LLM에게 글을 대신 써달라고 하지 말고, 교정자로만 부려먹으라는 것이다. 이를 위해 저자는 두 가지 규칙을 제시한다. 모델이 제안한 표현은 한 단어도 쓰지 않는다, 그리고 모델의 격려를 차단한다.

첫 번째 규칙이 중요한 이유는 최신 모델이 '듣기 좋은 문장'을 뽑아내는 데 비정상적으로 능숙하기 때문이다. 모델이 내놓는 문장은 대개 잡지 표지 헤드라인 같은 톤을 띤다. 헤드라인 하나는 훌륭하지만, 그런 문장이 수십 개 이어지는 글을 쓴 사람이 있다면 고개를 갸웃하게 된다. 그래서 저자는 모델이 제안한 구체적 표현을 아예 금지 목록에 올린다. 마음에 들든, 원래 문장보다 낫다고 확신하든 예외는 없다.

두 번째 규칙은 더 미묘하다. 초안을 모델에 넘기면 돌아오는 건 칭찬이다. 그런데 초안은 대부분 나쁘다. 문단은 엉성하고 흐름은 끊기고, 없어도 될 분량이 수백 단어는 붙어 있다. 문제는 이 칭찬이 반복되면서 필자가 1차 초안의 충동에 그대로 안주하게 만든다는 점이다. 원래라면 문단을 갈아엎고 다시 생각했을 자리에서 손을 떼게 되고, 그 '다시 생각하는 과정'이 바로 필자의 목소리를 떠받치는 부분이라는 게 저자의 지적이다. 독자는 무엇이 어긋났는지 정확히 짚지 못해도 인공적인 향이 난다는 사실은 감지한다.

대신 모델이 확실히 잘하는 일이 있다. 기계적인 결함 찾기다. 수동태 과용, 동사를 명사로 바꿔 행위를 흐리는 습관, 같은 표현의 반복, 'very'나 'really', 'actually', 'unfortunately' 같은 군더더기의 남발, 그리고 위치만 옮기면 즉시 명료해지는 문단 두세 개를 찾아내는 데 사람보다 낫다. 사람에게는 지루하고 소모적인 작업이지만 모델은 지치지 않는다.

배경에는 LLM 문체에 대한 문제의식이 있다. 아무리 손을 봐도 모델이 만든 문단은 상당수 독자에게 '글'이 아니라 '출력'으로 읽힌다. 그래서 순서가 중요하다. 먼저 직접 쓴다. 그다음 완성된 원고를 좋은 모델에 넣고 결함을 찾게 한다.

실전 워크플로는 이렇게 굴러간다. 교정용 프롬프트 목록을 미리 만들어 두고 원고 위로 여러 번 패스로 돌린다. 모델에 문제를 지목하게 하고, 지목된 문제마다 문단이나 문장을 직접 다시 쓴다. 그다음 원본과 수정본을 모델에 나란히 보여주고 어느 쪽이 나은지 묻는다. 이때 주의할 점이 있다. 방금 자기가 고쳤다는 맥락을 아는 모델에 물으면 새 버전이 낫다고 말해줄 것이라는 기대가 섞인다. 편집 과정을 모르는 별도의 모델에 판정을 맡겨야 한다.

저자는 탭을 오가며 모델을 설득하는 작업에 지쳐 도구를 직접 만들었다. 첫 프롬프트는 Python과 HTMX, SQLite 백엔드, Tailwind 프런트엔드(CDN이 아닌 로컬 빌드)로 Notion 스타일 편집기를 세우고, 하이라이트와 Genius 스타일 사이드바 주석, 제안 간 앞뒤 이동, 다중 문서와 리비전 추적, 주요 수정 플래그 기능을 붙이는 것이었다. 이후 앞서 만든 편집 프롬프트 목록을 Codex나 Claude, Antigravity 같은 CLI에 태워 돌린다. 이런 도구는 남이 만든 것보다 각자 자기 필요에 맞게 만든 쪽이 낫다는 게 저자의 생각이다.

교정 감각을 기르려면 책 한 권을 권한다. 'Style: Lessons in Clarity and Grace'다. 저자는 이 책이 산문 교정을 자바 코딩처럼 만들어 준다고 표현한다. 지루함의 정도도, 효과도 비슷하다는 것이다. 리처드 가브리엘에게 이 책을 알게 됐다며, 프로그래머라면 책상에 한 권 두고 볼 만하다고 덧붙인다.

마지막 주의사항은 모델의 조언을 전부 받아들이지 말라는 것이다. 저자는 이 글을 GPT-5에 넣어 검토시켰고, 전체 분량이 20% 정도 길다는 지적을 받았다. 아마 맞는 말이지만 고치지 않았다고 한다. 규칙을 지키면서 지루한 작업만 모델에 넘기면, 목소리는 그대로 두고 속도와 완성도만 끌어올릴 수 있다는 것이 이 글의 요지다.