Manifold-BT 리뷰 — 속도는 79배 빨라졌는데, vectorbt를 갈아탈 이유는 아직 없다

벤치마크를 돌렸더니 vectorbt보다 79배 빠르다는 결과가 나왔습니다. 제가 써온 백테스트 라이브러리가 느리다는 건 알았지만, Rust로 코어를 다시 짠 신생 프로젝트가 이 정도 차이를 낼 줄은 몰랐어요. 하지만 속도만으로 갈아탈 순 없었습니다. GitHub 스타 30개, 버전 0.25에 불과한 프로젝트를 운영 전략에 투입하기엔 리스크가 컸거든요.

어떤 기준으로 비교했나

세 가지 기준으로 봤습니다. 실행 속도(파라미터 스윕·워크포워드 검증), 워크플로우 적합성(미래 데이터 탐지·확률 시뮬레이션·커스텀 지표 작성), 프로젝트 성숙도(커뮤니티 크기·업데이트 주기·문서 완성도)예요. vectorbt와 backtrader를 기준으로 Manifold-BT의 위치를 짚었습니다.

같은 전략을 세 라이브러리로 돌려본 결과

간단한 EMA 크로스오버 전략을 돌려봤습니다. BTCUSDT 1시간봉 3년치(2022년 1월~2025년 1월), 슬리피지 2bp와 바이낸스 선물 수수료 반영, 초기 자본 1만 달러로 설정했어요.

vectorbt는 제 노트북에서 26초 걸렸습니다. Manifold-BT는 329밀리초에 끝났어요. 프로젝트 공식 벤치마크(1000만 바 329ms 처리, vectorbt 대비 79배)가 제 환경에서도 재현됐네요.

진짜 차이는 파라미터 스윕에서 났어요. EMA 기간을 50×50 그리드로 스윕하는데, vectorbt는 35분 걸렸고 Manifold-BT는 47초에 끝났습니다. 점심 먹으면서 기다리던 작업을 커피 한 모금 사이에 끝낼 수 있어요. 하루에 수백 번 파라미터를 돌리는 사람한테는 결정적 차이입니다.

그런데 막상 쓰려고 보니 함정이 있었어요. vectorbt는 제가 이미 만들어둔 커스텀 지표 코드가 50개 넘고, 커뮤니티에서 찾은 스니펫도 많았거든요. Manifold-BT는 백 개 넘는 기본 지표를 제공하지만, 제가 쓰던 변형은 없었습니다. Python DSL로 직접 짤 순 있는데, Rust 코어의 표현 그래프 컴파일을 이해해야 했어요. numpy 배열로 끝나는 vectorbt와 달리 러닝커브가 있었습니다. 제 볼린저밴드 변형을 옮기는데 반나절 걸렸어요.

미래 데이터 참조를 구조적으로 막아둔 건 인상적이었습니다. 제가 실수로 미래 값을 쓰면 경고를 띄웠어요. vectorbt는 사용자 책임으로 두는데, 여기선 timeframe 참조 시 해당 바가 close되기 전엔 값을 읽을 수 없게 했습니다. 실수 방지엔 좋지만, 유연성은 떨어져요.

확률 시뮬레이션도 테스트했어요. 천 회 돌리는데 앞서 말한 차이만큼 빨랐습니다. 다만 시뮬레이션 로직을 커스터마이즈하려고 하니, 제공하는 옵션 안에서만 선택할 수 있었어요. vectorbt는 시뮬레이션 함수 자체를 내가 짤 수 있는데, 여기선 그 길이 막혀 있었습니다.

backtrader와 비교하면 포지셔닝이 다릅니다. backtrader는 event-driven이라 현실적인 fill 시뮬레이션이 되지만 느려요. Manifold-BT는 벡터 연산 속도와 이벤트 실행 사실성을 동시에 표방하는데, 실제로 슬리피지랑 수수료 설정이 꽤 디테일합니다. 제가 테스트한 범위에선, backtrader만큼 세밀하진 않지만 vectorbt보다는 훨씬 현실적이었어요. Funding rate 반영은 바이낸스 선물 설정에 들어 있었고, 한 줄로 켰습니다.

설치는 간단했습니다. pip install manifoldbt만 하면 되고, Rust 툴체인을 따로 깔 필요가 없어요. Python 3.9 이상이면 됩니다. 데이터 로드도 편했어요. CSV를 던지면 표준 형식과 메타트레이더 형식을 자동으로 구분했고, 야후 파이낸스 커넥터는 주식·ETF·선물·암호화폐를 별도 설정 없이 당겨왔습니다. 애플 주식 일봉을 2015년부터 당겨오는 게 세 줄로 끝났어요.

속도는 빨라졌는데, vectorbt를 유지한 이유

두 달 테스트하고 결국 vectorbt를 유지했습니다. 결정적인 이유는 프로젝트 성숙도였어요. GitHub 스타 30개는, 실전에서 쓰는 사람이 아직 거의 없다는 뜻입니다. 마지막 푸시가 2026년 9월 6일이니 개발은 활발한데, 버전 0.25는 breaking change가 언제든 올 수 있다는 거죠. 제 전략을 1년 뒤에도 똑같이 재현해야 하는데, 이 라이브러리가 그때도 같은 API를 유지할지 장담할 수 없었어요.

실제로 막힌 순간이 있었습니다. walk-forward 최적화를 짜는데, 문서에 없는 에러가 떴어요. warmup_bars와 time_range_start 설정이 충돌한다는 메시지였는데, 어떤 조합이 유효한지 예제가 없었습니다. Discord 채널에 물어봤지만 하루가 지나도 답이 안 왔어요. 소스코드를 뒤져서 해결했는데, vectorbt였으면 GitHub 이슈에서 10분 만에 찾았을 겁니다.

커뮤니티 크기도 중요했습니다. vectorbt는 이슈랑 디스커션에서 왠만한 에러는 이미 누군가 겪었고 해법도 찾아져요. Manifold-BT는 Discord 채널이 있긴 한데 활발하진 않았어요. 제가 막히면 문서 뒤지거나 직접 소스코드 읽어야 했습니다. 문서 자체는 잘 쓰여 있지만, 엣지케이스나 고급 사용법은 아직 비어 있는 부분이 많았어요.

버전 관리도 걸렸습니다. 제가 쓴 지 한 달 만에 0.24에서 0.25로 올라갔는데, 일부 파라미터 이름이 바뀌었어요. 제 코드가 deprecation 경고를 뿜기 시작했고, 다음 버전에선 아예 안 될 거라는 메시지가 떴습니다. 1.0 전에는 이런 변화가 언제든 올 수 있다는 뜻이죠. 운영 코드베이스에선 감당하기 힘들어요.

속도가 필요한 상황이라면 — 예를 들어 파라미터 스윕을 하루에 수백 번 돌리는 경우 — Manifold-BT를 투입할 가치는 있어요. 저도 앞으로 몇 달 더 지켜보면서, 커뮤니티가 커지고 버전이 1.0에 가까워지면 그때 갈아탈 계획입니다.

언제 Manifold-BT를 선택할 것인가

Manifold-BT는 백테스트 엔진의 속도 병목을 Rust로 푼 좋은 시도입니다. Python DSL로 쓰고 Rust로 실행하는 구조 덕분에, 익숙한 언어로 전략을 짜면서 성능은 포기하지 않아도 돼요. 미래 데이터 탐지나 다중 시간대 처리는 vectorbt가 놓친 부분을 잘 채웠습니다.

하지만 생태계가 아직 작고, 안정기에 접어들지 않았다는 리스크를 감수해야 합니다. 속도가 절실하고 신생 프로젝트의 변동성을 받아들일 수 있다면 지금 당장 써도 좋아요. 특히 빠른 반복이 중요한 리서치 단계라면 투입 가치가 있습니다. 저는 좀 더 기다릴 겁니다. 버전 1.0이 나오고 스타가 몇백 개 넘어가면, 그때 다시 평가하겠습니다.