거래소 API 자동매매 연동: 개요와 핵심 흐름

자동매매 봇은 결국 거래소 API를 통해 시세를 읽고 주문을 냅니다. REST와 웹소켓의 역할 분담, 인증·서명, 레이트리밋, API키 보안까지 연동의 핵심 흐름을 짚습니다.

REST vs 웹소켓: 언제 무엇을 쓰나

거래소 API는 크게 두 가지 통신 방식을 씁니다. REST는 "요청-응답" 방식으로, 주문 넣기·취소·잔고 조회처럼 한 번 호출하고 결과를 받는 동작에 적합합니다. 웹소켓은 "연결 유지·실시간 푸시" 방식으로, 체결가·호가·내 주문 상태가 바뀔 때마다 거래소가 먼저 밀어줍니다.

실무 패턴은 명확합니다. 시세 수신은 웹소켓, 실제 주문 집행은 REST로 분리합니다. 웹소켓으로 가격을 받아 신호를 계산하고, 매수·매도 결정이 서면 REST로 주문을 냅니다. 스캘핑처럼 빠른 반응이 필요할수록 웹소켓 의존도가 높아집니다.

인증과 서명: 안전하게 명령을 전달하는 법

시세 조회는 보통 공개(public)지만, 주문·잔고 같은 자산 관련 호출은 반드시 인증(private)이 필요합니다. 대부분 거래소는 API Key + Secret Key 쌍과 HMAC-SHA256 서명을 씁니다.

1. 요청에 현재 시각 타임스탬프를 포함합니다(서버 시각과 보통 ±5초 이내, 시계 어긋나면 거부됩니다).
2. 요청 내용(경로·파라미터·타임스탬프)을 하나의 문자열로 만듭니다.
3. 그 문자열을 Secret Key로 HMAC 서명해 헤더에 담아 보냅니다.
4. 거래소가 같은 방식으로 서명을 재계산해 일치하면 요청을 승인합니다.

주문·잔고 호출의 기본 흐름

자동매매 한 사이클은 보통 이렇게 돕니다.

• 잔고 조회: 가용 자산을 확인해 주문 수량을 계산합니다. 시드 관리 원칙에 따라 한 번에 거는 비중을 제한합니다.
• 주문 생성: 종목·방향(매수/매도)·수량·가격·타입(지정가/시장가)을 보냅니다. 지정가는 슬리피지가 작지만 미체결 위험, 시장가는 즉시 체결되나 불리한 가격에 잡힐 수 있습니다.
• 체결 확인: 주문 ID로 상태를 조회하거나 웹소켓으로 체결 이벤트를 받습니다.
• 리스크 관리: 손절 주문을 함께 걸어 둡니다. 선물이라면 레버리지와 청산 가격을 매 사이클 점검합니다.

실거래 전에는 거래소 테스트넷(모의 환경)이나 충분한 백테스트로 주문 로직을 검증하는 것이 안전합니다.

레이트리밋: 차단당하지 않으려면

거래소는 과도한 호출을 막기 위해 레이트리밋(요청 한도)을 둡니다. 한도 단위는 거래소마다 다르지만 보통 "초당 또는 분당 요청 수" 또는 "가중치(weight) 합산" 방식입니다. 예를 들어 분당 1,200 가중치가 한도라면, 가중치 5짜리 주문 조회를 분당 240회까지만 보낼 수 있는 식입니다.

• 잔고·시세를 매초 폴링하지 말고 웹소켓 푸시로 대체해 호출 수를 줄입니다.
• 응답 헤더의 남은 한도 정보를 읽어 동적으로 호출 속도를 조절합니다.
• 429(한도 초과) 응답이 오면 즉시 재시도하지 말고 지수 백오프(점점 길게 대기)로 물러섭니다. 무시하고 두드리면 IP가 일시 차단될 수 있습니다.

API키 보안: 권한과 IP가 핵심

API키는 사실상 계정 출입증입니다. 유출되면 자산이 위험하므로 최소 권한 원칙으로 발급합니다.

추가로 다음을 지키면 사고 위험이 크게 줄어듭니다. API 키 관리의 기본입니다.

• IP 화이트리스트: 봇이 도는 서버 IP만 허용합니다. 키가 새도 다른 IP에서는 쓸 수 없습니다.
• 키를 코드·깃에 하드코딩 금지: 환경변수나 별도 보관소에 두고, 화면·로그·메시지에 노출하지 않습니다.
• 정기 회전(교체)과 사용처별 분리: 한 키가 노출돼도 피해 범위를 줄입니다.

리스크 안내: API 연동이 잘 돼도 수익이 보장되는 것은 결코 아닙니다. 연결 끊김, 거래소 점검, 슬리피지, 시계 오차, 코드 버그는 실손실로 이어집니다. 트레이딩 봇은 소액·테스트넷으로 충분히 검증한 뒤, 잃어도 감당 가능한 자금 한도 안에서만 운용하세요.