플랫폼 아키텍처

하나의 코어, 다양한 서피스 — 플랫폼이 실제로 작동하는 방식.

원장에서 시작해 위로 올라가며 플랫폼을 살펴봅니다. 하나의 복식부기 코어를 공유하는 계정, KYC, 카드, 암호화폐, 결제 한 건이 생성부터 대사까지 이동하는 과정, 그리고 앱 레이어, 운영 콘솔, 규제 경계가 각각 어디에 위치하는지를 다룹니다.

문의하기 제품 보기

코어

모든 것의 기반이 되는 하나의 원장.

플랫폼의 중심에는 단일 계정 원장이 있습니다. 고객 지갑, 가맹점 잔액, 수수료 계정, 정산 계정 등 모든 계정은 이 원장의 노드이며, 가치의 모든 이동은 복식부기 전표로 기록됩니다. 한 계정에서 차변을, 다른 계정에서 대변을 기록하고 양쪽 금액은 항상 같습니다. 원장은 추가 전용(append-only)입니다. 항목은 수정하거나 삭제하지 않으며, 정정은 반대 방향의 새 항목으로 기록합니다. 따라서 잔액이 현재 값에 이르기까지의 전체 이력을 언제든 재구성할 수 있습니다. 계정, KYC 상태, 발급된 카드, 암호화폐 주소는 모두 동일한 계정 모델에 연결됩니다. 그래서 카드 승인, 은행 이체, 온체인 입금이 서로 다른 시스템을 이어 붙이는 대사 레이어 없이 하나의 잔액에 반영됩니다.

01복식부기: 모든 전표의 차변과 대변이 일치
02추가 전용: 정정은 수정이 아닌 새 항목으로 기록
03법정화폐, 카드, 암호화폐를 아우르는 단일 계정 모델
04KYC 상태는 별도 테이블이 아닌 계정과 함께 이동

결제의 처음부터 끝까지

결제 한 건, 생성부터 대사까지.

결제는 하나의 호출이 아니라 짧은 라이프사이클이며, 각 단계는 원장과 고객 시스템이 모두 확인할 수 있는 상태입니다. 모든 상태 변경은 웹훅을 발생시키고 모든 쓰기는 멱등합니다. 같은 키로 다시 요청해도 같은 결과가 반환되므로 재시도한 요청이 이중 청구되지 않습니다.

01
생성
인텐트가 열립니다. 금액, 통화, 관련 계정이 지정됩니다. 아직 이동한 자금은 없으며, 원장에는 보류 항목이 기록됩니다.
02
승인
레일이 잔액과 리스크를 확인하고 홀드를 설정합니다. 카드는 승인이 이에 해당하고, 이체는 출금액이 예약됩니다.
03
캡처
홀드된 금액이 확정됩니다. 원장은 두 계정 사이에서 실제로 가치를 이동시키는 복식부기 전표를 기록합니다.
04
정산
자금이 카드 브랜드 네트워크, 은행, 체인 등 기반 레일을 통해 청산되고, 정산 계정이 실제 자금과 일치하게 됩니다.
05
대사
플랫폼이 자체 전표를 레일의 정산 리포트와 대조합니다. 일치하지 않는 항목은 숨기지 않고 표시합니다.

웹훅과 멱등성은 이 흐름의 모든 접점에 적용됩니다. 시스템은 폴링이 아니라 이벤트를 받아 결제가 이동했음을 알게 되며, 타임아웃 후 재시도한 요청은 멱등성 키를 통해 항상 같은 결과로 처리되므로 반복 요청이 이중 청구되지 않습니다. 승인과 캡처를 실행하는 서비스는 바로 결제 게이트웨이.

앱 레이어

위에는 화이트라벨 앱, 아래에는 하나의 플랫폼.

코어는 기능을 제공하고, 앱 레이어는 이를 제품으로 만듭니다. 웹과 모바일의 모든 고객용 앱은 화이트라벨 클라이언트로, 동일한 계정, 결제, 카드를 각자의 브랜드로 보여줍니다. 테마는 토큰 기반입니다. 색상, 타이포그래피, 라운드, 간격이 디자인 토큰 시스템(PDS)에서 정의되므로, 운영사는 앱을 포크하지 않고 토큰만 바꿔 전체 화면의 스타일을 변경할 수 있습니다. 하나의 플랫폼으로 소비자 네오뱅크, 가맹점 매입 앱, 카드 발급 프로그램, 암호화폐 온/오프램프, 내부 운영 도구까지 서로 다른 방향을 지향할 수 있으며, 다섯 개의 별개 제품이 되지 않습니다. 하나의 플랫폼이 다른 스킨을 입는 것이며, 각각 새로 만드는 것이 아니라 설정으로 구성합니다.

01공통 API 기반의 화이트라벨 웹·모바일 클라이언트
02토큰 기반 테마(PDS): 포크 없이 설정으로 스타일 변경
03다섯 가지 예시 방향 — 네오뱅크, 매입, 발급, 램프, 운영
04새 서피스는 새로 만들지 않고 설정으로 구성

운영

콘솔에서 운영하고, 사유는 기록으로 남깁니다.

모든 앱의 뒤에는 운영 콘솔이 있습니다. 지원 담당자가 계정을 조회하고, 리스크 분석가가 카드를 동결하며, 운영 책임자가 전표를 취소하는 곳입니다. 조회 권한은 넓지만 특권 작업은 그렇지 않습니다. 자금을 이동하거나, 한도를 변경하거나, 고객 자금에 영향을 주는 작업은 실행 전에 사유를 명시해야 하며, 누가, 무엇을, 언제, 왜 했는지가 변경 불가능한 감사 기록으로 남습니다. 접근은 최소 권한 원칙을 따르므로 운영자는 자신의 역할이 허용하는 범위만 보고 실행할 수 있습니다. 이것이 운영 콘솔인 Protocore Center의 모델이며, 플랫폼의 모든 시스템에 같은 원칙이 적용되어 있습니다. 민감한 작업은 의도적이고, 주체가 특정되며, 사후에 검토할 수 있습니다.

01넓은 조회, 제한된 쓰기 — 특권 작업은 예외
02자금에 영향을 주는 모든 작업에 사유 필수
03변경 불가능한 감사 추적: 누가, 무엇을, 언제, 왜
04운영자 역할별 최소 권한

암호화폐 브리지

같은 원장 위의 암호화폐와 법정화폐.

플랫폼에서 암호화폐는 별도의 사일로가 아닙니다. 암호화폐 주소도 같은 원장의 또 다른 계정일 뿐입니다. 온/오프램프는 경계에서 법정화폐와 디지털 자산을 상호 변환합니다. 고객은 카드나 이체로 잔액을 충전해 암호화폐를 받거나, 암호화폐를 매도해 은행 계좌로 출금할 수 있습니다. 온체인 가치는 은행 레일까지 정산될 수 있습니다. 들어온 온체인 결제는 계정에 입금되고 환전된 뒤 IBAN으로 지급되므로, 수취인은 일반 은행 계좌에서 일반 자금을 확인합니다. 두 구간이 하나의 복식부기 원장에 기록되므로, 온체인에서 시작해 은행 이체로 끝나는 거래는 수작업으로 맞추는 두 시스템이 아니라 하나의 대사된 이력으로 남습니다.

01암호화폐 주소도 다른 계정과 같은 계정
02온/오프램프: 경계에서 법정화폐와 디지털 자산 변환
03온체인 정산부터 IBAN 지급까지
04두 구간을 아우르는 하나의 대사된 이력

빌드 서피스

API, 웹훅, 그리고 개발용 샌드박스.

앱이 하는 모든 일은 문서화된 API로 수행됩니다. 계정 생성, 결제 개시, 카드 발급, 램프 시작 모두 마찬가지입니다. 예시 호출은 POST /v1/wallets 또는 POST /v1/payments와 같은 형태이며, 구조는 REST이고 모든 쓰기 요청에 멱등성 키가 적용됩니다. 상태 변경은 웹훅으로 전달되므로 시스템이 폴링하지 않고 이벤트에 반응합니다. 개발은 샌드박스 테넌트에서 진행합니다. 테스트 레일을 갖춘 플랫폼의 격리된 복사본으로, 실제 자금을 이동하지 않고 생성부터 대사까지 전체 흐름을 실행할 수 있습니다. 각 제품이 어떤 기능을 어느 티어에서 제공하는지는 액세스 밴드로 정해지며, 제품별 페이지에서 해당 밴드의 포함 범위를 확인할 수 있습니다.

01문서화된 REST API, 멱등성 보장 쓰기
02모든 상태 변경에 웹훅 제공 — 폴링 없는 이벤트 기반
03운영 환경과 격리된 테스트 레일 샌드박스 테넌트
04제품별 액세스 밴드로 범위와 한도 설정

솔직한 경계

Protocore는 소프트웨어를 만듭니다. 규제 영역은 라이선스가 담당합니다.

결제 제품은 두 가지가 결합된 것입니다. 자금을 보유하고 이동할 수 있는 규제상의 허가, 그리고 이를 지시하고 기록하며 대사하는 소프트웨어입니다. Protocore는 소프트웨어를 만듭니다. 고객 자금 보유, 계정 발급, 카드 브랜드 네트워크를 통한 자금 이동 같은 규제 대상 활동은 운영사 자신의 라이선스 또는 은행, EMI, 결제기관과 같은 라이선스를 가진 파트너가 담당합니다. 플랫폼은 고객이 준비한 어떤 규제 레일에도 맞도록 설계되었고, 카드 데이터를 레일에 두어 고객의 서버에 닿지 않게 합니다. 하지만 이 허가를 대체할 수는 없으며, 어떤 소프트웨어도 마찬가지입니다. 규제 경계를 어디에 둘지는 파트너와 함께 결정할 사안이며, 아키텍처는 그 경계의 어느 쪽에도 깔끔하게 놓이도록 설계되어 있습니다.