Skip to content
Published on

NoSQL·이기종 데이터 마이그레이션 — RDB와 MongoDB와 다양한 스토어 사이에서

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

들어가며 — 마이그레이션은 데이터 복사가 아니다

이기종 데이터 마이그레이션을 처음 맡으면 "데이터를 복사하는 작업"이라고 생각하기 쉽습니다. PostgreSQL의 테이블을 MongoDB의 컬렉션으로 옮기면 되는 것 아닌가, 하고요. 하지만 곧 깨닫게 됩니다. 관계형과 문서형은 데이터를 바라보는 철학 자체가 다르고, 그 차이를 무시하면 "동작은 하지만 느리고, 일관성이 깨지고, 운영이 지옥인" 시스템이 만들어집니다.

이기종 마이그레이션의 본질은 데이터 모델 재설계입니다. 정규화된 여러 테이블을 하나의 문서로 묶을지, 아니면 참조로 남길지. 강한 일관성을 포기하고 최종 일관성을 받아들일지. 이런 결정이 복사 작업보다 훨씬 중요합니다.

이 글에서는 모델 차이의 본질부터, 방향별 마이그레이션 전략, 스트랭글러와 이중 쓰기와 CDC를 통한 점진 이전, 스키마 진화의 함정, 검증, 보조 스토어 동기화, 일관성 트레이드오프까지 다룹니다.

모델 차이의 본질 — 정규화 vs 문서/KV

먼저 각 모델의 사고방식을 정리합니다.

+----------------+------------------------+----------------------------+
|  모델           |  데이터 배치             |  최적 워크로드               |
+----------------+------------------------+----------------------------+
|  관계형 (RDB)   |  정규화, 조인으로 결합    |  복잡한 쿼리, 트랜잭션 무결성  |
|  문서 (Mongo)   |  비정규화, 한 문서에 묶음  |  애그리거트 단위 읽기쓰기     |
|  키-값 (Redis)  |  키로 직접 접근          |  캐시, 세션, 단순 조회        |
|  와이드컬럼      |  파티션 키 기반 분산       |  대량 쓰기, 시계열           |
|  검색 (ES)      |  역색인                  |  전문 검색, 집계             |
+----------------+------------------------+----------------------------+

관계형은 "데이터를 한 번만 저장하고 조인으로 조합한다"는 정규화 철학을 따릅니다. 반면 문서형은 "함께 읽는 데이터는 함께 저장한다"는 비정규화 철학을 따릅니다. 같은 "주문과 주문 항목"이라도, RDB에서는 두 테이블에 나눠 저장하고 조인하지만, MongoDB에서는 하나의 주문 문서 안에 항목 배열을 임베드하는 것이 자연스럽습니다.

이 차이가 마이그레이션의 모든 것을 결정합니다.

방향별 마이그레이션 전략

RDB에서 문서로

정규화된 테이블을 문서로 옮길 때 핵심 질문은 "임베드할 것인가, 참조할 것인가"입니다.

RDB:
  orders(id, user_id, total)
  order_items(id, order_id, product, qty)

MongoDB (임베드):
  {
    "_id": "...",
    "user_id": "...",
    "total": 50000,
    "items": [
      { "product": "키보드", "qty": 1 },
      { "product": "마우스", "qty": 2 }
    ]
  }

임베드 기준은 "함께 읽고, 함께 변하고, 무한히 커지지 않는다"입니다. 주문 항목은 주문과 함께 읽히고, 한 번 확정되면 잘 안 변하고, 개수가 제한적이므로 임베드가 적합합니다. 반대로 "한 사용자의 모든 주문"처럼 무한히 늘어나는 관계는 참조로 두거나 별도 컬렉션으로 둡니다.

// 변환 로직 (의사 코드)
async function migrateOrder(order) {
  const items = await pg.query(
    "SELECT product, qty FROM order_items WHERE order_id = $1",
    [order.id]
  );
  await mongo.collection("orders").insertOne({
    user_id: order.user_id,
    total: order.total,
    items: items.rows,
  });
}

문서에서 RDB로

반대 방향은 더 까다롭습니다. 스키마리스 문서에는 필드가 들쭉날쭉할 수 있기 때문입니다. 어떤 문서에는 phone이 있고 어떤 문서에는 없을 수 있습니다. RDB로 옮기려면 먼저 실제 스키마를 파악해야 합니다.

1. 스키마 추론: 모든 문서를 스캔해 필드의 존재율과 타입 분포를 집계
   - phone: 73% 존재, 전부 string
   - tags: 41% 존재, array of string
2. 테이블 설계: 핵심 필드는 컬럼으로, 가변 필드는 JSONB 컬럼 또는 별도 테이블
3. 임베드 배열 -> 자식 테이블로 정규화
4. 누락 필드는 NULL, 타입 충돌은 변환 규칙 정의

PostgreSQL의 JSONB 컬럼은 이 마이그레이션의 좋은 안전판입니다. 명확하게 정규화할 수 있는 필드는 컬럼으로 빼고, 애매하거나 드문 필드는 JSONB에 담아 두면 데이터 손실 없이 점진적으로 정규화할 수 있습니다.

데이터 모델 재설계

마이그레이션은 모델을 다시 생각할 좋은 기회입니다. 단순히 옛 구조를 그대로 옮기지 말고, 새 스토어의 강점을 살리는 방향으로 재설계합니다.

  • 접근 패턴 우선: "어떤 쿼리가 가장 빈번한가"를 먼저 정하고, 그 쿼리가 빠르도록 모델을 짭니다. 문서 DB는 특히 접근 패턴 중심 설계가 중요합니다.
  • 비정규화 트레이드오프: 읽기 성능을 위해 데이터를 중복 저장하면, 쓰기 시 여러 곳을 갱신해야 합니다. 읽기가 압도적으로 많은 워크로드에서 유리합니다.
  • 애그리거트 경계: 함께 변하고 함께 일관성을 지켜야 하는 데이터를 하나의 애그리거트(문서)로 묶습니다. 도메인 주도 설계의 애그리거트 개념이 그대로 적용됩니다.

점진 이전 — 스트랭글러 패턴

큰 시스템을 한 번에 갈아엎는 빅뱅 마이그레이션은 위험합니다. 대신 스트랭글러 패턴을 씁니다. 새 시스템이 옛 시스템을 조금씩 "졸라매며(strangle)" 기능을 가져오는 방식입니다.

        [클라이언트]
             |
             v
     +-----------------+
     |  라우팅 레이어    |   기능별로 신/구 분기
     +--------+--------+
          |        |
     (옛 기능)   (이전 완료 기능)
          |        |
          v        v
      [RDB]    [MongoDB]

처음에는 모든 요청이 옛 시스템(RDB)으로 가지만, 기능을 하나씩 새 시스템(MongoDB)으로 옮기면서 라우팅을 바꿉니다. 사용자 프로필을 먼저 옮기고, 검증되면 주문을, 그다음 결제를 옮깁니다. 각 단계가 작아서 문제가 생겨도 그 기능만 되돌리면 됩니다.

이중 쓰기와 CDC

점진 이전의 핵심 기술이 이중 쓰기(dual write)와 CDC(Change Data Capture)입니다.

이중 쓰기

전환 기간 동안 애플리케이션이 옛 스토어와 새 스토어 양쪽에 씁니다.

  애플리케이션
      |
      +--> RDB (옛, 여전히 정답)
      |
      +--> MongoDB (새, 검증 중)

이중 쓰기의 함정은 두 쓰기가 원자적이지 않다는 것입니다. RDB에는 썼는데 MongoDB 쓰기가 실패하면 불일치가 생깁니다. 그래서 이중 쓰기는 "검증 단계"로만 쓰고, 정합성은 별도의 대조 작업으로 보강하거나, 더 안전한 CDC로 대체하는 것이 좋습니다.

CDC — 변경 데이터 캡처

CDC는 소스 DB의 변경 로그(PostgreSQL의 WAL, MySQL의 binlog)를 읽어 변경을 스트림으로 흘려보냅니다. Debezium이 대표적입니다.

  [RDB] --WAL--> [Debezium] --> [Kafka] --> [컨슈머] --> [MongoDB]
   소스           변경 캡처       스트림        변환        타깃

CDC의 장점은 애플리케이션 코드를 건드리지 않고, 소스의 모든 변경을 누락 없이 타깃에 반영한다는 것입니다. 초기 스냅샷으로 기존 데이터를 옮긴 뒤, CDC로 그 시점 이후의 변경을 따라잡으면, 소스를 멈추지 않고 타깃을 동기화할 수 있습니다. 무중단 마이그레이션의 핵심 기법입니다.

1. 스냅샷: 소스의 현재 데이터를 통째로 타깃에 복사
2. CDC 시작: 스냅샷 시점 이후의 변경을 스트림으로 따라잡기
3. 동기화 도달: 타깃이 소스를 거의 실시간으로 따라옴 (lag ~0)
4. 컷오버: 쓰기를 타깃으로 전환, 소스 폐기

스키마 진화 — 스키마리스의 함정

문서 DB는 "스키마가 없다"고 흔히 말하지만, 정확히는 "스키마가 데이터베이스가 아니라 애플리케이션 코드에 있다"는 뜻입니다. 스키마는 사라지지 않고 코드로 옮겨갈 뿐입니다.

이것의 함정은, 시간이 지나면 같은 컬렉션 안에 서로 다른 모양의 문서가 섞인다는 것입니다.

  v1 문서: { name, email }
  v2 문서: { name, email, phone }
  v3 문서: { fullName, email, phone }   <- name -> fullName 변경

대응 전략은 두 가지입니다.

  • 스키마 버전 필드: 각 문서에 schemaVersion을 두고, 읽을 때 버전에 따라 변환합니다(lazy migration). 읽으면서 점진적으로 최신 버전으로 갱신합니다.
  • 일괄 마이그레이션 스크립트: 전체 컬렉션을 순회하며 옛 모양을 새 모양으로 변환합니다. 대량이면 배치로 나눠 실행합니다.

스키마리스라고 검증을 포기하면 안 됩니다. MongoDB의 JSON Schema validation처럼, DB 레벨에서 최소한의 제약을 거는 것이 장기 운영에 도움이 됩니다.

검증

이기종 마이그레이션의 검증은 단순 행 수 비교로는 부족합니다.

  • 행/문서 수 일치: 소스와 타깃의 레코드 수가 같은지 확인합니다. 가장 기본이지만 필수입니다.
  • 샘플 대조: 무작위로 샘플을 뽑아 필드 단위로 값을 비교합니다. 변환 로직의 버그를 잡습니다.
  • 체크섬/해시: 핵심 필드의 해시를 양쪽에서 계산해 비교합니다. 전수 비교가 어려울 때 유용합니다.
  • 비즈니스 불변식: "모든 주문의 합계는 항목 합과 같다" 같은 도메인 규칙이 타깃에서도 성립하는지 검증합니다.
검증 레벨:
  L1 수량   : count(소스) == count(타깃)
  L2 샘플   : 무작위 1% 추출 후 필드 대조
  L3 체크섬 : 정렬 후 핵심 컬럼 해시 비교
  L4 불변식 : 도메인 규칙(합계, 참조 무결성) 재검증

보조 스토어 동기화 — ElasticSearch, Redis

주 스토어를 옮기면, 거기서 파생되는 보조 스토어(검색 인덱스, 캐시)도 함께 다시 채워야 합니다.

  • ElasticSearch: 주 스토어를 진실의 원천(source of truth)으로 두고, CDC나 인덱싱 파이프라인으로 검색 인덱스를 재구축합니다. 인덱스는 언제든 주 스토어에서 다시 만들 수 있으므로, 마이그레이션 후 통째로 재색인하는 것이 깔끔합니다.
  • Redis: 캐시는 일반적으로 진실의 원천이 아니므로, 마이그레이션 후 비우고 새로 채웁니다(cache warming). 캐시에만 있던 데이터가 있다면 먼저 주 스토어로 영속화해야 합니다.
  [주 스토어 마이그레이션 완료]
        |
        +--> ElasticSearch 전체 재색인 (주 스토어 기준)
        |
        +--> Redis 비우고 워밍 (주 스토어 기준)

핵심 원칙은 "보조 스토어는 항상 주 스토어에서 재생성 가능해야 한다"입니다. 그래야 마이그레이션이 단순해집니다.

일관성 트레이드오프

이기종 마이그레이션에서 가장 어려운 결정은 일관성 수준입니다. RDB의 강한 일관성과 ACID 트랜잭션에 익숙하던 팀이 문서/분산 스토어로 옮기면, 최종 일관성을 받아들여야 하는 경우가 많습니다.

  강한 일관성 (RDB)            최종 일관성 (분산 NoSQL)
  ----------------            -----------------------
  쓰기 즉시 모두가 같은 값 봄    잠시 후 모든 노드가 수렴
  트랜잭션으로 다중 행 원자성    문서(애그리거트) 단위 원자성
  조인으로 정합성 보장          애플리케이션이 정합성 관리
  확장성 한계                  수평 확장 용이

전환 시 점검할 질문은 다음과 같습니다. 이 데이터에 정말로 강한 일관성이 필요한가? 결제·재고처럼 강한 일관성이 필수인 부분과, 좋아요 수·조회 수처럼 최종 일관성으로 충분한 부분을 구분합니다. 모든 것에 강한 일관성을 요구하면 NoSQL의 장점을 못 살리고, 모든 것을 최종 일관성으로 두면 돈이 사라지는 버그가 생깁니다.

컷오버 전략 — 언제, 어떻게 전환할 것인가

마이그레이션의 가장 긴장되는 순간은 컷오버, 즉 진실의 원천을 옛 스토어에서 새 스토어로 넘기는 순간입니다. 컷오버 방식은 위험도에 따라 몇 가지로 나뉩니다.

+--------------------+------------------------------------------------+
|  방식               |  특징                                          |
+--------------------+------------------------------------------------+
|  빅뱅 컷오버         |  한 시점에 전체 전환. 단순하지만 롤백이 어렵다     |
|  점진 컷오버(읽기)   |  읽기를 일부씩 새 스토어로 (카나리)              |
|  점진 컷오버(쓰기)   |  쓰기를 기능별로 새 스토어로                     |
|  섀도 읽기           |  새 스토어를 읽되 결과는 버리고 옛것과 대조        |
+--------------------+------------------------------------------------+

가장 안전한 접근은 섀도 읽기부터 시작하는 것입니다. 새 스토어에서도 읽되, 사용자에게는 옛 스토어의 결과를 보여주고, 두 결과를 백그라운드에서 비교합니다. 불일치가 충분히 줄어들면, 그때 읽기를 점진적으로 새 스토어로 넘깁니다. 쓰기 전환은 마지막입니다.

1. 섀도 읽기: 새 스토어 읽기 결과를 옛것과 대조 (사용자엔 옛것 노출)
2. 카나리 읽기: 트래픽 1% -> 10% -> 50% -> 100% 새 스토어로
3. 쓰기 전환: 새 스토어를 진실의 원천으로
4. 옛 스토어 폐기: 일정 기간 읽기 전용 백업으로 유지 후 제거

각 단계 사이에 충분한 관찰 기간을 두는 것이 핵심입니다. 서두르지 않는 것이 가장 빠른 길입니다.

지속적 대조 — 마이그레이션 후에도

컷오버 후에도 한동안은 옛 스토어와 새 스토어를 병행 운영하며 지속적으로 대조하는 것이 안전합니다. 이중 쓰기를 유지하면서, 주기적으로 두 스토어를 비교하는 reconciliation 잡을 돌립니다.

  [reconciliation 잡 (매시간)]
        |
        +-- 옛 스토어와 새 스토어의 레코드를 키 기준으로 비교
        |
        +-- 불일치 발견 시: 로그 + 알림 + (자동) 새 스토어 교정
        |
        +-- 불일치율 추이를 대시보드로 관찰

불일치율이 0에 수렴하고 충분한 기간 안정되면, 그때 비로소 옛 스토어를 폐기합니다. 이 "겹치는 기간"이 마이그레이션의 안전을 보장하는 보험입니다. 옛 스토어를 너무 빨리 지우면, 새 스토어의 숨은 버그가 드러났을 때 돌아갈 곳이 없습니다.

마이그레이션 도구 — AWS DMS와 CDC 파이프라인

이기종 마이그레이션을 손으로 짠 스크립트로만 하기는 어렵습니다. 전용 도구가 도움이 됩니다.

AWS DMS

AWS Database Migration Service는 이기종 마이그레이션의 대표적 관리형 도구입니다. 소스와 타깃의 종류가 달라도 동작합니다(예: Oracle에서 PostgreSQL, MySQL에서 DynamoDB). 핵심 개념은 세 가지입니다.

+----------------+------------------------------------------------+
|  개념           |  역할                                          |
+----------------+------------------------------------------------+
|  복제 인스턴스   |  마이그레이션을 실제로 수행하는 컴퓨트            |
|  엔드포인트      |  소스/타깃 DB 연결 정보                          |
|  마이그레이션 태스크 | full load(전체 복사) + CDC(이후 변경 추적)      |
+----------------+------------------------------------------------+

DMS의 마이그레이션 태스크는 보통 두 단계로 구성됩니다. full load로 기존 데이터를 통째로 옮긴 뒤, CDC로 그 시점 이후의 변경을 따라잡습니다. 이기종일 때는 타입 매핑(소스의 NUMBER가 타깃의 무엇이 될지)을 변환 규칙(transformation rule)으로 명시해야 합니다.

변환 규칙의 함정

이기종에서 가장 까다로운 부분이 타입과 인코딩 변환입니다.

주의해야 할 변환:
  - 숫자 정밀도: Oracle NUMBER(38) -> PostgreSQL numeric (정밀도 보존)
  - 날짜/시간대: 타임존 정보 유실 주의 (timestamptz로 통일)
  - 문자 인코딩: Latin-1 -> UTF-8 변환 시 깨짐
  - NULL vs 빈 문자열: Oracle은 ''와 NULL을 같게 취급, Postgres는 다르게
  - 대소문자: Oracle 식별자 대문자 기본, Postgres 소문자 기본

이런 변환은 자동 도구가 대부분 처리하지만, 엣지 케이스는 반드시 검증으로 잡아야 합니다. 특히 NULL과 빈 문자열의 차이는 조용히 데이터를 망가뜨리는 대표적 함정입니다.

시계열·그래프 등 특수 스토어로의 이전

문서·검색 외에도 데이터 특성에 맞는 특수 스토어로 옮기는 경우가 있습니다.

  • 시계열 DB(TimescaleDB, InfluxDB): 로그·메트릭처럼 시간 축이 핵심인 데이터를 옮길 때, 시간 기반 파티셔닝과 다운샘플링 정책을 함께 설계합니다. 옛 데이터는 압축·롤업하고 최근 데이터만 고해상도로 둡니다.
  • 그래프 DB(Neo4j): 관계가 일급 시민인 데이터(소셜 그래프, 추천)는 RDB의 조인 지옥에서 그래프로 옮기면 쿼리가 단순해집니다. 마이그레이션 시 외래 키를 엣지로, 행을 노드로 변환합니다.
RDB의 관계         ->  그래프
  users 행          ->  (:User) 노드
  follows(a, b)     ->  (:User)-[:FOLLOWS]->(:User) 엣지
  복잡한 N단계 조인   ->  가변 길이 경로 쿼리 (단순)

핵심은 데이터의 본질적 형태에 맞는 스토어를 고르는 것입니다. 모든 것을 RDB에 욱여넣지 않고, 시계열은 시계열 DB로, 관계는 그래프로 옮기면 각각의 강점을 살릴 수 있습니다.

사례 — 모놀리식 RDB에서 문서 + 검색으로

가상의 전자상거래 팀 사례를 정리합니다.

초기:  PostgreSQL 하나에 모든 것 (사용자, 상품, 주문, 검색은 LIKE 쿼리)
문제:  상품 검색이 느림(LIKE %키워드%), 상품 카탈로그 스키마가 자주 변함
       (유연한 속성 필요), 트래픽 증가로 단일 DB 부하

전략:
  1. 상품 카탈로그를 MongoDB로 (유연한 속성, 문서 모델 적합)
  2. 상품 검색을 ElasticSearch로 (전문 검색, 패싯)
  3. 주문·결제는 PostgreSQL 유지 (강한 일관성 필요)

이전:
  - CDC(Debezium)로 PostgreSQL 상품 -> MongoDB 동기화
  - MongoDB -> ElasticSearch 인덱싱 파이프라인
  - 스트랭글러로 상품 조회 트래픽을 점진 전환
  - 검증 후 컷오버, 옛 상품 테이블은 읽기 전용으로 일정 기간 유지

핵심은 모든 것을 옮기지 않았다는 점입니다. 강한 일관성이 필요한 주문·결제는 RDB에 남기고, 유연성과 검색이 필요한 부분만 옮겼습니다. 이기종 환경에서는 "각 데이터에 맞는 스토어"를 고르는 폴리글랏 퍼시스턴스가 정답인 경우가 많습니다.

폴리글랏의 운영 부담

이기종으로 옮기면 각 데이터에 맞는 스토어를 쓰는 폴리글랏 퍼시스턴스의 이점을 얻지만, 운영 부담도 함께 늘어납니다. 이 트레이드오프를 솔직하게 인정해야 합니다.

폴리글랏의 비용:
  - 운영 복잡도: DB마다 백업·모니터링·튜닝·장애 대응이 다름
  - 일관성 경계: 스토어 간 데이터 동기화/정합성 관리 필요
  - 인지 부하: 팀이 여러 데이터 모델과 쿼리 언어를 알아야 함
  - 트랜잭션 부재: 스토어를 가로지르는 원자성이 없음

그래서 "옮길 수 있다"와 "옮겨야 한다"는 다릅니다. 새 스토어로 옮겨 얻는 이득(성능, 유연성, 확장성)이 늘어나는 운영 부담을 명확히 넘어설 때만 옮깁니다. 종종 가장 좋은 답은 "PostgreSQL의 JSONB로 충분하다"이거나 "지금은 RDB로 버티고 진짜 병목이 생기면 그때 옮긴다"입니다. 마이그레이션은 수단이지 목적이 아닙니다.

판단 기준을 표로 정리하면 다음과 같습니다.

+---------------------------+--------------------------------------+
|  이럴 때 옮긴다             |  이럴 때 머문다                        |
+---------------------------+--------------------------------------+
|  현재 스토어가 명확한 병목   |  성능 여유가 아직 충분                  |
|  데이터 모델이 근본적으로 안 맞음| JSONB 등으로 흡수 가능               |
|  새 스토어 운영 역량이 있음  |  팀이 새 스토어를 운영해 본 적 없음      |
|  이득이 운영 부담을 명확히 상회|  "최신 기술이라서"가 유일한 이유        |
+---------------------------+--------------------------------------+

흔한 함정

  • 빅뱅 마이그레이션: 한 번에 다 옮기려다 롤백 불가에 빠집니다. 스트랭글러로 쪼갭니다.
  • 모델을 그대로 복사: RDB 테이블을 문서로 1:1 복사하면 조인이 필요한 느린 문서 DB가 됩니다. 접근 패턴 기준으로 재설계합니다.
  • 이중 쓰기 원자성 착각: 두 쓰기는 원자적이지 않습니다. 불일치 보정 메커니즘이 필요합니다.
  • 검증을 행 수로만: 수량은 맞는데 값이 틀린 경우가 흔합니다. 샘플·체크섬·불변식까지 검증합니다.
  • 일관성 요구 과잉/과소: 부분별로 필요한 일관성 수준을 구분하지 않으면 성능을 잃거나 데이터가 깨집니다.
  • 보조 스토어 누락: 검색 인덱스와 캐시를 잊으면 마이그레이션 후 검색이 안 되거나 옛 데이터가 캐시에 남습니다.

체크리스트

  • 접근 패턴을 먼저 정의하고 그에 맞게 모델을 재설계했는가
  • 임베드 vs 참조 기준을 명확히 했는가
  • 스트랭글러로 점진 이전 계획을 세웠는가
  • CDC 또는 이중 쓰기로 무중단 동기화 경로를 마련했는가
  • 스키마 진화 전략(버전 필드 또는 일괄 변환)을 정했는가
  • 수량·샘플·체크섬·불변식 4단계 검증을 준비했는가
  • 보조 스토어(검색·캐시) 재구축 계획이 있는가
  • 데이터별로 필요한 일관성 수준을 구분했는가
  • 컷오버 실패 시 롤백 경로가 있는가

마치며

이기종 데이터 마이그레이션은 데이터를 옮기는 작업이 아니라, 데이터를 다시 모델링하는 작업입니다. 관계형의 정규화 사고에서 문서형의 애그리거트 사고로, 강한 일관성에서 최종 일관성으로의 전환은 단순한 도구 교체가 아니라 설계 철학의 전환입니다. 스트랭글러로 작게 쪼개고, CDC로 무중단으로 옮기고, 네 단계로 검증하고, 각 데이터에 맞는 일관성을 고르는 것. 이 원칙을 지키면, 이기종 마이그레이션은 위험한 도박이 아니라 통제된 진화가 됩니다.

참고 자료

Discuss on Twitter • View on GitHub