페이지 불러오는 중
javac), 패키징(jar), 디버거(jdb), 문서 생성기(javadoc) 등의 개발 툴체인과 런타임 환경(JRE/JVM)을 모두 포함합니다.jlink 도구를 통해 필요한 모듈만 조합한 경량 커스텀 런타임을 생성하는 패러다임으로 전환되었습니다.개념 요약:
┌─────────────────────────────────────────────────────────────┐
│ JDK (Java Development Kit) │
│ ├─ 개발 툴체인: javac, jar, javadoc, jdb, javap, jconsole │
│ │ │
│ └─ JRE (Java Runtime Environment) │
│ ├─ Java 표준 런타임 라이브러리 (rt.jar, charsets.jar 등) │
│ │ │
│ └─ JVM (Java Virtual Machine) │
│ ├─ Class Loader Subsystem │
│ ├─ Runtime Data Areas (Heap, Stack, Method) │
│ └─ Execution Engine (Interpreter, JIT, GC) │
└─────────────────────────────────────────────────────────────┘javac: .java 소스 코드를 JVM이 읽을 수 있는 .class 바이트코드로 컴파일.jar: 여러 .class 파일과 리소스, 메타데이터(MANIFEST.MF)를 단일 압축 아카이브로 패키징.javadoc: 소스 코드 주석으로부터 표준 HTML API 명세 문서 생성.jdb: Java 애플리케이션의 런타임 버그 추적을 위한 명령줄 디버거.javap: 컴파일된 바이트코드를 역어셈블(Disassemble)하여 분석하는 도구.전통적인 Java 8 시절에는 웹사이트에서 JRE 단독 설치 파일과 JDK 설치 파일을 별도로 다운로드받았습니다. 그러나 Java 9 (Project Jigsaw)부터는 배포 체계가 완전히 개편되었습니다.
rt.jar의 분해:rt.jar라는 약 60MB 이상의 거대 단일 파일에 모든 표준 라이브러리가 포함되어 있어 불필요한 메모리를 낭비했습니다.java.base, java.sql, java.desktop 등) 단위로 세분화되었습니다.jlink 맞춤형 런타임 이미지:jlink 도구를 사용하여 자신의 애플리케이션이 실제로 사용하는 Java 모듈만 선택적으로 묶은 수십 MB 수준의 초경량 커스텀 런타임 이미지를 직접 생성하여 컨테이너에 배포합니다.자바 바이트코드(.class)를 운영체제에 종속되지 않고 실행할 수 있도록 변환해 주는 가상머신입니다.
단순히 코드를 해석하는 인터프리터를 넘어, 자주 실행되는 핫스팟 코드를 기계어로 컴파일하는 JIT(Just-In-Time) 컴파일러와 메모리를 자동 관리하는 GC(Garbage Collector)가 핵심 엔진 역할을 합니다.
대표적인 구현체로는 오라클과 오픈소스 진영의 표준인 HotSpot JVM이 있으며, 최근에는 빠른 기동 속도(Cold Start 개선)와 AOT(Ahead-Of-Time) 네이티브 바이너리 빌드를 지원하는 GraalVM, 메모리 효율에 특화된 Eclipse OpenJ9 등으로 워크로드에 맞춰 대체할 수 있습니다.
JVM + Java 표준 라이브러리(Java Core API)로 구성됩니다.
java.util, java.lang(System 등), java.io와 같은 필수 런타임 클래스 라이브러리와 구동 환경을 제공하여, 이미 컴파일된 애플리케이션을 실행하기 위한 최소한의 패키지입니다.
JRE + 개발/컴파일/진단 툴의 완전체입니다.
자바 소스코드를 바이트코드로 변환하는 컴파일러(javac)뿐만 아니라, 실행 중인 프로세스의 상태를 추적하고 트러블슈팅할 수 있는 프로파일링 및 진단 도구(jcmd, jstat, jstack, jmap 등)를 모두 포함합니다.
소스코드 컴파일(javac), 디버깅, IDE 연동 및 로컬 성능 측정을 위해 필수적으로 JDK를 설치하여 활용해야 합니다.
보안 및 경량화(권장): 운영 환경에서는 공격 표면(Attack Surface)을 최소화하고 이미지 크기를 줄이기 위해 컴파일러나 불필요한 바이너리가 없는 JRE 또는 jlink 기반의 커스텀 경량 런타임 이미지를 사용하는 것이 원칙입니다.
트러블슈팅 및 모니터링: 다만, 실운영 중 발생하는 메모리 릭, CPU 스파이크, 스레드 데드락 등을 분석하기 위해 jcmd, jstack 같은 진단 도구가 필요한 경우가 많습니다. 이에 따라 실무에서는 진단 도구가 포함된 최소 JDK 환경을 구성하거나, APM(Application Performance Monitoring) 에이전트 및 디버그용 사이드카 컨테이너를 함께 운용하는 방식을 채택합니다.
애플리케이션의 응답 속도, 처리량(Throughput), 동시성 처리 및 리소스 효율성을 극대화하려면 어떤 JVM 구현체와 튜닝 전략을 사용할지 검토해야 합니다.
장시간 가동되며 안정적인 최적화와 대용량 힙 메모리 제어가 필요한 경우, HotSpot JVM(OpenJDK 기반의 Eclipse Temurin, Amazon Corretto 등)에 G1GC 또는 ZGC를 조합하여 레이턴시를 최소화합니다.
컨테이너의 즉각적인 기동(Sub-second Startup)과 최소한의 메모리 점유가 핵심인 환경에서는 GraalVM Native Image를 채택하여 네이티브 머신 코드로 빌드·구동하는 것이 효과적입니다.
결론적으로, 개발 단계에서는 풍부한 도구를 제공하는 JDK를 기본으로 활용하고, 운영 단계에서는 보안과 경량화를 고려한 런타임을 구성하되, 서비스의 부하 특성과 클라우드 아키텍처에 맞춰 최적의 JVM(HotSpot vs GraalVM 등)을 선별하는 것이 가장 이상적인 엔지니어링 접근 방식입니다.
댓글
GitHub 계정으로 의견이나 질문을 남길 수 있습니다.