Optiver의 실행 지연과 연구 반복 속도

구분: Optiver 공식 기술 블로그 · 현직 Engineering Team Lead 직접 작성
발표일: 2026년 7월 20일
채용공고 아님

확인 가능한 사실

Optiver Shanghai의 engineering team lead Daniel B.는 지난 약 10년간 세대별 trading stack이 어떻게 바뀌었는지를 공식 기술글에서 직접 설명한다. 핵심 갈등은 lowest latency와 fastest research iteration이 서로 반대 방향의 engineering requirement를 갖는다는 것이다. Optiver 공식 기술글

그의 설명에 따르면 trading이 더 systematic하고 model-driven해지면서 모델이 점점 무거워지고, 기존 시스템의 bottleneck을 반복해서 넘어가야 했다. 그래서 단순히 C++ 코드를 더 최적화하는 문제가 아니라 연구자가 새 모델을 빠르게 실험하면서도 production에서는 latency를 유지할 수 있는 architecture를 계속 재설계해 왔다.

Optiver가 현재 공식적으로 설명하는 전체 구조도 이와 일치한다. 회사는 deep learning, LLM, statistical modeling, reinforcement learning을 연구에 사용하고, rapid experimentation infrastructure가 아이디어를 production으로 빠르게 넘기는 역할을 한다고 밝힌다. 또한 매일 1,000만 건 이상의 trade가 실행되므로 pricing model이나 execution path의 작은 개선도 수백만 번의 live decision에 반복 적용된다. Optiver 공식 Research/Technology 설명

공개자료 기반 추론

여기서 Optiver가 해결하려는 engineering objective는:

Latency 최소화

하나가 아니다.

오히려:

Trading P&L ∝ Model Quality × Research Iteration Speed × Production Latency × Reliability

에 가깝다.

초저지연만 극단적으로 추구하면:

• feature 추가가 어렵고
• 모델 변경이 느리고
• 실험비용이 올라간다.

반대로 Python research stack을 그대로 production에 넣으면:

• latency
• jitter
• reliability

문제가 생긴다.

따라서 좋은 시스템은 research flexibility와 execution performance 사이에 명확한 interface를 만든다.

한국 채권시장 복제 아이디어

우리도 연구코드와 실행코드를 억지로 하나로 만들기보다 두 계층으로 나누는 것이 좋다.

Research Layer

• Python
• pandas/polars
• PyTorch
• 빠른 feature/model iteration

Production Decision Layer

• 고정된 feature contract
• model artifact
• deterministic risk checks
• low-latency execution

그리고 핵심은:

feature spec model input schema model version risk parameters

를 자동으로 production에 넘기는 것이다.

그렇게 하면 연구자는 Python에서 하루 20개 모델을 실험하고, 통과한 모델만 execution engine으로 안전하게 넘어갈 수 있다.

복제 가치: ★★★★★