자동주문 시스템의 성패는 매수 신호의 정확도보다 주문이 실패했을 때 자산을 어떻게 보호하는지에 달려 있습니다. 자동매매 프로그램 제작은 전략 조건, 거래소 API 권한, 주문 상태 확인, 장애 복구 규칙을 하나의 운영 체계로 묶는 작업입니다.
2026년에는 거래소가 시간분할자동주문인 TWAP, 포트폴리오 매수, 인공지능 기반 거래 보조 기능을 확대하면서 자동화 진입 장벽도 낮아졌습니다. 빗썸은 2026년 생성형 AI 기반 자동매매 프로그램 제작 도구인 AI 트레이드 킷을 선보였고, 거래 편의성과 고객 보호 체계도 강화했습니다.
자동매매 프로그램 제작 전 주문권한 설계
거래소 API 키는 전략 실행용 계정의 출금 권한을 제거한 상태로 발급하는 구조가 기본입니다. 매수와 매도 권한만 부여하고, 허용 IP를 서버 공인 IP로 제한해야 키 유출 이후의 피해 범위를 축소할 수 있습니다.
자동매매 프로그램 제작 단계에서 개인 실계좌 전체 잔고를 연결하면 오류 1회가 포트폴리오 전체 손실로 번질 수 있습니다. 자동화 전용 계정 또는 운용 한도를 분리한 하위 계정을 사용하면 주문 오류와 전략 오류를 계정 단위에서 격리할 수 있습니다.
주문 권한은 조회, 주문, 출금으로 분리해 관리합니다. 전략 서버에는 조회와 주문만 허용하고, 출금 기능은 API 키 발급 과정부터 비활성화하는 방식이 안전합니다.
아래 표는 거래소 API 연결에 필요한 권한과 운영 목적을 구분한 내용입니다.
| API 권한 유형 | 자동매매 사용 여부 | 운영 목적 | 보안 통제 방법 |
|---|---|---|---|
| 잔고 조회 | 필수 | 주문 가능 금액과 보유 수량 확인 | 읽기 전용 키 분리 |
| 주문 제출 | 필수 | 지정가·시장가 매수와 매도 실행 | 허용 IP 등록과 주문 한도 설정 |
| 주문 조회 | 필수 | 체결·미체결·취소 상태 확인 | 주문 식별자 별도 보관 |
| 출금 요청 | 불필요 | 자동매매 기능과 직접 관련 없음 | 권한 미부여 |
전략 서버의 비밀키는 소스 코드나 메신저에 저장하면 안 됩니다. 운영체제의 비밀값 관리 기능 또는 별도 암호화 저장소를 사용하고, 키 교체 주기와 폐기 기록을 남겨야 합니다.
모의투자 환경에서 주문 경로를 먼저 검증하는 절차도 중요합니다. 모의투자는 실시간 호가 지연, 부분 체결, 시장가 주문의 체결 가격 차이를 완전히 재현하지 못할 수 있으므로 최소 주문 금액의 실계좌 시험을 별도로 진행해야 합니다.
거래소 API 인증과 주문 상태 모델
API 주문 요청이 서버에서 전송됐다는 사실은 거래소가 주문을 접수했다는 의미와 다릅니다. 통신 시간 초과가 발생하면 주문이 실제로 접수됐는지, 요청 자체가 거래소에 도달하지 못했는지 확인하기 어려워집니다.
이 문제를 해결하려면 주문 요청마다 고유한 주문 식별자를 생성하고, 응답이 없더라도 주문 조회 API에서 해당 식별자를 우선 검색해야 합니다. 시간 초과 직후 같은 주문을 즉시 재전송하면 같은 종목을 2회 매수하는 사고가 발생할 수 있습니다.
주문 상태는 최소 5단계로 관리하는 방식이 적합합니다. 주문 접수 전 단계와 접수 확인 단계, 부분 체결 단계, 전량 체결 단계, 취소 또는 거절 단계를 분리하면 자산 수량 계산의 오류를 줄일 수 있습니다.
아래 표는 주문 데이터베이스에 기록해야 할 상태와 다음 처리 규칙입니다.
| 주문 상태 | 거래소 확인 내용 | 프로그램 처리 | 다음 점검 시점 |
|---|---|---|---|
| 전송 대기 | 주문 요청 미전송 | 잔고·가격·주문 한도 재확인 | 즉시 |
| 접수 확인 | 거래소 주문번호 발급 | 주문번호와 전략 식별자 저장 | 1초 이내 |
| 부분 체결 | 일부 수량 체결 | 체결 수량만 보유 자산에 반영 | 주문 만료 전까지 반복 |
| 전량 체결 | 주문 수량 전체 체결 | 평균 체결가와 수수료 확정 | 즉시 종료 |
| 거절·취소 | 가격 제한·잔고 부족·사용자 취소 | 실패 사유 기록과 전략 중지 여부 판단 | 즉시 |
거래소가 반환하는 주문번호는 전략 내부 식별자와 분리해 저장해야 합니다. 전략 식별자는 같은 신호에서 발생한 주문을 묶는 역할을 하고, 거래소 주문번호는 실제 체결 내역을 조회하는 열쇠 역할을 합니다.
평균 체결가는 주문 제출 당시의 예상 가격으로 계산하면 안 됩니다. 부분 체결이 발생한 경우 체결별 가격과 수량을 합산해 실제 평균 단가를 계산하고, 수수료까지 반영한 순매수 금액을 보유 자산 원가로 기록해야 합니다.
웹훅 신호 검증과 중복주문 차단
웹훅은 차트 플랫폼이나 외부 전략 서버가 특정 조건 발생 사실을 자동매매 서버로 전달하는 통로입니다. 웹훅 수신 주소가 외부에 노출되면 제3자가 임의 주문 신호를 전송할 위험이 있으므로 서명값과 비밀 토큰 검증이 필요합니다.
자동매매 프로그램 제작에서 웹훅 메시지는 종목명, 주문 방향, 전략명, 신호 발생 시각, 신호 식별자, 주문 비중을 포함하는 구조가 적합합니다. 주문 수량을 웹훅에서 직접 전달하기보다 서버가 잔고와 위험 한도를 계산해 최종 수량을 산출하는 방식이 안정적입니다.
같은 신호가 네트워크 재전송으로 2회 이상 도착하는 경우도 대비해야 합니다. 신호 식별자와 전략명, 종목, 발생 시각을 결합한 중복 방지 키를 저장하고 일정 시간 안에 같은 키가 들어오면 주문 요청을 차단해야 합니다.
아래 표는 웹훅 요청을 주문으로 전환하기 전의 검증 순서입니다.
| 검증 단계 | 확인 값 | 차단 조건 | 통과 후 처리 |
|---|---|---|---|
| 접속 인증 | 비밀 토큰과 발신 IP | 토큰 불일치 또는 허용 IP 외 접속 | 요청 본문 해석 |
| 메시지 형식 | 종목·매수매도·신호 시각 | 필수값 누락 또는 허용 외 종목 | 전략 식별자 생성 |
| 신호 신선도 | 신호 발생 시각과 수신 시각 차이 | 사전 설정한 유효 시간 초과 | 시장 가격 확인 |
| 중복 여부 | 신호 식별자와 주문 이력 | 이미 처리한 신호 | 위험 한도 계산 |
| 주문 가능성 | 잔고·최소 주문금액·보유 한도 | 한도 초과 또는 주문 가능 금액 부족 | 거래소 API 주문 제출 |
웹훅 수신 즉시 시장가 주문을 발행하면 급격한 가격 변동 구간에서 예상보다 불리한 체결가가 나올 수 있습니다. 신호 가격과 현재 최우선 매도호가 또는 매수호가의 차이가 사전 설정 범위를 넘으면 주문을 보류하는 가격 이탈 규칙이 필요합니다.
가상자산 시장은 24시간 운영되므로 새벽 시간의 서버 재시작과 통신 단절도 반복적으로 발생합니다. 웹훅 수신 기록, 주문 제출 기록, 체결 확인 기록을 시간순으로 보관하면 장애 시점의 주문 여부를 빠르게 확정할 수 있습니다.
주문 실패 코드별 재시도와 복구 설계
주문 실패는 모두 같은 방식으로 재시도하면 안 됩니다. 일시적 통신 오류는 제한된 횟수의 재전송 대상이지만, 잔고 부족과 최소 주문 금액 미달은 재시도해도 해결되지 않는 영구 오류입니다.
거래소 응답이 없을 때 기존 주문 상태를 먼저 조회합니다. 주문이 접수된 상태에서 재전송하면 동일 종목의 노출 금액이 계획보다 커지고, 손절 규칙도 의도와 다르게 작동할 수 있습니다.
재시도 간격은 1초, 2초, 4초처럼 단계적으로 늘리는 방식이 유용합니다. 주문 API 호출 제한에 걸렸을 때 짧은 간격으로 요청을 반복하면 계정 단위 제한이 길어질 수 있습니다.
아래 표는 대표적인 주문 실패 상황별 처리 규칙입니다.
| 실패 상황 | 발생 원인 | 즉시 처리 | 재주문 판단 |
|---|---|---|---|
| 통신 시간 초과 | 서버 지연 또는 네트워크 단절 | 주문 식별자로 기존 주문 조회 | 미접수 확인 후 1회 재시도 |
| 호출 제한 초과 | 짧은 시간의 과도한 API 요청 | 호출 중단과 대기 시간 적용 | 대기 후 잔여 횟수 범위에서 재개 |
| 잔고 부족 | 수수료 반영 부족 또는 다른 주문 점유 | 가용 잔고 재조회 | 주문 수량 재계산 후 신규 신호에서만 실행 |
| 최소 주문금액 미달 | 부분 매도 후 잔여 수량 축소 | 잔여 수량과 최소 금액 기록 | 가격 상승 또는 추가 수량 발생 시 판단 |
| 가격 제한 거절 | 허용 가격 범위 이탈 | 현재 호가와 신호 가격 비교 | 가격 이탈 한도 이내일 때만 재계산 |
주문 실패가 연속 발생하면 전략을 자동 정지하는 서킷브레이커가 필요합니다. 예를 들어 10분 동안 인증 오류가 3회 발생하거나 주문 조회 실패가 5회 누적되면 신규 주문을 차단하고 운영자 알림만 전송하는 방식입니다.
자동매매 프로그램은 주문 상태 확인과 오류 대응 체계를 중심으로 구축합니다. 체결 여부를 확정한 뒤에만 다음 주문을 허용하는 순서 제어가 손실 확산을 막는 핵심 장치입니다.
자동매매 프로그램 제작 위험한도와 운영기록
전략 수익률이 높더라도 주문 한도가 없으면 급격한 변동 구간에서 계좌 변동성이 과도하게 확대됩니다. 종목별 최대 보유 비중, 1회 주문 비중, 하루 손실 한도, 연속 손실 횟수를 각각 분리해 제한해야 합니다.
하루 손실 한도는 실현 손익만 반영하면 위험 관리가 늦어질 수 있습니다. 보유 포지션의 평가손익까지 포함한 계좌 손실률을 계산하고, 한도 도달 시 신규 진입을 중지하는 방식이 현실적입니다.
거래소 수수료와 호가 단위, 최소 주문 금액은 백테스트 수익률과 실제 운용 수익률의 차이를 키우는 요소입니다. 백테스트에는 보수적으로 높은 수수료와 불리한 체결 가격을 반영해야 실전 괴리를 줄일 수 있습니다.
아래 표는 계좌 규모별로 적용할 수 있는 주문 한도 계산 예시입니다.
| 운용 자금 | 1회 주문 비중 | 1회 최대 주문금액 | 종목별 보유 한도 | 하루 손실 중지선 |
|---|---|---|---|---|
| 1,000,000원 | 5% | 50,000원 | 200,000원 | 30,000원 |
| 5,000,000원 | 4% | 200,000원 | 1,000,000원 | 150,000원 |
| 10,000,000원 | 3% | 300,000원 | 2,000,000원 | 300,000원 |
| 30,000,000원 | 2% | 600,000원 | 6,000,000원 | 900,000원 |
위 계산은 위험 분산을 위한 예시이며, 레버리지 상품과 해외선물에는 동일 비율을 적용하기 어렵습니다. 증거금 거래는 가격 변동 폭과 강제청산 조건이 더 크게 작용하므로 계약 수, 증거금률, 손절 주문의 실제 작동 여부를 별도 관리해야 합니다.
운영 로그에는 신호 수신 시각, 주문 요청 시각, 거래소 응답, 주문번호, 체결 수량, 평균 체결가, 실패 코드, 재시도 횟수를 남겨야 합니다. 이 기록은 전략 성과 분석보다 주문 오류 원인과 계좌 수량 불일치를 추적하는 데 먼저 사용됩니다.
- 출금 권한 제거
- 허용 IP 제한
- 신호 식별자 중복 차단
- 주문번호 기반 체결 조회
- 하루 손실 한도 자동 중지
- 장애 알림과 로그 보관
- 해외선물 자동매매 프로그램 비교 및 2026년 추천 전략 (2026년)
- 해외선물 자동매매 추천 프로그램 비교 및 설정법 (2026년)
- 해외선물 자동매매 프로그램 추천 및 2026년 실제 수익 후기
질문으로 정리한 핵심
Q. 웹훅을 받으면 즉시 시장가 주문을 실행해도 됩니까?
웹훅 수신 직후에는 신호 시각, 중복 여부, 현재 가격, 가용 잔고를 먼저 확인해야 합니다. 신호 가격과 현재 호가의 차이가 커진 경우에는 시장가 주문이 예상보다 높은 매수가 또는 낮은 매도가로 체결될 수 있습니다.
Q. API 주문 응답이 없으면 같은 주문을 다시 보내도 됩니까?
우선 거래소 주문 조회 API에서 기존 주문의 접수 여부를 확인해야 합니다. 시간 초과는 주문 미접수를 뜻하지 않으므로, 확인 없이 재전송하면 중복 주문 위험이 발생합니다.
Q. 자동매매 서버가 재시작된 뒤 보유 수량이 맞지 않으면 어떻게 처리합니까?
거래소의 실제 잔고와 미체결 주문 상태를 우선 기준으로 적용합니다. 잔고 대사 완료 전까지 신규 주문을 중지하고, 체결 내역을 다시 반영한 뒤 전략 상태를 복원해야 합니다.
Q. 자동매매 프로그램 제작에서 가장 먼저 구현할 기능은 무엇입니까?
주문 제출 기능보다 잔고 조회, 주문 조회, 중복 주문 차단, 손실 한도 중지 기능을 먼저 구현해야 합니다. 이 4개 기능이 갖춰져야 전략 신호 오류와 통신 장애가 계좌 손실로 확대되는 위험을 낮출 수 있습니다.
여기 정리한 거래소 API 권한, 웹훅 보안, 주문 복구 기준은 2026년 10월 운영 환경을 기준으로 작성했으며 거래소별 API 정책과 주문 제한은 변경될 수 있습니다. 자동매매 프로그램 제작은 전략 수익률보다 주문 검증과 실패 대응 규칙을 먼저 완성하는 순서가 적합합니다.
정확한 적용 여부는 거래하시는 금융기관이나 관할 기관에 문의해 확인하시기 바랍니다.
