같은 질문에 부서마다 다른 숫자를 내놓는다
"지난달 매출이 얼마입니까"라는 질문에 세 부서가 세 개의 숫자를 가져오는 일은 생각보다 흔합니다. 영업팀은 주문일 기준 총액 12억 원을, 재무팀은 여기서 취소·환불 3%인 3,600만 원과 계열사 내부거래 2,000만 원을 제외한 11억 4,400만 원을, 마케팅팀은 정산일 기준으로 전월 말 주문을 당월로 옮긴 12억 3,000만 원을 제시합니다. 세 숫자 모두 계산 과정 자체는 틀리지 않았습니다. 틀린 것은 어느 것이 '매출'인지 합의된 적이 없다는 사실입니다.
공통 언어나 표준 없이 여러 분석 도구가 각자 지표를 내재화하면 이런 불일치는 필연적으로 누적됩니다. 결과적으로 대시보드를 더 만들수록 의사결정은 빨라지지 않고 숫자를 맞추는 검증 회의만 늘어나는 역설이 생깁니다. 대시보드가 40개인 조직에서 '활성 고객' 정의가 도구마다 조금씩 다르면, 40개 화면은 40개의 서로 다른 주장이 됩니다.
핵심 원인은 BI 도구의 성능이 아닙니다. '매출'과 '활성 고객'의 정의가 문서로도, 코드로도 어디에도 없다는 점입니다.
시맨틱 레이어가 실제로 하는 일
시맨틱 레이어는 비즈니스 로직을 한 번 정의해 조직 전체에서 재사용하는 계층입니다. 매출의 계산식, 제외 조건, 시점 기준을 한 곳에 선언하고, BI 화면·리포트·API·자연어 질의가 모두 그 정의를 참조합니다. 정의가 하나이므로 숫자도 하나가 됩니다.
최근 스노우플레이크의 시맨틱 뷰, 데이터브릭스의 비즈니스 시맨틱스처럼 데이터 플랫폼이 시맨틱 계층을 제품에 내재화하는 흐름이 뚜렷하고, 전용 시맨틱 레이어 제품에도 투자가 이어지고 있습니다. 지표 정의가 인프라 계층의 문제로 인식되기 시작했다는 신호입니다.
BI 도구에 계산식을 넣는 것과 시맨틱 레이어에 정의하는 것은 다릅니다. 전자는 특정 도구 안에서만 유효하고, 화면을 복제하면 정의도 복제됩니다. 후자는 도구 밖에 있으므로 버전 관리·코드 리뷰·테스트 대상이 되고, 도구를 교체해도 정의는 남습니다.
지표 정의서에 무엇을 적어야 하나
정의서는 장문의 설명서가 아니라, 한 지표당 한 페이지 수준의 표로 충분합니다. 다음 항목이 비어 있으면 그 지표는 아직 정의된 것이 아닙니다.
운영에서 더 중요한 원칙은 지표 수를 늘리지 말고 차원을 늘리는 것입니다. '모바일 신규 고객수', '앱 신규 고객수'를 각각 만들면 정의가 갈라집니다. '신규 고객수' 하나에 채널·기기·지역 차원을 붙이면, 지표 10개와 차원 8개로 80가지 질문에 답할 수 있습니다.
데이터 흐름을 어디까지 갖출 것인가
리포트가 운영 DB에 직접 붙는 구조는 초기에는 가장 빠르지만, 월말에 무거운 집계 쿼리가 동시에 돌면서 서비스 응답이 느려지는 사고로 이어집니다. 조회 시점마다 데이터가 변하므로 같은 화면을 두 번 열면 숫자가 달라지는 문제도 함께 옵니다.
소규모 조직이라면 데이터 웨어하우스 없이 읽기 전용 복제본과 집계 테이블만으로 시작해도 충분합니다. 다만 다음 신호가 보이면 분석용 저장소를 분리할 시점입니다.
적재 주기는 기술 사양이 아니라 업무 주기에 맞춥니다. 주간 회의용 지표라면 일 1회 적재로 충분하지만, 당일 재고나 광고비를 보고 판단해야 한다면 최대 24시간 지연은 쓸 수 없는 수치입니다. 화면에는 항상 "기준 시각"을 함께 노출해 신선도를 명시해야 합니다.
AI에게 물어보기 전에 필요한 전제
생성AI 에이전트가 사내 데이터에 질문을 받을 때, 엄선된 지식과 신뢰 기반 컨텍스트를 참조하도록 만드는 것이 시맨틱 계층의 역할입니다. 정의가 선언되어 있으면 모델은 계산식을 추측하지 않고 가져다 쓰므로, 환각이 줄고 같은 질문에 같은 답이 나옵니다.
반대로 정의가 없는 조직에 자연어 질의를 붙이면, 틀린 숫자가 더 빠르고 더 그럴듯하게 퍼지는 구조가 됩니다. 사람이 만든 오답은 회의에서 걸러지지만, AI가 즉시 낸 오답은 검증 없이 인용됩니다.
권한도 함께 내려가야 합니다. 지표 단위 접근 제어(인건비 지표는 특정 직급 이상)와 행 단위 제어(지점장은 자기 지점 데이터만)가 시맨틱 계층에서 적용되지 않으면, 자연어 질의가 권한 우회 경로가 됩니다.
3개월 안에 세우는 최소 구성
전사 데이터 거버넌스를 먼저 완성하려 하면 시작하지 못합니다. 순서를 좁히는 편이 현실적입니다.
POLYGLOTSOFT는 사내 시스템 구축과 ERP·결제·CRM 데이터 연계 개발 경험을 바탕으로, 지표 정의서 작성부터 계산 계층 구현과 리포팅 화면까지 한 번에 진행합니다. 특히 지표 정의는 한 번 만들고 끝나지 않고 사업이 바뀔 때마다 함께 바뀌므로, 구독형 개발 모델로 정의 변경과 화면 반영을 매월 이어서 처리하는 방식을 권해 드립니다. 지금 부서마다 다른 숫자로 회의 시간을 쓰고 계시다면, 현재 쓰는 리포트 목록만 가지고 상담을 요청해 주십시오. 어떤 지표부터 정의해야 하는지 정리해 드립니다.