미니원장 vs. 개인원장

1.
자본시장IT와 관련한 업무중 경험해보지 못한 일이 백오피스와 관련한 일입니다. 다른 것을 떠나서 제도와 회계와 관련한 일은 재미도 없고 기술적인 흥미도 없습니다. 아주 개인적인 취향입니다. 그래서 ‘원장’시스템이란 말은 무척이나 낯섭니다. 아마 99년쯤으로 기억합니다. H투자증권이 HTS를 구축하고 이어서 원장이관프로젝트를 진행한다고 하였습니다. 이미 구축한 HTS를 유지하느냐 마느냐 하면서 ?논란이 있었고 원장시스템에 맞게끔 재구축으로 결정이 났습니다. ?원장시스템이 트레이딩시스템을 결정하였습니다. 이 시절은 그랬습니다.??이후 원장시스템과 놀 기회가 없다가 마진FX시스템을 구축하면서 ‘원장’이라는 맛을 보았죠. 사실 회계가 없는 시스템을 원장이라고 해야 하는지 의심이 듭니다. 정확히 말하면 주문관리시스템에 몇 기능을 더한 수준입니다.

다시 몇 년이 흘러 전 직장에 다닐 때 ‘가원장’이란 단어를 들었습니다. 원장을 이관한 회사도 있지만 비이관한 회사도 많습니다. 저의 기억엔 비이관한 회사가 주문체결정보를 처리할 때 코스콤 원장에서 전문을 보냈습니다. 그런데 코스콤과 계약에 따르면 사용료는 전문의 숫자에 비례한다고 하더군요. 이 때문에 가원장이 등장하였다고 합니다. ?비용을 절감하고 속도도 빠르게 하기 위해서 주문체결과 관련한 데이타를 자체적으로 관리하고 조회와 관련한 업무가 곧 자체원장=가원장입니다. HTS를 구축할 때 요건중 하나였습니다. 제가 기억하는 가원장은 이렇습니다. 만약 자체원장을 가진 증권사가 고객을 위해 따로 원장시스템을 구축한다고 하면 이 또한 가원장입니다. 순전히 속도만을 위하여 원장을 개발합니다. ELW 스캘퍼용 시스템이나 선물사의 VIP시스템이 이런 경우였습니다.

가원장은 증권사의 필요에 의해 만들어진 서비스입니다. 그렇지만 2012년 4월 주문수탁제도가 바뀌면서 미니원장이라는 말로 공식화하였습니다. 가원장은 가짜 혹은 거짓이라는 느낌을 주지만 미니원장은 작다는 느낌으로 고객에서 신뢰감을 줍니다. ?이렇게 전사적 원장에서 미니원장의 시대로 진인하고 있습니다.

2.

ELW스캘퍼를 위한 가원장서비스를 두고 설왕설래하던 2011년 봄 어떤 분하고 미니원장을 두고 토론을 하였습니다. ZeroAOS의 요건과 관련한 부분이었습니다. 저는 속도를 위해서는 원장을 주문관리시스템에 두어야 한다고 생각했습니다. 그래서 ZeroAOS의 기능을 정의하면서 전략 + 주문관리 + 위험관리로 하였고 위험관리중 증거금을 포함하였습니다. 저는 이를 ‘개인원장’이라고 이름 붙였습니다. 반면 다른 분은 주문관리시스템은 그대로 두고 원장과 FEP를 통합한 형태로 원장을 구성하자고 하였습니다. 위험관리를 통합하여야 한다는 생각때문에 개인원장을 반대하였습니다. 우리끼리는 개인원장 vs. 미니원장 논쟁이라고 합니다.?이 때 합의한 의견은 없습니다. 다만 각자 생각한 대로 시스템을 구축하였습니다. 저는 위험관리중 증거금관리만을 뺀 상태로 ZeroAOS의 요건을 정의하였고 오늘에 이릅니다.

지난 4월 주문수탁제도가 바뀐 이전부터 DMA영업을 활발히 하였던 곳이나 영업을 준비하는 곳에서 미니원장을 프로젝트로 발주하고 있는 듯 합니다. 제가 본 요건정의는 이렇습니다.

?미니원장 = 주문관리 + 주문유효성 + 위험관리 + 증거금관리

이중 위험관리가 보편적인지는 확실하지 않지만 DMA서비스의 특성상 영업사원이 특별한 경우 주문에 개입하여야 할 필요성 때문에 위험관리를 두는 것이 보편적입니다. 이상은 기능요건입니다. 여기에 ?주문처리부터 FEP로 주문을 보낼 때까지 몇 마이크로초이내이어야 한다는 기술요건을 더합니다.

앞서 적었지만 원장시스템에 대한 이해가 부족합니다. 주문증거금처리를 어떤 방식으로 하는지도 잘 몰랐습니다. 그러다 전사적 원장이 어떻게 처리하는지를 들을 기회가 있었습니다. 우선 미니원장과 전사 원장은 전제가 다릅니다. 전사 원장은 자유로운 입출금이 전제입니다. 대용을 잡아서 예수금을 늘릴 수 있고 출금으로 예수금이 빠질 수도 있습니다. 주문을 받았을 때 이런 전제를 가지고 계산을 하여야 합니다. 주문체결수량뿐 아니라 돈과 관련한 모든 값이 변수입니다. 때문에 SQL로 하든 C/C++로 개발하든 빠른 처리가 쉽지 않다고 합니다. 반면 미니원장은 말 그대로 미니원장입니다. 모든 입출금을 배제합니다. 전일 배치처리한 값에서 출발합니다. 중간에 입금이 있든 출금이 있든 미니원장에 반영하지 않습니다. 때문에 빠른 처리가 가능합니다. 이런 전제를 놓고 주문시 ?미니원장처리속도를 계산하면 한자리숫자가 나올 수 있습니다. 증거금이 바뀌는 때는 체결전문을 받을 때이고 주문전문을 보낼 때는 이미 계산한 값을 가지고 단순연산만 하기때문입니다.??이상과 같이 데이타흐름을 정의하면 속도를 빨리하기 위한 기술은 단순합니다. Shared Memory를 잘 활용하고 데이타구조를 잘 만들어 속도를 빨리 하면 됩니다. 필요할 경우 CPU에 종속적인 Assembly언어도 사용합니다. 미니원장 서버는 CPU클락이 가장 높은 장비를 선택합니다.

이상과 같이 하면 다른 곳과 비교하면 비슷한 수준의 미니원장시스템을 만들 수 있습니다. 그런데 미니원장과 FEP도 다른 곳과 비교하여 Latency를 줄어야 합니다. 다른 방법이 없을까요? 저의 대안은 여전히 ‘개인원장’입니다.

3.
DMA서비스 혹은 속도 빠른 특화서비스를 구성할 때 후선업무의 요건은 이렇습니다.

빠른 후선업무 = 주문관리 + 주문유효성 + 위험관리 + 증거금관리 + FEP

앞서 미니원장과 똑 같습니다. 그렇지만 미니원장이라는 말때문에 선입견을 가지지 말고 그냥 서비스를 구성한다고 해보죠. 속도를 빠르게 하기 위한 가장 쉬운 방법중 하나는 처리하는 데이타를 줄이는 것입니다. 미니원장이 몇 명 혹은 몇 십명의 고객정보를 관리하는지 똑같을 수 없지만 고객당 주문체결데이타는 일반고객에 비해 아주 많습니다. 주문만 하루 몇 천건이 넘어섭니다. 주문중 정정도 있고 취소도 있습니다. 체결은 더 많습니다. 부분체결은 아주 많습니다. 개인원장은 데이타처리를 개인중심으로 하자는 이야기입니다. 미니원장과 개인원장의 insert, update속도가 당연히 다르지 않을까요?

또하나 증거금관리도 표준형이 아니라 개인형으로 최적화할 수 있습니다. 투자자별로 거래하는 상품은 제한적입니다. 지수선물만 하는 고객도 있고 지수선물과 옵션을 하는 고객 혹은 주식선물 혹은 ETF만 할 수 있습니다. 각각 어떤 상품을 거래하느냐에 따라 최소 순위험유지증거금 계산속도를 달리할 수 있습니다.

여기에 하나더 잇점을 만들 수 있습니다. 미니원장이 아니라 개인원장일 경우 고객의 주문시스템과 개인원장을 일체형으로 가져갈 수 있습니다. 고객을 기준으로 놓고 주문시스템 – 원장 – FEP는 두가지 모델이 가능합니다. 주문시스템-원장의 일체형, 원장-FEP의 일체형입니다. 물론 모두를 분리한 경우가 있지만 제외합니다. 주문-원자의 일체형이 원장-FEP일체형보다 좋은 점이 있습니다. 위험에 노출될 경우 반응속도가 빠릅니다. 방화벽을 통과하지 않고 TCP/IP통신을 하지 않습니다. IPC로 전문을 주고 받고 위험시 바로 응답을 받아 전략에 다시 주문을 만듭니다. 전략이 다양한 변화에 빨리 대응하도록 해줍니다.

그래도 찜찜할 수 있습니다. 앞서 반대한 분의 논거였던 중앙집중화한 위험관리입니다. 그렇지만 개인원장이라고 하여 중앙집중화한 위험관리가 불가능하지 않습니다. ?오히려 메시징방식을 통하면 다양한 시스템하에서도 중앙집중화한 위험관리시스템을 만들 수 있습니다. ZeroAOS는 그렇게 하고 있습니다.

4.
ZeroAOS는 이런 발상을 기초로 합니다. 그런데 증권사와 협의할 때 문제가 생겼습니다. 개인(미니)원장에서 발생할 수 있는 위험의 책임소재(R&R)입니다. 현재 한국거래소는 주문유효성검사를 소홀히 한 회원사에 경고와 같은 징계를 줍니다. 때문에 증권사IT가 직접 개발하고 유지보수하지 않는 서비스를 인정하기 쉽지 않습니다. 당연합니다. 때문에 ZeroAOS내 증거금서비스를 제공하지 않고 있습니다.

다만 이런 발상은 어떨까요? FEP API를 제공하는 증권사들이 많습니다. 사후증거금계좌인 외국계 투자자를 위한 서비스입니다. FEP API를 가진 사전증거금계좌인 투자자가 주문 및 원장 일체형 시스템을 가지고 와서 주문을 내겠다고 해보죠. 받아드려야 할까요? 말아야 할까요? 영업은 “하자”고 하고 IT는 “안된다”고 할 확률이 높습니다. IT가 “안된다”고 하지 말고 ‘인증제도’를 두면 어떨까요?

FEP에 주문시스템을 붙일 때 시나리오에 따라 다양한 기능을 점검합니다. 체크리스트를 작성하여 하나라도 통과하지 못하면 FEP에 접속을 허가하지 않습니다. 동일한 원리입니다. 체크리스트에 주문유효성과 증거금과 관련한 항목을 추가하여 같은 인증절차를 만듭니다. 여기에 혹 있을 수도 있을 미신고 변경때문에 장전 FEP접속시 위와 같은 시나리오에 따른 온라인시험을 합니다. 그러면 IT가 우려하는 위험을 회피할 수 있지않을까요?