바이낸스 Order Amendment History 확인 2026｜수정 전후 수량·Execution ID·이력 대조

바이낸스 Order Amendment History 확인 2026｜수정 전후 수량·Execution ID·이력 대조

바이낸스 Order Amendment History 확인은 한 주문의 수량이 언제, 어떤 값에서 어떤 값으로 바뀌었는지 추적하는 작업입니다. 주문 수량이 줄어들었다고 모두 체결된 것은 아닙니다. 사용자가 수량을 수정했을 수도 있고, 체결과 수정이 가까운 시점에 함께 발생했을 수도 있습니다. 현재 수량만 보면 이 차이를 놓치기 쉽습니다.

2026년 11월 2일 확인한 Binance 현물 공식 문서는 GET /api/v3/order/amendments를 통해 단일 주문의 수정 이력을 조회하는 방법을 안내합니다. 응답에는 orderId, executionId, origClientOrderId, newClientOrderId, origQty, newQty, time이 포함됩니다. 이 글은 기존 Order Amend Keep Priority의 개념을 반복하기보다 이력을 읽고 현재 주문·체결 내역과 대조하는 방법에 집중합니다.

앞선 SOR 배분 글에서 실제 실행 결과를 식별자로 연결했다면, 이번에는 주문 조건의 변화 자체를 연결합니다. 체결 기록, 배분 기록, 수정 기록은 모두 주문 분석에 쓰이지만 같은 종류의 행이 아닙니다. 하나의 합계에 섞기 전에 각각의 역할을 정해야 합니다.

먼저 보는 핵심

핵심은 수정은 조건 변화이고 체결은 실제 거래라는 구분입니다. 수량 감소분을 모두 매수·매도 실적으로 집계하면 거래량과 잔량, 손익을 잘못 계산할 수 있습니다. 이력은 변화의 이유를 설명하지만 현재 잔고 전체를 대신하는 자료는 아닙니다.

1. 왜 현재 주문만 보면 부족한가

현재 주문 조회는 지금 또는 조회 시점의 주문 상태를 보여줍니다. 그러나 처음 수량이 얼마였고 중간에 몇 번 수정됐는지까지 한 화면의 최종 숫자로 설명되지는 않습니다. 가상 주문 수량이 10에서 7로 바뀌었다면, 현재 7이라는 사실과 3이 감소한 이유는 다른 정보입니다.

주문을 관리하는 사람은 대개 “내가 요청한 변경이 실제로 반영됐는가”를 알고 싶어 합니다. 반면 거래 분석자는 “얼마가 체결됐고 얼마가 아직 남았는가”를 알고 싶어 합니다. 이 두 질문을 하나의 수량 값으로 답하려 하면 수정 감소분이 체결로 둔갑할 수 있습니다.

자동화 도구에서도 같은 문제가 발생합니다. 로컬 화면에서 수량을 바꿨다는 기록만 있고 서버의 수정 결과를 확인하지 않았다면, 화면과 실제 주문이 다를 수 있습니다. 반대로 서버에서 수정됐는데 응답을 놓쳤다면 수정 실패로 착각해 재요청할 수 있습니다.

이력을 조회하면 변경 전후의 값을 확인할 수 있습니다. 다만 이력 조회가 모든 문제를 해결하는 것은 아닙니다. 현재 주문 상태, 체결 내역, 계정 이벤트를 같은 대상과 시점으로 연결해야 상황을 완전히 이해할 수 있습니다.

2. Keep Priority와 Cancel Replace는 기록 구조가 다르다

Order Amend Keep Priority는 기존 주문을 수정하는 방식입니다. 현재 공식 설명에서 지원하는 변경은 수량 감소이며, 같은 가격의 대기 순서에서 우선순위를 유지하는 성격을 가집니다. 기존 주문 ID가 유지된다는 점이 이력 연결에 중요합니다.

Cancel Replace는 기존 주문을 취소하고 새 주문을 내는 흐름입니다. 새 주문은 다른 주문 ID를 가질 수 있으며 시간 우선순위도 달라집니다. 두 방식 모두 사용자가 보기에는 “주문 수정”처럼 느껴질 수 있지만 기록을 읽는 방법은 같지 않습니다.

따라서 하나의 주문에 대한 amendments 조회로 모든 취소·재주문을 찾을 수 있다고 가정하면 안 됩니다. 실제로 어떤 작업을 요청했는지 먼저 확인해야 합니다. 이름이 비슷하다는 이유로 서로 다른 작업 결과를 같은 표에 억지로 맞추지 않아야 합니다.

이 글에서 사용하는 “수정 이력”은 현물 Query Order Amendments가 제공하는 범위입니다. 앱의 모든 편집 행동이나 선물 주문 수정 기능을 포괄하는 이름으로 넓히지 않습니다. 어떤 제품과 요청을 사용했는지 알아야 맞는 자료를 찾을 수 있습니다.

3. 조회 전에 대상 주문을 고정하기

먼저 symbol과 orderId를 확인합니다. 현재 문서에서 두 값은 필수 조회 항목입니다. 사용자 화면의 별칭이나 전략 이름만으로 주문을 찾으려 하면 같은 전략이 여러 번 낸 주문을 혼동할 수 있습니다.

clientOrderId는 사람이 만든 식별 체계와 연결하는 데 유용하지만 수정 과정에서 바뀔 수 있습니다. 이력에는 수정 전후의 클라이언트 주문 ID가 함께 나옵니다. 따라서 현재 clientOrderId 하나만 저장하고 이전 값을 버리면 과거 로그와 연결이 끊길 수 있습니다.

기록을 정리할 때는 심볼, orderId, 최초 요청 시각, 당시 clientOrderId를 먼저 확보하는 편이 좋습니다. 이후 이력의 origClientOrderId와 newClientOrderId를 연결하면 이름이 바뀌어도 같은 주문의 흐름을 추적할 수 있습니다.

실계정 식별자나 인증 정보를 공개 예시에 넣을 필요는 없습니다. 이 글의 숫자와 이름은 가상 값으로 설명합니다. 고객센터 등 정당한 확인 과정에 자료를 제공하더라도 비밀키·서명·인증 토큰과 거래 식별자를 구분해야 합니다.

4. Query Order Amendments의 요청 항목

현재 공식 REST 문서는 symbol, orderId, timestamp를 필수로 안내하고 fromExecutionId, limit, recvWindow 등을 선택 항목으로 설명합니다. 계정 정보 조회이므로 서명과 권한 조건을 확인해야 합니다. 이 글의 표는 요청의 개념을 설명하며 실행 가능한 인증 요청을 제공하는 것은 아닙니다.

limit은 현재 기본 500, 최대 1000으로 안내됩니다. 이것을 주문을 1000번 수정할 수 있다는 의미로 해석하면 안 됩니다. 실제 수정 제한과 결과 페이지 크기는 별도의 규칙입니다.

fromExecutionId 역시 orderId와 같은 역할이 아닙니다. 하나의 주문 안에서 어느 실행 기록부터 확인할지와 관련된 값입니다. 숫자가 익숙하다고 다른 종류의 ID를 넣으면 엉뚱한 범위를 조회하거나 오류를 만들 수 있습니다.

지원되지 않은 시간 필터를 임의로 붙여 “하루 수정 이력 전체 조회”처럼 설명하지 않아야 합니다. 이 엔드포인트가 단일 주문을 대상으로 한다는 점을 유지하고, 여러 주문을 분석하려면 대상 주문 목록과 각 조회 범위를 별도로 관리해야 합니다.

5. origQty는 항상 최초 주문 수량이 아니다

수정 이력의 origQty는 해당 수정 전 값을 뜻합니다. 여러 번 수정했다면 각 행의 origQty는 직전 상태에 따라 달라집니다. 첫 주문 수량 하나가 모든 행에 반복된다고 가정하면 수량 변화 계산이 틀릴 수 있습니다.

가상 주문이 10에서 8로, 다시 8에서 6으로 수정됐다고 해 보겠습니다. 첫 행은 10과 8, 다음 행은 8과 6의 관계로 읽습니다. 두 번째 행의 origQty가 8이라고 해서 처음부터 수량 8인 별도 주문이었다고 판단하면 안 됩니다.

이력의 각 차이는 2와 2입니다. 그러나 이를 체결 수량 4로 집계해서는 안 됩니다. 그것은 주문 수량 조건이 감소한 내역이지 실제 거래 상대와 매매된 양을 뜻하지 않습니다. 실제 체결은 별도의 체결 필드와 거래 내역에서 확인해야 합니다.

또한 수정 후 수량을 곧바로 현재 남은 수량으로 읽는 것도 조심해야 합니다. 이미 체결된 수량이 있거나 조회 시점 사이에 추가 체결이 발생했을 수 있습니다. 현재 주문 응답의 수량 정의와 누적 체결량을 함께 확인해야 합니다.

6. executionId를 거래 ID로 오해하지 않기

executionId는 수정 실행 기록을 구분하는 식별자로 사용됩니다. 이름에 execution이 들어간다고 모든 행이 매매 체결을 의미하는 것은 아닙니다. 주문 처리 시스템에서는 체결 외에도 여러 실행 유형이 존재할 수 있습니다.

수정 이력의 executionId를 거래 내역의 tradeId와 같은 칸에 넣으면 연결 오류가 생길 수 있습니다. 두 값이 우연히 같은 숫자여도 같은 사건이라는 뜻은 아닙니다. 데이터 종류와 필드 이름을 함께 보존해야 합니다.

한 주문에 executionId가 여러 개 있다는 것은 여러 수정 기록이 있다는 의미로 읽어야 합니다. 이를 여러 번 체결됐다고 보고 거래 횟수로 더하지 않습니다. 반대로 같은 실행 기록을 여러 번 조회했다면 중복 처리 여부를 확인합니다.

ID의 연속성도 추측하지 않는 편이 좋습니다. 중간 숫자가 빠졌다는 이유로 곧바로 수정 기록 누락이라고 결론 내리지 않습니다. 공식 조회 범위와 페이지 수집 상태를 검증해야 하며, 숫자 차이만으로 보이지 않는 사건을 만들어내면 안 됩니다.

7. 클라이언트 주문 ID의 변화 연결하기

공식 Keep Priority FAQ는 수정된 주문의 clientOrderId가 기본적으로 새 값이 될 수 있고, 현재 값을 유지하려면 관련 요청 항목을 사용할 수 있다고 설명합니다. 따라서 수정 전후 값이 다르다는 것 자체가 주문이 취소되고 새로 생성됐다는 증거는 아닙니다.

가상 이력에서 origClientOrderId가 alpha, newClientOrderId가 beta이고 다음 행에서 beta가 gamma로 바뀌었다고 가정합니다. orderId가 같은 흐름이라면 alpha → beta → gamma라는 식별자 변경 사슬로 읽을 수 있습니다.

사용자 인터페이스에는 최신 이름을 보여주더라도 내부 대조표에는 이전 이름을 보존하는 것이 좋습니다. 과거 오류 로그나 알림이 alpha를 사용했다면 최신 gamma만으로 검색할 때 놓칠 수 있기 때문입니다.

단, 이름 변화가 이어지지 않는다고 무조건 서버 오류로 판단하지 않습니다. 일부 페이지가 누락됐거나 다른 주문의 행을 잘못 붙였을 수 있습니다. 먼저 symbol과 orderId, 실행 ID, 조회 범위를 다시 확인해야 합니다. 검증이 끝나지 않은 연결은 추측으로 완성하지 않습니다.

8. 이벤트와 조회 이력을 함께 읽는 법

현재 공식 FAQ는 수정 성공 시 갱신된 수량이 응답에 나타나고, User Data Stream에서 실행 유형 REPLACED를 가진 executionReport가 전달된다고 설명합니다. 주문 목록과 클라이언트 ID 변경 조건에 따라 listStatus도 관련될 수 있습니다.

이벤트는 실시간 상태를 파악하는 데 유용하지만 연결 끊김이나 수신 누락 가능성을 고려해야 합니다. 한 이벤트를 보지 못했다고 수정이 없었다고 단정하지 않고, 조회 이력과 현재 주문 상태를 대조하는 절차가 필요합니다.

반대로 이력을 조회했다고 실시간 이벤트를 모두 무시하는 것도 적절하지 않습니다. 조회 시점 사이에 체결이나 취소가 추가로 발생할 수 있습니다. 데이터 수집 시각과 사건 시각을 나눠 보존하면 두 자료의 차이를 설명하기 쉽습니다.

대조표에는 “수정 응답 확보”, “이력 확인”, “현재 주문 확인”, “체결 확인”을 별도 단계로 표시할 수 있습니다. 이는 자체 검증 단계이며 거래소의 공식 주문 상태 이름이 아닙니다. 확인 범위를 분명히 하는 목적입니다.

9. 부분 체결과 수정이 함께 있을 때

주문이 일부 체결된 뒤 남은 노출을 줄이려는 상황은 흔히 생각할 수 있습니다. 이때 수정 전후의 주문 수량과 누적 체결 수량이 함께 등장합니다. 세 숫자를 구분하지 않으면 남은 주문 규모를 잘못 읽게 됩니다.

예를 들어 가상 주문 총수량이 10이고 3이 이미 체결됐다고 가정합니다. 이후 허용되는 수정으로 주문 총수량이 8이 됐다면, 이 단순화된 상황에서 미체결 부분은 5로 계산할 수 있습니다. 수정 감소분 2가 추가 체결된 것은 아닙니다.

다만 이 계산은 같은 시점의 정확한 필드 정의를 전제로 한 설명입니다. 조회 사이에 추가 체결이 일어났다면 누적 체결량은 3이 아닐 수 있습니다. 따라서 이전 화면의 체결량과 최신 수정 수량을 섞어 계산하지 않아야 합니다.

수정 요청을 보내는 동안에도 시장은 움직입니다. 사용자가 입력한 값과 실제 허용 조건이 충돌할 수 있으므로 요청 성공 여부와 실제 주문 상태를 확인해야 합니다. 오래된 로컬 수량을 기준으로 계속 줄이는 자동화는 예상과 다른 결과를 만들 수 있습니다.

10. 다섯 가지 가상 사례

아래 사례는 이력 해석을 위한 것입니다. 실제 주문 지원 범위·계정 상태·수량 제한을 나타내지 않습니다. 주문을 실행하는 코드나 거래 권유로 사용하지 않아야 합니다.

사례 1. 두 번 줄였는데 거래량이 늘어난 보고서

가상 주문 700의 수량이 12에서 10으로, 다시 10에서 7로 수정됐습니다. 보고서가 각 감소분 2와 3을 체결량으로 기록해 거래량 5라고 표시합니다. 실제 체결 내역은 없다고 가정합니다.

이 경우 거래량 5는 잘못된 계산입니다. 수정 이력은 주문 조건이 바뀐 자료이고 실제 매매 발생을 의미하지 않습니다. 주문 수량 변화 합계는 별도로 표현할 수 있지만 체결량이라는 이름을 붙여서는 안 됩니다.

수정 전후 수량을 기록한 표와 체결 수량을 기록한 표를 분리하면 오류를 줄일 수 있습니다. 최종 보고에는 “주문 수량 12 → 7, 실제 체결 0”처럼 다른 사실을 각각 적는 편이 정확합니다.

사례 2. 부분 체결 후 수량 감소

가상 주문이 총수량 10으로 접수되고 4가 체결됐습니다. 이후 수정 결과 총수량이 8로 확인됐다고 가정합니다. 같은 시점에 추가 체결이 없다면 미체결 부분은 4로 읽을 수 있습니다.

여기서 newQty 8을 전부 잔량이라고 표시하면 실제 남은 노출을 과대평가합니다. 반대로 최초 10과 최종 8의 차이 2를 체결로 추가하면 누적 체결이 6으로 부풀어집니다.

정확한 표는 총수량, 누적 체결 수량, 미체결 부분을 구분합니다. 수정 이력은 왜 총수량이 달라졌는지를 설명하고 체결 내역은 실제 거래된 양을 설명합니다. 서로의 역할을 대신하지 않습니다.

사례 3. 응답을 놓쳐 같은 수정이 실패한 줄 앎

수정 요청 이후 연결이 끊겨 응답을 받지 못했다고 가정합니다. 사용자는 실패했다고 생각하지만 서버에서 수정됐을 가능성도 있습니다. 이때 곧바로 또 다른 변경을 보내면 원래 의도와 다른 수량이 될 수 있습니다.

먼저 기존 주문 ID로 현재 상태와 수정 이력을 확인합니다. 요청한 전후 수량과 시각, clientOrderId 변화가 실제 이력에 있는지 검토합니다. 확인되지 않은 결과는 성공이나 실패 어느 쪽으로도 확정하지 않습니다.

이 사례에서 중요한 것은 자동 재시도 횟수가 아니라 결과의 불확실성을 줄이는 절차입니다. 조회로 이미 반영된 사실을 확인했다면 같은 작업을 다시 수행할 이유가 없습니다. 요청 로그와 실제 상태를 연결해야 합니다.

사례 4. clientOrderId가 바뀌어 주문을 잃어버린 것처럼 보임

가상 주문 900의 이름이 old-label에서 new-label로 바뀌었습니다. 운영 도구가 old-label만 검색해 주문을 찾지 못하고, 새 주문이 필요하다고 표시했다고 가정합니다.

이력의 origClientOrderId와 newClientOrderId를 연결하면 같은 orderId 아래 이름이 변경됐음을 확인할 수 있습니다. 이름이 바뀐 사실을 주문 소멸로 해석하면 중복 주문 위험이 생깁니다.

관리 도구에서는 최신 이름을 보여주되 이전 이름으로도 같은 주문 기록을 찾을 수 있게 연결하는 편이 좋습니다. 이력 자체를 수정해 과거 이름을 지우기보다 변경 관계를 남겨야 과거 알림과 대조할 수 있습니다.

사례 5. 수정 이력이 비어 있는데 화면에서는 수정했다고 기억함

사용자가 주문 화면에서 가격을 바꿨고 이를 수정이라고 기억한다고 가정합니다. 실제 동작이 취소 후 새 주문이었다면, 이전 주문의 amendments 조회가 기대한 형태의 이력을 보여주지 않을 수 있습니다.

먼저 실행한 작업의 종류를 확인합니다. 취소 결과와 새 주문 ID가 있다면 두 주문을 별도로 연결해야 합니다. 단일 주문 수정 이력에서 모든 편집 행동을 찾으려 하면 잘못된 누락 판단을 할 수 있습니다.

이 경우 필요한 것은 “조회 기능이 고장났다”는 결론보다 작업 분류를 바로잡는 것입니다. 기존 주문 수정과 취소·재주문은 사용자의 표현이 비슷해도 데이터 구조가 다릅니다.

11. 실패한 수정은 어떻게 확인하나

공식 Keep Priority FAQ는 필터·권한·계정 제한 등으로 수정 요청이 거절되면 주문이 변경되지 않는다고 설명합니다. 따라서 로컬 입력칸에서 숫자를 바꿨다는 사실만으로 실제 수정 완료라고 표시해서는 안 됩니다.

오류가 발생하면 오류 코드와 설명을 먼저 보존합니다. 그다음 요청한 수량, 대상 심볼과 주문 ID, 당시 주문 상태를 확인합니다. 오류를 빈 이력으로 변환하거나 성공 메시지로 덮어쓰면 원인 분석이 어려워집니다.

이미 체결되거나 종료된 주문에 대한 요청인지, 허용되는 수량 감소인지, 현재 필터와 제한에 맞는지 확인해야 합니다. 구체적인 오류를 보지 않고 수량을 여러 번 임의로 바꾸면 의도와 다른 주문을 만들 수 있습니다.

결과가 불명확한 연결 오류와 명시적으로 거절된 응답도 구분합니다. 응답을 받지 못한 상태는 실제 서버 처리 결과를 아직 모르는 상태일 수 있습니다. 조회 이력과 현재 주문 확인이 중요한 이유입니다.

12. 수정 횟수 제한과 조회 페이지 크기

공식 필터 문서에는 MAX_NUM_ORDER_AMENDS라는 수정 관련 필터가 있습니다. 이는 한 주문의 수정 횟수와 관련된 거래 규칙입니다. 반면 Query Order Amendments의 limit은 반환되는 이력 행 수를 제한합니다.

두 숫자를 같은 한도라고 생각하면 잘못된 안내가 됩니다. 페이지에 500개가 보인다고 500번 수정이 허용된다는 뜻이 아니고, 한 번에 1000개까지 조회 가능하다고 거래 규칙도 같다는 뜻이 아닙니다.

운영 도구에서는 필터 값과 조회 설정을 다른 항목에 보관해야 합니다. 전자는 요청 가능성을 검토하는 데 쓰고, 후자는 자료 수집의 완전성을 검토하는 데 씁니다. 이름에 limit이 있다고 같은 단위로 합치지 않아야 합니다.

필터 값은 실제 심볼과 계정 조건, 최신 공식 자료를 확인해야 합니다. 문서에 나온 예시 숫자를 모든 계정의 현재 한도로 일반화하지 않습니다. 이력 분석을 위해 허용 횟수를 소모하는 시험 주문을 낼 필요도 없습니다.

13. 페이지와 중복 이력 관리

이력이 여러 페이지에 걸친다면 fromExecutionId와 limit의 현재 규칙을 확인해 이어 읽습니다. 경계 행이 반복될 가능성이나 정렬 방향을 검토하고 동일 실행 기록을 두 번 집계하지 않도록 해야 합니다.

중복 제거는 단순 시각 비교보다 대상 주문과 실행 식별자를 기준으로 설계하는 편이 좋습니다. 같은 시각 값에 서로 다른 기록이 있을 수 있고, 다시 조회한 같은 기록은 수신 시각만 달라질 수 있기 때문입니다.

원문 자료는 그대로 보존하고 정리된 표를 별도로 만드는 방식이 유용합니다. 나중에 파싱 규칙을 바꾸거나 잘못된 해석을 수정할 때 원문이 있어야 다시 검증할 수 있습니다. 편집한 표만 남기면 원래 응답이 무엇이었는지 알기 어렵습니다.

최종 보고서에는 조회 범위가 단일 주문인지 여러 주문인지 명시합니다. 한 주문의 완전한 이력을 확인했다고 계정 전체의 모든 수정 이력을 확인한 것은 아닙니다. 확인 범위를 과장하지 않는 것이 정확한 감사 기록의 기본입니다.

14. 시간 순서가 어긋나 보일 때

수정 요청을 보낸 시각, 서버가 기록한 시각, 응답을 받은 시각은 다를 수 있습니다. 네트워크 지연이나 프로그램 처리 시간 때문에 화면에 보인 순서가 사건 발생 순서와 완전히 같지 않을 수 있습니다.

한국시간 표시와 원래 타임스탬프를 함께 저장하면 대조에 도움이 됩니다. 다만 시간 단위를 먼저 확인해야 합니다. 밀리초와 마이크로초를 혼동하면 실제로는 정상 기록인데 날짜가 크게 어긋나 보일 수 있습니다.

수정과 체결이 가까운 시점에 발생했다면 한쪽 자료만으로 전체 순서를 단정하지 않습니다. 현재 주문, 이력, 체결 및 계정 이벤트의 공통 식별자를 확인하고 자료가 설명하는 범위 안에서 판단해야 합니다.

시간 차이가 보인다고 원문 시각을 임의로 바꿔 맞추지 않아야 합니다. 표시용 시간대 변환과 원자료 수정은 다릅니다. 변환 규칙을 명시하고 원래 값을 남겨야 나중에도 같은 결론을 검증할 수 있습니다.

15. 자주 묻는 질문

Q1. 주문 수정 이력은 어디서 확인하나요?

현물 공식 API는 GET /api/v3/order/amendments를 안내합니다. 특정 앱 메뉴가 모든 계정에 동일하게 존재한다고 가정하지 않고, 사용하는 도구가 해당 조회를 지원하는지 확인해야 합니다.

Q2. 이력 조회는 주문을 바꾸나요?

이력 조회는 자료를 읽는 작업입니다. 실제 주문 수량을 바꾸는 수정 요청과 구분해야 합니다. 조회 방법을 설명하는 글의 예시를 실거래 변경 요청으로 대체하지 않아야 합니다.

Q3. origQty는 처음 주문한 수량인가요?

해당 수정 직전 수량으로 읽어야 합니다. 여러 번 수정했다면 각 행에서 값이 달라질 수 있습니다. 첫 주문 수량과 각 수정 직전 수량을 구분해야 변화가 연결됩니다.

Q4. origQty와 newQty의 차이는 체결량인가요?

아닙니다. 주문 수량 조건의 변화입니다. 실제 체결은 체결 내역과 누적 체결 필드에서 확인해야 합니다. 수정 감소분을 거래량에 더하면 잘못된 집계가 됩니다.

Q5. newQty가 현재 잔량인가요?

그렇게 단정하면 안 됩니다. 이미 체결된 수량과 조회 시점의 추가 체결 여부를 함께 확인해야 합니다. 총 주문 수량과 미체결 부분을 구분해야 합니다.

Q6. executionId는 tradeId와 같나요?

서로 다른 필드와 기록 종류입니다. 이름이나 숫자가 비슷해도 같은 사건으로 연결하지 않습니다. 수정 실행 기록과 매매 체결을 별도 자료로 다뤄야 합니다.

Q7. clientOrderId가 바뀌면 새 주문인가요?

반드시 그렇지는 않습니다. 공식 수정 기능에서는 clientOrderId가 바뀔 수 있습니다. orderId와 수정 전후 ID 관계를 함께 확인해야 합니다.

Q8. 기존 clientOrderId를 유지할 수 있나요?

현재 공식 FAQ는 관련 요청 항목으로 현재 값을 유지하는 방법을 설명합니다. 실제 적용 전 최신 파라미터와 지원 조건을 확인해야 하며, 유지 여부는 결과에서 검증해야 합니다.

Q9. 모든 주문 편집이 이력에 나오나요?

이 엔드포인트의 범위 안에서 확인해야 합니다. 취소 후 새 주문이나 다른 시장의 편집 기능까지 동일한 이력으로 제공된다고 가정하지 않습니다. 실제 수행한 작업부터 구분해야 합니다.

Q10. 이력이 비어 있으면 수정 실패인가요?

조회 대상과 작업 종류, 요청 성공 여부를 확인해야 합니다. 빈 결과만으로 실패를 확정하지 않습니다. 현재 주문 상태와 실제 응답을 함께 대조해야 합니다.

Q11. 수정 요청이 거절되면 주문이 없어지나요?

공식 Keep Priority 설명은 수정이 거절되면 주문이 변경되지 않는다고 안내합니다. 다만 현재 상태는 별도로 확인해야 합니다. 거절 이후 다른 체결이나 취소가 발생할 수 있기 때문입니다.

Q12. limit 1000은 수정 허용 횟수인가요?

아닙니다. 조회 페이지의 반환 행 수 설정입니다. 실제 수정 횟수 관련 필터와 다른 규칙이므로 같은 숫자로 해석하지 않아야 합니다.

Q13. 타임아웃이면 다시 수정하면 되나요?

먼저 현재 주문과 수정 이력을 확인해야 합니다. 응답을 놓쳤어도 실제 변경됐을 가능성이 있습니다. 결과를 모르는 상태에서 반복 변경하면 의도와 다른 상태가 될 수 있습니다.

Q14. REPLACED 이벤트는 새 주문이라는 뜻인가요?

이 글의 Keep Priority 문맥에서는 수정 성공을 알리는 실행 유형으로 설명됩니다. 일반 언어의 replace만 보고 취소·신규 주문이라고 단정하지 말고 해당 기능과 주문 ID를 확인해야 합니다.

Q15. 수정 이력만 있으면 손익을 계산할 수 있나요?

이력은 주문 조건 변화 자료입니다. 실제 체결과 수수료, 자산 이동을 대신하지 않습니다. 손익 분석에는 별도의 거래 자료와 명확한 계산 범위가 필요합니다.

16. 확인 체크리스트

• 현물 단일 주문의 수정 이력을 확인하는지 범위를 정했는가?
• symbol과 orderId를 실제 주문에서 확보했는가?
• Keep Priority와 Cancel Replace를 구분했는가?
• executionId와 tradeId를 다른 필드로 저장했는가?
• 각 행의 origQty를 수정 직전 값으로 읽었는가?
• 수량 감소분을 체결량으로 합산하지 않았는가?
• newQty와 미체결 부분을 구분했는가?
• clientOrderId 변경 관계를 보존했는가?
• 응답·이력·현재 주문을 같은 대상으로 대조했는가?
• 페이지 제한과 경계 중복을 확인했는가?
• 수정 허용 횟수와 조회 limit을 구분했는가?
• 타임아웃을 무조건 실패로 처리하지 않았는가?
• 원문 시각과 표시 시간대를 구분했는가?
• 확인되지 않은 이력을 추측으로 채우지 않았는가?

수정 기록을 시간표로 재구성하는 연습

아래는 가상 주문 하나에 대해 설명을 위해 만든 기록입니다. 실제 계정에서 나온 값이 아니며 체결과 수정의 관계를 나눠 읽는 연습입니다.

마지막 단계에서 총수량 8과 누적 체결 5가 같은 시점에 확인됐다고 가정하면 미체결 부분은 3입니다. 최초 12와 마지막 8의 차이 4는 수정에 따른 감소이고 실제 체결 5와 다른 값입니다. 두 값을 모두 거래량으로 더하면 9라는 잘못된 실적이 만들어집니다.

수정 이력에는 12에서 10, 10에서 8로 바뀐 흐름을 확인하고, 체결 자료에는 3과 2의 실제 거래를 확인해야 합니다. 어느 한 자료만으로 전체 시간표를 만들면 다른 종류의 사건을 추정하게 됩니다. 사건 종류별 출처를 함께 남기는 것이 좋습니다.

이 표는 추가 체결이 없다는 가정을 명시한 순간의 계산입니다. 이력을 조회하는 동안 또 거래됐다면 최신 상태는 달라질 수 있습니다. 운영 화면에서는 과거 표의 값과 최신 주문 응답을 같은 시점의 값처럼 섞지 않도록 표시해야 합니다.

검증 메모에 포함하면 좋은 내용

첫째, 변경을 요청한 의도를 적습니다. 예를 들어 노출을 줄이려는 수량 감소인지, 가격 변경을 하려던 것인지 구분합니다. 현재 기능이 지원하는 수량 감소와 다른 의도를 혼동했다면 요청 종류부터 다시 검토해야 합니다.

둘째, 요청 결과를 적습니다. 명시적인 성공 응답인지, 명시적인 거절인지, 응답을 받지 못했는지 구분합니다. 응답 미수신을 실패로 바꾸어 기록하면 이후 재시도 판단이 잘못될 수 있습니다.

셋째, 실제 이력의 전후 값을 연결합니다. 로컬 로그의 예정 수량과 서버 이력의 newQty가 일치하는지 확인하고, 다른 값이면 왜 그런지 조사합니다. 화면에 예정값을 먼저 표시하는 도구에서는 실제 반영값과 혼동하기 쉽습니다.

넷째, 현재 주문 상태와 체결 범위를 적습니다. 수정됐다는 사실이 주문이 계속 미체결 상태라는 뜻은 아닙니다. 이후 체결되거나 취소·종료됐을 수 있으므로 최신 결과를 따로 확인해야 합니다.

다섯째, 확인되지 않은 사항을 남깁니다. 어떤 페이지나 이벤트가 빠졌는지, 조회 시각이 다른지, clientOrderId 연결이 불명확한지 구체적으로 적으면 다음 확인 작업이 분명해집니다. 막연히 실패 또는 완료라고 표시하는 것보다 재검증에 유용합니다.

원문 이력은 수정하지 않고 이런 메모를 별도 파일이나 표에 남기는 편이 좋습니다. 분석자의 해석이 바뀌어도 원래 증거를 다시 읽을 수 있기 때문입니다. 거래 결과를 검증하는 목적에서는 깔끔한 최종 숫자보다 확인 가능한 연결 관계가 더 중요합니다.

핵심 정리

바이낸스 Order Amendment History 확인의 목적은 주문을 더 자주 수정하는 것이 아니라, 이미 일어난 변경을 정확히 설명하는 것입니다. 조건 변화와 실제 거래를 분리하고, 같은 주문의 식별자·수량·시각을 연결하면 잔량 오류와 중복 재시도를 줄이는 데 도움이 됩니다.

공식 확인 자료: Order Amend Keep Priority, 계정 조회 API, 거래 필터. 최신 지원 범위와 요청 조건을 실제 사용 전에 확인하세요.

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