Spring Boot 적용 중 확인한 설정·ORM·URL 호환성
인증 서비스 업그레이드에서는 실행 환경과 의존성 여러 영역을 함께 바꿨습니다. 이 글에서는 그중 기존 설정과 새 프레임워크의 동작을 맞추며 확인한 내용을 정리합니다.
수동 Bean과 자동 설정
기존에는 DataSource와 TransactionManager, ObjectMapper, HTTP 클라이언트와 필터를 직접 등록했습니다. Boot를 추가한 뒤에는 각 Bean을 계속 유지할지, 자동 설정에 맡길지 판단해야 했습니다.
자동 설정이 언제나 같은 타입의 Bean을 하나 더 만드는 것은 아닙니다. @ConditionalOnMissingBean처럼 기존 Bean 유무를 보고 등록하지 않는 구성이 많습니다. 반대로 직접 만든 Bean 때문에 기대한 자동 설정이 적용되지 않을 수도 있습니다.
그래서 실제 등록된 Bean과 자동 설정 조건을 확인하고, 커넥션 풀·타임아웃·직렬화 옵션을 비교했습니다. RestTemplateBuilder를 제공하는 것과 RestTemplate Bean을 자동으로 만드는 것도 다릅니다. 기존 설정을 지울 때는 옵션이 새 구성에 어디로 옮겨졌는지 확인해야 했습니다.
이름이 같은 Bean의 덮어쓰기 허용 여부도 설정에 따라 다릅니다. 충돌을 피하려고 override를 일괄 허용하거나 @Primary만 붙이기보다, 중복 등록의 원인과 필요한 대상을 먼저 구분해야 했습니다.
Hibernate 쿼리와 타입 매핑
Hibernate 4에서 6으로 옮기며 기존 Session.createCriteria()와 org.hibernate.criterion 기반의 쿼리를 JPA Criteria로 바꿨습니다. 조건 검색뿐 아니라 조인 결과와 중복 처리, DTO 변환도 같이 확인해야 했습니다.
예를 들어 예전 Criteria 코드와 새 CriteriaQuery가 같은 목록을 반환하는지, 조회 건수와 페이지 처리가 달라지지 않는지 확인해야 합니다. 컴파일 오류를 고쳤다는 이유로 쿼리의 의미까지 같아지는 것은 아닙니다.
결과 변환 API도 구분할 필요가 있습니다. Hibernate 6.5에는 setResultTransformer()가 deprecated 상태로 남아 있고, 새 코드에는 setTupleTransformer()와 setResultListTransformer()가 권장됩니다. 기존 Criteria API의 제거와 결과 변환 API의 상태를 같은 변화로 설명할 수는 없습니다.
커스텀 타입은 새 타입 API에 맞추되 기존 DB 값을 읽고 다시 저장할 수 있는지 확인해야 했습니다. Java 타입 변환 성공과 기존 데이터 호환성은 별도로 봐야 했습니다.
후행 슬래시와 경로 매칭
QA에서는 /api/users로 선언한 API를 /api/users/로 호출할 때 404가 발생하는 문제도 확인했습니다. 기존 클라이언트가 사용하던 URL 형태까지 점검해야 했던 부분입니다.
Spring Framework 6에서는 URL 끝의 슬래시를 자동으로 처리하는 기본 설정이 달라졌습니다. 정규화 필터나 프록시, 명시적인 매핑 등 적용 버전과 호환성 요구에 맞는 방법을 선택해야 합니다. UrlHandlerFilter는 6.2부터 제공되므로 모든 Boot 3 조합에서 바로 사용할 수 있는 것은 아닙니다.
정규화가 필요하다면 Security의 경로 판단과 컨트롤러 매칭이 같은 경로를 보도록 순서도 맞춰야 합니다. AntPathMatcher로 바꾸는 것만으로 모든 후행 슬래시와 권한 문제가 해결되지는 않습니다.
인증 필터와 권한 확인
Spring Security에서는 기존 adapter 기반 구성을 SecurityFilterChain Bean 방식으로 옮겼습니다. 로그인과 토큰 검증, Basic Auth를 사용하는 경로, API 문서 접근, 환경별 설정을 함께 확인해야 했습니다.
인증 필터 뒤에 사용자 정보를 로그 문맥에 넣는 처리도 연결되어 있었습니다. 필터 순서가 바뀌면 인증은 되더라도 MDC에 정보가 없거나 이전 요청의 값이 남을 수 있습니다. 허용된 요청과 거부할 요청, 인증되지 않은 요청을 각각 확인하는 것이 필요했습니다.
테스트와 설정 이전
작업에서 시간이 많이 든 부분은 테스트였습니다. Hibernate와 Mockito, Spring 테스트 컨텍스트가 함께 바뀌어 기존 테스트 설정과 mock을 새 API에 맞춰야 했습니다. 기존 테스트가 없던 경로는 비교할 동작부터 정리해야 했습니다.
테스트 코드의 변경량과 제품 코드의 변경량은 달랐습니다. 컴파일과 기동을 먼저 확인한 뒤 인증·권한·DB 조회를 맞추고, 실제 호출자의 URL과 오류 응답까지 확인하며 범위를 넓혔습니다.
이렇게 내부 구성을 정리한 뒤에는 내보내기 서비스의 컨테이너 플랫폼 전환 POC 같은 실행 환경 작업도 이어졌습니다.