연구 작업이 자원을 많이 요청했어도 실제로 그만큼 사용하지 않을 수 있다. D. E. Shaw 사례는 짧은 실험과 장기 서비스가 같은 계산 기반을 쓰며 작업 식별자별 요청과 소비를 추적한다고 설명한다. 연구 대기와 자원 배분의 원인을 작업 단위에서 찾으려는 관찰 구조다.
동일 하드웨어·자료의 비교에서 ClickHouse는 단일 노드로 초당 약 3.5백만 개의 표본, 비교대상은 약 480,000표본을 처리했다고 보고됐다. 실제 운영은 초당 수십만 레코드를 받아들였고 여러 해에 걸친 압축 지표는 약 68TB였다. 벤치마크와 실제 평균 입력의 분모는 다르다. 비교의 대상은 지표 저장과 처리 능력이지 예측모형의 정확도나 거래수익이 아니다.
이 구조는 느린 연구가 계산 부족, 자료 대기, 자원 과다 요청 중 무엇에서 생기는지 구분하는 데 참고할 수 있다. 다만 보존된 자료의 관계자 확인도 투자성과의 개선을 입증하지는 않는다. 국내에서는 요청과 소비를 연결한 뒤 자원 변경이 연구 반복시간에 미치는 영향을 따로 측정해야 한다.
SCOPE인프라 운영·벤치마크의 역사적 기록이다. 처리 성능을 연구 품질 또는 투자성과의 개선으로 해석하지 않는다.
Evidence & verification ↓Sources & evidence
Original passages appear only when checked against the publication. Earlier briefing records are identified separately.
D. E. Shaw Group — Millions of Compute Jobs를 어떻게 관측하고 Alpha Factory의 병목을 찾는가0 primary · 3 archived +
These 3 records come from the earlier briefing, not a newly verified original publication. They are retained in the original briefing below; no primary-source quotation is shown.
Read the earlier record ↓Show the original briefing text
구분: D. E. Shaw 현직 SRE 인터뷰 기반 기술 case study / ClickHouse
발표일: 2026년 5월 15일
선정 사유: 최신성보다 기술적 가치 때문에 선정. 채용공고가 아니라 실제 production infrastructure 수치가 공개된 드문 자료다.
확인 가능한 사실
D. E. Shaw Group 내부 compute grid에서는 매월 수백만 개의 workload가 실행되며 researcher·engineer·quant 팀이 짧은 experiment부터 장기간 service까지 같은 HPC infrastructure를 이용한다. 회사는 각 task별 requested compute와 실제 consumed compute를 개별 task ID 수준에서 추적한다. ClickHouse × D. E. Shaw 기술 case study 원문
D. E. Shaw SRE Mike Vasiliou가 참여한 benchmark에서는 동일 hardware/data 조건에서 ClickHouse가 단일 노드 기준 약 3.5 million samples/sec, 비교대상은 약 480,000 samples/sec를 처리했다. 실제 production cluster는 평균 약 530k records/sec, peak 100만 건 이상을 ingest하며, 여러 해에 걸친 약 68TB compressed metrics data를 보유한다. 원문 — Scaling the metrics platform
이 자료의 진위는 ClickHouse의 일방적 광고만으로 보는 것보다 신뢰도가 높다. D. E. Shaw 현직자 Prerna Rai와 Jazmin Medina도 해당 사례를 직접 공유하며 자사 compute grid와 운영 의사결정에 ClickHouse를 사용한다고 확인했다.
왜 이게 Quant Alpha와 관련 있나
표면적으로는 observability 이야기다.
하지만 실질적인 경제학은:
수백만 Research Job
→ 어떤 experiment가 GPU/CPU를 얼마나 사용했는지 추적
→ idle / over-request / bottleneck 탐지
→ compute 재배분
→ 더 많은 연구 experiment
→ 알파 발견속도 증가
다.
즉 compute를 많이 보유하는 것만으로 끝나지 않는다.
“누가 얼마를 요청했고 실제로 얼마를 썼고 어느 workload가 병목인가?”
를 알 수 있어야 compute가 alpha factory가 된다.
공개자료 기반 추론
이걸 트레이딩 조직의 P&L로 옮기면:
Compute Utilization → Research Throughput → Valid Hypotheses Tested → Deployable Strategies → P&L
이다.
지난 브리핑의 Optiver가 researcher time을 강조했다면 D. E. Shaw 사례는 그 한 단계 아래인:
Researcher time을 줄이려면 infrastructure bottleneck 자체를 데이터로 측정해야 한다.
는 것을 보여준다.
한국 채권시장 복제 아이디어
대규모 HPC가 없어도 다음부터 기록하면 된다.
각 backtest마다:
researcher
strategy_id
dataset
training time
CPU/GPU hours
memory
data-read time
feature-compute time
OOS result
를 저장한다.
그러면 예를 들어:
모델 training은 5분인데 tick data loading이 42분
이라는 사실이 드러난다.
이 경우 GPU를 더 사는 것이 아니라 데이터 pipeline을 고치는 게 research velocity를 훨씬 많이 높인다.
따라서 채권 AI 연구플랫폼에 추가할 KPI는:
Useful Experiments / Compute Hour
와
Idea → Result Latency
다.
복제 가치: ★★★★★