(13편) 설계 산출물6: 데이터 이관 작성법 및 가장 중요한 리스크 알아보기

카테고리 없음

by 늦둥이아빠 2024. 4. 14. 09:32

데이터 이관 계획서는 설계 산출물 중 가장 마지막에 작성합니다. 기존 시스템에 저장된 데이터를 DB, 파일 형태에 따라 이관 계획을 수립하는 단계입니다. 대부분 데이터 정제와 고객요구사항 그리고 자료에 대한 검증을 어떻게 할 것인가에 초점이 맞춰져 있습니다. 하지만, 정작 중요한 것을 놓치면 경우가 있습니다. 권한 문제입니다. 권한이 잘못 설정되면 암호문서, 비밀문서가 풀리는 사태가 발생하고, 비공개 문서가 공개되어 모든 사람이 보게 되는 사태가 발생할 수 있습니다. 오늘은 기존 시스템에서 신규 시스템으로 어떻게 이관하고, 자료 검증 시 가장 놓치기 쉬운 권한 문제를 다뤄볼까 합니다.

(13편) 설계 산출물6: 데이터 이관 작성법 및 가장 중요한 리스크 알아보기

데이터 이관 이해하기

데이터 이관 기존 시스템에서 신규 시스템으로 DB와 파일을 이관하는 과정을 의미합니다. 일반적으로 이관 환경을 만들고, DB 이관의 경우 기존 DB를 이관 환경의 Temp DB에 복사한후 변환하여 신규 시스템으로 이관하는 과정을 거칩니다. 파일의 경우는 이관 툴을 만들어 신규 시스템으로 이관하는 과정을 거칩니다. 하지만, 이관 툴을 가지고 있다고 하더라도 파일 데이터의 경우 변환 과정이 들어가 있어 아주 시간이 많이 걸리며, 검증하는 과정도 거쳐야 합니다. 그래서, 1차 이관 전 시범 테스트 이관을 이관 툴의 안정성과 시간 소요시간 등을 체크하고 별 이상이 없다면 1차 이관을 실시합니다. 1차 이관은 전체 대상의 90%를 이상을 이관하고, 오픈 전 약 10%를 이관하는 식으로 하여 이관을 진행합니다.

이관 계획 수립

이관 일정은 파일 데이터의 량과 이기종의 DBMS의 종류에 따라 이관 일정과 투입인력등급, 투입인력 기간은 다릅니다. 통상 프로젝트 기간이 8개월이라면 이기종 시스템간의 이관은 약 5~6개월 정도로 산정을 하고 있습니다. 따라서 프로젝트 시작과 함께 이관 분석이 진행되어야 하며, 프로젝트 오픈 전까지 완료할 수 있도록 역산하여 일정을 수립하여야 합니다. 대부분의 기업들은 이관 툴이 있다고는 하지만, 고객의 시스템 환경 등을 명확히 파악하여 이관 일정이 수립되어야 합니다.

또한, 이관에 투입할 인력 계획과 수행 내역 등을 명확히 작성하고, 기존 시스템의 데이터 분석이 끝나면 개발 서버를 활용하여 테스트 이관, 즉 시범 이관을 어떻게 할 것인지 일정을 수립하고, 이관 툴은 언제 어떻게 개발 할 것인지를 명확히 해야 합니다.

데이터 이관 절차

데이터 이관을 위해서는 데이터 분석 및 설계 단계에서 자료를 수집하고, 요구사항을 분석합니다. 데이터 정비 과정은 테이블 중복이나, 데이터 중복, 미 사용 데이터 등을 고객과 협의하여 정비하는 작업을 진행하며, 데이터 정비가 끝나면 전환 데이터를 신규 시스템에 맞게 데이터 형태를 가공하여 이관 될 수 있도록 프로그램을 조정합니다. 이관 테스트를 한 후 문제없이 이관이 된다면 전환 이행을 수행합니다. 수행 후 검증작업을 진행하여 완료합니다.

다음은 이관 절차별 상세 단계와 각 단계별 작업내용을 정의한 내역입니다.

절차	상세 단계	작업 내용	비고
데이터 분석 및 설계	자료현황조사	기존 시스템 이관 대상 확정
	자료수집	기존 시스템 이관 대상 수량 및 크기 파악
	자료 및 요구사항 분석	기존 시스템 이관 대상 데이터 분석
자료 정비	정비대상 자료정의	기존 시스템 이관 대상 최종 확정
	자료정비 방안분석	기존 시스템 이관 대상 데이터 형태 분석
	자료정비	기존 시스템 데이터를 신규 시스템에 맞는 데이터 형태로 재배치
전환 프로그램 작성 및 시험	전환프로그램 구조 설졔 및 작성	기존 시스템 데이터를 신규 시스템에 맞는 데이터 형태에 맞게 전환프로그램 설계 및 구현
	단위시험	신규 시스템 전환프로그램 단위 테스트 수행
	전환시험 수행	기존 시스템 데이터를 신규 시스템으로 시범이관
	전환 데이터 및 시나리오 검증	시범이관 결과서 작성 및 전환 시나리오 보완
이행	사전 점검	신규 시스템 전환 환경 사전 점검
	데이터 전환	기존 시스템을 신규 시스템으로 전환
	사후작업 및 최종점검	데이터 전환 완료 후 전환결과보고서 작성

데이터 점검 및 정제

데이터 이관 대상은 다음과 같은 기준에 의해 결정됩니다. 메일의 경우 포맷이나 형식이 많이 다른 경우 이관 대상에서 제외하고 있습니다. (예-MS Exchange, IBM Notes에서 상용 SW 메일로 이관 등 이기종 메일 간 연동은 실제 이관 소요 시간이 많이 걸리며, 관련 전문가가 없는 경우 이관이 불가능한 경우도 있습니다.) 하지만, 메일 이관을 해달라고 한다면, 이 부분에 대해서는 기술검토가 명확히 되어야 합니다. 영업적으로 해 준다고 해 놓고, 실제 프로젝트에서는 이관이 제대로 되지 않아, 프로젝트가 지연되는 사유가 됩니다.

다음은 결재문서, 게시판, 조직도 이관에 대한 내용입니다.

- 기존시스템에서 결재가 완료된 전자결재문서 (년도별, 용량, 건수 체크)

- 기존시스템에서 고객에 의해 선별된 게시판 (년도별, 용량, 건수 체크)

- 기존시스템에서 사용중인 조직도

데이터 검증 절차

데이터 검증은 1차 검증과 2차 검증 그리고 마지막 3차 검증으로 나누어 실시합니다. 1차 검증은 전환 전 그 대상 DB 및 자료 건수가 일치하는지 여부를 검증하며, 2차 검증은 자료 전환 결과 이관 후 DB 데이터, 파일 건수를 체크하고, 전환 로그 확인 후 오류가 확인되면 오류 데이터 재변환합니다. 이때 데이터 무결성 검증을 이관 전 해시 값을 생성 후 이관 후 원본 해시값과 비교하는 간단한 로직을 사용하기도 합니다.

마지막 3차 검증은 기존 시스템 데이터에서 신규 시스템 이관 후 데이터 집계를 확인합니다.

검증 단계	검증 방안	비고
(1차) 전환대상 자료 파악	DB 기준 이관대상 건 수량 체크 File 건 수량 체크
(2차) 자료 전환	이관 후 DB 데이터 건 수량 체크 이관 후 File 데이터 건 수량 체크 전환 Log 확인 후 오류 체크 오류 데이터 재변환	이관전 데이터 건수는 고객측에서 제공해야 함
(3차) 전환 후 데이터 검증	기존 시스템과 신규시스템간 동일한 검증 기준으로 데이터 집계 확인

검증 시 권한 세팅에 대한 검증을 철저히 검증하라

결재 완료 문서는 기본적으로 부서 단위 공개를 원칙으로 하고 있으며, 하지만, 비공개문서가 있으며, 권한에 따라 결재라인에 있는 사람들만 볼수 있는 경우도 있습니다. 또, 게시판의 경우는 부서, 팀단위, 본부단위, 전사단위로 권한 체계가 복잡하게 구성되어 있으며, 게시판에 따라 비공개 게시판, 익명게시판, 글쓴이와 답변자만 볼수 있는 게시판 등이 있습니다. 이렇게 복잡하기 때문에 아무리 테스트를 하더라도 고객도 놓치고 그냥 오픈이 되는 경우가 있습니다. 프로젝트가 아주 잘 진행되었다고 하더라도, 한방에 수행사의 신뢰성에 심각한 문제가 발생할 수 있으며, 심지어 프로젝트가 위험으로 치닫게 될 수도 있습니다.

고객이나 이관팀 모두 권한 문제를 소흘히 다루는 경향이 있습니다. 사업초기부터 이 권한 문제를 심각하게 보고, 데이터 조사단계부터 이 부분을 집고 넘어가야 합니다.

하지만, 담당자가 퇴사를 했고, 문서도 없다면 이 부분은 블랙홀이 되어 버립니다. 그냥 저냥 넘어가고 이관만 열심히 한 다음에 결국 테스트 과정이나 오픈 이후 발생하게 됩니다.

이런 권한 문제를 해결하기 위해서는

먼저, 주관사인 고객은 권한관리 문서를 정확히 체크하고 있어야 합니다. 권한 관련된 정책이나 권한 테이블의 구조를 한눈에 알아 볼 수 있는 문서를 관리해야 합니다.

둘째, 정보시스템 담당자가 프로젝트 시점에 투입 할 수 있는 지와 권한관리를 할 수 있는 대체 인력이 있는지도 알고 있어야 합니다. 업그레이드 사업의 경우 이를 모두 알고 있는 정보시스템 담당자가 퇴사하는 경우가 많기 때문입니다.

셋째, 정보시스템 담당자가 퇴사했다면, 수행사에게 명확하게 이 부분에 대한 소스 분석을 의뢰해야 합니다. 이 회사는 이 분야에 아주 오래된 회사이기 때문에 당연히 알것이라는 생각으로 그냥 알아서 해 주겠지 하는 생각은 버려야 합니다. 권한체계는 그 회사의 고유한 정책이기 때문에 아무도 알수 없습니다. 그 회사만이 알고 있습니다.

특히, 게시판의 경우 300개가 넘어가는 게시판이 존재하고, 부서별, 팀별, 그리고 게시판별 권한체계가 다른 경우 가장 문제가 되니 고객측에서는 프로젝트 기간 만이라도 향후 운영을 위해서라도 권한 관리자를 별도 두어야 합니다. 결재 완료 문서의 경우는 비공개 문서의 개념이 어떻게 쓰이고 있는지, 결재완료 문서의 공개 범위는 어디까지인지를 사전에 명확히 파악하시길 권고 드립니다.

마치며

오늘은 설계 단계 산출물 중 데이터 이관 계획서 작성법에 대해 알아보왔습니다.

데이터 이관이 문제 없이 되었다고 하면, 그 프로젝트는 잘 끝나게 될 것입니다.

하지만, 데이터 이관은 단순히 문제가 아닙니다. 권한문제가 걸려 있기 때문입니다. 권한에 따른 데이터 이관이 되어야 합니다. 권한이 잘못 설정되면 암호화된 비밀문서가 풀리는 현상과 또 다른 사람의 문서가 나의 폴더에 들어와 있을 수 있습니다. 만약 이렇게 되면, 엄청난 파장이 올 수 있습니다.

이런 의미에서 데이터 이관 계획 수립은 사전에 발생할 수 있는 리스크를 점검하고, 이관 절차를 확인함으로써 체계화하고, 안정적인 이관을 할 수 있다는 점에서 아주 중요합니다.

다음 편에는 구축단계 산출물들에 대해 알아보도록 하겠습니다.

프로젝트에 대해 다른 사항이 궁금하시면 아래 링크를 클릭하세요

(1편) 프로젝트: 기술협상서 작성하기
(2편) 프로젝트: 사업수행계획서, WBS 작성하기