Corporate Information Factory

Corporate Information Factory 는 회사 데이터를 가운데 저장소 하나에서 먼저 맞춘 뒤 부서마다 나눠 주는 설계입니다. 여러 시스템에서 온 데이터를 한 번만 통합합니다. 부서가 쓰는 저장소는 그 통합본에서만 데이터를 받아 갑니다. 그래서 부서마다 같은 숫자가 다르게 나오는 일이 줄어듭니다.

쉽고 빠른 이해

Corporate Information Factory 는 회사의 분석 데이터를 한곳에서 먼저 맞춘 뒤 나눠 주는 구조입니다. 쇼핑몰이라면 주문·회원·배송 기록을 가운데 저장소 하나에 모아 맞춥니다. 영업팀과 재무팀은 그 저장소에서 자기 몫을 받아 갑니다.

부서마다 각 시스템에서 따로 데이터를 가져가면 계산이 제각각이 됩니다. 영업팀이 낸 지난달 매출과 재무팀이 낸 지난달 매출이 다르게 나옵니다. 두 팀이 같은 맞추기 작업을 두 번 짜기도 합니다.

1. 각 시스템에서 데이터를 뽑아 이름과 형식을 하나로 맞춥니다
2. 맞춘 데이터를 가운데 저장소에 합계가 아니라 주문 한 건 한 건 그대로 오래 쌓아 둡니다
3. 부서마다 필요한 몫만 집계하기 쉬운 모양으로 옮겨 따로 둡니다

대가도 있습니다. 가운데 저장소를 회사 전체 기준으로 먼저 설계해야 해서 첫 보고서가 늦게 나옵니다. 같은 데이터를 두 번 옮겨 담으니 저장 공간과 옮기는 작업도 늘어납니다.

상세

이 절은 Corporate Information Factory 가 데이터를 어떤 순서로 흘려보내는지 봅니다. 주문·회원·배송 시스템을 둔 쇼핑몰 회사 하나를 예로 들어 원래 기록에서 부서 보고서까지 따라갑니다. 끝에서는 이 구조의 대가를 짚습니다. 자주 견주는 다른 방식도 표로 놓습니다.

이름은 「회사의 정보 공장」이라는 뜻입니다. 줄여서 CIF(Corporate Information Factory)라고 부릅니다.

이 이름을 붙인 사람은 Bill Inmon 입니다. 그래서 Inmon 아키텍처라고도 부릅니다. Inmon 은 분석용 기록을 모아 두는 저장소, 곧 데이터 웨어하우스라는 말을 널리 퍼뜨린 사람입니다.

데이터가 흩어진 회사

쇼핑몰에는 주문 시스템, 회원 시스템, 배송 시스템이 따로 돕니다. 이렇게 데이터가 처음 생기는 시스템을 원천 시스템이라고 부릅니다. 원천 시스템은 서비스를 돌리려고 만든 것이라 분석 질문을 받기에 맞지 않습니다.

시스템마다 같은 것을 다르게 적기도 합니다. 주문 시스템은 고객을 회원 번호로 적습니다. 배송 시스템은 고객을 전화번호로 적습니다. 두 기록을 이으려면 누가 누구인지 맞추는 작업이 먼저 필요합니다.

부서마다 이 맞추기를 따로 하면 결과가 갈립니다. 영업팀은 취소된 주문을 빼고 매출을 셉니다. 재무팀은 환불까지 끝난 주문만 뺍니다. 회의에서 지난달 매출이 두 개 나옵니다.

CIF 는 이 맞추기를 한곳에서 한 번만 합니다. 모든 부서가 그 결과를 받아 씁니다. 아래 소절들이 그 흐름을 한 단계씩 봅니다.

통합과 변환

원천 시스템의 데이터는 먼저 통합과 변환 단계를 지납니다. 이 단계는 먼저 데이터를 뽑아 옵니다. 그다음 형식과 식별자를 맞춥니다. 맞춘 데이터는 다음 저장소에 넣습니다. 뽑고 바꾸고 넣는 이 작업을 ETL(Extract, Transform, Load, 추출·변환·적재)이라고 부릅니다.

맞추는 대상은 식별자만이 아닙니다. 날짜 형식을 하나로 맞추고 상태 코드의 이름도 통일합니다. 주문 시스템이 취소를 숫자 「9」로 적고 배송 시스템이 글자 「취소」로 적으면 둘을 한 값으로 바꿉니다.

엔터프라이즈 데이터 웨어하우스

데이터 웨어하우스는 분석하려고 여러 시스템의 기록을 모아 오래 쌓아 두는 저장소입니다. CIF 는 맞춘 데이터를 회사 전체가 함께 쓰는 웨어하우스 하나에 넣습니다. 이 웨어하우스를 엔터프라이즈 데이터 웨어하우스라고 부릅니다. CIF 의 한가운데가 이 저장소입니다.

이 웨어하우스는 데이터를 정규화된 모양으로 담습니다. 정규화는 같은 값이 한 번만 저장되도록 테이블을 잘게 나누는 설계입니다. 고객 이름은 고객 테이블에만 있습니다. 주문 테이블은 고객 번호만 가집니다.

이 모양은 어느 한 부서의 질문에 맞춘 것이 아닙니다. 그래서 어느 부서가 무엇을 물어도 여기서 다시 꺼내 쓸 수 있습니다.

데이터는 가장 잘게 쪼갠 단위로 둡니다. 월별 합계 대신 주문 한 줄 한 줄을 남깁니다. 값이 바뀌어도 옛 값을 지우지 않고 이력으로 쌓습니다. 합계는 나중에 다시 셀 수 있습니다. 버린 주문 한 건 한 건은 되살릴 수 없습니다.

모든 부서가 믿고 쓰는 한 벌의 데이터를 단일 진실 버전(single version of the truth)이라고 부릅니다. CIF 에서는 이 웨어하우스가 그 한 벌입니다. 부서끼리 숫자가 갈리면 이 웨어하우스를 기준으로 따져 봅니다.

데이터 마트

정규화된 웨어하우스는 분석가가 바로 쿼리하기에 불편합니다. 「분기별 카테고리 매출」 하나를 물으려 해도 테이블 여러 개를 이어 붙여야 합니다. 그래서 CIF 는 부서마다 쓰기 편한 저장소를 하나 더 둡니다.

이 부서용 저장소가 데이터 마트입니다. 영업 데이터 마트에는 영업팀이 볼 판매 데이터를 담습니다. 재무 데이터 마트에는 재무팀이 볼 매출과 비용을 담습니다. 데이터 마트는 원천 시스템이 아니라 웨어하우스에서만 데이터를 받습니다.

데이터 마트는 대개 차원 모델로 짓습니다. 차원 모델은 분석용 데이터를 더할 숫자와 그 숫자를 가를 기준으로 나눠 담는 모양입니다. 「분기별 카테고리 매출」이라면 매출액이 더할 숫자입니다. 분기와 카테고리가 가를 기준입니다.

더할 숫자는 팩트 테이블에 담습니다. 쇼핑몰이라면 주문마다 매출액이 한 줄씩 이 테이블에 쌓입니다.

가를 기준은 차원 테이블에 담습니다. 날짜를 담은 테이블과 상품을 담은 테이블이 따로 있는 식입니다. 상품 테이블에는 상품마다 카테고리가 적혀 있습니다.

그래서 「분기별 카테고리 매출」은 팩트 테이블 하나에 날짜 테이블과 상품 테이블을 한 번씩 붙이면 나옵니다. 정규화된 웨어하우스보다 이어 붙일 테이블이 적습니다. 그만큼 집계 쿼리가 짧아집니다.

두 마트가 같은 웨어하우스에서 받아 가므로 같은 질문에는 같은 숫자가 나옵니다. 영업 마트의 지난달 매출과 재무 마트의 지난달 매출이 같은 주문 기록에서 셈해집니다.

운영 데이터 저장소

웨어하우스는 정해진 때에만 새 데이터를 받습니다. 그런데 지금 이 순간의 통합된 모습이 필요한 부서도 있습니다. 고객센터는 전화한 고객의 최근 주문과 배송 상태를 한 화면에서 봐야 합니다.

CIF 는 이런 쓰임을 위해 운영 데이터 저장소를 따로 둡니다. 줄여서 ODS(Operational Data Store)라고 부릅니다. ODS 도 통합과 변환 단계를 거친 데이터를 받습니다. 웨어하우스와 달리 옛 이력보다 지금 값을 담습니다. 갱신도 더 자주 합니다.

메타데이터

메타데이터는 데이터 자체가 아니라 데이터를 설명하는 데이터입니다. 테이블의 한 칸이 어느 원천 시스템에서 왔고 어떤 변환을 거쳤는지가 여기에 듭니다. CIF 는 데이터가 거치는 단계가 여럿입니다. 이 기록이 없으면 마트의 숫자를 거슬러 올라가 확인하기 어렵습니다. 그래서 메타데이터를 구조의 한 부분으로 따로 관리합니다.

전체 흐름

아래 그림은 쇼핑몰 예를 한 장에 모았습니다. 화살표는 데이터가 옮겨 가는 방향입니다.

flowchart TD
    subgraph 원천["원천 시스템"]
        S1["주문 시스템"]
        S2["회원 시스템"]
        S3["배송 시스템"]
    end
    원천 --> T["통합과 변환"]
    T --> W["엔터프라이즈 데이터 웨어하우스<br/>정규화 · 이력"]
    T --> O["운영 데이터 저장소<br/>지금 값"]
    W --> M1["영업 데이터 마트<br/>차원 모델"]
    W --> M2["재무 데이터 마트<br/>차원 모델"]

데이터는 위에서 아래로 한 방향으로만 흐릅니다. 데이터 마트끼리 데이터를 주고받지 않습니다. 마트가 원천 시스템에서 직접 가져오지도 않습니다.

가운데 하나에 여러 갈래가 매달린 이 모양을 허브 앤 스포크(hub and spoke)라고 부릅니다. 자전거 바퀴의 축과 바큇살에서 온 이름입니다. CIF 에서는 엔터프라이즈 데이터 웨어하우스가 축이고 데이터 마트가 바큇살입니다.

짓는 순서

CIF 는 회사 전체의 웨어하우스를 먼저 설계합니다. 데이터 마트는 그 뒤에 부서가 필요할 때마다 하나씩 붙입니다. 전체를 먼저 정하고 부분으로 내려가는 이 순서를 하향식(top-down) 설계라고 부릅니다.

먼저 정할 것은 회사 전체가 쓰는 낱말입니다. 「고객」이 회원만 뜻하는지 비회원 구매자까지 뜻하는지를 부서들이 합의해야 웨어하우스의 고객 테이블을 만들 수 있습니다.

대가

첫 결과가 늦게 나옵니다. 부서 하나가 보고서를 원해도 회사 전체의 웨어하우스 설계와 통합 작업이 먼저 끝나야 합니다. 앞 소절의 낱말 합의도 부서가 많을수록 오래 걸립니다.

데이터를 두 번 옮겨 담습니다. 원천 시스템에서 웨어하우스로 한 번, 웨어하우스에서 데이터 마트로 또 한 번 옮깁니다. 저장 공간이 두 벌 듭니다. 돌리고 고쳐야 할 옮기기 작업도 늘어납니다. 옮기는 단계가 하나 더 있으니 마트에 새 데이터가 도착하는 시각도 그만큼 늦어집니다.

가운데 모델을 고치는 비용이 큽니다. 새 원천 시스템을 붙이거나 업무가 바뀌면 웨어하우스의 정규화 모델부터 고쳐야 합니다. 그 아래 매달린 데이터 마트들도 함께 영향을 받습니다.

버스 아키텍처와 견주기

CIF 와 자주 견주는 것은 Ralph Kimball 이 널리 알린 버스 아키텍처입니다. 이 방식은 가운데 정규화 웨어하우스를 두지 않습니다. 업무마다 차원 모델을 하나씩 짓습니다. 그 모델들을 이어 붙인 것이 웨어하우스가 됩니다.

버스 아키텍처는 여러 차원 모델이 같은 차원 테이블을 나눠 쓰게 해서 숫자를 맞춥니다. 판매 모델과 재고 모델이 똑같은 상품 테이블을 쓰는 식입니다. 이렇게 여러 모델이 함께 쓰는 차원 테이블을 컨폼드 디멘션이라고 부릅니다. 「버스」는 컴퓨터 부품들이 함께 꽂히는 버스에서 온 이름입니다. 여러 차원 모델이 이 공통 차원 테이블에 함께 꽂힌다는 뜻입니다.

아래 표는 두 방식이 갈리는 축을 나란히 놓습니다.

두 방식이 같은 곳도 있습니다. 부서가 실제로 쿼리하는 저장소는 둘 다 차원 모델입니다. 갈리는 것은 그 차원 모델 위에 정규화된 가운데 저장소를 하나 더 두느냐입니다.

언제 고르나

원천 시스템이 많고 시스템마다 식별자가 제각각인 회사에서 이 대가를 치를 이유가 생깁니다. 여러 부서가 같은 숫자로 보고해야 할 때도 그렇습니다. 가운데 웨어하우스가 통합을 한 번에 맡아 주기 때문입니다.

원천 시스템이 몇 개 없는 회사도 있습니다. 분석하는 부서도 하나뿐이라면 가운데 웨어하우스는 옮기기 단계만 하나 늘립니다. 이럴 때는 차원 모델 하나를 바로 지어 첫 보고서를 먼저 내는 방식이 흔히 쓰입니다.

관련 항목

CIF 를 이루는 구성 요소

원천 · ETL · 엔터프라이즈 데이터 웨어하우스 · 데이터 마트 · 운영 데이터 저장소 · 메타데이터 · 스테이징 영역

CIF 가 속하는 상위 분류

데이터 웨어하우스 · 데이터 엔지니어링 · 데이터 아키텍처 · 데이터 관리

CIF 안에서 쓰는 모델링 방법

정규화 · 제3정규형 · 엔티티-관계 모델링 · 차원 모델링 · 팩트 테이블 · 차원 테이블 · 스타 스키마 · 컨폼드 디멘션

CIF 와 같은 역할을 두고 겨루는 웨어하우스 구조

엔터프라이즈 데이터 웨어하우스 버스 아키텍처 · 데이터 볼트 · 메달리온 아키텍처 · 데이터 레이크하우스 · 데이터 메시

CIF 가 지키려는 성질과 설계 원칙

단일 진실 버전 · 데이터 통합 · 허브 앤 스포크 · 하향식 설계

CIF 가 데이터를 넘겨받고 내주는 처리 방식

OLTP · OLAP · 배치 처리 · 비즈니스 인텔리전스