바이낸스 Trading Status 뜻 2026｜TRADING·HALT·BREAK·CANCEL_ONLY 차이

바이낸스 Trading Status 뜻 2026｜TRADING·HALT·BREAK·CANCEL_ONLY 차이

바이낸스 Trading Status는 이 글에서 거래쌍의 현재 거래 상태를 뜻합니다. 개별 주문이 체결됐는지 보여주는 Order Status와 다르고, API 키의 거래 권한이나 코인의 입출금 가능 여부와도 별개입니다. 가격 데이터가 보인다는 사실만으로 지금 신규 주문을 넣을 수 있다고 판단해서는 안 됩니다.

자동 주문을 실행하기 전에는 심볼 이름과 가격·수량만 확인하는 것으로 충분하지 않을 수 있습니다. 거래쌍의 상태, 계정 권한, 지원 주문 종류, 현재 필터, 잔고 등 여러 조건이 함께 작용합니다. 그중 Trading Status는 “이 시장이 어떤 거래 모드인가”를 확인하는 출발점입니다.

이 글은 Binance Spot의 Symbol Status를 기준으로 합니다. 2026년 10월 27일 공식 ENUM·Spot Glossary·REST API 문서를 확인했습니다. 계정별 거래 제한 조회나 선물 계약 상태를 같은 개념으로 섞지 않으며, 특정 코인이 현재 중단됐다고 주장하는 글이 아닙니다.

주요 상태를 한눈에 보기

표의 상태 설명은 Binance Spot Glossary와 ENUM 문서를 기준으로 합니다. 특정 상황의 재개 시간과 사용자 조치는 해당 거래쌍에 대한 공식 공지도 함께 확인해야 합니다.

1. 심볼 상태와 주문 상태는 다르다

심볼은 BTCUSDT처럼 기준 자산과 표시 자산으로 구성된 거래쌍을 가리킵니다. Trading Status는 그 거래쌍의 거래 상태입니다. 반면 NEW, PARTIALLY_FILLED, FILLED, CANCELED 같은 값은 개별 주문이 어떤 상태인지 설명합니다.

예를 들어 심볼이 TRADING이라고 해서 내 주문이 체결된 것은 아닙니다. 시장이 주문을 받을 수 있는 상태라는 의미와 실제 상대 주문을 만나 체결됐다는 의미는 다릅니다. 반대로 특정 주문이 취소됐다고 해당 심볼 전체가 중단된 것도 아닙니다.

프로그램에서 두 값을 모두 status라는 이름으로 저장하면 혼동하기 쉽습니다. 내부에서는 symbol_status와 order_status처럼 목적을 드러내는 이름으로 분리할 수 있습니다. 이는 구현 편의를 위한 제안이며 공식 필드 이름을 임의로 바꾸어 API에 보내라는 뜻은 아닙니다.

계정 거래 권한과도 구분

심볼이 TRADING이어도 특정 계정이 그 상품을 거래할 권한이 없거나 API 키 설정이 맞지 않으면 주문이 거절될 수 있습니다. 따라서 시장 상태 하나만으로 모든 사용자에게 거래가 가능하다고 안내하지 않습니다. 지역·계정·상품별 조건은 실제 서비스 안내를 확인해야 합니다.

또한 코인의 입출금 상태와 현물 거래쌍의 상태는 다를 수 있습니다. 입금이 중단됐다는 공지가 곧바로 모든 현물 거래 중단을 의미한다고 단정하거나, 거래가 가능하다고 모든 네트워크 출금이 가능하다고 생각하면 안 됩니다. 작업 목적에 맞는 상태를 확인하세요.

2. TRADING을 읽는 방법

공식 Glossary는 TRADING을 주문을 제출할 수 있는 상태로 설명합니다. 이것은 거래쌍 차원의 출발 조건입니다. 실제 주문이 수락되려면 가격·수량 필터, 잔고, 권한, 시간 검증, 주문 종류 등 다른 조건도 충족해야 합니다.

“TRADING이니 어떤 주문이든 된다”는 해석은 범위를 넓힌 것입니다. 예를 들어 해당 심볼에서 지원하지 않는 주문 종류를 보내거나 수량 단위를 맞추지 않으면 별도 오류가 발생할 수 있습니다. 거래 상태와 주문 유효성 검사는 서로 보완 관계입니다.

조회 시점과 전송 시점 사이에 상태가 바뀔 가능성도 고려해야 합니다. 클라이언트가 방금 확인한 상태는 그 시점의 관측값이지 미래의 주문 수락을 보장하는 약속이 아닙니다. 최종 요청 결과를 읽고 오류에 맞는 처리를 해야 합니다.

상태 확인은 가격 판단을 대신하지 않는다

TRADING은 유동성이 충분하다거나 스프레드가 좁다거나 슬리피지가 작다는 뜻이 아닙니다. 시장 상태와 실행 품질은 다른 질문입니다. 실제 가격·호가 깊이·주문 크기·시장 변동을 별도로 확인해야 합니다.

이 구별은 고급 주문에서도 중요합니다. 알고리즘이 주문을 나누어 실행하더라도 거래쌍 상태와 계정 조건의 영향을 받을 수 있습니다. 특정 알고리즘을 사용하면 중단 상태에서도 계속 거래할 수 있다고 추측하지 마세요.

3. HALT와 BREAK의 차이

공식 Glossary는 HALT를 긴급 중단 상황 등에서 거래할 수 없는 상태로 설명하면서 시장 데이터는 계속 생성된다고 안내합니다. 따라서 시세 또는 호가 관련 데이터가 보인다는 사실만으로 신규 거래 가능성을 판단하면 안 됩니다.

BREAK는 예정된 중단 상황 등에서 거래할 수 없는 상태로 설명되며, 시장 데이터가 생성되지 않는다고 안내합니다. 두 상태 모두 거래 불가라는 공통점이 있지만 데이터 제공의 설명이 다르므로 같은 화면 처리로 합치기 전에 의미를 확인해야 합니다.

이 문서의 일반 설명만으로 특정 심볼의 중단 원인을 확정할 수는 없습니다. HALT라고 표시됐다는 이유로 어떤 사고가 발생했다고 추측하거나, BREAK이므로 몇 분 뒤 반드시 재개된다고 안내하지 않습니다. 실제 사유와 일정은 관련 공식 공지를 확인해야 합니다.

데이터가 움직이는 것처럼 보일 때

화면의 가격 숫자가 남아 있거나 데이터 메시지가 도착해도 현재 신규 주문 가능 상태라는 증거는 아닙니다. 데이터 생성 여부와 거래 허용 여부를 별도 항목으로 표시하면 사용자가 혼동할 가능성을 줄일 수 있습니다.

반대로 데이터가 멈췄다고 항상 거래소가 BREAK 상태라고 단정할 수도 없습니다. 네트워크 연결 중단, 클라이언트 파싱 오류, 화면 갱신 문제일 수 있기 때문입니다. 심볼 상태와 로컬 연결 상태를 각각 확인해야 합니다.

4. CANCEL_ONLY의 의미

현재 공식 Glossary는 CANCEL_ONLY에서 해당 심볼의 주문 취소와 수정만 가능하다고 설명합니다. 시장 데이터는 캔들을 제외하고 생성된다고 안내합니다. 이름만 보고 취소 외에는 아무 작업도 없다고 단정하지 말고 공식 설명을 확인해야 하는 이유입니다.

여기서 수정은 해당 기능의 지원 규칙을 따라야 합니다. 모든 종류의 가격·수량 변경을 자유롭게 할 수 있다고 일반화하지 않습니다. 특히 기존 주문의 수량 수정과 취소 후 새 주문 제출은 실행 구조가 다르므로 같은 행동으로 취급하지 않아야 합니다.

Cancel Replace는 취소와 새 주문 제출이 함께 관련되는 기능입니다. CANCEL_ONLY에서 새 주문 부분까지 정상 실행될 것이라고 추측하지 마세요. 해당 경로의 최신 규칙과 실제 응답을 확인해야 하며, 취소·수정 허용 설명을 신규 주문 허용으로 확대해서는 안 됩니다.

취소하면 과거 체결은 유지

거래쌍 상태가 제한돼도 이미 체결된 거래가 없었던 일이 되는 것은 아닙니다. 일부 체결 후 남은 주문을 취소한다면 실제 체결량과 잔량을 구분해야 합니다. 상태 전환 이후의 행동을 판단할 때 과거 체결 기록도 함께 확인하세요.

자동화가 상태 변화를 감지했다고 계정의 모든 주문을 일괄 취소하는 것은 별도 전략·권한 문제입니다. 이 글은 그런 일괄 조치를 권유하지 않습니다. 어떤 주문에 어떤 작업을 할지는 사용자의 승인 범위와 실제 운영 정책 안에서 판단해야 합니다.

5. END_OF_DAY를 이름만으로 추측하지 않기

END_OF_DAY는 공식 ENUM 목록에 포함된 상태입니다. 그러나 이름을 한국어로 번역한 것만으로 모든 시장에 동일한 일일 마감 시간이나 다음 날 자동 재개가 있다고 결론 내릴 수 없습니다. 구체적인 제품·심볼의 안내가 필요합니다.

프로그램이 예상하지 못한 상태를 만났을 때는 이를 TRADING으로 자동 치환하지 않는 편이 중요합니다. 알 수 없는 값은 원본과 관측 시각을 보존하고 신규 판단을 제한하는 검토 상태로 다룰 수 있습니다. 이는 클라이언트의 보수적인 운영 설계입니다.

지원 상태 목록이 바뀌면 파서를 갱신해야 할 수 있습니다. 따라서 ENUM을 코드에 고정해 두더라도 변경 감지와 검토 절차를 마련하세요. 새로운 값이 등장했다고 임의 의미를 만들어 사용자에게 확정적으로 설명하지 않습니다.

6. exchangeInfo에서 확인하는 순서

Spot REST API 공식 문서의 GET /api/v3/exchangeInfo는 현재 거래 규칙과 심볼 정보를 제공합니다. 응답의 symbols 항목에서 정확한 symbol을 찾고 status를 확인하는 것이 기본 흐름입니다.

심볼 문자열은 기준 자산과 표시 자산을 구분해 확인합니다. 같은 자산 이름이 들어가더라도 다른 quote 자산의 거래쌍은 별도 시장입니다. BTCUSDT와 BTCUSDC 같은 예시는 서로 다른 심볼이라는 설명을 위한 것이며 현재 거래 가능 여부를 여기서 확정하지 않습니다.

status와 함께 지원 주문 종류와 필터, 관련 허용 정보도 볼 수 있습니다. 단 하나의 필드만 추출해 전체 주문 가능 여부로 판단하지 않는 것이 중요합니다. 실제 주문에 필요한 조건은 해당 경로와 제품 문서에서 확인하세요.

symbolStatus 필터의 역할

현재 exchangeInfo 문서는 symbolStatus로 해당 거래 상태의 심볼을 필터링할 수 있다고 안내하며, symbol 또는 symbols와 함께 사용할 수 없다는 제약을 명시합니다. 필터가 있다고 모든 파라미터를 동시에 넣으면 더 정확해지는 것은 아닙니다.

특정 심볼 하나의 상태를 알고 싶다면 그 목적에 맞는 조회를 사용합니다. 상태별 목록을 만들고 싶다면 필터의 의미를 이해하고 사용합니다. 반환 목록에서 어떤 심볼이 빠졌다고 바로 상장폐지됐다고 결론 내리지 마세요. 필터 조건 때문에 제외됐을 수 있습니다.

권한 필터와 상태 필터도 구분

exchangeInfo에는 permissions 관련 조건도 있습니다. 권한에 따른 반환 범위와 거래 상태에 따른 반환 범위는 다른 질문입니다. 기본 조회에 무엇이 포함되는지와 필터 조합의 제약을 현재 문서로 확인해야 합니다.

목록에 없다는 관측을 설명하려면 요청 파라미터도 함께 기록해야 합니다. 응답만 저장하면 왜 제외됐는지 나중에 알기 어렵습니다. 다만 조회 기록에 인증 비밀을 포함할 필요는 없으며, 공개 정보 조회와 계정 권한 조회는 구분해서 다룹니다.

7. 주문 전 상태 점검 절차

1단계: 대상 시장과 환경 확정

현물인지 선물인지, 운영 환경인지 테스트 환경인지 먼저 구분합니다. 같은 자산 이름이 있어도 서로 다른 상품의 상태는 다를 수 있습니다. 현물 심볼 상태를 읽고 선물 주문 가능 여부를 대신 판단하지 않습니다.

외부 도구를 사용한다면 그 도구가 실제로 어떤 시장에 연결되는지도 확인해야 합니다. 화면 제목만 보고 내부 API 경로를 추측하지 마세요. 공식 안내와 도구의 설정을 확인한 뒤 해당 시장의 상태를 읽는 것이 순서입니다.

2단계: 최신 관측과 출처 기록

심볼 상태와 조회 시각을 함께 저장합니다. “TRADING”이라는 문자열만 캐시에 남아 있으면 언제 확인한 값인지 알 수 없습니다. 갱신 실패 시에는 이전 상태가 현재 확정값인 것처럼 보이지 않도록 표시해야 합니다.

상태를 매순간 무한 조회하는 것이 해결책은 아닙니다. 호출 예산과 갱신 필요성을 고려한 정책을 세우고, 오류나 공식 공지 등 재확인 조건을 마련합니다. 캐시를 쓰더라도 데이터의 오래됨을 감추지 않는 것이 중요합니다.

3단계: 상태에 맞는 작업인지 판단

신규 주문, 취소, 수정은 다른 작업입니다. TRADING이 아닌 경우에도 공식적으로 허용되는 작업이 무엇인지 구분해야 합니다. 반대로 취소·수정이 가능하다는 설명을 모든 거래 작업에 대한 허용으로 넓히지 않습니다.

현재 상태에 맞지 않는 작업을 반복하면 정상적으로 거절되는 요청만 늘어날 수 있습니다. 이를 네트워크 장애로 처리해 계속 재시도하는 구조는 피해야 합니다. 오류 메시지와 심볼 상태를 연결해 원인을 분류합니다.

4단계: 계정·주문 조건 확인

심볼 상태가 적절해도 계정 권한, API 키 권한, 잔고, 가격·수량 단위, 최소 금액, 주문 종류 등 다른 조건이 남습니다. 상태 확인은 전체 검증의 한 단계입니다. 순서도를 만들 때 이 단계를 생략하거나 반대로 모든 검사를 대체하게 하지 않습니다.

필터 값은 거래쌍마다 다를 수 있고 바뀔 수 있습니다. 이전 주문이 성공했다는 사실만으로 다음 주문도 같은 조건에서 수락된다고 보장하지 않습니다. 현재 요청을 기준으로 필요한 검사를 수행하고 최종 응답을 읽어야 합니다.

5단계: 요청 이후 실제 결과 확인

조회와 전송 사이에 상태가 바뀌거나 다른 조건이 실패할 수 있으므로 실제 응답과 주문 업데이트를 확인합니다. 사전 검사 결과가 초록색이었다고 오류 응답을 무시해서는 안 됩니다. 접수·부분 체결·취소·만료를 주문 단위로 추적하세요.

응답이 불명확하면 원래 주문 식별자로 확인하는 절차가 필요합니다. 심볼 상태가 바뀌었다는 사실만으로 원래 주문이 접수되지 않았다고 단정하지 않습니다. 시장 상태와 개별 주문의 실제 이력을 각각 대조해야 합니다.

8. 다섯 가지 상황별 사례

예시 1: 가격 데이터가 오지만 HALT

프로그램에 시장 데이터가 도착하는데 심볼 상태는 HALT라고 가정합니다. 공식 Glossary는 HALT에서도 시장 데이터가 생성될 수 있다고 설명합니다. 따라서 데이터 수신을 신규 주문 허용 신호로 사용하는 로직은 수정이 필요합니다.

화면에는 데이터 연결 상태와 거래 상태를 따로 표시할 수 있습니다. 사용자는 “가격이 보인다”와 “지금 주문할 수 있다”를 구분할 수 있어야 합니다. 구체적인 중단 이유와 재개 일정은 해당 공식 공지에서 확인하며 추측으로 채우지 않습니다.

예시 2: 데이터가 멈췄지만 원인은 네트워크

가격이 갱신되지 않는 상황에서 곧바로 BREAK이라고 판단했다고 가정합니다. 실제로는 클라이언트 연결이 끊겼을 수 있습니다. 데이터 미수신이라는 증상 하나로 거래소 상태를 확정할 수 없는 이유입니다.

연결 상태, 마지막 수신 시각, 공식 심볼 상태 조회를 구분해서 점검합니다. 오래된 가격을 현재 가격으로 표시하지 않도록 갱신 시각을 보여주는 것도 도움이 됩니다. 연결 복구 후에도 데이터가 최신인지 확인해야 합니다.

예시 3: CANCEL_ONLY에서 Cancel Replace 시도

운영자가 “취소가 가능하니까 취소 후 새 주문도 한 번에 가능할 것”이라고 생각했다고 가정합니다. Cancel Replace에는 새 주문 제출이 포함되므로 단순 취소와 같은 작업으로 볼 수 없습니다. 상태의 이름만으로 기능 조합 전체의 허용 여부를 추측하면 안 됩니다.

허용 작업과 해당 엔드포인트의 실제 결과를 구분해 확인해야 합니다. 이미 체결된 수량이 있으면 그 기록은 별도로 유지합니다. 이 예시는 특정 계정에서 어떤 오류 코드가 나온다고 단정하는 것이 아니라 작업 의미를 분리하라는 설명입니다.

예시 4: TRADING인데 주문 거절

심볼은 TRADING이지만 주문 수량이 현재 stepSize에 맞지 않거나 계정 권한이 없다고 가정합니다. 이 경우 거래 상태가 정상이라는 사실과 주문 거절은 모순되지 않습니다. 서로 다른 검사를 보기 때문입니다.

오류 코드와 메시지를 읽고 필터·잔고·권한·시간 등 해당 항목을 확인합니다. 상태 조회만 반복하는 것은 원인을 해결하지 못할 수 있습니다. “거래소가 열려 있는데 왜 안 되지?”라는 질문을 개별 조건으로 나누는 것이 진단의 핵심입니다.

예시 5: 필터된 목록에서 심볼이 사라짐

TRADING 상태만 요청한 목록에서 어떤 심볼이 보이지 않는다고 가정합니다. 이것만으로 심볼이 삭제됐거나 자산이 상장폐지됐다고 확정할 수 없습니다. 필터에 맞지 않아 제외됐을 수 있고 권한 관련 반환 범위도 확인해야 합니다.

요청 파라미터와 해당 심볼의 공식 정보를 대조합니다. 검색 결과의 부재를 곧바로 사건 발생으로 해석하지 않는 습관이 중요합니다. 사용자에게 공지할 때도 확인된 상태와 아직 확인하지 못한 사유를 구분해야 합니다.

9. 자동 주문과 알고리즘 실행에 미치는 의미

TWAP나 다른 실행 알고리즘을 사용할 때도 시장과 계정의 현재 상태를 이해해야 합니다. 알고리즘이 주문을 나누는 방식과 거래쌍이 허용하는 작업은 서로 다른 층입니다. 특정 상태에서 하위 주문이 어떻게 처리되는지는 해당 제품의 공식 규칙을 따릅니다.

상태 변화를 감지했다고 모든 알고리즘이 자동으로 같은 방식으로 재개되거나 취소된다고 일반화하지 않습니다. 제품마다 실행 기간, 중단 조건, 잔량 처리, 사용자 조치가 다를 수 있습니다. 이 글의 Spot Symbol Status 설명만으로 알고 주문의 전체 생명주기를 대체하지 마세요.

운영 기록에는 상태 변화 전후의 부모 주문·하위 주문·실제 체결을 연결할 수 있어야 합니다. 실행이 중단된 것처럼 보여도 이미 체결된 부분은 남을 수 있습니다. 원래 목표 수량과 실제 실행량을 구분하고, 재개 시 중복 실행되지 않도록 확인해야 합니다.

실행 품질과 거래 상태의 차이

TRADING 상태에서도 호가가 얕거나 스프레드가 넓을 수 있습니다. 거래 상태는 시장 접근의 조건이고 유동성은 실행 가격과 체결 가능성을 이해하는 별도 요소입니다. 따라서 상태 확인 뒤에도 주문 크기와 시장 데이터를 분석해야 합니다.

마찬가지로 HALT나 BREAK의 이름만으로 가격 방향을 예측할 수 없습니다. 재개 후 상승·하락이나 체결 유리함을 보장하는 신호로 사용하지 않습니다. 이 글은 상태를 읽는 기술적 안내이며 거래 신호를 제공하는 문서가 아닙니다.

10. 상태 캐시와 변경 감지

거래 규칙을 효율적으로 사용하려고 캐시를 둘 수 있지만 상태를 영구 고정하는 것은 적절하지 않습니다. 마지막 갱신 시각, 갱신 실패 여부, 원본 출처를 함께 저장하면 오래된 정보가 현재 정보처럼 쓰이는 문제를 줄일 수 있습니다.

상태가 바뀌었을 때 프로그램이 어떤 작업을 중단하고 어떤 확인을 계속할지 정해두는 편이 좋습니다. 단순히 오류가 나면 전부 재시도하는 방식보다 의미별 대응이 필요합니다. 다만 구체적인 자동 취소·수정 정책은 사용자가 승인한 거래 운영 범위에 속해야 합니다.

새로운 상태 값이 들어오면 로그에 남기고 공식 문서를 확인할 수 있도록 설계합니다. 알 수 없는 상태를 TRADING으로 간주하는 기본값은 예상치 못한 주문을 만들 수 있습니다. 반대로 모든 자료를 삭제하는 반응도 원인 분석에 도움이 되지 않습니다.

11. 상태별 혼동을 줄이는 표

문제 분석에서는 질문을 먼저 정확히 적는 것이 좋습니다. “거래가 안 된다”는 표현에는 계정 권한, 주문 필터, 네트워크, 심볼 중단 등 여러 원인이 포함될 수 있습니다. 어떤 작업을 시도했고 어떤 응답을 받았는지 기록하면 확인 범위를 좁힐 수 있습니다.

상태를 사용자 화면에 표시할 때

하나의 녹색 표시로 합치지 않기

네트워크 연결, 시장 데이터 갱신, 거래쌍 상태, 계정 권한, 주문 상태를 모두 “정상” 하나로 표시하면 원인을 찾기 어렵습니다. 예를 들어 연결은 정상이고 데이터도 수신되지만 심볼은 HALT일 수 있습니다. 사용자가 무엇이 정상인지 알 수 있도록 항목의 목적을 드러내는 표시가 필요합니다.

상태를 간단히 보여주더라도 상세 화면에서 마지막 확인 시각과 원본 상태를 볼 수 있게 할 수 있습니다. 공식 문자열을 사용자에게 친숙한 한국어로 바꾸는 경우에는 원래 값을 함께 보존하세요. 번역 문구가 너무 넓으면 취소·수정 가능과 신규 주문 가능의 차이가 사라질 수 있습니다.

중단 사유를 추측해서 쓰지 않기

HALT가 보였다는 이유만으로 해킹, 상장폐지, 규제 문제 같은 사유를 덧붙이면 근거 없는 정보가 됩니다. 상태값은 현재의 기술적 상태를 알려줄 뿐 특정 사건의 원인을 모두 설명하지 않습니다. 공식 공지에서 확인된 사유만 구분해서 전달해야 합니다.

재개 예상 시각도 마찬가지입니다. 화면에 과거 공지의 시간이 남아 있거나 다른 거래쌍의 일정이 보인다고 그대로 적용하지 않습니다. 시간대와 적용 대상, 갱신 공지 여부를 확인하고, 확인되지 않은 경우에는 일정 미확인으로 표현하는 편이 정확합니다.

오래된 상태를 표시하는 방법

상태 갱신에 실패했을 때 이전 TRADING 값을 계속 현재 상태처럼 보이면 사용자가 잘못 판단할 수 있습니다. 마지막 확인값과 현재 확인 불가를 나누어 보여주는 방식이 도움이 됩니다. 이 구분은 서버 상태가 실제로 바뀌었다는 단정이 아니라 관측의 한계를 표시하는 것입니다.

같은 원칙은 가격과 호가에도 적용됩니다. 과거 데이터 자체는 분석에 유용할 수 있지만 실시간 판단에 사용하는 값과 구분해야 합니다. 갱신 시각이 없으면 오래된 데이터와 현재 데이터가 똑같이 보이므로 상태 진단에 필요한 맥락을 잃게 됩니다.

주문 오류와 함께 보는 기록

주문이 거절됐을 때 직전 심볼 상태, 조회 시각, 실제 에러 메시지를 함께 저장하면 원인을 좁힐 수 있습니다. 직전 조회가 TRADING이었다고 오류를 삭제하지 않고, 조회 이후 상태 변화 또는 다른 검사를 고려합니다. 사전 관측과 최종 응답은 각각 보존할 가치가 있습니다.

운영자가 문제를 해결한 뒤에는 같은 요청을 반복하기 전에 현재 거래 의사와 원래 주문의 결과를 확인합니다. 시장 상태가 정상으로 돌아왔다는 사실만으로 과거에 보낸 요청이 모두 미접수였다고 볼 수는 없습니다. 재개 시점에도 식별자와 실제 주문 내역을 연결해야 합니다.

데이터 필터 오류와 거래 중단 구분

현재 REST 문서는 일부 시장 데이터 경로에서 symbolStatus 조건과 실제 심볼 상태가 맞지 않으면 -1220 SYMBOL_DOES_NOT_MATCH_STATUS가 반환될 수 있다고 설명합니다. 이는 요청한 필터 조건을 읽는 데 중요한 신호입니다. 모든 주문 거절에 같은 코드가 나온다는 뜻으로 일반화하지 않습니다.

단일 심볼 조회와 복수·전체 심볼 조회에서는 불일치 항목을 처리하는 설명이 다를 수 있습니다. 따라서 응답이 오류인지 빈 목록인지 확인할 때 사용한 경로와 파라미터를 함께 봐야 합니다. “응답이 없으니 시장이 사라졌다”는 결론보다 먼저 조회 조건이 목적에 맞는지 검토하세요.

공지와 기술 상태를 함께 보관하는 이유

공식 공지는 예정된 일정과 사용자 안내를 설명하고, API 상태는 조회 시점의 기술적 값을 보여줍니다. 둘은 서로 보완하는 자료입니다. 공지에 예정 시간이 있다는 이유로 실제 상태 확인을 생략하거나, 상태값만 보고 공지의 적용 대상과 조건을 무시하지 않습니다.

운영 기록에 공지의 대상 거래쌍과 확인 시각, API 관측 시각을 함께 남기면 시간 차이를 이해하기 쉽습니다. 다만 공지 내용이 바뀔 수 있으므로 과거 사본을 최신 안내처럼 제시하지 않습니다. 필요한 경우 공식 원문을 다시 확인하고 변경된 사실을 구분해 기록하세요.

12. FAQ

Q1. 바이낸스 Trading Status는 주문 상태인가요?

이 글에서 다루는 값은 거래쌍의 Symbol Status입니다. NEW나 FILLED 같은 개별 주문 상태와 구분해야 합니다. 같은 status라는 이름이 쓰이더라도 어느 응답 객체의 값인지 먼저 확인하세요.

Q2. TRADING이면 주문은 반드시 성공하나요?

아닙니다. 계정 권한, 지원 주문 종류, 필터, 잔고, 시간 유효성 등 다른 조건도 필요합니다. TRADING은 거래쌍 차원의 상태이며 특정 요청의 접수나 체결을 보장하지 않습니다.

Q3. HALT인데 데이터가 오는 것은 오류인가요?

공식 Glossary는 HALT에서 시장 데이터가 생성된다고 설명합니다. 따라서 데이터 수신과 거래 가능 여부를 분리해야 합니다. 구체적인 상황의 원인은 해당 심볼의 공식 공지로 확인하세요.

Q4. BREAK와 HALT는 같은가요?

둘 다 거래 불가 상태로 설명되지만 중단 맥락과 시장 데이터 생성 설명이 다릅니다. BREAK는 예정된 중단 등과 연결되고 데이터가 생성되지 않는다고 안내됩니다. 이름만으로 재개 시각을 추측하지 않습니다.

Q5. CANCEL_ONLY는 취소만 가능한가요?

현재 공식 Glossary는 취소와 수정만 가능한 상태로 설명합니다. 다만 모든 수정 종류가 자유롭게 허용된다는 뜻은 아니므로 해당 기능의 규격을 확인해야 합니다. 신규 주문 허용으로 확대 해석하지 마세요.

Q6. CANCEL_ONLY에서 캔들은 계속 생성되나요?

공식 설명은 캔들을 제외한 시장 데이터가 생성된다고 안내합니다. 실제 화면의 과거 캔들이 남아 있는 것과 새로운 캔들이 생성되는 것은 구분해야 합니다. 표시된 데이터의 갱신 시각을 함께 보세요.

Q7. END_OF_DAY면 다음 날 자동 재개되나요?

상태 이름만으로 그런 결론을 내릴 수 없습니다. 구체적인 제품과 심볼의 공식 설명·공지를 확인해야 합니다. 이 글은 확인되지 않은 재개 시간이나 자동 처리 규칙을 만들지 않습니다.

Q8. 상태는 어디서 확인하나요?

Spot REST의 exchangeInfo에서 심볼 정보를 확인할 수 있습니다. 정확한 symbol과 응답의 status를 읽고, 조회 시각과 요청 조건을 함께 기록하세요. 다른 시장의 상태를 현물에 대입하지 않습니다.

Q9. symbol과 symbolStatus를 같이 보내도 되나요?

현재 exchangeInfo 문서는 symbolStatus를 symbol 또는 symbols와 함께 사용할 수 없다고 안내합니다. 다른 엔드포인트까지 같은 조합 규칙이라고 일반화하지 말고 사용하는 경로의 설명을 확인해야 합니다.

Q10. 목록에서 사라지면 상장폐지인가요?

필터 조건이나 반환 범위 때문에 보이지 않을 수 있습니다. 요청 파라미터와 공식 심볼 정보·공지를 대조해야 합니다. 목록에서 빠졌다는 한 가지 관측만으로 상장폐지를 확정하지 마세요.

Q11. 출금이 중단되면 거래도 중단되나요?

입출금 상태와 현물 거래쌍의 상태는 별도입니다. 네트워크별 출금 안내와 거래 상태를 각각 확인해야 합니다. 한 기능의 중단을 모든 기능의 중단으로 확대해서 해석하지 않습니다.

Q12. 가격이 안 움직이면 BREAK인가요?

그럴 수 있다고 추측만 해서는 안 됩니다. 네트워크나 화면 처리 문제일 수도 있습니다. 연결 상태와 마지막 갱신 시각, 공식 심볼 상태를 구분해서 확인해야 합니다.

Q13. 상태가 바뀌면 기존 체결이 취소되나요?

상태 변화만으로 과거 체결이 자동으로 없어진다고 보지 않습니다. 개별 주문·체결 내역을 확인해야 합니다. 부분 체결과 남은 수량, 취소·만료 결과를 주문 단위로 기록하세요.

Q14. 자동 봇은 상태를 얼마나 자주 확인해야 하나요?

모든 환경에 같은 주기를 제시할 수는 없습니다. 호출 예산, 데이터의 오래됨, 오류 시 재확인, 공식 공지 등을 고려한 정책이 필요합니다. 무한 반복 조회나 영구 캐시 양쪽 모두 문제를 만들 수 있습니다.

Q15. 다음 글은 어떤 주제로 이어지나요?

거래 가능한 상태를 확인한 다음에는 주문 접수와 실제 실행 품질의 차이로 이어질 수 있습니다. 이후 주제는 기존 글과 중복을 확인해 선정해야 하며, 같은 상태 이름만 바꾼 유사 글을 반복할 필요는 없습니다.

13. 실행 체크리스트

• 현물·선물 등 대상 시장을 구분했다.
• 운영·테스트 환경을 구분했다.
• 정확한 거래쌍 symbol을 확인했다.
• 심볼 상태와 개별 주문 상태를 따로 저장한다.
• 상태의 조회 시각과 출처를 기록한다.
• TRADING을 체결 보장으로 해석하지 않는다.
• HALT·BREAK의 데이터 생성 차이를 이해했다.
• CANCEL_ONLY의 허용 작업을 신규 주문과 구분한다.
• 알 수 없는 상태를 임의로 TRADING 처리하지 않는다.
• 계정·API 키 권한과 주문 필터를 추가 확인한다.
• 필터된 목록의 부재를 상장폐지로 단정하지 않는다.
• 입출금 상태를 거래 상태와 분리한다.
• 요청 후 실제 주문·체결 결과를 확인한다.
• 재개 일정은 관련 공식 공지로 확인한다.

핵심 정리

바이낸스 Trading Status를 정확하게 읽으려면 데이터가 보이는지, 시장이 거래를 허용하는지, 내 계정과 주문이 조건을 충족하는지를 나누어 생각해야 합니다. 상태 문자열 하나로 모든 결과를 판단하지 않고 실제 주문 이력까지 연결하는 것이 안정적인 진단의 출발점입니다.

이 글은 거래 상태와 API 자료를 이해하기 위한 정보성 설명입니다. 특정 자산의 거래 가능성·재개 일정·투자 성과를 보장하지 않으며, 실제 이용 전 최신 Binance 공식 문서와 관련 공지를 확인하세요.