문서요약 - 데이터 마이그레이션 방법론 개요 by Hudicka

제목: 데이터 마이그레이션 방법론 개요(An Overview of Data Migration Methodology)

저자: Joseph R. Hudicka, 미국

문서유형: 웹문서, 1998년

http://www.dulcian.com/Articles/Overview_Data_Migration_Methodology.htm

 

데이터 마이그레이션 프로젝트의 수행 단계를 기술한 자료

---

데이터 마이그레이션

대부분의 소프트웨어 구현 노력은 아래의 두 의도 중 하나를 만족시키기 위해 수행된다.

• 신규 온라인 거래 처리(On Line Transactional Processing: OLTP) 시스템 전개
• 신규 온라인 분석 처리(On Line Analytical Processing: OLAP) 시스템 전개

 

신규 시스템이 위의 카테고리 중 어디에 속하든 하나 또는 그 이상의 레가시 시스템이 제공하는 기능을 대체 및 개선하는 목적을 가지므로 일부 데이터 전환(data conversion)이 필연적으로 발생한다. 즉, 현재 레가시 시스템에 의해 유지보수 되는 정보를 추출하고 이를 신규 시스템에 맞게 변환하는 작업인 데이터 마이그레이션이 대부분의 시스템 구현 노력에 공통적으로 포함된다. 데이터 마이그레이션은 레가시 시스템 재설계의 경우처럼 일회성으로 수행되거나 데이터 웨어하우스(data warehouse)의 경우처럼 지속적인 프로세스로 수행되기도 한다.

데이터 마이그레션의 7단계(The 7 Phases of Data Migration)

1) 전략 수립(Strategy)

전체 프로젝트의 핵심(the focus)을 결정. 데이터 마이그레이션 프로젝트가 독립적으로 시작되기 보다는 다른 개발 작업(OLTP 또는 OLAP 구현)의 일환으로 수행되는 점에 주의해야 한다. 자주 발생하는 근본적인 실수로 프로젝트 관리자가 신규 시스템이 충족시켜야 할 요구사항 결정에만 집중을 하고 이에 수반되는 데이터 마이그레이션은 그다지 신경을 쓰지 않거나 아예 무시하는 경우가 많다. 프로젝트 계획에도 데이터 마이그레이션이 단순한 하나의 작업 항목(a task item)으로 포함되어 있는 경우가 흔하지만, 실제는 그 자체로 하나의 프로젝트이며 그에 상응하는 계획과 노력이 필요하다는 것을 나중에 깨닫게 된다.

 

2) 분석(Analysis)

데이터 마이그레이션의 분석 단계는 핵심 프로젝트(즉, OLTP 또는 OLAP)의 분석 단계와 동시에 수행되도록 일정을 잡아야 한다. 이 단계에서는 새로운 시스템으로 이전되어야 하는 데이터 소스를 식별한다(OLAP의 경우 대개 다수의 데이터 소스가 존재). 데이터 소스에는 기존 애플리케이션 외에도 시스템으로 수행할 수 없는 작업을 위해 유지/관리하는 워드 프로세싱 문서, 스프레드시트, 데스크 탑 RDBMS 패키지, 텍스트 파일 등이 포함된다. 분석 단계의 또 다른 중요한 일은 마이그레이션을 계획한 실제 데이터에 익숙해 지는 것이다. 프로젝트의 이 시점에는 데이터가 마이그레이션이 가능한 정도의 품질인지도 불분명한 상태이므로 소스 데이터에 대한 레코드 수, 컬럼 수, 기타 다른 통계치를 제공하는 보고서를 검토하여 마이그레이션 할 데이터의 대략적인 볼륨을 가늠한다.

 

3) 설계(Design)

레가시 데이터 소스를 식별하고 데이터를 분석한 후에는 각 소스 데이터 구조에 대한 데이터 항목의 목록을 검토하여 각각의 마이그레이션 여부를 결정한다. 마이그레이션 후보로 선정된 각 데이터 항목이 데이터 모델에 변경을 줄 수 밖에 없으므로 데이터 마이그레이션의 설계 단계는 핵심 프로젝트의 분석 단계와 병행하여 이루어져야 한다. 설계 단계에서는 과거 데이터를 신규 시스템으로 바꾸는 변환 규칙(the transformation rules)을 완벽하게 식별하는 것 보다는 마이그레이션이 필요한 레가시 데이터 항목들의 체크리스트를 만드는데 집중한다.

 

4) 빌드(Build)

마이그레이션의 빌드 단계는 핵심 프로젝트의 설계 단계와 병행된다. 빌드 단계의 첫 작업은 새로운 데이터 구조를 만들고 이를 데이터베이스에서 생성하는 것이다. 데이터 매핑은 물리적 데이터 모델(the physical data model)에 수행해야 하며, 핵심 비즈니스 영역 각각에서 최소 3명이 팀을 이루어 매핑을 수행한다(한 사람은 마이그레이션 될 과거 데이터의 최종 사용자 프로세싱에 지식이 있는 비즈니스 분석가, 또 한 사람은 소스 시스템과 타겟 시스템에 지식이 있는 시스템 분석가, 나머지 사람은 데이터를 연구하고 비즈니스 분석가와 시스템 분석가가 협업하여 정의한 매핑에 따라 마이그레이션 루틴을 개발하는 프로그래머/분석가). 

5) 테스팅/구현(Testing/Implementation)

테스팅과 구현은 따로 떼기가 어려워 종종 한 단계로 결합된다. 테스팅은 크게 논리적 에러(logical errors)와 물리적 에러(physical errors)로 나뉜다. 물리적 에러는 구문(syntactical) 에러로 쉽게 식별 및 해결이 가능하고 매핑의 품질과는 관계가 없다. 구현은 논리적 에러를 식별하고 해결하는 단계로 매핑 실행이 성공적으로 완성되었다 하더라도 아래와 같은 사항들을 확인한다.

• 이 스크립트는 몇 개의 레코드를 생성하도록 되어 있는가?
• 올바른 개수의 레코드가 생성되었는가? 아니라면 무엇이 문제인가?
• 정확한 필드로 데이터가 로드 되었는가?
• 데이터가 올바른 포맷(format)으로 생성되었는가?

 

데이터 매핑을 제대로 테스트하려면 핵심 시스템의 분석과 설계에 참여했던 사용자에게 내용이 채워진 타겟 데이터 구조(the populated target data structures)를 제공하는 것이 좋다(사용자가 분석/설계 세션에서는 미처 생각하지 못했던 마이그레이션이 필요한 과거 데이터 항목을 식별하도록 도와줌). 이렇게 함으로써 많은 변환 및 매핑 요구사항(transformation and mapping requirements)을 추가로 발견할 수 있게 된다.

 

데이터 마이그레이션의 테스팅/구현 단계는 핵심 프로젝트의 설계와 빌드 단계에 앞서 이루어지도록 해야 한다. 그렇지 않은 경우 추가적인 마이그레이션 요구사항이 나타날 때마다 기 확립된 데이터 모델이 조금씩 무너지게 되고 여러 달의 개발 노력이 물거품이 될 수 있다(즉, 이 데이터 모델을 기반으로 개발된 애플리케이션의 근본적인 변경이 필요해짐).

6) 교정(Revise)

모든 데이터 모델 변경에 대해 변환 규칙 조정(transformation rule adjustment)과 스크립트 수정(script modification)이 이루어진다. 이 시점에 항상 등장하는 문제는 논리적 데이터 모델과 물리적 데이터 모델 양쪽 모두를 유지보수 해야 하는지 여부이다. 많은 프로젝트에서 논리적 설계와 물리적 설계의 연속성(continuity)을 유지하는 것을 목표로 하지만 실제는 이로 인해 얻는 이점보다 들어가는 노력이 많기 때문에 논리적 모델의 업데이트를 포기하는 경우가 많다(결과적으로 비일관적인 시스템 문서를 가지게 됨). 논리적 모델과 물리적 모델의 연관성을 유지하기 위해 CASE 도구를 활용하기도 한다

 

7) 유지보수(Maintain)

모든 매핑이 검증되고, 철저하게 테스트된 일련의 스크립트로 성공적으로 구현되는 단계이다. 마이그레이션 하는 시스템이 OLTP인지 OLAP인지에 따라 유지보수의 성격이 달라진다. 일회성 마이그레이션 개념인 OLTP는 레가시 데이터를 신규 시스템으로 성공적으로 마이그레이션 하고 나면 마이그레이션 스크립트는 더 이상 쓸모가 없게 된다. 즉, 스크립트가 한번만 런(run) 되므로 스크립트 성능에 그다지 신경을 안 쓴다. OLAP의 경우는 일정 시간 간격에 따라 신규 시스템을 재로딩 하게 되므로(새로운 정보가 OLTP 시스템에 레코딩 되면 이것을 OLAP 시스템으로 이전할 필요가 생김) 마이그레이션 스크립트의 성능이 매우 중요한 이슈이다.