모던 데이터 아키텍처

경계와 계약으로 설계하기

데이터가 여러 시스템에 흩어진 조직에서
아키텍처를 어떻게 설계하고 운영할지 다룬다.

전체 주장은 한 문장이다.

비즈니스 경계로 책임을 나누고,
경계를 넘을 때는 명시적인 계약으로 연결하며,
공통 기반은 플랫폼으로 표준화해서
작은 범위부터 점진적으로 확장한다.

23개 장은 이 문장을 풀어 쓴 것이다.

시작하기

처음이라면 0장. 이 책의 지도부터 읽는다.
전체 구조와 목적별 읽기 경로가 정리되어 있다.

목차

0장. 이 책의 지도

전체 구조, 읽는 순서, 반복해서 나오는 개념

1부 · 문제 — 왜 데이터가 흩어졌고 무엇이 문제인가

2부 · 경계 — 어디에 선을 긋고 누가 책임지는가

3부 · 연결 — 경계를 어떻게 넘는가

4부 · 제품 — 데이터를 어떻게 쓸 수 있게 하는가

5부 · 신뢰 — 찾고, 믿고, 안전하게 쓰려면

6부 · 가치 — 어떻게 성과로 바꾸는가

7부 · 실행 — 어디서부터 시작하는가

부록

더 읽기 전에

목적별 읽기 경로, 반복해서 나오는 개념의 설명 위치,
이 책이 드는 예시에 대해서는
0장. 이 책의 지도에 정리해 두었다.

급하다면 이것만 기억하면 된다.

기술 이름을 외우는 책이 아니다.
도구는 계속 바뀌지만 아래 질문은 바뀌지 않는다.

이 데이터는 무엇인가?

누가 책임지는가?

어디에서 왔는가?

얼마나 믿을 수 있는가?

누가 어떤 목적으로 쓰는가?

경계를 넘을 때 무엇을 약속했는가?

각 장을 덮을 때 이 질문에 조금 더 답할 수 있다면
그 장은 제 몫을 한 것이다.

0장. 이 책의 지도

모던 데이터 아키텍처 — 경계와 계약으로 설계하기

제목의 두 낱말이 책 전체를 떠받친다.
경계는 어디서 나눌 것인가이고,
계약은 그 경계를 넘을 때 무엇을 약속할 것인가다.

이 책은 데이터가 여러 시스템에 흩어진 조직에서
아키텍처를 어떻게 설계하고 운영할지 다룬다.

먼저 전체 주장을 한 문장으로 적어 둔다.

비즈니스 경계로 책임을 나누고,
경계를 넘을 때는 명시적인 계약으로 연결하며,
공통 기반은 플랫폼으로 표준화해서
작은 범위부터 점진적으로 확장한다.

나머지 23개 장은 이 문장을 풀어 쓴 것이다.

1. 전체 구조

flowchart TD
    p1["<b>1부 · 문제</b><br/>왜 이런 고민이 생겼는가<br/>1~3장"]
    p2["<b>2부 · 경계</b><br/>무엇을 어디까지 나눌 것인가<br/>4~7장"]
    p3["<b>3부 · 연결</b><br/>경계를 어떻게 넘을 것인가<br/>8~12장"]
    p4["<b>4부 · 제품</b><br/>데이터를 쓸 수 있게 하는 법<br/>13~14장"]
    p5["<b>5부 · 신뢰</b><br/>그 데이터를 믿어도 되는가<br/>15~18장"]
    p6["<b>6부 · 가치</b><br/>어떻게 성과로 바꾸는가<br/>19~20장"]
    p7["<b>7부 · 실행</b><br/>어디서부터 시작하는가<br/>21~23장"]
    p1 --> p2 --> p3 --> p4 --> p5 --> p6 --> p7

각 부는 하나의 질문에 답한다.

2. 읽는 순서

전체를 처음 배운다면 1장부터 순서대로 읽으면 된다.

목적이 분명하다면 아래 경로가 빠르다.

모놀리스에서 서비스를 분리하는 중이라면

flowchart TD
    a["2장<br/>문제 인식"]
    b["4~6장<br/>경계와 소유권"]
    c["7장<br/>무엇을 공개할 것인가"]
    d["8~12장<br/>연결 방법과 선택 기준"]
    e["13장<br/>데이터를 어떻게 넘길 것인가"]
    f["23장<br/>어디서부터 시작할까"]
    a --> b --> c --> d --> e --> f

15~18장은 분리가 끝난 뒤에 읽어도 늦지 않다.

데이터 플랫폼을 만든다면

flowchart LR
    a["3장<br/>이름들의 지도"] --> b["13~15장<br/>제품과 메타데이터"] --> c["19장<br/>소비 환경"] --> d["21~23장<br/>조직과 실행"]

거버넌스를 맡았다면

flowchart LR
    a["2장<br/>책임의 문제"] --> b["6장<br/>데이터 소유권"] --> c["14~18장<br/>품질·메타데이터·보안·기준"] --> d["23장<br/>어디서부터 시작할까"]

3. 반복해서 나오는 개념

몇 개념은 여러 장에 걸쳐 등장한다.
설명을 한 곳에 모아 두었으니 처음 만났을 때
아래 장을 펼치면 된다.

다른 장에서 이 개념이 나오면
한두 문장으로 짚고 넘어간 뒤 해당 장을 가리킨다.

4. 이 책을 읽는 방법

기술 이름을 외우는 책이 아니다.

Kafka, dbt, Debezium 같은 도구는 계속 바뀐다.
바뀌지 않는 것은 아래 질문들이다.

이 데이터는 무엇인가?

누가 책임지는가?

어디에서 왔는가?

얼마나 믿을 수 있는가?

누가 어떤 목적으로 쓰는가?

경계를 넘을 때 무엇을 약속했는가?

각 장을 덮을 때 이 질문에 조금 더 답할 수 있다면
그 장은 제 몫을 한 것이다.

5. 예시에 관하여

설명에는 온라인 쇼핑몰을 예로 든다.

회원 · 상품 · 주문 · 결제 · 배송 · 정산

판매자에게 대금을 지급하는 출금,
유상과 무상으로 나뉘는 포인트도 자주 나온다.

특정 업종에 익숙하지 않아도 읽을 수 있도록
가장 흔한 형태 하나로 통일했다.

6. 부록

본문에서 덜어낸 내용과 참고 자료를 부록에 두었다.

A와 B는 처음 읽을 때 건너뛰어도 된다.

C와 D는 순서대로 읽는 것보다
필요할 때 찾아보는 쪽이 쓸모 있다.

특히 D는 실무에서 결정을 앞두고 다시 보면
흔한 함정을 미리 피할 수 있다.

1장. 데이터는 이미 흩어져 있다

1부 · 문제 — 왜 데이터가 흩어졌고 무엇이 문제인가
1장 · 2장 · 3장

데이터는 왜 한곳에 모이지 않게 되었나

기업이 데이터를 많이 가지고 있다고 해서
곧바로 데이터 중심 조직이 되는 것은 아니다.

데이터 중심 조직은 필요한 데이터를 쉽게 찾고,
그 데이터의 의미를 이해할 수 있으며,
신뢰할 수 있는 상태로 활용할 수 있는 조직이다.

그리고 가장 중요한 것은
데이터가 실제 비즈니스 의사결정과
서비스 개선으로 이어져야 한다는 점이다.

현대의 데이터 환경은 과거와 크게 달라졌다.

클라우드, SaaS, 마이크로서비스, 실시간 처리,
머신러닝과 AI가 보편화되면서
데이터는 더 이상 한곳에만 존재하지 않는다.

이 장에서는 이러한 변화 속에서
왜 기존의 중앙집중형 데이터 관리 방식이
한계에 부딪히기 시작했는지 살펴본다.

1. 데이터 관리란 무엇인가

데이터 관리는 단순히
DB를 안정적으로 운영하는 일이 아니다.

데이터가 만들어진 순간부터
더 이상 필요하지 않아 삭제될 때까지
전체 수명주기를 관리하는 활동이다.

flowchart LR
    n0["생성"] --> n1["수집"] --> n2["저장"] --> n3["가공"] --> n4["공유"] --> n5["분석 / 활용"] --> n6["보관"] --> n7["폐기"]

이 과정에서는 계속 여러 질문이 발생한다.

이 데이터는 정확한가?

누가 이 데이터를 책임지는가?

누가 사용할 수 있는가?

어디에서 만들어졌는가?

어떤 과정을 거쳐 변환되었는가?

얼마나 보관해야 하는가?

개인정보는 안전하게 보호되고 있는가?

따라서 데이터 관리는
기술만의 문제가 아니다.

조직, 정책, 보안, 품질, 책임, 아키텍처가
모두 함께 움직여야 한다.

2. 데이터 관리의 기본 틀: DAMA-DMBOK

앞 절의 말이 추상적으로 들린다면
이 분야의 표준 체계를 한 번 보는 것이 도움이 된다.

대표적인 것이 DAMA-DMBOK다.

데이터 관리를 여러 전문 영역으로 나누고
그 가운데에 데이터 거버넌스를 둔다.

flowchart LR
    G["데이터 거버넌스"]
    G --- A["데이터 아키텍처"]
    G --- B["데이터 모델링"]
    G --- C["저장과 운영"]
    G --- D["보안"]
    G --- E["데이터 통합"]
    G --- F["메타데이터"]
    G --- H["데이터 품질"]
    G --- I["웨어하우징 · BI"]

    style G fill:#e8f4ff,stroke:#4a90e2,stroke-width:3px,color:#1a1a1a

여기서 두 가지만 읽으면 된다.

하나, 데이터 관리는 기술 하나가 아니라 여러 영역의 묶음이다.

앞 절에서 “조직, 정책, 보안, 품질, 책임, 아키텍처가
모두 함께 움직여야 한다“고 한 것이 이 그림이다.

둘, 그 가운데에 거버넌스가 있다.

누가 어떤 기준으로 책임질지 정하지 않으면
나머지 영역을 아무리 잘 만들어도 따로 논다.
거버넌스는 16장 「거버넌스」에서 자세히 다룬다.

이 틀은 지금도 유용하다.

다만 현대의 분산 시스템, 클라우드, 데이터 제품,
실시간 데이터와 같은 환경에서는
이 기본 틀을 새로운 아키텍처 방식과 함께 해석할 필요가 있다.

즉,

DAMA-DMBOK가 잘못됐다기보다는
현대적인 분산 데이터 환경에 맞는 보완이 필요하다

고 이해하는 편이 정확하다.

3. 중앙집중형 데이터 관리가 등장한 이유

과거 기업 시스템은 지금보다 비교적 단순했다.

여러 업무 시스템에서 만들어진 데이터를
한곳에 모아 분석하는 것이 효율적이었다.

대표적인 구조가
엔터프라이즈 데이터 웨어하우스, 즉 EDW다.

flowchart LR
    a["회원 시스템"] --> dw[("Data Warehouse")]
    b["결제 시스템"] --> dw
    c["상품 시스템"] --> dw
    d["회계 시스템"] --> dw
    dw --> bi["BI"] --> rep["보고서"]

이 방식은 매우 큰 장점이 있었다.

여러 시스템에 흩어진 데이터를 통합할 수 있었고,
회사의 공식적인 데이터를 한곳에서 관리할 수 있었다.

여기서 자주 등장하는 개념이

Single Source of Truth

즉, 진실의 단일 원천이다.

다만 이 개념을

모든 데이터를 반드시 하나의 DB에 저장한다

라고 이해하면 안 된다.

더 중요한 의미는

회사가 중요한 지표와 데이터에 대해
어떤 정의를 공식 기준으로 사용할지 합의되어 있다

는 것이다.

예를 들어 회사에서 매출이라는 용어를 사용할 때

결제 성공 금액 - 환불 금액

을 공식 매출이라고 정의했다면
어떤 시스템에서 계산하더라도
동일한 정의를 사용하도록 만드는 것이 중요하다.

물리적으로 데이터가 여러 곳에 존재하더라도
정의와 기준이 일관적이라면
Single Source of Truth의 목표를 달성할 수 있다.

4. 그런데 기업 환경이 크게 변했다

현대 기업의 애플리케이션 구조는
점점 더 분산되고 있다.

과거에는 하나의 거대한 시스템과
하나의 DB를 사용하는 경우가 많았다.

flowchart TD
    subgraph app["하나의 애플리케이션"]
        f1["회원"]
        f2["결제"]
        f3["배송"]
        f4["주문"]
        f5["정산"]
    end
    app --> db[("하나의 DB")]

하지만 지금은 서비스가 여러 개로 나뉘는 경우가 많다.

flowchart LR
    s1["회원 서비스"] --> d1[("회원 DB")]
    s2["결제 서비스"] --> d2[("결제 DB")]
    s3["배송 서비스"] --> d3[("배송 DB")]
    s4["주문 서비스"] --> d4[("주문 DB")]

여기에 클라우드와 외부 서비스까지 추가된다.

사내 DB

AWS / GCP / Azure

S3

Kafka

외부 PG

외부 SaaS

AI 서비스

Data Warehouse

즉 데이터는 애초부터
여러 환경에 분산되어 존재한다.

이러한 상황에서 모든 데이터를 다시 중앙으로 가져와
하나의 팀이 모두 이해하고 관리하는 방식은
조직이 커질수록 부담이 커질 수 있다.

여기서 중요한 점은

중앙집중형이 잘못됐다는 뜻이 아니라는 것이다.

조직이 작고 데이터 구조가 단순하다면
중앙집중형 방식이 오히려 가장 효율적일 수 있다.

문제는 규모가 커지면서
중앙 시스템과 중앙 조직이 모든 요구를 감당하기 어려워질 때다.

5. 분석과 AI가 데이터를 더욱 복잡하게 만든다

과거에는 데이터를 주로
보고서와 통계에 사용했다.

flowchart LR
    n0["데이터"] --> n1["집계"] --> n2["보고서"]

하지만 지금은 같은 데이터를
여러 목적으로 사용한다.

flowchart LR
    src["원본 데이터"] --> a["BI"]
    src --> b["실시간 분석"]
    src --> c["추천 시스템"]
    src --> d["이상 탐지"]
    src --> e["이탈 예측"]
    src --> f["머신러닝 / AI"]

같은 사용자 데이터라도
목적에 따라 다른 형태로 가공된다.

BI용 데이터

추천 모델용 데이터

마케팅 분석용 데이터

ML 학습 데이터

실시간 처리용 데이터

이 과정에서 데이터가 여러 장소로 복제된다.

flowchart LR
    n0["운영 DB"] --> n1["Kafka"] --> n2["S3"] --> n3["Data Warehouse"] --> n4["Feature Store"] --> n5["ML Dataset"]

그리고 새로운 문제가 발생한다.

어느 데이터가 최신인가?

어느 데이터가 공식 데이터인가?

왜 같은 지표인데 값이 다른가?

이 데이터를 누가 책임지는가?

그래서 현대 데이터 환경에서는
데이터 자체만 관리하는 것으로 부족하다.

데이터가 어디에 있고, 무슨 뜻이며, 누가 책임지는지를
함께 관리해야 한다.

6. 1장 정리

세 가지만 기억하면 된다.

데이터 관리는 DB를 안정적으로 운영하는 일이 아니다.
데이터가 만들어진 순간부터 폐기될 때까지
의미·책임·품질·보안을 함께 관리하는 활동이다.

중앙집중형 데이터 웨어하우스는 지금도 유효하다.
다만 클라우드, 마이크로서비스, SaaS, AI가 보편화되면서
데이터는 애초부터 여러 곳에 흩어져 생겨난다.

같은 데이터가 여러 목적으로 복제되기 시작했다.
BI, 추천, 이상 탐지, 학습 데이터가 각각 다른 형태를 요구한다.

그 결과 새로운 질문이 생긴다.

어느 데이터가 최신인가?

어느 데이터가 공식인가?

왜 같은 지표인데 값이 다른가?

다음 장에서는 이 질문들이
왜 저장 기술을 바꾸는 것만으로 풀리지 않는지 본다.

2장. 저장 위치가 아니라 책임의 문제

1부 · 문제 — 왜 데이터가 흩어졌고 무엇이 문제인가
1장 · 2장 · 3장

대시보드 숫자가 이상하다는 연락을 받았다.

어디부터 봐야 할까.
원본 DB인가, 중간 집계 테이블인가, 리포트 로직인가.
그리고 이 데이터는 누구에게 물어봐야 하는가.

1장에서는 데이터가 왜 여러 곳으로 흩어지는지 살펴봤다.

그런데 흩어진 데이터를 다시 모으는 것만으로는
문제가 풀리지 않는다.

이 장에서는 데이터가 많아질 때
무엇이 실제로 발목을 잡는지 본다.

중앙 데이터팀의 병목,
사라지는 비즈니스 맥락,
복잡해지는 파이프라인,
그리고 Data Lake가 해결한 것과 남긴 것이다.

여기까지 오면 질문이 바뀐다.

데이터를 어디에 저장할 것인가

에서

이 데이터는 누가 책임지는가

로 옮겨간다.

1. 중앙 데이터팀의 병목

중앙집중형 구조에서는
데이터 업무가 중앙팀에 집중되는 경우가 많다.

sequenceDiagram
    participant S as 서비스팀
    participant D as 중앙 데이터팀

    S->>D: 데이터 요청
    D->>D: ETL 변경
    D->>D: Warehouse 수정
    D->>D: 검증
    D-->>S: 결과 전달

조직이 작을 때는 괜찮다.

하지만 수많은 도메인이 존재하면
중앙팀이 모든 비즈니스 규칙을 이해하기 어렵다.

예를 들어 주문 데이터만 하더라도

유상 포인트인가?

무상 포인트인가?

출금 가능한가?

프로모션 지급인가?

유효기간이 있는가?

같은 규칙이 존재할 수 있다.

이러한 규칙을 가장 잘 이해하는 사람은
대부분 중앙 데이터팀이 아니라
주문 서비스를 직접 개발하고 운영하는 팀이다.

여기서 현대 데이터 아키텍처의 중요한 질문이 등장한다.

과거에는

데이터를 어디에 저장할 것인가?

가 중요한 질문이었다면,

이제는

누가 이 데이터의 의미와 품질을 책임질 것인가?

라는 질문이 중요해진다.

2. 값만 봐서는 알 수 없다

데이터가 많아질수록
데이터 자체보다 데이터에 대한 정보가 중요해진다.

amount라는 컬럼이 있다고 하자.

이름만으로는 결제 금액인지 주문 금액인지 알 수 없다.
단위가 원인지 포인트인지도 모른다.

이 데이터가 어디에서 만들어져 어디까지 흘러갔는지도 알아야 한다.

앞의 것을 메타데이터, 뒤의 것을 데이터 계보라고 부른다.
둘 다 15장 「메타데이터와 데이터 지도」에서 다룬다.

더 어려운 것은 맥락이다

이름과 단위를 적어 두는 것은 그나마 쉽다.

중앙에서 모든 데이터를 하나의 형태로 통합하려고 하면
원래 데이터가 가지고 있던 비즈니스 맥락이 사라진다.

예를 들어 이런 값이 있다고 하자.

point_amount = 1000

숫자만 보면 단순하다.

하지만 실제 서비스에서는 이에 따라 의미가 완전히 달라진다.

결제로 충전한 포인트인가?

이벤트로 지급한 포인트인가?

출금 가능한 포인트인가?

유효기간이 있는가?

이미 주문으로 사용된 포인트인가?

이것은 컬럼 설명을 잘 적는다고 해결되지 않는다.

이 규칙들은 서비스가 바뀔 때마다 함께 바뀌고,
그 변화를 아는 사람은 그 서비스를 만드는 팀뿐이다.

데이터가 흩어질수록
그 데이터를 설명할 수 있는 사람이 필요해진다.

그리고 그 사람은 대개 중앙팀이 아니라 도메인 팀이다.

이것이 뒤에서 볼 도메인 중심 데이터 소유권으로 이어진다.

3. 중앙 시스템이 복잡해지는 과정

Data Warehouse 자체가 문제인 것은 아니다.

문제는 오랜 기간 수많은 요구사항이 들어오면서
데이터 파이프라인의 의존성이 지나치게 복잡해지는 경우다.

ETL

SQL Script

Batch

Cron

View

임시 테이블

집계 테이블

ML 데이터

BI 데이터

처음에는 서로 독립적이지만
시간이 지나면서 서로 참조하기 시작한다.

flowchart LR
    a["raw_payment"] --> b["payment_clean"] --> c["daily_payment"]
    c --> d["정산"] --> e["회계"]
    c --> f["BI"] --> g["대시보드"]

그 상태에서 작은 컬럼 하나를 변경하려고 해도

이 컬럼을 누가 사용하지?

이 테이블을 변경하면 무엇이 깨지지?

이 ETL은 왜 존재하지?

를 확인해야 한다.

이런 상태를 소프트웨어 분야에서는
Big Ball of Mud,
즉 거대한 진흙덩이에 비유한다.

하지만 이것 역시

Data Warehouse는 시간이 지나면 반드시 이렇게 된다

라는 의미는 아니다.

잘 설계된 모델, 데이터 계약, 메타데이터 관리,
자동 테스트와 변경 관리가 있다면
복잡성을 상당 부분 통제할 수 있다.

즉 문제의 핵심은
중앙 저장소 자체보다 지나친 결합과 관리 부족이다.

4. Data Lake의 등장

기존의 Data Warehouse는
대체로 데이터를 저장하기 전에
구조를 먼저 정의하는 경향이 강했다.

flowchart LR
    n0["원본"] --> n1["정제"] --> n2["변환"] --> n3["스키마 적용"] --> n4["저장"]

이를 흔히

Schema-on-Write

라고 한다.

하지만 미래에 어떤 분석을 할지
미리 알 수 없는 경우가 많다.

그래서 원본에 가까운 데이터를 먼저 보관하고
나중에 사용할 때 필요한 구조로 해석하는
Data Lake가 주목받기 시작했다.

flowchart TD
    hub["Data Lake"]
    s0["DB 데이터"] --> hub
    s1["로그"] --> hub
    s2["JSON"] --> hub
    s3["CSV"] --> hub
    s4["이미지"] --> hub
    s5["영상"] --> hub

전통적으로 이를

Schema-on-Read

라고 설명한다.

다만 이 구분도 절대적인 것은 아니다.

현대의 데이터 레이크나 Lakehouse는
스키마 검증과 데이터 품질 규칙을
저장 시점에도 적용할 수 있다.

따라서 더 정확하게 이해하면 다음과 같다.

전통적인 Warehouse
→ 저장 전에 구조를 강하게 정의하는 경향

전통적인 Data Lake
→ 원본을 먼저 저장하고
   활용 시점에 구조를 적용하는 경향

현대 Lakehouse
→ 두 방식의 장점을 결합하려는 접근

5. Data Lake도 만능은 아니다

Data Lake는 유연한 저장 문제를 해결했지만
조직과 데이터 소유권 문제까지 해결한 것은 아니다.

flowchart TD
    hub["중앙 Data Lake"]
    s0["회원"] --> hub
    s1["결제"] --> hub
    s2["배송"] --> hub
    s3["주문"] --> hub

데이터를 기준 없이 계속 저장하면

이 데이터가 무엇인지 모르겠다.

누가 만들었는지 모르겠다.

어느 파일이 최신인지 모르겠다.

믿고 분석해도 되는지 모르겠다.

라는 상황이 발생할 수 있다.

이런 상태를 흔히
Data Swamp, 즉 데이터 늪이라고 부른다.

따라서 Data Lake 역시

메타데이터, 소유권, 품질, 보안,
카탈로그와 거버넌스가 필요하다.

중요한 교훈은 이것이다.

저장 기술을 바꾸는 것만으로
데이터 관리 문제가 해결되지는 않는다.

6. 2장 정리

세 가지만 기억하면 된다.

데이터가 많아지면 데이터에 대한 정보가 중요해진다.
값만 봐서는 의미를 알 수 없기 때문에
메타데이터와 데이터 계보가 필요해진다.

중앙 데이터팀은 규모가 커질수록 병목이 된다.
모든 도메인의 비즈니스 규칙을 한 팀이 이해하기 어렵고,
중앙으로 모으는 과정에서 원래의 맥락이 사라진다.

Data Lake는 저장 문제를 풀었지만 소유권 문제는 남겼다.
기준 없이 쌓기만 하면 늪이 된다.

그래서 질문이 옮겨간다.

flowchart LR
    n0["데이터를 어디에 저장할 것인가"] --> n1["이 데이터는 누가 책임지는가"]

다음 장에서는 이 문제에 이름을 붙인
여러 접근을 한 번에 정리한다.

3장. 이름들의 지도

1부 · 문제 — 왜 데이터가 흩어졌고 무엇이 문제인가
1장 · 2장 · 3장

“우리도 Data Mesh를 해야 하지 않나요?”

이런 질문을 받았을 때 바로 답하기는 어렵다.
그 이름이 무슨 문제를 풀려고 나왔는지 모르면
도입할지 말지도 판단할 수 없다.

Data Mesh, Data Fabric, DataOps.

데이터 아키텍처를 공부하면
비슷해 보이는 이름들이 쏟아진다.

이 장에서는 각 이름이
어떤 문제를 풀려고 나왔는지만 정리한다.

세부 구현은 뒤에서 하나씩 다루므로
여기서는 지도를 그린다는 느낌으로 읽으면 된다.

마지막에는 1부 전체를 한 번에 정리한다.

1. 중앙집중과 탈중앙화

여기에서 데이터 전략의 중요한 선택이 등장한다.

모든 데이터를 중앙에서 관리하면
통제와 일관성을 확보하기 쉽다.

하지만 조직이 커질수록
중앙팀의 병목이 생길 수 있다.

반대로 각 팀에게 모든 권한을 주면
빠르게 움직일 수 있다.

하지만 각 팀이 제각각 움직이면
새로운 데이터 사일로가 생길 수 있다.

따라서 현실적인 문제는

중앙집중이냐 탈중앙화냐

둘 중 하나를 선택하는 것이 아니다.

무엇을 중앙에서 관리하고
무엇을 도메인에 위임할 것인가

를 결정하는 것이다.

2. 연합형 거버넌스

현대 데이터 아키텍처에서는
중앙과 도메인이 역할을 나누는
연합형 접근이 중요하게 다뤄진다.

flowchart TD
    subgraph center["중앙"]
        c1["보안"]
        c2["개인정보 정책"]
        c3["공통 표준"]
        c4["공통 플랫폼"]
        c5["거버넌스"]
    end
    d1["회원 도메인"]
    d2["결제 도메인"]
    d3["배송 도메인"]
    resp["데이터 의미<br/>데이터 품질<br/>데이터 제공<br/>변경 책임"]

    center --> d1
    center --> d2
    center --> d3
    d1 --> resp
    d2 --> resp
    d3 --> resp

중앙에서 모든 데이터를 직접 관리하지 않는다.

대신 조직 전체가 반드시 지켜야 하는
공통 기준과 플랫폼을 제공한다.

도메인 팀은 자신이 가장 잘 알고 있는
데이터의 의미와 품질을 책임진다.

3. Data Mesh는 단순한 분산이 아니다

Data Mesh를

각 팀이 자기 데이터를 관리한다

정도로만 이해하면 부족하다.

Data Mesh의 핵심에는 크게 네 가지 생각이 있다.

도메인 중심 데이터 소유권,
Data as a Product,
Self-Service Data Platform,
Federated Computational Governance다.

쉽게 말하면 다음과 같다.

따라서 Data Mesh는

모든 것을 각 팀에게 맡기는 완전한 탈중앙화가 아니다.

공통 플랫폼과 거버넌스가 없는 상태에서
팀마다 제각각 데이터를 운영한다면
그것은 Data Mesh라기보다
새로운 데이터 사일로에 가까울 수 있다.

또 Data Mesh가
Data Warehouse나 Data Lake를 반드시 대체하는 것도 아니다.

물리적으로는 같은 Warehouse나 Lake를 사용하면서도
논리적인 데이터 소유권을 도메인에 나눌 수 있다.

4. Data Fabric과 DataOps

Data Mesh와 함께
Data Fabric이라는 개념도 자주 등장한다.

둘은 해결하려는 문제의 초점이 다르다.

Data Mesh가 주로

누가 데이터를 책임지는가?

를 고민한다면,

Data Fabric은

여러 환경에 흩어진 데이터를
어떻게 발견하고 연결하고 관리할 것인가?

에 더 가깝다.

메타데이터와 자동화를 적극적으로 활용해
분산된 데이터의 통합과 관리를 돕는 접근이다.

DataOps는 또 다른 문제를 다룬다.

데이터 파이프라인을
어떻게 빠르고 안정적으로 변경할 것인가?

소프트웨어 분야의 DevOps와 비슷한 철학을
데이터 엔지니어링에 적용한다고 생각하면 쉽다.

flowchart LR
    n0["데이터 코드 변경"] --> n1["자동 테스트"] --> n2["데이터 품질 검사"] --> n3["배포"] --> n4["모니터링"] --> n5["피드백"]

Data Mesh, Data Fabric, DataOps는
반드시 하나만 선택해야 하는 경쟁 개념은 아니다.

서로 다른 문제를 해결하기 때문에
함께 사용할 수도 있다.

5. 이름은 달라도 향하는 곳은 비슷하다

지금까지 본 이름들은 서로 경쟁하는 개념이 아니다.

Data Mesh는 누가 책임지는가를,
Data Fabric은 흩어진 것을 어떻게 연결하는가를,
DataOps는 어떻게 빠르고 안정적으로 바꾸는가를 다룬다.

풀려는 문제가 다르므로 함께 쓸 수 있다.

이 책의 나머지는 이 이름들을 하나씩 풀어 쓴 것이다.

6. 3장 정리

세 가지만 기억하면 된다.

이름들은 경쟁 관계가 아니다.
Data Mesh는 누가 책임지는가를,
Data Fabric은 흩어진 것을 어떻게 연결하는가를,
DataOps는 어떻게 빠르고 안정적으로 바꾸는가를 다룬다.
풀려는 문제가 다르므로 함께 쓸 수 있다.

Data Mesh는 단순한 분산이 아니다.
도메인 소유권, 데이터 제품, 셀프서비스 플랫폼,
연합형 거버넌스가 함께 있어야 한다.
나누기만 하면 새로운 사일로가 된다.

중앙집중이냐 탈중앙화냐를 고르는 문제가 아니다.
무엇을 중앙에서 관리하고 무엇을 도메인에 맡길지 정하는 문제다.

여기까지가 1부다

1부를 하나의 이야기로 보면 다음과 같다.

flowchart TB
    P["과거<br/>──────────<br/>중앙 Data Warehouse로 전사 데이터를 통합해<br/>효율적으로 분석했다"]
    C["환경 변화<br/>──────────<br/>Cloud / SaaS · Microservice · AI / ML<br/>실시간 처리 · 데이터 증가<br/>데이터가 자연스럽게 분산됐다"]
    R["문제 발생<br/>──────────<br/>ETL 복잡성 증가 · 데이터 복제 증가<br/>중앙 데이터팀 병목 · 도메인 맥락 손실<br/>기술 부채 증가"]
    L["Data Lake 등장<br/>──────────<br/>원본을 더 많이 저장하고 유연하게 분석하게 됐지만<br/>소유권 · 품질 · 거버넌스 문제와<br/>중앙집중 문제는 그대로 남았다"]
    H["새로운 관점<br/>──────────<br/>‘어디에 저장할 것인가?’에서<br/>‘누가 책임질 것인가?’로"]
    N["현대적인 방향<br/>──────────<br/>도메인 중심 데이터 소유 · 공통 데이터 플랫폼<br/>연합형 거버넌스 · 메타데이터와 품질 관리<br/>비즈니스 중심 데이터 전략"]

    P --> C --> R --> L --> H --> N

    style P fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style C fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style R fill:#fff4f4,stroke:#d9534f,color:#1a1a1a
    style L fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style H fill:#f8fbff,stroke:#4a90e2,color:#1a1a1a
    style N fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a

1부에서 놓치지 말아야 할 것은 둘이다.

중앙집중형 Data Warehouse와 Data Lake는 지금도 유용하다.
다만 조직 규모와 데이터 복잡성이 커지면
중앙집중적인 운영 모델이 병목이 될 수 있다.

질문이 저장 위치에서 책임으로 옮겨갔다.
어디에 둘 것인가보다 누가 의미와 품질을 책임지는가가 중요해졌다.

현대의 데이터는 이미 여러 시스템과 조직에 분산되어 있다.
모든 것을 중앙으로 모으거나 각 팀에 맡기는 극단보다,
비즈니스 목표를 기준으로 중앙의 통제와 도메인의 자율성을
조율하는 데이터 전략이 필요하다.

다음 부에서는 그 출발점인
경계를 어디에 그을 것인가를 본다.

4장. 좋은 경계의 원리

2부 · 경계 — 어디에 선을 긋고 누가 책임지는가
4장 · 5장 · 6장 · 7장

서비스가 작을 때는 데이터 관리가 어렵지 않다.

애플리케이션도 몇 개 없고,
데이터베이스도 많지 않다.

필요한 데이터가 있으면 테이블을 조회하고,
조금 복잡하면 여러 테이블을 JOIN해서 해결할 수도 있다.

하지만 서비스가 성장하면 상황이 달라진다.

회원
결제
상품
배송
주문
출금
정산
판매자
통계
...

기능과 데이터가 많아지고
여러 팀이 같은 데이터를 사용하기 시작한다.

처음에는 편했던 공용 DB와 직접 조회가
나중에는 변경을 어렵게 만드는 원인이 된다.

이 장에서는 이러한 문제를 해결하기 위해
시스템과 데이터를 비즈니스 경계를 기준으로 나누고,
각 도메인이 자신의 데이터에 책임을 가지는 방법을 알아본다.

단, 목표는 시스템을 무조건 잘게 쪼개는 것이 아니다.

핵심은 다음 질문에 명확하게 답할 수 있는 구조를 만드는 것이다.

이 기능은 누가 책임지는가?
이 데이터는 누가 책임지는가?
다른 영역과는 어떤 계약으로 연결되는가?

1. 왜 경계가 필요한가

1부에서 본 것처럼 데이터는 이미 여러 곳에 흩어져 있고
중앙에서 모두 해석하는 방식은 한계에 부딪힌다.

그렇다고 아무렇게나 나누면
작은 변경 하나가 여러 시스템으로 번진다.

결제 구조를 바꿨더니 ETL이 깨지고
리포트와 통계까지 손봐야 하는 상황이다.

그래서 필요한 것이 경계다.

이 장에서는 소프트웨어 설계가 오래 써 온 두 가지 원칙,
응집도와 결합도에서 출발한다.

2. 좋은 소프트웨어 설계에서 힌트를 얻다

데이터 도메인을 이해하기 전에
소프트웨어 설계의 기본 원칙을 알아야 한다.

핵심은 두 가지다.

응집도는 높이고, 결합도는 낮추는 것이다.

높은 응집도

응집도는 쉽게 말하면

서로 밀접하게 관련된 것들이
얼마나 가까이 모여 있는가

를 의미한다.

예를 들어 주문 영역에는 다음 기능이 있을 수 있다.

flowchart TD
    n0["주문"]
    n1["주문 생성"]
    n2["주문 조회"]
    n3["주문 취소"]
    n4["주문 상태 변경"]
    n5["주문 데이터"]
    n0 --> n1
    n0 --> n2
    n0 --> n3
    n0 --> n4
    n0 --> n5

이 기능들은 모두 주문이라는
같은 비즈니스 문제를 다룬다.

따라서 같은 경계 안에 있으면
이해하기도 쉽고 변경하기도 쉽다.

반대로 같은 주문을 다루는 기능이
이렇게 흩어져 있다면 복잡해진다.

flowchart LR
    A["시스템 A<br/>주문 생성"]
    B["시스템 B<br/>주문 조회"]
    C["시스템 C<br/>주문 취소"]
    D["시스템 D<br/>주문 상태"]

    style A fill:#fff4f4,stroke:#d9534f,color:#1a1a1a
    style B fill:#fff4f4,stroke:#d9534f,color:#1a1a1a
    style C fill:#fff4f4,stroke:#d9534f,color:#1a1a1a
    style D fill:#fff4f4,stroke:#d9534f,color:#1a1a1a

주문 규칙 하나를 바꾸려면 네 곳을 손봐야 한다.

좋은 설계에서는
함께 변경되는 것들을 가능한 한 함께 둔다.

낮은 결합도

결합도는

한 시스템이 다른 시스템의 내부 구조를
얼마나 많이 알아야 하는가

를 의미한다.

예를 들어 주문 시스템이
결제 DB를 직접 조회한다고 해보자.

flowchart LR
    n0["주문 시스템"] --> n1["결제 테이블 직접 SELECT"]

주문 시스템이 결제 DB의

테이블 이름,
컬럼 이름,
JOIN 관계

를 알아야 한다.

그러면 결제팀이 내부 테이블을 변경할 때
주문 시스템까지 영향을 받을 수 있다.

반대로 명확한 인터페이스를 두면 달라진다.

flowchart LR
    n0["주문"]
    n1["결제 인터페이스"]
    n2["결제 내부 로직"]
    n3["결제 DB"]
    n0 -- "결제 요청" --> n1
    n1 --> n2
    n2 --> n3

주문은 결제 내부가 어떻게 구현되었는지
알 필요가 없다.

결제 내부 구조가 변경되더라도
외부 계약만 유지하면 된다.

좋은 아키텍처의 중요한 목적 중 하나는

변경의 영향을 자신의 경계 안에 가두는 것

이다.

3. 경계를 만들고 계약으로 연결한다

하나의 시스템에는
외부에 공개해야 할 부분과
내부에서만 알아야 할 부분이 있다.

예를 들어 결제 시스템을 생각해보자.

flowchart LR
    OTHER["다른 시스템"]

    subgraph PAYMENT["결제 시스템"]
        API["외부 계약<br/><br/>결제 요청<br/>결제 취소<br/>결제 상태 조회"]

        subgraph IMPL["🔒 내부 구현"]
            PG["PG 연동"]
            RETRY["실패 재처리"]
            DB["결제 테이블"]
            STATE["내부 상태 관리"]
        end

        API --> IMPL
    end

    OTHER -->|"계약을 통해서만 접근"| API

    style API fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a
    style IMPL fill:#f5f5f5,stroke:#999,stroke-dasharray: 5 5,color:#1a1a1a

다른 시스템은 외부에 공개된 계약만 사용한다.

결제 내부의 테이블 구조까지
알 필요가 없다.

이를 흔히 캡슐화라고도 한다.

이 원칙은 나중에 데이터에도 그대로 적용된다.

내부 데이터 모델을 그대로 공개하지 말고
필요한 형태의 명확한 계약으로 제공하자.

4. 마이크로서비스에서 배우는 것

마이크로서비스의 큰 장점은
각 서비스를 독립적으로 개발하고 배포할 수 있다는 것이다.

회원 서비스

주문 서비스

결제 서비스

상품 서비스

상품 기능을 변경하면
상품 서비스만 수정하고 배포할 수 있다.

하지만 여기서 중요한 점이 있다.

서비스를 많이 나눈다고
좋은 아키텍처가 되는 것은 아니다.

서비스가 많아지면
다음과 같은 구조가 만들어질 수 있다.

flowchart LR
    A["A"] --> B["B"]
    A --> C["C"]
    B --> D["D"]
    C --> D
    D --> E["E"]
    E --> B

    style E fill:#fff4f4,stroke:#d9534f,color:#1a1a1a

누가 누구에게 의존하는지 파악하기 어려워진다.

특히 E → B처럼 되돌아오는 연결이 생기면
한 바퀴 도는 의존이 만들어진다.

서비스 하나의 장애가
다른 서비스로 전파될 수도 있다.

즉 물리적으로 서비스를 나누었지만
논리적으로는 여전히 강하게 결합되어 있을 수 있다.

5. Service Mesh가 해결하는 것과 해결하지 못하는 것

서비스가 많아지면

라우팅,
재시도,
타임아웃,
보안,
모니터링

같은 공통 통신 기능이 필요하다.

이런 운영상의 복잡성을 관리하기 위해
Service Mesh 같은 기술을 사용할 수 있다.

하지만 한 가지 주의해야 한다.

Service Mesh가 해결하는 것은 주로

서비스 간 통신의 기술적·운영적 복잡성

이다.

다음 질문까지 해결해주는 것은 아니다.

A 서비스가 정말 B 서비스를 호출해야 하는가?

이것은 기술 문제가 아니라
도메인 설계 문제다.

따라서 잘못된 비즈니스 경계를
Service Mesh가 해결해주는 것은 아니다.

6. 4장 정리

세 가지만 기억하면 된다.

함께 변경되는 것은 함께 둔다.
이것이 높은 응집도다.

다른 시스템의 내부 구조를 알아야 한다면 결합도가 높은 것이다.
명확한 인터페이스를 두면
상대의 내부가 바뀌어도 영향을 받지 않는다.

좋은 아키텍처의 목적은 변경의 영향을 경계 안에 가두는 것이다.
서비스를 많이 나누는 것 자체는 목적이 아니다.
물리적으로 나눠도 논리적으로 강하게 묶여 있을 수 있고,
Service Mesh 같은 기술이 잘못 그은 경계를 고쳐주지도 않는다.

그렇다면 남는 질문은 하나다.

경계를 어디에 그을 것인가

다음 장에서 그 방법을 본다.

5장. 비즈니스로 도메인 나누기

2부 · 경계 — 어디에 선을 긋고 누가 책임지는가
4장 · 5장 · 6장 · 7장

“이 기능은 어느 팀이 맡나요?”

회의에서 이 질문이 나왔는데
아무도 선뜻 답하지 못한 적이 있는가.

기능은 분명히 동작하고 있는데
책임의 경계가 어디인지는 아무도 모르는 상태다.

4장에서 좋은 경계의 원리를 봤다.

그렇다면 실제로 어디에 선을 그어야 할까.

이 장에서는 도메인 주도 설계가 제안하는 방법을 본다.

Domain과 Subdomain,
Bounded Context,
유비쿼터스 언어,
그리고 비즈니스 역량이다.

기술 구조가 아니라
비즈니스 문제를 기준으로 나누는 것이 핵심이다.

1. 도메인 주도 설계란?

답해야 할 질문은 이런 것들이다.

서비스를 어디까지 하나로 볼 것인가?

데이터를 누가 책임질 것인가?

어떤 기능끼리 함께 있어야 하는가?

이 질문에 답하는 방법으로 도메인 주도 설계(DDD) 가 있다.

DDD의 핵심은 단순하다.

기술 구조보다
실제 비즈니스 문제를 먼저 이해하자.

예를 들어 어떤 플랫폼이 다음 기능을 제공한다고 해보자.

회원
상품
결제
주문
출금
정산
판매자 관리

DDD에서는 처음부터

payment_table
order_log
payout_history

같은 테이블 구조부터 생각하지 않는다.

먼저 다음을 질문한다.

결제는 어떤 책임을 가지는가?

주문은 무엇을 의미하는가?

출금에는 어떤 규칙이 있는가?

어떤 규칙들이 함께 변경되는가?

어디까지를 하나의 문제 영역으로 볼 것인가?

이렇게 비즈니스를 이해하면서
자연스러운 경계를 발견한다.

2. Domain과 Subdomain

Domain은 우리가 해결하려는
비즈니스 문제 영역이다.

그런데 회사 전체의 비즈니스는 너무 크다.

그래서 큰 문제를
더 작은 문제 영역으로 나눈다.

이를 Subdomain이라고 한다.

예를 들어 커머스라는 큰 영역이 있다면

flowchart TD
    n0["커머스"]
    n1["상품"]
    n2["주문"]
    n3["결제"]
    n4["환불"]
    n0 --> n1
    n0 --> n2
    n0 --> n3
    n0 --> n4

처럼 나누어 볼 수 있다.

여기서 중요한 기준은
프로그램이나 테이블의 개수가 아니다.

비즈니스 문제가 서로 다른가가 핵심이다.

3. Bounded Context

DDD에서 가장 중요한 개념 중 하나가
Bounded Context다.

쉽게 말하면

같은 모델과 용어가
일관된 의미를 가지는 경계

라고 이해하면 된다.

예를 들어 상품이라는 단어가 있다고 하자.

커머스에서는

상품
= 고객에게 판매하는 대상

일 수 있다.

정산에서는

상품
= 매출과 지급 금액을 계산하기 위한 대상

일 수 있다.

통계에서는

상품
= 매출 분석을 위한 분류 단위

일 수도 있다.

같은 상품이라는 단어지만
필요한 정보와 규칙은 다르다.

그래서 모든 시스템이
하나의 거대한 상품 모델을 공유하게 만들 필요가 없다.

flowchart LR
    subgraph c1["커머스 Context"]
        a1["상품"]
        a2["판매 가격"]
        a3["판매 상태"]
    end
    subgraph c2["정산 Context"]
        b1["상품"]
        b2["매출"]
        b3["정산 금액"]
    end

각 Context 안에서
자신에게 필요한 모델을 가지면 된다.

4. Ubiquitous Language

Bounded Context와 함께 알아야 할 것이
Ubiquitous Language다.

쉽게 말하면

같은 Context 안에서는
현업, 기획자, 개발자가
같은 용어를 같은 의미로 사용하자.

는 것이다.

예를 들어 조직에서

출금 환산율
출금 환산단가
판매자 지급단가

를 섞어서 사용한다고 해보자.

세 용어가 정말 같은 개념이라면
하나로 통일하는 편이 좋다.

반대로 실제 규칙이 다르다면
서로 다른 이름을 사용해야 한다.

언어의 차이는 단순한 표현 문제가 아니다.

모델이 다른 것을 발견하는 단서가 되기도 한다.

예를 들어

구매 취소
환불
PG 취소

를 모두 같은 의미로 사용하고 있었는데
업무를 자세히 보면

구매 취소
= 주문 자체의 취소

환불
= 사용자에게 돈을 반환

PG 취소
= PG 승인 거래의 취소

처럼 실제로는 다른 개념일 수 있다.

5. 비즈니스 역량

도메인의 경계를 찾는 또 다른 관점은
Business Capability, 즉 비즈니스 역량이다.

쉽게 말하면

회사가 비즈니스를 수행하기 위해
할 수 있어야 하는 일

이다.

예를 들어 커머스 회사라면 이런 것들을 할 수 있어야 한다.

상품을 등록하고 노출한다
주문을 받고 처리한다
결제를 승인하고 취소한다
상품을 배송한다
판매자에게 정산한다
고객 문의에 응대한다

앞에서 본 도메인 목록과 비슷해 보이지만
표현이 다르다는 점을 보자.

도메인은 주문처럼 영역을 가리키고,
역량은 주문을 받고 처리한다처럼 할 수 있는 일을 가리킨다.

이것은 조직도와 다르다.

개발1팀
개발2팀
운영팀
사업팀

은 조직 구조다.

조직은 자주 바뀔 수 있지만

결제
예약
주문
정산
출금

같은 영역에서 하는 일은
상대적으로 오래 유지된다.

기술도 마찬가지다.

PHP에서 Go로 바뀌어도

고객의 결제를 처리한다.

라는 비즈니스 능력은 남는다.

6. 비즈니스 역량과 Bounded Context는 같은 것이 아니다

여기서 주의해야 한다.

비즈니스 역량과 Bounded Context는
서로 밀접하게 관련되어 있지만
동일한 개념은 아니다.

비즈니스 역량은

우리가 무엇을 할 수 있는가?

에 초점을 둔다.

Bounded Context는

어디까지 같은 모델과 언어를 사용할 것인가?

에 초점을 둔다.

따라서 다음처럼 기계적으로 생각하면 안 된다.

비즈니스 역량 하나
=
Bounded Context 하나
=
애플리케이션 하나
=
DB 하나

실제 설계에서는
서로 잘 맞춰보는 것이 좋지만
반드시 1:1일 필요는 없다.

7. 조직과 Context는 어떤 관계인가

Bounded Context를 현재 조직도에 억지로 맞추는 것은 좋지 않다.

조직은 자주 바뀌지만 비즈니스 문제는 그렇지 않기 때문이다.

그렇다고 조직 구조가 아무 관련이 없는 것도 아니다.

어떤 팀이 어떤 업무를 담당하는지,
어떤 사람들끼리 자주 대화하는지,
어떤 용어를 공유하는지는
도메인 경계를 발견하는 중요한 단서가 된다.

도메인이 조직도에 종속될 필요는 없지만
조직과 의사소통 구조는 경계를 찾는 중요한 정보다.

한 Context에 책임 팀이 하나면 좋다

이상적으로는 하나의 Bounded Context에
명확한 책임 팀이 있는 것이 좋다.

flowchart LR
    n0["주문 Context"] --> n1["주문 담당 팀"]

그러면 누가 변경하는지, 누가 장애를 책임지는지,
누가 정책을 결정하는지가 명확해진다.

하지만 절대 규칙은 아니다.

큰 Context를 여러 팀이 담당할 수도 있고,
작은 회사에서는 한 팀이 여러 Context를 담당할 수도 있다.

핵심은 팀의 개수가 아니다.

책임의 주체가 명확한가

8. 물리적 시스템과 논리적 도메인은 다르다

현실에서는 하나의 오래된 시스템이

회원
결제
주문
출금
통계

를 모두 가지고 있을 수 있다.

물리적으로는 하나의 애플리케이션이다.

하지만 이것이
하나의 도메인이라는 뜻은 아니다.

예를 들어 하나의 MariaDB에

customer
payment
order
point
payout
product

가 들어 있다고 해보자.

논리적으로는 다음처럼 볼 수 있다.

flowchart LR
    subgraph db["하나의 MariaDB"]
        c["고객 Domain · customer"]
        p["결제 Domain · payment"]
        o["주문 Domain · order"]
        w["출금 Domain · payout"]
    end

따라서 다음 공식은 성립하지 않는다.

DB 1개 = Domain 1개

Application 1개 = Domain 1개

Microservice 1개 = Domain 1개

도메인은 물리적인 배치보다
비즈니스 책임과 모델의 경계로 판단한다.

9. 5장 정리

세 가지만 기억하면 된다.

도메인은 비즈니스 문제로 나눈다.
테이블이나 프로그램 개수가 기준이 아니다.

Bounded Context는 같은 용어가 일관된 의미를 갖는 경계다.
같은 상품이라도 판매·정산·통계에서
필요한 정보와 규칙이 다르다.
그래서 하나의 거대한 공통 모델을 만들 필요가 없다.

물리적 배치와 논리적 경계는 다른 문제다.

DB 1개 = Domain 1개

Application 1개 = Domain 1개

Microservice 1개 = Domain 1개

이 공식은 성립하지 않는다.
하나의 DB 안에서도 도메인 경계를 그을 수 있다.

다음 장에서는 경계를 나눈 뒤에 따라오는 질문,
즉 데이터를 누가 책임지는가를 본다.

6장. 데이터 소유권

2부 · 경계 — 어디에 선을 긋고 누가 책임지는가
4장 · 5장 · 6장 · 7장

값이 이상하다는 이야기가 나왔다.

그런데 여러 팀에서 같은 답이 돌아온다.

“그건 저희가 만든 데이터가 아닌데요.”

분명히 어딘가에서 만들어진 데이터인데
아무도 자기 것이라고 하지 않는다.

경계를 나눴다면 다음 질문이 따라온다.

이 데이터는 누가 책임지는가

이 장에서는 데이터 도메인과 데이터 소유권을 다룬다.

복사했다고 소유권이 옮겨가지 않는다는 것,
하나의 도메인이 여러 데이터 제품을 가질 수 있다는 것,
그리고 분산이 각자 마음대로가 아니라는 것이다.

1. 데이터 도메인

이제 이 생각을 데이터에 적용해보자.

예를 들어 주문이라는 비즈니스 영역이 있다면

flowchart LR
    n0["주문 Domain"]
    n1["주문 규칙"]
    n2["주문 Application"]
    n3["주문 Data"]
    n0 --> n1
    n0 --> n2
    n0 --> n3

처럼 볼 수 있다.

여기서 데이터 도메인은

어떤 비즈니스 영역이
어떤 데이터에 책임을 가지는가

를 나타낸다.

데이터가 어느 DB에 저장되어 있는지만 보는 것이 아니다.

2. Data Ownership

도메인을 나누었다면
다음 질문을 해야 한다.

이 데이터는 누가 책임지는가?

이것이 Data Ownership이다.

데이터 소유권은 단순히
테이블을 만든 사람이 누구인가를 뜻하지 않는다.

도메인은 자신의 데이터에 대해

의미,
품질,
변경,
접근 권한,
보안,
개인정보,
제공 방식

등을 책임져야 한다.

예를 들어 주문 데이터의 값이 이상하다면

이 데이터가 맞는지
누가 최종적으로 판단할 것인가?

라는 질문에 답할 수 있어야 한다.

3. 복사했다고 소유권이 바뀌는 것은 아니다

주문 데이터를 출금 도메인으로 전달했다고 해보자.

flowchart LR
    n0["주문 Domain"]
    n1["출금 Domain"]
    n0 -- "데이터 제공" --> n1

출금 시스템이 이 데이터를 저장했다고 해서
원본 주문 데이터의 소유자가 바뀌는 것은 아니다.

출금 쪽에서

필터링하고,
JOIN하고,
이름을 바꾸고,
새로운 값을 계산해도

원본 주문 데이터에 대한 책임은
여전히 주문 도메인에 있을 수 있다.

대신 출금 도메인이 새롭게 계산한

출금 가능 금액
출금 상태
출금 처리 결과

같은 데이터는
출금 도메인의 책임이 된다.

이렇게 어떤 데이터의 어떤 의미를 누가 책임지는가를
명확하게 해야 한다.

4. Data Product

소유권을 정했다면 그것을 밖에서도 알 수 있어야 한다.

데이터를 다른 사람이 믿고 쓸 수 있도록
관리해서 제공하는 형태를 Data Product라고 부른다.

중요한 것은 이것이다.

Data Product는 단순한 테이블 하나가 아니다.

데이터와 함께 스키마, 의미 설명, 품질 기준,
접근 정책, 메타데이터, 제공 인터페이스를 같이 생각한다.

그래야 사용자가 이 질문에 답할 수 있다.

이 데이터를 믿고 사용해도 되는가?

한 가지 덧붙이면, Data Mesh에서 말하는 Data Product는
원래 분석용 데이터를 중심에 둔 개념이다.

실무에서는 운영 API나 도메인 인터페이스까지
넓게 부르는 경우도 있다.

무엇을 갖춰야 데이터 제품이라고 부를 수 있는지는
13장 「데이터 프로덕트」에서 자세히 다룬다.

이 장에서는 도메인이 소유권을 드러내는 형태
정도로 생각하면 충분하다.

5. 도메인은 여러 데이터 제품을 가질 수 있다

하나의 도메인이
반드시 데이터 제품 하나만 제공하는 것은 아니다.

예를 들어 주문 도메인에서

flowchart LR
    n0["주문 Domain"]
    n1["원천 주문 데이터"]
    n2["분석용 주문 데이터"]
    n3["판매자 실적 데이터"]
    n4["일별 주문 집계 데이터"]
    n0 --> n1
    n1 --> n2
    n1 --> n3
    n1 --> n4

처럼 여러 데이터 제품을 만들 수 있다.

따라서

Domain 1개
=
Data Product 1개

가 아니다.

6. 분산형 데이터 관리

기존에는 데이터 관리 책임이
중앙 데이터 조직에 집중되어 있었다.

flowchart LR
    s0["회원"] --> hub
    s1["결제"] --> hub
    s2["주문"] --> hub
    s3["출금"] --> hub
    hub["중앙 데이터팀"]

    style hub fill:#fff4f4,stroke:#d9534f,stroke-width:2px,color:#1a1a1a

도메인 중심 구조에서는 책임을 나눈다.

• 회원 Domain — 회원 데이터 책임
• 결제 Domain — 결제 데이터 책임
• 주문 Domain — 주문 데이터 책임
• 출금 Domain — 출금 데이터 책임

이것이 Data Mesh가 말하는 중요한 방향 가운데 하나다.

분산은 ’각자 마음대로’가 아니다

여기서 매우 흔한 오해가 있다.

중앙 관리를 걷어내면 각 팀이 알아서 하면 된다는 생각이다.

그렇게 하면 같은 의미의 데이터가 제각각 만들어진다.

user_id
member_no
uid
account_key

날짜 형식, 개인정보 처리 방식,
품질 기준, 보안 정책도 모두 달라진다.

그래서 도메인 자율성과 함께 공통 기준이 필요하다.

flowchart LR
    GOV["공통 기준<br/>──────────<br/>표준 · 보안 · 품질<br/>개인정보 · 메타데이터"]

    GOV --> A["결제<br/>자율 관리"]
    GOV --> B["주문<br/>자율 관리"]
    GOV --> C["출금<br/>자율 관리"]

    style GOV fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a

Data Mesh에서는 이 방향을 Federated Governance라고 부른다.

중앙에서 모든 데이터를 직접 관리하지는 않지만
회사 전체가 따라야 하는 기준은 함께 만든다.

7. Data Sprawl

분산형 데이터 환경의 위험 가운데 하나는
데이터가 여기저기 무질서하게 퍼지는 것이다.

flowchart TD
    src["원본 데이터"] --> a["운영 DB"]
    src --> b["Redis"]
    src --> c["DW"]
    src --> d["S3"]
    src --> e["팀 A DB"]
    src --> f["팀 B DB"]
    src --> g["개인 분석 데이터"]

어느 순간

어떤 것이 진짜 원본인가?

를 알기 어려워진다.

이를 Data Sprawl이라고 볼 수 있다.

따라서 데이터가 복제되더라도

원본은 어디인가?

누가 소유하는가?

어디로 전달되는가?

누가 소비하는가?

얼마나 최신인가?

를 추적할 수 있어야 한다.

8. 처음부터 완벽하게 바꾸려고 하지 않는다

오래 운영한 시스템에는 이미

공용 DB
직접 JOIN
공통 테이블
배치
ETL
레거시 코드

가 복잡하게 얽혀 있을 수 있다.

이것을 한 번에 모두 뜯어고치는 것은 위험하다.

먼저 현재 구조를 파악해야 한다.

AS-IS

어떤 서비스가
어떤 테이블을 읽는가?

누가 데이터를 수정하는가?

어떤 시스템이 직접 연결되어 있는가?

데이터 원본은 어디인가?

그다음 목표 구조를 설계한다.

flowchart LR
    n1["도메인 경계 정의"] --> n2["데이터 소유권 정의"] --> n3["불필요한 직접 의존 제거"] --> n4["공개 인터페이스 정의"] --> n5["점진적으로 확대"]

    style n5 fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a

작은 영역부터 적용하면서
경험을 쌓는 것이 현실적이다.

9. 6장 정리

세 가지만 기억하면 된다.

데이터 소유권은 테이블을 만든 사람이 누구인가가 아니다.
의미·품질·변경·접근 정책을 책임지는 주체를 말한다.

복사했다고 소유권이 옮겨가지 않는다.
다만 받은 데이터로 새로운 값을 계산했다면
그 값에는 새로운 소유자가 생긴다.

분산은 각자 마음대로가 아니다.
같은 의미의 데이터가 팀마다 다른 이름을 갖고,
날짜 형식과 품질 기준이 제각각이 되면
도메인을 나눈 의미가 없어진다.

그래서 도메인 자율성과 공통 거버넌스가 함께 가야 한다.

다음 장에서는 경계를 넘어
다른 도메인에 데이터를 넘기는 방법을 본다.

7장. 무엇을 공개하고 무엇을 감출 것인가

2부 · 경계 — 어디에 선을 긋고 누가 책임지는가
4장 · 5장 · 6장 · 7장

떼어내기로 한 서비스가 있다.

그런데 코드를 뒤져 보니
다른 팀 여러 곳에서 그 서비스의 테이블을
직접 조회하고 있다.

테이블 이름 하나만 바꿔도
어디가 깨질지 알 수 없는 상태다.

도메인을 잘 나누면 곧바로 현실적인 문제가 생긴다.

다른 도메인의 데이터가 필요하면 어떻게 하지?

이 장에서는 경계를 넘는 방법을 다룬다.

핵심은 하나다.
내부 데이터 모델과 외부 공개 계약을 나누는 것이다.

모놀리스에서 서비스를 떼어내는 중이라면
이 장이 가장 먼저 쓰인다.

1. 다른 도메인이 데이터를 필요로 한다면

도메인을 잘 나누면
다음 문제가 생긴다.

다른 도메인의 데이터가 필요하면 어떻게 하지?

예를 들어 출금에서
주문 데이터가 필요하다고 해보자.

가장 쉬운 방법은

flowchart LR
    n0["출금"] --> n1["주문 DB 직접 조회"]

다.

처음에는 편하다.

하지만 출금 시스템이 주문 DB의

테이블 구조,
컬럼,
JOIN 관계

까지 알게 된다.

결국 두 도메인이 다시 강하게 결합된다.

2. 공개 인터페이스를 만든다

대신 주문 도메인이
외부에 사용할 수 있는 계약을 제공할 수 있다.

flowchart LR
    WD["출금 Domain"]

    subgraph ORDER["주문 Domain"]
        CONTRACT["공개 인터페이스<br/><br/>판매자 ID<br/>주문 금액<br/>주문 시간<br/>포인트 유형"]

        subgraph INNER["🔒 내부 구현"]
            T1["order"]
            T2["order_detail"]
            T3["point_usage"]
            T4["…"]
        end

        CONTRACT --> INNER
    end

    WD -->|"공개된 계약만 사용"| CONTRACT

    style CONTRACT fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a
    style INNER fill:#f5f5f5,stroke:#999,stroke-dasharray: 5 5,color:#1a1a1a

출금 도메인은 이 네 가지만 알면 된다.

내부에서 몇 개의 테이블을 JOIN했는지는
알 필요가 없다.

이런 역할을 Data Provider라고 부르기도 한다.
다만 DDD의 표준 용어는 아니다.

핵심은 이름이 아니라

내부 데이터 구조와
외부 공개 계약을 분리한다.

는 원칙이다.

3. API만이 유일한 방법은 아니다

도메인 간 데이터를 전달한다고 해서
항상 HTTP API만 사용해야 하는 것은 아니다.

상황에 따라 여러 방법을 사용할 수 있다.

API

Domain Event

Message Broker

CDC

Data Pipeline

Data Product

Read Model

중요한 것은 어떤 기술을 사용하느냐보다

누가 생산자이고
누가 소비자이며
데이터의 의미와 책임이 어디에 있는가

가 명확해야 한다는 것이다.

4. 중간 시스템이 있다고 잘못된 구조는 아니다

데이터가 반드시 생산자에서 소비자로
직접 전달되어야 하는 것은 아니다.

예를 들어 다음 구조도 충분히 가능하다.

flowchart LR
    n0["주문 Domain"] --> n1["Kafka"] --> n2["출금 Domain"]

또는

flowchart LR
    n0["운영 DB"] --> n1["CDC"] --> n2["데이터 플랫폼"] --> n3["분석용 Data Product"]

도 가능하다.

문제는 Kafka나 파이프라인 자체가 아니다.

문제는 이런 구조다.

flowchart LR
    n0["원본 DB"] --> n1["ETL"] --> n2["공통 DB"] --> n3["또 다른 ETL"] --> n4["중간 DB"] --> n5["소비 시스템"]

    style n2 fill:#fff4f4,stroke:#d9534f,color:#1a1a1a
    style n4 fill:#fff4f4,stroke:#d9534f,color:#1a1a1a

이쯤 되면 소비 시스템 쪽에서 이런 질문이 나온다.

그래서 이 데이터의 주인이 누구지?

중간 시스템 때문에
데이터 출처와 의미와 소유권이 흐려지는 것이 문제다.

따라서 정확한 원칙은 다음과 같다.

중간 시스템을 쓰지 말라는 것이 아니라
중간 시스템 때문에 데이터 소유권과 의미가
사라지게 만들지 말자.

5. 소비자가 사용하기 좋은 데이터를 제공한다

내부 테이블을 그대로 공개하는 것보다
소비자가 필요한 데이터 모델을 제공하는 것이 좋다.

예를 들어 출금에서는

판매자 ID
주문 금액
포인트 유형
출금 가능 여부

가 중요할 수 있다.

반면 분석에서는

날짜
판매자
구매자
주문 금액
주문 시간

이 필요할 수 있다.

따라서 하나의 원천에서
여러 형태의 데이터가 나올 수 있다.

flowchart TD
    d["주문 Domain"] --> a["분석용 Data"]
    d --> b["실적용 Data"]
    d --> c["집계용 Data"]

하지만 소비자마다
모든 요구를 별도 모델로 만들어주는 것도 좋지 않다.

생산자가 소비자 요구에
지나치게 끌려다닐 수 있기 때문이다.

따라서

재사용성과
소비 편의성

사이의 균형이 필요하다.

6. 타 도메인 DB 직접 접근은 무조건 금지인가?

원칙적으로 비즈니스 로직에서

출금 → 주문 내부 테이블 직접 수정

같은 구조는 피하는 것이 좋다.

도메인 경계를 무너뜨리기 쉽기 때문이다.

하지만

다른 도메인 테이블을
어떤 상황에서도 읽으면 안 된다.

는 절대 법칙은 아니다.

예를 들어

분석,
통계,
CQRS Read Model,
Materialized View

처럼 여러 도메인의 데이터를
결합해야 하는 목적이 있을 수 있다.

따라서 더 정확한 원칙은

도메인의 핵심 비즈니스 로직이
다른 도메인의 내부 구현에 직접 의존하지 않게 한다.

라고 이해하는 것이 좋다.

7. 도메인 안은 강하게, 도메인 사이는 느슨하게

지금까지 배운 원칙을
가장 간단하게 표현하면 다음과 같다.

flowchart TD
    subgraph d1["주문 Domain · 내부는 높은 응집도"]
        a1["주문 규칙"]
        a2["주문 Application"]
        a3["주문 Data"]
    end
    subgraph d2["출금 Domain · 내부는 높은 응집도"]
        b1["출금 규칙"]
        b2["출금 Application"]
        b3["출금 Data"]
    end
    d1 -- "명확한 계약" --> d2

즉,

경계 안은 밀접하게 만들고
경계를 넘을 때는 느슨하게 만든다.

이 원칙이 DDD와 데이터 도메인을
관통하는 핵심이다.

8. 7장 정리

세 가지만 기억하면 된다.

내부 데이터 모델과 외부 공개 계약을 나눈다.
다른 도메인은 계약만 보고, 내부에 몇 개의 테이블이 있는지는 모른다.
그래야 내부를 바꿔도 밖이 깨지지 않는다.

계약이 반드시 API인 것은 아니다.
API, 도메인 이벤트, 메시지 브로커, CDC,
데이터 파이프라인, 데이터 제품 모두 계약이 될 수 있다.
중요한 것은 기술이 아니라 누가 생산자이고 의미를 누가 책임지는가다.

“남의 DB는 절대 읽지 마라“가 원칙은 아니다.
분석이나 조회 모델처럼 여러 도메인을 결합해야 하는 목적이 있다.
정확한 원칙은 이것이다.

도메인의 핵심 비즈니스 로직이
다른 도메인의 내부 구현에 직접 의존하지 않게 한다.

여기까지가 2부다

4장부터 7장까지를 하나로 이으면 다음과 같다.

flowchart TB
    S1["문제<br/>──────────<br/>서비스가 성장하며 시스템과 데이터가 얽히고<br/>변경 하나의 영향 범위를 알 수 없게 된다"]
    S2["원리<br/>──────────<br/>함께 변하는 것은 함께 두고<br/>남의 내부를 알아야 하는 연결은 줄인다"]
    S3["경계 긋기<br/>──────────<br/>기술이 아니라 비즈니스 문제로 나눈다<br/>Domain · Bounded Context · 유비쿼터스 언어"]
    S4["책임 정하기<br/>──────────<br/>각 도메인이 자기 데이터의<br/>의미와 품질을 책임진다"]
    S5["경계 넘기<br/>──────────<br/>API · Event · Data Product 같은<br/>명시적인 계약으로 연결한다"]

    S1 --> S2 --> S3 --> S4 --> S5

    style S1 fill:#fff4f4,stroke:#d9534f,color:#1a1a1a
    style S2 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S3 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S4 fill:#f8fbff,stroke:#4a90e2,color:#1a1a1a
    style S5 fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a

2부에서 가장 중요한 것은
시스템을 많이 쪼개는 기술이 아니다.

세 가지를 명확하게 만드는 것이다.

무엇을 책임지는가
어떤 데이터를 책임지는가
다른 영역과 어떤 계약으로 연결되는가

그래서 데이터 도메인이란

DB를 기준으로 데이터를 나누는 것이 아니라
비즈니스 책임을 기준으로 경계를 만들고
각 영역이 자신의 데이터에 책임을 가지게 하는 것

이다.

하나의 DB를 쓴다고 도메인 중심 설계를 못 하는 것이 아니고,
마이크로서비스를 수십 개로 나눴다고 좋은 설계가 되는 것도 아니다.

여기에 도메인의 자율성과 전사 공통 거버넌스가 더해질 때
규모가 커져도 감당할 수 있는 구조가 된다.

이 부에서 나온 용어는 부록 C 「용어집」의
「경계와 도메인」 항목에 정리해 두었다.

다음 부에서는 여기서 정한 계약을
무엇으로 구현할 것인가를 본다.

8장. API로 연결하기

3부 · 연결 — 경계를 어떻게 넘는가
8장 · 9장 · 10장 · 11장 · 12장

현대 시스템은 하나의 프로그램만으로 동작하지 않는다.

회원, 주문, 결제, 배송, 정산처럼
서로 다른 기능이 데이터를 주고받으며
하나의 서비스를 만든다.

시스템이 작을 때는 서로의 DB를 직접 조회하거나
내부 함수를 호출하는 방식으로도 충분할 수 있다.

하지만 규모가 커지면 문제가 생긴다.

어떤 시스템이 어떤 데이터를 소유하는지,
누가 변경할 수 있는지,
다른 시스템은 어떤 방식으로 접근해야 하는지가
점점 불분명해진다.

이 문제를 해결하는 핵심 도구가 서비스와 API이다.

이번 장에서는 API의 기본 개념에서 시작해
SOA와 ESB, REST, API Gateway까지 살펴본다.

서비스를 어떻게 나누고 조회를 어떻게 최적화할지는
9장에서 이어진다.

기술 이름을 모두 외우는 것이 목표는 아니다.

이번 장의 핵심은 다음 한 문장으로 정리할 수 있다.

각 도메인은 자신의 비즈니스 로직과 데이터를 책임하고,
다른 도메인은 명확하게 정의된 인터페이스를 통해 사용한다.

1. 데이터와 애플리케이션은 함께 움직인다

데이터 아키텍처를 공부하다 보면
DB와 데이터 모델에만 집중하기 쉽다.

하지만 실제 데이터는 DB에 가만히 있지 않다.

애플리케이션이 데이터를 생성하고,
다른 애플리케이션이 그 데이터를 조회하고,
또 다른 시스템으로 전달한다.

예를 들어 주문 시스템을 생각해보자.

flowchart LR
    n0["사용자"] --> n1["주문"] --> n2["결제"] --> n3["배송"]

주문은 결제와 연결되어야 하고,
결제가 완료되면 배송과 연결될 수 있다.

따라서 실제 시스템에서는

데이터
+
애플리케이션
+
서비스
+
API

가 함께 움직인다.

데이터 아키텍처와
애플리케이션 아키텍처를
완전히 별개의 문제로 볼 수 없는 이유이다.

분석 시스템도 마찬가지다.

운영 시스템은 작은 단위를 빠르고 정확하게 처리하고
분석 시스템은 많은 데이터를 읽어 계산한다.

요구사항은 다르지만 결국 같은 비즈니스 데이터를 쓴다.
둘을 안전하게 잇는 방법 가운데 하나가 API다.

두 영역의 경계가 어떻게 흐려지고 있는지는
12장 「무엇으로 연결할 것인가」에서 다룬다.

2. API란 무엇인가

API는

Application Programming Interface

의 약자이다.

쉽게 말하면

프로그램이 다른 프로그램의 기능이나 데이터를
사용할 수 있도록 정해 놓은 인터페이스

이다.

예를 들어 회원 정보를 조회하는 API가 있다고 하자.

GET /users/100

응답은 다음과 같을 수 있다.

{
  "id": 100,
  "name": "홍길동"
}

API를 사용하는 쪽에서는
회원 시스템 내부가 어떻게 구현되었는지 알 필요가 없다.

PHP인지
Go인지
MariaDB인지
Redis를 사용하는지

몰라도 된다.

Consumer가 알아야 할 것은

무엇을 요청하면 되는가?

어떤 형식으로 결과가 오는가?

이다.

이것이 API가 제공하는 중요한 가치이다.

3. API는 내부 구현을 숨긴다

결제 시스템 내부가 다음처럼 복잡하다고 생각해보자.

flowchart TD
    n0["결제 시스템"]
    n1["PG 연동"]
    n2["데이터베이스"]
    n3["Redis"]
    n4["쿠폰"]
    n5["포인트"]
    n6["결제 정책"]
    n0 --> n1
    n0 --> n2
    n0 --> n3
    n0 --> n4
    n0 --> n5
    n0 --> n6

다른 시스템이 이 구조를 전부 알아야 한다면
결제 시스템을 변경하기 매우 어렵다.

대신 외부에는 다음과 같은 인터페이스만 제공한다.

POST /payments

그러면 내부에서

PHP → Go

DB 구조 변경

PG사 변경

이 일어나더라도
외부 계약이 유지되는 한
Consumer의 변경을 최소화할 수 있다.

이렇게 내부 복잡성을 감추는 것을
추상화 또는 캡슐화라고 볼 수 있다.

4. 서비스 간 통신은 동기와 비동기로 나뉜다

서비스끼리 통신하는 방법은 크게
동기식과 비동기식으로 나누어 생각할 수 있다.

동기식 통신

동기식 통신은 요청한 쪽이
응답을 기다리는 방식이다.

flowchart LR
    n0["요청"] --> n1["처리"] --> n2["응답"]

예를 들어 결제 요청은
성공했는지 실패했는지 바로 알고 싶다.

flowchart LR
    n0["사용자"] --> n1["결제 요청"] --> n2["결제 시스템"] --> n3["성공 / 실패"]

이런 경우에는 동기식 요청-응답 방식이 자연스럽다.

비동기식 통신

반대로 즉시 결과를 기다릴 필요가 없는 작업도 있다.

예를 들어 주문이 완료된 이후

랭킹 반영
통계 적재
알림 발송
추천 데이터 반영

이 필요하다고 하자.

주문 서비스가 이 작업을 모두 기다릴 필요는 없다.

flowchart LR
    d["주문 완료"] --> e["이벤트 발행"] --> b["Message Broker"]
    b --> r["랭킹"]
    b --> s["통계"]
    b --> n["알림"]

이처럼 요청자가
후속 작업의 완료를 직접 기다리지 않는 방식이
비동기 통신이다.

5. Publish / Subscribe

비동기 시스템에서 자주 사용하는 방식이

Publish / Subscribe,
줄여서 Pub/Sub이다.

예를 들어 주문 서비스가

OrderCompleted

라는 이벤트를 발행한다고 하자.

flowchart LR
    s["Order Service"] --> e["OrderCompleted"] --> b["Message Broker"]
    b --> r["Ranking"]
    b --> t["Stats"]
    b --> n["Notification"]

주문 서비스는
누가 이 이벤트를 사용할지 모두 알 필요가 없다.

각 Consumer가 자신에게 필요한 이벤트를 구독하고
자기 역할을 수행한다.

이 방식은 서비스 간 직접 의존성을 줄이는 데
도움이 된다.

6. SOA: 서비스를 중심으로 시스템을 나누다

SOA는

Service-Oriented Architecture

즉, 서비스 지향 아키텍처이다.

핵심 아이디어는

시스템 기능을 서비스 단위로 제공하고,
명확한 인터페이스를 통해 서로 사용하게 하자.

이다.

예를 들어 거대한 쇼핑몰 시스템을

회원 서비스
상품 서비스
주문 서비스
결제 서비스
배송 서비스

처럼 나눌 수 있다.

서비스를 사용하는 쪽을

Service Consumer

라고 하고,

서비스를 제공하는 쪽을

Service Provider

라고 한다.

flowchart LR
    n0["웹 애플리케이션"] --> n1["회원 API"] --> n2["회원 서비스"]

이 경우 웹 애플리케이션은 Consumer이고
회원 서비스는 Provider이다.

7. 느슨한 결합

서비스 아키텍처에서 매우 중요한 목표가
느슨한 결합이다.

서비스 A가 서비스 B의 DB를 직접 조회한다고 하자.

flowchart LR
    n0["Service A"] --> n1["Service B DB"]

B의 테이블 구조가 바뀌면
A도 영향을 받을 수 있다.

반면 다음처럼 API를 사용하면

flowchart LR
    n0["Service A"] --> n1["Service B API"] --> n2["Service B"]

B의 내부 구현이 바뀌더라도
외부 API 계약을 유지하면
A의 변경을 줄일 수 있다.

이것이 느슨한 결합의 핵심이다.

8. REST와 리소스 중심 API

현대 웹 API에서 자주 사용하는 방식이 REST이다.

REST는

Representational State Transfer

라는 이름의 아키텍처 스타일이다.

REST는 단순히

GET
POST
PUT
DELETE

를 사용하는 규칙만을 의미하지 않는다.

REST에는

Client-Server
Stateless
Cacheable
Uniform Interface
Layered System

등 여러 제약이 포함된다.

다만 실무에서 RESTful HTTP API를 이해할 때는
먼저 리소스(Resource) 개념부터 보는 것이 쉽다.

리소스란 무엇인가

시스템에서 다루는 대상을 리소스로 볼 수 있다.

회원
주문
상품
결제
배송

예를 들어 URI를 다음처럼 만들 수 있다.

/users/100
/orders/500
/products/30

그리고 HTTP Method를 이용해
어떤 동작을 원하는지 표현한다.

실무에서 흔히 다음처럼 대응한다.

생성 → POST
조회 → GET
수정 → PUT / PATCH
삭제 → DELETE

예를 들어

POST /orders

는 주문 생성을,

GET /orders/100

은 주문 조회를 표현할 수 있다.

다만 이것은 REST 전체의 정의라기보다
RESTful HTTP API에서 흔히 사용하는 설계 관례이다.

9. REST와 CRUD는 완전히 같은 개념이 아니다

REST를 처음 배우면

REST = CRUD

라고 이해하기 쉽다.

하지만 실제 비즈니스는
CRUD만으로 표현하기 어려운 경우도 있다.

예를 들어 주문 취소는 단순한 DELETE가 아닐 수 있다.

flowchart TD
    n0["주문 취소"]
    n1["결제 취소"]
    n2["재고 복구"]
    n3["쿠폰 복구"]
    n4["상태 변경"]
    n0 --> n1
    n0 --> n2
    n0 --> n3
    n0 --> n4

따라서 상황에 따라

PATCH /orders/100

로 상태를 변경할 수도 있고,

취소를 별도 리소스로 모델링해서

POST /orders/100/cancellations

처럼 설계할 수도 있다.

실무에서는

POST /orders/100/cancel

같은 액션형 API도 흔히 볼 수 있다.

중요한 것은 CRUD에 억지로 맞추는 것이 아니라
API의 의미를 명확하고 일관성 있게 표현하는 것이다.

10. EAI와 ESB

기업에는 오래된 시스템과
새로운 시스템이 함께 존재하는 경우가 많다.

ERP
CRM
결제
회원
회계
레거시 시스템

이 시스템들은 서로 다른 기술과
데이터 형식을 사용할 수 있다.

이런 기업 애플리케이션들을 통합하는 분야를

EAI
Enterprise Application Integration

이라고 한다.

전통적인 EAI 환경에서 중요한 역할을 했던 것이
ESB(Enterprise Service Bus) 이다.

ESB의 역할

서비스들이 서로 직접 연결되면 관계가 빠르게 복잡해진다.

flowchart LR
    A["A"] <--> B["B"]
    A <--> C["C"]
    A <--> D["D"]
    B <--> C
    B <--> D
    C <--> D

넷일 때 연결이 여섯 개다.
시스템이 늘어날수록 연결은 그보다 빠르게 는다.

그래서 중앙의 통합 계층을 둔다.

flowchart LR
    a["A"] <--> esb["ESB"]
    b["B"] <--> esb
    c["C"] <--> esb
    d["D"] <--> esb

    style esb fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a

이제 각 시스템은 ESB 하나만 알면 된다.

ESB는 다음과 같은 역할을 수행할 수 있다.

메시지 라우팅
데이터 형식 변환
프로토콜 변환
서비스 연결
오케스트레이션

11. SOAP, WSDL, XSD

전통적인 SOA 환경에서는
SOAP과 XML 기반 기술이 많이 사용되었다.

SOAP은 XML을 이용한 메시징 프로토콜이다.

<Envelope>
  <Body>
    <GetUser>
      <UserId>100</UserId>
    </GetUser>
  </Body>
</Envelope>

WSDL은

Web Services Description Language

로,

웹 서비스가 제공하는 기능과 인터페이스를
기계가 읽을 수 있는 형태로 정의한다.

SOAP 기반 웹 서비스에서 특히 널리 사용되었다.

XSD는

XML Schema Definition

으로,

XML 문서의 데이터 구조와 타입을 정의한다.

User에는 Id가 있어야 한다.

Id는 숫자다.

Name은 문자열이다.

같은 규칙을 표현할 수 있다.

12. REST/JSON이 널리 사용된 이유

SOAP은 강력한 표준이지만
웹과 모바일 환경에서는 다소 복잡하게 느껴질 수 있다.

반면

HTTP
+
REST 스타일
+
JSON

조합은 웹 기술과 자연스럽게 연결되고
비교적 단순하게 사용할 수 있다.

그래서 일반적인 웹 API에서는
REST/JSON 방식이 매우 널리 사용되고 있다.

그렇다고 SOAP이 사라진 것은 아니다.

기업 내부 통합이나 레거시 환경에서는
여전히 SOAP 기반 시스템이 존재한다.

즉,

SOAP → 과거 기술이라서 폐기

REST → 무조건 최신 정답

이라고 이해하면 안 된다.

각 기술은 사용 환경과 목적이 다르다.

13. 서비스 애그리게이션과 오케스트레이션

여러 서비스를 결합하는 방법도 다양하다.

Service Aggregation

여러 서비스의 결과를 모아
하나의 응답으로 만드는 방식이다.

flowchart TD
    hub["하나의 응답"]
    s0["회원"] --> hub
    s1["주문"] --> hub
    s2["쿠폰"] --> hub
    s3["포인트"] --> hub

예를 들어 마이페이지 화면을 만드는 데 사용할 수 있다.

Service Orchestration

여러 서비스의 실행 순서와 조건을
중앙에서 제어한다.

flowchart TD
    o["Orchestrator"] --> a["결제"]
    o --> b["재고"]
    o --> c["배송"]

예를 들어

1. 결제한다.
2. 성공하면 재고를 차감한다.
3. 배송을 등록한다.

같은 흐름을 중앙의 Orchestrator가 알고 있다.

오케스트라의 지휘자와 비슷하다.

14. 서비스 코레오그래피

오케스트레이션과 대비되는 방식이

Service Choreography

이다.

여기에는 중앙 지휘자가 없다.

flowchart TD
    n0["OrderCreated"] --> n1["Payment Service"] --> n2["PaymentCompleted"] --> n3["Inventory Service"] --> n4["InventoryReserved"] --> n5["Delivery Service"]

각 서비스가 이벤트를 보고
자신이 해야 할 행동을 수행한다.

쉽게 비교하면

• 오케스트레이션 — 중앙 지휘자가 전체 흐름을 안다.
• 코레오그래피 — 각 서비스가 이벤트에 반응하며 움직인다.

이다.

둘 중 하나가 항상 좋은 것은 아니다.

실무에서는 두 방식을 섞어 사용하는 경우도 많다.

예를 들어 핵심 거래 흐름은 오케스트레이션으로 관리하고,

flowchart LR
    n0["결제"] --> n1["재고"] --> n2["주문 완료"]

주문 완료 이후의 부가 기능은 이벤트로 처리할 수 있다.

flowchart TD
    n0["OrderCompleted"]
    n1["알림"]
    n2["통계"]
    n3["추천"]
    n4["로그"]
    n0 --> n1
    n0 --> n2
    n0 --> n3
    n0 --> n4

15. 중앙 ESB가 너무 커질 때의 문제

ESB 자체가 나쁜 기술은 아니다.

문제는 모든 책임을 ESB에 넣기 시작할 때다.

라우팅
변환
업무 규칙
상태 관리
오케스트레이션
프로세스 관리

가 모두 중앙으로 모이면 이렇게 된다.

flowchart LR
    A["A"] <--> ESB
    B["B"] <--> ESB
    C["C"] <--> ESB
    D["D"] <--> ESB

    ESB["ESB<br/>──────────<br/>라우팅 · 변환<br/>업무 규칙 · 상태 관리<br/>오케스트레이션 · 프로세스"]

    style ESB fill:#fff4f4,stroke:#d9534f,stroke-width:3px,color:#1a1a1a

연결은 단순해졌는데
중앙 통합 계층이 가장 복잡한 시스템이 됐다.

또한 특정 기능의 소유자가 불명확해지고
변경 영향 범위가 커질 수 있다.

ESB를 고가용성으로 구성하면
물리적인 단일 장애점을 줄일 수 있다.

따라서 정확한 문제는

ESB 자체가 반드시 단일 장애점이라는 것이 아니라,
지나치게 많은 논리적 책임과 의존성을 중앙에 모으면
장애와 변경의 영향 범위가 커질 수 있다는 것이다.

라고 이해하는 것이 좋다.

16. 공통 데이터 모델의 장점과 한계

과거 SOA에서는 여러 시스템이
공통 데이터 모델을 사용하는 방식도 널리 사용했다.

이를

Canonical Data Model

이라고 한다.

예를 들어 서로 다른 시스템이 회원을

user_id
memberNo
customerId

처럼 다르게 표현한다면
통합 과정이 복잡해진다.

그래서 공통 모델을 만들 수 있다.

memberId
memberName

이 방식은 제한된 통합 영역에서는
여전히 유용할 수 있다.

문제는 회사 전체의 모든 의미를
하나의 초대형 모델에 넣으려고 할 때다.

각 팀의 요구사항이 계속 추가되면서

flowchart LR
    n0["모두를 위해 만든 모델"] --> n1["너무 거대하고 복잡한 모델"]

이 될 수 있다.

따라서 표준 모델 자체가 나쁜 것이 아니라
범위를 지나치게 넓히는 것이 문제이다.

17. 중앙집중에서 도메인 책임으로

현대적인 아키텍처에서는

중앙 시스템이 모든 것을 소유

하는 방식보다

각 도메인이 자기 영역을 책임

지는 방식을 중요하게 본다.

예를 들어

flowchart LR
    subgraph c["Commerce Domain"]
        c1["Business Logic"]
        c2["Data"]
        c3["API"]
    end
    subgraph m["Member Domain"]
        m1["Business Logic"]
        m2["Data"]
        m3["API"]
    end
    subgraph d["Delivery Domain"]
        d1["Business Logic"]
        d2["Data"]
        d3["API"]
    end

처럼 구성할 수 있다.

이 구조에서는 각 도메인의 소유권이 명확하다.

18. API Gateway

현대적인 API 환경에서 자주 등장하는 것이
API Gateway이다.

flowchart LR
    c["Client"] --> g["API Gateway"]
    g --> m["Member"]
    g --> o["Commerce"]
    g --> d["Delivery"]

API Gateway는 보통 다음과 같은 공통 기능을 담당한다.

라우팅
인증
인가
Rate Limit
TLS
로깅
모니터링

또한 상황에 따라
간단한 응답 변환이나 Aggregation을 수행할 수도 있다.

하지만 핵심 비즈니스 규칙을
Gateway에 집중시키는 것은 피하는 것이 좋다.

예를 들어

포인트 차감 우선순위
환불 가능 여부
결제 승인 정책

은 Gateway가 아니라
해당 도메인이 판단해야 한다.

따라서 쉽게 말하면

• API Gateway — 요청을 통제하고 전달
• Domain — 비즈니스 판단

이라고 이해하면 된다.

19. API를 제품으로 관리한다

API는 단순한 HTTP Endpoint가 아니다.

API에도 사용자가 있다.

웹
모바일
다른 개발팀
외부 파트너

따라서 API도 하나의 제품처럼 관리할 수 있다.

이를 흔히

API as a Product

관점이라고 부른다.

API 제품에는 다음과 같은 요소가 필요하다.

Owner
문서
버전
보안
모니터링
호환성 정책
Lifecycle
SLA 또는 SLO

즉,

API 개발 완료
→ 끝

이 아니다.

API도 지속적으로 운영하고 관리해야 한다.

20. API Contract

Provider와 Consumer 사이에는
명확한 약속이 필요하다.

이를 API Contract라고 한다.

예를 들어

GET /users/{id}

라는 API의 계약에는

URL
HTTP Method
Request
Response
Status Code
Error
인증 방법
버전

등이 포함될 수 있다.

Provider가 마음대로 응답 구조를 바꾸면
기존 Consumer가 깨질 수 있다.

따라서 API 계약은
도메인 간 결합을 안정적으로 관리하는 핵심 요소이다.

21. OpenAPI

HTTP API의 인터페이스를 문서화하는
대표적인 표준 중 하나가

OpenAPI Specification이다.

OpenAPI에서는

Endpoint
Method
Parameter
Request Schema
Response Schema
Authentication

등을 정의할 수 있다.

이를 기반으로

API 문서
Mock Server
Client SDK
Validation
테스트

등을 자동화할 수 있다.

다만

OpenAPI = API 계약의 모든 것

이라고 보면 안 된다.

실제 계약에는

SLA
Rate Limit 정책
호환성 정책
비즈니스 전제조건

처럼 OpenAPI 문서만으로 충분히 표현하기 어려운 내용도 있다.

따라서 OpenAPI는

API Contract를 표현하고 관리하는 대표적인 수단 중 하나

라고 이해하면 된다.

22. Composite Service

여러 API의 결과를 조합해
하나의 API로 제공할 수도 있다.

예를 들어 마이페이지에서

회원 정보
보유 포인트
최근 결제
배송 정보

가 필요하다고 하자.

flowchart TD
    n0["Client"]
    n1["MyPage Composite API"]
    n2["Member API"]
    n3["Point API"]
    n4["Payment API"]
    n5["Delivery API"]
    n1 --> n2
    n1 --> n3
    n1 --> n4
    n1 --> n5
    n0 --> n1

Client는 여러 API를 각각 호출할 필요가 없다.

하지만 Composite API가
각 도메인의 핵심 비즈니스 규칙까지 소유하기 시작하면
새로운 중앙집중 시스템이 될 수 있다.

따라서 Composite는 주로

호출
결과 결합
표현 변환

에 집중하고,

비즈니스 판단은
각 도메인이 담당하는 것이 좋다.

23. API 탐색 가능성과 메타데이터

API가 몇 개 없을 때는
개발자가 기억할 수 있다.

하지만 API가 수백 개로 늘어나면 어렵다.

회원 조회 API가 어디 있지?

누가 관리하지?

최신 버전은 뭐지?

이 API 아직 사용 중인가?

이 문제를 해결하기 위해

Service Registry
API Catalog
Developer Portal

등을 사용할 수 있다.

API 자체뿐 아니라
API에 대한 정보도 관리해야 한다.

이를 API Metadata라고 볼 수 있다.

API 이름
설명
Owner
도메인
버전
Endpoint
인증 방법
Deprecated 여부
의존 관계

등이 메타데이터에 포함될 수 있다.

24. 8장 정리

네 가지만 기억하면 된다.

API는 내부 구현을 숨기고 계약만 노출한다.
언어를 바꾸든 DB 구조를 바꾸든
외부 계약이 유지되면 소비자는 영향을 받지 않는다.

REST는 CRUD가 아니다.
주문 취소처럼 CRUD로 표현하기 어려운 업무가 많다.
중요한 것은 규칙에 억지로 맞추는 것이 아니라
API의 의미를 명확하고 일관되게 표현하는 것이다.

중앙 통합 계층에 책임을 몰면 그것이 가장 복잡한 시스템이 된다.
ESB 자체가 문제가 아니라
라우팅·변환·업무 규칙·상태 관리를 모두 중앙에 모으는 것이 문제다.

API도 제품이다.
Owner, 문서, 버전, 보안, 호환성 정책, 수명주기가 필요하다.

다음 장에서는 서비스를 어떻게 나누고
조회를 어떻게 최적화할지 본다.

9장. 서비스 경계와 조회 모델

3부 · 연결 — 경계를 어떻게 넘는가
8장 · 9장 · 10장 · 11장 · 12장

서비스를 잘게 나눴다.

그랬더니 화면 하나를 그리는 데
API를 일곱 번 호출하게 됐다.

응답은 느려지고,
그중 하나만 실패해도 화면 전체가 비어 버린다.

8장에서 API 계약을 봤다.

이 장에서는 서비스를 어떻게 나눌지,
그리고 조회를 어떻게 최적화할지 본다.

마이크로서비스, Service Mesh, BFF, GraphQL, CQRS가 나오지만
기술 이름보다 중요한 것은 하나다.

작게 나누는 것이 목표가 아니라
적절한 경계를 찾는 것이 목표다.

1. 마이크로서비스

마이크로서비스는

애플리케이션을 비교적 작은 서비스 단위로 나누고
각 서비스의 자율성과 독립적인 운영을 높이는
아키텍처 접근 방식

이다.

SOA와

서비스 단위 구성
느슨한 결합
인터페이스 통신

이라는 철학을 공유하지만,

마이크로서비스를
단순히 SOA의 새로운 버전이라고 볼 수는 없다.

마이크로서비스는 특히

독립적인 배포
작은 책임 범위
팀 자율성
자동화된 운영
분산된 데이터 소유권

등을 강하게 강조한다.

2. 마이크로서비스의 핵심은 작기가 아니라 경계다

마이크로서비스라는 이름 때문에

작을수록 좋다

라고 생각하기 쉽다.

하지만 중요한 것은 코드 크기가 아니다.

이 서비스가 어떤 비즈니스 책임을 가지는가?

가 더 중요하다.

서비스를 너무 잘게 나누면

flowchart LR
    n0["A"] --> n1["B"] --> n2["C"] --> n3["D"]

모든 작업이 네트워크 호출이 되어

지연
장애 가능성
배포 복잡성
운영 복잡성

이 증가할 수 있다.

따라서

가능한 한 작게 나누는 것이 아니라
적절한 도메인 경계를 찾는 것이 중요하다.

라고 이해해야 한다.

3. 데이터 소유권과 물리 DB는 다르다

마이크로서비스에서 흔히

각 서비스는 자신의 데이터를 가진다.

라고 말한다.

하지만 이것이 반드시

서비스 하나
=
물리 DB 서버 하나

를 의미하지는 않는다.

같은 DB 인스턴스를 사용하면서도

테이블 소유권 분리
스키마 분리
다른 서비스의 직접 접근 금지

같은 규칙을 적용할 수 있다.

중요한 것은

누가 데이터를 변경하고 책임지는지가 명확한가?

이다.

4. Service Mesh

마이크로서비스가 많아지면
서비스 간 네트워크 통신이 복잡해진다.

각 서비스가 모두 직접

TLS
인증
재시도
로드밸런싱
트래픽 제어
모니터링

을 구현하면 부담이 커진다.

이러한 통신 기능을
인프라 계층에서 처리하는 접근이

Service Mesh이다.

쉽게 비교하면

flowchart LR
    Client["외부 사용자"] <-->|"North-South<br/>외부 ↔ 내부"| Gateway["API Gateway"]

    Gateway --> A

    subgraph Mesh["Service Mesh"]
        A["Service A"] <-->|"East-West<br/>내부 서비스 간"| B["Service B"]
        B <-->|"East-West"| C["Service C"]
    end

    style Gateway fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a

라고 생각할 수 있다.

다만 이것은 대표적인 역할 구분이지
절대적인 경계는 아니다.

API Gateway를 내부 API에 사용할 수도 있고,
Service Mesh에도 ingress/egress 기능이 있을 수 있다.

5. Control Plane과 Data Plane

서비스 메시를 이해할 때
자주 등장하는 개념이다.

Control Plane은

라우팅 정책
보안 정책
트래픽 정책

등을 정의한다.

Data Plane은
실제 요청과 트래픽을 처리한다.

쉽게 표현하면

• Control Plane — 교통 정책을 정한다.
• Data Plane — 실제 차량이 다니는 도로다.

라고 이해할 수 있다.

6. 내부 API와 외부 API는 다르다

회사 내부 시스템끼리 사용하는 API와
외부 파트너에게 제공하는 API는
요구사항이 다르다.

내부 API는 상대적으로 빠르게 변경할 수 있지만,

외부 API는

강한 인증
Rate Limit
DDoS 대응
감사 로그
문서화
안정적인 버전 정책

등이 더 중요하다.

따라서 내부 API를
외부에 그대로 공개하는 것은 주의해야 한다.

내부 구현이 외부 계약으로 굳어지면
나중에 내부 구조를 변경하기 어려워질 수 있다.

7. Experience API와 BFF

사용자 화면에 맞게 API를 구성할 수도 있다.

예를 들어 모바일 홈 화면에서

회원 정보
보유 포인트
상품 목록
추천
알림

이 필요하다고 하자.

모바일 앱이 모든 API를 직접 호출하는 대신

flowchart LR
    n0["Mobile"] --> n1["Mobile API"] --> n2["여러 Domain API"]

형태로 구성할 수 있다.

이러한 소비자 경험 중심의 계층을
Experience API라고 부르기도 한다.

비슷한 목적의 대표적인 패턴이

BFF(Backend for Frontend) 이다.

Web BFF
Mobile BFF
Admin BFF

처럼 프론트엔드별로
전용 Backend를 둘 수 있다.

Experience API와 BFF는 비슷한 문제를 해결하지만
완전히 같은 개념이라고 볼 필요는 없다.

BFF는 특히
특정 프론트엔드 전용 Backend라는 의미가 강하다.

8. GraphQL

GraphQL은 Client가
필요한 필드를 직접 지정해 요청할 수 있는
API Query Language이자 실행 방식이다.

예를 들어

query {
  user(id: 100) {
    name
    profileImage
  }
}

처럼 원하는 데이터만 요청할 수 있다.

REST API에서 하나의 응답이 너무 많은 데이터를 내려주는
Over-fetching 문제나,

하나의 화면을 위해 여러 API를 호출해야 하는
Under-fetching 문제를 줄이는 데 도움이 될 수 있다.

하지만 GraphQL을 사용한다고 해서
자동으로 성능이 좋아지는 것은 아니다.

복잡한 Nested Query
N+1 Query
쿼리 비용 관리
권한 제어

같은 문제를 따로 고려해야 한다.

9. GraphQL은 REST 위에서만 동작하는 것이 아니다

GraphQL을 다음처럼 사용할 수 있다.

flowchart LR
    n0["Client"] --> n1["GraphQL"] --> n2["REST API"]

하지만 이것은 하나의 구현 방법일 뿐이다.

GraphQL Resolver는

DB
REST API
gRPC
다른 GraphQL 서비스
Cache
외부 API

등 다양한 데이터 소스를 사용할 수 있다.

또한 GraphQL 역시
도메인 소유권을 무너뜨리면 안 된다.

하나의 거대한 GraphQL 서버가
회사 전체 데이터를 직접 소유하기 시작하면

스키마 비대화
소유권 불명확
변경 영향 증가

가 생길 수 있다.

10. API 메타데이터와 의존 관계

서비스와 API가 많아지면
누가 누구를 사용하는지 추적해야 한다.

예를 들어

flowchart LR
    n0["Mobile BFF"] --> n1["Member API"] --> n2["Identity API"]

라는 구조가 있다고 하자.

Identity API에 장애가 발생하면

flowchart LR
    n0["Identity"] --> n1["Member"] --> n2["Mobile"]

까지 영향을 받을 수 있다.

API 메타데이터와 Dependency 정보를 잘 관리하면
이런 영향 범위를 파악하기 쉬워진다.

또한

v1 API를 아직 누가 사용하고 있는가?

이 서비스를 삭제해도 되는가?

어떤 API가 Deprecated 상태인가?

같은 Lifecycle 관리에도 도움이 된다.

11. 읽기 지향 API

모든 API가 데이터를 변경할 필요는 없다.

데이터 제품이나 분석 서비스라면
읽기만 제공하는 API가 유용할 수 있다.

GET /reports/sales
GET /rankings
GET /products/active

이러한 API는
Consumer가 데이터베이스를 직접 조회하지 않아도
필요한 데이터를 사용할 수 있게 해준다.

12. CQRS

읽기와 쓰기의 요구사항이 크게 다르다면
두 책임을 분리할 수 있다.

이를

CQRS
Command Query Responsibility Segregation

이라고 한다.

핵심은 매우 단순하다.

• Command — 상태를 변경
• Query — 상태를 읽음

그리고

Command Model
≠
Query Model

로 설계할 수 있다.

13. CQRS가 반드시 DB 두 개를 의미하는 것은 아니다

CQRS를 설명할 때 흔히 다음 구조를 본다.

flowchart LR
    n0["Command"] --> n1["Write Model"] --> n2["Write DB"]

flowchart LR
    n0["Query"] --> n1["Read Model"] --> n2["Read DB"]

하지만 이것은 CQRS의 한 구현 방법이다.

CQRS의 핵심은

읽기 책임
≠
쓰기 책임

을 분리하는 것이지,

반드시 물리적으로 DB를 두 개 만들어야 한다는 것은 아니다.

같은 DB를 사용하면서
Command Model과 Query Model만 분리할 수도 있다.

14. CQRS와 결과적 일관성

Write Store와 Read Store를 별도로 만들고
비동기 이벤트로 동기화한다면

flowchart LR
    n0["Write"] --> n1["Event"] --> n2["Read Model"]

짧은 시간 동안 데이터 차이가 발생할 수 있다.

예를 들어

포인트 차감

Write Store
900

Read Store
아직 1000

인 순간이 생길 수 있다.

시간이 지나면서 Read Store도 900으로 반영된다면
이를 결과적 일관성(Eventual Consistency) 이라고 한다.

하지만 중요한 점은

CQRS 자체가 결과적 일관성을 의미하지는 않는다.

는 것이다.

같은 저장소를 사용하거나
동기식 처리를 한다면 이런 문제가 없을 수도 있다.

15. CQRS와 Event Sourcing도 별개다

초보자가 자주 혼동하는 개념이다.

CQRS
≠
Event Sourcing

둘을 함께 사용하는 시스템이 많을 뿐
서로 다른 패턴이다.

CQRS는

Command와 Query의 책임 분리

가 핵심이고,

Event Sourcing은

현재 상태 자체가 아니라  
상태를 만든 이벤트의 기록을 저장

하는 방식이다.

16. CQRS는 성능 최적화만을 위한 것이 아니다

CQRS를

조회가 느림
→ CQRS 적용

정도로만 이해하면 부족하다.

CQRS의 근본적인 목적은

읽기와 쓰기가 서로 다른 모델과 책임을 가질 수 있다는 점을
아키텍처에 명확하게 표현하는 것

이다.

물론 이를 이용하면

• Write — 정합성 중심
• Read — 검색/조회 성능 중심

으로 각각 최적화할 수 있다.

예를 들어

• Write — MariaDB
• Read — Redis / Elasticsearch / Read Replica

같은 구조도 가능하다.

하지만 시스템이 단순하다면
굳이 CQRS를 적용할 필요는 없다.

17. 데이터 제품과 API

6장에서 소개한 데이터 제품과
이번 장의 API는 밀접하게 연결된다.

예를 들어 주문 도메인이
주문 데이터를 다른 도메인에 제공한다고 하자.

flowchart LR
    n0["Order Domain"] --> n1["Order Data Product"] --> n2["Read API"] --> n3["다른 Domain"]

이렇게 하면 다른 도메인이

Order DB 직접 조회

를 하지 않아도 된다.

즉, 데이터 제품을 제공하는 인터페이스로
API를 사용할 수 있다.

물론 도메인 간 데이터 공유가
항상 동기 API여야 하는 것은 아니다.

다음과 같은 방법도 가능하다.

API
이벤트
메시지
공식 데이터 제품

중요한 것은

다른 도메인이 상대 도메인의 내부 DB나 구현에
직접 결합하지 않는 것

이다.

18. 도메인 내부와 외부를 구분한다

도메인 내부에서는
상대적으로 구현 변경이 자유롭다.

Commerce Domain

Order
Payment
Refund

하지만 도메인 밖으로 나가는 인터페이스는
더 안정적이어야 한다.

flowchart LR
    n0["Commerce"] --> n1["API Contract"] --> n2["Settlement"]

따라서

• 도메인 내부 — 구현 자유도
• 도메인 외부 — 계약 안정성

을 구분하는 것이 중요하다.

19. API 이름에도 비즈니스 언어를 사용한다

비즈니스에서는 “주문“이라고 부르는데

코드와 API에서는

PointGrantTransferTransaction

같은 전혀 다른 용어를 사용한다면
의사소통이 어려워진다.

가능하면

비즈니스 언어
=
도메인 언어
=
API 언어

를 맞추는 것이 좋다.

예를 들어

POST /orders
GET /orders/{id}

처럼 의미가 쉽게 드러나게 만들 수 있다.

이것은 DDD에서 말하는
보편 언어(Ubiquitous Language) 와도 연결된다.

20. 도메인 자율성과 공통 거버넌스

각 도메인이 API를 책임한다고 해서

각 팀이 마음대로 API를 만든다.

는 뜻은 아니다.

조직 전체적으로 필요한 최소한의 기준은
공통으로 정할 수 있다.

예를 들어

API Naming
HTTP Method 사용 원칙
에러 응답 형식
인증 방식
버전 정책
OpenAPI 작성 규칙
로깅
보안 기준

같은 것이다.

즉,

도메인의 자율성
+
조직 공통 거버넌스

를 함께 가져가는 것이다.

이 철학은 앞에서 배운
데이터 메시의 연합형 거버넌스와도 닮아 있다.

21. 기술보다 문제를 먼저 본다

이번 장에는 많은 기술이 등장했다.

SOA
REST
ESB
API Gateway
Microservices
Service Mesh
GraphQL
BFF
CQRS

하지만 이 기술들은 서로 대체 관계가 아니다.

각각 해결하려는 문제가 다르다.

• REST / GraphQL — API 인터페이스와 데이터 접근 방식
• API Gateway — API 진입점과 공통 정책
• Service Mesh — 서비스 간 네트워크 통신
• Microservices — 서비스와 조직의 경계
• BFF — 특정 프론트엔드에 맞는 Backend
• CQRS — Command와 Query의 책임 분리

따라서 모든 시스템에
이 기술들을 전부 적용할 필요는 없다.

작은 시스템이라면

모놀리스
+
REST API
+
MariaDB

만으로 충분할 수 있다.

규모와 문제에 따라

API Gateway
Message Broker
BFF
Service Mesh
CQRS

등을 추가하면 된다.

좋은 아키텍처는
기술을 많이 사용하는 아키텍처가 아니라

현재 문제를 가장 단순한 방법으로 해결하면서
앞으로의 변경도 감당할 수 있는 구조

이다.

22. 9장 정리

네 가지만 기억하면 된다.

작게 나누는 것이 목표가 아니다.
마이크로서비스의 기준은 크기가 아니라 경계다.
잘못 그은 경계는 Service Mesh가 고쳐 주지 않는다.

물리 DB와 데이터 소유권은 다른 문제다.
DB를 나눠야만 소유권이 생기는 것이 아니고,
DB를 합쳤다고 소유권이 사라지는 것도 아니다.

CQRS는 DB 두 개를 뜻하지 않는다.
읽기와 쓰기의 책임을 나누는 것이고,
같은 DB 안에서도 할 수 있다.
Event Sourcing과도 별개다.

조회를 최적화하되 경계를 흐리지 않는다.
BFF와 GraphQL은 화면이 편해지는 만큼
누가 무엇을 책임지는지 흐려지기 쉽다.

기술 이름보다 먼저 답해야 할 질문은 이것들이다.

누가 이 기능을 책임지는가?

누가 이 데이터를 소유하는가?

어떤 경계를 외부에 공개할 것인가?

다른 도메인은 어떤 계약으로 사용할 것인가?

좋은 구조에서는 각 도메인의 책임이 이렇게 보인다.

flowchart LR
    subgraph da["Domain A"]
        a1["Business Logic"]
        a2["Data"]
        a3["API / Event"]
    end
    subgraph db["Domain B"]
        b1["Business Logic"]
        b2["Data"]
        b3["API / Event"]
    end

    da -- "명확한 계약" --> db

다른 도메인의 DB와 내부 구조를 직접 쓰는 대신
공식적으로 제공되는 API, Event, Message, Data Product를 쓴다.

도메인이 자신의 기능과 데이터를 책임지고,
다른 도메인은 명확하게 정의된 인터페이스로 사용한다.

8장과 9장이 함께 답한 것이 이 한 문장이다.

다음 장에서는 요청과 응답이 아니라
이미 일어난 일을 알리는 방식, 즉 이벤트를 본다.

10장. 이벤트로 연결하기

3부 · 연결 — 경계를 어떻게 넘는가
8장 · 9장 · 10장 · 11장 · 12장

이벤트의 생성부터 전달·처리·저장·운영까지

이벤트 기반 아키텍처를 처음 접하면
보통 Kafka나 메시지 큐부터 떠올리기 쉽다.

하지만 이벤트 기반 아키텍처는
특정 제품이나 기술을 의미하지 않는다.

핵심은 다음과 같다.

시스템에서 발생한 일을
이벤트라는 데이터로 표현하고,
필요한 시스템이 그 이벤트에 반응하도록
시스템을 연결하는 설계 방식이다.

예를 들어 결제가 완료됐다고 해보자.

기존에는 결제 서비스가 직접

flowchart LR
    n0["결제 서비스"]
    n1["포인트 서비스 호출"]
    n2["알림 서비스 호출"]
    n3["통계 서비스 호출"]
    n0 --> n1
    n0 --> n2
    n0 --> n3

할 수 있다.

이벤트 기반으로 바꾸면

flowchart TD
    n0["결제 서비스"]
    n1["PaymentCompleted"]
    n2["이벤트 시스템"]
    n3["포인트 서비스"]
    n4["알림 서비스"]
    n5["통계 서비스"]
    n0 --> n1
    n2 --> n3
    n2 --> n4
    n2 --> n5
    n1 --> n2

처럼 만들 수 있다.

결제 서비스는

“결제가 완료됐다.”

라는 사실만 알린다.

누가 그 정보를 사용하는지는
알 필요가 없다.

이것이 이벤트 기반 아키텍처를 이해하는
가장 중요한 출발점이다.

1. 이벤트란 무엇인가

이벤트(Event)는

이미 발생한 사실

을 의미한다.

예를 들어 다음은 모두 이벤트가 될 수 있다.

회원이 가입했다.
결제가 완료됐다.
상품이 주문됐다.
주문이 완료됐다.
배송이 시작됐다.
고객 정보가 변경됐다.

프로그램에서는 보통 다음처럼 표현할 수 있다.

UserRegistered
PaymentCompleted
OrderCreated
OrderCompleted
DeliveryStarted
CustomerUpdated

이벤트 이름을 과거형으로 표현하는 경우가 많은 것도
이미 발생한 사실을 나타내기 때문이다.

2. Event, Command, Query를 구분하자

메시지라고 해서 전부 이벤트는 아니다.

처음부터 세 개의 차이를 알아두는 것이 좋다.

Event

이미 일어난 사실이다.

PaymentCompleted
OrderCompleted
UserRegistered

의미는

"결제가 완료됐다."
"주문이 완료됐다."
"회원이 가입했다."

이다.

Command

무엇인가를 수행하라는 요청이다.

CreatePayment
CancelOrder
DeductPoint

의미는

"결제해라."
"주문을 취소해라."
"포인트를 차감해라."

이다.

Query

정보를 달라는 요청이다.

GetPayment
GetOrderHistory
GetPointBalance

Query는 일반적으로 시스템 상태를 변경하지 않는다.

정리하면 다음과 같다.

Event
= 이미 발생한 사실

Command
= 무엇인가를 수행하라는 요청

Query
= 정보를 요청

이 세 가지를 명확하게 구분하면
이벤트 기반 시스템의 설계가 훨씬 이해하기 쉬워진다.

3. 요청/응답 구조와 이벤트 기반 구조

전통적인 서비스 통신은
다른 서비스를 직접 호출하는 경우가 많다.

예를 들어:

flowchart LR
    n0["주문 서비스"] --> n1["랭킹 서비스 API 호출"] --> n2["알림 서비스 API 호출"] --> n3["통계 서비스 API 호출"]

이 구조의 장점은 흐름이 명확하다는 것이다.

하지만 주문 서비스가

랭킹 서비스
알림 서비스
통계 서비스

를 모두 알고 있어야 한다.

시스템이 커질수록 서비스 사이의 연결도 증가한다.

이벤트 기반에서는 다르게 접근한다.

flowchart TD
    n0["주문 서비스"]
    n1["OrderCompleted"]
    n2["Event Broker"]
    n3["랭킹 서비스"]
    n4["알림 서비스"]
    n5["통계 서비스"]
    n0 --> n1
    n2 --> n3
    n2 --> n4
    n2 --> n5
    n1 --> n2

주문 서비스는

주문이 완료됐다.

는 사실만 알린다.

랭킹, 알림, 통계 서비스는
각자 필요한 일을 수행한다.

이렇게 서로 직접 알지 않아도 되는 관계를

느슨한 결합(Loose Coupling)

이라고 한다.

4. 동기 통신과 비동기 통신

이벤트 기반 시스템을 이해하려면
동기와 비동기의 차이를 알아야 한다.

동기 통신

서비스 A가 B에게 요청을 보내고
응답이 올 때까지 기다린다.

서비스 A
   ↓ 요청
서비스 B
   ↓ 처리
서비스 A
   ↑ 응답

대표적으로 HTTP API가 있다.

장점은 단순하다는 것이다.

하지만 B가 느리면
A도 기다려야 한다.

B에 장애가 발생하면
A까지 영향을 받을 수도 있다.

비동기 통신

요청 또는 이벤트를 전달한 뒤
바로 다음 작업을 진행할 수 있다.

flowchart TD
    n0["서비스 A"]
    n1["이벤트 발행"]
    n2["메시지 시스템"]
    n3["서비스 B"]
    n4["서비스 C"]
    n5["서비스 D"]
    n0 --> n1
    n1 --> n2
    n2 --> n3
    n2 --> n4
    n2 --> n5

A는 B, C, D의 처리 완료를
즉시 기다리지 않아도 된다.

이벤트 기반 아키텍처에서는
이런 비동기 통신을 많이 활용한다.

5. 이벤트 알림 방식

이벤트를 만들 때 중요한 설계 문제가 있다.

이벤트에 변경 사실만 넣을 것인가,
필요한 상태까지 함께 넣을 것인가?

대표적으로 두 가지 접근이 있다.

먼저 변경 사실만 알리는 쪽부터 보자.

가장 작은 정보만 전달한다.

예를 들어:

{
  "customerId": 100
}

의 의미는

"고객 100의 정보가 변경됐다."

정도이다.

Consumer가 자세한 정보가 필요하다면
고객 서비스에 다시 요청한다.

flowchart LR
    n0["CustomerUpdated"] --> n1["Consumer"] --> n2["Customer API"] --> n3["최신 고객 정보 조회"]

장점

이벤트 크기가 작다.

불필요한 개인정보 전파도 줄일 수 있다.

단점

추가 API 호출이 필요하다.

원본 서비스가 장애 상태라면
정보를 가져오지 못할 수 있다.

6. 상태를 함께 전달하는 방식

이벤트 안에 Consumer가 필요한 데이터까지
같이 전달할 수도 있다.

이를 흔히

Event-Carried State Transfer

라고 한다.

예를 들어:

{
  "customerId": 100,
  "name": "Kim",
  "city": "Busan"
}

처럼 보낼 수 있다.

Consumer는 별도 API 호출 없이
이벤트만으로 필요한 데이터를 사용할 수 있다.

flowchart LR
    n0["CustomerUpdated"] --> n1["Consumer"] --> n2["자체 데이터 저장"]

7. 상태 전송의 장단점

장점은 Consumer의 독립성이 높아진다는 것이다.

하지만 데이터가 여러 시스템으로 복제되므로

데이터 중복
개인정보 관리
삭제 처리
스키마 변경
정합성 관리

같은 문제가 발생한다.

따라서 다음 트레이드오프가 있다.

이벤트에 데이터를 많이 포함

→ API 의존성 감소
→ 데이터 관리 복잡성 증가

정답은 하나가 아니다.

업무 특성에 따라 결정해야 한다.

8. Producer와 Consumer

이벤트를 만드는 쪽을

Producer

라고 한다.

flowchart LR
    n0["주문 서비스"] --> n1["OrderCompleted"]

이벤트를 받아 사용하는 쪽을

Consumer

라고 한다.

flowchart LR
    n0["OrderCompleted"]
    n1["랭킹"]
    n2["정산"]
    n3["알림"]
    n4["통계"]
    n0 --> n1
    n0 --> n2
    n0 --> n3
    n0 --> n4

Producer는 일반적으로
Consumer가 몇 개인지 몰라도 된다.

이것이 이벤트 기반 구조가
서비스 간 결합도를 줄이는 중요한 이유이다.

9. 메시지 큐

이벤트나 작업 메시지를 전달하는
대표적인 방식이 메시지 큐이다.

메시지를 잠시 줄 세워 놓는
대기열이라고 생각하면 된다.

flowchart LR
    n0["Producer"] --> n1["Queue"] --> n2["Consumer"]

Producer가 순간적으로 많은 작업을 만들어도
Consumer가 처리할 때까지 큐에 보관할 수 있다.

10. 메시지 큐가 유용한 경우

메시지 큐는 다음 상황에서 유용하다.

작업이 순간적으로 몰릴 때
처리 속도가 서로 다를 때
작업을 여러 Worker에게 분산할 때
재처리가 필요할 때

예를 들어:

flowchart LR
    n0["결제 완료"] --> n1["Queue"] --> n2["영수증 생성 Worker"]

영수증 시스템이 잠시 느려져도
결제 시스템 전체가 같이 느려질 필요는 없다.

11. 이벤트 브로커

서비스 사이에서 이벤트를 전달하는 중개자를
Event Broker라고 부른다.

flowchart TD
    n0["서비스 A"]
    n1["Event Broker"]
    n2["서비스 B"]
    n3["서비스 C"]
    n4["서비스 D"]
    n1 --> n2
    n1 --> n3
    n1 --> n4
    n0 --> n1

Broker를 사용하면 Producer가 Consumer에게
직접 연결될 필요가 없다.

12. 메시지 큐와 이벤트 스트림

이벤트 전달 기술이 모두 같은 역할을 하는 것은 아니다.

Message Queue
Event Stream
Event Router
Stream Processing / Aggregation

이 중 가장 헷갈리는 둘을 먼저 비교해 보자.

두 개는 특히 자주 비교된다.

메시지 큐

작업을 분배하는 데 초점이 있다.

flowchart TD
    n0["Producer"]
    n1["Queue"]
    n2["Worker A"]
    n3["Worker B"]
    n4["Worker C"]
    n0 --> n1
    n1 --> n2
    n1 --> n3
    n1 --> n4

하나의 작업을 여러 Worker 중 하나가
처리하는 구조가 대표적이다.

이벤트 스트림

시간 순으로 발생한 이벤트 기록을
일정 기간 유지하면서

여러 Consumer가 각자의 위치에서
독립적으로 읽을 수 있다.

flowchart TD
    n0["Producer"]
    n1["Event Stream"]
    n2["Consumer A"]
    n3["Consumer B"]
    n4["Consumer C"]
    n1 --> n2
    n1 --> n3
    n1 --> n4
    n0 --> n1

Kafka 같은 시스템을 떠올리면 쉽다.

다만 실제 메시징 제품들은 기능이 많이 겹치므로
제품 이름만 보고 완전히 구분하면 안 된다.

13. 이벤트 라우터

이벤트의 내용이나 조건을 보고
목적지를 결정하는 방식이다.

flowchart LR
    e["Event"] --> r["Router"]
    r -- "payment" --> a["결제 처리"]
    r -- "order" --> b["주문 처리"]
    r -- "delivery" --> c["배송 처리"]

복잡한 서비스 연결 관계를
중간에서 정리할 때 활용할 수 있다.

14. Fan-out

하나의 이벤트를
여러 Consumer가 독립적으로 사용하는 패턴이다.

flowchart LR
    p["Producer"] --> ev["Event"]
    ev --> a["Consumer A"]
    ev --> b["Consumer B"]
    ev --> c["Consumer C"]

예를 들어 OrderCompleted 이벤트를

랭킹
정산
통계
알림
분석

시스템이 각각 사용할 수 있다.

15. 단순 이벤트 처리

이벤트를 어떻게 다루느냐에 따라
처리 방식을 셋으로 나눠 볼 수 있다.

단순 이벤트 처리
스트림 처리
복합 이벤트 처리

가장 단순한 것부터 보자.

하나의 이벤트를 받아
바로 특정 작업을 수행한다.

flowchart LR
    n0["OrderCompleted"] --> n1["주문 알림 전송"]

이벤트 하나만 보고 판단하기 때문에
가장 단순한 처리 방식이다.

16. 스트림 처리

계속 들어오는 이벤트의 흐름을
실시간으로 처리한다.

flowchart LR
    e["끊임없이 들어오는 Event"] --> sp["Stream Processing"]

예를 들어 최근 1분 동안 발생한 주문을 모아

총 주문 금액
평균 주문 금액
주문 횟수

를 계산할 수 있다.

17. 복합 이벤트 처리

CEP(Complex Event Processing) 는
여러 이벤트 사이의 관계나 패턴을 분석한다.

예를 들어:

flowchart LR
    n0["로그인 실패 반복"] --> n1["새로운 지역에서 로그인"] --> n2["비밀번호 변경"] --> n3["고액 결제"]

가 짧은 시간 안에 연속해서 발생했다면

이상 거래 의심

으로 판단할 수 있다.

CEP와 일반적인 스트림 처리는
실제 기술이나 제품에서는 영역이 겹칠 수 있다.

따라서 다음 정도로 이해하면 충분하다.

단순 처리
= 개별 이벤트

스트림 처리
= 이벤트의 연속적인 흐름

CEP
= 여러 이벤트 사이의 복잡한 패턴

18. 윈도우

스트림은 끝없이 들어온다.

따라서

어느 범위를 계산할 것인가?

를 정해야 한다.

이를 Window라고 한다.

Tumbling Window

겹치지 않는 고정 구간이다.

10:00 ~ 10:01
10:01 ~ 10:02
10:02 ~ 10:03

예:

1분 단위 주문 금액 집계

Sliding Window

구간이 서로 겹친다.

10:00 ~ 10:05
10:01 ~ 10:06
10:02 ~ 10:07

예:

매분 최근 5분 평균 방문자 계산

Session Window

사용자의 활동 흐름을 기준으로 구간을 만든다.

클릭
클릭
구매

이후 일정 시간 활동이 없다면
하나의 세션이 끝났다고 볼 수 있다.

19. 애플리케이션에서 직접 이벤트 생성

이벤트는 반드시 애플리케이션 코드에서만 생성할 필요는 없다.

애플리케이션에서 직접 생성
Polling
DB Trigger
CDC

네 가지를 차례로 보자.

가장 자연스러운 방법이다.

flowchart LR
    n0["주문 처리"] --> n1["DB 저장"] --> n2["OrderCompleted 생성"] --> n3["Broker 전송"]

하지만 문제가 있다.

flowchart LR
    n0["DB 저장 성공"] --> n1["이벤트 전송 실패"]

한다면

DB에는 정상 처리됐지만
이벤트를 받아야 할 시스템은 알지 못한다.

이런 문제를 해결하기 위해
Transactional Outbox Pattern 같은 방식을 사용하기도 한다.

20. Polling

별도의 프로그램이 DB를
주기적으로 확인한다.

10:00 DB 조회
10:01 DB 조회
10:02 DB 조회

예를 들어:

SELECT *
FROM orders
WHERE updated_at > :last_checked_time;

같은 방식이다.

구현은 비교적 쉽다.

하지만 조회 주기가 너무 짧으면
DB 부하가 증가한다.

반대로 조회 주기가 길면
이벤트 전달도 늦어진다.

21. DB Trigger

DB 데이터가 변경되는 순간
추가 로직을 자동 실행하는 방식이다.

flowchart LR
    n0["orders INSERT"] --> n1["Trigger"] --> n2["event_outbox INSERT"]

즉각적인 처리가 가능하지만
비즈니스 로직이 DB Trigger에 많이 들어가면

로직 추적
장애 분석
성능 관리
DB 종속성

이 복잡해질 수 있다.

22. CDC

Change Data Capture는

데이터베이스의 변경 내용을 감지하여
다른 시스템으로 전달하는 기술

이다.

MySQL/MariaDB 환경에서는
binlog 기반 CDC가 대표적인 방식이다.

flowchart LR
    n0["Application"] --> n1["Database"] --> n2["Transaction Log"] --> n3["CDC Connector"] --> n4["Event Stream"]

Debezium 같은 도구가 대표적이다.

단, CDC 전체가 반드시
트랜잭션 로그 방식만을 의미하는 것은 아니다.

23. CDC 이벤트와 비즈니스 이벤트는 다르다

이 차이는 반드시 알아야 한다.

예를 들어 데이터베이스에서

balance

1000 → 900

으로 변경됐다고 하자.

CDC가 발견한 것은

잔액 데이터가 변경됐다.

는 사실이다.

하지만 비즈니스 의미는

주문으로 100을 사용했다.

일 수도 있고

관리자가 잔액을 조정했다.

일 수도 있다.

따라서

DB Change Event
≠ Business Event

이다.

CDC만으로 모든 비즈니스 의미를
표현할 수 있다고 생각하면 안 된다.

24. 레거시를 옮길 때도 쓸 수 있다

기존 시스템을 한 번에 걷어내지 않고
기능을 하나씩 새 서비스로 옮기는 방법이 있다.

이때 이벤트를 기존 시스템과 새 시스템 사이의
연결 수단으로 쓸 수 있다.
새 서비스가 기존 시스템의 이벤트를 구독하면
양쪽을 동시에 고치지 않아도 된다.

점진적으로 옮기는 방법은
23장 「실행 로드맵」에서 다룬다.

25. 이벤트를 저장해야 하는 이유

이벤트를 실시간 처리한 뒤
바로 폐기할 수도 있다.

하지만 장기간 저장하면
다른 가치를 만들 수 있다.

예를 들어 주문 이벤트를 저장하면

랭킹
통계
정산
과거 분석
이상 거래 탐지
추천 모델

등에 다시 사용할 수 있다.

26. 이벤트 저장소

이벤트를 저장하는 저장소를
넓은 의미에서 Event Store라고 부를 수 있다.

하지만 주의해야 할 것이 있다.

단순히 이벤트를 오래 보관한다고 해서
모두 Event Sourcing의 Event Store가 되는 것은 아니다.

일반적인 이벤트 보관소는
재처리나 분석을 위한 저장소일 수 있다.

Event Sourcing에서의 Event Store는
애플리케이션 상태를 구성하는 핵심 기록이라는
더 강한 의미를 갖는다.

27. Replay

이벤트를 저장해두면
과거 이벤트를 다시 처리할 수 있다.

이를 Replay라고 한다.

예를 들어 랭킹 계산에 버그가 있었다면

flowchart LR
    n0["과거 주문 이벤트"] --> n1["수정된 계산 코드"] --> n2["랭킹 다시 생성"]

할 수 있다.

이벤트 저장의 큰 장점이다.

28. Event Sourcing

Event Sourcing은

현재 상태의 원천을
상태를 만들어낸 이벤트 기록으로 두는 방식

이다.

일반적인 방식에서는

balance = 700

처럼 현재 상태를 저장한다.

Event Sourcing에서는

PointCharged +1000
PointUsed -100
PointUsed -200

같은 이벤트를 기록한다.

현재 상태는

1000 - 100 - 200
= 700

으로 다시 만들 수 있다.

29. Event Sourcing은 현재 상태를 저장하면 안 되는가

그렇지 않다.

Event Sourcing에서 이벤트가
궁극적인 원천(Source of Truth)이지만

성능을 위해

Snapshot
Materialized View
Read Model

같은 현재 상태 데이터를
별도로 저장하는 경우도 많다.

예를 들어 이벤트가 백만 건 있다면
매번 처음부터 재생하는 것은 비효율적이다.

그래서 중간 상태를 Snapshot으로 저장할 수 있다.

flowchart LR
    n0["Event 1 ~ 10000"] --> n1["Snapshot"] --> n2["10001 이후 이벤트만 적용"]

30. 이벤트와 CQRS

CQRS는 읽기와 쓰기에 서로 다른 모델을 사용하는 방식이다.
DB를 반드시 두 개 만드는 것은 아니라는 점을 포함해
자세한 내용은 9장 「서비스 경계와 조회 모델」에서 다뤘다.

이벤트를 이용하여
Read Model을 만들 수도 있다.

flowchart LR
    n0["Command"] --> n1["Write Model"] --> n2["Domain Event"] --> n3["Read Model 갱신"]

예를 들어 쓰기 모델에서는
복잡한 정합성을 유지하고

조회 모델에서는

사용자별 주문 내역
판매자별 오늘 주문 금액
최근 상품 목록

처럼 조회 목적에 최적화된 데이터를 만들 수 있다.

31. 이벤트 데이터를 데이터 제품으로 활용하기

이벤트 데이터를 장기간 보관하면
데이터 분석에도 활용할 수 있다.

대표적으로 데이터 레이크나 Lakehouse에서는

flowchart LR
    n0["Bronze"] --> n1["Silver"] --> n2["Gold"]

구조를 사용할 수 있다.

이를 흔히 Medallion Architecture라고 한다.

다만 이 구조는

이벤트 기반 아키텍처의 필수 요소가 아니라
데이터 플랫폼에서 사용할 수 있는 별도의 패턴

이다.

32. 스트리밍 분석

데이터가 발생할 때
바로 분석할 수도 있다.

flowchart LR
    n0["Event"] --> n1["Streaming Analytics"] --> n2["Dashboard / Alert"]

예를 들어:

현재 매출
현재 접속자
최근 5분 오류율
현재 주문 금액

을 실시간으로 계산할 수 있다.

33. 데이터 보강

이벤트 자체에 필요한 정보가
전부 들어있지 않을 수도 있다.

예를 들어:

{
  "userId": 100,
  "amount": 5000
}

만 들어왔는데 분석에는

회원 등급
국가
가입일

정보가 필요할 수 있다.

이때 다른 데이터와 결합한다.

flowchart TD
    n0["Event"]
    n2["Reference Data"]
    n3["Enriched Event"]
    n0 --> n3
    n2 --> n3

이를 Data Enrichment라고 한다.

34. 스트리밍 플랫폼은 DB와 다르다

Kafka 같은 시스템을
일반적인 데이터베이스와 똑같이 보면 안 된다.

이벤트 스트리밍 플랫폼은 주로

대규모 순차 이벤트 처리
Consumer별 독립적 소비
Replay
스트림 처리

에 강하다.

일반적인 데이터베이스는

특정 데이터 조회
조건 검색
인덱스
JOIN
트랜잭션

등에 강하다.

아주 단순화하면:

Event Stream
= 사건의 흐름

Database
= 상태의 저장과 조회

라고 이해할 수 있다.

물론 현대 시스템들은 서로의 기능 일부를 제공하기도 하므로
절대적인 구분은 아니다.

35. 내부 이벤트와 외부 공개 이벤트

시스템이 커지면
모든 이벤트를 다른 도메인에 공개해서는 안 된다.

크게 다음처럼 구분할 수 있다.

내부 이벤트
외부 계약용 이벤트

책이나 조직에 따라 이를

Internal Stream
Domain Stream
Business Stream
Integration Event

등 다양한 이름으로 부를 수 있다.

용어보다 경계를 이해하는 것이 중요하다.

36. 내부 이벤트

도메인 내부 구현을 위한 이벤트이다.

예를 들어:

OrderValidated
PointDeductionStarted
PointDeductionFinished

같은 이벤트이다.

다른 도메인이 이런 이벤트까지
직접 사용하면 내부 구현을 변경하기 어려워진다.

37. 외부 계약용 이벤트

다른 도메인이 사용하도록
명확하게 공개하는 이벤트이다.

예:

OrderCompleted
PaymentCompleted
DeliveryStarted

이 이벤트는 다른 팀과 시스템이 사용하므로

스키마
의미
버전
호환성
소유자

를 계약처럼 관리해야 한다.

쉽게 비교하면:

Internal Event
≈ private interface

공개 Domain Event
≈ public API

라고 생각할 수 있다.

38. 이벤트 거버넌스

이벤트가 수백 개, 수천 개로 늘어나면
기술보다 관리가 더 어려워질 수 있다.

다음 질문에 답할 수 있어야 한다.

이 이벤트의 소유자는 누구인가?

누가 사용하고 있는가?

스키마는 어디에 있는가?

현재 버전은 무엇인가?

이 필드를 삭제해도 되는가?

얼마나 오래 보관하는가?

개인정보가 포함되어 있는가?

이것을 체계적으로 관리하는 것이
이벤트 거버넌스이다.

39. 이벤트의 소유권

일반적으로 이벤트를 발행하는 도메인이
그 이벤트의 소유자가 된다.

예:

OrderCompleted

Owner
= Order Domain

소유자는 보통 다음을 책임진다.

이벤트 의미
스키마
문서
버전
호환성
품질

즉 이벤트를 외부에 공개했다는 것은

단순히 메시지 하나를 보낸 것이 아니라
다른 시스템과 계약을 만든 것

이라고 이해해야 한다.

40. Schema Registry

이벤트의 스키마와 버전을 관리하기 위해
Schema Registry를 사용할 수 있다.

기존 이벤트가:

{
  "userId": 100,
  "amount": 5000
}

이라고 하자.

그런데 Producer가 갑자기:

{
  "memberId": 100,
  "price": 5000
}

로 바꾸면 기존 Consumer가 깨질 수 있다.

Schema Registry와 호환성 정책을 사용하면

필드 삭제
타입 변경
필수 필드 변경
스키마 버전

등을 검사할 수 있다.

단,

Registry가 있다고 자동으로 안전해지는 것은 아니다.

CI/CD 과정에서 스키마 호환성을 검증하고
조직의 변경 정책을 함께 적용해야 한다.

41. Contract-First

이벤트가 많아질수록
구현 전에 계약을 먼저 정의하는 것이 좋다.

좋지 않은 흐름:

flowchart LR
    n0["코드 구현"] --> n1["이벤트 생성"] --> n2["나중에 문서 작성"]

Contract-First 방식:

flowchart LR
    n0["이벤트 의미 정의"] --> n1["스키마 정의"] --> n2["호환성 검토"] --> n3["Producer 구현"] --> n4["Consumer 구현"]

REST API의 API-First와
비슷한 사고방식이다.

42. AsyncAPI

이벤트 기반 인터페이스를 문서화하는 데
AsyncAPI 같은 표준을 사용할 수 있다.

초보자 관점에서는 다음과 같이 이해하면 된다.

• HTTP REST API — OpenAPI
• 이벤트/메시지 기반 API — AsyncAPI

이를 통해

채널
메시지
Payload
Schema
Producer
Consumer

등을 문서화할 수 있다.

OpenAPI와 완전히 동일한 역할은 아니지만
비슷한 목적의 계약 문서라고 이해하면 된다.

43. 셀프서비스와 플랫폼 팀

조직이 커지면
중앙 플랫폼 팀이 모든 이벤트를 직접 관리하기 어렵다.

그래서 플랫폼 팀은

이벤트 플랫폼
Schema Registry
Event Catalog
모니터링
보안 정책
배포 자동화

등을 제공한다.

각 도메인 팀은 그 위에서

이벤트 생성
스키마 등록
배포
소비

를 스스로 할 수 있다.

이런 구조를 셀프서비스 방식이라고 볼 수 있다.

44. 셀프서비스에는 가드레일이 필요하다

셀프서비스는

아무렇게나 만들 수 있다.

는 뜻이 아니다.

다음과 같은 검사를 자동화하는 것이 좋다.

이벤트 이름 규칙
스키마 호환성
소유자 등록
보안 검사
보존 기간
개인정보 여부

즉,

개발자가 빠르게 작업할 수 있도록 하되
위험한 변경은 자동으로 막는 것

이 좋은 플랫폼의 역할이다.

이 생각을 조직 전체로 넓히면
22장 「플랫폼과 조직」의 이야기가 된다.

45. 10장 정리

네 가지만 기억하면 된다.

이벤트는 이미 발생한 사실이다.
무엇을 해달라는 Command,
정보를 달라는 Query와 구분해야 한다.

Producer는 Consumer가 누구인지 몰라도 된다.
이것이 이벤트가 결합도를 낮추는 이유다.

이벤트에 무엇을 담을지가 설계의 핵심이다.
변경 사실만 알릴 것인가,
필요한 상태까지 함께 보낼 것인가에 따라
API 의존성과 데이터 관리 부담이 반대로 움직인다.

내부 이벤트와 공개 이벤트를 나눠야 한다.
공개한 이벤트는 메시지 하나가 아니라
다른 시스템과 맺은 계약이다.

여기까지는 이벤트를 만들고 전달하는 이야기였다.

다음 장에서는 만든 다음에 찾아오는 문제,
즉 운영을 본다.

11장. 이벤트를 운영한다는 것

3부 · 연결 — 경계를 어떻게 넘는가
8장 · 9장 · 10장 · 11장 · 12장

이벤트를 도입하고 한 달이 지났다.

같은 알림이 두 번 갔다는 문의가 들어오고,
어떤 정산은 순서가 뒤바뀐 채 처리됐다.

처리에 실패한 메시지가 어디로 갔는지도
아무도 모른다.

10장에서 이벤트를 설계하고 전달하는 방법을 봤다.

하지만 이벤트 기반 시스템의 어려움은
대부분 만든 다음에 찾아온다.

이 장에서는 운영에서 마주치는 문제를 다룬다.

중복과 순서, 실패와 재처리,
쌓이는 메시지, 스키마 변경, 보존 기간이다.

이벤트 기반 아키텍처가 공짜가 아닌 이유가 여기 있다.

1. 이벤트의 불변성

이벤트는 이미 발생한 사건이다.

따라서 기본적으로

Immutable

하게 취급하는 것이 좋다.

예를 들어:

OrderCompleted

이 잘못된 이벤트였다면
기존 이벤트를 수정하는 것이 아니라

OrderCancelled

또는

OrderCorrected

같은 새로운 이벤트를 발생시키는 방식이다.

즉:

과거의 사건을 수정 X

새로운 사건을 추가 O

라고 생각하면 된다.

2. 결과적 일관성

이벤트 기반 시스템은
여러 시스템이 동시에 갱신되지 않는 경우가 많다.

예를 들어:

10:00:00 결제 완료

10:00:01 통계 반영

10:00:03 정산 반영

10:00:02 시점에는

결제 시스템
= 반영 완료

정산 시스템
= 아직 미반영

일 수 있다.

하지만 새로운 변경이 없고
이벤트 전달과 재처리가 정상적으로 계속된다면

결국 같은 상태로 수렴할 수 있다.

이를 Eventual Consistency,
결과적 일관성이라고 한다.

3. 강한 일관성

강한 일관성이 필요한 시스템도 있다.

단순하게 말하면

성공한 최신 변경을
이후의 읽기에서 일관되게 볼 수 있도록 하는 강한 보장

이다.

예를 들어 중요한 잔액 데이터라면

flowchart LR
    n0["1000"] --> n1["300 사용"] --> n2["700"]

이라는 결과가 즉시 중요할 수 있다.

분산 시스템에서 강한 일관성을 구현하려면
노드 간 추가적인 조정이 필요하다.

그 결과

지연 증가
처리량 감소 가능성
가용성과의 트레이드오프

가 발생할 수 있다.

중요한 것은

강한 일관성
= 무조건 모든 노드를 Lock

이 아니라는 것이다.

구현에는 Consensus, Quorum 등
여러 방식이 사용될 수 있다.

4. 데이터마다 일관성 요구는 다르다

모든 데이터를
같은 수준으로 처리할 필요는 없다.

예:

실시간 인기 랭킹

→ 몇 초 지연 가능
→ 결과적 일관성 가능

반면:

결제 승인
잔액 차감
재고 확정

같은 영역은 더 강한 정합성이
필요할 수 있다.

따라서

업무의 중요도와 요구사항에 따라
일관성 모델을 선택한다.

가 중요하다.

5. 메시지 전달과 처리 보장

메시징 시스템에서는

At-most-once
At-least-once
Exactly-once

라는 표현이 자주 등장한다.

여기서 중요한 것은

어떤 범위에서 무엇을 보장하는가?

를 반드시 확인하는 것이다.

Broker 수준의 전달과
외부 DB까지 포함한 전체 비즈니스 처리는
다른 문제일 수 있기 때문이다.

6. At-most-once

최대 한 번 처리되는 방식이다.

0번 또는 1번

재전송하지 않는다면
메시지가 유실될 수 있다.

대신 중복 가능성은 줄어든다.

7. At-least-once

최소 한 번은 처리하도록
재전송하는 방식이다.

1번 이상

따라서 같은 이벤트가
여러 번 들어올 수 있다.

실무에서는 매우 흔한 방식이다.

8. 멱등성

At-least-once 환경에서는
Consumer의 멱등성이 중요하다.

Idempotency란

같은 작업을 여러 번 수행해도
최종 결과가 한 번 수행한 것과 동일하도록 만드는 것

이다.

예를 들어:

event_id = 100

이라는 주문 이벤트가 두 번 전달됐다고 하자.

잘못된 처리:

100 지급
100 지급

→ 총 200

멱등하게 처리하면:

flowchart TD
    n0["event_id=100 처리"]
    n1["다시 event_id=100 수신"]
    n2["이미 처리됨"]
    n3["무시"]
    n0 --> n2
    n1 --> n2
    n2 --> n3

할 수 있다.

9. Exactly-once

Exactly-once는 이름 그대로

유실 없이
중복 효과 없이
정확히 한 번

을 목표로 한다.

하지만 분산 시스템 전체에서
End-to-End Exactly-once를 구현하는 것은 어렵다.

예를 들어:

flowchart LR
    n0["Kafka 이벤트 읽음"] --> n1["DB UPDATE 성공"] --> n2["Kafka offset 저장 전 장애"]

가 발생하면

다시 실행된 Consumer가
같은 이벤트를 또 읽을 수 있다.

따라서 Kafka 자체의 트랜잭션 기능이 있다고 해서

Kafka
DB
외부 결제 API
메일 서비스

전체 작업이 자동으로 Exactly-once가 되는 것은 아니다.

현실에서는 흔히

At-least-once
+
멱등성

을 이용해
중복 효과를 방지한다.

10. 메시지 순서

이벤트는 순서가 중요할 수 있다.

예를 들어:

UserCreated
UserUpdated
UserDeleted

순서가 뒤집히면 문제가 발생할 수 있다.

분산 시스템에서는 병렬 처리가 많기 때문에
전체 이벤트의 순서를 보장하는 것은 비용이 크다.

11. Kafka와 메시지 순서

Kafka에서는 기본적으로

같은 Partition 내부에서 순서가 유지된다.

라고 이해해야 한다.

예를 들어 하나의 주문과 관련된 이벤트를
같은 Partition으로 라우팅하면

OrderCreated
PaymentCompleted
OrderCompleted

순서를 유지하기 쉬워진다.

흔히 Key를 이용해
같은 엔티티를 동일 Partition으로 라우팅한다.

하지만 정확한 표현은

같은 Key라서 순서가 보장된다.

가 아니라

동일 Partition 안에서 순서가 보장된다.

이다.

12. 전체 순서보다 엔티티 단위 순서

모든 이벤트를 하나의 Partition에 넣으면
전체 순서를 유지하기 쉽다.

하지만 병렬 처리 성능이 크게 떨어진다.

그래서 현실에서는

user_id
order_id
payment_id
delivery_id

같은 특정 Key 단위로
순서를 관리하는 경우가 많다.

13. Dead Letter Queue

처리를 계속 실패하는 메시지를
별도 공간으로 옮길 수 있다.

이를 Dead Letter Queue, DLQ라고 한다.

flowchart LR
    n0["Main Queue"] --> n1["Consumer"] --> n2["실패"] --> n3["Retry"] --> n4["계속 실패"] --> n5["DLQ"]

예를 들어:

잘못된 메시지 형식
필수 데이터 누락
Consumer 버그
지원하지 않는 이벤트 버전

등으로 실패할 수 있다.

14. DLQ를 만들었다고 끝이 아니다

DLQ가 있는데 아무도 확인하지 않는다면
사실상 데이터 쓰레기통이 된다.

따라서 반드시

모니터링
알림
원인 분석
수정
재처리

과정이 필요하다.

DLQ는 기술 기능인 동시에
운영 프로세스가 필요한 영역이다.

15. Backlog와 Backpressure

Producer가 Consumer보다
훨씬 빠르게 데이터를 생성한다고 해보자.

Producer
초당 10,000건

Consumer
초당 3,000건

그러면 처리되지 못한 메시지가 계속 쌓인다.

이를 Backlog라고 볼 수 있다.

flowchart LR
    n0["입력 > 처리량"] --> n1["Backlog 증가"] --> n2["지연 증가"] --> n3["저장 공간 증가"]

Backpressure란 무엇인가

Backpressure는 backlog 자체를 의미하는 것이 아니다.

Consumer나 하위 시스템의 처리 능력에 맞춰
상위 시스템의 데이터 생산 속도를 조절하는 메커니즘

이다.

예를 들어:

flowchart LR
    n0["Consumer 처리 한계 감지"] --> n1["Producer 전송 속도 감소"]

처럼 흐름을 제어할 수 있다.

시스템에 따라

생산 속도 제한
Consumer 확장
버퍼링
Batch 처리
Load Shedding

등 다양한 대응 전략을 사용할 수 있다.

16. 직렬화

Java Object나 Go Struct를
그대로 네트워크에 보낼 수는 없다.

전송 가능한 데이터 형식으로 변환해야 한다.

이를 Serialization,
직렬화라고 한다.

flowchart LR
    n0["Application Object"] --> n1["Serialization"] --> n2["Message"]

Consumer에서는 반대로

flowchart LR
    n0["Message"] --> n1["Deserialization"] --> n2["Application Object"]

을 수행한다.

17. JSON

가장 익숙한 데이터 형식이다.

{
  "userId": 100,
  "amount": 5000
}

장점:

사람이 읽기 쉬움
개발하기 쉬움
언어 독립적
범용성이 높음

단점:

상대적으로 데이터 크기가 큼
스키마 강제가 약함
타입 표현이 제한적

이다.

18. Avro와 Protocol Buffers

대규모 이벤트 시스템에서는

Apache Avro
Protocol Buffers
Apache Thrift

같은 직렬화 기술도 사용된다.

이들은 명확한 스키마를 기반으로
데이터 타입과 구조를 관리하기 좋다.

예를 들어:

flowchart LR
    n0["Schema 정의"] --> n1["Producer"] --> n2["Binary Message"] --> n3["Consumer"]

형태로 처리한다.

초보자 관점에서는

JSON
= 유연하고 쉬움

Avro / Protobuf
= 스키마를 강하게 관리하기 좋음

정도로 이해하면 충분하다.

19. 이벤트 스트림의 장기 보존

이벤트 스트리밍 플랫폼에
데이터를 장기간 보존할 수도 있다.

하지만 보존 기간이 늘어나면

저장 비용
운영 비용
개인정보 관리
삭제 정책
규제 준수

등을 고려해야 한다.

따라서 무조건

모든 이벤트 무기한 저장

하는 것이 좋은 것은 아니다.

20. Hot / Cold Storage 분리

최근 데이터와 오래된 데이터를
다른 저장소에 둘 수도 있다.

예:

• 최근 7일 이벤트 — Event Streaming Platform
• 7일 이전 — Object Storage / Data Lake

이렇게 하면

실시간 처리
= Streaming Platform

장기 분석
= Data Lake

처럼 역할을 나눌 수 있다.

21. 공통 플랫폼과 비즈니스 로직 분리

이벤트 플랫폼에는 가급적
범용적인 기능을 둔다.

예를 들어:

전송
저장
라우팅
스키마 검사
모니터링
보안

이다.

반면 다음 같은 비즈니스 규칙은

환불 가능 여부
주문 계산
출금 환산율
회원 등급

해당 도메인 안에 두는 것이 좋다.

플랫폼이 모든 비즈니스 규칙을 알기 시작하면
플랫폼 자체가 거대한 업무 시스템이 되기 때문이다.

22. 모든 것을 이벤트 기반으로 만들 필요는 없다

이벤트 기반 아키텍처는 강력하다.

하지만 다음과 같은 복잡성도 가져온다.

Broker
Schema 관리
Retry
DLQ
멱등성
순서 처리
모니터링
분산 추적
결과적 일관성

단순 CRUD 시스템에 이 모든 것을 도입하면
얻는 가치보다 운영 비용이 더 클 수 있다.

따라서 질문은

"이벤트 기반으로 만들 수 있는가?"

가 아니라

"이벤트 기반으로 만들 가치가 있는가?"

여야 한다.

23. 이벤트 기반 아키텍처가 잘 맞는 경우

다음과 같은 상황이라면
EDA가 큰 장점을 줄 수 있다.

하나의 사건에 여러 시스템이 반응해야 한다.

서비스 간 직접 의존성을 줄이고 싶다.

비동기 처리가 필요하다.

실시간 데이터 처리가 중요하다.

대량의 이벤트가 발생한다.

과거 이벤트를 다시 처리해야 한다.

여러 분석 시스템에 데이터를 제공해야 한다.

반대로 단순한 내부 관리 시스템이라면
일반적인 API 구조가 더 적합할 수도 있다.

24. 11장 정리

네 가지만 기억하면 된다.

이벤트는 중복될 수 있다고 가정한다.
At-least-once가 현실적인 기본값이고,
그래서 Consumer를 여러 번 처리해도 괜찮게 만든다.
Exactly-once는 조건이 붙는 보장이다.

순서는 전체가 아니라 필요한 단위만 보장한다.
모든 메시지의 전역 순서를 지키려 하면 처리량을 잃는다.
같은 주문, 같은 회원처럼 엔티티 단위면 대개 충분하다.

실패한 메시지는 어디론가 가야 하고, 누군가 봐야 한다.
DLQ를 만들어 두는 것과 그것을 들여다보는 것은 다른 일이다.
아무도 보지 않는 DLQ는 쓰레기통이다.

Kafka를 쓴다고 이벤트 기반 아키텍처가 되는 것은 아니다.
설계, 소비, 스키마, 중복, 순서, 장애 처리까지가 EDA다.

이벤트의 수명주기

이벤트는 만들고 끝나는 것이 아니다.

flowchart TB
    S1["만든다<br/>──────────<br/>사건이 발생하면 Application · CDC · Polling으로<br/>이벤트를 만든다"]
    S2["보낸다<br/>──────────<br/>Queue · Broker · Stream · Router로 전달한다"]
    S3["쓴다<br/>──────────<br/>단순 처리와 스트림 처리를 거쳐<br/>랭킹 · 알림 · 정산 · 통계가 소비한다"]
    S4["쌓는다<br/>──────────<br/>Event Store에 보관하고<br/>Replay · 분석 · 머신러닝에 쓴다"]
    S5["지킨다<br/>──────────<br/>재시도 · DLQ · 순서 · 멱등성<br/>백프레셔 · 모니터링"]
    S6["다스린다<br/>──────────<br/>Owner · 스키마 · 버전<br/>계약 · 보안 · 보존 기간"]

    S1 --> S2 --> S3 --> S4
    S4 -.-> S5
    S5 -.-> S6

    style S1 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S2 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S3 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S4 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S5 fill:#f8fbff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a
    style S6 fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a

위 넷은 10장에서, 아래 둘은 이 장에서 다뤘다.

만드는 것보다 지키고 다스리는 쪽이 어렵다.

새 이벤트를 설계할 때 던질 질문

이것은 정말 이벤트인가, 아니면 Command인가?

Producer는 누구이고 소유 도메인은 어디인가?

누가 Consumer인가?

어떤 데이터를 담을 것인가? 개인정보가 포함되는가?

중복 전달되어도 안전한가?

순서가 중요한가? 어느 단위까지 중요한가?

실패하면 어떻게 재시도하고, DLQ는 누가 보는가?

얼마나 오래 보관하고, 스키마 변경은 어떻게 관리하는가?

과거 이벤트를 Replay해야 하는가?

무엇을 모니터링할 것인가?

이 질문에 답할 수 있다면
운영에서 만날 문제를 상당 부분 미리 발견할 수 있다.

공짜가 아니다

이벤트로 서비스 간 결합은 줄일 수 있다.

대신 새로운 복잡성이 온다.

분산 시스템
비동기 처리
결과적 일관성
중복 처리
장애 복구
운영과 모니터링

그래서 좋은 설계의 기준은
최대한 많이 이벤트로 만드는 것이 아니다.

늘어나는 복잡성을 감수할 만큼
분명한 비즈니스 가치가 있는 곳에
이벤트 기반 구조를 쓰는 것.

다음 장에서는 API와 이벤트와 배치 가운데
무엇을 언제 고를지를 정리한다.

12장. 무엇으로 연결할 것인가

3부 · 연결 — 경계를 어떻게 넘는가
8장 · 9장 · 10장 · 11장 · 12장

8장과 9장에서는 API를,
10장과 11장에서는 이벤트를 따로 살펴봤다.

하나씩 볼 때는 분명해 보인다.
그런데 실제 시스템에서 둘 중 하나만 쓰는 경우는 드물다.

업무 하나를 처리하는 데도 API와 이벤트가 함께 등장하고,
아직 이름조차 꺼내지 않은 선택지가 하나 더 있다.

배치다.

이번 장의 질문은 하나다.

지금 이 연결에는 무엇이 맞는가?

API, 이벤트, 배치는 서로를 대체하는 기술이 아니다.
각각 잘 푸는 문제가 다르다.
그 차이를 정리하는 것이 이 장의 목적이다.

1. 하나의 업무에도 여러 방식이 함께 쓰인다

사용자가 10,000원짜리 상품을 주문한다고 해보자.

겉으로는 단순한 기능처럼 보인다.
하지만 실제로는 여러 시스템이 연결된다.

flowchart LR
    u["사용자"]
    o["주문 서비스"]
    p["포인트 서비스"]
    done["주문 완료"]
    noti["알림"]
    rank["랭킹"]
    settle["정산"]
    plat["데이터 플랫폼"]
    dp["Data Product"]
    bi["BI"]
    an["분석"]
    ml["ML"]

    u --> o
    o -- "포인트 차감 요청" --> p
    p -- "차감 성공" --> done
    done -- "Event" --> noti
    done -- "Event" --> rank
    done -- "Event" --> settle
    done -- "Event" --> plat
    plat --> dp
    dp --> bi
    dp --> an
    dp --> ml

이 그림 하나에 세 가지 방식이 이미 섞여 있다.

포인트 차감은 결과를 바로 알아야 하므로 동기 API로 부른다.

주문이 끝난 뒤의 알림, 랭킹 반영, 정산, 분석 데이터 적재는
주문 요청 안에서 다 끝날 필요가 없다.
이런 일은 이벤트로 흘려보낸다.

오래 쌓아 두고 분석할 데이터는
다시 별도의 데이터 프로덕트로 제공한다.

그래서 중요한 질문은 “API가 좋은가, 이벤트가 좋은가“가 아니다.

지금 해결하려는 문제에
어떤 방식이 맞는가?

이 장은 그 답을 이렇게 찾아간다.

먼저 도메인을 어떤 창구로 이어야 하는지,
그리고 무엇을 위해 잇는지를 정리한다.
그다음 API·이벤트·배치를 차례로 보고
마지막에 선택 기준으로 모은다.

2. 도메인을 나눠도 통신은 해야 한다

회사 시스템을 회원·결제·상품·주문·배송·정산으로 나눴다고 하자.

각각 다른 책임을 갖지만,
주문 하나를 처리하려면 회원 정보와 포인트 잔액과 배송 상태가 모두 필요하다.

도메인을 나눈다는 것은 서로 단절시키겠다는 뜻이 아니다.
독립적인 책임을 유지하면서도 필요한 정보는 주고받을 수 있어야 한다.
이를 상호운용성(Interoperability) 이라고 한다.

문제는 주고받는 방법이다.

가장 간단한 방법은 남의 DB를 직접 조회하는 것이다.

SELECT *
FROM payment.payment_history
WHERE user_id = 100;

처음에는 편하다. 별도의 API도 필요 없다.

하지만 이런 접근이 쌓이면
결제팀이 테이블 하나를 바꿀 때마다
누가 그 테이블을 쓰는지 전부 찾아야 한다.

도메인은 나눴는데 실제로는 더 강하게 묶인 상태가 된다.
7장 「무엇을 공개하고 무엇을 감출 것인가」에서 본 문제다.

그래서 각 도메인은 내부 구현 대신 공개된 계약을 내놓는다.

flowchart LR
    OTHER["다른 도메인"]

    subgraph DOMAIN["결제 도메인"]
        CONTRACT["외부 인터페이스<br/><br/>Payment API<br/>PaymentCompleted Event<br/>Payment Data Product"]

        subgraph INNER["🔒 내부 구현"]
            T1["payment"]
            T2["payment_detail"]
            T3["pg_log"]
        end

        CONTRACT --> INNER
    end

    OTHER -->|"공개된 계약만 사용"| CONTRACT

    style CONTRACT fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a
    style INNER fill:#f5f5f5,stroke:#999,stroke-dasharray: 5 5,color:#1a1a1a

여기서 초보자가 자주 오해하는 것이 하나 있다.

도메인을 나누려면
반드시 DB도 각각 분리해야 하는가?

그렇지 않다.

하나의 MariaDB를 쓰면서도
스키마로 소유권을 나누면 논리적인 경계를 만들 수 있다.

중요한 것은 물리적인 DB 개수가 아니라
누가 어떤 데이터에 접근할 책임을 가지고 있는가다.

flowchart LR
    ORDER["Order Domain"]
    COMMERCE["Commerce Domain"]

    subgraph DB["하나의 MariaDB"]
        OT[("order.*")]
        CT[("commerce.*")]
        ST[("settlement.*")]
        MT[("member.*")]
    end

    ORDER --> OT
    COMMERCE --> CT
    ORDER -. "❌ 직접 접근 금지<br/>필요하면 Commerce 도메인에 요청" .-x CT

    style DB fill:#fafafa,stroke:#999,color:#1a1a1a

즉,

물리적인 데이터베이스 분리와
논리적인 도메인 분리는 서로 다른 문제다.

정리하면 도메인끼리는 공개된 창구로만 잇는다.

그 창구의 형태가 바로 API, 이벤트, 배치다.
어떤 형태를 고를지는 무엇을 위해 잇는지에 따라 갈린다.

3. 운영 데이터와 분석 데이터

연결 방식을 고르기 전에
데이터가 두 세계를 오간다는 것을 알아 둘 필요가 있다.

하나는 실제 서비스를 처리하는 운영 영역이다.
로그인, 회원가입, 결제, 상품 구매, 주문, 배송 시작 같은 일이다.

여기서는 빠른 응답, 트랜잭션 처리, 현재 상태, 정합성이 중요하다.
흔히 OLTP라고 부른다.

다른 하나는 분석 영역이다.
월간 매출, 사용자 행동 분석, 상품별 주문 통계, 추천 모델, BI 같은 일이다.

전통적으로는 둘 사이를 이렇게 이었다.

flowchart LR
    n0["운영 DB"]
    n1["Data Warehouse"]
    n2["BI / 분석 / ML"]
    n0 -- "ETL" --> n1
    n1 --> n2

한 방향이었다. 운영에서 분석으로만 흘렀다.

그런데 오늘날에는 이 경계가 흐려졌다.

추천 기능을 생각해보자.
사용자가 상품을 조회하면 행동 데이터가 쌓이고,
그 데이터로 만든 추천 결과가 다시 서비스 화면에 나타난다.

flowchart LR
    o["운영"] -- "행동 데이터" --> a["분석"]
    a -- "추천 결과" --> o

분석 데이터가 다시 운영으로 돌아온다.

그래서 애플리케이션 아키텍처와 데이터 아키텍처를
서로 다른 문제로 떼어 놓기 어려워졌다.

4. 데이터 배포와 애플리케이션 통합은 목적이 다르다

연결 방식을 고를 때 먼저 구분해야 할 것이 있다.

무엇을 위해 잇는가다.

데이터 배포의 목적은
데이터를 다른 곳에서 쓸 수 있게 만드는 것이다.
Batch, CDC, Data Streaming, Data Product, CQRS Read Model이 여기에 속한다.

애플리케이션 통합의 목적은
애플리케이션들이 서로 협력하게 만드는 것이다.
REST API, gRPC, Message Queue, Event, Command가 여기에 속한다.

flowchart LR
    subgraph DIST["데이터 배포 — 데이터를 쓸 수 있게"]
        D1["Batch"]
        D2["CDC"]
        D3["Data Streaming"]
        D4["Data Product"]
    end

    subgraph INTEG["애플리케이션 통합 — 서로 협력하게"]
        I1["REST API"]
        I2["gRPC"]
        I3["Message Queue"]
        I4["Event"]
    end

    style DIST fill:#f8fbff,stroke:#4a90e2,color:#1a1a1a
    style INTEG fill:#f2fbf4,stroke:#4caf50,color:#1a1a1a

여기 나온 Data Product는
여러 팀이 반복해서 쓰는 데이터를 제품처럼 정리해 내놓는 것을 말한다.
지금은 데이터 배포 방식 중 하나로만 알아 두면 되고,
13장 「데이터 프로덕트」에서 자세히 다룬다.

둘은 목적이 다르지만 실제 시스템에서는 겹치기도 한다.
이벤트는 애플리케이션을 잇는 데도, 데이터를 나르는 데도 쓰인다.

그래도 “지금 나는 데이터를 넘기려는 것인가,
아니면 일을 시키려는 것인가“를 먼저 물으면
선택이 훨씬 쉬워진다.

5. API는 언제 쓰는가

API는 가장 익숙한 방법이다.

주문 서비스가 현재 포인트 잔액을 알고 싶다고 해보자.

flowchart LR
    n0["주문 서비스"] -- "GET /points/balance" --> n1["포인트 서비스"]
    n1 -- "잔액 반환" --> n0

요청하고 응답을 받는다.

현재 상태를 바로 확인하거나
처리 결과가 즉시 필요할 때 적합하다.
현재 잔액, 회원 상태, 구매 가능 여부, 결제 승인 결과 같은 것이다.

여기서 정확하게 알아둘 것이 하나 있다.

API 자체가 동기 통신을 뜻하는 것은 아니다.

요청-응답 API가 동기로 쓰이는 경우가 많을 뿐이다.

영상 처리 요청을 보냈다고 해보자.

POST /videos/process

서버는 처리가 끝날 때까지 기다리지 않고

202 Accepted

를 먼저 돌려줄 수 있다. 실제 처리는 뒤에서 비동기로 한다.

그래서 기준은 API냐 아니냐가 아니라 이렇게 잡는 것이 정확하다.

• 결과가 즉시 필요하다 — 동기 API를 우선 검토
• 나중에 처리해도 된다 — 비동기 API나 메시징을 검토

6. 동기 API를 써도 강한 일관성은 보장되지 않는다

또 하나 흔한 오해가 있다.

API를 썼으니 데이터가 항상 맞아떨어질 것이라는 생각이다.
그렇지 않다.

독립된 두 서비스가 있다고 하자.

flowchart LR
    n0["주문 서비스 DB"] -- "API" --> n1["포인트 서비스 DB"]

다음 상황이 일어날 수 있다.

1. 포인트 차감 성공
2. 주문 저장 시도
3. 주문 DB 저장 실패

API 호출은 성공했는데 전체 업무는 깨진 상태로 남는다.
포인트만 빠져나갔다.

따라서 여러 시스템에 걸친 정합성은 따로 설계해야 한다.
Transaction, Idempotency, Saga, Compensation,
Transactional Outbox, Lock 같은 장치가 이때 쓰인다.

동기 API는 결과를 즉시 확인하기 좋은 방법이지,
여러 시스템의 강한 일관성을 자동으로 보장하는 기술이 아니다.

일관성 자체는 11장 「이벤트를 운영한다는 것」에서 자세히 다뤘다.

7. 이벤트는 언제 쓰는가

이벤트는 어떤 일이 이미 일어났다는 사실을 표현한다.
OrderCompleted, PaymentCompleted 같은 이름을 쓴다.

명령과 구분하는 것이 중요하다.

"포인트 100을 차감해라"   → Command
"포인트 100이 차감됐다"   → Event

이벤트를 쓰면 생산자와 소비자의 결합이 느슨해진다.

주문 완료 이벤트에 처음에는 알림과 정산만 붙어 있었다고 하자.
나중에 랭킹이 필요해져도
주문 서비스는 거의 바꾸지 않고 소비자만 추가하면 된다.

flowchart LR
    n0["OrderCompleted"]
    n1["알림"]
    n2["정산"]
    n3["랭킹 (나중에 추가)"]
    n0 --> n1
    n0 --> n2
    n0 -.-> n3

    style n3 fill:#f2fbf4,stroke:#4caf50,stroke-dasharray: 5 5,color:#1a1a1a

주문 서비스는 누가 그 이벤트를 쓰는지 몰라도 된다.
여러 시스템이 같은 변경 사실을 나눠 쓸 때 특히 유용하다.

이벤트 설계 자체는 10장 「이벤트로 연결하기」에서 다뤘다.
여기서는 API·배치와 견주어 언제 고를지만 본다.

8. 이벤트는 공짜가 아니다

장점이 큰 만큼 복잡성도 함께 온다.

이벤트 중복, 순서, 유실, 재처리, 스키마 변경,
Consumer 장애, 관측성, 최종적 일관성.
전부 새로 고민해야 할 문제다.

같은 이벤트가 두 번 올 수 있다면
Consumer는 두 번 처리해도 괜찮게 만들어야 한다.

그래서 이벤트를 많이 쓸수록 좋은 아키텍처가 된다고 생각하면 안 된다.

모든 것을 이벤트로 만들 필요도 없다.

10,000원짜리 상품 주문을 전부 비동기로 설계했다고 해보자.
그런데 사용자는 지금 당장 알고 싶다.

잔액이 충분한가?
포인트 차감이 성공했는가?
주문이 성공했는가?

이런 핵심 결과를 즉시 보여줘야 한다면
이벤트만으로 처리하는 쪽이 오히려 복잡해진다.

그래서 보통은 이렇게 나눈다.

flowchart LR
    n0["주문 요청"]
    n1["포인트 차감"]
    n2["주문 성공"]
    n3["OrderCompleted"]
    n4["알림"]
    n5["랭킹"]
    n6["통계"]
    n0 -- "동기 · 핵심 업무" --> n1
    n1 --> n2
    n2 -- "비동기 · 후속 업무" --> n3
    n3 --> n4
    n3 --> n5
    n3 --> n6

핵심 업무와 후속 업무를 가르는 것.
이것이 API와 이벤트를 조합하는 가장 흔한 형태다.

9. 배치는 여전히 좋은 선택이다

모든 데이터를 실시간으로 처리할 필요는 없다.

전날의 판매자별 실적을 계산한다고 해보자.

flowchart LR
    n0["운영 데이터"] -- "매일 새벽" --> n1["Batch"]
    n1 --> n2["일간 통계"]

몇 시간 늦게 나와도 문제가 없다면
복잡한 실시간 시스템을 만들 이유가 없다.

배치가 맞는 일은 이런 것들이다.

일간 통계
월간 정산
장기 리포트
대량 데이터 이동
ML 학습 데이터 생성
아카이빙

여기서 중요한 원칙이 하나 나온다.

실시간으로 만들 수 있다고 해서
반드시 실시간으로 만들어야 하는 것은 아니다.

실시간성을 높이면 비용, 운영 난이도, 장애 대응, 복잡성이 함께 올라간다.
그 값을 치를 이유가 있을 때만 치르면 된다.

10. 셋을 어떻게 고르는가

아주 단순화하면 이렇게 볼 수 있다.

조회 부하 자체가 문제라면
변경 모델과 조회 모델을 나누는 CQRS도 선택지다.
9장 「서비스 경계와 조회 모델」에서 다뤘다.

다만 이 표는 정답표가 아니다.

실제 결정에서는 지연시간, 정합성, 트래픽,
소비자 수, 장애 처리, 운영 비용을 함께 봐야 한다.

표는 어디서 생각을 시작할지 알려 줄 뿐이고,
어디서 멈출지는 그 시스템의 사정이 정한다.

11. 호출이 실패할 때: Circuit Breaker

방식을 골랐다고 끝이 아니다.
고른 방식에는 저마다 운영상의 비용이 따라온다.

동기 API의 경우 그중 하나가 장애 전파다.

서비스 A가 서비스 B를 부르고 있다고 하자.

B가 장애인데도 A가 계속 요청을 보내면
실패한 요청이 A 쪽에 쌓인다.
결국 B뿐 아니라 A까지 무너진다.

이를 막는 대표적인 패턴이 Circuit Breaker다.

stateDiagram-v2
    state "Half-Open" as HalfOpen
    Closed --> Open : 실패 증가
    Open --> HalfOpen : 일정 시간 경과
    HalfOpen --> Closed : 성공
    HalfOpen --> Open : 실패

전기 차단기와 같다.
문제가 생겼을 때 잠시 호출을 끊어
장애가 옆 시스템으로 번지는 것을 줄인다.

동기 API로 잇는다는 것은
상대의 장애를 그대로 넘겨받는다는 뜻이기도 하다.
연결 방식을 고를 때 함께 봐야 할 비용이다.

12. API Gateway는 어느 경계에 필요한가

서비스가 많아지면 외부 소비자가
각 서비스를 직접 찾아 부르기 어려워진다.

그래서 외부 클라이언트 앞에 API Gateway를 둔다.

flowchart LR
    n0["외부 Client"]
    n1["API Gateway"]
    n2["회원"]
    n3["결제"]
    n4["주문"]
    n5["배송"]
    n0 --> n1
    n1 --> n2
    n1 --> n3
    n1 --> n4
    n1 --> n5

여기서 인증, 인가, 라우팅, Rate Limit,
로깅, TLS 처리, 공통 보안 정책을 한곳에서 처리할 수 있다.

하지만 내부 서비스끼리의 통신까지
전부 Gateway를 거쳐야 하는 것은 아니다.

상황에 따라 직접 호출, Service Discovery,
Service Mesh, 메시징이 더 나을 수 있다.

그래서 질문은 이렇게 바꾸는 편이 낫다.

“API Gateway를 쓰는 것이 좋은가“가 아니라
“어떤 경계에 Gateway가 필요한가”

Circuit Breaker와 API Gateway는 서로 다른 장치지만
묻는 것은 같다.
이 연결을 어디서 끊고, 어디서 모을 것인가다.

13. 원칙에도 예외는 있다

지금까지 정리한 것은 기본값이지 법이 아니다.

아키텍처 규칙을 절대적인 법칙으로 만들면
현실 문제를 못 푸는 경우가 생긴다.

전체 처리 시간을 100ms 이하로 맞춰야 하는데
중간 계층 때문에 도저히 못 맞춘다고 하자.
그러면 특정 통신 방식에 예외를 둘 수 있다.

다만 예외에도 근거가 있어야 한다.

❌  "그냥 직접 접근하는 게 편해서"

✅  "명확한 성능 요구사항 때문에
     현재 표준 구조로는 SLA를 만족할 수 없다."

예외는 허용할 수 있지만
설명할 수 있는 이유가 있어야 한다.

그리고 하나의 예외가 모든 규칙을 없애지는 않는다.

API Gateway를 거치지 않는 예외를 허용했다고 해서
API 문서화, 보안, 스키마 관리, 데이터 품질, Owner까지
함께 사라지는 것은 아니다.

기술적인 구현 방법에는 예외가 있어도
데이터와 서비스에 대한 책임은 그대로 남는다.

14. 12장 정리

네 가지만 기억하면 된다.

API, 이벤트, 배치는 대체 관계가 아니다.
각각 푸는 문제가 다르다.
질문은 “무엇이 더 좋은가“가 아니라
“지금 문제에 무엇이 맞는가“다.

동기 API를 쓴다고 강한 일관성이 보장되지 않는다.
여러 시스템에 걸친 정합성은 따로 설계해야 한다.

실시간으로 만들 수 있다고 반드시 실시간일 필요는 없다.
실시간성을 높이면 비용과 운영 난이도도 함께 올라간다.

아키텍처 원칙에 예외는 있을 수 있다.
다만 “직접 접근하는 게 편해서“는 근거가 되지 않는다.
명확한 성능 요구처럼 설명할 수 있는 이유가 있어야 한다.

여기까지가 3부다.

경계를 넘는 방법은 정했다.
하지만 넘겨받은 데이터를 다른 팀이 실제로 쓰려면
그것만으로는 부족하다.

어디에 있는지, 무슨 뜻인지,
믿을 수 있는지, 누가 책임지는지를 알 수 있어야 한다.

4부에서는 데이터를 제품처럼 제공하는 방법을,
5부에서는 그 데이터를 믿을 수 있게 만드는 장치를 다룬다.

다음 장에서는 여러 팀이 반복해서 쓰는 데이터를
어떻게 제품처럼 제공할지 본다.

13장. 데이터 프로덕트

4부 · 제품 — 데이터를 어떻게 쓸 수 있게 하는가
13장 · 14장

데이터를 ‘저장’하는 데서 ‘제품처럼 제공’하는 단계로

데이터를 많이 가지고 있다고 해서
그 조직이 데이터를 잘 활용하는 것은 아니다.

중요한 것은 필요한 사람이 데이터를 쉽게 찾고,
그 의미를 이해하고, 신뢰하면서 사용할 수 있는가이다.

예를 들어 회사에 다음과 같은 테이블이 있다고 해보자.

order
point_usage
point_type
member
seller
product
payout_rate

주문 데이터를 분석하려는 사람에게
이 테이블들을 그대로 열어주면서 이렇게 말할 수도 있다.

필요한 테이블을 JOIN해서 사용하세요.

하지만 분석하는 사람은 곧 여러 질문에 부딪힌다.

어떤 주문 상태를 포함해야 하는가?

취소된 주문은 제외하는가?

테스트 계정은 어떻게 구분하는가?

point_amount의 단위는 무엇인가?

출금 환산율은 현재 값을 사용하는가,
주문 당시 값을 사용하는가?

어느 테이블이 가장 신뢰할 수 있는 원본인가?

데이터는 존재하지만
실제로 사용하기는 쉽지 않은 상태다.

데이터 프로덕트(Data Product) 는
이 문제를 해결하기 위한 사고방식이다.

1. 데이터 프로덕트란 무엇인가

데이터 프로덕트를 가장 쉽게 설명하면 다음과 같다.

다른 사람이 반복적으로 신뢰하여 사용할 수 있도록
데이터와 그 데이터에 필요한 설명·품질·접근 방법 등을
하나의 제품처럼 관리하는 것

여기서 중요한 점은
데이터 프로덕트가 단순한 DB 테이블이나 파일 하나를 의미하지 않는다는 것이다.

보통 다음과 같은 요소가 함께 관리된다.

데이터

+ 데이터의 의미
+ 스키마
+ 메타데이터
+ 품질 정보
+ 소유자
+ 갱신 주기
+ 접근 방법
+ 보안 정책
+ 버전 및 변경 정보

예를 들어 다음과 같은 데이터 프로덕트를 생각할 수 있다.

이름
Seller Daily Sales

설명
판매자별 일일 판매 실적을 제공한다.

주요 데이터
seller_id
date
total_amount
buyer_count

갱신 주기
5분

소유 도메인
주문 도메인

품질 목표
최근 10분 이내 데이터 유지

제공 방법
SQL / API / File

이 정도 정보가 갖춰지면
다른 팀은 주문 시스템의 내부 구현을 전부 공부하지 않아도 데이터를 사용할 수 있다.

2. 데이터 프로덕트의 정의는 하나로 고정되어 있지 않다

데이터 프로덕트라는 용어는
조직과 방법론에 따라 범위가 조금씩 다르다.

어떤 조직은 다음 정도로 본다.

데이터셋
+
메타데이터
+
품질 기준
+
접근 방법

반면 Data Mesh처럼 비교적 넓은 관점에서는

데이터
+
메타데이터
+
변환 코드
+
정책
+
인터페이스
+
필요한 인프라 구성

까지 하나의 독립적인 데이터 제품으로 볼 수 있다.

따라서 중요한 것은

우리 조직에서 무엇을 데이터 프로덕트라고 부를 것인지
먼저 정의하는 것

이다.

이 장에서는 데이터뿐 아니라
그 데이터를 이해하고 안정적으로 소비하는 데 필요한 요소까지 포함하는
비교적 넓은 관점으로 설명한다.

3. Data Product와 Data Mesh는 같은 것이 아니다

둘은 자주 함께 등장하지만 동일한 개념은 아니다.

Data Product는
데이터를 제품처럼 관리하는 개념이다.

반면 Data Mesh는
대규모 조직에서 데이터를 분산하여 소유하고 운영하는 하나의 아키텍처·조직 운영 방식이다.

Data Mesh가 중요하게 보는 네 가지 원칙은 3장에서 다뤘다.

즉 관계를 단순화하면 다음과 같다.

flowchart LR
    dm["Data Mesh"] -- "핵심 구성 개념으로 사용" --> dp["Data Product"]

따라서 데이터 프로덕트를 만들기 위해
반드시 Data Mesh를 도입해야 하는 것은 아니다.

작은 조직에서도 데이터 프로덕트 개념만 따로 사용할 수 있다.

4. 왜 데이터 프로덕트가 필요한가

전통적인 데이터 조직에서는
중앙 데이터팀이 많은 요청을 처리한다.

flowchart LR
    subgraph TEAMS["비즈니스 조직"]
        P["기획팀"]
        M["마케팅팀"]
        F["재무팀"]
        O["운영팀"]
    end

    DATA["중앙 데이터팀<br/>SQL 작성 · 데이터 가공"]
    RESULT["결과 전달"]

    P --> DATA
    M --> DATA
    F --> DATA
    O --> DATA

    DATA --> RESULT

    style TEAMS fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style DATA fill:#fff0f0,stroke:#d9534f,stroke-width:3px,color:#1a1a1a

조직이 작다면 충분히 동작할 수 있다.

하지만 조직과 데이터가 커질수록
중앙 데이터팀이 모든 도메인의 비즈니스 규칙을 이해하기 어려워진다.

요청도 계속 증가한다.

그러면 데이터팀 자체가 병목이 될 수 있다.

데이터 프로덕트 관점에서는 생각을 바꾼다.

flowchart LR
    d["주문 도메인"] --> dp["주문 데이터 프로덕트"]
    dp --> a["분석"]
    dp --> b["정산"]
    dp --> c["랭킹"]
    dp --> e["운영"]

데이터를 만드는 도메인이
다른 사람이 사용할 수 있는 형태로 제공하는 것이다.

5. 데이터를 제품처럼 생각한다

API를 제품처럼 제공한다고 생각해보자.

코드만 작성했다고 끝나지 않는다.

API
+
문서
+
사용 방법
+
버전
+
보안
+
모니터링
+
장애 대응

등이 필요하다.

데이터도 마찬가지다.

다음과 같은 방식은 좋은 데이터 프로덕트라고 보기 어렵다.

테이블 열어놨습니다.

필요하면 알아서 사용하세요.

이 경우 소비자가 직접 알아내야 하는 것이 너무 많다.

어떤 테이블을 써야 하는가?

컬럼의 의미는 무엇인가?

어떤 JOIN이 필요한가?

어떤 데이터를 제외해야 하는가?

언제 갱신되는가?

누가 관리하는가?

숫자가 틀리면 누구에게 문의해야 하는가?

좋은 데이터 프로덕트는
이 지식을 데이터와 함께 제공한다.

6. 메타데이터

데이터 프로덕트에서 매우 중요한 것이
메타데이터(Metadata) 다.

메타데이터란

데이터를 설명하는 데이터

다.

다음 값이 있다고 해보자.

point_amount = 1000

이 숫자만으로는 의미를 알기 어렵다.

충전한 포인트인가?

사용한 포인트인가?

주문한 포인트인가?

남은 포인트인가?

출금 대상 포인트인가?

따라서 다음과 같은 설명이 필요하다.

point_amount

의미
주문이 완료된 포인트 수량

단위
개

NULL
허용하지 않음

취소 데이터
포함하지 않음

이런 정보가 메타데이터다.

7. 논리적인 제품과 물리적인 구현은 다르다

데이터 프로덕트를 특정 DB 하나라고 생각하면 안 된다.

논리적으로는 Order Data Product 하나지만
실제 구현은 여러 형태일 수 있다.

flowchart LR
    DP["Order Data Product<br/>논리적 정의"]

    DP --> n1["MariaDB"]
    DP --> n2["Data Warehouse"]
    DP --> n3["S3 Parquet"]
    DP --> n4["Kafka Topic"]
    DP --> n5["API"]

    style DP fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a

소비자는 이 저장 기술들을 알 필요가 없다.

소비자에게 중요한 것은 이것뿐이다.

어떤 주문 데이터를
어떤 품질로
어떤 방식으로 쓸 수 있는가

메타데이터는 논리 쪽에 붙인다

이 구분은 메타데이터를 관리할 때 특히 중요해진다.

같은 데이터가 MariaDB, 웨어하우스, S3에 복제되어 있다고 하자.

복제본마다 의미와 Owner와 품질 기준을 따로 적어 두면
하나를 고칠 때 세 곳을 모두 고쳐야 한다.

그래서 메타데이터는 논리적 정의에 한 번만 붙인다.

flowchart LR
    META["Metadata<br/>의미 · Owner · 품질 기준"]
    DP2["Order Data Product<br/>논리적 정의"]

    subgraph PHYS["물리적 저장 위치"]
        DB[("MariaDB")]
        S3[("S3")]
        WH[("Data Warehouse")]
    end

    META -- "한 번만 정의한다" --> DP2
    DP2 --> DB
    DP2 --> S3
    DP2 --> WH

    style DP2 fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a
    style PHYS fill:#fafafa,stroke:#bbb,color:#1a1a1a

정리하면 이렇게 나눌 수 있다.

8. CQRS는 데이터 프로덕트의 필수 조건이 아니다

데이터 프로덕트를 설명할 때
CQRS가 자주 등장한다.

CQRS는

Command Query Responsibility Segregation

의 약자로,

데이터를 변경하는 모델과
데이터를 조회하는 모델의 책임을 분리하는 것

을 의미한다.

하지만 중요한 점이 있다.

모든 데이터 프로덕트에 CQRS가 필요한 것은 아니다.

운영 시스템의 쓰기 구조와
데이터 소비자의 조회 구조가 크게 다를 때
CQRS의 사고방식이 유용한 것이다.

CQRS 자체는 9장 「서비스 경계와 조회 모델」에서 다뤘다.

9. 운영 모델과 조회 모델

운영 시스템에서는 다음이 중요하다.

트랜잭션
정합성
빠른 INSERT / UPDATE
동시성 처리

예를 들어 주문 시스템에는 이런 테이블이 있을 수 있다.

order
point_usage
point_balance
order_item

하지만 분석 소비자가 원하는 것은 다를 수 있다.

판매자별 일일 주문 금액
회원별 월간 주문 금액
시간대별 주문 통계

그래서 별도의 조회 모델을 만들 수 있다.

seller_daily_sales

seller_id
date
total_amount
buyer_count

구조는 다음과 같다.

flowchart LR
    n0["운영 시스템"]
    n1["원천 데이터"]
    n2["가공"]
    n3["읽기 모델"]
    n4["데이터 소비자"]
    n0 -- "쓰기 모델" --> n1
    n1 --> n2
    n2 --> n3
    n3 --> n4

이렇게 하면 소비자는
운영 DB의 복잡한 구조를 알 필요가 없다.

10. 읽기에 최적화한다

데이터 프로덕트는 소비 목적에 따라
읽기 편한 형태로 구성할 수 있다.

운영 DB에서는 정규화가 유리할 수 있다.

orders
order_items
products
customers
stores

하지만 분석할 때 매번 이 테이블을 JOIN해야 한다면 불편하다.

그래서 다음처럼 가공할 수 있다.

sales_analysis

date
customer_id
product_name
store_name
quantity
amount

즉 비정규화 자체가 나쁜 것이 아니다.

중요한 것은

• 운영 시스템 — 쓰기와 정합성 중심
• 데이터 프로덕트 — 소비와 조회 중심

처럼 목적에 맞게 설계하는 것이다.

11. 스타 스키마

조회 중심으로 설계한다고 했는데,
그럼 구체적으로 어떤 모양인가.

분석용 데이터 프로덕트에서 가장 많이 쓰이는 모양이
Star Schema다.

왜 이런 모양이 나왔나

분석에서 나오는 질문은 끝이 없다.

이번 달 주문 금액은 얼마인가?
판매자별로는?
상품 카테고리별로는?
판매자별 × 월별로는?

질문이 나올 때마다 테이블을 새로 만들 수는 없다.

그래서 질문을 두 조각으로 쪼갠다.

• 무엇을 재는가 — 주문 금액, 주문 수량
• 어떤 기준으로 나눠 보는가 — 판매자별, 월별, 상품별

재는 값은 가운데 테이블 하나에 모으고,
나눠 보는 기준은 각각 별도 테이블로 뺀다.

앞엣것을 Fact, 뒤엣것을 Dimension이라고 부른다.

구조

flowchart TD
    DU["dim_user<br/>──────────<br/>user_id<br/>가입일 · 등급"]
    DS["dim_seller<br/>──────────<br/>seller_id<br/>판매자명 · 등급"]
    DP["dim_product<br/>──────────<br/>product_id<br/>상품명 · 카테고리"]
    DD["dim_date<br/>──────────<br/>date_id<br/>날짜 · 월 · 분기"]

    F["fact_order<br/>──────────<br/>user_id · seller_id · product_id · date_id<br/><br/>주문 수량 · 주문 금액"]

    DU --> F
    DS --> F
    DP --> F
    DD --> F

    style F fill:#e8f4ff,stroke:#4a90e2,stroke-width:3px,color:#1a1a1a
    style DU fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style DS fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style DP fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style DD fill:#fafafa,stroke:#bbb,color:#1a1a1a

fact_order에는 숫자와 연결 키만 들어간다.
행 하나가 주문 하나다. 수천만 건이 쌓인다.

dim_*에는 그 키가 무엇인지 설명하는 값이 들어간다.
판매자 수만큼, 상품 수만큼만 있으므로 훨씬 작다.

예를 들어 fact_order에는 seller_id = 37만 있고,
그 판매자의 이름과 등급과 가입일은 dim_seller에 있다.

가운데 Fact 하나를 Dimension들이 둘러싸는 모양이라
별(Star) 스키마라고 부른다.

그래서 무엇이 좋아지나

질문이 바뀌어도 테이블 구조는 그대로다.
어떤 Dimension을 붙이느냐만 달라진다.

-- 판매자별 × 월별 주문 금액
SELECT s.seller_name, d.month, SUM(f.order_amount)
FROM fact_order f
JOIN dim_seller s ON f.seller_id = s.seller_id
JOIN dim_date   d ON f.date_id   = d.date_id
GROUP BY s.seller_name, d.month;

상품 카테고리별로 보고 싶으면
dim_seller를 dim_product로 바꾸기만 하면 된다.

새로운 분석 기준이 필요하면
Dimension 테이블을 하나 더 붙인다.
fact_order는 건드리지 않는다.

판매자 이름이 바뀌어도 dim_seller 한 행만 고치면 된다.
앞 절에서 본 넓은 테이블이었다면
수천만 행을 전부 고쳐야 했을 것이다.

언제 쓰나

집계와 조합이 많은 환경에서 유용하다.
월별·상품별·판매자별처럼 기준이 계속 바뀌는 분석이 대표적이다.

다만 모든 데이터 프로덕트가 이 모양일 필요는 없다.
기준 조합이 거의 고정되어 있고 조회가 단순하다면
앞 절처럼 넓은 테이블 하나로 충분할 때도 많다.

12. Data Vault

스타 스키마에도 약점이 있다.

원천 시스템이 바뀌면 흔들린다는 점이다.

주문에 새 속성이 생기거나, 판매자 등급 체계가 바뀌거나,
시스템 하나가 통째로 교체되면
Fact와 Dimension을 다시 설계해야 하는 일이 생긴다.

“작년 3월 시점에 이 판매자의 등급은 무엇이었나“처럼
과거 시점을 되짚는 질문에도 약하다.

이런 문제를 다루려고 나온 모델링 방법이 Data Vault다.

세 가지로 나누는 이유

핵심 발상은 하나다.

변하는 것과 변하지 않는 것을 섞지 않는다.

그래서 테이블을 세 종류로 나눈다.

flowchart LR
    HU["hub_user<br/>──────────<br/>user_id<br/>변하지 않는 키"]
    HO["hub_order<br/>──────────<br/>order_id<br/>변하지 않는 키"]

    LNK["link_user_order<br/>──────────<br/>user_id · order_id<br/>관계"]

    SU["sat_user<br/>──────────<br/>주소 · 등급<br/>+ 변경 시각<br/>변하는 것"]
    SO["sat_order<br/>──────────<br/>금액 · 상태<br/>+ 변경 시각<br/>변하는 것"]

    HU --> LNK
    HO --> LNK
    HU --> SU
    HO --> SO

    style HU fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a
    style HO fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a
    style LNK fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style SU fill:#f2fbf4,stroke:#4caf50,color:#1a1a1a
    style SO fill:#f2fbf4,stroke:#4caf50,color:#1a1a1a

무엇이 좋아지나

바뀔 때 고치지 않고 붙인다.

주문에 새 속성이 생기면 Satellite를 하나 더 만든다.
기존 Hub와 Link와 Satellite는 그대로 둔다.

새로운 원천 시스템이 들어와도
같은 Hub에 Satellite를 하나 더 붙이면 된다.

그리고 Satellite에는 값과 함께 변경 시각이 쌓인다.
덮어쓰지 않으므로 과거 어느 시점의 상태든 되짚을 수 있다.
감사 추적이 필요한 영역에서 특히 쓸모가 있다.

스타 스키마와 무엇이 다른가

둘 중 하나를 고르는 문제가 아니다.
푸는 문제가 다르고, 실제로는 함께 쓰는 경우가 많다.

flowchart LR
    SRC["원천 시스템"]
    DV["Data Vault<br/>──────────<br/>통합 · 이력 보존"]
    STAR["Star Schema<br/>──────────<br/>분석 · 집계"]
    USER["분석가 · BI"]

    SRC --> DV --> STAR --> USER

    style DV fill:#e8f4ff,stroke:#4a90e2,color:#1a1a1a
    style STAR fill:#f2fbf4,stroke:#4caf50,color:#1a1a1a

안쪽에 Data Vault로 원본과 이력을 쌓아 두고,
바깥쪽에 Star Schema로 분석용 모델을 만들어 내놓는 식이다.

지금 당장 필요한가

대부분은 아니다.

Data Vault는 원천 시스템이 여럿이고, 자주 바뀌고,
이력과 감사 추적이 중요할 때 값을 한다.
그렇지 않다면 관리할 테이블만 몇 배로 늘어난다.

지금은 변하는 것과 변하지 않는 것을 섞지 않는다는
발상만 기억해 두면 충분하다.
이 생각 자체는 Data Vault를 쓰지 않아도 쓸모가 있다.

13. 유비쿼터스 언어는 ‘전사 공통 언어’와 조금 다르다

5장에서 본 유비쿼터스 언어를
데이터 관점에서 다시 보자.

흔한 오해는 이것이다.

회사 전체에서
모든 단어의 의미를 하나로 통일한다.

서로 다른 Bounded Context라면
같은 단어가 서로 다른 의미를 가질 수도 있다.

커머스 Context의 회원

배송 Context의 회원

정산 Context의 회원

이 반드시 동일한 모델일 필요는 없다.

데이터 프로덕트를 만들 때 중요한 것은 다음이다.

• Context 내부 — 언어와 의미를 일관되게 유지
• Context 사이 — 데이터 계약과 매핑을 명확하게 정의

14. 의미적 일관성

같은 데이터 프로덕트나 같은 Context 안에서
같은 이름은 같은 의미를 가져야 한다.

다음과 같은 컬럼은 좋지 않을 수 있다.

amount

왜냐하면 이것이 무엇을 의미하는지 불분명하기 때문이다.

결제 금액인가?

주문 포인트 수인가?

출금 금액인가?

수수료인가?

차라리 다음처럼 의미를 명확히 드러내는 편이 좋다.

payment_amount
point_amount
payout_amount
fee_amount

15. NULL, 기본값, 데이터 타입

데이터 값이 없는 경우에도
그 의미를 명확하게 정의해야 한다.

예를 들어:

birthday = NULL

이 값이 의미하는 것이 무엇인가?

사용자가 입력하지 않음

정보를 알 수 없음

수집 실패

해당 없음

여러 해석이 가능하다.

따라서 데이터 계약에서 의미를 정해야 한다.

데이터 타입도 마찬가지다.

회원 시스템
user_id BIGINT

결제 시스템
user_id VARCHAR

분석 시스템
user_id INT

처럼 제각각이면 계속 변환이 필요해진다.

가능한 범위에서 공통 타입 규칙을 갖는 것이 좋다.

16. 속성의 원자성

하나의 필드에는
가능하면 하나의 의미를 담는다.

좋지 않은 예:

user_info =
"홍길동/010-1234-5678/부산"

더 나은 형태:

user_name
phone_number
address

원자성을 유지하면

검색
필터링
JOIN
검증
마스킹

이 훨씬 쉬워진다.

17. 원천 데이터를 무조건 직접 읽어야 하는 것은 아니다

데이터 계보를 단순하게 유지하려면
권위 있는 원천 데이터를 사용하는 것이 좋다.

하지만

모든 데이터 프로덕트가 반드시 운영 원천 DB를 직접 읽어야 한다

는 뜻은 아니다.

다음 구조도 충분히 가능하다.

flowchart LR
    n0["운영 시스템"] --> n1["Source-aligned Data Product"] --> n2["Consumer-oriented Data Product"]

예를 들어 주문 도메인이
신뢰할 수 있는 Order Data Product를 제공한다면,

정산 데이터 프로덕트가 운영 DB를 다시 직접 읽지 않고
이 데이터 프로덕트를 입력으로 사용할 수도 있다.

중요한 원칙은 다음과 같다.

불필요한 중간 의존성을 만들지 말고,
권위 있는 원천 또는 신뢰할 수 있는 상위 데이터 프로덕트를 사용한다.

18. Data Lineage

데이터가 어디에서 왔고
어떤 과정을 거쳤는지 추적하는 것을

Data Lineage라고 한다.

예:

flowchart LR
    n0["order"] --> n1["취소 주문 제외"] --> n2["테스트 계정 제외"] --> n3["판매자별 집계"] --> n4["seller_daily_sales"]

최종 숫자가 이상할 경우

원천 데이터 문제인가?

수집 과정에서 누락됐는가?

필터 조건이 잘못됐는가?

집계 로직이 잘못됐는가?

를 역으로 추적할 수 있다.

19. 13장 정리

세 가지만 기억하면 된다.

데이터 프로덕트는 테이블이나 파일 하나가 아니다.
데이터에 의미·스키마·품질 기준·소유자·갱신 주기·접근 방법이
함께 붙어 있어야 한다.

논리적인 제품과 물리적인 구현을 분리한다.
하나의 데이터 프로덕트가
DB, 웨어하우스, 객체 스토리지, 스트림, API로
동시에 제공될 수 있다.
소비자는 그 전부를 알 필요가 없다.

소비 목적에 맞는 읽기 모델을 따로 두면 도움이 된다.
운영 시스템은 쓰기와 정합성이 중심이고
데이터 프로덕트는 조회가 중심이기 때문이다.

다음 장에서는 이렇게 만든 데이터 프로덕트를
어떻게 믿을 수 있게 만드는지 본다.

14장. 데이터 프로덕트를 신뢰할 수 있게 만들기

4부 · 제품 — 데이터를 어떻게 쓸 수 있게 하는가
13장 · 14장

분석팀에 데이터를 열어 줬다.

돌아온 첫 질문은 기능에 대한 것이 아니었다.

“이 숫자 믿어도 되나요?”

13장에서 데이터 프로덕트가 무엇인지 봤다.

만드는 것과 믿게 만드는 것은 다른 문제다.

이 장에서는 신뢰를 만드는 요소를 다룬다.

품질과 테스트, 이력 관리, 수집과 제공 방식,
보안, 그리고 이것들을 떠받치는 플랫폼이다.

1. 데이터 품질

데이터 프로덕트는
데이터가 존재하는 것만 책임지는 것이 아니다.

신뢰할 수 있는 상태인지도 관리해야 한다.

대표적인 품질 기준은 다음과 같다.

예를 들어 주문 데이터에는 다음 규칙을 적용할 수 있다.

order_id 중복 금지

seller_id NULL 금지

point_amount > 0

created_at이 미래 시간이면 오류

2. 데이터에도 테스트가 필요하다

소프트웨어에는 테스트가 있다.

Unit Test
Integration Test

데이터 파이프라인도 테스트할 수 있다.

Schema Test

NULL Test

Unique Test

Range Test

Freshness Test

Reconciliation

예를 들어 다음처럼 구성한다.

flowchart LR
    n0["데이터 수집"] --> n1["스키마 검사"] --> n2["NULL 검사"] --> n3["중복 검사"] --> n4["품질 검사"] --> n5["저장 / 공개"]

문제가 발생하면

배포 중단
알림
격리
재처리

같은 정책을 적용할 수 있다.

3. 데이터 대사

Reconciliation은
원천과 결과가 맞는지 비교하는 것이다.

예를 들어:

운영 DB
어제 주문 1,000,000건

그런데 데이터 프로덕트에는

999,950건

만 존재한다고 하자.

50건이 누락된 이유를 찾아야 한다.

건수뿐 아니라 금액도 비교할 수 있다.

원천 SUM(point_amount)

vs

데이터 프로덕트 SUM(point_amount)

이런 비교를 자동화하면
데이터 파이프라인의 신뢰성을 높일 수 있다.

4. 데이터의 불변성은 상황에 따라 적용한다

데이터 프로덕트에서는
과거 사실이 임의로 바뀌지 않도록 하는 것이 중요하다.

하지만

모든 데이터를 절대로 수정하면 안 된다

라고 이해하면 안 된다.

예를 들어 거래 원장, 감사 로그, 이벤트 로그처럼
과거 사실의 재현이 중요한 데이터는

Append-only
Versioning
History

방식이 적합하다.

반면 현재 상태만 중요한 데이터는
기존 값을 갱신하는 것도 가능하다.

즉,

• 감사 / 이력 중요 — 불변성 적극 활용
• 현재 상태 중요 — 갱신 가능

처럼 데이터 특성에 따라 결정한다.

5. 이력 관리 방식

대표적인 이력 관리 방식을 살펴보자.

SCD Type 1

현재값만 중요하다면
기존 값을 덮어쓴다.

기존

grade = A

변경

grade = B

과거 등급이 A였던 사실은 남지 않는다.

SCD Type 2

과거 상태까지 보관해야 한다면
새로운 행을 만든다.

이렇게 하면 특정 시점의 상태를 조회할 수 있다.

SCD는 원래 Dimension 속성의 변화 이력을 관리하기 위한 기법이다.

모든 종류의 이력을 반드시 SCD로 관리하는 것은 아니다.

6. Snapshot

특정 시점의 전체 상태를 저장할 수도 있다.

2026-09-14 Snapshot

2026-09-15 Snapshot

2026-09-16 Snapshot

장점은 특정 시점 상태를 복원하기 쉽다는 것이다.

하지만 바뀌지 않은 데이터도 계속 저장하므로
저장량이 커질 수 있다.

7. Append-only

기존 데이터를 수정하지 않고
새로운 사실을 계속 추가하는 방식이다.

예를 들어:

OrderCreated

OrderCancelled

OrderRefunded

처럼 이벤트를 기록한다.

모든 변경 사실을 추적해야 하는 경우 유용하다.

8. CDC

Change Data Capture는
DB에서 발생한 변경을 감지하는 방식이다.

flowchart LR
    n0["OLTP Database"] --> n1["CDC"] --> n2["Change Stream"]

INSERT, UPDATE, DELETE 등의 변경을 감지하여
다른 데이터 시스템으로 전달할 수 있다.

실시간 데이터 파이프라인에서 많이 활용된다.

9. 이력 방식에는 하나의 정답이 없다

데이터의 성격에 따라 조합한다.

하나의 시스템에서도
여러 방식을 함께 사용할 수 있다.

10. Raw Data는 필요 없다는 뜻이 아니다

좋은 데이터 프로덕트는

DB Dump 있으니 알아서 사용하세요.

라고 하지 않는다.

하지만 Raw Data 자체가 쓸모없다는 뜻은 아니다.

Raw 데이터는 다음과 같은 상황에서 매우 중요하다.

재처리

장애 복구

감사

새로운 변환 로직 적용

과거 데이터 재계산

따라서 올바른 이해는 다음과 같다.

Raw Data만 제공하면서 소비자용 데이터 프로덕트라고 해서는 안 된다.

Raw는 내부 처리 계층으로 충분히 가치가 있다.

11. 데이터 수집 방식

데이터를 가져오는 방법에도
하나의 정답은 없다.

대표적으로 다음과 같은 방식이 있다.

Batch

정해진 시간마다 가져온다.

1시간마다

매일

매주

실시간성이 높지 않은 데이터에 적합하다.

Event / Streaming

데이터가 발생할 때 전달한다.

flowchart LR
    n0["주문 완료"] --> n1["OrderCompleted"] --> n2["Kafka"]

실시간 랭킹이나 모니터링 같은 기능에 적합하다.

API

외부 서비스나 SaaS에서
API를 통해 데이터를 가져올 수도 있다.

외부 서비스
    ↑
 REST API
    ↑
Data Pipeline

실제 환경에서는
Batch, Event, API를 혼합하는 경우가 많다.

12. Bronze / Silver / Gold

데이터 처리 구조에서 자주 등장하는 패턴이
Medallion Architecture다.

대표적으로 다음 단계로 나눈다.

flowchart LR
    n0["Bronze"] --> n1["Silver"] --> n2["Gold"]

Bronze는 원천에 가까운 데이터다.

Raw Data

Silver는 정제된 데이터다.

중복 제거
타입 정리
NULL 처리
표준화

Gold는 비즈니스 소비에 적합한 데이터다.

판매자 일별 주문 집계
월별 매출
정산 데이터

예를 들어:

flowchart LR
    n0["MariaDB order"] --> n1["Bronze"] --> n2["정제"] --> n3["Silver"] --> n4["판매자별 집계"] --> n5["Gold"] --> n6["Order Data Product"]

다만 중요한 점이 있다.

Bronze/Silver/Gold는 널리 사용되는 구현 패턴 중 하나이지
데이터 프로덕트나 Data Mesh의 필수 구조는 아니다.

13. 데이터 제공 방식

소비자가 필요한 방식도 다양하다.

SQL
API
File
Event
Streaming
Dashboard
Cache
Replica

예를 들면:

데이터 프로덕트는
소비자의 요구에 적합한 출력 인터페이스를 제공해야 한다.

14. Input Port와 Output Port

데이터 프로덕트를 하나의 서비스처럼 생각하면
입력과 출력을 구분할 수 있다.

flowchart LR
    n0["Source"] --> n1["Input Port"] --> n2["Data Product"] --> n3["Output Port"] --> n4["Consumer"]

Input Port는 데이터를 받아들이는 계약이고,

Output Port는 소비자가 데이터를 사용하는 계약이다.

이렇게 내부 구현과 외부 계약을 분리하면
데이터 저장 기술이 바뀌어도 소비자 영향을 줄이기 쉽다.

15. 데이터 보안

데이터 프로덕트에는
보안도 포함되어야 한다.

대표적인 방식으로 다음이 있다.

Row Level Security
특정 행만 조회

Column Level Security
특정 컬럼 조회 제한

Masking
민감 데이터 일부 숨김

Metadata Tag
PII, Financial 등의 태그 기반 정책

예를 들어 판매자 A에게는

seller_id = A

인 행만 보이게 할 수 있다.

분석팀에는

phone_number
email

같은 개인 식별 정보가 보이지 않도록 할 수 있다.

16. 도메인이 데이터 의미를 책임진다

데이터를 가장 잘 이해하는 것은
대개 데이터를 만드는 도메인이다.

중앙 데이터팀이
모든 비즈니스 규칙을 완벽하게 이해하는 것은 현실적으로 어렵다.

따라서 도메인이

데이터 의미

품질 기준

변경 규칙

소유권

을 책임지는 방향이 도움이 된다.

17. 새로운 데이터에는 새로운 소유권이 생길 수 있다

원천 데이터를 가공하면
새로운 비즈니스 의미가 만들어질 수 있다.

예를 들어:

flowchart TD
    n0["주문 데이터"]
    n2["출금 정책"]
    n4["수수료 정책"]
    n6["정산 규칙"]
    n7["판매자 예상 정산금"]
    n0 --> n7
    n2 --> n7
    n4 --> n7
    n6 --> n7

판매자 예상 정산금은
단순한 주문 데이터가 아니다.

새로운 규칙이 적용된 새로운 데이터다.

따라서

원천 데이터 소유자
≠
가공 데이터 소유자

일 수 있다.

데이터 프로덕트마다
최종 책임자를 명확하게 하는 것이 중요하다.

18. Single Source of Truth는 단순히 ‘숫자 하나’라는 뜻이 아니다

이 표현은 1장에서 다뤘다.
여기서는 데이터 프로덕트 관점에서 한 걸음 더 들어가 본다.

다음과 같은 상황이 있다고 하자.

숫자가 다르다고 해서
무조건 하나만 맞는 것은 아니다.

예를 들어 각각 다음을 의미할 수 있다.

PG 승인 금액

회계 인식 매출

환불 제외 순매출

모두 올바른 데이터일 수 있다.

따라서 중요한 것은

비즈니스 사실별로 어떤 정의를 사용하며
어떤 데이터가 그 정의의 권위 있는 출처인지 명확하게 하는 것

이다.

무조건 회사 전체에 숫자 하나만 존재하게 만드는 것이 목적은 아니다.

19. 하지만 도메인마다 마음대로 만들면 안 된다

앞의 세 절은 도메인이 데이터의 의미를 책임진다는 이야기였다.

그렇다고 분산 소유권이

각 팀이 원하는 기술을
아무 규칙 없이 선택한다.

는 뜻은 아니다.

그렇게 하면 다음 문제가 생긴다.

ID 규칙 불일치

스키마 불일치

보안 수준 불일치

중복 인프라

높은 운영비

통합 어려움

그래서 조직 전체의 최소한의 공통 규칙이 필요하다.

20. Federated Governance

앞 절의 균형 — 공통 규칙은 필요한데 중앙이 다 정할 수는 없다 —
이것을 다루는 방식이 Federated Governance다.

핵심은 하나다.

무엇을 전사가 정하고
무엇을 도메인이 정하는지를 나눈다.

왼쪽은 최소한이어야 한다.
목록이 길어질수록 중앙집중으로 되돌아간다.

Federated는 연방이라는 뜻이다.
주(州)가 자기 법을 갖되 연방 헌법은 함께 지키는 구조를 떠올리면 된다.

거버넌스 조직과 역할은 16장 「거버넌스」에서 자세히 다룬다.

21. Self-Service Data Platform

앞 절이 무엇을 지킬지를 정했다면
이 절은 어떻게 지키게 할지의 문제다.

규칙은 정해 놓아도 지키기 어려우면 지켜지지 않는다.

도메인마다 다음을 각자 직접 만든다고 해보자.

수집 시스템
Kafka
ETL
Scheduler
Catalog
Security
Monitoring
CI/CD

팀이 다섯이면 다섯 벌이 생긴다.

비용도 문제지만 더 큰 문제가 있다.
팀마다 보안 설정과 카탈로그 등록 방식이 달라진다.
앞 절에서 정한 규칙이 실제로는 지켜지지 않는다.

그래서 공통 플랫폼이 이 기능들을 셀프서비스로 제공한다.

flowchart LR
    subgraph PLAT["Data Platform"]
        P1["수집 · 저장 · 변환"]
        P2["카탈로그 · 접근 통제"]
        P3["품질 검사 · 배포"]
    end

    PLAT --> M["회원 Data Product"]
    PLAT --> C["결제 Data Product"]
    PLAT --> O["주문 Data Product"]

    style PLAT fill:#f8fbff,stroke:#4a90e2,color:#1a1a1a

여기서 중요한 것은 플랫폼이 규칙을 대신 지켜 준다는 점이다.

플랫폼으로 데이터 프로덕트를 만들면
카탈로그 등록과 접근 통제와 품질 검사가 기본으로 딸려 온다.
애써 지키지 않아도 지켜진다.

이것을 가드레일이라고 부른다.
10장 「이벤트로 연결하기」에서 본 것과 같은 생각이다.

역할은 이렇게 갈린다.

플랫폼팀이 데이터의 의미까지 책임지기 시작하면
다시 중앙 데이터팀 병목으로 돌아간다.

22. 데이터를 찾을 수 있게 만든다

데이터 프로덕트가 많아지면
어떤 데이터가 있는지 찾는 것 자체가 어려워진다.

그래서 Data Catalog를 사용한다.

카탈로그에서는 보통 다음을 찾을 수 있다.

데이터 이름

설명

Owner

Schema

갱신 주기

품질 상태

보안 등급

접근 방법

Lineage

쉽게 말하면

조직 내부 데이터를 위한 검색 엔진

이라고 생각할 수 있다.

좋은 데이터 환경에서는
사용자가 데이터팀에 매번 물어볼 필요가 없다.

기존:

“판매자별 주문 데이터 어디 있나요?”

셀프서비스:

flowchart LR
    n0["Data Catalog 검색"] --> n1["Seller Daily Sales 발견"] --> n2["설명 / 품질 확인"] --> n3["권한 요청"] --> n4["사용"]

이것을 Self-Service Discovery라고 부른다.

앞 절의 플랫폼이 만들기를 셀프서비스로 만든다면,
카탈로그는 찾기를 셀프서비스로 만든다.

카탈로그와 메타데이터는 15장 「메타데이터와 데이터 지도」에서 자세히 다룬다.

23. 데이터 변환도 코드처럼 관리한다

데이터 변환 로직도
애플리케이션 코드처럼 관리할 수 있다.

예:

flowchart LR
    n0["SQL / dbt"] --> n1["Git"] --> n2["Test"] --> n3["CI/CD"] --> n4["Deploy"]

변경할 때 다음을 자동으로 검사할 수도 있다.

Schema Compatibility

Data Quality

Metadata

Dependency

Test

이렇게 하면 데이터 구조 변경으로
소비자 시스템이 갑자기 깨지는 위험을 줄일 수 있다.

24. 데이터 복제는 성능과 독립성을 얻는 대신 관리 비용을 만든다

모든 소비자가
원본 데이터 프로덕트를 직접 사용할 필요는 없다.

예를 들어:

flowchart LR
    n0["Order Data Product"] --> n1["Consumer Replica"] --> n2["분석 시스템"]

처럼 소비자 쪽에 복제본을 둘 수도 있다.

또는:

flowchart LR
    n0["Order Data Product"] --> n1["Redis"] --> n2["Ranking Service"]

처럼 캐시를 둘 수도 있다.

장점은 다음과 같다.

조회 지연 감소

원본 부하 감소

소비자 장애 격리

소비 목적에 맞는 저장 구조 사용

하지만 복제는 새로운 문제를 만든다.

원본과 동기화됐는가?

삭제가 전파됐는가?

누가 복제본을 관리하는가?

개인정보 삭제 요청도 반영됐는가?

따라서 복제는 단순한 기술 선택이 아니라
거버넌스 문제이기도 하다.

25. 데이터 프로덕트 아키텍처에는 하나의 정답이 없다

어떤 조직은 중앙 플랫폼 의존도가 높을 수 있다.

다른 조직은 도메인 자율성이 더 높을 수도 있다.

다음 두 극단을 생각할 수 있다.

완전 중앙집중
────────────────────────
표준화 쉬움
중복 적음

하지만
중앙팀 병목 가능

반대편은 다음과 같다.

완전 분산
────────────────────────
도메인 자율성 높음
빠른 변경 가능

하지만
기술 난립
중복 비용 증가
통합 어려움

현실적으로는 그 중간에서 균형을 찾는다.

26. 데이터 프로덕트 도입은 작게 시작한다

처음부터 다음을 만들려고 하면
프로젝트가 너무 커지기 쉽다.

전사 Data Mesh

전사 Data Catalog

전사 Streaming Platform

전사 Governance

보다 현실적인 방식은 작은 성공 사례를 만드는 것이다.

예를 들어:

flowchart LR
    n0["주문 도메인"] --> n1["Seller Daily Sales"]

하나부터 시작한다.

여기에

Owner

Schema

Metadata

Quality

Lineage

Security

Access

Refresh Cycle

을 제대로 적용한다.

실제 소비자가 사용해보고 문제가 없는지 확인한다.

그 후 좋은 패턴을 다른 도메인으로 확장한다.

flowchart LR
    n0["주문"] --> n1["결제"] --> n2["회원"] --> n3["출금"] --> n4["배송"]

이런 점진적인 확장이 훨씬 현실적이다.

27. 데이터 프로덕트 전체 흐름

이 장의 내용을 하나로 연결하면 다음과 같다.

flowchart TB
    S1["문제<br/>──────────<br/>데이터가 여러 시스템에 흩어져 있고<br/>중앙 데이터팀만으로는 감당하기 어려워진다"]
    S2["책임<br/>──────────<br/>데이터를 만드는 도메인이 책임을 갖는다"]
    S3["제품<br/>──────────<br/>Raw Data를 그대로 던지지 않고<br/>소비 목적에 맞는 데이터 프로덕트를 만든다<br/>데이터 · 메타데이터 · 품질 · 계약을 함께 낸다"]
    S4["신뢰<br/>──────────<br/>이력 · 계보 · 품질을 관리한다"]
    S5["제공<br/>──────────<br/>Batch · API · Event · Streaming으로 내보내고<br/>필요하면 CQRS와 읽기 모델을 쓴다"]
    S6["기반<br/>──────────<br/>공통 기술은 Self-Service Platform이 제공하고<br/>도메인 자율성과 조직 표준의 균형을 유지한다"]

    S1 --> S2 --> S3 --> S4 --> S5 --> S6

    style S1 fill:#fff4f4,stroke:#d9534f,color:#1a1a1a
    style S2 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S3 fill:#f8fbff,stroke:#4a90e2,color:#1a1a1a
    style S4 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S5 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S6 fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a

28. 초보자가 특히 구분해야 하는 것

이 장을 공부하면서 다음 개념들을 서로 같은 것으로 혼동하지 않는 것이 중요하다.

Data Product
≠
Database Table

Data Product
≠
Data Mesh

Data Mesh
≠
Bronze / Silver / Gold

CQRS
≠
Data Product의 필수 조건

Raw Data
≠
쓸모없는 데이터

Single Source of Truth
≠
회사 전체 숫자를 무조건 하나로 통일

Ubiquitous Language
≠
전사에서 모든 용어를 하나로 강제

이 구분만 명확하게 이해해도
13~14장의 내용 대부분을 정확하게 이해한 것이다.

29. 14장 정리

이 장에서 가장 중요한 것은
특정 제품이나 기술 이름을 외우는 것이 아니다.

Kafka, dbt, S3, Data Vault, Star Schema,
Bronze/Silver/Gold 같은 기술과 패턴은
상황에 따라 얼마든지 바뀔 수 있다.

더 중요한 것은 사고방식이다.

데이터를 DB에서 우연히 생기는 부산물이 아니라
누군가가 사용하는 하나의 제품으로 생각한다.

그리고 그 제품에 대해 다음 질문에 답할 수 있어야 한다.

이 데이터는 무엇인가?

누가 책임지는가?

어디서 왔는가?

어떻게 만들어졌는가?

얼마나 믿을 수 있는가?

언제 갱신되는가?

과거 데이터는 어떻게 관리되는가?

어떻게 사용할 수 있는가?

누가 사용할 수 있는가?

변경되면 소비자에게 어떤 영향을 주는가?

이 질문에 명확하게 답할 수 있다면
그 데이터는 단순한 테이블이나 파일을 넘어
좋은 데이터 프로덕트에 가까워진다.

13~14장의 핵심 문장

데이터 프로덕트란 명확한 소유자가 데이터의 의미와 품질을 책임지고,
소비자가 별도의 도움 없이도 쉽게 찾고 이해하고 신뢰하여 사용할 수 있도록 제공하는 데이터 제품이다.

그리고 조직 차원에서는 다음 원칙으로 정리할 수 있다.

도메인은 데이터의 의미와 품질을 책임지고,
공통 플랫폼은 데이터 프로덕트를 쉽게 만들고 운영할 수 있는 기술과 표준을 제공한다.

이 두 문장을 이해했다면
13~14장의 가장 중요한 내용을 이해한 것이다.

이 장에서 나온 용어는 부록 C 「용어집」의
「데이터 제품과 모델링」 항목에 정리해 두었다.

15장. 메타데이터와 데이터 지도

5부 · 신뢰 — 찾고, 믿고, 안전하게 쓰려면
15장 · 16장 · 17장 · 18장

데이터 카탈로그와 계보에서 데이터 민주화까지

데이터 시스템이 작을 때는
개발자 몇 명이 구조를 대부분 기억할 수 있다.

어떤 테이블에 어떤 데이터가 있고,
누가 만들었으며 어디에서 사용하는지
코드나 DB를 보면 어느 정도 파악할 수 있다.

하지만 서비스가 커지면 상황이 달라진다.

회원 DB
결제 DB
배송 DB
Kafka
Redis
S3
Data Warehouse
BI
ML
외부 API

수많은 시스템에 데이터가 흩어지기 시작한다.

그러면 단순히 데이터를 저장하는 것만으로는
데이터를 제대로 관리하기 어려워진다.

사람들은 이런 질문을 하기 시작한다.

이 데이터는 무슨 뜻이지?

누가 관리하지?

어디에서 만들어졌지?

어디에서 사용하고 있지?

지금 믿고 사용해도 되는 데이터인가?

이 컬럼을 변경하면
어떤 시스템까지 영향을 받을까?

이런 질문에 답하기 위해 필요한 것이
메타데이터(Metadata) 다.

이번 장에서는 메타데이터가 무엇인지부터 시작해

flowchart LR
    a["메타데이터"] --> b["메타모델"] --> c["데이터 모델"] --> d["데이터 계보"] --> e["데이터 품질"] --> f["데이터 카탈로그"] --> g["데이터 민주화"]

가 어떻게 연결되는지 알아본다.

1. 메타데이터란 무엇인가?

메타데이터를 가장 쉽게 표현하면

데이터를 설명하는 데이터

다.

예를 들어 다음 값이 있다고 하자.

amount = 10000

이것만 봐서는 10000이 무엇을 의미하는지 알기 어렵다.

하지만 다음 정보가 함께 있다면 이해할 수 있다.

테이블
order

컬럼
amount

의미
주문에 사용된 금액

데이터 타입
BIGINT

소유자
주문 서비스팀

생성 시스템
주문 서비스

사용 시스템
정산 / 통계 / 랭킹

이런 정보가 바로 메타데이터다.

즉,

실제 데이터
= 10000

메타데이터
= 이 10000이 무엇을 의미하는지 설명하는 정보

라고 이해하면 된다.

2. 메타데이터가 왜 필요한가?

데이터가 많아질수록
데이터 자체보다 데이터를 이해하기 위한 정보가 중요해진다.

예를 들어 다음과 같은 컬럼이 있다고 하자.

status

이름만 보면 정확한 의미를 알 수 없다.

회원 상태인가?

결제 상태인가?

주문 상태인가?

정산 상태인가?

또 값이 2라고 하더라도

2 = 완료?

2 = 취소?

2 = 정지?

인지 알 수 없다.

그래서 데이터와 함께

의미
정의
소유자
출처
품질
사용처
변경 이력

등을 관리해야 한다.

메타데이터는 결국

회사 데이터 전체를 이해하기 위한 지도

역할을 한다.

3. 비즈니스 메타데이터

메타데이터를 분류하는 방법에 절대적인 표준은 없다.
조직이나 제품에 따라 조금씩 다르게 나눈다.

다만 실무에서는 다음 다섯 영역으로 나누어 보면 이해하기 쉽다.

하나씩 보자.

비즈니스 메타데이터는

데이터가 업무적으로 무엇을 의미하는지

설명한다.

예를 들어

활성 사용자란 무엇인가?

주문 금액은 어떤 금액인가?

결제 완료는 언제 완료로 보는가?

환불 금액에 수수료가 포함되는가?

같은 질문에 답한다.

예를 들어

용어
활성 사용자

정의
최근 30일 안에
1회 이상 로그인한 회원

처럼 정의할 수 있다.

대표적으로 다음 정보가 포함될 수 있다.

비즈니스 용어
용어 정의
업무 규칙
데이터 소유자
사용 목적
관련 도메인

핵심은

사람들이 같은 용어를
같은 의미로 사용하도록 만드는 것이다.

4. 기술 메타데이터

기술 메타데이터는

데이터가 기술적으로 어떻게 구성되어 있는지

설명한다.

예를 들어

DB
스키마
테이블
컬럼
데이터 타입
PK
FK
파일 포맷
암호화 여부

등이다.

table
payment

column
amount

type
BIGINT

nullable
false

같은 정보가 대표적인 기술 메타데이터다.

개발자와 데이터 엔지니어가
데이터 구조를 이해할 때 많이 사용한다.

5. 운영 메타데이터

운영 메타데이터는

데이터가 실제 시스템에서 어떻게 처리되고 있는지

설명한다.

예를 들어

최근 배치 실행 시간
배치 성공 여부
처리 건수
데이터 갱신 시간
파이프라인 실행 시간
오류 여부

등이다.

정산 배치

실행 시각
03:00

최근 결과
성공

처리 건수
1,200,000건

같은 정보다.

운영 메타데이터를 보면

데이터가 지금 정상적으로 만들어지고 있는가?

를 판단할 수 있다.

6. 사용·협업 메타데이터

데이터를 사람들이 어떻게 이용하는지도
중요한 메타데이터가 될 수 있다.

예를 들어

조회 수
즐겨찾기
댓글
리뷰
평점
태그
사용 설명

등이다.

어떤 데이터에 다음 설명이 붙어 있다고 하자.

이 데이터는 실시간 데이터가 아닙니다.

매일 오전 4시 이후 사용하세요.

정산팀에서 관리합니다.

이런 정보는 자동으로 생성된
DB 스키마 정보보다 실제 사용자에게
더 유용할 수도 있다.

7. 데이터 품질도 메타데이터다

데이터가 존재한다고 해서
무조건 믿고 사용할 수 있는 것은 아니다.

예를 들어 다음 데이터가 있다고 하자.

sales_summary

그런데 상태가 다음과 같다면 어떨까?

최근 갱신
3일 전

최근 배치
실패

NULL 비율
20%

데이터는 존재하지만
분석에 사용하기에는 위험하다.

따라서 다음과 같은 품질 정보도
메타데이터로 관리할 수 있다.

정확성
완전성
최신성
일관성
유효성

예를 들어

member.phone_number

NULL 비율
0.1%

형식 오류
0.03%

마지막 갱신
5분 전

처럼 관리할 수 있다.

8. 메타모델이란?

메타데이터를 단순히 모으는 것만으로는 부족하다.

중요한 것은

각 메타데이터가 어떤 관계를 가지는가

이다.

이 관계의 구조를 정의한 것이
메타모델(Metamodel) 이다.

쉽게 표현하면

메타데이터 관계의 설계도

다.

예를 들어 다음 정보가 있다고 하자.

회원 데이터
회원 도메인
회원 서비스
회원팀
회원 DB
회원 API

이 정보들이 따로 존재한다면
가치가 제한적이다.

하지만 다음처럼 연결하면 달라진다.

flowchart LR
    d["회원 데이터"]
    d -- "속한다" --> a["회원 도메인"]
    d -- "소유된다" --> b["회원팀"]
    d -- "저장된다" --> c["회원 DB"]
    d -- "사용된다" --> e["회원 서비스"]
    d -- "제공된다" --> f["회원 API"]

이제 데이터를 중심으로
업무와 기술의 관계를 탐색할 수 있다.

9. 메타모델은 데이터 지도를 만든다

메타모델을 잘 구성하면 다음 질문에
답할 수 있게 된다.

이 데이터는 어느 도메인에 속하는가?

누가 책임지는가?

어느 애플리케이션에서 사용하는가?

어느 DB에 저장되어 있는가?

어떤 비즈니스 용어와 연결되는가?

어떤 데이터 프로덕트의 일부인가?

그래서 메타모델은

조직 전체 데이터 생태계의 지도

라고 생각하면 이해하기 쉽다.

10. 논리적인 데이터와 물리적인 데이터를 구분하자

같은 의미의 데이터가
여러 시스템에 존재할 수 있다.

예를 들어 비즈니스 관점에서는

고객 데이터

하나지만 실제 시스템에는

MariaDB.customer

S3/customer.parquet

BigQuery.customer

customer.csv

처럼 여러 형태로 존재할 수 있다.

따라서

flowchart LR
    n0["논리적인 데이터 개념"] --> n1["실제 물리적인 데이터"]

를 구분해서 관리하면 좋다.

예를 들어

flowchart LR
    n0["고객 데이터셋"]
    n1["MariaDB.customer"]
    n2["S3/customer.parquet"]
    n3["BigQuery.customer"]
    n0 --> n1
    n0 --> n2
    n0 --> n3

처럼 표현할 수 있다.

이렇게 하면

같은 데이터가
어디에 어떤 형태로 존재하는가?

를 알 수 있다.

11. 데이터 도메인

데이터 도메인은 단순히
DB를 나누는 기준이 아니다.

특정 업무와 관련된 데이터, 규칙, 책임을 묶은 영역

이라고 이해하는 것이 좋다.

예를 들면

회원
커머스
결제
배송
주문
정산

같은 영역이다.

데이터 도메인에는 보통

데이터
업무 규칙
사람
프로세스
기술
책임

등이 함께 존재한다.

12. 데이터 프로덕트

데이터 프로덕트가 무엇인지는 13장에서 다뤘다.

메타데이터 관점에서 기억할 것은
데이터 프로덕트 자체도 관리 대상이라는 점이다.

판매자별 일별 주문 통계

라는 데이터 프로덕트가 있다면

정의
소유자
갱신 주기
품질 기준
사용 방법
관련 API
관련 데이터
접근 권한

등을 메타데이터로 함께 관리할 수 있다.

13. 데이터 모델의 세 단계

데이터 모델은 보통 다음 세 단계로 나눠 설명한다.

flowchart LR
    n0["개념적 데이터 모델"] --> n1["논리적 데이터 모델"] --> n2["물리적 데이터 모델"]

쉽게 기억하면 된다.

개념 모델
= 무엇이 존재하는가?

논리 모델
= 어떤 구조와 관계인가?

물리 모델
= 실제 기술 환경에서 어떻게 구현하는가?

14. 개념적 데이터 모델

개념적 데이터 모델은
가장 높은 수준의 모델이다.

기술 구현보다
비즈니스 개념에 집중한다.

예를 들어 커머스라면

회원
상품
주문
결제
환불

정도를 표현한다.

회원
  ↓ 주문한다

주문
  ↓ 포함한다

상품

주문
  ↓ 결제된다

결제

이 단계에서는

BIGINT
VARCHAR
INDEX
PK

같은 구현 정보는 중요하지 않다.

개념 모델은

비즈니스 세계의 지도

라고 보면 된다.

15. 논리적 데이터 모델

논리 모델에서는
개념 모델을 좀 더 구체화한다.

주요 속성과 관계가 들어간다.

flowchart LR
    M["회원<br/>──────────<br/>회원번호<br/>이름 · 가입일"]
    O["주문<br/>──────────<br/>주문번호<br/>회원번호 · 주문금액"]

    M -- "1 : N" --> O

    style M fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style O fill:#fafafa,stroke:#bbb,color:#1a1a1a

이렇게

1:1
1:N
N:M

등을 표현한다.

하지만 아직 반드시
특정 DBMS의 세부 구현까지 정할 필요는 없다.

16. 물리적 데이터 모델

물리 모델에서는
실제 시스템에 데이터를 어떻게 저장할지 결정한다.

예를 들어

CREATE TABLE orders
(
    order_id   BIGINT PRIMARY KEY,
    user_id    BIGINT         NOT NULL,
    amount     DECIMAL(12, 2) NOT NULL,
    created_at DATETIME       NOT NULL
);

같은 수준이다.

여기서는 실제 환경에 맞춰

데이터 타입
키
인덱스
파티셔닝
암호화
저장 방식
성능

등을 결정한다.

관계형 DB라면 PK나 FK를 사용할 수 있고,

NoSQL이나 분산 저장소라면
전혀 다른 형태의 물리 설계가 사용될 수도 있다.

17. 세 모델을 연결하면

전체 흐름을 보면 다음과 같다.

비즈니스 세계

회원
주문
결제

     ↓

개념 모델

회원 → 주문 → 결제

     ↓

논리 모델

회원번호
주문번호
결제금액

     ↓

물리 모델

users
orders
payments

     ↓

실제 DB

메타데이터 시스템에서는
이 관계가 연결되어 있으면 매우 유용하다.

예를 들어

“주문 금액“이라는 비즈니스 용어가
실제 어떤 DB의 어떤 컬럼인가?

를 추적할 수 있다.

18. 비즈니스 용어집

회사에서는 같은 용어를
서로 다르게 이해하는 경우가 많다.

예를 들어

활성 사용자

라고 했을 때

최근 7일 로그인 사용자

최근 30일 로그인 사용자

최근 결제 사용자

탈퇴하지 않은 사용자

등 여러 의미가 가능하다.

그래서 비즈니스 용어에는
가능하면 다음과 같은 정보를 함께 관리해야 한다.

용어
정의
적용 범위
도메인
소유자
관련 데이터
관련 용어

특히 같은 단어라도
도메인에 따라 의미가 달라질 수 있다.

회원팀의 고객
= 가입 회원

결제팀의 고객
= 결제 경험이 있는 사용자

영업팀의 고객
= 계약 대상 기업

따라서 용어는

용어
+
도메인
+
맥락

을 함께 관리하는 것이 중요하다.

19. 메타데이터는 가능한 부분부터 자동 수집한다

대규모 시스템에서 모든 메타데이터를
사람이 직접 작성하는 것은 현실적이지 않다.

예를 들어 회사에

테이블 10,000개
컬럼 100,000개

가 있다면 일일이 등록하기 어렵다.

따라서 기술 메타데이터는
가능하면 자동으로 가져온다.

flowchart LR
    n0["MariaDB"] --> n1["Metadata Scanner"] --> n2["Data Catalog"]

스캐너를 이용해

DB
테이블
컬럼
데이터 타입
스키마

등을 자동으로 가져올 수 있다.

20. 자동 수집만으로는 부족하다

자동 스캐너는 다음 정보는 쉽게 알 수 있다.

컬럼
amount

타입
BIGINT

NULL
허용하지 않음

하지만

이 amount가 결제금액인가?

주문 금액인가?

환불 전 금액인가?

는 자동으로 정확하게 알기 어렵다.

따라서 현실적인 방식은

자동 수집
+
사람의 보완

이다.

자동화는 기술 구조를 가져오고,

사람은

비즈니스 의미
주의사항
소유자
업무 규칙

등을 보완한다.

21. 데이터 계보란?

메타데이터에서 매우 중요한 것이
데이터 계보(Data Lineage) 다.

데이터 계보는

데이터가 어디에서 만들어지고
어떤 변환을 거쳐
어디로 이동하는지를 나타내는 정보

다.

예를 들어

flowchart LR
    n0["결제 DB"] --> n1["ETL"] --> n2["Data Warehouse"] --> n3["일별 매출"] --> n4["월별 매출"] --> n5["경영 Dashboard"]

가 하나의 데이터 계보다.

22. 데이터 계보가 중요한 이유

예를 들어 경영 대시보드의
매출 수치가 이상하다고 하자.

계보가 없다면

Dashboard 문제인가?

집계 테이블 문제인가?

ETL 문제인가?

원본 데이터 문제인가?

를 하나씩 조사해야 한다.

하지만 계보가 있다면

Dashboard
   ↑
monthly_sales
   ↑
daily_sales
   ↑
ETL
   ↑
payment

순서로 원인을 추적할 수 있다.

23. 변경 영향도 분석

계보는 변경 작업에도 중요하다.

예를 들어 개발자가

payment.amount

컬럼을 변경하려고 한다.

계보를 확인하면

flowchart LR
    n0["payment.amount"] --> n1["매출 집계"] --> n2["정산"] --> n3["재무 Report"] --> n4["CEO Dashboard"]

까지 연결되어 있다는 것을 알 수 있다.

그러면 변경 전에

어떤 시스템이 영향을 받는가?

를 파악할 수 있다.

이를 영향도 분석(Impact Analysis) 이라고 한다.

24. 계보 자동화에도 한계가 있다

계보도 가능한 부분은 자동으로 수집할 수 있다.

예를 들어

SQL 분석
ETL 분석
Spark Job 분석
API 연동

등을 이용할 수 있다.

하지만 모든 시스템과 모든 변환을
자동으로 완벽하게 파악할 수 있는 것은 아니다.

도구마다 지원 범위가 다르기 때문이다.

따라서 중요한 계보는

자동 수집
+
수동 보완

을 함께 사용할 수 있다.

또한

테이블 수준
컬럼 수준
프로세스 수준

중 어디까지 관리할지도 정해야 한다.

깊이가 세밀해질수록
관리 비용도 증가한다.

25. 데이터 카탈로그

메타데이터를 모아 놓았다면
사용자가 쉽게 검색할 수 있어야 한다.

이를 위한 대표적인 도구가
데이터 카탈로그(Data Catalog) 다.

쉽게 말하면

회사 데이터용 검색 포털

이라고 보면 된다.

예를 들어

주문

을 검색하면

주문 데이터 프로덕트
주문 관련 테이블
관련 API
데이터 소유자
관련 Dashboard
데이터 품질
데이터 계보

등을 확인할 수 있다.

26. 데이터 카탈로그의 핵심 목적

데이터 카탈로그의 중요한 역할은
세 가지 질문에 쉽게 답하도록 만드는 것이다.

무엇인가?

어디에 있는가?

믿고 사용해도 되는가?

여기에

누가 관리하는가?

어디에서 사용하는가?

까지 알 수 있다면 더욱 좋다.

27. 데이터 민주화

이런 환경의 궁극적인 목표 중 하나가
데이터 민주화(Data Democratization) 다.

데이터 민주화는

모든 직원에게
모든 DB 권한을 준다

는 뜻이 아니다.

정확하게는

필요한 사람이
필요한 데이터를 쉽게 찾고,
의미를 이해하고,
품질을 판단하고,
적절한 권한을 받아
스스로 활용할 수 있도록 만드는 것

이다.

예를 들어 기획자가

최근 30일
판매자별 주문 데이터를 보고 싶다.

고 했을 때

매번 개발자에게 질문하는 것이 아니라

flowchart LR
    n0["검색"] --> n1["데이터 발견"] --> n2["정의 확인"] --> n3["품질 확인"] --> n4["소유자 확인"] --> n5["권한 신청"] --> n6["사용"]

하는 것이 목표다.

28. 데이터 민주화와 보안은 반대 개념이 아니다

데이터 민주화를

모든 데이터를 공개하는 것

으로 이해하면 안 된다.

예를 들어

개인정보
결제정보
인사정보
재무정보

등에는 반드시 접근 통제가 필요하다.

따라서 좋은 데이터 민주화는

셀프서비스 + 적절한 거버넌스

를 함께 제공한다.

29. 데이터 계약

데이터를 제공하는 팀과 사용하는 팀 사이의 약속을
데이터 계약(Data Contract) 이라고 한다.

스키마, 갱신 주기, 가용성 목표, 변경 통보 기간 같은
내용을 정해 둔다.

데이터 계약은 16장 「거버넌스」에서 다룬다.

메타데이터 관점에서 중요한 것은
계약 내용도 카탈로그에서 확인할 수 있어야 한다는 점이다.

30. AI와 메타데이터

메타데이터가 잘 정리되어 있으면
AI를 활용하기도 쉬워진다.

예를 들어 사용자가

최근 30일 동안
판매자별 주문 금액을 볼 수 있는
데이터를 찾아줘.

라고 질문할 수 있다.

시스템에 다음 관계가 있다면

AI가 관련 데이터 프로덕트를
찾는 데 도움을 줄 수 있다.

또한 AI와 ML을 이용해

자동 분류
태그 추천
관련 데이터 추천
품질 이상 탐지
메타데이터 보완 후보 생성

등을 구현할 수도 있다.

31. AI가 모든 의미를 자동으로 알아내는 것은 아니다

이 부분은 중요하다.

예를 들어

cust_no

라는 컬럼을 보고 AI가

고객 식별자일 가능성이 높다.

라고 추천할 수는 있다.

하지만 항상 정확한 것은 아니다.

따라서 현실적으로는

flowchart TD
    n0["컬럼명"]
    n1["설명"]
    n2["샘플 데이터"]
    n3["계보"]
    n4["관련 테이블"]
    n5["비즈니스 용어"]
    n6["AI"]
    n7["의미 / 분류 후보 추천"]
    n8["필요한 경우 사람 검증"]
    n0 --> n6
    n1 --> n6
    n2 --> n6
    n3 --> n6
    n4 --> n6
    n5 --> n6
    n6 --> n7
    n7 --> n8

형태가 안전하다.

특히 개인정보나 보안 분류처럼
중요한 영역은 사람의 검증이 필요할 수 있다.

32. 처음부터 모든 데이터를 관리하려 하지 말자

메타데이터 프로젝트에서
흔히 발생하는 실수가 있다.

모든 DB

모든 테이블

모든 컬럼

모든 API

모든 서비스

모든 비즈니스 용어

를 한 번에 관리하려는 것이다.

범위가 지나치게 커지면
구축도 어렵고 유지도 어렵다.

좋은 접근은

flowchart LR
    n0["핵심 도메인 선정"] --> n1["핵심 데이터 프로덕트 선정"] --> n2["중요 테이블과 컬럼"] --> n3["소유자 / 정의 / 품질"] --> n4["계보"] --> n5["점진적인 확대"]

다.

33. 중앙 조직과 도메인의 역할

회사 전체 메타데이터를
중앙팀 하나가 직접 관리하는 것도 어렵다.

따라서 다음과 같이 역할을 나눌 수 있다.

flowchart LR
    subgraph CENTRAL["중앙이 맡는 것"]
        C1["공통 메타모델"]
        C2["표준"]
        C3["플랫폼"]
        C4["정책"]
    end

    subgraph DOMAIN["각 도메인이 맡는 것"]
        D1["실제 데이터"]
        D2["정의와 품질"]
        D3["소유권"]
    end

    style CENTRAL fill:#f8fbff,stroke:#4a90e2,color:#1a1a1a
    style DOMAIN fill:#f2fbf4,stroke:#4caf50,color:#1a1a1a

예를 들어 중앙에서

데이터 프로덕트란 무엇인가?

Owner는 어떻게 지정하는가?

품질을 어떻게 표현하는가?

계보를 어떤 방식으로 연결하는가?

를 정한다.

각 도메인은 이 기준에 따라

회원
커머스
배송
정산

데이터를 관리한다.

34. 데이터 오너십

메타데이터 관리에서 특히 중요한 것은

누가 책임지는 데이터인가?

를 명확하게 하는 것이다.

예를 들어

payment_transaction

Owner
커머스팀

품질 담당
커머스 데이터 담당자

처럼 관리할 수 있다.

소유자가 없다면

설명이 오래되어도 아무도 수정하지 않고

품질 문제가 발생해도 책임자가 없으며

문의할 사람도 찾기 어렵다.

좋은 메타데이터 관리에는
명확한 오너십이 필요하다.

35. 메타데이터도 낡는다

메타데이터도 데이터다.

시간이 지나면 틀릴 수 있다.

예를 들어

담당팀 변경

테이블 삭제

API 버전 변경

비즈니스 정의 변경

데이터 파이프라인 변경

등이 발생한다.

따라서 메타데이터 역시

모니터링
검증
갱신
피드백

이 필요하다.

36. 피드백 루프

예를 들어 사용자가

이 데이터 설명이 잘못됐습니다.

라고 신고했다고 하자.

좋은 시스템이라면

flowchart LR
    n0["문제 발견"] --> n1["담당자 알림"] --> n2["내용 수정"] --> n3["검증"] --> n4["카탈로그 반영"]

으로 이어져야 한다.

이런 구조가 있어야
메타데이터 품질도 지속적으로 좋아진다.

37. 기술만 도입한다고 성공하지 않는다

좋은 데이터 카탈로그를 설치했다고 해서
메타데이터 관리가 자동으로 성공하는 것은 아니다.

사람들이 실제로

설명을 작성하고

소유자를 지정하고

품질을 관리하고

용어를 정리하고

잘못된 정보를 수정해야

한다.

즉 메타데이터 관리는

기술
+
프로세스
+
조직
+
사람
+
문화

가 함께 필요한 영역이다.

38. 실무 예제로 전체 흐름 이해하기

다음 데이터가 있다고 하자.

commerce.order

메타데이터가 없다면

개발자는

DB를 확인하고

소스코드를 검색하고

다른 개발자에게 물어보고

관련 문서를 찾아야

이 테이블을 이해할 수 있다.

하지만 메타데이터가 잘 관리되어 있다면
다음처럼 볼 수 있다.

데이터 프로덕트
실시간 주문 데이터

도메인
커머스

소유자
주문팀

물리 데이터
commerce.order

주요 컬럼
buyer_id
seller_id
point_amount
amount

갱신
실시간

사용 시스템
정산
랭킹
통계

관련 비즈니스 용어
주문
포인트
판매자
주문 금액

계보도 확인할 수 있다.

flowchart LR
    n0["주문 서비스"] --> n1["Kafka"] --> n2["commerce.order"] --> n3["주문 집계"] --> n4["정산 / 랭킹 / Dashboard"]

품질 정보도 볼 수 있다.

최근 갱신
정상

파이프라인
정상

품질 검사
통과

그러면 새로운 개발자나 분석가도

이 데이터가 무엇이고
어디서 만들어지며
누가 책임지고
어디에서 사용하는지

빠르게 이해할 수 있다.

39. 15장 정리

이 장의 개념을 하나로 연결하면 다음과 같다.

flowchart TB
    S1["메타데이터<br/>──────────<br/>이 데이터는 무엇인가"]
    S2["메타모델<br/>──────────<br/>다른 데이터와 어떤 관계인가"]
    S3["개념 · 논리 · 물리 모델<br/>──────────<br/>업무 개념이 실제 시스템에<br/>어떻게 구현되는가"]
    S4["데이터 계보<br/>──────────<br/>어디에서 와서 어디로 가는가"]
    S5["데이터 품질<br/>──────────<br/>믿고 사용해도 되는가"]
    S6["데이터 카탈로그<br/>──────────<br/>어디에서 찾을 수 있는가"]
    S7["데이터 민주화<br/>──────────<br/>필요한 사람이<br/>안전하게 스스로 활용한다"]

    S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7

    style S1 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S2 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S3 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S4 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style S5 fill:#f8fbff,stroke:#4a90e2,color:#1a1a1a
    style S6 fill:#f8fbff,stroke:#4a90e2,color:#1a1a1a
    style S7 fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a

이 흐름을 문장으로 옮기면 이렇다.

데이터가 많아질수록
데이터 자체보다 데이터를 이해하기 위한 정보가 중요해진다.

메타데이터는 이 데이터가 무엇이고, 어디에 있고,
누가 관리하고, 어디에서 만들어졌고, 어디에서 쓰이고,
믿어도 되는지를 알려준다.

메타모델은 그 정보들을 관계로 연결한다.
연결되어야 지도가 된다.

개념·논리·물리 모델은
비즈니스 개념이 실제 시스템에 어떻게 구현되는지를 보여준다.

데이터 계보는 데이터의 이동과 변환을 추적하고,
데이터 품질 정보는 그 데이터를 신뢰할 수 있는지 알려준다.

데이터 카탈로그는 사람들이 필요한 데이터를 스스로 찾게 해준다.

그리고 이 모든 것의 목적이 데이터 민주화다.

여기서 더 나아가 조직의 데이터·서비스·사람·용어를
그래프로 연결하고(지식 그래프),
분산된 데이터를 하나처럼 다루고(데이터 패브릭),
데이터 프로덕트를 상품처럼 찾아 쓰게 하는(데이터 마켓플레이스)
접근법이 있다.
부록 B 「지식 그래프와 시맨틱 웹」에서 다룬다.

무엇보다 중요한 원칙

처음부터 모든 데이터를 완벽하게 관리하려고 하지 않는 것

핵심 도메인과 중요한 데이터부터 시작해
소유자와 정의와 품질과 계보를 명확하게 만들고
점진적으로 범위를 넓힌다.

그리고 메타데이터의 가치는
설명문을 많이 쓰는 데 있지 않다.

데이터의 의미, 구조, 출처, 품질, 소유권과
다른 시스템과의 관계를 연결해
조직이 데이터를 이해하고 신뢰할 수 있게 만드는 것.

궁극적인 목표는 하나다.

조직의 구성원이 필요한 데이터를 스스로 발견하고,
의미를 이해하고, 신뢰성을 판단하며,
적절한 권한 아래 안전하게 활용할 수 있는 환경.

이것이 메타데이터를 통한 데이터 민주화다.

이 장에서 나온 용어는 부록 C 「용어집」의
「메타데이터와 거버넌스」 항목에 정리해 두었다.
그래프 관련 기술은 「메타데이터 심화」에 있다.

16장. 거버넌스

5부 · 신뢰 — 찾고, 믿고, 안전하게 쓰려면
15장 · 16장 · 17장 · 18장

데이터를 책임 있게 관리하고 안전하게 활용하는 법

회사가 작을 때는 데이터 관리가 비교적 단순하다.

어떤 데이터가 필요하면
담당 개발자에게 물어보면 된다.

"회원 가입일은 어디에 있어요?"

"member 테이블의 created_at입니다."

문제가 생겨도 누가 만든 데이터인지
대략 알고 있기 때문에 해결하기 쉽다.

하지만 회사가 성장하면 상황이 달라진다.

회원, 결제, 배송, 정산, 마케팅처럼
여러 도메인이 생기고,

각 도메인마다 데이터베이스, API, 이벤트,
데이터 파이프라인과 분석 시스템이 만들어진다.

그러면 자연스럽게 이런 질문이 생긴다.

이 데이터의 정확한 의미는 무엇이지?

어느 데이터가 기준이지?

누가 이 데이터를 책임지지?

잘못됐으면 누가 고치지?

누가 접근할 수 있지?

개인정보는 어디에 저장되어 있지?

이 데이터를 다른 목적으로 써도 되나?

이런 문제를 조직적으로 해결하기 위한 체계가
데이터 거버넌스(Data Governance) 다.

그리고 데이터의 중요도와 사용 목적에 따라
적절한 보호 조치를 적용하는 것이
데이터 보안(Data Security) 이다.

두 영역은 서로 밀접하게 연결되어 있다.

1. 데이터 거버넌스란 무엇인가

데이터 거버넌스를 어렵게 생각할 필요는 없다.

간단히 말하면,

데이터를 누가 책임지고,
어떤 의미와 규칙에 따라
관리하고 사용할지 정하는 체계다.

예를 들어 회원가입일이라는 데이터가 있다고 하자.

거버넌스가 없다면 팀마다 의미가 달라질 수 있다.

모두 회원가입일이라는 이름을 쓰는데
실제 의미가 다르다.

이 상태에서 보고서를 만들면
팀마다 숫자가 다르게 나온다.

거버넌스를 적용하면 다음과 같이 정리할 수 있다.

데이터명
회원 가입일

정의
최초 회원가입 절차가 완료된 시각

소유자
회원 도메인

저장 위치
member.created_at

개인정보 여부
아님

주요 사용 목적
회원 가입 통계

즉 데이터의 의미와 책임을
공식적으로 정의하는 것이다.

2. 좋은 거버넌스는 데이터를 막지 않는다

거버넌스라고 하면 흔히

승인
통제
제한
규칙

을 떠올린다.

잘못 만든 거버넌스는 실제로
업무를 느리게 만들기도 한다.

예를 들어 데이터 하나를 보기 위해

flowchart LR
    n0["신청서 작성"] --> n1["팀장 승인"] --> n2["데이터팀 승인"] --> n3["보안팀 승인"] --> n4["권한 부여"]

를 거쳐야 한다면
사용자는 거버넌스를 피하려 할 것이다.

좋은 거버넌스의 목적은 그 반대다.

믿을 수 있는 데이터를
필요한 사람이 안전하게 사용할 수 있게 만드는 것

이 핵심이다.

따라서 좋은 거버넌스는

통제
+
자율성
+
안전성
+
접근성

사이의 균형을 맞춰야 한다.

3. 회사가 커질수록 거버넌스가 필요한 이유

조직이 커지면 데이터의 양뿐 아니라
데이터를 사용하는 사람과 시스템도 늘어난다.

처음에는 한두 사람이 알고 있던 지식이
더 이상 개인의 기억만으로 관리되지 않는다.

예를 들어 활성 사용자라는 지표도

• 서비스팀 — 최근 7일 로그인 사용자
• 마케팅팀 — 최근 30일 활동 사용자

처럼 달라질 수 있다.

데이터가 잘못됐을 때도

서비스팀 문제인가?

데이터 파이프라인 문제인가?

분석팀 문제인가?

를 알기 어려워진다.

개인정보나 금융정보가 포함되기 시작하면
더 복잡해진다.

조직은 최소한 다음을 알아야 한다.

어떤 데이터를 보유하는가

어디에 저장되어 있는가

왜 사용하는가

누가 책임지는가

누가 접근하는가

얼마나 보관하는가

이런 질문에 답할 수 있게 만드는 것이
데이터 거버넌스의 중요한 역할이다.

4. 데이터 거버넌스와 데이터 보안

두 개념은 관련되어 있지만 동일하지 않다.

데이터 거버넌스는 주로 이런 질문을 한다.

이 데이터는 무엇인가?

누가 책임지는가?

어떤 목적으로 사용하는가?

어떤 품질을 유지해야 하는가?

얼마나 보관해야 하는가?

데이터 보안은 이런 질문을 한다.

누가 접근할 수 있는가?

어떤 작업까지 허용할 것인가?

암호화가 필요한가?

마스킹해야 하는가?

접근 기록을 남겨야 하는가?

쉽게 관계를 표현하면 다음과 같다.

데이터 거버넌스
→ 관리 원칙과 책임을 정의

데이터 보안
→ 정책·프로세스·기술적 통제로
   데이터를 보호

데이터 보안은 단순히 기술만을 뜻하지 않는다.

접근 정책, 조직의 책임, 운영 절차, 감사 같은
관리적 활동도 함께 포함한다.

5. 가장 먼저 정해야 할 것은 책임이다

거버넌스를 시작할 때
가장 먼저 솔루션을 구매할 필요는 없다.

먼저 정해야 할 것은

누가 무엇을 책임지는가

이다.

조직마다 명칭과 책임 범위는 다르지만,
대표적으로 다음과 같은 역할을 사용한다.

하나씩 보자.

6. 최고 데이터 책임자

CDO(Chief Data Officer)는
조직의 전체적인 데이터 전략을 책임하는 역할이다.

조직에 따라 CDO가 없을 수도 있으며
다른 임원이나 데이터 조직이 역할을 나눠 맡기도 한다.

주요 관심사는 다음과 같다.

데이터 전략

데이터 관리 원칙

데이터 표준

거버넌스 운영 방향

즉 개별 테이블을 관리하기보다
회사 전체의 데이터 방향을 결정하는 역할에 가깝다.

7. 데이터 오너

Data Owner는 특정 데이터 영역에 대한
책임을 갖는 역할이다.

예를 들어 다음처럼 나눌 수 있다.

• 회원 데이터 — 회원 도메인
• 결제 데이터 — 커머스 도메인
• 배송 데이터 — 주문 도메인

Data Owner는 보통 다음과 같은 내용을 결정하거나
그 결정에 대한 책임을 가진다.

데이터 정의

사용 목적

품질 기준

분류 기준

접근 정책

Data Owner가 반드시 개발자일 필요는 없다.

데이터의 비즈니스 의미를 잘 이해하는 사람이
오히려 적절한 경우도 많다.

8. 데이터 스튜어드

Data Steward는 쉽게 말해

데이터 관리 실무 담당자

라고 이해하면 된다.

Data Owner가

"이 데이터는 이런 기준으로 관리합니다."

라고 방향을 정한다면,

Data Steward는 실제로

정의 관리

메타데이터 관리

품질 확인

표준 준수 확인

같은 일을 수행할 수 있다.

다만 Data Steward의 정확한 업무 범위는
조직마다 상당히 다르다.

9. 애플리케이션 오너

Application Owner는
데이터가 아니라 시스템을 책임한다.

예를 들어

결제 API

회원 서비스

정산 시스템

배송 시스템

등이다.

주요 관심사는

시스템 운영

유지보수

배포

장애 대응

접근 제어 구현

등이다.

10. Data Owner와 Application Owner의 차이

두 역할은 비슷해 보이지만
관점이 다르다.

Data Owner는 이런 질문을 한다.

결제 완료란 무엇인가?

결제 금액은 어떤 값을 의미하는가?

환불 데이터는 어떻게 정의하는가?

Application Owner는 이런 질문을 한다.

결제 API가 정상 동작하는가?

DB 연결에 문제가 없는가?

배포가 정상적으로 이루어졌는가?

권한 검사가 제대로 동작하는가?

즉,

• Data Owner — 데이터의 의미와 책임
• Application Owner — 시스템의 기술적 운영

으로 이해하면 쉽다.

11. 데이터 사용자와 비즈니스 사용자

Data User는 실제로 데이터를 사용하는 사람이다.

예를 들면

SQL 조회

대시보드 확인

리포트 작성

데이터 분석

등이다.

Business User는 비즈니스 요구를 제시하는 역할이다.

예를 들어

"월별 결제 전환율을 보고 싶습니다."

"신규 가입자의 30일 유지율이 필요합니다."

와 같은 요구사항을 만든다.

한 사람이 두 역할을 동시에 수행할 수도 있다.

12. 데이터 생성자

Data Creator는 데이터를 만드는
사람이나 시스템이다.

예를 들어

회원가입 API

결제 시스템

관리자 입력

외부 제휴 시스템

등이 있다.

현대 시스템에서는 사람이 직접 만드는 것보다
애플리케이션이 생성하는 데이터가 더 많은 경우가 일반적이다.

13. 중앙 집중과 도메인 자율성

대규모 조직에서는 중앙 데이터팀이
모든 데이터의 비즈니스 의미를 이해하기 어렵다.

그래서 상황에 따라

• 중앙 조직 — 공통 원칙과 표준
• 각 도메인 — 자기 데이터에 대한 책임

구조를 사용할 수 있다.

특히 Data Mesh 같은 접근에서는

도메인 데이터 소유권과
연합형 거버넌스(Federated Governance)

를 중요한 원칙으로 본다.

하지만 모든 회사가 반드시
이 구조를 사용해야 하는 것은 아니다.

조직 규모와 구조에 따라
중앙 집중형 거버넌스가 더 적합할 수도 있다.

중요한 것은 구조보다

책임과 의사결정 권한이 명확해야 한다는 것

이다.

14. 거버넌스 프레임워크

거버넌스 프레임워크는 쉽게 말해

조직이 데이터를 관리하는 전체 운영 방식

이다.

프레임워크에는 역할만 들어가는 것이 아니다.

역할

책임

정책

표준

절차

가이드라인

등이 함께 정의되어야 한다.

예를 들어 이런 질문에 답할 수 있어야 한다.

Data Owner는 무엇을 승인하는가?

품질 문제가 발생하면 누가 처리하는가?

개인정보 접근은 누가 승인하는가?

데이터 정의 변경은 어떤 절차를 따르는가?

15. 데이터 생명주기

데이터 거버넌스는
데이터가 저장된 순간만 관리하지 않는다.

데이터의 전체 수명주기를 살펴본다.

flowchart LR
    n0["생성"] --> n1["저장"] --> n2["제공"] --> n3["사용"] --> n4["보관"] --> n5["폐기"]

회원 데이터를 예로 들면

flowchart LR
    n0["회원가입"] --> n1["회원 데이터 생성"] --> n2["DB 저장"] --> n3["API 또는 분석 시스템으로 제공"] --> n4["서비스와 분석에 사용"] --> n5["보존기간 만료"] --> n6["삭제 또는 적절한 후속 처리"]

까지 관리 대상이 될 수 있다.

16. RACI로 책임을 명확하게 하기

복잡한 업무에서는 누가 무엇을 해야 하는지
명확하게 표현할 필요가 있다.

이때 자주 사용하는 방법 중 하나가 RACI다.

R - Responsible
실제 수행자

A - Accountable
최종 책임자

C - Consulted
의견을 제공하는 사람

I - Informed
결과를 전달받는 사람

예를 들어 개인정보 접근 정책을 변경한다면

A
Data Owner

R
Data Steward

C
보안팀 / Application Owner

I
Data User

처럼 정의할 수 있다.

핵심은

최종 책임자가 누구인지 모르는 상태를 없애는 것

이다.

17. 거버넌스 조직의 역할

회사에 별도의 Governance Team이 있다면
모든 데이터를 직접 관리하기보다는

전체적인 관리 체계를 운영하는 역할을 맡는다.

예를 들어

정책과 표준 관리

교육

정기 리뷰

감사

성숙도 평가

개선 영역 식별

등이다.

쉽게 말하면

• Data Owner — 자기 데이터 책임
• Governance Team — 회사 전체의 관리 체계 책임

이다.

18. 거버넌스는 기술 프로젝트만이 아니다

회사가 거버넌스를 시작할 때 흔히

데이터 카탈로그를 사자.

품질 관리 솔루션을 도입하자.

권한 관리 도구를 구축하자.

부터 생각한다.

하지만

데이터 책임자가 없고

정의가 합의되지 않았고

조직 간 책임도 불명확하다면

도구만으로 해결하기 어렵다.

일반적으로는

flowchart LR
    n0["역할과 책임"] --> n1["정책과 원칙"] --> n2["프로세스"] --> n3["필요한 도구"]

순서로 생각하는 것이 이해하기 쉽다.

19. 데이터 카탈로그

Data Catalog는 쉽게 말하면

회사의 데이터 검색 시스템

이다.

예를 들어 결제 금액을 검색했을 때

데이터명
payment_amount

정의
실제 승인된 결제 금액

Owner
커머스 도메인

위치
payment_order.amount

개인정보 여부
아님

품질 상태
정상

같은 정보를 확인할 수 있다.

현대적인 카탈로그는 테이블 목록만 보여주지 않는다.
비즈니스 용어, 소유자, 출처, 계보, 분류, 품질,
사용 현황까지 함께 관리할 수 있다.

카탈로그를 어떻게 구축하는지는 15장에서 다뤘다.
거버넌스에서 중요한 것은 카탈로그가
누가 무엇을 책임지는지 드러내는 창구라는 점이다.

20. 애플리케이션 리포지터리

Application Repository는

조직에 어떤 애플리케이션이 존재하는지 관리하는 목록

이라고 생각하면 된다.

예를 들어

Commerce API

Owner
커머스 개발팀

중요도
Critical

주요 데이터
결제 / 주문

개인정보
일부 포함

같은 정보를 관리할 수 있다.

데이터와 애플리케이션을 연결하면

이 데이터는 어느 시스템에서 만들어졌는가?

도 추적하기 쉬워진다.

21. 메타데이터와 데이터 계보

메타데이터는 데이터를 설명하는 데이터다.
컬럼 이름, 타입, 설명, 소유자, 개인정보 여부,
생성 시스템 같은 정보가 여기에 해당한다.

데이터 계보는 데이터가 어디에서 생성되고
어떤 변환을 거쳐 어디에서 사용되는지 추적하는 것이다.

flowchart LR
    n0["결제 DB"] --> n1["ETL"] --> n2["Data Warehouse"] --> n3["일별 매출 테이블"] --> n4["경영 대시보드"]

이렇게 기록해 두면 결제 DB의 컬럼을 바꿀 때

어떤 파이프라인이 영향을 받지?

어떤 리포트가 깨질 수 있지?

를 분석할 수 있다.

메타데이터와 계보를 어떻게 모으고 관리하는지는
15장 「메타데이터와 데이터 지도」에서 다뤘다.

거버넌스 관점에서 기억할 것은
이 정보가 없으면 책임도 통제도 성립하지 않는다는 점이다.

22. 데이터 계약

Data Contract는

데이터 제공자와 소비자 사이의 명시적인 약속

이라고 이해하면 된다.

API Contract와 비슷한 생각이다.

예를 들어 결제 이벤트를 제공한다면

• payment_id — bigint / 필수
• user_id — bigint / 필수
• amount — 0 이상
• 제공 주기 — 실시간
• 변경 — 호환성에 영향을 주면 사전 협의

같은 내용을 정할 수 있다.

23. 데이터 계약에 들어갈 수 있는 내용

Data Contract의 범위에는
하나의 국제 표준이 정해져 있는 것은 아니다.

조직이나 도구에 따라 달라진다.

기술적인 내용으로는

스키마

데이터 타입

품질 기준

전송 방식

가용성

버전

변경 정책

등이 포함될 수 있다.

필요하다면 비즈니스나 보안 측면의

사용 목적

허용된 소비자

보존 조건

개인정보 처리 조건

까지 포함할 수도 있다.

즉 Data Contract를
단순한 스키마 정의서로만 볼 필요는 없다.

24. 사용 약정

Usage Agreement는

데이터를 어떤 목적으로 사용할 수 있는지

를 정하는 약속이다.

예를 들어

사용 목적
마케팅 분석

사용 조직
마케팅팀

외부 반출
금지

제3자 재배포
금지

처럼 정의할 수 있다.

중요한 것은

데이터를 가지고 있다는 사실과
그 데이터를 어떤 목적으로든 사용할 수 있다는 것은
같은 의미가 아니라는 점이다.

25. 데이터 계약을 자동 검증하기

Data Contract가 문서로만 존재하면
실제 데이터가 계약을 지키는지 확인하기 어렵다.

그래서 계약을 검증 가능한 규칙으로 만들 수 있다.

예를 들어

• user_id — NULL 불가
• amount — 0 이상
• created_at — 미래 시각 불가

라고 정의했다면 데이터 파이프라인에서

flowchart LR
    n0["데이터 생성"] --> n1["계약 검증"] --> n2["품질 테스트"] --> n3["통과"] --> n4["배포 또는 제공"]

과 같은 흐름을 만들 수 있다.

이런 방식은 소프트웨어의 테스트와
CI/CD 사고방식과 비슷하다.

26. 데이터 관측 가능성

Data Observability는

데이터와 데이터 파이프라인의 상태를
지속적으로 관찰할 수 있는 능력

을 의미한다.

서비스를 운영할 때

CPU
Memory
Error
Latency

를 관찰하듯,

데이터에서도 대표적으로

최신성(Freshness)

데이터 양(Volume)

스키마 변화

데이터 품질

데이터 흐름(Lineage)

같은 요소를 관찰할 수 있다.

이것들은 이해를 돕기 위한 대표적인 예이며
공식적으로 고정된 하나의 목록은 아니다.

27. 계약과 관측 가능성

둘의 관계는 다음처럼 이해하면 쉽다.

• Data Contract — 정상 상태를 정의
• Data Observability — 실제 상태를 관찰

예를 들어 계약에

5분 이내에 새로운 데이터가 도착해야 한다.

라고 되어 있는데,

마지막 데이터가 30분 전에 들어왔다면
이상 상태를 감지할 수 있다.

28. 데이터 품질은 가능한 한 앞단에서 해결한다

데이터 품질 문제를 분석 시스템에서 계속 고치는 것은
장기적으로 관리 비용을 높인다.

좋지 않은 구조는 다음과 같다.

flowchart LR
    n0["서비스에서 잘못된 값 생성"] --> n1["ETL에서 보정"] --> n2["DW에서 또 보정"] --> n3["리포트에서도 예외 처리"]

가능하면

flowchart LR
    n0["데이터가 생성되는 곳에서 올바른 값을 만들고"] --> n1["뒤쪽 시스템이 그대로 사용"]

하는 편이 좋다.

이를 흔히

업스트림에서 품질 문제를 해결한다

고 표현한다.

29. 모든 데이터에 동일한 품질 수준이 필요한 것은 아니다

데이터의 목적에 따라 요구되는 품질 수준은 다르다.

예를 들어

• 정산 금액 — 매우 높은 정확성 필요
• 추천 시스템 행동 로그 — 일부 손실을 허용할 수도 있음

처럼 다르게 판단할 수 있다.

중요한 것은

데이터의 비즈니스 중요도에 맞는
현실적인 품질 목표를 세우는 것

이다.

30. 작게 시작해서 넓혀 간다

거버넌스를 시작하면서

모든 데이터 자동 분류

모든 접근 ABAC 적용

모든 Data Contract 자동 검증

완전한 셀프서비스

를 한 번에 만들려고 하면
프로젝트가 지나치게 커진다.

처음에는 회원·결제·정산처럼
중요한 데이터 몇 개부터 시작하는 것이 좋다.

순서는 조직 상황에 따라 달라지지만
대체로 다음 흐름이 이해하기 쉽다.

flowchart TB
    P1["1단계 · 정한다<br/>──────────<br/>데이터 책임자를 정하고<br/>핵심 데이터의 의미를 정의한다"]
    P2["2단계 · 보이게 한다<br/>──────────<br/>메타데이터를 모아 카탈로그에서 찾게 하고<br/>민감도와 사용 목적을 분류한다"]
    P3["3단계 · 지키게 한다<br/>──────────<br/>접근 정책과 데이터 계약을 적용하고<br/>품질과 관측 가능성을 관리한다<br/>반복 업무는 자동화한다"]

    P1 --> P2 --> P3

    style P1 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style P2 fill:#f8fbff,stroke:#4a90e2,color:#1a1a1a
    style P3 fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a

핵심은

작게 시작하고 반복적으로 개선하는 것

이다.

31. 거버넌스가 사용자에게 가치를 줘야 한다

사용자 입장에서 거버넌스가

승인

통제

문서 작업

규칙

으로만 느껴지면 정착하기 어렵다.

좋은 거버넌스는

필요한 데이터를 쉽게 찾고

정확한 의미를 확인하고

믿을 수 있는지 판단하고

책임자를 쉽게 찾고

적절한 권한을 빠르게 받는 것

을 가능하게 해야 한다.

즉,

거버넌스가 업무를 방해하는 것이 아니라
업무를 더 쉽게 만들어야 한다.

32. 결국 조직 문화가 중요하다

앞에서 도구보다 역할과 책임이 먼저라고 했다.

그런데 역할을 정해 놓아도
그 역할을 실제로 수행하지 않으면 종이에만 남는다.

결국 사람과 조직이

데이터에 책임을 가지고

공통 정의를 따르고

문제를 발견하면 수정하고

도메인 간에 협력

해야 한다.

그래서 데이터 거버넌스는
기술 프로젝트이면서 동시에

조직 변화 프로젝트

다.

33. 리더십의 역할

거버넌스는 한 팀만의 업무가 아니다.

여러 조직의 업무 방식과 책임에 영향을 준다.

따라서 리더는

왜 필요한지

어떤 원칙으로 운영할지

누가 책임지는지

조직이 어떤 가치를 얻는지

를 명확하게 설명해야 한다.

경영진이나 CDO, CTO, CISO 같은 역할의 지원이
필요한 경우도 많다.

34. 16장 정리

네 가지만 기억하면 된다.

거버넌스는 누가 어떤 기준으로 데이터를 관리할지 정하는 체계다.
같은 이름의 데이터가 팀마다 다른 의미를 갖는 상태를 없애는 일이다.

도구보다 역할과 책임이 먼저다.
책임자가 없고 정의가 합의되지 않은 상태에서
카탈로그를 사도 문제는 그대로 남는다.

데이터 계약은 제공자와 소비자의 명시적인 약속이다.
스키마, 품질 기준, 갱신 주기, 변경 정책을 정해 두면
문서로만 두지 않고 자동으로 검증할 수도 있다.

좋은 거버넌스는 데이터를 막지 않는다.
믿을 수 있는 데이터를 필요한 사람이
안전하게 쓸 수 있게 만드는 것이 목적이다.

다음 장에서는 이 정보를 바탕으로
데이터를 실제로 지키는 방법을 본다.

17장. 보안과 접근 제어

5부 · 신뢰 — 찾고, 믿고, 안전하게 쓰려면
15장 · 16장 · 17장 · 18장

분석용으로 복사해 둔 테이블을 열어 봤다.

운영 DB에서 그대로 떠온 탓에
전화번호와 이메일이 마스킹 없이 들어 있었다.

누가 이 테이블을 조회할 수 있는지도
정리된 적이 없다.

16장에서 누가 무엇을 책임지는지 정했다.

그 정보가 있어야 보호도 할 수 있다.

이 장에서는 데이터를 실제로 지키는 방법을 다룬다.

분류와 라벨, 접근 제어 모델, 행과 열 단위 통제,
그리고 API와 이벤트 각각의 보안이다.

1. 데이터 보안

이제 거버넌스를 통해

데이터가 무엇인지

누가 책임지는지

얼마나 중요한지

왜 사용하는지

알게 되었다.

이 정보를 바탕으로
실제 보호 조치를 적용할 수 있다.

보호 대상은 다양하다.

개인정보

금융정보

건강정보

기업 기밀

지적재산

등이 있다.

2. 데이터 중심 보안

기존 보안은 주로

네트워크

서버

애플리케이션

방화벽

같은 시스템 경계를 보호하는 데 집중했다.

하지만 현대 시스템에서 데이터는

DB
S3
Kafka
DW
API
SaaS

등 여러 환경으로 이동한다.

그래서 데이터가 어디에 있든
데이터 자체의 중요도를 기준으로 보호하는

Data-Centric Security

관점이 중요해졌다.

3. 신뢰 경계

Trust Boundary는

같은 신뢰 수준과 보안 규칙이 적용되는 영역의 경계

라고 이해하면 된다.

예를 들어 커머스 도메인 내부에서 사용되던 데이터가

flowchart LR
    n0["커머스"] --> n1["마케팅"]

으로 전달되는 순간,

사용 목적과 사용자가 달라질 수 있다.

따라서 경계를 넘을 때는

누가 사용하는가?

어떤 목적인가?

어떤 데이터가 필요한가?

민감한 정보가 포함되어 있는가?

를 다시 확인할 필요가 있다.

4. 데이터 분류

Data Classification은

데이터의 중요도와 민감도를 구분하는 것

이다.

예를 들어 조직에서 다음과 같이 정할 수 있다.

Public
공개 가능

General
일반 내부 데이터

Confidential
기밀

Highly Confidential
매우 민감한 데이터

명칭과 단계는 회사마다 달라질 수 있다.

5. 분류가 필요한 이유

회사 홈페이지의 공개 공지와
고객의 신용카드 정보를

같은 수준으로 보호할 필요는 없다.

• 공개 정보 — 낮은 보호 수준
• 신용카드 정보 — 높은 보호 수준

즉,

flowchart LR
    n0["데이터 중요도"] --> n1["적절한 보호 수준"]

을 결정하기 위해 분류가 필요하다.

6. 데이터 라벨

분류 결과를 실제 데이터에 표시하는 것을
라벨링이라고 생각할 수 있다.

예를 들어

credit_card_number

Classification
→ Highly Confidential

이라는 메타데이터를 붙인다.

시스템은 이 라벨을 보고

마스킹

암호화

접근 제한

감사 강화

같은 정책을 적용할 수 있다.

7. 데이터 사용 목적도 분류할 수 있다

데이터 자체의 민감도뿐 아니라
어떤 목적으로 사용되는지도 분류할 수 있다.

예를 들어

• DATA_SCIENCE — 분석과 연구
• AD_HOC_USAGE — 일회성 분석
• HR_ONLY — 인사 업무
• FINANCIAL_REPORTING — 재무 보고
• DQ_INVESTIGATION — 데이터 품질 조사

처럼 정의할 수 있다.

따라서 같은 데이터라도

HR 업무에는 허용

마케팅에는 금지

처럼 다른 정책을 적용할 수 있다.

8. 인증과 권한은 다르다

무엇을 얼마나 지켜야 하는지는 정했다.
다음은 누구에게 열어 줄 것인가다.

그 전에 자주 섞여 쓰이는 두 낱말부터 구분하자.

Authentication은

누구인가?

를 확인한다.

Authorization은

무엇을 할 수 있는가?

를 결정한다.

따라서

로그인 성공

했다고 해서

모든 데이터 접근 가능

이라는 뜻은 아니다.

9. 접근 제어

Access Control은

누가 어떤 데이터에
어떤 행동을 할 수 있는지 결정하는 것

이다.

대표적으로

ACL

RBAC

ABAC

같은 모델이 있다.

10. ACL

ACL은 Access Control List의 약자다.

대상마다

누가 무엇을 할 수 있는가

를 목록으로 관리한다.

예를 들어

문서 A

사용자 A
→ 읽기

사용자 B
→ 읽기 / 쓰기

사용자 C
→ 접근 불가

와 같은 방식이다.

세밀하게 설정할 수 있지만
사용자와 대상이 많아지면 관리가 복잡해질 수 있다.

11. RBAC

RBAC는 Role-Based Access Control이다.

사용자 개인에게 직접 권한을 주기보다
역할(Role)에 권한을 부여한다.

flowchart LR
    n0["사용자 A"] --> n1["HR 역할"] --> n2["직원 정보 조회 권한"]

예를 들어

• HR — 직원 정보 조회
• Finance — 재무 데이터 조회
• Developer — 개발 환경 접근

처럼 정의한다.

기업 시스템에서 널리 사용되는 접근 방식이다.

12. RBAC의 한계

조직이 커지면 역할이 지나치게 많아질 수 있다.

HR

HR 관리자

HR 조회 전용

서울 HR

부산 HR

채용 HR

처럼 역할을 계속 만들게 된다.

이를 Role Explosion 문제라고 한다.

또한 RBAC만으로는

접속 시간

접속 위치

사용 기기

데이터 민감도

같은 동적인 조건을 표현하기 불편할 수 있다.

13. ABAC

ABAC는 Attribute-Based Access Control이다.

역할 하나만 보는 것이 아니라
여러 속성을 조합해서 접근 여부를 판단한다.

예를 들어

사용자 부서 = HR

AND

데이터 분류 = Confidential

AND

관리되는 회사 기기 = true

이면 접근을 허용하는 식이다.

NIST가 설명하는 ABAC 역시
Subject, Object, Action, Environment 등의 속성과
정책을 기반으로 접근 결정을 내리는 방식이다.

14. 정책을 누가 정하고, 누가 판단하고, 누가 막는가

ABAC처럼 조건이 여러 개가 되면 규칙 자체가 복잡해진다.

그 규칙을 서비스 코드 안에 직접 박아 두면
같은 규칙이 여러 곳에 흩어지고, 바꿀 때마다 전부 찾아다녀야 한다.

그래서 보통 세 가지 일을 서로 다른 자리에 맡긴다.

• 규칙을 정하는 자리
• 규칙으로 판단하는 자리
• 판단 결과를 집행하는 자리

사용자가 민감한 HR 데이터를 요청했다고 하자.
요청 하나가 이렇게 흘러간다.

flowchart LR
    REQ["사용자 요청"]
    PEP["PEP<br/>요청을 가로막고<br/>결정을 적용한다"]
    PDP["PDP<br/>정책을 평가해<br/>결정한다"]
    PIP["PIP<br/>──────────<br/>사용자 부서 · 데이터 분류<br/>접속 위치 · 기기 정보"]
    PAP["PAP<br/>정책을 작성하고<br/>관리한다"]

    REQ --> PEP
    PEP -- "① 이 요청 허용해도 되나?" --> PDP
    PDP -- "② 판단에 쓸 속성 조회" --> PIP
    PIP -- "③ 속성 값" --> PDP
    PAP -. "정책" .-> PDP
    PDP -- "④ ALLOW / DENY" --> PEP

    style PDP fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a
    style PEP fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a
    style PIP fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style PAP fill:#fafafa,stroke:#bbb,color:#1a1a1a

네 자리에는 각각 이름이 붙어 있다.

판단 재료는 어디에서 오는가

PIP가 가져오는 속성은 사용자 쪽에만 있는 것이 아니다.

앞에서 데이터에 붙여 둔 분류 라벨과
16장에서 본 Data Contract의 사용 목적도
그대로 판단 재료가 된다.

flowchart LR
    IDP["IdP<br/>부서 · 직급 · 그룹"]
    CAT["데이터 카탈로그<br/>분류 라벨"]
    CON["Data Contract<br/>허용된 사용 목적"]
    PIP2["PIP"]
    PDP2["PDP<br/>판단"]

    IDP --> PIP2
    CAT --> PIP2
    CON --> PIP2
    PIP2 --> PDP2

    style PDP2 fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a
    style PIP2 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style IDP fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style CAT fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style CON fill:#fafafa,stroke:#bbb,color:#1a1a1a

그래서 데이터를 분류해 두는 일이 문서 작업으로 끝나지 않는다.
분류가 곧 정책의 입력이 된다.

그럼 게이트웨이에서 다 막으면 되지 않나

자연스럽게 드는 생각이다.
서비스마다 조건문을 쓰지 말고 API Gateway 한곳에서 검사하면 되지 않을까.

절반은 맞다. Gateway는 대표적인 PEP다.

다만 두 가지를 구분해야 한다.

첫째, 막는 자리를 옮기는 것과 규칙을 한곳에 두는 것은 다른 문제다.

조건문을 각 서비스에서 Gateway로 옮기기만 하면
규칙은 여전히 코드 안에 있다.
흩어져 있던 것이 한 덩어리가 됐을 뿐,
정책을 바꿀 때마다 Gateway를 고쳐서 배포해야 한다.

PDP를 따로 두는 이유가 여기에 있다.
규칙을 코드가 아니라 정책 데이터로 관리하면
막는 쪽을 건드리지 않고 규칙만 바꿀 수 있다.

둘째, Gateway가 판단할 수 없는 것이 있다.

GET /orders를 호출해도 되는지는 Gateway가 판단할 수 있다.

하지만 그 결과에서

어느 행을 보여줄 것인가
전화번호 컬럼을 가릴 것인가

는 데이터가 있는 곳에서만 정할 수 있다.
Gateway는 아직 결과를 보지 못했기 때문이다.

그래서 PEP는 보통 한 군데가 아니다.

flowchart LR
    U["요청"]
    GW["API Gateway<br/>PEP ①<br/>──────────<br/>이 API를 불러도 되나"]
    SVC["서비스 · DB<br/>PEP ②<br/>──────────<br/>어느 행을 보여줄까<br/>어느 컬럼을 가릴까"]
    PDP3["PDP<br/>정책은 한곳에"]

    U --> GW --> SVC
    GW -. "판단 요청" .-> PDP3
    SVC -. "판단 요청" .-> PDP3

    style GW fill:#f2fbf4,stroke:#4caf50,color:#1a1a1a
    style SVC fill:#f2fbf4,stroke:#4caf50,color:#1a1a1a
    style PDP3 fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a

행과 열 단위로 좁히는 방법은 이 장 뒤쪽에서 따로 다룬다.

이름보다 중요한 것

중요한 것은 약어가 아니라 역할이 나뉘어 있다는 점이다.

막는 쪽(PEP)과 판단하는 쪽(PDP)이 분리되어 있으므로
정책이 바뀌어도 각 서비스의 코드를 고칠 필요가 없다.

한 가지 덧붙이면, 이 네 이름은
ABAC의 필수 구성요소는 아니다.

XACML 계열을 포함한 정책 기반 접근 제어 아키텍처에서
널리 쓰이는 역할 구분이라고 이해하는 편이 정확하다.

15. 이 사용자가 누구인지 어떻게 아는가

RBAC든 ABAC든 판단의 출발점은 같다.

이 사용자가 누구인가

이걸 모르면 역할도 속성도 확인할 수 없다.

이 일을 맡는 시스템을 Identity Provider(IdP) 라고 부른다.

IdP는 보통 다음과 같은 신원 정보를 제공한다.

사용자 ID
부서
직급
그룹
역할

앞 절에서 PDP가 판단에 쓰려고 PIP에 조회하던 사용자 속성이
대개 여기에서 온다.

서비스마다 로그인하게 할 수는 없다

회사에 서비스가 열 개라고 해서
사용자를 열 번 로그인시킬 수는 없다.

한 번 인증한 사용자가 여러 서비스를 그대로 쓰게 해주는 것이
SSO(Single Sign-On) 다.

SSO를 실제로 구현하는 규약은 여러 가지다.

OAuth와 OpenID Connect는 다르다

이 둘은 자주 섞여 쓰이는데 하는 일이 다르다.

즉 OAuth 자체는 “이 사용자가 누구인가“에 답하는 기술이 아니다.

OAuth = 로그인 기술

이라고만 이해하면 부정확하다.

앞에서 본 인증과 권한의 구분이 여기에도 그대로 적용된다.

16. 데이터 제품마다 보안을 새로 만들 것인가

앞에서 PEP가 한 군데가 아니라고 했다.

데이터 프로덕트에서도 같은 문제가 생긴다.

주문·회원·정산 데이터 프로덕트가 각각 있다면
셋 모두 누가 어디까지 볼 수 있는지 판단하고 적용해야 한다.

이걸 데이터 프로덕트마다 직접 구현하면
프로덕트가 열 개일 때 보안 코드도 열 벌이 된다.

비용도 문제지만 더 큰 문제가 있다.
팀마다 마스킹 방식이 달라지고 감사 로그 형식도 달라진다.
어디가 어떻게 막혀 있는지 아무도 전체를 알지 못하게 된다.

그래서 보안을 데이터 프로덕트 본체에서 떼어낸다.

flowchart LR
    subgraph BAD["각자 구현하면"]
        B1["주문 DP<br/>+ 보안 코드"]
        B2["회원 DP<br/>+ 보안 코드"]
        B3["정산 DP<br/>+ 보안 코드"]
    end

    subgraph GOOD["공통으로 제공하면"]
        G1["주문 DP"]
        G2["회원 DP"]
        G3["정산 DP"]
        SEC["공통 보안 계층<br/>──────────<br/>마스킹 · 필터링<br/>접근 판단 · 감사"]
        G1 --> SEC
        G2 --> SEC
        G3 --> SEC
    end

    style BAD fill:#fff4f4,stroke:#d9534f,color:#1a1a1a
    style GOOD fill:#f2fbf4,stroke:#4caf50,color:#1a1a1a
    style SEC fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a

떼어내는 방법은 여러 가지다.

• 플랫폼이 제공하는 공통 컴포넌트를 거쳐 데이터를 내보낸다
• 데이터 프로덕트 옆에 보안 처리를 맡는 별도 프로세스를 붙인다 (사이드카)
• 저장소 자체의 행·열 단위 통제 기능을 쓴다

사이드카는 그중 한 가지 구현 패턴이지
반드시 써야 하는 표준은 아니다.

14장에서 본 셀프서비스 플랫폼과 같은 생각이다.
플랫폼이 보안을 기본으로 딸려 보내면
각 도메인이 애써 지키지 않아도 지켜진다.

17. 소비자마다 다른 데이터를 보여주기

같은 데이터셋이라고 해서
모든 사용자에게 모든 컬럼을 보여줄 필요는 없다.

예를 들어 고객 데이터가

이름

이메일

전화번호

주소

결제정보

를 가지고 있다고 하자.

마케팅팀에는

이름

이메일

지역

정도만 제공하고,

정산팀에는

회원 ID

결제 관련 정보

만 제공할 수 있다.

18. 데이터를 보호하는 방법

상황에 따라 다양한 기법을 사용할 수 있다.

• Filtering — 필요 없는 데이터 제외
• Masking — 민감한 값을 일부 숨김
• Tokenization — 실제 값을 다른 토큰으로 치환
• De-identification — 개인을 직접 식별하기 어렵게 처리

각 방식의 법적·보안적 효과는 다를 수 있으므로
사용 목적에 맞는 방법을 선택해야 한다.

19. Row-Level Security

RLS는 행 단위 접근 제어다.

예를 들어 영업 담당자가

SELECT *
FROM sales;

를 실행해도,

실제 결과는 해당 담당 지역 데이터만
보이도록 제한할 수 있다.

개념적으로는

• 사용자 A — 부산 지역 데이터만
• 사용자 B — 서울 지역 데이터만

처럼 동작한다.

20. Column-Level Security

CLS는 컬럼 단위 접근 제어다.

예를 들어

user_id
nickname
phone
resident_number

가 있을 때,

일반 직원에게는

user_id
nickname

만 보이고,

민감한 컬럼은 숨길 수 있다.

21. 도메인 내부와 도메인 간 보안

상황에 따라 도메인 내부 보안과
도메인 간 보안을 다르게 설계할 수 있다.

도메인 내부에서는

개발자
운영자
관리자

처럼 세밀한 권한을 관리한다.

반면

flowchart LR
    n0["커머스"] --> n1["마케팅"]

처럼 도메인 경계를 넘는 데이터 공유에는

Data Contract

Usage Agreement

공통 보안 정책

같은 좀 더 명시적인 약속을 적용할 수 있다.

22. API에서는 보안 정보를 어떻게 넘기나

앞에서 Gateway가 문 앞의 PEP가 된다고 했다.

API 환경에서 Gateway는 보통 이런 일을 맡는다.

인증
Access Token 검증
Rate Limit
접근 정책 적용
감사 로그

문제는 그다음이다.

Gateway를 통과한 요청이 Provider에 도착했을 때,
Provider는 이 요청이 누구 것이고 어떤 목적인지 모른다.

그런데 Provider도 PEP다.
어느 행을 보여줄지, 어느 컬럼을 가릴지는 여기서 정해야 한다.

판단하려면 재료가 필요하다.

사용자 ID와 역할만으로는 부족하다

주문 API라면 이런 정보까지 있어야 판단할 수 있다.

user_id
role
customer_id
department
delegation
purpose

이렇게 판단에 필요한 정보 묶음을
Security Context라고 부른다.

누가 Context를 만드나

두 가지 방식이 있다.

flowchart LR
    GW["API Gateway"]
    SRC["IdP · 권한 시스템<br/>고객 시스템"]
    PRV["API Provider"]

    GW -- "① 조회해서 Context를 만들고" --> SRC
    SRC --> GW
    GW -- "요청 + Context" --> PRV
    PRV -. "② 또는 Provider가 직접 조회" .-> SRC

    style GW fill:#f2fbf4,stroke:#4caf50,color:#1a1a1a
    style PRV fill:#f2fbf4,stroke:#4caf50,color:#1a1a1a
    style SRC fill:#fafafa,stroke:#bbb,color:#1a1a1a

어느 쪽이든, 문 앞에서 한 번 막았다고 끝이 아니라
안쪽에서도 판단할 재료가 있어야 한다는 점은 같다.

23. 이벤트 기반 아키텍처의 보안

API는 요청이 들어올 때 막으면 된다.

이벤트는 다르다.

flowchart LR
    P["Producer"] --> BRK["Event Broker"]
    BRK --> C1["Consumer A"]
    BRK --> C2["Consumer B"]
    BRK --> C3["Consumer C"]

    style BRK fill:#fafafa,stroke:#bbb,color:#1a1a1a

한 번 발행하면 여러 소비자에게 전달되고,
발행하는 쪽은 앞으로 누가 이 이벤트를 받을지 모른다.

브로커 권한으로 되는 것과 안 되는 것

Kafka는 리소스 단위의 ACL로 권한을 제어할 수 있다.
“이 컨슈머가 이 토픽을 구독해도 되나“까지는 여기서 정한다.

토픽 접근은 전부 아니면 전무다.
구독 권한을 준 순간 그 토픽의 모든 메시지, 모든 필드가 넘어간다.

Kafka 생태계의 상용 제품에서는 RBAC 같은 기능도 제공하므로
“Kafka는 ACL만 된다“고 단정할 필요는 없다.
다만 어느 쪽이든 메시지 내부의 필드 단위 통제는 별개의 문제다.

그럼 어떻게 하나

세 가지 방법이 있다.

하나. 애초에 민감한 값을 담지 않는다.

이벤트에는 식별자만 싣고, 필요한 쪽이 API로 조회하게 한다.
가장 단순하지만 조회가 늘어나고, 실시간성이 떨어질 수 있다.

둘. 소비자별로 이벤트를 따로 만든다.

원본 고객 이벤트가 이렇다고 하자.

user_id
email
purchase_amount

이것을 정책에 따라 변환해서 소비자마다 다른 이벤트를 내보낸다.

flowchart LR
    SRC["원본 Event<br/>──────────<br/>user_id · email<br/>purchase_amount"]
    POL["정책에 따른 변환"]
    M["마케팅용<br/>──────────<br/>email<br/>purchase_amount"]
    A["통계용<br/>──────────<br/>익명 user_id<br/>purchase_amount"]

    SRC --> POL
    POL --> M
    POL --> A

    style POL fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a
    style SRC fill:#fafafa,stroke:#bbb,color:#1a1a1a

소비자별로 토픽이 나뉘므로
브로커의 구독 권한만으로 통제가 된다는 것이 장점이다.

다만 토픽과 변환 파이프라인이 늘어나 운영 복잡도가 올라간다.

셋. 소비자 쪽에서 걸러 쓰게 한다.

가장 쉽지만 가장 약하다.
소비자가 규칙을 지킨다고 믿어야 하기 때문이다.

신뢰 경계 안쪽에서만 쓸 만한 방법이다.

앞에서 본 공통 보안 계층을 여기에 두면
변환 규칙을 소비자마다 따로 만들지 않아도 된다.

24. 데이터를 결합하면 보안 책임도 따라온다

예를 들어

회원 데이터
Confidential

+

결제 데이터
Highly Confidential

를 합쳐 새로운 데이터 제품을 만들었다고 하자.

새로운 데이터라고 해서
기존 데이터의 민감도가 사라지는 것은 아니다.

따라서 데이터가 변환되거나 결합되더라도

출처

분류

소유권

사용 제한

같은 정보를 추적할 필요가 있다.

이 때문에 메타데이터와 Lineage가 중요하다.

25. 개인정보와 데이터 윤리

데이터가 많아지고
여러 곳으로 복제될수록
개인정보 보호도 어려워진다.

운영 DB

Kafka

S3

Data Warehouse

Feature Store

ML Dataset

사용자가 개인정보 삭제를 요청했는데
운영 DB만 삭제했다고 끝나는 문제가 아닐 수 있다.

어떤 데이터가 어디에 존재하고
어디까지 전달되었는지 알아야 한다.

AI 활용이 증가하면서
질문은 더욱 넓어진다.

어떤 데이터를 수집했는가?

왜 수집했는가?

어떤 데이터와 결합했는가?

AI 모델에서 어떻게 사용했는가?

모델의 결과가 사람에게 어떤 영향을 미치는가?

데이터의 정확성뿐 아니라
데이터 사용 방식의 적절성도 중요해지는 것이다.

현대의 데이터 거버넌스는
품질과 보안을 넘어

개인정보, 윤리, 투명성, 규제 준수까지
함께 고려해야 한다.

26. 17장 정리

이 장의 흐름을 한 장으로 보면 다음과 같다.

flowchart TB
    C1["분류한다<br/>──────────<br/>데이터의 민감도와 사용 목적을 나누고<br/>라벨로 표시한다"]
    C2["정책을 만든다<br/>──────────<br/>ACL · RBAC · ABAC 중<br/>상황에 맞는 모델을 고른다"]
    C3["집행한다<br/>──────────<br/>PEP가 막고 PDP가 판단한다<br/>정책은 한곳에서 관리한다"]
    C4["데이터 단위로 좁힌다<br/>──────────<br/>Filtering · Masking · RLS · CLS로<br/>소비자마다 보이는 범위를 다르게 한다"]
    C5["경로마다 적용한다<br/>──────────<br/>API는 Gateway에서<br/>이벤트는 소비자별 변환으로"]

    C1 --> C2 --> C3 --> C4 --> C5

    style C1 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style C2 fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style C3 fill:#f8fbff,stroke:#4a90e2,color:#1a1a1a
    style C4 fill:#f8fbff,stroke:#4a90e2,color:#1a1a1a
    style C5 fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a

네 가지만 기억하면 된다.

보안은 데이터를 이해한 다음에 온다.
무엇이고 누가 책임지고 얼마나 민감한지 모르면
무엇을 어느 수준으로 지켜야 할지도 정할 수 없다.
16장에서 정한 책임과 정의가 여기서 재료가 된다.

인증과 권한은 다른 문제다.
로그인에 성공했다는 것이 모든 데이터를 봐도 된다는 뜻은 아니다.

막는 방식은 전부 아니면 전무가 아니다.
Filtering, Masking, RLS, CLS로
같은 데이터셋에서 소비자마다 다른 범위를 보여줄 수 있다.

데이터를 결합해도 민감도는 사라지지 않는다.
그래서 출처와 분류를 따라갈 수 있어야 하고,
메타데이터와 계보가 여기서도 필요하다.

좋은 보안의 목적은 데이터를 막는 것이 아니라,
믿을 수 있는 데이터를 필요한 사람이
허용된 목적과 범위 안에서 안전하게 쓰게 만드는 것이다.

다음 장에서는 여러 도메인이 함께 쓰는
회원·상품 같은 기준 데이터를 어떻게 관리할지 본다.

이 장에서 나온 용어는 부록 C 「용어집」의
「보안」 항목에 정리해 두었다.

18장. 마스터 데이터 관리

5부 · 신뢰 — 찾고, 믿고, 안전하게 쓰려면
15장 · 16장 · 17장 · 18장

회사가 작고 시스템이 몇 개 없을 때는
데이터를 일관되게 관리하기 어렵지 않다.

하지만 회사가 성장하면 회원, 결제, CRM, 상품, 정산,
분석 시스템처럼 여러 시스템이 생긴다.

그러면 자연스럽게 같은 고객이나 상품 정보가
여러 시스템에 중복해서 저장된다.

문제는 시간이 지나면서
각 시스템의 데이터가 조금씩 달라진다는 것이다.

회원 시스템
홍길동 / 010-1234-5678

CRM
홍 길동 / 01012345678

결제 시스템
홍길동 / 010-9999-9999

사람이 보면 같은 고객일 가능성이 높다.

하지만 시스템 입장에서는
서로 다른 고객으로 판단할 수도 있다.

이런 문제를 해결하기 위한 체계가

마스터 데이터 관리
MDM, Master Data Management

이다.

이번 장에서는 MDM이 무엇인지부터 시작해서
도메인 중심의 현대적인 데이터 아키텍처에서
MDM을 어떻게 적용해야 하는지 살펴본다.

1. 마스터 데이터란 무엇인가