Eclipse GlassFish가 달라졌다 — 자바 개발자가 다시 주목해야 할 이유

그 GlassFish가 아직 살아있었어?

"GlassFish"라는 이름을 들으면 어떤 생각이 드시나요? 아마 많은 분들이 "아, 그거 옛날에 쓰던 거 아니야?" 하실 것 같아요. 맞아요, GlassFish는 한때 자바 EE의 레퍼런스 구현체로 유명했지만, 상업적 지원이 끊기면서 사실상 잊혀진 프로젝트처럼 여겨졌거든요. 그런데 Eclipse 재단 아래에서 꾸준히 개발이 이어져온 Eclipse GlassFish가 최근 상당히 의미 있는 변화를 이뤄냈어요.

GlassFish의 역사를 간단히 짚어볼게요

이게 뭐냐면, GlassFish는 원래 Sun Microsystems가 만든 자바 애플리케이션 서버예요. 자바 EE(지금은 Jakarta EE라고 불러요) 스펙의 참조 구현체, 그러니까 "이 스펙대로 만들면 이렇게 동작해야 한다"는 걸 보여주는 공식 샘플 같은 역할이었죠. 2010년에 Oracle이 Sun을 인수하면서 GlassFish도 Oracle 소유가 됐는데, 2017년에 Eclipse 재단으로 이관됐어요.

문제는 이관 과정이 순탄치 않았다는 거예요. Oracle 시절의 코드를 그대로 가져왔는데, 내부적으로 엄청난 기술 부채가 쌓여 있었거든요. 오래된 의존성, 레거시 API, 테스트 커버리지 부족 등등. 그래서 지난 몇 년간 Eclipse GlassFish 팀은 겉으로 화려한 새 기능을 추가하기보다 내부를 갈아엎는 작업에 집중해왔어요.

무엇이 달라졌나

최신 Eclipse GlassFish의 핵심 변화는 크게 세 가지로 볼 수 있어요.

첫 번째는 Jakarta EE 최신 스펙 지원이에요. Jakarta EE 11을 완전히 지원하면서 최신 자바 표준을 따라가고 있어요. Jakarta EE가 뭐냐면, 예전 자바 EE가 이름을 바꾼 거예요. Oracle에서 Eclipse로 넘어오면서 "Java"라는 상표를 쓸 수 없게 되어서 Jakarta라는 새 이름을 쓰게 된 건데요, 단순히 이름만 바뀐 게 아니라 패키지 네임스페이스가 javax.에서 jakarta.로 전면 변경됐어요. 이 마이그레이션이 꽤 큰 작업이었는데, GlassFish가 이걸 완전히 소화했다는 거죠.

두 번째는 내부 아키텍처의 현대화예요. HK2라는 자체 의존성 주입 프레임워크 대신 표준적인 방식을 더 적극적으로 채용하고 있고, 빌드 시스템도 정비했어요. 개발자 입장에서 직접 체감하기는 어렵지만, 이건 프로젝트의 장기적인 건강성과 직결되는 부분이에요. 기반이 튼튼해야 위에 새로운 걸 쌓을 수 있으니까요.

세 번째는 성능 개선과 경량화예요. 불필요한 레거시 컴포넌트를 걷어내고 시작 시간을 줄였어요. 클라우드 네이티브 환경에서 컨테이너로 돌리려면 빠른 기동 시간이 중요하거든요.

경쟁 환경은 어떤가

솔직히 말하면, 자바 애플리케이션 서버 시장에서 GlassFish의 위치는 아직 도전적이에요. 대부분의 한국 기업에서는 Spring Boot를 내장 톰캣과 함께 쓰고 있고, 풀스택 애플리케이션 서버가 필요한 경우에는 WildFly(구 JBoss)나 상용인 WebLogic, WebSphere를 쓰는 경우가 많죠.

그런데 GlassFish만의 고유한 가치가 있어요. Jakarta EE 스펙의 레퍼런스 구현체라는 점이에요. 새로운 Jakarta EE 기능이 어떻게 동작해야 하는지를 가장 정확하게 보여주는 서버가 바로 GlassFish거든요. Jakarta EE 스펙을 공부하거나, 스펙 준수 여부를 테스트해야 하는 상황이라면 GlassFish가 가장 좋은 선택이에요.

또한 Payara라는 상용 서버가 GlassFish를 기반으로 만들어졌다는 점도 알아두면 좋아요. Payara를 쓰는 조직이라면 GlassFish의 변화가 곧 자신들의 스택에도 영향을 미치게 되는 셈이죠.

한국 개발자에게 어떤 의미가 있을까

한국 자바 생태계는 Spring 중심으로 돌아가고 있어서, GlassFish를 프로덕션에 당장 도입하겠다는 분은 많지 않을 거예요. 하지만 몇 가지 실질적인 시사점이 있어요.

우선, Jakarta EE의 방향성을 파악하는 데 좋은 참고점이에요. Spring도 내부적으로 Jakarta EE 스펙에 많이 의존하거든요. jakarta.servlet, jakarta.persistence 같은 건 Spring 개발자도 매일 쓰고 있죠. GlassFish가 새 스펙을 구현하는 과정을 보면 Jakarta EE가 어디로 향하고 있는지 감을 잡을 수 있어요.

그리고 레거시 시스템 현대화의 좋은 사례이기도 해요. 거대한 레거시 코드베이스를 점진적으로 개선하면서도 하위 호환성을 유지하는 전략은 어떤 프로젝트에서든 배울 점이 있거든요. 특히 javax에서 jakarta로의 마이그레이션은 한국에서도 많은 기업이 겪고 있는 과제인데, GlassFish가 이를 어떻게 처리했는지 살펴보면 참고가 될 거예요.