Claude Code Harness KPI 대시보드: 증거, 매출, 리스크를 한 장에서 추적하기

왜 별도 산출물로 만들어야 하는가

이 글은 Claude Code로 콘텐츠 운영과 자동화를 시작한 개발자를 위한 harness KPI 대시보드를 만든다. 흔한 실패는 단순하다. PV는 늘지만 어떤 글이 PDF 등록, Gumroad 클릭, 상담 방문, 검증 증거로 이어졌는지 보이지 않는다. Claude Code 작업은 자신감 있는 답변에서 끝나면 안 된다. 다른 사람이 확인할 수 있는 산출물을 남겨야 한다. 여기서 산출물은 글마다 검증 상태, 수익 행동, 리스크 메모를 기록하는 한 줄 대시보드이다.

이 산출물을 prompt, command line, public page 사이의 계약으로 다룬다. Claude Code가 무엇을 읽었고, 무엇을 바꿨고, 어떤 command로 증명했으며, 독자를 다음에 어떤 revenue path로 보낼지 보여야 한다. 이 주제는 harness engineering, getting started, permissions와 연결된다.

운영 루프

루프는 다섯 단계다. action을 정의하고, proof를 고르고, Claude Code가 가장 작은 유용한 일을 하게 하고, output을 검증하고, 다음 revenue action을 기록한다. 여기서 proof는 코드 실행만이 아니다. PDF 시작, Gumroad 클릭, training 페이지 방문, build 증거, 미해결 리스크를 본다. 이 필드가 보이면 추측으로 글을 고치지 않는다.

1. harness 글은 검색 유입이 많지만 PDF 등록이 적다면 무료 체크리스트를 첫 예제 가까이에 둔다.

2. 입문 글은 PDF 등록이 있지만 유료 클릭이 약하면 Setup Guide가 필요한 순간을 CTA에 적는다.

3. 권한 글에서 상담 방문이 나온다면 리스크 설명을 글 끝이 아니라 중간에도 보여 준다.

복사해서 쓰는 starter

const rows = [
  { slug: "claude-code-harness-engineering", sessions: 1882, pdfStarts: 42, gumroadClicks: 9, consultationVisits: 3, riskFlags: 1 },
  { slug: "claude-code-getting-started-complete", sessions: 760, pdfStarts: 28, gumroadClicks: 6, consultationVisits: 1, riskFlags: 0 },
];

function revenueSignal(row) {
  return row.pdfStarts * 1 + row.gumroadClicks * 4 + row.consultationVisits * 9 - row.riskFlags * 3;
}

for (const row of rows) {
  console.log(row.slug, revenueSignal(row));
}

현장 예시 세 가지

예시 1. harness 글은 검색 유입이 많지만 PDF 등록이 적다면 무료 체크리스트를 첫 예제 가까이에 둔다.

예시 2. 입문 글은 PDF 등록이 있지만 유료 클릭이 약하면 Setup Guide가 필요한 순간을 CTA에 적는다.

예시 3. 권한 글에서 상담 방문이 나온다면 리스크 설명을 글 끝이 아니라 중간에도 보여 준다.

셀프 리뷰 체크

이 workflow를 습관으로 만들기 전에 release note처럼 글을 다시 본다. 첫 번째는 scope다. 독자가 언제 harness KPI 대시보드를 쓰고, 언제 더 작은 checklist로 충분한지 알아야 한다. 두 번째는 proof다. 모든 권장 사항은 command, URL, diff, metric 중 하나로 이어져야 한다. 세 번째는 routing이다. free PDF, Gumroad guide, consultation path가 서로 경쟁하지 말고 다른 긴급도에 답해야 한다.

작은 owner rule도 둔다. artifact owner, verification owner, next CTA experiment owner를 구분한다. solo workflow라면 같은 사람이어도 된다. 하지만 note에는 역할 이름을 남긴다. 이렇게 하면 Claude Code가 publishing, measuring, selling을 하나의 흐린 task로 다루기 어렵다. 다음 run도 어디서 이어갈지 더 쉽게 판단한다.

가장 실용적인 질문은 이것이다. 내일 아침 이 글을 더 쉽게 검증하게 만드는 것은 무엇인가? 답이 screenshot이면 저장한다. 답이 더 강한 prompt이면 prompt pack에 넣는다. 답이 더 명확한 boundary이면 setup note에 넣는다. 글마다 검증 상태, 수익 행동, 리스크 메모를 기록하는 한 줄 대시보드는 다음 session에서 살아남을 때만 유용하다.

실패 사례

첫 번째 실패는 PV만 점수로 삼는 것이다. 두 번째는 proof command 없이 변경을 승인하는 것이다. 세 번째는 free PDF나 consultation이 더 맞는 독자에게도 같은 paid product만 보내는 것이다. CTA를 바꾸기 전에 routing rule을 쓰면 이 문제를 줄일 수 있다.

수익 경로

독자는 병목으로 나눈다. command fluency가 필요하면 free PDF 또는 free Gumroad cheatsheet로 보낸다. 같은 일을 매주 반복하면 50 Prompt Templates나 Setup Guide가 맞다. rollout, risk, revenue design이 문제라면 consultation이다. 이 글에서는 Prompt Templates는 검토 프롬프트 표준화에, Setup Guide는 harness 규칙 고정에 맞다.

검증 지표

게시 후에는 HTTP 200만 보지 않는다. h1, canonical, hero image, 본문 첫 부분, CTA link, mobile layout, language를 확인한다. 그리고 PDF 시작, Gumroad 클릭, training 페이지 방문, build 증거, 미해결 리스크를 본다. 지표가 움직이지 않으면 전체 rewrite보다 첫 번째 구체 예시 근처의 CTA를 먼저 고친다.