Claude Code 검증 리시트 워크플로: build, 공개 URL, CTA, 스크린샷으로 AI 변경 증명하기

왜 검증 리시트가 필요한가

Claude Code는 글, 랜딩 페이지, 링크, 코드 예제를 빠르게 고쳐 준다. 문제는 수정 속도가 아니라, 그럴듯한 diff를 보고 너무 빨리 완료라고 믿는 순간이다. 공개 글이나 매출로 이어지는 페이지에서는 로컬 build 성공만으로 충분하지 않다. 배포된 URL이 아직 예전 버전일 수 있고, CTA가 다른 상품으로 연결될 수 있으며, 모바일 화면에서는 긴 번역 문구 때문에 버튼이 깨질 수도 있다.

이때 필요한 것이 “검증 리시트”다. 여기서 리시트는 결제 영수증이 아니라, 변경 사항에 대한 증적 메모라는 뜻이다. 어떤 파일을 바꿨는지, 왜 바꿨는지, 어떤 명령으로 확인했는지, 공개 URL에서 무엇을 봤는지, 무료 PDF와 Gumroad와 상담 링크가 살아 있는지, 스크린샷에서 레이아웃 문제가 없는지를 짧게 남긴다. 다음 날 다시 작업할 때 기억이 아니라 증거를 기준으로 이어 갈 수 있다.

이 글은 build 오류 triage, review workflow checklist, permission audit checklist와 같이 쓰면 좋다. build가 실패하면 첫 번째 글을 보고, 검토 기준이 필요하면 두 번째 글을 보고, Claude Code의 권한 범위를 줄이고 싶으면 세 번째 글을 보면 된다.

검증 리시트 템플릿

아래 템플릿을 PR 코멘트, 작업 로그, Claude Code의 마지막 확인 프롬프트에 그대로 붙여 넣을 수 있다. 핵심은 “괜찮아 보인다”가 아니라 관찰한 사실을 적는 것이다. npm.cmd run build가 성공했는지, 공개 페이지 h1이 기대한 제목인지, CTA가 실제 Gumroad 상품으로 가는지처럼 확인 가능한 문장으로 남긴다.

Verification Receipt

Scope:
- changed files:
- user-facing behavior:
- out of scope:

Diff summary:
- what changed:
- why it changed:
- what should not change:

Proof commands:
- git status --short:
- git diff --stat:
- npm.cmd run build:

Public URL checks:
- article URL:
- expected h1:
- canonical:
- no fallback page:

Revenue and CTA checks:
- free PDF CTA:
- Gumroad product link:
- consultation link:
- thanks page or next step:

Screenshot checks:
- desktop screenshot:
- mobile screenshot:
- visible CTA:
- text overflow or broken layout:

Remaining risk:
- risk 1:
- risk 2:
- risk 3:

out of scope는 생각보다 중요하다. Claude Code는 주변 파일까지 자연스럽게 고치려는 흐름을 탈 수 있다. 글 보강 작업이면 글만 고치고, 패키지 업그레이드나 네비게이션 정리는 다른 작업으로 남기는 편이 안전하다. what should not change에는 slug, canonical, 작성자, 공개일, 상품 링크, 상담 링크를 적어 둔다.

build, 공개 URL, CTA, 스크린샷 확인 예시

처음에는 로컬에서 변경 범위를 확인한다. 대상 파일만 수정됐는지 보고, diff 크기를 보고, 사이트 build를 실행한다. Windows에서는 npm.cmd를 쓰면 명령 해석 차이를 줄이기 쉽다.

git status --short
git diff --stat
cd site
npm.cmd run build

그다음은 공개 URL 확인이다. HTTP 200만으로는 부족하다. 정적 사이트나 라우터 설정에 따라 존재하지 않는 페이지도 fallback HTML을 200으로 줄 수 있다. 페이지 고유의 h1, 본문 문구, CTA 문구를 함께 확인한다.

const checks = [
  {
    url: "https://claudecode-lab.com/ko/blog/claude-code-verification-receipt-workflow/",
    mustInclude: ["Claude Code 검증 리시트", "검증 리시트 템플릿", "Gumroad"],
  },
  {
    url: "https://claudecode-lab.com/en/products/",
    mustInclude: ["Claude Code", "Products"],
  },
  {
    url: "https://claudecode-lab.com/ko/training/",
    mustInclude: ["상담"],
  },
];

for (const check of checks) {
  const res = await fetch(check.url, { redirect: "follow" });
  const html = await res.text();
  const missing = check.mustInclude.filter((text) => !html.includes(text));
  console.log(check.url, res.status, missing.length === 0 ? "ok" : `missing: ${missing.join(", ")}`);
}

마지막은 스크린샷이다. 문자열 검사는 페이지가 존재하는지 알려 주지만, 모바일에서 버튼이 밀렸는지, 코드 블록이 화면을 넘는지, 번역된 CTA가 너무 길어졌는지는 알려 주지 않는다. Playwright가 있다면 데스크톱과 모바일을 모두 남긴다.

import { chromium } from "playwright";
import { mkdir } from "node:fs/promises";

const outDir = "tmp-verification/claude-code-verification-receipt-workflow";
await mkdir(outDir, { recursive: true });

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1440, height: 1100 } });
await page.goto("https://claudecode-lab.com/ko/blog/claude-code-verification-receipt-workflow/", {
  waitUntil: "networkidle",
});
await page.screenshot({ path: `${outDir}/desktop-ko.png`, fullPage: true });

await page.setViewportSize({ width: 390, height: 1200 });
await page.screenshot({ path: `${outDir}/mobile-ko.png`, fullPage: true });

await browser.close();
console.log(`screenshots saved to ${outDir}`);

스크린샷을 볼 때는 첫 화면, 첫 코드 블록, 중간의 템플릿, 마지막 CTA를 확인한다. 특히 한국어 문장은 영어보다 길어지는 경우가 있어 버튼과 목록의 줄바꿈을 반드시 봐야 한다.

사례 1: 얇은 글을 보강할 때

얇은 글을 늘릴 때 목표는 단순한 글자 수가 아니다. 독자가 검색해서 들어왔을 때 실제로 문제를 해결할 수 있어야 한다. 이 주제라면 검증 리시트의 정의, 템플릿, build 명령, 공개 URL 확인, CTA 확인, 스크린샷 확인, 실패 사례가 있어야 실무 글이 된다.

리시트에는 추가한 섹션, 내부 링크, 외부 링크, 코드 블록 종류, 남은 위험을 적는다. 또한 상품이나 상담으로 가는 흐름이 자연스러운지도 본다. 무료 PDF로 일일 확인 습관을 만들고, Gumroad 교재로 프롬프트와 설정을 확장하고, 팀 배포나 매출 경로가 얽히면 상담으로 넘어가는 순서가 독자에게 가장 부담이 적다.

사례 2: CTA나 상품 링크를 바꿀 때

CTA 수정은 작아 보이지만 성과에 직접 영향을 준다. 버튼 문구가 바뀌었는데 링크가 예전 상품이면 독자는 헷갈린다. 무료 자료 CTA라면 제출 뒤 페이지까지 확인하고, Gumroad라면 상품명과 설명 첫 문단을 확인한다. 상담 링크라면 독자가 왜 상담이 필요한지 문맥이 이어지는지 봐야 한다.

검증 리시트에는 CTA 문구, href, 도착 페이지 제목, 다음 행동을 남긴다. “링크 있음”은 충분하지 않다. 공개 글에서는 링크의 존재보다 링크가 올바른 약속을 지키는지가 더 중요하다.

사례 3: 다국어 글을 공개할 때

다국어 글은 영어판만 확인하면 안 된다. 한국어에서 “검증 리시트”라는 표현은 설명이 함께 있어야 자연스럽다. 중국어, 스페인어, 독일어에서는 CTA 길이가 달라지고, 힌디어에서는 영어 용어를 너무 많이 섞으면 읽기 어려워진다. 각 언어의 도입부, 템플릿, 실패 사례, 교재 안내, 상담 안내를 따로 확인해야 한다.

스크린샷은 이 문제를 빨리 보여 준다. 문법은 맞아도 화면에서 어색할 수 있다. 버튼이 두 줄을 넘어가거나, 코드 블록이 옆으로 밀리거나, 마지막 CTA가 너무 판매 문구처럼 보이면 수정한다.

자주 실패하는 지점과 피하는 법

첫째, HTTP 200을 게시 성공으로 착각한다. 반드시 h1, 고유 문구, canonical, CTA 문구를 함께 확인한다.

둘째, build 성공에서 멈춘다. build는 소스가 컴파일된다는 뜻이지, 공개 사이트가 최신이라는 뜻은 아니다.

셋째, CTA 링크의 존재만 본다. 링크는 올바른 상품, 무료 PDF, 상담 페이지로 가야 한다.

넷째, 스크린샷을 남기지 않는다. 다음 날 모바일 화면을 실제로 봤는지 기억에 의존하게 된다.

다섯째, Claude Code에게 “확인해 줘”라고만 말한다. 템플릿을 주고, 명령 결과와 URL과 CTA와 스크린샷과 남은 위험을 항목별로 돌려받는다.

교재와 상담으로 자연스럽게 이어가기

개인 작업이라면 무료 Claude Code cheatsheet로 매일 실행할 명령과 검증 프롬프트를 먼저 고정한다. 같은 요청이 반복되면 50개 prompt template과 Setup Guide를 사용해 CLAUDE.md, hooks, permission 규칙, 리뷰 문장을 재사용 가능하게 만든다.

팀이 공개 글, LP, 상품 판매, 상담 폼을 운영한다면 검증은 개인 습관을 넘어선다. 누가 공개 URL을 볼지, 어떤 CTA가 매출 경로인지, 스크린샷을 어디에 저장할지, 어떤 실패를 배포 중단 조건으로 삼을지 정해야 한다. 이 기준을 함께 설계해야 할 때 상담이 자연스러운 다음 단계가 된다.

• 무료 Claude Code Cheatsheet
• Claude Code Prompt Templates 50개
• Claude Code Setup Guide
• Products
• 상담

이 글에서 실제로 확인한 것

이 글은 diff 확인, build, 공개 URL, CTA, 스크린샷을 하나의 검증 리시트로 묶었다. 실제로 이 방식으로 정리하면 build는 했지만 공개 URL을 안 본 경우, CTA는 봤지만 상담 링크를 안 본 경우, 데스크톱만 보고 모바일을 놓친 경우가 바로 드러난다. Claude Code의 속도를 안전하게 쓰려면 빠른 수정만큼 빠른 증거 기록이 필요하다.