마이그레이션 적용 범위

장용희 팀장

마이그레이션의 의미는 다양하지만 이 글에서는 어플리케이션 시스템의 총괄적인 마이그레이션 적용 사례를 중심으로 소개한다. 많은 사용자들은 부분적으로 데이터베이스, 서버 통합 등의 마이그레이션으로 이해하고 있지만 그 부분은 기술적으로 난이도가 적을 뿐더러 일반적으로 일반 개발업체에서 총괄적으로 진행하는 프로젝트에서 처리하고 있다. 그러나 종합적인 개념의 마이그레이션은 다음과 같은 의미로 정리할 수 있어야 한다.

<그림 1> 마이그레이션의 의미

즉, 하드웨어에 해당하는 ‘서버’와 어플리케이션 시스템을 작성하기 위해 사용되었던 프로그램언어, 미들웨어, 웹 어플리케이션 서버 그리고 데이터베이스를 총괄적으로 포함하고 있는 마이그레이션 개념으로 정리하도록 하겠다.

마이그레이션의 진정한 의미
마이그레이션은 기존 시스템을 그대로 사용하거나 이동하는 방법이 아니라 기존의 알고리즘과 프로세스는 그대로 활용하되 현재 사용하고 있는 새로운 기술로 업그레이드 하는 기술을 의미하고 있다. 일반적으로 데이터베이스나 서버 마이그레이션의 의미는 기존 시스템을 수평으로 이동하면서 시스템의 변동 없이 재사용하는 기술로 이해하기 때문에 기술의 난이도가 낮고, 효율적이라기 보다는 필요성으로 이해하는데, 진정한 의미의 시스템 마이그레이션은 기존의 오래된 시스템을 신기술로 전환하는 기술로 이해하여야 한다. <그림 2>는 S카드의 마이그레이션 아키텍처이다.

<그림 2> S카드사의 마이그레이션 아키텍처

S카드 사례를 설명하면, 메인프레임 환경에서 운영되는 COBOL 프로그램을 오픈시스템 아키텍처에 맞도록 재구성하는 그림을 볼 수 있다. 메인프레임이 좋은가 오픈시스템이 좋은가 하는 논의는 마이그레이션 비즈니스에서는 언급하는 것이 좋지 않다. 사용자의 환경이 어떠한 아키텍처를 도입하는가에 따라 적용하는 기술이 마이그레이션 기술이다. S카드 사례는 메인프레임 환경에서 오픈시스템 환경으로 전환하는 사례이다. 서버나 데이터베이스 마이그레이션 보다는 매우 까다로운 기술이 도입이 되어야 시스템이 바뀐다는 점이다.

왜 마이그레이션을 도입하였는가
첫째, 비용절감을 위해서다.
금융위기로 시작된 경제한파는 대기업을 중심으로 비용절감 전략을 앞세워 차세대시스템 개발에도 절감요인 전략으로 기존 시스템을 재활용하는 전략은 당연한 접근이라 할 수 있겠다.
대부분 시스템 개발은 과거 개발한 내용을 버리고 새로운 시스템 개발만을 추구하던 방법에서 과거 시스템을 철저하게 분석하여 분류된 내용에 맞는 개발방법을 선택하는 방식으로 인해 많은 비용절감 효과와 비즈니스 프로세스 선진화 효과를 얻게 된 것이다.
실제로 S카드는 메인프레임에서 오픈시스템으로 전환하면서 90억 이상의 운용비용 절감효과를 예상하고 있으며, 실제로 서버 교체로 나타나는 비용 절감 효과가 50억 정도로 추정하고 있다. 실제로 이와 같은 효과를 이루기 위해서 반드시 필요한 것은 서버나 기존 시스템을 안전하고 정확하게 이전을 전제로 한다는 점에서 유념할 필요가 있다.

마이그레이션은 과거의 낡은 시스템을 신기술로만 전환하는 것으로 이해하고 있는데 실제로는 시스템 통합의 요인으로 마이그레이션 하는 경우가 많다.
D증권의 아키텍처는 <그림 3>과 같다.

<그림 3> D증권 아키텍처

둘째, 금융사의 자료처리의 생명은 속도이다.
Java가 신기술인 것은 사실이지만, 실제로 Unix 기반에서 C로 작성된 시스템의 성능이 훨씬 뛰어나다는 판단으로 기존에 개발된 java 시스템을 C환경으로 전환하는 방식을 선택하였다. 이는 비용절감이나 신기술의 문제가 아니라 성능을 높이기 위해서 시스템을 마이그레이션 하는 경우이다.
실제로 우리나라는 Java에 대한 불안감은 아직도 가지고 있으며, 특히 금융권을 중심으로 C환경을 주로 검토하고 있으며, 이에 대한 논쟁은 잠시 더 진행이 될 것으로 생각된다.

셋째, 개발기간을 단축하기 위함이다.
H화재는 차세대시스템의 거의 막바지에 달하는 구축단계에 와서 얼마 남지 않은 시스템 구축기간과 거의 소진된 비용으로 많은 어려움을 겪고 있었다. 또한 차세대시스템 구축이라고 하지만 많은 부분은 기존 시스템을 그대로 사용하고 새로운 Java 환경의 시스템을 구축해야 했다. 이 때 비용절감은 물론 ‘개발기간단축’이라는 측면에서 자동으로 마이그레이션 하는 솔루션의 도입이 필요했다.

사례 중심으로의 마이그레이션 전략
마이그레이션 프로젝트는 일반 프로젝트와 동일하지만 진행하는 절차에서는 약간의 차이가 있다.

<그림 4> S카드의 마이그레이션 프로젝트 절차도

<그림 4>는 S카드의 마이그레이션 프로젝트트 처리 절차도이다. 여기서 살펴 볼 수 있는 것은 일반 프로젝트에서의 처리 절차와는 달리, ‘마이그레이션’ 부분이 가장 핵심에 자리를 잡고 프로젝트를 진행하고 있다. 마이그레이션 프로젝트의 목적은 <그림 5>와 같다.

<그림 5> 마이그레이션 프로젝트 목적

업무범위와 기술적 구성도는 <그림 6>과 같다.

<그림 6> 데이터베이스 마이그레이션 업무 범위

S카드 및 D화재의 환경적 요소에서 특이할 점은 데이터베이스와 어플리케이션 프로그램을 동시에 변환하며, 타겟 시스템에서는 어플리케이션 프레임워크에 맞게 마이그레이션하고 있다는 점이다. 또한 데이터베이스도 단순히 SQL만 변환하는 것이 아니라 데이터베이스와 관련된 DB Object, 어플리케이션 프로그램에 해당하는 Pro*c, ESQL C, 등도 포함하여 변환한다는 것이다.

마이그레이션 프로젝트를 진행하는데 있어서 가장 중요한 부분이 있다면 비즈니스 룰을 추출하는 작업을 통해 마이그레이션 방향을 결정한다는 것이다. 

<그림 7>  4가지 형태의 비즈니스 룰

<그림 7>에서처럼 새롭게 개발할 대상에서 이를 분리하여 4가지 형태로 비즈니스 룰을 분리하게 된다.
 재활용 : 비즈니스 룰 전체를 기술적인 변화를 주면서 100% 재사용하는 경우를 말한다. 예를 들면 서버 로직단에 있는 프로그램이나 재사용 가능한 뱃치 프로그램언어가 여기에 해당된다.
 참조용 : 기존 시스템의 프로그램에서 정보를 참조만 하고 신규로 개발하는 경우를 말하는데, 대부분 차세대시스템 개발함에 있어서 재사용하지 않지만, 기존 시스템을 분석하여 참조할 경우에 해당하는 경우이다.
 신규개발용 : 기존 시스템을 참조하지만 재사용하지 않은 경우에 새롭게 개발하는 경우이다.
 삭제용 : 기존시스템도 필요하지 않고, 새롭게 개발할 필요가 없는 경우에 해당한다.
이러한 작업이 위 그림에서 나타난 대로 비즈니스 룰을 분석하는 과정에서 나타난다.

다음은 현행시스템을 마이그레이션 하기 전에 분석하는 과정을 거치게 된다.
분석 작업은 프로그램언어, 데이터베이스 그리고 시스템간의 연결관계 등 다양한 분석작업을 거쳐 작성하게 된다.

D화재 분석 내용은 다음과 같다.
어플리케이션 프로그램에 대한 정확한 현황 분석 그리고 문제점 등을 제시하고 있다.  <그림 8>은  D화재의 분석작업 내용이고 <그림 9>와 <그림 10>은 데이터베이스 분석 내용과 데이터베이스간 내 외부 복잡도 정보를 분석한 자료이다.

<그림 8> D화재 분석내용

<그림 9> 데이터베이스 분석 내용

<그림 10> 프로그램과 데이터베이스간의 내 외부 복잡도 분석 자료

이와 같은 분석은 30여 종의 다양한 분석 자료를 제공하게 된다.

마이그레이션을 어떻게 진행하였는가
마이그레이션 프로젝트는 일반적으로 수작업을 통해 진행할 때는 일반 프로젝트와 진행하는 절차가 동일한데, 메타마이닝에서 처리한 절차는 모든 절차를 자동화 솔루션과 절차를 도입함으로써 개발기간과 정확도 그리고 비용을 대폭 절감하는 효과를 가져왔다.

<그림 11> 마이그레이션 진행 과정

위와 같은 절차를 통해 작업을 하게 되는데, 이를 진행하는 방법론에는 마이그레이션 방법론인 ‘Re-method(v2.0)’를 활용하였다.

<그림 12> 어플리케이션 마이그레이션 절차

앞에서 설명한 바와 같이 마이그레이션 절차와 기존 프로젝트 개발 방법론과 적절하게 혼용하여 사용하면 매우 효과적이다.

끝으로, 다양하고 심층 있는 분석작업을 통해 재사용이 가능한 프로그램언어(데이터베이스 포함)를 자동으로 사용자가 원하는 프로그램언어를 변환하는데, CICS/COBOL을 java 환경으로, Java 환경을 C환경으로, Pro*c 를 C 환경으로 다양한 환경 변환에 따른 결과와 기대효과에 대해 살펴본다.

<그림 13>은 재사용 가능한 비즈니스 로직을 자동변환하는 분석 자료를 나타낸다.
대부분 사례에서 100% 자동 변환이 되지 않으면 안되는 것이 현실이다.

<그림 13> 자동변환 분석자료 제공의 예

첫째, 그 동안 메타마이닝은 이러한 마이그레이션 프로젝트를 수 많은 프로젝트를 통해 성공함으로써 이를 입증한다는 점이다. 만일 일반인의 궁금을 해결하지 못하였다면, 이러한 성공 사례를 갖지 못했을 것입니다.
둘째, 성능이나, 소스코드 가독율은 다음과 같이 설명할 수 있을 것이다. Java, C#, C, COBOL 등 다양한 어플리케이션 아키텍처에는 반드시 사용자가 보유하고 있는 표준화되고 정형화된 그리고 검증된 프레임워크를 보유하거나 메타마이닝에서 이를 제공하여 해당 프레임워크에 맞게 마이그레이션을 하기 때문에 사용자의 기술적 문제점은 거의 해결이 되는 셈이다. <그림 14>는 그러한 관점에서 100% 자동 변환을 지향한다는 의미를 나타내고 있다.

셋째, 자동변환 솔루션을 통해 변환된 이후에 솔루션과 독립적으로 사용자에게 모든 권한을 넘겨준다.
대부분 자동화 도구는 자사에 맞는 런타임 라이브러리를 제공함으로 공급자에게 의존토록 하는데, 100% 사용자가 원하는 소스코드를 제공받기 때문에 완벽한 마이그레이션에 대한 기술검증이라 할 수 있을 것이다.

넷째, 사용자는 변환 이전과 이후의 소스코드를 비교하여 열람하여 의문점을 해결하고 나아가 시스템의 이해도를 매우 높여 준다.

<그림 14> 소스코드 변환의 예

<그림 14> 왼편에 나타난 소스코드가 변환 이전의 소스코드이며, 오른쪽이 변환 후의 소소코드 그림이다. 대부분 마이그레이션 프로젝트를 수행한 사용자들은 위 기능을 가장 선호하여 사용하고 있다. 자신이 지금까지 개발한 소스코드를 비교하여 이해와 변환에 대한 사후 검증을 하기 위함이다.

<그림 15> 프로젝트 분석결과

<그림 15>은 마이그레이션 프로젝트를 진행하면서 얻는 분석결과인데, 사용자의 소스코드를 수집하여 자동으로 변환하게 되면 오류가 발생하게 된다. 오류의 원인을 분석해 가면서 사용자와 이를 추적하여 해결해 가는 과정을 거치게 되는데, 긍극적으로는 100%에 도달 할 때 까지 반복적인 작업을 수행하게 된다. 대부분 오류에는 사용자 자료 누락, 표준화를 벗어나거나 프로그램언어 문법적 오류 등이 여기에 해당된다.

지금까지 도입사례를 통하여 사용자들은 어떠한 기대효과를 얻었는지에 대해 알아보자. 
정성적 기대효과와 정략적 기대효과는 각각 <그림 16>, <그림 17>과 같다.

<그림 16> 정성적 기대효과

<그림 17> 정량적 기대효과

지금까지 금융권의 사례를 중심으로 성공사례를 살펴보았는데, 구체적인 사례와 데이터를 100% 공개하지 못함을 이해하기를 바라며, 상세한 내용은 필자에게 문의하면 자세하게 설명하겠다.