바이낸스 Pegged Orders 뜻 2026｜현물 기준 호가·오프셋·가격 검증 가이드

바이낸스 Pegged Orders 뜻 2026｜현물 기준 호가·오프셋·가격 검증 가이드

바이낸스 Pegged Orders는 주문 가격을 직접 숫자로만 정하는 대신 호가창을 기준으로 지정가를 선택하는 현물 주문 방식입니다. 같은 편 최우선 호가를 사용할지, 반대편 최우선 호가를 사용할지, 그보다 안쪽 가격 단계를 사용할지를 지시합니다. 이름에 Market이 들어간 설정을 쓰더라도 시장가 주문과 같은 뜻은 아닙니다.

이 글은 2026년 11월 2일 확인한 Binance Spot Developers 문서를 기준으로 합니다. 선물 화면의 Queue·Counterparty 버튼 설명을 그대로 옮기지 않고, 현물 API에서 사용하는 PRIMARY_PEG·MARKET_PEG·peggedPrice와 조건부 주문의 가격 결정 시점을 설명합니다. 앱에서 모든 계정에 같은 메뉴가 보인다고 가정하지 않습니다.

직전 글에서 Block Trade라는 이미 발생한 거래 데이터를 읽었다면, 이번에는 거래가 발생하기 전에 어떤 가격으로 주문을 호가창에 넣는가를 살펴봅니다. 체결 데이터와 주문 가격 결정은 연결되지만 서로 다른 단계입니다. 큰 거래가 관측됐다는 이유만으로 Pegged 주문을 선택해야 한다는 의미는 아닙니다.

먼저 알아둘 핵심

호가에 맞춰 가격을 선택하는 편의 기능과 거래 결과 보장은 구별해야 합니다. 유동성이 사라지거나 수량이 부족하면 일부만 체결될 수 있고, 제출 조건이 거래 규칙에 맞지 않으면 거절될 수 있습니다. 주문 접수 여부, 선택 가격, 실제 체결 수량을 각각 확인해야 합니다.

1. 고정 지정가와 다른 점

일반 지정가 매수는 사용자가 가격을 정합니다. 예를 들어 어떤 가상 자산을 100이라는 가격 이하에서 사겠다고 지정하면, 그 숫자가 주문 판단의 중요한 기준이 됩니다. 주문을 입력하는 동안 호가가 바뀌더라도 입력한 숫자가 저절로 현재 최우선 호가가 되는 것은 아닙니다.

Pegged 방식에서는 가격을 고르는 기준을 전달합니다. 같은 편 매수 호가를 선택하겠다는 지시와 반대편 매도 호가를 선택하겠다는 지시는 결과가 다릅니다. 따라서 입력 숫자가 줄어드는 대신, 기준 호가가 무엇인지 이해하는 부담이 생깁니다.

이를 가격 추종 봇과 혼동하면 안 됩니다. 공식 설명에서 확인할 수 있는 것은 주문이 호가창에 진입하는 시점과 조건부 주문이 발동하는 시점의 가격 선택입니다. 이 설명만으로 주문이 살아 있는 동안 매 순간 무제한 재호가된다고 단정하지 않습니다. 자동 취소·재주문 전략의 동작까지 포함한다고 해석하지 않아야 합니다.

또한 차트의 마지막 체결 가격과 호가창의 최우선 가격은 다를 수 있습니다. 마지막 거래가 100에서 일어났더라도 지금 매수호가가 99.8, 매도호가가 100.2라면 어느 숫자를 기준으로 삼는지 먼저 구분해야 합니다. 차트와 주문 결과가 다르다는 이유만으로 오류라고 결론 내리면 안 됩니다.

2. PRIMARY_PEG와 MARKET_PEG를 매수·매도로 읽기

PRIMARY_PEG는 주문과 같은 편, MARKET_PEG는 주문과 반대편을 봅니다. 같은 편이 항상 매수라는 뜻은 아닙니다. 주문 방향을 바꾸면 기준이 되는 호가도 바뀝니다.

매수자가 같은 편을 선택하면 이미 매수하려는 주문들이 있는 쪽의 가격을 기준으로 합니다. 반대편을 선택하면 매도하려는 주문이 있는 쪽의 가격을 기준으로 합니다. 이는 거래 상대를 만날 가능성과 가격 선택에 영향을 주지만, 실제 체결 여부는 수량·시간·주문 조건에 따라 달라집니다.

매도자는 반대로 읽습니다. 같은 편은 매도 호가이고 반대편은 매수 호가입니다. 따라서 코드나 운영표에 단순히 “Primary=Bid”라고 고정해 두면 매도 주문에서 잘못된 해석이 발생합니다. 주문 방향을 먼저 읽고 기준 편을 적용하는 순서가 필요합니다.

문서의 설명 표에 PRIMARY·MARKET 같은 축약 표현이 있더라도 실제 REST 요청값은 해당 엔드포인트의 열거값을 확인해야 합니다. 현재 새 주문 문서는 PRIMARY_PEG와 MARKET_PEG를 설명합니다. 사람이 읽는 이름과 전송하는 문자열을 별도로 관리하면 오타를 줄일 수 있습니다.

3. 시장가와 MARKET_PEG가 다른 이유

MARKET_PEG의 Market은 기준으로 삼을 호가 편을 나타냅니다. 주문 유형 MARKET과 동일한 속성이 아닙니다. 지정가 계열에 가격 선택 지시가 추가되는 구조를 먼저 이해해야 합니다.

시장가는 현재 가능한 유동성과 실행 규칙에 따라 여러 가격에서 체결될 수 있습니다. 반면 호가를 기준으로 선택한 지정가 주문에는 선택된 가격과 유효기간 조건이 존재합니다. 같은 시점에 비슷한 가격에서 일부 체결됐더라도 나머지 수량의 처리 방식까지 같다고 볼 수 없습니다.

예를 들어 가장 싼 매도 호가에 원하는 수량의 일부만 있을 수 있습니다. 그 가격을 기준으로 선택했다고 해서 더 비싼 모든 호가를 제한 없이 매수하는 주문으로 바뀌는 것은 아닙니다. 남은 수량이 어떤 상태가 되는지는 timeInForce와 주문 응답을 함께 확인해야 합니다.

이 구분은 설명 문구를 만들 때도 중요합니다. “현재가로 즉시 전량 매수”라는 표현은 기준 호가 선택과 전량 체결을 한 문장으로 섞습니다. “반대편 호가를 기준으로 가격을 선택하고, 체결 수량과 잔량은 결과에서 확인한다”가 더 정확합니다.

4. Peg Offset은 퍼센트도 틱 개수도 아니다

현재 REST 문서는 pegOffsetType에 PRICE_LEVEL을 안내하고, pegOffsetValue와 함께 지정하도록 설명합니다. 가격 단계는 실제 호가창에 존재하는 가격 수준입니다. 호가 간격이 비어 있을 수 있으므로 틱 크기에 단순히 숫자를 곱하는 것과 다릅니다.

가상 매도 호가가 100.00, 100.05, 100.30 순서로 존재한다고 가정해 보겠습니다. 첫 가격과 다음 가격의 차이는 0.05이고, 다음 두 가격의 차이는 0.25입니다. 호가 단계가 하나 이동했다고 해서 가격 차이가 항상 동일한 것은 아닙니다.

따라서 “오프셋 5는 가격 5%” 또는 “오프셋 5는 반드시 5틱”이라는 설명은 피해야 합니다. 현재 문서의 허용 최대값은 100으로 안내되지만, 그 값이 언제나 충분한 호가 깊이를 보장하는 것도 아닙니다. 실제 요청값과 지원 범위는 주문 직전 공식 엔드포인트 문서를 확인해야 합니다.

호가 단계 선택은 체결 비용과도 연결됩니다. 반대편 안쪽으로 들어가면 더 불리한 가격 수준이 기준이 될 수 있습니다. 같은 편 깊은 단계는 상대적으로 체결 기회가 줄어드는 위치가 될 수 있습니다. 어느 쪽이 유리한지는 목적과 시장 조건에 달려 있으므로 숫자가 클수록 좋은 설정이라고 평가하지 않습니다.

운영 도구에는 오프셋 값 옆에 단위를 함께 표시하는 것이 좋습니다. 단순 숫자 입력칸만 두면 사용자가 금액·퍼센트·틱 중 하나로 오해하기 쉽습니다. “호가 가격 단계”라는 설명과 선택 결과의 실제 가격을 함께 보여주면 오류를 찾기 쉽습니다. 이는 구현 권고이며 Binance 화면의 특정 UI를 설명하는 것은 아닙니다.

5. price와 peggedPrice를 따로 저장해야 한다

공식 응답 설명에서 price는 원래 주문 가격이고 peggedPrice는 선택된 가격입니다. pegPriceType을 지정하면 price가 선택 사항이 되는 경우가 있습니다. 원래 가격을 입력하지 않은 응답에서 price가 0으로 보일 수 있지만, 자산이 0원에 매매됐다는 뜻은 아닙니다.

수신 프로그램이 price만 표시하면 사용자는 주문 가격이 잘못됐다고 생각할 수 있습니다. 반대로 peggedPrice를 실제 평균 체결 가격이라고 표시해도 문제가 생깁니다. 선택 가격, 개별 체결 가격, 누적 체결 금액을 각각 다른 필드로 관리해야 합니다.

주문 입력 시점의 호가 화면도 참고 자료로 남길 수 있습니다. 다만 화면 캡처 시각과 엔진 처리 시각은 다르므로 그것만으로 선택 가격이 잘못됐다고 판단하지 않습니다. 실제 반환된 가격과 주문 상태가 우선 확인 대상입니다.

평균 체결 단가를 계산할 때는 체결 수량이 0인지 먼저 확인해야 합니다. 체결이 없는 주문에서 누적 금액을 수량으로 나누면 의미 없는 결과가 나옵니다. 또한 수수료가 별도 자산으로 부과되면 가격 평균과 순수령량은 같지 않습니다. 주문 가격 기능의 설명에서 계정 손익까지 추정하지 않는 이유입니다.

6. 지원 주문과 조건을 확인하는 순서

Pegged 지시는 모든 주문 유형에 붙일 수 있는 공통 옵션이 아닙니다. 확인한 현물 문서는 LIMIT, LIMIT_MAKER, STOP_LOSS_LIMIT, TAKE_PROFIT_LIMIT에 관련 지시를 설명합니다. MARKET과, 발동 후 시장가가 되는 STOP_LOSS·TAKE_PROFIT는 같은 방식으로 취급하지 않습니다.

또한 LIMIT에서 PRIMARY_PEG를 쓰는 경우 GTC 조건이 안내됩니다. LIMIT_MAKER에는 PRIMARY_PEG만 지원한다고 설명돼 있습니다. LIMIT_MAKER 자체는 즉시 테이커 체결이 발생하는 주문을 거절하는 성격이므로, “Maker라는 이름이 있으니 어떤 설정도 가능하다”고 생각하면 안 됩니다.

다음처럼 확인 순서를 정하면 빠뜨리기 쉽지 않습니다.

1. 거래 시장이 Spot인지 확인합니다.
2. 실제 심볼에서 pegInstructionsAllowed가 허용되는지 확인합니다.
3. 주문 유형이 Pegged 지시를 지원하는지 확인합니다.
4. 선택한 pegPriceType과 timeInForce의 조합이 허용되는지 확인합니다.
5. 오프셋을 쓴다면 두 관련 필드를 함께 지정했는지 확인합니다.
6. 수량·가격·명목 금액 필터를 확인합니다.
7. 응답에서 주문 ID와 선택 가격, 접수 상태를 확인합니다.

이 절차는 실제 주문을 내라는 권유가 아니라 문서를 읽고 설정을 점검하는 방법입니다. 예시를 실계정에 그대로 복사하지 말고, 지원되는 테스트 환경과 현재 규칙을 이용해 확인해야 합니다. 실거래 권한과 자금이 있는 요청은 조회 요청과 다릅니다.

7. 조건부 주문에서는 발동 시점이 중요하다

STOP_LOSS_LIMIT와 TAKE_PROFIT_LIMIT의 Pegged 가격은 조건부 주문을 처음 등록한 시점의 호가를 영구히 고정한 값으로 읽으면 안 됩니다. 공식 문서는 발동 시 호가를 기준으로 지정가가 결정된다고 설명합니다. 발동을 정하는 stopPrice와 발동 후 적용되는 limit 가격은 구분됩니다.

가상 상황에서 조건부 주문을 등록할 때 매도 최우선 가격이 101이었다고 해 보겠습니다. 한참 뒤 발동 조건이 충족됐을 때 그 호가가 105라면, 등록 당시 캡처의 101을 그대로 기대해서는 안 됩니다. 실제 지시와 발동 당시 호가에 따라 선택 가격을 확인해야 합니다.

Pegged는 stopPrice 자체를 호가에 연결하는 기능으로 설명되지 않습니다. 손절 조건을 움직이는 Trailing Stop과도 역할이 다릅니다. 두 기능을 함께 다루더라도 “언제 발동하는가”와 “발동 후 어떤 가격을 쓰는가”를 분리해야 합니다.

발동 시 검증이 다시 이뤄질 수 있다는 점도 중요합니다. 처음 접수됐을 때 유효했던 조건이 나중에도 유효하다는 보장은 없습니다. 시장 상태나 필터 조건이 달라지면 후속 주문이 거절될 수 있으므로 등록 성공 화면만 보고 종료해서는 안 됩니다.

8. OCO·OTO·OTOCO와 연결할 때

복합 주문에서는 모든 다리의 가격이 동시에 정해진다고 생각하기 쉽습니다. 그러나 working 주문과 pending 주문은 호가창에 들어가는 시점이 다를 수 있습니다. 바로 진입하는 지정가와 나중에 발동하는 조건부 지정가를 같은 시간 기준으로 비교하면 혼란이 생깁니다.

OCO는 위·아래 주문에 해당하는 지시를 구분합니다. 현물 API에서는 관련 필드 이름에 above·below 접두사가 붙는 구조를 확인해야 합니다. 한쪽에만 Pegged를 적용했는지 양쪽에 적용했는지도 기록해야 합니다. 두 주문이 연결돼 있다는 사실이 모든 가격 필드를 공유한다는 뜻은 아닙니다.

OTO의 working 주문은 먼저 작동하고 pending 주문은 선행 주문의 체결 이후 활성화됩니다. 공식 문서는 pending 지정가가 선행 주문 체결 후 당시 호가를 기준으로 진입하는 흐름을 설명합니다. pending 조건부 지정가는 그 조건이 발동하는 시점도 추가로 고려해야 합니다.

OTOCO 역시 각 역할을 구별해 읽어야 합니다. “진입·익절·손절을 한 번에 설정”했다는 설명만으로 세 주문이 모두 즉시 호가창에서 거래 가능하다고 판단하지 않습니다. 주문 목록 상태와 각 주문 상태를 함께 보며 어느 다리가 아직 대기 중인지 확인해야 합니다.

기록표에는 주문 목록 ID, 개별 주문 ID, 역할, 활성화 시각, 선택 가격, 최종 상태를 나눠 두는 것이 좋습니다. 나중에 체결 내역을 점검할 때 하나의 화면에서 서로 다른 단계의 가격이 섞이지 않도록 하기 위해서입니다.

9. 다섯 가지 가상 사례로 읽기

아래 숫자는 구조 설명을 위한 가상 값입니다. 실거래 가격, 실제 심볼 지원 상태 또는 기대 수익을 나타내지 않습니다. 수수료와 정밀도는 설명을 단순하게 하려고 제외했습니다.

사례 1. 같은 편 매수 호가에 진입했지만 체결은 0

가상 호가창의 최우선 매수 가격이 99, 최우선 매도 가격이 101이라고 가정합니다. 매수자가 같은 편 기준을 사용하면 매수 쪽 호가를 기준으로 가격이 선택됩니다. 선택 가격이 99로 확인됐다고 해서 99에 거래 상대가 즉시 생겼다는 뜻은 아닙니다.

이미 그 가격에 앞서 대기한 주문도 있을 수 있습니다. 주문 상태가 NEW이고 executedQty가 0이면 가격 선택과 접수는 이뤄졌어도 실제 취득한 자산은 없습니다. 이때 손익 계산에 주문 수량 전체를 넣으면 보유 자산을 과대 집계하게 됩니다.

확인해야 할 질문은 “선택 가격이 맞는가”와 “체결이 일어났는가” 두 가지입니다. 앞의 질문이 맞아도 뒤의 답은 아니오일 수 있습니다. 가격 선택 기능의 성공과 거래 완료를 분리하는 대표 사례입니다.

사례 2. 반대편 매도 호가를 기준으로 매수했지만 일부만 체결

매도 최우선 가격이 100이고 그 가격에 가상 수량 2가 있다고 가정합니다. 사용자는 수량 5를 거래하려 합니다. 반대편 호가를 기준으로 가격을 선택해도 그 가격의 유동성이 자동으로 5가 되는 것은 아닙니다.

설명상 2만 체결됐다면 주문 수량 5, 누적 체결 수량 2, 나머지 3을 따로 읽습니다. IOC인지 GTC인지 같은 유효기간 조건과 응답 상태를 확인해 잔량의 처리를 판단해야 합니다. 최우선 가격에서 일부 체결됐다는 사실은 다른 가격으로 나머지가 모두 체결됐다는 증거가 아닙니다.

평균 체결 가격을 계산하더라도 체결된 2에 대해서만 계산합니다. 주문 전체를 분모로 사용하면 실제보다 낮은 평균이 나올 수 있습니다. 잔량이 사라졌다고 해서 매매 자체가 없던 일로 되돌아가는 것도 아닙니다.

사례 3. 호가 간격이 벌어져 오프셋 해석이 달라짐

가상 호가가 100.00, 100.01, 100.50으로 이어진다고 가정합니다. 가격 단계 기준으로 이동하면 100.01 다음에 100.50을 만날 수 있습니다. 틱 크기만 보고 100.02를 기대하면 선택 결과를 잘못 이해하게 됩니다.

이 경우 필요한 것은 틱 단위 산술을 반복하는 것이 아니라 당시 존재했던 가격 단계와 반환된 peggedPrice를 비교하는 일입니다. 호가에 없는 가격도 유효한 지정가가 될 수 있지만, 기존 호가 단계에서 선택하는 규칙과는 별개입니다.

얇은 시장에서는 작은 단계 차이도 큰 가격 차이로 이어질 수 있습니다. 따라서 오프셋을 가격 위험 한도로 간주하지 않습니다. 사용자가 허용할 가격 범위와 실제 주문 규칙을 별도로 검토해야 합니다.

사례 4. 조건부 주문은 등록했지만 나중에 검증 실패

조건부 주문 등록 당시에는 수량과 예상 가격이 거래 규칙에 맞았다고 가정합니다. 발동 시 선택되는 호가가 달라져 명목 금액 조건을 충족하지 못한다면, 처음 등록 성공이 후속 주문 성공을 보장하지 못합니다.

이때 화면에 예전에 보인 주문 ID만 확인하고 “보호 주문이 계속 작동한다”고 생각하면 위험합니다. 발동 이벤트 이후 실제 개별 주문 상태와 오류 설명을 확인해야 합니다. 이미 체결된 선행 주문이 있다면 그 자산은 별도의 상태로 남습니다.

운영 기록에는 등록 시점 검증과 발동 시점 검증을 나눠 남기는 편이 좋습니다. 어느 단계에서 실패했는지 알아야 가격 입력 문제인지, 수량 문제인지, 당시 시장 규칙 문제인지 구분할 수 있습니다.

사례 5. price가 0으로 보이는 보고서

어떤 보고서가 응답의 price만 읽고 주문 가격을 0으로 표시했다고 가정합니다. 실제로는 pegPriceType과 peggedPrice가 함께 존재하고 선택 가격이 따로 기록돼 있습니다. 이때 원인을 확인하지 않고 주문을 다시 넣으면 의도하지 않은 중복 주문을 만들 수 있습니다.

먼저 주문 ID로 기존 주문을 조회하고 선택 가격 및 체결 수량을 확인합니다. 보고서 표시만 잘못됐다면 표시 로직을 수정해야 합니다. 주문 자체가 잘못됐는지 판단하기 전에 새 주문부터 만드는 대응은 피해야 합니다.

이 사례의 핵심은 데이터의 0을 문맥 없이 해석하지 않는 것입니다. 미입력 원래 가격, 실제 체결 수량 0, 수수료 0은 서로 다른 의미입니다. 필드 이름과 주문 유형을 함께 읽어야 합니다.

10. 필터는 자동 가격 선택에도 적용된다

Pegged라고 해서 거래 규칙을 건너뛰는 것은 아닙니다. 공식 FAQ는 선택 가격에 대해 가격·가격 범위·명목 금액 필터를 확인하도록 설명합니다. price를 함께 지정한 경우 원래 가격과 선택 가격 모두 검증 대상이 될 수 있습니다.

가격이 호가창에 존재한다는 사실만으로 내 주문이 모든 검증을 통과하는 것도 아닙니다. 수량이 다르면 명목 금액이 달라지고, 주문 유형이나 계정 조건도 별도일 수 있습니다. 다른 사람의 주문이 보인다는 이유로 내 주문도 같은 조건에서 허용된다고 판단하지 않습니다.

문제가 생기면 먼저 오류 메시지를 보존합니다. 다음으로 심볼, 주문 유형, 방향, 유효기간, Pegged 필드, 수량을 확인합니다. 한꺼번에 여러 값을 바꾸면 어떤 조건이 원인이었는지 알기 어렵습니다. 결과가 불명확한 요청은 기존 주문 상태부터 조회해야 합니다.

가격 필터 오류를 해결한다고 사용자가 감당할 수 없는 가격까지 무작정 넓히는 것도 적절하지 않습니다. 시스템에서 허용되는 주문과 사용자의 의도에 맞는 주문은 별도입니다. 규칙을 통과시키는 것만으로 설정 검토가 끝나지 않습니다.

11. 실행 전후 확인 절차

실행 전에는 목적을 한 문장으로 적어 봅니다. 같은 편 호가에 대기하려는 것인지, 반대편 가격을 기준으로 빠르게 거래하려는 것인지 분명해야 합니다. 이 목적이 정해지지 않으면 같은 설정도 사람마다 다른 결과를 기대하게 됩니다.

이어서 거래쌍 지원 여부와 실제 요청 조합을 확인합니다. 단일 주문과 주문 목록은 필드 접두사부터 다를 수 있습니다. 예시 문서에 있는 전체 응답을 요청으로 복사하지 말고 요청 항목만 따로 확인해야 합니다.

접수 이후에는 반환된 식별자를 저장합니다. 주문 ID, 심볼, 시각, 선택 가격, 상태를 함께 남기고 실제 체결 수량을 확인합니다. 타임아웃이나 연결 끊김이 발생하면 접수 실패로 단정하지 말고 조회 결과와 계정 이벤트를 대조해야 합니다.

마지막으로 체결 결과와 잔량 상태를 확인합니다. Pegged 주문을 한 번 사용했다는 기록만으로 분석을 끝내면 가격 선택의 정확성과 실행 품질을 평가할 수 없습니다. 수수료, 실제 체결 단가, 미체결 수량까지 구분해서 읽어야 합니다.

12. 다른 기능과 비교

같은 “고급 주문” 분류에 들어간다고 기능을 임의로 결합해서는 안 됩니다. 특히 가격 선택, 분할 실행, 유동성 라우팅, 발동 조건은 서로 다른 축입니다. 하나의 기능 이름으로 나머지 기능까지 제공한다고 설명하면 사용자가 실제 지원 범위를 오해하게 됩니다.

13. 자주 묻는 질문

Q1. Pegged Orders는 현물과 선물에서 완전히 같은가요?

이 글의 근거는 현물 문서입니다. 선물 BBO와 비슷한 용어가 있더라도 지원 주문·파라미터·화면을 그대로 대입하면 안 됩니다. 시장을 먼저 구분한 뒤 해당 제품 문서를 확인해야 합니다.

Q2. PRIMARY_PEG는 항상 매수 호가인가요?

아닙니다. 주문과 같은 편이라는 의미입니다. 매수 주문이면 매수 호가, 매도 주문이면 매도 호가를 기준으로 읽습니다. 방향을 빼고 기억하면 반대 주문에서 오류가 납니다.

Q3. MARKET_PEG는 시장가 주문인가요?

아닙니다. 반대편 호가를 기준으로 선택한다는 의미입니다. 주문 유형과 유효기간 조건을 별도로 확인해야 하며, 전량 즉시 체결을 보장하지 않습니다.

Q4. price를 반드시 입력해야 하나요?

현재 새 주문 문서는 pegPriceType을 지정하면 price가 선택 사항이 된다고 설명합니다. 다만 주문 유형과 다른 필수 항목을 함께 검토해야 하며, 일반 지정가의 규칙과 혼동하지 않아야 합니다.

Q5. price가 0이면 잘못된 주문인가요?

원래 가격을 입력하지 않은 Pegged 응답일 수 있습니다. peggedPrice와 주문 상태를 함께 확인해야 합니다. 0이라는 숫자 하나만 보고 주문 실패나 무료 거래로 판단하지 않습니다.

Q6. 오프셋은 퍼센트인가요?

현재 설명은 존재하는 가격 단계 기준입니다. 퍼센트와 금액, 틱 수로 자동 변환하면 안 됩니다. 호가가 비어 있는 구간에서는 단계 사이 가격 차이가 커질 수 있습니다.

Q7. 오프셋 두 필드는 함께 넣나요?

현재 문서는 pegOffsetType과 pegOffsetValue를 함께 지정하도록 안내합니다. 한 필드만 보내는 구현은 요청 규칙과 다를 수 있으므로 전송 전에 확인해야 합니다.

Q8. 같은 편 호가를 고르면 Maker가 보장되나요?

주문 이름만으로 실제 체결 역할과 수수료를 확정하지 않습니다. LIMIT_MAKER의 지원 조합과 거절 조건을 확인하고, 실제 체결의 역할·수수료 기록으로 결과를 판단해야 합니다.

Q9. SOR와 동시에 사용할 수 있나요?

작성일에 확인한 공식 Pegged FAQ는 SOR 미지원을 안내합니다. 서로 다른 기능의 예시를 합쳐 실제 지원되는 조합처럼 제시하지 않아야 합니다.

Q10. 모든 거래쌍에서 되나요?

exchangeInfo의 pegInstructionsAllowed를 확인해야 합니다. 한 심볼에서 가능하다는 이유로 모든 심볼과 모든 계정에서 동일하게 가능하다고 일반화하지 않습니다.

Q11. 조건부 주문 등록 당시 가격이 계속 유지되나요?

공식 문서는 조건부 지정가가 발동할 때의 호가를 기준으로 가격을 선택하는 흐름을 설명합니다. 등록 당시 화면 가격과 발동 시 선택 가격을 구분해야 합니다.

Q12. stopPrice도 Pegged가 되나요?

이 기능 설명에서 연결되는 것은 지정가 부분입니다. 발동 가격 자체와 혼동하면 안 됩니다. 발동 조건과 발동 후 주문 가격을 별도로 기록하는 것이 좋습니다.

Q13. 처음 접수되면 나중에도 주문이 유효한가요?

조건부·대기 주문은 발동 시 다시 검증될 수 있습니다. 나중에 거절될 가능성을 고려하고 실제 상태를 확인해야 합니다. 등록 성공만으로 후속 실행 완료를 가정하지 않습니다.

Q14. 평균 체결 가격은 peggedPrice와 같나요?

항상 같다고 가정하지 않습니다. peggedPrice는 선택 가격이고 평균 체결 가격은 실제 체결 자료로 계산합니다. 체결이 없다면 평균 체결 가격을 계산할 근거도 없습니다.

Q15. 이 기능이면 슬리피지와 손실이 없어지나요?

그렇지 않습니다. 가격 선택 방식은 시장 위험이나 미체결 위험을 제거하지 않습니다. 실제 유동성·가격 변동·수수료·거래 규칙을 함께 확인해야 합니다.

14. 실전 점검 체크리스트

• 현물 문서와 선물 문서를 구분했는가?
• 기존 BBO 화면 설명과 현물 API 필드를 혼동하지 않았는가?
• 심볼의 pegInstructionsAllowed를 확인했는가?
• 주문 방향을 기준으로 같은 편과 반대편을 골랐는가?
• 주문 유형과 timeInForce의 지원 조합을 확인했는가?
• 오프셋을 퍼센트나 틱 수로 오해하지 않았는가?
• 오프셋 관련 두 필드를 함께 검토했는가?
• price와 peggedPrice를 별도로 저장하는가?
• 조건부 주문의 발동 시점 가격 결정을 이해했는가?
• 발동 시 재검증과 거절 가능성을 고려했는가?
• 주문 ID와 실제 체결 수량을 확인했는가?
• 응답이 불명확할 때 중복 주문보다 조회를 먼저 하는가?
• 잔량 처리와 최종 상태를 확인했는가?
• 체결 역할과 수수료를 실제 결과로 확인했는가?

주문 기록을 읽는 연습: 세 시점의 가격표

실제 주문을 보내기 전에 가상 기록표로 판단 순서를 연습할 수 있습니다. 아래 표는 특정 거래소의 내부 처리 순서를 재현하는 자료가 아니라, 서로 다른 시점의 가격을 섞지 않는 연습입니다. 가격은 모두 가상 기준 자산 단위입니다.

이 표에서 앞의 두 줄만 보고 실제 선택 가격을 역산하지 않습니다. 주문 응답이 100.3이라는 가격을 보여준다면, 화면에 보였던 100.2와 지금 보이는 100.4 사이의 처리 시점을 고려해야 합니다. 세 값이 다르다는 사실만으로 오류를 확정할 수 없습니다.

먼저 주문이 매수인지 매도인지 적습니다. 다음으로 PRIMARY_PEG인지 MARKET_PEG인지 확인하고 오프셋이 사용됐는지 읽습니다. 이 세 가지가 없으면 비교해야 할 호가 자체를 고를 수 없습니다. 매수·매도 방향을 누락한 로그는 가격 숫자가 많아도 판단 자료가 부족합니다.

그다음 선택 가격과 체결 기록을 나눠 적습니다. 선택 가격이 100.3이고 실제 체결 수량이 0이라면 아직 평균 거래 단가는 없습니다. 일부만 체결됐다면 그 부분의 가격과 대금만 실제 실행 자료입니다. 선택 가격은 모든 주문 수량이 그 가격에 체결됐다는 선언이 아닙니다.

조건부 주문이라면 등록 시점과 발동 시점을 한 줄씩 추가합니다. 등록 당시 호가가 아니라 발동 시점의 지시와 결과를 대조해야 하는 이유가 표에서 드러납니다. pending 주문이 포함된 목록이라면 선행 주문 완료 시점도 별도 행으로 남길 수 있습니다.

보고서 문장을 검토하는 방법

“최우선 호가로 주문했으므로 최적 가격에 전량 거래됐다”는 문장은 두 가지 확인되지 않은 결론을 포함합니다. 최우선 호가 선택과 전량 체결은 다르고, 최적이라는 평가는 비교 기준이 필요합니다. 대신 실제 확인한 선택 가격, 체결량, 잔량 상태를 구체적으로 적는 편이 좋습니다.

“price가 0이므로 주문이 실패했다”는 문장도 응답의 다른 필드를 무시합니다. Pegged 여부와 선택 가격, 상태를 함께 확인한 뒤 판단해야 합니다. 보고서가 원래 가격과 선택 가격을 다른 열로 보여주면 이러한 문장 오류를 줄일 수 있습니다.

“오프셋을 늘리면 슬리피지가 줄어든다”는 주장도 일반화할 수 없습니다. 어느 편에서 어느 방향으로 가격 단계를 선택하는지와 당시 호가 간격이 중요합니다. 단계 수만으로 결과를 평가하지 않고 실제 선택 가격과 체결 결과를 확인해야 합니다.

마지막으로 “지원됨”과 “사용 가능 확인”을 구분합니다. 공식 문서에 기능이 있다고 해도 실제 심볼과 계정·제품에서 현재 조합이 허용되는지는 따로 확인해야 합니다. 문서 확인은 준비 단계이고 실제 요청 결과는 실행 단계입니다.

핵심 정리

바이낸스 Pegged Orders를 이해하는 핵심은 가격 숫자를 자동으로 골라 준다는 편의성보다 어느 호가를 언제 기준으로 선택하며 결과를 어떻게 확인하는가입니다. 기준 편, 가격 단계, 조건부 발동 시점, 실제 체결 기록을 나눠 읽으면 화면의 숫자가 달라 보여도 원인을 더 정확히 찾을 수 있습니다.

공식 확인 자료: Pegged orders, Spot 주문 API, 거래 필터. 지원 범위와 요청 항목은 변경될 수 있으므로 실제 사용 전에 다시 확인하세요.

이 글은 기능 이해를 위한 정보이며 투자 권유가 아닙니다. 가상 사례는 실제 시세와 수익을 나타내지 않습니다. 디지털 자산 거래에는 가격 변동, 미체결, 시스템 지연 및 원금 손실 위험이 있습니다.