안녕하세요. 린치핀소프트 한광희입니다.

이번 포스트에서는 소프트웨어 디자인 패턴에 대한 이야기를 해보려고 합니다. 대학에서 컴퓨터공학을 전공하며 수업을 들을 당시에는, 디자인 패턴(Design Pattern)에 대해서 조금 들어보고 GOF 의 책이 디자인 패턴에서 기본이며 잘 정리된 책 정도라고만 알고 있었습니다.  디자인 패턴의 필요성이나 어떠한 문제를 해결 해주는 지에 대해서는 궁금함을 가지고 있었습니다.

이후 소프트웨어의 코드리뷰와 설계리뷰를 하다보니, 생각보다 많은 문제들이 설계의 오류, 개발팀 내의 커뮤니케이션의 오류와 해당 문제가 앞으로도 계속 재현될 가능성이 있는 환경등에 대해서 해결책을 고민하게 되었습니다. 이때 가장 먼저 디자인패턴에 대해서 생각해보게 되었고, 디자인 패턴에서 제공하는 여러가지 패턴을 응용해 보며 문제를 해결해보고 있습니다.

그래서 이번 글에서는 제가 이해하고 있는 디자인 패턴에 대한 개념과 몇 가지 패턴에 대한 특징들을 소개해 보도록 하겠습니다.

 

디자인 패턴(Design Pattern) 이란?

“소프트웨어 디자인 패턴이란 소프트웨어 디자인에서 계속 재현되는 문제를 해결하는 재사용 가능한 해결법이다.”(A software design pattern is a reusable solution to a reoccurring software design pattern. 출처 Programming in the Large with Design Patterns. Eddie Burris)
상기 출처의 저서에서의 설명처럼 디자인패턴이랑 소프트웨어 개발간 또는 디자인간에 재현되는 문제를 해결할 수 있고 매 문제 발생시마다 그 재사용 할 수 있는 해결방법이라고 생각합니다.

예를들어 소프트웨어 개발간에서 모든 “특정 클래스가 실행간에 단 한번만 인스턴스화 되어 객체로 이용가능하여야 한다.” 라는 문제를 해결하기 위해 “싱글톤 디자인패턴(Singleton Design Pattern)”을 이용해볼 수 있습니다. 또는 특정 클래스의 생성 또는 객체화에 있어 호출당시의 콘텍스트(Context)를 고려하여 클래스를 반환해주는 “팩토리 디자인패턴(Factory Design Pattern)”이 유용하게 사용해볼 수 있습니다.
이렇듯, 디자인 패턴은 소프트웨어의 디자인(설계)간에 발생하는 문제를 해결해주는 해법이라고 볼수 있습니다. 단, 디자인 패턴은 데이터 구조 또는 알고리즘과 다르며, 아주 특정한 구조에서 특정한 문제에 한하여 한번만 문제를 해결할수 있는 디자인은 “디자인 패턴”이라고 보기는 어렵다는 견해도 있습니다.(조금 더 설명하자면, 디자인 패턴은 유사한 문제에 대해 특정 패턴들을 재사용하여 문제를 해결하는 소프트웨어 개발 방법론이라고 생각하는데, 재사용이 가능하지 않거나 아주 구체적인 특정 문제에서만 몇번 이용할 수 있는 디자인은 패턴으로 보기 어려울 수 있습니다.)

조금 더 쉽게 말해 디자인 패턴(Design Pattern)은  문제/의도/해결방법이 명시적입니다. 즉 해당 패턴이 사용되는 문제가 “정형화” 되어 있으며, 해당 문제를 접근하는데 어떠한 의도를 가지고 어떻게 해결하는지에 대해서 명시적인 해결 방법 또는 접근 방법을 제안합니다.

  • Decorator
  • Facade
  • Observer
  • Singleton
  • Factory
  • Strategy
  • Proxy
  • Adapter
  • Iterator
  • State

위 나열한 각 디자인 패턴의 명칭 처럼 정형화된 문제에서 해당 문제에 접근하는 의도와 해결법도 패턴으로 정형화 되어 있습니다. 디자인 패턴에 대한 목록은 (https://en.wikipedia.org/wiki/Software_design_pattern) 에서 더 확인해볼 수 있습니다. 위의 각 패턴들 중에서는 저 자신도 몇가지는 아직 프로젝트에서 응용해 보지 못한 패턴들도 많습니다. 그래서 각 패턴에 대한 설명보다도 디자인 패턴에 대한 공부와 소프트웨어 개발 프로젝트에서의 응용을 통해서 어떠한 효과를 체감 할 수 있었는지에 대해서 정리하고 글을 마치도록 하겠습니다.

 

1. 재현되는 디자인 문제에 대해서 프로젝트간 또는 팀 내부에서 공유하는 공통의 해법 도출

데이터 구조(Data Structure) 또는 특정 알고리즘을 해결가능한 범위가 아닌 디자인에서 기인하는 문제를 해결하기 위해 차용 하는 해결방법이 프로젝트 범위 또는 협업하는 팀 내부 개발자간에 공통된 원칙을 고수 할수 있게 되었습니다. 이에 따라 공통된 원칙하게 개발되어 코드의 구조가 팀 내부에서 더 잘 리뷰되어 공유될수 있었으며, 해결방법도 기존에 각 개발자마다 자의적으로 선택하던 방식에서 팀내에 수립된 원칙에서 권장되는 해법으로 통일될 수 있었습니다.

2.각 디자인 패턴의 문제/의도/해결방법을 학습함에 따라 소프트웨어 설계에 맞닥뜨리는 문제에 대한 빠른 유형 파악 및 해결방법 제안

앞서 설명한 것처럼 디자인 패턴은 항상 그 패턴이 사용되는 문제의 상황과 문제를 풀어가고자 하는 의도/방안이 명시적입니다. 그래서 여러 패턴을 조금씩 공부하다 보니, 소프트웨어 설계시 발생하는 디자인 문제에 대해 정형화 하여 빠른 해법을 도출할 수 있다는 장점이 있었습니다.

3.디자인 패턴의 재사용이 곧 코드의 재사용으로 이어져 이전보다 상대적으로 빠른 개발속도 및 유지보수에 용이

패턴을 사용한다고 코드의 재사용이 꼭 발생한다고 보장할수는 없지만, 제 체감으로는 패턴을 통해 구현된 클래스 유연함(Flexibililty)이 적지 않게 코드의 재사용으로 이어지는 결과를 보게 됩니다. 이에 따라 코드의 구조화와 재사용으로 생산성이 올라가고, 팀 내부의 문제를 해결하는 방법에 대한 협의된 원칙으로 코드의 개선/유지보수에서도 가독성이 높아져 더 빠른 생산성을 기대해 볼수 있었습니다.