[Design Pattern] 디자인 패턴 소개

Study/Design Pattern

[Design Pattern] 디자인 패턴 소개

v명월v 2021. 6. 8. 19:11

안녕하세요. 명월입니다.

이 글은 디자인 패턴에 대해 소개에 대한 글입니다.

디자인 패턴이란 먼저 영어로 디자인이 우리가 생각하는 화면 디자인의 뜻이 아니고 설계라는 뜻입니다. 즉, 설계 패턴이라는 소리입니다.

처음 이 디자인 패턴을 제시한 사람이 GoF라 불리는 네 명의 컴퓨터 과학자입니다. 저도 원서보다는 번역서와 해설서를 위주로 본 것이라 GoF에 대해서는 자세히 설명하기가 어렵네요.

어쨋든 이 네 명이 프로그램 코드를 작성하는 가운데 효휼적인 코딩 패턴과 실제 업무에서 프로그램 코드로 옮길 때 해석할 수 있는 패턴을 정리해 놓은 것입니다.

지금은 이 디자인 패턴이 물론 효율적인 설계 패턴을 위해서도 작성하지만 암묵적인 코딩 룰에 대한 것도 있습니다.

예로 제 경험담를 통해 설명하겠습니다. 제가 학교 다닐 때 약 10년 전에 디자인 패턴을 가볍게 공부한 적이 있었습니다.

그때 당시에는 솔직히 프로그램 객체 지향 프로그래밍(OOP)도 완벽히 이해가 되지 않은 상태에서 공부하려니 이해도 잘 되지 않았습니다. 또 그 당시 선배들로부터 디자인 패턴은 오히려 코딩하는 데 방해된다라고 들은 적이 있어서 깊게 생각하지 않고 넘겨 버렸네요. (어떤 선배인지 찾기만 해 봐라...)

그렇게 졸업하고 실무로 3~4년 경력을 쌓고 정체기가 왔었는데 그 당시에 설계 실력도 늘지도 않고 공부해도 매번 기초 공부에 힘들더라고요.

그래서 시작한 게 Open source project를 참여하는 것이었습니다. 오픈 소스 참여를 하면서 참 많은 충격을 받았습니다. 그 당시에도 나름 프로그램에 대해 많은 공부했다고 생각했었는데 오픈 소스는 이해가 하나도 안 되더라고요.

당연히 이해가 안 되니 참여도 못하고 간혹 아는 부분이 나와서 수정하고 Request(요청) 보내도 매번 Decline(거절) 왔었습니다. 개인적으로 좌절 많이 한 시절이기도 합니다.

한동안 그렇게 Decline(거절)만 오다가 용기내서 왜 Decline 했냐고 물으니 코딩 규약은 하나도 맞지 않고, 패턴식으로 해결을 해야 하는 데, 날 코딩으로 해결하려고 하니 또 다른 버그가 생길 가능성이 높아서 거절했다고 하더군요.

지금 생각해도 참 충격적이였는데, 그 후로 프로그램 프로젝트 공정이나 설계 기법, 표준 규약 등이 왜 중요한 지 알게 되겠더라고요. 지금 생각하면 저에게는 또 하나의 도약을 할 수 있는 기회가 되었던 것 같기도 합니다.

(지금은 프로젝트에서 프로그램 코딩은 진짜 10%고 공정과 설계가 제일 중요하다고 생각합니다.)

그 뒤 많은 디자인 패턴 책도 보고, 규약 사이트도 돌아다니면서 코딩하는 규칙에 대해 공부를 참 많이 한 것 같습니다. 어느 순간 프로그램 코딩에 있어서 코딩이라는 건 중요하지 않고 설계 기법이 얼마나 중요한지 알게 되었습니다.

디자인 패턴을 이야기하면 많은 해설책에서 설계적 문제점을 해결하기 위한 방법이라고 설명합니다. 물론 틀린 말은 아닙니다. 당연히 맞는 말입니다. 그런나 저는 여러 사람들이 쉽게 알아볼 수 있도록 설계적 약속이라고 생각합니다. 설계 규약 같은 것입니다.

프로그램 설계적 문제점에 대해서 디자인 패턴이 아니더라도 해결할 수 있는 방법은 많습니다. 그러나 자기 만의 방식으로 수정하고 만들면 그 설계에 대해서는 나 자신 말고는 아무도 알 수가 없습니다. 즉, 하루 종일 컴퓨터 앞에 앉아서 디버깅해야죠.

요즘에는 프로젝트를 설계함에 있어서 많은 오픈 소스를 사용하고, 오픈 소스도 사양에 맞게 직접 수정해야 할 일도 많이 있습니다.

오픈 소스는 이런 디자인 패턴에 맞게 설계가 되어 있기 때문에 디자인 패턴을 잘 알고 있으면 디버깅이 필요없이 소스만 보고도 프로그램이 어떻게 돌아가는 지 알 수가 있습니다.

예전에 어떤 책에서는 정말 잘 만들고 정교하게 설계한 프로그램은 주석이나 사양 도큐멘트가 필요없다. 코드 자체가 사양서이고 설명서인데 지저분하게 주석을 또 작성할 필요없지 않나? 라고 쓴 글을 봤습니다.

어떤 책인지는 잊어 버렸는데, 제가 프로그램 개발할 때마다 항상 마음 속 깊숙히 담고 있는 말입니다. 정말 잘 만든 소스는 주석과 도큐멘트가 필요없다. 그만큼 패턴과 규약을 잘 따른 소스이라는 소리입니다.

디자인 패턴을 이해하기 시작하면 오픈 소스들이 눈에 들어오기 시작합니다. 한번은 제가 디자인 패턴을 조금 이해하고 Java의 Spring 프레임워크 소스를 봤는데 소스만으로도 프로그램이 읽히더라고요(매트릭스의 네오가 이런 기분이였을까?).

즉, 디버깅을 하지 않아도 이 프레임워크는 어떤 식으로 움직이고 어떻게 활용하는 게 좋겠구나하고 말입니다. 그러니 오픈 스스 프래임워크 책을 살 필요가 없어졌습니다. 예를 들면 Spring 프레임워크와 책 같은 것을 말이죠. 그러나 Spring 프레임워크 자체가 워낙 커서 정리해 좋은 도큐멘트 없이 소스로 전부 해독하는 건 좀 힘들겠네요.

디자인 패턴에는 어느 정도 함수 명명과 클래스 명명법도 어느 정도 정해져 있고 약속이 있습니다. 예를 들면, GetInstance() 앗, 싱글톤!, FatoryBuilder() Builder 패턴과 Factory패턴! 그럼 내부를 보지 않아도 이 라이브러리는 이렇게 돌겠구나 추측을 해 볼 수 있습니다.

디자인 패턴을 공부할 때, 책을 보면 클래스 다이어그램으로 소개도 하고, 복잡한 예제들 소개해서 이해하기 어려운게 많았습니다. 예를 들면, 오라클 디비를 사용하다가 mysql 디비로 변경하라는 의뢰를 받았다. 이럴 때는 패턴을 어떻게 쓰고..등등 하는 책도 봤습니다.

이 패턴이라는게 딱 정해져 있는 것이 아니고 해석에 따라 달라지는 부분도 있고 상황에 따라 혹은 언어에 따라 알고리즘이 달라질 수도 있기 때문입니다.

그래서 처음 공부할 때는 디자인 패턴을 이해하기 매우 어려웠습니다. 그런 책들의 설명들이 틀린 것은 아닙니다. 맞는 설명들인데.. 이게 디자인 패턴을 정확히 이해하기 위해서는 기초 지식(OOP)나 알고리즘을 이해하고 있어야 합니다.

저는 가능하면 조금 쉽게 최대한 쉽게 설명해 보도록 하겠습니다.

디자인 패턴 목차.

1. 생성 패턴

- 객체를 생성하는(new)에 대한 정의입니다. 클래스 인스턴스를 제한하거나 혹은 쉽게 선언하기 위한 패턴으로 실제 프로그램 성능에 영향을 미치는 패턴입니다.

1-1. 싱글톤 패턴 - https://nowonbun.tistory.com/431

1-2. 빌더 패턴 - https://nowonbun.tistory.com/432

1-3. 프로토타입 패턴 - https://nowonbun.tistory.com/435

1-4. 팩토리 메서드 패턴 - https://nowonbun.tistory.com/433

1-5. 추상 팩토리 패턴 - https://nowonbun.tistory.com/434