수안이의 컴퓨터 연구실

임백준 (루슨트 테크놀로지)
2004/11/05

1980년대 중반 소프트웨어의 사용 범위와 규모가 폭발적으로 늘어나게 되면서 소프트웨어를 구성하는 프로그램의 논리는 점점 더 복잡한 실타래처럼 꼬여갔다. C 언어로 대표되는 기존의 ‘절차적’ 언어가 그런 변화를 감당하기에 역부족이라는 사실은 누구의 눈에도 분명했다. 이와 같은 상황에 등장하여 사태를 단숨에 제압한 존재가 바로 ‘객체’였다. 객체가 제공한 ‘코드의 재사용(reusability)’과 ‘다형성(polymorphism)’이라는 약은 중병을 앓던 소프트웨어의 세계에서 놀라운 효능을 지닌 처방이 되었다.

객체의 ‘약’맛을 본 프로그래머들은 세부적인 알고리즘의 구현에 점점 덜 구애받게 되었다. 세부적인 논리보다는 요구사항(requirements)을 분석한 결과에 따라서 객체를 정밀하게 설계하는 일이 더 중요하게 되었기 때문이었다. 하지만 모든 약이 그렇듯이 객체도 모든 병에 대한 만병통치약이 될 수는 없었다. 객체의 개념과 장단점을 정확하게 파악하고 있는 프로그래머에게 객체는 분명 약이 되었지만 그렇지 않은 프로그래머에게는 오히려 ‘독’이 되기도 했던 것이다.

객체지향의 창시자, 와드 커밍햄과 켄트 벡
1987년에 객체지향 언어인 ‘스몰토크(Smalltalk)’를 이용해서 소프트웨어 설계 작업을 하던 와드 커닝험(Ward Cunningham)과 켄트 벡(Kent Beck)은 막바지에 이른 작업의 완성을 위해서 소프트웨어를 이용하게 될 사용자들이 직접 설계를 끝내도록 맡겼다. 이 때 커닝험과 벡은 스몰토크에 익숙하지 않은 사용자들이 잘못된 설계를 하는 것을 방지하기 위해서 스몰토크 언어를 이용한 설계에서의 몇 가지 핵심적인 내용을 간추린 ‘패턴(pattern)’을 정리해서 교육시켰다.

교육의 결과는 만족스러웠다. 커닝험과 벡은 이 경험으로부터 객체지향 언어에 있어서 디자인 패턴의 중요성을 처음으로 깨닫게 되었다. 그리하여 그들은 1987년에 열린 OOPSLA(Object-Oriented Programming, Systems, Languages & Applications) 컨퍼런스에서 패턴의 개념과 그 의미심장함을 강변했다. 이것은 컴퓨터 프로그래밍의 세계에서 하나의 작은 획이 그어지는 순간이었다. 하지만 커닝험과 벡이 발견한 패턴은 ‘아이디어’를 뒷받침할 만한 구체적인 실체가 결여되어 있었기 때문에 사람들의 주목을 충분히 끌지는 못했다.

지금은 쮜리히(Zurich)에서 살면서 IBM의 이클립스(Eclipse)나 비주얼에이지(VisualAge) 같이 잘 알려진 프로젝트에 참여하고 있는 에리히 감마(Erich Gamma)는 80년대 후반에 박사 논문을 쓰는 대학원생이었다. 감마는 자신의 논문을 정리하는 과정에서 객체지향 언어로 객체를 설계할 때 특정한 패턴을 나타내면서 반복되는 ‘무엇’이 존재한다는 점을 분명히 인식했다. 하지만 그 ‘무엇’을 다른 사람에게 전달할 ‘어휘’ 혹은 ‘의사소통’의 방법이 구체적으로 드러나지 않고 있었다.

‘네 명의 일당’과 패턴의 등장
그리하여 감마는 불확실한 ‘무엇’의 존재를 연구하여 ‘합성(Composite)’, ‘결정자(Decider)’, ‘관찰자(Observer)’, 그리고 ‘제한자(Constrainer)’라는 일정한 패턴으로 정형화했다. 프로그래밍 고수들의 머릿속에서 추상적으로만 맴돌던 패턴이 마침내 두꺼운 옷을 입고 현실에 모습을 드러낸 순간이었다. 추상적인 개념이 구체적인 존재로 탈바꿈을 하면서 소프트웨어 설계에 있어서의 패턴에 대한 프로그래밍 고수들의 연구는 가속도가 붙게 되었다.

그리하여 마침내 1991년에 개최된 OOPSLA에는 훗날 ‘네 명의 일당들(Gang of Four)’라는 별칭으로 불리게 되는 에리히 감마, 리처드 햄(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vlissides)가 한 자리에 모이게 되었다. 이 네 명이 여러 개의 패턴을 집대성해서 저술한 책이 유명한 “디자인 패턴 : 재사용 가능한 객체지향 소프트웨어의 요소들(Design Patterns: Elements of Reusable Object-Oriented Software]”이었다. 패턴이라는 초식을 익히고자 하는 프로그래머라면 한번쯤 읽지 않을 수 없는 책이다.


“각각의 패턴은 우리를 둘러싸고 있는 환경에서 반복적으로 나타나는 특정한 문제와 그에 대한 해결책을 설명한다. 그리고 그 해결책은 계속 사용될 수 있기 때문에 동일한 과정을 반복할 필요가 없다.”


건축으로부터 빌려온 패턴의 개념
패턴에 대해서 이와 같이 간명한 정의를 내린 사람은 크리스토퍼 알렉산더(Christopher Alexander)라는 사람이었다. 패턴이라는 개념을 최초로 포착한 그는 놀랍게도 컴퓨터 프로그래머가 아니라 건축가였다. 결국 소프트웨어 설계에서 나타나는 패턴이라는 개념은 알렉산더가 ‘건축’ 분야에서 정립한 개념을 빌려온 것이다.

프로그래밍 세계에서 패턴의 개념을 정립한 사람들은 건축 설계에 몰두했던 알렉산더의 저술에서 영감을 받았다. 위에 인용한 패턴의 정의는 컴퓨터 프로그래밍이 아니라 건축과 관련이 있는 것이었지만 어떤 대상을 새롭게 디자인하는 과정 일반에 적용되는 보편적인 방법론을 가리키고 있기 때문에 소프트웨어 설계의 과정을 포함했다.

한편 건축보다는 소프트웨어 구현에 더 많은 관심을 가졌던 ‘네 명의 일당’이 정의한 소프트웨어 설계 패턴은 다음과 같이 보다 구체적이었다.


“설계 패턴은 객체지향 시스템 안에서 반복해서 등장하는 설계와 관련된 문제를 해결하기 위한 일반적인 기법에 이름을 붙이고, 동기를 부여하고, 설명을 한다. 그것은 문제를, 해결책을, 그리고 그 해결책을 언제 적용해야 하는지, 적용한 결과는 무엇인지 등을 설명한다. 그것은 또한 실질적인 구현에 대한 힌트와 예제도 제공한다. 해결책은 대개 문제를 해결하기 위해서 필요한 객체와 클래스를 일반적인 방식으로 배치한다. 해결책은 주어진 문제를 특정한 문맥(context) 안에서 해결하기 위해서 다듬어지고 구현된다.”


패턴을 익히는 것은 마치 바둑에서 ‘정석(定石)’을 익히는 것과 같아서 패턴의 내용이나 이름을 기계적으로 ‘암기’하는 것은 아무런 의미가 없다. ‘네 명의 일당’이 밝힌 바와 같이 각각의 패턴이 필요한 동기, 그 패턴이 제공하는 해결책을 사용해야 할 시점, 그리고 그 해결책을 사용한 결과 등을 충분히 이해하는 것이 핵심이기 때문이다. 그렇지만 프로그래머를 채용하기 위한 면접 과정에서 설계 패턴에 대한 질문을 던지면 머리 속에 암기하고 있는 패턴의 이름을 앵무새처럼 이야기하는 사람들을 종종 만나게 된다.

다시 한 번 이야기하지만 중요한 것은 패턴의 ‘이름’이 아니라 그 이름이 담고 있는 ‘내용’이다(철학자들은 이것을 ‘형식’과 ‘내용’ 혹은 ‘기표’와 ‘기의’라는 어려운 말로 표현하기도 한다). 프로그래머들이 가장 흔히 알고 있는 패턴으로 대표적인 것은 ‘싱글턴(Singleton)’ 패턴과 ‘팩토리(Factory)’ 패턴이 있다. 둘 다 객체를 생성할 때 흔히 사용하는 기법이기 때문에 적어도 한번쯤 들어보거나 구현해본 적이 있을 것이다. 예를 들어 자바 언어에서 자바 가상머신(VM) 내부에 생성되는 객체의 인스턴스 수를 하나로 국한시키고자 할 때 사용하는 ‘싱글턴’ 패턴을 생각해 보자. 싱글턴 패턴을 숙지하고 있는 사람들은 다음과 같은 코드를 작성한다.

private static MyObject instance = null; public static MyObject getInstance () { if (instance == null) { instance = new MyObject (); } return instance; } private MyObject () { // 객체 생성에 필요한 초기화 작업을 여기에서 수행한다. }

앞의 코드는 MyObject라는 이름의 객체를 만들기 위한 클래스를 정의하고 있다. 클래스의 생성자(constructor)가 프라이빗(private)으로 선언되어 있기 때문에 MyObject의 인스턴스가 필요한 코드는 반드시 퍼블릭(public)으로 선언되어 있는 ‘getInstance 메쏘드’를 통해서 접근해야 한다. getInstance 메쏘드는 스태틱(static)으로 선언되어 있기 때문에 ‘MyObject.getInstance()처럼’ (객체를 생성할 필요 없이 바로) 클래스에 대한 참조를 이용해서 접근할 수 있다.

싱글턴 패턴의 유용성
싱글턴 패턴은 단순하지만 유용해서 실전 프로그램에서 널리 사용되는 대표적인 패턴의 하나이다. 보통 ‘생성적(creational)’, ‘구조적(structural)’, 그리고 ‘행위적(behavioral)’이라는 세 범주로 구분되는 여러 개의 패턴은 싱글턴 패턴이 인스턴스의 수를 하나로 국한시키고자 하는 목적을 갖는 것처럼 저마다의 목적을 가지고 탄생했다. 그리고 소프트웨어를 설계하는 프로그래머들은 의식적이든 아니든 그러한 패턴의 도움을 받으면서 복잡하고 정교한 객체의 건축물을 완성해왔다.

커닝험과 켄이 패턴의 개념을 포착한 이후로 패턴은 고수가 되고자 하는 프로그래머가 반드시 익혀야 하는 초식이 되었지만, 객체와 마찬가지로 그것은 만병통치약은 아니다. 객체의 설계든, 정교한 알고리즘의 작성이든, 그것은 ‘약’의 힘으로 하는 것이 아니라 오직 프로그래머 본인의 힘으로 해야 하는 일이기 때문이다. 프로그램의 ‘완성도’와 ‘미학’은 패턴 자체에 놓여있는 것이 아니라 그 패턴을 이용하는 프로그래머의 능력과 자세에 달려있는 것이다. @

http://www.zdnet.co.kr/news/column/hoti ··· 2C00.htm

저자: 장세찬 / 삼성네트웍스

※ 본 컨텐츠는 [GoF 디자인 패턴! 이렇게 활용한다: C++로 배우는 패턴의 이해와 활용]에서 발췌한 내용 입니다.

1. 소프트웨어 개발과 WHAT-WHY-HOW 생각 모델

소프트웨어 개발이란 무엇일까?

다양한 정의가 가능하겠지만, 저자는 소프트웨어 개발을 “원하는 목적(Goal)을 달성하기 위해 기준이 되는 개념이나 철학(Paradigm)을 바탕으로 특정한 과정(Process)을 거쳐 소프트웨어적인 해결책(Solution)을 만들어내는 것”이라고 정의하고 싶다. 즉, 소프트웨어 개발은 원하는 목적을 달성하기 위한 수단으로써 소프트웨어적인 해결책을 만들어 내는 것이며, 이를 위해 특정 개념이나 철학을 기준으로 단계 단계의 과정을 거친다는 것을 의미한다.

그렇다면 소프트웨어를 만들어내는데 기준이 되는 개념이나 철학(Paradigm)에는 어떤 것들이 있는 것일까?


1.1. 소프트웨어 개발 개념 또는 철학

현재까지 소프트웨어 개발을 위한 개념이나 철학(Paradigm)으로 정립된 것은 크게 구조적(Structured)인 것과 객체지향적(Object Oriented)인 것으로 나눌 수 있다. 여기서 구조적인 것은 소프트웨어를 기능 위주의 관점으로 바라보면서 원하는 기능을 하향식으로 세분화, 구체화시킴으로써 해결책을 만들어내는 것인 반면, 객체지향적인 것은 소프트웨어를 데이터 위주의 관점으로 바라보면서 구체적인 데이터들간의 상호 관계를 정의함으로써 원하는 목적을 달성할 수 있는 해결책을 만들어내는 것이다.

이 두 가지를 좀더 자세히 비교하면 [표 1-1]과 같다. 표에서 보는 바와 같이 구조적인 개념이나 철학 또는 객체지향적인 개념이나 철학의 장단점은 근본적으로 다음과 같은 원인에 기인한다.

▶ 구조적 접근 방식이 객체지향적 접근 방식보다 해결책을 좀더 빨리 만들어낼 수 있는 원인은 구조적 접근 방식의 경우 원하는 목적을 직접적인 기능으로 세분화, 구체화하여 해결책을 생각해나가는 데 반해, 객체지향 접근 방식은 먼저 사용할 데이터와 그 데이터를 조작하기 위한 인터페이스를 객체로 정의한 후에 정의한 객체들간을 상호 관련시킴으로써 필요한 기능을 수행할 수 있는 해결책을 만들어내는 2 단계 방식이기 때문이다. 즉 객체지향적 접근 방식은 객체 및 객체의 자료형인 클래스를 설계하는 단계와 이를 이용하여 원하는 목적의 기능을 수행하도록 하는 2 단계를 거친다.

▶ 구조적 접근 방식에 의한 해결책이 객체지향적 접근 방식에 의한 해결책보다 구조가 간단하다. 왜냐하면 구조적 접근 방식은 하향식으로 기능을 분할 정복하는 것이므로 해결책이 트리 구조를 이루지만, 객체지향 접근 방식은 객체들간을 상호 관련지우면서 복잡한 네트워크 구조로 해결책이 만들어지기 때문이다.






▶ 구조적 접근 방식은 서브시스템에 대한 정의가 쉬운 반면, 객체지향 접근 방식은 그렇지 못하다. 그 이유는 구조적 접근 방식의 경우 트리 형태로 해결책이 만들어지므로, 특정 서브 트리를 서브시스템으로 정의할 수 있지만, 객체지향 접근 방식의 경우에는 네트워크 형태로 해결책이 만들어지므로, 서브시스템을 구분 짓기가 어렵기 때문이다.

▶ 객체지향적 접근 방식은 설계를 강요한다. 왜냐하면 앞서도 언급했듯이 객체지향적 접근 방식은 객체 및 클래스를 설계하는 단계와 이를 활용하여 원하는 기능을 구현하는 2 단계로 이루어져 있으며, 객체 및 클래스의 설계없이는 이를 활용하는 부분의 설계나 코딩이 불가능하기 때문이다.
한편 설계를 선행하게 되면 무턱대고 코딩을 하다가 예상치 못한 요소 때문에 전체 코딩을 다시 해야 하는 헛수고를 사전에 피할 수 있는 장점이 있다.

▶ 원하는 목적에 변화가 생겨 이미 구현해놓은 프로그램을 변경해야 할 경우 객체지향적 접근 방식이 구조적 접근 방식보다 수정해야 할 범위가 훨씬 적다. 그 근본적인 원인은 달성하고자 하는 목적에 변화가 생기더라도 응용 분야가 바뀌지 않는 한 프로그램에서 사용하는 데이터는 크게 변하지 않는 반면 기능은 변경되어야 할 가능성이 훨씬 많기 때문이다.
예를 들어 학생들의 성적을 이름순으로 출력하던 프로그램을 성적순으로 출력하게 바꾸는 경우를 생각해보자. 원하는 목적이 변경되었다. 그럼에도 학생들의 성적 정보를 담고 있는 데이터는 변경될 이유가 없다. 반면 학생들의 성적을 이름순으로 출력하던 기능은 성적순으로 출력하기 위해 완전히 변경되어야 할 것이다.

▶ 객체지향적 접근 방식이 구조적 접근 방식보다 유지, 보수가 쉽다. 그 이유는 객체지향 접근 방식의 경우 객체를 기준으로 수정해야 할 범위가 명백히 구분될 수 있고, 또 주로 수정이 일어나는 부분이 객체 내부로 한정이 되는데 반해 구조적 접근 방식은 하나의 기능을 수정하였을 경우, 그에 따라 영향을 받는 범위가 불명확하여 일일이 확인을 해야 하기 때문이다.

▶ 객체지향 접근 방식이 구조적 접근 방식보다 재사용이 수월한 원인은 크게 2가지로 언급할 수 있다. 하나는 객체지향 접근 방식이 잘 변화하지 않는 데이터를 기준으로 객체를 정의하였기 때문에 객체를 단위로 재사용이 이루어질 수 있기 때문이고, 다른 하나는 클래스 상속을 통해 기존 클래스를 재사용하여 확장하면서도 이전 프로그램을 수정할 필요가 없기 때문이다.

이처럼 소프트웨어 개발의 기준이 되는 개념이나 철학은 크게 구조적인 것과 객체지향적인 것 2가지로 구분되고 있다. 이중 근래에는 객체지향적 접근 방식이 확산되고 있는데 그 이유는 소프트웨어의 개발에 드는 비용보다 소프트웨어의 수정 및 유지, 보수 비용이 훨씬 커서 이를 줄일 수 있는 접근 방식을 선호하기 때문이다. 여기서 소프트웨어의 수정 및 유지, 보수 비용이 개발 비용보다 점차 더 커지는 이유는 사용하는 소프트웨어가 계속 늘어나고 있다는 점과 이미 사용하고 있는 소프트웨어라도 그 목적이 추가, 확장되거나 빠르게 변화하고 있다는 점에 기인한다.

그럼 소프트웨어 개발에서 과정은 무엇이며, 어떻게 구성되어 있을까?


1.2. 소프트웨어 개발 과정

소프트웨어 개발 과정(Process)이란 한 마디로 얘기하면 소프트웨어를 어떤 순서로 개발할 것인가 하는 것이다. 일반적으로 소프트웨어는 대체적으로 [그림 1-1]과 같은 과정을 거쳐 개발이 이루어진다고 할 수 있다. 즉, 무엇을 개발할 지에 대한 요구 사항을 모아서 정리하는 단계에서부터 그것을 분석하고, 어떻게 구현할 지를 설계하는 단계, 설계된 내용을 실제 구현하는 단계, 구현된 결과를 테스트하는 단계, 개발이 완료된 소프트웨어를 지속적으로 유지, 보수하는 단계가 그것이다.

참고로 [그림 1-1]에서 요구사항 명세(Specification) 단계와 요구사항 분석(Analysis) 단계를 구분한 것은 실제 현장에서 소프트웨어를 개발하는 과정을 반영한 것이다. 즉 요구 사항 명세 단계는 기획 부서에서 1차적으로 개발 의뢰할 내용을 정리하고, 이를 기초로 개발 부서와 협의 및 조정을 수행하여 최종적인 요구 사항을 정리하는 것을 가리킨다. 반면 요구 사항 분석 단계는 기획 부서에서 요구 사항 명세서를 넘겨받아 개발 부서에서 무엇을 개발해야 하는 지를 구체화하고, 체계적으로 검토하는 것을 가리킨다.






한편 소프트웨어 개발 과정을 구성하는 각 단계별 주요 작업 및 산출물은 [표 1-2]와 같이 정리될 수 있을 것이다.





[표 1-2]에서 언급된 각 단계별 주요 작업을 다시 요약하면 다음과 같다.

▶ 요구사항 명세 단계: 소프트웨어 개발의 목적을 명확히 이해하고 공유하며, 구체적인 요구사항에 대해 논리적이고 합리적인지를 검토하여 필요시 요구사항을 조율하거나 조정한다.

▶ 요구사항 분석 단계: 기능(Function), 행위(Behavior), 데이터(Data) 측면에서 요구 사항을 체계적이고 구체적으로 분석하고, 실제 개발될 소프트웨어가 실행될 환경에 대해서도 분석, 검토를 수행한다.

▶ 기본 설계 단계: 개발할 소프트웨어의 전반적인 아키텍쳐를 구상하고, 구성 요소간 사용할 프로토콜을 정의하며, 사용자 인터페이스를 결정한다. 또한 데이터베이스를 사용할 경우 데이터베이스 스키마를 설계한다.

▶ 상세 설계 단계: 프로그램 구현을 위한 구체적인 자료구조와 알고리즘을 결정한다.

▶ 구현 단계: 상세 설계된 결과물을 실제 프로그래밍 언어를 사용해서 코딩한다.

▶ 테스팅 단계: 구현된 개별 모듈별 단위 테스트와 각 모듈들을 통합하여 제대로 동작하는지 여부를 점검하는 통합 테스트, 요구사항과 정확히 일치하게 동작하는지 여부를 검증하는 적합성 테스트, 실제 실행 환경을 대상으로 장애 복구나 보안, 안정성, 성능 등에 대한 점검을 수행하는 시스템 테스트를 수행한다.

▶ 유지 보수 단계: 개발 완료된 소프트웨어에 대해 추가, 변경 요구사항을 검토하고 반영하거나 장애나 오류 발생 시 이에 대한 대처 및 복구, 실행되는 소프트웨어의 지속적인 모니터링 및 시스템 운영 등을 수행한다.

이처럼 소프트웨어 개발 과정은 소프트웨어를 어떤 단계를 거쳐 개발할 것인가를 정의하는 것이며, [표 1-2]에서 언급된 각 단계들은 구체적인 개발 방법마다 달라질 수 있다. 또한 각 단계들의 작업은 1회성으로 끝나는 것이 아니라, 필요할 경우 반복적으로 수행될 수 있다. 이를 강조하기 위해 UDP(Unified Development Process)에서는 기본적으로 반복 개발(Iterative Development)을 수행하는 것으로 말하기도 한다.

그렇다면, 소프트웨어를 개발하는 데 있어 왜 이렇게 개념이나 철학(Paradigm)을 따지고, 개발 과정(Process)을 언급하는 것일까?

그것은 바로 원하는 목적을 수행할 수 있는 수많은 해결책(Solution)중에서 가장 최적의 해결책(Optimal Solution)을 찾아내기 위해서이다. 그렇다면 최적의 해결책이란 무엇이고 어떻게 하면 최적의 해결책을 좀더 쉽게 찾아낼 수 있을까?


[GoF 디자인 패턴! 이렇게 활용한다: C++로 배우는 패턴의 이해와 활용]


1.3. 최적의 해결책

앞서 언급하였듯 우리는 소프트웨어를 개발할 때 단순한 해결책이 아닌 최적의 해결책을 지향한다.

그렇다면 먼저 최적의 해결책(Optimal Solution)이란 무엇일까?

이것은 최선의 해결책(The Best Solution)과는 다른 것이다. 최선의 해결책은 언제, 어디서나 가장 적합한 해결책을 가리키는 데 반해, 최적의 해결책은 원하는 목적을 수행하되 주어진 환경이나 상황에 가장 적합한 해결책을 말한다. 이는 바꾸어 말하면 주어진 환경이나 상황이 바뀌면 최적의 해결책도 바뀔 수 있음을 의미한다.

예를 들어 화면상에 “Hello World !”라는 문자열을 출력하는 프로그램을 작성한다고 가정해보자. 아마 머리 속에 금방 다음과 같은 소스코드가 떠오를 것이다.

[소스 1-1] 화면 상에 “Hello World !”를 출력하는 프로그램 예

#include
using namespace std;

int main() {
cout << “Hello World !”<< endl;
return 0;
}


그러나 가만히 생각해보면 화면상에 “Hello World !”를 출력하는 프로그램이 이 한 방법만 있는 것은 아니다. 몇 가지 더 가능한 방법들을 나열해보면 다음과 같다.

① “Hello World !” 라는 문자열을 상수 값으로 정의해두고 그것을 출력하는 방법
② 프로그램 실행 시 인자로 “Hello World !” 문자열을 전달받아 그것을 출력하는 방법
③ 표준 입력을 통해 “Hello World !” 문자열을 입력받아 그것을 출력하는 방법
④ 특정 파일에 저장된 “Hello World !” 문자열을 읽어들여 그것을 출력하는 방법

이 밖에도 더 다양한 방법을 생각해낼 수 있을 것이다. 그렇다면 이런 다양한 방법들 중에서 어떤 방법을 선택하여 “Hello World !”를 화면 상에 출력하도록 할 것인가, 그리고 왜 그 방법을 선택한 것인가?

위에서 제시한 “Hello World !” 문자열 출력 방법들을 자세히 살펴보면 다음과 같은 특징을 지닌다.

▶ [소스 1-1]과 같은 방법은 “Hello World !” 문자열 출력만이 목적이고, 가장 빠른 시간 내에 개발을 하고자 할 때 좋을 것이다. 왜냐하면 다른 방법보다 코딩해야 할 프로그램 양도 적고, 금방 머리 속에 떠오를만큼 코딩이 간단하기 때문이다.

▶ ①과 같이 출력할 문자열을 상수 값으로 정의해두고 그것을 출력하는 방법은 “Hello World !”라는 문자열을 출력하되 동일한 내용을 출력하는 코드가 프로그램 내의 여러 곳에서 필요한 경우에 좋을 것이다. 왜냐하면 “Hello World !”를 상수로 정의하여 사용하기 때문에 동일한 문자열을 출력하고자 할 때 빈 칸이 어디에 있는지 등을 신경쓸 필요가 없기 때문이다.

▶ ②와 같이 프로그램 실행 인자로 “Hello World !” 문자열을 입력하고, 프로그램에서는 입력받은 문자열을 출력하는 방식의 경우에는 출력할 문자열을 임의로 지정하고 싶을 때 좋을 것이다. 단, 이 방식의 경우 프로그램 실행 인자로 주어질 수 있는 문자열의 길이는 제한이 있으며, 여러 라인의 문자열을 프로그램에 전달하지 못한다.

▶ ③과 같이 표준 입력으로 출력할 문자열을 입력하고, 프로그램은 입력된 문자열을 출력하는 방식은 출력할 문자열을 임의로 지정하면서도 여러 라인의 문자열도 출력할 수 있게 하고 싶을 때 적절할 것이다. 다만, 이 방식도 문자열의 길이에는 한계가 있다.

▶ ④와 같이 특정 파일에 저장된 문자열을 읽어들여 출력하는 방식은 라인이나 길이의 제한없이 문자열을 출력하고자 할 경우 적절할 것이다. 다만 이 방식의 경우에는 출력할 문자열을 저장한 파일을 유지, 관리해야 한다는 비용이 발생할 것이다.

이처럼 “Hello World !” 문자열 하나를 출력하는 데에도 많은 방법들이 존재하며, 구체적인 목적이나 상황 또는 환경에 따라 최적의 해결책은 달라질 수 있다. 또한 각 방법들의 특징을 살펴볼 때 모든 경우에 가장 적합한 최선의 해결책은 존재하기 어렵다. 따라서 소프트웨어 개발에서는 최선의 해결책이 아니라 최적의 해결책을 찾을려고 하는 것이다.

그렇다면 우리는 왜 소프트웨어를 개발할 때 최적의 해결책을 지향하는가?

무엇보다도 최적의 해결책은 소프트웨어를 개발하려는 목적을 가장 잘 수행해줄 수 있기 때문이다. 여기서 소프트웨어를 개발하려는 목적은 표면적이고 추상적인 것이 아니라, 최대한 구체화되고 세분화된 목적을 가리킨다.

예를 들어 “Hello World !” 문자열을 출력하기 위한 여러 방법들은 모두 “Hello World !” 문자열을 출력하려는 목적을 수행할 수 있다. 그러나 목적이 보다 구체화되어 임의의 문자열을 출력할 수 있어야 하고, 출력할 문자열의 라인이나 길이에 제한이 없도록 하려면 위에서 언급된 방식들 중 특정 파일에 저장된 문자열을 출력해주는 방식만이 원하는 목적을 수행할 수 있다. 따라서 이 경우에는 파일에 저장된 문자열을 출력해주는 방식이 최적의 해결책인 것이다.

최적의 해결책을 지향하는 또 다른 이유는 구체적인 상황이나 환경에 맞추어 최소의 비용으로 최대의 효과를 보기 위해서이다. 즉 우리는 최적의 해결책을 통해 저비용 고효율을 달성하려고 하는 것이다. 여기서 주의해야 할 것은 비용이나 효율성을 따질 때 개발 시의 비용과 효율만을 고려할 것이 아니라, 소프트웨어가 실행될 때와 새로운 요구사항으로 인해 수정, 보완될 때의 비용이나 효율성도 같이 생각해야 한다는 점이다. 따라서 개발만 빨리 끝낼 수 있다고 최적의 해결책은 아니며, 실행 시간이 단축된다고 해서 최적의 해결책이 되는 것도 아니라는 점이다. 결국 최소 비용, 최고 효율의 해결책이 되기 위해서는 소프트웨어의 개발, 실행, 유지, 보수 작업에 따르는 비용과 비중을 종합적으로 고려하여야 한다는 것이다.

예를 들어 “Hello World !” 문자열을 출력하는 방법 중 [소스 1-1]은 개발 비용이 가장 적게 들고, 실행 시에도 출력할 문자열을 입력받는 데 소요되는 시간이 없으므로 실행 속도 또한 빠른 방법이다. 그러나 이 방식은 개발이 끝난 다음에 임의의 문자열을 출력할 수 있게 변경 요청이 발생한다면 처음부터 다시 소프트웨어를 개발해야 하는 비용이 발생할 수 있다.

이 같은 경우 [소스 1-1] 방식은 최소 비용, 최고 효율을 달성하는 해결책인가?

이에 대한 대답은 주어진 문제의 원래 목적이 어디에 더 큰 비중을 두고 있었느냐에 달렸다. 즉 원래 목적이 빨리 개발해서 프로그램이 제대로 실행되는 지 여부만을 확인하고자 한 것이었다면 당연히 개발과 실행에 대한 비중이 클 것이고, [소스 1-1] 방식은 이 부분에서 최소 비용, 최고 효율을 보장해준다. 버려질 프로토타입(Throwaway Prototype)을 개발할 경우가 주로 이 같은 예에 속한다고 할 수 있다. 반면, 개발된 소프트웨어를 장기적으로 운영하면서 추가, 변경되는 요구 사항을 수용해줄 목적이라면 [소스 1-1]과 같은 방식은 최소 비용, 최고 효율에 해당하는 해결책은 아닐 것이다. 왜냐하면 이 경우에는 유지, 보수 비용을 줄이는 것이 개발이나 실행 비용 못지 않게 비중이 클 것이기 때문이다.

이처럼 최적의 해결책을 지향하는 이유는 명백하다. 그렇다면 우리는 어떻게 최적의 해결책을 만들어낼 수 있을까?


1.4. What-Why-How 생각 모델

소프트웨어 개발이 추상화(Abstraction) 레벨을 구체화시켜나가면서 무엇을(What) 어떻게(How) 할 지를 반복해나가는 과정이라는 것은 독자 여러분도 이미 잘 알고 있을 것이다. 즉 무엇을 개발할 것인지, 그것을 어떻게 개발할 것인지를 반복하여 구체화시켜나가게 되면 소프트웨어 개발이 이루어진다는 의미다.

예를 들어 앞서의 “Hello World !” 문자열 출력 문제의 경우, 추상화 레벨 0 단계에서 무엇(What)에 해당하는 것은 “Hello World !” 문자열을 출력한다는 것이 될 것이다. 그리고 이 단계에서 어떻게(How)에 해당하는 부분은 파일로부터 “Hello World !” 문자열을 입력받아서 그것을 다시 출력하게 한다와 같은 방법을 선택할 수 있을 것이다. 그러면 추상화 레벨 0 단계의 어떻게(How)에 해당하는 부분은 다시 추상화 레벨 1 단계에서는 무엇(What)이 되고, 추상화 레벨 1 단계의 어떻게(How) 부분은 파일에서 어떻게 문자열을 입력받을 것인지, 입력받은 문자열은 어디에 저장할 것인지, 저장된 문자열을 어떻게 출력할 것인지와 같이 정의될 수 있을 것이다.

이처럼 추상화 레벨을 점차 구체화하면서 What-How를 정의하는 것을 반복해서 최종적으로 어떻게(How) 부분을 충분히 구체화시키게 되면 해결책을 만들 수 있다는 게 일반적인 What-How 생각 모델(Thinking Model)이다. 그러나 이 방법만으로는 해결책은 만들 수 있지만, 최적의 해결책을 만들어낼 수 없다고 저자는 생각한다. 왜냐하면 무엇(What)과 어떻게(How)에 대해 그것이 최적인지 아닌지에 대한 검증이 없기 때문이다.

이런 점들을 감안하여 저자는 소프트웨어를 개발하는데 있어 최적의 해결책을 만들어낼 수 있는 생각 모델(Thinking Model)로 [그림 1-2]의 What-Why-How 생각 모델을 제안하고자 한다.



[그림 1-2]의 What-Why-How 생각 모델에서 저자가 강조하고 싶은 것은 무엇(What)이나 어떻게(How)보다도 왜(Why)에 해당하는 것이다. 즉, 무엇(What)을 해야 하는가도 중요하지만, 왜(Why) 그것을 해야 하는가가 더 중요하다는 것이며, 어떻게(How) 할 것인가도 중요하지만, 왜(Why) 그렇게 해야 하는가가 더 중요하다는 의미다. 이때 ‘왜 그것을 해야 하는가’에 대한 검증 기준은 원하는 목적(Goal)이 무엇인가가 될 것이며, ‘왜 그렇게 해야 하는가’에 대한 검증 기준은 어떤 것이 최적(Optimization)의 방법인가가 될 것이다.

여기서 목적(Goal)이나 최적(Optimization)이란 부분은 지금까지의 설명에서도 언급했듯이 단순히 겉으로 드러난 것만을 기준으로 해서는 안되며, 주어진 상황이나 환경, 스케쥴이나 전략, 가용한 자원이나 예산, 상충하는 목적들간의 우선순위, 향후 유지보수나 스펙 확장 또는 재개발 계획 등등을 종합적으로 고려한 것이어야 할 것이다.

예를 들어 “Hello World !” 문자열을 출력하는 문제에서 개발 비용을 줄이고 빨리 결과를 보여주는 게 목적이냐, 향후 유지, 보수가 용이하게 개발하는 것이 목적이냐와 같은 질문이 바로 “Hello World !” 문자열을 출력하겠다는 무엇(What)을 검증하기 위한 구체적인 목적(Goal)이 될 것이다. 또한 이런 구체적인 목적에 따라 어떤 방식을 선택하는 것이 목적에도 잘 부합하면서 최소 비용으로 최고의 효율을 올릴 수 있는가하는 것이 바로 어떻게(How)를 검증하기 위한 구체적인 최적(Optimization)의 기준이 될 것이다.

이처럼 What-Why-How 생각 모델은 기존의 What-How 생각 모델에 왜(Why)라는 질문과 함께 구체적으로 무엇(What)과 어떻게(How)를 검증하기 위한 목적(Goal)과 최적(Optimization)이라는 기준을 제시하고 있으므로, 소프트웨어 개발에서 우리가 목적으로 하는 최적의 해결책을 만들어내기 위한 가장 기본적인 원칙이 될 것이다.

저자가 이처럼 What-Why-How 생각 모델을 맨 처음 제시하고, 강조하는 이유는 이러한 생각을 바탕으로 이 책에서 다룰 디자인 패턴들을 분석하고 이해해야지만 실전에서 문제가 주어졌을 때 이 책에서 제시하는 디자인 패턴들을 활용할 수 있고, 더 나아가 새로운 디자인 패턴들을 창조해낼 수 있다고 믿기 때문이다.

예를 들어 단 하나의 디자인 패턴을 읽더라도 어떤 종류의 문제를 풀기 위한 것이고, 그 문제는 어떤 목적을 달성하기 위한 것이며, 문제를 해결하기 위한 방법에는 어떤 것들이 있을 수 있는 지를 왜(Why)라는 질문을 지속적으로 던지면서 따져보고 이해하는 사람과 그냥 해당 패턴의 클래스 구조와 객체간의 관계, 동작 방식만을 이해하고 외우는 사람간에는 실전에서 디자인 패턴의 활용도가 천양지차일 것이다. 왜냐하면 실전에서 주어지는 문제는 이 책에서 각각의 디자인 패턴을 설명하기 위해 제시하는 문제와는 구체적인 목적이나 상황, 환경 등이 많이 다를 수 있는데 그냥 책에서 제시하는 패턴만 외워서 적용하기에는 쉽지 않을 것이기 때문이다.

따라서 저자는 독자 여러분이 이 책을 읽는 동안 What-Why-How 생각 모델을 늘 염두에 두고 각각의 디자인 패턴들을 살펴보게 되기를 바란다. 이를 돕기 위해 이 책에서는 각 패턴이 해결하고자 하는 문제와 그 구체적인 목적을 먼저 설명하고, 여러 가지 적용 가능한 방법들을 생각해본 다음 각 방식의 문제점들을 언급하고, 최적의 해결 방법으로 디자인 패턴 설계를 이끌어내는 형태로 내용을 설명할 것이다. 이 같은 책의 구성은 독자 여러분들을 보다 많이 생각하게 만들어줄 것이며, 이를 통해 여러분은 보다 빨리 디자인 패턴을 이해하고 더 나아가 실전에서 원활히 활용할 수 있게 될 것이다.

http://network.hanbitbook.co.kr/view.php?bi_id=960