프레임워크 (FrameWork) ?

좀더 이해하기 쉬운 문서 프레임워크란.pdf

프레임워크 vs 라이브러리

프레임워크의 가장 대표적인 특징 중 하나는 그 안에 클래스 라이브러리를 가지고 있다는 것이다. 혹자는 프레임워크를 반제품이라고 설명하기도 한다. 개발해야 할 애플리케이션의 일부분이 이미 만들어져 있다는 뜻이다. 프레임워크를 이용한 개발은 결국 그 기반이 되는 이미 존재하는 부분을 확장하고 이용하는 것이라고 볼 수 있다. 윈도우즈 환경의 대표적인 GUI 애플리케이션 프레임워크인 마이크로소프트의 MFC(Microsoft Foundation Classes)와 볼랜드의 OWL(Object Windows Library)는 그 이름 그대로 클래스 라이브러리로 구성되어있다. 자바기반의 대표적인 애플리케이션 프레임워크인 스프링프레임워크는 수 천 개의 클래스기반 API 라이브러리를 포함하고 있다. 또 .NET 프레임워크는 CLR, ASP.NET과 함께 프레임워크 클래스 라이브러리가 그 핵심구성요소이다. 이렇듯 프레임워크는 라이브러리와 유사하게 생각할 수도 있다.

하지만 프레임워크는 라이브러리와는 분명히 다르다. 그 차이는 프레임워크를 사용하는 사용자코드와 라이브러리를 사용하는 코드를 비교해보면 쉽게 알 수 있다.
  프레임워크는 주로 프레임워크 쪽에서 사용자의 코드를 호출하는 구조로 동작한다. 즉 실행의 흐름에 대한 제어를 프레임워크가 담당하게 된다. 많은 프레임워크는 템플릿 메소드 패턴 기반으로 만들어진 클래스를 서브 클래싱해서 사용하도록 되어있다. 결과적으로 사용자의 코드는 프레임워크 클래스에 이미 설계되어있는 흐름구조에 따라 동작하게 된다. 그래서 프레임워크의 동작원리는 그 제어흐름이 일반적인 프로그램 흐름과 반대로 동작한다고 해서 IoC(Inversion of Control)이라고 설명하기도 한다. 반면 라이브러리는 유저의 코드가 라이브러리를 호출해서 사용하는 구조로 되어있다. 즉 코드의 흐름을 유저코드가 관장하고 있는 것이다. 또 프레임워크는 오브젝트간의 연동구조를 미리 정의하고 있다. 이렇듯 같은 클래스 라이브러리이지만 프레임워크와 라이브러리는 그 것을 사용하는 유저코드의 작성방식이 판이하게 다르다.

프레임워크 vs 디자인 패턴
프레임워크는 애플리케이션의 구조와 디자인을 결정하는 요소를 가지고 있다. 디자인 패턴과 마찬가지로 프레임워크는 반복적으로 발견되는 문제를 해결하기 위한 특화된 솔루션이라고 이해할 수 있다. 구조적인(architectural) 디자인 패턴인 MVC 패턴 (Model-View-Controller Pattern) 기반의 애플리케이션을 손쉽게 만들 수 있도록 설계되어있는 대표적인 프레임워크가 스트럿트 프레임워크이다. 스트럿트는 GUI기반의 MVC 패턴을 웹 애플리케이션 개발에 적용할 수 있는 더 특화된 구조적 패턴을 가지고 있다. 테스팅 프레임워크의 대표 격인 xUnit 프레임워크들은 커맨드패턴과 콤포짓 패턴으로 설계되어있다. 따라서 그 프레임워크를 기반으로 만드는 애플리케이션의 구조도 자연스럽게 이 두 가지 패턴의 영향을 받게 된다.

디자인 패턴은 프레임워크의 핵심적인 특징이고 프레임워크를 사용하는 애플리케이션에 그 패턴이 적용된다는 특징을 가지고 있다. 하지만 프레임워크는 디자인 패턴이 아니다. 디자인 패턴은 애플리케이션을 설계할 때 필요한 구조적인 가이드라인이 되어 줄 수는 있지만 구체적으로 구현된 기반코드를 제공하지 않는다. 그 패턴을 어떤 식으로 적용하고 어떤 클래스로 만들 것인가는 그 패턴을 사용하는 개발자의 책임이다. 하지만 프레임워크는 디자인 패턴과 함께 그 것이 적용 되어진 기반 클래스 라이브러리를 제공해서 프레임워크를 사용하는 구조적인 틀과 구현코드를 함께 제공한다. 결국 개발자는 프레임워크의 기반코드를 확장하여 사용하면서 자연스럽게 그 프레임워크의 패턴을 적용하게 된다.

 프레임워크 = 디자인 패턴 + 라이브러리
프레임워크는 이렇게 디자인 패턴과 그것이 적용된 기반 라이브러리의 결합으로 이해할 수 있다. 이 두 가지가 프레임워크의 모든 특징을 다 설명해줄 수는 없다 하더라도 이 두 가지 관점에서 프레임워크를 관찰하는 것은 프레임워크를 이해하는 좋은 출발점은 될 수 있다. 때론 자신이 사용하고 있는 프레임워크에 적용된 패턴이 어떤 것인지 의식하지 않고 개발할 수 도 있다. 하지만 그 패턴을 이해하는 것은 프레임워크 기반의 개발이 잘못된 방향으로 나아가지 않도록 해주는 가이드라인이 되어 줄 수 있다. 또 프레임워크의 라이브러리를 살펴볼 때도 그 적용된 패턴을 주목해서 살펴본다면 그 구성을 이해하기가 매우 쉽다. 특히 프레임워크를 확장하거나 커스터마이징 할 때는 프레임워크의 패턴에 대한 이해가 꼭 필요하다.

 

프레임워크 활용의 지름길
라이브러리에 대한 분석과 이해도 매우 중요하다. 많은 프레임워크들이 실제 그 기능의 10~20%이하만 사용되고 있다는 보고가 있다. 프레임워크의 일부 기능만 필요해서 그랬다면 상관없지만 때로는 프레임워크에서 이미 제공되고 있는 기능과 클래스를 몰라서 똑같은 기능을 가진 코드를 직접 개발해서 쓰는 경우도 적지 않다는 점이 문제다. 프레임워크 개발자들이 자주 하는 이야기는 사용자들이 요청하는 새로운 기능의 많은 부분은 이미 다 구현이 되어 있는 것들이라고 한다. 숙련된 프레임워크 사용자 일수록 오히려 자신이 오랫동안 써 온 기능 외에는 관심을 두지 않아 유용한 라이브러리 기능을 놓치는 함정에 빠지기 쉽다. 레퍼런스 매뉴얼과 API/클래스 문서를 꾸준히 살펴보고 유용한 라이브러리의 기능에 대한 지식을 쌓는 것이 프레임워크를 잘 활용하기 위한 지름길이다.

 

프레임워크의 종류
프레임워크는 다양한 방법으로 구분되어 질 수 있다. 모두 프레임워크라는 이름으로 불리지만 하이버네이트와 루비 온 레일즈(RubyOnRails) 그리고 .Net 프레임워크는 사실 용도와 사용목적, 적용방식에 많은 차이가 있는 다른 종류의 프레임워크이다.

프레임워크의 도입을 고려할 때 가장 먼저 생각할 것은 어떤 종류의 프레임워크를 적용할 것인가이다. 프레임워크가 애플리케이션의 전체 구조를 결정하도록 하려면 애플리케이션 프레임워크 또는 애플리케이션 개발 프레임워크(ADF)를 살펴봐야 한다. .Net 프레임워크는 일반적인 프레임워크의 범위를 넘어서는 매우 방대하고 범용적인 플랫폼으로 활용될 수 있는 애플리케이션 개발 프레임워크이다. 루비 온 레일즈는 웹기반이면서 데이터베이스를 사용하는 애플리케이션을 개발하는데 사용되어질 수 있도록 개발된 웹기반 애플리케이션 프레임워크(WAF)이다. 이러한 애플리케이션 프레임워크 외에 애플리케이션의 일부 기술과 기능을 구현하는 부분을 위해 프레임워크를 사용하려면 그 기술과 기능을 위해 특화된 프레임워크를 찾아야 한다.

하이버네이트는 자바기반의 애플리케이션에서 관계형 데이터베이스(RDBMS)를 사용하고자 할 때 적용할 수 있는 ORM 프레임워크이다. 또 보안이나 로깅, 테스팅, 리모팅, UI, 캐싱과 같은 애플리케이션의 기술적인 부분을 담당하는 프레임워크들도 다양하게 존재한다. 이런 프레임워크들은 애플리케이션 전체 구조와 코드에 영향을 주기 보다는 일부분에만 적용된다. 이러한 기술적인 부분을 담당하는 프레임워크는 일반적으로 애플리케이션 프레임워크와 함께 사용되어질 수 있다. 애플리케이션 프레임워크를 통해서 구성된 커다란 틀 안에서 보조적인 프레임워크로서 역할을 담당하게 된다. 물론 애플리케이션 프레임워크를 사용하지 않고 일부 기술프레임워크만 도입하는 것도 가능하다.

프레임워크는 사용하는 프로그래밍 언어와 사용 환경에 따라서 구분할 수도 있다. 많은 프레임워크는 단일 언어 기반의 프레임워크이지만 한 가지 이상의 언어를 지원하는 버추얼머신에서 동작하는 프레임워크도 있다. CLR기반에서 동작하는 .NET 프레임워크는 VB, C#, C++ 등의 여러 가지 프로그래밍 언어로 개발이 가능하다. 또 자바의 JVM을 사용하는 스프링프레임워크는 최근 릴리즈 된 2.0 버전부터는 JVM에서 동작하는 다양한 스크립팅 언어를 함께 사용해서 애플리케이션을 개발할 수 있도록 지원하고 있다. 이에 따라 루비(Ruby), 파이썬(Python), 그루비(Groovy), 자바스크립트(JavaScript　)와 같은 스크립팅 언어와 자바를 동시에 사용해서 개발할 수 있는 것이다.

출처 :  http://www.blueb.net/blog/1231?category=1