금융 IT 구조 해부하기 (2) 계정계
금융IT의 꽃일까? 골칠까?
by
Apr 5. 2023
계정계에서 하는 거라 바꾸기 어려워요.
계정계는 처음 금융앱 PM이 된 때부터 지금까지 너무 어려운 곳이다. 계정계라는 명칭은 예전에 통장을 '계정'이라고 부른 것에서 유래되었다고 한다. 계정계는 Core Banking System이라고도 하는데, 그만큼 금융사에서 핵심적인 역할을 하는 시스템이다. 고객 정보와 계좌 정보 관리, 거래 정보 기록 및 처리, 금융상품 관리 등을 수행한다. 계정계에서 맡는 업무 단위가 너무 커지면 모듈별로 분할하기도 한다. 은행으로 치면 여신, 수신, 외환, 채권 등으로 분리될 수가 있다. 카드로 치면 승인, 할부/리스, 카드금융 등으로 분할될 수 있다.
표의 core banking 영역이 계정계이다. (IT위키)이렇게 중요한 거래를 처리하다 보니 너무 당연하게도 장애에 굉장하게 민감하다. 혹시라도 문제가 생겨서 고객 계좌 정보가 변경된다면? 금융상품이 오류를 뱉어 이자율에 문제가 생긴다면? 생각만 해도 끔찍하다. 게다가 계정계 시스템은 오만군데와 연계가 되어있는 경우가 많다. 이렇게 장애에 민감하고, 변경의 영향도가 크다 보니 보수적으로 운영된다. 예를 들자면 고객의 이력을 조회하는 xxxx번 전문이 있다고 하자. 이 전문을 가지고 채널계에서는 고객의 my페이지를 보여주고, 고객센터에서는 정보를 조회하며, CMS에서도 마케팅 관련 정보 분석을 위해 쓰인다. 그렇기 때문에 이 전문에 무언가 추가하고 싶다고 하면 '그건 거기서만 쓰는 게 아니어서 변경이 어렵습니다.'라는 대답을 듣게 된다.
그래서 결국 현업은 기존에 있던 전문을 여러 개 조합해서 화면에 보여주게 하거나, 요건을 변경하거나 포기하게 된다. 이런 기존의 레거시, 기간계 시스템으로 인해 새롭게 무언가를 하는 것이 굉장히 어려운 것이다. 그렇다고 계정계 탓으로만 돌리기 어려운 것이, 해당 시스템이 대고객 서비스만을 위해 존재하는 것이 아니라는 것이다. 고객을 위해 무언가를 만들겠다는 현업과 장단을 맞춰주다 시스템에 장애가 난다면 문제가 심각해질 수 있기 때문이다.
금융사의 계정계와 차세대 프로젝트
금융사 IT 시스템은 1970년대 은행 시스템이 메인 프레임 형식으로 개발된 것이 시작이고, 이때는 계정 처리를 위해 운영이 되었다고 한다. 그리고 여기에 여러 시스템을 덧붙여 사용하다 2000년대에 개선 작업을 진행했는데, 이 범위가 너무 커서 '차세대'라 불렀다고 한다. 이러한 차세대 작업을 통해 메인프레임 위주였던 시스템을 점차 개방형으로 만들고, 변화에 유연하게 만들어 가고 있다. 여러 금융사에서 차세대 프로젝트를 통해 서비스를 고도화하고, 경쟁력을 확보하고자 한다.
금융 차세대의 발전너네는 왜 토스 같이 못해?
금융사에서 IT 현업으로 있다고 하면 자주 듣는 이야기가 '너네는 왜 토스처럼 못해?'다. 친구들에게서 듣기도 하지만, 사실 회사 내에서 전무님, 부장님, 팀장님에게서도 듣는 얘기기도 하다. 왜 못하나, 거기에는 다양한 이유가 있지만 가장 큰 이유 중 하나는 계정계가 모놀리틱(Monolithic) 형태로 구성되어 있기 때문이다. 복잡한 정보처리를 한 시스템에서 처리하다 보니 어쩔 수 없이 느려지고 복잡해진다.
이에 대한 대안으로 나온 아키텍처 중 하나가 MSA(Micro Service Architecture)이다. 원래는 한 프로그램인 것을 작고 독립적인 단위로 나누어 서비스한다. 그리고 각 서비스는 API를 통해 다른 서비스와 커뮤니케이션한다. 이런 구조가 되면 서비스 단위별로 개발 및 배포를 할 수 있다. 물론 통합 테스트도 어려워지고, 데이터 역시 마이크로 서비스 단위로 적재되어 효율성이 떨어질 수 있다. MSA가 무조건적으로 모놀리틱 보다 좋다고 주장할 수는 없겠지만, 토스뱅크가 MSA를 통해 효과적으로 구축한 서비스를 보면 전통 금융사들에 주는 시사점이 크다.
오른쪽이 MSA이다. (출처 : IT위키)