Skip to content
←

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

|

개발자가 콘텐츠로 오디언스를 만드는 법 — 블로그·유튜브·뉴스레터·트위터, 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분면으로 정리하면 깔끔하다.

축검색 가능(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 시대 영향이 다르다.

축개인 블로그YouTube뉴스레터Twitter/X·LinkedIndev.to·Hashnode
글/영상 한 편당 시간3~8시간6~20시간2~6시간10~60분1~3시간
오디언스 빌딩 속도매우 느림빠름(알고리즘)느림(소유 가능)매우 빠름보통
깊이 적합도매우 높음중간(15분 한계)높음매우 낮음보통
머네타이즈 경로적음(직접)광고·스폰서유료 멤버십스폰서·DM적음
AI 시대 영향순풍(LLM 인용)순풍(영상은 LLM이 못함)강한 순풍(소유한 채널)역풍(SEO 없음, 휘발)혼합
데이터 소유권100%(자기 도메인)0%(YouTube)80%(이메일 리스트)0%30%
인용 안정성매우 높음낮음(URL 변경 적음이나 컨텐츠 자체는 인용 어려움)중간(아카이브)낮음(트윗 휘발)중간

한 줄 요약

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

축SubstackConvertKit (rebrand Kit)Beehiiv
진입 난도가장 쉬움중간중간
비용(첫 1k 구독자)무료무료무료
비용(10k 구독자)10% 수수료(유료시)약 79달러/월약 49달러/월
추천(referral)Notes 알고리즘약함강함(Boost)
데이터 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

플랫폼

도구

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

  • 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 — 한국 프론트엔드의 강한 의견

메타 · 데이터

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

How Developers Build an Audience in 2026 — Blogs, YouTube, Newsletters, Twitter: The Craft (Deep Dive) english

Prologue — The Reason to Make Content Changed in 2026

Ten years ago a developer's reason to blog was simple. "Get found on Google so future employers can find me." That was it.

2026 is different. Three discovery surfaces collapsed and resurfaced almost simultaneously.

  • The death and rebirth of SEO. Google's AI Overviews (formerly SGE), Perplexity, and ChatGPT search have eaten the SERP. "Zero-click search" is the default. Your analytics graph drops. And yet — your writing is being read more, just not by humans.
  • LLMs read your writing. Once as training data; daily as RAG context during inference. When ChatGPT answers "How do I do ISR in Next.js 13?", part of that answer was someone's blog post. That someone could be you. "Writing so that an LLM cites you" is the new definition of SEO.
  • Discovery moved to algorithms. Twitter/X For You, LinkedIn feed, YouTube recommendations, dev.to trending, the Hacker News front page — algorithms, not search, deliver you to new readers. Search is the surface for return visits; algorithms are the surface for discovery.

One thing has not changed. Developers who write well are still rare. AI made the average free, which made the rare even rarer. The average gets pumped out in five seconds by an LLM. Only what only you can write — the compressed hour of experience, the narrow deep taste, the honest failure — survives.

This piece is about the craft, not the money. Ad rates, sponsorship cuts, paid-membership conversion belong in a different post. Here we cover what to make, how to start, what fits which channel, how to find your voice, and what NOT to do.

To put the conclusion up front — the single most underrated channel of 2026 is a personal blog on your own domain that you keep posting to. Chapter 13 defends that.

1 · What to Write, What to Record — The Content Quadrant

The most common stuck-point when starting a blog is not "I have nothing to write." It is "I have too much to write and don't know which to pick." A 2x2 quadrant cleans it up.

axisSearchableAlgorithm-discoverable
Tutorial / How-to"How to configure ISR in Next.js 15 App Router""How I broke my SEO in 3 minutes with ISR"
Essay / Opinion"Why we left microservices""5 lies told in frontend hiring interviews"
  • Tutorial + Search — long shelf life, slow start. One good one stays useful for five years. LLMs cite this most. Fits a blog, dev.to, your own domain.
  • Tutorial + Algorithm — short burst, fast feedback. Fits YouTube and Twitter threads. The Fireship model.
  • Essay + Search — long shelf life plus authority. Hardest and most valuable. Your own domain plus Hacker News.
  • Essay + Algorithm — fastest audience build. Twitter and LinkedIn short-form. Risk: volatile, may not accrue trust.

Start with one quadrant. Trying all four at once means all four are mediocre. The safest pick is Tutorial + Search for six months, then add a second quadrant. Reason: validation is immediate (the code works so the post is correct), the self-esteem barrier is low (explanation is the value), and LLMs cite it.

Three veins of inexhaustible ideas

  1. "Something I searched today and could not find an answer for." The best vein. No answer = a market exists. Write it up that evening.
  2. "Something a senior caught in my PR." Pre-validated learning. "N things I learned in code review" is a series that never runs dry.
  3. "What I wish my self-from-six-months-ago had read." Most authentic. The reader is always six-months-ago-you.

What not to write

  • "What is X?" posts — Wikipedia and LLMs win that.
  • Summary posts with no first-hand source — net-negative value.
  • Company-flex pieces — put them on your careers page.
  • "10 things..." listicles — that ended in 2018.

2 · Start Small — The First-100 Rule

The biggest lie of content advice is "be consistent." Too abstract to act on. Two operational rules instead.

Rule 1 — Treat the first 100 pieces as throwaway

Almost every successful developer creator says the same thing. "My first year of writing was terrible." Fireship, Theo, Josh Comeau, Lee Robinson, Dan Abramov — all of them. The first 100 pieces are for finding your voice, not for an audience.

For YouTube, the first 30 videos. For Twitter, the first 500 tweets. For a newsletter, the first 20 issues. Asking "why no traction yet?" in this period is like running 1 km and asking why you didn't win a marathon.

Rule 2 — One piece a week, for six months

Frequency is the lever, but set too high it snaps. 1 per week, for 6 months (= 26 pieces) is the most validated entry slot. After that, raise or lower freely.

You don't need to write daily. You need to collect daily. The code you ran into, the problem you got stuck on, a PR comment you liked — keep a small note. Sunday evening, pick one and turn it into a post. Cleanshot for screenshots, Notion for the draft, Monday morning to your blog.

What "small" actually means

  • 800 words is a post. 2,000 is the average but 800 is enough if it concludes. Start short.
  • One conclusion per post. Two conclusions makes both weak.
  • 1 to 3 code snippets per post. Five or more, and the post should have been a GitHub repo.
  • One line of text is enough for the cover image. Figma is nice but spend that time on the writing first.

3 · Channel Economics — Five Surfaces at a Glance

This table is the center of the post. Every channel differs in time, audience speed, depth fit, monetization, and AI-era exposure.

axisPersonal BlogYouTubeNewsletterTwitter/X · LinkedIndev.to · Hashnode
Hours per piece3 to 86 to 202 to 610 to 60 minutes1 to 3
Audience-build speedvery slowfast (algorithm)slow (but owned)very fastmedium
Depth fitvery highmedium (15-min ceiling)highvery lowmedium
Monetization pathsparse (direct)ads, sponsorspaid membershipssponsors, DMssparse
AI-era impacttailwind (LLM citation)tailwind (LLMs cannot watch video)strong tailwind (you own the channel)headwind (no SEO, volatile)mixed
Data ownership100 percent (your domain)0 percent (YouTube)80 percent (email list)0 percent30 percent
Citation stabilityvery highlow (URLs persist but content is hard to cite)medium (archive)low (tweets evaporate)medium

One-line summary

  • Personal blog — the long game. Strongest AI-era tailwind and the most underrated of all in 2026. See chapter 13.
  • YouTube — fastest audience, most expensive production. The Fireship model is hard to copy.
  • Newsletter — the only real answer to "a channel I own." The 2025 trend is Substack to Beehiiv.
  • Twitter/X and LinkedIn — distribution surfaces. Not your home base. They drive traffic to somewhere else.
  • dev.to and Hashnode — bootstrap to your first readers. Your real home is your own domain.

4 · The Personal Blog — Home Base for the Long Game

Conclusion first. Every developer should have a blog on their own domain. It is foundation, not channel choice.

Why your own domain

  • You own the data. Medium, dev.to, Hashnode change policy whenever. Medium added a paywall in 2020. dev.to changes its algorithm constantly. The domain is yours.
  • URL stability equals LLM-citation stability. LLM training relies on URLs not changing. Domain hosting outlives platforms.
  • Trust weight. yourname.dev/post reads differently from medium.com/@username/post. The former carries more authority.
  • It fuses with your portfolio. Blog plus About plus Projects on one domain is a complete introduction.

Stack

The most common combo — Next.js + MDX + Tailwind + Vercel. This blog is one. Alternatives.

  • Astro — fastest build, lightest static site. Sharp share gain through 2025.
  • Hugo — extremely fast builds. Go-template learning curve.
  • Jekyll + GitHub Pages — zero dollars, zero ops. Weak analytics is the trade.
  • Notion to static site (Notion API plus Next.js) — best authoring UX, less search weight.

Five operating principles

  1. One post, one URL, forever. Do not change URLs. Redirects help humans, but LLM citations still degrade.
  2. Keep RSS on. Not dead. Resurrected. RSS readers are the home base for people fatigued by algorithms.
  3. Take multilingual seriously. A Korean-only blog reaches 5 percent of the pool. English plus Japanese plus Korean as a triple grows the pool by a hundred times. AI translation has been good enough since 2024.
  4. Do not block search. Avoid blanket-blocking GPTBot or ClaudeBot in robots.txt. Your call, but a block costs LLM citations. The llms.txt standard landed in 2026 — add one.
  5. Comments are optional. Disqus is slow and ad-laden. Wire GitHub Discussions, or just link to a tweet reply.

Six-month goals

  • 26 posts (one per week for 26 weeks).
  • 100 RSS subscribers.
  • One post on the Hacker News top 30. If not, do another six months.
  • Try once to be cited by an LLM. Search your post title in ChatGPT and check if it shows up as a source.

5 · YouTube — Can You Copy the Fireship Model?

Fireship (Jeff Delaney) and the 100-second series rewrote the standard for developer YouTube. About 3.5 million subscribers as of 2026. Per-video views in the 1 to 5 million range. Many try to copy it. Few succeed. Here is why.

Anatomy of the Fireship model

  • 100 seconds to 8 minutes per video. "Never give them time to be bored" is the first rule.
  • 1 to 3 second average cut length. Visual stimulation never stops.
  • B-roll is dominant. Code is never alone on screen. Memes, illustrations, screen captures, short clips overlay everything.
  • The title is the hook. "Next.js in 100 seconds" catches both search and algorithm.
  • Compression ratio. Six hours of docs into 100 seconds. This is the hardest part.

Why beginners struggle to copy it

  • An average of 10 to 20 hours of editing per video. Impossible with a day job.
  • Second-level cut sense takes a year-plus of training.
  • The curatorial compression to 100 seconds needs five-plus years of experience.

Three YouTube models that fit beginners better

  1. Theo / t3.gg model — "live, then trim." Record live coding or live reactions, cut after. Naturalness is the strength. Lighter edit.
  2. Primeagen model — "live code review." Look at other people's code or PRs and comment. Content source is infinite.
  3. Josh tried Coding model — "essay video." Slides, voice, sometimes code. Light edit, deep depth.

For beginners, the 100-second model is a trap. The first 30 videos should be "I really explain one topic in 10 minutes."

Tool stack

  • Recording — Descript (recording + editing integrated), Loom (easiest), OBS (most free), Riverside (high-quality interviews).
  • Editing — Descript (text-based), Final Cut Pro / DaVinci Resolve (traditional).
  • Thumbnails — Figma plus Photoshop. Figma alone at first.
  • Audio — Shure SM7B is a luxury. A Rode NT-USB Mini is plenty to start.

6 · Newsletter — The Only Real Owned Channel

One-line truth about 2026 distribution. Algorithms are rented; an email list is owned. As Twitter became X and the algorithm changed four times, your email list stayed yours.

Three platforms compared (2026)

axisSubstackConvertKit (rebranded Kit)Beehiiv
Entry difficultyeasiestmediummedium
Cost (first 1k subscribers)freefreefree
Cost (10k subscribers)10 percent cut on paidabout 79 dollars per monthabout 49 dollars per month
ReferralNotes algorithmweakstrong (Boost)
Data exportyesyesyes
Algorithm dependencehigh (Notes)lowmedium
Ads / sponsorsdirectdirectbuilt-in ad network
2025 to 2026 issuepolitics controversy, exodusstablefastest growth

The one-line 2025 trend. "Substack to Beehiiv migration." Politics controversy and algorithm volatility pushed top names like Casey Newton and Lenny Rachitsky to Beehiiv or self-hosting. For a new starter, Beehiiv is the safest default.

Three newsletter content models

  1. Curation plus commentary — "this week's dev news plus my one-liner." Easiest entry and longest runway. The Pragmatic Engineer, Tech Ladders, JavaScript Weekly.
  2. Deep dive — "one topic, 5,000 words per week." Hardest and most valuable. Pragmatic Engineer paid, Lenny's Newsletter.
  3. "My week" — a developer's weekly journal. Light but strong for building trust. Risk is running out of material.

Operating principles

  • Biweekly is the sweet spot. Weekly shakes the day job, monthly gets forgotten.
  • Fill the first 100 from your first- and second-degree network. "Email 50 people directly" is the start of every newsletter.
  • Turn on blog-to-newsletter automation. Blog is the home base, newsletter is the digest. RSS-to-Email.
  • Paywall later. Going paid before 1,000 free subscribers stalls the free pool.

7 · Twitter/X · LinkedIn · Bluesky — Distribution Surfaces

These are not home bases. They drive traffic to your home base. Get this distinction wrong and you end up Twitter-addicted with nothing to show.

State of play in 2026

  • Twitter/X — still the number-one developer distribution surface. The For You algorithm is widely believed to down-rank external links, so images and threads dominate. The post-API-closure outside-tool ecosystem collapsed.
  • LinkedIn — the biggest pool of senior developers and managers. Tone is different: first person, lots of line breaks, restrained emoji. The algorithm is known to penalize external links, so the standard pattern is to put the link in the first comment.
  • Bluesky — exploded in 2024 to 2025, growth flattened in 2026. Part of the dev community migrated but discovery is weak. About "the part of tech Twitter that left."
  • Threads — Meta's answer. Massive by 2026 but low dev-community share.
  • Mastodon — small but tight community. Devs who like fediverse make it their home.

Five patterns for good tweets

  1. Assertion plus reasoning — "ORMs lose in 95 percent of cases. Three reasons." Then unpack in the replies.
  2. Reversal opener — "Everyone loves React. I have used Backbone for seven years. Here is why." Curiosity is what the algorithm feeds on.
  3. Screenshots are the body. Code screenshots can be longer than the tweet. Carbon, Ray.so, Cleanshot.
  4. One number. "12 times faster," "47 percent decrease," "in just 3 minutes." Exactly one precise number per tweet.
  5. Threads under seven. Past that, drop-off destroys it. Depth belongs on the blog.

LinkedIn tone details

  • First line = hook. "Today my team recovered data loss in 4 hours."
  • Second line = blank.
  • Short paragraphs. One to two sentences each.
  • Last line = question. "What would you have done?"
  • External link in the first comment. Penalty avoidance.
  • Zero or one emoji. Don't look like sales.

What not to do

  • Treating Twitter as your home base — the algorithm is rented.
  • Going too "looking-for-work" on LinkedIn — seniors smell it instantly.
  • Betting it all on Bluesky — discovery is too weak.

8 · Community Surfaces — dev.to · Hashnode · Hacker News · Lobsters

These are neither home base nor distribution. They are community bootstrap — the fast entry to your first readers.

dev.to

  • Pros — easiest entry. Paste Markdown as is. First post can get 50 to 500 views.
  • Cons — algorithm shifts often. SEO weaker than your own domain. Zero data ownership.
  • 2026 use — publish to your own blog first, then cross-post to dev.to seven days later with the canonical URL set. You get both.

Hashnode

  • Free custom-domain mapping — one level above dev.to.
  • The build is host-dependent — export is possible but not as free as Next.js.
  • A fine six-month bootstrap. Migrate to your own stack after a year.

Hacker News

  • The peak of developer discovery. One front-page hit is usually 50,000 to 500,000 views.
  • How to submit — don't post your own; let a friend. Spam rings get banned instantly. The safest move is "submit it and forget it."
  • Timing — UTC 14:00 to 20:00 is when fresh items do well. Weekends are lower traffic but less competition.
  • Titles must be stronger than your first sentence. Not "Why X" but "X is broken. Here is why."

Lobsters

  • Narrower and deeper than HN. Systems, languages, security are strong.
  • Invite-only — the entry barrier is the invite, but inside the comment quality is the best anywhere.
  • One front-page hit is one-twentieth of HN in traffic, but the comments are the deepest.

Reddit r/programming · r/webdev · r/golang etc.

  • Subreddit rules are strict. Self-promotion is blocked in many.
  • But when it hits, it is HN-adjacent traffic. Read the subreddit's rules before posting.

9 · Conference Talks · Podcasts — The Slow Channels

The last two surfaces. Not fast. But one good output buys five years of trust.

Conference talks

  • First talk at a local meetup. 30 minutes, 30 attendees. Cut the fear.
  • Then a regional conference. JSConf KR, FEConf, PyCon KR, NDC, DEVIEW. Put CFP deadlines on the calendar.
  • Global comes next. React Summit, JSNation, KubeCon. The talk video on YouTube becomes content.
  • How to write a CFP. Title + 5-sentence abstract + 3-sentence takeaway. Your existing blog posts are the topic source.

Podcasts

Hosting your own is not recommended. Too much time, the first six months rarely cross 30 listeners. Be a guest on someone else's instead.

  • Latent Space — the peak of AI-engineer podcasts. Swyx and Alessio.
  • Changelog — the standard for open-source and developer interviews. Going for over ten years.
  • Software Engineering Daily — a new interview every day. Largest guest pool.
  • CoRecursive — developer storytelling. Very deep.
  • Korean — "I am a PRO," "Job Jamming," and others.

To be invited as a guest you need 5 to 10 strong posts on your blog. That is your card.

10 · Tool Stack — The 2026 Standard

The last practical chapter. The tools a writer writes with are their hands.

Writing flow

  • Capture — Apple Notes or Bear. Fast.
  • Draft — Notion. Strong multimedia embeds and collab.
  • Publish — MDX on your blog. VS Code plus Markdown All in One plus Vale.
  • Images — Cleanshot X for screenshots, Figma for thumbnails and illustrations, Excalidraw for diagrams, Carbon and Ray.so for code images.

Video and recording

  • Recording — Loom (simple), Descript (recording plus editing), OBS (most free).
  • Editing — Descript (text-based), Final Cut Pro / DaVinci Resolve (traditional).
  • Transcripts — Whisper Large v3 (open source), MacWhisper (Mac UI).

Newsletter

  • Beehiiv — default for new starters.
  • Substack — if you already have a pool, stay.
  • Buttondown — developer-friendly minimal.

Analytics

  • Plausible / Umami — cookieless, light.
  • Posthog — when you need deeper analytics.
  • Google Analytics is not recommended in 2026.

AI assist

  • Claude / ChatGPT — polish drafts and grammar.
  • Grammarly — for English only.
  • DeepL — multilingual translation. Core of a Korean to English to Japanese workflow.
  • Never — do not let the LLM decide the conclusion. The conclusion is yours. The LLM is for polish.

11 · Finding Your Voice

The most abstract and most important chapter. Tools and channels are learned in a year. Your voice takes five.

Voice is sculpted, not found

You start by mimicking a writer you like. That is natural and recommended. After about a year, the mimicked tones collide. At the collision point your own tone shows.

  • Dan Abramov's stance — "do not explain the complex as if it were simple. Explain the simple as if it were precise."
  • Julia Evans' illustrations — "the small piece I learned today."
  • Patrick McKenzie (patio11) — business lens — "this code moves whose money how."
  • Jbee, Hyunwoo, and other Korean dev bloggers — first-person honesty, anti-hype.

What combination of these are you? Where does your tone show? After a year, reread your posts in a single sitting and it appears.

Four exercises to find your tone faster

  1. Read a year of your own writing in one sitting. Repeated words, repeated sentence shapes — that is your tone.
  2. Send three of your posts to five close friends. "Who do you think wrote this?" The answer is your tone.
  3. Write down 10 words you will never use. "Leverage," "synergy," "incredible" — the words you avoid shape your tone.
  4. Record one post aloud. If it sounds nothing like how you actually speak, it is a mask.

Options versus opinions

The biggest polarity in dev content tone.

  • Option pieces — "There are methods A, B, C, with these pros and cons." Balanced but forgettable.
  • Opinion pieces — "Use B. A is a trap, C is overkill." Provokes, but stays in memory.

Start with option pieces. After enough writing, opinions form naturally. Once they do, don't shrink from writing them. Disagreement beats indifference.

12 · Content in the AI Era — LLMs Read Your Writing

The biggest variable of 2026 content. Chapter we can no longer defer.

Read twice

  • Once as training data. Your writing may sit in the training set of GPT-5, Claude 4.5, Gemini 2.5. You can also opt out — block GPTBot, ClaudeBot, Google-Extended in robots.txt.
  • Daily, N times, in inference. Perplexity, ChatGPT search, Claude with web search pulls your post via RAG when answering. Every day.

Writing so the LLM cites you — GEO (Generative Engine Optimization)

GEO is a 2025-coined term. SEO for LLMs.

  1. Clear definition sentence. "X is Y." One sentence to open. LLMs cite definition sentences best.
  2. Comparisons with numbers. "A is 12 percent faster than B." Sentences with numbers are cited five times more often (the consensus of several GEO studies).
  3. Lists. Bullets are cited more than prose.
  4. URL stability. A live URL in the LLM's training data preserves the citation.
  5. Add llms.txt. A 2026-landed standard. Put llms.txt at the root to tell LLMs "these are the core docs of this site."

You can also block citations

  • User-agent: GPTBot Disallow: /
  • User-agent: ClaudeBot Disallow: /
  • User-agent: Google-Extended Disallow: /
  • This blocks traffic too. Policy is your call.

One honest change

Search traffic drops. But the number of "people who saw your post" is similar or even higher. They simply saw it via ChatGPT. So if GA traffic is dropping and you stop posting, you misread the signal.

13 · The Single Most Underrated Channel of 2026 — Defending the Personal Blog

Now the defense I deferred in chapter 7.

Four lines of defense

  1. The currency of the AI era is the URL. What an LLM can cite is writing, and writing has an address — the URL. Tweets have URLs but evaporate. Videos have URLs but are hard to cite. A blog post has both.
  2. Algorithm dependence is zero. Twitter, LinkedIn, YouTube — one algorithm change halves your traffic. Your own domain blog is immune to algorithm changes. Even if the search algorithm changes, RSS, newsletter, and LLM citations remain.
  3. It is a long-lived asset. A post written five years ago still pulls traffic today. YouTube videos still play but the algorithm barely surfaces them. Tweets are gone in 24 hours. Blog posts are a five-year asset.
  4. It becomes the home base for every other channel. Twitter threads are blog-post summaries. Newsletters are blog-post digests. YouTube videos are blog-post visualizations. Conference talks are blog-post presentations. Without a blog, the rest float.

Why blogs get ignored anyway

  • "It is already too late" — wrong. The AI-era content ecosystem is restarting.
  • "Traffic is not coming" — impatience. Six months with no traffic is normal. Do not value a six-year asset on six months.
  • "I have nothing to write" — false. What you searched today is the next post.
  • "The design is bad" — avoidance. The default Tailwind template is fine. Worry about design after 100 posts.

One-line conclusion

Your domain blog is the home base, and every other channel is rented from it and routed back to it. If you are starting content in 2026, buy the domain first and publish your "Hello World" first.

Epilogue — To You, One Year From Now

Five years from now you are one of two types.

(A) 30 posts, 0 videos, 200 newsletter subscribers, 50 RSS subscribers. Traffic is so-so but — someone outside your company recognizes your name. A PR comment says "I saw this in your post." A recruiting DM lands on LinkedIn. A CFP gets accepted. A five-year asset has compounded.

(B) 2,000 Twitter followers, 0 blog posts. Home base is Twitter, the algorithm changes monthly. One volatility shock and you are back to zero. Nowhere to collect the work. Leave Twitter and the trail is gone.

The path to A is simple. Buy a domain, set up MDX, publish one post, publish another every Sunday. Six months. 26 posts. That is it.

Day-zero checklist — seven things to do today

  1. Buy the domain (yourname.dev or yourname.io).
  2. Clone a Next.js + MDX template (this blog is one).
  3. Deploy to Vercel. Five minutes.
  4. Publish "Hello World" as one post.
  5. Turn on RSS and subscribe yourself in an RSS reader.
  6. One more post this week. Something you searched today but found no answer for.
  7. One post every Sunday evening. For six months.

Seven anti-patterns — the most common mistakes

  1. Treating Twitter as your home base — algorithms are rented.
  2. Picking the first post too grand — 800 words is a post. Publish.
  3. The "design first" trap — in 100 hours of design you could write 100 posts.
  4. Quitting at three months — no result inside six is default.
  5. One-to-one mimicry of someone's blog — voice is sculpted by time. Mimic for a year, then stop.
  6. Despair over zero comments — comments rarely come. RSS subscribers are the real signal.
  7. Monetizing too early — paywall before 1,000 subscribers. The pool will not grow.

Coming up next

  • Monetizing developer content — economics of ads, sponsorship, paid memberships, courses, and books (2026)
  • "Get cited by an LLM" — a hands-on GEO guide
  • Common traps in the first 100 posts — diagnosing a year of writing one week at a time

"The reasons to make content went from 1 to 10. The number of people starting fell. Which means starting now pays more than it ever has."

— Developer content creation, end.

References

Platforms

Tools

Developer blogs and channels worth modeling

  • Julia Evans (jvns.ca) — illustration plus short-form depth, the standard
  • Dan Abramov (overreacted.io) — the peak of essay blogs
  • Josh Comeau (joshwcomeau.com) — interactive writing design standard
  • Patrick McKenzie / patio11 — deep posts through a business lens
  • Fireship / Jeff Delaney (YouTube) — the 100-second model
  • Theo / t3.gg (YouTube + blog) — live then trim
  • Lenny Rachitsky — newsletter design standard
  • Casey Newton / Platformer — independent journalism model
  • The Pragmatic Engineer / Gergely Orosz — balance of depth and cadence
  • Swyx / Latent Space — peak AI-engineer content
  • jbee.io — Korean blog's honest first-person tone
  • evan moon — strong Korean frontend opinions

Meta and data

All content is writing in the end. Video is writing visualized. A tweet is writing compressed. A talk is writing presented. The developer who writes well goes the farthest. More so in 2026.