LLM으로 글쓰는 법 — 유령작가가 아니라 교정자로 활용하기
독자는 LLM이 생성한 문장을 즉시 알아채므로, 글은 직접 쓰고 LLM은 교정자(copyeditor)로만 써야 한다는 주장입니다. 모델이 제안하는 표현은 단 하나도 쓰지 말 것, 모델의 격려를 받아들이지 말 것이라는 두 규칙과 함께, 문제 지적·수정본 비교·CLI 기반 편집 도구까지 실전 워크플로를 제시합니다.

본문
sockpuppet.org에 올라온 이 글은 LLM 시대의 글쓰기 방법론을 다룹니다. 필자는 프로그래머로서 스스로도 이 글을 쓰는 것이 불편했다고 고백하지만, 이 조언이 중요하고 논박하기 어렵기 때문에 정리했다고 밝힙니다. 출발점은 냉정한 전제입니다. 독자는 LLM의 단어를 조 단위(parts per trillion) 농도로도 감지하며, 아무리 손으로 문장을 문질러 인간답게 만들어도 LLM 문단은 상당수 독자에게 글이 아니라 출력물로 읽힙니다. 그러니 나쁜 소식부터 — 글은 직접 써야 합니다. 다만 LLM은 유령작가(ghostwriter)가 아니라 교정자로 쓰면 여전히 대단히 유용합니다.
규칙 1: LLM이 제안하는 단어는 하나도 쓰지 않는다
이 규칙을 어기는 것이 문제의 시작이라고 필자는 말합니다. 프론티어 모델은 그럴듯한 표현을 골라내는 데 초자연적으로 뛰어나며, 그것이 모델의 본질이기 때문입니다. 문제는 미묘합니다. 프론티어 모델은 모든 문장을 잡지 헤드라인처럼 쓰는 모드에 갇혀 있는데, 헤드라인 자체는 좋지만 헤드라인 수십 개로 이뤄진 기사를 쓰는 사람을 보면 의아해할 것이라는 비유를 듭니다. 그래서 모델이 제안하는 구체적 문구는 무조건 실격 처리해야 한다고 주장합니다. 이는 일종의 지적 개인보호장비이며, 자신이 좋아하는 표현이더라도, 기존 문장보다 낫다고 확신하더라도 예외가 없습니다. 모델이 당신의 글을 Velveeta 치즈처럼 가공된 맛으로 바꾸는 방식을 당신이 전부 간파할 수는 없기 때문입니다.
규칙 2: 격려를 피하라
더 미묘한 문제는 LLM이 영향력 행사를 통해 글을 오염시킨다는 점입니다. 어떤 글이든 모델에 건네면 칭찬이 돌아오지만, 초고의 현실은 다릅니다. 문단 대부분이 나쁘고, 주제 흐름은 어수선하며, 최소 750단어는 불필요합니다. 그런데 모델은 전체 구조를 칭찬하고, 이어서 문단과 전환, 단어 선택과 은유, 대중문화 인용까지 순차적으로 격려합니다. 이 격려를 들으면 초고의 충동을 그대로 굳히게 됩니다. 원래라면 편집하고, 다시 생각하고, 문단을 갈아엎었을 텐데, 바로 그 재검토 과정이 필자의 문장대로 문체를 지탱하는 하중을 받는 부분(load-bearing parts of your voice)입니다. 독자는 무엇이 잘못됐는지 짚어내지 못해도 글이 인공 조미료 맛이 난다고 느낍니다. 필자는 몇 년간 자신이 저자가 아니라 온라인 매체의 편집자라고 거짓말하며 교정 프롬프트를 열었지만, 모델이 가상의 매체 목표에 과적합해 지나치게 나가는 경우가 많았다고 합니다. 현실적 조언은 모델에게 격려를 금지시키고, 칭찬에는 극도로 경계하라는 것입니다.
모델이 실제로 잘하는 것
문제를 표시하는 일에는 탁월합니다. 수동태 남용, 동사를 명사화해 동작을 묻어버리는 습관, 같은 표현과 단어의 반복, very·unfortunately·really·actually처럼 톱밥처럼 여기저기 붙은 군더더기, 그리고 위치만 옮겨도 명료해지는 문단 두세 개를 기계적으로 찾아냅니다. 이런 체크는 사람도 할 수 있지만 지루하고 지치는 일인데 모델은 지치지 않습니다. 필자는 이런 편집의 설계도 같은 책으로 Style: Lessons in Clarity and Grace를 추천하며, Richard Gabriel을 통해 알게 됐고 교정 작업을 Java 코딩처럼 똑같이 지루하고 똑같이 효과적인 절차로 바꿔준다고 평가합니다.
실전 워크플로와 도구
방법은 단순합니다. 책 같은 자료로 편집 체크리스트를 만들어 프롬프트 목록화하고, 모델에게 문제 지적을 시킨 뒤, 각 문제를 직접 다시 쓰고, 원문과 수정본을 편집 맥락이 없는 모델에 제시해 어느 쪽이 나은지 묻습니다. 방금 고친 사실을 모델이 알면 새 버전이 낫다고 말하려 하기 때문에 맥락 분리가 필요합니다. 필자는 탭을 오가며 모델을 설득하는 데 지쳐 직접 워크숍 도구를 만들었습니다. Python, 상호작용용 HTMX, SQLite 백엔드, Tailwind 프런트엔드(CDN이 아닌 로컬 빌드), Notion 스타일 에디터, 하이라이팅과 Genius 스타일 사이드바 코멘터리, 제안 간 앞뒤 이동, 다중 문서와 리비전 추적을 갖추고, 편집 프롬프트들을 Codex·Claude·Antigravity CLI로 실행하게 했습니다. 다만 자신의 도구보다 각자 직접 만든 것이 더 낫다고 덧붙입니다.
마지막 조언
모델의 교정 조언을 전부 받아들이지 말라는 것이 규칙 2의 따름정리입니다. 필자는 이 글을 GPT-5에 넣었더니 전체가 20% 길다는 답을 받았고, 아마 맞을 것이라면서도 고치지 않기로 했다고 씁니다. 자기답게 남겠다는 선택입니다.
Hacker News 반응
- @jamiejquinn — '그 재검토들이 당신 문체의 하중을 받는 부분이다'라는 문장을 인용하며, LLM이 가장 좋아하는 비유인 load-bearing을 (아마도 의도적 아이러니로) 쓴 점이 마음에 들었다고 합니다. '모델의 교정 조언을 전부 받아들이지 말라'는 조언에도 동의하며, 자신은 교육 자료 검토에 LLM을 쓰는데 가르침의 요점을 이해하지 못하는 경우가 많고, 글에 대한 성찰을 촉발하는 데는 좋지만 여전히 idiot savant라고 평가합니다.
- @ameliaquining — 그것이 의도적 농담이 아닐 가능성은 전혀 없다고 단정합니다.
- @abc3354 — 기대했던 것보다 훨씬 좋은 글이었다며, Style: Lessons in Clarity and Grace라는 책에 대해 아는 사람이 있는지, 재미있는 책 같다고 묻습니다.
- @stackghost — 그 책은 보증할 수 없지만 Dreyer's English는 추천할 수 있다며, 적절한 단어(le mot juste)를 찾는 것을 즐기는 사람에게는 유쾌하면서도 훌륭한 스타일 가이드라고 답합니다.
- @bobmarleybiceps — Style은 매우 짧은 책으로, 좋은 조언이 담겼고 꽤 유명하다고 말합니다. 글을 많이 쓰는 직업에 종사하는 지인을 아는데 상급자가 피드백을 얼마나 명료하게 전달하는지 보고 놀랐고, 기술 업계 사람들도 문서 커뮤니케이션 능력이 더 좋았으면 한다는 바람을 덧붙입니다.
원문: Hacker News / 번역·요약: Trawling