테크커런트

Spring Framework 7 @Retryable 실전 설정: 지수 백오프·지터·재시도 예외 구분메타 설명: Spring Framework 7에 추가된 코어 @Retryable을 Spring Boot 4에서 활성화하고, 외부 API의 일시적 실패만 지수 백오프와 지터로 재시도하는 방법을 코드와 테스트로 설명합니다.외부 API가 한 번 타임아웃됐다는 이유로 요청을 즉시 실패시키면 복구 가능한 장애까지 사용자 오류가 됩니다. 반대로 모든 예외를 무조건 재시도하면 잘못된 요청을 반복하고, 장애 중인 서버에 트래픽을 더 보내며, 결제 같은 작업을 중복 실행할 수 있습니다.Spring Framework 7은 공통 재시도 기능을 코어에 포함했습니다. 기존 Spring Retry의 애노테이션과 이름은 같지만 패키..

Spring Bean Scope 실무 정리: Singleton·Prototype·Request 동작과 함정Spring의 @Service, @Repository, @Component는 별도 설정이 없으면 Singleton Bean으로 등록됩니다. 이 사실을 모르고 Bean 필드에 요청별 데이터를 저장하면 여러 사용자의 요청이 같은 값을 공유하는 동시성 문제가 생길 수 있습니다.반대로 Prototype을 사용했는데도 매번 새 객체가 만들어지지 않거나, Request Scope Bean을 비동기 작업에서 호출하다가 예외가 발생하기도 합니다.이번 글에서는 Singleton, Prototype, Request Scope의 생성 시점과 수명, 실무에서 자주 만나는 함정을 설명합니다.Bean Scope란 무엇인가Be..

Spring @TransactionalEventListener AFTER_COMMIT 함정: 저장 로직이 반영되지 않는 이유도입부주문 트랜잭션이 성공한 뒤 이메일을 보내거나 후속 상태를 저장할 때 @TransactionalEventListener를 사용할 수 있다. 기본 실행 시점은 AFTER_COMMIT이므로 커밋 성공 후에만 처리해야 하는 작업에 잘 맞는다.문제는 리스너에서 엔티티를 수정했는데 예외 없이 끝나면서도 DB에 반영되지 않는 상황이다. AFTER_COMMIT은 이름 그대로 기존 트랜잭션의 커밋이 완료된 뒤 실행되기 때문이다.외부 알림처럼 DB 저장이 필요 없는 작업은 AFTER_COMMIT에서 처리할 수 있다. 리스너에서 DB를 변경해야 한다면 별도의 REQUIRES_NEW 트랜잭션이 필요..

@Transactional 실전 함정 정리 — 셀프 호출부터 롤백까지결론부터@Transactional은 붙이는 순간 마법처럼 다 해결해주는 부적이 아니다. 스프링이 만든 프록시를 거쳐야만 동작하기 때문에, 같은 클래스 안에서 셀프 호출하면 통째로 무효가 되고, 기본 설정으로는 체크 예외에서 롤백도 안 된다. "어? 분명 @Transactional 붙였는데 왜 저장됐지" 싶은 장애의 8할은 이 두 가지에서 나온다. 아래 다섯 가지만 짚고 가면 실무에서 만나는 트랜잭션 사고는 거의 다 피할 수 있다.함정 1. 셀프 호출은 프록시를 안 탄다스프링의 @Transactional은 AOP 프록시로 동작한다. 즉 외부에서 프록시 객체를 거쳐 호출해야 트랜잭션이 시작된다. 같은 클래스 안에서 this.method()로..

HikariCP 커넥션 풀 설정, 숫자의 근거 정리결론부터. Spring Boot는 HikariCP를 기본 커넥션 풀로 내장하고 있어서, 대부분 application.yml을 한 줄도 안 건드리고 기본값(maximum-pool-size: 10)으로 운영한다. 문제는 이 기본값이 모든 서비스에 맞는 숫자가 아니라는 점이다. 무작정 풀 크기를 키우면 오히려 느려질 수 있다.커넥션 풀이 하는 일매 요청마다 DB에 새로 연결하면 TCP 핸드셰이크와 인증 과정이 반복돼 느리다. 커넥션 풀은 미리 연결을 여러 개 만들어두고 재사용하는 방식으로 이 비용을 없앤다. HikariCP는 이 중에서도 가볍고 빠르기로 정평이 나 있어 Spring Boot 2.0부터 기본값으로 채택됐다.spring: datasource: ..

요약 한 줄스프링 MVC는 DispatcherServlet이 중앙에서 요청을 받아 HandlerMapping → HandlerAdapter → (Controller) → ViewResolver → View 순으로 흐름을 조율하고, 중간에 필터/인터셉터/예외처리/리졸버들이 참여하는 파이프라인입니다.목차전체 흐름(빅픽처)주요 컴포넌트 한 줄 정의요청~응답 단계별 상세인터셉터 vs 필터 vs AOP예외 처리 흐름(@ExceptionHandler, @ControllerAdvice, HandlerExceptionResolver)확장 포인트(커스터마이징 체크리스트)실전 코드 스니펫 모음면접/시험 포인트 & 체크리스트1) 전체 흐름(빅픽처)HTTP 요청 ↓ (Servlet Filter 체인)DispatcherSer..

1. 스프링의 시작은 책 한 권에서스프링(Spring)은 단순한 프레임워크 그 이상입니다. 그 시작은 2002년, Rod Johnson이 집필한 『Expert One-on-One J2EE Design and Development』라는 책에서 등장한 소스 코드에서 비롯됩니다. 당시 **EJB(Enterprise JavaBean)**는 무거운 구조와 복잡성으로 인해 '겨울'과도 같았죠. Rod는 이를 비판하며 '단순함'을 추구했고, 그 철학이 '봄(Spring)'이라는 이름으로 이어진 것입니다.❝ EJB의 겨울을 지나, 스프링의 봄이 온다 ❞스프링은 2003년 6월에 처음 세상에 공개되었고, 오픈소스 프로젝트로서 Apache License 2.0을 따릅니다. 2022년 11월 기준으로는 6.0.0 버전까지 ..

Java에서 반복적으로 작성해야 하는 메서드들, 예를 들어 getter, setter, toString, 생성자 같은 것들로 인해 코드가 길어지는 것이 고민이신가요?Lombok은 이러한 반복 코드를 어노테이션 한 줄로 자동 생성해주는 강력한 라이브러리입니다. 이 글에서는 Lombok의 주요 어노테이션을 한 번에 정리해드립니다.💡 Lombok 설정 방법// build.gradleconfigurations { compileOnly { extendsFrom annotationProcessor }}dependencies { annotationProcessor 'org.projectlombok:lombok' compileOnly 'org.projectlombok:lombok' ..

스프링에서 수동으로 빈을 등록 할때 @Configuration 클래스 안에 @Bean을 사용한다. 왜 그런지 살펴보자. ● @Configuration 안에 @Bean을 사용하는 이유, proxyBeanMethods - @Bean 어노테이션을 이용한 수동 빈 등록 스프링에선 일반적으로 컴포넌트 스캔을 이용해 자동으로 빈을 등록하는 방법을 이용한다. 하지만 @Bean 어노테이션을 사용해 수동으로 빈을 등록해야 할 때도 있다. 개발자가 직접 제어가 불가능한 라이브러리를 활용할 때 애플리케이션 전 범위적으로 사용되는 클래스를 등록할 때 다형성을 활용하여 여러 구현체를 등록해야 할 때 @Bean을 이용한 수동 빈 메소드는 스프링 빈 안에만 구현되어 있다면 모두 동작한다. 하지만 스프링은 @Bean은 반드시 @Co..

기존의 스프링 MVC에서는 xml을 활용하여 Bean을 등록하고 있었다. 하지만 프로젝트의 규모가 커짐에 따라 사용하는 요소들은 xml에 등록하는 것이 상당히 번거로워 져서 어노테이션 기반의 Bean 등록 방법이 탄생하게 되었다. Bean을 등록하기 위한 @Bean, @Component, @Configuration 어노테이션에 대하여 알아보자. ● Spring Bean이란? - 스프링에서 스프링의 DI Container에 의해 관리되는 POJO(Plain Old Java Object)를 Bean이라고 부른다. 이러한 Bean들이 스프링을 구성하는 핵심 요소이다. POJO(Plain Old Java Object)로써 스프링 애플리케이션을 구성하는 핵심 객체이다. 스프링 IoC 컨테이너(또는 DI 컨테이너)..