LLM으로 글을 쓰면 지식의 지퍼가 열려 있다 (Bryan Cantrill)

TL;DR Highlight

LLM으로 쓴 LinkedIn 글은 티가 나서 독자가 읽기를 멈춘다

Who Should Read

블로그·LinkedIn·사내 공지를 LLM으로 대신 쓰게 하는 개발자

Core Mechanics

LLM 글은 문체만으로 티가 난다
- 이모지, 한 문장짜리 문단, "it's not just... but also" 구문, em-dash가 특징으로 꼽힌다.
- LLM 글을 조금이라도 본 사람에게는 이 티가 무시할 수 없을 만큼 눈에 띈다고 한다.
문제는 민망함이 아니라 신뢰다
- 작성자답지 않은 문체를 보면 내용이 진짜인지 LLM이 지어낸 팬픽인지 알 수 없다고 한다.
- 그래서 저자는 읽기를 멈추고, 다른 사람들도 그렇다고 말한다.
LLM은 편집자로는 훌륭하다
- 브레인스토밍, 글 이해, 편집에는 매우 유용하다고 한다.
- 편집 제안은 무시해도 되니 사람 편집자보다 부담이 없다고 한다.
LLM은 글쓴이를 대신하지 못한다
- LLM은 글솜씨가 서툴고 작성자 본인이 아니라는 점이 핵심이라고 한다.
- 진짜 내용도 LLM 틀에 싸이면 독자가 대충 훑거나 진정성을 의심한다고 한다.
결론은 직접 쓰라는 것
- 자기 목소리에 자신감을 갖고 직접 쓰라고 권한다.

Community Reactions

글쓰기는 생각하는 일이라는 의견
- 글을 쓰다가 자기 견해가 크게 바뀐 적이 많다는 경험이 나왔다.
- 설계 문서에서는 이해를 AI에 맡길 수 없다는 의견이다.
공개 여부가 진짜 문제라는 반론
- LLM 글솜씨가 좋아져도 무공개 사용은 싫을 것이므로, 진짜 이유는 사람이 쓴 것처럼 오해하게 만드는 점이라는 의견이다.
- 글쓴이가 내용을 알고 보증하는 글이 아니면 기본적으로 의심한다는 의견도 있었다.
잘 쓰게 시키면 쓸 만하다는 경험
- 글쓰기 샘플과 스킬 파일을 주고 다듬으면 꽤 좋은 결과가 나온다는 경험이 나왔다.
- 특히 절차적인 글에 잘 맞는다고 한다.
사내 문서도 LLM 범벅이 됐다는 경험
- 공지 메일이 길어지고 내용은 얇아져 아무도 링크를 안 눌렀다는 경험이 나왔다.
- 프로젝트 계획도 AI로 쓰이며 일정이 이상해졌다는 경험이 나왔다.

How to Apply

내 글에서 LLM 티 점검하기
- 최근 쓴 사내 공지나 블로그 초안에서 이모지, 한 줄 문단, "not just... but", em-dash를 찾아라.
- 발견된 것은 직접 다시 써라.
LLM 역할을 편집자로 제한하기
- 초안은 직접 쓰고 LLM에는 문제점 지적만 시켜라.
- 제안 중 받아들일 것만 골라 직접 반영하라.
LLM을 쓴 글에는 사용 사실 밝히기
- 요약처럼 LLM을 쓴 부분은 글 끝에 한 줄로 표기하라.
- 원문 링크도 함께 붙여라.

Try It

복사해서 바로 해보기

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

너는 글을 대신 쓰는 사람이 아니라 편집자다. 아래 초안을 다시 쓰지 말고 지적만 해라.

[초안]
{{내가 직접 쓴 초안}}

[지시]
1. 논리가 끊기거나 근거가 약한 부분을 번호로 짚어라.
2. 독자가 읽다 멈출 만한 부분을 짚어라.
3. 문장은 대신 써 주지 마라.

이어서 해 볼 것: 지적을 반영해 내가 고쳐 쓴 뒤 다시 붙여넣고 같은 점검을 시켜 보라.

Terminology

LLM tellsLLM이 쓴 글에서 반복되는 티 나는 습관이다. 이모지, 한 줄 문단, em-dash 같은 것이다.

em-dash문장 중간에 쓰는 긴 줄표(—)이다. LLM 글의 상징처럼 여겨진다.

toupee fallacy가발은 티 나는 것만 보여서 가발이 다 티 난다고 믿는 착각이다. 눈치 못 챈 LLM 글은 세지 않는다는 반론에 쓰였다.

Related Resources

https://bcantrill.dtrace.org/2025/12/05/your-intellectual-fly-is-open/