데이터 마이그레이션 2026 — 견적이 빗나가는 이유와 발주 범위 7단계

시스템을 새로 만들 때 견적이 가장 크게 빗나가는 항목이 데이터 마이그레이션이다. 개발 범위는 화면 수로 셀 수 있지만, 옛 데이터를 옮기는 일은 열어 보기 전까지 규모를 모른다.

이 글은 마이그레이션 기술을 설명하지 않는다. 그건 AWS·IBM 문서에 있다. 여기서 다루는 것은 발주하는 쪽이 판단해야 하는 것들이다. 비용이 어디서 나오는지, 발주서에 무엇을 적어야 범위가 닫히는지, 병행 운영을 며칠로 잡아야 하는지, 「옮겨졌다」를 무엇으로 판정하는지.

왜 견적이 빗나가는가 — 데이터 정리가 절반이다

마이그레이션 작업을 쪼개면 이렇게 된다.

실행은 짧고 정제가 길다. 발주처는 "데이터 옮기는 건 하루면 되지 않나"로 생각하는데, 실제로는 옮기기 전에 데이터를 사람이 읽을 수 있는 상태로 만드는 일이 일정의 절반을 먹는다.

그리고 정제는 개발사가 혼자 못 한다. 「이 두 거래처가 같은 곳인가」, 「이 상태값은 무슨 뜻인가」는 업무를 아는 사람만 답할 수 있다. 이 인력 투입을 발주처가 계획에 안 넣으면 일정이 밀린다.

실제로 나오는 질문은 이런 형태다. 「거래처명이 (주)한국상사와 한국상사(주)로 따로 들어가 있는데 같은 곳인가」, 「상태 코드 7이 뭘 뜻하는지 아는 사람이 있나」, 「이 필드가 비어 있는 건 값이 없는 건가 입력을 안 한 건가」. 코드 어디에도 답이 없고 담당자 머릿속에만 있다.

그래서 정제 기간에는 발주처 담당자가 붙어야 한다. 주당 몇 시간이 필요한지는 데이터 상태에 달렸지만, 0시간으로 잡으면 그 기간만큼 일정이 그대로 밀린다. 담당자가 퇴사했거나 없는 경우라면 그 사실 자체를 조사 단계에서 확인해야 한다 — 아무도 모르는 데이터는 옮기지 않는 편이 낫다.

열어 보기 전에는 견적이 안 나온다

그래서 실무에서는 현황 조사를 별도 단계로 떼는 방식을 쓴다.

마지막 줄이 중요하다. 상태를 모르는 데이터를 고정가로 묶으면 개발사는 최악을 가정해 가격을 올리거나, 낮게 써서 따낸 뒤 범위 다툼을 한다. 양쪽 다 발주처에 손해다.

현황 조사에서 세어야 할 것

조사 단계에서 이 숫자들이 나오면 견적이 성립한다.

두 번째가 비용을 가장 크게 줄인다. 10년 치 데이터가 있어도 실제로 조회되는 것은 최근 2~3년인 경우가 많다. 전부 옮기지 않고 오래된 것은 조회 전용으로 분리하면 정제 대상이 크게 준다.

조회 빈도를 재는 방법은 간단하다. 접속 로그가 있으면 최근 1년간 조회된 레코드의 날짜 분포를 뽑는다. 로그가 없으면 담당자에게 「작년에 몇 년 전 자료까지 찾아봤나」를 묻는다. 대개 2년을 넘기지 않는다.

일곱 번째도 자주 새어 나간다. 첨부파일은 DB 건수에 안 잡히는데 용량이 크고, 파일 경로가 DB에 문자열로 들어가 있어 옮기면서 경로가 깨지는 일이 흔하다. 파일 개수와 총용량을 조사 단계에서 따로 세어야 이관 방식과 소요 시간이 나온다.

데이터 구조를 문서로 남기는 방법은 테이블 정의서·ERD 작성법에 정리했다.

옮기지 않는 것을 먼저 정한다

범위를 닫는 가장 빠른 방법이다. 포함 목록보다 제외 목록이 분쟁을 더 많이 막는다.

두 번째는 법적 이유도 있다. 보유 기간이 지난 개인정보를 새 시스템으로 옮기면 파기 의무를 어긴 상태가 이어진다. 마이그레이션은 데이터를 정리할 기회이기도 하다. 판단 기준은 개인정보 영향평가 발주 가이드에서 다뤘다.

병행 운영 기간을 며칠로 잡을 것인가

옛 시스템과 새 시스템을 동시에 돌리는 기간이다. 이걸 0으로 잡으면 사고가 난다.

병행 기간에 정해야 할 것은 이렇다.

• 어느 쪽이 정본인가 — 값이 다르면 무엇을 믿는지
• 양방향인가 단방향인가 — 새 시스템 입력이 옛 시스템에도 들어가야 하는지
• 종료 조건 — 무엇이 확인되면 옛 시스템을 끄는지

세 번째가 없으면 병행이 끝나지 않는다. 「문제없으면 끈다」는 조건이 아니다. 「N일간 불일치 0건」처럼 숫자로 적어야 종료 판정이 된다.

첫 번째도 미리 못 박아야 한다. 병행 중에는 같은 건이 두 시스템에서 다르게 보이는 상황이 반드시 생기고, 그때마다 「어느 게 맞나」를 협의하면 업무가 멈춘다. 전환 시점부터는 새 시스템을 정본으로 두고 옛 시스템은 조회용으로 쓰는 쪽이 단순하다. 옛 시스템에 계속 입력이 들어가야 하는 사정이 있다면, 그 입력 경로를 먼저 없애는 것이 전환의 일부다.

「옮겨졌다」를 무엇으로 판정하는가

검증 기준을 이관 전에 정해 두지 않으면 인수 단계에서 다툰다.

두 번째가 가장 값싸고 강력하다. 건수만 맞추면 값이 틀려도 통과하는데, 금액 총합까지 맞으면 대부분의 사고가 걸린다.

여섯 번째도 빠뜨리기 쉽다. DB에는 들어갔는데 화면에서 깨지는 경우가 있다. 긴 텍스트가 잘리거나, 옛 시스템의 특수문자가 새 시스템에서 안 보이는 식이다. 검증은 DB가 아니라 화면에서 끝나야 한다.

검수 기준을 문서로 닫는 방법은 테스트 케이스 작성법에 있다.

발주서에 적을 것

세 번째가 실무에서 가장 자주 깨진다. 「데이터 정제는 발주처가 한다」고만 적으면 누가 언제 얼마나 하는지가 빠진다. 주당 몇 시간, 누구 담당인지까지 적어야 일정이 성립한다.

범위를 문서로 닫는 방법 전반은 과업지시서 작성법에서 다룬다.

되돌릴 수 있게 만든다

이관은 한 번에 성공하지 않는다. 실패를 전제로 설계한다.

두 번째가 핵심이다. 이관 스크립트는 여러 번 돌리게 된다. 리허설, 실패 후 재시도, 최종 이관까지 최소 세 번이다. 두 번 돌렸을 때 데이터가 두 배가 되는 스크립트는 쓸 수 없다.

방법은 단순하다. 원본의 식별자를 새 시스템에도 남겨 두고, 이미 있으면 건너뛰거나 덮어쓴다. 이걸 안 해 두면 재실행할 때마다 기존 데이터를 지우고 처음부터 넣어야 하는데, 운영이 시작된 뒤에는 그럴 수 없다.

네 번째도 계약에 넣을 만하다. 무엇을 언제 몇 건 옮겼는지 기록이 남아야 「이 건은 이관된 건가 원래 없던 건가」를 나중에 판정할 수 있다. 인도 몇 달 뒤에 나오는 질문이다.

이관 7단계

5번을 건너뛰는 경우가 많은데, 리허설 없이 본 이관을 하면 소요 시간조차 모른다. 전환 작업을 주말에 잡았는데 실제로는 이틀이 걸리는 상황이 여기서 나온다.

리허설은 운영 데이터 전량으로 해야 의미가 있다. 표본 1,000건으로 돌려 보고 「잘 된다」고 판단하면 실제 100만 건에서 메모리가 터지거나 시간이 수십 배로 늘어난다. 전량이 어려우면 최소한 가장 큰 테이블 하나는 전량으로 돌려 소요 시간을 재 둔다.

흔한 실수 다섯 가지

트리숲이 마이그레이션을 다루는 방식

트리숲은 마이그레이션이 포함된 사업에서 현황 조사를 먼저 하자고 제안한다. 데이터를 열어 보지 않고 낸 견적은 양쪽 모두에게 위험하다. 조사 결과로 건수·결측률·중복을 확인한 뒤 범위와 금액을 정하면 착수 후 협의가 크게 준다.

제외 항목은 발주처와 같이 만든다. 「3년 이상 지난 것」, 「탈퇴 회원」처럼 빼도 되는 것을 먼저 덜어내면 정제 대상이 줄고, 그만큼 일정과 비용이 준다. 이 작업은 데이터를 아는 발주처가 있어야 가능하다.

검증 기준은 건수와 합계를 기본으로 하고, 화면 표시까지 포함한다. DB에 들어간 것과 사용자가 보는 것이 다를 수 있기 때문이다. 견적 산정 근거를 맞추는 방법은 기능점수(FP) 기반 비용 산정에 정리해 두었다.

자주 묻는 질문

데이터 마이그레이션 비용은 어떻게 산정하나요?

건수만으로는 안 나온다. 결측률·중복·형식 불일치가 정제 공수를 결정하므로 현황 조사가 먼저다. 조사 없이 받은 고정가는 개발사가 위험을 얹은 가격이거나, 나중에 범위 다툼이 된다.

옛 데이터를 전부 옮겨야 하나요?

아니다. 조회 빈도가 낮은 오래된 데이터는 별도 보관으로 분리하는 편이 낫다. 보유 기간이 지난 개인정보는 옮기면 안 되고 파기 대상이다.

병행 운영은 얼마나 해야 하나요?

기간보다 종료 조건이 중요하다. 「N일간 불일치 0건」처럼 숫자로 정해야 끝낼 수 있다. 「문제없으면 끈다」는 조건이 아니다.

월 마감이나 정산이 걸린 시스템은 언제 전환하나요?

마감 주기가 한 번 온전히 돌아간 뒤로 잡는다. 월 마감이 있으면 최소 한 달은 병행해야 마감 로직이 새 시스템에서도 맞는지 확인된다. 마감 직전 전환은 피한다.

정제는 개발사가 해주나요?

형식 변환은 개발사가 하지만, 「이 두 건이 같은 거래처인가」 같은 판단은 업무를 아는 쪽만 할 수 있다. 발주처 인력 투입 시간을 계약에 적어야 일정이 성립한다.

이관이 잘못되면 되돌릴 수 있나요?

설계에 넣어 두면 가능하다. 원본을 보존하고, 같은 스크립트를 여러 번 돌려도 결과가 같게 만들고, 테이블 단위로 재이관할 수 있게 해 두면 된다. 이걸 요구사항에 넣지 않으면 개발사가 만들 이유가 없다.

정리

데이터 마이그레이션에서 발주처가 실제로 결정해야 하는 것은 기술이 아니라 범위와 판정 기준이다. 무엇을 옮기지 않을지, 정제를 누가 할지, 「옮겨졌다」를 무엇으로 확인할지, 병행 운영을 언제 끝낼지.

발주 전에 세 가지를 정해 두면 견적이 흔들리지 않는다. 현황 조사를 별도 단계로 뗄 것, 제외 항목을 목록으로 만들 것, 그리고 검증 기준을 건수·합계·화면 표시로 적을 것이다. 이 셋이 없으면 이관 당일에 무엇이 끝난 것인지 아무도 말하지 못한다.

레거시 시스템 자체를 새로 만들지 고칠지의 판단은 레거시 시스템 전환 가이드에서 다룬다.