디자인 패턴이란?

프로그래밍 언어를 공부하면 언젠가 1번은 꼭 보게 되는 단어다. 궁금했지만 당장 급하게 알아봐야 할 것은 아니라 넘겼었지만, 조금 여유를 갖게 되자 공부는 해보고 싶어져서 확인해봤다. 먼저 디자인 패턴이란 뭘까?

일단 디자인과 패턴이라는 2개의 단어가 합쳐졌다고 생각했다. 그래서 두 단어의 사전적 정의부터 확인해봤다.

Design : (건물, 책, 기계 등의) 디자인(된 형태), (상품, 건축물 등을)설계/도안하다
Pattern : (정형화된) 양식, 패턴, 모범, 귀감

저 둘을 합치면 어떤 것의 디자인을 할 때 지켜야 하는 양식, 어떤 것을 설계하는 것의 모범사례 정도의 뜻이 나오겠다고 상상했다.

그 다음 영문 위키백과에서 디자인패턴을 검색해봤다.

 

디자인 패턴은 소프트웨어 디자인의 주어진 컨텍스트 내에서 일반적으로 발생하는 문제에 대한 일반적이고 재사용 가능한 솔루션이다...(중략)...다양한 상황에서 사용할 수 있는 문제를 해결하는 방법에 대한 설명 또는 템플릿이다...(중략)...프로그래머가 응용 프로그램이나 시스템을 디자인할 때 일반적인 문제를 해결하는 데 사용할 수 있는 공식화된 모범 사례다.

 

• 어떤 문제에 대해 재사용 가능한 해결책, 설명, 템플릿
• 프로그램 따위를 디자인할 때 발생하는 문제 해결의 모범 사례

 

상상한 내용과 완벽하지는 않지만 절반은 맞췄다. 프로그램을 디자인할 때 발생하는 문제를 해결하는 모범 사례.

일단 디자인 패턴의 디자인은 프로그램의 설계라고 생각하는 게 아다리가 맞을 것 같아서, 디자인은 설계라고 생각하기로 했다.

그럼 여기서 궁금한 것들이 생긴다.

 

• 디자인 패턴이 존재하는 이유(목적)가 뭐야?
• 이걸 쓰면 뭐가 좋은데?
• 프로그램을 설계할 때 생기는 문제는 어떤 것들이 있는 거야? 

 

위의 질문들부터 해결해보면 뭔가 나올 것 같다.

먼저 프로그램을 설계할 때 생기는 문제는 어떤 것들이 있을까?

 

첫 번째로 설계하지 않고 막개발해서 생각하지 못했던 문제(버그)가 발생하는 것이다.

그러면 그 부분을 수정해야 하는데, 설계를 공들여 하지 않은 상태에서 이것이 반복되면 내가 코드를 짠 건지 누더기를 만든 건지 구분이 안 될 수 있다. 최악의 경우 내가 짠 코드의 로직을 파악하지 못하는 경우도 생길 것이다.

여기서 근본적인 문제를 해결하지 않고 계속 개발하면, 코드는 계속 증가하고 프로그램의 몸집은 점점 불어나게 될 것이다. API도 붙이고 서버 통신 등 여러 기능들이 추가될 것이다. 그런데 버그가 터졌다면? 게다가 버그의 원인을 찾을 수도 없다면? 헬파티 예약이다. 또는 이 더러운 코드를 인수인계받아서 내가 분석하고 응용해야 한다면? 인간애가 사라지는 게 어떤 기분인지 몸소 느낄 수 있을 것이다.

 

두 번째로 사람은 각자 코딩 스타일이 달라서 발생하는 의사소통 문제다. 예시로 안드로이드의 리사이클러뷰만 해도 구현 방법은 정말 많다. 아이템에 클릭 리스너 붙이는 방법도 많은 것은 말할 필요도 없다. 그래서 어지간해선 코드를 받게 되면 그 코드에 대한 분석이 필수적이다. 그래야 내가 자유자재로 응용하고 필요없는 부분은 쳐낼 수도 있으니까.

그래서 이것 때문에 의사소통 문제가 일어나기 마련이다. 시간과 여러 비용적인 문제들도 발생할 수 있다.

 

그래서 전문가들이 이미 이러이러한 경우에는 저러저러한 코딩을 해라, 이 경우에는 저렇게 코드 짜는 게 좋다고 정해놓은 여러 종류의 코드 스타일들이 있다.

즉, 클래스들이 가진 구조에서 공통적/반복적으로 보이는 일정한 형태에 객체지향적 설계 노하우가 입혀진 것이 디자인 패턴이다. 그럼 디자인 패턴을 쓰면 어떤 문제가 해결되는지는 짐작할 수 있다.

 

• 개발자들 간의 의사소통을 원활하게 할 수 있다
• 프로그램의 구조를 파악하는 시간이 단축될 수 있다
• 이미 만들어진 디자인 패턴을 가져다 쓰는 것이기 때문에 개발 시간이 단축된다
• 설계 구조를 바꾸거나 유지보수하기 편리하다. 즉, 기능을 추가하거나 버그 잡기 편해진다.

와! 그러면 우리 모두 디자인 패턴을 당장 사용해야 하는 것 아닌가? 이렇게 장점들이 많이 있는데 안 쓰면 손해 아닌가?

 

아니다. 디자인 패턴은 만병통치약이 아니라서, 모든 문제를 해결할 수는 없다. 만약 그 정도라면 디자인 패턴이 아니라 디자인 알고리즘이라고 불러야 뉘앙스가 맞다.

그리고 같이 작업하는 팀원들이 그 패턴을 이해했을 때, 그 패턴이 효과를 발휘하는 문제일 때라야 그 디자인 패턴의 가치가 빛을 발한다. 난 이해했다고 갖다 쓰면 다른 팀원들은 뭐 어쩌라고? 그거 공부할 시간이라도 있으면 다행이다. 그 팀원한테 이슈가 생겨서 디자인 패턴이고 나발이고 볼 시간이 없이 급히 그 이슈를 처리해야 한다면? 그로 인해서 작업시간이 줄어들고, 데드라인이 다가온다면?

이 때는 디자인 패턴이 필요없다. 자체적인 로직으로 처리하는 게 더 빠르고 좋은 해결방법일 수 있다.

 

또한 간단하게 몇 줄이면 해결되는 문제를 굳이 디자인 패턴을 갖다 써서 해결할 필요가 없다.

팀에서 어느 팀원이 디자인 패턴이라는 혁신적이고 기깔나는 거 찾았다면서, 미친듯이 코드 전체적으로 그 패턴을 적용했다면 어떨까? 그 결과 퍼포먼스가 떨어지거나 기한에 맞추지 못했다면? 민폐도 이런 상민폐가 없다.

 

디자인 패턴에 대해서 엄청 깊게 파고들어 공부한 것은 아니지만, 공부하면서 내 나름대로 내린 결론은 아래와 같다.

 

• 디자인 패턴은 프로그램 설계에서 일반적으로 발생할 수 있는 어떤 문제들에 대한 해결 방법이다
• 디자인 패턴을 쓸 거면 이게 정말로 필요한 패턴인지, 득실은 어떤지 분석하고 써야 한다