결론부터 말씀드리면, 백테스트가 아무리 좋아도 실전은 깨집니다. 백테스트에는 없고 실전에만 있는 변수들 때문입니다. 그 간극을 좁히는 능력이 곧 실력입니다.
제 첫 봇의 백테스트는 그럴듯했습니다. 그런데 실계좌에 올리자 자꾸 끊기고 손실이 났습니다. 코드가 틀려서가 아니라, 실전 환경을 견디지 못하는 설계였기 때문입니다.
백테스트가 못 보는 것들
| 요소 | 백테스트 | 실전 |
|---|---|---|
| 체결가 | 이상적 가격 | 슬리피지·미체결 |
| 통신 | 항상 연결 | 수시로 끊김 |
| 호출 한도 | 제한 없음 | 초과 시 봇 정지 |
| 예외 상황 | 거의 없음 | 수시 발생 |
실제로 나를 무너뜨린 실전 변수
- 호출 한도 초과(429): 종목을 자주 조회하다 한도를 넘겨 봇이 그대로 멈췄습니다. 도구를 바꿔도 이 문제는 따라왔습니다.
- 급락장 끊김: 거래 정지 구간에서 통신이 끊겨 관리 공백이 생겼습니다.
- 상태 소실: 봇이 죽으면 무엇을 들고 있었는지조차 잊었습니다.
간극을 좁히는 방법
실전은 ‘전략’보다 ‘방어 코드’가 계좌를 지킵니다. 제가 배운 최소한의 방어는 이렇습니다.
- 모든 외부 호출을 예외 처리로 감싸고, 전송 타임아웃을 넉넉히 둔다.
- 같은 데이터를 반복 조회하지 않도록 캐싱하고, 조회 속도를 조절해 한도를 넘기지 않는다.
- 재시작 시 보유 포지션을 다시 붙잡아 관리를 이어가게 한다.
- 실계좌 전에 모의투자로 실전 환경에서 충분히 관찰한다.
슬리피지가 수익을 갉아먹는 방식
백테스트는 원하는 가격에 즉시 체결된다고 가정합니다. 하지만 실전에서는 주문을 낸 순간과 체결되는 순간 사이에 가격이 움직입니다. 이 차이가 슬리피지입니다. 한두 번은 사소해 보여도, 하루에 수십 번 매매하는 단타 봇에서는 이 작은 손실이 쌓여 백테스트의 기대 수익을 통째로 지워버립니다.
여기에 미체결도 더해집니다. 백테스트에서는 신호가 뜨면 무조건 샀다고 치지만, 실전에서는 원하는 가격에 물량이 없어 못 사거나 일부만 체결됩니다. 이런 어긋남이 쌓이면 실제 성적은 백테스트와 전혀 다른 그림이 됩니다.
내 봇을 무너뜨린 실전 변수 되짚기
제 경우 가장 큰 타격은 호출 한도 초과였습니다. 종목을 자주 조회하다 한도를 넘기면 봇이 그대로 멈췄고, 멈춘 사이 시장은 계속 움직였습니다. 급락장에서는 통신 자체가 끊겨 손절도 익절도 못 하는 공백이 생겼습니다. 백테스트에는 이런 ‘멈춤’이라는 개념이 아예 없습니다.
방어 코드 체크리스트
그래서 실전 봇에는 전략만큼이나 방어 장치가 필요합니다. 제가 뼈저리게 배운 최소 목록은 이렇습니다.
- 모든 외부 호출을 예외 처리로 감싸고, 실패 시 재시도와 로그를 남긴다.
- 같은 데이터를 반복 조회하지 않도록 캐싱하고, 조회 속도를 조절해 한도를 넘기지 않는다.
- 봇이 죽었다 살아나면 보유 포지션을 다시 붙잡아 관리를 이어간다.
- 주문 실패·부분 체결·통신 끊김 각각에 대해 봇이 어떻게 행동할지 미리 정한다.
백테스트는 가설을 세우는 단계이고, 실전은 그 가설이 현실의 마찰을 견디는지 확인하는 단계입니다. 좋은 백테스트 결과는 출발선일 뿐 결승선이 아닙니다.
실전 로그는 거짓말을 하지 않는다
백테스트 성적표는 마음에 드는 구간만 보여주기 쉽지만, 실전 로그는 봇의 민낯을 그대로 기록합니다. 제 두 번째 봇의 알림 채널에는 한 달여간 2,700건이 넘는 메시지가 쌓였는데, 그중 상당수가 에러였습니다. 스캔과 진입, 청산 사이사이에 수백 건의 오류와 재시작이 섞여 있었습니다. 백테스트만 봤다면 결코 알 수 없었을 봇의 실제 상태가, 실전 로그에는 남김없이 드러났습니다.
이 로그를 보며 깨달은 것은, ‘얼마나 벌었나’보다 ‘얼마나 자주 넘어지고 어떻게 일어났나’가 봇의 진짜 실력이라는 점입니다. 넘어지지 않는 봇은 없습니다. 넘어졌을 때 스스로 일어나 관리를 이어가는 봇이 좋은 봇입니다.
그래서 실전 전에 무엇을 준비하나
백테스트와 실전의 간극을 인정하면 준비물이 달라집니다. 화려한 수익 곡선을 좇기보다, 에러가 났을 때 봇이 어떻게 반응하는지를 먼저 설계하게 됩니다. 주문이 실패하면 재시도할지 건너뛸지, 통신이 끊기면 어디까지 기다릴지, 한도에 걸리면 어떻게 속도를 줄일지를 미리 정합니다. 이 준비가 되어 있어야 실전이라는 무대에서 봇이 데뷔할 자격을 갖춥니다.
백테스트가 좋다는 이유로 실전을 서두르는 것은, 리허설 없이 무대에 오르는 것과 같습니다. 좋은 성적표는 자신감을 주지만, 그 자신감이 검증을 건너뛰게 만든다면 오히려 독이 됩니다.
백테스트는 가설이고 실전은 검증입니다. 좋은 백테스트 결과에 취하지 말고, 주문이 실패했을 때·접속이 끊겼을 때 봇이 어떻게 멈추고 알리는지에 더 많은 시간을 쓰십시오. 손실의 크기는 거기서 결정됩니다.
마지막으로 강조하고 싶은 것은, 백테스트를 불신하라는 게 아니라는 점입니다. 백테스트는 여전히 필요한 첫 관문입니다. 다만 그 결과를 ‘가능성’으로 읽되 ‘보장’으로 읽지는 마십시오. 좋은 백테스트는 실전에 나설 자격을 주는 것이지 실전의 성공을 약속하는 게 아닙니다. 그 둘을 구분하는 순간, 실전에서 덜 다칩니다.
답글 남기기