같은 지표에 대한 세 가지 알고리즘: 기준 사전, 버전 고정, 데이터 추출 감사 어떻게 할 것인가

경영에서 가장 난처한 상황: 영업팀은 대금이 입금됐다고 하고, 재무팀은 아직 안 들어왔다고 하며, 운영팀은 세 번째 표를 꺼내들어— 동일 지표에 세 가지 계산 방식. 모두가 사업 내용이 아니라 기준에 대해 다투고 있다. 보고 도구가 더 발전할수록 기준의 분열은 더욱 은밀해진다: 각자가 하나씩 SQL을 작성하고, 그 결과는 모두 ‘자체적으로 타당하다’고 주장한다.

먼저 기준 사전을 마련한 뒤, 대시보드의 미려함을 논하자

경영 측면에서 데이터 거버넌스의 최소 폐쇄 루프는 다음과 같다:

1. 지표 정의: 사업적 의미, 분자와 분모, 시간 단위, 통화/세금 포함 여부, 제외 규정
2. 버전 고정: 기준 변경 시 버전 번호를 적용하고, 과거 보고서는 재계산 가능하거나 ‘구 기준’으로 표기해야 한다
3. 데이터 조회 경로: 유일 인증 조회 또는 시맨틱 계층을 사용하며, 비즈니스 데이터베이스에 직접 연결되어 흩어지는 것을 금지한다
4. 감사: 누가 언제 어떤 기준으로 수치를 산출했는지 확인한다

사전이 없으면 미들웨어는 더 큰 데이터 늪으로 전락할 뿐이다. 사전이 있어도 데이터 조회 경로를 강제하지 않으면, 사전은 그저 장식에 불과하다.

설계

비즈니스 오너가 지표를 정의하고, 데이터 관리자가 실현 가능성을 검토하며, 분석가는 배포된 상태의 지표만 활용하고, 재무는 법정 기준에 대해 최종 거부권을 가진다. 주제 영역(영업, 재고, 자금)은 각각 별도로 관리되며, 영역 간 지표는 반드시 이미 공개된 원자 지표를 참조해야 한다.

• 지표 객체: 코드, 명칭, 기준 문서, 오너, 상태
• 계산 로직: SQL/시맨틱 표현식, 의존 관계
• 배포 버전: 시행일, 변경 설명, 호환성 전략
• 소비자: 보고서, 구독, API 등에서 기준 버전을 기록한다

회의 자료를 내보낼 때 자동으로 기준 버전 번호와 갱신 시간을 함께 첨부하여, 스크린샷을 통한 구두 전달을 차단한다.

비교: 개인용 SQL vs 기준 플랫폼

도입 및 검수

우선 경영 지표 상위 20개를 먼저 정비하고, 처음부터 전사 지표 라이브러리를 일괄 정비하려 하지 말아야 한다. 모든 지표에는 반드시 비즈니스 오너의 서명이 필요하다. 시맨틱 계층이 도입된 후에는 비즈니스 데이터베이스의 읽기 전용 계정을 회수한다(예외는 심사 후 단기간 사용).

검수: 동일 지표의 두 대시보드 수치가 일치하는지, 기준 변경 후 기존 구독에 알림이 전달되는지, 버전 번호 없는 보고서를 외부로 발송할 수 있는지(불가능), 그리고 보고서에서 출처 테이블까지 추적 가능한지 등을 확인한다.

데이터 인텔리전스의 전제는 숫자가 변론 가능해야 한다는 것이다. 변론할 수 없는 정확성은 결국 더 비싼 논쟁일 뿐이다.

실패 모델

지표의 동일명 이의미: 코드는 반드시 유일하게 부여하고, 명칭은 별칭을 허용한다. 분석가가 시맨틱 계층을 우회하는 경우: 감사에서 직결 연결이 발견되면 권한을 회수한다. 기준 변경 시 소통이 없을 경우: 변경 통지를 소비자에게 미리 전달하고, 병행 기간을 부여한다.

4주 후 무엇을 살펴볼 것인가

기준 분쟁 건수, 중복 지표 수, 직결 데이터베이스 계정 수, 경영회의 ‘수치 불일치’로 인한 중단 횟수. 이 네 가지 지표가 감소하면 AI 기반 데이터 조회 보조 도구를 확대한다—그러나 도구 역시 배포 상태의 지표만 읽을 수 있어야 하며, 미처리 SQL을 자유롭게 생성해서는 안 된다.

지표 계층화: 원자, 파생, 주제

원자 지표(예: 주문 행 금액)를 먼저 정비하고, 파생 지표(예: 총이익, 전환율)는 의존 관계를 명시하며, 주제 지표는 시나리오 중심(예: 대금 회수 건강도)으로 원자/파생 지표를 조합하여 구성한다. 주제 지표가 원자 계층을 우회해 노골적인 SQL을 직접 작성하는 것은 금지된다.

동일명 지표 합병 신청 절차: 코드는 유지하고 별칭을 추가한다. 폐기 지표에는 퇴역 기간을 설정하고, 소비자가 이전한 뒤 해당 지표는 오프라인 처리한다. 의존 관계 그래프는 영향 분석에 활용된다: 원자 지표 하나를 변경하면 모든 파생 지표와 관련 보고서를 한눈에 파악할 수 있다.

대외 규제 기준과 내부 관리 기준이 동시에 존재할 경우, 라벨로 구분하고, 회의 자료에는 반드시 어느 기준을 사용했는지 명시하여 혼용을 방지한다.

AI 데이터 조회의 한계

자연어로 질문할 수 있는 범위는 이미 공개된 지표와 관리된 차원에 한정된다. 모델이 생성한 SQL이 지표 코드로 매핑되지 않으면 기본적으로 실행을 거부한다. 질의응답 로그는 감사에 포함되어 ‘당시 사용한 기준 버전’을 쉽게 되돌릴 수 있도록 한다.

비즈니스 담당자들에게 ‘질문 스토리텔링’을 교육한다: 먼저 지표 코드나 표준 명칭을 언급한 뒤, 시간과 조직 범위를 설명한다. 모델이 ‘이익’이 어떤 종류인지 추측하는 것보다 훨씬 안전하다.

지표에 데이터 품질 규칙을 부착한다: 빈 값 비율, 변동 임계값, 대조 오차 등. 품질 적색등이 켜지면 대시보드는 ‘사용 불가’로 표시하여, 잘못된 숫자를 보여주는 것보다 훨씬 책임감 있게 대응한다.

조직적 도입

지표 위원회는 반드시 거대할 필요 없다: 비즈니스 오너, 데이터 플랫폼, 재무 각각 한 명이면 충분히 결정을 내릴 수 있다. 분쟁이 격화될 경우의 경로를 제도에 명시하여, 그룹 채팅에서 끝없이 다투는 일을 예방한다. 분기마다 죽은 지표와 중복 대시보드를 정리한다.

새로운 대시보드 개설 시 반드시 기존 지표 코드를 참조해야 하며, 신규 지표는 왜 기존 지표로는 부족한지 명시해야 한다. 이는 사후 정비보다 훨씬 저렴하다.

경영진 보고서에 ‘기준 각주’ 한 페이지를 첨부한다: 이번 기간에 어떤 지표 코드와 버전을 사용했는지 기록한다. 회의에서 숫자를 놓고 다툴 때는 각주를 먼저 확인한 뒤 사업 내용을 논의하여, 불필요한 보고서 재확인을 줄인다.

보고서 플랫폼과의 역할 분담

보고서 도구는 표시와 권한을 담당하고, 지표 플랫폼은 정의와 버전을 담당한다. 대시보드 작성자는 지표 코드를 선택할 뿐, 계산 공식을 복제하지 않는다. 보고서가 무단으로 공식을 수정하는 경우, 플랫폼은 적색 경고를 표시하고 경영 회의 목록에 게시를 차단해야 한다.

지표 변경 통지 구독: 소비자(보고서, API, 이메일 구독)는 의존 관계를 등록하고, 기준 업그레이드 시 자동으로 변경 설명과 이전 마감일을 전달받는다.

기준 분쟁 해결 방법

분쟁 신청서 기록: 제안자, 현재 사용 알고리즘, 요구 알고리즘, 사업 시나리오, 영향 보고서 목록. 위원회 판결 후에는 버전 설명과 시행일을 기록하고, 판결 전에는 외부 자료에서 구 버전을 동결하고 각자 다른 버전을 작성하는 것을 금지한다.

재무 결산 기간에는 기준 변경을 일시적으로 잠글 수 있으며, 변경은 다음 개방 창까지 대기한다. 개방 창 밖에서는 긴급 수정 시 특별 경로를 통해 진행하고, 전 직원에게 공지한다.

딜러나 프랜차이즈 파트너에게 제공되는 지표는 별도의 이름공간을 마련하여, 내부 관리 기준이 외부로 유출되거나 계약 기준으로 오해되는 것을 방지한다.

데이터 조회 감사 결과는 내부 감사에 제공된다: 누가 언제 어떤 버전의 지표로 어떤 표를 계산했는지 기록한다. 계층별 권한과 연계하여, 기준은 맞지만 데이터가 권한을 초과하는 상황을 방지한다.

시범 부서는 먼저 사전과 버전 고정을 완료한 뒤, 전사적으로 데이터 조회를 확대해야 합니다. 전 직원이 동시에 데이터 조회를 시작하면 기준의 혼란만 커질 뿐입니다.

기준 및 버전 번호는 회의록 첨부파일명에 명시하여 사후 분쟁을 줄입니다.