2014년 4월부터 제도권에서 트레이딩을 한지 5년이 다돼간다. 최근에는 벗어났지만 그 동안 박스권에 갇혀있던 어려운 시장에서도 마이너스 분기실적 없이 잘 견뎌냈다.

현재 사용중인 CherryPicker 는 최초에 개발했던 방향과는 많이 달라졌다(좋은쪽으로). 역시 첫 설계에서 생각했던거와 사용하면서 필요해지는 부분의 차이는 작지 않았다. 아마 이런 툴개발 경험이 없어서인거 같다. 이제는 나뿐만이 아닌 회사 동료분들의 전략 자동화에도 협조하고 있고 그 분들의 요구사항을 반영하면서 기능이 더욱 늘어났다. 특히 수동개입쪽 기능이 많이 추가됐다. 기존의 나는 수동개입은 불허하는 입장이지만 특수한 상황에서는 필요할것 같아 적극 반영을 했다.

사실 트레이딩툴 기본기능은 3년전에 거의 완성됐고 그 이후부터 최근까지는 거의 백테스트에 올인했다고 봐도 좋다. 그 중 분석하기 편하게 GUI 툴 개발과 병렬화에 집중했다. 그래서 테스트 결과를 비쥬얼하게 보여주는 Efreet 가 탄생했고, Efreet 는 결과 분석외에도 테스트 스크립트 기능도 있어서 테스트 설정 및 스케줄이 기록된 스크립트 파일을 읽어서 전략의 백테스트를 진행한다. Efreet 의 백테스트는 복수의 CPU 에 테스트 분량을 분산해서 병렬로 진행하는 기능도 있다. CPU 개수에 따라 테스트에 걸리는 시간이 대폭 줄어든다. 마지막으로 Efreet 의 중요한 기능은 백테스트에서 도출된 경우의수에서 가장 이상적인 경우의수 및 그것들의 조합을 추출하는것이다.. 이 작업 또한 백테스트만큼의 오랜 시간이 소요되는데 역시 CPU 병렬처리를 이용해서 그 시간을 단축시킬 수 있다.

CPU 병렬화는 시뮬레이션의 시간을 단축시켜준다. 위 문단에서 설명한것처럼 CPU개수분의 1의 수준으로 단축된다. 그래도 4코어 CPU 로 많으면 1주일이상의 시간이 소요되는 테스트를 3, 4일로 줄여줄 뿐이다. 물론 이것만으로도 엄청나지만 그래도 목이 마른 법. 며칠이 아닌 1,2 시간 내로 끝내고 싶었다. 언젠가는 계획하고 있지만 당장은 20코어 4프로레서보드 같은 서버를 장만할 수도 없다. 가격도 가격이거니와 최근에 터진 인텔 CPU 보안패치문제 때문에라도 지금은 별 계획이 없다. 그래서 주목하게 된것이 GPU 다.

CPU 보다 훨씬 많은 작은 코어들을 가지고 있는 GPU 의 병렬연산은 알파고의 등장하면서 주목받기 시작했다고 봐도 과언이 아니다. 그래서 나는 약 2년 전부터 이전 증권사에서 연을 맺게 된 분과 CUDA(NVIDIA 에서 개발한 GPU 병렬연산을 쉽게 해주는 언어시스템) 스터디를 시작했다.(현재는 CUDA 스터디를 어느정도 마치고 딥러닝 스터디로 전환) 이 CUDA 가 얼마나 Efreet 의 시뮬레이션 성능을 높혀줄지는 모르겠지만 알파고에서 대량으로 GPU가 운용되는것을 보면 가능성이 있어보인다. 그래서 당분간은 CUDA 프로그래밍에 집중해보려고 한다. 카테고리를 추가해서 관리하고자 한다.

추가로 예전에 올렸다가 지운 CherryPicker 엔진을 사용한 Gaia 의 스냅샷과 Efreet 의 백테스트 결과 분석화면을 올려본다.

Gaia(트레이딩툴) 운용화면

Efreet 백테스트 결과 분석화면(개인적인 부분은 책으로 가림)

마지막으로 기록된 개발일정을 보니 2014년 1월까지로 되어있다. 이 일정이 마무리 되었을 때 CherryPicker 를 실거래에 적용할 수 있을만한 형태가 되었다. 그리고 때마침 운 좋게 제도권에서 시스템 트레이딩을 할 수 있는 기회가 주어졌다. 기회가 주어지고 한 달간 증권사에 출근하면서 CherryPicker 에 증권 API 대신 거래소에서 직접 날라오는 UDP 패킷을 사용하게끔 개조를 했다. 그렇게 개조가 무사히 끝나고 드디어 2014년 3월부터 CherryPicker 를 이용한 첫 거래를 시작했다. 그 후 조금 더 좋은 조건으로 한 차례의 이직을 하고 2016년 1월 현재까지 CherryPicker 로 거래하고 있다.

다행히도 가장 우려스러운 '주문사고'는 없었지만 프로그램이 뻗은적도 여러번 있었고, 실시간 패킷통신에서 오는 동시성에 관련된 문제점들도 많았다. 하지만 시간이 흐르면서 버그가 발생하는 빈도는 점점 줄었고, 현재는 근 1년 버그없이 잘 운용되고 있다. 사실 버그가 발생하면 기분이 좋다. (물론 주문사고는 한 번이라도 있어서는 안된다.) 왜냐하면 그것은 내가 발견하지 못했던 문제가 발견된 것이기에 고쳐서 더 완벽한 프로그램이 되는 기회이기 때문이다.

제도권 입성이라는 목표를 가지고 업무시간 외 시간을 투자해 만든 시스템 트레이딩툴을 풀타임으로 개발할 수 있다는 사실에 너무 행복했던 지난 2년이었다. 제도권에 입사 후 첫 거래에 성공한 이후 지금까지 많은 기능을 구현했고, 로직 최적화를 통해 속도향상에도 상당한 진전이 있어왔다. 파생상품 운용을 직접 해보면서 생기는 요구사항이 생기는대로 바로바로 반영했다. 처음에는 두서없이 거래만 되게끔 구현하는게 첫 목표였지만 최종적으로 내가 분류한 시스템 트레이딩에 필요한 개발파트는 크게 1. 실운용, 2. 백테스트, 3. GUI, 4. 성과분석 의 카테고리로 나뉜다. 어느것 하나 무시할 수 없는 시스템 트레이딩 전반에 있어 필수적인 요소들이다. 각 카테고리가 중요한 이유를 간단히 설명해보면

1. 실운용

    말이 필요없는 부분이다. 최대한 빨리 시그널을 받고 주문을 해야하므로 속도를 위한 코드 최적화가 중요하다.

2. 백테스트

    시스템 트레이딩의 꽂이다. 백테스트를 통해 시스템 전략들이 만들어진다. 최적화 변수들이 많아질수록 테스트에 걸리는 시간이 천문학적으로 길어지므로(전략 하나에 일 주일, 한 달이상 소요되기도..) 이것 역시 코드 최적화가 중요하다. 그리고 데이터 흐름 알고리즘을 조금 바꾸는 거에 의해 수십분의 일, 수백분의 일까지도 소요시간을 줄일 수 있다. 물론 하드웨어의 성능을 모두 활용하는 멀티 스레드/프로세스는 필수이다.

3. GUI

    실운용에 있어 현 상황이 어떤 상황인지 알기에는 텍스트로도 문제가 없지만 편리하고 직감적으로 알기 위해서는 그래픽으로 더 효과적이다. 포트폴리오 포지션, 손익, 전략상황 등을 GUI 를 통해서 파악한다.

4. 성과분석

    성과분석툴은 크게 두 가지로 나뉜다. 백테스트한 결과중 어떤것을 실운용할지, 어떤 조합으로 포트폴리오를 구성할건지 분석할 수 있는 GUI툴과, 현재 실운용인중인 포트폴리오의 운용성과를 분석하고 백테스트한 결과와 비슷한 성과를 내고 있는지 분석할 수 있는 GUI툴이다. 이는 현 수익을 목적지(백테스트상 수익)로 안전하게 도달하게끔 유도해주는 역할을 해준다.

위 네 가지의 기능들을 수행하기 위해 그 동안 CherryPicker(알고리즘엔진) 외에 Unit_3(백테스트), Gaia(실운용), Efreet(성과분석) 등이 탄생했다. 현업에서 일하고 있는 이상 개발진행 사항을 포스팅 하기가 어려워져 이렇게 상황요약을 마지막으로 개발일정은 포스팅을 종료하겠다. 다른 메뉴들은 계속 업데이트할 생각이다.

지금까지 알고리즘 포스팅에 관심 가져주신 분들이 적지만 몇 분 계셨고 오프라인에서의 만남도 있었다. 나는 시스템 자동화에 대해 이야기하는걸 참 좋아한다. 교류를 원하시는 분들은 언제나 환영이다. :)

TWAP 은 풀어서 'Time Weighted Average Price' 이며 직역하면 '시간가중평균가격' 정도가 되겠다. 시시각각 변하는 가격을 주기적으로 수집하여 평균을 계산하는 것인데 이동평균과 비슷한 맥락이라고 생각하면 된다.

TWAP 은 알고리즘 트레이딩 세계에서는 대량의 증권을 시장충격을 최소화하고 매수 또는 매도하는 전략으로도 해석된다. 뭔가 거창하게 들리지만 그냥... 사고자하는 주식을 균등하게 나눠서 주기적으로 사거나 팔거나... 이다. 조금이라도 복잡성을 찾고자 한다면 사고자하는 수량이 상대1호가보다 많을 경우에 유리하게 매매하는 방법을 연구하면 된다. 그 외에는 초등학생도 쉽게 집행할 수 있는게 TWAP 이다.

TWAP(혹은 VWAP) 전략이 필요한 이유를 그림으로 설명해 보겠다. 다음 호가창을 보자.

어떤 상장 대기업의 대주주가 있고 그 대기업의 주가는 KOSPI200 과 아주 비슷하게 움직인다고 가정해보자. 이 대주주는 자신이 가지고 있는 주식 가격의 하락으로 인한 자산감소를 방지하고자 KOSPI200 지수선물을 1000 계약 매도하고자 한다.

(물론 해당 기업의 주식선물이 존재한다면 KOSPI 200 지수선물이 아닌 그 주식선물을 매도하는것이 맞지만 가지고 있는 자료가 선물 호가창뿐이라 선물을 헤지수단으로 정했다.)

이 대주주가 매도집행하는 방법은 여러가지가 있지만 다음 네 가지 방법 중 하나를 선택한다고 가정하자.

1. 마우스에 손을 얹고 무작위 시간에 1000 계약 시장가 매도

2. 선물가격이 고점이라고 판단했을 때 1000 계약 시장가 매도

3. 1000 계약을 7등분하여 매시간 142 계약씩 시장가 매도(9시~14시 정각에는 142 계약, 15시에는 148계약)

4. 1000 계약을 7등분하여 매시간 142 계약씩 호가를 컨트롤하며 지정가 매도

대주주가 이러한 선택지를 가지게 된 이유는 1000 계약의 선물 매도를 완료했을 때, 평균매도가격을 최대한 높히고 싶어서다. 대주주가 정확한 판단력을 가진 사람이라면 2 번이 가장 높은 평균매도가격을 가지게 될것이다. 1 번은 2 번과 같은 평균가를 가지거나 3, 4 번보다 좋을수도 혹은 나쁠수도 있다. 3 번과 4 번은 그 날 취할 수 있는 최악의 평균가격은 분명 면할 것이다. 하지만 3 번보다 4 번이 유리한 평균가를 얻을 확률이 높다.

3 번과 4 번의 방법 중 시장가 주문이 불리한 이유는 3 번 방법의 경우 시장가 주문을 함으로서 호가창의 매수 1 호가의 모든 잔량을 취하고도 매수 2 호가에서 59 계약을 더 취하게 돼 142 계약의 매도평균가격은 255.23 이 된다. 지정가 주문으로 아주 잘~컨트롤된 매도집행은 현재가인 255.25 이거나 시장가로 집행한 255.23 보다는 높은 매도평균가격을 갖게될 것이다.

위 방법 중 3 번과 4 번이 TWAP 알고리즘에 해당하는데 이는 최선도 최악도 아닌 그나마 평균적인 성과를 내는 방법이다. 최악의 성과를 내느니 차라리 최고는 아니지만 평균성과라도 내고싶을 때 아주 유용한 방법이다.

이제 실제로 TWAP 이 어느정도 성과가 있는지 과거데이터로 테스트를 해보겠다. 테스트 방법은 다음과 같다.

=============================================================

* 기간은 2009년 1월 2일 ~ 2013년 9월 30일 (1184 일)

* 매일 선물 10000 계약 매수목표

* TWAP 알고리즘은 9시 1분부터 장종료(15시 15분)까지 매분 27 계약씩 366 번의 선물을 매수

  (10000 / 366 은 27.32 라서 27 계약으로 결정했고 매수 완료후 118 계약이 남지만 무시하고 27 계약씩만 매수)

* 매분 종가로 매수

* 각 호가의 잔량정보가 있으면 좋지만 OHLC 정보밖에 없으므로 '종가 = 매도 1 호가'로 가정한다.

* 종가에 27 계약 모두 무조건 매수 가능하다고 가정한다.(호가잔량정보 부족의 한계)

=============================================================

이렇게 테스트를 해봤고 일별 선물 고가와 저가 사이에 어느정도의 평균가격으로 선물이 매수됐는지 며칠동안의 그래프를 살펴보면 다음과 같다.

예상한대로 TWAP 은 대략 고가와 저가의 중간값으로 나타났다.

근데 과연 정말 중간값일까...? 먼저 위 그래프에서 '당일 TWAP' 부분과 당일 '( 당일 고가 + 당일 저가 ) / 2' 값을 비교해봤다.

위의 그래프로는 두 데이터계열이 엎치락뒤치락한다. 샘플이 너무 적고 눈으로 식별해야 하는 불편함이 있으므로 테스트된 1184 개의 데이터의 정보를 산출해봤다.

TWAP 과 중간값의 차이는 한틱(0.05포인트)이 조금 넘는 값이다. TWAP 값이 아주 조금 높게 나온 이유는 급락에 의한 저가가 생성되어 중간값을 끌어내린 경우가 많기 떄문이다. 실제로 1184 개의 샘플 중 TWAP 이 고저가 중간값보다 낮은 경우가 그렇지 않은 경우보다 128 일이나 더 많았다. 

결론

선물 TWAP 과 선물 고저가격 중간값은 1184 개의 과거 샘플에 의해 평균적으로 대략 한 틱정도의 차이를 보였다. 이는 TWAP 알고리즘으로 증권을 매도 또는 매수하면 그 날의 고가와 저가의 중간값으로 거래하는것과 거의 같은 효과가 있음을 의미한다. 단, 한 틱이 조금 넘는 값의 차이로 평균 선물 TWAP 이 평균 선물 고저가의 중간값보다 높으므로 샘플에 의하면 선물 TWAP 거래시 매도가 매수보다는 한 틱가량 유리하다.

P.S.

TWAP 을 개선한 것이 VWAP(Value Weighted Average Price) 인데 다음 포스팅에서는 호가잔량 정보 및 거래량 정보를 사용하여 TWAP 과 VWAP 의 성과비교를 해보겠다.

옵션을 매매는 기초자산의 방향성보다는 기초자산의 변동성을 매매한다는 표현이 더 어울린다. 그래서 옵션을 매매하는 사람들은 기초자산의 변동성 예측에 많은 신경을 쓰게된다. 그러므로 현재 기초자산의 변동성이 어느정도 수준인지를 아는것 또한 매우 중요하다.

변동성은 높아지거나 낮아져도 평균수준으로 회귀하는 특성이 있는데, 현재 변동성이 역사적으로 최대값이나 최소값에 접근한 상태라면 평균으로 회귀할 가능성이 상당히 높다. 특정 변동성의 수준을 쉽게 알기위해 잔존만기에 따른 역사적 변동성의 최대값과 최소값을 나타내는 지표 중 하나가 변동성콘(Volatility Cone)이다.

다음 그림은 변동성콘의 예시이다. 어디서 퍼오면 저작권에 위반될것 같아 직접 그려봤다....

만약 잔존만기가 5 일이고 기초자산인 지수의 현재 변동성이 23% 라면 변동성콘의 상단 경계부분인 25% 에 근접했으므로 옵션 매수보다는 매도전략이 유리함을 알 수 있다.

만약 어떤 변수가 변동성같이 시간이 지남에 따라 회귀현상이 관측된다면 이런 Cone 차트를 적용시킬 수 있을것이다. 이 아이디어에 기초해서 만들어 본것이 총호가순건수콘과 총호가순잔량콘이다. 총호가순건수란 매수호가총건수에서 매도호가총건수를 차감한 값이고, 총호가순잔량이란 매수호가총잔량에서 매도호가총잔량을 차감한 값이다. 두 값 모두 다음과 같이 HTS 호가창에서 관찰이 가능하다.

위 화면의 최하단에 다섯 개의 숫자가 일렬로 보이는데 왼쪽부터 순서대로 각각 다음을 의미한다.

==================== HTS 호가관련 정보 설명 ====================

총매도호가건수 : 1,172

총매도호가잔량 : 5,915

총호가순잔량    : -2,154 (총매수호가잔량(5,915) - 총매도호가잔량(3,761))

총매수호가잔량 : 3,761

총매수호가건수 : 670

P.S. : 총호가순건수는 계산되어있지 않지만 총매수호가건수(670)에서 총매도호가건수(1,172)를 뺀 -502 임을 알 수 있다.

=======================================================

총호가순건수(과 총호가순잔량)는 다음과 같이 시간이 지남에 따라 0 으로 회귀하므로 cone 으로 만들어 전략에 참고할 의미가 있다. (있을지도 모른다고 믿고싶다...-_-)

본인이 만들어본 총호가순건수콘과 총호가순잔량콘이 변동성콘과 다른점이 있다면 가로축이 잔존만기가 아닌 시각이다. 측정을 위해 수집된 데이터 정보는 다음과 같다.

=============== 총호가순건수콘, 총호가순잔량콘 정보 설명 ===============

계측기간    : 2009/01/01 ~ 2013/09/30

수집데이터 : 9, 10, 11, 12, 13, 14 시 정각의 총호가순건수값, 총호가순잔략값 (KOSPI200 선물 최근월물)

계산값       : 각 시각의 총호가순건수값, 총호가순잔량값의 최대값, 최소값, 평균값

=========================================================

Cone 구성에 필요한 정보를 추출하는 코드는 대략 다음과 같다.

위에서 구한 값들로 cone 정보를 구하면 다음 표와 같다.

이를 보기좋게 그림으로 표현하면 다음과 같다.

총호가순건수 cone

총호가순잔량 cone

위의 그림과 같이 두 개의 cone 은 현재 호가건수와 호가잔량이 어느정도 수준인지 가늠할 수 있게 도와준다.

이번에는 구해놓은 두 개의 Cone 을 활용하여 간단한 전략을 테스트해보겠다. 이렇게 분석 후에 전략에 실제로 적용해보는 순간이 가장 두려운(?) 순간이다. 의미가 없다면 의미가 없다는것을 알았다는 점이 나름대로의 수확이라 말할 수 있지만 가설이 무의미하다는것을 아는 순간은 썩 기분이 좋은것은 아니기 떄문이다. 그렇다. 전략테스트가 완료되고 난 후에 이 글을 쓰고있는 것이고 가설이 무의미한 것이 입증됐기 떄문이다. 하지만 반대로 의외의 수확도 있었다. 먼저 전략의 로직부터 설명하겠다.

9시부터 14시까지 매정시의 최대값 및 최소값은 각각 유의한 차이를 보인다. 그러므로 전략에 응용할 때는 매정시마다 다른기준을 가지고 시그널을 발생시켜야 한다. 9시의 경우만 예를 들어보겠다. (참고로 이 전략에서는 호가건수만 이용한다.)

2009년 1월 2일부터 2013년 9월 30일까지 매일 9시 정각에 기록한 총호가순건수는 1159 개이다. 이 데이터들을 가지고 히스토그램을 만들어보면 다음과 같다.

가로축이 총호가순건수의 범위들이고 세로축은 그 범위 내에 포함된 건수들이다. 범위는 엑셀에서 자체적으로 지정한 것이므로 좀 지저분하게 표현됐다. 총호가순건수 최대값과 최소값은 각각 이 그래프의 최우측과 최좌측의 값 두 개의 값과 동일하다. 만약 이 두개의 값만을 이용한다면 4년 가까이 딱 두 번의 거래만 발생할 것이다. outlier 들을 제거해서 좀 더 현실적인 boundary 를 만들어야한다. 이벤트 발생이 10회 이하인 범위를 제거하면 boundary 는 다음과 같이 변경된다.

최대값 : 1408 -> 816

최소값 : -1381 -> -873

boundary 넓이가 무려 절반에 가깝게 줄어들었다. 이를 기초로 다음과 같이 전략로직을 세워봤다.

==================== 전략 로직 ====================

로직 :

총호가순건수가 boundary 에 접근하면 평균으로 회귀하려는 성향이 강하다. 총호가순건수의 움직임은 가격움직임과 양의 상관관계가 있으므로 boundary 에 접근하려 할 때 반대방향으로 주문한다.

매도주문 : 9, 10, 11, 12, 13, 14 시에 총호가순건수가 upper boundary 에 도달하면 매도

매수주문 : 9, 10, 11, 12, 13, 14 시에 총호가순건수가 lower boundary 에 도달하면 매수

로직평가 : 진입 후 한 시간동안의 진입우위성으로 평가 (진입우위성에 대한 설명 및 검증 페이지 <- 클릭)

==================================================

전략코드는 진입코드를 제외하고 진입우위성검증 페이지에 나와있는 코드와 동일하므로 여기서는 진입코드만 게시한다.

진입우위성 검증 결과는... 참담하다. 하지만 의외의 수확이 있다. 먼저 E-ratio 결과를 보자

E-ratio 가 1.0 이면 무작위, 1.0 보다 높으면 진입조건이 수익성이 있는것이고 1.0 보다 낮으면 진입조건이 수익성이 떨어진다는 의미다. 표를 보면 E-ratio 가 모든 시간대에 걸쳐 1.0 보다 높지 않은 수치들을 보이므로 이 전략은 수익성이 없는 전략이다. 하지만 1.0 보다 유의하게 낮은 경우는 얘기가 달라진다. 먼저 매도진입과 매수진입을 바꿔서 테스트해보면 다음 표와 같다. (위의 표의 값의 역수결과가 나올것이다.)

괜찮은 결과가 나왔다. 총 거래건수는 266 건, 승률은 57% 다. 승률은 절반에 가깝지만 수익성이 높다는것은 boundary 에 다다를 경우 추세발생시에 강한 추세를 가진다는것을 의미한다. 이 현상은 9시에 발생한 거래들을 살펴보면 더 확연해진다. 9시에 발생한 거래건수는 46건, 승률은 33% 다. 그럼에도 불구하고 가장 높은 수익성을 보인다는건 장 초반에 총호가순건수가 boundary 에 다다른 경우 총호가순건수의 평균으로의 회귀및 선물손실의 가능성은 크지만 추세가 발생할 경우 선물가격은 큰 수익성을 보인다는 의미로 해석된다. 

이 상황이 쉽게 이해되도록 그림을 그려봤다.

총호가순건수가 a 점에 다다르면 b 점인 선물가격은 작은확률로 크게 상승하고 높은확률로 적게 하락한다.

결론

현재 총호가순건수, 총호가순잔량이 역사적 최고점 또는 최저점에 다다르면 평균으로 회귀한다는 가정을 세우고 전략에 응용해 봤으나 유의한 수익성과는 얻지 못했다. 하지만 장 초반에 총호가순건수가 boundary 에 다다른 상태에서 선물가격에 추세가 발생할 경우에는 높은 수익성을 보였다.

2011 년 3월..  TradeStation 이 아닌 자기만의 트레이딩툴을 만들고 싶었던 그 때 증권 API 의 존재를 우연히 알게되고, 하루라도 빨리 화면으로 뭔가 표현해보고 싶은 마음에 급조한 프로그램이 있다. 시스템 트레이딩툴은 아니고 종목, 주문 수량,  주문 가격, 주문 타입 등을 선택하고 거래할 수 있는 수동매매툴이다. 지금은 모든 프로젝트가 Cherry Picker 라는 이름으로 통합됐고 더 이상 GUI 는 채용하고 있지 않지만 그 당시에는 TTrader 라는 이름을 지어줬었고, 허접하지만 아래 그림과 같이 GUI 로 정보를 표현할 수 있게 했다. 이 프로그램은 증권 API 테스트를 위해 급조된것에다가 시스템 전략의 수행도 불가능하므로 당연히 현재는 사용하지 않는다. 그래도 묻혀지는 것이 아쉬워 수행되는 모습을 남겨보고자 한다.

( 참고로 현재 운용중인 트레이딩 툴인 Cherry Picker 는 GUI 가 아닌 CUI 방식이며, 로그파일에 현 상황들이 실시간으로 기록이 된다. GUI 가 있으면 화려해보이고 프로그램다운 모습이지만 데이터를 보여주기 위해 필요한 리소스(CPU 등 컴퓨터 자원)가 결코 적지 않으며 무엇보다 시스템 전략은 전적으로 미리 코딩된 로직에 의해서만 운용되어야 함으로 GUI 에 의한 조작이 애초에 필요가 없기 때문이다. 시스템 트레이딩에 특화된 헤지펀드(특히 르네상스 테크놀로지)는 트레이딩룸 자체가 없고 오직 서버실과 전략개발을 위한 회의실, 그리고 개인 사무공간만 존재한다고 어디선가 읽은 기억이 있다. ) -> 이상 GUI 를 안만들어도 된다는 변명 ;;;

사진 2 장과 시연 동영상 1 개를 만들어봤다. 수행 프로그램 이름은 Cherry Picker 로 되어있는데, 이는 어느 시점에서 진행중인 모든 프로젝트 이름을 Cherry Picker 로 통합했기 때문이다. 

서버 접속 직전의 모습 (화면을 클릭하면 크게 볼 수 있습니다.)

첫 번째 사진은 프로그램이 증권사 서버에 접속하기 이전인 프로그램 수행 직후의 모습이다. 왼쪽 검은 화면은 각종 정보메세지를 출력하는 부분이고, 오른쪽 화면이 프로그램을 조작하거나 가격, 계좌정보, 잔고 등을 표현하는 GUI 부분이다.

서버 접속 후의 프로그램 수행중인 모습 (화면을 클릭하면 크게 볼 수 있습니다.)

두 번째 사진은 증권사 서버 접속 직후의 모습이다. 직관적으로 각 버튼 또는 창들이 의미하는바를 쉽게 알 수 있다.

증권사 서버 접속 후 간단한 거래를 하는 모습 (플레이 버튼을 누르면 재생됩니다.)

위 영상은 서버에 접속을 하고 간단한 선물거래를 하는 영상이다. 시계를 보면 9시 직전에 서버에 접속을 했으며 9시00분00초가 되자 수신되기 시작한 실시간 데이터들이 화면에 보여지며, 매수 또는 매도거래가 행해지고 계좌 및 잔고상태를 확인하는 버튼을 누르면 해당 정보가 갱신됨을 알 수 있다. 보다시피 시스템전략과는 무관한 프로그램이며 그냥 편한 수동거래툴(?) 정도로 인식하는것이 좋겠다.

다음 포스팅에서는 본격 시스템 트레이딩툴인 Cherry Picker 의 수행모습을 화면에 담아볼 것이다. (이미 이전 몇몇 포스팅에서 캡쳐사진을 올린바 있지만...) GUI 가 없기 때문에 뭔가 굉장히 단순해 보일지 모르겠지만 그 내부에서는 아주 나이스하게 시스템 전략들이 관리 및 운용되고 있다.

Cherry Picker 의 전략 클래스에서 바로 사용이 가능한 심볼들의 정보다.

증권 API 에서 오는 raw 데이터를 가공을 해야 전략에서 바로 사용이 가능한 형태가 되는데, 지굼까지 구현된 전략에서 필요한 정보가 새롭게 생길 떄마다 추가해왔다. 앞으로 전략 구현수가 늘어감에 따라 전략에서 사용 가능한 심볼 정보도 늘어갈 것이며 궁극적으로는 증권 API 에서 제공하는 모든 데이터를 이용할 수 있게 만들것이다.

분데이터 및 틱데이터 모두 사용되는 심볼과 심볼 속성은 동일하다.

     : 파생상품 종류

     : Symbol 이름

*   : Symbol 속성 (전략에서 참조할 수 있는 예약어)

(2013년 12월 11일 현재)

Index

   KOSPI200(KOSPI200 지수)

        * Open,High,Low,Close : 시가,고가,저가,종가

Futures

    KOSPI200_FUT(최근월물 선물체결)

    KOSPI200_FUT_2(근1월물 선물체결)

    KOSPI200_FUT_3(근2월물 선물체결)

    KOSPI200_FUT_4(근3월물 선물체결)

        * Open,High,Low,Close : 시가,고가,저가,종가

        * CVolume : 거래량

        * UpCVolume : 매수 거래량

        * DownCVolume : 매도 거래량

        * Volume : 당일 누적 거래량

        * UpVolume : 당일 누적 매수 거래량

        * DownVolume : 당일 누적 매도 거래량

   KOSPI200_FUT_HOGA(최근월물 선물호가)

   KOSPI200_FUT_HOGA_2(근1월물 선물호가)

   KOSPI200_FUT_HOGA_3(근2월물 선물호가)

   KOSPI200_FUT_HOGA_4(근3월물 선물호가)

        * AskPrice_1_Open(High,Low,Close) : 매도1호가OHLC

        * BidPrice_1_Open(High,Low,Close) : 매수1호가OHLC

        * AskRem_1_Open(High,Low,Close) : 매도1호가수량OHLC

        * BidRem_1_Open(High,Low,Close) : 매수1호가수량OHLC

        * AskCnt_1_Open(High,Low,Close) : 매도1호가건수OHLC

        * BidCnt_1_Open(High,Low,Close) : 매수1호가건수OHLC

        ... 5호가까지

        * TotAskRemOpen(High,Low,Close) : 매도호가총수량OHLC

        * TotBidRemOpen(High,Low,Close) : 매수호가총수량OHLC

        * TotAskCntOpen(High,Low,Close) : 매도호가총건수OHLC

        * TotBidCntOpen(High,Low,Close) : 매수호가총건수OHLC

Option

   KOSPI200_CALL_ATM(최근월물 ATM 옵션체결)

   KOSPI200_CALL_ITM_1(최근월물 ITM1 옵션체결)

   KOSPI200_CALL_ITM_2(최근월물 ITM2 옵션체결)

   ... 외 모든 ITM

   KOSPI200_CALL_OTM_1(최근월물 OTM1 옵션체결)

   KOSPI200_CALL_OTM_2(최근월물 OTM2 옵션체결)

   ... 외 모든 OTM

   KOSPI200_CALL_2_ATM(근1월물 ATM 옵션체결)

   KOSPI200_CALL_2_ITM_1(근1월물 ITM1 옵션체결)

   ... 외 모든 월물과 PUT 까지

        * Open,High,Low,Close : 시가,고가,저가,종가

        * CVolume : 거래량

        * UpCVolume : 매수 거래량

        * DownCVolume : 매도 거래량

        * Volume : 당일 누적 거래량

        * UpVolume : 당일 누적 매수 거래량

        * DownVolume : 당일 누적 매도 거래량

   KOSPI200_CALL_ATM_HOGA(최근월물 ATM 옵션호가)

   KOSPI200_CALL_ITM_1_HOGA(최근월물 ITM1 옵션호가)

   KOSPI200_CALL_ITM_2_HOGA(최근월물 ITM2 옵션호가)

   ... 외 모든 ITM

   KOSPI200_CALL_OTM_1_HOGA(최근월물 OTM1 옵션호가)

   KOSPI200_CALL_OTM_2_HOGA(최근월물 OTM2 호가)

   ... 외 모든 OTM

   KOSPI200_CALL_2_ATM_HOGA(근1월물 ATM 옵션호가)

   KOSPI200_CALL_2_ITM_1_HOGA(근1월물 ITM1 옵션호가)

   ... 외 모든 월물과 PUT 까지

        * AskPrice_1_Open(High,Low,Close) : 매도1호가OHLC

        * BidPrice_1_Open(High,Low,Close) : 매수1호가OHLC

        * AskRem_1_Open(High,Low,Close) : 매도1호가수량OHLC

        * BidRem_1_Open(High,Low,Close) : 매수1호가수량OHLC

        * AskCnt_1_Open(High,Low,Close) : 매도1호가건수OHLC

        * BidCnt_1_Open(High,Low,Close) : 매수1호가건수OHLC

        ... 5호가까지

        * TotAskRemOpen(High,Low,Close) : 매도호가총수량OHLC

        * TotBidRemOpen(High,Low,Close) : 매수호가총수량OHLC

        * TotAskCntOpen(High,Low,Close) : 매도호가총건수OHLC

        * TotBidCntOpen(High,Low,Close) : 매수호가총건수OHLC

Cherry Picker 는 다음 세 가지 클래스로 알고리즘 트레이딩이 가능한 라이브러리다.

1. Symbol Manager class (TradeStation 의 Chart Window 에 해당)

2. Symbol class (TradeStation 의 Symbol 에 해당)

3. Strategy class (TradeStation 의 Strategy 에 해당)

Symbol 과 Strategy 를 Symbol Manager 에 등록하면 Symbol Manager 가 이들을 관리하기 시작하고, Symbol 에 시계열 데이터를 삽입하면 Strategy 에서 주문 시그널이 나오는 구조다. 이들을 활용할 수 있는 시나리오는 다음 세 가지다.

시나리오 1.

과거 시계열 데이터 파일을 읽어들여 Symbol 에 순차적으로 삽입시킨 후, Strategy 에서 주문 시그널이 발생하면 Strategy 내부에서 손익을 계산한다. 이렇게 함으로서 전략의 시뮬레이션이 가능하다.

시나리오 2.

증권 API 를 통해 읽어들인 실시간 데이터를 Symbol 에 삽입한 후, Strategy 에서 주문 시그널이 발생하면 Strategy 내부에서 손익을 계산한다. 이렇게 함으로서 전략의 실시간 시뮬레이션이 가능하다.

시나리오 3.

증권 API 를 통해 읽어들인 실시간 데이터를 Symbol 에 삽입한 후, Strategy 에서 주문 시그널이 발생하면 증권 API 를 통해 주문을 낸다. 이렇게 함으로서 전략의 실전 운용이 가능하다.

이 블로그를 개설한 이후 현재까지 시나리오 1 과 시나리오 2 를 가능하게 만들었다. 사실 시나리오 2 가 가능하면 시나리오 3 도 가능하다. 하지만 그 동안 버그수정과 로직 검증에 많은 시간이 들었고, 이것들이 해결이 되면 시나리오 3 을 구현하는게 순서라고 생각되어 이제서야 시나리오 3 구현을 완료했다. 시나리오 3 구현의 핵심은 서버와의 통신이다. 시나리오 2 는 증권사 서버로부터의 데이터 수신에만 신경쓰면 됐으므로 비교적 구현이 간단한 반면, 시나리오 3 은 주문, 잔고확인 등 증권사 서버로 데이터를 전송하는 로직까지 구현해야 하므로 이를 관리해주는 관리자 역할이 필요하다. 이는 바로 직전 포스팅인 '실시간을 다루다' 에서 간략하게 소개했다.

시나리오 3 에서 Strategy 주문 시그널이 나오면 API 를 통해 증권사에 주문요청을 해야하는데, 이에 필요한 정보와 이를 사용하기 위한 인터페이스 조작에 대해 간략하게 설명하겠다.

주문에 필요한 정보

주문 시그널이 발생하면 이트레이드 증권 API 에서 제공하는 IXingAPI 클래스의 Request 라는 함수를 호출하게된다. 함수 파라미터를 7 개를 넣어줘야 한다. 이 함수는 주문시 뿐만 아니라 API 에서 제공하는 정보(증권가격, 잔고조회, 계롸조회 등)를 조회하고 싶을 때 사용되는데 IXingAPI 클래스에서 사용빈도가 가장 높은 함수다.

parameter 1 : 주문 요청 후 증권사에서 보내는 답장을 받을 윈도우

parameter 2 : 요청항목(이 요청이 '주문'임을 구분해주기 위한 문자열)

parameter 3 : 주문 정보를 담은 패킷

parameter 4 : 주문 정보를 담은 패킷의 크기

parameter 5 : 연속으로 다음 데이터를 요청할지 여부 (주문시에는 필요없다.)

parameter 6 : 연속으로 다음 데이터 요청시 다음 데이터 시작위치 (역시 주문시에는 필요없다.)

parameter 7 : 주문 요청후 증권사 응답을 기다릴 시간

실질적으로 주문에 필요한 모든 정보는 parameter 3 에 해당한다. 이는 다음과 같다.

* 계좌정보

    1. 계좌번호

    2. 비밀번호

* 주문정보

    3. 선물옵션 종목번호

    4. 매수/매도 여부

    5. 주문타입(시장가, 지정가 등)

    6. 주문가격

    7. 주문수량

주문을 할 떄마다 이 정보들을 빠짐없이 규칙에 맞게 패킷에 기록해서 보내야한다. '계좌정보' 는 이미 확보된 정보고, '주문정보' 의 경우 주문신호가 나올 때 알 수 있는 정보다. Request 함수를 호출하고 나면 증권사에서 응답 메세지가 오는데 그 메세지 안에 포함된 패킷에는 증권사에서 거래소에 요청된 정보들이 담겨져 있고,(Request 수행시 입력된 정보들에 문제가 없다면 그 정보들 그대로 거래소에 요청된다.) 요청한 주문을 취소 또는 정정할 때 필요한 주문번호도 담겨져 온다.

주문 interface

Strategy 클래스에서 사용되는 주문함수들은 처음 구현시에 이미 interface 방식으로 만들어졌다. interface 방식이란 리모콘의 전원, 채널, 음향 등의 버튼들과 그 개념이 같다. 다양한 리모콘들은 버튼명칭은 같지만 내부적으로는 서로 다른 TV 를 호출한다. 이 개념을 주문함수에 적용시키면 주문 방식은 똑같아도 설정에 따라 함수 내부로직은 다르게 호출되어 A 증권사의 API 를 호출할 수도 있고, B 증권사의 API 를 호출할 수도 있다. 혹은 API 를 사용하지 않고 Strategy 클래스 내부에서 주문이 됐다고 가정하는 시뮬레이션 작업을 수행할 수도 있다. 이들 중 어떤것을 수행하게 할지를 결정하기 위해서는 프로그램 구동시에 gApi 라는 변수에 특정 값을 세팅해주면 된다.

gApi = DEFAULT_API    ->    프로그램 내부에서 주문 및 체결을 가정

gApi = ETRADE_API      ->    etrade 증권 API 를 통해 주문

gApi = WOORI_API        ->    우리증권 APi 를 통해 주문(예시)

사실 증권 API 호출 및 주문 인터페이스는 시나리오 1 작업 초기에 모두 구현이 됐었다. 이번 시나리오 3 에서는 증권 API 를 호출하는 함수들을 주문 인터페이스 함수 안에 연결시키는 작업을 진행한 것이고, 추가로 클라이언트로(Cherry Picker)로부터의 요청과 서버(이트레이드증권)로부터의 응답처리를 관리하는 로직을 심어놓은 것이다.

다음 화면은

1. Strategy 에서 주문 시그널 발생

2. 증권사에 주문 요청

3. 증권사에서 거래소로 주문 요청

4. 거래소에서 주문 접수

5. 거래소에서 주문 체결

6. 증권사에 잔고정보 조회 요청

7. 증권사로부터 잔고정보 수신

하는 과정을 보여준다. 각 요청이 있거나 수신이 발생할 때마다 로그파일에 기록 및 화면에 해당내용이 출력된다. 중간중간 봉 생성이 됐다는 메세지('>>>' 로 시작)와 접수된 주문이 모두 체결됐다는 메세지([1/1] - full closing), 그리고 주문을 관리하는 queue 정보도 보인다. 아이맥이라 빛반사가 심하다;;;

API 를 이용한 시스템 트레이딩은 증권사 서버에서 정보를 받아와 그 정보를 분석한 후에 주문을 내거나 추가적인 정보를 다시 얻어오는 등 다양한 행동이 서버에서 받은 정보를 근거로 이루어진다. 그러므로 모든 행동은 절차적으로 정교하게 이루어져야한다.

시스템 분석 엔진에서 다음과 같은 신호가 발생했다고 가정하자.

===================================

"최근월물 선물의 매도 1호가로 1 계약 지정가 주문"

===================================

만약(그럴일은 없겠지만) 거래소 서버에 직접 트레이딩 프로그램을 깔 기회가 있다면 다음과 같이 코딩하면 된다. (사용해본 적이 없는 아주 엉뚱한 코드이므로 흐름만 보자)

===================================

char sPrice     [100] = ""; // 1호가를 담을 변수

char sFutCode[100] = ""; // 최근월물 선물 코드를 담을 변수

setFutCode( sFutCode, 1 );                    // 최근월물 선물 코드 세팅

setPrice     ( sPrice, sFutCode, ASK_1 );  // 1호가를 세팅

order( sFutCode, "지정가", sPrice, 1 );  // 주문함수

===================================

이렇게 간단하게 만들 수 있다. 하지만 위 코드에서 setFutCode, setPrice 부분은 서버와의 통신을 해야하는 클라이언트의 입장에서는 불가능한 함수이다.

(물론 해당함수의 내부에서 대기시키는 방법도 있고, 실시간 데이터를 받는 경우 로컬에 저장되어있는 값을 세팅한다면 위 코드도 가능하다. 하지만 전자는 다중 스레드 처리를 해줘야하고 후자는 로컬에 저장된 값과 실제 거래소의 값에 타이밍적으로 차이가 있을 수도 있다.)

그럼 위의 주문을 수행시키려면 어떤 방법이 효과적일까. 더 좋은 방법이 많겠지만 환형큐를 이용하여 모든 행동 하나하나를 action 이라고 칭하는 단위로 구분하여 순차적으로 수행시키는 것이다. 쉽게말해 '할일 리스트' 를 환형큐에 차례대로 세팅하고 큐를 관리하는 매니저한테 그것들은 순서대로 수행시키라고 명령을 하는것이다. 그럼 큐관리자는 action 하나를 처리하고 답을 얻을 떄까지 그 다음 action 은 진행시키지 않고 대기하면 된다. 위 주문을 action 단위로 나누면 다음과 같다.

action 1 : 선물코드를 모두 받아온다.

action 2 : 받은 선물코드 중에 최근월물을 찾아 로컬에 세팅한다.

action 3 : 세팅한 선물코드의 호가정보를 받아온다.

action 4 : 받은 호가정보중에 매도 1호가를 찾아 로컬에 세팅한다.

action 5 : action 2, action 4 에서 세팅한 정보로 주문을 낸다.

이렇게 하나의 주문을 내기위해 서버와 세 번의 통신(action 1, 3, 5)을 해야한다. 그래봤자 이 모든 과정이 0.1초도 안걸린다. HFT 의 세계에서는 위의 과정보다 더더욱 많이 효율적인 방법을 써야한다. 위의 예를 들면 선물코드는 장 시작 전에 이미 받아와서 모두 로컬에 세팅된 상태여서 action 1 의 과정이 필요없는 경우 등이 있다.

(참고로 실제 Cherry Picker 에서 위의 주문을 성사시키려면 action 5 만 수행하면 된다. action 1, 2 는 시스템 구동시에 이미 로컬에 저장된 상태고, action 3, 4 는 실시간 호가데이터 수신으로 역시 이미 로컬에 최신 정보가 저장된 상태이기 때문이다. action 1~4 는 circular queue 사용법을 설명하기 위한 예일 뿐이다.)

이를 그림으로 표현하면 다음과 같다. (못난그림)

15 개의 action 을 세팅할 수 있는 환형큐다. 큐안의 숫자는 action 고유번호고, action position 은 현재 수행되는 action 의 위치, set position 은 현세 세팅되는 action 의 위치를 의미한다. 큐사이즈는 마음대로 정할 수 있지만 그렇다고 1000, 2000 개까지는 필요없다. 코스피 전종목을 거래하는 거대한 시스템이라면 10000 개도 모자르겠지만... 

결론적으로 이런식으로 action 을 다루는 로직을 구현했고 정보창에 다음과 같이 표시되어 쉽게 현재상태를 알수 있게 만들었다.

부가설명을 하자면 'XX[YYY] will be executed' 는 '큐의 XX 번째에 있는 YYY 라는 action 이 수행된다.' 라고 해석하면 된다. action 번호를 다 외우지는 않았지만 111 은 호가조회 action 125 는 받아온 호가를 주문관련변수에 세팅하는 action 124 는 주문하는 action 일것이다. 그리고 숫자열 상단의 '@' 표시는 환형큐의 action position 을 의미하고 숫자열 하단의 '*' 표시는 환형큐의 set position 을 의미한다.

이런식으로 모든 행동을 관리하면 상당히 복잡한 주문도 절차에 의해 간단하게 수행될 수 있다. :)

SetTimer 함수를 도입하려고 한다.

SetTimer 는 수행시키는 순간부터 일정시간이 흐른 후에 callback 함수가 수행되거나 윈도우 메세지를 받을 수 있게한다. 단순 sleep 함수랑 다른점은 지정한 시간이 경과되고 타이머가 울릴(?)때까지 프로세스는 다른작업이 가능하다는 점이다. sleep 함수는 타이머가 울릴 때까지 (main thread 만 존재한다면)모든 작업이 중지된다. SetTimer 처럼 동작이 가능한 이유는 SetTimer 가 수행되면 thread 가 별도로 생성되기 때문이다. 

이 함수의 설명을 들으면 이것저것 적용을 시켜볼만한 부분이 떠오르는데 대략 정리하면 다음과 같다.

1. 장 시작, 장 마감, 동시호가 시작, 동시호가 끝 등의 알림

2. 분봉 생성을 위한 타이머의 역할

3. 장 종료 후에 파일 쓰기 버퍼에 쌓여있는 데이터들을 flush 하기위한 알림

4. 주문 후 일정시간이 지나도 체결이 되지 않으면 주문 취소

5. 진입 후 일정시간 후에 청산

6. 연속조회 또는 연속주문 제한에 걸리지 않기위해 delay 를 줄 때

7. 그 외 각족 알고리즘 전략에 활용

증권 API 에서 지수값을 실시간 데이터로 받기 시작하면 2 초에 한 번씩 수신이 되는데 이것은 훌륭한 타이머 역할을 한다. 실시간 지수 데이터에 기록된 시간은 거래소에서 사용되는 시간이고 다른 모든 증권 데이터들도 그 시간을 기준으로 동작하기 때문이다. 그래서 본인은 지수 데이터의 초단위가 '00' 초가 되는 순간 필요한 작업들을 수행한다.

이 훌륭한 타이머로 가능한 작업은 위 항목 중에 2 번에 해당된다. 안타깝게도 지수 타이머(?)는 장 시작과 동시에 작동하는게 아니고 장 시작시간 + 1 분, 즉 9 시 1 분부터 시작하고 파생상품 시장 종료 이전에(15시 정각) 끝나버리기 때문에 위 항목 중 1 번에는 적용이 안된다. 따라서 2 번을 제외한 모든 항목에서 이 SetTimer 함수는 아주 유용하게 쓰일것 같다. 참고로 2 번 이외의 항목들은 선물 실시간 데이터에 기록된 시간을 이용해서 구현했었다.

Cherry Picker 란?

정의 :

'증권 API 를 이용한 실시간 알고리즘 트레이딩' 및 '과거 틱데이터, 분데이터를 이용한 알고리즘 전략 시뮬레이션'을 수행하기 위해 개발된 라이브러리 (LIB 또는 DLL 형태)

이해하기 쉬운 정의 :

전략 아이디어만 몇 줄의 코드로 작성하면 나머지 모든 귀찮고 복잡한 처리들을 알아서 수행시켜주는 똘똘한 녀석. 여기서 말하는 '나머지' 일들이란...

(1) 증권사에 접속

(2) 전략에서 요구하는 어떠한 데이터든지 수량에 관계없이 실시간으로 자동연결

(3) 전략을 실시간으로 감시하다가 주문조건이 맞으면 자동으로 증권사에 주문

(4) 포지션 관리는 물론 복수의 전략을 포트폴리오로 단위로 묶어서 관리가 가능

(5) 실제 운용뿐 아니라 과거의 성과를 알아보기 위한 가상테스트가 가능

정도...

개발 시작 날짜 :

2011년 2월부터 현재까지

개발 언어 :

첫 반 년은 Java 로 개발하다가 그 후로 C++ 로 전환

기능(2013년 12월 12일 현재) :

* 데이터

    * 증권사 API 에서 제공하는 모든 실시간 정보 이용 가능 (알고리즘 트레이딩 카테고리의 '심볼리스트' 참조)

    * 과거데이터를 이용한 가상거래에서도 모든 데이터를 사용 가능

    * 전략에 사용되는 데이터 형태는 틱, 분, 시간, 일 등 모든 형태로 가공이 가능

* 함수

    * 모든 금융공학 관련 함수 이용 가능

    * 사용자 정의함수 추가 기능

    * 함수 내부에서 과거데이터 참조기능(average(close, 5) 형태)

    * 함수 내부에서 다른 함수의 재귀호출 가능

* 전략

    * 전략이란 전략에 사용되는 정보가 갱신될 때마다 수행되는 부분을 의미(TradeStation 과 동일한 형태)

    * 전략의 기본형태는 데이터 처리 -> 조건분석 -> 진입 or 청산

    * 같은 포트폴리오에 포함된 전략끼리는 포트폴리오 정보를 공유

    * 복수의, 다양한 형태(틱, 분 등)의 데이터를 하나의 전략에서 사용 가능

* 주문

    * 증권사 API 를 통해 복수의 종목을 동시에 주문 가능

    * 과거데이터를 이용한 가상거래시에는 프로그램 내부에서 주문 및 체결을 가정함

    * 포트폴리오 내부의 전략들의 주문이 상쇄되는 주문일 경우 무효처리되도록 감지

* 조회 및 전략 모니터링

    * CUI 형태로 전략 및 포트폴리오 상황 모니터링이 가능

    * CUI 형태로 체결, 미체결, 잔고, 손익결과 조회 가능

사용자 인터페이스 :

아래 5 개의 클래스가 사용자가 취급해야하는 클래스의 전부다.

Symbol : 이 클래스에 데이터를 등록한다.

Strategy : 이 클래스를 파생시킨 후 'run' 함수를 재정의 하면 재정의된 함수는 특정 타이밍마다 수행된다.

SymbolMgr : Symbol 과 Strategy 를 이 클래스에 등록시켜 관리한다.

TFile : 백테스트시 과거데이터 파일의 경로를 이 클래스에 세팅 후, Symbol 에 등록한다.

XingManager : 증권사와 데이터 통신을 담당한다.

블로그를 만든 이유

이 블로그는 제가 현재 개발하고 있는 Cherry Picker 라는 트레이딩 및 분석툴의 개발과정과 Cherry Picker 를 이용한 시장분석 및 트레이딩 성과 등을 포스팅하므로서 저와 같이 시스템 트레이딩 및 트레이딩툴 개발에 관심이 있는분들과 정보를 공유하는 목적을 가지고 있습니다.

블로그 메뉴 소개

* 알고리즘 트레이딩 -> Cherry Picker 를 이용한 알고리즘 트레이딩 및 분석 예제

    * 전략구현 프로세스 -> 빠른 전략 구현을 위한 전략구현 프레임(전략 구현 가이드)

    * 심볼 리스트 -> 현재 Cherry Picker 에서 전략 구현 시 사용 가능한 심볼 정보

    * (1) 알고리즘 트레이딩 전략 1

    * (2) 알고리즘 트레이딩 전략 2

    * (3) ...

* Cherry Picker 란? -> Cherry Picker 에 대한 설명

    * Cherry Picker 소개 -> Cherry Picker 및 블로그에 대한 소개

    * Cherry Picker 샘플 -> Cherry Picker 의 사용 예

* Cherry Picker 개발 -> Cherry Picker 개발 정보

    * 일정 -> Cherry Picker 의 개발 일정

    * 개발노트 -> Cherry Picker 개발에 관련된 내용

* TSimulator 개발 -> Cherry Picker 이전명칭으로 그에 대한 개발 정보 (업데이트 종료)

    * TSimulator 소개 -> TSimulator 에 대한 설명

    * 일정 -> TSimulator 의 개발 일정 (업데이트 종료)

    * 개발노트 -> TSimulator 개발에 관련된 내용 (업데이트 종료)

* 전략 시스템 성과 -> TradeStation 및 Cherry Picker 를 이용하여 테스트한 실제 운용전략 성과

    * 전략 pool -> 수익여부와 관계없이 백테스트한 모든 전략들의 특징과 성과를 모아뒀다.

    * 실거래를 위한 성과기준 -> 전략 pool 에서 실거래 가능한 전략을 추출하기 위한 성과기준

    * 실거래 전략 xxx -> 실거래를 위한 성과기준을 통과한 전략들의 상세 성과를 보고

    * 실거래 전략 포트폴리오 -> 실거래 전략들로 구성된 포트폴리오의 성과

* 일기 -> 가끔 생각하는 이야기들

* 잡동사니 -> 개인적인 관심사

    * 기타 -> 기타정보