시스템 점검 공지는 제목보다 서비스별 영향표를 읽어야 합니다. 현물·파생 주문 접수, 기존 주문의 체결·취소, 입금·출금, 내부 이체, 로그인, REST·WebSocket API가 각각 멈추는지 확인합니다. 예정 종료 시각은 보장이 아니며, 거래소 상태 페이지와 실제 기능의 정상 응답을 확인한 뒤 자동화를 재개해야 합니다.
공지 제목을 서비스 영향표로 다시 씁니다
점검 공지에서 가장 먼저 찾을 것은 시작·종료 시각보다 대상 서비스입니다. Binance의 2026년 9월 시스템 업그레이드 공지는 로그인과 인증, 입금·이체·출금·결제에서 일시 오류가 날 수 있지만 현물과 선물 거래는 영향받지 않는다고 구분했습니다. 같은 ‘시스템 업그레이드’라도 거래 엔진과 계정·자산 계층의 영향이 다를 수 있다는 사례입니다.
운영자는 공지를 현물 주문, 파생 주문, 주문 취소, 기존 주문 체결, 입금, 출금, 내부 이체, 로그인, API로 나눈 표로 옮겨야 합니다. 문서에 적히지 않은 칸은 정상이라고 채우지 말고 ‘미명시’로 둡니다. 특히 웹 화면이 열리는 것과 주문 API가 정상인 것은 별개이므로 접속 가능만으로 거래 가능을 판정하지 않습니다.
점검의 범위는 공지 제목이 아니라 거래·자금·계정·API별 문장으로 확정합니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 공지 제목을 서비스 영향표로 다시 씁니다
점검 공지에서 가장 먼저 찾을 것은 시작·종료 시각보다 대상 서비스입니다.
- 신규 주문과 기존 주문의 운명을 나눠 읽습니다
‘거래 중단’은 신규 주문 접수만 막는지, 취소까지 막는지, 이미 열린 주문이 계속 체결되는지에 따라 위험이 크게 달라집니다.
- API는 REST와 실시간 연결을 따로 봅니다
자동매매는 주문 REST API가 응답하더라도 WebSocket 체결 통지가 끊기면 내부 상태가 어긋날 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
신규 주문과 기존 주문의 운명을 나눠 읽습니다
‘거래 중단’은 신규 주문 접수만 막는지, 취소까지 막는지, 이미 열린 주문이 계속 체결되는지에 따라 위험이 크게 달라집니다. 열린 주문이 살아 있는데 취소 통로만 막히면 시장 가격이 움직이는 동안 예상치 못한 체결이 생길 수 있습니다. 반대로 거래 엔진이 멈춘다면 화면의 마지막 가격은 현재 거래 가능한 가격이 아닐 수 있습니다.
공지에 open orders, order cancellation, matching engine 같은 표현이 있는지 찾고, 없으면 거래소 지원 문서나 상태 페이지를 확인합니다. 파생 포지션은 거래 중단 여부 외에도 표시가격 갱신, 청산, 담보 이체가 계속되는지 봐야 합니다. 점검 전에 무조건 주문을 취소하라는 일반론보다 자신의 주문과 헤지 경로가 어느 서비스에 의존하는지 먼저 적는 편이 정확합니다.
API는 REST와 실시간 연결을 따로 봅니다
자동매매는 주문 REST API가 응답하더라도 WebSocket 체결 통지가 끊기면 내부 상태가 어긋날 수 있습니다. 반대로 시세 스트림은 살아 있어도 인증·주문 엔드포인트가 실패할 수 있습니다. Binance 문서는 5XX나 10초 처리 시간 초과가 주문 실패를 뜻하지 않고 실행 상태가 unknown일 수 있다고 설명합니다. 이때 같은 주문을 즉시 다시 보내면 중복 주문이 생길 수 있습니다.
점검 창에는 쓰기 요청을 멈추고 주문 ID로 상태를 조회하는 절차를 마련합니다. 연결 복구 후에는 스냅샷을 다시 받은 다음 누락된 체결을 대사하고 스트림을 재구독합니다. HTTP 200 한 번보다 계정 조회, 주문 조회, 시세 시퀀스, 서버 시간의 일관성이 확인돼야 자동화 재개 근거가 됩니다.
시각은 UTC와 예상치의 성격을 확인합니다
공지의 시간대가 UTC인지 현지 시각인지 확인하고 내부 일정도 UTC로 보관합니다. 시작 5분 전 입출금을 막는 공지처럼 실제 중단 시각이 작업 시작보다 이를 수 있습니다. ‘약 1시간’과 ‘06:00~09:00’은 모두 계획값이며, 이용자별 화면에 표시되는 시각 변환도 다시 확인해야 합니다.
종료 예정 시각이 지나도 자동으로 정상이라고 가정하지 않습니다. Binance 지갑 공지는 시스템이 안정적이라고 판단된 뒤 입출금을 재개하며 별도 종료 공지를 내지 않을 수 있다고 명시합니다. 따라서 공지 수정, 상태 페이지, 앱의 실제 입출금 상태처럼 거래소가 제시한 재개 신호를 함께 봐야 합니다.
| 항목 | 공지에서 찾을 문장 | 미명시 때의 처리 |
|---|---|---|
| 거래 | 신규 주문·취소·기존 주문 체결 | 거래쌍별 상태 확인 |
| 자금 | 입금·출금·내부 이체 시작 시각 | 송금 보류 |
| API | REST·WebSocket·인증 영향 | 쓰기 중단 후 상태 대사 |
| 복구 | 예정 종료·안정화·별도 공지 여부 | 공식 상태와 기능 확인 |
복구는 작은 읽기 작업부터 단계적으로 확인합니다
점검이 끝났다는 문구를 본 뒤에도 먼저 공개 시세와 서버 시간을 확인하고, 다음으로 계정 잔액과 열린 주문을 읽습니다. 읽기 상태가 기존 기록과 맞으면 취소·소액 주문 같은 제한된 쓰기 작업으로 넘어갑니다. 출금은 주소, 네트워크, 메모와 한도를 다시 확인한 뒤 별도 단계로 재개합니다.
복구 직후에는 대기 요청을 한꺼번에 재전송하지 않습니다. 클라이언트가 보관한 미확정 주문마다 거래소 주문 ID와 사용자 지정 ID를 조회하고, 체결됐는지 거절됐는지 알 수 없는 상태를 분리합니다. 중복 실행을 막는 대사가 끝나야 예약 작업과 봇을 원래 속도로 되돌릴 수 있습니다.
- 공지 원문의 시간대와 실제 중단 시작을 기록합니다.
- 서비스별로 정상·중단·미명시를 표시합니다.
- 기존 주문과 미확정 API 요청을 별도 목록으로 보관합니다.
- 복구 후 읽기·상태 대사·제한된 쓰기 순으로 확인합니다.
- 상태 페이지와 실제 응답 시각을 운영 로그에 남깁니다.
공지에 없는 사실은 현재 상태로 확장하지 않습니다
점검 공지는 특정 기간의 운영 안내입니다. 자금 안전 문구가 있더라도 모든 주문 손실이나 네트워크 지연을 보상한다는 뜻으로 넓혀 읽을 수 없습니다. 또한 과거 공지의 영향 범위를 다음 점검에 그대로 적용하면 안 됩니다. 매번 원문 제목, 게시·수정 시각과 대상 상품을 확인합니다.
현재 장애를 판단하려면 예정 공지와 상태 페이지의 사건 기록을 구분합니다. 예정 작업이 끝났다는 사실과 개별 계정의 대기 입출금이 처리됐다는 사실도 다릅니다. 독자는 공지로 확인된 범위만 사용하고, 계정별 결과는 거래 내역과 거래소 지원 절차에서 별도로 확인해야 합니다.
자주 묻는 질문
점검 중 거래 화면이 열리면 주문해도 되나요?
화면 표시와 주문·취소 서비스는 다릅니다. 공지의 거래 영향과 API 상태를 확인하고 기존 주문 대사가 끝난 뒤 판단해야 합니다.
예정 종료 시각이 지나면 봇을 바로 켜도 되나요?
그렇지 않습니다. 공식 상태와 REST·WebSocket의 일관성, 미확정 주문을 확인한 뒤 단계적으로 재개하는 편이 안전합니다.
입출금 중단이면 현물 거래도 중단되나요?
항상 그렇지는 않습니다. 공식 공지가 거래와 입출금을 별도로 명시하는 사례가 있으므로 해당 공지의 서비스별 문장을 읽어야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
