[알고리즘 트레이딩/전략편] 25. 알고리즘 전략 테스트와 시뮬레이터

알고리즘 트레이딩 (Algorithmic Trading) – 전략 (25)

알고리즘 전략 테스트와 시뮬레이터

일반적으로 전략을 테스트 (백 테스트)할 때는 과거의 주가를 이용한다. 기술적 분석이나 차익거래 전략을 테스트하려면 과거 일정기간 동안의 주가를 이용하여 최적화된 신호를 만들고, 그 신호를 이용하여 다음 일정기간 동안의 (이것도 과거) 주가에 대입해서 전략의 성과를 분석한다 (일종의 Cross validation). 더 나아가서는 몬테카를로 시뮬레이션을 통해 가상의 미래 주가를 만들어서 성과를 분석하기도 한다.

시장미시구조론을 활용한 알고리즘 트레이딩의 경우는 (ex : 고빈도매매 (HFT), 주문집행 알고리즘 등), 과거의 주가 데이터만으로는 부족하므로, 주문 흐름 (Order Flow)에 대한 과거 데이터를 이용한다 (호가 및 체결 데이터). 이 경우에는 API나 DMA로 저장해 놓은 과거의 시세데이터를 활용한다. 그런데 주문 흐름 데이터인 시세데이터도 시뮬레이션이 가능할까?

Replay 방식의 백 테스트

Replay 방식은 저장된 과거의 시세데이터를 하나씩 읽어가면서 전략을 테스트하는 방법이다. 저장된 시세데이터는 (과거의) 실제 데이터이므로 시장의 특성이 잘 반영되어 있다. 그러나 전략 테스트를 위해서는 몇 가지 단점이 있다.

첫째는 내 주문이 시장에 영향을 주지 못한다. 예를 들어 특정 순간에 Best Ask측 호가에 잔량이 10개 남아있고, 내 전략이 상대호가로 10개를 매수하는 전략이라면 Best Ask의 잔량은 모두 소진되고 Mid-price는 상승해야하지만, 저장된 시세데이터에는 잔량이 그대로 10개가 남아있고 Mid-price도 변하지 않는다. 유동성이 풍부한 시장에서 소량의 주문으로 테스트하는 경우는 이 영향이 크지는 않지만, 미시시장에서는 순간의 작은 영향이 누적되면 나중에는 점차 커질 수 있다. 특히, 시장충격비용 등을 고려해야하는 주문집행 알고리즘 등에서는 영향이 더 커진다.

둘째는 지정가 주문 (Limit Order)을 사용하는 전략은 Replay 방식으로 테스트가 곤란하다. 과거의 시세데이터를 통해 시장에 유입된 지정가 주문과 체결 주문은 확인이 가능하지만, 취소 주문의 흐름은 확인이 곤란하다. 만약, Best Ask 호가에 10개의 매도 주문을 냈다면, 내 주문은 맨 뒤에 접수되고 체결 주문과 취소 주문에 의해 점차 앞으로 이동한다. 체결 주문은 정확히 파악이 가능하지만, 취소 주문은 내 앞에서 취소된 것인지, 내 뒤에서 취소된 것인지 확인이 불가하다. 따라서 내 주문의 위치를 정확히 추적할 수 없으므로 내 주문이 언제 체결되는지 알 수가 없다. 증권사의 모의계좌 서비스의 경우 지정가로 낸 주문이 제대로 체결되지 못하는 경우가 바로 이런 이유 때문이다.

Simulator 방식의 백 테스트

주문 흐름인 시세데이터도 시뮬레이션을 통해 생성이 가능하다. 시뮬레이션으로 가상의 시세데이터를 만들고, 내 주문이 시세데이터에 영향을 줄 수 있다면 Replay에 의한 방법을 보완할 수 있다. 물론, 이 방법은 시장의 특성을 정확히 재현하기 어렵다는 단점이 있다. 따라서 알고리즘을 테스트할 때는 Replay 방식과 Simulator 방식을 병행할 필요가 있다.

Simulator 설계

알고리즘 트레이딩 전략을 테스트하기 위해 아래와 같이 Simulator를 설계해 보았다. 가상 시장을 재현하고 전략을 테스트하기 위해서는 기본적으로 가상 매매 체결 시스템 (Order Matching Engine)이 필요하고, 가상의 트레이더들이 필요하다. 또한, 내 전략을 시험하기 위해서는 내 주문이 거래소와 동일하게 처리되어야 한다.

Simulator는 실제 거래소 시스템과 유사하도록 통신망 (TCP/IP)을 경유한 서버/클라이언트 방식으로 한다. 통신망을 경유한 이유는 주문 데이터나 시세데이터에 지연시간 (Latency)을 고려하여 실제 증권전산망과 유사하도록 해야 하기 때문이다.

(1) 매매 체결 시스템 : 실제 거래소와 동일한 방식으로 거래를 체결하는 시스템이다. 거래 체결은 실제 거래소와 동일하게 Price-Time Priority 방식으로 구현한다. 매수 주문이라면 높은 가격을 제시하는 주문에 체결 우선권을 주고, 동일 가격이라면 선착순으로 체결시키는 방식이다.

(2) Market Factor : 재현하고자 하는 실제 시장의 특성을 분석하여, 해당 시장의 특성이 잘 나타나도록 시장의 Factor 들을 정리해둔다.

(3) 가상 거래자 : 다수의 가상 거래자를 멀티 프로세스 (쓰레드)로 돌린다. 가상 거래자들은 (2)에서 정리한 Market Factor들을 참조하여 자신들의 주문 패턴을 결정하고 (포아송 분포, 지수분포 형태의 패턴), 각자의 주문을 주문 접수 시스템으로 보낸다. 그러면 가상 거래자들의 행위에 의해 재현된 시장은 실제 시장과 유사하게 된다. 가상 거래자들은 주로 시장미시구조론에서 분류된 거래자들이다. 예를 들어, (A)는 정보기반 거래자 (Informed Trader), (B)는 유동성 거래자 (Liquidity Trader, or Noise Trader), (C)는 마켓메이커 등이다. 이 거래자들은 사전에 정의된 Market Factor 들의 제한을 받으면서, 자신의 전략을 최대한 실현하도록 주문을 전송한다.

(4) 주문 접수 및 통보 시스템 : 여러 프로세스로부터 유입된 주문을 매매 체결 시스템에 전달하고 결과를 각 프로세스로 통보한다.

(5) 시세 생성 및 분배 시스템 : 매매 체결 시스템에서 처리된 결과인 호가 정보 (B6)와 체결 정보 (A3/G7)를 클라이언트 측으로 분배한다. 실세 시장과 동일하도록 TCP/IP 망의 UDP 포트를 통해 실시간으로 분배한다.

(6) 주문 채널 : 클라이언트의 주문은 TCP 포트를 통해 전달된다. 서버의 주문 접수 시스템은 TCP 포트로 유입된 클라이언트의 주문을 매매 체결 시스템으로 전달하고, 결과를 해당 클라이언트에게 통보한다.

(7) 전략 스크립트 : 클라이언트에서 내 전략을 처리하는 부분이다. 다양한 전략을 처리하기 위해 Easy Language와 같이 스크립트로 처리한다. 또한, 스크립트는 2개의 쓰레드로 분리하여 두 전략이 동시에 병렬처리 되도록 하였다.

(8) 주문관리 : 클라이언트의 전략 스크립트에서 보내는 주문을 TCP 포트를 통해 서버 측으로 전달하고, 서버로부터 결과를 통보받아 스크립트 프로세스로 보낸다.

(9) 시세분석 : 클라이언트에서 UDP 포트로 유입되는 시세데이터를 이용하여 주문의 흐름을 분석한다. 분석된 주문 흐름 데이터는 스크립트에서 참조하여 전략을 실행한다.

(10) 성과관리 : 클라이언트에서 전략 스크립트의 최종 결과를 관리한다. 주로, 손익 (Profit & Lose)과 재고 (Inventory)를 관리한다. 전략 스크립트는 손익과 재고 결과를 이용하여 전략을 수정하거나 개선한다.

이상으로 알고리즘 테스트를 위한 Simulator가 가져야할 최소한의 기능에 대해 간단히 살펴보았다. 다음 시간에는 실제로 구현된 프로그램을 간단히 소개하고, 그 다음부터는 Simulator를 이용하여 알고리즘 트레이딩 전략들을 하나씩 시험해 보기로 한다.

[출처]25. 알고리즘 전략 테스트와 시뮬레이터|작성자아마퀀트