17.3 Alpaca 모의 계좌와 거래소 API 연결하기

주문 요청과 체결 통보는 서로 다른 통로를 지난다

프로그램이 미국 주식 10주를 주문하고 성공 응답을 받았다고 하자. 이 응답은 접수를 뜻할 수 있다. 이후 일부가 체결됐는지는 별도 주문 업데이트에서 확인한다. Representational State Transfer(웹 자원을 다루는 요청·응답 방식, REST)로 주문 제출, 계좌 조회, 포지션 확인을 수행한다. WebSocket(양방향 지속 연결)은 연결을 유지하며 체결과 시세 같은 이벤트가 생길 때마다 전달받는 데 쓴다. 스트림이 끊기면 재구독한 뒤 주문과 체결을 조회해 빈 구간을 채운다.

Paper Trading(모의 거래)에서는 모의 환경의 주소와 키를 사용해 전체 계좌 흐름을 연습한다. 여러 거래일 동안 주문 수와 체결 수량, 보유량, 장 마감 대사를 맞춘다. 모의 체결은 시장 주문장과 직접 경쟁하지 않으므로 실거래 미끄러짐이나 시장 충격, 일부 체결 빈도는 소액 실거래에서 별도로 측정한다.

연결 방법과 실행 비용을 함께 비교한다

수수료가 0원이어도 매수 호가와 매도 호가 사이의 간격인 Spread(스프레드)와 체결 전 가격 변화가 비용을 만든다. Payment for Order Flow(주문 흐름에 대한 대가, PFOF)가 적용되는 경로를 포함해, 어떤 장소로 주문이 가고 주문 도착 기준가와 실제 체결가의 차이가 얼마인지 살핀다. 시세 범위·속도·요청 한도는 사용하는 계약에서 확인한다.

현물과 무기한 계약은 같은 티커로 대체할 수 없다

암호자산 전략이 19개 무기한 계약에 점수를 냈는데 모의 실행 계좌에는 그중 11개에 대응하는 달러 표시 현물만 있었다고 하자. 현물로 매수 주문 흐름을 시험하고 나머지 8개는 신호만 남길 수 있다. 현물은 만기 없는 파생계약의 펀딩 지급과 공매도 조건을 그대로 재현하지 않는다. 분할 수량을 주문할 수 있더라도 최소 수량과 가격 단위는 상품마다 확인한다. 주말에도 열리는 시장에서는 주말의 장애와 주문 처리까지 감시한다.

Perpetual Swap(무기한 스왑)이나 암호자산 옵션이 필요하면 직접 거래소 API를 검토한다. 예를 들어 사례의 OKX 연결은 시세와 펀딩 기록을 읽고, 상품·계정 권한이 맞으면 같은 거래소를 실행 경로로도 쓸 수 있다. 직접 연결에서는 거래소가 주문을 맞추는 역할과 자산을 보관하는 역할을 함께 맡을 수 있어 장애와 보관 위험을 함께 평가한다. CryptoCurrency eXchange Trading Library(암호자산 거래소 연결 라이브러리, CCXT)로 공통 요청 형식을 쓸 수 있다. 상품별 증거금, 주문 규격, 관할 지역의 이용 자격은 각각 확인해야 한다.

타임아웃은 주문 실패와 구분한다

Hypertext Transfer Protocol(웹 통신 프로토콜, HTTP) 오류는 상태 코드와 본문을 함께 읽는다. 403이면 키·권한·환경을 확인한다. 422이면 수량, 구매력, 상품이나 거래 시간 같은 검증 사유를 고친다. 429이면 요청 속도를 낮추고 대기열을 둔다. 500·503이나 응답 시간 초과는 서버 장애 또는 응답 유실일 수 있다. 조회를 재시도할 수 있지만 주문 제출의 결과가 불명확하면 먼저 주문 상태를 확인한다.

같은 주문 의도가 한 번만 실행되도록 만드는 성질을 Idempotency(멱등성)라고 한다. ID는 전략, 주문 의도, 종목과 시각을 구별할 수 있어야 한다. 재요청 시 응답 형식과 중복 ID 처리 방식은 연결 규격에 따르고, 성공 기록·진행 중 주문·체결 기록을 모두 대조한다.