프레임 워크

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

GoF의 디자인 패턴으로 유명한 랄프 존슨(Ralph Johnson) 교수는 프레임워크를

"소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔

일련의 협업화된 형태로 클래스들을 제공하는 것"

이라고 정의하였다.

프레임워크는 라이브러리와 달리 애플리케이션의 틀과 구조를 결정할 뿐 아니라,

그 위에 개발된 개발자의 코드를 제어한다.

프레임워크는 구체적이며 확장 가능한 기반 코드를 가지고 있으며,

설계자가 의도하는 여러 디자인 패턴의 집합으로 구성되어 있다.

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

아, 저 말이 바로 이해가 간다면 굳이 다음 글을 읽을 필요는 없다.

이 글은 저 말을 이해하지 못하는 사람들 (나 자신을 포함하여) 을 위해

같은 이야기를 길게 풀어놓은 것에 불과하니까 말이다.

그런 분은 그냥 조용히 뒤로 가기 버튼을 눌러 주시거나,

가볍게 읽으시고 이 글에 잘못된 점이나 미비한 부분을 바로 잡아주셔도 된다.

위에서 프레임 워크와 라이브러리를 비교한 글귀를 찾을 수 있듯이,

 

일단 프레임 워크를 라이브러리의 연장선상에서 생각하는 것으로

프레임워크에 대한 이해를 시작해 보자.

라이브러리의 정의는 다들 대강은 알다시피

자주 쓰일 만한 기능들을 모아 놓은 유틸 (클래스)들의 모음집 정도로 정의할 수 있겠다.

(이 과제를 내준 형의 말대로)

사용자(프로그래머)와 실제 구현하고자 하는 기능 사이에,

사용자로 하여금 구현하고자 하는 기능을 쉽게 쉽게 제공해주는 중간 계층이란 면에 있어서

라이브러리와 프레임 워크는 일견 비슷한 점이 있다.

음.. 그렇다면 그냥 라이브러리라고 부르면 되지 거창하게 프레임 워크로 구분지어 부를 필요는 뭐냐?

대체 차이가 뭐냐? 라는 질문이 나올 법 하다.

  

프레임 워크와 라이브러리의 가장 큰 차이점이라 할만 한건

프레임 워크에는 라이브러리에

뼈대가 되는 클래스들과 그 클래스들의 관계로 만들어진

일종의 '설계의 기본 틀'이 추가된다는 점일 것이다.

여기서 쓴 혹은 설계 틀이란 말은

물론 위의 정의에서 나온 '확장 가능한 기반코드'라든지, '재사용 가능한 형태의 협업화된 클래스들' 이라는 말과 같은 뜻이다. 

자, 우선 라이브러리부터 생각 해보자.

라이브러리가 아무리 날고 기어봤자 라이브러리는 라이브러리다.

라이브러리가 설계를 대신해주진 않는다.

뭔 말이냐면, 라이브러리는 그저 프로그래머가 프로그램을 짜다가

'아, 요럴 땐 라이브러리에서 이런 기능을 뽑아다 쓰면 되겠구나'

라는 생각이 들었을 때, 그때 그때 필요한 걸 가져다 쓰는 대상이지

라이브러리가 그 기능을 쓰기 위해 필요한(혹은 효율적인)

구조에 대해 말해주지는 않는다는 뜻이다.

  

따라서, 동일한 라이브러리를 쓰는 동일한 기능의 프로그램일지라도

클래스 관계 구조나, 데이터를 처리하는 절차라든지,

프로그램이 화면에 그려지는 방식 같은 등등의 요소들은 

프로그램을 짜는 프로그래머마다 천차만별 일수 밖에 없으며

프로그램을 완성하는 데에 걸리는 시간도, 완성된 코드의 품질도

프로그래머의 역량에 따라 제각각일 것이다.

이제 프레임워크를 보자.

보통 프레임워크엔 프레임 워크의 제작자가 '이걸 기초로 해서 만드세염' 이라고

지가 만들어 놓은 '기반 코드'가 있다.

물론 이 코드, 혹은 클래스들은

차후 사용자들에 의해 확장될 것을 충분히 고려해서 만들어졌기 때문에

사용자 입장에서는 그저 이 것을 가지고,

여기 저기를 자기 입맛대로 바꾸고

살을 덧붙여 자기만의 프로그램을 완성해 나가면 되는 것이다.

왜, 비주얼 스튜디오를 켜서 새 MFC 프로젝트를 열고

다이알로그 기반 -> 확인 만 눌러도

일단 기본적으로 돌아가는 다이알로그 박스가 완성되고,

사용자가 만약 여기다 그리기 기능을 추가하고 싶다, 하면

상속 받은 클래스에 OnPaint() 함수를 재정의해서

단순히 함수 몸체 안에 코드를 쳐 넣기만 하면 되는 것처럼 말이다.

이러한 샘플, 즉 '확장 가능한 기반 코드'에는

프레임 워크 제작자 나름대로의 설계 철학이 담겨 있으며,

차후 이 프레임 워크의 사용자가

제작자가 설계한 구조를 유지하면서 확장할 수 있도록,

제작자에 의해 의도된 제약 사항이 존재한다.

아까 그 사용자가

OnPaint() 외에 다른 방식으로 그리기 구현을 해보고 싶다거나

혹시라도 OnPaint()가 호출되는 시점을 

자신이 통째로 제어해보고 싶다던지 하는 금지된 욕망을 가지게 되면 

프로그램 짜기가 상당히 껄쩍지근해 지는 것처럼 말이다.

(물론 불가능한 것은 아니며, 또 꼭 필요할 경우도 있기는 하지만,

이는 프레임워크를 사용할 때의 장점인 신뢰성과 비용 절감을 떨어뜨릴 수 있는 요소이다.)

이런 식으로 사용자에게 가해지는 제약 사항은

(특히 그 제약 규칙이 구조에 대한 것일 경우)

흔히 디자인 패턴을 구현한 코드의 형태로 표현되는데,

이 중 가장 흔하고 쉽게 찾아 볼 수 있는 예가 MVC 패턴이다.

MFC의 SDI(단일 문서 프로젝트)를 열어보면

처음부터 C~~~View와 C~~~Document의 두 클래스가 생기는 걸 볼 수 있는데

이 것은 이 프레임워크의 제작자가

MVC 패턴을 구현한 클래스인 CView와 CDocument를 기반 코드로 제공함으로써

자기가 만든 프레임 워크를 사용하여 만들어지는 프로그램들은

(MVC 패턴을 쓰는 이유인) '데이터의 연산 과 '데이터의 표현'이 서로 분리 되어야 한다는 것을

사용자에게 명시한 것이라고 보면 되는 것이다.

결론적으로 기반 코드는

프레임웍 제작자가 사용자들로 하여금

세세하게 신경 쓰지 않아도 쉽고 빠르게 기능을 확장하거나 유지보수할 수 있게 해주는 

구조에 대한 가이드라인 이나,

혹은 함부로 건들 경우 프로그램이 자칫 '신비롭게' 동작할 수 있기 때문에

제약을 가하고 싶은 사항 등을

여러 디자인 패턴을 조합해 표현해 놓은 결과라고 보면 된다. 

이 말은 다른 클래스의 부모가 되는 베이스 클래스를 짜본 경험이 있다면

쉽게 이해 할 수 있을 것이다.

다른 클래스들의 기초가 되는 기반 클래스의

각 멤버의 캡슐화 정도,

멤버의 상수화 여부,

다른 클래스들과의 관계,

함수 멤버의 가상화 여부 같은

만들 땐 별거 아닌거 같았던 자잘한 요소들이

후에 말단에서 실제로 사용되는 클래스들의 구현에 지대한 영향을 미치기 때문이다.

별 생각 없이 기반 구조를 짰다가

나중에 말단 클래스에서

어떤 기능을 구현하기가 참으로 난감한 경우가 생겨

기반 구조를 첨부터 다시 뜯어 고쳐야 했던 경험이 다들 한 번쯤은 있을 것이다.

여튼, 얘기가 약간 곁가지를 탄 느낌이 있는데 정리하자면

프레임 워크란

설계의 기반이 되는 부분을 기술한  확장 가능한 기반 코드와

사용자가 이 코드를 자기 입맛대로 확장하는 데 필요한 라이브러리

이 두 가지 요소가 통합되어 제공되는 형태를 말하며,

사용자가 이를 이용해

일정 수준 이상의 품질을 보장받는 코드를, 비교적 빠른 시간에 완성 및 유지 보수할 수 있는

환경을 제공해주는 솔루션으로

"기본적인 설계나 필요한 라이브러리는 알아서 제공해 줄꺼니깐

넌 그냥 니가 진짜로 하고 싶은 기능 구현에만 전념해!"

라는 취지에서 만들어진 물건이란 것이다.

출처 - http://blog.naver.com/PostView.nhn?blogId=sleepy1027&logNo=150085034164