1.
알고리즘트레이딩시스템을 어떻게 설계할까? 소프트웨어 구조에 대한 명확한 정답은 없습니다. 예를 들어 몇 년전 알고리즘트레이딩이 처음 회자할 때 가장 관심을 받았던 기술은 CEP/ESP입니다. 소프트웨어 구조를 그리면서 CEP/ESP를 중심에 놓고 사고하였습니다. 시간이 흐르고 트레이더들의 요구가 명확해지면서 지금 CEP/ESP는 잊혀진 기술이 되었습니다.
다시금 소프트웨어구조로 돌아가보면, 핵심은 트레이더의 요구입니다. 폭포수방법론에 따르면 요구사항분석입니다. 기술적인 기능뿐 아니라 업무적인 기능을 포함한 요구사항입니다. 트레이딩을 Pre-Trade, Trade, Post-Trade로 구분해 보면 HTS나 MTS와 같은 시스템은 Trade에 중점을 둔 요구를 반영하고 있습니다. Pre-Trade, Post-Trade와 관련한 요구를 담지 않고 있습니다. 요구사항이 다르기때문입니다.
오늘 소개할 자료는 남아프리카공화국 출신으로 대학을 나와 2013년 KPMG에 입사한 Stuart Gordon Reid가 정리한 글입니다. 자신의 블로그인 Stuart Reid 에 올린 글이기도 합니다.
Algorithmic Trading Systems (ATs) ~ Part 1 Requirements
위의 글 이전에 쓴 Dissecting Algorithmic Trading systems (ATs)에서도 알고리즘트레이딩시스템에 대한 개념적 모델을 정리해놓고 있습니다. 아마도 학부 수업을 하면서 정리한 내용으로 보입니다. 글의 목차를 보면 사물을 접근하고 분석하는 법이 몸에 배인 듯 합니다.
2.
앞서 소개한 글은 남아프리카공화국 대학생의 글입니다. 또다른 글은 인도입니다. 한동안 인도는 HFT의 천국이었습니다. 미국과 유럽에서 밀려난 HFT업체들이 찾은 곳중 하나가 인도입니다. Samssara Capital Technologies이 “ALGORITHIMIC TRADING”이라는 제목으로 발행한 자료입니다.
3.
마지막으로 연구자들의 글입니다. Communications of the ACM의 November 2013 (Vol. 56, No. 11)에 실린 Algorithmic Trading Review를 소개합니다.
원문은 Algorithmic trading review을 참조하세요.
CEP/ESP를 algo. platform에서 사용하는 것은 alpha 전략을 손쉽게 prototyping 해서 1차적 검증을 해보는데는 여전히 유효한 접근인것 같습니다만 결국은 CEP/ESP language로 표현/구현 할수 있는 정밀함의 한계는 있고 미들웨어가 한 layer 더 끼어버리기 때문에 throughput과 latency 관점에서는 추가적인 engineering을 해줘야 한다는(engineering을 아무리해도 줄일수 없는 몇 마이크로 overhead가 있을수도 있구요) overhead가 있는것 같습니다. 이러한 trade-off 간에 어떠한 부분이 더 큰비용인지에 따라 CEP/ESP를 구조에 포함시키는건 시장에서 의미가 있을것 같긴한데, 이것만 된다면 한계가 있지 않을까요?
최근 Big Data Analytics의 영향으로 CEP/ESP와 같은 기능을 덧붙여 시스템 구성을 하기도 합니다만 전략에 따라 다르지 않을까 합니다. 그리고 만족스러운 성능을 보여주는 제품을 찾아야 하는데 그 또한 쉽지 않을 듯 합니다. 상용이 아닌 제품중에서 Esper정도는 사례가 있지만.DBMS가 CEP/ESP를 통합해나가고 있고 In-Memory기능을 도입한 제품을 선택한다면 비용이 작지 않아 보입니다.
CEP/ESP는 이벤트 소스가 매우 다양하고, 업무 규칙이 수시로 바뀌는 비지니스 프로세스 처리에는 적합할지 모르겠는데, 트레이딩 플랫폼으로서는 별로라고 생각합니다. 그 이유는 결국 이벤트 소스는 tick data 하나 밖에 없고, 트레이딩 규칙을 CEP/ESP 구문으로 짜면 트레이딩 규칙이 조금만 복잡해져도 속도가 느려지는데 트레이딩 규칙을 CEP/ESP구문으로 짠다고해서 작성이 더 쉬워지는 것도 딱히 없다고 생각합니다. 남는것은 모듈간 커뮤니케이션용으로 쓰는 것인데, 그것도 그냥 zeromq 등의 특화된 message queue 쓰는게 속도나 편의성 면에서 나은 것 같은데요.
CEP/ESP를 아주 좁게 이해하면 “실시간 데이타에서 내가 원하는 패턴을 찾아내는 것”으로 보면 대부분의 트레이딩시스템은 CEP/ESP와 비슷한 기능을 하는 부분이 있습니다. 그것을 CEP/ESP라는 제품군으로 구현할지 아닐지는 전적으로 전략에 달렸다고 생각합니다. 속도보다는 전략적 유연성이 필요하다고 하면 CQL 등을 이용한 구현이 훨씬더 유용하겠죠. 또한 대용량 과거데이타와 실시간데이타를 통합한 이벤트처리를 하더라도 DBMS와 CEP를 통합한 제품이 좋겠죠. 당연히 가격도 고려해야 합니다.
IT와 관련한 일을 하지만 기술이 아니라 요구가 기준이라고 생각합니다.
Hi, thanks for including a link to my work on your blog. I have just published part 2 here: http://www.stuartreid.co.za/algorithmic-trading-systems-ats-part-2-architecture/
Thanks for your comment and new work.
I think, your works are very very useful to korean traders and software developers.