길리랩blog

레거시 데이터를 클라우드로 옮길 때 설계해야 할 마이그레이션 체계

레거시 시스템의 클라우드 데이터 마이그레이션에서 CDC, 스키마 진화, 데이터 라인리지를 설계하고 운영하는 방법을 정리합니다.

2026-08-14 · 최초 발행 2025-10-14

클라우드 이전에서 함께 다뤄야 할 데이터의 변화와 계보

레거시 DB나 파일 시스템을 클라우드 데이터 웨어하우스, 데이터 레이크, 레이크하우스로 옮기는 일은 단순 복사가 아니다. 전환 도중에도 원본 시스템은 계속 바뀌고, 대상 스키마와 소비 경로 역시 변한다. 목표 상태, 다운타임 제약, 규제 준수, 데이터 품질 기준을 먼저 정한 뒤 이행 계획을 세워야 한다.

이 과정에서 선택지는 Lift-and-Shift, Replatform, Refactor, CDC 기반 전환으로 나뉜다. 어떤 방식을 택하든 핵심은 무중단 동기화, 안전한 스키마 변경, 데이터 계보의 가시성이다.

레거시 시스템에서 클라우드로

온프레미스나 레거시 DB·파일 시스템의 데이터를 클라우드 데이터 플랫폼으로 이전하는 작업이다. 원본의 트랜잭션 특성과 데이터 보존 규칙을 파악하지 않으면 적재 이후의 정합성을 보장하기 어렵다.

스키마가 바뀌는 상황을 수용하는 방법

Schema Evolution은 시간이 흐르면서 필드 추가·제거, 타입 변경, 중첩 구조 변경이 생기는 상황과 이를 안전하게 처리하는 메커니즘을 뜻한다. Backward, Forward, Full 호환성 정책을 정하고, 스키마 레지스트리와 Parquet·Avro·Delta·Iceberg·BigQuery·Snowflake의 진화 지원 기능을 조합한다.

데이터가 거쳐 온 경로를 남기는 일

Data Lineage는 소스에서 변환과 적재를 거쳐 소비 단계에 이르는 데이터의 이동·변환 경로를 기록하고 시각화하는 체계다. 컬럼 단위 영향도를 파악하고 규정 준수 여부를 추적하는 데 쓰인다.

라인리지는 실행 시점의 OpenLineage 캡처, Apache Atlas·Data Catalog 같은 메타데이터 크롤링, 파이프라인 코드 인스트루먼테이션으로 수집할 수 있다.

이전 전에 확인할 데이터와 전환 조건

소스 데이터 프로파일링과 리버스 엔지니어링으로 데이터 볼륨·분포·품질 결함, 참조 무결성, 히스토리 보존 규칙을 확인한다. 비정상 레코드와 데이터 드리프트의 탐지 기준도 이때 정한다. 락과 일관성 레벨 같은 트랜잭션 특성, 아카이브와 파티션 전략도 함께 분석 대상이다.

전송은 배치 초기 적재와 CDC 증분 동기화를 결합해 다운타임을 낮추는 방식이 일반적이다. 컷오버는 블루-그린 또는 캔리 릴리스를 기준으로 설계할 수 있으며, CDC 소스로는 트랜잭션 로그·트리거·타임스탬프를 검토한다. 재처리와 역행 이벤트를 어떻게 처리할지도 전환 전에 정해 둬야 한다.

스키마 변경에는 허용 범위와 승인 워크플로우가 필요하다. Delta·Iceberg의 merge-on-read, BigQuery의 필드 추가 허용 같은 저장 계층 기능을 활용하되, 데이터 컨트랙트로 변경을 관리한다. 파이프라인 실행 단위의 오퍼레이션과 컬럼 매핑을 수집하면 변경 승인, 영향도 분석, 감사 리포트 자동화까지 연결할 수 있다.

품질 검증은 스키마·무결성·비즈니스 규칙 테스트를 자동화하고 샘플링보다 전량 검증을 우선한다. 샌드박스나 스테이징 환경에서 리허설을 거친 뒤 검증 통과 기준(KPI)을 충족할 때만 승격한다.

초기 적재부터 소비까지의 흐름

⤢✕운영 메커니즘통과실패체크포인트/재시도트랜잭션/락/일관성경보/온콜/자동롤백입력: Legacy DB/Files, CDC로그추출: 초기 풀로드 + CDC스테이징 저장: ObjectStorage/Lakehouse검증: 스키마/품질/무결성 체크적재: Warehouse/Lakehouse테이블 Upsert오류 큐: 재처리/격리라인리지 캡처:OpenLineage/Atlas출력: BI/ML/다운스트림서비스

평가부터 운영까지 이어지는 통제 지점

평가 단계에서는 다운타임과 규제 같은 비즈니스 제약, 데이터 볼륨과 변동률, 소스 시스템의 락 영향도를 분석한다. 목표 아키텍처와 SLO를 정하고, 데이터 분류와 보호 요구를 정리한다.

설계 단계에서는 초기 적재와 CDC 동기화 단계를 나누고 파티셔닝·정렬 키를 정한다. 대상 저장 형식과 컴퓨트 계층을 분리하며, 스키마 진화 정책·승인 프로세스·라인리지 수집과 보관 방식을 결정한다.

구현 단계의 파이프라인에는 idempotency, 체크포인트, 멱등 Upsert를 넣고 스키마 컨트랙트 유효성 검사를 배치한다. 라인리지 이벤트 인스트루먼트와 품질 테스트 자동화도 이 단계에 포함된다.

검증은 샘플, 부분, 전량 순서로 진행한다. 행 수와 해시, 합계와 통계, 참조 무결성, 샤딩 키 분포를 확인하고 회귀·리그레션 테스트와 성능 튜닝을 반복한다.

컷오버 전에 읽기 전환에 필요한 동기화 지연(lag)이 0인지 보장하고 마지막 델타를 재처리한다. 블루-그린 전환과 빠른 롤백 경로를 마련하며, 장애가 나면 타임스탬프·오프셋을 기준으로 재시도하고 트랜잭션 경계에서 재동기화한다.

운영 중에는 지연, 실패율, DQ 위반율을 SLO/SLA로 모니터링하고 비용 최적화를 수행한다. 라인리지 기반 영향도 알림, 스키마 드리프트 탐지, 데이터 계약 위반 차단이 이어져야 한다.

전환 방식별 선택 기준

접근 방식 성능 확장성 일관성 안정성 운영 편의
Lift-and-Shift 배치 중 중 높음(스냅샷) 중 높음
Replatform(호환 DB) 중상 상 중상 중상 중
Refactor(서비스화) 상 상 설계 의존 중 하
CDC 기반 무중단 중상 상 높음(정합 보장 시) 중상 중

도구, 네트워크, 소스 트랜잭션 특성에 따라 결과는 달라질 수 있다.

Spark와 Delta Lake에서 CDC를 머지하는 예시

전제조건은 다음과 같다.

  • Spark 3.4+, delta-spark 2.4+, Kafka 소스 선택적
  • 스토리지: S3/ABFS/GCS, 메타스토어 구성
  • 목적: Debezium CDC payload upsert, 신규 컬럼 자동 수용
# pyspark
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, from_json, expr
from pyspark.sql.types import StructType, StructField, StringType, LongType

spark = (SparkSession.builder
         .appName("cdc-migration")
         .config("spark.sql.shuffle.partitions", "200")
         .config("spark.databricks.delta.schema.autoMerge.enabled", "true")
         .getOrCreate())

# Debezium after payload 스키마 예시(신규 컬럼 추가 가능)
after_schema = StructType([
    StructField("id", LongType()),
    StructField("status", StringType()),
    StructField("amount", LongType()),
    # 신규 컬럼이 추가되면 schema.autoMerge로 수용
])

# 배치 예시: 초기 적재 또는 마이크로배치 처리 가능
source_df = (spark.read.format("json")
             .load("s3://staging/orders_cdc/*.json"))

parsed = (source_df
          .withColumn("after", from_json(col("payload.after").cast("string"), after_schema))
          .select(
              col("payload.op").alias("op"),
              col("after.*"),
              col("payload.ts_ms").alias("ts_ms"))
         )

# Delta 테이블 경로
target = "s3://lakehouse/tables/orders_delta"

# Delta 테이블이 없다면 생성
spark.sql(f"""
CREATE TABLE IF NOT EXISTS lake.orders
USING DELTA
LOCATION '{target}'
AS SELECT 0 as id, '' as status, 0 as amount
WHERE 1=0
""")

# 머지(삭제/업데이트/삽입), 스키마 진화 허용
from delta.tables import DeltaTable
delta_tbl = DeltaTable.forPath(spark, target)

merge_cond = "t.id = s.id"
(delta_tbl.alias("t")
 .merge(parsed.alias("s"), merge_cond)
 .whenMatchedUpdate(condition="s.op IN ('u','r')",
                    set={"status": "s.status", "amount": "s.amount"})
 .whenMatchedDelete(condition="s.op = 'd'")
 .whenNotMatchedInsert(values={
     "id": "s.id", "status": "s.status", "amount": "s.amount"
 })
 .execute())

schema.autoMerge를 활성화하면 신규 컬럼을 자동 반영할 수 있다. 타입 변경은 호환성 정책을 검토해야 한다. MERGE는 멱등 Upsert를 보장하고 Debezium op 코드를 기준으로 삭제와 갱신을 처리한다. Delta 트랜잭션 로그는 원자성과 일관성을 확보하며 타임 트래블 기반 롤백을 지원한다.

이전 환경에서 확인된 활용 장면

금융 코어 데이터 웨어하우스 전환에서는 초기 스냅샷 뒤 CDC 동기화로 다운타임 30분 이내를 달성했다. 트랜잭션 로그 기반 CDC와 최종 재동기화로 정합성을 보장하고, 스키마 변경은 Change Advisory Board 승인 후 배포했다. Atlas로 계보를 기록해 감사 리포트도 자동 생성했다.

제조 IoT 레이크하우스에서는 장비 펌웨어 업데이트로 센서 필드가 추가될 수 있다. Delta·Iceberg의 진화 기능과 데이터 계약으로 하위 호환성을 유지하고, OpenLineage와 데이터 품질 룰로 이상치·누락을 자동 탐지하며 영향도를 알린다.

커머스 주문 시스템 Replatform에서는 OLTP를 호환 DB로 마이그레이션하고 분석 계층은 레이크하우스로 분리한다. AWS DMS/Datastream 활용(최신 정보 확인 필요)과 블루-그린 컷오버, 참조 무결성 전수검증을 조합해 전환 위험을 낮춘다.

보안과 운영 비용 사이의 균형

전송·저장 암호화, KMS/HSM 기반 키 관리, 프라이빗 링크 같은 네트워크 경계가 필요하다. PII에는 토큰화와 마스킹을 적용하고 행·열 수준 접근제어를 둔다. 강한 보안 정책은 처리 지연과 운영 복잡성을 높일 수 있다.

스토리지와 컴퓨트를 분리하고 Parquet·Delta·Iceberg 같은 오픈 포맷을 채택하면 이식성을 확보할 수 있다. 스키마 레지스트리와 데이터 계약은 변경을 안정화하지만, 멀티 컴포넌트 구성은 초기 복잡도와 러닝 커브를 높인다.

운영에서는 SLO 기반 모니터링, 자동 재시도·재처리, 라인리지 기반 영향도 알림을 유지한다. 대신 라인리지와 DQ 수집은 메타데이터 시스템 비용과 오버헤드를 증가시킨다.

마이그레이션 체계가 만드는 변화

배치와 CDC를 혼합 적용하면 다운타임을 7095% 줄이고, 전량 검증과 계약 적용 시 오류율을 50% 이상 낮출 수 있다. 파티션·클러스터링·컬럼너 포맷은 쿼리 성능을 210배 개선할 수 있으며, 컴퓨트와 스토리지를 분리하면 스토리지 비용을 30~60% 절감할 수 있다.

라인리지 기반 운영은 감사 대응력과 변경 영향도 예측 가능성을 높인다. 데이터 신뢰도와 협업 효율이 개선되고, 클라우드 네이티브 분석·ML 파이프라인의 민첩성과 신규 기능 출시 리드타임에도 영향을 준다.

데이터 마이그레이션CDC스키마 진화데이터 라인리지데이터 거버넌스