단일 진실 공급원(SSOT)을 구축하는 방법: 전체 가이드

두 사람이 각각 스프레드시트를 열고 동일한 달의 매출을 보고하는데, 서로 다른 수치가 나옵니다. 두 사람 모두 신중하게 작업했고, 각자의 숫자가 맞다고 증명할 수 있습니다. 어느 쪽도 틀리지 않았습니다.

이는 데이터의 문제가 아닙니다. 데이터 문제의 탈을 쓴 '정의(definition)'의 문제입니다.

이를 해결하려는 대부분의 시도는 도구를 선택하는 잘못된 첫 단추에서 시작됩니다. 해결의 시작은 각 지표가 무엇을 의미하는지, 그리고 누가 이를 결정하는지 기록하는 것부터입니다.

이 가이드에서는 이 용어의 진짜 의미와 스프레드시트 작업을 시작하기 전에 내려야 할 네 가지 결정에 대해 다룹니다. 그런 다음 세 가지 수동 해결 경로와 각 경로가 한계에 부딪히는 지점을 살펴봅니다.

단일 진실 공급원(Single Source of Truth)의 진짜 의미

Workday의 SSOT 가이드에서는 이를 "모든 중요한 최신 비즈니스 데이터가 통합 및 정제되어 누구나 보편적으로 접근할 수 있도록 하는 중앙 집중식 시스템"으로 정의합니다.

하지만 같은 페이지의 뒷부분에 나오는 문장이 더 중요합니다. 단일 진실 공급원은 "기술 인프라 그 자체가 아니라, 기술 인프라를 올바르게 사용한 결과물인 경우가 많다"는 점입니다.

솔루션을 구매하기 전에 이 문장을 두 번 곱씹어 보세요. 데이터 웨어하우스는 저장 공간을 제공할 뿐입니다. 진실을 주는 것은 합의입니다.

해당 페이지에서는 수치가 일치하지 않는 근본적인 원인으로 데이터 사일로(data silo)를 꼽습니다. 데이터 사일로를 "서로 연결되지 않은 도구, 스프레드시트, 부서별 서버에 갇혀 고립된 정보의 풀"로 설명합니다. 권장하는 해결 순서는 플랫폼 도입이 아닌 거버넌스 구축부터 시작합니다. 즉, 용어를 정의하고, 담당자를 지정하고, 기술을 선택한 다음, 데이터를 정제하고, 단계적으로 배포하는 것입니다.

두 팀의 수치가 서로 다르게 나오는 이유

원인은 거의 항상 다음 네 가지 중 하나이며, 산수 오류인 경우는 없습니다.

서로 다른 필터. 한 보고서에서는 내부 계정과 테스트 기록을 제외하고, 다른 보고서에서는 이를 포함합니다. 아무도 이를 기록해 두지 않았기 때문에 아무도 눈치채지 못합니다.

서로 다른 시간 기준. 한 팀은 인보이스 발행일을 기준으로 한 달을 끊고, 다른 팀은 결제일을 기준으로 끊습니다. 둘 다 타당한 기준이므로 두 수치는 결코 일치할 수 없습니다.

서로 다른 분모. 비율에는 분자와 분모가 있습니다. 단 하나의 레코드도 변경되지 않더라도 분모(하단)를 바꾸면 백분율이 달라집니다.

서로 다른 데이터 추출 시점. 한 데이터는 1일에 추출했고 다른 데이터는 3일에 추출하여, 그 사이에 3일 치의 지연 데이터가 추가된 경우입니다.

가장 먼저 해결해야 할 네 가지 결정

수식을 건드리기 전에 이것부터 기록해 두세요. 수치 옆에 정의 탭을 만들어 두는 것은 가장 적은 비용으로 구축할 수 있는 훌륭한 거버넌스입니다.

결정 사항	답변해야 할 질문	중요한 이유
정의	이 지표의 1단위는 정확히 무엇을 기준으로 합니까?	분석 범위에 포함할 대상과 제외할 대상을 결정합니다
필터	어떤 레코드가 제외되며, 그 이유는 무엇입니까?	보통 수치 차이가 발생하는 가장 큰 원인입니다
기준 범위	기간을 구분하는 날짜 필드는 무엇입니까?	둘 다 타당한 선택지이지만, 서로 다른 결과를 낳습니다
담당자	이 정의의 변경을 승인하는 사람은 누구입니까?	담당자가 없으면 정의는 소리 없이 변질됩니다

담당자 지정은 팀들이 가장 자주 건너뛰는 부분입니다. 담당자가 없는 정의는 단순한 권장 사항에 불과하며, 권장 사항은 분기마다 자의적으로 재해석되기 마련입니다.

이를 현재 보고하고 있는 지표 레이어와 결합해 보세요. 모든 지표에 이 작업을 할 필요는 없으므로, 어떤 지표에 이 방식이 필요한지는 선행 지표와 후행 지표 가이드를 참고하시기 바랍니다.

수동으로 해결하는 방법

옵션 1: 두 버전을 한 줄씩 대조하기

이론적인 논쟁보다는 불일치하는 부분부터 시작하세요. 두 보고서를 하나의 통합 문서로 가져온 다음, 공통 키를 기준으로 XLOOKUP 함수를 사용하여 레코드를 매칭합니다.

매칭에 실패한 행들이 바로 단서입니다. 이 행들을 통해 한쪽에는 포함되고 다른 쪽에는 누락된 데이터가 무엇인지 알 수 있으며, 이것이 바로 아무도 기록하지 않았던 필터의 실체입니다.

이 작업을 할 때 유사한 중복 레이블을 주의 깊게 살펴보세요. EXACT 함수는 대소문자를 구분하여 두 텍스트 값을 비교합니다. 이를 통해 사람의 눈으로는 쉽게 놓치기 쉬운 "ACME Corp"와 "Acme Corp." 같은 쌍을 찾아낼 수 있습니다.

이 방법의 한계는 이번 한 달만 해결된다는 점입니다. 구조적인 변화가 없기 때문에 다음 달이 되면 동일한 두 보고서의 수치는 다시 어긋나게 됩니다.

옵션 2: 단일 데이터 세트를 구축한 후 모든 보고서 파생하기

먼저 통합하고, 그 다음에 보고하세요. Power Query의 병합 기능은 안티 조인(anti join)을 포함한 여러 조인 유형을 지원합니다. 안티 조인은 한쪽 원본에는 존재하지만 다른 쪽에는 없는 레코드 목록을 보여줍니다.

그런 다음 해당 단일 테이블에서 모든 하위 수치를 생성합니다. 이 테이블로 역추적할 수 없는 수치는 보고서에 올리지 않습니다.

조인 기준 키가 실제로 고유한지 확인하려면 UNIQUE 함수를 사용하세요. 키가 중복되면 합계가 소리 없이 부풀려지며, 눈에 띄지 않게 틀린 합계는 아예 오류가 나버리는 합계보다 훨씬 더 위험합니다.

이 방법의 한계는 유지보수입니다. 누군가 데이터를 계속 새로 고쳐야 하며, 그 담당자에게 의존하게 됩니다.

옵션 3: 수치 옆에 정의 탭 유지하기

지표당 한 행씩 작성합니다: 이름, 정의, 적용된 필터, 사용된 날짜 필드, 담당자, 최종 검토일.

이렇게 해야 다음 분기에도 보고서를 비교할 수 있습니다. 또한 "지난번 수치와 왜 다른가요?"라는 질문에 하루 종일 헤매지 않고 10초 만에 답변할 수 있게 됩니다.

한계는 정의를 적어둔다고 해서 그것이 자동으로 강제되지는 않는다는 점입니다. 정의 탭과 실제 수식은 서로 어긋나기 쉬우며, 실제로도 자주 어긋납니다.

공통적인 한계. 세 가지 옵션 모두 파일 내에서 불일치 원인을 찾아낼 수 있다는 전제하에 작동합니다. 두 부서가 완전히 다른 시스템을 사용하는 경우, 대조 작업은 비교 가능한 데이터를 내보내는 것부터 시작해야 합니다.

수동 방식이 한계에 부딪히는 지점

첫 번째 대조 작업은 흥미로울 수 있습니다. 하지만 세 번째가 되면 날짜만 바뀐 채 똑같은 오후 업무를 반복하는 지루한 작업이 됩니다.

비즈니스가 변할 때마다 정의는 낡은 것이 됩니다. 새로운 요금제 유형, 새로운 지역, 필드 이름 변경 등이 발생하면 지난 3월에 작성한 규칙은 9월의 데이터를 더 이상 제대로 반영하지 못합니다.

내보낸 데이터 파일 자체도 변합니다. 누군가 원본 시스템에서 필터를 변경하면, 새로 내려받은 파일은 겉보기에는 똑같아 보여도 실제로는 다른 의미를 담고 있게 됩니다.

또한 회의 중에만 드러나는 비용도 있습니다. 회의 현장에서 두 수치가 충돌하면 그 차이를 즉시 설명해야 하는데, 그 설명이 담긴 통합 문서를 미처 챙겨오지 못했을 수 있습니다.

이것이 바로 이 분야의 도구들이 존재하는 이유입니다. 데이터 팀 없이 비즈니스 인텔리전스를 구축하기 위한 AI 도구 모음에서 이 문제의 도구적 해결 방안을 다루고 있습니다.

Powerdrill Bloom으로 구축하는 방법

1단계: 불일치하는 두 데이터 파일 업로드하기

서로 일치하지 않는 두 파일을 함께 업로드합니다. Powerdrill Bloom은 파일이 업로드되는 즉시 열을 분석하므로, 합계가 계산되기 전에 일치하지 않는 키 형식, 일관되지 않은 레이블, 빈 필드 등을 미리 찾아냅니다.

2단계: 자연어로 정의 작성하기

규칙을 직접 구축하는 대신 말로 설명해 보세요. 지표 이름, 제외할 레코드, 기간을 구분할 날짜 필드, 그룹화 기준을 지정합니다.

그런 다음 수치 차이를 드러내는 질문을 던져보세요. 한 파일에는 있고 다른 파일에는 없는 레코드가 무엇인지 물어봅니다. 대소문자나 문장 부호만 다른 레이블이 무엇인지 물어봅니다. 그리고 각 날짜 기준에 따라 합계가 어떻게 달라지는지 물어봅니다.

3단계: 대조 완료된 보고서 내보내기

대조가 완료된 테이블, 차이 요약본 또는 합의된 정의가 수치와 함께 표시된 슬라이드를 내보냅니다.

수동 대조보다 이 방식이 더 나은 이유

	수동 방식	Powerdrill Bloom
일치하지 않는 레코드 찾기	파일 쌍마다 안티 조인 수행	누락된 레코드가 무엇인지 질문하기
유사 중복 레이블 감지	대소문자를 구분하는 보조 열 생성	업로드 시 즉시 감지
다른 기준 범위 테스트하기	필터를 다시 만들고 합계 재계산	다른 규칙을 말로 설명하고 질문하기
다음 달에 재실행하기	데이터를 새로 고치고 아무것도 바뀌지 않았기를 기도하기	규칙은 그대로 유지한 채 파일만 교체

세 번째 행이야말로 불필요한 논쟁을 끝내주는 핵심입니다. 두 가지 날짜 기준을 나란히 보여줄 수 있게 되면 "당신 숫자가 틀렸다"는 비난이 "서로 적용한 규칙이 다르다"는 생산적인 대화로 전환되어 문제를 해결할 수 있게 됩니다.

흔히 하는 실수들

정의에 합의하기 전에 플랫폼부터 구매하는 것. 저장 공간이 곧 합의를 의미하지는 않습니다. 먼저 용어를 정의하고 담당자를 지정하세요. 이 순서가 중요합니다.

분모를 명시하지 않는 것. 모든 비율 지표는 차트에 분자와 분모를 모두 표시해야 합니다. 그렇지 않으면 백분율은 그저 장식에 불과합니다.

한 번의 대대적인 통합을 최종 목표로 생각하는 것. 제품이나 조직이 변경되면 정의는 무용지물이 되므로, 매번 새로 구축하기보다는 정기적인 검토 일정을 잡으세요.

레이블이 동일하면 레코드도 동일할 것이라 가정하는 것. 대소문자, 문장 부호, 끝에 붙은 공백 등은 눈에 보이지 않는 중복을 만들어냅니다. 조인한 후가 아니라 조인하기 전에 확인하세요.

서로 다른 날에 추출한 데이터를 대조하는 것. 뒤늦게 입력된 데이터로 인해 수치 불일치가 발생할 수 있습니다. 행을 대조하기 전에 먼저 데이터 추출 타임스탬프를 맞추세요.

아무도 열어보지 않는 곳에 정의를 기록해 두는 것. 수치가 있는 동일한 파일에 정의를 보관하고, 차트에는 사용된 규칙을 명시하세요.

담당자 지정을 건너뛰는 것. 지정된 승인자가 없는 정의는 자의적으로 재해석되기 마련입니다. 모든 항목에 담당자를 명시하세요.

결론

단일 진실 공급원(Single Source of Truth)은 인프라보다 합의가 먼저입니다. 각 지표를 정의하고, 필터를 기록하고, 날짜 기준을 확정하고, 담당자를 지정한 다음, 하나의 데이터 세트에서 모든 보고서를 파생시키세요.

비용이 많이 드는 부분은 첫 번째 대조 작업이 아닙니다. 비즈니스가 계속 변화하는 과정에서 정의를 최신 상태로 유지하는 일입니다.

이러한 굴레 때문에 매달 말마다 시간을 허비하고 있다면, 불일치하는 두 파일에 Powerdrill Bloom을 사용해 보세요. 또한 스프레드시트로 KPI 대시보드 만들기 및 자체 데이터로 KPI 목표 설정하기 가이드도 참고해 보시기 바랍니다. AI data cleaning 페이지에서 준비 단계를 다루고 있습니다.

자주 묻는 질문 (FAQ)

단일 진실 공급원(Single Source of Truth)이란 무엇인가요?

모든 보고서가 파생되는 합의된 하나의 정의, 소스 및 계산 방식의 집합을 의미합니다. Workday의 가이드에서는 이를 인프라 자체라기보다는 인프라를 올바르게 사용한 결과물로 설명합니다.

이를 구축하려면 데이터 웨어하우스가 반드시 필요한가요?

아닙니다. 웨어하우스는 저장 공간과 확장성을 제공할 뿐이며, 수치를 일치시키는 것은 정의와 소유권에 대한 합의입니다. 소규모 팀은 잘 관리된 단 하나의 통합 문서만으로도 이를 실현할 수 있습니다.

두 보고서의 합계가 다르게 나오는 이유는 무엇인가요?

보통 필터, 기준 범위, 분모 또는 데이터 추출 타이밍 때문입니다. 계산 오류를 의심하기 전에 이 네 가지를 먼저 확인해 보세요. 산수 자체가 틀린 경우는 거의 없기 때문입니다.

지표 정의는 누가 담당해야 하나요?

지표당 변경 사항을 승인할 권한이 있는 한 명의 담당자를 지정해야 합니다. 공동 소유로 두면 부서마다 정의가 소리 없이 달라지는 경향이 있습니다.

정의는 얼마나 자주 검토해야 하나요?

비즈니스에 변화가 있을 때마다 검토해야 하며, 그렇지 않은 경우에도 정기적으로 검토해야 합니다. 새로운 요금제, 지역 추가, 필드 이름 변경 등은 작성 당시에는 맞았던 규칙들을 모두 무용지물로 만듭니다.