증상 — 클릭은 계속 나오는데 문의만 0건이었다
영업 메일을 자동으로 내보내기 시작한 뒤로 지표 하나는 꾸준히 움직였다. 사람들이 메일을 열었고, 본문 아래 링크를 눌렀다. 같은 문구를 쓴 발송 그룹에서 669통이 나갔고 그중 27건이 링크를 눌렀다. 비율로는 4.2%다.
문제는 그다음 층이다. 그 27건 가운데 상담 문의로 넘어온 사람이 한 명도 없었다. 기간을 30일 창으로 다시 잘라 봐도 그림은 같다. 열람 410건, 클릭 128건, 그 경로에서 나온 문의 0건.
이런 형태의 고장은 알아채기가 어렵다. 어딘가는 분명히 작동하고 있어서, 작동하지 않는 층이 눈에 안 띈다. 콜드메일 회신율이라는 축에서 보면 이 메일은 한 건도 만들어 내지 못했는데, 대시보드에는 매주 클릭이 찍혔다.
숫자를 그대로 말하면 이렇다. 우리가 지키고 있던 지표는 지금까지 단 한 번도 매출로 이어진 적이 없다. 0원짜리 지표였다.
처음 의심한 것 — 링크와 계측이 죽어 있다고 봤다
처음 세운 가설은 클릭 다음 층이었다. 메일이 열리고 링크도 눌리니 앞단은 멀쩡하고, 눌러서 도착하는 페이지나 그 페이지에서 다음 행동을 세는 계측이 고장 났다고 봤다.
근거가 없지는 않았다. 실제로 그 무렵 링크 쪽 결함을 둘 고쳤다. 하나는 메일 안 링크가 다른 주소로 걸려 있어 눌러도 접근 거부가 뜨던 문제였고, 하나는 클릭을 세는 경로가 세 갈래로 갈려 어느 값을 믿어야 할지 모르던 문제였다.
- 메일 본문 링크를 접근 거부가 나지 않는 주소로 전부 교체
- 클릭을 세는 세 경로를 실측으로 대조해 값 정정
- 착지 페이지 조회 신호를 새로 붙여 배포
가설이 맞다면 처방은 단순하다. 새는 층을 막고 다시 재면 뒷단 숫자가 따라 올라와야 한다. 세 가지를 다 고치고 나서 다시 쟀다.
미리 적어 두면, 이 세 가지를 고친 일 자체가 헛수고는 아니었다. 접근 거부가 뜨던 링크는 그 자체로 결함이었고, 세 갈래로 갈리던 클릭 값은 어느 숫자를 인용해도 틀릴 수 있는 상태였다. 다만 세 가지를 다 고친 뒤에 이 가설의 수명이 끝났다.
그 가설은 무엇으로 확인했나?
확인에 쓴 수단은 세 가지다. 셋 다 새로 만든 계측이 아니라 이미 돌고 있던 기록이다.
- 발송 기록 — 보낸 통수와 열람·클릭을 문구 그룹 라벨별로 나눠 센다
- 유입 목록 — 어느 경로로 들어온 문의인지 건별로 적어 둔 파일
- 단계별 퍼널 집계 — 클릭에서 진단 시작, 진단 시작에서 문의까지 층별 잔존
첫째로 발송 기록에서 같은 문구를 쓴 669통을 잘라 클릭 27건을 확인했다. 둘째로 유입 목록에서 이메일로 직접 들어온 문의 4건을 전부 열어 봤다. 셋째로 8월 13일에 한 번 잰 퍼널을 다시 꺼냈다.
유입 목록 4건은 전부 다른 경로였다. 상대가 먼저 보낸 문의가 있었고, 협업 제안이 있었고, 회사 공용 주소로 자동 등록된 항목이 있었다. 우리가 보낸 영업 메일에 회신해서 생긴 건은 하나도 없었다.
링크와 계측은 왜 범인이 아니었나?
고친 다음에도 숫자가 그대로였다. 이게 알리바이의 시작이다.
층을 하나씩 갈라 보면 반증이 더 분명해진다. 링크가 죽어 있었다면 클릭 자체가 안 잡혀야 한다. 그런데 30일 창에서 클릭 128건이 잡혔다. 메일이 전부 스팸함으로 갔다면 열람도 안 잡혀야 한다. 열람은 410건이었다.
계측이 없어서 못 보던 상황이라면, 세 경로를 정정하고 조회 신호를 새로 붙인 뒤에는 뭔가 하나쯤 떠야 한다. 아무것도 안 떴다. 계측을 고친 결과로 바뀐 값은 클릭 숫자의 정확도뿐이었고, 그 뒤 층은 0에서 움직이지 않았다.
결정적인 자료는 8월 13일 퍼널이었다. 클릭 24건 가운데 7건이 진단 화면까지 실제로 들어갔다. 링크가 깨져 있었다면 이 7이 나올 수 없다. 링크는 살아 있었고 페이지도 떴는데, 거기서 문의로 넘어온 사람이 0이었다.
다만 알리바이가 지운 후보는 링크와 계측 둘뿐이다. 명단이 어긋났을 가능성, 금액 문단이 안 먹혔을 가능성, 보내는 시각이 나빴을 가능성은 이 단계에서 하나도 지워지지 않았다. 그 후보들 가운데 아직 한 번도 안 건드려 본 축이 하나 있었고, 그게 요청 수였다.
여기서 첫 가설을 접었다. 클릭 다음 층을 아무리 손봐도, 클릭 자체가 매출로 이어진 적이 0건이면 우리가 지키던 지표는 수익 경로가 아니다. 링크 축을 계속 지키는 선택은 0원짜리 지표를 지키느라 한 번도 안 해 본 쪽을 계속 안 해 보는 선택이었다.
진짜 원인 — 한 통이 세 가지를 동시에 요구하고 있었다
가설을 접고 나서 메일 본문을 요청 단위로 세어 봤다. 지금까지 본문의 설득력만 봤지, 본문이 상대에게 시키는 행동이 몇 개인지는 세어 본 적이 없었다. 세어 보니 한 통에 셋이었다.
- 정정 — 틀렸으면 아니오 한 줄만 달라
- 클릭 — 아래에서 3분이면 확인할 수 있다
- 회신 — 한 줄만 회신해 달라
요청이 여럿이면 받는 쪽은 고르는 데 힘을 쓴다. 고르기가 막히면 기본 결과는 삭제나 보류다. 우리 숫자가 정확히 그 모양이었다. 셋 중 가장 부담이 적은 행동 하나만 살아남았고 그게 클릭이었다.
요청이 여럿일 때 선택이 막힌다는 판단은 우리 머리에서 나온 문장이 아니다. 메일 반응을 다룬 자료를 정리해 두면서 적어 둔 항목이었고, 정작 우리 본문에는 적용하지 않고 있었다. 자료에는 있는데 라이브 문구에는 없던 규칙을 이번에 처음 대조해 본 셈이다.
클릭 27건은 그래서 관심의 증거가 아니라 세 요청 중 제일 싼 선택지를 고른 흔적이다. 4.2%라는 비율은 성과가 아니라 회피의 크기였다. 그리고 그 선택지는 우리 쪽 매출과 연결된 적이 0건이다.
고친 방법 — 요청 하나만 남기고 나머지는 글자 그대로 뒀다
고친 내용 자체는 짧다. 발송 그룹 하나를 골라 요청 두 개를 지웠다. 라이브 문구 대비 4줄 삭제, 2줄 추가다.
지운 줄은 정정 요청과 링크 안내다. 새로 넣은 두 줄은 회신 하나만 남긴 문장이다. 이 업무에 주당 몇 시간이 들어가는지 한 줄만 회신하면 그 숫자로 다시 계산해 서면 진단을 보내겠다는 내용이다.
손대지 않은 자리가 더 중요하다. 금액을 다루는 문단과 절감을 보장하지 않는다고 밝히는 표시광고법 방어 문구는 기존 문구와 글자 그대로 같다. 바꾼 축이 요청 수 하나여야 나중에 판정이 선다.
적용 범위도 좁혔다. 새 문구는 발송 그룹 하나에만 들어가고 나머지 그룹은 예전 문구를 그대로 쓴다. 전부 갈아 치우면 대조군이 사라져 회신율 차이를 무엇에 돌려야 할지 알 수 없다.
그룹을 가르는 규칙은 발송 대상 이름을 해시로 바꿔 짝수 쪽만 새 문구로 보내고, 그중에서도 직원 수를 본문에 인용할 수 있는 곳만 남기는 방식이다. 사람이 고르지 않으니 좋아 보이는 회사만 새 문구로 몰릴 수 없고, 두 그룹의 명단 성격이 크게 갈리지도 않는다. 나머지 두 그룹은 본문 한 글자도 건드리지 않았다.
이 자리에서 기각한 대안이 셋이다.
- 전 그룹 교체 — 대조군이 사라져 회신율 차이를 귀속시킬 수 없다
- 링크는 두고 정정 요청만 제거 — 요청이 둘로 남아 요청 수 가설을 검증하지 못한다
- 다른 발송 건의 회신 창이 닫힐 때까지 대기 — 669건으로 이미 확정된 0을 다시 기다려 얻을 정보가 없고, 그동안 이 그룹은 계속 0원짜리 클릭만 생산한다
범인을 잘못 짚고 되돌린 사례는 이번이 처음이 아니다. 검색 노출이 떨어진 원인을 콘텐츠 중복으로 봤다가 입찰가로 바로잡은 노출 2.6에서 0.9로 떨어진 원인을 다시 잰 기록도 같은 자리에서 나왔다. 움직이는 중간 지표가 있으면 그 지표를 지키는 쪽으로 판단이 기운다.
판정 기준을 왜 켜기 전에 못 박았나?
문구를 바꾸기 전에 네 축을 먼저 확정했다. 표본이 얼마이고, 어떤 숫자면 채택이고, 어떤 숫자면 기각이고, 어떤 신호가 나오면 즉시 끄는지다.
이렇게까지 미리 적는 이유가 있다. 이 회사에서 2주 뒤에 애매하다로 끝나는 실패가 반복됐기 때문이다. 판정일도 2026년 9월 11일로 박아 뒀다.
기각 조건에는 다음 행동까지 붙였다. 회신이 0건이나 1건이면 원인이 문구가 아니라 명단이라는 뜻이므로, 문구를 더 만지지 않고 발송 대상 축으로 옮긴다. 기각이 아무것도 안 하는 상태로 끝나지 않게 하려는 장치다.
즉시 중단 조건은 반송률이다. 본문이 630자로 짧아지면 스팸 필터 반응이 달라질 수 있고, 그건 실측 전에는 모른다. 기존 문구 대비 2%p를 넘게 반송이 늘면 판정을 기다리지 않고 끈다.
판정을 흐릴 수 있는 요소도 미리 적어 뒀다. 예전 문구 라벨로 8월 27일에 379건이 한꺼번에 나갔고 그 회신이 아직 도착하는 중이다. 두 라벨의 회신이 시기적으로 겹친다는 뜻이라, 라벨을 안 갈라 뒀다면 나중에 어느 문구의 결과인지 따질 수 없었다.
그런데도 그 창이 닫히기를 기다리지 않았다. 예전 문구의 문의 0건은 669통으로 이미 확정된 값이라 더 기다려서 얻을 정보가 없고, 기다리는 동안 이 그룹은 계속 0원짜리 클릭만 만든다. 기다림의 비용이 정보의 값보다 컸다.
켰다고 켜진 게 아니었다 — 자동 발송이 읽던 폴더는 한 커밋 뒤처져 있었다
실험은 자동 발송 설정에 환경변수 한 줄을 붙여 켠다. 여기서 코드를 눈으로 읽고 끝내지 않고, 자동 발송과 같은 방식으로 실제로 돌려서 확인했다.
- 본문 생성 함수 호출 — 변형 이름이 회신 전용으로 바뀌고, 요청 목록에 회신 하나만 남고, 링크 버튼은 사라지고, 금액 문단은 그대로다. 본문 630자
- 같은 명령을 실전으로 실행 — 발송 큐 391행 가운데 178행이 새 변형으로 찍혔고 링크와 버튼은 0건
- 환경변수를 빼고 재실행 — 기존 문구로 되돌아온다
그 검증 중에 예상 못 한 결함이 하나 나왔다. 자동 발송이 도는 폴더가 원격 저장소보다 한 커밋 뒤처져 있었다. 그 상태에서 발송하면 496자짜리 옛 본문이 나간다.
문구 정정은 이미 병합해 뒀는데, 자동 발송은 병합 결과가 아니라 그 폴더를 읽는다. 최신 코드를 당겨오지 않았다면 정정 전 문구가 그대로 나갈 뻔했다. 당겨받아 해소했고, 교훈을 한 문장으로 남겼다.
기능을 켰다는 사실과, 그 코드가 자동 실행이 읽는 자리에 놓여 있다는 사실은 서로 다른 사실이다.
같은 실수를 막는 장치
이번 건에서 남긴 장치는 넷이다. 전부 사람의 주의력이 아니라 코드와 규칙 쪽에 걸었다.
- 요청 수를 세는 검사기 — 메일 본문에 행동 요구가 몇 개 들어갔는지 사람 눈이 아니라 코드가 센다. 이번 원인을 만든 조건이 다시 들어오면 검사기가 먼저 잡는다
- 라벨 분리 — 발송 기록이 기존 문구와 회신 전용 문구를 서로 다른 라벨로 저장한다. 전후 비교가 사후 해석 없이 성립한다
- 사전 판정 기준 — 표본과 채택과 기각과 즉시 중단 네 축을 켜기 전에 확정하고 판정일까지 적는다
- 되돌리기 한 줄과 백업 — 환경변수 한 줄만 지우면 원래대로 돌아가고, 설정 파일 292줄은 따로 떠 뒀다
여기에 하나를 더 붙였다. 자동 실행에 들어가는 변경은 켠 직후에 그 자동 실행과 같은 방식으로 한 번 돌려 본다. 상수를 눈으로 읽는 확인은 이번에 실패했다.
검사기를 사람 눈 대신 둔 이유도 같다. 이번 본문은 우리가 여러 번 읽고 고친 문구였는데도 요청이 셋이라는 사실을 아무도 세지 않았다. 읽어서 잡히는 결함이었다면 진작 잡혔을 것이다.
이 글은 성공 사례가 아니다. 지금 확정한 사실은 클릭이 매출로 이어진 적이 0건이라는 하나뿐이고, 요청을 하나로 줄인 문구가 회신을 만들어 내는지는 2026년 9월 11일에 판정한다. 기각으로 끝나면 그 결과도 그대로 적는다.
메일이든 광고든 클릭은 나오는데 문의가 안 붙는 상태라면, 문구의 설득력을 다듬기 전에 한 통 안의 요청 수부터 세어 보길 권한다. 우리가 무엇을 어떻게 재고 어디서 끊는지 궁금하다면 상담에서 이야기하면 된다.