BI 시스템의 세 가지 데이터 집계 오류

## BI 시스템이 거짓말하는 이유: 치명적인 데이터 집계 오류 세 가지

BI 도구의 메트릭은 종종 환상적인 정밀도를 보여줍니다. 실제로 데이터가 원시 거래에서 사전 집계된 마트로 옮겨가는 순간, 체계적인 왜곡이 나타납니다—때로는 수십 퍼센트에 이릅니다. 이것은 버그가 아닙니다; 속도와 정확성 사이의 아키텍처적 트레이드오프입니다. 분석을 의사결정에 위험하게 만드는 세 가지 주요 수학적 함정을 분해해 보죠.

오류 1: 평균의 평균 — 수학적 재앙

평균 영수증 금액, 평균 요청 처리 시간, 평균 주문 비용—이 메트릭들은 비가산적입니다. 이미 평균화된 값을 그냥 평균낼 수 없습니다. 전형적인 예: BI 시스템이 1월, 2월, 3월의 매장별 평균 영수증을 가져와서 더한 후 3으로 나누어 분기 수치를 계산합니다. 공식은 다음과 같습니다:

SELECT 
    region_name,
    EXTRACT(QUARTER FROM year_month) AS quarter,
    AVG(avg_receipt_amount) AS total_average_check
FROM dwh.store_monthly_aggregated
WHERE EXTRACT(QUARTER FROM year_month) = 1
GROUP BY region_name, EXTRACT(QUARTER FROM year_month);

문제는 A/B + C/D ≠ (A+B)/(C+D)입니다. 하루 10,000건 영수증을 처리하는 대형 마트가 50건인 키오스크와 같은 가중치를 받습니다. 매출 피크 월이 '죽은' 월과 동등하게 취급됩니다. 실제 데이터에서는 -6%에서 +7%까지 편차가 발생합니다. 평균 영수증이 1%포인트 증가할 때마다 수백만 루블을 의미하는 소매업에서 이런 왜곡은 용납될 수 없습니다. 최악은 분모의 우연한 일치로 올바른 결과가 나올 때—오류가 DWH에 '옳은' 것으로 굳어지는 것입니다.

오류 2: 필터 컨텍스트 변경 시 고유 건수 집계

고유 객체—고객, 영수증, 제품—를 세는 것은 상세 수준이 바뀔 때 무너집니다. 세 건의 거래를 상상해 보세요:

• 영수증 #101 | 식료품
• 영수증 #101 | 음료
• 영수증 #102 | 음료

실제 고유 영수증 수—2건. 하지만 카테고리별로 사전 집계된 데이터라면:

• 식료품: 1건 (#101)
• 음료: 2건 (#101, #102)

Power BI나 SQL 엔진에서 계층을 접으면 DAX가 단순 합을 합니다: 1 + 2 = 3. 고유성이 사라집니다. 시스템이 영수증 #101을 중복 집계한 겁니다. 이 오류는 평균 영수증, 전환율, LTV—고유 엔티티 수에 의존하는 모든 것을 즉시 왜곡합니다. 사용자는 뷰를 변경했다는 사실조차 모르고 가짜 숫자를 얻습니다.

오류 3: 반가산적 측정값과 경직된 달력

재고 잔고, 계좌 잔고, 활성 사용자 수—이것들은 스냅샷 메트릭입니다. 공간(매장, 지역)으로는 합할 수 있지만 시간으로는 안 됩니다. 이를 우회하기 위해 개발자들은 DAX의 LASTNONBLANK나 MDX의 NonEmpty 같은 함수를 씁니다:

Balance on konets perioda = 
CALCULATE (SUM('Inventory'[Balance]),
    LASTNONBLANK ('Calendar'[Date], 
        CALCULATE(SUM('Inventory'[Balance]))
    ))

이것은 세 가지 문제를 만듭니다:

• 성능: 엔진이 필터 변경마다 계층의 모든 날짜를 반복합니다. 대용량에서는 멈춥니다.
• 현실 실패: 30일에 POS가 데이터를 전송하지 못하면 31일 잔고가 0으로 보입니다. 수십만 루블어치 상품이 '사라집니다'.
• 코드 복잡성: 사용자가 개발자가 되어야 합니다. 여러 비즈니스 달력이 있으면 공식이 읽기 어렵고 취약해집니다.

중요한 점

• 집계는 정확성을 죽입니다. 속도를 위해 데이터를 미리 압축하는 것은 결과를 제대로 파악하지 않고 암묵적으로 받아들이는 트레이드오프입니다.
• 비가산적 메트릭은 원시 데이터가 필요합니다. 평균, 중앙값, 고유 건수—모두 전체 데이터셋에서 즉석 계산해야 합니다.
• 스냅샷 메트릭은 경직된 시간 경계를 용납하지 않습니다. 시스템이 현재 값을 유연하게 찾아야지 달력을 맹목적으로 따르지 말아야 합니다.
• BI 사용자는 DAX/MDX를 작성하지 말아야 합니다. 아키텍처가 복잡성을 숨겨야지 분석가에게 떠넘기지 말아야 합니다.
• 신규 플랫폼은 사전 집계를 버립니다. 원시 소스를 동적으로 연결하는 것이 수학적으로 정확한 분석의 유일한 길입니다.

패러다임 전환: 타협 없는 분석

전통 BI 시스템은 환상에 기반합니다: 비즈니스가 필요로 하는 모든 것을 미리 계산할 수 있다. 현실에서 비즈니스는 끊임없이 질문을 바꿉니다. DAX 우회책을 쓰는 대신 현대 플랫폼은 원시 데이터와 직접 작업합니다. 예를 들어 '재고 커버리지'—재고 대 매출 비율—을 계산할 때 수십억 행 재고와 수십억 행 영수증을 결합합니다. DWH에 경직된 마트를 구축하는 대신 시스템이 사용자 클릭마다 소스를 동적으로 연결해 메트릭을 수학적 정밀도로 재계산합니다. 코어가 시간 창을 결정하고 현재 재고 수준을 찾으며 필요한 데이터만 메모리에 로드합니다. 이것은 '더 빠른' 것이 아닙니다; '올바른' 것입니다. 은행 임원들이 평균 평균 왜곡 없는 진짜 요청 처리 시간을 처음 봤을 때 제대로 된 질문을 하기 시작했습니다. 소매 체인은 더 이상 500만 행 제한에 의미를 희생하지 않습니다. 분석은 JPEG가 아니라 RAW 파일이어야 합니다. 그래야 세부 사항과 통찰 정제가 보존됩니다. 기술은 존재합니다—이제 정신적 아키텍처를 재고할 때입니다.

— Editorial Team