Spring/SpringCore - advance18

• 스프링 핵심원리(심화) - 빈 후처리기(BeanPostProcessor) 이전 글에서는 프록시 팩토리를 이용해서 V1, V2 애플리케이션에 LogTrace 기능을 적용해봤다.그 과정에서 꽤 많은 문제가 해결됐다.인터페이스가 있으면 JDK 동적 프록시구체 클래스만 있으면 CGLIBAdvisor, Advice, Pointcut을 통해 어떤 기능을 어디에 적용할지도 명확하게 분리할 수 있었다여기까지 보면 꽤 깔끔해 보인다.그런데 막상 애플리케이션에 적용하려고 하면 또 다른 문제가 드러난다. 예를 들어 V1, V2 각각에 대해 프록시 설정 클래스를 따로 만들어야 했고,빈이 많아질수록 이런 설정 코드도 계속 늘어난다.게다가 컴포넌트 스캔을 사용하는 경우에는, 원본 객체가 이미 스프링 빈으로 등록된 뒤라서 지금까지의 방식으로는 프록시를 끼워 넣기가 쉽지 않다. 바로 이 지점에서 등장하는.. Spring/SpringCore - advance 2026. 3. 30.

• 스프링 핵심원리(심화) - 하나의 프록시, 여러 어드바이저 그리고 프록시 팩토리 적용 이전 글에서는 Advisor의 개념과 함께, 여러 어드바이저를 하나의 대상에 적용하려면 어떻게 해야 하는지 살펴봤다.가장 먼저 떠오르는 방법은 프록시를 여러 개 겹쳐서 만드는 방식이었다. 즉,target을 감싼 프록시를 하나 만들고그 프록시를 다시 또 다른 프록시로 감싸는 식으로여러 어드바이스를 순차적으로 적용하는 구조였다.이 방식 자체가 틀린 것은 아니지만,어드바이저가 늘어날수록 프록시도 계속 늘어나야 한다는 점에서 구조가 점점 복잡해진다.그렇다면 스프링은 이 문제를 어떻게 해결할까? 이번 글에서는 바로 그 다음 단계인하나의 프록시에 여러 어드바이저를 적용하는 방식을 먼저 보고,이어서 그 구조를 실제 애플리케이션에 적용하는 흐름까지 정리해보려고 한다. 하나의 프록시, 여러 어드바이저스프링은 여러 프록시.. Spring/SpringCore - advance 2026. 3. 26.

• 스프링 핵심원리( 심화 ) - 프록시 팩토리(ProxyFactory, Advisor, Advice , Pointcut) 이전 글에서는 스프링의 ProxyFactory를 사용하면JDK 동적 프록시와 CGLIB를 직접 구분해서 다루지 않아도 된다는 점을 정리했다.정리해보면 프록시 팩토리는 다음 문제를 꽤 깔끔하게 해결해줬다. 인터페이스가 있으면 JDK 동적 프록시 사용구체 클래스만 있으면 CGLIB 사용개발자는 구체 기술보다 Advice 중심으로 부가 기능을 작성하면 됨여기까지 보면 프록시를 적용하는 방식 자체는 꽤 편리해진다.그런데 여기서 또 다음 질문이 생긴다. 부가 기능은 알겠는데, 어디에 적용할지는 어떻게 정할까?모든 메서드에 다 적용하지 않고 특정 메서드에만 적용할 수는 없을까?그리고 Advice, Pointcut, Advisor는 서로 뭐가 다른 걸까?이번 글에서는 바로 이 부분을 정리해보려고 한다. Advisor.. Spring/SpringCore - advance 2026. 3. 25.

• 스프링 핵심원리( 심화 ) - 프록시 팩토리 앞에서 JDK 동적 프록시와 CGLIB를 각각 살펴봤다.JDK 동적 프록시는 인터페이스가 있을 때 사용할 수 있고, CGLIB는 구체 클래스를 기반으로 프록시를 만들 수 있다는 점도 확인했다. 그런데 마지막에 다음과 같은 의문으로 글을 마무리 하였다. 인터페이스가 있으면 JDK 동적 프록시를 쓰고인터페이스가 없으면 CGLIB를 써야 하는데 이걸 개발자가 매번 직접 구분해서 적용해야 할까? 그리고 부가 기능을 넣기 위해서도JDK 동적 프록시에서는 InvocationHandlerCGLIB에서는 MethodInterceptor를 따로 만들어야 했다.게다가 앞에서 해봤던 것처럼 특정 조건에만 프록시 로직을 적용하는 기능까지 넣으려면 코드가 점점 번거로워진다. 위와 같은 번거로움과 문제점을 해결해주는 스프링이 지.. Spring/SpringCore - advance 2026. 3. 23.

• 스프링 핵심원리( 심화 ) - 동적 프록시( CGLIB ) 이전 글에서 살펴본 것처럼 JDK 동적 프록시는 인터페이스가 필수이다.따라서 인터페이스가 존재하는 경우에는 JDK 동적 프록시를 사용할 수 있지만,인터페이스 없이 구체 클래스만 존재하는 경우에는 같은 방식으로 프록시를 적용할 수 없다.이 문제를 해결하기 위해 사용할 수 있는 기술이 바로 CGLIB이다. CGLIB란?CGLIB(Code Generator Library) 는 바이트코드를 조작해서 동적으로 클래스를 생성하는 기술을 제공하는 라이브러리이다.JDK 동적 프록시는 인터페이스를 구현해서 프록시를 만들지만,CGLIB는 구체 클래스를 상속해서 프록시를 생성한다.즉, CGLIB를 사용하면 인터페이스가 없어도 구체 클래스만 가지고 동적 프록시를 만들어낼 수 있다.( 원래 CGLIB는 외부 라이브러리였지만, .. Spring/SpringCore - advance 2026. 3. 17.

• 스프링 핵심원리( 심화 ) - 동적 프록시(JDK 동적 프록시 2) 이전 글에서는 JDK 동적 프록시가 무엇인지, 그리고 InvocationHandler를 이용해 공통 로직을 동적으로 적용할 수 있다는 점을 정리했다. 이번에는 실제 애플리케이션에 JDK 동적 프록시를 적용해보자.다만 JDK 동적 프록시는 인터페이스 기반으로 동작하기 때문에, 인터페이스가 존재하는 V1 애플리케이션에만 적용할 수 있다. JDK 동적 프록시 - 적용1먼저 LogTrace를 적용할 수 있는 InvocationHandler 구현체를 만들어보자.LogTraceBasicHandlerpackage hello.proxy.config.v2_dynamicproxy.handler;import hello.proxy.trace.TraceStatus;import hello.proxy.trace.logtrace.L.. Spring/SpringCore - advance 2026. 3. 17.

• 스프링 핵심원리( 심화 ) - 동적 프록시(JDK 동적 프록시 1) JDK 동적 프록시 및 CGLIB 기술을 활용하여, 프록시 기술을 적용하는 방법에 대해서 학습한 내용을 정리해보겠다. 지금부터 다루는 내용에 대해서 정리하자면, 프록시가 필요한 대상마다 직접적으로 각각의 프록시 클래스를 만드는 것이 아닌 하나의 프록시 객체를 통해 적용 대상에 필요한 부가적인기능을 일괄적으로 적용하는 것이다. JDK 동적 프록시 및 CGLIB 기술에 대해서 이해해보자. JDK 동적 프록시 JDK 동적 프록시는 JAVA가 기본적으로 제공해주는 기능이다.Interface를 기반에 두고 동적으로 프록시 객체를 런타임에 생성하며 필요한 실행 로직을 수행해주는 기술이다.( JDK 동적 프록시 기술을 사용하여면, Interface가 필수이다. ) 기본 예제 JDK 동적 프록시를 적용하기 위.. Spring/SpringCore - advance 2026. 3. 15.

• 스프링 핵심원리( 심화 ) - 동적 프록시(리플렉션) 지금까지 프록시를 통한 원본 코드에 대한 변경 없이 부가 기능을 적용하는 방법에 대해 알아보았다.처음 컨트롤러 - 서비스 - 레포지토리 각 계층 코드의 직접적인 변경을 요구하던 형태에서본 기능의 코드는 부가 기능으로 인하여 더렵혀지지 않는 방법까지 알아보았다.보다 유지보수에 수월한 형태와 방법을 적용한 것이다! 그러나 여전히 로그 추적기라는 부가 기능을 적용하기 위해서 각 계층의 대상 클래스에 모두 프록시 클래스나 인터페이스들을 만들어야하는 작업은 별도로 필요하다. 반복을 줄이기 위한 방법은 없을까?? 이에 대한 방법으로 자바는 기본적으로 JDK 동적 프록시 기술이나 CGLIB 같은 프록시 생성 오픈소스 기술을 활용하여 프록시 객체를 동적으로 만들어낼 수 있도록 제공한다. 그리고 이 JDK 동적 프록시 .. Spring/SpringCore - advance 2026. 1. 26.

• 스프링 핵심원리( 심화 ) - 구체클래스 기반 프록시 앞서 다룬 인터페이스의 기반의 프록시 뿐만 아니라, 구체클래스 기반의 프록시를 적용하는 방법에 대해 학습을 이어간다.상속을 통한 프록시 적용결론부터 말하자면, 인터페이스가 존재하지 않아도 '상속'을 통해 프록시 적용이 가능하다. 코드 예시를 통해 살펴보자. 상속을 통한 프록시 적용 예시 코드 프록시 적용 이전 예시먼저, ConcreteLogic이며, 인터페이스가 존재하지 않는 구체클래스이다.(ex, 서비스 로직)import lombok.extern.slf4j.Slf4j;@Slf4jpublic class ConcreteLogic { public String operation() { log.info("ConcreteLogic 실행"); return "data"; }} 그리고 이를 사용하는.. Spring/SpringCore - advance 2026. 1. 14.

• 스프링 핵심원리( 심화 ) - 인터페이스 기반 프록시 앞서, 프록시의 역할과 기능 및 사용법에 대해서 알아보았다. 이제, 앞서 만들었던 v1(인터페이스가 있는 구현 클래스)에 프록시를 적용하여 LogTrace 기능을 활용하는 방법에 대해서 알아보자.즉, 프록시를 적용하여 기존 코드를 전혀 수정하지 않으면서 로그 추적 기능을 도입하는 방법에 대해서 구체적으로 파악해보자는 것이다. V1 App 의존관계 v1 App의 기본 의존 관계(클래스 의존)와 런타임시 객체 인스턴스의 의존 관계는 아래의 그림과 같다. V1 App 기존 의존관계 V1 기본 클래스 의존관계 V2 런타임 객체 의존 관계 여기에 로그 추적 기능을 담당하는 프록시를 추가하면 다음과 같은 형태를 지닌다. V1 App 프록시 도입 클래스 의존관계V1 프록시 도입 기본 클래스 의존관계 V1 프록시.. Spring/SpringCore - advance 2025. 11. 7.

• 

  스프링 핵심원리( 심화 ) - 프록시 패턴과 데코레이터 패턴(2) 앞서, 추가되었던 요구사항과 함께 지금까지 만들어 온 로그 추적기에 대한 내용 역시 정리해보자. 기존 요구사항→ 모든 Public 메서드의 호출과 응답 정보를 로그로 출력 → 애플리케이션의 흐름을 변경하면 안됨 - 로그를 남긴다고 해서 비즈니스 로직의 동작에 영향을 주면 안됨→ 메서드 호출에 걸린 시간 → 정상 흐름과 예외 흐름 구분 - 예외 발생 시 예외 정보가 남아야 함→ 메서드 호출의 깊이 표현 → HTTP 요청을 구분 - HTTP 요청 단위로 특정 ID를 남겨 어떤 HTTP 요청에서 비롯된 것인지 명확하게 구분할 수 있도록 한다. - 트랜잭션ID (DB 트랜잭션 ❎) 예시 하지만, 지금까지 개발한 로그 추적기는 위의 요구사항을 만족하기 위해서 기존 코드를 많이 수정해야 하는 상황이다. .. Spring/SpringCore - advance 2025. 8. 23.

• 스프링 핵심원리( 심화 ) - 프록시 패턴과 데코레이터 패턴(1) 이번에는 스프링을 이루는 핵심 디자인 패턴의 일부로 프록시 패턴에 대해서 알아보자. 앞서 다뤘던, 템플릿 콜백 패턴을 비롯하여 공통 로직을 최대한 애플리케이션의 전반적으로 걸쳐 재사용할 수 있도록 하는 방법에 대해서 알아봤었다. 그러나, 여전히 로그 기능 추가로 인한 코드의 수정이 불가피하였다. 그리고 이는 개발자에게 가장 큰 문제로 남게 된다. 따라서 원본 코드의 수정을 필요로하지 않으며, 로그 추적기를 적용할 수 있는 방법에 대해 알아보기 위한 방법을 목표로 내용을 정리해보겠다. 기존 코드의 작동에서 아래와 같은 요구사항이 추가되었다. 요구사항 추가 - 원본 코드 수정없이 로그 추적기를 적용하라. - 특정 메소드는 로그를 출력하지 않도록 하라. → 보안상 일부는 로그를 출력하지 않는 기능 - 다.. Spring/SpringCore - advance 2025. 8. 10.