글 게시 전 수익 동선 점검을 자동화하기: Claude Code로 신청 누락 막기

어느 날 아침, 방문 통계를 열어보고 굳어버렸습니다. 전날 올린 글의 조회수가 평소의 3배였거든요. 그런데 무료 PDF 등록은 0건, 교재 클릭도 0건이었습니다. “터졌는데 1원도 안 움직인” 상태였죠.

원인을 찾아보니 어이없는 것이었습니다. 글 마지막의 신청 버튼이 반년 전에 닫은 옛날 상품 페이지를 그대로 가리키고 있었어요. 게다가 영어판 글은 본문 중간부터 한국어로 바뀌어 있어서, 해외 독자는 거기서 이탈하고 있었습니다. 본문은 멀쩡하게 써놓고, 마지막 몇 줄에서 전부 흘려보내고 있었던 겁니다.

그 뒤로 저는 “글을 쓰는 작업”과 “게시해도 되는 상태인지 확인하는 작업”을 완전히 분리했습니다. 후자를 매번 손으로 하면 반드시 빼먹기 때문에, Claude Code에 틀로 들려놓고 있습니다. 오늘은 그 내용을, 복사해서 바로 쓸 수 있는 형태로 전부 풀겠습니다.

핵심 요약

• 조회수가 늘어도 신청이 늘지 않는 원인 대부분은 깨진 링크, 옛날 상품 페이지, 번역 안 된 본문처럼 “게시 전이라면 알아챘을 실수”입니다.
• 게시 전에 볼 항목을 9개로 고정하고, 매번 같은 순서로 확인하면 누락이 확 줄어듭니다.
• Claude Code에 맡기는 건 “페이지를 열어 항목을 기계적으로 확인하는” 부분입니다. 어떤 버튼을 주인공으로 삼을지는 사람이 정합니다.
• 신청 버튼을 글 하나당 하나로 좁히기만 해도 독자가 헤매지 않게 되고, 다음 행동으로 이어지기 쉬워집니다.
• 확인한 내용을 로그로 남기면, 나중에 “무엇을 근거로 게시했는지”를 되짚을 수 있습니다.

게시 전에 볼 9가지 항목을 정한다

“제대로 확인해줘”라고 하면 사람도 AI도 아무것도 하지 않습니다. 확인이란 구체적인 항목 목록입니다. 제가 고정해 둔 건 다음 9가지입니다.

#	확인 항목	보는 포인트
1	페이지가 열리는가	서버가 200을 반환하는가 (404나 500이 아닌가)
2	제목이 맞는가	페이지 상단의 큰 제목이 글 제목과 일치하는가
3	정규 URL 지정	정규(canonical) URL 지정이 그 글 자신의 URL인가
4	대표 이미지	이미지가 표시되는가 (옛날 이미지나 이미지 없음이 아닌가)
5	본문 언어	각 언어판에서 처음부터 그 언어로 쓰여 있는가
6	무료 PDF 안내	등록 버튼이 있고, 링크가 살아 있는가
7	교재 링크	링크가 의도한 상품 페이지인가 (다른 상품으로 가지 않는가)
8	상담 페이지 동선	링크가 상담 페이지로 향하는가
9	모바일 표시	가로 스크롤이 생기지 않는가 (화면 밖으로 삐져나오지 않는가)

포인트는 3번과 7번입니다. 정규 URL 지정이 메인 페이지나 다른 글을 가리키면, 검색 엔진이 그쪽을 “정본”으로 취급해서 애써 쓴 글이 평가받지 못합니다. 링크가 엉뚱한 곳을 가리키는 일은, 복사해서 만든 글일수록 자주 일어납니다.

AI에 맡길 범위와 사람이 정할 범위

여기를 섞으면 사고가 납니다. 선을 명확히 긋겠습니다.

Claude Code에 맡길 것은 기계적으로 판정할 수 있는 확인입니다. 페이지를 연다, 제목을 읽어낸다, 링크 대상을 가져온다, 이미지가 표시되는지 본다, 모바일 너비에서 레이아웃을 확인한다. 여기는 사람이 하면 귀찮고, 귀찮으면 건너뛰기 때문에 AI에게 매번 시킵니다.

사람이 정할 것은 판단이 필요한 부분입니다. 이번 글에서 주인공으로 삼을 버튼은 어느 것인가. 본문 표현이 자연스러운가. 옛날 상품을 안내하고 있지는 않은가. 그리고 “이 글은 정말 게시해도 되는가”라는 최종 판단. 여기를 AI에게 통째로 던지면, 링크는 살아 있지만 내용이 어긋난 글이 세상에 나갑니다.

망설일 때의 기준은 단순합니다. 정답이 하나로 정해지는 건 AI, 취향이나 전략이 얽히는 건 사람. 링크가 200을 반환하는지는 하나로 정해지니까 AI. 버튼 3개 중 어느 걸 눈에 띄게 할지는 전략이니까 사람, 입니다.

복사해서 쓰는 지시문 템플릿

Claude Code에 그대로 붙여 넣을 수 있는 지시문입니다. 저장소 이름과 확인하고 싶은 URL만 자기 것으로 바꿔주세요.

다음 URL 각각에 대해 게시 전 점검을 실행하세요.
페이지가 200으로 열릴 것, 큰 제목이 글 제목과 일치할 것,
정규 URL 지정이 같은 글을 가리킬 것, 대표 이미지가 표시될 것,
본문이 해당 언어로 쓰여 있을 것, 무료 PDF 등록 버튼이 살아 있을 것,
교재 링크가 의도한 상품 페이지로 갈 것, 상담 페이지 링크가 올바를 것,
모바일 너비에서 가로 스크롤이 생기지 않을 것을 확인합니다.

각 URL에 대해 한 줄로, 통과한 항목과 떨어진 항목을 나눠서 보고하세요.
"200으로 열렸다"만으로 통과 처리하지 마세요. 떨어진 항목이 있으면,
원인 추정과 어느 파일을 고치면 되는지도 적어 주세요.

마지막 두 문장이 핵심입니다. “200으로 열렸다=OK”에서 멈추면, 가장 흔한 링크 오기를 놓칩니다. 떨어진 항목을 반드시 나눠 보고하게 하고, 고칠 위치까지 말하게 하면, 그대로 수정에 들어갈 수 있습니다.

복사해서 동작하는 판정 스크립트

확인 결과를 모아 “게시해도 되는지”를 기계적으로 반환하는 부분은, 코드로 만들어 두면 매번 흔들리지 않습니다. Node.js에서 동작하는 최소 버전입니다.

// 게시 전 반드시 통과시키고 싶은 9개 항목
const requiredChecks = [
  "페이지가 200으로 열림",
  "큰 제목이 글 제목과 일치",
  "정규 URL 지정이 같은 글을 가리킴",
  "대표 이미지가 표시됨",
  "본문이 해당 언어로 쓰여 있음",
  "무료 PDF 등록 버튼이 살아 있음",
  "교재 링크가 의도한 상품 페이지",
  "상담 페이지 링크가 올바름",
  "모바일 너비에서 가로 스크롤 없음",
];

// passed 에는 통과한 항목명 배열을 넘긴다
function summarizeSmokeResult(passed) {
  const missing = requiredChecks.filter((check) => !passed.includes(check));
  return {
    ok: missing.length === 0,
    missing,
    nextAction: missing.length === 0 ? "게시해도 됨" : "수정 후 재확인",
  };
}

// 동작 예: 교재 링크만 떨어진 경우
const passed = requiredChecks.filter((c) => c !== "교재 링크가 의도한 상품 페이지");
const result = summarizeSmokeResult(passed);

console.log(result.ok ? "게시 OK" : "게시 NG");
console.log("떨어진 항목:", result.missing);
console.log("다음 행동:", result.nextAction);

이 스크립트를 실행하면 게시 NG와 떨어진 항목명, 다음에 할 일이 표시됩니다. 한 항목이라도 빠지면 ok는 false가 되니까, “대충 OK”로 게시하는 사고가 일어나지 않습니다. passed 배열을, 앞서 지시문으로 AI에게 확인시킨 결과로 채우기만 하면 됩니다.

실제로 효과가 있었던 3가지 장면

1. 하루에 여러 편을 게시하는 날 3편을 한꺼번에 내는 날은 확인이 대충대충 됩니다. 각 글을 한 편씩 모바일 너비로 열고, 제목, 본문 첫 부분, 신청 버튼 근처까지 스크롤해서 봅니다. 영어 이외의 판에서 본문이 영어 그대로면, 그 시점에 게시를 멈춥니다. 대충 하기 쉬운 날일수록 고정 목록이 효과를 봅니다.

2. 인기 글의 버튼만 교체할 때 잘 읽히는 글의 마지막 버튼을 하나만 바꾸는 경우에도, “관련된 부품을 찾아서 고쳐줘”라고만 부탁하면 너무 넓습니다. 먼저 건드려도 되는 파일, 건드리지 않을 파일, 확인할 URL, 각 링크 대상을 정합니다. 이것만으로도 작업 후의 확인이 “왠지 괜찮아 보임”에서 “이 증거라면 게시 가능”으로 바뀝니다.

3. 다국어 글의 품질 확인 글 설정상의 언어 지정이 올바르더라도, 본문이 영어 그대로면 게시 품질이 아닙니다. 각 언어에서 큰 제목, 본문 첫 부분, 버튼 근처를 보고, 그 언어의 독자가 다음에 무엇을 하면 되는지 알 수 있는지 확인합니다. 한국어 독자라면 무료 PDF 설명도, 교재 안내도, 상담 유도도 한국어로 자연스럽게 읽혀야 합니다.

흔한 함정과 고치는 법

함정 1: 로컬에서 빌드가 통과한 것만으로 “게시 완료”라고 보고한다 손쉽게 빌드가 성공해도, 게시된 페이지가 올바르게 표시된다는 보장은 없습니다. 고치는 법은, 확인 대상을 “로컬 빌드 결과”가 아니라 “게시 URL의 실물”로 삼는 것입니다. AI에게도 “게시 URL을 열어서 확인해줘”라고 명시합니다.

함정 2: 신청 버튼을 전부 늘어놓는다 무료 PDF, 교재 A, 교재 B, 상담을 같은 크기로 늘어놓으면, 독자는 무엇을 눌러야 할지 몰라서 결국 아무것도 안 누릅니다. 고치는 법은, 글 하나당 주인공 버튼을 하나로 정하고, 나머지는 조용한 보조로 돌리는 것입니다.

함정 3: 링크가 다른 상품으로 간다 “무료 PDF”라고 적혀 있는데 클릭하면 유료 교재로 가는 일은, 복사한 글에서 자주 일어납니다. 고치는 법은, 확인 항목 7번의 링크 대상 가져오기를 AI에게 반드시 시키고, 상품 ID까지 눈으로 대조하는 것입니다.

함정 4: 되돌리는 법을 정하지 않고 크게 고친다 게시 직전에 넓은 범위를 다시 쓰고, 이상해져도 원래대로 못 돌리는 게 최악입니다. 고치는 법은, 한 번의 작업에서 “이상하면 원래대로 되돌리는 절차”를 미리 마련할 수 있는 범위로 좁히는 것입니다. 되돌리는 법을 적을 수 없는 작업은, 그 회차에는 너무 큽니다.

자주 묻는 질문

Q. 조회수는 늘었는데 신청이 늘지 않습니다. 먼저 무엇을 봐야 하나요? A. 신청 버튼의 링크 대상과 본문의 언어를 먼저 보세요. 링크가 옛날 상품 페이지 그대로이거나, 해외 독자용 판이 영어로 안 되어 있는 게 두 가지 대표 원인입니다. 게시 전 점검의 항목 5, 6, 7에 해당합니다.

Q. 이 확인은 매번 필요한가요? 번거롭습니다. A. 매번 필요합니다. 그래서 손으로 하지 말고, 이 글의 지시문을 Claude Code에 넘겨 기계적으로 시킵니다. 번거로운 확인일수록 사람은 바쁜 날에 건너뜁니다. 건너뛴 날에 한해서 사고가 납니다.

Q. 버튼을 하나로 좁히면, 다른 상품으로 가는 입구가 줄어들지 않나요? A. 입구의 수보다, 독자가 헤매지 않고 하나를 누를 수 있는지가 중요합니다. 여러 개를 늘어놓으면 못 고르고 이탈합니다. 주인공을 하나 정하고, 보조 링크는 글 안에 자연스럽게 1~2개만 두는 게 딱 맞는 균형입니다.

Q. 정규 URL 지정이 왜 그렇게 중요한가요? A. 검색 엔진은 정규(canonical) URL로 지정된 페이지를 “정본”으로 평가합니다. 여기가 다른 글이나 메인 페이지를 가리키면, 쓴 글이 아니라 다른 페이지가 평가받고, 검색 순위도 그쪽으로 모입니다.

Q. 확인 로그는 무엇을 위해 남기나요? A. 나중에 “무엇을 근거로 게시했는지”를 되짚기 위해서입니다. 문제가 생겼을 때 본문, 버튼, 링크, 상담 동선 중 어디서 떨어졌는지를 가려내기 쉬워집니다. 남아 있지 않으면, 다음 운영에서 처음부터 다시 확인해야 합니다.

확인한 내용을 한 장에 남긴다

게시 후 짧은 메모를 남겨두면, 다음 확인이 단번에 편해집니다. 다음과 같은 형태면 충분합니다.

- 글: claude-code-revenue-smoke-test
- 게시일: 2026-06-14
- 확인한 증거: 게시 URL, 큰 제목, 정규 URL 지정, 대표 이미지, 본문 언어, 버튼 링크 대상
- 주인공 버튼: 교재 링크 (스스로 굴러가는 독자용)
- 다음에 볼 숫자: 조회수, PDF 등록, 교재 클릭, 상담 페이지 이동

숫자를 볼 때도 조회수만으로 판단하지 않습니다. 무료 PDF 등록, 교재 클릭, 상담 페이지로의 이동을 같은 날짜로 나란히 둡니다. 초보자용 글이라면 PDF 등록이, 설정이나 권한을 다루는 글이라면 교재 클릭이 늘 거라는 가설과 대조합니다. 이 습관이 있으면, 매일의 게시가 “그냥 올리는 작업”에서 “동선을 조금씩 고치는 구조”로 바뀝니다.

이 “기계에 맡기는 확인”과 “사람이 정하는 판단”의 선 긋기는 수익 점검 말고도 같은 사고방식을 쓸 수 있습니다. 비개발자가 Claude Code를 쓸 때의 전체 그림은 비개발자가 Claude Code를 쓰는 방법에, 매일의 작업을 빠르게 하는 잔기술은 Claude Code 생산성 향상 팁에 정리해 두었습니다. 확인을 AI에 제대로 부탁하려면 지시문의 정밀도가 필요하니, Claude Code 프롬프트 실전 테크닉도 함께 읽으면 효과적입니다.

참고로 AI에게 파일을 읽히거나 링크를 확인시키는 처리의 전제가 되는 구조는, 공식 Claude Docs에서 확인할 수 있습니다. 동작이 바뀐 것 같다고 느끼면, 우선 1차 정보를 보는 게 결국 가장 빠릅니다.

실제로 시험해 본 결과

이 틀을 제 사이트에서 2주쯤 돌려봤습니다. 확인하고 싶었던 건 “게시 전 9항목 점검이 정말로 누락을 줄이는가”였습니다.

결과적으로, 페이지가 200으로 열리는 것만 보던 시절에는 그냥 지나쳤던 문제가 여럿 발견됐습니다. 구체적으로는, 다른 글의 대표 이미지를 그대로 가져다 쓴 채 게시하려던 경우가 2건, 신청 버튼 링크가 옛날 상품을 가리키던 경우가 1건, 영어판 본문이 중간부터 한국어 그대로이던 경우가 1건입니다. 전부 “200으로 열린다”만으로는 통과 처리됐을 것들입니다.

특히 효과가 있던 건, 신청 버튼을 글 하나당 하나로 좁히는 운영이었습니다. 무료 PDF, 교재, 상담을 같은 무게로 늘어놓던 글을 주인공 하나로 정리했더니, 버튼 클릭률이 눈에 띄게 올랐습니다. 독자는 선택지가 적을수록 움직인다는 걸 숫자로 실감했습니다.

반대로 알게 된 건, 이 확인은 수작업이면 지속이 안 된다는 것입니다. 처음 며칠은 손으로 했지만, 바쁜 날에 깔끔하게 건너뛰었습니다. 지시문과 스크립트 형태로 만들어 매번 같은 절차로 돌리게 한 뒤에야, 비로소 자리 잡았습니다.

게시 전의 수수한 확인을 구조로 만들어 둔다. 이것이 조회수를 수익으로 잇는 가장 싼 보험이었습니다. 혹시 회사의 블로그 운영이나 팀 게시 흐름에 녹여 넣고 싶다면, 연수·상담에서 실제 운영에 맞춘 틀을 함께 설계할 수 있습니다.