[Spring 핵심원리 - 고급] 프록시 및 데코레이터 패턴(디자인 패턴)

이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.

---

프록시

프록시 개념

클라이언트와 서버 개념에서 일반적으로 클라이언트가 서버를 직접 호출하고, 처리 결과를 직접 받는다. 이것을 직접 호출이라 한다.

 

그런데 클라이언트가 요청한 결과를 서버에 직접 요청하는 것이 아니라 어떤 대리자를 통해서 대신 간접적으로 서버에 요청할 수 있다.

예를 들어서 내가 직접 마트에서 장을 볼 수도 있지만, 누군가에게 대신 장을 봐달라고 부탁할 수도 있다.

여기서 대신 장을 보는 대리자를 영어로 프록시(Proxy)라 한다.

 

객체에서 프록시가 되려면, 클라이언트는 서버에게 요청을 한 것인지, 프록시에게 요청을 한 것인지 조차 몰라야 한다.

쉽게 이야기해서 서버와 프록시는 같은 인터페이스를 사용해야 한다. 그리고 클라이언트가 사용하는 서버 객체를 프록시 객체로 변경해도 클라이언트 코드를 변경하지 않고 동작할 수 있어야 한다.

 

프록시의 주요 기능

프록시를 통해서 할 수 있는 일은 크게 2가지로 구분할 수 있다.

접근 제어

• 권한에 따른 접근 차단
• 캐싱
• 지연 로딩

접근 제어 / 캐싱
마케팅 부서 직원이 임원에게 결재 요청을 하려고 했는데, 비서(프록시)가 말한다:
“이건 지난달에 이미 결재된 내용이에요. 다시 올릴 필요 없어요.”
→ 클라이언트가 직접 접근하지 않고, 중간에서 요청을 걸러주는 구조
→ 중복 요청 방지, 캐싱, 권한 체크 등의 역할을 프록시가 수행

 

부가 기능 추가

• 원래 서버가 제공하는 기능에 더해서 부가 기능을 수행한다.
• 예) 요청 값이나, 응답 값을 중간에 변형한다.
• 예) 실행 시간을 측정해서 추가 로그를 남긴다.

부가 기능 추가
개발팀 팀장이 회의실 예약 요청을 비서에게 했는데, 비서(프록시)가 말한다:
“회의실 예약하면서 음료도 같이 주문해뒀어요.”
→ 클라이언트는 회의실 예약만 요청했지만,
→ 프록시가 추가 작업(부가 기능)을 함께 처리
→ 로깅, 모니터링, 트랜잭션 처리 등 부가기능을 프록시에서 수행할 수 있음

프록시 객체가 중간에 있으면 크게 접근 제어와 부가 기능 추가를 수행할 수 있다.

추가적으로 프록시는 체인 패턴을 가질 수 있다.

 

프록시 체인

• 프록시(대리자)는 또 다른 프록시를 사용할 수 있다.
• 이를 프록시 체인이라고 한다.

프록시 체인
담당자가 결재 요청을 주 비서에게 전달했는데, 주 비서가 바빠서 대리 비서에게 다시 요청을 넘겼고, 대리 비서가 최종적으로 임원에게 결재를 요청함
→ 클라이언트는 첫 비서에게만 요청했을 뿐,
→ 그 이후 어떤 경로로 처리되었는지 알지 못함
→ 프록시끼리 이어지는 구조 = 프록시 체인

 

GOF 디자인 패턴

둘다 프록시를 사용하는 방법이지만 GOF 디자인 패턴에서는 이 둘을 의도(intent)에 따라서 프록시 패턴과 데코레이터 패턴으로 구분한다.

• 프록시 패턴: 접근 제어가 목적
• 데코레이터 패턴: 새로운 기능 추가가 목적

둘다 프록시를 사용하지만, 의도가 다르다는 점이 핵심이다. 용어가 프록시 패턴이라고 해서 이 패턴만 프록시를 사용하는 것은 아니다.

데코레이터 패턴도 프록시를 사용한다.

 

프록시 패턴과 데코레이터 패턴

스프링 컨테이너와 스프링 빈

프록시 패턴과 데코레이터 패턴 모두 프록시를 스프링 빈으로 등록하고, 실제 객체는 스프링 빈으로 등록하면 안된다.

• 스프링 빈으로 실제 객체 대신에 프록시 객체를 등록했기 때문에 앞으로 스프링 빈을 주입 받으면 실제 객체 대신
  에 프록시 객체가 주입된다.
• 실제 객체가 스프링 빈으로 등록되지 않는다고 해서 사라지는 것은 아니다. 프록시 객체가 실제 객체를 참조하기
  때문에 프록시를 통해서 실제 객체를 호출할 수 있다. 쉽게 이야기해서 프록시 객체 안에 실제 객체가 있는 것이
  다.

 

인터페이스 기반

프록시 패턴

 

public interface Subject {
    String operation();
}

 

@Slf4j
public class CacheProxy implements Subject {

    private Subject target;
    private String cacheValue;

    public CacheProxy(Subject target) {
        this.target = target;
    }

    @Override
    public String operation() {
        log.info("프록시 호출");
        if (cacheValue == null) {
            cacheValue = target.operation();
        }
        return cacheValue;
    }
}

• private Subject target : 클라이언트가 프록시를 호출하면 프록시가 최종적으로 실제 객체를 호출해야한다. 따라서 내부에 실제 객체의 참조를 가지고 있어야 한다. 이렇게 프록시가 호출하는 대상을 target 이라 한다.
• operation() : 구현한 코드를 보면 cacheValue 에 값이 없으면 실제 객체(target)를 호출해서 값을 구한다. 그리고 구한 값을 cacheValue 에 저장하고 반환한다. 만약 cacheValue 에 값이 있으면 실제 객체를 전혀 호출하지 않고, 캐시 값을 그대로 반환한다. 따라서 처음 조회 이후에는 캐시(cacheValue )에서 매우 빠르게 데이터를 조회할 수 있다.

 

@Slf4j
public class RealSubject implements Subject {
    @Override
    public String operation() {
        log.info("실제 객체 호출");
        sleep(1000);
        return "data";
    }

    private void sleep(int millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

• operation() 은 데이터 조회를 시뮬레이션 하기 위해 1초쉬도록 했다.
• 예를 들어서 데이터를 DB나 외부에서 조회하는데 1초가 걸린다고 생각하면 된다. 호출할 때 마다 시스템에 큰 부하를 주는 데이터 조회라고 가정.

 

public class ProxyPatternClient {

    private Subject subject;

    public ProxyPatternClient(Subject subject) {
        this.subject = subject;
    }

    public void execute() {
        subject.operation();
    }
}

• Subject 인터페이스에 의존하고, Subject 를 호출하는 클라이언트 코드이다.
• execute() 를 실행하면 subject.operation() 를 호출한다.

 

public class ProxyPatternTest {

    @Test
    void cacheProxyTest() {
        RealSubject realSubject = new RealSubject();
        CacheProxy cacheProxy = new CacheProxy(realSubject);
        ProxyPatternClient client = new ProxyPatternClient(cacheProxy);
        client.execute();
        client.execute();
        client.execute();
    }
}

realSubject와 cacheProxy를 생성하고 둘을 연결한다. 결과적으로 cacheProxy가 realSubject를 참조하는 런타임 객체 의존관계가 완성된다. 그리고 마지막으로 client에 realSubject가 아닌 cacheProxy를 주입한다.

 

이 과정을 통해서 client → cacheProxy → realSubject 구조의 런타임 객체 의존관계가 완성된다.

 

cacheProxyTest()는 client.execute()를 총 3번 호출한다.이번에는 클라이언트가 실제 realSubject를 호출하는 것이 아니라, cacheProxy를 호출하게 된다.

캐시 프록시 도입 이후에는 최초에 한번만 1초가 걸리고, 이후에는 거의 즉시 반환한다.

 

정리
프록시 패턴의 핵심은 RealSubject 코드와 클라이언트 코드를 전혀 변경하지 않고, 프록시를 도입해서 접근 제어를 했다는 점이다.
그리고 클라이언트 코드의 변경 없이 자유롭게 프록시를 넣고 뺄 수 있다. 실제 클라이언트 입장에서는 프록시 객체가 주입되었는지, 실제 객체가 주입되었는지 알지 못한다.

 

데코레이터 패턴

부가 기능 추가

이번에는 프록시를 활용해서 부가 기능을 추가해보자. 이렇게 프록시로 부가 기능을 추가하는 것을 데코레이터 패턴이라 한다.

 

데코레이터 패턴: 원래 서버가 제공하는 기능에 더해서 부가 기능을 수행한다.

• 예) 요청 값이나, 응답 값을 중간에 변형한다.
• 예) 실행 시간을 측정해서 추가 로그를 남긴다.

 

public interface Component {
    String operation();
}

 

@Slf4j
public class TimeDecorator implements Component {

    private Component component;

    public TimeDecorator(Component component) {
        this.component = component;
    }

    @Override
    public String operation() {
        log.info("TimeDecorator 실행");
        long startTime = System.currentTimeMillis();

        String result = component.operation();

        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("TimeDecorator 종료 resultTime={}ms", resultTime);
        return result;
    }
}

• TimeDecorator 는 실행 시간을 측정하는 부가 기능을 제공한다.
• 대상을 호출하기 전에 시간을 가지고 있다가, 대상의 호출이 끝나면 호출 시간을 로그로 남겨준다.

 

@Slf4j
public class MessageDecorator implements Component {

    private Component component;

    public MessageDecorator(Component component) {
        this.component = component;
    }

    @Override
    public String operation() {
        log.info("MessageDecorator 실행");

        //data -> *****data*****
        String result = component.operation();
        String decoResult = "*****" + result + "*****";
        log.info("MessageDecorator 꾸미기 적용 전={}, 적용 후={}", result, decoResult);
        return decoResult;
    }
}

• MessageDecorator 는 Component 인터페이스를 구현한다.
• 프록시가 호출해야 하는 대상을 component 에 저장한다.
• operation() 을 호출하면 프록시와 연결된 대상을 호출(component.operation()) 하고, 그 응답 값에 ***** 을 더해서 꾸며준 다음 반환한다.

예를 들어서 응답 값이 data 라면 다음과 같다.

• 꾸미기 전: data
• 꾸민 후 : *****data*****

 

@Slf4j
public class RealComponent implements Component {
    @Override
    public String operation() {
        log.info("RealComponent 실행");
        return "data";
    }
}

• RealComponent 는 Component 인터페이스를 구현한다.
• operation() : 단순히 로그를 남기고 "data" 문자를 반환한다.

 

@Slf4j
public class DecoratorPatternClient {

    private Component component;

    public DecoratorPatternClient(Component component) {
        this.component = component;
    }

    public void execute() {
        String result = component.operation();
        log.info("result={}", result);
    }
}

• 클라이언트 코드는 단순히 Component 인터페이스를 의존한다.
• execute() 를 실행하면 component.operation() 을 호출하고, 그 결과를 출력한다.

 

@Slf4j
public class DecoratorPatternTest {

    @Test
    void decorator2() {
        Component realComponent = new RealComponent();
        Component messageDecorator = new MessageDecorator(realComponent);
        Component timeDecorator = new TimeDecorator(messageDecorator);
        DecoratorPatternClient client = new DecoratorPatternClient(timeDecorator);
        client.execute();
    }
}

client -> timeDecorator -> messageDecorator -> realComponent 의 객체 의존관계를 설정하고, 실행한다.

 

실행 결과를 보면 TimeDecorator 가 MessageDecorator 를 실행하고 실행 시간을 측정해서 출력한 것을 확인할 수 있다.

 

인터페이스 기반 프록시 정리

• 생각해보면 Decorator 기능에는 일부 중복이 있다.
• 꾸며주는 역할을 하는 Decorator들은 스스로 존재할 수 없고, 항상 꾸며줄 대상이 있어야 한다.
• 따라서 내부에 호출 대상인 component를 가지고 있어야 하며, component를 항상 호출해야 한다. 이 부분이 중복이다.
• 이런 중복을 제거하기 위해 component를 속성으로 가지고 있는 Decorator라는 추상 클래스를 만드는 방법도 고민할 수 있다.

 

이렇게 하면 클래스 다이어그램에서 어떤 것이 실제 컴포넌트인지, 어떤 것이 데코레이터인지 명확하게 구분할 수 있게 된다.

 

디자인 패턴에서 중요한 것은 해당 패턴의 겉모양이 아니라 그 패턴을 만든 의도가 더 중요하다. 따라서 의도에 따라 패턴을 구분한다.

• 프록시 패턴의 의도: 다른 개체에 대한 접근을 제어하기 위해 대리자를 제공
• 데코레이터 패턴의 의도: 객체에 추가 책임(기능)을 동적으로 추가하고, 기능 확장을 위한 유연한 대안 제공

 

클래스 기반 프록시

• 자바의 다형성은 인터페이스를 구현하든, 아니면 클래스를 상속하든 상위 타입만 맞으면 다형성이 적용된다.
• 쉽게 이야기해서 인터페이스가 없어도 프록시를 만들수 있다는 뜻이다. 

 

@Slf4j
public class ConcreteLogic {

    public String operation() {
        log.info("ConcreteLogic 실행");
        return "data";
    }
}

• ConcreteLogic 은 인터페이스가 없고, 구체 클래스만 있다. 여기에 프록시를 도입해야 한다.

 

@Slf4j
public class TimeProxy extends ConcreteLogic {

    private ConcreteLogic concreteLogic;

    public TimeProxy(ConcreteLogic concreteLogic) {
        this.concreteLogic = concreteLogic;
    }

    @Override
    public String operation() {
        log.info("TimeDecorator 실행");
        long startTime = System.currentTimeMillis();

        String result = concreteLogic.operation();

        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("TimeDecorator 종료 resultTime={}ms", resultTime);
        return result;
    }

}

• TimeProxy 프록시는 시간을 측정하는 부가 기능을 제공한다.
• 그리고 인터페이스가 아니라 클래스인 ConcreteLogic 를 상속 받아서 만든다.

 

public class ConcreteClient {

    private ConcreteLogic concreteLogic; //ConcreteLogic, TimeProxy 모두 주입 가능

    public ConcreteClient(ConcreteLogic concreteLogic) {
        this.concreteLogic = concreteLogic;
    }

    public void execute() {
        concreteLogic.operation();
    }
}

 

public class ConcreteProxyTest {

    @Test
    void addProxy() {
        ConcreteLogic concreteLogic = new ConcreteLogic();
        TimeProxy timeProxy = new TimeProxy(concreteLogic);
        ConcreteClient client = new ConcreteClient(timeProxy);
        client.execute();
    }
}

여기서 핵심은 ConcreteClient의 생성자에 concreteLogic이 아니라 timeProxy를 주입하는 부분이다.

ConcreteClient는 ConcreteLogic을 의존하는데, 다형성에 의해 ConcreteLogic에 concreteLogic도 들어갈 수 있고, timeProxy도 들어갈 수 있다.

 

ConcreteLogic에 할당할 수 있는 객체

• ConcreteLogic = concreteLogic (본인과 같은 타입을 할당)
• ConcreteLogic = timeProxy (자식 타입을 할당)

 

인터페이스 기반 프록시 VS 클래스 기반 프록시

인터페이스가 없어도 클래스 기반으로 프록시를 생성할 수 있다.
클래스 기반 프록시는 해당 클래스에만 적용할 수 있다.
인터페이스 기반 프록시는 인터페이스만 같으면 모든 곳에 적용할 수 있다.

클래스 기반 프록시는 상속을 사용하기 때문에 몇가지 제약이 있다.
- 부모 클래스의 생성자를 호출해야 한다.
- 클래스에 final 키워드가 붙으면 상속이 불가능하다.
- 메서드에 final 키워드가 붙으면 해당 메서드를 오버라이딩 할 수 없다.

인터페이스 기반 프록시가 일반적으로 더 좋다.
- 인터페이스 기반의 프록시는 상속이라는 제약에서 자유 롭다.
- 프로그래밍 관점에서도 인터페이스를 사용하는 것이 역할과 구현을 명확하게 나누기 때문에 더 좋다.
- 인터페이스 기반 프록시의 단점은 인터페이스가 필요하다는 그 자체이다.
- 인터페이스가 없으면 인터페이스 기반 프록시를 만들 수 없다.

하지만
인터페이스를 도입하는 것은 구현을 변경할 가능성이 있을 때 효과적인데, 구현을 변경할 가능성이 거의 없는 코드에 무작정 인터페이스를 사용하는 것은 번거롭고 그렇게 실용적이지 않다.
이런곳에는 실용적인 관점에서 인터페이스를 사용 하지 않고 클래스 기반 프록시를 바로 사용하는 것이 좋을 수 있다.