바이낸스 Account Filters 뜻 2026｜myFilters·MAX_ASSET·계정별 주문 조건 확인

바이낸스 Account Filters 뜻 2026｜myFilters·MAX_ASSET·계정별 주문 조건 확인

바이낸스 Account Filters는 내 계정이 특정 거래쌍에서 주문할 때 적용되는 조건을 확인하는 관점입니다. 같은 심볼을 보고 같은 가격과 수량을 입력했더라도, 공개된 거래쌍 규칙만으로 내 주문의 모든 조건을 설명할 수 있다고 가정하면 안 됩니다. 공개 시장 규칙과 계정에 관련된 필터를 나눠 확인하는 일이 핵심입니다.

2026년 11월 2일 확인한 현물 공식 문서는 GET /api/v3/myFilters를 통해 해당 계정과 심볼에 관련된 필터를 조회하는 방법을 안내합니다. 특히 MAX_ASSET이 계정에 적용되는지 보여주는 요청으로 설명합니다. 이 글은 기존 Tick Size·Notional·Exchange Info 개론을 반복하기보다 계정 관점에서 규칙을 모아 읽고 오류를 분류하는 방법에 집중합니다.

앞선 주문 수정 이력 글에서는 무엇이 실제로 바뀌었는지를 확인했습니다. 다음 질문은 “왜 이 변경이나 새 주문이 허용되지 않았는가”입니다. 이 질문에 답하려면 과거 이력뿐 아니라 현재 적용되는 규칙도 확인해야 합니다. 규칙을 읽는 일과 규칙을 우회하는 일은 다릅니다.

먼저 보는 핵심

필터를 조회했다고 주문 성공이 보장되는 것은 아닙니다. 권한, 잔고, 거래 상태, 시장 변화와 요청 형식도 관련됩니다. 조회 결과는 중요한 검증 자료이지만 모든 실패 원인을 한 번에 설명하는 만능 승인서가 아닙니다.

1. 같은 거래쌍인데 결과가 다를 수 있는 이유

공개 호가창은 누구나 같은 시장을 볼 수 있게 하지만, 각 계정의 상태까지 같다는 뜻은 아닙니다. 사용 가능한 잔고, 이미 열려 있는 주문, 보유 자산, 권한 및 적용 조건이 다를 수 있습니다. 따라서 다른 사람의 주문이 접수됐다는 사실만으로 내 주문도 같은 조건에서 접수된다고 단정하지 않습니다.

특히 예시 코드나 인터넷 화면은 특정 시점의 자료입니다. 문서에 나온 숫자가 실제 현재 계정의 제한이라고 생각하면 오해가 생깁니다. 공식 문서는 구조를 설명하는 예시와 실제 조회 결과를 구분해서 읽어야 합니다.

내 계정의 주문 실패를 분석하려면 요청 내용과 당시 상태를 연결해야 합니다. 가격과 수량만 따로 적어 두면, 다른 미체결 주문 때문에 제한에 걸렸는지 자산별 조건 때문인지 확인하기 어렵습니다. 심볼, 주문 유형, 방향, 수량, 가격, 오류 응답을 함께 확보하는 것이 좋습니다.

이때 비밀키나 서명을 공개할 필요는 없습니다. 요청 조건을 설명하는 자료와 인증 자격 증명은 별개입니다. 오류를 공유하거나 문의할 때 필요한 정보만 남기고 민감한 인증 값은 제거해야 합니다.

2. myFilters가 제공하는 세 묶음

현재 공식 응답 예시는 exchangeFilters, symbolFilters, assetFilters를 구분합니다. 세 배열은 같은 종류의 값을 반복하는 것이 아니라 적용 범위가 다른 규칙을 나누는 구조입니다. 이름이 filter로 끝난다고 모두 가격 제한이라고 생각하면 안 됩니다.

symbolFilters에는 가격과 수량, 명목 금액처럼 특정 심볼에 관련된 규칙이 있을 수 있습니다. exchangeFilters는 더 넓은 범위의 주문 조건을 설명합니다. assetFilters는 자산을 기준으로 적용되는 규칙을 설명합니다.

응답을 읽을 때는 먼저 filterType을 확인하고 해당 필터의 문서상 의미와 연결해야 합니다. 배열의 첫 번째 행이 항상 가격 필터라고 가정하는 구현은 순서가 바뀌거나 필터가 추가될 때 잘못된 해석을 할 수 있습니다.

필터가 없거나 예상한 항목이 보이지 않는 경우에도 무조건 제한이 없다고 확대 해석하지 않습니다. 요청 성공 여부와 실제 응답 구조, 문서의 범위를 확인해야 합니다. 다른 조건이 별도로 존재할 수 있다는 점을 유지해야 합니다.

3. MAX_ASSET의 핵심은 한 주문과 자산 단위다

공식 필터 문서는 MAX_ASSET을 계정이 한 주문에서 거래할 수 있는 특정 자산의 최대 수량과 관련된 규칙으로 설명합니다. 여기서 중요한 단어는 한 주문, 자산, 해당 심볼에서의 역할입니다. 계정 전체 평가액이나 일일 출금 한도와 같은 개념으로 읽으면 안 됩니다.

해당 자산이 심볼의 기초 자산이라면 주문 수량에 적용됩니다. 기준 자산이라면 주문의 명목 금액에 적용됩니다. 같은 자산 이름이어도 거래쌍에서 어느 쪽에 위치하는지에 따라 비교할 값이 달라집니다.

가상 자산 X가 기초 자산인 X/Y 시장에서는 수량 X를 확인합니다. X가 기준 자산인 Z/X 시장에서는 X로 표시한 거래 금액을 확인합니다. 단위를 보지 않고 같은 숫자를 주문 수량에만 대입하면 서로 다른 시장에서 오류가 생깁니다.

현재 문서의 예시에는 특정 자산과 limit 값이 등장하지만, 그 숫자는 모든 사용자의 현재 한도가 아닙니다. 실제 적용 여부와 값은 자신의 계정에 대한 적절한 조회 결과로 확인해야 합니다. 예시를 현재 정책으로 인용하지 않는 것이 중요합니다.

4. 기초 자산과 기준 자산을 먼저 표시하기

거래쌍을 읽을 때 기초 자산은 거래 수량의 중심이고 기준 자산은 가격과 대금을 표현하는 단위입니다. 실제 심볼의 baseAsset과 quoteAsset을 확인하면 문자열을 눈대중으로 나누다가 발생하는 오류를 줄일 수 있습니다.

예를 들어 가상 X/Y 시장에서 가격 20, 수량 3이라면 명목 금액은 설명상 60 Y입니다. X에 대한 수량 제한은 3 X와 비교하고, Y에 대한 금액 제한은 60 Y와 비교해야 합니다. 3과 60 중 어느 숫자가 맞는지는 규칙의 단위에 따라 달라집니다.

실제 계산에서는 가격·수량 정밀도와 주문 유형을 함께 확인해야 합니다. 특히 시장가처럼 실행 가격이 사전에 단일 값으로 확정되지 않는 주문을 단순 지정가 예제처럼 검증한다고 보장할 수 없습니다. 확인한 공식 규칙의 범위를 넘어 자체 계산을 승인 결과처럼 제시하지 않아야 합니다.

화면이나 관리표에는 숫자 옆에 자산 단위를 붙이는 것이 좋습니다. “한도 100”보다 “100 X”와 “100 Y 상당 명목 금액”처럼 구분해야 사용자가 같은 숫자를 다른 의미로 읽지 않습니다. 이는 자체 도구를 설계할 때의 권고입니다.

5. MAX_POSITION과 MAX_ASSET은 다르다

두 이름 모두 최대치를 말하지만 범위가 다릅니다. MAX_ASSET은 특정 자산의 한 주문 거래량과 관련되고, MAX_POSITION은 해당 심볼의 기초 자산에 대해 계정이 가질 수 있는 포지션 조건을 설명합니다. 한 번의 주문 크기와 누적 노출을 같은 것으로 취급하면 안 됩니다.

공식 MAX_POSITION 설명은 기초 자산의 free 잔고, locked 잔고, 열려 있는 매수 주문 수량의 합을 고려합니다. 따라서 현재 자유 잔고만 보고 충분히 여유가 있다고 판단할 수 없습니다. 다른 주문이 미래에 체결될 수 있는 수량도 영향을 줄 수 있습니다.

가상으로 자유 수량 2, 잠긴 수량 1, 열린 매수 주문 수량 4가 있다면 설명상 이미 고려되는 수량은 7입니다. 새 매수 수량을 검토할 때 2만 보고 계산하면 노출을 과소평가합니다. 실제 적용은 최신 필터와 계정 상태를 확인해야 합니다.

MAX_ASSET과 MAX_POSITION을 비교할 때는 “한 주문의 크기”와 “계정의 관련 노출”이라는 질문을 나눠 적어 보면 좋습니다. 하나의 필터를 통과했다고 다른 필터까지 통과하는 것은 아닙니다.

6. 가격·수량·명목 금액은 동시에 맞아야 한다

가격이 tickSize에 맞고 수량이 stepSize에 맞더라도 명목 금액 조건이 맞지 않을 수 있습니다. 반대로 명목 금액이 충분해도 수량 단위가 맞지 않으면 문제가 될 수 있습니다. 필터는 하나만 골라 통과시키는 선택지가 아니라 적용되는 조건을 함께 확인하는 구조입니다.

가상 지정가 주문에서 가격 10, 수량 0.3이면 금액은 3입니다. 수량 단위가 맞는다고 해도 최소 명목 금액이 그보다 크다면 다른 조건에서 걸릴 수 있습니다. 예시 숫자는 실제 시장의 한도가 아니라 조건 간 관계를 설명하기 위한 것입니다.

반올림 방향도 중요합니다. 수량을 단위에 맞춰 올리면 금액이나 자산 한도를 넘을 수 있고, 내리면 최소 금액을 충족하지 못할 수 있습니다. 따라서 한 필드를 조정한 뒤 다른 조건도 다시 계산해야 합니다.

오류 해결을 위해 값을 자동으로 바꿔 실제 주문을 내는 도구라면 사용자의 거래 의도와 허용 범위를 존중해야 합니다. 단순히 요청이 통과할 때까지 수량을 늘리거나 가격을 넓히는 것은 원래 의도와 다른 거래가 될 수 있습니다. 이 글은 규칙 확인 절차를 설명하며 그런 자동 변경을 권하지 않습니다.

7. 조회 절차를 순서대로 정리하기

현재 myFilters 문서는 symbol과 timestamp를 필수로 안내하며 계정 서명 요청입니다. 공식 문서의 권한·시간·서명 조건을 확인해야 합니다. 여기서는 인증 정보를 입력하거나 계정에 직접 연결하지 않고 읽는 순서를 설명합니다.

1. 실제 거래쌍의 정확한 심볼을 확인합니다.
2. 해당 시장이 현물인지 확인합니다.
3. 공개 거래 정보로 기초·기준 자산과 일반 규칙을 확인합니다.
4. 계정에 관련된 myFilters 결과를 확보합니다.
5. 세 필터 묶음을 종류별로 분리합니다.
6. 각 값의 단위와 적용 범위를 적습니다.
7. 실제 주문 조건과 오류 메시지를 비교합니다.
8. 바꾼 값이 다른 규칙에 영향을 주는지 다시 검토합니다.

조회 자료에는 확인 시각을 붙이는 편이 좋습니다. 어제의 규칙을 오늘의 주문에 적용했는지, 주문 실패 이후 최신 자료를 다시 확인했는지 알 수 있기 때문입니다. 다만 불필요한 반복 호출로 요청 한도를 소모하지 않도록 해야 합니다.

기존 도구가 myFilters를 지원하지 않는다면 현재 문서와 도구의 지원 범위를 먼저 확인합니다. 공개 exchangeInfo 결과를 계정별 조회 결과처럼 이름만 바꿔 표시해서는 안 됩니다. 실제로 확보한 자료의 출처를 정확히 구분해야 합니다.

8. 다섯 가지 가상 사례

아래 숫자는 구조를 설명하는 가상 값입니다. 실제 계정 제한이나 특정 자산의 현재 거래 규칙을 나타내지 않습니다. 실제 사용 전에는 최신 응답을 확인해야 합니다.

사례 1. 자산이 기초 자산인 경우

가상 X/Y 시장에서 X에 대한 MAX_ASSET 한도가 5 X라고 가정합니다. 주문 수량이 6 X이면 이 한 주문 수량이 한도와 비교되는 대상입니다. 가격이 낮아 총금액이 작다는 이유만으로 수량 제한을 무시할 수 없습니다.

이 사례에서는 가격을 낮춰도 주문 수량 6 X라는 사실은 바뀌지 않습니다. 수량 조건을 해결할 때는 해당 필터의 단위와 자신의 거래 의도를 함께 검토해야 합니다. 단순 가격 변경으로 모든 오류를 해결하려는 접근은 맞지 않습니다.

또한 주문을 나누면 모든 제한이 사라진다고 설명하지 않습니다. 다른 주문 수·노출·계정 조건이 별도로 적용될 수 있습니다. 필터의 뜻을 이해하는 것과 제한을 피하려는 실행 전략은 구분해야 합니다.

사례 2. 같은 자산이 기준 자산인 경우

가상 Z/X 시장에서 X가 기준 자산이고 X의 한 주문 한도가 100이라고 가정합니다. 지정가 25 X, 수량 5 Z인 주문의 명목 금액은 125 X입니다. 비교 대상은 5 Z가 아니라 125 X입니다.

사용자가 수량 5가 한도 100보다 작다고 생각하면 단위를 잘못 비교한 것입니다. 같은 숫자라도 자산이 다르면 직접 비교할 수 없습니다. 가격 곱하기 수량으로 계산한 기준 자산 금액과 필터의 자산 단위를 맞춰야 합니다.

가격을 바꾸거나 수량을 바꾸면 명목 금액이 달라집니다. 그러나 다른 필터도 다시 확인해야 합니다. 실제 시장가 주문에 이 단순 지정가 계산을 그대로 적용해 성공을 보장하지 않아야 합니다.

사례 3. 자유 잔고만 보고 MAX_POSITION을 계산함

가상 계정의 기초 자산 자유 잔고는 1, 잠긴 잔고는 2, 열린 매수 주문 수량은 4라고 가정합니다. 사용자는 자유 잔고 1만 보고 새 매수를 크게 넣을 수 있다고 생각합니다.

공식 설명의 구성 요소를 적용하면 이미 고려되는 관련 수량은 7입니다. 새 주문 수량이 더해졌을 때 허용 범위를 넘는지 검토해야 합니다. 자유 잔고는 전체 관련 노출과 같지 않습니다.

이 사례는 잔고가 충분한지와 포지션 제한이 맞는지를 나눠 확인해야 함을 보여줍니다. 기준 자산 잔고가 넉넉하더라도 기초 자산의 노출 조건에 걸릴 수 있습니다. 잔고 화면 하나로 모든 주문 조건을 판단하면 안 됩니다.

사례 4. 수량 단위를 맞췄더니 최소 금액이 부족함

가상 주문 수량을 stepSize에 맞추기 위해 아래로 조정했다고 가정합니다. 조정 전에는 예상 금액이 최소 명목 금액 이상이었지만, 조정 후에는 그보다 작아질 수 있습니다.

이때 “수량 필터 오류를 해결했으니 끝났다”고 생각하면 다음 요청에서 다른 오류를 만납니다. 가격·수량·금액을 함께 검토하고, 조정 후 결과를 다시 계산해야 합니다. 조건 사이의 관계를 보는 것이 중요합니다.

반대로 최소 금액을 맞추려고 수량을 올리면 자산 한도나 잔고 조건에 걸릴 수 있습니다. 자동 보정은 한 방향으로 끝없이 진행할 문제가 아닙니다. 의도한 거래 범위 안에서 가능한 조합인지 먼저 판단해야 합니다.

사례 5. 오래된 설정 파일과 최신 응답이 다름

자체 도구가 과거에 저장한 필터 값을 계속 사용한다고 가정합니다. 실제 주문에서는 다른 오류가 발생하지만 로컬 검증은 통과합니다. 이때 로컬 계산이 통과했다는 사실만으로 거래소 응답이 잘못됐다고 결론 내리면 안 됩니다.

필터 자료의 확인 시각과 실제 대상 심볼을 확인합니다. 최신 공식 조회 결과와 저장값을 비교하고 변경된 부분을 기록합니다. 새로운 값을 적용하기 전에 단위나 필드 구조가 달라진 것은 아닌지도 검토해야 합니다.

설정 갱신은 과거 기록을 지우는 방식보다 버전을 남기는 편이 분석에 유리합니다. 과거 주문이 당시 어떤 규칙으로 판단됐는지 알아야 오류 원인을 재현할 수 있기 때문입니다. 현재 값과 과거 값을 동시에 참으로 취급하지 않고 시점을 구분합니다.

9. 오류 메시지를 필터 종류와 연결하기

오류를 만났을 때 가장 먼저 할 일은 실제 메시지를 읽는 것입니다. 모든 오류를 “최소 주문 금액 부족”으로 묶으면 가격·수량·권한·잔고 문제를 구분할 수 없습니다. 필터 이름이 명시돼 있다면 그 종류를 현재 응답과 연결합니다.

가격 관련 오류라면 가격 단위와 허용 범위를 확인합니다. 수량 관련 오류라면 minQty·maxQty·stepSize 같은 해당 규칙을 확인합니다. 명목 금액 오류라면 가격과 수량의 조합, 주문 유형별 적용 조건을 검토해야 합니다.

자산 관련 조건이라면 asset과 baseAsset·quoteAsset의 관계를 봅니다. 주문 수나 포지션 관련 문제라면 현재 열려 있는 주문과 잔고 구성을 함께 확인해야 합니다. 같은 가격·수량을 반복 전송하는 것만으로 상태가 해결되지 않을 수 있습니다.

오류가 명확하지 않으면 임의로 원인을 확정하지 않습니다. “요청 거절 확인, 해당 규칙 대조 필요”처럼 현재 확인된 상태를 남기고 필요한 자료를 확보하는 편이 좋습니다. 오류 설명을 보지 않고 값만 계속 바꾸면 원래 실패 원인을 잃어버립니다.

10. 필터 통과와 체결 완료는 다르다

필터 검증은 주문이 규칙에 맞는지를 판단하는 단계입니다. 주문이 접수됐다고 실제 거래가 완료되는 것은 아닙니다. 지정가 주문은 대기할 수 있고, 시장 조건에 따라 일부만 체결되거나 종료될 수 있습니다.

따라서 “필터를 통과했으니 안전한 주문”이라는 표현은 적절하지 않습니다. 시스템이 허용하는 입력이라는 사실과 사용자의 투자 위험은 별개입니다. 가격 변동이나 유동성 위험, 수수료와 손실 가능성은 그대로 남습니다.

같은 이유로 필터 조회 결과를 투자 판단에 직접 연결하지 않아야 합니다. 한도가 크다고 좋은 자산이라는 뜻이 아니고, 규칙이 엄격하다고 특정 가격 방향을 예측할 수 있는 것도 아닙니다. 거래 규칙은 실행 조건에 관한 정보입니다.

결과 보고에는 요청 검증, 접수, 체결, 잔량 처리를 구분하는 편이 좋습니다. 한 단어로 완료라고 표시하면 사용자가 실제 거래까지 끝났다고 오해할 수 있습니다. 확인한 단계에 맞는 표현을 사용해야 합니다.

11. 자체 검증표를 만들 때 유용한 항목

실무에서는 심볼, 시장, 기초 자산, 기준 자산, 주문 유형, 방향, 가격, 수량을 먼저 적습니다. 그 옆에 적용 필터와 현재 값을 연결하고, 계산 단위를 표시하면 오류를 찾기 쉽습니다.

예를 들어 가격은 Y/X처럼 의미가 혼동되지 않게 실제 문맥에 맞춰 표시하고, 수량은 기초 자산 단위, 명목 금액은 기준 자산 단위로 분리합니다. 표시 관례를 팀이나 도구 안에서 일관되게 정하는 것이 중요합니다.

필터 종류별로 검증 결과를 남기되, 미확인 상태를 통과로 바꾸지 않아야 합니다. 자료를 확보하지 못한 항목은 확인 필요로 표시합니다. 모든 칸을 초록색으로 만들기 위해 기본값을 임의로 채우는 것은 검증의 목적과 다릅니다.

원문 조회 결과와 자체 계산 결과를 분리하면 나중에 계산 오류를 수정하기 쉽습니다. 실제 반환값을 수정해 계산값에 맞추는 방식은 피해야 합니다. 검증표는 거래소 응답을 설명하기 위한 도구이지 응답을 바꾸는 자료가 아닙니다.

12. 숫자 정밀도와 반올림

가격과 수량은 작은 소수 단위까지 사용될 수 있습니다. 이진 부동소수점 계산에서 생기는 오차를 그대로 사용하면, 사람이 보기에는 단위에 맞아 보이는데 나머지 계산이 어긋날 수 있습니다. 사용하는 도구의 소수 처리 방식을 확인하는 것이 좋습니다.

이 글은 특정 언어의 구현을 요구하지 않습니다. 중요한 것은 문자열로 받은 원래 값을 보존하고, 필요한 정밀도로 계산하며, 반올림 정책을 명시하는 것입니다. 화면 표시를 위해 줄인 숫자를 다시 주문 검증의 입력으로 사용하면 정보가 손실될 수 있습니다.

필터 문서에서 특정 값 0이 규칙 비활성화를 의미하는 경우가 있지만, 이를 모든 필터의 모든 0에 적용하면 안 됩니다. PRICE_FILTER의 개별 규칙 설명처럼 해당 문서에 정의된 의미를 따로 확인해야 합니다.

값이 없다는 것과 0이라는 것도 다릅니다. 응답 파싱에 실패했는데 0으로 채우면 제한이 없는 것처럼 보이거나 최소값이 없는 것처럼 보일 수 있습니다. 누락·오류·실제 0을 다른 상태로 관리해야 합니다.

13. 최신성 관리와 과도한 호출 방지

규칙은 변경될 수 있으므로 최신 자료 확인이 필요합니다. 그렇다고 매 화면 갱신마다 모든 계정 필터를 무조건 반복 조회하는 것이 좋은 설계라는 뜻은 아닙니다. 요청 비용과 현재 한도를 함께 고려해야 합니다.

현재 myFilters의 요청 가중치는 공식 문서에 안내돼 있습니다. 실제 구현에서는 최신 값을 확인하고 전체 프로그램의 호출량을 관리해야 합니다. 필터 검증을 하려다가 과도한 조회로 다른 요청까지 제한받는 상황을 피해야 합니다.

캐시를 사용한다면 언제 확보한 자료인지 표시하고 갱신 조건을 정합니다. 주문 오류가 발생했을 때 오래된 규칙 때문인지 확인할 수 있어야 합니다. 단순히 파일이 존재한다는 이유로 영구히 유효하다고 취급하지 않습니다.

변경을 감지했을 때는 바뀐 필드와 적용 시점을 기록하는 것이 좋습니다. 모든 과거 주문을 새 규칙으로 소급 평가하면 당시에는 유효했던 요청을 잘못된 요청으로 분류할 수 있습니다. 규칙과 사건의 시점을 함께 보존해야 합니다.

14. 자주 묻는 질문

Q1. Account Filters는 공식 주문 유형인가요?

주문 유형이 아니라 계정에 관련된 거래 조건을 확인하는 관점입니다. 공식 API의 Query relevant filters와 관련 필터 문서를 기준으로 읽어야 합니다. 새로운 매수·매도 방식이라는 뜻은 아닙니다.

Q2. exchangeInfo만 보면 충분한가요?

공개 심볼 규칙을 확인하는 데 중요하지만 계정에 관련된 모든 조건을 대신한다고 가정하면 안 됩니다. 공식 문서는 myFilters를 통해 계정에 관련된 필터와 MAX_ASSET 적용 여부를 확인하도록 설명합니다.

Q3. myFilters는 공개 조회인가요?

계정 관련 USER_DATA 요청입니다. 인증·서명 조건을 확인해야 하며 공개 시세 요청처럼 다루지 않습니다. 자격 증명을 공개 예제나 오류 화면에 노출하지 않아야 합니다.

Q4. MAX_ASSET은 하루 거래 한도인가요?

확인한 문서는 한 주문에서 거래할 수 있는 특정 자산 수량과 관련된 규칙으로 설명합니다. 일일 거래 총액이나 출금 한도로 바꿔 해석하지 않습니다.

Q5. 자산이 기초 자산이면 무엇과 비교하나요?

주문 수량과 비교하는 구조입니다. 실제 심볼의 baseAsset을 확인하고 단위를 맞춰야 합니다. 가격이 낮다는 이유로 수량 조건을 무시할 수 없습니다.

Q6. 자산이 기준 자산이면 무엇과 비교하나요?

주문의 명목 금액과 관련됩니다. 수량 숫자만 비교하면 단위가 달라질 수 있습니다. 실제 가격·수량과 주문 유형에 맞는 규칙을 확인해야 합니다.

Q7. MAX_POSITION은 MAX_ASSET과 같은가요?

아닙니다. 한 주문의 자산 거래량과 계정의 관련 포지션 조건은 다릅니다. MAX_POSITION은 자유·잠긴 잔고와 열린 매수 주문 수량 등 문서상 구성 요소를 확인해야 합니다.

Q8. 잔고가 충분하면 주문이 접수되나요?

잔고 외에도 가격·수량·금액·주문 수·권한·거래 상태 등 조건이 있습니다. 잔고 하나만으로 모든 규칙의 통과를 판단하지 않습니다.

Q9. 필터를 통과하면 전량 체결되나요?

아닙니다. 규칙 검증과 실제 체결은 다른 단계입니다. 주문 유형과 유동성, 가격 움직임에 따라 대기하거나 일부만 체결될 수 있습니다.

Q10. 문서 예시의 limit이 내 계정 한도인가요?

예시 숫자를 실제 현재 계정 한도로 일반화하면 안 됩니다. 자신의 대상 심볼과 계정에 대한 현재 응답을 확인해야 합니다.

Q11. 오류가 나면 주문을 쪼개면 되나요?

그렇게 단정하지 않습니다. 다른 주문 수·노출·계정 규칙도 적용될 수 있습니다. 먼저 어떤 필터에서 거절됐는지 확인하고 사용자의 거래 의도 안에서 조건을 검토해야 합니다.

Q12. 수량을 반올림하면 해결되나요?

한 조건이 맞아도 다른 조건이 어긋날 수 있습니다. 수량 조정 후 명목 금액과 자산 한도 등을 다시 확인해야 합니다. 반올림 방향도 의도한 거래 규모에 영향을 줍니다.

Q13. 필터 값이 0이면 제한이 없나요?

해당 필터의 공식 정의를 확인해야 합니다. 특정 규칙의 0 의미를 모든 필드에 확장하지 않습니다. 누락된 값과 실제 0도 구별해야 합니다.

Q14. 오래된 필터 파일을 계속 써도 되나요?

규칙은 변경될 수 있으므로 확인 시각과 갱신 정책이 필요합니다. 실제 오류가 발생하면 최신 자료와 대조해야 합니다. 파일이 있다는 이유만으로 현재 유효하다고 단정하지 않습니다.

Q15. 필터 값으로 가격 전망을 알 수 있나요?

거래 실행 조건에 관한 정보이지 미래 가격을 예측하는 지표가 아닙니다. 한도와 지원 범위를 투자 매력이나 수익 가능성으로 바꿔 해석하지 않아야 합니다.

15. 실무 체크리스트

• 시장이 현물인지 확인했는가?
• 실제 symbol과 baseAsset·quoteAsset을 확인했는가?
• 공개 규칙과 계정 관련 조회를 구분했는가?
• myFilters의 세 묶음을 종류별로 읽었는가?
• 배열 순서 대신 filterType으로 의미를 연결했는가?
• MAX_ASSET의 자산과 단위를 확인했는가?
• 기초 자산 수량과 기준 자산 금액을 구분했는가?
• MAX_POSITION을 한 주문 한도와 혼동하지 않았는가?
• 자유·잠긴 잔고와 열린 매수 주문을 함께 검토했는가?
• 가격·수량 조정 후 다른 필터도 다시 확인했는가?
• 실제 오류 메시지를 보존했는가?
• 조회 시각과 규칙 버전을 남겼는가?
• 누락 값과 실제 0을 구분했는가?
• 필터 통과를 체결 보장이나 투자 안전성으로 표현하지 않았는가?

주문 조건표를 직접 읽는 연습

가격과 수량, 자산 한도가 함께 등장하면 숫자를 섞기 쉽습니다. 아래는 구조를 이해하기 위한 가상 지정가 주문입니다. 실제 거래쌍의 지원 조건이나 현재 한도를 나타내지 않습니다.

가상 X/Y 시장에서 가격이 20 Y, 수량이 4 X라고 놓겠습니다. 명목 금액은 80 Y입니다. X 관련 한 주문 수량 조건과 Y 관련 한 주문 금액 조건이 동시에 있다면 각각 다른 숫자를 비교해야 합니다.

이 표에서 X 한도가 가상으로 5라면 수량 4와 비교합니다. Y 한도가 가상으로 70이라면 명목 금액 80과 비교합니다. 첫 조건을 만족해도 둘째 조건을 만족하지 않을 수 있습니다. 한 주문에는 서로 다른 단위의 규칙이 함께 적용될 수 있다는 뜻입니다.

사용자가 수량을 3 X로 조정하면 명목 금액은 설명상 60 Y가 됩니다. 그러나 이 계산만으로 주문이 허용된다고 결론 내리지 않습니다. 수량 단위, 최소 금액, 잔고, 다른 주문 상태 등 아직 검토하지 않은 조건이 있기 때문입니다.

가격을 15 Y로 바꾸면 같은 수량 4 X의 명목 금액은 60 Y가 되지만, 가격을 바꾸는 것은 거래 의도 자체를 바꾸는 행동입니다. 시스템 규칙을 통과시키기 위해 사용자가 원하지 않는 가격으로 조정해서는 안 됩니다. 검증 도구는 결과를 설명해야지 사용자의 거래 결정을 대신 만들어서는 안 됩니다.

단위 오류를 찾는 질문

첫 번째 질문은 “이 숫자는 자산 수량인가 금액인가”입니다. 가격·수량·대금이라는 이름을 정확히 붙이면 단위가 드러납니다. 열 제목 없이 숫자만 나열된 표는 같은 값도 다른 의미로 읽힐 수 있습니다.

두 번째 질문은 “이 규칙은 한 주문인가 계정 전체인가”입니다. 한 주문 한도와 현재 보유 및 열린 주문을 고려하는 조건은 계산 범위가 다릅니다. 어느 범위를 제한하는지 모르면 같은 주문 수량을 올바르게 평가할 수 없습니다.

세 번째 질문은 “실제 현재 값인가 예시인가”입니다. 문서 샘플의 숫자, 과거에 저장한 값, 현재 조회한 값은 서로 다른 근거입니다. 값을 옮길 때 출처와 확인 시각을 같이 남기면 현재 규칙으로 오해하는 일을 줄일 수 있습니다.

네 번째 질문은 “이번 요청에 적용되는가”입니다. 주문 유형과 방향에 따라 필터의 적용 항목이 다를 수 있습니다. 모든 숫자를 모든 주문에 똑같이 적용하는 단순 계산기는 실제 규칙을 충분히 반영하지 못할 수 있습니다.

조회 실패를 제한 없음으로 바꾸지 않기

계정 필터 조회에서 인증 오류나 시간 오류가 발생했는데 프로그램이 빈 배열로 바꿔 버리면 사용자에게는 아무 제한이 없는 것처럼 보일 수 있습니다. 정상 응답에서 항목이 없는 경우와 요청 자체가 실패한 경우를 다른 상태로 표시해야 합니다.

예를 들어 자체 점검표에서 자료 확보 실패는 “미확인”으로 남기는 편이 좋습니다. 가격·수량 계산을 할 수 있는 항목이 있더라도 계정 관련 조건 전체를 확인했다고 표시하지 않습니다. 부분 검증과 전체 검증을 구별하는 것은 불필요한 경고를 늘리려는 것이 아니라 실제 근거의 범위를 지키기 위한 것입니다.

오류가 해결되면 같은 대상 심볼로 정상 결과를 확보하고 이전 자료와 구분해 저장합니다. 오류 당시의 응답을 지우지 않고 보존하면 왜 그 시점의 검증이 끝나지 않았는지 설명할 수 있습니다. 성공 결과가 나왔다고 과거 실패를 없던 일로 바꿀 필요는 없습니다.

검증표를 공유할 때는 인증 정보 없이 심볼·규칙 종류·확인 시각·검증 상태를 중심으로 전달할 수 있습니다. 다른 사람이 재검토할 때 필요한 것은 비밀키가 아니라 어떤 자료로 어떤 비교를 했는지입니다.

핵심 정리

바이낸스 Account Filters를 이해하는 핵심은 필터 이름을 많이 외우는 것이 아니라 어떤 범위의 어떤 단위를 제한하는지 구분하는 것입니다. myFilters와 공개 규칙, 실제 주문 응답을 함께 읽으면 같은 숫자를 서로 다른 의미로 비교하는 실수를 줄일 수 있습니다.

공식 확인 자료: 계정 조회 API, Filters, 현물 REST API. 실제 사용 전에 최신 적용 조건을 다시 확인하세요.

이 글은 거래 규칙 이해를 위한 정보이며 투자 권유가 아닙니다. 가상 값은 실제 계정 한도나 현재 정책을 나타내지 않습니다. 디지털 자산 거래에는 가격 변동, 유동성 부족, 시스템 지연 및 원금 손실 위험이 있습니다.