방법론과 개발의 간격을 메워주는「프레임워크」

프레임워크는 특정 도메인 또는 기능 군에 속한 응용 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 이들의 아키텍처를 일반화해 부분적으로 구현한 소프트웨어 시스템이라 할 수 있습니다. 

객체지향 프레임워크는 개조 및 확장이 용이한 클래스들로, 분해될 수 있는 유연한 아키텍처를 제공함으로써 컴포넌트 기반의 효율적인 소프트웨어 개발을 지원합니다. 다수의 응용 소프트웨어의 개발에 반복적으로 재사용되므로 프레임워크에 대한 철저한 시험이 요구되며, 재사용시 확장된 프레임워크에 대해서도 추가적인 시험이 필요합니다. 

스트럭처? 아키텍처? 프레임워크! 
스트럭처(Structure), 아키텍처(Architecture), 프레임워크(Framework)란 용어는 기술과 시대가 변하면서 조금씩 그 의미를 달리해가고 있습니다. 스트럭처가 트리(Tree)와 같은 계층적(Hierarchical)인 기반 구조를 말하는 반면, 프레임워크는 다소 수평적인 의미를 갖는 하부 구조를 나타냅니다. 또한 아키텍처는 더 포괄적인 개념으로 이 두 부분을 모두 포함하는 체계적인 기반 구조를 의미합니다. 

이 때, 프레임워크란 용어는 스트럭처나 아키텍처보다 더 낮은 레벨의 의미를 갖습니다. 즉 프레임워크의 실체는 때론 API의 집합으로 나타나기도 한다는 것입니다. 그러나 최근에 와서 IBM의 '샌프란시스코 프레임워크' 또는 MS의 '.NET 프레임워크'라는 용어가 등장하면서 '반 제품'의 의미를 강하게 띄고 있습니다. 

이러한 샌프란시스코 프레임워크와 .NET 프레임워크는 정형화된 업무를 위한 비즈니스 컴포넌트를 미리 만들어두고, 이를 조립함으로써 생산성을 극대화하자는 것이 요지입니다. 현재의 프레임워크란 것은 '기반 틀 구조' 라는 모호한 추상적인 개념 보다는 물리적인 실체이면서 반 제품 성격의 구체적이고 체계화된 API를 제공하는 개념에 더 가깝습니다. 

자동차 제작으로 알아본 프레임워크 
자! 자동차와 냉장고의 모든 각종 부품이 전부 분해돼 바닥에 서로 섞여 있는 모습을 상상해봅시다. 수많은 볼트와 넛트·게스킷·파이프·심지어 팬치와 드라이버까지 마구 섞여 있습니다. 이러한 부품과 연장을 이용해 우리가 만들려는 것은 파란색 자동차입니다. 

물론 완전히 분해된 부품들을 하나하나 조립해 파란색 자동차를 만들어낼 수는 있습니다. 하지만 상당한 시간이 걸리겠죠. 자동차를 만드는 데 전혀 쓸모없는 냉장고 부품은 걷어내고, 엔진조립부터 시작해 페인트칠까지 하다 보면, 갖가지 일이 발생할 것입니다. 그렇게 처음부터 우왕좌왕 하다보면, 납기는 가까이 오고 제때 완제품을 못 만드는 경우가 발생하기 쉽겠죠. 

그러나 엔진과 기어 변속장치, 동력 전달장치 등 각종 단위 부품을 미리 조립해둔 반 제품을 이용한다면 최종적으로 자동차를 만드는 기간은 엄청나게 단축시킬 수 있겠죠. 완제품을 만드는 사람은 엔진구조 공학은 모르지만 단지 최종적인 조립을 위한 최소한의 '조립 공정'과 기술만 보유하고 있어도 됩니다. 

만들려는 자동차를 SI 프로젝트를 통해 완성시켜야 할 최종적인 시스템에 비유한다면, 각종 부품들은 API(Application Programming Interface)에 해당될 수 있습니다. 이렇게 자동차를 더 빠르게 생산하기 위해 미리 조립해 제공하는 반 제품과 각종 부품에 해당하는 API를 일컬어 프레임워크라 할 수 있습니다. 

고질적인 불협화음을 제거하자 
물론 사람에 따라 정도의 차이는 있겠지만 일반적으로 개발 기술과 구현을 고려하지 않는 방법론과, 방법론이나 디자인을 고려하지 않는 개발·구현 사이에서 불협화음은 끊이지 않았습니다. 그러나 OOAD의 탄생과 자바 언어의 출현은 많은 부분에서 두 진영의 자연스런 합일의 방향으로 인도하고 있는 바람직한 현상이 나타나고 있습니다. 그러나 여전히 구체적이고 물리적인 소스코드와 산출물이라는 부분에서는 아직 뜬구름 잡는 얘기를 서로 다른 관점에서 하고 있는 것도 사실입니다. 

이 두 부분이 만나는 곳이 어딜까요? 바로 개발 프레임워크입니다. 자바 개발 프레임워크는 방법론적인 관점에서 구체적인 산출물에 대한 정의를 해야 하며, OOAD의 디자인 관점에서 구현돼야 합니다. 

자바 개발 프레임워크에서 제공되는 컴포넌트는 이미 정형화된 산출물로 별도로 제공될 것이며, 이 프레임워크를 이용해 프로젝트를 진행할 때는 그 프레임워크에 기초해 개발자의 비즈니스를 표현하는 산출물이 나와줘야 합니다. 산출물에 기술할 내용의 범위도 아주 명확합니다. 많은 부분이 이미 자바 개발 프레임워크 내에서 기술돼 있으며, 개발자를 위한 산출물은 좀더 비즈니스적인 부분만을 담고 있으면 됩니다. 

프레임워크 기반의 프로젝트 실무 
지금부터는 자바서비스넷에서 제안하는 JDF(Java Development Framwork)를 통해 실제 프로젝트에 프레임워크가 어떻게 적용되는지 살펴보겠습니다. 일반적으로 프로젝트를 통해 시스템을 개발할 때, 다음과 같이 네 단계의 개발 API 계층으로 나눠 접근할 수 있습니다. 

① 첫번째 계층 : 가장 상위 계층은 프로젝트에서 비즈니스를 애플리케이션으로 변환해 말 그대로 프로그램을 코딩하는 일반 개발자가 사용하는 API 계층입니다. 

② 두번째 계층 : 개발자들이 쉽게 프로그램을 구현할 수 있도록 도와주기 위해 프로젝트에서 많이 사용하는 공통모듈 혹은 프로그램 템플릿을 만들어 제공하는 모듈성 프로그램 API 계층이 있습니다. DB 자원을 액세스하는 모듈, 로그를 남기는 모듈, 모든 어플리케이션에서 공통적으로 사용하는 모듈을 개발하는 계층입니다. 사실상 전체 애플리케이션의 틀이 만들어지는 부분입니다. 이 계층이 없거나 흔들리기 시작하면 그 프로젝트는 상당히 위험하게 되죠. 

③ 세번째 계층 : 아키텍처와 성능을 고려해 전체적인 틀을 만들기 위한 가장 바탕이 되는 API를 제공해주는 계층입니다. 다양한 레거시 시스템 액세스 API, 애플리케이션 서버의 API를 이용해 백그라운드 코어 클래스를 만들어줌으로써 보다 효과적으로 전체 시스템의 틀을 만들어낼 수 있도록 도와주는 것입니다. 

④ 네번째 계층 : 마지막 계층은 제품의 API 계층입니다. BEA 웹로직·IBM 웹스피어·서블릿·JSP·RM·EJB API 등등 산업계에서 제공되는 API 계층입니다. 

 

최근 들어 일어나는 현상 가운데 가장 심각한 현상은 다음에 나오는 <그림 1>에서와 같이 가장 상위층의 일반개발자가 가장 하부층의 제품 API 계층을 바로 이용하고 있는 상황입니다. 소스 코드 내의 DB 액세스 정보같은 static 변수를 명시적으로 사용한다거나, 동일한 소스를 모든 개발자가 잘라붙이기(Cut & Paste)해 전부 자신의 프로그램에 넣어놓고 사용한다는 것이지요. 

그러다 보니 제품이 버전업돼 API가 변경되면 모든 프로그램의 소스를 변경해야 하거나, 각 모듈이 수행한 시간을 로그로 남겨야 하는 추가적인 요구가 있을 경우 모든 소스를 전부 새롭게 바꿔야 하는 상황에 처하게 되는 것입니다. 

 

그나마 나은 경우는 통합팀에서 주관해 시스템의 전체 틀을 잡고, 필요한 API를 제공해 개발자들은 그러한 API의 바탕 위에서 프로그래밍을 하는 경우입니다. 그러나 매 프로젝트마다 제 각각의 방식으로 동일한 작업을 하는거나 다름없습니다. 

어떤 프로젝트에서 고민했던 것을 다른 프로젝트에 가서 다시 처음부터 고민하고 있고, 또 다른 프로젝트에 가서 또 다시 처음부터 다시 하고 있습니다. 문제는 그러한 틀이 정말 제대로 된 방법으로 구현돼 있었느냐는 것입니다. 따라서 가장 이상적인 모습은 <그림 2>에서와 같이 세번째 계층인 개발 프레임워크가 존재할 때입니다. 제안하고자 하는 자바 개발 프레임워크는 세번째 계층에서 해줬어야 할 일들을 기술적인 입장에서 재정의하고 구체화해 프로젝트에 도입하자는 것입니다. 

이처럼 자바 개발 프레임워크는 기능성을 제공해 주는 API의 모음이며, 프로젝트 지원 툴이자 개발 프레임워크입니다. 이 때 개발 프레임워크는 물리적인 API뿐만 아니라 프로젝트를 진행하면서 꼭 필요한 프로젝트 지원 툴도 함께 고려돼야 합니다.

 

실제 프레임워크 사례

그럼, 지금부터는 실제 프레임워크 사례들을 살펴볼까요.

▶컬렉션 프레임워크(Collections Framework)
컬렉션 프레임워크는 컬렉션을 나타내고 조작하기 위한 통합 아키텍처로서, 서로 무관한 API 간에 상호 운영성을 허용하며 새로운 API를 설계하고 습득하는 데 들이는 노력을 줄이고 소프트웨어를 다시 사용하도록 할 수 있습니다. 여기에는 인터페이스 구현 및 인터페이스를 조작하는 알고리즘이포함됩니다(http://java.sun.com/products/jdk/1.2/docs/guide/collections/index.html).

▶자바빈즈 액티베이션 프레임워크(JavaBeans Activation Framework)
JAF(JavaBeans Activation Framework) 표준 확장을 사용하면, 자바 기술을 사용하는 개발자가 표준 서비스를 사용해 임의의 데이터 조각의 유형을 결정하고 해당 유형에 대한 액세스를 암호화한 다음, 유형에서 사용할 수 있는 작업을 찾고 이를 수행하는 적절한 빈의 경우를 생각해볼 수 있습니다. (http://java.sun.com/products/javabeans/glasgow/jaf.html).

▶자바 전자상거래 프레임워크
자바 전자상거래 프레임워크 기술은 인터넷에서 안전한 전자 상거래 무역을 지원하는 썬 마이크로시스템즈의 자바 기술 아키텍처입니다(http://java.sun.com/products/commerce/index.html).

▶자바 미디어 프레임워크(Java Media Framework)
자바 미디어 프레임워크 기술은 오디오, 비디오 및 MIDI와 같은 전통적인 시간 기반 매체를 처리합니다. 이것은 타이밍·동기화·조합에 대한 공통 모델을 제공하는데 이 모델을 매체 구성요소에 적용해 이들 구성요소가 통합될 수 있도록 합니다(http://java.sun.com/products/java-media/jmf/index.html).

▶.NET 프레임워크 
.NET 프레임워크는 웹 서비스의 제작·배포·운영 및 다른 애플리케이션을 위해 제공된 환경이며, CLR(Common Language Runtime), 프레임워크 클래스, 그리고 ASP.NET이라는 세 부분으로 구성돼 있는 복수 언어 컴포넌트 개발 및 실행 환경이라 할 수 있습니다. 이와 짝을 이루는 .NET 컴팩트 프레임워크(.NET Compact Framework)는 프로그래밍 인터페이스로서 개발자들이 스마트폰이나 PDA 같은 휴대용 장치를 위한 것입니다. .NET 프레임워크는 소프트웨어 작성의 세부 과정을 자동화함으로써 개발자가 COM 하부구조가 아닌 비즈니스 로직에 전념할 수 있도록 해줍니다.

▶마이크로소프트의 비트토크 프레임워크
비즈토크 프레임워크에는 XML 스키마를 구현하는 디자인 프레임워크와 응용 프로그램 간에 주고받는 메시지에 사용하는 XML 태그 집합이 포함돼 있습니다. 마이크로소프트와 다른 소프트웨어사 그리고 업계 표준 조직들은 비즈토크 프레임워크를 사용해 일관된 방식으로 XML 스키마를 생산함으로써 플랫폼이나 운영체제, 기본 기술과 상관 없이 업체 간 그리고 비즈니스 시스템 간 통합이 가능합니다(http://www.biztalk.org).

출처 : http://shiftspace.blog.me/100151333053

[출처] [펌] 방법론과 개발의 간격을 메워주는「프레임워크」|작성자 shiftspace