개인화 랜딩페이지 인원별 절감액 — 결론에서 1명으로 돌아간 논증

개인화 랜딩페이지는 무엇을 설득하려 했나

개인화 랜딩페이지는 방문자마다 내용을 바꿔 보여 주는 도착 페이지입니다. 이 페이지는 주소에 실린 회사명·업종·직원 수를 받아, 그 회사의 담당 인원을 기준으로 두 가지 숫자를 계산합니다. 하나는 반복 업무에 지금 새고 있는 돈이고, 다른 하나는 그 업무를 자동화했을 때 아끼는 돈입니다.

첫 버전 화면에는 다음 요소가 들어 있었습니다. 요소마다 인원을 얼마나 반영했는지가 이 글의 핵심이라, 첫 버전 상태를 그대로 적어 둡니다.

• 첫 화면(히어로)의 대표 금액 312만 원 — 어떤 인원 기준인지 적혀 있지 않았습니다.
• 인원별 규모 카드 — 1명·3명·5명 카드 뒤에 그 회사의 담당 인원 카드를 붙였습니다.
• ② 낭비 섹션 — 반복 업무에 새는 돈을 인원별 표로 보여 줬습니다.
• ③ 절감 섹션 — 자동화로 아끼는 돈을 1인 기준 값 하나로 보여 줬습니다.
• 회수 문구 — 구축비를 얼마 만에 되찾는지를 「본전입니다」라는 표현으로 알렸습니다.
• 사례 소개 할인율(10~20%)과 선택지 3개짜리 상담 폼이 마지막에 붙었습니다.

이 페이지가 설득하려는 논리는 한 줄입니다. 담당 인원이 많을수록 새는 돈이 크고, 자동화로 아끼는 돈도 커지므로, 같은 구축비를 더 빨리 되찾는다는 논리입니다. 숫자가 인원을 따라 커져야 이 논리가 섭니다.

그런데 2026년 8월 13일 첫 버전을 배포한 뒤 대표가 화면을 직접 검수하자, 인원을 따라 올라가던 숫자가 곳곳에서 1명 기준으로 되돌아가 있었습니다. 이런 어긋남은 계산 오류처럼 눈에 띄지 않습니다. 타입 검사도 빌드도 통과하고 화면도 멀쩡히 그려집니다. 다만 직원이 많은 회사의 담당자가 읽으면, 자기 회사 규모로 시작한 이야기가 결론에서 1명짜리 이야기로 끝나는 셈이라 앞에서 본 숫자까지 의심하게 됩니다.

처음 잰 숫자 — 검수 지적 6건과 추가 결함 2건

측정 방법은 단순했습니다. 대표가 배포된 화면을 처음부터 끝까지 읽으며 걸리는 곳을 짚었고, 그 지적을 코드에서 재현하는 과정에서 결함이 더 나왔습니다. 검수 지적 6건, 재현 중 추가 발견 2건, 합쳐 8건입니다.

여덟 건은 겉보기에 성격이 제각각입니다. 카드 배열, 문구 하나, 할인율 숫자, 폼 선택지, 빈 문자열 처리까지 섞여 있습니다. 하지만 검수 지적 6건 중 3건, 곧 인원별 카드와 첫 화면 금액과 ③ 절감 섹션은 같은 곳을 가리킵니다. 인원을 따라 커져야 할 숫자가 어딘가에서 1명으로 돌아간다는 지점입니다.

처음 세운 가설 — 인원 숫자를 몇 군데 바꾸면 개인화가 된다

첫 버전은 인원 개인화를 화면 부품(컴포넌트) 단위로 붙였습니다. 인원별 카드와 ② 낭비 섹션 표는 담당 인원을 받아 숫자를 바꿨고, 첫 화면 금액과 ③ 절감 섹션과 회수 문구는 인원과 상관없는 값을 그대로 썼습니다. 코드가 이렇게 짜여 있었다는 사실이 당시의 전제를 보여 줍니다. 인원이 드러나는 자리가 몇 군데만 있어도 방문자는 자기 회사 이야기로 읽으리라는 전제였습니다.

코드에서 읽히는 전제가 하나 더 있습니다. 1명 기준 숫자는 가장 작은 숫자라서 보수적이고, 보수적인 숫자는 안전하다는 전제입니다. 과장보다 축소가 낫다는 판단 자체는 틀리지 않았습니다. 문제는 그 보수적인 숫자가 논증의 어느 자리에 놓이느냐였고, 첫 버전은 그 자리를 따로 따지지 않았습니다.

가설은 어디서 틀렸나

틀린 자리는 논증의 끝이었습니다. 인원별 카드를 그리는 코드는 고정 배열 1·3·5 뒤에 그 회사의 담당 인원을 이어 붙였습니다. 담당 인원이 13명이면 카드는 1명·3명·5명·13명으로 커지며 끝납니다. 하지만 인원 정보가 없어 담당 인원이 1명으로 잡히면 카드는 1명·3명·5명·1명이 됩니다. 올라가던 규모가 마지막 카드에서 처음 숫자로 되돌아갑니다.

같은 숫자가 두 번 들어가면 문제가 하나 더 생깁니다. React는 목록 항목을 key 값으로 구분하는데, 담당 인원이 고정 배열의 숫자와 겹치면 같은 key를 가진 카드가 두 장 생깁니다. 화면 논리의 역행과 렌더링 버그가 같은 한 줄에서 함께 나왔습니다.

③ 절감 섹션도 같은 방향으로 틀렸습니다. 바로 앞 ② 낭비 섹션은 인원별 표로 새는 돈이 인원을 따라 커진다고 보여 주는데, ③은 1인 기준 값 하나만 보여 줬습니다. 새는 돈은 13명 기준으로 보여 주고 아끼는 돈은 1명 기준으로 보여 주면, 인원 축은 논증의 절반에서만 작동합니다.

회수 문구에서는 같은 실수가 한 번 더 나올 뻔했습니다. 고치는 과정에서 1명·3명·5명일 때 각각 몇 년 만에 구축비를 되찾는지 숫자 예시를 붙이는 안이 있었습니다. 그런데 직원이 13명인 회사 페이지 아래에 「1명이면 1.9년」 같은 문장이 붙으면, 대표가 지적한 역행이 결론부에서 그대로 다시 나타납니다. 보수적인 숫자가 결론 자리에 오면 신중함이 아니라 후퇴로 읽힌다는 사실이 이 대목에서 드러났습니다.

정리하면 가설은 두 군데서 틀렸습니다. 인원을 몇 군데만 반영해도 된다는 전제는 ③ 절감 섹션에서 깨졌고, 1명 기준 숫자가 어디서나 안전하다는 전제는 카드의 마지막 자리와 회수 문구에서 깨졌습니다.

진짜 원인 — 인원 축이 논증 사슬의 일부에만 걸려 있었다

여덟 건을 다시 묶어 보면 원인은 두 갈래입니다. 첫째는 논증 설계입니다. 이 페이지의 설득은 새는 돈에서 아끼는 돈으로, 아끼는 돈에서 회수 기간으로 이어지는 사슬입니다. 인원 축은 이 사슬의 고리마다 걸려 있지 않고 일부 부품에만 붙어 있었고, 고리 하나가 1명 기준으로 남으면 그 자리에서 규모 논증이 끊겼습니다.

둘째는 기본값 처리입니다. 업종을 판별하지 못한 방문자는 기본 그룹으로 떨어지는데, 이 그룹의 이름이 빈 문자열이었습니다. 자바스크립트에서 빈 문자열은 거짓으로 취급하므로 `grp.label || companyName` 은 업종 이름 대신 회사명을 돌려줍니다. 그래서 업종 이름이 들어갈 자리에 회사명이 찍혔습니다.

회사명을 모르는 진입에서는 호칭이 「귀사」로 떨어졌습니다. 두 결함 모두 정보가 부족한 방문자에게 개인화가 가장 어색하게 드러나는 자리에서 났습니다. 개인화 랜딩페이지는 정보가 다 갖춰진 방문자보다 정보가 빠진 방문자 쪽에서 더 쉽게 티가 납니다.

두 갈래 모두 컴파일러와 빌드는 잡지 못합니다. 타입은 맞고 화면은 그려지며, 첫 버전도 그 상태로 배포까지 갔습니다. 숫자가 논증 안에서 어느 방향으로 움직이는지는 사람이 처음부터 끝까지 읽어야 보였습니다.

무엇을 어떻게 고쳤나

고친 범위는 파일 2개, 추가 109줄·삭제 38줄입니다. 핵심은 인원 축을 논증의 모든 고리에 거는 일이었고, 기본값 처리 두 곳을 함께 손봤습니다.

• 카드 배열에서 중복을 없애고 숫자 오름차순으로 정렬했습니다. 담당 인원이 고정 숫자와 겹치면 카드가 한 장으로 합쳐지고, 그 회사의 카드는 브랜드 색으로 강조합니다.
• 첫 화면 금액 옆에 기준 문구 자리를 새로 만들었습니다. 담당 인원이 1명이면 「가장 보수적인 기준」, 2명 이상이면 「담당 N명·반복 업무 1개 기준」이라고 적습니다.
• ③ 절감 섹션에 ② 낭비 섹션과 같은 인원별 절감액 표를 넣었습니다.
• 「본전」을 「회수」로 바꾸고, 회수 기간이 1년 미만이면 개월로 환산해 보여 줍니다.
• 구축비와 인원의 관계를 한 문장으로 새로 적었습니다(아래 인용).
• 사례 소개 할인율 표기를 10~20%에서 37~49%로 올렸습니다. 실제로 집행한 계약 한 건의 할인율 37.9%가 근거입니다.
• 상담 폼 선택지를 3개에서 4개로 늘렸습니다(「기타」 추가).
• 업종 기본 그룹의 이름을 빈 문자열에서 「동종」으로 바꿨습니다. 회사명 자리는 `{company:폴백}` 처럼 기본값을 문구 안에 함께 적는 문법으로 바꿔 「귀사」 노출을 없앴습니다.

첫 화면 기준 문구는 숫자를 줄이지 않고 숫자의 범위를 밝힙니다. 「담당 N명·반복 업무 1개 기준」은 이 금액이 그 회사 담당 인원이 반복 업무 한 가지만 자동화했을 때의 값이라는 뜻입니다. 인원 정보가 없는 방문자에게는 「가장 보수적인 기준」이라고 적어, 1명 기준 숫자가 결론이 아니라 하한이라는 점을 드러냈습니다. 같은 312만 원이라도 기준이 붙기 전에는 단정이고, 붙은 뒤에는 조건이 달린 추정입니다.

「본전」을 바꾼 이유는 어감입니다. 본전은 들인 돈을 겨우 되찾는다는 말이라, 도입을 검토하는 사람의 기대치를 먼저 낮춥니다. 회수는 같은 사실을 투자의 언어로 옮긴 말입니다. 1년 미만을 개월로 환산한 이유도 비슷합니다. 소수점이 붙은 연 단위보다 개월 수가 한눈에 읽히기 때문입니다.

구축비는 인원 수와 무관, 시스템 한 벌 처리량엔 인원 상한 없음 — 담당 2배면 절감 2배·회수 절반

이 문장이 논증의 빈 고리를 메웁니다. 구축비는 시스템 한 벌 값이라 담당 인원이 늘어도 그대로이고, 그 시스템이 처리하는 양에는 인원 상한이 없습니다. 그러면 인원이 늘수록 구축비는 고정인데 절감액만 커지므로, 회수 기간은 인원에 반비례해 짧아집니다. 첫 버전이 결론에서 1명 기준으로 내려앉던 자리에, 인원이 클수록 유리하다는 방향을 문장으로 못 박아 둔 셈입니다.

이 문장에는 숫자 예시를 일부러 넣지 않았습니다. 1명·3명·5명의 회수 기간을 나란히 적으면 구체적이긴 하지만, 인원이 큰 회사 페이지에서 결론이 다시 최소 인원으로 내려앉습니다. 구체성을 조금 잃는 대신 논증의 방향을 지켰습니다.

기각한 대안이 하나 더 있습니다. 첫 화면 금액을 인원과 상관없이 312만 원으로 고정하는 안입니다. 방문자의 직원 수를 이미 알고 있는데 그 정보를 버리면 개인화 전체가 의미를 잃기 때문에 채택하지 않았습니다. 사례 할인율 조정은 실제 집행 근거가 있어서 따로 저울질할 거리가 없었습니다.

재측정 결과 — 서버 렌더링 3가지 진입 경우

고친 뒤에는 타입 검사(`tsc --noEmit`)와 운영 빌드(`next build`)를 통과시킨 다음, 운영 모드로 서버 렌더링한 HTML을 세 가지 진입 경우로 받아 문자열을 셌습니다. 세 경우는 주소 파라미터가 없는 진입, 직원 126명 진입, 직원 30명 진입입니다. 마지막 경우는 이전 코드에서 같은 인원 카드 중복이 재현되던 조건입니다.

네 숫자가 모두 기대한 값으로 나왔습니다. 그래도 재측정은 여기서 끝내지 않았습니다. 페이지 안의 논증을 고쳤으니, 이 페이지에 실제로 도착하는 방문자가 얼마나 되는지도 재야 했습니다. 공들여 고친 개인화 랜딩페이지도 방문자가 오지 않으면 효과가 0이기 때문입니다.

개인화 페이지는 방문자 몇 %에게 닿고 있었나

다음 날인 2026년 8월 14일, 이 개인화 페이지가 모든 메일 경로에 적용돼 있는지 확인했습니다. 이미 관계가 있는 상대에게 보내는 메일은 100%가 개인화 페이지로 향했습니다. 반면 처음 연락하는 콜드메일은 29%만 개인화 페이지로 갔고, 나머지 71%인 424건은 예전 자가진단 페이지로 향하고 있었습니다.

여기서 처음 내놓은 설명은 틀렸습니다. 사내 설계 문서에 A/B 테스트 대조군 설계가 적혀 있었기에, 71%는 비교 실험을 위해 일부러 남겨 둔 대조군이라고 답했습니다. 대표가 한 줄로 되물었습니다.

A/B 테스트를 위해서라는 거야?

다시 확인하자 반증이 두 방향에서 나왔습니다. 하나는 실험 설계입니다. 그 콜드메일 실험이 판정하는 지표는 메일 열람 대비 클릭률이었고, 클릭은 방문자가 도착 페이지에 닿기 전에 이미 확정됩니다. 도착 페이지를 바꿔도 그 실험은 흔들리지 않으니, 개인화 적용을 미룰 이유가 처음부터 없었습니다.

다른 하나는 기록입니다. 링크를 개인화 페이지로 옮긴 이전 커밋의 메시지는 발송 갈래 하나만 옮겼다고 명시하고 있었습니다. `git log -S` 로 코드 변경 이력을 뒤져도 나머지 갈래를 대조군으로 설계했다는 흔적은 어디에도 없었습니다. 대조군 설계라는 설명은 문서의 다른 절을 끌어와 붙인 사후 해석이었습니다.

고친 내용은 세 가지입니다. 링크 주소를 개인화 페이지로 바꾸되, 캠페인 추적 태그(utm_campaign)는 그대로 둬 분석 도구(GA4)에서 실험 갈래를 계속 구분할 수 있게 했습니다. 링크를 만들 때 업종 그룹과 회사명 파라미터도 함께 넘기게 했습니다. 이전에는 이 두 값이 빠져 있어, 이 경로로 들어온 방문자는 앞에서 본 「귀사」 화면을 봤습니다. 버튼 문구는 「3분 자가진단 보기」에서 「3분 진단 결과 보기」로 바꿨습니다. 도착 화면이 진단 도구에서 결과지로 바뀌었기 때문입니다.

진짜 대조군은 손대지 않았습니다. 다른 비교 실험에서 기준으로 쓰는 243건은 예전 페이지로 그대로 보냈습니다. 발송 대기열 955건을 다시 생성해 세어 보니, 원래 개인화 페이지로 가던 288건과 새로 옮긴 424건을 합쳐 712건이 개인화 페이지로 향했습니다. 콜드메일 개인화 적용률은 29%에서 74%로 올랐습니다.

발송 스크립트 테스트는 463개가 통과했습니다. 실패한 4건은 이 변경과 상관없이 기본 브랜치에서도 똑같이 실패하던 기존 테스트였습니다. 페이지 안의 논증을 고친 작업과 페이지로 가는 길을 고친 작업이 같은 「귀사」 결함에서 만났다는 점이 이 재측정에서 얻은 수확입니다.

남는 한계

첫째, 페이지 수정은 그날 운영 서버에 올라가지 못했습니다. 코드는 머지했지만 호스팅 서비스 Vercel 무료 플랜의 하루 배포 한도 100건을 이미 넘긴 상태라 배포가 반영되지 않았고, 한도가 풀린 뒤 다시 배포해야 했습니다. 머지와 배포 사이에 이런 틈이 있으면, 코드에서는 고친 결함이 방문자 화면에는 한동안 그대로 남습니다.

둘째, 사례 소개 할인율 37~49%의 하한은 실제 계약 한 건의 37.9%에 기대고 있습니다. 표기를 실제 집행에 맞췄다고 해도, 근거로 남은 사례가 한 건뿐이라는 사실은 그대로입니다.

셋째, 회수 기간 숫자 예시를 뺀 대가로 구체성이 줄었습니다. 담당 인원이 2배면 절감도 2배, 회수 기간은 절반이라는 비례 문장은 논증의 방향을 지키지만, 자기 회사 숫자를 바로 대입해 보고 싶은 방문자에게는 계산 한 걸음이 더 남습니다.

넷째, 이번 결함 8건 가운데 6건은 사람이 화면을 읽어서 나왔고, 나머지 2건도 그 지적을 코드에서 재현하다가 나왔습니다. 타입 검사와 빌드는 첫 버전도 통과했습니다. 논증의 방향처럼 컴파일러가 모르는 성질은 지금도 읽는 사람이 확인해야 하고, 이를 자동으로 잡는 검사는 아직 없습니다.

절감 숫자 자체를 어디까지 믿을 수 있는지는 AI 업무 자동화 절감 시간을 실측과 추정으로 가른 기록에서 따로 다뤘습니다. 개인화 랜딩페이지나 업무 자동화 절감액 계산을 설계하면서 숫자와 논증을 함께 점검하고 싶다면 상담에서 이야기할 수 있습니다.