
2026년 10월 13일6분 분량Администратор
P2P 송금 후 누가 누구에게 빚지는가: 돈과 의무의 경로
고객 결제, 트레이더 계좌의 돈, 담보, 가맹점에 대한 채무는 어떻게 연결될까요? 거래 한 건을 모든 참여자 기준으로 따라가 봅니다.
가상의 거래로 P2P 송금 이후의 채무 관계를 따져 보겠습니다. 12:04에 고객이 10 000 화폐 단위를 송금했습니다. 트레이더는 입금을 확인하고, 운영자는 가맹점에 '결제 완료'를 보냈으며, 상점은 상품을 내주었습니다. 그러나 10 000은 여전히 수취인의 계좌에 있습니다. 이제 돈은 누구에게 있고, 누가 상점과 정산해야 하며, 트레이더가 사라질 경우 상점을 정확히 무엇이 보호할까요? 초록색 상태 하나로는 이 질문 중 어느 것에도 답할 수 없습니다.
P2P 프로세싱에서는 돈의 물리적 이동과 의무의 발생을 구분하는 것이 특히 중요합니다. 메시지는 1초 만에 전체 체인을 통과할 수 있지만, 정산은 저녁에 이루어질 수 있습니다. 그 사이 누군가는 사실상 나머지 참여자에게 신용을 제공합니다. 이 역할을 미리 정해 두지 않으면, 보통 첫 정산이 멈췄을 때에야 드러납니다.
먼저 모델을 정하자
P2P라는 이름 아래에는 서로 다른 구조가 있습니다. 거래소 플랫폼에서는 구매자와 판매자가 법정화폐와 디지털 자산을 교환하고, 플랫폼은 자체 규정에 따라 자산의 보관을 관리합니다. 라이선스를 받은 결제 프로세스에서는 참여자들이 허용된 역할로 자금을 받거나 보냅니다. 제3자 개인 계좌로 송금하는 비공식 네트워크는 고유한 법적·은행 리스크를 지닌 별개의 구조입니다. API와 담보 보증금이 있다고 그것이 허가된 결제 서비스가 되지는 않습니다.
이하에서는 가상의 투명한 대금 수납 모델을 다룹니다. 계약과 은행이 해당 운영 방식을 허용하고, 수취인이 공개되어 있으며, 운영자가 이 참여자를 쓸 권한이 있고, 고객은 송금의 목적을 알고 있습니다. '트레이더'는 계약상 이행 참여자를 가리킵니다. 그 의무는 계약으로 정해지며, 어떤 거래소 P2P 플랫폼이든 남의 상점 대금을 받는 것을 허용한다는 뜻이 아닙니다. 숫자는 구조를 설명하기 위한 것이며 특정 서비스의 요율을 나타내지 않습니다.
계좌 정보를 보여 주기 전에 첫 번째 예약이 생긴다
가맹점이 10 000짜리 주문을 생성합니다. 운영자는 주문 식별자, 통화, 금액, 유효 기간, 합의된 요율을 저장합니다. 그다음 적합한 담당자를 고르고, 허용된 결제 수단, 계좌 가용성, 한도, 담보를 확인합니다. 동시에 이 주문을 위한 용량을 예약합니다. 예약이 성공한 뒤에야 고객에게 구체적인 계좌 정보와 안내가 제공됩니다.
가맹점 수수료가 400이고, 그중 150은 트레이더가, 250은 운영자가 가져간다고 합시다. 거래가 성공하면 가맹점이 받을 금액은 9 600입니다. 트레이더의 보수를 수납한 돈에서 공제한다면, 운영자에게 보낼 금액은 9 850이 됩니다. 계약은 전체 금액 10 000 또는 다른 익스포저 기준으로 예치를 정할 수 있습니다. 이 예에서는 10 000을 택합니다. 임의의 '슬롯 하나'가 아니라 구체적인 금액을 예약하는 것입니다.
이 시점에는 아직 고객의 돈이 없습니다. 예약은 트레이더에 대한 신규 배정을 제한하지만, 결제를 증명하거나 매출을 만들지는 않습니다. 쓰이지 않은 주문은 만료될 수 있습니다. 시스템에는 발급한 계좌 정보의 흔적이 남아 있어야 합니다. 고객은 화면을 닫은 뒤에도 송금할 수 있기 때문입니다.
은행 입금 이후 서로 다른 채무가 생긴다
고객은 허용된 자기 출처에서 송금합니다. 참여자는 은행 데이터로 수령을 확인하고, 금액, 통화, 주문과의 연결을 검증합니다. 이 모델에서 운영자는 그런 확인을 거친 뒤 가맹점에 대한 의무를 인수합니다. 이는 예시의 계약 조건입니다. 다른 공급자는 자기 계좌로 돈을 받은 뒤에만 정산을 약속할 수도 있습니다.
이제 트레이더는 법정화폐 10 000을 보유하고 있으며 운영자에게 9 850을 보내야 합니다. 운영자는 가맹점에 9 600의 채무가 있습니다. 차액 250은 자체 비용 차감 전 운영자의 보수이고, 150은 담당자의 보수입니다. 운영자의 장부에는 트레이더에 대한 채권과 상점에 대한 채무가 생겼습니다. 그렇다고 운영자의 은행 계좌에 돈이 생긴 것은 아닙니다.
가맹점에 보내는 알림에는 비즈니스상의 의미가 있습니다. 합의된 규칙에 따라 결제가 인정되었으니 주문을 이행해도 된다는 것입니다. 알림 자체는 은행 송금이 아닙니다. 알림 식별자는 주문, 입금 기록, 요율 버전, 의무 인정 시점과 연결됩니다. 알림이 다시 가더라도 같은 인정을 참조해야 하며, 9 600의 채무를 하나 더 만들어서는 안 됩니다.
이 그림에서 담보는 어디에 있는가
트레이더가 미리 30 000 가치의 담보를 제공했다고 합시다. 거래 전에는 담보가 고객 수납금과 따로 관리되었습니다. 계좌 정보를 발급한 뒤 가용 용량 중 10 000이 예약되었습니다. 결제 확인이 이 예약을 반드시 해제하는 것은 아닙니다. 트레이더가 아직 수납한 법정화폐를 보유하고 있다면, 운영자에 대한 정산 리스크는 그대로이기 때문입니다.
선택한 모델에서 예약은 9 850 이체가 확인되고 나머지 해제 조건이 충족될 때까지 유지됩니다. '수령' 버튼을 누르자마자 시스템이 용량 전체를 돌려준다면, 별도의 미상환 한도 없이는 같은 담보로 아직 갚지 않은 채무를 끝없이 늘릴 수 있습니다. 이는 이미 다른 신용 모델이며, 별도의 한도와 의식적인 리스크 수용이 필요합니다.
담보는 정해진 근거가 있을 때만 의무에 충당할 수 있습니다. 이때 채무가 두 번 상환되어서는 안 됩니다. 입금된 정산 송금과 병행된 담보 차감으로 두 번 갚는 일입니다. 두 작업은 하나의 익스포저에 연결됩니다. 동결된 디지털 자산 역시 상점에 지급할 수 있는 법정화폐로 자동 간주해서는 안 됩니다.
저녁 정산이 자금 사슬을 닫는다
트레이더는 합의된 정산 경로로 9 850을 보냅니다. 운영자는 실제 입금을 원장과 대조하고, 트레이더에 대한 채권을 줄이며, 다른 보류가 없으면 해당 담보를 해제합니다. 그다음 가맹점에 9 600을 지급합니다. 지급이 확인되면 상점에 대한 의무는 종결됩니다. 운영자에게는 비용 차감 전 250이, 트레이더에게는 150이 남습니다.
운영자가 12:10에 상점에 돈을 지급하고 18:00에 트레이더의 정산을 받았다면, 그 5시간 50분은 운영자 자신의 가용 유동성이나 허용된 자금 조달원으로 메운 것입니다. 그동안 의무의 대차는 줄곧 맞았을 수 있습니다. 하지만 현금 잔액은 줄어들고 있었습니다. 그래서 "보증금으로 다 커버된다"는 말로는 일정대로 지급할 능력을 평가하기에 부족합니다.
일괄 정산에서는 은행 송금 한 건이 여러 주문, 수수료, 이전에 합의한 정정을 함께 정리할 수 있습니다. 배분은 원장의 구성 내역에 따라 합니다. 여기서 개별 고객 거래 금액과 정확히 같은 송금을 찾으면 잘못된 경보가 울리고, 전체 금액을 처음 보이는 비슷한 주문에 배분하면 나머지 주문의 잔액이 망가집니다.
다른 모델: 운용 잔액이 차감된다
선불 운용 잔액을 쓰는 구조도 있습니다. 따로 살펴봅시다. 트레이더는 운영자에 대해 1 000 USDT의 채권이 있었고, 예시를 위해 합의한 환율은 USDT당 정산 단위 100입니다. 법정화폐 10 000을 수납한 뒤 운용 잔액에서 9 850에 해당하는 98.5 USDT가 차감됩니다. 운영자에 대한 트레이더의 채권은 901.5 USDT로 줄고, 받은 법정화폐는 트레이더에게 남습니다. 가맹점에는 정산 조건에 따라 9 600이 인정되며, 운영자에게는 여전히 실제 지급을 위한 적합한 유동성이 필요합니다.
이 두 번째 모델에서는 같은 9 850을 법정화폐로 다시 보내지 않습니다. 운용 채권을 줄이는 것으로 경제적 정산이 이미 이루어졌기 때문입니다. 별도의 고정 보증 예치금을 쓸 필요도 없습니다. 두 구조를 섞으면 트레이더는 두 번 정산하게 됩니다. 이때 내부 잔액은 회사에 대한 일반 채권, 그것도 무담보 채권일 수 있습니다. 보기 좋은 화면이 자산의 분리 보관이나 즉시 출금 권리를 증명하지는 않습니다.
당사자 사이에 라우터가 있다면
기술적 중개자는 돈을 받지 않고 가맹점의 채무자가 되지도 않은 채 주문과 상태를 전달할 수 있습니다. 예를 들어 PayStar는 예상 지급액 계산을 통제 기능으로 명시하면서, 정산 의무는 직접 계약에 따라 PSP에 남겨 둡니다. 다른 체인에서는 역할을 처음부터 다시 확인해야 합니다. 패널에 로고가 여러 개 있다고 독립된 유동성 출처가 여러 개라는 뜻은 아닙니다.
첫 번째 예에서 운영자가 자기 몫 250 중 50을 이런 중개자에게 지불한다면, 기타 비용 차감 전 200이 남습니다. 상점에 대한 채무는 여전히 9 600이고, 기술 서비스에 대한 의무 50은 별도입니다. 고객 자금이 전혀 거치지 않더라도 모든 결제에 대한 메시지는 중개자를 거칠 수 있습니다. 라우팅과 데이터에 대한 그 책임이 모든 자금의 반환 보증과 같지는 않습니다.
사슬이 보통 끊어지는 세 지점
트레이더가 돈을 확인했지만 정산이 들어오지 않았다면, 트레이더의 의무가 열려 있는 것이며 계약에 정한 회수 절차나 담보 사용이 필요합니다. 운영자가 정산을 받았지만 가맹점에 지급하지 않았다면, 고객의 원래 송금이 다른 참여자를 거쳤더라도 문제는 운영자 쪽에 있습니다. 상점이 알림을 받았지만 은행 입금이 확인되지 않는다면, 먼저 잘못된 인정의 근거를 밝히고, 그다음 정정을 처리하고 책임을 배분합니다.
주문마다 하나의 일관된 답을 재구성할 수 있으면 유용합니다. 누가 고객 자금을 받았는가, 누가 어떤 근거로 결제를 인정했는가, 지금 누가 돈을 빚지고 있는가, 그 채권은 무엇으로 담보되는가, 어떤 실제 송금으로 종결되는가. 구조의 어느 구간이든 '파트너'라는 말로 대체되어 있다면, 금융 투명성은 바로 그곳에서 끝납니다.
댓글 · 0
아직 댓글이 없습니다 — 첫 댓글을 남겨 보세요.
로그인 · 댓글을 남기려면 로그인하세요.