2026년 전자정부프레임워크의 방향과 JSP의 운명: SI 개발자가 알아야 할 현실

2009년에 태어난 전자정부표준프레임워크(eGovFrame)는 17살이 되었다. Spring Boot 4가 Jakarta EE 11을 품고, React/Vue가 프론트엔드의 기본값이 된 2026년, 여전히 JSP와 MyBatis 위에서 돌아가는 공공 SI 현장은 어디로 향하고 있는가?

---

전자정부프레임워크, 지금 어디까지 왔나

전자정부표준프레임워크는 2009년 행정안전부 산하 한국정보화진흥원에서 처음 출시된 이래, 공공 정보화 사업의 사실상 필수 요건으로 자리잡았다. Spring 프레임워크 위에 MyBatis, Jackson, Apache Commons 등을 조합한 "2차 가공 프레임워크"로, 다양한 업체가 중구난방으로 쓰던 기술 스택을 통일하겠다는 취지였다.

2026년 4월 현재 최신 버전은 eGovFrame 4.3.0이다. 주요 변화를 정리하면 다음과 같다.

버전별 핵심 전환점:

• v4.0 (2022.3): Spring 5 기반 전환, Boot-Template/MSA-Template 추가, Java 8 최소 요구
• v4.2 (2024): 공통컴포넌트 251종, Eclipse 2022-12 적용
• v4.3 (2025): Spring Boot 기반 Boot-Template·MSA-Template 업그레이드, Java Config 생성 기능 추가, 공통컴포넌트 254종, 보안 패치 강화

눈여겨볼 점은 MSA 템플릿의 공식 지원이다. eGovFrame GitHub에서 egovframe-msa-edu 저장소를 보면, Spring Cloud Gateway, Config Server, Service Discovery 기반의 마이크로서비스 아키텍처를 공식 교육 과정으로 제공하고 있다. 2026년 교육 과정도 초급/고급/심화로 개편되었다.

그러나 핵심적인 문제가 있다. eGovFrame 4.3은 Spring 5 / Spring Boot 2.x 기반이다. 2025년 11월에 Spring Boot 4가 GA 되었고, Spring Boot 3.5의 무료 지원도 2026년 6월에 종료된다. 업스트림이 두 세대나 앞서 나간 상황에서, eGovFrame의 다음 메이저 버전이 언제 나올지는 아직 공식 로드맵이 없다.

---

Spring Boot 4 시대, eGovFrame이 직면한 기술 격차

Spring 생태계는 2025~2026년에 걸쳐 세대교체를 완료했다. eGovFrame이 따라잡아야 할 격차를 구체적으로 보자.

javax → jakarta 패키지 전환

Spring Boot 3부터 javax.* 패키지가 jakarta.*로 전면 교체되었다. Spring Boot 4에서는 javax.servlet, javax.persistence 등이 완전히 제거되었다. eGovFrame의 254개 공통컴포넌트가 모두 이 전환을 거쳐야 한다는 뜻이다. 단순 find-replace가 아니라, 의존하는 서드파티 라이브러리 전체의 호환성을 검증해야 하는 작업이다.

Java 17 최소 기준선

Spring Boot 4의 최소 Java 버전은 17이다. Java 25까지 공식 지원한다. 반면 eGovFrame은 여전히 Java 8을 기준선으로 잡고 있다. 공공기관의 운영 환경이 Java 8에 머물러 있는 현실과, 최신 프레임워크가 요구하는 기준선 사이의 간극이 점점 벌어지고 있다.

Hibernate ORM 7.1 / Jakarta Persistence 3.2

Spring Boot 4는 Hibernate ORM 7.1을 탑재했다. detached entity의 재연결(reassociation) 방식이 변경되는 등 JPA 사용 패턴 자체가 달라졌다. eGovFrame은 여전히 MyBatis 중심인데, JPA/Hibernate를 함께 지원하는 공통컴포넌트가 이 변화를 수용하려면 상당한 리팩토링이 필요하다.

JSpecify Null Safety

Spring Framework 7은 JSpecify 어노테이션을 포트폴리오 전체에 적용해 컴파일 타임 null 안전성을 제공한다. Kotlin 2.2와도 자동 연동된다. 이건 eGovFrame이 직접 대응할 영역은 아니지만, Spring 생태계 전반의 코드 품질 기준이 올라갔다는 신호다.

---

JSP의 운명: 죽지 않았지만, 이미 퇴장 중

기술적 현실

JSP(JavaServer Pages) 자체가 "deprecated"로 선언된 적은 없다. Jakarta Server Pages는 Jakarta EE 11에도 여전히 포함되어 있다. 하지만 사실상(de facto) 퇴장이 진행 중이다.

Spring Boot에서 JSP의 위치:

• Spring Boot는 초기부터 JSP 대신 Thymeleaf를 권장해왔다
• 내장 톰캣에서 JSP를 쓰려면 별도 의존성(tomcat-embed-jasper)과 WAR 패키징이 필요하다
• Spring Boot의 fat-jar 배포 모델과 JSP는 구조적으로 궁합이 맞지 않는다
• Spring Boot 4에서 JSP가 제거된 것은 아니지만, 공식 문서와 예제에서 JSP는 사실상 언급되지 않는다

프론트엔드 패러다임의 전환:

2026년의 웹 개발은 백엔드와 프론트엔드의 분리가 기본값이다. 서버가 JSON API만 제공하고, 프론트엔드는 React/Vue/Next.js 등의 SPA(또는 SSR) 프레임워크가 담당한다. JSP는 서버에서 HTML을 생성하는 SSR(Server Side Rendering) 방식인데, 이 모델은 다음과 같은 한계를 갖는다.

• 모바일 앱이나 외부 연동을 위해 별도 API를 다시 만들어야 한다
• 프론트엔드 개발자와 백엔드 개발자의 역할 분리가 어렵다
• 컴포넌트 재사용, 상태 관리, 라우팅 등 현대 UX 요구사항을 충족하기 어렵다
• CDN 캐싱, 정적 배포 등 성능 최적화 전략을 적용하기 어렵다

한국 SI 현장의 현실

그럼에도 JSP는 한국 SI 현장에서 아직 살아 있다. 이유는 기술적이 아니라 구조적이다.

발주처가 eGovFrame을 요구한다. 공공기관 정보화 사업의 RFP(제안요청서)에 "전자정부표준프레임워크 적용"이 명시되어 있으면, 수주 업체는 eGovFrame을 써야 한다. 그리고 eGovFrame의 공통컴포넌트 상당수가 JSP 기반 뷰를 포함하고 있다.

기존 시스템이 JSP로 되어 있다. 유지보수 사업에서 "기존 시스템과 동일한 기술 스택"은 암묵적 요구사항이다. JSP로 만들어진 시스템의 유지보수를 React로 하겠다고 제안하면, 발주처 입장에서는 리스크다.

개발 인력 수급 문제. 하청-재하청 구조에서 투입되는 개발자의 다수가 JSP + jQuery + MyBatis 스택에 익숙하다. 새로운 기술 스택으로의 전환은 재교육 비용과 일정 리스크를 수반하며, 이를 감당할 여유가 SI 프로젝트 구조에는 거의 없다.

---

eGovFrame의 MSA 템플릿: 변화의 조짐

eGovFrame 4.x에서 가장 주목할 변화는 MSA 템플릿의 공식화다. egovframe-msa-edu 저장소를 보면, 프론트엔드가 React 기반으로 분리되어 있다. 백엔드는 Spring Cloud 기반 마이크로서비스, 프론트엔드는 SPA로 구성되는 구조다.

이것은 eGovFrame 진영에서도 "JSP 중심의 모놀리식 구조"가 더 이상 유일한 선택지가 아님을 공식적으로 인정한 것이다. 2025년 11월 128차 세미나에서는 K-PaaS(구 PaaS-TA)와의 연계, 카카오클라우드 콜라보가 진행되었고, MSA 포함 템플릿 프로젝트 컨트리뷰션 실습까지 다루었다.

다만, 이 MSA 템플릿이 실제 공공 SI 사업에서 채택되는 비율은 아직 극히 낮다. 대부분의 중소규모 공공 사업은 여전히 모놀리식 + JSP + MyBatis 조합이다. MSA 템플릿은 "대규모 클라우드 네이티브 사업"을 위한 선택지로 제시되고 있을 뿐, 표준 선택지를 대체하지는 못하고 있다.

---

5년 후를 내다본 예측

eGovFrame 5.0은 올 것인가?

Spring Boot 3.5의 무료 지원이 2026년 6월에 종료된다. eGovFrame이 Spring 5 기반에 머물러 있으면, 보안 패치를 받지 못하는 구간이 점점 늘어난다. eGovFrame 5.0(또는 그에 준하는 메이저 업데이트)이 Spring Boot 3.x 이상, Jakarta EE 10+ 기반으로 나오는 것은 시간문제다. 다만, 254개 공통컴포넌트의 javax → jakarta 전환과 호환성 테스트를 고려하면, 2027년 이전에 나오기는 쉽지 않을 것이다.

JSP는 언제 사라지는가?

JSP는 "특정 시점에 사라지는" 기술이 아니다. 마치 COBOL처럼, 새로운 프로젝트에서는 선택되지 않지만, 기존 시스템에서는 수십 년간 유지되는 기술이 될 가능성이 높다.

구체적으로 예측하면:

• 신규 공공 SI 사업: 2028년경이면 RFP에 "SPA 프론트엔드 + REST API 백엔드" 구조가 보편화될 것이다. eGovFrame의 MSA 템플릿이 그 교두보 역할을 하고 있다.
• 기존 시스템 유지보수: JSP 기반 시스템은 2030년대 중반까지도 운영될 것이다. 이 시스템들의 유지보수 인력 수요는 감소하겠지만, 완전히 사라지지는 않는다.
• 개발자 커리어: "JSP만 할 줄 아는 개발자"의 시장 가치는 이미 하락세에 있다. React/Vue + Spring Boot(API 서버) 조합을 기본으로 갖추지 않으면, SI에서도 점점 입지가 좁아진다.

Thymeleaf은 대안인가?

JSP의 "바로 다음 세대" SSR 기술로 Thymeleaf이 자주 거론된다. Spring Boot가 공식 권장하는 템플릿 엔진이기도 하다. Thymeleaf은 순수 HTML로도 브라우저에서 미리보기가 가능해 퍼블리셔와의 협업이 수월하고, Spring Boot의 fat-jar 배포와도 잘 맞는다.

하지만 Thymeleaf도 결국 SSR이다. API 서버 + SPA 구조가 대세인 상황에서, Thymeleaf은 "가벼운 관리자 페이지"나 "내부 백오피스" 수준에서 선택되는 기술이지, 대규모 공공 서비스의 메인 뷰 기술로 자리잡기는 어렵다.

---

SI 개발자를 위한 현실적 제언

지금 당장

• Spring Boot 3.x → 4.x 전환의 핵심 포인트(javax→jakarta, Hibernate 6→7, Jackson 2→3)를 파악해두자. eGovFrame이 언제 따라오든, Spring 생태계의 방향 자체는 변하지 않는다.
• React 또는 Vue 기본기를 익혀두자. 프론트엔드 전문가가 될 필요는 없지만, REST API를 설계하고 SPA와 연동하는 구조를 이해하는 것은 백엔드 개발자에게도 필수다.

중기적으로

• eGovFrame MSA 템플릿을 직접 돌려보자. GitHub에 교육 소스가 공개되어 있다. Spring Cloud Gateway, Config Server, Service Discovery 구조를 eGovFrame 맥락에서 경험해두면, 향후 클라우드 네이티브 공공 사업에서 경쟁력이 된다.
• K-PaaS(구 PaaS-TA) 생태계를 주시하자. 정부의 클라우드 전환 정책과 맞물려, 컨테이너 기반 배포가 공공 SI에도 점진적으로 확산되고 있다.

장기적으로

• JSP + MyBatis + eGovFrame만으로는 개발자 커리어가 정체된다. 서비스 회사든 SI든, 도메인 이해력 + 현대적 아키텍처 설계 능력이 차별화 요소가 되는 시대다.
• AI 코딩 도구(Claude Code, GitHub Copilot 등)가 보일러플레이트 코드 생성을 대체하고 있다. 개발자의 가치는 "코드를 치는 속도"가 아니라 "무엇을 만들어야 하는지 판단하는 능력"에 있다.

---

마무리

전자정부프레임워크는 죽지 않는다. MSA 템플릿, 클라우드 네이티브 교육 과정, K-PaaS 연계 등 변화의 조짐은 분명히 있다. 하지만 그 변화 속도가 Spring 생태계의 발전 속도를 따라잡기에는 구조적으로 느리다.

JSP도 죽지 않는다. 다만, 새로운 가치를 창출하는 기술로서의 수명은 이미 다했다. 유지보수 기술로서의 수명만 남아 있다.

결국 개발자 개인의 선택이 중요하다. eGovFrame이 바뀌길 기다리기보다, Spring Boot 4 + SPA + 클라우드 네이티브라는 업스트림의 방향에 먼저 올라타는 것이 현실적인 전략이다. eGovFrame은 결국 그 방향으로 따라올 수밖에 없으니까.