바이낸스 Cancel Replace 뜻 2026｜취소·재주문·부분 실패 확인

바이낸스 Cancel Replace 뜻과 취소·재주문 결과 확인

바이낸스 Cancel Replace는 기존 주문을 취소하고 같은 거래쌍에 새 주문을 넣는 요청입니다. 한 번의 요청으로 두 동작을 다루지만, 결과까지 언제나 한꺼번에 성공하거나 실패한다고 생각하면 안 됩니다. 기존 주문의 취소 결과와 새 주문의 접수 결과를 각각 읽는 것이 핵심입니다.

특히 ‘수정 버튼을 눌렀다’는 사용자 경험만으로 원래 주문이 새 조건으로 바뀌었다고 판단하기 쉽습니다. 실제로 취소·재주문 방식이 사용됐다면 기존 주문과 새 주문은 별개이며, 취소만 성공하거나 신규 접수만 성공하는 등 처리 결과가 나뉠 수 있습니다.

이 글은 2026년 10월 26일 확인한 Binance Spot 공식 REST API 문서를 기준으로 cancelReplaceMode, 취소 제한, 신규 주문 결과와 복구 순서를 설명합니다. 일반 앱의 모든 수정 버튼이 이 API를 사용한다고 단정하지 않습니다. 아래 주문번호·가격·수량은 결과 해석을 위한 가상값이며 실제 주문 권유가 아닙니다.

가장 먼저 기억할 원칙

취소 성공은 신규 주문 성공이 아니고, 신규 주문 성공은 기존 주문 취소 성공이 아닙니다. 응답의 가장 바깥쪽 메시지만 읽고 끝내면 현재 시장에 어떤 주문이 남아 있는지 잘못 파악할 수 있습니다.

또한 취소는 과거에 이미 발생한 체결을 되돌리지 않습니다. 원래 10을 주문했는데 4가 거래된 뒤 남은 부분이 취소됐다면 실제 거래 4는 별도 결과로 남습니다. 이전 주문 전체를 미실행으로 간주하고 10을 다시 넣으면 목표보다 더 큰 거래가 발생할 수 있습니다.

마지막으로 통신 오류와 거래소의 명시적 거절은 다릅니다. 결과를 못 받았다는 이유만으로 요청 전체가 실패했다고 가정하지 않습니다. 기존 주문과 새 식별자를 조회해 실제 처리 상태를 확인하는 절차가 필요합니다.

Cancel Replace가 필요한 상황을 구분합니다

기존 주문의 가격이나 조건을 바꾸려는 상황에서는 원래 주문을 유지할지, 종료하고 새 주문을 만들지 판단해야 합니다. Cancel Replace는 기존 주문 종료와 신규 주문 생성이 함께 필요한 경우를 이해하는 개념입니다. 다만 어떤 주문 유형과 조건 조합이 가능한지는 현재 공식 파라미터 규칙을 확인해야 합니다.

수량만 줄이고 기존 시간 우선순위를 유지하려는 목적이라면 Order Amend Keep Priority와 비교할 필요가 있습니다. 모든 변경을 무조건 취소·재주문으로 처리하면 이전 주문의 순서와 기록 연속성을 잃을 수 있습니다. 반대로 지원 범위를 넘는 변경을 단순 수량 수정으로 처리할 수는 없습니다.

주문을 완전히 끝내려는 상황이라면 새 주문 생성 자체가 필요 없는 경우도 있습니다. Cancel Replace라는 기능을 사용하기로 먼저 결정하기보다, 원하는 최종 상태가 무엇인지 먼저 적는 편이 좋습니다. ‘이전 주문은 닫고 새 조건으로 하나만 남긴다’와 ‘모든 주문을 종료한다’는 서로 다른 목적입니다.

하나의 요청에 두 개의 결과가 생기는 구조

공식 REST 경로는 POST /api/v3/order/cancelReplace입니다. 현재 문서는 같은 심볼의 기존 주문을 취소하고 신규 주문을 배치하는 동작으로 설명합니다. 처리 결과에는 취소 관련 응답과 새 주문 관련 응답이 분리되어 나타납니다. Binance 공식 거래 API

네트워크 요청은 하나일 수 있지만 거래 상태는 여러 조합으로 나뉩니다. 그래서 내부 기록도 ‘성공 여부’라는 하나의 칸만 두기보다 취소 결과와 신규 결과를 따로 저장하는 편이 좋습니다. 사람이 확인하는 보고서에도 같은 구분을 적용할 수 있습니다.

HTTP 상태나 상위 오류 코드 역시 응답 본문을 대신하지 않습니다. 부분 실패를 설명하는 경우에는 하위 결과를 끝까지 읽어야 합니다. 오류 메시지가 보였다는 이유로 이미 성공한 취소나 신규 주문까지 없는 일로 처리하면 안 됩니다.

STOP_ON_FAILURE와 ALLOW_FAILURE 차이

STOP_ON_FAILURE: 취소가 실패하면 신규 주문을 시도하지 않음

STOP_ON_FAILURE는 취소 요청이 실패했을 때 새 주문 배치를 시도하지 않는 모드입니다. ‘원래 주문이 정리돼야 새 주문을 시도한다’는 의도를 이해하는 데 도움이 됩니다. 그러나 취소가 성공하면 새 주문도 반드시 성공한다는 뜻은 아닙니다.

원래 주문 취소는 성공했지만 신규 주문이 다른 조건에서 거절될 수 있습니다. 이 경우 기존 주문으로 자동 복구된다고 가정해서도 안 됩니다. 현재 열린 주문이 없는 상태가 되었는지, 과거 체결이 있었는지를 다시 확인해야 합니다.

또한 취소 실패에는 여러 원인이 있을 수 있습니다. 대상 식별자가 틀렸거나 이미 상태가 달라졌을 수도 있습니다. 실패라는 단어만 보고 기존 주문이 계속 열려 있다고 확정하지 말고 최신 상태를 조회합니다.

ALLOW_FAILURE: 취소 실패 뒤에도 신규 주문을 시도할 수 있음

ALLOW_FAILURE는 취소가 실패해도 새 주문 배치를 시도하는 모드입니다. 이 모드의 뜻을 ‘실패를 무시해도 괜찮다’로 읽으면 위험합니다. 이전 주문 상태와 새 주문 상태를 동시에 확인해야 할 필요가 더 커집니다.

취소 실패 후 신규 접수가 성공했다면, 취소 대상이 이미 체결된 것인지, 아직 남은 것인지 또는 잘못 지정된 것인지에 따라 전체 노출이 달라집니다. 단순히 ‘교체 완료’라고 적는 대신 두 주문을 각각 조회해야 합니다.

어떤 모드를 선택할지는 주문 운영 목적과 실패 시 허용할 상태를 기준으로 판단해야 합니다. 이 글은 특정 모드를 모든 사용자에게 권하는 자료가 아닙니다. 모드 이름보다 처리 중 어떤 상태를 허용하는지가 더 중요합니다.

주요 결과 조합을 읽는 표

이 표는 읽는 틀입니다. 모든 모드와 한도 조건에서 모든 조합이 똑같이 발생한다는 뜻은 아닙니다. 현재 공식 문서의 모드별 처리표와 실제 응답을 함께 확인해야 합니다.

NOT_ATTEMPTED도 FAILURE와 구분합니다. 전자는 신규 주문 배치가 시도되지 않았다는 의미이고, 후자는 해당 처리에 실패가 보고됐다는 의미입니다. 둘을 같은 문자열로 바꾸면 나중에 어느 단계까지 실행됐는지 확인하기 어려워집니다.

더 주의할 점은 현재 공식 문서가 NOT_ATTEMPTED인 신규 주문도 미체결 주문 카운트를 1 증가시키는 동작을 설명한다는 것입니다. 주문이 생성되지 않았을 것 같다는 직관만으로 한도 사용량도 0이라고 계산하면 안 됩니다.

취소 대상을 정확히 지정하는 방법

현재 문서는 cancelOrderId 또는 cancelOrigClientOrderId로 취소 대상을 지정하도록 설명합니다. 두 값을 모두 넣는 경우에는 주문번호로 찾은 대상과 사용자 지정 식별자의 일치 여부까지 확인하는 조건이 있습니다. 값을 많이 넣는다고 무조건 더 잘 처리되는 것은 아닙니다.

예를 들어 거래소 주문번호는 A 주문의 값이고 사용자 지정 식별자는 B 주문의 값이라면, 서로 같은 주문을 가리키지 않습니다. 이런 조합은 ‘둘 중 하나가 맞으면 되겠지’라는 의도로 보내면 안 됩니다. 대상 식별은 선택지를 많이 주는 문제가 아니라 하나의 주문을 정확히 가리키는 문제입니다.

긴 주문번호는 문자열로 보존하는 편이 검증에 유리합니다. 스프레드시트나 일부 프로그램이 큰 정수를 반올림하면 비슷해 보이지만 다른 식별자가 될 수 있습니다. 화면에서 복사한 값과 저장한 값이 같은지 전체 문자열로 비교해야 합니다.

기존 주문과 새 주문의 사용자 지정 식별자도 별도로 기록합니다. 취소를 식별하는 값과 새 주문을 식별하는 값을 같은 열에 계속 덮어쓰면 이전 기록을 찾기 어려워집니다. 요청 단위의 기록에는 원래 대상과 새 대상의 연결 관계를 남깁니다.

cancelRestrictions는 상태 조건입니다

cancelRestrictions에는 현재 문서상 ONLY_NEW, ONLY_PARTIALLY_FILLED 같은 조건이 있습니다. 이름 그대로 특정 주문 상태에서만 취소가 성공하도록 제한하는 의미를 확인해야 합니다. 부분 체결 여부를 마음대로 바꾸는 옵션이 아닙니다.

사전 조회에서 NEW였던 주문이 요청 처리 전에 PARTIALLY_FILLED로 바뀔 수 있습니다. 이때 상태 제한이 왜 거절됐는지 이해하려면 요청 시각과 실제 체결 시각, 최종 주문 상태를 함께 봐야 합니다. 화면을 봤던 시점과 처리 시점의 차이를 고려해야 합니다.

상태 제한이 걸렸다고 이를 제거해 즉시 재시도하는 것이 항상 맞는 해결책은 아닙니다. 그 제한을 넣은 목적이 ‘체결이 시작되면 교체하지 않겠다’였다면, 거절은 의도한 보호 조건이 작동한 결과일 수 있습니다. 오류를 없애는 것과 원래 의도를 지키는 것을 구분합니다.

신규 주문 조건은 따로 검증해야 합니다

새 주문은 새로운 주문입니다. 주문 유형에 따른 필수 항목, 가격과 수량 필터, 잔고, 허용되는 옵션을 별도로 확인해야 합니다. 기존 주문이 한 번 접수됐다는 사실이 새 조건도 유효하다는 증거는 아닙니다.

특히 가격을 계산해 재주문하는 경우에는 Tick Size, 수량을 계산하는 경우에는 Step Size와 관련 필터를 확인해야 합니다. 숫자를 소수점 몇 자리로 표시할 수 있다는 사실과 실제 주문 가능한 단위에 맞는다는 사실은 다릅니다.

공식 문서는 취소와 신규 배치를 처리하기 전에 필터와 주문 카운트를 평가한다고 설명합니다. 따라서 잘못된 새 주문을 보내면 언제나 기존 주문부터 취소되고 나중에 오류가 나온다고 가정해서는 안 됩니다. 처리 순서를 임의로 재구성하지 말고 응답에 나타난 실제 결과를 읽습니다.

신규 주문에 LIMIT_MAKER 같은 조건을 사용한 경우에는 현재 시장과의 관계도 영향을 줄 수 있습니다. 공식 응답 예시는 새 주문이 즉시 맞물려 taker가 될 조건이라 거절되는 상황을 보여 줍니다. 예제의 오류를 모든 지정가 주문의 공통 오류로 확대하지 않도록 합니다.

주문 우선순위와 기록의 연속성

Cancel Replace로 만들어진 주문은 새 주문번호와 새 시간 우선순위를 가집니다. 같은 가격과 같은 수량을 다시 넣어도 예전 주문의 도착 순서가 자동으로 이어지지 않습니다. 이를 모르고 자주 교체하면 예상한 대기 순서와 실제 순서가 달라질 수 있습니다.

반면 수량 감소만 필요하고 지원 조건이 맞는다면 우선순위 유지 수정과 비교할 수 있습니다. 두 기능은 이름만 다른 같은 동작이 아닙니다. 주문번호의 변화, 지원하는 변경 범위와 확인할 결과가 다릅니다.

사례 1: 취소와 신규 접수가 모두 성공한 경우

가상 주문 A는 가격 100에 수량 8로 제출됐고 아직 체결이 없습니다. 사용자는 같은 거래쌍에서 조건을 변경한 새 주문 B를 만들기로 했습니다. 응답에는 취소 SUCCESS와 신규 SUCCESS가 모두 나타납니다.

이 경우에도 ‘모든 거래 완료’라고 기록하지 않습니다. A의 취소와 B의 접수가 성공한 것입니다. B가 실제로 체결됐는지, 열린 상태로 대기하는지 또는 이후 다른 이유로 종료됐는지는 별도 조회가 필요합니다.

기록에는 A와 B의 주문번호를 연결해 둡니다. A의 최종 누적 체결이 0인지 실제로 확인하고, B의 요청 수량·접수 수량과 상태를 확인합니다. 신규 성공 응답이 간단한 ACK 형태라면 없는 필드를 추측해서 채우지 않습니다.

또한 B의 대기 순서를 A의 과거 순서로 계산하지 않습니다. 교체는 새 주문 생성이라는 사실을 성과 분석에도 반영해야 합니다. 요청이 성공한 시각과 실제 거래가 시작된 시각을 나눠 두면 주문 처리 지연과 체결 대기를 구분할 수 있습니다.

사례 2: 취소는 성공했지만 새 주문이 거절된 경우

사용자 B는 기존 주문을 교체하려고 했지만 결과는 취소 SUCCESS, 신규 FAILURE입니다. 이때 화면에 큰 오류 문구가 보였다고 기존 주문이 그대로 남았을 것이라 생각하면 안 됩니다. 응답의 취소 결과가 이미 성공을 알려 주기 때문입니다.

먼저 기존 주문의 최종 상태와 과거 누적 체결을 확인합니다. 다음으로 신규 오류를 읽고 현재 열린 주문 목록에 새 주문이 있는지 확인합니다. 취소만 됐다면 원래 계획했던 대기 주문이 없는 상태일 수 있습니다.

복구를 위해 원래 주문 내용을 그대로 다시 보내는 것도 자동 정답은 아닙니다. 시장과 잔고가 달라졌고 과거 체결이 있었을 수 있습니다. 새 주문이 필요한지, 필요하다면 어느 양과 조건인지 현재 상태를 기준으로 다시 판단해야 합니다.

결과 보고는 ‘교체 실패’ 한 줄보다 ‘기존 주문 취소 성공, 신규 주문 거절, 신규 오류 확인’처럼 구체적인 편이 좋습니다. 이 표현만으로도 다음 사람이 어떤 대상을 조회해야 하는지 알 수 있습니다.

사례 3: 취소 실패 뒤 신규 주문만 성공한 경우

ALLOW_FAILURE를 사용한 가상 사례에서 취소 FAILURE, 신규 SUCCESS가 반환됐다고 합시다. 새 주문이 접수됐다는 사실만 보고 교체가 완료됐다고 기록하면 기존 주문의 상태를 놓치게 됩니다.

취소 실패의 원인은 기존 주문이 이미 종료됐기 때문일 수도 있고, 잘못된 대상을 지정했기 때문일 수도 있습니다. 취소 실패 자체만으로 원래 주문이 여전히 열려 있다고도, 이미 없다고도 단정할 수 없습니다. 실제 대상을 조회하는 단계가 필요합니다.

만약 원래 관리하려던 주문이 여전히 열려 있다면 신규 주문과 함께 전체 노출을 계산해야 합니다. 반대로 원래 주문이 이미 거래됐다면 그 실제 체결을 신규 주문과 합산해 목표 대비 상태를 확인해야 합니다. 두 경우 모두 새 주문만 보는 것으로는 충분하지 않습니다.

이 사례는 오류 처리의 목적이 단순한 성공률 향상이 아니라는 점을 보여 줍니다. 한 번 더 시도해서 성공 메시지를 얻는 것보다, 현재 실제 주문 수와 거래량을 정확히 파악하는 것이 우선입니다.

사례 4: 원래 주문이 부분 체결된 뒤 교체된 경우

가상의 전체 목표 수량은 10입니다. 기존 주문에서 4가 실제 거래됐고 나머지가 열린 상태입니다. 사용자는 조건을 바꾸고 싶어 합니다. 여기서 원래 주문의 수량 10을 신규 주문에 그대로 복사하면 전체 목표와 어긋날 수 있습니다.

이미 거래된 4는 취소로 되돌아가지 않습니다. 전체 목표를 여전히 10으로 유지한다는 가정 아래에서 추가로 필요한 양을 검토해야 합니다. 다만 요청 중 추가 체결이 발생할 수 있으므로 사전 조회의 잔량을 최종값으로 고정해서는 안 됩니다.

취소 응답과 최종 거래 내역에서 누적 체결이 4인지, 그 이후 더 늘었는지 확인합니다. 신규 주문의 실제 접수·체결도 따로 확인합니다. 목표량과 체결량, 열린 주문량을 한 줄에 섞지 말고 각각 표시합니다.

예를 들어 보고서에 ‘목표 10, 이전 실제 체결 4, 새 주문 수량 6’이라고 적는 것은 가정이 맞는 시점의 설명입니다. 그 뒤 상태가 바뀌면 최신 기록으로 갱신해야 합니다. 주문 관리표는 한 번 계산한 목표 산식보다 실제 결과를 우선해야 합니다.

사례 5: 응답이 끊겨 성공 여부를 모르는 경우

사용자 E의 프로그램은 요청을 보낸 후 통신 시간 초과를 받았습니다. 결과를 받지 못했지만 거래소에서 아무 처리도 하지 않았다고 확정할 수는 없습니다. 이 상태에서 같은 교체 요청을 반복하면 원래 요청과 재시도가 겹칠 수 있습니다.

E는 기존 주문번호와 신규 사용자 지정 식별자를 이용해 각각의 상태를 조회합니다. 기존 주문의 취소 여부, 새 주문의 존재와 누적 체결을 확인하고 요청 로그와 연결합니다. 사용자 데이터 스트림을 수신했다면 해당 이벤트도 대조합니다.

조회가 일시적으로 늦거나 결과가 모순된다면 미확인 상태를 유지합니다. 확인되지 않은 주문을 실패로 바꿔 새로운 주문을 만드는 것보다, 증거가 확보될 때까지 관련 변경을 억제하는 편이 중복 위험을 줄입니다.

최종 기록에는 통신 오류가 있었다는 사실과 실제 확인된 결과를 모두 남깁니다. 통신이 실패했지만 거래 처리가 성공했다면 두 사실은 동시에 참일 수 있습니다. 시스템 상태와 거래 상태를 분리하면 복구 과정이 훨씬 명확해집니다.

주문 한도에 걸렸을 때의 별도 옵션

orderRateLimitExceededMode는 미체결 주문 한도 초과 상황과 관련된 옵션입니다. 기본 동작인 DO_NOTHING과 취소 처리 쪽을 허용하는 CANCEL_ONLY를 현재 문서에서 구분합니다. 이 옵션은 cancelReplaceMode와 목적이 다릅니다.

cancelReplaceMode는 취소 실패 뒤 신규 주문을 시도할지와 관련되고, orderRateLimitExceededMode는 한도 초과 상황의 처리와 관련됩니다. 두 값을 같은 ‘실패 무시 옵션’으로 합치면 어떤 조건에서 무엇을 허용하는지 불분명해집니다.

CANCEL_ONLY라는 이름을 보고 모든 상황에서 취소 성공이 보장된다고 생각하지도 않습니다. 대상 주문의 실제 상태와 취소 결과는 여전히 확인해야 합니다. 그리고 신규 주문 제한을 우회하는 기능으로 해석해서는 안 됩니다.

공식 문서의 예시는 한도 초과에서 취소는 성공하고 신규 주문은 한도 오류로 실패하는 결과를 보여 줍니다. 이 경우 새 주문이 들어가지 않았다는 사실을 기록해야 합니다. ‘기존 주문을 취소했으니 한도가 즉시 복구된다’고 추정해 반복 제출하지 않습니다.

연결 주문 목록에 속한 주문의 취소

현재 공식 문서는 Cancel Replace에서 주문 목록에 속한 개별 주문을 취소 대상으로 지정하더라도 전체 주문 목록을 취소하는 것과 같은 결과가 될 수 있음을 설명합니다. 목록에 속한 주문을 다룰 때는 한 행만 지우는 작업으로 생각하지 않아야 합니다.

예를 들어 연결된 조건 주문을 관리하면서 한 주문번호만 기록했다면, 교체 후 나머지 주문의 상태 변화를 놓칠 수 있습니다. 요청 전에는 목록 식별자와 구성 주문을 확인하고, 요청 후에는 영향을 받은 목록 전체를 조회해야 합니다.

새 주문이 접수됐다고 기존 연결 구조가 자동으로 재생성되는 것도 아닙니다. 새 요청에 무엇을 제출했는지와 어떤 주문이 실제 생성됐는지를 확인해야 합니다. 단일 주문을 새로 만들었다면 이전 목록의 조건 관계까지 복원됐다고 보고하지 않습니다.

이 부분은 주문 관리의 목적과 연결됩니다. 단순히 가격 한 칸을 바꾸려던 사용자가 의도치 않게 다른 조건 주문까지 종료시키지 않도록, 변경 대상의 범위를 먼저 확인하는 습관이 필요합니다. 기능 사용 전에 목록 여부를 확인할 이유입니다.

결과를 저장하는 최소 기록 구조

교체 요청 한 건에는 대상 심볼, 이전 주문번호, 새 사용자 지정 식별자, 모드, 취소 제한과 제출 시각을 남깁니다. 결과에는 취소 결과·응답, 신규 결과·응답, 최종 확인 시각을 따로 둡니다. 실제 거래는 별도 목록과 연결합니다.

기존 주문의 체결과 신규 주문의 체결을 합산할 때는 같은 거래를 중복 수신한 것인지 확인해야 합니다. 요청 응답에 들어 있는 체결 정보와 나중에 거래 목록에서 읽은 같은 체결을 두 번 더하면 안 됩니다. 주문별 누적값과 개별 체결값도 구분합니다.

상태표에는 ‘미확인’이 들어갈 자리가 있어야 합니다. 성공과 실패만 허용하면 통신 중단을 억지로 둘 중 하나로 분류하게 됩니다. 실제 확인 전까지 미확인으로 두는 것이 잘못된 자동 복구를 막는 데 도움이 됩니다.

문의 자료를 정리할 때는 비밀 키나 서명 문자열을 포함하지 않습니다. 오류 분석에 필요한 것은 보통 상품·심볼·주문 식별자·시각·모드·응답 정보입니다. 민감한 인증값을 공개 게시물이나 일반 로그에 넣는 것은 문제 해결에 필요하지 않습니다.

재시도 전 점검 절차

첫 단계는 ‘실패한 단계가 무엇인가’를 찾는 것입니다. 전체 요청이 접수되기 전에 거절됐는지, 취소가 실패했는지, 신규 배치가 실패했는지, 아니면 결과 자체가 미확인인지 나눕니다. 각각의 다음 행동이 다르기 때문입니다.

두 번째는 실제 상태 확인입니다. 취소 대상과 새 주문을 조회하고, 현재 잔고와 과거 체결을 연결합니다. 이 과정 없이 입력만 수정하면 이미 성공한 처리를 다시 실행하거나 원래 목표보다 많은 양을 만들 수 있습니다.

세 번째는 원인 해결입니다. 잘못된 단위라면 필터를, 권한 문제라면 계정 조건을, 한도 문제라면 해당 제한과 안내를 확인합니다. 실패 원인이 그대로인 상태에서 전송 속도만 높이는 것은 해결책이 아닙니다.

마지막으로 새로운 거래 의도를 확인합니다. 시간이 흐른 뒤에도 원래 가격과 수량이 유효한지는 자동으로 보장되지 않습니다. 이전 요청을 성공시키는 것 자체보다 현재 원하는 최종 상태를 정확히 만드는 것이 중요합니다.

교체 작업의 목표 상태를 문장으로 정의합니다

교체를 요청하기 전에 원하는 최종 상태를 짧게 적으면 오류 처리 기준이 명확해집니다. 예를 들어 ‘기존 주문 A는 종료하고, 새 조건의 주문 B 하나만 유지한다’는 목표라면 A와 B를 모두 확인해야 합니다. B의 성공만으로 목표가 달성됐다고 볼 수 없습니다.

다른 예로 ‘기존 주문에 체결이 시작됐으면 교체를 진행하지 않는다’는 목표가 있다면 상태 제한의 의미가 중요합니다. 요청 중 부분 체결이 발생해 취소가 거절된 것을 단순 장애로 보고 조건을 제거하면 원래 의도를 어길 수 있습니다. 오류가 원하는 제한을 지킨 결과인지도 검토해야 합니다.

목표를 수량으로 표현할 때는 과거 체결과 현재 열린 양을 분리합니다. 전체 목표가 10이라는 말만으로 새 주문도 10이 되는 것은 아닙니다. 이미 실제로 거래된 양과 다른 열린 주문을 함께 고려해야 현재 계획과 실제 상태를 비교할 수 있습니다.

이 과정은 시장의 움직임을 예측하는 일이 아닙니다. 이미 확인된 주문 상태를 바탕으로 같은 거래를 두 번 요청하지 않기 위한 확인입니다. 확인할 수 없는 값은 추정값으로 표시하고, 그 추정치를 실제 주문 결과로 바꿔 기록하지 않습니다.

상태표를 갱신할 때 순서가 뒤바뀌는 경우

실시간 이벤트와 REST 응답이 서로 다른 순서로 도착할 수 있습니다. 취소 응답이 화면에 표시되기 전에 새 주문 관련 이벤트를 먼저 볼 수도 있습니다. 사용자에게 도착한 순서와 거래소에서 처리된 사건의 순서를 동일하게 가정하면 기록이 어긋날 수 있습니다.

이전 주문 A의 상태는 A의 식별자로, 신규 주문 B의 상태는 B의 식별자로 저장합니다. 화면의 ‘현재 주문’ 한 행을 모든 이벤트가 덮어쓰게 만들면 오래된 A의 응답이 B의 상태를 바꿔 버릴 수 있습니다. 요청 단위와 주문 단위의 자료를 분리하는 이유입니다.

교체 작업 전체의 상태는 두 주문의 확인 결과를 모아 계산합니다. A가 취소되고 B가 접수됐다는 증거가 있으면 교체 처리를 확인할 수 있지만, B의 체결은 별도 상태로 관리합니다. 통신 오류가 뒤늦게 나타나더라도 이미 확인된 실제 주문 존재를 지우지 않습니다.

이벤트를 두 번 수신했을 때는 수신 횟수와 실제 사건 수를 구분합니다. 같은 신규 주문 성공을 두 번 받았다고 새 주문 두 개가 생긴 것은 아닐 수 있습니다. 반대로 값이 비슷한 서로 다른 주문을 하나로 합쳐서도 안 됩니다. 실제 식별자를 기준으로 대조해야 합니다.

사후 점검에서 묻는 네 가지 질문

첫째, 이전 주문의 최종 상태와 누적 체결을 확인했는가입니다. 둘째, 신규 주문의 실제 존재와 식별자를 확인했는가입니다. 셋째, 두 주문을 합친 거래량과 현재 열린 양이 의도한 범위를 벗어나지 않았는가입니다. 넷째, 미확인 요청이 남아 있어 후속 재시도와 충돌할 가능성이 없는가입니다.

이 네 질문에 답할 수 있다면 성공 메시지 하나만 보는 것보다 실제 결과를 정확히 설명할 수 있습니다. 답할 수 없는 항목은 어떤 조회가 필요한지 구체적으로 남깁니다. 막연한 ‘재시도 필요’ 대신 ‘신규 식별자 존재 확인 필요’처럼 다음 확인 대상을 적는 편이 좋습니다.

자주 묻는 질문 FAQ

1. Cancel Replace는 단순 주문 수정인가요?

기존 주문 취소와 새 주문 생성을 함께 다루는 방식입니다. 기존 주문을 제자리에서 바꾸는 수량 감소 수정과는 다릅니다. 주문번호와 시간 우선순위, 결과 확인 방법을 구분해야 합니다.

2. 한 요청이면 둘 다 같이 성공하나요?

항상 그렇지 않습니다. 취소와 신규 결과가 나뉠 수 있으므로 각 필드를 확인해야 합니다. 부분 실패를 전체 실패나 전체 성공으로 단순화하지 않는 것이 핵심입니다.

3. STOP_ON_FAILURE면 새 주문 성공이 보장되나요?

취소 실패 때 신규 배치를 시도하지 않는다는 뜻입니다. 취소 성공 뒤 신규 주문이 다른 조건에서 거절될 수 있습니다. 새 주문의 결과를 별도로 읽어야 합니다.

4. ALLOW_FAILURE는 어떤 점에 주의하나요?

취소 실패 뒤에도 신규 배치를 시도할 수 있습니다. 따라서 기존 주문이 실제로 어떤 상태인지 반드시 확인해야 합니다. 두 주문 또는 과거 체결과 새 주문이 함께 전체 노출에 영향을 줄 수 있습니다.

5. NOT_ATTEMPTED는 무엇인가요?

신규 주문 배치를 시도하지 않았다는 의미입니다. 시도 후 거절된 FAILURE와 구분해 저장합니다. 현재 문서에는 이 경우의 주문 카운트 증가도 별도로 설명되어 있으므로 사용량이 없다고 추측하지 않습니다.

6. 취소 성공 후 새 주문 실패면 원래 주문이 복구되나요?

자동 복구를 가정하지 않습니다. 기존 주문의 최종 상태와 신규 오류를 확인해야 합니다. 다시 주문할지 여부도 현재 체결·잔고·거래 의도를 확인한 뒤 결정합니다.

7. 이미 체결된 수량도 취소되나요?

이미 발생한 거래는 취소·재주문으로 되돌리는 대상이 아닙니다. 과거 체결을 남겨 두고 새 주문 규모를 판단해야 합니다. 원래 총수량을 무조건 다시 넣으면 중복 거래가 생길 수 있습니다.

8. 같은 가격이면 우선순위가 유지되나요?

새 주문은 새 시간 우선순위를 갖습니다. 같은 숫자의 가격을 입력했다는 이유로 예전 순서를 이어받지 않습니다. 수량 감소만 필요하면 별도의 우선순위 유지 기능과 비교할 수 있습니다.

9. 대상 주문번호와 clientOrderId를 둘 다 보내도 되나요?

현재 문서의 일치 조건을 확인해야 합니다. 서로 다른 주문의 값을 섞으면 안 됩니다. 주문번호와 사용자 지정 식별자가 같은 실제 주문을 가리키는지 먼저 검증합니다.

10. ONLY_NEW 조건에서 부분 체결되면 어떻게 하나요?

요청 처리 시점의 상태가 조건과 맞는지에 따라 결과를 확인해야 합니다. 사전 화면의 상태를 영구적인 값으로 보지 않습니다. 제한을 제거하기 전에 원래 제한의 목적을 다시 확인합니다.

11. CANCEL_ONLY면 한도를 우회하나요?

신규 주문 제한을 우회하는 기능으로 해석하지 않습니다. 한도 초과 상황의 취소 처리와 신규 처리 결과를 나눠 읽어야 합니다. 실제 취소 성공 여부도 응답으로 확인합니다.

12. 주문 목록 안의 하나만 교체할 수 있나요?

목록에 속한 주문의 취소 영향은 단독 주문과 다를 수 있습니다. 현재 문서의 전체 목록 취소 관련 조건을 확인하고 구성 주문 전체를 점검합니다. 새 주문이 이전 연결 구조를 자동 복원한다고 생각하지 않습니다.

13. HTTP 오류만 기록하면 충분한가요?

부분 실패에서는 하위 취소·신규 결과가 중요합니다. 상위 코드만 저장하면 실제로 성공한 처리를 놓칠 수 있습니다. 응답 본문과 실제 주문 조회를 함께 보관하는 편이 좋습니다.

14. 응답이 없으면 같은 요청을 반복해도 되나요?

먼저 기존 주문과 새 식별자의 실제 상태를 확인해야 합니다. 처리 결과 미확인을 명시적인 실패로 바꾸지 않습니다. 중복 주문이 생기지 않도록 복구 절차를 분리합니다.

15. 일반 앱의 수정 버튼도 동일한가요?

이 글은 Spot API의 문서상 동작을 설명합니다. 앱의 특정 버튼 내부 구현은 별도 확인이 필요합니다. 화면 안내와 실제 주문번호·상태 변화를 기준으로 판단하십시오.

실전 확인 체크리스트

• [ ] 기존 주문을 유지할지 새 주문으로 바꿀지 목적을 정했다.
• [ ] 상품·계정·심볼을 확인했다.
• [ ] 취소 대상 식별자가 같은 주문을 가리킨다.
• [ ] 기존 누적 체결과 현재 잔량을 확인했다.
• [ ] 취소 실패 뒤 신규 시도 여부를 이해했다.
• [ ] cancelRestrictions의 목적을 확인했다.
• [ ] 신규 주문의 가격·수량·유형 조건을 점검했다.
• [ ] 한도 초과 처리 옵션을 별도로 이해했다.
• [ ] 연결 주문 목록에 미칠 영향을 확인했다.
• [ ] 취소 결과와 신규 결과를 각각 기록했다.
• [ ] 새 주문번호와 기존 주문번호를 연결했다.
• [ ] 실제 체결을 중복 집계하지 않았다.
• [ ] 응답 미확인 상태에서 맹목적으로 재전송하지 않았다.
• [ ] 최종 열린 주문과 잔고를 대조했다.

핵심 정리

바이낸스 Cancel Replace를 사용할 때는 ‘교체 성공’이라는 한 문장보다 취소 결과와 신규 주문 결과를 나눠 확인하는 습관이 중요합니다. 기존 체결을 보존하고 새 주문을 별도로 추적해야 중복 실행과 상태 오해를 줄일 수 있습니다.

이 글은 주문 처리 구조를 설명하는 정보성 자료입니다. 투자 권유나 특정 주문 방식의 성과 보장이 아니며, 실제 이용 전 최신 공식 문서와 계정·상품·심볼의 조건을 확인하십시오.