광고 전환 퍼널 점검, 끊긴 곳을 고쳐도 같은 절단이 되돌아온 이유

광고 클릭이 매출로 이어지지 않을 때 무엇이 끊긴 걸까?

광고 전환 퍼널 점검에서 가장 흔한 실수는 끊긴 지점을 하나씩 고치고 끝내는 방식이었습니다. 저희는 2026년 7월 20일 첫 점검에서 네 층의 절단을 모두 고쳤는데도, 같은 종류의 절단이 다음 서브도메인과 다음 키워드 그룹에서 다시 나왔습니다. 증상을 고치는 방식으로는 점검이 끝나지 않았다는 뜻입니다.

증상은 단순했습니다. 광고 클릭은 들어오는데 문의로 이어지지 않았습니다. 점검해 보니 끊긴 곳이 한 군데가 아니었습니다. 가격 층에서는 입찰가를 하한 기준으로 재서 경매에 참여하지 못하고 있었습니다. 키워드와 랜딩 페이지 사이에서는 노무 그룹에 세일즈 키워드가 섞여 검색 의도가 어긋나 있었습니다. 랜딩 페이지와 문의 폼 사이에서는 다른 도메인으로 가는 버튼, 메일 링크(mailto), 빠진 GA4 측정 태그가 나왔습니다. 마지막 배포 층에서는 코드를 합쳤는데 라이브 사이트에는 반영되지 않은 일이 있었습니다.

이 글은 그 네 층을 어떻게 찾았고, 왜 하나씩 고치는 방식이 실패했으며, 점검 단위를 무엇으로 바꿨는지 적은 기록입니다. 광고 대행사나 제작사에서 «끊긴 곳을 전부 찾아 고쳤습니다»라는 보고를 받아 본 적이 있다면, 그 보고가 어디까지 믿을 만한지 가늠하는 데 쓸 수 있습니다.

처음 의심한 것은 끊긴 지점 하나하나였다

처음 세운 점검 규칙은 이랬습니다. 절단점을 발견하면 바로 고치고, 다시 점검해서 새 절단점이 0건 나오는 라운드가 2회 연속 나올 때까지 반복한다. 발견의 단위도 수리의 단위도 끊긴 지점 하나였습니다.

이 규칙에는 합리적인 구석이 있습니다. 끊긴 곳이 눈에 보이면 고치는 편이 가장 빠르고, 0건 2회 연속이라는 종료 조건도 «이제 더 없다»를 확인하는 방법으로 그럴듯합니다. 그래서 저희는 처음 의심한 대로 «고쳐야 할 절단점이 아직 남아 있다»고 보고 점검을 돌렸습니다.

그런데 이 가설에는 반증이 따라왔습니다. 고친 뒤에도 새 절단점이 계속 나왔습니다. 의심은 두 갈래로 나뉘었습니다. 점검이 덜 꼼꼼해서 놓쳤는지, 아니면 점검 단위 자체가 잘못됐는지였습니다. 뒤의 두 절에서 이 둘을 차례로 따져 봅니다.

끊긴 곳을 어떻게 찾았나 — 8가지 점검 차원과 관측 수단

끊긴 곳을 찾으려면 먼저 어디를 볼지 정해야 합니다. 저희는 점검을 8개 차원으로 나눠 각각 다른 도구로 관측했습니다. 관측 수단이 달라야 한 가지 도구의 맹점을 다른 도구가 덮습니다.

여기서 쓴 도구는 특별하지 않습니다. 광고 채널이 공개한 API, 주소 응답을 보는 curl 명령, HTML 문자열 검색, 소스 코드 읽기, 배포 서비스의 상태 API가 전부입니다. 중요한 점은 차원을 8개로 고정해 두고 같은 칸을 매번 채웠다는 사실입니다. 점검자의 기분에 따라 보는 곳이 달라지면 0건이라는 결과를 믿을 수 없습니다.

관측하다 보면 도구 자체가 거짓말을 하는 자리도 만납니다. 바로 다음 절이 그 사례입니다.

curl로 본 화면은 정말 전부였을까?

77차 점검에서 저희는 한 랜딩 페이지에 문의 버튼이 없다고 단정했습니다. curl로 받은 HTML에 버튼이 보이지 않았기 때문입니다. 응답은 200이었고 페이지는 멀쩡히 떠 있었으니, 버튼을 빼먹은 듯했습니다.

이 판단이 틀렸습니다. 해당 페이지는 «use client»로 만든 화면이라 조건이 맞을 때만 버튼을 그렸습니다. curl은 서버가 처음 내려주는 HTML만 받습니다. 브라우저가 스크립트를 실행한 뒤에야 나타나는 버튼은 curl 화면에 원래 없습니다. 도구가 못 보는 것을 «없다»로 읽은 오진이었습니다.

curl은 초기 HTML만 본다. 소스 코드로 교차 확인.

이 일로 규칙 하나가 생겼습니다. 화면에서 무언가가 빠졌다고 말하려면 curl 결과만으로는 안 되고 소스 코드와 맞대 보아야 합니다. 4번 차원이 «조건부 렌더 함정»이라는 이름으로 표에 들어간 이유입니다.

같은 종류의 함정이 두 개 더 있었습니다. 첫째, 광고 API가 본문 없는 400 응답을 돌려줄 때입니다. 파라미터를 바꿔 가며 다섯 번 시도하는 것보다 응답 본문을 한 번 읽는 편이 빠르고, 본문이 빈 400은 주소 인코딩을 의심하라는 교훈이 남았습니다. 둘째, 네이버 통계 API는 캠페인 단위를 30일, 그룹과 키워드 단위를 약 3일만 보관합니다. 캠페인 합계와 하위 합계가 어긋나도 데이터가 틀린 것이 아니라 보관 기간이 다른 것입니다.

절단점을 고쳐도 같은 절단이 되돌아온 이유

앞의 가설에서 갈라진 두 의심 가운데 «점검이 덜 꼼꼼했다»는 쪽을 먼저 검증했습니다. 8개 차원을 고정해 두었고 curl 오진도 잡아냈으니 꼼꼼함은 이미 충분했습니다. 그런데도 절단은 되돌아왔습니다. 이 가설은 반증됐습니다.

남은 의심은 점검 단위였습니다. 끊긴 지점 하나를 고치면 그 지점은 막히지만, 그 지점을 끊기게 만든 이유는 그대로 남습니다. 다른 서브도메인이나 다른 키워드 그룹에서 같은 이유가 같은 절단을 다시 만들었습니다. 규칙은 0건 2회 연속을 요구했지만, 증상을 하나씩 지우는 방식으로는 0건이 오래 유지되지 않았습니다.

2026년 10월 3일, 이 반복을 본 대표가 점검 방식을 지적했습니다. 원문은 이렇습니다.

구조적 결함을 찾아서 설계를 고치는 방식으로 cut audit 을 하지 않으면 계속 이런 식의 문제가 발생한다.

이 지적을 받고 7월 20일의 네 층 절단을 다시 읽었습니다. 증상은 네 개였지만 원인으로 묶어 보니 질문이 바뀌었습니다. «무엇이 끊겼나»가 아니라 «무엇이 그것을 끊기게 만들었나»였습니다.

진짜 원인은 끊긴 지점이 아니라 끊기게 만든 구조였다

네 개의 증상을 구조 원인으로 다시 읽은 표가 아래입니다. 한 가지 단서를 먼저 적습니다. 오른쪽 칸의 재판정은 당시 기록 문구를 근거로 한 것이고, 코드를 열어 다시 확인하지는 않았습니다. 그래서 이 표는 확정이 아니라 점검 방식을 바꾸는 근거로만 썼습니다.

표를 가로로 읽으면 증상 네 개가 서로 달라 보이지만, 세로로 읽으면 같은 병이 반복됩니다. 같은 값이 여러 곳에 따로 박혀 있거나, 값을 정하는 주인이 없거나, 성공을 판정하는 기준이 없습니다. 이 셋이면 사람이 아무리 조심해도 다음 페이지, 다음 그룹에서 값이 어긋납니다.

퍼널에서 자주 나오는 구조 원인은 다섯 가지로 정리했습니다. 라우팅 기준 부재, 페이지별 수작업, 조건부 경로, 합침과 라이브의 불일치, 채널 집계 불일치입니다. 각각 점검자에게 던지는 질문이 하나씩 붙습니다. 예를 들어 조건부 경로에는 «전환 경로가 상태가 바뀐 뒤에만 존재하나, 그 경로를 정적 검사가 볼 수 있나»를 묻습니다. 앞에서 본 curl 오진이 바로 이 유형이었습니다.

구조 원인을 어떻게 고쳤나?

원인이 구조라면 수리도 구조여야 합니다. 새 규칙은 수리의 기본값을 «그 종류의 절단이 생길 수 없게 만드는 설계 변경»으로 바꿨습니다. 예외 하나, 특수 케이스 하나를 더 얹는 덧대기는 변경이 불가능한 사유가 있을 때만 허용하고, 그때도 그 원인은 열린 채로 남깁니다.

구체적인 수리 방향은 원인 유형마다 정해져 있습니다. 같은 값이 복제돼 있으면 단일 기준 출처 하나로 모으고 소비하는 쪽이 그것을 불러다 쓰게 합니다. 페이지마다 손으로 넣던 CTA와 태그는 공통 레이아웃으로 옮깁니다. 이미 실례가 있습니다. 키워드와 랜딩 연결을 한 곳에서 정하는 스크립트(ads_keyword_sot.py)를 만든 일이 «라우팅 기준 부재»를 설계 변경으로 푼 사례였습니다. 이후 광고 채널 콘솔에서 키워드를 직접 수정하지 않고 이 스크립트로만 운영합니다.

설계를 바꾼 뒤에는 앞서 덧댔던 임시 처방을 걷어냅니다. 새 구조가 이미 문제를 막고 있는데 예전 예외가 남아 있으면, 그 예외가 또 하나의 복제된 설정이 되기 때문입니다.

검증 방식도 바뀌었습니다. 개발 환경 통과는 라이브 통과가 아닙니다. 수리하면 라이브 주소를 다시 조회해 반영을 확인합니다. 합쳤으니 라이브일 것이라는 추정은 검증이 아니고, 배포 상태 API와 라이브 HTML 검색 둘을 모두 봅니다.

점검의 발견 보고 형식도 네 칸으로 고정했습니다. 구조 원인, 증상, 설계 변경안, 변경 불가 사유입니다. 이 네 칸이 모두 채운 보고만 발견으로 세고, 증상만 적은 보고는 세지 않습니다. 첫 라운드는 구조를 진단하는 라운드라 0건이 나와도 종료 판정에 포함하지 않습니다.

같은 실수를 막는 장치는 무엇인가?

재발 방지 장치는 네 개입니다. 사람의 주의가 아니라 구조로 막도록 짰습니다.

• 원인마다 «변경 후 0이어야 하는 신호»를 정해 주간 감사 스크립트(fleet_link_audit.py)에 넣는다. 고친 날 한 번 확인하고 끝내지 않고 매주 같은 질문을 던진다.
• 2라운드부터는 이전 수리 내역을 모르는 새 AI 에이전트(서브에이전트)에게 점검 차원을 병렬로 나눠 맡긴다. 직접 고친 자리는 통과 판정이 쉽고, 같은 렌즈로는 놓친 표면이 몇 번을 돌려도 보이지 않기 때문이다. 렌즈는 첫 라운드에서 고정하고 끝까지 같은 프롬프트를 쓴다.
• 신규 원인과 재개 원인의 합이 두 라운드 연속 줄지 않으면 멈추고 첫 라운드로 돌아가 구조 지도를 다시 그린다. 라운드를 더 돌리거나 상한을 두거나 기준을 낮추지 않는다.
• 종료 조건은 새 구조 원인 0건이 2회 연속 나오고 열린 원인이 0일 때뿐이다. 열린 원인이 남으면 «미종결 — 설계 이월»로 기록한다.

이 목록에서 둘째 장치가 가장 중요합니다. 같은 컨텍스트에서 돌린 0건은 깨끗함이 아니라 편향입니다. 점검자가 직접 고친 곳은 통과 판정이 후하고, 점검 렌즈가 놓친 곳은 같은 렌즈로 몇 번을 돌려도 드러나지 않습니다. 그래서 점검하는 쪽의 기억을 일부러 끊습니다. 다만 구조 지도는 새 에이전트에게도 건넵니다. 지도 없이 보내면 매번 처음부터 다시 그려야 해서 라운드마다 결과를 비교할 수 없습니다.

기록 방식도 정했습니다. 구조 원인 하나를 지식 기록 한 건으로, 점검 실행 한 번을 수렴 현황 표의 한 행으로 남깁니다. 다음 점검이 같은 원인을 새 원인으로 착각하지 않도록, 닫은 원인과 열린 원인을 기록으로 구분해 두는 것입니다.

전환 퍼널 점검을 맡길 때 확인할 것

광고 전환 퍼널 점검 결과를 받을 때, 보고서가 증상 목록인지 구조 진단인지부터 보면 됩니다. 증상 목록은 고치면 줄어드는 것처럼 보이다가 다음 달 다른 곳에서 다시 늘어납니다. 구조 진단은 어느 값의 주인이 없는지, 그 주인을 어디에 두었는지가 적혀 있습니다.

• 보고된 절단이 «이 종류의 절단이 어디서 또 생길 수 있는가»까지 적혀 있는가
• 같은 값(입찰가·랜딩 주소·CTA 목적지·GA4 ID·폼 주소)이 몇 곳에 따로 박혀 있는지 파일과 줄 번호로 나열했는가
• 화면 점검에 curl만 쓰지 않고 소스 코드로 교차 확인했는가
• 배포 확인이 «합쳤다»가 아니라 배포 상태와 라이브 HTML 둘로 이뤄졌는가
• 같은 점검을 다음 라운드에 이전 내용을 모르는 점검자가 다시 해도 0건이 나오는가

저희가 이 규칙을 쓰는 이유는 단순합니다. 클릭이 매출로 안 이어지는 이유를 한 번 찾아서 끝낼 수 있다면 좋겠지만, 실제로는 서브도메인이 늘고 키워드 그룹이 늘 때마다 같은 구조에서 같은 절단이 다시 나왔습니다. 퍼널 점검이나 광고 운영 구조에 막혀 있다면 상담으로 현재 퍼널의 구조 지도부터 같이 그려 볼 수 있습니다.

측정 전에 코드 값이 복제돼 있는지부터 확인하고 싶은 분께는 자동화 효과를 읽는 방법을 다룬 관련 글도 같은 관점에서 도움이 됩니다. 이 글은 SGK 스튜디오가 광고와 사이트를 직접 운영하며 남긴 점검 기록을 정리한 것입니다.