자동매매 봇 개발 체크리스트: 시세 관찰부터 주문 복구까지
WORKBENCH / DEVELOPMENT CHECKLIST
자동매매 봇을 만들 때 ‘주문이 한 번 나갔다’를 완성 기준으로 삼으면, 주문이 나가면 안 되는 상황과 응답을 받지 못한 상황이 뒤로 밀립니다. 개발 순서를 나누는 이유는 기능 수를 세기 위해서가 아니라, 다음 단계로 넘어갈 근거를 남기기 위해서입니다.
이 글은 시세 수집부터 주문 복구까지의 작업을 점검하는 체크리스트입니다. 아래 장애 상황은 검증을 설계하기 위한 예시이며, 실계좌에서 발생한 사건이나 수익 기록을 주장하지 않습니다.
M1: 숫자가 바뀌는 화면보다 입력의 이력이 먼저다
시세를 받으면 값과 함께 ‘거래소가 붙인 시각’과 ‘프로그램이 받은 시각’을 구분해 남깁니다. 두 시계가 정확히 맞는다는 전제도 따로 점검해야 합니다. 화면에 최신처럼 보이는 숫자가 있어도 입력이 끊긴 뒤 마지막 값만 유지되고 있을 수 있습니다.
이 단계의 결과물은 시세 표시 화면과 작은 재현 파일입니다. 연결을 일부러 끊었다 붙였을 때 누락을 알 수 있는지, 프로그램이 오래된 값을 계속 새 값처럼 취급하지 않는지를 확인합니다. 공급자가 순번을 제공한다면 순서 역전과 누락 판단에 활용하되, 그 순번의 범위와 재연결 시 동작은 공급자 문서에 맞춥니다.
M2: 같은 입력에는 같은 이유를 돌려준다
실시간 입력을 전략에 바로 연결하기 전에 저장한 데이터로 판단을 재생합니다. BUY라는 결과만 남기면 왜 그 판단이 나왔는지 설명하기 어렵습니다. 사용한 기간, 마지막 확정 봉, 신호를 건너뛴 이유를 함께 기록하면 코드 변경 전후를 비교할 수 있습니다.
예를 들어 이동평균 교차 예제의 입력 [5, 4, 3, 6], 단기 2봉·장기 3봉은 BUY를 반환합니다. 상승 중인 [1, 2, 3, 4]는 새 교차가 없으므로 HOLD입니다. 매수 신호가 나오는 예시와 나오지 않아야 하는 예시를 함께 남기는 것이 포인트입니다.
M3: 주문 상태를 복구할 수 있어야 한다
모의 주문 경로를 붙일 때는 정상 체결 한 번보다 경계 상황을 먼저 목록으로 만듭니다. 주문을 보낸 뒤 응답이 사라졌을 때, 일부 수량만 체결됐을 때, 취소 요청과 체결 통지가 엇갈릴 때 내부 상태가 어떻게 변하는지 정합니다.
| 점검 상황 | 보여 줄 근거 |
|---|---|
| 같은 봉이 두 번 도착 | 같은 이벤트로 두 번째 주문 의도가 생성되지 않는 기록 |
| 주문 응답을 받지 못함 | UNKNOWN 상태 및 조회·대조 경로 |
| 10개 주문 중 4개 체결 | 체결 4개와 미체결 6개가 분리된 상태 |
| 프로세스 재시작 | 저장 상태와 실제 미체결 주문을 대조한 결과 |
| 중지 요청 | 신규 진입 중지, 미체결 처리, 보유 포지션 정책의 구분 |
‘중지’는 하나의 행동이 아닙니다. 신규 진입을 막는 것, 남은 주문을 취소하는 것, 보유 포지션을 청산하는 것은 각각 결과가 다릅니다. 특히 청산은 추가 거래이므로 버튼 하나에 암묵적으로 섞지 말고 정책을 분명히 표시해야 합니다.
작업 노트 한 장으로 남기는 방법
아래처럼 하나의 검증을 한 기록으로 남길 수 있습니다. 예시의 결과는 실행 증거가 아니라 작성 형식을 보여 주는 자리표시자입니다.
case: order_response_lost
environment: local simulator
input: one saved order intent
fault: response dropped after simulated acceptance
expected: UNKNOWN -> query -> reconcile
observed: <fill in after running>
evidence: <local log or test case>관찰값이 비어 있으면 검증은 끝나지 않은 것입니다. 코드가 존재한다는 사실, 테스트가 통과했다는 사실, 실제 서비스 조건까지 확인했다는 사실을 각각 기록하면 다음 작업자가 이어받기도 쉬워집니다.
M1·M2·M3 구현 단계에서 각 단계의 범위를 살펴보고, 전체 모듈 경계는 자동매매 봇 구조도와 맞춰 보세요.
내용·예제 검토: 2026-09-29
댓글
댓글 쓰기