Delphi와 C++Builder의 개발툴로서의 가장 큰 특징들 중의 하나는 바로 다양한 서드파티 컴포넌트들이죠. 물론 경쟁 개발환경인 .NET이나 네이티브 환경의 비주얼 스튜디오에도 OCX 등의 여러 서드파티 컴포넌트들이 있습니다.

하지만 Delphi와 C++Builder에 있어 서드파티 컴포넌트는 MS 개발환경에서 지원하는 것과는 많이 다릅니다. 닷넷 컴포넌트나 OCX 형태의 컴포넌트는 대체로 덩치가 크고 둔하며, 개발자가 개발한 애플리케이션 바이너리에 완전히 통합되지도 않습니다. 반면 VCL 서드파티 컴포넌트는 작고 빠르며, Delphi/C++Builder의 기본 VCL과 완전히 동등한 수준이기 때문에 순수하게 네이티브합니다. 물론 개발한 애플리케이션 실행파일 등에 완전히 링크가 가능하므로 별도로 배포할 필요도 없습니다.

하지만, 적지 않은 경우에 이런 서드파티 VCL 컴포넌트들이 논쟁의 대상이 되기도 합니다. 상당히 많은 개발자들이 여러 이유로 서드파티 컴포넌트의 사용을 의도적으로 피하기도 하고, 반대로 또 많은 개발자들은 필요한 어떤 기능이 대두되면 자체 구현을 하기에 앞서 적극적으로 서드파티 컴포넌트부터 찾아보기도 합니다.

저는 후자쪽입니다. 물론 무조건 서드파티 컴포넌트가 더 낫다는 것은 아니구요. 적절한 대안 컴포넌트가 이미 존재하고 특별한 문제가 없다면, 굳이 자체 구현하기 위해 다른 중요한 기능들에 들일 수 있는 시간을 이미 존재하고 구할 수 있는 컴포넌트 기능의 구현을 위해 시간을 들일 필요는 없다는 거죠.

다만, 서드파티 컴포넌트의 사용을 피하는 분들의 주장에도 고려해볼 만한 부분이 있습니다. 서드파티 컴포넌트를 사용했다가 차후 Delphi/C++Builder를 업그레이드했을 때 바이너리 버전 문제가 발생한다든지 혹은 지원이 끊어진다든지 하는 부분에 대한 우려가 가장 클 것입니다.

서드파티 컴포넌트를 사용하는 데 있어서, 단순히 설치된 그대로 사용하기만 하기보다는 최소한의 소스코드 핸들링은 필요하다고 생각됩니다. 다시 말해, 아예 소스가 제공되지 않는 컴포넌트의 경우 어쩔 수 없겠지만(바로 아래 언급한 RealGrid가 그 예죠), 소스 코드가 제공된다면 자체 컴파일 정도는 할 수 있고, 개발툴의 버전이 업그레이드되었을 때 최소한의 검증이나 판단은 가능해야 한다는 것입니다. 개발툴을 업그레이드해야 하는데 기존에 사용하던 컴포넌트를 도대체 어떻게 해야 하는지 방향조차 잡지 못해서는 안되겠죠.

이런 부분은, 프로젝트 팀 내에 아키텍트 역할을 하는 개발자가 책임을 져야 할 부분입니다(‘팀장’ 혹은 PM/PL과 같은 사람일 수도 있지만 엄밀하게 말해서 아키텍트는 별도의 역할이죠). 만약 4~5명 이상의 개발자가 모여 공동 프로젝트를 수행하는데 이런 정도의 최소한의 기술적 핸들링을 할 레벨의 개발자도 없이 진행하고 있다면, 그 프로젝트 팀은 기술적으로 심각하게 취약하다고 할 수 있겠습니다.

또, 여러 컴포넌트들 중에 어떤 컴포넌트를 선택할 것인가의 문제도 간단한 문제가 아닙니다. 단순히 원하는 기능이 다 있다고 해서 다른 고려 없이 채택해서는 위험한 상황에 빠질 수 있습니다. 필요한 기능이 구현되었나의 여부 외에 다음과 같은 것들이 중요한 기준이 될 수 있을 것입니다.

성능의 문제 – 화려한 UI 때문에 선택하는 컴포넌트가 화면 갱신 속도가 너무 느려서 화면이 그려지는 게 하나하나 보여질 정도라면 곤란하겠죠. 또 TCP/IP이나 시리얼과 같이 통신 컴포넌트의 경우, 그리고 특정 알고리즘을 구현한 컴포넌트의 경우에도 성능이 주요 이슈가 되겠습니다.

배포 크기의 문제 – 대부분의 강력한! 컴포넌트들은 프로그램의 배포 크기를 생각보다 훨씬 크게 만듭니다. 커지는 것 자체는 어쩔 수가 없겠지만, 그게 용인 가능한 수준인가 아닌가는 고려해야 하겠지요.

가격의 문제 – 대부분의 서드파티 VCL 컴포넌트는 타당한 수준의 가격이 매겨져 있습니다. 적지 않은 컴포넌트들이 무료로 배포되기도 하구요. 하지만 QuickReport가 그보다 훨씬 강력한 컴포넌트인 FastReport보다 몇배나 비싸게 판매되고 있는 것처럼, 판매 가격이 좀 비상식적인 경우도 있습니다.

지원의 문제 – 저는 이것이 가장 중요한 문제라고 생각합니다. 꽤 시간이 흐른 후에 큰 버그를 발견했다든가, Delphi나 C++Builder가 메이저 업그레이드가 되었을 때 업그레이드하려고 찾아보니 회사 사이트 자체가 없어져서 어디 하소연할 곳도 없다든가 하는 경우가 적지 않게 있습니다. 특히, 가벼운 마음으로 갖다 쓴 무료 컴포넌트가 종종 문제가 됩니다. 물론 소스포지 등의 오픈소스 프로젝트로 활발하게 지원이 이루어지고 있는 컴포넌트의 경우 큰 걱정을 할 필요가 없겠지만, 개인 개발자가 본인의 홈페이지에 올려놓은 무료 컴포넌트의 경우, 몇년쯤 후에 연락할 방법조차 없어지는 경우도 있는데, 이렇게 되면 정말 난감할 수밖에 없습니다. (물론 이런 경우라도 팀내 아키텍트가 이 소스를 핸들링할 수 있다면 문제가 없겠습니다만)

물론 이런 컴포넌트의 기술적 핸들링은 그리 간단한 일이 아닙니다. 하지만, 이런 ‘오버헤드’가 두려워서 무조건 서드파티 컴포넌트를 아예 안쓰고 프로젝트를 하는 것이 좋은 방법일까요?

그런 만큼 개발팀 내에 아키텍트가 최소한의 핸들링을 할 수 있는 역량을 가지는 것이 중요합니다. 업무개발 프로젝트에서 아키텍트가 전혀 없거나, 조직내에서 공식적으로 인정되는 직책이 아닌 비공식적으로 아키텍트 역할을 하고 있어 필요한 권한과 책임이 부여되지 않은 경우가 적지 않은데요. 서드파티 컴포넌트 때문이 아니더라도 여러가지 기술적 시도에 대한 리스크에 대해 검토하고 검증할 아키텍트는 꼭 필요합니다.

만약 여러 여건상으로 서드파티 컴포넌트의 채택 문제를 기술적 리더십을 가지고 결정할 수 있는 아키텍트를 운영할 수 없고 다른 어디에서도 자문을 구할 수 없다면, 제게 문의를 해주셔도 좋습니다. 물론 공식적인 책임을 가지고 뒷일까지 핸들링을 하려면 유료의 컨설팅이 될 수밖에 없지만, 비용을 들이지 않더라도 최소한의 의견 정도는 무료로 상담해드릴 수 있습니다.

정리하자면, 델파이와 C++빌더에 있어 서드파티 컴포넌트는 개발의 역량을 몇배로 올려줄 수 있는 중요한 선택입니다. 물론 아무런 대비도 없이 당장 편하게 갖다 쓸 수 있다는 정도의 생각으로 사용하다보면 문제가 많이 커질 수 있지만, 위험도도 이해하면서 체계적으로 관리하면서 사용한다면 이런 위험성은 충분히 막으면서 생산성과 기능, UI의 품질을 끌어올릴 수 있습니다.