🔥 문제점

우리 프로젝트에서 사용자는 ROLE_GUEST 혹은 ROLE_HOST에 해당하는 권한을 가질 수 있다. 그리고, 권한에 따라 접근할 수 있는 API 또한 상이하다. 예를 들어, 물품 등록에 해당하는 API Call은 ROLE_GUEST의 권한을 가진 유저만이 가능하다. 즉, 클라이언트로부터 API Call이 들어오면 서버 측은 해당 유저의 권한을 확인하는 작업이 필요하다.

처음에는 컨트롤러단에서 getCurrentUserRole() 메서드를 통해 현재 로그인한 유저의 권한을 불러와, 권한이 일치하지 않으면 예외를 던져주는 방식을 고려했다. 하지만, 이렇게 했을 때 문제점이 몇가지 존재했는데,

@PutMapping("/keep")
	public BaseResponse<Void> keep(@Valid @RequestBody MatchingKeepRequest matchingRequest, HttpServletRequest servletRequest) {
		Long userId = extractUserId(servletRequest);
		if (!RequestParser.getCurrentUserRole().equals("ROLE_HOST")) {
			throw new CustomRuntimeException(UserException.NOT_AUTHORIZED);
		}
		return matchingService.keep(matchingRequest, userId);
	}

1. 가독성이 구렸다.
   • RequestParser의 getCurrentUserRole() 메서드를 사용하는 것부터, 권한을 비교하고, 예외를 던지는 작업까지, 코드가 깔끔해보이진 않는다.
2. 컨트롤러의 모든 메서드에 권한 관련 예외처리를 추가적으로 해주어야 했다.
   • 만약 권한 확인 로직이 바뀌거나 예외처리 방식이 변경된다면, 모든 메서드를 수정해야 한다.

📕해결방안

AOP를 도입하여 권한 검증 로직을 공통 관심사로 분리하여 관리하기로 했다.

AOP(Aspect-Oriented Programming)란?

**AOP(Aspect-Oriented Programming)**는 애플리케이션 로직에 대한 부가적인 관심사를 비즈니스 로직과 분리하는 개념이다.

즉, MatchingController 및 MatchingService의 keep 메서드의 비즈니스 로직은 보관 요청을 처리하는 것이고, 부관심사는 권한 확인 등이 있다. 여기서 권한 검증 파트를 모듈화하고자 하는 것이다. 이 외에도 AOP는 로깅, 트랜잭션 관리 등의 반복적이거나 횡단 관심사(cross-cutting concern)를 모듈화하는 데에 유용하다.

❓ 횡단 관심사(cross-cutting concern)?

횡단 관심사는, 여러 모듈이나 계층에 걸쳐 반복적으로 나타나는 기능이나 로직을 의미한다. 여기서는 권한 확인 로직이 이에 속한다.

AOP 용어

• Target: AOP가 적용될 대상, 즉 부가 기능이 적용되는 클래스나 메서드이다.
• Advice: 실제 부가 기능 로직. 메서드 실행 전, 후 등 특정 시점에 실행할 코드이다.
  • @Before: 타겟 메서드 실행 전에 실행된다.
  • @After: 타겟 메서드 실행 후, 결과와 관계없이 항상 실행된다.
  • @AfterReturning: 메서드가 성공적으로 완료된 후 실행된다.
  • @AfterThrowing: 메서드가 예외를 던진 후 실행된다.
  • @Around: 메서드 실행 전후에 모두 실행된다.
• Join Point: 부가 기능을 삽입할 수 있는 위치로 주로 메서드, 필드, 생성자 등이 해당한다.
• Point Cut: Advice를 적용할 실제 조건이나 규칙을 정의한 것. 예를 들어, 특정 패키지의 모든 메서드에 적용한다는 규칙을 설정할 수 있다.