“알고리즘 매매”는 규칙을 점검하는 스프레드시트부터 주문을 라우팅하고 체결을 대사하는 소프트웨어까지 다양한 의미로 쓰일 수 있습니다. 이 명칭만으로는 어느 쪽이 작동 중인지 알 수 없습니다. 봇을 평가하거나 프로토타입을 만들기 전에, 시장 관측과 포지션 확정 사이에서 벌어지는 일을 추적해 보세요.
리서치와 주문 실행을 분리하세요
리서치 명세부터 시작하세요. 시장과 상품, 데이터 출처, 타임프레임, 각 결정 시점에 이용 가능한 입력값, 진입 및 청산 조건, 포지션 크기 규칙, 비용 가정, 벤치마크, 그리고 테스트를 결론 없게 만들 조건을 정합니다. 명세와 데이터셋의 버전을 관리하세요. 백테스트는 다른 사람이 검토할 수 있는 기록을 남겨야 하며, 모델상 체결로 이어지지 않은 신호도 포함해야 합니다.
그런 다음 세 가지 운영 상태를 구분하세요.
| 상태 | 입증할 수 있는 것 | 입증할 수 없는 것 |
|---|---|---|
| 과거 시뮬레이션 | 명시된 규칙이 선택한 과거 데이터와 체결 가정에서 어떻게 작동하는지 | 데이터가 완전한지, 미래 결과가 표본과 비슷할지 |
| 모의 관측 | 관측 기간 동안 프로세스가 가상의 결정을 어떻게 기록하는지 | 주문이 거래소에 도달하거나 모델링된 체결을 받을 수 있는지 |
| 실거래 주문 경로 | 인증된 거래소 확인, 체결, 수수료, 계정 기록이 무엇을 보여주는지 | 전략에 지속적인 우위가 있는지, 특정 개인에게 적합한지 |
소프트웨어 테스트가 성공해도 그것은 테스트한 동작만을 검증합니다. 거래소 계정, API 권한, 운영 환경의 시크릿 저장소, 실제 주문까지 검증하지는 않습니다.
전략보다 통제 경계를 먼저 설계하세요
시스템이 실제 주문을 제출할 수 있다면, 그 운영 경로를 별도의 엔지니어링 문제로 다루세요. 신호를 사용하기 전에 데이터 최신성과 상품 식별 정보를 확인하세요. 요청을 보내기 전에 최대 주문, 노출, 최대 손실 한도를 적용하세요. 거래소가 지원하는 경우 전송 전에 고유한 결정 참조와 클라이언트 주문 참조를 저장하세요. 이 참조는 불확실한 요청을 조회하고 대사하는 데 도움이 되지만, 모든 거래소에서 중복 제출을 안전하게 만들어 주지는 않습니다. 응답을 받은 후에는 주문과 포지션 상태를 거래소 기록과 대사하세요. HTTP 요청이 성공한 것과 체결된 것은 다릅니다.
어떤 부분이든 불확실할 때 시스템이 무엇을 하는지 정의하세요. 오래된 가격, 잘못된 수량, 거부된 주문, 부분 체결, 연결 끊김, 알 수 없는 포지션은 상태를 다시 확인할 때까지 새로운 리스크 감수를 중단해야 합니다. 킬 스위치는 명확히 테스트된 효과, 담당자, 복구 절차를 갖춰야 합니다. 스탑 주문 자체는 체결 가격을 보장하지 않으며 거래소 규칙에 따른 청산을 막지도 못합니다.
SEC의 Rule 15c3-5 가이드는 미국 증권 시장의 해당 브로커-딜러를 대상으로 시장 접근 리스크 통제를 설명하며, 주문 전 임계값과 정기 검토를 포함합니다. 이 규칙은 모든 개인 크립토 스크립트에 부과되는 일반 체크리스트가 아니며, 모든 관할권의 크립토 법률을 진술하는 것도 아닙니다. 이 제한적인 적용 범위는 시장 접근 통제를 어떻게 배정하고 문서화할 수 있는지 보여주는 유용한 사례입니다. 시스템을 만들거나 운영하는 사람은 자신에게 실제로 적용되는 규칙을 별도로 확인해야 합니다.
정상 경로만이 아니라 실패를 짚어 보세요
전략 프로세스가 주문을 제출했는데 응답이 도착하기 전에 네트워크 시간이 초과된다고 가정해 보세요. 클라이언트가 응답을 보지 못해도 그 요청은 매칭 엔진에 도달했을 수 있습니다. Binance의 Spot REST 문서는 특정 시간 초과와 일부 서버 오류를 실행 상태 불명(execution-status unknown)으로 명시하고, 사용자 스트림을 확인하거나 주문 상태를 조회하라고 안내합니다. Hyperliquid는 클라이언트 주문 ID와 주문 ID 또는 클라이언트 ID로 주문 상태를 조회하는 방법을 문서화합니다. 이는 거래소별 도구이며 보편적인 정확히 한 번 실행 보장이 아닙니다. 거래소의 현재 계약을 확인하고, 첫 응답이 유실되었다는 이유만으로 두 번째 주문을 보내지 마세요. Binance Spot REST API 안내, Hyperliquid 거래소 엔드포인트, Hyperliquid 주문 상태 조회를 참고하세요.
작은 대사 프로토콜을 사용하고 모든 상태 변경의 근거를 기록하세요.
| 상황 | 거래소 근거와 대조 | 운영 결정 |
|---|---|---|
| 요청 시간 초과 또는 모호한 서버 오류 반환 | 지원되는 경우 원래 클라이언트 ID로 조회하고 주문 상태와 체결을 검사 | 결정을 미해결로 유지하고, 노출이 불명확한 동안 새 주문으로 재시도하지 않음 |
| 주문이 부분 체결되었거나 취소가 대기 중 | 개별 체결, 수수료, 남은 미체결 수량을 합산한 뒤 취소 후 다시 확인 | 다음 조치의 크기는 요청 수량이 아니라 대사된 노출을 기준으로 산정 |
| 프로세스 또는 프라이빗 스트림 재연결 | 미체결 주문, 포지션, 최근 체결을 새로 고치고, 상태가 일치한 뒤에만 이벤트 처리 재개 | 격차를 대사할 수 없으면 새로운 리스크를 일시 중단 |
| 거래소가 레이트 리밋 응답 반환 | 해당 거래소의 백오프 지침을 따르고 현재 주문/계정 상태를 검사 | 빠른 재시도를 중단하고, 반복 요청은 장애를 연장할 수 있음 |
예를 들어 Binance의 Spot REST 안내는 429 응답이 레이트 리밋 초과를 의미하며 클라이언트가 백오프해야 한다고 밝히고, 위반이 계속되면 IP 차단으로 이어질 수 있다고 경고합니다. 이는 Binance Spot의 동작이며 다른 API가 같은 코드를 사용한다는 보장은 아닙니다. Hyperliquid의 거래소 문서는 자체적인 주문 유효 조건을 정의합니다. ALO는 즉시 유동성을 취하는 대신 취소하고, IOC는 미체결 잔량을 취소합니다. 이러한 규칙은 주문 결과에 영향을 주므로, 같은 전략 의도라도 거래소 지침이 다르면 남는 포지션이 달라질 수 있습니다. 리허설에서 사용한 정확한 거래소, 상품, API 버전, 주문 플래그를 문서화하세요.
실행 컨트롤러를 어떤 배포에도 사용할 준비가 되었다고 판단하기 전에, 비운영 환경에서 이러한 실패 사례를 의도적으로 연습하세요. 오래된 호가, 접수 후 유실된 응답, 취소 중 부분 체결, 프라이빗 스트림 연결 끊김, 레이트 리밋 응답을 주입하세요. 각 사례에서 시스템이 알 수 없는 상태로 인해 노출을 늘리지 않는지, 남은 수량을 놓치지 않는지, 운영자가 기록된 근거를 바탕으로 중지하고 검사하고 재개할 수 있는지 확인하세요. 정상 경로의 모의 세션만으로는 복구를 테스트할 수 없습니다.
선물이나 레버리지 상품의 경우 통제 경계는 계정 리스크와도 만납니다. CFTC의 가상통화 선물 권고는 논의하는 선물 맥락에서 레버리지가 손실을 증폭시키고 추가 증거금이나 청산으로 이어질 수 있다고 밝힙니다.
SuperQuant의 실제 경계
SuperQuant는 합성으로 묶인 과거 데이터를 사용하는 로컬 과거 리서치 엔진과 수동 모의 실습 워크플로를 제공합니다. 거래소 주문을 제출하거나 사용자의 거래 계정에 연결하지 않습니다. 자동 매매 봇으로 설명하지 마세요. 리서치 측면을 살펴보려면 추세 추종 예시로 시작하고, 백테스트 워크플로를 따라가며, 재량 매매와 시스템 매매 비교를 확인하세요. 이 글은 아키텍처 가이드이며 실거래 실행 조언이나 전략 추천이 아닙니다.