
얼마 전 자동 매매 수익률이 월 8%라는 화면을 봤다. 제일 먼저 찾은 건 매매 횟수와 수수료였다. 7년 동안 거래소와 온체인 데이터를 같이 보다 보니, 수익 곡선보다 그 곡선을 만든 거래 내역을 먼저 보게 된다. 코인 자동 매매 프로그램도 주문을 빠르게 넣는 기능보다 비용과 손실을 통제하는 기능이 더 중요하다.
1. 왕복 거래비용이 기대 수익을 넘는가
프로그램 설명에 적힌 수익률은 수수료를 빼기 전인지부터 확인한다. 예를 들어 매수와 매도 수수료가 각각 0.05%라면 왕복 수수료만 0.10%다. 여기에 매수·매도 때 예상보다 불리한 가격으로 체결되는 비용이 각각 0.05%씩 붙으면 한 번 거래할 때 총 0.20%가 나간다. 거래당 평균 이익이 0.15%인 전략은 승률이 높아 보여도 비용을 감당하기 어렵다.
실제 수수료는 거래소, 거래량 등급, 주문 방식에 따라 달라진다. 그래서 홍보 자료의 기본값을 그대로 쓰지 않는다. 내 계정의 체결 내역으로 수수료율과 평균 체결 가격을 계산해야 한다. 하루에 여러 번 사고파는 전략일수록 이 차이가 누적된다.
2. 주문 금액을 호가 잔량이 받아낼 수 있는가
백테스트는 원하는 가격에 전량 체결됐다고 가정하기 쉽다. 실제 시장에서는 주문이 호가창을 밀어 올리거나 내린다. 매도 1호가부터 세 번째 호가까지 쌓인 물량이 300만 원인데 1,000만 원을 시장가로 사면, 마지막 체결 가격은 첫 화면의 가격보다 높아질 수 있다. 특히 거래량이 적은 알트코인은 신호가 맞아도 체결 비용 때문에 손익이 뒤집힌다.
나는 최근 거래량과 함께 매수·매도 호가의 깊이, 스프레드, 시간대별 체결 금액을 본다. 프로그램에는 주문을 나누는 기능과 미체결 주문을 취소하는 규칙이 있어야 한다. 급등 직후처럼 호가가 얇아지는 구간에서는 주문 금액을 줄이거나 거래를 건너뛰는 편이 낫다.
3. 온체인 신호가 주문 전에 확인되는가
거래소 유입량이 늘면 매도 압력을 의심할 수는 있다. 다만 입금 주소를 거래소 지갑으로 잘못 분류했거나, 거래소 내부 지갑 이동을 유입으로 잡았다면 신호의 뜻이 달라진다. 큰 이체 한 건만 보고 자동으로 매도하게 만들기에는 데이터가 거칠다.
온체인 지표를 쓸 때는 지표가 기록된 시각과 프로그램이 그 값을 받은 시각을 따로 남긴다. 과거 데이터에는 나중에 수정된 지갑 분류가 반영될 수도 있다. 그 상태로 백테스트를 하면 당시에는 알 수 없었던 정보를 이용한 셈이다. 거래소 순유입, 스테이블코인 이동, 미결제약정 같은 신호를 묶더라도 실제 주문 시점에 확인 가능했던 값만 써야 한다.
4. 최대 손실 폭과 연속 손실을 보여주는가
연 수익률 30%라는 숫자만으로는 버틸 수 있는 전략인지 판단하기 어렵다. 같은 수익률이라도 중간에 계좌가 10% 내려간 전략과 50% 내려간 전략은 전혀 다르다. 50% 손실을 회복하려면 남은 자금으로 100% 수익을 내야 한다.
최소한 최대 낙폭, 최장 연속 손실, 월별 손익, 거래당 손익 분포를 본다. 상승장 한 구간에서만 잘 맞은 조건도 의심한다. 과거 데이터를 조정용 구간과 검증용 구간으로 나누고, 수수료와 불리한 체결 가격을 반영한 뒤에도 성과가 남는지 확인해야 한다. 백테스트의 높은 수익률이 다음 달 수익을 보장하지는 않는다.
5. 한 번의 오류로 얼마까지 잃을 수 있는가
자동 매매에서는 전략 오류보다 운영 오류가 더 빨리 계좌를 흔들 때가 있다. 주문 요청 뒤 응답이 늦어 같은 주문을 다시 보내거나, 연결이 끊긴 동안 미체결 주문이 남는 식이다. 거래소 API에는 요청 횟수 제한도 있다. 업비트와 바이낸스 개발 문서 모두 API 권한과 요청 제한을 별도로 안내한다.
실거래 전에는 한 종목당 투자 한도, 하루 손실 한도, 주문 횟수 한도를 숫자로 정한다. 예를 들어 총자산 1,000만 원 계좌라면 첫 시험에서 주문당 10만 원, 하루 손실 5만 원처럼 작게 시작해 실제 체결 기록을 모을 수 있다. 이 수치는 권장 비율이 아니라 오류가 났을 때 감당할 수 있는 금액을 정하는 예시다. API 키에는 주문에 필요한 권한만 주고 출금 권한은 제외한다. 허용 IP 설정과 키 보관 방식도 확인한다.
내가 프로그램을 계속 쓸지 판단하는 시점은 수익 화면을 볼 때가 아니다. 몇 주간 쌓인 실제 주문 기록에서 비용을 뺀 손익이 남고, 데이터 지연과 주문 오류가 정해 둔 한도 안에 있는지 확인할 때다. 숫자가 아직 부족하다면 거래 규모를 키울 이유도 없다.
