조용한 개발 노트

12편에서는 Spring MVC의 시작점인 DispatcherServlet이 모든 웹 요청의 관문 역할을 한다는 점을 살펴봤습니다.DispatcherServlet이 요청을 받았다면, 다음 질문은 자연스럽게 이어집니다.이 요청을 어떤 컨트롤러가 처리해야 할까?이 결정을 담당하는 컴포넌트가 바로 HandlerMapping입니다.1. HandlerMapping의 역할HandlerMapping은 한 문장으로 정리할 수 있습니다.요청 정보를 기준으로 실행할 핸들러(컨트롤러)를 찾아주는 역할여기서 중요한 점은,HandlerMapping은 실행하지 않는다단지 “누가 처리할지”만 결정한다는 것입니다.실제 실행은 다음 단계인 HandlerAdapter가 담당합니다.2. Spring MVC에는 HandlerMapping이..

11편까지는 Spring 트랜잭션을 중심으로,프록시 기반 동작롤백 규칙전파와 격리 수준실무에서 자주 터지는 설계 실수를 하나의 흐름으로 정리했습니다.이번 글부터는 Spring MVC 파트로 넘어가, 웹 요청이 들어와서 컨트롤러 메서드가 실행되기까지 실제로 어떤 일이 벌어지는지를 차근차근 살펴보겠습니다.그 첫 번째 주인공이 바로 DispatcherServlet입니다.1. Spring MVC의 핵심 질문웹 요청 처리에서 Spring이 풀고자 한 핵심 질문은 단순합니다.수많은 컨트롤러와 URL 중에서 이 요청은 누가, 어떻게 처리해야 할까?DispatcherServlet은 이 질문에 대한 Spring의 답입니다.즉, DispatcherServlet은모든 웹 요청의 단일 진입점으로 설계되었습니다.2. Dispa..

7~10편에서는 Spring 트랜잭션의 핵심 요소인프록시 기반 동작롤백 규칙(RuntimeException vs Checked Exception)전파(Propagation)격리 수준(Isolation)을 차례대로 살펴봤습니다.이번 글에서는 이 개념들이 실무에서 어떻게 잘못 사용되는지, 그리고 그 결과로 왜 데이터가 꼬이게 되는지를 대표적인 사례 중심으로 정리해보겠습니다.1. 실수 #1 – 로그도 같이 롤백된다가장 흔한 실수 중 하나는 로그나 이력 저장 로직을 메인 비즈니스 트랜잭션에 그대로 포함시키는 경우입니다.@Transactionalpublic void processOrder() { orderService.createOrder(); logService.saveLog(); // 같은 트랜잭션..

9편에서는 트랜잭션 전파(Propagation)를 통해 Spring이 하나의 요청 안에서 트랜잭션 경계를 어떻게 나누고, 왜 REQUIRED와 REQUIRES_NEW가 존재하는지를 살펴봤습니다.이번 글에서는 트랜잭션 격리 수준(Isolation)을 통해,동시에 여러 트랜잭션이 실행될 때 무엇을 허용하고, 무엇을 막아야 하는가라는 질문에 대해 Spring과 데이터베이스가 어떤 선택을 했는지를 차근차근 정리해보겠습니다.1. 트랜잭션 격리 수준(Isolation)이란 무엇인가격리 수준은 한 트랜잭션이 다른 트랜잭션의 변경 내용을 어디까지 볼 수 있는지를 정의합니다.즉, 격리는정합성의 문제이자동시성의 문제이며성능과 직결된 설계 선택입니다.모든 트랜잭션을 완전히 격리하면 가장 안전하겠지만, 그만큼 동시 처리 성능..

8편에서는 @Transactional이 프록시 기반으로 동작하며, 예외 타입에 따라 롤백 여부가 어떻게 결정되는지를 내부 구현 관점에서 살펴봤습니다.이번 글에서는 그 다음 단계의 질문을 다뤄보겠습니다.이미 트랜잭션이 시작된 상태에서 또 다른 @Transactional 메서드를 호출하면 Spring은 왜 굳이 “전파”라는 개념을 사용할까?그리고 더 중요한 질문은 이것입니다.왜 REQUIRED가 기본값이고, REQUIRES_NEW는 기존 트랜잭션을 suspend까지 하면서 새로 시작하도록 설계됐을까?1. 트랜잭션 전파(Propagation)란 무엇인가트랜잭션 전파란,이미 트랜잭션이 존재할 때 새로운 트랜잭션 경계를 어떻게 처리할지에 대한 정책입니다.즉, 전파는 “트랜잭션을 시작할지 말지”가 아니라,이미 있는..

7편에서는 Spring AOP가 프록시 기반으로 동작하며, JDK Dynamic Proxy와 CGLIB 중 어떤 방식을 선택하는지를 살펴봤습니다.이번 글에서는 Spring에서 가장 많이 사용하면서도 가장 많이 오해되는 기능인 @Transactional이 실제로 어떻게 동작하는지를 프록시와 내부 구현 관점에서 정리해보겠습니다.1. @Transactional은 마법이 아니다먼저 가장 중요한 전제부터 짚고 가겠습니다.@Transactional은 메서드에 트랜잭션을 “붙여주는” 애노테이션이 아니다Spring에서 @Transactional은프록시를 생성하고메서드 호출 전후에트랜잭션 경계를 설정하는AOP 기반 기능입니다.즉, 실제 비즈니스 메서드 안에는 트랜잭션 관련 코드가 전혀 들어가지 않습니다.2. @Trans..

6편에서는 Spring AOP가 프록시 기반으로 동작하며, 그 구조가 왜 선택되었는지를 살펴봤습니다.이번 글에서는 그 프록시가 구체적으로 어떤 방식으로 만들어지는지, 즉 JDK Dynamic Proxy와 CGLIB의 차이를 중심으로 정리해보겠습니다.이 차이를 이해하면왜 인터페이스가 중요해지는지final 클래스/메서드가 왜 문제가 되는지프록시 관련 설정이 왜 존재하는지를 자연스럽게 설명할 수 있습니다.1. Spring 프록시는 두 가지 방식이 있다Spring AOP는 프록시를 생성할 때 두 가지 방식 중 하나를 선택합니다.JDK Dynamic ProxyCGLIB(Code Generation Library)둘 다 “프록시”이지만, 동작 방식과 제약 조건이 크게 다릅니다.2. JDK Dynamic Proxy란..

5편에서는 의존성 주입 과정에서 프록시 객체가 언제, 왜 주입되는지를 살펴봤습니다.이번 글에서는 그 프록시 구조의 출발점, Spring AOP(Aspect-Oriented Programming)가 왜 필요했고, 어떤 문제를 해결하려고 등장했는지를 정리해보겠습니다.1. 비즈니스 코드에 반복되는 것들실제 비즈니스 로직을 작성하다 보면 항상 비슷한 코드들이 반복됩니다.트랜잭션 시작과 종료로깅권한 체크성능 측정이 코드들은핵심 비즈니스 로직은 아니지만여러 클래스에 걸쳐 반복되며없으면 안 되는 코드라는 특징을 가집니다.Spring은 이런 코드를 횡단 관심사(Cross-cutting Concern)라고 부릅니다.2. 횡단 관심사가 만드는 구조적 문제횡단 관심사를 그냥 메서드 안에 직접 작성하면 다음과 같은 문제가 생..

4편에서는 Bean이 생성되고 초기화되며, 어떤 과정을 거쳐 소멸되는지까지 Bean 생명주기 전체 흐름를 살펴봤습니다.이번 글에서는 그 생명주기 안에서 가장 중요한 단계 중 하나인 의존성 주입(Dependency Injection)이 실제로 어떻게 동작하는지를 다뤄보겠습니다.특히,왜 생성자 주입을 권장하는지필드 주입은 왜 문제가 되는지주입 대상이 언제 프록시로 바뀌는지를 공식문서 흐름에 맞춰 정리합니다.1. 의존성 주입은 “생성 이후”에 일어난다먼저 가장 많이 오해되는 부분부터 짚고 가겠습니다.의존성 주입은 Bean 생성과 동시에 일어나지 않는다Spring의 실제 순서는 다음과 같습니다.Bean 인스턴스 생성의존성 주입초기화 콜백 실행즉, 생성자 호출이 끝난 이후에야 다른 Bean과의 연결이 이루어집니다..

3편에서는 Spring IoC 컨테이너에 Bean이 어떻게 등록되는지를 살펴봤습니다.이번 글에서는 그 다음 단계, 등록된 Bean이 언제 생성되고, 어떤 과정을 거쳐 사용되다가, 언제 소멸되는지를 정리해보겠습니다.Bean 생명주기는DI가 안 되는 이유@Transactional이 적용되지 않는 이유초기화 로직이 예상과 다르게 동작하는 이유를 설명해주는 핵심 개념입니다.1. Bean 생명주기를 한 문장으로 정리하면Spring 공식문서 기준으로 Bean 생명주기는 다음과 같이 요약할 수 있습니다.Bean 정의 등록 → Bean 생성 → 의존성 주입 → 초기화 → 사용 → 소멸 중요한 점은, “등록”과 “생성”은 전혀 다른 단계라는 것입니다.컴포넌트 스캔이나 @Bean 등록은 설계도(BeanDefinition)..