멀티풀 라우팅은 정말 장애에 강한가: 2,642회 실측
견적 2,642회를 집계했습니다. 89.6%는 경로가 하나뿐이었고, 두 번째 경로는 코리도별 최소 금액을 넘어야 나타납니다. 실제로 주문을 살리는 것은 주문 생성 단계의 페일오버입니다. 모든 숫자는 실측입니다.
'애그리게이션'은 확인 가능한 숫자이지 구호가 아닙니다. 2026-10-25 08:57부터 11-01 종료까지 견적 엔진은 2,642회의 가격 제시를 기록했습니다. 그중 2,366회(89.6%)는 경로가 정확히 하나, 275회(10.4%)는 둘, 셋은 단 1회였습니다. 같은 엔진, 같은 주에 답이 크게 다릅니다. 한 줄 요약입니다. 중복성은 '사이트의 속성'이 아니라 '코리도와 금액의 속성'입니다. 그래서 이 글은 애그리게이터의 가치를 논하지 않고, 두 번째 경로가 실제로 무엇을 사는지, 언제 나타나고 언제 도움이 안 되는지를 측정합니다. (모네로 확인 대기)
스왑은 네 곳에서 실패하고, 라우팅은 앞의 두 곳만 건드립니다. 견적에서 실패하거나(아무도 이 페어에 가격을 주지 않음), 주문 생성에서 실패하거나(풀이 페어·주소 형식·금액 범위를 거부), 정산에서 실패하거나(입금은 확인됐는데 지급이 멈춤), 그저 느리거나(모두 정상, 네 시간 뒤 도착). 라우팅은 견적·생성 단계의 장치입니다. 100 USDT가 이미 입금 주소에 있고 풀이 조용해진 뒤에는 두 번째 풀이 소급해서 도울 수 없습니다. 자금은 이미 단일 거래상대방에게 맡겨졌습니다. 그래서 멀티풀 프런트엔드를 정직하게 읽는 방법은 '시작하지 못할 확률을 낮추는 것이지, 끝내지 못할 확률을 낮추는 것이 아니다'입니다. (XMR→USDT 출구 루트)
엔진이 실제로 하는 일은 상수 다섯 개로 설명됩니다. 세 풀의 어댑터를 병렬로 던지고, 각각에 8,000ms 타임아웃을 걸고, 한쪽 실패가 전체를 죽이지 않도록 전부 정착 방식으로 모으고, 살아남은 견적을 사용자 수령액 내림차순으로 정렬하고, 동일 견적은 8초간 재사용하며, IP당 10분에 60회까지 허용합니다. 클라이언트에는 두 가지만 전달됩니다. 참여 경로 수, 그리고 승자가 차점을 몇 bps 앞섰는지. 2026-11-02 06:04 UTC에 12개 코리도에서 측정한 전체 견적은 종단 간 456~1,291ms였습니다. 타임아웃은 중복성의 숨은 대가입니다. 한 풀이 소켓에서 멈추면 사용자 화면에서 최대 8초를 가져갑니다. 그래서 이 상수는 코드에 묻지 말고 논의할 가치가 있습니다.
두 숫자는 정확히 읽어야 합니다. routes는 그 회차에 몇 개의 제시가 있었는지이며 0은 반환되지 않지만 1이 매우 흔합니다. advantageBps는 차점과의 격차이지 시장 가격과의 격차가 아닙니다. 그래서 0은 '나쁜 환율'이 아니라 '비교가 일어나지 않음'이고, 900은 '시장보다 9% 저렴'이 아니라 '이 코리도·이 금액에서 다른 풀보다 9% 우수'입니다. 시장 비교로 읽는 것이 가장 흔한 오해이며 양방향으로 작동합니다. 단일 경로 견적이 0을 표시해도 충분히 경쟁적일 수 있고, 이중 경로 견적이 900을 표시해도 다른 곳보다 나쁠 수 있습니다.
2,642회의 실제 내용. 두 개의 제시가 있던 275회만 보면 우위 중앙값 143bps, 10분위 33bps, 90분위 893bps입니다. 구간별로는 50bps 미만 59회, 50~200 102회, 200~1,000 88회, 1,000 이상 26회입니다. 놀라운 것은 승자 분포입니다. 이 275회 중 두 번째 풀이 이긴 것은 273회, 99.3%였습니다. 즉 실무의 '애그리게이션'은 보통 '한 명의 가격 결정자 + 가끔 1% 이상 앞서는 대기자'이며 기계의 가치는 중앙값이 아니라 꼬리에 집중됩니다. 전형적인 견적만 보면 차이가 없다고 결론 내립니다. 차이는 아무도 스크린샷하지 않는 26회에 있습니다.
두 번째 제시에는 하한이 있고, 하한은 코리도별입니다. 2026-11-02 06:05 UTC USDT-TRC20→XMR은 계단 같았습니다. 40 USDT는 경로 하나에 0.04760146 XMR(XMR당 840달러 상당), 60은 하나에 0.08004357(750), 100은 하나에 0.14492777(690). 130에서 두 번째 사업자가 들어와 두 경로, 우위 927bps, 0.211546 XMR(614.52). 이어 200은 606bps(613.97), 500은 270bps(613.20), 2,000은 101bps(613.04), 10,000은 63bps(612.96)였습니다. 숫자가 아니라 모양을 읽어야 합니다. 임계값을 넘으면 한 번 약 9%를 얻고, 그 뒤로는 주문당 고정비가 분산되며 우위가 줄어듭니다. 그 고정비는 소액 교환을 비싸게 만드는 것과 같은 장치이며 경쟁의 양쪽에 부과됩니다. (XMR→USDT 출구 루트)
커버리지는 열 개 티커이지 카탈로그 전체가 아닙니다. 사이트는 62개 네트워크의 430개 자산, 349개 티커를 나열하지만 06:04 UTC에 살아 있던 두 풀이 가격을 공유하는 것은 열 개 티커뿐입니다. BTC, ETH, BNB, LTC, DOGE, BCH, XMR, ZEC 그리고 스테이블코인 USDT와 USDC입니다. 나머지는 '아직 취급하는 풀'의 단독 가격입니다. 그 열 개 안에도 구멍이 있습니다. 한 풀은 ZEC 입금을 받지 않아 5 ZEC→XMR이 경로 하나(10.26414479 XMR)였고, SOL은 그 풀에 매핑이 없어 3 SOL→XMR도 하나(0.4529562)였습니다. DOGE→XMR 200달러는 하나였지만 DOGE→BTC 500달러는 둘에 125bps였습니다. 깊이가 있는 코리도와 비교하면 0.05 BTC→XMR은 두 경로 43bps(6.381238 XMR), 1 XMR→USDT-TRC20은 두 경로 216bps(600.933 USDT), 10 LTC는 158bps, 2 BCH는 211bps입니다. (BCH to XMR guide)
주문을 실제로 살리는 층은 견적 아래에 있습니다. 주문 생성 시 서버는 브라우저가 본 가격을 무시하고 비교를 다시 돌리며 클라이언트는 풀을 지정할 수 없습니다. 이어 수령액 높은 순서의 목록을 위에서부터 시도하고, 어떤 풀이 생성을 거부하면 — 주소 방언 불일치, 그 풀의 범위를 벗어난 금액, 상류 장애 — 조용히 다음을 시도하며 전부 소진해야 실패합니다. 전부 실패할 때 표면화되는 것은 '상류 이용 불가'가 아니라 파라미터 오류(잘못된 주소, 하한 미달)입니다. 사용자가 행동할 수 있는 유일한 메시지이기 때문입니다. 마지막 층은 서킷브레이커로, 환경변수 하나로 배포나 코드 변경 없이 풀을 경쟁에서 뺄 수 있습니다. 작성 시점에 세 풀 중 하나가 의도적으로 꺼져 있고, 그것이 여러 코리도에서 routes=1이 보이는 이유입니다. 운영 프로브에서 남은 두 풀은 252ms와 520ms에 응답했습니다.
실제 주문에서 살아남는 다섯 가지 점검. 첫째, 금액을 정하기 전에 routes를 보세요. 1이면 입찰에서 밀린 것이 아니라 두 번째 사업자의 손이 닿지 않는 것입니다. 둘째, 금액을 계단식으로 시험하세요. 두 번째 제시에는 하한이 있고(오늘 TRC20 130 USDT, BTC 0.0016, XMR 0.05) 넘으면 한 번 약 9%의 가치가 있습니다. 셋째, 애그리게이션을 가동 보장으로 착각하지 마세요. 정산은 여전히 단일 경로이므로 refundAddress는 자신이 보유한 지갑으로 두고 입금 거래 해시는 브로드캐스트하는 순간 저장하세요. 넷째, 실금액 전에 하한 근처(이 코리도 약 27 USDT)로 시험하세요. 다섯째, advantageBps는 풀 대 풀이지 시장 대비가 아님을 기억하세요. 여기 모든 수치는 2026-11-02 06:04 UTC 스냅숏입니다. 견적은 초 단위로 움직이고 권위 있는 숫자는 라이브 페이지뿐입니다. (XMR→USDT 출구 루트)