[연재] [프로그램세계] -VBX 죽이기

[타이거팀]

 

1. VBX 해킹기법

2. VBX 죽이기

3. VB로 만드는 쉐어웨어

---

 

이글은 월간 프로그램세계 96년도 6월호를 통해 발표한 글입니다.  

분명히 말씀드리지만 저작권의 보호를 받으므로 다른 서적등에 무단전재를 금합니다.

VBX 죽이기

플러그-인 아키텍처에 대해서

윈도 3.1의 아키텍처는 플러그-인 (Plug-In) 방식을 가진 운영체제라고 할 수 있다. OS 사용자마다 각기 바라는 모든 기능을 운영체제가 전부 지원해 주기는 어려울 것이다. 네트워크 기능만을 주로 사용하기도 하고, 프로그래밍 리소스를 충분히 공급해 주길 바라는 사용자도 있을 수 있고, 멀티미디어 지원을 바라기도 한다.

각양각색의 요구에 대해 윈도 3.1은 시스템 운영을 위한 최소의 기능만을 인스톨하고, 사용자가 나중에 더 끼워 넣길 바란다. 넷스케이프 네비게이터의 플러그-인으로 유명한 '쇼크웨이브'나 'RealAudio'같은 소프트웨어도 마찬가지라고 하겠다.

윈도 3.1을 처음 설치하면 AVI 디지털 비디오나 음악 CD를 재생할 수 있는 멀티미디어 파트가 설치되지 않는다. 플러그 & 플레이가 지원되지 않기 때문에 "멀티미디어-PC"라는 걸 OS가 모르기 때문인데, 사용자는 불편하지만 소프트웨어들을 따로 인스톨하고, IRQ나 DMA채널 등을 셋업해주어야만 한다.

AVI라는 디지털 비디오를 제어하기 위해서는 비디오 포 윈도즈 (이하 VFW) 1.1을 제어기 형태로 설치해야 하고, VFW에 포함된 비디오 코덱이 압축된 AVI 비디오 파일의 비디오 스트림을 풀어서 재생시킨다.

디지털 비디오의 재생은 MSVIDEO.DLL이나 AVICAP.DLL등의 여러 VFW 런타임 파일들의 도움을 필요로 한다. 일단 윈도 3.1에 VFW를 추가해 주기만 하면 디지털 비디오 재생을 VFW가 대신 맡아서 하게 된다.

디지털 비디오가 더 이상 필요 없다면 윈도 3.1에서 VFW를 삭제해 버리면 그만이다.

레고블럭 같은 컴포넌트웨어

오늘날의 소프트웨어는 자꾸 덩치가 커져 쓸데없는 기능을 만드는데 개발 인력이 낭비되고 있고, 사용자들은 필요하지도 않고, 잘 사용하지도 않는 기능에 돈을 내야 한다. 이러한 상황을 슬기롭게 헤쳐 나가기 위해 객체 지향 프로그래밍이 나타났다.

특정한 기능을 수행할 수 있는 단위별 프로그램 모듈을 클래스라는 덩어리로 묶고, 재사용이 가능하게 만들어 유지 보수가 쉽도록 만들었다는 것인데, 이제는 이 클래스와 함수 덩어리들을 사용자에게 상품으로 팔기 위해 어느 정도 적당한 크기를 가지면서 다른 프로그램 모듈에 대해 표준화된 인터페이스를 지원하도록 하는 VBX란 아키텍처 구조로 개발자의 프로그램에 플러그-인 방식으로 끼워 넣을 수 있도록 만들어냈다.

컴포넌트웨어는 아마도 '프로그래밍'이라는 단어 자체에 'Assembling like Lego' (레고처럼 조립하는) 이라는 사전적 의미를 추가시킬지도 모른다. 프로그래밍의 개념 자체를 뒤집어 놓을 수 있는 컴포넌트웨어는 이미 VBX가 화려한 성공을 거두었고, OCX같은 새로운 컴포넌트웨어를 향해 가고 있다.

소프트웨어가 차라리 건축이라면 중간에 짓던 건물에 마음대로 설계 변경을 하진 않을 것이다. 하지만 프로젝트의 진행 도중에 계획이 바뀌면 모든 기초를 허물고, 새로 시작해야만 한다.

컴포넌트웨어 프로그래밍에서는 기초를 허물지 않고도 VBX나 OCX를 통해 새로운 기능을 개발자의 프로젝트에 바로 덧붙일 수 있게 해주지만, 반대로 사용 중이던 특정 VBX나 OCX가 필요 없다고 판단되면 과감하게 죽여(?) 버릴 수도 있다.

비주얼 베이식(이하 비베)에서는 그 컴포넌트와 관련된 소스 코드에 단지 작은따옴표 하나를 붙여 주면 주석문으로 바뀌어 버린다. 요즘 같은 컴퓨팅 파워가 높은 시대에 빠른 속도를 위한 코드 최적화를 시켰다거나 밤새도록 코딩해 만든 것도 아니라서 개발자에게는 VBX에 대한 애착 같은 것은 전혀 없다. 불행하게도 달면 삼키고 쓰면 뱉는 그런 법칙이 적용된다.

지금까지 독자들은 한결같이 비베에 대해선 '코드의 재사용성과 확장성을 제공해 SW 개발자의 편의를 덜고...' 라든지 '각 기능별로 개발할 수 있어 효율적인...' 등의 이야기만 들어서 VBX 환상에 젖어 있을 수도 있다. 유명한 테크니컬 라이터들의 분석 기사를 맹신하는 독자도 상당수 있을 것이고, VBX를 깔아뭉개고 있는 필자의 독설에 분통이 터진다는 긍지 있는 VB 개발자도 있을 것이다.

필자는 VBX를 즐겨 쓰지만 필자의 시각에서 VBX는 단지 프로젝트의 소모품에 불과하며, 약점 투성이다. 필자는 VBX에 대한 단점을 하나하나 지적하면서 새로운 OCX 컨트롤에 대해서도 함께 이야기하려고 한다.

VBX 죽이기

VBX는 미완성의 객체 지향적 패러다임을 채택했다. VBX는 비교적 사용이 간편하다는 것과 시간이 절약된다는 점을 빼고는 그리 나아 보일 것이 없다.

VBX는 객체 지향적인 면보다는 쉽게 붙여 넣을 수 있는 컴포넌트임을 더 강조한다.

개인적인 의견이지만 코드의 재사용성만 해도 VBX보다 컴파일러에 포함된 클래스 라이브러리가 훨씬 더 나을 것이다. 객체를 담을 수 있는 능력이 전혀 없어 OLE와는 전혀 관련이 없어 보인다.

확장성이라는 문제도 VBX가 가지는 한계를 노출시키는데, 직접 만들어 낸 커스텀 컨트롤이 아니기 때문에 서드파티 개발사가 그 VBX 컨트롤을 버전업하기 전에는 기능을 향상시킬 수도 없다.

개발자가 MFC클래스처럼 VBX의 기능중 필요한 80%만 상속받고, 20%는 직접 추가하고 싶다고 해도 그런 일은 불가능하다. 윈도에서 사용하는 기존 표준 컨트롤의 기능을 상속받을 수 있는 서브클래싱 (Subclassing)이란 방법이 있기는 하지만 VBX 컨트롤을 개발할 때뿐이지, VBX를 사용하는 프로그래밍 파트에 통용되는 개념은 아니다.

위와 같은 이유로 OLE 2.0에 따라 새로 디자인된 객체 모델인 OCX 아키텍처가 나오지 않았을 까라는 의문이 들지 않는지?

실제로 그렇다. VBX는 16비트 플랫폼에 종속적으로 얽매여 있어 윈도 95나 윈도 NT같은 32비트 플랫폼으로 이식하는 것조차 어려우며, 윈도 95상에서 동작하는 비주얼 베이식 4.0에서는 VBX의 로드조차 불가능하다. 인텔 프로세서가 아닌 RISC CPU인 Alpha나 MIPS 머신 등에서도 결코 동작할 수 없다고 한다.

그렇다면 모든 면에서 비교하여 잘난 것하나 없는 VBX가 성공할 수 있었던 이유는 무엇일까?

우선 서드파티 개발사의 제품들이 비베의 뒤를 받쳐 준 덕분인데, 수백 가지 유틸리티들의 기능들이 VBX라는 커스텀 컨트롤로 캡슐화되었기 때문이다.

MS-엑셀 같은 스프레드시트를 C나 C++로 구현하려면 많은 시간과 소스 코딩이 필요할 것이다. 하지만 단지 마우스로 클릭하기만하면 엑셀의 인터페이스를 가지는 어플리케이션을 덧붙일 수 있다는 것은 제한된 시간에 쫓기는 개발자들에게 이브의 사과처럼 매우 달콤한 유혹이 아닐 수 없다.

개발하는 어플리케이션에 매끄럽게 덧붙일 수 있는 바이너리 오브젝트 코드로 공급되었다는 점도 중요하다. 즉, 개발사의 소스를 보호하면서도 특정 프로그래밍 언어에 얽매이지 않기 때문에 볼랜드 델파이, 비주얼 C++, 비주얼 폭스 프로 같은 여러 개발툴이 바이너리 오브젝트 코드를 지원해 주었고, 그만큼 사용자 층도 확산되었다.

OCX 아키텍처

윈도 3.1의 DLL에서 출발한 커스텀 컨트롤 구조에 다른 프로그램 모듈에 대해 표준화된 인터페이스가 덧붙여진 것이 VBX라면, 새로운 OLE 컨트롤은 VBX 아키텍처의 단점을 넘어서기 위해 VBX 구조를 과감히 버리고, OLE / COM의 객체 모델에 맞추어 새로 디자인되었다.

마이크로소프트와 DEC가 CORBA 표준에 대응해 만들어낸 OLE기반의 객체 COM모델을 Component Object Model 또는 Common Object Model이라고도 한다.

32비트 윈도 95상에서 동작하는 비주얼 베이식 4.0에 VBX가 로드되지 않는 이유도 새로 디자인된 COM 모델을 따르기 때문이다. OLE 컨트롤은 이벤트와 메소드, 프로퍼티를 통해 OLE 컨테이너와 통신할 수 있는 메커니즘이 있어 (OLE의 객체 통신인 LRPC 통신 방법이 아니다) OLE 컨테이너가 OLE 컨트롤을 제어할 수 있다.

프로퍼티 파트도 좀더 자세히 들어가면 Ambient, Standard, Extended, Custom처럼 네 가지 프로퍼티로 나눌 수 있는데, Ambient와 Extended는 OLE 컨테이너가 OLE 컨트롤을 제어하기 위해 설정하며, Custom과 Standard는 OLE 컨트롤이 사용한다.

Ambient는 컨트롤이 객체를 내장한 컨테이너의 정보를 얻기 위해 사용하는 프로퍼티로 이미 정의된 값만을 사용하고, 개발자가 따로 정의한 값을 쓸 수 없다.

Standard 프로퍼티는 컨트롤마다 공통적인 .ForeColor나 .Caption, .Enabled 속성들이며, Custom 컨트롤은 개발자가 컨트롤에 추가한 .LeftMargin 같은 추가 속성이다.

커스텀 속성은 OLE 컨테이너 개발자들이 사용할 수 있도록 문서화를 시켜주어야할 것이다.

VBX는 컨테이너에 의해 단지 프로퍼티만이 설정될 수 있었지만, OLE 컨트롤은 OLE 컨테이너에게 공개되는 몇 개의 커스텀 메소드를 가지게 되었고, 메소드는 OLE 컨테이너로부터 호출될 수도 있다. OLE 컨트롤은 C/C++ 컴파일러를 사용하는 개발자들도 RISC 머신인 MIPS에서 동작하는 32비트 컨트롤을 사용하고자 하는 요구를 하도록 만들었으며, 비베 개발자들도 32 비트의 플랫폼에서 무한한 자유를 보장하는 OCX라는 컨트롤로 VBX를 완전 대체할 수 있게 되었다.

'MS 워드'를 제외하고 'MS 액셀', 'MS 프로젝트'같은 OLE 컨테이너들도 VBA(Visual Basic for Application)이라는 매크로 언어를 통해 커스텀 컨트롤을 제어할 수 있다.

하지만 비베에서 VBX나 OCX를 쓴다고 해도 실제로는 소스 코딩이 많이 필요하다. 비베가 마치 '오소웨어' 저작 도구처럼 마우스로 끌어당겨 놓기만 하면 동작한다는 위험한(?) 상상은 버려야 한다. VBX나 OCX는 단지 비베의 일부일 뿐 나머지는 개발자의 몫이다.

VBX의 문제점중 또 하나는 개발자가 개발 도구를 사용하면서 창의성을 잃게 되는 경우가 있다. 시간에 쫓기다 보면 나중에는 코딩보다는 VBX를 사서 끼워 넣으려는 의식이 팽배해진다. 필자도 프로그래밍으로 구현할 수 있는 문제가 귀찮아서 비슷한 기능의 VBX를 이용하려고 하는 경향이 짙어진 것같다.

실제 예를 하나 들자면 상용 VBX중에는 THREED.VBX를 개발한 Sheridan사의 '디자이너 위젯'이라는 패키지가 있다. 'Dockable ToolBar', 윈도 테두리 바꾸기, 캡션바의 크기와 위치 조정을 하는 C 코드를 VBX로 캡슐화시켜두고, 프로퍼티 조정만 하면 사용자 마음대로 커스터마이징 할 수 있는 편리함을 제공한다.

하지만 자세히 뜯어보면 윈도 스타일에 관련된 여러 개의 Windows API를 섞어서 프로그래밍한 것에 불과하기 때문에 두툼한 Windows API Bible과 Windows API Programming만 습득한다면 비베 API 프로그래밍으로도 어느 정도 구현이 가능하다.

화면에 생성된 윈도에서 캡션바를 드래그했을 때 HTCAPTION이란 리턴 값과 그 윈도의 핸들이 윈도 3.1로 보내지게 된다. 그러면 윈도 3.1은 사용자가 어떤 윈도의 캡션바를 누른 채 움직이는 것이라고 생각해 파라미터로 넘어온 마우스의 위치를 새로운 윈도 포지션으로 생각하고, 윈도를 옮긴다. 비베에서는 이런 시나리오를 프로그래밍으로 그대로 적용할 수 있다.

비베 3.0에 포함된 컨트롤 가운데 픽처박스 컨트롤을 생각해 보자. 픽처박스 컨트롤은 캡션바가 없다. 즉, 윈도에 움직이는 속성이 없다. 윈도 스타일도 Sizable할 수 없고, 스크롤바는 아예 생각도 못한다.

그러나, .hWnd 프로퍼티를 가지고 있기 때문에 분명 하나의 윈도임에는 틀림없다. 종류에 상관없이 하나의 윈도라면 윈도 스타일을 적용해 줄 수 있기 때문에 픽처박스도 그대로 변신을 한다. 윈도즈라는이름(수많은 윈도들)이 왜 붙여졌는지 이해할 수 있을 것 같다.

[표 1]의 VB코드는 비베의 픽처박스에 WS_THICKFRAME 스타일을 추가하는 코드이다. 필요한 스타일을 Or로 여러개 연결해 주면 그 윈도의 스타일로 적용된다.

 

''' VB\WINAPI\WINNAPI.TXT에서 나타나는 윈도 필드 오프셋으로 아래의 API

''' GetWindowLong()와 GetWindowWord() 에서 사용된다.

Global Const GWL_STYLE = (-16)

'''필요한 WS_ 스타일 정의

Global Const WS_THICKFRAME = &H40000&

Global Const WS_VSCROLL = &H200000&

Global Const WS_HSCROLL = &H100000&

Sub Form_Load()

Dim Ret As Long

'' 픽처박스의 윈도 스타일을 얻는다. Windows 95에서는 GWL_STYLE 선언에 관한

'' 내용이 바뀌었으므로 VB 4.0으로 프로그래밍할 때는 반드시 레퍼런스 매뉴얼을

'' 참조한다.

Ret = GetWindowLong(picture1.hWnd, GWL_STYLE)

'' THICKFRAME 으로 픽처박스의 윈도 스타일을 바꾼다.

Ret = Ret& Or WS_THICKFRAME

Ret = SetWindowLong(picture1.hWnd, GWL_STYLE, Ret&)

end Sub

OCX 라이선스 문제 ?

자신의 프로젝트에 상용 VBX를 사용하게 되면 사용한 VBX가 많은 만큼 얻는 효과도 크겠지만 더불어 라이선스 비용 문제가 얽혀 들어간다.

지난호 'VBX 해킹 기법'에도 몇 가지 VBX 라이선스 파일에 관한 것을 살펴보았지만, OLE 컨트롤의 경우엔 VBX와 다른 라이선스 방법이 필요하다.

보통 VBX 라이선스는 보통 1카피당 1대씩의 데스크톱 PC에 인스톨하도록 규정하고 있다. 하지만 'Q+E ODBC 엔진'이라는 VBX는 약간 다르다. Q+E는 저렴한 가격으로 MS사의 ODBC 드라이버가 지원하지 못하는 인포믹스, IBM DB/2, WatcomSQL 등의 여러 데이터베이스 Back-End에 접속할 수 있는 기능을 제공하는 패키지인데, 개발 업체가 Q+E를 사용했을 때, 개발 중에는 모르던 라이선스 문제가 납품 직전에 구체화되고 만다.

만일 Q+E로 개발한 응용 소프트웨어를 클라이언트/서버 환경에서 사용하려고 하는데 클라이언트 1대당 1카피씩 Q+E 런타임 버전을 설치해야 한다는 계약 조건이 있다면 어떨까?

서버에는 데이터베이스와 DBMS가 있을 것이고, 클라이언트에는 Q+E 응용 프로그램과 런타임을 설치해야 한다. 즉, 수십 개의 클라이언트용 런타임 버전을 따로 구입해야 하는 추가 부담이 생겨 배보다 배꼽이 커지는 격이 될 수도 있다.

Q+E 런타임 엔진을 구입하느니 차라리 ODBC 접속용 SW를 개발하는데 투자하는 편이 훨씬 나았을 것이다. LIC 파일이 딸려 있는 VBX 패키지가 거의 이런 식이므로 라이선스 문제를 유통사에 확실히 물어 보고 구입하여야 할 것이다.

그럼 OCX 라이선스는 어떨까? 객체 지향적인 컴포넌트웨어의 시대에 어플리케이션에 분산되어지는 OLE 컨트롤들이 다른 어플리케이션에 재사용되는 것을지극히 당연한 일이므로 막을 방법이 없다.

개발자들은 상용 OLE 컨트롤을 디자인 타임에서만 사용할 수 있도록 고심해야 했는데, VBX에서 사용하던 라이선스 방법에 여러 가지를 더 확장했다고 생각할 수 있다.

 

  typedef struct licinfo

  {

    long cbLicInfo;

    bool fRuntimeKeyAvail;

    bool fLicVerified;

  }LICINFO;

VBX에서는 윈도의 특정 디렉토리에 라이선스 파일이 있을 경우만 메모리에 VBX 컨트롤의 인스턴스를 생성해 냈는데, OLE 컨트롤의 경우도 인스턴스를 생성할 때 IFactory 인터페이스의 확장인 IFactory2::GetLicInfo()를 사용해 라이선스 파일의 유무를 묻는 방법을 쓴다.

IFactory2의 메소드는 3가지로 GetLicInfo()와 RequestLicKey(), CreateInstanceLic()이다.

OLE 컨트롤을 OLE 컨테이너에 로드하려고 할 때는 GetLicInfo() 메소드가 컨트롤과 관련된 라이선스 파일이 존재하는지 찾는다. 컨트롤의 인스턴스가 만들어지면 OLE 컨트롤을 포함한 OLE 컨테이너가 OLE 컨트롤에 대해서 Unique한 라이선스 키를 요구하기 위해 RequestLicKey() 메소드를 호출한다.

OLE 컨테이너는 넘어온 라이선스 키값을 저장해 둔다. 어플리케이션은 OLE 컨트롤을 포함한 채 배포되더라도 라이선스 파일이 없다면 인스탄스가 생성되지 않아 디자인 타임에서 사용은 불가능하다.

런타임에도 OLE 컨테이너에 저장된 Unique한 키값을 CreateInstanceLic()에서 파라미터로 해서 OLE 컨트롤에 넘겨준다. 만약 요구하는 라이선스 키값과 틀린다면 그 컨트롤을 사용할 수 있는 방법은 없어진다.

또다른 응용법은 평가 버전과 프로 버전이 하나의 컨트롤에 들어 있지만, 두 개의 라이선스 파일로 풀리도록 만들어져 있어 평가 버전일 경우 사용할 수 있는 메소드나 프로퍼티를 제한시킬 수 있다. 프로용 라이선스로 바꾸어 주면 OLE 컨트롤을 즉시 프로 버전으로 업그레이드한다.

OLE 컨트롤 개발방법

비주얼 C++ 4.0에서는 OLE 컨트롤의 CDK를 포함하고 있기 때문에 마우스로 클릭해주는 것만으로도 비주얼하게 OLE 컨트롤을 개발할 수도 있고, VB 프로젝트에 직접 사용할 수도 있다.

비주얼 C++ 2.0에서는 개발할 수는 있었지만 VBX 컨트롤을 이용할 수 없었던 점에 비해 큰 도약이라 하겠다.

새로운 32비트 플랫폼과 32비트 OLE 컨트롤 컨테이너의 등장은 VBX의 단점을 넘어서서 OLE 2.0을 통합하는 새로운 OLE 컨트롤로 가려는 길을 닦아주었지만, OCX는 기존의 많은 VBX를 쓸모없게 만들 수 있다는 문제점을 내포하고 있었기 때문에 기존의 서드파티사들 가운데 OCX를 거부하는 움직임이 있었던 것은 사실이다. OCX는 서드파티 개발사들이 OLE 2.0 표준을 선택한다는 것과 같은 맥락에서 이해될 수 있으며, 선택한 OLE 표준에 대한 계속적인 지원과 보장이 필요했다.

마이크로소프트사는 이러한 문제점을 해소하기 위해 비주얼 C++의 ControlWizard에서 VBX를 OCX로 간단히 포팅할 수 있는 VBX Template을 제공한다. VBX Template는 기존 VBX의 모델 구조체를 사용해 OCX의 기본 구조를 위한 프로토타입 소스 코드를 생성해준다. 그 다음은 VBX의 소스 코드를 OCX 코드의 적당한 위치로 옮기면 되는 것이다.

OCX는 아마도 차세대 운영체제 카이로의 일부로 포함될 것으로 기대되고 있다. 마이크로소프트사의 비주얼 C++ 4.0을 비롯한 비주얼 베이식 4.0등의 개발도구도 확실하게 지원해주며, 서드파티사는 기존 VBX 제품을 대신한 OCX 컨트롤이라는 새로운 시장을 가지게 되었다.

개발한 OLE 컨트롤을 컴파일한 후에는 비주얼 베이식 4.0같은 OCX를 시험해 볼 OLE 컨테이너가 필요하다. 비주얼 C++의 Tools 메뉴의 'Test Container'를 이용할 수도 있다.

'테스트 컨테이너'에 의해 사용되기 전에 먼저 Tools 메뉴의 'Register Control'에서 시스템 레지스트리에 OCX를 등록해야 한다. REGSVR32.EXE라는 유틸리티는 DLLRegister()함수를 호출하여 [그림 7]처럼 OCX를 시스템 레지스트리에 등록해준다.

테스트 컨테이너의 'Insert OLE Control' 대화상자에서 우리가 제작한 OLE 컨트롤이나 시스템 레지스트리에 이미 등록되어있는 OLE 컨트롤들을 실험해 볼 수 있다. [그림 8]은 필자가 윈도 95의 버튼을 상속받아 만든 버튼 객체를 등록시켜 테스트하고 있는 화면이다.

상속이란 개념은 리스트 컨트롤이나 버튼같은 기존의 윈도 컨트롤을 상속받아 여기에 기능을 확장하는 것이다. 버튼 객체를 상속받으면 기존의 윈도 95 버튼 클래스를 상속받는 것이므로 매우 비슷하게 작동한다. 개발자는 필요한 이벤트와 프로퍼티를 입맛대로 골라 추가해 줄 수 있다.

비주얼 C++ 4.0에서는 컴포넌트 갤러리에 OLE 컨트롤을 등록시켜 두었다가 (시스템 레지스트리에 등록되어 있는) 자신의 프로젝트에서 원하는 컨트롤을 불러서 사용하면 된다. 선택한 OLE 컨트롤 클래스에 대한 코드가 자동 생성되고, 애플리케이션 스튜디오의 다이얼로그 박스 에디터의 팔레트에 OLE 컨트롤이 자동 추가된다. 다이얼로그 에디터에서는 컨트롤의 인스탄스를 생성시켜 개발자가 Property를 지정해주면 된다.

NICHE Market

세계는 우루과이 라운드에서 정보 라운드로 이어지면서 급속도로 변하고 있는데, 국내시장은 한정된 몇 가지 품목에 대한 업체들간의 과열 경쟁으로 10여개 이상의 워드프로세서가 난무하고 있는 실정이다.

상업성을 가지지 못하는 VBX의 개발에 투자하려는 기업은 전혀 없다. 외국의 VBX 서드파티 개발사가 많은 이유도 역시 마이크로소프트라는 공룡의 물량 공세에 밀려서 워드부터 운영체제까지 어디 한군데 파고들 시장이 없었기 때문이다.

뭔가 경쟁력 있는 제품은 몇몇 공룡 기업에서 M&A(기업 인수 및 합병)라는 이름으로 꿀꺽 집어삼켜 버린다. IBM과 로터스 합병, 어도비사의 앨더스 합병, 타임워너와 CNN-터너방송사의 인수, 월트디즈니가 캐피털 씨티즈 및 ABC 방송사를 잇달아 인수하는 일이 1995년 한 해동안 벌어졌다.

M&A를 통한 합병은 멀티미디어 개발 경쟁에서 한발이라도 우위를 차지하기 위한 발빠른 포석으로 덩치가 큰 초국가적 기업을 만들어 엔터테인먼트와 컴퓨터 업계를 지배하려는 야심을 그대로 표현해 준다. 규모의 경쟁 시대인 21세기는 큰돈 깔아 놓고 그물로 훑는 덩치 싸움에서 판가름이 나고 만다.

우리의 소프트웨어 전략은 어떤가? 지금까지 '한글'이라는 언어의 특수성 덕분에 계속 버텨 왔던 중소 개발사들에게 한글 코드는 더 이상 바람막이 역할을 할 수가 없을 것이다.

인터넷에 올려진 한글 윈도우용 어플리케이션은 글자가 깨져서 나오고, IME를 사용하기라도 하면 프로그램은 아예 동작하지 않는다. 세계로 뻗어나가야할 한국 SW시장에 '한글'이라는 특수성이 도리어 발목을 잡는 요소로 작용하고 있다.

'한메한글 for 윈도 95'는 영문 윈도 95와 한글 윈도 95가 나오는 시기적인 니치 마켓 (Niche Market: 틈새 시장)을 노린 제품이다,. 실리콘 밸리의 한 대만 기업이 만든 '파워 온 디맨드' 칩은 '에너지 스타' 규격보다 작은 저전력이란 틈새를 노려서 성공한 제품이다.

이제 우리나라 소프트웨어 업계가 가야할 길은 두가지 중의 하나이다. OCX처럼 틈새 마켓을 노려 공략하든지 아니면 이제부터라도 꾸준히 OS나 DATABASE 같은 기초기반 기술에 투자할 때라고 생각하지 않는가.

---