바이낸스 Order Amend Keep Priority 뜻 2026｜수량 감소·우선순위·수정 이력

바이낸스 Order Amend Keep Priority 뜻과 주문 수량 수정

바이낸스 Order Amend Keep Priority는 기존 현물 주문의 수량을 줄이면서 같은 가격에서의 시간 우선순위를 유지하는 수정 기능입니다. 주문을 취소하고 새로 넣는 것과 달리, 기존 주문의 자리를 유지한 채 거래하려는 양을 축소하는 데 초점이 있습니다.

이름에 ‘수정’이 들어가지만 가격을 자유롭게 바꾸거나 수량을 늘리는 범용 편집 기능으로 이해하면 안 됩니다. 현재 Binance Spot 공식 문서가 설명하는 핵심 범위는 열린 주문의 수량 감소입니다. 거래를 더 늘리려는 상황, 가격을 바꾸려는 상황, 주문 자체를 종료하려는 상황은 서로 다른 판단이 필요합니다.

2026년 10월 26일 Binance의 공식 Spot API 문서와 Order Amend Keep Priority FAQ를 확인했습니다. 이 글은 해당 API의 의미와 결과 확인 방법을 설명합니다. 앱의 모든 주문 수정 버튼이 이 경로를 사용한다고 가정하지 않으며, 선물 주문 수정 규칙에도 그대로 적용하지 않습니다. 아래 숫자와 주문번호는 이해를 위한 가상 사례입니다.

먼저 알아둘 세 가지 답

첫째, 유지되는 것은 같은 가격에서 기존 주문이 갖던 시간 우선순위입니다. 다른 가격보다 먼저 체결되거나 상대 주문이 없어도 체결된다는 뜻이 아닙니다. 시장에 들어온 주문의 방향과 가격, 사용 가능한 유동성에 따라 실제 거래 결과는 달라집니다.

둘째, 줄이는 것은 주문 수량이며 과거 체결을 되돌리는 기능이 아닙니다. 주문이 이미 일부 거래됐다면 실제 체결과 현재 수정 결과를 함께 읽어야 합니다. 화면에서 숫자가 줄었다는 이유만으로 과거 매매가 취소됐다고 판단해서는 안 됩니다.

셋째, 요청 성공과 체결 완료는 다릅니다. 수정 응답이 왔다면 변경된 주문 정보부터 확인합니다. 전량 거래됐는지, 일부만 거래됐는지, 아직 주문장에 남아 있는지는 주문 상태와 실제 거래 내역에서 별도로 확인합니다.

주문장 우선순위가 왜 중요한가요?

지정가 주문은 가격과 도착 순서에 따라 대기하는 상황이 생깁니다. 같은 가격에 여러 주문이 있다면 먼저 들어온 주문의 자리를 유지하는 것이 의미를 가질 수 있습니다. 다만 그 자리는 거래를 약속하는 예약권이 아니라, 조건이 맞는 주문이 들어왔을 때 적용되는 순서의 일부입니다.

가상 거래쌍에서 같은 매수가격 100에 A, B, C 주문이 순서대로 대기한다고 합시다. 내 주문이 B라면 A보다 뒤이고 C보다 앞입니다. 거래하려는 양만 줄이기 위해 B를 지우고 다시 제출하면 새 주문은 기존 B와 별개의 주문이 됩니다. 같은 가격으로 다시 제출해도 예전 도착 시각이 따라오는 것은 아닙니다.

Keep Priority는 이 차이를 다루는 기능입니다. 가격과 기존 주문의 정체성을 유지하면서 수량을 줄이는 변경이라면, 취소와 재접수로 순서를 새로 부여받는 대신 기존 주문의 우선순위를 보존할 수 있습니다. 무엇을 유지하고 무엇을 변경하는지 나눠 보면 이름을 이해하기 쉽습니다.

여기서 ‘앞에 있다’는 표현을 수익성과 연결하면 안 됩니다. 먼저 거래되는 것이 항상 유리한 것도 아니고, 거래되지 않는 것이 항상 실패인 것도 아닙니다. 이 기능은 주문 처리 방식이며 가격 전망이나 투자 성과를 판단하는 도구가 아닙니다.

취소·재주문과 실제로 무엇이 달라지나요?

공식 FAQ는 기존 주문을 취소하고 새 주문을 넣는 Cancel Replace와 수량을 제자리에서 수정하는 Order Amend Keep Priority를 구분합니다. 전자는 새 주문의 시간 우선순위를 갖게 되고, 후자는 기존 주문의 우선순위를 유지합니다. Binance 공식 수정 FAQ

예를 들어 목표 수량이 8에서 5로 줄었고 가격은 그대로라면, 수량 감소라는 목적과 Keep Priority의 범위가 맞는지 검토할 수 있습니다. 반대로 가격을 100에서 99로 바꾸려는 목적이라면 이름에 ‘수정’이 있다는 이유로 같은 기능을 적용하면 안 됩니다.

두 방식의 결과를 보고서에 같은 사건으로 저장하는 것도 피해야 합니다. 기존 주문의 수정은 하나의 주문에 변경 이력이 추가되는 구조이고, 취소·재주문은 이전 주문과 이후 주문을 연결해 관리하는 구조입니다. 기록 방식이 다르면 재시도와 중복 판단도 달라집니다.

사용 가능 여부를 먼저 확인하는 순서

1. Spot 주문인지 구분합니다

현재 설명은 Binance Spot 문서 기준입니다. 선물, 옵션, 마진 또는 별도의 알고리즘 주문 서비스에서 비슷한 이름을 보더라도 동일한 파라미터와 우선순위 처리를 추정하지 않습니다. 주문을 제출한 상품과 문서의 상품 범위를 먼저 맞춥니다.

처음 확인할 항목은 계정, 상품, 거래쌍과 주문번호입니다. 이 네 가지를 고정하지 않고 ‘아까 넣었던 주문’이라는 기억으로 수정하면 다른 주문을 대상으로 삼을 위험이 있습니다. 여러 전략을 사용하거나 같은 거래쌍에 주문이 많을수록 식별자를 기준으로 확인하는 편이 좋습니다.

2. 거래쌍의 지원 정보를 확인합니다

공식 FAQ는 Exchange Information에서 amendAllowed가 true인 심볼을 지원 여부 확인 기준으로 설명합니다. 모든 심볼에 기능이 열려 있다고 가정하지 말고 현재 조회 결과를 확인해야 합니다. 문서에 예시로 등장하는 거래쌍이 있다는 사실만으로 내 거래쌍도 지원된다고 결론 내릴 수 없습니다.

지원 정보는 현재 시점의 조건입니다. 과거에 가능했던 심볼이라는 메모만 저장해 두고 계속 사용하기보다, 거래 규칙을 갱신하는 절차에 지원 여부도 포함합니다. 조회 시각을 함께 남기면 나중에 기능 변경과 입력 오류를 구분하는 데 도움이 됩니다.

3. 주문이 여전히 열려 있는지 봅니다

수정하려는 시점에 주문이 이미 체결되거나 취소됐을 수 있습니다. 주문을 조회한 순간과 수정 요청이 처리되는 순간은 같지 않습니다. 열린 주문 목록을 봤다는 사실은 요청이 도착할 때까지 상태가 고정된다는 보장이 아닙니다.

따라서 사전 조회는 대상과 의도를 확인하는 단계이고, 최종 결과는 수정 응답 및 이후 조회로 판단합니다. 사전 화면만 보고 수정이 성공했을 것이라고 기록하면 거래 경합 상황에서 잘못된 상태가 남을 수 있습니다.

4. 현재 필터와 감소 조건을 확인합니다

수량이 줄어드는 방향이라고 해서 어떤 소수값이나 허용되는 것은 아닙니다. 거래쌍의 수량 단위, 최소 조건과 수정 제한 등 해당 요청에 적용되는 조건을 확인해야 합니다. 공식 문서는 필터·권한·계정 제한 등에 의해 수정이 거절될 수 있다고 설명합니다.

실패를 피하려고 원하는 수량을 임의로 올리는 것도 적절하지 않습니다. 원래 의도는 위험 노출을 줄이는 것일 수 있습니다. 유효한 입력으로 바꾸는 과정에서 사용자의 거래 목표가 달라지지 않는지 확인해야 합니다.

API 입력값을 읽는 방법

REST 경로는 PUT /api/v3/order/amend/keepPriority입니다. WebSocket API와 FIX에도 관련 기능이 있지만, 이 글에서는 REST 필드 이름을 중심으로 설명합니다. 실제 요청은 인증·권한과 최신 문서 조건을 따라야 하며, 아래 설명은 실행 코드를 복사하라는 안내가 아닙니다.

현재 문서는 orderId 또는 origClientOrderId로 대상을 지정하고, newQty는 0보다 크면서 기존 주문 수량보다 작아야 한다고 설명합니다. 이 조건을 ‘0을 보내면 취소’로 바꿔 해석하면 안 됩니다. 주문 종료가 목적이면 취소 기능의 규칙을 확인해야 합니다. Spot 거래 요청 공식 문서

newQty는 감소량이 아닙니다

미체결 상태의 가상 주문 수량이 9이고 최종 수량을 6으로 줄이려 한다면, 의도한 변경 후 값은 6입니다. 감소한 양은 3이지만 감소량과 새 수량은 같은 필드가 아닙니다. 변경 의도를 기록할 때 ‘기존 9, 목표 6, 감소 3’처럼 세 값을 나누면 잘못 넣을 가능성을 줄일 수 있습니다.

부분 체결이 섞이면 더 주의해야 합니다. 화면에서 보이는 총수량과 현재 잔량이 무엇인지 먼저 구분하고, 최신 주문 정보와 엔드포인트 정의를 대조해야 합니다. ‘남은 것을 몇 개 줄인다’는 자연어만 가지고 요청값을 계산하면 의미가 달라질 수 있습니다.

주문번호와 clientOrderId는 다릅니다

Keep Priority가 거래소 주문번호를 유지한다고 해서 모든 식별자 문자열까지 자동으로 그대로 남는 것은 아닙니다. 공식 문서는 newClientOrderId를 지정하지 않으면 새로운 사용자 지정 식별자가 생성될 수 있으며, 기존 값을 새 식별자로 전달해 재사용할 수 있다고 설명합니다.

기록표에 주문번호 하나와 사용자 지정 식별자 하나만 덮어써 저장하면 과거 요청을 찾기 어려워질 수 있습니다. 거래소 주문번호를 중심으로 이전과 이후 사용자 지정 식별자, 수정 요청 시각을 연결해 두는 방식이 더 명확합니다. 둘 중 하나가 바뀌었다는 사실만으로 새 거래소 주문이 생겼다고 판단하지 않습니다.

성공한 수정은 어떻게 확인하나요?

수정 응답에서 대상 주문과 변경된 수량을 확인합니다. 요청한 심볼과 주문번호가 맞는지, 의도한 감소가 반영됐는지를 먼저 봅니다. 응답을 받았다는 사실만 기록하지 말고 어떤 값이 적용됐는지 보관해야 합니다.

공식 FAQ는 사용자 데이터 스트림의 executionReport에서 실행 유형 REPLACED가 나타나는 것을 설명합니다. 이 이벤트는 수정이 일어났다는 단서이지, 그 수량이 거래됐다는 뜻이 아닙니다. 실제 체결은 거래 이벤트와 거래 내역으로 확인해야 합니다.

또한 GET /api/v3/order/amendments로 변경 이력을 조회할 수 있습니다. 이력은 언제 어떤 수정이 적용됐는지 확인하는 데 유용합니다. 다만 이력 한 줄과 현재 주문 상태가 다를 수 있으므로, 오래된 수정 성공을 현재 열린 주문의 증거로 사용하지 않습니다.

실무적으로는 요청 전 스냅샷, 수정 응답, 변경 이력과 최신 주문 조회를 구분해서 저장하면 좋습니다. 각각의 자료가 답하는 질문이 다릅니다. 사전 스냅샷은 의도, 수정 응답은 처리 결과, 이력은 변화의 순서, 최신 조회는 현재 상태를 설명합니다.

수량 감소와 실제 체결을 혼동하지 않기

주문 수량이 줄어드는 원인은 하나가 아닙니다. 사용자가 수정을 요청했을 수도 있고, 실제 체결이 발생했을 수도 있으며, STP처럼 별도 규칙에 따른 처리가 있을 수도 있습니다. ‘화면 숫자가 2 줄었다’는 사실만으로 2가 매매됐다고 계산하면 안 됩니다.

주문 수정 이력에서 감소한 수량은 거래량의 근거가 아닙니다. 수수료 계산이나 평균 체결 가격을 만들 때는 실제 거래 수량과 거래 대금을 사용해야 합니다. 수정된 양에 지정가격을 곱한 숫자를 실제 지출로 기입하지 않습니다.

반대로 이미 체결된 거래를 수정으로 없앨 수도 없습니다. 수정 이후 주문의 규모가 작아졌더라도 기존 거래 내역은 별도로 남습니다. 목표 대비 얼마나 더 거래할 필요가 있는지 판단할 때 과거 체결을 빠뜨리면 같은 양을 중복 주문할 수 있습니다.

사례 1: 미체결 주문의 규모만 줄이고 싶은 경우

가상 거래쌍에서 내 주문번호 520의 매수가격은 100, 수량은 12입니다. 같은 가격에는 나보다 먼저 접수된 A와 나중에 접수된 C가 있습니다. 아직 내 주문의 체결은 없고, 거래하려는 양을 7로 줄이려 합니다.

이때 확인할 질문은 ‘가격도 바꾸는가’, ‘수량을 늘리는가’, ‘주문을 완전히 종료하는가’입니다. 세 질문 모두 아니라면, 현재 심볼과 주문이 지원 조건을 충족하는지 확인한 뒤 수량 감소 방식의 수정 범위를 검토할 수 있습니다. 목표는 기존 12에서 새로운 7이며 감소량은 5입니다.

수정 성공 후 기록에는 주문번호 520, 적용된 수량 7과 확인 시각을 남깁니다. 기존의 시간 우선순위를 유지한다고 해서 A보다 앞으로 이동했다고 쓰지 않습니다. C보다 앞선 기존 위치를 유지한다는 의미와 더 빨리 거래됐다는 실제 결과는 다릅니다.

나중에 매도 주문이 들어와 3만 체결됐다면 실제 거래량은 3입니다. 수정으로 줄인 5와 체결 3을 합쳐 8이 거래됐다고 기록하면 안 됩니다. 수정 사건과 체결 사건을 분리하면 현재 상태와 거래 성과가 일치합니다.

이 사례의 실용적인 교훈은 ‘변경 후 수량’을 명확하게 표현하는 것입니다. 감소량만 메모하면 다른 사람이 입력값을 검토할 때 의미가 뒤집힐 수 있습니다. 요청 전후의 값과 단위를 함께 적는 습관이 도움이 됩니다.

사례 2: 가격을 바꾸려는 의도를 잘못 적용한 경우

사용자 B는 가격 100의 주문을 98로 바꾸면서 기존 순서를 유지하고 싶어 합니다. 하지만 Keep Priority를 모든 변경에 우선순위를 붙여 주는 기능으로 이해하면 안 됩니다. 현재 설명 범위는 기존 주문의 수량 감소입니다.

가격 98의 주문장과 가격 100의 주문장은 다른 가격 수준입니다. 기존 가격에서 기다렸다는 이유로 다른 가격의 기존 주문보다 먼저 도착한 것으로 취급해 달라는 요구는 이 기능의 의미가 아닙니다. 지원 범위를 넘어선 기대를 분리해야 합니다.

B는 먼저 목적을 가격 변경으로 기록합니다. 그다음 가격 변경을 지원하는 실제 주문 경로를 확인하고, 취소와 신규 주문을 사용한다면 각각의 결과와 새 우선순위를 받아들여야 합니다. 수량 감소 기능에 가격 변경을 끼워 넣지 않습니다.

여기서 중요한 위험은 기능 이름보다 의도가 앞서야 한다는 것입니다. 특정 API를 쓰기로 먼저 결정한 뒤 거래 목적을 거기에 맞추면, 원래 원하는 동작과 다른 주문을 제출할 수 있습니다. ‘무엇을 바꾸려는가’를 한 문장으로 적은 뒤 방법을 선택합니다.

사례 3: 요청 중 체결이 발생한 경우

사용자 C는 화면에서 열린 주문을 확인하고 수정을 준비합니다. 그런데 그 사이 상대 주문이 들어와 일부가 거래됩니다. 사전 조회와 처리 시점 사이의 상태 변화는 오류가 아니라 실제 시장의 진행일 수 있습니다.

C가 해야 할 일은 오래된 화면의 숫자만으로 결과를 추정하지 않는 것입니다. 수정 요청의 응답을 읽고 현재 주문 상태와 실제 체결 내역을 다시 연결합니다. 수정 거절이 반환됐는지, 변경이 적용됐는지, 주문이 종료됐는지를 구분해야 합니다.

가상으로 사전 기록에는 체결 0이지만 최신 내역에는 체결 2가 있다면, 2를 단순한 수정량으로 처리하지 않습니다. 거래 내역에 확인된 체결은 실제 거래로 남기고, 별도의 수정 이력과 비교합니다. 두 사건이 가까운 시각에 일어났다고 하나로 합치면 안 됩니다.

결과가 불명확한 동안 다른 프로그램이 자동으로 취소·재주문을 시작하지 않도록 하는 것도 중요합니다. 조회가 늦는 동안 여러 변경을 겹치면 어떤 요청이 어떤 결과를 만들었는지 확인하기 어려워집니다. 대상 주문을 중심으로 한 번에 하나의 미확인 변경을 관리하는 것이 합리적입니다.

사례 4: Iceberg 주문의 노출 수량을 오해한 경우

공식 FAQ는 Iceberg 주문도 수정할 수 있으며, 새 수량이 수정 전의 보이는 수량보다 작아지는 경우에 노출 수량 변화가 관련된다고 설명합니다. 따라서 총수량을 줄였다고 노출 수량도 항상 같은 비율로 줄어든다고 가정하면 안 됩니다.

가상의 Iceberg 주문을 관리하는 D가 총량과 노출량을 같은 열에 저장했다면, 수정 뒤 무엇이 달라졌는지 알기 어렵습니다. 총 주문 규모와 주문장에 보이는 양을 나눠 두어야 합니다. 둘은 같은 자산 단위를 사용해도 역할이 다릅니다.

D는 수정 응답의 주문 정보와 현재 노출 관련 조건을 대조합니다. ‘절반 줄였으니 보이는 양도 절반’처럼 비례 계산을 적용하지 않습니다. 현재 공식 규칙과 실제 결과를 기준으로 판단합니다.

Iceberg를 쓴다는 이유로 시장 영향이 사라지거나 주문 규모가 완전히 비밀로 보장되는 것도 아닙니다. 이 사례에서는 수량 수정과 노출 조건의 구분만 다룹니다. 기능 하나의 지원 사실을 거래 효과의 보장으로 확대하지 않는 것이 중요합니다.

사례 5: 연결 주문을 하나만 수정했다고 생각한 경우

OCO는 서로 연결된 두 주문의 관계를 확인해야 합니다. 공식 FAQ는 OCO 쌍이 같은 수량을 가져야 하므로 한쪽의 수정이 양쪽에 영향을 준다고 설명합니다. 주문 목록에 속한 주문을 단독 주문처럼 취급하면 다른 쪽의 변경을 놓칠 수 있습니다.

사용자 E가 OCO의 한 주문을 수정한 뒤 해당 행만 새로고침했다고 합시다. 한쪽만 보고 작업이 끝났다고 하면 다른 주문의 수량과 목록 상태가 기록에서 빠집니다. 목록 식별자와 구성 주문을 함께 확인해야 합니다.

OTO는 working 주문과 pending 주문을 개별 수정할 수 있다는 별도 설명이 있습니다. OCO의 규칙을 이름이 비슷한 모든 연결 주문에 그대로 적용하지 않습니다. 목록 종류에 따라 어떤 주문이 연결되는지와 변경 범위를 읽어야 합니다.

E의 결과표에는 목록 식별자, 영향을 받은 각 주문번호, 수정 후 수량과 현재 상태를 둡니다. 하나의 성공 응답이 전체 거래 전략의 목적을 달성했다는 의미는 아닙니다. 실제 연결 구조가 의도대로 남아 있는지까지 확인해야 합니다.

실패했을 때 원래 주문은 어떻게 되나요?

공식 FAQ는 필터, 권한 또는 계정 제한 등으로 수정 요청이 실패하면 수정이 거절되고 원래 주문은 그 수정으로 변경되지 않는다고 설명합니다. 이것은 수정 실패가 자동 취소를 의미하지 않는다는 중요한 구분입니다.

다만 ‘수정으로 변경되지 않았다’와 ‘시장에서도 아무 일도 일어나지 않았다’는 다릅니다. 요청을 보내는 동안 별도의 체결이나 취소가 발생할 수 있으므로, 현재 주문 상태는 다시 조회해야 합니다. 거절 응답과 실시간 주문 상태를 함께 읽어야 정확합니다.

응답이 아예 오지 않은 상황도 별도로 다룹니다. 명시적인 거절을 받은 것과 통신 시간 초과로 처리 결과를 모르는 것은 같은 사건이 아닙니다. 결과 미확인 상태에서는 변경 이력과 최신 주문을 먼저 확인하고, 실패로 단정해 곧바로 새 주문을 만들지 않습니다.

오류를 조사하는 실용 순서

1. 계정·상품·심볼·주문번호가 맞는지 확인합니다.
2. 현재 주문 상태와 누적 체결을 조회합니다.
3. 심볼의 수정 지원 여부와 최신 필터를 확인합니다.
4. 새 수량이 의도한 변경 후 값인지 확인합니다.
5. 권한, 시간 관련 요청 조건과 오류 메시지를 구분합니다.
6. 변경 이력이 이미 남았는지 확인합니다.
7. 원인이 해소된 경우에만 다음 작업을 결정합니다.

이 순서는 오류 코드만 보고 무조건 재시도하는 것을 피하기 위한 확인 절차입니다. 같은 잘못된 수량을 빠르게 반복해 보내도 필터는 달라지지 않습니다. 요청 제한까지 겹치면 오히려 원인 조사에 필요한 조회가 어려워질 수 있습니다.

주문 개수 제한과 요청 제한은 다릅니다

현재 공식 문서에서 이 수정 요청의 미체결 주문 카운트 증가는 0으로 안내됩니다. 그러나 이를 ‘비용이나 제한이 전혀 없다’고 이해하면 안 됩니다. 요청 가중치와 계정·심볼 조건, 수정 횟수 제한은 별도의 확인 대상입니다.

특히 MAX_NUM_ORDER_AMENDS 같은 필터는 한 주문에 대한 수정 횟수와 관련됩니다. 같은 주문을 계속 작은 단위로 줄이는 전략이라면 거래량이 적다는 이유로 제한도 없을 것이라고 생각하기 쉽습니다. 하지만 거래량, 열린 주문 수와 수정 요청 수는 서로 다른 지표입니다. Spot 필터 공식 문서

설계할 때는 필요하지 않은 변경을 줄이는 것이 좋습니다. 표시 소수점의 사소한 변화까지 매번 수정 요청으로 보내는 대신, 실제 거래 의도가 달라졌는지 먼저 판단합니다. 이 판단은 제한 우회가 아니라 불필요한 요청을 만들지 않기 위한 운영 원칙입니다.

기록표는 이렇게 나누면 읽기 쉽습니다

주문 기본표에는 심볼, 거래소 주문번호, 최초 의도와 현재 상태를 둡니다. 수정 이력표에는 수정 전후 수량, 사용자 지정 식별자의 변화, 요청 시각과 결과를 둡니다. 실제 거래표에는 체결 수량·대금·수수료를 둡니다. 세 자료를 연결하되 합계의 의미를 섞지 않습니다.

예를 들어 주문의 총수량이 12에서 7로 바뀐 뒤 3이 거래됐다면, 수정표에는 12→7, 거래표에는 실제 체결 3이 들어갑니다. 주문 현황은 최신 조회 결과로 관리합니다. 감소한 5를 거래표에 넣지 않으면 평균 가격이나 거래량을 왜곡하지 않을 수 있습니다.

시각도 구분하는 편이 좋습니다. 요청을 보낸 시각, 거래소가 응답한 시각과 내가 결과를 확인한 시각은 같지 않을 수 있습니다. 나중에 통신 지연을 조사할 때 이 구분이 있으면 오래된 정보가 뒤늦게 도착했는지 파악하기 쉽습니다.

정밀도는 원본을 유지합니다. 화면 표시를 위해 0.123456을 0.1235로 줄여 보여줄 수는 있지만, 수정 요청과 사후 대조에는 원본 값을 사용해야 합니다. 긴 주문번호를 스프레드시트 숫자로 저장해 마지막 자릿수를 잃는 일도 피해야 합니다.

주문 수정 검토표를 만드는 방법

실제 수정 전에 한 줄짜리 검토표를 만들면 의도가 분명해집니다. ‘대상 주문번호, 현재 확인 수량, 원하는 변경 후 수량, 가격 유지 여부, 최신 체결 확인 시각, 관련 목록 여부’를 적습니다. 특히 원하는 값이 총수량인지 잔여량인지 모호하다면 전송 전에 그 의미부터 정리해야 합니다.

검토표는 주문을 자동 실행하기 위한 별도의 승인 형식이 아니라, 서로 다른 숫자를 혼동하지 않기 위한 작업 기록입니다. 사람이 화면에서 처리하더라도 같은 질문을 순서대로 확인할 수 있습니다. API를 사용한다면 요청값을 만드는 단계와 그 값을 검증하는 단계를 분리하는 데 도움이 됩니다.

성공 판정도 사전에 정할 수 있습니다. 대상 주문이 같고, 수량 감소가 의도대로 반영됐으며, 연결 주문의 영향이 확인됐다는 조건을 기록합니다. 체결 완료를 성공 판정에 섞지 않습니다. 수정의 성공과 거래의 완료는 서로 다른 목표이기 때문입니다.

예를 들어 단독 미체결 주문을 줄이는 경우에는 수정 응답과 최신 수량이 중요한 증거입니다. OCO라면 양쪽 주문과 목록 상태까지 확인 범위가 늘어납니다. 통신이 끊긴 경우에는 명시적 성공 응답 대신 변경 이력과 현재 주문을 연결해 확인하는 절차가 필요합니다. 상황마다 필요한 증거가 같지 않습니다.

변경 전후를 비교할 때 놓치기 쉬운 비용과 노출

주문 수량을 줄였다고 실제 보유 자산이 즉시 같은 양만큼 줄거나 늘어나는 것은 아닙니다. 아직 거래되지 않은 주문의 규모를 바꾼 것과 이미 보유한 자산의 거래는 다릅니다. 사용 가능 잔고와 주문에 묶인 자산의 변화는 실제 계정 기록에서 확인해야 합니다.

또한 수정 뒤에도 다른 주문이 남아 있다면 전체 계획의 노출을 함께 봅니다. 관심 주문 하나를 줄였지만 같은 자산의 다른 주문이 커졌다면 계정 전체의 상태는 단일 주문 변화와 다를 수 있습니다. 하나의 주문 성공만으로 전체 거래 계획이 축소됐다고 보고하지 않습니다.

수수료를 비교할 때도 수정으로 줄어든 수량에 임의의 요율을 곱해 ‘절약한 금액’이라고 확정하지 않습니다. 그 양이 실제로 어떤 가격과 역할로 거래됐을지 확인되지 않았기 때문입니다. 실제 발생 비용과 가정에 따른 추정 효과를 분리해야 합니다.

운영 기록에서 유용한 표현은 ‘미체결 주문 규모를 축소했고, 실제 체결은 별도 확인했다’입니다. 이 문장은 수정과 거래를 혼동하지 않습니다. 이후 검토자가 원래 목적과 결과를 비교할 때도 어떤 양이 주문에서 줄었고 어떤 양이 시장에서 거래됐는지 쉽게 연결할 수 있습니다.

자주 묻는 질문 FAQ

1. Order Amend Keep Priority는 무엇인가요?

기존 Spot 주문의 수량을 줄이면서 같은 가격에서의 시간 우선순위를 유지하는 기능입니다. 이름에 수정이 있어도 가격 변경이나 수량 증가까지 모두 지원하는 것으로 이해하면 안 됩니다. 현재 거래쌍과 주문의 적용 조건을 먼저 확인합니다.

2. 가격도 바꿀 수 있나요?

이 글에서 확인한 공식 기능의 범위는 수량 감소입니다. 가격 변경이 목적이면 그 목적을 지원하는 주문 경로를 별도로 확인해야 합니다. 다른 가격에서도 예전 도착 시각을 유지한다고 추정하지 않습니다.

3. 수량을 늘릴 수 있나요?

현재 문서는 새 수량이 기존 수량보다 작아야 한다고 설명합니다. 늘리는 요청은 감소와 다른 의도입니다. 추가 거래를 원한다면 현재 주문과 잔고를 확인하고 별도 거래 판단이 필요합니다.

4. 0을 넣으면 취소되나요?

newQty의 조건은 0보다 큰 값입니다. 따라서 0을 취소 명령으로 사용하면 안 됩니다. 주문 종료가 목적이면 실제 취소 기능과 그 결과를 확인해야 합니다.

5. 주문번호는 유지되나요?

공식 FAQ는 거래소 주문번호가 유지된다고 설명합니다. 다만 사용자 지정 식별자인 clientOrderId의 처리와는 구분해야 합니다. 두 식별자를 같은 것으로 저장하면 변경 이력을 잘못 읽을 수 있습니다.

6. clientOrderId도 그대로인가요?

자동으로 항상 같다고 가정하지 않습니다. 현재 문서는 새 식별자를 지정하지 않을 때 새로운 값이 생성될 수 있고 기존 값을 재사용하는 방식도 설명합니다. 실제 요청값과 응답값을 대조하십시오.

7. 우선순위를 유지하면 체결이 보장되나요?

아닙니다. 기존 시간 우선순위의 유지와 상대 주문·유동성의 존재는 다른 문제입니다. 가격 조건이 맞지 않거나 거래 상대가 부족하면 주문이 계속 남을 수 있습니다.

8. 수정 실패가 주문 취소인가요?

수정 거절과 취소는 다릅니다. 공식 FAQ상 실패한 수정으로 원래 주문이 바뀌지는 않지만, 그동안 발생한 시장 체결까지 없다는 의미는 아닙니다. 현재 주문을 다시 조회합니다.

9. 수정 성공은 어디서 확인하나요?

수정 응답의 대상과 적용 수량을 확인하고, 필요하면 사용자 데이터 스트림과 수정 이력을 대조합니다. 최신 주문 상태도 함께 확인해야 합니다. 과거 수정 성공만으로 현재 주문이 열려 있다고 판단하지 않습니다.

10. REPLACED는 체결 이벤트인가요?

수정 관련 실행 유형과 실제 거래를 구분해야 합니다. 해당 이벤트가 보였다고 수량을 거래량에 더하지 않습니다. 매매량은 실제 거래 내역에 근거해 계산합니다.

11. Iceberg에도 사용할 수 있나요?

공식 FAQ는 지원을 설명하지만 총수량과 노출 수량의 변화 조건은 따로 읽어야 합니다. 총량을 줄인 비율만큼 노출량도 자동으로 줄어든다고 계산하지 않습니다. 실제 수정 결과를 확인합니다.

12. OCO 한쪽만 바꾸면 되나요?

OCO는 양쪽 수량 관계가 연결됩니다. 한쪽의 수정이 다른 쪽에도 영향을 주는 공식 조건을 확인하고 목록 전체를 점검해야 합니다. 단독 주문처럼 한 행만 읽고 끝내지 않습니다.

13. 주문 카운트가 0이면 무제한인가요?

카운트 증가가 0이라는 특정 규칙과 모든 제한이 없다는 말은 다릅니다. 요청 가중치, 수정 횟수 필터와 권한·계정 조건은 별도로 존재할 수 있습니다. 현재 문서와 실제 응답을 기준으로 관리합니다.

14. 앱의 수정 버튼도 같은 기능인가요?

이 글은 API 문서로 확인한 동작을 설명합니다. 특정 앱 화면의 버튼이 동일한 내부 경로를 쓴다고 단정하지 않습니다. 사용 중인 화면의 공식 설명과 처리 결과를 확인해야 합니다.

15. 결과를 못 받으면 바로 다시 보내나요?

처리 결과가 미확인인 상황에서는 변경 이력과 최신 주문부터 확인합니다. 같은 요청을 반복하거나 취소·재주문으로 전환하기 전에 이미 수정이 적용됐는지 확인해야 합니다. 통신 실패를 거래 실패로 곧바로 바꾸지 않는 것이 핵심입니다.

실행 전후 체크리스트

• [ ] Spot 문서와 실제 상품 범위를 맞췄다.
• [ ] 계정·심볼·주문번호를 확인했다.
• [ ] 가격 변경이 아니라 수량 감소가 목적인지 확인했다.
• [ ] 현재 주문이 열린 상태인지 조회했다.
• [ ] 거래쌍의 amendAllowed 정보를 확인했다.
• [ ] 새 수량과 감소량을 구분했다.
• [ ] 수량 단위와 필터를 최신 조건으로 점검했다.
• [ ] 부분 체결과 수정 사건을 따로 기록했다.
• [ ] 주문번호와 사용자 지정 식별자를 분리했다.
• [ ] 연결 주문이면 목록 전체의 영향을 확인했다.
• [ ] 수정 응답과 변경 이력을 대조했다.
• [ ] 응답 미확인을 명시적 거절과 구분했다.
• [ ] 요청·수정 횟수 관련 제한을 따로 확인했다.
• [ ] 실제 체결 내역과 현재 주문 상태를 최종 대조했다.

핵심 정리와 마무리

바이낸스 Order Amend Keep Priority를 이해하는 핵심은 기존 주문의 수량 감소, 시간 우선순위 유지와 실제 체결을 각각 구분하는 것입니다. 거래 의도를 먼저 정하고, 지원 여부와 입력 조건을 확인한 뒤, 수정 결과와 최신 주문을 대조해야 합니다.

이 글은 주문 기능을 설명하는 정보성 자료이며 투자 권유나 체결·수익 보장이 아닙니다. 실제 지원 범위와 필터·한도는 변경될 수 있으므로 이용 시점의 Binance 공식 문서와 계정 조건을 확인하십시오.