조형익 wrote:

> 저희 회사에 맞는 4GL언어를 선택할려고 하는데

> 어떤언어를 선택해야 할지 모르겟네요..

>

> Delphi/ Visual Basic/ Power Builder 제품간의 비교자료나,

> 장단점을 기록한 자료나, 사용경험이 있으신 분이나

> 많은 정보를 부탁드립니다.

>



여기 Q&A덕을 본사람입니다.

제가 조사한걸 혹시 필요로 하는사람이있을 수도 있을것 같아서 띄워놉니다.



표로만들어놓은것도 있으니 필요하신분은 연락 주십시오.





천리안 ▶ C프로그램세계PC 출력일 : 2000/05/22

제 목 : [9810]비주얼베이식과델파이-1

----------------------------------------------------------------------------

월 호 : 98년 10월





비주얼베이식과 델파이 그 끝은?

현재 윈도 플랫폼에서 가장 인기있는 RAD 개발툴을 꼽으라면 무엇을 들 수

있을까? 대부분의 사람들이 주저없이 비주얼베이식과 델파이를 지목할 것이다.

그간 VB와 델파이의 비교에 대해서는 아주 많은 논의와 말들이 있었다. 일단

본격적인 RAD툴의 새벽을 연 VB는 편리한 사용자 인터페이스와 MS라는 큰

OS개발사를 업고 있다는 막강한 장점을 무기로 해서 시장점유를 넓혀나갔다.

이에비해 후발주자로 뛰어든 인프라이즈의 델파이는 빠른 개발과 편리한 디버

깅뿐만 아니라 VB보다 높은 프로그램 퍼포먼스로 사용자 층을 넓혀갔다.

각 툴이 분명히 강한 부분이 있고 그렇지 못한 부분이 있지만 그것마저도 각

도구의 특성으로 이해하고, 어째서 이 툴이 그런 형태를 갖게 되었는가를 이해

시키는 것이 이 글의 목적이다. 보다 많은 사람이 이 훌륭한 두 RAD의 특성과

각각의 장단점을 이해하고 용도에 맞게 활용할 수 있다면 좋겠다.

노규남 자유기고가 BARD@hitel.net



VB 3.0 vs 델파이 1.0

시장에 먼저 나타난 것은 VB였는데 VB는 베이식의 쉽고 간편한 언어를 지원

한다는 장점과 VBX라는 확장라이브러리에 힘입어 순식간에 확산되었다. 더구

나 IDE안에 컴파일하지 않고 실시간으로 실행시키면서 디버그할 수 있는 도구

를 포함시켜서 훨씬 더 디버깅작업을 쉽게 만들었다. 그러면서 VB는 3.0까지

윈도에서의 유일한 비주얼툴로 군림했다.

그러나 도스에서 TC나 BC시리즈로 컴파일러 시장을 석권했던 볼랜드도 가만

있지 않았다. 볼랜드는 도스시절의 히트상품이었던 파스칼을 다시 꺼내서 윈도

에서 작동하는 투웨이 툴로 작성함으로써 델파이를 탄생시켰다. 이때는 델파이

가 VB보다 후에 나왔기 때문에 필자를 포함한 VB 옹호론자들이 무슨 얘기를

하든지간에 델파이가 기능적으로(이런 면에서 우수한 것이 항상 히트상품이 되

지는 않지만) 우세했다는 것을 인정하지 않을 수 없다.

델파이는 VB보다 다소 어렵지만 네이티브 코드 컴파일러를 지원한다는 것, 볼

랜드의 축적된 컴파일러 기술을 사용한 빠른 컴파일시간 등으로 순식간에 사용

자들을 매료시켰다. VC++의 애매한 코드와 VB의 느린 속도에 염증을 내고 있

던 사용자들은 삽시간에 델파이에 빠져들었다.

그러나 VB는 이미 3.0까지 업그레이드를 하면서 엄청난 사용자와 서드파티를

확보하고 있었고 델파이는 그 우수성에도 불구하고 그렇게 많은 시장을 뺏지는

못했다. 이에는 VB가 베이식이라는 대단히 명료하고 쉬운 언어를 기반하고 있

다는 점도 상당히 기여했을 것이다.

어쨌거나 마이크로소프트(이하 MS로 약칭)는 델파이의 출현으로 VB의 존립에

상당히 위협을 느끼게 되었고, 볼랜드는 볼랜드 나름대로 도스에서의 영광을

찾으려는 노력을 지속하지 않을 수 없었다. 그래서 VB 3.0과 델파이 1.0의 승

부는 좀 싱겁게 끝났다. 굳이 판정을 내리자면 시장에서는 VB가 우세했고 기

능적으로는 델파이가 우위였다.



VB 4.0 vs 델파이 2.0

95년은 중요한 사건이 있었던 해이다. 바로 그해 MS의 야심작 윈도 95가 발표

된 것이다. 운영체계가 새로 발표되면 무엇보다도 개발툴의 업그레이드가 절실

해진다. 새 술은 새 부대에 담으라는 말이 있듯이 새로운 운영체계에는 그 운

영체계의 특성을 잘 반영할 수 있는 새로운 개발툴이 필요해진다. 그래서 MS

는 좀 서둘러서(아무리 봐도 서두른 흔적이 보인다) 별 다를 것도 없는 VB 4.0

을 발표했다(발표된 것은 96년이다).

VB 4.0은 내부적으로 달라진 부분이 많았다. 일단 인텔계 CPU에 다소 종속된

구조를 갖는 VBX를 OCX로 대치하도록 했고 툴 자체를 COM 객체를 조각 맞

춘 형태로 함으로써 앞으로 윈도 95가 지향하는 COM기반의 프로그래밍을 가

능하게 만들었다. 그리고 데이터베이스에 있어서도 오피스가 업그레이드됨에

따라 Jet 엔진이 2.5로 버전이 올라갔고 새로운 데이터베이스 객체인 RDO 등

이 추가되었다. 그러나 전반적으로 봤을 때 VB 4.0은 윈도 3.1용이었던 VB 3.0

을 윈도 95용으로 이식한 것에 지나지 않는다는 인상이 강했고 사용자들에게

확실하게 어필하지 못했다. 그에 비해서 델파이 2.0은 강점인 네이티브 코드와

빠른 컴파일 속도, 적은 자원 요구를 잘 살려서 새로운 기능들도 많이 추가되

었고 개발자 입장에서는 훨씬 매력적인 툴이 되었다.

VB와 델파이의 기능비교가 화제가 되었던 것도 이때 가장 활발했다. VB는 여

전히 의사코드였고 COM을 사용하는 오버헤드가 있었기 때문에 속도는 3.0에

비해서 더 느렸다. 그래서 이때 많은 개발자들이 델파이쪽으로 옮겨갔다. 델파

이로 보면 이때가 가장 좋았던 시절이 아니었나 생각된다.

===============================================================

VB 3.0 델파이 1.0

비주얼 툴의 효시. VBX사용(2.0에서부터) Two-Way툴. 16비트 네이티브 코

데이터베이스 기본탑재 드를 생성

---------------------------------------------------------------

VB 4.0 델파이 2.0

컴포넌트가 OCX로 바뀜. 16비트와 32비트 32비트 코드로 바뀜

버전이 동시에 개발됨. 클래스모듈 포함

---------------------------------------------------------------

VB 5.0 델파이 3.0

원시코드 컴파일러. 사용자정의 컨트롤지원. Code Complete Wizard지원.

ActiveX Document지원. 인텔리센스 마이다스(MIDAS)

---------------------------------------------------------------

VB 6.0 델파이 4.0

? ?

===============================================================

표 1 : VB와 델파이의 비교연표



VB 5.0 vs 델파이 3.0

그런데 1년 후에 중대한 사건이 다시 일어난다. 업그레이드한지 1년도 채 되지

않은 VB가 다시 업그레이드되며 이번에는 더구나 ‘네이티브 코드’를 지원한

다는 소문까지 돌았던 것이다. 그 외에도 윈도의 커스텀 컨트롤인 OCX를 제작

할 수 있도록 되었다는 얘기 등, VB 5에 대해서는 온갖 무수한 소문들과 억측

이 난무했다.

그리고 마침내 VB 5가 발표되었는데 이 프로그램은 정말로 물건이라고 할 수

밖에 없을 정도로 훌륭했다. 네이티브 코드와 OCX 제작을 지원하는 것은 물론

이고 인터넷을 위한 ActiveX Document 지원과 수많은 자동화도구들, 지금까

지도 다른 툴 사용자들의 부러움을 사고 있는 인텔리센스 등 VB 5는 여태까지

와는 전혀 다른 도구라고 말할 수 있을 정도로 많은 변화를 가지고 나타났다.

또한 오피스에서 VBA로의 지원, 인터넷 익스플로러에서 VBS로의 지원 등

VB는 이제 하나의 개발도구가 아닌 컨셉으로서 윈도에 단단히 자리잡게 되었

다. 이렇게 엄청난 무기를 들고 온 VB쪽에 비해서 델파이 3.0은 다소 조용하게

발표되었고 사람들의 눈길도 끌지 못했다. 다만 예전부터 델파이를 사용하던

사람들은 마이다스(MIDAS)라는 새로운 컨트롤세트를 써보고 그 엄청난 효용

에 감탄했다.

그외 VB의 인텔리센스에 해당하는 Code Complete Wizard같은 좋은 기능이

많이 있었지만 언제나 사람들은 새로운 변화에 끌리게 마련이다. 대단한 변화

를 가지고 돌아온 VB 5.0은 일대 선풍을 일으켰다.

그리고 VB 6.0 vs 델파이 4.0

그리고 이제는 VB 6.0과 델파이 4.0이 거의 동시에 발표되었다. 이 두 개발툴

의 릴리즈는 윈도 98의 발표와 때를 맞춘 것으로, 역시 새로운 운영체계가 드

러났기 때문에 새로운 도구가 있지 않으면 안되었다. 또한 이 도구를 평가하는

작업 역시 필요할 것이다. 그렇기 때문에 독자 여러분과 함께 비주얼베이식과

델파이를 다시 한번 되짚어 보는 시간을 가지려 한다.

최대한 공정하게 툴의 성능을 측정하기 위해서 여러대의 컴퓨터에 설치해서 사

용해보았고 사용한 CD는 각각 마이크로소프트와 인프라이즈에서 제공한 파이

널 베타였다. 더불어 한가지 면만을 보고 판단을 내리는 우를 범하지 않기 위

해 몇 가지의 주제를 가지고 테스트했다.

또한 이 글은 두 툴을 비교하고 각 주제에 대해 어떤 툴이 우수하다는 판정을

내리기 위함(즉 벤치마크)이 아니라는 점을 분명히 해둔다. 각 툴이 분명히 강

한 부분이 있고 그렇지 못한 부분이 있지만 그것마저도 각 도구의 특성으로 이

해하고, 어째서 이 툴이 그런 형태를 갖게 되었는가를 이해시키는 것이 이 글

의 목적이다.

보다 많은 사람이 이 훌륭한 두개의 RAD의 특성과 각각의 장단점을 이해하고

용도에 맞게 활용할 수 있기를 바란다.

===============================================================

도구 요구사항

---------------------------------------------------------------

VB 윈도 95 또는 윈도 NT 4.0(서비스 팩 3)

RAM 24M(32M 이상 권장)

펜티엄 90MHz이상

VGA이상의 해상도를 갖는 모니터

마우스 및 기타 포인팅 디바이스

CD-ROM

*하드디스크 요구량

VB6.0: 116MB typical;135MB maximum

IE: 43MB typical;59MB maximum

MSDN: 57MB typical;493MB maximum

윈도 NT 4.0 옵션 팩: 20MB 윈도 95 이상;200MB 윈도 NT 4.0

SQL Server: 80MB typical;95MB maximum

SNA Server: 50MB typical;100MB maximum

-----------------------------------------------------------

델파이 윈도 95, 윈도 NT 4.0(서비스 팩 3)

RAM 16M(32M이상 권장)

인텔 486DX/66MHz 이상

CD-ROM drive

VGA이상의 해상도를 갖는 모니터

마우스 및 기타 포인팅 디바이스

최소 60MB 하드디스크 여유분

===============================================================

표2: VB와 델파이의 하드웨어 요구사항(MS와 인프라이즈의 웹사이트에 근거)



새로운 특성들

VB6.0, 파격적인 업그레이드

VB는 매번 파격적인 업그레이드를 들고 나오는 편인데 이번에도 그에 어긋나

지 않게 많은 것이 바뀌었다. 먼저 사용가능한 모듈타입이 예전에는 폼, 모듈,

클래스 모듈, 사용자 정의 컨트롤, 속성페이지의 다섯 가지뿐이었지만 이번에는

사용자 정의 문서, DHTML 클래스, Data Report, Web Class, Microsoft

UserConnection 등이 추가되었다.

또한 만들 수 있는 프로젝트의 템플릿 타입에 데이터 프로젝트, IIS 응용프로

그램, 추가기능(AddIn) 등이 더해져서 늘었다. 이 각각의 추가된 컴포넌트들이

어떤 의미가 있는지는 이후 각 주제별 단락에서 좀더 자세하게 설명하도록 하

겠다. 또한 컴포넌트들이 거의 6.0으로 업그레이드되었으며 DBGrid 같은 데이

터 바운드 컨트롤들은 OLEDB를 지원하게 되었다. 한눈에 봐도 여러가지 메뉴

에서 바뀐 부분이 꽤 많은 것을 알 수 있는데 이런 새로운 기능 중에는 중요한

것들이 많으므로 주의를 요한다.

일설에는 디바이스 드라이버 프로젝트가 추가되었다거나 소스레벨의 상속이 가

능하게 되었다는 얘기도 있었는데 루머였던 것으로 밝혀졌다. 역시 이런 일은

끝까지 기다렸다가 뚜껑을 열어봐야 안다. 앞서 언급했듯이 엔터프라이즈 버전

의 가격은 1299달러 그리고 비주얼스튜디오 98을 구입하면 1619달러이다. 대부

분의 RAD 중에서는 가장 싼 가격이라고 말할 수 있는 수준이다.



MTS와 코바지원이 눈에띄는 델파이4.0

델파이도 새로운 기능들이 많이 추가되었다. 우선 많은 종류의 VCL컴포넌트가

추가되었는데 ActionList라든가, NestedTable, ORBConnection 등 새로운 개념

을 수용한 컴포넌트들이다. 사용자 편의측면에서 본다면 VB의 인텔리센스는

델파이 유저들에게 부러움의 대상이었는데 인텔리센스는 아니지만

Code

Complete Wizard라는 기능을 지원하여 좀더 빠르고 쉽게 각 객체의 속성이나

메소드를 인식하고 코딩할 수 있도록 했다(이건 이미 3.0부터 지원하던 것이

다).

또한 많은 위저드를 지원하여 사용자가 적은 코드로 많은 일을 하도록 구현하

였다. 델파이쪽의 위저드도 VB쪽의 마법사 못지 않게 편리한 기능을 많이 지

원하는데 그 중에서도 NT 서비스를 손쉽게 만들 수 있도록 한 NT Service

Application Wizard는 압권이다.

델파이 4에 추가된 기능 중에 가장 중요한 것은 MTS와 코바지원이라고 말할

수 있을 텐데 양자 모두 분산처리에 관계된 기술이다. 앞으로도 분산처리는 중

요한 기술중 하나로 자리잡을 것이다. 그외 오브직트 파스칼의 측면에서 상당

한 언어확장이 이루어졌다는 사실도 간과할 수 없겠다.

델파이 4.0은 VB 6.0보다 먼저 릴리즈되었으며 그렇기 때문에 정품이나 복사본

이 많이 배포되어 있을 것이다. 하지만 새로운 기능에 못지 않게 불안한 면들

이 존재하기 때문에(필자의 경우도 윈도 95에서 계속 다운되었기에 윈도 NT로

바꾸고서야 간신히 제대로 작동되었다. 이를 위해 델파이를 다섯 번쯤 설치했

다) 업데이트팩으로 패치해주지 않으면 프로젝트에 투입하고도 안심하기는 쉽

지 않을 듯하다.

인프라이즈 홈페이지에 이미 첫 번째 패치가 올라와 있으며 이를 설치한 후의

버전은 4.01이 된다. 델파이 4.0 C/S의 경우 국내에서의 소비자가격은 485만원

이라고 하는데 비주얼스튜디오 98과 비교해서도 2배 이상이나 되는 가격이다.

좀 많이 비싸다는 생각이 든다.

노파심에서 밝혀두는데 MTS는 Microsoft Transaction Server의 약자이다.

MS의 트랜잭션 서버를 델파이에서 지원한다는 것뿐이지 인프라이즈에서 새로

어떤 기술을 개발한 것이 아니다. 그럼 이제 두개 툴에 대해서 몇 가지 주제를

가지고 비교, 분석해 보도록 하자.







첫 번째 주제 : 데이터베이스

엔터프라이즈, 즉 기업환경에서 개발하는 경우는 거의 대부분 데이터베이스 관

련 업무를 처리하게 된다. 그만큼 이 데이터베이스 처리에 대한 능력은 중요한

데 MS와 인프라이즈도 이 중요성을 모르지 않는지라 사용자들 알게 모르게

이 부분에 공을 많이 들였다. MS는 VB뿐만 아니라 MS제품군 모두에서 사용

하는 데이터베이스 객체인 DAO를 이번에 3.51로 업그레이드했으며 인프라이

즈도 BDE를 업그레이드했다. 또한 C/S환경에서의 개발이 늘어남에 따라 서버

에 접속해서 사용하는 클라이언트 데이터베이스 프로그램도 중요해지는데 VB

의 경우는 SQL 서버를 기본으로 하여 여러 가지 ODBC 드라이버를 제공하고

있다.

===============================================================

툴 추가된 기능

---------------------------------------------------------------

VB 6.0 Native Code Compiler

ADO(ActiveX Data Object)

Integrated ActiveX Visual Database Tools

Automatic Data Binding

Data Environment Desinger

Data Report Desinger

Creation of Custom data consumers and providers

Multi-tier development & testing tools

Microsoft SQL Server 6.5 Developer Edition

Visual Modeler

Microsoft Visual SourceSafe 6.0

Windows NT 4.0 option pack

---------------------------------------------------------------

델파이 4.0 MIDAS Multi-tier Distributed Application Essentials

Advanced State of the Art AppBrowser IDE

Speed up coding and reduce syntax errors with

CodeInsight Robust Suite of Advanced

Debugging

Tools Best Windows Development

Environment Turn

corporate data into information for better decision

===============================================================

표 3 : VB 6.0과 델파이 4.0의 새로운 기능



델파이는 자사의 데이터베이스 서버인 InterBASE 서버를 CD안에 내장하고 있

고 전용 ODBC드라이버와 오라클 그리고 SQL 서버용의 드라이버도 같이 제공

한다. 데이터베이스 엔진의 퍼포먼스는 BDE쪽이 낫다는 평가를 받고 있는데

이건 공정한 평가라 생각된다(빠르다). 그러나 매일같이 빠르게 하드웨어가 발

전하는 것을 고려해 볼 때 속도차이는 그렇게 심각한 문제가 되지 않는다.

필자가 여기서 말하고자 하는 것은 속도 대 생산성비이다. 속도면에서 크게 이

익을 얻을 수 있다고 하더라도 DB프로그램을 제작하기가 까다롭다거나 시간이

많이 걸린다거나 하면 여러 가지 커스터마이징과 업그레이드가 잦은 요즈음은

그다지 매력적이지 못하다는 것이다. 그렇기 때문에 이 경우는 속도와 더불어

서 얼마나 원하는 프로그램을 빠르고 쉽게 만들 수 있는가하는 생산성면을 같

이 고려해야 한다. 또한 JET의 속도가 느린 것은 RDBMS의 스타일을 그대로

고집하는데 따른 오버헤드가 있다는 사실도 인정해야 할 것이다.



생산성이 돋보이는 VB

VB쪽의 데이터베이스는 모두들 잘 아는 대로 MS의 공통 데이터베이스 엔진

인 JET를 사용하고 있다. JET를 사용하는 방법에는 여러 가지가 있지만 어떤

방법을 쓰든지 실질적인 처리는 JET에서 담당하는 것이다. 이 방법에

는 ODBC, RDO, DAO, ADO, JET API 등 각 개발환경에 따라 여러 가지가 있는

데 앞서 언급한대로 이번에 DAO는 3.51로 업그레이드되었고 RDO의 버전은

변경이 없다.

또한 기업환경에서 데이터베이스가 많이 사용되는 것을 고려해서 처음 시작시

에 고를 수 있는 템플릿 타입에 ‘데이터프로젝트’라는 것이 추가되었다. 이

데이터프로젝트에는 디자이너(*.dsr)라는 생소한 타입의 모듈이 포함되는데 이

모듈을 통해서 ODBC나 SQL 서버 등의 C/S환경에 아주 쉽게 접속할 수 있으

며 더불어 미려한 리포트출력을 얻을 수 있다. 물론 이전의 방식대로 코딩할

수도 있으나 VB 6의 데이터베이스 개발환경은 대단히 많이 바뀌었다. 새로운

방식을 채택하는 것이 생산성에 도움이 될 것이다.

여기에는 새로운 AddIn인 비주얼 모델러라든가 T-SQL 디버거 등이 추가되어

서 SQL 서버 등에 연동해서 사용하는 경우 대단히 조직적이고 편리한 코드를

사용할 수 있다. 다만 간단한 로컬 데이터베이스 애플리케이션을 만들 경우 보

통 데이터 컨트롤과 데이터 바운드 컨트롤을 사용하게 되는데 이때 사용되는

데이터 컨트롤이 델파이의 TNavigatior 컴포넌트보다 현저하게 낮은 성능이므

로 불만의 요소가 된다.

처음 사용하는 사람들은 VB의 데이터베이스가 퍼포먼스가 낮고 여러 가지 귀

찮은 작업이 필요한 애물단지처럼 보일는지도 모르겠지만 그것은 MDB파일 자

체가 SQL 서버의 데이터베이스 객체(데이터베이스 디바이스가 아닌)와 거의

흡사한 형태를 갖고 있기 때문이다. 즉 dBASE 등, ISAM에 익숙한 사람이 로

컬에서 애플리케이션을 만든다면 잘 맞지 않을 그런 형태로 되어있다. 좋은 예

로 데이터컨트롤을 써서 레코드세트를 핸들링하는 경우는 ‘관련객체가 작업을

취소했습니다’라는 에러메시지가 자주 뜨는데 이것은 VB에서의 데이터베이스

작업이 SQL 서버와 마찬가지로 개개 작업이 각각 독립된 트랜잭션처럼 작동

한다는 것을 보여준다.

이런 사실은 VB가 사용상의 편의보다 데이터의 무결성에 더 중점을 둔, 좀더

엔터프라이즈적인 입장에서의 DBMS를 채용하고 있음을 실증한다. 또한 SQL

서버의 데이터베이스 객체를 그대로 본떠서 만들었기 때문에 인덱스나 내장쿼

리(Stored Procedure에 해당하는-QueryDef) 등의 객체를 MDB 파일 하나에

모두 포함하고 있으며 그런 이유로 트랜잭션이 많거나 로그가 복잡해지는, 의

외로 큰 규모의 애플리케이션을 코딩하는데 적합하다.

그러나 이는 RDBMS의 기본개념을 잘 이해하고 있는 경우에 한한다. VB의 데

이터베이스를 제대로 사용하려면 개념부터 바꿔야 한다. 또한 Add-In 중의 하

나인 Visual DataManager가 삭제되고 메뉴의 데이터 뷰(Data View)라는 버튼

이 추가되어 Visual DataManager보다 훨씬 더 강력하고 편리한 데이터관리를

할 수 있게 되었다. 기본적으로 모든 데이터를 연결(Connection)로 관리하며

테이블의 추가나 수정, 레코드 편집, SQL 서버에 접속한 경우 스토어드 프로시

저의 편집 등을 모두 수행할 수 있다.

더불어 비주얼 모델러(Visual Modeler)라는 Add-In을 통해서 시스템 모델을

설계하고 이를 클래스로 Import할 수 있다. 이 모델러는 규모가 있는 프로젝트

의 경우 효용이 클 것으로 기대되는데 만들어진 모델에 맞추어 VB와 VC++의

두개 툴의 소스코드를 자동으로 생성해준다. VB의 리포트 제작툴로 이름이 높

았던 크리스탈 리포트가 빠지고 그대신 리포트 디자이너라는 디자이너가 포함

되었다. 또한 응용 프로그램 마법사에서 자동으로 생성해주는 데이터 폼 코드

가 예전에 비해서 훨씬 안정되었다는 것도 주목할만하다. VB에서의 데이터베

이스를 공부하고 싶은 사람은 이 코드를 잘 살펴볼 필요가 있을 것이다.



속도면에서 우수한 델파이

델파이쪽은 그렇게 많은 변화는 없고 예전에 하던 방식대로 사용할 수 있다.

마이다스나 Decision Cube 같은 컨트롤들도 그대로이고 출력이나 선택을 돕는

여러 가지 컨트롤들도 그대로이다. 하나로 여러 가지 역할을 하는 VB쪽의 데

이터컨트롤들에 비해 델파이쪽의 컨트롤들은 그 기능에 따라 많이 세분화되어

있는 편이다. 테이블만을 갖는 TTable 컴포넌트나 쿼리만을 갖는 TQuery 컴

포넌트 등, 그 용도에 알맞게 많은 컨트롤들이 있기 때문에 코딩하는 사람의

머리를 다소 복잡하게 할는지도 모른다.

델파이에서 가장 좋은 것은 간단한 로컬 데이터베이스를 구성할 때 사용되는

VB에서라면 데이터컨트롤에 해당하는 TNavigator 컴포넌트가 상당히 좋은 퍼

포먼스를 나타낸다는 것이다. 컨트롤내에서 추가, 삭제 및 수정, 취소 등의 작

업을 모두 할 수 있으며 그때마다 테이블의 상태에 따라 사용할 수 있는 버튼

과 그렇지 않은 버튼을 자동으로 구분해서 Enable/Disable시켜주므로 편리하

다.

VB가 SQL 서버의 데이터베이스 객체를 본떠서 파일을 만든 것에 비해 델파

이쪽은 ISAM의 형태를 그대로 유지하고 있으며 인덱스도 마찬가지로 별도 파

일로 존재한다. 그렇기 때문에 dBASE나 클리퍼를 사용하던 사람들이 작업하

기에는 좀 나을는지도 모른다.

기본적으로 오라클, 사이베이스, SQL서버, DB2, InterBASE, 인포믹스 등에 대

한 네이티브 SQL링크 드라이버를 제공하며 로컬 DB로는 액세스, 폭스프로, 패

러독스와 비주얼 dBASE에 직접 접근할 수 있다. ODBC는 물론 지원한다.

또한 Business Object Broker라는 툴은 리모트 데이터 브로커, COM 객체,

RPC 서버 등의 모든 객체를 안전하게 관리해주는 것으로 여러 개의 다양한

물리적인 서버에서 같은 객체의 복사본을 실행시킬 수 있도록 한다.

더불어 마이다스(MIDAS)라는 데이터 컨트롤세트가 이번에 컴포넌트 팔레트로

올라갔는데 이 컨트롤들은 Multi-tier 구조를 구성하는데 요구되는 것들이므로

이 주제에서 다루지 않고 C/S를 말할 때 다시 얘기하도록 하겠다.



두 번째 주제 : 개발환경

이 쪽은 MS가 예전부터 신경을 써오던 부분이다. 이제 비주얼스튜디오의 모든

제품에서 지원하는 인텔리센스는 그 중에서도 꽃이라고 할 수 있는 부분으로

개발자 입장에서는 모든 타입과 멤버가 지원되므로 레퍼런스를 찾는 시간을 줄

여주는 대단한 것이다. 또한 VB에서 지원하는 많은 도구들, 다소 효율에는 문

제가 있지만 자동으로 코드를 생성해주는 코드 제너레이터 등 VB는 사용자가

빠르고 쉽게 코드를 작성할 수 있도록 많은 노력을 가하고 있다.

또한 간과하지 못할 부분이 Localization이다. MS는 이제 세계에서 사용되는

모든 MS제품군을 Localize해서 한달 안에 배포하고 있다. 아무리 국제화시대가

되고 영어를 잘한다고 해도 국어만큼 편하게 읽을 수는 없는 일이다. VB는 정

육면체처럼 보이는 패키지 안에 포함된 책의 전부를 한글화했고 도움말 및 메

뉴 등도 전부 한글화되어 있다. 델파이쪽을 보자면 3.0버전부터 비주얼스튜디오

의 직관적인 인터페이스를 많이 따른 흔적이 보이며 델파이의 인텔리센스라고

할 수 있는 Code Complete Wizard 기능도 갖고 있다.

그러나 한글화가 되지 않았다는 점은 역시 상당한 핸디캡이 되며 인터페이스도

비주얼스튜디오보다 덜 직관적이다. 필자의 개인적인 평을 하자면 ‘RAD는 프

로그래밍이 아니다’라고 말하는 프로그래머들이 좋아할 만한, 초보자에게는

다소 혼란스러울 수 있는 인터페이스다.



뛰어난 사용자 환경을 제공하는 VB

VB의 패키지를 구입하게 되면 정육면체의 상자안에 두꺼운 책들이 몇권이나

들어있는데 이 책들은 윈도헬프로 VB안에 고스란히 전자문서화되어 포함되어

있다.

기본적인 도움말은 VB의 헬프에서 찾을 수 있으며 다소 전문적이고 자세한 설

명이 필요하다면 같이 포함된 비주얼베이식 Online Books를 보면 된다. 메뉴얼

이 전부 포함되어 있으니 책 찾는 수고를 덜어서 좋고 하이퍼링크로 참조할 수

있으므로 관련정보도 빠르게 찾을 수 있어서 더욱 좋다. 다만 이번에 문제가

될 수 있는 것은 MSDN을 설치하지 않으면 이 모든 도움말을 사용할 수 없다

는 것이다. 또한 많은 마법사, 템플릿, 기능을 극도로 집약한 컨트롤들, 인텔리

센스, 실시간 에러체킹 등 VB의 사용자 편의환경은 거의 최상급이다.

현재 나와있는 툴들 중에 최고라고 감히 단언할 수 있다. 특히 한줄한줄 코딩

할 때마다 문법을 체크하고 공백을 포함한 표준형의 코딩으로 포맷팅 해주는

기능은 프로젝트에 있어서 시간을 허비하는 요소 중에는 문법에러가 적지 않다

는 점을 감안할 때 대단히 많은 시간을 줄여주는 훌륭한 것이다. VB의 경우는

매번 라인을 입력할 때마다 문법을 체크할 뿐만 아니라 그 라인을 백그라운드

에서 컴파일하고 있으므로 차후 컴파일시 속도향상을 기대할 수 있으며 무엇보

다도 p-Code의 인터프리터방식을 같이 채용하고 있다는 것이 대단한 유연함을

더해준다.

예전부터 VB의 약점으로 지목되어 왔던 p-Code가 장점이 된다는 것은 아이러

니컬한 일인데 실제로 VB에서 프로그래밍을 하게 되면 IDE내부에서 실행한

것, p-Code로 컴파일한 것 그리고 Native Code로 컴파일한 것이 각각 속도가

다르다. IDE에서 p-Code로 실행하는 경우가 가장 속도가 느리지만 이때는 런

타임에서 소스를 바꿀 수 있다는 엄청난 장점이 있고 또한 무한루프로 빠졌을

때 Ctrl+Break로 프로그램을 종료할 수 있다는 이득도 있다.

프로그램을 돌려보고 그 결과에 맞춰 실시간으로 소스를 수정할 수 있다는 것

은 개발과정에서의 시행착오를 상당히 줄일 수 있는 요소이다. 또한 VB에 포

함된 많은 Add-In들은 프로그래머의 일들을 대폭 덜어준다. 애플리케이션 위

저드나 ActiveX Document Migration Wizard는 사용자의 프로젝트를 ActiveX

Document로 바꾸는 것을 아주 쉽게 해준다. 클래스 빌더 유틸리티는 프로젝트

에 포함된 클래스의 멤버를 다루는 작업을 도와준다.

여러 명이 공동으로 프로젝트를 진행하는 경우 버전관리를 위해 포함시키던

Visual Source Safe는 이번에 버전이 6.0으로 올라갔는데 우리나라에서는 여전

히 많이 쓰이지 않는 듯하다. 또 비주얼스튜디오라는 이름으로 여러 개의 툴을

묶어서 통합된 환경을 제공하는데 이 환경에서의 시너지가 상당히 있다.



한글화가 아쉬운 델파이

VB가 현재 RAD 중에서 가장 좋은 사용자환경을 제공한다고 한다면 델파이가

뒤진다고 생각할 수 있는 첫 번째 요건은 한글화이다. 델파이쪽도 도움말을 모

두 헬프파일로 만들어서 포함시키고 있으며 하이퍼링크가 가능하다. 그러나 아

무래도 영어는 한글보다 보기 불편한 법이다.

VB의 인텔리센스와 유사한 Code Complete Wizard라는 기능을 3.0버전부터 지

원하고 있다. 그러나 마법사나 템플릿이 VB보다 부족하고 기능이 미약한 인상

을 준다. NT 서비스 애플리케이션 위저드는 좋지만 VB쪽이 데이터베이스 등

에 대해서 구체적이고 많은 마법사를 지원하며 직접 사용자가 마법사를 만들어

서 사용할 수도 있도록 하고 있는 것에 비하면 다소 부족한 감이 있다. 그러나

One step-CORBA나 One step-ActiveX와 같이 몇 가지 질의에 대답함으로써

원하는 모듈을 만들 수 있는 기능이 강화되었다는 것은 반가운 일이다. 애당초

p-Code를 사용하지 않는 컴파일러 환경만을 제공하며 그렇기 때문에 VB와 같

은 실행중 소스수정은 할 수 없다.

델파이에서는 VB에서 말하는 Add-In의 개념으로 많은 expert를 지원하고 있

다. 또한 버전 관리툴로 PVCS를 제공하고 있는데 이것도 사용은 잘 안 된다.

개발자들이 한번 재고해보아야 할 일이다. 더불어 비주얼스튜디오와 같이 통합

된 환경을 제공하는 골든 게이트 프로젝트라는 것이 있는데 아직 가시적이지는

않다. 이 패키지에는 델파이, C++ 빌더, J 빌더, Web Broker 등의 툴이 포함될

것으로 예정되어 있다. 그러나 골든 게이트 프로젝트 쪽의 툴은 각각의 독립성

이 매우 강하기 때문에 통합된 환경이 제공되어도 어느 정도의 시너지를 보일

지는 미지수이다.





----------------------------------------------------------------------------



천리안 ▶ C프로그램세계PC 출력일 : 2000/05/22

제 목 : [9810]비주얼베이식과델파이-2

----------------------------------------------------------------------------

월 호 : 98년 10월





세 번째 주제 : 개발지원

현재의 상태만을 본다면 이 방면은 VB쪽이 다소 우세하다. 일단 새로운 하드

웨어에 딸려오는 라이브러리의 경우는 윈도용의 C/C++소스를 기본적으로 포함

시키는데 요즈음의 라이브러리에는 C/C++ 소스 외에 VB 소스와 샘플을 추가

시키는 것이 거의 일반화되고 있다. 또한 MS에서의 서비스팩을 통한 지속적인

지원, 세계적으로 300만이 넘는 많은 사용자, 수많은 웹사이트 등 여러 가지 자

원이 아주 풍부하다. 소스도 많이 구할 수 있고 OCX도(어차피 거의 모든

RAD에서 사용할 수 있지만) 널려있다.

델파이쪽은 이런 분야에서 좀 고전을 면치 못하고 있다. 앞서 언급한대로 여러

가지 라이브러리가 C/C++용으로 개발되어 나오므로 델파이에서 사용하려면 한

번 포팅해주지 않으면 안되는데 이것 역시 상당한 일이 된다는 것이다. 물론

델파이를 사랑하는 많은 사람들의 노력으로 DirectX 등 여러가지 라이브러리가

지속적으로 포팅되고 있지만 그 많은 C/C++라이브러리를 전부 이식할 수는 없

는 노릇이다. 이것은 앞으로 델파이의 발전에 상당한 암운을 드리우는 것이다.

외부의 라이브러리를 사용하기 여의치 않다는 것은 앞으로의 자유로운 확장이

쉽지 않다는 의미이기 때문이다.



막강 서드파티 군단을 등에 업은 VB

VB는 일단 MS로부터 직접적인 지원을 받는다. 이 지원은 매년 몇 차례 발송

되는 MSDN 라이브러리에 의해 가시화된다. 이 라이브러리는 몇 GB급의 도움

말, 최신기술, 온갖 소스를 포함한 것이다. 전세계에 300만이 넘는 사용자들이

나름대로 웹사이트를 운영하며 여러 가지 노하우들을 공개하고 있다. 또한 MS

에서 발행하는 단계별 학습물, MCSD를 위한 트레이닝 킷, 그 외 많은 출판사

들이 VB에 관련된 서적을 발행하고 있다. 게다가 전세계의 많은 서드파티들이

VB용의 소스코드 모음집이나 라이브러리를 제공하고 있는 것이다.

이미 OCX개발은 소프트웨어업계에서 하나의 거대시장으로 형성되어 있다. 여

담인데 이상하게 우리 나라에서 VB를 가지고 개발할 때는 VB에 포함된 기본

컨트롤만을 가지고 개발하는 경우가 많고 그 이상의 기능이 요구되면 혼자서

끙끙대다가 VB를 던져버리는 경우가 흔한 것 같다. OCX시장을 둘러보면 원하

는 컨트롤들이 얼마든지 있는데 말이다.

MPEG이나 바코드 등은 아주 흔한 것에 불과하고 DirectX를 지원하는 OCX나

데이터베이스의 내용을 분석해서 그 결과를 웹문서로 돌려주는 OCX, 이미지캡

처 OCX, 플라스틱 OCX, I/O용 OCX등 찾아보면 원하는 기능들은 거의 OCX

로 구현되어 있다. 그렇다고 가격이 비싼 것도 아니다. IMF이후 환율이 많이

올라서 문제가 되기는 하지만 아직도 $5짜리 컨트롤도 더러 있다. 어쨌거나 이

렇듯 MS로부터의 MSDN지원, 수많은 사용자 집단으로부터의 지원, 이들을 겨

냥한 출판사들로부터의 지원, 서드파티 컨트롤 회사로부터의 지원 등, VB가 지

원 받을 수 있는 길은 엄청나다. MS로부터의 공식적인 지원은 MSDN과

MCSD를 공부하는 사람들을 위한 트레이닝 킷 정도가 있을 것이다. 그 외 MS

의 공인교육기관인 ATEC에서 VB에 대한 교육을 받을 수 있고 많은 학원에서

VB를 과목중의 하나로 채택하고 있다.



VB보다 MS에 밀리고 있는 델파이

델파이의 경우는 일단 MSDN처럼 최신기술을 그때그때 받을 수 있는 공식루

트가 없다는 것이 약점이 된다. 또한 사용자층이 VB보다 두텁지 못하며 출판

물도 VB쪽보다 적다. 무엇보다도 델파이의 컴포넌트 라이브러리인 VCL이 사

실상 액티브X 컨트롤에 패배했고 그래서 서드파티로부터 VCL을 지원받지 못

한다는 것이 가장 큰 문제이다. 이것은 앞으로 델파이를 기능확장하는 경우 심

각한 문제가 된다.

그러나 델파이는 OCX를 Import해서 사용할 수 있고, 또한 OCX를 상속하는

것도 가능하므로 현재 시장에 나와있는 OCX를 모두 쓸 수 있다는 점에서 VB

와 동등한 입지를 얻을 수 있다. 게다가 델파이에 대한 정보를 다루고 있는 웹

사이트도 만만치 않게 많다.

또한 델파이의 높은 수행능력과 빠른 개발환경이 점점 인정받고 있는 추세여서

델파이를 주개발도구로 사용하는 업체들도 늘고 있고, 예전에는 VC++나 VB용

의 라이브러리만을 제공하던 하드웨어 벤더들도 델파이용의 소스를 같이 포함

시키고 있다. 아직 VB나 VC++만큼의 활동영역은 얻지 못하고 있지만 서서히

델파이의 입지가 넓어지고 있다는 점은 주목할만하다.

아직 델파이에 대한 공인자격증은 없고, 델파이를 정식으로 공부할 수 있는 곳

도 국내에는 많지 않은데 이것은 MS의 개발도구가 표준이 되어있는 현실때문

일 것이다. 그러나 델파이에 대한 수요도 늘고 있는 추세이므로 앞으로 교육받

을 수 있는 곳이 늘어날 것을 예상한다. 한국 인프라이즈의 홈페이지에 가보면

BorWare Training Center라는 교육장을 운영하고 있는 것을 볼 수 있는데 여

기서 델파이에 대한 공식적인 교육을 받을 수 있고 교육후에 소정의 시험을 거

쳐서 공인증을 수여하고 있다고 한다. 아직 MCP처럼 광범위하고 조직적으로

가동되는 시험제도는 아닌 것으로 생각되지만 델파이쪽에도 공식적인 교육기관

이 생겼다는 것의 의미가 크다.



네 번째 주제 : 퍼포먼스

이상하게도 VB와 델파이를 비교하려면 ‘속도’ 혹은 ‘효율’에 대한 얘기가

전부인 것처럼 된다. VB가 p-Code를 지원하던 시절부터 p-Code이기 때문에

늦다는 편견이 있었지만 실제로는 p-Code가 네이티브 코드에 비해서 그렇게

아주 늦지도 않다. 평균적으로 보면 약 20%정도의 속도저하가 있는 것으로 알

려져 있다(이것은 자바가 느리다는 얘기와 똑같다. 지금의 자바는 JIT컴파일러

를 지원함에도 불구하고 말이다).

VB는 5.0부터 네이티브 코드 컴파일러를 지원하도록 되었고 퍼포먼스에 대한

논쟁은 끝나는가 싶었지만 다시 슬며시 고개를 쳐들기 시작했다. 확실히 VB는

느리다. 이건 인정하지 않으면 안된다. 그러나 이것은 네이티브 코드를 비효율

적으로 컴파일하기 때문이 아니라 각 객체를 결합시키는데 드는 오버헤드가 크

기 때문이다. 또한 이 ‘느리다’는 말에 대해서 우리는 다시 재고해볼 필요가

있다. 자동차는 비행기보다 느리다. 하지만 자동차가 서울시내를 돌아다닐 수

없을 정도로 느리지는 않다. 이것은 리눅스나 솔라리스에 비해서 퍼포먼스가

확실히 낮은 윈도 NT가 어째서 각광받고 있는가와 똑같은 이유인 것이다(어셈

블리는 VB나 델파이보다 몇배 빠르다. 그런데 왜 어셈블리를 사용하지 않을

까?). 즉, VB에서 발생하는 퍼포먼스 저하가 VB의 편리한 인터페이스를 기반

으로 한 유지보수비용 절감으로 상쇄될 수 있다면 VB를 선택할 이유는 충분한

것이다.

대개의 윈도 애플리케이션은 사용자의 입력을 기다렸다가 이벤트로 받아서 프

로그램에 전달하고 실행되는 구조이다. 즉 윈도 애플리케이션을 실행시키는 대

부분의 시간은 사용자의 입력을 기다리는 시간이다. 그럼에도 불구하고 프로그

래머들은 좀더 빠른 컴파일러를 원한다. 일각에서는 빠른 입력을 받아야 하는,

즉 밀리초단위의 작업에는 VB가 부적절하다고 말한다. 그러나 밀리초단위의

리얼타임작업을 원한다면 그건 OS부터가 잘못됐다. 윈도 95나 윈도 NT는 절

대로 리얼타임 OS에 적합하지 않다. 그런 작업을 하려고 한다면 윈도 CE나 자

바 OS를 쓰는 편이 낫다.

반면 델파이는 확실히 퍼포먼스 측면에서 VB나 VC++보다도 우위에 있다. 빠

르게 애플리케이션을 개발할 수 있는 RAD를 이정도로 최적화했다는 것은 대

단한 일이다. 델피언들은 델파이는 VB의 쉬운 사용법과 VC++의 높은 퍼포먼

스를 동시에 추구하는 이원적인 도구라고 얘기를 한다. 즉 VB만큼 쉽고 VC++

만큼 강력하다라고 주장하는 것이다.

그러나 두개의 도구를 모두 사용하는 필자의 입장에서 본다면 그렇지도 않다.

델파이는 VC++나 Symantec C++, 왓콤 C++ 등의 여타 컴파일러에 비하면 대

단히 유연하고 편리한 환경을 제공하고 있다. 그러나 VB와 비교해서도 그만큼

편안한 환경이라고 말할 수 있을까? 필자 입장에서는 아니라고 본다. 이것은

델파이가 아직 RAD로서 무언가 부족해서 그렇다는 것이 아니라 VB가 너무나

편리한 환경을 제공하기 때문에 그런 것이다. 델파이에는 VB가 갖는 백그라운

드 컴파일이 없다. 또한 문법적인 에러를 그때그때 체크해주지도 않는다.

프로그램을 실행하려면 반드시 컴파일을 한번 거쳐야 하며 무한루프에 들어간

프로그램을 중단할 수 있는 방법도 없다. 실시간으로 코드를 수정할 수도 없다.

큰 프로젝트의 경우도 부분 컴파일이 되지 않으므로 전부를 컴파일해서 시간이

많이 걸린다. 즉 델파이는 컴파일러로서 효율을 사용자 편의보다 중시하는 입

장에 있기 때문에 VB보다 높은 효율을 얻을 수 있으며, 여기서는 VB를 쓰는

경우 발생하지 않는 비용이 존재한다. 그리고 ‘효율적인 컴파일러’가 주는

비용절감이 ‘상대적인 사용자 편의의 부재’에서 발생하는 추가비용을 능가할

때 델파이를 사용하는 의미가 있다.



떨어지는 효율성을 사용자 편의로 만회하려는 VB

VB의 경우는 런닝 에디션을 제외하고는 모두 p-Code 혹은 네이티브 코드로

컴파일할 수 있는 옵션이 있다. 앞서 언급한대로 이때 실행을 시켜보면 VB의

통합환경에서 실행하는 것이 제일 느리고 그 다음이 p-Code 그리고 속도에 최

적화된 네이티브 코드가 가장 빠르다. 그러나 정수/실수 연산 등의 단순연산은

느리지 않으며 이 경우 속도를 저하시키는 주범은 폼내의 컨트롤들이다. Paint

나 Redraw 등의 작업이 완전 자동적으로 이루어지는데 여기에 들어가는 오버

헤드가 만만치 않은 것이다. 만약 폼에 많은 컨트롤을 사용하게 되면 그만큼

속도가 저하되며 폼위에 직접 그리게 되면 훨씬 속도가 많이 향상된다.

참고로 백그라운드 컴파일이 항상 이루어지기 때문인지는 정확하지 않지만 VB

의 경우 시스템을 다시 부팅시켜서 만들어진 실행파일이 가장 빠르고 크기도

작은 것으로 알려져 있다. 포인터를 지원하지 않기 때문에 메모리에 대한 직접

적인 접근은 불가능하며 이로 인해 또 다른 속도저하가 생기기도 한다. 주로

DirectX를 사용하는 경우 이런 문제가 많이 발생한다.



월등히 뛰어난 퍼포먼스를 앞세운 델파이

델파이의 경우는 애당초 네이티브 코드를 지원했었고 볼랜드의 축적된 컴파일

러 기술을 사용했기 때문에 퍼포먼스는 VB보다 월등히 뛰어나다. 이것은 VB

가 p-Code이고 델파이는 네이티브 코드여서 그런 것이 아니라 델파이쪽의 코

드 최적화기술이 뛰어나기 때문이다. 실제로 소스를 컴파일해서 만들어진 코드

를 보면 거의 손댈 필요가 없을 정도로 최적화된 것을 볼 수 있다.

델파이는 이런 퍼포먼스의 우위를 바탕으로 해서 많은 사용자를 확보할 수 있

었다. 그 사실은 VB가 네이티브 코드로 전환한 지금도 마찬가지이다. 델파이의

퍼포먼스를 VB와 비교한다는 것은 사실 적합하지 않고 이런 경우 델파이는

VC++이나 왓콤 C++ 등의 윈도 컴파일러와 비교하는 편이 좋다(VB는 사실 컴

파일러로서 대단히 예외적인 경우이다). 델파이는 일단 컴파일된 코드의 최적

화가 좋고 더불어서 컴파일속도가 빠르기 때문에 프로젝트의 진행에 있어서 많

은 이득을 볼 수 있다.

코드의 최적화가 좋다고 하더라도 컴파일에 시간이 많이 걸린다면 소스수정이

잦은 요즈음 별로 환영받지 못할 것이다. 더불어 VB와 비교한다면 포인터를

지원하므로 메모리에 대한 직접 접근이 가능하고 잘 사용되지는 않지만 볼랜드

의 이전 제품들처럼 인라인 어셈블리가 가능하므로 필요한 경우 실행속도를 최

소화할 수 있는 장점이 있다.

===============================================================

C를 원하다

---------------------------------------------------------------

현재 업계에서의 표준은 C/C++이다. 그만큼 많이 사용하고 있기 때문

에

C/C++에는 표준을 담당하는 위원회가 있다. 그리고 이 위원회는 매

년

ANSI-C/C++는 어떠해야 한다는 것에 대한 규약을 내놓는다. 대부분의 컴파일

러 회사들은 이 규약을 지키고 있는 편이고 그래서 유닉스든, 윈도든, 메인프레

임이든 C/C++로 만들어진 코드는 손쉽게 이식이 된다. 또 이것이 C를 사용하

는 중요한 이유중의 하나이다. 그런데 베이식이나 파스칼의 경우는 이런 공식

표준기구가 전혀 없다. 물론 예전에 만들어졌던 베이식과 파스칼의 원형이랄까

그런 것은 있다. 그러나 지금은 전혀 쓰이지 않는 GW-BASIC이나 APPLE

BASIC같은 것의 원형을 따라서 좋을 것은 없고 표준을 설정해줄 기구가 없는

상태에서 MS는 독자적으로 베이식을 확장해서 QBASIC을 만들었다. 어차피

어떤 것이 베이식이라고 말해줄 사람이 하나도 없는 상황에서 MS는 자기 좋

을대로 이렇게 저렇게 확장해서 이전의 베이식과는 아주 다른 것을 만들어내고

말았다. 그리고 그 확장은 계속 되어서, 지금의 VB에까지 이르고 있다. 아직도

베이식에 대한 표준은 없는 상태지만 현재는 VB가 사실상의 표준이다.

물론 인프라이즈도 파스칼에 대한 표준이 전무한 상황이었기에 자신들의 생각

대로 파스칼을 변형해서 오브직트 파스칼이라는 언어를 만들었다. 그리고 파스

칼에 한에서는 델파이만큼 많이 사용되는 툴이 없기 때문에 인프라이즈는 파스

칼계에 있어서 표준이나 다름없는 회사가 되어버렸다. 다시 말하자면 베이식계

에서의 MS의 위치는 파스칼계에 있어서 인프라이즈의 위치와 비슷하다. 이렇

듯 각각의 언어에서 독보적인 위치를 차지한 두 회사는 내심 좋았을 것이다.

일단 표준이 없는 상황이었기 때문에 앞으로도 어떤 제약도 받지 않고 자신들

의 입맞에 맞게 확장을 계속 꾀할 수 있는 것이다. 두 회사의 초창기 전략은

그랬었다. 그러나 업계의 현실을 본다면 큰 프로젝트의 경우는 대개 C나 C++

로 코딩해주길 원한다. 사실 퍼포먼스나 안정성면에서의 차이는 거의 없는데도

불구하고 아무도 자기 회사의 프로젝트를 파스칼이나 베이식으로 코딩하길 원

하지 않는 것이다. 이런 현상은, C/C++가 업계표준이기 때문이기도 하고, 또한

C/C++로 코딩하면 ‘뭔가 있어 보이는’ 이미지 때문이기도 하다.

어쨌거나 고객들이 C계열을 원한다면 모처럼 만들어낸 RAD도 소용이 없다.

즉 MS와 인프라이즈 양쪽은 모두 빠르게 코딩할 수 있는 RAD이면서 업계 표

준인 C/C++ 컴파일러가 필요했다. 그래서 MS는 VC++를 만들었고 인프라이즈

는 C++ 빌더를 만든 것이다(그러나 VC++나 C++ 빌더 모두 표준 C/C++ 규

약에는 맞지 않다. VC++는 MFC를 컴파일하기 위해, C++ 빌더는 RAD툴의 특

성을 얻기 위해 표준에는 없는 수많은 extension을 사용했기 때문에 표준과는

많이 동떨어져 있다. 이것은 인프라이즈가 BC++를 계속 업그레이드하는 이유

와도 관계가 있다. BC++는 현재 윈도에서 거의 유일하게 표준 C/C++ 규약을

지원하는 컴파일러이기 때문이다). 하지만 인프라이즈는 델파이와 같은 환경을

기대하지만 C++를 원하는 사람들을 위해서 C++ 빌더를 만들었고 MS는 VC++

를 VB와는 다른 전략적 차원에서 유지하고 있다는 점이 다르다.

===============================================================



다섯 번째 주제 : 게임/멀티미디어

게임과 멀티미디어도 이제는 빼놓을 수 없는 컴퓨팅의 한 영역이다. 일단 VB

는 MCI나 MCIWndX 등의 컨트롤을 통해서 멀티미디어를 지원하고 있고 이것

은 델파이도 마찬가지이다. 이런 컨트롤들은 간단한 속성을 바꾸는 정도로 윈

도의 강력한 멀티미디어 엔진을 사용할 수 있도록 해준다. 그러나 멀티미디어

관련 프로그래밍을 해본 사람은 알 것이다.

MCI 수준의 간단한 프로그램이 아닌 동영상을 캡처한다든가, 스냅샷을 찍는다

든가하는 작업을 하려면 직접 MCI관련 API에 접근하지 않으면 안 된다. 이런

쪽에서는 델파이가 훨씬 나은 면을 보여준다. 말하자면 VB는 기본적인 멀티미

디어관련 기능들은 가지고 있지만 섬세한 기능은 부족한 편이라는 것이다.

더불어, 게임쪽을 본다면 윈도 게임은 기본적으로 DirectX를 지원해야 한다는

사실을 알 것이다. 물론 지원하지 않고 만들 수도 있지만 속도가 너무 느려져

서 간단한 퍼즐이나 만들 수 있을 정도이다. 그러나 DirectX는 기본적으로

VC++를 기본으로 해서 배포되고 있기 때문에 양쪽 모두 MS로부터의 직접적

인 지원은 받지 못하고 있다(MS는 VB가 DirectX같은 일에는 적합하지 않다고

판단했을 것이다. 이것은 어떤 면에서 잘못 된 생각이다). 그렇기 때문에 VB

사용자들과 델파이 사용자들은 각자 MS에서 배포한 DirectX SDK를 사용하

는 툴에 맞게 포팅해서 쓰고 있다. 델파이 사용자들은 이미 델파이용 DirectX

VCL을 만나봤고 사용해본 독자도 있을 것이다. 이 엔진은 VC++용의 DirectX

를 델파이용으로 훌륭하게 포팅한 것으로 성능도 구성도 좋다. 그러나 VB쪽은

상대적으로 이런 자료가 부족한데, VB자체가 여기에 요구되는 타입라이브러리

(*.tbl)를 만들 수 없다는 약점이 있기 때문이다.



게임과 어울리지 않는 VB

VB를 가지고 윈도용 게임을 만든다는 것은 어딘지 모르게 좀 어색해보일 것이

다. 이것은 VB에 대한 사람들의 편견에 많은 부분 근거한 것이다. VB는 3.0시

절의 벤치마크에서 의사코드이기 때문에 느리다라는 딱지를 얻었다. 그리고 5.0

의 원시코드를 거쳐서 6.0으로 업그레이드된 지금까지도 그런 편견은 없어지지

않고 있다.

또한 MS측에서 윈도용 게임엔진인 DirectX를 내놓았을 때 이것을 전적으로

VC++용으로 내놓았기 때문에 VB쪽은 전혀 지원받을 길이 없었다. 그래서 유

럽쪽에서는 VB로 간간히 게임을 만들고 있기도 하지만, 대개 유아용, 혹은 교

육용의 정적인 게임에 국한되었다. 만약 VB를 가지고 게임을 만들겠다고 한다

면 엄청난 자료빈곤에 시달려야 할 것이다.

반면, VB에서의 멀티미디어구현은 이미 여러 가지 프로그램에 의해서 입증된

바 있다. 칵테일 98도 VB 5.0으로 코딩된 것이며, 외국에서도 많은 타이틀들을

VB로 구현하고 있다. VB는 툴북 같은 타이틀용의 전용도구와는 다른 범용도

구이므로 그렇게까지 많이 쓰이지는 않고 있지만 MCI나 MCIWndX 등 여러

가지 편의한 OCX를 통해서 높은 수준의 타이틀을 아주 쉽게 만들 수 있다. 다

만 일반적이지 않은 멀티미디어 요소들, 말하자면 MPEG을 인코딩한다든가, 플

레이한다든가, 동영상을 캡처한다든가 하는 작업은 VB단독으로는 문제가 있고

API를 통해서 해야 한다.



활발한 움직임을 보이는 델파이

델파이는 그 효율과 높은 수행능력을 인정받고 있으므로 델파이를 사용한 게임

제작 논의도 비교적 활발하게 이루어지고 있다. 다만, MS에서 DirectX를 배포

할 때 VC++에 최적화해서 내놓았으므로 이 라이브러리 SDK의 직접적인 수혜

를 못받는 것은 VB나 델파이나 마찬가지이다. 그러나 후에 설명하겠지만 델파

이는 4.0으로 업그레이드되면서 오브직트 파스칼에 몇가지 확장을 가해서 C++

에서 지원하는 수준의 객체지향성을 갖도록 만들었다. 즉 VC++용의 소스나 라

이브러리의 포팅에는 VB보다 유리한 입장에 있다.

또한 델파이를 사용하는 많은 유저들이 이미 델파이용의 DirectX VCL을 만들

어서 배포하고 있으며 이를 이용한 게임도 계속 선보이고 있다. 이것은 실제로

델파이가 코드를 컴포넌트화하기 쉽고, 또 많이 사용되고 있다는 사실이 장점

이 된 것이다.

델파이의 멀티미디어쪽으로 눈을 돌려보면 이 부분은 VB와 거의 차이는 없다.

기본적으로 포함된 media player 컨트롤을 가지고 속성을 바꾸고, 이벤트 핸들

러를 붙이는 것으로 간단하게 수준높은 타이틀을 제작할 수 있다. 그러나 델파

이는 API수준의 코딩이 직접 가능하고 컨트롤들의 속성도 섬세한 제어가 가능

하기 때문에 VB보다 좀더 API에 근접한 프로그래밍을 할 수 있다.

즉, 다른 라이브러리를 쓰지 않은 상태에서 기본적으로 구현되는 수준이 높다

는 것이다.



여섯 번째 주제 : 클라이언트/서버, 혹은 Multi-tier

트랜잭션 서버의 VB

현재 기업의 컴퓨팅구조는 C/S에서 Multi-tier 구조로 가고 있고 VB도 그를

위한 솔루션을 상당히 제공한다. 그런데 MS는 Multi-tier를 위한 방법은 인트

라넷이 가장 좋은 것이라고 생각하고 있는 듯하다. VB는 DHTML 프로젝트를

통해서 웹상의 동적인 페이지를 만들 수 있고 트랜잭션 서버를 미들웨어로 하

는 n-tier 구조를 만들 수 있다. 또한 이를 위해서 ADO라든가 OLE DB 등 인

터넷에서 사용할 수 있는 솔루션을 패키징하는데 많은 노력을 기울였다.

아무래도 MS는 앞으로 인터넷으로 승부를 걸 모양이다. 델파이가 MIDAS의

여러 가지 컨트롤을 통해서 Multi-tier를 구현하는 것이 주가 되는 한편 VB는

트랜잭션 서버가 미들웨어의 모든 작업을 대행해준다. 어떻게 보면 상당히 편

해진 것이고 어떻게 보면 섬세한 조작이 부족하다. 트랜잭션 서버가 40M도 안

되는 용량을 가지고 있는 것에 비하면 기능은 좋은 편이라고 말할 수 있다. 그

외에 VB로 미들웨어를 제작할 수도 있는데 이런 기술은 VB 사용자로서는 상

당히 테크니컬한 부분에 속한다.



마이다스(MIDAS)의 델파이

델파이는 3.0버전부터 MIDAS라는, Multi-tier구조를 위한 전용 컨트롤들을 가

지고 있었다. 이 컨트롤들을 사용해서 NT에서 서비스를 만들고 여기에 연결하

는 것은 아주 간단하다. 참고로 MIDAS는 그리스에 살았던 사람이름이 아니고

Multi-tier Distributed Application Services의 약자이다.

만약 MIDAS를 사용해서 3-tier구조를 만든다면 서버 사이드의 서비스, 클라이

언트 사이드의 클라이언트 그리고 클라이언트의 요청을 받아서 서버에 접속하

는 서비스 이렇게 세 개의 프로그램을 만들어야 할 것이다. 또한 MTS를 지원

함으로써 VB에서 제공하는 수준의 n-Tier 시스템을 구성할 수 있다. VB가

MTS만을 사용할 수 있는 것에 반해 델파이쪽은 선택의 폭이 좀더 있다고 평

가할 수 있을 것이다. 또한 코바(CORBA)를 지원함으로써 운영체계나 하드웨

어에 종속적이지 않은 컴포넌트를 만들 수 있다.



일곱 번째 주제 : 인터넷/인트라넷

DHTML 프로젝트를 지원하는 VB

VB의 경우는 DHTML 프로젝트도 지원하며 애당초 IE 4.0이나 5.0이 VB 스크

립트를 사용하는 것에서 알 수 있듯이 MS가 거의 여기에 사운을 걸고 있다.

이제 곧 나올 오피스 2000도 HTML기반의 슈트가 될 것이라고 하는데 IE는

유니버셜 컨테이너가 되며 여기에 VBA나 VB 스크립트로 코딩하여 인터넷 혹

은 인트라넷 기반의 애플리케이션을 만들 수 있다. 특히 MS는 코어 부분만을

예전과 같은 방식의 하드코딩으로 처리하고 사용자 인터페이스는 전부 웹기반

으로 추진하려는 움직임을 보이고 있다.

이런 방식으로 만들면 IE를 쓰는 경우에 한해서 인터넷으로 서버에 접속해서

여러가지 서비스를 사용하는 것도 가능하게 된다. 그 외에 Internet

Control(WebBrowser컨트롤이라고 흔히 부르는)이나 Internet

Transfer

Control, Winsock 등 저수준의 컨트롤도 다소 있다. 그러나 VB의 경우 인터넷

서비스의 기반은 IE이며 IE가 대부분의 기능을 모두 처리하고 있기 때문에 섬

세한 조작을 위한 기능은 지원하지 않는다.



더 많은 프로토콜을 지원하는 델파이

델파이의 경우는 VB쪽이 ActiveX Document나 DHTML 프로젝트로 웹을 직

접 지원하는데 반해서 프로젝트 차원에서 직접 지원되는 부분은 없다. 다만 전

통적인 방식의 지원, 즉 ftp나 텔넷을 지원하는 컨트롤 등을 갖고 있는데

NNTP, SMTP, POP3, TCP, UDP와 같이 용도별로 세분화해서 VB보다 훨씬

더 많은 프로토콜을 지원한다. 더불어서, 코바를 통해서 인터넷을 경유한 C/S

혹은 Multi-tier 구조를 구성할 수 있도록 하고 있다. VB의 직관적이고 즉물적

인 지원에 비해서 델파이쪽은 다소 사전지식이 필요하고 테크니컬한 지원을 하

고 있다고 평가된다.



여덟 번째 주제 : 베이식 대 오브직트 파스칼

다들 아는 바와 같이 VB는 베이식 언어를 그 근간으로 하고 있으며 그 뿌리는

MS 도스의 GW-BASIC까지 거슬러 올라간다. GW-BASIC은 초창기 변변한

개발툴이 없을 때 도스에서 사용 가능한 유일한 언어였으며 아직 8비트의 그늘

을 벗어나지 못해 행번호 등이 존재하는 MSX-DOS와 유사한 언어였다.

나중에 컴파일러가 나왔지만 기본적으로는 인터프리터 방식이었고 매우 느렸으

며 구조화되지 않아서 큰 프로젝트를 하기에는 무리가 많이 있었다(지금이야

납득하기 어려운 얘기지만 IBM-PC 초창기에는 GW-BASIC으로 업무용 프로

젝트를 구성하는 일도 종종 있었다). 그러나 BASIC에 남다른 애착을 갖고 있

던 빌 게이츠는 GW-BASIC을 QBASIC이라는 형태로 다시 살려내는데 이

QBASIC이야말로 현재 VB의 언어적 모태가 되는 툴이었다.

Subroutine의 정의에 의한 모듈화 프로그래밍을 도입하고 행번호를 없앴으며

도스 및 바이오스 인터럽트도 사용할 수 있도록 했다. 무엇보다도 중요한 것은

Global과 Local의 개념을 도입함으로써 각 모듈을 캡슐레이션할 수 있도록 했

다는 사실이다.

그에 비해 델파이는 오브직트 파스칼을 뿌리로 삼고 있다. 터보 파스칼로 호황

을 누렸던 볼랜드(현 인프라이즈)의 필립 칸은 한때 TC나 BC++에 주력하기도

했지만 윈도시대로 접어들면서 MS의 공세가 계속되자 예전에 썼던 비장의 카

드인 파스칼을 다시 꺼내서 델파이를 발표하게 됐다. 델파이의 근간인 오브직

트 파스칼은 여러가지로 편리한 언어이다. 파스칼을 공부해본 사람은 알겠지만

그 구조자체가 객체지향에 알맞도록 되어 있고 거기에 오브직트 개념이 들어가

서 많은 모듈을 블럭화해서 나누어 개발하는 것이 가능하도록 되어 있다.

말하자면 언어개념적인 면에서는 델파이가 VB보다 앞서 있다고 평가할 것이

다. 그러나 그런 언어구조적인 우월함이 개발자들에게 큰 장점이 될 수 없는

것이 현재 윈도에서는 C/C++가 표준적인 개발도구로 되어 있기 때문이다. 물

론 VB도 C라이브러리의 직접적인 혜택을 받을 수 없는 위치에 있지만 MS는

VB에 대한 엄청난 물량지원과 업계에 대한 영향력 행사로 VB를 사실상 윈도

에서의 업계표준으로 만드는데 성공했다. 그렇기 때문에 요즈음은 특정한 라이

브러리를 발표할 때 윈도용 C/C++ 라이브러리와 함께 VB용의 라이브러리를

같이 배포하는 것이 일반적인 추세로 되어있다(DirectX처럼 VB의 특성에 다소

부조화하는 라이브러리의 경우는 예외인데 이 얘기는 차후에 또 할 기회가 있

을 것이다). 델파이가 VB에 대해서 언어적인 우월성을 획득하고도 다소 고전

을 면치 못하는 것은 이런 이유가 있는 것이다.



언어적인 측면의 한계를 느끼는 VB

VB는 4.0버전부터 언어적인 측면에서는 거의 변화가 없는데 사실상 구조면에

서 가할 수 있는 변화는 그 정도에 거의 완결되었기 때문이다. 클래스의 도입

이나, 상속, 캡슐레이션 등 다만 아쉬운 것은 델파이처럼 지속적으로 객체지향

성을 강구하는 모습을 보여줬으면 하는 바램이다.

VB라는 도구 자체가 액티브X를 충실하게 구현하고 있고 액티브X는 전체의

수정이 아닌 컴포넌트의 수정으로 업그레이드를 해나가는 방식을 취하고 있기

때문에 변화가 상대적으로 적게 된다. 다시 말하자면 VB는 컴포넌트를 연결하

는 도구의 역할을 충실히 하고 있고 그렇기 때문에 액티브X가 업그레이드되기

전에는 VB의 언어적인 측면에서 많은 변화의 소지는 없을 것으로 예상된다.



언어 개념적인 측면에서 앞서는 델파이

델파이는 이번에 오브직트 파스칼에 몇 가지 특성이 추가되었다. 먼저 동적배

열이 사용가능하게 되었다는 점이 고무적이며 개방형 배열인자(Variant)를 사

용하여 모든 배열을 하나의 기본형으로 처리할 수 있게 되었다.

또한 동적배열은 다차원으로 확장될 수 있다. 덧붙여 앞서 설명했던 OOP측면

에서의 확장, 즉 메소드 오버로딩, 일반 함수와 프로시저 오버로딩, 디폴트 인

자 사용 등이 가능해졌다. 변수타입에는 64비트 정수와 32비트 unsigned

Integer인 Long Word도 새롭게 더해졌다. Real타입은 48비트 floating point에

서 64비트의 Double로 변환되었다. 델파이에 이런 객체지향적 특성이 마무리된

것은 중요한 의미를 갖는데 바로 업계 표준인 C++의 클래스를 가능한한 적게

수정해서 이식할 수 있게 되었다는 것이다.

VB의 경우는 C++의 객체지향적 특성중 지원하지 않는 것이 상당히 있기 때문

에 C++ 소스를 이식할 때 난감해지는 경우가 상당히 있었고 델파이의 경우도

마찬가지였다.



아홉 번째 주제 : 컴포넌트 라이브러리

모두 아는 것처럼 VB의 컴포넌트웨어는 액티브X 컨트롤이고 델파이의 컴포넌

트웨어는 VCL이다. 물론 델파이가 액티브X 컨트롤을 지원하기는 하지만 이것

은 업계표준으로 된 규격이므로 지원하는 것이며 액티브X라면 누가 뭐라고 해

도 VB쪽이 원조이다.

VB쪽의 컴포넌트인 액티브X는 MS의 SDK 공급과 VC++, VB 등에서의 컨트

롤 제작기능 추가로 인하여 현재 매달 엄청난 양의 컴포넌트가 개발되고 있다.

전세계적으로 3만개 이상의 서드파티가 액티브X를 조달하고 있으며, 앞으로도

이 수는 더 늘어날 전망이다.

델파이쪽의 컴포넌트인 VCL은 그에 비해 다소 조용한 편이다. VCL은 델파이

1.0때와 비교해서도 별로 스펙이 변화하지 않았고 액티브X처럼 혁신적인 기능

변화도 없다. 또한 서드파티에서도 델파이쪽에서만 사용가능한 컴포넌트

인

VCL은 별로 인기가 없기 때문에 만들지 않고 있다. 그러나 델파이 사용자가

자신의 라이브러리를 정리하려고 한다면 VCL은 아주 효율적인 방법이 될 수

있다.



액티브X의 VB

VB는 이것이 참 곤란한 점 중의 하나인데 사실은 만들어진 컴포넌트를 재사용

할 수 있는 방법이 상당히 부족하다. 물론 VB에서도 액티브X DLL이나 액티브

X 컨트롤같은 형식으로 바이너리 수준의 컴포넌트를 재사용할 수 있는 길이

열려있다. 그러나 이 컨트롤이나 DLL을 만드는 과정이 생각 외로 복잡하고 제

대로 쓰려면 많은 것을 생각하고 만들어야 하는 것이다(사실 잘 아는 사람이

생각보다 그렇게 많지 않다).

액티브X용의 컴포넌트를 만들려면 클래스가 필히 추가되어야 하며 클래스의

속성과 메소드, 그리고 이벤트로 모든 것을 처리하지 않으면 안 된다. 그러나

VB의 클래스는 객체지향이 완벽하게 지원되지 않는 특이한 형태이며 그런 이

유로 많이 사용되지 않고, 따라서 코드의 컴포넌트화도 잘 이루어지지 않는다.

Quick-Basic에서는 쉽게 라이브러리를 만들 수 있었기 때문에 많은 코드가 공

유되었지만 VB에서는 함수타입의 라이브러리를 지원하지 않고 객체타입의 라

이브러리만을 만들 수 있기 때문에 코드의 라이브러리화가 잘 이루어지지 않고

있다. 이것은 VB에서 객체를 다루기가 어렵기 때문인데 객체가 아닌 일반 코

드를 라이브러리화할 수 있도록 해주면 좋겠다는 생각이 든다. 그러나 그러려

면 새로운 타입의 유닛구조를 만들지 않으면 안 될 것이고 MS는 차라리 현재

처럼 액티브X 컴포넌트를 같이 사용하기를 바랄 것이다. 어쨌거나 그런 이유로

VB에서 코드를 공유하는 방법은 소스차원에서 합쳐버리는 경우가 많은 것이

다.





----------------------------------------------------------------------------



천리안 ▶ C프로그램세계PC 출력일 : 2000/05/22

제 목 : [9810]비주얼베이식과델파이-3

----------------------------------------------------------------------------

월 호 : 98년 10월







VCL의 델파이

델파이는 DSU라는 형태로 바이너리 유닛을 지원하며 또한 VCL의 형태로 컴

포넌트를 패키징할 수 있다. 만들어진 프로그램을 유닛형태로 바꾸어서 사용할

수 있으며 컴포넌트화도 어렵지 않다. 이렇게 컴포넌트화가 쉽다보니 많은 유

닛들이 DSU혹은 VCL형태로 만들어져서 공유되게 되었다. 물론 이것은 델파

이가 MS에서 지정한 윈도용의 공식 컴포넌트 규약인 COM을 따르지 않고 자

사의 고유형태인 VCL을 고집한 덕이다. 또한 액티브X 컨트롤을 Import할 수

있고 상속도 받아서 자신이 원하는 형태의 컨트롤을 제작할 수 있다. 아쉬운

것은 DBGrid나 FlexGrid, 그 막강한 Apex의 TrueGrid 등 JET 엔진에 연결되

는 바운드 컨트롤들은 Import해도 사용할 수 없다는 것이다.

비주얼스튜디오 VS 골든게이트 프로젝트

MSDN이라든가, 비주얼스튜디오의 이해할 수 없는 가격정책은 MS가 VB 아닌

비주얼스튜디오를 구입하도록 종용하고 있다는 것을 확실히 하고 있다. 이런

사실은 MS의 무슨 생각을 보여주는 것일까? 필자의 생각은 VB만으로는 윈도

용의 애플리케이션을 개발하는 것이 충분하지 않다라고 MS가 결론을 내렸다

는 것이다. VB는 대단히 훌륭한 툴이다.

일단 RAD라는 개념을 윈도에 처음 도입한 것이 VB였고 그 혁신적인 액티브X

에 의해 기능을 확장해나가는 방식이라든가, 인텔리센스 등은 대단히 생산성을

높여주는 훌륭한 것이다. 원시코드를 지원하게 되어서 퍼포먼스 측면에서도 할

말이 생겼다. 그러나 VB가 가장 중점을 둔 것은 사용자편의이다. 비슷한 코드

를 작성하더라도 델파이나 C++ 빌더 등 여타 RAD들과 비교할 때 지극히 빠

른 시간에 안정된 코드를 만들 수 있다. 또한 도구내에 포함된 여러 가지 마법

사나 자동화도구들도 다른 RAD에서는 찾아보기 힘든 것들이다. 그러나 이렇게

사용자 편의에 신경을 쓰다보니 간단한 작업 하나 하는데도 많은 내부적 절차

를 거쳐야 하고 그래서 퍼포먼스측면에서 다소 희생이 생긴다. 그렇기 때문에

매우 빠른 실행이나 밀리초 단위의 리얼타임을 요구하는 작업에는 어느 정도

맞지 않는다는 인상을 준다. 이런 경우에 사용되는 것이 바로 VC++이다.

또한, VB는 DHTML 프로젝트를 지원함으로써 웹상에서의 코딩도 가능하다.

IIS용 프로젝트를 선택하면 ASP 서비스도 만들 수 있다. 그러나 VB는 웹전용

의 도구가 아니기 때문에 때로는 웹상에서의 구현에 한계를 보일 수 있다.

이런 경우에는 VJ++가 컴포넌트를 만들어준다. 이렇듯, 비주얼스튜디오는 하나

만으로는 충분히 그 전력이 나오지 않는다. VB를 전위로 하고 VC++가 컴포넌

트를 만들며 VJ++가 웹상에서의 코딩을 담당하고 비주얼 폭스프로가 데이터베

이스를 맡는 ‘독수리 오형제’식의 분담이 바로 비주얼스튜디오의 스타일인

것이다.

이에 반해서 골든 게이트 프로젝트는 각각의 툴들이 모두 비슷한 형태를 띠고

있다. 델파이는 VB를 겨냥한 RAD툴이었지만 VC++의 높은 수행능력도 더불

어 가진 훌륭한 툴이다. 또 C++ 빌더는 어떤가. 이것은 델파이가 오브직트 파

스칼로 한 것을 C++로 옮겨 놓은 것이라고 말하면 정확하다.

또한 J 빌더는 델파이와 완전히 똑같은 인터페이스를 갖는 자바 개발툴이라고

말하면 모든 설명이 된다. 다시 말하면 골든 게이트 프로젝트에 포함된 개발도

구들은 하나같이 독립적으로 사용할 수 있는 완성도가 높은 것이며 인터페이스

도 동일하고 문제는 단지 사용자가 어떤 환경에서 작업하고 있으며 어떤 개발

언어를 선호하는가 뿐이다. 그러나 각개의 툴이 모두 자신의 독립적인 완결성

을 갖고 있기 때문에 여러 개의 툴을 같이 사용해도 시너지는 미미하다.

결국, 비주얼스튜디오는 각각 다른 역할을 하는 여러 개의 툴들을 하나로 묶음

으로써 막대한 시너지를 꾀한 것이며 골든게이트 프로젝트는 시너지는 없지만

비슷한 역할을 하는, 언어가 다른 동일한 툴들의 묶음인 것이다. 이런 상황이니

까 MS가 비주얼스튜디오를 한꾸러미로 해서 판매하는 것도 이해가 간다는 것

이다.

또한 MS의 이러한 전략은 현재 한가지 분야만 잘하는 전문가를 원하지 않는

컴퓨터 업계의 실태와도 관련이 있다. 즉 컴퓨터 업계는 RAD가 갖는 빠른 개

발속도와 C++가 갖는 높은 수행능력 그리고 웹과의 연계, 데이터베이스 관련

기능 등을 모두 갖춘 인력을 요구한다(점점 밥먹기 힘들다). MS는 이 모든 툴

들을 전부 익히기를 바라고 있다. 더 정확히 말하면 VB와 VC++를 같이 사용

하기를 권고한다는 것이다. MCSD, 즉 MS공인개발자 자격시험에 비주얼스튜

디오의 제품들 중 VB와 VC++ 트랙만이 포함되어 있다는 사실이 이를 뒷받침

한다. 즉, MS에서 인정하는 이정도면 개발자다라고 생각할 수 있는 프로그래

머는 VB와 VC++양자를 모두 습득해야 하는 사람인 것이다.



열 번째 주제 : 액티브X 지원

액티브X의 효시가 되었던 것이 VB였음을 감안할 때 놀랍게도 이 부분은 델파

이가 VB보다 앞서 있다. 모두들 알듯이, 액티브X의 근간이 되는 것은 COM이

기 때문에 COM을 얼마나 잘 지원하는가가 액티브X와의 궁합에 중요한 요소

가 된다. VB에서는 하나의 클래스가 하나의 COM객체에 해당하며 또한 COM

객체에 대한 타입라이브러리를 만들면 COM 객체를 하나의 클래스로 간주해서

동일한 방식으로 사용할 수 있다. 그리고 인터페이스 상속, 그로 인한 다형성의

구현, 캡슐화 등 여러 가지 특성이 COM객체와 정확하게 일치한다.

그러나 델파이는 이 모든 것을 지원하면서 VB보다 한술 더 뜬다. 일단 COM

객체를 소스레벨에서 상속해서 사용할 수 있다는 큰 장점을 가지고 있으며 현

재 나와 있는 모든 종류의 툴 중에 유일하게 ‘Interface’타입을 지원하고 있

다는 것이다. Interface 객체를 갖는다는 사실은 대단히 중요한 의미가 있다. 이

는 단지 객체에서 기본적으로 만들어지는 인터페이스를 사용할 수 있는 것뿐만

아니라 사용자가 필요한 형태의 인터페이스를 만들고 조작할 수 있다는 사실을

의미하기 때문이다(레퍼런스 카운팅도 볼 수 있다).

COM에 대한 이해가 있는 사람은 델파이가 지원하는 Interface 객체를 사용해

서 대단히 여러 가지 유연한 작업을 할 수 있다. 델파이는 이러한 COM관련

확장을 3.0버전부터 제공하고 있다. 아예 언어적인 측면에서 COM을 지원하도

록 확장해버린 것이다.



열한번째 주제 : 어디서 사용할 수 있는가?

MS의 목표는 윈도 제품군을 세계 표준으로 만드는 것이지만 그것은 단지 인

텔 기반의 PC에서 운영되는 윈도 95나 98을 의미하는 것은 아니다. MS는 PC

나 NC 그리고 더 나아가서는 IA까지 모든 제품을 윈도 라인으로 장악하고 서

로간의 데이터 호환이나 애플리케이션 호환을 지원하도록 하려고 계획하고 있

다. 특히 윈도 CE로 대표되는 앞으로의 IA시장은 그 잠재력에서 현재의 PC시

장을 크게 추월할 것으로 기대되고 있으므로 MS도 이쪽을 계속 주목하고 있

다.

그런 이유로 해서 VB는 여러개 플랫폼(모두 윈도 계열이지만)에서 운영되어야

한다. 현재 VB는 윈도 95와 윈도 98 그리고 인텔계열 윈도 NT 4.0과 알파기

반의 윈도 NT 4.0에서 사용할 수 있으며 향후 전략적인 제휴를 할 것으로 예

상되는 파워맥에의 포팅이 기대된다. MS는 또한 윈도 CE를 위해서 VB용의

툴킷을 따로 제공하고 있다. 이 툴킷은 각 기종에 따른 에뮬레이터와 크로스컴

파일러로 이루어져 있는데 에뮬레이터에서 테스트해보고 이것을 랜이나 시리얼

을 통해 윈도 CE에 다운로드할 수 있도록 되어 있다. 또한 VB는 VBA라는 서

브셋 형태로 오피스 제품군에 포함되며 IIS에서는 VBS라는 형태로 사용할 수

있다. VB는 이제 대단히 넓은 업무영역을 얻은 셈이다.

그런 것에 비해 델파이는 아직 인텔 기반의 윈도 95, 98 그리고 윈도 NT에 머

물러 있다. 델파이 유저들로서는 움직일 수 있는 영역이 상당히 좁은 셈인데

그런 단점을 MTS나 코바지원으로 커버하고 있다. 코바를 지원함으로써 델파

이는 언어나 OS에 관계없이 사용할 수 있는 컴포넌트를 만들 수 있는 것이다.

더불어 IBM AS/400용의 Delphi/400을 출시함으로써 좀더 작업영역이 넓어졌

다.



윈도 CE용 개발도구로써 VB

일단 VB는 윈도라는 운영체계에 묶여있는 입장이지만 현재 윈도 패밀리가 컴

퓨팅의 전영역으로 확산되고 있는 추세이므로 이를 간과해서는 안된다. MS는

모빌 컴퓨팅용으로 윈도 CE 2.0 그리고 서브 노트북용으로 윈도 CE 3.0을, 개

인사용자에게는 윈도 95나 윈도 98을, 개발자들에게는 윈도 NT 워크스테이션

을, 서버나 메인프레임용으로는 윈도 NT 서버를 포함하는 폭넓은 라인업을 구

축하고 있다. 그리고 VB는 이 모든 패밀리에서 사용할 수 있는 범용도구가 된

다.

특히 윈도 CE는 앞으로 PDA와 경량 노트를 상당부분 대체할 것으로 보이며,

더욱 중요한 것은 윈도 CE는 임베디드 시스템에 사용하는 리얼타임 OS라는

것이다. 윈도 CE를 단순히 PDA나 서브노트용의 Thin OS로 생각하는 경우가

많은데 필자는 윈도 CE의 진짜 가치는 정말 가벼워야하는 IA(인터넷 가전)의

운영체계로 사용될 때 드러난다고 생각하고 있다.

이 경우 윈도 CE용으로 사용 가능한 개발도구는 VC++ For WinCE, VB For

WinCE, VJ++ For WinCE의 세 가지 뿐이다. 그러나 윈도 CE는 완전한 32비

트 운영체계이기 때문에 API를 사용한 프로그래밍에서는 제한을 많이 받게 된

다(작동하지 않는 API가 상당히 존재한다

조형익 wrote:

> 저희 회사에 맞는 4GL언어를 선택할려고 하는데

> 어떤언어를 선택해야 할지 모르겟네요..

>

> Delphi/ Visual Basic/ Power Builder 제품간의 비교자료나,

> 장단점을 기록한 자료나, 사용경험이 있으신 분이나

> 많은 정보를 부탁드립니다.

>



아래 글은 델파이코리아의 권용길님의 글입니다.

참고하세요.



장단점을 모두 나열하긴 어렵지만 간략히 기술해보겠습니다.



파워빌더는 데이터베이스를 설계하는 기능이 뛰어나고

응용프로그램과 DB를 유기적으로 관리합니다. 단점은

성능면에서 있어 델파이보다 많게는 20배 이상 느리다는 겁니다.

많은 분들이 성능때문에 파워빌더에서 델파이나 비주얼베이식으로

툴을 바꾸고 있습니다.



비주얼베이식과 델파이 모두 데이터베이스 기능을 지원하

상대적으로 빠른 프로그램을 생성합니다. 물론 성능면에서

델파이가 한 수 위입니다. 또 파워빌더와 비교해서

보다 다양한 분야와 종류의 컴포넌트를 지원합니다.



비주얼베이식은 개발사가 아무래도 OS와 각종 산업표준을

생산하는 회사이기 때문에 각종 최신 기술을 발빠르게 수용하는

장점을 가지고 있습니다. 그리고, 한글 지원(개발환경, 도움말..)

문제에 있어서도 세 툴 중 가장 뛰어납니다.



델파이는 다른 툴처럼 스크립트 원의 언어를 뛰어넘는

진정한 언어를 가지고 있는 컴파일러입니다. 언어가

가장 객체 지향적이며 제공되는 라이브러리(VCL)도 체계적으로

짜여져있다고 정평이 나있습니다. 그리고, 멀티티어(마이다스),

CORBA, ORACLE8 의 지원면에 있어 세 툴중 가장 뛰어납니다.



제한이 있지만 세 툴 모두 윈도우 API를 호출할 수 있기

때문에 만들 수 있는 프로그램의 범위는 같다고 봐도 됩니다.

심지어 VC++과 BC++빌더 와도 같지요.



참고로 마이크로소프트웨어 11월호에 특집으로

이 세툴에 대한 벤치마크가 있을 예정입니다.

객관적으로 다룬다고 하니 도움이 될겁니다.



위의 견해는 순전히 저의 개인적인 생각입니다.

혹 이견이 있거나 추가 보충해야할 생각이 있으시면

이 쓰레드 아래에 글을 올려주시면 감사히 읽겠습니다.