10년 전에 만든 JSP · Spring 시스템이 아직 잘 돌아가고 있다면, 대부분 보안 지원이 끝난 버전 위에서 돌아가고 있을 가능성이 큽니다. 지원이 끝난 버전은 새 취약점이 나와도 패치가 나오지 않습니다. 업그레이드를 고민하기 전에, 먼저 지금 버전부터 정확히 확인하세요.
1. 우리 시스템 버전 확인하는 법
개발자가 없어도 서버 접속 권한만 있으면 대부분 확인할 수 있습니다.
| 확인 대상 | 확인 방법 |
|---|---|
| Java | 서버에서 java -version 실행. Tomcat이 다른 Java를 쓰는 경우가 있어 setenv.sh · 서비스 설정의 JAVA_HOME도 확인 |
| Tomcat | Tomcat 폴더의 bin/version.sh(윈도우는 version.bat) 실행, 또는 lib/catalina.jar 버전 확인 |
| Spring · 전자정부 프레임워크 | 배포 폴더 WEB-INF/lib의 jar 파일 이름 확인. 예: spring-core-4.3.25.RELEASE.jar, egovframework.rte.*-3.x.jar |
| Spring Boot | 소스의 pom.xml · build.gradle에서 spring-boot 버전 확인. 소스가 없으면 실행 jar 안의 BOOT-INF/lib 목록 확인 |
| Log4j 등 라이브러리 | WEB-INF/lib에서 log4j-1.2.x.jar, log4j-core-2.x.jar, struts, commons-fileupload, jackson-databind 파일 이름과 버전 확인 |
소스와 운영 서버의 버전이 다른 경우도 많습니다. 만든 업체가 마지막에 운영 서버에만 직접 반영하고 소스를 남기지 않았다면, 운영 서버 파일이 기준입니다.
2. 보안 지원이 끝난 버전
| 구분 | 지원 종료 | 비고 |
|---|---|---|
| Tomcat 7 | 2021년 3월 | Tomcat 8.0은 2018년 6월 종료 |
| Tomcat 8.5 | 2024년 3월 | Tomcat 9 이상으로 전환 필요 |
| Spring Framework 4.3 | 2020년 12월 | 전자정부 표준프레임워크 3.x가 Spring 4 기반 |
| Spring Framework 5.3 | 2024년 8월 (오픈소스 지원) | 이후 Spring 6은 Java 17 이상 필요 |
| Spring Boot 2.7 | 2023년 11월 (오픈소스 지원) | Spring Boot 3.x는 Java 17 이상 필요 |
| Log4j 1.x | 2015년 8월 | Log4j 2.x도 2.17.1 미만은 알려진 취약점(Log4Shell 등) 있음 |
| Java 6 · 7 | 공개 업데이트 종료 | Java 8은 배포판에 따라 지원 중이나, 신규 라이브러리 지원이 줄고 있음 |
보안점검에서 "지원 종료 소프트웨어 사용"이나 "취약한 라이브러리 사용"으로 지적받는 경우가 대부분 이 목록에 해당합니다.
3. 운영을 멈추지 않는 업그레이드 순서
한 번에 모든 버전을 올리면 어디서 문제가 생겼는지 찾기 어렵습니다. 위험이 큰 것부터, 바꾸는 범위가 작은 것부터 단계를 나눕니다.
- 현황 정리와 백업 — 위 방법으로 버전 목록을 만들고, 운영 서버 파일 · DB를 백업합니다.
- 빌드 환경 복구 — 소스로 운영 서버와 같은 결과물을 만들 수 있는지 먼저 확인합니다. 빌드가 안 되면 아무것도 고칠 수 없습니다.
- 긴급 취약 라이브러리 교체 — Log4j · Struts · Commons FileUpload처럼 원격 공격이 가능한 취약점부터 교체합니다. 대부분 코드 수정이 적습니다.
- WAS 교체 — Tomcat 7 · 8.5를 Tomcat 9로 옮깁니다. Tomcat 9는 기존
javax기반 코드를 그대로 쓸 수 있어 부담이 적습니다. - Java 버전 업 — Java 6 · 7 · 8을 Java 11 · 17로 옮기고, 삭제된 API와 깨지는 라이브러리를 수정합니다.
- 프레임워크 업그레이드 — Spring 4 → 5.3, 전자정부 3.x → 4.x처럼 같은
javax계열 안에서 먼저 올립니다. Spring 6 · Spring Boot 3은javax를jakarta로 바꾸고 Tomcat 10.1 이상이 필요해 사실상 별도 프로젝트로 계획하는 것이 안전합니다.
4. 업그레이드 전에 꼭 정할 것
- 테스트 범위: 로그인, 조회 · 저장, 파일 업로드 · 다운로드, 엑셀 출력, 배치처럼 업무에 꼭 필요한 기능 목록
- 되돌리기 계획: 문제가 생기면 몇 분 안에 이전 버전으로 돌아갈 수 있는지
- 반영 시간: 사용자가 적은 시간대와 공지 방법
정리
오래된 Java 시스템은 "잘 돌아가니까 괜찮다"가 아니라, 지원 종료 버전 위에서 운이 좋게 버티고 있는 상태일 수 있습니다. 버전 확인은 하루면 끝나고, 그 결과로 무엇을 먼저 고칠지 정할 수 있습니다. 만든 업체와 연락이 끊긴 JSP · Spring · 전자정부 프레임워크 시스템의 진단과 단계적 업그레이드는 Java · Spring · JSP 유지보수에서 자세히 볼 수 있습니다.