데이터 통합

데이터 통합은 여러 시스템에 흩어진 데이터를 모아 한 번에 물어볼 수 있게 맞추는 일입니다. 시스템마다 데이터를 적는 방식이 달라서 모으기만 해서는 함께 쓸 수 없습니다. 그래서 통합은 데이터를 옮기는 일과 형식과 뜻을 맞추는 일을 함께 합니다.

쉽고 빠른 이해

여러 시스템에 나뉜 데이터를 한곳에서 함께 볼 수 있게 만드는 일입니다. 「지난달 가장 많이 산 회원 열 명의 이메일」을 뽑으려면 주문 쪽 데이터와 회원 쪽 데이터를 함께 봐야 합니다.

이게 없으면 사람이 양쪽에서 따로 뽑은 결과를 스프레드시트에서 손으로 맞춥니다. 맞추는 사람마다 규칙이 달라서 같은 질문에도 숫자가 어긋납니다.

1. 각 시스템에서 데이터를 꺼냅니다
2. 날짜 적는 법, 이름, 뜻을 한 가지로 맞춥니다
3. 맞춘 데이터를 한곳에 모으거나, 물을 때마다 여러 곳에 나눠 물어 합칩니다

대가는 셋입니다. 한곳에 모아 두는 쪽은 원본보다 늦습니다. 원본 시스템이 바뀌면 맞추는 규칙이 깨집니다. 시스템이 늘수록 그 규칙도 늘어 누군가 계속 돌봐야 합니다.

질문이 한 시스템 안에서 끝나거나, 요청을 처리하는 도중에 지금 값이 필요하면 쓰지 않습니다.

상세

부서마다 장부를 따로 쓰는 회사를 떠올려 보면 가깝습니다. 영업부는 거래처를 상호로 적습니다. 경리부는 사업자 번호로 적습니다. 날짜도 한쪽은 「3월 2일」, 다른 쪽은 「03/02」로 씁니다. 회사 전체 매출을 알려면 누군가 장부를 한데 모아 같은 방식으로 다시 적어야 합니다.

데이터 통합은 여러 곳의 데이터를 모아 형식과 뜻을 맞추는 일입니다. 맞춘 데이터는 한곳에서 함께 조회할 수 있습니다. 쇼핑몰이라면 「지난달 가장 많이 산 회원 열 명의 이메일」 같은 질문이 그 대상입니다. 구매 금액은 주문 쪽에, 이메일은 회원 쪽에 있어서 한쪽만 봐서는 답이 안 나옵니다.

데이터를 처음 만들고 들고 있는 시스템을 원천이라고 부릅니다. 주문 서비스의 데이터베이스, 회원 서비스의 데이터베이스, 외부 결제 대행사가 보내는 정산 파일이 각각 하나의 원천입니다. 통합은 이런 원천 여럿을 입력으로 받습니다.

통합한 데이터를 받아 쓰는 쪽은 대개 분석입니다. 매출 대시보드, 월말 보고서, 추천 모델 학습처럼 여러 원천을 가로질러 봐야 하는 일들입니다.

데이터가 흩어지는 까닭

데이터가 애초에 여러 곳으로 나뉘는 이유와, 나뉜 채로 둘 때 생기는 곤란을 차례로 봅니다.

시스템은 저마다 자기 일에 맞게 데이터를 저장합니다. 주문 서비스는 주문을 빨리 받는 데 맞춘 테이블을 둡니다. 회원 서비스는 로그인과 개인 정보 관리에 맞춘 테이블을 둡니다. 서비스를 잘게 나누는 마이크로서비스 구조에서는 서비스마다 데이터베이스를 따로 갖는 일이 흔합니다.

나뉜 데이터베이스는 한 질의로 묶을 수 없습니다. SQL(Structured Query Language, 구조화 질의 언어)의 조인은 두 테이블을 공통 값으로 이어 붙이는 연산입니다. 그런데 한 데이터베이스는 자기 테이블만 알아서, 다른 데이터베이스의 테이블과는 조인하지 못합니다.

결제 대행사나 광고 플랫폼 같은 외부 원천의 데이터는 데이터베이스가 아니라 파일이나 API(Application Programming Interface, 애플리케이션 프로그래밍 인터페이스)로 받습니다. API 는 다른 시스템이 기능이나 데이터를 내주려고 열어 둔 호출 창구입니다. 이런 데이터는 데이터베이스 조인으로는 아예 닿지 않아서, 먼저 꺼내 와야 다른 데이터와 맞춰 볼 수 있습니다.

통합이 없으면 사람이 손으로 합칩니다. 양쪽에서 따로 뽑은 결과를 스프레드시트에 붙여 회원 번호로 맞춰 봅니다. 이 일을 부서마다 따로 하면 같은 질문에 서로 다른 숫자가 나옵니다. 누가 어느 때의 데이터를 어떤 규칙으로 맞췄는지가 제각각이기 때문입니다.

주문을 받는 원천 데이터베이스, 곧 운영 데이터베이스에 분석 조회를 바로 던지기도 어렵습니다. 몇 달 치 주문을 훑는 조회가 도는 동안 새로 들어오는 주문 처리가 느려집니다. 분석용 데이터를 운영 시스템과 떼어 따로 두는 까닭입니다.

모으면서 맞추는 차이

데이터를 한곳에 복사해 두기만 해서는 함께 쓸 수 없습니다. 원천마다 같은 것을 다르게 적기 때문입니다. 통합에서 손이 가장 많이 가는 일이 이 차이를 맞추는 일입니다. 차이는 아래 표의 네 가지로 나눠 볼 수 있습니다.

형식과 이름은 규칙만 정하면 프로그램이 바꿉니다. 문자열 날짜를 날짜 타입으로 바꾸고 컬럼 이름을 고치는 일은 한 번 짜 두면 매번 같게 돌아갑니다. 데이터를 목표 모양으로 바꾸는 이 단계가 변환입니다.

식별은 더 까다롭습니다. 두 원천이 같은 번호를 쓰지 않으면 이메일이나 전화번호 같은 다른 값으로 같은 사람인지 가려야 합니다. 이 일이 레코드 연결입니다. 이메일을 바꾼 회원이나 이름에 오타가 난 회원처럼 규칙으로 딱 떨어지지 않는 경우가 늘 남습니다.

뜻의 차이는 프로그램이 찾아 주지 않습니다. 두 컬럼이 모두 amount 이고 타입도 같으면 겉으로는 같아 보입니다. 부가세를 넣었는지, 환불을 뺐는지는 그 원천을 만든 팀에 물어봐야 압니다. 규모가 큰 조직은 「매출」「활성 회원」 같은 낱말의 정의를 데이터 카탈로그에 적어 두고 함께 봅니다.

옮겨서 합치기와 두고 합치기

맞춘 데이터를 어디에 두느냐로 통합 방식이 크게 둘로 갈립니다. 두 방식을 차례로 보고 표로 견줍니다.

첫째는 데이터를 복사해 한 저장소로 옮기는 방식입니다. 원천은 데이터를 꺼내 줄 때만 부담을 집니다. 분석 조회는 전부 옮겨 온 복사본에서 실행됩니다.

받는 저장소로는 분석하기 좋게 정리해 두는 데이터 웨어하우스를 흔히 씁니다. 원본 모양을 바꾸지 않고 쌓아 두는 데이터 레이크도 씁니다.

아래 그림은 옮겨서 합치는 흐름입니다. 대시보드와 보고서는 원천을 건드리지 않고 데이터 웨어하우스만 조회합니다.

flowchart TD
    subgraph 원천
        A["주문 데이터베이스"]
        B["회원 데이터베이스"]
        C["결제 대행사 정산 파일"]
    end
    A --> D["꺼낸다"]
    B --> D
    C --> D
    D --> E["형식 · 이름 · 식별 · 뜻을 맞춘다"]
    E --> F["데이터 웨어하우스에 싣는다"]
    F --> G["대시보드 · 보고서가 조회한다"]

옮기는 순서에 따라 이름이 갈립니다. 꺼내고 바꾸고 싣는 순서면 ETL(Extract, Transform, Load, 추출·변환·적재)이라고 부릅니다. 먼저 싣고 저장소 안에서 바꾸면 ELT(Extract, Load, Transform, 추출·적재·변환)입니다.

원천이 바뀔 때마다 바뀐 행만 흘려보내는 방법도 있습니다. 이를 변경 데이터 캡처, 줄여서 CDC(Change Data Capture)라고 부릅니다. 매번 전체를 다시 꺼내지 않아서 복사본이 원본을 더 바짝 따라갑니다.

둘째는 데이터를 원천에 둔 채 합치는 방식입니다. 조회가 들어오면 여러 원천에 질의를 나눠 보냅니다. 돌아온 결과는 그때 합쳐 돌려줍니다. 이 방식이 데이터 가상화입니다.

두 방식을 나란히 놓으면 이렇습니다.

두 방식의 장단점은 서로 반대입니다. 옮겨서 합치면 조회가 가볍습니다. 대신 값이 늦습니다. 두고 합치면 값은 지금 것입니다. 대신 조회할 때마다 원천들이 일을 합니다.

통합이 치르는 대가

통합을 들이면 떠안는 부담이 셋 있습니다.

옮겨서 합친 데이터는 원본보다 늦습니다. 하루 한 번 옮기면 오늘 들어온 주문은 내일에야 보입니다. 복사본이 원본을 얼마나 바짝 따라가는지를 신선도라고 부릅니다.

원천이 바뀌면 통합이 깨집니다. 스키마는 테이블이 어떤 컬럼을 어떤 타입으로 갖는지를 정한 짜임입니다. 주문 서비스 팀이 컬럼 이름이나 타입을 바꾸면, 그 컬럼을 읽던 변환 규칙이 멈추거나 틀린 값을 싣습니다.

원천을 고치는 팀은 대개 통합을 모릅니다. 그래서 이런 변경은 예고 없이 들어옵니다. 스키마가 시간에 따라 바뀌는 일과 그 변화를 견디는 방법을 스키마 진화라고 부릅니다.

맞추는 규칙도 결국 코드입니다. 원천이 늘수록 규칙이 늡니다. 누군가 그 규칙을 계속 고치고 돌봐야 합니다. 이렇게 데이터를 옮기고 맞추는 데이터 파이프라인을 만들고 운영하는 분야가 데이터 엔지니어링입니다.

통합이 필요 없는 경우

모든 조회에 통합이 필요하지는 않습니다. 통합 없이 끝나는 경우는 셋입니다.

질문이 한 시스템 안에서 끝나면 통합이 필요 없습니다. 주문 목록 화면은 주문 데이터베이스만 보면 됩니다.

원천이 하나이고 분석 조회만 떼어 내고 싶다면 읽기 복제본이 더 가볍습니다. 읽기 복제본은 운영 데이터베이스를 복제해 읽기만 받는 사본입니다. 맞출 차이가 없으니 변환도 필요 없습니다.

사용자 요청을 처리하는 도중에 다른 서비스의 데이터가 필요하면, 통합한 저장소가 아니라 그 서비스의 API 를 부릅니다. 통합한 저장소의 값은 늦어서, 방금 바뀐 값을 믿고 처리를 이어 가기 어렵습니다.

애플리케이션 통합과 가르는 법

「통합」이라는 말은 시스템끼리 동작을 잇는 일에도 씁니다. 주문이 들어오면 재고 서비스에 알리고 결제 서비스를 부르는 식으로 시스템을 엮는 일입니다. 이 일을 애플리케이션 통합이라고 부릅니다.

두 일은 넘기는 것이 다릅니다. 애플리케이션 통합은 「주문이 들어왔다」 같은 사건과 요청을 그때그때 넘겨 다음 동작을 일으킵니다. 데이터 통합은 쌓인 데이터를 모아 나중에 함께 조회하게 합니다.

관련 항목

데이터 통합이 속하는 상위 분류

데이터 엔지니어링 · 데이터 관리 · 데이터 파이프라인 · 파이프라인

데이터 통합을 수행하는 방식

ETL · ELT · 변경 데이터 캡처 · 데이터 복제 · 데이터 가상화 · 역방향 ETL · 배치 처리 · 스트림 처리

데이터 통합이 거치는 처리 단계

추출 · 변환 · 적재 · 데이터 정제 · 레코드 연결 · 중복 제거 · 증분 추출

통합한 데이터가 놓이는 저장소

데이터 웨어하우스 · 데이터 레이크 · 레이크하우스 · 데이터 마트 · 스테이징 영역

데이터 통합에 데이터를 내주는 원천

원천 · 데이터베이스 · API · 마이크로서비스 · 읽기 복제본

데이터 통합이 지켜야 하는 성질

데이터 품질 · 신선도 · 일관성 · 단일 진실 공급원 · 마스터 데이터 관리

데이터 통합을 깨뜨리는 변화

스키마 · 스키마 진화 · 스키마 드리프트 · 데이터 계약

통합한 데이터의 뜻을 적어 두는 도구

데이터 카탈로그 · 메타데이터 · 데이터 리니지 · 데이터 거버넌스

데이터 통합과 이름이 겹치는 다른 통합

애플리케이션 통합 · 엔터프라이즈 서비스 버스 · 메시지 큐 · 이벤트 기반 아키텍처