1.
ZeroAOS의 1호 고객을 위한 마무리작업을 계속하고 있습니다. 아주 작지만 소중한 고객입니다. “One For All”이므로 마무리가 곧 서비스의 완성도를 높이는 일입니다. 이런저런 분들이 도와주셔서 상담 겸 설명을 하러 다닙니다. 현재 목표는 2012년 1월 1일 금융투자회사와 협력하에 일반트레이더용 서비스를 시작하는 것입니다.
지난 주 어떤 분이 찾아오셨습니다. ZeroAOS을 알아보기 위한 방문이었습니다. 두런두런 이야기를 한 후 헤어졌고 몇 일전 다시 만났습니다. 저도 잘 알고 시장점유율이 아주 높은 회사가 내놓은 차세대시스템 설명서를 가지고 오셨습니다. 남의 제품을 평가할 생각은 없습니다. 예의가 아닙니다. 다만 자료를 보면서 큰 차이는 느끼지 못했지만 색다른 점이 눈에 들어오더군요. “윈도우용 API를 제공한다”는 문구였습니다.
HFT와 비슷한 전략을 사용하는 트레이더들이 증권사 트레이딩팀으로 많이 옮겨가고 있다고 합니다. 아니면 증권사 트레이딩전략중 HFT전략의 비중이 커지고 있다는 이야기도 들립니다. 이 때문에 증권사 트레이딩팀들은 “자신의 전략을 노출하지 않고 AS-IS시스템에 탑재할 수 있는 방안”을 달라고 요구를 하고 있습니다. 전통적인 클라이언트/서버방식이고 클라이언트를 통하여 트레이더가 의사결정하는 시스템으론 한계가 있습니다. 이를 해결하여야 했고 내놓은 방안이 윈도우클라이언트API를 공급하는 서비스입니다.
HTS서비스가 진화한 모습과 동일합니다. 처음 다양한 화면을 통하여 의사결정을 하던 HTS는 빠른 속도로 개인투자자를 흡수하였습니다. 아무리 화면을 많이 만들어 제공한다고 하여도 모든 이를 만족시킬 수 없습니다. 특히 큰손들이 자신만의 전략을 녹인 화면을 요구합니다. 증권사는 별도의 화면을 만들어 개별적으로 배포를 하기도 하였습니다. 시간이 흘러 화면으로는 자신이 원하는 트레이딩전략을 구현하기 힘든 트레이더들이 생겨났습니다. 이들이 요구합니다. “내가 원하는 전략을 스스로 짤 수 있는 환경을 달라!” 그래서 탄생한 서비스가 트레이딩API입니다. API로 자신들이 원하는 전략을 스스로 구현하여 트레이딩을 할 수 있는 환경이 마련되었습니다. 그런데 나와 비슷한 전략을 사용하는 트레이더가 항상 나보다 먼저 호가물량을 가져갑니다. 기회가 눈앞에서 사라집니다. 무엇때문인지 고민을 합니다. 바로 DMA=Sponsored Access서비스를 받는 트레이더들이 있었습니다. Latency가 아주 중요한 경쟁요소가 되었습니다. 그리고 ELW수사가 이루어졌고 현재 재판이 진행중입니다. 모든 것이 멈춰버린 듯 하지만 수면아래에서는 Latency를 둘러싼 복잡한 수읽기가 이루어지고 있습니다. 출발은 ‘ELW추가건전화방안”에 담긴 다양한 서비스입니다.
2.
일반트레이더의 시스템인 HTS나 증권사 프랍트레이더의 시스템은 기술이나 철학적인 면에서 같은 바탕위에서 출발합니다. 그렇기 때문에 현재 자본시장에서 의미있는 역할을 하는 회사들을 보면 대부분 HTS와 프랍시스템 모두를 합니다. HTS의 API라는 발상은 프랍트레이더용 시스템의 API라는 개념으로 이어진 듯 합니다. 이제 다시금 HTS가 프랍트레이더용 시스템에서 영향을 받을 차례입니다.
현재 HTS API는 인터넷구간에 있는 트레이더의 컴퓨터에서 동작합니다. 대부분이 그렇습니다. 예외가 있었습니다. ELW트레이더를 위한 VIP서비스입니다. VIP서비스는 서버와 클라이언트가 인트라넷구간 혹은 DMZ구간에 위치하였습니다. Latency를 어느 정도 줄였습니다. 또한 트레이딩API를 이용하여 자신들의 전략을 탑재한 클라이언트를 개발하여 운영합니다.
ELW재판결과가 나와야 하지만 금융위와 금감원이 밝힌 감독규정이 달라지지 않는다고 하면 다음 단계의 API서비스는 VIP서비스의 대중화가 아닐까 합니다. 아마도 기계트레이더가 늘어나고 이에 전략적으로 대응하겠다라고 생각하면 가장 손쉽게 결정할 수 있는 방식이 “클라이언트 클라우드 서비스”입니다. VIP서비스처럼 트레이딩API를 이용하여 개발된 트레이더의 클라이언트를 증권사 DMZ구간에 설치된 클라우드서버에 운용하도록 하는 서비스입니다. 물론 감독규정이 허락하는 한 별도의 HTS서버와 가원장 및 FEP서버를 둘 수 있습니다. 이렇게 하면 ZeroAOS와 다른 HTS-AOS(그냥 제가 만든 이름입니다)가 탄생합니다.
이런 기획을 하고 있는 증권사가 있겠죠?(^^)
3.
얼마전 ZeroAOS설명회를 하였습니다. 질문중 하나가 “HTS API와 ZeroAOS가 어떤 차이가 있느냐” 였습니다. ZeroAOS나 HTS도 API를 제공하고 시스템도 DMZ에 위치하는데 차별요소가 있냐는 물음이었습니다.
ZeroAOS는 어떤 차별적인 가치를 제공할까요? ZeroAOS의 철학은 “트레이더에게 자유와 속도를 주자”는 것입니다.
속도향상=Low Latency를 위한 노력은 이렇습니다. 우선 ZeroAOS는 클라이언트/서버 구조가 아니라 Standalone에 가깝습니다. Application Layer를 최소화하여 어플리케이션간의 통신으로 인한 지연(Latency)를 최소화하였습니다. 또한 어쩔 수 없이 프로세스를 연결하여야 할 경우 – 시세와 주문 및 (가)원장서비스 -ZeroM을 이용하여 아주 빠른 방식의 데이타교환이 가능하도록 하였습니다. 출발는 HTS가 가질 수 밖에 없는 오버헤드를 줄일 수 있는 방법에 대한 문제의식이었습니다. 저는 ZeroM이라는 메시징을 선택하였습니다. 아마 HTS Platform을 가지고 계신 회사는 플랫폼개선으로 문제를 해결하는 듯 합니다. 서로 다른 방향이지만 목적은 하나입니다. Latency 단축입니다.
둘째는 메모리테이블입니다. Shared Memory이든 Local Memory이든 새로운 Hash Algorithm을 구현하여 나름 빠른 메모리테이블을 구현하였습니다. 오랜 시간을 투자하였지만 이유가 있습니다. 앞서 ZeroAOS는 스탠드얼론이라고 했습니다. 내부적으로 (가)원장이 제공하는 프로세스를 내부에서 처리하기 위하여 메모리에서 데이타를 관리합니다. 가원장시스템이 DBMS에서 MMDBMS로 나아갔고 다시금 shared memory로 나아간 것과 같습니다. 다만 shared memory를 구성할 때 좀더 빠른 알고리즘을 개발하여 시간을 단축시켜보자는 노력입니다.
트레이더에게 자유를 주기 위하여 노력한 부분은 ‘최소개발의 원칙’과 ‘최대시험의 원칙 그리고 ‘위험관리요소의 직접통제원칙’입니다. 전략을 제외한 나머지 부분은 서비스로 제공하여 트레이더가 전략개발에 집중할 수 있도록 하여 ‘최소개발의 원칙’을 구현하였습니다. Multichart나 Metatrade를 사용하는 트레이더들이 전략에 집중하는 것과 비슷한 개념입니다. 실거래환경이 아니더라도 다양한 방법으로 전략을 시험할 수 있는 시뮬레이션서비스를 제공하여 ‘최대시험의 원칙’을 반영하였습니다. 알고리즘에 의한 자동매매는 항상 위험에 노출되어 있습니다. 이 때문에 위험관리는 아주 중요합니다. 하여 국제기구나 해외거래소들이 권고하는 위험관리요소를 내장하였습니다. 반면 위험관리기능이 더해지면 질 수록 지연의 원인이 됩니다. 기술적으로 지연을 최소화하는 노력에 더하여 트레이더들이 자유롭게 위험요소를 관리할 수 있도록 하였습니다.
‘자유’와 ‘속도’. 너무 거창하지만 ZeroAOS가 지향하여야 할 가치라고 생각합니다.
다시 처음으로 돌아갑니다. 기계트레이더를 중심으로 한 시장이 커지고 감독규정이 허락을 한다고 하면 다양한 서비스가 생겨납니다. ZeroAOS도 있고 제가 이름을 붙였지만 HTS-AOS도 있습니다. 또다른 개념이 등장할 수 있습니다. 어떤 서비스가 생겨나든 HTS처럼 시장 독점으로 나아가서 증권사간의 차별성이 없어져서는 곤란합니다. 결국 서로가 서로의 살을 깍아먹었습니다. 그래서 저는 소수의 금융투자회사와 제휴를 하려고 합니다. 많은 곳을 하기보다는 작지만 알찬 서비스를 만들어 경쟁력을 높히고 파트너인 금융투자회사도 성장할 수 있는 모습을 만들어보고 싶습니다. 그것이 상생입니다. 물론 저의 꿈입니다만 꿈이 현실이도록 노력하려고 합니다.
(*)앞서 AOS를 기준으로 HTS-AOS라고 했는데 좀더 쉬운 말로 하면 Hosted-API서비스가 아닐가요? 지난 주말 문득 이런 생각이 들더군요.
