투자 관련 API를 사용할 때 조심해야 할 점

 

 

잠수함 패치

 

키움증권 OpenAPI/OpenAPIG, 대신증권 CreonAPI, 이베스트 투자증권 XINGAPI, 빗썸, BYBIT, Binance, 업비트...

최근 3년 사이에 그래도 꽤 많은 API들을 써본 사용자의 입장에서 가장 고민스러운 것은 API가 언제 어떻게 업데이트될지 알 수가 없다는 것이다.

 

 

다행히 주력으로 사용하고 있는 키움증권 OpenAPI/OpenAPIG의 경우에는 중요한 업데이트 전에는 이와 관련된 문자메시지를 사전에 몇 번 받았던 좋은 경험이 있었다. 처음 어떤 API를 사용할까 고민도 많이 했는데 가장 큰 증권사이고 사용자가 많아서 Trouble shooting도 어렵지 않다는 점에서 키움증권을 선택했는데 중요한 업데이트 시에도 미리 알려주는 점은 만족스러웠다. 가끔 뜬금없이 수익률이나 잔고조회 TR들이 일 년에 한 번쯤 말썽을 부릴 때가 있긴 했지만 그 외에 지금까지는 큰 문제는 없었다. 

 

 

반면에 이베스트 투자증권 XINGAPI는 크게 실망했던 기억이 있다. 멀쩡하게 거래하고 있었는데 어느 날부터 프로그램이 진입 시그널은 보내고 있는데 주문에 실패했다는 메시지만 계속 반복됐다. 주중에 너무 바쁜 일들이 많아서 한 3~4일 정도 방치해두었다가 문제를 해결해보려고 한참을 끙끙대다가 홈페이지를 가보니 다른 사소한 것도 아닌 중요한 주문 관련 API의 함수들이 한꺼번에 변경되었다는 공지사항을 보고는 당황했다. '필독!'이라고 강조된 공지사항을 올려놓기는 했는데 API의 사용자들이 매일같이 증권사 홈페이지에 접속해서 구석에 있는 API 게시판에 찾아가서 API의 업데이트 유무를 확인하는 것을 기대하고 있는 걸까?

 

 

어떻게 이런 차이가 생기는지 생각해보면 이유는 간단하다. 사용자가 적다. 문제가 생겨도 가서 항의하는 사용자도 적다. 결국 적극적으로 사용자의 입장을 배려할 필요성을 못 느낀다. 만일 지금 당장 무슨 API를 사용해야 할지 고민하는 사람이 있다면 가장 우선적으로 고려해야 할 사항은 많은 사람들이 사용하는 프로그램인가? 하는 사항을 가장 우선적으로 고려하라고 말하고 싶다. COM vs DLL, 33bit vs 64bit, Websocket 지원이니 그런 것들은 다 부차적인 문제다. 자칫 잘못하면 내가 계좌의 예수금을 걸고 API의 베타테스터(또는 알파테스터)가 될 수도 있다.

 

 

 

 

안전지대는 없다.

 

이러한 몇몇 사건들을 겪으면서 키움증권의 API는 그래도 믿을만하다고 생각하고 있었는데 이번 기회로 그 생각을 바꾸게 되었다. 데이터베이스를 정리하다가 어느 순간부터 선물, 주식, 분봉 단위 가리지 않고 모든 테이블이 30초 봉으로 데이터들이 저장된 것을 발견했다. 내 프로그램에 오류가 생겨서 30초 봉으로 요청한 것이 아닐까 하는 생각을 잠시 했지만 키움증권 API에서 지원하는 최소 분봉은 1분 봉으로 애초에 요청이 불가능하다. 이런 말도 안 되는 일이 언제부터 발생했는지 일자별로 DB에 저장된 행의 개수를 점검해봤더니 충격적인 사실을 알게 되었다. 테이블마다 차이는 있지만 대략 9월부터 이런 말도 안 되는 데이터들이 저장되고 있었다. 

 

노란색으로 칠해진 부분들은 각각 1분, 5분, 10분 봉이 하루 동안 발생하는 개수는 396개, 80개, 41개로 정확하게 일치하지만 흰색으로 칠해진 부분의 791개, 792개는 1분 봉의 2배가 되는 수준이다. 즉, 이 구간은 데이터가 30초 봉으로 저장된 것이다.

 

 

프로그램을 점검해봤지만 특별하게 문제 될 것들은 찾을 수가 없었다. 그러다 문득 왜 뒷부분은 문제가 없는 걸까? 하는 의문이 들었다. 따져보니 뒷부분의 노란색으로 칠해진 개수를 다 더하면 대략 900개가 되고 이 개수는 키움증권 API로 한 번에 조회할 수 있는 분봉의 최대 개수와 일치한다. 그렇다면 추가적인 자료를 연속 조회하는 부분에 문제가 있는 것일까 하고 점검해봤더니 역시나...

 

 

 

 

 

예전 코드로 조회하면 아래의 최초 푸른색의 900개를 넘어서는 붉은색의 연속 조회 자료로 넘어가면 뜬금없이 시간 단위가 5분에서 30초로 변경되고 이에 따라 거래량도 급감한다.

 

예전 코드

예전 코드의 출력자료

 

 

 

혹시나 해서 set_input_value 값들을 연속 조회할 때 그대로 다시 넣어주었더니 문제없이 출력됐다. 프로그램의 매뉴얼 상 연속 조회 시 입력 값들의 기준이 바뀌었는지는 확인해보지 않았지만 분명한 것은 기준이 바뀌었다면 애초에 데이터가 출력되지 말았어야 했다. 그런데도 사용자 입장에서 그 어떤 TR을 써서도 조회할 방법이 존재하지도 않는 30초 봉이 출력된 것은 내 입장에서는 결국 최악의 상황이 됐다.

 

수정 코드

수정 코드의 출력자료

 

 

 

 

왜 몰랐을까?

 

 

 

이상한 점들이 몇 가지 있었고 좀 더 빨리 눈치챘어야 했다. 위의 백테스트 자료를 보면 이 시점부터 Equity curve가 이상하게 흘러가고 있다. 거기다가 결정적으로 Equity curve의 선형성을 보기 위해서 slopeline을 그어놓았는데 이 선이 이상하게 튀기 시작한다. 그럴 수밖에 없는 것이 저 구간의 분봉 데이터 밀도가 다른 구간들보다 압도적으로 높으니 선이 위로 튄 것이다. 사실 slopeline이 휘어지는 문제는 비교적 초기에 발견했지만 기능 자체가 필요 없다고 판단하고는 제거해버렸는데 그 선택이 또 한 번 독이 됐다.

 

 

매일 같이 모든 자료들을 하나씩 확인할 수도 없는 노릇이라 앞으로 어떻게 해야 할지 고민해봤다. 중요한 데이터베이스에는 정기적인 백업 기능을 추가하고 API를 활용하는 데이터베이스마다 자료의 정합성을 검증하기 위한 방법을 고안해서 추가하기로 했다.