[연재] [마소][최승락] VB4를 파헤친다 - 3회 객체와 OLE 오토메이션 서버 만들기

[타이거팀]

본 연재의 1회와 2회에서 끊임없이 나오는 단어가 있다. 바로 '객체'라는 단어이다. 이번 연재에서도 제목에 객체라는 단어가 들어간다. 그 만큼 객체 지향은 컴퓨팅 환경에 크나큰 영향을 주었고 앞으로도 계속 그러할 것이다.

지금까지 우리가 언급한 객체는 주로 프로그램의 개발과 관련된 컴포넌트 혹은 언어 자체에서 지원하는 라이브러리 형태의 객체와 관련되었다. 무슨 말씀인고 하니, 객체 자체가 홀로 독립적으로 실행될 수 있는 단일 프로그램은 아니었고 프로그램을 만들기 위한 재료로써 그 자체로는 별 의미가 없었다. 이제 우리가 언급하려고 하는 객체는 이와는 조금 틀리다. 그 자체가 하나의 프로그램일 수도 있다.

비베 3.0에서 이미 엑셀이나 워드를 객체로 사용해 본 경험이 있는 독자가 있을 것이다. 액셀이나 워드처럼 독립된 프로그램도 OLE 기술중의 하나인 OLE 오토메이션(automation)을 통해 다른 프로그램을 위한 객체로 사용될 수 있다. 이제 비베 4.0에서는 객체를 쓰는 것에 덧붙여 액셀이나 워드와 같은 OLE 오토메이션 서버 즉 OLE 객체(이 연재에서 OLE 오토메이션 서버, OLE 객체, OLE 서버는 모두 같은 의미를 가진 단어들이다.)을 아주 간단하게 만들 수 있게 되었다.

사실 OLE 오토메이션은 프로그램간의 데이터 교류에 대한 또 하나의 메카니즘이라고 볼 수 있다. 초창기의 윈도우즈는 클립보드를 통해 프로그램간에 데이터를 교류하였다. 그 후 윈도우즈 3.0부터는 프로그램간의 통신(IPC: InterProcess Communication)은 주로 DDE(Dynamic Data Exchange)에 의존했었다. 하지만 이제는 OLE 오토메이션이 그 대를 이을 것이다. 그러면 DDE와 OLE 오토메이션의 차이점은 무엇인가? DDE의 중점이 이름에서도 나타나듯이 데이터(data)였다면 OLE 오토메이션이 중점으로 두는 것은 바로 객체이다. 아마 이렇게 말해도 피부로 와 닿지 않는 독자가 있을 것이다. OLE 오토메이션에 익숙하지 않은 독자를 위해서 한 가지 예를 보이겠다.

엑셀의 데이터 파일인 '추천사양.xls'의 첫 번째 열의 첫 번째 행에 있는 값을 메시지 박스로 보여주려 한다면 다음과 같이 코딩할 수 있다.

Dim objExcel As Object

Set objExcel = CreateObject("Excel.Application")

objExcel.Workbooks.Open ("E:\Doc\Sale\추천사양.xls")

MsgBox objExcel.Worksheets(1).Cells(1, 1).Value

위의 코드의 두 번째 열을 보면 엑셀을 objExcel 변수에 객체로써 대입하고 있다. 일단 이렇게 객체가 얻어지면 그 다음부터는 엑셀이 OLE 오토메이션을 통해 개방한 여러 객체를 보통 다른 비베내의 객체처럼 프라퍼티와 메쏘드로 마음껏 조작이 가능하다. 이처럼 OLE 오토메이션은 비베 프로그램머에게 친숙한 메쏘드와 프라퍼티를 통해 객체 지향 풍으로 유연한 데이터 교환과 서버 프로그램의 자유로운 제어를 통한 새로운 IPC 메카니즘을 제공한다.

이러한 액셀과 같이 다른 프로그램에 개방될 수 있는 OLE 오토메이션 서버를 비베 4.0에서 만들어 낼 수 있다. OLE 오토메이션은 하나의 기계에 국한되지 않는다. 비베 4.0 엔터프라이즈 버전에서는 네트워크로 맞물린 서로 다른 컴퓨터간에 있는 어플리케이션간에 통신할 수 있는 원격(remote) OLE 오토메이션 서버를 만들 수 있다. 이러한 원격 OLE 오토메이션은 three-tier 클라이언트/서버나 비동기적 처리(asynchronous processing)등을 위해 사용될 수 있다. 결국 각각의 컴포넌트는 네트워크상의 어느 곳에나 분산되어 서로가 물릴 수 있는 분산 환경을 제공한다.

비베에서 만들어진 OLE 서버는 비베에서만 사용될 수 있는 것은 아니다. VBA을 언어 엔진으로 탑재하고 있는 엑셀이나 억세스 그 외에 OLE 오토메이션을 사용할 수 있는 모든 개발 툴에서 비베에서 만들어진 OLE 서버를 사용할 수 있다.

필자는 시외전화를 위한 지역 번호 검색 객체를 만들고자 한다. 이러한 OLE 서버를 만들어 두면 쓰일 때가 많을 것이다. 사용자가 지역만 입력하면 지역 번호를 자동으로 검출해 낼 수 있을 테니 말이다. 이 예를 통해 OLE 서버가 만들어지는 과정을 살펴보도록 하자.

OLE 오토메이션 서버를 정의하자

앞에서 언급했듯이 OLE 서버는 객체로써 인지된다. 비베에서 외부로 개방되는 객체를 만들기 위해서는 이전 연재에서 설명했듯이 클래스 모듈(class module)을 사용해야 한다. 지역 번호 검출에 대한 클래스 모듈의 정의는 매우 간단하다. 지역 이름을 받아서 그에 해당하는 지역 코드를 반환하는 게 전부다. 이는 메쏘드로 처리하면 된다. 지역 코드에 대한 데이터베이스는 실상은 데이터베이스 엔진을 사용해야 하겠지만 여기서는 간단하게 콜렉션으로 처리하겠다. 콜렉션은 이름에 의한 원소 접근이 가능함을 이전 회에서 설명하였다. 따라서 키값으로 지역 이름을 주고 데이터로 지역 코드를 줘서 콜렉션에 추가 하면 그만이다.

먼저 Insert|Class Module 메뉴를 선택하여 클래스 모듈을 프로젝트에 추가한다. 다음, 지금 만들려고 하는 OLE 서버는 폼이 필요 없으니까 기본으로 추가되어 있던 폼 모듈을 제거한다. 그 다음 콜렉션을 선언하기 위한 다음의 코드를 클래스의 General 부분에 삽입한다.

Dim m_LocalCodes As New Collection

필자는 모듈 레벨 변수 앞에 m_을 접두어로 붙인다. MFC을 보고 본 딴 것이다. 사실 프로그래밍할 때 짜증나는 작업 중에 하나가 변수나 프로시져 이름 정하는 작업이다. 어떤 이름이 이 변수를 위해 적합할까? 하고 고민하다 보면 시간이 금방금방 흐를 때가 부지기수다. 여하튼 변수 이름 앞에 변수의 타입이나 스코프(scope)를 암시하는 접두어를 붙이는 것은 매우 바람직하다. 이에 대해 공통적으로 널리 쓰이는 규약이 있다면 이를 따르는 게 좋다.

그 다음에 해야 할 일은 콜렉션에 데이터를 등록시키는 일인데 객체가 생성될 때 Class_Initialize가 호출되므로 이 프로시져에 다음의 코드를 넣으면 되겠다.

m_LocalCodes.Add Item:="02", Key:="서울"

m_LocalCodes.Add Item:="051", Key:="부산"

m_LocalCodes.Add Item:="053", Key:="대구"

m_LocalCodes.Add Item:="032", Key:="인천"

m_LocalCodes.Add Item:="062", Key:="광주"

m_LocalCodes.Add Item:="042", Key:="대전"

m_LocalCodes.Add Item:="0522", Key:="울산"

실제로는 더 많은 지역 번호가 있지만 예제일 뿐이니 몇 개정도, 광역시들과 몇 년안에 광역시가 될 필자의 거주지도 넣었다. 이제 검색을 위한 메쏘드를 정의해야 할 차례이다. 인자로 지역명을 받고 반환 값으로 지역코드를 넘겨주는 메쏘드면 완벽하다. 콜렉션에서 검색은 콜렉션의 item 메쏘드를 사용하므로 다음의 코드로 그러한 작업을 해 낼 수 있다.

Public Function GetCode(Area As String)

GetCode = m_LocalCodes.Item(Area)

End Function

필자는 식별자의 이름 정하는 것이 짜증나는 작업 중에 하나라고 했는데 이러한 작업에는 또 하나가 더 있다. 바로 에러 처리하는 루틴이다. 에러만 나지 않으면 별 필요 없는 부분인데 그래도 넣어주어야 하는 부분이다. 특히 비베의 에러 처리는 goto 문에 의존해서 깔끔하지 못하다. C++처럼 예외처리(exception handling) 기능이 있으면 얼마나 좋을까 하는 생각이 든다. 비베의 에러처리 기능을 핑계로 필자가 위의 메쏘드에서 에러처리 기능을 넣지 않은 점을 널리 양해해 주기 바란다. 사실 하나의 프로그램이 아닌 여러 OLE 객체가 모인 경우에는 에러처리는 좀 더 신중을 기해야 한다. 즉 에러를 어디에서 발생하게 할 것인가를 결정하는 문제이다. 이에 대해서는 on-line book에서 'Error Handling with OLE Automation Objects' 토픽을 보면 자세히 잘 설명하고 있다.

서버를 위한 준비

클래스 모듈에는 다음 세 가지의 속성(property)이 있다. 이 중 두 가지 Public과 Instancing을 주목해야 한다. Public 속성은 클래스 모듈의 객체를 프로젝트 안에서만 접근할 것인지 아니면 OLE 오토메이션을 통해 다른 어플리케이션에서의 접근도 허락할 것인지를 결정한다. 만약 Public의 값이 False이면 다른 어플리케이션에서 클래스 모듈의 객체에 접근할 수 없다.

Instancing은 세 가지 값을 가진다. 0(Not Creatable)이면 다른 어플리케이션은 이미 존재하는 클래스의 인스턴스에 대해서만 접근할 수 있다. 1(Creatable SingleUse)이면 각각의 인스턴스에 대해 별도의 OLE 서버가 실행된다. 따라서 클라이언트의 요청에 보다 능동적으로 대응할 수 있다. 대신에 다수의 OLE 서버가 필요하므로 시스템 자원을 보다 많이 소비하는 단점이 있다. 이에 비해 2(Creatable MultiUse)이면 여러 개의 인스턴스가 있을지라도 오직 한 개의 OLE 서버만이 실행된다. 이 하나의 OLE 서버가 여러 클라이언트로부터의 요청을 차례대로 처리하게 된다. 따라서 여러 요청이 동시에 들어올 경우 Creatable SingleUse에 비해 즉각적이 대응이 어렵다. 이런 경우 쓰레드(thread)의 사용은 좋은 해결책인데 아직까지 비베는 쓰레드를 지원하지 않는다. 하지만 오직 하나의 OLE 서버가 메모리에 존재하므로 시스템 자원을 절약할 수 있다. 이러한 모든 Instancing의 설정은 Public이 True일 때만 그 의미를 가진다.

Name 속성은 클라이언트 어플리케이션에서 인스턴스를 선언할 때 사용되는 이름이다.

<그림 1> 클래스 모듈의 속성

다음에 프로젝트에 대한 설정이 필요하다. Tools|Options 메뉴에서 Project 탭을 선택하면 <그림 2>의 대화상자가 나온다.

<그림 2> OLE 서버를 위한 프로젝트 옵션 설정

폼이 없으므로 Start Form에는 아마도 Sub Main만 나올 것인데 이는 OLE 서버가 시작될 때 처음으로 실행되는 코드가 삽입될 프로시져이다. Sub Main은 클래스 모듈에 정의할 수 없으므로 일반 모듈을 하나 만들어서 Sub Main 프로시져를 정의해야 한다. 이 프로시져에 코드가 삽입될 필요가 없더라도 비베의 인터프리터는 OLE 서버가 처음 실행될 때 이 프로시져를 찾으므로 아무 코드가 없는 Sub Main이라도 반드시 정의되어 있어야 한다.

Project Name에는 서버의 이름을 적어주면 되는데 이 이름은 클라이언트 어플리케이션에서 다음과 같이 인스턴스를 생성할 때 필요하다.

Dim objTELLocalCodes As Object

Set objTELLocalCodes = CreateObject ("TELServer.LocalCodeClass")

CreateObject의 인자 문자열중 LocalCodeClass는 클래스 모듈의 Name 속성에서 정의된 이름이다.

StartMode에서는 지금 만들고 있는 것이 OLE 서버이므로 OLE Server를 선택하면 된다. Application Description에는 OLE 서버의 설명을 간단히 적는다. 이곳의 문장은 뒤에서 설명될 References 대화상자에서 우리의 OLE 서버를 설명하기 위해 나타나게 될 것이다.

OLE 서버의 사용

만들어진 OLE 서버를 이제 사용해 보자. 비베의 개발환경은 3.0과는 달리 4.0에서는 여러 개의 인스턴스가 실행될 수 있다. 따라서 OLE 서버를 디버깅할 때 하나의 비베에는 OLE 서버를 실행시키고 다른 비베에는 클라이언트 어플리케이션을 개발하면서 OLE 서버를 디버깅할 수 있다. OLE 서버를 실행시키고 또 다른 비베를 실행시키자. 새로 실행시킨 비베에서 Tools|References 메뉴를 선택하면 <그림 3>의 대화상자가 열린다.

<그림 3> References 대화상자

프로젝트 탭의 Application Description에서 설명된 우리의 OLE 서버가 리스트에 등장하는 것을 볼 수 있다. 당당하게 이 서버를 선택하자. 이러한 References 대화상자는 비베뿐만이 아니라 VBA을 지원하는 엑셀이나 억세스에서도 볼 수 있다. 앞에서도 언급했듯이 비베에서 만들어진 OLE 서버는 OLE 오토메이션을 지원하는 모든 개발 툴에서 사용할 수 있다. 개발 툴에 제한을 받지 않는 OLE 서버는 매우 큰 장점이 아닐 수 없다.

References 대화상자에서 일단 선택을 했다면 Object Browser 대화상자를 열었을 때 선택된 OLE 서버가 나타날 것이다. Object Browser(<그림 4>)는 View|Object Browser 메뉴를 선택하면 열린다.

<그림 4> Object Browser 대화상자

Object Browser는 사용할 수 있는 여러 객체에 대한 메쏘드와 속성을 알려준다.

이제 본격적인 코딩 작업에 들어갈 순서이다. 다음의 예는 OLE 서버의 객체를 선언하고 객체의 GetCode 메쏘드를 통해 서울의 지역 번호를 얻어온다.

Dim objTELLocalCodes As Object

Set objTELLocalCodes = CreateObject("TELServer.LocalCodeClass")

MsgBox objTELLocalCodes.GetCode("서울")

<그림 5> 비주얼베이직에서 OLE 서버의 사용

위의 코드에 대해서는 별다른 설명이 필요 없을 것이다. 처음에 서버의 인스턴스를 만들기 위해 CreateObject라는 함수를 사용하고, 이렇게 해서 일단 객체가 만들어지면 그 다음부터는 서버에서 정의된 메쏘드와 속성을 사용하여 사용하면 된다.

앞에서도 언급했듯이 OLE 서버는 비베에서만 사용할 수 있는 것이 아니다. <그림 6>은 엑셀에서 OLE 서버를 사용하는 상황을 보여 준다.

<그림 6> 엑셀에서 OLE 서버의 사용

In-Process vs. Out-of-Process

OLE 서버에 대한 정의와 디버깅 작업이 끝났다면 이제는 비베가 없어도 실행될 수 있도록 파일을 만들어 내야 한다. 그런데 비베 4.0에서 독립된 파일을 만들려고 보니 EXE를 만드는 메뉴, OLE DLL을 만드는 메뉴 두 가지가 보인다. OLE 서버이니 OLE DLL을 만들어야 하는가? 그렇지만은 않다. EXE로 만들면 out-of-process 서버가 만들어지고, OLE DLL로 만들면 in-process 서버가 만들어진다. 그럼 out-of-process 서버는 무엇이고, in-process 서버는 무엇인가? <표 1>을 참조하기 바란다.

<표 1> In-Process vs. Out-of-Process

In-Process	Out-of-Process
DLL 확장자를 가진다.	EXE 확장자를 가진다.
호출 프로세스와 동일한 메모리 영역에 상주하다.	호출 프로세스와 다른 메모리 영역에 상주하다.
32bit에서만 사용가능	16bit와 32bit사이에 연결 가능
정형(model) 대화상자를 통해서만 화면에 나타난다.	화면 출력에 대한 제한이 없다
원격(remote)으로 실행될 수 없다.	원격 OLE 오토메이션을 사용할 수 있다.
통신이 매우 빠르다.	통신이 상대적으로 느리다.

근본적인 차이는 메모리의 구성에서 온다. 사실 in-process 서버는 DLL이다. 다른 점이라면 직접적으로 함수를 호출하지 않고 OLE 오토메이션을 사용한다는 사실이다. 그러하기 때문에 in-process 서버는 별도의 메모리 영역을 가지지 못한다. 즉 호출자의 메모리 공간을 공유한다. 따라서 도저히 호출 프로세스와 다른 컴퓨터에 있을 수가 없다. in-process는 비정형(modeless) 대화상자를 사용할 수 없다. 이러한 제한 때문에 한 가지 주의해야 할 점이 있다. 무엇인가 하면, 처음으로 시작되는 폼은 비정형이기 때문이기 때문에 앞에서 언급된 프로젝트 탭에서 Start Form을 Sub Main으로 지정하여 비정형 폼이 열리지 못하게 해야 한다. 호출자와 같은 메모리 영역에 있다는 특성이 단점만 있는 것은 아니다. 메모리를 공유하므로 별도의 통신을 위한 처리가 요구되지 않고, 따라서 속도가 매우 빠르다.

이에 비해 out-of-process는 호출자와 별개의 메모리 공간을 가지는 또 하나의 프로세스이다. 따라서 화면 출력에 전혀 제한이 없고 원격 OLE 오토메이션에 이용될 수 있으며, 호출자와 비동기적(asynchronous)으로 실행될 수 있다. 또한, 서버와 클라이언트는 별개의 프로세스이므로 서로 같은 메모리 여건을 가질 필요도 없다. 즉 서버가 32bit이면 클라이언트는 16bit일 수도 있고 혹은 그 반대일 수도 있다. Out-of-process가 클래스의 모듈의 Instancing 속성을 통해 여러 개의 인스턴스가 활성화 될 수 있도록 하면 클라이언트의 요구에 능동적으로 대응할 수 있다. 각각의 인스턴스는 별도의 프로세스이므로 멀티테스킹에 의해 각각이 활성화된다. 물론 이 경우 쓰레드(thread)로 처리했다면 좀 더 효율적이었을 것이다. 비베 다음 버전은 쓰레드를 지원할 것을 기대해 본다. 참고로 In-process는 DLL이기 때문에 여러 개의 인스턴스가 활성화될 수 없다. 이러한 장점에 비해 out-of-process는 호출자와 메모리 영역이 다르므로 통신이 in-process 서버에 비해서 느릴 수밖에 없다는 단점을 내포하고 있다.

원격 OLE 오토메이션 서버

원격 OLE 오토메이션은 서버와 클라이언트가 서로 다른 컴퓨터에 존재할 수 있도록 한다. 이로써 OLE 서버는 네트워크를 가로질러 존재할 수 있게 되었고 클라이언트는 원격 OLE 오토메이션을 통해 제공되는 이러한 서버 컴포넌트에 쉽게 전근할 수 있게 되었다. 따라서 클라이언트/서버 시스템을 구축하는데 있어서 보다 유연성 있게 프로그램을 네트워크 전체에 걸쳐 분산시킬 수 있다.

그럼 지역(local) OLE 오토메이션과 원격 OLE 오토메이션에 대해 좀 더 내부적으로 고찰해 보자. 먼저 지역 OLE 오토메이션에 대해서 알아보자. In-process 오토메이션인 경우 서버와 클라이언트간의 연결은 매우 간단하다. 두 부분이 하나의 메모리를 공유하는 하나의 프로세스이기 때문이다. 이에 반해 Out-of-process인 경우에는 다소 복잡해진다. 서버와 클라이언트가 별도의 프로세스이기 때문이다. 프로세스의 메모리는 다른 프로세스로부터 철저히 보호된다. 오직 운영체제의 커널만이 불법적인 침입자의 대상에서 제외된다. 이런 상황에서 서버와 클라이언트의 연결을 위해서는 별도의 처리가 필요하다. 이를테면 참조형(call by reference)으로 인자가 메쏘드를 통해 서버에 전달되어야 하는 경우를 생각해 보자. 메모리 보호에 의해 서버는 클라이언트의 메모리 공간을 가리키는 포인터를 전혀 사용할 수 없다. 따라서 OLE 오토메이션은 포인터가 가리키는 메모리의 내용을 서버의 메모리 공간에 복사하고 포인터가 서버에 복사된 내용을 가리키도록 조정한다. 서버의 메쏘드가 끝났을 때 결과를 다시 클라이언트의 메모리 공간으로 복사하고 포인터를 원래의 값으로 전환한다. 이러한 작업은 proxy와 stub에 의해 처리되는데 <그림 7>을 참조하기 바란다.

<그림 7> Out-of-process 지역 OLE 오토메이션에서 연결 방법

클라이언트 쪽의 오토메이션 proxy와 서버 쪽의 오토메이션 관리자(automation manager)는 기존의 지역 OLE 오토메이션을 확장한다. <그림 8>에 나타나 있듯이 클라이언트 쪽의 오토메이션 proxy와 서버 쪽의 오토메이션 관리자중 원격 오토메이션 stub간에 RPC(Remote Procedure Call)을 통한 네트워크 상에 데이터 교류가 일어난다. 오토메이션 관리자는 다중 쓰레드로 구현되어 있어서 많은 클라이언트의 요구를 즉각 처리할 수 있다. 오토메이션 관리자의 OLE proxy와 서버의 OLE stub에 관계는 지역 OLE 오토메이션에서 설명된 proxy/stub 관계와 동일하다. 이러한 방법을 통해 클라이언트 입장에서는 서버가 같은 메모리에 있는지 아니면 네트워크로 연결된 다른 메모리에 있는지는 고려 대상이 아니다. 서버 입장에서도 서버와 같은 메모리에 있는 오토메이션 관리자가 RPC로 넘어온 데이터를 지역 OLE 오토메이션의 상황과 동일하게 넘겨주므로 원격적이든 지역적이든 신경 쓸 필요가 없다. 따라서 이러한 추상화는 개발자에서 많은 짐을 덜어준다.

윈도우즈와 OLE 그리고 비베

마이크로소프트는 자사의 운영체제인 윈도우즈 패밀리를 객체지향적으로 변모시키기 위해 OLE을 내놓았다. 사실 1990년 컴덱스 쇼에서 OLE 1.0 스펙이 발표되었을 때 만 해도 별 다른 특별한 점이 없었다. 복합문서(compound document)를 꾸미기 위해 여러 가지 객체를 연결하고 붙이는 정도였다. 사용자 입장에선 객체 지향을 위해서가 아니라 문서를 예쁘고 손쉽게 꾸미기 위해서 OLE가 있다라고 인식하는 게 보통이었다. 그러나 2.0이 나오면서 OLE는 정말이지 객체지향 윈도우즈를 위한 초석임을 보여주었다. 특히 OLE 2.0의 오토메이션 기술은 모든 응용 프로그램을 위한 컴포넌트를 형성하므로써 기존의 소프트웨어의 설계나 프로그래밍 방식에 큰 영향을 미칠 것이다. 보통 언어 내에서 만의 객체 지향 기술의 첨가는 분명히 한계가 있다. 그 언어 영역 외에 속하는 운영체제의 여러 개체들에 대해서는 전혀 그 힘을 쓰지 못하기 때문이다. OLE와 같은 운영체제 차원에서의 객체지향의 지원은 운영체제가 전체 컴퓨터 환경을 관할하기 때문에 전반적이고 직접적인 영향을 끼친다. 이러한 OLE에 근거해 만들어진 객체는 특정 언어에 비의존적이 되고 메모리의 공유 여부에 비의존적이 되었으며 이제 플랫폼에 비의존적이 되어야 할 것이다. 서로간의 이질적인 운영체제 아래서 서로간의 객체를 서로 교환할 수 있다면 그야말로 완벽한 분산체제 환경이다. 이에 대해선 CORBA(Common Object Request Broker Architecture)와 같은 스펙이 발표되어 있지만 마이크로소프트처럼 독식하기 좋아하는 기업이 과연 다른 곳과 협력하며 이 안을 그대로 수용할 지도 미지수다.

현재로서는 비베가 OLE 객체를 손쉽게 만들 수 있는 최선의 선택이다. C++과 같은 비교적 하위 레벨의 컴파일러 언어로 OLE 객체를 만든다는 것은 쉬운 일만은 아니다. 이런 의미에서 비베 4.0의 출시는 마이크로소프트에게는 전략적으로 매우 중요하다. 사실 OLE 2.0이 나온 지 몇 년이 지났지만 그 기술의 난해함 때문에 쉽게 그 기술을 사용하기가 쉽지는 않았고 그래서인지 OLE 객체를 제공하는 제품은 마이크로소프트사의 제품과 VISIO같은 몇몇 제품을 제외하곤 거의 찾아보기 힘들었다.

다음 회에서는 add-ins라는 비베 개발환경의 독특한 특징을 다루고자 한다. 비베의 개발 환경은 OLE 오토메이션을 통해 개발 환경을 커스터마이징(customizing)할 수 있는 객체들을 공개하고 있다. 비베 개발 환경의 내부를 자세히 몰라도 VBAssist와 같은 애드온 툴을 쉽게 만들 수 있다. 그것도 C++과 같은 언어가 아닌 비베 자체로 말이다.

하루가 다르게 급변하는 컴퓨터 산업을 바라볼 때면 그저 한숨이 나오는 경우가 많다. 그저 따라갈 뿐이다. 미국에서 만든 기술들을 보고 우리는 최신 기술을 얻었음을 기뻐한다. 다른 학문에서도 항상 거론되는 말이지만 순수 기초 학문의 부재는 컴퓨터 과학(computer science)에서도 그대로 적용된다. 미국과 경쟁 자체를 하기에도 너무 뒤쳐져있는 현실 속에서 우리들은 그네들이 만들어 놓은 운영체제, 데이터베이스, 개발 툴들을 가져다 응용할 뿐이다. 대학생들이 운영체제를 만든다는 그들을 우리들은 언제나 따라갈 수 있을는지...

예제에 대해서... <- 적당한 위치에 넣어주세요.

예제는 두 개의 프로그램으로 되어 있다. 하나는 OLE 서버(Telcode.vbp)이고 다른 하나는 클라이언트(OLECli.vbp)이다. 따라서 두 개의 비베를 실행시켜 하나에는 OLE 서버를 실행시키고 다른다른 하나에는 클라이언트 예제 프로그램을 실행시키면 된다.