객체지향의 탄생- 디자인패턴과 프레임워크, 그리고 라이브러리

 

1. 디자인패턴과 프레임워크, 그리고 라이브러리

디자인패턴(Design Pattern)이 무엇이고 프레임워크(Framework)가 무엇이고 라이브러리(Library)도 있는데, 이 둘의 차이가 무엇이냐는 질문은 객체지향 개발이 무엇이냐는 질문처럼 나를 바보로 만든다. 하지만 명색이 제대로 된 객체지향 개발자를 꿈꾼다면, 이 셋의 실체를 알아내는 것이 두렵다고 해서 이 들의 추적을 중단해서는 안될것이다.

 

 

먼저 디자인패턴부터 그 정의의 실체를 추적했다. 디자인패턴 같은 경우 대략의 뜻은 알고있고 써먹을줄도 알지만 명확한 정의에 대해서는 생각이 잘 떠오르지 않았다. 그럴수록 좀더 생각을 하면서 단어의 뜻을 따라가 보았다. 디자인이란 말은 설계란 뜻이다. 패턴은 일종의 정형화된 해결 방법이다. 이 두 단어를 연결하여 맞춰보면 '일종의 정형화된 객체 설계 방법들의 모음'이라 정리 할 수 있다. 연결해보니 맞아떨어진다.

 

객체지향 프로그래밍을 하다보면 특정한 설계영역에서 자주 나타나는 문제가 있고 이것을 해결하는 정형화된 해결 방법이 객체지향 프로그래밍의 고수이자 선각자들에 의해 발견되었다. 예를들어 상속 구조만 사용했더니, 상위 클래스의 메소드를 써먹기 위해 상속의 의미가 통하지 않음에도 억지로 상속받아서 뭔가 의도와 어긋난 경우가 있다. 그런데 이 경우 구성 구조로 캡슐화한 결과 좀더 깔끔하게 구현이 가능했다. 이런 경우를 정리했더니 스트라테지 패턴(Strategy Pattern)으로 이름지어 패턴화할 수 있겠더라. 등의 발견이 지속적으로 이루어 졌을 것이다.

 

그래서 다시 디자인패턴을 그럴듯 하게 정리하면 '특정한 객체지향 개발 영역에서 자주 발생되는 설계 구현 문제에 대하여, 유연하고 확장성 높은 객체지향적 설계 패턴으로 해결하는 방법들의 모음' 이라 정의할 수 있다.

 

여기서 중요한 것은 디자인패턴은 여러 소프트웨어 개발 이슈에 대하여 미리 패턴을 구성하고 해결하는 방법을 제시하지만, 이 디자인을 어플리케이션에 맞게 적용하는 것은 객체지향 개발자들의 역량에 달려있다. 마치 대략의 여행패턴은 여행사에서 제시하지만 나머지는 여행자가 알아서 하는 배낭여행과 비슷하다.

 

 

라이브러리(Library)의 정의는 간단하다. 자주 쓸만한 로직을 잘 갖춰놓고 필요할 때마다 가져다 쓰는 유틸리티 클래스들의 모음이다. 나의 라이브러리 정의를 놓고 고수 개발자가 그건 아니라고 조언을 해주었다. 라이브러리가 유틸리티 클래스들의 모음(=기능 제공)이라고 한것은 라이브러리의 일부분만 정의한 것이다. 라이브러리는 기능 제공 외에도 '정해진 틀'을 따라야할 의무가 생길수도 있다.

 

예를들어 C언어에서 TCP/IP 프로그래밍을 한다면 TCP/IP 라이브러리를 이용 해야 한다. create(), bind(), accept(), listen() 등의 라이브러리 함수를 이용하는데, 이때 꼭 정해진 순서와 틀을 따라야 한다. 또한 정해진 순서와 틀이라는 '제어 흐름'의 작성은 개발자 자신이 해야 한다. 그래서 라이브러리는 자주 쓸만한 로직을 미리 구성하였으며, 이 로직은 셋트로 사용할때 정해진 제어 흐름을 따라야 할수도 있는데, 이때 제어 흐름의 작성은 개발자 자신이 해야 한다.

 

 

프레임워크는 더 정의하기 어려웠다. 디자인패턴은 설계방법만의 모음이기 때문에 라이브러리와의 차이점이 명확했는데 프레임워크는 설계요소가 들어가면서도 라이브러리 요소가 들어가기 때문에 애매모호한 회색같은 실체였다.

 

하지만 이 푸념에서 찾을수 있는 단서는 프레임워크는 디자인 패턴 요소도 들어가고 라이브러리 요소도 포함되었다는 것이다. 여기서 그 실체를 쫓아보기로 했다.

 

프레임워크는 디자인 패턴의 결합과 설계자의 독자적인 설계 끝에 업무 구현에 적당한 '제어흐름'을 구성한다. 그러면 개발자가 이 '제어흐름'에 주어진 규칙을 저절로 지키게끔 강제한다. 그래서 프레임워크 설계자가 의도한 어플리케이션을 쉽고 편하게 작성할수 있게 이끌어 줄 것이다.

 

프레임워크를 쓰는 개발자가 프레임워크에서 주어지는 '제어흐름' 을 지키면서 기타 필요한 유틸리티 로직이나 기반 클래스는 미리 프레임워크에서 구비해놓고 있다. 그래서 필요할때 개발자에게 적시적소에 제공할 것이다.

 

 

이 사실을 바탕으로 다시 정리하면, 프레임워크는 디자인 패턴의 결합과 설계자의 독자적인 설계 끝에 요구사항에 알맞는 '제어흐름'을 만든다. 프레임워크는 개발자가 이 '제어흐름'을 지킬때 설계자, 개발자 모두가 원하는 어플리케이션을 쉽게 작성할수 있게 도와준다. 이때 프레임워크는 개발자가 '제어흐름'을 지킬때 필요한 유틸리티 로직이나 기반 클래스들을 미리 구비하여 개발자에게 제공한다.

 

프레임워크와 디자인패턴과의 차이는, 디자인패턴은 설계단계에서 필요한 기술이기 때문에 어플리케이션 알고리즘의 뼈대 구축도 개발자의 몫이다. 그러나 프레임워크는 이미 디자인패턴등을 이용하여 어플리케이션 알고리즘의 뼈대도 구축한 상태이다. 프레임워크는 개발자가 구축한 객체 구성 뼈대를 바탕으로 코딩할것을 강제하고 있어서 좀더 구현단계와 관련있는 기술이라 정의할 수 있다.

 

프레임워크와 라이브러리의 차이는, 제어흐름에 있다. 프레임워크나 라이브러리나 개발자가 수월하게 개발할 수 있도록 다양한 로직들을 구성해 놓았다. 라이브러리 같은 경우 이 로직들은 독립적으로 작동할수 있지만 TCP/IP 라이브러리처럼 정해진 틀을 꼭 따라야 제대로 작동하는 경우도 있다. 다만 라이브러리는 '제어흐름'을 정의하진 않고 '로직'만 정의하였기 때문에 제어흐름을 개발자가 작성한다. 프레임워크는 '로직'도 구성해 놓았고 '제어흐름'도 구성해 놓았다. 그래서 개발자는 정해진 '제어흐름'에 정해진 '로직'을 사용한다. 프레임워크는 '제어흐름'도 구성하기 때문에 이 작업때 '디자인패턴'등의 설계 기술을 사용하여 제어흐름을 구축하는 것이다. 그래서 프레임워크는 제어흐름과 주어진 로직으로 개발자가 설계자 의도대로 자연스럽게 코딩할수 있도록 통제하는 효과를 크게 얻을 수 있을 것이다.

 

 

프레임워크는 디자인패턴의 결합끝에 공통으로 추상화 할 수 있는 제어흐름의 뼈대를 구축해 놓았고, 개발자가 프레임워크를 사용할때 필요한 라이브러리를 미리 작성해 놓았다. 그래서 프레임워크는 디자인 패턴들의 결합과 라이브러리 개발 끝에 탄생한, '개발자가 주어진 제어흐름을 지키고 주어진 로직을 잘 활용할때 원하는 어플리케이션을 쉽게 작성하도록 도와주는 솔루션'이다.

 

[교통 인프라로 생각해보면, 라이브러리는 교통 인프라 구축에 필요한 구성요소들이다. 디자인 패턴은 인프라 구축을 효과적으로 하기 위해 미리 설계해 놓은 도로 종류와 같은 설계 패턴이다. 프레임워크는 라이브러리와 디자인 패턴을 잘 결합시킨 어느 솔루션의 인프라와 같다.]

 

덧 ) 이 객체지향의 탄생 원고는 제가 책으로 내려다가 일단 잘 안되었는데요. 이유는 비문이 많다. 단락내 주제가 중복된다. 어떤 상황 설명을 과장한다.등 입니다. 그래도 원고를 일단 블로그에 몽땅 풀어보고 언젠가 제대로 교정해서 다시 도전할 생각입니다. 이점을 감안해서 읽고 객체지향을 이해하는데 도움이 되셨으면 좋겠습니다. 의견도 주셨으면 좋겠습니다. 원고 조금만 교정하면 괜찮을것 같은 출판사 관계자분의 피드백도 환영합니다. 매주 월요일 발행 예정입니다.