거래 봇은 거래소에 어떻게 연결할까? API 키, 웹훅, TradingView 알림

하나의 그림으로 보는 전체 연결

자동 거래는 여러 시스템을 거칩니다. 전략이나 머신러닝 모델이 판단을 만듭니다. 웹훅이나 내부 이벤트가 그 판단을 실행 서비스로 전달합니다. 서비스는 거래소 API를 호출하기 전에 메시지와 위험 한도를 확인합니다.

거래소는 주문을 수락할지, 거부할지, 부분 체결할지 결정합니다. 별도의 데이터 스트림이 실제로 일어난 일을 보고합니다. 이후 실행 서비스는 거래소 상태를 자체 기록과 비교합니다.

따라서 신뢰할 수 있는 연결에는 거래소로 향하는 경로와 거래소에서 돌아오는 경로가 모두 필요합니다. 결과를 받고 대사하지 않은 채 주문만 보내는 것은 불완전한 자동화입니다.

웹훅, API, WebSocket은 역할이 다르다

웹훅은 이벤트 알림입니다. TradingView는 알림이 발생하면 URL로 HTTP POST 요청을 보냅니다. 수신 애플리케이션은 메시지를 읽고 어떤 작업을 할지 결정할 수 있습니다.

거래소 API는 시장 데이터 요청, 계좌 정보 조회, 주문 제출 또는 취소에 사용하는 통제된 인터페이스입니다. 인증된 요청에는 보통 API 키, 타임스탬프, 비밀키로 생성한 암호학적 서명이 포함됩니다.

WebSocket은 반복적으로 요청하지 않아도 계속 업데이트를 전달하는 지속 연결입니다. 거래 시스템은 시장 데이터와 주문 변경, 체결, 잔액 업데이트 같은 비공개 계좌 이벤트에 이를 사용합니다.

• 웹훅: TradingView가 신호를 전송
• REST API: 실행 서비스가 주문을 제출하거나 취소
• WebSocket: 거래소가 주문과 계좌의 지속적인 업데이트를 보고

거래 신호는 어디에서 만들어질 수 있는가

TradingView는 가능한 신호원 중 하나입니다. Pine Script 전략이나 지표는 조건이 충족되면 알림을 발생시킬 수 있습니다. 웹훅 메시지에는 종목, 방향, 전략 식별자, 의도한 작업을 포함할 수 있습니다.

머신러닝 봇은 자체 서버 안에서 신호를 만들 수도 있습니다. 시장 특성을 처리하고 환경을 분류한 뒤 TradingView 없이 내부 판단을 동일한 위험 및 실행 시스템에 직접 보낼 수 있습니다.

연결 방식이 전략을 지능적으로 만들거나 수익성 있게 만들지는 않습니다. 웹훅은 단순한 이동평균 신호를 전달할 수 있고, 직접 API를 사용하는 시스템은 복잡한 모델을 실행할 수 있습니다. 신호 품질과 전달 구조는 별개의 문제입니다.

TradingView 알림 발생 후에 일어나는 일

TradingView는 설정된 HTTPS 엔드포인트로 알림 본문을 보냅니다. 본문이 유효한 JSON이면 JSON 콘텐츠 유형으로 전송합니다. 수신 서비스는 빠르게 응답하고 이벤트를 저장한 뒤 시간이 오래 걸리는 작업은 큐로 넘겨야 합니다.

서비스는 요청을 인증하고 모든 필드를 검증하며 알 수 없는 종목이나 작업을 거부해야 합니다. 반복 전송이 중복 주문을 만들지 않도록 고유한 이벤트 식별자도 부여해야 합니다.

웹훅에는 지시를 넣어야 하며 거래소 자격 증명을 넣어서는 안 됩니다. TradingView는 웹훅 URL이나 메시지에 비밀번호, 로그인 정보 또는 다른 민감한 정보를 넣지 말라고 명시적으로 경고합니다.

거래소 API 키가 작동하는 방식

API 키는 거래소에 애플리케이션을 식별합니다. 함께 제공되는 비밀키는 비공개 요청에 서명하는 데 사용됩니다. 비밀키는 실행 서버에 보관해야 하며 브라우저 코드, 공개 저장소, 웹훅 메시지 또는 스크린샷에 절대 나타나서는 안 됩니다.

거래소는 기능을 권한별로 나눕니다. 키에는 계좌 데이터 조회, 현물 주문, 선물 거래 또는 다른 상품 접근이 허용될 수 있습니다. 가장 안전한 설정은 전략에 필요한 최소 기능만 부여하는 것입니다.

일반적인 자동 거래에는 자금 출금 권한이 필요하지 않습니다. 출금을 비활성화하면 거래 키가 탈취됐을 때 가능한 행동을 제한할 수 있습니다. 지원되는 경우 IP 제한으로 서명된 요청을 수락할 출발지도 더 제한할 수 있습니다.

신호와 주문 사이에 위험 엔진이 필요한 이유

신호가 독립적인 확인 없이 자동으로 주문이 되어서는 안 됩니다. 실행 서비스는 종목이 허용되는지, 요청한 매수·매도 방향이 유효한지, 수량이 거래소 규칙을 준수하는지, 결과 노출이 계좌 한도 안에 있는지 확인해야 합니다.

오래된 알림이나 현재 포지션과 충돌하는 판단은 거부해야 합니다. 여러 알림이 동시에 도착하거나, 전략이 같은 지시를 반복하거나, 신호 생성 이후 가용 증거금이 바뀌었을 때 어떻게 할지도 정해야 합니다.

이 분리는 전략 오류와 잘못된 형식의 메시지 모두로부터 계좌를 보호합니다. 전략은 행동을 제안합니다. 위험 엔진은 그 행동이 지금 허용되는지 결정합니다.

주문 제출과 체결은 다르다

API 요청 수락은 보통 거래소가 주문을 인식했다는 뜻입니다. 전체 수량이 거래됐다는 뜻은 아닙니다. 지정가 주문은 미체결 상태로 남거나 부분 체결될 수 있습니다. 시장가 주문은 여러 가격에서 체결될 수 있습니다. 수량, 정밀도, 증거금 또는 요청 빈도 제한 때문에 주문이 거부될 수도 있습니다.

봇은 거래소 주문 식별자를 저장하고 최종 상태에 도달할 때까지 상태를 추적해야 합니다. 요청이 시간 초과되면 재시도 전에 거래소가 주문을 생성했는지 확인해야 합니다. 무작정 재시도하면 중복 포지션이 생길 수 있습니다.

손절과 익절 로직에도 확인된 포지션 정보가 필요합니다. 체결됐다고 가정하고 청산 주문을 연결하면 실제 포지션이 충분히 보호되지 않거나 실제 노출보다 큰 주문이 만들어질 수 있습니다.

비공개 데이터 스트림과 대사가 필수인 이유

거래소는 비공개 사용자 데이터 스트림을 통해 주문, 체결, 포지션, 잔액 변경을 푸시할 수 있습니다. 이렇게 하면 전체 계좌 상태를 반복 요청하는 것보다 실행 서비스가 더 빠르게 피드백을 받습니다.

스트림은 연결이 끊기거나 이벤트를 놓칠 수 있으므로 유일한 기록이 되어서는 안 됩니다. 시스템은 API로 공식 계좌 데이터를 주기적으로 요청하고 내부 데이터베이스와 비교해야 합니다. 이 과정을 대사라고 합니다.

불일치는 알림이나 일시 중지를 유발해야 합니다. 봇은 거래소 계좌와 다른 포지션을 보유하고 있다고 믿는 상태로 무기한 계속 실행되어서는 안 됩니다.

최소 보안 기준

웹훅 엔드포인트에는 HTTPS, 강력한 인증, 엄격한 입력 검증, 요청 빈도 제한을 적용해야 합니다. 비밀 정보는 소스 코드가 아니라 전용 비밀 관리 시스템이나 보호된 서버 환경에 저장해야 합니다.

사용자와 전략마다 인가를 분리해야 합니다. 식별자만 바꿔서 한 계좌가 다른 계좌를 참조할 수 있어서는 안 됩니다. 로그는 비밀 정보 전체를 노출하지 않은 채 판단과 주문 결과를 기록해야 합니다.

노출이 의심되면 키를 교체하고 더 이상 필요하지 않으면 즉시 제거해야 합니다. TradingView와 거래소 계좌는 2단계 인증으로 보호해야 합니다. 보안은 한 번의 설정 화면이 아니라 지속적인 운영 과정입니다.

연결의 일부가 실패하면 일어나는 일

TradingView는 웹훅이 설정된 URL에 간혹 도달하지 않을 수 있다고 설명합니다. 따라서 실행 서비스에는 알림 로그와 전달 모니터링이 필요합니다. 신호 누락, 주문 거부, 피드백 스트림 손실은 서로 다른 세 가지 실패이므로 각각 다른 대응이 필요합니다.

시스템은 실패 시 안전하게 동작해야 합니다. 현재 계좌 상태를 알 수 없다면 보통 새로운 노출을 여는 것보다 일시 중지하는 편이 타당합니다. 주된 전략 과정이 작동하지 않아도 기존 보호 주문은 확인하고 관리할 수 있어야 합니다.

운영 테스트에는 중복 메시지, 지연된 메시지, 잘못된 수량, 부분 체결, 연결 손실, 서버 재시작, 거래소 중단이 포함되어야 합니다. 정상 경로는 실제 운영 준비의 한 부분일 뿐입니다.

TensorParadigm이 자산을 보관하지 않고 연결하는 방식

TensorParadigm은 사용자 자금이 사용자의 거래소 계좌에 남아 있도록 설계되었습니다. 거래 에이전트는 사용자에게 서비스로 자금을 옮기라고 요구하는 대신 시장 접근과 실행에 필요한 API 권한으로 연결합니다.

일반적인 운영에는 출금 권한이 필요하지 않으며 비활성화 상태로 유지해야 합니다. 이는 자산 보관 권한을 제한하지만 시장 위험이나 거래 자격 증명을 보호할 필요를 없애지는 않습니다.

신호는 주문이 거래소에 도달하기 전에 실행 및 위험 통제를 거칩니다. 이후 주문 결과와 계좌 포지션을 모니터링하고 대사해야 합니다. 연결의 가치는 단순히 속도에 있지 않습니다. 통제되고 관찰 가능하며 반복 가능한 실행에 있습니다.

솔직한 결론

거래 봇은 하나의 마법 같은 설정이 아니라 여러 단계의 연결을 통해 거래소에 접속합니다. 웹훅은 이벤트를 전달하고 API는 지시를 제출하며 비공개 스트림은 실제로 일어난 일을 보고합니다.

안전한 설계는 자격 증명을 웹훅 메시지에 넣지 않고, API 권한을 제한하며, 모든 신호를 검증하고, 모든 실거래 포지션을 대사합니다. 이렇게 만든 연결도 수익성 있는 거래를 보장하지는 못하지만 피할 수 있는 실행 및 보안 실패를 많이 예방할 수 있습니다.