조회수는 늘었는데 안 팔리는 글을, 다음 행동으로 잇는 동선 만들기

지난달 제 블로그에서 가장 많이 읽힌 글은 “Claude Code 입문”이었습니다. 월 3,200 조회. 나쁘지 않은 숫자죠. 그런데 그 글을 통해 무료 PDF를 내려받은 사람은 한 달 동안 딱 4명이었습니다.

이상하다 싶어 글 끝부분을 봤더니 원인은 금방 드러났습니다. 마지막 문단에 무료 PDF, 유료 템플릿 모음, 설정 가이드, 상담 폼, 상품 목록 링크가 전부 똑같은 크기로 5개 나란히 놓여 있었던 겁니다.

이러면 독자는 고를 수 없습니다. 입문 글에 도착한 사람은 “다음에 뭘 하면 되는지”를 알고 싶을 뿐인데, 갑자기 5지선다를 들이밀린 거죠. 결국 아무것도 안 누르고 탭을 닫고 끝입니다.

글은 읽히는데 매출로 이어지지 않는다. 이 막힘은 글의 품질 문제도, Claude Code가 똑똑한지의 문제도 아닙니다. 글 한 편에 권하는 걸 5개나 두고 있다는 것이 원인입니다. 오늘은 이걸, 글마다 “다음 한 수”를 딱 하나만 정하는 분류표로 바꿔 보겠습니다.

핵심 요약

• 조회수가 있는데 교재나 상담이 안 움직이는 건, 글 끝에서 권하는 게 너무 많기 때문입니다. 독자는 5지선다를 받으면 아무것도 고르지 않습니다.
• 해결책은 글의 “검색 의도”를 보고, 권할 것을 글 한 편당 하나로 좁히는 분류표를 만드는 것입니다.
• 입문 글은 무료 PDF, 의뢰문에 고민하는 사람은 프롬프트 모음, 설정·권한 글은 유료 가이드, 팀 도입은 상담. 이렇게 의도별로 출구를 나눕니다.
• Claude Code에 맡기는 건 “어떤 의도에 어떤 출구인가”의 기계적 분류입니다. “이 독자에게 무엇을 권해야 하는가”의 최종 판단은 사람이 합니다.
• 공개 후에는 글 전체를 다시 쓰지 말고, 도입부 이탈률과 첫 링크 클릭만 보고 약한 한 곳만 고칩니다.

왜 “다음 한 수”를 하나로 좁히면 효과가 있나

사람은 선택지가 많을수록 결정하지 못합니다. 행동경제학에서 “선택의 역설”이라 부르는, 잘 알려진 이야기죠. 잼 시식을 24종류 늘어놓은 매대보다, 6종류만 놓은 매대가 훨씬 잘 팔렸다는 유명한 실험이 있습니다.

글 끝의 링크도 마찬가지입니다. 무료 PDF, 템플릿 모음, 설정 가이드, 상담, 상품 목록. 좋은 마음으로 전부 늘어놓으면, 독자 머릿속에서 “어느 게 내게 맞지?”라는 비교 작업이 시작됩니다. 비교는 귀찮으니 대부분 사람은 거기서 이탈합니다.

그래서 출구는 글 한 편당 하나로 좁힙니다. 단, “항상 무료 PDF” 같은 고정은 아닙니다. 글마다, 그 글을 읽으러 온 사람이 다음에 원하는 게 다르기 때문입니다. 입문 글을 읽는 사람과 권한 설정에서 막힌 사람은 권해야 할 게 완전히 다릅니다. 이 “글의 의도에 맞춰 출구를 바꾸는” 구조를 오늘은 표와 코드로 만듭니다.

검색 의도별로 출구를 정하는 분류표

먼저 내 블로그 글을 “독자가 무엇에 곤란해서 여기 왔는가”로 분류합니다. 이 곤란함을 여기서는 검색 의도라고 부릅니다. 저는 5개로 나눕니다.

검색 의도(독자의 곤란함)	예가 되는 글	다음에 권할 하나
일단 시작하고 싶다(초보)	입문, 설치 절차	무료 PDF
같은 의뢰문을 매번 쓰는 게 귀찮다	프롬프트 요령, 의뢰문 틀	프롬프트 모음(유료)
설정·권한·안전 운용에서 막힌다	권한 설정, CLAUDE.md 작성법	설정 가이드(유료)
팀이나 회사에서 실무 도입하고 싶다	팀 운용, 실무 리스크, 비용 추산	도입 상담
어디에도 안 맞는다	잡담, 뉴스류	무료 PDF(기본 출구)

핵심은 오른쪽 끝 열입니다. 글 한 편에 여기 들어가는 건 반드시 하나뿐. 여러 개 쓰고 싶어지면, 그 글의 독자상이 아직 흐릿하다는 증거입니다.

예를 들어 권한 설정 글에 “무료 PDF도 유료 가이드도 상담도” 전부 넣고 싶어지면 멈춥니다. 권한 설정에서 곤란한 사람이 다음에 원하는 건 거의 확실히 “더 자세한 설정 안내”입니다. 거기에 무료 PDF를 섞으면, 모처럼 유료 가이드에 딱 맞는 독자를 싼 쪽으로 흘려보냅니다.

이 표가 완성되면, 나머지는 글마다 “어떤 의도인가”를 하나 정해서 출구를 끼워 넣기만 하면 됩니다. 판단이 망설여지는 글은 대개 한 편에 두 가지 화제가 섞여 있습니다. 그럴 땐 글을 나누는 편이 동선도 가독성도 좋아집니다.

AI에 맡기는 범위와, 사람이 판단하는 범위

여기서 흔한 실패가, 분류 전체를 Claude Code에 통째로 떠넘기는 것입니다. “알아서 각 글에 CTA 좀 붙여 둬”라고 부탁하면, 맥락을 너무 읽어서 이상한 출구를 붙여 옵니다.

선 긋기는 이렇게 합니다.

• Claude에 맡길 것: 분류표를 따른 기계적 작업. 글의 의도 라벨을 받아 대응하는 출구를 끼워 넣기. 글 끝 문구를 정한 하나의 출구에 맞춰 쓰기. CTA가 2개 이상 남아 있지 않은지 기계 점검하기.
• 사람이 판단할 것: 그 글의 검색 의도가 무엇인지 최종적으로 정하는 일. 가격이나 보여 주는 방식을 바꾸는 일. 새 의도 카테고리를 늘리는 일. 여기는 독자의 마음을 읽는 일이라 사람이 합니다.

즉 “어떤 의도인가”를 사람이 한 단어로 정하고, “그럼 어떤 출구인가”와 “문구 초안”을 Claude에 시킵니다. 이렇게 나누면 사고가 안 납니다. 참고로 Claude Code에 이런 정형 작업을 한꺼번에 맡길 때의 기본은 Anthropic 공식 Claude Code 문서에도 정리돼 있습니다.

의뢰할 때 쓰는 프롬프트 틀은 이런 형태로 두고 있습니다. 복붙해서 따옴표 안만 자기 글로 바꾸세요.

다음 글에, 출구(다음에 권할 것)를 하나만 붙여 주세요.

- 글의 slug: 「claude-code-permissions-guide」
- 검색 의도: 「설정·권한·안전 운용에서 막힌다」
- 분류표에서 대응하는 출구: 「설정 가이드(유료)」
- 출구의 링크 URL: 「https://example.com/setup-guide」

조건:
1. 글 끝의 출구는 반드시 하나만. 다른 링크는 두지 않는다.
2. 「사 주세요」가 아니라, 이 글의 작업을 내일도 재현하기 위해
   그 가이드가 어떻게 도움이 되는지 1~2문장으로 쓴다.
3. 출구가 2개 이상 남아 있지 않은지, 마지막에 스스로 점검해 보고한다.

마지막 3번이 중요합니다. Claude에 자기 점검을 말로 지시해 두면, 링크 수를 빠뜨리는 일이 확 줄어듭니다.

복붙으로 동작: CTA 개수를 세서 경고하는 스크립트

사람 눈에만 기대면, 바쁜 날에는 반드시 놓칩니다. 그래서 “글 끝의 출구가 2개 이상 아닌가”를 기계로 세는 작은 문지기를 둡니다. Node.js로 동작하는, 의존 라이브러리 없는 스크립트입니다.

import { readFile } from "node:fs/promises";

// 출구로 간주할 링크 패턴(자기 동선에 맞게 추가)
const offerPatterns = [
  { name: "무료 PDF", re: /\/thanks\// },
  { name: "프롬프트 모음", re: /gumroad\.com\/l\/huqrgo/ },
  { name: "설정 가이드", re: /gumroad\.com\/l\/ceyhda/ },
  { name: "도입 상담", re: /\/training\// },
];

// 글 끝(마지막 제목 이후)만 대상으로 한다
function tailSection(markdown) {
  const idx = markdown.lastIndexOf("\n## ");
  return idx === -1 ? markdown : markdown.slice(idx);
}

async function checkOffers(filePath) {
  const text = await readFile(filePath, "utf8");
  const tail = tailSection(text);
  const found = offerPatterns.filter((p) => p.re.test(tail));

  if (found.length === 0) {
    console.log(`⚠ ${filePath}: 출구가 하나도 없습니다. 다음 한 수가 없는 글입니다.`);
  } else if (found.length > 1) {
    const names = found.map((f) => f.name).join(", ");
    console.log(`⚠ ${filePath}: 출구가 ${found.length}개 있습니다(${names}). 하나로 좁히세요.`);
  } else {
    console.log(`OK ${filePath}: 출구는 "${found[0].name}" 하나뿐입니다.`);
  }
}

// 사용법: node check-offers.mjs 글 파일의 경로
const target = process.argv[2];
if (!target) {
  console.error("사용법: node check-offers.mjs <글 파일>");
  process.exit(1);
}
checkOffers(target);

check-offers.mjs라는 이름으로 저장해서, 이렇게 실행합니다.

node check-offers.mjs ./content/blog/claude-code-permissions-guide.mdx

출구가 2개 이상 남아 있으면 그 자리에서 경고가 나옵니다. 공개 전에 이걸 전 글에 돌리면, “깜빡하고 5개 늘어놓은 채 공개”가 물리적으로 일어나지 않게 됩니다. 저는 공개 흐름 마지막에 이 한 줄을 끼워 두는데, 덕분에 서두에 말한 사고는 멈췄습니다.

실제로 써 본 3가지 장면

1. 입문 글의 출구를 무료 PDF만으로 했다 3,200 조회의 입문 글에서 유료 템플릿과 상담 링크를 빼고 무료 PDF만 남겼습니다. 이유는 단순합니다. 입문 글에 온 사람은 아직 돈을 낼 단계에 있지 않기 때문입니다. 결과적으로 PDF 다운로드는 월 4건에서 31건으로 늘었습니다. 무료로 명단에 들어오게 한 다음 후속 메일로 유료 교재를 안내하는 편이, 처음부터 들이파는 것보다 잘 됩니다.

2. 프롬프트 글을 유료 템플릿 모음에 직결했다 의뢰문 작성법에 고민하다 검색해 온 사람은 이미 Claude Code 자체는 쓸 줄 압니다. 그래서 무료 PDF는 필요 없습니다. 이 층에는 프롬프트 실력 키우는 법 글에서 유료 템플릿 모음만 출구로 두었습니다. “내일도 같은 품질의 의뢰문을 재현하는 데 도움이 됩니다”라는 한 문장만 덧붙였더니 클릭률이 올랐습니다.

3. 권한·설정 글을 상담으로 이었다 팀 도입이나 실무 운용 리스크를 다루는 글은 셀프 교재만으로는 부족합니다. 독자가 알고 싶은 건 “우리 환경에서 안전한가”라는 개별 판단이기 때문입니다. 권한 가이드 같은 글은 상담 폼을 유일한 출구로 했습니다. 여기서 무료 PDF를 섞으면, 본래 상담으로 진행해야 할 회사 담당자를 무료 소책자로 만족시켜 놓쳐 버립니다.

흔한 함정과, 그 고치는 법

함정 1: 약한 동선을 발견하고 글 전체를 다시 쓴다 “PDF 클릭이 적다”는 걸 알면, 그만 글을 통째로 리라이트하고 싶어집니다. 하지만 그건 느리고, 맞을 확률도 낮습니다. 고치는 건 약한 한 곳만. PDF가 약하면, 본문에서 다룬 작업을 “PDF로 어떻게 복습할 수 있는가”를 끝에 1~2문장 더할 뿐. 이걸로 충분한 경우가 많습니다.

함정 2: 로컬에서 빌드가 통과하면 공개됐다고 착각한다 손에서 빌드가 통과해도, 공개 URL에서 다른 글이나 첫 페이지가 표시되고 있는 경우가 있습니다. HTTP 200이 돌아오는 것만으로는 부족합니다. 공개 후 실제 URL을 열어, 제목, 대표 이미지, 본문 도입, 출구 링크가 “그 글의 것”으로 돼 있는지 눈으로 확인합니다.

함정 3: 무엇을 시험했는지 기록하지 않는다 출구를 바꿔 클릭이 어떻게 움직였는지 메모에 남기지 않으면, 다음 달 또 같은 시행착오를 반복합니다. “이 글은 의도를 ○○로 고치고, 출구를 △△로 했다, 결과 클릭은 □건”이라고 한 줄만 남깁니다. 이것만으로 판단이 쌓입니다.

수정의 기본 규칙은 늘 같습니다. 실패가 보이면 글 전체가 아니라, 첫 실패 예 근처에 증거를 모으고, 출구 수를 줄이고, 다음 행동을 잴 수 있는 형태로 만든다. 이 순서만 지켜도 개선 속도가 달라집니다.

자주 묻는 질문

Q. 출구는 정말 글 한 편당 하나만 둬야 하나요? 무료와 유료를 둘 다 두고 싶은데요. A. 끝부분의 주 출구는 하나로 좁히세요. 굳이 무료 보험을 남기고 싶다면, 유료 출구를 눈에 띄게 하고 무료는 그 아래에 작게 한 줄만 덧붙입니다. 같은 크기로 둘을 나란히 두면, 독자는 거의 싼 쪽이나 아무것도 안 하는 쪽으로 흐릅니다.

Q. 분류표의 의도 카테고리는 5개보다 늘려도 되나요? A. 늘릴 수 있지만, 처음엔 5개로 시작하길 권합니다. 카테고리가 많을수록 어느 글이 어디에 들어가는지 망설이는 시간이 늘어납니다. 운용하면서 “도저히 5개에 안 담기는 글 무리”가 보이면, 그때 하나 더하는 정도가 딱 좋습니다.

Q. Claude Code에 전 글 CTA 붙이기를 한 번에 시켜도 괜찮나요? A. 한 번에는 위험합니다. 글의 의도 라벨만은 사람이 한 글씩 정하고, 그 후 문구 생성과 점검을 Claude에 맡깁니다. 의도 판단까지 맡기면, 맥락을 너무 읽어서 엉뚱한 출구를 붙일 때가 있습니다. 먼저 몇 글로 시험한 뒤 넓히세요.

Q. 클릭을 측정하는 구조가 없습니다. 어떻게 시작하면 되나요? A. 처음부터 완벽한 측정을 노리지 말고, 링크에 표시 파라미터(예: ?from=intro-article)를 붙이는 것만으로도 어느 글에서 온 클릭인지 알 수 있습니다. 접근 분석의 기초는 Claude Code 시작하는 법에서 다룬 절차와 같은 사고방식으로 도입할 수 있습니다.

Q. 조회수가 적은 글의 출구는 나중으로 미뤄도 되나요? A. 네. 조회수가 많은 상위 10개 글부터 손대세요. 동선 개선은 조회수에 비례해 효과가 나므로, 접근이 적은 글을 고쳐도 효과가 잘 안 보입니다. 먼저 돈줄이 되는 입구를 정돈하는 게 우선입니다.

실제로 시험해 본 결과

이 분류표를 제 블로그 전 23개 글에 적용해 봤더니, 가장 효과가 컸던 건 “출구를 세는 문지기 스크립트”였습니다. 돌려 봤더니 놀랍게도 8개 글에 출구가 2개 이상 남아 있었고, 3개 글은 출구가 0개였습니다. 스스로는 하나로 좁혔다고 생각했는데, 과거 템플릿의 링크가 지우는 걸 깜빡해 남아 있었던 겁니다.

의도 라벨을 다시 붙이는 작업은 Claude Code에 통째로 떠넘기지 않고, 직접 한 글씩 “이건 초보용” “이건 권한에 곤란한 사람용”이라고 정했습니다. 23개 글에 30분쯤. 그 뒤 문구 초안과 수의 최종 점검만 Claude에 맡겼더니, 반나절에 전 글의 출구가 하나로 정렬됐습니다.

한 달 뒤 숫자로 확인한 건, 입문 글의 PDF 다운로드가 4건에서 31건으로 늘었다는 것, 그리고 전체 조회수는 거의 변하지 않았다는 것입니다. 접근을 늘린 게 아니라, 이미 와 있던 독자를 놓치지 않게 됐을 뿐. 글을 늘리기 전에 출구를 고치는 편이 빠르다, 라는 게 이번에 가장 납득한 점이었습니다.

동선보다 먼저 글 자체를 만드는 법을 정돈하고 싶은 사람은 Claude Code 시작하는 법부터 읽는 걸 권합니다. 비개발자라 동선 설계가 막막하다면 비개발자를 위한 Claude Code도 함께 보면 좋습니다. 회사 블로그나 오운드 미디어에서 팀으로 수익 동선을 설계하고 싶다면, 개별 연수·상담에서 함께 짜고 있습니다.