What Every Spring Developer Should Know About Jakarta EE by Ivar Grimstad @ Spring I/O 2025

 

What Every Spring Developer Should Know About Jakarta EE by Ivar Grimstad @ Spring I/O 2025

https://www.youtube.com/watch?v=8j9W573EhtE

 

 

slide

https://speakerdeck.com/ivargrimstad/what-spring-developers-should-know-about-jakarta-ee

What Spring Developers Should Know About Jakarta EE

 

 

Jakarta EE는 사양(specifications)들의 모음이며, Spring Framework는 내부적으로 많은 Jakarta EE API에 의존합니다. Jakarta EE 9의 javax.* -> jakarta.* 네임스페이스 전환과 Jakarta EE 11의 현대화(예: Jakarta Data, Virtual Threads 지원 등)는 Spring 개발자에게 직접적인 영향이 있으므로 핵심 사양과 상호운용 지점을 이해해야 한다.

---

분석 목차

1. 발표 배경과 메시지
2. 역사(Enterprise Java의 진화)
3. Jakarta EE의 본질: 사양(standards)과 구현(implementations)
4. javax.* → jakarta.*가 남긴 영향
5. Spring과 Jakarta EE의 관계: 의존성 맵
6. Jakarta EE 11의 핵심 변경점 요약
7. 주요 사양별 상세 설명 (CDI, Servlet, JAX-RS, Persistence, Transactions, Security 등)
8. Jakarta Data 1.0 깊게 보기
9. Virtual Threads와 Concurrency 관련 변경
10. CDI vs Spring DI 비교 (코드 레벨)
11. REST: JAX‑RS vs Spring MVC/WebFlux
12. 트랜잭션과 영속성: Jakarta Persistence vs Spring Data/JPA
13. 보안: Jakarta Security와 Spring Security의 경계
14. 배포/런타임: 애플리케이션 서버 vs Spring Boot 실행 모델
15. 마이그레이션 및 네임스페이스 전환 체크리스트
16. 호환성 문제와 해결 패턴 (classpath, library shading 등)
17. 데모/AI 시연 요약(발표 내용 기반)
18. 실무 권장사항 (단계별 액션 플랜)
19. 코드 스니펫: 변환 예시와 상호운용 예시
20. 테스트 전략: TCK, 통합 테스트, 컨테이너 테스트
21. 운영/모니터링 관점에서의 차이
22. 커뮤니티와 리소스(권장 읽기/도구)
23. FAQ: 자주 묻는 질문 정리
24. 결론 및 다음 단계

---

1) 발표 배경과 핵심 메시지

• Ivar는 Spring 개발자들에게 Jakarta EE의 최근 변화(특히 네임스페이스 전환과 Jakarta EE 11)를 이해하면 기존 Spring 코드의 안정성 확보와 새로운 기능(예: Jakarta Data, Virtual Threads) 활용에 유리하다고 주장합니다.
• 발표는 사양의 역할, Spring이 내부적으로 어떤 Jakarta EE API에 의존하는지, 그리고 Jakarta EE 11의 주요 개선점을 중심으로 구성되어 있습니다.

2) 역사(Enterprise Java의 진화)

• 1990년대부터 Java는 서버사이드에도 광범위하게 사용되었고, J2EE → Java EE → Jakarta EE로 이어지는 과정에서 표준화와 구현 생태계가 발전했습니다. 발표자는 이 역사적 맥락을 짧게 상기시키며, 오늘날의 위치를 설명합니다.

3) Jakarta EE의 본질: 사양 vs 구현

• Jakarta EE는 "프레임워크"가 아니라 사양(specifications) 이며, 사양 문서(TCK, API, 문서)가 중심입니다. 실제로 동작하는 것은 각 사양을 구현한 여러 구현체(예: Payara, OpenLiberty, WildFly, TomEE, Helidon 등)입니다.
• 이 관점은 Spring 개발자가 Jakarta EE를 단순히 경쟁자로 보지 말고, 상호보완적 기술 스택으로 이해해야 한다는 메시지로 연결됩니다.

4) javax.* → jakarta.* 네임스페이스 전환의 영향

• Jakarta EE 9에서의 네임스페이스 전환은 생태계 전체에 큰 파급을 남겼습니다. 기존 javax.persistence, javax.servlet 등 패키지명을 jakarta.persistence, jakarta.servlet로 바꾸어야 하는 점은 라이브러리 호환성 이슈를 야기했습니다.
• Spring 개발자는 이미 많은 라이브러리와 설정에서 jakarta.* 네임스페이스가 표준이 되어가는 과정을 체감하고 있으며, 마이그레이션 전략을 준비해야 합니다.

5) Spring과 Jakarta EE의 관계: 의존성 맵 (핵심 포인트)

• SpeakerDeck에서 지적하는 바와 같이 Spring Framework 자체가 생각보다 많은 Jakarta EE API에 의존합니다: 예를 들어 jakarta.annotation, jakarta.inject (Dependency Injection 표준), jakarta.transaction, jakarta.persistence 등. 이 때문에 Jakarta EE의 변화는 Spring 생태계에도 파급됩니다.

6) Jakarta EE 11의 핵심 변경점 (요약)

• Jakarta Data 1.0 추가: Spring Data와 유사한 저장소 레이어를 표준화하려는 시도.
• Java 21 기능 지원 강화(예: Virtual Threads): Concurrency 사양 업데이트로 더 쉽게 Virtual Threads를 활용할 수 있게 됨.
• 여러 사양의 업데이트 및 TCK 현대화: TCK(Test Compatibility Kit)를 재구성하여 검증과 온보딩을 개선.
• (참고: Jakarta EE 공식 릴리스 노트에서 자세한 변경 항목 확인 권장)

7) 주요 사양별 상세 설명

• CDI (Contexts and Dependency Injection)
  • CDI Lite와 표준 CDI의 차이.
  • Spring의 DI와 비교했을 때의 장단점(예: 컨텍스트 범위, 인터셉터, 확장 포인트).
• Servlet / Jakarta RESTful Web Services (JAX-RS)
  • JAX-RS는 REST API를 위한 표준이며, Spring MVC/WebFlux와 비교되는 점(애노테이션, 필터/인터셉터 모델, 비동기 처리 방식).
• Persistence (Jakarta Persistence / JPA)
  • 엔티티 관리와 영속성 컨텍스트, 트랜잭션 경계 관리.
• Transactions (JTA / jakarta.transaction)
  • Container-managed transactions vs Spring Programmatic/Declarative transaction management.
• Security (Jakarta Security)
  • Jakarta Security가 표준화한 인증·인가 메커니즘과 Spring Security의 풍부한 기능 비교.

8) Jakarta Data 1.0 깊게 보기

• Jakarta Data는 Repository 인터페이스 스타일을 표준으로 정의하여 CRUD 및 쿼리 메서드 작성을 단순화하려는 사양입니다.
• Spring Data와의 유사성 때문에, Spring 개발자들은 Jakarta Data를 사용하면 일부 코드(특히 레포지토리 계층)를 표준 API로 옮길 수 있는 이점이 있습니다.
• 예시(의사 코드):

// Jakarta Data - 의사 예시

import jakarta.data.repository.Repository;

 

public interface PersonRepository extends Repository<Person, Long> {

Optional<Person> findByEmail(String email);

}

 

Jakarta Data는 아직 에코시스템에서 성숙하는 단계이므로, 프로덕션 채택 전 구현체 호환성(어떤 앱 서버/라이브러리가 Jakarta Data를 지원하는지)을 검증해야 합니다.

9) Virtual Threads와 Concurrency 관련 변경

• Jakarta EE 11은 Java 21의 Virtual Threads와 연계하여 Concurrency 사양을 개선했습니다. 이는 고동시성 트래픽 처리 시 쓰레드 관리 비용을 줄여 성능/확장성에 이점을 줄 수 있습니다.
• Spring에서는 Virtual Threads(프로젝트 Loom) 지원을 위한 Spring Framework의 업데이트와 연동하는 방법을 고려해야 합니다.

10) CDI vs Spring DI (비교와 상호운용 예)

• 공통점: 둘 다 의존성 주입, 범위(Scopes), 라이프사이클 관리, 인터셉터/어드바이스 같은 확장 포인트를 제공.
• 차이점: 애노테이션 이름/관습, 확장성 포인트(CDI Extension API 등), Bean 발견(automatic scanning) 방식 등에 차이가 있음.
• 상호운용: Spring 컨텍스트와 Jakarta CDI를 연동해야 할 경우, 브리지 패턴(예: CDI Bean을 Spring Bean으로 래핑) 또는 마이크로서비스 수준의 분리(한 서비스는 Spring, 다른 서비스는 Jakarta EE) 전략을 권장.

11) REST: JAX‑RS vs Spring MVC/WebFlux

• JAX‑RS는 표준으로서 다양한 런타임에서 동일한 코드 스타일로 동작할 수 있게 해준다.
• Spring은 편의 기능(HandlerMethodArgumentResolver, 컨버터, 강력한 DI 통합)을 제공하여 생산성이 높다.
• 선택 기준: 조직의 표준화 필요성, 런타임(애플리케이션 서버) 사용 여부, 팀의 숙련도.

12) 트랜잭션과 영속성

• Jakarta Transaction(JTA)은 분산 트랜잭션을 표준화한다. Spring은 PlatformTransactionManager 추상화를 통해 다양한 트랜잭션 전략을 지원한다.
• JPA 엔티티와 영속성 컨텍스트 다루는 방식은 기본적으로 동일하지만, 설정(데이터 소스 바인딩, 트랜잭션 관리자 설정 등)에 차이가 있다.

13) 보안

• Jakarta Security는 표준 인증/인가 API를 제공한다. Spring Security는 더 많은 기능과 세부 설정을 제공하지만, 표준을 지원하면 상호운용성 측면에서 장점이 있다.

14) 배포/런타임 모델 비교

• Jakarta EE: 전통적 애플리케이션 서버(또는 Jakarta EE 호환 경량 서버)에서 배포.
• Spring Boot: 임베디드 톰캣/넷티/톰캣 기반 실행 모델로 배포.
• 상호운용성 전략으로는 fat-jar 방식의 Spring Boot 앱에 Jakarta EE 라이브러리를 의존시키거나, 애플리케이션 서버에 Spring 애플리케이션을 배포하는 패턴이 있다.

15) 마이그레이션 및 네임스페이스 전환 체크리스트

• 프로젝트 내 javax.* 의존성 검색 및 jakarta.*로 대체(또는 호환 라이브러리 사용).
• 의존 라이브러리(타사 라이브러리 포함)가 jakarta.*를 지원하는지 확인.
• 빌드/CI에서 module-info 또는 모듈 설정이 있다면 네임스페이스 변경에 따른 영향 점검.
• 테스트: 단위 테스트 + 통합 테스트(실제 컨테이너에서 실행)로 검증.

16) 호환성 문제와 해결 패턴

• Shading / Relocation: 라이브러리가 아직 javax.*만 제공한다면, shading으로 네임스페이스를 변경하는 방법(하지만 위험성 존재).
• 버전 동기화: 애플리케이션 서버와 라이브러리(예: Hibernate, EclipseLink)의 Jakarta 버전 일치.
• 멀티 모듈 분리: 새로운 모듈은 jakarta.*로 작성하고, 레거시 모듈은 점진적으로 마이그레이션.

17) 데모/AI 시연 요약 (발표에서 언급된 데모 요약)

• 발표자 슬라이드/트랜스크립트에 따르면 단순한 데모(코드 변환/호환성 예)와 함께 AI(코드 변환 보조) 활용 사례가 짧게 언급되었습니다. 실무에서는 codemods 또는 AI 기반 코드 변환 도구를 사용하여 대규모 네임스페이스 변경을 보조할 수 있습니다.

18) 실무 권장사항 (단계별)

1. 의존성 스캔: javax.* 사용 지점 전수 조사.
2. 테스트 파이프라인 강화: 컨테이너 기반 통합 테스트 추가.
3. Jakarta EE 11 기능(예: Jakarta Data, Virtual Threads) 도입 검토: PoC를 통해 성능/생산성 확인.
4. 운영시 모니터링: 스레드/쓰레드풀 관련 메트릭(특히 Virtual Threads 도입 시) 모니터링 추가.

19) 코드 스니펫: 변환 예시와 상호운용 예시

• 간단한 네임스페이스 변환 예

// Before

import javax.persistence.Entity;

 

// After

import jakarta.persistence.Entity;

 

• Jakarta Data 스타일 레포지토리 (의사 코드)

import jakarta.data.repository.Repository;

public interface BookRepository extends Repository<Book, Long> {

List<Book> findByAuthor(String author);

}

 

• Spring에서 JAX-RS 리소스 호출 예 (상호운용)

@Path("/api/books")

@Produces(MediaType.APPLICATION_JSON)

public class BookResource {

@GET

public List<Book> list() { ... }

}

// Spring 앱에서 JAX-RS 구현체(예: Jersey)를 의존시켜 함께 동작시킬 수 있음

 

20) 테스트 전략: TCK, 통합 테스트, 컨테이너 테스트

• Jakarta EE는 TCK를 통한 규격 검증이 중요하고, Spring 개발자는 자신의 앱이 사용하는 Jakarta API를 컨테이너 환경에서 테스트해야 함.
• Testcontainers, Arquillian 같은 도구를 사용하여 실제 런타임과 유사한 환경에서 테스트 권장.

21) 운영/모니터링 관점

• Virtual Threads 도입 시 기존 스레드 풀 지표(활성 스레드 수, 큐 길이 등) 해석 방식이 바뀔 수 있으므로 모니터링 대시보드와 알람 설정을 재검토해야 함.

22) 커뮤니티와 리소스

• Jakarta EE 공식 사이트와 Jakarta EE 11 릴리스 문서, SpeakerDeck(발표 자료), Spring 이슈/릴리스 노트, Eclipse Foundation 블로그를 정기적으로 모니터링할 것.

23) FAQ (요약)

• Jakarta EE는 Spring을 대체하는가? No. 둘은 목적과 접근이 다르며 상호보완적이다.
• 언제 마이그레이션해야 하는가? 라이브러리/컨테이너 호환성, 보안 업데이트, 새로운 Jakarta EE 기능 필요성에 따라 단계적으로.

24) 결론 및 다음 단계

• 발표의 핵심은 "Spring 개발자라면 Jakarta EE의 변화(특히 Jakarta EE 11)를 모니터링하고, 필요한 부분을 실무에 반영하라" 입니다.
• 다음 단계: 위의 체크리스트를 바탕으로 조직의 프로젝트에 대해 PoC 수행(특히 Jakarta Data와 Virtual Threads 관련).

 

 

 

TCK 란?

TCK는 Technology Compatibility Kit 

특정 기술 표준(Specification)을 구현한 제품(예: 자바 플랫폼 구현체, Jakarta EE 애플리케이션 서버 등)이 해당 표준을 정확하고 완전하게 준수하는지 검증하기 위해 사용되는 **테스트 스위트(Test Suite)**와 관련 문서 및 도구들

 

TCK의 핵심 목적은 호환성과 표준 준수를 보장하는 것입니다.

예 : Java SE/EE (Jakarta EE): Oracle, IBM, Red Hat 등 여러 회사가 자바/Jakarta EE 표준을 구현할 때, TCK를 통과해야만 공식적으로 해당 표준을 준수한다고 인정받을 수 있습니다. 예를 들어, 웹로직(WebLogic), 제이보스(JBoss/WildFly), 아파치 톰캣(Apache Tomcat) 등이 Jakarta EE의 특정 버전을 구현했다고 주장하려면 해당 버전의 TCK를 통과해야 합니다

Google Gemini

 

 

 

CDI란 

CDI는 Contexts and Dependency Injection의 약자
Jakarta EE 플랫폼의 핵심 사양입니다. 
애플리케이션 컴포넌트의 라이프사이클을 관리하고 타입-안전한(type-safe) 의존성 주입 (Dependency Injection, DI) 서비스를 제공합니다.

 

CDI는 자바 엔터프라이즈 환경에서 컴포넌트 간의 느슨한 결합을 촉진하고, 애플리케이션 컴포넌트 (Beans)의 생명주기(Lifecycle) 및 **컨텍스트(Context)**를 관리하는 표준화된 방법을 제공합니다.

특징	설명
의존성 주입 (DI)	$@Inject$ 애너테이션을 사용하여 필요한 의존성을 컨테이너가 자동으로 주입합니다. 생성자, 필드, 메서드 등에 적용 가능합니다.
컨텍스트 및 범위 (Scopes)	빈(Bean)이 존재하는 컨텍스트와 **범위(Scope)**를 정의합니다. $@RequestScoped$, $@SessionScoped$, $@ApplicationScoped$ 등 Jakarta EE의 다양한 환경(웹, 트랜잭션 등)에 맞는 표준화된 범위를 제공합니다.
타입 안전성 (Type Safety)	한정자(Qualifier) 애너테이션을 사용하여 주입 대상을 명확하게 지정함으로써, 주입 시점에 컴파일러가 오류를 잡아낼 수 있게 합니다.
인터셉터 및 데코레이터	빈의 메서드 호출 전후에 **횡단 관심사(Cross-Cutting Concerns)**를 적용하거나 빈의 기능을 동적으로 강화할 수 있는 표준화된 메커니즘을 제공합니다.

 

 

 

 주요 Jakarta EE 사양 개요

CDI는 아래와 같은 Jakarta EE의 다른 주요 사양들과 긴밀하게 통합되어 애플리케이션 서버 환경에서 동작합니다.

사양	약자	역할
Contexts and Dependency Injection	CDI	컴포넌트의 라이프사이클 관리 및 의존성 주입의 표준.
Servlet		웹 요청 처리 및 응답 생성을 위한 저수준(low-level) 표준. 모든 웹 기반 Jakarta EE 기술의 기반.
RESTful Web Services	JAX-RS	RESTful 웹 서비스를 쉽게 개발할 수 있도록 하는 표준. CDI 빈으로 구현되어 의존성 주입을 활용합니다.
Persistence	JPA (Java Persistence API)	객체-관계 매핑(ORM) 표준. 자바 객체를 관계형 데이터베이스에 저장하고 조회하는 방법을 정의합니다.
Transactions	JTA (Java Transaction API)	분산 환경을 포함한 트랜잭션 관리 표준. $@Transactional$ 같은 애너테이션을 통해 선언적 트랜잭션을 지원합니다.
Security	Jakarta Security	인증(Authentication) 및 인가(Authorization)를 처리하는 표준. 웹 및 엔터프라이즈 환경에서 보안을 통합합니다.

 

 

CDI vs Spring DI: 주요 차이점

구분	CDI (Jakarta EE)	Spring DI (Spring Framework)
기본 애너테이션	$@Inject$, $@Named$, $@Produces$	$@Autowired$, $@Component$, $@Bean$
컨텍스트 범위	표준화된 웹/EE 범위: $@RequestScoped$, $@SessionScoped$, $@ConversationScoped$ 등.	주로 $@Scope("prototype")$, $@Scope("singleton")$, 웹 범위($@RequestScope$, $@SessionScope$)는 Spring Web이 제공.
빈 발견 방식	기본적으로 자동 스캔 ($beans.xml$ 파일이 없으면 Implicit Bean Archive) 또는 명시적 빈 아카이브 ($beans.xml$이 있는 경우).	$@ComponentScan$ 애너테이션으로 지정된 패키지 내의 $@Component$ 등을 스캔.
확장성	강력한 CDI Extension API를 통해 컨테이너의 라이프사이클에 깊숙이 관여하여 동적 기능 추가 가능.	BeanPostProcessor, BeanFactoryPostProcessor 등의 인터페이스를 통한 확장.
사용 환경	주로 Jakarta EE 호환 애플리케이션 서버 (WildFly, OpenLiberty, GlassFish) 내에서 표준으로 사용.	독립형 또는 내장형 컨테이너 (Tomcat/Jetty)에서 주로 사용. 경량화 및 유연성이 강점.

 

 

Google Gemini