기본 금융권 아키텍쳐
은행 업무의 전산화, 계정계
옛날에 은행이 처음 전산화되던 시절에는 슈퍼컴퓨터가 사용되었다. IBM에서 만든 메인 프레임을 도입했고, 은행 거래에서 발생하는 수많은 입출금 데이터들을 이 곳에 저장했다. 이것이 은행의 최초의 전산화된 컴퓨터였고, 처음에 들어온 이 시스템을 은행 코어 시스템이라고 한다. 코어계, 기반계, 계정계라고도 부른다. 즉 은행에서 가장 중요한 부분을 담당하는 것이다. 여기에 주로 사용되는 언어는 COBOL, PL/1이었다. 그 옛날에 전공책에서나 보던 천공 카드에 구멍을 뚫던 시절이었다.(참고 블로그)
정보계의 등장
이렇게 데이터가 저장되면, CEO와 같은 대표들은 이 데이터를 활용한 통계 자료를 보고 싶어할 것이다. 어제 돈이 얼마가 들어왔고 고객이 얼마나 이용했는가? 단순히 생각하면 어려운 일은 아니다. 그냥 DB에 select group by하면 쉽게 결과가 나올 것이다. 하지만 해당 시스템은 계속해서 고객들의 돈이 거래되고 있다는 점이 문제다. 성능은 한정되어 있기 때문에 계속해서 거래가 이루어지고 있는 메인 프레임에 추가적인 처리를 요청하는 것은 시스템에 부하를 줄 수 있다.
그래서 계정계와 동일한 시스템과 DB를 복제해서 그러한 부수적인 업무만을 수행하도록 정보계를 만들었다. 당시에는 DB를 실시간으로 복제하는 기술이 없었기 때문에 하루 정도는 딜레이가 있었다. 이를 디퍼드(Deferred) 시스템이라고 한다. 디퍼드 시스템이란 동일 기종인 메인 프레임끼리 데이터를 (정보계로) 전송하는 것을 뜻하며, deferred의 의미 그대로 지연돼서 처리되는 것으로 이해하면 된다.
UNIX와 다운사이징
인터넷이 발달하며 이제는 사용자 친화적인 웹 UI가 일반적이지만, 아직도 메인 프레임을 쓰는 기업들이 있다. 코스트코에 가보면 아직도 직원들이 검은 화면에 SSH같은 터미널을 이용하는 모습을 볼 수 있다. 왜 아직도 메인 프레임을 쓰는 걸까? 효율이 매우 좋기 때문이다. KB은행도 아직 메인 프레임을 사용하고 있다. (SC제일은행은 추진?)
그런데 메인 프레임은 치명적인 단점이 있다. 비용이 너무 비싸다는 것이다. 은행이 비싼 IBM 금액을 부담으로 느끼던 와중, 유닉스(c/c++ 기반)와 이를 기반으로 한 다양한 프레임워크가 등장했다. 은행은 비용 절감을 위해 IBM의 메인 프레임에서 유닉스로 다운사이징을 하게 되었다. 성능이 조금 떨어지더라도 비용을 아끼는 것이다. 유닉스 환경으로 교체하기 위해서는 기존의 코볼과 PL/1에서 c언어 기반으로 바꿀 필요가 있었다. TMAX에서 개발한 proframe는 c언어 기반의 프레임워크를 제공하며, 실제 많은 은행에서 차세대 프로젝트에 해당 기술을 도입되었다. 코어계는 중요한 부분인 만큼 건들기 어려우니 정보계부터 유닉스로 바뀌게 되었고, 안정성이 검증되자 코어계도 서서히 바꾸기 시작했다. 이렇게 다운사이징하는 것을 금융권 차세대 프로젝트라고 한다.
KB은행의 차세대?
IBM의 메인 프레임도 일정 기간이 지나면 장비를 교체해야 한다. KB은행은 장비를 교체할 경우 IBM의 지원을 받기 위한 비용과, 다운사이징을 위해 시스템을 전부 c언어 기반으로 교체하는 데 드는 비용 2가지를 비교해 보았다. 그 결과 다운사이징 경우가 더 저렴한 것으로 판단히고 유닉스 시스템으로 전환하기로 결정했었다. (2012년부터 검토, 결정 후 2013년 10월에 금감원에 보고) 물론 비용뿐 아니라 IBM은 시스템 개방성이 떨어진다는 문제 등 다양하게 고려한 결과였다.
그러나 14년 4월, 한국 IBM 대표가 경영진들에게 사적인 이메일을 보내면서 내분이 시작되었다. 유닉스 시스템 전환에 리스크가 클 것이고, 저렴한 가격으로 메인프레임을 제공할 수 있다고 제안하는 내용이었다. 그렇게 최종적으로 유닉스 전환 결정은 철회하고 계속해서 IBM의 메인프레임을 2020년까지 사용하기로 결정되었다. 이후로는 ‘코어뱅킹 현대화’를 통해 유닉스로 전환하는 계획을 밝혔으나, 현재 2025년 기준 국민은행의 ‘탈 IBM 메인프레임’ 전략은 사라졌다. 오히려 오는 2030년까지 IBM 메인프레임 기반의 ‘코어뱅킹1’을 구축하겠다는 것으로 전략이 바뀌었다.
LINUX와 다운사이징
다시 돌아와서, 유닉스의 등장으로 많은 시중 은행들은 메인 프레임에서 유닉스로 다운사이징 차세대를 진행했다. 그러다 이후에는 훨씬 더 저렴한 (자바 기반의) 리눅스가 등장하게 된다. 심지어 리눅스는 오픈소스라는 장점도 갖고 있다. IBM의 메인 프레임의 아키텍처가 공개되지 않은 closed system 이었다. 유닉스 때와 마찬가지로 여러 곳에서 다운사이징을 진행했다. 최근 정보계는 대부분 리눅스로 전환되었으며, 계정계도 리눅스로 전환되는 추세인 것 같다.
채널계와 MCI
기존 오프라인 창구 뿐 아니라 인터넷 뱅킹이 발달하고 스마트폰 앱도 활성화되는 등, 은행 시스템에 접근하는 채널이 점점 더 다양해졌다. 이렇듯 고객이 금융 기관의 서비스를 이용하기 위해 사용하는 다양한 수단(영업점 창구, 인터넷뱅킹, ATM, 스마트폰 등)을 통틀어 채널계라고 지칭한다.
이러한 요청들이 전부 계정계에 바로 직접적으로 전달이 된다면 다양한 형태의 요청을 처리하기가 복잡해질 것이다. 이를 해결하기 위해 MCI(Multi Channel Integration)라는 통합 표준 인터페이스를 만들었다. MCI는 채널계의 다양한 채널에서 들어오는 요청을 표준화된 형식으로 통합해주는 역할을 한다.
EDMS, EAI, FEP(대외계)
- EDMS
은행 시스템이 점점 복잡해짐에 따라 전자 문서를 다룰 필요성도 생기게 되었다. 문서파일의 작성부터 소멸될 때까지의 모든 과정을 관리하는 시스템을 EDMS(Electronic Document Management System), 전자문서 관리 시스템이라고 한다. 각종 전자 문서의 등록, 저장, 관리, 송수신, 조회 등을 통일된 인터페이스로 지원한다. - EAI
지금까지 살펴본 것처럼, 하나의 기업 내에도 수많은 애플리케이션이 존재한다. 그리고 이 애플리케이션들은 서로 통신을 하게 된다. 만약 모든 애플리케이션이 각각 개별적으로 연결된다면, 시스템 간 개별적인 연결이 매우 많이 생기게 된다. 시스템이 6개일 때 15개의 연결이 필요한 것이다. 이럴 경우 유지보수는 물론 통신 환경에도 많은 어려움이 발생할 수 있다. 이런 문제점을 해결하기 위해 EAI(Enterprise Architecture Integration), 전사적 애플리케이션 통합 솔루션을 적용하게 된다. 이로 인해 중앙 집중화된 시스템 관리가 가능해진다. 은행은 계정계와 정보계에 각각 EAI가 존재하여 2중으로 되어있다.
- FEP
FEP(Front End Processor)란 원래 메인프레임에서 통신 과부하를 경감시키기 위해 전처리 작업을 하는 과정을 의미하나, 금융권에서는 의미가 조금 와전되어 B2B 연계(대외계)를 FEP라고 부른다. (타행 이체 시 요청 전달 등) 이러한 대외계는 아무래도 최신 기술의 변화에 느리게 대응할 수밖에 없다. 이 부분이 바뀌면 모든 은행이 바뀌어야 한다는 의미이기도 하기 때문이다. 그 대표적인 예로, 통신 시 HTTP 대신 TCP를 사용해야 하고, payload를 json이 아닌 fixed string을 사용해야 한다는 점이 있다. 아주 옛날에는 fixed length라고 해서 정해진 길이로 텍스트를 잘라 전송했고, ‘;’를 기준으로 구분하는 delimiter 방식, xml, json 순서로 발전해왔다. 요즘 대부분의 인터페이스들은 json format을 제공해주지만 대외계는 아직이란 거다.
OpenAPI
원래는 FEP 하나를 설치하는 것 자체로도 돈이 많이 들었다. 그런데 Open API가 등장하며 이 문제가 해결됨과 동시에 핀테크 서비스를 확장하는 데 도움이 되었다. 오픈 API란 이용자가 일방적으로 정보를 제공받는 데 그치지 않고 직접 응용 프로그램과 서비스를 개발할 수 있도록 공개된 API를 말한다. 금융권의 오픈 API를 활용하면 고객은 금융기관의 웹/앱에 직접 접속하지 않고도 오픈 API를 이용한 서비스를 사용하여 각기 다른 금융 기관의 계좌 조회나 송금 등을 한 번에 편리하게 실행할 수 있는 것이다. 보안이 필요하다면 VPN을 넣으면 된다. 하지만 그래도 openAPI에 개인정보는 가급적 포함하지 않도록 하며, 개인 정보가 필요한 경우에는 전부 FEP로 처리하고 있다.
💡VPN이란?
VPN의 목적은 크게 2가지가 있다. (1) 암호화 (2) 네트워크 가상화 이다. 여기서는 보안을 위해 사용하기 때문에 1번 역할을 하는 것이다. HTTPS는 프로토콜 자체가 암호화된 것인 데 반해, VPN은 장비가 암호화한다. 즉 원래는 VPN을 사용하기 위해서는 장비 설치가 필요하다. 하지만 최근에는 기술이 발전함에 따라 SW 서비스로도 제공된다. 다만 하드웨어에 비해 소프트웨어 VPN의 경우, 대용량 데이터가 빈번하게 들어오는 경우 속도가 많이 저하될 수 있다. 그렇기 때문에 안정성을 위해 대부분은 하드웨어 VPN을 사용한다. 하드웨어의 경우 장치가 암호화하고 것이라고 했는데, 이 말은 곧 보내는 쪽과 받는 쪽이 모두 동일한 장비를 사용해야 한다는 의미이다.
클라우드 시스템
서버 가상화 개념
IBM의 메인 프레임에는 하이퍼바이저라는 개념이 존재한다. 하이퍼바이저란 컴퓨터의 OS와 응용프로그램을 물리적 하드웨어에서 분리하는 프로세스를 말한다. 이를 통해 하나의 호스트 시스템이 여러 대의 가상 머신을 운영하여 컴퓨팅 자원을 더 효과적으로 사용할 수 있었다.
1990년대 말에 유닉스 서버의 전성기가 일어나고, 이때 서버 가상화라는 개념이 생기게 되었다고들 한다. 하지만 명확히 말하지면 서버 가상화라는 개념은 그 이전부터 존재했고, 유닉스와 함께 본격적으로 확장되었다고 볼 수 있다. IBM의 하이퍼바이저는 메인프레임이라는 특정 하드웨어에 종속된 개념이었기 때문이다.
그런데 유닉스에도 불편함은 있었다. 초기 OS가 개발된 이후로, 여러 기업이 각자의 버전으로 발전시킴에 따라 서로 호환이 잘 안된다는 점이다. 이렇듯 벤더마다 커널과 명령어 셋이 다르기 때문에 표준화된 가상화 솔루션을 만들기 어려웠다. 하지만 리눅스는 오픈 소스로 누구나 사용할 수 있었고, x86 아키텍처와 결합하면서 가상화 기술을 표준화 하기가 쉬웠다.
컴퓨터의 가상화
VMware의 VM은 Virtual Machine으로, 가상의 기계장치를 의미한다. 가상화 기술을 이용하여 한 개의 시스템으로 여러 개의 가상 데스크톱 환경을 구성하여 사용하는 것이다. 이러한 가상 머신에는 VirtualBox, VMware 등이 있다. VMware에는 주인(HOST)와 손님(GUEST)의 개념이 있다. 하나의 컴퓨터(host) 안에 여러 개의 가상 머신(guest)를 만드는 것으로 이해하면 된다. 이 host를 나눌 때 하이퍼바이저를 사용한다.
이러한 VM의 개념이 발전하여 SDC(Soft Defined Compute)가 등장했다. SDC는 소프트웨어 기반으로 컴퓨팅 리소스를 동적으로 관리하고 최적화하는 개념이다. VM은 하드웨어 중심적인 환경인 데 반해서, SDC는 소프트웨어를 통해 CPU, 메모리 등의 자원을 유연하게 관리할 수 있다. SDC + SDN(Soft Defined Network) + SDS(Soft Defined Storage) 3가지 개념을 합치면 결국 클라우드가 된다. 클라우드가 등장하면서 컴퓨팅 환경과 트렌드는 완전히 변화했다. 이렇게 좋은 클라우드 기술, 당연히 은행도 사용할까? 물론 사용하지만 VM도 여전히 사용 중이다.
은행은 왜 계속 VM을 쓸까?
이를 이해하기 위해서는 VM 과 컨테이너에 대한 비교가 필요하다. 우선 둘 모두 host OS 위에서 돌아간다. VM의 경우 하이퍼바이저를 사용하여 여러 Guest OS를 올려 여러 VM을 모두 별도의 OS를 가지고 있는 것처럼 사용 가능하다. 컨테이너의 경우 도커 등을 활용해서 여러 컨테이너들 간에 호스트 자원을 분리해서 사용할 수 있게 해준다. 이는 리눅스의 고유 기술인 namespace와 cgroup을 이용한 것이다.
은행이 컨테이너를 사용하지 않고 아직까지 VM을 사용하는 이유는 결국 보안성 때문이라고 생각한다. 컨테이너는 관리가 편하지만, 구조적으로 하나의 OS 커널을 공유하기 때문에 문제가 생겼을 때 다른 서비스에도 영향이 미칠 수 있다. 반면 VM은 서로 독립된 OS 환경을 제공하기 때문에 하나의 VM이 공격 당하더라도 각 VM은 독립적이기 때문에 다른 시스템에 피해가 가지 않는다.
OpenStack 플랫폼
다시 돌아와서, 클라우드 기술은 다양한 산업과 서비스에서 활발하게 사용되고 있다. AWS, Azure, GCP와 같은 서비스들이 대표적이다. 그런데 보안을 중요시하는 금융권에서 타사의 클라우드 서비스를 쓴다? 자신들만의 리소스를 활용해서 새로운 클라우드 서비스를 만들고 싶지 않을까? 이것이 프라이빗 클라우드이다.
그리고 프라이빗 클라우드 구축 시에 사용하는 것이 OpenStack이다. OpenStack은 퍼블릭/프라이빗 클라우드를 구축/관리하는 오픈소스 플랫폼이다. 하나금융의 하나클라우디아가 이를 기반으로 개발되었다.
Docker와 K8s
기존 VMware는 물리 서버(host) 하나를 하이퍼바이저를 이용해서 여러 개의 가상 머신으로 나누는 방식으로 동작했다. 이러한 방식은 무거운 구조를 가진다는 단점이 있었고, 이후에 나온 것이 컨테이너 기술이다. 대표적으로 Docker와 이를 관리하는 K8s(쿠버네티스)가 있다. 컨테이너는 VM과 다르게 host의 OS 커널을 공유하면서 프로세스 수준의 격리를 제공한다. 이는 VMware보다 훨씬 가볍고 빠르게 애플리케이션을 실행할 수 있도록 도와줬다. 이러한 컨테이너가 많아짐에 따라 이를 한 번에 관리/배포/확장/모니터링하기 위한 도구의 필요성이 등장했다. 처음에는 Docker swarm 등 다양한 툴이 있었지만, 현재로서는 사실상 쿠버네티스가 표준이 되었다고 볼 수 있다.
쿠버네티스는 오픈소스로 공개되었기 때문에 여러 기업에서 이를 기반으로 상용 제품을 만들었다. RedHat의 Open Shift는 여기에 기업용 기능(보안, 인증 등)이 추가된 것이다. OpenShift의 오픈소스 버전으로 OKD(Origin Community Distribution)도 있다.
IaC(Infrastructure as Code)
쿠버네티스는 애플리케이션이 실행되는 환경이 온프레미스든, 프라이빗 클라우드든, 퍼블릭 클라우드든 상관없이 동일한 실행 환경을 제공해준다. YAML 파일을 통해 필요한 리소스를 정의하며, 이 파일을 쿠버네티스 클러스터에 적용하면 완전히 동일한 상태를 언제 어디서든 재현할 수 있다. 이것이 바로 코드로 인프라를 관리하는 IaC의 예이다.
그보다 더 하위 레벨의 인프라(VM, 네트워크, LB 등)을 코드로 관리할 수 있도록 도와주는 도구가 바로 HashiCorp의 Terraform이다. 쿠버네티스와 테라폼 모두 코드로 인프라를 정의한다는 공통점이 있지만, 쿠버네티스는 컨테이너 오케스트레이션만 다루고 테라폼은 클라우드 자원의 생성/제어를 다룬다는 점에서 차이가 있다. Terraform은 원래 오픈소스로 시작했지만, 최근에는 라이센스 변경으로 인해 커뮤니티 주도로 OpenTofu가 오픈소스로 제공되고 있다.
여기에 Ansible을 같이 사용한다면 완전한 자동화를 만들 수 있다. Ansible이란 Python으로 개발된 오픈소스 IaC 솔루션으로, 시스템을 구성하고 애플리케이션을 배포하는 등의 IT 작업을 자동화할 수 있다. httpd를 설치하고, 방화벽을 설정하고, 패키지를 설치하고.. 등의 과정을 모두 하나의 Playbook 파일로 작성하는 것이다. 그렇다면 ansible과 쉘 스크립트의 차이점은 무엇일까? 가장 큰 차이는 멱등성인 것 같다. 멱등성이란 “어떤 연산이 여러 번 수행되더라도 결과가 달라지지 않는 성질”을 뜻하며, 쉘의 경우 같은 모듈을 반복 실행했을 때 중복 생성이나 충돌 등의 발생 가능성이 있다.
References
'Etc' 카테고리의 다른 글
| 리눅스 마스터 2급 정리(2) - 기본 명령어 (0) | 2025.05.02 |
|---|---|
| 리눅스 마스터 2급 정리(1) - 리눅스 일반 (0) | 2025.05.01 |
| USB 마운트 및 파일시스템 (0) | 2025.03.12 |
| [코테후기] 2022 원티드 3rd 쇼미더코드(+코드) (0) | 2023.01.14 |
| 블로그 시작 (0) | 2023.01.04 |