주문접수가 사라진 Exture+의 프로토콜?

1.
미루던 일은 드디어 시작했습니다. 자본시장IT사랑방 때 Exture+에서 달라지는 부분을 소개하기로 했기때문입니다. 처음 Exture+와 관련한 자료를 받았을 때 주문접수를 처리하는 통신방식이 Sync에서 Async로 바뀌는 것이 가장 큰 변화라고 생각했습니다. Sync인 조건에서 주문을 많이 처리하려고 도입했던 블록주문도 당연히 없어졌습니다.

그런데 유심히 살펴보니까 사라진 것이 있었습니다. ‘주문응답’입니다. 2013년 7월 1일자로 배포된 Exture+ 시장접속프로토콜 v2.2를 보면 주문응답이 보이지 않습니다. 딱 하나 일련번호가 틀렸을 때 주문거부를 줄 때뿐입니다. 그러면 Exture와 Exture+사이에 어떤 변화가 있는지 한국거래소의 자료를 통해 보겠습니다.

위의 것이 Exture입니다. 아래는 Exture+입니다. 차이를 아시겠습니까?

(*)덧붙임

혹시나 해서 추가로 더 살펴보았습니다. 먼저 주문서비스 업무흐름도입니다.

주문응답이 사라졌습니다. 그래서 주문응답의 전문을 담은 엑셀을 살펴보았습니다. Exture와 Exture+의 스펙이 거의 바뀌지 않았습니다.

엑셀전문을 보면 주문응답을 설계한 문제의식은 주문거부를 처리하기 위함으로 보입니다. 그런데 sync환경에서 주문을 처리하다가 보니까 주문거부 + 주문접수을 위한 전문으로 사용하였습니다. 그런데 Async로 바꾸면서 주문접수를 빼버리고 최초의 설계로 돌아간 것이 아닐까 추측해봅니다. 주문응답을 꼭 Sync이어야 처리가능한 업무인지 궁금하네요. Async라고 하더라도 체결처럼 처리하면 되는데…

2.
Low Latency Trading이라는 시대적 변화에 대응하기 위하여 추진한 프로젝트가 Exture+입니다. 그래서 매매체결속도를 두자리 마이크로초단위를 목표로 하고 있습니다. DMA와 같은 특화주문서비스를 이용하는 트레이디들은 속도측정을 기본으로 합니다. 현재의 조건에서 속도측정을 하는 방법은 아주 단순합니다.

주문시스템 주문송신시간 – FEP주문송신시간 – KRX주문접수시간 – FEP주문접수시간 – 주문시스템 주문접수시간 – KRX체결시간 – FEP체결접수시간 – 주문시스템체결접수시간

물론 시간동기화 등을 고려할 수 없는 조건이기때문에 상대값으로 비교합니다. 이중에서 가장 중요한 잣대가 주문접수시간입니다. Time/Price Priority중 주문접수는 Time Priority에 의하기때문입니다. KRX주문접수간을 주던 전문이 주문응답이었습니다. 만약 제가 v2.2를 이해한 것이 틀리지 않다면 앞으로 트레이더들이 알 수 있는 시간은 아래와 같습니다.

주문시스템 주문송신시간 – FEP주문송신시간 – KRX체결시간 – FEP체결접수시간 – 주문시스템체결접수시간

체결은 주문의 결과입니다. 과장을 생략한 결과를 보여줍니다. 체결시간은 중요하지 않습니다. 주문접수시간을 보면 대략 시장에서 자신의 주문이 주문접수큐에서 어떤 순서에 있는지를 추측할 수 있습니다. 앞으로 이런 행위를 못합니다. 할 수 있는 방법이 없습니다. 그렇다고 Order to Quote식으로 시세를 통하여 자신의 주문이 접수한 시간을 추정할 수 있는 시세정보도 주지 않습니다.

진짜로 주문응답이 사라진 것인가요? 제가 틀리길 바랍니다.

(*)덧붙임
3.
다시 문서를 읽었습니다. 주문응답이 사라졌는지, 제가 잘못 이해하였는지를 확인하였습니다.

아! 제가 오해한 부분이 나왔습니다.

ZeroAOS를 개발할 때 개발자와 제가 대화할 때 ‘주문응답’이라는 말을 사용합니다. 주문응답을 정확히 Exture+시장접속프로토콜에 맞추어 정의하면 ‘회원호가처리’입니다. 엑셀을 찾았습니다. 체결과 관련한 부분입니다. 체결전문으로 처리하는 업무중 회원호가처리가 있습니다. 아래는 Exture의 시장접속 프로토콜이지만 크게 달라지지 않았습니다.

이런 오해를 한 이유를 다시금 살폈습니다.

첫째 전문구조를 보면 Header와 Body로 나뉩니다. 전문 Header와 전문Body는 각각 Transaction Code를 사용합니다. 예를 들어 Header에서 사용하는 TCHODR00000(주문요청,주문응답),TCHTDP00000(체결)을 사용합니다. Body는 앞선 트랜잭션코드를 세부화한 코드를 사용합니다. TCHODR10001(호가입력,신규호가), TCHODR10002(호가입력,정정호가),TCHODR10003(호가입력,취소호가)입니다.

둘째 주문응답은 Header에만 있는 트랜잭션코드입니다. 이를 놓고 추측해보면 매매체결시스템을 설계하면서 거래소FEP를 위한 전문과 매매체결시스템을 위한 전문을 각각 정의하고 이를 하나의 포맷으로 만들어놓지 않았을까 추측해봅니다. 거래소FEP는 회원사FEP로부터 전문을 받아서 해당하는 매매체결시스템으로 주문을 보내는 역할을 합니다.여기서 FEP가 주문을 받지 못하는 경우가 있을 수 있을 수 있습니다. 일련번호가 빠진 경우입니다. 이런 경우를 대비하기 위하여 header에 주문응답을 만들어놓지 않았을까 합니다.

문제가 된 경우를 놓고 전문만 보면 이렇습니다.먼저 Exture의 경우입니다. TCHODR00000로 주문요청을 하고 거래소FEP가 매매체결에 조회를 하여 접수여부를 확인한 후 Header에 TCHODR00000를 담아서 주문응답을 줍니다. 이것이 FEP ACK라는 값입니다. 다음으로 체결쪽은 TCHODR10001와 같은 코드값을 가진 데이타가 들어옵니다. 이 값은 FEP가 아니라 매매체결엔진이 호가를 접수한 만든 데이타입니다. Exture+의 경우는 약간 다릅니다.TCHODR00000로 주문요청을 하고 거래소FEP는 일련번호이상이 있는 경우만 Header에 TCHODR00000를 담아서 주문응답을 주고 그렇지 않으면 아무런 응답을 주지 않습니다. FEP ACK가 없어집니다. 이후 체결쪽은 TCHODR10001와 같은 코드값을 가진 데이타가 들어옵니다. 이 값은 FEP가 아니라 매매체결엔진이 호가를 접수한 만든 데이타입니다. 이런 차이를 제가 이해하지 못했습니다.

주문시스템의 입장을 놓고 볼 때 주문응답은 두가지로 정의합니다.

첫째는 FEP접수시간입니다.
둘째는 매매체결접수시간입니다.

두가지 모두 주문시스템에 중요합니다. 저는 첫째와 둘째가 모두 빠진 것으로 오해했습니다. 그런데 다시금 문서를 읽어보니 FEP접수시간이 빠졌네요.

FEP접수시간이 의미가 있을까요? 없을까요?