About New High Frequency Algorithmic Trading Framework Design

이 글은 오픈 소스 High-frequency 알고리즘 트레이딩 프레임워크 개발에 앞서 프레임워크의 필요성과 요건 등에 대해 정리한 글입니다. 기존에 제가 제작하여 사용하고 있는 프레임워크의 개발 및 사용 경험을 바탕으로 업그레이드 된 새로운 프레임워크를 설계하는 과정의 하나입니다.

현재 증권사 딜링룸/해외영업부서, 부티끄, 개인 투자자 등 많은 분들이 HFT, 알고 트레이딩 등의 프로그램 개발에 관한 관심을 가지고 실제로 개발 및 운용을 하고 있는 것으로 알고 있습니다. 그러나 현재 국내에서는 그러한 과정에서 쌓일 수 있는 각종 지식 및 노하우가 그다지 효율적으로 통합되지 못하는 상황인 것 같습니다. 이러한 상황의 개선에 조금이나마 도움이 되고자 많은 분들이 자유롭게 사용하거나 참고할 수 있는 오픈 소스 High-frequency 알고리즘 트레이딩 프레임워크를 개발하고자 하는 것이 목표입니다.


최신의 High-frequency 알고리즘 트레이딩 프로그램이 가져야 할 요건

High-frequency 알고리즘 트레이딩 프로그램이 가져야 할 요건으로는

  1. 매매 손실을 가져올수 있는 오류의 방지,
  2. 사용자에 의한 직접적인 개발 및 유지 보수의 가능성
  3. 모든 시장 정보에 대한 틱 단위의 빠른 프로세싱
  4. 다수의 종목 및 포트폴리오 전략 매매가 가능토록 확장 가능

등 이 있습니다.

첫째, 프로그램 전체에 매매 손실을 유발 할 수 있는 논리적 오류가 없어야 한다는 점이 가장 중요합니다.

이는 단지 High-frequency 알고리즘 트레이딩 프로그램만에 국한된 문제는 아니지만 High-frequency 알고리즘 트레이딩 프로그램에서 더 중요해지는 요소입니다. 최근 들어 잦아진 트레이딩 프로그램의 오류에 의한 매매 사고를 보시면 이러한 문제를 실감하실 수 있으리라 생각합니다. 몇 가지 발생 할 수 있는 오류에 의한 매매 손실의 예를 들자면,

  • 네트워크 소켓 프로그래밍의 코딩 오류로 주문 코드에 무한 루프가 돌면서 지정가 주문이 반복되어 들어간 경우
  • 매매 사고가 발생한 비정상적 시장 상황을 인식 못하여 잘못된 매매가 이루어지는 경우
  • 선물 시장의 사고로 인해 옵션의 fair price 계산이 잘못되어 옵션 시장에 영향을 미치는 경우
  • 시장의 순간적인 유동성을 고려하지 못한 채 다량의 주문을 시장가로 내는 경우
  • 전략 로직 및 코딩의 복합적 오류로 저가 매도와 고가 매수가 순간적으로 반복되는 경우

등이 있을 수 있습니다. 특히 마지막에 예로 든 경우에서는 빠른 속도로 매매가 반복되므로 작은 계약수로도 순간적으로 엄청난 손실을 낼 수 있다는 점에서 계약수 한도를 이용한 기존의 리스크 관리 방법이 무용지물이 될 수 있습니다. 따라서 High-frequency 알고리즘 트레이딩 프로그램의 리스크 관리는 기존의 리스크 관리와는 다른 관점에서 접근할 필요가 있습니다. 만일의 경우라도 이러한 오류에 의한 매매 손실이 발생할 경우 손실의 규모가 작게는 몇 천만원에서 크게는 몇 백억까지 가는 경우도 있을 수 있으므로 프로그램의 논리적 오류는 절대로 발생하면 안되는 요소입니다.

프로그램을 작성함에 있어 처음부터 모든 것을 고려하여 짜면 최선이겠으나 이러한 일은 사실상 불가능합니다. 따라서 현실적으로 사용할 수 있는 보조 대안으로는

  • 실전 환경과 가장 유사한 환경에서 오프라인 테스트
  • 소규모의 계약 수로 많은 온라인 테스트
  • 기존 회원사 OMS(order management system)에 의한 리스크 관리를 받는 방법
  • 잘 설계된 프레임워크를 이용하는 방법

등이 있을 수 있습니다.

오프라인 테스트에서는 실전 환경과 가장 유사한 환경에서 작동해야 합니다. 실전에 사용되는 코드를 변경하지 않은 채로 바로 오프라인 테스트를 할 수 있어야 함은 기본입니다. 만일 전략이 특정 가격의 매수 잔량의 틱 단위 변화 값을 사용한다면 오프라인 테스트에서도 동일한 정보가 전략에 주어져야 합니다. 또한 주문 패킷이 거래소에 도달하고 다시 확인 패킷이 돌아오는데 실제 지연시간이 있고 이것이 전략에 영향을 미친다면 오프라인 테스트에서도 이러한 경우를 어느 정도 감안해야 합니다.

증권사 딜링룸이나 운용사/자문사의 경우에는 회원사/기관투자자로서의 지위를 활용하여 실시간 증거금/한도 체크 등의 회원사 OMS단에서의 리스크 관리를 받지 않고 바로 주문을 내는 경우가 있을 수 있습니다. 이는 실시간 리스크관리시 데이터베이스 쿼리 등에서 발생하는 시간 지연을 줄이기 위함입니다. 그러나 속도 자체에 대한 테스트가 아닌 이상 초기 운용에서 이러한 기초적인 리스크 관리도 받지 않는 다는 것은 심각한 위험을 초래할 수 있습니다. 최근에 발생했던 몇 가지 매매 사고가 제대로 된 OMS단 리스크 관리만 받았어도 발생하지 않을 수 있었다는 사실을 살펴볼 때 수익 및 스피드에 대한 무리한 욕심은 제어할 필요가 있다고 생각합니다. 또한 개인적으로는 현재의 한국 거래소 매칭 시스템의 성능을 감안할 때 FEP 뒷단에서의 (sub-) mili second order의 시간지연 차이가 과연 이러한 리스크 대비 얼마만큼 수익을 더 가져올 수 있는지도 의구심이 있습니다. (이 이슈는 추후 다시 설명할 기회가 있을 것 같습니다.)

마지막 방법은 실전에서 검증이 된 프레임워크, 다수의 사용자를 가진 프레임워크를 사용하는 것입니다. 이는 제가 오픈 소스 프레임워크를 개발하고자 하는 이유 중의 하나이기도 합니다.
매매 전략 자체가 아닌 프레임워크 단은 다수 사용자에 의해 공통된 사용이 가능합니다. 이러한 사용과정에서 오픈 소스 프레임워크 자체의 오류도 수정가능하고 전략 코딩에 프레임워크에서 제공하는 검증된 컴포넌트나 리스크 관리 툴을 사용한다면 코딩시 발생할 수 있는 오류의 가능성을 감소시킬 수 있습니다.

둘째, 사용자에 의한 직접적인 개발 및 유지 보수가 가능해야 합니다.

컴퓨터에 의한 자동매매 시스템은 그 복잡도를 막론하고 기존에 많이 개발되고 사용되어 왔습니다. 기존의 자동 매매는 크게 나누어 상용으로 판매되는 TradeStation, MultiChart 등을 사용하는 방식과 증권사, 운용사, 부티끄 등의 기관 내부에서 IT 개발인력을 활용하여 증권사에서 제공하는 API를 기반으로 내부적 개발 프레임워크를 활용한 in-house 코딩으로 이루어지는 방식이 대부분이었습니다. 물론 일부 외국계 하우스는 ORC 등 고가의 상용 프레임워크를 사용하기도 합니다. 또 개발 경력이 오래되신 분들은 자신만의 코드를 짜서 자기 계정으로 매매하시기도 합니다.

TradeStation, MultiChart 등을 사용하는 경우에는 최초 사용이 간편하다는 장점이 있지만 원래가 외국 거래소에서의 Low-frequency 매매를 기준으로 만들어진 것이라 국내 거래소에서 High-frequency 매매를 하기 위해서는 여러가지 수정을 통해 사용해야 하거나 복잡한 portfolio / high-frequency 전략의 수행이 힘들다는 단점이 있었습니다. 국내 셀러로부터 데이터 피딩을 받는 방식도 시간 지연 및 비싼 피딩 비용의 문제를 가지고 있습니다.

내부 개발의 경우 작은 부티끄의 경우에는 매매와 개발이 밀접하게 붙어서 이루어질 수 있지만 트레이딩/개발 부서 간의 관계 등 여러가지 내부 사정으로 다음과 같은 방식으로 이루어지는 것이 보통입니다.

  1. 트레이더가 시스템 requirement 를 결정하여 IT개발 부서로 전달
  2. IT개발 부서에서는 내부 프레임워크를 사용하여 개발. requirement 만족시 project closed.
  3. 트레이더가 시스템 사용.

즉, 트레이더는 시스템 스펙만을 정하고 실제 개발에는 참여하지 않는, 말하자면 일종의 턴키(turn-key) 방식입니다.

이 방식에는 실제로 여러가지 문제가 있습니다. 우선 IT 프로젝트는 사양정의(system requirement specification) 단계에서 프로젝트 성과가 많이 좌우됩니다. 얼마나 구체적이고 현실적인 사양정의가 이루어지는가에 의해 프로젝트 진행 속도 및 시스템 성능이 결정되는 것입니다. 그러나 대부분의 트레이더는 IT에 문외한이거나 대규모 시스템 개발 경력이 전무한 경우가 많으므로 우수한 사양정의가 이루어지기 힘듭니다. 그러다 보니 프로젝트가 완료된 후에도 트레이더는 큰 만족감을 못느끼고 각종 사양 변경을 요구하고 개발부서는 나름대로 유지보수에 곤란을 겪습니다. 이러한 과정에서 적시 업데이트가 이루어지지 못하고, 시스템이나 전략이 시장의 변화를 따라가지 못하는 경우가 발생합니다.

가장 좋은 경우는 마지막에 언급한 바와 같이 트레이더가 직접 코딩을하는 경우입니다만 여기에도 문제는 있습니다. 제대로 동작하면서 앞서 말한 오류를 발생시키지 않는 working code를 만들기까지는 처음 시작했을 때 예상했던 것보다 훨씬 많은 개발시간이 투입될 가능성이 높습니다. 배보다 배꼽이 커지는 거죠.

이러한 이유로 프레임워크의 사용이 필요하게 됩니다. 완전한 트레이딩 프로그램의 개발을 위해 필요한 재활용 가능 컴포넌트들과 코드의 설계 개념, 개발 도구, 샘플 코드 등을 완비한 프레임워크가 있는 경우, 개발시간의 많은 단축이 가능합니다. 따라서 사용자인 트레이더가 직접 코드를 작성하거나 변경하는 것이 현실적으로 가능해 집니다.

셋째, 모든 시장 정보에 대한 틱 단위의 빠른 프로세싱 및 주문 관리

시장에서 오랜 기간 시스템 트레이딩을 하시거나 스켈핑을 하시는 분들이 많이 말씀하시는 것이 시장이 옛날과는 다르다는 것입니다. 이는 High-frequency trading의 활성화에 기인한 부분이 크다고 여겨집니다. 특히 일본 시장의 경우 TSE가 ArrowHead를 오픈한 이후 market dynamics에 큰 변화가 생각다고 합니다. 매칭 시스템의 성능이 High-frequency trading 이 가능한 수준으로 높아지면서 발생한 일입니다.

과거에는 컴퓨터를 이용하여 대규모의 High-frequency trading 을 하기 힘들었던 이유가 전략 설계의 기반이 되는 이론적 베이스가 없었다는 것입니다. 그러다 보니 매매 전략의 손익 프로필에 확신을 가지기가 힘들었습니다. 그러나 이러한 상황은 2000년대 들어 market microstructure theory 가 트레이딩 하우스 사이에 빠르게 전파되면서 바뀌었습니다. 우선 가장 수익창출의 기반이 되는 market making의 자동화가 가능해 졌고 과거 Black-Sholes 방정식으로 옵션 market making 및 헷지 트레이딩을 하듯 market microstructure theory 를 이용하여 underlying 의 직접 market making 이 가능해진 것입니다.

이러한 전문 HFT 하우스들의 시스템은 order book의 모든 정보를 사용하여 빠르게 quote revision 을 반복하고 변동성이 특정치 이상으로 커지면 신속하게 loss-cut 이나 scaling-out 을 합니다. 그러다 보니 이에 상대하는 전략들도 order book의 모든 정보를 사용하여 빠르게 움직이지 않으면 수익을 내기 힘든 상황이 되고 있습니다. 또한 주문에 있어서도 과거처럼 단순하게 시장가나 최우선/최유리 호가를 사용하는 방법, 포지션의 scaling 없이 단순하게 매수/매도 반복의 bang-bang control 방식의 전략만이 아닌 더 고도의 전략을 요구하고 있습니다.

넷째, 다수의 종목 및 포트폴리오 전략 매매가 가능토록 확장 가능

마지막으로 다수의 종목에 대해 coordinated 된 전략적 매매가 가능해야 합니다. 지수 선물 한 종목만 매매하는 경우에는 큰 문제가 없지만 포트폴리오 implementation, pair trading, implied volatility 전략 등 고도의 복잡한 전략을 high-frequency 로 수행하려는 경우에는 현실적으로 확장 가능성이 큰 문제가 됩니다.

사실 이 이슈는 빠른 프로세싱과 trade-off 관계를 가집니다. 제한된 컴퓨터 리소스를 사용하는 경우, 종목수가 증가하면 프로세싱 속도는 당연히 그에 따라 감소합니다. 예를 들어 volatility skew, volatility term structure 매매를 하고자 하는 경우에는 거의 전종목의 옵션과 선물을 동시에 매매해야 하는데 만일 사용하는 전략이 틱 단위로 모든 order book 정보를 사용하는 전략이라면 선물 및 옵션 전종목 매매를 단일 코어에서 프로세싱한다는 것은 제 경험상 어려운 일입니다. 만일 implied volatility를 틱단위로 구하기라도 해야 한다면 실질적으로 불가능합니다. 그러면 결국 multi-core 및 distributed/parallel computing을 사용하는 방향으로 나아가야 합니다. 따라서 프레임워크를 설계한다면 distributed computing에 중점을 가지고 설계할 필요가 있습니다.

또한 전략의 수행에 있어서도 decentralized control 이 가능토록 하여야 합니다. 즉 전략이 여러 단계의 layer를 가지고 상위 단계의 전략은 큰 그림을 보며 하위 전략의 파라미터 등을 실시간으로 조정해 주고 하위 전략은 큰 파라미터 등은 상위 전략의 지시를 받지만 기본적으로 order book 정보를 빠르게 쫒아가며 시장의 상황에 따라 매매를 수행하거나 특정종목에서 매매 실수에 의한 시장의 outlier 발생시 이를 상위 전략에 통보해 주는 등의 coordinated 전략 설계 및 구현이 가능해야 합니다.


High-frequency 알고리즘 트레이딩 프레임워크

프레임워크가 왜 필요한지는 앞서의 이야기에서 어느 정도 이해를 하셨으리라 생각합니다. 여기서 말하는 프레임워크란 프로그램(어플리케이션) 제작을 위한 기본 틀을 말합니다. 예를 들어 windows 기반의 응용 프로그램을 제작할 때, native win32 SDK & API 를 이용하여 코딩을 할 수도 있지만 MFC(Microsoft Foundation Class)를 이용하여 제작할 수도 있습니다. 프레임워크는 개발에 필요한 라이브러리를 뜻하기도 하지만 저는 그와 더불어 더 중요한 것이 트레이딩 프로그램의 설계 및 구현에 필요한 기본 개념(concept)을 제공하여야 한다고 봅니다. 이 부분은 한 마디로 쉽게 설명하기 힘들지만 개발경력이 있으신 분들은 무슨 말인지 이해하시리라 생각합니다.

제가 목표로 하는 High-frequency 알고리즘 트레이딩 프레임워크의 세부 요건은 다음과 같습니다.

  • 쉽게 이해가능하고 활용가능한 설계 개념
  • C/Python을 이용한 코드 구현
  • OOP 기반 구성 library
  • green threads 기반의 multi-processing
  • IPC, RPC 및 ZeroMQ 메시지 등을 사용한 분산 전략 수행

세부 사양에 대해서는 추후 덧붙이도록 하겠습니다만 위의 사양은 순전히 개인적인 경험 및 취향에 따른 것입니다. 혹시 이러한 구성에 대해 suggestion이 있으신 분들의 많은 comment 바라겠습니다.