TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 27 READS

LLM에게 글을 맡기되 단어는 뺏기지 마라: 실무형 글쓰기 규칙

LLM에게 글을 맡기되 단어는 뺏기지 마라: 실무형 글쓰기 규칙
SOURCE IMAGE · HACKER NEWS

생성형 AI로 글을 쓰는 일이 흔해지면서, 역설적으로 'AI 냄새'가 나는 글에 대한 독자의 거부감도 커지고 있다. 보안 분야 필자 토마스 프타첵(sockpuppet.org)은 이 문제를 정면으로 다루면서, LLM을 유령작가(ghostwriter)가 아니라 교열자(copyeditor)로만 쓰라는 구체적인 방법론을 제시한다. 핵심은 두 개의 규칙과 한 가지 작업 분담이다. 규칙을 지키면 글의 목소리는 그대로 두면서도 지루한 노동만 모델에 넘길 수 있다는 것이 그의 주장이다.

왜 첫 문장부터 직접 써야 하는가

필자는 독자가 LLM 특유의 표현을 '조 단위(parts per trillion) 농도'로도 감지한다고 말한다. 아무리 문장을 거칠게 다듬고 사람 손길을 덧입혀도, LLM이 만든 문단은 상당수 독자에게 '글'이 아니라 '출력물'로 읽힌다는 것이다. 그래서 나쁜 소식부터 인정하고 시작한다. 글은 결국 스스로 써야 한다. 대신 다 쓴 뒤 좋은 모델에 먹여 결함을 찾게 하라는 것이 그의 2단계 방법이다. 이 구도에서 모델의 역할은 문장을 대신 짓는 것이 아니라, 이미 쓴 문장의 문제를 지적하는 데 한정된다.

두 개의 규칙

첫 번째 규칙은 'LLM이 제안한 단어는 단 하나도 쓰지 말라'다. 최신 모델은 듣기 좋은 표현을 고르는 데 초인적으로 능한데, 바로 그 점이 함정이다. 필자는 프런티어 모델이 모든 문장을 잡지 신문 헤드라인처럼 쓰는 모드에 갇혀 있다고 비유한다. 헤드라인은 좋지만, 기사 전체가 헤드라인 수십 개로 채워져 있다면 이상하게 느껴진다. 그래서 그는 '지적 개인보호장비'처럼 이 규칙을 엄격히 지키라고 한다. 그 표현이 마음에 들든, 내 원문보다 낫다고 확신하든 상관없이 실격 처리하라는 것이다.

두 번째 규칙은 '모델이 나를 칭찬하게 두지 말라'다. 원고를 넘기면 LLM은 대개 '훌륭하다'고 응수한다. 하지만 초고는 대부분의 문단이 나쁘고, 흐름이 엉켜 있으며, 750단어쯤은 군더더기다. 모델의 칭찬을 믿으면 초고의 충동을 오히려 강화하게 되고, 원래라면 고쳐 쓰고 다시 생각했을 부분을 그대로 밀어붙이게 된다. 그 재고(再考)의 과정이야말로 글쓴이의 목소리를 지탱하는 부분이다. 필자는 한동안 '나는 저자가 아니라 온라인 매체의 편집자'라는 거짓 전제로 프롬프트를 열었지만, 이 경우 모델이 가상의 '매체 방침'에 과적합하는 부작용이 있었다고 털어놓는다. 그의 현실적 조언은 모델에 격려를 금지시키고, 그럼에도 새어 나오는 칭찬을 극도로 경계하라는 것이다.

지루한 일은 전부 모델에게

반대로 모델이 압도적으로 잘하는 영역은 결함 탐지다. 수동태 남용, 동사를 명사로 굳혀 행동을 파묻는 습관, 같은 표현의 반복, 그리고 'very' 'really' 'actually' 'unfortunately' 같은 군더더기 부사가 톱밥처럼 흩뿌려진 자리를 지치지 않고 짚어낸다. 위치만 옮겨도 명료해지는 두세 개의 문단을 찾아주기도 한다. 이런 기계적 점검은 사람에겐 소모적이지만 모델은 피로하지 않는다. 필자는 이런 교열의 '설계도' 역할을 하는 책으로 조지프 윌리엄스의 'Style: Lessons in Clarity and Grace'를 강력히 추천하며, 산문 교열을 마치 자바 코딩처럼 반복 가능하고 효과적인 작업으로 바꿔준다고 표현한다. 책을 읽고 편집 지침을 프롬프트 목록으로 정리한 뒤, 이를 여러 번의 패스로 원고에 돌리라는 것이다.

다만 여기서도 두 번째 규칙의 변형이 튀어나온다. 문단을 고쳐 쓴 뒤 원본과 새 버전 중 무엇이 나은지 물으면, 모델은 사용자가 방금 새로 썼다는 맥락을 눈치채고 새 버전을 편들기 쉽다. 그래서 비교 판정은 편집 과정을 모르는 별도의 모델에 맡기라고 조언한다. 필자는 이 흐름을 자동화하려 파이썬·HTMX·SQLite·Tailwind 기반의 노션식 교열 워크숍 도구를 직접 만들었고, 각 편집 프롬프트를 Codex·Claude·Antigravity CLI로 돌리게 했다고 밝힌다. 그러면서 남의 도구보다 각자 자기에게 맞게 만든 도구가 늘 더 낫다고 덧붙인다.

한국의 실무자에게 이 글의 쓸모는 분명하다. 문서, 기술 블로그, 릴리스 노트, 제안서를 쓸 때 LLM을 초안 생성기로 쓰면 결과물의 신뢰도와 개성이 함께 깎이지만, 교열 도구로 한정하면 속도와 품질을 동시에 얻을 수 있다. 다만 한계도 있다. 이 방법은 영어 산문과 필자 개인의 취향에 맞춰진 경험칙이며, 한국어 문체나 조직의 공식 문서 톤에 그대로 적용되지는 않는다. 무엇보다 필자 자신도 마지막에 인정한다. GPT-5에 이 글을 넣자 '20% 너무 길다'는 지적이 돌아왔고, 아마 맞는 말이지만 그는 고치지 않겠다고 한다. 모델의 조언을 전부 받아들이지 않는 것, 끝내 '나답게 두는 것'이야말로 그가 말하는 규칙의 종착점이다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://sockpuppet.org/blog/2026/09/17/how-to-write-with-an-...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...