조건 충족, 상향 돌파, 대기 시간을 구분하기
가격이 100보다 크다는 조건을 생각해 봅시다. 101, 102, 103은 모두 이 조건을 충족하지만 상향 돌파가 세 번 발생한 것은 아닙니다. 이 글에서는 유효한 직전 관측값이 100 이하이고 다음 유효한 값이 100을 초과할 때 상향 돌파로 정의합니다. 정확히 100인 값은 이 정의에서 아래쪽에 포함합니다.
반복 정책에 따라 조건이 계속 참일 때 다음 행동을 허용할 수도 있습니다. 돌파만 사용하는 정책은 새로운 전환이 필요합니다. 어느 쪽에도 대기 시간을 추가할 수 있습니다. TradingView 문서 역시 비교 조건과 알림 빈도를 구분합니다. 그 설정이 SharkRule과의 연동을 뜻하지는 않습니다.
무엇이 대기를 시작하는지 적어 두세요. 주문 전송 허용, 체결, 포지션 종료는 서로 다른 시점입니다. 예를 들어 Freqtrade의 CooldownPeriod는 포지션 종료 후 해당 거래쌍에 적용됩니다. 이는 그 도구의 동작이며 보편적인 정의나 SharkRule 타이머 시작 시점의 근거가 아닙니다.
신호를 세기 전에 예제 규칙 정하기
아래 시간, 가격, 금액은 모두 가상이며 자산이나 설정 추천이 아닙니다. 종이 위에서 이름 없는 현물 거래쌍 하나와 규칙 하나를 검토합니다. 관측값은 최신이고 시간순이며 가격은 호가 통화 단위, 시간은 UTC입니다. 표에 있는 관측만 평가합니다. 첫 행은 이전 상태를 정할 뿐 돌파를 만들지 않습니다. 실제 주문은 보내지 않습니다.
100을 새로 상향 돌파하고 마지막으로 허용한 진입에서 최소 120초가 지나야 다음 진입을 허용합니다. 정확히 120초도 통과합니다. 진입을 허용하면 즉시 매수 대금 25와 비용 여유분 1을 예약하고 대기 시간을 시작하며, 이번 실행에서 최대 두 번인 진입 횟수 중 하나를 사용합니다. 비용 여유분을 포함한 누적 한도는 60입니다. 학습용 가정이며 SharkRule 기본값이 아닙니다.
대기 중 차단된 돌파는 기록한 뒤 버리고 나중에 실행할 목록에 넣지 않습니다. 대기 중에도 모든 유효한 관측값으로 직전 가격을 갱신합니다. 차단된 후보는 이 예제의 타이머를 다시 시작하지 않습니다. 권한과 다른 검사는 모두 통과하고 결과를 모르는 이전 주문도 없다고 가정합니다. 표는 행동 허용과 예약 금액을 셀 뿐 거래소의 주문 접수나 체결을 세지 않습니다.
가상 기록: 참인 관측 여섯 번, 허용된 진입 두 번
| UTC 시간 | 가격 | 100 초과? | 새 상향 돌파? | 판단 |
|---|---|---|---|---|
| 09:59:59 | 99 | 아니요 | 초기 상태 | 행동 없음 |
| 10:00:00 | 101 | 예 | 예 | 진입 1 허용, 26 예약 |
| 10:00:30 | 102 | 예 | 아니요 | 조건은 계속 참, 새 사건 없음 |
| 10:01:00 | 99 | 아니요 | 아니요 | 다시 기준선 아래 |
| 10:01:30 | 101 | 예 | 예 | 90초만 경과, 신호 버림 |
| 10:02:00 | 102 | 예 | 아니요 | 120초 경과, 새 돌파 없음 |
| 10:03:00 | 99 | 아니요 | 아니요 | 다시 기준선 아래 |
| 10:03:30 | 101 | 예 | 예 | 210초 경과, 진입 2 허용, 26 예약 |
| 10:06:00 | 99 | 아니요 | 아니요 | 다시 기준선 아래 |
| 10:06:30 | 101 | 예 | 예 | 180초 경과, 횟수와 예산 한도로 진입 3 차단 |
횟수와 그대로 유지되는 예산 확인하기
관측은 열 번입니다. 100을 넘는 값은 여섯 번이고 상향 돌파는 네 번입니다. 시간 조건을 충족하는 돌파는 세 번입니다. 10:00:00에는 이전 진입이 없고, 10:03:30에는 첫 진입 후 210초, 10:06:30에는 두 번째 진입 후 180초가 지났습니다. 이 중 횟수와 지출 한도까지 통과하는 것은 앞의 두 번뿐입니다.
한 번에 25 + 1 = 26을 배정하므로 두 번이면 2 × 26 = 52, 남은 한도는 60 − 52 = 8입니다. 세 번째까지 허용하면 78이 되어 한도 60을 18만큼 초과하고, 최대 두 번이라는 횟수 제한도 넘습니다. 더 기다려도 어느 제한도 풀리지 않습니다. 비용 1은 가상 예약액이지 실제 거래소 수수료가 아닙니다. 실제 비용과 사용 예정 금액은 따로 대조해야 합니다.
10:02:00에 계속 참인 조건을 사용하는 별도의 규칙이라면 동일한 대기 시간과 남은 한도에서 두 번째 진입을 허용할 수 있습니다. 하지만 이 예제의 돌파 규칙은 할 수 없습니다. 10:01:30의 돌파는 버렸고 101에서 102로 바뀐 것은 새 돌파가 아니기 때문입니다. 차단된 신호를 보관한다면 유효 기간과 재검사 조건을 갖춘 별도의 정책이 필요합니다. 카운트다운만 보고 그런 대기 목록이 있다고 추정하지 마세요.
반복 행동을 해석할 때 흔한 실수
조회할 때마다 새 사건으로 세면 조건이 계속 참인 동안 행동이 늘어납니다. 반대로 쿨다운이 끝나면 곧바로 행동할 것이라고 생각하면 돌파 규칙에 필요한 새 전환을 놓칩니다. 시작 당시 가격이 이미 기준선 위라면 초기 상태를 정하는 정책도 필요합니다. 첫 관측만으로는 돌파를 입증할 수 없습니다.
같은 사건이 두 번 전달된 것과 나중에 같은 가격이 새로 관측된 것은 다릅니다. 사건 식별자 또는 관측 시각과 규칙 버전을 남기세요. 중복 전달은 대기가 끝난 뒤에도 도착할 수 있습니다. 도구를 다시 시작한다고 이전 사건 기록, 타이머, 진입 횟수, 지출 약정이 조용히 지워져서는 안 됩니다.
누락된 데이터를 거짓인 값으로 취급해 조건을 초기화하지 마세요. 데이터 공백 뒤의 돌파처럼 보이는 움직임에는 문서화된 복구 정책을 확인해야 합니다. 관측 가격이 100 위아래를 오가면 실제로 여러 번 돌파할 수도 있습니다. 쿨다운은 빈도를 제한할 뿐 신호의 질을 입증하지 않습니다.
시간 초과는 주문 실패의 증거가 아닙니다. Binance는 불명확한 주문 상태를 조회하도록 안내합니다. SharkRule에서는 결과가 해결되지 않은 Binance 주문이 추가 Binance 주문 전송을 막아야 합니다. 확인하는 동안 원래 주문과 지출 기록을 유지하세요. 시간이 지났다는 이유로 이 차단이 해제되지는 않습니다.
반복 정책을 확인하는 체크리스트
- 거래소, 거래쌍, 입력값, 비교 방식, 평가 시점을 적습니다. 같은 값과 첫 관측을 어떻게 처리하는지 정하고 지속 조건인지 새로운 돌파인지 구분합니다.
- 대기 범위가 이 규칙, 이 거래쌍, 계정 전체 중 무엇인지 확인합니다. 시작 사건, 시간 단위, 경계값을 기록하고 다른 규칙도 같은 타이머를 쓴다고 가정하지 않습니다.
- 대기 중 신호를 버릴지, 유효 기간과 재검사를 정해 보관할지 확인합니다. 차단된 신호가 대기를 다시 시작하는지도 적습니다.
- 최대 진입 횟수, 누적 예산, 비용, 미결 약정을 나열합니다. 각 카운터가 언제 초기화되는지 확인합니다. 재시작, 매도, 타이머 종료가 자동으로 지출 권한을 늘리지는 않습니다.
- 지속적으로 참인 조건, 기준선 아래로 돌아온 값, 대기 중 돌파와 대기 후 돌파를 종이에 재현합니다. 중복 사건, 데이터 공백, 소진된 예산도 넣습니다.
- 예상 판단과 확인 가능한 활동 기록을 비교합니다. 차단된 후보, 전송 허용, 거래소 접수, 체결을 나누고 확인하지 못한 결과는 미해결로 남겨 둡니다.
확인할 수 있는 범위와 다음 단계
이 연습은 작성한 규칙이 자신의 반복 정책과 일치하는지 확인합니다. 수익을 내는 대기 시간을 찾는 작업이 아닙니다. 기다리는 사이 움직임을 놓칠 수 있고 반복 행동으로 수수료와 보유 위험이 늘 수 있습니다. 손실, 슬리피지, 부분 체결, 미체결, 거래소 장애는 여전히 가능합니다. 모의투자로 실제 체결을 보장할 수 없습니다.
출처에 있는 한국어 SharkRule 바이낸스 안내에서 직접 시작하기 전 확인하는 매수당 금액과 최대 매수 횟수를 살펴보세요. 해당 안내는 사용자 지정 규칙의 쿨다운도 설명합니다. 내 Shark에 실제로 표시되는 제어 항목을 이 기록과 비교하세요. 그 안내만으로 이 예제의 타이머 시작점, 돌파 정책, 차단 신호 처리 방식이 제품 동작이라고 볼 수는 없습니다.
사용 가능한 규칙과 이용 자격은 현재 대시보드, 계정, 지역에 따라 달라집니다. 거래소를 연결하는 것만으로 거래가 시작되지 않습니다. SharkRule은 Binance와 제휴하거나 공식 지원을 받는 서비스가 아닌 독립 소프트웨어입니다. 금융·투자 자문을 제공하지 않으며 이 글은 자산, 배분, 포지션 규모, 거래를 추천하지 않습니다.
자주 묻는 질문
쿨다운이면 신호당 한 번만 거래하나요?
그 자체로는 그렇지 않습니다. 쿨다운은 정해진 정책에 따른 대기 조건입니다. 지속 조건은 대기 후 다시 행동을 허용할 수 있지만 돌파 규칙은 새 전환이 필요합니다. 총횟수는 별도의 진입 한도가 제한합니다.
대기 중 발생한 돌파는 어떻게 되나요?
문서에 적힌 정책에 달려 있습니다. 이 예제는 돌파를 버리면서 직전 가격은 갱신합니다. 신호를 보관하는 도구라면 유효 기간과 재검사가 필요합니다. 나중에 자동 실행된다고 가정하지 마세요.
일시 정지하고 다시 시작하면 예산이 새로 생기나요?
그렇게 가정하면 안 됩니다. 저장된 횟수, 열린 주문, 누적 지출 약정을 확인하세요. 새 세션은 남은 예산의 증거가 아닙니다. 재시작 처리나 이전 주문 결과를 모른다면 확인할 정보가 남아 있는 것입니다.
2분이 적절한 쿨다운인가요?
120초는 계산을 보여 주기 위한 값일 뿐 추천이 아닙니다. 행동이 적다고 결과가 더 좋다는 증거도 아닙니다. 먼저 규칙의 입력, 대기 시작 사건, 계속 적용되는 한도를 확인하세요.
공식 자료와 출처
링크된 공식 문서를 바탕으로 AI의 도움을 받아 작성했습니다. 예시는 가상 상황이며 실제 계정 테스트나 수익률 비교를 수행하지 않았습니다.
- SharkRule: 바이낸스 규칙 검토, 매수 금액과 최대 횟수
https://sharkrule.com/ko/binance-trading-bot/ - TradingView: 비교 조건과 알림 발생 빈도
https://kr.tradingview.com/support/solutions/43000763312/ - Freqtrade: 포지션 종료 후 거래쌍별 CooldownPeriod
https://www.freqtrade.io/en/stable/plugins/#cooldown-period - Binance Spot: 시간 초과와 알 수 없는 주문 실행 상태
https://developers.binance.com/en/docs/products/spot/rest-api