추출 변환 로드

추출 단계는 하나 이상의 데이터 소스로부터 데이터를 수집하고 읽어오는 과정이다. 이 단계의 주요 목표는 후속 변환 및 로드 과정을 위해 원본 데이터를 안정적으로 획득하는 것이다. 데이터 소스는 매우 다양할 수 있으며, RDBMS, 플랫 파일, API, 로그 파일, SaaS 애플리케이션 등이 포함된다.

추출 방식은 크게 전체 추출과 증분 추출로 나뉜다. 전체 추출은 매번 소스 시스템의 전체 데이터 집합을 가져오는 방식이다. 이는 구현이 간단하지만, 데이터 양이 많을 경우 시스템 부하와 처리 시간이 크게 증가한다는 단점이 있다. 증분 추출은 마지막 추출 이후 변경되거나 추가된 데이터만 식별하여 가져오는 방식이다. 이는 변경 데이터 포착 기술을 활용하며, 시스템 자원을 효율적으로 사용할 수 있다.

추출 과정에서 고려해야 할 핵심 요소는 다음과 같다.

성공적인 추출 단계는 정확하고 완전한 데이터를 손상 없이 가져오는 것을 보장하며, 이는 전체 ETL 프로세스의 신뢰성 기반이 된다.

변환 단계는 추출된 원천 데이터를 목적 시스템에 적합한 형태로 가공하고 정제하는 과정이다. 이 단계는 데이터 품질을 보장하고 비즈니스 규칙을 적용하며, 분석에 유용한 형식으로 데이터를 구조화하는 핵심 역할을 한다. 변환 작업은 주로 ETL 도구 내부의 변환 엔진이나 별도의 스크립트를 통해 수행된다.

변환 과정에서 수행되는 일반적인 작업은 다음과 같다.

또한, 변환 과정에서는 데이터의 무결성을 검증하는 규칙이 적용된다. 예를 들어, 특정 필드에 대한 유효성 검사(예: 이메일 주소 형식), 참조 무결성 확인(예: 주문 테이블의 고객 ID가 고객 마스터에 존재하는지), 비즈니스 규칙 검증(예: 할인율이 정해진 범위 내에 있는지) 등이 수행된다. 이러한 검증을 통해 데이터 웨어하우스에 로드되는 정보의 신뢰성을 높인다.

변환 로직의 복잡성은 비즈니스 요구사항과 원천 시스템의 상태에 따라 크게 달라진다. 단순한 필드 매핑에서부터 다단계의 복잡한 비즈니스 로직을 포함하는 경우까지 다양하다. 효율적인 변환 설계는 처리 성능과 유지보수성에 직접적인 영향을 미치므로, 모듈화와 재사용성을 고려하는 것이 중요하다.

로드는 변환된 데이터를 최종 목적지인 데이터 웨어하우스, 데이터 마트, 데이터 레이크 또는 운영 시스템과 같은 타깃 시스템에 적재하는 과정이다. 이 단계는 데이터의 가용성을 보장하고, 이후 비즈니스 인텔리전스 도구나 분석 애플리케이션이 효율적으로 데이터를 활용할 수 있도록 기반을 마련한다.

로드 작업은 주로 두 가지 방식으로 수행된다. 첫째는 전체 로드(Full Load)로, 목표 테이블의 기존 데이터를 모두 삭제한 후 새로운 데이터 세트를 처음부터 적재하는 방식이다. 둘째는 증분 로드(Incremental Load)로, 마지막 로드 이후 변경되거나 추가된 데이터만 식별하여 목표 시스템에 병합하는 방식이다. 증분 로드는 대용량 데이터를 처리할 때 성능과 효율성 면에서 유리하다.

로드 과정에서 중요한 고려사항은 데이터 무결성과 트랜잭션 관리이다. 데이터 적재 중 시스템 장애가 발생하더라도 데이터의 일관성을 유지하기 위해 롤백(rollback) 메커니즘을 갖추거나, ACID 속성을 지원하는 데이터베이스의 기능을 활용한다. 또한, 적재 성능을 최적화하기 위해 인덱스를 일시적으로 비활성화하거나 대량 삽입(Bulk Insert) 기능을 사용하는 경우가 많다.

로드가 완료된 후에는 데이터 검증 작업이 수반된다. 예상된 레코드 수가 정확히 적재되었는지, 기본키 제약이나 참조 무결성 규칙에 위배되는 데이터는 없는지 확인하여 ETL 프로세스의 최종 품질을 보증한다. 이 검증은 이후의 데이터 분석과 보고서 신뢰도의 기초가 된다.

배치 ETL은 정해진 일정에 따라 또는 특정 조건이 충족되었을 때, 대량의 데이터를 한꺼번에 처리하는 방식이다. 이 방식은 주로 야간, 주말 등 시스템 사용량이 적은 시간대에 실행되어 일일, 주간, 월간 등의 주기적인 데이터 적재 작업에 적합하다. 처리할 데이터가 충분히 축적된 후에 일괄적으로 작업을 수행하므로, 리소스를 효율적으로 사용할 수 있고 작업 관리가 비교적 단순하다는 장점이 있다.

전형적인 배치 ETL 작업의 흐름은 다음과 같은 단계를 거친다.

1. 스케줄링: 작업 실행 시간을 미리 예약한다.

2. 추출: 원본 시스템(예: 운영 데이터베이스, 로그 파일)에서 지난 배치 주기 동안 생성되거나 변경된 모든 데이터를 추출한다.

3. 변환: 비즈니스 규칙을 적용하여 데이터를 정제, 표준화, 집계한다.

4. 로드: 변환이 완료된 데이터를 데이터 웨어하우스나 데이터 마트 같은 목적지에 적재한다.

배치 ETL은 역사적으로 가장 널리 사용된 패턴으로, 데이터 웨어하우스 구축의 핵심 기술이었다. 이 방식은 데이터의 일관성과 정확성을 보장하는 데 강점을 보이며, 복잡한 변환 로직과 대규모 데이터 집계를 처리하는 데 최적화되어 있다.

그러나 배치 처리의 본질적인 한계도 존재한다. 데이터가 생성된 시점과 분석 가능한 시점 사이에 수시간에서 수일의 지연이 발생할 수 있어, 실시간성이 요구되는 의사결정에는 부적합하다. 또한 대량의 데이터를 한 번에 처리하기 때문에 실행 시간이 길고, 중간에 오류가 발생하면 전체 작업을 롤백하거나 재실행해야 할 수 있다. 이러한 특성 때문에 실시간 데이터 수요가 증가하는 현대 환경에서는 배치 ETL이 실시간 ETL이나 ELT 패턴과 함께 혼용되어 사용된다.

실시간 ETL은 데이터 소스에서 발생하는 변경 사항이나 이벤트를 지속적으로 감지하여 거의 실시간에 가깝게 데이터 웨어하우스나 분석 시스템으로 전달하는 프로세스이다. 이는 전통적인 배치(Batch) ETL이 주기적으로(예: 매일 밤) 대량의 데이터를 처리하는 방식과 대비된다. 실시간 ETL은 신용카드 사기 탐지, 주식 시장 모니터링, IoT 센서 데이터 분석, 개인화된 추천 시스템 등 지연 시간이 매우 중요한 의사결정이 필요한 비즈니스 시나리오에서 필수적이다.

실시간 ETL을 구현하는 주요 기술로는 CDC(Change Data Capture)와 스트림 처리(Stream Processing)가 있다. CDC는 관계형 데이터베이스의 트랜잭션 로그를 읽어 삽입, 갱신, 삭제된 레코드만을 식별하여 추출한다. 스트림 처리 엔진(예: Apache Kafka, Apache Flink, Apache Spark Streaming)은 이러한 변경 데이터 스트림이나 메시지 큐의 이벤트를 실시간으로 변환(필터링, 집계, 조인)하고 목적지에 로드한다.

이 방식은 데이터의 신선도를 극대화하지만, 시스템 설계와 유지보수가 더 복잡하고 비용이 많이 들 수 있다. 또한, 실시간으로 도착하는 데이터의 순서 보장, 정확히 한 번 처리(exactly-once processing), 장애 복구 등의 기술적 과제를 해결해야 한다[3]. 따라서 비즈니스 요구사항에 따라 실시간 처리의 필요성을 신중히 평가하고, 배치 처리와 혼합된 아키텍처(람다 아키텍처)를 채택하는 경우도 많다.

ELT는 추출 변환 로드 프로세스의 변형된 패턴으로, 데이터를 먼저 목표 시스템에 로드한 후 그 안에서 변환 작업을 수행하는 접근법이다. 이는 전통적인 ETL의 단계적 순서를 변경한 것이다.

ELT의 핵심은 변환 단계의 위치와 실행 환경의 변화에 있다. 원본 데이터는 최소한의 정제만 거친 채 원시 형태 그대로 데이터 웨어하우스나 데이터 레이크 같은 목표 저장소에 적재된다. 이후 변환 작업은 목표 시스템 내부의 컴퓨팅 리소스(예: 데이터베이스 엔진)를 활용하여 수행된다. 이 패턴의 등장은 클라우드 기반의 대규모 병렬 처리 데이터 웨어하우스와 데이터 레이크하우스의 확산과 밀접한 관련이 있다. 이러한 플랫폼들은 강력한 SQL 처리 능력과 거의 무제한에 가까운 스토리지 확장성을 제공하여, 원시 데이터를 그대로 저장하고 필요할 때 변환하는 방식을 실용적으로 만들었다.

ELT의 주요 장점은 데이터의 유연성과 확장성에 있다. 모든 원시 데이터를 저장소에 보관하기 때문에, 새로운 분석 요구사항이 발생했을 때 기존 로직을 수정하지 않고도 데이터를 재변환할 수 있다. 또한, 클라우드 플랫폼의 탄력적인 컴퓨팅 자원을 활용하여 대용량 데이터 변환 작업의 성능을 쉽게 확장할 수 있다. 반면, 목표 시스템의 비용과 성능에 직접적인 영향을 미칠 수 있으며, 데이터 저장소 내에서 복잡한 변환 로직을 관리해야 하는 어려움이 있을 수 있다. 이 패턴은 특히 데이터 레이크에 원시 데이터를 축적하고, 데이터 과학이나 탐색적 분석을 위해 다양한 형태로 데이터를 처리해야 하는 현대적인 데이터 파이프라인에서 널리 채택되고 있다.

상용 ETL 도구는 기업이 데이터 통합 작업을 수행하기 위해 구매하여 사용하는 소프트웨어 제품군이다. 이러한 도구들은 일반적으로 그래픽 사용자 인터페이스를 제공하여 코드 작성 없이 데이터 흐름을 시각적으로 설계하고 관리할 수 있게 하며, 다양한 데이터 소스와 대상 시스템에 대한 사전 구축된 커넥터, 강력한 데이터 변환 기능, 그리고 중앙화된 작업 스케줄링 및 모니터링 환경을 제공한다. 주요 목표는 복잡한 데이터 파이프라인 구축을 단순화하고 유지보수 비용을 절감하며, 데이터 처리의 안정성과 일관성을 보장하는 것이다.

대표적인 상용 ETL 도구로는 인포매티카 파워센터, IBM 인포스피어 데이터스테이지, 오라클 데이터 인티그레이터, SAP 데이터 서비스, 마이크로소프트 SQL 서버 통합 서비스 등이 있다. 이러한 도구들은 각각 고유한 강점을 지니고 있으며, 예를 들어 인포매티카는 메타데이터 관리와 데이터 품질 기능에, IBM 데이터스테이지는 대규모 배치 처리에, 마이크로소프트 SSIS는 마이크로소프트 생태계와의 긴밀한 통합에 특화되어 있다.

상용 ETL 도구의 선택은 기업의 기술 스택, 예산, 처리할 데이터의 규모와 복잡성, 필요한 통합 패턴(배치 또는 실시간) 등 여러 요소에 따라 결정된다. 아래 표는 일부 주요 상용 ETL 도구의 특징을 비교한 것이다.

이들 도구는 전통적인 데이터 웨어하우스 환경뿐만 아니라, 현대적인 클라우드 컴퓨팅 플랫폼과 데이터 레이크로의 데이터 수집을 지원하기 위해 지속적으로 진화하고 있다. 많은 공급업체들이 SaaS 형태의 클라우드 네이티브 ETL 서비스를 별도로 출시하여 유연성과 확장성을 더하고 있다.

오픈소스 ETL 도구는 라이선스 비용이 없고 커뮤니티 지원이 활발하며 소스 코드를 자유롭게 수정 및 확장할 수 있다는 장점을 가진다. 이들은 주로 Apache 재단이나 다양한 개발자 커뮤니티에 의해 주도적으로 개발 및 유지보수된다. 초기에는 단순한 스크립트나 Apache Airflow 같은 워크플로 오케스트레이션 도구를 조합하여 사용하는 경우가 많았으나, 현재는 기능이 풍부한 통합 프레임워크들이 많이 등장했다.

대표적인 오픈소스 ETL 도구로는 Apache NiFi, Apache Airflow, Talend Open Studio, Pentaho Data Integration (Kettle) 등이 있다. Apache NiFi는 데이터 라우팅, 변환, 시스템 미디어션을 위한 강력한 웹 인터페이스와 데이터 흐름을 시각적으로 설계할 수 있는 기능으로 유명하다. Apache Airflow는 파이프라인을 코드로 정의하고 스케줄링, 모니터링하는 데 특화된 워크플로 오케스트레이션 도구로, 복잡한 ETL 작업의 의존성을 관리하는 데 널리 사용된다.

이들 도구는 상용 솔루션에 비해 초기 진입 장벽이 낮고 유연성이 높다는 장점이 있지만, 엔터프라이즈급 지원, 사용 편의성, 통합 관리 기능 측면에서는 상용 도구에 비해 부족한 점이 있을 수 있다. 따라서 조직의 기술 역량, 요구되는 기능의 복잡도, 유지보수 부담을 고려하여 선택해야 한다. 아래는 주요 오픈소스 ETL 도구들을 비교한 표이다.

클라우드 기반 데이터 파이프라인 서비스는 AWS, Google Cloud, Microsoft Azure와 같은 주요 클라우드 컴퓨팅 제공업체가 관리형 서비스 형태로 제공하는 데이터 파이프라인 구축 및 운영 솔루션이다. 이 서비스들은 전통적인 온프레미스 ETL 도구의 기능을 클라우드 환경에 최적화하여, 사용자가 서버 인프라를 직접 관리할 필요 없이 데이터 통합 작업에 집중할 수 있게 한다. 주요 특징으로는 탄력적인 확장성, 사용한 만큼 지불하는 과금 모델, 그리고 클라우드 네이티브 데이터 저장소 및 분석 서비스와의 긴밀한 통합을 꼽을 수 있다.

각 클라우드 벤더는 고유한 서비스 스택을 제공한다. AWS는 AWS Glue (서버리스 ETL 서비스)와 AWS Data Pipeline을, Google Cloud는 Cloud Dataflow (스트림 및 배치 처리)와 Cloud Composer (관리형 Apache Airflow)를, Microsoft Azure는 Azure Data Factory를 대표적인 서비스로 운영한다. 이러한 서비스들은 일반적으로 시각적 도구 또는 코드 기반 인터페이스를 제공하여 파이프라인을 구성하고, 트리거 기반 또는 예약된 방식으로 작업을 실행하며, 실행 로그와 모니터링 대시보드를 통해 상태를 추적한다.

클라우드 ETL 서비스의 장점은 명확하다. 인프라 프로비저닝과 유지 관리 부담이 없어 빠른 구축과 출시가 가능하며, 트래픽에 따라 자동으로 확장되는 서버리스 아키텍처를 통해 비용과 성능을 효율적으로 관리할 수 있다. 또한, 동일한 플랫폼 내의 데이터 웨어하우스 (예: Amazon Redshift, Google BigQuery, Azure Synapse Analytics)나 데이터 레이크 (예: Amazon S3, Google Cloud Storage, Azure Data Lake Storage)와의 네이티브 연동이 용이하여 종합적인 데이터 플랫폼을 구성하기에 적합하다. 그러나 특정 벤더의 서비스에 종속될 수 있는 벤더 락-인(Vendor Lock-in) 가능성과, 대규모 지속적인 데이터 처리 시 비용이 급증할 수 있는 점은 주의 깊게 고려해야 할 요소이다.

데이터 품질 관리는 추출 변환 로드 프로세스의 신뢰성과 유용성을 보장하는 핵심 활동이다. 이 과정은 데이터의 정확성, 완전성, 일관성, 적시성, 유일성을 검증하고 개선하는 것을 목표로 한다. 품질이 낮은 데이터는 잘못된 분석 결과와 비즈니스 의사결정으로 이어질 수 있으므로, ETL 파이프라인의 각 단계에 품질 검증 규칙을 내재화하는 것이 중요하다.

주요 데이터 품질 관리 활동은 다음과 같다.

이러한 검증은 주로 변환 단계에서 수행되며, 품질 검사 실패 시 사전 정의된 정책에 따라 처리된다. 예를 들어, 치명적 오류는 파이프라인을 중단시키고 경고를 발생시키며, 경미한 오류는 기본값으로 대체하거나 별도의 큐에 저장하여 후속 수정 작업 대상으로 삼을 수 있다. 효과적인 데이터 품질 관리를 위해서는 데이터 프로파일링 도구를 활용한 사전 분석과, 데이터 품질 지표를 지속적으로 추적하는 대시보드 구축이 필수적이다.

ETL 프로세스의 성능은 데이터 처리 시간과 시스템 자원 사용 효율성으로 측정된다. 확장성은 증가하는 데이터 볼륨, 복잡성, 처리 요구 사항에 맞춰 시스템의 용량을 늘릴 수 있는 능력을 의미한다. 성능 최적화와 확장성 확보는 대규모 데이터 환경에서 ETL 파이프라인의 핵심 설계 목표이다.

성능을 개선하기 위한 주요 접근법은 병렬 처리, 분할, 증분 로드, 적절한 인덱싱 전략을 포함한다. 예를 들어, 배치 ETL 작업에서는 대용량 데이터를 시간 범위나 키 값 기준으로 분할하여 여러 스레드나 서버에서 동시에 처리할 수 있다. 변환 단계에서 복잡한 조인 연산이나 집계 함수의 사용을 최소화하고, 중간 결과를 임시 테이블에 저장하는 전략도 성능에 큰 영향을 미친다. 또한, 소스 및 대상 시스템의 네트워크 대역폭과 I/O 성능도 전체 처리 속도의 병목 지점이 될 수 있다.

확장성은 일반적으로 수직 확장과 수평 확장 두 가지 방식으로 구현된다. 수직 확장은 단일 서버의 CPU, 메모리, 저장 장치를 업그레이드하는 방식이다. 수평 확장은 여러 서버에 작업을 분산시키는 방식으로, 클라우드 컴퓨팅 환경에서 탄력적으로 인스턴스를 추가하거나 Apache Spark와 같은 분산 처리 프레임워크를 활용하는 것이 일반적이다. 현대의 ELT 패턴은 변환 작업을 대상 데이터 웨어하우스의 강력한 처리 엔진에 위임함으로써 확장성 문제를 해결하는 경향이 있다.

성능과 확장성 설계 시 다음 요소들을 종합적으로 고려해야 한다.

이러한 요소들 간의 균형을 맞추지 못하면 처리 지연, 비용 증가, 시스템 불안정 등의 문제가 발생할 수 있다. 따라서 초기 설계 단계부터 성능 목표와 확장성 요구사항을 명확히 정의하고, 정기적인 모니터링과 튜닝을 통해 파이프라인을 진화시켜 나가는 것이 중요하다.

ETL 프로세스에서 오류는 데이터 소스의 비정상, 변환 로직의 결함, 대상 시스템의 문제 등 다양한 지점에서 발생할 수 있다. 효과적인 오류 처리는 데이터 파이프라인의 신뢰성과 데이터 품질을 보장하는 핵심 요소이다. 일반적으로 오류는 크게 데이터 오류와 시스템 오류로 구분되며, 각각에 대한 대응 전략이 필요하다. 데이터 오류는 잘못된 형식, 무결성 제약 위반, 비즈니스 규칙 불일치 등을 포함하며, 시스템 오류는 네트워크 장애, 연결 시간 초과, 리소스 부족 등을 포함한다.

오류 처리 전략은 주로 다음과 같은 접근 방식을 취한다.

• 오류 격리 및 로깅: 오류가 발생한 레코드나 작업을 별도의 오류 큐나 테이블로 격리하고, 상세한 오류 메시지와 컨텍스트를 로그에 기록한다. 이는 정상 데이터의 처리를 지속하면서 나중에 오류 데이터를 분석하고 재처리할 수 있게 한다.

• 재시도 및 회로 차단기 패턴: 일시적인 시스템 오류(예: 일시적인 네트워크 불안정)의 경우, 지수 백오프(Exponential Backoff) 전략을 적용한 재시도 메커니즘이 유용하다. 반복적인 실패 시에는 회로 차단기(Circuit Breaker) 패턴을 적용하여 시스템에 과부하가 걸리는 것을 방지한다.

• 데이터 검증 및 정제: 추출 또는 변환 단계에서 사전에 정의된 데이터 품질 규칙을 적용하여 오류를 사전에 탐지한다. 규칙 위반 데이터는 거부되거나 기본값으로 대체될 수 있다.

강력한 모니터링 체계는 ETL 작업의 상태와 성능을 실시간으로 가시화하고 문제를 조기에 발견하는 데 필수적이다. 모니터링은 일반적으로 다음 지표와 활동을 포함한다.

• 작업 실행 모니터링: 각 ETL 작업의 시작/종료 시간, 성공/실패 상태, 처리된 레코드 수, 처리 소요 시간 등을 추적한다.

• 성능 지표 모니터링: 처리량(Throughput), 지연 시간(Latency), 시스템 자원(CPU, 메모리, I/O) 사용률을 모니터링하여 병목 현상을 식별한다.

• 데이터 품질 모니터링: 처리 과정에서 발견된 오류 레코드 수, 데이터 완전성, 정확성 추이를 모니터링하고 경고를 설정한다.

• 경고 및 알림: 정의된 임계값을 초과하거나 작업이 실패할 경우, 이메일, 슬랙, SMS 등을 통해 관련 담당자에게 자동으로 알림을 전송한다. 많은 현대 ETL 도구와 클라우드 컴퓨팅 플랫폼은 대시보드, 로그 집계, 분산 추적 시스템과의 통합을 제공하여 종합적인 모니터링을 지원한다.

데이터 레이크는 정제되거나 구조화되지 않은 대량의 원시 데이터를 그대로 저장할 수 있는 저장소이다. 전통적인 ETL 프로세스는 주로 정형화된 데이터를 데이터 웨어하우스에 적재하는 데 초점을 맞췄다면, 데이터 레이크의 등장은 ETL의 범위와 접근 방식을 확장시켰다. 데이터 레이크와의 통합은 ELT 패턴을 더욱 부각시켰는데, 이는 원시 데이터를 먼저 레이크에 로드한 후, 필요에 따라 변환 및 분석을 수행하는 방식이다.

이러한 통합은 데이터 처리 흐름을 변화시켰다. 데이터 레이크는 다양한 소스의 원본 데이터를 오브젝트 스토리지에 비용 효율적으로 저장하는 장소로 작동한다. 이후 분석이나 특정 비즈니스 용도를 위해 데이터를 추출할 때, ETL 또는 ELT 프로세스가 실행되어 데이터를 변환하고 대상 시스템(예: 데이터 웨어하우스, 데이터 마트, 분석 도구)으로 이동시킨다. 이는 데이터 사용 패턴에 따라 유연하게 변환 로직을 적용할 수 있는 장점을 제공한다.

데이터 레이크와 ETL을 통합할 때의 주요 고려사항은 다음과 같다.

결과적으로, 데이터 레이크는 ETL 파이프라인의 출발점이자 원시 데이터의 중앙 저장 허브 역할을 하며, 현대적인 데이터 플랫폼 아키텍처의 핵심 구성 요소로 자리 잡았다.

데이터 메시는 데이터 아키텍처를 조직 구조에 맞추어 분산시키는 패러다임이다. 이는 중앙 집중식 데이터 웨어하우스나 데이터 레이크 팀이 모든 데이터 파이프라인을 소유하고 관리하는 전통적인 모델에서 벗어난다. 대신, 데이터 메시는 데이터를 비즈니스 도메인(예: 마케팅, 재무, 고객 서비스) 단위로 분할하고, 각 도메인 팀이 자신의 데이터 제품에 대한 소유권과 책임을 지도록 한다. 이 접근법은 데이터 소비자에게 높은 품질의 데이터를 제공하는 것을 서비스로 간주한다.

데이터 메시 아키텍처의 핵심 원칙은 도메인 소유권, 데이터를 제품으로 취급, 자율적인 인프라 플랫폼, 연합 거버넌스이다. 여기서 ETL 또는 ELT 파이프라인은 중앙 팀이 아닌 각 도메인 팀에 의해 설계되고 운영된다. 도메인 팀은 자신의 비즈니스 로직에 맞는 변환 규칙을 적용하고, 데이터 제품의 품질, 보안, 문서화를 보장할 책임을 진다. 이는 데이터 생산자와 소비자 간의 거리를 줄여 민첩성을 높인다.

데이터 메시 환경에서 ETL 프로세스는 변화한다. 중앙의 단일 파이프라인이 아니라, 여러 도메인에 걸쳐 분산된 수많은 파이프라인이 존재한다. 이때 중앙 팀의 역할은 이러한 분산된 ETL 작업을 지원하는 공통 인프라 플랫폼(예: 표준화된 데이터 파이프라인 도구, 메타데이터 카탈로그, 접근 제어 시스템)을 제공하고, 전체 조직에 걸친 데이터 발견, 보안, 상호 운용성을 위한 표준과 프로토콜을 수립하는 데로 전환된다.

이 아키텍처는 대규모 조직에서 데이터 소유권과 확장성 문제를 해결하는 데 유용하지만, 구현 복잡도가 높다. 분산된 ETL 로직으로 인한 데이터 일관성 유지, 중복 개발 방지, 조직 전체의 데이터 표준 준수를 보장하는 것이 주요 과제이다. 따라서 효과적인 데이터 메시 구현을 위해서는 강력한 자동화된 거버넌스 프레임워크와 팀 간 협업 문화가 필수적으로 요구된다.