[Java] 자바 역사 가이드: SE와 EE(Jakarta EE) 통합 타임라인과 대전환 비화
저도 정리도 할겸 해서 Java에 대해서 글을 써보고 있습니다.
재미가 있으실지는 모르겠지만, 읽으시는 분들이 재미가 있어야 할텐데요 ^^
저는 정리하면서 오 그랬지를 외치고 있습니다.
그럼 본격적으로 글을 시작합니다.
[Java] 자바의 탄생 배경과 역사, C언어와의 차이점 총정리 / https://www.steemit.com/kr/@talkit/java-c--ji3f9j
1. 서론: 가전제품 제어에서 전 세계 웹의 표준이 되기까지
오늘날 자바(Java)는 단순한 프로그래밍 언어를 넘어 전 세계 거대한 IT 인프라를 지탱하는 거대한 플랫폼입니다. "한 번 작성하면, 어디서나 실행된다(Write Once, Run Anywhere)"라는 강력한 철학을 바탕으로 지난 30년간 수많은 격변을 겪으며 발전해 왔습니다.
자바의 역사를 이해하는 것은 단순히 과거의 기록을 보는 것을 넘어, 현대 엔터프라이즈 소프트웨어 아키텍처가 왜 지금과 같은 모습으로 자리 잡았는지 이해하는 핵심 열쇠입니다. 개인용 개발을 위한 표준 에디션(Java SE)과 대규모 기업 시스템을 위한 에디션(Java EE)이라는 두 축이 시대의 흐름에 따라 어떻게 발맞추어 성장하고 변천해 왔는지, 그 흥미진진한 역사의 타임라인과 숨겨진 비화를 정리해 드립니다.
2. 본론
① Java SE & Java EE 통합 연혁 타임라인
자바의 표준 스펙(SE)과 기업용 분산 환경 스펙(EE)은 기술의 발전과 패러다임의 변화에 맞춰 유기적으로 결합하며 진화해 왔습니다. 최초의 버전부터 현재에 이르기까지의 핵심 마일스톤입니다.
- JDK 1.0 (1996): 최초의 공식 버전, 제임스 고슬링의 '오크(Oak)' 프로젝트에서 시작된 자바 언어의 탄생
- JDK 1.1 (1997): 내부 클래스, 데이터베이스 연동을 위한 JDBC, 컴포넌트 모델인 JavaBeans 도입
- J2SE 1.2 / J2EE 1.2 (1998~1999): 스윙(Swing) GUI 및 컬렉션 프레임워크 추가 / 최초의 기업용 스펙(Servlet, JSP 1.1) 표준화
- J2SE 1.4 / J2EE 1.4 (2002~2003): 정규표현식 및 비동기 NIO 지원 / 웹 서비스(Web Services) 기본 프로필 지원
- Java SE 5 / Java EE 5 (2004~2006): 제네릭, 열거형(Enum), 어노테이션 도입 / EJB 3.0 도입으로 기업용 개발의 복잡성 대폭 완화
- Java SE 6 / Java EE 6 (2006~2009): JVM 가비지 컬렉션 성능 향상 및 스크립트 지원 / 웹 프로필(Web Profile) 개념 및 CDI(의존성 주입) 최초 도입
- Java SE 7 / Java EE 7 (2011~2013): 다이아몬드 연산자 및 try-with-resources 추가 / HTML5 지원 파이프라인 구축 및 WebSocket 표준 채택
- Java SE 8 / Java EE 8 (2014~2017): 람다식, 스트림(Stream) API 혁신 / 오라클 주도의 마지막 기업용 버전, HTTP/2 지원 및 JSON-B 추가
- Java SE 11 / Jakarta EE 8 (2018~2019): 6개월 정기 출시 주기 정착 / 이클립스 재단으로 이관 후 첫 버전 (기능은 Java EE 8과 동일)
- Java SE 17 / Jakarta EE 9 (2021~2020): 봉인된 클래스 정식 추가 / 패키지 명칭 대전환 (
javax.*->jakarta.*변경) - Java SE 21 / Jakarta EE 10 (2023~2022): 가상 스레드(Virtual Threads) 도입으로 동시성 혁신 / 클라우드 네이티브 아키텍처 공식 지원
- Java SE 25 / Jakarta EE 11 (2025~2024): 최신 장기 지원(LTS) 버전으로 안정성 확보 / 가상 스레드 기술을 기업용 스펙에 본격 통합
- Java SE 26 (2026): 최신 버전, HTTP/3 지원 및 런타임 성능의 지속적인 개선
② Java EE에서 Jakarta EE로의 대전환과 상표권 분쟁 비화
자바가 전 세계 금융권과 대기업 시스템의 백엔드를 독점할 수 있었던 원동력은 Java EE였습니다. 하지만 2010년 오라클(Oracle)이 선 마이크로시스템즈를 인수하면서 자바 생태계에는 거대한 제약과 격변이 일어납니다. 오라클 체제 하에서 기업용 자바 표준의 발전이 정체되자, 오픈소스 커뮤니티는 더 개방적인 혁신을 요구했습니다. 결국 2017년, 오라클은 Java EE의 소스 코드와 운영 권한을 오픈소스 재단인 이클립스 재단(Eclipse Foundation)에 완전히 넘겨주기로 결정합니다.
그러나 이 아름다운 이관 과정 뒤에는 거대한 상표권 갈등이 숨어 있었습니다. 오라클이 소스 코드는 넘겼지만, 'Java'라는 브랜드 상표권만큼은 자신들의 소유라며 양도하지 않은 것입니다. 이로 인해 이클립스 재단은 기존의 명칭인 'Java EE'를 더 이상 사용할 수 없게 되었고, 소스 코드 내부에서 수십 년간 표준으로 사용되던 핵심 패키지 명칭인 java.*와 javax.* 역시 새로 업데이트하는 코드에 사용할 수 없게 되는 사상 초유의 제약을 받게 됩니다.
결국 이클립스 재단은 커뮤니티 투표를 거쳐 Java EE의 새 이름으로 Jakarta EE(자카르타 EE)를 공표합니다. 그리고 명칭만 바꾼 것에 그치지 않고, Jakarta EE 9에 이르러 소스 코드 내부의 핵심 API 경로를 javax.servlet.*에서 jakarta.servlet.* 형태로 통째로 바꾸는 대대적인 이주(Migration) 작업을 단행합니다.
이 변화는 초기에 전 세계 수많은 라이브러리와 프레임워크(대표적으로 스프링 부트 3.0 이상 버전)가 코드를 완전히 리팩토링해야 하는 극심한 호환성 진통을 유발했습니다. 하지만 결과적으로 오라클이라는 단일 기업의 독점적 제약에서 완전히 벗어나, 전 세계 개발자와 기업들이 함께 주도하는 진정한 의미의 '개방형 클라우드 네이티브 기업용 자바 표준'으로 완벽하게 재탄생하는 위대한 계기가 되었습니다.
3. 요약: 독점에서 개방으로, 쉼 없이 진화하는 자바 생태계
자바의 역사는 단순히 소프트웨어 버전 업그레이드의 기록이 아니라, 하드웨어의 한계와 기업의 독점 시도를 기술적 아키텍처와 커뮤니티의 힘으로 우아하게 해결해 온 투쟁의 역사입니다.
C/C++의 메모리 관리 한계를 극복하기 위해 가전제품 제어용 '오크' 언어로 출발한 자바는 웹의 폭발적인 성장과 함께 표준 스펙(SE)을 다져왔으며, 대규모 기업 환경을 겨냥한 EE 스펙을 통해 시장의 절대 강자로 군림했습니다. 비록 오라클 인수 이후 상표권 분쟁이라는 초유의 진통을 겪으며 javax 패키지를 jakarta로 통째로 바꾸는 아픔을 겪었지만, 이 계기를 통해 자바는 특정 기업의 전유물이 아닌 진정한 오픈소스 커뮤니티 중심의 '개방형 표준'으로 거듭날 수 있었습니다.
탄생한 지 30년이 넘은 지금도 최신 가상 스레드 기술(Virtual Threads)과 클라우드 네이티브 아키텍처를 적극 흡수하며 진화하고 있는 자바는, 앞으로도 오랫동안 전 세계 백엔드 생태계의 견고한 표준으로 자리를 지킬 것입니다.
관련글 :
[Java] 자바의 탄생 배경과 역사, C언어와의 차이점 총정리 / https://www.steemit.com/kr/@talkit/java-c--ji3f9j 🔗
자바가 아직도요? ㅠㅠ
0.00 SBD,
7.49 STEEM,
7.49 SP
[booming-kr-auto]
보팅 완료했습니다 🙌
자바는 앞으로도 잘 돌아가야 합니다. ㅎㅎㅎ
제가 저걸로 밥먹고 살고 있어서 ^^
Upvoted! Thank you for supporting witness @jswit.