저는 술을 좋아합니다. 친한 주변인들이나 공통의 관심사를 갖는 사람들과 모여 맛있는 안주와 함께 술을 마시는 것은 매우 즐거운 일입니다. 하지만 제가 알콜 중독자가 된다면 반길 사람은 없을 겁니다.
이런 상황을 디자인 패턴과 관련해서도 유사하게 적용할 수 있습니다. 다양한 디자인 패턴의 목적과 원리를 잘 이해하고 있다면 좋겠지만 소프트웨어 세상에 접근할 때 모든 것을 디자인 패턴의 필터를 통해서만 이해하거나 시스템을 패턴으로 뒤덮으려 한다면 동료들에게 환영받지 못합니다.
오래전 처음 디자인 패턴이란 것에 대해 알게 되었을 때 전혀 열광하지 않았습니다. 당시에 접했던 것들은 공장(factory), 관찰자(observer), 적응(adapter), 장식(decorator), 합성(composite), 반복자(iterator) 따위의 것들이었는데 어떤 것들은 기존에 사용하던 프레임워크를 통해 접하고 있던 것들이고 다른 것들은 마주친 문제를 해결하기 위해서 추상화 과정을 통해 직접 만들어 사용하던 것이었습니다. 분해된 문제들을 적절한 수준으로 추상화하고 컴퓨팅 원리를 사용해 풀어내는 능력을 기르는 것에 비해 해답 목록을 작성하고 이름을 붙이는 것은 별로 중요하지 않다고 생각했습니다.
지금도 디자인 패턴에 대해 아주 큰 의미를 부여하지 않는 것은 동일하지만 두 가지 측면에서는 위대함을 인정합니다. 첫 번째는 많은 프로젝트에서 반복적으로 겪는 다양한 문제의 가장 잘 정제된 해결책 중 하나라는 것이고, 두 번째는 패턴들의 이름이 매우 효율적인 의사소통 수단이라는 점입니다.
디자인 패턴이란 용어를 사용했지만 엔터프라이즈 아키텍처 패턴, 응용프로그램 아키텍처 패턴 등에도 동일하게 적용할 수 있습니다.
비극은 주객이 전도될 때에 발생합니다. 기업에서 소프트웨어를 만드는 이유는 현실 문제를 해결하기 위함입니다. 현실 문제는 무척이나 다양하며 모든 프로젝트는 해결하려는 고유의 문제를 가집니다. 현실 문제를 해결하는 과정에 포함된 더 작은 문제들 일부는 그동안 어디선가 반복되었고 이미 효율적이고 확실한 해법이 제시되어 있을 수 있습니다. 우리는 이것들을 패턴이라고 부릅니다.
하지만 다른 것들은 그렇지 않습니다. 프로그래머는 스스로의 지적능력을 사용해 이 문제들을 풀어야 하죠. 그렇기 때문에 패턴은 어디까지나 문제를 풀어내는 방법 중 하나이고 문제에 따라서 디자인 패턴은 선택지에 없을 수 있습니다.
패턴 중독자들은 패턴을 문제의 해법이 아니라 소프트웨어 구성요소로 여깁니다. 문제가 주어지면 해법을 찾기보다는 자신의 목록에 들어있는 패턴 중 가장 그럴듯한 것이 무엇인지 고민합니다. 그리고는 하나를 골라 배치하죠. 문제를 정확히 해결하는 것보다는 멋진 이름을 가진 디자인 패턴인지가 더 중요합니다. 문제는 제대로 풀리지 않았습니다. 오히려 일부 왜곡되어 버렸습니다.
각 디자인 패턴의 의미는 컴퓨팅 환경에 따라 달라지기도 합니다. Java 프로그래머가 관찰자 패턴을 사용하려면 잘 알려진 멋진 구현체 패키지를 설치하거나 직접 구현 코드를 작성할 것입니다. 그 후에는 자랑스러워하겠죠. 특히 후자의 경우 스레드 안정성 등을 확보했다면 더욱 그럴겁니다.
반면 C# 코딩 중 관찰자 패턴을 사용해야 할 문제를 만나게되면 그냥 언어가 제공하는 특징인 이벤트를 사용하면 상황은 종료됩니다. 이것은 사실입니다.
반복자 패턴은 추상적이고 단순합니다. 배열이나 연결 목록과 같은 데이터 스트림에 접근하는 가장 멋진 방법 중 하나로 사용되어왔죠. 이 글이 작성되는 시점에 비동기 입출력은 보편화되었습니다. 하지만 전통적인 반복자 패턴은 비동기 스트림을 지원하지 못합니다. 비동기 스트림을 처리해야 하는 상황에서 반복자 패턴을 적용하려 애쓴다면 문제 해결에 전혀 도움이 되지 않는 불필요한 거래(trade off)가 발생하게 된다는 것은 분명합니다.
Rx(Reactive Extensions)는 비동기 스트림을 처리하기 위한 인터페이스를 제공하지만 이것은 전통적인 반복자 패턴이라고 보기 어렵습니다.
새로 접하는 기술과 코드를 어떻게든 자신이 알고 있는 디자인 패턴에 끼워 맞추려는 시도 역시 좋지 않습니다. 기술적 산물의 본질을 이해하는 것을 방해할 뿐 아니라 동료들과의 의사소통을 더디고 불편하게 만듭니다. 누군가의 주장처럼 패턴 중독의 원인이 지식을 과시하고 싶은 유혹이라면 더욱 그렇겠죠. 팔각의 기어를 보고 잘 깎인 둥글고 빛나는 바퀴만을 얘기한다면 회전 운동이 직선반복 운동으로 변환되는 상호작용에 대해 이해하는 것은 아주 어려워질 겁니다.
패턴 중독과 알콜 중독이 환영받지 못한다는 점은 동일한 반면 치료법은 많이 다릅니다. 알콜 중독의 경우 알콜 섭취를 중단하고 뒤돌아 빠져나가야 하겠지만 패턴 중독의 경우는 앞으로 나아가는 것이 좋습니다.
패턴 중독자라면 다양한 패턴에 대한 지식을 가집니다. 메시징 문제를 해결하기 위해 합성 패턴을 떠올리진 않겠죠. 어쩌면 누군가에게는 패턴 중독이 성장 과정의 한 단계일 수도 있습니다. 오히려 적절히 활용하는 방법을 연마하는 것이 바람직합니다.
소프트웨어의 모든 구성요소를 디자인 패턴에 투영하는 것은 본질적인 문제를 왜곡하고 상황을 악화시킬 수 있습니다. 자신이 패턴 중독자라고 생각된다면 가능한 한 빨리 현명한 방법으로 중독에서 벗어나 자신의 지식이 프로젝트와 팀에 도움이 되도록 해야 합니다. 하지만 안타깝게도 중독자 스스로 중독 증세를 판단하는 것은 어렵습니다. 멘토나 동료들의 조언과 도움이 이럴 때 유용하겠죠.
원문 : Just Hack’em
