Agency / 2026.07
Lead QA — 리드 납품 데이터의 마지막 관문
28컬럼 납품 양식 검증, 중복 탐지(hard/soft), 유효 CPA 집계를 한 흐름으로 묶었습니다. 납품 반려와 정산 분쟁을 코드로 예방합니다.
기획·검증 엔진 구현·테스트
Metrics
- 단위 테스트 97개
- 중복 탐지 2단계: hard(확정)/soft(사람 판단 회부)
- SheetJS raw:true 강제변환 버그 발견·수정 — 조용한 데이터 손상 차단
- 유효 리드 기준 CPA 자동 집계
Stack
Problem
광고로 수집한 리드는 광고주 양식(28컬럼, 상품·플랜코드 룩업, 채널 규칙)에 맞춰 납품됩니다. 검증이 눈검수에 머물면 형식 오류나 중복 리드가 납품 후에 발견되고, 반려·정산 분쟁으로 돌아옵니다. 리드 1건이 곧 매출 1건인 구조에서 품질 게이트가 사람 손에만 있었습니다.
Idea
납품 반려와 정산 분쟁을 사후 대응하지 말고, 실제 납품 양식의 규칙을 코드화해 출고 전 fail-closed 게이트로 만들자는 문제의식에서 출발했습니다.
Decision
납품 전 마지막 관문을 코드로 세웠습니다. 실양식의 채번·룩업·채널 규칙을 검증 룰로 옮기고, 중복은 확정 중복(hard)과 의심 중복(soft)으로 나눴습니다. 의심 건은 사람 판단으로 넘겼습니다. 자동화가 확신할 수 없는 것을 확신하는 척하지 않는 게 원칙이었습니다.
Outcome
납품 파일은 게이트를 통과해야만 나갑니다. 검증 과정에서는 엑셀 파서의 자동 형변환이 데이터를 조용히 손상시키는 결함을 발견해 수정했습니다. 눈검수로는 영원히 못 잡았을 종류의 버그입니다.
문제
리드 제너레이션 캠페인의 산출물은 클릭이 아니라 납품 파일입니다. 광고주 양식은 28컬럼입니다. 채널ID 고정값, 성별 코드, 종료일자 계산 규칙, 상품·플랜코드 룩업까지 규칙이 촘촘합니다. 이걸 눈으로 검수하다 틀리면 반려가 오고, 중복 리드가 섞이면 정산에서 분쟁이 됩니다.
결정
- 실양식을 해부해 룰로. 추정이 아니라 실제 납품 양식과 룩업시트의 규칙을 그대로 검증 코드로 옮겼습니다. 개인정보 실데이터는 어떤 단계에서도 사용하지 않았고, 규칙만 추출했습니다.
- 중복 탐지는 2단계. 완전 일치는 hard로 자동 차단, 유사 건은 soft로 표시해 사람 판단에 회부합니다. 도구가 애매한 것을 단정하면 그 자체가 새로운 리스크이기 때문입니다.
- 오류 보고는 사람의 언어로. “행 17: 연락처 형식” — 마케터가 엑셀에서 바로 찾아 고칠 수 있는 좌표로 알려줍니다.
성과
가장 값진 발견은 도구 자체가 아니라 파이프라인 깊은 곳의 버그였습니다. 엑셀 파서(SheetJS)의 기본 형변환이 특정 조건에서 값을 조용히 바꿔치기하고 있었습니다. 화면상 멀쩡해 보이는 데이터가 실제로는 손상된 상태였던 겁니다. raw 모드 강제로 수정하고 회귀 테스트를 남겼습니다. 눈검수 체제에서는 발견 자체가 어려웠을 결함이고, 이것이 “검증을 코드로 옮겨야 하는 이유”의 실증이라고 생각합니다.