Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 2026년, 콘텐츠를 만들어야 하는 이유가 바뀌었다

10년 전 개발자가 블로그를 쓰는 이유는 단순했다. "구글에 검색되어 잠재 고용주가 나를 찾게." 그게 전부였다.

2026년은 다르다. 세 가지 표면이 거의 동시에 무너지고 다시 솟았다.

- **SEO의 죽음과 부활.** 구글의 AI Overviews(이전 SGE)와 Perplexity, ChatGPT search가 SERP를 잠식했다. "클릭이 일어나지 않는 검색"이 디폴트다. 트래픽 그래프는 떨어진다. 그런데 — 당신의 글은 더 많이 읽힌다, 사람이 아닌 LLM에게.

- **LLM이 당신의 글을 읽는다.** 학습 데이터로 한 번, RAG/추론으로 매일. ChatGPT가 "Next.js 13에서 ISR 어떻게 해?"에 답할 때, 그 답의 일부는 누군가의 블로그였다. 그 누군가가 당신이 될 수 있다. "글을 LLM이 인용하게 쓰는 것"이 SEO의 새 정의다.

- **디스커버리는 알고리즘으로 이동.** Twitter/X의 For You, LinkedIn의 피드, YouTube의 추천, dev.to의 trending, Hacker News의 front page — 검색이 아니라 알고리즘이 당신을 새 독자에게 데려간다. 검색은 "재방문"의 영역이고, 알고리즘은 "발견"의 영역이다.

여기에 변하지 않은 한 가지가 있다. **글을 잘 쓰는 개발자는 여전히 드물다.** AI가 평균을 공짜로 만들어서 오히려 더 드물어졌다. 평균은 LLM이 5초만에 뽑는다. 당신만이 쓸 수 있는 것 — 그 압축된 1시간의 경험, 그 좁고 깊은 안목, 그 솔직한 실패담 — 만이 살아남는다.

이 글은 **머네타이즈가 아니라 크래프트**다. 광고 단가, 스폰서십 비율, 유료 멤버십 전환율은 다른 글에서 다룬다. 여기서는 **무엇을 만들지, 어떻게 시작할지, 어떤 채널에 무엇이 맞는지, 자기 목소리를 어떻게 찾는지, 그리고 하지 말아야 할 것이 무엇인지**를 다룬다.

결론을 먼저 말하자면 — 2026년 가장 저평가된 단 하나의 채널은 **꾸준히 굴러가는 자기 도메인의 개인 블로그**다. 7장에서 변호하겠다.

1장 · 무엇을 쓰고 찍을 것인가 — 콘텐츠의 4분면

블로그를 시작할 때 가장 흔한 막힘은 "쓸 게 없다"가 아니다. **"쓸 게 너무 많은데 뭘 써야 할지 모르겠다"**다. 4분면으로 정리하면 깔끔하다.

| 축 | 검색 가능(Searchable) | 알고리즘 발견(Algorithmic) |

| --- | --- | --- |

| **튜토리얼·하우투** | "Next.js 15 App Router에서 ISR 설정하기" | "내가 ISR로 3분만에 SEO 무너뜨린 썰" |

| **에세이·관점** | "왜 우리는 마이크로서비스를 버렸나" | "프론트엔드 채용 면접의 거짓말 5가지" |

- **튜토리얼·검색** — 긴 수명, 느린 시작. 한 번 잘 쓰면 5년 간다. LLM이 가장 자주 인용한다. 블로그·dev.to·자기 도메인이 어울린다.

- **튜토리얼·알고리즘** — 짧은 폭발, 빠른 학습. YouTube·트위터 쓰레드가 어울린다. Fireship 모델.

- **에세이·검색** — 긴 수명 + 권위. 가장 어렵고 가장 가치 있다. 자기 도메인 블로그 + Hacker News.

- **에세이·알고리즘** — 가장 빠른 오디언스 빌딩. 트위터·LinkedIn 단문. 위험: 휘발되고, 신뢰가 안 쌓일 수 있다.

처음에는 한 사분면을 고르라. 4개를 동시에 굴리려다 모두 어설프게 된다. 가장 안전한 선택은 **"튜토리얼·검색"**으로 시작해 6개월 뒤 다른 사분면을 더하는 것이다. 이유는 단순하다 — 검증이 즉시 되고(코드가 돌면 글이 맞다), 자존감의 진입장벽이 낮고(설명이 곧 가치다), LLM이 인용한다.

콘텐츠 아이디어가 마르지 않는 3가지 광맥

1. **"오늘 내가 검색했지만 답이 없었던 것."** 가장 좋은 광맥이다. 답이 없었다는 건 시장이 있다는 뜻이다. 그날 저녁에 글로 정리하라.

2. **"내 PR에서 시니어가 지적한 것."** 이미 검증된 학습이다. "Code review에서 배운 N가지" 시리즈는 절대 마르지 않는다.

3. **"내가 6개월 전의 나에게 보내고 싶은 글."** 가장 진정성이 있다. 독자는 항상 6개월 전의 당신이다.

무엇을 쓰지 말 것인가

- "OOO이란 무엇인가?" 류 — Wikipedia와 LLM이 이긴다.

- 1차 출처 없는 요약 글 — 가치 음수다.

- 회사 자랑 글 — 채용 페이지에서 해라.

- "10가지 X" 같은 리스티클 — 2018년에 끝났다.

2장 · 작게 시작하기 — 첫 100편 법칙

콘텐츠 크리에이션의 가장 큰 거짓말은 "꾸준히 하라"다. 너무 추상적이라 행동이 안 나온다. 실전 규칙은 두 가지다.

규칙 1 — 첫 100편은 버리는 셈 쳐라

거의 모든 성공한 개발 크리에이터가 같은 말을 한다. "처음 1년 동안 쓴 글은 형편없었다." Fireship, Theo, Josh Comeau, Lee Robinson, Dan Abramov 모두. 첫 100편은 **자기 목소리를 찾는 시간**이지 오디언스를 얻는 시간이 아니다.

YouTube 영상이라면 처음 30개. 트위터라면 처음 500개 트윗. 뉴스레터라면 처음 20호. 이 시기에 "왜 안 떠?"를 묻는 건 1km 달리고 "왜 마라톤 우승 못해?"를 묻는 것과 같다.

규칙 2 — 게시 빈도는 1주에 1편, 단 6개월간

빈도가 핵심이지만 너무 잡으면 부러진다. **1주 1편, 6개월(=26편)** 이 가장 잘 검증된 진입 슬롯이다. 그 이후에 늘리든 줄이든 본인이 정한다.

매일 글을 쓸 필요는 없다. 매일 **수집**하라. 그날 만난 코드, 막힌 문제, 좋았던 PR 코멘트 — 작은 노트로 남긴다. 일요일 저녁에 그 중 하나를 골라 글로 만든다. Cleanshot으로 스크린샷, Notion에 초안, 월요일 아침에 본인 블로그로 옮긴다.

"작게"의 진짜 의미

- 800자도 글이다. 2,000자가 평균이지만 800자도 완결되면 충분하다. 처음에는 짧게.

- 한 글에 하나의 결론. 두 개를 담으면 둘 다 약해진다.

- 코드 스니펫 1~3개면 충분. 5개 이상이면 그 글은 GitHub 레포가 되어야 한다.

- 표지 이미지는 텍스트 한 줄로 충분. Figma도 좋지만 처음엔 그 시간을 글에 써라.

3장 · 채널 경제학 — 5가지 표면 한눈에

이 표가 이 글의 중심이다. 채널마다 시간·오디언스·깊이·머네타이즈·AI 시대 영향이 다르다.

| --- | --- | --- | --- | --- | --- |

| 글/영상 한 편당 시간 | 3~8시간 | 6~20시간 | 2~6시간 | 10~60분 | 1~3시간 |

한 줄 요약

- **개인 블로그** — 장기전. AI 시대 가장 순풍이고 가장 저평가됐다. (7장)

- **YouTube** — 가장 빠른 오디언스, 가장 비싼 제작. Fireship 모델은 모방하기 어렵다.

- **뉴스레터** — "내가 소유한 채널"의 유일한 답. Substack→Beehiiv 전환이 2025년 트렌드.

- **Twitter/X·LinkedIn** — 디스트리뷰션. 본진이 아니다. 트래픽을 다른 곳으로 보내는 도구.

- **dev.to·Hashnode** — 빠른 첫 독자를 얻는 부트스트랩. 본진은 자기 도메인.

4장 · 개인 블로그 — 장기전의 본진

먼저 결론. **모든 개발자는 자기 도메인의 블로그를 가져야 한다.** 채널 선택 이전의 기반이다.

왜 자기 도메인인가

- **데이터 소유.** Medium·dev.to·Hashnode는 언제든 정책을 바꾼다. Medium은 2020년 paywall을 도입했다. dev.to는 알고리즘을 자주 바꾼다. 도메인은 당신 거다.

- **URL 안정성 = LLM 인용 안정성.** LLM이 학습할 때 URL이 안 바뀌어야 인용이 안정적이다. 도메인 호스팅은 영원하다.

- **신뢰의 무게.** `yourname.dev/post` 와 `medium.com/@username/post` 는 다르게 읽힌다. 전자가 훨씬 신뢰 있다.

- **포트폴리오와 융합.** 블로그 + about + projects가 한 도메인에 있으면 자기소개가 끝난다.

스택

가장 흔한 조합 — `Next.js + MDX + Tailwind + Vercel`. 이 블로그도 그렇다. 대안.

- `Astro` — 가장 빠른 빌드, 가장 가벼운 정적 사이트. 2025년 점유율 급상승.

- `Hugo` — 빌드가 정말 빠르다. 다만 Go 템플릿 학습 곡선.

- `Jekyll + GitHub Pages` — 0원, 0운영. 단점은 트래픽 통계가 약함.

- `Notion → 정적 사이트` (Notion API + Next.js) — 작성 UX가 최고지만 검색 무게가 줄어든다.

운영 원칙 5가지

1. **글 하나에 URL 하나, 영원히.** URL을 바꾸지 마라. 리다이렉트를 깔아도 LLM 인용은 손상된다.

2. **RSS는 켜둬라.** 죽지 않았다. 다시 살아났다. RSS 리더는 알고리즘 피로에 지친 사람들의 본진이다.

3. **다국어를 진지하게 고려하라.** 한국어만 쓰는 블로그는 풀의 5%만 닿는다. 영어 + 일본어 + 한국어 트리플이면 풀이 100배 늘어난다. AI 번역은 2024년부터 충분히 좋아졌다.

4. **검색을 막지 마라.** robots.txt에서 GPTBot, ClaudeBot을 차단하지 말라. (선택은 본인이지만, 차단은 LLM 인용을 막는 셈이다.) `llms.txt` 표준이 2026년 자리잡았으니 그것도 추가.

5. **댓글은 없어도 된다.** Disqus는 느리고 광고 붙는다. GitHub Discussions를 연결하든지, 그냥 트위터 답글 링크를 달든지.

첫 6개월 목표

- 26편 글 (주 1회 × 26주)

- 100명의 RSS 구독자

- 1편이 Hacker News 상위 30위 안에 들기 (없으면 6개월 더)

- 글 하나가 LLM에 인용되는지 시도 ("내 글 제목을 ChatGPT에 검색해보고 출처로 잡히는지 확인")

5장 · YouTube — Fireship 모델은 흉내 낼 수 있는가

Fireship(Jeff Delaney)의 100초 시리즈는 개발 YouTube의 표준을 다시 썼다. 2026년 기준 약 350만 구독자. 영상 한 편이 1~5백만 조회. 흉내 내는 사람은 많지만 진짜 성공한 사람은 드물다. 이유를 보자.

Fireship 모델의 해부

- **편당 100초 ~ 8분.** "지루할 시간을 안 준다"가 1차 룰.

- **컷 간격 평균 1~3초.** 시각적 자극이 멈추지 않는다.

- **B-roll이 압도적.** 코드만 보여주지 않는다. 밈, 일러스트, 화면 캡처, 짧은 영상이 깔린다.

- **타이틀이 곧 후크.** "Next.js in 100 seconds." 검색·알고리즘 둘 다 잡는다.

- **압축률.** 6시간 분량의 문서를 100초로. 이게 가장 어렵다.

진입자가 따라하기 어려운 이유

- 한 영상에 평균 10~20시간의 편집. 본업이 있다면 못 한다.

- 컷 1초 단위의 편집 감각은 1년 이상 훈련 필요.

- 100초로 압축하는 큐레이션은 5년 이상 경력이 있어야 가능.

진입자에게 더 맞는 YouTube 모델 3가지

1. **Theo / t3.gg 모델 — "라이브 + 정리".** 라이브 코딩이나 라이브 리액션을 찍고 잘라낸다. 자연스러움이 강점. 편집이 적다.

2. **Primeagen 모델 — "코드 리뷰 라이브".** 다른 사람 코드/PR을 보면서 의견 낸다. 콘텐츠 소스가 무한.

3. **Josh tried Coding 모델 — "에세이 영상".** 슬라이드 + 음성 + 가끔 코드. 편집이 적고 깊이가 깊다.

진입자에게 100초 모델은 함정이다. 첫 30편은 "10분 안에 한 주제를 진짜로 설명한다"가 안전하다.

도구 스택

- **녹화** — Descript(편집·녹화 통합), Loom(가장 쉬움), OBS(가장 자유), Riverside(고품질 인터뷰).

- **편집** — Descript(텍스트 기반 편집), Final Cut Pro / DaVinci Resolve(전통).

- **썸네일** — Figma + Photoshop. 처음에는 Figma만.

- **음성** — Shure SM7B는 사치다. Rode NT-USB Mini로 시작해도 충분하다.

6장 · 뉴스레터 — 소유한 채널의 유일한 답

2026년 디스트리뷰션의 진실 한 줄. **알고리즘은 빌리는 것이고, 이메일 리스트는 소유하는 것이다.** Twitter가 X로 바뀌고 알고리즘이 4번 바뀌는 동안에도, 이메일 리스트는 그대로 당신 거다.

플랫폼 3개 비교 (2026년 기준)

| --- | --- | --- | --- |

| 진입 난도 | 가장 쉬움 | 중간 | 중간 |

| 비용(첫 1k 구독자) | 무료 | 무료 | 무료 |

| 데이터 export | 가능 | 가능 | 가능 |

| 알고리즘 의존 | 높음(Notes) | 낮음 | 중간 |

| 광고/스폰서 | 직접 | 직접 | 자체 광고 네트워크 |

| 2025~2026 이슈 | 정치 논란·이탈 | 안정 | 가장 빠른 성장 |

2025년 트렌드 한 줄. **"Substack에서 Beehiiv로의 이주"**. 정치 논쟁 이슈와 알고리즘 변동성 때문에 Casey Newton, Lenny Rachitsky 등 톱 뉴스레터가 Beehiiv·자체 호스팅으로 이동했다. 신규 시작자는 Beehiiv가 안전한 디폴트다.

뉴스레터의 콘텐츠 모델 3가지

1. **큐레이션 + 코멘트 — "이번 주 개발 뉴스 + 내 한 줄".** 가장 진입이 쉽고 가장 길게 굴러간다. The Pragmatic Engineer, Tech Ladders, JavaScript Weekly.

2. **딥 다이브 — "한 주에 한 주제 5,000자".** 가장 어렵고 가장 가치 있다. Pragmatic Engineer paid, Lenny's Newsletter.

3. **"내 일주일" — 개발자의 일주일 일기.** 가볍지만 신뢰 쌓기에 강하다. 단점은 글감이 마를 때 위험.

운영 원칙

- **격주가 가장 잘 굴러간다.** 매주는 본업이 흔들리고, 월 1회는 잊혀진다.

- **첫 100명은 본인의 1촌·2촌에서 채워라.** "이메일 50명에게 직접 보내라"가 모든 뉴스레터 시작점이다.

- **블로그 → 뉴스레터 자동 전환을 켜라.** 블로그가 본진이고, 뉴스레터는 그 다이제스트로 깐다. RSS-to-Email.

- **유료화는 천천히.** 무료 구독자가 최소 1,000명 넘기 전에 유료 도입하면 무료 풀이 자라지 않는다.

7장 · Twitter/X·LinkedIn·Bluesky — 디스트리뷰션 표면

본진이 아니다. 본진으로 트래픽을 보내는 도구다. 이 구분이 안 서면 트위터 중독으로 끝난다.

2026년 현황 정리

- **Twitter/X** — 여전히 개발 디스트리뷰션의 1번. For You 알고리즘이 외부 링크를 깎는다는 인식이 있어 이미지·쓰레드가 강세. API 폐쇄 이후 외부 도구 생태계는 무너졌다.

- **LinkedIn** — 시니어 개발자·매니저 풀이 가장 큼. 톤이 다르다: 1인칭 스토리, 줄바꿈 많이, 이모지 절제. 알고리즘이 외부 링크에 페널티를 주는 것으로 알려져 댓글에 링크 다는 패턴이 표준.

- **Bluesky** — 2024~2025년 폭발 후 2026년 상승세 둔화. 개발 커뮤니티는 일부 이주했지만 디스커버리가 약하다. "테크 트위터의 일부" 정도.

- **Threads** — Meta의 답. 2026년 들어 거대해졌지만 개발 커뮤니티 점유는 낮다.

- **Mastodon** — 작아도 단단한 커뮤니티. fediverse를 좋아하는 개발자 집단이 본진.

트윗을 잘 쓰는 5가지 패턴

1. **단언 + 근거 — "ORM은 95% 케이스에서 손해다. 이유는 3가지."** 그 다음에 답글로 풀어라.

2. **반전 시작 — "전부 React 좋아할 때 나는 7년째 Backbone을 쓴다. 이유:"** 호기심이 알고리즘에 잘 먹힌다.

3. **스크린샷이 핵심.** 코드 스크린샷은 트윗 본문보다 더 길어도 된다. Carbon, Ray.so, Cleanshot.

4. **숫자 1개.** "12배 빨라졌다", "47% 감소", "단 3분만에". 한 트윗에 정확한 숫자 1개.

5. **쓰레드는 7개 이내.** 길어지면 이탈한다. 깊이는 본진(블로그)에서.

LinkedIn 톤의 디테일

- 첫 줄 = 후크. "오늘 우리 팀이 4시간 만에 데이터 손실을 복구했다."

- 두 번째 줄 = 줄바꿈.

- 짧은 문단들. 한 문단 1~2문장.

- 마지막 줄에 질문. "당신이라면 어떻게 했을까?"

- 외부 링크는 첫 댓글에. (페널티 회피)

- 이모지는 0~1개. 영업처럼 보이지 마라.

안 해야 할 것

- 트위터에 본진을 두는 것 — 알고리즘은 빌리는 거다.

- LinkedIn에 너무 "취업용" 톤 — 시니어들은 그걸 가장 빨리 알아챈다.

- Bluesky에 베팅 다하기 — 디스트리뷰션이 약하다.

8장 · 커뮤니티 표면 — dev.to·Hashnode·Hacker News·Lobsters

이건 본진도 아니고 디스트리뷰션도 아닌 **"커뮤니티 부트스트랩"**이다. 첫 독자를 데려오는 빠른 입구.

dev.to

- **장점** — 진입이 가장 쉽다. Markdown 그대로 붙여넣기. 첫 글에도 50~500 조회수.

- **단점** — 알고리즘이 자주 바뀐다. SEO가 본인 도메인보다 약하다. 데이터 소유 0%.

- **2026년 활용법** — 본인 블로그에 먼저 게시 → 7일 뒤 dev.to에 canonical URL 박고 크로스포스트. 둘 다 챙긴다.

Hashnode

- 자기 도메인 매핑이 무료 — dev.to보다 한 단계 위.

- 다만 빌드가 호스팅 의존 — 데이터 export는 가능하지만 Next.js만큼 자유롭지 않다.

- 처음 6개월 부트스트랩으로는 좋다. 1년 뒤 자기 스택으로 이주.

Hacker News

- 개발 디스커버리의 정점. 한 번 front page에 들면 보통 5~50만 조회.

- **올리는 법** — 본인이 올리지 말고 친구가 올리게 하라. 단 spam ring은 즉시 ban. 가장 안전한 건 "그냥 올리고 잊는다."

- 시간대 — UTC 14:00~20:00에 신선한 글이 잘 뜬다. 주말은 트래픽 적지만 경쟁도 적다.

- 제목은 본문 첫 문장보다 더 강해야 한다. "Why X" 보다 "X is broken. Here's why."

Lobsters

- HN보다 좁고 깊다. 시스템·언어·세큐리티가 강세.

- 초대제 — 초대 받기가 진입 장벽이지만 들어가면 댓글 품질이 가장 높다.

- 한 번 첫 페이지 들면 HN의 1/20이지만 댓글이 가장 깊다.

Reddit r/programming · r/webdev · r/golang 등

- 서브레딧마다 룰이 까다롭다. self-promotion이 막힌 곳도 많다.

- 그래도 한 번 통하면 HN 다음의 트래픽. 첫 글 올리기 전 그 서브레딧 룰을 정독하라.

9장 · 컨퍼런스 토크 · 팟캐스트 — 슬로우 채널

콘텐츠 빌딩의 마지막 두 표면. 빠른 채널이 아니다. 다만 한 번 잘 만들면 **5년 가는 신뢰**가 쌓인다.

컨퍼런스 토크

- **첫 토크는 동네 밋업.** 30분, 청중 30명. 두려움을 깎는다.

- **그 다음 지역 컨퍼런스.** JSConf KR, FEConf, PyCon KR, NDC, DEVIEW. CFP 마감을 캘린더에 박아두라.

- **글로벌은 그 다음.** React Summit, JSNation, KubeCon 등. 토크 영상이 YouTube에 올라가면 그게 그대로 콘텐츠가 된다.

- **CFP 쓰는 법.** 제목 + 5문장 abstract + 3문장 takeaway. 평소 블로그에 쓰던 글이 곧 토픽이다.

팟캐스트

본인이 진행하는 팟캐스트는 권장하지 않는다. 시간이 너무 들고 시작 6개월간 청취자가 30명을 넘기기 어렵다. 대신 **남의 팟캐스트에 게스트로 나가라.**

- **Latent Space** — AI 엔지니어 팟캐스트의 정점. Swyx와 Alessio.

- **Changelog** — 오픈소스·개발 인터뷰의 표준. 10년 넘게 유지.

- **Software Engineering Daily** — 매일 새 인터뷰. 게스트 풀이 가장 큼.

- **CoRecursive** — 개발 스토리텔링. 깊이가 깊다.

- 한국 — 나는 PRO다, 잡-잡한 잡담, 김 작가의 ARSI(작가들의 알쓸신잡) 등.

게스트로 나가려면 — 본인 블로그에 좋은 글이 5~10편 있어야 한다. 그게 명함이다.

10장 · 도구 스택 — 2026년 표준

이 글의 마지막 실용 챕터. 작가가 글을 쓰는 도구가 곧 자기 손이다.

글쓰기 흐름

- **수집** — Apple Notes 또는 Bear. 빠르게.

- **초안** — Notion. 멀티미디어 임베드와 협업이 좋다.

- **공개 글** — MDX (자기 블로그). VS Code + Markdown All in One + Vale.

- **이미지** — Cleanshot X (스크린샷), Figma (썸네일·그림), Excalidraw (다이어그램), Carbon / Ray.so (코드 이미지).

영상·녹화

- **녹화** — Loom (간단), Descript (편집과 통합), OBS (자유).

- **편집** — Descript (텍스트 기반), Final Cut Pro / DaVinci Resolve (정통).

- **트랜스크립트** — Whisper Large v3 (오픈소스), MacWhisper (Mac UI).

뉴스레터

- **Beehiiv** — 신규 진입자 디폴트.

- **Substack** — 이미 풀이 있다면 유지.

- **Buttondown** — 개발자 친화 미니멀.

분석

- **Plausible / Umami** — 쿠키리스, 가벼움.

- **Posthog** — 깊은 분석 필요 시.

- 구글 애널리틱스는 2026년에는 권장하지 않는다.

AI 보조

- **Claude / ChatGPT** — 초고 다듬기, 문법 점검.

- **Grammarly** — 영어 글에 한정.

- **DeepL** — 다국어 번역. 한 → 영 → 일 워크플로의 핵심.

- 절대 — **LLM이 글의 결론을 정하게 두지 마라.** 결론은 사람이 정해야 한다. LLM은 윤문만.

11장 · 목소리를 찾는 법

이 글에서 가장 추상적이지만 가장 중요한 챕터다. 도구·채널은 1년이면 다 익힌다. 자기 목소리는 5년 걸린다.

목소리는 발견하는 것이 아니라 깎는 것

처음에는 본인이 좋아하는 작가의 톤을 흉내 낸다. 그건 자연스럽고 권장된다. 1년쯤 지나면 흉내 낸 톤들이 충돌하기 시작한다. 그 충돌 지점에서 본인 톤이 생긴다.

- Dan Abramov의 비유 — "복잡한 걸 쉽게 설명하지 말고, 쉬운 걸 정확하게 설명하라."

- Julia Evans의 일러스트 — "내가 배운 그날의 작은 한 조각."

- Patrick McKenzie(patio11)의 비즈니스 시각 — "이 코드는 누구의 돈을 어떻게 움직이나."

- 박지욱(현우의 jbee.io 등 한국 개발 블로거) — 솔직한 1인칭과 안티-과장.

당신은 이들의 어떤 조합인가? 어떤 부분에 본인 톤이 보이는가? 1년 동안 글을 모아 다시 읽으면 보인다.

톤을 빨리 찾는 4가지 운동

1. **자기 글 1년치를 한 번에 읽어보라.** 반복되는 단어, 반복되는 문장 구조 — 그게 본인 톤이다.

2. **친한 친구 5명에게 본인 글 3편을 보여주라.** "이거 누가 쓴 거 같아?"의 답이 톤이다.

3. **본인이 절대 안 쓸 단어 10개를 적어보라.** "leverage", "synergy", "incredible" — 안 쓰는 단어가 톤을 만든다.

4. **한 글을 음성으로 녹음해 들어봐라.** 글이 본인의 말투와 너무 다르면 그건 가면이다.

옵션 vs 의견

개발 콘텐츠 톤의 가장 큰 양극단.

- **옵션 글** — "방법 A, B, C가 있고 각각 이런 장단점이 있다." 균형 잡혔지만 잊혀진다.

- **의견 글** — "B를 써라. A는 함정이고 C는 과잉이다." 욕먹지만 기억된다.

처음에는 옵션 글로 시작하라. 충분히 글을 쓰면 의견이 자연스럽게 생긴다. 의견이 생긴 뒤에는 두려워하지 말고 의견을 쓰라. **무관심보다 반대가 낫다.**

12장 · AI 시대의 콘텐츠 — LLM이 당신의 글을 읽는다

2026년 콘텐츠의 가장 큰 변수. 더 이상 미룰 수 없는 챕터.

두 번 읽힌다

- **학습 데이터로 1번.** GPT-5, Claude 4.5, Gemini 2.5 의 학습 데이터에 당신의 글이 들어갈 수 있다. (들어가지 않게 할 수도 있다 — `robots.txt`로 `GPTBot`, `ClaudeBot`, `Google-Extended` 막기.)

- **추론에서 매일 N번.** Perplexity, ChatGPT search, Claude with web search가 답할 때 RAG로 당신의 글을 가져간다. 매일.

LLM이 인용하게 쓰는 법 — GEO (Generative Engine Optimization)

GEO는 2025년 등장한 신조어다. SEO의 LLM 버전.

1. **명료한 정의문.** "X는 Y다." 한 문장으로 시작. LLM은 정의문을 가장 잘 인용한다.

2. **숫자가 있는 비교.** "A는 B보다 12% 빠르다." 숫자가 있는 문장은 인용 확률이 5배 높다(여러 GEO 연구의 합의).

3. **목록.** Bullet point가 산문보다 인용된다.

4. **URL 안정성.** LLM의 학습 데이터의 URL이 살아있어야 인용이 유지된다.

5. **`llms.txt` 추가.** 2026년 자리잡은 표준. 사이트 루트에 `llms.txt`를 두어 LLM에게 "이 사이트의 핵심 문서들"을 알려준다.

인용을 막을 수도 있다

- `User-agent: GPTBot` `Disallow: /`

- `User-agent: ClaudeBot` `Disallow: /`

- `User-agent: Google-Extended` `Disallow: /`

- 다만 이건 트래픽을 막는 셈이다. 정책 선택은 본인.

한 가지 솔직한 변화

검색 트래픽은 떨어진다. 그러나 **"내 글을 본 사람"의 수는 비슷하거나 오히려 늘었다.** 단지 그 사람이 ChatGPT를 통해 보게 된 것뿐. 그래서 GA에서 트래픽이 떨어진다고 콘텐츠를 멈추면 잘못 읽는 거다.

13장 · 2026년 가장 저평가된 채널 — 개인 블로그 (변호)

이제 7장에서 미뤘던 변호를 한다.

4가지 변호 논리

1. **AI 시대의 화폐는 URL이다.** LLM이 인용할 수 있는 형태는 글이고, 글의 주소는 URL이다. 트윗은 URL은 있지만 휘발된다. 영상은 URL이 있지만 인용하기 어렵다. 블로그 글은 두 가지를 다 가진다.

2. **알고리즘 의존이 0이다.** Twitter도 LinkedIn도 YouTube도 알고리즘 한 번 바뀌면 트래픽이 반토막난다. 자기 도메인 블로그는 알고리즘 변동에 영향받지 않는다. 검색 알고리즘이 변해도 — RSS·뉴스레터·LLM 인용은 남는다.

3. **장기 자산이다.** 5년 전 쓴 글이 오늘도 트래픽을 가져온다. YouTube 영상이 5년 후에도 보여지긴 하지만 알고리즘이 거의 안 보내준다. 트윗은 24시간 후 없는 거나 마찬가지. 블로그 글은 5년 가는 자산이다.

4. **다른 모든 채널의 본진이 된다.** 트위터 쓰레드는 블로그 글의 요약. 뉴스레터는 블로그 글의 다이제스트. YouTube 영상은 블로그 글의 시각화. 컨퍼런스 토크는 블로그 글의 발표. 블로그가 없으면 다른 모든 채널이 떠다닌다.

그래도 블로그가 외면받는 이유

- "이미 늦었다"는 착각. 안 늦었다. AI 시대 콘텐츠 생태계가 다시 시작 중이다.

- "트래픽이 안 나온다"는 조급함. 첫 6개월 트래픽이 안 나오는 게 정상이다. 6년 자산을 6개월로 평가하지 마라.

- "쓸 게 없다"는 거짓말. 오늘 검색한 게 곧 글감이다.

- "디자인이 별로다"는 회피. 디폴트 Tailwind 템플릿으로 충분하다. 디자인은 100편 쓴 뒤 신경 써라.

한 줄 결론

**자기 도메인 블로그가 본진이고, 다른 모든 채널은 그 본진에서 빌리고 그 본진으로 돌려보내는 디스트리뷰션이다.** 2026년에 콘텐츠를 시작한다면 가장 먼저 도메인을 사고 가장 먼저 Hello World를 게시하라.

에필로그 — 1년 뒤의 당신에게

5년 뒤 당신은 두 종류 중 하나다.

**(A)** 글 30편, 영상 0개, 뉴스레터 구독자 200명, RSS 구독자 50명. 트래픽은 별로지만 — 회사 외부의 누군가가 당신을 알아본다. PR에 누군가가 "이거 본인이 쓴 그 글에서 봤어요"라고 답한다. 채용 제안이 LinkedIn DM으로 온다. 컨퍼런스 CFP에 통과한다. 5년 자산이 쌓였다.

**(B)** 트위터 팔로워 2,000명, 블로그 글 0편. 매일 본진은 트위터인데 매월 알고리즘이 바뀐다. 한 번 휘발되면 0으로 돌아간다. 그동안 만든 콘텐츠를 모아둘 곳이 없다. 트위터를 떠나면 흔적이 사라진다.

A가 되는 길은 단순하다. **도메인 사고, MDX 깔고, 글 1편 쓰고, 일요일마다 1편 더 쓰는 것.** 6개월. 26편. 그게 전부다.

체크리스트 — 오늘 시작하는 사람의 첫 7가지

1. 도메인 산다 (yourname.dev 또는 yourname.io).

2. Next.js + MDX 템플릿 1개 클론한다 (이 블로그도 그렇다).

3. Vercel 배포. 5분.

4. "Hello World" 글 1편 게시.

5. RSS 켜고 자기 RSS 리더에 추가.

6. 이번 주 안에 글 1편 더. 본인이 오늘 검색했는데 답이 없었던 것.

7. 일요일 저녁마다 글 1편. 6개월간.

7가지 안티패턴 — 가장 흔한 실수

1. **본진을 트위터에 두기** — 알고리즘은 빌리는 거다.

2. **첫 글을 너무 거창하게 잡기** — 800자도 글이다. 그냥 게시하라.

3. **"디자인부터" 함정** — 디자인 100시간 쓰는 동안 글 100편이 가능하다.

4. **3개월 만에 그만두기** — 6개월 안에 결과 안 나오는 게 디폴트다.

5. **남의 블로그 1:1 흉내** — 톤은 시간이 깎는다. 흉내는 1년만.

6. **댓글 0개에 절망하기** — 댓글은 안 달릴 수 있다. RSS 구독자가 진짜 신호다.

7. **머네타이즈에 일찍 손대기** — 구독자 1,000명 전에 유료화 X. 풀이 안 자란다.

다음 글 예고

- **개발자 콘텐츠로 머네타이즈하기 — 광고·스폰서·유료 멤버십·강의·책의 경제학 (2026)**

- **"내 블로그를 LLM이 인용하게 하기" — GEO 실전 가이드**

- **첫 글 100편의 흔한 함정 — 1년치 글을 1주마다 진단하기**

> "콘텐츠를 만들 이유가 1개에서 10개로 늘었다. 하지만 시작하는 사람은 줄었다. 그래서 지금 시작하는 게 그 어느 때보다 큰 보상을 준다."

— 개발자 콘텐츠 크리에이션, 끝.

참고 / References

플랫폼

- Substack — https://substack.com

- Beehiiv — https://www.beehiiv.com

- Kit (구 ConvertKit) — https://kit.com

- Buttondown — https://buttondown.com

- dev.to — https://dev.to

- Hashnode — https://hashnode.com

- Medium — https://medium.com

- Hacker News — https://news.ycombinator.com

- Lobsters — https://lobste.rs

- Bluesky — https://bsky.app

- Threads — https://www.threads.net

- Mastodon — https://joinmastodon.org

도구

- Descript — https://www.descript.com

- Loom — https://www.loom.com

- Cleanshot X — https://cleanshot.com

- Figma — https://www.figma.com

- Excalidraw — https://excalidraw.com

- Carbon — https://carbon.now.sh

- Ray.so — https://ray.so

- Plausible — https://plausible.io

- Posthog — https://posthog.com

본받을 만한 개발자 블로그 · 채널

- Julia Evans (jvns.ca) — 일러스트레이션 + 짧은 깊이의 표준

- Dan Abramov (overreacted.io) — 에세이 블로그의 정점

- Josh Comeau (joshwcomeau.com) — 인터랙티브 글의 디자인 표준

- Patrick McKenzie / patio11 — 비즈니스 시각의 깊은 글

- Fireship / Jeff Delaney (YouTube) — 100초 모델

- Theo / t3.gg (YouTube + blog) — 라이브 + 정리

- Lenny Rachitsky — 뉴스레터 디자인의 표준

- Casey Newton / Platformer — 독립 저널리즘 모델

- The Pragmatic Engineer / Gergely Orosz — 깊이 + 빈도의 균형

- Swyx / Latent Space — AI 엔지니어 콘텐츠의 정점

- jbee.io — 한국 개발 블로그의 솔직 톤

- 김덕성 / kdeuk.tistory — 한국 백엔드 깊이 글

- evan moon — 한국 프론트엔드의 강한 의견

메타 · 데이터

- llms.txt — https://llmstxt.org

- robots.txt for AI crawlers (Google-Extended, GPTBot, ClaudeBot)

- IndieWeb — https://indieweb.org

- RSS specification — https://www.rssboard.org

> 모든 콘텐츠는 결국 글이다. 영상은 글의 시각화고, 트윗은 글의 압축이고, 토크는 글의 발표다. 글을 잘 쓰는 개발자가 가장 멀리 간다. 2026년에 더 그렇다.