DataStage 및 Informatica에서 Databricks Medallion Architecture로: 마이그레이션이 단순한 코드 변환

레거시 ETL 현대화는 종종 기술 마이그레이션으로 묘사됩니다.

DataStage 작업을 Databricks로 이동합니다.
Informatica 매핑을 PySpark로 변환합니다.
레거시 워크플로우를 노트북(notebooks)과 Delta 테이블(Delta tables)로 교체합니다.

하지만 그러한 설명은 가장 어려운 부분을 놓치고 있습니다.

진정한 과제는 구문(syntax)을 변환하는 것이 아닙니다.

과제는 수년간 숨겨져 온 변환 로직(transformation logic)을 이해하고, 데이터 리니지(data lineage)를 재구성하며, 기술적 처리와 비즈니스 로직을 분리하고, 현대적인 아키텍처에서 각 책임이 어디에 속해야 하는지를 결정하는 것입니다.

DataStage 작업이나 Informatica 매핑은 하나의 워크플로우 안에 원시 수집(raw ingestion), 데이터 정제(data cleansing), 룩업(lookups), 조인(joins), 비즈니스 규칙, 집계(aggregations), 오류 처리(error handling) 및 보고 로직을 모두 포함하고 있을 수 있습니다.

Databricks Medallion 아키텍처는 이와 다른 방식을 기대합니다.

이 아키텍처는 데이터 처리를 더 명확한 계층으로 분리합니다:

Bronze (브론즈)
원시 수집(Raw ingestion) 및 소스 보존
Silver (실버)
정제(Cleansing), 표준화(standardization), 강화(enrichment), 일치(conformance) 및 품질 제어
Gold (골드)
비즈니스 준비 모델, 집계(aggregates), KPI, 보고용 데이터 세트 및 시맨틱 출력(semantic outputs)

즉, 성공적인 마이그레이션은 맹목적인 일대일 변환이 되어서는 안 됩니다.

그것은 메타데이터(metadata) 및 아키텍처 설계 과정이 되어야 합니다.

⸻

일대일 변환이 실패하는 이유

전통적인 레거시 ETL 작업은 종종 다음과 같은 형태를 띱니다:

소스 데이터 읽기
→ 레코드 필터링
→ 참조 데이터 룩업(Lookup)
→ 값 정제
→ 중복 제거
→ 비즈니스 계산 적용
→ 집계
→ 보고 출력 작성

문제는 이 모든 책임이 하나의 작업, 매핑, 시퀀스 또는 워크플로우 내에 존재할 수 있다는 점입니다.

예를 들어, 단일 DataStage 작업은 다음과 같은 일을 수행할 수 있습니다:

• Oracle에서 데이터 수집
• 취소된 레코드 제거
• 공백 제거(trim whitespace)
• 상태 값 표준화
• 고객 마스터 데이터 조인
• 순 주문 금액 계산
• 월별 매출 집계
• 보고용 테이블 작성

만약 그 작업 전체를 하나의 Databricks 노트북으로 직접 변환한다면, 조직은 단순히 새로운 플랫폼에서 기존의 아키텍처를 재현하는 것에 그칠 수 있습니다.

코드는 Databricks에서 실행될 수 있지만, 설계 자체가 유지보수, 테스트, 거버넌스(Governance) 및 확장(Scale)을 어렵게 남겨둘 수 있습니다.

목표는 다음과 같아서는 안 됩니다:

기존의 레거시 잡(Job) 하나를 하나의 노트북으로 변환하는 것.

목표는 다음과 같아야 합니다:

각 변환(Transformation)이 무엇을 수행하는지 이해하고, 이를 적절한 현대적 데이터 레이어(Data Layer)에 배치하는 것.

⸻

첫 번째 단계: 코드만이 아닌 메타데이터(Metadata) 추출

레거시 ETL 마이그레이션은 기존 플랫폼에서 구조화된 메타데이터를 추출하는 것부터 시작해야 합니다.

DataStage, Informatica, SSIS, Talend, 저장 프로시저(Stored Procedures) 또는 기타 ETL 도구의 경우, 유용한 메타데이터에는 다음이 포함될 수 있습니다:

• 잡(Job) 또는 매핑(Mapping) 이름
• 워크플로(Workflow) 의존성
• 소스 테이블, 파일 및 API
• 타겟 테이블 및 파일
• 소스-타겟 필드 매핑(Field Mappings)
• 조인(Join) 및 룩업(Lookup) 로직
• 필터(Filter) 및 조건
• 변환 표현식(Transformation Expressions)
• 집계(Aggregations)
• 대리 키(Surrogate Key) 생성
• 거부(Reject) 처리
• 파라미터(Parameter) 값
• 스케줄 및 시퀀싱(Sequencing)
• Pre-SQL 및 Post-SQL
• 재시작(Restart) 또는 복구(Recovery) 로직
• 에러 처리(Error-handling) 동작

이 목적은 레거시 잡에 대한 구조화된 표현을 만드는 것입니다.

레거시 ETL 내보내기 (Export)
→ 메타데이터 파서 (Metadata Parser)
→ 정형 메타데이터 모델 (Canonical Metadata Model)
→ 변환 그래프 (Transformation Graph)
→ 마이그레이션 청사진 (Migration Blueprint)

이는 단순히 변환 코드를 한 줄씩 읽는 것보다 훨씬 더 가치 있는 작업입니다.

⸻

변환 그래프(Transformation Graph) 재구성

메타데이터가 추출되면, 다음 단계는 데이터 리니지(Data Lineage)와 변환 그래프를 재구성하는 것입니다.

다음의 가상의 예시를 고려해 보십시오:

orders.csv
↓
취소된 주문 필터링 (Filter cancelled orders)
↓
고객 마스터 룩업 (Lookup customer master)
↓
고객 상태 표준화 (Standardize customer status)
↓
order_id 기준 중복 제거 (Deduplicate by order_id)
↓
주문 금액 계산 (Calculate order_amount)
↓
월간 매출 집계 (Aggregate monthly sales)
↓
monthly_sales_summary

이 그래프는 여러 가지 서로 다른 종류의 작업을 드러냅니다:

• 원천 데이터 수집 (Raw Ingestion)
• 필터링 (Filtering)
• 인리치먼트 (Enrichment)
• 표준화 (Standardization)
• 중복 제거 (Deduplication)
• 비즈니스 계산 (Business Calculation)
• 보고용 집계 (Reporting Aggregation)

이것들을 모두 하나의 기술적 단위로 취급해서는 안 됩니다.

변환 그래프 (Transformation graph)는 데이터가 어디서 변하는지, 왜 변하는지, 그리고 어떤 다운스트림 출력물 (downstream outputs)이 해당 변경 사항에 의존하는지를 식별하는 데 도움을 줍니다.

또한 이는 숨겨진 비즈니스 로직 (business logic)을 가시화합니다.

⸻

레거시 ETL 로직을 Bronze, Silver, Gold로 매핑하기

Medallion 아키텍처 (Medallion architecture)는 책임을 분리하기 때문에 유용합니다.

다음은 레거시 ETL 로직을 분류하는 실질적인 방법입니다.

레거시 ETL 패턴	의미	예상되는 Medallion 레이어
파일, API, 데이터베이스 또는 CDC 추출	원천 소스 수집 (Raw source ingestion)	Bronze
소스 보존 및 수집 메타데이터	원본 소스 상태 캡처	Bronze
기본 스키마 강제 (Schema enforcement)	표준화된 수집	Bronze 또는 Silver
Trim, cast, 이름 변경, null 정리	정제 및 표준화 (Cleansing and standardization)	Silver
중복 제거 (Deduplication)	레코드 정규화 (Record normalization)	Silver
Lookup 및 참조 조인 (Reference joins)	풍부화 및 일치 (Enrichment and conformance)	Silver
SCD 처리	이력 차원 처리 (Historical dimensional processing)	Silver
비즈니스 계산	큐레이션된 비즈니스 로직	Gold
집계 및 KPI 생성	보고용 지표 (Reporting-ready metrics)	Gold
대시보드/보고서 출력	소비 준비 완료된 데이터셋	Gold

중요한 점은 레거시 컴포넌트 유형이 자동으로 Medallion 레이어를 결정하지 않는다는 것입니다.

예를 들어, DataStage의 Transformer 스테이지 (Transformer stage)는 다음과 같은 작업을 수행할 수 있습니다:

• 문자열 트리밍 (string trimming)
• null 처리 (null handling)
• 비즈니스 계산 (business calculation)
• 고객 룩업 (customer lookup)
• 보고용 집계 (reporting aggregation)

이것들이 모두 Silver 변환 (Silver transformations)인 것은 아닙니다.

마이그레이션 프로세스는 로직의 의도 (intent)를 조사해야 합니다.

⸻

예시: 하나의 레거시 잡 (Legacy Job)이 여러 Databricks 레이어가 되는 과정

다음과 같은 가상의 레거시 ETL 워크플로우 (workflow)를 가정해 보겠습니다:

Oracle Orders
→ Transformer: 문자열 트리밍 및 상태 표준화
→ Lookup: 고객 마스터 (customer master)
→ Transformer: net_amount 계산
→ Aggregator: 고객별 월간 매출
→ 보고용 테이블 (Reporting table)

현대적인 Databricks Medallion 제안은 다음과 같을 수 있습니다:

Bronze 레이어 (Bronze Layer)
bronze_orders_raw

• Oracle 원시 주문 데이터 수집 (Ingest raw Oracle orders)
• 소스 필드 보존 (Preserve source fields)
• 수집 타임스탬프 추가 (Add ingestion timestamp)
• 소스 식별자 추가 (Add source identifier)
• 로드 날짜 추가 (Add load date)
• 추적 가능성을 위해 원시 레코드 유지 (Retain raw records for traceability)

Silver 레이어 (Silver Layer) silver_orders

• 문자열 필드 정리 및 표준화 (Trim and standardize string fields)
• 상태 값 표준화 (Standardize status values)
• 스키마 검증 (Validate schema)
• Null 처리 규칙 적용 (Apply null-handling rules)
• 주문 레코드 중복 제거 (Deduplicate order records)

silver_orders_enriched

• 고객 마스터 데이터 조인 (Join customer master data)
• 고객 키 해결 (Resolve customer keys)
• 표준화된 강화 로직 적용 (Apply standardized enrichment logic)
• 정규화된 net_amount 계산 (Calculate normalized net_amount)

Gold 레이어 (Gold Layer) gold_customer_monthly_sales

• 고객 및 월별 순매출 집계 (Aggregate net sales by customer and month)
• 승인된 보고 정의 적용 (Apply approved reporting definitions)
• 큐레이션된 비즈니스 준비 완료 출력 생성 (Produce a curated business-ready output)

이는 더 명확한 소유권을 생성합니다.

Bronze는 소스를 보존합니다.

Silver는 신뢰할 수 있고 재사용 가능한 데이터를 준비합니다.

Gold는 비즈니스 지향적인 출력을 제공합니다.

⸻

AI가 지원할 수 있는 부분

AI는 이 마이그레이션 프로세스를 더 빠르고 구조적으로 만들 수 있습니다.

예를 들어, AI 지원 마이그레이션 워크플로우는 다음과 같은 작업을 도울 수 있습니다:

• 레거시 작업 목적 요약 (summarize legacy job purpose)
• 변환 표현식 파싱 (parse transformation expressions)
• 소스 및 타겟 의존성 식별 (identify source and target dependencies)
• 리니지 재구성 (reconstruct lineage)
• 의도에 따른 변환 분류 (classify transformations by intent)
• 내장된 비즈니스 로직 탐지 (detect embedded business logic)
• Bronze, Silver, Gold 배치 제안 (suggest Bronze, Silver, and Gold placement)
• PySpark 또는 Spark SQL 초안 작성 (draft PySpark or Spark SQL)
• Delta 테이블 DDL 생성 (generate Delta table DDL)
• 데이터 품질 검사 제안 (propose data-quality checks)
• 대조 로직 생성 (generate reconciliation logic)
• 마이그레이션 문서 생성 (create migration documentation)
• 불분명하거나 위험한 규칙 식별 (identify unclear or risky rules)

레거시 규칙이 다음과 같다고 가정해 봅시다:

IF status_code = 'C' THEN 'Closed' ELSE 'Open'

AI 시스템은 다음과 같이 제안할 수 있습니다:

예상 분류:
Silver 레이어 표준화 규칙

잠재적 우려 사항:
status_code = 'C'가 모든 소스 시스템에서 'Closed'를 의미하는지 확인 필요

권장 조치:
표준화 규칙을 확정하기 전에 인간의 검토 필요

이는 시스템이 비즈니스 정의를 아는 척하지 않기 때문에 유용합니다.

시스템은 내려야 할 결정을 표면화하는 것입니다.

⸻

여전히 인간의 검토가 필요한 부분

AI가 분석과 초안 작성을 가속화할 수는 있지만, 인간의 책임(accountability)은 여전히 필수적입니다.

인간은 다음 사항에 대해 최종 결정을 계속 내려야 합니다:

• 비즈니스 정의 (business definitions)
• 신뢰할 수 있는 단일 원천 (source-of-truth) 선택
• 재무 로직 (financial logic)
• 규제 관련 계산 (regulatory calculations)
• 데이터 보존 정책 (data-retention policies)
• 예외 처리 (exception handling)
• 데이터 품질 임계값 (data-quality thresholds)
• 보고 지표 (reporting metrics)
• 운영 환경 배포 승인 (production deployment approval)

예를 들어, 레거시 집계(aggregation)는 다음과 같이 계산할 수 있습니다:

SUM(revenue) BY region, month

기술적 마이그레이션 시스템은 Gold 레이어를 추천할 수 있습니다.

하지만 인간은 여전히 다음 질문에 답해야 합니다:

• 매출(revenue)이 총매출(gross)인가요, 아니면 순매출(net)인가요?
• 환불액이 포함되어 있나요?
• 월(month)은 달력 기준 월인가요, 아니면 회계 기준 월인가요?
• 지역(region)은 고객, 매장, 또는 영업 구역 중 어디에서 파생되었나요?
• 이 지표는 여러 보고서에서 재사용 가능한가요?

이것들은 단순한 코딩 문제가 아니라 비즈니스 및 거버넌스(governance) 문제입니다.

⸻

표준 메타데이터 모델 (Canonical Metadata Model)의 역할

표준 메타데이터 모델 (Canonical Metadata Model)은 레거시 ETL과 현대적 데이터 아키텍처 사이의 가교 역할을 할 수 있습니다.

이 모델은 다음을 표현할 수 있습니다:

• 소스 (sources)
• 타겟 (targets)
• 컬럼 (columns)
• 변환 (transformations)
• 조인 (joins)
• 키 (keys)
• 데이터 타입 (data types)
• 품질 기대치 (quality expectations)
• 리니지 (lineage)
• 비즈니스 정의 (business definitions)
• 승인 상태 (approval status)
• 가정 사항 (assumptions)
• 마이그레이션 결정 사항 (migration decisions)

메타데이터가 정규화되면, 동일한 신뢰할 수 있는 원천(source of truth)으로부터 여러 개의 결과물을 생성할 수 있습니다.

표준 메타데이터 모델 (Canonical Metadata Model)
→ Databricks Medallion Architecture 제안서
→ PySpark / Spark SQL
→ Delta Table DDL
→ 데이터 품질 규칙 (Data Quality Rules)
→ 대조 확인 (Reconciliation Checks)
→ 리니지 문서화 (Lineage Documentation)
→ 마이그레이션 사양서 (Migration Specification)
→ 인간 검토 대기열 (Human Review Queue)

이는 고립된 코드 변환보다 더 강력한데, 재사용 가능한 엔지니어링 지능(engineering intelligence)을 생성하기 때문입니다.

⸻

데이터 엔지니어링 코파일럿 (Data Engineering Copilot)이 레거시 ETL 마이그레이션을 지원하는 방법

미래의 데이터 엔지니어링 코파일럿 (Data Engineering Copilot) 기능은 레거시 ETL 마이그레이션 코파일럿 (Legacy ETL Migration Copilot) 역할을 수행할 수 있습니다.

입력값에는 다음이 포함될 수 있습니다:

• DataStage export 파일
• Informatica 매핑 (mapping) export
• 워크플로 (workflow) 메타데이터
• SQL 프로시저 (procedures)
• ETL 작업 문서
• 소스-대상 매핑 (source-to-target mappings)
• 데이터 모델 문서

워크플로 (workflow) 과정은 다음과 같을 수 있습니다:

레거시 ETL 내보내기 (Export)
→ 작업 메타데이터 파싱 (Parse)
→ 변환 그래프 (Transformation Graph) 구축
→ 의존성 (Dependencies) 식별
→ 변환 의도 (Transformation Intent) 분류
→ Bronze / Silver / Gold 레이어 제안
→ 마이그레이션 산출물 (Artifacts) 생성
→ 모호성 플래그 지정
→ 인간 검토를 위한 라우팅

잠재적인 출력값에는 다음이 포함될 수 있습니다:

• 메달리온 아키텍처 (Medallion architecture) 권장 사항
• Bronze, Silver, Gold 파이프라인 설계
• Databricks 노트북 구조
• PySpark 코드 초안
• Spark SQL 변환
• Delta 테이블 정의
• 데이터 품질 (data-quality) 규칙
• 대조 (reconciliation) 체크
• 마이그레이션 문서
• 의존성 분석
• 리니지 (lineage) 다이어그램
• 해결되지 않은 로직에 대한 검토 질문

핵심은 감독 없는 자동 마이그레이션이 아닙니다.

핵심은 숨겨진 레거시 ETL 로직을 검토 가능한 현대화 청사진 (modernization blueprint)으로 전환하는 것입니다.

⸻

마이그레이션은 메타데이터 및 아키텍처의 문제입니다

많은 레거시 ETL 현대화 시도가 실패하는 이유는 도구 교체에만 집중하기 때문입니다.

하지만 오래된 ETL 작업에는 수년간 축적된 비즈니스 지식이 포함되어 있는 경우가 많습니다.

그 지식은 문서화되어 있지 않을 수 있습니다.

변환 (transformations), 룩업 (lookups), 저장 프로시저 (stored procedures), 필터 (filters), 시퀀싱 규칙 (sequencing rules), 예외 로직 (exception logic) 내부에 숨겨져 있을 수 있습니다.

성공적인 마이그레이션은 아키텍처를 개선하는 동시에 해당 지식을 보존해야 합니다.

즉, 마이그레이션 프로세스는 다음과 같아야 합니다:

메타데이터 추출
→ 리니지 (lineage) 재구성
→ 변환 의도 식별
→ 기술적 책임과 비즈니스 책임 분리
→ 메달리온 (Medallion) 레이어 제안
→ 검토 가능한 산출물 생성
→ 가정 사항 캡처
→ 인간의 승인 요구

ETL 현대화의 미래는 단순히 하나의 도구를 다른 도구로 번역하는 것이 아닙니다.

레거시 데이터 로직을 가시화하고, 구조화하며, 거버넌스(governed)를 적용하고, 재사용 가능하게 만드는 것입니다.

⸻

맺음말

DataStage 및 Informatica 작업(job)은 데이터 수집(ingestion), 정제(cleansing), 비즈니스 로직(business logic), 그리고 리포팅(reporting)이 밀접하게 결합되어 있던 시대에 구축된 경우가 많았습니다.

Databricks Medallion 아키텍처(architecture)는 팀들에게 이러한 책임들을 분리하고, 더 깨끗하며 유지보수가 용이한 데이터 제품(data products)을 만들 수 있는 기회를 제공합니다.

하지만 조직이 맹목적인 일대일 변환(one-to-one conversion)을 수행할 때 그 기회는 사라집니다.

더 나은 접근 방식은 레거시 ETL 현대화를 메타데이터 기반(metadata-driven) 아키텍처 설계 작업으로 취급하는 것입니다.

단순히 레거시 작업(job)을 새로운 코드로 변환하지 마십시오.
숨겨진 변환 로직(transformation logic)을 검토 가능한 현대화 청사진(modernization blueprint)으로 변환하십시오.

바로 이 지점에서 AI 지원 메타데이터 플랫폼이 엔터프라이즈 데이터 엔지니어링(data engineering) 팀을 위해 진정한 가치를 창출할 수 있습니다.

⸻

Data Engineering Copilot은 메타데이터 기반 엔지니어링(metadata-driven engineering)과 거버넌스가 적용된 전달 워크플로(governed delivery workflows)에 초점을 맞춘 개인적인 제품 이니셔티브입니다.

이 기사의 예시들은 가상의 메타데이터만을 사용합니다. 어떠한 고객, 고용주, 운영 환경 또는 독점 정보도 포함되어 있지 않습니다.