AOP로 횡단 관심사를 분리하는 소프트웨어 설계

비즈니스 코드에 섞이는 공통 기능을 분리하는 방법

객체지향 프로그래밍은 데이터와 기능을 하나의 단위로 묶어 응집도를 높이는 데 적합하다. 다만 로그 기록, 보안 검사, 트랜잭션 관리처럼 여러 모듈에서 반복되는 기능은 예외다. 이런 코드는 비즈니스 로직 곳곳에 퍼지고, 같은 기능이 여러 위치에 중복되는 문제가 생긴다.

관점지향 프로그래밍(AOP, Aspect-Oriented Programming)은 관심사의 분리를 바탕으로 이 문제를 다룬다. 애플리케이션의 본래 기능과 공통 부가 기능을 따로 개발한 뒤, 위빙(Weaving) 과정으로 필요한 지점에 결합한다. 비즈니스 로직은 본연의 역할에 집중하고, 공통 기능은 독립적인 모듈로 관리할 수 있다.

핵심 기능과 횡단 기능을 구분한다

핵심관심사(Core Concern)는 시스템이 제공해야 하는 고유한 기능이다. 뱅킹 시스템이라면 계좌 이체와 잔액 조회가 이에 해당한다.

반대로 보안, 로깅, 트랜잭션 처리는 여러 핵심 기능에 공통으로 적용된다. 이런 기능을 횡단관심사(Cross-cutting Concern)라고 한다. 시스템의 여러 계층을 가로질러 적용된다는 특성 때문에, 객체나 모듈 단위만으로는 깔끔하게 묶기 어렵다.

AOP는 횡단관심사를 별도의 관점(Aspect)으로 응집시킨다. 부가 기능의 세부 구현을 감추면서 적용 위치를 제어할 수 있고, 핵심 로직에서는 관련 코드가 빠져 가독성과 의도가 더 분명해진다.

적용 지점과 실행 기능을 조합하는 구조

AOP는 공통 기능을 단순히 분리하는 데서 그치지 않는다. 어떤 위치에 어떤 기능을 넣을지 표현하는 구성 요소가 함께 필요하다.

핵심관심 (Core Concern): 시스템이 수행해야 하는 비즈니스 본연의 기능이다.
횡단관심 (Cross-cutting Concern): 핵심관심에 공통으로 적용되는 부가 모듈이다.
조인 포인트 (Join Point): 횡단관심사를 넣을 수 있는 후보 지점이다. 메서드 호출, 필드 값 변경, 생성자 호출 등이 해당한다.
포인트컷 (Point-Cut): 조인 포인트 가운데 실제 적용 대상을 고르는 필터링 규칙이다.
어드바이스 (Advice): 선택된 조인 포인트에서 실행할 횡단관심사 모듈이다.
애스펙트 (Aspect): 포인트컷과 어드바이스를 결합한 AOP의 기본 단위다.
위빙 (Weaving): 지정한 조인 포인트에 어드바이스를 삽입해 타겟 객체와 결합하는 과정이다.

⤢✕

Visitor와 Proxy가 보여주는 분리 방식

Visitor 패턴은 객체 구조와 처리 로직을 분리한다. 새로운 처리를 추가할 때 객체 구조를 바꾸지 않아도 되며, 공통 기능을 별도 클래스로 분리한다는 점에서 AOP의 횡단관심사 처리와 닮아 있다. 특정 작업을 수행하는 방문자를 만들고 대상 객체에 적용하는 방식은 어드바이스 적용과 유사한 개념적 기반을 갖는다.

프락시(Proxy) 패턴은 AOP, 특히 Spring AOP 구현에서 많이 활용된다. 클라이언트는 타겟 객체를 직접 호출하는 대신 타겟을 감싼 프락시 객체를 호출한다. 프락시는 핵심 로직 전후에 어드바이스를 실행해 부가 기능을 투명하게 넣는다. 원본 코드를 수정하지 않고 기능을 확장하므로 개방-폐쇄 원칙(OCP)과도 연결된다.

코드에 결합되는 시점

위빙은 어드바이스가 타겟 코드에 삽입되는 시점에 따라 구분된다.

컴파일 시점 위빙 (Compile-time Weaving): 소스 코드를 컴파일할 때 위버가 개입해 바이트코드에 어드바이스를 직접 삽입한다. AspectJ가 대표적이다.
클래스 로딩 시점 위빙 (Load-time Weaving): 클래스 파일이 JVM에 로드될 때 에이전트로 바이트코드를 조작한다.
런타임 위빙 (Runtime Weaving): 애플리케이션 실행 중 프락시 객체를 동적으로 생성해 기능을 결합한다. Spring AOP에서 주로 사용하는 방식이다.

모듈화의 이점과 실행 흐름의 대가

AOP를 적용하면 핵심 로직에서 로깅이나 보안 코드가 빠져 코드의 의도가 선명해진다. 공통 기능을 바꿔야 할 때도 해당 애스펙트만 수정하면 되므로 중복 작업을 줄일 수 있다. 독립적으로 만든 애스펙트는 다른 프로젝트나 모듈에도 적용하기 쉽다.

반면 소스 코드에 직접 드러나지 않는 로직이 실행되므로, 익숙하지 않은 개발자에게는 실행 경로가 불투명하게 느껴질 수 있다. 디버깅 과정에서도 이 점을 고려해야 한다. 런타임 위빙은 프락시 생성과 호출에 따른 약간의 오버헤드가 발생할 수 있으므로, 적용 범위와 방식은 시스템 특성에 맞춰 판단해야 한다.

AOP는 객체 구조를 수직적으로 설계하는 OOP와 달리, 그 구조를 가로지르는 관심사를 관리한다. 공통 기능을 무분별하게 숨기는 장치가 아니라 반복되는 부가 로직의 책임을 분명하게 분리할 때 가장 의미가 있다.

Sources

Robert C. Martin, "Clean Code: A Handbook of Agile Software Craftsmanship"
Gregor Kiczales et al., "Aspect-Oriented Programming", ECOOP '97
Spring Framework Documentation: Aspect Oriented Programming with Spring