컴포저블 뱅킹?

맘부 (Mambu) - 핀테크 Case Study

뱅킹 시스템, 무겁고 겁나 어려운 시스템에서 가벼운 레고 블록으로

몇년전 부터 글로벌 금융 IT 시장에서 자주 떠드는 말은 클라우드 네이티브(Cloud Native)와 컴포저블 뱅킹(Composable Banking)이다. 과거 수백~수천억 원을 들여 수년에 걸쳐 구축하던 무거운 단일(Monolithic) 시스템 시대가 저물고, 필요한 기능만 API로 조립해 쓰는 시대가 도래 했다고 다들 말했던 적이 있다. 말은 매우 쉬워 보였는데, 과거 코어가 무척 해비하고 정말 무서워서 건딜지도 못하고 오래된 시스템을 쓰는 것에 비해서 조금 쉽고, 가볍게 만들자는 이야기가 과장 되었지만, 제품으로 만들어 지면서 조금씩 성공의 이야기가 전달되어 졌다. 사실 이런 성공 스토리는 한국 보다는 유럽쪽에서 먼저 시작했는데 그런 회사 중의 하나로 2011년 마이크로파이낸스 SaaS로 출발해 글로벌 유니콘으로 성장한 맘부(Mambu)에 대해서 글을 쓰고자 한다. (22년에 내가 작성했던 Case Study를 다시 각색하였음, 아래그림들은 내 보고서에서 발췌함, 이와 비슷한 내용은 내가 디지털데일리 주관 금융세미나에서도 발표 했었다.)

맘부는 영국의 소트머신(Thought Machine), 10x 등과 함께 3세대 클라우드 코어뱅킹을 대표한다. 하지만 화려한 성공 스토리와 컴포저블이라는 매력적인 마케팅 용어 이면에 숨겨진 기술적, 전략적 실체는 무엇일까? 코어뱅킹의 진화를 조금 안다는 입장에서 맘부의 전략을 분석해 봤었다. (과거 22년에 쓴 자료 인데, AI가 없던시절 고생해서 작성 ㅎ) . 참고로 코어뱅킹 진화 관련해서는 석사과정학생에 논문지도를 했었고, 그 학생은 Publish까지 했지만, 내이름이 논문에 있으면 안되는 사정이 있어서 논문소개는 내가 자유인이 되었을때 이야기 해야 겠다.

대서양의 작은 섬에서 시작된 따뜻한 마음

맘부의 혁신적인 아이디어는 대서양 포르투칼 마데이라 제도(Madeira Island)에 위치한 카메기멜론 (CMU) 포르투갈 분교에서 처음 싹을 텄다. 당시 HCI(사람-컴퓨터 상호작용) 석사 과정 동기였던 유진 다니엘키스, 프레데릭 피스터러, 소피아 누네스 3인은 졸업 프로젝트의 연구 대상으로 모잠비크의 마이크로파이낸스 시장을 선택했다.

연구 과정에서 영세 금융기관들이 낙후되고 비싼 소프트웨어 비용 때문에 포용 금융을 확산시키는 데 어려움을 겪는 현실을 목격했다. '저렴한 비용으로 안정적인 금융 플랫폼을 제공하자'는 비전은 마데이라 섬의 강의실에서 졸업 연구 과제로 시작되었고, 이 뒤로 이 창업자 3명은 2011년 베를린으로 둥지를 옮기고, 거기에서의 창업과 오늘날의 '린 코어(Lean Core)' 철학으로 이어지는 뿌리가 되었다.

사실 이들 창업자를 면밀히 보면, 유진과 소피아는 사실 엔지니어는 아니고 프레데릭이 엔지니어 경험이 있던 사람으로 금융IT와는 조금 무관한 백그라운드를 지녔다. 쩐주인 소피아를 통해서 캐나다 백수인 유진이 리딩하고 프레데릭이 SaaS 아이디어를 합친 그렇게 출발한거로 보인다.

맘부의 Composable Banking: ‘작은 코어’가 아니라 ‘경계가 명확한 코어’

맘부의 핵심은 단순히 클라우드 기반 코어뱅킹이 아니다. 더 정확히 말하면, 맘부는 코어뱅킹을 모든 업무를 담는 거대한 시스템이 아니라, 금융 거래의 상태와 회계적 정합성을 책임지는 경량화된 금융 엔진으로 재정의했다.

전통적인 코어뱅킹은 대출, 수신, 심사, 한도, 채널, 상품, 회계, 보고, 운영 프로세스를 하나의 거대한 애플리케이션 안에 묶어두는 방식으로 진화해 왔다. 이 구조에서는 기능이 많을수록 안정성이 높아지는 것이 아니라, 오히려 변경 비용과 릴리스 리스크가 증가한다. 신상품 하나를 출시하기 위해 코어 수정, 채널 수정, 심사 로직 변경, 회계 검증, 배치 영향 분석이 연쇄적으로 발생하고, 그 결과 금융기관은 변경하지 않는 것을 안정성으로 착각하게 된다.

맘부의 코어는 고객 경험 전체를 컨트롤하는 시스템이 아니라, 계좌, 상품, 거래, 이자, 상환, 잔액, 회계분개 등 금융 상태의 원천 기록을 관리하는 시스템에 가깝다.

레거시 금융 IT사람들은 맘부의 시스템이 Toy라고 하지만, 맘부의 Lean Core는 “기능이 부족한 코어”가 아니라 코어가 반드시 책임져야 할 영역과 외부로 분리해도 되는 영역을 엄격하게 구분한 코어 다. 금융 상태의 정합성, 상품 조건, 계좌 라이프사이클, 거래 처리, 원장 반영은 코어가 책임진다. 반면 고객 온보딩, KYC/AML, 신용평가, 대출심사, 채권관리, CRM, 데이터 분석, 규제보고, 카드 발급, 결제 네트워크 연계와 같은 변화가 잦은 기능은 외부 전문 솔루션과 연결해 버린다.

즉 맘부 코어는 API를 통해 고객, 계좌, 거래, 시스템 설정, 이자율, 권한관리 등 핵심 기능에 접근할 수 있도록 했다. 이러한 API 노출이 composable banking의 핵심 전제라고 정의한다. 즉, 맘부 코어는 닫힌 업무 시스템이 아니라, 외부 애플리케이션이 금융 상태를 안전하게 읽고 변경할 수 있도록 설계된 API 기반 system of record에 가깝다고 볼수 있다.

Composable은 레고 조립이 아니라 계약 기반 아키텍처

Composable banking을 흔히 레고처럼 조립하는 방식으로 설명하지만, 조립 자체가 아니라, 조립 가능한 상태를 유지하기 위한 기술적 계약이다. (그런데 자꾸 조립가능하다고 한다.. )

맘부가 말하는 composable banking은 하나의 all-in-one 시스템에 의존하지 않고, 목적별로 선택한 독립 컴포넌트를 API로 연결하여 금융 서비스를 구성하는 접근이다. 맘부는 이를 선택, 자유, 적응성의 문제로 설명하며, 각 컴포넌트가 API를 통해 통신하고 필요에 따라 추가, 제거, 업그레이드될 수 있어야 한다고 정의한다.

맘부의 composable 메시지는 rapid, flexible, assembly, independent, best-for-purpose라는 키워드로 정리되어 있는데 이는 단순한 마케팅 용어가 아니라 기존 코어뱅킹 벤더의 “one size fits all” 접근에 대한 반대 명제로 만들었다고 볼수 있다. 하나의 벤더가 모든 기능을 제공하는 대신, 각 영역에서 가장 적합한 전문 솔루션을 선택하고 조합하겠다는 것이다.

다만 여기서 진짜 포인트는 컴포넌트를 많이 붙일 수 있다거나, 컴포넌트가 많다가 아니다. 진짜 composable architecture에 필요한 핵심 요건은 코어와 컴포넌트 사이의 책임경계, API는 단순 호출이 아닌 계약, 연결성이다. (현존하는 All in one package 회사는 맘부에서 하는 것의 정반대로 주로 한다. 모든 업무를 다 담을수 있는 시스템.. 이렇게 되어 있다고 설명들 한다)

코어와 외부 컴포넌트 사이의 책임 경계: 예를 들어 대출심사 결과는 외부 origination 솔루션에서 산출될 수 있지만, 대출계좌 개설, 상환 스케줄, 이자 계산, 원장 반영은 코어에서 일관되게 관리되어야 한다.

API는 시스템을 연결하는 기술 인터페이스를 넘어, 업무 책임을 나누는 계약과 같은 기준선이라는 개념: 예를 들어 대출 승인, 계좌 개설, 지급 요청, 상환 처리 같은 이벤트가 발생했을 때 어느 시스템이 최종 상태를 확정할지, 처리 실패나 중복 요청은 어떤 기준으로 보정할지, 거래 데이터와 회계 데이터의 불일치는 어떻게 검증할지까지 사전에 정의되어야 한다. 그래야 composable 구조가 단순한 API 연결의 집합이 아니라, 운영 가능한 금융 아키텍처로 작동할 수 있게 된다.

연결은 프로젝트성 SI가 아니라 제품화된 connector로 관리: 맘부는 연결 생태계 전략을 쓰는데 연계를 위한 connector가 중요하다.

MPO: 조립된 시스템을 하나의 업무 흐름으로 묶는 계층

맘부의 Composable 구조에서 MPO, 즉 Mambu Process Orchestrator는 외부 시스템과 Mambu Banking Engine 사이의 업무 흐름을 조율하는 역할을 한다.

맘부의 코어는 계좌, 상품, 거래, 이자, 상환, 원장처럼 금융 상태의 최종 기록을 담당한다. 반면 고객 온보딩, KYC/AML, 신용평가, 대출심사, 결제, 카드 발급 같은 기능은 외부 전문 솔루션과 연결될 수 있다. 문제는 이 기능들이 각각 따로 동작해서는 실제 금융 업무가 완성되지 않는다는 점이다.

예를 들어 대출 업무에서는 고객 온보딩, 본인확인, 신용평가, 심사 승인, 대출계좌 생성, 실행, 상환 스케줄 생성, 원장 반영이 순서대로 이어져야 한다. MPO는 이 과정에서 각 시스템의 API를 호출하고, 데이터를 전달하며, 다음 단계로 넘어갈 조건을 관리한다. 단순히 시스템을 “연결”하는 것이 아니라, 여러 시스템을 하나의 업무 프로세스로 실행되게 만드는 역할이다.

Lean Core 전략으로 코어를 가볍게 유지하려면, 코어 밖에 있는 여러 솔루션을 업무적으로 묶어주는 오케스트레이션 계층이 필요하기 때문에 MPO는 중요한 역할을 한다. 위 그림에서 MPO는 비즈니스 시스템, 프로세스, party 사이의 middle-layer API로 설명되고, workflow 모델링과 실행, API 중심의 비즈니스 프로세스 설계·유지 기능을 지원하는 것으로 정리했다. 즉, MPO는 가벼운 코어와 외부 전문 솔루션 사이의 업무 흐름을 어떻게 안정적으로 운형하는 오케스트레이션 도구이다. .

Best-of-Breed 전략의 핵심: '연결'보다 '운영 책임'의 설계

맘부가 내세우는 컴포저블 뱅킹의 가장 큰 매력은 필요한 기능을 외부 전문 솔루션으로 자유롭게 조합할 수 있다는 점이다. 고객 확인(KYC)은 전문 인증 솔루션을, 신용 평가는 특화된 스코어링 엔진을, 카드 발급과 결제는 해당 지역에 최적화된 전문 네트워크를 연동하는 식이다. 하나의 거대한 벤더 제품에 모든 것을 의존하는 대신, 업무 영역별로 '최고의 솔루션(Best-of-Breed)'을 취사선택할 수 있는 구조이다.

흔히 최적의 솔루션들을 조립하면 시스템이 단순해질 것이라 기대하지만, Best-of-Breed 전략이 곧바로 '낮은 복잡성'을 보장하지 않는다. 과거에는 코어뱅킹 내부의 거미줄 같은 커스터마이징과 하드코딩 속에 복잡성이 얽혀 있었다. 반면 컴포저블 구조에서는 코어와 외부 솔루션 사이의 인터페이스, 데이터 매핑, 장애 대응, 정합성 검증이라는 새로운 영역으로 복잡성이 이동했다. (복잡성의 위치만 바뀌었다고 본다)

맘부가 제공하는 커넥터는 단순한 API 호출 예제나 연동 가이드 문서가 아니다. 맘부의 뱅킹 엔진과 외부 기술 벤더 사이의 연결 자체를 하나의 '제품(Integration Layer)'으로 규격화한 것에 가깝다. 이를 통해 계좌 개설, 대출 실행, 결제 처리, 카드 발급 등 맘부가 직접 보유하지 않은 기능까지 고객의 니즈에 맞춰 시스템을 매끄럽게 확장할 수 있다.

금융 시스템에서 진짜 중요한 것은 데이터가 기술적으로 잘 전달되었는가가 아니라, 그 데이터가 어떤 비즈니스적 의미를 지니며, 어떤 시스템의 기록을 최종 기준(Single Source of Truth)으로 삼을 것인가 이다.

예를 들어, 외부 결제 시스템에서 처리된 내역이 맘부의 거래 원장에 반영될 때, 시스템 간 시차로 인해 결제 상태와 회계 상태의 갱신 시점이 불일치할 수 있다. 이때 고객 잔액의 기준을 어느 시점으로 볼 것인지, 회계 마감의 기준 데이터는 무엇인지, 오류 발생 시 어느 시스템에서 보정 작업을 수행할 것인지 명확한 업무 규칙이 정의되어야 한다. 하위 데이터(Downstream Data) 영역에서도 동일하게 적용된다. 코어 엔진에서 발생한 총계정원장(GL), 거래 ID, 상품 내역 등을 외부 회계 플랫폼으로 유연하게 확장할 수 있는 만큼, 회계 및 마감 기준, 데이터의 출처 추적(Data Lineage), 그리고 감사 체계를 더욱 정교하게 설계해야만 한다.

결국 컴포저블 뱅킹의 성공 여부는 얼마나 많은 솔루션을 레고처럼 붙일 수 있는가가 아니라, 연결된 수많은 솔루션들을 하나의 유기적이고 안전한 금융 시스템으로 통제할 수 있는가에 달려 있다.

고객 정보의 마스터 시스템은 어디인지, 거래 상태의 최종 승인자는 누구에게 있는지, 외부 시스템 장애 시 원장 정합성은 어떻게 보호할 것인지 빈틈없이 설계되어야 한다. 이 때문에 현지 딜리버리와 시스템 통합을 책임지는 SI 파트너와 확장 가능한 조합을 제공하는 기술 파트너의 역량이 맘부 코어 플랫폼 못지않게 중요하다.

"조립만 하면 끝난다"가 아니고 코어는 가볍게 유지하되 외부와의 연결 고리를 규격화하고, 그 결합이 실제 금융 현장의 엄격한 운영을 견뎌낼 수 있도록 '책임 구조'를 치밀하게 설계했다는점이 맘부 코어의 핵심이다.

컴포저블 뱅킹은 복잡성을 없애는 팬시한 개념이 아니라 오히려 기존에 뭉쳐 있던 복잡성을 밖으로 꺼내어 눈에 보이게 만들고, 이를 기능별로 나누어 더 똑똑하게 통제하려는 진일보한 아키텍처로 이해해야 한다.

시사점

맘부 사례가 한국 금융IT나 금융기관에 주는 메시지는 맘부 Composable 처럼 하자가 아니고, 차세대 시스템을 다시 거대한 코어로 만들지 말자이다.

한국 금융권의 차세대 프로젝트는 오랫동안 Big Bankg, rip & replace 방식에 익숙했다. 그렇게 어렵게 작업하는 것인 기존 코어를 한 번에 걷어내고, 새로운 대형 코어를 구축하고, 주변 시스템을 다시 붙이는 방식이다. 이 접근은 단기적으로는 정합성을 확보하기 쉬워 보이지만, 시간이 지나면 새로운 거대 레거시를 만드는 결과로 이어질 뿐만 아니라, 프로젝트자체도 매우 어렵고, 리스크가 크다.

맘부시스템에서 배운 교훈을 보면, 앞으로의 코어 현대화는 다르게 접근해야 하는데, 먼저 코어에 남길 영역을 정의부터 해야 한다. 계좌, 상품, 거래, 잔액, 이자, 상환, 회계, 감사추적처럼 금융 상태의 원천이 되는 기능은 강하게 통제해야 하는 반면 고객 온보딩, 심사, 채널, 마케팅, CRM, 데이터 분석, 규제보고, 외부 결제망 연계처럼 변화 속도가 빠른 영역은 모듈화하고 외부 컴포넌트와 연결 가능하게 설계가 필요하다고 생각한다.

솔루션을 판매하는 회사가 가져가야 할 차별점은 단순히 “우리도 composable하다”, "우리도 레고블록이다"가 아니라, 통합의 복잡성을 얼마나 제품화해서 줄여줄 수 있는가에 있다. 즉, connector catalogue, 표준 API 처리, 이벤트 스키마, 장애 재처리 패턴, 분산거래 보정 로직, 원장 reconciliation template, 규제보고 데이터 lineage, 운영 모니터링 체계등을 이해하고 함께 제공되는 제품이어야 하지 않을까한다.

맘부의 성공은 코어를 작게 만든 데서만 나온 것이 아니라, 코어를 작게 만든 뒤, 그 바깥의 생태계를 파트너와 connector로 확장하고, SI와 Customer Success 조직을 통해 실제 고객 환경에 배포할 수 있었기 때문에 가능했다.

그림에서 Mambu의 파트너십은 SI, Business Consultants, Technology Partners, Cloud Service Providers로 나뉘며, 현지 딜리버리, 통합 아키텍처, 제품 공동개발, 클라우드 인프라 제공의 역할을 담당한다.

결국 맘부의 composable banking에서 배워야 할 것은 “레고처럼 조립한다”는 표면적 메시지가 아닌, 핵심은 금융 코어의 책임을 좁고 명확하게 정의하고, 변화가 잦은 기능은 외부 컴포넌트와 연결 가능한 구조로 분리하며, 그 연결의 복잡성을 API, connector, orchestration, reconciliation 체계로 관리한다는 점이다.

다음 세대의 뱅킹 플랫폼 경쟁력은 코어가 얼마나 많은 기능을 품고 있는가가 아니라, 코어가 무엇을 책임지고 무엇을 책임지지 않는지 얼마나 명확히 말할 수 있는가의 코어의 본질부터 곰곰히 생각해보고, 차세대를 하건, 신규은행을 만들던, 기본 부터 생각하는게 필요하지 않을까 한다.