for_develop

[Spring DB] 커넥션풀과 데이터소스 이해

sw_develop — Sat, 12 Jul 2025 15:35:31 +0900

커넥션 풀 이해

데이터베이스 커넥션을 매번 획득

데이터베이스 커넥션을 획득할 때는 아래 과정을 거침

어플리케이션 로직은 DB 드라이버를 통해 커넥션을 조회한다.
DB 드라이버는 DB와 TCP/IP 커넥션을 연결한다. 이 과정에서 3 Way Handshake 같은 TCP/IP 연결을 위한 네트워크 동작이 발생한다.
DB 드라이버는 TCP/IP 커넥션이 연결되면 ID, PW와 기타 부가정보를 DB에 전달한다.
DB는 ID, PW를 통해 내부 인증을 완료하고, 내부에 DB 세션을 생성한다.
DB는 커넥션 생성이 완료되었다는 응답을 보낸다.
DB 드라이버는 커넥션 객체를 생성해서 클라이언트에 반환한다.

단점

커넥션을 새로 만드는 것은 과정도 복잡하고 시간도 많이 소요됨
DB와 어플리케이션 서버 모두 TCP/IP 커넥션을 새로 생성하기 위한 리소스를 매번 사용해야 함
SQL을 실행하는 시간 뿐 아니라 커넥션을 생성하는 시간이 추가되어 결과적으로 응답 속도에 영향을 줌

커넥션 풀 활용

위 문제를 해결하는 아이디어가 커넥션을 미리 생성하고 사용하는 '커넥션 풀' 방법임
커넥션 풀은 서버당 최대 커넥션 수를 제한할 수 있기 때문에 DB에 무한정 연결이 생성되는 것을 막아줌
최근에는 hikariCP를 주로 사용함 (Spring Boot 2.0부터 기본 커넥션 풀로 hikariCP 제공)

커넥션 풀 초기화 및 연결 상태

어플리케이션을 시작하는 시점에 필요한 만큼 커넥션을 미리 생성해서 커넥션 풀에 보관함
커넥션 풀에 들어있는 커넥션은 TCP/IP로 DB와 커넥션이 연결되어 있는 상태이기 때문에 언제든지 SQL을 DB에 전달할 수 있음

커넥션 풀 사용

어플리케이션 로직에서 이제는 DB 드라이버를 통해 새로운 커넥션을 획득하는 것이 아님
이제는 커넥션 풀을 통해 이미 생성되어 있는 커넥션을 객체 참조로 가져다 쓰기만 하면 됨
커넥션 풀에 커넥션을 요청하면 커넥션 풀은 자신이 가지고 있는 커넥션 중 하나를 반환함

어플리케이션 로직은 커넥션 풀에서 받은 커넥션을 사용해 SQL을 DB에 전달하고 그 결과를 받아서 처리함
커넥션을 모두 사용하고 나면 이제는 커넥션을 종료하는 것이 아니라, 다음에 다시 사용할 수 있도록 해당 커넥션을 그대로 커넥션 풀에 반환하면 됨. 이때 커넥션을 종료하는 것이 아니라 커넥션이 살아있는 상태로 커넥션 풀에 반환해야 함

DataSource 이해

커넥션을 획득하는 방법을 추상화

자바에서는 javax.sql.DataSource라는 인터페이스를 제공함
DataSource는 커넥션을 획득하는 방법을 추상화하는 인터페이스임
- 이 인터페이스의 핵심 기능은 커넥션 조회 하나

정리

대부분의 커넥션 풀은 DataSource 인터페이스를 이미 구현해두었으므로, DataSource 인터페이스에만 의존하도록 어플리케이션 로직을 작성하면 됨
DriverManager는 DataSource 인터페이스를 구현하지 않지만 스프링은 DriverManager도 DataSource를 통해서 사용할 수 있도록 DriverManagerDataSource라는 DataSource 인터페이스를 구현한 클래스를 제공함
자바는 DataSource를 통해 커넥션을 획득하는 방법을 추상화함. 이제 어플리케이션 로직은 DataSource 인터페이스에만 의존하면 됨

예제 - DriverManager, 커넥션 풀

Link

참고

스프링 DB 1편

[Spring DB] 데이터 접근 핵심 원리 - JDBC 이해

sw_develop — Sat, 28 Jun 2025 23:15:59 +0900

JDBC 이해

JDBC 등장 이유

어플리케이션 서버와 DB - 일반적인 사용법

커넥션 연결 : 주로 TCP/IP를 사용해서 커넥션을 연결한다.
SQL 전달 : 어플리케이션 서버는 DB가 이해할 수 있는 SQL을 연결된 커넥션을 통해 DB에 전달한다.
결과 응답 : DB는 전달된 SQL을 수행하고 그 결과를 응답한다. 어플리케이션 서버는 응답 결과를 활용한다.

어플리케이션 서버와 DB - DB 변경

각각의 데이터베이스마다 커넥션을 연결하는 방법, SQL을 전달하는 방법, 결과를 응답 받는 방법이 모두 다름
이런 문제를 해결하기 위해 JDBC라는 자바 표준이 등장함

JDBC 표준 인터페이스

대표적으로 다음 3가지 기능을 표준 인터페이스로 정의해서 제공함
- java.sql.Connection - 연결
- java.sql.Statement - SQL을 담은 내용
- java.sql.ResultSet - SQL 요청 응답
JDBC 인터페이스를 각각의 DB 벤더에서 자신의 DB에 맞도록 구현해서 라이브러리로 제공하고 이것을 'JDBC 드라이버'라고 함

JDBC와 최신 데이터 접근 기술

JDBC를 직접 사용하기 보다 JDBC를 편리하게 사용하는 다양한 기술이 존재함
대표적으로 SQL Mapper와 ORM 기술로 나눌 수 있음

1) JDBC 직접 사용

2) SQL Mapper

장점
- JDBC를 편리하게 사용하도록 도와준다.
- SQL 응답 결과를 객체로 편리하게 변환해준다.
- JDBC의 반복 코드를 제거해준다.
단점
- SQL을 직접 작성해야 한다.
대표 기술 : 스프링 JdbcTemplate, MyBatis

3) ORM 기술

ORM은 객체를 관계형 DB 테이블과 매핑해주는 기술
반복적인 SQL을 직접 작성하지 않고, ORM 기술이 개발자 대신에 SQL을 동적으로 만들어 실행해줌
- 추가로 각각의 DB마다 다른 SQL을 사용하는 문제도 중간에서 해결해줌
대표 기술 : JPA, Hibernate, EclipseLink
- JPA는 자바 진영의 ORM 표준 인터페이스이고, 이것을 구현한 기술로 Hibernate와 EclipseLink 등이 있음

데이터베이스 연결

JDBC DriverManager 연결 이해

JDBC 커넥션 인터페이스와 구현

JDBC는 java.sql.Connection 표준 커넥션 인터페이스를 정의함
H2 데이터베이스 드라이버는 JDBC Connection 인터페이스를 구현한 org.h2.jdbc.JdbcConnection 구현체를 제공함

DriverManager 커넥션 요청 흐름

JDBC가 제공하는 DriverManager는 라이브러리에 등록된 DB 드라이버들을 관리하고, 커넥션을 획득하는 기능을 제공함
흐름
- 어플리케이션 로직에서 커넥션이 필요하면 DriverManager.getConnection()을 호출한다.
- DriverManager는 라이브러리에 등록된 드라이버 목록을 자동으로 인식한다. 이 드라이버들에게 순서대로 다음 정보를 넘겨서 커넥션을 획득할 수 있는지 확인한다.
  - URL, 이름, 비밀번호 등 접속에 필요한 추가 정보 전달
  - 각각의 드라이버는 URL 정보를 체크해서 본인이 처리할 수 있는 요청인지 확인함
- 이렇게 찾은 커넥션 구현체가 클라이언트에 반환된다.

참고

스프링 DB 1편 - 데이터 접근 핵심 원리

[stack] valid parentheses

sw_develop — Sat, 7 Jun 2025 11:42:49 +0900

✅ Problem

https://leetcode.com/problems/valid-parentheses/description/

✅ Approach & Solution

방식1) stack, map 사용

class Solution {
    public boolean isValid(String s) {
    	// 유효성 검증을 위한 스택 선언
        Deque<Character> stack = new ArrayDeque<>();

        // 매핑 테이블 선언
        Map<Character, Character> table = new HashMap<>(){{
            put(')', '(');
            put('}', '{');
            put(']', '[');
        }};

        // 한 문자씩 처리
        for (int i = 0; i < s.length(); i++) {
            char c = s.charAt(i);
            // 열림 괄호일 때
            if (!table.containsKey(c)) {
                stack.push(c);
            }
            // 닫힘 괄호일 때
            else if (stack.isEmpty() || table.get(c) != stack.pop()) {
                return false;
            }
        }

        // 문자열 순회 완료 후 빈 스택이어야 함
        return stack.isEmpty();
    }
}

방식2) 배열 사용

char[]의 시작 idx = -1
열림 괄호일 때 대응하는 닫힘 괄호를 배열에 저장
닫힘 괄호일 때 배열의 마지막 원소가 본인과 일치하는지 확인

class Solution {
    public boolean isValid(String s) {
        int idx = -1;
        char[] bracketArr = new char[s.length()];

        for (int i = 0; i < s.length(); i++) {
            char c = s.charAt(i);

            if (c == '(') {
                bracketArr[++idx] = ')';
            } else if (c == '{') {
                bracketArr[++idx] = '}';
            } else if (c == '[') {
                bracketArr[++idx] = ']';
            } else {
                if (idx == -1 || bracketArr[idx--] != c) {
                    return false;
                }
            }
        }
        
        return idx == -1; // 문자열 모두 순회 후 빈 배열이어야 함
    }
}

[linked list] reverse linked list 2

sw_develop — Fri, 6 Jun 2025 12:11:19 +0900

✅ Problem

https://leetcode.com/problems/reverse-linked-list-ii/description/

✅ Approach & Solution

방식)

head 노드를 가리키는 임시 노드를 생성한다.
start와 end 노드를 고정하고 한 단계씩 뒤집기를 수행한다.

/**
 * Definition for singly-linked list.
 * public class ListNode {
 *     int val;
 *     ListNode next;
 *     ListNode() {}
 *     ListNode(int val) { this.val = val; }
 *     ListNode(int val, ListNode next) { this.val = val; this.next = next; }
 * }
 */
class Solution {
    public ListNode reverseBetween(ListNode head, int left, int right) {
        if (head == null) {
            return null;
        }

        ListNode root = new ListNode(0); // 임시 노드 선언
        root.next = head;

        // 임시 노드부터 시작해 변경 필요한 위치 앞으로 이동
        ListNode start = root;
        for (int i = 0; i < left - 1; i++) {
            start = start.next;
        }
        
        // 변경 필요한 마지막 위치 선언
        ListNode end = start.next;

        // right - left만큼 위치 변경 진행
        // start와 end가 가리키는 노드를 고정하고 한 단계씩 뒤집기 수행
        for (int i = 0; i < right - left; i++) {
            ListNode tmp = start.next;
            start.next = end.next;
            end.next = end.next.next;
            start.next.next = tmp;
        }

        // 첫 번째 노드는 임시 노드이므로 그 다음부터 결과로 리턴
        return root.next;
    }
}

[linked list] odd even linked list

sw_develop — Sun, 25 May 2025 10:03:52 +0900

✅ Problem

https://leetcode.com/problems/odd-even-linked-list/description/

✅ Approach & Solution

방식)

주어진 노드를 사용해 odd 노드는 odd 노드끼리, even 노드는 even 노드끼리 연결한다.
odd 노드의 마지막과 even 노드의 첫 번째 연결한다.

/**
 * Definition for singly-linked list.
 * public class ListNode {
 *     int val;
 *     ListNode next;
 *     ListNode() {}
 *     ListNode(int val) { this.val = val; }
 *     ListNode(int val, ListNode next) { this.val = val; this.next = next; }
 * }
 */
class Solution {
    public ListNode oddEvenList(ListNode head) {
        if (head == null) {
            return null;
        }
        
        ListNode odd = head;
        ListNode even = head.next;
        ListNode evenHead = even;

        while(even != null && even.next != null) {
            odd.next = even.next;
            even.next = even.next.next;

            odd = odd.next;
            even = even.next;
        }

        // odd 노드의 마지막과 even 노드의 첫 번째 연결
        odd.next = evenHead;

        return head; // head가 가리키는 노드는 odd의 첫 번째 노드
    }
}

[Spring] 스프링 핵심 원리 - 스프링 AOP 주의사항

sw_develop — Wed, 7 May 2025 06:47:51 +0900

프록시와 내부 호출 - 문제

개요
- 스프링은 프록시 방식의 AOP를 사용함
- AOP를 적용하려면 항상 프록시를 통해서 대상 객체(Target)를 호출해야 함
- 만약 프록시를 거치지 않고 대상 객체를 직접 호출하게 되면 AOP가 적용되지 않으므로 Advice(부가 기능)도 호출되지 않음
일반적인 상황
- AOP를 적용하면 스프링은 대상 객체 대신에 프록시 객체를 스프링 빈으로 등록함
- 따라서 스프링은 의존관계 주입 시 항상 프록시 객체를 주입함
- 프록시 객체가 주입되기 때문에 대상 객체를 직접 호출하는 문제는 일반적으로 발생하지 않음
문제 상황
- 대상 객체의 내부에서 메서드 호출이 발생하면 프록시를 거치지 않고 대상 객체를 직접 호출하는 문제가 발생함
프록시 방식의 AOP 한계 : 메서드 내부 호출에 프록시를 적용할 수 없음

프록시와 내부 호출 - 대안

1. 자기 자신 주입

내부 호출을 해결하는 가장 간단한 방법은 자기 자신을 의존관계 주입 받는 것
- 생성자 주입 방식은 순환 사이클을 만들기 때문에 사용 불가하므로 setter 주입 사용해야 함

예시)

import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Slf4j
@Aspect
public class CallLogAspect {

    @Before("execution(* com.example.demo.proxy.internalcall..*(..))")
    public void doLog(JoinPoint joinPoint) {
        log.info("app={}", joinPoint.getSignature());
    }
}

아래 CallServiceV1에 AOP를 적용하기 위해 Aspect 정의함

import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Slf4j
@Component
public class CallServiceV1 {

    private CallServiceV1 callServiceV1;

    @Autowired
    public void setCallServiceV1(CallServiceV1 callServiceV1) {
        this.callServiceV1 = callServiceV1;
    }

    public void external() {
        log.info("call external");
        callServiceV1.internal(); // 외부 메서드 호출로 변경
    }

    private void internal() {
        log.info("call internal");
    }
}

자기자신을 의존관계 주입으로 받는 경우 생성자 주입은 순환 사이클을 만들기 때문에 사용할 수 없음 (위에서는 setter 주입 대신 사용)
스프링에서 AOP가 적용된 대상을 의존관계 주입 받으면 주입 받은 대상은 실제 자신이 아니라 프록시 객체임
위에서 수정자를 통해 주입받은 callServiceV1은 프록시이므로 AOP를 적용할 수 있음

2. 지연 조회

스프링 빈을 지연해서 조회하는 방식으로, ObjectProvider 혹은 ApplicationContext를 사용하면 됨
- ObjectProvider는 스프링 컨테이너에서 객체를 조회하는 것을 스프링 빈 생성 시점이 아니라 실제 객체를 사용하는 시점으로 지연할 수 있음

예시)

아래 CallServiceV2에 AOP를 적용하기 위해 Aspect 정의한 상태라고 가정

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Component;

@Slf4j
@Component
@RequiredArgsConstructor
public class CallServiceV2 {

    // private final ApplicationContext applicationContext;
    private final ObjectProvider<CallServiceV2> callServiceProvider;

    public void external() {
        log.info("call external");
        // CallServiceV2 callServiceV2 = applicationContext.getBean(CallServiceV2.class);
        CallServiceV2 serviceV2 = callServiceProvider.getObject();
        serviceV2.internal(); // 외부 메서드 호출
    }

    private void internal() {
        log.info("call internal");
    }
}

`callServiceProvider.getObject()`를 호출하는 시점에 스프링 컨테이너에서 빈을 조회함 (프록시 객체가 반환됨)

3. 구조 변경

가장 나은 대안은 내부 호출이 발생하지 않도록 구조를 변경하는 것 (실제 이 방법을 가장 권장함)
- 구조를 변경하는 것은 클래스 분리말고도 다양한 방법들이 있을 수 있음

예시)

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;

@Slf4j
@Component
@RequiredArgsConstructor
public class CallServiceV3 {

    private final InternalService internalService;

    public void external() {
        log.info("call external");
        internalService.internal(); // 외부 메서드 호출
    }
}

내부 호출을 InternalService라는 별도의 클래스로 분리함

프록시 기술과 한계

JDK 동적 프록시

구체 클래스로 타입 캐스팅 불가
인터페이스를 기반으로 프록시를 생성하기 때문 (인터페이스를 구현하여 프록시 생성)

예시)

인터페이스를 구현하여 프록시를 생성하므로 인터페이스의 구체 클래스로 타입 캐스팅 불가

구체 클래스를 상속하여 프록시를 생성하므로 인터페이스와 구체 클래스로 타입 캐스팅 가능

CGLIB

구체 클래스를 상속받기 때문에 다음과 같은 문제가 있음
- 대상 클래스에 기본 생성자 필수
- 대상 클래스의 생성자 2번 호출
- final 키워드 클래스, 메서드 사용 불가

예시)

대상 클래스에 기본 생성자 필수

자바 언어에서 상속을 받으면 자식 클래스의 생성자를 호출할 때 자식 클래스의 생성자에서 부모 클래스의 생성자도 호출해야 함
- 이 부분이 코드상 생략되어 있다면 컴파일 시 컴파일러가 자식 클래스의 생성자 첫 줄에 부모 클래스의 기본 생성자를 호출하는 super()가 자동으로 추가함 (이것은 자바 문법 규약)
CGLIB 프록시는 대상 클래스를 상속 받고, 생성자에서 대상 클래스의 기본 생성자를 호출함. 따라서 대상 클래스에 기본 생성자를 만들어야 함
- 기본 생성자는 파라미터가 하나도 없는 생성자
- 생성자가 하나도 없으면 자동으로 만들어짐

대상 클래스의 생성자 2번 호출 문제

아래 상황으로 생성자가 2번 호출됨
- 실제 target의 객체를 생성할 때
- 프록시 객체를 생성할 때 부모 클래스의 생성자 호출

final 키워드 클래스, 메서드 사용 불가

final 키워드가 클래스에 있으면 상속이 불가능하고, 메서드에 있으면 오버라이딩 불가능함
CGLIB는 상속을 기반으로 하기 때문에 두 경우 프록시가 생성되지 않거나 정상 동작하지 않음

프록시 기술과 한계 - 스프링의 해결책

스프링의 기술 선택 변화

스프링 3.2부터 CGLIB를 스프링 내부에 함께 패키징
- 스프링은 CGLIB 라이브러리를 스프링 내부에 함께 패키징해서 별도의 라이브러리 추가 없이 CGLIB를 사용할 수 있게 됨
CGLIB 기본 생성자 필수 문제 해결
- 스프링 4.0부터 CGLIB의 기본 생성자가 필수인 문제가 해결됨
- objenesis라는 특별한 라이브러리를 사용해 기본 생성자 없이 객체 생성이 가능해짐 (해당 라이브러리는 생성자 호출 없이 객체를 생성할 수 있게 해줌)
생성자 2번 호출 문제
- 스프링 4.0부터 CGLIB의 생성자 2번 호출 문제가 해결됨 (target 객체 생성할 때만 1번 호출됨)
- 이것도 objenesis 라이브러리 덕분에 가능해짐
스프링 부트 2.0부터 CGLIB 기본 사용
- 스프링 부트는 별도의 설정이 없다면 AOP를 적용할 때 기본적으로 proxyTargetClass=true로 설정해서 사용함 (CGLIB 사용)
- 인터페이스가 있어도 JDK 동적 프록시가 아닌 항상 CGLIB를 사용해 구체 클래스를 기반으로 프록시를 생성함
- 다음과 같이 설정하면 JDK 동적 프록시도 사용할 수 있음
  - application.properties > spring.aop.proxy-target-class=false

정리하자면,

스프링 부트 2.0에서부터 CGLIB를 기본으로 사용하도록 함
CGLIB를 사용하면 JDK 동적 프록시에서 동작하지 않는 구체 클래스 주입이 가능함
추가로 objenesis 라이브러리를 사용해 CGLIB의 단점들이 많이 해결됨

참고

스프링 핵심 원리 - 고급편

[linked list] swap nodes in pairs

sw_develop — Sun, 4 May 2025 11:45:09 +0900

✅ Problem

https://leetcode.com/problems/swap-nodes-in-pairs/description/

✅ Approach & Solution

방식)

아래 작업을 하나의 사이클로 수행

ex) dummy -> 노드1 -> 노드2 -> 노드3 -> 노드4
- 패턴화 시키기 위해 dummy 노드 추가
- 노드1과 노드2 swap
- dummy가 노드2를 가리키도록 업데이트

/**
 * Definition for singly-linked list.
 * public class ListNode {
 *     int val;
 *     ListNode next;
 *     ListNode() {}
 *     ListNode(int val) { this.val = val; }
 *     ListNode(int val, ListNode next) { this.val = val; this.next = next; }
 * }
 */
class Solution {
    public ListNode swapPairs(ListNode head) {
        ListNode dummy = new ListNode(0, head);
        ListNode prev = dummy; // swap 대상 노드의 이전 노드
        ListNode cur = head; // swap 대상 노드

        while (cur != null && cur.next != null) {
            ListNode nextPairNode = cur.next.next; // 다음 swap 대상 노드 저장

            ListNode second = cur.next; // 노드2 저장
            second.next = cur; // 노드2 -> 노드1 연결
            cur.next = nextPairNode; // 노드1 -> 노드3 연결

            prev.next = second; // swap 대상 노드의 이전 노드 -> 노드2 연결

            prev = cur;
            cur = nextPairNode;
        }

        return dummy.next;
    }
}

[Spring] 스프링 핵심 원리 - 스프링 AOP

sw_develop — Wed, 23 Apr 2025 21:45:40 +0900

AOP 소개 - 핵심 기능과 부가 기능

어플리케이션 로직은 크게 핵심 기능과 부가 기능으로 나눌 수 있음
- 핵심 기능 : 해당 객체가 제공하는 고유의 기능
- 부가 기능 : 핵심 기능을 보조하기 위해 제공되는 기능 ex) 로그 추적 로직, 트랜잭션 기능
  - 단독으로 사용되지 않고, 핵심 기능과 함께 사용됨
부가 기능 적용 문제
- 보통 부가 기능은 여러 클래스에 걸쳐서 함께 사용됨. 따라서 이러한 부가 기능은 횡단 관심사(cross-cutting concerns)가 됨
  - 즉, 하나의 부가 기능이 여러 곳에 동일하게 사용되다는 뜻
- 아래와 같은 문제 발생함
  - 부가 기능이 여러 곳에 퍼져 중복 코드를 만들어냄
  - 중복으로 인해 부가 기능을 변경하거나 부가 기능의 적용 대상을 변경할 때 많은 수정이 필요함

AOP 소개 - Aspect

위와 같은 부가 기능의 문제를 보완하기 위해 Aspect라는 개념을 도입함
- 부가 기능과 부가 기능을 어디에 적용할지 선택하는 기능을 합해서 하나의 모듈로 만듦
- Aspect는 부가 기능과, 해당 부가 기능을 어디에 적용할지 정의한 것
- 스프링이 제공하는 Advisor도 Advice(부가 기능)와 Pointcut(적용 대상)을 가지고 있어서 개념상 하나의 Aspect임
Aspect는 '관점'이라는 뜻으로, 이름 그대로 어플리케이션을 바라보는 관점을 하나하나의 기능에서 횡단 관심사(cross-cutting concerns) 관점으로 달리 보는 것임
Aspect를 사용한 프로그래밍 방식을 '관점 지향 프로그래밍 AOP(Aspect-Oriented Programming)'이라 함
- 횡단 관심사를 깔끔하게 처리하기 어려운 OOP의 부족한 부분을 보조하는 목적으로 개발됨
AOP의 대표적인 구현으로 AspectJ 프레임워크가 있음
- 스프링도 AOP를 지원하지만 대부분 AspectJ의 문법을 차용하고, AspectJ가 제공하는 기능의 일부만 제공함

AOP 적용 방식

스프링은 런타임 시점에 프록시 방식의 AOP 를 사용함

런타임 시점은 컴파일과 클래스 로딩이 끝나서 이미 자바가 실행되고 난 다음을 말함
- 즉, 자바의 메인(main) 메서드가 이미 실행된 후
따라서 자바 언어가 제공하는 범위 안에서 부가 기능을 적용해야 함
- 스프링과 같은 컨테이너의 도움을 받고, 프록시과 DI, Bean Post Processor 같은 기능들을 동원해야 함
최종적으로 프록시를 통해 스프링 빈에 부가 기능을 적용할 수 있음
참고)
- 스프링은 AspectJ의 문법을 차용하고 프록시 방식의 AOP를 적용함. AspectJ를 직접 사용하는 것이 아님

프록시 방식을 사용하는 스프링 AOP의 장단점

장점
- 특별한 컴파일러나, 자바를 실행할 때 복잡한 옵션과 클래스 로더 조작기를 설정하지 않아도 됨
- 스프링만 있으면 얼마든지 AOP를 적용할 수 있음
단점
- AOP 기능에 일부 제약이 있음
  - 메서드 실행 지점에만 AOP를 적용할 수 있음
    - 프록시는 메서드 오버라이딩 개념으로 동작함. 따라서 생성자나 static 메서드, 필드 값 접근에는 프록시 개념이 적용될 수 없음
    - 즉, 스프링 AOP의 조인 포인트는 메서드 실행으로 제한됨
  - 스프링 컨테이너가 관리할 수 있는 스프링 빈에만 AOP를 적용할 수 있음
    - BeanPostProcessor를 사용해 프록시 객체를 스프링 빈으로 등록하기 때문
    - 대상 객체가 스프링 빈이 아니라면 프록시 객체를 런타임에 생성하지 않음

정리하면,

스프링이 제공하는 AOP는 프록시를 사용함
(스프링 빈을 대상으로) 프록시를 통해 메서드를 실행하는 시점에만 AOP가 적용됨
스프링 AOP는 별도의 추가 자바 설정 없이 스프링만 있으면 편리하게 AOP를 사용할 수 있음

추가) 컴파일 시점, 클래스 로딩 시점의 AOP 적용 방식

컴파일 시점

.java 소스 코드를 컴파일러를 사용해 .class를 만드는 시점에 부가 기능 로직을 추가함
AspectJ가 제공하는 특별한 컴파일러를 사용해야 함
컴파일된 .class를 디컴파일 해보면 Aspect 관련 호출 코드가 들어가 있음
AspectJ 컴파일러는 Aspect를 확인해 해당 클래스가 적용 대상인지 먼저 확인하고, 적용 대상인 경우에 부가 기능 로직을 적용함
이렇게 원본 로직에 부가 기능 로직이 추가되는 것을 '위빙(Weaving)'이라 함

단점

컴파일 시점에 부가 기능을 적용하려면 특별한 컴파일러도 필요하고 복잡함

클래스 로딩 시점

자바를 실행하기 위해 클래스 파일을 JVM의 런타임 데이터 영역에 로딩함
이때 중간에서 .class 파일을 조작한 다음 JVM에 올릴 수 있음
자바 언어는 .class를 JVM에 로딩하기 전에 조작할 수 있는 기능을 제공함
이 시점에 Aspect를 적용하는 것을 '로드 타임 위빙'이라 함

단점

자바를 실행할 때 특별한 옵션(java -javaagnet)을 통해 클래스 로더 조작기를 지정해야 하는데, 이 부분이 번거롭고 운영하기 어려움

런타임 시점에 적용하는 AOP와의 차이

부가 기능 적용 차이
- 컴파일 시점, 클래스 로딩 시점에 적용하는 AOP
  - 실제 대상 코드에 Aspect를 통한 부가 기능 호출 코드가 포함됨
  - AspectJ를 직접 사용해야 함
- 런타임 시점에 적용하는 AOP
  - 실제 대상 코드는 그대로 유지됨. 대신 프록시를 통해 부가 기능이 적용됨
  - 따라서 항상 프록시를 통해야 부가 기능을 사용할 수 있음
AOP 적용 위치
- 컴파일 시점, 클래스 로딩 시점에 적용하는 AOP
  - AspectJ를 사용해 바이트코드를 실제 조작하기 때문에 모든 지점에 적용할 수 있음
    - 적용 가능 지점(join point) : 생성자, 필드 값, static 메서드, 메서드
- 런타임 시점에 적용하는 AOP
  - 프록시 방식을 사용하기 때문에 메서드 실행 지점에만 적용할 수 있음 (메서드 오버라이딩 불가능한 static 메서드 제외)

AOP 용어 정리

Join Point
- Advice가 적용될 수 있는 위치, 메서드 실행, 생성자 호출, 필드 값 접근, static 메서드 접근 같은 프로그램 실행 중 지점
- 추상적인 개념으로, AOP를 적용할 수 있는 모든 지점을 의미함
- 스프링 AOP는 프록시 방식을 사용하므로 Join Point는 항상 메서드 실행 지점으로 제한됨
Pointcut
- Join Point 중에서 Advice가 적용될 위치를 선별함
- 주로 AspectJ 표현식을 사용해 지정함
- 프록시를 사용하는 스프링 AOP는 메서드 실행 지점만 Pointcut으로 선별 가능
Target
- Advice를 받는 객체, Pointcut으로 결정됨
Advice
- 부가 기능
- Around, Before, After와 같은 다양한 종류의 Advice가 있음
Aspect
- Advice + Pointcut을 모듈화한 것
- @Aspect를 생각하면 됨
- 여러 Advice와 Pointcut이 함께 존재함
Advisor
- 하나의 Advice와 하나의 Pointcut으로 구성
- 스프링 AOP에서만 사용되는 특별한 용어
Weaving
- Pointcut으로 결정한 Target의 Join Point에 Advice를 적용하는 것
- 핵심 기능 코드에 영향을 주지 않고 부가 기능을 추가할 수 있음
AOP 프록시
- AOP 기능을 구현하기 위해 만든 프록시 객체
- 스프링에서 AOP 프록시는 JDK 동적 프록시 또는 CGLIB 프록시임

[Spring] 스프링 핵심 원리 - @Aspect AOP

sw_develop — Tue, 22 Apr 2025 23:33:34 +0900

@Aspect 프록시 - 적용

스프링은 @Aspect 어노테이션으로 Pointcut과 Advice로 구성되어 있는 Advisor 생성 기능을 지원함

예시)

import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;

@Slf4j
@Aspect
public class LogTraceAspect {

    private final LogTrace logTrace;

    public LogTraceAspect(LogTrace logTrace) {
        this.logTrace = logTrace;
    }

    @Around("execution(* com.example.demo.proxy..*(..))")
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {

        TraceStatus status = null;

        try {
            String message = joinPoint.getSignature().toShortString();
            status = logTrace.begin(message);

            Object result = joinPoint.proceed();

            logTrace.end(status);
            return result;
        } catch (Exception e) {
            logTrace.exception(status, e);
            throw e;
        }
    }
}

@Aspect : 어노테이션 기반 프록시를 적용할 때 필요함
@Around(...)
- @Around의 값에 Pointcut 표현식을 넣음 (표현식은 AspectJ 표현식을 사용함)
- @Around의 메서드는 Advice가 됨
ProceedingJoinPoint joinPoint : Advice에서 살펴본 `MethodInvocation methodInvocation`과 유사한 기능임
- 내부에 실제 호출 대상, 전달 인자, 어떤 객체와 어떤 메서드가 호출되었는지 정보가 포함되어 있음
joinPoint.proceed() : 실제 호출 대상(target)을 호출함
@Aspect가 있어도 스프링 빈으로 등록해줘야 함

@Aspect 프록시 - 설명

스프링의 자동 프록시 생성기(AnnotationAwareAspectJAutoProxyCreator)는 2가지 역할을 수행함
1. @Aspect를 보고 Advisor(Pointcut + Advice)로 변환해서 저장한다.
2. Advisor를 기반으로 프록시를 생성한다.

1) @Aspect를 Advisor로 변환해서 저장하는 과정

실행 : 스프링 어플리케이션 로딩 시점에 자동 프록시 생성기를 호출한다.
모든 @Aspect 빈 조회 : 자동 프록시 생성기는 스프링 컨테이너에서 @Aspect 어노테이션이 붙은 스프링 빈을 모두 조회한다.
Advisor 생성 : @Aspect Advisor Builder를 통해 @Aspect 어노테이션 정보를 기반으로 Advisor를 생성한다.
@Aspect 기반 Advisor 저장 : 생성한 Advisor를 @Aspect Advisor Builder 내부에 저장한다.

추가) @Aspect Advisor Builder

BeanFactoryAspectJAdvisorsBuilder 클래스
@Aspect의 정보를 기반으로 Pointcut, Advice, Advisor를 생성하고 보관하는 것을 담당함
@Aspect의 정보를 기반으로 Advisor를 만들고, @Aspect Advisor Builder 내부 저장소에 캐시함
캐시에 Advisor가 이미 만들어져 있는 경우 캐시에 저장된 Advisor를 반환함

2) Advisor를 기반으로 프록시 생성

자동 프록시 생성기의 작동 과정

생성 : 스프링 빈 대상이 되는 객체를 생성함 (@Bean, 컴포넌트 스캔 모두 포함)
전달 : 생성된 객체를 빈 저장소에 등록하기 직전에 빈 후처리기에 전달함 (여기서는 스프링의 자동 프록시 생성기에 전달됨)
Advisor 조회
1. Advisor 빈 조회 : 스프링 컨테이너에서 Advisor 빈을 모두 조회함
2. @Aspect Advisor 조회 : @Aspect Advisor Builder 내부에 저장된 Advisor를 모두 조회함
프록시 적용 대상 체크
- 3-1, 3-2에서 조회한 Advisor에 포함되어 있는 Pointcut을 사용해서 해당 객체가 프록시를 적용할 대상인지 판단함
- 이때 객체의 클래스 정보는 물론이고, 해당 객체의 모든 메서드를 Pointcut에 하나하나 모두 매칭해봄
- 조건이 하나라도 만족하면 프록시 적용 대상이 됨 (메서드 하나만 Pointcut 조건에 만족해도 프록시 적용 대상이 됨)
프록시 생성
- 프록시 적용 대상이면 프록시를 생성하고 프록시를 반환하고 해당 프록시를 스프링 빈으로 등록함
- 프록시 적용 대상이 아니라면 원본 객체를 반환해서 원본 객체를 스프링 빈으로 등록함
빈 등록 : 반환된 객체는 스프링 빈으로 등록됨

참고

스프링 핵심 원리 - 고급편

[Spring] 스프링 핵심 원리 - 빈 후처리기

sw_develop — Mon, 21 Apr 2025 23:54:09 +0900

빈 후처리기 (BeanPostProcessor)

@Bean이나 컴포넌트 스캔에 의해 스프링이 빈 저장소에 등록할 목적으로 생성한 객체를 빈 저장소에 등록하기 직전에 조작하고 싶다면 BeanPostProcessor를 사용하면 됨
- 빈 객체를 프록시로 교체하는 것도 가능함

BeanPostProcessor에 의한 스프링 빈 등록 과정

생성 : 스프링 빈 대상이 되는 객체를 생성한다. (@Bean, 컴포넌트 스캔 모두 포함)
전달 : 생성된 객체를 빈 저장소에 등록하기 직전에 BeanPostProcessor에 전달한다.
후 처리 작업 : BeanPostProcessor는 전달받은 스프링 빈 객체를 조작하거나 다른 객체로 바꿔치기 할 수 있다.
등록 : BeanPostProcessor는 빈을 반환한다. 전달된 빈을 그대로 반환하면 해당 빈이 등록되고, 바꿔치기 하면 다른 객체가 빈 저장소에 등록된다.

참고) BeanPostProcessor 인터페이스 - 스프링 제공

package org.springframework.beans.factory.config;

public interface BeanPostProcessor {
    @Nullable
    default Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }

    @Nullable
    default Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }
}

빈 후처리기를 사용하려면 해당 인터페이스를 구현하고, 스프링 빈으로 등록하면 됨
postProcessBeforeInitialization : 객체 생성 이후 @PostConstruct 같은 초기화 발행하기 전에 호출되는 포스트 프로세서
postProcessAfterInitialization : 객체 생성 이후 @PostConstruct 같은 초기화 발행한 다음에 호출되는 포스트 프로세서

스프링이 제공하는 빈 후처리기

스프링은 프록시를 생성하기 위한 빈 후처리기를 이미 만들어서 제공함

build.gradle 추가

implementation 'org.springframework.boot:spring-boot-starter-aop'

해당 라이브러리를 추가하면 aspectjweaver라는 aspectJ 관련 라이브러리를 등록하고, 스프링부트가 AOP 관련 클래스를 자동으로 스프링 빈에 등록함
- 스프링부트가 활성화하는 빈은 AopAutoConfiguration 클래스 참고
스프링부트가 없던 시절에는 @EnableAspectJAutoProxy를 직접 사용해야 했는데, 이 부분을 스프링부트가 자동으로 처리해줌

자동 프록시 생성기 (AutoProxyCreator)

위 스프링부트 자동 설정으로 AnnotationAwareAspectJAutoProxyProcessor 라는 빈 후처리기가 스프링 빈에 자동 등록됨
- 이름 그대로 자동으로 프록시를 생성해주는 빈 후처리기
스프링 빈으로 등록된 Advisor들을 자동으로 찾아서 프록시가 필요한 곳에 프록시를 적용해줌
- Advisor 안에는 Pointcut과 Advice가 이미 포함되어 있음
- 따라서 Advisor만 알고 있으면 Pointcut으로 어떤 스프링 빈에 프록시를 적용해야 할지 알 수 있고, Advice로 부가 기능을 적용하면 됨

작동 과정

생성 : 스프링이 스프링 빈 대상이 되는 객체를 생성한다. (@Bean, 컴포넌트 스캔 모두 포함)
전달 : 생성된 객체를 빈 저장소에 등록하기 직전에 빈 후처리기에 전달한다.
모든 Advisor 빈 조회 : 스프링 컨테이너에서 모든 Advisor를 조회한다.
프록시 적용 대상 체크 : 앞서 조회한 Advisor에 포함되어 있는 Pointcut를 사용해서 해당 객체가 프록시 적용 대상인지 판단한다.
- 대상 객체의 클래스 정보와 모든 메서드를 Pointcut에 모두 매칭하고 조건이 하나라도 만족하면 프록시 적용 대상이 됨
프록시 생성 : 프록시 적용 대상이면 프록시를 생성하고 반환해서 프록시를 스프링 빈으로 등록함
- 프록시 적용 대상이 아니라면 원본 객체를 반환해서 원본 객체를 스프링 빈으로 등록함
빈 등록 : 반환된 객체는 스프링 빈으로 등록됨

생성된 프록시

프록시는 내부에 Advisor와 실제 호출해야 할 대상 객체(target)을 알고 있음

예시)

Advisor Bean 등록

import org.springframework.aop.Advisor;
import org.springframework.aop.support.DefaultPointcutAdvisor;
import org.springframework.aop.support.NameMatchMethodPointcut;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class AutoProxyConfig {

    @Bean
    public Advisor advisor1() {
        NameMatchMethodPointcut pointcut = new NameMatchMethodPointcut();
        pointcut.setMappedNames("request*", "order*", "save*");

        TimeAdvice advice = new TimeAdvice();
        
        // advisor = pointcut + advice
        return new DefaultPointcutAdvisor(pointcut, advice);
    }
}

BeanPostProcessor는 등록하지 않고 Advisor만 Bean으로 등록함
스프링은 자동 프록시 생성기(AnnotationAwareAspectJAutoProxyCreator)라는 빈 후처리기를 자동으로 등록해줌

중요: Pointcut의 2가지 용도

프록시 적용 여부 판단 - 빈 생성 단계
- 자동 프록시 생성기는 Pointcut을 사용해 해당 빈이 프록시를 생성할 필요가 있는지/없는지 체크함
- 클래스 + 메서드 조건을 모두 비교함
  - 모든 메서드를 체크하기 위해 Pointcut 조건에 하나하나 매칭해봄
  - 조건에 부합하는 것이 하나라도 있으면 프록시를 생성함
- 만약 조건에 부합하는 것이 하나도 없으면 프록시를 생성할 필요가 없으므로 프록시를 생성하지 않음
Advice 적용 여부 판단 - 사용 단계
- 프록시가 호출되었을 때 부가 기능인 Advice를 적용할지 말지 Pointcut을 보고 판단함
  - ex) 대상 빈 : 프록시 적용된 orderController, pointcut : request*로 시작하는 메서드
    - orderController의 request() : 현재 포인트컷 조건에 만족하므로 프록시는 Advice를 먼저 호출하고, 이후 target을 호출함
    - orderController의 noLog() : 현재 포인트컷 조건에 만족하지 않으므로 Advice를 호출하지 않고 바로 target만 호출함
참고)
- 프록시를 모든 곳에 생성하는 것은 비용 낭비이므로, 꼭 필요한 곳에 최소한의 프록시를 적용해야 함
- 자동 프록시 생성기는 모든 스프링 빈에 프록시 빈을 적용하지 않고 Pointcut으로 한번 필터링해서 Advisor가 사용될 가능성이 있는 곳에만 프록시를 생성함

하나의 프록시, 여러 Advisor 적용

Q. 스프링 빈으로 등록된 advisor1, advisor2가 제공하는 포인트컷의 조건을 모두 만족하면 스프링의 프록시 자동 생성기는 프록시를 몇 개 생성할까?

프록시 자동 생성기는 프록시를 '하나만' 생성함
프록시 팩토리가 생성하는 프록시는 내부에 여러 advisor들을 포함할 수 있기 때문에 프록시를 여러 개 생성해서 비용을 낭비할 이유가 없음

프록시 자동 생성기 상황별 정리

advisor1의 포인트컷만 만족 : 프록시 1개 생성, 프록시에 advisor1만 포함
advisor1, advisor2의 포인트컷을 모두 만족 : 프록시 1개 생성, 프록시에 advisor1과 advisor2 모두 포함
advisor1, advisor2의 포인트컷을 모두 만족하지 않음 : 프록시가 생성되지 않음

참고

스프링 핵심 원리 - 고급편