레거시 재구축에서 데이터 이관이 프로젝트를 잡아먹는 이유

결론부터: 이관은 배포 작업이 아니라 분석 작업입니다

레거시 재구축 프로젝트가 일정을 넘기는 지점은 대개 신규 기능 개발이 아닙니다. 화면과 API는 요구사항이 문서로 존재하고, 만들다 보면 진척률이 눈에 보이고, 늦으면 범위를 줄여 협상할 수 있습니다. 데이터 이관은 그 어느 것도 해당하지 않습니다. 요구사항이 문서가 아니라 수십 년 치 실제 데이터 안에 흩어져 있고, 진척률은 마지막에야 드러나며, 범위를 줄이는 협상이 거의 불가능합니다. 과거 데이터의 절반만 옮기고 오픈하겠다고 말할 수 있는 조직은 드뭅니다.

그래서 결론을 먼저 말하면 이렇습니다. 데이터 이관은 프로젝트 후반의 배포 작업이 아니라, 착수 첫 주에 시작해야 하는 분석 작업입니다. 이관 담당자가 실제 데이터를 처음 열어보는 시점이 곧 프로젝트의 진짜 시작 시점이고, 그 시점이 늦어진 만큼 일정은 그대로 밀립니다. 이 글은 왜 그런지, 그리고 어떤 순서로 판단하고 실행해야 하는지를 정리합니다.

왜 항상 과소평가되는가

이관 일정은 보통 이렇게 산정됩니다. 테이블이 몇 개인지 세고, 인당 하루에 몇 개를 처리할 수 있다고 가정하고, 나눕니다. 이 계산이 틀리는 이유는 작업량이 테이블 수에 비례하지 않기 때문입니다. 실제 작업량은 변환 규칙의 수에 비례하고, 더 정확히는 아직 발견하지 못한 예외의 수에 비례합니다.

문제는 예외를 미리 셀 수 없다는 점입니다. 예외는 데이터를 실제로 읽어야 발견되고, 데이터를 읽으려면 접근 권한과 사본이 필요하며, 그 절차는 조직에서 가장 느리게 움직이는 일 중 하나입니다. 결국 이관 일정 산정은 "우리가 아직 모르는 것이 얼마나 되는가"에 대한 추정이 되고, 그런 추정은 대개 낙관 쪽으로 기웁니다.

구조적인 이유도 있습니다. 이관은 인력 배치에서 후순위로 밀립니다. 신규 개발이 어느 정도 끝나야 사람이 붙는 구조가 흔하고, 그때는 이미 남은 기간이 짧습니다. 그리고 이관 실패는 컷오버 당일 새벽에 드러납니다. 다른 결함은 오픈 후에 고칠 수 있지만, 이관 결함은 되돌릴 시간이 없는 순간에 나타납니다. 과소평가의 대가가 유독 비싼 이유입니다.

한 가지 더 있습니다. 이관은 담당자가 명확하지 않은 일입니다. 신규 개발은 화면 단위, 도메인 단위로 주인이 정해지지만, 이관은 개발 조직과 업무 조직 사이에 걸쳐 있습니다. 개발자는 "이 값을 어떻게 처리할지는 업무에서 정해줘야 한다"고 하고, 업무 담당자는 "그건 시스템이 알아서 옮기는 것 아니냐"고 합니다. 이 공백은 저절로 메워지지 않습니다. 착수 시점에 이관 총괄 한 명과 업무 측 결정권자를 이름으로 지정해 두지 않으면, 프로젝트 후반에 같은 대화를 반복하게 됩니다.

스키마는 협상 가능하고, 데이터는 아닙니다

이관 설계를 시작하면 대부분 스키마 매핑표부터 만듭니다. 원천 컬럼과 대상 컬럼을 나란히 놓고 타입 변환을 적는 작업입니다. 이 일은 지루하지만 기계적이고, 예상 가능하며, 대체로 예상한 시간 안에 끝납니다. 진짜 비용은 그다음에 나옵니다.

실제로 시간을 잡아먹는 것들

• 필수값이 비어 있는 과거 데이터 — 신규 모델에서 NOT NULL로 정의한 컬럼이 과거에는 선택 입력이었던 경우입니다. 값을 지어낼 수도, 그 건을 버릴 수도 없습니다.
• 코드값 표류 — 코드 테이블에 없는 코드가 실데이터에 존재하고, 같은 의미의 코드가 시기별로 여러 개이며, 앞뒤 공백이나 대소문자만 다른 변종이 섞여 있습니다.
• 참조 무결성 부재 — 외래키 제약이 없던 시스템에서는 부모가 사라진 고아 레코드가 거의 예외 없이 나옵니다.
• 유일하다고 믿었던 키의 중복 — 자연키로 알고 설계를 진행했는데 실데이터에서 중복이 나오는 경우입니다. 이건 이관 문제가 아니라 신규 모델 재설계 문제로 번집니다.
• 자유 텍스트에 파묻힌 업무 규칙 — 비고란에 특정 문구가 들어 있으면 취소 건으로 취급한다는 규칙이 코드 어디에도 없고 담당자 머릿속에만 있는 경우입니다.
• 상태값의 모순 — 삭제 여부, 사용 여부, 상태 코드가 서로 다른 시기에 추가되어 조합이 논리적으로 맞지 않는 행이 존재합니다.
• 시간 표현 — 문자열 날짜, 타임존 정보가 없는 로컬 시각, 미래를 뜻하는 99991231 같은 센티널 값이 함께 있습니다. 오프셋 없이 저장된 시각을 UTC 기준 타입으로 옮기면 어떤 지역 시각으로 해석할지부터 결정해야 합니다.
• 금액과 수량의 정밀도 — 반올림 규칙이 DB가 아니라 화면단이나 리포트에만 존재해서, 그대로 옮기면 합계가 어긋납니다. 금액이 부동소수점 타입에 들어 있으면 더하는 순서만 달라져도 합계 끝자리가 흔들립니다.
• 인코딩 — 문자셋 전환기를 거친 시스템에는 이중 인코딩되거나 깨진 문자열이 남아 있습니다. 이모지나 일부 한자처럼 저장 시점에 잘려 나간 문자도 있습니다.

이 목록의 공통점은, 문제의 정답을 개발자가 정할 수 없다는 것입니다. 필수값이 빈 과거 계약 건을 어떻게 할지, 고아 레코드를 살릴지 버릴지, 중복 키를 어떤 기준으로 병합할지는 업무 담당자의 결정 사항입니다. 그래서 이관 일정에서 가장 긴 구간은 코딩 시간이 아니라 의사결정 대기 시간인 경우가 많습니다. 이관은 데이터를 옮기는 일이 아니라 과거의 예외를 신규 모델 안에서 어떻게 표현할지 결정하는 설계 작업이고, 설계에는 결정권자가 필요합니다.

첫 주에 할 일: 프로파일링

가장 먼저 세워야 할 마일스톤은 설계서 작성이 아니라 실데이터 또는 마스킹 사본에 대한 접근권 확보입니다. 이게 늦어지면 그 뒤의 모든 일정이 같은 만큼 밀립니다. 접근권이 생기면 테이블별로 다음을 기계적으로 뽑습니다.

-- 코드값 실태: 코드 테이블에 없는 값이 실데이터에 얼마나 있는가
SELECT o.status_cd, COUNT(*) AS cnt
  FROM orders o
  LEFT JOIN code_status c ON c.code = TRIM(o.status_cd)
 WHERE c.code IS NULL
 GROUP BY o.status_cd
 ORDER BY cnt DESC;

-- 유일성 가정 검증
SELECT biz_no, COUNT(*) AS cnt
  FROM customer
 GROUP BY biz_no
HAVING COUNT(*) > 1;

-- 고아 레코드
SELECT COUNT(*)
  FROM order_item i
 WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.id = i.order_id);

여기에 컬럼별 NULL 비율, 고유값 개수, 길이 분포, 최소·최대값, 연도별 건수 추이를 더하면 프로파일링 1차 산출물이 됩니다. 연도별 추이는 특히 유용합니다. 어느 해를 기점으로 값의 분포가 갑자기 바뀐다면 그 시점에 업무 규칙이나 화면이 바뀌었다는 뜻이고, 그 전후는 서로 다른 변환 규칙이 필요할 가능성이 큽니다.

중요한 건 숫자 자체가 아니라 그 숫자로 만드는 다음 문서입니다. 예외 대장을 만드십시오. 한 행에 하나의 예외, 그리고 네 개의 열을 둡니다. 예외의 내용, 해당 건수, 결정된 처리 방식(그대로 이관 / 변환 / 기본값 부여 / 보류 테이블로 격리 / 제외), 그리고 그 결정을 내린 사람과 날짜입니다. 이 대장이 이관 명세서의 본체입니다. 그리고 결정이 채워지지 않은 행의 개수가 곧 남은 위험의 크기이므로, 프로젝트 관리 지표로 그대로 쓸 수 있습니다.

예외 대장을 쓰다 보면 건수가 판단을 크게 바꾼다는 것을 알게 됩니다. 같은 종류의 예외라도 수 건이면 업무 담당자가 눈으로 보고 개별 보정하면 되고, 전체의 상당 비율을 차지하면 신규 모델 쪽을 고쳐야 합니다. 그래서 예외를 보고할 때는 반드시 건수와 비율을 함께 적으십시오. 건수 없는 예외 보고는 결정을 유도하지 못합니다.

검증은 세 층으로 쌓습니다

이관 검증을 "건수가 맞는지 확인한다"로 끝내면 반드시 사고가 납니다. 건수는 가장 약한 검증입니다. 세 층을 모두 세워야 합니다. 이 글에서 조정 리포트라고 부르는 것은, 원천과 대상을 각각 읽어 이 세 층의 차이를 자동으로 뽑아내는 대사(對査) 프로그램을 말합니다.

모든 비교에는 기준 시점이 필요합니다

세 층에 들어가기 전에 먼저 정해야 할 것이 있습니다. 어느 시점의 원천과 비교하는가입니다. 운영 중인 원천은 비교하는 동안에도 계속 변합니다. 기준 시점을 고정하지 않으면 매번 다른 차이가 나오고, 팀은 그 차이가 이관 결함인지 그동안 들어온 신규 거래인지 구분하지 못한 채 시간을 씁니다. 스냅샷이든 특정 시각 이전으로 자른 조건이든, 조정 리포트의 첫 줄에는 기준 시점이 찍혀 있어야 합니다.

건수

핵심은 등식을 성립시키는 것입니다. 옮기지 않은 건이 있다면 그 사유별 건수가 반드시 남아야 합니다. "몇 건이 넘어오지 않았다"는 보고는 쓸모가 없고, "테스트 계정 건 얼마, 고아 레코드 얼마, 필수값 누락으로 보류 얼마"라야 판단이 가능합니다. 제외 건은 삭제하지 말고 사유 코드와 함께 별도 테이블에 남기십시오. 오픈 이후 "그 건은 어떻게 됐느냐"는 질문은 반드시 들어오고, 그때 답할 수 있어야 합니다.

집계

전체 합계만 비교하면 오차가 서로 상쇄되어 통과할 수 있습니다. 반드시 그룹별로 비교하십시오. 연도별, 상태별, 조직별, 상품 구분별처럼 업무가 실제로 들여다보는 축으로 쪼갭니다. 양쪽에서 같은 축으로 집계한 뒤, 차이가 있는 행만 남겨 리포트합니다.

-- 원천과 대상에서 각각 같은 축으로 집계한 뒤 차이만 남긴다
SELECT COALESCE(s.yr, t.yr)         AS yr,
       COALESCE(s.status, t.status) AS status,
       s.cnt, t.cnt, s.amt, t.amt
  FROM src_agg s
  FULL OUTER JOIN tgt_agg t
    ON s.yr = t.yr AND s.status = t.status
 WHERE s.cnt IS DISTINCT FROM t.cnt
    OR s.amt IS DISTINCT FROM t.amt;

문자열 컬럼은 개별 비교가 어려우니 정규화한 뒤 해시를 집계해 비교하는 방법을 씁니다. 다만 이 방법에는 함정이 많으니, 비교 전에 다음을 규약으로 못 박아야 합니다.

• NULL과 빈 문자열의 취급 — DBMS에 따라 빈 문자열을 NULL과 같게 다루는 곳이 있습니다. 어느 쪽이든 한 가지 표현으로 통일한 뒤 해시하십시오.
• 공백과 대소문자 — 고정 길이 문자 타입은 뒤쪽이 공백으로 채워지고, 뒤 공백을 비교에서 무시할지는 DB와 콜레이션 설정에 따라 다릅니다. 비교 전에 명시적으로 잘라내는 편이 안전합니다.
• 숫자와 날짜의 문자열 표현 — 같은 값이라도 소수점 뒤 0의 개수나 날짜 포맷이 다르면 해시가 달라집니다. 자릿수와 포맷을 지정해 문자열로 만든 뒤 해시하십시오.
• 해시 함수와 인코딩 — 원천과 대상이 다른 DBMS라면 같은 이름의 함수가 같은 결과를 준다고 가정하지 마십시오. 확실하지 않으면 양쪽에서 정규화한 문자열만 추출해 한쪽 엔진에서 해시하는 편이 낫습니다.

샘플

무작위 샘플만으로는 부족합니다. 위험 샘플을 따로 뽑으십시오. 금액 최대·최소 건, 가장 오래된 건과 가장 최근 건, 예외 규칙에 걸려 변환된 건, 다국어·특수문자가 포함된 건, 관계가 가장 복잡한 건입니다. 그리고 최종 관문은 DB 비교가 아니라 구 시스템 화면과 신 시스템 화면을 나란히 놓고 같은 값이 보이는지 확인하는 것입니다. 사용자가 문제 삼는 것은 테이블이 아니라 화면이기 때문입니다.

화면 대사에는 개발자가 아니라 그 업무를 매일 하는 사람을 앉히십시오. 개발자는 값이 같은지를 보지만, 실무자는 "이 건이 여기 뜨면 안 된다"는 것을 봅니다. 이관의 가장 위험한 결함은 값이 틀린 것이 아니라 분류가 틀린 것이고, 그건 업무를 아는 사람만 알아봅니다.

검증 코드는 이관 코드와 분리하십시오

같은 사람이 같은 가정으로 이관 스크립트와 검증 스크립트를 함께 짜면, 가정이 틀렸을 때 두 코드가 사이좋게 통과시킵니다. 조정 리포트는 이관 로직을 참조하지 않고 원천과 대상을 독립적으로 읽어 비교하도록 만들고, 가능하면 작성자를 분리하십시오. 그리고 이 리포트는 컷오버 당일 한 번 도는 물건이 아니라, 병행 운영 기간 내내 매일 자동으로 도는 물건이어야 합니다.

리허설: 스크립트가 아니라 시간표를 검증합니다

이관 리허설의 목적을 "스크립트가 오류 없이 도는지 확인"으로 잡으면 절반만 얻습니다. 리허설의 진짜 산출물은 실측된 컷오버 시간표입니다. 최소 세 번은 돌리는 것을 권합니다.

1. 1차 — 완주 자체가 목표입니다. 부분 데이터로 시작해도 됩니다. 여기서는 오류가 쏟아지는 게 정상이고, 예외 대장이 크게 늘어납니다.
2. 2차 — 전량 데이터로 돌리고 단계별 소요 시간을 측정합니다. 여기서 처음으로 "정해진 정지 시간 안에 끝나는가"라는 질문에 답할 수 있습니다.
3. 3차 — 운영과 동일한 사양·동일한 절차로, 런북에 적힌 대로만 수행합니다. 그리고 롤백까지 실제로 해 봅니다. 롤백을 연습하지 않은 롤백 계획은 계획이 아닙니다.

2차 리허설은 반드시 운영과 비슷한 사양에서 재야 의미가 있습니다. 개발 장비에서 잰 시간으로 컷오버 시간표를 짜면 디스크 처리량과 메모리 여유가 달라 그대로 어긋납니다. 사양을 맞출 수 없다면, 최소한 데이터 전량으로 재고 그 수치가 참고값일 뿐임을 계획서에 적어 두십시오.

측정할 항목은 총 소요 시간만이 아닙니다. 단계별 소요 시간, 제약조건과 인덱스 재생성 시간, 통계 갱신 시간, 검증 리포트 수행 시간, 실패 시 재시작 가능한 지점, 그리고 사람이 개입해 판단해야 하는 대기 구간을 모두 적습니다. 인덱스를 끄고 적재한 뒤 다시 만드는 방식이라면, 인덱스 생성 시간이 전체의 상당 부분을 차지하는 일이 흔합니다.

측정 결과가 허용된 정지 시간을 넘으면, 스크립트를 조금 튜닝해서 될 일이 아닙니다. 구조를 바꿔야 합니다. 대부분의 답은 사전 이관 + 증분 이관입니다. 변동이 없는 과거 데이터를 미리 옮겨두고, 컷오버 창에서는 마지막 변경분만 처리하는 방식입니다. 이 방식을 쓰려면 원천에서 변경분을 식별할 수단이 있어야 합니다. 변경 시각 컬럼이 있으면 가장 간단하지만, 그 컬럼이 애플리케이션 코드로만 채워진다면 일괄 수정이나 DBA 작업으로 바뀐 행은 잡히지 않습니다. 물리 삭제가 일어나는 테이블이라면 변경 시각만으로는 삭제를 알 수 없다는 문제도 있습니다. 이런 제약은 늦게 발견할수록 대가가 크므로, 리허설을 앞당겨야 하는 실질적인 이유가 됩니다.

리허설이 끝날 때마다 런북을 갱신하십시오. 런북은 문서가 아니라 대본입니다. 몇 시에, 누가, 어떤 명령을 실행하고, 무엇을 보고 성공으로 판정하며, 실패하면 누구에게 연락해 무엇을 하는지가 한 줄씩 적혀 있어야 합니다. 새벽 3시에 판단력이 남아 있을 것이라고 가정하지 마십시오.

병행 운영 기간 설계

전환 방식은 조직의 취향이 아니라 데이터 규모와 허용 정지 시간, 그리고 되돌림 가능성으로 결정됩니다.

지켜야 할 원칙 하나

쓰기의 기준이 되는 원본은 언제나 한 곳이어야 합니다. 병행 운영에서 사고가 나는 거의 모든 경우는 이 원칙을 어긴 결과입니다. 양쪽에서 수정이 가능한 상태를 며칠만 허용해도, 어느 쪽이 맞는지 판정할 수 없는 행이 쌓이고, 그 조정 작업이 다시 프로젝트를 잡아먹습니다. 병행은 "두 시스템이 대등하게 돌아가는 상태"가 아니라 "한쪽이 원본이고 다른 쪽이 그림자인 상태"로 설계하십시오. 그리고 그림자 쪽은 화면에서 읽기 전용으로 만드는 데 그치지 말고, 계정 권한 수준에서 쓰기를 막으십시오. 배치와 연계 인터페이스는 화면을 거치지 않습니다.

기간은 달력이 아니라 업무 주기로

병행 기간을 "2주"처럼 정하는 것은 의미가 없습니다. 기준은 업무 주기입니다. 월 마감이 있는 시스템이라면 최소한 한 번의 마감을 신·구 양쪽에서 통과시키고 결과가 일치하는 것을 봐야 합니다. 분기 정산이나 연말 결산처럼 주기가 긴 업무가 있다면, 그것까지 병행하겠다는 계획은 대개 비현실적이므로 별도의 검증 계획으로 분리해야 합니다. 과거 데이터를 넣고 지난 기간의 결산을 재현해 구 시스템 결과와 맞춰 보는 방식이 현실적인 대안입니다.

병행은 공짜가 아닙니다

병행 기간에는 운영 인력이 두 배로 들고, 장애 대응 창구가 두 개가 되며, 매일 조정 리포트를 확인하고 차이를 처리하는 새로운 업무가 생깁니다. 그래서 종료 조건을 착수 시점에 문서로 못 박아야 합니다. "N회 마감이 오차 없이 통과하고, 조정 리포트가 연속 M일 무결하면 구 시스템 쓰기를 차단한다"처럼 판정 가능한 문장이어야 합니다. 종료 조건 없는 병행 운영은 사실상 두 시스템을 영구히 유지하기로 결정한 것과 같습니다.

되돌릴 수 있게 만드는 방법

롤백은 문서로 확보되지 않습니다. 되돌릴 수 있도록 설계된 절차만 되돌아갑니다. 최소한 다음은 지켜야 합니다.

• 원천은 읽기 전용으로 취급합니다. 정제와 보정은 스테이징 영역에서만 합니다. 원천을 손대는 순간 비교 기준이 사라집니다.
• 모든 이관 단계는 재실행 가능해야 합니다. 중간에 실패했을 때 처음부터 다시 도는 것 말고 다른 선택지가 없다면, 그 자체가 정지 시간 초과의 원인이 됩니다. 배치 단위를 쪼개고, 어디까지 처리했는지 기록하고, 같은 구간을 다시 돌려도 결과가 같도록 만드십시오.
• 원천 키를 대상에 남기십시오. 신규 테이블에 원천 식별자 컬럼을 하나 두는 것만으로 대사, 재실행, 사후 추적이 전부 가능해집니다. 이걸 "지저분하다"는 이유로 빼면 문제가 생겼을 때 손쓸 방법이 없습니다.
• 복구 시간을 실측하십시오. 백업이 존재하는 것과 정해진 시간 안에 복구되는 것은 전혀 다른 이야기입니다. 컷오버 직전 스냅샷의 복구 소요 시간을 리허설에서 재두지 않으면, 롤백 결정을 내려도 창을 넘깁니다.
• 되돌릴 수 없는 지점을 명시하십시오. 대개 신규 시스템에서 첫 대외 전송, 첫 정산, 첫 고객 통지가 나간 순간입니다. 그 이후는 롤백이 아니라 보정의 영역이고, 대응 방식이 완전히 달라집니다. 이 지점을 런북에 굵게 표시하십시오.
• 신규에서 발생한 데이터를 구 시스템으로 되돌릴 방법이 있는지 확인하십시오. 신규가 쓰기를 받기 시작한 뒤의 롤백은 단순한 백업 복구가 아닙니다. 그 사이에 들어온 거래를 구 시스템에 다시 넣거나 수작업으로 재입력해야 하고, 이 작업의 소요 시간이 롤백 가능 시한을 결정합니다.
• Go/No-Go 판정 시각과 기준을 미리 정하십시오. "새벽 4시 시점에 조정 리포트의 필수 항목이 모두 통과하지 못하면 롤백한다"처럼, 사람의 낙관이 아니라 시계와 수치가 결정하게 만들어야 합니다. 롤백 결정은 늦을수록 비싸지고, 늦어지는 이유는 언제나 "조금만 더 보면 될 것 같아서"입니다.

적재 직후에 자주 빠뜨리는 마무리

데이터가 다 들어갔다고 이관이 끝난 것이 아닙니다. 다음 항목은 런북에 단계로 명시하고, 리허설에서 소요 시간까지 재 두십시오.

• 시퀀스·아이덴티티 현재값 조정 — 원천의 식별자를 그대로 넣었다면 채번 객체의 현재값을 최대값 위로 올려야 합니다. 이걸 빼먹으면 오픈 직후 첫 등록에서 중복 키 오류가 납니다. 이관 결함 중 가장 빨리, 가장 눈에 띄게 터지는 유형입니다.
• 제약조건과 트리거 재활성화 — 성능을 위해 끄고 적재했다면 다시 켜야 합니다. 일부 DBMS에는 제약을 켜되 기존 행은 검증하지 않는 옵션이 있는데, 그걸로 켜 두면 위반 행이 그대로 남습니다. 무엇을 어떤 옵션으로 켰는지 기록하십시오.
• 이관 중 부수 효과 차단 — 이력 적재 트리거, 알림·메일 발송, 대외 연계 배치가 켜진 채로 이관하면 과거 건이 오늘 발생한 것처럼 나갑니다. 반대로 껐다면 다시 켜는 단계가 런북에 있어야 합니다.
• 통계 갱신 — 대량 적재 직후 통계가 낡아 있으면 실행계획이 어긋나 오픈 직후 성능 문제로 나타납니다. 데이터는 정확한데 시스템이 느린 상황은 이관 실패로 인식되며, 원인 파악에 시간이 걸립니다.
• 첨부파일 실물 확인 — 경로 문자열만 옮기고 실제 파일이 따라오지 않은 경우가 흔합니다. 건수뿐 아니라 표본에 대해 실제로 열리는지까지 확인하십시오.

일정 산정: 무엇을 세어야 하는가

테이블 수로 산정하지 마십시오. 세어야 할 것은 세 가지입니다. 변환 규칙의 수, 아직 결정되지 않은 예외의 수, 남은 리허설 회차입니다. 앞의 두 가지는 프로파일링을 해야 알 수 있으므로, 프로파일링 이전의 산정은 추정이 아니라 희망입니다. 계획서에 프로파일링 완료 후 이관 일정 재산정이라는 공식 마일스톤을 넣는 편이 정직하고, 실제로도 안전합니다.

산정에서 반복적으로 누락되는 구간도 적어 둡니다.

• 데이터 접근 권한 취득과 마스킹 사본 생성에 걸리는 행정 시간
• 업무 담당자의 예외 처리 의사결정 대기
• 조정 리포트 자체의 개발과 검증
• 리허설 회차 사이의 수정 작업 — 리허설을 도는 시간보다 그 결과를 반영해 고치는 시간이 훨씬 깁니다
• 첨부파일과 바이너리 — DB와 저장소가 달라 별도 파이프라인이 필요하고, 건수와 용량이 크며, 산정에서 가장 자주 빠집니다
• 연계 시스템이 보관 중인 키의 매핑 — 우리 쪽 식별자가 바뀌면 상대 시스템도 영향을 받고, 그쪽 일정은 우리가 통제할 수 없습니다
• 계정·권한·조직 구조 이관, 그리고 이력·로그성 데이터의 처리 방침
• 구 시스템에서 뽑아 쓰던 리포트·통계의 재현 — 화면은 맞는데 월간 보고서 숫자가 달라지는 문제는 오픈 후에야 드러납니다

실행 체크리스트

1. 실데이터 또는 마스킹 사본 접근권을 첫 주에 확보한다
2. 이관 총괄과 업무 측 결정권자를 이름으로 지정한다
3. 프로파일링을 돌려 예외 대장을 만들고, 예외마다 건수와 비율을 적는다
4. 예외마다 처리 방식과 결정권자를 명시하고, 미결정 건수를 주간 지표로 관리한다
5. 이관 코드와 독립적인 조정 리포트를 만든다 (건수·집계·샘플 3층, 기준 시점 명시)
6. 리허설 1차로 완주하고, 2차로 시간을 재고, 3차로 롤백까지 연습한다
7. 실측 시간이 정지 창을 넘으면 사전 이관 + 증분 구조로 전환한다
8. 병행 방식과 종료 조건을 판정 가능한 문장으로 문서화한다
9. 런북에 Go/No-Go 시각, 판정 기준, 되돌릴 수 없는 지점, 적재 후 마무리 단계를 적는다
10. 컷오버 후에도 조정 리포트를 매일 자동 수행한다

언제는 하지 말아야 하는가

모든 것을 권하는 글은 신뢰할 수 없으므로, 하지 말아야 할 것들을 분명히 적습니다.

전량 이관을 기본값으로 삼지 마십시오

보존 의무는 이관 의무가 아닙니다. 조회 목적으로만 필요한 오래된 데이터를 신규 모델에 억지로 밀어 넣으면, 신규 모델이 과거의 예외를 수용하느라 망가집니다. 읽기 전용 아카이브나 별도 조회 화면으로 분리하는 선택지를 먼저 검토하십시오. 판단 기준은 단순합니다. 그 데이터로 업무 처리가 일어나는가, 아니면 가끔 들여다볼 뿐인가입니다. 후자라면 신규 모델의 제약을 전부 만족시킬 이유가 없습니다. 이관 범위를 줄이는 것은 이관 난이도를 줄이는 가장 강력한 수단이고, 대개 유일하게 남은 수단입니다.

이관 배치 안에서 데이터 정제를 하지 마십시오

"어차피 옮기는 김에 정리하자"는 제안은 합리적으로 들리지만, 이관과 정제를 한 배치에 섞으면 검증이 성립하지 않습니다. 원천과 대상이 달라야 정상인 구간이 생기기 때문입니다. 정제가 필요하면 이관 전에 원천 쪽에서 끝내거나, 이관 후 신규 시스템에서 별도 과제로 수행하십시오. 이관 배치의 목표는 의도한 변환 외에는 아무것도 바꾸지 않는 것입니다.

이중 쓰기를 기본 전략으로 선택하지 마십시오

서로 다른 두 시스템에 동시에 쓰는 것은 본질적으로 분산 트랜잭션 문제입니다. 한쪽만 성공했을 때 어떻게 할지, 재시도가 중복을 만들지 않는지, 순서가 뒤집히면 어떻게 판정할지에 대한 답을 모두 준비해야 합니다. 무중단이 계약상 요구되고 그 복잡도를 감당할 인력이 있는 경우가 아니라면, 짧은 정지 창을 협상하는 편이 거의 항상 저렴합니다. 정지 창을 얻기 위해 협상하는 데 쓰는 시간이, 이중 쓰기를 만들고 그 불일치를 조정하는 시간보다 짧습니다.

데이터를 보지 못한 상태에서 신규 모델을 확정하지 마십시오

설계를 먼저 끝내고 이관을 나중에 맞추는 순서는, 실데이터가 설계 가정을 부수는 순간 전면 재작업으로 돌아옵니다. 유일성, 필수 여부, 관계의 다중성, 코드값의 유한성 같은 핵심 가정은 반드시 실데이터로 확인한 뒤 확정하십시오. 데이터를 볼 수 없는 기간이 길어진다면, 그 기간에는 모델을 확정하는 대신 확정을 미룰 수 있는 구조로 두는 편이 낫습니다.

리허설 없이 컷오버하지 마십시오

예외는 하나뿐입니다. 데이터 규모가 매우 작고, 롤백이 수 분 안에 확실하게 끝나며, 실패해도 업무 영향이 제한적인 경우입니다. 그 외에는 리허설을 생략해서 아낀 시간보다 컷오버 당일에 잃는 시간이 큽니다.

마감·정산 직전에 컷오버하지 마십시오

월말, 분기말, 연말 정산 직전은 문제가 생겼을 때 대응할 여유가 가장 없는 시점입니다. 일정 압박 때문에 그쪽으로 밀리는 경우가 많은데, 그 압박이야말로 날짜를 미뤄야 할 이유입니다. 긴 연휴 직전도 마찬가지입니다. 문제가 드러나는 시점과 사람이 모이는 시점이 어긋납니다.

병행 기간을 "일단 넉넉히" 잡지 마십시오

종료 조건이 없는 병행은 관리 대상이 두 배가 된 상태를 무기한 유지하겠다는 결정입니다. 기간을 늘리는 대신 종료 조건을 명확히 하고, 그 조건을 충족하면 지체 없이 구 시스템의 쓰기를 차단하십시오. 구 시스템을 언제 끄는지 정하지 않은 전환 프로젝트는 끝나지 않습니다.

완벽한 일치를 오픈 조건으로 걸지 마십시오

마지막 항목은 반대 방향의 경고입니다. 수십 년 된 데이터에는 원천 자체가 모순인 행이 남아 있고, 그 행은 어떤 이관 로직으로도 "맞게" 만들 수 없습니다. 차이가 0이 될 때까지 오픈하지 않겠다는 기준은 프로젝트를 무기한 정지시킵니다. 필요한 것은 0이 아니라 설명 가능한 차이입니다. 모든 차이에 사유와 처리 방침이 붙어 있고 결정권자가 그것을 승인했다면, 그 상태가 오픈 가능한 상태입니다. 조정 리포트의 목표를 "차이 없음"이 아니라 "미확인 차이 없음"으로 잡으십시오. 이 구분을 착수 시점에 합의해 두지 않으면, 마지막 2주가 설명 가능한 차이를 놓고 벌이는 소모전으로 끝납니다.

같은 주제의 다른 글

• 모놀리스를 쪼갤 때 현실적인 순서
• 로그와 추적을 나중에 붙이면 늦는 이유

맘소프트는 19년 넘게 금융 · 엔터프라이즈 · 모바일 시스템을 만들어 왔습니다. 여기 적는 글은 그 과정에서 실제로 부딪히고 해결한 것들입니다.

• 기술 블로그 전체 목록
• 이전 글 — 로그와 추적을 나중에 붙이면 늦는 이유
• 다음 글 — Flutter로 게임을 만들 때 부딪히는 성능 문제