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

라이브러리(Library)의 정의는 간단하다. 자주 쓸만한 로직을 잘 갖춰놓고 필요할때마다 가져다 쓰는 유틸리티 클래스들의 모음이다. 그런데 디자인패턴을 정의하려면 말문이 막혀서 터지지 않는다. 대략의 뜻은 알고있고 써먹을줄도 알지만 명확한 정의에 대해서는 생각이 잘 떠오르지 않는다.

그럴수록 좀더 생각을 하면서 단어의 뜻을 따라가보았다. 디자인이란 말은 설계란 뜻이다. 패턴은 일종의 정형화된 해결 방법이다. 이 두 단어를 연결하여 맞춰보면 ‘일종의 정형화된 객체 설계 솔루션 방법들의 모음’이라 정리 할 수 있다. 연결해보니 맞아떨어진다.

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

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

여기서 중요한 것은 디자인패턴은 라이브러리처럼 미리 구현된 로직들의 모음이 아니다. 객체를 미리 제시된 패턴에 맞게 해결하는 방법을 제시하지만, 이 디자인을 어플리케이션에 맞게 적용하는 것은 객체지향 개발자들의 역량에 달려있다. 마치 라이브러리가 여행 가이드가 이끌어주는 정해진 여행 일정이라면 디자인패턴은 대략의 여행패턴은 여행사에서 제시하지만 나머지는 여행자가 알아서 하는 배낭여행과 같다.


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

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

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

프레임워크를 쓰는 개발자가 프레임워크에서 주어지는 알고리즘 틀의 규칙을 준수해야 할때 필요한 유틸리티 로직이나 기반 클래스는 미리 프레임워크에서 구비해놓고 있다. 그래서 필요할때 개발자에게 적시적소에 제공할 것이다.

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

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


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



산골이 덧) 이 글은 수필 객체지향이라는 책쓰기용 원고의 일부라서 펌은 불허합니다. 이 글의 원고는 1차로 쓴것을 그대로 올려서 다듬어지지 않았습니다. 못써도 이해해주시고요. 지금 올리는 것은 공부한것을 독자와 공유하고 객체지향 개발자님의 조언을 받기 위해서입니다. 혹시 내공이 부족해서 미흡한 내용이 있을것 같습니다. 그래서 혹시 시간되시면 조언 부탁드립니다. ^ ^;

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 산골
산골 블로그 소개 저는 하얀머리 개발자와 작가를 꿈꾸는 블로거 산골 입니다. 프로그램 개발자로서 저의 관심사는 개발자의 숨통을 트여준 아이폰 개발, 철학과 같은 깊이가 있는 객체지향 방법론입니다. 글쓰기와 수영을 좋아합니다. 블로그를 통해 관심사를 공유합니다. 제 블로그에 관심 있으시면 아래 RSS나 즐겨찾기로 편하게 구독하세요.

rss Bookmark and Share

댓글을 달아 주세요

  1. 2009.07.02 12:45  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • BlogIcon 산골 2009.07.03 10:27 신고  댓글주소  수정/삭제

      앗 조언 감사합니다.
      비밀님의 말씀을 정리하면

      라이브러리도 프레임워크처럼 개발자가 주어진 틀과 규칙을
      따라야 한다. 다만 라이브러리와 프레임워크의 차이는
      제어흐름에 달려있다. 라이브러리는 제어흐름의 작성이
      개발자에게 있지만 프레임워크는 제어 흐름을 책임지고,
      개발자가 그 제어의 흐름에 자신의 로직을 끼어넣는 형태가
      된다.

      는 말씀이시군요. 저는 라이브러리를 생각하길
      단순한 유틸리티 로직들 있잖아요..거외 숫자에
      콤마 넣어주는 이런 단순한 유틸리티 로직들만
      생각했는데 보편적인 라이브러리에는 이런 유틸리티
      로직보다 더 크게 정의를 잡아야 되는거군요.

      특히 제어흐름의 차이가 라이브러리와 프레임워크
      의 차이라는것은 무릎을 딱치며 알게되었습니다.

      다음에 원고수정할때 참고하겠습니다~!

      아참..비밀님이 누구신지 알것같아요..이글루스의
      유명한 아이티블로거신데..왜 블로그를 정리하셨나요 @@;
      다시 살려주세요~ ^ ^;

  2. 2009.07.02 12:46  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • BlogIcon 산골 2009.07.03 10:27 신고  댓글주소  수정/삭제

      어이쿠..죄송하면서..정성에 감사드립니다..
      하지만 저는 좀 강하게 펌을 막는 편이라서요..에고..
      죄송합니다. ^ ^;

  3. 2009.07.03 12:13  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • BlogIcon 산골 2009.07.05 22:04 신고  댓글주소  수정/삭제

      예 생각하신 분이 맞습니다. ^ ^
      다시 돌아오셨으면 좋겠어요..
      주말은 잘 보내셨는지..
      계속 관심가져 주셔서 고맙습니다. ^ ^

  4. 2009.07.05 23:01  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • BlogIcon 산골 2009.07.07 09:48 신고  댓글주소  수정/삭제

      오늘 만나뵈러 갑니다.
      비밀님도 꼭 개인적으로 뵙고 싶습니다.
      부담은 되지만..끝까지 지구력을 갖고 열심히 할꺼고요~
      저도 도움드릴 일이 있었으면 합니다.
      항상 감사드립니다. ^ ^