[디자인 패턴] 프록시(Proxy) 패턴

프록시(Proxy)는 영어로 대리자를 뜻한다. 프록시 패턴은 구조 패턴 중 하나로 클라이언트가 직접 서버에 요청하는 것이 아니라 어떤 대리자 객체를 통해 간접적으로 서버에 요청하는 패턴을 말한다. 여기서 클라이언트는 의뢰인을 의미하며 서버는 서비스나 상품을 제공하는 사람 또는 물건을 뜻한다. 즉 웹에서는 클라이언트는 사용자가 접속한 웹 브라우저가 되고, 서버는 클라이언트의 요청을 처리한다. 

 

실행 시 의존 관계

 

 

인터페이스 기반 프록시 상속 관계

구체 클래스 기반 프록시 상속 관계

 

 

 

1. 가상 프록시(Virtual Proxy) - 실제 객체의 크기가 거대해서 생성과 접근에 비용이 많이 드는 경우 필요한 시점에만 객체를 생성하도록 지연된 초기화를 수행할 수 있다.

2. 보호 프록시(Protection Proxy) - 실제 객체에 대한 접근을 통제하여 특정 권한을 가진 사용자(클라이언트)만이 접근하도록 제어할 수 있다.

 

 

서버와 프록시는 같은 객체를 사용해야한다. 클라이언트가 서버에게 요청한 것인지 프록시에 요청한 것인지 몰라야(대체 가능해야만) 프록시 객체라고 할 수 있다. `Client -> Server`에서 `Server -> Proxy`로 의존 관계가 바뀌더라도, 클라이언트는 그 코드를 전혀 변경하지 않아도 된다. 심지어 변경 사실조차 모를 수 있다. 클라이언트는 서버 인터페이스만을 의존하고 있으며 서버와 프록시가 서버 인터페이스에 의존한다. 이 내용이 DI(Dependency Injection: 의존성 주입)의 핵심이다.

 

 

 

 

📌 접근 제어를 위해 프록시를 사용한 예시

클라이언트가 요청 시 유저 유형 정보를 제공하고 이 유형은 String 값으로 "user" 또는 "admin"으로 주어진다고 가정했을 때, "user"라면 DB 접근을 제한하고 "admin"이라면 DB 접근을 허용하는 요구사항이 있다면 코드는 다음과 같이 작성될 수 있다.

 

public class ClientExample {
    public static void main(String[] args) {
        // 클라이언트로부터 받은 정보에 따라 유저 유형 설정
        // 여기서는 그냥 "admin"으로 선언했지만, 웹이라면 request.getParameter("level") 등으로 받아올 수 있음
        String username = "admin"; // 또는 "user"

        // 팩토리를 통해 적절한 프록시 생성
        UserServiceProxyFactory proxyFactory;
        if ("admin".equals(username)) {
            proxyFactory = new AdminUserServiceProxyFactory();
        } else {
            // "user"인 경우 DB 접근이 불가능한 프록시 생성
            proxyFactory = new RegularUserServiceProxyFactory();
        }

        // 생성된 프록시로 UserController를 생성
        UserController userController = new UserController(proxyFactory.createServiceProxy());

        // 클라이언트 요청 처리
        userController.handleRequest();
    }
}

 

 

추상 팩토리 패턴, 그리고 팩토리 메서드 패턴 또한 적용되어 있는 것을 볼 수 있다.

각 객체의 상속 계층도는 다음과 같다.

 

 

추상 팩토리 패턴과 팩토리 메서드 패턴 또한 적용된 것을 확인할 수 있다.`UserServiceProxy`는 내부에 `UserServiceImpl`을 가지고 있으며 필요할 때마다 실제 객체에 접근한다. 데코레이터 패턴과 유사하지만 접근 제어를 목적으로 프록시를 사용한다는 점에서 구분될 수 있다. 

 

 

 

 

 

 

📌  캐싱

한 번의 조회 이후에 변하지 않는 데이터의 경우, 처음 조회했을 때 그 데이터를 보관해두었다가 재요청 시 보관된 데이터를 사용한다면 불필요한 자원 낭비를 감소시킬 수 있다. 이를 캐싱이라고 한다. 

 

 

import java.util.HashMap;
import java.util.Map;

// 실제 객체의 인터페이스
interface Component {
    String operation();
}

// 실제 객체
class RealComponent implements Component {
    public String operation() {
        System.out.println("실제 객체가 메서드 실행");
        return "result";
    }
}

 

// 프록시
class CachingProxy implements Component {
    private RealComponent realComponent;
    private Map<String, String> cache;

    public CachingProxy() {
        this.cache = new HashMap<>();
    }

    public String operation() {
        if (realComponent == null) {
            realComponent = new RealComponent();
        }
        
        // if 캐시 확인하고 데이터가 있으면 캐시에 저장해두었던 데이터 반환
        // else 캐시에 데이터가 없으면 실제 객체 호출
        if (cache.containsKey("result") {
            System.out.println("프록시가 캐싱 데이터 반환");
            return cache.get("result");
        } else {
            // 실제 객체 호출
            String result = realComponent.operation();
            // 결과를 캐시에 저장
            cache.put("result", result);
            return result;
        }
    }
}

 

// 클라이언트 코드
public class Client {
    public static void main(String[] args) {
        // 클라이언트 코드는 프록시를 통해 실제 객체에 간접적으로 접근
        CachingProxy proxy = new CachingProxy();

        System.out.println(proxy.operation()); // 처음 호출시 실제 객체에서 연산 수행
        System.out.println(proxy.operation()); // 두 번째 호출부터는 프록시에서 캐시 데이터 반환
    }
}

// 출력

// 실제 객체가 메서드 실행
// result
// 프록시가 캐싱 데이터 반환
// result

 

 

클라이언트가 처음 요청했을 때만 실제 객체에 접근하고, 그 이후로는 캐시에 저장된 데이터를 사용한다. 실행 시간을 크게 줄여 성능 향상에 도움이 된다.

 

캐싱을 사용할 때는 반드시 다음의 주의점을 고려한다. 

1. 캐싱 데이터는 항상 실제 데이터와 일치해야 한다. 데이터가 갱신된다면 캐싱 데이터 또한 갱신되어야 한다. 실제 데이터와 캐싱 데이터의 일관성이 유지되지 않으면 신뢰성이 깨질 수 있다. 이를 방지하기 위해 적절한 캐싱 만료 기간을 설정한다.

2. 캐싱 데이터는 메모리를 사용하므로 주의한다. 너무 많은 캐싱 데이터를 사용한다면 오히려 성능 저하를 일으킬 수 있다.

3. 멀티 쓰레드 환경에서 동기화 문제가 발생할 수 있으므로 주의한다.

4. 캐싱 데이터의 보안에 주의한다.

 

 

 

 

 

 

📌  Spring MVC 내 프록시 패턴 적용

실행 시 의존 관계

 

 

MVC 패턴에서`Service`의 구현체가 `Repository`의 구현체를 직접 참조하는 대신 `ServiceImpl`을 참조하는  `ServiceProxy`가 `RepositoryImpl`을 참조하는 `RepositoryProxy`를 호출하도록 설계한다면 Service 계층이 데이터 접근 계층과 완전히 분리되므로 둘은 느슨하게 결합될 수 있다. 데이터 접근 계층이 변경됐을 때 (새로운 데이터 소스나 DB 접근 방식이 도입되더라도) 실제 객체인 `RepositoryImpl`을 참조하는 `RepositoryProxy`의 코드만 변경하면 된다. 이는 객체 지향 5대 원칙 중 하나인 OCP(개방 폐쇄 원칙: Open-closed Principle)에 부합한다. 

 

 

1. 프록시와 실제 객체는 하나의 인터페이스를 구현한다.

   1-1. 실제 객체의 인터페이스가 존재하지 않을 경우 프록시 객체가 실제 객체를 상속한다. 클라이언트 생성자의 매개 변수 타입이 실제 객체라면 다형성의 적용을 받아 참조하는 객체가 실제 객체 또는 프록시 객체로 변경되더라도 클라이언트의 코드를 수정할 필요가 없다. 단, 인터페이스 기반의 프록시가 상속의 제약이 없기 때문에 더 유리할 수 있다.

2. 프록시는 내부에 실제 객체를 가지고 있다.

3. 실제 객체 대신 프록시 객체를 스프링 빈으로 등록하는 경우 스프링 컨테이너에는 프록시 객체만 등록된다. 프록시 객체가 내부에서 실제 객체를 참조하고 있다. 

프록시 객체: 스프링 컨테이너, JVM Heap 메모리에 올라감

실제 객체: JVM Heap 메모리에만 올라감(스프링 컨테이너가 관리하지 않는다.)

 

 

 

📌 프록시 패턴 vs 데코레이터 패턴

프록시 패턴과 데코레이터 패턴은 매우 유사하다. 둘은 프록시의 생성 목적으로 구분될 수 있다. 프록시 패턴은 접근 제어가 목적이며 데코레이터 패턴은 새로운 기능의 추가가 목적이다. 프록시 패턴과 데코레이터 패턴 둘 다 프록시, 즉 대리자를 사용하지만 의도가 다르다는 것이 중요하다. 프록시 패턴은 프록시를 사용하는 디자인 패턴 중 하나로 이름이 프록시 패턴일 뿐 반드시 프록시 패턴만이 프록시를 사용하는 것은 아니다. 

 

프록시 패턴: 접근 제어

데코레이터 패턴: 부가 기능 추가

 

 

✨ 장점

1. 실제 객체가 거대한 경우 필요한 시점에만 객체를 생성하기 때문에 비용을 아낄 수 있다. = 지연된 초기화(Lazy initialization)

2. 프록시 객체에서 캐싱을 사용할 경우 요청마다 거대한 객체에 접근하지 않고도 데이터를 반환할 수 있어 빠른 응답이 가능하다.

3. 클라이언트 코드를 크게 변경하지 않고 접근 제어 요구 사항을 반영할 수 있다. 

 

 

👎 단점

1. 프록시 객체의 추가로 클래스의 양이 늘어나면 코드가 복잡해질 수 있다.

2. 프록시 객체가 추가적인 작업을 수행하기 때문에 성능 저하가 발생할 수 있다.

3. 지연된 초기화의 장점은 곧 실제 객체의 생성 시점이 불명확해진다는 단점을 의미한다. 어떤 경우에는 초기화 시점이 분명해야 하는 상황이 존재하므로 잘 고려하여 패턴을 적용해야한다. 

 

 

[디자인 패턴] 데코레이터(Decorator) 패턴