HFT 시스템 설계, 단일 스레드 법칙을 뒤집은 CME 1년 측정 연구

"스레드를 나누면 반드시 느려진다" — 초고속 매매 세계에서 오랫동안 통용된 이 철칙을, 거래소 데이터 1년치로 정면 반박한 측정 연구가 나왔습니다.

---

들어가며

우리가 인터넷 쇼핑몰에서 "결제하기"를 누르면, 주문은 순식간에 처리됩니다. 그 '순식간'이 사실은 수십 밀리초(1000분의 1초 단위)인데도 우리는 전혀 느끼지 못하죠.

그런데 초고속 매매(HFT, High-Frequency Trading)의 세계에서는 이야기가 완전히 달라집니다. 여기서는 1밀리초는커녕 1마이크로초(100만분의 1초)가 승부를 가릅니다. 시장 데이터가 도착해 우리 시스템이 해석하고 주문을 내기까지 걸리는 시간이 경쟁사보다 1마이크로초만 길어도, 좋은 가격은 이미 남이 가져간 뒤입니다.

이 세계의 시스템 설계자들 사이에는 오래된 격언이 있었습니다. "처리 경로는 단일 스레드(하나의 작업 흐름)로 만들어라. 스레드를 나누면 데이터를 넘기는 데 시간이 걸려 반드시 느려진다." 마치 요리사 한 명이 재료 손질부터 플레이팅까지 전부 하는 게 제일 빠르다는 주장과 같습니다. 중간에 다른 사람에게 재료를 넘기는 순간, 넘기는 동작 자체가 시간을 잡아먹는다는 거죠.

2026년 9월에 나온 이 논문은, 미국 대형 거래소 CME의 선물 시장 데이터 1년치를 패킷 하나까지 전부 추적해서 이 격언을 시험대에 올렸습니다. 결론부터 말하면, "절반은 맞고 절반은 틀렸습니다." 언제는 단일 스레드가 답이고, 언제는 그 법칙이 정확히 뒤집히는지가, 놀라울 만큼 깔끔한 숫자 하나로 결정된다는 겁니다.

---

무엇이 문제였나

HFT 시스템은 대략 이렇게 생겼습니다.

1. 거래소가 보내는 시장 데이터(호가, 체결) 패킷을 수신하고
2. 그 패킷을 해독(디코드)해서
3. 호가창(오더북)을 갱신하고
4. 전략이 의사결정을 내리고
5. 주문을 전송합니다.

이 과정을 하나의 긴 작업 흐름으로 처리하면 스레드 간 데이터 전달이 없어 가장 빠르다는 것이 '단일 스레드 법칙'의 논리였습니다. 실제로 많은 HFT 시스템이 이 원칙대로 만들어졌고, 업계 서적과 블로그들이 이를 공고화했습니다.

하지만 이 법칙에는 결정적인 구멍이 있었습니다. "실제 시장 데이터가 어떻게 도착하는지 아무도 정밀하게 측정하지 않았다"는 점입니다. 평균 초당 패킷 수 같은 굵은 통계만으로, "버스티(bursty)할 것이다", "클러스터로 올 것이다" 같은 막연한 추정만 있었습니다. 설계 법칙이 실측 없이 통념으로만 굳어 있었던 셈입니다.

---

핵심 아이디어: 1년치 패킷을 전부 따라가 봤더니

이 논문은 추측 대신 측정을 택했습니다. CME에서 거래량이 가장 많은 선물 중 하나인 나스닥 100 선물(NQ) 근월물의 시장 데이터를 1년 넘게 받아, 모든 패킷과 매칭엔진(주문을 체결시키는 거래소의 심장부)의 모든 트랜잭션을 두 개의 거래소 타임스탬프로 추적했습니다. 게다가 실제 운영 중인 프로덕션 수신기(다른 종목용)에서도 같은 통계를 재확인해, 측정이 한 종목의 착시가 아님을 확인했습니다.

여기서 세 가지 놀라운 발견이 나옵니다.

발견 1: 시장은 "퐁당퐁당"이 아니라 "우르르" 몰려옵니다

패킷(데이터 묶음)은 무작위로 흩어져 오지 않습니다. 짧은 시간에 우르르 몰려오는 클러스터 형태로 도착합니다. 논문은 이 패턴을 호크스 과정(Hawkes process)이라는 자기여흥(self-exciting) 모델로 수치화했는데, 분지비(branching ratio)가 약 0.8로 '임계'에 가깝습니다. 쉽게 말하면 사건 하나가 평균 0.8개의 후속 사건을 부른다는 뜻인데, 1에 가까울수록 연쇄 반응이 오래 이어집니다. 1이 넘으면 폭발적으로 불어나고, 0에 가까우면 흩어져 오죠.

더 재미있는 건 이 클러스터링의 정체입니다. 거래소가 여러 메시지를 한 패킷에 쑤셔 넣어서 생기는 현상일 수도 있으니까요. 그런데 분석해 보니 거의 모든 트랜잭션(체결 단위)이 패킷 하나에 그대로 담겼고, 클러스터의 진짜 원인은 매칭엔진이 연속 트랜잭션을 마이크로초의 일부 간격으로 연달아 처리하기 때문이었습니다. 시장 참여자들의 주문이 마이크로초 단위로 몰려서 오는 것 — 왜 그런지는 이 논문의 범위 밖입니다 — 이 매칭엔진에 그대로 반영된 겁니다.

발견 2: 거래소의 데이터 발신기는 사실 '줄 서는 창구'다

매칭엔진에서 체결이 일어나면, 그 결과는 거래소의 마켓데이터 퍼블리셔(시장 데이터 발신기)를 거쳐 우리에게 도착합니다. 논문은 이 퍼블리셔가 대기열(큐)처럼 동작함을 발견했습니다.

• 퍼블리셔는 약 7.5마이크로초(µs)마다 최대 한 패킷만 보냅니다. 우체국 창구가 초당 처리 가능한 건 수가 정해져 있는 것과 같습니다.
• 매칭엔진이 우르르 몰려 처리되면(버스트), 퍼블리셔의 지연은 약 10배까지 커집니다.
• 백로그가 쌓이면 퍼블리셔는 패킷을 키워서 보내지 않고, 작은 패킷을 여러 개 연달아 보냅니다.

그래서 매칭엔진의 버스트는 우리에게 "약 7.5µs 간격의 패킷 열차" 형태로 도착합니다. 위 그림에서 다른 거래와 뭉쳐서 전송되는 비율이 4%에서 27%로 뛰는 모습이 바로 이 대기열의 서명입니다.

발견 3: 진짜 문제는 '평균'이 아니라 '열차'다

이것이 시스템 설계에 주는 교훈은 단순합니다. "초당 평균 패킷 수"로 수신기를 설계하면 안 됩니다. 그 수치는 실제 필요한 처리 속도보다 수백 배나 느립니다. 버텨야 할 것은 평균이 아니라, 퍼블리셔 주기(약 7.5µs) 간격으로 연달아 도착하는 패킷 열차입니다. 그리고 그 주기라는 숫자는 한 번 측정하면 끝입니다. 시장이 조용하든 폭주하든 바뀌지 않으니까요.

---

결과: 단일 스레드 법칙은 언제 뒤집히는가

핵심 질문으로 돌아갑니다. 스레드를 나누면 항상 느려질까요? 논문은 수신기의 패킷당 처리 시간과 퍼블리셔 주기(약 7.5µs)의 대소 관계로 답이 갈린다는 사실을 보여줍니다.

케이스 1: 처리가 퍼블리셔 주기보다 빠르면 → 단일 스레드가 정답

패킷 하나를 주기(7.5µs) 안에 끝낼 수 있다면, 아무리 열차가 몰려와도 앞 패킷이 처리되는 동안 뒤 패킷이 기다릴 일이 없습니다. 대기 꼬리가 아예 생기지 않습니다. 이 영역에서는 단일 스레드 법칙이 정확히 맞고, 스레드 분할은 전달 비용만 추가하는 손해입니다.

실제로 논문이 살펴본 프로덕션 수신기는 같은 코드를 소켓 수신 스레드에서 바로 처리하면 호가창 갱신이 중앙값 약 1µs에 끝나, 주기보다 훨씬 빠릅니다. 이 경우 "단일 스레드가 최적"이라는 격언이 그대로 성립하죠.

케이스 2: 처리가 주기보다 느리면 → 법칙이 뒤집힌다

반대로 한 패킷을 처리하는 데 주기보다 오래 걸리면, 열차가 대기열을 만들고 꼬리 지연이 생깁니다. 그리고 이 꼬리는 처리 시간만큼이 아니라 그것보다 훨씬 빠르게 자랍니다. 이때는 오히려 체인을 여러 단계로 자르면(각 단계를 별도 스레드에 배치) 데이터 전달 비용 1홉(hop)을 내고도 꼬리 대부분이 제거됩니다. 왜냐하면 대기열이 쌓이는 곳은 가장 느린 단계 하나뿐이기 때문입니다.

숫자로 정리하면 이렇습니다.

• 꼬리는 대략 7~8µs부터 모습을 드러냅니다.
• 체인 분할이 이득이 되기 시작하는 지점은 8~10µs(꼬리가 전달 비용보다 커지는 순간).
• 16µs부터는 거의 모든 상황에서 분할이 이득입니다.
• 상태를 들고 있는 단계(호가창)는 분할이 답이고, 상태가 없는 단계(디코드)는 코어가 4개 이상이면 분할 대신 코어 풀(여러 코어가 패킷을 통째로 나눠 처리)이 더 낫습니다.

그렇다면 실제 운영 지점은?

흥미롭게도, 논문이 검토한 실제 프로덕션 수신기(패킷을 디코더 스레드에 넘기는 2단계 구조)는 처리 시간이 약 7µs로 주기의 바로 아래에 놓여 있습니다. 이 애매한 지점에서는 스레드 수를 늘리는 게 아니라 메시지 하나당 처리 비용과 처리 시간의 편차를 줄이는 게 관건입니다. 메시지 여러 개가 든 긴 패킷이 오면 그 메시지들을 하나씩 순서대로 해독하는 동안 뒤 패킷이 밀리기 때문입니다.

그리고 한 가지 위안이 되는 사실: 시장이 아무리 몰려와도, 모든 패킷을 퍼블리셔 주기 안에 처리할 수만 있다면 꼬리는 없습니다. 목표가 명확한 셈입니다.

---

한계와 주의점

정직하게 말씀드리면, 이 논문에 몇 가지 제약이 있습니다.

• 측정은 CME 나스닥 선물(NQ) 근월물 1종목에 대한 것입니다. 다른 종목, 다른 채널, 다른 거래소에도 같은 구조가 성립하는지는 각자 측정해야 합니다. 논문 스스로도 "다른 피드에 적용하려면 퍼블리셔 주기와 각 단계의 처리 시간을 직접 재라"고 권고합니다.
• "주문이 왜 마이크로초 이내로 몰려서 오는가" — 클러스터링의 궁극적 원인 — 는 시장 현상으로 보고 이 논문에서 다루지 않았습니다.
• 시뮬레이션의 처리 시간은 상수 또는 메시지 수의 함수로 단순화되어 있어, 실제 시스템의 처리 시간 편차를 완전히 재현하지는 못합니다. 프로덕션 수신기 검증으로 이를 부분적으로 보완했습니다.
• 재현성: 분석 코드(Kaspar-HFT 저장소)는 공개되어 있으나 원본 패킷 캡처는 재배포가 불가능해, 데이터 자체의 재현은 어렵습니다. 논문은 작성에 생성형 AI를 사용했음을 명시적으로 밝히고 있기도 합니다.

---

그래서 투자/실무엔?

일반 투자자에게 이 이야기는 어떻게 다가올까요?

첫째, "더 빠른 컴퓨터"가 항상 정답은 아니라는 교훈은 어떤 규모의 투자에도 통합니다. 이 연구의 진짜 메시지는 속도 경쟁 자체가 아니라 "자신의 병목이 어디에 있는지 실측하라"는 것입니다. 내 전략의 체인에서 가장 느린 단계가 무엇인지, 그 단계가 시장 데이터가 몰려오는 주기보다 느린지 빠른지만 알아도 인프라 투자 방향이 완전히 달라집니다. 무조건 스레드를 늘리거나 서버를 더 사는 대신이죠.

둘째, 평균이 아닌 꼬리를 보라는 원칙입니다. "초당 평균 처리량이 충분한데 가끔 주문이 밀린다"는 경험을 해본 분이 계시다면, 원인은 대개 평균이 아니라 몰려오는 순간(버스트)에 있습니다. 트레이딩 시스템이 아니어도, 주문 관리 시스템이나 데이터 파이프라인 설계에서 같은 원리가 적용됩니다.

셋째, 자기자본으로 초단기 전략을 운용하는 팀 입장에서는 아주 실용적입니다. 피드별 '퍼블리셔 주기'에 해당하는 숫자를 한 번 측정해 두고, 각 처리 단계의 처리 시간 상위 분위수를 그 숫자와 비교하는 것만으로 "어디를 잘라야 하나"라는 문제의 답이 나옵니다. 논문이 제안하는 "느린 단계를 짧게 만드는 경계에서 자르기", "상태 없는 단계는 코어 풀로" 같은 규칙들은 바로 적용 가능한 체크리스트입니다.

결국 이 논문은 "단일 스레드 vs 멀티스레드"라는 진영 논쟁을 "주기보다 빠른가, 느린가"라는 하나의 실측 가능한 질문으로 바꿔 놓았습니다. 좋은 엔지니어링 연구가 늘 그렇듯, 정답을 주는 대신 정답을 구하는 법을 준 셈입니다.

---

더 알아보기

• 원문: Packets, Transactions and Queues: Design Principles for HFT Systems from a Measurement Study of CME Market Data (arXiv:2609.32848)
• OHSE AI Lab 5차원 점수 (참고): 종합 69.1 — 참신성 76 / 실용성 86 / 엄밀성 68 / 재현성 38 / 통찰 81 (A등급, 고빈도 트레이딩 분과)
• 관련 논문 (KB 엔티티 기반 이웃):
  • Exponential Kernels with Latency in Hawkes Processes (arXiv:2101.06348) — 지연을 포함한 호크스 과정 모형
  • C++ Design Patterns for Low-latency Applications (arXiv:2309.04259) — 저지연 시스템의 프로그래밍 설계 패턴
  • Order Book Queue Hawkes-Markovian Modeling (arXiv:2107.09629) — 호가창 대기열의 호크스-마르코프 모형
  • Latency and Liquidity Risk (arXiv:1908.03281) — 지연과 유동성 리스크의 관계

본 글은 arXiv 프리프린트(동료심사 전) 기반의 리뷰이며, 인용 수치는 원문 기준입니다.