증권회사 api 선택시 고려 사항
속도
com은 쉽게 이용할 수 있는 대신 느리다. com은 component object model의 머리글자인데 이름만 봐서는 이해하기가 어렵다. 마이크로소프트는 여러 플랫폼들 사이에서 쉽게 데이터를 오가게 하기 위해 이걸 만들었지만 실패했다. 지금은 윈도우즈 안에서만 일부 애플리케이션들 사이에서 데이터 전송을 하는 데에 이용된다. 윈도우즈 중급 이상 수준이 되는 사람이라면 ole는 들어봤을 거다. com, ole, 액티브x, ocx는 사실상 모두 같은 기술이다. 대부분의 사람들은 모를 텐데 인터넷 익스플로러는 맥os와 리눅스 버전으로도 나왔었다. 액티브x를 적용하면 인터넷 익스플로러에서 실행되는 기능을 구현할 수 있다. 인터넷 익스플로러만 설치되어 있다면 os나 플랫폼에 상관없이 실행할 수 있었으니 마치 자바 버추얼 머신이나 .네트와 비슷한 개념이었다. ocx는 ole control extension의 머리글자로 이건 이름만 봐도 대충 뭔질 알 수 있다. 모두 폐기 직전의 기술들이다. 보편적인 호환성을 갖는 것은 거의 예외 없이 성능 저하를 감수해야 한다.
속도가 느리다, 성능이 떨어진다 하는 얘기는 구체적으로는 cpu나 메모리 점유를 많이 한다는 소리다. 하드웨어 이용률이 높다는 건 처리에 더 긴 시간이 걸린다는 뜻이고 이러한 정도가 심하면 처리해야 할 작업이 아예 사라져 버릴 수도 있다. 윈도우즈 안에서 일어나는 일들은 message라는 걸 통해서 처리된다. 윈도우즈가 처리할 수 있는 메시지 큐의 용량에는 한계가 있다. 현재 코스피와 코스닥 종목들의 수를 합하면 3천 개 정도 되는데 이것들 모두의 가격과 호가 변경 데이터를 실시간으로 처리하려면 윈도우즈가 감당할 수 있는 한계를 쉽게 넘어선다. 특히 호가의 경우 20개 호가들의 값이 하나라도 변하면 이벤트가 실행되기 때문에 그 발생 빈도가 무척 잦다. 시장이 조용할 땐 괜찮지만 급변할 때에는 처리가 느려지며 수신된 패킷들이 소실된다. com을 이용하면 이런 정도가 특히 심하다.
com의 문제를 피하려면 com 아닌 api나 리눅스용 api를 쓰면 된다. 리눅스는 메시지 처리 능력이 윈도우즈의 그것보다 뛰어나다. 모든 증권회사들은 com api를 제공하며 이베스트투자증권과 조그만 증권회사 하나만 com 아닌 api를 같이 제공한다. 이들 회사의 api는 거의 같다. 한 회사가 개발한 거다. 리눅스용 api 역시 대부분의 증권회사들이 가지고는 있지만 제한적으로 제공한다. 예를 들어 선물 한 종목만 제어할 애플리케이션을 만든다면 com을 이용해도 충분하다. 하지만 많은 종목들을 제어해야 한다면 com은 적당하지 않다. 일반적인 수준으로 이용을 한다면 리눅스용 api까지 이용할 필요는 없다. 리눅스용 api를 이용하면 윈도우즈용 애플리케이션을 만드는 거에 비해 시간이 더 걸린다.
non-com api
이베스트투자증권은 com api와 함께 dll api도 제공을 한다. dll은 dynamic link library의 머리글자로 라이브러리를 애플리케이션에 완전히 넣질static 않고 애플리케이션과 분리된 상태로 둔 채로 필요할 때마다dynamic 가져다 쓰는 걸 말한다. 보통은 라이브러리 파일의 확장자가 dll이라서 그냥 dll이라고 부르지만 엄밀하게는 com과 ocx도 동적 라이브러리이므로 com에 대비되는 의미로 dll이라는 이름을 쓰는 건 틀리다.
이베스트투자증권의 non-com api는 c++로 만들어져 있다. 그 안의 메떠드들을 이용하려면 c++의 데이터 타입을 자신이 이용하는 프로그래밍 언어의 데이터 타입으로 바꿔야 한다. 이러려면 c++의 데이터 타입을 대충은 이해할 수 있어야 한다. 이 과정은 com을 이용하면 필요하지 않다. non-com api를 이용하는 게 처음에는 힘들지만 그 뒤로는 오히려 편하며 더 강력하다. 이베스트투자증권의 레퍼런스에는 non-com api는 c++로만 개발할 수 있다고 나와 있지만 이는 틀리다. 윈도우즈에서 돌아가는 대부분의 언어들로 이용할 수 있다.
동시 접속 가능 회선의 수
개발을 하다 보면 테스트를 위한 접속과 개발을 위한 접속 또는 의뢰를 받아 만드는 경우라면 의뢰인의 접속 등 여러 클라이언트들로 서버에 접속해 있어야 한다. 이러한 접속 가능 회선의 수는 증권회사마다 다른데 이베스트투자증권의 경우에는 실제 서버에 세 개의 동시 접속을 허용한다. 그 외에 모의 서버에도 따로 접속할 수 있다.
쿼리 빈도의 제한 정도
증권회사 서버와의 통신은 조회query와 구독으로 나누어진다. 조회는 클라이언트가 필요할 때마다 서버에 요청을 하여 받는 방식으로 서버는 반드시 응답해야 하고 클라이언트는 응답을 받았는지 확인해야 한다. 대표적인 예가 주문 송신으로 일단 클라이언트가 송신을 하면 서버는 수신 확인 – 처리 – 응답 등 이후의 절차들을 하나도 빠짐 없이 진행해야 한다. 이러다 보니 부하가 크다. 구독은 서버가 일방적으로 보내는 걸 받아 보는 방법이다. 계속 변하는 종목의 가격을 수신하는 게 그 예다. 이건 워낙 발생 빈도가 크기 때문에 가끔 한두 개 빠져도 큰 지장이 없으며 실제로 종종 그러기도 한다. 위에 설명한 가격과 호가의 변경 이벤트가 그런 경우다. 부하는 적다.
조회는 부하가 크기 때문에 클라이언트로 하여금 무한정 허용하면 서버는 금방 먹통이 되어 버린다. 따라서 서버는 조회 요청의 빈도를 제한하는데 보통은 초당 횟수로 정한다. 조회의 종류를 가리지 않고 1초에 세 번이나 네 번처럼 딱딱하게 정하는 회사들이 있고 이베스트투자증권처럼 조회의 부하 정도에 따라 1초에 한 번부터 수십 번까지 동적으로 적용하는 경우도 있다. 일반적으로 제한에 걸려도 우회 방법들이 있으므로 개발에 중대한 영향을 주는 문제는 아니다.
개발 편의성
굳이 레퍼런스를 보지 않아도 개발 관련 게시판에 글들이 얼마나 많은가를 보면 간단하게 확인할 수 있다. 예를 들어 하나증권을 보면 이 회사는 예전 하나대투증권 시절부터 오프라인 영업을 공격적으로 해 왔다. 거래 조건이 좋아서 이 회사 계좌를 써야 할 경우들이 종종 있었는데 개발을 하려고 보면 게시판에 있는 1년치 글들의 수가 이베스트투자증권의 며칠 꺼만도 안 된다. 수수료도 싸고 증거금 조건도 좋은데도 굳이 개발자들이 선호하지 않는다면 거기에는 분명한 이유들이 있게 마련이다. 구색을 맞추기 위해 만들어는 놨지만 귀찮으니까 굳이 쓰지는 말라는 무언의 메시지를 느낄 수 있다.
모의 매매 가능 여부
자동 매매 애플리케이션을 만드는 경우라면 모의 매매는 꼭 해 봐야 한다. 주문 처리 과정은 무척 복잡하여 많은 문제들이 생길 수 있다. 모의 환경에서 충분한 테스트를 거쳐야 한다. 이베스트투자증권의 모의 매매 환경이 완벽하지는 않아서 전략의 성능을 검증하는 데에는 부족하지만 주문 기능을 테스트하는 데에는 충분하다. api를 이용하여 만든 애플리케이션으로 모의 서버에 접속하여 실제처럼 돌려 볼 수 있다.
특정 증권회사를 이용해야 하는 경우
수수료나 증거금 문제 때문에 특정 증권회사를 이용하는 경우라면 좋은 성능이 필요한 주된 연산은 non-com api를 제공하는 이베스트투자증권을 이용하고 주문만 실제로 주문을 해야 하는 증권회사의 api를 이용하는 방법도 좋다. 주문 처리의 부하는 크지 않으므로 리눅스를 이용한 hfthigh frequency trading를 할 게 아니라면 아무 방식의 api라도 큰 차이는 없다. 주문 처리가 단순한 전략의 자동 매매라면 굳이 복잡하게 api를 이용할 필요도 없이 바로 원하는 회사 애플리케이션의 주문 창에 있는 버튼을 간단하게 제어할 수도 있다. 선물 같은 경우에는 증거금 때문에 불법 매매회사를 이용하는 사람들도 많은데 이 경우 특히 유용한 방법이다.