얼마전에 볼포 자체에서 C++BuilderX에 대해 요구 사항을 조사 했었던 적이 있었습니다. 그 일이 영향을 미쳤는지 아닌지는 모르겠지만, 즐겁게도 VCL이 추가된다는 소식 등이 들려왔었는데요, 사용하다가 보니 볼랜드가 ALM으로 자사의 솔루션을 구분함으로써 C++BuilderX 자체에 아쉬운 부분이 있음이 뒤늦게 느껴져서 추가적으로 적어봅니다.

ALM으로 진행되면서 우려되고 아쉬운 부분이 Design 영역과 Develop 영역의 연계 문제입니다. ALM 중에 Design 영역과 Develop 영역이 있는데, 그 중 Together 제품군은 Design 영역(영역이라는 용어가 적당치 않은 것 같습니다만 적당한 용어를 몰라 그냥 쓰겠습니다)으로 잡혀 있고, C++BuilderX는 Develop 영역에 속해있습니다.

Products and Solutions

...(중략)

Design : Together
-Together ControlCenter
-Together Solo
-Together Edition for JBuilder
-Together Edition for Eclipse
-Together Edition for WebSphere Studio
-Together Edition for SAP NetWeaver Studio
-Together Edition for Microsoft Visual Studio .NET
-Together Edition for C++BuilderX

Develop :
-Borland Enterprise Studio for C++
-Borland Enterprise Studio For Java
-Borland Enterprise Studio For Mobile
-C++BuilderX
-C#Builder for the Microsoft® .NET Framework
-CodeWright
-Delphi
-JBuilder
-JBuilder Mobile Edition
-Kylix
-Mobile Studio

...(하략)

*출처: http://www.borland.com/products/
*NOTE: 리스트를 강조하기 위해 조금 수정 했습니다.


볼랜드 홈페이지에서 가져온 리스트입니다. Develop 쪽을 살펴보면, 언어 유형별(C++, Java, C#, OOP Pascal)로 나눌 수도 있고 개발 플랫폼에 따라서 나눌 수도 있겠습니다만 볼랜드가 이러한 결과를 내기위해 처음부터 계획했던 것이 아니라, 개발툴을 만들다보니까 나온 산물이므로 정확하게 유형을 구분하기는 무의미해 보입니다. -특이할 점은 C++이라는 명칭은 들어있지만 C++ Builder 제품의 정확한 명칭을 쓰지는 않고 있다는 점입니다. Kylix에 CLX를 포함하는 비슷한 류의 C++ Builder가 포함되어 있긴 하지만, 국내 정서에서 말하는 C++ Builder는 아니지요- 결과적으로 IBM 호환 기종의 컴파일러부터 시작해서 다중 플래폼으로 점점 이전 되고 있고, stand alone 환경에서 enterprise, mobile 등 다양한 환경을 위한 툴이 개발, 판매 및 지원 되고 있음을 알 수 있습니다.
하지만 Design 쪽을 보면 Together라는 하나의 줄기로 이루어져 있습니다. -이런점에서 보면 볼랜드의 Together의 인수는 최상의 선택이었다고 말하고 싶습니다. 아직 이른 감이 있지만 IBM의 Rational Rose의 인수를 악밥했다는 시각에서보면 어느만큼의 비중인지 판단할 수 있을 것 같습니다- Together 하나에 다수의 Edition 별로 버젼이 있는데요, 이런 양상은 Together의 특성상 가능한 일입니다. 도대체 어떤 특성이길래 이것이 가능할까요?

Together가 단일 솔류션으로 여러 언어나 플래폼의 개발환경을 보장해주는 이유는 첫째, UML 기반의 디자인 도구라는 점입니다. 디자인이라는 측면은 개발 프로세스와는 무관하다고 할 수 있습니다. 디자인은 모델링과 설계 정도로 나눌 수 있습니다. 모델링 단계에서는 Entity를 구체화하고 요구사항을 분석하긴 하지만, 실제 적용 시스템에 의존적이진 않을 겁니다. 설계에서는 의존적인 부분이 있습니다만 이 부분 조차도 UML을 사용한다는 점에서 의존적이라기보다는 유연하게 대처할 수 있다 정도로 말해도 될 것 같습니다. 이는 UML이 OOP 기반의 모델링 언어라는 부분 때문입니다. 이것이 둘째 이유가 됩니다.
둘째, OOP를 사용하는 점입니다. UML을 사용하다는 의미에서 비슷한 요소가 됩니다만 다른 시각에서 보면 추가적인 기능이 있습니다. 우선 OOP 바탕으로 되어있는 언어는 Together와 연동 시키기가 용이하다는 얘기가 됩니다. 즉 Together - (UML - (OOP)) - C++, Java 라는 흐름을 볼 수 있구요, 여기다가 플래폼용 라이브러리를 추가하면 Together - (UML - (OOP)) - C++, Java로 만들어진 플래폼용 라이브러리 라는 구성이라고 보면 되겠습니다.

정리 하자면, 이러한 이유로 Together에서 나온 결과물은 디자인에 쓰일뿐 아니라 소스 레벨까지 나오게 됩니다. 즉 Design 영역의 결과물이 Develop 영역까지 진행할 수 있다는 겁니다.

디자인 -> 소스 생성 -+-> 디자인 수정 -+-> 동기화...
                                |                       ^
                                |                       |
                                +-> 소스 수정   -+
                    
이런 과정을 반복을 합니다만, Together라는 툴에서 소스나 디자인 수정시 라이브소스라는 디자인과 소스 동기화 기술로 어느쪽에 수정을 하든 상관없게 해줍니다. 이러다보니 Design 영역이 Develop 영역과 혼재되버리는 거죠. 이런 현상은 오히려 자연스럽다고 할 수 있고, 앞으로 진행되어야할 방향이기도 합니다.
  그렇다면 이런 점이 왜 'Design 영역과 Develop 영역의 연계 문제인가?' 하면 Design 영역에서 Develop 영역의 기능을 지원하는 정도는 Develop 영역에서 자체적으로 지원을 해야하지 않나 하는 부분입니다. 구체적으로는 디자인 패턴을 적용해서 클래스를 생성하는 등의 디자인 패턴 지원(http://xper.org/wiki/xp/DesignPatterns), 생성된 클래스의 재구성을 도와주는 리팩토링 지원(http://xper.org/wiki/xp/ReFactoring), 테스트 기반의 개발(TDD, http://www.tdd.or.kr/moin.py, http://xprogramming.com/software.htm)을 지원하는 테스트 모듈 지원 입니다. 물론 일일이 수작업으로 구성할 수 도 있고, 여타 기법으로 처리를 할 수 있습니다만 이러한 기능은 Together툴에서 이미 지원을 하고 있습니다. 하지만 C++BuilderX는 현재 지원하고 있지 않으며, 앞으로도 어찌될지 모른다는 겁니다. Design 영역에서 다해버릴 수 가 있으니까요. Design 영역에서 더 Develop 영역다운 면모를 보여준다면, 굳이 Develop 영역 전문 툴들을 사용할 이유가 없겠지요.
  저같이 작은 규모의 프로젝트를 하는 개발자는 ALM 전 영역을 소화해야 하니까, 필요한 기능들만 조금씩 적용하면 됩니다만, 큰 규모의 프로젝트는 모델러, 디자이너, 컨스트럭터, 코더, 테스터... 등등 세분화 될텐데요, 컨스트럭터가 만들어낸 결과물을 가지고 코더가 작업을 할때, 결과물 분석부터 시작해서 일일이 수작업으로 적용을 한다면 ALM이라는 말이 툴을 적당히 구분했다 정도로만 그칠 것 같습니다.

ALM에 의해 구분된 솔루션 자체가 따로 구분할 수 없는 부분이 이렇듯 존재하고 있습니다. 이러한 부분에 대해서 다 알 필요는 없지만, C++ BuilderX가 향후 어떻게 될지 정도는 예측 할 수 있었으면 합니다. C++ BuilderX에 추가했으면 하는 바램은 Together 수준의 디자인패턴, 리팩토링, TDD 의 지원입니다(가장 바라는 것은 Togethr Edition for C++Builder 입니다만 ^^;). 혹시 또 메일을 보내실 때 의견을 같이 수렴해주셨으면 합니다.