프록시 패턴과 복합 패턴

진짜 객체 대신 대리인을 세워 접근을 제어하고, 여러 패턴을 조합해서 더 큰 문제를 풀어보자.

뽑기 기계 모니터링 시스템을 만들어야 하는데, 뽑기 기계가 다른 JVM, 다른 컴퓨터에 있어. **원격 프록시(Remote Proxy)**는 네트워크 너머의 객체를 로컬에서 쓰는 것처럼 만들어주는 대리인이야. Java RMI가 자동으로 스텁을 생성해서 네트워크 통신을 처리하고, 클라이언트는 machine.getCount()를 호출할 뿐 그게 네트워크를 건너간다는 사실을 몰라. 한편 **가상 프록시(Virtual Proxy)**는 생성 비용이 큰 객체의 대리인이야. CD 커버 이미지를 인터넷에서 가져올 때, ImageProxy가 처음에는 "로딩 중"을 보여주다가 로딩이 끝나면 실제 ImageIcon에 위임하는 식이지. 실제 객체가 필요해질 때까지 생성을 미루는 거야.

**보호 프록시(Protection Proxy)**는 접근 권한에 따라 메소드 호출을 허용하거나 거부해. 데이트 서비스에서 자기 프로필은 수정할 수 있지만 다른 사람 건 안 되고, 평점은 자기한테 못 매기는 — 이런 권한 로직을 Java의 동적 프록시와 InvocationHandler로 메소드 호출을 가로채서 구현하는 거야. 이 세 가지가 전부 프록시 패턴(Proxy Pattern) — 특정 객체로의 접근을 제어하는 대리인 — 의 변형이야. 데코레이터와 구조가 비슷해 보이지만, 데코레이터는 행동을 추가하고 프록시는 접근을 제어한다는 점에서 목적이 다르거든.

프록시처럼 개별 패턴도 강력하지만, 현실의 복잡한 문제는 여러 패턴의 조합으로 풀어야 할 때가 많아. 1장의 SimUduck으로 돌아가서, 이번엔 패턴을 하나씩 쌓아올려봐. 거위를 오리처럼 쓰려면 어댑터, 꽥꽥 횟수를 세려면 데코레이터, 데코레이터 감싸는 걸 빼먹지 않으려면 추상 팩토리, 오리떼를 한꺼번에 관리하려면 컴포지트, 개별 오리를 실시간으로 관찰하려면 옵저버. 한 예제에 다섯 가지 패턴이 자연스럽게 녹아드는데, 핵심은 억지로 끼워 넣은 게 아니라 문제가 있을 때 적절한 패턴으로 해결한 거라는 점이야. 이런 식으로 반복적인 문제를 여러 패턴의 조합으로 해결하는 게 **복합 패턴(Compound Pattern)**이야.

가장 유명한 복합 패턴은 **MVC(Model-View-Controller)**야. Model이 Subject, View가 Observer인 옵저버 패턴으로 상태 변화를 알리고, Controller가 View에 대한 Strategy인 전략 패턴으로 교체 가능하고, View 내부의 UI 요소는 컴포지트 패턴으로 트리 구조를 이뤄. BPM 제어 도구를 MVC로 만들면, DJ용 Controller 대신 HeartBeat Controller를 끼우는 것만으로 같은 View가 심장 박동 모니터링 앱이 돼 — View 코드 한 줄 안 바꾸고. 결국 MVC의 진짜 가치는 관심사의 분리야. Model은 비즈니스 로직만, View는 표시만, Controller는 입력 처리만. 각자 역할에 집중하니까 한 부분을 바꿔도 나머지에 영향이 적어.

---

정리

5장 읽고 기억할 거 세 가지:

1. 프록시 패턴은 접근을 제어하는 대리인이야 — 원격(네트워크), 가상(지연 생성), 보호(접근 권한) 등 목적에 따라 변형이 다양하고, 데코레이터와는 의도가 달라.
2. 복합 패턴은 여러 패턴의 자연스러운 조합이야 — 문제가 있을 때 적절한 패턴으로 해결하다 보면 여러 패턴이 함께 동작하게 돼.
3. MVC = 옵저버 + 전략 + 컴포지트 — 관심사를 분리해서 Controller 교체만으로 완전히 다른 앱을 만들 수 있어.