문서 5,135건 옮겼는데 시간을 먹은 건 마지막 6%였다

검수 시 확인 항목

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

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

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

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

착수 전 준비물

데이터 마이그레이션 외주가 처음인 사람을 위해 실제 흐름을 적어둔다.

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

아래에 이런 걸 적었다
· 레거시 시스템 이관은 이런 순서로 간다
· 90%는 정말 빨리 끝난다
· 남는 것들은 전부 사연이 있다
· 이미지 하나 때문에 며칠
· 레거시 시스템 이관 견적에서 확인할 것
필요한 데로 내려가면 됨

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

90%는 정말 빨리 끝난다

개발 기간 산정

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

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

문제는 그다음이다.

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

관리자 권한 복잡도

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

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

이걸 하나씩 봐야 한다. 일괄 처리가 안 된다. 되는 거였으면 애초에 실패 안 했다.

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

이미지 하나 때문에 며칠

검수 테스트 체크리스트

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

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

찾고 나면 고치는 건 5분이다. 찾는 데 며칠이 걸린다.

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

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

인수인계 체크리스트

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

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

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

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

레거시 시스템 이관 비용

이건 솔직하게 말한다.

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

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

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

견적은 두 덩어리로 나누는 게 낫다

내가 지금 견적을 낼 때 쓰는 방식이다.

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

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

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

같이 보면 좋은 글

• 개발 외주 계약서에 꼭 있어야 할 여섯 가지
• 소프트웨어 외주 개발 비용과 실무 — 받는 쪽에서 본 전부
• 크몽 외주로 별점 5점 리뷰 받고 접었습니다