금융 서비스 산업의 메인프레임 기반 디지털 전환

이 콘텐츠는 메인프레임 현대화에 대한 5부작 시리즈 중 1부입니다.

앞선 내용에서 메인프레임 현대화가 금융 산업만의 과제가 아니라는 점을 다뤘으니, 이제 본격적으로 가장 중요한 문제를 이야기해 볼 때입니다. 전 세계에서 가장 큰 현대화 과제들은 은행 산업에 집중되어 있습니다.

인터넷과 클라우드 컴퓨팅이 등장하기 전, 그리고 스마트폰과 모바일 앱이 등장하기 전에는 은행들이 대규모 전자 결제 게이트웨이를 통해 결제를 처리하고 메인프레임을 기록 시스템으로 운영했습니다.

금융 서비스 기업은 글로벌 경제 시스템의 핵심 측면을 관리하고 움직이기 때문에 기관으로 간주됩니다. 그리고 금융 기관의 심장은 IBM 메인프레임입니다.

은행은 메인프레임 애플리케이션과 데이터 자산을 클라우드와 같은 최신 표준의 유연성, 민첩성, 혁신으로 끌어올려 고객 수요를 충족하는 데 성공하면 가장 큰 이익을 얻을 수 있고, 실패할 경우 가장 큰 손실을 볼 수 있습니다.

우리는 최근 기억만 돌이켜보아도, 2008년 ‘대마불사(too big to fail)’ 금융위기부터 팬데믹 이후의 고금리로 인해 일부 대형 예치은행이 과도한 위험 노출과 지급불능 상태에 빠지는 상황에 이르기까지 전 세계적인 경제 불확실성을 겪어 왔습니다.

은행의 실패는 잘못된 경영 결정과 정책의 결과인 경우가 많지만, 현대화 이니셔티브와 전략의 지연에도 일부 책임이 있을 수 있습니다. 경영진이 데이터 내에서 위험을 발견하기 위해 더 나은 분석을 실행할 수는 없었을까요? 새로운 모바일 앱을 출시하지 못한 이유는 무엇일까요? 누군가 해킹을 해서 고객을 차단한 것은 아닌가요?

모두가 메인프레임 애플리케이션 현대화를 미루면 기회 비용이 발생한다는 것을 알고 있지만, 현재 운영을 지원하고 있는 시스템을 변경하는 것은 위험하다는 믿음이 있습니다.

커뮤니티 및 지역 은행은 기술 리소스가 부족할 수 있는 반면, 대형 기관은 과도한 기술 부채, 심각한 데이터 이동 문제, 비즈니스 사례의 어려움에 직면해 있습니다.

크고 작은 은행은 모두 하나 이상의 현대화 또는 마이그레이션 이니셔티브에 실패했을 가능성이 높습니다. 이러한 노력들이 무산되면서 해당 조직의 IT 리더들은 자신이 감당할 수 있는 것보다 더 많은 것을 빼앗아 가고 있다고 느꼈습니다.

현대화 노력을 혁신하는 데 메인프레임 코드를 전면적으로 다시 작성하거나, 번거롭고 비용이 많이 드는 리프트 앤 시프트 작업을 수행해서는 안 됩니다. 대신, 팀은 비즈니스의 가장 중요한 우선순위에 적합한 것을 현대화해야 합니다.

고도로 분산된 소프트웨어 아키텍처와 오늘날의 높은 고객 경험 기대치라는 맥락에서 단순히 현대화 이니셔티브를 다시 시작하는 것을 넘어 메인프레임의 가치를 크게 개선한 은행의 몇 가지 훌륭한 사용 사례를 소개합니다.

많은 은행은 분산 시스템이 등장하기 전에 COBOL 또는 다른 언어로 작성되었을 수 있는 기존 메인프레임 코드 내에서 기술 부채를 해결하는 것을 두려워합니다. 원래 시스템을 설계한 엔지니어가 더 이상 존재하지 않는 경우가 많고, 비즈니스 중단은 좋은 선택이 아니기 때문에 IT 의사 결정권자는 중간 계층에서 땜질식 처방으로 혁신을 지연시킵니다.

Atruvia AG는 세계 최고의 뱅킹 서비스 기술 공급업체 중 하나입니다. 800개 이상의 은행이 4개의 데이터 센터에서 운영되는 8개의 IBM z15 시스템에서 지원되는 혁신적인 서비스를 통해 연간 약 1,000억 건의 거래를 처리하고 있습니다.

이 은행은 전면적인 교체 대신 메인프레임에서 실행되는 기존 COBOL과 함께 Java로 RESTful 서비스를 작성하는 리팩터링을 결정했습니다. 핵심 뱅킹 트랜잭션의 85%를 최신 Java로 점진적으로 교체함으로써 은행 고객을 위한 새로운 기능을 구축하는 동시에 메인프레임의 워크로드 성능을 3배 향상할 수 있었습니다.

대부분의 은행은 데이터 센터에 있는 운영 메인프레임의 기본 복사본과 몇 달마다 새로운 배치 업로드를 수행하는 오프사이트 보조 백업 또는 가상 테이프 솔루션과 같은 재해 복구(DR)를 위한 이중화를 포함하는 데이터 보호 계획을 가지고 있습니다.

데이터 볼륨이 거래량 증가와 애플리케이션 엔드포인트 확대로 계속해서 커짐에 따라, 레거시 백업 기술로 데이터를 복제하는 작업은 비용과 시간이 점점 더 많이 들게 됩니다. 또한 이를 다시 복구하는 과정도 느려서, 복구 시간 동안 재해 복구(DR) 공백이 발생할 수 있습니다. 현대 은행의 컴퓨팅 환경을 안전하게 보호하기 위해서는, 랜섬웨어를 포함한 위협에 대비해 보다 신속한 백업과 복구가 필수적입니다.

호주 상위 5대 은행인 ANZ는 850만 명 이상의 고객에게 높은 가용성을 보장하기 위해 메인프레임 백업을 더 신속하게 수행하고 재해 복구(DR) 성능을 더욱 향상시키는 역량을 확보하고자 했습니다.

ANZ는 사이트 간 복원력 환경을 구축해, HyperSwap 기능을 활용한 IBM zSystems 미러 서버를 운영했습니다. 이를 통해 서비스 중단 없이 멀티 타겟 스토리지 전환이 가능해졌으며, 동일한 서버 중 하나가 백업 또는 복구 작업을 수행하더라도 다른 서버가 즉시 운영 워크로드를 이어받을 수 있게 되었습니다.

ANZ의 IT 리더십은 향상된 시스템 가용성 덕분에 한층 더 안정성을 확보했습니다. 하지만 그보다 중요한 점은, 이제 고객에게 비즈니스 연속성을 제공할 수 있음을 인증받을 수준의 현대적 재해 복구 체계를 갖추게 되었다는 것입니다.

은행은 고객 만족도, 재무 성과, 인프라 투자 및 위험 관리에 영향을 미치는 주요 비즈니스 의사 결정의 거의 모든 측면에서 고급 분석을 활용합니다.

메인프레임의 방대한 데이터 세트에 대한 복잡한 분석 쿼리는 컴퓨팅 예산을 소모하고 실행하는 데 몇 시간 또는 며칠이 걸릴 수 있습니다. 데이터를 클라우드 데이터 웨어하우스와 같은 다른 곳으로 옮기면 전송 지연이 더욱 심해질 수 있으며, 이로 인해 데이터가 오래되고 의사 결정의 품질이 저하될 수 있습니다.

터키에서 두 번째로 큰 은행인 Garanti BBVA는 메인프레임 CPU 소비를 줄이면서 쿼리 워크로드를 가속화하는 IBM Db2 Analytics Accelerator for z/OS를 배포했습니다.

메인프레임 운영 환경의 우려와 비용으로부터 분석 워크로드를 분리한 덕분에 Garanti는 매일 밤 300개 이상의 분석 배치 작업을 실행할 수 있게 되었으며, 이전에는 이틀이 걸리던 규정 준수 보고서를 이제 1분 만에 실행할 수 있게 되었습니다.

은행들은 고객에게 혁신적인 신규 애플리케이션과 서비스 제공을 통해 경쟁하기 때문에, 애자일 개발 테스트 팀은 끊임없이 새로운 소프트웨어 기능을 추가하고 있습니다. 우리는 이를 흔히 스마트폰 앱의 프런트엔드 개선이나 클라우드 서비스와의 API 기반 통합 정도로 일반화해서 생각하곤 합니다.

하지만 잠깐만요. 이러한 신규 기능 대부분은 결국 메인프레임을 거치게 됩니다. 그렇다면 메인프레임 팀을 DevOps 체계의 일급 참여자로 끌어와 처음부터 함께할 수 있도록 하면 어떨까요?

Danske Bank는 약 1,000명에 달하는 내부 메인프레임 개발자를 기업 전체의 DevOps 전환 흐름에 참여시키기로 결정했습니다. 이를 위해 IBM Application Delivery Foundation for z/OS(ADFz)를 기능 개발, 디버깅, 테스트, 릴리스 관리를 위한 플랫폼으로 활용했습니다.

기존 COBOL 및 PL/1 코드 역시 CI/CD 관리 파이프라인에 그대로 가져와 개발자들의 IDE에서 직관적으로 열어 수정할 수 있었습니다. 더 이상 그린스크린과 씨름할 필요가 없었습니다. Danske Bank는 이제 예전보다 절반 수준의 시간 내에 제품 및 서비스를 시장에 출시할 수 있습니다.

Danske Bank 사례 연구 읽기 https://www.ibm.com/kr-ko/case-studies/danske_bank_as

최근에 등장한 ‘클라우드 기반’ 핀테크 기업들 역시, 자사 혁신이 끊임없이 변화하는 거래 상대방의 하이브리드 컴퓨팅 환경과 어떻게 상호작용해야 하는지 고려하는 것이 바람직합니다.

모바일 앱에서 이뤄진 거래는 결국 글로벌 결제 네트워크, 규제 기관, 다른 은행 등으로 이어지며, 각 주체는 요청을 처리하기 위해 자체 메인프레임 컴퓨팅 및 스토리지 리소스를 보유하고 있습니다.

은행마다 상황이 모두 다르고, 메인프레임 애플리케이션 현대화 여정에서 선택할 수 있는 변화의 방식도 매우 다양하기 때문에, 앞으로 나아가는 데 단 하나의 경로만 존재하지는 않습니다.

IT 리더들은 어딘가에서 시작해, 메인프레임이 속하게 될 고유한 애플리케이션 환경의 아키텍처와 비즈니스 요구 사항에 가장 잘 맞는 사용 사례를 선택해야 합니다.

자세한 내용은 이 시리즈의 다른 글을 참조하세요.

• 1부: "뱅킹을 넘어선 메인프레임 애플리케이션 현대화"
• 2부: "마이그레이션이 아닌 협업을 통해 메인프레임 애플리케이션을 클라우드로 현대화하기"
• 4부: "메인프레임과 클라우드? 오픈소스로 쉽게 해결하세요"