오라클의 인수부터 자바의 역습까지: JVM 생태계 15년사

“자바는 죽었다.”

2010년 오라클(Oracle)이 썬마이크로 시스템즈(Sun Microsystems)를 74억 달러에 인수했을 때, 개발자 커뮤니티 곳곳에서 이 말이 돌았다. JDK 유료화 소문, 구글과의 특허 소송전, 굼뜨기로 악명 높은 업데이트 주기. 불안의 이유는 차고 넘쳤다.

15년이 지난 2026년, 자바는 여전히 살아있다. 아니, 오히려 더 강해졌다. 그 사이 도대체 무슨 일이 있었던 걸까?

왜 오라클은 자바를 인수했을까

2010년 1월, 오라클이 썬마이크로 시스템즈 인수를 완료했을 때 많은 사람들이 고개를 갸우뚱했다. “데이터베이스 회사인 오라클이 왜 하드웨어 회사를?”

오라클의 진짜 목표는 하드웨어가 아니었다. 플랫폼과 생태계였다.

당시 자바(Java)는 단순한 프로그래밍 언어가 아니었다. 전 세계 수십억 대의 기기에 설치된 JVM(Java Virtual Machine)이라는 실행 환경이었고, 전 세계 엔터프라이즈 서버의 상당수가 자바 위에서 돌아가고 있었다. 오라클의 주력 제품인 Oracle DB와 미들웨어 WebLogic은 자바 생태계와 찰떡궁합이었다. 자바를 손에 쥔다는 건, 엔터프라이즈 시장 전체의 식수원을 확보하는 것과 다름없었다.

“오라클은 언어를 산 게 아니라, 세계 최대의 엔터프라이즈 플랫폼을 샀다.”

인수 직후, 오라클은 구글(Google)을 상대로 특허·저작권 소송을 제기했다. 구글의 안드로이드(Android)가 자바 API를 무단으로 사용했다는 이유였다. 이 소송은 무려 10년에 걸쳐 이어졌고, 2021년 미 대법원이 최종적으로 구글의 손을 들어주며 끝났다.

게다가 오라클은 2018년부터 Oracle JDK 유료화 정책을 강화했다. 상업적 목적으로 Oracle JDK를 사용하려면 라이선스 비용을 내야 했다. “오라클이 자바를 망치고 있다”는 비판이 쏟아졌고, 기업들은 OpenJDK, Amazon Corretto, Eclipse Temurin 같은 무료 배포판으로 눈을 돌리기 시작했다. 분위기는 살벌했다. 그리고 그 틈새를 파고든 언어들이 등장했다.

코틀린·스칼라의 등장: JVM의 구원투수들

오라클 인수 이후, 자바는 한동안 정체기에 빠졌다. Java 7(2011년)과 Java 8(2014년) 사이의 3년 공백, 그리고 Java 8과 Java 9(2017년) 사이의 또 다른 3년. 업데이트는 느렸고, 언어는 장황했다. 같은 일을 하기 위해 다른 언어보다 몇 배 더 많은 코드를 써야 했다.

// Java의 악명 높은 "보일러플레이트(boilerplate)" 코드
public class User {
    private final String name;
    private final int age;

    public User(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() { return name; }
    public int getAge()     { return age; }

    @Override
    public boolean equals(Object o) { /* ... 수십 줄 ... */ }
    @Override
    public int hashCode()  { /* ... */ }
    @Override
    public String toString() { /* ... */ }
}

데이터 클래스 하나 만드는 데 이 정도 코드가 필요했다. 개발자들은 피로했다. 그 피로를 파고든 두 언어가 스칼라(Scala) 와 코틀린(Kotlin) 이다.

스칼라: 함수형의 기치를 들다

스칼라는 “Scalable Language”의 약자다. 마틴 오더스키(Martin Odersky) 교수가 설계한 언어로, JVM 위에서 돌아가면서도 함수형 프로그래밍(Functional Programming) 과 강력한 정적 타입 시스템을 품었다.

스칼라의 결정적 도약은 아파치 스파크(Apache Spark) 였다. 2014년 등장한 스파크는 빅데이터 분산 처리의 판도를 바꿨고, 스파크 자체가 스칼라로 작성됐다. 데이터 엔지니어링 분야에서 스칼라를 모르면 대화가 안 되는 시대가 열렸다.

// 스칼라의 우아함: 데이터 클래스를 한 줄로
case class User(name: String, age: Int)

// 함수형 스타일의 간결한 데이터 처리
val activeUserNames = users
  .filter(_.age >= 18)
  .map(_.name)
  .sorted

코틀린: 자바의 불편함을 통째로 갈아엎다

코틀린(Kotlin)은 IDE 명가 젯브레인(JetBrains) 이 만들었다. IntelliJ IDEA를 만든 팀이니, 개발자 생산성에 대한 이해가 남달랐다. “자바와 100% 호환되면서, 자바의 단점은 모두 걷어내겠다.” 그것이 코틀린의 선언이었다.

코틀린의 진짜 전환점은 2017년, 구글이 안드로이드 공식 언어로 코틀린을 지정한 순간이었다. 전 세계 안드로이드 개발자 커뮤니티가 코틀린으로 이동하기 시작했고, 코틀린은 더 이상 실험적인 언어가 아니었다.

// 코틀린: 같은 데이터 클래스를 단 한 줄로
data class User(val name: String, val age: Int)

// Null 안전성, 확장 함수, 코루틴(Coroutine)까지
val activeUserNames = users
    .filter { it.age >= 18 }
    .map { it.name }
    .sorted()

자바가 제자리걸음을 하는 동안, 코틀린과 스칼라는 JVM 생태계의 혁신가로 떠올랐다. 오라클은 위기감을 느꼈다.

오라클의 반격: 6개월마다 새 자바가 나온다

2018년, 오라클은 체질 개선을 선언했다. Java 10부터 6개월 릴리스 주기(Fast-track) 를 도입한 것이다. 3~4년을 기다리게 하던 자바가, 봄과 가을마다 새 버전을 내놓기 시작했다.

변화의 속도는 놀라웠다.

코틀린의 장점이던 val/var 타입 추론을 자바도 var로 흡수했다. 스칼라의 강점이던 패턴 매칭(Pattern Matching)과 봉인 클래스(Sealed Classes)도 차례로 자바에 들어왔다. Record는 스칼라의 case class, 코틀린의 data class에 대한 자바식 응답이었다.

Project Loom: 가상 스레드의 혁명

그리고 결정타가 있었다. 자바의 고질병 중 하나는 스레드(Thread) 비용이었다. OS 스레드 하나가 수백 KB의 메모리를 차지하기 때문에, 수만 개의 동시 연결을 처리하려면 리액티브 프로그래밍(Reactive Programming)이라는 복잡한 패러다임을 써야 했다.

// Java 21 이전: 머리가 아픈 리액티브 코드 (WebFlux 스타일)
Mono.fromCallable(() -> fetchUser(id))
    .flatMap(user -> Mono.fromCallable(() -> fetchOrders(user)))
    .map(orders -> process(orders))
    .subscribe();

// Java 21 이후: 그냥 동기 코드처럼 쓰면 된다
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    var user   = executor.submit(() -> fetchUser(id)).get();
    var orders = executor.submit(() -> fetchOrders(user)).get();
    process(orders);
}

비동기의 복잡성 없이 고성능을 얻는 것. 이것이 2020년대 자바의 가장 강력한 무기가 됐다.

2026년 현재: 싸움이 아닌 공존

2026년의 JVM 생태계는 더 이상 “누가 이기느냐”의 싸움이 아니다. 각자의 영역에서 왕좌를 굳힌 평화적 공존 상태다.

Java: 엔터프라이즈의 기둥

Spring Boot 3와 가상 스레드의 조합은 대형 엔터프라이즈 시스템의 표준으로 자리잡았다. 수십 년간 쌓인 레거시 코드베이스, 성숙한 라이브러리 생태계, 검증된 안정성. 자바가 점령한 영역은 쉽사리 무너지지 않는다.

Kotlin: 모바일을 넘어 멀티플랫폼으로

안드로이드(Android) 세계는 이미 코틀린의 영토다. 그리고 코틀린은 더 넓은 세계를 노린다. **KMP(Kotlin Multiplatform)**를 통해 iOS, 웹, 데스크톱, 서버를 하나의 코드베이스로 커버하려는 시도가 본격화되고 있으며, 모던 백엔드 프레임워크 Ktor도 꾸준히 영역을 넓히고 있다.

Scala: 빅데이터와 AI 파이프라인의 핵심 축

아파치 스파크(Apache Spark), 아파치 플링크(Apache Flink)의 세계는 여전히 스칼라가 강세다. AI 인프라를 떠받치는 대규모 데이터 파이프라인 영역에서 스칼라는 없어서는 안 될 언어로 자리를 굳혔다.

JVM의 미래: 도전과 진화

JVM 생태계가 안정적이라고 해서 도전이 없는 건 아니다.

GraalVM: Cold Start 문제의 해답

서버리스(Serverless)와 컨테이너 환경에서 JVM의 약점이 드러난다. JVM은 시작하는 데 시간이 걸리고(콜드 스타트, Cold Start), 메모리를 많이 먹는다. GraalVM의 AOT(Ahead-of-Time) 컴파일은 이 문제를 정면 돌파하는 기술이다. 자바 애플리케이션을 네이티브 바이너리로 컴파일해, 밀리초 단위 시작 시간과 크게 줄어든 메모리 사용량을 실현한다. Quarkus, Micronaut 같은 프레임워크가 GraalVM과 결합하며 클라우드 네이티브 자바의 미래를 열고 있다.

Go와 Rust의 도전

클라우드 인프라와 쿠버네티스(Kubernetes) 생태계에서는 이미 Go가 JVM 언어들을 상당 부분 대체했다. 쿠버네티스, 도커(Docker), 테라폼(Terraform)이 모두 Go로 작성된 건 우연이 아니다. Rust는 시스템 프로그래밍과 고성능 툴링 영역에서 가파르게 성장 중이다.

WebAssembly: 장기적 와일드카드

웹어셈블리(WebAssembly, Wasm) 는 언어의 장벽을 허무는 기술이다. 어떤 언어로든 Wasm으로 컴파일해 브라우저와 서버에서 실행할 수 있게 된다면, JVM의 “한 번 작성하면 어디서나 실행(Write Once, Run Anywhere)“이라는 철학 자체가 도전받는다. 아직 초기 단계지만, 장기적으로 주목해야 할 변수다.

결론: 자바는 흔들리지 않는다, 그러나 진화한다

수십 년간 쌓인 엔터프라이즈의 비즈니스 로직과 라이브러리 자산은 하루아침에 대체되지 않는다. 더 중요한 건, JVM 생태계가 변화를 거부하지 않고 흡수하며 스스로 진화해왔다는 점이다.

AI 인프라의 데이터 파이프라인은 Scala로, 모바일과 크로스플랫폼은 Kotlin으로, 그리고 거대한 엔터프라이즈의 심장부는 Java로. 세 언어는 서로 경쟁하면서도 JVM이라는 공통 기반 위에서 함께 생태계를 키워가고 있다.

“자바는 죽었다”고 했던 2010년의 그 목소리들은 어디로 갔을까. 2026년의 자바는, 그 어느 때보다 건강하다.