들어가며
금융권 IT 현대화는 이제 선택이 아닌 필수가 되었습니다. 특히 메인프레임에서 x86-리눅스 플랫폼으로의 전환은 많은 은행들이 고민하고 있는 핵심 과제입니다. 하지만 현실은 녹록지 않습니다. 이론상으로는 분명한 장점들이 있음에도 불구하고, 실제 구현 과정에서는 예상치 못한 벽에 부딪히곤 합니다.
메인프레임이 빠른데 왜 현대화가 필요할까?
1. 천문학적인 유지보수 비용
메인프레임의 가장 큰 문제점은 비용입니다. 보통 은행에서 사용하는 메인프레임의 도입 비용은 기본적으로 수천억 원을 상회한다. 규모에 따라 조 단위로 올라가기도 한다. 여기에 유지 보수 비용이 더욱 많이 드는 지경이라, 한국에서는 금융권에서조차 기기 수명을 다 한 메인프레임 장비 교체를 망설이는 현실이다.
실제 사례를 보면:
- 국민은행: 메인프레임 유지·보수를 위해 매달 90억원을 지출하는 상황
- 비용 차이: 메인프레임을 기반으로 하는 경우와 리눅스를 사용하는 경우는 비용에서 약 여덟 배까지도 차이가 남
- 2020년대 기준: 유지 보수 비용은 연간 1코어 당 40-45억원 가량
2. COBOL 개발자 부족과 기술 인력 고령화
메인프레임의 두 번째 큰 문제는 인력 문제입니다.
COBOL 개발자의 멸종 위기:
- 숙련된 코볼 프로그래머가 은퇴하고 인기가 시들어가면서 프로그램들은 새로운 플랫폼으로 이관돼 현대의 언어로 다시 작성되거나 소프트웨어 패키지로 대체되는 추세
- 값비싼 구식 인프라 유지 비용, 메인프레임 기반 코볼을 유지보수 할 수 있는 사람들을 찾아 유지하기 어렵다는 문제
- 노후화되었고, 이를 지원할 전문성을 가진 인력도 고령화되고 있는 인프라
실제 기업 사례:
영국 DWP(Department for Work and Pensions)의 사례를 보면, VME 메인프레임 운영 체제가 2020년 12월 만료될 예정이라는 현실에 직면했습니다. 조직은 2,500만 줄의 코드를 업데이트한다는 결정을 내려야 했습니다.
3. 현대적 시스템과의 통합 어려움
디지털 트랜스포메이션의 장벽:
- 현대적 시스템, 모바일 및 클라우드 시스템을 구형 메인프레임에 통합하기가 정말 어렵다
- 경쟁 우위 측면에서 보면, 메인프레임 이용이 불리하다. 디지털 트랜스포메이션을 추진한다면, 결국 비즈니스 애플리케이션의 70%를 호스팅하고 있는 구석의 큰 메인프레임실의 코끼리를 다뤄야 한다
API와 마이크로서비스 아키텍처의 한계:
- 메인프레임은 모놀리식 구조로 되어 있어 최신 API 중심의 마이크로서비스 아키텍처와 통합하기 어려움
- 실시간 데이터 분석, 머신러닝, AI 기술과의 연계가 제한적
4. 데이터 활용의 한계
데이터 분석과 AI 도입 제약:
- 수십 년간의 비즈니스 거래가 포함되어 경쟁 차별화 요소를 모색하는 데이터 분석 또는 머신 러닝 이니셔티브를 제공할 수 있는 메인프레임 데이터 활용에 제약
- 실시간 분석, 빅데이터 처리, AI/ML 모델 적용이 어려움
이러한 이유들로 인해 많은 기업들이 메인프레임 현대화를 추진하고 있지만, 동시에 안정성과 성능을 포기할 수 없다는 딜레마에 빠져 있습니다.
IBM 메인프레임의 작동원리와 금융권 지배력
메인프레임이란? IBM Z 메인프레임은 z/OS, Linux, z/VM, z/VSE 및 z/TPF에서 운영되며 하나의 메인프레임에서 여러 운영 체제가 실행되는 경우가 많습니다.
1964년 IBM에서 출시한 시스템/360이 현대식 메인프레임의 시초이며, 현재까지도 금융권에서 절대적인 지위를 차지하고 있습니다. 상위 50개 은행 중 45개, 상위 5개 항공사 중 4개, 상위 10개 글로벌 소매업체 중 7개, Fortune 100대 기업 중 67개 기업이 메인프레임을 핵심 플랫폼으로 활용하고 있을 정도입니다.
메인프레임의 핵심 특징
1. 클러스터링 인덱스 기반의 고성능
고품질 메인프레임 서비스를 위해 설계된 OS를 통해 신용 카드 및 항공사 예약과 같은 높은 트랜잭션 볼륨을 거의 실시간으로 처리합니다.
2. 극강의 안정성
한번 들여놓으면 수십 년씩 운용할 수 있고, 이 특징 덕분에 1960~1970년대에 코볼로 짠 프로그램이 21세기에도 현역으로 돌아가는 진풍경이 펼쳐질 수 있는 것입니다.
3. 최신 AI 기술 통합
IBM z/OS 3.2는 z17 메인프레임의 핵심 운영체제로, IBM 메인프레임의 새로운 AI 가속 기술을 지원하며, 하루 4,500억 건 이상의 AI 추론 작업을 1밀리초 응답 시간으로 처리할 수 있도록 지원합니다.
이원화 운영의 필연성
금융권에서 현대화 프로젝트가 직면하는 가장 큰 과제는 무중단 서비스 요구사항입니다. 계정계 데이터 = 곧 돈과 거래기록 이기 때문에, 장애는 바로 금전적 피해로 이어진다. 따라서 데이터를 이중, 삼중으로 백업하며 시스템이 매우 보수적으로 운영된다.
이러한 이유로 대부분의 현대화 프로젝트는 이원화 전략을 택합니다:
- 기존 메인프레임 시스템: 안정적인 대량 거래 처리
- 신규 x86-리눅스 시스템: 디지털 혁신과 민첩한 서비스 개발
대량 거래를 안정적으로 처리하는 기존 메인프레임 기반의 '코어뱅킹1'과, 신규 비대면 금융 서비스에 최적화된 '코어뱅킹2'로 이원화하는 전략이 현실적인 대안으로 부상하고 있습니다.
계정계 후처리 시스템과 대사의 중요성
계정계 시스템의 구조
은행의 전통적인 핵심 업무는 통장이 중심이 됩니다. 이 통장을 계좌, 계정이라고 합니다. 계정을 관리하는 시스템이 모여 있다보니 "계정계"라고 부릅니다. 한 사람이 여러 개의 통장을 만들 수도 있고, 돌아가신 분의 통장도 있기 때문에 기본 데이터가 1억건이 가뿐히 넘습니다. 통장별 거래기록을 포함하면 수백억건의 데이터가 기본적으로 있습니다.
후처리 시스템과 대사의 역할
후처리 시스템에서 가장 중요한 것은 대사(Reconciliation)입니다. 대사란 서로 다른 시스템 간의 거래 데이터가 일치하는지 확인하는 과정으로, 0.1원의 오차도 허용되지 않습니다. 0.1원의 오류가 1억원의 피해로 이어질 수도 있음. 오류는 일결산에서 확인이 안되고, 월결산이나 연결산에서 발견될 수도 있다.
이원화 환경에서는 기존 모놀리식 시스템과 새로운 분산 시스템 간의 대사가 필수적이며, 이 과정에서 성능 문제가 불가피하게 발생합니다.
GUID/UUID와 분산시스템의 성능 딜레마
GUID/UUID 도입의 배경
분산 시스템에서는 각 서비스가 독립적으로 고유 식별자를 생성할 수 있어야 합니다. UUID는 Universally unique identifier의 약자로서, 정보 식별을 위하여 사용되는 식별자이다 128-bit 숫자로 이루어져 있으며, xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx 형식으로 표현한다
The power of a GUID comes from the fact that by definition it is 'Globally Unique'. That means that our consuming app can safely generate the value of the PK itself, without waiting for a response from the database.
UUID의 성능 문제
그러나 UUID를 Primary Key로 사용할 때 심각한 성능 문제가 발생합니다:
1. 저장 공간 문제
MySQL 의 Secondary Index 는 PK 컬럼 값을 포함하기 때문에 PK 컬럼의 길이가 길어지는 만큼 Secondary Index 의 크기도 증가하게 되는 구조입니다. UUID VARCHAR(36) 를 선언하는 것은 유혹적입니다. 그리고 아마도 전 세계적으로 생각하고 있을 것이므로 CHARACTER SET utf8(또는 utf8mb4)이 있습니다. utf8의 경우: utf8(또는 utf8mb4)의 경우 문자당 3(또는 4)바이트이므로 최대 길이 = 2+3*36 = 110(또는 146)바이트입니다.
2. 삽입 성능 저하
UUID를 PK로 사용할 경우 MySQL 내부적으로 재정렬을 하기 때문에 Insert 성능이 저하될 수 있다는 것이 핵심 문제입니다. GUID/UUID(Globally/Universally Unique Identifiers)는 매우 무작위적입니다. 따라서 인덱스에 INSERT하는 것은 많이 뛰어다니는 것을 의미합니다. 인덱스가 캐시하기에는 너무 커지면 대부분의 INSERT는 디스크 히트를 수반합니다.
3. 실제 성능 벤치마크
실제로 제가 수백만건의 레코드를 가지고 있는 서비스를 운영할 당시, uuid와 그냥 auto_increment를 사용할 때 사람이 인지할 수 있을 정도의 성능차가 있었으며,이를 개선하기 위해 꽤 많은 시간을 할애하였었습니다.
순서와 연관된 부분에서의 성능 차이는 약 11% 정도로, 그 차이가 더 확연하게 나타납니다. 이 차이는 uuid의 값을 이용해 순서와 연관된 sub 쿼리를 작성하였을 때 더욱 눈에 띄게 발생하게 됩니다.
전문 길이와 네트워크 오버헤드
분산 시스템에서는 서비스 간 통신을 위해 JSON, XML 등의 전문(메시지)을 주고받습니다. UUID 기반의 시스템에서는 식별자 자체가 36자의 문자열이므로 전문 크기가 상당히 커집니다.
예를 들어, 기존 시스템에서 고객번호가 12345678(8바이트)이었다면, UUID 시스템에서는 550e8400-e29b-41d4-a716-446655440000(36바이트)가 됩니다. 하나의 거래에서 수십 개의 식별자가 포함된다면, 네트워크 트래픽과 직렬화/역직렬화 비용이 급격히 증가합니다.
개발자 관점에서 생각
무중단 서비스를 위한 카나리 배포 전략
금융권에서 가장 중요한 것은 무중단 서비스이고, 이를 위한 카나리 배포 전략을 적용해 볼 수 있습니다.
대사 확인을 위한 Kafka 기반 이벤트 소싱
메인프레임과 MSA간 데이터 정합성을 보장하기 위해서, Kafka를 활용한 이벤트 소싱 패턴으로 해결
실시간 Kafka Stream으로 즉시 검증 가능하다!
UUID/GUID 성능 문제
Snowflake ID 패턴 : 64bit 분산 ID 생성 방식으로, 타임스탬프 + 머신ID + 시퀀스로 구성되어 시간순 정렬이 가능하면서도 분산 환경에서 충돌 없이 고성능 생성이 가능
UUID v7 (Time-ordered UUID) : 앞 48bit를 타임스탬프로 사용하여 기존 UUID v4의 무작위성은 유지하면서도 시간순 정렬이 가능해 데이터베이스 인덱스 성능을 크게 개선
전문 크기 최적화
MSA에서 서비스 간 통신 시 전문이 너무 길어지는 문제를 해결하기 위해
GraphQL 도입 : 클라이언트가 필요한 데이터만 정확히 요청할 수 있는 쿼리 언어로, REST API의 Over-fetching 문제를 해결하여 네트워크 트래픽과 응답 크기를 대폭 줄일 수 있는 기술
메시지 압축 (gRPC + Protocol Buffers) : Google에서 개발한 바이너리 직렬화 프로토콜로, JSON 대비 60-80% 작은 크기와 더 빠른 파싱 속도를 제공하여 마이크로서비스 간 통신 효율성을 크게 향상시키는 기술
마무리
금융 IT 현대화는 기술적 문제만이 아니라 조직문화, 개발 프로세스, 인력 구성까지 모든 것이 연결된 복합적 과제이다. 이러한 아이디어들을 PoC로 만들어보면서 팀을 구성하고, 검증해나가면 결국 완성할 수 있을 것이다.
