PM이 데이터 정합성 문제를 정의하고, 측정하는 법
3월이 왔습니다. 벚꽃이 피면, 어김없이 2분기 과제 검토가 시작됩니다. 무엇을 할지 고르고, 왜 해야 하는지를 숫자로 만들고, 우선순위를 붙이는 작업입니다.
그 과정에서 언제 마주쳐도 골치 아픈 주제가 하나 있습니다. 데이터 정합성입니다.
중요하다는 건 다들 압니다. 문제는 그 다음입니다. “이 데이터 문제는 얼마짜리입니까?” 라는 질문 앞에서 막히는 경우가 많습니다. 잘못된 데이터가 잘못된 의사결정으로 이어졌고, 그게 실제 손실로 연결됐다는 걸 보여주는 연결고리를 보여주는 것이 쉽지 않습니다. 잘못된 의사결정이지만, 소 뒷걸음치듯 잘 풀리는 경우도 있고, 정확한 데이터가 정확한 의사결정으로 반드시 이어지는 것도 아니기 때문입니다.
과제 하나하나에 판단 근거와 비즈니스 타당성을 만드는 능력이 PM에게 중요해지는만큼, 관련 내용을 공부하고 정리해봤습니다.
조직에서 “데이터가 맞지 않는다”는 말은 생각보다 자주 들립니다. 그런데 이 한 마디 안에 성격이 전혀 다른 두 종류의 문제가 섞여 있습니다.
(1) 실제 데이터가 잘못된 경우
데이터 자체가 잘못 수집되거나 저장된 경우입니다. 보통 원인은 두 가지입니다.
하나는 사람의 실수입니다. 운영자가 상품 가격을 1,000원이 아닌 10,000원으로 잘못 입력하거나, 담당자가 수동으로 시트를 작성하다 행 하나를 빠뜨리는 것처럼, 데이터를 만드는 사람이 개입하는 모든 지점에서 발생합니다.
다른 하나는 시스템의 결함입니다. API 타임아웃으로 거래 데이터가 중간에 유실되거나, ETL 파이프라인이 중단되어 일부 레코드가 적재되지 않거나, 외부 시스템과 연동하는 과정에서 인코딩 오류로 값이 깨지는 경우들입니다.
(2) 거버넌스 이슈 - 보는 사람마다 기준이 다른 경우
보통은 이 유형이 훨씬 까다롭고, 케이스가 많은 것 같습니다. 데이터가 기술적으로 틀린 것은 아닌데, 팀마다 보는 숫자가 달라서 생기는 문제입니다.
가장 흔한 원인 중 하나는 지표 정의의 차이입니다. ‘월간 활성 사용자’를 A팀은 30일 내 로그인 기준으로, B팀은 30일 내 구매 기준으로 집계한다면, 두 팀은 같은 지표를 얘기하면서 완전히 다른 숫자를 보고 있는 겁니다. 예측 지표라면 문제는 더 심각해집니다. 무엇을 예측값으로 볼 것인지 합의가 없으면, 예측 정확도 논의 자체가 불가능해집니다.
적재 시점 정책의 차이도 있습니다. 주문이 ‘발생한 시점’을 기준으로 집계하는 팀과 ‘정산 완료 시점’을 기준으로 집계하는 팀은, 같은 날의 매출도 다르게 봅니다. 어느 쪽이 틀린 게 아닙니다. 단지 기준이 다를 뿐입니다. 그런데 이 차이를 명시하지 않으면, 매번 숫자를 맞추는 소모전이 반복됩니다.
거버넌스 이슈는 기술이 아닌 합의로 해결해야 합니다. 이해관계자를 모아 지표 정의에 합의하고, 그 결과를 문서화하여 단일 진실 출처(Single Source of Truth)를 만드는 것으로 해결할 수 있습니다.
물론 문제를 정의했다고 바로 과제로 만드는 건 아닙니다. 휴먼 에러가 날 가능성은 있더라도, 그걸 방지하기 위해 들어가는 리소스에 비해 임팩트가 너무 작다면 진행하지 않는 게 맞을 수 있습니다. 그래서 결국 측정이 필요합니다. 과제로 만들려면 숫자가 있어야 하고, 우선순위를 논하려면 규모를 알아야 하니까요.
그런데 데이터 정합성 문제는 측정이 유독 어렵습니다. 앞에서 다룬 것처럼, 데이터의 오류가 의사결정에 영향을 미치고, 그 의사결정이 결과로 이어지는 과정에서 수많은 변수가 끼어들기 때문입니다. 인과를 깔끔하게 분리하는 게 본질적으로 쉽지 않습니다.
그럼에도 같은 정합성 문제라도 상황에 따라 측정 가능한 문제로 접근해볼 수 있습니다. 아래는 그때 쓸 수 있는 비용 프레임워크입니다.
(1) 직접 비용 (Direct Cost)
데이터 정합성 문제로 인해 직접 발생하는 비용입니다. 가장 측정하기 쉬운 영역으로, 세 가지 항목으로 정리할 수 있습니다.
데이터 클렌징 비용: 잘못된 데이터를 수작업으로 정제하는 데 드는 인력 및 시간
시스템 복구 비용: 정합성 오류로 인한 다운타임, 롤백 작업, 재처리 비용
감사 및 검증 비용: 문제를 찾기 위한 데이터 감사, QA 시간
이 항목들은 작업 로그와 공수 추적으로 정량화가 가능합니다. 이 때 유용한 기준점이 하나 있습니다. Sirius-Decisions에서 제시한 1-10-100 룰입니다. 데이터를 입력 시점에 검증하면 건당 1달러, 사후에 정제하면 10달러, 아무것도 하지 않으면 100달러의 비용이 발생한다는 원칙입니다. 초기 검증 비용이 10배, 100배의 사후 비용을 막는다는 논리는, 경영진에게 데이터 품질 투자를 설득할 때 꽤 유효하게 씁니다.
(2) 간접 비용 (Indirect Cost)
직접 비용보다 측정이 어렵지만, 실제로는 더 큰 손실로 이어지는 영역입니다.
비효율적인 업무 프로세스 - 팀 간 숫자가 맞지 않아 회의마다 데이터를 재확인하고, 보고서를 올리기 전에 수동 검증을 거칩니다. 한 번은 별것 아닌 것 같지만, 조직 전체로 보면 상당한 낭비입니다. Gartner에 따르면 데이터 품질 문제는 전체 노동 생산성을 최대 20%까지 저하시킵니다.
컴플라이언스 리스크 - 잘못된 데이터를 기반으로 한 보고가 외부에 제출되거나, 개인정보 처리 이력이 부정확하게 관리되면 규제 위반과 과태료로 이어질 수 있습니다. 금융, 의료, 이커머스처럼 규제가 강한 도메인일수록 이 리스크는 커집니다. 보통 컴플라이언스 문제로 발생하는 과태료나 벌금 등의 발생가능한 예상 피해액은 정보보안 조직에서 산출해서 전달해줍니다.
고객 경험 저하로 인한 이탈 - 추천, 개인화, 알림 등 고객에게 직접 노출되는 기능이 잘못된 데이터를 기반으로 작동하면 경험이 나빠집니다. (식품/생활용품 이외 영역에서) 사용자에게 이미 구매한 상품을 반복 추천하거나, Frequency Capping 관리 실패로 하나의 고객에게 엄청나게 많은 메시지를 보내는 것이 대표적입니다. 이런 경우는 보통 수신 거부율 등 지표를 토대로 창출가능한 LTV의 손실 규모를 파악합니다.
그리고 간접 비용 중 가장 측정하기 어렵고, 동시에 가장 임팩트가 클 수 있는 영역이 있습니다. 잘못된 데이터가 의사결정에 직접 영향을 미친 경우입니다. 이건 단순한 업무 비효율이 아니라, 잘못된 전략 선택으로 이어지기 때문에 별도로 다룰 필요가 있습니다.
(3) 전략적 의사결정에 미치는 비용
모든 의사결정에는 근거가 된 숫자가 있습니다. 그 숫자가 잘못되어 있었다면, 결정 자체가 달라졌을 수도 있습니다. 그 손실을 어떻게 측정할 수 있을까요?
① 결정적 가정 역추적 (Critical Assumption Tracking)
의사결정의 근거가 됐던 숫자를 역으로 추적하는 방식입니다. 재고 관리 시스템에서 실제 재고가 500개인데 시스템에 800개로 표기되어 있었다면, 그 숫자를 근거로 발주를 줄이는 결정이 내려졌을 겁니다. 그 결정으로 생긴 재고 부족 비용과 기회비용을 역산하는 것이 이 방법의 핵심입니다.
② 가상 시뮬레이션 (What-If Analysis)
“만약 데이터가 정확했다면 우리는 어떤 선택을 했을까?”를 모델링하여 실제 결과와 비교합니다. 과거 의사결정 시점의 데이터를 정확한 값으로 교체하고, 동일한 결정 로직을 적용했을 때 어떤 결과가 나왔을지를 시뮬레이션합니다. 이 방식은 결정 로직이 명확히 정의되어 있어야 의미가 있습니다. 로직이 사람의 직관에 의존하는 경우엔 시뮬레이션 자체가 어렵습니다.
이처럼 의사결정에 대한 비용은 위와 같은 과정을 통해 (올바른 데이터 기반 최적 결정의 결과) − (잘못된 데이터 기반 실제 결정의 결과)로 보여줄 수 있습니다.
우리는 “데이터가 나빴다”는 진단에서 멈추지 않고, 그게 구체적으로 얼마짜리 문제였는지를 비즈니스 언어로 전환하는 것. 경영진에게 데이터 품질 투자를 설득할 때 가장 강력한 논리가 됩니다.
데이터 정합성 문제를 실제 측정가능한 과제로 올리고 평가하는 것은 쉽지 않습니다. 저 또한 완벽한 측정에 늘 어려움을 겪지만, 측정을 포기하면 문제는 과제화 시킬 수도, 다른 과제와 타당성을 놓고 검토하기도 어려워집니다. 그래서 오늘도 머리를 쥐어싸고 방법을 찾아보려합니다.
2분기 데이터 과제를 검토하고 있을 모든 PM들을 응원하며 글을 마칩니다. :)
참고 자료
Gartner, Measuring the Business Value of Data Quality (Ted Friedman, Michael Smith, 2011)
Knowledge Integrity, Evaluating the Business Impacts of Poor Data Quality (David Loshin)
180ops, Impact of Poor Data Quality on Business: Understanding Revenue Consequences
SiriusDecisions, 1-10-100 Rule