CBD 방법론 (Component Based Development)

프로그래밍

by 라제폰 2008. 12. 13. 21:02

컴포넌트 중심 개발

e비즈니스를 성공으로 이끄는 로드맵

CBD ? 지금이 적기인가?
CBD ? 진정 새로운 것인가?
컴포넌트가 뭐길래?
컴포넌트에도 전략이 필요하다
CBD는 장애를 극복해야 한다.
CBD방법론 ? 실용적인 경로 채택으로 생존력을 길러야 한다.
CBD - 경쟁력 있는 우위를 점하려면.

1. CBD ? 지금이 적기인가?

만약 여러분이 CBD(Component Based Development)에 대해 아직 들어보지 못했다면 곧 알게 되겠지만, CBD는 개발 지연과 믿을 수 없는 품질 등 사시사철 지속되는 문제들을 돌파할 수 있는 최신의 개발방법으로서 최근에 관심을 끌고 있다.

관계형 데이터베이스, 4GL, CASE와 같은 기술 파도를 연속해서 뚫고 나온 많은 IT 관리자들은 CBD에 대해 회의를 품고 있지만 나름대로 일리도 있다. 그들은 이미 생산성이 대폭 증가를 이룰 수 있다는 열광적인 예측들로부터, 적은 투자만으로도 큰 효과를 얻어낼 수 있다는 것 까지 포함해서, 그 동안의 기술 결과들을 익히 보아 왔기 때문이다.

그렇다면 CBD는 지금까지 것과는 다른 것인가? 그것은 CIO들이 무시해도 될 만한 일시적인 기술 유행에 그칠 것인가? 아니면 IT분야에서 포용하고 인정해야 할 새로운 패러다임인가? 비용은 실제로 얼마나 들 것이며 거기서 얻는 이익은 무엇인가?

이 글에서는 CBD전망과 문제들에 대해서 조사하고자 한다. 여러분은 왜 CBD가 IT를 위한 진정한 주요 패러다임 변동인지, 그리고 왜 그것이 결국 널리 적용되어야 하는지 알게 될 것이다. 주요 회사들은 이미 CBD로 이동중이다. 그것이 새로운 개념이기 때문이 아니라 전략적 규범이 될 것이기 때문이다. 가트너 그룹은 2004년 까지 CBD 와 비즈니스 컴포넌트의 대규모 상품을 소유한 IS 조직들은 그렇지 않은 조직들보다, 5배에서 10배 까지 더 많은 생산성과 대응력을 가질 것으로 보고 있다.

많은 회사들은 그들이 계속 전통적인 방법으로 일하는 한, 경쟁자들의 앞서가는 생산성을 도저히 따라잡을 수 없게 될 것이다. 새로운 인터넷 경제에서, IT 솔루션과 비즈니스 성공 사이에 연관이 매우 밀접해 지면서, 많은 CIO들은 시스템 평가 방법을 재정립하고 있다. 기업의 어플리케이션 개발 능력을 향상시키는 일은 단지 효율성 개선 수준이 아닌 훨씬 더 큰 의미를 가지는 것으로 - 전략적 필요성으로 인식되고 있다.

CBD가 가져올 효과는, 열심히 뛰어서 회사의 응용프로그램을 인도해 주는 수준으로부터 더 나아가서, 그 자체가 경쟁력 있는 무기가 되는 것이다. CBD를 사용한 회사들이 새로 정교하게 만든 e비즈니스 어플리케이션을 배치하고 주도해 나가고 있을 때, 다른 회사들은 설계, 개발, 테스트, 디버깅 하느라 고생하게 될 것이다.

그림 1: CBD 전망

만약 CBD의 이점들이 그렇게도 극적인 것이라면, 왜 더 널리 보급되지 않았을까? 거기에는 산업 표준 미성숙, 기술 장벽, CBD기반 도구 부족, 좋은 조언자 부족, 실용 방법론 부족과 같은 몇가지 요인들이 있다. CBD의 전략적인 이점을 정확히 알고 있는 일부 기업들은 야심적인 CBD 프로젝트를 곧 진수할 차비를 차리고 있다. 위에 열거한 요인들 때문에 그 동안의 노력들은 실패를 거듭하였고, 그런 실패들은 IT조직들이 CBD에 대한 편견을 갖는데 기여했다. 그러나 지난 몇 년 동안의 기술 진보에 힘입어 위의 실패 요인들을 해결하게 되었고, CBD를 이용하여 성공을 경험하고 있는 조직들도 이제는 나타나고 있다. 이런 성공들은 CBD의 근본 전망을 확인시켜 주었다. 이렇게 중요한 추세인 CBD를 CIO들이 주시해야 되는 이유는 그에 내포된 전략성 때문이다.

Princeton Softech에서는 대규모 기업용 어플리케이션을 조직적으로 매일 개발하고 있다. 실용적이고 생산적인 스텝을 지키게 함으로서, 생존력 있는 CBD프로그램을 유도하고 있다. 그 곳에서는 여러 가지를 확인할 수 있었는데, 되는 것과 안 되는 것은 무엇인지, 맹점과 지름길은 무엇인지도 알게 되었다. CIO들은 너무 학구적인 것이나 난해한 이론들은 찾지 않는다. 그런 이론들은 실제 e비즈니스에 바로 적용할 수 없기 때문이다. 프린스턴 소프텍에서는 제품, 패턴, 프로세스, 요원을 결합한 독창적인 프로그램을 만들고, 기업 전체의 비즈니스 성공에 IT가 극적으로 기여할 수 있게 하고 있다.

2. CBD ? 진정 새로운 것인가?

모듈화modular 프로그래밍에 관해 들어본 사람이라면 컴포넌트의 기본적인 가치 명제도 이와 같다고 보면 된다. 큰 시스템을 관리하기 편한 조각으로 나누고, 식별되는 명세서 별로 인터페이스를 명확히 갖는 모듈로 구현하고, 문서로 정확히 나타낸 후, 소프트웨어 빌딩블록의 집합을 만들 수 있다. 개발자들은 빌딩 블록을 조립하여 어플리케이션을 마무리 짓는다.

오늘날까지 경험으로 증명된 바에 따르면, 개발자들이 외부 파라미터 위주로 컴포넌트를 호출하면, 컴포넌트의 내부 코드를 조사하여 그것을 프로그램과 연동시키는 것 보다, 작업을 완료하고 시험하는데 있어, 수십, 수백 배 더 빠르게 일을 마칠 수 있다.

그림 2: 캡슐화 된 기능은 인터페이스만을 통해서 이용 가능함

적절히 구현된 모듈화의 주요 이점중의 하나는, 개발자들이 결과를 내는 방법에 관해서는 신경 쓸 필요가 없다는 것이다. 단지 주어진 기능을 사용하면 되는 것이다. 예를 들면, 고정금리 대출이자 계산 모듈이 있다면 새로운 대출금 지불 시스템을 개발할 때 “재사용”할 수 있다. IT조직은 “바퀴를 재 발명” 하는 일과 같은 경우를 피할 수 있을 뿐만 아니라, 전체 개발 스텝에서 널리 사용될 수 있는 복잡한 로직을 가진 모듈을 미리 만들고 테스트하는 등 모자라는 IT 기술자들을 지렛대 효과로 활용할 수 있다.

모듈화 개념은 오랫동안 IT 조직에서 이용되어 왔다. 만약 그것이 컴포넌트 중심 개발의 전부라면 왜 CBD를 IT의 새로운 파도라고 귀찮게 권유하는가?

CBD가 힘을 얻고 있는 이유는 모듈화 이점을 대규모로 확장할 수 있게 되었기 때문이다. e비즈니스 세계는 궁극적으로 이기종 분산 컴퓨팅 환경이다. 미들웨어 수준에서 컴포넌트들은 이기종 플랫폼 마다 서로 다른 아키텍처와 언어, 표준화 장벽들을 극복할 수 있는 접착제 역할을 흘륭히 증명했다. CBD는 전자 상거래와 같은 다방면의 e비즈니스 어플리케이션 개발에서 선진적 방법을 지렛대로 쓸 수 있다.

다시 대출금 계산 루틴 예제로 돌아가서, 만약 이 모듈이 20년 전에 개발되었다면 그것은 관계형 DB가 출현하기 이전 환경인 메인 프레임에 배치되었을 것이다. 그 후에 조직이 클라이언트-서버 시스템으로 전환될 때 이 모듈은 호환성이 없었기 때문에 재사용할 수 없었고 따라서 재작성할 수 밖에 없었다. 더욱이 데스크 탑과, 브라우저 중심 어플리케이션 환경으로 구현되면서 호환성은 더욱 멀어졌고 당연히 재사용은 되지 않았다.

새로운 운영 시스템으로 진화되고 난 후, 새로운 플랫폼, 새로운 DBMS, 새로운 네트워킹 프로토콜, 새로운 프로그래밍 언어들도 진화되면서, 이때 호환성 문제들이 얼마나 복합적으로 얽히는지 우리는 알고 있다. 이것이 바로 관리를 잘하는 IT 조직들이 "모듈화 프로그래밍”을 오랫동안 가장 좋은 규칙으로 선택한 이유이다. 그러나 그들은 지속적으로 진화된 기술 아키텍처들을 지렛대로 이용하여 대규모 개발 방법론으로 발전시키지 못한 아쉬움이 있다.

그러나 이제, 모든 것이 변했다.

오늘날 모든 타입의 컴퓨팅 플랫폼들은 인터넷을 통해 상호 연동된다. 표준들이 등장하여 이기종 시스템들 사이의 비 호환성을 중화 시키고 있다. 사용자 인터페이스용 공통 프로토콜들도 태어났다. 벽이 허물어진 것이다.

오늘날 SQL을 사용하는 관계형 모델은 기업 데이터 관리 분야에서 사실상de facto 표준으로 부상하고 있다. 또한 이기종 분산 어플리케이션 미들웨어 표준으로서 COM+, CORBA, EJB(Enterprise Java Beans) 가 빠르게 성숙되는 것을 볼 수 있고, Java, Visual Basic과 같은 컴포넌트 기반 언어들이 e비즈니스 개발 표준이 되어가는 것도 볼 수 있다.

그림3: 표준화 진전으로 CBD가 성숙됨

혹자는 각각의 기술 간에 상대적인 장점들을 논하려 들지도 모른다. 그러나 언제나 얻을 수 있는 이점으로는 어플리케이션과 애플릿, 컴포넌트들이 개발되면 이기종 플랫폼에도 보급되어 수행될 수 있다. 이와 같은 상호연동은 CBD 패러다임으로 이동되면 나타날 수 있는 현실이다. 그렇게 되면 한 환경에서 개발된 소프트웨어 모듈은 다른 환경에서도 실행될 수 있게 된다.

패러다임이 이동되고 있는 증거로는 기술 컴포넌트들이 시장에서 번성하는 것을 보면 알 수 있다. 웹을 통해 컴포넌트들을 이용할 수 있을 뿐 아니라, 어떤 종류의 컴포넌트들이든지 다운로드할 수 있고 구매도 할 수 있다. 때때로 규격품widget이라 불리는 기술 컴포넌트들은 공통 기능들을 자동화하여 GUI 디스플레이 관리나 grid 컨트롤, 프린트 유틸리티 형태로 나오고 있다.

컴포넌트 시장은 더 높은 수준의 기능 분야로 확장되기 시작하였다. e비즈니스 어플리케이션 구축자들은 쇼핑 cart나 주문 관리와 같은 공통 웹사이트 작업을 다룰 수 있는 컴포넌트들을 획득해서 사용할 수 있다.

요약하면, 모듈화 개념은 새로운 것은 분명 아니지만, 이기종 환경에서 구현할 수 있는 능력은 새로운 것이다. CBD는 중요한 개발의 새로운 파도로서, 그것이 아주 새로운 아이디어라서 가 아니라, 품질과 생산성을 함께 이루고자 했던 이전의 생각들을 최근까지는 이루지 못하다가, 이제서야 실현할 수 있는 수단이 되었기 때문이다.

컴포넌트가 뭐길래?

위에서 말했던 것처럼, 컴포넌트는 그 본질이 개별 특성을 가진 소프트웨어 모듈이다. 그것은 패키지로서, 사용자에게 서비스를 제공할 수 있도록 잘 정의되어야 한다. 컴포넌트는 객체지향 기술 분야의 용어를 자주 빌려 쓰지만, 컴포넌트와 객체지향이 결코 같은 것은 아니다. 메인 프레임에 있는 COBOL 루틴도 자바 프로시저 만큼 쉽게 컴포넌트로 쓸 수 있다.

그림 4: 컴포넌트 청사진

컴포넌트는 각각 명세서를 한 개씩 동반하면서 거기서 자신이 제공하는 서비스를 식별하도록 돕는다. 서비스는 기능을 구체화시켜 이를 통해 밖으로부터 접근할 수 있게 한다. 서비스에는 이름과 파라미터 목록이 있다. 캡슐화encapsulation 개념은 CBD에서 근본을 이루고 있다. 컴포넌트에는 데이터와 그들이 제공할 필요가 있는 프로세스들을 포함시킨다. 그리고 컴포넌트에 접근하여 기능을 수정할 수 있는 방법은 정의된 인터페이스를 통하는 길 뿐이다. 이 “폐쇄 경계”closed boundary 개념은 CBD가 객체지향 기술과는 다른 길을 가도록 한다.

객체지향기술에서, 상속은 한 객체가 다른 객체를 효과적으로 수정할 수 있는 강력한 원리이다. 객체 특성이 변경되면, 해당 하위 객체는 모두 자동으로 변경을 상속 받는다. 상속은 강력하기는 하지만 기술을 습득하기가 매우 어렵고, 시스템 개발에서 큰 도전 정신이 필요하다. 왜냐하면, 설계가 바뀌면 파급효과는 객체 경계를 넘나들어 통제하기가 힘든 때문이다.

CBD 캡슐화로 시스템 설계에서 관리 체계를 세울 수 있게 되었다. 그것은 변경이 일어나도 컴포넌트 내로 국한시킬 수 있고, 캡슐 밖으로는 어떤 영향도 주지 않기 때문이다. 상속기능을 모두 사용하여 객체지향 언어를 쓰면 컴포넌트에서 지렛대로 사용될 수 있으나, CBD 기술로 안정된 어플리케이션 빌딩 블록을 인도할 수 있도록 컴포넌트 경계이내로 캡슐화 사용을 제한했다.

컴포넌트를 구현할 때는 서비스가 어떻게 실행되는지를 정의한다. 구현된 결과로 나오는 것은 소스 코드가 한 부분이고, 다른 한 부분은 설계 모델 자체이다. 고급 툴 집합들 중에는 소스 코드를 모델에 연관시켜, 본래의 비즈니스 요구사항과 프로세스들 까지 역 추적 할 수 있는 것도 있다. 이렇게 연결하면 전통적인 방법과 툴을 사용하였을 때 보다 컴포넌트의 설계 의도를 더욱 깊이 이해 할 수 있게 된다. 컴포넌트 명세서는 서로 다른 몇 개 환경으로 구현될 수 있다. 예를 들면, 어떤 컴포넌트를 COM+ 나 CORBA 두 가지로 구현할 수 있다.

컴포넌트 실행물executable(즉, 오브젝트 코드)은 구현으로부터 나온다. Princeton Softech 제품인 Select Component Manager^TM 와 같은 몇몇 CBD 지원 툴들은 실행물들을 저장할 때 컴포넌트의 구현물implementation과 명세서들도 함께 붙여 놓을 수 있다. 그리고 사이트 관리자가 지정하는 대로 분산시킬 수도 있다.

대체로, 컴포넌트들은 테스팅과 QA 프로세스들을 강도 높게 거쳤기 때문에, 품질이 높은 소프트웨어 모듈들이다. 다시 말하면 미리 시험한 단단한 소프트웨어 루틴들이므로 새로운 어플리케이션에 신뢰를 가지고 포함(재사용) 시킬 수 있다는 것이다. 이렇게 일할 때, 전체적인 어플리케이션의 인도 시기는 더 앞당길 수 있다. CBD 환경을 사용하지 않는 것보다 미리 시험된 컴포넌트는 테스팅과 디버깅 중 많은 부분을 생략할 수 있기 때문이다.

최근에, 표준 인터페이스 정의 언어들이 부상하고 있다 (CORBA에서 IDL, COM에서 ODL 등). 이제는 개발자들이 목표로 하는 미들웨어 환경에서 사용할 최종 상품에 상호연동해서 쓸 수 있도록 컴포넌트를 생산할 수 있게 되었다.

오늘날 컴포넌트는 기술 컴포넌트와 비즈니스 컴포넌트 두 종류로 나누는 것이 보편적이다. 기술 컴포넌트는 위에서 말했던 “규격품”widgets처럼 어플리케이션의 기술적 경향에 초점을 맞추고 다양한 비즈니스에서 재사용 할 수 있다. 왜냐하면, 그것들은 GUI 행동처럼 계통generic 기능들을 가지고 있기 때문이다.

비즈니스 컴포넌트는 초점이 고 수준이다. 그것은 해당 어플리케이션의 요구사항에 제한되어 설계하는 경향을 항상 띠기 때문에 만들기가 더욱 어렵다. 그러나 조그만 더 앞서 생각하면 다른 어플리케이션에서도 재사용 될 수 있는 비즈니스 컴포넌트들을 설계할 수 있다.

예를 들면, 새로운 e비즈니스 어플리케이션에서 화면에 카탈로그 품목들을 표시하고, 선택품목을 쇼핑 바구니에 추가 하는 기능이 필요할 수도 있다. 쇼핑 바구니 관리자를 일반화로 설계하여 여러 서비스를 제공할 수 있는 컴포넌트로 만들면, 현재 개발중인 어플리케이션에서 가치 있게 쓸 뿐만 아니라, 아직 밑그림 단계에 있는 미래의 e비즈니스 어플리케이션에서도 쓸 수 있는 것이다. (이 예는 비즈니스 컴포넌트라기보다는 기술 컴포넌트를 범용으로 만든 정도라고 주장할 수도 있겠는데, 여기서는 단지 컴포넌트 설계 방법을 설명하려는 취지이다.)

기술 컴포넌트들은 개발 작업 속도를 획기적으로 높였다. 그러나 CBD가 IT 조직에 - 수십, 수백 배 생산성 향상으로 실질적으로 기여하려면 - 중요 비즈니스 컴포넌트 라이브러리를 개발하고 활발히 재사용해야 한다.

4. 컴포넌트에도 전략이 필요하다

CBD로 소프트웨어를 개발할 때 전통적 개발 방법도 함께 써서 혼성 조립 프로세스가 되고 이것은 “소프트웨어 개발의 산업 혁명”으로 부르고 있다. CBD에 내재된 개념들은 다른 산업에서 성공한 품질 개선, 예측 가능한 생산들과 일맥 상통한 것이기 때문이다. 즉, 미리 생산한 표준 컴포넌트들을 획득하고 포함시켜 최종 제품을 구축하는 것이다

그림 5: 컴포넌트로 전체 개발 시간을 단축하고 비용을 절감한다

컴포넌트를 이용해 조립한 어플리케이션 부분이 “재사용” 성취 비율이다. 재사용이 많을 수록 생산성은 커지기 마련이다. 경쟁력이 높으므로 어플리케이션은 더 빨리 인도되고, 전통적 시스템에 비해 품질은 돋보이게 높아진다.

몇 년이 지나면, IT 조직들은 경제적 필요성 때문에라도 CBD로 넘어갈 수 밖에 없다. CBD가 비즈니스 컴포넌트 라이브러리를 이용하면서 충분한 시간을 두고 개발될 때, 큰 생산성 이득을 가져올 수 있다. 그에 더해, 실용 방법론을 채용하여 CBD를 구현한다면, IT는 “대규모 병렬 개발”을 이루어, 주요 어플리케이션의 큰 부분들이 순차로 생산되는 대신에, 동시에 생산할 수 있게 된다. 효과가 전체에 파급되어 생산성이 더욱 증가되면 가트너 그룹이 예측한 대로 다섯 배에서 열 배까지 제품 인도가 빨라질 것이다.

내부 IT 요원을 유지하면서, 고객 요구에 맞추어, 경쟁력 있게 솔루션을 생산하고자 하는 회사들은, 외주 개발비 이하로 생산하면서 경쟁사 보다 신속히 어플리케이션을 인도하려면 CBD가 필요할 것이다. 서비스 제공자들은 경쟁사보다 싸게 입찰에 응하기 위해 CBD가 필요할 것이고, CBD를 사용하지 않는 내부 요원들에게 더 저렴한 비용을 요구하는 목적으로도 CBD가 필요하다. 이런 시나리오로 나가면, 비즈니스 컴포넌트 라이브러리가 있는 서비스 회사는 전투 초기에 어플리케이션 완료 비율이 어느 정도 있으므로, 그 컴포넌트들을 지렛대로 요긴하게 이용할 수 있다. 즉, 출시는 더 신속히, 제품 품질은 더 높게, 비용은 더 낮게 제안 할 수 있게 된다. CBD 구현에 실패한 IT 조직들로서는 작업을 직접하지 못하고 다른 곳에 양도하지 않을 수 없게 될 것이다.

CBD는 또한 부족한 IT 기술자들을 지렛대로 이용할 수 있는 수단이기도 하다. 특별히 전문적 기술을 가지고 있거나 해박한 비즈니스 분야 지식을 가진 최고의 개발자들은 재사용이 가능한 컴포넌트들을 만들고, 다른 많은 개발자들은 그들의 작업 결과를 이용한다. 회사는 이런 재능 있는 사람들로부터 이익 최대화를 실현할 수 있다.

미들웨어 표준 출현과 함께, 컴포넌트 기반 언어와 기술이 도처에 증가하고 있고, 컴포넌트 산업은 초기 상태에 있으며, ERP 벤더와 선진 IT 회사들의 CBD 포용 움직임들 ? 이들 징후들을 볼 때 지나가는 유행으로서가 아닌, CBD에 대한 진지한 장기 투자가 필요하다. CIO들은 CBD의 본질에 친숙해질 필요가 있다. 첨단 회사들로서는 “미래는 바로 지금”the future is now” 이기 때문에 CBD기술의 파도를 결코 놓쳐서는 안 될 것이기 때문이다.

　

CBD는 장애를 극복해야 한다.

CBD가 그렇게 명확하다면, 왜 모든 사람들이 그것을 사용하지 않는가? 위에서 말했던 것처럼 기술과 표준의 장벽이 최근에야 무너지고 있기 때문이다. 그 동안 Y2K 문제가 중심을 지배하고 있었다. 그 외에 많은 IT회사들이 CBD를 경계하고 있는 이유는 CASE 전문가들과 객체지향 이론가들로부터 그 동안 충분히 뎄기 때문이다. 그들은 대학에서 결코 끝나지 않을 것 같은 프로젝트를 수행 하면서 “완벽한 어플리케이션 설계”를 하느라, 마치 성배 탐사 여행 하듯이 개발 시간을 물쓰듯 했다.

현재 CBD는 아직도 “시장 진입”early-market 단계에 머물러 있다. 지금까지는 IT회사들이 따를만한 안내서나 원형이 좋은 게 없었고, 실제 적용될 수 있는 실용적인 방법도 알려지지 않았다. 또한 최근까지만 해도, CBD를 지원할 수 있는 도구는 거의 없었다.

상황이 바뀌고 있었지만, 많은 회사들은 Y2K문제에 묶인 나머지 CBD를 중시할 입장은 아니었다. 그래서 대체로 새로운 기술 파도가 밀려올 때는 소수의 첨단 회사들만이 앞으로 나가면서 도구도 없이 해 보거나 스스로 만들어 써 보면서 배워갈 수 밖에 없다. 다른 회사들은 대부분 표준화가 정립되기를 기다리면서 적용 회사도 늘고 지원 도구도 많아질 때까지 기다렸다가 합류하려고 한다.

CBD장애 중 몇 가지는 시간 경과와 시장 성숙만으로도 쉽게 극복되겠지만, 다른 장애들은 매우 근본적인 저항에 부딪혀 해결이 쉽지 않을 것이다. CIO 들은 CBD를 할 수 있도록 준비하고 평가에 필요한 프로세스들과 도구들을 모은 후에, 전이계획을 세우고는 굳건히 밀고 가야 한다. CBD로 가는데 넘어야 할 장벽은 다음 세가지 범주로 들어온다.

비용
문화
채널

비용 장벽

경쟁력을 유지하려면, 오래된 생산업체들은 도구 개조에 주기적으로 투자가 필요하다는 것을 알고있다. 도구 개조는 생산 공정에서 신제품을 개발할 때나, 비용 효율을 높일 때 사용 되었다. 생산 공장을 멈추고, 새로운 장비를 도입하여 설치한 후, 요원들을 다시 훈련시켰다. 비용이 많이 드는 공정이었지만, 회사가 도구를 개조하지 않으면 심각한 쇠퇴에 직면 하지 않을 수 없었다.

때때로 회사는 기존에 기술 투자한 것을 가능한 많이 뽑아내야 할 경우 도구 개조 시기를 가능한 늦출 수 밖에 없었다. 경우에 따라서는 회사는 회복할 수 없는 손실로 고생하기도 했는데 그 이유는, 그들이 도구 개조를 했을 때에는 이미 시기적으로 너무 늦어서 경쟁사들이 도구 개조를 먼저 하고 들어와서 시장을 많이 잠식한 뒤였기 때문이다. 도구 개조의 결정은(장.단점이 있지만) 나중에 가서야 결과가 나타나기 때문에 모든 비즈니스 결정에서 가장 중요한 전략 중 한 개다

CBD를 구현하는 일은 도구를 개조하는 것과 많이 닮았다. 다만 조립 라인에 비해 더 좋은 점은 전이가 진행되는 동안에도 계속 일할 수 있다는 점이다. CBD를 효과적으로 이룩하려면 훈련, 하부구조, 조직 정비에 투자를 해야 한다. 학습 곡선 동안에는 생산성 손실은 누적되지만 동시에 새로운 기술을 흡수하는 기간이기도 하다.

다행스럽게도, 비용 문제를 완화시킬 수 있는 여러 실용 방법이 있다. 그 내용들을 아래에 소개할 텐데, 비용 문제는 아직도 큰 관심사이다. 때로는 열렬한 CBD 전도사들이 나타나서는 CIO들에게 잘못 메시지를 주어 그들이 배웠던 것을 모두 그만두어야 하고, 조직적인 고통을 감수해야 하고, 재정적인 대가를 회수하는데 오랜 시간이 걸린다고 오도하는 경우가 많다. 프린스턴 소프텍에서는 경험으로 증명된 방법들을 이용하고 있다. CBD로 이동한 큰 회사들과 매일 일하면서 투자 대가를 신속히 회수할 수 있고, 오랫동안 시간을 들여 증명된, 결과가 나오는 실무 기술들을 버릴 필요도 없었다.

“IT 도구 개조 비용”은 시장에 따라 대응도 다르다. 유럽과 일본 회사에서는 하부 구조에 장기간 투자를 더 하는 듯이 보인다. 그러나 미국에서는 즉시 결과를 내라는 압력이 강하기 때문에 기술 투자는 첫번째 프로젝트에서 효과를 보여준 다음 에라야 가능한 경우가 많다.

CBD는 큰 생산성 이점을 약속한 반면, 첫번째 프로젝트 만으로는 대가를 회수할 수 없다. 우리가 보아왔던 것처럼 CBD 이익은 비즈니스 컴포넌트 라이브러리가 축적되면 몇 배로 이룰 수 있다. 첫 번째 프로젝트에서는 라이브러리를 생성하고 재사용 기반을 수립한다. 비용은 다시 말하면 투자다. 따라서 IT전략이나 비즈니스 전략이 승리하려면 투자 시기를 아는 것도 중요하다.

IT 회사들이 CBD를 경계하는 것도 당연하다. 그들은 전부터 보아서 알고 있다. CASE시절로부터 새로운 객체지향 프로젝트로 옮겨가면서, 방법론들에 시간을 많이 투자했으나 너무 아카데믹하고 일률적인 장황한 이론에 비해서 결과물은 보잘 것 없어 허탈했다. CIO 들은 방법론자 들에게 백지수표를 줄 수는 없는 노릇이다. 그들은 완벽한 모델을 만드는 것에 집착하는 나머지 비즈니스에서 시급히 필요로 하는 시스템을 인도하는 데는 관심이 덜하기 때문이다.

프린스턴 소프텍에서는 실용적이면서 효율적인 비용으로 CBD로 이동할 수 있는 방법을 개발하였다. Select Perspective에 내장되어 있는 이 독창적인 프로세스를 쓰면 IT 조직들은 CBD본질을 배울 수 있는데, 그것은 시간을 효율적으로 쓰면서도 반복적인 방법으로, 결과를 규칙적으로 받아 볼 수 있기 때문이다. 하부구조 투자와 요원 훈련비 그리고 조직 분야 투자들은 여전히 필요하지만, 장기적으로는 비용 문제를 타당한 규모로 이끌 수 있다. 그러는 동안 IT 조직은 오늘의 도전을 이기면서 미래 경쟁에도 대비할 수 있게 될 것이다.

문화 장벽

CBD가 소프트웨어 개발의 산업 혁명으로 불린다고 앞에서 말했다. 어떤 혁명이든지 환영하는 사람이 있는가 하면 두려워하는 사람도 있기 마련이다. 낡고 친숙한 구조들은 새로운 것으로 바꿀 수 밖에 없다. 그런데 새 것은 옛 것 보다 더 안 좋아 보일 수가 있는데, 그것은 단지 다르고 익숙하지 않은 때문이다.

CBD에서 어플리케이션들은 미리 만들어 테스트 완료된 컴포넌트들로 조립된다. 많은 IT 개발자들은 CBD를 기술 변동이나 방법론 변동 만큼의 문화 변동으로 인식한다. 개발자들은 대개 다른 사람이 만든 코드를 재사용하는데 익숙하지 않다. 믿을 수 있느냐가 주요 관건이다. 이 소프트웨어 컴포넌트가 작동을 할 것이라고 정말 믿을 수 있는가? 그것이 효율적으로 실행될 수 있는지는 어떻게 알 것인가? 내가 완성된 어플리케이션이 나빠지지는 않을 것인가?

창의적인 공정에 대한 작업 만족도와 개인적 판단은 또 다른 문화 요인이다. 대부분의 개발자들은 개발 공정을 좋아한다. 어떤 이들은 어플리케이션을 조립해서 만드는 것이 백지로부터 개발하는 것 만큼 재미있을까 하는 의문을 가진다. 사실을 듣자면, 개발자들은 바퀴를 재 발명하는 것을 꺼리지 않는다. 개발은 재미있고, 이전 사람들보다 더 좋은 바퀴를 만들 수 있다고 믿기 때문이다.

　

　

　

2004년까지, IS 조직들 중 적어도 절반은 재사용을 최대화 할 수 있는 새로운 객체 지향 컴포넌트를 < /FONT>개발하거나, 문화적, 정치적 이유로 비 효율적인 재사용을 할 것이다.

-Gartner Group

　

　

조직 문화와 개발 방법은 다른 문제이다. CBD 구현에 성공한 대부분의 기업들은 대체로 컴포넌트 관리 그룹을 설립했다. 이 팀은 프로젝트 개발기간에는 QA와 컴포넌트 버전 관리를 하면서, 설계사들과 협조하여 컴포넌트 후보들을 식별하고 생성한다. 어떤 조직들은 컴포넌트 개발팀을 분리 운영하는데, 다른 곳에서는 어플리케이션 프로젝트 그룹과 컴포넌트 개발자들을 통합 운영하기도 한다. 조직들이 깨달은 것이 있는데 개발자에 따라 컴포넌트를 만드는 역할이 더 맞는 사람이 있는가 하면, 전체 비즈니스 솔루션에서 최종 컴포넌트를 조립하는 역할이 더 잘 맞는 사람이 있다는 것이다.

CBD를 구현하는 일은 때로 새로운 방법론을 배우는 것 이상으로 중요하다. CBD에서 전망한 이익을 실현하려면 기존의 IT조직 개발 문화를 일부 바꿀 필요도 있다. 훌륭한 관리 기술로 올바른 인센티브와 실용적인 파일럿 프로그램으로 CBD의 가치를 보여주면서, 익숙한 관리자들이라면 CBD로 합의를 끌어 낼 수 있겠으나 ? 이에 앞서 미리 잠재적인 문화적 장벽을 고려하지 않으면 안된다.

프린스턴 소프텍에서는 IT 조직들이 개발자들을 위협하지 않고, 변화를 북돋아 CBD로 옮겨갈 수 있도록 도와주고 있다. 문화적 문제들을 인지하고 처리하는 것도 그 공정의 한 부분이다.

채널 장벽

CBD가 성공하려면 IT조직은 개발자에게 CBD를 접할 수 있는 채널을 제공해야 한다. 채널 중에는 여러 도구, 공정, 조언자들이 있고, 이들을 통해서 개발 조직은 쉽게 효과적으로 실제에 접근할 수 있다.

최근까지만 해도 기업 수준에서 채널이 유지되는 CBD는 거의 없었다. 선진 회사들은 Lotus Notes와 Microsoft Office 같은 계통적인 툴들을 이용해서 자신에 맞는 것을 만들어 보려고 노력하였다. 그러나 CBD를 메인스트림으로 채용하고자 하면 맞춤 도구, 템플릿, 교사들을 산업계에서 수시로 활용할 수 있어야 한다.

좋은 CBD 채널이라면 어떻게 보여야 하는가? IT조직들이 어떤 종류의 도관을 설치해야 CBD가 활발하고 효율적으로 유통될 것일까? 가트너 그룹은 핵심 리스트를 작성했다. (그림7).

　

　

재사용 프로그램 핵심 요소

재사용 품목 목록유지

카탈로그 또는 리파지토리를 유지하고 여기에는 품목 목록이 들어 있고 검색 설비도 유지

재사용 관리자와 지원 요원이 카탈로그를 유지하고,

재사용 촉진자는 훈련과 지원을 담당함

개발 방법론이 있고 여기서 재사용 생명 주기와 재사용 가능한 품목을 모으는 생명 주기를 정의함

설계 표준을 두어 컴포넌트 행동과 모습을 일관성 있게 유지

측정 프로그램으로 계량치를 획득하고 재사용 효과를 감시

인센티브 프로그램으로 재사용이 성공하도록 요원들의 행동을 독려

- 가트너 그룹

　

　

　

　

　

　

Figure 7: 회사 차원의 CBD로 성공하기 위한 가트너 그룹 기준

어떤 이들은 인센티브 프로그램 필요성에 대해 이의를 제기하기도 하는데, CBD 채널이 성공하려면 주요 요인을 식별할 수 있어야 한다.

컴포넌트 명세서를 문서화하고 회람하는 절차가 있어야 한다. 컴포넌트 개발자들은 무엇을 만들어야 좋은지 알 필요가 있고, 컴포넌트 관리자들로서는 어떤 컴포넌트가 현재 있는지 알 수 있어야만 그들이 이용 방법을 생각할 수 있다

IT 조직은 리파지토리를 만들어 놓고 컴포넌트가 완료될 때마다 그 곳에 저장해야 한다. 컴포넌트는 키워드로 설명해 놓아야만 정교한 검색 방법을 쓸 수 있다. 문화 장벽과 비용 장벽이 극복된다 하더라도, 개발자들로서 필요로 하는 컴포넌트를 찾을 방법이 없다면, 그들은 계속 바퀴를 재 발명할 것이고, 중요한 재사용은 결코 이루어지지 않을 것이다. IT 조직이 라이브러리에 컴포넌트들을 많이 축적해 갈수록, 버전 관리 설비 못 지 않게 연구를 잘 하는 것도 매우 긴요해진다. 원격 개발 팀들이 협의할 수 있는 설비들도, 웹을 통해 원격 리파지터리에 질의할 수 있는 기능과 함께 중요하다.

컴포넌트들이 파생된 설계 모델들을 통합하는 방법을 강구해야 한다. 점점 더 가치 있는 자산은 코드가 아니라 설계임을 알게 되는데 이것은 자동화 대상인 비즈니스 프로세스와 역으로 맵핑이 가능하기 때문이다. 컴포넌트 명세서와 설계 모델을 통합시킬 수 있는 컴포넌트 도구들이 있다면 가치를 매우 높여주고, 시간 절감도 가져온다. 왜냐하면 기술 구현을 획득하는 것은 물론 그 뒤에 가려서 안 보이는 기업 비즈니스로 연결된 지적 자산도 획득할 수 있기 때문이다.

공지 시스템을 자동화할 필요가 있다 - 개발자들은 컴포넌트에 관한 관심사를 등록할 수 있고 새로운 버전이 이용 가능하게 될 때 이메일을 통해 즉시 알릴 수 있다

컴포넌트 관리 소프트웨어는 기술 지원을 독립적으로 해야 한다. CORBA, COM+, EJB와 같은 컴포넌트들은 모두 단일 컴포넌트 리파지토리 안에서 문서화나 관리할 수 있다.

많은 조직들은 이미 컴포넌트로 만든 프로그램들을 많이 가지고 있다. COM 기반의 Visual Basic 프로그램도 그 예다. 컴포넌트 리파지토리는 “끌어 놓기drag and drop” 를 지원해야 한다. 거기서 이들 컴포넌트들을 분석하고, 카탈로그 만들고, 라이브러리에 넣어, CBD 가 진행될 수 있도록 한다.
IT 조직들은 방법론과 조언자들 도움이 필요하다. 그들은 어떻게 컴포넌트 유산을 찾고, 어떻게 올바른 컴포넌트 설계를 하고, 어떻게 전체 어플리케이션 개발 공정에 CBD를 삽입할지 알 필요가 있다. 개발도구만 가지고는 이런 지식들을 전달할 수 없다. 그것은 사람만이 할 수 있는 일이다.

위의 열거한 리스트가 다는 아니다. 예를 들면, CBD 환경을 확장할 수 있어야만 매우 큰 모델과 큰 개발팀을 지원할 수 있다. IT 조직들은 다양한 도구와 서비스로 이루어진 채널을 구축할 수 있게 되어서, 사용자들에게 CBD공정을 보여 주면서 접근할 수 있게 하고있다

CBD방법론 ? 실용적인 경로 채택으로 생존력을 길러야 한다

인터넷 세상은 이미 컴포넌트 세상이다. IT 조직이 공식적인 CBD 프로그램을 가지고 있든 아니든 상관없이 명백히 소프트웨어 컴포넌트를 이용하여 일하고 있다. 자바나 비쥬얼베이직 언어들과, COM+와 EJB 표준들은 모두 컴포넌트 기반이다. 그러므로 컴포넌트는 더 이상 새로운 이론이 아니다. 이미 널리 보급되어 많은 곳에서 활발히 사용되고 있기 때문이다.

그러나 CBD 개념을 단순히 이해하는 것만으로는 IT 회사들로서 CBD 프로그램 구현에 성공할 수 없다. CBD의 성공 스토리는 아직 찾기 어려우므로 필요한 것은 점차 CBD로 안전하게 이동할 수 있는 방법이다.

CBD는 RAD, 객체지향 개발, 구조적 개발 등, 초기 기술들을 대체하는 것이 아니라, 이런 기술들의 장점을 이용하고 확장 시킨다. 조직들은 그들이 알고 있는 원칙들은 그대로 쓰면서, RAD에서 부족했던 엄격함과 CASE에서 성취할 수 없었던 신속히 돌아 오기(turnaround)와, OO와 UML 이론 중에서 실용적인 것들을 추가하면 된다.

프로젝트에 따라 일부만 CBD로 이동해 갈 수는 있다. 그러는 동안 컴포넌트 구조를 설계하는 일과 CBD 공정에서 개발하는 일들에 관한 본질 원리들을 배우고 또 가치를 평가할 수 있을 때, 그 다음 단계에서 본격적인 “도구 개조”에 착수하면 된다.

그림 8: 위험을 줄이면서 기업 차원의 CBD로 점진 이동하기

오늘날 IT 조직들은 프린스턴 소프텍 제품인 Select Perspective에 접근하여, 컴포넌트 기반으로 프로그램을 개발할 수 있다. 그 도구는 주요 회사에서 실제로 CBD로 구현을 하면서 경험을 통해 성장했기 때문에 독특한 데가 있다. Perspective 본질은 “실용성” 철학이 강하고, 객체지향, UML, CBD이론의 장점만을 결합한 것이다. 그 결과로 매우 실용적인 프로세스가 되었기 때문에 IT조직들이 CBD 장벽을 효과적으로 극복하는데 도움 줄 수 있게 되었다.

Select Perspective는 제품, 패턴, 프로세스 그리고 요원들까지 통합한다. 거기에는 프린스턴 소프텍 제품인 Component Factory도 들어 있는데 이것은, CBD의 공급/관리/소비 모델을 지원하는 제품군으로서, 요구사항 획득으로부터, 비즈니스 프로세스 모델링과 실제 코드 생성에 이르기까지 여러 방법을 동원하여 개발 공정을 향상시킨다.

Select Perspective는 또한 구조architecture에 주의를 기울이는 점에서 독창적이다. 비즈니스 어플리케이션 구조와 기술 어플리케이션 구조를 만드는 일은 아마도 가장 간과되었던 분야에 속했는데, 사실은 CBD 공정에서 가장 생명력 있는 요소다. Select Perspective는 즉시 사용할 수 있는 아키텍처 설계 패턴을 실용성 있게 만든다. 프린스턴 소프텍에 있는 Perspective 패턴은 이론을 실습해서 나온 결과 정도로 간단히 만든 게 아니다. 실제 e비즈니스 프로젝트에서 개발한 후 정제를 거듭한 것으로 현재 생산 공정에서 활발히 사용되고 있다. 프린스턴 소프텍 고객들은 그들의 특정 필요성에 따라, 몇 달이 걸릴 설계 작업을 건너뛰려고 Perspective 패턴을 채용한 것이다.

그림 9: Select Perspective는 제품, 패턴, 공정 그리고 요원을 조합한다

또한 프린스턴 소프텍에서 이용 가능한 것 중에는 Select Perspective에 있는 독창적인 솔루션 개발 공정이다. 이 실용 방법론은 현장 교육과 훈련 시설에서 보급하고 있고, 실제 개발 프로젝트에서 책임 컨설턴트들로부터 자문 받을 수도 있다.

Select Perspective에서는 점진적, 반복적, time-boxed 전략을 채용하여 결과들을 가시화하고있다. 사용자들과 IT 요원들은 단기간에도 진척사항을 볼 수 있고, 전체 비즈니스 전략이 조정되면 시스템 개발 계획은 이에 즉시 대응할 수 있다. 개발 공정은 세 가지 주 요소로 구성된다.

정렬align
설계architect
조립assemble

정렬 단계는 “올바른” 시스템이 보장되도록 IT 와 비즈니스를 동기 시켜 개발한다. Select Perspective 는 주요 비즈니스 연결 점에서 활발해 지는데, 이전의 UML 중심 방법론에서는 비즈니스 프로세스 모델링을 완전히 무시했었다. 이것은 프린스턴 소프텍의 실용적인 철학이 반영된 것이다: 설계 활동의 최종 결과는 비즈니스 요구를 반영 해야 한다. 단지 방법론자들만 즐겁게 해 주는 예쁜 그림이어서는 안 된다.

설계 단계에서는 알맞게 세그먼트로 나누어 설계와 개발이 CBD로 잘 진행될 수 있게 한다. 미래 재사용에 쓰려고 핵심 씨앗을 생산적으로 뿌리는 시기는 바로 이 단계다. Perspective 패턴을 사용하면 이 단계에서 시간과 비용을 획기적으로 절약한다.

조립 단계에서는 UML, 다른 모델링 규율, 코드 생성, CBD 관리 기술을 적용하여 어플리케이션 증분을 최종 완료 시킨다. 요점은 실질 결과를 인도하여 비즈니스에 실질 가치를 더해주는 것이다. 기업 수준의 CBD라면, 조립 공정은 “공급”과 ”관리” 기능을 통합한다. 즉, 도구들을 이용하여 가용 컴포넌트를 찾고 통합하여 최종 비즈니스 솔루션을 만들어간다.

Select Perspective에서는, 강력한 능력에 비해서는 단순한 기법인 프린스턴 소프텍의 LUCID 를 반복이 진행되면서 점점 더 상세히 적용하고 있다. 배우기도 쉽고, 적용하기도 쉽기 때문에 Select Perspective는 주요 회사의 핵심 e비즈니스를 일정도 당기고 예산도 절감하면서 성공적으로 인도하고 있다.

CBD - 경쟁력 있는 우위를 점하려면

컴포넌트 기반 개발 방법은 전성기를 눈 앞에 두고있다. 미들웨어 표준(CORBA, COM+, EJB) 는 이미 쓰이고 있고, CBD에 적합한 객체 지향 언어들은(Java, Visual Basic) 지금 첨단 e비즈니스 어플리케이션 개발에 널리 이용되는 도구이다. 기술 수준에서 본다면 컴포넌트를 사용하는 일은 표준 실무가 되었다.

현재 컴포넌트 팩토리 같은 제품과 Select Perspective 같은 공정은 기업 차원의 CBD를 당장 지원할 수 있다.

조직 문화와 비용 문제들은 현실적인 것들이지만, 그것들은 또한 예상 할 수 있는 수준이다. CBD로 이동은 현재 진행중이다. CBD 적응에 실패한 회사들은 경쟁에서 치명적인 손실을 감수해야 될 것이다.

프린스턴 소프텍은 오늘날 컴포넌트 기반 개발 솔루션에서 선두 주자다. Select Perspective는 그 동안 축적한 제품, 패턴, 프로세스, 요원들로 당신 조직이 비즈니스 솔루션을 성공적으로 개발하도록 도울 수 있다.

2000. 8. 7

DACOM ST 품질보증팀 자료

출처: “Component Based Development” ? A Roadmap to eBusiness Success, White Paper, Princeton Softech, Jan., 10, 2000, http://www.princetonsoftech.com/index.asp