문서 5,135건을 옮겼습니다, 시간을 먹은 건 마지막 6%였어요

제조업 고객사의 옛 사내 시스템을 웹에서 다시 볼 수 있게 옮기는 작업을 했습니다.

문서 5,135건, 첨부파일 6만 3천 개. 최종적으로 294건이 실패했어요. 성공률 94%입니다.

그런데 그 남은 6%를 처리하는 데 걸린 시간이 앞의 94%보다 길었습니다. 데이터 마이그레이션 외주에서 견적이 틀어지는 게 대개 여기예요.

레거시 시스템 이관은 이런 순서로 갑니다

데이터 마이그레이션 외주가 처음이신 분들을 위해 실제 흐름을 적어둘게요.

• 1. 구조 파악 — 원본 시스템이 데이터를 어떻게 담고 있는지 봅니다. 문서가 어디 있고, 첨부가 어디 붙어 있고, 화면이 어떻게 그려지는지.
• 2. 접근 확보 — VPN, 계정, 방화벽. 여기서 며칠 밀리는 경우가 흔합니다.
• 3. 추출 — 대량으로 긁어옵니다. 진도가 제일 잘 나가는 구간이에요.
• 4. 변환·적재 — 새 구조에 맞게 바꿔 넣습니다.
• 5. 실패 처리 — 안 옮겨진 것들을 하나씩 봅니다. 여기가 제일 오래 걸립니다.
• 6. 검수 — 제대로 옮겨졌는지 확인합니다.

견적은 대개 1~4번 기준으로 나옵니다. 그런데 실제 시간은 5~6번에서 갑니다.

90%는 정말 빨리 끝납니다

마이그레이션은 초반 진도가 잘 나갑니다. 구조를 파악하고, 옮기는 코드를 짜고, 돌리면 대량으로 처리돼요. 며칠 만에 "거의 다 됐다"는 화면을 보게 됩니다.

그래서 견적을 낼 때도 그 감으로 계산하게 돼요. "이 정도면 2주면 되겠는데."

문제는 그다음입니다.

남는 것들은 전부 사연이 있습니다

실패한 294건은 그냥 무작위로 실패한 게 아니었어요. 하나씩 이유가 달랐습니다.

• 원본 파일이 이미 없는 것
• 파일명이 깨져서 못 찾는 것
• 옛날 방식으로 인코딩돼서 경로가 안 맞는 것
• 권한이 걸려 있어서 접근이 안 되는 것

이걸 하나씩 봐야 합니다. 일괄 처리가 안 돼요. 되는 거였으면 애초에 실패 안 했을 테니까요.

그리고 이런 게 발견되는 시점이 늘 늦습니다. 90%가 끝난 뒤에야 "안 된 게 몇 건 있네"로 나타나거든요.

이미지 하나 때문에 며칠

기억에 남는 버그가 하나 있습니다.

문서 안에 들어 있는 이미지를 같이 받아와야 했는데, 일부가 계속 안 나왔어요. 원인은 경로에 들어간 특수문자 처리 하나였습니다. 그 한 줄 때문에 수천 개 문서의 이미지가 깨져 있었어요.

찾고 나면 고치는 건 5분입니다. 찾는 데 며칠이 걸리죠.

결국 못 받은 것들은 "이미지 없음" 표시로 대체했습니다. 전부 살릴 수는 없었어요.

레거시 시스템 이관 견적에서 확인할 것

데이터 마이그레이션 외주 견적을 받으시면 이걸 물어보세요.

• 성공률 기준이 몇 퍼센트인지. "전부 옮긴다"는 말은 대개 안 지켜집니다. 94%인지 99%인지에 따라 비용이 완전히 달라져요.
• 실패한 건을 어떻게 처리하는지. 목록으로 주는지, 하나씩 손으로 살리는지, 대체 표시를 하는지.
• 원본 시스템에 접근이 되는지. VPN이나 계정 발급이 늦어지면 그 기간이 그대로 일정이 됩니다. 저는 이것 때문에 며칠 기다린 적이 있어요.
• 검수를 누가 하는지. 옮긴 게 맞는지 확인하려면 원래 내용을 아는 사람이 봐야 합니다. 외주 업체는 그걸 모릅니다.

마지막 항목이 제일 자주 빠집니다. 개발자는 "옮겨졌다"까지만 알 수 있어요. "제대로 옮겨졌다"는 그 문서를 아는 사람만 압니다.

데이터 이관에 100%를 요구하지 마세요

이건 솔직하게 말씀드릴게요.

오래된 시스템일수록 원본 자체가 이미 망가져 있는 경우가 많습니다. 삭제된 파일, 깨진 링크, 서로 안 맞는 데이터. 그걸 옮기는 쪽에서 복원할 수는 없어요.

100%를 계약서에 넣으면 두 가지 중 하나가 됩니다. 견적이 크게 올라가거나, 나중에 분쟁이 나거나요.

차라리 "94% 이상, 실패 건은 목록 제공"처럼 숫자로 적는 게 낫습니다. 서로 기대가 맞고, 실패 목록을 받으면 발주사가 판단할 수 있어요. 어떤 건 살릴 가치가 있고 어떤 건 그냥 버려도 되니까요.

견적을 두 덩어리로 나누세요

제가 지금 견적을 낼 때 쓰는 방식입니다.

옮기는 값과 마무리하는 값을 따로 세웁니다. 앞엣것은 예측이 되고, 뒤엣것은 실제로 열어봐야 압니다.

그래서 뒤엣것은 "실패 건수에 따라"로 조건을 걸어두는 게 서로 편해요. 처음부터 넉넉하게 불러서 발주사가 비싸다고 느끼는 것보다, 조건을 적어두고 실제 나온 만큼 정산하는 쪽이 낫습니다.

예전엔 이런 걸 다 개발비에 숨겨놨었어요. 그러면 결국 양쪽 다 손해더라고요.