한빛출판네트워크

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

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

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

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

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

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


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

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

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

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

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


[표 1-1] 구조적 개념이나 철학 또는 객체지향 개념이나 철학과의 비교



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

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

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

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

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

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

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


1.2. 소프트웨어 개발 과정

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

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



[그림 1-1] 일반적인 소프트웨어 개발 과정


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


[표 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 생각 모델(Thinking Model)


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