design pattern디자인 패턴이란 무엇인가?

   

1.1. 소프트웨어 설계의 중요성

시스템 개발을 할 때에는 여러 단계를 거쳐서 완성된 결과물을 만들어 내게 됩니다. 사용한 방법론에 따라서 혹은 적용되는 기업에 따라서 그 절차는 서로 다르게 되지만 일반적으로 고려를 해 본 다면 다음과 같은 절차를 따릅니다.

 

l  분석 : 현업 요구 사항 분석

l  설계 : 요구 사항에 맞게 시스템 설계

l  개발 : 설계 내용에 맞게 구현

l  테스트 : 구현된 내용이 요구 사항과 일치하는지 테스트

l  유지보수 : 운영

 

분석 단계에서는 일반적으로 고객의 요구 사항을 접수하고 이를 토의 합니다. 즉 고객의 요구 사항을 충족시킬 수 있도록 프로젝트의 범위를 결정하고 또한 해당 요구 사항이 현실적으로 수용이 가능한지를 판단하게 됩니다. 그리고 분석 단계를 거쳐서 시스템을 설계하게 됩니다. 하지만 여기서 한가지 문제가 발생합니다. 고객은 매우 변덕이 심한 존재라는 점입니다. 즉 고객의 요구 사항이 언제 얼마만큼 변화할 지는 예측하기가 힘듭니다. 그러므로 설계 시점에 고객의 요구 사항의 변경에 따라 쉽게 적용할 수 있도록 설계를 해야 합니다. 또한 이러한 확장성 있고 융통성 있는 시스템을 설계하기 위해서 다른 어떤 단계에 비해서 설계에 많은 시간과 돈을 투자해야 합니다. 즉 완벽한 설계는 그 만큼 개발 시간과 비용을 단축시키며 향후 요구의 변화에도 쉽게 대처할 수 있게 됩니다.

하지만 대부분의 방법론이 설계 단계를 강조하고 있지만 시간과 돈은 역시 개발에 투자를 하고 있다는 것을 대부분의 개발자들은 이미 경험하고 있을 것입니다.

단계	요구 비용 비율
분석 설계 개발 단위 테스트 통합 테스트 유지 보수	1 5 10 20 50 200

<표 1> 요구 변경시 비용 발생 비율

 

<표 1>은 각 단계별로 요구 사항이 변경되었을 때 발생할 수 있는 비용을 비율로 나타낸 것입니다. 즉 분석 단계에서 요구 사항 변경이 일어났을 경우에는 1이라는 비용이 들지만 유지 보수 시에 요구 사항이 변경이 되면 200이라는 비용이 발생한다는 점입니다. 자 여기서 디자인 패턴의 역할이 생기게 됩니다. <표 1>을 그래프로 변경한 것이 <그림 1>입니다. 이 그래프를 잘 보면 막대가 기하 급수 적으로 증가하는 것을 볼 수 있습니다. 디자인 패턴의 역할은 <그림2>와 같이 설계 단계에 좀 더 투자를 하여 그 이후에 발생하는 기하 급수적인 비용 상승을 억제하는 데 그 목적을 가지고 있습니다. 즉 다시 정리하자면 설계를 완벽히 하여 그 이후에 발성될 추가적이 요구 사항 변경 등이 있을 시에능동적으로 대처하여 비용을 최소화하고 궁극적으로는 잘 설계된 시스템을 다른 시스템에 적용하여 재사용하자는 데 그 목적이 있는 것입니다.

<그림 1> 디자인 패턴 적용 이전 비용 곡선

<그림 2> 디자인 패턴 적용 후 비용 곡선

지금까지 디자인 패턴의 목적에 대해서 알아보았습니다. 그렇다면 과연 디자인 패턴이 만능이 되어 줄 것인가 한번 생각해 볼 필요가 있습니다. 일반적으로 디자인 패턴을 적용하기 위해서는 설계 단계에 많은 시간과 비용이 소모가 됩니다. 그리고 어찌 되었건 개발 단계에서 코딩은 필수적으로 이루어져야 합니다. 그러한 이유로 비용이 적거나 혹은 시스템 구축 기간이 무척 짧은 프로젝트에 디자인 패턴의 적용은 다소 위험한 상황에 놓일 수도 있습니다. <그림 3>은 이러한 내용을 표시하고 있습니다. 즉 소프트웨어의 크기와 복잡도가 많지 않을 경우에는 오히려 디자인 패턴을 적용하는 것 보다 적용하지 않는 것이 더 좋은 선택일 수도 있다는 것입니다.

<그림 3> 소프트웨어 복잡도에 따른 수익 지점

1.2. 개발자로서 디자인 패턴을 통해 얻는 이점

 

지금까지 설명한 것은 디자인 패턴과 비용에 대한 관계에 대해서 알아본 것입니다. 위의 내용들은 주로 PM이나 관리자 급에서 관심을 가지는 내용일 것이며 개발자들에게는 재미는 있지만 솔직히 크게 다가오지는 않을 겁니다. 여기서는 개발자와 디자인 패턴간의 관계를 한번 살펴 보도록 하겠습니다.

스타트업 독자들은 이 책을 읽고 있는 지금 이 순간에도 고급 개발자가 되기 위해서 많은 노력을 하고 있을 것입니다. 그렇다면 고급 개발자가 되려면 어떻게 해야 할까요? 그리고 초보 개발자와 고급 개발자의 차이점은 어떤 것일까요? 지금부터 살펴보도록 하겠습니다.

이른바 고급 개발자라고 말하는 사람들이 만든 소프트웨어 혹은 시스템을 보면 첫째로 설계가 무척 잘되어 있다는 것을 알 수 있으며 그 결과 소스 코드나 내용 등이 무척 쉽고 이해하기 편리하게 되어 있습니다. 또한 고급 개발자들은이렇게 한번 만들어낸 결과물들을 계속 재사용하고 적용하며 다시 결과물들을 발전시키는 작업을 하고 있습니다. 그에 비해서 경험이 부족한 개발자들의 경우 소스 코드에 각종 옵션들 즉 임시 변수, 전역 변수 등이 남용 되어 있는 것을 볼 수 있습니다. 그리고 무엇보다 가장 심각한 것은 예전에 잘못 들인 버릇 즉 잘못된 사고와 코딩 습관을 계속해서 사용하고 있다는 것입니다. 그럼 이제 우리들의 모습을 한편 살펴보시기 바랍니다. 다음의 질문들에 마음 속으로답을 한번 해 보세요.

 

l  설계는 하고 코딩을 하고 있나요?

l  하고 있다면 재사용은 고려해서 하고 있나요?

l  재사용할 수 없도록 설계하고 있진 않나요?

l  설령 재사용 할 수 있도록 설계 했을 지라도 재사용은 하고 있나요?

 

위의 4가지 질문에 대해서 각자 다른 대답을 하고 있을 것입니다. 위의 질문의 가장 중요한 점은 설계를 하고 있더라도 재사용 할 수 없도록 설계를 하고 있으며 설령 재사용할 수 있도록 설계 했을 지라도 재사용 하지 않고 있다는 점입니다.

자 그렇다면 진정 고급 개발자로서 우리가 나아가기 위해서는 어떻게 해야 할까요? 여러분들은 바둑을 좋아하나요? 저는 잘 못하지만 바둑을 잘하기 위해서는 아무리 열심히 바둑을 둔다고 해서 실력이 느는 것은 아닙니다. 방법은프로 기사들의 기보들을 찬찬히 살펴보면서 그들이 바둑을 진행해 나가는 전략과 전술 그리고 패턴을 읽어 내는 것입니다. 스타크래프트를 잘하기 위해서 임요환의 전술을 시험해 보는 것 역시 좋은 방법이 듯이 말입니다.

소프트웨어 개발도 마찬가지 입니다. 고급 개발자가 되기 위해서는 고급 개발자의 패턴을 따라하는 것이 좋은 방법입니다. 그리고 그러한 고급 개발자들의 설계 패턴이 디자인 패턴인 것입니다.

고급 개발자는 설계적인 능력 그리고 다양한 패턴의 적용 능력 뿐만 아니라 빼 놓을 수 없는 것이 바로 풍부한 경험입니다. 풍부한 경험은 시스템의 문제점을 찾아내서 그것을 해결할 수 있는 능력을 의미합니다.

 

=== <박스 기사> ===============================================================

 

체스 고수 vs 설계 고수

 

다음 표는 체스 고수 그리고 설계 고수가 되는 단계를 비교 정리해 본 것입니다. 매우 유사한 것을 볼 수 있을 것입니다.

 

	체스 고수 되는 법	설계 고수 되는 법
기본 규칙 이해	l  말(패)의 이름 l  올바른 이동 방법 l  체스 판에 대한 이해	l  알고리즘 l  자료 구조 l  프로그래밍 언어
기법 습득	l  말간의 관계 l  전략 l  속임수	l  객체 지향 l  절차 지향 l  응용 능력
고수의 패턴학습	l  기보 학습 l  기보 적용	l  디자인 패턴 학습 l  패턴 적용

 

어떤 것이든지 고수가 되기 위해서 가장 빠른 길을 고수의 경험과 노하우를 익히는 것이며 그것을 자신의 것으로 응용하는 것입니다.

컴퓨터 언어, 혹은 소프트웨어 설계도 이와 크게 다르지 않습니다.

 

=============================================================================

 

1.3. 디자인 패턴과 디자인 패턴이 아닌 것

 

패턴이라는 의미는 무척 광범위합니다. 광범위한 만큼 그것을 정의하는 것 역시 무척 힘들고 까다롭습니다. 그래서 여기서는 디자인 패턴과 디자인 패턴이 아닌 것을 구분해 보도록 하겠습니다.

디자인 패턴에 분류 할 수 있는 것 중 가장 중요한 점은 소프트웨어 설계시에 일반적으로 발생하는 문제를 반복적으로 적용한 해결책이라는 것 입니다. 여기서 중요한 것이 반복이라는 말과 일반적이라는 말입니다. 즉 반복적으로 적용할 수 없고 아주 특정한 경우 혹은 한 곳에 적용한 이후 다른 곳에는 절대 적용될 수 없는(이른바 꽁수라는 것) 것들은 패턴의 대상이 되지 않습니다. 그리고 실질 세계에 적용된 적이 있어야만 합니다.

그에 비해서 패턴으로 분류 할 수 없는 것은 실질 세계에 적용된 적이 없는 아이디어나 이론, 오직 한번 적용된 해결책, 객체 지향이나 알고리즘 처럼 이미 너무나 일반화 된 것 등은 디자인 패턴으로 분류 하지 않습니다.

또한 중요한 오류 중에 하나는 디자인 패턴 하면 GoF의 “Design Patterns’에 나오는 23개의 디자인 패턴을 전부로 아는 것입니다. 2001년도에 공식적으로 디자인 패턴이라고 인정 받는 것이 약 800여 개입니다. 다만 그 중에서 가장유명한 패턴을 고르라면 GoF의 23개를 꼽을 수 있는 것이랍니다. 실제로 GoF의 ‘Design Patterns’를 보면 자신들의 책에서 소개하는 패턴들은 자신들이 독창적으로 개발한 아이디어가 아니라 다만 이미 있는 내용들을 자신들이 잘정리를 한 것이라고 얘기하고 있습니다.

 

1.4. 디자인 패턴의 4대 요소

 

디자인 패턴을 설명하기 위해서는 반드시 4가지 요소를 언급해야 하며 이를 정리하면 다음과 같습니다.

 

l  이름 : 패턴을 간단히 설명 할 수 있는 하나 혹은 두 개의 단어

l  목적 : 어떠한 경우에 이 패턴을 사용할 수 있는지 설명

l  해결 방법 : 해결 방법은 다시 디자인, 관계, 책임, 협동으로 분류해서 설명. 개념상의 설명을 하는 것이다.

l  결과 : 패턴을 적용함으로써 얻을 수 있는 결과를 설명

 

거의 모든 디자인 패턴들은 위의 분류를 가지고 디자인 패턴에 대해서 설명을 합니다. 아마 독자들이 디자인 패턴을 구입해서 보게 되면 위의 4가지에 형식으로 디자인 패턴을 설명하는 것을 알 수 있을 것입니다. 이 중에서 해결 방법은 다시 여러 분류로 나뉘어서 설명을 하고 있습니다.

위의 요소에 맞게 Brad Appleton이 제안한 재미있는 디자인 패턴을 한번 소개해 보고자 합니다. (http://www.cmcrossroads.com/bradapp/docs/pizza-inv.html)

 

l  이름 : 피자 전환

l  다른 이름 : 피자 샌드위치

l  목적 : 여러 조각으로 나누어져 있는 뜨거운 피자를 효율적으로 먹기 위한 방법. 피자가 가지고 있는 열을 캡슐화하고 피자 표면을 만지는 데 필요한 시간을 최소화 한다.

l  동기 :

소프트웨어 개발자들이 직면한 가장 중요한 문제점 중에 하나는 영양 보충을 지속적으로 하는 것이다. 바쁜 스케쥴과 프로젝트로 인해 본인들의 배고픔을 충족시킬 만한 시간이 부족하다. 그런면에서 피자는 배달을 해 주고, 고칼슘에다른 패스트 푸드에 비해서 좋은 영양을 가지고 있기 때문에 개발자들에게는 더 없이 좋은 음식이다. 하지만 피자는 매우 뜨거워서 빨리 먹을 수 없는 단점을 가지고 있으며 대부분의 개발자는 피자를 2-3조각 이상 먹는데 이를 빨리먹을 수 있는 방법이 필요하다. 이것을 해결하는 방법은 피자 2조각을 샌드위치 처럼 합쳐서 먹는 것이다.

<그림 4> 피자 패턴 해결책

위와 같이 하나의 피자 조각을 다른 피자 조각 위에 덮어서 먹게 되면 뜨거운 토마토 소스를 입에 직접 대지 않아도 되며 여러 조각을 한번에 먹게 되어서 매우 시간을 줄일 수 있게 된다.

 

l  구조 :

 

<그림 5> 피자 전환 패턴 구조

 

l  결론 : 뜨거운 토마토 소스와 기타 토핑으로부터 입을 보호할 수 있게 되었으며 두 개의 조각을 한번에 먹게 됨으로 효율이 두 배로 증가하였다.

 

비교적 재미있는 디자인 패턴입니다. 내용이 꽤 많은 편이라 부분적으로 인용을 했으니 위의 URL에 접속해서 한번 읽어보시기 바랍니다.

 

		목적
		생성(Creational)	구조(Structual)	행동(Behavioral)
범위	클래스	Factory Method	Adapter	Interpreter Template Method
	객체	Abstract Factory Builder Prototype Singletone	Adapter Bridge Composite Decorator Façade Flyweight Proxy	Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

<표 2> GoF 디자인 패턴의 분류

<그림 6> 디자인 패턴 간의 관계

 

=== <박스 기사> ===============================================================

 

Brian Foote의 게으른 건축가

 

어는 한 건축가가 대학 건물과 그 주변의 인도에 대한 설계를 하게 되었다. 그러나 그 건축가는 대학 건물만을 설계해 놓고 그 건물 주변의 인도에 대한 설계는 하지 않고 있었다. 그래서 건물은 지어졌지만 사람이 다닐 수 있는 인도는아직 없었다. 시간이 지나서 눈이 내리는 겨울이 되었다. 사람들은 건물 주위에 인도가 없었기 때문에 각자가 편한 대로 건물주위를 걸어 다녔다. 겨울이 되기 전까지 인도를 만들지 않고 게으름(?)을 피우던 건축가는 사진기를 가지고사람들이 눈 위에 만들어 놓은 건물과 건물 사이의 발자국의 모양을 찍기 시작했다. 긴 겨울이 지나고 봄이 되어서 건축가는 겨울 내 찍어 두었던 발자국의 사진을 바탕으로 인도를 만들기 시작했다. 디자인 패턴은 이와 같은 성질을가지고 있다. 디자인 패턴 작가(writer)는 시스템이 어떻게 동작할 가에 대한 성급하고 검증되지 않은 추측을 바탕으로 시스템에 대한 설계를 하기 보다는 영악하고 게으른 건축가처럼 눈 위의 발자국을 찾아서 어떻게 작동했는지를기술한다.

 

위의 예화에서 눈 위의 발자국은 여러 다른 소프트웨어 엔지니어의 경험을 의미하고 영악한 건축가는 새로운 시스템을 디자인 하는 과정에서 기존의 여러 소프트웨어 엔지니어에 의해서 검증된 디자인을 사용하고 있는 소프트웨어엔지니어를 나타낸다. 즉, 디자인 패턴이란 시스템 디자인 시에 자주 발생하는 문제들에 대한 “재사용 가능한 해결책”이라고 이해 할 수 있다.

 

=============================================================================

 

1.5. 개발자, 프로젝트 그리고 디자인 패턴

 

앞에서 개발자와 디자인 패턴의 관계에 대해서 설명하면서 고급 개발자로 가기 위한 지름길 혹은 도구라는 의미로 설명하였습니다. 여기서는 개발자 자신에 대한 내용이 아니라 개발자가 속해 있는 프로젝트와 연관해서 설명해 보겠습니다.

요즘 개발자들 사이에 디자인 패턴은 더 이상 공부해야 할 대상이 아닌 필수적으로 알아야 하는 기본 소양으로 자리 잡았습니다. 이러한 기본 소양으로 디자인 패턴이 자리 잡으면서 디자인 패턴의 중요한 역할 중에 하나는 의사 소통을 위한 언어로 사용된다는 점입니다. 예를 들어 우리가 객체 지향 프로그래밍에 익숙해 있어서 객체, 클래스, 상속, 다형성, 인터페이스 라는 용어를 자주 사용합니다. 그리고 개발자들 사이에서 이러한 용어를 이용해서 대화를 하고회의를 합니다. 이런 것이 가능한 이유는 바로 해당 용어를 통해 의사 소통이 가능하고 또한 해당 용어를 풀어서 설명할 필요가 없을 정도로 일반화 되었기 때문입니다.

디자인 패턴도 마찬가지입니다. 예를 들어 두 명의 프로그래머가 소프트웨어를 개발하기 전에 설계와 관련된 회의를 한다고 가정합시다. 그러면 두 사람은 여러가지 가능성을 고려할 것이며 그러한 고려를 통해 어떠한 디자인 패턴을사용할 것인지를 얘기할 것입니다. 만일 A라는 개발자는 디자인 패턴을 알고 있고 B라는 개발자는 디자인 패턴을 모를 경우 당연히 소프트웨어 설계를 할 때 서로 의사 소통이 되지는 못할 것입니다. 디자인 패턴은 기술이라기 보다는오히려 의사 소통을 위한 용어라고 하는 것이 더 올바를 정도입니다.

디자인 패턴을 모르는 개발자들일지라도 이미 디자인 패턴에서 언급하고 있는 다양한 접근 방법을 이용해서 개발하고 있는 사람들이 있습니다. 다만 해당 개발자는 이게 어떤 디자인 패턴인지를 모를 뿐입니다.

다만 중요한 것은 디자인 패턴으로 의사 소통이 되기 위해서는 디자인 패턴도 알아야 하지만 그것 보다도 먼저 객체 지향에 대한 확고한 이해와 적용 능력을 가지고 있어야 합니다. 객체 지향을 이해 못하는 상황에서 디자인 패턴의 공부는 무의미한 시간 낭비일 뿐입니다.

 

1.6. 디자인 패턴을 도입하면 성공할 것인가?

 

우리가 디자인 패턴을 필수적으로 알아야 할 것으로 여기고 이를 위해 많은 시간과 돈을 투자합니다. 책을 사서 읽습니다. 서로 토론도 합니다. 그리고 실제로 구현을 해 봅니다. 또한 대부분의 디자인 패턴 책은 매우 두껍습니다. 이렇게 어렵게 공부하고 적용한 디자인 패턴이지만 프로젝트에 적용할 경우 여러가지 문제점 이 발생할 수 있습니다.

 

모두가 디자인 패턴을 알아야 한다.

 

만일 팀원 중에 디자인 패턴을 모르는 개발자가 있다면 디자인 패턴을 도입한 프로젝트는 오랜 시간과 불투명한 의사 소통으로 인해 효율이 오히려 떨어질 수 있습니다. 앞에서 개발자 간에 의사 소통이 안될 수 있다는 예를 들었습니다.

 

디자인 패턴을 알기 전에 객체 지향을 알아야 한다.

 

물론 현대 개발자 중에 객체 지향을 모르는 경우는 거의 없을 것입니다. 하지만 중요한 것은 디자인 패턴은 객체 지향을 기반으로 한다는 것입니다. 객체 지향에 대한 완벽한 이해가 기본이 되어야 디자인 패턴을 이해할 수 있습니다.객체 지향에 대한 개념이 불명확한 초보 개발자들 혹은 절차 지향에 익숙한 개발자가 있을 경우는 디자인 패턴은 그만큼 불확실해 질 수 있으며 오히려 더 잘못된 설계를 야기할 수 있습니다.

 

개발자의 예측이 얼마나 적중할 것인가?

 

디자인 패턴은 설계 단계를 강조하고 있습니다. 즉 변화 혹은 변경이 있을 것으로 예상되는 부분에 디자인 패턴을 적용해서 유용하게 대처하는 것입니다. 하지만 중요한 것은 개발자의 예측이 항상 맞는 것은 아니라는 점입니다. 예를들어 이 부분은 유연한 변경이 필요하므로 디자인 패턴을 적용하고 이 부분은 그렇지 않으니깐 적용하지 말자라고 가정하고 소프트웨어를 설계합니다. 하지만 실제로 고객은 디자인 패턴을 적용한 부분에 대해서는 변경 요청을 하지않지만 적용하지 않은 부분에 대해서는 변경 요청을 할 수 있습니다. 그리고 이러한 일이 매우 자주 발생한 다는 점에 문제가 있습니다. 실제로 개발자의 예측이 맞을 확률은 채 10%가 되지 못한다는 주장도 있습니다.

 

디자인 패턴은 너무 어렵다.

 

국내의 대부분의 개발자들이 디자인 패턴을 공부하면서 얘기 하는 것이 너무 어렵다는 점입니다. 그렇다면 정말 디자인 패턴이 어려운 것일까요? 사실은 그렇지가 않습니다. 근데 어렵게 느끼는 이유는 무엇일까요? 그것은 대부분의디자인 패턴 책이 미국 책을 번역한 것이며 인터넷이나 잡지에 나오는 내용들 역시 미국에서 나온 자료를 토대로 하고 있다는 것이 문제 입니다. 미국의 개발자들은 오랜 기간 동엔 객체 지향 -> UML -> 디자인 패턴으로 옮겨오는 과정에 이미 익숙해 있습니다. 즉 디자인 패턴을 설명하면서 객체 지향과 UML에 대한 설명은 전혀 하지 않고 자연스럽게 해당 용어를 사용합니다. 하지만 국내 개발자들은 이러한 체계적인 과정 혹은 기술적인 적립이 매우 짧습니다. 그러므로 객체지향과 UML 등과 같은 체계에 익숙하지 않은 상태에서 디자인 패턴을 접하게 되므로 매우 혼동스러워 하게 되는 것입니다.

만일 디자인 패턴이 어렵다고 느낀 다면 자신이 객체 지향에 대한 이해가 부족하지 않은 지를 의심해 보고 다시 기본부터 공부 해 보는 것이 바람직 합니다.

 

디자인 패턴의 남용

 

어떤 분야의 엔지니어든 한번 공부한 것 혹은 터득한 것 그 중에서도 터득하는 데 아주 어려움을 겪었다면 이것을 꼭 적용하고 싶어하는 경향이 있습니다. 그리고 심지어 억지로 디자인 패턴을 적용하는 경우도 발생합니다. 비록 디자인 패턴이 고급 개발자들의 경험의 결과라고는 하지만 잘못 적용된 디자인 패턴은 오히려 소프트웨어를 어렵고 복잡하게만 합니다.

 

결국 이렇게 적용된 디자인 패턴은 프로젝트에 별 도움이 되지 않으며 재사용과 융통성 역시 이루어지지 않고 그 누구도 재사용하지 않는 결과로 나타나게 됩니다. 개발자들은 그냥 ‘그래 디자인 패턴 한번 적용해 봤어’라고 스스로 위안을 하고 프로젝트를 끝내게 될 것입니다.

 

결국 디자인 패턴을 성공적으로 적용하기 위해서는 디자인 패턴이 기반으로 하는 객체 지향에 대한 사고를 확실히 이해하고 있어야 하며 뿐만 아니라 디자인 패턴을 맹신해서도 안됩니다. 그러한 이유로 리팩토링과 XP와 같은 다른접근 방법에 대해서도 함께 고려를 하고 병행해서 적용해야 합니다.

 

== <박스 기사> ================================================================

 

코딩을 중요시 하는 리팩토링

 

디자인 패턴의 주된 주제가 재사용 가능한 소프트웨어를 만드는 것이며 리팩토링의 주제 역시 디자인을 향상 하여 재사용 가능하도록 만드는 것입니다. 둘다 디자인에 강조를 하고 재사용과 효율을 강조하지만 가장 큰 차이가 있습니다. 디자인 패턴은 바로 설계 시점을 중요시 하는 반면 리팩토링은 개발 시점을 중요시합니다.

 

“작성을 한 후에 디자인을 향상 시켜라”

 

위의 글은 마틴 파울러의 ‘Refactoring’에서 리팩토링을 설명하면서 나오는 대목 중에 하나입니다. 이렇게 작성을 먼저하고 디자인을 향상 시키라는 의미는 디자인 패턴의 문제점과 연결해서 생각할 수 있습니다. 디자인 패턴은 설계자의 예측에서부터 시작됩니다만 설계자의 예측이 맞을 확률은 10% 정도 밖에 안됩니다. 즉 재사용성을 고려해서 개발을 했지만 이것이 재사용 될 확률은 극히 낮다는 것을 의미합니다. 재사용되지도 않을 것이면서 디자인 패턴을 적용해서 많은 패키지와 클래스가 탄생하고 그런 이유로 인해 소프트웨어는 복잡해지며 에러 지향적으로 변하게 됩니다. 그러므로 개발시점에서 최대한 간략하게 코딩을 한 후에 해당 코드의 디자인과 구조를 변경해서 재사용 가능하도록 하자는 것이 리팩토링입니다.

또한 초기에 설계를 잘 하고 거기에 맞게 잘 코딩을 하였을 지라도 해당 소프트웨어를 계속 사용하면서 유지 보수로 수정을 가하게 되면 기존의 설계와는 무관하게 코드가 변경이 되고 그로 인해서 소프트웨어는 재사용 불능 상태에빠집니다. 이러한 경우에도 역시 리팩토링을 통해 디자인을 재 구성해야 합니다.

그러한 이유로 리팩토링은 주로 기존 소스를 어떻게 고쳐야 하는 가라는 내용들이 주를 이룹니다. 그리고 기존 소스 코드를 수정한 다는 의미에서 외부 구조가 아닌 내부 구조를 변경하는 일련의 행위라고 정의합니다.

리팩토링에서 언급하고 있는 리팩토링을 적용해야 할 대상을 정의 하면 다음과 같습니다.

 

l  중복된 소스 코드 : 당연한 얘기지만 아직도 많은 소스는 중복되고 있다.

l  긴 메소드 : 하나의 메소드에 너무 많은 기능이 포함되어 있는 경우

l  긴 클래스 : 하나의 클래스에 너무 많은 기능이 포함되어 있는 경우

l  긴 매개 변수 : 메소드의 매개 변수가 너무 많은 경우. 이해하기 어렵고 사용하기 어렵다.

l  잦은 변경 : 여러가지 변경 요구에 대해 특정 클래스 혹은 메소드가 집중적으로 변경되는 것. 기능의 분리가 이루어 지지 못했음을 의미

l  샷건 현상 : 하나의 변경 요청이 수 많은 부분에 영향을 미칠 때.

l  스위치 문장 : 길이가 긴 switch ~ case 문장

l  잘 사용되지 않는 클래스

l  발생 가능성이 없는 것을 대비한 코드

l  임시 변수 : 임시 변수의 남용

l  객체와 객체간의 연속된 호출

l  커플링 : 클래스와 클래스간의 연관 성이 너무 큰 경우

l  데이터 필드와 getter, setter 메소드만 있는 클래스

l  주석 : 자신 없는 로직에 주석을 단다.

 

위의 리스트를 보면 다소 이해 못할 부분도 있습니다. 우리는 일반적으로 PM 들이 주석을 아주 많이 달기를 요구 받으며 Chain of Responsibility 패턴은 객체와 객체간의 연속된 호출로 구성이 되며 데이터 필드만을 가진 클래스를이용해서 데이터베이스 처리를 하는 경우가 대다수이기 때문입니다. 하지만 이것도 디자인 패턴이 절대 진리가 아니듯 리팩토링 역시 절대 진리는 아니라는 점을 이해하고 서로 병행해서 보완 발전 시켜야 합니다.

 

디자인 패턴과 더불어 리팩토링은 현대 개발자의 필수 소양이랍니다. 오히려 디자인 패턴 보다 더 적용하기 쉽고 쉽게 이해할 수 있으므로 리팩토링을 먼저 공부하는 것도 좋은 방법입니다.

 

=============================================================================

 

1.7. 이것만은 꼭 읽어 보세요

 

디자인 패턴 만으로 훌륭한 소프트웨어의 설계와 구현을 할 수는 없습니다. 디자인 패턴 외에도 리팩토링, XP 등을 통해 다양한 방법과 기술을 익히는 것이 중요합니다. 또한 어떤 면에서는 리팩토링에 디자인 패턴보다 우리나라 실정에 더 잘 맞는 것일 지도 모릅니다. 그래서 디자인 패넌 보다는 리팩토링을 먼저 보기를 추천하는 경우도 있습니다. 우선 여기서는 이러한 것을 공부하기 위해 반드시 읽어야 할 책들을 언급해 보겠습니다.

 

l  Design Patterns : Elements of Reusable Object-Oriented Software

 

Erich Gamma, John Vissides, Ralph Johnson, Richard Helm의 공동 저서입니다. 흔히 GoF(Gang of Four)라고 불려지며 이 책은 디자인 패턴의 베스트 셀러이며 표준입니다. 다만 C++과 Smalltalk로 예제가 되어 있어서 이해가잘 안갈 수도 있습니다. 번역서로도 나와 있습니다.

 

l  Refactoring : Improving the design of existing code

 

Martin Fowler가 지은 리팩토링 책입니다. 앞서 소개한 Design Patterns가 디자인 패턴의 베스트 셀러이면서 기준이 되는 책이라면 이 책은 리팩토링의 기준이 되는 책입니다. 그리고 디자인 패턴과 관련해서는 많은 책이 나와 있지만 리팩토링 책은 이 책외에는 거의 찾아보기 힘들답니다. 만일 디자인 패턴에 부담을 갖고 있는 독자라면 리팩토링 책을 먼저 읽어 볼 것을 추천합니다.

1.8. 마치며

 

이번 호는 6개월간 진행될 디자인 패턴의 가장 첫번째 이야기입니다. 시작이 반인 것처럼 이번 호에서의 내용이 앞으로 진행될 내용을 모두 포함하고 있다고 해도 과언이 아닙니다. 디자인 패턴은 소스 코드를 외운다고 해서 되는 문제가 아닙니다. 가장 중요한 것은 디자인 패턴의 사상과 용어를 익히는 것입니다. 소스 코드는 두번째 문제입니다.

또한 디자인 패턴만이 절대 진리는 아닙니다. 디자인 패턴에 대해 회의를 느끼는 사람들도 많으며 궁극적으로는 재사용 가능한 소프트웨어를 만들자는 취지는 같지만 접근 방법이 다른 리팩토링 등이 존재합니다.