콜드메일 발송량을 늘리기 전에 무엇이 문제였나?
콜드메일 발송량은 처음부터 문제가 아니었고, 문제는 메일을 누른 사람이 문의까지 오지 않는 데 있었습니다. 2026년 8월 13일 기준으로 영업 콜드메일은 클릭 61건까지는 만들었지만, 그 클릭이 상담 문의로 이어진 경우는 0건이었습니다. 끊기는 자리로는 클릭한 사람이 도착하는 안내 페이지가 지목됐고, 회사마다 문구를 바꾸는 개인화 페이지로 고친 뒤 클릭이 2배로 늘었다는 측정이 이미 나와 있었습니다.
그 상태에서 네 가지를 하루에 판정해야 했습니다. 첫째, 하루 발송 상한 100통을 올려도 되는가. 둘째, 이미 메일을 클릭한 회사(이 글에서는 “웜 후보”라고 부릅니다)에 다시 연락할 것인가, 한다면 누구에게 할 것인가. 셋째, 개발사에는 보내지 않는다는 규칙에 구멍이 있다는 제보가 들어왔는데 어디가 새는가. 넷째, 고친 안내 페이지의 개인화가 처음 보내는 메일과 재접촉 메일 양쪽 진입에 실제로 적용되는가.
발송량은 양날입니다. 많이 보내면 기회가 늘지만, 반송과 스팸 신고가 쌓이면 발신 도메인의 평판이 깎이고 그 뒤로는 정상 메일까지 스팸함으로 갑니다. 그래서 발송량은 단계적으로 늘립니다. 메일 업계에서는 이 과정을 웜업 또는 램프라고 부르고, 수신 서버의 스팸 필터가 새 발신자를 서서히 익히게 하는 데 목적이 있습니다. 우리 운영 규칙에도 “반송률·신고율 실측을 근거로 명시적으로 올린다”는 한 줄이 있었습니다.
처음 잰 숫자: 반송률 4.3%, 신고 0건, 누적 832통
측정은 발송 기록 파일에서 했습니다. 최근 30일 동안 나간 메일 가운데 반송으로 돌아온 비율, 수신자가 스팸으로 신고한 건수, 발송을 시작한 뒤 쌓인 누적 발송 수를 셌습니다. 결과는 반송률 4.3%, 신고 0건, 누적 832통이었습니다. 누적 832통은 단계적 증량을 이미 다 밟았다는 뜻이었고, 반송률 4.3%는 저희가 안전선으로 잡아 둔 8%의 절반 수준이었습니다.
클릭 쪽도 셌습니다. 클릭한 회사는 34곳이었는데, 그중 11곳이 발송 제외 목록에 걸려 다시 연락할 수 없는 상태였습니다. 제외 사유는 하나였습니다. “레퍼런스 없이 대기업에 들이밀지 않는다”는 대기업 상한 규칙입니다. 이와 별도로 대상을 고르는 단계에는 직원 50명, 매출 500억 원을 넘는 회사를 빼는 규모 필터가 있습니다.
개발사 필터 쪽 숫자는 사람 눈에서 먼저 나왔습니다. 재접촉 대상 목록을 훑던 대표가 (주)단군소프트를 찾아냈습니다. 저희는 홈페이지와 업무 자동화를 만들어 주는 쪽이라, 직접 개발 조직을 가진 소프트웨어 회사는 고객이 아니라 경쟁자에 가깝습니다. 그런데 이 회사는 개발사 필터를 통과해 목록에 올라 있었습니다. 직원 54명, 국민연금 기록상 업종 코드 722000, 포스트맨 파트너인 응용 소프트웨어 개발사였습니다.
처음에 세운 가설 세 가지
숫자를 보고 세운 가설은 셋이었습니다. 지금 돌아보면 셋 다 그럴듯했고, 그중 둘은 틀렸습니다.
- 발송량 가설: 반송률이 안전선의 절반이니 상한을 100통에서 200통으로 한 번에 올려도 된다.
- 대기업 가설: 대기업은 레퍼런스 없는 작은 스튜디오의 메일에 반응하지 않으니, 클릭한 회사라도 대기업이면 계속 막아 두는 편이 맞다.
- 필터 가설: 업종 코드(한국표준산업분류) 이름만 보면 단군소프트 같은 회사가 새니, 사업자등록의 업태·종목 문구까지 읽어 개발 흔적이 있으면 빼면 더 정확해진다.
세 번째 가설은 데이터가 받쳐 주는 듯했습니다. 저희가 쓰는 기업 데이터베이스는 21,961곳 가운데 18,325곳, 83%에 업태·종목 문구가 들어 있었습니다. 라벨 하나만 보던 필터에 문구라는 두 번째 층을 얹으면 빈틈이 줄어들 거라고 봤습니다.
첫 번째 가설은 숫자보다 원칙에서 먼저 막혔습니다. 한 번에 2배를 올리면 단계적으로 늘린다는 규칙의 취지와 맞지 않습니다. 스팸 필터가 발신자를 익히는 속도보다 발송량이 먼저 뛰기 때문입니다. 그래서 200 대신 150에서 멈추고, 2주 뒤인 2026년 8월 27일에 반송률과 신고를 다시 재서 200을 검토하기로 했습니다. 이 가설은 틀렸다기보다 판정을 미뤘습니다.
두 번째 가설 옆에는 대안도 함께 올라와 있었습니다. 웜 후보에게도 기존 상한을 그대로 두는 안입니다. 아무것도 바꾸지 않으니 위험이 없어 보였지만, 실제로 관심을 보인 회사를 버리는 선택이기도 했습니다. 판정은 클릭 날짜를 확인한 뒤로 미뤘습니다.
가설은 어디서 틀렸나?
대기업 가설은 날짜 하나로 무너졌습니다. 발송 제외 목록에 막힌 11곳의 클릭 날짜를 확인해 보니 전부 8월 7일 하루에 몰려 있었습니다. 그날은 규모 필터가 빠진 채로 대기업 묶음이 발송된 날이었습니다. 실수로 나간 메일이었지만, 대기업이 실제로 반응한 기록이기도 했습니다. 대기업은 반응하지 않는다는 전제로 세운 규칙이, 정작 대기업이 반응한 증거를 가리고 있었습니다.
대기업 상한 규칙이 막으려던 장면은 레퍼런스 없이 처음 보는 대기업에 들이미는 장면이었습니다. 이미 클릭으로 관심을 보인 회사에 다시 연락하는 장면에서는 그 사유가 사라집니다. 같은 규칙이 처음 보내는 메일에서는 맞고 재접촉에서는 틀렸습니다.
필터 가설은 직접 구현해 돌려 보고 나서야 틀린 줄 알았습니다. 업태·종목 문구에 “개발”과 소프트웨어 관련 단어가 함께 있으면 빼는 조건을 만들어 발송 후보 4,249곳에 적용했습니다. 추가로 빠진 회사는 108곳, 2.5%였습니다. 목록을 열어 보니 문구용 종이제품 제조사, 골판지 제조사, 부동산 임대사가 나왔습니다. 저희가 걸러 내려던 개발사가 아니었습니다.
“개발” 한 단어만 조건으로 쓰는 안은 더 나빴습니다. 제조업 업태에 흔한 “신제품 개발”이 전부 걸리기 때문입니다. 두 안 모두 저희가 가장 원하는 고객인 중소 제조사를 깎아 내고 있었습니다. 국민연금 업종 코드를 교차로 보는 안도 있었지만, 지금 데이터 원천에 없는 값이라 따로 모아야 했고 그 비용만큼 효과가 있는지 검증한 적이 없었습니다.
진짜 원인은 무엇이었나?
원인은 필터가 읽는 라벨과 회사의 실체가 서로 어긋난 데 있었습니다. 단군소프트의 업종 코드 이름은 “컴퓨터 및 주변장치, 소프트웨어 도매업”(G4651)이었습니다. 개발사 필터는 업종 코드 이름에 개발이나 프로그래밍 같은 낱말이 들어 있는지를 보는데, “도매업”이라는 이름은 그 낱말을 하나도 갖고 있지 않았습니다. 소프트웨어를 만들어 파는 회사가 업종 코드로는 유통사였습니다.
업태·종목 문구는 반대 방향으로 실체와 어긋났습니다. 한국 사업자등록의 업태·종목은 그 회사가 실제로 하는 일이라기보다 등록해 둘 수 있는 항목의 나열에 가깝습니다. “소프트웨어 개발, 공급” 같은 항목이 개발 조직 없이도 흔히 붙어 있습니다. 업종 코드는 너무 좁게 읽혀 개발사를 놓쳤고, 업태 문구는 너무 넓게 읽혀 제조사를 잡았습니다.
대기업 쪽도 구조가 같았습니다. 대기업이냐 아니냐는 라벨 하나로 판정하다 보니, 그 회사가 이미 클릭했다는 행동 기록이 판정에 끼어들 자리가 없었습니다. 정리하면 세 문제 모두 발송량과 무관했습니다. 누구에게 보내는가, 그리고 클릭한 뒤 무엇을 보여 주는가의 문제였습니다.
이런 어긋남은 오류 메시지를 내지 않습니다. 필터는 규칙대로 정확히 동작했고, 대기열은 매일 문제없이 만들어졌습니다. 단군소프트가 드러난 계기도 검사기가 아니라, 사람이 재접촉 목록을 직접 읽은 일이었습니다. 라벨로 거르는 필터가 맞게 돌고 있는지는 결과 목록을 사람이 열어 보기 전까지 알 수 없었습니다.
조치: 상한 150통, 재접촉 21곳, 필터 한 줄
조치는 갈래마다 되돌리기 쉬운 크기로 잘랐습니다. 발송 쪽 변경과 필터 변경은 서로 다른 변경 요청으로 나눠 따로 반영했습니다.
- 하루 발송 상한을 100통에서 150통으로 올렸습니다. 2주 뒤 반송률과 신고를 다시 재서 200을 검토합니다.
- 웜 후보는 대기업 상한을 풀었습니다. 발송 제외 목록에서 11곳을 지우지 않고 주석으로 막아 두어, 필요하면 한 줄로 되돌릴 수 있게 했습니다. 처음 보내는 메일로 대기업이 다시 섞여 드는 길은 직원 50명·매출 500억 원 규모 필터가 계속 막습니다.
- 재접촉 발송은 21곳으로 정하고, 2026년 8월 14일 오전 9시에 도는 예약 작업으로 걸었습니다.
- 수신거부를 한 1곳과 webmaster·privacy 같은 관리용 주소 3곳은 웜 후보여도 절대 제외로 남겼습니다. 관심 신호보다 법적 경계가 먼저입니다.
- 개발사 필터가 보는 낱말 목록에 “소프트웨어 도매업”을 추가했습니다. 컴퓨터 제조업은 정상 고객이라 그대로 두었습니다.
상한을 올리면 발송량만큼 평판 위험도 커집니다. 그 위험을 감수할 여유로 본 숫자가 반송률 4.3%, 안전선 8%의 절반이었습니다. 여유가 있어도 한 단계씩 올리면, 문제가 생겼을 때 어느 단계에서 생겼는지 가를 수 있습니다.
필터 수리는 단군소프트 한 곳만 빼는 방법도 있었습니다. 하지만 같은 G4651 코드를 가진 회사가 처음 보내는 메일 대기열에 12곳 더 있었습니다. 낱말을 추가하고 대기열을 다시 만들자 G4651 잔존은 0곳이었습니다. 개별 회사를 지우면 다음 단군소프트가 또 새고, 규칙을 고치면 같은 유형이 한꺼번에 빠집니다.
업태·종목 문구를 읽는 두 번째 층은 코드를 되돌리고 커밋하지 않았습니다. 대신 108곳 오탐 수치와 함께 기각한 이유를 설계 문서에 남겼습니다. 같은 아이디어가 몇 달 뒤 다시 떠올랐을 때 다시 구현하지 않게 하려는 기록입니다. 이 선택에는 대가가 있습니다. 업종 코드가 실체와 다른 개별 회사는 계속 통과할 수 있습니다. 저희는 오탐 108곳이 미탐 몇 곳보다 비싸다고 판단했습니다. 놓치는 고객 108곳은 매출 기회이고, 잘못 나간 메일 한 통은 부적합 발송 한 건입니다.
안내 페이지 쪽은 개인화를 모든 진입에 적용했습니다. “귀사”라는 말을 링크에 실려 오는 회사명으로 바꾸고, 담당자 수(1명·3명·5명·그 회사의 인원)에 따라 낭비 시간이 함께 늘어나는 표를 넣었습니다. 상담 신청 버튼은 다른 페이지로 넘기지 않고 그 자리에서 열리는 폼으로 바꿨습니다. 대표가 “이동시키지 말라”고 했고, 페이지를 옮길 때 생기는 이탈을 없애는 대신 폼 입력이라는 마찰을 하나 더하는 쪽을 택했습니다. 배포 뒤 라이브 페이지를 열어 회사명이 24번 들어가는지, 폼이 그 자리에서 뜨는지 확인했습니다.
변경 뒤에는 테스트도 맞췄습니다. 개발사 필터를 바꾼 직후 기존 테스트가 옛 규칙을 기대하고 있어 기본 브랜치에 빨간불이 들어왔고, 새 결정에 맞게 테스트를 고쳐 불을 껐습니다. 규칙을 바꾸는 결정은 테스트의 기대값까지 바꿔야 끝납니다.
다시 재 보니 결과는 어땠나?
2026년 8월 17일, 전체 발송 기록을 메일 한 통 단위로 다시 접어서 셌습니다. 같은 메일에 열람과 클릭 이벤트가 여러 번 찍히기 때문에, 메일 ID마다 가장 멀리 간 상태 하나만 남기는 방식입니다. 실발송 1,193건 가운데 배달 895건, 열람 177건, 클릭 56건, 반송 60건이었습니다. 8월 13일에 61건이던 클릭이 이 셈법으로는 56건이었습니다.
클릭 56건은 고유 회사 37곳에서 나왔습니다. 그리고 폼 문의는 0건이었습니다. 같은 기간 들어온 고유 리드 14건은 전부 검색과 광고에서 왔고, 콜드메일에서 온 리드는 한 건도 없었습니다. 클릭한 37곳에는 다국적 기업의 한국 지사가 섞여 있었고, 받는 주소는 customerservice@, webmaster@, info@ 같은 공용 메일함이었습니다. 받을 사람을 고르는 단계부터 정확하지 않았다는 신호였습니다.
같은 날 메일 본문 실험 결과도 나왔습니다. 발송 기록과 실험 기록을 메일 ID로 이어 붙여, 배달 기준으로 세 가지 본문을 비교했습니다.
직원 수를 인용한 v3 본문이 열람률 30.2%, 클릭률 7.5%로 가장 높았습니다. 다만 v3의 클릭은 4건뿐이라 순위만 읽고 효과 크기는 읽지 않았습니다. 그리고 세 본문 모두 문의는 0건이었습니다. 문구를 바꿔서 답할 수 있는 질문이 아니었습니다. 메일 클릭 수와 실제 사이트 방문 수가 어긋나는 문제는 이메일 클릭률과 GA4 방문 수의 차이에서 따로 다뤘습니다.
8월 13일 판단의 전제를 다시 짚어 보면, 안내 페이지가 끊기는 자리였고 그곳을 고치면 문의가 생긴다는 가정이었습니다. 클릭이 2배로 늘었다는 측정은 그 가정의 앞 절반만 확인했습니다. 나흘 뒤 숫자는 뒤 절반, 즉 클릭이 문의로 바뀐다는 부분이 성립하지 않는다고 말했습니다.
정리하면 발송량을 150통으로 올린 조치는 반송 쪽에서 사고를 내지 않았지만, 문의 0건이라는 본래 문제에는 손대지 못했습니다. 개인화 페이지도 클릭을 늘렸을 뿐 문의를 만들지는 못했습니다. 이 결과를 보고 첫 메일의 내용 자체를 바꾸기로 했습니다. “AI 자동화 해 드립니다” 같은 추상 제안 대신, 수신자가 자기 브라우저에서 30초 안에 확인할 수 있는 웹사이트 결함 1건을 첫 메일에 담는 방식입니다. 발송 대상 597개 도메인을 전수 검사했고, 그 과정에서 검사기가 틀리는 자리부터 걸러야 했습니다. 클릭한 회사 9곳에서 결함이 나왔는데 그중 3곳, 33%가 위양성이었습니다.
남는 한계
이번 기록에는 아직 닫히지 않은 칸이 여럿 있습니다. 숨기지 않고 적어 둡니다.
- 재접촉 21곳의 결과도 이 기록에는 없습니다. 발송 뒤에는 예약 작업을 지우고, 발송 기록과 대조해 누가 다시 반응했는지 추적하기로만 적혀 있습니다.
- 상한 200 재검토는 2026년 8월 27일로 잡았지만, 그 재측정 결과는 이 기록에 없습니다. 150통이 적정했는지는 아직 판정하지 못했습니다.
- 반송률 셈법이 하나로 통일되지 않았습니다. 2026년 8월 25일 다른 문서는 7월 20일~8월 24일 도달 11,367건 기준으로 오픈 22.2%, 클릭 5.3%, 반송 4.65%를 적었습니다. 메일 한 통 단위로 접은 1,193건과는 규모부터 다릅니다. 이후 “회신 초안 실적 수치가 발송량을 7배로 부풀렸다”는 수정 커밋이 들어갔습니다. 셈법을 하나로 맞추기 전에는 증량 전후 반송률을 나란히 놓고 비교할 수 없습니다.
- 안전선도 두 개였습니다. 증량을 판정할 때는 반송률 8%를 안전선으로 봤고, 2026년 8월 25일 문서는 자체 반송 기준을 5% 미만으로 적었습니다. 어느 쪽이 기준인지 한 곳에 정해 두지 않으면 같은 숫자로 다른 결론이 나옵니다.
- 업종 코드가 실체와 다른 회사는 여전히 통과할 수 있습니다. 이 잔여 위험은 발송 전 대기열을 사람이 훑어보고, 수신자 반응을 보는 방식으로 흡수합니다. 반대로 “소프트웨어 도매업” 낱말은 순수 소프트웨어 유통사까지 막습니다. 과하게 막는 쪽이 안전하다는 원칙에 따랐습니다.
- 재접촉한 대기업이 실제로 답하면, 지금 판매 서비스보다 큰 유지보수형 계약을 요구할 수 있습니다. 대기업 10곳이 응답하는 경우를 대비한 준비는 아직 없습니다.
콜드메일 발송량 상한은 무엇을 보고 올려야 하나?
콜드메일 발송량 상한은 반송률, 스팸 신고, 누적 발송 수 세 가지로 판정하고, 올릴 때는 한 번에 2배가 아니라 단계로 올리는 편이 안전합니다. 저희는 반송률 4.3%, 신고 0건, 누적 832통을 보고 100통에서 150통으로 올렸고, 다음 단계는 2주 뒤 같은 숫자로 다시 판정하기로 했습니다. 셈법은 미리 정해 둬야 합니다. 이벤트 줄 수로 세는지 메일 한 통 단위로 접는지에 따라 분모가 달라집니다.
다만 이번 기록의 핵심은 발송량이 아니었습니다. 클릭이 있는데 문의가 0건이면 더 많이 보내도 0건이 더 큰 분모 위에 놓일 뿐입니다. 그때 봐야 할 곳은 누구에게 보내는지를 정하는 필터와, 메일과 안내 페이지가 무엇을 약속하는지입니다. 필터를 고칠 때는 규칙을 머릿속으로 평가하지 말고 실제 후보에 돌려 빠지는 목록을 열어 보는 편이 빠릅니다. 이번에 업태 문구 필터를 기각한 근거도 그 108곳 목록이었습니다.
실수로 나간 발송도 데이터입니다. 8월 7일 대기업 묶음은 규칙을 어긴 발송이었지만, 그 덕에 대기업도 반응한다는 사실을 알았습니다. 실수를 덮기 전에 그 실수가 남긴 반응부터 세어 보길 권합니다.
라벨로 고객을 거르는 시스템이라면 라벨과 실체가 어긋나는 방향을 두 가지 다 확인해 보길 권합니다. 좁게 읽혀 새는 쪽과 넓게 읽혀 잘라 내는 쪽입니다. 영업 메일이나 문의 폼 흐름을 같은 방식으로 점검해 보고 싶다면 상담으로 남겨 주세요.