프로그램 개발 전 기존 데이터 이전 범위 정하는 법

# 프로그램 개발 전 기존 데이터 이전 범위 정하는 법

시스템 교체를 앞둔 실무자를 위한 데이터 마이그레이션 범위 설정 완벽 가이드

---

새 프로그램 개발을 앞두고 있다면 가장 먼저 부딪히는 질문이 하나 있습니다. "기존 데이터, 다 옮겨야 할까요? 아니면 일부만 옮겨야 할까요?" 이 질문에 명확한 답을 내리지 못한 채 개발을 시작하면, 프로젝트 중반에 범위가 계속 늘어나는 이른바 '스코프 크립(Scope Creep)' 현상을 겪게 됩니다. 실제로 시스템 교체 프로젝트가 지연되는 가장 흔한 원인 중 하나가 바로 데이터 이전 범위를 사전에 확정하지 못한 것입니다.

데이터 마이그레이션은 단순히 파일을 복사해서 붙여넣는 작업이 아닙니다. 삼성SDS 자료에 따르면 데이터 마이그레이션은 기존 시스템의 데이터를 새 시스템으로 안전하고 효율적으로 옮기는 과정이며, 단순 이동이 아니라 정제·표준화·활용성 향상을 목표로 원천 시스템의 데이터를 추출(Extract)·변환(Transform)·로딩(Load)하는 ETL 작업입니다. 이 과정을 제대로 계획하지 않고 개발부터 시작하면, 나중에 "이 데이터는 왜 안 넘어왔지?", "이 필드는 새 시스템에 없는데?"라는 질문이 프로젝트 막바지에 쏟아지게 됩니다.

이 글에서는 클라우드플레어와 퓨어스토리지 등에서 공개한 마이그레이션 방법론을 바탕으로, 개발 착수 전 데이터 이전 범위를 어떻게 정해야 하는지 단계별로 정리해드립니다. 이 글을 끝까지 읽고 나면 프로젝트 킥오프 회의에서 바로 활용할 수 있는 실무 체크리스트를 손에 넣을 수 있을 겁니다.

준비물·전제조건: 범위를 정하기 전에 갖춰야 할 것들

데이터 이전 범위를 정하려면 현재 시스템에 대한 정확한 이해가 선행되어야 합니다. 클라우드플레어 자료에서 설명하는 것처럼, 마이그레이션 전 사전 단계에서는 프로젝트 목표, 범위, 필요한 인력·리소스, 중요 요구 사항을 먼저 수립해야 하는데, 이를 위해서는 몇 가지 준비물이 필요합니다.

먼저 기존 시스템의 데이터베이스 구조를 확인할 수 있는 권한이 있어야 합니다. 테이블 목록, 스키마 정의서, ERD(개체관계도)가 있다면 이상적이지만, 오래된 시스템이라면 이런 문서가 아예 없는 경우도 흔합니다. 이럴 때는 DB 관리 도구를 이용해 직접 스키마를 추출하는 작업부터 시작해야 합니다.

다음으로 업무 담당자와의 인터뷰 채널이 필요합니다. 개발자나 IT 담당자만으로는 "이 필드가 실제로 쓰이는지", "이 테이블이 지금도 참조되는지"를 파악하기 어렵습니다. 실무자의 경험이 데이터 이전 범위를 정하는 데 결정적인 힌트가 됩니다.

그리고 데이터 볼륨을 측정할 수 있는 환경도 준비해야 합니다. 테이블별 로우 수, 전체 DB 용량, 파일 첨부 자료의 용량 등을 미리 파악해두면 이후 이전 작업의 소요 시간과 리소스를 가늠하는 데 큰 도움이 됩니다.

마지막으로 규정 준수 요구 사항 확인입니다. 업종에 따라 개인정보, 결제 정보, 의료 정보 등은 보관 기한이나 이전 방식에 제약이 있을 수 있으므로, 법무·보안 담당자와 사전에 논의해두는 것이 안전합니다.

Step 1. 원천 데이터 프로파일링으로 현황부터 파악하기

데이터 이전 범위를 정하는 첫걸음은 원천 데이터를 있는 그대로 파악하는 프로파일링 작업입니다. 클라우드플레어 자료에 따르면 마이그레이션 전 작업에는 데이터 원본, 대상 및 형식을 평가하는 프로파일링이 포함될 수 있다고 설명하는데, 이는 실무에서도 가장 먼저 손대야 할 작업입니다.

프로파일링은 쉽게 말해 "우리 데이터가 지금 어떤 상태인지 진단하는 것"입니다. 퓨어스토리지 자료에서는 이를 '가로(원천 데이터) 분석' 단계로 설명하며, 데이터의 구조, 의미, 콘텐츠, 컨텍스트를 파악하는 과정이라고 소개합니다. 이 단계에서 해야 할 작업은 다음과 같습니다.

첫째, 테이블별 세부 데이터 사전을 작성합니다. 각 테이블에 어떤 컬럼이 있고, 각 컬럼이 실제로 어떤 값을 담고 있는지 정리하는 작업입니다. 컬럼명만 봐서는 알 수 없는 경우가 많기 때문에 실제 데이터 샘플을 함께 확인해야 합니다.

둘째, 높은 수준의 소스-타겟 매핑 사양을 초안 형태로 작성합니다. 이 시점에서는 아직 세밀한 매핑까지 갈 필요는 없고, "이 테이블은 새 시스템의 어느 영역에 대응하는가" 정도의 큰 그림만 그려도 충분합니다.

셋째, 볼륨을 산정합니다. 각 테이블의 로우 수, 전체 데이터 용량, 첨부파일 용량 등을 측정해서 프로젝트 추정치를 구체화하는 근거로 삼습니다. 볼륨이 크다면 이전 방식(배치 처리, 실시간 동기화 등)에 대한 결정도 함께 검토해야 합니다.

넷째, 높은 수준의 범위 지정 보고서를 작성합니다. 지금까지 파악한 내용을 바탕으로 "무엇을 옮기고, 무엇을 옮기지 않을지"에 대한 초안을 문서로 남깁니다.

여기서 반드시 주의해야 할 점이 있습니다. 퓨어스토리지 자료는 "데이터 품질은 마이그레이션 계획에서 가장 간과되는 요소"라는 취지의 지적을 하고 있습니다. 프로파일링 단계에서 데이터 품질 문제(중복, 결측값, 형식 불일치 등)를 미리 발견하지 못하면, 개발이 다 끝난 뒤에야 "이 데이터는 옮길 수가 없다"는 사실을 알게 되는 최악의 상황을 맞을 수 있습니다. 따라서 프로파일링은 단순 현황 파악이 아니라 품질 진단까지 포함하는 작업으로 접근하는 것이 바람직합니다.

Step 2. 이전 대상과 제외 대상을 명확히 분류하기

프로파일링이 끝났다면 이제는 실제로 "무엇을 옮기고 무엇을 버릴지"를 결정할 차례입니다. 이 단계를 건너뛰고 "일단 다 옮기자"는 식으로 접근하면, 오래되고 쓸모없는 데이터까지 새 시스템에 그대로 이식되어 정작 중요한 데이터가 파묻히는 결과를 낳습니다.

분류 작업은 보통 세 가지 카테고리로 나누어 진행하면 효율적입니다.

① 필수 이전 데이터: 새 시스템 운영에 반드시 필요한 데이터입니다. 회원 정보, 거래 이력, 현재 진행 중인 업무 데이터 등이 여기 해당합니다.

② 선택적 이전 데이터: 있으면 좋지만 없어도 당장 운영에 지장이 없는 데이터입니다. 예를 들어 3년 이상 지난 로그 데이터나, 사용 빈도가 낮은 참고용 테이블이 여기 속합니다.

③ 이전 제외 데이터: 새 시스템과 구조적으로 맞지 않거나, 더 이상 의미가 없는 데이터입니다. 예를 들어 이미 폐기된 서비스와 관련된 테이블, 테스트 목적으로 생성됐던 더미 데이터 등이 이에 해당합니다.

이 분류 작업을 할 때 고려해야 할 요소는 업계에서 통상적으로 언급되는 몇 가지 기준을 참고하면 도움이 됩니다. 비용, 이전 시기, 기술적 요구 사항, 비즈니스 운영에 미치는 영향, 데이터 손실 가능성, 규정 준수 요구 사항 등을 종합적으로 검토하는 것이 일반적인 접근 방식입니다. 예를 들어 데이터 볼륨이 지나치게 크면 이전 비용과 시간이 늘어나므로, 정말 필요한 데이터인지 다시 한번 따져봐야 합니다. 반대로 규정상 일정 기간 보관이 의무인 데이터라면, 사용 빈도가 낮더라도 임의로 제외할 수 없습니다.

또한 조직이 데이터 마이그레이션 여부와 범위를 결정할 때는 데이터의 무결성, 마이그레이션에 드는 비용, 비즈니스와 고객에게 미치는 영향을 함께 고려하는 것이 바람직합니다. 특히 다운타임이 발생하면 실제 서비스를 이용하는 고객에게까지 영향이 갈 수 있으므로, 이전 작업의 타이밍(야간, 주말, 서비스 저사용 시간대 등)도 범위 설정 단계에서 함께 논의해두는 것이 좋습니다.

이 분류 작업의 결과물은 반드시 문서로 남겨서 이해관계자 전원이 합의한 형태로 확정해두어야 합니다. 구두로만 합의하고 넘어가면 개발 중간에 "이건 옮기기로 했던 거 아니었나요?"라는 혼선이 생기기 쉽습니다.

Step 3. 소스-타겟 데이터 매핑 문서 작성하기

범위가 확정됐다면 이제 원천 데이터의 각 필드가 새 시스템의 어느 필드로 대응되는지 상세하게 매핑하는 작업이 핵심입니다. 이 문서가 바로 개발팀이 실제 개발에 착수할 때 참고하게 되는 가장 중요한 산출물입니다.

데이터 매핑 문서에는 최소한 다음 항목이 포함되어야 합니다.

먼저, 원천 테이블명과 컬럼명을 그대로 기재합니다. 개발자가 기존 시스템을 몰라도 이 문서만 보고 데이터의 출처를 정확히 파악할 수 있어야 합니다.

다음으로, 대상 테이블명과 컬럼명을 기재합니다. 새로 설계되는 시스템의 스키마와 원천 데이터가 어떻게 연결되는지 명시하는 부분입니다.

그리고 데이터 타입 변환 규칙을 명시합니다. 예를 들어 기존 시스템에서는 날짜가 문자열(YYYYMMDD)로 저장되어 있었는데, 새 시스템에서는 표준 날짜 타입을 쓴다면 이 변환 규칙을 문서에 남겨야 합니다.

또한 값 변환·정제 규칙도 함께 기재해야 합니다. 예를 들어 기존 시스템에서 성별 값이 '1', '2'로 저장되어 있었다면 새 시스템에서는 'M', 'F'로 바꿔야 할 수 있는데, 이런 변환 로직을 매핑 문서에 명확히 남겨야 나중에 ETL 스크립트를 작성할 때 헷갈리지 않습니다.

마지막으로, 예외 처리 방침을 정의합니다. 매핑이 애매하거나 값이 비어 있는 경우 어떻게 처리할지(기본값 삽입, 이전 제외, 수동 검토 등)를 미리 규칙으로 정해두어야 합니다.

이 매핑 작업을 진행하다 보면 원천 데이터의 품질 문제가 본격적으로 드러나기 시작합니다. 컬럼에 예상과 다른 값이 섞여 있거나, 동일한 의미인데 표기 방식이 제각각인 경우(예: '서울', '서울시', 'Seoul'이 혼재)가 자주 발견됩니다. 이런 문제를 매핑 단계에서 발견하면 바로 다음 단계인 데이터 정제 계획에 반영할 수 있지만, 발견하지 못하고 넘어가면 개발 완료 후 실제 이전 작업 중에 오류가 터져 나오게 됩니다.

매핑 문서는 엑셀이나 스프레드시트로 작성해도 무방하지만, 프로젝트 규모가 크다면 협업 도구를 활용해 개발팀과 실무 담당자가 실시간으로 코멘트를 남기며 수정할 수 있도록 하는 것이 효율적입니다.

Step 4. 데이터 정제 계획과 ETL 절차 설계하기

매핑 문서가 완성되면 실제로 데이터를 어떻게 추출·변환·적재할지 ETL 절차를 구체적으로 설계해야 합니다. 이 단계에서는 앞서 발견한 데이터 품질 문제를 어떻게 해결할지에 대한 정제(Cleansing) 계획이 함께 확정되어야 합니다.

ETL 절차는 이름 그대로 세 단계로 나뉩니다.

추출(Extract) 단계에서는 원천 시스템에서 이전 대상으로 확정된 데이터만 골라 뽑아내는 방식을 설계합니다. 이때 서비스 운영에 영향을 주지 않도록 추출 시점(야간 배치, 스냅샷 방식 등)을 신중하게 정해야 합니다.

변환(Transform) 단계에서는 앞서 작성한 매핑 문서의 규칙에 따라 데이터 타입 변환, 값 정규화, 중복 제거, 결측값 처리 등을 수행합니다. 이 단계가 사실상 데이터 정제의 핵심이며, 여기서 얼마나 꼼꼼하게 처리하느냐에 따라 새 시스템 오픈 초기의 데이터 신뢰도가 결정됩니다.

적재(Load) 단계에서는 변환이 끝난 데이터를 새 시스템의 데이터베이스에 실제로 삽입합니다. 이때 대량 데이터를 한 번에 적재하면 시스템에 부하가 걸릴 수 있으므로, 배치 단위로 나눠서 처리하거나 점진적으로 적재하는 방식을 고려해야 합니다.

이 단계에서 놓치기 쉬운 부분이 테스트 이전(Test Migration)입니다. 실제 운영 데이터를 바로 프로덕션 환경에 적재하기 전에, 반드시 샘플 데이터 또는 복제된 데이터로 ETL 절차를 시험해봐야 합니다. 테스트 이전을 생략하고 바로 실제 이전에 들어가면, 예상치 못한 오류가 발생했을 때 되돌리기가 매우 어려워집니다.

또한 롤백 계획도 이 단계에서 반드시 수립해야 합니다. 이전 도중 심각한 문제가 발견됐을 때 기존 시스템으로 즉시 되돌릴 수 있는 절차와 기준을 미리 정해두지 않으면, 문제 발생 시 현장에서 즉흥적으로 판단해야 하는 위험한 상황에 놓이게 됩니다.

마지막으로 검증(Validation) 절차를 설계해야 합니다. 이전이 끝난 후 원천 데이터의 로우 수와 새 시스템의 로우 수가 일치하는지, 샘플 데이터를 무작위로 뽑아 값이 정확히 옮겨졌는지 확인하는 절차를 미리 정의해두어야 실제 이전 완료 후 신속하게 검증을 마칠 수 있습니다.

자주 발생하는 오류: 범위 설정 단계에서 놓치기 쉬운 함정들

데이터 이전 범위 설정 단계에서 가장 흔하게 발생하는 문제는 "범위를 문서화하지 않고 구두로만 합의하는 것"입니다. 이 문제가 프로젝트 후반부에 가장 많은 재작업을 유발합니다.

대표적으로 다음과 같은 오류가 자주 발생합니다.

오류 1. 숨겨진 데이터 소스를 놓치는 경우
메인 데이터베이스만 확인하고 엑셀 파일이나 별도 서브 시스템에 흩어져 있는 데이터를 빠뜨리는 경우가 많습니다. 실무 담당자가 개인적으로 관리하던 스프레드시트에 중요한 데이터가 있을 수 있으니, 인터뷰 단계에서 반드시 "혹시 별도로 관리하시는 자료가 있나요?"라고 물어봐야 합니다.

오류 2. 데이터 품질 문제를 개발 완료 후에 발견하는 경우
프로파일링을 형식적으로만 하고 넘어가면, ETL 스크립트를 다 짜고 나서야 "이 필드에 이상한 값이 섞여 있다"는 걸 발견하게 됩니다. 이렇게 되면 스크립트 자체를 다시 수정해야 하므로 일정이 크게 지연됩니다.

오류 3. 다운타임 계획 없이 이전을 진행하는 경우
데이터 이전에는 반드시 일정 시간 서비스가 중단되거나 제한되는 구간이 발생할 수 있습니다. 이를 미리 이해관계자에게 공지하지 않으면 이전 당일 예상치 못한 항의나 혼란이 발생할 수 있습니다.

오류 4. 규정 준수 요구 사항을 뒤늦게 확인하는 경우
개인정보 관련 데이터는 마스킹 처리나 별도 동의 절차가 필요할 수 있는데, 이를 개발 단계에서 미처 고려하지 못하고 이전 직전에 발견하는 경우가 있습니다. 법무 검토는 반드시 범위 설정 초기 단계에 병행되어야 합니다.

오류 5. 롤백 시나리오를 준비하지 않는 경우
"잘 될 것"이라는 낙관적 가정만으로 이전을 진행하다가, 문제가 발생했을 때 되돌릴 방법이 없어 급하게 대응하는 경우가 많습니다. 롤백 절차는 반드시 사전에 문서화되어야 합니다.

활용 팁 & 베스트 프랙티스: 범위 설정을 더 안전하게 만드는 노하우

범위 설정 작업의 완성도를 높이려면 "단계별 승인 절차"를 명확히 두는 것이 가장 효과적인 방법입니다. 프로파일링 결과, 분류 결과, 매핑 문서, ETL 계획 각 단계가 끝날 때마다 이해관계자의 서면 승인을 받아두면, 나중에 "이런 얘기는 못 들었다"는 분쟁을 원천 차단할 수 있습니다.

몇 가지 추가로 참고하면 좋은 노하우를 정리해보겠습니다.

팁 1. 데이터를 우선순위별로 나눠서 단계적으로 이전하기
모든 데이터를 한 번에 옮기려 하지 말고, 핵심 업무 데이터를 먼저 이전하고 부가 데이터는 이후 단계에서 옮기는 방식을 고려해볼 수 있습니다. 이렇게 하면 초기 오픈 리스크를 줄이면서도 전체 이전 작업을 관리 가능한 단위로 쪼갤 수 있습니다.

팁 2. 실제 사용자를 매핑 검토에 참여시키기
개발팀과 IT 담당자만 매핑 문서를 검토하면 실제 업무 맥락을 놓치기 쉽습니다. 실무에서 데이터를 직접 다루는 사용자를 매핑 검토 회의에 참여시키면 예상치 못한 오류를 초기에 잡아낼 확률이 훨씬 높아집니다.

팁 3. 데이터 볼륨에 따라 이전 방식을 다르게 설계하기
소규모 데이터라면 한 번에 통째로 이전하는 방식(빅뱅 마이그레이션)도 가능하지만, 볼륨이 크다면 병행 운영 기간을 두고 점진적으로 이전하는 방식이 더 안전할 수 있습니다.

팁 4. 프로파일링 결과를 시각적으로 공유하기
데이터 품질 문제나 볼륨 현황을 텍스트 보고서로만 전달하면 이해관계자가 심각성을 체감하기 어려울 수 있습니다. 그래프나 대시보드 형태로 시각화해서 공유하면 의사결정 속도가 빨라집니다.

팁 5. 범위 확정 후에도 변경 관리 프로세스를 유지하기
범위를 한 번 확정했다고 끝이 아닙니다. 개발이 진행되면서 새로운 요구 사항이 발견될 수 있으므로, 변경이 필요할 때는 반드시 공식적인 변경 요청 절차를 거치도록 규칙을 정해두는 것이 좋습니다.

응용·확장: 범위 설정 노하우를 다른 프로젝트에도 적용하기

지금까지 다룬 범위 설정 방법론은 단순히 시스템 교체 프로젝트에만 국한되지 않고, 여러 상황에 응용할 수 있습니다.

예를 들어 클라우드 전환 프로젝트를 진행 중이라면, 온프레미스 서버에 있던 데이터를 클라우드 환경으로 옮기는 과정에서도 동일한 프로파일링-분류-매핑-ETL 절차를 그대로 적용할 수 있습니다. 클라우드 환경은 데이터 저장 방식이나 접근 권한 체계가 기존과 다를 수 있으므로, 매핑 단계에서 이 차이를 더욱 세심하게 반영해야 합니다.

또한 여러 부서의 시스템을 하나로 통합하는 프로젝트에서도 이 방법론이 유용합니다. 이 경우에는 원천 데이터 소스가 여러 개이므로, 각 부서별로 프로파일링을 개별적으로 진행한 후 통합 매핑 문서를 작성하는 방식으로 확장할 수 있습니다. 부서 간 동일한 의미의 데이터가 서로 다른 이름이나 형식으로 저장되어 있는 경우가 많기 때문에, 이 응용 시나리오에서는 특히 값 정규화 작업이 중요해집니다.

M&A(인수합병)로 인해 두 회사의 시스템을 통합해야 하는 상황에서도 유사한 접근이 필요합니다. 이 경우 데이터 볼륨과 복잡도가 훨씬 커지기 때문에, 범위 설정 단계에 투입하는 시간과 인력을 처음부터 넉넉하게 계획해야 합니다.

마지막으로, 이 글에서 다룬 범위 설정 프로세스는 일회성 이전 프로젝트뿐 아니라 지속적인 데이터 거버넌스 체계를 구축하는 출발점으로도 활용할 수 있습니다. 한 번 정리한 데이터 사전과 매핑 문서는 향후 시스템을 다시 교체하거나 확장할 때도 재사용할 수 있는 귀중한 자산이 되므로, 프로젝트가 끝났다고 폐기하지 말고 지속적으로 관리하는 것을 권장합니다.

점검 체크리스트: 개발 착수 전 마지막으로 확인할 것들

개발팀에 범위 문서를 넘기기 전, 다음 항목들을 마지막으로 점검해보시기 바랍니다.

☑ 원천 데이터 프로파일링이 완료되고 데이터 사전이 작성되었는가

☑ 필수·선택·제외 데이터 분류가 이해관계자 전원의 합의로 확정되었는가

☑ 소스-타겟 매핑 문서에 데이터 타입 변환 규칙과 값 정제 규칙이 명시되었는가

☑ ETL 절차(추출·변환·적재)와 테스트 이전 계획이 수립되었는가

☑ 롤백 절차와 검증 기준이 사전에 문서화되었는가

☑ 규정 준수(개인정보 등) 요구 사항이 법무·보안 담당자와 함께 검토되었는가

☑ 다운타임 발생 가능성과 일정이 사전에 공지되었는가

이 체크리스트를 모두 통과했다면, 개발팀은 명확한 범위와 매핑 규칙을 기반으로 안정적으로 개발에 착수할 수 있습니다.

자주 묻는 질문 FAQ

Q1. 데이터 이전 범위를 정하는 데 보통 얼마나 시간이 걸리나요?
시스템 규모와 데이터 복잡도에 따라 크게 달라지기 때문에 일률적으로 말씀드리기는 어렵습니다. 다만 클라우드플레어 자료에서도 사전 마이그레이션 단계를 별도의 초기 계획 단계로 명확히 구분하고 있는 만큼, 개발 일정과 별개로 충분한 시간을 확보해두는 것이 안전합니다.

Q2. 오래된 데이터는 무조건 이전 대상에서 제외해도 되나요?
사용 빈도가 낮다고 해서 무조건 제외하기보다는, 규정 준수 요구 사항이나 향후 조회 가능성을 함께 검토한 후 결정해야 합니다. 필요하다면 아카이브 형태로 별도 보관하는 방안도 고려해볼 수 있습니다.

Q3. 데이터 정제는 이전 전에 해야 하나요, 이전 후에 해야 하나요?
가능하면 이전 전(ETL의 변환 단계)에 정제하는 것이 바람직합니다. 정제되지 않은 데이터를 그대로 새 시스템에 옮기면 새 시스템에서도 동일한 품질 문제가 반복되기 때문입니다.

Q4. 매핑 문서는 개발자가 직접 작성해야 하나요?
개발자만 작성하기보다는 실무 담당자, IT 담당자, 개발팀이 함께 검토하며 작성하는 것이 효과적입니다. 실무 맥락을 아는 사람이 검토에 참여해야 매핑 오류를 초기에 발견할 수 있습니다.

Q5. 범위를 확정한 후에 변경이 생기면 어떻게 해야 하나요?
변경 자체를 막을 수는 없지만, 공식적인 변경 요청 절차를 거치도록 사전에 규칙을 정해두면 무분별한 범위 확대를 방지할 수 있습니다.

---

지금까지 프로그램 개발 전 데이터 이전 범위를 정하는 절차를 프로파일링부터 ETL 설계까지 단계별로 살펴봤습니다. 범위 설정은 시간이 걸리는 작업이지만, 이 과정을 충실히 거칠수록 개발 단계에서의 재작업과 혼선을 크게 줄일 수 있습니다. 새 시스템 도입을 앞두고 계시다면 이 글의 체크리스트를 팀과 함께 활용해보시기 바랍니다.