프로그래밍 패러다임 관점에서 본 마이크로소프트 API의 변천

TechNet NTO 칼럼

프로그래밍 패러다임 관점에서 본 마이크로소프트 API의 변천
	김명호, 한국마이크로소프트 NTO 출처 : 윈도우 & 닷넷 매거진 2004년 6월호 MS-DOS 1.0에서 시작하여 Windows XP와 Windows Server 2003에 이르기까지 마이크로소프트의 운영체제 플랫폼은 기반코드와 핵심기능, 사용자 인터페이스 면에서 대체로 점진적이면서도 가끔씩 혁신적인 변경과 발전을 거듭해 왔다. 사용자 관점에서 보면 커맨드라인과 그래픽 기반의 인터페이스는 큰 차이가 있으며, 인터넷과 웹의 지원 여부 또한 실용적 측면에서 너무나 중요할 것이다. 그러나 사용자 관점이 아닌 개발자의 관점에서 본다면 과거의 플랫폼과 오늘날의 플랫폼은 어떤 차이가 있는가? 또한 미래의 플랫폼은 어떤 의미로 받아 들여야 하고, 이를 위하여 지금 무엇을 준비해야 하는가? Windows Longhorn이 소개되고 있는 이 시점에 한번쯤은 진지하게 생각해 보아야 할 것이다. 1. 절차적 프로그래밍과 Win32 Win32는 단계층(평면적)의 절차적 API로, C 프로그램에서 호출 가능한 함수들로 정의되었다. Win32의 특징은 윈도우가 제공하는 기능에 대한 거의 무제한적인 액세스를 허용한다는 것이다. 이러한 이유로 재사용성이나 조립가능성과 같은 고급 기능을 제공하는 API가 점차 추가되는 추세에도 불구하고 많은 프로그래밍 작업에 여전히 Win32가 사용되고 있다. 그러나 이러한 Win32의 사용에는 혹독한 대가도 있다. 무엇보다 API 만으로는 다른 프로세스의 기억장소 영역을 침범한다거나 허용되지 않는 위치에 선을 그리라고 요청하는 것과 같이, 실수나 고의에 의한 잘못된 사용을 판별하기 어렵다는 것이다. 이러한 실수들은 대부분 특정 목적을 위한 보다 큰 규모의 프로그램 내부에서 사용되는 일부 API 호출 코드에서 발생한다. 절차적 프로그래밍은 함수보다 큰 단위의 재사용과 확장을 위한 효과적 수단을 제공하지 않으므로 API 함수들을 일일이 호출하는 시퀀스를 피하기 힘든 문제가 있다. 또 다른 문제는 Win32가 C 언어를 위주로 정의되었지만 실제 프로그래밍에는 Visual Basic을 위시하여 다른 많은 프로그래밍 언어가 사용될 수 있다는 것이다. 그 결과 여러 프로그래밍 언어 사이의 바이너리 호환성이 보장되지 않으면 모든 프로그래머가 C 언어를 사용하도록 강요할 수 밖에 없다. 마지막으로 Win32는 다른 프로그램과의 정보 교환을 거의 고려하지 않고 설계된 까닭에 분산 프로그래밍이 필요한 환경에 대처할 수 있는 적당한 수단이 없다. 2. 컴포넌트 프로그래밍과 COM COM(Component Object Model)은 바이너리 수준에서 상호 호환되고 조립에 의한 방법으로 재활용할 수 있는 프로그램 단위인 "컴포넌트"를 위한 마이크로소프트의 표준이다. COM은 고수준의 기능을 제공하는 보다 큰 단위의 재사용 수단을 제공하므로 개별적인 API 함수들을 절차적으로 호출하는 코드를 일일이 작성하지 않고 조립에 의한 프로그래밍을 실현할 수 있다. COM 컴포넌트와 이를 활용하는 프로그램이 서로 다른 언어로 작성될 수 있도록 COM은 바이너리 수준의 인터페이스 정의를 통하여 언어 사이의 상호 운용성을 모색하였다. 또한 COM 컴포넌트들이 서로 다른 프로세스나 머신에서 실행되는 컴포넌트와 상호작용 할 수 있도록 하는 DCOM(Distributed COM) 표준도 제공되었다. 윈도우의 일부 API는 COM 형태로 제공되기 시작했으며 DirectX API는 그 대표적인 사례이다. 심지어 일상 업무에서 자주 사용하고 있는 Microsoft Word나 Internet Explorer도 COM API를 제공하므로 COM을 지원하는 임의의 프로그래밍 언어에서 이들을 컴포넌트로 자유롭게 활용할 수 있다. COM은 지나치게 C++ 친화적이고, 한 컴포넌트와 다른 컴포넌트의 의존성을 표현하기 어려우며, 여러 버전을 효과적으로 관리하기 어렵다는 문제가 있다. (이 문제는 흔히 "DLL Hell"로 알려져 있다.) 3. 혼돈의 시기 - MFC/ATL, Visual Basic, ASP MFC(Microsoft Foundation Classes)는 Win32의 특이성과 절차적 패러다임의 약점을 극복하기 위하여 일관성 있고 객체지향적 C++ 클래스 라이브러리를 정의한 것이다. MFC는 자주 사용되는 기능을 추상화한 클래스를 제공함으로써 일상적 코드 작성의 노력을 크게 감소시킬 수 있고 오류 발생 가능성도 줄일 수 있었다. 그러나 MFC가 직접 제공하지 않는 기능이 필요하면 Win32와 MFC 클래스의 상호작용 규칙까지 이해해야 하는 심각한 문제가 있다. ATL(ActiveX Template Library)은 템플릿(template) 기반의 클래스를 최대한 활용하여 효율적인 COM 컴포넌트나 일반 애플리케이션을 작성하도록 한 것이다. 그러나 ATL은 C++의 특이성에 의존하여 작성된 코드의 이해도가 매우 나쁘다는 문제가 있다. MFC/ATL이 복잡하고도 강력한 기능성을 제공하려 한 것에 반해 Visual Basic 팀에서는 Win32의 모든 기능을 충실히 제공하기 보다는 일부 기능을 희생하더라도 핵심적 기능들을 손쉽게 사용할 수 있는 컴포넌트 라이브러리로 재구성하여 제공하고자 하였다. ASP(Active Server Pages)는 기능적 코드와 마크업으로 구성된 웹 애플리케이션 개발을 위한 서버측 기술이다. ASP는 동적 웹 페이지를 효과적으로 구축할 수 있지만 기능적 코드 작성에 Visual Basic Script나 JScript와 같은 스크립트 언어에 의존하므로 고급의 프로그래밍 언어와 라이브러리가 지원되지 않으며, 일일이 해석하여 페이지를 생성하므로 효율에도 문제가 있었다. 4. 통합과 상호운용을 위한 .NET 닷넷(.NET)은 공통의 기술적 기반을 사용하여 Win32, COM/DCOM, MFC/ATL, Visual Basic, ASP 등을 통합하고, 이질적인 시스템과의 효과적인 상호운용을 위하여 XML과 웹 서비스를 지원하는 프레임워크이다. 닷넷은 프로그래밍 언어 중립적인 실행환경인 CLR(Common Language Runtime)과 CLR 환경에서 실행되는 관리되는 라이브러리들의 집합인 FCL(Framework Class Libraries)로 구성되어 있다. 닷넷은 C#, Visual Basic, C/C++, J#, JScript 등의 여러 프로그래밍 언어를 지원하며 현재에도 지속적으로 새로운 언어가 추가되고 있다. 닷넷은 이전의 API와 프로그래밍 환경과는 다음과 같은 중요한 차이가 있다. 임의의 닷넷 언어에서 (거의) 동일한 수준의 기능성을 사용할 수 있다. CLR에서 실행되는 임의의 언어에서 FCL을 사용할 수 있으므로 프로그래밍 언어의 선택이 사용할 수 있는 기능성의 범위를 좌우하지 않는다. FCL과 모든 닷넷 언어에서 객체지향 프로그래밍을 일관성 있게 지원한다. 심지어 Visual Basic 언어도 절차적 언어일 뿐만 아니라 C#이나 C++와 동일한 수준의 객체지향 프로그래밍을 구문적, 의미적, 실용적으로 지원한다. 여러 프로그래밍 언어가 상호운용될 수 있다. CLR은 서로 다른 언어로 작성된 프로그램이 동일한 의미적 기반을 사용하여 통합될 수 있는 환경을 제공하므로 Visual Basic으로 작성한 클래스를 C#에서 상속하여 확장할 수 있고, C++ 코드에서 그 클래스의 인스턴스를 생성하여 사용할 수 있다. 그러므로 닷넷을 위한 라이브러리는 그 소스코드를 작성한 언어에 관계없이 임의의 닷넷 언어에서 활용될 수 있다. 효과적인 배포와 버전관리를 지원한다. COM이 DLL/EXE와 TLB를 별도로 제공하여야 했던 것과는 달리 닷넷은 메타정보를 활용하여 TLB가 없더라도 라이브러리의 내용과 다른 라이브러리와의 의존성을 자동으로 유추할 수 있다. 또한 한 시스템에 동일한 라이브러리의 여러 버전을 유지할 수 있다. 예전의 API 함수들과 COM, DLL 등을 지원하는 여러 직접적인 수단을 제공한다. XML과 웹 서비스를 근원적이고도 총체적으로 지원한다. 닷넷은 XML이 정수나 객체처럼 일반적이고도 손쉬운 데이터 표현 수단으로 사용된다. ADO.NET을 사용하면 데이터베이스의 테이블과 XML을 호환적으로 사용할 수도 있다. ASP.NET을 사용하면 컴포넌트 모델과 닷넷 언어를 사용하여 효율적인 동적 웹 페이지를 매우 손쉽게 작성할 수 있다. 즉 컴포넌트와 이벤트 기반의 프로그래밍 모델을 사용하여 웹 서버 프로그래밍과 일반 애플리케이션 개발 모델을 단일화 하였다. 닷넷은 다른 플랫폼과의 상호운용을 위하여 WS-I Basic Profile 1.0을 충실히 구현하였다. 웹 서비스를 개발하는 노력이 일반 함수 개발 노력과 거의 차이가 없고, 어떤 언어를 사용하더라도 웹 서비스를 개발-활용할 수 있으며, 어떤 목적의 어떤 수준의 기능도 웹 서비스로 제공될 수 있다. 이는 프로토콜에 대한 깊은 지식이 필요하고 특정 언어로 특정 티어를 위한 기능만 웹 서비스로 제공할 수 있는 다른 플랫폼과는 근본적으로 구별되는 특징이다. 5. The Road Ahead - WinFX Windows Longhorn에서는 닷넷의 FCL을 기반으로 웹 서버와 일반 애플리케이션 개발을 완전히 통합한 Avalon 서브시스템과 XAML 언어, 확장 가능한 메타정보를 기반으로 고수준의 정보 검색과 관리를 위한 WinFS 서브시스템, 여러 유형의 커뮤니케이션을 서비스/메시지/채널 등의 개념으로 통합한 Indigo 서브시스템을 추가한 API인 WinFX를 제공할 것이다. 운영체제의 모든 핵심 API를 관리되는 환경에서 실행되는 객체지향 라이브러리로 제공하려는 것은 매우 새롭고 도전적인 시도이다. 그러나 대규모로 분산화된 오늘날의 컴퓨팅 환경에서는 생산성과 신뢰성을 분리해서 생각할 수 없으며 어느 한 목표를 위하여 다른 목표를 절대 희생할 수 없다. WinFX를 관리되는 코드로 정의한 것은 효율성과 기능성을 절대 목표로 했던 예전 관행과는 달리 "신뢰할 수 있는 컴퓨팅"(Trustworthy Computing, TwC)을 핵심 API 수준에까지 적용하고자 하는 적극적인 노력으로 간주할 수 있을 것이다.