전자정부 표준프레임워크 5.0, Spring 6와 Jakarta 전환 핵심

전자정부 표준프레임워크 5.0, Spring 6와 Jakarta 전환 핵심

전자정부 표준프레임워크 5.0은 단순한 라이브러리 버전 업데이트가 아니다. JDK 17, Spring Framework 6.2 계열과 Jakarta 기반 기술 스택을 적용하면서 과거 Java EE와 Spring 5 중심의 구조에서 현대적인 Java 애플리케이션 환경으로 이동한 버전이다. 기존 4.x 프로젝트를 운영하는 조직이라면 신규 기능보다 호환성 변화와 마이그레이션 범위를 먼저 확인해야 한다.

핵심 요약
전자정부 표준프레임워크 5.0 실행환경은 JDK 17을 기본 전제로 한다.
Spring Framework는 5.3 계열에서 6.2 계열로 올라갔다.
기존 javax.* 기반 코드는 jakarta.* 전환 여부를 반드시 점검해야 한다.
Spring Boot 기반 템플릿은 Boot 3 계열을 사용하므로 기존 Boot 2 프로젝트와 직접 호환되지 않는다.

전자정부 표준프레임워크 5.0은 무엇이 달라졌나

전자정부 표준프레임워크는 Spring을 기반으로 공공 정보시스템 개발에 필요한 실행환경, 개발환경, 공통컴포넌트와 예제 프로젝트를 제공한다. 5.0에서는 기반 프레임워크와 Java 버전이 크게 변경되면서 프로젝트의 최소 실행 조건도 달라졌다.

JDK 17 이전 Java 버전을 계속 사용하는 프로젝트는 빌드와 실행 환경부터 변경해야 한다.

Spring Framework 6.2 Spring 5.3 기반이었던 4.x와 주요 API 및 기반 사양이 달라졌다.

Jakarta 기반 Servlet, Validation, Persistence 등에서 javax 대신 jakarta 패키지를 사용한다.

Spring Boot 3 Boot 기반 프로젝트는 Jakarta 전환과 JDK 17 요구사항을 함께 적용받는다.

공통컴포넌트 5.0 실행환경 5.0에 맞게 공통 업무 기능과 프로젝트 구성이 갱신됐다.

현대화된 개발 구조 전통적인 JSP·XML 방식과 함께 Java Config, REST API, 프런트엔드 분리형 예제가 제공된다.

공식 실행환경 저장소에서는 전자정부 표준프레임워크 5.0이 Spring Framework 6.2.11과 Java 17을 기반으로 한다고 안내한다. Boot 기반 예제에서는 Spring Boot 3.5 계열과 Jakarta EE 10 구성이 사용되며, 전통적인 웹 템플릿은 Jakarta EE 9와 Servlet 5 조합을 사용하는 사례도 있다.

프로젝트마다 Jakarta 버전이 같다고 단정하면 안 된다
Boot 기반 예제와 외부 WAS에 배포하는 전통적인 WAR 템플릿은 기술 구성이 다를 수 있다.
Jakarta EE 9인지 10인지, Servlet 5인지 6인지 프로젝트 템플릿과 배포 서버별로 확인해야 한다.
프레임워크 5.0이라는 이름만 보고 모든 서버에서 같은 사양을 지원한다고 판단하면 안 된다.

주요 기술 스택 비교

구분	전자정부 표준프레임워크 4.x	전자정부 표준프레임워크 5.0
기본 Java	프로젝트 버전에 따라 Java 8 이상 중심	JDK 17 필수
Spring Framework	5.3 계열	6.2.11 기반
Spring Boot	Boot 2 계열 중심	Boot 3.5 계열 기반 예제 제공
엔터프라이즈 API	Java EE와 javax.* 중심	Jakarta EE와 jakarta.* 중심
Servlet API	javax.servlet	jakarta.servlet
Validation API	javax.validation	jakarta.validation
Persistence API	javax.persistence	jakarta.persistence
배포 서버	Java EE·Servlet 구형 사양 지원 서버	Jakarta EE 9 이상 또는 Servlet 5 이상 지원 서버 필요
호환성	5.0 실행환경과 직접 호환되지 않음	코드와 의존성 마이그레이션 필요
권장 적용	기존 운영 시스템 유지	신규 구축 또는 계획된 현대화 프로젝트

Spring Framework 6.2 전환의 의미

전자정부 표준프레임워크 5.0은 Spring Framework 6.2 계열을 기반으로 한다. Spring 6은 Java 17과 Jakarta EE를 기본 전제로 하므로 기존 Spring 5 프로젝트에서 단순히 Maven 버전만 바꾸는 방식으로는 전환하기 어렵다.

Java 17이 최소 기준이 된다

빌드 서버, 개발자 PC, WAS와 컨테이너 이미지의 Java 버전을 모두 확인해야 한다. 애플리케이션은 JDK 17로 빌드했지만 운영 WAS가 이전 Java 버전으로 실행된다면 배포 단계에서 실패한다.

운영 환경에서는 애플리케이션 서버만 확인해서는 부족하다. Jenkins, Maven 실행 환경, 정적 분석 도구, 테스트 도구와 에이전트가 JDK 17을 지원하는지도 함께 확인해야 한다.

Spring 5용 확장 라이브러리 호환성을 확인해야 한다

Spring Security, Spring Batch, Spring Data, ORM 연동 라이브러리와 사내 공통 모듈이 Spring 6을 지원하는지 확인해야 한다. 오래된 라이브러리가 javax.servlet이나 제거된 Spring API를 참조하면 컴파일 또는 실행 오류가 발생할 수 있다.

XML 설정을 반드시 버릴 필요는 없다

Spring 6을 사용한다고 해서 모든 XML 설정을 Java Config로 바꿔야 하는 것은 아니다. 기존 XML 기반 애플리케이션도 호환되는 스키마와 클래스를 사용하면 운영할 수 있다.

다만 신규 프로젝트에서는 Java Config, 컴포넌트 스캔과 Boot 자동 설정을 활용하면 설정 변경 추적과 테스트가 쉬워질 수 있다. 기존 시스템은 안정성을 우선하고 신규 모듈부터 단계적으로 전환하는 방법이 현실적이다.

Jakarta 전환에서 가장 많이 생기는 문제

Java EE 사양이 Eclipse 재단으로 이전되면서 패키지 이름이 javax에서 jakarta로 변경됐다. 전자정부 표준프레임워크 5.0과 Spring 6은 이 Jakarta 기반 API를 사용한다.

// 기존 코드

import javax.servlet.http.HttpServletRequest; import javax.validation.Valid; import javax.persistence.Entity;

// 전환 코드 import jakarta.servlet.http.HttpServletRequest; import jakarta.validation.Valid; import jakarta.persistence.Entity;

패키지 이름을 일괄 치환하는 것만으로 전환이 끝나는 것은 아니다. 사용 중인 라이브러리, WAS, 배포 기술자와 테스트 코드가 모두 Jakarta API를 지원해야 한다.

Servlet 필터와 리스너

직접 구현한 Filter, ServletContextListener, HttpSessionListener와 파일 업로드 코드는 jakarta.servlet 기반으로 수정해야 한다. 보안 필터나 사내 인증 모듈이 오래된 javax.servlet API를 사용한다면 별도 업그레이드가 필요하다.

JPA와 데이터 접근 계층

JPA를 사용하는 프로젝트는 Entity, PersistenceContext와 관련 annotation을 jakarta.persistence로 바꿔야 한다. Hibernate 같은 구현체도 Jakarta 대응 버전으로 올려야 한다.

MyBatis 중심 프로젝트는 JPA 프로젝트보다 영향을 적게 받을 수 있지만, 트랜잭션과 Spring 연동 모듈의 버전 호환성은 별도로 확인해야 한다.

Validation과 Bean Validation

javax.validation을 사용하는 DTO와 폼 객체는 jakarta.validation으로 변경해야 한다. Validator 구현체와 메시지 처리 설정도 새로운 사양을 지원하는 버전인지 확인해야 한다.

JSP 태그와 WAS 호환성

JSP를 계속 사용할 수는 있지만 Jakarta 사양에 맞는 Servlet 컨테이너가 필요하다. 기존 Tomcat 9 계열은 javax 기반이므로 일반적으로 Jakarta 기반 애플리케이션을 그대로 배포할 수 없다.

Tomcat 10 이상이나 Jakarta EE 지원 WAS를 사용해야 하며, 실제 템플릿이 요구하는 Servlet 사양과 서버 버전을 맞춰야 한다.

javax와 jakarta 라이브러리를 한 애플리케이션에 혼합하지 않는다
이름이 비슷해도 서로 다른 타입이므로 자동 호환되지 않는다.
필터, 요청 객체, Validation annotation과 JPA Entity가 서로 다른 패키지를 사용하면 런타임 오류가 발생할 수 있다.
애플리케이션과 주요 라이브러리를 같은 Jakarta 세대로 맞추는 것이 중요하다.

Spring Boot 3 기반 개발에서 달라지는 점

전자정부 표준프레임워크 5.0은 Spring Boot 기반 starter와 예제 프로젝트를 제공한다. Boot 기반으로 구성하면 내장 서버, 자동 설정, 외부 설정과 실행 가능한 패키징 방식을 활용할 수 있다.

외부 WAS 없이 실행할 수 있다

내장 Tomcat을 사용하는 Boot 프로젝트는 별도의 WAS 설치 없이 애플리케이션을 실행할 수 있다. 개발 환경과 테스트 자동화에서는 서버 설치 과정이 줄어들고, 컨테이너 이미지에도 애플리케이션 실행 환경을 함께 포함할 수 있다.

설정 방식을 단순화할 수 있다

전통적인 XML 설정을 모두 제거할 필요는 없지만, application.yml과 Java Config를 사용하면 환경별 설정을 외부화하기 쉽다. 데이터소스, 로그 수준, 프로파일과 서버 포트도 배포 환경에서 주입할 수 있다.

배포 단위가 달라질 수 있다

기존 공공 프로젝트는 WAR 파일을 외부 WAS에 배포하는 방식이 많았다. Boot 프로젝트는 실행 가능한 JAR 또는 컨테이너 이미지로 배포할 수 있다.

단, 기관 운영 표준이 외부 WAS 배포를 요구하거나 여러 애플리케이션을 하나의 WAS에서 관리한다면 기존 WAR 방식이 필요할 수 있다. 기술적으로 가능하다는 이유만으로 운영 표준을 무시해서는 안 된다.

실무 기준으로 보면
신규 REST API나 컨테이너 기반 시스템은 Boot 방식이 유리한 경우가 많다.
기존 JSP 중심 업무 시스템은 전통적인 WAR 구조를 유지하는 편이 전환 위험을 줄일 수 있다.
같은 기관에서도 시스템 성격에 따라 두 방식을 나누어 적용할 수 있다.

전통적인 웹 프로젝트와 Boot 프로젝트 비교

비교 항목	전통적인 WAR 프로젝트	Spring Boot 프로젝트
배포 방식	외부 WAS 또는 Servlet 컨테이너에 WAR 배포	실행 가능한 JAR 또는 컨테이너 이미지
서버 구성	운영 서버에 WAS를 별도 설치	내장 서버를 애플리케이션과 함께 구성 가능
설정 형태	XML과 WAS 설정 비중이 높음	Java Config와 외부 설정 중심
JSP 사용	적용하기 쉬움	가능하지만 패키징과 뷰 구성을 신중히 설계
REST API	구현 가능	API 중심 구조에 상대적으로 편리
컨테이너 배포	WAS 이미지와 배포 구조를 함께 관리	애플리케이션 단위 이미지 구성에 유리
운영 독립성	공용 WAS 운영 정책에 영향	서비스별 버전과 설정을 독립적으로 관리하기 쉬움
적합한 환경	기존 JSP 업무 시스템과 중앙 WAS 운영	신규 API, 독립 서비스와 클라우드 환경

공통컴포넌트 5.0에서 확인할 점

공통컴포넌트 5.0은 로그인, 권한, 게시판, 파일, 통계와 시스템 관리 같은 공통 업무 기능을 제공한다. 신규 프로젝트에서는 필요한 컴포넌트만 선택하고 실제 보안 정책과 업무 요구사항에 맞게 검토해야 한다.

전체 컴포넌트를 무조건 설치하지 않는다

all-in-one 예제는 학습과 기능 확인에는 편리하지만 실제 운영 시스템에 불필요한 기능까지 포함할 수 있다. 사용하지 않는 Controller, 관리자 화면과 테이블이 남아 있으면 관리 범위와 보안 점검 대상이 늘어난다.

인증과 권한 기능을 그대로 운영하지 않는다

로그인과 권한 컴포넌트는 기관의 인증 체계, 개인정보 처리 기준, 비밀번호 정책과 감사 요구사항에 맞게 검토해야 한다. SSO, 행정전자서명, 민간 인증 또는 기관 통합 인증을 사용한다면 별도 연계 설계가 필요하다.

제공 예제와 운영 코드를 구분한다

공통컴포넌트는 개발을 시작하기 위한 기반이지 완성된 업무 시스템 전체를 의미하지 않는다. 화면, 예외 처리, 개인정보 마스킹, 접근 통제, 로깅과 성능 설정을 운영 기준에 맞게 수정해야 한다.

AI 기능이 포함됐다는 의미

전자정부 표준프레임워크 5.0 개발가이드에는 Spring AI와 LangChain4j 연계 계층 및 예제 프로젝트가 포함되어 있다. 프레임워크가 관련 의존성 버전을 관리해 생성형 AI 기능을 프로젝트에 연결하는 출발점을 제공한다.

이것이 공공 시스템에서 생성형 AI를 바로 운영해도 된다는 의미는 아니다. 외부 AI 서비스에 전송되는 데이터, 개인정보와 행정정보의 저장 위치, 프롬프트 기록, 모델 응답 검증과 비용 통제가 별도로 필요하다.

AI 연계 기능 적용 전 확인할 내용
개인정보와 비공개 행정정보를 외부 모델로 전송할 수 있는지 검토한다.
모델 응답을 업무 의사결정에 그대로 사용하지 않도록 검증 절차를 둔다.
프롬프트와 응답 로그의 보존 기간 및 접근 권한을 정의한다.
모델 장애나 사용량 제한이 발생했을 때의 대체 흐름을 마련한다.

기존 4.x 프로젝트를 5.0으로 옮길 때 어려운 이유

전자정부 표준프레임워크 5.0은 Spring 6과 Jakarta 전환 때문에 이전 실행환경과 직접 호환되지 않는다. 따라서 실행환경 의존성 버전만 5.0으로 변경하는 방식은 권장하기 어렵다.

소스 코드 변경

javax import를 jakarta로 변경하고 제거되거나 변경된 Spring API를 수정해야 한다. 사내 공통 라이브러리와 외부 솔루션의 연동 모듈도 함께 점검해야 한다.

빌드 환경 변경

Maven Compiler 설정, Java 버전, 플러그인과 테스트 환경을 JDK 17 기준으로 맞춰야 한다. 오래된 Maven 플러그인이 Java 17에서 정상 동작하지 않을 수 있다.

WAS 변경

기존 WAS가 Jakarta EE 또는 Servlet 5 이상을 지원하지 않으면 서버 업그레이드나 교체가 필요하다. WAS 버전 변경은 JVM 옵션, 데이터소스, 세션 클러스터링과 보안 설정까지 영향을 줄 수 있다.

연계 모듈 변경

전자결재, SSO, 리포팅, DRM, 파일 변환, 메시징과 대외 연계 솔루션이 Jakarta 환경을 지원하는지 확인해야 한다. 핵심 애플리케이션을 전환했더라도 연계 모듈 하나가 호환되지 않으면 전체 배포가 지연될 수 있다.

회귀 테스트 확대

컴파일 성공만으로 호환성이 확인되는 것은 아니다. 로그인, 권한, 파일 업로드, 배치, 트랜잭션, 세션, 엑셀 다운로드, 보고서 출력과 대외 연계를 실제 운영 조건으로 테스트해야 한다.

5.0 마이그레이션 권장 순서

1. 현재 기술 스택을 조사한다.
   Java, Spring, Servlet, WAS, 데이터베이스 드라이버와 외부 라이브러리 버전을 목록화한다.
2. javax 사용 범위를 검색한다.
   애플리케이션 코드뿐 아니라 사내 공통 모듈과 배포 라이브러리까지 조사한다.
3. JDK 17 빌드 환경을 먼저 만든다.
   개발 PC와 CI 서버가 같은 JDK 및 Maven 버전을 사용하도록 맞춘다.
4. Jakarta 지원 WAS를 선정한다.
   사용할 템플릿의 Servlet 및 Jakarta 사양과 서버 지원 범위를 일치시킨다.
5. 대표 업무 한 개를 시험 전환한다.
   로그인, 데이터 조회, 저장, 파일과 외부 연계가 포함된 업무를 선정한다.
6. 의존성을 단계적으로 교체한다.
   Spring, 보안, 데이터 접근, 로깅과 테스트 라이브러리를 호환되는 세대로 맞춘다.
7. 성능과 장애 복구를 검증한다.
   정상 부하뿐 아니라 WAS 재시작, DB 단절과 세션 장애 상황도 시험한다.
8. 병행 운영과 롤백 절차를 마련한다.
   전환 중 문제가 발생하면 기존 4.x 환경으로 되돌릴 수 있어야 한다.

의존성 설정에서 확인할 부분

Boot 기반 프로젝트에서는 전자정부 표준프레임워크가 제공하는 parent 또는 BOM을 사용해 주요 의존성 버전을 관리할 수 있다. 개별 라이브러리 버전을 임의로 덮어쓰면 호환성 문제가 생길 수 있으므로 필요한 경우에만 변경하는 것이 좋다.

<parent>
<groupId>org.egovframe.boot</groupId>
<artifactId>egovframe-boot-starter-parent</artifactId>
<version>5.0.0</version>
<relativePath/>

실제 프로젝트에서는 공식 템플릿의 최신 설정을 기준으로 groupId, artifactId와 버전을 확인해야 한다. 프레임워크 의존성만 5.0으로 바꾸고 Spring 또는 Boot 버전을 별도로 낮추는 구성은 피하는 것이 안전하다.

의존성 충돌 점검 방법
Maven dependency tree로 Spring과 Jakarta API가 여러 버전으로 섞였는지 확인한다.
WAS가 제공하는 라이브러리와 애플리케이션에 포함된 라이브러리의 중복을 확인한다.
테스트와 운영에서 같은 dependency lock 또는 빌드 결과물을 사용한다.
보안 취약점 때문에 버전을 변경할 때는 프레임워크 호환성 테스트를 함께 진행한다.

신규 프로젝트에 5.0이 적합한 경우

• 신규 공공 Java 시스템을 JDK 17 이상으로 구축한다.
• Spring 6과 Jakarta 기반 기술 스택을 사용할 계획이다.
• 기존 javax 라이브러리 의존성이 없다.
• REST API와 프런트엔드 분리형 구조를 적용한다.
• Spring Boot와 컨테이너 기반 배포를 검토하고 있다.
• Jakarta 지원 WAS 또는 최신 Servlet 컨테이너를 사용할 수 있다.
• 공통컴포넌트를 필요한 범위만 선별해 적용할 수 있다.
• JDK 17 기반 CI/CD와 보안 점검 체계를 준비할 수 있다.

기존 4.x를 당장 유지하는 편이 나은 경우

• 서비스 종료나 재구축 일정이 가까운 시스템이다.
• 사용 중인 WAS와 상용 솔루션이 Jakarta를 지원하지 않는다.
• 대규모 javax 기반 사내 공통 모듈을 사용하고 있다.
• 업그레이드 테스트와 업무 회귀 테스트 기간을 확보하기 어렵다.
• 현재 시스템이 안정적으로 운영되고 보안 지원도 유지되고 있다.
• 단순 버전 변경보다 전체 시스템 재구축 비용이 더 큰 상황이다.

다만 유지 결정을 내렸더라도 Java와 Spring의 보안 지원 기간, 사용 중인 WAS의 제품 수명주기와 외부 솔루션 지원 종료 시점은 계속 확인해야 한다. 장기적으로는 Jakarta 전환을 피하기 어렵기 때문에 기술 부채와 예상 전환 비용을 문서화하는 것이 좋다.

운영 환경에서 반드시 확인할 체크리스트

확인 영역	주요 점검 내용
Java	개발, 빌드, 테스트, 운영 환경의 JDK 17 통일 여부
Spring	Spring 6 미지원 라이브러리와 제거된 API 사용 여부
Jakarta	javax와 jakarta API 혼재 여부
WAS	Jakarta EE와 Servlet 사양 지원 버전 확인
데이터베이스	JDK 17 대응 JDBC 드라이버와 커넥션 풀 설정
인증·보안	SSO, 인증 모듈, Spring Security와 세션 정책 호환성
공통컴포넌트	실제 사용하는 기능만 포함했는지 확인
배치	Spring Batch 버전 변화와 재시작·중복 실행 검증
외부 연계	리포팅, DRM, 메시징과 전자결재 모듈의 Jakarta 지원
운영 도구	APM, 보안 에이전트, 로그 수집기와 JDK 17 호환성
성능	응답 시간, 메모리, GC, 스레드와 커넥션 풀 재측정
복구	배포 실패와 운영 장애 발생 시 롤백 절차

전자정부 표준프레임워크 5.0의 기대 효과

장기 지원 가능한 Java 기반 확보

JDK 17과 Spring 6 기반으로 전환하면 오래된 Java 환경에서 벗어나 최신 라이브러리와 도구를 적용하기 쉬워진다. 신규 보안 패치와 생태계 지원을 받을 수 있는 기반도 마련된다.

Jakarta 생태계와의 호환성

최신 Tomcat, WildFly, JBoss EAP와 Jakarta 지원 상용 WAS 등 현대적인 애플리케이션 서버 환경을 사용할 수 있다. 앞으로 제공되는 Java 엔터프라이즈 라이브러리도 대부분 Jakarta 패키지를 기준으로 개발된다.

Boot와 컨테이너 적용 확대

서비스별 독립 배포, 외부 설정, 상태 점검과 컨테이너 이미지 기반 운영을 적용하기 쉬워진다. 공용 WAS에 여러 애플리케이션을 배포하던 구조에서 서비스 단위 운영으로 전환할 수도 있다.

기존 공공 개발 자산 활용

전자정부 표준프레임워크의 계층 구조와 공통컴포넌트를 유지하면서 기반 기술을 최신 세대로 전환할 수 있다. 완전히 새로운 프레임워크로 교체하는 것보다 기존 개발자와 운영자의 경험을 활용하기 좋다.

도입 시 주의해야 할 오해

5.0으로 올리면 자동으로 클라우드 네이티브가 되는가

그렇지 않다. Spring Boot를 사용하더라도 세션을 로컬 메모리에 저장하고 파일을 서버 디스크에 직접 쓰거나 서버 주소를 코드에 고정하면 컨테이너 확장에 적합하지 않다.

Jakarta로 패키지만 바꾸면 끝나는가

아니다. 연동 라이브러리, WAS, 데이터베이스 드라이버와 테스트 코드가 모두 새로운 사양을 지원해야 한다. 패키지 치환은 전체 전환 과정 중 일부에 불과하다.

공통컴포넌트를 모두 사용해야 표준프레임워크인가

아니다. 필요한 실행환경과 공통 기능을 선별해 사용할 수 있다. 불필요한 기능을 포함하는 것은 유지보수와 보안 측면에서 오히려 불리할 수 있다.

기존 프로젝트도 무조건 즉시 업그레이드해야 하는가

아니다. 서비스 중요도, 지원 종료 일정, 전환 비용과 연계 솔루션 호환성을 기준으로 판단해야 한다. 신규 시스템은 5.0을 우선 검토하고 기존 시스템은 계획된 현대화 일정에 맞춰 단계적으로 전환하는 방식이 현실적이다.

최종 정리

전자정부 표준프레임워크 5.0의 핵심은 JDK 17, Spring Framework 6.2와 Jakarta 기반으로의 전환이다. 이는 최신 Java 생태계를 활용할 수 있다는 장점이 있지만, 이전 4.x 프로젝트와의 직접 호환성이 낮다는 의미이기도 하다.

신규 프로젝트라면 Spring Boot, REST API, 컨테이너와 프런트엔드 분리형 구조를 함께 검토할 수 있다. 기존 프로젝트라면 javax 패키지, WAS, 사내 공통 모듈과 외부 솔루션의 호환성을 먼저 조사해야 한다.

한 줄 정리
전자정부 표준프레임워크 5.0은 단순 업데이트가 아니라 Spring 6와 Jakarta 시대로 넘어가는 전환점이다.
신규 구축에는 적극적으로 검토할 수 있지만 기존 4.x 시스템은 별도의 마이그레이션 프로젝트로 접근해야 한다.
버전 숫자보다 Java, WAS, 라이브러리와 운영 체계 전체의 호환성을 기준으로 판단해야 한다.