Jane Street의 LLM 시대 아키텍처 설계

YouTube 영상 5편 시청 기반 정리 · 머스트자산운용 내부 인사이트 노트 · 2026.05

한 줄 요약

Jane Street는 단일 거대 모델이 아닌 "수많은 특화 모델의 병렬 실험 인프라"를 핵심 자산으로 보고, 컴퓨트를 옵셔널리티 관점에서 자본 배분한다. 트레이딩 회사로서는 이례적으로 자체 텍사스 데이터센터를 운영하며, 수만 → 수십만 GPU 규모로 확장 중이다.

0. 분석 대상 영상

1. 정량 데이터 — Jane Street의 컴퓨트 스케일

지표	수치	출처 / 비고
단일 텍사스 사이트 GPU	4,032 GPUs / 56 racks	영상 설명 + 본문 (GB300 NVL72)
전사 GPU 보유 규모	tens of thousands	Ron Minsky 발언
가까운 미래 목표	hundreds of thousands	"in not too long"
CoreWeave 계약	$6 billion	Dwarkesh 언급, Ron 시인
랙당 전력 (현세대)	140 kW peak	GB300 캐비닛 (Pontecorvo)
차세대 랙 밀도 목표	~1 MW / rack	영상 17:31 부근
액체냉각 비율	85~90%	나머지는 공랭
단일 사이트 IT 부하 추정	~7.84 MW (140kW × 56)	시설 합산 약 10MW대
수십만 GPU 시 전력	250~600 MW급 (1GW 근접)	외부 추정 (영상 미언급)

2. 컴퓨트 자본배분 — 옵셔널리티 전략

"You could disconnect the powering the data center from the chips… commit to the data center and the power now but delay the decision on the chips which are very expensive. Just be slightly long power and data center… it's much easier for us to offload power and data center capacity than the chips themselves." — Ron Minsky

자산별 페이오프 프로파일

자산	리드타임	감가속도	2차 시장	전략
전력 / 부지	매우 김 (1년+)	느림	활발	Slightly Long
제너레이터 / 트랜스포머	6~18개월	중간	중간	핵심만 유지
표준 인프라 부품	중간	느림	활발	사전 비축
GPU / ASIC	짧음~중간	매우 빠름	얇음	Option (지연)

이 전략은 본질적으로 금융 옵션의 비대칭 페이오프를 자본지출에 그대로 옮긴 것. 일반 하이퍼스케일러는 남는 GPU를 광고 서빙으로 흡수 가능하지만, Jane Street는 그런 보조 워크로드가 없어 옵셔널리티의 가치가 더 크다.

3. ML 모델 아키텍처 — 왜 단일 거대 모델이 아닌가

Ron Minsky가 꼽은 frontier 랩과의 3가지 차이:

데이터 다양성: 다양한 데이터 소스마다 최적 모델이 다름
데이터 레이트 차이: 처리 속도 요구로 모델 설계 분기
Bytes-to-FLOP ratio: "way more data… but byte-for-byte less informative because financial data is very noisy"

머스트가 주목할 핵심

금융 데이터의 정보 밀도 문제는 텍스트 LLM을 그대로 트레이딩에 갖다 쓸 수 없는 근본 이유. Jane Street조차 LLM + 트레이딩 특화 커스텀 아키텍처 병렬 학습의 하이브리드 전략을 쓴다.

4. 물리적 인프라 설계 — 학습된 교훈들

4.1 Retrofit 사례

텍사스 사이트는 원래 200kW 랙 미지원이던 시설을 액체냉각으로 retrofit. 라이즈드 플로어 대신 오버헤드 파이핑이 신규 트렌드(배치 속도 우선).

4.2 액체냉각의 새로운 리스크

박테리아 관리: 증류수 + 프로필렌글리콜 25% 혼합
누수 감지: 청색 와이어로 바닥 누수 감지
버퍼 탱크 = 열 배터리: 정전 시 칠러 재시작까지 냉각 유지

4.3 비즈니스 결정 vs 엔지니어링 결정 — 결정적 인용

"My entire data center is backed up by generators. But generators are some of the longest lead time items… maybe we take those away and only put it for a core part that needs that resiliency. That gets our GPUs on six months faster. Let's do it. Maybe it's not the best engineering decision, but it's truly the best business decision." — Daniel Pontecorvo

"전체 백업 = 좋은 엔지니어링"이라는 도그마를 깨고, 6개월 빠른 가동의 NPV가 백업 손실 리스크를 압도한다는 명료한 의사결정.

4.4 Power Oversubscription

전력은 fungible하지 않아 (브레이커 트립 = 학습 중단), "Edge 가까이 달리되 안전망" 운용. 자체 모니터링 SW가 토폴로지 인식으로 워크로드 자동 셧다운까지 한다.

5. 거래소 아키텍처 — 시스템 사고법

패시브 매칭 엔진: 동일 코드 병렬 실행 → UDP 순서 무관 결정론적 복구
Idempotent 메시지: Publisher ID로 식별, 시퀀스 충돌 시 cancel reject 재발행
OCaml 정적 타입: 리팩토링 시 안전망 → 빠른 변경에도 신뢰성

6. "AI가 사람을 대체하지 않는다"

"Trading is AGI-complete… I have never been more desperate to hire more humans… This is a good argument for buying more compute, not for hiring fewer people." — Ron Minsky

리서처 가치가 높다는 사실 자체가 컴퓨트를 더 사야 한다는 논거. 자동화될수록 비자동화 영역의 경쟁우위가 결정되므로 인간은 가속화됨.

7. 머스트자산운용 7가지 실행 인사이트

① 데이터 인프라 우선순위

Jane Street조차 데이터 로딩 성능에 가장 큰 엔지니어링 자원을 투입하고 자체 object store까지 구축. 머스트 규모에서는 자체 구축은 과하지만, 벤더 종속을 피하고 데이터 파이프라인을 자산화하는 관점이 필요.

② "단일 모델 환상" 경계

금융 데이터는 노이즈가 많아 byte당 정보가 적다. 범용 LLM을 시장 예측에 그대로 쓰는 접근은 한계. 커스텀 아키텍처 + 도메인 특화 모델 + LLM 하이브리드가 정석. 머스트는 자체 학습 인프라가 없으므로 오픈소스 백본 + 파인튜닝/RAG 조합부터.

③ 컴퓨트 자본배분의 옵셔널리티

머스트 맥락 번역: "클라우드 약정 vs 온디맨드"의 비대칭성을 의식적으로 관리. 장기·범용 부분(스토리지·기본 컴퓨트)은 reserved instance로 long, 실험적 GPU 워크로드는 spot/on-demand로 옵션 유지.

④ "엔지니어링 최적 ≠ 비즈니스 최적"

Daniel의 제너레이터 사례처럼 완벽주의가 비즈니스 가속을 막는 경우를 식별. 머스트 사례: 백테스팅 완벽 검증 vs 빠른 실전, 모든 자산 클래스 동시 vs 핵심 클래스 집중.

⑤ 모니터링을 1급 시스템으로

Jane Street의 "one pane of glass" + 자동 반응(워크로드 셧다운)까지. 머스트의 리스크/포지션/시스템 모니터링을 통합 대시보드 + 자동화 액션으로 격상.

⑥ 정적 타입 / 함수형 패러다임 재평가

OCaml은 부담스럽지만, 핵심 트레이딩 로직에서 정적 타입 + 패턴 매칭의 안전성은 분명한 가치. Python 스택이라면 TypedDict, Pydantic, mypy strict 도입, 혹은 Rust로 코어 일부 이전을 검토.

⑦ "AI = 인력 감축"이 아니라 "AI = 인력 레버리지"

Ron의 명제: 리서치 가치가 높을수록 컴퓨트와 인력을 동시에 늘려야 한다. AI 도구 도입을 비용절감이 아닌 "같은 인력으로 더 많은 가설을 더 빠르게 검증" 프레임으로 정당화해야 ROI가 명확.