Data Migration — 본질, 방법 및 데이터 전송 프로세스

Data Migration이란

Data Migration은 한 소스에서 다른 소스로 데이터를 전송하고 완료 후 무결성, 일관성 및 가용성을 보장하는 프로세스입니다. 단순 복사와 달리 마이그레이션에는 형식 변환, 중복 제거, 참조 무결성 확인 및 결과 검증이 포함됩니다.

Data Migration의 필요성은 DBMS 업그레이드(예: MySQL 5.7에서 MySQL 8.0), 클라우드 제공업체 변경, 모놀리스에서 마이크로서비스로 마이그레이션 또는 NoSQL 스키마로 전환 시 발생합니다. Stripe(2024)에 따르면, 89%의 기업이 2년에 한 번 이상 데이터 마이그레이션을 경험하며, 43%는 이를 기술 업데이트 중 가장 어려운 단계로 인식합니다.

데이터 마이그레이션의 주요 목표

첫 번째 목표는 더 현대적인 스토리지 솔루션으로 전환하여 성능을 향상시키는 것입니다. 두 번째는 인프라 제공업체 변경 시 운영 비용을 절감하는 것입니다. 세 번째는 데이터를 특정 관할권에 저장해야 하는 규제 요구사항(GDPR, 152-FZ)을 준수하도록 하는 것입니다.

마이그레이션과 통합의 차이점

통합은 두 개의 실행 중인 시스템 간의 지속적인 동기화를 포함합니다. 마이그레이션은 일회성 전송 후 소스를 폐기합니다. 통합은 소스의 데이터를 삭제하지 않으며, 마이그레이션은 대상 시스템을 기본 상태로 전환하여 종료됩니다. 이 근본적인 차이가 도구와 검증 접근 방식의 선택을 결정합니다.

데이터 마이그레이션의 ETL 모델

모든 Data Migration의 기본 아키텍처는 ETL 모델(추출, 변환, 로드)을 기반으로 합니다. 추출 — 소스에서 데이터 가져오기. 변환 — 대상 스키마로 변환. 로드 — 대상에 로드. 각 단계에는 자체 품질 관리 방법이 있습니다.

추출: 데이터 추출

추출 단계에서는 소스 데이터베이스, 파일 스토리지 또는 API에서 데이터를 읽습니다. 증분 추출(CDC — Change Data Capture)을 사용하면 변경된 레코드만 전송하여 트래픽 양을 줄일 수 있습니다. 전체 덤프는 소량의 데이터에 적합하지만 테라바이트 규모의 데이터베이스에는 Debezium 또는 Kafka Connect를 통한 스트리밍 복제가 더 좋습니다.

변환: 스키마 변환

변환에는 열 이름 변경, 데이터 유형 변경, 값 정규화 및 집계가 포함됩니다. 예를 들어 MySQL에서 PostgreSQL로 마이그레이션할 때 숫자 유형 DECIMAL은 NUMERIC으로 변환하고 날짜 형식은 ISO 8601로 변환해야 합니다. Talend(2024)에 따르면, 마이그레이션 시간의 70%가 전송이 아닌 변환에 소요됩니다.

로드: 대상에 로드

로드는 배치(batch insert) 또는 스트리밍 방식으로 수행됩니다. 중복을 제거하기 위해 멱등성 키가 사용됩니다. 로드 후에는 검증 단계가 필수입니다: 레코드 수 비교, 체크섬 계산 및 비즈니스 규칙 확인. 검증 없이는 Data Migration이 불완전한 것으로 간주됩니다.

데이터 마이그레이션 전략

Data Migration 전략의 선택은 시스템 가동 중단 시간, 롤백 복잡성 및 준비 작업량을 결정합니다. 주요 전략은 Big Bang, Trickle 및 Parallel Run입니다. 각각 다른 시나리오에 적용 가능합니다.

Big Bang 마이그레이션

Big Bang은 기존 시스템을 한 번에 종료하고 데이터를 전송한 후 새 시스템을 시작하는 것입니다. 소량의 데이터와 단순한 스키마에 적합합니다. 위험: 장애 발생 시 백업에서 완전히 복구될 때까지 시스템을 사용할 수 없습니다. 2024년 GitLab은 14시간의 가동 중단 시간으로 AWS RDS에서 GCP Cloud SQL로 5TB 데이터를 마이그레이션하기 위해 Big Bang을 사용했습니다.

Trickle 마이그레이션

Trickle은 소량씩 스트리밍 동기화하는 방식입니다. 기존 시스템과 새 시스템이 병렬로 실행되고 변경 사항이 실시간으로 복제됩니다. 데이터 안정화 후 기존 소스가 종료됩니다. 이 접근 방식은 양방향 동기화와 충돌 해결이 필요합니다. 가동 중단 없이 데이터베이스 스키마를 업데이트할 때 지속적 전달(Continuous Delivery)에서 사용됩니다.

Parallel Run

Parallel Run — 두 시스템이 동시에 작동하며 애플리케이션이 두 소스 모두에 쓰고 읽습니다. 대상에서 데이터 검증 후 기존 소스가 종료됩니다. 가장 안전한 전략이지만 두 가지 인프라를 유지해야 하므로 가장 비용이 많이 듭니다. 중요 금융 시스템을 마이그레이션할 때 사용됩니다.

데이터 마이그레이션 유형

애플리케이션 개발에서는 전송 대상과 컨텍스트에 따라 여러 유형의 Data Migration이 구분됩니다. 각 유형에는 고유한 방법론과 도구가 있습니다. 유형을 이해하는 것이 올바른 전략을 선택하는 첫 번째 단계입니다.

데이터베이스 마이그레이션(Database Migration)

Database Migration은 다른 공급업체의 DBMS 간 전송입니다: Oracle에서 PostgreSQL, SQL Server에서 MySQL, MongoDB에서 DynamoDB. 복잡성은 호환되지 않는 데이터 유형, SQL 방언 및 인덱싱 메커니즘에 있습니다. 도구: AWS DMS, Debezium, Liquibase.

애플리케이션 데이터 마이그레이션(Application Data Migration)

동일한 애플리케이션의 다른 버전 간 데이터 전송 — 예를 들어 엔티티 구조 변경과 함께 코드를 업데이트할 때. 종종 애플리케이션 언어로 마이그레이션 스크립트를 실행하는 것을 수반합니다: Ruby on Rails의 Active Record Migrations, Java용 Flyway, .NET의 Entity Framework Migrations. 이 스크립트들은 스키마와 데이터를 순차적으로 변환합니다.

클라우드 데이터 마이그레이션(Cloud Data Migration)

Cloud Data Migration은 온프레미스 인프라에서 클라우드로 또는 클라우드 간 데이터 전송입니다. AWS Snowball, Azure Data Box 및 Google Transfer Appliance는 테라바이트 규모 데이터의 물리적 운송에 사용됩니다. 온라인 마이그레이션에는 VPN 터널과 복제가 사용됩니다. Gartner에 따르면, 2027년까지 70%의 마이그레이션이 하이브리드 클라우드 환경에서 수행될 것입니다.

데이터 마이그레이션 계획

계획 없는 Data Migration은 확실한 실패입니다. 계획에는 현재 스키마 감사, 데이터 프로파일링, 전략 선택, 환경 준비, 테스트 및 롤백 계획 승인이 포함됩니다. McKinsey 연구(2024)에 따르면, 54%의 실패한 마이그레이션은 공식 계획의 부재로 인해 발생합니다.

감사 및 프로파일링

마이그레이션 전에 소스 시스템 감사가 필요합니다: 데이터 볼륨, 테이블 수, 엔티티 간 종속성, null 가능 필드 유형 및 중복 존재 여부 확인. 프로파일링은 주요 필드의 NULL 값, 형식 불일치, 끊어진 링크 등의 이상 징후를 식별합니다. 이 데이터는 전체 덤프의 기준선을 형성합니다.

테스트 환경 준비

본격적인 시작 전에 프로덕션 데이터 사본으로 테스트 마이그레이션을 수행합니다. 목표는 ETL 파이프라인 성능, 변환 정확성 및 로드 속도를 확인하는 것입니다. Big Bang 전에 최소 3번의 전체 테스트 사이클이 권장됩니다. 각 사이클에는 전체 전송, 검증 및 롤백이 포함됩니다.

롤백 계획

롤백은 심각한 오류가 감지되었을 때 원래 시스템으로 돌아가는 것입니다. 롤백 계획에는 다음이 포함됩니다: 시작 전 소스의 전체 백업, 스키마 복구 스크립트, 기존 시스템 재활성화를 위한 단계별 지침 및 사용자 알림을 위한 커뮤니케이션 계획. 승인된 롤백 계획 없이는 Data Migration을 프로덕션에서 시작해서는 안 됩니다.

데이터 마이그레이션 코드 예제

Flyway와 결합된 Kotlin의 실용적인 Data Migration 예제를 살펴보겠습니다. 마이그레이션 스크립트 V1은 users 테이블을 생성하고 레거시 형식에서 데이터를 전송합니다. Flyway는 적용된 마이그레이션을 자동으로 추적하고 멱등성을 보장합니다.

// V1__Migrate_Users.kt — 레거시 형식에서 데이터 마이그레이션
import org.flywaydb.core.api.migration.BaseJavaMigration
import java.sql.Connection
import java.sql.PreparedStatement

class V1__MigrateUsers : BaseJavaMigration() {
    override fun migrate(connection: Connection) {
        val legacyUsers = connection.prepareStatement(
            "SELECT id, name, legacy_role FROM users_legacy"
        ).executeQuery()

        val insertStmt: PreparedStatement = connection.prepareStatement(
            "INSERT INTO users (id, name, role, migrated_at) VALUES (?, ?, ?, NOW())"
        )

        while (legacyUsers.next()) {
            insertStmt.setInt(1, legacyUsers.getInt("id"))
            insertStmt.setString(2, legacyUsers.getString("name"))
            val role = mapLegacyRole(legacyUsers.getString("legacy_role"))
            insertStmt.setString(3, role)
            insertStmt.executeUpdate()
        }
    }
}

SQLAlchemy를 사용하여 CSV에서 PostgreSQL로 데이터를 전송하는 Python 마이그레이션 예제. 스크립트는 파일에서 추출하고, 유형을 변환하며 대상 테이블을 로드합니다.

# migrate_data.py — 변환과 함께 CSV를 PostgreSQL에 로드
import pandas as pd
from sqlalchemy import create_engine

engine = create_engine("postgresql://user:pass@host/db")
df = pd.read_csv("legacy_orders.csv")

df["order_date"] = pd.to_datetime(df["order_date"])
df["amount"] = df["amount"].astype("float")
df.to_sql("orders", engine, if_exists="append", index=False)

print("데이터 마이그레이션 완료")