심화 CH 26 · 미래 자바 — Valhalla·Panama·GraalVM

🎯 이 장을 끝내면

Project Valhalla의 값 클래스/원시 클래스가 식별자 없는 값 타입으로 박싱·메모리 밀집 문제를 어떻게 푸는지 설명할 수 있어요.
Project Panama의 Foreign Function & Memory API(FFM)가 왜 JNI를 대체하는지, 어디까지 정식화됐는지 구분해요.
GraalVM Native Image의 AOT 이점(빠른 시작·낮은 메모리)과 대가(closed-world·리플렉션 사전설정)를 이해해요.
각 프로젝트가 어떤 실무 문제를 겨냥하는지, 지금 도입해도 되는지를 판단하는 감을 잡아요.
무엇이 확정이고 무엇이 진행 중/프리뷰인지를 스스로 구분할 수 있어요.

🧭

큰 그림

세 프로젝트, 세 가지 오래된 숙제

Valhalla·Panama·GraalVM은 각각 다른 통증을 겨냥해요.

자바는 20년 넘게 "안전하고 이식성 좋은" 언어였지만, 그 대가로 몇 가지 구조적 비용을 지불해 왔어요. 모든 객체가 식별자를 갖고 힙에 흩어지는 비용(캐시 비효율), 네이티브 세계와 대화할 때의 JNI 지옥, 그리고 JVM 워밍업으로 인한 느린 시작이 대표적이죠. 아래 세 프로젝트가 정확히 이 셋을 겨눕니다.

💎

Valhalla

값 타입 · 메모리 밀집 · 박싱 제거

🌉

Panama

네이티브 함수·메모리 상호운용(FFM)

🚀

GraalVM

AOT Native Image · 다언어 · JIT

⚠️

이 장의 전제 — "확정 아님"이 많아요. Panama의 FFM처럼 이미 정식화된 것도 있지만, Valhalla의 값/원시 클래스는 아직 프리뷰조차 미출시이고 Vector API는 여전히 인큐베이터 단계예요. 그래서 세부 문법·최종 명칭은 얼마든지 바뀔 수 있습니다. 여기서는 세부 API 암기가 아니라 "무슨 문제를 어떤 방향으로 푸는가"에 집중하세요. (아래 버전·상태 서술은 2024~2025 기준입니다.)

💎

Project Valhalla

"코드는 클래스처럼, 저장은 int처럼"

식별자를 버리면 얻는 것 — 밀집·캐시 친화·박싱 제거.

지금 자바에서 Integer, Point 같은 객체는 모두 식별자(identity)를 가져요. 즉 힙에 따로 존재하고, 참조로 가리키며, ==로 주소를 비교하고, 락을 걸 수 있죠. 문제는 수백만 개의 작은 값을 다룰 때예요. 배열이 값이 아니라 참조들의 배열이 되면서 메모리가 흩어지고, 캐시 미스가 폭증합니다.

💎 값 클래스 / 원시 클래스(value / primitive classes)란 Valhalla가 도입하려는 값 클래스는 식별자가 없는 값 타입이에요. 두 값이 필드가 같으면 구별 불가능(동일한 값)으로 취급돼, JVM이 자유롭게 복사·인라인·평탄화(flatten)할 수 있어요. 덕분에 값들의 배열은 참조의 배열이 아니라 값이 촘촘히 박힌 배열이 될 수 있어 — 박싱 제거 · 메모리 밀집 · 캐시 친화라는 세 이득을 노립니다. 목표 슬로건이 바로 "코드는 클래스처럼 쓰되, 저장은 int처럼"이에요.

구분	일반 클래스(현재)	값/원시 클래스(Valhalla 목표)
식별자	있음(힙에 개별 존재, `==`=주소)	없음(필드 값이 곧 정체성)
메모리 배치	참조 + 힙 객체(흩어짐)	평탄화·인라인 가능(밀집)
박싱	`Integer` 등 래퍼 박싱 비용	박싱 제거 지향
동기화/null	락 가능, null 허용	락 불가, 일부는 null 불가(원시성)

🧭

더 큰 그림 — 제네릭 특수화. Valhalla의 궁극 목표 중 하나는 제네릭 특수화(generic specialization)예요. 지금은 List<int>가 안 되고 List<Integer>로 박싱해야 하죠. 값 타입이 제네릭에 자연스럽게 들어가면 박싱 없는 제네릭 컬렉션이 가능해집니다. 이게 완성되면 "성능 위해 배열·원시 타입으로 손수 최적화하던" 코드가 훨씬 줄어들 거예요.

⚠️

아직 실무에 못 씁니다. 2024~2025 기준 값/원시 클래스는 정식은 물론 표준 프리뷰로도 출시되지 않았어요(초기 접근용 빌드·JEP 초안 단계). 명칭과 문법도 논의 중이라 계속 바뀝니다. 그러니 지금은 방향성 이해가 전부고, 코드에 도입할 대상이 아니에요. "언젠가 값 타입이 오면 내 hot-path 자료구조가 어떻게 나아질까"를 상상해 두는 정도가 적당합니다.

🌉

Project Panama

JNI를 은퇴시키는 다리

Foreign Function & Memory API — 안전한 네이티브 호출·off-heap 메모리.

C 라이브러리를 부르거나 off-heap 메모리를 다루려면 예전엔 JNI를 썼어요. 하지만 JNI는 C 보일러플레이트가 많고, 취약하고(크래시·메모리 오류), 느리고, 유지보수가 고통이었죠. Panama의 Foreign Function & Memory API(FFM)는 이걸 순수 자바 API로, 더 안전하고 빠르게 대체합니다.

핵심 요소	역할
`MemorySegment`	힙 밖(off-heap) 또는 네이티브 메모리 영역을 안전하게 표현·접근(경계 검사 포함)
`Arena`	세그먼트의 수명(lifetime)·해제를 관리하는 할당 범위. 스코프를 벗어나면 정리
`Linker` / `MethodHandle`	네이티브 함수를 자바 메서드 핸들로 연결해 직접 호출
`jextract`	C 헤더 파일에서 바인딩(자바 코드)을 자동 생성하는 도구

🌉 JNI vs FFM — 무엇이 나아졌나 JNI — C로 짠 글루 코드 필요, 컴파일·플랫폼 종속, 타입 안전성 약함, 실수 시 JVM 크래시.
FFM — 자바만으로 네이티브 함수 호출·메모리 접근, Arena 기반 결정적 해제, 경계 검사로 안전성↑, jextract로 바인딩 자동화. 한 줄 요약 — "FFM은 JNI를 대체하기 위한, 더 안전하고 성능 좋은 표준 API"입니다.

💡

상태 정리 — 여기가 헷갈리기 쉬워요. FFM API는 여러 릴리스의 프리뷰를 거쳐 Java 22에서 정식(final) 기능이 됐어요(JEP 454). 즉 이건 실무에 쓸 수 있는 확정 기능입니다. 반면 같은 Panama 우산 아래의 Vector API(SIMD 병렬 연산)는 아직 인큐베이터(incubator) 단계라 아직 확정이 아니에요. "Panama = 전부 확정"이 아니라, FFM은 정식 / Vector API는 인큐베이터로 나눠 기억하세요.

MemorySegment Arena Linker jextract FFM = Java 22 정식 Vector API = 인큐베이터

🚀

GraalVM

시작을 빠르게, 메모리를 가볍게 — 대신 세계를 닫는다

Native Image · Truffle · Graal JIT.

GraalVM은 하나가 아니라 세 얼굴을 가진 프로젝트예요. 실무에서 가장 화제인 건 Native Image고, 그 밑에 다언어 런타임(Truffle)과 고성능 JIT(Graal 컴파일러)가 있습니다.

📦

Native Image

AOT로 네이티브 실행파일 생성

🗣️

Truffle

JS·Python·Ruby 등 다언어 런타임

⚡

Graal JIT

C2를 대체 가능한 JIT 컴파일러

📦 Native Image — 얻는 것과 잃는 것 얻는 것 — 애플리케이션을 빌드 시점에 AOT 컴파일해 하나의 네이티브 실행파일로 만들어요. 그래서 시작이 매우 빠르고(밀리초급), 메모리 사용이 낮아 서버리스·CLI·짧게 뜨는 컨테이너에 유리합니다.
잃는 것 — JVM 워밍업(JIT 최적화)이 없어 오래 도는 워크로드에선 피크 처리량이 JIT보다 낮을 수 있고, 리플렉션·동적 프록시·JNI·리소스는 빌드 때 사전 설정(구성 파일)이 필요해요. 근본 이유는 closed-world 가정이에요. 빌드 시점에 도달 가능한 모든 코드가 이미 알려져 있다고 보고 나머지를 잘라내므로, 런타임에 클래스를 동적으로 로딩하는 방식은 기본적으로 제약됩니다.

⚠️

"자바인데 왜 리플렉션이 안 돼요?"의 정체. Native Image는 빌드 때 코드 전체를 정적 분석해 도달하지 못하는 코드를 제거합니다(closed-world). 그래서 런타임에 이름으로 클래스를 찾는 리플렉션·프록시는 빌드가 그 존재를 알 수 없으면 실패해요. 그래서 reflect-config·resource-config 같은 구성으로 "이건 런타임에 쓸 거야"를 미리 알려줘야 합니다. Spring Boot/Quarkus/Micronaut가 이 구성을 상당 부분 자동 생성해 주는 이유죠.

구성요소	한 줄 정리
Native Image	AOT 컴파일 → 빠른 시작·낮은 메모리, 대신 closed-world·사전설정
Truffle	언어 인터프리터 프레임워크 — JS·Python·Ruby·R 등을 한 런타임에서(GraalJS 등)
Graal JIT	자바로 작성된 고성능 JIT 컴파일러. HotSpot의 C2를 대체할 수 있음

🧭

JIT와 AOT는 반대 방향의 트레이드오프. 전통적 JVM은 실행하며 뜨거운 코드를 JIT 최적화해 피크 처리량이 좋지만 워밍업이 필요합니다. Native Image의 AOT는 워밍업 없이 즉시 빠르게 시작하지만 런타임 프로파일 기반 최적화 기회가 줄어요. 오래 도는 대형 서비스는 JIT, 짧게 뜨고 자주 재시작하는 서버리스/CLI는 AOT — 워크로드로 고르는 게 핵심입니다.

🧩

정리 · 적용

각 프로젝트가 푸는 문제와 실무 시점

지금 준비할 것 vs 나중에 볼 것.

프로젝트	푸는 문제	상태(2024~2025)	실무 태도
Valhalla	메모리 밀집·추상화 비용(박싱·식별자)	미출시(초기 접근·논의 중)	방향성만 이해, 도입 X
Panama (FFM)	네이티브 함수·off-heap 메모리 상호운용(JNI 대체)	Java 22 정식	네이티브 연동 시 JNI 대신 검토
Panama (Vector)	SIMD 병렬 수치 연산	인큐베이터	실험적으로만
GraalVM Native Image	느린 시작·높은 메모리(서버리스·CLI)	사용 가능(성숙 중)	서버리스·CLI에 유효, 제약 숙지

🧩 한 문장씩 — 무엇을 겨냥하나 Valhalla = "객체의 추상화를 유지하면서도 원시 타입처럼 밀집하게" — 메모리·캐시 비용을 없앤다.
Panama = "네이티브 세계와 안전하고 빠르게 대화한다" — JNI를 FFM으로 대체.
GraalVM = "AOT로 즉시 시작하고 가볍게 돈다" — 대신 closed-world라는 대가. 공통 흐름은 "자바가 더 낮은 레벨(메모리·네이티브·시작속도)까지 안전하게 내려가려 한다"는 거예요. 클라우드·서버리스 시대의 요구에 대한 응답이죠.

💡

5년차의 실전 태도. 오늘 당장 코드를 바꿀 건 많지 않아요. 하지만 FFM은 지금 네이티브 연동을 새로 짤 때 JNI 대신 진지하게 후보가 되고, Native Image는 람다/CLI 도구를 만들 때 시작속도 카드로 실전 검토할 만합니다. Valhalla·Vector는 "확정되면 내 hot-path가 어떻게 좋아질지"만 머리에 담아두면 충분해요. 핵심은 확정/미확정을 구분해 과잉 도입하지 않는 판단입니다.

🧠 이 장 핵심 요약

Valhalla = 식별자 없는 값/원시 클래스 → 박싱 제거·메모리 밀집·캐시 친화, 향후 제네릭 특수화. 아직 미출시(방향성 이해).
Panama FFM = JNI를 대체하는 안전한 네이티브 호출·off-heap 메모리(MemorySegment·Arena·jextract). Java 22에서 정식(JEP 454).
Vector API(SIMD)는 같은 Panama라도 아직 인큐베이터 — FFM과 상태를 구분.
GraalVM Native Image = AOT로 빠른 시작·낮은 메모리(서버리스·CLI), 대신 closed-world·리플렉션 사전설정 필요, 피크 처리량은 JIT보다 낮을 수 있음.
GraalVM엔 Truffle(다언어), Graal JIT(C2 대체 가능)도 있음. JIT=처리량, AOT=시작속도의 트레이드오프.
실무 원칙 — 확정(FFM)과 미확정(Valhalla·Vector)을 구분하고, 워크로드에 맞게 과잉 도입 없이 선택.

📝

문제풀이 · 점검

방향성과 상태를 정확히

특히 "무엇이 확정이고 무엇이 진행 중인지"를 헷갈리지 않는 게 관건이에요.

🧪

개념을 "안다"와 "설명할 수 있다"는 달라요. 네 유형(객관식 · O/X · 빈칸 · 코드/개념)으로 점검해보세요.

로드맵으로 📋 심화 트랙 마지막 장이에요. 목차로 돌아가 전체 흐름을 다시 조망해 보세요. →

자바는 지금 어디로 가고 있을까? — Valhalla·Panama·GraalVM