[📰 위클리페이퍼] Spring AOP & Controller vs RestController

📌 AOP(Aspect Oriented Programming)

🧐 AOP?

핵심 비즈니스 로직과는 별개인 공통 기능(횡단 관심사)을 하나의 모듈(Aspect)로 분리하여 관리할 수 있게 해주는 프로그래밍 패러다임
-> 핵심 개념은 "관심사의 분리(Seperation of Concerns)"

👉 AOP를 적용하면 공통 기능은 하나의 곳에서 정의하고, 필요한 핵심 로직에 자동으로 끼워넣는 방식으로 처리할 수 있음

🧐 AOP가 필요한 이유?

1️⃣ 중복 제거 + 유지보수성 향상

객체지향 프로그램(OOP)은 역할에 따라 책임을 분리하는 데 탁월하지만, 실제 시스템을 설계하다 보면 모든 모듈에서 반복적으로 등장하는 로직들이 존재함

ex)

• 로깅
• 트랜잭션 처리
• 보안 검사
• 실행 시간 측정

👉 이러한 코드들은 여러 클래스에 분산되어 반복되기 쉽고, OOP만으로는 이 중복을 효과적으로 제거하기 어렵기 때문
-> AOP는 이런 공통 로직을 @Aspect로 빼서 한 번에 적용

2️⃣ 관심사 분리(Seperation of Concerns)

비즈니스 로직(예: "채널 목록 조회", "메시지 전송")과 인프라/운영 로직(예: "권한 체크", "트랜잭션 처리", "모니터링")을 분리함

👍 관심사 분리를 했을 때

• 도메인 코드가 더 읽기 쉬워짐
• 테스트도 더 간단해짐
• "운영 정책"을 바꾸기 쉬워짐

3️⃣ 일관성(정책 강제)

"모든 write 요청은 트랜잭션이 있어야 한다", "모든 API는 요청 ID를 남겨야 한다" 같은 규칙을 개발자 실수로 빠뜨리지 않도록 강제로 적용할 수 있음

4️⃣ Spring의 프록시 기반 기능과 궁합이 좋음

Spring의 @Transactional 자체가 대표적인 AOP 활용임
-> AOP는 이미 Spring에서 "검증된 방식"이고, 실제 실무에서도 자주 쓰임

💁 실제 애플리케이션 개발 사례

사례 1) “API 요청 단위 로깅 + 실행시간 + 요청 추적ID”

상황

• 운영 중 장애가 나면 “어떤 요청이 어떤 서비스 메서드를 호출했고, 얼마나 걸렸는지”가 필요함
• 컨트롤러/서비스마다 로그를 넣으면 중복이 폭발

AOP 적용

@Around로 Controller 또는 Service 패키지를 포인트컷으로 잡아

• 메서드 시작/종료 로그
• 실행 시간(ms)
• 예외 발생 시 에러 로그
• (선택) MDC에 requestId 넣어서 로그를 묶음

효과

• 모든 API가 동일한 포맷으로 추적 가능
• 성능 병목 지점 찾기가 쉬움
• 개발자가 로그를 “까먹는” 문제 제거

사례 2) “감사 로그(Audit) 자동 기록”

상황

• 금융/사내시스템에서 “누가 어떤 리소스를 생성/수정/삭제했는지”는 필수인 경우가 많음
• 서비스마다 audit 테이블 insert 코드를 넣기 싫음

AOP 적용

@Auditable(action="UPDATE_USER") 같은 애노테이션 기반으로
실행 전후에 변경 대상 ID, 사용자 ID, 결과(성공/실패), timestamp 기록

효과

• 감사 정책 변경이 쉬움(필드 추가/마스킹/저장 위치 변경)
• 비즈니스 로직이 깨끗해짐

---

📌 Controller vs RestController

💻 Spring MVC의 기본 요청 처리 흐름

Client
  ↓
DispatcherServlet (Front Controller)
  ↓
HandlerMapping (어떤 컨트롤러가 처리할지 찾음)
  ↓
Controller Method 실행
  ↓
HandlerAdapter
  ↓
Return 값 처리
  ↓
ViewResolver or HttpMessageConverter
  ↓
Response

👉 여기서 중요한 분기점이 바로 “컨트롤러 메서드의 반환값을 어떻게 해석하느냐”이고, 그 차이를 만드는 게 @Controller vs @RestController

💁 @Controller 기반 요청 처리 과정

@Controller는 전통적인 MVC 패턴에서 View(HTML 화면)를 반환할 때 주로 사용

📌 흐름

• 클라이언트 요청 → DispatcherServlet
• HandlerMapping이 @Controller 클래스의 메서드 매핑 탐색
• 메서드 실행
• 반환 타입이 String → View 이름으로 해석
• ViewResolver가 JSP, Thymeleaf 같은 템플릿 찾음
• View 렌더링 후 HTML 응답

🔍 예시 코드

@Controller
@RequestMapping("/users")
public class UserController {

    @GetMapping("/{id}")
    public String getUser(@PathVariable Long id, Model model) {
        model.addAttribute("user", userService.findById(id));
        return "user-detail"; // View 이름
    }
}

특징

• 반환값 → 뷰 이름
• Model에 데이터 담아서 화면 렌더링
• JSP / Thymeleaf 같은 템플릿 엔진과 함께 사용
• 웹 페이지용 서버 사이드 렌더링(SSR)에 적합

💁 @RestController 기반 요청 처리 과정

@RestController는 REST API 전용 컨트롤러
사실 내부적으로는:
@RestController = @Controller + @ResponseBody

👉 반환값을 View로 해석하지 않고 HTTP Response Body에 그대로 써줍니다.

📌 흐름

• 요청 → DispatcherServlet
• HandlerMapping이 메서드 찾음
• 메서드 실행
• 반환 객체를 HttpMessageConverter가 JSON/XML로 변환
• Response Body로 전송

🔍 예시코드

@RestController
@RequestMapping("/users")
public class UserApiController {

    @GetMapping("/{id}")
    public UserResponse getUser(@PathVariable Long id) {
        return userService.findUser(id);
    }
}

👉 반환 객체 → Jackson 같은 라이브러리가 JSON으로 변환:

{
  "id": 1,
  "name": "kim"
}

특징

• 반환값 = API 응답 데이터
• ViewResolver 안 탐
• JSON 기반 REST API에 특화
• 프론트엔드(React/Vue/앱)와 통신할 때 주력