잊었던 그러나 아주 중요한 또 다른 레이턴시

1.
어제 알고리즘트레이딩교육을 위한 사전 모임이 있었습니다. 여러 분을 초청하여 강사님이 1시간정도 직접 강의를 하고 평가를 받는 자리였습니다. 저같이 기획하는 입장의 의견도 있고 트레이더로서의 의견도 있었고 영업하는 분의 의견도 있었습니다. ?이런 의견이 있었습니다.

?”강의한 내용을 직접 보여주거나 실습해볼 수 있으면 좋겠다.”

이 말을 들으면 금융IT 인력양성을 이렇게 하면…..에서 소개하였던 Subotnick Financial Services Center가 떠오르더군요. 코스콤의 자본시장IT아카데미도 이런 정도의 시설이 없는 것으로 압니다. 여건이 녹녹하지 않습니다. ?그럼에도 해볼 수 있는 방법은 가능할 듯 합니다.
현재 파트너들이 모 선물사에 제공할 ZeroAOS 시험을 하고 있습니다. 시험하는 환경은 어떤 트레이더가 요청한 전략샘플을 가지고 ZeroVE를 이용하고 있습니다. ZeroVE는 가상거래소입니다. Exchange Simulator에서 개발한다고 했던 제품입니다. ZeroAOS를 시험하는 파트너가 말합니다.

?”ZeroVE때문에 시험에 들어가는 시간을 대폭 줄이고 실환경과 비교하여 90%까지 개발생산성을 올릴 수 있다”

여기서 “줄인다”는 표현을 다르게 말하면 Latency단축입니다. 이것이 오늘 제시하고자 하는 또다른 레이턴시인 Testing latency입니다.

2.
Exchange Simulator에서도 말하였던 것을 정리하면 두가지입니다. 하나의 전략을 운용하려면 반드시 거쳐야 하는 몇가지 과정이 있습니다. 시계열데이타든 무엇이든 수집하여 분석하는 과정(Research). 분석한 결과를 토대로 알고리즘을 구성하는 과정(Model). 알고리즘을 전산화하여 시험하는 과정(Development). 전략자체에 대한 시험(Back-Testing)입니다. 이중에 Development와 Back-Testing은 어떤 전산환경을 구축하느냐에 따라 투입하는 시간과 자원을 줄일 수 있습니다. 이것을 Testing Latency라고 합니다.

실거래에 필요한 Latency단축과 다릅니다. 전략에 직접적인 영향을 주는 요소가 아니라 무시하거나 의미를 축소할 수 있습니다. 그렇지만 전산적인 시험, 전략 시험을 충분히, 그렇지만 완전히 짧은 시간동안 할 수록 그만큼 시장에 맞는 전략이 적합한 시기에 운용할 수 있고 – 적시생산(Just In Time) – 비용도 절약할 수 있습니다. 트레이딩도 비즈니스이기때문에 원가관리를 하여야 합니다. 트레이딩 원가라고 하면 TCA를 생각할 수 있지만 비즈니스적 관점으로 보면 전략을 운용을 위하여 필요한 전과정에 들어간 비용이 모두 원가입니다. 자원뿐 아니라 시간도 원가입니다. 원가를 절감하면 전략을 운용할 때 같은 수익률을 얻더라도 더 많은 이익을 얻을 수 있습니다. 여기에 Testing latency의 중요성이 있습니다.

Testing Latency를 줄이기 위한 전산적인 환경은 무엇이 있을까요?

첫째는 고성능의 틱데이타관리환경을 구축하는 일입니다. 이와 관련하여 다양한 의견이 있습니다. 10년쯤 HDF5를 소개한 것도 같은 맥락입니다.

Market Data와 HDF5

그렇다고 HDF5가 최적의 대안은 아닙니다. kdb와 같은 최고의 상용솔류션도 있고 아니면 칼럼기반의 메모리DB도 선택가능한 방안입니다.

메모리DB를 부담없이!

둘째는 백테스팅 환경을 구축하는 일입니다. Tradestation이나 Multichart와 같이 개인화한 툴에서 제공하는 서비스도 좋지만 DMA나 프랍 트레이더를 위한 전사적인 환경도 중요합니다. 이를 위한 두가지 방법이 가능합니다. 보통 Tradestation과 같은 툴이 제공하는 Programmable Loop Back Testing입니다. 주문메시지를 사전에 정의한 규칙에 따라 체결로 변환하여 시험하는 방법입니다. 아니면 Exchange Simulator입니다. 실거래소의 Order Book을 이용하여 체결을 하여 시험하는 방법입니다. 현재 ZeroAOS는 Exchange Simulator방식을 채용하고 있습니다. 우여곡절을 겪은 끝에 최종 시험을 하고 있습니다. 최종 시험을 거치면 서비스방식으로 공개하려고 합니다.

3.
다시 원점으로 돌아가보죠. 트레이더라면 다 알고 있는 내용을 Testing Latency라고 소개하였습니다. 표현을 달리하면 생각이 바뀌고 생각이 바뀌면 행동이 달라질 수 있습니다.

다양한 방식으로 Latency을 줄이는 노력을 하고 있습니다. Latency 경쟁입니다. 그렇지만 가장 본질적인 경쟁은 전략(Strategy)입니다. 전략을 실전에 투입하는 시간과 비용을 단축하는 노력, 이것이 Testing Latency입니다.

9 Comments

  1. 먼땅

    Exchange Simulator을 개발하실 때 지정가 순번 처리를 위해 체결정보를 활용하실거라 생각이 되는군요. 제 질문은 지정가 체결 메카니즘에서 취소율과 정정율 그리고 5호가 이상에 넣어둔 지정가의 순번 변화를 어떻게 처리하는지요? 추정을 해서 사용하시는 지 그리고 추정을 하신다면 어떤 방법론을 사용하시는지요?

    Reply
    1. smallake

      그렇게 복잡한 논리를 구성하지 않았습니다.

      우선 취소율과 정정율에 대한 정의는 없습니다. 5호가 이상 넘어가는 지정가에 대한 처리도 없습니다. 이런 저런 고민을 했지만 결국 한국거래소가 주는 호가잔량범위내에서 처리합니다. 다만 특정 시점에 5호가가 넘는 지정가 주문을 냈는데 거래소 호가가 변동하여 체결하는 일을 있을 듯 합니다. 논리구성에 예전에 소개하였던 penn project의 규칙을 적용하였습니다.

      시뮬레이터라고 하니까 거래소 시뮬레이션이 아닙니다. 한국거래소의 매매체결시스템을 약식으로 만들었다고 생각하시면 됩니다. 거래소와 동일한 Order Book을 만들기 위해 호가정보만을 사용합니다. 만약 거래소가 개별호가를 주면 100% 동일한 orderbook을 만들 수 있지만 5단계만 주기때문에 이 범위내의 가격에서만 체결합니다.

      그래서 최초 전제로 하신 체결정보는 사용하지 않습니다.

      사실 고민했던 것은 다른 것인데…(^^)

      Reply
  2. 먼땅

    당연히 모의 체결 시스템은 실제 order book을 사용합니다. 다만 실제 체결이 아니라 모의로 체결시키는 것이지요. playback Mode에서도 동일한 원리가 작동합니다. 다만 실데이터가 아니고 DB에서 호출되는 과거 데이터입니다.

    문제는 지정가로 주문(정정포함)을 모의 시스템에서 어떻게 실제와 비슷하게 체결시키는 가입니다. 저희는 현실보다 엄격하게 체결하도록 구성했습니다. 아무튼 주문처리전략을 테스트하기 위해서는 무엇보다 얼마나 실제와 비슷하게 지정가 주문을 체결시키는 가가 핵심이라고 생각합니다. 실제 체결률과 비슷하게 하기위해 모의 체결시스템에서 취소율/정정율을 어떻게 처리했는 지 물어보았던 것입니다^^

    Reply
    1. smallake

      realtime mode이든 playback mode이든 거래소의 호가데이타를 이용하는 것이니까 같은 원리라고 생각합니다. 저희는 DB를 직접이용하지 않습니다. Data Source가 어떤 형태이든 Market Data Feeder를 통하여 Simulator는 호가를 공급받습니다.

      저는 취소율과 정정율을 고민하지 않고 다른 방식으로 유사한 환경을 만들려고 했습니다.

      그리고 취소율과 정정율을 어떻게 할지는 전략에서 일정한 변수를 두어 모델화하여 시험하는 것이 좋은 방법이 아닐까 합니다. 저희 구조에서는 정정주문이든 취소주문이든 전략에서 나오기 때문에 전략내부에서 처리하는 것이 어떨까 합니다.

      물론 깊은 고민을 한 것은 아닙니다.

      Reply
  3. 먼땅

    취소율과 정정율을 다른 방향으로 이해한 것 같군요. 제가 언급한 취소와 정정은 모의 체결 시스템(실제 order book)에서 지정가 주문을 넣었을 때 앞에 호가 잔량이 다 소진한 후에 넣어 둔 지정가가 체결됩니다. 이때 지정가 주문 앞에 넣어둔 다른 참여자의 지정가 물량 중에 일부 물량이 취소되거나 또는 다른 호가로 정정될 수 있습니다 (1호가에서 멀리 떨어져 지정가 주문을 할 경우 더 문제가 됨). 제가 언급한 취소율과 정정율은 취소, 정정 물량이 호가 물량당 차지하는 비율을 말하는 것이었습니다.

    Reply
    1. smallake

      음. 이해를 했습니다. 말씀대로 정정율과 취소율을 정의하고 호가잔량별로 패러매터화할 수 있을 듯 합니다.

      두가지 문제가 저에게 있습니다.

      첫째 어떤 값으로 할지가 남을 듯 합니다. 말씀대로 취소와 정정에 따라 모형이 달라지는데 어떤 값이 좀더 좋은 모형를 판단하여야 하는데 그런 능력이 저에겐 없네요. 아마도 오랜시간 틱데이타를 분석하면서 분석을 해야 나올 수 있는 값이 아닐까 합니다. 즉, 트레이더가 사용할 수 있도록 취소와 정정율을 정의할 수 있는 환경변수까지는 만들 수 있지만 그 다음은 저의 몫은 아닌 듯 합니다.

      둘째 말씀처럼 하더라도 그것이 좋은 모형일지는 자신이 없네요. 역시나 첫번째와 같이 끊임없이 시험을 해보면서 어떤 모형이 나올 듯 합니다만…

      하여튼 좋은 의견을 받았네요. 어떤 논문을 보니까 비슷한 것을 주장하던데 그 때는 잘 이해가 되지 않았네요.

      현재 패러매터를 하나만 가지고 있는데 말씀대로 두가지를 더 넣으면 좋겠네요.

      감사합니다.(^^)

      Reply
    2. smallake

      그런데 의문이 드네요…말씀하신 정정, 취소비율이 결국 호가의 변화로 나타났죠. 거래소의 호가가 시간에 따라 변화는 이유가 체결뿐 아니라 정정,취소가 반영되었기때문이죠. 시간변수와 정정,취소율을 같이 볼 수 있지않을까요?

      이런 의문은 정정취소율을 적용하여 매매체결시스템을 구현하면 어떤 그림일까 의문이 들기때문입니다.

      또하나 모든 전략이 지정가주문만을 사용하는 것은 아닐 듯 합니다. 지정가, 시장가, 조건부지정가, 최유리지정가, 최우선지정가, IOC, FOK 등 다양한 주문과 조건을 사용하는데 이런 것들은 어떻게 처리할지..

      현재까지 개발한 모형은 거래소가 제공하는 모든 주문유형과 조건을 지원하고 시간변수를 둔다는 정도입니다.하여튼ㅋㅋㅋ

      Reply
  4. 먼땅

    주문 유형은 크게보면 시장가와 지정가로 구분할 수 있습니다. 다른 유형은 이것들의 변형들이라고 생각합니다. 시장가는 상대호가에 체결되니 문제는 없고요. 지정가 체결 문제만 해결되면 큰 문제없이 모든 유형의 주문들이 해결된다고 생각합니다. 다만 5호가 이상에 넣어둔 지정가는 앞서 대기한 잔량을 모른다는 사실입니다. 전체 잔량을 이용해 추정은 가능하게지만요^^

    시간을 (독립)변수로 사용할 수 있고 호가 움직임도 변수가 될 수 있겠죠^^

    Reply
    1. smallake

      시간에 따른 호가변화가 결국 취소와 정정율의 반영 아니냐는 뜻입니다.제가 정정 및 취소율을 변수로 두고 이를 체결에 반영하는 흐름을 잘 이해하지 못했을 수도 있을 듯 하네요.(^^)

      저도 좀더 여러가지 논문을 읽어보고 혹 기회가 되면 나중에 이야기를 해보시죠…

      좋은 이야기 잘 읽었습니다. 주말 잘 보내세요.

      Reply

Leave a Comment

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.