Aop on kastori

[Spring 완전 정복 #2] Spring Core — IoC, DI, AOP를 코드로 이해하기

Tue, 19 May 2026 00:00:00 +0000

“@Service만 붙이면 왜 되는 걸까?”

Spring을 처음 쓸 때 누구나 한 번쯤 갖는 의문이다. 클래스에 어노테이션 하나 달았을 뿐인데 의존성이 주입되고, @Transactional만 붙이면 트랜잭션이 처리된다.

이게 “마법"처럼 느껴지는 건, 내부 동작을 모르기 때문이다. 이 글에서는 Spring의 핵심 메커니즘 세 가지 — IoC, DI, AOP — 를 코드 수준에서 풀어낸다.

어노테이션은 라벨일 뿐이다

먼저 오해를 하나 짚고 시작한다. @Service, @Autowired 같은 어노테이션은 그 자체로 아무 일도 하지 않는다.

Java 어노테이션은 코드에 붙이는 메타데이터다. Spring Container가 없다면 @Service를 붙여도 그냥 라벨이 붙은 일반 클래스일 뿐이다.

Spring이 하는 일은 애플리케이션 시작 시 리플렉션으로 클래스를 스캔해서 어노테이션을 읽고, 그에 따라 동작을 결정하는 것이다.

애플리케이션 시작
 → @ComponentScan이 지정 패키지 하위를 전부 탐색
 → 각 클래스를 리플렉션으로 읽음
 → @Service/@Repository 발견 → "Bean으로 등록"
 → @Autowired 발견 → "등록된 Bean 중 타입 맞는 것을 주입"
 → @Transactional 발견 → "CGLIB 프록시로 감싸기"

Spring이 이 과정을 대신 처리해준다. 개발자가 직접 구현하면 아래처럼 된다.

// Spring 내부에서 실제로 일어나는 일 (단순화)
for (Class<?> clazz : scannedClasses) {
 if (clazz.isAnnotationPresent(Component.class)) {
 Object instance = clazz.getDeclaredConstructor().newInstance();
 beanContainer.register(clazz, instance);
 }
}

이걸 자동으로 해주는 것이 Spring의 핵심이다.

IoC — 제어권을 Spring에게 넘기다

전통적인 방식에서는 개발자가 객체를 직접 생성하고 의존성을 연결한다.

public class OrderService {
 // 직접 생성 — 강한 결합
 private PaymentService paymentService = new PaymentService();
}

이 코드의 문제는 OrderService가 PaymentService의 구체적인 구현에 묶여있다는 점이다. PaymentService 구현을 KakaopayService로 바꾸려면 OrderService도 수정해야 한다.

**IoC(Inversion of Control, 제어의 역전)**는 이 제어권을 개발자에서 Spring Container로 넘기는 것이다.

전통적: 개발자 → 객체 생성 → 의존성 연결
IoC: Spring Container → 객체 생성 → 의존성 연결 → 개발자에게 제공

개발자는 “무엇이 필요한지"만 선언하면 된다. “어떻게 만들지"는 Spring이 결정한다.

DI — IoC를 구현하는 방법

DI(Dependency Injection, 의존성 주입)는 IoC를 실현하는 구체적인 방법이다. Spring이 의존성을 주입하는 방식은 세 가지가 있다.

생성자 주입 (권장)

@Service
public class OrderService {
 private final PaymentService paymentService;

 @Autowired // 생성자가 1개면 생략 가능
 public OrderService(PaymentService paymentService) {
 this.paymentService = paymentService;
 }
}

필드 주입 (비권장)

@Service
public class OrderService {
 @Autowired
 private PaymentService paymentService; // 테스트 어려움
}

생성자 주입을 쓰는 이유가 있다.

이유	설명
불변성	`final` 선언 가능 — 런타임 중 변경 불가
필수 의존성 명시	컴파일 시점에 의존성 누락 감지
테스트 용이	`new OrderService(mockPaymentService)`로 직접 주입 가능
순환 의존성 감지	앱 시작 시 즉시 오류 발생

필드 주입의 치명적 단점은 테스트다. Spring Container 없이 new OrderService()를 하면 paymentService가 null이다. 반면 생성자 주입은 테스트 코드에서도 의존성을 명확히 넘길 수 있다.

Bean — Spring이 관리하는 객체

Bean은 Spring Container가 생성하고 관리하는 객체다. 개발자가 new로 직접 생성하지 않는다.

등록 방법

컴포넌트 스캔 — 클래스에 어노테이션을 붙이면 자동 등록된다.

@Component // 일반 컴포넌트
@Service // 서비스 레이어
@Repository // 데이터 접근 레이어 (예외 변환 기능 추가)
@Controller // Spring MVC 컨트롤러

자바 설정 — 외부 라이브러리처럼 소스코드를 수정할 수 없을 때 사용한다.

@Configuration
public class AppConfig {
 @Bean
 public PaymentService paymentService() {
 return new KakaopayService(); // 구현체를 여기서 결정
 }
}

같은 타입 Bean이 여러 개일 때

PaymentService 구현체가 KakaopayService, NaverPayService 두 개라면 @Autowired만으로는 어떤 걸 주입할지 알 수 없다.

// @Primary — 기본 Bean 지정
@Component
@Primary
public class KakaopayService implements PaymentService { ... }

// @Qualifier — 이름으로 명시적 선택
@Autowired
@Qualifier("naverpay")
private PaymentService paymentService;

Singleton Bean의 함정

Spring Bean의 기본 스코프는 Singleton이다. Container당 인스턴스가 1개이고, 모든 요청에서 이 인스턴스를 공유한다.

@Service
public class OrderService {
 // 위험! 여러 스레드가 이 변수를 동시에 읽고 씀
 private int orderCount = 0;
 
 public void createOrder() {
 orderCount++; // 스레드 안전하지 않음
 }
}

Singleton Bean은 **무상태(stateless)**로 설계해야 한다. 인스턴스 변수에 요청별 데이터를 저장하면 안 된다.

AOP — 비즈니스 로직에서 공통 코드를 분리하다

로깅, 트랜잭션, 인증 체크 같은 코드는 특성이 있다. 비즈니스 로직과 무관하지만 여러 곳에 반복해서 등장한다.

// AOP 없이 — 모든 메서드마다 반복
public Order createOrder(...) {
 log.info("createOrder 시작"); // 로깅
 checkAuth(); // 인증
 startTransaction(); // 트랜잭션

 Order order = doCreateOrder(); // 실제 비즈니스 로직

 commitTransaction();
 log.info("createOrder 완료");
 return order;
}

AOP는 이 **횡단 관심사(Cross-cutting Concerns)**를 별도 모듈로 분리해서, 비즈니스 코드가 핵심 로직에만 집중하게 한다.

프록시가 핵심이다

Spring AOP는 프록시 패턴으로 동작한다. 실제 Bean을 직접 주입하는 대신, Bean을 감싼 프록시 객체를 주입한다. 메서드 호출이 들어오면 프록시가 먼저 받아서 부가 로직을 실행하고, 실제 Bean으로 넘긴다.

호출자 → [프록시] → 실제 Bean
 ↑
 Advice(부가 로직) 실행

@Aspect
@Component
public class LoggingAspect {

 // service 패키지의 모든 메서드 실행 전후
 @Around("execution(* com.example.service.*.*(..))")
 public Object around(ProceedingJoinPoint pjp) throws Throwable {
 long start = System.currentTimeMillis();

 Object result = pjp.proceed(); // 실제 메서드 실행

 log.info("{} — {}ms",
 pjp.getSignature().getName(),
 System.currentTimeMillis() - start);
 return result;
 }
}

@Transactional도 AOP다

@Transactional이 붙은 Bean에는 CGLIB 프록시가 주입된다. 트랜잭션 시작/커밋/롤백은 프록시가 처리하고, 실제 메서드는 비즈니스 로직만 담는다.

@Service
public class OrderService {
 @Transactional
 public Order createOrder(...) {
 // 트랜잭션 begin → 프록시가 처리
 Order order = orderRepository.save(...);
 return order;
 // 트랜잭션 commit → 프록시가 처리
 }
}

여기서 하나의 함정이 있다. 같은 클래스 내부에서 @Transactional 메서드를 직접 호출하면 트랜잭션이 적용되지 않는다.

@Service
public class OrderService {

 public void process() {
 createOrder(); // 프록시를 거치지 않음 → 트랜잭션 미적용!
 }

 @Transactional
 public void createOrder() { ... }
}

외부에서 호출할 때만 프록시를 거치기 때문이다. 내부 호출은 this.createOrder()와 같아서 프록시를 건너뛴다.

마치며

Spring의 핵심은 결국 세 가지다.

IoC: 객체 생성·의존성 연결의 제어권을 Spring에게 넘긴다.
DI: Spring이 필요한 의존성을 주입해준다. 생성자 주입을 쓰자.
AOP: 횡단 관심사를 프록시로 분리한다. @Transactional이 대표적이다.

이 구조를 이해하면 @Transactional 자기 호출 버그나 Singleton Bean 상태 문제 같은 Spring의 흔한 함정을 미리 피할 수 있다.

다음 편에서는 Spring MVC — DispatcherServlet 내부 구조와 요청 처리 흐름을 정리한다.

[Spring 완전 정복 #3] Spring MVC 내부 구조 — DispatcherServlet이 요청을 처리하는 방법

Tue, 19 May 2026 00:00:00 +0000

모든 요청이 거치는 하나의 관문

Spring MVC 애플리케이션에서 HTTP 요청은 예외 없이 DispatcherServlet을 먼저 통과한다. URL이 /users든 /orders든 상관없다. 이 “하나의 관문"이 무엇이고, 내부에서 무슨 일이 일어나는지 이해하면 Filter, Interceptor, AOP 중 어디서 로직을 처리해야 하는지가 자연스럽게 보인다.

Front Controller 패턴 — 왜 DispatcherServlet이 필요한가

Spring MVC 이전에는 URL마다 Servlet을 따로 만들었다.

/users → UserServlet
/orders → OrderServlet
/items → ItemServlet

이 방식의 문제는 공통 처리다. 인증 체크, 로깅, 인코딩 설정을 Servlet마다 중복해서 넣어야 했다.

Front Controller 패턴은 모든 요청을 하나의 진입점이 받아 적절한 핸들러에 위임한다.

모든 요청 (/*) → DispatcherServlet → Controller 위임

공통 로직을 DispatcherServlet 한 곳에서 처리하니 중복이 사라진다. Spring Boot는 이 DispatcherServlet을 자동으로 등록해 모든 URL(/)을 받도록 설정한다.

DispatcherServlet 내부 구성요소

DispatcherServlet은 모든 일을 혼자 처리하지 않는다. 역할별 전문 컴포넌트에게 위임한다.

DispatcherServlet
 ├─ HandlerMapping : "이 URL → 어떤 Controller?"
 ├─ HandlerAdapter : "이 Controller를 어떻게 실행?"
 ├─ HandlerInterceptor : Controller 실행 전·후 부가 처리
 ├─ ViewResolver : "뷰 이름 → 실제 View 파일?"
 └─ HandlerExceptionResolver : "예외 발생 → 어떻게 응답?"

HandlerMapping — @GetMapping("/users/{id}")처럼 선언된 매핑 정보를 읽어 요청 URL에 맞는 Controller 메서드를 찾는다.

HandlerAdapter — 찾은 Controller 메서드를 실제로 실행한다. @RequestBody, @PathVariable, @ModelAttribute 파라미터 바인딩도 여기서 처리한다.

ViewResolver — Controller가 문자열 뷰 이름을 반환할 때 실제 파일 경로로 변환한다. @RestController를 쓰면 이 단계를 건너뛰고 HttpMessageConverter가 JSON으로 직렬화한다.

HandlerExceptionResolver — @ControllerAdvice + @ExceptionHandler가 이 메커니즘으로 동작한다.

@RestControllerAdvice
public class GlobalExceptionHandler {
 @ExceptionHandler(UserNotFoundException.class)
 public ResponseEntity<String> handle(UserNotFoundException e) {
 return ResponseEntity.status(404).body(e.getMessage());
 }
}

단, Filter에서 발생한 예외는 DispatcherServlet 밖이라 이 핸들러가 잡지 못한다.

요청 처리 12단계 흐름

HTTP 요청이 응답까지 가는 전체 흐름이다.

① HTTP 요청 → Tomcat
② Filter Chain (전처리)
③ DispatcherServlet 진입
④ HandlerMapping → 처리할 Controller 메서드 조회
⑤ Interceptor.preHandle() — 순서대로 실행
 (false 반환 시 여기서 중단)
⑥ HandlerAdapter → Controller 메서드 실행
 (AOP 프록시를 통해 Before → 메서드 → After)
⑦ ModelAndView 반환
⑧ Interceptor.postHandle() — 역순으로 실행
⑨ ViewResolver → View 렌더링 (REST면 생략)
⑩ Interceptor.afterCompletion() — 역순, 예외 발생해도 항상 실행
⑪ Filter Chain (후처리, 역순)
⑫ HTTP 응답

postHandle()은 Controller에서 예외가 발생하면 실행되지 않는다. afterCompletion()은 예외 여부와 무관하게 항상 실행된다. 그래서 실행 시간 측정이나 리소스 해제는 afterCompletion()에 넣어야 한다.

Interceptor — Spring 내부에서 요청을 제어하다

Interceptor는 DispatcherServlet 내부, Spring Context 안에서 동작한다. Spring Bean을 주입받을 수 있고, @ControllerAdvice 예외 처리도 적용된다.

@Component
public class AuthInterceptor implements HandlerInterceptor {

 @Override
 public boolean preHandle(HttpServletRequest request,
 HttpServletResponse response,
 Object handler) {
 String token = request.getHeader("Authorization");
 if (token == null) {
 response.setStatus(401);
 return false; // 여기서 중단, Controller까지 가지 않음
 }
 return true;
 }

 @Override
 public void afterCompletion(HttpServletRequest request,
 HttpServletResponse response,
 Object handler, Exception ex) {
 // 요청 처리 시간 로깅 — 예외가 나도 실행됨
 }
}

URL 패턴으로 적용 범위를 지정할 수 있다.

@Configuration
public class WebConfig implements WebMvcConfigurer {
 @Override
 public void addInterceptors(InterceptorRegistry registry) {
 registry.addInterceptor(new AuthInterceptor())
 .addPathPatterns("/api/**")
 .excludePathPatterns("/api/login", "/api/signup");
 }
}

Filter vs Interceptor vs AOP — 결론은 레이어 위치

이 세 가지를 구분하는 가장 명확한 기준은 어느 레이어에 위치하는가다.

구분	위치	Spring Bean 접근	예외 처리	적합한 용도
Filter	Servlet Container (Spring 밖)	제한적	직접 처리	CORS, 인코딩, XSS 방어
Interceptor	Spring MVC (DispatcherServlet 내)	가능	@ControllerAdvice	로그인 체크, URL별 접근 제어
AOP	Spring Bean	가능	@ControllerAdvice	트랜잭션, 실행 시간 측정, 메서드 로깅

Filter는 Spring Context가 시작되기 전에 동작하므로 Spring Bean 주입이 어렵고, 예외가 발생해도 @ControllerAdvice가 잡지 못한다. 반면 Interceptor와 AOP는 Spring 안에서 동작하므로 Bean 주입과 통합 예외 처리가 모두 가능하다.

Spring Security의 필터체인이 Filter 레이어에 있는 것도 이 때문이다. 인증되지 않은 요청은 DispatcherServlet까지 도달하지 못하고 Filter에서 차단된다.

입력값 검증 — Controller 진입 전 자동 검증

Spring MVC는 @Valid로 Controller 파라미터를 자동 검증한다.

public class CreateUserRequest {
 @NotBlank(message = "이름은 필수입니다")
 private String name;

 @Email
 private String email;

 @Min(18)
 private int age;
}

@RestController
public class UserController {
 @PostMapping("/api/users")
 public ResponseEntity<UserDto> create(
 @Valid @RequestBody CreateUserRequest request) {
 // 여기까지 오면 request는 유효한 상태
 return ResponseEntity.ok(userService.create(request));
 }
}

검증 실패 시 MethodArgumentNotValidException이 발생한다. @ControllerAdvice에서 공통 처리하면 된다.

@RestControllerAdvice
public class GlobalExceptionHandler {
 @ExceptionHandler(MethodArgumentNotValidException.class)
 public ResponseEntity<ErrorResponse> handleValidation(
 MethodArgumentNotValidException e) {
 List<String> errors = e.getBindingResult().getFieldErrors().stream()
 .map(err -> err.getField() + ": " + err.getDefaultMessage())
 .toList();
 return ResponseEntity.badRequest().body(new ErrorResponse("VALIDATION_FAILED", errors));
 }
}

마치며

DispatcherServlet은 Spring MVC의 모든 요청 처리를 조율하는 중앙 컨트롤러다. 이 구조를 이해하면 Filter와 Interceptor의 차이, @ControllerAdvice가 Filter 예외를 잡지 못하는 이유, Interceptor 세 메서드의 실행 조건 등이 자연스럽게 설명된다.

다음 편에서는 Spring Boot — 설정 없이 바로 실행되는 원리(자동설정, 스타터, 내장 서버)를 정리한다.