새 업무 시스템을 만들 때 가장 무서운 건 기능 개발이 아니에요. 기존에 쌓여 있던 데이터를 옮기는 일이에요. 몇 년 치 엑셀, 사람마다 다른 양식, 비어 있는 칸, 셀 병합, "기타" 컬럼에 몰아넣은 메모까지. 이걸 새 시스템으로 옮기다 한 번 꼬이면 신뢰가 통째로 무너져요.
맞춤형 CRM을 구축한 사례에서도 고객은 수천 건의 인물 데이터를 엑셀로 관리하고 있었어요. 이 글은 그 데이터를 "한 번에 갈아엎지 않고" 옮긴 방법이에요.
빅뱅 마이그레이션의 유혹과 함정
가장 단순한 그림은 "날을 잡아서 한 번에 옮기자"예요. 깔끔해 보이지만 위험해요. 옮기다 중간에 실패하면 어디까지 됐는지 모르고, 양식이 제각각이라 자동 변환이 한 번에 통하지도 않아요. 무엇보다 데이터 정제와 시스템 전환을 동시에 하려다 둘 다 어정쩡해져요.
그래서 전제를 바꿔요. 엑셀을 적으로 보지 않고, 당분간 공존하는 입력 통로로 인정하는 거예요. 옮기는 건 한 번의 이벤트가 아니라 반복 가능한 절차여야 해요.
업로드 → 매핑 → 비동기 실행, 3단계로 쪼개요
핵심은 마이그레이션을 반복 가능한 3단계 파이프라인으로 만드는 거예요.
- 업로드: 엑셀(.xlsx/.xls/.csv)을 그대로 올려요. 양식을 미리 맞추라고 요구하지 않아요.
- 필드 매핑: 업로드한 파일의 열을 시스템 필드에 연결해요. "이 열은 이름, 저 열은 예산" 식으로요. 이 단계가 자동 변환의 실패를 사람이 메우는 지점이에요.
- 비동기 실행: 매핑이 끝나면 백그라운드 작업으로 실제 적재를 돌려요. 수천 건이어도 화면이 멈추지 않아요.
# 업로드 → 매핑 정보와 함께 비동기 잡으로
ImportDataJob.perform_later(import_log.id)
# 잡은 매핑을 따라 한 행씩 적재하고, 결과를 로그에 남겨요
import_log.update!(status: :completed, error_details: errors)실패를 1급 시민으로 다뤄요
마이그레이션에서 진짜 중요한 건 "성공"이 아니라 **"실패를 어떻게 보여주느냐"**예요. 현실의 엑셀에는 깨진 행이 반드시 있어요. 날짜가 텍스트로 들어 있거나, 필수값이 비어 있거나, 중복이거나.
그래서 임포트 상태와 오류를 기록으로 남겨요. 몇 건 들어갔고 몇 건 실패했는지, 실패한 행이 왜 실패했는지를 남기면, 운영자가 그 행만 고쳐서 다시 올릴 수 있어요. 전체를 다시 굴릴 필요가 없죠. 이게 "도망치지 않고 옮기는" 핵심이에요. 한 번에 완벽하게가 아니라, 틀린 부분만 반복해서 옮기는 거예요.
데이터 정제와 전환을 분리해요
빅뱅이 위험한 이유는 정제와 전환을 한 번에 하려 해서예요. 3단계 파이프라인은 이 둘을 자연스럽게 분리해요. 일단 들어갈 수 있는 건 넣고, 실패 로그를 보며 원본을 다듬어 다시 올려요. 시스템은 그동안에도 돌아가요. 자동화를 어디까지 밀어붙일지 정하는 감각은 자동화가 실패하는 이유와도 통해요. 사람이 메워야 할 지점을 인정하는 게 오히려 안전하거든요.
정리
데이터 마이그레이션은 "한 번에 옮기는 이벤트"가 아니라 "반복 가능한 절차"로 설계해야 안전해요. 업로드·매핑·비동기 실행으로 쪼개고 실패를 기록으로 남기면, 깨진 데이터가 있어도 시스템 전환이 멈추지 않아요. 이렇게 옮긴 데이터가 어떤 구조 위에 올라가는지는 고객사마다 다른 스키마 다루기와 맞춤형 CRM 구축 사례에서 이어집니다.
자주 묻는 질문
엑셀 양식을 미리 통일해야 하나요?
아니요. 업로드 후 매핑 단계에서 열을 시스템 필드에 연결하므로, 제각각인 양식도 그대로 올린 뒤 매핑으로 맞출 수 있어요. 양식 통일을 전제하지 않는 게 현실적이에요.
옮기다 실패하면 처음부터 다시 해야 하나요?
아니요. 임포트 로그에 성공·실패 건수와 실패 사유가 남습니다. 실패한 행만 고쳐 다시 올리면 되고, 이미 들어간 데이터를 다시 적재할 필요가 없어요.
수천 건을 올려도 화면이 멈추지 않나요?
적재는 백그라운드 작업으로 처리됩니다. 업로드·매핑만 화면에서 하고 실제 실행은 비동기로 돌아가므로, 대량 데이터도 화면을 잡아두지 않아요.