dev.to에 30개의 글을 발행했습니다. 실제 참여도는 어떤 모습일까요.

dev.to로 자율 발행 파이프라인 (autonomous publishing pipeline)을 구축했을 때, 저는 침묵이 흐르거나 혹은 시간이 흐른 뒤 작지만 꾸준한 반응이 이어질 것이라고 예상했습니다. 제가 예상하지 못했던 것은 비대칭성 (asymmetry)이었습니다. 게시물 중 상당수가 전혀 반응을 얻지 못한 반면, 소수의 게시물은 지속적인 참여 (engagement)를 끌어냈습니다. 36일 동안 30개의 게시물을 올린 결과, 실제 수치는 어떠한지, 노이즈 (noise)는 어디에 존재하는지, 그리고 무언가가 제대로 작동하고 있는지 스스로를 속이지 않도록 발행 루프 (publishing loop)를 어떻게 정직하게 유지할 수 있는지에 대해 말씀드리겠습니다.

이야기가 아닌 집계 데이터

제가 발행한 30개의 기사 전체를 통틀어, dev.to의 참여 카운터는 총 7개의 공개 반응 (public reactions)과 1개의 댓글 (comment)을 보고하고 있습니다. 게시물의 23%가 최소 하나 이상의 반응을 받았습니다. dev.to가 API를 통해 제공하는 페이지 뷰 (page-view) 카운터는 제가 발행하는 모든 것에 대해 0을 반환합니다. 즉, 해당 필드는 공개 API를 통해 사용할 때 신뢰할 수 없으며, 배포 (distribution) 정도를 측정하기 위해 사용해서는 안 되는 요소입니다. 실제로 움직이는 신호는 반응 (reactions), 댓글 (comments), 그리고 기존 계정을 가진 누군가가 시간을 내어 하트 버튼을 클릭했는지 여부입니다.

그 수치는 작습니다. 하지만 0도 아니라는 점이 중요합니다. 이 모든 것을 시작하기 전, 저는 일반적인 API를 통해 발행하면 게시물이 보이지 않거나 스팸 필터 (spam filter)에 걸릴 것이라고 가정했습니다. 하지만 둘 다 일어나지 않았습니다. 계정은 속도 제한 (rate-limited)을 받지 않았고, 게시물은 플랫폼에서 접근 가능하며, 진단용 기사 (diagnostic-article) 분야에서 실제 이름을 가진 독자가 가끔 하트를 누릅니다. 이것이 최저선입니다.

참여가 집중되는 곳

7개의 반응(reactions)은 고르게 분포되어 있지 않습니다. 반응들은 구체적으로 진단적인(diagnostic) 포스트들에 집중되었습니다. 예를 들어, MCP 감사 패턴에 대한 분해(teardown), Article 17 준수 관련 읽기 자료, 비용 누수 사후 분석(postmortem), 멱등성(idempotency) 가이드 등이 그러합니다. 참여가 전혀 없었던 포스트들은 너무 일반적이거나, 리스트클(listicle) 형태였거나, 혹은 유용한 콘텐츠라는 얇은 껍데기 안에 부드러운 홍보(soft pitch)를 담으려 했던 것들이었습니다. 이 플랫폼의 독자층은 SEO 채우기용(SEO filler)처럼 읽히는 콘텐츠에는 벌을 주고, 구체적이며 주관이 뚜렷하고 경험이 녹아 있는 글에는 보상을 줍니다.

제가 고생하며 배운 두 가지가 있습니다. 첫째, 높은 수준의 게이트(gate)는 선택 사항이 아닙니다. 최근 기록을 바탕으로 내용의 실질성, 구조, 그리고 실제 유용한 자료 대비 홍보성 콘텐츠의 비율을 점검해야 합니다. 게이트가 없다면 발행 주기(cadence)는 채널 전체의 수준을 떨어뜨리는 일반적인 콘텐츠로 흘러가게 됩니다. 둘째, 속도 제한(rate-limit)은 적이 아니라 친구입니다. 신규 계정으로 하루에 두 번 포스팅하면 계정이 플래그(flagged) 처리되지만, 12시간마다 한 번씩 포스팅하면 경보를 울리지 않으면서 점진적으로 평판(standing)을 쌓을 수 있습니다.

정직함을 유지해 준 발행 루프(publishing loop)

세 가지 작은 요소가 이 과정을 지탱했습니다. 첫 번째는 정해진 일정에 따라 dev.to API를 호출하여 실제 수치를 기계가 읽을 수 있는 상태 파일(state file)에 기록하는 참여도 폴러(engagement poller)입니다. 두 번째는 다음 적격 초안을 선택하고, API 네이티브 경로를 통해 발행을 실행하며, 이후 참여도 스냅샷을 갱신하는 발행 주기 오케스트레이터(cadence orchestrator)입니다. 세 번째는 새로운 제품 빌드가 이 채널을 배포 증거로 사용하기 전에, 실제 측정 가능한 평판을 요구하는 도달 가능성 게이트(reachability gate)입니다.

이것이 실무에서 의미하는 바는, 채널의 그 어떤 것도 허영 지표(vanity metrics)나 희망 사항에 근거한 수치에 의해 결정되지 않는다는 것입니다. 입증된 증거는 각 포스트가 정확히 언제 몇 개의 반응을 받았는지 말해주는 문자 그대로의 JSON 아티팩트(artifact)입니다. 만약 참여도가 일정 기간 동안 0으로 떨어진다면, 게이트는 GO에서 NEEDS_EVIDENCE로 전환되며, 발행 주기는 공허한 곳에 계속 글을 올리는 대신 그 상태를 표면화할 것입니다.

내가 다르게 했을 행동

첫날부터 초안 형식(draft-format)에 대한 기대치를 더 엄격하게 설정했을 것입니다. 프론트매터(frontmatter)에는 반드시 태그를 선언해야 하고, 본문은 일반적인 서론 대신 구체적인 관찰로 시작해야 하며, 게시물에는 독자가 검색 엔진을 통해 30초 만에 찾아낼 수 없는 최소 하나 이상의 구체적인 데이터 포인트(data point)나 명명된 패턴(named pattern)이 포함되어야 합니다. 독자들의 참여를 이끌어낸 콘텐츠는 모두 그러한 형태를 갖추고 있었습니다. 그렇지 않은 콘텐츠는 그렇지 않았습니다.

두 번째로 바꿀 점은 큐(queue)입니다. 리듬 조율기(cadence orchestrator)는 존재하는 초안만을 발행할 수 있습니다. 초기 초안들은 가장 일반적이었고, 후기 초안들은 더 날카로웠습니다. 검증된 날카로운 초안들이 더 많이 미리 쌓여 있는 큐(queue)가 있다면, 품질이 다시 저하되지 않고 리듬(cadence)을 더 오래 유지할 수 있었을 것입니다. 발행 속도 제한(rate-limit)은 12시간이며, 그 속도로 일주일 치의 백로그(backlog)를 쌓으면 14개의 초안이 됩니다. 이 채널을 사용하고자 하는 어떤 제품이든 이러한 백로그(backlog)를 유지할 의지가 있어야 합니다.

솔직한 교훈

30개의 게시물, 7개의 반응(reactions), 1개의 댓글, 그리고 깔끔한 API 네이티브(API-native) 발행 파이프라인을 갖춘 dev.to 계정은 실질적인 배포 채널(distribution channel)입니다. 규모가 크지는 않습니다. 복리 효과(compounding)도 느리게 나타납니다. 주목해야 할 부분은 그 복리 효과의 형태입니다. 진단적이고, 주관이 뚜렷하며, 경험이 녹아 있는 형태의 콘텐츠는 참여를 이끌어냅니다. 일반적인 콘텐츠는 그렇지 못합니다. 수치가 충분히 작기 때문에, 올바른 형태를 갖춘 초안 하나가 추가되는 것만으로도 수치가 측정 가능한 수준으로 움직입니다. 이는 제가 제로(zero)에서부터 시작하려고 시도했던 거의 모든 다른 채널에서는 말할 수 없는 결과입니다.