트레이딩 시스템의 속도는 모델 inference 한 구간의 benchmark로 끝나지 않는다. Optiver는 ingestion, query planning, execution, serialization, network transfer와 rendering의 지연이 누적된다고 설명한다. 각 service가 정상이어도 연결된 critical path가 길면 trader가 보는 가격과 risk state는 이미 오래될 수 있다.
작은 데이터에서는 전체를 client memory로 가져와 filtering과 aggregation을 해도 빨라 보인다. 사용자와 view가 늘면 같은 interaction이 중복 query와 data movement를 만들고, 늦게 적용된 filter가 upstream work를 줄일 기회를 잃는다. targeted 또는 subscription-based delivery는 필요한 변화만 보내 이 전송량을 제한하는 선택지다.
글의 결론은 특정 database가 아니라 일을 어디서, 언제, 얼마나 수행할지 결정하라는 것이다. 채권 desk에서는 ingest부터 feature, model, risk check와 UI까지 trace ID를 연결하고 장중 꼬리지연, stale quote와 bytes를 함께 봐야 한다. 회사는 내부 latency나 거래성과를 공개하지 않았으므로 production 원칙을 성과사실로 확대하면 안 된다.
SCOPEOptiver의 일반적인 실시간 데이터 아키텍처 설명이다. 내부시스템의 실제 수치, 모델 latency와 P&L 개선을 공개한 성과보고가 아니다.
Evidence & verification ↓Sources & evidence
Original passages appear only when checked against the publication. Earlier briefing records are identified separately.
When Speed and Scale Collide3 primary · 0 archived +
Optiver는 여러 계층에서 latency가 누적된다고 설명한다.
ORIGINAL PASSAGELatency is cumulative.Optiver, When Speed and Scale Collide, Scale section, 2026-02-10, accessed 2026-11-04설계의 핵심은 계산의 위치와 시점을 정하는 일이라고 설명한다.
ORIGINAL PASSAGEwhere work should happen, when it should happenOptiver, When Speed and Scale Collide, conclusion, 2026-02-10, accessed 2026-11-04대규모 전송의 대안으로 targeted 또는 subscription 기반 전달을 언급한다.
ORIGINAL PASSAGEtargeted or subscription-based deliveryOptiver, When Speed and Scale Collide, Scale section, 2026-02-10, accessed 2026-11-04Show the original briefing text
구분: Optiver 공식 기술 글·실시간 거래 데이터 pipeline의 속도와 규모
발표일: 2026년 2월 10일
선정 이유: 최신성보다 연구·트레이더용 데이터 시스템에서 지연이 누적되는 경로를 설명한 production 가치 때문에 선정했다.
핵심 요약
Optiver 원문은 interactive data system의 latency가 ingestion, query planning, execution, serialization, network와 rendering을 거쳐 누적된다고 설명한다. 작은 표본에서 편했던 client-side filtering과 반복계산은 사용자·데이터가 늘면 병목이 되며, targeted 또는 subscription-based delivery가 불필요한 전송을 줄인다. 글은 특정 거래성과보다 work placement와 전체 pipeline 관측의 설계원칙을 공개한다.
실무 시사점
모델 inference만 빠르게 만들어도 trader 화면과 risk gate까지 늦으면 실시간 의사결정은 느리다. feature 생성·query fan-out·serialization·rendering을 한 trace로 연결하고, p50보다 장중 p99와 stale-data 비율을 봐야 한다. 회사는 아키텍처 원칙을 설명했지만 내부 latency 수치나 거래 개선치는 공개하지 않았다.
한국 시장 복제 아이디어
국채선물·국고채·IRS 실시간 dashboard에서 ingest부터 feature, model, risk check와 화면까지 trace ID를 이어 붙인다. client filtering과 server precompute, polling과 subscription을 동일 장중 replay에서 비교해 p50·p99 latency, network bytes, stale quote 비율, CPU cost와 trader refresh 실패율을 측정한다.