[펌] CBD 개론.

◈	서론
◈	CBD의 유래, 현황및 전망
	- 정보시스템의 계층적 아키텍쳐 - Business Component - Component의 재사용성과 응용Framework - Web Service Component
◈	CBD로의 전환대책
◈	결론
◈	참고문헌

 

서론

 

CBD(Component-Based Development)라 함은 SW를 구축하는데 있어 부품을 조립하여 완제품을 만드는 방식이다. CBD는 한 때의 유행이 아닌 장기간에 걸쳐 발전된 SW 산업의 한 진화 형태이다. CBD는 SW 개발 기술 만의 변화가 아닌 SW 산업 및 시장 전반에 걸친 구조적 변화이다. CBD 기술 자체도 앞으로 상당 기간 계속 변화가 일어날 것이며, CBD가 산업, 시장에 미치는 효과 또한 계속적인 변화가 다가오고 있다.

CBD 기술은 Client/Server 시대에 그 기초가 마련되어, Internet 시대에 들어 SW 구축 Paradigm의 주류가 되었으며, 이러한 추세는 (세계 경제 구조, 기업 경영 환경 및 IT 기술의 변화에 따른) 기업의 SW 수요 Pattern의 변화에 대한 SW 산업의 대응이었다고 해석할 수 있다.

CBD는 Internet 시대의 성공적인 기업이 필요로 하는 끊임없는 경영 혁신, 신속한 사업 기회의 포착, 관련 기업들과의 Win-Win Networking, 모든 고객과의 1:1 관계 등을 지탱해주는 제반 정보 시스템의 구축 전략인 것이다 [15]. CBD는 Component 단위의 개발, 조립, 유지보수를 통해 현대 경영이 필요로 하는 정보시스템의 신속한 구축(Time to Market), 변경 확장의 용이성(Flexibility)와 타 시스템과의 호환성(Interoperability)를 달성하고자 하는 SW Engineering 프로세스, 방법론 및 기술의 총체적 개념이다 [24].

1990년대에 기업 내 BPR 및 기업 간 정보 시스템의 정태적 연결이 미국 경제의 전성기를 가능케 하였다면, 2000년대의 새로운 경영 환경에서는 Internet을 기반으로 한 기업 간 실시간 BPR(Inter-Organizational Real-Time BPR) 및 기업 간 정보 시스템의 동태적 연결/해체(Dynamic e-Business)가 기업 경쟁력의 차별화 요인이 될 것이며, CBD는 이를 뒷받침하는 핵심 기술 역량인 것이다.

 

CBD의 유래,현황 및 전망

 

1970년대부터 작게는 컴퓨터 프로그램의 코딩, 크게는 SW 시스템의 구축에 대한 방법론이 정립되어 왔다. 그 당시의 구조적 분석, 설계 및 프로그래밍 방법론[21]에서 강조되던 것을 몇 가지 살펴보면, 첫째 모듈화(Modularization)가 중요하다. 각 모듈은 기능적으로 응집력이 강하며 (Functionally Cohesive), 모듈 간의 상호작용은 최소화되어야 (Loosely Coupled) 한다는 것이다. 둘째 각 모듈은 그 Interface 만을 외부에 공표하고 내부의 Data Structure나 Algorithm은 숨겨야 한다는 (Information Hiding) 것이고, Data Structure 값의 변경은 그 Data Structure에 특유하게 정의된 Operation을 통해서 한다는 (Encapsulation) 것이다. 셋째로 복잡한 프로그램이나 시스템은 Divide & Conquer, 즉 Top Down Decomposition에 의해 분석, 설계, 구현되어야 한다는 것이다.

그 후 1980년대에 등장한 객체지향적 분석, 설계 및 프로그래밍에서는 Encapsulation이 Syntax로 실현되면서 Inheritance와 Polymorphism이 추가되었다. 또한 80년대에 정보시스템 구축 방법론의 주류를 이뤘던 정보공학(Information Engineering)[20]에서는 Relational Database의 Data Model(즉 Entity-Relationship Diagram)을 중심으로 Application을 구축하는 방법이 체계화되었다. CBD는 그 전신인 구조적 및 객체지향적 방법론과 정보공학에서 강조하는 모든 개념을 그대로 이어 받는다. 단 Inheritance와 Polymorphism은 대형 시스템 구축 및 유지보수에 있어서의 逆기능 때문에 배제하고 있다,

그렇다면 CBD의 무엇이 새로운 것인가?

 

 

◈ 정보시스템의 계층적 아키텍쳐

1990년대 중 정립된 CBD는 기업용 SW의 구축에 있어 계층적 아키텍쳐(Tiered Architecture 또는 Layered Architecture)를 전제로 한다. 1990년대 전반 Client/Server System의 기본 아키텍쳐가 정립되면서, 모든 기업용 SW는 최소한 User Interface (UI) Layer, Business Logic Layer 및 Database Layer의 3 계층으로 구성된다는 데 전 SW 산업의 공감대가 형성되었다 . 이어 Business Logic Layer가 Business Process Layer와 Data Access Layer로, 다시 90년대 후반에 들어 Business Process Layer가 Facade Layer, Process Control Layer 및 Business Rule Layer로 분화되는 과정을 보인다. SW Component도 따라서 GUI Component와 Business Component로 구분되며, 후자는 Business Logic Layer에 속하는 Sever-Side의 Component인 것이다. 표 1에는 정보시스템의 3-Layer Architecture 상의 각 Layer별로, 또한 SW 구축 Life Cycle의 각 단계별로 정의, 창출해야 할 주요 요소들을 나타내는 3*3 Matrix를 제시하였다. 표에서 보듯, 정보시스템 구축에 있어서는 우선적으로 Business Architecture가 정해져야 한다. Business Architecture는 사용자(Actor)가 처리할 Business Event 들(예컨대 고객으로부터의 판매주문), 각 Event가 발생했을 때 사용자가 수행해야 할 단위 업무들과 업무처리Flow(Work Flow), 업무 처리 시 준수해야 할 표준 프로세스 및 회사 규정들이 밝혀져야 한다. 또한 업무처리에 필요한 Data 및 정보와 업무처리 시 창출, 변경되는 Data를 개념적으로 정확히 정의해야 한다. 앞서 언급했듯이, 무엇보다도 Business Process 및 Rule을 과감히 개선하는 것이 시스템 투자의 ROI를 높이는 데 관건이 된다. 다음으로는 SW Architecture를 설계해야 한다. CBD에 있어서는 먼저 사용자의 각 단위업무를 실행할 Operation(Computer Program 상 최소 단위의 Subroutine)들을 정하고, 다음 이 들을 포함할 Class(또는 Program Module)들을 설계한다. 다음엔 각 Business Event에 대응하는 Business Process(또는 그 Subprocess들)별로 Process 완수를 위해 어느 Class의 어느 Operation들이 어떤 순서로 실행되어야 하는지를 정한다. 이제 Business Event, Business Process 또는 구성 Subprocess 관점에서 빈번히 같이 쓰이는 Class들을 하나의 Business Component로 Packaging해 나아가면 Component-Based SW Architecture가 구축되는 것이다. 분석 및 설계 단계에서 여러 개의 밀접히 관련된 Class들을 하나의 Component로 묶음으로써 시스템의 Component화가 이뤄지면, 시스템 개발의 프로젝트 관리나 시스템의 유지보수, 확장에 있어 효율이 현저히 증대된다. 예를 들어 ERP 시스템의 경우 그 안에 포함된 Class의 수는 수만에 이르지만, Business Component의 수는 수백 수준으로 제한된다. 따라서 오늘날 대형 정보시스템 들에 대해서는 Class보다는 Abstraction-level이 높은 Component 단위로 개발, 유지, 보수, 교체하는 것이 정상적인 방법으로 간주되고 있다. 이는 앞서 2장에서 언급한 CBD의 세가지 기본목적 -Time to Market, Flexibility 및 Interoperability-중 Flexibility를 성취하는 데 해당한다고 하겠다.

 

◈ Business Component

오늘날 CBD는 Business Component의 발굴, 제작에 힘쓰고 있다. Business Component는 어느 특정 Domain의 Business Process나 그에 기여하는 단일 업무 Step을 처리해주는 Server-Side의 독립된 SW 모듈이라고 보면 된다. 즉 Business Component는 Functionally Cohesive, Loosely Coupled, Encapsulated SW 모듈인 것이다. 예컨대 판매주문 처리프로세스나, 또는 보다 작게는 그의 한 Step인 송장발급 업무가 하나의 Business Component로 실현될 수 있다. Business Component는 여러 프로젝트에서 재사용할 수 있어야 좋고, 나아가 기업 간, 업종 간, 응용 Domain 간에 널리 공용될 수 있으면 더욱 값진 것이다. 왜냐하면 한번 잘 만든 부품이 여러 시스템에 쓰이면 그만큼 개발생산성과 품질이 향상되고, Cost는 저하되기 때문이다. GUI Component보다는 Business Component 개발이 업계의 초점이 되고 있는 이유도 후자가 업종 및 응용 Domain에 대한 전문지식을 담고 있어 그 재사용 시 생산성 증가, 품질 제고 및 원가 절감 효과가 현저하기 때문이다. 1990년대 후반 이후 CBD의 발전은 무엇보다도 Business Component의 개발을 용이하게 하고 그 실행을 지원하는 Middleware의 발전에 힘입은 바 크다. CBD 기반기술의 양 축을 이루는 Microsoft의 COM+와 SUN의 J2EE는 각기 MTS와 EJB Container를 Middleware로 깔고 있으며, 이들 Middleware가 Server-Side의 Business Component가 필요로 하는 Database Connectivity, Component 간 호출, TP Monitoring, Load Balancing, Fault Tolerance 등의 기본기능을 제공한다 [27]. 더욱이 COM+는 Component의 개발 언어에 무관하게 Component 간의 호환성을 보장하며, J2EE는 한 Component가 상이한 Operating System에서 구현될 수 있도록 보장한다. 이와 같은 언어독립성(Language Independence)과 운용환경독립성(Operating Systems Independence)이 Component, 또한 Component Interface로 Wrapping된 Package Module이나 Legacy Application 상호간의 호환성(Interoperability)를 제고한다. 다시 2장에서 언급한 CBD의 세가지 기본목적을 상기컨대, CBD에서는 국제적으로 널리 보급된 COM+나 EJB 등의 표준(De Facto Standard) 기술을 활용함으로써 Interoperability, 즉 상이한 시스템간의 호환성 및 통합을 쉽게 달성할 수 있는 것이다. Component Middleware 뿐 아니라, CBD의 분석, 설계 단계를 지원하는 Notation으로서 Unified Modeling Language(UML)[23]이 출현하여 국제 표준화되기에 이르고, 분석, 설계를 지원하는 방법론 [1][11][16] 및 CASE Tool(Rational, Together, Telelogic 등)이 발달하고, 또한 Component 기반의 SW를 구현하는 Tool(Microsoft의 Visual Studio, IBM의 WebSphere, BEA의 WebLogic 등)이 크게 발전함에 따라 Business Component 개발이 대폭 용이해 졌으며, 이 또한 CBD의 발전을 촉진했다.

 

◈ Component의 재사용성과 응용Framework

CBD의 3대 목적 중 하나인 시스템 구축의 신속성은 어떻게 강구되는가? 시스템 구축기간을 대폭 단축할 수 있는 가장 효과적인 길은 이미 개발된 Component를 재사용하는 것이다. 그러나 재사용성(Reusability)이 높은 Business Component를 만드는 것은 결코 쉽지 않다. 동종업종의 두 기업이 같은 종류의 응용 시스템을 구축(예컨대 한국통신과 AT&T가 요금징수 시스템을 구축)한다 하더라도, 각 기업이 다소 상이한 Business Rule 및 Business Process를 활용하기 때문에 공용할 수 있는 Component를 도출하는 데는 많은 분석 노력이 요구된다. 그 뿐 아니라 개별 Component의 범용성을 확보하기 위해서는 추가적인 프로그래밍 노력(예컨대 Plug-In Points의 삽입, 사용자 Configuration 기능의 추가 등)도 요구된다. 두 기업이 공용 Component를 활용하여 SW 구축 원가를 줄이고자 한다면, 무엇보다도 두 기업 간에 사전 협의를 통해 공통 요소 기능을 찾아내야 할 것이다. 이와 같이 Component 재사용의 활성화는 개발기법 및 기술의 확산뿐 아니라, 각 기업 내 표준 업무 프로세스의 정립, 동일업종 내 기업간의 프로세스 표준화를 위한 제휴, 특정 업종에 전문화된 공용Component 개발사의 출현, 업종별 Best Practice를 반영한 국제 표준 SW아키텍쳐 및 표준 Component 사양의 발전 등 어려운 고비들을 넘겨야 한다. 이러한 상황에서 1990년대 후반 CBD의 발전을 가속화 시킨 것이 B2C, B2B, B2E등 Web 응용 시스템의 신규 개발 붐이었다. 이 시스템들은 상당수의 공용 서비스 Component(Shared Service Component)를 내포하고 있다. 예를 들자면, User Profiling, Content Management, Cataloging, Search Engine, Shopping Cart, e-Payment, Event Notification, Authorization등이 많은 e-Commerce, e-Business 시스템에서 공통적으로 쓸 수 있는 기본 요소 기능들이다 [15]. IBM, BEA, Microsoft 등의 선진 SW 기업들은 공용 서비스 Component들을 개발하여, 그들의 주력 상품인 WebSphere, WebLogic, Windows DNA등의 Web Application Server(WAS)에 내장하여 판매하는 전략을 취하고 있다. 이와 같이 e-Commerce와 같은 특정 응용시스템에 필요한 공용Component들을 특정 SW Architecture를 전제로 만들어, 집합적으로 제공하는 것을 Application Framework라 부른다 [17]. Application Framework를 이용하여 어떤 응용시스템을 구축하는 것은, 이미 많은 기본부품을 결합해 놓은 반제품을 구입 한 후, 추가 가공하여 완제품을 만드는 것과 같다. 그림 2에는 응용Package, 응용Framework, Business Component, GUI Component 등 정보시스템 구축에 활용할 수 있는 Building Block들을, 표 1에 제시한 3´3 Matrix의 틀 안에서, 개발 Life Cycle 및 시스템 Layer를 기준으로 비교해 보았다.   1990년대 후반 많은 해외 SI 사업자들은 고객의 e-Commerce, e-Business를 구축해 줌에 있어 타사가 개발한 Application Framework를 이용, 빠른 납기에 고품질 시스템을 구현해왔다. 2000년 이후 WAS Tool들이 소위 Integrated Application Environment(IAE)로 발전하면서, 지금은 CBD 개발 Tool, Application Server, Application Framework 뿐 아니라 EAI, Wireless Access 및 Web Service등의 부가기능을 제공하고 있어, IAE를 활용한 B2C, B2B 및 B2E 개발이 세계적으로 보다 확산될 추세를 보인다.

 

◈ Web Service Component

2001년에 들어 본격화되고 있는 Web Service 기술 및 산업의 발전은 IT 역사의 제4.5세대라 불러도 될 만큼 기업 정보시스템에 혁명적인 영향을 미칠 전망을 보인다. Web Service를 정의하자면, 이는 Loosely Coupled, Business Component로서, 그 서비스를 XML, SOAP 등 국제표준 기술 만을 이용하여 Internet을 통해 제공하는 그러한 Component이다. Web Service 기술의 출현은 CBD에 의한 정보시스템 구축을 보다 쉽게 하면서 CBD의 利點을 보다 강화시키는 결과를 가져오고 있다. 우선 Web Service Component는 종래의 COM+, EJB등과는 달리 각 Component를 실행시키고 있는 Platform에 무관하게 상호간 완벽한 호환성을 보장한다. 이는 Web Service Component 간의 호출이 XML, HTTP, SOAP등 표준 Internet 기술 만에 의존하기 때문이다. 또한 Web Service Component들은 Universal Description, Discovery and Integration(UDDI)라는 Component 등록 메커니즘을 통해 동태적으로(On the Fly) 결합되면서 복합적 서비스를 창출할 수 있다. 이와 같이 Web Service 기술은 종래의 COM+나 EJB 기술보다 Business Component들을 더 크고 복합된 기능을 가질 수 있도록 하고, 보다 쉽고, 싸게 개발할 수 있게 하고, 또한 Business Component의 조립에 의한 정보시스템의 구축을 보다 동태적으로 유연하게, 빠르게 하는 효과를 가지고 있다 [26]. Web Service Component의 개발 및 조립을 Service-Oriented Development of Application (SODA -오렌지 소다에서와 같이 ‘소다’로 읽힘)라 부르기도 하고, SODA의 지원 Tool을 IAE와 구분하여 Integrated Service Environment(ISE)라 부르기도 한다. 향후 당분간은 현재의 대표적인 IAE Tool들이 ISE 기능을 추가 제공할 전망이다. 또한 당분간 Web Service Component들은 COM+나 EJB Component를 XML Interface로 Wrapping한 형태로 개발되고 있다. 이와 같이 기술적인 면에서 보면 Web Service는 Business Component의 진화 연장선 상에 있는 것이다. 그러나 기업 경영 관점에서 보면, Web Service는 또 하나의 새로운 혁명을 야기할 것으로 기대되고 있다. Web Service는 그 동태적 유연성으로 인해 ‘Dynamic e-Business’, ‘Dynamic e-Marketplace’라는 새로운 응용 시스템들의 창출을 가능케 할 것이다. 또한 구축의 용이성 및 원가 하락을 통해, CBD에 의한 e-Business 구축 및 참여를 종래의 대기업 중심에서 중소 및 개인기업으로 까지 크게 확산시키는 효과가 있을 것으로 전망되고 있다. Web Service 기술의 궁극적인 성공은 同 기술의 표준화 진척도, Internet이라는 Global Network의 성능 및 신뢰도, 또한 무엇보다도 성공적인 Dynamic e-Business Model의 개발과 그의 기업 간 재사용성 등의 변수에 의해 좌우될 것이다. 특히 Web Service의 매체인 Internet의 불완전성 때문에 최소한 당분간은 Web Service의 활용이, 실시간 처리 및 높은 Throughput을 요구하는 OLTP 등 기간 업무 분야보다는, 비교적 경영 상의 중요도가 떨어지며 다소 간의 처리 지연도 허용될 수 있는 EP, e-Learning, Information Push 등의 응용 분야에 국한될 가능성이 크다. 해외 IT분석기관의 CBD 관련된 조사 결과를 몇 가지 소개하면 다음과 같다. ▶ META Group에 의하면, 세계 2000大 기업들이 200년까지는 대부분 SW Factory 방식을 채택하여, SW 개발자들은 Craftsmanship에서 Assembly/ Reuse 문화로 전환하고, 신규 구축되는 응용시스템 들은 Component-based, Message-based, Event-driven 및 Multi-tier Design의 특성을 갖춤. ▶ Forrester Research에 의하면, 2001년까지 Component 기반의 시스템 구축이 크게 증가, 공용 서비스 Component의 시장이 본격적으로 형성됨. ▶ Gartner Research에 의하면, 2002년까지 세계 Component 시장이 연평균 35% 성장하여 70억불에 이름. ▶ Gartner Research에 의하면, 2002년 말 까지 매출 1억불 이상의 대기업 중 75%가, 2003년 전반기 말 까지 1억불 이하 중소기업의 50%가 Web Service를 경영에 활용할 전망임. ▶ Gartner Research에 의하면, 2003년까지 Web Service Component의 세계 시장 규모가 17억불에 이를 전망임. ▶ Gartner Research에 의하면, 2004년까지 CBD 개발방법 및 Component Repository를 갖춘 기업은 그렇지 못한 기업에 비해 5-10배의 생산성 우위를 확보함.

 

CBD로의 전환 대책

 

세계적인 SW 산업의 변천 추이로 볼 때, 우리 나라 SW 업체들도 SW 개발 체제를 하루 바삐 CBD로 전환해야 겠다는 데 대해서는 의심의 여지가 없다. 기업의 CBD 능력은 지속적인 사업 구조 조정 및 신규 사업 창출이 불가피한 21세기의 경영환경에서 필수적으로 확보해야 할 기업 핵심 역량으로 간주되고 있다. 선진국에서는 CBD가 90년대 중반부터 본격화되어 이제는 기업 정보시스템 구축 방식의 主流가 되어 있다. 국내에서도 금융, 국방 부문을 선도로 CBD에 의한 정보시스템 구축을 요구하기 시작했으며, 향후 그 수요가 급증할 전망이다. 정통부에서도 CBD의 중요성을 인지하고 1999년 이래 SW Component산업 육성정책을 시행해 오고 있다. 그러나 문제는 CBD로의 전환에는 여러 가지 역경이 도사리고 있다는 데 있다. 이제 CBD로 전환함으로써 거둘 수 있는 이득이 무엇인지, 전환을 위해 갖추어야 할 조건이 무엇인지를 살펴 보자. 앞에서 언급한 바와 같이, 어떤 응용시스템을 CBD로 구축한다 하면, Server-Side의 SW를 몇 개의 어떤 Component로 조립할 것인가를 정해야 한다. 이들 Server-side Component들은 Business Process Layer의 Component일 수도 있고, Data Access Layer의 Component일 수도 있다. 또한 보다 계층의 수가 많은 SW Architecture를 전략적으로 선택했다면, 그 외의 Layer에 속하는 Component일 수도 있겠다. 여기서 강조하고자 하는 것은 구축하고자 하는 응용시스템에 대한 Layered Architecture를 명확하게 설계하고 각 Layer에 속하는 하나 하나의 Component의 명세를 정의하는 것이 CBD의 본질이라는 점이다. 따라서 구축할 정보시스템의 Architecture를 정립하는 것이 선행되어야 하는데, 국내에는 Architecture기반의 시스템 구축이 활발히 실천되지 못하고 있는 실정이다. Component의 재사용성을 확보하는 것은 더욱 어렵다. 이를 위해서는 무엇보다도 Component를 재사용하고자 하는 업무영역에 있어 업무 프로세스, 규칙 및 사용정보의 정형화 내지 표준화가 이뤄져 있어야 한다. 업무 프로세스의 Modeling, 표준화 및 Reengineering이 습관화되어 있지 않은 국내 기업 들을 대상으로, 공통 범용 기능을 추출하여 재사용성이 높은 Component를 도출하는 데는 많은 업무 현황 분석 및 프로세스 정비 노력이 수반되어야 할 것이다. CBD를 수행하는 개발조직 측면에서는 우선 UML 기반의 CBD 프로세스, 방법론 및 Tool을 완전히 소화하여 적용할 수 있어야 한다. 선진국에서 이미 개발된 Enterprise Architecture, Application Architecture, Business Component 들에 대한 많은 사례 분석과 함께 SW Pattern[8][12][13]에 대한 깊은 연구를 통해 재사용성이 높은 Component를 설계할 수 있는 역량을 키워야 한다. 또한 일차 개발된 Component를 여러 정보시스템에 적용하면서 그 재사용성을 확장하는 지속적 개선 노력을 기울여야 한다. 보통 한 Component가 재사용성이 높도록 가다듬어지려면 3-4 차례의 실 프로젝트 적용을 거쳐야 한다는 것이다.

그림 3. 기업 내의 CBD 성숙 단계

그림 3에는 한 기업이 CBD를 채택하여 성숙시켜 나아가는 데 있어 전형적으로 겪게 되는 몇 가지 단계를 도시하고 있다 [31]. CBD의 초보단계(그림 3의 2단계)에서는 최소한 시스템을 앞에서 설명한 3-Layer Architecture로 개발하면서 Server-Side의 Business Logic을 COM+나 EJB로 구현하는 단계이다. 이 단계에서는 보통 구축 완료 시에 다른 프로젝트에서 재사용 가능한 Component가 확보된다거나, 또는 구축 과정에서 기 개발된 Component가 재사용되지는 않는다. 이 단계의 CBD는 개발 생산성을 향상 시키지는 못한다. 그러나 유지, 보수, 확장을 용이하게 하고, 구입한 Package 등 외부시스템과의 호환성을 높이는, 장기적으로 지속되는 긍정적 효과를 발휘한다. 그렇다면 기존 Component를 재사용하고, 재사용성이 높은 신규 Component를 만들려면(즉 그림 3의 4단계로 도약하려면) 무엇이 필요한가? 첫째로는, 특정 Business Domain(예컨대 PC 조립 母기업에 회로부 부품을 공급하는 PC 부품업체의 재고관리)에 대한 경영학적 전문지식, 同 Domain 분야의 여러 기존 정보시스템을 섭렵한 Application SW 전문지식, UML, CBD, Pattern 등의 SW공학 지식, 그리고 동 분야의 IT 기술 동향에 대한 전문지식을 두루 갖춘 사람이 필요하다. 선진국에서는 이들을 SW Architect라 한다. Bill Gates의 Microsoft 내 직함이 Chairman and Chief SW Architect인 것도 SW Architect의 중요성을 나타내는 한 예라 하겠다. SW Architect는 구축할 정보시스템의 분석단계에서 이미 재사용할 수 있는 Component를 정의해 나아가기 시작할 수 있는 역량을 갖춘 사람이다 (그림 3의 3단계). 둘째로, 재사용 범위를 전 조직차원으로 확대해 나아가기 위해서는 전사차원의 CBD/Reuse 조직을 결성하여, SW개발 및 관리 표준을 수립하고, 전사차원의 Enterprise Architecture 및 응용 Domain별 표준 Architecture를 정립하고, 공용 Component를 도출하여 기업 내의 자산으로 Repository에 축적 재사용해 나아가야 한다. 더 나아가 기업 간 공동으로 재사용할 수 있으려면, 해당 기업 간에 업무프로세스에 대한 합의가 선행되어야 하며, 이 합의가 경우에 따라서는 Component의 수요/공급기업을 다수 포함한 Consortium을 통해 집합적으로, 때로는 특정 수요 또는 공급업체 또는 정부의 Leadership을 통해 선도적으로 이뤄질 수 있다 [34]. 예컨대 PC 회로부 부품업체를 위한 재고관리용 Component의 경우 한국의 동종 업종 내 여러 회사가 제휴하여 공동개발하고 공용할 수 있다. 미국의 경우 연방정부가 350명의 SW 전문가를 투입하여 14개월에 걸쳐 50개 주정부, 수많은 County 및 시정부가 표준으로 따라갈 e-Government Architecture를 개발, 지난 3월 발표하였다 [28]. 이 Architecture 속에는 Shared Service Component들이 명시되어 있어, 한 개의 Component 개발로 전국의 수많은 정부기관들이 재사용할 수 있도록 하고 있다. 이와 같은 재사용 노력 없이 각 정부기관 마다 별도의 시스템을 구축할 때 정부예산의 막대한 낭비가 불가피 하다. Microsoft는 .Net 환경에서 전세계가 공유할 수 있는 Web Service Component들을 개발하여 MyServices라는 Framework로 제공하고 있다 [22]. 재사용이 실현될 경우의 혜택은 자명하다. 개발공수 절감, 생산성 증가, 원가 하락, Time-to-Market의 단축을 통한 Business 기회의 선점, 부품 단위의 개발, 유지 보수, 교체 및 확장에 의한 사용자 요구 변화에의 신속한 대응, 검증된 SW 부품들의 재사용을 통한 품질 향상 등이 그 것이다. 또한 SW 수출이 총매출 대비 3%에도 못 미치는 우리 나라의 경우, 선진국형 재사용 위주의 SW Architecture를 적용함으로써 구미 및 기타 지역에 SW Component를 수출할 수 있다는 점도 간과할 수 없다 [32]. SW진흥원의 조사에 따르면, SW 산업의 수출비율이 최근 대만은 33%, 이스라엘은 47%, 인도는 70%, 아일랜드는 88%에 이르고 있다. 우리도 이제는 지금까지 큰 성과를 거두지 못해온 SW 완제품보다는 SW Component로 수출시장에 본격적으로 도전해 보아야 하겠다. 기업이 CBD 역량을 보유키 위해 갖추어야 할 필수 조건들은 다시 정리해 보자. 자동차 신제품을 개발할 때 전체 설계도면(Blueprint)에 입각하여 부품 하나 하나를 CAD를 이용해 디자인하듯, SW 전체 Architecture를 디자인 할 수 있는 SW Architect의 양성이 무엇보다 중요하다는 점은 기 언급하였다. 자동차의 생산공정 설계가 생산성 및 생산되는 제품의 품질에 결정적 영향을 주듯, CBD 프로세스 및 방법론을 설계할 수 있는 SW Process Engineer(SPE)의 양성이 또한 요구된다. 한편 자동차 설계에 CAD Tool이 필수적이듯, CBD를 위한 분석, 설계 및 구현 Tool에 정통한 Tool 전문가(Tool Smith)의 양성도 빼 놓을 수 없다. CBD는 최신 Platform 기술(J2EE, .Net, Web Application Server, XML-Based EAI등)을 활용하므로 그 각 부문의 기술 전문가도 필요하다. 세계 및 국내시장에서 널리 재사용될 수 있는 SW Component 제작을 위해서는 국제 표준의 파악 및 국가 표준의 수립을 선도해 나아갈 수 있는 경영학, 산업공학, SW공학, 전산학 등의 학제간 연구 집단이 조성되어야 하며, 그들과 SW 기업들 간의 産學硏 협동이 시급하다. CBD를 추진하는 것이 기술역량 및 Domain 지식의 확보만으로 되지 않으며, 기업 내의 SW 재사용 체제 확립을 위한 문화, 조직, 보상제도 등의 개혁이 뒷받침해 주어야 한다. 재사용을 활성화하기 위해서는 기업이 통합된 Architecture(Enterprise Architecture)를 수립하고, 각 부서의 응용시스템들이 공유할 수 있는 Component를 SW Repository에 준비하여 제공해야 한다. 또한 장기적인 Vision을 수립하여, 직원들에게 많은 교육과 초기 투자를 아끼지 말아야 하며, 재사용률이 높은 부품을 만들어 낸 사람에게는 그에 상응하는 보상을 하는 등의 인사, 재무 등의 제도 개혁도 병행해야 한다. 또한 개발자 각자가 공정 단계마다 재사용성을 고려하여 분석, 설계, 개발하는 습관과 노력을 기울여야만 할 것이다. 한편 정보시스템의 구축을 필요로 하는 발주처도 CBD의 利點을 인식하여, 개발원가를 개발공수 기준이 아닌 시스템 전체의 Function Point 기준으로 산정함으로써 기 개발된 Component의 활용 시 그 자산가치를 인정해야만 한다. 특히 정부를 비롯한 공공부문에서 SW 개발원가 산정기준을 개혁하는 것이 국내 SW 산업의 CBD로의 전환에 가장 직접적인 유인책이 된다는 점을 강조하지 않을 수 없다.

 

결론

 

우리가 CBD를 추구한다 함은, 무엇보다도 70년대 이래 발전해 온 SW공학에서 강조하는 기본 원칙을 따르자는 것이다. 이들 원칙들은 SW의 품질 확보, 위험 통제, 원가 절감을 위해 필요한 것들이다. SW 개발자들이 기본 원칙을 이해하고 적용할 수 있다면, 그 때는 J2EE, .Net, EAI, IAE, ISE, ebXML 등 최신 기술의 도입을 통해 CBD를 보다 용이하게 수행할 수 있는 것이다.

그러나 IT 기술이 가능케 하는 경영혁신 Model을 한국 산업의 현실에 맞도록 개발하는 것, 또한 해외 시장에 수출할 수 있는 SW 제품 및 부품을 기획할 수 있는 역량을 마련하는 것이 신기술 투자에 앞서야 될 선결 과제이다. CBD는 이러한 새로운 Business Model의 개발, 기존 Business Process의 Reengineering 등 SW 설계 이전의 전략적 경영 기획을 강조하고 지원하는 방법임을 충분히 이해해야 한다.

우리 나라의 SW 산업이 SW 공학의 기본원칙을 적용하는 데 있어 미흡하다는 것을 부인할 수 없는 실정이다. SW 공학의 기본 원칙 및 국제 표준 기법의 교육 확산, 그 적용 여부의 감리, SW 개발인력의 자격 심사 등이 현 실정에서 중요하다고 보인다. 단기적인 J2EE, .Net 등의 기술 교육 만으로 CBD 소기의 목적을 달성할 확률은 극히 낮다. 더욱이 IT 기술의 변화 속도가 빨라짐에 따라 IT 기술에 대한 투자는 3-4년이면 그 효과가 감소하기 시작하는 데 반해, SW Process 및 SW Architecture는 기업 내에 축적되는 지식, 제도 및 문화로서 장기적인 핵심 역량으로 남는다.

부존자원이 빈약한 우리나라에서 SW산업은 국가경제상 전략산업일 수 밖에 없다. SW산업은 대표적인 지식집약형 산업으로 우수한 두뇌가 필요한 자원의 모두이다. 여타 산업에서와 마찬가지로 SW 산업에서도 제조(Programming) 능력보다는 설계(Architecting) 능력이 고부가가치 자원이며, 이는 무엇보다도 체계적인 교육의 강화를 통해 확보될 수 있다. CBD는 한마디로 Architecture 중심의 SW 구축 방법으로서 이의 보급이 시급한 실정이다.

 

참고자료

 

[1] Allen, P. and S. Frost, Component-Based Development for Enterprise Systems: Applying the Select Perspective. Cambridge University Press, 1998.
[2] Andrews, W., D. Plummer, D. Smith, “How Web Services Mean Business,” Gartner Research Note, May 2001.
[3] Blechar, M. “Component-Based Development,” Gartner Symposium/ITxpo 2000, Orlando, FL, October 2000.
[4] Business Week, “The Technology Payoff” McGraw-Hill, June 14, 1993.

[5] Business Week, “How Long Can This Last?-Strong Growth with Little Unemployment and Low Inflation,” McGraw-Hill, May 19, 1997.
[6] Business Week, “Silicon Valley on the Rhine,” McGraw-Hill, November 3, 1997.
[7] Cameron, B. et al. “Component Apps Realities,” The Forrester Report, June 1998.
[8] Coad, P. Object Models: Strategies, Patterns and Applications. Englewood Cliffs, NJ: Yourdon Press, 1995.
[9] Davenport, T.H. “Putting the Enterprise into the Enterprise System,” Harvard Business Review, July-August 1998.
[10] Downes, L. and C. Mui, Unleashing the Killer App, Harvard Business School Press, 1998.
[11] D’Souza, D.F. and A.C. Wills, Objects, Components and Frameworks with UML: The Catalysis Approach. Reading, MA: Addison Wesley, 1998.
[12] Fowler, M. Analysis Patterns: Reusable Object Models. Reading, MA: Addison Wesley, 1997.
[13] Gamma, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison Wesley, 1995.
[14] Hammer, M. and J. Champy, Reengineering the Corporation, New York: Harper Business, 1993.
[15] Hoque, F. e-Enterprise: Business Models, Architecture and Components, Cambridge, UK: Cambridge University Press, 2000.
[16] Jacobson, I., G. Booch and J. Rumbaugh, The Unified Software Development Process, Reading, MA: Addison-Wesley, 1999.
[17] Larsen, G. “Component-Based Enterprise Frameworks,” Communications of ACM, Vol. 43, No. 10, October 2000.
[18] Lee, S., I. Han and J.S. Park, "Effects of Organizational Characteristics on EDI Implementation in Korea," Telecommunication Systems, Vol. 14, No. 1-4, August 2000.
[19] Marinescu, F. “2001: The Year of Web Services,” Java Developer’s Journal, April 2001.
[20] Martin, J. Information Engineering: Vol. 1-3. Englewood Cliffs, NJ: Prentice-Hall, 1989.
[21] Martin, J. and C. McClure, Diagramming Techniques for Analysts and Programmers, Englewood, NJ: Prentice-Hall, 1985.
[22] Microsoft Corporation, http://www.microsoft. com/myservices/.
[23] Object Management Group, http://www.omg. org/technology/uml/.
[24] Park, J.S. “A New Revolutionary Paradigm of Software Development for Mainstream Business Operations,” International Journal of Technology Management Vol. 20, No. 3/4, 2000. pp. 272-286.
[25] Park, J.S. “Component-Based Development of eBusiness Solutions Using COOL:Plex,” CA-World Conference, Orlando, FL, July 2001.
[26] Park, J.S. “Component-Based e-Business Engineering,” 4th International Conference on Electronic Commerce Research, Dallas, TX, November 2001.
[27] PricewaterhouseCoopers, Technology Forecast: 2001-2003, Menlo Park, CA: PricewaterhouseCoopers Technology Centre, 2001.
[28] Sawhill, J.C. “E-Government: The Next American Revolution,” www.excelgov.org/ publication/enews/41/enews41_egov.htm, March 2001.
[29] Smith, D. et al. “The Future of Web Services: Dynamic Business Webs,” Gartner Research Note, April 2001.
[30] Vaskevitch, D. Client/Server Strategies, San Mateo, CA: IDG Books, 1993.
[31] Wilkes, L. “Component-Based Development,” Butler Group (www.butlerforums.com) 1999.
[32] 박준성, “CBD 시장 바로보기,” 디지털 타임즈, 2001. 8. 3.
[33] 박준성, “CBD에 대한 소고,” 정보통신연구진흥지 제3권 제3호, 2001. pp. 42-55.
[34] 오영배, 박준성, “CBD 적용 사례 연구,” 한국정보과학회 소프트웨어공학회지 제12권 제3호, 1999. 9. pp. 75-85.