티스토리 뷰
Spring에서 AOP(Aspect Oriented Programming)가 필요한 이유와 이를 활용한 실제 애플리케이션 개발 사례에 대해 설명하세요.
AOP(Aspect Oriented Programming)란 무엇인가?
AOP는 이름 그대로 '관점(Aspect)'을 기준으로 프로그래밍하는 기법
여기서 '관점'이란 애플리케이션의 핵심 비즈니스 로직은 아니지만, 여러 곳에서 공통적으로 사용되는 기능을 의미함
객체지향 프로그래밍(OOP)이 "객체"를 기준으로 코드를 짠다면,
AOP는 "공통된 작업"을 한곳에 모아서 관리하는 것에 집중함
AOP가 필요한 이유
핵심 로직과 공통 로직을 분리하기 위해
AOP가 없다면 모든 메서드 안에 기능들을 일일이 복사해서 붙여넣어야 한다. 100개의 메서드가 있다면 100번 복붙해야 함. 결국 코드가 지저분해지고, 수정할 때도 100곳을 다 찾아가야 하는 코드 중복과 '강한 결합' 문제가 발생한다.
AOP를 사용하면 공통 로직을 Aspect로 한 번만 정의한다. 그리고 이 로직을 어느 메서드에 적용할지만 설정하면 끝 비즈니스 로직은 본연의 기능에만 집중할 수 있게 된다
AOP를 언제 사용해야 할까?
- 여러 곳에서 반복되는 코드가 보일 때
- 비즈니스 로직과 직접 관계없는 기능일 때
- 정책이 자주 바뀌는 공통 기능일 때
AOP를 사용하면 얻는 장점
- 중복 코드 제거
- 비즈니스 로직 집중
- 유지보수성 향상
- 공통 정책 일괄 관리
- 코드 가독성 증가
실제 개발 사례
1. 트랜잭션 관리 (@Transactional)
상황 : 계좌 이체나 회원 가입 처럼 모든 조건을 만족해야만 정상 처리되고 아니면 취소 되어야하는 작업
- 기존 방식: 메서드 시작 때 begin(), 끝날 때 commit() 또는 rollback()을 직접 적어야 함.
- AOP 활용: 어노테이션 하나만 붙이면 AOP가 알아서 메서드 전후에 트랜잭션 처리 로직을 주입
2. 로그 기록 및 성능 모니터링
상황 : 특정 서비스의 모든 메서드 실행 시간을 측정하라는 작업
AOP 활용: Around Advice를 사용하여 모든 메서드의 시작 시간과 종료 시간을 계산해 로그를 남길 수 있다. 실제 비즈니스 코드에는 시간 측정 로직이 한 줄도 들어가지 않는다.
3. 권한 체크 및 보안
상황 : 사용자가 관리자 페이지에 접근할 때 권한이 있는지 확인해야 하는 작업
AOP 활용: 컨트롤러나 서비스 메서드 실행 전에 세션을 확인하는 Aspect를 배치. 권한이 있다면 메서드 정상 실행 권한이 없으면 메서드 자체를 실행하지 않고 바로 예외를 던지도록 설계할 수 있음.
요약
Spring AOP는 "핵심 비즈니스 로직과 부가 기능을 분리"하여 코드의 재사용성과 유지보수성을 극대화하는 강력한 도구
Spring MVC에서 클라이언트의 요청 처리 흐름을 @Controller와 @RestController의 차이점을 중심으로 각각의 처리 과정과 특징을 포함하여 설명하세오.
MVC란?
MVC 패턴은 애플리케이션의 개발 영역을 MVC(Model, View, Controller)로 구분하여 각 역할에 맞게 코드를 작성하는 개발 방식이다.
쉽게 말해 "프로그램의 역할을 3가지로 나누어 관리하는 설계도" 라고 생각하면 된다.
Spring MVC의 전체 요청 흐름 (Common Flow)
1. 클라이언트 요청: 사용자가 브라우저에서 URL을 입력
2. DispatcherServlet: 모든 요청의 입구 역할을 하며, 요청을 받는다
3. HandlerMapping: 요청된 URL을 처리할 적절한 '컨트롤러'를 찾아줌
4. HandlerAdapter: 찾아낸 컨트롤러의 메서드를 실제로 실행함
5. 비즈니스 로직 수행: 컨트롤러가 서비스를 호출해 데이터를 가져오거나 처리함
6. 응답 반환: 여기서 @Controller냐 @RestController냐에 따라 길이 갈림
@Controller (템플릿 기반 응답)
작동: 컨트롤러가 ModelAndView 또는 뷰 이름(String)을 반환
후속 처리: ViewResolver가 호출
논리적인 이름(예: home)을 물리적인 경로(예: /views/home.jsp)로 바꿈(HTML 렌더링)
최종 형태: 서버에서 완성된 HTML이 클라이언트에게 전달됨
@RestController (데이터 기반 응답)
작동: 컨트롤러가 자바 객체(DTO, List 등)를 그대로 반환함. (내부적으로 @ResponseBody가 붙어있기 때문.)
후속 처리: HttpMessageConverter가 호출
- Java 객체 → JSON 변환
- Jackson 라이브러리 사용
ViewResolver를 거치지 않고, 객체를 JSON이나 XML 텍스트로 변환
최종 형태: 순수한 데이터(JSON)가 HTTP 응답 본문에 담겨 클라이언트에게 전달
요약
@Controller를 사용하는 경우
서버에서 HTML을 직접 렌더링
Thymeleaf, JSP 사용
전통적인 MVC 웹 애플리케이션
@Controller는 "화면을 반환"
@RestController를 사용하는 경우
프론트엔드(React, Vue)와 분리
모바일 앱 API
백엔드 서버 API
@RestController는 "데이터를 반환"