“메인프레임은 최고급 기술과 운용 관리 체제를 계속 유지하고 있는 시스템”
레거시에서 다른 플랫폼으로 이행을 고려하는 경우에는 우선 현재 운용중인 레거시 시스템에서 어느 정도의 문제가 발생하고 있는지를 정확히 파악하고, 이행해야 할 필연성이 있는지 여부를 검토해야 한다.
최근 우리는 여기저기서 사용되고 있는 '차세대(次世代)'라는 낱말에 매우 익숙해져 있어 여러 분야에서 거의 고정적인 접두어로 사용되고 있는 느낌이다. 차세대 휴대폰, 차세대 디지털 카메라, 차세대 전투기, 차세대 전자정부 IT …, 차세대 웹 통합 … 등에서 볼 수 있다. IT와 관련하여 '차세대'가 사용되는 의미는 "현재 사용중인 업무가 아닌 새로운 업무 시스템"으로 규정 지을 수 있을 것이다.
그렇다면 '차세대'의 사전적인 의미는 어떠한 것인가? '차세대' - "지금 세대가 지난 다음 세대"라고 되어 있으며, '세대'란 "어린아이가 성장하여 부모 일을 계승할 때까지의 약 30년 정도 되는 기간. 대(代)"라고 되어 있다. 결국 차세대가 갖는 내면적인 시간의 길이는 약 30년이라고 보아야 할 것이며 이 용어를 사용하는 것이 과연 타당한 것인가 하는 의문이 든다.
이번 호에서는 차세대 시스템과 플랫폼 선정이라는 주제를 가지고 정보 시스템 또는 전략 정보 기획 부서에서 차세대에 대하여 어떻게 대응하여야 하는지를 살펴보고자 한다.
차세대(Next Generation)와 레거시(Legacy)
우리나라 IT 관련 업계에서는 차세대와 레거시라는 단어를 반대말의 개념으로 사용하는 것을 흔히 볼 수 있다. 즉, "차세대는 새로운 것이고, 레거시는 오래된 유물과 같은 것이다"라는 얘기가 바로 그것이다.
레거시(Legacy)라는 말은, '유산', '전 세대부터 계승되어 온 것'이라는 의미를 지니고 있다. 하지만 정보시스템의 세계에서는 레거시 시스템을 '개발기간이 끝나 보수단계에 들어간 시스템을 가리키는 것'이라는 부정적인 이미지로 바뀌었다. '레거시 시스템'이란 "기업 내에서 오랫동안 사용해 왔으며, 지금은 노쇠화해 무엇인가 문제를 안고 있는 플랫폼이나 애플리케이션"을 의미한다고 정의할 수 있다.
우리나라 IT업계에서 레거시 시스템과 메인프레임 시스템이 마치 동의어인 것처럼 사용되고 있는 경우가 종종 있다. 이것은 매우 그릇된 인식이다. 왜냐하면 모든 메인프레임이나 또는 메인프레임에서 가동되고 있는 애플리케이션이 노쇠화로 인해 문제를 일으키고 있는 것이 아니기 때문이다. 실제로 메인프레임은 1964년 4월 처음 발표된 이래 오늘날까지 컴퓨팅 시스템의 모든 신기술을 선도하고 있는 위치에서 흔들림이 없었다. 가상화 기술, 워크로드 관리, 결코 해킹이 되지 않는 완벽한 보안을 위한 하드웨어 Built-in 기능 등 메인프레임에서 최초로 구현된 후에 하이엔드 유닉스 서버 또는 윈도우 서버로 일부 기술이 이전된 점은 이런 주장을 뒷받침하고 있다.
많은 사람들이 알고 있듯이, 메인프레임 시장을 이끌고 있는 것은 과거나 지금이나 IBM이다. IBM은 44년에 걸쳐 메인프레임 제품에 최신 기술을 도입하고 성능과 기능을 계속 강화해 왔다. 2006년도 포춘지가 선정한 전세계 500대 기업에 포함된 57개 은행의 플랫폼 사용 현황을 보면 56개의 은행이 메인프레임을 사용하고 있다. 또한 IDC에서 발표한 2006년 3분기까지의 서버시장 동향을 보면 메인프레임이 다른 어떠한 플랫폼보다 압도적인 성장세를 보이고 있다 .<그림1>
'메인프레임 = 레거시' 라고 하는 오해
<그림1>의 내용을 보면 "아직도 메인프레임을 사용하고 있는 것은 소수 기업뿐이며, 오픈시스템으로의 이행이 끝나가고 있다"라는 주장은 정확한 사실이 아니라는 것을 알 수 있다.
IBM은 2003년에 고객에게 드리는 IBM의 약속으로서 메인프레임 고객들에게 '기술혁신에 따른 신기술의 신속한 제품화, 가치의 공유화 및 메인프레임 커뮤니티의 활성화'를 의미하는 <메인프레임 헌장>을 발표하였으며 이에 기반을 두고 하드웨어 및 자바, 리눅스, SOA (Service Oriented Architecture) 등 업계 표준을 수용하는 신기능들을 개발하여 이미 상용화하였다. 또 전세계 300여개 대학에 메인프레임 과정을 개설하여 기술 인력 양성을 지원하고 있으며, 1,500여개의 메인프레임 솔루션 파트너와 함께 새로운 솔루션을 지속적으로 내놓고 있다. 국내에서도 대학 정규 과정을 개설하여 기술 인력 양성을 활발하게 지원하고 있다.
후지쯔, NEC, 히다찌 등 메인프레임을 추구해온 일본 메인프레임 제조사들 역시 최신 인텔 프로세서를 채용하는 등 고객의 메인프레임 애플리케이션 자산을 보호하는 전략을 취하고 있으며, 정보 시스템 기반으로서의 메인프레임에 적극적인 투자를 아끼지 않고 있다. 대규모의 미션 크리티컬한 애플리케이션을 가동시킬 경우, 메인프레임이 가장 신뢰할 수 있는 플랫폼이라는 점은 많은 사용자가 동의하는 부분이다.
역으로 "노쇠화로 인해 문제가 발생하고 있는 시스템"이라는 관점에서 볼 때 메인프레임 보다도 지원 기간이 끝난 낡은 레벨의 유닉스 운영체제를 가동하는 컴퓨터나 지금은 거의 사용되지 않는 4GL 애플리케이션, 그리고 클라이언트 서버형이면서 프로그램 구조가 너무 복잡해서 손을 댈 수 없는 시스템 등이 문제를 발생시키는 경우가 많다. 이러한 의미에서 이들 시스템이야말로 레거시 시스템이라고 할 수 있을 것이다. 아무리 최신기술을 채용한 시스템이라 해도 적절한 요건 분석이나 문서화 없이 임시 방편의 땜질 공사식으로 만들어가면 매우 비효율적인 레거시 시스템이 되어 버리는 것이다.
물론, 과거에 개발된 메인프레임 시스템 중에는 노쇠화에 따른 문제를 안고 있는 것도 있을 것이다. 그렇기 때문에 '메인프레임 -> 레거시 -> 비호의적 -> 즉각 교체대상'이라는 방식의 단편적인 생각은 기업의 기 투자된 부분을 포함하여 막대한 비용의 낭비를 의미하는 것이므로 피해야 할 것이다.
'레거시'가 문제가 아니라
'문제가 발생하고 있는 레거시'가 문제
최근 국내의 많은 기업들에게 레거시 이행이 중요한 화두로 자리잡고 있다. 복잡하고 다양하게 변화하는 업무 지원 기능을 보강하고 정보 시스템의 비용 절감이 지상 최대 과제가 되어 있는 상황에서 이것은 당연한 현상이라고 할 수 있다. 그렇다고 해서 레거시 시스템이 장기간 가동되고 있는 것 자체가 문제가 될 수는 없다는 점에 주의해야 할 필요가 있다. 장기간 가동하며, 기술적으로 노쇠화가 눈에 띄는 시스템일지라도 기업의 업무요건을 만족시키고 있다면 막대한 투자로 이행을 할 필요는 없기 때문이다.
레거시에서 다른 플랫폼으로 이행을 고려하는 경우에는 우선 현재 운용중인 레거시 시스템에서 어느 정도의 문제가 발생하고 있는지를 정확히 파악하고, 이행해야 할 필연성이 있는지 여부를 검토해야 한다. 문제를 일으키는 원인이 레거시 플랫폼에 있는 것인지 아니면, 레거시 애플리케이션에 있는지를 명확히 구별하는 것이 중요하다. 결국, 문제의 근본적인 원인이 하드웨어나 시스템 소프트웨어의 노쇠화에 있는 것인지, 그렇지 않으면 애플리케이션의 노쇠화에 있는 것인지를 따져보라는 것이다. 물론 회사에 따라서는 양 쪽 모두가 문제의 원인이 있는 경우도 많이 있을 것이다.
문제의 원인을 파악하면, 전혀 의미가 없는 이행 프로젝트를 수행하는 일은 필요없게 된다. 예를 들어 프로그램의 설계가 낙후되어 업무 요건에 맞지 않는 문제를 안고 있는 메인프레임 시스템의 경우 애플리케이션에는 손을 대지 않고 플랫폼만을 유닉스 서버로 이행하면 어떤 문제도 해결되지 않고 단순히 이행에 필요한 비용만 낭비하는 결과를 초래할 수 있다.
레거시의 이행 과정, 무엇이 문제인가?
이번에는 프로그램의 설계가 낙후되어 업무 요건에 맞지 않은 문제가 있다고 판단되어 레거시 업무의 이행을 하기로 결정하는 단계는 어떠한 것인지를 알아 보자.
노쇠화된 애플리케이션을 버리고 새로운 업무 시스템의 개발- 우리는 흔히 이를 차세대 프로젝트라고 하므로 이를 그대로 사용한다- 즉 차세대 업무 시스템의 개발을 위한 단계가 한가지 방식으로만 정해져 있는 것은 아니다. 새로 요구되는 업무 요건을 분석하고, 솔루션을 결정하고, 이 솔루션에 가장 적합하며 회사의 미션 크리티컬한 기간계 업무 수행 요건을 만족시키는 최적의 플랫폼을 선정하는 것이 바람직하다. 하지만 솔루션의 검토 없이 플랫폼을 먼저 결정하는 경우도 있다. 이러한 경우 단순한 가정에 의거하여 결론을 도출할 수 밖에 없으므로 회사에 중대한 위험을 초래할 수 있다.
<그림 2>에 나타난 7번 단계에서 이루어진 비용 분석은 매우 어렵고 복잡한 일이다. 비용 절감이라는 목표를 달성하기 위하여 메인프레임에서 유닉스로 이행한다는 논리는 그럴 듯 하지만 그 속을 들여다 보면 결코 그렇지 않다는 것을 알 수 있다. 다시 말해 비용 분석을 하면서 기기의 일시적인 구매 비용과 소프트웨어 사용료 및 유지/정비 비용을 위주로 하는 단순한 구매용의 분석 - TCA (Total Cost of Acquisition) - 으로는 충분하지 않으며 장애나 재해시 발생하는 기회비용의 분석을 포함한 총 소유비용 - TCO (Total Cost of Ownership) - 과 투자 효과 분석 (ROI-Return on Investment)이 진정한 의미의 비용분석이라고 할 수 있기 때문이다.
몇 년전 미국에서 일어난 9.11 사건 이후 국내에서도 재해복구 시스템을 앞다투어 구축하여 운영을 하고 있지만 장애 또는 재해로 발생되는 기회 비용에 대한 분석 없이 솔루션을 선정하고 재해 복구 시스템을 구축하였다. 다양한 재해 복구 솔루션을 선정할 때 정확한 분석 없이 결정하는 것은 결국 비용의 낭비를 초래한다는 것을 의미한다. 몇 년이 지난 현재 많은 기업들은 수년간의 운영 경험을 통해 필자와 비슷한 의견을 가지고 있을 것이다.
여기서 한가지 질문을 던지고자 한다. 우리 회사에 1시간의 서비스 중단 사태가 발생하였을 경우 손실 비용이 어느 정도 될까? 손실 비용에 대한 분석이 있을 때 최적의 재해 복구 솔루션을 결정할 수 있으며, 차세대 업무 시스템의 플랫폼의 결정이 가능하다.
메인프레임은 전성기가 끝나고 현재에는 시대에 뒤쳐진 시스템의 대표적인 존재라는 의미로 '레거시', '화석', '공룡'이라고 말하기도 한다. 그렇지만, 단순히 오래되어 비실용적인 시스템이라면 시장 논리로 볼 때 저절로 도태되어 그 존재가 이미 사라졌을 것이다. 결국 메인프레임을 질시하는 소리가 높은 것은 그 만큼 메인프레임이 강력한 존재이기 때문이기도 하다. 지금부터는 메인프레임의 가치에 대하여 알아 보고자 한다.
클러스터 구성으로 99.999% 가용성 실현
앞에서 설명한 것과 같이 메인프레임의 기술은 '레거시'가 아니다. 최신의 메인프레임은 최첨단 테크놀러지로 이루어진 시스템으로 기술개발의 성과를 압축하여 갖고 있다. 원래 메인프레임에는 '레거시' 즉, 좋은 의미의 '레거시'라고 불려도 이상하지 않을 부분도 포함되어 있다. 그것은 하드웨어 기술이 아니라 운용 관리 체제 부분이다.
메인프레임을 유닉스와 비교할 때 가장 먼저 떠오르는 것이 바로 신뢰성이다. 메인프레임의 가용성의 우위를 나타낼 때 종종 'Five Nine'라는 수치가 이용되는데, 99.999%의 가용성이란, 1년 365일중 99.999%의 시간 동안 운용이 계속될 수 있다는 것을 의미한다. 이것을 실제 시간으로 따지면 1년간 허락되는 다운타임이 5분 15초 정도가 된다. 물론 이것은 공식적으로 보증되어 있는 수치가 아니다. 유닉스 계열 서버 공급업체들이 '메인프레임급 신뢰성'을 걸고 넘어지는 경우에 드는 수치이다. 하지만 이는 메인프레임의 신뢰성이 어느 정도인지를 알 수 있는 참고자료가 될 것이다.
다운타임을 연간 5분 정도로 억제하기 위해서는 대단한 운용관리 체제가 필수 불가결하며 하드웨어 및 소프트웨어에 대한 통합적인 품질 관리 체제가 갖춰져야 한다. 이 때문에 IBM도 메인프레임 단독으로 99.999%의 가용성을 실현할 수 있다고는 공언하지 않고 있다. 즉, Five Nine의 가용성을 실현하기 위해서는 IBM이 말하는 대로 '병렬 시스플렉스(Parallel Sysplex)', 즉 클러스터 구성이 전제가 된다. 만약 1대의 컴퓨터에 문제가 발생하더라도 다른 컴퓨터가 업무를 계속 담당하여 시스템 전체가 다운되는 것을 막는 것이 가능하도록 하여 다운타임을 연간 5분 정도로 억제할 수 있는 것이다.
그렇다고, 어느 시스템이든 클러스터로 구성하면 분한 신뢰성을 확보할 수 있다는 것은 아니다. 클러스터 구성이라면 유닉스 서버에서도 가능하고 IA/윈도우 서버에서도 마찬가지다. 그렇지만, 신뢰성의 확보는 단순하게 테크놀러지만으로 풀 수 있는 문제는 아니다. 여기에는 다양한 요소에 통합적인 체계, 최종적으로는 장해나 불안요소를 하나씩 찾아서 제거해 가는 인적 지원을 포함한 고도의 작업이 필요하다.
결국 신뢰성에 정평이 있는 IBM 메인프레임의 경우 이러한 체계를 갖추고 운영되고 있다.
용도에서 입증되는 메인프레임의 신뢰성
다음으로 용도면에서 메인프레임의 신뢰성이 어떠한 형태로 발휘되고 있는 지를 살펴보기로 한다. 메인프레임을 주력 제품의 하나로 계속 유지하고 있는 IBM도 결코 메인프레임을 절대적으로 보고 있는 것은 아니다. 용도에 따라 메인프레임과 유닉스 서버를 나누어 사용하는 것을 생각하는 것이다. 현재 메인프레임은 주로 기간계 서버나 서버 통합용 플랫폼으로서 이용되고 있다.
전자는 메인프레임에서 실행되어 온 업무 애플리케이션을 그대로 계속하여 이용하는 경우이다. 예를 들어, 은행이나 증권 등 금융기관의 온라인 시스템은 현재에도 메인프레임상에서 가동하는 것이 대부분이다. 물론 유닉스 계열 서버만으로 업무 시스템을 구축하고 있는 회사도 있듯이 "금융기관은 모두 메인프레임을 사용하여 고신뢰성을 실현하고 있다"라고 말할 수도 없다. 하지만, 현시점에서 대표적인 메인프레임 사용자가 시스템의 높은 신뢰성을 추구하는 금융기관인 것은 확실하다.
또한, 과거 시스템 자산의 계승도 메인프레임의 이용을 계속하는 목적중의 하나이다. 유닉스 계열 서버로 이행하게 되면 오랜 세월에 걸쳐 개량을 거듭해 온 다수의 업무 애플리케이션을 모두 재구축하지 않으면 안되며 이에는 막대한 공수와 비용이 필요하게 된다. 장기적인 안목으로 보면 이행 비용은 회수가 가능한 비용이기는 하여도 이행에 착수할 지 말지는 경영상의 판단이 필요하다.
한편, 후자는 최근 주목을 받고 있는 용도이다. 앞에서 서술한 것처럼 메인프레임은 파티셔닝 기능으로 서버를 분할하여 각각의 구획 별로 운용할 수 있다. System z에서는 구획상에 실행가능한 OS로서 리눅스를 지원하고 있으며 유닉스 계열 서버에서 실행되고 있는 업무를 리눅스 구획으로 흡수하여 실행하는 것이 가능하다.
유닉스 계열의 서버에 의하여 구축된 시스템의 약점 중 하나는 시간이 갈수록 서버의 대수가 늘어난다는 점과 이에 따른 관리 부담의 증가이다. 또한, 일반적으로 시스템 전체의 신뢰성도 메인프레임에는 미치지 못하여 장애 발생 빈도 또한 높아진다. 서버의 대수가 많으면 많을수록 시스템 다운에 대응하기 위한 인력부하도 증가한다. 이에 반해, 메인프레임상에서 리눅스를 실행하여 유닉스 계열 서버와 동일한 처리를 하는 경우 소프트웨어 부분의 신뢰성은 유닉스 계열 서버와 별반 다르지 않다. 그러나 하드웨어에 기인하는 문제의 감소를 기대할 수 있으며, 문제 발생시에 더욱 상세한 원인 규명을 할 수 있다. 이 점이 바로 메인프레임의 커다란 장점이다. 또한 완벽한 관리 체제하에 있는 메인프레임상에 모든 처리를 집약함으로서 관리 대상 서버 수를 줄이고, 운용관리 부담을 경감할 수 있다는 점도 간과할 수 없는 매력이다.
신뢰성 확보 방법- 풍부한 툴과 세밀한 지원 필요
그러면 운용 관리 면에서는 어떠한 방법으로 신뢰성을 확보하는 것일까. PC나 유닉스 서버의 경우 문제가 발생하여도 재부팅하여(컴퓨터를 껐다 켜는 것) 장애가 재발하지만 않으면 된다는 경향이 강하다. 이런 경우 벤더에는 문제가 생겼다는 일조차 보고되지 않고 문제의 원인을 추구하는 것도 곤란하게 된다.
한편, 메인프레임의 판매 형태는 팔고 나서 그걸로 끝이라는 모델이 아니라 리스 계약이나 장기계약이 기본적이다. 이 때문에 보수계약에 근거한 IBM으로부터 전면적인 지원을 받는 것이 전제가 되어 있으며, 이 운용 체제하에서 문제가 발생한 경우 문제의 해결을 책임지는 것이다.
이러한 차이점은 비즈니스 모델의 차이에 의해 만들어진 것으로 볼 수 있다. 대량 판매하는 서버의 경우, 사용 상황에 따라 상세한 트러블 슈팅을 하려고 하면 이에 상응한 대가가 따르기 마련이다. 결국 이용 상황에 따른 상세한 지원은 메인프레임에서 비로소 가능한 것이다. 물론 운용 관리에 관한 기술의 차이도 당연히 있다. 메인프레임에서는 상세한 로그 기능이나 트레이스 기능 등 트러블 대응을 위한 기능들이 충실하므로 유닉스 계열 서버와 비교해 매우 상세한 정보를 입수할 수 있다. 이러한 차이가 고도의 트러블 대응을 가능하게 한다. 트러블의 원인이 부품 고장 등 명확한 경우는 물론 소프트웨어와 관련된 복합적인 문제의 경우에는 트러블 발생시의 시스템 상황에 연관된 요소가 늘어나면서 수집해야 할 정보량은 막대해진다. 따라서 유닉스 계열 서버에서도 메인프레임에 준한 트러블 대응기능이 구비되어 있지만 다양한 공급자가 제공하는 부품으로 구성된 유닉스 계열 서버가 메인프레임 수준에 도달하는 것은 불가능할 것으로 예상된다.
맺음말
이상과 같은 상황을 종합해서, 현시점에서 메인프레임은 극히 높은 수준의 신뢰성과 처리 능력이 필요한 기간계 업무에 적합하다고 할 수 있다. 그러나 이렇게 "최고 수준의 시스템을 운용한다"라는 컴퓨팅 모델은 컴퓨터를 이용하는 것 자체가 최첨단 기술이었던 시대에는 당연하였을지 모르지만 컴퓨터가 어플라이언스화되고 있는 현실에서 모든 업무에 전면적으로 적용하여야 한다고 주장하는 것은 아니다.
이 차이는, 스페이스 셔틀과 여객기의 예를 들면 이해하기 쉽다. 스페이스 셔틀을 운용하고 있는 NASA에는 전세계에서 최고 수준의 인재가 수 천명 또는 수 만명 규모로 모여 있다. 한편 민간항공회사에 고도의 전문지식을 갖는 인재가 많다고 해도 그 수준은 NASA에 비교할 만한 것은 아니다. 또, 여객기의 운용에는 스페이스 셔틀에 준하는 기술, 운용 관리 체제까지는 필요하지 않다. 일반적으로 시스템이 기술적으로 보편화되어 가는 중에 운용 관리 체제도 동일한 변화를 겪지만 메인프레임은 이러한 변화를 받지 않고 최고급의 기술과 운용 관리 체제를 계속 유지하고 있는 시스템인 것이다.
다음호에서는 차세대 프로젝트와 IT 업계의 화두로 떠오르고 있는 SOA (Service Oriented Architecture - 서비스 지향 아키텍처)에 대하여 알아 보고자 한다.
참고자료 : IBM Japan 및 GBS Korea Technical White Paper