Spring Boot 4에서 spring.threads.
정산 배치가 3원 차이로 불일치를 내뱉기 시작한 건 Spring Boot 4 올린 지 열흘째 되는 날이었다. API 서버는 멀쩡했다.
Spring Boot 4로 올리면서 kotlinx.serialization 스타터도 같이 넣었다.
새벽 2시, Grafana에서 CPU 사용률 경보가 울렸다. 트래픽은 평소의 절반도 안 되는데 서버 파드 4개가 전부 CPU 80%를 넘기고 있었다.
요즘 이상한 현상이 하나 있다. GitHub Copilot, Claude, Cursor — 도구는 전보다 10배는 좋아졌는데, 주니어 개발자들의 야근은 줄지 않았다.
새벽 2시 47분, 슬랙에 알림이 쏟아졌다. 결제 API 응답률 0%.
CS팀에서 "고객이 같은 알림 메일을 여러 통 받는다"는 티켓이 올라온 건 금요일 오후였다. 재현도 안 되고, 로그도 깨끗하고, 코드에 버그도 없었다.
프로덕션 배포가 끝나면 Grafana를 5분 정도 지켜보는 게 루틴이었다. 그런데 어느 순간부터 배포 직후 consumer lag 그래프가 수직으로 치솟았다가 천천히 내려오는 패턴이 반복됐다.
금요일 밤 11시, PagerDuty가 울렸다. Redis 클러스터 마스터 1대가 메모리 부족으로 eviction을 시작했고, 페일오버가 진행되는 30초 동안 캐시 히트율이 98%에서 0%로 떨어졌다.
장애가 터지면 다들 영웅이 된다. Slack에 불 이모지가 날아다니고, 핫픽스 PR이 올라가고, 누군가 "resolved" 상태를 찍으면 팀 채널에 박수 이모지가 쏟아진다.
커스텀 메트릭 하나 추가한 게 전부였다. "사용자별 API 응답 시간 추적하면 좋겠다"는 PM의 요청에 @Timed 어노테이션에 userId 태그를 하나 끼워 넣었고, 스테이징에서 잘 돌았고, 배포했다.
쿠폰 발급 테이블에 동시 수정이 가능하다는 코드 리뷰가 달렸고, 다음 날 PR에 @Version 필드가 추가됐다. 낙관적 락을 걸면 충돌 시 예외가 터지니까 안전하다 — 이론적으로는 맞다.
새벽 3시, PagerDuty가 울린다. 런북 열고, 대시보드 확인하고, 슬랙에 타임라인 찍고, 롤백 판단하고 — 이 과정을 AI가 전부 해준다면?
readiness probe 설정할 때 "/actuator/health 쓰면 되죠?"라고 대답하는 개발자가 많다.
동시에 두 명이 포인트를 사용하면 잔액이 마이너스가 되지 않는 게 당연하다고 생각했다. 그 생각이 틀렸다는 걸 화요일 오후 CS 인입량이 알려줬다.
캐시 정리의 최적화라고 생각했다. 서비스 전체에 흩어진 @Cacheable 설정을 보니 TTL이 3분, 7분, 15분, 30분 — 제각각이었다.
새벽 2시, 슬랙 알림이 울린다. 결제 완료 후 포인트 적립이 안 됐다는 CS가 3건 들어왔다.
지난달 팀에서 Spring Boot 4로 올리면서 "Jackson 3? 패키지명만 바뀌었겠지"라고 생각했다.