Valhalla JDK 28, 자바 성능 모델의 재작성

10년 넘은 실험이 JDK 28 논의로 들어왔다

JVM Weekly의 Project Valhalla 설명 글은 오랜 기간 진행된 OpenJDK 프로젝트가 JDK 28과 함께 현실권에 들어오는 흐름을 정리했다. Valhalla의 핵심은 자바에 값 기반 데이터 모델을 더해 객체 지향의 표현력과 원시 타입의 성능 이점을 더 가깝게 만드는 것이다. 공식 출발점은 OpenJDK Project Valhalla 페이지와 JEP 401: Value Classes and Objects에서 확인할 수 있다.

자바 개발자에게 이것은 단순히 새 키워드가 추가되는 뉴스가 아니다. JVM에서 객체는 참조, 헤더, 정렬, 포인터 추적 비용을 가진다. 작은 데이터 구조가 수억 개 쌓이는 서버에서는 이 비용이 곧 메모리 사용량, GC 압박, CPU 캐시 미스, 클라우드 비용으로 이어진다. Valhalla는 자바가 오랫동안 감수해 온 이 비용 구조를 낮추려는 장기 프로젝트다.

값 클래스가 겨냥하는 병목

오늘날 AI 서비스의 백엔드는 파이썬만으로 굴러가지 않는다. 피처 저장소, 검색, 결제, 권한, 로깅, 메시징, 데이터 파이프라인에는 자바와 JVM 생태계가 깊게 깔려 있다. 대규모 트래픽에서 중요한 것은 모델 추론 비용만이 아니다. 요청 하나가 지나가는 백엔드 객체 수, 직렬화 비용, 캐시 효율, GC 멈춤도 사용자 경험과 인프라 비용을 좌우한다.

Valhalla가 제안하는 값 클래스는 동일성보다 값 자체가 중요한 타입을 더 조밀하게 표현할 수 있게 한다. 좌표, 복소수, 금액, 토큰 범위, 임베딩 메타데이터, 벡터 검색 결과 같은 작은 구조체가 대표적이다. Valhalla early-access 빌드가 따로 제공되는 이유도 이런 변화가 언어, 컴파일러, 런타임, 라이브러리 전체에 영향을 주기 때문이다.

Apple Core AI, 앱 안 모델 실행의 새 기준이 온디바이스 런타임의 의미를 다뤘다면, Valhalla는 서버 런타임의 메모리 경제성을 겨냥한다. 둘 다 AI 시대 인프라의 같은 문제, 즉 데이터 이동 비용을 줄이는 이야기다.

코딩 에이전트 시대에도 런타임 이해는 남는다

코딩 에이전트는 자바 코드를 빠르게 생성할 수 있다. 하지만 Valhalla 같은 변화는 단순 자동완성으로 해결되지 않는다. 값 클래스는 어떤 타입에 동일성이 필요한지, 어떤 데이터가 불변이어야 하는지, 어떤 API가 박싱 비용을 만들고 있는지 판단해야 한다. 이런 결정은 도메인 모델링과 성능 분석을 동시에 요구한다.

Fabrice Bellard가 AI 시대에 주는 기준은 작은 구현과 시스템 이해가 여전히 강력한 기준이라고 봤다. Valhalla도 비슷하다. 모델이 코드를 생성하더라도 런타임의 타입과 메모리 의미를 잘못 이해하면 더 빠른 코드를 만드는 대신 더 복잡한 버그를 만들 수 있다.

기업 자바 팀의 현실적인 준비

기업 팀이 지금 당장 해야 할 일은 실험 빌드로 운영 코드를 바꾸는 것이 아니다. 먼저 객체 할당이 많은 핫패스를 찾고, JFR과 프로파일러로 GC와 캐시 미스를 관찰하며, 작은 불변 값 타입이 많은 도메인을 분류해야 한다. Valhalla가 정식으로 들어와도 모든 클래스를 바꾸는 식의 마이그레이션은 위험하다.

Inside Java와 OpenJDK 문서를 따라가며 JEP 상태를 확인하는 것도 중요하다. JDK 28이라는 표현은 현재 커뮤니티 논의와 일정 전망을 반영한 것이며, 실제 포함 여부는 릴리스 과정에서 바뀔 수 있다. 따라서 제품 로드맵에는 확정 기능이 아니라 준비해야 할 방향으로 반영하는 편이 안전하다.

Simple HTML, AI 에이전트 시대의 내구성이 오래 가는 웹의 단순함을 강조했듯, 오래 가는 서버도 근본 비용을 낮추는 변화가 중요하다. Valhalla는 자바가 AI 시대에도 대규모 엔터프라이즈 백엔드의 언어로 남기 위한 체질 개선에 가깝다.

한국 개발자에게 중요한 이유

한국의 금융, 커머스, 통신, 제조 백엔드는 여전히 JVM 비중이 높다. AI 기능을 붙일수록 기존 서비스는 더 많은 임베딩, 로그, 추천 후보, 권한 컨텍스트, 이벤트 데이터를 다루게 된다. 이 데이터가 모두 무거운 객체로 흐르면 모델 비용을 최적화해도 백엔드 비용이 남는다.

ARD 공개, 에이전트 검색 표준 경쟁의 시작은 에이전트가 외부 리소스를 찾는 표준 경쟁을 다뤘다. 그런 리소스 검색과 호출 뒤에도 대량의 메타데이터 처리가 남는다. Valhalla가 성숙하면 자바 팀은 모델 호출 이전과 이후의 데이터 구조를 더 촘촘하게 설계할 수 있다. AI 시대의 성능 최적화는 GPU만 보는 일이 아니다.

자주 묻는 질문

Q1: Project Valhalla는 무엇인가요?

A: 자바와 JVM에 값 클래스와 관련 런타임 개선을 도입해 객체 표현 비용을 낮추려는 OpenJDK 장기 프로젝트다.

Q2: JDK 28에 확정 포함됐나요?

A: 현재는 커뮤니티와 관련 글에서 JDK 28이 중요한 목표 지점으로 언급되는 단계다. 최종 포함 여부와 형태는 OpenJDK 릴리스 과정에서 확인해야 한다.

Q3: AI 서비스와 무슨 관련이 있나요?

A: AI 서비스도 검색, 랭킹, 권한, 로깅 같은 JVM 백엔드 위에서 돌아간다. 작은 객체 비용이 대규모 트래픽에서는 큰 인프라 비용이 된다.

Q4: 개발자는 지금 무엇을 해야 하나요?

A: 운영 코드 변경보다 할당이 많은 핫패스, 작은 불변 값 타입, GC 병목을 먼저 측정하고 정리하는 것이 좋다.

Q5: 코딩 에이전트가 알아서 최적화해주지 않나요?

A: 일부 패턴은 도와줄 수 있지만 값 동일성, API 호환성, 성능 트레이드오프는 사람의 설계 판단이 필요하다.