바이낸스 Expiry Reason 뜻 2026｜주문 만료 사유·부분 체결·종료 기록 읽기

바이낸스 Expiry Reason 뜻 2026｜주문 만료 사유·부분 체결·종료 기록 읽기

바이낸스 Expiry Reason은 현물 주문이 만료되거나 특정 종료 처리를 거친 배경을 읽는 사유 정보입니다. 주문의 status가 “현재 어떤 상태인가”를 보여준다면, expiryReason 또는 관련 이벤트의 eR은 “왜 그 처리가 발생했는가”를 이해하는 데 도움을 줍니다.

주문에 EXPIRED가 표시됐다고 단순히 시간이 오래 지나서 끝났다고 생각하면 안 됩니다. IOC의 남은 수량, FOK의 전량 체결 조건, 유동성 부족, 가격 실행 규칙, 연결된 주문의 종료 등 서로 다른 원인이 있을 수 있습니다.

이 글은 2026년 11월 3일 Binance Spot 공식 주문 응답과 열거형 정의를 기준으로 작성했습니다. 기존 POV Order Expiry의 예약 유효기간 설명과는 다른 주제입니다. 여기서는 현물 주문 기록에 나타나는 종료 사유를 해석하는 방법을 다룹니다.

상태와 사유를 먼저 구분하기

주문 상태는 결과의 큰 범주입니다. NEW, PARTIALLY_FILLED, FILLED, CANCELED, EXPIRED, EXPIRED_IN_MATCH처럼 현재 주문의 단계를 나타냅니다.

사유는 그 상태에 이른 배경을 더 세부적으로 설명합니다. 같은 EXPIRED라도 주문 유형과 당시 조건에 따라 확인해야 할 항목이 달라집니다.

따라서 화면이나 보고서에는 상태와 사유를 별도 열로 두는 편이 명확합니다. 두 값을 하나의 문자열로 덮어쓰면 나중에 “부분 체결은 있었는가”, “사용자가 취소했는가”, “연결 주문 때문인가”를 구분하기 어려워집니다.

사유를 확인해도 실제 체결량을 생략할 수 없습니다. 일부 체결 후 남은 수량이 만료되는 경우가 있기 때문입니다. “주문 만료”와 “거래가 전혀 없었음”은 같은 말이 아닙니다.

어디에서 확인하는 정보인가

공식 REST 주문 응답 문서는 expiryReason을 조건부 필드로 설명하며, 만료된 주문의 원인을 나타내는 예시로 INSUFFICIENT_LIQUIDITY를 보여줍니다. 공식 열거형 문서에는 Expiry Reasons와 eR 표기가 제시되어 있습니다.

자료를 읽을 때는 REST 응답의 필드명과 사용자 데이터 이벤트의 짧은 키 이름을 구분해야 합니다. 다른 전송 형식에서 이름이 다르다고 전혀 다른 개념이라고 판단하거나, 모든 엔드포인트가 항상 동일 필드를 반환한다고 가정하면 안 됩니다.

특정 화면에 이 값이 그대로 노출되는지는 별도 확인 사항입니다. 이 글은 공식 API 기록의 의미를 설명하며 확인하지 않은 앱의 메뉴 위치나 한국어 번역명을 만들지 않습니다.

사유 필드가 보이지 않을 때

필드가 조건부라면 모든 응답에 항상 나타나는 것은 아닙니다. ACK처럼 간략한 응답을 받았는지, 아직 종료 전 상태인지, 다른 조회 자료를 보고 있는지 확인해야 합니다.

누락된 필드를 임의로 NONE으로 채우면 실제 서버가 NONE을 반환한 것과 구분되지 않습니다. 알 수 없는 상태는 알 수 없는 상태로 남기고 필요한 자료를 더 확인합니다.

오래된 SDK가 새 필드를 무시하는 경우도 점검 대상입니다. 원본 응답과 프로그램이 가공한 화면이 같은 정보를 보존하는지 비교할 필요가 있습니다.

공식 사유 목록의 큰 구조

작성일 공식 열거형에는 아래 값들이 안내되어 있습니다. 실제 의미를 읽을 때는 철자를 그대로 확인하고, 새로운 값이 추가될 수 있다는 점도 고려해야 합니다.

이 표는 오류를 자동으로 고치는 처방전이 아닙니다. 같은 사유라도 구체적인 계정과 주문 상태를 확인해야 다음 조치를 판단할 수 있습니다.

특히 한 값을 보고 “가격을 올리면 해결”, “잔고만 늘리면 해결”처럼 단정하지 않습니다. 주문의 의도와 위험 한도를 바꿀 수 있는 조치는 별도 판단이 필요합니다.

NONE: 만료되지 않았다는 의미

NONE은 주문이 만료되지 않았다는 의미로 정의됩니다. 이것을 “문제 없음”, “전량 체결”, “앞으로 성공”이라는 넓은 뜻으로 사용하면 안 됩니다.

주문이 NEW 또는 PARTIALLY_FILLED 상태라면 만료되지 않았어도 아직 실행이 끝나지 않았을 수 있습니다. 상태와 체결량이 함께 필요합니다.

또한 필드가 아예 없는 경우와 값이 NONE인 경우는 다릅니다. 원본 데이터에 값이 있었는지, 프로그램이 기본값으로 넣었는지 확인해야 합니다.

REJECTED: 상태 이름과 사유 이름 구분

REJECTED라는 단어는 주문 상태에도 등장할 수 있고 만료 사유 목록에도 등장합니다. 같은 철자라도 어느 필드에서 읽는지에 따라 문맥이 다릅니다.

Expiry Reasons의 REJECTED는 조건부 주문 또는 OTO의 일부 주문이 주문장에 올라가려는 시점에 매칭 엔진에서 거절된 상황을 설명합니다. 공식 문서는 흔한 배경으로 자금 부족과 필터 거절을 듭니다.

처음 주문 목록을 만들 때의 조건과 후속 주문이 실제로 작동하려는 시점의 조건은 달라질 수 있습니다. 최초 요청이 받아들여졌다는 사실만으로 모든 후속 단계의 실행을 보장할 수 없는 이유입니다.

점검해야 할 자료

어느 개별 주문이 거절됐는지, 그 주문이 어떤 목록에 연결되어 있었는지 확인합니다. 다음으로 해당 시점의 잔고와 주문 규칙, 실제 오류나 상태 자료를 대조합니다.

“목록이 처음에 접수됐으므로 후속 주문도 정상”이라고 표시하는 프로그램은 수정이 필요할 수 있습니다. 목록 접수와 개별 주문의 실제 작동을 별도 사건으로 기록해야 합니다.

사유가 REJECTED라고 해서 항상 잔고 부족이라고 번역하는 것도 부정확합니다. 공식 설명이 예시로 든 원인과 실제 개별 요청의 원인을 구분합니다.

EXCHANGE_CANCELED: 거래소에 의한 취소

이 값은 Binance에 의해 주문이 취소됐다는 뜻입니다. 값 하나만으로 구체적인 내부 이유를 모두 알 수 있는 것은 아닙니다.

거래쌍의 상태 변화, 관련 공지, 주문 기록을 확인할 수 있지만 문서에 없는 원인을 추측해 확정해서는 안 됩니다. 특히 사용자가 직접 취소했다고 잘못 표시하지 않도록 구분해야 합니다.

이미 체결된 부분이 있다면 해당 체결은 별도로 기록합니다. 거래소에 의한 종료라는 이유만으로 이전 체결을 장부에서 삭제하지 않습니다.

OCO_TRIGGER: 연결된 다른 주문을 함께 보기

OCO는 연결된 주문의 관계가 중요합니다. 공식 사유 설명은 다른 주문이 작동하기 시작했거나 전체 OCO가 만료되어 해당 주문이 취소되는 경우를 포함합니다.

따라서 개별 주문 한 줄만 보면 정상적인 연결 동작을 오류로 오해할 수 있습니다. 어느 주문이 먼저 작동했는지, 다른 주문의 상태가 무엇인지, 목록 전체가 어떻게 끝났는지를 함께 읽습니다.

OCO_TRIGGER를 보았다고 어느 주문이 어떤 가격에 모두 체결됐다고 단정하지 않습니다. 작동 시작과 전량 체결은 다른 단계입니다. 실제 체결량과 상태를 확인해야 합니다.

같은 목록 안에서도 결과가 다르다

연결된 주문들은 하나의 목적을 위해 함께 구성될 수 있지만 각각의 상태와 수량을 갖습니다. 한 주문의 사유를 다른 주문에 그대로 복사하면 기록이 틀어질 수 있습니다.

보고서에는 목록 식별자와 각 주문 식별자를 함께 둡니다. “OCO 종료”라는 요약 아래에 어느 주문이 실행됐고 어느 주문이 종료됐는지 설명할 수 있어야 합니다.

OTO_PHASE_ONE_EXPIRED: 첫 단계에서 이어진 종료

이 사유는 작업 주문이 만료되어 전체 주문 목록이 만료된 경우를 뜻합니다. 후속 주문 자체의 가격이 틀려서 끝난 것으로 곧바로 해석하면 안 됩니다.

순차 구조에서는 앞 단계가 충족되어야 뒤 단계가 작동할 수 있습니다. 앞 단계가 만료됐다면 뒤 단계의 실행 가능성도 그 관계에 영향을 받습니다.

진단할 때는 먼저 작업 주문의 종료 사유와 체결 상태를 확인합니다. 후속 주문만 보고 숫자를 바꾸는 것은 실제 원인과 동떨어진 수정이 될 수 있습니다.

IOC 관련 사유: 남은 수량의 종료

UNFILLED_IOC_QUANTITY_EXPIRED는 IOC가 전량 체결되지 않아 만료된 상황을 설명합니다. IOC는 가능한 만큼 즉시 체결을 시도한 뒤 남은 부분이 끝나는 구조로 이해할 수 있습니다.

핵심은 부분 체결이 있을 수 있다는 점입니다. 사유에 UNFILLED가 포함됐다고 전체 주문이 아무 거래도 하지 않았다고 단정하지 않습니다.

원수량, 실제 누적 체결량, 종료 상태를 함께 읽으면 어떤 결과가 남았는지 알 수 있습니다. 종료된 잔량을 다시 주문하려면 현재 시장과 사용자의 의도를 새로 확인해야 합니다.

미체결 잔량과 실제 체결량

가상의 주문 10개 중 6개가 체결되고 나머지가 만료됐다고 가정합니다. 6개는 실제 거래 결과이고 4개는 같은 주문에서 더 이상 실행되지 않는 부분입니다.

이 둘을 하나의 실패로 합치면 보유 자산을 잘못 판단하게 됩니다. 반대로 10개 모두 체결된 것으로 표시하면 실제보다 큰 포지션이나 보유량을 가정하게 됩니다.

IOC 사유를 읽는 목적은 “성공·실패” 이분법보다 결과를 수량 단위로 정확히 나누는 데 있습니다.

FOK 관련 사유: 전량 조건 확인

UNFILLED_FOK_ORDER_EXPIRED는 FOK의 전량 체결 조건을 충족하지 못한 종료를 설명합니다. 공식 timeInForce 정의는 실행 시 전체 주문을 채울 수 없으면 만료된다고 안내합니다.

IOC와 FOK는 둘 다 빠르게 끝날 수 있지만 조건이 다릅니다. IOC의 부분 체결 사례를 FOK의 일반 동작으로 설명하면 안 됩니다.

진단에서는 요청의 timeInForce가 실제로 FOK였는지 확인합니다. 화면의 옵션 표시와 최종 요청값이 다르면 사용자는 IOC를 선택했다고 생각해도 다른 결과를 받게 됩니다.

전량 조건이 충족되지 않았다고 무작정 수량을 줄이거나 가격을 바꾸는 것은 새로운 거래 의사결정입니다. 사유 확인과 재주문 판단을 구분해야 합니다.

INSUFFICIENT_LIQUIDITY: 매칭할 주문의 부족

공식 정의는 해당 주문과 매칭할 주문장 주문이 충분하지 않았다는 것입니다. 이것은 단순히 거래소 전체 거래량이 적다는 말과 같지 않습니다.

어떤 거래쌍에서 어떤 주문 유형과 가격 조건으로 실행하려 했는지 중요합니다. 화면에 보이는 24시간 거래량이 많아도 해당 시점의 실행 가능한 상대 주문이 충분하다는 보장은 없습니다.

시장의 누적 통계와 현재 주문장 조건은 다른 자료입니다. 따라서 이 사유를 이해할 때는 현재 호가, 주문 조건, 실제 체결 결과를 중심으로 살펴봅니다.

관측한 호가와 실행 시점의 차이

사용자가 주문 전에 본 호가와 실제 주문이 매칭되는 시점의 호가는 달라질 수 있습니다. 다른 참가자의 주문·취소·체결이 계속 발생하기 때문입니다.

“화면에는 수량이 충분했는데 왜 부족하다고 나왔는가”라는 질문에는 자료의 시각 차이가 포함됩니다. 사유 값만으로 특정 참가자의 행동이나 내부 처리를 추측할 수는 없습니다.

기록에는 관측 시각과 제출 시각, 실제 결과 시각을 구분해 남기면 도움이 됩니다. 다만 시각이 가깝다고 동일한 주문장 상태였다고 보장할 수는 없습니다.

가격 범위 실행 규칙 관련 사유

EXECUTION_RULE_PRICE_RANGE_EXCEEDED는 가격 범위 실행 규칙을 만족하지 않는 가격으로 거래를 시도한 상황을 뜻합니다.

이 값은 사용자가 설정하는 일반적인 지정 가격, 가격 필터, 슬리피지 허용치와 무조건 같은 개념이 아닙니다. 실제 적용되는 공식 실행 규칙을 별도로 확인해야 합니다.

기존 PRER 글의 내용을 반복하기보다 여기서는 사유를 읽는 절차에 집중합니다. 주문이 어떤 조건에서 끝났는지 확인한 뒤 관련 규칙 문서로 연결하고, 내부 공식을 임의로 만들어 원인을 계산하지 않습니다.

규칙을 우회하려 하지 않기

사유가 표시됐다고 제한을 피하기 위한 반복 주문을 자동으로 실행하는 것은 적절한 복구가 아닙니다. 사용자의 가격 한도와 거래 목적을 다시 검토해야 합니다.

현재 시장이 변했다면 같은 요청을 반복해도 결과가 달라질 수 있지만, 이것은 성공 보장이 아닙니다. 재주문은 기존 주문의 잔량·체결·종료 여부를 먼저 확인한 뒤 별도 판단으로 다룹니다.

STP 만료는 어떻게 구분하는가

공식 주문 상태 정의에서 EXPIRED_IN_MATCH는 STP, 즉 자기거래 방지로 만료된 상태입니다. 일반 EXPIRED와 구분하고 preventedMatchId·preventedQuantity 등 관련 기록이 있는지 확인할 수 있습니다.

모든 만료를 유동성 부족으로 번역하면 STP에 따른 결과를 놓칠 수 있습니다. 반대로 EXPIRED라는 단어만 보고 모두 자기거래 방지라고 판단할 수도 없습니다.

사유·상태·관련 필드를 함께 읽는 것이 중요합니다. 실제 체결 자료와 방지된 매칭 기록은 같은 거래 장부에 합산하지 않습니다.

방지된 거래와 실제 거래

자기거래 방지 기록은 주문들이 서로 거래할 수 있었지만 방지된 사건을 설명합니다. 실제 체결 거래와 다른 자료입니다.

주문에 과거 실제 체결이 있었고 이후 STP로 남은 부분이 종료됐을 수 있으므로, 하나의 주문에 실제 체결과 방지 기록이 함께 연결될 수 있습니다. 그렇다고 두 수량을 모두 거래량으로 더하면 안 됩니다.

다음 글에서는 이 기록을 조회하고 주문 ID와 연결하는 Prevented Matches를 다룹니다. 여기서는 종료 원인을 분류한 뒤 맞는 자료로 넘어가는 흐름을 기억하면 됩니다.

실제 기록 확인 절차

1단계: 주문을 정확히 식별한다

symbol과 orderId, 필요한 경우 clientOrderId를 확인합니다. 비슷한 시간에 같은 종목으로 여러 주문을 냈다면 시각만으로 특정 주문을 고르지 않습니다.

계정과 시장이 맞는지도 확인합니다. 현물 주문 자료와 다른 상품의 주문 상태를 같은 표에 섞으면 필드 의미가 달라질 수 있습니다.

2단계: 상태와 사유의 원본값을 보존한다

화면에 번역된 문구뿐 아니라 실제 상태값과 사유값을 구분해 저장합니다. 내부 요약 문구가 원본 의미를 축소하지 않는지 확인합니다.

알 수 없는 새로운 사유가 나오면 임의로 기존 값에 매핑하지 않습니다. 원본 문자열을 보존하고 현재 공식 문서에서 의미를 확인합니다.

3단계: 체결량과 대금을 확인한다

누적 체결량이 있는지 확인하고 실제 거래 내역과 대조합니다. 만료됐다는 이유로 누적 체결량을 0으로 초기화하지 않습니다.

평균 체결 가격을 계산할 때는 체결량 0을 처리하고, 수수료 포함 비용과 단순 체결 평균을 구분합니다.

4단계: 주문 유형과 유효 방식을 확인한다

IOC·FOK·GTC 등 요청 조건을 확인합니다. 사유와 요청값이 서로 어떻게 연결되는지 읽습니다.

기억이나 화면의 현재 기본값이 아니라 해당 주문이 실제로 어떤 값으로 제출됐는지 확인해야 합니다. 기본값은 이후 변경됐을 수도 있습니다.

5단계: 연결 주문을 확인한다

OCO·OTO 관련 사유라면 목록과 개별 주문을 함께 조회합니다. 한 주문의 종료가 전체 목록에서 어떤 역할을 했는지 확인합니다.

연결 관계를 보지 않고 후속 주문만 수정하면 원인 해결이 되지 않을 수 있습니다. 첫 단계의 조건과 실제 결과를 먼저 읽습니다.

6단계: 필요한 자료만 추가 확인한다

유동성 관련이면 주문장 관측과 실행 시점을, 필터 관련이면 해당 규칙을, STP 관련이면 방지 기록을 확인합니다.

모든 문제에 같은 자료를 무작정 많이 모으기보다 사유에 맞는 자료를 선택하는 것이 효율적입니다. 확인하지 못한 부분은 추측으로 채우지 않습니다.

7단계: 재주문과 기록 정리를 분리한다

종료 원인을 이해하는 것과 다시 거래하는 것은 다른 결정입니다. 기존 체결량과 잔고를 반영하지 않고 원수량 전체를 다시 보내면 의도보다 큰 거래가 될 수 있습니다.

기록 정리는 실제 결과를 반영하는 작업이고 재주문은 새로운 시장 행동입니다. 두 절차를 자동으로 붙이지 않는 것이 중요합니다.

가상 사례 1: IOC 10개 중 6개 체결

가상의 매수 IOC 주문 원수량은 10개이고 실행 시 6개가 체결됐다고 가정합니다. 나머지가 끝나면서 IOC 관련 사유가 나타났습니다.

이 주문을 “실패, 체결 0”으로 기록하면 보유 자산 6개를 놓칩니다. “성공, 체결 10”으로 기록해도 실제 결과와 다릅니다.

올바른 해석은 확인된 체결량 6개와 종료된 나머지 부분을 나누는 것입니다. 실제 대금과 수수료도 체결된 자료에서 확인합니다.

다시 4개를 주문할지는 현재 시장과 사용자의 목표에 따른 별도 판단입니다. 자동으로 원수량 10개를 반복하면 이미 체결된 6개까지 중복해 거래할 수 있습니다.

가상 사례 2: FOK 전량 조건 미충족

가상의 FOK 주문은 정해진 조건에서 전체 10개를 실행해야 합니다. 조건을 충족하지 못해 FOK 관련 만료 사유가 기록됐다고 가정합니다.

이 결과를 IOC처럼 “가능한 6개는 체결됐을 것”이라고 추측해서는 안 됩니다. 실제 주문 유형과 체결 기록을 확인해야 합니다.

프로그램이 IOC와 FOK를 같은 “즉시 주문”으로 묶어 표시했다면 사용자의 기대와 실제 조건이 달라질 수 있습니다. 옵션 이름과 요청값을 명확히 구분하는 것이 우선입니다.

사유 분석 뒤에도 가격을 바꾸거나 수량을 나누는 것은 새로운 전략 결정입니다. 종료 사유가 곧 최적의 재주문 방법을 알려주는 것은 아닙니다.

가상 사례 3: OCO의 한 주문이 끝남

가상의 OCO 목록에서 한 주문이 작동하면서 다른 주문에 OCO_TRIGGER가 나타났다고 가정합니다. 다른 주문만 보면 이유 없이 취소된 것처럼 보일 수 있습니다.

목록과 두 주문의 식별자를 연결하면 이 종료가 연결 구조 안에서 발생한 결과임을 확인할 수 있습니다. 다만 작동한 주문의 실제 체결량은 별도로 읽어야 합니다.

“한쪽이 끝났으므로 다른 쪽이 모두 체결”이라는 결론도 성급합니다. 작동 시작, 부분 체결, 전량 체결은 구분되는 사건입니다.

보고서에는 목록 전체 결과와 각 주문의 상태를 함께 남깁니다. 이를 통해 정상적인 연결 동작과 별도 오류를 구분할 수 있습니다.

가상 사례 4: OTO 첫 단계의 만료

가상의 작업 주문이 만료되면서 전체 목록이 끝났고 후속 주문에 관련 사유가 표시됐다고 가정합니다. 사용자는 후속 주문의 가격이 잘못됐다고 생각할 수 있습니다.

그러나 먼저 확인해야 할 것은 작업 주문입니다. 첫 단계가 왜 만료됐는지, 어떤 체결 결과가 있었는지, 목록이 어떤 상태로 끝났는지를 확인합니다.

후속 주문만 다시 만드는 것은 기존 의도를 재현하지 못할 수 있습니다. 앞 단계의 결과와 현재 잔고를 반영하지 않으면 예상과 다른 거래가 됩니다.

이 사례는 연결 주문을 개별 주문 여러 개의 단순 묶음으로만 처리하면 안 된다는 점을 보여줍니다. 관계와 단계가 결과 해석에 직접 영향을 줍니다.

가상 사례 5: 많은 거래량과 유동성 부족 사유

가상의 시장은 24시간 거래량이 크지만, 주문이 도착한 시점의 특정 가격 범위에는 충분한 상대 주문이 없었다고 가정합니다. INSUFFICIENT_LIQUIDITY가 나타났습니다.

24시간 통계가 크다는 이유로 이 사유가 불가능하다고 판단할 수 없습니다. 누적 거래 통계와 현재 실행 가능한 주문장은 다른 자료입니다.

진단에는 주문 유형, 가격 조건, 실제 누적 체결량, 관측 시점이 필요합니다. 과거 호가 스크린샷 하나로 실행 시점의 전체 주문장을 재구성할 수는 없습니다.

이 결과가 향후에도 같은 방향의 가격 움직임을 뜻하는 것은 아닙니다. 주문 종료 사유는 시장 전망 지표나 매수·매도 신호가 아닙니다.

흔한 오류와 수정 방향

EXPIRED를 시간 초과로만 번역

현물의 EXPIRED는 주문 유형 규칙이나 거래소 처리 등 다양한 배경이 있을 수 있습니다. 별도 사유를 읽고 문맥에 맞게 설명합니다.

사유 문자열만으로 체결량 초기화

종료 사유는 과거 체결을 지우지 않습니다. 누적량과 실제 거래 자료를 유지하면서 종료 상태를 반영합니다.

필드 누락을 NONE으로 채움

원본에 값이 없는 것과 NONE을 반환한 것은 다릅니다. 데이터 수집 단계에서 구분해야 합니다.

한 주문의 사유를 목록 전체에 복사

목록과 개별 주문의 상태가 다를 수 있습니다. 연결 관계를 유지하되 각 주문의 실제 결과를 따로 기록합니다.

종료 즉시 원수량 재주문

이미 일부 체결됐을 수 있으므로 과도한 거래가 될 수 있습니다. 현재 보유량과 목표 수량을 다시 확인해야 합니다.

알 수 없는 값을 기존 코드로 강제 변환

새로운 사유가 추가될 수 있습니다. 알 수 없는 값은 보존하고 확인 대상으로 분류합니다. 모르는 값을 정상이나 실패로 임의 매핑하지 않습니다.

분석 기록에 필요한 항목

이 표는 모든 값을 공개하라는 뜻이 아닙니다. 계정 정보와 인증 자료는 보호하고 문제 해결에 필요한 범위만 공유합니다.

원본 자료와 분석 문장을 분리하면 나중에 해석을 수정해도 실제 기록은 유지할 수 있습니다. “유동성이 부족해 보인다”라는 분석과 실제 INSUFFICIENT_LIQUIDITY 값은 구분해서 남깁니다.

자주 묻는 질문

Q1. Expiry Reason은 주문 만료 시간을 뜻하나요?

아닙니다. 이 글에서 다루는 값은 종료 사유입니다. 사용자가 설정하는 유효기간이나 POV Order Expiry와 구분해야 합니다.

Q2. EXPIRED면 거래가 전혀 없었나요?

그렇지 않을 수 있습니다. 일부 체결 후 남은 부분이 종료될 수 있으므로 실제 누적 체결량과 거래 내역을 확인합니다.

Q3. expiryReason과 status는 같은가요?

다릅니다. status는 주문 상태, 사유는 그 처리가 발생한 배경을 설명합니다. 같은 상태에도 서로 다른 사유가 연결될 수 있습니다.

Q4. NONE이면 주문이 모두 체결됐나요?

아닙니다. 만료되지 않았다는 뜻입니다. 실제 상태가 무엇인지와 체결량을 함께 읽어야 합니다.

Q5. REJECTED면 항상 잔고 부족인가요?

아닙니다. 공식 사유 설명은 자금 부족과 필터 거절 등을 예로 듭니다. 해당 주문의 실제 자료를 확인해야 구체적인 원인을 좁힐 수 있습니다.

Q6. OCO_TRIGGER면 다른 주문이 전량 체결됐나요?

그렇게 단정할 수 없습니다. 다른 주문의 작동 또는 전체 목록 만료 관련 상황을 포함하므로 연결 주문의 상태와 체결량을 별도로 확인합니다.

Q7. OTO_PHASE_ONE_EXPIRED는 무엇을 먼저 봐야 하나요?

작업 주문, 즉 첫 단계의 상태와 만료 배경을 먼저 확인합니다. 후속 주문만 수정하면 원인을 놓칠 수 있습니다.

Q8. IOC 만료와 FOK 만료는 같은가요?

조건이 다릅니다. IOC는 일부 체결 후 잔량 종료가 가능하고, FOK는 전량 체결 조건을 기준으로 이해해야 합니다. 실제 요청값과 기록을 확인합니다.

Q9. 거래량이 많은데 유동성 부족이 나올 수 있나요?

누적 거래량과 특정 시점의 실행 가능한 주문장은 다릅니다. 주문 유형·가격 조건·시점에 맞는 상대 주문이 충분한지와 관련됩니다.

Q10. 가격 범위 사유가 나오면 제한을 풀면 되나요?

사유를 확인한 뒤 현재 공식 규칙과 사용자 가격 한도를 검토해야 합니다. 제한을 우회하거나 무조건 반복 주문하는 방식으로 해결한다고 볼 수 없습니다.

Q11. EXPIRED_IN_MATCH는 무엇인가요?

공식 상태 정의에서 STP에 따른 만료입니다. 방지된 매칭 기록과 실제 체결 자료를 구분해 확인합니다.

Q12. 필드가 없으면 NONE으로 넣어도 되나요?

권장할 수 없습니다. 미수신·조건부 생략과 실제 NONE 값은 의미가 다릅니다. 원본 존재 여부를 보존해야 합니다.

Q13. 종료 사유가 나오면 자동 재주문해도 되나요?

기존 체결량과 현재 잔고, 사용자 목표를 먼저 확인해야 합니다. 재주문은 새로운 거래 결정이며 기존 요청의 단순 복구로 취급하면 중복 위험이 있습니다.

Q14. 처음 보는 사유 문자열은 어떻게 처리하나요?

원본값을 보존하고 최신 공식 정의를 확인합니다. 기존 사유에 임의로 끼워 맞추거나 사용자에게 확정 원인을 설명하지 않습니다.

Q15. 가장 중요한 대조 항목은 무엇인가요?

정확한 주문 식별자, 상태, 사유, 실제 체결량, 주문 유형과 연결 관계입니다. 이 항목을 함께 보면 종료와 실제 거래 결과를 구분할 수 있습니다.

확인 체크리스트

• 현물의 종료 사유와 다른 상품의 유효기간을 구분했는가.
• status와 expiryReason을 다른 항목으로 보관하는가.
• 원본 필드 누락과 NONE을 구분하는가.
• 주문 식별자와 symbol이 맞는가.
• 실제 요청의 주문 유형과 timeInForce를 확인했는가.
• 부분 체결량과 실제 대금을 유지하는가.
• 만료됐다는 이유로 과거 체결을 삭제하지 않는가.
• OCO·OTO라면 목록과 연결 주문을 함께 확인했는가.
• IOC와 FOK의 실행 조건을 구분했는가.
• 유동성 사유를 24시간 거래량으로만 판단하지 않는가.
• STP 방지 기록을 실제 거래량에 더하지 않는가.
• 규칙 관련 사유를 임의의 내부 공식으로 설명하지 않는가.
• 알 수 없는 새 값은 원본 그대로 보존하는가.
• 재주문 전에 기존 결과와 현재 목표를 다시 확인하는가.

핵심 정리 표

마무리

바이낸스 Expiry Reason은 주문이 끝난 이유를 읽는 단서입니다. 상태와 사유, 실제 체결량을 함께 봐야 사용자에게 정확한 결과를 설명할 수 있습니다.

만료는 항상 시간 초과도 아니고, 항상 체결 0도 아닙니다. 연결 주문과 실행 조건을 확인한 뒤 필요한 자료로 넘어가면 불필요한 재주문과 잘못된 장부 처리를 줄일 수 있습니다.

공식 참고 자료

• Binance Spot Expiry Reasons와 주문 상태
• Binance Spot 주문 응답과 조건부 필드
• Binance Spot 사용자 데이터 스트림

이 글은 주문 기록 해석을 위한 정보이며 투자·재주문 권유가 아닙니다. 필드와 규칙은 변경될 수 있고 계정·상품별 조건이 다르므로 최신 공식 자료를 확인하세요.