자바나 C++ 같은 프로그래밍 언어를 사용하다가 루비나 얼랭(erlang) 같은 동적인 언어를 사용하면서부터 늘 하게되는 생각 중 하나는 "이보다 더 나은 방법은 없을까?" 하는 것입니다. 객체지향 언어를 사용하면서부터 전가의 보도처럼 여겨온 GoF의 디자인 패턴도 그 중 하나일 것입니다. 왜 꼭 이 방법이어야 할까? 뭔가 다른 방법이 있지 않을까? 그렇지만 나름대로 다른 방법들을 찾아 사용하다가도 갑자기 예전의 방식이 떠오르거나, 문득 누군가 다른 사람이 짜놓은 코드 속에서 GoF의 흔적을 발견할 때면, 지금 내가 가고 있는 길이 정도(正道)를 벗어난 것이라는 불안감과 의구심에 휩싸이곤 하죠. 그 이면에 자리잡고 있는 게 바로 "지혜의 간극(wisdom gap)" 이라네요. 무언가 새로운 것이 출현하고 그게 사람들 사이에 받아들여져 최선의 사용 패턴이 생겨나기까지의 시간 격차를 그렇게 부르는군요. 그런 의미에서 Russ Olsen의 Design Patterns In Ruby는 지혜의 간극을 발견하고 좁혀나가는 길을 열어준 책이라 할 수 있습니다. 무엇보다도 책의 마지막 결론이 맘에 들어 인용해 봅니다.(이 책이 아직 국내에서 출간되지 않은 관계로, 그리고 아마 앞으로도 오랫동안 번역되어 출간될 가능성은 없을 거란 판단에, 임의로 번역하여 인용하였습니다. 혹 저작권과 관련하여 문제의 소지가 있을 경우에는 언제든 내리도록 하겠습니다.)

"긴 여정이었다. 우리는 이 책에서 Template Method 패턴이 제공하는 메서드 오버라이딩부터 시작하여 관례(convention)에 따라 동적으로 클래스를 로드하는 법까지 살펴 보았다. 그러는 가운데 우리는 오리-타입에 기반한 루비 언어의 동적인 특징들이 많은 프로그래밍 문제들을 해결하는데 있어 어떠한 변화를 가져다 주는지 보았다. 만약 우리가 어떤 클래스 속에 깊숙이 자리잡고 있는 알고리즘을 다양하게 가져가려 한다면, Strategy 객체를 구현할 수도 있지만 단지 그냥 코드 블럭에다 던져넣을 수도 있다. 위임(delegation)에 상당 부분 의존하고 있는 Proxy나 Decorate 패턴을 구현하는 것도 더는 상투적인 코드들을 기계적으로 만들어 내는 것이 아니다. 루비의 동적이면서도 반영적인 특징들은 전통적인 Abstract Factory와 Factory Method 패턴의 상속과 연관된 한계들을 뛰어 넘는 팩터리 개념을 제공한다. 아무데서나 인터페이스를 조정할 수 있는 언어에서 Adapter는 더 이상 문제가 되지 않는다. 루비에서도 외부 반복자(external iterator)를 이따금씩 사용하기는 하지만, 대세는 내부 반복자(internal iterator)이다. 내부 도메인 특정 언어(internal domain-specific language; 역주 - external DSL에 대응하는 개념) 기법 덕택에 우리는 루비 인터프리터 그 자체를 인터프리터를 만들 때 파서로서 사용할 수 있다.

이들 중 놀랄 만한 것은 아무 것도 없다. GoF의 디자인 패턴이 나옴으로써 프로그램을 작성하는 기술에 있어 커다란 도약이 있은 것은 사실이지만, 그 책이 출간된 뒤로 이미 10년 하고도 반의 시간이 흘렀다. 만약 그 많은 시간이 흘렀음에도 우리가 여전히 똑같은 문제를 똑같은 방식으로 해결하고 있다면 슬픈 일이 아닐 수 없다. GoF의 패턴들 중 많은 부분은 분명 오래도록 살아 있을 해결책이자 오랜 시간 동안 우리와 함께할 아이디어임에 틀림없다. 그렇지만 프로그래밍은 문학과 유사한 면이 있다. 영어로 된 로미오와 줄리엣을 이탈리아어로 번역한다고 해 보자. 어순도 변경될 거고 작품의 느낌도 달라질 것이다. 줄리엣은 여전히 젊고 아름답겠지만, 이탈리아의 줄리엣은 뭔가 조금 다를 것이다. 디자인 패턴을 다른 언어, 예컨대 루비로 변환하는 것 역시 마찬가지다. 비슷하지만 완전히 똑같지는 않다.

원전 디자인 패턴에서의 문제들이 루비에서 이렇게 달라지는 까닭은 거의 무한대로 유연한 루비의 언어적 특성에서 기인하는 것이다. 루비로 프로그래밍할 때는, 만약 어떤 클래스의 행위나 인터페이스가 마음에 들지 않으면 여러가지 선택을 할 수가 있다. 그 문제 클래스의 인스턴스를 어댑터로 둘러 쌀 수도 있고, 데코레이터나 프록시를 만들 수도 있다. 그렇게 둘러싼 인스턴스들을 만들어 내기 위해 팩터리를 생성할 수도 있다. 팩터리를 싱글턴으로 만들 수도 있다. 만약 여러분이 큰 조직에 속해 있고 여러분 조직에서 누군가 다른 팀원이 만들어 놓은 복잡한 비즈니스 객체를 다루는 경우라면, 이 모든 것들이 민감한 문제일 수 있다. 그렇지만 여러분이 이해하는 간단한 객체를 다루는 경우라면, 간단하게 그 객체를 수정할 수 있다. 여러분의 구미에 정확하게 맞는 걸로 주무르면 되는 것이다. 루비를 사용하면 우리는 더 이상 작은 문제를 푸는데 있어 상대적으로 무거운 디자인 패턴을 가져다 쓸 필요가 없다. 간단한 문제는 간단하게 해결하는 방법을 루비가 제공하기 때문이다.

디자인 패턴이 출간된 이후로 지금까지 변하지 않는 것 중 하나가 지혜에 대한 욕구이다. Bruce Tate는 어떤 새로운 프로그래밍 기법이나 또는 언어가 나오게 되면, 지혜의 간극(wisdom gap)이 생긴다는 점을 지적한다. 업계에서 그 새로운 기법을 습득하고 기법을 적용하는 최상의 방법을 알아내기 까지는 시간이 필요하다는 것이다. 생각해보라. 객체지향 프로그래밍이 처음 등장하고 나서 우리가 객체지향 기술을 효과적으로 다룰 수 있기까지 얼마만큼의 시간이 걸렸던가? 그 간격이 바로 지혜의 간극인 것이다.

루비와 같이 동적이면서도 유연한 언어의 가치가 업계에 알려지기 시작하면서 우리는 또 한번 지혜의 간극에 빠지게 된다. 루비의 강력한 기능들은 우리가 여러 해 동안 씨름해 온 프로그래밍 문제들에 대해 다른 접근 방법을 제안한다. 루비는 또한 우리가 이전에 결코 생각하지 못했던 일들을 할 수 있는 힘을 제공한다. 그렇지만 우리가 정말로 해야 할 일은 무엇인가? 안전하게 갈 수 있는 지름길은 무엇이고 피해야 할 함정은 또 무엇인가? 루비를 사용하면, 우리는 이 모든 능력들을 손에 쥐게 되지만, 그러기 위해서는 약간의 안내(guide), 즉 지혜가 필요하다. 이 책에서 나는 루비의 강력함으로 할 수 있는 것들이 무엇인지 밝히려고 하였다. 그러나 우리가 이 새로운 지혜의 간극을 헤쳐나가는 가운데 우리는 더 나은 해법들을 발견해 내고, 동적이면서도 유연한 루비의 세계에 어울리는 더 나은 디자인 패턴들을 찾아낼 것이다. 그 패턴이 어떤 것인지는 알 수 없지만, 그걸 찾을 때까지 기다릴 여유가 내겐 없다. 분명 그것은 프로그래머에게 있어 멋진 시간이 될 것이다."