[번역글] 새로운 시대의 Java를 맞이하며

안녕하세요. Popit에서 글을 쓰고 있는 김대희라고 합니다.  해당 글을 읽고 꽤 흥미로워서 여러분들과 공유하고 싶어서 이번 글 또한 번역하게 하였습니다. 기사의 맥락과 독자분들이 접하는 환경에 따라 차이가 있을 수 있고, 다소간 매끄럽지 않아도 많은 좋은 피드백 부탁드립니다.

원문 링크는 다음과 같습니다.

새로운 시대의 Java를 맞이하며

필자는 조직 내 Java 주제 전문가로서,  지난 2 년 동안 Java를 둘러싼 사건( JDK 모듈러, 6개월마다 Release 되는 Java , OpenJDK의 성장, 그리고 Oracle JDK 11 의 새로운 라이센스 등의 주제)에 세심한 주의를 기울였습니다.   JVM에 관해 안전을 보장하는 패치를 적용할 수 있는 Java 버전을 사용을 하려고 파악할 때,  조직이 이러한 변경 사항을 적절하게 파악할 수 있도록 하여, 소프트웨어 변경 사항을 파악하지 못하고 위반하는 실수를 방지할 수 있게 할 것입니다. 이러한 목표를 달성하는 것은 다른  이해당사자들, 특히 고위 경영진을 교육하는 데서 출발합니다.  Java의 변경사항을 역사적 맥락(즉, 시대적인 관점에서)으로 표현함으로써 기술 수준이 낮은 고객들에게 이러한 최근 상황을 설명하는 것이 도움이 된다는 것을 파악하였습니다.

안정성의 시대 

2004 년 9 월에 출시한 Java 5.0은 Java 역사에서 중요한 시대를 열었습니다. Java 5.0은 언어의 중대한 변화를 가져왔으며,  표준 버전 API(주로 Annotations 및 Generics),  새로운 버전 번호 지정 체계(90 년대 후반부터 존재해온 "J2SE 1.X"브랜드의 혼란을  없앰)를 통해  긴 시간동안 안정성을 가져왔습니다. 10 년 동안 Java는 거의 동일하게 유지하였으며 Java 6 및 Java 7에서 중단없는 개선이 이루어졌습니다.

Oracle이 2010 년 Sun을 인수함으로써 안정성에 대한 우려가  제기되었지만 JDK 자체의 전환은 매우 순조롭게 진행하였습니다. 인수 전의 Sun JDK는 Apache Harmony와 IBM JDK의 다른 JDK 구현보다 JDK 구현을 선도했습니다. Oracle의 Sun 인수 후 주요 JDK는 Oracle JDK (동일한 JDK, 다른 이름) 입니다.  Java 8은 더 중요한 언어의 변화와 JavaSE 변경 사항 (특히 lambdas 및 Stream API)을 가져 왔지만 전반적으로 이전 버전과의 호환성에 대한 Oracle의 헌신 덕분에 "안정성의 시대"가 계속되었습니다. 기업들은 13년 동안 위험을 최소화하고 최소한의 작업으로 Java를 업그레이드하는 견고한 서비스를 누렸으며, 이는 기업이 원치 않는 변화를 피할 수 있게 해주었습니다.

불확실성의 시대 

2017 년 9 월에 출시한 Java 9는 안정성을 혼란에 빠뜨리고 "불확실성의 시대"를 시작하게 하였습니다. 출시를 오래 기다리기는 했지만, 정작 개발자들은 열광적으로 새로운 Java 버전으로 전환하지 않았습니다. 이것은 아래의 사항과 같은 여러 가지 이유  때문이었습니다.

 JPMS의 불필요한 복잡함 

Jigsaw라고도 알려진 Java Platform Module System (JPMS)의 "킬러 (killer)"기능은 잘 정립되있던 Java 규범을 뒤집어 놓았습니다.  예를 들면,  JDK 디렉토리 구조, rt.jar의 존재, 공용 클래스 / 메소드의 의미 및 클래스 경로 등을 말합니다. 물론 Class-Path는 여전히 일반적으로 작동했지만 Module System은 불가분의 관계로 서로 얽혀있게 하였습니다.

사용하지 않는 API들이 실제로 제거하였습니다. 

Java 9는 API 메소드를 제거하고 출시한 첫 번째 버전입니다. Java 1.1 이후에 메소드가 더 이상 사용되지 않았지만 실제로 제거되지는 않았기 때문에 많은 사람들이 절대로 메소드가 삭제될 수 없다고 생각하고 있습니다. 이로 인해 제거된 API가 거의 없고 미미한 수준임에도 불구하고,  당분간은 Java 8을 고수할 수 있는 더 많은 이유를 제공했을 것입니다.

Java 10 버전의 출시 예정 

Java 9가 출시됨과 함께 Oracle은 Java 10이 2018 년 3 월에 출시할 것이라고 발표했습니다. Java 9의 출시가 여러번 지연된 후에  Oracle은 6 개월 주기로 Java를 출시할 의사를 표명했습니다. Java 9가  Java 10에 의해 6개월 후에 제거되고 Java 10은 Java 11의 발표로  6개월 후에 Java 10을 제거할 것이라고 했습니다.  "안정성의 시대"에서 Java 사용자는 오랜 기간 무료 공개 지원을 받았습니다. 예를 들어, Java 6은 2006년에 출시하였으며 Java 7이 출시된 지 2년 후인 2013년 중반까지 무료 공개 지원을 받았습니다. 그러나 Java 9 (및 10)의 제한된 수명을 감안할 때 많은 조직에서는 Java 8을 계속 사용하기로 결정했습니다.

예측 가능한 시대 

자바 11이 2018년 9월 현재 출시하였기 때문에 저는 우리가 불확실성의 시대를 벗어나 새로운 시대,  즉 예측 할 수 있는 시대로 전환하고 있다고 예측합니다.

정기적인 출시 주기 

Java 9의 출시 날짜가 여러 번 연기된 후에도 Oracle이 제안한 6개월 출시 주기를 고수할 수 있을지는 미지수입니다. Oracle은 출시 이후 3가지 버전의 Java 버전을 예정대로 출시했습니다. 이제 Java 12, 13이 정기적으로 출시할 것을 의심하는 사람은 거의 없습니다.

한편, 일부 사람들은 이러한 자바 9 이후의 출시는 "major(중대한)"가 아니라 "feature(기능)"의 출시라고 주장합니다. 저는 동의하지 않습니다. 필자는 출시를 이전 버전과의 비 호환성 / 변경 사항 변경으로 인해 별도의 업그레이드 작업을 수행하는,  단순한 업그레이드 작업으로 간주합니다. 이전 시대의 Java 출시에서는 일반적으로 최소한의 업그레이드 작업이 필요했습니다. (사용할 수 있는 가장 많은 작업은 Java 5.0의 enum 단어 예약과 관련된 것이었습니다.) 그러나 Java 9 이후 JPMS의 도입, API 및 모듈의 제거, "preview features(미리 보기 기능)"의 존재는 모두 이전 버전과 호환되지 않습니다. 따라서 비록 지난 출시보다 새로운 출시의 변경이 작을지라도, 새로운 시대의 출시는 여전히 "major(중대한)" 지정을 받을 가치가 있다는 것을 의미합니다.

균일한 지원 기간 

안정성의 시대( Era of Stability )에 주요 출시는 불규칙한 간격으로 출시하였습니다. 예를 들어, Java 6과 7 출시 간격은 4년 반, Java 7과 8의 출시 간격은 2년 반, Java 8와 9 사이의 출시 간격은  3년 반이었습니다. 또한 출시는 일관성이 없고 긴 기간 동안 무료 공개 지원을 제공했습니다. (예: Java 5.0의 경우 5년, Java 6의 경우 6년, Java 7의 경우 3년).

새로운 시대의 지원 사례는 훨씬 더 규칙적입니다.

  • 모든 주요 출시는 Oracle로부터 6 개월 간의 무료 공개 지원을 받습니다.
  • 이 6 개월 동안 일반적으로 2 개의 패치 출시 버전이 있습니다 (예 : Java 11, 11.0.1 및 11.0.2 버전이 지금까지 출시 하였습니다).
  • Java 11을 시작으로 모든 6번째 출시는 Oracle이 장기 지원 출시로 지정합니다.
  • 이 LTS 지정은 순수하게 지원과 관련된 것입니다. LTS 출시 버전과 비 LTS 출시 버전 사이에 생산 가치 측면에서 기술적으로 다른 것은 없습니다.
  • Oracle은 무료 공개 지원 기간이 끝난 후 비 LTS 출시 버전에 대한 상업적 지원을 제공하지 않습니다.
  • Oracle은 LTS 출시 버전에 대한 유료 상용 지원을 제공 할 예정입니다.

 JDK 구현의 일관성 

과거에는  OpenJDK와 Oracle JDK는 서로 밀접하게 관련이 있지만 Java Development Kit의 서로 다른 두 구현체였습니다. 한 JDK에서 다른 JDK로의 전환은 Oracle의 JDK에만 존재했던 독점적 특징, 특히 보안 및 데스크톱 개발 분야에서만 존재했기 때문에 원활하지 않다고 보장을 할 수 있지 않았습니다. 그러나 Java 11부터는 Oracle의 모든 독점적인 부분이 오픈 소스로 바뀌었으므로 기능상 두 JDK는 동일한 JDK라고 할 수 있습니다. 필자가 아는 한, 현재 시장에 나와있는 모든 최신 JDK 구현은 OpenJDK를 기반으로 하고 있습니다. 이것은 Java 사용자가 자신의 JDK를 얻은 특정 공급 업체와 관계없이 고도로 일관된 개발 및 기능 경험을 얻을 것이라는 가정을 의미합니다.

예측 가능한 시대로 진입하고 있습니다. 

이제 새로운 6개월간의 출시 주기에 따른 첫 장기 지원 출시(LTS 버전이)가 나온 만큼, 자바 11로의 이전을 진지하게 검토할 때가 하였습니다. 그러나 그렇게 하기 전에, 해결해야 할 몇 가지 선택사항들이 있습니다.

 JDK의 지원 요구 사항들에 대한 이해 

안정성의 시대( Era of Stability )에 Java 소비자는 장기간의 무료 공개  지원에  익숙해졌습니다. 그들은 Oracle JDK 배포판을 설치하고 보안 업데이트가 발표 할 때 패치를 적용하여, 수년 동안 무료 보안 업데이트가 더 많이 제공 할 것이라고 당연시했습니다.

예측 가능한 시대( The Era of Predictability )에서는 더 이상 그렇지 않습니다. 무료 공용 지원은 모든 Java 출시에 대해 6 개월 동안만 지속할 것입니다.

  • 6 개월마다 Java 버전을 업그레이드 하려고 한다면 - 좋습니다! 당신은 무료로 업그레이드 할 수 있습니다.
  • 6 개월 이상 특정 Java 버전을 사용하려는 경우에도 -  좋습니다! 무료 OpenJDK 업데이트를 사용할 수 없기 때문에 잠재적인 보안 취약점을 패치하지 않은 상태로 유지하는 것이 좋으면,  선택한 Java 버전을 유지할 수 있습니다.

적절한 JDK의 배포 선택 

많은 조직에서는 안정성의 시대에 Oracle JDK를 다운로드하여 사용하였습니다. 하지만 새로운 시대에는 JDK를 다운로드 하는데 더 많은 고찰이 필요합니다.

일부 공급업체와 지원 계약을 체결하려는 경우 해당 공급업체로부터 JDK 배포를 받아야 합니다. 무료 버전을 사용하려고 계획하고 있다면 라이센스에 주의를 기울여서, Classpath Exception 라이센스가 있는 GPLv2를 사용하는 JDK 배포를 선택하셔야 합니다. Oracle은 "JDK"와 "Oracle OpenJDK"라는 두 가지 라이센스가있는 JDK 배포판을 제공합니다. Oracle의 OpenJDK는 GPLv2 + CE입니다. Oracle JDK는 버전 11을 기준으로 JDK를 '데이터 처리 또는 개발, 테스트, 프로토타이핑 및 애플리케이션 시연 이외의 상업, 생산 또는 내부 비즈니스 목적'으로 사용할 수 없도록 하는 새로운 라이센스를 제공하기 시작했습니다.

따라서 Oracle에서 지원을 받을 유료버전을 구입하려는 경우가 아니라면 Oracle JDK 11(또는 이후 Oracle JDK 버전)을 사용하지 마십시오.

데스크탑 응용 프로그램 및 애플릿에 대한 의미 이해 

오랜 시간이 지났지만, Java 11은 데스크탑 패키지 JDK를 설치하거나 오래된 브라우저에서 애플릿을 사용하는 웹 페이지를 볼 때  별도로 설치되는 Java Runtime Environment를 삭제하였습니다. 저는 여러분이 애플릿을 사용하고 있다면, 여러분은 아마도 구식이고 안전하지 않은 브라우저와 JRE 버전을 사용하는 것에 거리낌이 없을 것이기 때문에, 애플릿이 삭제된 것을 슬퍼하는 사람은 아무도 없을 것이라고 생각합니다.

일부는 데스크탑 응용 프로그램에 미치는 영향을 슬퍼할 수 있지만, 사실, Java 기반 데스크탑 응용 프로그램의 개념은 사라지지 않고 있습니다. 그것은 단지 그들이 Oracle이 지원 로드맵에서 설명하는 대로 다르게 개발되고 전달 할 필요가 있다는 것입니다.

Oracle은 자동 업데이트 기능을 통해 Desktop의 JavaSE 버전을 Java SE 8에서 이후 버전으로 마이그레이션 할 계획이 없습니다. 여기에는 Java Plugin과 Java Web Start가 포함됩니다. 브라우저에서 액세스 할 수있는 시스템 JRE에 의존하는 대신,  Application 개발자는 Java SE 9에 도입 된 패키지 옵션을 사용하여 Java 응용 프로그램을 자체 사용자 지정 런타임을 포함하는 독립형 Application으로 다시 패키징하고 제공할 것을 권장합니다.

즉, Desktop Java Application을 빌드하고 배포하는 방법을 재구성하지 않는 한 Desktop Java Application을 Java 11 버전으로 이동하기를 권하지 않습니다. 왜냐하면, Desktop에 JRE 11이 설치되지 않기 때문입니다. 대신 JRE (즉, JDK의 Desktop 관련 Module)를 독립형 Application과 함께 제공해야 합니다. 필자는 Application 개발자가 사용하는 Java 버전을 보다 잘 제어할 수 있을것이기 때문에,  이는 긍정적인 변화라고 생각됩니다. 또한 JDK가 모듈화되어 있으므로 필요없는 JDK를 포함 할 필요가  없기 때문에, Application을 통한 보안 취약점 악용 위험을 줄일 수 있습니다.

Application팀이 JDK를 관리하는 것에 대한 고려 

전체 DevOps 동작/개념을 완전히 파악하지 못한 조직은 JDK를 제공하고 패치하는 큰 책임들을 운영 팀에게 부여할 수 있습니다. 데스크탑 응용 프로그램에 대한 Oracle의 권장 사항, 마이크로 서비스 아키텍처의 인기 및 클라우드 기본 트렌드를 고려하여, 개발팀이 Application과 함께 JDK를 운영 환경에 제공함으로써 JDK를 개발팀이 담당하도록 하는 생각을 진지하게 검토하게 합니다.

새로운 Java 출시에는 제거된 API/Module로 인한 이전 버전과의 호환이 되지 않는 위험이 더 많이 수반되므로, 모든 Java 기능 출시 업그레이드에는 약간의 코드 또는 빌드 시스템 변경이 필요하게 됩니다. 그러므로, 작업에서 최신 JDK 버전을 설치하고 Java Application을 문제 없이 계속 실행한다고 가정하지 않아야 합니다. 또한 JDK (예 : Shenandoah 및 ZGC)에서 현재 사용할 수 있는 가비지 콜렉터의 정교함과 다양성을 고려할 때 Application 개발팀은 JDK를 담당 할 때 JVM을보다 쉽게 실험하고 미세하게 조정할 수 있습니다.

결론 

필자는 불확실성의 시대동안 유보적인 태도로 이러한 여러가지 일들이 펼쳐지는 것을 지켜봤지만, 이제 우리가 예측가능한 시대에 확고히 들어섰다고 생각하기 때문에, 필자는 JDK의 미래에 대해 낙관적으로 생각합니다. 왜냐하면, Jigsaw의 출시와 , 새로운 LTS 버전의 출시, Oracle JDK 라이센스 변경 사항을 둘러싼 FUD는 소비자가 원하는 대로 많은 OpenJDK 옵션을 보유하고 있다는 사실을 인식함에 따라 JDK에 대한 논쟁들이 해결하였기 때문입니다. 필자는 개인적으로 Java 11로 이동하기를 열망하고 있습니다. 필자의 조직에도 위의 사항들을 통한 설득을 하여 조직 또한 Java11로 이동하기를 희망합니다.

역자의 글 후기

Java에 대한 여러가지가 오가고 있는 만큼  기사 중 하나를 번역하였고, 해외에서는 위의 글과 같은 반응이 있음을 알 수 있었습니다. 꾸준히 Java에 대한 이야기가 해외에서도 오고 감을 알 수 있었던 글이었습니다.  다소 부족한 번역이었지만, 이 글을 읽음으로 Java의 흐름은 이렇게 가는구나 정도로만 가볍게 봐주시면 감사하겠습니다.


Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.