[ECL] AI 시대의 데이터 엔지니어링: ETL에서 ECL로

 

요약

• ECL = Extract · Contextualize · Link
• ETL을 대체하는 개념이 아니라 ETL을 확장하는 관점
• 기존 Transform 단계 안에 있던 두 가지 문제를 분리
  • 데이터 의미 정의
  • 데이터 엔티티 연결
• 데이터 엔지니어의 역할 변화: 파이프라인 코드 작성 → 데이터 의미 구조 설계
  ※ 데이터 이동 중심 → 데이터 의미 중심

 

1. ETL로 이해하던 데이터 엔지니어링

 

• ETL을 배운 사람에게 데이터 엔지니어링은 비교적 명확한 구조로 이해된다.
  • 소스 시스템에서 데이터를 추출
  • 정제와 조인을 통해 데이터를 가공
  • 분석에 적합한 저장소에 적재
• 위와 같은 ETL 프레임은 오랫동안 효과적으로 작동했다.
  • 데이터 소스는 서로 다른 시스템에 존재했고, 데이터 포맷도 제각각이었으며,
  • 누군가는 이를 분석 가능한 형태로 변환해야 했기 때문이다.
• 그러나 AI가 등장하면서 상황이 달라지고 있다.
  • SQL 생성
  • 데이터 파이프라인 코드 초안 작성
  • 스키마 매핑
• 이러한 반복적이고 기계적인 작업이 점점 자동화되면서 새로운 질문이 등장했다.
  • 앞으로도 인간이 책임져야 하는 일은 무엇인가
• Data Engineering Weekly에서 제안한 ECL 개념은 이 질문에 대한 하나의 답을 제시한다.
  • 데이터 엔지니어링의 핵심은 단순한 데이터 이동이 아니라
  • 데이터의 의미를 정의하고 유지하는 일이라는 것이다.
• 즉 데이터 엔지니어링의 중심은 데이터 이동 → 데이터 의미 관리로 점점 이동하고 있다.

---

2. ETL이 충분했던 시대, 그리고 한계

• ETL의 강점
  • 구조가 명확
  • 데이터 흐름 단순
  • 데이터 처리 과정이 직관적
• 기본 처리 흐름
  • 데이터 수집
  • 필요한 형태로 변환
  • 조회·분석 가능한 저장소에 적재
• 문제는 Transform 단계에서 발생
  • 동일 용어라도 의미가 다를 수 있음
    • Finance의 매출
    • Sales의 매출
  • 같은 컬럼이라도 의미 차이 존재
    • clickstream timestamp
    • billing record timestamp
• 문제의 원인
  • 의미 차이가 transformation 과정에서 코드 내부로 숨겨짐
  • 데이터 정의가 테이블·쿼리 안에 분산
• 현대 데이터 스택에서의 문제
  • Bronze → Silver → Gold 구조 사용
  • 하류 단계로 갈수록 원래 맥락 손실 가능
• Gold 테이블의 특징
  • 특정 질문에 최적화된 결과 데이터
  • 원천 의미를 반드시 보존하지는 않음
• 결과
  • 조회 가능한 데이터 ≠ 신뢰 가능한 데이터

비교 항목	ETL	ECL	실무에서 보이는 변화
핵심 질문	데이터를 어떻게 옮기고 바꿀까	데이터가 무엇을 뜻하고 어떻게 연결될까	운영 중심에서 의미·거버넌스 중심으로 이동
대표 산출물	파이프라인, 정제 테이블, 데이터 마트	계약, 시맨틱 정의, glossary, lineage, 엔터티 링크	코드 외부의 메타데이터 자산이 중요해짐
주요 실패 원인	배치 실패, 지연, 품질 오류	정의 불일치, 의미 드리프트, 잘못된 엔터티 매칭	겉보기엔 정상인데 해석이 틀린 상태가 문제
AI 시대의 차별점	코드 자동화가 빨라짐	정의 승인과 책임 소재는 여전히 사람의 몫	사람은 의미의 아키텍트가 됨

---

3. ECL에서 C와 L이 왜 핵심인가

• Extract
  • ECL에서도 그대로 유지되는 단계
  • 데이터는 여전히 소스 시스템에서 분석 환경으로 이동
  • 주요 고려 요소
    • 신뢰성(reliability)
    • 지연 시간(latency)
    • 장애 대응(fault tolerance)
  • ECL은 Extract 자체를 부정하지 않음

• Contextualize
  • Transformation보다 한 단계 위의 작업
  • 데이터 구조 변경이 아니라 데이터 의미 정의가 핵심
  • 데이터 계약 관점에서 포함 요소
    • 스키마 구조
    • 무결성 제약
    • 메타데이터
    • 필드 의미(semantic)
  • 데이터 계약 정의
    • 구조와 semantics를 포함하는 형식적 합의

• Contextualize에서 중요한 개념
  • Semantic Layer
    • metric 정의 중앙 관리
    • 자동 조인 처리
    • 동일한 metric 정의 재사용 가능
  • Business Glossary
    • 조직 공통 비즈니스 용어 정의
    • 비즈니스 개념과 실제 데이터 자산 연결
  • 관련 도구
    • dbt Semantic Layer
    • OpenMetadata
    • DataHub
  • 핵심 의미
    • 단순 문서화가 아님
    • 실제 쿼리와 애플리케이션에서 재사용되는 실행 가능한 의미 체계

• Link
  • 서로 다른 시스템의 엔터티 관계 연결
  • 연결 대상 예시
    • CRM 고객
    • 제품 DB 사용자
    • 분석 로그 세션
    • 고객 지원 티켓
  • 목적
    • 동일한 현실 세계 엔터티 연결
    • 데이터 맥락을 시스템 전체로 확장
  • 관련 기술
    • Entity Resolution
      • 여러 데이터 소스의 레코드 매칭
      • 레코드 연결 및 보강
  • 관련 도구
    • AWS Entity Resolution
    • OpenLineage
  • OpenLineage 역할
    • 데이터셋 및 작업에 metadata facets 기록
    • 데이터 맥락과 lineage 관리

ECL을 ETL 언어로 번역하면 Extract는 그대로, Transform은 둘로 쪼개진다.
값의 모양을 바꾸는 처리는 여전히 필요하지만, 그보다 앞서 '무엇을 뜻하는가'를 정의하는 Contextualize와, '어디와 연결되는가'를 관리하는 Link가 별도 계층으로 올라온다.

 

---

4. ECL 아키텍처는 실제로 어떻게 보일까

• ECL 아키텍처에서 Early Binding과 Late Binding을 함께 사용
• Early Binding
  • 내부 데이터에 적용
  • 생산 시점에 데이터 계약(Data Contract) 정의
  • 책임 주체가 명확한 데이터 대상
  • 계약에 포함되는 요소
    • 스키마
    • 품질 규칙
    • 의미 정의
    • 소유자
• Late Binding
  • 외부 데이터 또는 책임 경계가 불명확한 데이터에 적용
  • Contextualize 파이프라인이 의미를 추론
  • 활용되는 정보
    • 스키마 구조
    • 샘플 데이터 값
    • 데이터 분포
    • 데이터 lineage
• 핵심 기준
  • 기술 스택이 기준이 아님
  • **Accountability(책임 주체)**가 기준
  • 누가 데이터 정의에 책임질 수 있는지가 중요

• ECL에서 맥락(Context)의 이동 방식
  • 맥락이 데이터 내부에 직접 포함되는 구조가 아님
  • 데이터와 별도의 메타데이터 레이어로 관리
• 이해를 돕는 개념: OpenLineage
  • lineage metadata 기록
  • dataset metadata 관리
  • 기록되는 정보 예시
    • 어떤 job이 어떤 데이터를 입력으로 사용했는지
    • 어떤 데이터를 출력으로 생성했는지
    • 처리 과정에서 추가된 메타데이터

• ECL의 이상적인 구조
  • 또 하나의 거대한 데이터 테이블을 만드는 것이 아님
  • 별도의 메타데이터 레이어 구성
  • 포함 요소
    • 데이터 계약(Data Contract)
    • 시맨틱 정의(Semantic Definition)
    • 데이터 lineage
    • 엔터티 링크(Entity Link)
• 목적
  • 데이터 의미와 관계를 함께 조회 가능
  • 데이터 맥락을 시스템 전체에서 관리
• 정리
  • ECL은 데이터 구조 자체보다
  • 메타데이터와 의미 관리 레이어 중심 아키텍처에 가깝다.

---

5. 마무리

 

• ETL이 던진 질문
  • 데이터를 어디서 가져올 것인가
  • 데이터를 어디로 이동시킬 것인가
  • 데이터를 어떻게 변환할 것인가
• ECL이 던지는 질문
  • 이 데이터는 정확히 무엇을 의미하는가
  • 이 데이터는 무엇과 연결되는가
  • 이 데이터의 의미를 어떻게 유지할 것인가
• AI 등장 이후 변화
  • 변환 코드 자동화 증가
  • 파이프라인 구현 자동화
  • 기술적 작업의 자동화 가속
• 결과
  • 데이터 의미 관리의 중요성 증가
• ECL의 의미
  • 새로운 기술 트렌드라기보다 데이터 엔지니어링이 원래 다루던 문제를 명확하게 드러낸 개념적 프레임
• 정리
  • 데이터 이동 중심 사고 → 데이터 의미 중심 사고 전환

 

---

6. 참고자료

[1] Ananth Packkildurai, Data Engineering After AI, Data Engineering Weekly
https://www.dataengineeringweekly.com/p/data-engineering-after-ai

[2] Confluent Documentation, Data Contracts for Schema Registry on Confluent Platform
https://docs.confluent.io/platform/current/schema-registry/data-contracts.html

[3] dbt Developer Hub, Semantic Models / dbt Semantic Layer
https://docs.getdbt.com/docs/build/semantic-models

[4] OpenLineage Documentation, Facets & Dataset Metadata
https://openlineage.io/docs/spec/facets/

[5] OpenMetadata / DataHub Documentation, Business Glossary
https://docs.open-metadata.org/latest/how-to-guides/data-governance/glossary
https://datahubproject.io/docs/generated/business-glossary/

[6] AWS Documentation, What is AWS Entity Resolution?
https://docs.aws.amazon.com/entityresolution/latest/userguide/what-is-service.html