Spring Boot 4/Batch 6 업그레이드, Composite PK 지원을 위한 여정
Spring Data JDBC의 Composite ID 지원을 위해 Spring Boot 4로 업그레이드를 시작했으나, Spring Batch 6, Kotlin, Jackson, Gradle 등 기술 스택 전반의 업그레이드로 확대됨
Spring Batch 6으로의 전환 과정에서 Job 실행 API, Listener 모델, 메타데이터 저장 방식 등 핵심 기능들의 변경 사항을 상세히 분석하고, 마이그레이션 과정에서 발생한 문제점들을 제시함
운영 환경 적용 후 DB 접근 정책 문제 발생, 세션 식별자 변경으로 인한 문제 해결 과정을 공유하며, 운영 환경에서의 사전 점검의 중요성을 강조함
Spring Batch 6 주요 변경 사항 분석
Spring Batch 6으로의 업그레이드는 단순히 의존성 버전 변경 이상의 의미를 가진다. JdbcDefaultBatchConfiguration과 ResourcelessJobRepository 분리로 JDBC 기반 메타데이터 저장 설정을 명확히 해야 하며, JobOperator를 통해 Job 실행 API를 변경해야 한다. 또한, JobParameters의 내부 컬렉션이 Map에서 Set으로 변경되어, 파라미터 처리 로직을 수정해야 한다. 특히, Spring Batch 5에서 실패한 JobExecution은 Spring Batch 6에서 재시작할 수 없으므로, 업그레이드 전에 미완료 JobExecution을 정리해야 한다.
Kotlin 코드에서 Nullable 처리 전략
Spring Batch 6에서 FieldSet.readString(name)의 반환 타입이 @Nullable로 변경됨에 따라, Kotlin 코드에서 NPE(NullPointerException) 발생 가능성이 높아졌다. 저자는 확장 함수(Extension Function)를 활용하여, readStringOrEmpty, readStringOrThrow 등과 같은 안전한 null 처리 로직을 구현했다. 이를 통해 코드의 가독성을 높이고, 잠재적인 널 관련 오류를 방지했다. 이처럼 라이브러리 변경에 유연하게 대처하는 확장 함수 활용은 유지보수성을 향상시키는 효과를 가져온다.
운영 환경에서 발생한 DB 접근 문제
업그레이드 후 운영 환경에서 DB 접근 문제가 발생했는데, 이는 세션 식별자(Session Identifier) 변경과 운영 DB 접근 정책의 충돌로 인한 것이었다. 기존 JDBC Thin Client에서 JarLauncher로 세션 식별자가 변경되면서, 운영 DB 접근 정책에 등록된 클라이언트 프로그램명과 매칭되지 않아 접속이 차단되었다. 이 문제를 해결하기 위해, 운영 측 정책에 새로운 클라이언트 식별자를 등록하고, 운영 반영 체크리스트에 세션의 client program 값을 확인하는 항목을 추가했다. 이는 운영 환경의 정책과 테스트의 중요성을 보여준다.
Spring Boot 4 업그레이드 시 고려 사항
Spring Boot 4로 업그레이드하면서, Spring Framework 7, Kotlin 2.3, Jackson 3, Kotest 6, ojdbc11, Gradle 9 등 다양한 기술 스택의 업그레이드가 함께 진행되었다. Gradle Plugin은 Gradle 8.14 이상 또는 Gradle 9.x를 지원하므로, Gradle 버전을 함께 업그레이드해야 한다. 또한, Spring Boot 4는 Java 17 이상, Kotlin 2.2 이상을 요구하며, javax.* 의존성, Servlet/JPA/Validation 관련 API 영향에 대한 확인이 필요하다. spring-boot-properties-migrator 의존성을 활용하여 프로퍼티 변경 사항을 확인하는 것도 좋은 방법이다.
Composite ID 적용과 엔티티 모델 설계
Spring Data JDBC 4.0부터 Composite ID 매핑이 정식 지원되면서, 복합 키(Composite PK)를 가진 엔티티를 더욱 간결하게 표현할 수 있게 되었다. 저자는 SettlementMappingId를 @Id로 사용하고, Persistable 인터페이스를 구현하여 신규 엔티티 여부를 명시하는 방식을 선택했다. 이 방식은 save/findById뿐 아니라 derived query / AggregateReference 조합까지 SQL 동작을 직접 확인해야 한다. 또한, Composite PK 테이블에서 @Id를 한 컬럼에만 붙이는 우회 방식은 데이터 불일치 문제를 야기할 수 있으므로, Spring Data JDBC 4.0의 Composite ID 지원을 활용하는 것이 바람직하다.
