lastest update: 20250414

1. 히스토리

이전 글에서 시장 데이터 피더에서 생기는 레이턴시 하한 에 대한 주제로 글을 썼다.

플랫폼의 가장 앞단에 위치하고, 가장 많은 트래픽이 발생하기에Tick to Trade 최적화 하는것은 매우 중요한 문제이다. 여기서 병목이 발생할 경우, 우리는 이미 훨씬 지난 과거 데이터를 가지고 거래를 해야한다. 시뮬레이션과 완전히 다른 PNL이 나올 수 있다.

이 밖에도 HFT Platform 만들면서 다양한 구현 요구사항과 계좌를 한순간에 녹여버릴 엣지 케이스들이 많다. 예를 들자면 다음과 같다.

1. 거래소 API의 한계 및 불일치 문제
   1. 마켓 데이터가 들어오는 순서를 보장할 수 없다.
   2. 마켓 데이터가 들어왔는데 오염된 정보일 수 있다.
   3. 마켓 데이터가 누락될 수 있다.
   4. Rate limit에 걸릴 경우 대형사고가 날 수 있다.
2. 주문 체결 및 슬리피지 문제
   1. 생성한 주문이 거래소 시스템 내에서 처리되지 않거나, 체결 알림이 지연되는 경우가 있다.
   2. Tick To Trade 레이턴시가 너무 느려질 경우, 슬리피지가 발생해서 손실로 이어질 수 있다.
   3. 웹소켓 세션이 끊어져서 체결 업데이트를 받지 못할 수 있다.
3. 등 상상하기 어려운 엣지 케이스들

이번 글에서는 주문/체결의 상태관리 시나리오를 다룰 예정이다.

2. 문제상황

HFT 전략을 사용한다면 하루에 수만~수십만건의 주문, 체결 데이터를 받을 것이다. 간혹 변동성이 높아져서 주문을 자주 생성하고 취소해야 하는 상황이 자주 생기게 된다.

하지만 거래소는 꽤 빡빡한 Rate limit policy를 가지고 있고, 한번이라도 어기게 되면 가차없이 벤을 준다. 이것은 전략에 매우 위험한 상황이다.

델타 뉴트럴이 풀어질수도 있고, 인벤터리가 가득 쌓인상태에서 역선택을 크게 당할 수 있다. 그러므로 부하분산 구조는 반드시 필요하다. 한쪽 거래소가 어떤 이유로 막히더라도 어떻게든 서브 거래소에서 헷지 주문을 넣어야 한다.