CBD ( Component-Based Development ) 방법론은 이름 그대로 컴포넌트들을 개발하고 조림하여 소프트웨어를 완성하는 방법론입니다.
각 컴포넌트는 독립적이고 재사용 가능하도록 설계하고 개발됩니다.
개인적으로 아주 매력적인 방법론이라고 생각되는 방법론 중 하나입니다.
제 첫 직장에서 이 방법론을 기반으로 여러 어플리케이션 및 시스템을 개발하였기 때문에 저에게는 매우 소중한 추억의 방법론이 되겠습니다.
다른 방법론들과 비교하면 CBD는 매우 구체적이고, 실제적인 사례도 주변에서 많이 찾을 수 있을 만큼 오랫동안 사랑받은 방법론이라고 볼 수 있습니다.
이제는 생소해진 OCX(OLE Control Extension) , ActiveX , ATL (Active Template Library) 것들이 있습니다.
지금은 EJB ( Enterprise JavaBeans)나, .NET Framework 등이 익숙하겠습니다.
이 방법론으로 개발하던 당시에 가장 어려웠던 부분은 인터페이스 표준, 문서화, 그리고 버전 관리였습니다.
특히 버전 관리는 매우 어려웠는데, 그 이유는 아래와 같습니다.
1. 하나의 기능을 수행하는 컴포넌트는 여러 프로그램에서 재사용되어야 하며, 유지보수도 동일하게 이루어져야 합니다.
2. 다양한 프로그램에서 컴포넌트를 재사용하면서 각각의 요구사항에 따라 인터페이스가 추가되거나 변경되는 경우가 생깁니다.
3. 컴포넌트는 독립적이어서 수정과 검증은 비교적 쉬우나, 모든 프로그램에 적용하는 것은 비용이 많이 들 수 있습니다.
4. 이러한 이유로 버전이 분할되는 경우가 생기기 시작합니다.
5. 이러한 과정에서 복잡성이 증가하게 되었습니다.
결과적으로 이러한 상황들로 인해 버전 관리가 복잡해지고, 어느 순간에는 굉장히 복잡한 상황이 벌어지게 되었습니다.
언제나 원칙을 지키는 것은 어렵습니다.
특히, 유지보수를 고려하지 않은 계획은 당장은 문제가 되지 않지만, 언젠가 아주 큰 시련의 토대가 될 수 있음을 교훈으로 얻었습니다.
CBD에 심취해있던 저는 어느 날 선배에게 이런 질문을 했던 적이 있습니다.
"선배님, 컴포넌트를 조합해서 다른 컴포넌트를 만들던가, 프로그램을 만들 수 있는데요.
적절한 컴포넌트가 없을때 그 컴포넌트는 어떤 방법론으로 만들어야 하나요? "
여러분들의 대답은 어떤가요 ?