# 🤖🔎 글의 해부학 — 오래 읽히는 글 9편의 구조를 뜯어서 얻은 글쓰기 절차

- URL: https://soohan.dev/notes/hanibot/research/writing-research/anatomy-of-good-writing
- Category: notes/hanibot/research/writing-research
- Published: 2026-08-26
- Tags: writing, editing, research
- Author: 박수한 (Soohan Park)

> 잘 쓴 글이 왜 읽히는지를 내용이 아니라 구조에서 찾았다. 오래 읽힌 글 9편의 첫 문장·전개·마무리를 해부하고 글쓰기론 원전 12편과 대조해, 이 블로그의 글쓰기 스킬이 따르는 절차와 그 근거를 정리했다.

---

잘 쓴 글을 흉내 내면 대개 표면만 남는다. 문장은 비슷한데 읽히지 않는다. 그래서 이번 리서치는
문장을 모으는 대신 구조를 뜯었다. 첫 문장이 어디에 놓였는지, 주장이 몇 번째 문단에서 나오는지,
사례가 원칙보다 앞서는지 뒤서는지.

표본은 넷으로 나눴다. 글쓰기론 원전 12편(전문 정독), 오래 읽힌 글 9편(도입·전개·마무리 해부),
고전 교본 8권(한국어 4권 포함), 확산과 인지에 관한 실증 연구 4건. 글은 Hacker News 상위 노출
이력, 재인용 빈도, 장르 다양성(설명문·사고 후기·논쟁문·장애 보고서)을 기준으로 골랐다.

결과는 이 블로그의 글쓰기 스킬 `document:writing-post`
([soohan-skills](https://github.com/soohanpark/soohan-skills))가 됐다. 이 글은 그 스킬이 왜 그
규칙을 따르는지의 근거다. 스킬에는 인물 이름을 뺐지만, 여기에는 누가 무엇을 근거로 그렇게
말했는지를 그대로 남긴다.

## 규칙보다 먼저: 무엇을 최적화할지

리서치를 시작하고 30분 만에 부딪힌 것이 있다. 대가들의 조언이 정면으로 충돌한다. 그래서 "좋은
글의 규칙 20가지" 같은 목록은 만들 수 없었다. 규칙마다 전제가 다르고, 그 전제는 이 글로 무엇을
얻으려 하는가 하나로 갈린다.

Dan Luu는 자기 글의 도달을 늘리는 방법을 알면서 쓰지 않는다. 그가 직접 나열한 목록 — 클릭베이트
제목, 분노를 유발하는 어조, 잦은 발행, 유명인 추천, 뜨거운 주제, 일부러 과격한 프레이밍.
"확신에 찬 단정형 문장이 독자를 모은다"는 것도 관찰해 적어놨지만, 자기 목적에 맞는 선택은
아니라고 판단했다.

반대로 Scott Alexander는 목적이 설득이라고 못 박고 시작한다. 그래서 부족 신호(tribal signal),
미세 유머, 선제 반박을 적극적으로 권한다. 둘 다 맞다. 목적이 다를 뿐이다.

확산에 관한 실증도 이 판단에 재료를 준다. Berger와 Milkman이 뉴욕타임스 3개월치 기사를 전수
분석한 결과, 각성도가 높은 감정(경외·분노·불안)은 공유를 늘리고 각성도가 낮은 감정(슬픔)은
줄인다. 놀라움·흥미·실용성을 통제해도 유지된다. 도달을 원하면 당길 레버가 분명히 있다. 당길지
말지는 선택이고, 그 선택을 먼저 해야 나머지 항목이 방향을 갖는다.

이 블로그는 도달이 아니라 "정확하게, 도움이 되게"를 골랐다. 아래는 그 선택 위에서 정리한 것이다.

## 1. 겪은 것만이 복제되지 않는다

해부한 글 아홉 편 중 여덟 편의 출발점이 문장이 아니라 소재였다. 잘 쓴 글은 대체로 잘 고른 글이다.

Julia Evans의 기준이 가장 실용적이다. 내가 막혔던 것을 써라. 이게 강력한 건 겸손해서가 아니라
범위를 자동으로 좁혀주기 때문이다. 그의 예시가 정확하다 — "Go에 대해 쓴다"는 막막한데, "Go에서
내가 막혔던 것"으로 바꾸는 순간 갑자기 명확해진다. 데드락에 대해 쓰면 되니까. 소재 선정이 곧
개요 작성이다.

단서가 하나 붙는다. 막혔던 기억이 생생할 때 쓰라는 것이다. "고생하던 때가 어땠는지 기억나지
않으면, 내가 무엇을 배웠는지를 잘못 짚기가 아주 쉽다." 시간이 지나면 우리는 배운 것을 재구성하고,
재구성된 교훈은 대체로 뻔하다.

Simon Willison — Hacker News에서 3년 연속 가장 많이 읽힌 블로거 — 은 세 갈래로 나눈다. 배운 것,
만든 것, 발견한 것. 그가 TIL 형식을 "가장 해방적인 형식"이라 부르는 이유는 독창성 요구를 아예
제거하기 때문이다. "방금 알아냈다, 여기 내 메모다, 당신에게도 쓸모 있을지 모른다." 그는 이걸 4년간
346편 넘게 썼고, 대부분 10분 안에 쓴다.

가장 반직관적인 발견은 Dan Luu에게서 나왔다. 그는 초기에 "너무 뻔해 보이는 건 안 쓴다"는 원칙이
있었고, 나중에 그게 실수였다고 적었다. 뻔해서 안 쓰려던 글 하나가 나머지 글 전부를 합친 것보다
많은 "덕분에 도움이 됐다"는 반응을 받았다. 뻔함의 판단 기준이 나 자신이라는 게 함정이다.

소재를 거를 때는 Paul Graham의 곱셈을 쓴다. 유용한 글은 중요도 × 새로움 × 정확성 × 강도의
곱이다. 곱셈이라 하나라도 0이면 전체가 0이다. 중요도는 다시 "몇 명에게 중요한가 × 그들에게 얼마나
중요한가"로 쪼개진다.

> 글쓰기의 기본은 문장에 있지 않고, 한 사람의 삶 안에 있다. — 이오덕, 『우리글 바로쓰기』

## 2. 한 문장으로 압축되지 않으면 아직 쓸 때가 아니다

Randy Olson은 해양생물학자로 일하다 영화감독이 된 사람이고, 과학자들의 글이 왜 지루한지를 한
줄로 진단했다. "그리고, 그리고, 그리고"의 나열이기 때문이다. 사실을 순서대로 쌓으면 정보는
전달되지만 읽히지는 않는다.

그의 해법이 ABT다. And(맥락, 독자와 합의된 상태) · But(갈등, 그 합의가 깨지는 지점) ·
Therefore(그래서 무엇이 달라지는가). 해부한 표본에서 이걸 역추출해보면 예외 없이 나온다.

- Choose Boring Technology — 기술 선택은 하나하나 보면 다 합리적이다(And). 그런데 새 기술을
  도입할 수 있는 총량에는 예산이 있는데 아무도 그걸 합산해서 세지 않는다(But). 그래서 "혁신
  토큰"이라는 한정된 자원으로 세라(Therefore). But 자리에 놓인 문장이 이 글 전체의 존재 이유다.
- Parse, don't validate — 타입 주도 설계를 간결하게 설명하려고 오래 애썼다(And). 그런데 validate는
  확인한 정보를 버려서 같은 검사를 코드 곳곳에서 반복하게 만든다(But). 그래서 검증하지 말고
  파싱하라(Therefore). Therefore가 그대로 제목이 됐다.

저널리즘에서는 이 한 문단을 nut graf라 부르고, 도입부(lede) 바로 다음 두세 번째 문단에 놓는다.
역할은 "이 글이 무엇에 관한 것이고 왜 계속 읽어야 하는지"를 독자에게 통보하는 것이다. 여기까지
읽고 나가는 독자도 요지는 가져가게 하는 게 목적이다.

## 3. 도입 — 제목 포함 세 문장 안에 두 질문

Michael Lynch의 규칙이 가장 검사하기 쉽다. 독자는 도착하자마자 두 가지를 묻는다 — 이 글이 나를
위한 것인가, 읽으면 뭐가 남는가. 여기에 답할 예산은 제목과 첫 세 문장이다. "두 번째 문단에
들어섰는데 아직 둘 다 답하지 못했다면 곤란한 상태다."

표본 여덟 편의 첫 문장을 그대로 놓고 비교했다. 여덟 편 중 배경 설명으로 시작한 글은 하나도 없다.
배경은 독자가 계속 읽기로 결심한 뒤에 온다. 유형은 여섯 가지로 갈렸다.

**고백** — "Historically, I've struggled to find a concise, simple way to explain what it means to
practice type-driven design." (Alexis King, Parse, don't validate). 전문가가 독자와 같은 높이에서
출발한다. 그리고 400단어쯤 뒤에 세 단어 슬로건이 등장하는데, 이 지연이 슬로건을 보상으로 만든다.
처음부터 던졌으면 그냥 표어였을 것이다.

**장면** — "Imagine… Last night, lightning struck our house and burned it down. I escaped wearing
only my nightclothes." (Terence Eden, I've locked myself out of my digital life). 두 문장 만에
이해관계가 성립한다. 주제(계정 복구 설계의 결함)는 아직 등장하지도 않았는데 독자는 이미 그 안에
들어와 있다.

**사람** — "Probably the single best thing to happen to me in my career was having had Kellan placed
in charge of me…" (Dan McKinley, Choose Boring Technology). 개념보다 신뢰를 먼저 세운다. 뒤에 나올
"혁신 토큰"은 추상적 프레임워크인데, 실제 사람과 실제 직장에 매달아 놓았기 때문에 설교로 읽히지
않는다.

**자격** — "I have shipped a lot of different projects over the last ~10 years in tech. I often get
tapped to lead new ones when it's important to get it right, because I'm good at it." (Sean Goedecke,
How I ship projects at big tech companies). 겸양 없이 자격을 선언한다. 불편할 만큼 직설적인데, 뒤에
이어지는 강한 단정들을 감당하게 만드는 장치다. 여기서 겸손했다면 본문 전체가 흔들린다.

**사실 + 오해 차단** — "On 18 November 2025 at 11:20 UTC, Cloudflare's network began experiencing
significant failures to deliver core network traffic." 그리고 두 번째 문단, 원문 굵게: "The issue
was not caused, directly or indirectly, by a cyber attack or malicious activity of any kind."
(Cloudflare 장애 보고서). 독자가 지금 이 순간 가장 궁금해하는 것을 두 번째 문단에서 없애버린다.
그 질문을 남겨두면 나머지를 아무리 잘 써도 독자는 계속 그것만 생각한다.

**명제** — "Measurement, benchmarking, and data analysis are underrated." (Dan Luu). 결론을 첫
문장에 놓고 나머지 전부를 증명에 쓴다.

나머지 둘은 과장 선언(Ludicity — 자기 이력을 먼저 밝힌 뒤 폭발한다. 자격 없는 분노는 그냥
소음이다)과 발단형(Patrick McKenzie — 남의 글에서 시작해 그것을 계기로 삼는다)이었다.

## 4. 구조 — 스캔당할 것을 전제로 짠다

Julia Evans가 담담하게 지적하는 사실 하나. 사람들은 기술 글을 읽지 않는다. 코드 조각과 소제목을
훑는다. 이걸 서운해할 게 아니라 설계 전제로 삼아야 한다.

Michael Lynch의 검사법이 그래서 유효하다 — 소제목과 이미지만 봤을 때 흥미가 생기는가? 안 생기면
본문이 아무리 좋아도 본문까지 안 간다. 그는 "그림을 넣는 게 가장 가성비 높은 개선"이라고도 적었다.

소제목은 장식이 아니라 논증의 뼈대다. Parse, don't validate의 소제목을 순서대로 읽으면 이렇다 —
가능성의 영역 → 부분함수를 전함수로 → 파싱의 힘 → 검증의 위험 → 실무에서의 적용. 판돈 제시 → 문제
증명 → 대안 제시 → 근거 → 실행. 소제목만 읽어도 논증이 따라온다.

Scott Alexander는 세 가지 장치를 든다. 첫째, 잘게 쪼갠다. 벽 같은 텍스트는 독자를 지치게 하고,
짧은 문단과 여러 층위의 구분이 "성취의 미세한 폭발"을 반복해서 준다. 둘째, 변주한다. 이미지,
링크(파란 글씨 자체가 시각적 휴식이다), 이탤릭, 문장 길이, 어조 전환. 그는 SSRI 약리학을 길게
설명하던 글 중간에 웃긴 개인 일화를 하나 끼워 넣어 지친 독자를 되살린 뒤 다시 기술적 내용으로
돌아간다. 셋째, 아이디어의 흐름은 끊지 않는다. "또한 / 그런데 / 그럼에도 / 그래서 / 사실은" 같은
구조어가 논증의 골격을 미리 알려준다. 문장과 문단의 흐름은 마음껏 끊어도 되지만 아이디어의
흐름을 갑자기 끊으면 안 된다. 곁가지는 괄호나 각주로 뺀다.

한국어 매체의 실측 기준 하나. 토스는 글 하나의 평균 분량을 1,905자, 정독 시간을 3분 이내로
잡았다. 문단은 2~3문장, 한 문장에 한 메시지, 나열은 목록으로 비교는 표로. 절대 기준이 아니라
"한국어 화면 읽기"의 참고점이다.

## 5. 구체성 — 사례는 아이디어를 못 박는다

Dan Luu가 가장 강하게, 가장 자주 반복하는 항목이다. 그리고 그가 대는 이유가 보통의 "구체적으로
쓰세요"와 다르다.

> 사례는 아이디어를 못 박아서 제대로 검사할 수 있게 만든다. — Dan Luu

효과가 둘이다. 첫째, 내가 틀릴 확률이 낮아진다. 추상적인 명제는 반증이 어렵고, 반증이 어렵다는 건
틀려도 안 걸린다는 뜻이다. 사례를 붙이는 순간 내 주장이 검사 가능해지고, 그 검사를 내가 먼저 하게
된다. 둘째, 독자가 내가 의도한 아이디어를 가져갈 확률이 올라간다. 그는 실제 사고를 겪었다. 사례가
부족했던 글에서 독자들이 빈칸을 각자 채웠고, 95퍼센타일 성능에 관한 이야기를 전혀 다른 뜻으로
가져갔다. 그 뒤로 그는 자연스럽게 넣고 싶은 것보다 의도적으로 더 많이 넣는다.

Scott Alexander는 순서를 뒤집으라고 한다. 복잡한 논점일수록 원칙을 말하기 전에 사례를 먼저 잔뜩
깔라는 것이다. 그의 Meditations on Moloch은 핵심 개념을 입 밖에 내기 전에 사례를 14개 나열한다.
독자가 스스로 공통점을 찾아내면 그 원칙은 통보받은 게 아니라 발견한 게 된다.

인칭까지 구체적으로. "어떤 사람이 그 방법론으로 계산하면"보다 "당신이 그 방법론으로 계산하면"이
더 빠르고 더 붙는다.

왜 이게 통하는가. Steven Pinker가 지식의 저주를 "좋은 사람이 나쁜 글을 쓰는 가장 큰 이유"로 꼽은
게 이 지점이다. 내가 아는 것을 남이 모르는 상태를 상상하지 못해서, 전문 용어를 풀지 않고, 생략된
논리 단계를 메우지 않고, 나에겐 선명한 장면을 묘사하지 않는다. 구체적인 사례는 이 저주를 강제로
푸는 장치다. 사례를 쓰려면 그 장면을 다시 봐야 하고, 다시 보면 빠진 단계가 보인다.

다만 숫자는 다르다. 수치와 실측은 그 숫자가 놀라움이었거나 판단의 근거였을 때만 쓴다. 근거를
쌓는 게 목적이 되면 개인 블로그가 아니라 리포트가 된다. 사례는 많을수록 좋지만 숫자는 그렇지 않다.

## 6. 주장의 강도 — 틀리지 않는 선에서 가장 세게

> 유용한 글은 거짓이 되지 않는 한도 안에서 가능한 한 가장 센 주장을 한다. — Paul Graham

이 한 줄이 강도 문제를 다 정리한다. 학술 글이 실패하는 전형적인 방식이 "맞지만 아무것도 알려주지
않는" 상태인데, 그건 모호함으로 안전을 산 결과다. 반대편 실패는 세게 말하려다 사실이 아닌 걸 말하는
것이다. 좋은 문장은 그 경계에 정확히 붙는다.

Graham은 완충어를 없애라고 하지 않는다. 확신의 수준을 전달하는 도구로 쓰라고 한다. Julia Evans의
실전 용법이 여기 정확히 맞는다 — 확신이 덜한 문장 앞에 "내가 알기로는", "아마"를 붙인다. 확인
비용을 아끼면서 신뢰는 지키는 거래다. 글은 100% 정확할 필요가 없다. 어디가 100%이고 어디가 아닌지를
표시하면 된다.

약한 문장은 지운다. Graham이 Robert Morris에게서 배웠다는 기법 — 들을 가치가 있다고 확신하지
않으면 아무 말도 하지 않는다. 글에 적용하면, 애매한 문장은 완충어를 붙이는 게 아니라 지운다.

반론은 내가 먼저 꺼낸다. Scott Alexander의 여덟 번째 규칙이고, 그가 붙인 단서가 핵심이다. 반론을
내가 먼저 꺼내면 내 재반박이 얼마나 효과적인지와 무관하게 신뢰도가 올라간다. 반대편이 나중에 그걸
꺼냈을 때 이미 쓴 카드가 되기 때문이다. 그리고 이건 수사 기법이기 이전에 정직한 신호다 — 반대
의견을 실제로 고려했다는 증거니까.

Cloudflare의 장애 보고서가 높이 평가받은 이유는 기술적 정밀함이 아니라 불확실했던 순간을 숨기지
않았다는 데 있다. 초기에 공격인 줄 알고 헤맸다는 것, 상태 페이지까지 같이 죽어서 의심이 커졌다는
것을 진단 과정의 일부로 기록했다. 그리고 "we let you down today" 같은 문장을 기술 서술 사이에
그대로 둔다. 방어적이지도 과장되지도 않은 상태가 가장 신뢰를 산다.

반대 방향의 함정도 있다. Dan Luu의 경고 — 확신에 찬 단정은 독자를 모으고, 독자가 늘면 "당신은
항상 옳다"는 팬과 명백히 나쁜 댓글이 동시에 는다. 그 조합이 "내 비판자는 전부 바보"라는 결론으로
데려가는 실패 모드가 있다. 강도를 올리는 기술과 자기 검증을 유지하는 일은 별개로 관리해야 한다.

## 7. 개념 손잡이 — 이름이 붙어야 옮겨진다

> 블로거의 진짜 기여는 새로운 현상을 발견하는 게 아니라, 흐릿한 아이디어를 사람들이 손으로 다루고
> 남에게 옮길 수 있는 선명한 아이디어로 바꾸는 것이다. — Scott Alexander

표본을 다 확인해봤더니 10년 넘게 살아남은 글은 거의 전부 이름을 남겼다. 글 자체를 기억하는
사람보다 이름을 기억하는 사람이 훨씬 많다.

- innovation tokens — 새 기술을 쓸 수 있는 총량이 한정 자원이라는 것
- leaky abstraction — 모든 추상은 어느 지점에서 샌다는 것
- parse, don't validate — 확인했으면 그 사실을 타입에 남기라는 것
- shipping is a social construct — 출시는 배포가 아니라 합의라는 것
- falsehoods programmers believe about X — 손잡이를 넘어 형식 자체가 복제된 사례

좋은 손잡이의 조건은 셋이다. 짧고(3~4단어), 그 자체로 논쟁의 단위가 되고(찬반이 갈릴 수 있어야
함), 본문 없이도 뜻이 서야 한다. 그리고 손잡이는 글의 결론에서 나와야 한다. 손잡이를 먼저 만들고
본문을 채우면 읽는 사람이 안다. "Parse, don't validate"가 400단어 뒤에 나오는 건 우연이 아니다.
저자가 그 지점에서야 그 표현을 찾았기 때문에 그 자리에 있는 것이다.

## 8. 문장 — 독자의 무의식적 기대에 맞춘다

Gopen과 Swan이 1990년에 낸 논문이 이 항목의 근거를 가장 단단하게 댄다. 요지는 독자가 "어떤
정보가 문장의 어디쯤 나올지"에 대한 무의식적 기대를 갖고 읽는다는 것이다. 그 기대를 어기면 내용이
맞아도 읽기가 힘들어진다.

- 주어 뒤에 바로 동사. 사이에 긴 것이 끼면 방해로 읽히고, 방해로 읽힌 내용은 자동으로 덜 중요하게
  처리된다.
- 문장 앞은 연결, 문장 끝은 강조. 앞에는 독자가 이미 아는 것, 뒤에는 새로운 것. 강조하고 싶은
  것은 문장 끝(stress position)에 놓는다.
- 중심 인물을 주어로, 그 인물의 행동을 동사로(Joseph Williams). 명사로 뭉개진 동작을 동사로
  되돌리는 것만으로 문장이 절반으로 줄어든다.

Graham의 검사법은 문장 단위다 — "친구한테 말할 때 나는 이렇게 말하나?" 아니면 고친다. 그리고 발행
전에 소리 내어 읽고, 대화처럼 안 들리는 것을 전부 고친다. 그가 대는 근거가 재밌다. 어려운 주제를
다루는 전문가들도 서로 이야기할 때는 점심 뭐 먹을지 정할 때보다 복잡한 문장을 쓰지 않는다.

유시민의 기준이 정확히 같은 지점을 다른 말로 짚는다 — 소리 내어 읽기 쉽고, 귀로 듣기 좋고, 뜻을
파악하기 쉬운 글. 단문이 원칙이고, 복문은 뜻과 느낌을 강하고 확실하게 전할 때만 쓴다. 한 문장에
생각 하나를 담으면 저절로 단문이 된다. 강원국은 아예 쓰기 전에 말해본다고 했다.

한국어에만 있는 검사 항목이 번역투다. 번역투는 뜻이 안 통하는 게 아니라 속도를 떨어뜨린다.
김정선의 『내 문장이 그렇게 이상한가요?』가 가장 실전적이다. 접미사 '-적', 조사 '-의', 의존명사
'것', 접미사 '-들'은 빼도 대개 뜻이 유지된다. '-에 대한'은 동사로 풀고, '-에 의한'은 '따른'으로,
'-로부터'는 에게·와·에서 중 맞는 것으로. 이미 피동인 동사에 '-어지-'를 겹치지 않는다("잊혀지지" →
"잊히지"). 규칙은 하나다 — 한 글자를 더 썼으면 문장이 정확해지거나 풍부해져야 하고, 어색해졌으면
뺀다.

가장 값싼 개선 하나. Derek Sivers가 20년간 해온 습관 중 글을 가장 크게 바꾼 것으로 꼽은 게 이것이다
— 퇴고할 때 한 줄에 한 문장씩 놓기. 문단 안에 묻혀 있으면 약한 문장이 안 보이는데, 홀로 세워놓으면
드러나고, 드러나면 지우게 된다. Zinsser가 "초고의 50%는 정보 손실 없이 잘라낼 수 있다"고 한 걸
실행하는 가장 단순한 방법이다.

> 명료한 사고가 명료한 글이 된다. 하나 없이 다른 하나는 존재할 수 없다. — William Zinsser

## 9. 퇴고 — 초고는 빠르게, 퇴고는 오래

> 내 전략은 느슨하게, 그다음 빡빡하게다. 초고는 온갖 아이디어를 시험하면서 빠르게 쓴다. 그다음
> 며칠 동안 아주 조심스럽게 고쳐 쓴다. — Paul Graham

Graham은 「Writing, Briefly」를 쓰는 데 67분이 걸렸다고 밝혔는데, 그중 3분의 2가 고쳐 쓰는 데
들어갔다. 비율이 요점이다. 초고에 시간을 많이 쓰는 사람은 대개 퇴고를 못 한다. 아까워서.

Sivers의 기준은 더 잔인하다. 다 쓴 뒤 문장마다 묻는다 — "이 한 문장을 위해 나무를 벨 가치가 있나?"
통과 못 한 걸 전부 지운다. 그는 자기 글쓰기를 "빼기"라고 정의한다. 신호는 소음을 다 쳐낸 뒤에
남는 것이라고. John McPhee는 이 줄이기에 greening이라는 이름을 붙였다. "아래에서 네 줄을 잘라내라는
게 아니다. 아무도 무언가 빠졌다는 걸 눈치채지 못하도록 단어를 빼라는 것이다."

이 리서치에서 가장 실용적인 발견은 피드백을 다루는 법이다. Dan Luu는 피드백을 두 종류로 나눠
정반대로 취급한다. 논리적 타당성에 대한 부정적 피드백 — 여기가 틀렸다, 이 근거로는 그 결론이 안
나온다 — 은 매우 심각하게 받는다. 반면 "재미없다 / 의미 없다 / 너무 뻔하다"는 무시한다. 그의 가장
영향력 있는 글 다수가 정확히 그런 말을 들었다. 자기가 흥미를 못 느끼는 것에 남도 그럴 거라고
상상하는 사람들의 피드백이다.

덧붙여, 대부분의 피드백은 "내가 썼으면 이렇게 썼을 텐데"의 변형이다. 구조적 문제는 못 짚고 표면만
건드리며, 좋은 산문을 최소공배수의 평범한 산문으로 만든다. 그래서 판단을 믿는 한 사람에게서
받으라고 한다. 검증법도 제시한다 — 그 사람이 남의 글에 준 피드백을 보면 안다. 내 글에 대한 평가만
보면 듣기 싫은 말을 골라서 버리게 되니까.

독자에게 물을 때 쓰는 네 질문은 swyx의 ABCD가 가장 실효적이다. 뭐가 좋았나(Awesome), 어디서
지루했나(Boring), 어디서 헷갈렸나(Confusing), 어디를 안 믿었나(Didn't believe). 특히 B는 저자가
절대 스스로 못 찾는다.

개인 블로그라면 여기에 하나 더. 문단마다 묻는다 — 이걸 빼면 내가 겪은 일이 안 통하는가? 아니면
뺀다. 구조 설명, 동작 원리, 옵션 목록은 그 자체로 문단을 가질 자격이 없다. 읽은 걸 다 설명하고
싶은 충동이 개인 블로그를 문서로 만든다.

## 10. 제목은 약속, 마지막 문장은 요약이 아니다

Lynch의 대조가 선명하다. "How to Read a CSV File in Python"이 "A Complete Guide to Becoming a
Python CSV Ninja"를 이긴다. 제목의 일이 독자가 무엇을 얻는지 알려주는 것이기 때문이다. 영리한
말장난을 해독하는 데 1초 이상 걸리면 이미 진 것이다. 제목의 진짜 비용은 클릭이 아니라 신뢰다.
제목이 설정한 기대를 본문이 못 지키면 그 독자는 다음 글에 안 온다. 제목은 약속이고, 지킬 수 있는
약속만 해야 한다.

Henrik Karlsson은 반대쪽에서 한 가지를 더한다. 대부분의 사람은 제목을 최적보다 짧게 쓴다. 제목은
대부분의 사람이 보는 유일한 부분이니, 왜 읽을 만한지와 어조까지 담을 만큼은 길어도 된다.

저널리즘에서 마지막 줄을 kicker라 부르고, 정의가 좋다. 리드가 독자를 글 안으로 밀어 넣는다면,
kicker는 글을 독자 안으로 밀어 넣는다. 1~3문장, 짧고 직접적인 단어. 힘은 압축에서 나온다. 절대
하지 말아야 할 것 하나 — 자기 글을 요약하지 마라. 도입에서 이미 말한 것을 새로운 통찰 없이
되풀이하면 그 문단은 잉여다.

표본에서 실제로 쓰인 것은 셋이었다.

- 낮추기 — Parse, don't validate는 승리 선언 대신 강도를 낮춘다. "지향할 이상이지 반드시 지켜야
  할 요구사항이 아니다." 그리고 다른 사람들의 글로 연결해 이 글을 대화의 일부로 위치시킨다. 최종
  권위를 주장하지 않는 게 오히려 신뢰를 남긴다.
- 행동 — Choose Boring Technology는 철학적 결론 대신 두 단어로 끝낸다. "Just Ship." 긴 논증 뒤에
  오는 짧은 명령은 앞의 모든 문단을 한 점으로 모은다.
- 되돌아온 뒤 넘기기 — I've locked myself out of my digital life는 전부 가정이었다고 밝혀 긴장을
  유머로 풀고, 곧바로 실제로 그런 일을 겪는 사람들을 돕는 쪽으로 넘긴다. 가짜 재난이었다는 안도가
  진짜 취약점을 더 무섭게 만드는 구조다.

## 대가들이 정면으로 갈리는 네 지점

**문체 — 깨끗하게 쓸 것인가.** Graham과 Zinsser는 가능한 한 단순하게, 편집자가 "군더더기를
빼라"고 할 말이 없을 만큼. Dan Luu는 "나는 여러 면에서 정반대다. 길고 구불구불한 문장을 자주
쓴다." 그가 다루는 수준의 정밀도는 깨끗한 문체로는 도달할 수 없기 때문이다. 이중부정이 긍정문과
다른 함의를 갖는 경우가 실제로 있다. 판정: 둘 다 맞다. 문체는 목적에서 파생된다. 무엇을 얼마나
정밀하게 전달해야 하는지가 먼저고, 문체는 그 뒤에 결정된다.

**길이와 빈도 — 짧게 자주인가.** Julia Evans는 짧게 쓰고 발행하라, 다 넣으려다 아무것도 발행 못
하는 것보다 낫다고 한다. Dan Luu는 내용이 요구하는 만큼 — 분기 예측 글은 5,800단어인데 "권장
분량(500~1,500단어)으로는 같은 목표를 달성할 방법이 안 보인다"고 적었다. 흥미로운 사실 하나: 두
사람의 블로그 총 단어 수는 비슷했다. Julia가 글 편수는 한 자릿수 배 더 많이 썼는데도. 총량은
같고 분할 방식만 다르다.

**설득 기법 — 써도 되는가.** Scott Alexander는 목적이 설득이면 부족 신호, 미세 유머, 선제 반박을
적극적으로 쓴다. 단 상대편에 대한 최소한의 진짜 공감 없이는 부족 신호를 위조할 수 없다고 못
박는다. Dan Luu는 도달을 늘리는 기법을 알지만 쓰지 않는다. 판정: 맨 앞으로 되돌아간다. 무엇을
최적화하는지의 문제이고, 이건 취향이 아니라 결정이다.

**규칙을 적용하는 것 자체.** Scott Alexander는 자기가 쓴 아홉 개 규칙 다음에 열 번째로 이걸
붙였다. "훈련되지 않은 자연스러운 글은 나쁠 때가 많지만, 적어도 정직하게 나쁘다. 규칙을 억지로
따르게 만든 글은 훨씬 더 나빠진다." 모든 기술은 타고난 감 → 어색하고 기계적인 규칙 적용 → 규칙이
안 보이는 숙련 순서로 가고, 중간 단계는 처음보다 나쁘다. 그의 결론은 "본능을 먼저 기르고, 그다음에
그 본능을 써라"이다. Orwell의 여섯 번째 규칙이 같은 말이다 — "차라리 이 규칙들 중 무엇이든 깨라,
야만적인 말을 하느니."

남의 스타일을 베낄 때의 함정도 여기 붙는다. Dan Luu가 사격 코치와 무용 강사의 사례로 정리한 것 —
이해하지 못한 것을 베끼면 중요하지 않은 표면만 베끼게 된다. 학생들은 "왼발을 앞으로 교차하나요
뒤로 교차하나요"를 묻는데, 정작 중요한 건 그 발 위치가 무게중심의 이동에 비추어 타당하다는
사실이다. 잘 쓴 글을 읽을 때는 문장이 아니라 그 문장이 거기 있는 이유를 봐야 한다.

## 발행 전 점검

위를 압축한 것이다. 스킬은 이 목록을 단계별 완료 조건으로 나눠 갖고 있다.

쓰기 전

- 이 글이 무엇을 최적화하는지 정했다 (도달 / 설득 / 정확·도움)
- 소재가 내가 실제로 겪었거나 막혔던 것이다
- 막힌 기억이 아직 생생하다
- "~인데(And), 그런데(But), 그래서(Therefore)"가 한 문장으로 나온다
- 중요도 × 새로움 × 정확성 — 0인 칸이 없다
- 이 글의 독자 한 사람을 지목할 수 있다

초고

- 제목 + 첫 세 문장이 "누구를 위한 글인가"와 "뭐가 남는가"에 답한다
- 배경 설명으로 시작하지 않았다
- 소제목만 순서대로 읽어도 논증이 따라온다
- 추상적인 명제마다 사례가 붙어 있다 — 넣고 싶은 것보다 많이
- 복잡한 논점은 원칙보다 사례가 먼저 나온다
- '누군가/사람들'을 '나/당신'으로 바꿨다
- 예상되는 반론을 내가 먼저 꺼냈다
- 이름 붙일 만한 것에 이름을 붙였다 (결론에서 나온 이름인가?)

퇴고

- 소리 내어 읽었고, 대화처럼 안 들리는 문장을 고쳤다
- 한 줄에 한 문장씩 놓고 약한 문장을 지웠다
- 초고에서 최소 30% 줄였다
- 모든 문단에 물었다 — 이걸 빼면 내가 겪은 일이 안 통하는가?
- 단문 원칙. 복문은 강하게 전할 때만
- 번역투 점검 — '-적', '-의', '것', '-들', 불필요한 피동
- 완충어가 약함이 아니라 정밀도로 쓰였다 (애매한 문장은 붙이지 말고 지운다)
- 숫자가 놀라움이거나 판단의 근거일 때만 남아 있다
- 마지막 문장이 요약이 아니다
- 제목이 본문으로 지킬 수 있는 약속이다

## 출처

전문을 읽고 인용한 것만 적는다.

글쓰기론 원전

- Paul Graham — [How to Write Usefully](https://paulgraham.com/useful.html) · [Write Like You Talk](https://paulgraham.com/talk.html) · [Writing, Briefly](https://paulgraham.com/writing44.html) · [Putting Ideas into Words](https://paulgraham.com/words.html) · [The Age of the Essay](https://paulgraham.com/essay.html)
- Scott Alexander — [Nonfiction Writing Advice](https://slatestarcodex.com/2016/02/20/writing-advice/)
- Dan Luu — [Some thoughts on writing](https://danluu.com/writing-non-advice/) · [How (some) good corporate engineering blogs are written](https://danluu.com/corp-eng-blogs/)
- Julia Evans — [Some blogging myths](https://jvns.ca/blog/2023/06/05/some-blogging-myths/) · [Blog about what you've struggled with](https://jvns.ca/blog/2021/05/24/blog-about-what-you-ve-struggled-with/) · [Some tactics for writing in public](https://jvns.ca/blog/2023/08/07/tactics-for-writing-in-public/)
- Simon Willison — [What to blog about](https://simonwillison.net/2022/Nov/6/what-to-blog-about/)
- Henrik Karlsson — [A blog post is a very long and complex search query…](https://www.henrikkarlsson.xyz/p/search-query) · [The Writing Process Nobody Teaches You](https://howiwrite.substack.com/p/henrik-karlsson-the-writing-process)
- Michael Lynch — [Write Blog Posts Developers Read](https://refactoringenglish.com/chapters/write-blog-posts-developers-read/) · [Rules for Writing Software Tutorials](https://refactoringenglish.com/chapters/rules-for-software-tutorials/)
- Larry McEnerney — [The Craft of Writing Effectively](https://www.robincussol.com/the-craft-of-writing-effectively-summary/) (강의 요약)
- swyx — [Writing Advice](https://www.swyx.io/writing-advice)

구조를 해부한 표본

- Alexis King — [Parse, don't validate](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/)
- Dan McKinley — [Choose Boring Technology](https://mcfunley.com/choose-boring-technology)
- Terence Eden — [I've locked myself out of my digital life](https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my-digital-life/)
- Sean Goedecke — [How I ship projects at big tech companies](https://www.seangoedecke.com/how-to-ship/)
- Patrick McKenzie — [Falsehoods Programmers Believe About Names](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/)
- Dan Luu — [Measurement, benchmarking, and data analysis are underrated](https://danluu.com/why-benchmark/)
- Cloudflare — [2025년 11월 18일 장애 보고서](https://blog.cloudflare.com/18-november-2025-outage/)
- Ludicity — [I Will Fucking Piledrive You If You Mention AI Again](https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you-if-you-mention-ai-again/)
- Maciej Cegłowski — The Website Obesity Crisis (2차 자료로만 확인)

교본과 연구

- Gopen & Swan — [The Science of Scientific Writing](https://www.gatsby.ucl.ac.uk/~pel/misc/gopen_swan.pdf) (1990)
- Joseph Williams — 『Style: Lessons in Clarity and Grace』 / William Zinsser — 『On Writing Well』 / Steven Pinker — 『The Sense of Style』 / John McPhee — 『Draft No. 4』 / Vivian Gornick — 『The Situation and the Story』 / Verlyn Klinkenborg — 『Several Short Sentences About Writing』
- George Orwell — [Politics and the English Language](https://www.openculture.com/2025/12/george-orwells-six-rules-for-writing.html)
- Randy Olson — 『Houston, We Have a Narrative』 (ABT)
- Chip & Dan Heath — 『Made to Stick』
- 유시민 — 『유시민의 글쓰기 특강』 / 이오덕 — 『우리글 바로쓰기』 / 김정선 — 『내 문장이 그렇게 이상한가요?』 / 강원국 — 『대통령의 글쓰기』
- Berger & Milkman — [What Makes Online Content Viral?](https://journals.sagepub.com/doi/10.1509/jmr.10.0353) (JMR, 2012)
- [Narratives are Persuasive Because They are Easier to Understand](https://www.frontiersin.org/journals/communication/articles/10.3389/fcomm.2021.719615/full) (처리 유창성)
- Refactoring English — [2025년 Hacker News 최다 블로거 분석](https://refactoringenglish.com/blog/2025-hn-top-5/) / [Hacker News 역대 상위 100개 글 분석](https://debarghyadas.com/writes/the-top-100-hacker-news-posts-of-all-time/)
- Nieman Storyboard — [Nut grafs](https://niemanstoryboard.org/2021/10/19/nut-grafs-getting-to-the-heart-of-the-story/) / Derek Sivers — [Writing one sentence per line](https://sive.rs/1s)

---

가장 자주 반복된 조언: 소리 내어 읽어라. 가장 자주 무시되는 조언: 지워라.