21장. 도메인 토폴로지

7부 · 실행 — 어디서부터 시작하는가
21장 · 22장 · 23장

앞 장까지는 데이터 도메인이 무엇인지,
그리고 비즈니스를 어떤 기준으로 나눠야 하는지를 살펴봤다.

이제 다음 단계로 넘어가야 한다.

회원
결제
배송
주문
정산

이렇게 도메인을 나눴다고 해서
아키텍처 설계가 끝난 것은 아니다.

실제 시스템을 만들려면 다음과 같은 질문에
답해야 한다.

각 도메인의 데이터는 누가 관리할까?

다른 도메인의 데이터는 어떻게 사용할까?

도메인끼리 직접 연결할까?

중앙 데이터 플랫폼을 둘까?

어떤 기능을 공통으로 제공할까?

클라우드에서는 각 도메인을 어디에 배치할까?

이 장이 답하는 것은 앞쪽 질문들이다.

도메인들을 어떻게 연결하고 운영할 것인가

마지막 질문, 즉 이 구조를 실제 클라우드에 어떻게 배치하는지는
부록 A 「클라우드 랜딩 존과 Blueprint」에서 따로 다룬다.

1. 도메인 토폴로지란 무엇인가

토폴로지(Topology)는 어렵게 생각할 필요가 없다.

쉽게 말하면

구성 요소들이 어디에 있고,
서로 어떻게 연결되어 있는지를 나타내는 구조

다.

예를 들어 회사에 다음과 같은 도메인이 있다고 하자.

회원
결제
배송
주문
정산

도메인을 나눈 뒤에는
이들의 관계를 정해야 한다.

예를 들어 주문 도메인은
회원 정보가 필요할 수 있다.

정산 도메인은
주문 결과를 필요로 할 수 있다.

flowchart LR
    n0["회원"] --> n1["주문"] --> n2["정산"]

그렇다면 다음을 결정해야 한다.

주문이 회원 DB를 직접 조회할까?

회원 도메인이 API를 제공할까?

이벤트를 받을까?

중앙 데이터 플랫폼에서 가져올까?

이러한 관계를 설계하는 것이
도메인 토폴로지다.

2. 먼저 알아야 할 것: 정답은 하나가 아니다

도메인 아키텍처에는
모든 회사에 적용되는 하나의 정답이 없다.

어떤 조직은 빠른 개발과
팀의 자율성을 중요하게 생각한다.

각 팀이 기술을 선택

각 팀이 직접 운영

각 팀이 빠르게 변경

반대로 어떤 조직은

보안

데이터 품질

규제 준수

감사

표준화

를 더 중요하게 생각할 수 있다.

따라서 아키텍처를 설계한다는 것은
결국 여러 요소 사이에서 균형점을 찾는 일이다.

3. 데이터 제품이란 무엇인가

도메인 구조를 이해하려면
먼저 데이터 제품(Data Product) 개념이 필요하다.

6장에서 본 것처럼 데이터 제품은
DB 테이블이나 파일 하나를 뜻하지 않는다.

다른 사람이 신뢰하고 사용할 수 있도록
의미·품질·소유자·접근 방법까지 함께 관리한 데이터다.

무엇을 갖춰야 데이터 제품이라고 부를 수 있는지는
13장에서 다뤘다.

이 장에서는 데이터 제품을
도메인이 외부에 내놓는 단위 정도로 생각하면 충분하다.

4. 데이터 메시와 도메인 소유권

데이터 메시(Data Mesh)를 이야기할 때
가장 중요한 개념 중 하나가

도메인 중심 데이터 소유권이다.

기존에는 이런 구조가 많았다.

flowchart LR
    hub["중앙 데이터팀"]
    s0["회원 데이터"] --> hub
    s1["결제 데이터"] --> hub
    s2["주문 데이터"] --> hub
    s3["배송 데이터"] --> hub
    s4["정산 데이터"] --> hub

모든 데이터를 중앙 데이터팀이 관리한다.

문제는 중앙 데이터팀이
모든 비즈니스 의미를 정확히 알기 어렵다는 것이다.

예를 들어 주문 데이터는
주문 서비스를 만드는 팀이 가장 잘 이해한다.

그래서 데이터 메시에서는

회원 데이터 → 회원 도메인

결제 데이터 → 결제 도메인

주문 데이터 → 주문 도메인

처럼 데이터의 비즈니스 책임을
해당 도메인에 가깝게 둔다.

5. 데이터 메시의 핵심 원칙

데이터 메시의 핵심은
특정 네트워크 구조나 특정 제품이 아니다.

3장에서 본 네 가지 원칙,
즉 도메인 소유권·데이터 제품·셀프서비스 플랫폼·연합형 거버넌스가
함께 있어야 한다.

따라서

데이터 메시
= 모든 것을 완전히 분산

이라고 이해하면 안 된다.

공통 플랫폼이나 중앙 인프라도 충분히 사용할 수 있다.

6. 도메인 토폴로지 패턴

이제 여러 가지 도메인 구조를 살펴보자.

여기서 중요한 주의사항이 있다.

앞으로 나오는

완전 연합형

거버넌스 기반

부분 연합형

가치 사슬 정렬형

큰 단위 도메인

중앙집중형

같은 이름은

데이터 아키텍처 업계에서 반드시 따라야 하는
공식 표준 분류

라고 생각하면 안 된다.

조직의 중앙화와 분산 정도를 이해하기 위한
대표적인 설계 패턴으로 보는 것이 좋다.

7. 완전 연합형 도메인 토폴로지

가장 분산된 구조부터 살펴보자.

완전 연합형에서는
각 도메인이 자신의 데이터를 직접 책임진다.

flowchart LR
    m["회원 도메인"] --> mp["회원 데이터 제품"]
    p["결제 도메인"] --> pp["결제 데이터 제품"]
    o["주문 도메인"] --> op["주문 데이터 제품"]
    s["정산 도메인"] --> sp["정산 데이터 제품"]

각 도메인은 상당한 자율성을 가진다.

예를 들어

데이터 구조

품질 기준

데이터 제품

배포 방식

기술 선택

을 자체적으로 결정할 수 있다.

8. 완전 연합형의 장점

가장 큰 장점은
도메인의 자율성이다.

주문 데이터를 가장 잘 이해하는 사람이
주문 도메인 개발자라면,

주문 데이터에 대한 중요한 판단도
그 팀이 하는 것이 자연스럽다.

중앙팀에게 매번 요청하지 않아도 되므로

변경 속도 ↑

도메인 전문성 ↑

자율성 ↑

을 기대할 수 있다.

9. 자율성이 ’마음대로’를 의미하지는 않는다

도메인이 자율적으로 운영된다고 해서

각 팀 마음대로 하면 된다

는 뜻은 아니다.

조직 전체에서 반드시 지켜야 하는
공통 규칙은 존재한다.

예를 들면

개인정보 정책

접근 권한 규칙

보안 정책

메타데이터 규칙

데이터 표준

등이다.

따라서 이상적인 형태는

• 도메인 내부의 세부 구현 — 도메인이 결정
• 회사 공통 원칙 — 모두 준수

다.

이를 연합형 거버넌스 관점으로
이해하면 된다.

10. Peer-to-Peer는 하나의 방식일 뿐이다

완전 분산된 구조에서는
도메인들이 직접 데이터를 주고받을 수도 있다.

회원 ↔ 결제

회원 ↔ 주문

주문 ↔ 배송

주문 ↔ 정산

이런 방식을 Peer-to-Peer라고 생각할 수 있다.

하지만 중요한 점이 있다.

데이터 메시가 Peer-to-Peer 구조를
반드시 요구하는 것은 아니다.

도메인들은 공통 플랫폼이나
이벤트 플랫폼 등을 통해 연결될 수도 있다.

Peer-to-Peer는
가능한 연결 방식 중 하나일 뿐이다.

11. 완전 연합형이 어려운 이유

완전 연합형은 매력적이지만
실제로 운영하려면 조직의 성숙도가 높아야 한다.

도메인이 늘면 연결이 기하급수로 는다

도메인이 서넛이라면 직접 연결도 문제가 아니다.

하지만 수십 개가 되면 관리할 것이 함께 늘어난다.

네트워크
인증
권한
API 버전
이벤트 스키마
장애 대응
데이터 계약

도메인 자율성은 올라가지만 전체 복잡도도 같이 올라간다.

표준이 없으면 통합이 안 된다

같은 회원 ID를 도메인마다 다르게 부를 수 있다.

user_id
member_id
member_no
customer_seq

시간 표현도 제각각이 된다.

2026-09-15
20260915
2026-09-15T10:30:00+09:00

이런 차이가 쌓이면 나중에 데이터를 합칠 수 없다.

도메인마다 데이터 역량이 필요하다

각 도메인이 데이터 제품까지 직접 운영하려면
서비스 개발 능력만으로는 부족하다.

데이터 모델링
파이프라인 구축과 운영
품질 관리
메타데이터 관리
보안과 접근 제어

모든 팀이 이것을 갖추기는 어렵다.

그래서 다음에 볼 구조들이 나온다.
중앙이 무엇을 대신해 줄 것인가의 문제다.

12. 거버넌스 기반 도메인 토폴로지

완전 연합형의 복잡도를 줄이기 위해
중앙 기능을 일부 도입할 수 있다.

핵심 개념은 다음과 같다.

데이터의 비즈니스 책임은 도메인에 두면서,
공통 배포와 거버넌스 기능만 중앙에서 제공한다.

flowchart LR
    subgraph OWN["도메인이 데이터 제품까지 책임진다"]
        M["회원<br/>+ 회원 데이터 제품"]
        P["결제<br/>+ 결제 데이터 제품"]
        O["주문<br/>+ 주문 데이터 제품"]
    end

    HUB["중앙 배포 계층<br/>──────────<br/>배포 경로 · 카탈로그<br/>표준 · 접근 제어"]

    M --> HUB
    P --> HUB
    O --> HUB
    HUB --> C["소비자"]

    style OWN fill:#f2fbf4,stroke:#4caf50,color:#1a1a1a
    style HUB fill:#f8fbff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a

여기서 중앙은 데이터를 만들지 않는다.

데이터 제품은 각 도메인이 만들고,
중앙은 그것이 지나가는 통로와 규칙을 제공한다.

13. 중앙 배포 계층

예를 들어 주문 데이터가

정산

추천

BI

통계

에서 필요하다고 하자.

직접 연결한다면

주문 → 정산

주문 → 추천

주문 → BI

주문 → 통계

가 된다.

중앙 배포 계층을 사용하면

flowchart LR
    o["주문"] --> c["중앙"]
    c --> a["정산"]
    c --> b["추천"]
    c --> d["BI"]
    c --> e["통계"]

처럼 만들 수 있다.

14. 중앙 계층에서 제공할 수 있는 기능

공통 계층에서는 다음과 같은 일을 할 수 있다.

스키마 검사

권한 검사

데이터 마스킹

데이터 라우팅

메타데이터 등록

품질 검사

감사 로그

이렇게 하면
모든 도메인이 동일한 기능을 다시 만들 필요가 없다.

15. 중앙화의 가장 큰 위험

중앙 기능이 많아지면
다시 중앙팀이 병목이 될 수 있다.

예를 들어

flowchart LR
    n0["도메인팀<br/>‘데이터 하나 추가해주세요’"] --> n2["중앙팀 검토"] --> n3["승인"] --> n4["배포"]

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

과정이 오래 걸리면
도메인의 자율성과 속도가 사라진다.

따라서 중앙 플랫폼의 이상적인 모습은

중앙팀이 직접 작업

X

중앙팀이 Self-Service 플랫폼 제공

O

에 가깝다.

16. 부분 연합형 도메인 토폴로지

현실에서는 모든 팀의 기술 수준이 같지 않다.

예를 들어

• 신규 서비스팀 — 클라우드 / 자동화에 익숙
• 레거시 서비스팀 — 기존 시스템 유지가 우선

일 수 있다.

이럴 때는 서로 다른 운영 방식을
함께 사용할 수 있다.

• 성숙한 도메인 — 높은 자율성
• 지원이 필요한 도메인 — 중앙 플랫폼 지원

이런 방식을 부분 연합형이라고 이해할 수 있다.

17. 부분 연합형의 위험

운영 방식이 섞이면
책임이 애매해질 수 있다.

예를 들어

• 원본 데이터 — 도메인 팀
• 데이터 제품 — 중앙 데이터팀

이라고 하자.

데이터가 잘못됐을 때

도메인팀
"우리가 준 데이터는 정상입니다."

중앙팀
"원본부터 이상했습니다."

라는 문제가 생길 수 있다.

따라서

누가 무엇을 책임하는지

명확하게 정의해야 한다.

18. 가치 사슬 정렬 도메인 토폴로지

도메인을 개별 기능으로만 보지 않고
하나의 비즈니스 가치 흐름으로 묶는 방식이다.

가치 사슬(Value Chain)은

고객에게 하나의 가치를 제공하기 위해
여러 업무가 이어지는 흐름

이다.

쇼핑몰이라면 이런 흐름이 하나의 가치 사슬이다.

flowchart LR
    P["상품"] --> O["주문"] --> PAY["결제"] --> D["배송"] --> S["정산"]

왜 묶는가

같은 사슬 안의 도메인들은 함께 변하기 때문이다.

주문 흐름에 「부분 취소」를 넣는다고 하자.

상품 재고를 되돌려야 하고, 결제를 부분 환불해야 하고,
배송을 멈춰야 하고, 정산 금액을 다시 계산해야 한다.

네 도메인이 같이 움직인다.

이럴 때마다 도메인끼리 계약을 새로 협상하면
기능 하나 넣는 데 몇 달이 걸린다.

무엇을 같이 하는가

묶는다는 것은 경계의 무게를 두 단계로 두는 것이다.

여기서 오해하기 쉬운 점이 있다.

사슬 안이라고 해서 남의 테이블을 직접 조회해도 된다는 뜻은 아니다.

7장과 12장에서 본 원칙은 그대로다.
달라지는 것은 계약을 바꾸는 절차의 무게다.

밖에서는 사전 통보와 버전 관리가 필요하지만,
안에서는 관련 팀이 모여 합의하고 함께 배포할 수 있다.

19. 여러 사슬이 함께 쓰는 도메인은

모든 도메인이 하나의 사슬에만 속하지는 않는다.

대표적인 예가 회원이다.

flowchart LR
    M["회원"]
    M --> C["커머스 사슬"]
    M --> S["구독 사슬"]
    M --> A["광고 사슬"]

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

이런 도메인을 어느 한 사슬에 넣으면 문제가 생긴다.

커머스 사슬에 회원을 넣었다고 하자.

커머스 팀이 회원 스키마를 자기 편한 대로 바꾸기 시작하고,
구독과 광고는 매번 끌려다니게 된다.

그래서 이런 도메인은 어느 사슬에도 넣지 않는다.

• 독립된 공통 도메인으로 둔다
• 모든 사슬에 똑같이 엄격한 계약을 적용한다
• 특정 사슬에만 느슨하게 열어 주지 않는다

마지막 항목이 중요하다.
한 사슬에만 편의를 봐주는 순간 그 사슬에 종속된다.

회원이나 상품처럼 전사가 같은 의미로 써야 하는 데이터는
18장 「마스터 데이터 관리」에서 본 전사 기준 관리 대상이기도 하다.

20. 큰 단위로 나눈 도메인

오래된 대기업에서는
비즈니스 기준보다 기존 시스템이나 조직 기준으로
큰 덩어리가 만들어져 있는 경우가 많다.

예를 들어

한국 플랫폼

일본 플랫폼

광고 플랫폼

커머스 플랫폼

처럼 나뉘어 있을 수 있다.

각 플랫폼 안에는
수십~수백 개 시스템이 들어 있을 수 있다.

21. 큰 단위 도메인의 문제

가장 큰 문제는
비즈니스 경계와 시스템 경계가 일치하지 않는다는 것이다.

예를 들어

• 플랫폼 A — 회원 존재
• 플랫폼 B — 회원 존재
• 플랫폼 C — 회원 존재

라면 이런 문제가 생긴다.

누가 회원의 실제 소유자인가?

어느 회원 데이터가 기준인가?

회원 데이터 품질은 누가 책임지는가?

따라서

현재 시스템 구조가
반드시 올바른 도메인 구조인 것은 아니다.

22. 도메인은 비즈니스 기준으로 나눈다

다음과 같은 기준으로 도메인을 나누는 것은
조심해야 한다.

서버

DB

기존 애플리케이션

개발팀 이름

도메인의 가장 중요한 기준은

비즈니스 책임

비즈니스 능력

데이터 소유권

이다.

물론 현실에서는 조직과 시스템 구조도 고려하지만,
출발점은 비즈니스가 되어야 한다.

23. 공통으로 쓰는 핵심 데이터는 기준이 필요하다

도메인을 나누면 회원이나 상품처럼
여러 도메인이 함께 쓰는 데이터가 남는다.

이런 핵심 데이터를 일관된 기준으로 관리하는 체계를
MDM(Master Data Management) 이라고 한다.

시스템마다 같은 회원을 member_id, user_no, customer_seq로
다르게 부른다면 데이터를 맞추기 어렵다.
교환할 때 쓸 공통 표현을 정해 두기도 하는데
이를 Canonical Model이라고 부른다.

둘 다 18장 「마스터 데이터 관리」에서 자세히 다룬다.

여기서는 토폴로지를 정할 때
도메인에 맡길 데이터와 전사 기준이 필요한 데이터를
구분해야 한다는 점만 기억하면 된다.

24. 중앙집중형 도메인 토폴로지

이번에는 중앙화 정도가 가장 높은 구조다.

flowchart LR
    subgraph SRC["도메인은 원본만 넘긴다"]
        M["회원"]
        P["결제"]
        O["주문"]
    end

    HUB["중앙 데이터 플랫폼<br/>──────────<br/>저장 · 변환 · 품질<br/>메타데이터 · 카탈로그<br/>공통 분석까지"]

    M --> HUB
    P --> HUB
    O --> HUB
    HUB --> C["소비자"]

    style SRC fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style HUB fill:#fff4f4,stroke:#d9534f,stroke-width:3px,color:#1a1a1a

거버넌스 기반과 무엇이 다른가

그림이 비슷해 보이지만 결정적인 차이가 있다.

누가 데이터 제품을 만드는가다.

거버넌스 기반에서 중앙은 통로였다.

중앙집중형에서 중앙은 생산자다.
도메인은 원본을 넘기는 데서 역할이 끝난다.

25. 중앙집중형의 장점

각 팀이 같은 기능을
반복해서 만들지 않아도 된다.

예를 들어

Spark

Kafka

Airflow

데이터 카탈로그

데이터 품질 도구

를 각 팀이 하나씩 운영하기보다
공통 플랫폼으로 제공할 수 있다.

장점은

운영 비용 절감

기술 표준화

데이터 재사용

보안 관리 단순화

다.

26. 중앙집중형의 단점

중앙팀으로 일이 집중될 수 있다.

flowchart LR
    n0["데이터 변경 요청"] --> n1["중앙팀 대기"] --> n2["개발 지연"]

또한 조직 문화가

데이터 문제
= 중앙 데이터팀 문제

가 되어버릴 수도 있다.

그래서 다음과 같이 책임을 구분하는 것이 좋다.

• 공통 기술 플랫폼 — 플랫폼팀
• 데이터의 비즈니스 의미와 품질 — 도메인팀

27. 중앙화와 분산은 스펙트럼이다

중앙화와 분산을

중앙집중
VS
분산

으로만 보면 안 된다.

실제로는 그 사이에 많은 형태가 있다.

flowchart LR
    n0["완전 중앙집중"] --> n1["부분 중앙집중"] --> n2["거버넌스 기반"] --> n3["부분 연합"] --> n4["높은 연합"]

그리고 하나의 회사에서도
여러 형태를 동시에 사용할 수 있다.

예를 들면

• 규제 데이터 — 중앙 관리
• 추천 데이터 — 자율성 높음
• 레거시 — 중앙 지원
• 신규 플랫폼 — Self-Service

같은 형태다.

28. 도메인 크기를 어떻게 정하나

패턴을 골랐다면 남는 질문이 하나 있다.

도메인 하나를 얼마나 크게 잡을 것인가.

판단 기준은 4장 「좋은 경계의 원리」에서 본 것과 같다.
같이 변하는 것은 붙이고(높은 응집도),
남의 내부에 기대지 않는다(낮은 결합도).

여기서는 그 기준을 크기 문제에 적용해 보자.

너무 크면 사일로가 된다

모든 것을 하나에 넣으면

flowchart LR
    P["커머스 플랫폼"]
    P --> M["회원"]
    P --> O["주문"]
    P --> PAY["결제"]
    P --> D["배송"]
    P --> S["정산"]
    P --> A["광고"]

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

나눈 의미가 사라지고 다시 거대한 덩어리가 된다.

너무 작으면 통신이 비용이 된다

반대로 이렇게 쪼개면

회원 닉네임
회원 프로필
회원 설정
회원 등급
회원 인증

의존성과 통신이 지나치게 많아진다.

데이터 제품도 마찬가지다.

작게 나누면 독립성과 재사용성은 좋아지지만,
분석 하나를 하려고 회원·배송·주문·결제·정산 제품을
전부 찾아다녀야 한다면 소비자가 힘들어진다.

찾고, 권한 받고, 스키마 이해하고, 조인하고, 품질 확인하는
일이 제품 수만큼 늘어나기 때문이다.

기준은 크기가 아니다

도메인은 몇 개로 나눌지가 아니라
비즈니스 책임과 변경 단위로 정한다.

함께 바뀌는 것이 함께 있으면 크기는 따라온다.

29. 21장 정리

네 가지만 기억하면 된다.

중앙화와 분산은 양자택일이 아니라 스펙트럼이다.
완전 중앙집중과 완전 연합 사이에
여러 형태가 있다.

완전 연합형은 매력적이지만 높은 성숙도를 요구한다.
표준화, 자동화, 셀프서비스 플랫폼,
그리고 각 도메인의 데이터 역량이 함께 있어야 한다.

한 회사 안에서도 데이터마다 다른 방식을 쓸 수 있다.
규제 데이터는 중앙에서,
실험 성격의 데이터는 자율성 높게 운영하는 식이다.

도메인은 비즈니스 책임으로 나눈다.
서버, DB, 기존 애플리케이션, 팀 이름은
출발점이 되기 어렵다.

다음 장에서는 이 구조를 실제로 지탱하는
플랫폼과 조직을 본다.