올바른 프레임워크의 선택과 사용법

올바른 프레임워크의 선택과 사용법
잘 고른 프레임워크는 프로젝트 성공의 열쇠

이경원 | 한국오라클 테크니컬 컨설턴트

언젠가부터 아파치, 소스포지 등 오픈소스 진영의 프레임워크 공세로 우리는 필요한 프레임워크를 쉽게, 그리고 많이 구할 수 있게 되었다. 이에 따라 개발자들도 자신의 입에 딱 맞는 프레임워크 사냥을 즐기고 사용법을 익히는 데 많은 시간을 투자한다. 하지만 우리는 프레임워크의 개념이나 사용 방식에 익숙하지 않다. 이번 시간을 통해 필자가 쌓아 온 프레임워크의 내공(?)을 소개하도록 하겠다.
현재 한국오라클에서 테크니컬 컨설턴트를 맡고 있다. 스트럭처, 객체지향, CBD, SOA 순으로 전문영역을 넓혀 왔으며 현재는 프레임워크와 아키텍처에 많은 관심을 가지고 있다.
컴퓨터가 역사에 등장한 지 채 100년이 되지 않았다. 하지만 발전 속도는 다른 산업에 비해 매우 빨라서 새로 나오는 기술이나 개념을 따라잡기 힘든 경우가 많다. 특히나 소프트웨어 분야에서 이러한 경향은 더욱 두드러지는데, 수없이 많은 ‘수단’이나 ‘방법’들이 나타나 각광을 받기도 하고 사라지기도 한다. 그 중에 프레임워크는 각광을 받고 있는 쪽에 속한다. 이젠 소프트웨어 개발의 필수요소로 그 입지를 확고히 차지하고 있으며, 새로 등장하는 프레임워크는 그 수를 헤아리기조차 어려울 정도다. 말 그대로 프레임워크의 홍수, 프레임워크의 춘추전국시대다. 신발 가게에 신발이 많다고 해서 모두 발에 맞는 것이 아니듯, 이들 중 자신에게 적합한 프레임워크를 식별하는 기술은 개발자의 조건으로 중요한 자리를 차지하게 된다.
프레임워크는 반쪽 애플리케이션?
일반적으로 프레임워크는 사전적으로 ‘무언가를 이루는 뼈대나 기반 구조’를 의미한다. 컴퓨터 소프트웨어 분야에서의 프레임워크도 ‘특정 애플리케이션 소프트웨어를 만들 때 사용하는 기반 구조’라는 점에서 의미는 같다. 소프트웨어를 만들 때 문제영역에 대해 잘 설계된 디자인이 있다면 같은 문제영역을 개발하는 많은 사람들은 그 디자인을 차용하여 소프트웨어를 설계할 것이다. 그 디자인이 재사용해도 좋을 정도로 유용하다면 사람들은 곧바로 그들의 디자인 모델에 포함시킬 것이다. 그리고 이 디자인을 이미 구현해 놓았다고 한다면 사람들은 디자인 과정을 생략하고 개발시에 그 코드를 재사용할 것이다. 이렇게 특정 문제영역의 일반적인 솔루션 구현물을 프레임워크라고 해도 무방하다. 물론 같은 기능을 하는 라이브러리나 컴포넌트 등이 있지만, 이는 박스기사에서 자세히 다루도록 하자.
여기서 포착할 특징은 프레임워크 자체는 완전한 애플리케이션 소프트웨어가 아니라는 것이다. 혹자는 프레임워크를 반쯤 완성된 애플리케이션(semi-complete’ application)으로 정의하기도 한다. 어떤 문제영역을 해결하기 위한 잘 설계된 일반적인, 재사용 가능한 모듈(이미 만들어진 ‘반’)이기 때문에 완결된 애플리케이션으로 제공되지 못한다. 따라서 사용자가 프레임워크를 확장하여 비즈니스 요구사항을 만족시키는 완전한 애플리케이션 소프트웨어를 완성시키는 작업(나머지 ‘반’)이 요구된다.
이제 프레임워크에 대한 간단한 실례를 보기로 하자. 데이터베이스에서 값을 읽어들여 이를 메모리 캐시에 저장해 두었다가 애플리케이션이 요청을 하면 값을 전달해 주는 캐시 시스템을 구현해야 한다. 일반적으로 애플리케이션의 마스터 데이터나 메타 데이터와 같이 변경은 잘 되지 않으면서 사용 빈도가 높은 데이터를 캐시 시스템에 저장해서 사용한다. 캐시 시스템의 동작 원리는 간단하다. 클라이언트가 원하는 값을 캐시 시스템에 요청하면 캐시 시스템은 자신의 캐시된 데이터를 검색하여 있다면 리턴한다. 만약 값이 없다면 데이터베이스에서 값을 읽어와 캐시에 저장하고 이를 클라이언트에 돌려준다. 그 전체적인 구조는 <그림 1>과 같다.

여기서 값이 저장되어 있는 매체(데이터 소스)가 데이터베이스가 아닌 다른 것일 경우는 어떻게 될까? 가령 데이터 소스는 로컬 디스크에 있는 플랫 파일이 될 수도 있고, 원격 시스템에 있는 XML 파일이 될 수도 있다. 만약 이렇게 되었을 경우 앞의 데이터베이스의 예에서처럼 값을 가져오는 방식만 달라질 뿐이지 값을 가져온 이후 처리되는 컴포넌트들과는 영향을 미치지 않는다. 그렇다면 영향을 끼치지 않는 나머지 부분은 재사용 가능하게 된다. 단지 값을 가져오는 부분을 각 애플리케이션마다 상호작용하는 데이터 소스에 맞게 확장하여 사용해도 큰 무리가 없을 것이다. 여기서 실제로 값이 저장된 매체(데이터 소스)로부터 값을 가져온 이후까지는 사용자 확장이 필요한 부분이 된다. 데이터 소스로부터 데이터를 얻어와 애플리케이션에 전달해 주는 부분까지는 프레임워크로 정의한다면 데이터에 대한 캐시가 필요한 여러 클라이언트에 두루 사용할 수 있다.
즉, 프레임워크는 Open-Closed 원칙(이하 OCP)을 그대로 따르고 있다. 재사용되는 공통된 부분은 프레임워크로 구현되어 다른 사람이 그 내부를 가공없이 이용하도록 제공하고 있다(Closed). 확장이 필요한 부분은 사용자 요구사항에 맞게 정의하여 확장시키므로 문제영역에 최적화된 애플리케이션 설계가 완성된다(Open).
<그림 2>는 캐시 프레임워크의 일반적인 구조를 도식화한 것이다. 프레임워크를 애플리케이션에 적용할 때 변경되지 않고 반복적으로 재사용되는 부분을 프레임워크의 코어로 정의한다. 변경이 잘 일어나지 않는 프레임워크의 코어 부분을 콜드 스팟(Cold spot)이라고 부르기도 한다(OCP에서 Closed 모듈에 해당한다).

프레임워크 코어는 각 애플리케이션마다 확장 모듈을 연결하는 확장점을 제공하는데, 이를 훅 포인트(hook point)라고 한다. 대개 훅 포인트는 추상 클래스나 인터페이스의 형태로 나타난다. 애플리케이션마다 이 훅 포인트를 통해 확장 모듈을 바인딩한다. 이 확장 모듈을 핫 스팟(Hot Spot)이라고 부른다(OCP에서 Open 모듈에 해당한다).
일반적으로 훅 포인트는 사용자가 소스코드 상에서 함수 호출을 통해 확장 모듈을 등록(혹은 바인딩)하게 된다. 하지만 바인딩 코드들이 사용자 코드 곳곳에 분포되어 산만하고 반복 작업을 하게 한다. 이런 불편 때문에 현재 프레임워크는 메타 데이터를 이용하여 훅 포인트로의 연결, 정책 설정들을 정의하고 있는 추세다. struts의 struts-config.xml이나 J2EE의 사용자 정의 파일들이 대표적인 예다. 전자의 경우 프로그램에 의한(programmatic) 바인딩이라 하며 후자의 경우 선언에 의한(declarative) 바인딩이라고 한다.
이렇게 프레임워크에 기반해 애플리케이션을 개발하게 되면 생산성이 향상될 뿐 아니라 여러 애플리케이션이 비슷한 구조를 가지게 되므로 관리하기도 쉬워진다. 물론 프레임워크에 맞춰 애플리케이션을 개발해야 하므로 창조적인 소프트웨어 생산을 원하는 사람들은 좋아하지 않는 경우도 있다. 이런 사람들은 프레임워크 자체를 만드는 쪽이 더 적합할 것이다.
프레임워크의 다양한 분류 방법
프레임워크는 컴퓨터 소프트웨어와 관련된 거의 모든 영역에서 사용되고 있는 개념이다. J2EE나 닷넷 프레임워크 같은 아키텍처 모델에서도 프레임워크라는 용어가 사용되는데 이 경우 아키텍처 프레임워크라고 한다. 한편 IBM RUP(Rational Unified Process)나 마이크로소프트 솔루션 프레임워크 같이 방법론에서도 프레임워크 개념을 사용한다. 이렇게 프레임워크는 전형적인 버즈워드(buzzword: 전문적인 어감을 풍기는 유행어)가 된 듯한 느낌이다. 일반적으로 프레임워크라고 하면 애플리케이션 프레임워크를 말한다. 여기서는 애플리케이션 프레임워크를 몇 가지 기준에 따라 분류해 보기로 하겠다.
프레임워크의 계층에 따른 분류
프레임워크가 이용되는 계층에 따라 몇 가지로 분류할 수 있다.
시스템 인프라스트럭처 프레임워크
시스템의 인프라스트럭처의 효과적인 개발을 위한 프레임워크이다. OS나 커뮤니케이션 인프라, 사용자 인터페이스, 언어 처리 툴과 같은 애플리케이션을 이식성 좋고 효과적으로 개발할 수 있도록 해준다. 보통 소프트웨어 벤더 조직 내부에서 쓰이는 것이 일반적이다. TAO나 프레임워크로 제공되지 않으며, 자바 기본 패키지의 경우가 여기에 속한다.
미들웨어 통합 프레임워크
분산된 애플리케이션이나 컴포넌트들의 통합에 사용되는 프레임워크들이다. 미들웨어 통합 프레임워크는 프로그래머들이 마치 단일 환경에서 작업하는 것과 같은 소프트웨어 인프라스트럭처를 제공함으로써 기존 방식의 프로그램 제작 방법을 무리 없이 사용할 수 있도록 해준다. 미들웨어 통합 프레임워크에는 ORB 프레임워크, MOM (Message Oriented Middleware) 등이 있다.
엔터프라이즈 애플리케이션 프레임워크
실제 비즈니스 도메인(통신, 항공, 조업, 금융 등)에서 사용할 애플리케이션을 개발하기 위한 프레임워크다. 대부분의 대형 비즈니스 애플리케이션이 이 엔터프라이즈 애플리케이션 프레임워크를 기반으로 작성된다. CMS나 ERP 프레임워크들이 대표적인 예이다.

확장 방법에 따른 분류
프레임워크에 사용자가 확장하는 모듈을 정의에 따라 분류할 수 있다. 이 정의 방식은 바인딩(훅킹 방식)과도 연관이 깊다.
화이트 박스 프레임워크
객체지향 언어가 제공하는 상속이나 동적 바인딩에 의존해서 확장을 하는 프레임워크 방식이다. 프레임워크 코어의 베이스 클래스를 상속하고 미리 정의된 훅 포인트를 구현함으로써 프레임워크를 확장한다. 화이트 박스 프레임워크는 애플리케이션 개발자가 프레임워크의 내부 구조에 대한 지식을 필요로 한다. 프레임워크가 정의한 클래스를 상속하여 클래스의 인터페이스를 구현해야 하기 때문에 각 인터페이스의 역할, 규약, 정책 등에 대해 숙지해야 한다. 화이트 박스 프레임워크를 확장한 경우에는 프레임워크의 세부 구조와 밀접하게 연관된 애플리케이션이 만들어지는 경향이 있다.
블랙 박스 프레임워크
프레임워크에서 정의한 핫 스팟 인터페이스를 구현해야 하며, 이 구현한 객체를 인터페이스와 컴포지션을 통해 확장한다. 객체의 상속 없이 컴포지션과 딜리게이션(위임)으로 확장되기 때문에 프레임워크 내부 구조의 의존성이 상대적으로 낮다. 따라서 프레임워크에 대한 이해가 다소 적게 요구되며 쉽게 확장할 수 있다. 반면, 프레임워크 개발자는 미래에 잠재적으로 발생할 확장 포인트까지 미리 정의해야 하는 예지력이 필요하다. 따라서 프레임워크 자체의 개발이 어려워지는 경향이 있다.
처리 영역에 따른 분류
기능 프레임워크
전체 애플리케이션 중에서 특정 기능 부분의 구현에 사용되는 프레임워크이다. 데이터베이스 핸들링이나 사용자 인터페이스 구현과 같이 한정된 영역을 해결해 주는 역할을 한다. 즉, 애플리케이션이 동작하기 위해 필요한 여러 영역들(DB, 그래픽, 로깅, 리소스 풀링, 캐싱 등)의 문제점을 전담하는 각각의 프레임워크들이다. 현재 많은 개발자들이 이 프레임워크들의 조합으로 시스템을 구축하고 있으며 자바의 경우 classpath에 여러 jar 파일들을 사용하는 게 그 증거다.
우리가 사용하는 가장 일반적이고 보편적인 프레임워크에 해당하며 대부분의 프레임워크들이 기능 프레임워크로 출발한다. Log4X 시리즈와 같은 로깅을 위한 프레임워크나 OR-맵핑 프레임워크, 스트럿츠와 같은 웹 프레임워크 등이 대표적이다. 과거의 아키텍트들은 시스템의 전체의 설계를 많이 고민했다. 하지만 우수한 기능 프레임워크들 덕택에 프레임워크 사용에 대한 가이드라인이나, 샘플 코드, 프레임워크를 잘 사용할 수 있는 유틸리티 등을 고민하는 모습을 많이 발견하게 된다.
지원 프레임워크
애플리케이션을 개발하는 작업에 도움을 주는 개발 지원 프레임워크를 말한다. 기능 프레임워크는 운용 환경에 같이 배치되는 데 반해 지원 프레임워크는 애플리케이션에 포함되지 않는다. 애플리케이션 빌드를 위한 프레임워크나 Xunit 시리즈와 같은 테스팅 프레임워크 등이 여기에 속한다.
통합 프레임워크
여러 기능 프레임워크들을 한 곳에 모아 통합한 프레임워크를 말한다. 특정 아키텍처 모델에 기반한 애플리케이션의 전체 영역을 모두 다룬다. 따라서 통합 프레임워크에서 개발을 하면 아키텍처와 디자인의 상당수를 프레임워크 구조에 맞추게 된다. 규모가 큰 소프트웨어의 경우 통합 프레임워크에 기반해서 개발하는 것이 일반적이다. 왜냐하면 작업량이 많고 개발해야 할 시스템이 거대하기 때문에 생산성 향상을 위해 구현해야 할 많은 부분을 프레임워크에 맡기기 때문이다. 대체로 대형 소프트웨어 벤더들이 개발 환경과 통합하여 제공하는 경우가 많으며, BEA의 비하이브나 오라클의 ADF 등이 여기에 속한다.

프레임워크 사용 가이드라인
이제까지 프레임워크의 자체에 대한 내용을 살펴봤다. 하지만 개발자에게 ‘프레임워크란 무엇인가?’ 즉, WHAT의 문제보다도 ‘어떻게 사용해야 하는가?’ 즉, HOW의 문제가 주된 관심사다. 이제 프레임워크를 어떻게 실제로 적용하는 것이 좋을지에 대해 살펴보자.
만들고자 하는 애플리케이션의 성격 파악하기
애플리케이션은 한번 만들어지면 결국 직·간접적으로 우리 삶에 영향을 미치게 된다. 그 영향의 정도는 미미할 수도 있고 아주 클 수도 있다. 애플리케이션의 성격을 명확히 해야 적절한 프레임워크를 선택할 수 있다. 애플리케이션은 성격에 따라 다음과 같이 크게 네 가지로 나눌 수 있다.
첫 번째 경우
애플리케이션이 잘못되었을 때 아무런 물질적 손해가 없거나 있다 해도 경미한 애플리케이션. 이러한 애플리케이션은 비즈니스에 직접적으로 미치는 영향이 거의 없다고 봐도 무방하다. 실제로 이 유형의 애플리케이션은 비즈니스에 직접적으로 사용되는 경우도 거의 없으며 대부분 테스트 목적인 경우가 대부분이다. 다음과 같은 경우가 이에 속한다.
1. 개인이 취미 삼아 만들어 보는 애플리케이션
2. 기술 수준을 높이기 위한 연구 목적의 작업
3. 무언가가 타당한지를 확인해 보기 위한 파일럿 프로젝트
대개 한 명 내지는 약간 명으로 구성된 하나의 팀이 작업을 수행하게 되고 이들은 보통 한 자리에 모여서 작업을 하게 되는 경우가 일반적이다. 프로젝트를 수행하는 구성원은 학생부터 기술적 수준이 높은 개발자까지 다양하다. 6개월 이내로 짧게 끝나는 경우가 일반적이다.
두 번째 경우
애플리케이션이 잘못되었을 때 사용자에게 다소간의 불편만을 초래하는 애플리케이션. 애플리케이션의 잘못이 궁극적으로는 물질적 손해를 발생시키지만 그것이 그리 큰 문제가 되지 않는 애플리케이션이다. 다음과 같은 경우가 이에 속한다.
1. 개인이 취미로 운영하는 웹 사이트
2. 회사의 비즈니스에 큰 영향을 주지 않는 웹 사이트
3. 회사가 내부적으로 운영하는 인트라넷 상의 애플리케이션
대개 약간 명에서 10여 명으로 구성된 하나 내지는 두 팀이 작업을 수행하게 되고 이들은 보통 한 자리에 모여서 작업을 하게 된다. 보통 작업 기간이 1년을 넘지 않는다.
세 번째 경우
애플리케이션이 잘못되었을 때 금전적인 손해를 초래하는 애플리케이션. 애플리케이션의 잘못으로 인한 금전적인 손해가 회사 내부에서 발생하는 경우로 금전적인 손해의 금액이 얼마인가보다는 금전적인 손해 자체가 의미가 있는 경우이다. 애플리케이션의 영향이 회사 내부에만 국한된다. 다음과 같은 경우가 이에 속한다.
1. 회사 내부의 인사·회계 애플리케이션
2. 인터넷 쇼핑몰
3. 돈을 받고 제공하는 인터넷 서비스
대개 10~40명 정도의 사람이 여러 팀으로 나뉘어 작업을 수행하게 된다. 자리가 여러 곳으로 나눠질 수 있으며, 작업기간은 1~2년 정도가 소요된다.
네 번째 경우
애플리케이션이 잘못되었을 때 인명 피해가 발생하거나 큰 금전적인 손해가 발생하는 애플리케이션. 비즈니스적으로 매우 중요한 애플리케이션으로 검증된 아키텍처와 기술을 사용해야 한다. 다음과 같은 경우가 여기에 속한다.
1. 공장을 운영하는 조업 시스템
2. 원자력 발전소 운영 시스템
3. 금융기관의 전산 시스템
참여하는 사람이나 투입되는 자원의 양이 상당하다. 매우 엄격하게 통제·관리되고, 작업 기간은 보통 수년에 이른다.
이러한 애플리케이션의 성격은 프레임워크를 선택할 때 완성도라는 측면의 기준이 된다. 애플리케이션이 잘못되었을 경우 미치는 파장이 별로 크지 않은 경우라면 프레임워크 선택의 폭이 넓어진다. 따라서 시스템의 리스크, 중요도, 목적이 낮다면 업계에서 검증된 완성도 높은 프레임워크부터 그렇지 않는 새로운 프레임워크까지 다양한 종류의 프레임워크를 사용해 볼 수 있다.
반면 애플리케이션이 비즈니스에 미치는 영향이 큰 경우라면 다양한 환경에서 사용되는, 어느 정도 검증된 완성도가 높은 프레임워크를 선택해야 한다. 메이저 벤더에서 만든 상용 프레임워크를 사용하는 것도 좋은 방법이다. 왜냐하면 프레임워크에 대한 지원이 얼마나 잘 되는지, 문제가 발생했을 때 얼마나 빠르고 정확하게 문제를 해결할 수 있는지가 프로젝트 위험요소의 완충지대가 되기 때문이다. 메이저 밴더의 경우 이 시행착오를 오랫동안 많은 사이트에서 관리했기 때문에 좀 더 신뢰가 간다.
개발하려는 애플리케이션의 아키텍처를 정의하기
적절한 프레임워크를 선택하기 위해서 개발하는 애플리케이션의 구조를 정의하는 것이 선행되어야 한다. 이른바 애플리케이션의 아키텍처를 명확히 해야 하는데, 이는 애플리케이션 개발에서 가장 먼저 해야 할 일이기도 하다. 예를 들어 엔터프라이즈 비즈니스 애플리케이션을 만들고자 한다면 먼저 몇 개의 계층으로 시스템을 구축할 것인지, 사용자 인터페이스는 무엇으로 할 것인지, 데이터 소스는 어떤 것을 사용할 것인지, 비즈니스 로직은 어떠한 기술을 사용해 구현할 것인지 등을 정의해야 한다.
이런 경우 각 아키텍처의 구성 요소마다 선택하고자 하는 기술들이 경합을 이룬다. 예를 들어 데이터베이스를 다루는 부분의 경우 간단한 DAO(Data Access Object)를 이용하는 형태로 구현할 수도 있고 OR-맵핑을 통해서 처리할 수도 있다. 사용자 인터페이스와 관련해서는 웹을 지원하는 하나의 사용자 인터페이스로 처리할 수도 있고, 휴대전화나 PDA에서도 보여지도록 다중 인터페이스를 처리해야 할 수도 있다. 데이터 소스도 데이터베이스만이 아니라 레거시 시스템이나 파일도 동시에 처리해야 할 수도 있다. 이렇게 같은 문제영역에 대한 프레임워크도 요구사항, 규약들에 의해 필요/불필요가 결정된다. 이 필요/불필요의 기준을 명확히 하기 위해서 아키텍처를 명확히 정의하는 것이 필요하다.
프로젝트 구성원을 고려해 프레임워크 선택하기
프레임워크를 이용한 프로젝트에서 가장 필요한 부분이 프레임워크와 운용 환경, 문제 환경 등에 대한 이해도이다. 즉, 프로젝트 기간에 프레임워크 사용에 대한 적당한 시간이 필요하며 이 학습 시간과 학습하기 쉬운 프레임워크의 균형은 프로젝트를 위험에 노출시키지 않는 요령이다. 따라서 개발자가 프레임워크나 프로그래밍 언어에 익숙하지 않은 상황에서 교육할 시간도 부족하다면 보다 사용하기 쉬운 프레임워크를 선택해야 한다. 이런 경우 프로그램에 의한 바인딩 프레임워크보다 선언에 의한 바인딩을 제공하는 프레임워크를 추천한다. 메타 데이터를 이용하는 방식은 프레임워크 구조에 대한 이해가 비교적 낮게 요구되며 프레임워크에서 원하는 인터페이스만 구현해 주면 된다.
통합 개발환경이나 위자드와 같은 개발 도구와의 연계도 중요한 고려대상이다. 실제로 많은 프레임워크들이 코드 생성이나 메타 데이터 정의와 같은 부분을 개발 도구와 연계하고 있다. 이러한 개발 도구들의 지원이 있다면 많은 수의 개발자가 참여하는 애플리케이션 개발 프로젝트에서도 쉽게 프레임워크를 도입해 사용할 수 있게 된다.
실제로 프레임워크 차세대 버전으로 프레임워크 + 비주얼 빌더 + 프로그래밍 언어 지원 기능을 전망하고 있다. 프로그램 코드에 의한 사용이 불편하기 때문에 선언에 의한 사용을 제공하지만 역시 선언 방식이나 규약들을 알아야 한다. 이런 학습곡선(Learning Curve)과 선언 작업을 최소화시키기 위해 위자드 등의 비주얼 빌더를 통해 관계 방식을 설정하고 스크립트 언어를 통해 메타 코드를 제너레이팅하는 기능을 목표로 하고 있다. 이를 프레임워크 열반(Framework Nirvana)라고 한다.
프레임워크를 적절히 조합하기
프레임워크는 해당 문제영역을 해결한다. 하지만 소프트웨어는 전체의 관점에서 여러 문제영역을 포함하고 있다. 따라서 소프트웨어 개발에선 여러 프레임워크들을 조합하여 개발한다. 하지만 프레임워크는 프레임워크간의 조합을 위한 인터페이스를 제공하고 있지 않다. 가령, 데이터베이스에서 DB 프레임워크를 통해 10개의 항목을 얻어와 웹 프레임워크를 통해 HTML 테이블로 리턴한다고 했을 때 두 개의 프레임워크를 사용하는 코드가 필요하며, 각 프레임워크간의 데이터 조작 방식이 다르기 때문에 맵핑을 해주어야 한다. 이렇게 프레임워크를 조합하는 데 필요한 비용이 따르게 되며 적절한 조합은 이 비용과 시스템 품질을 향상시킨다. 다음은 프레임워크를 조합하는 방법들이다.
프레임워크를 직접 선택하는 방법
애플리케이션에서 사용할 프레임워크를 프로젝트팀에서 일일이 선택하고 이들을 조합해서 사용하는 방법이다. 자유도가 가장 높은 방법이지만 프레임워크를 직접 선택해야 하므로 해야 할 일이 많다. 각 프레임워크간의 연계는 잘 되는지, 기능은 충분한지 등을 확인해야 한다. 각 프레임워크의 버전업이나 특정 기능 프레임워크를 다른 프레임워크로 교체한다거나 할 때도 일일이 확인해야 할 것이 많아지기도 한다.
프레임워크 배포판을 사용하는 방법
리눅스와 관련된 여러 소프트웨어를 하나로 묶어 리눅스 배포판을 내듯이 프레임워크들을 하나로 묶어 프레임워크 배포판을 내는 경우가 있는데 이를 사용하는 방법이다. 프레임워크간의 연계나 기능에 대한 검토는 배포판을 내는 쪽에서 확인하기 때문에 편하게 프레임워크를 사용할 수 있다. 프레임워크의 배포판을 사용할 경우에는 배포판을 내는 쪽이 얼마나 지원해 줄 것인가를 잘 살펴야 한다. 어느 날 갑자기 배포판에 대한 관리가 이루어지지 않는다면 그 후에는 배포판을 구성하는 프레임워크를 직접 일일이 관리해야 하는 경우가 생길 수도 있다.
메이저 벤더의 프레임워크를 사용하는 방법
메이저 벤더가 제공하는 통합 프레임워크를 사용하는 방법이다. 구입 비용이 많이 드는 반면 가장 안정적으로 프레임워크를 사용하는 방법이다. 메이저 벤더가 제공하는 기술 지원을 받을 수 있다는 점과 프레임워크의 완성도가 높다는 점에서 매력적이다. 규모가 큰 엔터프라이즈 애플리케이션을 개발하는 경우라면 이 방법이 가장 적절한 선택이라고 할 수 있다.
세상은 넓고 프레임워크는 많다
지금까지 프레임워크에 대해 간단히 정리하고 프레임워크를 사용하는 방법에 대해서 간단히 살펴보았다. 글이 다소 추상적인 개념을 위주로 했고 실제 프레임워크에 대한 언급을 최소화한 경향이 있는데, 이것은 필자가 알고 있는 몇몇 프레임워크에 대한 설명으로 글을 이끌어 가지 않기 위해서였다.
애플리케이션의 규모가 대형화되고 그 제작에 많은 인원이 관여되고 시간적인 여유도 적은 경우가 많은 프로젝트 상황이 요즘의 현실이다. 이 상황에서 프레임워크는 매우 효과적으로 개발 비용, 시간을 줄이는 애플리케이션 개발 수단이다. 따라서 적절한 프레임워크를 사용하는 것은 성공의 보증 수표가 된다. 한 가지 분명하게 말할 수 있는 것은 여러 곳에서 사용돼 검증된 프레임워크를 선택해야 한다는 것이다. 세상은 넓고 프레임워크는 많다. 보다 많은 사람들이 효과적으로 프레임워크를 사용해서 성공적인 프로젝트를 수행하기를 희망한다.
[ 프레임워크와 관련된 주요 개념들 ]

다음은 프레임워크와 관련된 주요 개념들이다. 이들은 프레임워크로 실현되기도 하고, 상호 포함관계를 갖기도 하고, 이용관계를 갖기도 한다.

패턴
패턴은 특정 도메인 영역에서 자주 발생하는 문제와 이에 대한 해결책을 나름의 형식을 통해 정리한 것이다. 아키텍처 패턴, 분석 패턴, 설계 패턴 등 그 적용 분야도 다양하며 이미 상당수의 패턴이 여러 분야에서 다양하게 사용되고 있다.
패턴과 프레임워크는 이미 성공한 솔루션에서 유래했다는 점과 다른 유사한 사례에서 재사용할 수 있다는 점에서 공통점을 갖고 있다. 하지만 패턴이 추상화된 구조나 설계 등에 대한 개념(모델)인 반면, 프레임워크는 실제로 구현된 무엇이라는 점에서 큰 차이가 있다. 즉, 패턴은 디자인의 재사용을 제공하고 프레임워크는 구현된 코드의 재사용을 제공한다. 필자가 서두에 설명한 ‘어떤 문제영역에 대한 잘 설계된, 재사용 가능한 디자인’이 패턴의 위치에 해당하고 이 디자인이 구현된 모듈을 프레임워크로 대입하면 될 것이다.
프레임워크는 디자인 패턴들을 실제로 구현한 결과물이고 이런 관계로 프레임워크를 문서화할 때 패턴을 통해 기술하는 것이 효과적이다. 실제로 잘 만들어진 프레임워크의 내부를 보면 유명한 패턴을 구현한 것인 경우가 많다. 이런 관계로 프레임워크 설명서로 디자인 패턴들을 소개하는 경우도 많다(J2EE 아키텍처, JUnit 설명서). 패턴은 다음 세 가지 점에서 프레임워크와 다르다.

1. 패턴은 ‘추상적인 무엇’이고 프레임워크는 좀 더 ‘실제적인 어떤 것’이다. 프레임워크는 코드로 구현되어 있지만 패턴은 추상화된 디자인 모델이다. 그러므로 패턴에 대한 샘플코드 정도가 있을 뿐이다.

2. 디자인 패턴은 프레임워크보다 작은 단위의 개념이다. 하나의 프레임워크는 보통 여러 가지 패턴으로 구성되고 있다.

3. 디자인 패턴은 보다 일반적이고 프레임워크는 대부분 특정 애플리케이션 도메인 영역에 특화되어 있다.

클래스 라이브러리
애플리케이션은 여러 클래스들이 상호작용하면서 그 기능을 수행하는데, 특정 기능을 수행하는 클래스들을 클래스 라이브러리 혹은 툴킷이라고 한다. 클래스 라이브러리는 범용적으로 사용할 수 있는 기능을 제공하는 재사용할만한 연관된 클래스들의 묶음이다. 리스트나 테이블 스택과 같은 자료 구조를 구현해 놓은 컬렉션 라이브러리, STL, IO 스트림 라이브러리 같은 것들이 그 전형적인 예이다. 클래스 라이브러리는 일반적인 기능만 제공한다는 점에서 프레임워크와는 다르다. 따라서 클래스 라이브러리의 목적은 일반적인 기능을 개발자가 다시 구현하지 않도록 해주는 수준에 속한다. 따라서 클래스 라이브러리를 사용함으로써 보다 용이하게 프레임워크를 개발할 수 있다.
클래스 라이브러리와 프레임워크간의 가장 큰 차이는 제어 권한의 위치에 있다. 클래스 라이브러리의 경우 사용자 코드가 필요에 의해 호출하여 사용하는 반면, 프레임워크의 경우 프레임워크에서 플로우가 시작하여 사용자가 등록한 핫 스팟 모듈을 호출한다. 이를 역제어(Inversion of Control)라고 한다.

컴포넌트
컴포넌트는 표준으로 정의된 컨테이너 규약 하에서 독립적으로 사용할 수 있는 소프트웨어 모듈이다. 컴포넌트의 기능은 인터페이스로 정의되며 그 내부 구현은 감추어져 있다. 프레임워크가 애플리케이션 기반 구조에 더 초점을 맞춘 개념이다. 반면 컴포넌트는 컨테이너라고 하는 기반 구조에서 작동하는 컴포넌트 모듈에 초점을 맞춘 개념이라는 점에서 차이가 있다.
프레임워크와 컴포넌트의 컨테이너는 애플리케이션을 이루는 기반 구조라는 점에서 매우 유사하다. 또한, 프레임워크에 등록하는 사용자정의 확장 모듈은 같은 종류의 프레임워크에서 재사용 가능하기 때문에 컴포넌트의 경우와 그 형태가 유사하다. 이런 관계 때문에 컴포넌트와 프레임워크를 혼용하게 되거나 분류가 어려워진다. 컴포넌트는 컨테이너-컴포넌트간의 관계 구조나 컨테이너, 컴포넌트 각각의 내부 구조를 구현하는 데 있어 프레임워크를 사용하기도 한다. 프레임워크는 핫 스팟과 콜드 스팟 구현 단위나 핫 스팟 인터페이스 설정에 있어 컴포넌트의 개념을 사용하기도 한다. 이런 관계로 일반적으로 프레임워크가 오래 사용되어서 기반 구조가 안정화되고 그 프레임워크를 확장해서 구현한 모듈이 많아지게 되면 그 자체가 바로 컴포넌트와 컨테이너가 된다.



출처 : 마이크로스프트웨어 [2004년 12월호]