혹시 우리가 애지중지하던 프로그래밍 언어가, 마치 서랍 속 먼지 쌓인 구형 가전제품처럼 서서히 존재감을 잃어가는 건 아닐까, 은근히 걱정해 본 적 없으신가요? Java 26이 방금 출시되었는데, 이건 단순히 ‘아직 죽지 않았어!’를 외치는 수준이 아닙니다. 디지털 시대의 다음 막을 위해 스스로를 재정비하고 있다는 강력한 메시지를 던지고 있죠. 이건 단순한 점진적 업데이트가 아니라, 마치 조용히 일어나고 있는 지각 변동처럼, 근본적인 플랫폼의 변화를 예고하는 신호탄입니다. 우리는 여기서 앱릿—네, 바로 그 앱릿—의 공식적인 은퇴를 선언하고, 웹의 미래인 HTTP/3 지원이 코어에 깊숙이 통합되는 것을 목격하게 될 겁니다. 풀어야 할 이야기가 많지만, 솔직히 말해 매우 흥미진진합니다.
많은 이들이 여전히 엔터프라이즈급 안정성과 동의어처럼 여기는 Java의 6개월 릴리스 주기는 놀랍도록 빠른 속도를 유지하며 계속되고 있습니다. 지난 9월 LTS(Long-Term Support) 릴리스였던 Java 25에 이어, Java 26은 2026년 3월 출시 슬롯에 등장합니다. 이번 릴리스는 LTS 후보가 아니지만, 다음 단계로 나아가는 데 있어 매우 중요한 디딤돌 역할을 할 것입니다. 기능 개수만 보면 이전 버전보다 적어 보일 수 있습니다—이 점은 릴리스 노트에서도 익살스러운 이모티콘과 함께 슬쩍 인정하고 있죠—하지만 그 변화들의 ‘질’이야말로 진정한 마법이 발현되는 지점입니다.
미스터리한 ‘final’ 필드의 속사정
자, ‘final’ 필드에 대해 이야기해 봅시다. 수년간 이것들은 불변성(immutability)에 대한 짜릿한 약속, 한 번 설정되면 절대 변하지 않을 값이라는 컴파일러와의 계약처럼 여겨져 왔습니다. 하지만 여기에 리플렉션(reflection)이라는, 강력하지만 약간은 위험한 도구가 등장했죠. 이 도구를 통해 개발자들은 커튼 뒤를 엿볼 수 있었고, 심지어 ‘final’이라고 선언된 값들을 변경하는 것까지 가능했습니다. 이는 언어 자체의 약속과 현실 사이의 미묘한 불협화음을 만들어냈습니다. 언어는 한 가지를 약속했지만, 허점은 다른 것을 허용했던 것이죠.
이것은 단순한 이론적 논쟁거리가 아니었습니다. 성능 병목 현상의 주범이었죠. 컴파일러가 어떤 값이 진정으로 상수인지 확신할 수 없을 때, 코드를 최적화하려는 시도를 상상해 보세요. ‘상수 폴딩(constant folding)’과 같은 기본적인 최적화 작업은 불가능해집니다. Java 26은 JEP 491을 통해 이 허점을 체계적으로 막기 시작합니다. 이는 의도적이고 단계적인 접근 방식입니다. 지금 당장은 경고 메시지가 표시될 것이고, 미래에는? 예외가 발생할 것입니다. 이것이 바로 고전적인 Java 방식입니다. 개발자들을 부드럽게, 그리고 결국에는 단호하게, 더욱 일관되고 최적화된 미래로 이끌어가는 방식이죠. 마치 훈련용 바퀴가 떨어져 나가지만, 안전망은 그대로 있는 것과 같습니다.
앱릿: 9년 간의 마지막 투어
그리고 앱릿이 있습니다. 기억하시나요? 90년대 후반, 약 5분 동안은 미래처럼 느껴졌던, 브라우저에 내장되는 작은 Java 애플리케이션들 말입니다. 이제 Java 26이 마침내 문을 닫아 겁니다. 놀라운 소식이 아닙니다. 이것은 9년에 걸친 치밀한 단계적 제거 과정의 최종 결론입니다. JDK 9(2017)에서 지원 중단(deprecated)되었고, JDK 11(2018)에서 앱릿 뷰어가 제거되었으며, JDK 17(2020)에서 forRemoval=true로 표시되었고, 이어서 앱릿 보안에 필수적이었던 SecurityManager가 JDK 24(2024)에서 사라졌습니다. 그리고 이제, 2026년 Java 26에서 마침내 JDK에서 완전히 삭제됩니다. 조용하지만 중대한 순간입니다. 디지털 고고학 발굴이 마지막 유물을 목록화하고 저장하는 것으로 마무리되는 것과 같습니다. 아마도 그것들은 진정으로 이해받지 못했을 수도 있지만, 그들의 떠남은 현대 웹에 대한 Java의 집중을 시사합니다.
앱릿 API 제거 노력이 시작된 지 9년 만에, 이 모든 이야기가 논리적인 결론에 도달했습니다! 겨우 33살도 안 됐는데… 너무 일찍 떠났고, 진정으로 이해받지 못했습니다.
HTTP/3: 웹의 새로운 고속도로
하지만 Java는 작별 인사만 하는 것이 아닙니다. 그것은 바로 다음을 포용하는 것입니다. 그리고 웹 통신 세계에서 다음은 바로 HTTP/3입니다. 이미 3분의 1 이상의 웹 서버가 이를 지원하고 있는 상황에서, Java 11에서 HttpUrlConnection의 현대적인 대체재로 도입된 HttpClient에 통합되는 것은 단순한 기능 추가라기보다는 필수적인 조치처럼 느껴집니다. JEP 487은 이 최첨단 프로토콜을 표준 라이브러리에 가져옵니다. 이것이 왜 중요할까요? 더 빠른 핸드셰이크, 더 안정적인 데이터 파이프, 그리고 수년간 웹 성능을 괴롭혀온 ‘머리-of-라인(head-of-line)’ 차단 문제의 근절을 상상해 보세요. 마치 1차선 시골길에서 다차선 광섬유 초고속도로로 업그레이드하는 것과 같습니다. 간단한 플래그(HttpClient.Version.HTTP_3)로 옵트인할 수 있으며, 서버가 준비되지 않았다면 Java는 연결을 우아하게 다운그레이드합니다. 똑똑하죠. 너무 똑똑해서 왜 이렇게 오래 걸렸는지 의문이 들 정도입니다.
지연된 상수(Lazy Constants)의 귀환 (미리보기)
이러한 주요 기능 외에도 Java 26은 개발자 경험을 계속해서 다듬고 있습니다. JEP 502의 미리보기 버전인 “Stable Values”는…
