자동매매의 안정성은 복구 조건에 달려 있다

자동매매를 개인 컴퓨터에서 서버로 옮기면 전원과 접속 환경을 개선할 수 있다. 하지만 서버가 켜져 있다는 사실만으로 프로그램이 정확한 주문 상태를 알고 있거나 안전하게 재시도한다는 뜻은 아니다.

중요한 질문은 장애가 전혀 없는 장소를 고르는 데서 끝나지 않는다. 장애 뒤 무엇을 확인하고 어떤 조건에서 다시 작동할지를 설계해야 한다.

자동화의 안정성은 계속 실행되는 시간과 함께 잘못된 상태에서 멈추고 복구하는 능력으로 평가한다.

1. 살아 있는 프로세스와 정상 작동을 구분한다

프로그램이 켜져 있어도 입력 자료가 오래되었거나 인증이 만료되었을 수 있다. 주문 연결과 계좌 조회가 각각 가능한지도 확인해야 한다.

상태를 확인할 때 마지막 자료 시각, 마지막 정상 처리, 주문과 체결 조회 결과를 본다. 단순한 실행 시간만으로 정상 여부를 판단하지 않는다.

주문을 보낸 뒤 응답이 끊기면 서버에 도착하지 않았을 수도 있고 이미 접수되었을 수도 있다. 곧바로 같은 주문을 새로 보내면 의도보다 많은 주문이 생길 수 있다.

통신 실패와 거래 실패를 같은 상태로 처리하지 않는다. 주문 식별자와 거래소·증권사가 제공하는 조회 기능을 통해 상태를 확인할 절차가 필요하다.

AWS의 재시도 설계 설명은 요청 식별자를 이용해 같은 의도의 반복 실행에서 부작용을 줄이는 방법을 다룬다.

이 원리를 거래에 적용하려면 사용하는 주문 API의 지원 범위·식별자 유효기간·재사용 규칙을 실제 문서로 확인해야 한다. 같은 식별자를 붙였다는 이유만으로 어떤 주문 API에서든 중복이 방지된다고 가정할 수 없다.

재시작 때 내부 파일만 읽지 않고 실제 미체결 주문·체결·보유 수량과 비교한다. 처리 여부가 불명확한 주문을 다시 보내기 전에 조회와 조정이 필요하다.

대기 서버를 두어도 두 프로그램이 동시에 같은 계좌를 제어하면 새 문제가 생긴다. 누가 주문할 권한을 갖는지와 권한을 넘기는 조건을 분명히 한다.

오래된 자료, 계좌 상태 불일치와 미확인 주문처럼 안전하게 판단할 수 없는 조건을 정한다. 원인이 해소되었다는 확인 없이 자동으로 반복 재시작하는 방식은 검토가 필요하다.

복구의 완료는 프로세스가 다시 켜진 순간보다 상태를 확인하고 재개 조건을 충족한 순간에 가깝다. 장애 모의 실험은 실거래와 분리한 환경에서 수행하고, 확인 결과와 남은 제한을 기록한다.