ZeroAOS API와 기술적 배경

1.
매매를 위한 필요한 정보는 다양하지만 가장 기본적인 정보는 시세, 주문/체결 및 계좌정보입니다. 시세(Market Data Management)는 거래하고자 하는 종목이 시장에서 어떤 흐름을 보이고 있는지를 알고 매매시점을 찾기 위해 필요합니다. 주문과 체결정보(Order Management, Position Management)는 투자자의 거래 현황 – 어떤 주문을 내었고 주문은 현재 어떤 상황인지 -을 알려주는 정보입니다. 계좌정보(Money Management)는 투자금의 현황을 알려줍니다. 이외에 경제뉴스, 공시 혹은 통계자료 등이 있지만 기본은 세가지입니다. 어떤 유형의 매매시스템을 구축하더라도 세가지 정보를 관리하여야 온전한 매매시스템이라고 할 수 있습니다.

증권선물사는 투자자들의 주문을 수탁하기 위하여 매매시스템을 갖추고 있습니다. 회사들마다 상세한 구조는 차이가 있지만 큰 그림으로 보면 아래와 같습니다. 주문체결을 주고 받기 위하여 한국거래소와 연결하여야 하고 시세정보를 받기 위하여 코스콤의 시세분배시스템과 연결하여야 합니다. 넓은 의미로 FEP(Front End Processor)라고 부릅니다. 또한 금융투자회사가 고객들의 주문을 수탁하기 위하여 원장시스템을 갖춥니다. 또한 전자적인 주문을 내기 위한 고객을 위한 서비스로써 HTS시스템을 구축합니다. 2012년 5월 한국거래소의 주문수탁제도가 바뀌면서 DMA라고 하는 특화주문서비스를 제공하고 있습니다.

90년대 후반 HTS가 등장한 이후 온라인매매 혹은 전자적인 매매는 보편적인 트레이딩의 방식입니다. 스마트폰이 대중화하면서 HTS가 MTS으로 변화하고 있지만 기술로 보면 뿌리는 HTS입니다. HTS는 Home Trading System의 약자이며 매매에 대한 전문적인 지식이 없다고 하더라도 투자자 스스로가 매매를 할 수 있도록 의사결정을 지원할 수 있는 다양한 정보를 제공하는 트레이딩서비스입니다. HTS는 매매에 필요한 데이타, 특히 시세정보를 투자가가 쉽게 이해하고 분석할 수 있도록 다양한 방식으로 가공하여 제공하는 서비스입니다. 현재가, 관심종목, 순위정보, 차트 등입니다. 주문체결정보도 투자자가 눈으로 보고 분석한 후 의사결정=매매조건을 쉽게 반영하는 방향으로 구현하였습니다. 넓은 의미로 Point & Click 방식의 매매에 최적화한 시스템입니다. 매매기법으로 보면 투자자의 경혐과 판단을 상황에 맞춰 시의 적절하게 반영하여 매매를 하는 Discretionary Trading (주관적 매매)를 위해 최적화한 시스템입니다. 그렇지만 어느 때부터 새로운 요구가 나옵니다. 계량화 가능한 지표를 바탕으로 규칙성 있는 원칙을 작성하여 매매를 수행하는 Systematic Trading (시스템 매매)입니다. 물론 HTS가 등장했던 때부터 Tradestation과 같은 도구들이 이전에도 있었지만 대중적이지 않았습니다. HTS가 주관적인 매매뿐 아니라 시스템적 매매까지를 포괄하는 방향으로 변화가 일어났고 현재에 이르고 있습니다.

2.
시스템적 매매를 하고자 하는 투자가가 HTS에서 이용할 수 있는 수단은 두가지입니다. 첫째는 Easy Language나 MQL과 같은 Trading Script Language를 이용하는 방법입니다. 둘째는 Automatic Built-In Strategy서비스(예를 들면 Stop-Loss전략)를 이용하는 방법입니다. 문제는 이런 방식에 만족하지 못하는 트레이더들이 있습니다. 일반적인 프로그래밍언어를 이용하여 ‘나만의 전략’을 개발하여 매매를 하고자 하는 투자자입니다. 이들을 위한 서비스가 API=Application Programming Interface입니다.

현재 한국자본시장에서 투자자가 매매시스템을 직접 개발할 때 이용가능한 API는 두가지입니다.

첫째는 HTS API입니다. 대부분의 증권사가 제공하고 있는 서비스입니다. HTS라는 수식어를 붙인 이유는 HTS 클라이언트를 구축하기 위하여 사용한 라이브러리를 이용하였기때문입니다. 쉽게 말하면 HTS 클라이언트에서 화면을 빼고 제공한 서비스입니다. TR=Transaction이 HTS API의 근간입니다. 이트레이드증권 Xing API문서는 TR을 아래와 같이 정의합니다.

TR= Transaction의 약자로 서버로부터 데이터를 얻기 위해 요청하고 데이터를 받는 일련의 행동

무엇을 요청하면 무엇을 주는 방식으로 이루어진 HTS API는 크게 두가지 유형이 있습니다. 대신증권이 제공하는 Cybosplus의 도움말을 보면 다음과 같은 설명이 있습니다. Request/Reply와 Publish/Subscribe입니다. RR방식은 DB데이타 요청, Pub/Sub는 실시간 요청을 위한 통신방식입니다.

이를 흐름도로 그리면 아래와 같습니다.Xing API를 제공하는 이트레이드증권이 제공하는 그림입니다. 조회성 TR이 RR방식이고 실시간TR은 Pub/Sub방식입니다.

보통 HTS클라이언트의 현재가 화면을 개발할 때 먼저 조회하는 시점의 현재가를 가져오기 위한 TR을 호출합니다. 대신증권의 경우 ‘StockMst’입니다. 이 때 조회한 이후 달라지는 정보를 받기 위해 두가지 선택이 가능합니다. 클라이언트가 데이타를 요청하는 Poll방식과 서버에서 변경한 데이타를 내려주는 Push방식입니다. Comet과 같은 기술이 나오기 전에 WTS는 Poll을 사용했습니다. 반면 HTS는 Push방식을 사용했습니다. 달라지는 데이타를 그냥 보내주면 되지 왜 절차를 두었을까요? Push도 여러가지가 있습니다. Peer-2-Peer, Publish/subscribe 및 Broadcast입니다. P2P는 카카오톡으로 1대1대화를 할 경우 사용하는 방식입니다. Publish/Subscribe는 특정한 그룹끼리 대화를 할 경우 Pub/Sub라고 합니다. Broadcast는 서버장애로 카카오톡 관리자가 전체 이용자에게 알람을 보내는 경우입니다. 이를 트레이딩에 적용해보죠. 유한양행(000100)의 현재가를 조회하였습니다. 현재 HTS를 이용하는 투자가가 이만명이고 이중에서 10명정도만 유한양행의 체결과 호가데이타를 원한다고 하죠. Push를 하고자 하는 시스템의 입장에서 어떤 프로그램이 0001000을 원하는지 알아야 합니다. 그래서 Push방식이 Pub/Sub이고 subscibe는 ‘나에게 보내주세요’라는 뜻입니다.HTS 클라이언트는 RR후 Pub/Sub를 자동적으로 하도록 설계했지만 API를 이용할 경우 RR없이 Pub/Sub를 통하여 실시간 데이타를 받을 수 있습니다. 시세만 아니라 주문과 체결도 같습니다. 주문은 RR방식, 체결은 Pub/Sub을 사용합니다. 계좌정보의 경우 대부분 RR방식입니다. 실시간 잔고의 경우 시세를 가지고 실시간으로 평가하기 때문에 잔고정보를 RR로 받은 후 잔고에 있는 종목을 Pub/Sub로 Push 요청을 합니다. 이상이 가장 많은 투자자가 이용하는 HTS API의 원리입니다.

두번째는 KRX API입니다. 흔히 DMA API라고 하기도 합니다. 다만 DMA는 투자자 주문시스템의 지리적 위치를 담은 개념이라 정확하지 않습니다. DMA서비스=특화서비스라고 하지만 HTS를 통하여 시세,주문,체결서비스를 제공하는 경우 전산적으로 보면 HTS API와 다르지 않습니다. 그래서 전산적으로 다른 점을 강조하기 위하여 KRX API라고 이름을 붙였습니다. FEP와 시세분배스위치를 통하여 한국거래소가 제공하는 원데이타를 이용하는 API라는 의미입니다. 증권사의 전산시스템 구조중 하단에 해당하는 개념입니다. KRX라는 말을 사용했기때문에 어느 증권사나 선물사의 DMA서비스를 이용하더라도 KRX API는 다 같다고 오해하는 경우가 있습니다. 코스콤의 시세분배시스템이 제공하는 시세를 그대로 DMA 고객에 제공한다고 하면 전 회원사의 시세 API는 같습니다. 그렇지만 주문체결은 다릅니다. KRX와 주문체결전문을 처리하기 위한 표준은 Exture 시장접속프로토콜(KRX Market Access Protocol) 1.5입니다. 이 때문에 앞서 지적한 FEP중 KRX 접속부의 경우 전 회원사가 같습니다. 반면 FEP의 후반부인 사내시스템과의 Interface는 같지 않습니다. DMA 시스템은 FEP 후반부를 통하여 KRX에 접속합니다. 따라서 KRX API중 주문체결과 관련한 프로토콜은 증권사마다 다릅니다. 만약 Money Management를 하려고 하면 원장시스템과 Interface를 한다고 하면 이 또한 회원사별로 다릅니다. DMA서비스를 이용하기 위한 KRX API는 증권사와 선물사마다 다릅니다.

3.
그러면 HTS API와 KRX API는 어떤 차이가 있을까요?

첫째 HTS API가 제공하는 통신방식을 빌어 설명하면 KRX API의 경우 TR=Transaction과 같은 데이타요청이 없습니다. 물론 계좌와 같은 경우 TR방식이지만 가장 중요한 시세와 주문체결의 경우 TR이 아닙니다. TR이 없기때문에 FEP(혹은 미니원장)이 보내주는 실시간데이타를 소켓을 이용하여 직접 받아야 합니다. 다시말하면 Stream Data Processing을 하여야 합니다. 또한 받은 데이타를 이용하여 직접 주문체결, 포지션 및 손익관리를 할 수 있도록 해야 합니다. Dada Layer를 구성하여 Processing Layer도 구축하여야 합니다. 이 때문에 HTS API에 비하여 상품/주문체결과 관련한 업무지식을 필요로 하고 전산적인 능력도 있어야 합니다.이 때문에 온전한 방식의 DMA를 이용하고자 할 경우 기술적인 진입장벽이 존재합니다. 기술은 곧 비용이기때문에 자본규모도 중요합니다.

둘째 HTS API는 API라는 이름에 걸맞게 프로그래머가 사용할 수 있는 DLL 혹은 COM방식 라이브러리를 제공합니다. 반면 DMA서비스를 제공하는 증권사나 선물사중 KRX API를 제공하는 곳은 없습니다. 오직 스펙과 프로토콜만 있습니다. HTS의 TR에 익숙하면 KRX API는 KRX가 제공하는 데이타를 그대로 사용하기 때문에 불편합니다. 그래서 KRX API를 이해하는 첫걸음은 KRX가 사용하는 포맷과 프로토콜을 이해하는 것입니다.

시세분배시스템을 운영하고 있는 코스콤은 Specworks를 통하여 시세정보의 포맷을 제공하고 있습니다. 아니면 증권사나 선물사의 DMA 담당자에게 문의하면 받을 수 있습니다. 주문체결과 관련한 프로토콜은 증권사마다 다르다고 했지만 KRX의 KMAP를 변형한 것입니다. KRX의 프로토콜을 이해하면 쉽습니다.

KRX Exture 시장접속프로토콜 V1.5
Exture와 매매전문(최종자료)

3.
서론이 길었습니다. 이제 본론으로 들어갑니다.

ZeroAOS는 DMA트레이딩을 위한 시스템이면서 서비스입니다. ZeroAOS는 HTS API를 기반으로 하지 않고 KRX 프로토콜를 기반으로 하고 있습니다. 특정한 증권사나 선물사의 HTS에 종속적이지 않습니다. KRX 프로토콜을 이해하고 있다면 ZeroAOS는 쉽게 이용할 수 있습니다.

ZeroAOS는 다음과 같은 서비스로 이루어져 있습니다.

첫째 ZeroFeeder로 시세분배시스템-시세스위치로부터 받은 시세를 ZeroOMS와 ZTerminal이 이용할 수 있도록 분배하는 시세서비스입니다.
둘째 ZeroOMS로 자동매매전략,전략관리,주문체결관리,포지션관리, 위험관리,증거금관리,계좌관리등을 제공하는 매매서비스입니다.
셋째 ZeroBOG로 증권,선물사의 FEP와의 Interface를 맡아 주문체결데이타를 주고 받는 게이트웨이서비스입니다.
넷째 ZTerminal로 전략관리,계좌관리, 주문체결, 포지션, 계좌잔고 모니터링을 위한 기능을 제공하고 시세조회와 손매매도 가능한 트레이더용 UI서비스입니다.
마지막 ZeroM으로 ZeroFeeder,ZeroOMS,ZeroBOG 그리고 ZeroTerminal사의 통신을 담당하는 미들웨어입니다.

ZeroAOS를 이용하는 트레이더가 자신의 전략을 설치하고 운영하기 위하여 제공하는 ZeroAOS API는 두가지로 제공합니다.

첫째는 Visual C++ Source와 Dll로 이루어진 ZTerminal API입니다.
둘째는 ZeroOMS에서 가동할 전략개발을 위한 ZeroOMS API입니다.

ZeroAOS API는 ZeroM API를 이용합니다. ZeroM은 Exture+를 개발하기 위하여 KRX가 도입한 오픈소스인 ZeroMQ와 비슷한 역할을 합니다. Tibco사의 Rendezvous와 같은 MOM=Message Oriented Middleware입니다. ZeroM은 TCP/IP와 IPC를 지원하고 Peer2Peer, Publish/Subscribe 및 Request/Reply와 같은 통신방식을 지원합니다.이를 위한 함수는 아래와 같습니다.

ZMconnect()
ZMdisconnect()
ZMsetSubscribe()
ZMpubMsg()
ZMsubMsg()
ZMgetIPC()
ZMpubIPC()
ZMsubIPC()
ZMrequestMsg()
ZMrecvRequest()
ZMreplyMsg()
ZMopenTopic()
ZMcloseTopic()

일반적으로 MOM을 이용하여 시스템을 개발할 때 서로 다른 데이타유형을 구분하기 위하여 Topic을 정의합니다. Topic을 HTS의 TR로 이해하면 비슷합니다. 예를 들어 대신증권 Cybosplus API의 현재가 TR은 ‘StockMST’입니다. 이에 대응하는 Topic은 현재 ZeroAOS에 존재하지 않습니다. 대신 시세분배시스템이 제공하는 데이타유형중 유가증권/호가정보를 받고자 할 때는 Topic을 ‘/ZeroAOS/ZF/0/KRX/SPI/STK/QUOTE’로 정의하고 ZMopenTopic()을 하면 호가데이타 스트림(Stream)을 받을 수 있습니다.

ZeroAOS API는 ZeroM API를 기초로 트레이더가 원하는 업무별 데이타 스트림을 받아서 필요한 프로세싱(전략 혹은 의사결정 화면 등)을 하도록 하는 기능을 제공합니다. ZeroOMS API는 Linux C로 개발할 수 있는 헤더 및 오브젝트파일을 제공하고 ZTerminal API는 Visual C++로 개발할 수 있는 Dll과 헤더파일을 제공합니다. 물론 문서도 제공합니다.

다음은 ZeroAOS API에 대한 자세한 설명입니다.