여유 한도 하나에 주문 두 건: 트레이더 용량은 어떻게 배분되는가

가상의 요청 경합 상황으로 트레이더 용량 문제를 살펴보겠습니다. 14:00:00에 두 개의 처리 스레드가 같은 여유 잔액 12 000을 읽었습니다. 각각 8 000짜리 주문을 받아 '돈이 충분한가'라는 조건을 확인하고 고객에게 계좌 정보를 내주었습니다. 따로 보면 두 결정 모두 옳아 보였습니다. 그러나 합치면 가용 용량 12 000에 대해 16 000의 의무가 생겼습니다.

이것이 반드시 트레이더의 사기나 은행 잔액 반영 지연 때문인 것은 아닙니다. 잔액 확인과 예약을 서로 독립된 두 작업으로 나누기만 해도 충분히 생깁니다. 주문들이 충분히 가까운 간격으로 들어오기 전까지 시스템은 겉보기에 정상적으로 작동합니다. P2P 흐름에서는 계좌 정보 발급, 실제 송금, 입금 확인 사이의 시간이 이런 오류를 키웁니다.

용량은 여러 제약으로 이루어진다

주문에는 금액, 통화, 결제 수단, 이행 기한이 있습니다. 트레이더에게는 가용 담보 또는 운용 정산 잔액, 허용된 계좌, 동시 주문 한도, 운영 가능 상태가 있습니다. 개별 계좌에는 자체 허용 금액, 은행의 제한, 이미 사용 중인 규모가 적용됩니다. 운영자는 참여자 한 명과 연관된 담당자 그룹 전체에 대해 계약상 추가 한도를 둘 수 있습니다.

이 중 어느 것도 다른 것을 대신하지 못합니다. 보증금이 크다고 은행 한도를 넘을 수 있는 것은 아닙니다. 은행 잔액에 여유가 있다고 선불 정산 잔액이 새 수납을 인정하기에 충분하다는 뜻은 아닙니다. 카운터상 주문 하나를 더 받을 수 있더라도, 이용 가능한 유일한 채널이 해당 통화를 지원하지 않으면 소용이 없습니다.

하나의 동질적인 거래 범주에서 금전적 용량은 가장 빡빡한 금전 제약에 묶입니다. 그러나 동시 주문 카운터와 허용 금액 범위는 별도의 조건으로 남습니다. 서로 다른 통화의 잔액을 그냥 합치거나, 빈 슬롯 두 개가 크기와 상관없이 결제 두 건을 자동으로 수용한다고 보아서는 안 됩니다. 각 한도의 기간도 명시해야 합니다. 달력상 하루, 이동 구간, 근무조, 또는 계약 기간 전체입니다.

Sprut 패널에 대한 공개 영상 리뷰에서 작성자는 최소·최대 금액, 거래 카운터, 계좌 총한도를 따로 보여 줍니다. 이 장면에서는 뒤의 두 항목의 기간이 확인되지 않습니다. 이런 시연은 패널 설명에 개별 설정이 있다는 것을 보여 줄 뿐, 은행의 허가, 서버 측 검증의 정확성, 실제 처리 능력을 증명하지는 않습니다.

결정과 동시에 자원을 점유해야 한다

12 000 예시에서 첫 번째 8 000짜리 주문이 예약을 받으면 가용 금액은 4 000이 됩니다. 두 번째 주문은 이미 바뀐 상태를 기준으로 확인되므로 통과하지 못합니다. 원자적 예약의 의미가 바로 이것입니다. 확인과 상태 변경이 하나의 나눌 수 없는 결정으로 기록됩니다. 그 결과에는 예약 식별자, 금액, 소유자, 유효 기간이 포함됩니다.

결제 원장은 이런 보호를 여러 방식으로 구현합니다. 예를 들어 Modern Treasury 문서는 최종 잔액이나 계정 버전을 조건으로 하는 기록을 설명합니다. PostgreSQL은 경합하는 변경을 관리하기 위한 행 잠금을 제공합니다. 이것들은 기술적 메커니즘일 뿐 완성된 P2P 정책이 아닙니다. 팀은 여전히 어떤 자원들이 함께 바뀌는지, 어떤 이벤트에서 예약이 해제되는지를 정해야 합니다.

배정이 트레이더 잔액, 계좌 잔여 한도, 슬롯 하나를 동시에 점유한다면 일부만 실행되는 것은 위험합니다. 자금 예약은 기록했는데 배정을 잃으면 한도가 묶입니다. 주문은 만들었는데 잔액을 줄이지 않으면 과다 배정이 생깁니다. 하나의 일관된 트랜잭션 안에서 이 변경들은 함께 일어나거나 아예 일어나지 않습니다. 여러 시스템이 관련된다면 명시적인 중간 상태와, 필요한 예약이 확인되기 전에는 계좌 정보를 내주지 않는 복구 절차가 필요합니다.

요청 재시도가 두 번째 몫을 가져가서는 안 된다

가맹점이 응답을 받지 못해 생성 요청을 다시 보냈습니다. 논리적 주문이 같다면 운영자는 기존 예약을 찾거나 그 생성을 안전하게 마무리해야 합니다. 새 네트워크 요청이 왔다는 것만으로 같은 트레이더에게 새 주문을 만들 이유는 없습니다. 그렇지 않으면 구매자 한 명이 슬롯 여러 개를 차지하고, 한 번만 결제하려 했는데도 계좌 정보 세트를 여러 개 받게 됩니다.

배정 결과가 불확실한 경우는 특히 골치 아픕니다. 담당자에게 메시지는 전달됐지만 확인 응답이 사라졌을 수 있습니다. 상황이 밝혀지기 전까지 자원을 다른 주문에는 비어 있고 첫 주문에는 점유된 것으로 동시에 볼 수는 없습니다. 시스템은 시도 식별자를 저장하고, 실제 상태를 확인하고, 하나의 결정을 내립니다. 이 확인에는 담당자와 시간 제한이 있어야 합니다. 그렇지 않으면 대기열이 영원한 '거의 배정됨'으로 가득 찹니다.

운영자는 묶여 있는 예약을 정상 부하와 따로 봅니다. 여기에는 경과 시간, 사유, 마지막으로 확인된 사실, 다음 복구 시도가 중요합니다. 타이머에 따른 해제는 이미 발급된 계좌 정보에 대해 이후 무엇을 할지가 분명한 만큼만 안전합니다. 예약이 만료되었다고 고객이 이미 보낸 송금이 취소되지는 않습니다.

슬롯은 비웠지만 리스크는 남았다

주문이 14:10에 만료되어 예약을 해제했는데, 14:12에 은행 입금이 감지되었다고 합시다. 여유 한도가 없다고 해서 돈의 기록이 사라지지는 않습니다. 이 건은 예외로 넘어갑니다. 출처와 목적지를 확인하고, 의무를 정하고, 리스크 배분을 올바르게 복구합니다. 결정이 나기 전까지 해당 참여자에 대한 신규 배정을 중단해야 할 수도 있습니다.

잘못된 해결책은 늦게 들어온 돈을 운영자 수익으로 잡거나, 같은 금액의 다음 주문에 자동으로 연결하는 것입니다. 올바른 해결책은 원래의 계좌 정보 발급과의 연결을 유지합니다. 지연 입금을 위한 별도의 대기 구간을 둔다면, 그 비용을 미리 점유 모델에 포함합니다. 그렇지 않으면 한도를 빨리 해제하는 '최적화'는 리스크를 수동 대기열에 숨길 뿐입니다.

보증금은 여유를, 속도는 회전을 만든다

가상의 처리 능력을 계산해 봅시다. 사용 가능한 담보가 300 000, 일반적인 주문이 10 000, 동시 운영 슬롯이 12개입니다. 주문을 확인까지 처리하는 데 평균 8분이 걸립니다. 슬롯 제약으로는 이론상 시간당 90건의 배정이 가능합니다. 12에 60을 곱하고 8로 나눈 값입니다. 금액이 같다면 다른 제약 전 기준으로 시간당 900 000의 흐름입니다.

그런데 계약상 담보는 정산까지, 평균 40분 동안 묶입니다. 그러면 300 000의 담보는 쉬지 않고 가동할 때 시간당 약 450 000의 회전을 지탱합니다. 300 000에 60을 곱하고 40으로 나눈 값입니다. 운영 슬롯은 더 받을 수 있지만 담보가 더 느리게 돌아옵니다. 이는 꾸준하고 고른 흐름에 대한 추정이지 성능 약속이 아닙니다.

은행 채널의 일일 허용량 잔여분이 1 200 000이라면, 이 속도로도 약 2시간 40분이면 소진됩니다. 보증금을 늘려도 은행 한도는 바뀌지 않습니다. 정산 시간이 80분으로 늘어나면, 연결된 트레이더 수가 그대로여도 담보 제약 때문에 추정치는 시간당 225 000으로 떨어집니다.

업무 화면에서 봐야 할 것

유용한 용량 화면은 거절 사유를 설명합니다. 담보, 운용 잔액, 출금 유동성, 채널 허용량, 빈 슬롯, 또는 참여자의 확인된 가용성 중 무엇이 부족한지입니다. 그 옆에 예약의 경과 시간과 실제 해제 시각이 보입니다. 뭉뚱그린 '계좌 정보 없음'은 전혀 다른 결정이 필요한 원인들을 가립니다.

제약은 동시 배정, 요청 재시도, 단계 사이의 장애, 지연 입금, 정산 기간 전환 상황에서 검증해야 합니다. 목표는 계약과 은행 규칙의 범위 안에서 허용된 흐름을 처리하는 것입니다. 금액 쪼개기나 불투명한 계좌 바꿔치기로 제약을 우회하는 것은 용량 모델을 바로잡지 못하고 새로운 리스크만 만듭니다. 좋은 시스템은 제때 새 주문을 거절하면서도 이미 받은 주문은 끝까지 처리할 줄 압니다.