Zipline vs Lean — 로컬 백테스트 엔진 어느 쪽이 나을까?
Zipline ingest-data를 돌렸더니 30분째 멈춰 있었습니다. Lean은 5분 만에 끝났는데 말이죠. 로컬 백테스트 엔진 둘을 6주 돌려본 결론은 명확해요. 파이썬에 익숙하고 단순 전략이면 Zipline-Reloaded, C# 괜찮고 실전 연결까지 보면 Lean입니다.
무엇을 기준으로 비교했나요?
제 환경은 우분투 22.04, 파이썬 3.10입니다. 미국 주식 일봉 5년치 백테스트를 기준으로 삼았어요. 평가 기준은 세 가지로 좁혔습니다. 설치부터 첫 백테스트까지 걸린 시간, 같은 전략을 돌렸을 때 속도 차이, 그리고 실전 브로커 연결 가능성이에요.
Quantopian이 문을 닫은 뒤 커뮤니티가 이어받은 Zipline-Reloaded와, 클라우드 없이도 돌아가는 QuantConnect Lean을 놓고 고민했습니다. 둘 다 로컬 독립성을 내세우지만 실제론 차이가 컸어요.
퀀트 자동화를 시작하는 개인 투자자 입장에서 가장 먼저 부딪히는 건 환경 구축입니다. 파이썬 의존성 지옥을 겪을지, 닷넷 SDK를 새로 배울지 선택해야 하거든요.
설치 단계에서 이미 갈립니다
Zipline-Reloaded는 pip install zipline-reloaded 한 줄이면 끝입니다. 다만 파이썬 3.10 이상에서 TA-Lib 의존성 에러가 튀어나왔어요. conda로 갈아타니 해결됐지만 그 과정에서 30분을 썼습니다.
Lean은 dotnet SDK 6.0 설치가 선행 조건이에요. apt install dotnet-sdk-6.0 후 Lean CLI를 받았는데, 여기까진 10분 정도였어요. 문제는 데이터였습니다.
Zipline은 zipline ingest -b quandl 명령으로 Quandl Wiki 데이터를 받습니다. 5년치 미국 주식이 30분 걸렸고 디스크는 2.3GB 차지했어요. Lean은 QuantConnect 클라우드 데이터를 로컬에 내려받는 구조인데, lean data download --dataset us-equity --resolution daily 명령이 5분 만에 1.8GB를 받아왔습니다.
속도 차이는 압축 방식 때문이었어요. Lean은 데이터를 ZIP으로 미리 묶어 두고, Zipline은 CSV를 런타임에 파싱합니다. 초기 적재는 Lean이 빨랐지만, Zipline은 한 번 받으면 재사용이 쉬웠어요.
같은 전략을 돌려봤더니
20일 이동평균 돌파 전략을 양쪽에 심었습니다. Zipline 코드는 이렇게 시작해요.
from zipline import run_algorithm
from zipline.api import order_target_percent, symbol
def initialize(context):
context.asset = symbol('AAPL')
def handle_data(context, data):
price = data.current(context.asset, 'price')
ma20 = data.history(context.asset, 'price', 20, '1d').mean()
if price > ma20:
order_target_percent(context.asset, 1.0)Lean은 C#이라 구조가 다릅니다.
public class MomentumAlgorithm : QCAlgorithm
{
private Symbol _symbol;
private SimpleMovingAverage _sma;
public override void Initialize()
{
SetStartDate(2020, 1, 1);
_symbol = AddEquity("AAPL", Resolution.Daily).Symbol;
_sma = SMA(_symbol, 20);
}
public override void OnData(Slice data)
{
if (_sma.IsReady && data[_symbol].Price > _sma)
SetHoldings(_symbol, 1.0);
}
}Zipline은 파이썬이라 익숙했어요. 그런데 실행 속도는 Lean이 2배 빨랐습니다. 5년 일봉 백테스트가 Zipline은 12초, Lean은 6초 걸렸어요. 컴파일 언어 차이가 여기서 나타났습니다.
메모리는 반대였어요. Zipline이 800MB, Lean이 1.2GB를 썼습니다. Lean은 전체 데이터를 메모리에 올리는 반면 Zipline은 필요한 구간만 읽어요.
백테스트 결과 해석도 달랐습니다. Zipline은 pyfolio 라이브러리로 샤프 비율, 최대 낙폭, 월별 수익률을 시각화해줬어요. Lean은 JSON 리포트만 덩그러니 떨어져서 별도로 차트를 그려야 했습니다.
실전 연결에서 Lean이 앞서는 이유
Zipline은 백테스트 전용입니다. 실전 거래 브로커 API 연결은 직접 짜야 해요. Lean은 Interactive Brokers, OANDA, Bitfinex 등 12개 브로커를 기본 지원합니다. 설정 파일 몇 줄만 바꾸면 같은 코드가 실전으로 넘어가요.
제가 IB 연결을 시도했을 때, Lean은 config.json에 계정 정보만 넣으니 바로 붙었습니다. Zipline은 ib_insync 라이브러리를 별도로 엮어야 했고, 주문 로직을 다시 써야 했어요.
확장성도 달랐습니다. Zipline은 단일 전략 백테스트에 최적화돼 있어요. 여러 전략을 동시에 돌리려면 멀티프로세싱을 직접 구현해야 합니다. Lean은 AlgorithmManager가 여러 전략을 한 프로세스 안에서 돌려요. CPU 4코어 기준으로 전략 3개를 병렬 실행했을 때 Lean은 8초, Zipline은 36초 걸렸습니다.
커스터마이징 자유도는 Zipline이 높았어요. 자체 데이터 번들을 만들어 한국 주식, 암호화폐, 대체 데이터를 바로 넣을 수 있었습니다. Lean도 커스텀 데이터 피드를 지원하지만 인터페이스 구현이 복잡했어요.
언제 Zipline을 고르고 언제 Lean을 골라야 할까?
저는 처음 3주를 Zipline으로 시작했습니다. 파이썬이 편했고, 간단한 팩터 전략 검증이 목적이었거든요. 그런데 전략이 5개로 늘어나자 속도가 발목을 잡았어요. 하나씩 돌리면 1분이 넘었고, 멀티프로세싱을 짜려니 코드가 복잡해졌습니다.
Lean으로 갈아탄 계기는 실전 연결 필요성이었어요. IB API를 직접 엮는 것보다 Lean의 브로커 추상화가 훨씬 깔끔했습니다. C# 문법은 일주일이면 익숙해졌고, 타입 안전성 덕분에 런타임 에러가 줄었어요.
지금 기준으로 정리하면 이렇습니다. 파이썬만 쓰고 단일 전략 검증이면 Zipline-Reloaded입니다. C#을 배울 의향이 있고 실전 거래까지 보거나 여러 전략을 병렬로 돌린다면 Lean이 맞아요. 데이터 커스터마이징은 Zipline이 쉬웠지만, 속도와 확장성은 Lean이 압도했습니다.
둘 다 로컬에서 무료로 쓸 수 있다는 게 핵심입니다. 클라우드 의존 없이 내 컴퓨터에서 전략을 검증하고 실전까지 연결할 수 있어요. 선택 기준은 언어 선호도와 최종 목표가 될 겁니다.
자주 묻는 질문
Q. Zipline-Reloaded는 Quantopian 코드를 그대로 쓸 수 있나요? A. 대부분 호환됩니다. 다만 일부 팩터 라이브러리(alphalens 등)는 별도 설치가 필요하고, 최신 파이썬 버전에서 의존성 충돌이 있을 수 있어요.
Q. Lean을 파이썬으로 쓸 수 있나요? A. 네, Lean은 파이썬 알고리즘도 지원합니다. 다만 C# 대비 실행 속도가 느리고 타입 힌트가 약해 디버깅이 어려웠어요.
Q. 한국 주식 데이터를 쓸 수 있나요? A. Zipline은 커스텀 데이터 번들을 만들면 됩니다. Lean은 QuantConnect 클라우드에 한국 주식 데이터가 없어서 직접 데이터 피드를 구현해야 해요. 국내 데이터 활용은 Zipline이 유리합니다.
Q. 두 엔진 모두 무료인가요? A. 로컬 사용은 둘 다 무료입니다. Lean의 경우 QuantConnect 클라우드 고급 데이터는 유료지만, 로컬에서 자체 데이터를 쓰면 비용이 없어요.
Q. 백테스트 결과 신뢰도는 어느 쪽이 높나요? A. 둘 다 슬리피지와 수수료 모델을 지원합니다. 다만 Lean이 틱 단위 시뮬레이션까지 지원해 고빈도 전략에선 더 정확했어요. 일봉 전략이라면 차이가 크지 않습니다.