처음 금융 IT 프로젝트에 투입되고, 새로운 용어들 속에 굉장히 혼란스러웠다. 채널계와 계정계를 나눠서 프로젝트를 진행하는 것 같은데… 각각이 무엇을 의미하는 지는 모르겠고, MCI와 EAI를 사용하여 통신을 하는 것 같은데… 이게 또 정확히 무엇인지는 모르겠고… 오늘은 이러한 부분들을 다시 한번 톺아보고 해소하기 위해 금융앱빌런 님의 글을 기반으로 정리해보았다.
채널계, 계정계, 정보계, 대외계
금융 IT를 하다보면, 채널계/계정계/정보계라는 용어를 많이 듣게된다.
먼저 각각의 개념에 대해 간단히 살펴보고, 뒤에서 더 상세히 살펴보자.
금융권은 업무를 시스템 단위로 분류하여 일반적으로 다음과 같이 3가지로 부른다.
1. 채널계
가장 먼저 채널계는 최종 사용자가 사용하는 앱/웹을 담당하는 시스템이다. 계정계에서 전달해 준 데이터를 바탕으로 사용자가 보는 화면을 제공하는 역할을 한다.
2. 계정계 (Core Banking)
Core Banking이라고 불리며 금융IT의 핵심이라고 할 수 있는 계정계는 예금, 대출, 카드 등 금융 상품을 제공하고 거래 정보를 처리하는 시스템이다. 업무 단위가 커지면 외환, 수신, 여신, 승인계 등 시스템을 나누기도 한다.
3. 정보계
정보계는 채널(대외), 계정계에서 처리된 데이터를 처리하는 시스템이다. Data Warehouse에 데이터를 적재해 현업이 sql/python 등으로 분석을 할 수 있게 해 주는 시스템이다.
+ 대외계
대외계는 채널계와 함께 외부 연계를 담당하는 시스템이다. 외부 기간과 전문/API 등의 연계를 담당한다. 채널계와 대외계는 모두 외부와 연계되는 만큼 DMZ 구간에 구성해 내부 시스템과 분리한다.
PT-BT-DT로 이해해보기
금융앱빌런 님께서 PT-BT-DT의 관점으로 정리하셨는데, 이해하기 좋은 것 같아서 추가로 가져와봤다.
객체지향 프로그래밍 방법론(OOP)에서는 PT(Presentation Tier), BT(Buisness Tier), DT(Data Tier)로 구조를 나누기도 한다.
- 채널계(대외계)는 PT라고 볼 수 있다. UI와 관련이 깊고, 사용자가 입력한 정보를 BT에 전달한다.
- 계정계는 BT라고 볼 수 있다. 비즈니스 로직과 관련된 영역으로 데이터 처리, 비즈니스 규칙을 포함한다.
- 정보계는 DT라고 볼 수 있다. 데이터베이스 및 DW와 관련된 시스템으로 데이터의 저장, 관리, 처리를 수행한다.
그러면 이제 각 분류에 대해 더 상세히 알아보자 !
채널계
💡 사용자(End User)가 접속하는 다양한 채널의 데이터를 관리하는 시스템
쉽게 설명하면 인터넷 뱅킹, ATM 등 고객이 은행 거래를 위해 접근하는 수단이 바로 채널계라고 이해하면된다. 최근 채널이 다양해지면서, 채널계의 중요도도 높아졌다고 한다.
뭔가 해야 하는 일이 생겼는데 채널계 쪽 담당자는 계정계가 보내주는 대로 보여준다고 하고, 계정계쪽 담당자는 채널에서 여러 전문의 항목을 조합해 사용하는 것이라고 한다. 도대체 채널계는 구체적으로 무엇을 하는 것일까?
이러한 채널계의 핵심적인 업무는 다음과 같다.
- 계정계의 데이터를 전문을 통해 화면에 뿌린다.
- 사용자의 요청을 계정계에 전달하고, 계정계의 처리 결과를 노출한다.
사용자가 앱을 실행시키고 로그인할 때 채널계와 계정계가 어떻게 움직이는지 살펴보자.
- 사용자는 앱에 아이디/비밀번호를 입력 후 확인을 누른다. 이 요청은 채널계로 전송된다.
- 채널계는 아이디/비밀번호 혹은 인증 내역을 받아 채널계 내의 원장(테이블)을 바탕으로 검증한다. 이때 문제가 있다면 오류화면을 보여준다. 검증이 되었다면 고객 ID를 게정계로 전달한다.
- 계정계는 채널계에서 받은 고객ID를 바탕으로 각 업무단에서 필요한 정보를 취합해 전문으로 전달한다. 여기에는 고객의 보유계좌, 계좌잔액, 대출잔액, 한도 등 다양한 정보가 포함되어 있다.
- 채널계는 계정계에서 받은 데이터를 바탕으로 고객의 메인화면을 구성해 사용자에게 노출한다.
계정계(Core Banking)
💡 고객의 거래 데이터를 처리하는 핵심 시스템
우리는 은행에서 거래할 때, 통장 정보를 필수로 입력해야 한다. 이처럼 거래의 핵심 요소인 통장을 계좌, 계정이라고도 부르는데, 이러한 계정을 관리하는 시스템을 모아 ‘계정계’라고 한다. 계정계라는 명칭은 예전에 통장을 ‘계정’이라고 부른 것에서 유래되었다고 한다. 한 사람 당 여러 계좌를 갖고 있기도 하고, 돌아가신 분의 계좌가 있을 수도 있고, 각 계좌의 거래 데이터도 여러 건이 될테니, 그 데이터량은 1억도 가뿐히 넘는다고 한다.
계정계는 Core Banking System이라고도 하는데, 그만큼 금융사에서 핵심적인 역할을 하는 시스템이다. 고객 정보와 계좌 정보 관리, 거래 정보 기록 및 처리, 입금, 출근, 계좌이체, 신규개설, 금융 상품 관리 등의 핵심 업무를 수행한다. 계정계에서 맡는 업무 단위가 너무 커지면 모듈별로 분할하기도 한다. 은행으로 치면 여신, 수신, 외환, 채권 등으로 분리될 수 있다. 카드로 치면 승인, 할부/리스, 카드금융 등으로 분할될 수 있다.
이처럼 계정계는 굉장히 중요한 시스템이고, 이러한 계정계에 장애가 생기면 바로 금전적 손실로 이어지기 때문에, 장애에 굉장히 민감하고 매우 보수적으로 운영된다. 혹시라도 문제가 생겨서 고객 계좌 정보가 변경된다면? 금융상품이 오류를 뱉어 이자율에 문제가 생긴다면? 정말 생각만 해도 끔찍하다.
금융앱빌런님의 예시를 살펴보자. 예를 들어 고객의 이력을 조회하는 0000번 전문이 있다고 하자. 이 전문을 가지고 채널계에서는 고객의 마이페이지를 보여주고, 고객센터에서는 정보를 조회하며, CMS에서도 마케팅 관련 정보 분석을 위해 쓰인다. 그렇기 때문에 이 전문에 무언가 추가하고 싶다고 하면 ‘그건 거기서만 쓰는 게 아니어서 변경이 어렵습니다.’ 라는 대답을 듣게 된다.
💡 전문(Message)이란?
’정해진 길이대로 저장하는 체계’라는 의미를 지닌다. 금융 it에서는 중개 서버를 두고 데이터를 송수신할 때 정해진 형식으로 데이터를 보내겠다는 약속을 하고, 이렇게 정해진 형식을 ‘전문’이라고 할 수 있다. 쉽게 얘기하면 request는 ~하게 고정돼있고, reponse는 ~하게 고정된 형태라고 말할 수 있을 것 같다.
실제로 필자가 경험한 금융 프로젝트에서도 전문을 여러개 호출하여 조합하거나, 특정 데이터만 필요한 경우에도 리턴 값이 큰 전문을 호출하는 경우를 찾아볼 수 있다. 이런 기존의 레거시, 기간계(계정계) 시스템으로 인해 새롭게 무언가를 하는 것이 굉장히 어려운 것이다. 새로운 변화를 위해 시도하다가 시스템 장애가 난다면 문제가 심각해질 수 있기 때문이다.
이에 따라 채널계를 MSA로 전환하여 운영하는 곳은 찾아볼 수 있어도 계정계를 MSA로 운영하는 곳은 쉽게 찾아보기 어려운 것이 아직은 현실이다. 그럼에도 계정계(Core Banking)를 MSA로 전환한 곳이 있는데 바로 토스뱅크(Toss)이다. 이에 대한 내용은 토스 기술 블로그에 잘 설명되어 있어서 관심있는 사람들은 함께 보면 좋을 것 같다.
https://toss.tech/article/slash23-corebanking
은행 최초 코어뱅킹 MSA 전환기 (feat. 지금 이자 받기)
수십 년간 정체되어 있던 전통적인 은행 시스템의 모놀리식 소프트웨어 아키텍처를 MSA로 전환할 수 있을까요? 토스뱅크의 ‘코어뱅킹 MSA 전환’ 사례를 통해 향후 은행 시스템이 나아가야 할
toss.tech
정보계
💡 거래의 기록을 관리하고 통계 처리하는 시스템
계정계의 데이터를 기반으로 영업점 및 각 부서의 업무 처리를 위해 필요한, 고객의 거래 데이터에 대한 ‘기록’ 및 기록의 ‘통계’를 관리하는 시스템이다. 이러한 정보계의 핵심적인 업무는 다음과 같다.
- 고객 등 회사 데이터에 대한 데이터 관리
- 채널계와 계정계에서 생성되는 데이터의 적재, (빅)데이터 분석
- ODS, DW 등의 데이터 관련 시스템 관리
📍 고객 등 회사 데이터에 대한 데이터 관리
가장 기본적인 기능은 고객, 금융 상품 등 금융 회사에서 관리가 필요한 데이터들의 관리를 담당하고 있다. 정보계에서 관리하는 데이터를 바탕으로 계정계에서 거래를 처리하고, 그 처리 결과는 채널계를 통해 고객에게 전달된다.
📍 채널계와 계정계에서 생성되는 데이터의 적재
채널계와 계정계에서는 하루에도 셀 수 없이 많은 데이터가 생성된다. 채널계에서는 웹로그 데이터가 주로 쌓이고, 계정계에서는 업무/조회/에러로그/고객거래정보가 쌓인다. 이러한 데이터들은 EAI 같은 미들웨어를 거쳐 ODS(Operational Data Store)에 적재된다. 그리고 ODS에서 정해진 데이터들이 DW(Data WareHouse)에 적재된다. 그러면 이제 분석할 수 있게 된다.
💡 EAI란?
여기서는 ‘금융IT 시스템에서의 중개서버’ 정도로 이해하고 넘어가도 될 것 같다. 내부 연계에 대한 내용은 다음 포스팅에서 자세히 다뤄볼 예정이다.
그러나 채널과 계정계에서 생성된 모든 로그가 적재되는 것은 당연히 아니다. 너무나도 많은 데이터들이 생성되기 때문에, 이 중 현업의 요건에 따라 분석에 필요한 데이터들이 주로 적재된다.
대외계
💡 각 금융기관의 대내외 망을 연결하는 시스템
대외계는 은행 외부기관과의 연계 업무를 위해 구축하는 시스템으로, 은행 공동망, 제휴 기관, 금융 결제원 등 각종 대외 가관과의 연결 프로토콜을 관리한다. 예를 들어, 은행에서 외부 보험상품을 판매하기 위해서는 해당 보험사와 실시간 정보 공유를 해야 하지만 보안을 이유로 내부 시스템과 직접 통신이 아닌 대외계 시스템을 거쳐 주고 받는 프로세스라고 볼 수 있다.
다들 잘 알고있겠지만 금융사는 보안에 굉장히 예민하다. 금융사 보안에 대해서는 별도의 시행령도 있고, 규정도 있으며, 감독기관에서 감사를 나오기도 한다. 이러한 금융사가 외부와 연결하는 것이 쉬울 수가 없다. 그럼에도 불구하고 외부와 연계하는 업무를 하는 곳이 바로 대외계이다. 웹뮤 호출 등의 간단한 연동은 채널계에서 하는 경우도 있지만, 외부 기관과 ‘거래’를 하는 순간 대외계에서 나서야 한다. 대외계에는 채널계와 함께 DMZ라는 곳에 있다.
우리가 사용하는 앱, 웹은 어디서든 접속이 가능하다. 그러나 당연하게도 금융사 내부의 데이터에는 접속이 불가능하다. 그러면 금융사 내부에 있는 데이터가 우리 스마트폰으로 어떻게 전송되는 것일까? 이때 사용되는 것이 바로 DMZ(De-Militarized Zone)라는 요소이다.
DMZ는 외부망(공중망)과 내부망 사이에 존재해 외부에서 접근하는 웹서버, WAS, 이메일 서버 등을 운영하는 영역이다. 외부망과 DMZ, DMZ와 내부망 사이에는 방화벽이 존재해 외부에서의 침입을 방지한다. 정리하면 DMZ에 존재하는 대외계는 외부와의 연동이라는 역할을 수행한다.
다음 예시를 살펴보자.
1. 고객의 신용을 조회하기 위해 CB 사로 고객의 CI 정보를 (통신사가 발생하는 고객의 키값) 보낸다.
2. 이 정보는 계정계가 가지고 있으나, 대외계를 통해 전용선 또는 VPN을 적용한 공중망을 통해 CB사로 전송된다.
3. 응답 역시 동일한 방식으로 돌아오고, 대외계를 거쳐 내부망으로 들어온다.
Reference