주문 유형 종료는 ‘앞으로 만들 수 없음’과 ‘이미 열린 주문의 처리’를 나눠 읽어야 합니다. 신규 접수 중단 시각, 기존 주문의 자동 취소·만료·존속, 부분 체결 잔량, API와 화면의 적용 범위를 확인합니다. 이름이 비슷한 대체 주문도 트리거 가격, 지정가 전환, time-in-force와 연동 주문의 취소 규칙이 다를 수 있으므로 일대일 치환하지 않습니다.
종료 시각을 세 개로 나눕니다
공지에는 화면에서 주문 버튼이 사라지는 시각, API 신규 요청이 거절되는 시각, 기존 주문을 처리하는 시각이 각각 있을 수 있습니다. 날짜 하나만 보고 모든 변화가 동시에 일어난다고 가정하지 않습니다. 상품·거래쌍·지역과 현물·마진·파생 범위도 확인합니다.
기존 주문은 자동 취소, 자연 만료, 계속 유효 중 하나일 수 있습니다. 문구가 없으면 자동 취소라고 추정하지 않고 open orders 조회로 확인합니다. 부분 체결 주문은 이미 체결된 수량과 남은 수량의 처리가 다르므로 원 주문 ID와 체결 내역을 보존합니다.
주문 유형의 종료는 버튼 삭제가 아니라 접수·존속·체결·취소 상태 전이의 변경입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 종료 시각을 세 개로 나눕니다
공지에는 화면에서 주문 버튼이 사라지는 시각, API 신규 요청이 거절되는 시각, 기존 주문을 처리하는 시각이 각각 있을 수 있습니다.
- 대체 주문의 이름보다 실행 의미를 비교합니다
STOP과 STOP_LIMIT은 트리거 뒤 시장가 또는 지정가 주문으로 이어지는 차이가 있을 수 있습니다.
- 열린 주문을 상태별로 재고 조사합니다
종료 전에 order type, 상태, 체결 수량, 잔량, time-in-force, 트리거 가격, 연결된 list ID를 내려받습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
대체 주문의 이름보다 실행 의미를 비교합니다
STOP과 STOP_LIMIT은 트리거 뒤 시장가 또는 지정가 주문으로 이어지는 차이가 있을 수 있습니다. 지정가형은 가격 통제가 있지만 급격한 움직임에서 미체결될 수 있고, 시장가형은 체결 가능성을 높이는 대신 실제 가격이 달라질 수 있습니다. 거래소 문서의 정의를 사용해야 합니다.
OCO는 두 주문을 묶어 하나가 실행되면 다른 하나가 만료되는 구조입니다. Binance Spot Glossary도 STOP_LOSS 또는 STOP_LOSS_LIMIT과 LIMIT_MAKER 조합의 조건부 목록으로 설명합니다. 개별 주문 두 개로 바꾸면 한쪽 체결 뒤 다른 주문을 자동 취소하는 원자적 의미가 사라질 수 있습니다.
열린 주문을 상태별로 재고 조사합니다
종료 전에 order type, 상태, 체결 수량, 잔량, time-in-force, 트리거 가격, 연결된 list ID를 내려받습니다. Coinbase International의 열린 주문 응답은 LIMIT, MARKET, STOP, STOP_LIMIT 같은 유형과 NEW·TRADE·CANCELED·EXPIRED·STOP_TRIGGERED 등 이벤트 상태를 구분합니다. 유형만 저장하면 실제 진행 상황을 놓칩니다.
자동 취소 공지가 있다면 취소 이벤트와 잔액 해제가 모두 반영됐는지 확인합니다. 직접 취소가 필요하면 취소 응답만 믿지 않고 주문 조회나 체결 스트림에서 최종 상태를 대사합니다. Coinbase Exchange 취소 문서도 open order를 ID로 취소하며 주문 기록이 제공되지 않을 수 있는 조건을 설명합니다.
| 상태 | 확인할 내용 | 완료 증거 |
|---|---|---|
| 미체결 NEW | 자동 취소·존속 | 최종 주문 상태 |
| 부분 체결 | 체결분·잔량 | 체결 합계와 잔량 0 |
| 트리거 대기 | 트리거 유지 여부 | 조건 주문 조회 |
| 연동 목록 | 상대 주문 취소 규칙 | list 상태 이벤트 |
API 클라이언트는 요청과 응답을 함께 바꿉니다
주문 생성 enum만 제거하면 충분하지 않습니다. 주문 조회 응답, 체결 이벤트, 취소·교체 요청과 오류 코드에도 종료된 유형이 남을 수 있습니다. 과거 주문 이력은 이전 enum을 계속 반환할 수 있으므로 읽기 파서는 구 값을 보존해야 합니다.
Coinbase Upcoming Changes는 cancel-replace가 기존 limit 외 stop과 TPSL까지 지원하도록 확대되는 사례를 보여 줍니다. 지원 범위는 요청 종류마다 달라질 수 있습니다. 대체 주문이 생성 API에 있어도 amend·cancel-replace나 FIX 채널에서 지원된다고 추정하지 않습니다.
전환 리허설에서 가격 경로를 검증합니다
테스트 환경에서 트리거 전 취소, 트리거 직후, 부분 체결, 급격한 가격 통과와 재연결을 재현합니다. 대체 주문의 체결 결과가 과거 주문과 같다고 요구하기보다 의도한 손실 제한·이익 실현 조건이 어떻게 달라지는지 기록합니다.
운영 전환 때는 신규 구형 주문을 먼저 막고 열린 주문 목록을 고정합니다. 잔량을 대체 주문으로 옮길 때 이미 체결된 수량을 빼고 현재 tick size와 최소 주문 조건을 다시 적용합니다. 동일 client order ID 재사용 가능 여부도 문서에서 확인합니다.
- 종료되는 상품·거래쌍·채널과 UTC를 기록합니다.
- 열린 주문의 체결분·잔량·트리거·list ID를 내보냅니다.
- 대체 주문의 트리거와 체결 방식 차이를 승인합니다.
- 생성·조회·취소·체결 이벤트를 함께 회귀 테스트합니다.
- 전환 뒤 구형 enum이 과거 이력에서 읽히는지 확인합니다.
공지에 없는 자동 취소를 가정하지 않습니다
거래소가 신규 접수를 중단한다고만 썼다면 기존 주문이 즉시 사라진다는 뜻이 아닙니다. 반대로 자동 취소가 명시됐는데 직접 존속할 것이라 기대해서도 안 됩니다. 공지 원문과 실제 주문 상태를 근거로 판단합니다.
종료 이유나 시장 영향도 공지에 없는 내용을 꾸며내지 않습니다. 운영팀의 목표는 가격 방향을 예측하는 것이 아니라 주문 의도가 전환 뒤에도 명시적으로 표현되고, 남은 위험 주문이 없는지 확인하는 것입니다.
자주 묻는 질문
주문 유형이 종료되면 기존 주문도 자동 취소되나요?
공지에 명시된 기존 주문 처리와 실제 open order 상태를 확인해야 합니다. 신규 접수 종료만으로 자동 취소를 추정할 수 없습니다.
STOP을 STOP_LIMIT으로 바꾸면 같은 주문인가요?
아닙니다. 트리거 뒤 시장가와 지정가 체결 방식, 미체결 위험이 다를 수 있습니다.
API enum만 바꾸면 전환이 끝나나요?
주문 조회·취소·교체·체결 이벤트와 과거 이력 파싱까지 함께 검증해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
