은행 아키텍처 알아보기

들어가며 (동기) 

 

대출금 상환 프로젝트는 실제 은행 시스템을 모방하여 설계하고 이 과정에서 신뢰성 , 성능 등의 문제 상황을 가정 , 이를 해결해보는 개인 포트폴리오 입니다. 

아키텍처를 설계하기 전 , 아키텍처 스타일에는 어떤 것들이 있으며 , 실제 은행 아키텍처는 어떤지 공부해야할 필요성을 느꼈습니다. 

그래서 이 글에서 , 이를 공부하고 글로 남겨보겠습니다. (검수 필요) 

 

---

아키텍처 스타일 : 모놀리식 vs MSA

 

서비스를 어떻게 나누고 배포할 것인가는 아키텍처를 설계할 때 가장 먼저 마주하는 질문 입니다.

흔히 비교되는 2가지 스타일인 모놀리식과 MSA 를 정리해보겠습니다.

 

모놀리식 아키텍처 

 

모놀리식 은행 아키텍처

 

모놀리식은 서비스의 기능들이 하나의 애플리케이션 안에 모두 포함되고 , 하나의 데이터베이스를 공유하는 구조 입니다. 

예를 들어 은행 시스템이라면, 수신·여신·카드·회계 기능이 단일 서버 안에 함께 구현되고 하나의 DB를 바라보게 됩니다.

가장 기본적이고 직관적인 구성 방식이라 처음 아키텍처를 설계할 때 가장 많이 선택되는 구조입니다.

 

장점

 

• 구조가 단순해 이해하고 개발하기 쉽습니다.
• 하나의 코드베이스, 하나의 배포 파이프라인이라 빠르게 개발하고 배포할 수 있습니다.

 

단점

 

• 서비스 규모가 커질수록 코드 복잡도가 증가하고 유지보수가 어려워집니다.
• 일부 기능만 트래픽이 몰려도 전체를 함께 확장해야 해서 확장성과 가용성이 떨어집니다.
• 성능 최적화나 부분적인 분산 처리에 한계가 있습니다.

 

MSA (마이크로 서비스 아키텍처)

 

MSA 은행

 

 

 

MSA는 동일한 은행 도메인을 여신, 회계, 수신, 카드처럼 기능 단위로 완전히 쪼개서, 각각을 독립된 애플리케이션으로 만들고 독립된 DB를 갖게 하는 구조입니다. 모놀리식이 하나의 애플리케이션·하나의 DB였다면, MSA는 도메인 경계를 따라 애플리케이션과 DB를 모두 나눈다는 점이 가장 핵심적인 차이입니다.

 

서비스가 물리적으로 분리되어 있으니, 서비스 간에 필요한 정보를 주고받으려면 더 이상 메서드 호출이 아니라 네트워크를 통한 통신이 필요해집니다. 이때 즉시 응답이 필요한 경우에는 REST API 같은 동기 방식을, 응답을 바로 기다릴 필요가 없는 경우에는 메시지 큐를 통한 비동기 방식을 사용합니다. 

 

장점 

• 도메인별로 서비스가 완전히 분리되어 독립적으로 개발하고 배포할 수 있습니다.
• 한 서비스에 장애가 나도 다른 서비스로 전파되지 않는 장애 격리가 가능하고, 필요한 서비스만 따로 확장할 수 있습니다.
• 서비스마다 다른 언어, 프레임워크, DB를 자유롭게 선택할 수 있습니다.

단점

• 서비스가 여러 개로 나뉘는 만큼 시스템 전체의 복잡도가 증가합니다.
• 여러 DB에 걸친 데이터 일관성 관리, 서비스 간 통신 장애 처리 등 설계 난이도가 올라갑니다. 
• 서비스마다 비슷한 기능(인증, 로깅 등)을 중복 개발하게 될 가능성이 있습니다.

 

---

은행 아키텍처 들여다보기

 

출처 : https://toss.tech/article/slash23-corebanking

 

 

채널

 

채널이란 고객이 은행 서비스에 접근하는 모든 접점(인터페이스)을 의미합니다. 

"어떤 수단으로 은행과 상호작용하는가"를 가리키는 개념입니다. 

 

채널은 크게 두 갈래로 나뉩니다.

대면 채널 : 직원이 직접 응대하는 방식 (영업점 창구 , 텔러 단말) 

비대면 채널 : 직원 개입 없이 고객이 직접 접근 하는 방식 (ATM , 인터넷 뱅킹 , 뱅킹앱 , 오픈 뱅킹 API)   

 

채널계 

 

채널들이 보낸 요청은 곧바로 코어뱅킹으로 가지 않습니다. 그 사이에서 다양한 채널의 요청을 표준화해 코어뱅킹으로 전달하는 시스템이 채널계입니다. 보통 채널계는 자체 DB 를 두고, MCI(Multi Channel Integration)라는 미들웨어를 통해 코어뱅킹과 통신합니다. 단순히 "요청을 모아서 전달"하는 수준을 넘어, 실질적으로 다음과 같은 책임을 함께 지고 있습니다.

 

전문 변환과 라우팅 

뱅킹앱이 보내는 요청과 ATM 이 보내는 요청의 포맷은 다릅니다. 채널계는 이 서로 다른 포맷을 코어뱅킹이 이해하는 표준 전문 형식으로 변환하고, 어떤 업무(수신,여신,카드)로 보낼지 라우팅 합니다. 

 

인증과 세션 관리 

고객이 앱에 로그인하면, 그 세션이 유효한지·토큰이 만료되지 않았는지 같은 인증 검증을 채널계가 1차로 처리합니다. 코어뱅킹이 매 요청마다 인증을 다시 확인하지 않도록, 채널계가 일종의 게이트 역할을 하는 셈입니다.

 

화면용 데이터 조합 (Backend For Frontend)

화면을 그리는 일 자체는 모바일 앱이나 웹 클라이언트가 담당합니다. 다만 화면 하나를 채우는 데 필요한 데이터가 여러 코어뱅킹 거래에 걸쳐 있는 경우가 많아서, 채널계가 이 거래들을 대신 호출하고 화면에 맞는 형태로 조합해 클라이언트에 내려주는 역할을 합니다. 반면 ATM이나 영업점 단말처럼 클라이언트가 가벼운 채널에서는, 어떤 화면을 다음에 보여줄지 같은 흐름 제어까지 채널계가 더 깊이 관여하는 경우가 많습니다.

 

로깅

채널계에는 주로 웹로그(접속 이력, 화면 흐름 등)가 쌓이고, 코어뱅킹에는 업무 처리 로그·거래 내역이 쌓입니다. 두 로그는 성격이 달라서 별도로 적재되고, 이후 EAI 같은 미들웨어를 거쳐 분석 시스템으로 모입니다.

 

가용성·성능 병목 관리
구조적으로 모든 채널의 트래픽이 한 곳(MCI)으로 몰리기 때문에, MCI에 장애가 생기면 시스템 전체 장애로 번질 수 있어 별도의 장애 대응 방안이 필요합니다. 그래서 채널계는 단일 장애점(SPOF)이 되지 않도록 이중화나 부하분산 설계가 중요한 영역 입니다.

 

코어뱅킹 (계정계) 

 

채널계가 전달한 요청을 받아 실제로 처리하는 곳이 코어뱅킹입니다. 금원과 관련된 메인 비즈니스 로직을 처리하는 시스템으로, 계정계라고도 부릅니다. 여신, 수신, 외국환 업무 등 고객과의 직접적인 금융거래를 담당하며, 금융회사 전체의 정보시스템을 통제하는 핵심 솔루션입니다. 계좌 잔액, 거래 원장 같은 가장 민감하고 중요한 데이터가 여기서 관리됩니다. 한 번 구축되면 최소 5~7년간 사용되고, 구축 비용도 수백억 원에 달할 만큼 무겁고 보수적으로 다뤄지는 시스템입니다.

 

모놀리식

 

코어뱅킹은 대부분의 은행에서 여전히 거대한 모놀리식 구조로 운영되고 있습니다. 채널이 늘어날 때마다(폰뱅킹 → 인터넷뱅킹 → 모바일뱅킹) 기존 시스템에 기능을 계속 얹어온 결과로, 처음부터 모놀리식을 의도했다기보다는 자연스럽게 굳어진 형태에 가깝습니다. 여신·수신·카드·회계가 한 코드베이스에 있을 뿐 아니라, 채널계와의 통신을 위한 MCI, 대외연계를 위한 FEP, 대내 시스템과의 연계를 위한 EAI까지 코어뱅킹 서버에 강결합되어 있는 구조입니다. 

---

코어뱅킹의 MSA 전환 사례 - 토스뱅크