조용한 개발 노트

7편에서는 NESTED 전파 옵션이“이론적으로는 가능하지만, 실무에서는 거의 선택되지 않는 이유”를 살펴봤습니다.이제 Spring Transaction에서 가장 많이 오해되고, 가장 많은 장애를 만드는 질문으로 넘어가야 합니다.왜 RuntimeException만 롤백되고, Checked Exception은 기본 커밋될까?이 질문에 답하지 못하면,“분명 예외가 났는데 왜 커밋됐지?”“rollbackFor를 왜 써야 하지?”“예외 설계는 트랜잭션과 무슨 관계지?”같은 혼란을 끝없이 반복하게 됩니다.1. 먼저 사실부터 정리하자Spring의 기본 롤백 규칙은 아주 명확합니다.RuntimeException과 Error → 롤백Checked Exception → 커밋이 규칙은 버그도 아니고,JPA의 제약도 아닙니다..

47편에서는 Spring 서비스에서 모니터링·알림을 어떻게 설계해야 하는지를 정리했습니다.이번 글에서는 그 설계를 바탕으로,“실제로 장애가 터졌을 때 처음부터 끝까지 어떻게 대응해야 하는가”를 하나의 현실적인 시나리오로 따라가 보겠습니다.시나리오 개요배포 직후 일부 API 응답 지연p99 급등 + 에러율 증가사용자 체감 장애 발생이 상황에서 감 → 추측 → 수동 조작으로 가면 대응이 늦어집니다.대신,“정해진 흐름대로”움직이는 것이 핵심입니다.1단계. 첫 알림 – 무엇이 문제인가알림 시스템에서 다음과 같은 신호가 옵니다.p99 응답 시간 SLO 초과에러율 증가여기서 중요한 건:“증상이 무엇인지”를 명확히 하는 것입니다.이 단계에서는 원인을 추측하지 않습니다.2단계. 영향 범위 판단바로 다음 질문으로 넘어갑..

45편에서는 Rollback과 Canary 배포 전략을 통해 문제가 생겨도 빠르게 복구하는 운영 방식을 정리했습니다.이번 글에서는 그 전략을“사람이 아니라 파이프라인이 실행하게 만드는 방법”즉, Spring 서비스에 맞는 CI/CD 파이프라인 설계를 실무 기준으로 정리해보겠습니다.1. CI/CD 파이프라인의 목표좋은 CI/CD의 목표는 단순합니다.빠르게 배포하고문제가 있으면 즉시 멈추고안전하면 자동으로 확장즉,“배포 판단을 자동화한다”는 것입니다.2. Spring 서비스 기준 파이프라인 단계Spring + Kubernetes 환경에서 일반적인 CI/CD 파이프라인은 다음 단계로 구성됩니다.코드 변경 감지빌드 & 테스트이미지 생성배포 (Canary / Rolling)검증 (Health / Metric)확장..

44편에서는 Spring + Kubernetes 환경에서 무중단 배포를 구현하는 전략을 살펴봤습니다.하지만 실무에서는 이 질문이 반드시 뒤따릅니다.“배포 후 문제가 생기면 어떻게 빠르게 복구할 것인가?”이번 글에서는Rollback – 이미 배포된 것을 되돌리는 전략Canary – 문제를 사전에 감지하는 전략을 요청 흐름 기준으로 정리해보겠습니다.1. Rollback은 왜 별도 전략이 필요한가무중단 배포가 있어도,치명적인 버그성능 급락외부 연동 실패는 언제든 발생할 수 있습니다.이때 중요한 것은:“원인을 찾는 것”보다 “서비스를 살리는 것”입니다.그래서 Rollback은빠르고판단이 단순하며자동화되어 있어야합니다.2. Kubernetes에서의 기본 RollbackKubernetes Deployment는 기본..