자동매매 프로그램에서 '중복 주문'이 왜 문제가 되는가
직접 자동매매 프로그램을 개발하는 투자자에게 가장 현실적인 위험은 전략의 정교함이 아니라 같은 주문이 의도치 않게 여러 번 전송되는 상황입니다. 네트워크 지연이나 응답 지연이 발생하면 프로그램이 주문이 실패했다고 판단해 같은 주문을 다시 보내는 경우가 생길 수 있고, 이 경우 실제로는 먼저 보낸 주문이 체결되었는데도 추가 주문이 중복으로 들어갈 수 있습니다. 수동 매매라면 사람이 화면을 보고 즉시 알아차리지만, 자동매매는 사람이 개입하지 않는 구조이기 때문에 이런 오류가 누적될 위험이 더 큽니다.
토큰 발급과 오류 처리, 구조부터 이해해야 합니다
KB증권 Open API는 App Key와 Secret Key로 발급받은 토큰(Access Token)을 요청 헤더에 담아 호출하는 방식을 사용합니다. 토큰은 일정 시간이 지나면 만료되므로, 자동매매 프로그램을 만들 때는 토큰이 만료되기 전에 미리 재발급을 받도록 설계해야 합니다. 만약 호출이 실패했다면 그 원인이 토큰 만료인지, 아니면 다른 오류인지를 HTTP 상태 코드와 API 오류 코드로 구분해 확인하는 절차가 필요합니다.
중복 주문을 막기 위한 점검 목록
개발 단계에서 아래 항목을 순서대로 점검해 두면 중복 주문으로 인한 손실 위험을 줄일 수 있습니다.
- 주문을 다시 보내기 전에, 먼저 주문번호와 체결 여부를 조회해 이미 처리된 주문인지 확인합니다.
- 동일한 조건의 주문 요청이 짧은 시간 안에 반복되지 않도록 요청 간격을 코드 안에서 직접 제한합니다.
- 응답이 지연되거나 타임아웃이 발생했을 때, 바로 재전송하지 않고 체결 조회 결과를 먼저 확인합니다.
- App Key, Secret Key, 계좌번호는 로그나 화면에 그대로 남기지 않도록 별도로 처리합니다.
호출 한도와 오류 코드, 운영 정책 변화를 함께 확인해야 합니다
API 호출 한도와 제공 기능, 이용 가능 시간은 운영 정책에 따라 제한되거나 변경될 수 있습니다. 따라서 자동매매 프로그램이 한도를 초과해 호출을 반복하면 일시적으로 요청이 거부될 수 있으므로, 재시도 간격과 호출량을 코드 안에서 관리하는 장치를 마련해 두어야 합니다. 또한 주문 가능 상품과 시간, 오류 처리 조건은 최신 API 문서를 통해서만 정확히 확인할 수 있으므로, 전략을 실제 계좌에 적용하기 전에는 포털의 최신 안내를 다시 확인하는 절차가 필요합니다. 한편 자동매매 대상 종목의 재무 상태나 공시 변화는 API로 조회되는 시세·주문 정보만으로는 파악하기 어려운 경우가 있으므로, 전략에 포함된 종목의 공시 내역은 전자공시시스템 DART에서 별도로 확인하는 습관을 함께 가지는 것이 바람직합니다.
정리하며
자동매매 프로그램을 만드는 과정에서는 전략의 수익성보다 먼저 주문이 중복되지 않도록 설계하는 작업이 선행되어야 합니다. 토큰 재발급, 체결 여부 선확인, 호출 한도 관리라는 세 가지 장치를 코드 안에 넣어 두면, 네트워크 지연이나 일시적 오류가 발생해도 의도치 않은 중복 주문으로 이어지는 위험을 줄일 수 있습니다. 모든 투자 판단과 프로그램 실행의 책임은 이용자 본인에게 있으므로, 실제 계좌에 연동하기 전에는 모의거래 체험 기능 등으로 충분히 점검하는 과정이 필요합니다.