Claude Code로 만든 타로·사주 서비스, 광고비보다 먼저 검증할 것

Claude Code로 타로·사주 서비스를 만들었다면, 광고를 시작하기 전에 무엇을 검증해야 할까? 제작 속도가 빨라질수록 비슷한 서비스를 마주한 고객이 이 서비스를 선택할 이유가 중요해진다. 이 글은 랜딩페이지를 만드는 순서부터 광고비와 실제 결제를 대조하는 방법까지 따라간다.

서비스보다 구매할 이유를 먼저 적는다

클코단 논의에서는 타로·사주 서비스를 만드는 일과 고객을 확보하는 일을 별개로 봐야 한다는 의견이 나왔다. 비슷한 선택지가 많다고 느끼는 시장에서는 노출만 늘려서는 부족하다는 판단이다. 다만 시장 규모나 경쟁 서비스 수를 조사한 대화는 아니므로, 과밀 여부를 확정된 통계처럼 말할 수는 없다.

검증할 질문은 더 작고 구체적이다. ‘연애 고민을 짧게 정리하고 싶은 사람’과 ‘사주 풀이를 처음 구매하는 사람’이 같은 설명을 보고 결제할까? 두 고객에게 모두 ‘정확한 운세’만 강조하면 무엇을 받고 얼마를 내는지조차 구별하기 어렵다.

페이지를 만들기 전, 각 고객에게 보여줄 약속을 한 장씩 써볼 수 있다. 대상 고객, 다루는 질문, 제공 결과, 가격, 전달 시점, 환불 안내를 분리해 적는다. 타로나 사주 풀이의 정확도를 입증하지 못했다면 결과를 보장하는 문구도 넣지 않는다. 이 문서는 광고 문구와 실제 상품 설명이 서로 다른 말을 하지 않도록 잡아주는 기준이 된다.

Claude Code에는 화면보다 입력 자료를 먼저 준다

방 논의에서 제안된 과제는 타깃별 랜딩페이지를 여러 개 설계하는 일이었다. 이를 제작 절차로 옮기려면 먼저 offer.md에 앞서 정한 상품 조건을 적는다. audience-a.md와 audience-b.md에는 각 고객의 질문과 구매 전 우려를 따로 적는다. 이 파일들은 이미 존재하는 방의 결과물이 아니라, 독자가 직접 만들 수 있는 작업 예시다.

프로젝트 폴더에서 Claude Code를 실행한 뒤 세 파일을 읽게 한다. 첫 요청은 코딩이 아니라 두 페이지의 구성안이다. 예를 들어 ‘상품 조건은 바꾸지 말고, 고객별 제목·설명 순서·자주 묻는 질문만 달리한 화면 계획을 제시해줘’라고 요청한다. 구성안을 검토한 다음에야 /landing-a와 /landing-b를 구현하게 한다. Claude Code 공식 문서도 작업 전에 코드베이스를 살피고 계획한 뒤 구현과 검증을 거치는 방식을 안내한다. (code.claude.com)

산출물은 예쁜 화면 두 장으로 끝나지 않는다. 모바일에서 가격과 구매 버튼이 보이는지, 결제 버튼이 올바른 화면으로 가는지 확인해야 한다. 제공하지 않는 상담 방식이나 처리 시간을 AI가 문구에 덧붙이지 않았는지도 사람이 읽어야 한다. 랜딩페이지를 만들어본 사람들 사이에서도 초안 이후의 문구와 상호작용은 손질이 필요하다는 반응이 있다.

광고 클릭과 결제를 다른 사건으로 기록한다

노출을 늘리고 구매 확률을 높이자는 방의 제안은 측정 항목을 나누면 실행 가능해진다. 광고가 보여진 횟수와 클릭 수는 유입을 설명한다. 페이지 방문, 결제 시작, 결제 완료를 보면 방문 이후 어디에서 멈추는지 알 수 있다. 클릭이 늘었는데 구매가 그대로라면 광고 예산을 올리기 전에 페이지와 상품 제안을 다시 살펴야 한다.

GA4 공식 문서는 웹사이트의 행동을 이벤트로 측정하며, 전자상거래 흐름에 begin_checkout과 purchase를 사용한다. 구현 예시에서는 결제 시작 시점과 구매 확정 시점을 구분한다. 구매 이벤트에는 실제 거래 금액과 거래 식별자를 연결해 중복 집계 여부까지 시험한다. 이벤트가 찍힌다는 사실만으로 올바른 매출이 기록됐다고 가정하지 않는다. (developers.google.com)

어느 광고에서 들어왔는지도 남겨야 한다. Google Analytics는 광고 링크에 utm_source, utm_medium, utm_campaign을 붙여 캠페인별 유입을 구분하도록 안내한다. 두 페이지로 향하는 링크의 이름을 일관되게 정하고 구매까지 이어지는지 확인한다. Google Ads의 랜딩페이지 보고서에서는 광고가 보낸 URL별 성과도 살필 수 있다. (support.google.com)

여러 페이지를 만들되 한 번에 하나만 바꾼다

타깃별 페이지를 동시에 내놓는 것과 무엇이 효과를 냈는지 알아내는 것은 다르다. 고객층, 광고 영상, 가격, 페이지 제목을 한꺼번에 바꾸면 결과의 원인을 분리하기 어렵다. Google Ads는 실험 목표를 정하고 한 번에 한 변수만 시험하라고 안내한다. 광고 실험 기능은 원래 캠페인과 변경안을 비교할 수 있다. (support.google.com)

가령 같은 고객층에 같은 광고를 보여주고 도착 페이지만 바꿔볼 수 있다. 처음에는 가격을 그대로 둔 채 첫 화면의 설명 순서만 달리한다. 광고 문구와 타깃까지 바꾸고 싶다면 별도 실험으로 넘긴다. 방에서 나온 ‘여러 랜딩페이지’ 제안은 페이지를 많이 만드는 목표보다 어떤 고객에게 어떤 설명이 통하는지 묻는 실험으로 좁힐 때 유용하다.

표본이 적은 초기 서비스라면 작은 차이를 승리로 선언하지 않는 편이 낫다. Google Ads 실험 안내도 결과를 판정할 데이터가 부족할 수 있다고 설명한다. 실제 써본 사람들 사이에서도 적은 예산의 테스트는 클릭보다 구매 같은 최종 행동을 읽기 어렵다는 불만이 있다. 이때는 수치를 과장하기보다 방문자가 어느 단계에서 멈췄는지와 들어온 질문을 함께 기록할 수 있다. (support.google.com)

광고비보다 매출이 큰데도 손해일 수 있다

방에서는 광고에 쓴 돈보다 더 벌 수 있는지가 기준으로 제시됐다. 개인 개발자나 작은 팀에게 필요한 출발점이지만, 매출과 이익은 구분해야 한다. 결제 수수료, 환불, 풀이를 제공하는 데 드는 비용을 빼기 전이라면 광고비보다 매출이 커도 남는 돈은 없을 수 있다. Google Ads도 광고 효과를 판단할 때 매출뿐 아니라 비용을 반영한 투자수익을 살피도록 설명한다. (support.google.com)

실험 기록에는 페이지별 광고비, 결제 건수, 결제 금액을 함께 둔다. 환불과 제공 비용을 반영해 실제로 남은 금액도 적는다. 무료 풀이를 제공한다면 무료 체험 신청을 매출로 세지 않는다. 숫자가 적을 때는 한 건의 구매가 결과를 크게 흔든다는 점도 표시해야 한다.

아이디어에 비해 실행이 더디다는 고민에는 또 다른 기능 제안이 답이 되지 않는다. 이번 실험의 산출물을 고객 설명 두 개, 작동하는 결제 경로 하나, 신뢰할 수 있는 구매 기록으로 한정하면 어떨까. 그 자료가 쌓여야 다음 광고가 필요한지, 아니면 상품의 약속부터 바꿔야 하는지 판단할 수 있다.