양면 시장에서 데이터를 신뢰한다는 것 — 정확한 숫자가 분쟁을 못 막던 날

정확한데도 안 믿는다

측정 파이프라인을 며칠 붙들고 노출 숫자를 0.1% 단위까지 맞춰 놓은 적이 있다. 로그를 다 뒤져 봐도 우리 집계는 정확했다. 그런데 그 주에 광고주는 "우리 MMP는 다른 숫자가 나온다"고 했고, 매체는 "우리 측정이랑 왜 다르냐"고 했다. 양쪽 다, 정확한 숫자를, 동시에 의심했다.

광고주: "노출 100만이라는데 진짜야? 봇 아니야? 우리 MMP는 다른 숫자인데."
매체: "우리 광고 자리에서 발생한 수익이 이거 맞아? 왜 우리 측정이랑 달라?"

처음엔 이걸 "신뢰 부족"이나 "측정 버그"로 봤다. 버그를 찾으러 들어갔다가, 찾을 버그가 없다는 걸 알고 나서야 다르게 보였다. 이 불신은 내 코드의 문제가 아니라 양면 시장의 구조적 특성이었다. 플랫폼이 양쪽 사이에서 숫자를 집계하는 한, 양쪽 다 자기에게 불리한 방향의 오차를 의심할 동기가 있다. 정확도로는 닿지 않는 영역이었다.

왜 구조적인가

일반 시장(예: 직접 판매)에서는 측정 주체가 하나다. 내가 파는 사람이고 내가 센다. 분쟁이 적다.

양면 시장에서는 플랫폼이 양쪽의 거래를 측정한다. 그리고 그 측정이 양쪽의 돈을 결정한다.

노출/클릭이 많이 집계되면 → 광고주가 더 낸다 (광고주는 적게 집계되길 원함)
노출/클릭이 많이 집계되면 → 매체가 더 받는다 (매체는 많이 집계되길 원함)

같은 숫자가 한쪽에는 비용, 다른 쪽에는 수익이다. 이해가 정반대다. 그래서 양쪽 다 "플랫폼 숫자가 상대방에게 유리하게 편향됐을 것"을 의심한다. 플랫폼이 아무리 정확해도 이 의심은 구조적으로 남는다.

그래서 신뢰를 따로 설계했다

버그가 없다는 걸 확인한 다음부터, 나는 측정 코드 대신 신뢰를 설계하기 시작했다. 정확해도 양쪽이 안 믿으면 거래가 멈춘다는 걸 분쟁 한복판에서 배웠기 때문이다. 다음 네 가지는 그렇게 하나씩 붙여 나간 장치들이다.

제3자 검증을 끌어들이기

플랫폼 자체 숫자만으로는 양쪽을 설득할 수 없다. 우리가 "정확하다"고 백번 말해도 이해가 반대인 쪽은 안 믿는다. 그래서 판단의 무게를 중립적 제3자로 옮겼다.

MMP(Mobile Measurement Partner): AppsFlyer·Adjust 같은 독립 측정
광고 검증: IAS·DoubleVerify 같은 viewability·fraud 검증
양쪽이 동의하는 중립 기준

플랫폼이 "우리가 정확하다"고 말하는 것보다, 양쪽이 동의한 제3자가 "이 범위 안"이라고 하는 게 신뢰를 만든다. 설득의 주체를 우리 자신에서 중립 기준으로 옮긴 것이다.

discrepancy를 버그가 아니라 정상으로 선언하기

처음 분쟁의 불씨가 됐던 게 이거였다. 플랫폼 숫자와 광고주 MMP 숫자는 항상 다르다. 측정 시점·기준·dedup이 다르니까. 그런데 이걸 "0% 일치"인 척 숨기면, 작은 차이 하나에도 "숫자 조작" 의심이 붙는다.

discrepancy 허용 범위를 사전 합의 (보통 ±10%)
그 범위 안이면 "정상", 벗어나면 조사
왜 다른지(측정 방법론 차이)를 문서로 공개

"다를 수 있다, 이 범위까지는 정상"이라고 먼저 말해 두면 신뢰가 오히려 올라간다. 숨기던 걸 먼저 꺼내 놓는 쪽이 더 신뢰받는다는 게 처음엔 직관에 어긋났다.

측정 방법론을 블랙박스에서 꺼내기

블랙박스 숫자는 불신을 키운다. 양쪽이 검증할 수 없는 숫자는 결국 안 믿는다. 그래서 각 지표가 어떻게 나오는지를 열었다.

노출은 언제 카운트되나 (서버 응답? 클라이언트 렌더? viewable?)
클릭 dedup 규칙은?
fraud 필터링은 어떻게?

방법론이 공개되면 양쪽이 "이 숫자가 어떻게 나왔는지" 직접 따라가 볼 수 있다. 검증 가능성이 신뢰의 기반이다.

기본값을 약한 쪽으로 두기

가장 의식적으로 결정한 게 이 부분이었다. 양면 시장에서 보통 한쪽(매체)이 약하다. 측정 방법론을 강한 쪽(광고주)에 유리하게 기본 설정하면 당장은 조용하지만, 약한 쪽이 장기적으로 플랫폼을 떠난다 — 그러면 양면 시장 자체가 무너진다.

fraud 필터링을 과하게 → 매체 수익 부당 감소
viewability 기준을 과하게 엄격 → 매체 노출이 집계 안 됨

기본값을 중립 또는 약한 쪽 보호로 두고, 강한 쪽이 더 엄격한 기준을 원하면 명시적으로 opt-in. 이게 양쪽 신뢰를 모두 유지하는 길이다.

무너지는 건 한순간이었다

이 네 장치를 붙여 신뢰가 자리 잡는 데는 수개월이 걸렸다. 일관된 정확성과 투명성을 한참 쌓아야 했다. 그런데 한쪽에 유리한 변경 하나를 조용히 내보낸 순간, 그 모든 게 흔들리는 걸 봤다. "플랫폼이 조작한다"는 인식이 한 번 박히면 그 뒤로는 멀쩡한 숫자까지 의심받는다. 그날 이후 나는 데이터 변경을 양쪽에 동시에, 같은 문장으로 공지하는 걸 원칙으로 굳혔다. 한쪽이 먼저 알면 다른 쪽은 자기가 늦게 안 만큼 의심한다.

측정과 신뢰는 다른 문제다

이 일을 겪고 나서 내 안에서 가장 크게 바뀐 건 문제를 보는 위치였다. 신입 때는 "정확하게만 측정하면 된다"고 생각했다. 그래서 분쟁이 나면 본능적으로 로그부터 뒤졌다. 그러다 찾을 버그가 없는 분쟁을 한 번 제대로 겪고 나니, 정확성은 필요조건이지 충분조건이 아니라는 게 보였다. 양쪽이 그 숫자를 믿고 거래하게 하는 일은 측정 코드 바깥에 있었다. 제3자 검증, discrepancy 선언, 방법론 공개, 약한 쪽 보호 — 전부 정확성 위에 따로 올려야 하는 레이어였다.

그래서 지금은 데이터 문제를 받으면 두 가지를 분리해서 본다. 숫자가 틀렸는가, 아니면 맞는데 안 믿기는가. 전자는 코드로 풀고, 후자는 설계로 푼다. 둘을 섞어서 코드만 붙들면 영원히 못 푼다.

결론

정확한 숫자를 만드는 건 절반이고, 양쪽이 그 숫자를 믿게 만드는 게 나머지 절반이다 — 나는 두 번째 절반을 직접 설계해 본 엔지니어다.

양면 시장에서 결정하기의 연장선이다. 거기서 "양쪽이 떠나지 않게 결정한다"였다면, 여기서는 "양쪽이 숫자를 믿게 설계한다"이다. 둘 다 양면 시장의 같은 구조에서 나온다 — 한쪽만 보면 다른 쪽이 무너진다.