158. 프록시 패턴 (Proxy Pattern)

핵심 인사이트 (3줄 요약)

1. 본질: 프록시 패턴 (Proxy Pattern)은 실제 객체(Real Subject) 앞에 동일한 인터페이스의 대리 객체를 두어, 접근 제어·지연 로딩·원격 호출 캡슐화 같은 부가 책임을 중간에서 처리하게 하는 구조 패턴이다.
2. 가치: 클라이언트는 실제 객체를 직접 다루지 않아도 되므로, 무거운 객체 생성 비용·보안 정책·네트워크 지연 같은 복잡성을 감추면서도 사용 방식은 단순하게 유지할 수 있다.
3. 판단 포인트: 프록시는 기능 확장이 목적이 아니라 접근 중재가 목적이므로, 데코레이터(Decorator)나 어댑터(Adapter)와 혼동하지 말고 "실제 객체 접근을 왜 통제해야 하는가"가 분명할 때 채택해야 한다.

Ⅰ. 개요 및 필요성

프록시 패턴 (Proxy Pattern)은 실제 객체에 대한 접근을 다른 객체가 대신 받는 구조다. 객체 생성 비용이 크거나, 외부 시스템 호출이 느리거나, 권한 통제가 필요하면 클라이언트가 직접 실제 객체를 다루는 순간 코드가 무거워지고 관심사가 섞인다. 프록시는 이 중간에 서서 "언제 실제 객체를 만들지", "누가 접근할 수 있는지", "호출 전후에 무엇을 기록할지"를 통제한다.

이 패턴이 필요한 이유는 객체지향 설계에서 사용 편의성과 운영 제어가 자주 충돌하기 때문이다. 클라이언트는 단순한 인터페이스를 원하지만, 시스템은 인증·캐싱·원격 통신·지연 로딩 같은 현실 문제를 처리해야 한다. 프록시는 인터페이스는 유지하면서도 접근 경로만 바꿔, 클라이언트와 운영 정책을 분리한다.

특히 대용량 이미지 로더, 원격 서비스 호출 stub, 객체 관계 매핑(ORM, Object-Relational Mapping)의 지연 로딩에서 이 패턴의 효과가 뚜렷하다. 실제 객체를 항상 즉시 만들면 메모리와 응답 시간이 낭비되고, 아무 제어 없이 열어 두면 보안과 감사 추적이 어려워진다. 프록시는 이 두 문제를 동시에 다루는 설계 장치다.

• 📢 섹션 요약 비유: 프록시는 회사 대표 대신 먼저 방문객을 맞는 비서와 같다. 방문 목적을 확인하고, 필요한 사람만 연결하고, 아직 준비되지 않았다면 잠시 대기시키며 전체 흐름을 정리한다.

Ⅱ. 아키텍처 및 핵심 원리

프록시 패턴의 핵심은 프록시와 실제 객체가 같은 추상 인터페이스를 구현한다는 점이다. 클라이언트는 인터페이스만 보고 호출하므로, 프록시가 있든 실제 객체가 직접 오든 코드를 바꿀 필요가 없다. 프록시는 요청을 가로채 필요한 검사를 수행한 뒤, 조건이 맞으면 실제 객체에 위임한다.

아래 그림은 프록시가 단순 전달자가 아니라 "접근 정책이 모이는 제어 지점"임을 보여준다.

┌──────────────────────────────────────────────────────────────────┐
│              프록시 패턴의 호출 흐름과 제어 지점                 │
├──────────────────────────────────────────────────────────────────┤
│ Client                                                           │
│   │                                                              │
│   ▼                                                              │
│ Subject Interface                                                │
│   │                                                              │
│   ▼                                                              │
│ Proxy ---------------------------------------------------------┐ │
│   │ 1) 권한 확인                                              │ │
│   │ 2) 캐시/로그 확인                                         │ │
│   │ 3) 필요 시 Real Subject 생성                              │ │
│   ▼                                                            │ │
│ Real Subject                                                   │ │
│   │                                                            │ │
│   └────────────── 실제 업무 처리 결과 반환 ─────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘

이 구조에서 중요한 설계 포인트는 프록시가 실제 객체를 "대체"하는 것이 아니라 "대표"한다는 점이다. 즉 프록시의 책임은 본업을 새로 만드는 것이 아니라, 접근 조건을 조율하고 실제 객체 호출을 관리하는 데 있다.

핵심 원리는 결국 "동일 인터페이스 + 지연 위임"이다. 프록시는 인터페이스 투명성을 유지하면서도 호출 전후에 정책을 삽입할 수 있기 때문에, 객체지향 내부 설계뿐 아니라 리버스 프록시(Reverse Proxy), 응용 프로그래밍 인터페이스(API, Application Programming Interface) 게이트웨이, 서비스 메시 사이드카처럼 시스템 아키텍처 전체로 확장된다.

• 📢 섹션 요약 비유: 프록시는 공연장 입구의 안내 데스크와 같다. 관객은 같은 공연을 보러 오지만, 안내 데스크는 표를 확인하고, 좌석을 안내하고, 필요한 경우 입장을 잠시 지연시키며 전체 질서를 지킨다.

Ⅲ. 비교 및 연결

프록시를 제대로 이해하려면 비슷해 보이는 구조 패턴과의 경계를 분명히 해야 한다. 프록시는 "접근 통제"가 목적이고, 데코레이터는 "행동 추가", 어댑터는 "인터페이스 변환", 퍼사드(Facade)는 "복잡한 서브시스템 단순화"가 목적이다. 겉으로는 모두 중간 객체를 두지만, 채택 이유가 다르다.

프록시는 AOP (Aspect-Oriented Programming, 관점 지향 프로그래밍)와도 연결된다. 스프링의 트랜잭션, 보안, 로깅은 본질적으로 프록시를 이용해 비즈니스 로직 앞뒤에 공통 관심사를 삽입하는 방식이다. 네트워크 레벨에서는 Nginx 리버스 프록시, 클라우드에서는 서비스 메시 사이드카가 같은 발상을 더 큰 범위로 구현한다.

즉 프록시는 단순한 객체지향 시험 문제를 넘어, "직접 처리하지 말고 중간 계층에서 통제하라"는 아키텍처 사고방식을 대표한다. 그래서 설계감리 관점에서는 패턴 이름보다도, 시스템의 제어점(control point)을 어디에 둘 것인지가 더 중요하다.

• 📢 섹션 요약 비유: 프록시는 출입문 앞 경비원이고, 데코레이터는 선물 포장지이며, 어댑터는 콘센트 변환기이고, 퍼사드는 종합 안내 데스크다. 모두 중간에 있지만 맡은 임무가 다르다.

Ⅳ. 실무 적용 및 기술사 판단

프록시는 "중간에 하나 더 두면 편해 보인다"는 이유만으로 쓰면 오히려 복잡도를 키운다. 실제로는 접근 시점과 정책을 통제할 명확한 이유가 있을 때만 효과가 난다. 예를 들어 지연 로딩이 필요한 도메인 객체, 외부 시스템 호출을 감싸는 클라이언트, 권한 검사가 필수인 서비스 진입점은 프록시 채택 타당성이 높다.

실무 적용 포인트

1. 지연 로딩: ORM 연관 객체를 처음부터 전부 읽지 않고, 실제 접근 시점에만 조회한다.
2. 보안 제어: 관리자 화면, 결재 API, 중요 파일 접근 전 권한을 중앙에서 검사한다.
3. 원격 호출 캡슐화: 네트워크 재시도, 타임아웃, 로깅을 프록시 계층에 모아 클라이언트를 단순화한다.
4. 감사 추적: 누가 언제 어떤 자원에 접근했는지 일관된 로깅 포인트를 만든다.

설계 감리 관점의 체크리스트

• 프록시와 실제 객체가 정말 같은 인터페이스를 유지하는가?
• 프록시 내부에 본업 로직이 침투해 단일 책임 원칙(SRP, Single Responsibility Principle)을 해치지 않는가?
• 원격 프록시라면 네트워크 실패와 지연을 호출자에게 적절히 드러내는가?
• 지연 로딩으로 인해 N+1 조회 같은 성능 함정이 생기지 않는가?

안티패턴

• 만능 프록시화: 로깅, 보안, 캐시, 검증, 업무 규칙을 한 프록시에 몰아넣는 경우
• 원격 호출 은폐: 로컬 메서드처럼 보이게 만들어 네트워크 비용과 실패 가능성을 잊게 하는 경우
• 불필요한 래핑: 직접 호출해도 충분한 단순 객체에 억지로 프록시를 두는 경우

기술사 답안에서는 프록시를 "객체 접근의 제어점"으로 설명하고, 적용 사례로 AOP, ORM 지연 로딩, 리버스 프록시를 연결하면 설계 수준의 이해를 보여주기 좋다.

• 📢 섹션 요약 비유: 프록시는 모든 길목에 톨게이트를 세우는 일이 아니라, 통제가 꼭 필요한 진입로에만 게이트를 두는 일이다. 필요한 곳에 두면 질서가 생기지만, 아무 데나 세우면 차만 막힌다.

Ⅴ. 기대효과 및 결론

프록시 패턴을 올바르게 적용하면 클라이언트 코드는 단순해지고, 접근 제어 정책은 중앙화되며, 무거운 객체 생성 시점도 조절할 수 있다. 이는 성능 최적화와 보안 강화, 유지보수성 향상으로 이어진다. 특히 공통 관심사를 한곳에 모을 수 있어, 기능 변경보다 운영 정책 변경이 잦은 시스템에서 효과가 크다.

반면 프록시는 호출 경로를 한 단계 더 늘리기 때문에, 숨겨진 지연과 디버깅 난도를 높일 수 있다. 또한 프록시 내부가 비대해지면 본래 의도였던 단순화가 사라지고, 실제 객체보다 프록시가 더 중요한 복합 객체가 되는 역전 현상도 생긴다. 따라서 프록시는 "기능을 더하는 패턴"이 아니라 "직접 접근을 통제하는 패턴"이라는 초점을 잃지 않아야 한다.

앞으로도 프록시의 중요성은 줄지 않는다. 객체지향 코드 안에서는 동적 프록시와 AOP로, 인프라에서는 API 게이트웨이와 서비스 메시로 계속 확장되고 있기 때문이다. 기억해야 할 핵심은 하나다. 프록시는 실제 일을 대신하는 척하면서, 사실은 시스템의 통제 질서를 세우는 패턴이다.

• 📢 섹션 요약 비유: 프록시는 집 현관문과 같다. 문 자체가 생활을 대신하지는 않지만, 누가 들어오고 나가는지 통제함으로써 집 전체의 안전과 질서를 지켜 준다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

직접 접근의 한계
    │
    ▼
추상 인터페이스 분리
    │
    ▼
프록시 (Proxy) 패턴
    │
    ├─▶ 가상 프록시 (Virtual Proxy)
    ├─▶ 보호 프록시 (Protection Proxy)
    ├─▶ 원격 프록시 (Remote Proxy)
    │
    ▼
AOP · ORM 지연 로딩 · 리버스 프록시 · 서비스 메시

이 흐름은 프록시가 단순 객체 패턴에서 출발해, 애플리케이션 프레임워크와 인프라 제어 계층으로 확장되는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

1. 프록시는 중요한 사람을 바로 만나기 전에 먼저 이야기해 주는 비서 같은 거예요.
2. 비서는 아무나 들여보내지 않고, 준비가 되면 그때 진짜 사람에게 연결해 줘요.
3. 그래서 사람들은 더 안전하고 편하게 일을 맡길 수 있어요.