디자인 패턴이란 소프트웨어 설계 과정에서 자주 발생하는 문제들을 해결하기 위해 일반화된 재사용 가능한 솔루션을 제공하는 것이다. 특정 문제에 구체적인 코드를 제시하는 게 아니라 문제를 해결하는 방법의 템플릿을 제공하여 설계시간을 단축하고 코드의 재사용성을 높이는 것이다.
디자인 패턴은 90년대 초쯤에 등장했으며, 프로그래밍 초기에 개발자들이 비슷한 문제에 대해서 반복적으로 비슷하게 풀어가고 이를 표준화하고 체계화하여 개발자가 효율적으로 문제를 해결할 수 있도록 정의되었다
디자인 패턴을 학습하기 위해 정보를 찾다 보면 가장 먼저 GoF라는 단어를 볼 수 있는데 이는 Gang of Four의 약자인데 Erich Gammma, Richard Helm, Ralph Johnson, John Vlissides 네 명의 소프트웨어 엔지니어를 의미하는 것이다. 이 엔지니어들은 디자인패턴의 개념을 널리 알린 주요 인물들인데 94년에 발간된 Design Patterns : Elements of Reusable Object-Oriented Software라는 책에서 23가지의 디자인 패턴을 알리며 영향력을 끼치게 되었다.
디자인 패턴의 유형은 크게 3가지로 분류된다.
1. 생성패턴 (Creational Patterns)
- 개체의 생성과 조합을 캡슐화하는 방법을 제공하며 대표적으로 Singleton, Builder, Factory Method 등이 있다.
2. 구조패턴 (Structural Patterns)
- 클래스 혹은 객체를 조합해서 더 큰 구조를 만드는 패턴이다. 대표적으로 Adapter, Decorator, Composite 등이 있다.
3. 행동패턴 (Behavioral Patterns)
- 개체들 간의 통신을 다루는 패턴으로 작업 처리 방식과 개체 간의 의존성을 감소시키는 패턴이다. 대표적으로 Observer, Strategy, Command 등이 있다.
3가지 유형에 대해서 처음 보면 어렵게 느껴질 수 있다. 내가 이해할 때 가장 쉬운 표현으로는...
생성 패턴은 공장이라고 이해하면 좋지 않을까 싶다. 공장에서는 제품을 찍어내야 하고 그렇기 위해서는 각각 프로세스에 불필요한 과정을 중간중간에 넣기보다는 제품을 만드는데 프로세스화된 구조를 가진 것이라고 생각하면 조금 쉽게 이해하지 않을까 싶다.
구조패턴은 건축을 하는 것이라고 이해하면 다소 쉽지 않을까 싶다. 예를 들어 블록을 이용하여 집을 만든다고 해보자 이때 우리는 레고를 가장 많이 떠오를 텐데 레고의 모양은 제각각이다. 하지만 그 레고들도 어느 정도 종류가 정해져 있고 그 종류들을 잘 이용하면 각지고 멋진 집을 만들 수 있다.
행동패턴은 우리가 평소에도 자주 사용하는 길 찾기 서비스라고 이해하면 좋을 것 같다. 길찾기 서비스를 이용할 때 우리는 단순하게 현재 위치와 목적지를 넣고 찾지만 이는 서비스 내부에서는 목적지에 맞는 경로에 대해 탐색하고 이때 최적의 경로를 맞춰주기 위해서 많은 전략이 들어간다.
디자인 패턴을 사용하면 어떤 점이 좋을까?
일관된 패턴을 사용함으로써 소스코드의 가독성을 높일 수 있다. 가독성이 높아지면 읽기 쉬운 코드가 된다는 것인데 읽기 쉽다는 건 그만큼 이해하기 쉽다는 것이고 유지보수를 함에 있어서 좋다는 것이다. 또한 유사한 문제에 접근하거나 해결하는 과정에서 동일한 패턴을 이용하여 재사용성이 증가되는 이점이 있다. 또한 디자인패턴을 이해하고 사용하는 사람들이 모여 제품을 개발하고 유지보수하는 과정에서 상호 간에 설계된 정보에 대해 커뮤니케이션에 큰 도움이 된다.
예를 들어 A라는 사람이 새로운 회사로 이직을 했다고 치자. 그러면 새로 입사한 회사에서 인수인계를 받게 되는데 과정 중에 코드를 설명할 때 어떤 패턴인지 덧붙여 설명을 듣게 되면 A라는 사람은 설명들은 패턴에 대해서 사용해 본 패턴이라면 단번에 어떤 이유로 이 패턴을 사용했을 것이며 이 코드에 대해 더 쉽게 접근할 수 있게 되는 것이다. 또한 동료들과 협업을 통해 구조화시키는 과정에서 상호 간에 이해를 요구하며 긴 시간을 논의하지 않아도 된다는 것이다.
이미 검증된 패턴을 사용하면 효율적인 시스템 설계가 가능할 것이다.
문제는 나 역시나 역시 프로그래밍 개발 초기 혹은 주니어시절 잠깐 공부했던 상황이고, 각 패턴에 대해 언급하지 않으면 내가 어떤 패턴을 이용해서 코드를 작성했는지 인지하지 못할 수 있다. 또한 분명 알고 있는 개념인데도 잊어버리는 경우가 허다하다. 개발자 면접의 단골 코스 질문이 디자인 패턴에 대한 질문인데 이때 나 역시 대답을 잘하지 못한다.
언젠가 내 소스코드를 보면 분명 군데군데 패턴적용을 잘 시켜둔 것이 눈에 띄기도 한다. 문제는 내가 그것을 인지하고 작성했느냐 혹은 누군가의 소스코드를 보고 카피하는 과정에서 작성했느냐의 차이일 수도 있다고 생각한다.
환경적으로 뒷받침이 되지 않으면 개발자는 성장함에 있어 이러한 부분을 놓칠 수 있을 수 있는 것 같다. 위에 언급한 내용과 같이 사내에서 직접적인 코드리뷰를 하거나 인수인계 과정에서 "이쪽 부분은 ~~~ 패턴을 적용해서 구조화했고요"라는 얘기를 들어본 적 없거나 한 적이 없다면, 그것은 환경적인 요소가 작용한 부분이 있을 수 있다는 것이다.
환경을 탓하기보다 스스로를 질책하라고 할 수 있지만 프로그래밍을 함에 있어 예술을 하거나 연구를 하는 게 아닌 생존을 위해 하는 사람들도 분명 있다. 그렇기에 디자인 패턴에 대해 다소 모르거나 헛갈려하더라도 차분하게 다시 설명해 주거나 같이 공부를 해보자고 제안해 보는 건 어떨까?