Composite PK에서 시작된 Spring Boot 4 / Spring Batch 6 업그레이드 기록
Spring Data JDBC 의 Composite ID 적용을 위해 Spring Boot 3.5 → 4.0.1 업그레이드 시 Spring Batch, Kotlin, Jackson 등 전체 스택 메이저 전환 필요.
Spring Data JDBC 의 Composite ID 적용을 위해 Spring Boot 3.5 → 4.0.1 업그레이드 시 Spring Batch, Kotlin, Jackson 등 전체 스택 메이저 전환 필요.
이벤트 기반 알림 서비스가 JVM 기동 시간(4.784초)으로 콜드스타트 병목이 발생해 스케일아웃 대응이 느렸다.
Kubernetes 위 Spring Boot 서버가 평균 90초, Pod 별 55~130초 부팅으로 배포/스케일링이 느렸다.
레거시 알림톡 발송 로직이 여러 비즈니스 코드에 산재되고 데이터 조회 기준이 달라 일관성이 부족했다.
1,300 개 매장의 수백만 종이라벨을 수동 관리하면서 프로모션 기간 업무 과중과 재고 정보 지연이 반복됐다.
SQS 이벤트 기반 알림톡 시스템 전환 후 HikariPool 커넥션 데드락(30,000ms 타임아웃)이 발생했다.
백오피스에서 사용자 권한별(본사/매장/협력사)로 다른 보안 솔루션을 적용해야 하는데 수십 개 다운로드 API마다 중복 로직이 필요했다.
당일 배송(오늘드림) 배달대행사별 콜백 API가 12개로 난잡했고, REQUIRES_NEW 트랜잭션 옵션 하나가 피크 시간대 Connection Pool을 고갈시켜 서버 응답 불가 장애를 일으켰다.
외부 Batch Scheduler 솔루션의 지속적 운영 비용·커스터마이징 한계·장애 대응 어려움으로 내재화가 필요했다.
마이크로서비스 환경에서 설정값 하나를 변경하면 관련 서비스 전체를 재빌드·재배포해야 해 평균 20분 소요, 서비스 가용성 저하
긴 스택 트레이스가 Slack에 뭉텅 쏟아져 근본 원인 파악에 시간 낭비, 개발자가 외부 도구 없이 빠른 분석이 어려운 상황
사립학교교직원연금 같은 복잡한 한국어 세금 도메인을 영어 변수명으로 표현하면 가독성이 극도로 낮아진다.
@CircuitBreaker + @Cacheable 이중 어노테이션의 복잡성과 Cache Stampede(캐시 만료 시 DB 동시 요청 폭주) 문제로 API 응답이 급격히 지연됐다.
3인 팀이 퀸잇에서 포크된 팔도감을 MSA로 운영하면서 여러 저장소·서버 관리 오버헤드, API 호환성 문제, 인프라 비용 증가로 생산성이 저하됨.
최대할인 서비스의 쿠폰 API를 Spring Boot 2.7.1에서 Spring Boot 3.x 사내 서비스로 옮긴 뒤 Old gen에 Micrometer 객체가 GC되지 않고 쌓이는 메모리 누수가 발생했다.
카카오스타일 PDP는 약 20개 마이크로서비스에서 실시간 데이터를 끌어모으는 구조라 외부 입출력 변경이 잦았고, 이로 인해 도메인 로직에 잔잔한 변경이 자꾸 전이됐다.
모놀리스에서 마이크로서비스를 분리하는 작업을 진행하면서 기능 개발과의 Git 충돌, QA 지연으로 인한 배포 블로킹이 반복됨.
레거시 DB를 DDD로 재설계하면서 멀티 테넌트 배포 환경(외부/내부 API 분리)을 코드 중복 없이 지원해야 했다.
Replica Set 환경에서 MongoDB 트랜잭션 도입 시 Primary-Secondary 복제 지연으로 인한 데이터 불일치와 SQS 메시지 조기 발행 문제가 발생했다.
Spring Boot 애플리케이션 시작 시 콜드 스타트로 초기 요청 지연, DB/Redis 연결 풀 미초기화, 헬스 체크 오탐 문제가 있었다.