중앙 집중식 데이터 레이크(Data Lake) 아키텍처는 규모가 커질수록 필연적인 병목 현상에 직면합니다. 데이터 생산자(Producer)와 소비자(Consumer) 사이의 결합도는 높아지고, 중앙 데이터 엔지니어링 팀은 비즈니스 도메인 지식의 부재 속에서 단순 ETL 파이프라인 유지보수에 매몰됩니다. 결과적으로 데이터 품질 저하, 스키마 변경에 따른 파이프라인 파손(Breakage), 그리고 데이터 활용까지의 긴 리드 타임(High Latency)이 발생합니다.
수천 개의 테이블이 하나의 S3 버킷이나 HDFS에 덤프(Dump)되어 있고, 그 의미를 아는 사람은 퇴사했으며, 카탈로그조차 최신화되지 않은 상태를 의미합니다. 이는 "데이터 늪(Data Swamp)"의 전형적인 증상입니다.
패러다임 전환: 도메인 소유권과 데이터 프로덕트
데이터 메쉬(Data Mesh)는 기술적 솔루션이라기보다 조직 및 아키텍처의 패러다임 전환입니다. 핵심은 데이터를 부산물이 아닌 제품(Product)으로 취급하고, 그 소유권을 중앙 팀에서 도메인 팀(예: 결제 팀, 물류 팀, 회원 팀)으로 이관하는 것입니다.
이를 구현하기 위해 각 도메인 팀은 다음과 같은 '데이터 프로덕트' 인터페이스를 노출해야 합니다.
- Discoverable: 데이터 카탈로그에 등록되어 검색 가능해야 함
- Addressable: 유일한 URI를 통해 접근 가능해야 함
- Trustworthy: SLO(Service Level Objective)와 품질 지표를 준수해야 함
- Self-describing: 스키마와 메타데이터를 포함해야 함
# Data Product Descriptor Example (YAML)
apiVersion: datamesh.io/v1alpha1
kind: DataProduct
metadata:
name: payment-transactions
domain: payment
owner: team-fintech@example.com
spec:
inputPorts:
- name: checkout-events
source: kafka://checkout.topic
outputPorts:
- name: daily-reconciliations
type: snowflake-table
schemaURI: s3://schemas/payment/v3/reconcile.json
sla:
freshness: "1h"
availability: "99.9%"
governance:
classification: "PII-Sensitive"
accessControl: "role-based"연합된 계산 거버넌스 (Federated Computational Governance)
탈중앙화의 가장 큰 위험은 표준의 부재로 인한 사일로(Silo)화입니다. 이를 방지하기 위해 연합된 거버넌스가 필요합니다. 정책(Policy)은 중앙에서 정의하되, 실행(Enforcement)은 각 데이터 프로덕트 레벨에서 자동화되어야 합니다.
OPA(Open Policy Agent)와 같은 도구를 사용하여 데이터 접근 제어 및 품질 검사를 코드로 관리(Policy as Code)하는 것이 업계 표준입니다.
# Rego Policy for Data Mesh Governance
# 패키지: 데이터 프로덕트 생성 시 필수 태그 검증
package datamesh.governance
deny[msg] {
# 입력으로 들어온 데이터 프로덕트 스펙 확인
input.kind == "DataProduct"
# 보안 등급(classification)이 누락되었는지 확인
not input.spec.governance.classification
msg := "데이터 프로덕트는 반드시 보안 등급(classification)을 명시해야 합니다."
}
deny[msg] {
input.spec.governance.classification == "PII-Sensitive"
not input.spec.encryption.enabled
msg := "PII 데이터는 반드시 암호화(encryption.enabled)가 설정되어야 합니다."
}아키텍처 비교: Data Lake vs. Data Mesh
기존 모놀리식 접근법과 데이터 메쉬의 아키텍처 차이를 명확히 이해해야 합니다. 핵심은 파이프라인 중심 사고에서 도메인 중심 사고로의 이동입니다.
| 비교 항목 | 모놀리식 데이터 레이크 (Monolithic) | 데이터 메쉬 (Data Mesh) |
|---|---|---|
| 소유권 (Ownership) | 중앙 데이터 팀 (Centralized) | 도메인 팀 (Decentralized) |
| 데이터 관점 | 부산물 (By-product), 수집 대상 | 제품 (Product), 서빙 대상 |
| 아키텍처 분해 | 기술적 파이프라인 (Ingest -> Process -> Serve) | 도메인 경계 (Bounded Context) |
| 거버넌스 | 중앙 통제, 관료적 승인 절차 | 연합형, 자동화된 정책 실행 (Computational) |
| 병목 지점 | 데이터 엔지니어링 팀의 백로그 | 도메인 팀의 데이터 역량 성숙도 |
셀프 서비스 데이터 인프라 플랫폼
각 도메인 팀이 데이터 엔지니어링의 복잡성(Spark 클러스터 관리, Airflow 설정, ACL 관리 등)을 모두 감당하는 것은 불가능합니다. 따라서 플랫폼 팀은 도메인 팀이 비즈니스 로직에만 집중할 수 있도록 추상화된 인프라를 제공해야 합니다.
플랫폼 팀은 "데이터를 만드는 방법"을 제공하지 않고, "데이터 제품을 쉽게 배포하고 운영할 수 있는 도구"를 제공합니다. 예를 들어, Terraform 모듈이나 K8s Operator를 통해 kubectl apply -f data-product.yaml 명령어 하나로 저장소, 컴퓨팅 리소스, 접근 제어 정책을 프로비저닝할 수 있어야 합니다.
Sidecar 패턴을 통한 Polyglot 지원
MSA 환경에서 Service Mesh가 사이드카 프록시를 사용하는 것처럼, Data Mesh에서도 데이터 제품 컨테이너 옆에 'Data Mesh Sidecar'를 배치할 수 있습니다. 이 사이드카는 다음과 같은 공통 기능을 수행합니다.
- 정책 위반 감지 및 차단
- 데이터 리니지(Lineage) 추적을 위한 메타데이터 전송
- 입출력 포트(Port)에 대한 표준화된 인터페이스 제공
결론: 엔터프라이즈 적용을 위한 로드맵
데이터 메쉬는 은탄환이 아닙니다. 조직의 규모가 작거나 도메인 복잡도가 낮다면 중앙 집중식 아키텍처가 여전히 효율적일 수 있습니다. 데이터 메쉬는 데이터 소스가 다양하고 변경이 잦으며, 소비자의 요구사항이 복잡한 대규모 조직에 적합합니다.
전환을 위해서는 먼저 '파일럿 도메인'을 선정하여 데이터 프로덕트를 MVP(Minimum Viable Product) 형태로 구축하고, 이를 지원하기 위한 최소한의 셀프 서비스 플랫폼을 병행하여 개발하는 점진적 접근이 필수적입니다.
Post a Comment