화이트라벨 네오뱅크 플랫폼 구매 가이드

화이트라벨 네오뱅크 플랫폼은 코어를 처음부터 만들지 않고도 자사 브랜드를 입혀 계좌, 카드, 송금, 때로는 암호화폐까지 갖춘 뱅킹형 앱을 출시할 수 있는 소프트웨어입니다. 이를 도입하는 일은 사실 하나로 착각하기 쉬운 두 가지를 사는 일입니다. 돈을 움직이는 코어와 고객이 보는 앱 레이어입니다. 이 가이드는 계약 전에 둘을 구분하는 방법을 다룹니다. 화이트라벨 플랫폼에 대한 어려운 질문은 거의 모두 경계가 어디에 있느냐는 질문으로 귀결되기 때문입니다. 공급사는 그 경계를 흐리게 하고, 구매자는 그것을 찾아내야 합니다.

결정하기 전에 나눠 볼 기준은 다섯 가지입니다. 코어와 앱 레이어, 라이선스의 위치, 디자인 시스템의 깊이, 독립형과 임베디드 제공 방식, 그리고 이 모든 것의 밑바탕에 있는 구축 대 도입 판단입니다. 순서대로 살펴보겠습니다.

첫 번째 기준: 코어와 앱 레이어

가장 유용한 구분선은 정확해야 하는 부분과 자사만의 것이어야 하는 부분 사이에 있습니다. 코어는 잘못되면 비용이 큽니다. 복식부기 원장, 계좌와 잔액, KYC와 온보딩, 카드 발급과 처리, 암호화폐와 스테이블코인 레일, 그리고 이 모두를 뒷받침하는 운영자 콘솔이 여기에 속합니다. 앱 레이어는 고객이 만지는 부분입니다. 브랜드, 화면, 정보 구조, 활성화한 기능 구성입니다. 구매할 만한 플랫폼은 모든 브랜드가 하나의 코어를 공유하고 앱은 테넌트별로 구성합니다. 두 영역은 평가 기준이 다릅니다. 코어는 정확성으로 판단합니다. 원장이 진짜 복식부기인지, 대사가 맞아떨어지는지, 운영자가 실제로 운영할 수 있는지를 봅니다. 앱 레이어는 유연성으로 판단합니다. 포크가 필요해지기 전까지 브랜드가 얼마나 달라질 수 있는지를 봅니다.

라이선스의 위치, 그리고 분리 가능 여부

돈을 보관하거나 이동할 수 있는 권한은 규제 대상이며, 소프트웨어 구매와는 별개입니다. 플랫폼이 규제 허가를 포함하는지, 아니면 직접 확보해 오길 기대하는지 분명히 물어야 합니다. 포함한다면 누구의 라이선스인지, 어느 국가인지, 그리고 자사가 그 라이선스 보유자의 직접 고객인지 대리인인지 확인해야 합니다. 구매자에게 중요한 것은 분리 가능성입니다. 소프트웨어를 교체할 수 없는 단일 라이선스에 묶어 둔 플랫폼은 관할권과 파트너를 조용히 대신 정해 버린 셈이고, 라이선스를 직접 가져오는 레일로 다루는 플랫폼은 허가를 독립적으로 고르고 나중에 바꿀 수 있게 합니다. 어느 쪽도 틀리지 않았지만, 어느 쪽을 사는지는 알아야 합니다. Protocore Pay(/products/pay)는 소프트웨어 레이어만 제공하며, 고객이 준비한 규제 레일 위에서 동작합니다. 어떤 소프트웨어도 라이선스가 될 수는 없습니다. 이 논의에서 마주칠 EMI, 결제기관, 에이전트, 스폰서 뱅크 같은 개념은 /glossary에 정리되어 있습니다.

디자인 시스템의 깊이

화이트라벨의 약속은 앱이 공급사 데모의 리스킨이 아니라 자사의 것처럼 보인다는 것이며, 이 약속은 그 밑의 디자인 시스템만큼만 깊습니다. 얕은 시스템은 로고와 포인트 컬러를 바꾸는 정도입니다. 깊은 시스템은 색상, 타이포그래피, 모서리 반경, 간격, 밀도, 모션이라는 실제 어휘를 모든 화면이 읽는 토큰으로 제공하므로 브랜드가 포크가 아니라 오버라이드의 집합이 됩니다. 토큰이 몇 개이고 무엇을 다루는지, 같은 토큰이 웹, 네이티브, 데스크톱으로 출력되어 한 색이 어디서나 같은 색인지, 디자이너가 코드를 건드리지 않고 테넌트를 기준 빌드에서 멀리 벗어나게 할 수 있는지 물어보십시오. Protocore의 디자인 시스템(/products/pds)은 그 한 가지 답입니다. 토큰 144개와 유틸리티 클래스 889개, 다크 우선, 기본 반경 0이며 웹, .NET, 네이티브용으로 출력됩니다. 다만 구매자의 질문은 보다 일반적입니다. 디자인 레이어가 진짜 토큰 시스템인지, 고정된 앱 위에 칠한 페인트에 불과한지입니다.

독립형 앱인가, 임베디드 레이어인가

제공 방식은 두 가지입니다. 독립형 앱은 자사 브랜드로 자사 이름 아래 출시하는 완전한 뱅킹 앱입니다. 고객은 자사의 은행을 내려받습니다. 임베디드 레이어는 이미 운영 중인 제품에 넣는 컴포넌트와 플로우의 묶음입니다. 결제와 잔액이 기존 앱 안에서 동작합니다. 선택 기준은 품질이 아니라 금융 경험이 어디에 있어야 하느냐입니다. 뱅킹이 제품 자체라면 독립형 빌드가 맞습니다. 뱅킹이 더 큰 제품의 기능이라면, 예를 들어 판매자에게 정산하는 마켓플레이스나 사용자에게 지갑을 제공하는 플랫폼이라면 임베디드 방식이 맞으며, 돈이 고객이 이미 있는 곳에 놓입니다. 구매할 만한 플랫폼은 하나의 코어로 둘 다 지원합니다. 코어는 프런트엔드가 독립형 앱인지 다른 제품 안의 패널인지 신경 쓰지 않기 때문입니다.

구축 대 도입의 득실, 솔직하게

코어를 직접 구축하면 통제권을 얻는 대신 수년이 듭니다. 정확한 원장, 카드 처리, KYC, 대사, 운영자 콘솔은 각각 하나의 프로젝트이며, 고객이 체감하는 기능을 단 하나 출시하기 전에 넘어야 하는 기본 요건입니다. 코어를 도입하면 그 수년을 아끼는 대신 주권을 일부 내줍니다. 계좌, 한도, 정산에 대한 남의 모델을 물려받게 됩니다. 솔직한 판단 방법은 어느 부분이 자사의 제품이고 어느 부분이 배관인지 묻는 것입니다. 정산, 대사, 컴플라이언스 도구 같은 배관은 누구에게나 거의 같고 승부처가 되는 경우도 드무니 사서 쓰십시오. 고객이 실제로 자사를 선택하는 이유가 되는 플로우, 브랜드, 기존 사업자보다 잘하는 한 가지에는 자사 엔지니어가 전력을 쏟아야 합니다. 플랫폼 도입은 코어가 배관이고 차별화는 그 위에 있다는 데 거는 베팅입니다.

네오뱅크를 사는 것이 아닙니다. 배관이길 바라는 코어와 자사의 것으로 만들 앱 레이어를 사는 것이며, 평가의 전부는 공급사가 그 선을 자사가 그었을 자리에 그었는지 판단하는 일입니다.

다섯 개의 제품이 아니라 다섯 개의 방향

공급사에 사례를 요청하면 완성된 앱 몇 개를 보여 주는 경우가 많습니다. 이를 올바르게 읽어야 합니다. 그것은 고르는 메뉴가 아니라 같은 코어가 취할 수 있는 방향입니다. 한 플랫폼의 레퍼런스 코어는 깔끔한 거래소(Halcyon — 절제된 디자인, 거래가 전면에), 채팅 중심 슈퍼앱(Lumen — 대화 안에서 돈이 움직임), 송금 중심 앱(Fern — 일괄 지급과 규칙 기반 환전이 우선), 스테이블코인 다크 빌드(Volt — 급여 분류기와 팀 카드), 다중 통화 계좌(Meridian — USDC 옆의 EUR 잔액, 카드 리워드가 쌓이는 BTC 계좌)를 모두 받쳐 줄 수 있습니다. 브랜드 다섯, 정보 구조 다섯, 기능 구성 다섯이지만, 그 밑에는 하나의 원장, 하나의 KYC, 하나의 카드 프로세서가 있습니다. 중요한 숫자는 다섯이 아니라 코어가 감당할 수 있는 테넌트의 수입니다. 제품이 앱 다섯 개라고 말하는 공급사는 자사 제품을 오해한 것이고, 여섯 번째가 쉽다는 것을 증명하려고 다섯 개를 보여 주는 공급사는 제대로 이해한 것입니다.

벤더를 가려내는 질문들

짧은 질문 목록만으로도 대부분의 영업 피치를 걸러낼 수 있습니다. 코어가 하나의 공유 시스템인가, 고객마다 갈라진 포크인가? 버그를 수정하면 그 수정이 모든 테넌트에 동시에 반영되는가? 디자인 레이어가 실제 토큰을 제공하는가, 아니면 로고 슬롯만 있는가? 플랫폼에 규제 허가가 포함되어 있는가, 아니면 직접 확보해야 하는가? 그리고 나중에 교체할 수 있는가? 같은 코어로 독립형 앱과 임베디드 레이어를 모두 제공할 수 있는가? 어떤 부분을 기반 인프라로 보고, 어떤 부분을 직접 구축하라고 하는가? 이 답변들은 이 가이드가 그려온 지도 위에 벤더의 위치를 잡아 줍니다. 공유 코어인가 포크 농장인가, 토큰 시스템인가 덧칠인가, 소프트웨어와 제 라이선스의 결합인가 일체형 번들인가, 제공 형태가 하나인가 둘인가. 이러한 코어 하나를 완전히 해부한 내용, 즉 다섯 가지 방향, 레퍼런스 앱, 그 뒤의 운영자 콘솔은 /products/pay에, 그 밑바탕의 디자인 시스템은 /products/pds에, 용어 정의는 /glossary에 있습니다.