Visual Studio 2010! 나랑 놀아보자 – 기본편 (4회)

Visual Studio 2010! 나랑 놀아보자 – 기본편 (3회)

Visual Studio 2010! 나랑 놀아보자 – 기본편 (2회)

Team Foundation Server 2010 은 많은 부분 획기적인 변화를 가져왔습니다. 기능적인 부분은 더할 나위 없거니와 관리적인 부분은 이전 버전을 운용해 보신 분이라면 과히 편해졌다고 할 수 있습니다. AT(Application Tier) 와 DT(Database Tier) 전반적인 부분에 걸쳐 한 자리에서 관리적인 부분을 모두 커버할 수 있기 때문입니다.

하지만, Team Foundation Server 2010 의 새로운 기능 중의 Test & Lab 부분이 상당히 강력해졌지만, 새로운 플랫폼과의 결합과 새로운 개념 등으로 환경 구축이 쉽지만은 않습니다. 필자도 이러한 부분에서 많은 부분 시행 착오를 겪으며 정리한 내용을 공유하고자 합니다.

Team Foundation 의 운용을 어렵게만 느끼지 마시고, 문제가 발생하면 바로 아래의 링크를 통해서 확인해 보는 것도 좋은 방법일 것 같습니다.^^

이 문서는 지속적으로 업데이트 될 예정입니다.

마지막 업데이트 : 2010-04-06

Test & Lab Manager

[HowTo] 가상 Lab 환경의 가상 머신 시작하기
[HowTo] Lab Manager 환경 구성 중 TF260078 오류 해결하기
[HowTo] 가상 Lab 배포 중 오류 해결하기 TF259115
[HowTo] Lab Manager 에서 가상 Lab 환경 만들기

Visual Studio 2010

[HowTo] Work Item 쿼리를 Excel 로 내보내기 할 수 없는 경우 TF80012 에러

Team Foundation Server 2010

[HowTo] Team Foundation Server 2010 FQDN 설정 방법
[HowTo] TFS 설치 중 Reporting Services 관련 오류 Error 28805
[HowTo] Team Project Collection 옮기거나 복원하기 TF246081
[HowTo] TFS 2005/2008 데이터베이스를 TFS 2010 으로 마이그레이션
[HowTo] Team Project Collection 이름 변경하기

System Center Virtual Machine Manager

[HowTo] SCVMM 에서 암호화된 파일 전송을 사용하지 않으려면?
[HowTo] SCVMM 라이브러리 템플릿 만들기
[HowTo] SCVMM 의 라이브러리 템플릿 배포 작업이 무한 대기할 경우

본 원고는 월간 마이크로소프트 2010년 3월호에 기고한 원문입니다.

Visual Studio 2010을 활용한 ALM(Application Lifecycle Management)

작성자: 엄준일 선임/ Microsoft MVP

감수자:안재우 수석/Microsoft MVP

ALM(Application Lifecycle Management) 의 개요

최근 몇 해 사이에 ALM(Application Lifecycle Management)라는 용어를 자주 듣게 되었고, ALM에 대해 논의를 하게 되고, ALM 을 해야 한다라는 말을 자주 듣게 됩니다. 최근 들어, 실제로 많은 기업이나 조직에서 ALM 도입을 검토하고 있고, 왜 ALM에 대해 열광하는지에 대해서도 궁금한 부분이 아닐 수 없습니다. 그렇다면 우리는 이제 ALM이 무엇이고, 왜 등장하였으며, ALM에 대한 오해와 진실에 대해서 충분히 이야기를 나눌 가치가 있다고 생각합니다.

ALM 이란?

ALM(Application Lifecycle Management, 이하 ALM)을 한글로 번역하면 "응용프로그램 수명주기 관리" 라고 합니다. 현대 사회는 문화, 언어, 가치관, 기술 등이 빠르게 발전하고 있습니다. 문명의 발전이 없다면 죽은 문명이고, 마찬가지로 소프트웨어가 변화하고 발전하지 않으면 죽은 소프트웨어나 마찬가지 입니다. ALM 을 쉽게 말하면 바로 이런 소프트웨어가 생산되고 릴리즈, 유지, 관리하기 위한 기술을 총칭합니다.

ALM 등장배경

예전부터 소프트웨어를 개발하는 방법이 꾸준히 연구되었으며, 그 중 가장 대표적인 방식이 SDLC(Software Development Lifecycle) 입니다.

SDLC 의 대표적인 개발 방법론 중에 폭포수 모델(Waterfall Model)이 있는데, 로이스(Royce) 라는 사람에 의해 정의된 폭포수 모델은 요구사항, 디자인, 구현, 통합, 테스트, 릴리즈, 유지보수라는 단계로 구분이 되며, 각 단계는 순차적으로 진행되게 됩니다. 요구 사항이 없으면, 디자인을 할 수 없고, 디자인을 하지 않으면 구현을 할 수 없는 형태의 개발 방법으로 현 단계에 문제나 오류가 발생하게 반드시 위험 요소를 제거한 후에 다음 단계로 이동하게 됩니다. 이러한 개발 방법은 각 단계별로 상하 연관성이 없고 명확하게 구분되어 있으며, 최근에도 이러한 개발 방법으로 많은 프로젝트가 진행됩니다.

그림 1 일반적인 폭포수(Waterfall) 모델

하지만 최근 이러한 Top-Down 방식의 수직적인 개발 방식에 많은 비판을 받고 있습니다. 초기 계획이 완벽하지 않으면 전체 일정 또는 계획이 완벽하지 않다는 의미이기 때문입니다. 고객도 자신의 정확한 요구 사항을 알지 못합니다. 이런 과정에서 프로토타입(Prototype) 을 고객에게 시연하고 고객의 정확한 요구 사항을 도출해야 합니다. 하지만 고객의 요구 사항은 언제나 변할 수 있습니다. 즉, 완벽한 요구 사항을 정의한 후에, 다음 단계로 넘어간 이후에도 고객의 요구 사항은 변할 수 있고, 그렇다면 어찌되었건 초기 계획이 잘못될 수 밖에 없습니다. 이미 구현과 테스트로 검증이 끝난 기능에도 기능적인 기능의 추가 및 변경, 디자인 요소의 변경 등을 이유로 고객의 요구 사항은 변할 수 있고, 그렇다면 다시 원점으로 돌아가 이전의 계획은 수정이 되어야 하며, 이미 이러한 경우는 최초 계획이 잘못되었다고 생각할 수 밖에 없습니다.

그 이외에도 초기 계획을 얼마나 정확하게 수립할 것인지는 굉장히 민감한 문제이기도 합니다. 초기 계획 단계를 지나치게 명확하게 강조할 경우 그만큼의 비용이나 시간이 추가되는데, 전체 프로젝트의 일정과 대비하여 그것이 지나칠 경우 실제로 구현이나 테스트를 해야 할 시간은 촉박해 질 수 밖에 없습니다. 프로젝트의 기간은 6개월인데 정확한 프로젝트의 계획 수립을 위해 3개월의 시간을 소비한다면 분명 구현이나 테스트를 여유 있게 할 수 없을 것입니다. 고객을 이해시킬 수 있는 신뢰된 계획안을 보여줄 수 있겠지만, 오히려 불필요한 문서의 양산할 수 있을 가능성이 충분합니다. 이런 경우 프로젝트의 단계별로 거꾸로 기간을 산정하는 역산법 등을 이용하기도 합니다.

폭포수 모델(Waterfall Model)은 여러 가지의 문제 제기를 통해 다양하게 변형된 모델로 발전해 왔습니다. 여기에서는 설명하지 않을 예정이지만, 소프트웨어 개발 방법론은 여러 가지 변형된 형태로 발전해왔음을 알 수 있습니다.

• Spiral model
• Iterative and incremental development
• Iterfall development
• V-Model
• Agile software development

그렇다면, ALM 의 등장 배경을 얘기 하기 위해 왜 이렇게 긴 SDLC(Software Development Lifecycle) 이야기를 했을까요? 위의 이야기에서 볼 때 SDLC 는 바로 소프트웨어를 개발하기 위한 방법론이라는 것입니다. SDLC 는 소프트웨어 공학에서 정의하는 용어로써, 소프트웨어를 효과적으로 개발하기 위한 다양한 방법을 이야기 한다는 것입니다. 즉, SDLC 은 소프트웨어를 개발하는 기술적인 관점을 이야기 합니다.

ALM 은 바로 소프트웨어를 개발하기 위한 기술적인 관점과 더불어 비즈니스적인 가치를 융합하도록 합니다. 소프트웨어의 개발은 기술적이거나 방법적인 문제와 더불어, 실제로 조직 간의 이해 관계, 그리고 비즈니즈 관계의 영역까지 확대됩니다. 소프트웨어를 개발하기 위해 프로젝트의 비전이나 목표 그리고 이것을 이행하기 위한 여러 방법론적인 단계는 통합되고 유기적인 관계입니다. 단지 기술적인 관점에서 바라보는 것이 아닌, 비즈니스 관점에서의 이해 관계나 조직의 측면도 ALM 에서 포괄하고 있습니다.

그렇다면 ALM 은 전혀 새로운 기술이 아님을 알 수 있습니다. ALM 은 이미 오래 전부터 조직적으로 알게 모르게 수행하였고, ALM 을 수행하기 위해서는 어떠한 프로세스적인 요소를 강제하고 있었습니다. 마치 군대에서 기상->아침 구보->보고(점호)->아침 식사-> … -> 저녁 식사->청소->보고(점호)->취침 과 같이 매일 반복되는 프로세스와도 유사할 수 있습니다. 그리고 이런 프로세스가 잘 진행되는지의 여부를 알기 위해 상사에게 "보고" 하는데 소프트웨어 개발 측면에서는 각종 산출물이나 보고서가 필요합니다. 그리고 병사들이 야간 근무를 교대하고 활동을 추적하기 위해 교대 시간마다 기록을 하게 됩니다.

표 1 ALM 의 3대 구성 요소

하지만, 이러한 일련의 통일되고 융합된 활동을 한다는 것은 쉽지 않습니다. 문서화나 정형화된 프로세스조차 없는 팀이나 조직이 있는 경우도 있고, 암묵적인 프로세스가 존재하지만 어쨌든 이런 프로세스를 강요한다는 것은 쉽지 않습니다. 또한 팀의 매니저 또는 PM(Project Manager) 나 그 위의 상부 조직은 일이 잘 진행되는지 궁금해 하기 때문에, 이러한 이유로 개발자는 팀장 또는 상사에게 일일 보고서나 주간 보고서를 작성하고, 이것을 다시 취합하여 최종 보고서로 작성합니다. 프로젝트의 단계가 진행될수록 보고서의 양은 늘어나고, 그 종류도 다양해질 것입니다. 어찌 보면, 프로젝트를 위한 프로젝트가 아닌, 보고서를 위한 프로젝트가 되어버리는 셈입니다.

이젠 활동이나 작업을 추적하는 것도 어려울 것입니다. 수십 수백의 여러 가지 종류의 보고서는 이제 버전 관리 하기 조차 버거워질 수 있습니다. 또한 각 역할 담당자들은 결과물, 인도적 차원, 유지보수 차원에서 다양한 산출물을 양산해 냅니다. 필요에 의해 과거의 산출물을 찾는 것도 어렵고, 산출물 자체를 유지 보수 하는 것도 어려워 집니다. 그 외에도 변화하는 모든 활동들은 어떻게 변화했는지조차 알 길이 없습니다. 다양한 산출물과 활동, 그리고 변화에 대한 추적이 불가능 하다면 이미 양산된 문서를 관리하는 것은 결국 의미 없는 활동일 수 있습니다. 실제로 컨설팅 의뢰로 기업을 방문하여 문제를 진단하기 위해 몇 가지 산출물을 요청하여 받은 적이 있으나, 아키텍처가 실제 시스템과 너무 달랐고, 언제, 어떻게 달라졌는지 아는 사람은 아무도 없었던 적도 다반사이기도 합니다.

ALM 의 3대 구성 요소를 조직 전반적으로 융합하기 위해서는 ALM 솔루션이 필요합니다. 관리가 어렵고 정확성을 요구하는 ALM 을 좀 더 쉽게 실현할 수 있는 도구가 필요하다는 것입니다. 초기의 ALM 은 마케팅적인 용어로 사용되면서 초기 ALM 솔루션도 매우 난해했습니다. 단순히 이슈 추적 기능과 소스 제어 기능을 합하여 ALM 이라고 하였으며, 어떤 ALM 솔루션은 테스팅 도구만을 통합하여 ALM 솔루션이라고 하기도 하였습니다.

그림 2 ALM 의 전체적인 컨셉

최근에 ALM 이 정착하는 단계에 들어서면서, 현재의 ALM 과 미래의 ALM 을 분류하기도 합니다. 그리고 아직 이러한 분류 단계는 미성숙한 단계이므로 여러 방면으로 각기 해석을 하고 있습니다. 내용을 정리해 보면 아래와 같이 요약할 수 있습니다.

표 2 ALM 의 단계별 정의

위의 내용으로 볼 때, 앞으로 알아볼 Visual Studio 2010 과 Team Foundation Server 2010 은 이미 ALM 2.0 에 매우 근접해 있습니다. 기본적인 ALM 1.0 요소를 충분히 충족하고 있으며, 각 제품은 확장성이 뛰어나고 다양한 클라이언트를 지원하기 위한 크로스 플랫폼을 실현하였습니다.

ALM 의 오해와 진실

ALM 은 아직까지도 많은 오해와 진실 속에 자주 언급되는 용어입니다. 사실 ALM 을 알고 보면 SDLC(Software Development Lifecycle) 처럼 정형화된 어떤 유형의, 또는 무형의 지식으로 갑자기 나타난 기술이 아닙니다. 그리고 무언가를 해결하기 위한 완벽한 솔루션도 아닙니다. 아직도 마치 ALM 에 대해 뜬 구름 잡는 듯한 느낌이 든다면 아래의 몇 가지 질문 답변 형식으로 좀 더 ALM 에 대해 오해와 진실을 이야기 해보도록 하겠습니다.

Q: 그럼 도대체 ALM 은 무엇인가요?

A: 마치 Web 1.0 과 Web 2.0 을 비교하는 것과 같습니다. 기존 Web 1.0 은 기업이나 서비스 제공자에 의해 제공되고 그 주체가 바로 기업이나 서비스 제공자였습니다. 하지만 Web 2.0 의 컨셉은 개방, 협력, 참여, 공유라는 요소를 중심으로 차츰 주체가 사용자에게로 이동하는 트랜드화된 용어이기도 합니다. Web 2.0 의 대표적인 것이 바로 UCC 나 위키피디아(Wikipedia) 와 같은 것들이 있습니다.

ALM 도 이런 트랜드에 크게 벗어나지 않는 용어입니다 ALM 은 궁극적으로 3대 구성 요소를 쉽게 실현할 수 있도록 하였지만, 이것을 실현하기 위해 설계, 개발, 테스트, 유지 보수 등 개발 조직, 운영 조직, 비즈니스 조직 등 여러 조직간에 의사 소통이나 각 단계별로 독립적인 활동을 유기적으로 통합하고 신뢰할 수 있는 데이터를 제공할 수 있도록 ALM 솔루션은 여러 가지 도구와 연동하거나 통합하고 자동화하였습니다.

최종 소프트웨어를 사용할 고객은 품질 좋은 소프트웨어를 사용하길 기대합니다. 요구 사항, 아키텍처, 개발, 테스트, 릴리즈, 유지 및 관리, 추적 등 모든 과정을 ALM 솔루션 안에서 이루어 집니다. 이후에 설명한 Visual Studio 2010 과 Team Foundation Server 2010 을 이용하여 개발 프로세스가 어떻게 개선되고 편리해지며, 어떻게 ALM 을 실현하는지에 대해 천천히 짚고 넘어갈 예정입니다.

Q: 그럼 ALM 을 실현하려면 ALM 솔루션이 필요한가요?
A: 아닙니다. ALM 을 실현하기 위해서 반드시 ALM 솔루션이 필요하지 않습니다. 위에서 군대를 예로 든 ALM 의 3대 구성 요소를 설명한 바 있습니다.

실제로 여러 프로젝트를 경험하면서 ALM 과 유사한 경험을 많이 해 보았을 것입니다. UML 도구를 사용하고 엑셀로 요구 사항이나 개발 진행 관리, 그리고 엑셀의 함수나 스크립트를 이용하여 보고서를 만들고, 테스트와 테스트 문서 및 코드 리뷰 과정을 수동적으로 한 바 있습니다. 사실 관리적인 부분만 본다면 엑셀만큼 뛰어난 도구도 없을 것입니다.

하지만 실제로 수동적인 ALM 실현은 많은 어려움이 따릅니다. 가장 먼저 문서를 매번 업데이트해야 하는 시간적인 문제와 문서의 버저닝(Versioning), 변화에 따른 계획의 수정 및 문서 수정, 테스트를 위한 테스트 케이스 관리 및 테스트 결과 문서화, 그리고 수동적인 코드 리뷰는 사실상 있으나 마나 한 단계이기도 합니다. 특히 반복적인 짧은 릴리즈는 밤을 새게 하는 주요 원인 중의 하나이기도 합니다. 릴리즈 계획도 문제였지만, 버그의 발생은 곧바로 버그의 상황을 문서로 만들어져야 하는 산출물이 되기도 하기 때문입니다.

분명 ALM 솔루션은 여러 가지 어려웠던 요소들을 통합하고 자동화하였습니다. 결과적으로 ALM 은 도구가 없이도 가능하지만, 실현하기 위해서 훨씬 많은 노력이 필요하다는 것입니다.

Q: 우리 팀은 형상 관리(소스 제어) 만으로도 프로젝트가 잘 됩니다. 과연 ALM 솔루션이 필요한가요?

A: 맞습니다. 현재 자신의 팀이나 조직에서 정형화된 프로세스나 암묵적인 프로세스가 존재하고, 개별적인 문서 관리와 소스 제어만으로 ALM 을 실현할 수 있습니다. 그렇다면 현재 자신의 조직이나 팀은 ALM 레벨은 ALM 0.5 세대에 있다고 보시면 됩니다.

소프트웨어의 품질을 높이기 위해서는 많은 노력이 필요합니다. 소스 코드나 문서의 버전 관리, 테스트, 보고서, 빌드, 이슈나 작업의 추적은 한 두 명의 개인이 수행하기는 매우 힘듭니다. 그렇기 때문에 보다 도구를 통합하고 자동화된 솔루션을 통해 ALM 을 수행한다면 훨씬 많은 이점이 있습니다.

Q: 그럼 ALM 을 원활하게 수행하기 위해서는 통합된 ALM 솔루션이 필요한가요?

A: 그렇지 않습니다. 현재 소프트웨어를 개발에 필요한 많은 도구들이 오픈 소스 또는 무료로 제공이 되고 있습니다.

아래는 오픈 소스 중에 .NET 환경에서 사용할 수 있는 도구들을 정리한 표입니다.

표 3 Team Foundation Server 와 오픈 소스 기반의 도구를 통한 ALM 도구 비교

하지만 오픈 소스를 사용하는 것은 저렴하게 ALM 환경을 갖출 수 있지만, 이음매 없는 매끈한 끈과도 같습니다. 도구들 간에 서로 연관성이 없거나 업그레이드가 되지 않는 것들도 상당히 존재하기 때문입니다. 통합되지 않은 각 도구들은 누가 관리를 할 것이며, 연관성이 없는 각 도구들 간의 프로세스를 어떻게 강요할 것인가도 고민해 보아야 할 부분입니다.

안녕하세요. Visual Studio 2010 팀입니다.
이제 다가오는 2010년 4월 12일은 Visual Studio 2010 정식 버전이 출시되는 날입니다.
이에 맞추어 저희 팀과 함께 활동하실 에너지 충만한 분들을 모집하고자 합니다.

지원 분야

• Visual Studio 2010
• .NET Framework 4.0
• Cloud Development
• Parallel Development
• Web Development
• Windows 7 Development
• RIA Development
• Architecture Development
• Agile Development
• Office Business Application Development
• Team Foundation
• Windows Mobile 7
• User Experience (UX)
• 기타 .NET 과 관련된 모든 분야

활동 영역

온라인 활동 영역

오프라인 활동 영역

지원 방법

umc골벵이dotnetxpert.com 으로 아래의 양식으로 메일 보내주세요.

애자일에 대한 고찰에 앞서 먼저 '정말 TDD 가 필요한가?' 에 대해 이야기 부터 시작해봅니다.

애자일에 대한 고찰

애자일 프로그래밍이 도마에 오르면서 단연 단위 테스트(Unit Test)와 TDD(Test Driven Development) 를 빼놓을 수 없습니다. 단위 테스트와 TDD는 상호 공생 관계에 놓이면서, 둘 중 어느하나 포기하기 쉽지 않습니다. 왜냐하면 TDD에 대한 이상론자들은 TDD의 중요성을 매우 높이 강조하고 있기 때문입니다.

필자는 이에 대해 정말 개발에 TDD가 얼마나 좋고 효과가 좋은지 사실 산술적으로 검증할 수는 없다고 생각합니다. 좋은 것이 있는 많큼 잃는 것도 있을테니까요.

TDD 를 해야한다는 관점

일반적으로 코드를 작성한 후에 그 기능을 테스트하는 코드를 작성하는 것을 단위 테스트라고 합니다. 단위 테스트를 작성함으로써 결함없는 소프트웨어를 만들기 위한 지속적인 통합(CI-Continuous Integration) 라는 관점에서 상당히 효과적인 방법입니다.

여기에서 TDD 는 단위 테스트를 작성하는 단계의 순서를 기존의 Last 에서 First 로 바꾸면서, 단위 테스트 코드를 먼저 작성하도록 하는 방법입니다. 처음 오류가 날 수 밖에 없는 코드를 테스트하면서 Red, Green, Refactor 단계로 옮겨가도록 하는 기법입니다.

사실 이런 저런 TDD 의 효과중에 단연, 코드가 매우 견고해진다는 큰 장점이 있습니다.    

처음부터 기능을 구현하는 코드를 작성하게 된다면, 클래스와 메서드를 잘 분리한다고 하더라도 한 클래스나 메서드는 생각지도 않게 기능의 크기가 커질 수 밖에 없습니다. 왜냐하면 코드 작성자는 코드를 만드는 목적이 기능이 정상적으로 작동해야 한다는 전제하에 코드를 만들기 때문에 오류 없는 코드가 목적이기 때문입니다.

또 한가지 TDD를 하지 않는다면 코드의 리팩토링을 코드가 완료된 이후에만 가능하다는 것입니다. 지속적으로 이런 문제는 소프트웨어의 디자인이 바뀌거나 오류가 발생하지 않을 경우 굳이 리팩토링을 하지 않게 되죠.

결국 어떤 이유에서든지 좋은 코드를 만들기 위해서는 TDD가 매우 좋은 기법이 될 수 있습니다. 쉽게 Database 를 예로 들자면, 초기에 테이블을 정규화할 것인지, 나중에 문제가 생길 경우 정규화를 할 것인지의 고민과 유사하기도 합니다. 하지만 절대 변하지 않는 진리는, 처음부터 갈귀갈귀 정규화를 한 것을 합치는 것은 쉬워도, 통짜를 분리하는 것은 사실 엄청난 리스크가 됩니다.

TDD 를 하지 말아야한다는 관점

개인적으로 필자는 이 부류에 속하기도 합니다. 누구든 TDD를 알게 되면 그것이 가지는 이상적인 효과를 이해할 수 있습니다. 하지만 살짝 TDD에 발가락을 담구어보면 금방 TDD에 대해 의심을 하게 됩니다. 바로 TDD를 해보면 너무 어렵다는 것입니다.

첫번째로 Red, Green, 그리고 최종적으로 Refactor 단계로 가는 과정이 오래 걸리고 어렵습니다. TDD코드를 만들기 시작하는 순간부터 리팩토링의 시작이며, 길지 않은 코드조차 굉장히 버겁다는 것을 알 수 있죠. 정말 지루하고도 기계적인 과정입니다.

두번째는 이미 언급했다시피 지루하고도 기계적인 과정입니다. 즉 TDD기법으로 생상되는 코드는 기존에 코드를 만들고 테스트하는 예상 시간이 +a 가 됩니다. 코드의 양에 비례하여, 'stub(코드의 양) * alpha(가중치) = TDD 수행시간' 이라는 대략적인 예측 소요 시간이 걸릴 것입니다.

TDD의 시작은 곧 리팩토링의 연속입니다. 아무리 개발 도구가 좋아진다고 하더라도 사람이 하던 리팩토링을 대신해줄 수는 없을 것입니다. 즉, TDD기법을 도입하기 위해서 기존 방식의 산술적인 계산법으로 더 이상 기간과 공수를 예측할 수 없습니다. 분명 시간과 비용이 터무니없이 증가할 것입니다.

아마도 우리나라에서는 TDD를 조직내에서 개발 방법으로 채택하는 곳은 없다고 봅니다. 우리나라에서는 소프트웨어의 생산 기간을 어떻게 줄일까에 집중하고 있기 때문에, TDD는 팀과 조직의 goal 에 방해 요소만 될 뿐입니다. 효용성 측면에서 TDD를 본다면 그저 빛 좋은 개살구로 보이기 쉽기 때문입니다.

애자일을 명목으로 스스로 족쇄를 차고있는 우리 조직

애자일이라는 이름과 이상적인 가이드를 이행하려는 조직에서 특히 불화음이 많을 것입니다. 그리고 그들은 애자일을 해 본 결과 애자일은 왜 실패하냐는 물음을 던집니다. 사실 애자일이 가지는 그 사상은 굉장히 높이 살만 합니다. 기존의 폐쇄적인 조직을 개방하려는 의지를 보인다는 것으로 시작하여 팀간의 커뮤니케이션을 향상시키도록 합니다.

그런데 애자일을 도입하려는 사람들은 큰 함정에 빠집니다. 팀을 위한다는 명목으로 너무 많은 것을 팀에게 강요합니다. 자신이 바라보기엔 좋은 기법들이 많고 팀에게 전파하려고 노력하겠지만, 팀은 이미 기존에도 잘 되고 있는 부분을 왜 뜯어고치려는지 이해할 수 없기 때문이죠. 팀에게 변화라는 명목으로 팀원들의 공감을 얻지 못한채로 강요를 시작하게 됩니다.

사실 애자일한 팀과 애자일한 프로그래밍을 위해 애자일은 아무것고 강요하지 않습니다. 그런데 누군가의 손에 애자일이 쥐어지면 은근히 강요로 변질되는 경우가 대부분입니다.

애자일 중에, 특히 XP(eXtreme Programming) 는 우리나라 실정이 전혀 반영되지 않았습니다. XP 의 여러가지 기법 중에 특히 코드 리뷰 와 짝 프로그래밍이 대표적이죠. 짝 프로그래밍은 짝이 되어 서로의 생각과 노하우를 전수해 주는 기법이지만, 필자로써는 '글쎄…'

필자는 오히려 짝 프로그래밍을 함으로써 개인 업무 시간을 너무 할애당한다는 생각이 듭니다. 필자가 메신저의 채팅보다 이메일을 좋아하는 이유도 여기에 있습니다. 업무 진행에 탄력을 받다가도 채팅으로 내 생각의 컨텍스트가 강제로 전환됩니다. 생각이 정리되지 않은 상대편이 타자를 치고있는 것을 멍하니 바라만 봅니다. 기술적인 것을 물어볼땐 답을 알려줘도 채팅이라는 특성상 한번에 한줄의 글로 모든 것을 표현하기가 힘듭니다. 만약 이메일이었다면 보낸 사람도 생각을 정리해서 보냈을테고, 또한 내가 보고싶을 때 보고, 명쾌한 MSDN 링크와 곁들여 오히려 짧은 시간에 높은 성과를 낼 수 있을텐데요...

결국 짝 프로그래밍은 그것을 성취한 후의 성과가 소비된 리소스에 비해 턱없이 낮으며, 짝 프로그래밍의 특성상 지속성을 유지하기에 한계가 있습니다.

또, 코드 리뷰를 진행하기 위해 다양한 기법들과 절차를 선보입니다. Self Review, Pair Review, Team Review 등 전혀 현실을 고려하지 않고 단지 그 기법들에 대해서만 매달리는 사람들이 많습니다. 특히 코드 리뷰는 도구를 이용한 자동화를 하지 않을 경우 있으나 마나한 기법입니다. 장기적으로 코드 리뷰는 형식적일 수 밖에 없습니다.

더 중요한 것은 코드 리뷰 기법이 아니라, 프로세스적으로 이것을 통제하여 코드 리뷰 책임자를 두는 것이 효과적일 수 있습니다. 보안이나 성능 등에 관련하여 코드 리뷰의 책임을 위임하고, 보안이나 성능 문제 발생시에 책임을 물을 수 있도록 체계화된 프로세스 말입니다.

사실 이런 면에서 기존의 애자일인 XP(eXtreme Programming) 이나 스크럼(Scrum) 보다 MSF(Microsoft Solution Framework) 가 기존 애자일 방법론을 현실적이고 수행가능하도록 체계화시킨 프로세스이기도 합니다.

입장이 서로 다른 애자일

대부분 현장에서 개발하시는 분들은 내 옆의 동료나 우리 팀보다 자기 개인이 더 중요할 것입니다. 개인 업무 성과가 팀과 조직이 나를 판단하는 기준이 대부분의 경우이기 때문입니다. 또 어떤 경우는 개발자의 특성상 발언권이 없는 경우도 있을 것입니다.

이에 반해 팀의 관리자의 평가는 자신이 관리하는 팀 전체의 성과가 조직이 관리자를 판단할 것입니다. 팀 프로젝트나 팀의 업무 성과가 낮다는 것은 관리자의 능력과 비례하기도 합니다.

결과적으로 애자일이라는 공통 분모로 애자일의 목표를 이루고자하는 시각이 전혀 다르다는 것이죠. 서투른 애자일은 팀원의 불만만 증가할 뿐, 팀원과 공감대를 이루기 힘듭니다. 관리자의 입장에서는 팀원간의 커뮤니케이션을 높이고 팀원 스스로 변화하길 기대하고 이것이 소리없는 강요가 될 수 있습니다.

애자일을 성공시키기 위해

앞서 이야기한 바와 같이 애자일이라는 목표와 사상은 굉장히 좋습니다. 그것이 팀과 조직뿐만 아니라, 개인, 가족, 단체, 사회, 국가적으로 비유해도 좋은 모델이 될 것입니다. 하지만 애자일, 특히 XP 가 이루는 그 구성 요소들은 조금은 허무맹랑한 것들이 많습니다. TDD나 짝 프로그래밍, 코드 리뷰 등 현실성이 부족한 것들을 이행하기를 권장합니다. 적어도 우리나라에서는 그것을 이행하기 위한 주변 여건이 좋지만은 않지요.

예전 트로이 목마라는 전쟁 이야기에서 나오듯이, 적진에게 해를 가하기 위해 트로이 목마를 적진에게 가져다 놓았습니다. 적진은 트로이 목마를 보며 마치 신이 주신 선물로 생각하겠지만 정작 트로이 목마는 적군에게 해가 되는 무시무시함을 가졌습니다.

과학에서 모든 물체는 현재 상태를 유지하려는 힘, 관성을 가지고 있듯이 우리의 팀과 조직도 마찬가지 입니다. 애자일도 마찬가지로, 그것이 좋아보인다고 자신의 팀과 조직에 구역구역 쑤셔넣다보면 상태를 유지하려는 관성을 가진 구성원과 바로 맞닿을 수 있습니다. (물론 애자일이 해를 가한다는 의미는 아닙니다)

애자일이 추구하는 여러 구성 요소는 짧은 반복으로 결과물의 품질을 높이고 결함을 줄이고자 합니다. 애자일의 대부분의 구성 요소는 짧은 반복으로 인한 높은 위험성을 줄이기 위한 보조적인 수단이라는 것입니다. 예를 들면, 스크럼(Scrum) 을 도입한다고 해서 대시보드와 붙이는 메모지를 준비하고, 매일 매일 스크림 미팅을 할 필요는 없습니다. 스크럼 미팅이라는 형식에 갇히는 순간부터 자멸의 길이라는것을 뒤늦게 깨닳게 될 것입니다. 즉 스크럼 미팅은 매일할 필요도 없으며 어떤 다른 모습으로 바뀔 수 있고, 동료와 담배를 피거나 커피를 먹으면서 알게 모르게 나타날 수도 있습니다. 어떤 경우는 상대편 알게 모르게 하는것이 자연스러운 참여에 도움이 되는 경우도 있지요.

결론적으로 팀과 조직, 구성원 개인의 차이를 인정하고, 팀과 조직의 문화를 최대한 존중하는 것이 성공하는 애자일이 되는 것입니다. 필자 또한 이것을 깨닿기까지 많은 시행 착오를 겪으며 애자일로 인한 물음표에 종지부를 찍을 수 있었습니다. 즉, 애자일로 스스로에게 족쇄를 차지 마십시오. 족쇄를 끊은 후에야 진정한 애자일이 당신의 곁에 있음을 느낄 수 있을 것입니다.

.NET Framework 4.0 에 포함될 MEF(Managed Extensibility Framework) 은 컴포넌트를 조합하는 방식으로 컴포넌트의 재사용성과 보다 컴포넌트를 동적으로 사용할 수 있는 프레임워크입니다.

하 지만 MEF 는 기존에 제네릭 타입(Generic Types) 을 지원하지 않습니다. 이미 C# 2.0 부터 지원하는 Generic Type 을 MEF 에서 지원하지 않는 것도 참 아이러니 합니다. 여기에 대한 내용은 아래의 링크를 참고하십시오.

MEFGeneric 이란?

안타깝게도, MEF 에 Generic Type 을 지원하기 위해 적당한 대안이 아직 전세계적으로도 없다는 것입니다. Microsoft 의 MEF 개발 팀 리더도 MEF V1.0 버전에는 지원하지 못할거라고 합니다. 

http://codebetter.com/blogs/glenn.block/archive/2009/03/21/why-doesn-t-mef-support-open-generics-for-exports-because-mef-is-not-type-based.aspx
http://codebetter.com/blogs/glenn.block/archive/2009/08/20/open-generic-support-in-mef.aspx

MEFGeneric 은 전세계적으로 처음으로 정식으로 Generic Type 을 지원합니다. 세계 최초로 한국에서, 그리고 닷넷엑스퍼트에서, 그리고 나로부터 문제를 해결하니, 로또 맞은 기분이네요.

MEFGeneric 은 기존의 MEF 를 Core(코어) 소스 코드를 수정/확장하여 Generic Type 을 지원하도록 하였습니다. 필자는 이 소스 코드를 codeplex 사이트를 통해 공개하였으니, 아래의 사이트를 참고하세요. ^^

때는 바야흐로 2009년 7월이네요. Velocity 를 공부하면서 메모해 놓은 것을 이제서야 발견하여 포스팅을 하고 있습니다. ^^;

현재는 Windows Server AppFabric 이라는 이름으로 공개가 되고 있으며, 코드명은 바로 "Velocity" 라는 이름입니다. 현재 AppFabric Beta 1 까지 출시되었고 이제는 거의 모습을 찾아가고 있는 것 같습니다. 차후에 Velocity 의 현재 제품이름인 AppFabric 을 자세히 살펴보기로 하며, Velocity CTP 3 기준으로 설치와 사용 방법을 간단히 알아보고자 합니다.

Why Windows Server AppFabric (Codename "Velocity") ?

Velocity 는 분산 캐싱 프레임워크입니다. 우선 분산 캐싱이 왜 필요한지 이해가 필요합니다. 기존에는 캐싱이라고 함은 in-proc 캐싱을 의미했으며 즉 메모리 상에서 객체를 캐싱(Caching)하거나 풀링(Pooling)하기 위해 시스템의 리소스(Resource) 를 사용했습니다.

하지만 점차 엔터프라이즈 솔루션은 대규모, 대용량화 되어감에 따라 in-proc 캐싱은 시스템 리소스나 성능에 영향을 받게 되었습니다. 기존의 엔터프라이즈 솔루션은 데이터베이스의 대용량 아키텍처에 민감했고, 즉 데이터 중심의 아키텍처링을 할 수 밖에 없었습니다. 데이터의 정합성, 안정성, 성능은 기업에서 돈(Money) 와 직결되는 문제이기 때문이죠.

하지만 이미 데이터와 관련된 기술과 노하우는 이미 포화 상태이고, 엔터프라이즈 전체적인 아키텍처를 보았을때 단지 병목은 데이터에서만 존재하는 것이 아니었다는 것입니다. Middleware 나 Application Server 의 아키텍처링도 이미 포화 상태이고, 이것을 극복하기 위해서는 바로 캐싱(Caching) 이라는 기술이 필요했습니다.

위에서도 언급하였듯이 in-proc 캐싱은 굉장히 단순한 아키텍처입니다. 서버의 리소스가 받쳐 주느냐 그렇지 않느냐의 문제였고 in-proc 그리고 더 나아가 out-proc 를 이용하여 서버 자원을 최대한 활용하고자 합니다. 하지만 여기에서 또 문제가 발생합니다. 분산 out-proc 캐싱을 하자니 분산된 캐싱 데이터의 정합성을 어떻게 보장하느냐 입니다. 즉, out-proc 로 인해 캐싱은 중앙 집중화가 될 수 밖에 없으며 이것은 서버의 리소스에 의존하는 문제의 원점으로 돌아간다는 것이죠.

About Windows Server AppFabric (Codename "Velocity")

이러한 엔터프라이즈 환경의 서비스 확장에 대해서 고질적인 문제였던, 그리고 성능을 극대화 할 수 있는 캐싱이라는 기술을 어떻게 활용하느냐에 관심을 갖게 되었습니다. 현재 이런 문제를 해결할 수 있는 솔루션이 Windows Server AppFabric(Codename "Velocity") 입니다.

데이터의 정합성, 안정성, 성능은 기존의 아키텍처를 버리고 전용 Repository 를 통해 해결할 수 있습니다. 그것은 데이터베이스가 될 수 있고, 그 밖에 다른 Repository 가 될 수 도 있겠죠. 바로 이러한 컨셉은 캐싱을 어떤 분산 시스템간이라도 공유한다는 의미입니다. 이러한 캐싱을 클러스터링한다는 것은 흔히 Caching Dependency 를 해결할 수 있는 아주 좋은 해결 방법이기도 합니다. 어떤 로컬 시스템이건, 어떤 원격 시스템이건 캐싱 정책을 적용받게 되는 것입니다.

Install Windows Server AppFabric (Codename "Velocity")

아래는 필자는 게으름으로 Velocity CTP 3 기준으로 설치하는 방법입니다. (지금이라도 포스팅 하는걸 보면 대견스럽습니다만;;;)

기본적으로 캐싱 데이터는 데이터베이스를 사용합니다. 데이터베이스의 파일이 저장이 될 경로를 입력하거나 Storage 타입을 정하시면 됩니다.

먼저 이전 포스트의 "MEF 는 Generic Type 을 지원하지 않는다!" 에서 언급했고, .NET CLR 2.0 부터 Generic Type 을 지원함에도 불구하고, .NET Framework 4.0 에 포함되는 MEF 가 Generic Type 을 지원하지 않는다는 것은 솔직히 납득하기가 어렵습니다. MEF 개발 PM 이 말하는 강력한 계약 기반(Strongly Contract Based) 의 모델이라는 점은 머리로는 이해는 되지만, 사실 안될 것도 없습니다. -_-;

MEF 가 갖는 대표적인 키워드인 Composable 은 현재 Generic Type 을 지원하지 않지만, 상당히 매력이 있습니다. 이미 현대적인 프레임워크는 Modular 에 집중하고 있고, MEF 는 더 나아가 Modular + Composite 이라는 상당한 매력을 가진 프레임워크입니다.

일단 서두는 이쯤에서 접어두고, MEF 가 Generic Type 을 지원하기 위한 몇 가지 공개되어 있는 방법을 알아보고, 다시 이야기를 나누어 봅시다. 
   

How to support Generic Type of MEF ?    

첫 번째 방법 - Factory Provider

가장 간단한 방법이 바로 Factory Pattern 을 이용한 방식입니다. 객체의 생성은 Factory 를 통해 생성하도록 하고, Factory 는 객체의 Type 을 받음으로써 객체의 생성을 Factory 에게 모두 의존하는 방법입니다. 우선 아래의 링크를 참고하세요.

 ExportProvider 를 재정의하여 객체의 Type 을 등록하여 원하는 Type 의 객체를 생성하도록 합니다.

1: public interface IService { }

2: public interface IUserService : IService { }

3:  

4: [Export]

5: public class UserController {

6: [ImportingConstructor]

7: public UserController(IUserService userService) { }

8: }

9:  

10: // in your application

11: private void Compose() {

12: var catalog = new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly());

13: var factoryProvider = new FactoryExportProvider<IService>(GetService);

14: var container = new CompositionContainer(catalog, factoryProvider);

15: container.AddPart(this);

16: container.Compose();

17: }

18:  

19: public IService GetService(Type type) { return ... }

하지만, 이 방법은 상당히 문제가 많은 방법입니다. 가장 즐겨쓰고, 흔히 볼 수 있는 Pattern 이기 때문에 추가되는 Factory 마다 객체 등을 Factory Provider 에 등록을 해 주어야 합니다. 그 뿐만이 아니죠. Factory Pattern 의 특성상 객체를 생성하는 Factory 는 일일이 각 객체의 타입을 체크하여 반환해 주어야 합니다.

그리고 위의 코드에서는 Type 인자가 1개이지만, 그 이상이라면??? 가령, Generic Type Class<T1,T2,T3,T4,T5> 가 된다면 대략 난감하겠죠. 일단 작은 코드에서는 쓸만할 수 있지만, 꾸준히 성장하는 코드라면 이러한 Factory 방식은 코드의 변경이 너무 잦아집니다.

두 번째 방법 - Type Mapping

MEF 는 Codeplex 에 공개가 되어있고, MEF Contrib 으로 불리우는 MEF 의 확장 라이브러리 입니다. MEF Contrib 의 가장 큰 특징 중에 하나인 ComposablePartCatalog 를 재정의 하는 Generic Catalog 를 지원해 줍니다. 이 링크에서 Type Mapping 을 통한 문서를 볼 수 있습니다.

public class GenericCatalogContext
{
protected AggregateCatalog _aggegateCatalog;
protected GenericCatalog _genericCatalog;
protected ImportDefinition _repositoryImportDefinition;

public GenericCatalogContext()
{
var typeCatalog = new TypeCatalog(typeof(OrderProcessor), typeof(RepositoryTypeLocator));
_aggegateCatalog = new AggregateCatalog();
_aggegateCatalog.Catalogs.Add(typeCatalog);
_genericCatalog = new GenericCatalog(_aggegateCatalog);
string orderProcessorContract = AttributedModelServices.GetContractName(typeof(OrderProcessor));
var orderProcessPartDefinition = typeCatalog.Parts.Single(p => p.ExportDefinitions.Any(d => d.ContractName == orderProcessorContract));
_repositoryImportDefinition = orderProcessPartDefinition.ImportDefinitions.First();
Context();
}

public virtual void Context()
{

}
}

[InheritedExport]
public abstract class GenericContractTypeMapping
{
public GenericContractTypeMapping(Type genericContractTypeDefinition, Type genericImplementationTypeDefinition)
{
}

public Type GenericContractTypeDefinition { get; }
public Type GenericImplementationTypeDefinition { get; }
}

public class RepositoryTypeLocator : GenericContractTypeMapping
{
public RepositoryTypeLocator()
:base(typeof(IRepository<>), typeof(Repository<>))
{
}
}

public class Repository<T> : IRepository<T>
{
}

이러이러한 과정을 통해서 아래와 같이 Type Mapping 을 통해 Generic Type 을 사용할 수 있습니다.

[TestFixture]
public class When_querying_catalog_for_an_order_repository_and_no_closed_repository_is_present : GenericCatalogContext
{
[Test]
public void order_repository_part_definition_is_created()
{
Assert.IsNotNull(_result.Item1);
}

[Test]
public void order_repository_export_is_created()
{
Assert.IsNotNull(_result.Item2);
}

public override void Context()
{
_result = _genericCatalog.GetExports(_repositoryImportDefinition).Single();
}

private Tuple<ComposablePartDefinition, ExportDefinition> _result;
}

Contract Type 와 Mapping Type 을 매핑하여 Locator 로 등록하여 주고, 각각 Mapping Class 를 통해 실제 계약의 Generic Type 매핑이 이루어 집니다.

다시 말해서, Generic Class 별로 Locator Class, Mapping Class, 그리고 Mapping Context Class 를 만들어주어야 합니다. 배보다 배꼽이 더 커지는 격입니다. 일단, 아이디어는 좋지만 안쓰고 말랍니다.

세 번째 방법 - MEF + Unity 조합

아마도 가장 이상적인 방법이긴 합니다. Unity Application Block 은 Unity Container Extension 을 지원하기 때문에 객체의 Register, Resolve 등의 이벤트를 가로채서 Unity 의 기능을 확장할 수 있습니다. 이 이벤트를 MEF 에서 받도록 하여 MEF 의 ExportProvider 의 GetExportsCore 를 통해 Unity 의 객체에서 Resolve 하도록 하는 방법입니다.

UnityContainerExtension 을 재정의하여, 아래와 같이 이벤트를 받고, 이것을 MEF ExportProvider 로 전달하는 방법입니다.

UnityContainerExntension 에서는 아래와 같이...

protected override void Initialize()
{
this.Context.Registering += new EventHandler<RegisterEventArgs>(Context_Registering);
this.Context.RegisteringInstance += new EventHandler<RegisterInstanceEventArgs>(Context_RegisteringInstance);
}

MEF 의 ExportProvider 에서는 아래와 같이…

protected override IEnumerable<Export> GetExportsCore(ImportDefinition definition, AtomicComposition atomicComposition)
{
if (definition.ContractName != null)
{
Type contractType;
if(Mapping.TryGetValue(definition.ContractName, out contractType))
{
if (definition.Cardinality == ImportCardinality.ExactlyOne || definition.Cardinality == ImportCardinality.ExactlyOne)
{
var export = new Export(definition.ContractName, () => serviceLocator.GetInstance(contractType));
return new List<Export> { export };
}

}
}
return Enumerable.Empty<Export>();
}

일단 가장 완벽해 보입니다만, 이 속에는 그 이상 많은 문제들이 생기게 됩니다. MEF 도 내부적으로 Injection(주입) 기법을 사용하고, Unity 에서도 Injection 을 사용하는데 바로 이 Injection 방법이 달라지게 되는 것입니다. 즉, MEF 기반의 코드와 Unity 기반의 코드의 Injection 선언 방법이 틀려지고, 서로 호환할 수 없다는 것입니다.

결국 DI 프레임워크는 특정 DI Container 에 의존할 수 밖에 없어지고, 더불어 Compisite 과 Injection 은 두 가지의 사용 방법이 혼재될 수 밖에 없다는 것이죠.

Conclusion

MEF 에서 Generic Type 을 사용하고 싶어서 안달이 난 1人은 여러 가지 방법을 찾아보았지만, 사용성, 재사용성, 확장성, 유연성 등 모든 면에서 원하는 해답을 찾지 못했습니다. 그리고 현재까지 MEF 에서 Generic Type 을 지원하기 위한 대략적인 3가지 방법을 정리해보도록 하죠.

이제 슬슬 머리가 아파옵니다. 향후 .NET Framework 4.0 에서 가장 큰 빛을 보게 될 MEF 이지만, Generic Type 을 지원하지 않는다는 것은 가장 큰 오점이 아닐까 생각합니다. 우선 이쯤에서 마무리하고 어떻게 해야 할지 생각해 보도록 하지요.

MEF 에서 Generic Type 문제는 코드 플랙스에 MEFGeneric 으로 공개하였습니다.
[.NET/.NET Framework] - MEFGeneric 코드 플랙스에 공개합니다.

.NET Framework 4.0 에 포함이 될 Managed Extensibility Framework(이하 MEF) 는 Generic Type 을 지원하지 않습니다. ( MEF is not supporting Generic Type!!!! )   

상당히 충격입니다. MEF 는 현재 Generic Type 을 지원하지 않습니다. 이것을 가지고 현재 중요한 프로젝트를 진행하기 위해 여러 가지 리뷰를 해 보고 있습니다만, MEF 가 Generic Type 을 지원하지 않는 것은 쉽게 말해 'MEF 는 아직…' 이라는 결론이 나는군요.    

Managed Extensibility Framework Basic

이것을 이해하기 위해서는 MEF 의 기본부터 이해해야 할 필요가 있습니다. 자세한 내용은 아래의 필자의 블로그 링크를 클릭하시면 Managed Extensibility Framework 에 대한 아티클을 볼 수 있습니다.

우선 이러한 원인은 MEF 가 Contract Model(계약 모델) 기반이라는 있다는 이유 입니다. 우리가 흔히 사용하는 계약 모델은 쉽게 이야기하면 제공자와 소비자로 구분할 수 있습니다. 제공자와 소비자의 거래가 성립이 되기 위해서는 바로 계약이라는 것이 필요하죠. MEF 로 비유하자만 Import/Export 가 바로 그것이며 그 계약을 성립시켜 주는 것이 MEF Container 와 Composition Batch 로 볼 수 있습니다.

바로 이러한 계약 기반과 Composable Part 라는 개념으로 기존의 컴포넌트의 재사용성을 높일 수 있게 되며, 좀 더 동적이며, 추상화가 가능한 프레임워크 입니다. 더 쉽게 얘기하면, 새로운 C 라는 컴포넌트는 A 와 B 라는 컴포넌트와 계약하여 결합시키거나, 기존 컴포넌트를 변형시키는 등 Composable Application 을 만들기 위해 계약의 명세만 알면 다양한 컴포넌트를 재생산, 변형, 다양성, 재활용 등을 할 수 있습니다.

MEF 는 내부적으로 이러한 명확한 계약을 위해 여러 가지 방법으로 계약을 정의할 수 있습니다. 기본적으로 ExportAttribute 을 사용하여 String, CLR Type, ExportMetadata 를 사용하게 되어 있지요. 하지만 MEF 는 모든 계약의 명세는 바로 String 을 사용하는 데에서 문제가 발생하게 됩니다. 그리고 이것이 Dependency Injection(DI) 와 Inversion Of Control(IoC) 와 다른 점입니다. 대부분의 DI 프레임워크는 Object 의 Lifecycle 을 관리하고 객체의 의존성을 낮추기 위해 역제어 하는 것에 초점이 맞추어져 있기 때문에 CLR Type 기반으로 Container 에 등록이 됩니다.

예를 들어 보면, 아래와 같은 것이 MEF 에서는 계약 명세 규격에 어긋난다는 의미입니다. (특정 DI 프레임워크에 종속되지 않는 코드입니다)

Why MEF is not supporting Generic Type?

MEF 가 Generic Type 을 지원하지 않는 것에 이미 많은 사람들이 문제를 발견했고, 몇 가지 해결 방법이 있긴 있습니다.

이미 Ayende Rahien 이라는 사람의 블로그에는 MEF 가 Generic Type 을 지원하지 않는 것에 대한 이야기를 합니다. 내용을 보면 처음부터 Microsoft 의 MEF 개발 팀은 Generic Type 을 배제하고 있었던 것 같습니다. 하지만 Ayende Rahien 씨는 이 문제에 대해 반드시 해결해야 한다는 이야기를 MEF 개발 팀과 나누었습니다. 저도 이 문제가 반드시 해결 되리라 생각합니다만… 현재로써는 글쎄 ^^;

여기에서 MEF 개발 팀은 조금 구차한 변명을 합니다. 위에서 얘기한 MEF 의 기본은 계약 기반의 프레임워크라는 것입니다. 이 문제에 대해 추측을 해보면, MEF 가 Generic Type 을 지원한다는 것은 Strongly Contract Based 가 될 수 없기 때문이고, Generic Type 으로 인해 명확한 계약이 이루어질 수 없다는 것입니다. 특히 MEF 는 계약의 명세가 모두 MEF 가 내부적으로 관리하고 있기 때문에, Generic Type 에 의한 객체 의 계약 관리는 엄청난 메모리 사용량을 증가로 이어질 가능성이 충분합니다.

실제로 Microsoft 에서 MEF 개발 팀의 PM 을 맡고 있는 Glenn Block 씨는 이 아티클에서는 MEF v1 에서는 Generic Type 을 지원하지 못할 것이라고 합니다. 만약에 Generic Type 을 지원하게 된다면 차기 버전이 될 듯 합니다.

하지만, 다시 한번 MEF 는 계약 기반의 모델이라는 것을 생각하지 않을 수 없습니다. 만약 계약이 명확하지 않다면 계약 자체가 불명확하다는 의미입니다. C# 2.0 부터 지원하는 Generic Type 의 명확하지 않는 타입이 계약에 존재한다면 이것은 계약 자체가 성립되기 힘들다는 전제 조건을 포함하게 됩니다.

MEF 의 예를 들어 봅시다. 아래와 같은 Generic Type 의 계약이 존재합니다. (현재의 MEF 로는 전혀 불가능한 코드입니다^^;)

CLR(Common Language Runtime) 의 Generic Type 의 특성상 Generic T Parameter 는 굉장히 다형적입니다. UMC<string> 또는 UMC<int> 또는 모든 Class Type 이 T Parameter 에 대입될 수 있습니다. 단순히 어떤 타입도 올 수 있다는 것을 떠나 물건을 팔 사람은 도대체 소비자가 누구와 계약한 것인지 알 수 없고, 실제 상거래와 같은 상황이라면 사기와도 같다는 것이죠. 굳이 예를 들자면, 주민등록번호가 다름에도 불구하고, 주민등록증의 이름이 같은 동명인에게 언제든지 계약을 할 수 있다는 것이죠.

DI(Dependency Injection / IoC) 는 CLR Type 을 기반으로 합니다. 일부 DI 프레임워크는 Tag 와 같은 Contract Data 를 제공하기는 하지만 이것은 Metadata 그 이상의 역활을 하지 않습니다. 즉 Contract(계약) 와는 전혀 무관하다는 이야기 입니다. 객체를 질의(Query) 하기 위함이지 Composable 을 위한 것은 아닙니다.

OK! I'm understand. But…!!

처음부터 MEF 는 계약 기반의 Composable/Plugin Model/Contract Based 라는 용어를 자주 만나게 됩니다. 그리고 계약 자체라는 의미에서 Generic Type 은 가장 큰 장애 요소임이 확실합니다. 그렇기 때문에 현존하는 모든 DI(Dependency Injection) 프레임워크는 계약(Contract) 라는 용어를 절대 사용하지 않습니다. 목적 자체가 계약과는 전혀 무관하기 때문입니다.

하지만, MEF 의 계약 모델은 내부적으로 String Based Contract 를 사용하고 있고, Generic Type 또한 String 으로 표현이 가능하기 때문에, 문자열의 Parsing 만으로 어느 정도의 Generic Type 을 지원할 수 있을 거라고 생각했습니다.

필자는 처음 MEF 를 본 순간 "이것을 물건이다!" 라는 걸 느꼈습니다만, 아마도 MEF 개발 팀은 두 가지의 고민을 했을 거라고 생각합니다. Silverlight 를 지원할지, Generic Type 을 지원할지에 대한 범용성에 대해서 말입니다. 하지만, Generic 에 대해 많은 피드백을 받음에도 불구하고 MEF v1 에 지원하지 않을 듯한 대답은 사실 "구차한 변명" 으로 밖에 들리지 않는답니다. 결국, 현재 MEF 는 Silverlight 를 지원하는 등 .NET Framework 의 범용성에 치중하였고, 결국 Generic Type 은 현재 시점에서 릴리즈 시점까지 구현이 불가능할 거라고 예상합니다.

아쉽긴 하지만, 현재 MEF 가 불가능한 Generic Type 에 대한 영역은 몇 가지 Open Source 에서 제공을 하고 있습니다. 단지 실제 사용성에 대한 의구심과 필자의 견해로는 안쓰는게 나을 것 같다는 판단입니다.

다음에 당장 지원하지 않는 Generic Type 을 어떻게 사용할지 알아보고 함께 돌파구를 찾아보도록 하겠습니다. 

MEF 에서 Generic Type 문제는 코드 플랙스에 MEFGeneric 으로 공개하였습니다.
[.NET/.NET Framework] - MEFGeneric 코드 플랙스에 공개합니다.

설치 과정 중에 TF255040 문제

Team Foundation Server 2010 을 설치하는 중 TF255040 오류가 발생하였습니다. 아래의 그림과 같이 SQL Server 의 Reporting Services 와 관련된 컴포넌트가 설치 되지 않았다는 오류입니다. 훔...

SQL Server Analysis Services 인스턴스를 찾지 못한다는 오류 메시지가 나타납니다.

TFS 설치 오류 로그를 자세히 보면 아래와 같이 문제 지점의 예외 메시지를 찾을 수 없습니다.

TF255040 오류 문제 해결하기

해결 방법은 두 가지가 있습니다. 그 중에 두 번째 방법을 추천 드립니다.

왜냐하면 SQL Express 버전을 설치하면 되지만, 결국 SQL Server 인스턴스를 만들어야 하기 때문에 왠지 TFS 전용 서버의 순결함을 잃는 듯 하군요.. 사용하지도 않을 SQLEXPRESS 라는 반갑지 않은 인스턴스와 말이죠. 두 번째 SQL Server 2008 Feature Pack 은 SQL Server 의 구성 요소 일부만 설치할 수 있습니다. 제가 필요로 하는 Analysis Service 관련 어셈블리만 설치되도록 설치 패키지를 제공해 주고 있습니다.

• Microsoft® SQL Server® 2008 Management Studio Express

  그럼 Microsoft SQL 2008 관련 구성 요소를 설치해 주어야 하는데, 아래의 주소에서 기본적인 클라이언트가 설치되도록 합니다. 근데 Management Studio Express 를 설치하게 되면 SQLEXPRESS 라고 하는 인스턴스가 설치가 되는데 Team Foundation Server Application Tier 에 SQLEXPRESS 인스턴스가 그다지 필요해 보이지도 않고, 설치 시간도 오래걸리고요.

• Microsoft SQL Server 2008 Feature Pack, April 2009

  위의 방법은 Analysis Services Object 어셈블리만 설치하는 방법입니다. HTML 페이지가 다운로드 되면 HTML 파일을 열어봅니다. 다운로드 가능한 여러 가지 목록 중에 아래 Analysis Services Object 만 골라서 다운로드 하시는 것이 더 좋겠죠?

     

아래를 설치하고 Team Foundation Administrator Console 을 다시 실행해 주시면 아래의 그림과 같이 정상적으로 SQL Server 의 Analysis Services 에 접근할 수 있습니다.

Configure Team Foundation Build Service 에서 Start Wizard 를 클릭합니다.

아래는 Build Service 설치 안내 페이지 입니다. 다음을 클릭합니다.

Team Build 를 수행한 Team Project Collection 을 지정해야 합니다. Browser 를 클릭하여 Team Project Collection 을 선택합니다. 만약 Team Foundation Server 와 연결되지 않은 상태일 경우 Team Foundation Server 와 연결해야 합니다.

기본 설정대로 Recommended 를 선택하고 다음을 클릭합니다.

Team Build 를 수행할 계정과 포트를 입력합니다. 필자는 TFSBUILD 계정으로 사용하였고, 환경에 따라 NETWORK SERVICE 등으로 사용하셔도 됩니다.

모든 설정이 완료 되었고, Verify 를 클릭하여 Team Build 환경을 점검합니다.

모든 점검이 완료되면, Configure 를 클릭하여 설치를 진행합니다.

아래는 Team Foundation Build Service 설치가 완료된 화면입니다.

Team Foundation Server 2010 은 기존의 2008 버전에 비해 굉장히 설치가 간단해 졌습니다.  

사실 설치과 구성 패키지 자체는 TFS 2008 이 간단하긴 했지만, 구성이 올바르게 완료되어야만 설치가 가능했었습니다. 이런 문제로 인해서 초기 설정이 유효하지 않을 경우 설치를 완료한들 다시 제거를 하고 재설정을 했던 경우가 많았습니다. 그리고 TFS 2008 에서는 설정 정보가 IIS 의 TFS Web Service 의 web.config 와 데이터베이스의 특정 필드를 직정 수정해야 하는 관리상의 불편함이 많았습니다.

하지만 이번 Team Foundation Server 2010 는 이런 면에서 초기 설치 단계에서 구성하는 단계까지 많이 편리해졌습니다. 설치와 구성을 따로 따로 하도록 말이죠.  

아래는 Team Foundation Server 2010 을 설치하고, Team Foundation Server Administration Console 을 이용하여 TFS 환경을 구성하는 방법입니다. 

아래의 설치 과정은 3-tier 로 구성된 서버에 TFS 2010 을 설치하는 단계입니다.

• 서버 1 : Active Directory, DNS 서버
• 서버 2 : MSSQL 2008
• 서버 3 : Team Foundation Server 2010

Team Foundation Server Administrator Console 을 실행하여 Configure Installed Features 를 클릭합니다.

다중 Tier 환경으로 설치할 예정이므로, Advanced 를 선택하고 Start Wizard 를 클릭합니다.

Wizard 안내 페이지입니다. 그냥 다음으로 넘어 갑니다.

SQL Server 의 인스턴스를 입력하고 Test 를 클릭합니다. 인스턴스가 유효하면 푸른색 V 표시가 나타나고, 다음으로 넘어 갑니다.

Service Account 계정을 입력하고 Test 를 클릭해보고, 계정이 유효하면 다음으로 넘어갑니다.

Team Foundation Server 2010 의 웹 서비스의 설정을 합니다. 그냥 기본 구성 그대로 다음으로 넘어갑니다.

보고서를 구성하는 페이지의 안내입니다. 필자는 보고서를 구성할 것이므로, Configure Reporting for use with Team Foundation Server 항목 체크 박스를 체크 한 후에 다음으로 넘어갑니다.

Reporting Service 인스턴스를 입력하고 Populate URLs 를 클릭하면 유효한 보고서 서비스를 찾아줍니다. 그리고 다음으로 넘어갑니다.

TFS Report 서비스의 실행 계정을 지정해 줍니다. 필자는 기본 계정인 NETWORK SERVICE 계정을 사용합니다.

아래는 Sharepoint 를 설치를 안내하는 페이지 입니다. 다음으로 넘어갑니다.

Sharepoint 서버의 계정을 입력하고 Test 를 클릭하여 유효성을 검사합니다. 그리고 다음으로 넘어갑니다.

기본적으로 Team Project Collection 이 체크되어 있습니다. 그대로 다음으로 넘어갑니다.

모든 설정이 완료 되었습니다. Verify 를 클릭하여 최종 점검을 진행합니다.

Verify 결과가 양호할 경우 설치를 진행하도록 합니다. Configure 를 클릭하여 설치를 진행합니다.

아래는 Team Foundation Server 2010 이 설치가 완료되었습니다.

이제 설치가 완료되었고, Team Foundation Server 관리를 위하여 관리 권한을 지정합니다.

Application Tier 의 Administer Group Membership 을 클릭합니다.

Team Foundation Administrators 그룹을 더블 클릭(또는 Properties 클릭) 하고, 관리자 계정을 지정해 줍니다.

이제 모든 설치와 구성을 마쳤습니다. 아래의 그림은 Visual Studio 2010 으로 Team Foundation Server 2010 에 연결된 모습입니다.

오늘 Visual Studio 2010 출시 일정이 나왔습니다. Rob Caron 말에 의하면 2010년 4월 12일에 출시가 된다고 합니다. Microsoft 직원이 전하는 이야기이니 아마도 이 날에 출시하는 것을 신뢰하시면 될 것 같습니다.

Rob Caron 은 Microsoft 에서 마케팅 커뮤니케이션 매니저로 일하고 있으며, Developer, User Experience Runtime, Tools 과 관련된 일을 하고 있는 분입니다. Microsoft 에 입사 하기 전에 개발자 출신인데, Microsoft 에서 이전에는 개발자 마케팅과 MSDN 개발자 센터, Visual Studio 마케팅 사이트, 개발자 이벤트, MSDN Library 에 콘텐트를 게시하는 일도 하셨다고 합니다.

좀 아쉬운 것은 현재 문제나 개선되고 있는 부분을 좀 더 자세히 알고 싶은데, 출시 일정 외에 다른 언급은 전혀 없네요.   

Visual Studio 2010 의 처음 출시 일정은 2010년 1월에 RC 버전, 3월에 정식 버전을 출시하기로 예정하였습니다. 그러나 가상 메모리 관련, 성능 최적화 문제로 정확한 출시 일정을 공개하지 않고 출시 기간을 연장하였습니다. 일정이 연기된 것은 개인적으로 아쉽지만, 보다 충실한 플랫폼을 만들기 위해서라면 충분히 기다릴만 하다고 생각합니다. 써본 후에 투덜댈봐엔 좀 더 완성도 높은 플랫픔을 위한 것이라면 말이죠^^ 

언제나 언급했던 이야기 이지만, 예전의 Visual Studio 2008 까지는 기능에 충실했던 강력한 개발 도구임이 틀림이 없습니다. 하지만 Visual Studio 2010 과 관련된 플랫폼은 기능은 기대 이상 완벽히 충실하고 있으며, 편의성까지 갖추게 될 그야말로 차세대 플랫폼입니다. 앞으로 다가올 4월이 정말 기대가 됩니다.

한국 마이크로소프트에서 주최하는 TECH DAY 2009 행사가 오픈하였습니다. 지난 Dev Days 2008 에 이어 새롭게 개최하는 행사입니다. TECH DAY 는 온라인으로 진행되며 다양한 주제로 동영상 세미나가 준비되어 있습니다.

http://www.techdays.co.kr/

이번 TECH DAY 는 새로운 플랫폼 시대를 대비하기 위한 개발자와 IT 전문가를 위한 컨퍼런스 입니다. 특히 온라인 컨퍼런스의 장점이라면 시간과 장소에 구애 받지 않고 언제나 오픈되어 있는 컨퍼런스라는 점입니다.

트랙은 키노트와 개발 트랙, IT 전문가 트랙으로 구성되어 있으며, 특히 개발 트랙과 IT 전문가 트랙은 굉장히 많은 동영상 콘텐트가 준비되어 있습니다. 그리고 개발 플랫폼 트랙은 제가 몸담고 있는 VSTS 2010 팀에서 전체 세션을 맡았습니다.    

이번 TECH DAY 2009 행사에 많은 참여를 부탁드립니다. 경품도 많이 준비가 되어있으니 경품 이벤트에도 도전해 보세요.

우선 설치해서 잠깐 둘러본 결과, 가장 우려했던 IDE 의 성능 문제는 의외로 빨랐습니다. 어떤 부분은 Visual Studio 2008 보다 더 빨랐고, 기본적인 대부분의 동작의 실행 속도는 굉장히 만족스럽습니다.

마이크로소프트 Visual Studio 개발팀도 이 점을 인지하고 개선하려고 상당히 노력한 흔적이 엿보입니다. 기존 CTP 와 Beta 1 에서 기어가는 듯한 IDE 가 느렸던 문제는, Beta 2 버전에서는 걱정하지 않으셔도 될 것 같습니다. 체감적으로 Visual Studio 2008 보다 느리지 않네요.  

Visual Studio CTP 와 Beta 버전에 익숙해졌는지 외관상 크게 거부감도 없습니다. 

설치된 구성 요소 검색하는 화면

라이선스 동의 화면

설치 패키지 선택 화면

설치 시작 화면

설치되는 구성 요소 목록

.NET Framework Beta 2 가 설치 된 후 시스템 재시작이 필요합니다.

Visual Studio 2010 Beta 2 의 Splash 화면

Visual Studio 시작 페이지 화면

미국 시간으로 2009년 10월 19일, Visual Studio 2010 Beta 2 버전이 공개가 되었습니다. MSDN 을 통해 Beta 2 버전을 다운로드 받으실 수 있습니다.

다운로드
http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx

그간 Visual Studio 2010 CTP/Beta 버전에서 보여주었던 약간의 성능적인 문제는 이번 Beta 2 버전에서 상당히 많이 개선이 되었다고 합니다.

특히 이번 Beta 2 버전부터는 제품 라인이 전체적으로 변경되었습니다. 기존의 Professional 제품을 제외한 모든 제품의 라인이 변경이 됩니다. 다운로드 받으실 때 혼란이 없으시길 ^_^

더불어 Expression 제품 군도 두 개의 제품으로 나뉘어지게 될 것입니다.

아래는 변경된 MSDN 로고 입니다. ^_^

Visual Studio Extensibility 이야기

VSX(Visual Studio Extensibility) 는 Visual Studio 의 기능을 확장할 수 있는 SDK(Software Development Kit) 를 통해 툴의 기능을 확장할 수 있는 소프트웨어 개발 키트입니다. 잘 설계된 Visual Studio 의 확장 가능한 모델은 Visual Studio 2005 부터 비약적으로 발전했습니다. 그리하여 현재 Visual Studio 2010 은 MEF(Managed Extensibility Framework) 를 기반으로 하여 개발, 패키징, 배포에 이르러 훨씬 단순화된 새로운 확장 모델인 VSIX 를 내놓게 되었습니다.

Visual Studio 2003 부터 Visual Studio SDK 를 제공해 주었지만, Visual Studio 2003 버전에서는 확장 기능을 개발할 수 있는 그리 좋은 여건은 아니었습니다. 왜냐하면 Visual Studio 2003 의 Customizing Point 는 대부분 자동화 개체 모델인 DTE 에 굉장히 의존적이었습니다.

Visual Studio 2005 는 이전의 IDE 기반을 갈아엎었다고 할 수 있을 정도로 상당히 파격적인 모습으로 다가왔습니다. 사실 이때만해도 Visual Studio 2003 에 비해 너무 느려지지 않았냐는 불만을 상당히 많이 들었습니다. 하지만 개발자들의 하드웨어 스팩이 좋아지고, Visual Studio 2005 가 제공하는 다양한 기능은 안쓸래야 안쓸수 없었답니다. 그리고 Visual Studio 2005 SDK 는 2008 버전까지 고스란히 답습하고 있었습니다.

Visual Studio 2008 은 이제 .NET 개발의 국민 IDE 로 자리매김 하였습니다. 그리고 빠르게 많은 기업에서 Visual Studio 2008 과 .NET Framework 3.5 기반으로 마이그레이션을 하고 있습니다. (적어도 제 주변 대부분이..) 그리고 이 시점부터 Software Factories 개념을 도입한 Guidance Automation 과 Blueprints 등 Visual Studio 확장 기능들이 대거 모습을 드러내기 시작했습니다. (GA 는 2005 버전부터 등장했지만 실제 활성화된 시점은 개인적으로 2008 부터가 아닐까 생각합니다)

그렇다면 Visual Studio 2010… 이제는 IDE 환경의 지존을 논한다고 생각합니다. 광고성 멘트라고 생각하시면 그냥 스킵 하셔도 좋습니다. .NET Framework 는 더없이 탄탄해지고, 딱딱했던 IDE 환경은 UX 친화적인 면을 보여주기 위해 노력한 흔적이 엿보입니다. 그리고 Oslo, Velocity, Pex, T4 Templates, 미려해진 DSL Tools, 진정한 통합을 꿈꾸는 Team System, 그리고 이번 주제였던 정말 편한 개발 환경 확장을 제공해주는 VSX...

Visual Studio Extensibility 종류

그럼 기존의 VSX 는 어떻게 IDE 도구를 확장하였을까요?

• Visual Studio Macro
  VB 스크립트 언어를 이용하여 Visual Studio 의 자동화 개체 모델의 DTE 객체를 제어할 수 있습니다. 아무래도 스크립트 언어이다보니 개발의 편의성은 좋지만 배포와 코드 보안에 좀 떨뜨름합니다.

     

• Visual Studio Addin
  기능적인 면에서 Visual Studio Macro 와 큰 차이는 없습니다만, 스크립트 언어가 아닌 C# 과 같은 Managed 언어로 개발이 가능합니다. 태생적으로 Visual Studio Macro 와 동일선상이기 때문에 Addin 의 독립적인 기능만으로는 확장에 한계는 있었습니다. 하지만, DTE 개체 모델을 통해 개발이 굉장히 쉽고, 배포 또한 단순하여 가장 많은 사랑을 받은 VSX 분야입니다.

     

• Visual Studio Integration Package (이하 VSIP)
  Visual Studio 를 진정으로 통합할 수 있는 확장 방법입니다. Visual Studio 의 COM Interface 를 고스란히 사용할 수 있고, 이것을 이용하여 Visual Studio 의 모든 기능을 활용하고 확장할 수 있습니다. 실제로 Visual Studio 기능의 대부분이 VSIP 를 통해 개발이 되었고 Visual Studio 의 특징을 가장 잘 보여주는 Interface 들로 구성이 되어있습니다. 여러분이 잘 알고 있는 솔루션 탐색기, 오류 리스트, 팀 탐색기 등 셀 수 없을 정도의 많은 VSIP 들이 Visual Studio 에 포함되어 있습니다.

     

• Visual Studio Shell Isolated
  Visual Studio Shell Isolated 는 Visual Studio 와 같은 Shell 을 제공하고 개발할 수 있는 방법입니다. VSIP 가 Visual Studio 확장 기능에 필요한 요소를 가르킨다면, Shell Isolated 는 VSIP 를 담는 그릇이 되겠군요. Visual Studio Shell Isolated 를 이용하게 되면 기존에 Visual Studio 에서 제공하는 여러 가지 인터페이스를 고스란히 사용할 수 있는 이점이 있습니다. 가량, Project Type, Intellisence 와 Microsoft 의 통합 빌드 솔루션인 MSBuild 등 다양한 기능을 곧바로 사용할 수 있다는 장점이 있는 것이죠.

     

• Visual Studio Language Package
  Visual Studio 에서 사용할 수 있는 언어를 개발할 수 있습니다. 기본적으로 C#, VB.NET, C++ 등을 사용할 수 있지만 PHP, RoR, Native C 등의 언어를 개발할 수 있도록 하고, 이미 Visual Studio for PHP, Visual Studio for RoR 가 상용화 되었고, Visual Studio for C 는 Visual Studio SDK 예제로도 포함이 되어 있답니다.
  
  
     
• Domain-Specific Language Package
  도메인에 특화된 언어를 개발할 수 있는 방법을 제공합니다. 일반적으로 IT 조직과 개발 조직은 서로가 사용하는 언어가 다릅니다. 즉, 경영진과 실무진과 같은 물과 기름의 관계를 이해시키기 위한 언어로써, 이미 Visual Studio 에서 광범위하게 사용되고 있는 방법입니다.

• Help Integration
  MS HELP 2.0 을 이용하여 Microsoft Document Explorer 의 콘텐츠를 추가할 수 있는 방법입니다. Microsoft Document Explorer 는 일반적으로 Visual Studio 도움말로 생각하시면 됩니다. 이곳에 콘텐츠를 추가하기 위해 Setup Wizard 를 제공하고, 쉽게 Visual Studio 도움말에 자사 또는 자신의 콘텐츠를 추가할 수 있습니다.

     

어휴,, 정말 다양한 방법으로 Visual Studio 를 확장하는 방법을 제공해 주는군요. 이러한 아키텍처는 Visual Studio 2005 부터 제대로 뿌리를 내렸는데, 그 중 일부분은 Visual Studio 2010 에서 좀 더 획기적으로 변신을 합니다.

변신을 하면서 기존의 COM 기반의 인터페이스는 더 이상 WPF 기반의 어플리케이션에서 상당수 비호환적인 면이 있고, 한계점을 드러내지 않았나 생각을 해봅니다. 실제로 기존의 인터페이스는 WPF 의 Managed 환경에서 더 이상 호환할 수 없어집니다. WPF 기반의 IDE 환경에서는 새로운 인터페이스가 필요했고, MEF 를 도입함으로써 새로운 확장 가능한 모델이 필요했습니다. 바로 그것이 새로운 확장 가능한 모델인 VSIX 입니다.

VSIX 는 기존의 IDE 확장 모델과 새로운 MEF 기반의 확장 기능을 개발부터 패키징, 배포까지 통합할 수 있는 방법을 제공해 줍니다. 뿐만 아니라 기존의 확장 기능과 새로운 MEF 기반의 확장 기능을 통합하고 연동까지 할 수 있으니 이것이야 말로 누이 좋고 매부 좋은 일이 아닐까 합니다.

이제부터 위의 다양한 확장 기능을 개발하는 방법을 시작하여 VSIX 에 이르기 까지 한번 짚고 넘어가볼 예정입니다. 아직까지 국내에서는 이러한 희귀한 분야를 다루는 곳도 흔치 않고, 관심이 있더라도 정보가 부족하여 어느 정도 종점을 찍고 포기하는 분들도 많이 있습니다. 아마 이 연재를 통해서 Visual Studio 에 보다 관심을 갖고 널리 기술을 알리는 좋은 기회가 되지 않을까 생각을 하면서, 연재를 기대해 주세요.

MEF(Managed Extensibility Framework) 이 2009년 7월 13일에 릴리즈되어 14일에 공개가 되었습니다. 특히 MEF 는 .NET Framework 4.0 에 포함이 되어있으며, CodePlex 에서 굉장히 빠른 속도로 발전하고 있는 프레임워크 중에 하나 입니다.    

CodePlex MEF 사이트에 등록된 릴리즈 노트 입니다.

그 중에서 몇 가지만 살펴보도록 하겠습니다.

실버라이트 3 지원

특히 이번에 눈여겨 볼 만한 것이 Silverlight 3 를 지원하는 것입니다. 이미 Preview 5 이전의 MEF 에서는 실버라이트를 지원하기 위해 코드에서 전처리 명령 구문을 사용하여 프레임워크 실버라이트가 지원되긴 했습니다. 그것을 기반으로 이번 Preview 6 버전에서는 실버라이트 3 용 솔루션이 제공됩니다. 이 솔루션을 통해 실버라이트용 MEF 프레임워크를 빌드 하시면 됩니다.

ExportAttribute 의 seal 키워드 제거

이번 MEF Preview 6 에서 ExportAttribute 의 seal 키워드가 제거됩니다. 이 전 Preview 5 에서는 ExportAttribute 을 절대 상속할 수 없는 구조였기 때문에 독자적인 Export 를 제공할 수 없었기, Metadata 를 ExportAttribute 와 같은 기능울 개별적으로 지정해야 하는 등의 Export 기능의 확장에 불합리한 구조로 되어있었습니다. 하지만 이번 Preview 6 버전에서는 ExportAttribute 클래스의 seal 키워드가 제거 됨으로써 ExportAttribute 의 확장이 용이하게 되었습니다.

ImportMany 로 통일된 컬렉션 처리

이제 모든 컬렉션은 ImportMany 로 통일되었습니다. Preview 5 에서는 ExportCollection<T> 또는 IEnumerable<T> 와 같이 사용하기도 까다롭고 이것으로 반환된 객체를 처리하기에도 편리한 구조는 아니였습니다. Preview 5 에서도 ImportMany 의 기능이 존재하였지만, 이번 Preview 6 는 이것으로 모든 컬렉션 처리를 하도록 통일되었다는게 혼란스러웠던 부분을 간소화할 수 있을 것 같습니다.

기타 그 밖에도 구조적으로 보다 안정되었고, 메서드나 클래스의 네이밍이 변경되었고, 예외 시에 Composition 동작의 분석을 추적하기 쉽도록 덤프(Dump) 를 뜰 수 있는 로깅 기능 등 다양한 기능이 추가되었습니다. 정식 버전의 MEF 는 어떤 모습으로 나올지 정말 기대가 됩니다. 더 자세한 내용은 아래의 링크를 통해 더 쉽게 설명이 되어있으니 참고 하십시오.

참고문헌
MEF Preview 6 Available
http://blogs.msdn.com/nblumhardt/archive/2009/07/09/mef-preview-6-available.aspx