SQL BOOSTER 이어지는 이야기 몰아보기: https://cafe.naver.com/dbian/6444
서른 여섯번째, SQL BOOSTER 이어지는 이야기입니다. 지난 글에 이어 데이터 이행에 관련된 내용입니다. 데이터 이행을 고민하고 계신 분들이 있다면, 한 번쯤 읽어보실만한 글이라 생각합니다.
아래는 PDF로 작성된 문서입니다. 누군가에게 도움이 되길 바래봅니다.
데이터 이행(Migration)의 꽃은 ‘키맵’이라고 이전의 글에서 정의했습니다. 그렇다고 키맵만 잘 만들면 이행을 성공하는 것은 절대 아닙니다. 키맵은 복잡한 데이터 변환 처리를 위한 핵심 기술 중 하나입니다. 데이터 이행이 성공하기까지는 많은 난관이 존재합니다. 이러한 난관을 뚫기 위해 어떠한 것들이 필요한지 살펴보도록 하겠습니다.
36-1. 데이터 이행 프로젝트의 분류
데이터 이행을 성공으로 이끌기 위한 열쇠가 무엇인지 살펴보기 전에, 데이터 이행 프로젝트를 분류해보도록 하겠습니다. 데이터 이행 프로젝트는 다음과 같이 분류해 볼 수 있습니다.
구분 | AS-IS VS TO-BE
DBMS | AS-IS VS. TO-BE
테이블 구조 | AS-IS VS. TO-BE
데이터 체계 |
서버 교체 | 같음 | 같음 | 같음 |
변환 이행(4) | 같음 | 같음 | 다름 |
재설계 이행(5) | 같음 | 다름 | 다름 |
이기종 이행(3) | 다름 | 같음 | 같음 |
이기종 변환 이행(4) | 다름 | 같음 | 다름 |
이기종 재설계 이행(5+) | 다름 | 다름 | 다름 |
위의 분류는 제 임의대로 해본 것입니다. 개인적인 기준이므로 사람마다 다를 수 있습니다. 이행 프로젝트 명칭 역시 제 나름대로 지어 본 것이며, 실제 현장에서는 이처럼 구체적으로 나누어 부르기보다는 ‘데이터 이행 프로젝트’ 또는 ‘데이터 전환 프로젝트’ 정도로 뭉뚱그려 부릅니다. 프로젝트 분류명 옆에 괄호 안의 숫자는 개인적으로 생각하는 이행 프로젝트의 난이도입니다. (1)이 가장 쉬운 난이도, (5)가 가장 어려운 난이도입니다.
제가 지금까지 진행해온 프로젝트는 (5) 난이도의 재설계 이행입니다. 재설계 이행은 테이블 구조의 변경 정도와 데이터 체계의 변경 정도에 따라 난이도가 달라집니다. 그리고 이기종 이행은 AS-IS와 TO-BE DBMS의 차이에 따라 난이도가 올라갈 수 있습니다. 어쨌든, 데이터 이행 프로젝트는 다양한 케이스와 다양한 난이도가 존재합니다. 이 글은 테이블 구조와 데이터 체계가 변경되는 재설계 이행을 주제로 합니다.
36-2. 신속하고 정확한 의사 결정
테이블 구조나 데이터 체계가 변경되는 재설계 이행은 담당자의 효율적인 ‘의사 결정’이 필수입니다.
예를 들어, TO-BE의 주문 테이블에 ‘주문처리유형’이라는 새로운 컬럼이 추가되었다면, 해당 컬럼이 AS-IS의 어떤 컬럼을 이용해 변환되는 컬럼인지, 디폴트 값으로 처리해야 하는지를 빠르게 결정해 주어야 합니다. 또는, 주문번호가 새로운 주문ID 체계로 변경된다면 어떤 방식으로 변경되는지도 잘 결정해 주어야 합니다.
이러한 내용 대부분은 TO-BE 모델을 그리는 데이터 모델러가 어느정도 정리를 해주어야 하는 부분입니다. AS-IS 시스템을 TO-BE로 전환한다는 것은, AS-IS 데이터를 TO-BE로 적재해야 하기 때문에, AS-IS 데이터 각각이 TO-BE의 어디로 들어갈지 정의하면서 데이터 모델을 설계해야 합니다. 그러므로 일차적인 의사 결정을 수행할 담당자는 ‘데이터 모델러’가 되어야 합니다. 하지만, 모델링 과정에서 정의가 어렵거나, 정의가 누락된 부분도 존재합니다. 이러한 부분은 실제 이행 프로그램을 개발하는 과정에서 발견이 됩니다. 이러한 이슈가 나왔을 때, 의사 결정을 해줄 담당자는 AS-IS와 TO-BE 시스템을 모두 이해하는 사람입니다. 보통은 운영팀의 데이터 모델을 관리하던 담당자가 해당합니다. 이 역할의 사람이 의사 결정을 신속하고 정확하게 해주어야, 이행 프로젝트가 원만하고 수월하게 진행될 수 있습니다.
이 글에서는 1차 의사 결정을 모델러가, 2차 의사 결정을 운영팀 담당자라고 정의했지만, 프로젝트마다 상황이 다를 수 있습니다. 업무 담당자나 어플리케이션 분석가, 또는 개발팀 리더가 더 적절한 의사 결정자 일 수 있습니다. 중요한 것은 누군가 의사 결정을 적시에 해주어야 한다는 점입니다.
의사 결정은 데이터 이행만이 아니라. 프로그램 개발 일정에도 매우 중요한 요소입니다. 응용 프로그램 개발팀과 이행 개발팀의 실력이 문제없다는 전제하에, 프로젝트 일정을 크게 좌우하는 요소 중에 하나는 담당자의 의사 결정일 것입니다. 또한, 의사 결정이 잘못되었다고 해서 서로 감정 상하지 않도록 노력해야 합니다. 큰 프로젝트일수록 의사 결정이 변경될 가능성이 존재합니다. 이러한 부분을 어느정도 인지하고 유연하게 프로젝트에 임할 필요가 있습니다.
36-3. 우린 도구가 필요하다.
재설계 이행을 위해서는 적절한 이행 툴이 필요합니다. 재설계 정도가 심하고 대상 테이블이 많을수록 이행 툴 없이 이행을 진행하기는 어려움이 많습니다.
재설계 이행에는 매핑 정의서가 필요합니다. 일차적으로 AS-IS VS. TO-BE 테이블에 대한 매핑을 정의하고, 테이블 매핑에 따라, 세세한 컬럼 매핑 정의서까지 필요합니다. 이러한 매핑 정의서가 있어야 AS-IS 데이터가 TO-BE의 어떤 데이터로 변환되는지 추적할 수가 있습니다. 프로젝트에 따라서는 매핑 정의서를 참고해 개발자들이 개발을 진행하기도 합니다. 매핑 정의서를 정리하기 위해 가장 많이 사용하는 툴은 엑셀입니다. 하지만 이행할 테이블이 많고, 매핑 룰이 자주 변경될수록, 엑셀로 매핑을 관리하고 공유하기에는 어려움이 있습니다. 그렇기 때문에 매핑 정의서를 DB화하고 관리할 수 있는 별도의 툴이 있으면 이행 프로젝트 진행에 큰 도움이 됩니다.
매핑 정의서가 작성되었다면, 이제는 이행 프로그램을 개발할 차례입니다. 재설계 이행은 재설계 정도에 따라 복잡한 SQL을 동반합니다. 작성된 이행 SQL을 어떻게 보관하고 관리할지 고민이 필요합니다. 이행 프로그램은 시스템이 오픈하기 전까지 빈번하게 변경되기도 합니다. 또한, 개발자나 운영팀의 요청으로 로직을 확인해주어야 할 때도 있습니다. 그러므로 필요할 때 빨리 찾아볼 수 있도록 이행 SQL을 관리해야 합니다. 이러한 관리 역시 툴을 사용한다면 비교적 간편합니다. 툴이 없다면, 각자 SQL 스크립트를 작성해 저장해서 관리하거나, DBMS 내에 각각의 프로시저로 구현해 관리합니다.
매핑 정의서를 관리할 툴과, 이행 SQL을 관리할 툴 없이 이행 프로그램을 모두 개발했다고 가정해 봅니다. 이제 이행을 위해 작성된 SQL들을 실행할 차례입니다. 이 역시 만만한 작업이 아닙니다. 어떤 SQL이 성공적으로 실행되었는지, 실패했는지를 모두 추적해야 하며, 혹시라도 이행 프로그램 간의 순서가 있다면, 이 역시 잘 지켜졌는지 확인할 수 있어야 합니다. 그리고 이행에 대한 결과를 리포트화해야 합니다.
찾아보면, 앞에서 설명한 기능들을 지원하는 상용 툴이 존재(대표적으로 Informatica, Data-Stream과 같은 툴이 있습니다.) 하지만, 가격이 저렴하지 않고 해당 툴을 능숙하게 다룰 수 있는 인력도 필요합니다. 또는 오픈소스에도 이러한 툴이 있을 수 있습니다. (개인적으로 찾아보거나 사용해 보지 않아 정확히 알지는 못합니다.)
제가 최근에 진행한 이행 프로젝트에서는, 프로젝트에 맞는 맞춤 이행 툴을 개발해 사용했습니다. DBian과 꾸준히 협업해온 변동구 이상님이 개발한 ‘mi’라는 툴입니다. 이행 초기에 변이사님이 현재 프로젝트에 맞게 ‘mi’를 맞춤 개발했고, 해당 툴을 통해 수월하게 이행을 진행하고 있습니다. 짧은 기간에 개발한 ‘mi’는 다음과 같은 막강한 기능들을 가지고 있습니다.
Miscellaneous | Mapping | Verify / Data | Development | Run Migration |
오브젝트검색 | 데이터베이스 | 검증항목정의* | 테이블이행* | 이행정의 |
테이블정보 | 모델동기화 | 공통코드매핑 | 스크립트검색 | 이행그룹 |
사용자 | 테이블목록* | 공통코드매핑현황 | 스크립트추출 | 이행순서* |
이슈관리 | 컬럼목록* | 매핑정의서 | Table vs SQL Check | 사전데이터체크SQL |
이슈관리대장 | 테이블매핑목록 | 이행대상테이블목록 | Table Rows, Size | 이행실행 |
컬럼매핑목록 | Session Monitoring | 이행결과* | ||
테이블매핑* | SQL Performance | 검증결과* | ||
프로그램목록 | Job Monitoring | 오브젝트백업 | ||
Tablespace Check | 운영DB 데이터체크 | |||
운영DB 셋업적재* | ||||
운영DB 최종적재* | ||||
Migration Summary | ||||
이행결과서 |
‘mi’를 통해 매핑을 정의하고 관리할 수 있으며, 그에 따른 이행 프로그램을 개발할 수 있습니다. 간단한 1:1 매핑이라면 별도의 SQL을 개발할 필요도 없습니다. 이행 프로그램을 툴 내에서 모두 관리하고 테스트할 수 있습니다. mi 내에서 이행을 실행할 그룹을 지정해 여러 이행 프로그램을 병렬로 실행도 가능합니다. 이행 프로그램 별로 다양한 검증 로직(PK, 데이터 건수, 릴레이션, 도메인, 업무로직)을 입력해 관리할 수 있습니다. 이행이 완료된 후에는 이행에 실패한 내용을 추적할 수 있으며, 이행 리포트까지 자동으로 추출해줍니다.
‘mi’는 상업화된 솔루션이 아닌, 기본 골격만 존재하는 툴입니다. 각 프로젝트 환경에 맞게 추가 개발과 커스터마이징이 필요한 툴입니다. 다시 말해, 이행 프로젝트마다 각각 맞춤으로 개발하는 시간이 필요합니다. 하지만, 이 툴이 완성되고 나면, 이행 개발 시간을 단축할 수 있으며, 수많은 테스트 이행과 리허설을 쉽게 처리할 수 있습니다. 하지만, mi가 이행에 관련된 모든 문제를 100% 해결해 주지는 않습니다. 데이터를 단순 이관하는 업무는 EXPORT/IMPORT와 같은 DBMS의 고유 기능을 사용하는 것이 성능에 더 유리할 수 있습니다. ‘mi’는 이행할 테이블이 많거나, 테이블 구조와 데이터 체계의 변경으로 SQL을 활용한 이행에 적합한 툴입니다.
결국 ‘mi’는 프로젝트를 편하게 진행하기 위한 자동화 툴이라고 볼 수 있습니다. 각 프로젝트 특성에 맞춘 자동화 툴을 마련해두면, 이후 진행되는 개발 과정이 훨씬 간단해지고 부담도 줄어듭니다. ‘mi’가 아니더라도, 다양한 언어와 방법으로 맞춤형 이행 자동화 툴을 별도로 개발하는 것은 충분히 좋은 선택지입니다.
36-4. 육각형 역량을 가진 팀
이행 프로젝트를 위해서는 ‘이행 경험치, 데이터 모델링, 의사소통, SQL, 튜닝, DBMS의 이해’와 같은 여섯 가지 역량이 필요합니다. 하지만 한 사람이 이 모든 역량을 다 완벽히 갖추기는 현실적으로 불가능합니다. 결국 팀을 이루어 협업하면서, 각 분야의 전문성을 상호 보완해 나가는 것이 핵심입니다. 이 역량들을 간단히 살펴보면 다음과 같습니다.
1. 이행 경험치
실제 이행 프로젝트에서 계획-개발-테스트-리허설-본이행까지 여러 단계를 거쳐본 경험이 있다면 훨씬 유연하게 이행 프로젝트를 진행할 수 있습니다. 이러한 경험이 있어야만 치밀하게 이행 계획을 세울 수 있으며, 경험을 토대로 예기치 못한 오류나 장애도 빠르게 해결할 수 있습니다. 실제로, 저희 팀에도 이행 경험치가 많은 분이 있어 이행을 진행하는 과정에서 많은 도움이 되고 있습니다.
2. 데이터 모델링
데이터 모델을 읽고, 데이터를 이해할 수 있어야 합니다. AS-IS와 TO-BE 모델 간의 구조적 차이를 정확히 파악해야 테이블과 컬럼 매핑을 할 수 있으며, 그에 맞게 이행 프로그램을 개발할 수 있습니다. 이행과 모델링이 한 팀에서 진행될 수도, 별개로 진행될 수도 있습니다. 이행과 모델링이 별개 팀으로 진행된다면, 이행팀에는 AS-IS와 TO-BE 모델을 모두 이해할 수 있는 팀원이 필요합니다.
3. 의사소통
이행 프로젝트는 데이터 모델러, 운영팀, 개발팀, DBA, 외부 협력사 등 다양한 주체와 협업이 필요합니다. 마이그레이션 범위·스케줄, 이행 룰, 이슈 해결방안 등 다양한 사안을 놓고 여러 팀과 협의해야 하므로, 명확하고 유연한 커뮤니케이션 능력이 필수적입니다.
4. SQL
테이블 구조나 데이터 체계가 달라지는 재설계 이행은, 복잡한 변환 로직이 필요합니다. 그 핵심은 결국 SQL 스크립트로 구현됩니다. SQL을 많이 작성해보고 잘 작성하는 개발자가 필요합니다.
5. 튜닝
대량 데이터 이행 시, 이행 SQL을 최적화해야 하는 경우가 종종 발생합니다. 또한 대량 데이터 이행을 위해 적절한 단위로 잘라서 처리할 수 있는 경험도 필요합니다. 정해진 이행 시간 내에, 이행을 완료하기 위해 SQL 튜닝 지식이 필요합니다.
6. DBMS의 이해
Oracle, MySQL, PostgreSQL처럼 서로 다른 DBMS 간 마이그레이션은 난이도가 높아집니다. 각 DBMS가 다른 부분을 인식하고 있거나 찾아내 문제를 해결할 수 있는 인원이 필요합니다.
이행 프로젝트에서는 다양한 역할의 팀원이 이 여섯 가지 영역을 분담하면서 협업하는 형태가 가장 바람직합니다. 누군가는 데이터 모델링에 강하고, 또 다른 누군가는 SQL과 튜닝에 특화되어 있을 수 있습니다. 이렇게 역량이 고르게 분포되어 있고 서로가 믿고 협업할 때, 복잡한 이행 업무를 안정적으로 처리하고, 프로젝트를 원활히 마무리할 수 있습니다. 하지만, 현실적으로 이런 팀을 구성하는 것이 쉽지 않습니다. 이행 프로젝트가 어려운 또 하나의 이유라 할 수 있습니다.