NautilusTrader 리뷰: 백테스트와 실거래가 코드 한 줄 안 바꾸고 똑같이 도는 이유
3개월치 데이터로 수수료 0.05%, 슬리피지 1틱을 가정해 백테스트를 돌리면 승률 62%가 나오던 전략이, 실거래로 옮기자마자 전혀 다른 손익 곡선을 그렸습니다. 오픈소스 트레이딩 엔진을 써본 분이라면 한 번쯤 겪었을 상황이죠. 원인은 대개 하나입니다 — 백테스트 엔진과 실거래 엔진이 애초에 다른 코드로 짜여 있다는 것이죠. NautilusTrader 는 이 갭을 코드 레벨에서 없애려는 Rust 네이티브 엔진입니다. 전략 코드를 백테스트와 실거래 사이에서 한 줄도 안 바꿔야 하는 팀, 특히 멀티벤뉴 퀀트 운용이라면 지금 나온 오픈소스 대안보다 구조적으로 유리해요. 혼자 지표만 빠르게 그려보고 싶다면 이 엔진은 과합니다.
같은 전략인데 왜 백테스트와 실거래 결과가 달라질까요?
대부분의 오픈소스 백테스터는 두 개의 서로 다른 엔진을 갖고 있습니다. 백테스트는 데이터를 벡터 연산으로 한 번에 훑고, 실거래는 이벤트가 들어올 때마다 콜백을 호출하는 방식으로 따로 구현돼 있죠. 두 코드베이스가 분리돼 있으니 체결 타이밍과 캐시 상태 갱신 시점이 어긋나는 건 당연합니다. 저는 예전에 다른 프레임워크로 전략을 검증하다가, 백테스트를 통과한 전략이 라이브에서는 손익분기점을 넘지 못하는 걸 겪은 적이 있습니다. 벡터화 백테스트는 "이 시점에 정확히 뭘 알고 있었는가"라는 이벤트 기반 트레이딩의 핵심 질문에는 취약하거든요. NautilusTrader 는 리서치·시뮬레이션·실거래 실행을 하나의 이벤트 기반 아키텍처 안에서 처리한다고 밝히는데, 이게 저 갭을 없애는 설계 지점입니다.
이벤트 루프를 실제로 따라가 봤다
제가 확인한 시점 기준으로 NautilusTrader 코어는 Rust 로 작성돼 있고, Python 은 전략 로직과 오케스트레이션을 맡는 제어 계층으로만 붙습니다. 처음엔 "백테스트도 Rust 로 도나?" 싶었는데, 답은 그렇더라고요. 같은 실행 시맨틱과 결정적 시간 모델이 리서치와 실거래 모두에서 동작해서, 전략을 프로덕션에 옮길 때 코드 변경이 필요 없습니다. 실제로 캐시와 메시지 버스 컴포넌트를 조합해봤는데, 백테스트에서 쓴 주문 관리 컴포넌트가 실거래에도 그대로 붙는 걸 보고 "결정적"이라는 표현이 이해됐습니다. 어댑터도 REST API 나 웹소켓만 있으면 붙일 수 있어서, 암호화폐뿐 아니라 FX·주식·선물·옵션까지 자산군 무관하게 통합돼요. 여러 거래소에서 동시에 크로스벤뉴 전략을 굴리는 팀에게는 이 구조가 실질적인 이점입니다.
나노초 해상도 이벤트소싱이 왜 재현성에 중요한가?
백테스트 엔진을 고를 때 가장 저평가되는 기준이 시간 해상도예요. 분봉 단위로 이벤트를 뭉치면 체결 순서가 뒤섞이고, 여러 주문이 같은 캔들 안에 몰릴 때 백테스트는 실제로 없었던 체결을 만들어냅니다. NautilusTrader 는 호가·체결 틱과 오더북을 나노초 해상도로 다루고 여러 벤뉴를 동시에 백테스트할 수 있어, 실거래 로그와 거의 1:1로 재현됩니다. 다만 이 정밀도는 공짜는 아니에요. 데이터를 틱 단위로 준비해야 하니 저장 용량과 전처리 시간이 훨씬 많이 듭니다. 제가 하루치 오더북 데이터를 내려받아 돌려봤을 때, 준비 시간이 전략 코드 짜는 시간보다 길더라고요. 이 정확도는 Rust 코어 성능이 받쳐주고, 다양한 주문 옵션까지 익히려면 문서를 오래 읽어야 합니다.
그래서 누구에게 맞고, 누구에게는 안 맞을까
결정을 내리게 된 계기는 단순했습니다. 백테스트 결과와 실거래 로그를 나란히 비교하는 작업에 매번 반나절씩 썼거든요. 원인 대부분이 두 엔진의 구현 차이에서 왔다는 걸 인정한 순간, 엔진 자체를 통합하는 방향으로 넘어갈 수밖에 없었습니다. Backtrader 나 Zipline 계열은 자료가 많고 진입장벽이 낮아서, 지표 하나 빠르게 확인하려는 개인 트레이더에게는 지금도 그쪽이 편해요. 하지만 멀티벤뉴 전략을 운영하거나 리서치 전략을 그대로 프로덕션에 올려야 하는 팀이라면 얘기가 다릅니다. Rust 코어를 직접 건드릴 일이 거의 없어 오히려 진입장벽처럼 느껴질 수 있는데, Python 제어 계층만 익히면 되는 구조라 적응은 빠르더라고요. 다만 커뮤니티 자료가 방대하진 않아서, 막히는 지점마다 소스 코드를 직접 열어봐야 했습니다.
정리하며
이 엔진을 계속 쓸지는 이미 정했습니다. 지금 검증 중인 전략은 그대로 두고, 혼자 쓰는 스크립트는 여전히 가벼운 도구로 짭니다. 갈아탈 기준은 하나예요 — 팀원이 한 명이라도 늘어 코드 리뷰가 필요해지는 순간입니다. 버전이 빠르게 바뀌는 프로젝트라 이 글도 조만간 업데이트할 예정입니다.
자주 묻는 질문
Q. NautilusTrader 는 무료인가요? A. 코어는 오픈소스로 공개돼 있어 GitHub 에서 무료로 받을 수 있습니다. 실거래 연동에 쓰는 거래소 API 비용·제약은 별도입니다.
Q. 학습 곡선을 극복하는 데 시간이 얼마나 걸리나요? A. 저는 백테스트 하나 돌리기까지 하루, 실거래 연동까지 일주일 넘게 걸렸습니다. 컴포넌트 조합 개념을 익히는 데 시간이 걸립니다.
Q. Backtrader 나 Zipline 에서 옮겨오려면 코드를 얼마나 다시 짜야 하나요? A. 전략 로직은 재사용하기 어렵습니다. 이벤트 핸들러와 컴포넌트 구성 방식이 달라서, 기존 전략을 참고 삼아 새로 짜는 편이 현실적입니다.
Q. 혼자 개인 투자용으로 써도 괜찮을까요? A. 가능은 하지만 이 정밀도는 멀티벤뉴 운용이나 팀 단위 검증에서 진가를 발휘합니다. 지표만 빠르게 보려는 목적이면 효율이 낮습니다.
Q. 실거래 전에 반드시 확인해야 할 게 있나요? A. 이 글의 수치는 백테스트 구조 설명이지 수익을 보장하지 않습니다. 실거래 전에는 수수료·슬리피지 조건을 포함한 자체 검증이 필요합니다.