결제 서비스가 8개월 동안 아무 문제 없이 돌다가 금요일 밤 자정에 터졌다. HikariPool-1 - Connection is not available, request timed out after 30000ms.
3월 12일 오후 2시 17분, AWS 3개 리전에서 동시에 5xx 알림이 쏟아지기 시작했다. 원인은 DDoS도 아니고 코드 배포도 아니었다 — cert-manager 크론잡 하나가 Let's Encrypt에 14,000개의 인증서 발급 요청을 90초 만에 쏟아부은 게 전부였다.
6월에 동료가 PR을 하나 올렸다. 제목은 "chore: Resilience4j 의존성 제거, Spring 7 내장 @Retryable로 전환.
올해 상반기에만 Spring 생태계에서 서버 사이드 요청 위조 관련 CVE가 세 건 터졌다. Spring AI Bedrock(CVE-2026-22742), Spring Authorization Server(CVE-2026-22752), Spring Cloud Config까지.
금요일 오후 4시 47분, 슬랙에 배포 성공 알림이 초단위로 쏟아졌다. "누가 릴리스 브랜치 잘못 건드렸나?
주문 완료 후 알림을 보내는 코드에 @Async를 붙인 건 금요일 오후였다. 월요일 아침, CS팀에서 연락이 왔다.
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 필드가 추가됐다. 낙관적 락을 걸면 충돌 시 예외가 터지니까 안전하다 — 이론적으로는 맞다.