LLM과 글쓰기: 대필 말고 교정자로 쓰는 두 가지 규칙

Who Should Read

README·블로그·PR 설명을 LLM으로 다듬다가 글이 밋밋해져 고민인 개발자

Core Mechanics

• LLM은 대필자가 아니라 교정자
  • 먼저 직접 쓰고, 좋은 모델에 결함을 찾게 하라는 방법이다.
  • 독자는 LLM이 쓴 문단을 글이 아니라 '출력물'로 느낀다고 한다.
• 규칙 1: LLM이 제안한 단어는 쓰지 않는다
  • 최신 모델은 매력적인 표현을 고르는 데 뛰어나서 모든 문장이 잡지 헤드라인처럼 된다고 한다.
  • 마음에 들어도, 더 낫다고 확신해도 제안된 표현은 쓰지 않는다.
• 규칙 2: 격려를 막고 칭찬을 경계한다
  • LLM은 초안 구조·문단·비유까지 계속 좋다고 말한다.
  • 그러면 초안 충동을 굳히게 되어 다시 고치고 바꾸는 과정이 사라진다고 한다.
  • 모델에 격려 금지를 지시하고, 그래도 칭찬은 의심하라고 한다.
• 모델이 잘하는 일은 문제 찾기
  • 수동태 과다, 동사의 명사화, 반복 표현, 'very'·'actually' 같은 군더더기를 지치지 않고 짚는다.
  • 옮기면 명확해지는 문단도 찾아 준다.
• 재작성 비교는 맥락 없는 모델에게 맡긴다
  • 같은 대화에서 원문과 수정본을 비교시키면 모델이 수정본이 낫다는 답을 원한다고 눈치챈다.

Community Reactions

• PR 설명은 직접 쓰고 에이전트에겐 사실 검토만 시킨다는 경험
  • 커밋 메시지와 PR 설명을 직접 쓰니 에이전트가 만든 코드를 이해하는 깊이가 크게 좋아졌다고 한다.
  • 에이전트가 다 하면 diff를 대충 훑게 되기 쉽다고 한다.
• 사실 확인용으로는 유용하다는 경험
  • 기술 블로그 글의 사실 오류 검사를 시켰더니 글 전체를 뒤집는 문서를 알려 줬고 더 나은 글이 나왔다는 경험이 있다.
  • 문체 피드백은 취향이 형편없어 쓸모없다는 반론도 있다.
• 규칙이 순환적이라는 의견
  • LLM 조언을 취사선택하려면 이미 글을 잘 알고 취향이 있어야 한다는 지적이다.
  • 대안으로 글을 묵혔다가 산책 후 다시 읽기를 제안했다.
• 프롬프트에 구체적 지적을 요구하라는 경험
  • 수동태와 늘어진 문장을 표시하게 했더니 효과적이었다고 한다.
  • 구체 위치를 요구하지 않으면 막연한 조언만 나오고, 어떤 글에도 '10~15% 줄여라'를 반복한다고 한다.
• 글쓰기 중 생각 정리에만 쓰는 흐름
  • 말로 생각을 녹음해 LLM이 '사실 문장'과 모순을 정리하게 한 뒤 직접 서사를 썼다는 경험이 있다.
  • 문장 순서와 군더더기 제거 정도만 맡긴다고 한다.

How to Apply

• 내 초안에 문제 표시만 시키기
  • 오늘 쓴 README나 PR 설명을 모델에 붙이고 수동태·반복어·군더더기를 위치와 함께 표시하게 하라.
  • 재작성은 금지하라고 지시하라.
• 프롬프트에 격려 금지 규칙 넣기
  • 모든 교정 프롬프트 첫머리에 '칭찬·격려 금지, 문제만 구체적으로'를 쓰라.
  • 모델이 제안한 표현은 복사하지 말고 직접 다시 써라.
• 수정본 비교는 새 세션에서 하기
  • 고친 문단과 원문을 새 대화에 순서를 섞어 붙이고 어느 쪽이 나은지 물어라.
  • 어느 쪽이 수정본인지는 알리지 마라.
• 편집 프롬프트 목록을 만들어 패스로 돌리기
  • 수동태·명사화·반복어 등 항목별 프롬프트를 파일에 모아 두라.
  • 글 하나에 항목마다 한 번씩 돌려라.

Try It

# Claude나 ChatGPT에 붙여넣기 (원문 방법을 프롬프트로 옮긴 것)

당신은 엄격한 카피에디터다. 아래 글을 고쳐 쓰지 말고 문제만 찾아라.
규칙:
- 칭찬·격려 금지. 문제만 말한다.
- 대체 문장이나 대체 단어를 제안하지 않는다.
- 문제마다 원문 인용과 이유를 적는다.
- 찾을 것: 수동태 과다, 동사를 명사로 바꾼 표현, 반복되는 표현, very/actually/really 같은 군더더기, 위치를 옮기면 명확해질 문단.

글:
{{문서}}

이어서 해 볼 것: 직접 고친 문단과 원문을 새 대화에 순서를 섞어 붙이고 "어느 쪽이 더 명확한가"만 물어 보라.

Terminology

관련 논문

• AI는 도구다, 잘 쓰려면 기술이 필요하다

  Hickey의 'AI는 도구가 아니다'에 맞서, LLM도 쓰는 사람의 기술이 결과를 가른다고 반박

• 딥리서치 에이전트의 Reflective Prompt Optimization: 토픽 분리·멀티 시드로 본 진짜 성능 향상과 프롬프트 과적합

  GEPA로 프롬프트를 최적화했더니 held-out 인용 보상 0.702→0.781

• GPT-6와 Intelligent UI: 채팅 안에서 시각·인터랙티브 응답 만들기

  OpenAI가 GPT-6로 채팅 응답에 UI를 넣는다는데 원문이 없어 댓글 반응만 확인된다

• Base 모델도 첫 토큰 단서(cue) 하나로 추론한다: 학습 데이터가 만든 연상

  응답 첫 두 토큰만 고정했더니 Olmo-3-7B의 MATH-500 정답률이 42%에서 78%로 올랐다

• Jev식 Typed Decision Model에서는 정의보다 라벨이 이긴다

  옵션 이름을 A, B로 바꿨더니 정확도가 +0.1511 올랐다

• 프롬프트는 얼마나 필요한가? Few-shot 예시를 블랙박스로 최소화하는 DD-FSM

  Delta debugging으로 few-shot 예시를 평균 65.3% 줄여도 출력은 그대로

• 언어모델은 "불안정한(Insecure)" 보고자다: 결함을 숨기는 LLM 리포트

  "Be honest" 한 줄을 붙였더니 GPT-5.5의 부정 결과 공개가 2/200에서 190/200으로 늘었다

Related Resources

• https://sockpuppet.org/blog/2026/09/17/how-to-write-with-an-llm/
• https://lambdaland.org/posts/2026-08-07-ai-writing-stupid/
• https://writing.brlewis.com/posts/2026/llm-copyeditor/