1.
ZeroAOS를 설계할 때 전제는 DMA(Direct Market Access)입니다. 시세나 주문체결을 처리하는 프로세스도 DMA가 기준입니다. DMA시장이 커지고 있었고 레이턴시(Latency)가 중요한 경쟁력이 조건에 의해 선택한 기술적 구조입니다. 만약 시장이 계속 성장을 하였으면 비즈니스적인 고민은 다른 방향으로 향했을 듯 합니다. 현실은 반대입니다. DMA서비스가 계륵인 곳도 많습니다. 성장기때 무료로 제공하던 서비스가 유료로 바뀐 곳도 있습니다. 숫자를 중요시하는 경영환경에 따른 변화입니다. ZeroAOS서비스도 타격을 받았습니다. 매출이 곤두박질하였습니다. 여의도에서 6년을 버티기은 현재의 고민을 정리해서 방향을 찾고자 하는 노력이었습니다.
유가증권시장으로 방향을 틀고자 하였을 때 질문을 하였습니다.
“DMA환경으로 매매를 하는 투자자가 있을까?”
그래서 모바일 앱을 이용한 서비스로 나아갔습니다. 데이타사업자와 제휴를 하여 DIY형 로보어드바이저를 만들 구상을 하였슴니다. 발상의 전환을 한 계기는 ‘고객과의 대화’였습니다. 많은 증권사들이 미니원장을 경우하는 DMA서비스를 제공하지만 거래가능한 상품이 제한적입니다. 고객이 요청하는 상품을 거래하려면 DMA서비스를 제공해야 하는데 제공하지 않는다고 주저앉으면 새로운 고객을 확보할 수 없는 딜레마에 놓였습니다. 어떻게 할까, 고민을 하다가 이베스트투자증권이 리눅스용 API를 제공하는 소문을 떠올렸습니다.
만약 증권사가 제공하는 윈도우옹 API와 같은 기능중 ZeroAOS가 필요로 하는 기능만 리눅스로 구현하면 어떨까?
ZeroAOS는 HTS와 다른 시스템이라서 API중 많은 부분은 필요로 하지 않습니다.시세조회와 시세자동갱신, 주문체결송수신, 계좌조회와 같은 함수만 구현하면 됩니다. 오랜 동안 HTS를 개발했고 HTS미들웨어도 가지고 있기때문에 HTS통신구조를 분석하여 필요한 TR함수를 구현하는 것은 시간의 문제일 뿐입니다.
리눅스API를 개발한다고 하면 가장 먼저 떠오르는 의문이 ‘공인인증’일 듯 합니다. 2011년 BS투자증권 서비스를 개발할 때 비슷한 어려움을 겪었습니다. 여러가지 방법을 고민하다가 해결할 방법을 찾았습니다. 하나의 해결책이 아닌 여러 해결책이 가능할 듯 합니다.
2.
리눅스용 API를 직접 구현해서 ZeroAOS에 내장할 계획을 하니까 DMA기반의 ZeroAOS로는 상상할 수 없었던 서비스가 가능합니다.
먼저 멀티브로커(Broker)입니다. 코스콤이 제공하는 부산IDC를 제외하면 – 여의도에 있는 KT의 IDC도 가능할 수 있지만 – 외부의 데이타센터에서 여러곳의 증권사DMA서비스를 이용할 수 없습니다. 보안상의 이유입니다. 이 때문에 외국계 투자자를 제외하면 멀티브로커시스템은 그림의 떡입니다. 여러 증권사를 이용하더라도 각 증권사에 동일한 시스템을 설치해서 운영합니다. 그런데 증권사 API는 Open API입니다. 정해진 규칙만 따르면 어느 장소에서 누구라도 사용(Access)할 수 있습니다. ‘가’라는 투자자가 있습니다. 여러 증권사에 계좌가 있습니다. 각 증권사마다 HTS를 설치하여 모니터링할 수 있지만 비효율적입니다. Open API를 이용하고 DMA를 벗어던지면서 멀티브로커시스템이 현실화하였습니다.
둘째 멀티거래소(Exchange)입니다. DMA서비스는 미니원장과 전용FEP를 전제로 합니다. 지원하는 시장을 늘릴 때마다 별도의 IT투자를 필요로 합니다. 그랫 DMA서비스로 거래하는 상품은 제한적입니다. 그런데 API는 다릅니다. 대부분의 증권사가 유가증권부터 시작하여 국내파생상품, 해외파생상품을 거쳐서 FX까지 거래가능합니다. 멀티상품이고 멀티거래소입니다. 만약 증권사가 KRX뿐 아니라 HKeX(홍콩), TSE(일본) 및 CME등을 거래할 수 있도록 하고 이를 API로 제공하면 ZeroAOS도 역시 다 지원합니다. 로보어드바이저가 국내 주식, 국내ETF 및 해외ETF로 포트폴리오를 구성하면 주문관리시스템으로는 ZeroAOS 3.0이 딱 적합합니다.(^^)
셋째 자문형서비스입니다. 2015년 가을 어떤 자문사의 연락이 있었습니다. 비용때문이지 성사되지 않았지만 DMA서비스를 이용하여 복수의 계좌를 거래하는 방법을 문의받았습니다. 일임형자문서비스일 경우 여러 계좌를 관리하여야 합니다. 만약 고객들이 거래하는 증권사가 각각이라고 하면 복잡합니다. 어떤 자문사는 FIX프로토콜을 이용하여 주문관리시스템을 구축해서 해결한 사례가 있습니다만 IT투자를 해야 합니다. FIX가 아니라 API를 이용한 자문서비스라고 하면 비용이 줄지않을까요?
넷째 복수의 알고리즘와 복수의 계좌를 연결한 서비스입니다. 최초 BS투자증권과 제휴하여 ZeroAOS를 준비할 때 멀티계좌,멀티이용자, 멀티알고리즘 방식으로 설계하였습니다. A,B계좌는 ‘가’라는 알고리즘, C,D,E게좌는 ‘나’라는 알고리즘으로 매매할 수 있는 구조입니다. 멀티브로커와 연결하여 다양한 방식의 매매기법을 구현할 수 있습니다.
3.
오늘 쓴 검소한 혁신과 진화적 혁신중 Natural Innovation을 보면 Fidessa가 혁신을 하는 시작은 ‘고객’이었습니다. 인내를 갖고 고객의 요구를 분석하면서 혁신을 할 수 있는 업무를 발견(Discover)하였습니다.
왜 API를 이용할 생각을 못했을까?
이런 질문을 해보니 스스로 선입견에 사로잡혀 장벽을 쌓은 느낌이었습니다. 투자자를 자주 접하지 못한 저의 불찰입니다. 늦었지만 시작하였습니다. 그래서 ZeroAOS 3.0은 개발중입니다.
