바이낸스 상장 코인 개수를 API로 직접 세면 — 종목 목록 3,681개 가운데 TRADING은 1,354개였습니다

altnara 자금흐름 데스크는 시장 데이터가 어느 창구에서 어떤 모양으로 나오는지를 점검합니다. 이번 노트의 주제는 거래소가 내주는 종목 목록에 무엇이 남아 있는가입니다. 운영자 보유 가능성: 본 매체는 비트코인·주요 알트 및 스테이블코인 보유 가능성을 명시합니다.

먼저 이 노트가 재는 자리를 못박아 둡니다. 여기서 잰 것은 전부 인증 헤더를 한 번도 붙이지 않고 부른 공개 종목 목록의 내용물입니다. 가격도 거래량도 보지 않았고, 어느 창구가 낫다는 판단도 하지 않습니다. 그리고 목록은 분 단위로 움직이는 살아 있는 데이터라서, 아래 숫자는 전부 호출 시각을 함께 적었습니다.

"이 거래소에 코인이 몇 개 있나"를 알아보려고 공개 API 를 한 번 불러 보신 적이 있으시다면 한 번쯤 걸리는 자리가 있습니다. 응답에 줄이 몇천 개 오는데, 그 줄이 전부 지금 거래되는 종목은 아닙니다. 이번에 해외 거래소 아홉 곳의 공개 종목 창구를 같은 분에 인증 없이 받아, 각 창구가 스스로 적어 둔 상태 필드로만 세어 봤습니다.

결론부터 — 무엇을 어느 필드로 셌는지부터 밝힙니다

첫째, 제목의 3,681은 코인 개수가 아니라 거래쌍 줄 수입니다. 바이낸스 현물 정보 창구가 내주는 symbols 배열의 길이입니다. 이 배열에는 결제통화가 다른 같은 코인이 여러 줄로 들어 있고, 지금 거래되지 않는 상태로 표시된 줄도 함께 들어 있습니다. 줄 수와 코인 수와 거래 가능한 종목 수는 전부 다른 값이고, 바꿔 쓰면 글이 통째로 틀립니다.

둘째, 그 배열을 응답 자신의 status 필드로 세면 TRADING 1,354개, BREAK 2,327개였습니다. 다른 값은 하나도 없었습니다. 두 수를 더하면 3,681로 전체 길이와 맞습니다. BREAK 비율은 63.22%였습니다. 곧 목록 길이를 그대로 "상장 종목 수"로 읽으면 2,327줄을 잘못 세게 됩니다. 이 값은 2026년 8월 21일 12시 20분 17초(KST) 응답에서 센 것이고, 그때 응답은 17,513,382바이트였습니다. 요청 주소는 이것 하나입니다.

https://api.binance.com/api/v3/exchangeInfo

셋째, 갈리는 폭이 창구마다 완전히 다릅니다. 같은 시각에 받은 아홉 창구 가운데 거래되지 않는 것으로 표시된 줄이 63.22%인 곳이 있는가 하면, 0건인 곳도 있습니다. 그 차이는 시장 상황이 아니라 창구가 목록에 무엇을 남겨 두느냐에서 생깁니다. 어떤 곳은 남겨 두고 상태 칸으로 구분하며, 어떤 곳은 기본 응답에서 통째로 빼 버리고, 어떤 곳은 상태 칸을 값 하나로만 채웁니다.

이 노트가 재는 자리와 재지 않는 자리

같은 주제어로 묶이기 쉬운 자리를 먼저 갈라 둡니다.

첫째, 어느 코인을 사라 마라 하는 글이 아닙니다. 아래에 종목 코드가 여럿 나오지만 전부 상태 칸이 어떻게 적혀 있는지를 보이는 사례로만 씁니다. 가격도 수익률도 다루지 않고, 어떤 자산도 매수 또는 매도 대상으로 지목하지 않습니다.

둘째, 어느 창구가 정확하냐를 가리는 글도 아닙니다. 숫자가 갈리는 이유는 뒤에서 밝히지만, 그것은 목록 수록 기준의 차이이지 한쪽이 틀린 것이 아닙니다.

셋째, 해외 거래소의 공개 창구만 열었습니다. 국내 거래소는 한 곳도 부르지 않았고, 국내 제도도 이 노트의 범위 밖입니다.

넷째, 상태 칸이 그 값이 된 사유는 다루지 않습니다. 응답도 문서도 사유를 알려 주지 않습니다. 이 노트는 "거래되지 않는 상태로 표시돼 있다" 까지만 씁니다.

다섯째, 인증 없이 부른 응답만 봤습니다. 계정 등급이나 지역에 따라 실제로 주문이 들어가는지는 재지 않았습니다.

바이낸스 현물 목록에 남아 있는 BREAK 2,327개

먼저 이 2,327줄이 어떤 모양으로 들어 있는지부터 보겠습니다. 줄이 비어 있지 않습니다. BREAK 로 표시된 줄도 TRADING 줄과 키 구성이 완전히 같고, 주문 제약을 담은 filters 배열까지 그대로 들어 있습니다. 예를 들어 NEOBTC 는 BREAK 인데 filters 가 11개 들어 있습니다. 값이 다 차 있으니 파싱하는 쪽에서는 살아 있는 종목처럼 읽힙니다.

기초자산 단위로 다시 세면 그림이 더 선명해집니다. 같은 응답에서 서로 다른 baseAsset 은 806종이었습니다. 그중 TRADING 상태의 쌍을 하나라도 가진 것은 485종이고, 나머지 321종은 BREAK 쌍만 가지고 있었습니다. 806종의 39.83%입니다. 검산도 맞습니다. 485에 321을 더하면 806입니다.

이 806종과 485종은 같은 응답을 티커 쪽에서 센 어제 노트가 8월 20일 15시 39분(KST) 응답으로 이미 한 번 센 값인데, 하루가 지난 오늘 12시 20분 응답에서도 똑같이 806종·485종이었습니다. 같은 기간에 TRADING 쌍 수는 1,361에서 1,354로 움직였습니다. 거래쌍 단위로는 하루 사이에 일곱 줄이 옮겨 갔는데 기초자산 단위 집계는 한 종도 움직이지 않은 것입니다. 옮겨 간 일곱 줄의 기초자산이 저마다 다른 TRADING 쌍을 아직 가지고 있기 때문입니다.

결제통화 쪽을 보면 덩어리가 어디에 몰려 있는지가 드러납니다. 서로 다른 quoteAsset 은 49종이었고, 그중 TRADING 쌍이 하나도 없는 결제통화가 23종이었습니다. 이 23종에 걸린 쌍만 더해도 645개로 전체의 17.52%입니다.

가장 눈에 걸리는 줄이 맨 아래입니다. BUSD 결제쌍은 378개인데 TRADING 이 하나도 없었습니다. 결제통화 하나에 걸린 378줄이 통째로 BREAK 로 표시된 채 목록에 남아 있는 것입니다. BTC 결제쌍도 488줄 가운데 TRADING 은 38줄뿐이었습니다.

여기서 한 칸 더 넓히면 틀립니다. 이 줄들이 어떤 절차를 거쳤는지, 언제 다시 거래되는지는 응답이 알려 주지 않습니다. 아래에서 볼 공식 용어집도 "거래할 수 없는 상태"라고만 적어 두었습니다. 이 노트는 거기까지만 씁니다.

29분 사이에 일곱 줄이 옮겨 간 자리

숫자가 살아 있다는 말을 추상적으로 남기지 않으려고, 같은 창구를 세 번 불러 대조했습니다.

읽히는 것이 세 가지입니다.

첫째, 34초 간격으로 두 번 부른 2회와 3회는 심볼 단위로 완전히 같았습니다. 상태가 바뀐 심볼 0개, 새로 생긴 심볼 0개, 사라진 심볼 0개였습니다. 곧 값이 아무 때나 흔들리는 것은 아닙니다.

둘째, 29분 떨어진 1회와 2회 사이에는 정확히 일곱 줄이 움직였습니다. 목록 길이는 3,681로 그대로였고, 1회에만 있는 심볼도 2회에만 있는 심볼도 없었습니다. 오직 상태 칸만 바뀌었고 일곱 줄 전부 TRADING 에서 BREAK 로 옮겨 갔습니다. 옮겨 간 줄은 FUSDC, HIVEUSDC, ILVUSDC, LTCBNB, NMRUSDC, STEEMUSDC, SUIBNB 였습니다.

셋째, 왜 옮겨 갔는지는 이 응답으로 알 수 없습니다. 응답에는 사유 칸이 없고 공식 문서도 개별 사유를 적지 않습니다. 그래서 이 노트는 원인을 쓰지 않고 관측만 남깁니다. 다만 실무적으로 읽히는 것은 하나 있습니다. 어제 받아 둔 목록으로 오늘 종목을 고르면 이런 줄을 밟게 됩니다.

문서가 정의한 상태 값과 응답에 실제로 나온 값

여기서 통설을 한 번 걷어내야 합니다. 바이낸스 심볼 상태 값으로 널리 인용되는 목록에는 PRE_TRADING, POST_TRADING, AUCTION_MATCH 가 들어 있는 경우가 많습니다. 현행 공식 파일에는 그 세 값이 없습니다. 공식 저장소의 enums.md 를 12시 21분 16초(KST) 에 직접 받아(5,244바이트) 확인하니 Symbol status (status) 절에 적힌 값은 다섯이었습니다. TRADING, END_OF_DAY, HALT, BREAK, CANCEL_ONLY 입니다.

그리고 값의 뜻은 이 파일이 아니라 다른 파일에 있습니다. 같은 저장소의 용어집 faqs/spot_glossary.md 를 12시 29분 6초(KST) 에 받아(15,846바이트) 확인했습니다. 축자로 옮기면 이렇습니다.

• TRADING — Trading status where orders can be placed.
• BREAK — Symbol's trading status that represents the symbol is not available for trading, which can happen during expected downtime. Market data is not generated during BREAK.
• HALT — Symbol's trading status that represents the symbol is not available for trading, which can happen during emergency downtime. Market data is still generated during HALT.
• CANCEL_ONLY — Trading status where users can only cancel and amend orders on that symbol.

BREAK 와 HALT 를 가르는 자리는 두 곳입니다. 중단이 expected 냐 emergency 냐가 하나이고, 그동안 시장 데이터가 생성되지 않느냐(not generated) 여전히 생성되느냐(still generated)가 다른 하나입니다. 두 정의를 낱말 단위로 맞대면 값 이름을 빼고 갈리는 자리는 이 둘뿐이고 나머지 문장은 글자까지 같습니다. 그 이상은 문서가 적지 않았습니다. 왜 그 상태가 되었는지도, 언제 풀리는지도 적혀 있지 않습니다.

다섯 값 가운데 뜻이 적혀 있지 않은 것은 END_OF_DAY 하나였습니다. 이건 부정 서술이라 범위를 밝혀 두겠습니다. 공식 저장소에서 직접 받아 훑은 파일 일곱 개에서 END_OF_DAY 문자열이 몇 번 나오는지를 세었습니다. enums.md(5,244바이트) 1회, rest-api.md(181,189바이트) 0회, filters.md(13,528바이트) 0회, errors.md(20,321바이트) 0회, web-socket-api.md(277,525바이트) 0회, CHANGELOG.md(132,483바이트) 0회, faqs/spot_glossary.md(15,846바이트) 0회입니다. 이 일곱 파일에서는 목록에 한 번 등장하는 것이 전부이고 뜻을 적은 자리는 0건이었습니다. 저장소 전체와 중국어판, 웹 문서 사이트는 훑지 않았으므로 "어디에도 없다"로 넓히지는 않겠습니다.

한 가지 더 어긋나는 자리가 있습니다. rest-api.md 를 12시 28분 11초(KST) 에 받아 보니, 종목 목록을 상태로 걸러 주는 파라미터 설명이 이렇게 적혀 있습니다. 축자로 Filters for symbols that have this tradingStatus. Valid values: TRADING, HALT, BREAK 입니다. 상태 값은 다섯인데 필터가 받는 값은 셋입니다. END_OF_DAY 와 CANCEL_ONLY 는 넘길 수 없습니다. 원인은 문서에 적혀 있지 않아 관측만 적어 둡니다.

기본 응답에서 통째로 빠지는 종목 — 바이비트 선물의 Closed 945건

바이낸스가 목록에 남겨 두는 쪽이라면, 반대쪽 방식도 있습니다. 12시 20분 18초(KST) 에 바이비트 v5 종목 창구를 선물(linear) 기준으로 네 번 불렀습니다.

세 상태를 더하면 1,781건이고, 기본 응답 832건은 그중 46.72%입니다. 곧 아무 파라미터도 넣지 않으면 Closed 945건과 PreLaunch 4건, 합쳐 949건이 응답에 아예 나오지 않습니다. 1,781 대비 53.28%가 화면에 안 보이는 셈입니다. 세 몫을 따로 적으면 832건 46.72%, 945건 53.06%, 4건 0.22%이고 더하면 100.00%입니다. 이 검산을 건너뛰고 100에서 53.06을 빼면 46.94%라는 다른 값이 나옵니다. PreLaunch 네 건의 몫이 기본 응답 쪽에 얹히기 때문입니다.

이게 페이지가 잘려서 생긴 일이 아니라는 것도 확인했습니다. 네 호출 모두 nextPageCursor 가 빈 문자열이었습니다. 다음 페이지가 없다는 뜻이니, 빠진 949건은 페이지 밖이 아니라 응답 조건 밖에 있는 것입니다.

바이비트 공식 문서도 이 동작을 그대로 적어 두었습니다. 12시 21분 17초(KST) 에 받은 종목 창구 문서(223,087바이트)에서 status 파라미터 설명은 한 문장이 아니라 항목 네 개로 갈려 있습니다. 첫 항목이 축자로 linear & inverse & spot By default returns only Trading symbols 이고, 세 번째 항목에 Spot has Trading only 가 따로 적혀 있습니다. 그 사이에는 option 을 다루는 다른 항목이 하나 끼어 있습니다. 상태 값 목록은 같은 시각에 받은 열거값 문서(90,347바이트)에 PreLaunch Trading Delivering Closed 넷으로 적혀 있습니다. 문서가 정의한 값은 넷인데 이번 조회에 나온 값은 셋이고, Delivering 은 0건이었습니다.

현물 쪽도 확인했습니다. category=spot 은 status 를 무엇으로 넣든 555건 전부 Trading 이 왔고, 네 호출의 응답 크기가 300,999바이트로 전부 같았습니다. 파라미터를 넣어도 오류가 나지 않고 같은 응답이 옵니다. 이건 버그가 아니라 문서에 적힌 대로입니다. 앞서 옮긴 Spot has Trading only 가 그 문장입니다. 응답이 정상으로 오는데도 원하는 조건이 조용히 무시되는 자리가 있다는 점은 응답 머리글이 알려 주는 것과 알려 주지 않는 것을 정리한 노트에서도 다뤘습니다.

참고로 status=PreLaunch 로 온 4건은 ANTHROPICUSDT, BPUSDT, MOONSHOTUSDT, OPENAIUSDT 였습니다. 위에서 더한 949건 가운데 넷이 이들입니다.

같은 스위치를 서로 다른 이름으로 적은 아홉 창구

아홉 창구를 같은 분에 받아 한 표에 놓겠습니다. 세는 규칙은 하나입니다. 각 응답이 스스로 적어 둔 분류 필드로만 셌고, 그 필드 이름을 수치 옆에 적었습니다. 티커 목록을 미리 만들어 두고 맞춰 보는 방식은 쓰지 않았습니다. 전부 12시 20분 17초부터 12시 20분 20초(KST) 사이의 응답입니다.

한 줄씩 짚어 두겠습니다.

HTX 는 목록에 남겨 두는 쪽입니다. 2,110건 가운데 state 가 offline 인 것이 1,513건으로 71.71퍼센트였고, online 은 594건, suspend 는 3건이었습니다. 아홉 창구 중 거래 가능 표시 비율이 가장 낮았습니다. 공식 문서(830,811바이트, 12시 23분 41초 KST)는 이 필드의 값을 여덟 개로 적어 두었습니다. 축자로 unknown，not-online，pre-online，online，suspend，offline，transfer-board，fuse 입니다. 여덟 중 셋만 응답에 나왔습니다.

OKX 는 목록 자체가 짧습니다. 현물 1,379건 가운데 live 가 1,371건이고, 나머지는 preopen 6건과 rebase 2건뿐입니다. 다만 여기에 함정이 하나 섞여 있습니다. 공식 문서(5,242,376바이트, 12시 22분 19초 KST)는 rebase 를 축자로 can't be traded during rebasing 이라 적어 두었는데, 그 2건이 거래 가능한 live 와 한 목록에 섞여서 옵니다. 목록 길이를 세면 이 2건도 함께 세어집니다.

게이트 는 단위를 바꾸면 답이 뒤집히는 자리를 보여 줍니다. 거래쌍 창구에서 2,226쌍 가운데 tradable 이 2,224쌍으로 99.91퍼센트입니다. 그런데 같은 거래소의 코인 목록 창구를 부르면 5,482종 가운데 delisted 가 true 인 것이 2,295종으로 41.86퍼센트입니다. 거래쌍 단위로는 거의 전부 거래 가능이고, 코인 단위로는 열에 넷이 그 반대 칸에 있습니다. 어느 쪽도 틀리지 않았고 세는 단위가 다를 뿐입니다. 필드 정의는 공식 SDK 문서(1,934바이트, 12시 21분 17초 KST)에서 축자로 확인했습니다. untradable: cannot be traded - buyable: can be bought - sellable: can be sold - tradable: can be bought and sold 입니다. 네 값 중 buyable 과 sellable 은 0건이었습니다.

MEXC 는 상태 칸을 값 하나로만 채웁니다. 2,109건의 status 가 전부 문자열 1 이었습니다. 공식 문서(445,494바이트, 12시 22분 20초 KST)의 필드표는 이 칸을 축자로 status:1 - online, 2 - Pause, 3 - offline 이라 적어 두었으니, 응답은 전부 online 칸에 있는 셈입니다. 다만 같은 문서의 예시 응답에는 다른 표기가 들어 있습니다. 축자로 "status" : "ENABLED" 입니다. 필드표는 숫자 문자열, 예시는 영문 낱말, 실제 응답은 숫자 문자열입니다. 문서 안에서도 표기가 갈리므로 이 칸만 보고 자동화를 짜면 어느 쪽에 맞출지가 정해지지 않습니다. 참고로 같은 응답의 다른 칸은 갈립니다. isSpotTradingAllowed 가 false 인 것이 105건, st 가 true 인 것이 62건이었습니다.

쿠코인 은 enableTrading 이 1,000건 전부 true 였고, 대신 별도 필드 st 가 true 인 것이 37건이었습니다. 목록 길이가 정확히 1,000이라 잘린 것처럼 보이지만 잘렸다고 단정하지 않았습니다. 확인 절차는 뒤에 따로 적었습니다.

비트겟 은 1,283건 중 online 1,280건, halt 3건이었습니다. 상태 값의 정의는 공식 문서 「Get Symbol Info」에 그대로 적혀 있습니다. 13시 51분(KST) 에 https://www.bitget.com/api-doc/classic/spot/market/Get-Symbols 를 받으니 HTTP 200 에 41,445바이트였고, 이 노트가 부른 창구(GET /api/v2/spot/public/symbols)를 설명하는 문서였습니다. 응답 필드표의 축자는 offline: offline, gray: grey scale, online: normal, halt: suspend trading 입니다. 정의된 넷 가운데 gray 와 offline 은 이번 응답에 0건이었습니다.

이 문서는 한 번 헛짚었다가 다시 찾은 자리라 그 과정도 함께 적습니다. 주소에서 classic 한 조각을 빼고 부르면 HTTP 301 이 옵니다. 응답 머리글의 이동 목적지는 /api-doc/uta/intro 이고, 거기서 표가 들어 있지 않은 23,627바이트짜리 다른 문서가 200 으로 옵니다. 13시 53분(KST) 에 그대로 다시 대조한 결과입니다. 최종 상태 코드만 보면 문서를 받은 것처럼 보이지만 받은 것은 다른 페이지입니다. 200 이 왔다는 사실만으로 "그 문서에 없다"고 적으면 안 되는 자리이고, 이 노트가 앞에서 다룬 "응답이 정상으로 오는데 원하는 것이 빠져 있는" 자리와 같은 모양입니다.

폴로닉스 는 860건 중 NORMAL 820건, PAUSE 40건이었습니다. 공식 문서(124,840바이트, 12시 23분 42초 KST)는 축자로 state String NORMAL, PAUSE, POST_ONLY 라 적었고, 셋 중 POST_ONLY 는 0건이었습니다.

표 전체를 가로로 읽으면 한 줄이 남습니다. 아홉 창구 어디에서도 문서가 정의한 값이 응답에 전부 나오지는 않았습니다. 정의된 값이 여덟인 곳에서 셋이 나왔고, 일곱인 곳에서 셋이 나왔고, 다섯인 곳에서 둘이 나왔고, 넷인 곳에서는 많아야 셋이 나왔습니다.

거르는 칸을 잘못 고르면 2,287줄이 그대로 남습니다

여기가 실무에서 가장 조용히 틀리는 자리입니다. 바이낸스 응답에는 isSpotTradingAllowed 라는 불리언 칸이 있습니다. 이름만 보면 현물 거래가 되는 종목을 거르는 스위치처럼 보입니다. 같은 응답에서 실제로 세어 보면 그렇지 않습니다.

BREAK 2,327줄 가운데 isSpotTradingAllowed 가 true 인 것이 2,287줄이었습니다. BREAK 안에서 98.28%입니다. 곧 이 칸으로 거르면 40줄만 빠지고 2,287줄이 그대로 남습니다. TRADING 1,354줄은 전부 true 였으니, 이 칸은 거래 가능 여부를 가르는 스위치가 아니었습니다.

다행히 바이낸스는 거르는 파라미터를 따로 제공합니다. 앞에서 문서로 확인한 그 파라미터를 12시 28분 32초(KST) 에 직접 넣어 봤습니다.

셋을 더하면 1,354에 2,327을 더해 3,681이고, 무필터 응답 길이와 정확히 맞습니다. 문서가 적어 둔 동작이 그대로 재현됐습니다. 덤으로 응답 크기도 크게 줄었습니다. 17,513,382바이트에서 5,817,415바이트로, 무필터 대비 33.22%입니다. 거래 중인 종목만 필요하다면 17메가바이트를 통째로 받아 파싱할 이유가 없습니다.

이 숫자를 다시 재는 절차

이 노트의 숫자는 오늘 낮의 값입니다. 그대로 인용하지 마시고 직접 재시는 편이 정확합니다. 절차는 네 단계입니다.

1. 인증 없이 목록 창구를 한 번 부르고, 부른 시각과 응답 바이트를 먼저 적습니다. 시각을 안 적으면 나중에 그 숫자가 무엇이었는지 되짚을 수 없습니다.
2. 응답이 스스로 적어 둔 분류 필드 이름을 먼저 찾습니다. 이름이 창구마다 다릅니다. status 인 곳, state 인 곳, trade_status 인 곳, 불리언 enableTrading 인 곳이 다 있습니다. 필드를 정한 다음에야 셈이 시작됩니다.
3. 그 필드의 값별 개수를 세고, 값들의 합이 목록 길이와 맞는지 검산합니다. 안 맞으면 세는 방식이 어딘가 어긋난 것이니 여기부터 맞추시는 편이 좋습니다.
4. 같은 창구의 공식 문서에서 그 필드의 값 목록을 축자로 확인합니다. 정의된 값과 응답에 나온 값이 다른 것이 정상입니다. 이번에 아홉 창구가 전부 그랬습니다. 다만 문서에만 있는 값이 언제 응답에 나타날지 모른다는 전제로 코드를 짜야 합니다.

여기에 확인 절차를 하나 더 붙이겠습니다. 목록 길이가 딱 떨어지는 수면 잘린 것인지 먼저 확인해야 합니다. 쿠코인 목록이 정확히 1,000건이라 이 자리에 걸렸고, 12시 23분 17초부터 12시 23분 20초(KST) 사이에 네 경로로 다시 확인했습니다. 마켓 목록 창구가 마켓 23개를 알려 주기에 그 23개로 종목 창구를 23번 나눠 불렀고, 행 합계는 1,282인데 중복을 제거한 고유 심볼은 정확히 1,000이었습니다. 합집합에만 있고 무필터 응답에 없는 심볼이 0개, 그 반대도 0개였습니다. 구버전 종목 창구도 1,000, 전체 티커 창구도 1,000이었습니다. 네 경로가 전부 1,000이고 합집합도 1,000이라 잘림으로 단정하지 않았습니다. 이 노트는 "이 창구에서 받은 수는 1,000" 까지만 씁니다.

응답 시각을 적는 습관이 왜 필요한지는 거래소 서버 시각과 요청 타임스탬프 허용 창을 잰 노트에서 따로 정리했습니다.

이 조회의 한계와 확인하지 못한 것

• 무인증 공개 창구만 열었습니다. 계정 등급·지역 제한·본인확인 단계에 따라 실제로 주문이 들어가는지는 재지 않았습니다. 여기서 센 것은 응답에 적힌 상태 칸뿐입니다.
• 상태가 그 값이 된 사유는 확인하지 못했습니다. 응답에 사유 칸이 없고, 아홉 창구의 문서 어디에서도 개별 종목의 사유를 찾지 못했습니다. 29분 사이에 옮겨 간 일곱 줄도 원인 없이 관측만 적었습니다.
• 비트겟의 옛 문서 사이트는 이번 값 목록과 맞대지 못했습니다. 정식 문서에서는 네 값을 확인했지만, 옛 사이트(611,442바이트)에는 halt 문자열이 0건이었습니다. 그 사이트가 어느 시점의 판인지는 확인하지 않았습니다.
• END_OF_DAY 의 뜻은 훑은 일곱 파일에서 찾지 못했습니다. 저장소 전체와 중국어판, 웹 문서 사이트는 훑지 않았습니다.
• 현물 위주입니다. 선물은 바이비트만 함께 열었고, 나머지 여덟 창구의 선물 목록은 이번에 부르지 않았습니다.
• 국내 거래소는 한 곳도 열지 않았습니다.
• 값의 유효 기간이 짧습니다. 한 회선에서 한 번 받은 스냅샷이고, 이번 조회 안에서만도 29분에 일곱 줄이 움직였습니다.

지금 바로 해 볼 수 있는 다섯 단계 자가 점검

1. 지금 쓰시는 목록이 "응답 줄 수"입니까, "거래 가능한 종목 수"입니까. 두 값이 같은 창구는 이번 아홉 곳 중에도 있고 63.22%가 벌어지는 곳도 있었습니다. 목록 길이를 상장 종목 수로 쓰고 계셨다면 그 자리부터 갈라 놓으시는 것이 첫 단계입니다.
2. 거르는 칸의 이름이 아니라 그 칸의 값 분포를 세어 보셨습니까. 이름이 그럴듯한 칸이 실제로는 거의 아무것도 거르지 않는 경우가 있습니다. 이번에 isSpotTradingAllowed 로 거르니 3,681줄 중 3,641줄이 남았습니다. 거르기 전후 개수를 찍어 보면 30초면 드러납니다.
3. 창구가 제공하는 상태 필터 파라미터를 찾아보셨습니까. 바이낸스는 symbolStatus, 바이비트는 status 로 걸러집니다. 걸러서 받으면 응답 크기도 함께 줄어듭니다.
4. 기본 응답이 전부라고 가정하고 계십니까. 바이비트 선물은 기본 호출에서 Closed 945건과 PreLaunch 4건이 안 나옵니다. 파라미터를 넣어 다시 부르기 전에는 그 949건이 있는지조차 알 수 없습니다.
5. 목록을 언제 받았는지 기록하고 계십니까. 어제 받아 둔 목록으로 오늘 고르면 그 사이 상태가 바뀐 줄을 밟습니다. 이번 조회에서 29분에 일곱 줄이 움직였습니다.

FAQ

Q: 바이낸스 상장 코인 개수는 결국 몇 개인가요? A: 무엇을 세느냐에 따라 세 가지 답이 나옵니다. 2026년 8월 21일 12시 20분 17초(KST) 응답 기준으로, 거래쌍 줄 수는 3,681, 그중 status 가 TRADING 인 줄은 1,354, 서로 다른 기초자산 종류는 806종이고 그중 TRADING 쌍을 하나라도 가진 것은 485종입니다. 인용하실 때 어느 값인지 밝히지 않으면 세 배 넘게 어긋납니다.

Q: BREAK 상태면 그 종목은 없어진 건가요? A: 그렇게 읽으시면 안 됩니다. 바이낸스 공식 용어집은 BREAK 를 축자로 not available for trading, which can happen during expected downtime 이라고만 적어 두었습니다. 거래할 수 없는 상태라는 것까지가 문서가 밝힌 전부이고, 사유도 해제 시점도 적혀 있지 않습니다. 이 노트도 상태 칸에 그렇게 적혀 있다는 사실만 셌습니다.

Q: 응답 줄 수를 그대로 쓰면 왜 위험한가요? A: 오류가 나지 않기 때문입니다. BREAK 줄도 키 구성이 TRADING 줄과 같고 filters 배열까지 들어 있어서, 파싱하는 쪽에서는 정상 종목과 구분되지 않습니다. 이번 응답에서 BREAK 는 3,681줄 중 2,327줄이고 63.22퍼센트였습니다.

Q: 거래 가능한 종목만 받으려면 어떻게 하나요? A: 창구가 필터를 제공하면 그것을 쓰시는 편이 가장 확실합니다. 바이낸스는 종목 정보 창구에 symbolStatus 를 붙일 수 있고, TRADING 으로 넣으니 1,354건이 왔습니다. 응답 크기도 17,513,382바이트에서 5,817,415바이트로 줄었습니다. 바이비트 선물은 반대로 기본이 이미 Trading 만 주므로, 빠진 것을 보시려면 status=Closed 를 넣어 다시 부르셔야 합니다.

Q: 창구마다 숫자가 갈리는데 어느 쪽이 맞나요? A: 어느 쪽도 틀리지 않았습니다. 목록에 남겨 두고 상태 칸으로 구분하는 방식과, 기본 응답에서 빼는 방식과, 상태 칸을 값 하나로 채우는 방식이 섞여 있을 뿐입니다. 그래서 두 거래소의 숫자를 나란히 놓기 전에 각각 어느 필드로 센 값인지를 먼저 맞추셔야 합니다.

Q: 같은 거래소인데 코인 수와 거래쌍 수가 왜 그렇게 다른가요? A: 세는 단위가 다르기 때문입니다. 게이트가 선명한 사례입니다. 거래쌍 창구에서는 2,226쌍 중 2,224쌍이 tradable 로 99.91%인데, 코인 목록 창구에서는 5,482종 중 2,295종이 delisted 가 true 로 41.86%였습니다. 같은 시각, 같은 거래소, 다른 단위입니다.

Q: 이 숫자들은 얼마나 오래 쓸 수 있나요? A: 오래 못 씁니다. 같은 주소를 29분 간격으로 부르니 목록 길이는 3,681로 그대로였는데 일곱 줄의 상태가 TRADING 에서 BREAK 로 옮겨 갔습니다. 반대로 34초 간격의 두 호출은 심볼 단위로 완전히 같았습니다. 그래서 이 노트는 절마다 호출 시각과 요청 주소를 함께 적었습니다. 직접 다시 부르셔서 그날의 값을 세시는 편이 정확합니다.

함께 보면 좋은 글

• 거래 중인 기초자산 485종을 공개 ID 맵에 맞대 본 노트: 이 글이 센 것과 같은 exchangeInfo 응답을 하루 전에 받아, 485종이 두 ID 맵의 티커 공간에서 어디까지 겹치는지를 셌습니다.
• 코인 거래소 API 호출 제한을 잰 노트: 공개 창구를 인증 없이 부를 때 응답 머리글이 무엇을 알려 주고 무엇을 알려 주지 않는지를 정리했습니다.
• 코인 과거 시세 데이터 소급 한계를 잰 노트: 응답이 정상으로 오는데도 원하는 구간이 조용히 빠져 있는 자리를 다룹니다.
• 무기한 계약 최소 주문 금액을 잰 노트: 같은 종목 목록 응답 안에서 주문 제약이 어떤 필드로 오는지 정리했습니다.

데이터·개념 출처

본 노트의 수치는 2026년 8월 21일에 직접 호출해 받은 응답을 읽은 것입니다. 아홉 창구의 종목 목록은 전부 12시 20분 17초부터 12시 20분 20초(KST) 사이에 받았고, 바이낸스 재측정은 12시 20분 51초, 쿠코인 보강 조회는 12시 23분 17초부터 12시 23분 20초, 바이낸스 필터 파라미터 실행은 12시 28분 32초입니다. 드리프트 대조에 쓴 앞선 회차 측정은 같은 날 11시 51분 25초(KST) 응답(17,513,402바이트)입니다. 전부 인증 헤더 없이 부른 공개 호출입니다.

부른 주소를 그대로 적습니다. 바이낸스 현물은 https://api.binance.com/api/v3/exchangeInfo, 바이비트는 https://api.bybit.com/v5/market/instruments-info(category 와 status 파라미터를 바꿔 여덟 번), OKX 는 https://www.okx.com/api/v5/public/instruments(instType SPOT·SWAP), 게이트는 https://api.gateio.ws/api/v4/spot/currency_pairs 와 https://api.gateio.ws/api/v4/spot/currencies, HTX 는 https://api.huobi.pro/v2/settings/common/symbols, MEXC 는 https://api.mexc.com/api/v3/exchangeInfo, 비트겟은 https://api.bitget.com/api/v2/spot/public/symbols, 쿠코인은 https://api.kucoin.com/api/v2/symbols(및 v1 종목·마켓·전체 티커 창구), 폴로닉스는 https://api.poloniex.com/markets 입니다.

문서 문구는 같은 날 직접 받아 축자로 확인했습니다. 바이낸스는 공식 저장소의 enums.md(5,244바이트), faqs/spot_glossary.md(15,846바이트), rest-api.md(181,189바이트), CHANGELOG.md(132,483바이트)를 받았고, END_OF_DAY 등장 횟수는 여기에 filters.md·errors.md·web-socket-api.md 를 더한 일곱 파일에서 세었습니다. 바이비트는 종목 창구 문서(223,087바이트)와 열거값 문서(90,347바이트), OKX 는 문서 사이트(5,242,376바이트), 게이트는 공식 SDK 저장소의 CurrencyPair.md(1,934바이트), HTX 는 문서 사이트(830,811바이트), MEXC 는 문서 사이트(445,494바이트), 폴로닉스는 문서 사이트(124,840바이트)입니다. 비트겟은 정식 경로 https://www.bitget.com/api-doc/classic/spot/market/Get-Symbols(41,445바이트)를 13시 51분(KST) 에 받아 상태 값 넷을 축자로 확인했고, 같은 주소에서 classic 을 뺐을 때 301 로 옮겨 가는 자리는 13시 53분(KST) 에 대조했습니다.

이 글은 공개 API 응답과 개발자 문서를 정리한 정보 제공 목적의 자료이며 특정 종목이나 거래소의 이용을 권하는 글이 아닙니다. 본 노트는 진입가나 정리 가격을 제시하지 않고, 어떤 자산도 매수 또는 매도 대상으로 지목하지 않으며, 어느 창구가 더 정확하다는 판단도 하지 않습니다. 본문에 나온 종목 코드는 전부 상태 칸이 어떻게 적혀 있는지를 보이기 위한 것입니다. 가상자산은 원금 손실이 발생할 수 있습니다. 위 개수와 비율은 특정 시각에 특정 회선에서 받은 한 번의 스냅샷이라 다시 부르시면 달라지고, 각 창구가 언제든 수록 기준을 바꿀 수 있어 이후에도 같은 값인지는 이 글에서 확인하지 않았습니다. 투자 판단과 그 결과는 전적으로 본인 책임입니다.