인증 서비스의 Spring 4·Java 8 업그레이드
여러 관리자 애플리케이션에서 사용하는 인증 서비스를 Spring Boot 3와 Java 21로 올렸습니다. 기존 서비스는 Spring Boot 없이 Spring Framework 4와 Java 8을 사용했고, web.xml과 XML·Java 설정으로 구성한 WAR를 외장 Tomcat에 배포하는 구조였습니다.
로그인과 사용자 정보, 권한 확인을 여러 서비스가 호출하고 있었기 때문에 기존 동작을 유지하는 것이 중요했습니다. 런타임만 바꾸는 작업이 아니라 보안과 데이터 접근, 테스트 설정을 함께 옮겨야 했습니다.
함께 바꾼 라이브러리
| 영역 | 기존 구성 | 전환한 구성 |
|---|---|---|
| 런타임 | Java 8 | Java 21 |
| 프레임워크 | Spring Framework 4 | Spring Boot 3·Spring Framework 6 |
| 보안 | Spring Security 4 | Spring Security 6 |
| ORM | Hibernate 4 | Hibernate 6 |
| 설정 | web.xml과 수동 설정 | Java Config와 Boot 설정 |
| 테스트·문서·계측 | 구버전 테스트·문서 라이브러리와 메트릭 | 새 프레임워크와 호환되는 구성 |
Jakarta 전환에 맞춰 엔티티와 Servlet·Validation 관련 API도 바꿨습니다. 내부 토큰 검증 라이브러리처럼 프레임워크에 의존하는 코드도 함께 확인해야 했습니다.
PR은 추가 약 1만 6천 줄, 삭제 약 1만 4천 줄 규모가 됐습니다. 그만큼 새 기능을 만든 것은 아니었습니다. 기존 동작을 새 라이브러리로 옮기고 테스트를 다시 맞추는 변경이 많았습니다.
운영 반영 전 테스트
새 버전은 운영을 제외한 사전 환경에 배포해 검증하고 있었습니다. 인증 서비스를 사용하는 팀에서도 각자의 애플리케이션에서 로그인과 권한 조회가 유지되는지 확인해야 했습니다.
특히 자동 설정과 수동 Bean의 관계, Hibernate 쿼리·타입 매핑, 보안 필터와 테스트 컨텍스트를 맞추는 데 시간이 들었습니다. 변경이 서로 연결되어 있어 리뷰 범위도 커졌습니다. 이 내부 작업은 Spring Boot 적용 중 확인한 호환성 문제에서 따로 설명합니다.
기존 버전에서 발생한 기동 장애
운영 배포 일정을 잡기 전에 기존 서비스에서 장애가 발생했습니다. 당시 환경에서 XML의 XSD 참조 과정이 인증서 검증 실패로 막혀 설정을 읽지 못한 문제였습니다. Zero Trust 환경 변화와 컨테이너의 신뢰 인증서 구성이 연결된 상황이었습니다.
기존 이미지를 다시 배포해도 같은 설정과 인증서 조건을 사용하므로 해결되지 않았습니다. 새 버전은 XML 설정을 Java Config와 속성 설정으로 옮겨 둔 상태였고, 해당 XML 파싱 경로를 사용하지 않았습니다.
글로벌 팀에서는 UAT까지 진행한 새 버전을 운영에 올렸습니다. 이 결정과 배포는 한국 팀이 자고 있던 시간에 이뤄졌고, 저는 아침에 배포가 끝났으며 정상 기동했다는 소식을 들었습니다. 예정대로 기다린 배포는 아니었지만, 앞서 진행한 사전 검증이 있었기에 선택할 수 있었던 경로였습니다.
인증서와 후속 확인
이후에는 컨테이너에 필요한 내부 Root CA가 포함되어 있는지, 런타임의 trust store가 실제 통신 경로와 맞는지도 확인할 항목으로 봤습니다. 같은 설정 파일이라도 스키마가 클래스패스와 외부 주소 중 어디에서 해석되는지에 따라 결과가 달라질 수 있습니다.
XML을 없앴다는 이유로 모든 외부 통신의 인증서 문제가 해결되는 것은 아닙니다. 새 버전에서도 필요한 HTTPS 연결과 토큰 검증, 사용자·권한 조회를 계속 확인해야 했습니다.
업그레이드 이후의 작업
기반 버전을 올린 뒤 구조화 로깅과 비동기 문맥 전파, 감사 이벤트 처리를 이어서 정리했습니다. 취약점 검사와 품질 확인도 배포 과정에서 함께 다뤘습니다.
한 번에 많은 코드가 바뀌면서 리뷰와 검증 부담이 컸다는 점은 남았습니다. 다음 작업에서는 실행 환경과 의존성, 실제 기능의 호환성을 더 작은 범위로 확인할 수 있도록 준비할 필요가 있었습니다.