자바가 금융 트레이딩에 쓰인다고요?
많은 분들이 '지연 시간이 목숨처럼 중요한 시스템이면 당연히 C++이나 Rust 같은 언어를 쓰는 거 아냐?'라고 생각하세요. 그런데 놀랍게도, 마이크로초(100만분의 1초) 단위로 승부가 갈리는 고빈도 매매(HFT, High-Frequency Trading) 세계에서도 자바가 아주 널리 쓰이고 있거든요.
여기서 '지연 시간(latency)'이라는 게 뭐냐면, 요청이 들어와서 응답이 나갈 때까지 걸리는 시간을 말해요. 우리가 흔히 짜는 웹 서비스는 100밀리초(0.1초) 정도만 나와도 '빠르네' 하는데, 트레이딩 시스템은 그것보다 만 배쯤 빠른 세계에서 놀거든요. 그런데 자바에는 '느리다'는 오래된 편견이 붙어 있죠. 이 글의 핵심은, 자바로도 초저지연이 충분히 가능하지만 그냥 평소처럼 코딩하면 절대 안 되고, 상당한 '규율(discipline)'을 지켜야 한다는 거예요.
자바의 발목을 잡는 세 가지 함정
첫 번째는 가비지 컬렉션(GC)이에요. 자바의 최대 장점이자 초저지연에서는 최대 골칫거리인데요. GC가 뭐냐면, 우리가 안 쓰는 메모리를 자동으로 청소해주는 청소부예요. 편하죠. 그런데 이 청소부가 일하는 동안 프로그램 전체가 잠깐 멈춰버리는 '스톱 더 월드(stop-the-world)' 현상이 생겨요. 평소엔 몇 밀리초라 티도 안 나지만, 마이크로초 세계에선 이게 재앙이에요. 그래서 고수들은 아예 쓰레기를 안 만드는 코딩(zero-garbage)을 해요. 객체를 매번 새로 만들지 않고 미리 만들어둔 걸 재사용(객체 풀링)하거나, 아예 힙 바깥 메모리(off-heap)에 데이터를 두어서 GC가 손댈 것조차 없게 만들죠.
두 번째는 JIT 워밍업이에요. 자바는 실행하면서 자주 쓰이는 코드를 그때그때 기계어로 번역(JIT 컴파일)해요. 문제는 프로그램이 막 켜졌을 때는 아직 번역이 안 돼서 느린 통역 모드로 돈다는 거예요. 그래서 트레이딩 회사들은 장이 열리기 전에 실제 거래를 흉내 낸 가짜 데이터를 잔뜩 흘려보내서 JVM을 미리 '데워두는(warm-up)' 작업을 해요. 몸 풀고 경기 뛰는 거랑 똑같죠.
세 번째는 하드웨어를 무시한 코드예요. 이걸 '기계적 공감(mechanical sympathy)'이라고 부르는데, CPU가 메모리를 어떻게 읽는지 이해하고 그에 맞게 짜는 거예요. 예를 들어 CPU는 데이터를 캐시 라인이라는 64바이트 덩어리 단위로 가져오는데, 서로 다른 스레드가 같은 덩어리 안의 다른 값을 건드리면 '거짓 공유(false sharing)'가 생겨서 성능이 뚝 떨어져요. 이런 걸 알고 데이터 배치를 조정하는 거죠.
평균이 아니라 '꼬리'를 봐야 해요
일반 서비스는 평균 응답 속도를 신경 쓰지만, 초저지연에서는 테일 레이턴시(tail latency)가 핵심이에요. 이게 뭐냐면, 1000번 중 999번은 빨랐는데 딱 한 번 크게 튀는 그 최악의 경우(p99, p99.9)를 말해요. 평균은 멀쩡한데 가끔 한 번씩 느려지는 게 트레이딩에선 손실로 직결되거든요. 그래서 '평균 빠름'이 아니라 '항상 예측 가능하게 빠름'이 목표예요.
한국 개발자에게 주는 시사점
사실 우리 대부분은 마이크로초 튜닝까지 갈 일이 없어요. 하지만 여기서 배울 교훈은 분명해요. 불필요한 객체 생성을 줄이고, 메모리 할당 패턴을 의식하고, 평균이 아니라 p99를 보는 습관은 결제·광고 입찰·실시간 스트리밍 같은 일반적인 백엔드에서도 그대로 통하거든요. 요즘 GraalVM 네이티브 이미지나 프로젝트 발할라(Valhalla)의 값 타입처럼 자바 자체가 이런 고민을 언어 차원에서 덜어주는 방향으로 진화하고 있어서, 이런 원리를 알아두면 앞으로 나올 기능들을 훨씬 잘 활용할 수 있어요.
결국 핵심은 이거예요. 언어가 느린 게 아니라, 언어의 특성을 모르고 쓰면 느려진다. 여러분은 지금 짜는 코드에서 '나도 모르게 쓰레기를 얼마나 많이 만들고 있나' 한번 들여다본 적 있으세요?
🔗 출처: Hacker News