3개월이 지난 지금, 나는 Bluesky에 충분한 인프라를 투입했기에 이를 단순한 헤징(hedged) 실험이 아닌 실제 베팅(bet)이라고 부르는 것이 정직하다고 느낀다.

오늘 기준으로, 나의 자동화 시스템은 하루에 150개의 Bluesky 계정을 팔로우하고, 14일이 지난 후 맞팔로우가 아닌 계정을 제거하는 야간 언팔로우 프로세스를 실행하며, 발행되는 모든 기사를 ["devto", "hashnode", "bluesky"]로 라우팅한다. 각 포스트에는 Playwright 파이프라인에 의해 렌더링된 시각적 요약 카드가 포함된다. 나는 여기에 실제 GitHub Actions 분(minutes)과 실제 개발 시간을 소비하고 있다. 따라서 내가 실제로 주장하는 바가 무엇인지, 그리고 무엇이 내 주장이 틀렸음을 증명할 것인지에 대해 정확하게 말할 가치가 있다.

주장

12개월 차인 2027년 4월까지, Bluesky는 나의 세 가지 AI 디렉토리 사이트인 Top AI Tools, Find Games Like, Open Alternative To 중 적어도 한 곳의 상위 3위 이내 유기적 추천 소스(organic referral source)가 될 것이다. 나는 그 시점에 별도의 요약 포스트를 통해 정확한 Cloudflare Analytics 추천 수치를 공개할 것이다.

더 완화된 버전이자, 내가 실현 가능성이 더 높다고 생각하는 버전은 다음과 같다: 현재 Twitter/X가 훨씬 더 큰 개발자 사용자 기반을 보유하고 있음에도 불구하고, 해당 기간 내에 Bluesky의 추천 클릭 수가 절대적인 양 측면에서 Twitter/X를 앞지를 것이다.

나는 검색 엔진과 동등한 트래픽을 주장하는 것이 아니다. 출시된 지 3개월 된 사이트의 유기적 소셜 추천(Organic social referrals)은 결국 SEO가 가져다줄 트래픽에 비하면 노이즈에 불과할 것이다. 이 베팅의 핵심은 Bluesky가 지금 구축해야 할 적절한 소셜 레이어(social layer)이며, 따라서 SEO가 효과를 발휘하기 시작하는 시점에 함께 복리 효과를 낼 것이라는 점이다.

구조적 근거가 실재한다고 생각하는 이유

Twitter/X로부터의 개발자 탈출은 잘 기록되어 있지만, 중요한 것은 헤드라인 수치가 아니다. 중요한 것은 이동한 사람들의 구성이다.

내가 관찰한 바에 따르면 — 누가 맞팔로우를 하는지, 내가 오픈 소스 (open-source) 대안이나 AI 도구 비교에 대해 게시물을 올릴 때 누가 반응(engage)하는지를 보면 — Bluesky는 도구를 공유하고, 링크 클릭을 실행하며, Dev.to나 Hashnode에 글을 쓰는 유형의 개발자들을 불균형적으로 많이 끌어들이고 있다. Twitter/X의 개발자 커뮤니티가 더 규모는 크지만, 그곳에는 클릭 없이 게시물만 올리는 사람들의 비율이 훨씬 높다. 내 콘텐츠는 실제로 클릭해서 들어오는 독자를 위해 설계된 니치(niche) 관심사 콘텐츠다. 해당 세그먼트는 전체 규모 대비 Bluesky에 과잉 표집(over-indexed)되어 있을 수 있다.

아직 데이터로 이 관찰을 증명할 수는 없다. 이는 행동 패턴으로부터 얻은 추론이며, 틀릴 수도 있다. 하지만 이것이 대략적으로 맞다면, 절대적인 팔로워 격차보다는 팔로워당 참여율 (engagement rate)이 더 중요하다.

시각적 형식은 세 번째 요인이다. 각 기사 게시물에는 세로형 요약 카드 (portrait-format summary card)가 포함된다. 이는 주요 통계, 파이프라인 다이어그램, 또는 비교 그리드가 담긴 1080×1350 PNG 이미지다. 이 이미지는 Bluesky에서 클릭하여 확장할 필요 없이 인라인(inline)으로 렌더링된다. Twitter/X의 카드는 피드에 섞여 들어가는 16:9 배너 형태다. 이러한 형식의 차이가 결정적인 것은 아니지만, 표준적인 링크 언펄 (link unfurl) 방식이 하지 못하는 방식으로 '게시물 보기'와 '클릭하여 이동' 사이의 마찰을 줄여준다.

마지막으로, 주제가 적합하다. 나의 세 사이트는 AI 도구, 인디 게임 대안, 그리고 오픈 소스 소프트웨어 대안을 다룬다. 이들은 탈중앙화 인프라에 대한 진정한 선호로 인해 중앙 집중식 플랫폼을 떠난 개발자들인 Bluesky의 현재 사용자층이 주로 참여하는 카테고리와 정확히 일치한다. 내가 무엇을 하기 전부터 이미 청중의 자기 선택 (self-selection)이 작동하고 있는 것이다.

가장 강력한 반론, 명확하게 기술하자면

Bluesky의 팔로워 수는 적습니다. 하루에 150명이 팔로우한다고 가정할 때, 그중 3분의 1이 맞팔로우(reciprocate)를 하고 그중 절반이 한 달 이내에 언팔로우(unfollow)를 한다면, 순수 상호 팔로워 증가량은 하루에 약 25명 정도일 것입니다. 3개월 동안 이를 계산하면 대략 2,000~3,000명의 참여형 팔로워(engaged followers)가 됩니다. 10,000명의 개발자 팔로워를 보유한 Twitter/X 계정이 링크 하나를 게시했을 때 얻는 절대적인 클릭 수는 제가 Bluesky에서 한 달 동안 얻을 클릭 수보다 많을 것입니다.

발견의 격차(discovery gap)가 이 문제를 심화시킵니다. Bluesky에는 팔로워가 아닌 사람들에게 새로운 계정을 노출해 주는 효과적인 트렌딩 페이지(trending page)나 키워드 기반의 콘텐츠 발견(content discovery) 기능이 없습니다. 누군가 제 글을 리포스트(repost)하지 않는 한, 제 기사는 제 팔로우 그래프(follow graph)를 넘어 도달하지 못할 것입니다. Twitter/X의 알고리즘은 투박하고 종종 짜증을 유발하기도 하지만, 현재의 Bluesky가 하지 못하는 방식으로 팔로우 그래프 전반에 걸쳐 콘텐츠를 증폭(amplify)시킵니다.

기초적인 문제도 있습니다. 출시 3개월 후, 저는 어떤 소셜 채널로부터도 유의미한 추천 트래픽(referral traffic)을 얻지 못하고 있습니다. Twitter/X로부터는 0, Bluesky로부터는 사실상 0입니다. 제 콘텐츠가 유기적인 공유(organic sharing)가 일어나는지조차 아직 알 수 없습니다. Bluesky에 거는 베팅은 콘텐츠가 적절한 사람들에게 도달하기만 하면 공유될 것이라는 전제를 깔고 있습니다. 하지만 그것은 보장된 것이 아닙니다.

제가 1개월 차에 작성했던 교차 채널 배포 베팅 (cross-channel distribution bet)에서는 소셜 트래픽이 6개월 차 혹은 그 이후까지는 무의미할 것이라고 인정했습니다. 그 관점은 변하지 않았습니다. 지금 Bluesky에 투자하는 이유는 12개월 차가 되었을 때, 이 계정이 제로(zero)에서 시작하는 대신 복리로 쌓이는 팔로워 관계를 보유하게 될 것이기 때문입니다.

자동화가 실제로 하는 일

팔로우 성장 스크립트는 키워드 중첩(keyword overlap)을 통해 하루에 150개의 계정을 선정하고, AT 프로토콜 (AT Protocol) API를 통해 이들을 팔로우합니다. 스크립트는 모든 팔로우 기록을 중복 제거 저장소 (dedup store) 역할을 하는 영구적인 JSONL 원장 (ledger)에 기록합니다. 원장에 나타난 계정은 언팔로우 (unfollow)를 한 후라도 다시 팔로우하지 않습니다. 이 스크립트는 GitHub Actions에서 정해진 UTC 시간에 실행되며, 배치(batch)마다 무작위 지연 시간 (randomized delays)을 가집니다.

언팔로우 단계는 팔로우 슬롯과 의도적인 간격을 두기 위해 JST 기준 14:37에 별도로 실행됩니다. 이 단계는 봇이 팔로우한 계정 중 14일이 지나도 맞팔로우 (follow back)를 하지 않은 계정을 하루 최대 30개까지 제거합니다. 수동 팔로우와 맞팔로우 상태인 계정은 건드리지 않습니다. 14일의 유예 기간을 두는 이유는 맞팔로우가 느린 계정을 불이익 주는 것을 방지하기 위함이며, 하루 30개의 제한을 두는 이유는 플랫폼이 탐지하는 대량 언팔로우 (mass-unfollow) 행위를 방지하기 위함입니다.

일일 게시물 대기열 (post queue)은 기사 발행 단계와 별도의 사이트 업데이트 공지사항으로 채워집니다. 각 게시물을 올리기 전, 4단계 품질 관리 (four-gate QC) 체크를 통해 표준 URL (canonical URL)이 활성화되어 있는지, 요약 카드 이미지가 정상적으로 불러와지는지, 글자 수가 제한 내에 있는지, 그리고 해당 기사가 이번 주에 이미 게시되지 않았는지를 확인합니다. 이 과정 중 어느 하나라도 실패하면 조용히 넘어가지 않습니다. 실패한 게이트(gate)는 대기열의 JSONL 에러 로그에 기록되고 해당 게시물은 건너뜁니다.

전체 시스템은 GitHub Actions 커밋을 통해 리포지토리 (repo)에 기록을 남깁니다. 모든 팔로우, 언팔로우, 게시물은 타임스탬프 및 결과와 함께 커밋됩니다. 12개월 차의 추천 (referral) 데이터가 들어오면, 이를 게시 타임라인과 정확하게 대조해 볼 수 있습니다.

내가 하지 않으려는 비교

나는 의도적으로 이것을 "Bluesky 대 Dev.to" 또는 "소셜 대 검색"의 구도로 설정하지 않습니다. 그것들은 서로 다른 시간 지평 (timescales)을 가진 서로 다른 베팅입니다.

Dev.to와 Hashnode는 표준 SEO 가중치 (canonical SEO weight)를 가집니다. 기사 발행 파이프라인(pipeline)은 이들을 기본(primary)으로 취급하며, Bluesky는 하류(downstream) 배포 단계입니다. 기사는 먼저 Dev.to에 게시되고, Hashnode 교차 게시물은 Dev.to의 표준 URL (canonical URL)을 따르며, Bluesky 게시물은 Dev.to로 다시 링크를 겁니다. 이 체인은 Bluesky가 Dev.to 기사로 트래픽을 유도하고, 해당 기사가 인덱싱(indexing)되어, 결과적으로 디렉토리 사이트들로 다시 링크가 연결되도록 설계되었습니다.

또한 저는 Bluesky를 유료 획득 (paid acquisition)과 비교하고 있는 것도 아닙니다. 프로젝트 전체를 위한 저의 월 25달러 예산은 호스팅, Turso 데이터베이스, 그리고 콘텐츠 생성을 위한 Claude Haiku API 호출 비용을 포함합니다. 유료 소셜 광고는 범위에 포함되지 않습니다. 이 베팅은 오직 자동화와 콘텐츠 품질만으로 어떤 일이 일어나는지에 관한 것입니다.

간접적인 수익이 사실 제가 가장 궁금해하는 부분입니다. 기사를 읽는 Bluesky 팔로워들은 댓글을 다는 Dev.to 팔로워가 됩니다. Dev.to의 댓글 활동은 저자 페이지의 권위 (authority)에 기여하며, 이는 디렉토리 사이트들이 필요로 하는 링크 자산 (link equity)에 기여합니다. 문장 고유성(sentence uniqueness)에 대한 베팅과 AdSense 승인 경로 (AdSense approval path)는 실제로 확산되는 콘텐츠 품질에 달려 있습니다. 직접적인 추천(referrals)이 적게 유지되더라도 Bluesky는 그 루프(loop)의 일부입니다.

반증 가능한 타임라인 (The falsifiable timeline)

6개월 차 (2026년 10월): 첫 번째 엄격한 점검. 만약 세 사이트 전체에서 Bluesky 추천이 월 10건 미만이고 상승 추세가 없다면, 팔로우 한도(follow cap)를 다시 줄이고 CI 예산을 내부 링크 개선 (internal link improvements)과 ETL 품질로 재배정할 것입니다. 베팅이 실패했다고 선언하는 것이 아니라, 투자를 수정하는 것입니다.

9개월 차 (2027년 1월): 이 시점까지 Bluesky가 최소한 한 곳의 사이트에서 주요 소셜 유입원 (social referral source)이 되지 못한다면, 이 베팅은 아마 틀린 것일 겁니다. 진행 도중에 전략을 바꾸지는 않겠지만, 현재의 궤적을 반영하여 이 포스트를 업데이트하겠습니다.

12개월 차 (2027년 4월): 12개월 차 요약 포스트에서 최종 판결을 내립니다. Bluesky가 세 곳의 사이트 중 어느 곳에서라도 상위 3위 이내의 유기적 유입원 (organic sources)에 포함된다면 = 베팅 성공. 어떤 사이트에서도 상위 3위 안에 들지 못한다면 = 베팅 실패. 어떤 결과가 나오든 실제 수치와 함께 명시하겠습니다.

베팅을 조기에 철회하게 만드는 요인: AT Protocol 생태계가 분열되거나, Bluesky가 현재의 자동화 (automation)를 불가능하게 만드는 API 속도 제한 (rate limits)을 도입하거나, 개발자 계정들 사이에서 Twitter/X로의 명확한 대규모 회귀 현상이 나타난다면 — 이 중 어느 것이라도 발생한다면 저는 베팅을 조기에 종료할 것입니다. 구조적 논거는 Bluesky가 현재의 궤적을 유지한다는 전제하에 성립합니다. 이는 보장된 것이 아닙니다.

내가 틀렸기를 바라는 부분

내가 틀렸기를 가장 흥미롭게 생각하는 시나리오는 다음과 같습니다: 어쩌면 이 베팅은 전혀 "Bluesky 대 Twitter/X"의 문제가 아닐 수도 있으며, 진짜 유입 채널은 내가 무시하고 있는 다른 무언가일 수도 있습니다. Dev.to 자체의 추천 알고리즘 (recommendation algorithm)? Hashnode의 디스커버리 페이지 (discovery pages)? Google Search Console 데이터는 모든 시나리오에서 유기적 검색 (organic search)이 소셜보다 더 빠르게 작동하기 시작함을 보여줄 수도 있으며, 이는 성장 스토리에서 Bluesky에 대한 투자를 무의미하게 만들 수도 있습니다.

내가 이를 기록해 둔 이유는 베팅을 명시적으로 함으로써, 12개월 차의 데이터가 모호한 주장이 아닌 실제 주장을 평가하게 만들기 위해서입니다. 팔로우 성장 (follow-growth) 및 언팔로우 자동화 (unfollow automation)는 이미 실행 중입니다. 포스트 대기열 (post queue)도 이미 채워지고 있습니다. 매몰 비용 (sunk cost)이 충분히 작기 때문에, 3개월 차에 좋아 보이는 방향으로 조기에 최적화하기보다는 실험을 끝까지 완료하는 것이 합리적입니다.

FAQ

왜 Reddit이 아니라 Bluesky인가요?
Reddit에는 활발한 서브레딧(r/singularity, r/LocalLLaMA, r/programming)들이 있으며, 이들은 제가 Bluesky에서 얻을 수 있는 것보다 게시물당 더 많은 유기적 도달 범위 (organic reach)를 가지고 있습니다. 제가 Reddit을 피해온 이유는 Reddit의 API 상황과 운영 (moderation) 마찰로 인해 자동화 또는 반자동화된 게시가 계정 건강에 위험을 초래할 수 있기 때문입니다. 1인 개발자로서 대규모의 수동 게시를 유지하는 것은 지속 가능하지 않습니다. Bluesky의 API는 설계 단계부터 개방적입니다. 만약 대역폭 (bandwidth)이 제약 사항이 아니었다면, 저는 두 곳 모두에서 활동했을 것입니다.

언팔로우 패스 (unfollow pass)가 어떻게 Bluesky의 서비스 약관 위반을 피할 수 있나요?
구현 방식은 팔로우를 수행하고, 14일을 기다린 다음, 상호 팔로우가 아닌 계정을 언팔로우합니다. 하루 30개 제한, 14일 대기, 그리고 배치 (batch)당 무작위 지연 시간은 인간이 신뢰할 수 있는 팔로우 동작 범위 내에 충분히 머물도록 설계되었습니다. Bluesky의 개발자 문서 (developer documentation)는 이 패턴을 제한하지 않으며, AT 프로토콜 (AT Protocol)의 설계는 제3자 클라이언트 (third-party clients)를 명시적으로 지원합니다. 플랫폼의 입장이 바뀌면 이 내용을 업데이트하겠습니다.

만약 콘텐츠가 공유될 만한 가치가 없다면 어떻게 되나요?
그것이 이 모든 베팅 뒤에 숨겨진 진짜 리스크입니다. 3개월 동안 게시물을 올렸지만, 제 콘텐츠가 유기적으로 퍼지는지에 대해서는 본질적으로 아무런 신호 (signal)를 얻지 못했습니다. 팔로워 수가 너무 적어서 "발견되지 못한 좋은 콘텐츠"와 "발견되었을 때 공감을 얻지 못하는 콘텐츠"를 구분할 수 없습니다. 6개월 차가 되면 첫 번째 실제 신호를 얻게 될 것입니다. 만약 적절한 팔로워 수에도 불구하고 그때까지 유기적인 리포스트 (repost)가 나타나지 않는다면, 콘텐츠 적합성 (content-fit) 가정이 틀린 것이며 Bluesky에 대한 질문은 부차적인 문제가 될 것입니다.

현재 팔로워 수는 얼마인가요?
저는 팔로우 원장 (follow ledger, 봇이 팔로우한 계정들)은 추적하지만, 별도의 API 호출이 필요한 순 상호 팔로워 수 (net mutual follower count)는 추적하지 않습니다. 6개월 차 체크포인트에서 두 수치 모두를 공개하겠습니다.