런타임

런타임 — 교체가 실제로 옮기는 비용

런타임을 바꾸는 이유는 대개 비슷합니다. 시동이 느리다, 메모리를 많이 먹는다, 오토스케일이 붙을 때마다 처음 몇 초가 아프다. 그래서 JVM을 GraalVM으로 바꿔 보고 동기 워커를 스레드 배치로 바꿔 봅니다.

이 챕터는 그 선택을 “빨라지나"로 묻지 않습니다. 어느 쪽을 고르든 해야 할 일의 총량은 그대로입니다. 클래스를 읽고 링크하는 일, 무엇이 뜨거운지 알아내는 일, 요청을 받아 응답을 만드는 일. 런타임 교체는 그 일을 없애는 게 아니라 다른 시점, 다른 프로세스, 다른 청구서로 옮기는 결정입니다. 옮긴 자리에는 반드시 새 비용이 생깁니다. 그래프에 안 나타나는 종류일 때가 많습니다.

문서 지도

문서	다루는 것
01 JVM vs GraalVM	2025년 9월 Oracle 발표로 바뀐 선택지 지도, JIT과 AOT가 맞바꾸는 것, CE에서 Serial GC가 만드는 상한, 가상 스레드와 리액티브의 실측, 그리고 런타임을 안 바꾸고 시동만 사는 AOT 캐시
02 Python 워커와 스레드	`--workers 16` vs `--workers 2 --threads 32`. 최대 처리량은 왜 같고 무엇이 다른가 — 대기열 구조, GIL 안팎의 경계, DB 커넥션 산수, 조용히 사라지는 요청 타임아웃, Celery와 스레드의 선후관계

공통 축

Native Image는 컴파일을 빌드로 옮기고 되돌림 능력을 내줍니다. 스레드 배치는 동시성을 프로세스 밖으로 옮기고 장애 반경을 키웁니다. 무엇을 내줬는지 모르면 나중에 사고로 알게 됩니다.
벤치마크의 숫자보다 그 숫자가 선 전제를 봅니다. “GraalVM이 C2보다 빠르다"는 PGO와 G1을 켠 유료 배포판을 전제합니다. “스레드 배치가 7.5배 빠르다"는 앞단 프록시가 없다는 전제 위에 있습니다. 전제가 다르면 재현되지 않습니다.
컨테이너 limit은 런타임 선택을 되받아칩니다. JVM은 limit이 없으면 노드 코어를 보고 스레드를 잔뜩 만들고 파이썬 워커는 개수만큼 quota를 빨리 태웁니다. 런타임 설정과 파드 스펙은 따로 정할 수 없습니다. → k8s 02 CPU Throttling
동시성 모델을 바꾸기 전에 앞단부터 확인합니다. 6만 연결 실측에서 Tomcat은 CPU 20%인 채로 무너졌습니다. 연결을 받아들이는 층의 한계였습니다. 실행 모델을 바꿔도 그 벽은 그대로 있습니다.
확인 못 한 건 확인 못 했다고 씁니다. Native Image가 JEP 491을 반영하는지, 워커 16 대 스레드 32를 같은 앱에서 돌린 공개 실측이 있는지 — 두 문서 모두 공백을 채우지 않고 남겨뒀습니다. 직접 재보는 수밖에 없습니다.

마지막 수정 일자 2026년 8월 29일