바이낸스 Exchange Info 뜻 2026｜거래 규칙·심볼 정보·권한·필터 읽는 법

바이낸스 Exchange Info 뜻 2026｜거래 규칙·심볼 정보·권한·필터 읽는 법

바이낸스 Exchange Info는 현재 거래 규칙과 거래쌍 정보를 조회하는 현물 API 자료입니다. 가격 차트나 내 주문 이력을 보여주는 기능과 목적이 다릅니다. 자동 주문을 만들기 전에 어떤 거래쌍인지, 어떤 주문 종류를 지원하는지, 가격과 수량에 어떤 조건이 있는지 확인하는 출발점으로 이해하면 쉽습니다.

거래쌍이 TRADING 상태라는 사실만으로 주문의 모든 조건이 충족되는 것은 아닙니다. 같은 현물 시장에서도 수량 단위와 최소 주문 금액이 다를 수 있고, 계정 권한과 지원 기능도 구분해야 합니다. Exchange Info를 읽는 이유는 이런 조건을 한꺼번에 추측하는 대신 실제 응답에서 항목별로 확인하기 위해서입니다.

이 글은 2026년 10월 28일 확인한 Binance Spot 공식 개발 문서를 기준으로 합니다. 설명의 대상은 GET /api/v3/exchangeInfo이며 선물·옵션의 비슷한 이름을 가진 경로까지 같은 규칙으로 적용하지 않습니다. 숫자 예시는 이해를 위한 가정이며 특정 거래쌍의 현재 주문 조건을 대신하지 않습니다.

1. Exchange Info가 답하는 질문

Exchange Info는 시장의 메타데이터를 제공합니다. 여기서 메타데이터란 가격 자체보다 가격과 주문을 어떻게 해석할지 알려주는 정보를 뜻합니다. symbol, baseAsset, quoteAsset, orderTypes, filters 같은 항목이 이 범주에 속합니다. 실제 매수 주문을 보내는 기능은 아니며 조회만으로 계정의 자산이 바뀌지 않습니다.

예를 들어 어떤 프로그램에 코인 이름과 수량만 입력했다고 가정해 보겠습니다. 그 코인이 어떤 자산으로 가격이 표시되는지, 수량 소수점을 어디까지 사용할 수 있는지, 시장가 주문을 지원하는지 모르면 요청을 제대로 구성하기 어렵습니다. Exchange Info는 이런 판단에 필요한 자료를 제공하지만 최종 주문 성공을 보증하지는 않습니다.

시세 정보와의 차이

가격을 알고 싶다면 목적에 맞는 시세·호가·체결 자료를 봐야 합니다. Exchange Info에서 거래 규칙을 읽었다고 현재 최우선 매도호가를 알 수 있는 것은 아닙니다. 반대로 가격 API를 조회했다고 주문 수량의 stepSize나 최소 주문 금액을 모두 알 수 있는 것도 아닙니다.

실무에서는 규칙 자료와 시장 자료를 나누어 관리하는 편이 이해하기 쉽습니다. 규칙은 주문이 형식과 조건에 맞는지 판단하는 데 쓰고, 시장 자료는 현재 가격·유동성·체결 상황을 이해하는 데 씁니다. 둘을 결합하더라도 각각의 갱신 시각과 출처는 보존해야 합니다.

계정 정보와의 차이

이 경로가 제공하는 심볼 정보는 내 계정의 가용 잔고나 실제 거래 권한을 모두 보여주는 자료가 아닙니다. 심볼이 어떤 권한 집합을 요구하는지와 내 계정이 그 요구를 충족하는지는 다른 질문입니다. 계정과 API 키에 필요한 권한이 있는지는 해당 계정 자료와 설정에서 추가로 확인해야 합니다.

“목록에 심볼이 있으니 누구나 거래할 수 있다”는 설명은 잘못된 확대 해석입니다. 지역·계정·상품별 접근 조건이 다를 수 있고 요청 시점의 잔고나 주문 제한도 별도로 작용합니다. 공개 거래 규칙을 사용자별 이용 가능성의 최종 증명으로 삼지 마세요.

2. 공식 조회 경로와 확인 순서

Binance Spot REST API 공식 문서는 GET /api/v3/exchangeInfo를 현재 거래 규칙과 심볼 정보 조회 경로로 설명합니다. 작성 시점 문서의 요청 가중치는 20이며 데이터 출처는 Memory로 안내되어 있습니다. 이 수치는 영구 고정값으로 코드에 방치할 정보가 아니라 문서 변경 때 다시 확인할 항목입니다.

먼저 대상이 Spot인지 확인하고 정확한 경로를 선택합니다. 다음으로 전체 목록이 필요한지, 특정 심볼 하나가 필요한지, 몇 개의 심볼이 필요한지 결정합니다. 목적 없이 모든 조건을 동시에 넣는 것보다 필요한 반환 범위를 먼저 정하는 편이 오류를 줄입니다.

공식 문서는 이 경로의 모든 파라미터가 선택 사항이라고 설명합니다. 그러나 선택 사항이라는 말은 어떤 조합으로 넣어도 된다는 뜻이 아닙니다. symbol, symbols, permissions, symbolStatus 사이에는 조합 제약이 있으므로 각 항목의 의미를 함께 읽어야 합니다.

symbol과 symbols

symbol은 특정 거래쌍을 지정할 때 사용합니다. symbols는 여러 거래쌍을 대상으로 하는 배열 형태의 요청에 사용됩니다. 문자열 목록을 직렬화하는 방식은 사용하는 클라이언트에 따라 달라질 수 있으므로 실제 전달되는 쿼리 값이 공식 형식과 맞는지 확인해야 합니다.

코인 이름을 symbol이라고 생각하면 혼동하기 쉽습니다. BTC라는 자산과 BTCUSDT라는 거래쌍은 같은 단위의 이름이 아닙니다. 거래쌍은 기준 자산과 표시 자산을 함께 나타내며, 자산 하나에 여러 거래쌍이 있을 수 있습니다. 특정 예시 심볼이 현재 모든 계정에서 지원된다는 뜻으로 읽지 않습니다.

문서에서는 존재하지 않는 symbol 또는 symbols 값을 전달하면 유효하지 않은 심볼이라는 오류가 발생한다고 안내합니다. 요청이 실패했다면 먼저 정확한 심볼 문자열과 제품을 확인하세요. 오류 하나를 보고 거래소 전체 장애나 자산 상장폐지로 바로 결론 내리지 않습니다.

permissions 필터

permissions는 반환할 심볼의 권한 범위를 지정하는 조회 조건입니다. 단일 값과 여러 값을 지원하지만 symbol 또는 symbols와 함께 사용할 수 없다고 공식 문서에 명시되어 있습니다. 이 제약은 파라미터를 많이 넣으면 더 정밀해질 것이라는 직관이 항상 맞지 않음을 보여줍니다.

현재 문서는 permissions를 주지 않으면 SPOT, MARGIN, LEVERAGED 중 하나의 권한을 가진 심볼이 노출된다고 설명합니다. 따라서 기본 응답을 어떤 조건도 없는 절대적인 모든 심볼 목록이라고 부르지 않는 편이 정확합니다. 다른 권한 범위를 확인하려면 공식 목록과 필터 설명을 따라야 합니다.

symbolStatus와 showPermissionSets

symbolStatus는 거래 상태에 따라 심볼을 필터링하는 조건입니다. 이 역시 symbol 또는 symbols와 조합할 수 없다고 안내됩니다. 상태별 목록을 원하는 요청과 특정 심볼의 현재 상태를 원하는 요청을 구분하면 어떤 조건을 선택해야 하는지 명확해집니다.

showPermissionSets는 응답의 permissionSets 내용을 채울지 제어하는 옵션이며 현재 문서의 기본값은 true입니다. 이 값을 false로 설정했다고 계정의 권한 검사가 해제되는 것은 아닙니다. 반환 자료의 표시 범위와 실제 거래 권한은 별개라는 점을 기억해야 합니다.

3. 응답을 위에서 아래로 읽는 방법

응답에는 최상위 수준의 정보와 symbols 배열 안의 개별 심볼 정보가 함께 존재합니다. 모든 필드를 같은 수준으로 평평하게 저장하면 어느 규칙이 전체에 관한 것인지 특정 심볼에 관한 것인지 잃기 쉽습니다. 원본 구조를 이해한 뒤 목적에 맞는 내부 구조로 옮기는 것이 좋습니다.

rateLimits는 제한 종류와 기간, 한도 등을 설명하는 자료입니다. REQUEST_WEIGHT와 ORDERS처럼 서로 다른 제한을 같은 카운터로 합치지 않아야 합니다. 응답 예시에 나온 숫자를 모든 시점의 실제 한도로 복사하는 대신 현재 응답과 관련 공식 제한 문서를 확인해야 합니다.

exchangeFilters와 개별 심볼의 filters도 위치가 다릅니다. 공식 Filters 문서는 심볼 필터, 거래소 필터, 자산 필터를 구분합니다. 필터 이름만 보는 것이 아니라 어떤 대상에 적용되는지 확인하는 이유입니다.

symbol·baseAsset·quoteAsset

symbol은 거래쌍의 식별 이름입니다. baseAsset은 수량의 중심이 되는 자산, quoteAsset은 가격을 표시하는 자산으로 이해할 수 있습니다. 가격과 수량을 곱한 값의 단위를 확인할 때 이 구분이 필요합니다. 예를 들어 가격이 quote/base 단위이고 수량이 base 단위라면 곱한 금액은 quote 단위가 됩니다.

USDT 거래쌍 예시만 보다가 BTC로 가격을 표시하는 거래쌍에 같은 숫자를 적용하면 금액 해석이 달라질 수 있습니다. minNotional이라는 필드의 숫자를 읽을 때도 quoteAsset을 함께 보아야 합니다. 숫자 크기만 보고 원화나 달러라고 가정하지 않습니다.

status와 주문 상태 분리

symbols 안의 status는 해당 심볼의 거래 상태입니다. 개별 주문이 NEW인지 FILLED인지 알려주는 값이 아닙니다. 프로그램 내부에서 둘 다 status라는 이름을 사용하더라도 저장 위치와 의미를 분리해야 합니다.

TRADING이라는 상태는 다른 검사를 생략할 근거가 되지 않습니다. 반대로 심볼 상태가 제한됐다고 이전에 체결된 주문이 자동으로 사라지는 것도 아닙니다. 시장의 현재 상태와 계정에 남은 주문·체결 이력을 각각 확인하는 구조가 필요합니다.

4. 정밀도와 주문 단위를 혼동하지 않기

응답에는 baseAssetPrecision, quoteAssetPrecision, 수수료 관련 precision처럼 여러 정밀도 필드가 있습니다. 이런 필드가 보인다고 그것만으로 주문 가격의 tickSize나 주문 수량의 stepSize를 계산해서는 안 됩니다. 표현 정밀도와 실제 주문 허용 간격은 다른 개념입니다.

예를 들어 소수점 여덟 자리로 값을 표현할 수 있는 자산이라도 해당 거래쌍의 주문 수량 간격이 더 클 수 있습니다. 소수점 자릿수를 맞췄는데 주문이 거절되는 이유가 여기에 있을 수 있습니다. 실제 수량 조건은 LOT_SIZE 등 적용되는 필터에서 읽어야 합니다.

가격 단위는 PRICE_FILTER 확인

PRICE_FILTER에는 minPrice, maxPrice, tickSize가 설명되어 있습니다. 공식 문서는 각 값이 0이면 해당 가격 규칙이 비활성화될 수 있다고 안내합니다. 이 설명을 다른 필터의 모든 0 값에 무조건 적용하면 안 됩니다. 필터마다 규칙이 다르므로 항목별 문서를 읽어야 합니다.

가격의 소수점 자릿수가 맞더라도 tickSize의 배수 조건을 만족하지 않을 수 있습니다. 반대로 표시 형식의 뒤쪽 0 개수만 보고 주문이 유효하지 않다고 판단하는 것도 적절하지 않습니다. 수치의 의미와 문자열 표시를 분리해서 검증합니다.

수량 단위는 LOT_SIZE 등 확인

LOT_SIZE는 최소·최대 수량과 stepSize를 다룹니다. 시장가에는 MARKET_LOT_SIZE처럼 별도 필터가 관련될 수 있으므로 주문 종류에 적용되는 현재 규칙을 확인해야 합니다. 하나의 필터를 통과했다고 다른 필터도 자동으로 통과하는 구조로 만들지 않습니다.

수량을 허용 단위에 맞추는 과정에서 주문 금액이 달라질 수 있습니다. 특히 최소 금액 부근에서는 수량을 내린 뒤 가격과 곱하면 하한을 벗어날 수 있습니다. 따라서 수량 조정 후 금액 검사를 다시 수행해야 합니다. 필터 검증은 독립된 항목들을 일관되게 조합하는 과정입니다.

5. permissionSets를 읽는 핵심

permissionSets는 배열 안에 배열이 있는 구조입니다. 공식 문서는 한 내부 배열에 A와 B가 있으면 A 또는 B 중 하나를 가진 계정이 조건을 충족하는 예시를 보여줍니다. 내부 배열이 따로 나뉘면 각 집합의 조건을 모두 충족해야 하는 방식으로 설명합니다.

개념적으로 [[A, B]]는 A 또는 B이며, [[A], [B]]는 A와 B입니다. [[A], [B, C]]는 A를 만족하면서 B 또는 C 중 하나를 만족하는 형태로 이해할 수 있습니다. 여기서 A·B·C는 논리를 설명하기 위한 기호입니다. 실제 응답의 권한 이름과 적용 조건을 확인해야 합니다.

OR와 AND를 평평하게 합치면 생기는 문제

모든 권한을 하나의 목록으로 펼친 뒤 그중 하나만 맞으면 허용하는 구현은 원래 조건을 약하게 바꿀 수 있습니다. 반대로 목록의 모든 권한이 필요하다고 처리하면 원래 허용되는 사용자를 잘못 거절할 수 있습니다. 배열 경계가 의미를 가진다는 점이 핵심입니다.

이 자료를 해석하는 것은 거래 권한을 새로 부여하는 행위가 아닙니다. 실제 계정·키의 권한 상태와 결합해 사전 점검에 활용하는 것입니다. 계정 정보가 없거나 최신인지 알 수 없을 때는 권한 충족 여부를 확정값으로 표시하지 않는 편이 정확합니다.

기존 permissions 필드와의 관계

문서의 응답 예시에 permissions가 빈 배열이고 permissionSets에 내용이 들어 있는 경우가 있습니다. 따라서 예전 구현이 단일 필드만 읽고 있다면 현재 응답 구조와 맞는지 점검할 필요가 있습니다. 빈 배열 하나를 보고 해당 심볼에 어떠한 권한 조건도 없다고 결론 내리면 안 됩니다.

변경 대응에서는 필드를 무작정 대체하기보다 공식 문서와 실제 사용하는 라이브러리 버전을 함께 확인해야 합니다. 캐시에 과거 형식의 자료가 남아 있다면 새 파서와 섞여 결과가 달라질 수도 있습니다. 데이터 형식 변경과 거래 규칙 변경을 구분해 기록하면 진단이 쉬워집니다.

6. orderTypes와 기능 허용 필드

orderTypes는 해당 심볼에서 지원하는 주문 종류를 읽는 항목입니다. LIMIT, MARKET 등의 이름을 확인하더라도 주문 종류별 필수 파라미터와 조건은 별도 문서를 따라야 합니다. 종류가 목록에 있다는 사실이 어떤 조합의 파라미터도 허용된다는 뜻은 아닙니다.

icebergAllowed, ocoAllowed, quoteOrderQtyMarketAllowed, allowTrailingStop 같은 허용 필드도 공식 응답 예시에 있습니다. 현재 사용하는 기능의 필드를 정확하게 읽어야 하며 비슷한 이름의 다른 기능에 적용하지 않습니다. 예를 들어 금액 기준 시장가 허용 여부와 모든 주문에서 금액 입력을 허용하는지는 다른 문제입니다.

기능 하나의 허용을 전체 조합으로 넓히지 않기

OCO와 같은 주문 목록 기능에는 개별 주문의 규칙 외에 목록 자체의 구성 조건이 있습니다. 기능 허용 필드가 true여도 가격 관계, 주문 종류 조합, 주문 수 제한 등을 추가 확인해야 할 수 있습니다. 최종 요청 문서와 실제 응답을 확인하는 단계가 남습니다.

Cancel Replace나 수량 수정 기능도 각각 지원 여부와 처리 규칙이 다릅니다. 이름에 모두 수정 의미가 있다고 하나의 boolean으로 합치면 실제 동작의 차이가 사라집니다. 기존 주문의 유지, 취소, 새 주문 생성, 우선순위에 관한 의미를 해당 기능별로 구분해야 합니다.

UI 기능과 API 지원을 동일하게 보지 않기

API 응답에서 기능을 지원한다고 현재 앱의 특정 화면에 동일한 메뉴가 반드시 있다는 뜻은 아닙니다. 앱 버전·제품·계정별 표시가 다를 수 있습니다. API 설명 글에서 확인하지 않은 버튼 위치나 메뉴 경로를 만들어 넣지 않아야 합니다.

외부 거래 도구를 이용한다면 그 도구가 해당 API 기능을 실제로 구현했는지도 확인해야 합니다. 거래소가 지원하는 것과 도구가 제공하는 것은 별개의 조건입니다. 문제가 생겼을 때는 거래소 응답과 도구의 요청 구성, 표시 방식을 나누어 살펴보세요.

7. 주문 전 점검 절차

1단계: 제품·환경·심볼 확정

현물인지 선물인지, 운영 환경인지 테스트 환경인지부터 구분합니다. 같은 이름의 자산이라도 다른 제품의 규칙은 다를 수 있습니다. 요청 주소와 반환된 심볼을 기록해 잘못된 환경의 메타데이터를 재사용하지 않도록 합니다.

거래쌍은 사용자의 입력을 그대로 믿기보다 실제 응답에서 확인한 값으로 연결하는 것이 좋습니다. 검색용 별칭과 API symbol은 다를 수 있습니다. 단순 문자열 이어붙이기로 심볼을 만드는 방식은 자산 이름의 길이나 표기 변화에 취약할 수 있으므로 현재 목록을 기준으로 확인합니다.

2단계: 요청 목적에 맞는 반환 범위 선택

특정 심볼 하나의 규칙이 필요하다면 전체 목록을 계속 조회할 이유가 없는지 검토합니다. 반대로 여러 심볼을 관리한다면 중복 조회를 줄일 수 있는 구조를 생각할 수 있습니다. 이것은 효율성 설계이며 어떤 주기가 모든 사용자에게 정답이라는 뜻은 아닙니다.

필터를 사용했다면 그 조건을 응답과 함께 저장합니다. 나중에 특정 심볼이 목록에 없다고 느낄 때, 당시 어떤 조건으로 조회했는지 알 수 있어야 합니다. 반환된 목록만 보관하면 권한·상태 필터로 빠진 것인지 실제 대상이 달라진 것인지 구분하기 어렵습니다.

3단계: 필터를 종류별로 해석

filters 배열을 순서로 읽기보다 filterType을 기준으로 찾아야 합니다. 첫 번째가 항상 가격 필터라는 가정은 응답 구조의 의미를 잘못 사용한 것입니다. 필요한 필터가 없거나 알 수 없는 종류가 등장했을 때의 처리 정책도 명확히 해야 합니다.

모든 심볼에 모든 필터가 있다고 가정하지 않습니다. 공식 예시는 구조를 설명하기 위한 것이며 실제 반환 내용은 달라질 수 있습니다. 필요한 검증을 할 수 없는 상황이면 임의 기본값으로 주문을 정상 처리하기보다 확인 필요 상태로 분류하는 것이 좋습니다.

4단계: 계정 조건과 현재 시장 자료 결합

메타데이터를 읽은 뒤에는 잔고·계정 권한·현재 가격 등 요청에 필요한 자료를 결합합니다. 서로 다른 시점에 조회한 값이라면 그 차이를 고려해야 합니다. 최신 규칙과 오래된 잔고를 조합했다고 전체 판단이 최신이 되는 것은 아닙니다.

사전 점검이 통과되어도 실제 요청을 전송하는 사이에 조건이 달라질 수 있습니다. 따라서 최종 응답을 읽고 주문 상태를 추적해야 합니다. Exchange Info 기반 검증은 불필요한 오류를 줄이는 도구이며 서버의 최종 판단을 대체하는 계약이 아닙니다.

5단계: 오류 이후 해당 조건 재확인

필터 오류가 발생하면 요청값과 사용한 규칙의 조회 시각을 먼저 확인합니다. 캐시가 오래됐는지, 다른 심볼의 필터를 사용했는지, 문자열을 숫자로 변환하는 과정에서 값이 달라졌는지 분리해 살펴봅니다. 모든 오류에 전체 조회와 즉시 재주문을 반복하는 대응은 적절하지 않습니다.

특히 응답이 유실되어 주문 결과가 불명확한 경우에는 단순 필터 오류와 다르게 처리해야 합니다. 규칙을 새로 읽었다는 이유만으로 원래 주문이 미접수였다고 판단할 수 없습니다. 원래 주문 식별자와 상태를 확인한 뒤 재시도 여부를 결정해야 합니다.

8. 다섯 가지 상황별 예시

예시 1. 소수점 자릿수는 맞는데 수량 오류

가상의 심볼이 소수점 여덟 자리 표현을 지원하지만 수량 stepSize가 0.01이라고 가정합니다. 0.015라는 수량은 표현 자체는 가능해 보여도 0.01 간격에는 맞지 않습니다. precision 값만 보고 주문을 허용한 로직이라면 이 차이를 놓칠 수 있습니다.

이 경우 확인할 대상은 수량 필터입니다. 필요한 자릿수로 출력하는 작업과 허용 배수인지 검사하는 작업을 구분합니다. 수량을 조정했다면 주문 금액과 잔고도 다시 확인해야 합니다. 조정 방향은 사용자의 거래 의사와 관련되므로 프로그램이 임의로 더 큰 금액을 주문하도록 만들지 않습니다.

예시 2. 기본 목록에서 원하는 심볼을 못 찾음

전체 목록이라고 생각한 응답에서 특정 심볼을 찾지 못했다고 가정합니다. 현재 문서는 permissions를 생략했을 때의 반환 범위를 설명하고 있으므로 먼저 요청 조건을 확인해야 합니다. 목록의 부재만으로 자산이 삭제됐다고 확정할 수 없습니다.

대상 제품과 정확한 심볼, 권한 필터, 상태 필터를 순서대로 확인합니다. 필요한 경우 공식 공지와 현재 문서를 대조합니다. 검색 결과가 없다는 관측과 그 이유에 대한 결론을 구분해서 기록하면 잘못된 알림을 줄일 수 있습니다.

예시 3. 여러 조건을 함께 넣어 조회 실패

특정 symbol을 지정하면서 permissions나 symbolStatus도 추가했다고 가정합니다. 조건을 더 넣었으니 더 정확한 조회라고 생각할 수 있지만 공식 문서에 조합 불가 조건이 있습니다. 이 경우는 서버 부하보다 요청 구성부터 확인해야 합니다.

질문을 하나로 정리하세요. 특정 심볼의 정보를 원하는지, 특정 상태의 목록을 원하는지, 특정 권한 범위의 목록을 원하는지에 따라 요청을 나눕니다. 오류가 사라질 때까지 파라미터를 무작위로 삭제하는 대신 각 조건의 의미를 이해하는 편이 이후 유지보수에도 도움이 됩니다.

예시 4. 권한 집합을 잘못 평탄화

[[A], [B, C]] 구조를 A 또는 B 또는 C로 해석한 프로그램을 생각해 볼 수 있습니다. 실제 의도는 A를 만족하고 동시에 B 또는 C를 만족하는 형태입니다. 배열 경계를 없애면 원래 조건보다 느슨한 사전 판단을 하게 됩니다.

테스트에서는 A만 있는 경우, B만 있는 경우, A와 B가 있는 경우, A와 C가 있는 경우를 따로 검토할 수 있습니다. 이런 기호 테스트는 권한을 조작하는 작업이 아니라 논리 해석을 검증하는 방법입니다. 실제 주문 가능 여부는 현재 계정과 서버의 판단으로 확인합니다.

예시 5. 어제 규칙으로 오늘 주문을 구성

프로그램이 어제 저장한 필터를 계속 사용하고 오늘 발생한 오류를 일시적 장애라고 처리한다고 가정합니다. 규칙이나 지원 조건이 바뀌었을 가능성도 진단 대상에 포함해야 합니다. 영구 캐시는 조회 비용을 줄여도 현재 조건을 놓칠 수 있습니다.

마지막 갱신 시각과 실패 이유를 기록하고 필요한 조건에서 재조회합니다. 새 자료를 받으면 기존 자료와 차이를 비교하되 변경된 항목이 실제로 어떤 판단에 영향을 주는지 확인해야 합니다. 캐시를 갱신했다는 사실과 과거 주문 결과가 확인됐다는 사실은 별도로 관리합니다.

9. 캐시와 갱신 정책

Exchange Info를 매 주문마다 전체 조회하면 호출 예산을 불필요하게 소모할 수 있습니다. 반대로 실행 시작 시 한 번만 읽고 계속 쓰면 변경을 놓칠 수 있습니다. 두 극단 사이에서 관리하는 심볼 수, 호출 예산, 오류 대응, 변경 감지 요구를 고려한 정책이 필요합니다.

최소한 원본 출처, 조회 시각, 요청 조건, 파싱 성공 여부를 함께 저장하면 좋습니다. 단순히 마지막 성공 데이터만 덮어쓰면 갱신 실패를 알기 어렵습니다. 화면이나 로그에서도 현재 확인한 값과 과거 마지막 확인값을 구분해야 합니다.

실패한 응답으로 정상 캐시를 덮어쓰지 않기

네트워크 오류나 예상하지 못한 형식의 응답을 빈 심볼 목록으로 처리하면 실제로 시장이 모두 사라진 것처럼 보일 수 있습니다. 조회 실패와 정상 빈 결과를 분리하는 것이 중요합니다. 기존 자료를 보존하더라도 오래된 자료라는 표시를 유지해야 합니다.

캐시 교체는 필요한 구조 검증이 끝난 뒤 한 번에 적용하는 방식으로 설계할 수 있습니다. 일부 심볼만 새 버전이고 나머지는 이전 버전인 상태가 의도된 것인지도 판단해야 합니다. 이런 구현 선택은 사용자 시스템의 요구에 따라 달라지며 공식 서버의 보장사항으로 표현하지 않습니다.

재시작과 환경 변경

운영 환경을 바꾸거나 라이브러리를 업데이트한 뒤에는 저장된 메타데이터가 새 환경에도 적합한지 확인해야 합니다. 테스트 환경의 규칙을 운영에 가져오거나 반대로 운영의 과거 캐시를 테스트 결과처럼 사용하는 실수를 피해야 합니다.

캐시 파일에 버전과 환경 이름을 넣는 것은 이런 혼동을 줄이는 방법입니다. 다만 파일 이름만 믿지 말고 실제 요청 주소와 응답 출처도 기록해야 합니다. 자료가 어디서 왔는지 알 수 없으면 최신 여부뿐 아니라 적용 대상 자체를 판단하기 어렵습니다.

10. 필터 검증을 설계할 때 놓치기 쉬운 부분

가격·수량 필터를 통과한 뒤 최소 금액을 확인하는 순서는 유용하지만, 각 단계를 거치며 값이 바뀐다면 앞 단계도 영향을 받을 수 있습니다. 가격을 조정하면 금액이 달라지고 수량을 조정하면 잔고 사용량이 달라집니다. 최종 요청값으로 전체 조건을 다시 확인하는 과정이 필요합니다.

필터 오류를 피하기 위해 값을 자동으로 크게 바꾸는 것은 단순한 형식 보정이 아닐 수 있습니다. 주문 금액과 위험이 달라지기 때문입니다. 사용자에게 어떤 값이 어떤 이유로 조정되는지 알 수 있게 하고, 승인된 거래 범위 안에서만 처리해야 합니다.

정확한 소수 계산

가격과 수량은 소수 문자열로 전달되는 경우가 많습니다. 이를 이진 부동소수점으로 변환한 뒤 나머지 연산을 하면 사람이 기대한 배수 조건과 다르게 계산될 수 있습니다. 사용하는 언어의 십진수 처리나 정수 스케일 방식 등 적절한 표현을 검토해야 합니다.

어떤 방식을 쓰더라도 입력값, 규칙값, 최종 직렬화값이 일관되어야 합니다. 내부 검증에서는 통과했지만 전송 문자열이 다른 값으로 바뀌는 구조라면 사전 검증의 의미가 약해집니다. 화면에 보이는 반올림값과 실제 전송값도 구분해서 확인하세요.

알 수 없는 필드와 필터

새 필드가 추가됐다고 전체 응답을 무조건 버리는 파서는 변경에 취약할 수 있습니다. 반대로 알 수 없는 필터를 무시한 채 모든 주문을 정상으로 간주하면 필요한 검사를 빠뜨릴 수 있습니다. 일반 부가 필드와 주문 가능성에 영향을 주는 규칙을 구분해 대응 정책을 정합니다.

문서와 실제 응답에 차이가 있으면 확인한 사실과 추정한 의미를 분리합니다. 필드 이름이 직관적으로 보여도 공식 설명을 찾기 전에는 계산식이나 동작을 만들어내지 않습니다. 변경 기록과 문서 확인 시각을 남겨 이후 검토가 가능하게 합니다.

11. 오류 진단 표

이 표는 원인을 좁히기 위한 출발점입니다. 실제 오류 코드와 메시지, 요청값, 사용한 규칙의 시각을 함께 확인해야 합니다. 개인 인증 정보나 비밀 키를 외부에 공유하지 않고도 공개 규칙과 요청 형식의 많은 문제를 진단할 수 있습니다.

12. FAQ

Q1. 바이낸스 Exchange Info는 주문을 넣는 기능인가요?

아닙니다. 현재 거래 규칙과 심볼 정보를 조회하는 기능입니다. 조회 결과를 주문 전 검증에 사용할 수 있지만 조회 자체가 주문 접수나 체결을 만들지 않습니다. 실제 거래 요청은 별도 경로와 권한을 따릅니다.

Q2. 현물과 선물의 Exchange Info는 같은가요?

제품별 경로와 응답 규격을 따로 확인해야 합니다. 이 글은 Spot의 GET /api/v3/exchangeInfo를 다룹니다. 이름이 비슷해도 선물 계약 조건이나 계정 구조를 현물 문서로 대신할 수 없습니다.

Q3. 모든 파라미터가 선택이면 아무 조합이나 가능한가요?

그렇지 않습니다. permissions와 symbolStatus에는 symbol·symbols와의 조합 제약이 있습니다. 선택 여부와 조합 가능 여부를 구분하고 현재 공식 파라미터 설명을 읽어야 합니다.

Q4. 기본 조회가 모든 심볼을 반환하나요?

현재 문서는 permissions 생략 시의 반환 권한 범위를 명시합니다. 따라서 조건 없는 완전한 전체 목록이라고 단정하지 않습니다. 필요한 범위가 무엇인지 정한 뒤 필터 조건과 공식 권한 목록을 확인하세요.

Q5. baseAssetPrecision으로 stepSize를 만들 수 있나요?

정밀도와 주문 수량 간격은 다른 개념입니다. 실제 수량 조건은 적용되는 필터에서 확인해야 합니다. 소수점 자릿수가 맞아도 허용 배수나 최소·최대 수량 조건에서 거절될 수 있습니다.

Q6. filters 배열의 첫 항목이 항상 가격 필터인가요?

배열 위치에 의존하지 말고 filterType으로 필요한 규칙을 찾아야 합니다. 순서가 의미를 보장한다고 가정하면 변경이나 다른 심볼에서 잘못된 값을 읽을 수 있습니다. 없는 필터와 알 수 없는 필터도 구분합니다.

Q7. permissionSets의 내부 배열은 왜 중요한가요?

내부 집합 안의 선택 관계와 집합 사이의 동시 충족 관계를 표현하기 때문입니다. 배열을 평평하게 합치면 원래 조건을 바꿀 수 있습니다. 공식 예시의 OR·AND 구조를 그대로 해석해야 합니다.

Q8. showPermissionSets를 false로 하면 권한 제한이 없어지나요?

아닙니다. 응답의 해당 내용을 채울지 제어하는 옵션입니다. 실제 계정 권한이나 서버의 거래 허용 조건을 바꾸는 기능이 아닙니다. 표시 범위와 실행 권한을 혼동하지 마세요.

Q9. TRADING이면 필터를 확인하지 않아도 되나요?

거래 상태와 주문 조건은 별개입니다. 가격·수량·금액·권한·잔고 등 필요한 조건을 추가로 충족해야 합니다. TRADING은 특정 주문의 접수나 전량 체결을 보장하지 않습니다.

Q10. 응답 예시의 최소 금액을 그대로 써도 되나요?

예시는 형식과 의미를 설명하는 자료입니다. 현재 대상 심볼의 실제 응답을 확인해야 합니다. quoteAsset과 시장가 적용 조건도 함께 보아야 하며 모든 거래쌍에 같은 값을 적용하면 안 됩니다.

Q11. 매 주문 전에 전체 목록을 조회해야 하나요?

모든 환경에 그런 고정 규칙이 있는 것은 아닙니다. 호출 예산과 변경 대응을 고려한 캐시 정책을 설계할 수 있습니다. 중요한 것은 갱신 시각과 실패 상태를 알고 필요할 때 현재 규칙을 다시 확인하는 것입니다.

Q12. 조회 실패하면 기존 캐시를 삭제해야 하나요?

조회 실패와 실제 빈 목록을 구분해야 합니다. 기존 자료를 보존할 수 있지만 오래된 자료임을 표시하고 그 상태에서 허용할 판단을 정해야 합니다. 실패 응답으로 정상 자료를 무조건 덮어쓰는 것은 원인 분석을 어렵게 합니다.

Q13. 기능 허용 값이 true인데 앱에 메뉴가 없어요.

API 지원과 앱 화면 제공은 동일한 질문이 아닙니다. 앱 버전·계정·제품·외부 도구의 구현 범위가 다를 수 있습니다. 확인하지 않은 메뉴 위치를 추측하기보다 현재 공식 이용 안내와 도구의 지원 범위를 확인하세요.

Q14. 사전 필터 검사를 통과했는데 왜 거절되나요?

조회와 전송 사이의 변화, 계정 조건, 다른 필터, 실제 전송값의 차이 등이 있을 수 있습니다. 서버 응답을 기준으로 원인을 분류해야 합니다. 사전 검사는 오류를 줄이는 단계이지 최종 수락을 보장하는 단계가 아닙니다.

Q15. 다음으로 어떤 개념을 보면 좋나요?

가격과 수량을 곱한 주문 금액의 조건을 다루는 MIN_NOTIONAL·NOTIONAL로 이어집니다. 정밀도와 수량 간격을 맞춘 뒤에도 금액 하한·상한을 확인해야 하므로 Exchange Info의 필터를 실제로 읽는 연습에 적합합니다.

13. 운영 체크리스트

• 현물·선물 등 제품과 API 경로를 구분했다.
• 운영 환경과 테스트 환경을 구분했다.
• 정확한 symbol과 baseAsset·quoteAsset을 확인했다.
• 요청 파라미터의 조합 제약을 확인했다.
• 필터된 목록의 부재를 상장폐지로 단정하지 않는다.
• precision과 tickSize·stepSize를 구분한다.
• filters는 배열 순서가 아닌 filterType으로 찾는다.
• permissionSets의 내부·외부 배열 논리를 보존한다.
• 기능 허용과 계정 권한을 별도로 확인한다.
• 최종 가격·수량으로 금액 조건까지 재검사한다.
• 캐시의 출처·조회 시각·실패 여부를 기록한다.
• 새 필드와 알 수 없는 필터의 대응 정책이 있다.
• 실제 요청 응답과 주문 상태를 확인한다.
• 로그에 비밀 키나 인증 정보를 남기지 않는다.

핵심 정리

바이낸스 Exchange Info를 제대로 활용한다는 것은 긴 응답에서 숫자 몇 개를 복사하는 것보다 각 필드가 어떤 질문에 답하는지 이해하는 데 가깝습니다. 거래 규칙, 현재 시장 자료, 계정 상태를 분리해서 읽고 최종 요청 결과까지 확인하면 주문 오류를 더 구체적으로 진단할 수 있습니다.

이 글은 API와 거래 규칙을 이해하기 위한 정보성 자료입니다. 특정 주문의 접수·체결이나 투자 성과를 보장하지 않습니다. 실제 이용 전 최신 Binance 공식 문서와 대상 심볼·계정의 현재 조건을 확인하세요.