네, 핵심은 맞습니다. 기존의 자바 코딩 방식과 비즈니스 로직은 거의 그대로 유지됩니다. 하지만 기술적으로는 **"정적 분석(Ahead-Of-Time, AOT)"**이라는 과정이 추가되기 때문에 개발 단계에서 몇 가지 주의할 점과 차이점이 존재합니다.
쉽게 이해하실 수 있도록 요약해 드리겠습니다.
스프링 부트 3.x 버전부터는 Native Image 지원이 기본으로 통합되었습니다. 따라서 코드를 짜는 방식은 똑같습니다. 하지만 **"런타임에 동적으로 일어나는 일들"**에 대해 제약이 생깁니다.
RuntimeHints라는 설정을 통해 "이 클래스는 리플렉션을 쓸 거야"라고 미리 알려줘야 합니다.
빌드 과정이 훨씬 무겁고 오래 걸립니다.
java -> class -> jar (수 초~수십 초 소요)java -> AOT 분석 -> GraalVM 컴파일 -> OS 전용 실행 파일 (수 분 소요, 메모리 점유율 높음)
빌드가 완료된 후에는 결과물이 .jar 파일이 아니라, ls -al로 봤을 때 실행 권한이 있는 바이너리 실행 파일 하나가 나옵니다.
OS(distroless 등) 이미지 위에 실행 파일 하나만 올리면 됩니다."ARM 4코어, 24G RAM, 여러 개의 앱 분리" 상황에서 Spring Native는 아주 좋은 선택지입니다.
Native Image로 빌드합니다. (ARM용으로 빌드해야 하므로 해당 서버에서 빌드하거나 Cross-compile 설정을 해야 합니다.)**"개발은 똑같지만, 빌드할 때 시간이 더 걸리고, 결과물이 아주 가벼운 실행 파일로 나온다"**고 이해하시면 됩니다.
처음 시도하신다면 모든 앱을 한꺼번에 바꾸기보다, 하나만 먼저 Spring Boot 3.x + GraalVM Native Support로 만들어서 도커에 올려 메모리 점유율을 확인해 보시는 것을 추천드립니다. 생각보다 드라마틱한 효과를 보실 수 있습니다.