개발자가 콘텐츠로 오디언스를 만드는 법 — 블로그·유튜브·뉴스레터·트위터, 2026년의 크래프트 (심층)

프롤로그 — 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분면으로 정리하면 깔끔하다.

• 튜토리얼·검색 — 긴 수명, 느린 시작. 한 번 잘 쓰면 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 시대 영향이 다르다.

한 줄 요약

• 개인 블로그 — 장기전. 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년 기준)

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년에 더 그렇다.