솔직하게 밝히는 나의 베팅은 다음과 같습니다: 2027년 4월까지, 내가 Dev.to와 Hashnode에 교차 게시(cross-publish)하는 기사들이 내 3개의 디렉토리 사이트로 가져오는 월간 유기적 세션(organic sessions)이 Bluesky 포스트의 추천 클릭(referral clicks)을 통한 유입보다 최소 3배 더 많을 것이라는 점입니다. 수치가 확보되면 공개하겠습니다.

현재 유기적 트래픽(Organic traffic)은 오차 범위 수준으로 매우 적습니다. 시작한 지 4개월이 지났지만, 검색 인덱싱(search indexing)은 여전히 따라잡는 중입니다. 이 글은 최종 결론이 아닙니다. 나중에 스스로에게 책임을 물을 수 있도록 미리 등록해 두는 근거입니다.

여기서 "복리(compound)"가 실제로 의미하는 것

소셜 포스트는 빠르게 소멸합니다. Bluesky 포스트는 몇 시간 동안만 살아있으며, 재공유(reshare)가 된다 해도 하루 정도일 것입니다. 피드가 시간순으로 구성되고 빠르게 스크롤되기 때문에 추천 클릭(referral click)의 창은 매우 좁습니다. 3개월 전의 Bluesky 포스트로 누군가를 다시 불러올 수 있는 메커니즘은 없습니다.

Dev.to에 게시된 기사들은 다르게 작동합니다. Dev.to는 90 이상의 도메인 점수(domain rating)를 보유하고 있습니다. 기사들은 몇 시간 내에 Google 인덱스(index)에 나타나며 그 상태를 유지합니다. 해당 기사가 순위가 매겨진 문구를 누군가 검색한다면, 그 기사는 2년 후에도 유기적 검색 트래픽(organic search traffic)을 받게 됩니다. 4개월 동안 138개의 기사를 게시했다는 것은, 현재 138개의 인덱싱된 문서가 각각 독립적으로 검색 노출 영역(search surface area)을 축적하고 있음을 의미합니다.

축적은 비선형적(nonlinear)이기 때문에 "복리(Compound)"가 적절한 단어입니다. 각 기사는 Google 인덱스 내에서의 전체 발자국(footprint)을 증가시키는 코퍼스(corpus, 말뭉치)를 확장합니다. 4개월 차의 기사는 1개월 차의 기사로부터 혜택을 받는데, 이는 기사들이 서로 연결되어 있고 광범위한 주제 커버리지가 깊이(depth)를 나타내기 때문입니다. 12개월 차의 컬렉션은 1개월 차의 컬렉션에 11개월간의 쇠퇴가 더해진 것이 아니라, 복리로 쌓이는 내부 권위(internal authority)를 가진 확장되는 도서관처럼 보일 것입니다.

이것이 대규모로 운영되는 개발자 콘텐츠 사이트들이 작동하는 방식입니다. Stack Overflow, CSS-Tricks, 그리고 1년 된 Hacker News 스레드들이 2026년에도 검색 결과에 나타나는 이유는 그 메커니즘이 유지되기 때문입니다. 제가 그 정도 규모로 구축하겠다는 주장을 하는 것이 아닙니다. 메커니즘은 동일하다는 점을 주장하는 것입니다. Google의 자체 E-E-A-T 가이드라인은 그들이 편집적 깊이(editorial depth)에서 무엇을 찾고 있는지를 설명합니다. 즉, 경험(Experience), 전문성(Expertise), 권위성(Authoritativeness), 신뢰성(Trustworthiness)입니다. 1인칭 경험을 보여주는 교차 게시(Cross-published)된 기사들은 바로 그 신호(signal)를 직접적으로 겨냥합니다.

내가 기대하는 Dev.to 인덱싱(indexing)의 이점

교차 게시 파이프라인은 Dev.to가 표준(canonical)을 보유하도록 설정되어 있습니다. 내가 내부 링크 해결 시스템을 구축했을 때, Hashnode의 originalArticleURL 필드가 Dev.to URL을 다시 가리킬 수 있다는 것을 발견했습니다. Google은 하나의 문서로 인식하고, Hashnode의 독자들은 동일한 콘텐츠를 보게 됩니다. 두 플랫폼 모두 기사를 전달하지만, 오직 Dev.to만이 랭킹 신호(ranking signal)를 가져갑니다.

게시 워크플로우는 main 브랜치에 커밋(commit)될 때 실행되며 두 플랫폼을 순차적으로 처리합니다. 그 과정에서 몇 가지 특수한 예외 상황(edge cases)을 처리해야 했습니다. Dev.to에는 명확하지 않은 속도 제한(rate-limit) 및 초안 상태(draft-state) 동작 방식이 존재하며, 저는 이를 운영 환경에서 겪은 후 문서화했습니다.

실질적인 효과는 다음과 같습니다: 내가 쓰는 모든 기사는 24시간 이내에 인덱싱 가능한 문서가 됩니다. 누적된 인덱스는 단조 증가(monotonically)합니다. Dev.to와 Google의 관계가 변하지 않는 한, 어떤 기사도 만료되지 않습니다.

이 방식에 반대하는 논거는 실재합니다. 즉, 나는 나의 도메인이 아닌 Dev.to의 도메인 위에 권위(Authority)를 쌓고 있다는 점입니다. 유용한 쿼리(Query)에 대해 순위가 매겨진 기사는 독자를 Dev.to로 먼저 보냅니다. 하지만 그 대안인, 기사가 몇 주 동안 인덱싱(Indexing)되지 않은 채 방치되는 나의 새로운 도메인에만 게시하는 방식은 0~12개월 차의 복리 효과(Compounding clock)를 완전히 상실하게 만듭니다. 초기 성장 단계에서 Dev.to의 권위를 빌려 쓰는 것이 우아한 방식은 아닐지라도, 제로(Zero)에서 시작하는 것보다는 빠릅니다.

Bluesky가 나에게 주는 것과 주지 않는 것

한 달 전, 나는 Bluesky를 나의 최상위 추천 채널(Referral channel)로 베팅하고 있다고 썼습니다. 그 기사의 논리는 여전히 방어 가능합니다. Bluesky의 시간순 피드(Chronological feed)와 개발자 밀도가 높은 오디언스는 대부분의 소셜 채널보다 클릭당 더 나은 품질을 만들어냅니다. 하지만 Bluesky가 하지 못하는 것에 대해서는 정확히 짚고 넘어가고 싶습니다.

JSONL 큐 파이프라인은 하루에 한두 개의 항목을 게시하며, 신선한 콘텐츠를 통해 작지만 실제적인 클릭률(Click-through)을 생성합니다. Bluesky가 하지 못하는 것은 축적(Accumulate)입니다. 지난주에 올린 게시물은 오늘 추천 클릭을 전혀 생성하지 못합니다. 각 게시물의 추천 유효 기간은 대략 48시간입니다.

채널마다 구조적으로 다른 형태를 가지고 있기 때문에 이 비교는 중요합니다:

내가 베팅하는 3배의 비율은 콘텐츠당 정점 세션(Peak sessions)이 아니라, 12개월 동안의 누적 세션(Cumulative sessions)에 관한 것입니다. 성장하는 인덱싱된 코퍼스(Corpus)로부터 발생하는 12개월 차의 유기적 트래픽(Organic traffic)은 12개월 차의 Bluesky 추천 트래픽을 실질적으로 초과해야 합니다. Bluesky의 총량은 365개의 게시물 × 48시간의 유효 기간에 의해 제한됩니다. 반면 기사의 총량은 12개월 동안 복리로 쌓이는 인덱스 커버리지(Index coverage)입니다.

솔직한 반론

AI 개요 (AI overviews). Google은 정보성 쿼리 (informational queries)에 대해 검색 결과 페이지에서 직접 답변을 제공하는 비중을 점점 늘리고 있습니다. 지난 5월, 저는 탐색형(navigational) 및 비교형(comparison) 쿼리가 정보성 쿼리보다 이러한 현상에 더 잘 저항한다는 별도의 베팅을 한 바 있습니다 — 제가 운영하는 디렉토리들은 일반적인 방법(how-to) 쿼리보다는 "X와 유사한 게임 찾기"나 "Y의 오픈 소스 대안"을 타겟팅합니다. 그 베팅은 여전히 유효합니다.

하지만 제가 교차 게시(cross-publishing)하는 기사들이 모두 탐색형인 것은 아닙니다. "이 특정 코드베이스에서 X를 어떻게 구현했는가"와 같은 기술적인 기사들은 본질적으로 정보성(informational)입니다. 만약 Google이 클릭 유도(click-through) 없이 검색 결과 페이지에서 이러한 질문에 답변하기 시작한다면, 유기적 검색(organic search)에서 해당 기사들이 갖는 롱테일(long-tail) 가치는 침식될 것입니다.

저는 세 개의 좁은 버티컬(verticals)이 하나의 넓은 애그리게이터(aggregator)를 이기는 이유가 바로 버티컬의 깊이가 AI 개요의 가로채기에 저항하기 때문이라고 주장해 왔습니다. 디렉토리 페이지는 탐색형 표면(navigational surface)이며, 기사들은 도메인을 위한 E-E-A-T 신호를 구축하는 편집 레이어(editorial layer)입니다. 지난 5월의 E-E-A-T 투명성 작업과 이번 주에 구현한 quality_contract v2 필드 — original_evidence, verified_at, search_intent — 는 모두 쿼리가 가로채기 당하기 전에 Google이 1인칭 경험(first-person experience)을 읽을 수 있도록 만들기 위한 시도입니다.

메타 베팅(meta-bet) 구조: 설령 AI 개요(AI overviews)가 내 기사를 타겟팅하는 쿼리의 60%를 가로채더라도, 남은 40%는 12개월 동안 Bluesky의 48시간 윈도우(window)보다 여전히 더 빠릅니다. 만약 가로채기 비율이 90% 이상에 도달한다면 계산은 반대가 됩니다. 저는 "내 특정 코드베이스에서 X를 어떻게 구축했는가"와 같은 쿼리에 대해 90% 이상의 가로채기가 발생할 가능성은 낮다고 생각합니다. 이러한 쿼리들은 1인칭 증거(first-person evidence) 없이는 가로채기가 어렵기 때문입니다. 하지만 가능성을 완전히 배제하지는 않습니다.

측정 프레임워크 (Measurement framework)

6개월 차(2026년 10월)와 12개월 차(2027년 4월)에 확인할 사항:

6개월 차 데이터는 인덱싱(indexing)이 제대로 추적되고 있는지를 알려줄 것입니다. 138개의 기사가 게시되고, 80% 이상이 인덱싱되며, 10월까지 측정 가능한 GSC 노출(impressions)이 나타난다면, 이는 베팅이 궤도에 올랐음을 보여주는 선행 지표(leading indicator)가 됩니다.

6개월 차 데이터를 확인한 후에도 목표를 수정하지 않을 것입니다. 12개월 종료 제약 조건은 정직한 회계(honest accounting)를 강제합니다 — 지표는 매각 결정(sale decision)을 향해 나아가고 있기 때문에 실제적이어야 합니다. 만약 12개월 차에 Bluesky 추천이 유기적 세션의 5배로 나타난다면, 그때는 직접 게시할 것입니다.

내 생각을 바꿀 변수

다음 세 가지 시나리오가 발생하면 저는 소셜 우선(social-first) 배포 방식으로 전환할 것입니다.

Dev.to가 Google과의 관계를 변경하는 경우. 만약 Dev.to가 교차 게시된 콘텐츠에 noindex를 적용하거나, Google이 해당 도메인을 처리하는 방식을 업데이트한다면, 인덱싱된 발자국(indexed footprint)이 붕괴될 것입니다. 저는 초기 신호로서 GSC 내 Dev.to 기사 노출(impressions)의 상당한 감소를 주시할 것입니다.

Bluesky가 인덱싱되는 검색 표면(search surface)이 되는 경우. AT 프로토콜(AT Protocol)은 공개되어 있습니다. 만약 제3자 인덱서(indexers)나 Google 자체가 Bluesky 포스트를 의미 있게 인덱싱하기 시작한다면, 포스트와 기사 사이의 구조적 비대칭성이 해소될 것입니다. Bluesky 포스트도 기사와 동일한 방식으로 검색 커버리지(search coverage)를 축적하기 시작할 것입니다.

나의 쿼리 가로채기 가설(query interception hypothesis)은 틀렸습니다. 제가 6월에 했던 문장 고유성(sentence-uniqueness) 베팅과 5월의 AI 개요(AI overviews) 베팅은 모두 1인칭 정보성 콘텐츠가 가로채기에 저항할 것이라고 가정했습니다. 만약 Search Console에서 내 기사를 타겟팅하는 쿼리의 80% 이상을 AI 개요가 캡처한다면, 기사 채널은 롱테일(long-tail)의 이점을 잃게 되며 Bluesky의 즉각적인 반응성(warmth)이 더 지속 가능한 것으로 보이기 시작할 것입니다.

이 중 어느 것도 임박해 보이지는 않습니다. 그것이 제가 베팅을 하는 이유입니다.

FAQ

Q: 본인의 도메인이 아닌 Dev.to에 SEO 이득을 주는 것 아닌가요?

네, 의도적인 것입니다. 저의 디렉토리 사이트들은 권위(authority)가 없는 새로운 도메인입니다. 제 도메인에 올라온 새 기사는 몇 주 동안 Google에 노출되지 않지만, Dev.to에 올라온 동일한 기사는 몇 시간 만에 인덱싱(indexing)됩니다. 이는 실질적인 트레이드오프(trade-off)입니다. 12개월 차가 되면 제가 구축하고 있는 검색 가치의 일부가 Dev.to의 도메인에 머물게 될 것입니다. 하지만 12개월 실험의 4개월 차 시점에서, 제 도메인의 트래픽이 0인 것과 Dev.to에 약간의 트래픽이라도 있는 것은 비교할 가치도 없는 문제입니다.

Q: Dev.to와 Hashnode에 교차 게시(cross-posting)를 하면 중복 콘텐츠(duplicate content) 문제가 발생하지 않나요?

아니요. Hashnode의 originalArticleURL 필드가 Dev.to를 캐노니컬(canonical)로 설정합니다. Google은 이를 하나의 문서로 인식합니다. Hashnode의 복사본은 두 번째 인덱싱 기회를 제공하는 것이 아니라, 다른 오디언스 세그먼트(audience segment)에게 서비스를 제공하는 역할을 합니다.

Q: 분석 도구(analytics)에서 기사 기반 유기적 트래픽(organic)과 Bluesky 추천 클릭(referral clicks)을 어떻게 구분할 예정인가요?

추천 소스(Referral source)를 통해 구분합니다. Bluesky 클릭은 bsky.app 추천으로 나타납니다. Google 유기적 트래픽은 UTM이 제거된 분석 도구에서 google / organic으로 나타납니다. 경계 영역에서는 기여도(attribution)가 노이즈가 섞일 수 있습니다. 예를 들어 누군가 Google을 통해 Dev.to에서 기사를 발견하고 동시에 Bluesky에서 저를 팔로우할 수도 있습니다. 하지만 전체적인 채널 분할(channel split)은 이 베팅을 평가하기에 충분히 읽기 쉬운 수준일 것입니다.

Q: 만약 3배 목표치가 임의적인 것이고 두 채널 모두 성과가 낮다면 어떻게 되나요?

3배 목표치는 중요한 방향성 측면에서 반증 가능하도록(falsifiable) 설정된 것입니다. 만약 두 채널 모두 성과가 저조하다면, 그것은 다른 진단이 필요하다는 뜻입니다. 즉, 사이트의 키워드 타겟팅(keyword targeting)이나 인덱싱(indexing)에 문제가 있다는 의미입니다. 비율에 관한 질문은 채널 간에 배분할 의미 있는 트래픽이 존재할 때만 유의미합니다. 6개월 차가 되면 제가 그런 시나리오에 처해 있는지 알 수 있을 것입니다.

관련 글: 왜 나는 Bluesky를 나의 최상위 추천 채널로 베팅하는가 · 왜 3개의 수직적 디렉토리가 하나의 수평적 AI 애그리게이터(aggregator)보다 나은가

이 글은 3개의 AI 큐레이션 디렉토리 사이트를 운영하는 6개월간의 지속적인 실험의 일부입니다. 여기에 언급된 기술적 주장들은 실제이며, 이 기사는 AI의 도움을 받아 작성되었습니다.