CBD , Component Based Development

1.     CBD , Component Based Development

A.     CBD 방법론의 이면적 관찰

CBD는 재사용(reuse) 와 조립(assembly)이 가능한 소프트웨어 자산을 컴포넌트라는 것으로 만들고,
그것들을 기반으로 시스템을 개발하여 개발의 생산성 향상과 비용의 절감을 추구하고자 하는 개발방식의
Trend 이다.

그리고 그러한 CBD 개념을 적용하기 위한 역할(role), 작업(task), 산출물(work product)등을 체계적으로 정리해 놓은 것이 CBD 방법론 이다.

그런데 이겨서 생각해 볼 것은 “과거에는 소프트웨어 자산을 컴포넌트화 하지 않을까?’’ 라는 것이다.
과연 컴포넌트라는 개념이 새롭게 등장한 것이고 그것을 기반으로 개발하는 것이 전혀 다른 이슈가 될 수 있느냐는 것을 생각해보면 대부분 “그렇지 않다” 라고 답을 할 것이다.

과거 소프트웨어 개발을 시작했을 때부터 많은 개발자들이 개발의 효용성을 위해 재사용을 고민해 왔고 그것을 실천하기 위해 많은 방법들을 사용하여 왔다.
시스템의 공통적 기능을 별도로 구성해 놓고 그것을 사용하면 생산성과 비용에서 효율적이라는 것은 소프트웨어 개발을 해 본 사람이면 어느 누구나 다 알고 있는 내용이다.

모듈(module), 공통함수(common function) 등으로 소프트웨어 자산을 만들어 놓고 그것을 활용하는 시스템 개발은 소프트웨어 개발 역사와 함께 해 왔다.
GUI의 데이터 CRUD(Create , Read , Update , Delete) 의 독립적인 기능을 만들어 두고 여러 개발자가 그것을 사용하면서 개발해 본 경험은 C/S 시스템 개발자라면 대부분 경험을 가지고 있다. 

그렇지만 객체 지향(Object-Oriented) 기술이 발달하면서 재사용과 조립의 실천이 좀 더 원활해 지고, 무엇보다 표준 모델링 언어는 UML(Unified Modeling Language)이 등장하면서 체계적인 방법론의 정립이 가능해 짐으로 해서 객체지향 방법론이라는 커다란 울타리 속에서 컴포넌트 기반의 개발이 활개를 치게 된다.

기존의 개발환경보다는 새롭고 더 강력한 기능을 발휘하게 되는 객체지향 개발 환경이 도래하면서 시대적으로는 객체지향 방법론의 전성기를 맞이하게 되는데, 그 객체지향 방법론에서도 컴포넌트 개발과 컴포넌트 기반의 시스템 개발을 충분히 이야기 하고 있었다. 그런데 그 시대에는 왜 CBD 라고 이슈가 되지는 않았을까? 여기에서 CBD방법론이라고 하는 것의 정체가 드러나게 된다.

객체라는 것이 데이터의 보안을 강화하고, 인터페이스를 통한 재사용과 조립을 원활하게 하며, 좋은 객체는 좋은 유지/보수의 효율성을 보장하는 등 충분히 소프트웨어 자산의 컴포넌트로서 그 역할을 다 하고 있었지만 그 당시에 객체지향 방법론과 CBD 방법론을 같이 이야기 하지는 않았다.

B.      컴포넌트 기반의 아키텍처

거의 모든 객체지향 방법론에서 주장하고 있는 최선의 실천과제중의 하나가 “컴포넌트 기반의 아키텍처 사용” 이다.
아키텍처라는 것이 “시스템을 구성하는 핵심 내용들에 대한 논리적인 구조”라고 한다면, 그것을 컴포넌트 단위로 개발하고 결합해서 튼튼한 아키텍처를 구성하고 그 아키텍처 위에서 시스템을 개발하고자 주장하면서 개발환경에 맞는 적절한 아키텍처 스펙을 벤더들이 만들어 냈다.

초기에 개발자들은 그 스펙에 맞도록 프로젝트에서 직접 그 내용들을 구현하면서 진행하였고 그 결과들이 스펙에 반영되기도 하였다.
그러한 경험들이 쌓이면서 많은 벤더들은 시스템의 아키텍처에 해당하는 여러 가지 것들을 실제로 구현하고 그것을 상품화하여 프레임웍으로 제공을 하게 된다.
.NET 과 WebSphere, WebLogic 같은 WAS(Web application Server)가 그 대표적인 상품이다.
밴더들은 상품화된 프레임웍을 판매하기 위해서 새로운 Trend를 만들 필요가 있었고 그 결과로 나타난 것이 CBD 방법론이다.
 CBD방법론이 만들어지고 그 방법론의 실천을 위해 프레임웍이 제공되었다기 보다는 프레임웍을 사용하기 위해 CBD 방법론이 만들어 졌다고 보는 것이 더 맞을 것이라는 것이다.

사실 CBD 라는 Trend는 존재하지만 CBD 방법론이라고 새롭게 등장한 것은 없다.
RUP(Rational Unified Process), UML Component, MaRMI 등 소위 CBD 방법론이라고 칭해지는 방법론들은 그 역사는 오래하면서도 자기들이 객체지향 방법론이다, CBD방법론이다 라고 이야기를 한적은 없다.

단지 소프트웨어 개발 방법론을 만들었는데 객체지향 패러다임을 적용했고, 컴포넌트 기반 개발의 효율성을 실천할 수 있도록 그 절차를 포함하고 있다고 메타레벨에서 이야기 하고 있지, 그 방법론들이 스스로 CBD 방법론이다라고 이야기 한적은 없다는 것이다.

 그러한 다양한 방법론들은 시간을 거치면서 시대의 흐름과 기술 환경에 맞추어 그 내용을 업데이트 하면서 발전해 온 것이지 갑자기 CBD 방법론이다 라고 탄생한것은 아니라는 것이다.
 객체지향 패러다임으로 paradigm shift 를 하면서 그 내용이 기존의 방법과는 확연하게 바뀌었고 처음부터 컴포넌트 기반의 개발 문제도 당연히 다루고 있다.

그런데 어느 때부터인가 신문과 뉴스에 CBD 가 대세인 것처럼 다루기 시작하더니, 갑자기 .NET 이나 WAS를 쓰지 않으면 CBD 가 아닌 것처럼 이야기하는 상황까지 되어버린 것이다.

 메시징 서비스, 트렌젝션 관리, 보안 등 아키텍처적으로 중한 이슈들을 API성격의 컴포넌트로 개발해 두고 그것들을 동일한 프레임 웍 상에서 운영되도록 제공하는 벤더들의 제품이 나쁘다는 것은 아니지만 많은 사람들이 단지 그러한 상용화된 컴포넌트 기반의 아키텍처를 사용하는 것이 CBD의 전부라고 생각하게 만드는 것이 안타까울 뿐이다.

물론 개발자가 직접 개발하는 것보다 벤더들의 노력이 많이 들어간 상용화된 제품이 품질면에서나 효율성면에서나 탁월한 것이 사실이기에 많은 개발자들이 노력을 들이며 그것을 배우려 하는 것일 것이다.

그렇지만 CBD 방법론 의 문제는 다르다.
기존의 객체지향 패러다임 중심의 방법론에 중간중간 컴포넌트 내용을 집어 넣어 그것이 새로운 CBD 방법론인것처럼 떠들면서 사용자들에게 오히려 애매모호한 환경만 가중시켜, 새로운 것이지만 새로운 것이 없는, 단지 비싸게 돈을 들려 벤더들의 제품 구입에 비용을 지불하게 되는 그러한 상황을 생각해 보면서 이 CBD방법론이라는 것이 과연 필요한 것인가 하는 의구심마저 들게 한다.

C.      현실적인 CBD 방법론의 구성

CBD 방법론이 새로운 시대적 흐름의 방법론이 되려면 기존의 방법론과는 분명히 차별되는 것이 있어야 한다.
기존의 객체 지향 방법론들이 객체지향 패러다임 중심의 시스템 개발 내용을 집중적으로 조명하면서 컴포넌트 개발이나 관리에 대해서는 정확한 방안이나 시스템적인 체계를 제공하지 못하는 것에 대해서, CBD 방법론이라고 한다면 그에 대한 좀 더 발전된 모습이 있어야 한다는 것이다.

그렇다면 이제부터 CBD 방법론은 어떠한 내용이 있어야 하는 것인가에 대해서 고민해보도록 하자.
 CBD 가 되기 위해서 필요한 절차적 방법에 어떤 것들이 있어야 하고 그것 들을 기존의 방법론들과 비교하여 생각한다면 CBD 방법론의 필요성에 대해서 좀 더 나은 상황인식이 될 것이다.

CBD가 되기 위해서는 CBD 에 두 가지 영역이 있다는 것을 인식 해야 한다.
그것은 CD(Component Development)의 영역과 CBSD(Component Based System Development)의 영역 두 가지이다.
컴포넌트 기반의 개발을 위해서는 컴포넌트가 존재해야 한다는 전제가 반드시 필요한 것이기에 컴포넌트 자체를 개발하는 CD영역이 있고, 그렇게 만들어진 컴포넌트를 이용하여 시스템을 구축하는 방법이 별도로 필요하기 때문에 CBSD의 영역이 있는 것이다.
이 구분이 지극히 당연한 것임에도 불구하고 많은 방법론과 실제 프로젝트에서는 그 영역의 존재조차 인식하지 못하는 경우가 허다하다.

먼저 CD 영역을 살펴보자.

컴포넌트를 개발하기 위해서도 일반적인 소프트웨어 개발에 필요한 절차에서 처럼 컴포넌트 개발을 위한 요구사항을 정의해야 할 것이다.
컴포넌트 자체에 대한 요구사항을 정의한다라는 것은 컴포넌트가 제공하는 하나 이상의 인터페이스를 정의하고 그것이 지니는 오퍼레이션(컴포넌트가 제공하는 기능)을 정의하는 것이다.
 여기에서는 인터페이스 정의서 정도가 산출물로 필요할 것이다.

그 다음에는 컴포넌트의 인터페이스에 정의된 오퍼레이션을 구현하기 위한 분석과 설계의 과정이 필요하다.
 최근의 업데이트된 방법론들에서는 이 부분을 Operation analysis, operation design 이라고 이야기하고 있다.(개인적으로 사용하였던 용어가 유명한 방법론에서 똑같이 사용하고 정의해 주니 고마울 따름이다.)
그리고 그 내용을 구현하고 테스트를 거쳐 컴포넌트 저장소에 넣어 관리하게 될 것이다. (이 과정들이 진행되는 동안 형상변경관리가 적용되는 것도 좋겠다.)

전체적인 과정은 요구사항정의 – 분석 – 설계 – 구현 – 테스트 – 배포 의 일반적인 소프트웨어 개발라이프 사이클을 따르겠지만 그 단계단계의 진행되는 내용들은 일반적인 소프트웨어 시스템 개발 프로세스와는 다른 점들이 많을 것이다.

비즈니스 컴포넌트를 생각한다면 그 컴포넌트의 요구사항 정의를 위해서 비즈니스 모델링이 먼저 진행되어야 할 것이고, 소프트웨어 시스템의 아키텍처를 구성하는 컴포넌트를 개발하고자 한다면 그 컴포넌트의 요구사항을 획득하고 정의하는 시점에 따라 다른 진행이 있을 것이고, 개발하고자 하는 컴포넌트가 또 다른 사용컴포넌트를 이용하게 되어 CD 자체가 CBSD가 되어버리는 등 과거의 방법론들에서 제공하지 않았던 내용들이 나타나게 된다.

 소위 CBD 방법론이라고 하는 기존의 방법론들의 내용들을 살펴보면 CD 부분의 내용이 아주 약하게 되어 있거나, CD를 다루더라도 위에서 언급한 프로세스적 내용이 약하게 되어 있다. 이것은 컴포넌트 기반의 아키텍처 사용의 측면을 강조해서 방법론을 전개하다 보니 당연히 컴포넌트 자체를 개발하는 부분을 간과하게 된 것이다.
지금 까지 CBD 방법론을 살펴보았고, CBD 의 CD 의 영역에 대해서 간단하게 흐름을 집어 보았다. 이번에는 CBSD 의 흐름을 짚어보고 CD 와 CBSD의 상호관계적인 흐름을 살펴 본다.