DATOR


이행 프로젝트, 여행 가방 꾸리기...(주)엔코아 김중현 수석 컨설턴트 커버 스토리


coverstory.jpg


데이터 이행이라 함은 한 개 이상의 시스템(Source System)으로부터 다른 시스템(Target Syste)으로 데이터 또는 스키마를 옮기는 것을 의미한다.
또한 데이터 이행 유형, 절차, 이행 프레임워크 등은 아래 엔코아 리포트에 잘 정리되어 있다.
(데이터 이행을 위한 실전 방안: http://www.dator.co.kr/bmonthly/931261)

오늘은 이행 프로젝트에서 반드시 고려해야 할 누구나 알고 있지만 쉽게 되지 않는 몇 가지를 이야기하고자 한다.



첫 번째, 고객이 원하는 것과 내가 해야 할 것을 명확히 해야 한다.

지금 당신은 DA인가? 이행 개발자인가?
내가 그렇게 불러서 DA나 이행 개발자인가 아니면 남이 그렇게 불러서 DA나 이행 개발자인가?
하고 싶은 얘기는 당신이 이행 개발자라면 이행 개발자에 대해서 정의하고 필요한 것들을 요구하고 고객 또는 프로젝트 관련자와 사전에 협의를 해야 한다는 것이다. 회사 내 영업대표가 넌 이행 개발자라고 하면 당신은 이행 개발자인가? 절대 그렇지 않다. 고객이 프로젝트를 아웃소싱하면서 전문가 집단과 계약을 하는 목적은 짧게 정리하면 ‘잘 알아서 해달라’ 이다. 물론 단가는 싸게.


내가 아는 이행 개발자는 매핑정의서를 작성하지 않고 정의된 매핑정의서를 기반으로 Open Target Time 내 이행 완료를 목적으로 이행 및 검증 프로그램을 작성하고 수행한다. 물론 내가 정의한 이행 개발자에 대해서 이견이 있을 것이다. 강조하고자 하는 것은 어떤 역할을 하는 것이 이행 개발자이다라는 것이 아니라 투입된 팀원들이 이행 개발자는 어떤 것이다~ 라는 부분을 공유해야 하고, 영업과 고객과 차이가 발생한다면 프로젝트가 더 진행되기 전에 빨리 차이를 줄여나가야 한다는 점이다. 고객의 이행 개발자는 이행 전략 수립, 매핑정의서 작성 및 배포, 이행인프라 가이드, ETL, Target 적재, 개발자 SQL지원 까지를 이행 개발이라 하고, 투입된 팀원들은 작성된 매핑정의서를 기반으로 프로그래밍하여 데이터를 옮겨 주기만 하면 되는 것이 이행 개발자라고 한다면 어떤 일이 벌어질지 상상이 되는가? 경험하지 못하면 상상조차 할 수 없다. 그렇게 힘들면 왜 못한다고 나오지 않냐고 물어 볼지도 모른다. 그게 참 그렇다. 회사, 가족, 책임, 도전… 난 이미 많은 관계를 맺고 있고 그렇게 살 수 밖에 없다. 하지만 정말 아닌 것은 절대 사라지지 않는다. 다만 무뎌질 뿐이다.


프로젝트 투입과 동시에 고객이 원하는 것을 충분히 듣고 파악하고 거기에서 내가 할 수 있는 것과 할 수 없는 것, 그리고 내가 좀 더 해줄 수 있는 것을 명확히 목록화하고 할 수 있는 것에 대한 업무적 종속성을 고려하여 ‘내가 A같은 것을 하려면 B같은 것들이 필요하고 C같은 것들은 누가 제공해 줘야 한다.’를 반드시 명문화하여 고객의 확인을 받아야 한다. 고객이 “알았으니 그건 됐고 언제부터 매핑할 거에요 이행 프로그래밍 언제 끝날 수 있다는 거에요?” “일단 보고하는 내 입장을 봐서라도 이 문구는 빼고” “일단 이렇게 작성하고 나중에 다시 변경합시다. 지금은 그냥 원래 제안대로 가시죠” 등 이런 말들은 흘려 듣고 반드시 꼭 필히 수행계획서(SOW)에 내가 해야 할 것(하려면 필요한 것들 포함), 할 수 없는 것을 상세히 하자. 요약이 아니고 추상적이지 않은 정말 명확하고 상세히 적어야 한다. 프로젝트를 그래도 상식적으로 수행할 수 있나 없느냐는 이 과정에서 90% 결정된다. 더불어 중요한 것이 내부 팀원과 공유와 협의를 통해서 이뤄져야 한다는 점이다. 내부 PM 혼자 결정해서 작성된 수행계획서(SOW)는 내부 분란 및 내부 PM과 수행원 사이의 거리감을 넓히는 시초가 되기도 한다. 프로젝트는 1등보다는 마지막 사람까지 모두 끝나야 끝나는 것이니 많이 얘기하고 많이 듣고 서로 밀어 주고 당겨주고 그렇게 가야 한다.




두 번째, 내가 일하고 있음을 널리 알려라.
DA업계에 종사하는 사람들은 대쪽 같은 선비가 많다. 스스로 옳다고 생각하면 타협하지 않고 어떤 외압에도 흔들리지 않고 언제가 진실은 밝혀질 것이라 믿는 경우가 있다. 정의는 승리하고 진실은 언젠가 밝혀진다는 진리를 반박하고자 하는 것은 아니지만, 역사적으로 어느 시점을 보면 정의는 패배하고 진실은 깊고 캄캄한 심해 속에 가라 앉아 있기도 하다.


짧게는 6개월, 길게는 2년 남짓한 프로젝트에서 결국은 내가 옳았다는 것을 알게 될 거라고 묵묵히 욕먹고 뒷얘기 들으면서 일하고 있지는 않은가? 결국 프로젝트 끝날 때쯤에는 자신을 인정해 줄 거라고 믿고 있지는 않은가? 길어야 2년 남짓한 프로젝트이며 100~300여명이 수행하는 프로젝트이다. 전염성 높은 바이러스도 아니고, 절대 우리가 스스로 우리의 우수성을 증명하지 못하면 몇몇 소수만이 알 뿐, 그 소수 조차도 프로젝트가 원활히 진행되지 않았을 경우엔 결과가 없는 곤란한 존재로 우리를 평가한다. 아무리 열심히 일했어도 말이다.
모델링의 주요한 목적 중 하나가 업무 관계자 간 커뮤니케이션이고 항상 다수를 상대해야 하는 소수 입장에서 DA의 침묵은 절대 좋은 방법이 아니다.


이행 프로젝트를 수행하면서 작성하는 모든 산출물 – AS IS 분석서, TO BE 모델 설명서, 매핑정의서, 이행 전략 등- 들은 사전에 관련자와 항상 공유하고, 조금이라도 프로젝트 수행에 도움이 되는 경우라면 자료를 만들어 배포해야 하며, 특히 데이터 집합간의 변환 규칙을 정의한 매핑정의서는 반드시 단순 컬럼 매핑 정보 외 상세한 이행 규칙 등이 작성되어 관련자들과 공유/배포 되어야 하며, 배포 후에는 변경 관리 – 변경 요청자, 요청 사유, 요청 일자, 변경 일자 등 – 가 되어야 한다. 프로젝트가 정상적으로 수행될 경우에는 큰 문제가 없을 지 몰라도 산으로 가는 프로젝트(마치 Survival 게임장 같다. 자신과 자신이 속한 팀의 생존에 목적이 있지 프로젝트에는 관심이 없고 누구를 희생양으로 삼아야 할까?를 고민하고 실천한다)의 경우 매핑정의서 공유/배포/변경 관리가 되고 있지 않다면 굶주린 하이에나에 둘러싸인 얼룩말이나 우리나 다를 바 없게 된다.


업무적 관련자들과 밀접한 관계를 맺고 있는 문서들은 사전에 잘 정리해 두고 요청 전에 공유, 배포 해야 한다. 최소한 요청했을 때 바로 제공이 가능해야 한다. 그 외 “당신 오늘 뭐 했어요?” “그 일을 하는데 얼마나 걸려요? 누가 시켰어요?”라는 초등학생도 하지 않는 유치한 질문에 근거를 댈 수 있다면 최상이다. 이 부분은 프로젝트 분위기를 봐서 내부에서 결정하면 된다(생각보다 그런 기업 문화를 가진 갑들이 없지 않다). 반드시 내가 한 일은 기록하고 공유하고 널리 알리자.




세 번째, 이행 룰이 명확하지 않더라도 검증은 필수.
데이터 이행에서 검증은 크게 기본 검증과(건수, 합계, 코드, RI) 비즈니스(업무 연속성 관점에서 업무 룰을 적용한 검증) 검증으로 나눌 수 있다. 그럼 이행 규칙이 잘못 됐다고 했을 때 기본 검증도 틀린 결과가 나오는가?


아니다. 비즈니스 검증은 잘못된 결과가 나올지라도 기본 검증 특히 건수, 합계 검증은 이행 규칙과는 별개로 맞아야 한다. 아직 요건이 명확하지 않은 이행 규칙일지라도 그 상태로 이행을 했다면 건수, 합계 검증은 반드시 맞아야 한다. 모든 검증의 출발은 건수와 합계 검증이다. 이행 소스를 그대로 COPY한 검증이 아니라 Source와 Target만을 대상으로 건수와 합계를 증명해야 한다. 
Source Table 건수(이행 제외 대상 건수) 이행 추가 건수 = Target Table 건수


초기 이행 프로그램 작성 시에 모든 검증을 다 작성하기는 어려울지 모르지만 최소한 건수와 합계 검증은 반드시 작성해야 한다(설사 Source Table 단순 Copy 작업일지라도).
기본 검증 통과는 어려울지 몰라도 첫 통과를 거치게 되면 그 후는 여유롭게 진행될 수 있을 것이다.




네 번째, 이행 서버 Disk 산정 시 고려 사항.
대부분 이행 프로젝트 수행 시 이행 서버의 Disk 용량은 Source System의 3배 정도를 구성한다. 일반적으로 차세대를 진행하면 Target System은 Source System 대비 최대 70%를 넘지 않는다. 여기서 강조하고자 하는 점은 3배 또는 70%등 정량적 수치가 아니라 어떤 점을 고려해야 하는가이다.


① Source System에서 이행 서버에 Source 적재 공간은 최소 2벌의 Source를 관리할 수 있어야 한다.
통합 테스트를 하게 되면 짧게는 3주 길게는 5주마다 테스트 일정에 맞게 이행을 하게 되고, 즉 테스트와 다음 테스트에 대한 이행이 동시에 이뤄지게 된다. 따라서 테스트 결과에 대한 문의 응대 및 이행이 병행되는 것뿐만 아니라 배치 신구대사를 위해서도 배치 수행 전 Source와 배치 수행 후 Soure를 관리하면 검증에 큰 도움이 된다.


② Soure – Target Gap이 클 경우 이행 과정에서 성능상 이슈로 생기는 Temp 영역을 반드시 고려해야 한다.
In-House 프로젝트의 경우에는 Soure와 Target간 Gap이 그렇게 크지 않다. 하지만 Target이 패키지 기반이거나, Source – Target 집합 변화가 클 경우 Temp Table을 활용할 수 밖에 없는데 복잡한 이행일수록 Temp Table의 활용도는 높을 수 밖에 없다.


③ Target 적재 전 즉 이행 완료 시점 데이터를 백업할 수 있는 공간은 반드시 확보해야 한다.
통합 테스트 데이터 이행이 끝나게 되면 이행팀은 이행 변경 작성 또는 검증 추가 등의 작업을 통해 이행 데이터의 변경이 가해지므로, Target 적재 전 데이터는 반드시 백업해 놓아야 한다.



이행은 DA 프로젝트의 종합 선물 세트라고 얘기하기도 하고, 한 번은 반드시 경험해야 하지만 두번은 망설여지기도 한다. 그만큼 광범위하고 어렵기도 하다. 하지만 세상만사 모두 그렇듯이 기본을 지키고 소통을 중요시한다면 생각보다는 즐거운 프로젝트가 될 것이다.

조잡한 글이지만 여기까지 읽어주신 모든 분들께 감사를 드리며, 기회가 된다면 이행에 대해서 좀 더 상세한 내용으로 다시 뵙기를 소망한다.




Tag :

Leave Comments