
클라이언트 : 의뢰인
서버 : 서비스나 상품을 제공하는 사람이나 물건
클라이언트는 서버에 필요한 것을 요청하고,
서버는 클라이언트의 요청을 처리하는 것이다.
이 개념을 우리가 익숙한 컴퓨터 네트워크에 도입하면
- 클라이언트: 웹 브라우저
- 요청을 처리하는 서버: 웹 서버
이 개념을 객체에 도입하면,
- 클라이언트: 요청하는 객체
- 서버: 요청을 처리하는 객체
직접 호출과 간접 호출
클라이언트와 서버 개념에서 일반적으로 클라이언트가 서버를 직접 호출하고, 처리 결과를 직접 받는다. 이것을 직접 호출이라 한다.

그런데 클라이언트가 요청한 결과를 서버에 직접 요청하는 것이 아니라 어떤 대리자를 통해서 대신 간접적으로 서버에 요청할 수 있다.
예를 들어서 내가 직접 마트에서 장을 볼 수도 있지만, 누군가에게 대신 장을 봐달라고 부탁할 수도 있다. 여기서 대신 장을 보는 대리자를 영어로 프록시(Proxy)라 한다.

간접 호출을 하면 대리자가 중간에서 여러가지 일을 할 수 있다.
- 엄마에게 라면을 사달라고 부탁 했는데, 엄마는 그 라면은 이미 집에 있다고 할 수도 있다. 그러면 기대한 것 보다 더 빨리 라면을 먹을 수 있다. (접근 제어, 캐싱)
- 아버지께 자동차 주유를 부탁했는데, 아버지가 주유 뿐만 아니라 세차까지 하고 왔다. 클라이언트가 기대한 것 외에 세차라는 부가 기능까지 얻게 되었다. (부가 기능 추가)
- 그리고 대리자가 또 다른 대리자를 부를 수도 있다. 예를 들어서 내가 동생에게 라면을 사달라고 했는데, 동생은 또 다른 누군가에게 라면을 사달라고 다시 요청할 수도 있다. 중요한 점은 클라이언트는 대리자를 통해서 요청했기 때문에 그 이후 과정은 모른다는 점이다. 동생을 통해서 라면이 나에게 도착하기만 하면 된다. (프록시 체인)

실제 프록시의 기능도 이와 같다. 객체에서 프록시의 역할을 알아보자.
클라이언트는 실제 서버가 동작하는지, 아니면 프록시가 동작하는지 알 필요가 없다. 쉽게 이야기해서 서버와 프록시는 같은 인터페이스를 구현해야 한다.
그리고 클라이언트가 사용하는 서버 객체를 프록시 객체로 변경해도 클라이언트 코드를 변경하지 않고 동작할 수 있어야 한다.

클래스 의존관계를 보면 클라이언트는 서버 인터페이스(ServerInterface)에만 의존한다. 그리고 서버와 프록시가 같은 인터페이스를 구현한다. 따라서 DI(Dependency Injection)를 사용해서 대체 가능하다.
참고 ) 코드 예시
public interface ServerInterface {
String getData();
}
@Service
public class Server implements ServerInterface {
@Override
public String getData() {
return "Data from Server";
}
}
@Component
public class Proxy implements ServerInterface {
private ServerInterface server;
@Autowired
public Proxy(ServerInterface server) {
this.server = server;
}
@Override
public String getData() {
return "Proxy: " + server.getData();
}
}
@Component
public class Client {
private ServerInterface server;
@Autowired
public Client(ServerInterface server) {
this.server = server;
}
public void displayData() {
System.out.println(server.getData());
}
}
이번에는 런타임 객체 의존 관계를 살펴보자.

프록시 도입 전에는 클라이언트 인스턴스가 서버 인스턴스를 의존

프록시 도입 후에는 client는 proxy를 참조하고 proxy는 server를 참조
런타임(애플리케이션 실행 시점)에 클라이언트 객체에 DI를 사용해서 Client -> Server에서 Client -> Proxy로 객체 의존관계를 변경해도 클라이언트 코드를 전혀 변경하지 않아도 된다. 클라이언트 입장에서는 변경 사실조차 모른다. DI를 사용하면 클라이언트 코드의 변경 없이 유연하게 프록시를 주입할 수 있다.
프록시의 주요 기능
프록시를 통해서 할 수 있는 일은 크게 2가지
- 접근 제어
- 부가 기능 추가
프록시 객체가 중간에 있으면 크게 접근 제어와 부가 기능 추가를 수행 가능
GOF 디자인 패턴
둘다 프록시를 사용하는 방법이지만 GOF 디자인 패턴에서는 이 둘을 의도(intent)에 따라서 프록시 패턴과 데코레이터 패턴으로 구분한다.
- 프록시 패턴: 접근 제어가 목적
- 데코레이터 패턴: 부가 기능 추가가 목적
둘다 프록시를 사용하지만, 의도가 다르다는 점이 핵심이다.
용어가 프록시 패턴이라고 해서 이 패턴만 프록시를 사용하는 것은 아니다.
데코레이터 패턴도 프록시를 사용한다. 이왕 프록시를 학습하기로 했으니 GOF 디자인 패턴에서 설명하는 프록시 패턴과 데코레이터 패턴을 나누어 학습해보자
'Spring, JPA 🌱 > 김영한 스프링 고급편' 카테고리의 다른 글
[김영한 스프링 고급/AOP] 데코레이터 패턴 (0) | 2025.02.07 |
---|---|
[김영한 스프링 고급/AOP] 프록시 패턴 (0) | 2025.02.07 |

클라이언트 : 의뢰인
서버 : 서비스나 상품을 제공하는 사람이나 물건
클라이언트는 서버에 필요한 것을 요청하고,
서버는 클라이언트의 요청을 처리하는 것이다.
이 개념을 우리가 익숙한 컴퓨터 네트워크에 도입하면
- 클라이언트: 웹 브라우저
- 요청을 처리하는 서버: 웹 서버
이 개념을 객체에 도입하면,
- 클라이언트: 요청하는 객체
- 서버: 요청을 처리하는 객체
직접 호출과 간접 호출
클라이언트와 서버 개념에서 일반적으로 클라이언트가 서버를 직접 호출하고, 처리 결과를 직접 받는다. 이것을 직접 호출이라 한다.

그런데 클라이언트가 요청한 결과를 서버에 직접 요청하는 것이 아니라 어떤 대리자를 통해서 대신 간접적으로 서버에 요청할 수 있다.
예를 들어서 내가 직접 마트에서 장을 볼 수도 있지만, 누군가에게 대신 장을 봐달라고 부탁할 수도 있다. 여기서 대신 장을 보는 대리자를 영어로 프록시(Proxy)라 한다.

간접 호출을 하면 대리자가 중간에서 여러가지 일을 할 수 있다.
- 엄마에게 라면을 사달라고 부탁 했는데, 엄마는 그 라면은 이미 집에 있다고 할 수도 있다. 그러면 기대한 것 보다 더 빨리 라면을 먹을 수 있다. (접근 제어, 캐싱)
- 아버지께 자동차 주유를 부탁했는데, 아버지가 주유 뿐만 아니라 세차까지 하고 왔다. 클라이언트가 기대한 것 외에 세차라는 부가 기능까지 얻게 되었다. (부가 기능 추가)
- 그리고 대리자가 또 다른 대리자를 부를 수도 있다. 예를 들어서 내가 동생에게 라면을 사달라고 했는데, 동생은 또 다른 누군가에게 라면을 사달라고 다시 요청할 수도 있다. 중요한 점은 클라이언트는 대리자를 통해서 요청했기 때문에 그 이후 과정은 모른다는 점이다. 동생을 통해서 라면이 나에게 도착하기만 하면 된다. (프록시 체인)

실제 프록시의 기능도 이와 같다. 객체에서 프록시의 역할을 알아보자.
클라이언트는 실제 서버가 동작하는지, 아니면 프록시가 동작하는지 알 필요가 없다. 쉽게 이야기해서 서버와 프록시는 같은 인터페이스를 구현해야 한다.
그리고 클라이언트가 사용하는 서버 객체를 프록시 객체로 변경해도 클라이언트 코드를 변경하지 않고 동작할 수 있어야 한다.

클래스 의존관계를 보면 클라이언트는 서버 인터페이스(ServerInterface)에만 의존한다. 그리고 서버와 프록시가 같은 인터페이스를 구현한다. 따라서 DI(Dependency Injection)를 사용해서 대체 가능하다.
참고 ) 코드 예시
public interface ServerInterface { String getData(); }
@Service public class Server implements ServerInterface { @Override public String getData() { return "Data from Server"; } }
@Component public class Proxy implements ServerInterface { private ServerInterface server; @Autowired public Proxy(ServerInterface server) { this.server = server; } @Override public String getData() { return "Proxy: " + server.getData(); } }
@Component public class Client { private ServerInterface server; @Autowired public Client(ServerInterface server) { this.server = server; } public void displayData() { System.out.println(server.getData()); } }
이번에는 런타임 객체 의존 관계를 살펴보자.

프록시 도입 전에는 클라이언트 인스턴스가 서버 인스턴스를 의존

프록시 도입 후에는 client는 proxy를 참조하고 proxy는 server를 참조
런타임(애플리케이션 실행 시점)에 클라이언트 객체에 DI를 사용해서 Client -> Server에서 Client -> Proxy로 객체 의존관계를 변경해도 클라이언트 코드를 전혀 변경하지 않아도 된다. 클라이언트 입장에서는 변경 사실조차 모른다. DI를 사용하면 클라이언트 코드의 변경 없이 유연하게 프록시를 주입할 수 있다.
프록시의 주요 기능
프록시를 통해서 할 수 있는 일은 크게 2가지
- 접근 제어
- 부가 기능 추가
프록시 객체가 중간에 있으면 크게 접근 제어와 부가 기능 추가를 수행 가능
GOF 디자인 패턴
둘다 프록시를 사용하는 방법이지만 GOF 디자인 패턴에서는 이 둘을 의도(intent)에 따라서 프록시 패턴과 데코레이터 패턴으로 구분한다.
- 프록시 패턴: 접근 제어가 목적
- 데코레이터 패턴: 부가 기능 추가가 목적
둘다 프록시를 사용하지만, 의도가 다르다는 점이 핵심이다.
용어가 프록시 패턴이라고 해서 이 패턴만 프록시를 사용하는 것은 아니다.
데코레이터 패턴도 프록시를 사용한다. 이왕 프록시를 학습하기로 했으니 GOF 디자인 패턴에서 설명하는 프록시 패턴과 데코레이터 패턴을 나누어 학습해보자
'Spring, JPA 🌱 > 김영한 스프링 고급편' 카테고리의 다른 글
[김영한 스프링 고급/AOP] 데코레이터 패턴 (0) | 2025.02.07 |
---|---|
[김영한 스프링 고급/AOP] 프록시 패턴 (0) | 2025.02.07 |