ETL이냐 CDC냐 가상화냐 — 데이터 통합 패턴을 상황별로 고르는 법

같은 "여러 소스를 하나로 합쳐달라"는 요청도 대용량 분석용인지, 실시간 재고 반영용인지, 규제 데이터인지에 따라 완전히 다른 방식으로 풀어야 한다. 데이터 통합과 데이터 패브릭은 이 방식들을 구분하고 언제 무엇을 쓸지 판단하는 틀이다.

통합과 패브릭은 서로 다른 층의 개념이다

데이터 통합은 다양한 소스의 데이터를 공통 스키마·정책 아래 수집·정제·결합·제공하는 프로세스로, 배치(ETL/ELT)와 스트리밍(CDC/Event)을 모두 포함한다. 데이터 패브릭은 물리적 데이터 이동 방식과 무관하게 메타데이터·정책·오케스트레이션을 일원화해 데이터 접근·거버넌스·옵서버빌리티를 크로스도메인으로 제공하는 아키텍처 패턴이다. 데이터 패브릭이 중앙(연합) 메타데이터·정책 기반의 통합 제어면을 제공하는 쪽이라면, 데이터 메시는 도메인 자율성과 제품화를 강조하는 쪽이다. 대규모 조직에서는 패브릭으로 제어면을 통합하고 메시로 도메인 운영을 병행하는 조합이 흔하다.

이 제어면을 실제로 움직이는 것은 다섯 개 구성요소다. 표준 커넥터 기반 추출과 트랜잭션 로그 기반 CDC를 병행 운영하는 수집 계층은 실시간·근실시간·배치 SLO를 소스별로 차등 설계하고, 스키마 진화 이벤트를 메타데이터 카탈로그와 동기화한다. 기술·업무·운영 메타데이터를 통합 관리하는 메타데이터·지식 그래프는 계보와 품질 규칙, SLO를 결합해 정책 집행을 지원하고 엔터티·관계 중심의 임팩트 분석을 자동화한다. RBAC/ABAC와 데이터 분류·민감도 등급, 마스킹·토큰화·목적 제한 처리를 코드로 관리하는 거버넌스·정책 엔진은 PII/PCI/HIPAA 준수 증적을 자동 수집한다. 레이크하우스 기반 ELT, 스트리밍 조인·업서트, 가상화를 워크로드 특성에 따라 혼합하는 처리·조합 엔진은 캐시·프루닝·프록시 푸시다운으로 지연을 줄인다. 마지막으로 SLI/SLO를 정의·모니터링하고 이상 탐지·스키마 드리프트 경보를 자동화하는 관측성·품질 계층이 실패 격리와 데드레터 큐, 보상·재처리 플레이북을 표준화한다.

패턴과 상황

대용량 분석이나 클라우드 레이크하우스 중심 환경은 저장 후 변환을 일괄 최적화하는 ELT가 우선이고, 규제·민감 데이터나 소스 부하를 최소화해야 할 때는 전처리·필터링이 되는 ETL로 돈다. 실시간에 가까운 변경을 반영해야 하면 Debezium·Kafka 같은 로그 기반 CDC로 변경 이벤트를 수집하고 스키마 레지스트리로 진화를 관리하며, 스트리밍에서 디멘전 테이블과 타임-버전 조인을 적용해 업서트(MERGE)로 골드 레이어를 최신화하는 CDC+스트리밍 합류 패턴이 맞다. 데이터 복제를 피하고 즉시성을 원할 때는 푸시다운 가능한 뷰·페더레이션 쿼리로 응답하는 가상화 패턴을 쓰고, 캐시·TTL·정책 필터를 결합해 높은 QPS에 대응한다.

브론즈(원천)·실버(정제)·골드(서빙) 3계층으로 나눠 존 경계에서 스키마 강제와 품질 검사를 집행하고 Delta·Iceberg·Hudi 같은 ACID 테이블 포맷으로 타임트래블·롤백을 보장하는 것이 다중 존 레이크하우스 패턴이다. 접근 통제가 핵심이면 OPA·Ranger·Lake Formation 같은 정책 엔진으로 뷰 기반 마스킹·행필터를 걸고 목적 제한·동의 상태에 따라 조건부 접속을 허용하는 정책 중심 접근 패턴을 쓰며, 정책 변경은 GitOps 파이프라인으로 검증·승인·롤아웃한다. 카탈로그·라인리지 이벤트가 발생하면 Argo·Airflow 같은 오케스트레이터가 영향 범위를 재실행·검증하도록 트리거하고 품질 실패 시 자동 격리·알림·롤백으로 MTTR을 줄이는 것이 액티브 메타데이터 오케스트레이션 패턴이다.

입력에서 출력까지, 그리고 오류가 났을 때

소스 이벤트·스냅샷이 스키마 등록과 함께 들어오면 정책 평가 → 변환/조합 → 성공/오류 분기 순으로 처리되고, 트랜잭션 경계는 이 과정 내내 지켜진다. 성공하면 서빙 계층에 적재되거나 가상화로 응답되고 관측성 피드백 루프로 돌아가지만, 실패하면 데드레터·보상 트랜잭션 경로로 빠져 리트라이·사후보정을 거친다.

⤢✕

패턴별로 운영 특성이 갈린다

패턴	성능	확장성	일관성	안정성	운영 편의
배치 ETL	대용량 일괄 강점	스케줄 확장 용이	강한 일괄 일관성	재처리 단순	배포/스케줄 단순
ELT(레이크하우스)	MPP/벡터화 우수	스토리지/컴퓨트 탄력	스냅샷 일관성	타임트래블·ACID	데이터 거버넌스 연계 용이
CDC 스트리밍	지연 최소	파티션 확장 우수	최종적 일관성(옵션 ACID 싱크)	장애 격리 필요	스키마 드리프트 관리 필요
데이터 가상화	소스 Pushdown 의존	소스 성능 한계 영향	소스 트랜잭션 준수	네트워크·캐시 영향	복제 없음, 정책 일원화 용이
데이터 패브릭(오케스트레이션)	제어면 오버헤드 존재	다도메인 확장	정책·메타 일관성	실패 격리·보상 내장	거버넌스·카탈로그 통합 용이

산업별로는 이렇게 조합한다

글로벌 리테일의 실시간 재고·가격 일치화는 CDC → 스트리밍 업서트 → 골드 서빙 뷰에 프로모션 정책 기반 가격 마스킹을 얹는다. 재고 반영은 T90 기준 5초 이내, 재처리 MTTR은 10분 이내를 목표로 삼고 오버셀 방지를 위한 재고 락 윈도우를 건다. 금융 KYC/AML은 가상화로 고객 360도 조회를 하고 배치 ELT로 규칙·그래프 스코어링을 돌리며 정책 엔진으로 PII 열을 마스킹하는데, 의심거래 탐지 리드타임을 30% 단축하고 감사 추적을 100% 자동화하는 게 목표다. 제조 예지정비는 IoT 스트리밍과 마스터 데이터의 SCD2 조인을 실버 레이어에서 피처 스토어와 동기화해 경고 탐지 지연 2초 이내, 오탐률 15% 감소를 노린다. 공공 데이터 허브는 데이터 가상화와 캐시를 오픈 API 포털로 묶어 정책 기반 접근·목적 제한을 걸고, API 가용성 99.9%와 평균 응답 300ms 이내를 SLO로 잡는다.

보안·아키텍처·운영에서 지키는 선

보안은 최소권한·목적 제한·동적 마스킹을 적용하고 키·비밀 관리를 KMS로 일원화하며 전 구간 암호화와 감사 로그 불변 스토리지를 갖추는 게 모범사례지만, 강력한 정책은 지연을 늘리고 캐시 적중률을 낮추며 뷰 기반 마스킹은 Pushdown 한계에 부딪힌다. 아키텍처는 브론즈·실버·골드 존 분리, ACID 테이블 포맷, 카탈로그·정책 엔진 이중화가 기본이지만 패브릭 제어면이 복잡해지고 멀티벤더 연동에서는 ANSI SQL·OPA·OpenLineage 같은 표준을 우선 적용해야 한다. 운영은 스키마 진화 계약, DQ 게이트, 데드레터·보상 트랜잭션 자동화, SLO 기반 용량 계획이 필요하지만 과도한 DQ·알림은 소음을 늘리고 옵서버빌리티 도구가 중복되면 비용이 오른다.

이 여섯 패턴을 조합해 도입한 조직 전반에서 나타나는 효과로는 데이터 리드타임 4070% 단축, 중복 파이프라인 30% 이상 축소, 가상화·존 분리 최적화 시 스토리지 복제 비용 2040% 절감이 보고된다. 품질 측면에서는 DQ 실패율이 50% 이상 줄고 라인리지 커버리지가 90% 이상 오르며 규제 감사 준비 시간이 60% 줄어드는 경우도 있다. 운영 측면에서는 Policy-as-Code와 GitOps 도입으로 배포 실패율이 30% 줄고, 신규 도메인 온보딩 소요 시간(TTV)이 50% 단축되는 것으로 나타난다.

최소 구현: CDC에서 스트리밍 업서트까지

Kafka 3.6, Debezium 2.x, Spark 3.5, Iceberg/Delta 테이블, Schema Registry를 사용한다는 전제다.

Debezium MySQL 커넥터 설정은 다음과 같다.

{
  "name": "mysql-inventory-cdc",
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
    "database.hostname": "mysql",
    "database.port": "3306",
    "database.user": "debezium",
    "database.password": "******",
    "database.server.id": "184054",
    "database.server.name": "inventory",
    "table.include.list": "inventory.customers,inventory.orders",
    "include.schema.changes": "true",
    "tombstones.on.delete": "false",
    "snapshot.mode": "initial"
  }
}

이 변경 이벤트를 Spark Structured Streaming으로 받아 Delta 테이블에 업서트하는 스케치는 다음과 같다.

// Spark 3.5, Delta/Iceberg sink 가정
val cdc = spark.readStream
  .format("kafka")
  .option("kafka.bootstrap.servers", "broker:9092")
  .option("subscribe", "inventory.customers")
  .load()

// 파싱·정규화 후 MERGE
import io.delta.tables._
val target = DeltaTable.forName("gold.customers")

val query = parsedCdc.writeStream
  .foreachBatch { (batch, batchId) =>
    target.as("t")
      .merge(batch.as("s"), "t.id = s.id")
      .whenMatched().updateAll()
      .whenNotMatched().insertAll()
      .execute()
  }
  .option("checkpointLocation", "s3://chk/gold/customers")
  .start()

파싱에 실패한 레코드는 데드레터 토픽으로 격리하고, 배치 재처리와 보상 트랜잭션은 분리해서 운영한다.

데이터 패브릭은 ETL/ELT/가상화/스트리밍이라는 기술적 통합 방식을 포괄하면서 메타데이터·정책·오케스트레이션을 중앙 제어면으로 일원화하는 아키텍처 패턴이다. 핵심은 활성 메타데이터 기반 자동화, 정책 코드화, 관측성 주도 운영이며, 브론즈·실버·골드 존 분리와 ACID 테이블 포맷, CDC 스트리밍이라는 최소 패턴부터 시작해 가상화·정책 엔진·지식 그래프 순으로 확장하는 것이 권장된다. SLO·DQ·라인리지를 제도화해야 신뢰할 수 있는 데이터 제품 공급 체계가 만들어진다.