Qlib vs Backtrader vs FinRL-X — 목적별 퀀트 프레임워크 선택 가이드
공개 비교 자료와 제가 직접 돌려본 결과 모두에서 Qlib이 Backtrader보다 속도가 약 10배 빨랐습니다. 같은 팩터 전략 기준 Qlib은 10초대, Backtrader는 2분 이상 걸리더라고요. ML 팩터 리서치가 목적이면 Qlib, 이벤트드리븐 로직을 손으로 배우려면 Backtrader, 백테스트에서 라이브 배포까지 코드 일관성이 중요하면 FinRL-X가 답입니다. 단, Backtrader는 2019년 이후 공식 유지보수가 멈췄고, Qlib은 한국 시장 데이터 전처리가 복잡하며, FinRL-X는 강화학습 러닝커브가 있다는 함정을 먼저 알아야 합니다.
어떤 기준으로 비교했나요?
팩터를 빠르게 반복 테스트하고 실전 배포까지 고려했어요. 평가 기준은 세 가지였습니다. 백테스팅 속도, ML 모델 통합 난이도, 백테스트 코드의 실전 배포 가능성. 수익률보다 워크플로우 적합성을 중시했습니다.
같은 팩터 전략을 돌려보니 드러난 차이
모멘텀과 밸류 팩터를 조합한 단순 전략을 세 프레임워크로 구현해봤어요. Backtrader는 next() 메서드에서 주가·지표를 체크하고 매매하는 이벤트드리븐 구조라 입문자가 로직을 익히기 좋았어요. 하지만 5년 일봉 규모에서 수분이 걸렸고, 2019년 이후 공식 릴리스가 없어 Python 3.12 환경선 의존성 문제가 있었어요. next() 안에서 팩터 계산과 포지션 체크를 함께 하려니 코드가 길어지고, 벡터화 없이 루프를 도는 구조라 종목 수가 늘면 속도가 선형으로 느려졌습니다.
Qlib은 벡터화 엔진으로 같은 작업이 10초대에 끝났어요. 팩터를 Feature 객체로 정의하면 자동 병렬 계산되고, XGBoost·LSTM 래퍼로 ML 파이프라인이 매끄러웠어요. 예를 들어 20일 모멘텀 팩터는 Ref($close, -20) / $close - 1 한 줄로 끝나고, 수백 종목에 동시 적용됐죠. 하지만 한국 데이터는 Qlib 포맷 전처리가 필요했고, 거래일 캘린더까지 직접 만드는 데 주말 하루가 걸렸어요. CSV를 .bin 바이너리로 변환하는 DumpDataAll 스크립트를 돌리고, 공휴일·대체휴일을 반영한 KRX_CALENDAR 파일을 따로 만들어야 했습니다.
FinRL-X는 gym 인터페이스로 백테스트와 라이브를 통일해 코드 수정 없이 배포할 수 있었어요. 상태는 현재 포지션과 최근 N일 가격, 행동은 매수·매도·홀드 비율, 보상은 샤프비율로 설계했는데요. 하지만 이 설계 자체가 전략 로직을 강화학습 문제로 번역하는 작업이라 러닝커브가 있었어요. 하이퍼파라미터 튜닝까지 포함하면 첫 결과까지 며칠이 걸렸습니다.
프레임워크별 핵심 특징 요약:
- Backtrader: 이벤트드리븐 직접 구현 — 로직 학습용으로 적합, 유지보수 중단 리스크와 느린 속도가 약점
- Qlib: ML 팩터 벡터화 엔진 — 대량 스크리닝에 강력, 데이터 전처리 선행 필수
- FinRL-X: gym 인터페이스 통일 — 백테스트→라이브 코드 일관성, 강화학습 러닝커브 감수 필요
비추 케이스를 먼저 보면 선택이 빨라집니다
Backtrader는 프로덕션 배포나 ML 팩터 리서치엔 비추합니다. 유지보수 중단 리스크와 느린 속도 때문이에요. 다만 "이벤트드리븐 백테스팅이 뭔지" 개념을 배우려는 학습용으로는 여전히 좋습니다. 실제로 cerebro.addstrategy()와 broker.setcash() 구조를 손으로 짜보니 백테스트 엔진의 작동 원리가 체감으로 이해됐거든요.
Qlib은 데이터 파이프라인 구축이 갈림길입니다. 포맷 변환 스크립트와 거래일 캘린더를 직접 만들어야 해요. 증권사 API에서 받은 CSV를 Qlib 바이너리로 바꾸는 과정에서 날짜 파싱 오류나 결측치 처리가 막히는 경우가 많았어요. 반면 팩터 수백 개를 빠르게 스크리닝하는 리서치 단계에선 대체 불가였어요. 팩터 10개씩 조합해서 1000개 조합을 테스트하는 작업이 Qlib에선 한 시간에 끝났지만, Backtrader론 하루가 넘게 걸렸을 겁니다.
FinRL-X는 규칙 기반 전략만 쓰려면 오버엔지니어링입니다. 기존 팩터 전략엔 Qlib이나 Backtrader가 단순해요. 대신 백테스트 환경과 실전 배포 코드를 완전히 일치시키고 싶다면 유일한 선택지였습니다. 같은 env.step(action) 코드가 백테스트에선 과거 데이터로, 라이브에선 실시간 데이터로 돌아가니 배포 시 버그가 거의 없었어요.
두 달 쓰다 프레임워크를 바꾼 이유
처음엔 Backtrader로 시작했지만 팩터 조합이 늘면서 속도 병목이 체감됐어요. 하루 20개 조합에 한 시간이 걸렸거든요. 팩터 3개를 각각 3가지 파라미터로 조합하면 27개 케이스인데, 이걸 매일 돌리려니 현실적으로 불가능했어요. 반복 속도를 기준으로 Qlib로 갈아탔고, 전처리 후엔 같은 작업이 5분에 끝났어요. 전처리에 주말 하루를 쓴 게 아깝지 않더라고요.
FinRL-X는 백테스트와 라이브가 같은 인터페이스라 인상적이었지만, 제 전략엔 강화학습이 불필요했어요. 팩터 시그널로 매매하는 규칙 기반 전략이라 굳이 보상 함수를 설계할 이유가 없었죠. 동적 포트폴리오 리밸런싱이나 멀티 에이전트 전략을 실험한다면 다시 고려할 것 같습니다.
지금 제가 쓰는 건 Qlib입니다
결국 Qlib로 정착했어요. 팩터 스크리닝이 주말 이틀에서 서너 시간으로 줄었거든요. 배포는 별도 경량 스크립트로 분리했어요. Qlib로 신호만 생성하고, 실제 주문은 브로커 API로 직접 보내는 구조죠. 신호 생성 부분만 Qlib Workflow로 감싸고, 주문 로직은 Python requests로 REST API를 호출하는 단순한 스크립트로 구현했습니다.
여러분이 팩터 리서치 속도를 우선하면 Qlib, 로직 학습이 목적이면 Backtrader, 코드 일관성이 생명이면 FinRL-X로 가세요. 어느 단계에 시간을 쓸지 먼저 정하면 선택이 명확해집니다.
자주 묻는 질문
Q. Qlib 데이터 전처리 없이 바로 쓸 수 있는 방법은 없나요? A. qlib.data 모듈에 Yahoo Finance 어댑터가 있지만, 한국 시장은 공식 지원 안 됩니다. FinanceDataReader 같은 라이브러리로 데이터를 받아서 DumpDataAll 스크립트로 변환하는 게 현재 최선이에요. 초기 구축 후엔 증분 업데이트만 하면 됩니다.
Q. Backtrader 유지보수 중단 후 대안 포크는 뭐가 있나요? A. backtrader2라는 커뮤니티 포크가 Python 3.10+ 호환성을 일부 개선했지만, 공식 릴리스 수준은 아닙니다. 장기 프로젝트라면 처음부터 Qlib이나 FinRL-X를 고려하세요.
Q. 백테스트 수익률이 실전과 다른 이유는 뭔가요? A. 슬리피지·수수료·체결 지연을 백테스트에 반영 안 했을 가능성이 큽니다. 세 프레임워크 모두 슬리피지 모델을 설정할 수 있지만, 기본값은 0이에요. 실전 거래비용(수수료·세금·호가 스프레드)을 백테스트 조건에 명시적으로 추가해야 합니다.