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는 지금도 유용하다.
다만 조직 규모와 데이터 복잡성이 커지면
중앙집중적인 운영 모델이 병목이 될 수 있다.

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

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

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