바이낸스 ACK RESULT FULL 차이 2026｜주문 응답·체결 내역·상태 확인 가이드

바이낸스 ACK RESULT FULL 차이 2026｜주문 응답·체결 내역·상태 확인 가이드

바이낸스 ACK RESULT FULL 차이는 현물 신규 주문 요청에 어떤 범위의 정보를 응답으로 받을지에 있습니다. ACK는 주문 식별 중심, RESULT는 주문 상태와 누적 수량 중심, FULL은 체결 세부 정보까지 읽는 데 쓰입니다. 세 이름은 주문의 성공 등급이나 체결 우선순위를 뜻하지 않습니다.

특히 FULL을 선택했다고 전량 체결되는 것은 아닙니다. FULL은 응답 형식이고 FILLED는 주문 상태입니다. 단어가 비슷해 보여도 역할이 다릅니다.

이 글은 2026년 11월 3일 Binance Spot REST API의 신규 주문 문서와 공식 상태 정의를 기준으로 설명합니다. 실제 주문을 실행하는 안내가 아니라 응답을 올바르게 읽고 기록하기 위한 가이드입니다. 예시 가격·수량·식별자는 모두 가상입니다.

세 가지를 먼저 한눈에 비교

응답 형식은 신규 주문 요청의 newOrderRespType으로 선택합니다. 작성일 기준 공식 문서는 ACK, RESULT, FULL을 안내하며 MARKET과 LIMIT의 기본값은 FULL, 나머지 주문 유형의 기본값은 ACK라고 설명합니다.

기본값은 코드에서 생략했을 때의 동작을 이해하는 데 필요합니다. 모든 주문을 같은 파서로 처리하는 프로그램이라면 주문 유형별 기본 응답이 다를 수 있다는 점을 알아야 합니다.

응답이 짧다고 실패한 주문이 아니고, 응답이 길다고 더 유리한 주문도 아닙니다. 필요한 정보를 어떻게 확보하고 후속 상태를 어떻게 갱신할지가 선택 기준입니다.

주문 응답과 주문 상태의 차이

응답은 요청에 대해 서버가 반환한 자료입니다. 상태는 특정 시점의 주문이 어떤 단계에 있는지 나타내는 값입니다. 이 두 층을 나누지 않으면 정상적인 ACK를 오류로 보거나 FULL을 전량 체결로 오해할 수 있습니다.

예를 들어 RESULT라는 응답 안에 NEW가 들어 있을 수 있습니다. RESULT는 “결과 자료를 받았다”는 형식 설명이고 NEW는 그 자료가 나타내는 주문 상태입니다.

FULL 응답을 받아도 아직 남은 수량이 있을 수 있으며, 이후 상태는 바뀔 수 있습니다. 응답 수신 시각과 주문 처리 시각, 나중에 조회한 시각을 함께 이해해야 합니다.

FULL과 FILLED는 다른 단어

FULL은 newOrderRespType의 값입니다. FILLED는 주문 상태의 값입니다. 이 차이를 사용자 화면의 번역에서도 유지해야 합니다.

FULL을 “전체 체결”이라고 번역하면 정보 형식이 거래 결과로 바뀌어 버립니다. “상세 응답”처럼 역할을 드러내는 설명이 더 적절합니다.

반대로 FILLED는 주문이 완료됐다는 상태를 읽을 때 사용합니다. 응답 형식이 ACK였는지 FULL이었는지와 별개로, 실제 상태 자료에서 확인해야 합니다.

접수와 체결은 시간적으로 구분된다

주문을 제출하고 식별자를 받는 단계와 시장에서 체결되는 단계는 구분됩니다. 지정가 주문은 주문장에 남을 수 있고, 조건부 주문은 별도 조건을 기다릴 수 있습니다.

따라서 “주문 요청이 성공했으니 자산이 모두 바뀌었다”는 표시를 바로 내보내면 안 됩니다. 체결량과 상태를 확인해야 합니다.

응답 형식을 이해하는 목적은 거래를 더 빨리 강제하는 데 있지 않습니다. 현재 알고 있는 사실과 아직 확인해야 할 사실을 화면과 기록에서 구분하는 데 있습니다.

ACK: 식별과 후속 추적의 출발점

공식 신규 주문 ACK 예시는 symbol, orderId, orderListId, clientOrderId, transactTime을 포함합니다. 이 자료는 어떤 주문 요청이 처리됐는지 연결하는 출발점입니다.

ACK 예시에 status나 executedQty가 없다는 이유만으로 해당 주문이 미체결이라고 단정할 수 없습니다. 응답 형식상 그 정보가 제공되지 않은 것과 실제 체결량이 0인 것은 다릅니다.

orderId를 확보했다면 이후 주문 조회나 사용자 데이터 이벤트와 연결할 수 있습니다. ACK만 받고 추적을 끝내는 방식은 접수 이후의 상태를 놓칠 수 있습니다.

orderId와 clientOrderId

orderId는 거래소가 부여한 주문 식별자이고 clientOrderId는 클라이언트가 지정하거나 자동 생성되는 주문 식별 값입니다. 두 값을 같은 필드에 덮어쓰지 않는 것이 좋습니다.

주문 조회와 이벤트를 연결할 때는 symbol도 함께 보관합니다. 식별자만 숫자 하나로 저장하면 다른 시장이나 계정의 자료와 혼동할 수 있습니다.

내부 기록에는 사용자 요청 식별자, 거래소 주문 식별자, 클라이언트 주문 식별자를 각각 구분할 수 있습니다. 한 사용자의 한 번의 클릭이 어떤 실제 주문으로 이어졌는지 추적하기 위한 설계입니다.

orderListId와 독립 주문

공식 예시는 주문 목록에 속하지 않을 때 orderListId가 -1이라고 설명합니다. 이 값은 주문 목록의 관계를 읽는 데 쓰이며, 수량이나 성공 횟수가 아닙니다.

조건부 주문 목록을 다루는 경우 하나의 개별 주문과 전체 목록의 상태를 혼동하지 않아야 합니다. 이 글은 신규 단일 주문 응답을 중심으로 설명하므로 목록 엔드포인트의 응답까지 동일하다고 확장하지 않습니다.

ACK에 없는 값을 0으로 만들지 않기

파서가 필드 누락을 모두 0으로 바꾸면 “체결량 정보 없음”이 “체결량 0”으로 바뀝니다. 화면에서는 비슷해 보여도 의미가 다릅니다.

주문 상태를 아직 확인하지 못한 경우에는 미확인 상태를 유지하고 후속 조회 결과로 갱신해야 합니다. 누락값, 실제 0, null, 비지원 필드는 프로그램에서 각각 구분할 필요가 있습니다.

이 원칙은 수수료에도 적용됩니다. ACK에 commission이 없다고 수수료가 0이라고 기록하면 장부가 틀어질 수 있습니다.

RESULT: 상태와 누적 수량을 읽기

RESULT 예시는 기본 식별자에 price, origQty, executedQty, origQuoteOrderQty, cummulativeQuoteQty, status, timeInForce, type, side 등 주문 정보를 더합니다.

이 정보로 요청 수량과 현재 누적 체결량, 누적 기준 자산 대금을 구분할 수 있습니다. 특히 executedQty와 cummulativeQuoteQty는 단위가 다릅니다.

필드 이름의 철자를 그대로 확인해야 합니다. 문서의 cummulativeQuoteQty는 익숙한 영어 철자와 다르게 보일 수 있지만, 실제 API 키 이름을 임의로 고치면 파서가 데이터를 놓칠 수 있습니다.

origQty와 executedQty

origQty는 주문의 수량 정보이고 executedQty는 누적 체결 수량입니다. 두 숫자를 더해 총 주문량으로 계산하면 안 됩니다. 체결량은 주문 수량 중 실행된 부분을 나타내기 때문입니다.

가상의 원수량이 10, 누적 체결량이 4라면 일반적인 단순 주문에서 4는 별도의 추가 주문량이 아닙니다. 다만 잔량을 계산할 때는 수정·방지 수량·종료 상태 등 해당 주문에 적용되는 조건도 함께 확인해야 합니다.

모든 주문에 origQty-executedQty만 적용해 “지금 바로 체결 가능한 잔량”이라고 표시하는 것은 과도한 단순화일 수 있습니다. 상태가 종료됐거나 STP가 수량에 영향을 줬는지 확인합니다.

cummulativeQuoteQty와 평균 체결 가격

누적 기준 자산 대금과 누적 기초 자산 체결량을 구분하면 평균 체결 가격을 계산할 수 있습니다. executedQty가 0보다 클 때, 누적 대금을 누적 체결량으로 나누는 방식으로 체결 평균을 확인할 수 있습니다.

이 평균은 주문의 지정 가격과 다를 수 있습니다. 지정 가격은 주문 조건이고, 실제 체결 평균은 실행 결과이기 때문입니다.

executedQty가 0이면 나눗셈을 수행하지 않습니다. 이때 평균 가격을 0으로 확정 표시하기보다 아직 계산할 체결이 없다는 상태로 처리하는 편이 의미가 명확합니다.

price를 시장가 체결 평균으로 사용하지 않기

시장가 주문의 price 필드가 0처럼 보인다고 실제로 무료 체결됐다는 뜻은 아닙니다. 필드의 역할과 주문 유형을 함께 읽어야 합니다.

실제 가격 분석에는 체결 수량과 대금, 또는 개별 fills의 price와 qty가 필요합니다. 주문 조건 필드 하나로 실제 평균을 대체하지 않습니다.

지정가 주문에서도 주문 가격을 실제 비용의 최종 평균으로 고정하면 여러 가격에서 이루어진 체결을 놓칠 수 있습니다. 보고서에는 지정 가격과 체결 평균을 별도 열로 두는 것이 좋습니다.

status를 함께 읽는 이유

NEW, PARTIALLY_FILLED, FILLED, CANCELED, EXPIRED, EXPIRED_IN_MATCH 등은 서로 다른 상태입니다. 누적 체결량만 보고 현재 주문이 활성 상태인지 판단할 수는 없습니다.

예를 들어 일부 체결 후 취소됐다면 체결량은 남아 있지만 주문은 더 이상 같은 방식으로 실행되지 않습니다. 반대로 일부 체결 상태로 남아 있다면 이후 추가 체결이 있을 수 있습니다.

상태와 수량을 함께 기록해야 “이미 체결된 부분”과 “앞으로 남아 있는 실행 가능성”을 구분할 수 있습니다.

FULL: 개별 체결 자료까지 확인하기

FULL 응답 예시는 fills 배열을 포함하고 각 항목에 price, qty, commission, commissionAsset, tradeId가 표시됩니다. 이 자료는 개별 체결 가격·수량·수수료를 읽는 데 유용합니다.

다만 fills를 주문의 미래까지 포함한 전체 거래 장부로 생각하면 안 됩니다. 응답 이후에도 주문이 활성 상태라면 후속 체결과 상태 변화를 별도로 확인해야 합니다.

한 주문이 여러 체결로 나뉘는 것은 이상 현상이 아닙니다. 여러 상대 주문과 가격 수준에서 나뉘어 실행될 수 있으므로 배열의 각 항목을 별도 체결로 읽습니다.

수수료는 자산과 함께 읽기

commission은 수수료 수량이고 commissionAsset은 그 수수료의 자산입니다. 숫자만 더하면 서로 다른 자산을 같은 단위처럼 합산하는 오류가 생길 수 있습니다.

가상의 체결 A는 수수료가 0.01 BNB이고 체결 B는 0.2 USDT라면 둘을 0.21로 합쳐 단일 비용이라고 표시할 수 없습니다. 자산별 합계를 내거나 명시한 평가 시점과 환율로 환산하는 별도 절차가 필요합니다.

또한 체결 대금과 수수료를 구분해야 합니다. 누적 대금이 이미 어떤 항목을 포함하는지 확인하지 않고 비용을 임의로 차감하면 손익 계산이 중복될 수 있습니다.

tradeId와 중복 집계

같은 체결이 최초 FULL 응답, 이후 사용자 데이터 이벤트, 거래 내역 조회에서 다시 나타날 수 있습니다. 자료를 세 번 받았다고 체결이 세 번 발생한 것은 아닙니다.

실제 식별 규칙과 symbol·계정 범위를 고려해 중복을 제거해야 합니다. 주문 ID만으로 묶으면 하나의 주문에 포함된 여러 체결을 하나로 뭉칠 수 있고, 수신 시각만으로 묶으면 재전송을 놓칠 수 있습니다.

기록을 갱신할 때는 원본 출처를 남기고 같은 거래를 재확인한 것인지 새 거래인지 구분하는 편이 좋습니다. 상세 응답을 받는 목적은 정보량을 늘리는 것만이 아니라 정확한 대조를 가능하게 하는 데 있습니다.

조건부 필드는 항상 나오지 않는다

공식 문서는 주문 응답의 일부 필드가 특정 조건에서만 나타난다고 안내합니다. icebergQty, stopPrice, strategy 관련 값, trailing 관련 값, STP 관련 값, SOR와 peg 관련 값 등이 이에 해당합니다.

따라서 한 번 본 FULL 예시를 모든 주문의 고정 구조로 삼으면 안 됩니다. 선택한 주문 기능과 실제 발생한 사건에 따라 필드가 달라질 수 있습니다.

필드가 없을 때는 “해당 조건이 적용되지 않았을 수 있음”과 “아직 정보를 확인하지 못함”을 구분해야 합니다. 없는 필드를 임의로 만들어 채우는 방식은 데이터의 의미를 흐릴 수 있습니다.

STP와 체결을 혼동하지 않기

자기거래 방지 관련 자료가 보인다면 실제 체결 내역과 구분합니다. preventedMatchId나 preventedQuantity 같은 값은 일반적인 fills의 체결 수량과 역할이 다릅니다.

특히 방지된 수량을 거래량에 더하면 실제 거래보다 많은 수량을 거래했다고 기록하게 됩니다. 무엇이 실행됐고 무엇이 방지됐는지를 별도 항목으로 처리해야 합니다.

새로운 조건부 필드가 추가될 수 있으므로 파서는 모르는 필드 하나 때문에 전체 응답을 잘못 읽지 않도록 설계할 수 있습니다. 그렇다고 모르는 필드를 임의로 해석해 사용자에게 확정 설명을 제공해서도 안 됩니다.

응답 형식 선택 기준

ACK가 필요한 시스템은 이후 상태를 조회하거나 이벤트로 갱신하는 경로가 준비되어 있어야 합니다. 짧은 응답을 선택했다는 이유로 후속 상태 확인을 생략할 수는 없습니다.

RESULT는 누적 상태를 빠르게 읽는 화면에 유용할 수 있습니다. 다만 개별 체결별 수수료와 거래 식별자를 필요로 한다면 추가 자료가 필요합니다.

FULL은 초기 체결 세부 정보를 처리하는 데 도움이 되지만, 상세 응답을 받는다는 이유만으로 후속 이벤트와 조회를 없애면 안 됩니다. 시스템의 일관성은 응답 길이보다 서로 다른 자료를 정확히 연결하는 구조에 달려 있습니다.

속도에 관한 과장 피하기

응답이 짧으면 데이터량이 적을 수 있지만, 이것을 주문장 우선순위나 체결 가격 개선으로 연결할 근거는 없습니다. ACK를 선택하면 다른 사람보다 먼저 체결된다는 식의 설명은 하지 않습니다.

네트워크 지연, 서버 처리, 클라이언트 파싱 등은 서로 다른 요소입니다. 특정 응답 형식이 몇 밀리초를 보장한다고 문서에 없는 숫자를 제시할 수 없습니다.

필요한 자료와 오류 복구 방식을 기준으로 선택하고 실제 시스템에서 관측한 성능은 별도의 측정 결과로 다루는 것이 맞습니다.

실무 확인 순서

1단계: 요청에서 응답 형식을 확인한다

newOrderRespType을 명시했는지, 생략했다면 주문 유형의 기본값이 무엇인지 확인합니다. 요청 설정과 파서가 기대하는 형식이 같아야 합니다.

매수·매도 함수가 같은 내부 파서를 쓰더라도 주문 유형에 따라 기본 응답이 달라질 수 있습니다. 옵션을 명시하는 정책을 사용한다면 지원 값과 요청 문서를 그대로 따라야 합니다.

2단계: 식별자와 요청을 연결한다

symbol, orderId, clientOrderId를 저장하고 내부 요청과 연결합니다. 응답을 받는 순서가 요청을 보낸 순서와 같을 것이라고 가정하지 않습니다.

동시에 여러 주문을 보내는 시스템에서는 응답 도착 순서만으로 주문을 연결하면 다른 사용자의 요청이나 다른 거래쌍에 결과를 붙일 수 있습니다. 식별자가 연결 기준이 되어야 합니다.

3단계: 상태와 누적값을 분리해 저장한다

status, executedQty, cummulativeQuoteQty는 각각의 의미를 유지합니다. 상태는 문자열, 수량은 기초 자산 단위, 대금은 기준 자산 단위로 기록합니다.

누적값을 새 체결량으로 더하지 않습니다. 이전 누적 체결량이 2이고 다음 누적값이 5라면 같은 기준에서 새로 늘어난 양은 3이지 5 전체가 아닙니다. 수정·정정·자료 시점 차이도 검토해야 합니다.

4단계: 개별 체결은 별도 장부로 대조한다

FULL의 fills가 있다면 체결 식별자·가격·수량·수수료 자산을 저장합니다. 누적 주문 상태와 개별 체결 장부는 연결하되 같은 방식으로 합산하지 않습니다.

두 장부의 합계가 맞지 않으면 자료 수신 시점, 중복, 누락, 조회 범위를 확인합니다. 불일치가 있다는 이유만으로 임의의 보정 체결을 생성하지 않습니다.

5단계: 후속 상태를 갱신한다

사용자 데이터 이벤트나 주문 조회로 이후 상태를 확인합니다. 최초 응답이 NEW였다고 끝까지 NEW라고 표시하면 안 됩니다.

연결이 끊기거나 이벤트 누락이 의심되면 현재 주문 자료와 거래 내역으로 복구할 수 있는 절차가 필요합니다. 정확한 조회 방법과 보존 범위는 현재 공식 문서를 따릅니다.

6단계: 종료 상태와 비용을 확인한다

주문이 종료됐더라도 이미 발생한 체결은 남습니다. 취소나 만료를 거래 취소와 동일하게 처리하지 않습니다.

최종 장부에는 실제 체결 수량, 실제 대금, 자산별 수수료와 주문 종료 상태를 구분해 남깁니다. “주문 완료”라는 한 문장으로 전량 체결·취소·만료를 모두 뭉뚱그리지 않는 것이 좋습니다.

가상 사례 1: ACK를 받고 체결량 0으로 표시한 화면

한 프로그램이 ACK 응답을 받았는데 executedQty가 없었습니다. 개발자는 기본값 0을 넣어 사용자에게 “아직 체결되지 않았습니다”라고 표시했습니다.

그러나 이 화면은 확인하지 않은 사실을 단정한 것입니다. ACK가 체결량을 제공하지 않았을 뿐 실제로 그 사이 체결이 발생했을 수 있습니다.

개선된 화면은 “주문 식별자 확인, 체결 상태 확인 중”처럼 현재 확보한 자료를 설명하고, 이후 조회 결과로 체결량을 갱신합니다.

이 사례의 핵심은 정보 부재를 숫자 0으로 바꾸지 않는 것입니다. 사용자가 체결되지 않았다고 믿고 같은 주문을 다시 넣는 실수를 줄이는 데도 중요합니다.

가상 사례 2: RESULT 누적값을 반복 합산

가상의 주문 원수량은 10개입니다. 처음 RESULT에서 executedQty=2를 확인했고, 이후 조회에서 5, 마지막 조회에서 10을 확인했다고 가정합니다.

이를 2+5+10=17개 체결로 집계하면 잘못입니다. 모두 누적값이므로 최종 확인한 누적량과 개별 체결 내역을 대조해야 합니다.

연속 자료의 차이를 계산하려면 자료 순서와 동일 주문 여부가 확실해야 합니다. 늦게 도착한 과거 상태를 최신값으로 덮어쓰지 않도록 처리 시각과 식별자를 함께 봅니다.

주문 누적 장부와 거래별 장부를 구분하면 이런 오류를 찾기 쉽습니다. 최종 누적량이 10인데 거래 합계가 17이라면 중복 집계 가능성을 먼저 확인할 수 있습니다.

가상 사례 3: 두 가격에서 나뉜 FULL 체결

가상의 매수 주문이 2개는 100 USDT, 3개는 102 USDT에 체결됐다고 가정합니다. 총 체결량은 5개, 총 대금은 506 USDT이고 단순 체결 평균은 101.2 USDT입니다.

가격 두 개를 단순 평균한 101 USDT는 수량 가중치를 무시한 결과입니다. fills의 price와 qty를 함께 읽어야 하는 이유입니다.

수수료는 이 계산과 별도 확인합니다. 수수료 지급 자산과 실제 수량을 확인하지 않은 채 평균 가격에 임의로 더하면 단위가 섞일 수 있습니다.

표시 목적도 구분합니다. 체결 평균, 수수료 포함 취득 원가, 현재 평가 손익은 서로 다른 지표입니다. FULL 응답 하나의 숫자를 모든 지표로 재사용하면 안 됩니다.

가상 사례 4: 일부 체결 후 취소

가상의 원수량 10개 중 4개가 체결된 뒤 나머지가 취소됐다고 가정합니다. 최종 상태가 CANCELED여도 체결된 4개가 사라지는 것은 아닙니다.

프로그램이 취소 상태를 보고 주문의 모든 거래를 장부에서 제거하면 보유 자산과 거래 기록이 맞지 않게 됩니다. 종료 상태와 체결 이력을 분리해야 합니다.

첫 FULL 응답에서 일부 체결을 읽었더라도 최종 취소 결과는 후속 자료로 확인해야 합니다. 최초 응답을 최종 결과라고 고정할 수 없는 대표 사례입니다.

보고서에는 “4개 체결, 잔여 부분 취소”처럼 실제 결과를 나누어 설명할 수 있습니다. 종료됐다는 사실과 전량 체결됐다는 사실을 혼동하지 않습니다.

가상 사례 5: 응답 유실과 재조회

실제 주문 요청을 보낸 뒤 네트워크 문제로 응답을 받지 못했다고 가정합니다. 화면에 ACK도 RESULT도 FULL도 나타나지 않았습니다.

이때는 주문이 반드시 실패했다고 단정할 수 없습니다. 요청 전달과 응답 수신은 다른 단계이기 때문입니다. 공식 오류 지침에 따라 사용자 데이터 이벤트와 주문 조회로 실제 상태를 확인하는 절차가 필요합니다.

응답이 없다는 이유로 같은 주문을 곧바로 다시 보내면 중복 주문이 발생할 수 있습니다. 식별자를 활용해 기존 요청과 실제 주문을 대조해야 합니다.

이 사례에서 중요한 것은 특정 응답 형식으로 바꾸면 통신 문제가 사라진다는 주장이 아닙니다. 어떤 형식에서도 불명확 상태를 별도로 다루고 복구할 수 있어야 한다는 점입니다.

화면 설계에서 피해야 할 표현

“FULL 성공”이라고만 표시하면 사용자가 전량 체결로 받아들일 수 있습니다. 응답 형식과 주문 상태를 각각 표시하는 편이 명확합니다.

“수수료 없음”도 주의해야 합니다. 현재 응답에 수수료 필드가 없다는 뜻인지 실제 체결 수수료가 0이라는 뜻인지 구분해야 합니다.

“주문 종료”는 취소·만료·전량 체결을 포함할 수 있는 넓은 말입니다. 사용자가 결과를 판단해야 하는 화면에서는 실제 상태와 체결량을 함께 보여주는 것이 좋습니다.

사용자에게 설명할 최소 정보

거래쌍, 매수·매도 방향, 주문 유형, 확인된 상태, 누적 체결량, 확인 시각이 기본적인 맥락을 제공합니다. 개별 체결 비용을 보여줄 때는 수수료 자산도 필요합니다.

아직 확인하지 못한 값은 미확인으로 남겨야 합니다. 화면이 깔끔해 보이도록 빈칸을 임의의 0이나 완료 표시로 채우면 신뢰할 수 있는 기록이 되지 못합니다.

오류 메시지에는 실제 확인한 범위를 담습니다. “체결 실패”라고 단정하는 대신 “응답을 받지 못해 주문 상태 확인 필요”처럼 상황에 맞는 설명이 필요할 수 있습니다.

데이터 대조표 만들기

대조표는 공식 API 필드를 새로 정의하는 표가 아닙니다. 서로 다른 자료를 내부적으로 관리할 때 역할을 나누는 예시입니다.

응답을 원문 그대로 보관하는 것과 분석용 필드를 정규화하는 것은 함께 사용할 수 있습니다. 다만 인증 자료는 제거하고 보관 범위와 접근 권한을 적절히 관리해야 합니다.

문제 해결에서는 원본 자료를 바꾸지 않은 채 파생 계산을 별도로 남기는 방식이 유리합니다. 평균 가격 계산이 잘못됐다면 원본 체결값에서 다시 계산할 수 있기 때문입니다.

자주 발생하는 문제와 점검

RESULT인데 fills가 없다

RESULT와 FULL의 정보 범위가 다릅니다. 개별 체결 배열을 요구하는 파서라면 요청 형식과 기대 구조가 맞는지 확인합니다. fills가 없다는 사실만으로 체결이 없었다고 결론내리지 않습니다.

FULL인데 주문이 NEW다

FULL은 응답 형식입니다. 주문 상태는 별도로 읽습니다. 체결이 없는 상태에서는 실제 체결 자료가 생길 때까지 후속 확인이 필요합니다.

평균 가격이 비정상적으로 크다

기초 자산 수량과 기준 자산 대금의 단위, 소수점 처리, 누적값 중복 합산 여부를 확인합니다. 가격 필드와 평균 가격 계산식을 혼동하지 않았는지도 봅니다.

거래량이 실제보다 많다

최초 응답과 이벤트, 거래 내역을 모두 새 거래로 더했는지 확인합니다. 한 주문의 누적값을 여러 번 합산한 경우도 흔한 구조적 원인입니다.

수수료 합계가 잔고와 맞지 않는다

수수료 자산을 분리했는지, 시험 요율과 실제 차감액을 혼동하지 않았는지, 체결 중복이 있는지 확인합니다. 동일 숫자라도 단위가 다르면 합산할 수 없습니다.

오래된 상태가 다시 나타난다

응답 도착 순서만으로 최신 상태를 결정하는지 확인합니다. 서로 다른 출처와 시각의 자료를 비교할 때는 실제 처리 시각과 조회 시점의 차이를 고려해야 합니다.

자주 묻는 질문

Q1. ACK가 가장 빠른 체결을 보장하나요?

아닙니다. 응답 정보의 범위를 선택하는 값입니다. 주문장 우선순위나 체결 가격의 개선을 보장하는 옵션으로 설명할 수 없습니다.

Q2. FULL은 전량 체결이라는 뜻인가요?

아닙니다. FULL은 상세 응답 형식이고 FILLED는 주문 상태입니다. 실제 전량 체결 여부는 상태와 수량 자료로 확인합니다.

Q3. 기본 응답 형식은 무엇인가요?

작성일 현물 신규 주문 문서는 MARKET과 LIMIT은 FULL, 다른 주문 유형은 ACK를 기본값으로 안내합니다. 개별 엔드포인트와 최신 문서를 다시 확인해야 합니다.

Q4. ACK에 executedQty가 없으면 0인가요?

확인되지 않은 값입니다. 필드 부재를 실제 체결량 0으로 바꾸면 안 됩니다. 후속 조회나 이벤트로 상태를 확인합니다.

Q5. RESULT의 executedQty는 이번 체결량인가요?

누적 체결량으로 읽습니다. 여러 번 받은 누적값을 모두 더하면 중복 집계가 발생할 수 있습니다.

Q6. FULL의 fills는 미래 체결까지 포함하나요?

미래 결과를 포함하지 않습니다. 주문이 이후에도 활성 상태라면 후속 체결과 종료 상태를 별도로 확인해야 합니다.

Q7. 시장가 price가 0이면 잘못 체결된 건가요?

그 숫자만으로 판단할 수 없습니다. 주문 조건 필드와 실제 체결 가격을 구분하고 누적 대금·수량 또는 개별 체결 내역을 확인합니다.

Q8. 평균 체결 가격은 어떻게 읽나요?

체결량이 0보다 클 때 누적 기준 자산 대금을 누적 기초 자산 체결량으로 나눠 확인할 수 있습니다. 수수료 포함 원가와는 별도 지표입니다.

Q9. commission 값만 더해도 되나요?

commissionAsset을 함께 확인해야 합니다. 다른 자산의 수수료를 숫자만으로 단순 합산하면 의미 없는 결과가 됩니다.

Q10. 취소됐으면 기존 체결도 없어지나요?

아닙니다. 일부 체결 후 취소된 주문은 이미 발생한 체결이 남습니다. 종료 상태와 거래 이력을 분리해 기록합니다.

Q11. 응답을 못 받으면 같은 주문을 다시 보내면 되나요?

먼저 실제 상태를 확인해야 합니다. 요청 전달은 됐지만 응답만 유실됐을 수 있어 즉시 재주문은 중복 위험을 만들 수 있습니다.

Q12. Test Order에서도 같은 형식으로 읽으면 되나요?

시험 엔드포인트의 응답 계약을 별도로 확인해야 합니다. 일반 시험의 {} 응답을 실제 신규 주문 파서로 판단하면 오류가 생길 수 있습니다.

Q13. FULL을 쓰면 사용자 데이터 이벤트가 필요 없나요?

최초 응답 이후의 변화를 확인해야 할 수 있습니다. 상세 응답이 주문 생애 전체의 상태 추적을 대신하지 않습니다.

Q14. 조건부 필드가 없으면 오류인가요?

해당 기능이나 사건이 적용되지 않아 생략될 수 있습니다. 공식 문서의 표시 조건을 확인하고 필드 부재를 임의로 해석하지 않습니다.

Q15. 어떤 형식을 선택하는 것이 좋은가요?

필요한 정보와 후속 조회·이벤트 처리 구조에 따라 다릅니다. 짧은 응답이나 긴 응답 자체보다 식별·상태 갱신·중복 제거·복구 절차가 중요합니다.

운영 점검 체크리스트

• 요청의 newOrderRespType과 주문 유형별 기본값을 확인했는가.
• FULL과 FILLED를 다른 값으로 처리하는가.
• ACK의 필드 부재를 0이나 미체결로 바꾸지 않는가.
• symbol·orderId·clientOrderId를 구분해 저장하는가.
• 누적 체결량과 개별 체결량을 구분하는가.
• 가격과 수량의 자산 단위를 유지하는가.
• 체결량 0에서 평균 가격 나눗셈을 피하는가.
• 지정 가격과 실제 체결 평균을 별도로 표시하는가.
• 수수료 수량과 수수료 자산을 함께 보관하는가.
• 동일 체결이 여러 경로로 들어와도 중복 집계하지 않는가.
• 조건부 필드의 표시 조건을 공식 문서와 대조하는가.
• 일부 체결 후 취소·만료를 올바르게 기록하는가.
• 응답 유실 시 실제 주문 상태를 먼저 확인하는가.
• 최초 응답 이후의 상태를 갱신하는 경로가 있는가.

핵심 정리

마무리

바이낸스 ACK RESULT FULL 차이를 이해하면 응답에서 확인된 사실과 아직 모르는 사실을 나눌 수 있습니다. ACK는 추적의 출발점이고, RESULT는 상태와 누적값을 읽는 자료이며, FULL은 체결 세부 정보를 더 제공합니다.

세 형식 중 무엇을 선택하든 실제 상태와 체결 내역을 일관되게 연결하는 과정이 필요합니다. 다음 단계에서는 주문이 종료됐을 때 expiryReason이 상태값과 어떻게 다른 설명을 제공하는지 살펴보면 좋습니다.

공식 참고 자료

• Binance Spot 신규 주문과 응답 형식
• Binance Spot 주문 상태 정의
• Binance Spot 사용자 데이터 스트림

이 글은 API 기능과 기록 해석을 위한 정보이며 투자 권유가 아닙니다. 응답 필드와 지원 조건은 변경될 수 있으므로 실제 적용 전 최신 공식 문서를 확인하세요.