무인 블로그의 현재 위치를 3곳에서 측정하기: 대장, 공개 로그, 참여도 실적

본 기사는 시리즈 「Claude Code로 기술 블로그를 무인 운영하는 — 무료 장부터 읽는 메커니즘 전체 개요」의 제 3회(총 6회)입니다. Claude Code의 스케줄 실행만으로 기술 블로그(Qiita 중심, Zenn 시험 투고, X 공지, 이미지 생성)가 사람의 손 없이 계속 돌아가는 시스템을, 운영하고 있는 리포지토리의 실측 로그와 커맨드 결과로 설명하는 연재물입니다. Zenn 원서 『Claude Code로 기술 블로그를 무인 운영하기』의 무료 장(제 1~3장, 제 18장, 제 20장)을 기반으로 하며, 각 회차는 책의 해당 장으로 돌아갈 수 있는 연결 고리를 가지고 있습니다. 게재하는 수치와 실행 결과는 각 회차 집필 시점에 다시 측정합니다.

전체 메커니즘을 자신의 리포지토리에 재구성하고 싶은 분들을 위해: 무료 장의 다음 내용(기사 형식, 품질 게이트, Qiita/Zenn/X 공개 설계, 무인 실행, 측정)을 총 20장으로 된 매뉴얼로 작성한 Zenn Book을 공개했습니다 (유료 500엔・체험판 있음).

시리즈 전체 목차

• 제 1회 하루 4 스ล็อต의 스케줄 실행으로, 기술 블로그가 사람 손 없이 계속 나오는 메커니즘 전체 개요
• 제 2회 거버넌스의 토대는 공개 베이스를 설정하는 것만으로 충분하다. 그 위에 블로그 레이어를 추가할 경계 긋기
• 제 3회 무인 블로그의 현재 위치를 3곳에서 측정하기: 대장, 공개 로그, 참여도 실적 (본 기사) - 제 4회 Zenn이 배포 성공했는데 공개되지 않는다・Qiita의 429: 무인 운영으로 부딪힌 공개 관련 증상 (공개 예정)
• 제 5회 X의 403・승인 대기 등으로 스ล็อต가 공염병 되다・git push가 403: 무인 운영 확산과 운영 증상 (공개 예정)
• 제 6회 책을 Claude Code에 읽히고 자신의 리포지토리에 재현하기: 읽는 경로・검증된 SHA・수정 사항 추적 (공개 예정)

제 1회에서는 하루 4회의 기동으로 글이 작성되어 외부로 나가는 흐름을, 제 2회에서는 그 흐름을 지탱하는 토대와 블로그 레이어의 경계를 다루었습니다. 둘 다 메커니즘 설명입니다. 메커니즘 설명을 아무리 쌓아도, 「그래서 정말로 기사가 계속 나오고 있는가」「너무 많이 나와서 막히지는 않았는가」「나온 기사는 읽히고 있는가」에는 답할 수 없습니다.

이번 회차에서 던질 질문은, 무인으로 운영하는 기술 블로그의 현재 위치를 무엇으로, 어떻게 측정해야 확실하게 알 수 있는가 입니다. 본 리포지토리에서는 대장(台帳)・공개 로그・반응 보고서의 3곳에서 측정하고 있습니다. 좋은 숫자만 나열하면 현재 위치를 오판할 수 있으므로, 상한에 도달해 멈춘 횟수와 목표에 미치지 못하는 KPI도 그대로 게재합니다.

대상 독자는 무인 운영에 관심은 있지만 「정말로 성과가 나올지」를 숫자로 확인하고 싶은 사람과, 자신의 블로그의 현재 위치를 같은 절차로 측정하고 싶은 사람입니다.

게재된 커맨드의 출력은 본 리포지토리에서 2026-10-01 16:07~16:10 JST에 수집한 것입니다. 모두 파일을 읽어서 세는 것만 하는 커맨드라, 투고나 과금을 동반하는 처리는 실행하지 않았습니다. 반응 보고서만은 주간 자동 생성물이므로, 측정일이 아닌 생성 일시(2026-09-28 09:27 JST)를 기재합니다.

3곳은 글을 쓰는 주체도, 업데이트하는 타이밍도 다릅니다.

저장소(台帳)는 글을 작성한 시점에 행이 추가되고, 공개될 때 상태가 변경됩니다. 공개 로그(公開ログ)는 슬롯이 작동할 때마다 1행씩 기록됩니다. 반응 보고서(反応レポート)는 Qiita API에서 주간 단위로 가져온 집계입니다. 측정 시점과 범위가 다르기 때문에 세 곳의 수치가 정확히 일치하지 않습니다. 불일치 자체를 이상으로 간주하기보다는, 어느 지점에서 어떤 범위를 측정한 값인지 명시해 두면 그 차이가 비교 자료가 됩니다.

저장소의 맨 앞에는 본수 집계가 YAML 블록 형태로 위치합니다.

$ sed -n '2,7p' docs/article-registry.md
registry:
total: 656
...

저장소에 등록된 글은 총 656개이며, 이 중 560개가 공개되었고 96개가 공개 대기 상태의 재고입니다. 초안(ドラフト) 상태의 행은 없습니다. last_updated는 촬영일과 같은 2026-10-01로, 당일에 업데이트된 저장소를 읽었습니다.

같은 날짜에 public/ (Qiita 형식으로 변환한 글이 위치하는 곳)을 세어보면, 연속 번호가 시작되는 .md 파일은 672개이며, frontmatter의 id가 null인 파일(아직 Qiita에 게시하지 않은 것)이 120개 있었습니다. 저장소의 656개와 public/의 672개는 일치하지 않습니다. 저장소는 글의 행을 세고, public/은 파일을 세고 있기 때문에, 측정 방식이 다른 두 값으로 병기합니다. 어느 쪽이 정확한지 여기서 단정할 근거는 없습니다.

재고 수량 역시 저장소의 96개와 public/의 미게시 120개로 일치하지 않습니다. 운영에 영향을 주는 것은 이 재고 측면입니다. Qiita의 신규 게시물은 하루 2건으로 제한하고 있기 때문에, 재고가 100개 전후라면 새로운 글쓰기를 중단해도 1개월 반에서 2개월 정도는 공개가 지속될 것으로 계산됩니다.

공개 로그는 공개 처리가 실행될 때마다 1행 1 이벤트의 JSON을 추가하는 파일입니다. 측정 시점에는 3,181행이 있었으며, 시작은 2026-06-17 02:55 JST, 끝은 2026-10-01 16:05 JST 기록이었습니다. 로그는 공백 없이 한 줄 JSON으로 작성되어 있어, grep -c로 이벤트 건수를 셀 수 있습니다.

$ grep -c "event":"post_success"" logs/qiita-post-log.jsonl
227
$ grep -c 'daily_cap_reached' logs/qiita-post-log.jsonl
...

신규 게시 성공 건수는 227건입니다. 월별로 나누면 다음과 같습니다.

공개 로그에는 성공 기록뿐만 아니라, 상한에 도달하여 공개를 미룬 기록도 남아있습니다. 무인 운영에서는 나오지 않는 것만큼이나 너무 많이 나오는 것이 문제입니다. 너무 많이 내면 플랫폼 측의 제한을 받게 되어 취소할 수 없는 형태로 계정 평가가 하락할 우려가 있기 때문입니다. 멈춘 횟수는 그 '너무 많이 내지 않도록' 기계적으로 관리되고 있다는 기록입니다.

일일 상한과 주간 창의 두 가지는, 저희가 API를 호출하기 전에 멈춘 기록입니다. 일일 상한 값은 도중에 바뀌어, 2026-09-15에 하루 3건에서 2건으로 낮춰졌습니다. 같은 날짜에 포함된 것이, 직전 168시간 동안 신규 게시물을 14건으로 제한하는 주간 창 게이트입니다.

429는 Qiita 측에서 거부된 기록이라 성격이 다릅니다. 최종 건수는 2026-09-14 16:07 JST이며, 주간 창(weekly window) 게이트를 넣은 다음 날 이후로는 1건도 나오지 않았습니다. 대신 주간 창이 가득 차서 미룬 기록이 3건 기록되었습니다. Qiita에 거부되어 멈추던 운영 방식이, 거부되기 전에 스스로 멈추는 운영 방식으로 바뀐 것이 로그 상에서는 이 교체로 보입니다. 게이트의 효과라고 단정하기에는 기간이 짧지만, 적어도 2주가 넘게 429 에러가 나오지 않았다는 사실은 세어볼 수 있습니다.

429 건수만은 위 grep -c 와 같은 방법으로는 셀 수 없었습니다. 수집 계획 단계에서는 다음 명령어로 셀 생각이었습니다.

$ grep -c ""httpStatus":429' logs/qiita-post-log.jsonl
0

0건이 반환되지만, 429가 없었던 것은 아닙니다. 이 로그에서는 HTTP 상태 코드가 http 객체의 status에 있고, httpStatus라는 키는 존재하지 않기 때문입니다. 그래서 각 행을 JSON으로 파이썬(Python)으로 읽어, errorClass가 QiitaRateLimitError이고 http.status가 429인 행을 다시 세어본 것이 표의 91건입니다.

grep -c는 일치하지 않으면 조용히 0을 반환하기 때문에, 키 이름에 대한 추측은 '0건이었다'라는 잘못된 사실로 남게 됩니다. 자신의 블로그에서 같은 일을 한다면, 0이 반환되었을 때 로그의 한 행을 눈으로 보고 키의 위치를 확인한 후에 숫자를 채택해야 합니다.

참고로, 동일 로그의 fail 이벤트는 1,844건이 있었으며, 세부 내역은 QiitaForbiddenError가 1,705건(그중 기존 기사 업데이트인 PATCH가 1,274건), QiitaRateLimitError가 91건, QiitaUnknownError가 48건이었습니다. 상한에 의한 정지와는 별개의 실패이므로, 이번의 '멈춘 횟수'에는 포함하지 않았습니다.

반응은 npm run metrics 가 주간으로 생성하는 docs/engagement-report.md 에서 읽습니다. 여기서 사용하는 것은 2026-09-28 09:27 JST에 생성된 버전이며, 자동 집필을 시작한 2026-02-20 이후부터 Qiita에 작성한 기사(보고서 내 명칭은 '자동 집필 era')를 집계한 것입니다.

기사 수 546본은 대장(ledger)의 공개된 560본과 일치하지 않습니다. 반응 보고서는 Qiita API로 얻을 수 있는 기사를 작성일자로 한정하여 만든 값이므로, 대장과는 범위가 다릅니다. 보고서 자체에도 생성 시점의 public/ 의 연속 파일 수가 657본으로 기록되어 있어, 같은 리포지토리 내에서도 세는 장소마다 값이 달라질 수 있다는 것을 알 수 있습니다.

보고서의 월별 트렌드에는 공개 후 14일 미만이거나 PV가 100 미만인 기사를 제외한 '성숙 기사' 한정 값도 있습니다. 공개 직후의 기사를 섞으면 관측 기간이 짧다는 이유로 숫자가 나쁘게 보일 수 있기 때문입니다.

| 공개월 | 성숙 기사 수 | PV 평균 (성숙) | 좋아요율 (성숙) | 스톡률 (성숙) | 제로 좋아요율 (생값) |
|---|---|
| 2026-03 | 152 | 4,527.58 | 0.05% | 0.03% | 42% |
| ... |

여기서 알 수 있는 것은 '새로운 글일수록 읽히는 양이 적다'는 사실까지입니다. 오래된 글일수록 PV(페이지 뷰)를 쌓는 시간이 길다는 점은 성숙기 글(mature article) 분류에서 일부 흡수하고 있지만, 주제 선정 방식, Qiita 측의 노출 메커니즘, 공개 본수 변화 중 무엇이 얼마나 효과가 있었는지 이 표만으로는 구분할 수 없습니다. 원인을 정하지 않고, 노출량(읽히는 양)과 반응률(읽힌 글 대비 반응)을 나누어 계속 추적하기로 했습니다.

KPI의 정의와 목표는 docs/project-mission.md에 있습니다. 다만, 표에 실린 측정값은 2026-07-21 시점의 것이며, 위에서 읽으신 반응 리포트(2026-09-28 생성)와 날짜가 다릅니다. 혼동을 막기 위해 출처별로 나누어 배열합니다.

K-1은 분모가 성숙기 글에 한정되어 있으므로, 리포트의 전체 기사 평균 0.95와는 엄밀히 비교할 수 없습니다. 그럼에도 불구하고 두 값 모두 목표치인 2.0의 절반 전후에 머물고 있습니다. K-2 역시 생값과 성숙기 글 한정에 정의가 통일되지 않았다고 하더라도, 월별로 60%를 밑돈 달은 2026-07 이후 없습니다. K-3는 자동 집필 era 전체의 누적 PV 평균이므로, 오래된 글이 PV를 쌓을수록 높아지기 쉬운 지표입니다. 월별 표에서 본 새로운 기사의 PV 하락은 이 평균에는 나타나기 어렵다는 점에 주의가 필요합니다.

이 차이를 무엇으로 줄여나가려고 하는지는 책 안에서 장을 나누어 다루고 있습니다. 무엇을 쓸지 실적으로 결정하는 시스템은 제6장, 교차 요약 및 내부 링크로 기존 기사의 재방문을 늘리는 이야기는 제5장과 제6장, KPI를 주간 단위로 검토하며 손을 대는 측정 및 개선 루프는 제17장에 있습니다. 이 회에서는 그러한 시스템들이 어떤 숫자를 움직이기 위해 존재하는지 그 출발점까지만 보여드릴 수 있습니다.

비용은 Stop Hook이 각 세션의 트랜스크립트에서 기록하고 있으며, npm run cost:report (내용물은 python3 tools/calc_daily_cost.py --report)로 취합할 수 있습니다.

$ npm run cost:report
📊 비용 실측 리포트 (2026-08-30 ~ 2026-10-01 JST・30일 / 160 세션)
총액: $8,158.94(≒ ¥1,223,841)
...

읽어야 할 것은 세션 종류의 두 줄입니다. routine:blog-dispatch가 무인 슬롯의 합계로 30일 동안 $2,907.75, 하루당 약 $97이었습니다. interactive는 수동으로 열어본 세션(하네스 개발・개수・조사)이며, 이 부분이 총액의 64.4%를 차지합니다. 완성된 시스템을 가동하는 것만으로는 전자의 줄이 소요됩니다. 금액은 토큰 수에 공개 단가(tools/cost_dimensions.py의 PRICING)를 곱한 환산값이며, 엔화는 1달러당 150엔이라는 고정 환율이므로 청구액 그 자체는 아닙니다. 또한, 이 리포트가 취합하는 것은 Claude 모델 이용료만이고, 이미지 생성 비용은 포함되어 있지 않습니다. 이미지 생성 비용 감각은 책의 제1장에서 별도로 다루고 있습니다.

도입부의 질문으로 돌아갑니다. 무인 블로그의 현재 위치는 3곳을 나열하자 각각 다른 답을 내놓았습니다.

첫째로, 기사는 계속 나오고 있습니다. 신규 투고 성공 건수는 227건이며, 최근 8일은 거의 매일, 최대치인 2개에 딱 맞춰 채워져 있었습니다.

둘째로, 너무 많이 올리지 않는 측면도 수치화하여 지켜지고 있습니다. 이쪽에서 멈춘 기록이 일일 상한으로 42회, 주간 창(window)으로 3회가 있었으며, 429는 2026-09-14 이후로 나오지 않았습니다. 성공 건수만 보고 있었다면, 이 '멈춘 횟수'는 보이지 않은 상태였습니다.

세 번째로, 작성한 글은 읽히지만 저장되지는 않았습니다. 저장률은 0.04%이고, 스톡 효율은 목표의 절반 정도 수준이며, 새로운 글일수록 개당 PV(페이지뷰)가 작아지고 있습니다.

이것들을 나란히 놓고 보니 가장 효과적이었던 것은 세 곳의 수치가 달라질 것을 전제로 각각에 추출 명령어와 시점을 부여한 것이었습니다. 대장(台帳) 656개, public/ 폴더의 672개, 반응 리포트의 546개는 모두 거짓이 아니며 단지 세고 있는 범위가 다를 뿐입니다. 시점과 범위가 명시되어 있으면 그 차이가 '어딘가에서 글이 누락되지 않았는지' 확인할 단서가 되지만, 그렇지 않으면 단순한 모순으로 보일 수 있습니다.

만약 제 블로그에서 같은 작업을 한다면, 가장 먼저 준비해야 할 세 가지는 다음과 같습니다.

• 작성된 본문 수를 반환하는 명령어 (대장 또는 기사 디렉토리 집계)
• 발행된 본문 수와 중단 횟수를 반환하는 명령어 (공개 로그의 event 집계)
• 읽힌 양과 저장된 양을, 기사의 연령으로 필터링하여 반환하는 리포트

이 세 가지 모두 추출한 날짜/시간과 함께 기록해야 합니다. 다음에 같은 명령어를 실행했을 때 값이 변해 있다면, 그것 자체가 시스템이 계속 작동하고 있다는 증거가 됩니다.

이번 글은 Zenn의 『Claude Code로 기술 블로그를 무인 운영하기』 제2장 '전체 개요' 실적 부분과 제1장 '이 책을 읽는 방법' 비용 관련 부분을 기반으로, 모든 값을 2026-10-01 기준으로 다시 작성한 것입니다. 두 부분 모두 무료 장이며, 제2장과 제1장에서 읽을 수 있습니다. 다음 내용부터는 유료 장에 해당하며, 제6장이 무엇을 쓸지 실적으로 결정하는 시스템을 다루고, 제17장은 KPI와 비용을 순환시키는 측정 및 개선 루프를 다룹니다. 책에는 Claude Code가 읽으면 자신의 리포지토리에서 같은 시스템을 구축할 수 있도록 작성된 사양 패키지(제19장)도 포함되어 있습니다.

본 리포지토리 내 파일들 (리포지토리는 비공개이므로 경로만 표시합니다):

• docs/article-registry.md: 기사 관리 대장 (상단의 registry: 블록에서 본문 수 집계)
• public/: Qiita 형식의 기사. frontmatter의 id가 null이면 미게시됨
• logs/qiita-post-log.jsonl: Qiita 공개 구조화 로그 (1행 1이벤트 JSON)
• docs/engagement-report.md: npm run metrics가 생성하는 반응 리포트 (이번 버전은 2026-09-28 09:27 JST 기준)
• docs/project-mission.md: KPI 정의・목표・실측 (실측은 2026-07-21 시점)
• tools/calc_daily_cost.py / tools/cost_dimensions.py: npm run cost:report의 집계 및 단가표

➡️ 다음 예고: 제4회 Zenn이 배포에 성공했으나 공개되지 않음・Qiita 429: 무인 운영으로 걸린 공개 관련 증상 역추적편. Zenn의 사일런트 비공개・제목 70자 초과로 인한 연쇄 피해・Qiita 429 및 주간 창(window)・연번 4자리화 등, 공개 과정에서 실제로 겪었던 증상을 원인과 대처법으로 정리합니다.

이미 공개된 회차: (1편 - 어느 회차부터든 읽을 수 있습니다)

시스템 전체를 자신의 리포지토리로 재구축하고 싶은 분은 무료 장의 다음 내용(기사 형식・품질 게이트・Qiita/Zenn/X 공개 설계・무인 실행・측정)을 총 20장 분량의 매뉴얼로 작성한 Zenn Book (유료 500엔, 샘플 읽기 가능)을 참고해 주십시오.