퀀트 트레이더의 두 가지 엔진
# 두 가지 엔진
퀀트 트레이더는 트레이더라는 직업답게 금융시장에서 트레이딩, 즉 매매를 통해 수익을 창출한다. 하지만 퀀트 트레이더는 다른 전통적 개념의 트레이더와는 업무적인 면에서 다소 차이점이 있다.
우선, 퀀트 트레이더는 다른 트레이더들이 하는 것처럼 직접 손수 매매를 하지 않는다. 인간의 클릭 속도는 알고리즘 처리 속도보다 빠를 수 없으며, 손으로 하는 매뉴얼 방식의 트레이딩은 소위 팻 핑거(Fat Finger)라고 불리는 엄청난 오퍼레이션 리스크에 노출되기 때문이다. 그렇기 때문에 퀀트 트레이더의 트레이딩은 철저히 알고리즘에 기반해 있으며, 이는 퀀트 트레이딩이 가지는 대표적인 특징이자 장점이다.
또한 퀀트 트레이더는 메사끼로 트레이딩을 하는 것이 아닌 철저히 데이터에 기반한 트레이딩을 하기 때문에 전략을 운용하기 위해서는 해당 전략을 뒷받침할 수 있는 객관적인 증거가 언제나 필요하다. 이 객관적인 증거는 당연히 과거 데이터로부터 나온다. 퀀트 트레이더는 과거 데이터를 분석해 잠재적 리스크 프리미엄이 될 수 있는 패턴을 찾아내고, 이 패턴의 배후에 진짜 합리적인 경제적 논리가 자리하고 있는지를 증명한다. 또한 이를 최종적으로 트레이딩 알고리즘으로 변환해 내는 데 이러한 업무의 특징은 퀀트 트레이더라는 업의 본질을 잘 보여준다.
따라서 이러한 고유한 업무적 속성들 때문에 퀀트 트레이더는 좌청룡 우백호 마냥 항상 두 가지 종류의 엔진이 필요하다. 이 두 종류의 엔진은 각각 백테스팅 엔진과 매매체결 엔진이다.
# 백테스팅 엔진
백테스팅 엔진(Backtesting Engine)은 퀀트에 대해 관심이 있거나 들어본 적이 있다면 익숙한 개념인 바로 그 백테스팅을 수행하는 엔진이다. 이 백테스팅(Backtesting)은 단어의 의미 그대로 과거 데이터를 가지고 어떤 트레이딩 전략을 수행했을 때 어떤 결과를 얻을 수 있었는가를 확인해 보는 작업이다. 퀀트 트레이딩은 어떤 정해진 매매의 규칙이 있고 또 이것은 알고리즘으로 정형화될 수 있는 것이기 때문에 우리는 과거 데이터가 주어진다면 백테스팅을 통해 과거에는 성과가 어땠었는지 충분히 검증이 가능하다.
그런데 이 백테스팅을 통한 검증이 유의미한 검증이 되기 위해서는 한 가지 조건이 있다. 그것은 바로 백테스팅이 실제 트레이딩하는 환경과 정확하게 일치해야 한다는 것이다. 그렇지 않는다면 사실 백테스팅을 한 전략과 내가 실제 트레이딩할 전략은 엄밀히 말해서 서로 다른 전략이 되어버린다. 트레이딩하는 환경이 동일하지 않기 때문이다. 여기서 말하는 환경에는 시그널 생성 시간, 매매 체결시간, 체결 거래량 및 시장 유동성, 휴일 처리, 선물 롤오버 시간 등 잡다한 디테일들이 전부 포함된다.
그렇기 때문에 실무적으로 백테스팅을 수행할 때는 실제 라이브로 트레이딩을 할 때 어떤 조건에서 매매를 수행할 것인지 모든 디테일들을 가능한 한 정확하고 세밀하게 구체화시켜놓은 후 이에 맞게 백테스팅 작업을 시작해야 한다. 이러한 디테일을 설계해놓지 않고 무작정 백테스팅 엔진을 만들려고 한다면 결국 중간중간 소스코드의 많은 부분을 두 번 세 번 수정하는 과정을 거치게 될 수밖에 없으며, 이는 업무 효율성의 저하로 귀결된다. 또한 더 최악의 상황은 이를 무시하고 그냥 매매를 해버리게 되었을 때 발생하는데, 만약 이런 디테일을 고려하지 않는다면 백테스팅으로부터 예상했던 결과와 실제 매매 결과 사이에 엄청난 괴리가 발생할 수 있다는 것이다. 따라서 이런 현상이 발생한다면 즉시 라이브 트레이딩을 중지하고 원인을 분석하여 문제를 해결해야 한다. 결국 이론적으로는 쉬워 보이는 전략도 구현의 레벨로 오게 되면 실제 자동차 엔진을 조립한다는 생각으로 더욱 세밀하게 접근을 해야 한다. 디테일의 차이가 성과의 차이를 만들어낸다.
백테스팅 엔진을 구현할 때는 기본적으로 벡터화 방식(Vectorized Approach)이 선호된다. 그 이유는 백테스팅 엔진의 목적이 대량의 데이터를 가지고 가능한 한 빠르게 백테스팅의 성과를 계산해 보는 것이기 때문이다. 여기서 말하는 벡터화란 시간 순서대로 데이터를 받아 하나씩 처리를 하는 방식이 아닌 전체 데이터셋에 대해 한꺼번에 계산을 수행하는 것을 의미한다. 벡터화를 사용할 수 없는 부득이한 상황이 아니라면 백테스팅 엔진은 벡터화 방식으로 구현하는 것이 기본적인 구현의 관행이다. 벡터화 방식을 사용하게 되면 시그널 생성과 포지션 관리, 손익 계산 등의 요소가 매우 빠르게 계산된다.
물론 벡터화 방식을 사용했을 때 조심해야 할 점이 있는데 바로 코드 자체에 선견 편향(Forward Bias)가 들어갈 수 있다는 점이다. 과거 전체 데이터셋이 한꺼번에 주어지다 보니 자칫 잘못하면 그때 당시 얻지 못한 데이터를 가지고 트레이딩 시그널이 계산되거나 수익률이 계산될 수도 있다. 코드에 선견 편향이 들어가면 대부분의 경우 백테스팅 결과가 매우 좋게 나오는데, 당연히 이는 현실성이 없는 백테스팅이다. 따라서 벡터화 방식을 사용할 때는 이러한 잠재적 오류들을 주의해야 한다.
# 매매체결 엔진
매매체결 엔진(Execution Engine)은 말 그대로 실제 자동으로 매매를 체결시키는 엔진을 의미한다. 퀀트 트레이더의 트레이딩은 바로 이 매매체결 엔진을 구동함으로써 실행된다. 엔진을 실제 구동하게 되면 이는 실제 포지션의 진입과 청산을 유발하게 되기 때문에 매매체결 엔진을 사용하는 것은 백테스팅 엔진의 경우보다 훨씬 더 주의를 기울여야 하는 작업이다. 자동차를 운전하는데 만약 자동차에 결함이 있다고 한다면 당연히 도중에 사고가 발생할 가능성이 큰 것처럼, 매매체결 엔진 또한 알고리즘을 구동하는 과정에서 단 하나의 결점이라도 발생한다면 실제 손익에 심각한 문제가 발생할 수 있다. 따라서 이 엔진을 사용해 실제 매매를 수행하는 프로덕션 레벨까지 가기 위해서는 수십수백 번의 코드 리뷰와 크로스 체크, 그리고 모의 테스트가 필수적으로 수반된다. 알고리즘은 절대 실수를 하지 않지만 그것을 개발하는 사람은 항상 실수를 할 수 있기 때문이다.
매매체결 엔진은 실시간 데이터를 받아 주문을 내고 매매를 체결시키는 알고리즘이기 때문에 백테스팅 엔진처럼 벡터화 방식으로 제작되는 것이 아닌 이벤트 드리븐 방식(Event-Driven Approach)으로 구현되어야 한다. 여기서 말하는 이벤트(Event)란 실시간 데이터가 시간순에 따라 순차적으로 들어오고 시그널을 계속해서 생성하는 도중 매매를 해야 한다는 트리거가 발생하는 것을 의미한다. 이벤트가 트리거 됨에 따라 알고리즘은 각각의 이벤트에 맞는 반응을 하게 된다. 이러한 이벤트의 트리거는 언제 발생할지 모르기 때문에 매매체결 엔진은 철저히 데이터를 스트리밍하는 방식으로 그 구조가 설계된다.
또한 실시간 트레이딩 시그널을 계산하기 위해 만약 최근 일정 기간 동안의 과거 데이터가 필요하다면, 엔진을 스타트하는 과정에서 초기화(Initiaize)를 통해 필요한 모든 변수와 조건들을 셋팅한다. 매매체결 엔진은 데이터를 스트리밍받아 처리하고 실제 매매주문을 내는 전 과정에서 발생하는 모든 정보들을 기록하는 역할도 담당하고 있는데, 여기에는 실시간 가격 데이터, 트레이딩 시그널 로그, 거래내역 및 일별 손익 등이 전부 포함된다. 이 정보들은 전부 저장되어 포워드 테스트나 새로운 전략의 개발 그리고 손익 관리를 하는데 또다시 사용된다.
퀀트 트레이더는 이 두 가지 엔진을 개발하는데 이론적인 리서치 및 연구를 제외한 대부분의 시간을 쏟아붓는다. 결국 이 두 가지 엔진은 퀀트 트레이더에게 있어 묠니르이자 스톰 브레이커다. 따라서 이 엔진의 퀄리티는 트레이딩의 성과를 좌우하는 매우 결정적인 요인이며, 이는 바로 퀀트 트레이더에게 좋은 인프라 기반이 필요한 이유이다.
