하나의 코어, 여러 앱: 화이트라벨 뱅킹 플랫폼의 작동 방식

화이트라벨 뱅킹 플랫폼은 프런트 엔드를 교체할 수 있는 하나의 뱅킹 코어입니다. 코어는 정확해야 하는 부분입니다. 복식부기 원장, 고객 계좌, KYC와 온보딩, 카드 발급 및 처리, 암호화폐와 스테이블코인 레일, 그리고 이 모두를 뒤에서 운영하는 오퍼레이터 콘솔이 여기에 속합니다. 앱은 고객이 보는 부분으로, 이름과 색상, 화면 구성, 켜 둔 기능의 조합이 해당합니다. 화이트라벨이란 하나의 코어가 여러 얼굴을 갖되, 얼굴마다 코어를 다시 만들지 않는다는 뜻입니다. 하나의 코어, 여러 앱.

쉽게 말해, 이음매를 어디에 두느냐에 관한 주장입니다. 돈과 닿는 모든 것은 공유되고, 감사받고, 한 번만 대사됩니다. 고객과 닿는 모든 것은 테넌트별로 설정됩니다. 중요한 엔지니어링은 이 경계를 지키는 일입니다. 프런트 엔드는 자유롭게 달라지되, 그 아래의 코어는 절대 포크되지 않아야 합니다. 이 글은 그 경계를 어떻게 긋는지, 그리고 포크가 아니라 디자인 토큰으로 긋는 편이 왜 나은지 분해해서 설명합니다.

달라지지 않는 것: 코어

창의성이 허용되지 않는 쪽부터 보겠습니다. 앱이 송금, 결제, 지급 중 무엇이라 부르든 거래는 똑같이 기록됩니다. 복식부기 원장에 두 개의 항목이 남고, 삭제되는 것은 없습니다. 원장에는 추가만 가능하므로 환불은 원본을 참조하는 반대 항목이지 삭제가 아닙니다. 계좌, 잔액, 승인 보류(authorization hold)가 여기에 있습니다. KYC와 온보딩, 카드 발급과 정산, 암호화폐와 스테이블코인 레일도 마찬가지입니다. 그 뒤에는 하나의 오퍼레이터 콘솔이 있으며, 모든 권한 작업에는 사유가 필수이고 감사 로그에 기록됩니다.

이들은 각각 정확히 하나뿐이며, 바로 그 점이 핵심입니다. 정산, 대사, 컴플라이언스는 제대로 구현하기 어렵고 잘못되면 비용이 큽니다. 그래서 한 번만 만들고 모든 앱이 그 결과를 물려받게 합니다. 테넌트가 고객을 온보딩하면, 어느 앱의 화면에서 서류를 받았든 코어가 판정한 KYC 등급이 그대로 콘솔까지 따라갑니다. 코어는 위에 올라간 앱의 이름을 알지도, 신경 쓰지도 않습니다. 코어가 보는 것은 브랜드가 아니라 계좌와 항목입니다.

달라지는 것: 디자인 언어, 정보 구조, 기능 구성

코어 위의 모든 것은 세 가지 축으로 자유롭게 달라집니다. 첫째는 디자인 언어로, 색상, 타이포그래피, 모서리 반경, 간격, 모션 등 브랜드의 시각 문법입니다. 둘째는 정보 구조입니다. 홈 화면에 무엇을 두는지, 흐름의 이름과 순서를 어떻게 정하는지, 어떤 동작을 한 번의 탭으로 하고 어떤 동작을 세 번의 탭으로 하는지가 여기에 속합니다. 셋째는 기능 구성으로, 어떤 모듈을 켜는지입니다. 간결한 송금 앱과 기능이 빽빽한 슈퍼 앱이 동일한 코어에서 돌면서 화면은 하나도 공유하지 않을 수 있습니다.

/products/pay 제품 페이지에서는 다섯 가지 방향을 실제 사례로 보여 줍니다. 다섯 개 중에서 고르는 메뉴라기보다, 무수히 많은 가능성 가운데 몇 가지 예로 보시는 편이 좋습니다. Halcyon은 깔끔한 거래소로, 절제된 화면 수에 거래가 전면에 놓입니다. Lumen은 대화 안에서 돈이 오가는 슈퍼 앱으로, 채팅 결제, 구독, 이자(earn)가 홈 화면을 함께 씁니다. Fern은 송금이 중심이며 일괄 지급과 규칙 기반 환전이 먼저 나옵니다. Volt는 스테이블코인 중심의 다크 테마로, 급여 분류기와 팀 카드를 갖추었습니다. Meridian은 다중 통화 앱입니다. EUR 계좌 옆에 USDC가 있고, GBP 여행 잔액과 카드 리워드가 쌓이는 BTC 계좌가 있습니다. 다섯 개의 브랜드, 다섯 개의 정보 구조, 다섯 개의 기능 구성이지만, 그 아래에는 하나의 원장, 하나의 KYC, 하나의 카드 프로세서가 있습니다.

그렇다고 이 제품이 다섯 개의 앱이라는 뜻은 아닙니다. 다섯 개는 같은 파이프라인이 취할 수 있는 방향일 뿐이며, 중요한 숫자는 다섯이 아니라 온보딩하는 테넌트의 수입니다. 각각은 홈 화면의 모양까지 프런트 엔드가 달라질 수 있어도 그 아래의 코어는 전혀 영향을 받지 않는다는 증거입니다.

코어는 새로 발명해서는 안 되는 부분이고, 앱은 제약해서는 안 되는 부분입니다. 화이트라벨 플랫폼이란 이 두 문장을 동시에 참으로 유지하는 규율입니다.

코드베이스 포크보다 토큰 수준 테마가 나은 이유

하나의 제품을 여러 개처럼 보이게 하는 방법은 두 가지입니다. 흔한 방법은 포크입니다. 고객마다 코드베이스를 복사해 스타일을 바꾸고 출시합니다. 이 방식은 딱 한 번의 릴리스까지만 통합니다. 그 뒤로는 모든 버그 수정과 규제 변경을 서로 달라져 가는 N개의 복사본에 N번 적용해야 하고, 복사본들은 점점 어긋나며, 따져 봐야 할 보안 범위는 고객 수만큼 늘어납니다. 포크는 이해하고 있던 하나의 시스템을 이해할 수 없는 여럿으로 바꿔 놓습니다.

토큰 수준 테마는 이를 뒤집습니다. 코드베이스는 하나입니다. 브랜드는 값의 집합입니다. 색상, 타이포그래피, 반경, 간격 토큰과 컴포넌트 설정, 기능 플래그 세트가 빌드 시점에 브랜드 앱으로 확정됩니다. 토큰 하나를 바꾸면 그 토큰을 읽는 모든 화면이 함께 바뀝니다. 토큰에서 가져와야 할 값을 하드코딩하는 곳이 없기 때문입니다. 송금 흐름의 수정은 모든 테넌트에 한꺼번에 배포됩니다. 고칠 송금 흐름이 하나뿐이기 때문입니다. 브랜드는 소스가 아니라 설정에서 서로 다릅니다.

디자인 시스템의 위치

토큰은 막연한 개념이 아니라 실제로 배포되는 산출물입니다. Protocore Design System(/products/pds)은 144개의 디자인 토큰과 889개의 유틸리티 클래스로 구성되며, 모든 앱의 테마를 이루는 어휘입니다. 다크 우선, 토큰 기반이며 기본 반경은 0입니다. 같은 토큰 세트가 웹, .NET, 네이티브용으로 출력되므로, 한 번 정의한 색상은 React 화면, 데스크톱 콘솔, 네이티브 모바일 빌드에서 모두 같은 색상을 뜻합니다. 테넌트의 브랜드는 이 어휘에 대한 오버라이드로 표현되기 때문에, 앱의 스킨을 바꾸는 일은 재작성이 아니라 설정 변경입니다.

그래서 프런트 엔드는 템플릿 안에서만 자유로운 것이 아니라 진정으로 자유롭습니다. 디자인 언어가 일회성 스타일시트가 아니라 토큰과 유틸리티 클래스에 있기 때문에, 디자이너는 코어를 건드리거나 앱을 포크하지 않고도 테넌트를 기준 빌드에서 멀리 벗어나게 할 수 있습니다. 고유한 팔레트, 타이포그래피, 밀도, 리듬까지 가능합니다. 도장은 깊게 하되 어디까지나 도장일 뿐이고, 그 아래의 배관은 공유됩니다.

앱은 빌드가 아니라 설정입니다

기능 구성도 같은 원칙을 따릅니다. 채팅 결제, 이자, 암호화폐, 카드, 구독, 팀 카드, 추천 등 모든 모듈은 테넌트별로 켜고 끄는 스위치이며, 플래그는 전체 공개 전에 일부 사용자에게만 먼저 적용할 수 있습니다. 오퍼레이터는 배포가 아니라 설정 패널에서 이를 전환합니다. 그래서 최소한의 송금 앱과 풀 슈퍼 앱의 차이는 두 개의 프로젝트가 아니라 하나의 프로젝트에 대한 두 가지 설정입니다. 모든 테넌트가 출발점으로 삼는 기준 앱은 Protocore 브랜드의 중립적인 빌드이며 전체 메뉴를 갖추고 있습니다. 각 화이트라벨은 이 빌드에서 토큰을 오버라이드하고 모듈을 켜거나 끈 것입니다.

솔직한 경계

하나의 코어, 여러 앱 구조는 실제로 앱이 여러 개일 때, 또는 하나의 앱을 은행을 다시 만들지 않고 시간에 따라 스킨, 구성, 범위를 바꿔 가며 운영할 때에만 그만한 장치를 들일 가치가 있습니다. 두 번째 브랜드를 입을 일이 없는 고정된 앱 하나를 출시한다면 화이트라벨 플랫폼이 아니라 앱이 필요합니다. 이 구조가 제값을 하는 것은 설계 목적에 맞는 경우입니다. 테넌트마다 브랜드 뱅킹 상품을 연달아 세우고, 각각이 분명히 고유하며, 어느 것도 포크가 아닌 플랫폼입니다. 다섯 가지 방향, 기준 앱, 그 뒤의 오퍼레이터 콘솔까지 담은 전체 분석은 /products/pay에, 그 아래의 디자인 시스템은 /products/pds에 있습니다.