1.
ReadWriteWeb.com에서 API개발에 대한 글을 실었습니다.
A View Into How Apple Develops APIs
API를 개발공급하는 금융회사들이 늘어나길 바라고 좀더 굳건한 API들이 많이 제공되길 바라며 소개합니다.
아래 비디어에 등장한 인물은 Bertrand Serlet, 소프트웨어 엔지니어링담당 수석부사장입니다. 소프트웨어개발을 총괄하고 스티브잡스에게 직접 보고를 한다고 합니다.
Apple에서 API를 만드는 프로세스를 설명하는 매우 짧은 동영상입니다. 코드를 작성할 때 뿐 아니라 모바일과 클라우드 시대의 Web?2.0 기반 API들은 바로 mashup 등 확장 플랫폼으로 사용됩니다. API를 어떻게 공개할 것인가에 대해 생각해볼 수 있는 1분 30초 동영상입니다.
API는 긴 수명을 가지고 있으므로 API를 만들 때는 매우 신중해야 한다.유닉스 API는 40년 전, 맥의 코코아 API는 20년 전, OpenGL API는 15년 전에 개발되었고 아직 사용되고 있다. Apple에서는 이를 위해 API의 라이프사이클을 신중하게 관리한다
2.
Trading API에 대한 관심이 많습니다. 블로그중에서 꾸준히 읽히는 글중 하나가 Trading API를 정리한 글입니다.
위키페디아는 API를 다음과 같이 정의합니다.
API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)는 응용 프로그램에서 사용할 수 있도록 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있도록 만든 인터페이스를 뜻한다. 주로 파일 제어, 윈도우 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.
API를 이해하면서 놓쳤던 내용이 있습니다. 어플리케이션이 아니라 API이어야 하는 이유가 있었고 ?트레이더가 API를 원하는 큰 이유입니다.그에 대한 글이 있었습니다.
자동매매 프로그램은 거의 대부분이, 계좌와 주문체결에 관한 항목들을 반영하는 함수를 제공하지 않고 있다. 자동매매 프로그램은 매매신호가 발생하면, 그에 따라 주문을 내어 보내지만, 실제로 체결이 되었는지 또 얼마에 체결이 되었는지를 알지 못하므로, 실제의 체결여부와는 상관없이, 수식화 된 내용대로 무조건 진행을 하게 되고, 여기서 주문이 뒤엉키는 문제가 발생할 가능성을 가지고 있다. 이로 인해, 자동매매 프로그램을 사용하더라도, 신호가 발생하면, 실제의 체결 상황을 파악하여, 프로그램을 제어하여야 한다. 이러한 불편함에서 벗어나고 싶은 욕구를 만족 시켜주기 위해 등장한 것이 API이다.
자동매매프로그램과 API중에서
ZeroDMA를 기획하면서 중요한 기능중 하나를 API로 잡았습니다. 이미 증권사들이 API를 제공하는 것과 같은 이유입니다. 다만 ZeroDMA는 알고리즘이 있고 이를 전산적으로 표현할 능력은 있지만 다른 부분은 할 능력도 없고, 있다고 하여도 하고 싶지도 않는 트레이더를 위해 API를 고민하였습니다. 전략에 집중하고 구현을 위해 자신의 전략을 공개하지 않아도 되는 환경을 제공하려고 했습니다.
그러면 Apple이 고민한 것과 같은 수준을 당장 고민할 수는 없습니다. 다른 방향이 필요했고 이에 대한 중요한 시사점을 준 글을 보았습니다.
위의 글은 크게 세부분으로 API를 나눕니다. Market Data, Order, Risk Management. 특별하지 않습니다. 이미 증권사의 API도 그렇고 대부분 트레이딩시스템은 이런 기능을 가지고 있습니다. 제가 눈여겨 본 부분은 “통합이냐, 분리이냐” 입니다. 증권사는 일반트레이더에게 통합형 API를 제공합니다. 보안등을 고려할 때 어쩔 수 없는 선택입니다. 그렇지만 환경이 달라진다면 분리도 가능하지 않을까 생각하였습니다. 요즘 HTS는 주문과 시세세션을 분리한다고 들었습니다. 90년말 처음 HTS가 나올 때 분리했다고 2000년초 통합세션으로 갔던 것을 생각하면 돌고 돕니다. 하여튼 같은 문제의식입니다.
제가 생각하는 Market Data는 증권사가 제공가능한 전상품의 시세입니다. 국내 주식과 파생, 해외 주식과 파생, FX까지를 포함합니다. 물론 메시징의 Pub/Sub방식을 취하고 Topic Filtering을 제공하여 필요한 종목 혹은 종목들은 아주 간단히 받을 수있도록 했습니다. 하여튼 시세API는 분리하여야 할 필요가 있었습니다.
그리고 좀더 고민을 해서 이런저런 방향을 잡았지만 가장 기본적인 뿌리는 메시징입니다. API의 가장 밑바탕은 Messaging Layer입니다.
3.
앞서 자동매매시스템은 Tradestation,Multicharts와 같은 제품들입니다. 제가 협력하고 있는? PT Multistation도 같은 범주의 제품입니다. 그래서 트레이더가 API를 요구하는 이유때문에 우크라이나에 메일을 보냈습니다.
“계좌와 주문체결에 관한 함수를 줄 수 있느냐”
답은 영어실력이 짧아서 그런지 자세한 요구사항을 달라고 합니다.
서비스 혹은 소프트웨어는? 이용자가 원하는 방향을 담아야 합니다. 그렇지만 자신만의 철학을 녹여야 합니다.Apple이 나아가는 방향이 그렇다는 생각입니다.
