모든 브로커는 결국 자신만의 모바일 앱을 요구하게 됩니다. 그 이유는 충분히 타당합니다. 고객은 휴대폰으로 생활하고, 플랫폼 벤더의 앱에는 다른 사람의 로고가 붙어 있으며, 트레이더의 홈 화면에 브랜드 아이콘 하나를 올리는 것만으로도 가치가 있기 때문입니다. 그러다 프로젝트가 Apple의 심사팀을 만나면 일정은 두 배로 늘어납니다.
여기서 실제 옵션이 무엇인지, 앱이 무엇을 해야 하는지, 그리고 어떤 경우 제출이 거절되는지 살펴보겠습니다.
트레이딩 앱을 귀사 이름으로 만드는 세 가지 방법
첫 번째 옵션은 아예 만들지 않는 것입니다. 고객은 플랫폼 벤더의 앱을 다운로드해 귀사의 서버를 선택하면 됩니다. 이 방법은 비용이 들지 않고, 스토어 리스크도 없으며, 브랜딩은 전혀 제공하지 않습니다. 소규모 포트폴리오를 가진 신규 브로커리지라면 첫해에는 종종 가장 적절한 선택입니다.
두 번째는 플랫폼 벤더가 제공하는 화이트 라벨 모바일 앱을 귀사 명의로 출시하는 방식입니다. 여러 플랫폼 제공업체가 이를 지원합니다. 검증된 트레이딩 터미널에 귀사의 이름과 색상을 입힐 수 있고, 대신 등록 절차, 심사 과정, 업데이트 주기를 함께 떠안게 됩니다. 초기 구축 비용은 낮지만, 지속적인 의무는 실제로 존재합니다.
세 번째는 귀사의 CRM과 트레이딩 API 위에 구축하는 커스텀 앱입니다. 이 방식만이 고객이 한곳에서 필요한 모든 일을 처리하게 해줍니다. 회원가입, 서류 업로드, 계좌 입금, 새 트레이딩 계좌 개설, 그리고 차트 옆에서 잔액 확인까지 가능합니다. 동시에 구축 비용이 가장 높고, 모든 거절 책임을 온전히 떠안는 유일한 방식이기도 합니다.
세 번째 옵션에 대해 솔직해질 필요가 있습니다. 대부분의 브로커에게 트레이딩 터미널은 차별화 요소가 아닙니다. 차트에 민감한 트레이더는 이미 MetaTrader나 cTrader를 설치해 두었고, 캔들 차트의 ‘귀사 버전’으로 옮겨갈 이유가 없습니다. 실제로 고객이 체감하는 진짜 고유한 영역은 계좌 영역입니다. 그래서 많은 커스텀 앱은 온보딩, 입금, 계좌 관리를 처리하고 실제 트레이딩 화면은 플랫폼 앱에 넘깁니다.
앱이 차트 표시 외에 해야 하는 일
기능이 자꾸 늘어나는 것이 이 프로젝트를 망치므로, 다음 항목 중 버전 1에 포함할 것을 초기에 정해야 합니다.
- 등록 및 로그인, 이상적으로는 웹 클라이언트 영역과 공유되어 고객이 두 개의 계정을 따로 관리하지 않아도 되는 구조.
- 휴대폰 카메라를 활용한 서류 업로드. 모바일 온보딩이 데스크톱 온보딩보다 전환율이 높은 가장 큰 이유입니다.
- 입금 및 출금, 해당 지역에서 실제로 사용하는 로컬 결제수단 포함.
- 계좌 목록, 잔액, 레버리지, 플랫폼 자격 정보.
- 증거금 수준, 서류 승인, 결제 상태에 대한 푸시 알림.
이 목록은 앱 형태의 trader’s room 을 설명하는 것이며, 바로 그런 형태여야 합니다. 동일한 데이터가 이미 웹 포털을 구동하고 있다면, 모바일 빌드는 플랫폼 프로젝트가 아니라 인터페이스 프로젝트입니다. 모바일 개발자는 CRM API 를 대상으로 개발하게 되며, 아무도 Swift 코드를 한 줄 쓰기 전에 그 API가 목록의 모든 항목을 노출하는지 확인할 가치가 있습니다. Prop firm도 내용은 다르지만 비슷한 목록을 갖습니다. 해당 화면은 challenge dashboard 로서, 규칙 진행 상황, 드로다운, 지급 상태를 보여주기 때문입니다.
푸시는 별도로 짚고 넘어갈 가치가 있습니다. 많은 경우 앱을 굳이 만드는 이유 자체가 푸시이기 때문입니다. 이는 트레이더에게 받은편지함과 경쟁하지 않고 도달할 수 있는 유일한 채널이기 때문입니다. 증거금 경고, 인증 승인, 입금 실패 알림은 고객이 실제로 원하는 알림이며, 별도의 아무도 관리하지 않는 도구가 아니라 CRM이 이미 사용하는 동일한 notification system 에서 발송되어야 합니다.
Apple 심사 통과하기
이 분야의 거절 사유 대부분은 네 가지 가이드라인으로 설명됩니다.
- Guideline 3.2.1(viii)을 가장 먼저 읽어야 합니다. Apple의 문구는 다음과 같습니다. “Apps used for financial trading, investing, or money management should be submitted by the financial institution performing such services and must have necessary licensing and permissions in the locations where you make them available.” 실제로는 개발자 계정이 면허를 보유한 법인 명의여야 하고, 계정상의 이름이 라이선스 명칭과 일치해야 하며, 제공 국가도 실제로 권한을 보유한 지역과 맞아야 한다는 뜻입니다. 개발 대행사가 귀사를 대신해 제출하는 앱은 거절을 부르기 쉽습니다.
- Guideline 4.3(b)은 “이미 널리 이용 가능한 것과 구별되지 않는” 앱을 다룹니다. 같은 트레이딩 터미널의 브랜드 변형은 이 경계선에 매우 가깝기 때문에, 잘 알려진 플랫폼의 브로커별 복제본은 오랫동안 어려운 길이었습니다. 방어 논리는 귀사의 앱이 일반 앱이 하지 못하는 일을 한다는 점이며, 이것이 또 다른 차트 화면보다 계좌 영역을 만드는 쪽이 더 낫다는 이유이기도 합니다.
- Guideline 4.2는 내용이 빈약한 앱을 걸러냅니다. 제출물이 클라이언트 포털을 웹뷰로 감싼 수준이고 네이티브 요소가 없다면, 앱이 모바일 사이트 대비 무엇을 더하는지 질문받을 가능성이 높습니다. 카메라 기반 문서 촬영, 생체 로그인, 푸시 알림이 보통의 답이며, 심사 메모에서 약속할 것이 아니라 제출 전에 실제로 있어야 합니다.
- Guideline 5.1.1은 어떤 데이터를 수집하는지, 어떻게 사용하는지, 누구와 공유하는지, 사용자가 자신의 데이터를 어떻게 삭제하는지 명시한 개인정보 처리방침을 요구합니다. Apple은 앱 내부에서 계정 삭제가 가능하기를 기대하기도 합니다. 기록 보관 의무가 있는 규제 대상 브로커라면 이에 대해 실질적인 답변이 필요하며, 보통은 앱 계정 삭제와 법적으로 보존해야 하는 항목 및 보존 기간에 대한 명확한 설명이 함께 필요합니다.
심사 기간을 줄이는 실무 팁 두 가지는, 자금과 미결 포지션이 있는 계정의 데모 자격 증명을 심사자에게 제공하고, 흐름을 짧게 보여주는 화면 녹화 영상을 첨부하는 것입니다. KYC 관문을 통과하지 못하는 심사자는 확인하려 하기보다 거절합니다.
Prop firm의 인앱 결제 문제
Prop firm에는 추가적인 문제가 있습니다. Guideline 3.1.1은 기능이나 콘텐츠 잠금을 해제하는 경우 인앱 구매를 요구하며, 이를 위해 자체 결제 방식을 사용하는 것을 명시적으로 금지합니다. 챌린지 수수료가 디지털 콘텐츠에 해당하는지는, 플로우를 만든 뒤가 아니라 만들기 전에 답을 받아야 하는 질문입니다. 수수료 차이가 단가 구조를 바꿀 정도로 크기 때문입니다.
대부분의 운영사가 사용하는 안전한 패턴은 챌린지 구매는 웹에서 유지하고, 앱에서는 트레이더가 이미 보유한 계정의 표시와 관리만 수행하는 것입니다. 외부 결제로 연결하는 Apple 규정은 최근 몇 년 동안 여러 차례 변경되었고 지역별로도 다르므로, 2년 전 블로그 글이 아니라 현재의 가이드라인 원문을 읽으십시오. 이 글도 예외는 아닙니다.
Google Play
Play는 일반적으로 더 빠르지만 자체 서류 절차가 있습니다. 금융 기능이 있는 모든 앱은 Play Console에서 Financial features declaration을 작성해야 하며, Financial Services 정책은 국가에 따라 추가 요건을 부과합니다. 일부 시장에서는 라이선스 문서도 필요합니다. 최초에는 솔직하게 선언서를 작성해야 하며, 거절 후 수정하는 것보다 처음 심사하는 것이 훨씬 빠릅니다.
또한 개인정보처리방침과 일치하는 완료된 데이터 보안 섹션이 필요하며, 제품에 변경 사항이 없더라도 매년 기술 업데이트를 강제하는 Google의 대상 API 수준 요구사항도 염두에 두어야 합니다.
스토어 문구를 쓰기 전에 확인해볼 또 한 가지는: 복잡한 투기성 금융 상품에 대한 광고 규정상 양쪽 스토어와 광고에서 트레이딩을 어떻게 설명할 수 있는지 제한된다는 점입니다. 수익을 암시하는 스크린샷은 제재를 받는 확실한 방법입니다.
출시가 아니라 2년 차 예산을 잡으세요
개발 견적은 작은 숫자일 뿐입니다. 매년 새로운 OS 릴리스, Android의 의무적인 API 수준 상향, 플랫폼 벤더의 SDK 업데이트, 그리고 각각에 대한 검토 주기가 찾아옵니다. 유지보수 예산이 전혀 없는 앱은 약 18개월 안에 작동을 멈추며, 애초에 앱을 만들지 않는 것보다 브랜드에 더 큰 피해를 줍니다.
유지보수 항목에 예산이 배정되지 않는다면, 솔직한 답은 앱이 아니라 반응형 고객 영역입니다. 잘 설계된 모바일 웹 포털 은 휴대폰에서 온보딩, 자금 입금, 계정 관리를 처리하고, 대부분의 기기에서 웹 푸시를 지원하며, 스토어 승인이 필요 없고, 원할 때 언제든 업데이트를 배포할 수 있습니다.
어떻게 결정할까
고객 영역 트래픽 중 모바일 비중이 얼마나 되는지, 그리고 그 세션에서 무엇을 하는지 살펴보세요. 대부분이 잔액 확인과 입금 진행이라면 앱이 도움이 되고 범위도 명확합니다. 수요가 영업팀에서 나오고 잠재 고객에게 보여줄 무언가를 원한다면, 브랜드 웹 포털이 훨씬 적은 비용으로 같은 역할을 합니다.
직접 개발한다면 계정 영역을 먼저 출시하고, 수치가 타당성을 뒷받침할 때 거래 화면을 나중에 추가하세요. 고객들은 더 나은 차트를 원해서 앱을 요구하는 경우가 거의 없습니다. 그들은 돈과 문서를 한 번의 탭으로 확인하고 싶어서 요청하며, 이는 우리가 트레이더가 실제로 브로커에게서 원하는 것을 검토할 때 본 패턴과 맞아떨어집니다.
모바일 고객 경험에 대한 상담 요청하기
브로커리지나 Prop Firm에 가장 적합한 모바일 전략을 선택하는 데 전문가의 안내를 받아보세요. 네이티브 앱, 브랜드 Trader Room, 반응형 웹 포털 중 어떤 것이 귀사의 비즈니스, 고객 기대치, 운영 요구사항에 가장 잘 맞는지 평가해 드립니다.
함께 현재 고객 여정을 검토하고 장기적인 확장성과 유지보수성을 고려한 모바일 전략을 수립해 드립니다.
