Eclipse Jetty 지원 종료(EOL): 버전, 업그레이드 경로 및 옵션

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

Jetty 8, 9, 10, 11은 모두 지원 종료되었습니다. 2026년 1월 1일을 기점으로 Webtide와 Jetty 프로젝트는 Maven Central에 9, 10, 11 계열의 릴리스를 더 이상 배포하지 않게 되었으므로, 새로운 CVE에 대한 수정 패치는 더 이상 공개 채널을 통해 제공되지 않습니다.
현재 커뮤니티 지원이 계속되고 있는 버전은 Jetty 12.0과 12.1뿐입니다. Jetty 12.1이 현재 최신 버전이며, Webtide 측은 12.0에 대한 업데이트가 2026년 중 중단될 것이라고 밝혔으나, 아직 구체적인 날짜는 확정하지 않았습니다.
Jetty 12로 전환하는 것은 단순한 버전 업그레이드를 넘어서는 작업입니다. JDK 17이 필요하며, 대상 EE 환경에 따라 javax에서 jakarta로의 마이그레이션이 필요하고, 임베디드 Spring Boot 애플리케이션의 경우 Spring Boot 3.2 이상으로의 전환이 필요합니다.
아직 마이그레이션을 진행할 수 없다면, 현실적인 대안으로는 공급업체가 지원하는 연장 지원, 자체 유지보수를 통한 백포트, 또는 Jetty를 대체하는 방법이 있습니다. 연장 지원은 대개 가장 수고가 덜 드는 과도기적 해결책이며, 자체 유지보수는 팀들이 과소평가하기 쉬운 방법입니다.

지난 분기에 모든 패치를 적용했습니다. 그런데 의존성 스캔 결과, 2021년 이후로 아무도 손대지 않은 서비스의 3단계 깊숙한 곳에 묻혀 있던 jetty-server 9.4.x가 문제로 표시되었고, 필요한 수정된 버전은 Maven Central에 없습니다. 이것이 2026년 Eclipse Jetty의 EOL(지원 종료) 현황입니다. Jetty 9, 10, 11은 모두 지원이 종료되었으며, 2026년 1월 1일부터 해당 프로젝트는 더 이상 해당 버전에 대한 릴리스를 공개적으로 배포하지 않습니다.

이 가이드에서는 지원이 종료된 버전이 무엇인지, 현재 해당 버전을 사용 중인지 확인하는 방법, 실제 위험이 어떤지, 그리고 가장 깔끔하게 전환하는 방법에 대해 다룹니다.

Eclipse Jetty는 지원 종료 단계에 접어들었나요?

네, 그리고 이 일정에 포함된 변수들은 대부분의 팀이 예상했던 것보다 훨씬 많습니다. Jetty 10과 11은 2024년 1월 1일에 커뮤니티 지원이 종료되었으며, 2025년 1월부로 제품 수명 종료(EOL)가 선언되었습니다. Jetty 9는 2022년 6월 1일에 커뮤니티 지원이 종료되었으며, 2025년 1월에 EOL이 예정되어 있었으나, 2025년 8월에 9.4.58.v20250814 버전이 출시될 때까지 고객 후원 보안 릴리스가 계속 제공되었습니다.

위험 평가 기준을 바꿔야 할 시점은 비교적 최근입니다. 2026년 1월 1일부터 Webtide와 Jetty 프로젝트는 더 이상 Maven Central이나 그 밖의 공개 저장소에 Jetty 9, 10, 11 릴리스를 배포하지 않습니다. 따라서 오늘날 12 이전 버전에 대한 CVE가 공개되더라도, 해당 문제가 수정된 빌드가 이미 존재하는 경우가 많습니다. 다만 여러분의 빌드 환경에서는 이를 확보할 수 없는 것뿐입니다.

Jetty 12.0과 12.1만이 커뮤니티 지원 대상 버전이며, 12.0은 지원 종료 예고 상태입니다.

참고: Jetty 9는 사용자가 별도로 설치하지 않아도 귀하의 환경에서 실행되고 있을 가능성이 가장 높은 버전입니다. Apache Solr, Spark, ActiveMQ, Hadoop의 모든 버전에는 Jetty가 내장되어 제공되며, Jetty Maven 플러그인이 빌드에 이를 포함시키기 때문에, Jetty는 의도적인 선택이라기보다는 번들 또는 전이적 의존성으로 빌드에 포함되는 경향이 있습니다.

주요 Eclipse Jetty 버전 및 출시일

버전과 상태 간의 대응 관계는 대부분의 독자들이 실제로 필요로 하는 정보이므로, 이를 먼저 소개합니다. 이 내용은 2026년 7월 기준 최신 정보이며, Eclipse Jetty의 공식 공지 및 릴리스 목록에서 발췌한 것으로, 2026년 7월 기준 최신 정보입니다.

버전	최신 출시 목록	EOL 상태	필수 Java SE
8번 부두	8.2.0.v20160908	2014년부터 단종됨	자바 6
Jetty 9.4	9.4.58.v20250814 (2025년 8월)	EOL; 커뮤니티 지원은 2022년 6월에 종료되었습니다.	자바 8
제티 10	10.0.26	EOL; 커뮤니티 지원은 2024년 1월에 종료되었습니다.	자바 11
제티 11	11.0.26	EOL; 커뮤니티 지원은 2024년 1월에 종료되었습니다.	자바 11
Jetty 12.0	12.0.37 (2026년 7월)	지원 중; 2026년에 업데이트가 종료될 예정	자바 17
Jetty 12.1	12.1.11 (2026년 7월)	지원됨 (현재 줄)	자바 17

두 번째 열에 대해 한 가지 주의할 점이 있습니다. EOL(지원 종료) 제품군에는 9.4.60 이상, 10.0.28 이상, 11.0.28 이상과 같이 더 높은 고정 버전 번호가 존재합니다. 이러한 빌드는 Maven Central에 공개되지 않기 때문에, 표가 해당 지점에서 끝나는 것입니다.

사용 중인 Eclipse Jetty가 EOL(지원 종료) 버전인지 확인하는 방법

서로 다른 확인 절차가 필요한 두 가지 상황이 있습니다. 독립형 Jetty는 찾기 쉽습니다. 임베디드 Jetty는 팀들이 골치 아파하는 부분입니다.

Jetty를 독립형 서버로 실행하는 경우, Jetty에 직접 다음과 같이 요청해 보세요:

java -jar $JETTY_HOME/start.jar –version

그러면 정확한 빌드 정보가 출력됩니다. 예를 들어 jetty-12.1.11와 같이 정확한 빌드 버전을 출력합니다. 또한 Jetty 홈 디렉토리 내의 파일을 확인할 수도 있습니다.

Jetty가 Spring Boot 애플리케이션, Solr 인스턴스 또는 어떤 팻 JAR 파일에든 내장되어 있는 경우, 해당 버전은 의존성 트리에서 숨겨집니다. Maven의 경우:

mvn dependency:tree -Dincludes=’org.eclipse.jetty*’

끝에 오는 와일드카드는 그대로 두십시오. Jetty 12는 환경 아티팩트를 다음과 같은 별도의 그룹 ID로 배포합니다. org.eclipse.jetty.ee10와 같은 별도의 그룹 ID로 배포하며, org.eclipse.jetty 와 같은 정확한 일치 필터를 사용하면 해당 아티팩트가 보고되지 않습니다. 필터 구문으로 골치 아파하고 싶지 않다면, mvn dependency:tree | grep -i jetty 를 실행하면 모든 항목을 확인할 수 있습니다.

Gradle의 경우:

./gradlew dependencies | grep -i jetty

그리고 다른 제품 내부에 디스크에 저장된 Jetty JAR 파일을 파악하려면:

find / -name ‘jetty-*.jar’ 2>/dev/null

다음 대신 실제 애플리케이션 루트 경로를 지정하세요. / 대신 실제 애플리케이션 루트 디렉터리를 지정하십시오. 또한, 대형 JAR 파일이나 컨테이너 레이어 내에 포함된 JAR 파일은 별도의 파일로 전혀 표시되지 않는다는 점을 명심하십시오.

출력 결과에 9.x, 10.x 또는 11.x가 표시되면 EOL(지원 종료) 버전의 Jetty를 실행 중인 것입니다. 12.0.x 또는 12.1.x가 표시되면 지원 대상 버전을 사용 중이지만, 12.0 버전에 대한 업데이트는 올해 중단될 예정이라는 점에 유의하시기 바랍니다.

지원 종료(EOL)된 Eclipse Jetty를 계속 실행하면 어떻게 될까요?

이 위험은 이론적인 것이 아니며, 단순히 눈에 보이는 버전 문제에만 국한되지 않습니다. 이 위험은 세 가지 측면으로 나뉩니다. 바로 공개 저장소에 수정 패치가 반영되지 않은 새로운 CVE, Jetty의 오랜 HTTP 파싱 버그 이력, 그리고 지원이 중단된 소프트웨어를 실행함으로써 발생하는 보안 감사상의 취약점입니다.

공개 패치가 없는 새로운 CVE

오늘 공개된 Jetty 9, 10 또는 11의 취약점에 대해서는 Maven Central을 통해 수정 버전이 배포되지 않습니다. 이것이 2026년 1월 변경 사항이 가져오는 실질적인 결과이며, 보통은 수정 패치가 존재하기 때문에 이 문제는 처음 들었을 때보다 훨씬 더 이상한 문제입니다.

CVE-2026-2332 이것이 명확한 예시입니다. 이는 Jetty의 청크 전송 인코딩 파서에서 발생하는 HTTP 요청 스머글링 결함입니다. Jetty는 따옴표로 묶인 문자열 내의 CRLF를 오류로 처리하지 않고 청크 확장자 구문 분석의 끝으로 간주하여, 공격자가 Jetty와 프론트엔드 프록시 간의 동기화를 깨뜨릴 수 있게 합니다. 2026년 4월 14일 공개되었으며, CVSS 점수는 7.4입니다. 이 취약점은 9.4.0부터 9.4.59까지, 10.0.0부터 10.0.27까지, 11.0.0부터 11.0.27까지, 12.0.0부터 12.0.32까지, 그리고 12.1.0부터 12.1.6까지의 버전에 영향을 미쳤습니다. 공개 패치는 12.0.33 및 12.1.7에 반영되었습니다. 9.4.60, 10.0.28, 11.0.28과 같은 지원 종료(EOL) 버전용 수정 빌드도 존재하지만, Maven Central에는 포함되어 있지 않습니다. Jetty의 공식 공지사항에도 이와 같은 내용이 명시되어 있으며, TuxCare를 비롯한 상용 공급업체를 통해 지원 종료 패치를 구할 수 있다고 안내하고 있습니다.

그리고 또다시 같은 일이 발생했습니다. 조기 반환 후에도 ThreadLocal 상태가 유지되어 발생하는 JASPI 인증 우회 취약점인 CVE-2026-5795는 12.0.34 및 12.1.8 버전에서 공개적으로 수정되었으며, 9.4.61, 10.0.29, 11.0.29 버전은 동일한 확장 지원 채널을 통해서만 제공됩니다. 한 봄에 두 건의 고위험 보안 권고 사항이 발표되었고, 두 건 모두 패치가 적용되었으나, 12 버전 이전 버전을 사용 중인 경우 공개 빌드에서는 해당 패치를 적용할 수 없습니다.

Jetty 9.4를 내장한 Spring Boot 2.7 애플리케이션이 이러한 함정의 실체를 보여줍니다. 빌드에서 Jetty 버전을 재정의하려면 이를 재정의할 수 있는 공개된 버전이 있어야만 하는데, 9.4의 경우 더 이상 그런 버전이 없습니다. 대안은 12.x 아티팩트인데, 이는 JDK 17, 자카르타 네임스페이스, 그리고 스프링 부트의 주요 업그레이드를 의미하므로, 해당 CVE는 대개 보고서에 그대로 남아 있게 됩니다. 수정 패치는 존재하지만, 지원되는 빌드를 서버에 적용하는 것이 어려운 부분이며, 강제 업그레이드 없이 이 격차를 해소하는 것이 바로 벤더 지원 패치의 목적입니다.

Jetty의 HTTP 파싱 실적

Jetty의 반복적으로 나타나는 취약점은 HTTP/1.x 요청 처리이며, 이러한 패턴은 충분히 일관성이 있어 이에 대비한 계획을 세울 수 있습니다. CVE-2026-2332는 청크 인코딩 구문 분석 버그로, 이번이 처음이 아닙니다. CVE-2023-40167 의 경우, Jetty가 + 문자를 Content-Length 값 앞에 +문자를 허용하는 문제였습니다. 이는 프론트엔드에서 해당 헤더를 다르게 해석할 경우 요청 스머글링을 유발할 수 있는 파싱상의 특이점입니다.

2017년 분은 세 가지 파서 버그를 통해 동일한 문제를 보여줍니다. CVE-2017-7656 은 HTTP/0.9를 선언한 HTTP/1 스타일의 요청 줄을 수락하는 문제와 관련되어 있으며, 중개 서버가 해당 버전을 처리하지 않고 그대로 전달할 경우 캐시를 오염시킬 수 있었습니다. CVE-2017-7657 는 청크 길이 파싱 시 발생하는 정수 오버플로우로, 큰 청크가 더 작은 청크로 인식되어 그 본문이 파이프라인 요청으로 처리될 수 있는 문제였습니다. CVE-2017-7658 는 Content-Length와 청크 인코딩 표시자 간의 충돌과 관련이 있습니다. 후자의 두 경우에서, 문제가 발생한 시나리오는 인증을 적용하고 요청을 변경 없이 전달하는 중개 서버 뒤에 Jetty가 위치해 있을 때였습니다. 이로 인해 밀반입된 요청이 해당 인증 점검을 통과하여 반대편에 도달하게 되었습니다.

이러한 역사에서 두 가지 교훈을 얻을 수 있습니다. Jetty가 프록시, 로드 밸런서 또는 CDN 뒤에 위치해 있다면, 파서 관련 CVE를 단순한 이론적 문제로 치부하지 말고 최우선 순위로 다루어야 합니다. 왜냐하면 이러한 중간 계층이 바로 해당 취약점을 악용 가능하게 만드는 원인이기 때문입니다. 또한 즉시 패치를 적용할 수 없는 경우, 프론트엔드에서 청크 확장자를 정규화하거나 제거하는 것이 이러한 유형의 버그에 대한 실질적인 임시 대응책이 됩니다.

숨겨진 내재화와 규정 준수 위험 노출

The 전이적 의존성 문제 는 앞서 언급한 모든 사항을 더욱 어렵게 만듭니다. Solr, Spark, ActiveMQ, Hadoop의 각 버전에는 Jetty가 포함되어 있으며, Jetty Maven 플러그인이 빌드 과정에 Jetty를 끌어들이기 때문에 “우리는 Jetty를 사용하지 않는다”는 가정은 종종 틀립니다. 대규모 포트폴리오에서는 서로 다른 서비스에 걸쳐 하나 이상의 Jetty 주요 버전이 존재하는 경우가 흔하며, 각 버전은 고유한 노출 범위와 담당자를 가지고 있습니다.

감사 측면도 있습니다. PCI DSS 는 패치 적용 및 취약점 관리에 대한 명확한 요구 사항을 규정하고 있으며, FedRAMP 는 문서화된 스캔 및 수정 일정을 요구하며, 반면 SOC 2 은 패치 의무가 아닌 귀하가 정의한 통제 사항에 대한 검증이지만, 감사관은 지원이 중단된 HTTP 서버가 귀하가 작성한 통제 사항과 어떻게 부합하는지 여전히 질문할 것입니다. EOL(지원 종료) 상태의 Jetty만으로는 감사에서 불합격 판정을 받지는 않습니다. 다만 이에 대한 설명을 요구받게 되며, “업스트림 수정 프로그램이 더 이상 공개되지 않습니다”라는 답변은 이를 보완할 통제 수단이 뒷받침되지 않는다면 설득력이 부족한 답변입니다.

주의: 애플리케이션 저장소에 대한 Green Dependency 스캔 결과가 정상이라고 해서 문제가 없는 것은 아닙니다. EOL Jetty는 대개 단일 아티팩트로 배포한 타사 제품 내에 숨어 있는 경우가 많기 때문에, 취약점이 있는 JAR 파일이 여러분의 pom.xml에 직접적인 의존성으로 나타나지 않을 수 있습니다. 빌드하는 저장소뿐만 아니라 배포된 아티팩트와 컨테이너 이미지도 스캔하십시오.

업그레이드 경로: Eclipse Jetty 12로 전환

마이그레이션 작업은 사용 중인 Jetty가 독립형인지 임베디드형인지에 따라 크게 달라집니다. 아래의 각 단계는 다음 단계로 넘어가는 전제 조건이므로 순서를 준수해야 합니다.

먼저 JDK 17부터 살펴보겠습니다. Jetty 12.0과 12.1 모두 Java 17 을 최소 런타임 버전으로 설정하고 있습니다. 만약 Java 8 또는 Java 11을 사용 중이라면, 이것이 핵심 과제이며 대개 가장 큰 단일 작업입니다.
그런 다음 EE 환경을 선택하세요. Jetty 12는 환경별 모듈 내에서 애플리케이션을 실행합니다. 12.0 버전에는 EE8, EE9, EE10이 포함되어 있으며, 12.1 버전은 EE8부터 EE11까지를 지원합니다. EE10은 jakarta.servlet(Servlet 6.0)을 사용하고 EE11은 Servlet 6.1을 사용하므로, Java EE javax.* API를 임포트하는 코드와 라이브러리는 해당 대상에 맞게 이동해야 합니다. EE8은 javax.* 네임스페이스를 유지하므로, Jetty 12 코어를 먼저 배포하고 네임스페이스 관련 작업은 별도로 진행할 수 있습니다. 이를 스크립트로 처리하는 분들을 위해 명확히 말씀드리자면, 이동된 것은 Java EE 패키지뿐입니다. javax.crypto, javax.sql 및 그 외의 Java SE 패키지는 기존 위치에 그대로 남아 있습니다.
임베디드 사용자를 위한 Spring Boot 버전 연동 문제. 여기에는 함정이 있습니다. 임베디드 Jetty 12는 Spring Boot 3.2 이상이 필요합니다. Spring Boot 3.0 및 3.1은 Jetty 11과 함께 제공되었으며, Jetty를 사용하려면 Servlet API를 5.0으로 다운그레이드해야 했기 때문입니다. 반면 Spring Boot 3.x는 Java 17과 Jakarta EE 9 네임스페이스를 필요로 하므로, “Jetty 버전 업그레이드” 요청은 Spring Boot 2에서 3으로의 마이그레이션이 되며, 최소 버전은 3.2가 되어야 합니다.

Spring Boot 2.7을 기반으로 하고 Jetty 9.4가 내장된 SaaS 애플리케이션을 생각해 봅시다. Jetty 업그레이드는 pom.xml에 한 줄을 추가하는 식의 간단한 작업이 아닙니다. 이는 JDK, 코드베이스 전반에 걸친 Java EE 임포트, Spring Security 구성, 그리고 Jakarta 호환 릴리스가 필요한 수많은 라이브러리에 이르기까지 광범위하게 영향을 미치는 다중 스프린트 프로젝트입니다.

결정 사항은 명확하게 나뉩니다. 독립형 Jetty를 실행 중이고 이미 Java 17을 사용하고 있다면, 임베디드 환경보다 마이그레이션 범위가 더 좁지만, 이름이 변경된 Maven 아티팩트, 새로운 모듈 및 환경 구성, jetty-base 구성, 배포 설명자에 대한 검토 시간을 확보해야 합니다. Jetty가 Spring Boot 2.x 애플리케이션에 임베드된 경우, 먼저 Spring Boot 3.2 이상으로의 마이그레이션을 계획하고 Jetty 버전 업데이트는 그에 따른 후속 조치로 처리하십시오. 또한 이미 Spring Framework EOL 마이그레이션을 진행 중이라면, 두 작업을 순차적으로 진행하십시오. 자카르타 관련 작업이 거의 완전히 중복되기 때문입니다.

전문가 팁: Eclipse Transformer는 소스 코드에서 재빌드할 수 없는 종속성에 대해 바이트코드 내의 javax.* 참조를 jakarta.*로 자동으로 변환해 줄 수 있습니다. 이를 통해 반복적인 수작업이 크게 줄어듭니다. 하지만 변환된 아티팩트는 철저한 회귀 테스트가 필요하며, 원본 공급업체에서는 이를 지원하지 않으므로, 이를 마이그레이션 전략이라기보다는 차단된 단일 종속성을 해결하기 위한 임시 방편으로 간주해야 합니다.

지금 당장 업그레이드할 수 없는 경우의 선택지

때로는 이번 분기 내에 마이그레이션을 완료할 수 없는 경우도 있습니다. Spring Boot 3 관련 작업이 너무 방대하거나, 공급업체의 제품이 귀사가 통제할 수 없는 구버전 Jetty를 고정해 놓은 경우 등이 그 예입니다. 그래도 현실적으로 취할 수 있는 세 가지 방안이 있습니다. 바로 공급업체가 지원하는 확장 지원, 사내에서 직접 백포트를 유지 관리하는 것, 또는 Jetty를 대체하는 것입니다.

1. Jetty용 TuxCare Endless 라이프사이클 지원 이용하기

마이그레이션까지 몇 달이 남았다면, 공급업체가 지원하는 연장 지원 서비스를 통해 EOL(제품 수명 주기 종료) 상태인 Jetty에 패치를 계속 적용받을 수 있으며, 귀사의 일정에 맞춰 강제로 업그레이드할 필요가 없습니다. TuxCare의 Endless Lifecycle Support 는 지원 종료된 오픈 소스 소프트웨어에 대한 보안 수정 사항을 제공하며, Jetty 지원 범위는 7, 8, 9.2, 9.4, 10, 11 버전을 아우르며, 2026년 CVE를 해결하는 지원 종료 후 빌드(9.4.60 이상, 10.0.28 이상, 11.0.28 이상)도 포함됩니다. Webtide는 TuxCare와 제휴하여 이 서비스를 제공하고 있으며, 이에 따라 Jetty의 공식 보안 권고문에서는 이제 지원 종료(EOL) 사용자에게 상용 패치 제공업체를 안내하고 있습니다.

이 솔루션은 귀사가 이미 보유하고 있는 툴체인에 완벽하게 통합됩니다. 패치된 아티팩트는 TuxCare가 관리하는 Maven 호환 레지스트리에 서명된 패키지로 게시되므로, 기존 Maven 및 Gradle 빌드 환경에서는 빌드 방식을 변경할 필요 없이 다른 리포지토리를 지정하고 버전을 업데이트하는 것만으로도 이를 활용할 수 있습니다.

Jetty 자체의 메모리 사용량은 적고 깔끔합니다: jetty-server 는 jetty-http, jetty-io, jetty-util, 그리고 slf4j-api. 문제는 CVE가 어디에 할당되느냐는 점입니다. jetty-http 와 jetty-server 는 요청 스머글링 및 URI 파싱 버그가 정확히 존재하는 곳이며, jetty-http는 대개 다른 구성 요소를 통해 3단계 아래로 전달된 후에 스캐너가 표시하는 아티팩트입니다. ELS는 추가 비용 없이 직접 및 전이적 종속성을 모두 다루므로, 사용자가 명시한 아티팩트뿐만 아니라 실제로 Jetty의 취약점을 포함하고 있는 모듈까지 패치됩니다.

대부분의 팀에게 이는 실용적인 해결책입니다. 이를 통해 당면한 보안 부담을 덜어줄 뿐만 아니라, 타사의 마감 기한에 맞춰 임베디드 웹 서버 통합 기능을 재작성하는 대신, Java 17 및 Spring Boot 3.2 작업을 제대로 계획하는 동안 감사 논의에 제시할 수 있는 문서화된 패치 적용 현황을 확보할 수 있습니다.

2. 제티를 내부적으로 자체 유지 관리하기

가장 최근에 공개된 Jetty 릴리스를 포크하여 보안 수정 사항을 직접 백포트할 수 있습니다. 기술적으로는 가능하며, 어차피 원활하게 마이그레이션할 수 없는 고도로 맞춤화된 배포 환경의 경우 때로는 이것이 올바른 선택일 수 있습니다.

또한 가장 중요한 측면에서 비용이 많이 듭니다. 바로 여러분이 직접 Jetty 포크의 유지보수자가 되어야 한다는 점입니다. 누군가는 모든 새로운 보안 권고 사항을 주시하고, HTTP/1.x 파서를 면밀히 분석하여 보안 취약점 수정 사항을 올바르게 이식한 뒤, 회귀 테스트를 거친 후 빌드 및 릴리스 프로세스를 통해 배포해야 합니다. 파서 수정 시 미묘한 차이를 잘못 파악하면, 적용된 것처럼 보이지만 실제로는 적용되지 않은 패치를 배포하게 되는데, 이는 취약점이 노출되어 있다는 사실을 아는 것보다 더 심각한 문제입니다. 이를 유지 관리하려면 전담 보안 엔지니어링 및 릴리스 관리 역량이 필요하지만, 대부분의 애플리케이션 팀에는 이러한 여력이 따로 마련되어 있지 않습니다.

3. Jetty를 다른 솔루션으로 대체하기

Jetty를 다른 서블릿 컨테이너로 교체하는 방안도 검토 대상에 포함되어 있습니다. 특히 어차피 아키텍처 변경을 고려하고 계셨다면 더욱 그렇습니다. Tomcat 과 언더토우(Undertow)는 동급의 대안이며, 단순한 서블릿 요구 사항이 있는 독립형 배포 환경의 경우 톰캣이 가장 흔히 선택되는 옵션 중 하나입니다. 네티(Netty)는 사정이 다릅니다. 네티는 서블릿 컨테이너라기보다는 저수준의 비동기 네트워킹 프레임워크이므로, 네티로 전환하는 것은 단순한 대체가 아니라 아키텍처 전반의 재구성을 의미합니다.

규모에 대해 솔직하게 평가해야 합니다. 임베디드 앱의 경우, 서버를 교체하는 것은 Jetty를 업그레이드하는 것보다 더 많은 재작업이 필요한 경우가 많습니다. 구성 모델이 달라지고, 커넥터 및 스레드 풀 튜닝이 달라지며, 부하 테스트를 다시 수행해야 하기 때문입니다. “동등해야 할” 대체 솔루션이라 해도 실제 운영 트래픽 하에서는 극한 상황에서의 동작 차이가 드러나는 경우가 많습니다. 게다가 이미 Jetty 12로 마이그레이션 작업을 진행 중이라면, 그 작업의 대부분이 그대로 이어지므로 많은 팀에게 Jetty를 계속 사용하는 것이 더 수월한 선택지가 됩니다.

TuxCare를 통해 지원 종료(EOL)된 Eclipse Jetty를 안전하게 사용하세요

버전 관련 문제는 해결되었습니다. Jetty 8, 9, 10, 11은 지원 종료되었으며, 9, 10, 11 계열의 공개 릴리스는 2026년 1월 1일을 기해 중단되었고, Jetty 12로의 전환은 단순히 체크리스트를 채우는 차원이 아닌 실질적인 프로젝트입니다. 남은 과제는 현재 시점부터 마이그레이션이 완료될 때까지의 공백기를 어떻게 메울 것인가 하는 점입니다.

이번 분기에 Jetty 12로 마이그레이션할 수 있다면 그렇게 하시고, JDK 17 및 Spring Boot 3.2 관련 작업을 현실적인 일정에 맞춰 진행하십시오. 만약 불가능하다면, 패치가 적용되지 않은 상태로 운영하지 마십시오. 지원 종료(EOL)된 제품군에 대한 수정된 빌드는 실제로 존재하지만, 더 이상 공개적으로 배포되지 않을 뿐입니다. 공급업체의 지원을 받으면 알려진 취약점에 대한 패치가 지속적으로 적용되며, 귀사가 계획을 수립하는 동안 적극적인 문제 해결 과정이 진행되고 있음을 확인할 수 있습니다. 자세한 내용은 TuxCare가 EOL 오픈소스 소프트웨어를 어떻게 관리하는지방식을 참고하고, 가격 를 확인하여 귀사의 포트폴리오에 맞춰 적용 범위를 파악해 보십시오.

자주 묻는 질문

현재 어떤 Eclipse Jetty 버전이 여전히 지원되고 있나요?

Jetty 12.0과 12.1만 커뮤니티 지원을 받고 있습니다. Jetty 12.1은 현재 지원 중인 버전으로 활발한 수정 패치를 받고 있으며, 12.0도 여전히 업데이트를 받고 있지만, Webtide는 2026년 중 어느 시점에 업데이트가 중단될 것이라고 밝혔으나 구체적인 날짜는 확정하지 않았습니다. Jetty 8, 9, 10, 11을 포함한 그 이전의 모든 버전은 지원 종료되었습니다.

Eclipse Jetty 9는 여전히 운영 환경에서 안전하게 실행할 수 있나요?

보안 수정 사항이 지속적으로 제공되지 않는다면 불가능합니다. Jetty 9.4는 지원 종료(EOL) 상태이며, 마지막 공개 릴리스는 2025년 8월의 9.4.58.v20250814입니다. 또한 2026년 1월 1일부터는 Maven Central에 9.x 릴리스가 더 이상 게시되지 않습니다. 이후 수정된 빌드가 존재하긴 하지만, 이는 확장 지원(extended-support) 제공업체를 통해서만 제공되므로, 9.4 버전을 책임감 있게 운영하려면 해당 지원을 확보하거나, 그 앞에 상응하는 통제 조치를 마련하고, 이 두 가지 모두에 대한 마이그레이션 계획을 수립해야 합니다.

내 Spring Boot 애플리케이션이 Jetty의 지원 종료(EOL) 버전을 사용하고 있는지 어떻게 알 수 있나요?

실행 mvn dependency:tree -Dincludes=’org.eclipse.jetty*’ 또는 ./gradlew dependencies | grep -i jetty를 실행하세요. Jetty 12는 org.eclipse.jetty.ee10과 같은 그룹 ID로 환경 아티팩트를 배포하므로, 정확한 일치 필터로는 이를 놓칠 수 있으므로 와일드카드를 유지해야 합니다. 출력 결과에 9.x, 10.x 또는 11.x 버전의 Jetty 아티팩트가 표시된다면, Jetty가 사용자가 명시적으로 선언하지 않은 전이적 의존성으로 포함되었더라도 해당 앱은 지원 종료(EOL) 단계에 있습니다.

Jetty 10에서 Jetty 12로 업그레이드하려면 javax에서 jakarta로 마이그레이션해야 하나요?

Jetty 12의 EE10 또는 EE11 환경을 대상으로 하는 경우에만 해당됩니다. Jetty 10은 javax.servlet을 사용하고, EE10은 jakarta.servlet(Servlet 6.0)을, EE11은 Servlet 6.1을 사용합니다. Jetty 12에는 EE8 및 EE9 환경도 포함되어 있으며, EE8은 javax.* 네임스페이스를 유지하므로, 먼저 Jetty 코어와 JDK를 이전한 후 네임스페이스 마이그레이션을 별도의 프로젝트로 처리할 수 있습니다.