리더를 지키는 멤버

프록시와 데코레이터

 프로그래밍에는 데코레이터 패턴과 프록시 패턴이 있다. 이 둘은 모두 구조적 패턴에 속하며, 래퍼(wrapper)라는 구조적 유사성을 가지고 있어 종종 혼동되기도 한다; 래퍼는 특정 객체를 감싸는 객체이다. 하지만 데코레이터 패턴은 기능의 확장에 중점을 두고, 프록시 패턴은 접근의 제어를 목적으로 한다는 점에서 명확한 차이가 있다. 

 데코레이션 패턴의 목적은 객체의 기능을 동적으로 확장하거나 수정하는 것이다. 객체를 감싸는 데코레이터 객체(wrapper)를 통해 추가적인 기능을 제공한다. 여러 개의 데코레이터 객체를 조합하여 본래 객체의 기능을 점진적으로 확장할 수 있다. 기본 커피 객체에 우유나 설탕을 추가하는 것처럼, 데코레이터 객체를 사용하여 본래 객체에 추가적인 기능을 덧붙인다.

 프록시 패턴의 목적은 객체에 대한 접근을 제어하거나 중재하는 데 사용된다. 프록시 패턴은 객체를 감싸는 프록시 객체(wrapper)로 접근 제어, 로깅, 지연 로딩 등 부가적인 기능을 제어한다. 예를 들어 외부 서버에 객체가 접근하려고 한다. 이때 프록시가 객체와 외부 서버의 중간에 위치하여 접근을 제어하거나, 요청을 대신 처리하고 필요한 경우에만 객체와 상호작용하도록 한다.

 이 개념을 업무에 차용해 보면, 리더와 구성원(멤버)의 관계에서를 조금 다르게 이해해 볼 수 있다. 리더는 구성원에게 지시를 내리고, 구성원은 그 지시에 따라 업무를 수행한다. 업무 중에는 이슈가 발생하며, 이슈는 반드시 해결되어야 한다. 그러나 리더는 이슈 해결의 모든 세부 사항을 알 수 없기에, 세세한 문제들은 구성원이 해결해야 한다. 이러한 세부 사항의 해결은 메인 액션에 대한 기능 확장이라고 볼 수 있다. 기능의 확장이라는 측면에서 보면, 구성원이 리더의 지시 이 외의 이슈의 세부사항을 해결하는 것은 데코레이터 패턴을 적용한 것과 같다.

 이슈는 팀 내부에서만 발생하는 것이 아니다. 외부와의 협력을 통해 해결해야 하는 이슈도 있다. 리더는 구성원이 외부와 협력하여 이슈를 해결하길 원하지만, 모든 세세한 사항을 리더가 직접 외부와 소통할 수는 없다. 따라서 구성원은 리더가 외부로부터 불필요한 접근을 받지 않도록 조절해야 한다. 이러한 접근의 제어는 프록시 패턴과 유사하다.

 

 결국, 이슈를 해결하는 과정에서 세부적인 기능 확장은 데코레이터 패턴을 적용하는 것이며, 불필요한 소통을 차단하는 것은 프록시 패턴을 적용하는 것과 같다. 업무적으로 볼 때, 구성원은 리더를 둘러싸는 래퍼의 역할을 하게 되는 것이다. 이는 리더만이 구성원을 보호하는 것이 아니라, 구성원도 이슈 해결의 관점에서 리더를 보호하고 지원할 수 있음을 의미한다.

 리더가 팀의 목표를 달성하는 과정에서 외부의 정치적 위협을 막아낸다면, 구성원은 리더가 자신의 업무에 집중할 수 있도록 세부적인 문제들을 처리하고 외부의 방해를 막아주는 존재가 될 수 있다. 이처럼 리더와 구성원은 한쪽이 다른 쪽에 무조건적으로 의존하는 것이 아니다. 두 존재는 상호작용을 통해야만 더 단단한 팀을 이룰 수 있다. 이번 글이 독자의 팀을 더 단단하게 하는데 도움이 되었으면 좋겠다 :-)