한 플랫폼에서 여러 브랜드를 운영해야 하나요?
Kenmore의 Regions 아키텍처를 통해 브로커사는 백오피스를 건드리지 않고도 새로운 브랜드를 런칭하고, 포지셔닝을 테스트하며, 오디언스를 마이그레이션할 수 있습니다. 운영 방식에 대해 저희에게 문의해 주세요.
다중 브랜드. 하나의 CRM. 마이그레이션 없음.
고객은 탄탄한 동남아시아 소매 Forex 브로커로, 지역 트레이더 기반을 대상으로 합니다. 다만 트레이더의 대부분이 단일 국가에 집중되어 있는데, 등록 고객 중 거의 97%가 한 개의 본국 시장에서 유입됩니다. 그 외에는 이 지역 내 다른 국가에 거주하는(이주) 트레이더들이 긴 꼬리(tail)처럼 분포합니다. 고객의 인수(acquisition) 모델은 IB(Introducing Broker) 중심입니다. 대략 10명 중 7명은 Introducing Broker 파트너십을 통해 가입하며, 단 하나의 최상위 IB가 플랫폼에서 완료된 전체 예치금 거래의 약 3분의 1을 이끌었습니다.
이 고객이 Kenmore와 처음 인연을 맺은 수년 전, 이미 Forex 사업을 운영하고 있었고 빠르게 테스트하고 싶었던 시장 공략용 신(新) 브랜드의 속도에 맞춰줄 수 있는 플랫폼을 찾고 있었습니다. 한 번에 끝나는(원샷) 배포는 원하지 않았습니다. 시장 진출(go-to-market) 가설이 발전할 때마다 백오피스를 매번 새로 플랫폼화(re-platforming)하지 않고도, 트레이딩 브랜드를 손쉽게 스핀업(spin up), 리네임(rename), 선셋(sunset), 재출시(re-launch)할 수 있는 인프라가 필요했습니다.
이 고객을 위한 최초 Trader’s Room 및 CRM 배포는 계약서 체결부터 실제 운영 시스템까지 약 3주가 소요됐습니다. 이번 납품에는 MetaTrader에 연결된 Trader’s Room, 다중 티어(multi-tier) IB 모듈, 결제 애그리게이터로서 NinjaCharge 연동, 영업 및 지원 라우팅을 위한 맞춤 워크플로우가 포함된 CRM, 다국어 지원, 그리고 실시간 채팅 레이어가 포함되었습니다.
이번 케이스 스터디의 데이터셋을 기준으로 처음으로 가동된 첫 번째 지역 브랜드는 분석 기간의 1개월 차 초반에 라이브에 들어갔습니다. 2개월 차에는 인덱스 성장 측정을 위한 기준선(baseline)으로 사용하는 임계치를 월별 예치금 규모가 이미 넘어섰습니다. 3개월 차에는 그 규모가 기준선의 거의 20배로 늘었습니다. 8개월 차에는 68배까지 도달하며 운영상 피크를 기록했습니다.
Kenmore의 CRM은 고객이 성장 전략 전반의 핵심 레버로 활용하던 개념을 기반으로 구축되어 있습니다. 바로 Regions입니다. Region은 동일한 백오피스 위에 올라가지만, 플랫폼의 완전히 격리된 완전한 브랜드 단위 슬라이스입니다. 각 Region에는:
통합되는 것은 운영 코어입니다. 즉, 하나의 관리자 팀, 하나의 리포팅 레이어, 하나의 티켓팅 시스템, 하나의 IB 계층 구조, 하나의 KYC 파이프라인이 유지됩니다. 고객은 “새 브랜드를 원한다”와 “첫날부터 운영팀이 생산적으로 일할 수 있게 하고 싶다” 사이에서 선택할 필요가 없었습니다.
이 브로커의 경우, 이는 대부분의 기업이 랜딩 페이지를 테스트하듯 브랜드 아이덴티티를 시험해볼 수 있게 해주었고, 실제로 그렇게 했습니다. 전반적인 관계 속에서 고객은 Kenmore의 플랫폼에서 6개의 서로 다른 지역 브랜드를 운영했습니다. 그중 2개 브랜드가 이 케이스 스터디 데이터의 대상입니다. 하나는 런칭을 주도한 기본 브랜드이고, 다른 하나는 고객이 약 10개월 후에 의뢰해 서로 다른 포지셔닝을 테스트하기 위해 만든 후속 브랜드입니다.
고객은 라이브 및 데모 계정 개설, KYC 문서 업로드, 예치금 및 출금 요청, 그리고 개인 정보 및 계정 이력에 대한 트레이더의 셀프 서비스까지 처리하는 Trader’s Room이 필요하다고 우리에게 요청했습니다. 이 모든 기능은 CRM과 연결되어, 유입되는 활동을 올바른 담당 직원에게 라우팅하도록 구성되어야 했습니다. 우리는 약 3주 만에 임베디드 CRM이 포함된 New Edition Trader’s Room을 제공했습니다. 운영 피크 시점에는 별도의 티켓 도구 없이도 시스템이 월 1,100건이 넘는 내부 작업을 처리했습니다. 예를 들어 등록 승인, KYC 심사, 예치금 확인, 출금 승인, 그리고 IB 계정 오픈 등이었습니다.
고객의 트레이더는 MT에서 실행합니다. 이번 참여에서 각 Region은 각자 고유한 MT 트레이딩 서버에서 동작하며, 독립적으로 구성됩니다. 고객이 두 번째 Region을 추가하고자 했을 때, 두 브랜드가 백오피스는 공유하더라도 트레이딩 인프라를 공유하지 않도록 별도의 MT 서비스 연결을 프로비저닝했습니다. 계정 유형, 레버리지 티어, 그룹 네이밍 규칙은 Region별로 적용됩니다.
IB 프로그램은 고객의 주요 인수 채널입니다. 활동 중인 트레이더의 거의 7명 중 10명은 IB 또는 서브-IB에 의해 유입된 것으로 집계됩니다. Kenmore는 Day 1부터 기존 다중 티어 IB 계층 구조를 새로운 플랫폼으로 마이그레이션했습니다. 여기에는 리퍼럴 URL 추적, 티어별 커미션 규칙, 수익 공유 옵션, 그리고 Trader’s Room 내부의 “My IBs / My Traders” 분석 화면이 포함되었습니다. 시스템은 단일 IB 계보(라인리지)가 두 Regions 모두를 아우르도록 구성되었으며, 고객은 브랜드 간 커미션 추적을 조각내는 것을 원하지 않았습니다.
NinjaCharge는 고객의 결제 애그리게이터입니다(PSP 위에 올라앉는 라우팅 레이어이며, 그 자체는 PSP가 아님). 우리는 NinjaCharge 뒤에 로컬 통화 결제 경로(local-currency rails) 기준으로 30개 이상 PSP 엔드포인트를 연동했습니다. 주로 본국 시장을 위한 VND가 사용되었고, 이 지역의 다른 국가 고객을 위한 MYR, THB, IDR, BTC 구성도 추가되었습니다. PSP 가시성은 Region별로 제어됩니다. 두 번째 Region은 첫 번째 Region과는 별개로, 자체 큐레이션된 PSP 세트로 런칭되었기 때문입니다. 30개가 넘는 연동 엔드포인트 중 약 3분의 2는 특정 시점에 Trader’s Room에서 공개되어 있으며, 나머지는 예비로 보관됩니다.
예치금은 NinjaCharge를 통해 흐르며, 자동 콜백 처리로 진행됩니다. 트레이더는 Trader’s Room에서 실시간 상태를 확인할 수 있습니다. 출금은 CRM에서 태스크 기반 수동 승인 워크플로우로 처리되며, 고객이 요청한 맞춤 검증 규칙(잔액 확인, 통화 환전 방지 가드, PSP별 수취인 이름 검증)이 적용됩니다. 모든 예치 및 출금 이벤트는 CRM 작업을 생성하고, 올바른 담당 운영 팀으로 라우팅되며, 트레이더의 계정 이력으로 다시 반영됩니다.
CRM은 6개 언어를 지원하도록 구성되어 있으며, Trader’s Room과 이메일 템플릿 모두에서 언어별 문구를 해당 언어 그대로 유지했습니다. 지오(Geo) 기반 언어 감지로 인해 트레이더가 첫 방문 시 사이트를 올바른 언어로 전환합니다.
고객은 IB 커미션 흐름의 일부로, 그리고 프로모션 캠페인을 위해 보너스 및 크레딧 운영을 사용합니다. 플랫폼은 예치금과 동일한 작업 및 승인 파이프라인을 통해 라우팅되는 잔액 조정 기능을 지원합니다.
각 Region에는 로고, 컬러 팔레트, 헤더, 푸터, 폰트, 그리고 맞춤 테마 CSS까지 포함된 자체 브랜드 그래픽이 제공됩니다. 이 데이터셋의 두 Region은 시각적으로 서로 다른 정체성을 갖고 있습니다. 어느 한 Region에 착륙한 트레이더는 자신이 동일한 기반 CRM을 사용하고 있다는 사실을 알 방법이 없습니다.
프로젝트 전반에 걸쳐 표준 모듈 제공과 나란히 지속적인 맞춤 개발 스레드가 진행되었습니다. 고객은 표준 제품에 포함되지 않은 특정 요구 사항을 가지고 있었고, Kenmore는 수정과 개선을 일반적인 며칠 단위의 주기로 신속히 처리했지, 몇 주가 걸리지 않았습니다. 개발 로그의 예시는 다음과 같습니다.
맞춤 개발 주기가 고객이 여러 해 동안, 그리고 여러 브랜드 반복에도 불구하고 플랫폼을 계속 사용하게 된 이유 중 하나입니다. 고객의 GTM(Go-to-market)이 진화할 때, 플랫폼은 분기가 아니라 며칠 만에 적응합니다.
분석 기간의 10번째 달 무렵 — 첫 번째 지역이 여전히 피크에 가까운 예금 물량을 게시하던 때 — 고객은 두 번째 지역을 의뢰했습니다. 요구 사항은 간단했습니다. 별도 브랜드, 별도 도메인, 별도 MT 서버, 별도 PSP 세트. 다만 같은 팀이 같은 CRM에서 관리하는 구조로요. 고객은 6주를 원했고, 실제로 6주가 걸렸습니다. 세부 내역은 다음과 같습니다:
12번째 달 초에 두 번째 지역은 첫 트레이더 등록을 시작했습니다. 14번째 달까지는 월간 신규 등록에서 첫 번째 지역과 동등한 수준에 도달했습니다. 18번째 달에는 두 번째 지역이 첫 번째 지역보다 더 많은 예금 물량을 처리하고 있었습니다. 20번째 달에는 첫 번째 지역을 종료했고, 두 번째 지역이 모든 신규 비즈니스(등록, 예금, 계정) 100%를 담당하게 되었습니다. 전환은 플랫폼 교체 없이, 데이터 마이그레이션 없이, 운영자 재교육 없이 이루어졌습니다. 동일한 CRM, 동일한 관리자 팀. 단지 다른 지역이 켜졌을 뿐입니다.
이는 지역(Regions) 아키텍처가 가능하게 하려는 일을 보여주는 전형적인 사례입니다. 고객의 브랜드 전략(brand thesis)은 진화했지만, 운영은 그에 맞춰 바뀌지 않아도 됐습니다.
분석 기간의 2번째 달(중요한 예금 활동이 있는 첫 달)을 인덱스 기준 1×로 사용했습니다:
| 기간 | 예금 물량 인덱스 | 비고 |
|---|---|---|
| 1월 | 0.04× | 소프트 런치 |
| 2월 | 1.00× | 기준선 |
| 3월 | 19.67× | 첫 IB 코호트 가동 |
| 4월 | 31.09× | |
| 5월 | 32.51× | |
| 6월 | 33.63× | |
| 8월 | 68.36× | 운영 피크(첫 번째 지역) |
| 10월 | 33.39× | 예금 건수 기준 피크(한 달 227건) |
| 11월 | 13.30× | 첫 번째 지역이 식어감; 두 번째 지역 의뢰 |
| 14월 | 6.86× | 두 번째 지역 라이브 |
| 17월 | 8.38× | 두 번째 지역이 첫 번째를 추월 |
| 18월 | 24.33× | 두 번째 지역이 이를 감당 |
| 20월 | 42.90× | 두 번째 지역의 자체 피크; 첫 번째 지역 종료 |
플랫폼은 바닥 아래의 어떤 것도 바꾸지 않고, 두 가지 서로 다른 브랜드에서 두 번의 뚜렷한 성장 파동을 흡수했습니다.
두 지역은 퍼널 특성에서 측정 가능한 차이를 보입니다:
| 지표 | 첫 번째 지역 | 두 번째 지역 |
|---|---|---|
| IB 귀속 비중 | 70.5% | 61.0% |
| 예금 전환(등록 → 예금) | 17.5% | 31.4% |
| 예금자당 평균 예금 건수 | 6.4 | 5.5 |
두 번째 지역은 첫 번째 지역보다 등록된 트레이더를 예금자로 전환하는 비율이 거의 2배에 가깝습니다. 동일한 기본 CRM, 동일한 운영 팀, 동일한 PSP 레이어 — 하지만 서로 다른 브랜드, 서로 다른 획득 믹스, 서로 다른 트레이더 행동입니다. 이는 고객의 브랜드 반복(brand-iteration) 전략이 실제로 작동하고 있었다는 명확한 신호로 읽힙니다.
분석 전체 기간 동안 총 출금 요청 금액은 완료된 입금액 대비 약 1.34:1의 USD 환산 비율에 해당합니다. 입금과 출금은 서로 다른 통화로 표시되며 서로 다른 운영 워크플로우를 통해 처리된다는 점에 유의하세요. 즉, 입금은 PSP 집계기(aggregator)를 통해 자동으로 처리되고, 출금은 수동 승인 대기열을 거칩니다. 따라서 이 비율은 “해당 플랫폼이 특정 기간 동안 트레이더에게 지급된 금액이 그들이 입금한 금액보다 약간 더 높은 수준으로, 양방향 자금 흐름을 균형 있게 유지했다”고 해석하는 것이 가장 적절합니다. 이는 IB가 주도한 소매 외환 책의 건전한 유지(리텐션) 현황을 보여줍니다.
제1년 말 운영 피크 시점에 CRM은 월 1,100건이 넘는 내부 작업을 처리하고 있었습니다. 등록 승인, KYC 검토, 입금 확인, 출금 승인, IB 계정 오픈, 지원 티켓 — 이 모든 것이 하나의 워크플로우 엔진을 통해 라우팅되었습니다. 동일한 엔진이 전환 이후 지역(Region)에서는 더 작고 안정적인 처리량으로 계속해서 작업을 처리하고 있습니다.
이 참여는 Kenmore의 Regions 아키텍처가 무엇을 위한 것인지에 대한 가장 명확한 실증입니다. 핵심은 “우리는 CRM을 출시했다”가 아닙니다. 대부분의 CRM 벤더는 CRM을 출시할 수 있습니다. 핵심은 이겁니다:
출시까지의 속도.클라이언트의 첫 번째 Region은 계약 후 약 3주 만에 가동에 들어갔습니다. 두 번째 Region — 별도의 MT 서버에서 별도의 PSP 세트를 사용하는 완전히 분리된 브랜드 — 역시 킥오프부터 QA 완료까지 약 6주 만에 가동에 들어갔습니다.
플랫폼 재구축 없이 브랜드를 개선.클라이언트의 시장 진출(go-to-market) 전략이 발전했을 때, 그들은 이전으로 마이그레이션하지 않았습니다. 그들은 Region을 추가하고 이를 단계적으로 확장한 뒤, IB와 트레이더가 이동하면서 기존 Region은 자연스럽게 종료되도록 했습니다. 데이터 마이그레이션도 없고, 운영자 재교육도 없었으며, 다운타임도 없었습니다.
여러 브랜드를 아우르는 하나의 운영 팀.동일한 CRM, 동일한 관리자 인력, 동일한 워크플로우, 동일한 KYC 파이프라인이 두 개의 Region을 동시에 지원했습니다. 그리고 더 넓은 관계 전반에서도 6개를 지원해 왔습니다.
지속적인 커스텀 개발 주기.플랫폼의 표준 제품이 바로 그대로 완벽히 들어맞을 필요는 없습니다. 커스텀 검증기(custom validators), 지역(Region)별 워크플로우, 고정 통화 환율 핸들러(fixed-currency-rate handlers), PSP 전용 수취인(payee) 로직, 그리고 긴 꼬리 형태의 수많은 소규모 개선 사항들이 며칠 단위의 주기로 제공되었습니다. 클라이언트는 수년간 커스텀 가치가 누적(compounding)되도록 만들어 왔습니다.
부하 상황에서의 운영 확장.해당 플랫폼은 한 Region에서 월간 입금 볼륨이 68배(68×)로 상승하는 것을 흡수한 뒤, 다른 Region에서도 거의 피크에 가까운 별도의 상승을 동시에 처리했습니다. 공유 인프라를 기반으로 진행했으며, 그 사이에 아키텍처 재작업은 없었습니다.
이것이 외환 브로커가 CRM을 고정된 배포물로 보지 않고, 브랜드-반복(iteration) 플랫폼으로 보기 시작할 때의 모습입니다.
| 지표 | 값 |
|---|---|
| 운영 타임-투-라이브(첫 번째 Region) | ~3주 |
| 두 번째 Region의 타임-투-라이브 | ~6주 |
| 피크 월간 입금 볼륨 vs 기준선 | 68× |
| 두 번째 지역의 피크 vs. 기준선 | 43× |
| 활성 지역 브랜드는 단일 CRM에서 운영됩니다 | 6+ (더 넓은 관계 전반 기준) |
| NinjaCharge를 통해 통합된 구분된 PSP 엔드포인트 | 30+ |
| 지원 언어 | 6 |
| MT 트레이딩 서버 연결 | 2 (지역당 1개) |
| IB 귀속 고객 비중 | ~70% |
| 이메일 확인 전환율 | ~89% |
| KYC 승인 전환율 | ~33% |
| 등록 → 예치 전환 | ~19% 전체 (~31% 두 번째 지역) |
| 예치자 1인당 평균 완료 예치 건수 | 6+ |
| 출금 대비 예치(USD 상당) 비율 | ~1.34:1 |
| 전환 기간 동안 동일 CRM에서 동시 운영되는 지역 수 | 2 |
| 지역 전환: 데이터 마이그레이션 없이 브랜드 교체 | ✓ |
Kenmore의 Regions 아키텍처를 통해 브로커사는 백오피스를 건드리지 않고도 새로운 브랜드를 런칭하고, 포지셔닝을 테스트하며, 오디언스를 마이그레이션할 수 있습니다. 운영 방식에 대해 저희에게 문의해 주세요.
다중 브랜드. 하나의 CRM. 마이그레이션 없음.