Borland C++Builder vs. Microsoft Visual C++

0. 개요

비교 항목	Borland C++Builder	Microsoft Visual C++
빠른 RAD 개발	○ (비주얼하다)	× (비주얼하지 않다)
습득 용이성	쉽다 (2개월 ~ 1년)	어렵다 (6개월 ~ 수년)
개발 생산성	높다	낮다
코드 재사용성	높다	낮다
ANSI/ISO 표준 C++ 지원	높다	낮다
다양한 STL 지원도	높다	낮다
외부 C++ 코드 사용	용이	불편
지원 라이브러리	VCL, CLX, OWL, MFC, ATL, STL	MFC, ATL, STL
주력 라이브러리 난이도	VCL: 단순하고 쉽다	MFC: 복잡하고 어렵다
경쟁 개발툴 소스 지원	○	×
STL 지원	STLport, RogueWave 등 다양한 STL	포함된 변형 버전만 지원
DOS 프로젝트 포팅	쉽다	어렵다
크로스플랫폼 개발	○ (윈도우/리눅스)	× (윈도우)
윈도우 개발 능력	높음	높음
리눅스 개발 능력	○	×
기술의 포용성	높다	낮다
타사 기술 지원	높음	미약
타 개발툴 소스	Visual C++, Delphi 소스 직접 사용	불가

1. 빠른 RAD 개발

RAD란?

C++Builder는 C++ 언어에 기반한 RAD(Rapid Application Development) 개발툴입니다. 이 RAD라는 개념은, 우리가 흔히 ‘비주얼하다’라고 말하는 개념으로써, 클래스의 확장된 개념인 컴포넌트를 시각적으로 이용하여 프로그램의 개발 작업을 이전의 코딩에만 의존하던 방법에 비해 작업량을 혁신적으로 줄여줍니다.

RAD는 완전한 대세

이미 RAD 개발 방법은 개발자들에게 필수적인 개념이 되어 있습니다. 마이크로소프트사의 Visual Basic을 비롯하여 볼랜드의 Delphi 및 C++Builder, 사이베이스의 PowerBuilder 등이 모두 RAD 개발툴입니다. 또한 자바 분야쪽으로도 볼랜드의 JBuilder를 비롯하여 IBM의 VisualAge for Java, 오라클사의 Jdeveloper 등이 모두 RAD 환경의 개발툴입니다.

유일한 C++ RAD

C++ 언어 기반의 RAD 개발툴을 만든다는 것은 한때 불가능하다고 여겨져왔습니다. 대부분의 RAD 개발툴들의 경우, RAD 환경을 구축하기 위해 대부분 프로그래밍 언어를 뜯어고쳐야 했기 때문입니다. 반면 C++의 경우 ANSI/ISO C++의 강한 표준에 묶여 있는데다 언어 자체의 가변성이 높아서 RAD 개발툴의 기반 언어로 이용하기에는 무리가 많았습니다.

볼랜드 C++Builder는 이런 업계의 관측을 무색하게 한 혁신적인 개발툴입니다. 볼랜드는 C++ RAD 개발환경을 만들어내기 위해 기존의 프로그래밍 방법을 거의 건드리지 않는 선에서 6~7개의 키워드 추가 만으로 이것을 이루어냈습니다.

Visual C++

경쟁사인 마이크로소프트사의 Visual C++은, 현재 상업적인 개발툴 중 ‘유일한’ 구세대 개발툴입니다. Visual C++은 이전의 Microsoft C/C++의 단순 업그레이드일 뿐 이름에서와 같은 ‘비주얼’한 측면은 없으며, 제품명에 ‘비주얼’이라는 수식어를 붙인 것은 마케팅상의 목적 때문입니다.

습득 용이성 면에서의 차이

Visual C++로 프로그래밍을 하기 위해서는 기본 라이브러리인 MFC를 능숙하게 사용할 수 있어야 합니다. MFC는 전혀 비주얼하지 않은 일반적인 클래스 라이브러리로, 그 구조적인 복잡함 때문에 습득하는 데 상당한 기간이 필요로 합니다. 이전에 C++ 프로그래밍을 어느정도 갖고 있는 학생이라 하더라도 비주얼 C++에서 MFC로 어느정도 기초적인 프로그래밍이라도 하려면 최소 6개월 정도는 걸리며, 능숙하게 사용하려면 수년이 걸려도 모자란다는 문제가 있습니다.

C++Builder의 기본 라이브러리인 VCL은 비주얼하게 디자인할 수 있는 컴포넌트들의 라이브러리로서, 클래스 구조나 하나하나의 멤버들을 모두 숙지하기 전이라도 충분히 프로그래밍을 시작할 수 있습니다. C++Builder로 기본적인 프로그래밍 작업을 하기 위해서는 2~3개월 정도면 충분하며, 1년 정도면 능숙하게 사용할 수 있습니다.

개발 생산성 면에서의 차이

현재의 개발자에게는 높은 생산성이 다른 모든 기준들을 뛰어넘는 최고의 미덕으로 평가되고 있습니다. C++Builder의 RAD 개발 방법은 C++ 개발자들에게도 더 이상 성능이라는 최후의 마지노선에 집착하지 않아도 되게 해줍니다. C++Builder의 RAD 개발 방법을 이용하면 동일한 작업을 거의 성능 저하 없이 훨씬 빠르게 완수할 수 있습니다.

실제로 많은 Visual C++개발자들이 C++Builder의 이러한 높은 생산성에 매력을 느껴 수년동안 사용해왔던 Visual C++을 버리고 C++Builder를 주력 개발툴로 택하고 있습니다. 이렇게 C++Builder로 주력을 바꾼 개발자들은 실무에서 적용한 결과는 개발 기간의 단축으로 직접적으로 연결됩니다. C++Builder로 프로젝트를 수행해본 많은 개발자들이 같은 프로젝트를 Visual C++로 했더라면 두배에서 세배의 기간이 걸렸을 것이라고 혀를 내두르는 경우가 흔합니다.

코드의 재사용성 면에서의 차이

소프트웨어 공학에서의 재사용성은 생산성과 함께 개발자들에게 또 하나의 화두입니다. 재사용성에 대한 관심으로 C 언어 시대의 함수 라이브러리는 클래스 라이브러리로 발전해왔으며, 이제 한 차원 더 높은 컴포넌트 라이브러리에까지 이르렀습니다. 컴포넌트는 C++ 기반 클래스의 재사용성을 극대화한 것으로 OOP의 장점을 진정 제대로 활용하는 방법입니다.

Visual C++이 재사용성면에서 좀 뒤져있는 클래스 구조를 주로 사용하지만, Visual C++에서도 컴포넌트를 전혀 지원하지 않는 것은 아닙니다. 마이크로소프트는 COM/ActiveX 기반의 컴포넌트 기술을 Visual C++에서 사용할 수 있도록 지원합니다. 하지만 이들 기술들은 기존 기술에 비해 비대한 크기와 성능의 저하를 가져오는 단점이 있습니다.

이에 반해, C++Builder는 컴포넌트의 재사용성이 대단히 뛰어날 뿐 아니라 컴포넌트를 사용하더라도 성능의 저하는 거의 없습니다.

2. ANSI/ISO 표준 C++ 지원

C/C++의 역사, 볼랜드

C++Builder는 터보 C(Turbo-C)와 볼랜드 C++(borland C++)가 업그레이드된 후속 제품입니다. 터보 C와 볼랜드 C++은 각각 IT 업계에 C와 C++ 프로그래밍 열풍을 불러일으킨 주인공으로, C/C++ 언어 역사의 가장 중요한 부분을 차지하고 있습니다. C++Builder 6에 포함된 컴파일러 엔진은 볼랜드 C++ 5.6입니다.

표준 C++

볼랜드는 초기부터 자사의 모든 개발툴에 대해 업계 표준을 준수하려는 의지를 가져왔습니다. 이것은 C/C++ 개발툴에 있어서도 마찬가지입니다. 현재에 있어 C++Builder는 상업적으로 판매되는 C++ 컴파일러들 중 ANSI/ISO 국제 C++ 표준을 가장 잘 준수하는 것으로 업계에 정평이 나 있습니다.

다른 C/C++ 개발툴과의 소스 호환성

이 같은 표준의 준수는, 타 C/C++ 개발툴들과의 소스코드 호환성에 있어 대단히 중요한 의미를 갖습니다. 이에 반해 마이크로소프트사의 Visual C++은 종종 표준을 지키지 않는 경우가 있습니다. 일반적인 C++ 문법에 맞고 다른 컴파일러에서도 잘 동작하는 코드가 Visual C++에서는 오동작하는 경우로 개발자들이 애로를 호소하는 경우가 종종 있습니다. C++Builder에서는 이런 일이 전혀 없는 것은 아니지만, Visual C++에 비하면 대단히 적습니다.

STL 지원 정도

표준 템플릿 라이브러리(Standard Template Library, 이하 STL)는 모든 C++ 컴파일러들이 지원해야 하는 중요한 표준 라이브러리입니다. C++Builder는 자체 내에 번들된 STLport 버전과 RogueWave 버전은 물론, 대부분의 STL 버전들을 지원합니다.

Visual C++의 미약한 표준 지원은, STL 지원에서도 문제를 일으킵니다. Visual C++은 대부분의 STL 배포 버전들을 제대로 소화해내지 못한 관계로 자체내에 Visual C++만을 위해 특별히 커스터마이즈(customize)된 STL 버전을 따로 번들하고 있습니다.

3. 다양한 라이브러리의 지원

막강한 라이브러리들의 지원

강력한 RAD 엔진과 표준 C++ 컴파일러와 함께, 다양한 라이브러리에 대한 지원은 C++Builder의 또하나의 중요한 장점 중 하나입니다.

Visual C++에는 기본 라이브러리인 MFC 외에 ATL과 STL이 포함되어 있습니다. 꽤 다양한 것 같지만, C++Builder에 비하면 답답한 수준입니다.

C++Builder는 기본 라이브러리인 VCL 외에 크로스플랫폼 개발을 위한 CLX, 이전 제품인 볼랜드 C++의 OWL은 물론, STL의 두가지 버전(STLport,/RogueWave), Visual C++의 MFC와 ATL, 그리고 터보C에서 볼랜드C++까지 업그레이드되어온 볼랜드 RTL 등의 라이브러리들을 포함하고 있습니다.

배우기 쉬운 라이브러리

Visual C++의 MFC는 배우기가 어렵기로 개발자들 사이에 악평이 높습니다. 개발자들의 편를 고려하여 제대로 만들어진 라이브러리라면 그렇게 어려울 필요는 없습니다. C++Builder의 주력 클래스 라이브러리는 그 자체가 비주얼한 RAD 엔진의 일부이므로 배우기가 쉬우며, 처음 공부하기 시작해서 전체 구조를 파악하지 못하더라도 당장 프로그래밍을 시작할 수 있습니다.

경쟁 개발툴의 소스 지원 여부

C++Builder는 MFC를 라이선스하여 포함하고 있어, 경쟁 개발툴인 Visual C++의 소스코드를 손쉽게 불러들여 컴파일할 수 있습니다. 이에 더하여 Visual C++ Project Import 유틸리티를 포함하고 있어 Visual C++로 작성된 프로젝트 전체를 통째로 C++Builder에서 컴파일할 수 있습니다.

이런 특징으로 인해, Visual C++로 작성했던 프로젝트를 C++Builder로 마이그레이션하는 작업이 대단히 편해집니다. 여러 개의 소스파일로 이루어진 Visual C++ 프로젝트를 일단 C++Builder로 컴파일한 후, 단계적으로 소스코드별로 마이그레이션할 수 있습니다.

Visual C++에서는 C++Builder의 주력 라이브러리인 VCL을 지원하지 않습니다.

DOS 프로젝트의 윈도우 포팅

DOS 기반으로 개발된 프로그램의 대다수는 볼랜드의 터보 C 혹은 볼랜드 C++로 작성되어 있습니다. 이런 DOS 프로젝트를 윈도우로 포팅하기 위해서는 단지 윈도우 코드로 바꾸는 작업 외에도, 터보 C나 볼랜드 C++에서 사용되었던 수백개의 볼랜드 RTL 함수들도 심각한 문제가 됩니다.

C++Builder는 터보 C와 볼랜드 C++의 후속 버전이므로 볼랜드 RTL들을 기본으로 포함하고 있어, 터보 C나 볼랜드 C++ 기반의 DOS 프로젝트를 윈도우로 포팅하기가 용이합니다. 반면 Visual C++은 마이크로소프트 C/C++의 후속버전으로서 볼랜드 RTL 함수들은 지원하지 않아, 윈도우 환경으로 포팅하기가 대단히 까다롭습니다.

4. 크로스 플랫폼 개발

C++Builder 6와 Kylix 3 for C++

볼랜드는 오래전부터 리눅스의 강력한 지원자중 하나입니다. 썬마이크로시스템즈사와 협력하여 리눅스용 자바 플랫폼을 공동으로 개발한 것을 비롯하여, 2001년 초에는 볼랜드 Delphi의 리눅스 버전인 Kylix 1을 출시하였습니다. Kylix 1은 리눅스 환경을 위한 최초의 RAD 환경이며, 윈도우용 Delphi와 완벽한 소스코드 수준 호환성을 가지고 있습니다.

여기에서 한발 더 나아가서, 볼랜드는 2002년 7월에 C++ 언어를 추가한 Kylix 3를 출시하였습니다. Kylix 3는 기존의 Delphi 언어(Object Pascal)에 더해 C++ 언어를 위한 별도의 IDE를 가지고 있습니다.

Kylix 3 for C++은 윈도우용 C++Builder와 모양부터 기능까지 완벽하게 동일하며, 크로스플랫폼 라이브러리인 CLX(component Library for Cross-platform)를 이용하여 윈도우용 C++Builder에서 개발한 소스코드와 100% 호환이 됩니다. 물론 반대로 리눅스에서 Kylix 3 for C++로 개발한 소스코드도 윈도우용 C++Builder에서 사용가능하며, 실질적으로 어디에서 개발했건 소스코드는 동일하게 됩니다.

윈도우 개발 능력에서의 비교

볼랜드 C++Builder와 마이크로소프트 Visual C++은 윈도우 플랫폼에서의 개발 능력에 있어서는 완벽하게 동등합니다. 그것은 C++Builder가 마이크로소프트가 제시한 Win32 플랫폼 표준을 100% 지원하기 때문입니다. 기본적인 exe 실행 프로그램은 물론, Dll(Dynamic Link Library), NT 서비스, ISAPI 웹서버 애플리케이션 등등, 비주얼 C++에서 지원하는 모든 형식을 동등하게 지원합니다. 물론 더 쉽고 빠르게 개발할 수 있습니다.

리눅스 개발 능력에서의 비교

앞서 설명드린 대로 윈도우에서 볼랜드 C++Builder로 개발한 소스코드는 그대로 리눅스 플랫폼에서 Kylix 3 for C++로 그대로 컴파일 가능하며, 사실상 Kylix 3 for C++이 리눅스용 C++Builder라고 할 수 있습니다.

마이크로소프트사에서는 마케팅 정책상 리눅스 환경을 위한 Visual C++을 출시할 계획조차 없는 상태입니다. 이것은 Visual C++이라는 일개 개발툴 시장보다, 윈도우라는 플랫폼 시장이 훨씬 더 크며, 근본적으로 마이크로소프트사가 개발툴 시장을 계속 이어가는 이유가 플랫폼 시장을 위한 마케팅 도구로서 이용하기 위해서이기 때문입니다.

5. 기술의 포용성

볼랜드의 기술 포용 정책

볼랜드는 초기부터 업계의 다양한 기술들을 모두 포용하는 방향으로 정책을 정하고 개발툴들을 개발해왔습니다. 볼랜드는 자사의 경쟁 회사의 기술들까지도 포용해왔으며, 서로 경쟁중인 여러 벤더들의 기술들을 두루 포용하고 있습니다. 반면 마이크로소프트사 등 다른 대부분의 IT 업체들은 보통 자사와 경쟁하는 기술은 거의 포용하지 않습니다.

이런 볼랜드의 정책에 따라, ‘볼랜드는 IT 기술에 있어 스위스와 같다’는 평판을 얻고 있습니다. 현재도 볼랜드는 윈도우-닷넷-리눅스-자바의 4대 플랫폼을 모두 높은 수준으로 지원하고 있는 유일한 회사입니다.

C++Builder의 타사 기술 지원

볼랜드의 이런 포용적인 기술 정책은 물론 C++Builder에도 마찬가지로 적용됩니다. C++Builder는 자바 진영의 CORBA와 마이크로소프트의 DCOM 기술을 양쪽 모두 지원하는 드문 개발툴입니다. 또한 윈도우 플랫폼과 리눅스 플랫폼 사이의 크로스플랫폼 개발을 지원하는 유일한 개발툴입니다.

다른 개발툴 소스 지원

C++Builder는 앞에서 말했던 대로 Visual C++의 소스를 사용할 수 있음은 물론, Delphi 컴파일러가 내장되어 있어 Delphi 소스를 하나의 프로젝트 안에서 같이 컴파일할 수 있습니다.