사전 비즈니스 인텔리전스
개념

비즈니스 인텔리전스

gabury1고친 사람 github-actions[bot]

비즈니스 인텔리전스는 회사에 쌓인 기록을 의사 결정에 쓸 숫자로 바꿔 줍니다. 여러 시스템에 흩어진 데이터를 한곳에 모읍니다. 그 데이터를 매출이나 가입자 수 같은 숫자로 요약합니다. 경영진과 기획자는 그 숫자를 보고서와 대시보드로 받아 봅니다.

쉽고 빠른 이해

비즈니스 인텔리전스는 회사의 기록을 모아 「지금 장사가 어떤가」에 숫자로 답하는 일입니다. 쇼핑몰이라면 월요일 회의 화면에 지난주 지역별 매출과 새로 가입한 회원 수를 띄워 주는 일이 여기 듭니다.

주문, 회원, 광고 기록은 저마다 다른 데이터베이스에 흩어져 있습니다. 서비스가 도는 데이터베이스에 큰 계산을 돌리면 서비스가 느려집니다. 부서마다 따로 세면 같은 매출이 팀마다 다르게 나옵니다.

어떻게 도나:

  1. 밤마다 여러 시스템의 기록을 분석용 저장소 한곳으로 복사해 옵니다
  2. 매출처럼 자주 보는 숫자는 미리 계산해 둡니다
  3. 사람들은 보고서와 대시보드 화면으로 그 숫자를 봅니다

숫자는 대개 어제까지의 것이라 방금 일어난 일은 아직 안 보입니다. 숫자가 떨어진 것은 보여 줘도 왜 떨어졌는지는 사람이 파고들어야 합니다. 복사해 오는 작업이 늘수록 돌봐야 할 것도 늘어납니다.

상세

동네 빵집 주인은 가게 문을 닫고 나서 그날 장부를 폅니다. 크루아상이 몇 개 팔렸고 식빵이 몇 개 남았는지 봅니다. 크루아상이 사흘 내리 남았다면 내일은 덜 굽습니다.

비즈니스 인텔리전스(BI, Business Intelligence)는 회사에 쌓인 기록을 모아 결정에 쓸 숫자로 요약해 보여 주는 일입니다. 빵집 주인이 장부를 보고 내일 구울 양을 정하는 것과 같은 일입니다. 온라인 쇼핑몰이라면 「지난주 지역별 매출」이나 「이번 달 새로 가입한 회원 수」를 매주 회의 화면에 띄우는 일이 BI 입니다.

이 이름은 일 자체만 가리키지 않습니다. 그 숫자를 만드는 과정과 거기 쓰는 저장소와 도구를 한데 묶어 부를 때도 BI 라고 합니다. 「BI 팀」이나 「BI 도구」가 그런 쓰임입니다.

회사가 커지면 기록이 한곳에 있지 않습니다. 주문은 주문 서비스의 데이터베이스에, 회원은 회원 서비스의 데이터베이스에, 광고 클릭은 로그 파일에 쌓입니다. 「광고를 보고 들어온 새 회원이 첫 달에 얼마를 샀나」는 이 셋을 다 봐야 답이 나옵니다. BI 는 이런 질문에 답하려고 기록을 한곳에 모으는 일부터 합니다.

이 절은 쇼핑몰 하나를 따라갑니다. 보는 순서는 아래와 같습니다.

  1. 비즈니스 인텔리전스가 답하는 질문
  2. 데이터가 화면까지 오는 길
  3. 서비스 데이터베이스와 따로 두는 이유
  4. 숫자를 받아 보는 방식
  5. 숫자의 뜻을 맞추는 일
  6. 비즈니스 인텔리전스가 맞지 않는 경우

비즈니스 인텔리전스가 답하는 질문

BI 가 주로 다루는 것은 이미 일어난 일입니다. 「지난달 매출은 얼마였나」처럼 과거와 현재를 숫자로 요약합니다. 이런 요약에 쓰는 계산은 대개 집계입니다. 집계는 여러 행을 합계나 평균 같은 값 하나로 줄이는 계산입니다.

아래 표는 쇼핑몰에서 흔히 묻는 질문 셋이 어떤 기록을 쓰고 어떤 모양으로 나오는지 보입니다.

질문 필요한 기록 보여 주는 모양
지난달 매출은 얼마였나 주문 숫자 하나
매출이 달마다 어떻게 변했나 주문 달을 가로축으로 둔 선 그래프
어느 지역에서 가장 많이 샀나 주문 · 회원 주소 지역별 막대그래프

세 질문은 모두 주문 금액을 더하는 계산입니다. 다른 것은 무엇으로 나눠 보느냐입니다. 달로 나누면 흐름이 보입니다. 지역으로 나누면 비교가 됩니다.

숫자가 이상하면 한 단계씩 좁혀 들어갑니다. 전체 매출이 떨어졌다면 먼저 지역별로 나눠 봅니다. 그다음 그 지역을 상품별로 나눠 봅니다. 이처럼 큰 합계에서 세부로 내려가며 보는 방법을 드릴다운이라고 합니다.

회사가 늘 지켜볼 숫자는 미리 정해 둡니다. 지표는 이렇게 판단에 쓰려고 정해 둔 숫자입니다. 쇼핑몰이라면 하루 주문 수나 장바구니에 담은 뒤 결제까지 간 비율이 지표가 됩니다.

지표 가운데 회사의 목표에 곧바로 걸린 몇 개를 핵심 성과 지표(KPI, Key Performance Indicator)라고 합니다. 「올해 월 매출을 두 배로」가 목표라면 월 매출이 KPI 가 됩니다. BI 화면은 대개 이 KPI 몇 개를 가운데 둡니다.

데이터가 화면까지 오는 길

BI 화면의 숫자는 서비스의 데이터베이스에서 곧바로 오지 않습니다. 몇 단계를 거쳐 옮겨지고 다듬어집니다. 주문 한 건이 월요일 회의 화면의 매출 숫자가 되기까지를 따라갑니다.

출발점은 원천 시스템입니다. 주문 데이터베이스나 광고 클릭 로그처럼 데이터가 처음 생기는 곳입니다. 서비스는 여기에 주문을 넣고 읽으며 돕니다.

원천의 데이터는 분석용 저장소인 데이터 웨어하우스로 복사됩니다. 웨어하우스는 여러 시스템의 기록을 같은 모양으로 맞춰 한곳에 오래 쌓아 둡니다. 주문 서비스와 회원 서비스가 따로 적은 회원을 같은 회원 번호로 이어지게 맞추는 일도 여기서 합니다.

복사는 세 단계로 돕니다. 먼저 원천에서 필요한 데이터를 뽑아 옵니다. 다음에 분석하기 쉬운 모양으로 다듬습니다. 마지막으로 웨어하우스에 넣습니다.

이 세 단계를 묶어 ETL(Extract, Transform, Load, 추출·변환·적재)이라고 부릅니다. 이름은 세 단계의 영어 머리글자를 딴 것입니다.

ETL 은 대개 밤처럼 정해진 때에 몰아서 돕니다. 낮에는 원천 시스템이 서비스 요청을 받느라 바쁩니다. 쓰는 사람이 적은 밤에 하루 치를 한 번에 옮기면 원천에 주는 부담이 적습니다. 이렇게 쌓아 두었다가 한 번에 처리하는 방식을 배치 처리라고 합니다.

부서마다 자주 보는 데이터만 다시 떼어 두기도 합니다. 마케팅 팀은 광고와 주문을, 재무 팀은 매출과 환불을 봅니다. 한 부서의 몫만 모아 둔 이 작은 저장소가 데이터 마트입니다.

마트에는 자주 보는 숫자를 미리 계산해 담아 둡니다. 「날짜별·지역별 매출」 테이블을 만들어 두면 화면은 수많은 주문을 매번 더하지 않고 그 테이블만 읽습니다.

길의 끝에서 사람이 숫자를 봅니다. 정해진 때마다 같은 모양으로 나오는 문서가 보고서입니다. 자주 보는 지표를 그래프와 표로 한 화면에 모아 둔 것이 대시보드입니다.

아래 그림은 이 길을 그린 것입니다. 데이터 마트는 건너뛰기도 합니다. 웨어하우스에서 곧바로 보고서와 대시보드를 만드는 회사도 있습니다. 그림의 점선이 그 길입니다.

flowchart TD
    subgraph 원천["원천 시스템"]
        A["주문 데이터베이스"]
        B["광고 클릭 로그"]
    end
    원천 -->|ETL| W["데이터 웨어하우스"]
    W --> M["데이터 마트"]
    M --> R["보고서"]
    M --> D["대시보드"]
    W -.-> R
    W -.-> D

서비스 데이터베이스와 따로 두는 이유

BI 는 서비스의 데이터베이스에 바로 묻지 않고 복사본을 따로 둡니다. 두 쪽이 받는 질문의 모양이 서로 다르기 때문입니다.

서비스의 데이터베이스는 주문 한 건을 넣고 회원 한 명을 읽는 짧은 요청을 쉴 새 없이 받습니다. 이런 작업을 온라인 트랜잭션 처리(OLTP, Online Transaction Processing)라고 부릅니다. 요청 하나가 건드리는 행은 몇 개뿐입니다.

BI 의 질문은 반대입니다. 「지난 분기 지역별 매출」 하나에 답하려면 석 달 치 주문을 전부 훑어 더해야 합니다. 이런 작업은 온라인 분석 처리(OLAP, Online Analytical Processing)에 속합니다.

두 작업을 한 데이터베이스에 섞으면 큰 집계가 디스크와 프로세서를 오래 붙잡습니다. 그동안 주문을 넣는 짧은 요청이 기다립니다. 그래서 서비스가 느려집니다. 웨어하우스를 따로 두면 분석이 무거워져도 그 부담이 서비스 쪽으로 번지지 않습니다.

OLTP 와 OLAP 는 이렇게 갈립니다.

OLTP OLAP
주로 하는 일 한 건 넣기 · 고치기 · 읽기 많은 행을 훑어 더하기
요청 하나가 건드리는 행 몇 개 테이블의 큰 부분
데이터의 시점 지금 이 순간 대개 어제까지
묻는 쪽 서비스 분석가 · 기획자 · 경영진

숫자를 받아 보는 방식

같은 숫자라도 받아 보는 방식은 여럿입니다. 가르는 기준은 화면의 모양을 누가 정하느냐입니다.

이 소절은 데이터 팀이 미리 정해 두는 방식에서 시작합니다. 그다음은 보는 사람이 화면에서 기준을 고르는 방식입니다. 마지막은 분석가가 질의를 직접 써서 답을 구하는 방식입니다.

보고서와 대시보드는 「데이터가 화면까지 오는 길」에서 봤습니다. 둘 다 미리 정해 둔 질문에만 답합니다. 새 질문이 생길 때마다 데이터 팀에 화면을 새로 부탁하면 답이 늦게 옵니다.

셀프서비스 BI는 이 부탁을 줄입니다. 기획자가 화면에서 직접 기준을 골라 숫자를 나눠 봅니다. 「지역별」로 보던 매출을 스스로 「연령대별」로 바꿔 보는 식입니다.

화면으로도 안 되는 질문은 분석가가 직접 묻습니다. 분석가는 SQL(Structured Query Language, 구조화 질의 언어)로 데이터베이스에 질문을 적습니다. SQL 은 데이터베이스에서 무엇을 꺼낼지 적는 언어입니다.

분석가의 질의는 대개 그때 한 번 쓰고 맙니다. 미리 만들어 둔 화면 없이 필요할 때 적어 던지는 이런 질의를 임의 질의라고 합니다. 한 번 생긴 질문 하나를 위해 화면을 새로 만들 까닭은 없습니다.

네 방식은 모양을 누가 정하느냐와 맞는 때로 갈립니다.

방식 모양을 정하는 사람 맞는 때
보고서 데이터 팀 매주·매달 같은 숫자를 같은 모양으로 볼 때
대시보드 데이터 팀 자주 보는 지표를 한눈에 훑을 때
셀프서비스 BI 보는 사람 정해진 화면으로 답이 안 나올 때
임의 질의 분석가가 직접 한 번 묻고 말 질문일 때

숫자의 뜻을 맞추는 일

BI 에서 흔히 부딪히는 어려움은 계산보다 숫자끼리 안 맞는 것입니다. 마케팅 팀과 재무 팀의 보고서에 같은 달 매출이 다르게 나오면 회의는 어느 숫자가 맞는지 따지는 데 시간을 씁니다. 이런 어긋남은 흔히 두 곳에서 생깁니다. 읽는 데이터가 다른 경우와 세는 법이 다른 경우입니다.

먼저 읽는 데이터가 다른 경우입니다. 팀마다 주문 데이터를 제 저장소에 복사해 두면 복사한 날과 걸러 낸 행이 저마다 달라집니다. 같은 주문에서 출발해도 숫자가 벌어집니다. 이처럼 부서마다 따로 쌓여 서로 맞춰지지 않는 데이터를 데이터 사일로라고 합니다.

이를 막으려고 모두가 같은 데이터를 한곳에서 읽게 합니다. 모두가 기준으로 삼는 이 한 곳을 단일 진실 원천이라고 부릅니다. BI 에서는 웨어하우스가 흔히 이 역할을 맡습니다.

같은 데이터를 읽어도 세는 법이 다르면 숫자는 또 갈립니다. 「매출」 하나도 결제한 금액으로 셀 수 있습니다. 결제 금액에서 환불을 뺀 금액으로 셀 수도 있습니다.

그래서 웨어하우스 위에 시맨틱 레이어를 두기도 합니다. 시맨틱 레이어는 지표의 계산식만 모아 적어 두는 계층입니다. 「매출은 결제 금액에서 환불을 뺀 것」을 여기 한 번 적어 두면 모든 보고서와 대시보드가 그 식을 가져다 씁니다.

정리하면 웨어하우스는 모두에게 같은 데이터를 줍니다. 시맨틱 레이어는 그 데이터 위에서 모두에게 같은 계산식을 줍니다.

비즈니스 인텔리전스가 맞지 않는 경우

BI 의 숫자는 늦습니다. 밤마다 몰아서 복사하므로 아침 화면은 어젯밤까지의 숫자입니다. 방금 난 장애나 지금 몰리는 주문을 보려면 서비스가 내는 지표를 곧바로 그리는 운영 모니터링 대시보드가 맞습니다.

BI 는 다음 달 매출을 맞히는 일에도 맞지 않습니다. 지난 기록에서 규칙을 찾아 앞일을 내다보는 일은 머신러닝과 데이터 과학이 주로 맡습니다. BI 는 그 앞 단계인 「무슨 일이 있었나」를 맡습니다.

숫자는 무엇이 변했는지를 보여 줄 뿐 왜 변했는지는 알려 주지 않습니다. 드릴다운으로 범위를 좁힐 수는 있어도 원인은 사람이 가설을 세워 따로 확인해야 합니다. 새 결제 화면이 매출을 올렸는지 알려면 손님을 무작위로 둘로 나눠 두 화면을 보여 주는 A/B 테스트 같은 실험이 필요합니다.

복사해 오는 작업은 한 번 만들고 끝나지 않습니다. 원천 테이블의 열 이름이나 값의 뜻이 바뀌면 그 테이블을 읽는 ETL 이 멈추거나 틀린 숫자를 냅니다. 원천과 보고서가 늘수록 돌봐야 할 작업도 늘어납니다.

관련 항목

비즈니스 인텔리전스가 속하는 상위 분류

데이터 분석 · 데이터 엔지니어링 · 데이터 과학 · 의사 결정 지원 시스템

비즈니스 인텔리전스에 데이터를 대는 저장소

원천 시스템 · 데이터 웨어하우스 · 데이터 마트 · 데이터 레이크 · 데이터 레이크하우스 · 운영 데이터 저장소

데이터를 화면까지 옮기는 처리 단계

ETL · ELT · 배치 처리 · 데이터 파이프라인 · 변경 데이터 캡처 · 스트림 처리

비즈니스 인텔리전스가 기대는 분석 방식

OLAP · OLTP · OLAP 큐브 · 집계 · 드릴다운 · 슬라이스와 다이스 · 기술 통계 · 코호트 분석 · 퍼널 분석

분석용 테이블을 짜는 모델링 기법

차원 모델링 · 스타 스키마 · 스노우플레이크 스키마 · 팩트 테이블 · 차원 테이블 · 열 지향 저장

비즈니스 인텔리전스가 숫자를 내보이는 수단

보고서 · 대시보드 · 데이터 시각화 · 셀프서비스 BI · 임의 질의 · SQL · 스프레드시트

비즈니스 인텔리전스가 재는 지표

지표 · 핵심 성과 지표 · 전환율 · 재구매율 · 이탈률 · 메트릭

숫자의 뜻을 맞추는 관리 체계

단일 진실 원천 · 시맨틱 레이어 · 데이터 사일로 · 데이터 거버넌스 · 데이터 계보 · 데이터 품질 · 데이터 카탈로그

비즈니스 인텔리전스를 구현한 도구

Tableau · Power BI · Looker · Metabase · Apache Superset

비즈니스 인텔리전스에 관여하는 역할

데이터 분석가 · 애널리틱스 엔지니어 · 데이터 엔지니어 · 데이터 과학자

비즈니스 인텔리전스가 못 하는 일을 맡는 수단

모니터링 · 머신러닝 · 예측 분석 · A/B 테스트

다른 이름: business intelligence · BI · 비즈니스인텔리전스