Crypto Perpetual Trading: 라이브 전에 전략을 백테스트하기

짧은 답

Crypto perpetual trading은 레버리지보다 테스트 가능한 규칙에서 시작해야 합니다.

무기한 계약 시장, 가격 또는 펀딩 신호, 리스크 경계, 리뷰 창을 정의하세요. 그 정확한 규칙을 과거 데이터로 백테스트하고, 모든 트리거를 검사하고, 첫 라이브 버전은 알림으로 운영한 뒤, 지원되는 경우에만 통제된 실행을 고려하세요.

crypto perpetual trading이란?

암호화폐 무기한 계약은 만기일이 없는 futures와 비슷한 계약입니다. 트레이더는 보통 레버리지로 long 또는 short 노출을 표현하고, funding payment는 perpetual 가격이 기초 시장에 가깝게 유지되도록 돕습니다.

이 구조는 유용한 전략 입력을 제공합니다.

• 펀딩비는 long 또는 short 중 어느 쪽이 노출 유지를 위해 비용을 내는지 보여줍니다.
• Open interest는 포지셔닝이 늘어나는지 줄어드는지 보여줍니다.
• 가격 행동은 시장이 가설을 확인하는지 거부하는지 보여줍니다.
• 청산 구간과 변동성은 리스크가 빠르게 바뀔 수 있는 지점을 보여줍니다.

위험한 점은 같은 입력이 실시간에서는 명확해 보이지만 역사적으로는 취약한 전략을 만들 수 있다는 것입니다. 백테스트는 그럴듯한 아이디어와 모니터링할 가치가 있는 규칙 사이의 점검 지점입니다.

백테스팅 워크플로

| 단계 | 정의할 것 | 중요한 이유 | | --- | --- | --- | | 1. 시장 | 자산, venue, 계약 | Hyperliquid의 BTC-PERP와 다른 venue의 ETH-PERP는 다릅니다 | | 2. 방향 | Long, short, neutral, 또는 alert-only | 규칙에는 명시적 의도가 필요합니다 | | 3. 신호 | 펀딩, 가격, open interest, 변동성, 또는 조합 | 무기한 전략은 신호가 모호할 때 실패하기 쉽습니다 | | 4. 임계값 | 정확한 숫자 또는 분위수 | “높은 펀딩”에는 측정 가능한 경계가 필요합니다 | | 5. 쿨다운 | 트리거 사이 최소 시간 | 하나의 crowded setup이 반복 발동하지 않게 합니다 | | 6. 리뷰 창 | 1시간, 4시간, 24시간 또는 커스텀 기간 | 각 트리거 이후 무슨 일이 있었는지 보여줍니다 | | 7. 활성화 경로 | 알림, 프리뷰, 확인, 또는 지원 시 실행 | 리서치와 라이브 리스크를 분리합니다 |

예시 프롬프트

유용한 perpetual trading 프롬프트는 구체적입니다.

Hyperliquid의 BTC-PERP를 백테스트해줘. 펀딩이 음수이고, BTC가 60분 동안 최소 0.5% 상승하며, open interest가 증가할 때 신호를 발생시켜줘. 1시간 쿨다운을 사용하고, 활성화 전 모든 트리거와 1시간, 4시간, 24시간 이후 수익률을 보여줘.

이 프롬프트는 시스템에 다음을 제공합니다.

• 시장과 venue.
• 펀딩 조건.
• 가격 확인.
• 포지셔닝 필터.
• 쿨다운.
• 리뷰 기간.
• 명확한 “아직 활성화하지 않음” 경계.

결과는 블랙박스 거래 제안이 아니라 검사 가능한 규칙과 트리거 기록이어야 합니다.

무기한 시장에서 중요한 신호

무기한 시장은 가격만 제공하지 않습니다. 가장 유용한 입력은 보통 조합입니다.

• 펀딩과 가격 확인: 음수 펀딩과 가격 강세는 갇힌 short을 가리킬 수 있습니다.
• 펀딩과 실패한 가격 행동: 극단적 양수 펀딩과 실패한 돌파는 crowded long을 드러낼 수 있습니다.
• Open interest와 변동성: 큰 움직임 속에서 open interest가 증가하면 단순 drift와 실제 참여를 구분할 수 있습니다.
• 쿨다운과 체제 필터: 같은 시간대 반복 트리거는 규칙의 실제 기회 수를 과장하는 경우가 많습니다.

시스템에 “perp를 잘 거래해줘”라고 묻지 마세요. 하나의 정확한 행동을 테스트하게 하세요.

라이브 전에 검사할 것

라이브 알림이나 실행 전에 다음을 검토하세요.

• 쿨다운 이후 규칙이 몇 번 발동했는지.
• 수익이 하나의 시장 이벤트에 집중되어 있는지.
• 수수료, 슬리피지, 펀딩 지급이 결과를 지우는지.
• 반대 규칙이 더 나았는지.
• 더 단순한 버전도 비슷하게 작동하는지.
• 트리거 이후 최악의 역사적 움직임.
• 변동성이 큰 세션에서 규칙이 얼마나 자주 발동했는지.
• 모든 조건에 라이브 데이터 소스가 있는지.

좋은 perpetual 전략은 백테스트에서 수익이 나는 것만으로 충분하지 않습니다. 실패할 때도 이해 가능해야 합니다.

주문보다 알림으로 시작

첫 라이브 버전은 테스트 조건이 발동했을 때 알려주는 형태여야 합니다.

알림 단계는 백테스트가 답할 수 없는 질문에 답합니다.

• 규칙이 가설과 맞는 시점에 발동했나요?
• 예상한 setup을 놓쳤나요?
• 라이브 venue 데이터가 과거 테스트와 일치했나요?
• 시장 맥락을 본 뒤에도 신호가 여전히 행동 가능했나요?

알림이 합리적으로 동작한 뒤에만 실행 통제를 워크플로에 넣으세요.

Stingray가 맞는 지점

Stingray는 perpetual trading thesis를 테스트된 워크플로로 바꾸는 경로를 위해 만들어졌습니다. 아이디어를 자연어로 설명하면 Stingray가 typed rule로 바꾸고, 백테스트하고, 트리거 기록을 보여주고, 같은 조건을 알림으로 모니터링합니다.

구체적인 펀딩비 예시는 한 문장으로 펀딩비 규칙 백테스트하기를 읽어보세요. 더 넓은 노코드 흐름은 코드 없이 온체인 트레이딩 전략 자동화하기를 참고하세요.

결론

Crypto perpetual trading은 정밀함에는 보상하고 모호한 자동화에는 벌을 줍니다.

라이브 전에 계약, 펀딩 또는 가격 신호, 쿨다운, 리스크 경계, 리뷰 창을 정의하세요. 정확한 규칙을 백테스트하고 트리거를 검사한 뒤, 어떤 실행 경로보다 먼저 알림으로 시작하세요.

다음 글:

• 한 문장으로 펀딩비 규칙 백테스트하기
• Whale Feed 전략: Open Interest 다이버전스 활용법
• 코드 없이 온체인 트레이딩 전략 자동화하기