향후 소프트웨어 개발은 CBD라는 방법을 통해 이루어질 것이란 예측이 선명해지면서 무엇이 CBD인지 그 장점이 무엇인지에 대해 궁금해하는 사람들이 늘어나고 있다. 본 글에서는 어떻게 CBD가 탄생하였고 CBD의 사상과 이를 적용하였을 때의 장점과 앞으로의 발전방향에 대해 알아보도록 하겠다.
현대 산업 발전의 원동력은 분업과 공정관리, 표준화 등을 통한 효율성 있는 대량생산에 있었다. 더 우수한 품질의 제품을 더 낮은 가격으로 제공하게 됨에 따라 사회 전반적인 생산성이 향상되고 경제적 발전을 이루게 되었다. 이렇게 오랜 역사를 지닌 제조업과 달리 소프트웨어 산업은 50년 정도밖에 안된 역사를 가진 분야로써 급격한 변화와 발전을 겪어 왔으며 앞으로도 큰 변화들이 발생할 가능성이 매우 높은 분야다.
소프트웨어 개발의 딜레마
소프트웨어 생산에서 직면하게되는 고민은 근본적으로는 제조업의 그것과 유사하다. 즉, 어떻게 좋은 품질의 제품을 저렴한 비용으로 만들 것인가이다. 이를 위해 오래전부터 많은 개발자들이 이미 만들어 둔 프로그램의 일부를 재사용하는 방법들을 연구해왔다.
이를 위해 프로그램에서 공통적으로 많이 사용되는 부분을 라이브러리(library)라 부르는 함수들의 집합체 형태로 만들거나 기능별 구분에 따른 단위로 모듈(Module)을 구성하여 소프트웨어를 작성하고 추후 유사한 작업을 할 때 이들 프로그램 소스를 가져다가 약간의 수정이나, 전달하는 매개변수 값의 변화를 통해 개발작업 시간을 절감할 수 있게 되었다.
현재는 기본 라이브러리(객체지향언어에서는 클래스)를 잘 알고 손쉽게 사용하여 얼마나 빠르고 효과적으로 프로그램을 만드느냐가 능력있는 프로그래머의 선별 조건이 될 만큼 중요한 사항이 되었다.
또 하나의 고민은 프로그램을 유지보수하는 문제이다. 개인이 사용하는 작은 규모의 프로그램이라면 수정할 사유도 그다지 발생하지 않고 설사 생겼더라도 본인이 작성한 프로그램을 조금 살펴본 후 고칠 수 있으므로 전혀 문제가 되지 않는다. 그러나, 큰 기업에서 사용되는 대규모의 프로그램은 작성한 사람과 추후에 수정할 사람이 동일인이 아닌 경우가 대부분이고 그 내용이나 설계의 배경에 대해서도 충분한 이해없이 프로그램을 볼 경우 수정하기가 매우 어렵다. 설사 수정한다 해도 다른 부분에 미치는 영향을 정확히 몰라 큰 오류를 초래하게 될 수도 있으므로 이를 관리하기 위해 개발 산출물과 프로그램 내의 설명(comment)을 강조하게 되었다.
또한, 각 모듈 단위의 프로그램들이 모듈 외부의 프로그램들에 끼치는 영향을 최소화하는 것이 잘 작성된 소프트웨어의 기본적인 소양이 된 것은 당연한 일이다. 이런 연유로 소프트웨어 유지보수에 드는 비용이 개발에 드는 비용보다 몇배나 크다는 것은 잘 알려진 사실이다.
이런 문제들은 H/W 및 S/W 개발기술의 빠른 발전을 실제 S/W 개발이 따라가지 못함에 따라 더욱 두드러지게 되었다. 대형 시스템의 경우 개발에 걸리는 시간은 1∼2년에 이르는데 그것에 맞추어 있던 H/W와 시스템의 개념들은 때때로 이미 진부한 것이 되곤 했기 때문에 개발하자마자 다시 재개발 계획을 새워야 하는 상황이 되었던 것이다.
CBD는 마치 레고 블럭을 이용하여 목적하고 있는 구조물을 조립하는 것과 유사한 개념이다. 각 블럭이 상황에 따라 다양하게 쓰여질 수 있고 또 유사한 블럭과 교체될 수 있듯이 각각의 컴포넌트들도 인터페이스라하는 레고 블럭의 오목/볼록한 연결단자들이 재사용 및 교체가 가능하다. 컴포넌트는 컴포넌트 명세에 따라 인터페이스가 정의되어 있는 실행 가능한 코드라고 정의할 수 있으며 별도의 수정이나, 프로그램 컴파일 없이 사용이 가능하다.
CBD의 등장
단, 이를 위해서는 미리 인터페이스가 약속되어 있어야 한다. 서로 다른 규격으로 만든 블럭끼리는 조립이 불가능하듯이 동일한 인터페이스 명세서에 맞추어 만들어진 컴포넌트끼리만 조립이 가능하다. 결국 서로 다른 회사의 컴포넌트 간에 호환성이 보장되기 위해서는 표준화된 인터페이스 명세가 있어야 하며 더욱 크게는 해당 산업분야의 표준 설계도가 필요할 것이다.
업계 내의 표준 재정을 통한 일관된 컴포넌트 인터페이스 확보와 표준에 따르는 컴포넌트들의 병존 및 단품 판매가 가능해지면 어떤 일이 발생할 것인가? 앞서 이야기한 소프트웨어 개발에서 재사용과 사후관리 문제를 혁신적으로 풀어낼 수 있을 것이다. 즉, 개발자는 더 이상 코드레벨에서의 개발에 집중하기보다는 시스템의 전체적인 구조에 더 많은 노력을 기울일 수 있으며 필요한 기능들은 컴포넌트 시장에서 판매되는 여러가지 컴포넌트 중 맘에 드는 것들을 사다가 끼워 넣으면 되는 것이다. 이렇게 될 경우 S/W 제작기간이 혁신적으로 단축될 수 있다. 빠르게 완성된 최신 시스템은 업계 내에서 강력한 경쟁력을 갖게하여 경쟁우위를 확보할 수 있게될 것이다.
또한 시스템 유지관리에 있어서 새로운 컴포넌트가 등장하거나, 기존 제품이 업그레이드될 경우, 법제나 환경의 변화에 따라 소프트웨어가 변경되어야 할 경우, 특정 부분에 기술이 적용될 경우, 심지어 시스템 전반적인 업그레이드와 구조적인 변경이 있을 경우에도 기존의 컴포넌트들은 재사용될 수 있고 필요에 따라 최소의 조치로 시스템을 안정되게 운영할 수 있다.
이러한 변화는 S/W 산업전반에 혁명을 가져올 것이라 예상된다. 또한 이런 변화의 파급효과는 단순히 S/W산업 안에서만이 아니라 전산업적으로 영향을 끼칠 것이라 생각한다. 더욱 빠르게 사회를 변화시키고 발전시킬 수 있을 것이며, 많은 부분들이 더욱 다이내믹하게 환경에 따라 변화되는 구조로 재구성될 것이라 생각된다.
앞서 기술한 바와 같이 CBD는 멋진 청사진을 제시하고 있지만 현시점에서는 아직도 풀어야할 많은 난제들을 갖고있다. 무엇보다 절대적으로 컴포넌트의 양이 부족하고, 업계 내의 표준도 없는 형편이다.
현재 CBD의 문제점과 발전방향
현시점에서는 대부분의 경우 S/W 개발을 CBD로 한다고 하면 먼저 컴포넌트부터 만들어야 한다(해당되는 컴포넌트 제품군 중에서 구입하는 것이 아니라). 또한 컴포넌트를 만들려면 어디까지를 하나의 컴포넌트로 할 것이며, 각 컴포넌트의 인터페이스 명세는 어떠한지가 있어야 하는데(제조업의 설계도면처럼) 이 또한 없으므로 개발하는 측에서는 표준안까지 만들어야 한다.
CBD는 각 컴포넌트의 인터페이스를 통한 연결이 핵심요소이므로 초기의 설계가 무척 중요하며, 이런 부분에서의 오류를 거부하기 위해 전통적인 워터폴(waterfall)방식의 개발 방법을 채택하지 않고 이터레이션(iteration)을 통해 점진적으로 진화시키는 방식으로 개발을 한다.
초기의 설계에서 해당 도메인(Domain)의 업무를 통찰하면서 CBD에 대해서도 잘 알고 있는 아키텍터의 존재가 무척 중요하지만 그 어느 쪽도 그렇게 흔한 인력은 아닌 것이다. 초기 설계가 기능적으로는 문제가 없더라도 CBD 관점에서 정확한 컴포넌트 추출이나 인터페이스 정의가 되지 못하면 CBD를 통해 얻을 수 있는 많은 장점들이 사라지게 될 것이다.
이런 문제를 풀기 위해서 먼저 업계 전체가 동의하는 CBD 표준 아키텍처들이 합의되어야 한다. 또, 이런 표준에 따라 동일 제품군내에 많은 컴포넌트들이 경쟁제품으로 존재할 필요가 있으며, CBD개발의 전문가들이 더욱 많이 길러져야할 것이다.
세계적으로도 아직은 CBD의 초기단계이며 더욱 효과적인 방법론들과 표준, 기술적인 발전들이 진행되고 있다. 마치 자동차를 사고나서 광폭타이어, 선루프를 달고 오디오를 교체할 수 있는 것처럼 S/W도 다양한 특징과 기능을 갖고 있는 컴포넌트들로 교체함으로써 손쉽게 원하는 기능들을 갖춘 시스템들로 변환이 가능한 시대가 조만간 도래할 것이다. 제조업의 혁명이 사회전반에 영향을 끼쳤듯이 S/W에서의 혁명이 어떻게 사회에 긍정적 영향을 끼칠치 기대되며 CBD가 성공적으로 산업계에 정착되기를 기대해본다. 
