바이낸스 SOR 주문 뜻 2026｜Smart Order Routing 작동 원리 완벽 정리

바이낸스 SOR 주문 뜻 2026

바이낸스 Spot API에는 하나의 Order Book에만 주문을 매칭하지 않고 여러 유동성 경로를 확인할 수 있는 SOR 주문이 있습니다.

SOR은

Smart Order Routing

의 약자입니다.

쉽게 말하면

내가 주문한 거래 Pair의 Order Book만 확인하는 것이 아니라 → 같은 Base Asset을 가진 다른 SOR 대상 Order Book의 유동성도 확인하고 → 체결 가능한 경로를 찾아 주문을 실행하는 기능

입니다.

예를 들어 일반 Spot 주문에서는 BTCUSDT를 주문하면 기본적으로 BTCUSDT Order Book에서 매수·매도 주문을 찾습니다.

하지만 SOR 대상 그룹에 BTCUSDT와 BTCUSDC처럼 같은 Base Asset을 사용하면서 서로 교환 가능한 Quote Asset을 가진 Pair가 포함되어 있다면 SOR은 여러 Order Book의 유동성을 활용할 수 있습니다.

핵심은

일반 주문 → 하나의 Order Book 중심

SOR → 여러 연결된 Order Book의 유동성 활용

입니다.

다만 SOR을 사용한다고 무조건 더 좋은 가격이나 전체 체결이 보장되는 것은 아닙니다.

---

바이낸스 SOR이란?

Binance Spot API 공식 Glossary에서는 Smart Order Routing을

interchangeable quote assets를 이용해 유동성을 개선하는 기능

으로 설명합니다.

여기서 중요한 용어는 두 가지입니다.

Base Asset

거래 Pair의 앞쪽 자산입니다.

예를 들어

BTCUSDT

에서는

BTC가 Base Asset입니다.

Quote Asset

가격을 표시하고 결제에 사용하는 뒤쪽 자산입니다.

BTCUSDT에서는

USDT가 Quote Asset입니다.

---

Interchangeable Quote Assets란?

SOR에서는 모든 거래 Pair를 무작정 연결하는 것이 아닙니다.

Binance가 SOR 그룹으로 설정한 상호 교환 가능한 Quote Asset의 Order Book을 사용합니다.

초기 Binance 공식 설명에서는 고정된 1:1 교환 관계를 가진 USD Stablecoin 계열을 대표적인 예로 들었습니다.

즉 개념적으로

같은 Base Asset

+

서로 교환 가능한 Quote Asset

조건을 활용해 여러 Order Book의 유동성을 사용할 수 있습니다.

중요한 점은 사용자가 임의로

“USDT와 USDC는 비슷하니까 모두 SOR로 연결되겠지”

라고 판단하면 안 된다는 것입니다.

실제 SOR Group은 Binance의 현재 Exchange Information을 기준으로 확인해야 합니다.

---

SOR 그룹은 어떻게 확인할까?

현재 Binance Spot REST API의 Exchange Information에는 SOR이 제공되는 경우 선택적으로

`sors`

필드가 표시될 수 있습니다.

구조는 개념적으로 다음과 같습니다.

Base Asset → BTC

SOR Symbols → BTCUSDT → BTCUSDC

처럼 하나의 SOR Group에 여러 Symbol이 포함될 수 있습니다.

따라서 API에서 SOR 기능을 구현한다면 주문을 보내기 전에 현재 Exchange Information에서 SOR 지원 그룹을 확인하는 것이 좋습니다.

---

SOR 주문은 어떻게 작동할까?

일반적인 구조를 단순화하면 다음과 같습니다.

1. 사용자가 Spot 주문 제출

↓

2. SOR가 사용 가능한 Order Book 확인

↓

3. 같은 Base Asset의 연결된 유동성 비교

↓

4. 체결 가능한 유동성 활용

↓

5. 사용자 계정에 최종 체결 결과 반영

즉 사용자는 특정 Symbol을 기준으로 주문하지만 내부적으로는 SOR가 연결된 유동성 경로를 활용할 수 있습니다.

---

일반 Spot 주문과 SOR 차이

가장 쉽게 이해하려면 일반 Spot 주문과 비교하면 됩니다.

일반 주문

BTCUSDT Buy 주문을 제출했다면

기본적으로

BTCUSDT Order Book

의 Ask 주문과 매칭됩니다.

SOR 주문

같은 BTC Base Asset에 대해 Binance가 SOR Group으로 연결한 다른 Order Book의 유동성까지 활용할 수 있습니다.

따라서 하나의 Order Book에 충분한 물량이 없더라도 다른 연결된 유동성에서 일부 또는 전체 주문을 처리할 가능성이 생깁니다.

---

SOR 예시

아래 예시는 구조를 이해하기 위한 단순 예시입니다.

SOR Group에

BTCUSDT

와

BTCUSDC

가 포함되어 있다고 가정해보겠습니다.

BTCUSDT Ask

100,100 100,200 100,300

BTCUSDC Ask

100,050 100,150 100,250

일반 BTCUSDT Buy라면 BTCUSDT Order Book을 중심으로 체결합니다.

SOR 주문에서는 Binance가 허용한 라우팅 구조 안에서 BTCUSDC 쪽의 더 나은 유동성을 활용할 수 있습니다.

따라서

한 Order Book의 가격과 유동성만 보는 것보다 체결 선택지가 넓어질 수 있습니다.

단 실제 지원 Pair와 실행 결과는 현재 Binance SOR 설정을 기준으로 확인해야 합니다.

---

SOR을 사용하면 다른 Quote Asset을 직접 받아야 하나요?

Binance가 SOR을 처음 공개했을 때 제공한 공식 예시가 이 부분을 잘 설명합니다.

예를 들어 사용자가 BNB/TUSD SOR 주문을 제출했는데 BNB/FDUSD Order Book의 가격이 더 유리한 경우에도 사용자의 주문은 원래 제출한 주문의 Quote Asset을 기준으로 처리될 수 있도록 설계됐습니다.

즉 사용자가 다른 Pair의 유동성을 직접 찾아가서

TUSD → FDUSD 변환 → BNB 구매

과정을 수동으로 반복하는 구조가 아닙니다.

SOR이 내부적인 Order Routing과 Allocation을 처리합니다.

---

Allocation이란?

Binance Spot API에서 SOR을 이해할 때 알아두면 좋은 용어가

Allocation

입니다.

Binance API Glossary에서는 Allocation을 SOR 등에서 직접 일반 Order Book 체결 방식이 아닌 경로로 거래가 처리됐을 때 Exchange에서 사용자 계정으로 자산을 할당하는 과정으로 설명합니다.

SOR을 이용한 체결 내역은 별도의 Allocation 정보로 확인할 수 있습니다.

---

SOR Allocation 확인

현재 Binance WebSocket API에는

`myAllocations`

기능이 있습니다.

이를 통해 SOR 주문에서 발생한 Allocation 내역을 확인할 수 있습니다.

대표적으로 다음 정보가 포함될 수 있습니다.

• allocationId
• allocationType
• orderId
• price
• qty
• quoteQty
• commission
• commissionAsset
• time
• isBuyer
• isMaker

SOR을 이용한 Allocation이라면

allocationType = SOR

형태로 확인할 수 있습니다.

---

usedSor란?

현재 Binance Spot 주문 응답에는

`usedSor`

라는 필드가 존재할 수 있습니다.

의미는 간단합니다.

usedSor = true

라면 해당 주문이 SOR을 사용했다는 의미입니다.

따라서 API 프로그램에서 실제로 SOR 경로가 사용됐는지 확인할 때 활용할 수 있습니다.

---

workingFloor란?

SOR과 함께 알아둘 필드가

`workingFloor`

입니다.

Binance 공식 Glossary에서는 해당 주문이 현재

SOR

을 통해 처리되고 있는지,

또는

원래 주문을 제출한 Order Book

에서 작동하고 있는지를 나타내는 필드로 설명합니다.

예를 들어

`workingFloor = SOR`

이면 SOR 체결 경로에서 처리되고 있음을 확인할 수 있습니다.

---

usedSor와 workingFloor 차이

두 필드는 비슷해 보이지만 의미가 조금 다릅니다.

usedSor

해당 주문이 SOR을 이용했는지 확인

workingFloor

현재 주문이 어느 체결 경로에서 작동하는지 확인

입니다.

API 기반 자동매매 시스템에서는 두 정보를 함께 확인하면 주문의 실제 실행 방식을 파악하는 데 도움이 됩니다.

---

---

현재 SOR이 지원하는 주문 유형

2026년 현재 Binance Spot API 문서 기준

`POST /api/v3/sor/order`

와

`sor.order.place`

에서는

LIMIT

과

MARKET

주문을 지원합니다.

따라서 SOR 자체가 별도의 매수·매도 방식이라기보다 기존 Spot 주문에 Smart Routing 기능을 적용한 주문 Endpoint라고 이해하면 됩니다.

---

SOR LIMIT 주문

Limit SOR에서는 사용자가

• Symbol
• Side
• Quantity
• Price
• Time in Force

등을 설정합니다.

예를 들어

BTCUSDT

BUY

LIMIT

형태의 주문을 SOR Endpoint에 제출할 수 있습니다.

SOR은 설정한 가격 조건을 지키면서 사용 가능한 연결 Order Book의 유동성을 활용합니다.

---

SOR LIMIT도 원하는 가격을 넘어서 체결되나요?

Limit Order의 기본 가격 조건은 그대로 존재합니다.

SOR을 사용한다고 해서 사용자가 설정한 Limit Price를 무시하고 어떤 가격에서도 체결하는 것은 아닙니다.

즉 SOR의 역할은

가격 제한 제거

가 아니라

사용할 수 있는 유동성 경로 확대

에 가깝습니다.

---

SOR MARKET 주문

현재 Binance Spot API에서는 SOR MARKET Order도 지원합니다.

Market Order는 가격을 직접 지정하지 않고 현재 가능한 유동성을 이용해 빠른 체결을 목표로 합니다.

SOR이 적용되면 하나의 Order Book뿐 아니라 지원되는 SOR 유동성 경로를 활용할 수 있습니다.

다만 Market Order 특성상 실제 체결 가격은 주문 시점의 시장 유동성과 가격 변화에 따라 달라질 수 있습니다.

---

중요한 제한｜quoteOrderQty는 지원하지 않습니다

현재 Binance SOR API 문서에서는

`quoteOrderQty`

를 지원하지 않는다고 명시하고 있습니다.

즉 SOR MARKET 주문에서도

“USDT 1,000어치 BTC를 사겠다”

처럼 Quote Asset 금액만 지정하는 Reverse Market 방식이 아니라

Base Asset Quantity

를 지정해야 합니다.

현재 문서 기준 SOR 주문에서는

`quantity`

가 필수입니다.

---

일반 Market과 SOR Market 차이

일반 Market

제출한 Symbol의 Order Book을 중심으로 즉시 체결

SOR Market

SOR Group의 여러 유동성 경로를 활용해 주문 실행

입니다.

둘 다 Market Order이므로 특정 체결 가격을 보장하지 않습니다.

SOR이 더 많은 유동성 경로를 사용할 수 있다는 것이 핵심 차이입니다.

---

SOR은 더 좋은 가격을 보장하나요?

아닙니다.

SOR의 목적은 여러 Order Book의 유동성을 활용해 잠재적으로 더 나은 가격 또는 더 깊은 유동성을 이용할 수 있도록 하는 것입니다.

하지만

SOR = 항상 최저 매수가

또는

SOR = 항상 최고 매도가

를 보장하는 것은 아닙니다.

시장 가격은 계속 변하고 있으며 각 Order Book의 유동성도 실시간으로 달라집니다.

주문이 전달되고 실제 체결되는 순간 시장 상황에 따라 결과는 달라질 수 있습니다.

---

SOR은 전체 체결을 보장하나요?

아닙니다.

SOR을 사용해도 충분한 유동성이 없다면 주문 전체가 체결되지 않을 수 있습니다.

특히 Limit Order에서는 설정한 가격 조건 안에서 충분한 상대 주문이 없다면

• 일부 체결
• 미체결
• Open Order 유지
• Time in Force에 따른 취소

등이 발생할 수 있습니다.

즉 여러 Order Book을 활용한다고 해서 무조건 전체 주문이 완료되는 것은 아닙니다.

---

GTC SOR은 어떻게 될까?

GTC는

Good Till Canceled

의 약자입니다.

주문이 체결되거나 사용자가 취소할 때까지 유지되는 방식입니다.

Binance가 SOR을 처음 도입했을 당시 공식 안내에서는 SOR GTC Limit 주문이 연결된 유동성에서 모두 체결되지 않는 경우 남은 Quantity가 사용자가 처음 주문한 Symbol의 Order Book에 남을 수 있다고 설명했습니다.

즉

SOR 유동성 활용

↓

남은 Quantity 존재

↓

원래 Symbol Order Book에 주문 유지

형태입니다.

현재 실제 동작은 최신 API와 거래 Pair 조건을 기준으로 확인하는 것이 좋습니다.

---

IOC SOR은 어떻게 다를까?

IOC는

Immediate or Cancel

입니다.

즉시 체결할 수 있는 수량만 체결하고 나머지는 취소합니다.

SOR과 함께 사용되는 IOC 구조에서는 연결된 유동성을 이용해 즉시 체결 가능한 수량을 처리한 뒤 남은 수량을 Order Book에 계속 유지하지 않는 방식으로 이해할 수 있습니다.

따라서

GTC → 남은 주문이 유지될 수 있음

IOC → 남은 주문 취소

차이가 있습니다.

---

SOR과 일반 Limit IOC 차이 예시

예를 들어 특정 Symbol의 원래 Order Book에서는

100.2

가격이 가장 좋은 Ask라고 가정하겠습니다.

하지만 SOR로 연결된 다른 Order Book에

100.1

의 유동성이 존재할 수 있습니다.

일반 IOC 주문은 원래 Symbol의 Order Book에서 체결을 시도합니다.

SOR IOC는 허용된 여러 Order Book의 유동성을 확인할 수 있기 때문에 더 나은 가격의 유동성을 사용할 가능성이 있습니다.

다만 실제 결과는 주문 시점에 따라 달라집니다.

---

SOR과 Split Order는 다릅니다

SOR을 TWAP이나 POV처럼 하나의 큰 주문을 여러 시간대에 나누는 알고리즘으로 생각할 수도 있습니다.

하지만 개념이 다릅니다.

SOR

어느 Order Book의 유동성을 사용할 것인가

TWAP

언제 주문을 나눠 실행할 것인가

POV

시장 거래량에 따라 얼마나 실행할 것인가

입니다.

즉 SOR은 Routing이 핵심입니다.

---

SOR과 TWAP 차이

SOR

여러 Order Book의 유동성 경로를 활용합니다.

TWAP

큰 주문을 시간에 따라 여러 번 나누어 실행합니다.

따라서 두 기능은 목적이 완전히 다릅니다.

---

SOR과 POV 차이

POV는

Percentage of Volume

으로 시장 거래량에 따라 주문 실행 속도를 조절합니다.

SOR은 시장 Volume 비율을 기준으로 주문을 나누는 것이 아닙니다.

SOR → 어디에서 체결할지

POV → 거래량에 맞춰 얼마나 빨리 실행할지

입니다.

---

SOR과 Scaled Order 차이

Scaled Order는 여러 가격에 Limit Order를 배치합니다.

SOR은 하나의 주문을 여러 유동성 경로로 라우팅합니다.

즉

Scaled → 가격 분산

SOR → Order Book 유동성 탐색

입니다.

---

SOR과 Iceberg 차이

Iceberg는 전체 대형 주문 중 일부 Quantity만 Order Book에 공개하는 기능입니다.

SOR은 주문 Size를 숨기는 기능이 아닙니다.

Iceberg

얼마나 보여줄 것인가

SOR

어느 유동성을 사용할 것인가

라고 구분하면 됩니다.

---

SOR과 STP 차이

두 기능 모두 API 고급 주문에서 자주 볼 수 있지만 역할이 전혀 다릅니다.

SOR

여러 Order Book의 유동성을 활용합니다.

STP

자신의 Buy·Sell Order끼리 서로 체결되는 것을 차단합니다.

즉

SOR → 유동성 라우팅

STP → Self-Trade 방지

입니다.

SOR 주문에서도 지원되는 범위에서 `selfTradePreventionMode` 같은 STP 설정을 사용할 수 있습니다.

---

SOR과 OCO·OTO·OTOCO 차이

OCO·OTO·OTOCO는 여러 주문 사이의 실행 관계를 설정합니다.

SOR은 한 주문의 체결 경로를 관리합니다.

OCO

A 또는 B

OTO

A → B

OTOCO

A → B 또는 C

SOR

A 주문 → 여러 적격 유동성 경로 탐색

입니다.

따라서 이름이 모두 고급 주문처럼 보여도 구조가 전혀 다릅니다.

---

SOR은 Futures 기능인가요?

이번 글에서 설명하는 Binance SOR은 Spot API의 Smart Order Routing을 기준으로 합니다.

Binance 공식 Spot API 문서에

`POST /api/v3/sor/order`

Endpoint가 별도로 존재합니다.

따라서 USDⓈ-M 또는 COIN-M Futures 주문과 동일한 기능으로 생각하면 안 됩니다.

Futures에는 Futures 전용 Matching·Algo Order 구조가 별도로 존재합니다.

---

SOR은 일반 Binance 앱에서도 사용할 수 있나요?

전통적인 SOR은 Binance 공식 자료에서 Spot API 사용자 중심 기능으로 제공되어 왔습니다.

따라서 일반 Spot 화면에서

SOR

이라는 주문 버튼을 직접 선택하는 방식과는 다릅니다.

API에서는 별도의 SOR Endpoint를 사용해 주문을 제출합니다.

다만 2026년 9월 Binance에는 일반 사용자 화면을 대상으로 한 AOR(Auto Order Routing) 기능도 별도로 출시됐습니다.

SOR과 AOR은 관련 개념이지만 같은 기능으로 단순하게 합쳐서 이해하면 안 됩니다.

---

SOR과 AOR 차이

2026년에는 이 차이를 특히 알아둘 필요가 있습니다.

SOR

Smart Order Routing

Spot API를 중심으로 제공되는 주문 라우팅 기능입니다.

같은 Base Asset과 교환 가능한 Quote Asset으로 구성된 SOR Group의 유동성을 활용합니다.

AOR

Auto Order Routing

2026년 9월 Binance가 일반 Spot Trading UI에 새롭게 도입한 자동 라우팅 기능입니다.

특히 유동성이 상대적으로 낮은 지역 통화 거래 Pair에서 더 깊은 중간 Pair의 유동성을 활용할 수 있도록 설계됐습니다.

즉

SOR → API 중심

AOR → 일반 Spot Trading UI에서 선택 가능한 자동 라우팅 기능

이라는 차이를 먼저 알아두면 좋습니다.

---

AOR의 간단한 예시

Binance 공식 AOR 설명에서는 지역 통화 Pair를 예로 듭니다.

예를 들어 사용자가

BTC/BRL

을 거래하려는데 직접 BTC/BRL Order Book보다

BTC/USDT

와

USDT/BRL

경로의 유동성이 더 깊을 수 있습니다.

기존에는 사용자가 직접 여러 거래를 해야 할 수 있었습니다.

AOR은 이를 백그라운드에서 자동으로 비교해 더 적합한 경로로 주문을 라우팅할 수 있도록 설계됐습니다.

이는 SOR의 API 기반 interchangeable quote asset 구조와 관련된 개념이지만 현재 제품과 사용자 인터페이스는 별도로 구분됩니다.

---

SOR 주문은 어떻게 API로 제출하나요?

Binance Spot REST API에서는

`POST /api/v3/sor/order`

를 사용합니다.

WebSocket API에서는

`sor.order.place`

를 사용합니다.

주요 파라미터는 다음과 같습니다.

• symbol
• side
• type
• quantity
• timeInForce
• price
• newClientOrderId
• icebergQty
• selfTradePreventionMode
• recvWindow

실제 필수 파라미터는 주문 Type에 따라 달라집니다.

---

SOR 주문은 몇 개의 주문으로 계산될까?

현재 Binance Spot API 문서 기준 SOR 주문 하나는

Unfilled Order Count에 1개

를 추가합니다.

또

`EXCHANGE_MAX_ORDERS`

와

`MAX_NUM_ORDERS`

필터에도 하나의 주문으로 반영됩니다.

따라서 자동매매 프로그램에서 여러 SOR 주문을 동시에 운영한다면 계정과 Symbol의 주문 제한을 확인해야 합니다.

---

SOR에서 Iceberg도 사용할 수 있나요?

현재 Binance SOR API 파라미터에는

`icebergQty`

가 존재합니다.

공식 문서에서는 해당 값이 LIMIT Order에서만 사용 가능하다고 안내합니다.

즉 API 환경에서는 SOR Limit과 Iceberg Quantity를 함께 활용할 수 있는 구조가 존재합니다.

다만 해당 Symbol의 주문 규칙과 지원 조건을 함께 충족해야 합니다.

---

SOR에서 STP도 설정할 수 있나요?

가능한 환경에서는

`selfTradePreventionMode`

파라미터를 사용할 수 있습니다.

지원되는 값은 Symbol 설정에 따라 달라질 수 있으며 대표적으로

• NONE
• EXPIRE_TAKER
• EXPIRE_MAKER
• EXPIRE_BOTH

등의 STP Mode가 존재합니다.

2026년에는 거래 시장별 STP 정책이 계속 확대되어 왔기 때문에 실제 주문에서는 현재 Symbol이 허용하는 STP Mode를 확인하는 것이 중요합니다.

---

SOR 주문이 실제 사용됐는지 확인하려면?

대표적으로 다음 정보를 확인하면 됩니다.

usedSor

SOR 사용 여부

workingFloor

현재 체결 경로

Allocation

SOR 체결로 발생한 자산 할당 내역

즉 API 로그에서 단순히

FILLED

여부만 확인하는 것이 아니라

usedSor → workingFloor → Allocation

을 함께 확인하면 실제 주문 경로를 더 자세히 파악할 수 있습니다.

---

SOR 주문 기록 확인

일반 Binance Spot Order History에서도 주문 상세에 SOR 정보가 표시될 수 있습니다.

또 API 사용자는

• Query Order
• Open Orders
• All Orders
• myAllocations

등을 통해 관련 정보를 확인할 수 있습니다.

특히 SOR로 발생한 Allocation을 분석해야 하는 시스템에서는 `myAllocations` 조회가 중요합니다.

---

SOR 수수료는 어떻게 적용될까?

SOR을 사용했다고 해서 일반적인 Spot 거래 수수료 개념이 사라지는 것은 아닙니다.

실제 체결에는 계정의 Spot Trading Fee 정책이 적용될 수 있습니다.

수수료 조건은

• VIP Level
• 거래 Pair
• BNB Fee 설정
• 프로모션
• 실제 체결 구조

등에 따라 달라질 수 있습니다.

따라서 특정 수수료율을 고정해서 생각하기보다 현재 계정의 Fee 정보를 확인하는 것이 좋습니다.

---

다른 Order Book을 사용하면 환전 수수료가 여러 번 발생할까?

SOR은 사용자가 직접

Quote Asset 교환 → 다른 Pair 거래 → 다시 변환

을 여러 번 수행하는 구조와는 다릅니다.

Binance가 Order Routing과 Allocation을 내부적으로 처리합니다.

초기 공식 SOR 예시에서도 다른 Quote Asset Pair의 유동성을 이용하면서 최종 사용자는 원래 제출한 주문의 Quote Asset을 기준으로 거래하는 방식이 설명됐습니다.

따라서 일반적인 수동 다단계 거래와 동일하게 이해하면 안 됩니다.

---

SOR의 장점

여러 Order Book의 유동성을 활용할 수 있습니다

하나의 Pair에만 의존하지 않고 연결된 SOR Group의 유동성을 사용할 수 있습니다.

체결 가격 개선 가능성이 있습니다

다른 연결 Order Book에 더 유리한 가격이 존재할 경우 해당 유동성을 활용할 가능성이 있습니다.

대형 주문의 유동성 확보에 도움이 될 수 있습니다

한 Order Book의 Depth만 사용하는 것보다 사용할 수 있는 유동성 범위가 넓어질 수 있습니다.

API 자동매매에 활용할 수 있습니다

개발자가 여러 Pair의 Order Book을 직접 비교하고 수동 라우팅하는 로직 일부를 줄일 수 있습니다.

---

SOR의 한계

더 좋은 가격을 보장하지 않습니다

시장 상황이 계속 바뀌기 때문에 특정 가격 개선을 보장하지 않습니다.

전체 체결을 보장하지 않습니다

연결된 Order Book에도 충분한 유동성이 없다면 일부만 체결될 수 있습니다.

모든 Pair가 지원되는 것은 아닙니다

SOR은 Binance가 구성한 SOR Group에서만 사용할 수 있습니다.

일반 사용자 UI와 API 기능을 혼동하기 쉽습니다

SOR은 API 중심 기능이고 2026년에 출시된 AOR과는 별도로 구분해야 합니다.

API 구현 지식이 필요할 수 있습니다

SOR Endpoint, 주문 상태, Allocation 등을 직접 처리해야 합니다.

---

바이낸스 SOR 주문 자주 하는 실수

SOR을 여러 거래소로 주문을 보내는 기능이라고 생각

아닙니다.

Binance 내부 Spot 유동성 경로를 이용하는 기능입니다.

모든 Stablecoin Pair를 자동으로 사용한다고 생각

실제 SOR Group에 포함된 Symbol을 기준으로 합니다.

SOR이면 무조건 더 좋은 가격이라고 생각

잠재적으로 가격과 유동성을 개선할 수 있지만 보장하지 않습니다.

SOR이 TWAP처럼 주문을 시간 분할한다고 생각

SOR은 시간 분할 기능이 아니라 Routing 기능입니다.

SOR이 POV처럼 거래량에 따라 속도를 조절한다고 생각

POV와 목적이 다릅니다.

quoteOrderQty를 사용할 수 있다고 생각

현재 SOR API에서는 `quoteOrderQty`를 지원하지 않습니다.

일반 Spot 앱에서 SOR 버튼을 찾는 경우

기존 SOR은 API 중심 기능입니다.

SOR과 2026년 AOR을 완전히 같은 기능이라고 생각

기본적인 Order Routing 개념은 관련 있지만 대상 사용자와 구현 구조가 다릅니다.

---

바이낸스 SOR 체크리스트

• [ ] Spot API 기능인지 확인
• [ ] SOR Group 확인
• [ ] Base Asset 확인
• [ ] 연결 Symbol 확인
• [ ] LIMIT 또는 MARKET 확인
• [ ] BUY / SELL 확인
• [ ] Quantity 확인
• [ ] LIMIT이면 Price 확인
• [ ] Time in Force 확인
• [ ] quoteOrderQty 미지원 확인
• [ ] Symbol 거래 규칙 확인
• [ ] STP Mode 확인
• [ ] 주문 제한 확인
• [ ] usedSor 확인
• [ ] workingFloor 확인
• [ ] Allocation 확인
• [ ] 실제 Filled Quantity 확인
• [ ] Commission 확인

특히 API에서는

SOR 지원 확인 → 주문 제출 → usedSor → workingFloor → Allocation → 실제 체결

순서로 확인하는 것이 좋습니다.

---

바이낸스 SOR FAQ

바이낸스 SOR이란 무엇인가요?

Smart Order Routing의 약자로 같은 Base Asset과 Binance가 지정한 상호 교환 가능한 Quote Asset을 가진 여러 Spot Order Book의 유동성을 활용하는 주문 라우팅 기능입니다.

SOR은 Spot 기능인가요?

이 글에서 설명하는 SOR은 Binance Spot API 기능입니다.

SOR은 Futures에서도 동일하게 사용하나요?

아닙니다.

현재 설명한 `POST /api/v3/sor/order`는 Spot API Endpoint입니다.

SOR은 어떤 주문을 지원하나요?

2026년 현재 Binance Spot API 문서에서는 LIMIT과 MARKET Order를 지원합니다.

quoteOrderQty를 사용할 수 있나요?

현재 공식 SOR API 문서 기준 지원하지 않습니다. `quantity`를 사용해야 합니다.

SOR은 모든 거래 Pair에서 사용할 수 있나요?

아닙니다.

Binance가 SOR용으로 구성한 Symbol Group에서 사용해야 합니다.

SOR 사용 여부를 어떻게 확인하나요?

주문 응답 및 조회 데이터의 `usedSor` 필드를 확인할 수 있습니다.

workingFloor란 무엇인가요?

주문이 SOR에서 작동하는지 원래 Order Book에서 작동하는지를 나타내는 필드입니다.

Allocation이란 무엇인가요?

SOR 등을 통해 처리된 체결 결과가 사용자 계정에 할당되는 기록입니다.

SOR Allocation을 조회할 수 있나요?

네. 현재 Binance WebSocket API의 `myAllocations` 기능 등으로 관련 Allocation을 확인할 수 있습니다.

SOR을 사용하면 무조건 더 좋은 가격인가요?

아닙니다.

여러 유동성 경로를 활용해 잠재적으로 개선할 수 있지만 특정 가격을 보장하지 않습니다.

SOR은 전체 체결을 보장하나요?

아닙니다.

시장 유동성과 주문 조건에 따라 일부 또는 전체가 미체결될 수 있습니다.

SOR과 TWAP 차이는 무엇인가요?

SOR은 여러 Order Book의 유동성을 활용하고 TWAP은 주문을 시간에 따라 나누어 실행합니다.

SOR과 POV 차이는 무엇인가요?

SOR은 체결 경로를 선택하고 POV는 시장 거래량을 기준으로 주문 속도를 조절합니다.

SOR과 STP 차이는 무엇인가요?

SOR은 유동성 Routing 기능이고 STP는 자기 주문끼리 체결되는 것을 방지하는 기능입니다.

SOR과 AOR 차이는 무엇인가요?

SOR은 기존 Spot API 기반 Smart Order Routing이고 AOR은 2026년 Binance가 일반 Spot Trading UI에 도입한 Auto Order Routing 기능입니다.

---

바이낸스 SOR 핵심 정리

바이낸스 SOR 주문을 한 문장으로 정리하면

“Spot 주문을 하나의 Order Book에만 제한하지 않고 같은 Base Asset을 가진 적격 Order Book의 유동성까지 활용해 체결 경로를 넓히는 Smart Order Routing 기능”

입니다.

---

마무리

바이낸스 SOR은 일반적인 주문 유형이라기보다 Spot 주문의 체결 경로를 확장하는 Smart Order Routing 기능입니다.

일반 Spot 주문이

주문 Symbol → 해당 Order Book

을 중심으로 체결된다면 SOR은

주문 Symbol

↓

SOR Group 확인

↓

여러 적격 Order Book의 유동성 탐색

↓

주문 체결

방식으로 동작할 수 있습니다.

현재 Binance Spot API에서는

LIMIT

과

MARKET

주문을 SOR Endpoint로 제출할 수 있으며 `quoteOrderQty`는 지원하지 않습니다.

API에서는 실제 SOR 사용 여부를

usedSor

로 확인할 수 있고,

현재 주문이 어느 경로에서 작동하는지는

workingFloor

필드,

SOR 체결 세부 결과는

Allocation

정보를 통해 확인할 수 있습니다.

다른 고급 주문과 비교하면 차이도 명확합니다.

Scaled Order → 가격 분산

TWAP → 시간 분산

POV → 거래량 기반 실행

Iceberg → 공개 수량 관리

STP → 자기 체결 방지

SOR → 유동성 경로 확장

입니다.

다만 SOR은 더 좋은 가격이나 전체 주문 체결을 보장하지 않습니다.

실제 주문 전에는 현재 SOR 지원 Symbol과 Order Type, Quantity, Price, Time in Force 등을 확인하고 주문 후에는

usedSor → workingFloor → Filled Quantity → Allocation → Commission

순서로 확인하는 것이 좋습니다.

또 2026년 9월에는 일반 Spot Trading UI를 위한 AOR(Auto Order Routing)도 별도로 출시됐기 때문에 SOR과 AOR을 동일한 기능으로 혼동하지 않는 것이 중요합니다.

이 글은 Binance Spot API 주문 기능을 설명하기 위한 정보성 콘텐츠이며 특정 거래 전략이나 투자 수익을 보장하지 않습니다. 가상자산 거래에는 가격 변동에 따른 원금 손실 위험이 있습니다.