IT 종합뉴스서비스

보통 프레임워크라고 하면 자바 기반의 다양한 프레임워크를 떠올리기 십상이지만, 최근에는 닷넷 버전으로 컨버전 되고 있는 경우도 종종 보게 된다. 프레임워크의 중요도가 높아짐에 따라 MS는 닷넷 프레임워크 3.0의 모습을 거의 갖춘 상태이다. 또, 지난해에는 한국 MS 단독으로 microsoft.Framework를 무료 공개하기도 했다. 어쩌면 머지않아 더 다양한 닷넷 기반 프레임워크들을 만나게 될 지도 모를 일이다.

닷넷 프레임워크의 활용 전략에 대해 알아보기에 앞서 프레임워크가 무엇인지에 대해 다시 정의해 보자. 프레임워크는 Gof의 디자인 패턴으로 유명한 랄프 존슨(Ralph Johnson)은 프레임워크를 다음과 같이 정의했다.

“A framework is a set of cooperating classes that make up a reusable design for a specific class of software”
“프레임워크란 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 클래스들의 집합”

랄프 존슨의 정의에서 알 수 있듯이 프레임워크의 핵심은 재사용성에 있다. 재사용 가능하도록 클래스들을 설계해서 만들어야만 프레임워크라 부를 수 있는 것이다. 이러한 재사용성은 추상화를 전제로 한다. 그렇다면 라이브러리와는 어떻게 구별할 수 있을까?

라이브러리는 특정 기능을 구현하는데 중심을 둔 반면에, 프레임워크는 이러한 기능 문제를 해결한 라이브러리를 조합하여 실제 문제 해결에 중심을 두고 만든 것이라고 이해하면 쉬울 것이다.

프레임워크는 보는 관점 따라서 다양한 분류 방법이 있다. 닷넷 프레임워크 같은 것을 보통 벤더 프레임워크(Vendor Framework)라고 분류한다. MS라는 벤더 사에서 만들었기 때문이다. 잘 사용되지는 않지만 썬마이크로시스템즈에서도 자바 기반의 JATO(Sun One Application Framework)라는 벤더 프레임워크를 만들어 배포하고 있다.

닷넷 프레임워크는 그 자체로 하나의 훌륭한 프레임워크이다. 하지만 이 닷넷 프레임워크만 가지고 애플리케이션을 만드는 경우는 흔치 않을 것이다. 대부분 애플리케이션 성격에 맞는 프레임워크를 미리 준비해서 그 프레임워크 위에서 개발을 하게 된다.

따라서 닷넷 프레임워크는 프레임워크의 프레임워크라고도 할 수 있다. 프레임워크는 그 자체로 완성된 작품이 아니며, 업무에 따라 프레임워크 위에 또 다른 프레임워크를 올려서 더욱 추상화된 형태로 사용할 수도 있는 것이다.

<그림1> 닷넷 개발 아키텍처

프레임워크가 필요한 이유?

프레임워크가 필요한 이유를 한마디로 요약하자면 바로 생산성이다. 프레임워크 없이 프로젝트를 한다면 같은 기능을 수행하는 서로 다른 버전의 코드가 존재할 것이고, 매번 똑같은 일을 수행하는 코드가 Copy&Paste 방식으로 차용될 것이다.

또, 개발자의 실력에 따라 천차만별로 달라지는 코드를 통해서 유지보수의 어려움을 느낄 것이다. 새로운 환경이나 변화에 따라 코드를 다시 다 뒤집어 업는 경우도 발생할 것이며, 개발자들이 개발한 코드를 정말 잘 만들었는지 검수할 방법조차 막막해 질 것이다.

정형화된 프레임워크를 사용하면 표준화된 코드들을 생산해 낼 수 있으며, 이를 통해서 생산성을 향상 시키고 좋은 품질의 코드를 만들어 낼 수 있는 것이다.

MS와 프레임워크의 역사
기업용 애플리케이션 환경에서 그동안 자바 진영이 두각을 나타내온 만큼 자바 진영에는 수많은 오픈 프레임워크가 존재 한다. 오히려 너무 많아서 무엇을 선택해야 할지 행복한 고민에 빠지기도 한다. 하지만 닷넷 진영에서는 선택할 수 있는 프레임워크가 많지 않다.

MS는 과거 클라이언트 기반의 윈도우나 오피스와 같은 패키지 소프트웨어에서 두각을 나타내었지만, 서버 기반의 기업용 애플리케이션은 자바 진영이 두각을 나타내고 있었다.

MS는 이러한 기업용 시장에서는 후발 주자였으며, 패턴이니 프레임워크니 하는 용어 자체가 MS내에서는 익숙하지 않은 용어였다. 하지만 근래에 들어 이러한 기업용 시장에 눈을 뜬 MS는 기업용 서버 기반의 애플리케이션을 제작하는데 있어 개발 방법론, 패턴, 개발 프레임워크를 정리하기 시작했다.

그렇게 해서 만든 사이트가 MS의 패턴 앤프렉티스 사이트이다(http://msdn.microsoft.com/practices). 이곳에 가면 아키텍처에서부터 라이브러리까지 상세한 가이드라인을 제시하고 있다.

프레임워크를 위한 엔터프라이즈 라이브러리
보통 프로젝트를 한다고 하면 개발에 앞서 프레임워크를 준비하게 된다. 회사에서 자체적으로 만들어둔 표준 프레임워크가 있다면 그것을 사용할 것이다. 만약, 자체 프레임워크가 없다면 일단 프레임워크부터 만들어야 프로젝트를 시작할 수 있다. 하지만 프레임워크를 처음부터 만든다는 것이 그리 쉬운 일이 아니다.

프레임워크를 만드는 것은 아주 많은 시간과 노력을 필요로 하는 작업이다. 때문에 대부분의 경우 프레임워크를 처음부터 만드는 대신 다른 프레임워크를 가져다가 그 위에 자사의 고유한 특징들을 추가하여 사용하게 마련이다. 또, 다른 라이브러리들을 조합해서 자사의 프레임워크로 만들어 사용하기도 한다.

MS는 이처럼 복잡한 프레임 워크 개발을 돕기 위해 엔터프라이즈 라이브러리(Enterprise Library)라는 프레임워크를 내놓았다. 엔터프리이즈 라이브러리는 프레임워크를 위한 종합 선물 세트 같은 것이다(엔터프라이즈 라이브러리는 이미 본지 2006.7~8월호에 소개가 되었으니 자세한 내용은 과월호를 참조하길 바란다).

엔터프라이즈 라이브러리 2.0은 다음과 같이 여섯 개의 블록으로 구성된다.

• 캐싱 애플리케이션 블록(Caching Application Block) 로컬 캐시 처리를 위한 블록
• 암호 애플리케이션 블록(Cryptography Application Block)해시 함수와 동기 암호화를 위한 블록
• 데이터 액세스 애플리케이션 블록(Data Access Application Block)표준화된 데이터베이스 액세스 기능을 위한 블록
• 예외 처리 애플리케이션 블록(Exception Handling Application Block)아키텍처 레이어 전체를 포함하여 일관된 예외 처리 정책 수립을 위한 블록
• 로깅 애플리케이션 블록(Logging Application Block)로깅 정보 처리를 위한 블록
• 보안 애플리케이션 블록(Security Application Block)권한 검증과 보안 캐시 처리를 위한 블록

엔터프라이즈 라이브러리의 블록은 많이 사용되는 기능들을 유형별로 구분해 놓은 것이라고 생각하면 쉽다. 그뿐 아니라 엔터프라이즈 라이브러리의 소스 코드까지 다 제공되는 덕에 개발자들이 자신의 업무나 현장에 맞도록 블록을 재구성하여 새로운 프레임워크로 만들 수도 있다.

즉, 필요 없는 기능은 제거하고 더 필요한 기능은 추가해서 맞춤형 프레임워크를 만들 수 있도록 도와주는 라이브러리인 것이다.

엔터프라이즈 라이브러리의 각 블록들은 사실 하나 하나가 프레임워크라고도 할 수 있다. 로깅 프레임워크, 보안 프레임워크로 불릴 수도 있다. 왜냐하면 이들 블록은 각각, 재사용성을 가지고 있고, 로깅 및 보안과 같은 해당 업무를 총괄하는 기능을 모두 가지고 있는 까닭이다.

따라서 이들을 프레임워크 분류상으로 기능 프레임워크(Fuctional Framework)라고도 부른다. 단위 테스트 도구인 JUNIT의 닷넷 버전인 NUNIT 또한 단위 테스트 프레임워크라고도 부를 수 있다.

하지만 MS에서는 프레임워크라는 용어 대신 좁은 범위로 묶어서 라이브러리라는 용어를 채택하였다. 그 의도를 알 수는 없으나, 향후 이러한 라이브러리를 묶어서 어떤 상위 개념의 프레임워크의 등장을 염두에 두고 한 것이 아닌가라고 개인적으로 추측을 해 보았다.

엔터프라이즈 라이브러리의 가장 큰 특징은 설정 부분을 별도의 외부 파일로 노출하였다는 점이다. 그 덕에 환경이 바뀌더라도 다시 컴파일 할 필요 없이 환경 설정 파일만 변경해 주면 된다.

예를 들어 DB로 SQL Server를 사용하다가 Oracle로 바꾸었다든지, 암호화 방식을 AES방식에서 DES방식으로 변경해야 한다면, 소스 코드를 수정하지 않고 환경 파일의 내용만 변경하면 된다. 또 다른 특징으로는 성능 카운터 측정을 위한 도구를 제공한다는 것이다.

예를 들어 해당 애플리케이션의 반응 속도가 너무 느려졌는데, 어디에서 원인이 있는지 찾아보려고 할 때, 성능 카운터를 돌려서 어느 부분에서 부하가 있는지 알아 볼 수 있다는 것이다. 이처럼 다양한 기능을 가진 라이브러리를 제공하므로 이를 적절히 조합해서 해당 분야에 맞는 프레임워크를 만들 수 있다.

MS 코리아의 자체 프레임워크 Microsoft.Framework
지난 12월 MS 코리아에서는 닷넷 엑스퍼트라는 회사에서 개발하여 사용해 오던 닷넷 기반의 개발 프레임워크인 DxFramework을 인수했다. 이 프레임워크를 공개용 버전으로 만들어서 Microsoft.Framework라 이름을 붙이고 MS 개발자 사이트인 MSDN에서 무료로 배포하고 있다.

(http://www.microsoft.com/Korea/MSDN/netframework/technologyinfo/overview/ netdevelopmentguid.aspx)DxFramework은 처음에 반복되는 데이터 액세스 코드 부분을 간소화하기 위해 라이브러리로 묶은 것이었으나 점점 다른 기능들을 추가 하면서 프레임워크 형태로 발전한 것이다. 위 사이트에는 이 개발 프레임워크 외에도 닷넷 기반의 개발 방법론까지 공개하고 있으므로 관심 있는 독자는 한번 다운로드 받아서 보길 바란다.

Microsoft.Framework 의 활용

공개된 Microsoft.Framework는 닷넷 1.1 버전의 프레임워크이다. 여기서 소개된 Microsoft.Framework는 닷넷 익스퍼트라는 회사에서 만든 DxFramework의 Lite 버전이다. 하지만 현재 닷넷 익스퍼트에서 상용으로 판매하고 있는 DxFramework와는 전혀 다른 프레임워크임을 알아두자. 다운로드는 앞에서 언급한 URL에서 프레임워크 설치파일을 다운받을 수 있을 것이다. 모두 한글 기반으로 작성된 프레임워크인 덕에 누구나 쉽게 설치하여 사용할 수 있다.

Microsoft.Framework 설치
설치 프로그램을 다운로드 받은 뒤에 ‘Microsoft.FrameworkSetup.msi’라는 파일을 실행하면 자신이 원하는 폴더에 프레임워크를 설치할 수 있다.

<화면 1> Microsoft.Framework의 설치화면

설치를 하게 되면 해당 폴더에 Bin과 Source라는 폴더가 만들어 진다. Bin 폴더에는 컴파일 된 프레임워크 dll 파일이 생성되고, Source 폴더에는 Microsoft.Framework를 구성하고 있는 소스와 솔루션 파일들이 만들어지게 된다.

<화면 2> Microsoft.Framework의 소스파일

<그림 2>는 Microsoft.Framework의 구조와 주요한 네임 스페이스의 기능을 정리한 것이다. Microsoft.Framework는 크게 네 가지 기능을 가지고 있다. 첫 번째 기능인 Microsoft.Framework.Configuration은 xml 형태를 가진 계층적 구조를 가진 config 파일 내용을 읽어 오기 위해 사용된다. Microsoft.Framework.Data는 SQL 데이터베이스를 연결을 위한 Microsoft.Framework의 핵심 기능이다.

Microsoft.Framework.Diagnostics는 애플리케이션 실행 중 발생하는 에러를 기록할 때와 컴포넌트의 실행시간을 체크하기 위해서 COM+의 JITA 속성과 결합해서 사용되는 기능이다. 마지막 기능인 Microsoft.Framework.Utility는 스트링이나 파일의 조작을 보다 쉽고 편하게 하도록 지원된다.

<그림 2> Microsoft.Framework의 구조

샘플 프로젝트 설치
Microsoft.Framework는 샘플 프로젝트를 제공하고 있다. 이 프로젝트를 설치하면 3Tier 기반의 사이트를 볼 수 있을 것이다. 또한 가장 중요한 프레임워크 매뉴얼도 볼 수 있기 때문에 이 샘플 프로젝트는 반드시 설치하여 확인해 보아야 한다. Microsoft.Framework는 다음과 같은 디자인 목표를 가지고 있다.

• 가급적이면 컴포넌트나 컨트롤 형식으로 작성하여 디자인 타임 지원 기능을 가지도록 한다.
• 런타임 시에 필요한 정보는 속성이나 메소드의 매개 변수로 전달받기 보다는 구성 파일이나 스택 정보에서 읽어내도록 하여 사용을 간편하게 한다.
• 초기화 및 정리 작업이 지능적으로 이루어지도록 하여 되도록이면 작성해야 하는 코드 량을 줄일 수 있도록 한다.
• 구성 파일에서 다양한 동작 특성을 지정할 수 있도록 하여 별도의 커스터마이징 작업이 필요하지 않도록 한다.
• 닷넷 프레임워크와 흡사한 네임스페이스 구조를 가지도록 하여 직관적으로 해당 클래스가 어떠한 역할을 하는지 알 수 있도록 한다.

Microsoft.Framework 샘플 소스의 버전은 닷넷 1.1 버전이다. 이 코드를 VS.NET 2005 환경에서 실행하고 싶다면 Visual Studio 변환 마법사를 통해 쉽게 컨버팅 할 수 있다.

<화면 3> Viusal Studio 변환 마법사

이 샘플은 DB는 SQL2000에 기본으로 들어 있는 Northwind DB 스키마를 사용하며 내용을 한글화 한 것이다. 이는 MS 한글 오피스 프로그램이 액세스 샘플로 제공하고 있기도 하다. 샘플에서 제공하고 있는 데이터베이스의 스키마는 <화면 4>와 같다.

<화면 4> Northwind DB 스키마

이 샘플의 특징 중 하나는 모든 웹 페이지는 BaseClass/PageBase를 상속 받고 있다는 것이다. PageBase는 OnInit 오버라이딩 메소드에서 자신의 Content를 화면에 나타내기 전에 Table과 함께 Top Control을 먼저 출력시킨다. 나중에 자신의 Content를 지정된 TD 안에 출력시킨다. <리스트 1>은 이와 관련된 예제 코드이다.

<리스트 1> BaseClass/PageBase 상속 예제

Microsoft.Framework.Configuration
앞에서도 잠깐 알아본 것처럼 Microsoft.Framework.Configuration은 XML 형태의 계층적 구조를 가진 Config 내용을 읽어 오기 위한 기능의 네임스페이스이다. 그 기능을 담당하는 클래스는 AppSettingsReader이다. 만약 어떤 특정한 가변적인 정보를 설정하거나 할 때 Config 파일을 활용해서 설정하면 될 것이다.

물론 Web.Config나 App.Config를 이용해서 특정 정보를 관리 할 수도 있다. 그렇다면 여기서 제공하고 Configuration의 특징은 무엇인가? 다음은 기본 Configuration과 차별된 특징을 보여주고 있다.

• 기본 구성 파일이 아닌 사용자 지정 구성 파일을 사용 할 수 있다.
• 다른 AppDomain의 구성 정보 파일을 기본으로 사용하도록 지정할 수 있다. 이 기능은 서버 활성화를 사용하는 COM+ 클래스에서 편리하게 구성 정보에 접근할 수 있도록 한다.
• 계층적으로 구성된 구성 정보를 사용할 수 있다.
• 지정된 키 값에 해당하는 정보가 없을 경우 디폴트값을 사용할 수 있다.
• 디폴트값의 타입에 맞춰 리턴 값의 타입이 정해지므로 별도의 캐스팅이 필요 없다.
• 구성 정보를 읽는 기본 메서드(GetValue())외에 인덱스를 제공함으로써 호출구문이 간단해진다.

<리스트 2> AppSettingsReader의 구성파일 설정 예

<리스트 3>은 구성 파일을 초기화해서 구성 요소를 불러오는 간단한 예제이다.

<리스트 3> AppSessingsReader 사용 예

Microsoft.Framework.Data
이 네임스페이스는 SQL 데이터베이스를 연결을 위한 Microsoft.Framework의 핵심 기능을 담당하고 있다. 그 안의 클래스들 중에서도 SqlDbAgent라는 클래스가 가장 대표적인 기능을 하고 있다. 이 SqlDbAgent의 메소드와 사용 예제를 다루어 보도록 하겠다.

<리스트 4>는 가장 많이 사용하게 될 Fill 메소드에 대한 사용 예이다. 데이터를 받아와서 데이터셋에 채우기 위해서는 많은 양의 코드가 필요하지만 Fill 메소드를 사용하면 간단하게 작성할 수 있다.

<리스트 4> Fill 메소드 예제

SqlDbAgent 클래스의 특징은 다음과 같이 요약할 수 있다.

• DataAdapr, Command 클래스의 자주 사용되는 대부분의 메소드 지원
• 구성 파일을 통한 데이터베이스 연결문자열 지원
• 다중 데이터베이스 연결문자열 지원
• 데이터베이스 연결 자원 관리
• 데이터베이스 관련 에러 로깅
• 성능카운터 객체 제공
• COM+ 분산 트랜잭션 및 자동 트랜잭션 지원

SqlDbAgent 라는 클래스 말고도 쿼리를 쉽게 작성하기 위한 QueryBuilder나SqlParameter를 보다 쉽게 조작하기 위한 DbParamHelper라는 클래스가 제공되고 있다. <리스트 5>는 DbParamHelper와 QueryBuilder의 예를 보여주고 있다.

<리스트 5> DbParamHelper와 QueryBuilder 예제

Microsoft.Framework.Diagnostics
애플리케이션 실행 중에 발생하는 에러를 기록할 때와 컴포넌트의 실행 시 체크하기 위해서 COM+의 JITA 속성과 결합해서 사용되는 기능이다. 에러를 기록하기 위한 클래스로는 ErrorLog 클래스가 구현되어 있으며, 컴포넌트의 실행 시간을 기록하기 위한 클래스로는 ExecutionTimeLog가 구현되어 있다.

ExecutionTimeLog 클래스는 메소드를 실행하기 전에 Prepare 메소드를 실행해서 실행 시간을 기억해 두었다가 특정 처리가 끝난 뒤에 MeasureAndWriteLog 메소드를 호출해서 시간을 기록하게 된다. <리스트 6>은 ExecutionTimeLog의 구성 설정의 예를 보여주고 있다.

<리스트 6> ExecutionTimeLog의 구성 설정

ErrorLog 클래스는 WriteLogMessage 메소드를 이용해서 각각의 에러로그를 기록할 수 있다. 에러를 기록하기 위한 보편적인 모델은 각각의 계층에서 가장 상위의 계층으로 Throw해서 Application Error 이벤트를 통해서 에러로그를 기록하는 것이다. <리스트 7>은 에러를 처리하는 예를 보여주고 있다.

<리스트 7> 에러 처리 예

Microsoft.Framework.Utility
Utility 네임스페이스 문자열과 파일의 조작을 보다 쉽고 편하게 할 수 있도록 지원하기 위해서 구현한 네임스페이스이다. 하지만 Microsoft.Framework에서의 핵심은 데이터를 엑세스하는 부분이라서 그런지 이 부분의 구현은 조금 미흡하다는 생각을 가지게 될 것이다.

FileHandler 클래스에서는 바이너리와 텍스트를 불러온다거나 저장하는 메소드를 제공하고 있다. 그리고 StringEx 클래스에서는 원본 문자열 중에서 찾는 문자열의 위치를 얻어내는 메소드를 제공하고 있다. <리스트 8>은 FileHadler를 활용한 예를 보여주고 있다.

<리스트 8> FileHadler의 활용 예

프레임워크의 활용

프로젝트를 진행할 때 개발 표준 프레임워크는 필수적이다. 프레임워크는 개발 환경이나 해당 애플리케이션의 업무 환경에 맞도록 보통 맞춤 제작을 하게 된다. 앞에서도 이야기 한 것처럼 보통 이 과정에서는 기본 프레임워크에 맞춤 프레임워크를 올리는 작업을 하게 된다.

이때 중요한 것은 바로 확장성이다. 해당 환경이나 업무가 변화함에 따라 프레임워크도 그에 맞춰 쉽게 변경되거나 확장될 수 있어야 한다. 그래야만 살아있는 프레임워크가 된다.

보통은 공통 표준화팀에서 이러한 개발 프레임워크를 전담하게 되며, 이 팀에서 개발 프레임워크를 기초 설계 환경에 맞도록 만든다. 하지만 프로젝트를 진행 하다보면 처음에 예상하지 못했던 공통적인 기능을 추가하거나 새로운 환경이 추가되는 경우가 많이 발생한다.

이때 이러한 기능을 즉각적으로 개발 프레임워크에 추가하여 개발자들에게 재배포를 하여야만 한다. 그렇지 않다면 개발자들은 각각 자신만의 클래스를 만들어서 사용하게 될 것이고, 이러한 일이 계속되면 점점 프레임워크에서 멀어져가게 될 것이다.

즉, 처음에는 모든 기능을 프레임워크에서 찾아서 썼지만 나중에는 점점 자신만의 라이브러리를 추가해서 사용하게 되면 결국 프레임워크에 대한 의존도가 떨어져서 프레임워크를 통한 생산성 향상이나 코드 표준화는 이루어지지 못한다.

가끔 공통 표준화팀의 파워가 강해서 일반 비즈니스 개발자의 이러한 요구 사항을 무시하는 경우가 있을 수 있는데, 이런 사태는 막아야만 한다.

개발 프레임워크는 해당 업무 비즈니스 개발자로부터 끊임없는 피드백을 받아서 수정을 해야만 의존도가 높은 프레임워크로 만들어 질 수 있다. 그래야 비로소 프레임워크를 통한 생산성 향상과 코드 품질의 일관성을 얻을 수 있다.

닷넷 기반 프레임워크의 트렌드
자바 기반의 다양한 각종 프레임워크가 최근 닷넷 버전으로 많이 컨버전 되고 있다. 최근 프레임워크의 특징이라면 관점지향 프로그래밍(Aspect-Oriented Programming)과 IOC(Inversion of Control)기능이라고 할 수 있다. AOP는 업무 비즈니스 개발자가 비즈니스의 요구사항에 집중할 수 있도록 부수적인 기능들은 따로 구현하는 기법을 말한다.

핵심 관심사(core concerns)와 부수적인 횡단 관심사(cross-cutting concerns)로 나누어서 이들을 따로 구현한 다음에 나중에 하나로 합쳐주는 위빙(weaving) 과정을 거쳐 하나의 시스템으로 조립하는 기법이다.

닷넷에 보면 클래스나 함수 위에 기능을 설정하는 속성(attribute)을 지정할 수 있는데, 이 방법 또한 AOP의 한 방법이라고 할 수 있다. IOC는 제어의 반전이라고 번역하는데 이 용어 보다는 의존성 삽입(Dependency Injection)이라는 용어가 더 어울릴 것이다. 이것의 핵심은 이용으로부터 설정을 분리한다는 것이다.

클래스의 재사용성을 높이기 위해서 객체를 사용하는 측에서 만들 것이 아니라, 컨테이너가 설정 정보를 통해서 대신 만들어 주겠다는 개념이다. 이러한 개념들이 자바 진영에서 먼저 시작이 되었고, 이를 이용한 스프링(spring) 프레임워크 등이 닷넷 버전인 Spring.NET으로 발표되고 있다. @

MS닷넷 프레임워크 3.0

얼마 전까지 Ajax에 대한 열기 덕에 Atlas(지금은 Microsoft ASP.NET AJAX)가 개발자들 사이의 화두였다면, 요새는 닷넷프레임워크 3.0이 개발자들 사이의 최대 관심사이다. 이에 맞춰 닷넷 프레임워크 3.0에 대한 아티클들이 점차 올라오고 있고, MSDN 세미나도 줄줄이 열리고 있다.

많은 닷넷개발자들이 MS의 전략을 따라가면서도 ‘닷넷프레임워크 2.0이 발표된 지 얼마나 되었다고, 벌써부터 3.0이란 말인가?’라는 의문점을 가지고 있다. 그렇다면 MS는 왜 이렇게 발 빠른 행보를 하고 있는 것일까?

경쟁 대응을 위한 MS의 전략
MS의 민첩한 발걸음은 닷넷 개발자들의 요구 탓이 아니다. 자체적인 혁신에 의한 것 또한 아니다. 전적으로 사업적인 이유에서 이처럼 발걸음을 재촉하게 된 것이다. 예전에도 쟁쟁한 경쟁사들이 있어왔지만, 최근에 들어서는 경쟁 회사의 선전에 밀리는 듯한 모습마저 보이고 있다.

최신 사례로는 Microsoft ASP.NET AJAX가 그렇다. Ajax 열풍에 개발자들이 손쉽게 대처할 수 있도록 개발되었다고 생각하시는 사람들도 있으나(물론 이러한 이유도 내포되어 있다), 보다 현실적이고 근원적인 답안은 사업적인 이유이다(Ajax를 가장 많이 활용하고 있는 개발자들은 대개 자바 진영이고, IBM이 제일 열심히 밀어주고 있다).

닷넷 프레임워크 3.0도 이러한 선상에 있다. 그렇다면 MS는 무엇을 내다보고 있으며, 닷넷프레임워크 3.0을 통해 얻고자 하는 바는 무엇일까?

MS가 보는 소프트웨어 개발 트렌드
최신 자료에 의하면 MS가 내다보는 소프트웨어 개발 트렌드는 다음과 같다(용어는 필자가 번역하였다).

• 차등화 사용자 경험(Differentiated User Experience)
• 서비스 기반 개발(Service-Oriented Development)
• 비즈니스 프로세스 모델링(Business Process Modeling)
• 디지털 정체성 관리(Digital Identity Management)

누차 강조하지만 Ajax 열풍 이면에는 사용자 경험이 자리 잡고 있다. 기술적인 요소를 떠나 사용자 경험을 향상시키기 위한 대책으로 나온 것이 Ajax이다. Ajax 열풍 이후 많은 기업들이 사용자 경험에 중점을 두고 있으며, MS도 관련 자료를 조금씩 내놓고 있다.

서비스 기반 개발은 프로그래밍 형식이 변해감에 따라 나왔고, 단일 애플리케이션의 설계를 서비스 지향 아키텍처(SOA: Service-oriented architecture)의 개념을 적용한 개발방법론이다.

비즈니스 프로세스 모델링은 기업의 비즈니스 프로세스를 선진화된 표준 규약을 준수하여 설계하도록 함으로써 프로세스에 대한 명세 및 프로세스가 표출하는 데이터와 연계 지점을 명확하게 하여 프로세스 간의 통합이 가능할 수 있도록 하는데 있다. 작업흐름(workflow)을 대체하는 개념이다.

닷넷 프레임워크 3.0의 구성도
닷넷 프레임워크 3.0의 구성도를 간단하게 표현하면 다음 그림과 같다.

닷넷 프레임워크 3.0 구성도

닷넷 프레임워크 3.0은 기존 2.0에 WPF(Windows Presentation Foundation)와 WCF(Windows Communication Foundation), WF(Windows Workflow Foundation) 및 카드 스페이스(CardSpace)를 추가한 형태로 구성되어 있다.

WPF는 UI나 문서 및 미디어를 조합하는 차세대 스마트 클라이언트 응용 프로그램 구축을 위한 클래스를 제공한다. WCF는 서비스 지향 응용 프로그램 구축을 위한 통합 프로그래밍 모델 및 런타임을 제공한다.

또, WF는 비즈니스 프로세스를 모델링하는 워크 플로우에 사용 가능한 응용 프로그램 구축을 위한 프로그래밍 모델과 엔진 및 도구를 제공한다. 마지막으로 카드 스페이스는 개인 ID 정보를 이용한 온라인 작업에 대한 보안을 단순화하고 강화하는 기술을 제공한다.

이건 무엇을 뜻할까? 소프트웨어 개발 트렌드와 닷넷 프레임워크 3.0 구성이 무슨 관계일까? 그 답은 닷넷프레임워크 3.0이 바로 이러한 트렌드에 맞추어져 있다는 것이다. 정리해보면 구성요소 각각은 다음과 같이 대칭 한다.

• WPF ==> 차등화 사용자 경험
• WCF ==> 서비스기반 개발
• WF ==> 비즈니스 프로세스 모델
• 카드스페이스 ==> 디지털 정체성 관리

트렌드를 읽는 개발자
개발자도 트렌드를 읽을 줄 알아야 한다. 소프트웨어 개발 트렌드가 어떻게 흐르고 있는지 알아야 다가오는 미래에 대비할 수 있고, 하기에 따라 앞서갈 수도 있다. 현재 주어진 업무에 치여 트렌드를 읽을 수 없다면, 당분간은 별 문제가 없겠지만 패러다임이 변화되었을 때에는 여러 어려움을 겪게 된다.

다행히도 MS에서는 이러한 트렌드를 분명하게 인지하게 해주기 때문에 의미하는 바가 무엇인지 알아야 한다.

트렌드에 대비하는 개발자
닷넷 프레임워크 3.0을 보고 '이게 뭐야?'하며 다소 실망하시는 사람들도 있지만, 대부분은 ‘어떻게 대비해야 할까?’를 고민하고 있다. 개인적으로도 명확하게 답해 주고 싶지만, 아쉽게도 아직까지는 그럴 수 없다. 필자 자신도 각 사항에 대해서 고민해보는 시간들을 가져야 한다.

그럼에도, 긍정적으로 권면할 수 있는 것은 닷넷 프레임워크 3.0은 소프트웨어 개발 트렌드를 반영하여 바람직한 방향으로 나아가고 있다는 점이다. MSDN과 세미나 등 다양한 방법을 통해 자료들이 나오고 있기 때문이다. 아직은 대비할 시간이 충분하다. 심적으로 부담스러워하지 말고, 조금씩 하지만 꾸준히 닷넷 프레임워크 3.0의 세계로 나아가보자.

그럼 여기에서 Microsoft ASP.NET AJAX("Atlas")는 어떻게 되냐고? ASP.NET 2.0에 통합되므로, 닷넷 프레임워크 3.0에서는 추가적인 설치 없이도 사용 가능하다는 것이 답이다.

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.