2005년 02월 01일
방법론과 개발의 간격을 메워주는「프레임워크」
zdnet 코리아에서 퍼왔습니다.
프레임워크는 특정 도메인 또는 기능 군에 속한 응용 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 이들의 아키텍처를 일반화해 부분적으로 구현한 소프트웨어 시스템이라 할 수 있습니다.
객체지향 프레임워크는 개조 및 확장이 용이한 클래스들로, 분해될 수 있는 유연한 아키텍처를 제공함으로써 컴포넌트 기반의 효율적인 소프트웨어 개발을 지원합니다. 다수의 응용 소프트웨어의 개발에 반복적으로 재사용되므로 프레임워크에 대한 철저한 시험이 요구되며, 재사용시 확장된 프레임워크에 대해서도 추가적인 시험이 필요합니다.
스트럭처? 아키텍처? 프레임워크!
스트럭처(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 계층입니다.
프레임워크는 특정 도메인 또는 기능 군에 속한 응용 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 이들의 아키텍처를 일반화해 부분적으로 구현한 소프트웨어 시스템이라 할 수 있습니다.
객체지향 프레임워크는 개조 및 확장이 용이한 클래스들로, 분해될 수 있는 유연한 아키텍처를 제공함으로써 컴포넌트 기반의 효율적인 소프트웨어 개발을 지원합니다. 다수의 응용 소프트웨어의 개발에 반복적으로 재사용되므로 프레임워크에 대한 철저한 시험이 요구되며, 재사용시 확장된 프레임워크에 대해서도 추가적인 시험이 필요합니다.
스트럭처? 아키텍처? 프레임워크!
스트럭처(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 계층입니다.
# by | 2005/02/01 19:30 | Development | 트랙백
