알고리즘 트레이딩 시스템의 데이터 통신: 기술 개요

알고리즘 트레이딩에서 수익과 손실의 차이는 마이크로초 단위로 측정될 수 있습니다. 데이터 전송 아키텍처는 트레이딩 시스템의 효율성을 결정하는 핵심 요소 중 하나입니다. 이 기사에서는 거래소와의 상호작용부터 내부 서비스 간 통신, 저장소, 데이터 배포에 이르기까지 모든 수준의 통신 기술을 분석합니다.

이 기사는 "외부"(거래소 프로토콜)에서 "내부"(IPC, 메시지 브로커, 저장소)로 수준별로 구성되어 있으며, 알고리즘 트레이딩 플랫폼의 실제 아키텍처를 반영합니다.

1. 거래소와의 통신: REST, WebSocket, FIX

1.1 REST API

REST는 거래소 API와 상호작용하는 가장 쉽고 일반적인 방법입니다. 각 요청은 별도의 HTTP 연결입니다: TCP 핸드셰이크 → TLS 핸드셰이크 → 요청 전송 → 응답 수신 → 연결 종료.

트레이딩에서 REST의 문제점:

각 요청에는 연결 설정 오버헤드가 수반됩니다. HTTP keep-alive를 사용하더라도 "요청-응답" 모델에서는 요청을 보내는 것보다 빠르게 데이터를 수신할 수 없습니다. 이로 인해 폴링이 발생합니다 — "새로운 데이터가 있습니까?"라는 끝없는 쿼리 주기로 거래소 서버 부하의 최대 80%를 생성합니다(암호화폐 거래소 개발자에 따르면). 거래소는 속도 제한(일반적으로 분당 10~1200건의 요청)을 도입하여 REST를 고빈도 전략에 부적합하게 만듭니다.

REST가 적절한 경우: 과거 데이터 가져오기(캔들, OHLCV), 계정 관리(잔고, 포지션), 비실시간 운영(DCA 봇, 시간별 리밸런싱).

1.2 WebSocket

WebSocket은 데이터가 양방향으로 흐르는 하나의 영구 TCP 연결을 설정합니다. Upgrade 헤더가 있는 일반 HTTP 요청으로 시작한 다음 양방향 프레이밍 프로토콜(페이로드는 텍스트 JSON 또는 바이너리)로 전환됩니다.

트레이딩에서의 장점:

주요 장점은 요청당 오버헤드가 없다는 것입니다. 한번 설정되면 데이터가 서버에서 즉시 푸시됩니다. WebSocket을 통한 시장 데이터 전달 레이턴시는 거래소 게이트웨이에서 클라이언트까지 일반적으로 50ms 미만입니다. 단일 연결로 50개 이상의 심볼을 동시에 구독할 수 있습니다.

중요한 포인트: WebSocket을 통한 주문. 많은 트레이더가 일부 거래소(Binance, HitBTC, Deribit, Bybit 등)가 WebSocket을 통해 주문을 전송할 수 있다는 것을 모릅니다 — 데이터 수신뿐만 아니라. 이것이 REST보다 근본적으로 빠른 이유:

• 각 주문에 TCP/TLS 핸드셰이크 불필요(연결이 이미 "웜")
• HTTP 오버헤드 없음(헤더, 쿠키 등)
• 비동기 모델: 주문을 보내고 동일한 WebSocket을 통해 스레드를 차단하지 않고 확인을 수신.

Deribit에 따르면 WebSocket과 FIX는 종종 동일한 실행 속도를 가집니다. REST는 연결 수준 전처리로 인해 약간 느립니다. WebSocket 주문은 FIX 주문과 마찬가지로 매칭 엔진 큐에 들어갑니다.

컨텍스트 혼합 문제. REST를 통해 주문을 보내고 WebSocket을 통해 체결 알림을 받으면 경쟁 조건이 발생합니다: WebSocket 알림이 REST 요청 완료 전에 도착할 수 있습니다. 이는 상태 불일치로 이어집니다. 해결책은 동일한 WebSocket을 통해 주문을 보내고 완전히 비동기 모델로 전환하는 것입니다.

1.3 FIX 프로토콜 (Financial Information eXchange)

FIX는 1992년부터 존재하는 전자 거래의 산업 표준입니다(Fidelity Investments와 Salomon Brothers가 개발). 트레이딩을 위해 특별히 설계된 바이너리 오버 TCP 프로토콜입니다.

FIX 아키텍처:

• 세션 레이어 — 연결 관리, 하트비트, 시퀀스 번호, 갭 리커버리. 전달과 메시지 순서를 보장.
• 애플리케이션 레이어 — 비즈니스 로직: 주문 유형, 체결 보고서, 시장 데이터 요청.

FIX 메시지는 SOH 문자로 구분된 "태그=값" 쌍으로 구성됩니다. 예를 들어, AAPL 100주를 $150에 매수하는 주문은 다음과 같습니다:

8=FIX.4.2|35=D|49=BUYER|56=SELLER|11=ORD1001|38=100|40=2|54=1|55=AAPL|44=150.00

FIX가 WebSocket보다 빠른 이유: FIX는 HTTP 레이어가 없는 네이티브 TCP 프로토콜입니다. AWS는 암호화폐 거래소의 tick-to-trade 최적화 가이드에서 프로토콜로 인한 레이턴시를 최소화하기 위해 REST와 WebSocket보다 FIX를 명시적으로 권장합니다. FIX는 마이크로초 수준에서 작동하며, WebSocket은 일반적으로 밀리초입니다.

FIX가 지배적인 분야: 거래소 매칭 엔진에 대한 DMA(Direct Market Access), 기관 투자자 공간에서의 알고리즘 및 HFT 트레이딩, 유동성 집계(프라임 브로커가 FIX를 통해 수십 개의 은행에 연결).

FIX의 한계: 통합의 복잡성, 구식 메시지 형식(텍스트 태그-값은 바이너리 형식보다 효율성이 낮음), 높은 진입 장벽. 암호화폐 업계에서 FIX를 지원하는 거래소는 제한적입니다.

1.4 SBE (Simple Binary Encoding) — FIX의 진화

SBE는 FIX Trading Community 내 High Performance Working Group이 만든 바이너리 직렬화 형식입니다. 초저레이턴시 트레이딩을 위해 텍스트 FIX 형식을 컴팩트한 바이너리 표현으로 대체하는 것이 미션입니다.

SBE의 핵심 원칙:

• Zero-copy flyweight 패턴 — 인코더와 디코더가 버퍼 위의 "템플릿"으로 작동. 값이 중간 복사 없이 직접 기록됩니다(여러 번 복사가 필요한 Protobuf와 다름).
• 와이어 형식 = 메모리 형식 — 와이어의 데이터가 메모리와 동일한 형태로, 변환 오버헤드를 최소화.
• 고정 필드 먼저, 가변 필드 나중에 — Protocol Buffers 대비 한 자릿수 이상의 성능을 제공하는 설계 제약.

SBE + Aeron은 고성능 트레이딩 시스템의 표준 조합입니다. Aeron은 Real Logic의 오픈소스 메시징 시스템입니다(전 LMAX Exchange CTO인 Martin Thompson과 전 29West/Ultra Messaging CTO인 Todd Montgomery가 개발). 이것은 사실상 UDP와 공유 메모리 위에서 한 자릿수 마이크로초 레이턴시로 작동하는 금융 시스템을 위한 특수 전송 계층입니다. SBE가 직렬화를 처리하고, Aeron이 마이크로초 지연으로 전달을 관리합니다. Aeron에 대한 자세한 내용은 섹션 3.1에서 설명합니다.

1.5 거래소 프로토콜 비교표

2. 내부 마이크로서비스 통신

거래소에서 시스템으로 데이터가 들어오면 내부 처리가 시작됩니다: 파싱 → 전략 → 결정 → 주문 전송. 각 단계에서 서비스 간 통신이 발생합니다.

2.1 gRPC 양방향 스트리밍 (TCP)

gRPC는 직렬화에 Protocol Buffers를 사용하는 HTTP/2 기반의 Google 프레임워크입니다. 알고리즘 트레이딩에서는 양방향 스트리밍이 특히 중요합니다 — 클라이언트와 서버가 하나의 연결을 통해 동시에 메시지 스트림을 보내는 방식입니다.

gRPC가 트레이딩 시스템에 적합한 이유:

• Protobuf는 JSON보다 3~10배 컴팩트
• HTTP/2 멀티플렉싱 — 하나의 TCP 연결로 여러 스트림
• .proto 스키마를 통한 엄격한 타이핑으로 컴파일 시 오류 감지
• Python, Rust, Go, C++, Java 등의 코드 생성
• 양방향 스트리밍으로 하나의 채널에서 "시장 데이터 다운, 주문 업" 패턴 구현.

SmartDev에 따르면 AI 기반 HFT를 배포하는 금융 기관의 70%가 마이크로초 응답 시간을 위해 gRPC 또는 로우 TCP를 사용합니다.

아키텍처 예시: Market Data Collector(Rust) → gRPC 스트림 → Strategy Engine(Python/Rust) → gRPC 호출 → Order Router(Rust) → WebSocket/FIX → 거래소.

2.2 Unix Domain Socket(UDS)을 통한 gRPC

서비스가 동일한 머신에서 실행되는 경우(코로케이션의 전형적인 경우) TCP는 불필요한 오버헤드입니다. Unix Domain Socket(UDS)은 전체 네트워크 스택을 우회합니다: TCP 핸드셰이크, 라우팅, 체크섬 없음.

벤치마크가 보여주는 상당한 차이:

• UDS를 통한 gRPC: ~102 μs/요청 (100K 요청)
• TCP를 통한 gRPC: ~127 μs/요청 (100K 요청)
• UDS 이득: 작은 메시지에서 ~20%, 큰 메시지(100KB+)에서 최대 50%.

F. Werner(MPI Heidelberg)에 따르면 gRPC UDS와 로우 블로킹 I/O UDS를 비교하면 gRPC는 약 10배의 오버헤드를 추가합니다 — 중앙값 ~130 μs vs 로우 UDS의 ~13 μs. 이것은 추상화의 비용(HTTP/2 프레이밍, protobuf 직렬화)입니다.

gRPC+UDS를 사용할 때: 개발자 편의성(스키마, 코드 생성)이 절대적인 최소 레이턴시보다 중요한 경우의 단일 서버 내 프로세스 간 통신. UDS는 Unix 파일 권한을 통한 보안 이점도 제공합니다.

사용하지 말아야 할 때: 10 μs 미만의 레이턴시가 필요한 경우 공유 메모리 또는 gRPC 없는 로우 UDS가 더 좋습니다. 참고: 로우 UDS 중앙값 ~13 μs, gRPC UDS 중앙값 130 μs. 공유 메모리(Aeron IPC)는 1 μs 미만, LMAX Disruptor 링 버퍼는 약 50100 ns. 따라서 gRPC+UDS는 로우 UDS보다 10배 느리고 공유 메모리보다 1001000배 느립니다. 하지만 레이턴시가 낮아질수록 코드 복잡성은 증가합니다.

직접 재현해 보세요: 이 섹션의 모든 IPC 레이턴시 수치는 오픈소스 컴패니언 벤치마크 **suenot/trading-ipc-bench**로 재현할 수 있습니다 — TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, 공유 메모리, 명명된 파이프의 왕복을 Python으로 구현하여 자신의 하드웨어에서 p50/p95/p99/p99.9 레이턴시와 처리량을 측정합니다.

gRPC 없는 로우 UDS — gRPC 오버헤드가 과도한 경우 gRPC를 제거하고 소켓만 유지합니다. 성능 내림차순 옵션:

• AF_UNIX 소켓 + 커스텀 직렬화(SBE, FlatBuffers, MessagePack) — 중앙값 ~13 μs, 최대 제어, 최대 복잡성
• ZeroMQ IPC(ipc://) — 50100 μs, 보일러플레이트 없는 기성 패턴(PUB/SUB, REQ/REP), 내부적으로 UDS 사용
• nanomsg/NNG IPC — ZeroMQ와 유사, 작은 메시지(<64 KB)에서 약간 더 나은 레이턴시
• Cap'n Proto RPC over UDS — 제로 카피 직렬화 + RPC 추상화, gRPC보다 빠름, 스키마 있음

2.3 공유 메모리 IPC

동일 호스트에서의 초저레이턴시를 위해 공유 메모리를 사용합니다. 두 프로세스가 동일한 RAM 세그먼트를 매핑하고, 데이터는 시스템 콜 없이(초기 설정 제외) 전달됩니다.

LMAX Disruptor 패턴(공유 메모리의 링 버퍼)은 단일 스레드에서 초당 약 600만 이벤트를 처리합니다. 이 접근 방식은 LMAX Exchange와 많은 HFT 시스템의 핵심입니다.

구현: Aeron IPC(Java/C++), Chronicle Queue(Java), 커스텀 mmap 기반 솔루션(Rust/C++). IronSBE(Rust SBE 구현)는 SPSC 채널 수준에서 ~20 ns 레이턴시로 공유 메모리 IPC를 지원합니다.

3. 전송 시스템: 메시지 브로커 및 라이브러리

3.1 Aeron — 골드 스탠다드

Aeron은 Real Logic이 개발한 오픈소스 고성능 메시지 전송 시스템입니다. 개발자는 Martin Thompson(전 LMAX CTO)과 Todd Montgomery(전 29West CTO)입니다. 2014년 미국 대형 거래소를 위해 시작되었으며 현재 70명 이상의 기여자와 5000명 이상의 GitHub 구독자가 있습니다.

실제로: Aeron은 브로커(Kafka와 같은)도 소켓 라이브러리(ZeroMQ와 같은)도 아닙니다. 예측 가능한 저레이턴시를 위해 설계된 전송 계층입니다. UDP(네트워크)와 공유 메모리(IPC) 위에서 작동하며, 원시 UDP에 없는 안정적인 전달, 순서 보장, 흐름 제어를 제공합니다. Aeron을 "UDP 레이턴시의 TCP"로 생각하세요.

Aeron 특성:

• 레이턴시: 클라우드에서 100 μs 미만, 베어 메탈에서 18 μs 미만.
• 처리량: 마이크로초 레이턴시에서 100만 메시지/초 이상.
• 피크 2000만 메시지/초 이상.
• 브로커리스 — 단일 장애점 없음.
• 유니캐스트, 멀티캐스트, IPC 지원.
• 내장 흐름 제어 및 손실 감지.

Aeron Cluster — 최소한의 추가 레이턴시로 일관된 트레이딩 로직을 위한 내결함성 상태 머신 복제(Raft 합의).

Aeron Archive — 풀 스트림 속도의 메시지 영속화 및 리플레이 기능.

Aeron Sequencer — 에코시스템의 최신 컴포넌트로, 대규모 조직 전체에서 여러 프로젝트를 조정하도록 설계. Aeron Transport와 Aeron Cluster 위에 구축. 주요 특성:

• 분산 로그 — 내결함성을 위해 여러 머신에 복제되는 긴 메시지 시퀀스
• 다중 리더 — 여러 애플리케이션이 다른 목적으로 동일한 로그에서 동시에 읽기
• 분리된 팀 — 팀이 단일 조정 시스템 내에서 독립성을 유지
• 대상 사용 사례: 시장 데이터 처리, 브로커 플랫폼, 거래소 엔진

Kafka와의 비교: 둘 다 분산 로그를 사용하지만, Aeron은 마이크로초 레이턴시용이고 Kafka는 밀리초 내구성과 처리량용입니다. Aeron은 실시간 로직용, Kafka는 데이터 파이프라인과 분석용입니다.

3.2 Apache Kafka

Apache Kafka는 대규모 이벤트 스트리밍의 사실상 표준입니다. 거래 핫 패스용이 아니지만(밀리초 지연) 다음에는 필수적입니다:

• 시장 데이터 집계: 100개 이상의 거래소에서 스트림을 하나의 파이프라인으로 수집.
• 이벤트 소싱: 모든 시스템 행동을 이벤트 토픽으로 기록.
• CDC (Change Data Capture): 거래 DB 변경 사항을 분석으로 스트리밍.
• QuestDB 통합: Kafka → QuestDB로 실시간 틱 분석.

엔드투엔드 레이턴시는 2~15 ms. HFT에는 허용 불가하지만 1초 이상의 호라이즌을 가진 전략에는 충분합니다.

3.3 Redis Pub/Sub 및 스트림

Redis는 인메모리 스토어이자 경량 브로커로도 작동합니다.

Redis Pub/Sub — 파이어 앤 포겟; 서브밀리초 레이턴시. 실시간 알림에 이상적: 가격 업데이트, 전략 시그널, 알림.

Redis Streams — 영속화와 컨슈머 그룹(미니 Kafka)을 추가. 히스토리 읽기와 ACK 지원.

Redis는 작은 메시지에 대해 Kafka보다 빠르지만(서브밀리초), Kafka의 헤비듀티 복제와 내구성이 부족합니다.

3.4 NATS

NATS는 Go로 작성된 초경량 시스템입니다. 서브밀리초 레이턴시, 내장 pub/sub, 요청/응답. NATS JetStream은 영속화와 exactly-once 전달을 추가합니다.

3.5 ZeroMQ 및 nanomsg

피어투피어 통신을 위한 소켓 추상화를 제공하는 브로커리스 라이브러리. ZeroMQ는 500만 메시지/초 이상을 처리하며 2007년부터 실전 검증됨. nanomsg(및 NNG)는 "후계자"로 작은 메시지(<64KB)에서 더 나은 레이턴시를 제공합니다.

4. 클라이언트용 실시간 PUB/SUB: Centrifugo

Centrifugo는 Go로 작성된 셀프호스팅 PUB/SUB 서버로, WebSocket, SSE, 또는 gRPC를 통해 수천~수백만 클라이언트에 브로드캐스트하도록 최적화되어 있습니다.

Centrifugo가 알고 트레이딩에 적합한 이유:

• 단일 서버에서 100만 WebSocket 연결과 분당 3000만 메시지 처리.
• 60Hz 스트리밍 지원.
• 트래픽 최소화를 위한 델타 압축(Fossil 알고리즘).
• 웹 대시보드나 모바일 앱으로의 "라스트 마일"에 완벽.

5. 실시간 접근 데이터 스토어

5.1 QuestDB — 트레이딩을 위한 시계열 데이터베이스

QuestDB는 Java(제로 GC), C++, Rust로 작성된 오픈소스 시계열 데이터베이스입니다.

• 쿼리: SIMD를 통한 서브밀리초 벡터화 실행.
• SAMPLE BY/ASOF JOIN: 트레이더 친화적 네이티브 SQL 확장.
• WAL: 초저레이턴시 추가 쓰기.
• B3(브라질 증권거래소)가 사용.

5.2 데이터 레이어로서의 Redis

일반적으로 중간 레이어:

• 가격에 대한 O(1) 접근을 위한 핫 캐시.
• 오더북을 위한 정렬된 세트.
• 원자적 연산을 위한 Lua 스크립트.

5.3 전문 솔루션: RayforceDB, AXL DB

제로 의존성과 SIMD 가속을 갖춘 미니멀리스트 C 기반 벡터 데이터베이스(바이너리 <1MB). HFT를 위한 결정론적 레이턴시에 집중.

6. 직렬화: Protobuf vs SBE vs JSON

7. 레퍼런스 아키텍처

7.1 암호화폐 아비트라지 (중빈도)

거래소 → Collector(Rust) → Redis(핫) → Strategy(Python) → gRPC → Router(Rust) → 거래소.

7.2 HFT 마켓 메이킹 (코로케이션)

거래소 피드 → Kernel Bypass NIC → Aeron IPC → Strategy(C++) → SBE → Aeron → 거래소.

8. 실용적 조언

• <10 μs (HFT): FPGA, 공유 메모리, SBE, Aeron IPC.
• 10–100 μs: Aeron(UDP), gRPC+UDS, ZeroMQ.
• 100 μs – 1 ms: gRPC(TCP), WebSocket, Protobuf.
• 1–10 ms (중빈도): WebSocket, Kafka, Redis.
• >10 ms (저빈도 / 스윙): REST API로 충분. DCA, 리밸런싱, 포트폴리오 관리.

병목이 아닌 것을 최적화하지 마세요. 전략 결정에 50 ms가 걸린다면, Aeron의 100 μs 절약은 중요하지 않습니다. 하이브리드 아키텍처는 정상입니다: 설정에 REST, 핵심에 gRPC, 전달에 WS를 사용하세요.

벤치마크 리포지토리

이 기사에서 인용된 레이턴시 수치는 **suenot/trading-ipc-bench**로 재현할 수 있습니다 — 여기서 논의된 모든 주요 IPC 전송을 다루는 오픈소스 Python 벤치마크 스위트: TCP, UDS, 명명된 파이프, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, 공유 메모리.

git clone https://github.com/suenot/trading-ipc-bench
cd trading-ipc-bench
pip install -r requirements.txt
python run_all.py   # runs all 8 transports, saves results to results/
python report.py    # prints a summary table + ASCII latency chart

자신의 하드웨어에서 실행하세요 — CPU, OS, 커널 버전, 튜닝에 따라 결과가 이 기사의 수치와 다를 것입니다. 그것이 핵심입니다.

결론

"완벽한" 통신 기술은 없습니다. 각 수준에는 고유한 요구사항이 있습니다: 외부(호환성), 내부(레이턴시), 파이프라인(신뢰성), 클라이언트(유연성). 아키텍처란 특정 작업에 적합한 도구를 선택하는 것입니다.