스프링이 쓰는 Dynamic Proxy는 Proxy 패턴인가 Decorator 패턴인가?

디자인 패턴의 가치는 그것을 사용해서 코드를 만드는데 있지 않고, 만들어진 코드를 설명하는데 있다고 누군가 트위터에서 그랬다. 누구더라.. –_-;

GoF패턴이 어려운 이유는 구조는 거의 동일한데 경우에 따라서 이 패턴일 수도 있고, 저 패턴일 수도 있기 때문이다. 패턴에서 가장 중요한 것은 의도(intent) 또는 목적(purpose)라고 홀럽이 그랬다. 구조가 같지만 의도가 다르면 다른 패턴이다. 그래서 헷갈린다. 때론 같은 패턴도 조금씩 다른 구조를 가지고 있기도 하기 때문이다.

결국 패턴을 구조적으로만 이해하면 남는 건, 클래스 스코프 패턴들은 구현상속을 하고, 오브젝트 스코프 패턴들은 인터페이스 써서 콤포짓으로 만들어라 이것뿐이다. 단 두개의 패턴일 수는 없으니, 당연히 그 안에서 다양한 의도에 따라 구분이 되는 것이다.

따라서 패턴을 구조적인 설계의 도구 내지는 족보로 사용하면 항상 필요 이상으로 오버하기 쉽다. 그런 탓에 수 많은 개발자들이 머리를 쥐어짜서 만들어 써왔고, 그걸 GoF가 열심히 수집하고 정리해서 공개한 나름 소중한 디자인패턴이 맨날 여기 저기서 욕먹는 동네 북이 되는 것이다. 차라리 패턴은 영리한 의도를 가지고 설계한 코드의 의도와 가치를 설명하는데 사용하는 것이 더 나을 것 같다.

 

아무튼  자바의 Dynamic Proxy는 프록시 패턴인지 데코레이터 패턴인지 설명해야 할 상황이 되버렸는데, 순간 헷갈렸다. 이름이 벌써 프록시인데 멀 망설이냐. 음음.. 하지만 스프링의 AOP에 사용한 ProxyFactoryBean은 사실 부가적인 기능을 추가하는 것이 목적이니까.. 데코레이터 같은데 말이다. 늦은 로딩용도 아니고, 웹이나 리모팅 스텁도 아니고, 액세스 보안을 위한 대리인도 아니고 이것을 뭐라고 하나 싶었다. 

내가 살펴보는 스프링의 AOP에서의 사용예를 보자면 ProxyFactoryBean은 그 자체로 자바의 Dynamic Proxy를 사용해서 동작하지만 런타임시에 다이나믹하게 Advice를 Target에 적용시켜주는 것이 목적인 데코레이터 처럼 동작한다. 사전에 target을 결정해두고 그 액세스 과정에 개입하는 것에 관심을 두는 프록시와는 의도가 분명히 다르다. 

스프링에서도 사용하기에 따라서 lazy loading이나 remoting이나 기타 프록시의 전형적인 사용예를 적용한 경우도 있을 수 있다. 그럼에도 ProxyFactoryBean 내부에서 만들어지는 프록시 그 자체가 그런 역할을 하는 것이 아니라, 다이나믹하게 그런 기능을 담당하는 Advice를 바인딩 해서, 타겟의 호출이 일어나게 만드는 것이 사실 DynamicProxy로 만들어지는 프록시의 역할이다. 따라서 Advice는 프록시일 망정, 그 안에서 사용되는 Jav Proxy는 DI해주는 데코레이터라고 우겨볼 수 있을 것 같기도.

 

정리해보면

데코레이터의 의도는 타겟에 추가적인 책임을 더 하는 것이다. 트랜잭션, 보안, 트레이싱 등은 사실 타겟 빈들이 가지고 있어야 할 부가적인 책임이다. 그걸 밖으로 빼낸 것이다. 게다가 데코레이트의 특징 대로 타겟의 직접 액세스를 얼마든지 허용한다. 따라서 데코레이터 +1.

물론 책임 부가 대신 액세스 컨트롤하기 위한 경우도 있긴 하다. 싱글톤 외의 스코프가 적용된 빈 액세스라덩가, 웹 서비스를 포함한 각종 리모팅이나 메소드 보안 등등. 이게 쫌 애매하다. 런타임시에 부가되는 구조나 Advice에게 책임을 떠넘기니 프록시 자체의 역할이 애매한 등등이 있지만, 전체 뭉뚱그려서 그 의도를 보면 타겟에 대한 기능 부가보다는 액세스 컨트롤이니 프록시 +1.

그러나 스프링은 내부적으로 DynamicProxy는 단지 Advice를 DI 받아 실행해주는 역할이라고 쳐서 매커니즘만 가지고 보면 DI + 0.1

하지만 DynamicProxy를 쓰는 목적인 스프링의 AOP의 꽃은 뭐니뭐니 해도 트랜잭션 디마케이션 기능 부가. 따라서 데코레이터의 힘겨운 승리.

 

오늘의 결론: 그때 그때 다르다. 이름에 속지말자.

또다른 결론 : 역시 패턴지식은 실전 코드와 함께 살펴봐야 실체가 드러난다.

3 Comments

hangumJuly 15th, 2009 at 11:51 am

디자인 패턴에 대한 정의가 매우 인상깊네요.

July 15th, 2009 at 12:02 pm

그냥 두 개 다 이용했다고 하면 안 되나요?

TobyJuly 15th, 2009 at 7:29 pm

썬/ 하고 싶으면 해.

Leave a comment

Your comment