[Language] Java

Java란?

---

Java는 클래스 기반 객체지향 언어이자, JVM(Java Virtual Machine)을 중심으로 동작하는 실행 플랫폼이다. 언어로서의 Java는 소스 코드를 바이트코드로 컴파일하고, 플랫폼별 JVM이 그 바이트코드를 검증, 로딩, 해석, JIT 컴파일해 실행한다. 그래서 Java의 핵심 가치는 단순히 문법이 아니라 런타임, 표준 라이브러리, 빌드 도구, 프레임워크, 운영 도구가 결합된 생태계에 있다.

Java는 C/C++의 포인터, 수동 메모리 관리, 플랫폼 종속 빌드가 만들던 복잡성을 줄이고, 네트워크 시대의 장기 실행 서버 애플리케이션에 맞는 이식성과 안정성을 제공하기 위해 등장했다. 현재는 웹 백엔드, 금융 시스템, 엔터프라이즈 업무 시스템, Android 생태계, 빅데이터 플랫폼, 메시징·스트리밍 시스템에서 널리 쓰인다.

Java는 "언어"와 "JVM 플랫폼"을 함께 봐야 이해되는 기술이다. 소스 문법보다 중요한 것은 바이트코드 실행 모델, 표준화된 런타임, 강한 생태계, 운영 가능성이다.

 

등장 배경과 생태계상 위치

---

Java의 설계 방향은 "한 번 작성하면 여러 곳에서 실행한다"는 JVM 기반 이식성, 자동 메모리 관리, 표준 라이브러리, 보안 모델, 네트워크 친화 API에 맞춰져 있다. 이 방향성은 데스크톱 애플릿보다 서버 애플리케이션에서 더 강하게 살아남았다. 운영체제와 CPU가 달라도 JVM이라는 추상 실행 계층을 기준으로 배포할 수 있고, 런타임이 메모리 관리와 최적화를 맡기 때문이다.

생태계 관점에서 Java는 Spring, Jakarta EE, Micronaut, Quarkus 같은 서버 프레임워크, Maven과 Gradle 같은 빌드 도구, JUnit과 Testcontainers 같은 테스트 도구, Kafka·Hadoop·Elasticsearch·Cassandra 같은 JVM 기반 인프라 소프트웨어와 맞물린다. Kotlin, Scala, Groovy, Clojure도 JVM 위에서 동작하기 때문에 Java 플랫폼의 가치는 Java 문법을 넘어선다.

Java는 엔터프라이즈 서버 개발의 공통 기반에 가깝다. 언어 자체보다 JVM, 라이브러리, 프레임워크, 운영 도구의 축적이 선택 이유가 되는 경우가 많다.

 

핵심 동작 원리: 컴파일, 클래스 로딩, JVM 실행

---

Java 코드는 javac에 의해 .class 바이트코드로 컴파일된다. 실행 시 JVM은 클래스 로더를 통해 필요한 클래스를 로딩하고, 바이트코드 검증기로 타입 안전성과 스택 규칙을 확인한 뒤, 인터프리터와 JIT 컴파일러를 조합해 실행한다. 자주 실행되는 코드는 HotSpot 같은 JVM이 런타임 프로파일을 기반으로 네이티브 코드로 최적화한다.

이 구조는 Java 성능의 핵심이다. 정적 컴파일 언어처럼 시작부터 네이티브 바이너리를 만드는 방식은 아니지만, 장기 실행 서버에서는 실제 트래픽 패턴을 보고 최적화하는 JIT의 장점이 크다. 반대로 짧게 실행되는 CLI, 서버리스 콜드 스타트, 초저지연 시스템에서는 JVM 시작 시간, 워밍업, GC 튜닝이 부담이 될 수 있다. 이 문제를 줄이기 위해 CDS, GraalVM Native Image, AppCDS, AOT 계열 접근이 함께 쓰인다.

Java 실행 모델은 바이트코드 이식성과 런타임 최적화의 교환이다. 장기 실행 서버에는 강하지만, 시작 시간과 워밍업이 중요한 환경에서는 별도 전략이 필요하다.

 

타입 시스템과 언어 특성

---

Java는 정적 타입 언어이며, 클래스와 인터페이스를 중심으로 추상화를 구성한다. 제네릭은 컴파일 타임 타입 안정성을 제공하지만 타입 소거(type erasure)를 기반으로 하므로 런타임에는 일부 타입 정보가 사라진다. 이 특성은 하위 호환성을 지키는 데 유리했지만, 리플렉션, 직렬화, 프레임워크 자동 바인딩에서는 제약으로 작동한다.

최근 Java는 record, sealed class, pattern matching, switch 개선, virtual threads 등으로 표현력과 동시성 모델을 꾸준히 개선해 왔다. 다만 Java의 강점은 급진적 문법보다 하위 호환성이다. 오래된 코드와 최신 런타임이 함께 살아야 하는 기업 환경에서는 이 보수성이 큰 장점이지만, 언어 혁신 속도만 보면 Kotlin, Rust, Go, TypeScript보다 답답하게 느껴질 수 있다.

Java의 타입 시스템은 안정성과 호환성을 우선한다. 현대적 문법은 계속 추가되지만, 기존 생태계를 깨지 않는 방식으로 천천히 진화한다.

 

운영 관점: 메모리, GC, 관측 가능성

---

Java 운영의 핵심은 힙, 스레드, GC, 클래스패스·모듈패스, 의존성 충돌을 이해하는 것이다. JVM은 자동 메모리 관리를 제공하지만 메모리 문제가 사라지는 것은 아니다. 객체 할당률이 높거나, 캐시·컬렉션·ThreadLocal·클래스 로더가 참조를 오래 붙잡으면 GC 부하와 메모리 누수가 발생한다. G1, ZGC, Shenandoah 같은 컬렉터 선택은 지연 시간, 처리량, 힙 크기, 운영 JDK 배포판에 따라 달라진다.

현업에서는 JVM 옵션, GC 로그, JFR(Java Flight Recorder), Micrometer, OpenTelemetry, APM을 함께 사용해 병목을 찾는다. 장애 대응에서는 OutOfMemoryError, 스레드 고갈, deadlock, connection pool saturation, classpath 충돌, serialization 취약점, TLS·인증서 문제, 컨테이너 메모리 제한과 JVM 힙 설정 불일치를 자주 확인한다.

Java는 운영 도구가 강한 언어다. 대신 JVM 내부 동작을 모르면 GC 지연, 메모리 누수, 스레드 고갈 같은 문제가 추상화 뒤에 숨어버린다.

 

아키텍처와 선택 기준

---

Java는 복잡한 도메인 모델, 트랜잭션 처리, 장기 유지보수, 대규모 팀 협업, 강한 테스트·빌드·배포 체계가 필요한 시스템에 적합하다. Spring Boot 기반 백엔드, 배치 처리, 메시지 소비자, API 게이트웨이 뒤의 업무 서비스, Kafka Streams 같은 JVM 기반 스트리밍 처리에서 특히 많이 선택된다.

반대로 단일 바이너리 배포, 극단적으로 작은 메모리 풋프린트, 짧은 콜드 스타트, 시스템 프로그래밍, 브라우저 중심 개발이 핵심인 경우에는 Go, Rust, Node.js, TypeScript, Python 같은 대안이 더 단순할 수 있다. Java를 선택할 때는 언어 취향보다 조직의 운영 역량, 기존 코드 자산, 프레임워크 표준, 배포 환경, 성능 요구, 채용 시장을 함께 봐야 한다.

Java는 "가장 빠른 개발 언어"라기보다 "큰 조직이 오래 운영하기 쉬운 플랫폼"에 가깝다. 선택 기준은 문법보다 운영·생태계·인력·레거시 자산이다.

 

보안, 호환성, 마이그레이션 고려사항

---

Java 보안은 JDK 업데이트, 의존성 취약점, 직렬화, 리플렉션, 템플릿·표현식 엔진, XML 처리, 클래스패스 오염, 서드파티 라이브러리 공급망에 크게 좌우된다. Log4Shell 같은 사건은 Java 생태계에서 의존성 관리와 런타임 탐지의 중요성을 보여준다. 운영팀은 SBOM, dependency scanning, CVE 대응 절차, JDK 패치 주기, 컨테이너 이미지 베이스라인을 관리해야 한다.

마이그레이션에서는 JDK 버전, 빌드 도구, 프레임워크 버전, javax에서 jakarta로의 패키지 변화, removed API, illegal reflective access, TLS 기본값, GC 기본값, 컨테이너 인식 옵션을 점검한다. 특히 Java 8에서 11, 17, 21 이후 버전으로 올라갈 때는 단순 컴파일보다 테스트 자동화, 성능 회귀 측정, GC 로그 비교, 라이브러리 호환성 검증이 중요하다.

Java 마이그레이션은 JDK만 올리는 작업이 아니다. 프레임워크, 의존성, 보안 정책, GC, 컨테이너 배포 기준까지 함께 바뀌는 운영 프로젝트다.

 

사례

---

• Oracle Java Language Specification / JVM Specification: Java의 문법, 타입 시스템, 실행 모델은 Oracle의 Java SE 사양 문서가 기준이다. 언어 기능을 설명할 때는 튜토리얼보다 Java SE Specifications와 Java SE Documentation을 먼저 확인하는 것이 정확하다.
• OpenJDK Project Loom: virtual threads는 기존 플랫폼 스레드 중심 동시성 모델의 비용을 낮추기 위해 도입된 대표적 변화다. 대량의 blocking I/O 서버를 더 단순한 동기 코드로 작성할 수 있게 만드는 방향이며, 공식 배경은 OpenJDK Project Loom에서 확인할 수 있다.
• LinkedIn의 Java 11 전환: LinkedIn Engineering은 대규모 서비스의 Java 11 마이그레이션 경험을 공유했다. 단순 버전 업그레이드가 아니라 빌드, 테스트, 런타임 성능, 라이브러리 호환성, 운영 안정성을 함께 검증해야 한다는 점을 보여주는 사례다. 출처: LinkedIn's Journey to Java 11.
• Spring 생태계: Java 서버 개발에서 Spring Boot는 설정, 의존성 관리, 관측 가능성, 배포 패턴을 사실상 표준화한 대표 생태계다. 공식 문서의 production-ready features와 actuator 문서는 Java 애플리케이션을 실제 운영 시스템으로 다룰 때 필요한 관점을 제공한다. 출처: Spring Boot Actuator Documentation.