퀀트 트레이딩을 시작할 때 가장 먼저 만나는 질문은 대개 라이브러리 선택이다. 어떤 백테스터가 빠른지, 어떤 프레임워크가 유명한지, Python으로 어디까지 만들 수 있는지를 찾게 된다. paperswithbacktest/awesome-systematic-trading은 그 질문에 곧바로 하나의 답을 내놓지 않는다. 대신 연구에서 실거래까지 이어지는 시스템의 지형을 펼쳐 보인다.
README에는 연구와 라이브 트레이딩에 사용할 수 있는 97개 라이브러리와 패키지가 정리돼 있다. 목록은 이벤트 기반 프레임워크, 벡터 기반 프레임워크, 암호화폐 도구, 트레이딩 봇, 지표, 성과 지표 계산, 최적화, 가격결정, 리스크, 브로커 API, 데이터 소스, 데이터베이스, 머신러닝, 시계열 분석, 시각화로 나뉜다. 단순히 저장소 이름을 늘어놓은 것이 아니라, 전략이 데이터와 계산을 거쳐 주문 실행으로 이동하는 과정을 따라가게 하는 구성이다.
구체적인 도구를 보면 차이가 더 선명해진다. vn.py, zipline, backtrader는 이벤트 기반 알고리즘 거래와 백테스트의 대표적인 선택지로 소개된다. backtesting.py는 과거 데이터로 전략의 실행 가능성을 추론하는 가벼운 Python 프레임워크로 설명되고, HFTBacktest는 Python과 Numba를 사용해 HFT 데이터의 고정밀 백테스트를 표방한다. aat는 비동기·이벤트 기반 구조를 바탕으로 여러 거래소 사이의 실거래를 염두에 둔다. QuantConnect Lean은 Python과 C#을 함께 지원한다. 같은 목록 안에서도 데이터의 시간 해상도, 이벤트 처리 방식, 실행 환경에 따라 필요한 도구가 달라진다는 뜻이다.
여기서 긴장이 생긴다. 백테스트가 잘 돌아간다고 해서 실거래 시스템이 준비되는 것은 아니다. 과거 데이터에서 전략 신호를 계산하는 일과, 브로커 API를 거쳐 주문을 보내고 포지션과 리스크를 관리하는 일은 서로 다른 실패 지점을 가진다. README가 backtesting and live trading을 함께 묶으면서도 라이브러리의 역할을 여러 범주로 나누는 이유를 이 차이에서 읽을 수 있다.
목록의 나머지 절반도 같은 방향을 가리킨다. 40개가 넘는 전략, 55권의 책, 23개의 영상과 인터뷰, 블로그와 강의가 함께 정리돼 있다. 코드를 고르는 일만큼 전략의 가정과 검증 방법을 다시 읽는 일이 중요하다는 판단이다. 다만 GitHub stars를 기준으로 정렬한 큐레이션이라는 점은 기억해야 한다. stars는 발견의 순서를 정할 뿐, 최신 유지보수 상태나 특정 브로커의 실거래 안정성, 데이터 라이선스를 보장하지 않는다.
그래서 이 저장소를 읽는 가장 좋은 방법은 '최고의 툴'을 찾는 것이 아니다. 먼저 내 전략이 연구 단계인지, 백테스트를 넘어 페이퍼 트레이딩이나 실거래를 준비하는 단계인지 정한다. 그다음 데이터 소스, 실행 엔진, 브로커 API, 리스크 계산이 어디에서 이어지는지 확인한다. 브라우저에서 시작한 링크 탐색이 시스템 설계의 경계 확인으로 바뀌는 순간, 이 목록의 쓰임새가 분명해진다.