"엄준일"과 함께하는 소프트웨어를 위한 플랫폼 이야기

Roslyn(로즐린)은 분명 차기 비주얼 스튜디오(Visual Studio)에 한 획을 그을 만한 컴파일러 서비스(Compiler as a Services) 기능들을 제공한다. 이것이 장점이라면 단점이 더 많아질 것이라고 필자는 생각한다.

필자도 Roslyn(로즐린)을 좋아한다. Roslyn(로즐린)의 좋은 점에 대해서는 충분히 Microsoft가 이야기하고 있다고 본다. 하지만 필자는 여기에 부정적인 면을 살펴보고자 한다. 필자는 그냥 제 3자의 입장에서 글을 쓰고자 노력을 했다. 혹시 어느 방향으로 편향이 된 부분이 있어서 불편한 감정이 생긴다면 서두에서 미리 양해를 구한다.

개발자 측면에서 본 Roslyn(로즐린)으로 할 수 있는 것들…[1]

1. 서비스화
   • 동적으로 소스코드를 넣으면 바로 바이너리가 나온다. 블랙 박스(Black Box) 상태 제거
   • C#, VB.NET 의 Lexer, Parer, Alanyzer APIs의 공개
   • 비주얼 스튜디오(Visual Studio) 의 리팩토링, 코드 자동완성 등 개선
2. REPL(Read-Eval-Print Loop)
   • C#, VB.NET을 스크립트 언어처럼 쓸 수 있다.
   • 확장 도구(플러그인) 개발자가 더 많은 비주얼 스튜디오(Visual Studio) 기능을 쉽게 제어
   • MVVM의 ViewModel, 엔티티 POCO 코드를 동적으로 자동 생성
   • T4 템플릿을 런타임에서 바로 사용

Roslyn(로즐린) 으로 엿보는 그저 그런 미래의 시작

Microsoft 의 Roslyn(로즐린) 프로젝트, 그리고 Visual Studio의 미래를 살짝 엿보자. 그리고 .NET 플랫폼과 함께 비약적으로 성장하고 있는 Mono Project 에 대한 이야기도 잠깐 할 예정이다.

Roslyn(로즐린)은 2011년에 CTP로 처음 공개된 Compilers as a Services 프레임워크다. Compilers as a Services는 뭔가 대단해 보이는 이름처럼 묘사되지만 간단하게 설명하면 컴파일러(Compiler)가 가지는 기능을 APIs로 노출해 주는 것이고, Roslyn(로즐린)은 그 APIs를 제공해주는 라이브러리이다.

Roslyn(로즐린)을 코드 레벨에서 제공하는 APIs를 살펴보고자 한다면 Roslyn White Paper를 참고하자. 대부분의 대한 기술적인 내용은 모두 여기에 있다.

여러분들은 왜 Roslyn(로즐린) 프로젝트가 암울한 미래를 예고하는지 필자에 대한 생각과 다를 수 있다. 대다수의 사람들은 관심이 없을 것이고, 그 중 관심이 있는 소수의 사람들은 필자와 공감하지 않을 것이며, 그 나머지 사람들은 필자와 같은 공감을 할지도 모르겠다.

하지만 필자의 지금까지의 작은 경험을 빗대어 본다면 충분히 암울해 질 수 있는 개발환경이 찾아오고 있는 것은 확실하다.

이유 1. Microsoft의 생색내기용 프로젝트, Roslyn(로즐린)

• Compiler as a Services 가 과연 내게 필요할까?
• Roslyn(로즐린), 과연 누구를 위한 프레임워크인가?
• 결론은 있어도 그만, 없어도 그만…

1.1. Compiler as a Services 가 과연 내게 필요할까?

컴파일러(Compiler)의 기능의 일부는 닷넷 프레임워크(.NET Framework)에서 제공해주지만 이 APIs를 필요로 하는 사람은 얼마나 될까? 안그래도 가뜩이나 무거워진 닷넷 프레임워크(.NET Framework)는 사용자의 PC에 다운로드하고 설치하려면 사용자는 매우 지루할 만큼의 시간이 걸린다.

그래서 Microsoft는 가장 최신의 닷넷 프레임워크(.NET Framework) 4.5 환경에서 돌아가도록 컴파일된 바이너리를 최소한 .NET Framework 3.5 SP1이 설치된 PC에서 실행이 되도록 컴파일 옵션에 이것이 가능하도록 해주어야 한다. 전혀 불가능한 것이 아니다. 이와 유사한 도구들이 있고, 또 이와 유사한 Visual Studio SDK에 포함되는(또는 Visual Studio) CorFlags.exe[2] 도 있다.

우리가 닷넷 프레임워크(.NET Framework)를 사용하는 가장 큰 이유는 풍부한 라이브러리에 있다. 이 라이브러리를 이용하면 데스크탑 응용 프로그램과 웹 응용 프로그램, 그리고 커뮤니케이션 서비스(Communication Services)를 매우 쉽게 개발할 수 있다는 생산성이 가장 큰 장점이다.

최근 64비트 머신을 많이 사용한다. 서버 머신도 데스크탑 머신도, 울트라북도 64비트 머신이다. 닷넷 플랫폼(.NET Platform)은 이런 AnyCPU 환경에서 동작한다는 것 또한 큰 장점이다.

이 모든 것이 .NET이 관리 언어이고, 이를 중간 언어로 컴파일하기 때문에 누릴 수 있는 이점들이다. 왜냐하면 .NET의 JIT(Just in Time) 컴파일러가 어느 환경에서도 동작할 수 있는 로우 레벨(Low Level)의 코드를 런타임(Runtime)에 만들어 주기 때문이다. 그래서 .NET 개발은 더 이상 스택(Stack)이나 버퍼(Buffer) 오버플로우를 신경조차 쓰지 않아도 C# 컴파일러가 코드를 최적화하여 중간 언어(IL)로 만들어 주고, JIT(Just in Time) 컴파일러가 필요한 IL 코드만 런타임에 컴파일하고 메모리상 기계어 코드가 어디 위치할지 짐작조차 하기 힘들게 만든다.

그래서 C# 컴파일러는 포인터가 필요한 코드에 unsafe 키워드를 제공해 주지만, C# 컴파일러도 unsafe 한 코드를 무척이나 싫어한다. 이 안에서 포인터 변수는 fixed 키워드로 묶어서 가비지 컬렉션(Garbage Collection)이 일어나지 않도록 알려주는다. “이 쓰레기는 절때 치우지 말고 냅두라고…”

우리는 더 이상 컴파일러에 대해 신경을 쓰지 않아도 된다. 즉, 어떻게(How)가 중요한 시대가 아니라 무엇을(What)을 할 것인가를 집중하도록 언어와 플랫폼이 성장해 왔다. 그리고 이는 닷넷 플랫폼(.NET Platform) 이 추구하는 목적과도 잘 부합된다.

그러나 다시 컴파일러(Compiler)로 귀환이라니… (사전적인 컴파일러가 아닌 이 글에서 이야기 하는 의미의 컴파일러)

1.2. Roslyn(로즐린), 과연 누구를 위한 프레임워크인가?

많은 닷넷 플랫폼(.NET Platform) 개발자들에게 Roslyn(로즐린)이 제공하는 서비스가 필요한지 생각해보자. 여러분도 이 서비스 라이브러라가 과연 나에게 필요한지도 한번 생각해보자.

Roslyn(로즐린) White Paper에 의하면 Roslyn(로즐린) 은 C#, VB.NET 언어를 이용해서 새로운 언어를 만들고 스크립트 실행이나 인터렉티브가 가능하다고 한다.

The Microsoft “Roslyn” CTP previews the new language object models for code generation, analysis, and refactoring, and the upcoming support for scripting and interactive use of C# and Visual Basic. This document provides a conceptual overview of the Roslyn project. Further details can be found in the walkthroughs and samples included in the Roslyn CTP.

우리는 언제 Roslyn(로즐린)이 필요할까? Roslyn(로즐린)이 제공하는 파이프라인(APIs+Services) 을 보면서 다시 얘기해 보자. (Roslyn White Paper 웹 페이지의 이미지 참조)

첫 번째로 아래의 그림은 Roslyn(로즐린)의 파이프라인(Pipeline) 도식이다.

두 번째로 아래의 그림은 Roslyn(로즐린)의 컴파일러(Compiler) APIs 도식이다.

세 번쨰로 아래의 그림은 Roslyn(로즐린)의 언어 서비스(Languages Services)의 도식이다.

전체적으로 어떤 구성인지 요약해 보자. 여러분은 구성들을 보면서 이 중에서 필요한 것이 있는지 살펴보기 바란다. (일부 구성요소는 생략한다)

Roslyn(로즐린)의 구성 요소

1. 컴파일러(Compiler) APIs
   MS가 잘 만들어 놓은 MSBuild가 있다. 빌드(Build)라는 것은 일련의 작업(Tasks)이 순차적으로 표현하는, 컴파일러(Compiler)의 상위 개념이다. 그리고 자바(Java)에 영향을 받은 오픈 소스인 NAnt도 있다. MSBuild는 이 중 제일 꼴지로 나왔다. 그만큼 표현 문맥과 기능이 가장 세련되었다. 즉, 빌드라는 것은 컴파일부터 시작해서 배포(Deployment)가 가능한 단계까지 거의 모든 단계가 포함이 된다.
   컴파일러(Compiler)는 빌드(Build)라는 작업 중의 하나의 작업 단위로 보면 된다. 코드 문법적인 검사를 하고 소스 코드를 목적 코드(Object Code)로 잠깐 만들어 놓는다. 그리고 실행에 직접 필요한 코드와 이 코드들이 참조하는 메타데이터(Metadata)로 나눈 후 다시 싸그리 모아 실행이 가능하고 메모리에 로드할 수 있는 바이너리(Binary)를 최종적으로 만들어 낸다. 여기에서 내부적으로 사용하는 APIs들은 아주 조금 닷넷 프레임워크(.NET Framework)에 포함이 되어있다. 필자의 지난 Umc.Core 프레임워크 다이나믹 프록시(Dynamic Proxy) #1 에 관한 아티클에서 언급한 일부에 포함이 되어있다.

2. 언어 서비스(Language Services)
   언어 서비스(Language Services)는 Microsoft가 숨겨놓고 못쓰게 해 놓은 DLL 중 하나다. 과거부터 현재 Visual Studio 2012까지 포함되어 있는데, 예전부터 지금까지 이 언어 서비스(Language Services)는 C/C++로 만들어진 네이티브(Native)로 비주얼 스튜디오(Visual Studio)와 함께 바이너리가 배포된다.
   필자는 예전부터 Visual Studio SDK를 이용하여 많은 확장 기능을 만들어 왔다. 가장 마지막에 배포한 확장 기능이 VsGesture라고 하는 확장기능이다. 오픈 소스로 공개도 해놓았으니 관심 있는 분들 참고해도 좋다. 그래서 Visual Studio의 내부적인 구조를 꽤 많이 아는 편이다. 이 언어 서비스(Language Services) 네이티브 라이브러리는 참조해도 직접적으로 사용하지 못하고 상당히 제약이 많다.
   Roslyn(로즐린)에는 Visual Studio 고유의 기능인 에디터(Editor) APIs 도 포함된다. 구문(Syntax)와 토큰(Token)에 따라 코드 구문을 꾸밀 수 있는 데코레이션(Decoration) APIs 들도 포함이 된다.

구성요소를 더 잘게 쪼개서 설명해 주고 싶으나, 주제와 점점 벗어져 나가는 것이 느껴지기에 여기까지만 설명한다.

그렇다면 처음에 말한 것 처럼 이 Roslyn(로즐린)이 당신이 개발하는 응용 프로그램에 얼마나 많은 도움을 줄 수 있을까 생각해보면 거의 직접적으로 도움이 되지 않는 것이라고 생각해 볼 수 있다.

1.3. 결론은 있어도 그만, 없어도 그만…

여러분이 기업에서 단체에서 학교에서 개인적으로, 쓸만한 APIs 인지 생각해보라. 이런 걸로 간단한 에디터나 새로운 언어를 만드는데 매우 유용하겠지만, 얼마나 많은 곳에서 이 유용함이 필요한지 사실 걱정이다. 이런 툴이나 도구를 만드는 회사에서는 정말 반가운 소식이겠지만 말이다.

그리고 속한 조직에서 개인적 이유 등 새로운 언어가 필요했다면 이미 파이썬(Python), 루아(Lua), 웹킷 자바스크립트 V8 엔진(Webkit), 심지어 족보도 없는 언어(Languages)들이 오픈 소스로 널려 있다. 필요했다면 벌써 이들을 이용하여 도메인 전용 언어(DSL-Domain Specification Languages)를 만드는데 큰 어려움이 없을 것이다. 심지어, 이런 언어를 만들 수 있는 프레임워크도 찾아보면 몇몇 된다.

결론적으로 Roslyn(로즐린)이 제공하는 APIs들은 굳이 없어도 되는 프레임워크다. 더 잘 구현된 것들이 많이 있다. Roslyn(로즐린) 프레임워크의 장점이라면 올인원(All in One), 다 쑤셔넣어 통합시킨 것에 의미가 있다. 그 이상 그 이하도 아니다.

통합… 하지만 최근 오픈 소스 시대에서 통합은 매우 위험한 트랜드이다. 너무 강한 응집력과 확장의 제한이 있을 수 있다. 통합이라는 것은 모든 것을 만족시키지만, 모든 것을 만족시키지 못하는 양날의 검과 같다. 팀 파운데이션 서버(Team Foundation Server)와 같이 모든 것을 한데 통합시켜 놓아서 모든 것을 만족시키지만, 사실 어느 한가지를 제대로 만족시키지 못하는 그런 통합이 대부분이기 때문이다.

이유 2. 비주얼 스튜디오(Visual Studio)와 통합 예고

• 완벽함은 더 이상 뺄 것이 없을 때 완성된다.
• 느려질 수 밖에 없는 WPF 껍데기와 코드
• Roslyn(로즐린)과 비주얼 스튜디오(Visual Studio) 통합은 쥐약!!

2.1. 완벽함은 더 이상 뺄 것이 없을 때 완성된다.

비주얼 스튜디오(Visual Studio)는 매번 기능을 만들어 내고 개선하는 것은 새로운 버전에서 매우 중요한 부분이다. Visual Studio 2002/2003부터 사용해 본 사람들이라면 항상 새로운 버전에서 실망을 한다. 새로운 기능은 언제나 어정쩡하거나 버그 투성이로 출시된다. 그리고 서비스 팩(Services Pack)으로 떄운다.

필자가 예전에 작성한 글을 참고하면 비주얼 스튜디오(Visual Studio)의 역사에 대해 좀 더 쉽게 이해할 수 있을 것이다. - [월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012 - .NET 의 과거와 현재, 그리고 미래 - .NET 체제 및 개발 환경/언어의 버젼 정리

요즘은 새로운 비주얼 스튜디오(Visual Studio)가 출시가 되면 ‘얼마나 느려졌을까?’가 최우선으로 점검한다. 얼마나 느려졌을까를 걱정을 한다면 분명 초기 버전은 느리지 않았을 거라 예측할 수 있다.

시대가 변할 수록 컴퓨터의 파워가 증가하는데, 아래의 필자의 체감은 그 시대의 컴퓨터 파워 성능의 체감 속도라는 점을 참고하기 바란다. (필자가 느끼는 것과 다른 체감을 할 수 있을 것이다.)

필자가 비주얼 스튜디오(Visual Studio) 2010 버전부터 사용한 노트북의 사양은 다음과 같다.

SONY VPCZ115/GK, Intel Core i5–540M 2.53GHz (Turbo Max 3.06GHz), Hypervisor, 8GB RAM, Samung SSD 256GB, Intel HM57 Express, L3 Cache 3Mb,

• Visual Studio 2002/2003
  클릭하면 바로 떴다. 파일 바로 생성된다. 종료 바로 된다. 빌드 만족한다. 에디터 전혀 굼뜨지 않고 빠릿 빠릿. (필자 컴 성능 보통)
• Visual Studio 2005
  구동 느려졌다. 빌드 느려졌다. 에디터가 꿈떠지기 시작했다. (필자 컴 성능 보통)
• Visual Studio 2008
  더 느려졌다. 솔루션 불러오기 느리다. 종료도 느리다. 에디터 마찬가지로 좀 꿈뜬다. (필자 컴 최신컴)
• Visual Studio 2010
  기존 윈도우폼+WPF로 바꿨다. 완벽하게 느려졌다. 메뉴에 마우스 커서를 대면 한참 있다가 포커스가 온다. 에디터 나쁘지 않았는데, 오래 켜 놓을 수록 기가 막히게 느려진다. 비동기 UI로 바꿨으면 체감 성능 향상 기대 하지만 더 느려진 건지 헷갈림. 솔루션 불러오기 완전 느리다. 주기적으로 재시작 해야할 정도로 뭔가가 있었다.
• Visual Studio 2012
  이전 버전보다는 나아졌다. 완벽하게 느린 개발툴. 비동기 UI로 되려 느려진 것들이 덜 느려짐. 오래써도 안느려짐. 에디터 한번씩 순간적으로 반응이 멈춤. 솔루션 탐색기 파일 열 때 느려짐. 성능 개선은 이전보다 되었음 하지만 상대적으로 개선됨. 절대적으로 여전히 느림.

더 이상 뺄 것이 없다면 아직도 발전해야 할 것이 있어서 그런다고 믿고 싶다. 비주얼 스튜디오(Visual Studio) 가 완벽하지 않기에, 성숙기에 도달한다면 그 때는 분명 무엇을 빼야 할지 고민해 볼 필요가 있다.

하지만 과연 지금 여러분이 쓰고 있는 비주얼 스튜디오(Visual Studio) 의 수백여 가지 기능 중에 몇 퍼 쓰고 있는지요?

비주얼 스튜디오(Visual Studio) 기능 전체가 100% 라면 아마 아래와 같지 않을까?

• 자주/매일 쓰는 기능 : 5%
• 한 달에 한번 쓸까 말까 기능 : 4%
• 어쩌다가 한 번 쓰는 기능 : 2%
• 써보지 않은 기능 / 있어도 안쓰는 기능: 89%

또 한 가지 더, 비주얼 스튜디오(Visual Studio) 기능을 얼마나 썼는지 체크할 수 있는 방법이 있다. 예를 들어, ASP.NET MVC 4 프로젝트, ASP.NET 웹폼 프로젝트, 시퀸스 워크플로우, 뭐 이런 프로젝트를 일컫는 것이다.

• 현재 가진 버전에서 만들 수 있는 프로젝트 개수 - 만들어본 프로젝트 개수
  = (안만들어 본 프로젝트 개수)
  = 안쓰는 기능 몇 퍼? (아마 추측으로 대부분 안쓰는 기능 80% 될 듯 합니다)

필자가 좀 짜게 준 것 같은데, 정말 짜게 준 것일까? 여러분이 넉넉하게 줘보세요. 몇 퍼가 나오는지 저도 궁금하네요 ^^

마지막 한 가지, 대부분 디버깅을 하는 능숙도와 기능 활용도만 보아도 개발툴 전체 활용을 얼마나 하는지 짐작이 가능하다. 생각나는 것만 적었지만, 능숙하게 할 수 있는 것들만 골라보시면 그게 곧 점수다.

• 디버깅 및 프로세스 디버깅
• 디버깅 중 편집
• 브레이크 포인트 / 조건부 브레이트 포인트
• SQL 쿼리, 자바스크립트 등 디버깅
• 디버깅 스택, 디버깅 변수 관리
• 명령줄 기능
• 간략한 조사식
• 브레이트 포인트 관리 기능
• 심볼 로드 소스 코드 디버깅
• 디버깅 상태 저장, 다음에 다시 로드
• 스레드 스택 디버깅
• 스레드 시각화하여 문제 및 병목 해결
• 이하 생략…

추측건데 안 쓰는 기능이 평균 80% 정도는 될거다.

안쓰는 기능이 많아서 점수가 높더라도 전혀 기분 상하지 않아도 된다. 안쓰는 기능이 많은 만큼 빼야 할 기능이 많다는 얘기고, 정령 개발툴을 사용하는 개발자의 니즈(Needs)를 파악하지 않은 사람들이 문제라고 생각한다.

자신에게 딱 맞춤 옷이 가장 편하듯이, 필요한 기능만 설치하고, 더 필요하면 확장 기능/플러그인 형태로 보탤 수 있도록 하면 지금보다 훨씬 날렵한 개발툴이 될 것이다. 참고로 비주얼 스튜디오(Visual Studio) 2005 버전부터 모든 구성요소는 플러그인(Plugin) 형태다. 이 플러그인이 얼마만큼 포함되었는지에 따라 프로페셔널(Professional), 얼티밋(Ultimate) 에디션으로 구분을 한다. (당시 에디션 구분과 현재 에디션은 다르다)

비주얼 스튜디오(Visual Studio)와 팀 파운데이션 서버(Team Foundation Server)는 통합이라는 것을 매우 강조하고 그것이 장점이자 단점이다. 통합이란 완벽하게 통합하지 않을 거면 그냥 거추장 스러운 혹을 여러개 달고 있는 것이나 마찬가지이다.

2.2. 느려질 수 밖에 없는 WPF 껍데기와 코드

지금도 충분히 느리고, 이런 개발툴 자체의 퍼포먼스(Performance) 개선은 마이크로소프트도 두손 두발 다 들었고, 새로운 기능을 넣는데에만 집중하는 것이 아닌지 착각이 들 정도이다.

개인용 컴퓨터 파워가 아무리 증가해도 내 주머니 사정상 매번 쫓아갈 수가 없다.

비주얼 스튜디오(Visual Studio) 2003, 2005, 2008 버전은 아름다운 기술 조합으로 완성이 되었다. 코어(Core)는 네이티브(Native), 껍데기는 윈도우 폼(Windows Form) + NativeWindow(IWin32Window) 조합으로 만들어졌다. C# 코드로 COM Interface를 불러 쓰는 형태였기 때문에 UI Binding 작업을 제외하면 무척 빨랐다. 에디터도 모두 COM Interface로 핸들링 해야 했다.

비주얼 스튜디오(Visual Studio)는 2010 버전부터 데스크탑 응용 프로그램에서 가징 많은 리소스를 차지하고 구동 성능이 가장 느린 WPF(Windows Presentation Framework)로 껍데기를 바꾸면서 악몽이 시작된다. 에디터를 WPF로 바꾸면서 UI 바인딩 방법도 WPF 형태로 바뀌었다. 에디터 하나에 여러 개의 느린 WPF 레이어가 걸쳐지고, 확장 기능을 설치하면 경우에 따라 또 에디터에 레이어를 걸쳐놓는다. 완벽하게 느려질 수 있는 구조를 아직까지 고수하고 있다.

현재 WPF 에디터는 XAML(eXtansible Application Markup Language) 완벽하게 느릴 수 밖에 없는 마크업 언어를 이용한다. 국제 표준인 아름다운 XML과 Microsoft의 비표준 규격인 CLR을 짬뽕시켜 놓은 덕에 어느 벤더도 관심을 갖어주지 않는 또 하나의 독자 기술을 만들어 냈다. 특히 XAML은 객체지향 언어의 표현이 가능한데, 거기에다 UI 요소와 백터(Vector), 바인딩(Binding), 트리거(Trigger), 이벤트 버블링(Event Bubbling) 과 같은 너무 많은 요소를 넣어 놓았다. 또 거기에 그래픽을 처리하는 다이렉트X(DirectX)를 걸쳐놓아서 XAML이 UI 하나 표현하려면 XAML Loader, XAML Parser, DirectX Interop 등 많은 단계를 거치게 되어 되레 엄청 느려진 UI 표현 기술이 되었다.

과거 네이티브(Native) 에디터 시절에는 굳이 겹겹히 레이어를 덮을 필요 없는 GDI/GDI+면 충분했다. 그리고 에디터를 꾸미기 위해서 IVsTextManager, IVsTextMarker, IVsEnumStreamMarkers 등 COM Interface 로 제공되는 인터페이스와 GDI/GDI+/Bitmap을 이용하여 얼마든지 화려하고 인터렉티브한 에디터 기능이 가능했다.

결국 비주얼 스튜디오(Visual Studio) 2010, 2012 버전부터는 똑같은 에디터를 핸들링 하기 위해서 두 가지 모드를 제공한다. 네이티브 기반(Properties, 속성 창 등에서 사용)의 에디터와 WPF 에디터. 그리고 똑같은 역할을 하는 네이티브 API와 관리 언어로 작성된 API 두 가지가 존재한다. 물론, 네이티브를 남겨 놓은 것은 하위 호환성을 유기 하기 위함이다. 실제 동작은 WPF 에디터의 동작으로 연결된다.

누가 그랬던가, ‘마이크로소프트가 망해도 XAML은 남을 것이라고…’ 이건 XAML이 처음 나올 때의 얘기고, 이제는 어떤 벤더도 성큼 사용하지 않는 마이크로소프트의 완벽한 독자 기술이 되었다. WPF의 성능도 개선이 되면 개발툴의 성능도 개선이 될텐데, 성능에 자신이 있어서 그런지 WPF 버전 4.5의 새로운 기능을 보면 ‘성능’이라는 단어는 딱 3번, 성능이 개선된 기능은 딱 1개에 불과하다.

Mono-Project 에서 .NET과 호환이 가능한 목록을 살펴보면 WPF는 Mono에서 계획조차 하지 않는다고 한다. 다른 플랫폼으로 포팅조차 될 수 없는 기술이다.

WCF - silverlight 2.0 subset completed
WPF - no plans to implement
WWF - Will implement WWF 4 instead on future versions of Mono.

2.3. Roslyn(로즐린)은 비주얼 스튜디오(Visual Studio) 차기 버전에 통합

필자는 2007년도에 Comment Helper라는 주석달기 애드인을 만들면서 2011년도까지, 거의 5년 동안 Visual Studio SDK를 이용하여 Visual Studio 내부적인 구조 등을 이해하기 위해 상당히 많은 시간을 투자하여 공부해왔다. 그래서 지금까지의 내용 모두 괜한 추측성이나 거짓 내용은 없다고 보면 된다.

지금까지 비주얼 스튜디오(Visual Studio) 내부적으로 빠른 부분, 느린 부분 등 일부 만을 설명했다. 더 많은 부분은 여기에서 생략하도록 하겠다.

Roslyn(로즐린)이 비주얼 스튜디오(Visual Studio)와 통합이 된다면 상당 부분의 네이티브 코어(Native Core)를 대체할 수 있다. 비주얼 스튜디오(Visual Studio)가 이클립스(Eclipse)와 같은 완벽한 관리 언어(Managed-Language) 기반을 꿈꾸고 있다면 당장 포기하는 것이 낫다.

필자는 거의 4년을 부하테스트와 테스팅 기술을 실무에서 적용해 왔다. 마지막 직장이었던 엔씨소프트(ncsoft)에서 테스트 시스템 자체를 최초로 도입시켰고 고가 장비에 구축하였고, 대만 NCTaiwan에서 초대규모 부하테스트 업무를 혼자서 2주 동안 진행해 본적도 있다. 소소한 것 까지 치자면 너무 소소해져서…

이 이야기를 하는 이유는 솔직히 필자는 닷넷 플랫폼(.NET Platform)의 쓰레기 청소부인 GC(Gabage Collector)를 백퍼, 아니 80%도 신뢰하지 않는다. 부하테스트를 하다보면 ‘아~ 이래서 이럴 때는 .NET, Java 등을 쓰면 안되겠구나’ 를 뼈저리게 느낀 적이 많다.

C++과 C#, 똑같이 짠 비효율적인 코드가 부하 상태에서는 C#이 구석에 박혀 찌그러져 있어야 할 정도로 패배를 인정해야 한다. ‘최근 서버 성능과 파워가 좋아져서…’. 필자가 말한 상황이라면 돈이 많으면 돈으로 바르고, 돈이 없으면 관리 언어를 안쓰거나 완벽하게 리팩토링 하는 것이 대안이 될 것이다. 예전에 필자가 쓴 [ALM-Testing] 10. 부하테스트 이야기, 테스트 데이터 분석 문제 풀어보세요.에서 다음 회차로 쓸 글에 그 답이 있을 예정인데, 귀찮아서 여태까지 안쓰고 있었다.

런타임에 생성되는 동적인 코드들은 가비지 컬렉션(Garbage Collection)의 대상이 될 수도 있지만, Roslyn(로즐린)에서 사용하는 것들은 대체적으로 가비지 컬렉션(Garbage Collection) 대상이 될 수 없는 것들이 많다. 고로, 차기 Roslyn(로즐린)과 통합되는 비주얼 스튜디오(Visual Studio)는 사용할 수록 느려지거나, 점점 더 많은 리소스를 선점해야 할 가능성이 매우 농후할 것으로 예상된다.

결론은 Roslyn(로즐린)이 비주얼 스튜디오(Visual Studio) 차기 버전에 통합이 된다면, 얼마나 느려지게 될 지 상당히 주목된다.

하지만 개발툴 내부적으로 동적 컴파일이 많이 일어날 것이고, 소스 코드를 컴파일하지 않고도 코드를 변경하여 결과를 볼 수 있거나 인터렉티브한 요소들이 개발 환경을 상당히 개선할 것이라는 것에 대해 일절의 의심은 없다.

이유 3. 하둡과 대결 구조 정도 되는 프로젝트를

마이크로소프트는 사실 오픈 소스를 사랑하는 기업이 아니다. 마이크로소프트의 제품 대부분 소스 코드를 취득할 수 있는 통로가 없다. 그 대신 CodePlex와 같은 오픈 소스 공간을 마련한 건 대단히 여기나 시기 상으로 너무 늦어 버렸다. 이미 오픈 소스는 구글 코드(Google Code)나 아파치 재단(Apache Foundation)가 주도하고 있다.

CodePlex의 많은 오픈 소스 프로젝트들이 GitHub로 이사하고 있다. CodePlex에는 다른 곳으로 이사 가고 남은 무덤들이 넘처난다.

• 2년이 넘도록 릴리즈를 못할 정도의 규모가 아닌 Roslyn(로즐린)
• 수 년전에 이미 오픈 소스화 된 것들인데, 진정 생색내기용 Features?

3.1. 2년이 넘도록 릴리즈를 못할 정도의 규모가 아닌 Roslyn(로즐린)

Roslyn(로즐린) 프로젝트도 그 자체가 문제다. 고급 인재들을 가지고 있으면서 이미 오픈 소스로 다 있는 Compiler as a Services를 또 다시 만든다는건 이해하기가 조금은 힘들다. 오픈 소스 외에도 이미 자체적으로 모두 다 만들어 놓은 라이브러리들이 있으면서도 말이다.

2011년도 8월에 Roslyn CTP 버전이 일반에게 공개가 되었다. 그렇다면 훨씬 그 이전에 개발을 시작했다고 볼 수 있는다. 한 가지 재미있는 의혹은 Roslyn(로즐린) 프로젝트의 규모를 본다면 2년을 넘게 할 만큼 프로젝트 규모 면에서 크지 않다. 뭐 Microsoft 내부적으로 정치적인 문제 등이 있을 수 있겠지만, 2년 동안 끌고 아직도 제대로 릴리즈를 하지 못했다는 건 이유 불문하고 의심의 여지가 있다.

2012년 3월 기사의 내용 중 ‘아직 준비가 안됐다’ 라고 얘기했다. 내용으로 보아 Visual Studio에 포함 시킨다는 걸 알 수 있다. 어느 기사에서 포함될거라고 언급한 내용을 읽은 기억이 있다

10. Will Roslyn be released in the next version of Visual Studio?
No, Roslyn won’t be ready in time for it to be included in the next version, code-named Visual Studio 11. Microsoft hasn’t committed to a release date at this time. [3]

필자의 정보력이 부족할 수 있겠을지 모르겠지만, Roslyn(로즐린)은 아직 정확한 릴리즈 시점도 공개하지 않았다. 아니면 비주얼 스튜디오(Visual Studio) 차기 버전에 조용히 포함되어 출시될 수도 있다.

3.2. 수 년전에 이미 오픈 소스화 된 것들인데, 진정 생색내기용 Features?

필자는 Mono Project에 매우 관심을 가져왔다. Mono 소스 코드를 감상하는 것은 매우 즐거운 일이며, Microsoft가 닷넷 프레임워크(.NET Framework) 에서 제공해 주지 않거나 불가능 하다고 일침을 놓았던 것들이 Mono 에서는 모두 가능하다.

Mono Project의 소스 코드를 이용하여 파생되어 탄생하는 오픈 소스들도 상당히 많다.

Roslyn(로즐린), But 하지만, Mono Project에서 이미 다 구현된 구현체가 있다. Roslyn(로즐린)이 제공하는 파이프 라인과 서비스는 다음의 Mono Project에서 확인할 수 있다.

• Mono Cecil[4] - 닷넷 어셈블리, C# 코드, IL 코드, 디컴파일(Decompile), 디버그 심볼(PDB) 지원
• Mono CSharp Repl[5] - (Read-Eval-Print Loop) C# 스크립트 언어 + 인터렉티브
• Mono AOT[6] - (Ahead of Time) 컴파일된 어셈블리를 네이티브(Native) 코드로 변경 (ngen.exe 유사하지만 다름)
• Mono Debugger - 디버거
• Mono Develop - 통합 개발툴 (IDE), 여기 소스 코드에 코드 에디터, 코드 분석, 코드 포메팅, 새로운 언어를 작성할 수 있는 언어 서비스(Language Services), 컴파일러, Mono용 MSBuild

몇 가지만 나열했지만, 지금 나열한 몇 가지는 그 중 작은 일부이다.

위에 언급한 몇 가지 어셈블리만 참조하고 간단한 몇 가지 예제 코드를 만들어 보면 Roslyn(로즐린)의 as a service / pipeline / editor / language service 등이 무색할 정도라는 것을 알 수 있을 것이다. 아니, 통합되지 않은 것만 빼면 Mono의 것들이 확실히 더 강력하다는 것을 알 수 있다.

작년인가 미국 본사에서 Roslyn(로즐린)을 개발한다는 한국인과 페이스북에서 이야기할 기회가 있었다. Roslyn(로즐린)에 대해 침을 튀기며 자랑을 하길래 필자는 “그거 Mono에 이미 다 있던데요” 라고 했었다. 하지만 그는 Mono의 것들은 전혀 들어보지는 않았지만, 자신의 프로젝트는 전혀 새로운 것이라고 맹신 하고 있었다

Roslyn(로즐린)을 개발하는 Microsoft 본사 직원도 Mono Project의 컴파일러 서비스들을 본적도, 들어본적도 없다고 하고, Roslyn(로즐린)이 최초이고 가장 완벽하다고 착각하고 있는데, 무슨 말이 더 필요하겠나 싶었다.

요즘 참 할일도 많은데 할 수 있는 일이 점점 줄어든다. 필자는 블로그 버킷 리스트(bucket list)를 작성하는데 블로그가 사망하기 전에 꼭 해야 할 일을 목록으로 만들어 놓고 하나 하나씩 글을 써 나간다. 근데 할 일이 늘어만 간다. ㅠ

• 당장 쓸 수 있는 글 39개
  사소한 개발 기술부터 심도있는 내용으로 흐리멍텅한 개념을 글을 쓰면서 잡아 나가는 것들

• 개발 후 산출물로 쓸 글 37개
  오픈소스로 내놓을 계획, 또는 알고 있는 것들에 대한 증명이 필요하고 그 후에 쓸 수 있는 글

• 연구개발 11개
  배우고 싶은 것, 하고 싶은 것, 해야 하는 것들이고 공부해야 쓸 수 있는 글들

아무튼 점점 쓸 것들이 늘어만 가지만, 하나 하나 하다보면 쓸게 없어 지는 날이 올거라 믿는다 >.,<

#1 - Umc.Core 프레임워크 다이나믹 프록시(Dynamic Proxy)

다이나믹 프록시(Dynamic Proxy)는 최근 IoC(Inversion of Controls)라는 개념으로 확장되고 객체지향 프로그래밍(OOP)의 효율성을 극대화한다. 다이나믹 프록시 기법은 이미 오래 전부터 존재해 왔다.

C++의 스마트 포인터(Smart Pointer) 처럼 직접 포인터를 건들이지 않고 레퍼런스 카운팅이나 객체의 생명주기를 프록시 개체(Proxy Object)를 통해 관리하는 기법이 있고, RPC(Remote Procedure Call)과 같은 원격 프로시저 호출을 위해 프록시 패턴(Proxy Pattern)이 기반에 깔려 직접 원격 구현을 숨기고 간단한 인터페이스만 제공해 주는 패턴 등 매우 다양하다.

최근의 다이나믹 프록시(Dynamic Proxy)는 IoC(Inversion of Control), DI(Dependency Injection), ORM(Object Relation Mapping), AOP(Aspect Oriented Programming) 등 객체를 다루는 프레임워크에서 기본적으로 채용할 만큼 객체를 다룸에 있어 가장 기본적인 기법 또는 기술에 속한다.

필자가 오늘 다루어 볼 내용은 이런 프록시 패턴(Proxy Pattern)이 기반이 되는 개체 제어를 위한 기법이다.

먼저 다이나믹 프록시(Dynamic Proxy)에 대해 예전에 잠깐 쓴 글을 참고하자.

• DxEF.Proxy.Dynamic 프레임워크 개발
• DxEF.Proxy.Dynamic.SoaServices 프레임워크 개발

과거 2009년도 닷넷엑스퍼트 재직 시절에 다이나믹 프록시(Dynamic Proxy)를 만들었다가, 2011년 좀 더 나은 객체 디자인으로 완전히 다시 만든 다이나믹 프록시(Dynamic Proxy) 프레임워크가 지금 설명할 Umc.Core.Dynamic.Proxy 이다.

Umc Core 프레임워크는 오픈 소스로 공개되어 있으며 누구든지 소스 코드를 열람할 수 있다. 현재 소스 코드는 다음의 링크를 통해 제공된다.

• 코드 플랙스(CodePlex) - http://umccore.codeplex.com
• github - https://github.com/powerumc

#2 - 코드부터 보자.

만약 관리 언어(Managed Language)의 동작 매커니즘을 이해하지 못했다면 마치 마법과도 같은 기법으로 보일 것이다. 아래의 코드는 완벽하게 돌아가는 소스 코드이다.

using System;  
using Umc.Core.Dynamic;  

namespace ConsoleApplication1
{  
public interface IPerson
{
    string Name { get; set; }
    string Email { get; set; }
}  

class Program
{
    static void Main(string[] args)
    {
        var type   = DynamicProxyObject.InterfaceImplementationType<IPerson>();
        var person = (IPerson)Activator.CreateInstance(type);

        person.Name  = "POWERUMC";
        person.Email = "powerumc at 지멜";

        Console.WriteLine("Name : {0}, Email : {1}", person.Name, person.Email);
    }
}
}  

한번 위의 코드를 보자. IPerson 인터페이스는 IPerson을 구현하는 클래스가 반드시 있어야 객체를 생성할 수 있다. 다음과 같이 말이다.

public class Person : IPerson
{
    public string Name { get; set; }
    public string Email { get; set; }
}   

C#의 상식으로 보아도 인터페이스(Interface)는 인스턴스를 생성할 수 없으며, 인스턴스를 생성하기 위해 구현 클래스가 반드시 존재햐여 하는 것 쯤은 알고 있을 것이다. 즉, Person 클래스가 있어야 IPerson person = new Person(); 으로 객체를 생성할 수 있다. 분명, 처음 코드의 DynamicProxyObject.InterfaceImplementationType<IPerson>(); 가 뭔가의 마법을 부리는 것이 확실하다고 보면 된다.

#3 - 다이나믹 프록시(Dynamic Proxy) 의 다른 구현 방법들

방금 언급한 DynamicProxyObject.InterfaceImplementationType<IPerson>(); 코드가 바로 class 로 구현조차 되지 않은 클래스를 동적(Dynamic)으로 런타임에 생성한다. 이 동적 클래스를 런타임에 생성하기 가장 쉬운 방법이 있는데, 그것은 .NET Framework에서 제공하는 CodeDomProvider 이다.

간단히 CodeDomProvider를 언급만 하고 넘어가보자. CodeDomProvider는 C#, VB.NET의 객체 표현을 Code Dom으로 표현할 수 있는데, 각각 CSharp, VB.NET Provider를 제공해 주고, 런타임에 컴파일을 한다. 다만, 컴파일 시간이 동적 객체 생성 기법 중에 가장 느리다.

그리고 C# 3.0부터 지원하는 람다 표현식(Lambda Expression)을 이용하는 방법이다. 이 람다 표현식도 내부적으로 CodeDom과 매우 유사하다. 단점이라면, 객체의 이름(Class Name)과 주소(Namespace) 등을 원하는데로 줄 수 없다. LambdaExpression 클래스의 맴버들이 많은데, 이것들로 모든 구현이 가능하다. 간단한 예제 코드를 보자.

Expression<Func<string, string>> expression = (s) => "Hello " + s;               
var func = expression.Compile();               
var ret = func("POWERUMC");   
Console.WriteLine(ret);

이 코드를 실행하면 “Hello POWERUMC” 라는 결과가 나오는 것을 확인할 수 있다.

이렇게 알게 모르게 이미 .NET Framework에서 다이나믹 프록시(Dynamic Proxy) 기법을 쓰는 곳이 의외로 많다. C# 컴파일러는 익명의 표현식들을 내부적으로 컴파일하면서 메서드로 만들어 버리기도 한다. 이렇게 똑똑한 컴파일러 덕분에 람다 표현식이나 LINQ의 성능이 매우 좋다는 것이다.

이 외에 동적메서드(DynamicMethod) 방법이 있는데, 얘는 그냥 넘어가도 무관하다.

#4 - 다이나믹 프록시(Dynamic Proxy) 개체가 생성되는 일련의 순서

동적 개체가 만들어지려면 어떤 순서가 필요할까?

먼저 객체지향 언어라는 점을 생각해볼때, 객체의 주소(Namespace)와 이름(Type Name)이 필요하다. 필자의 프레임워크 코드 중 Umc.Core.Dynamic.Proxy.Builder 네임스페이스의 ModuleBuilderExtension와 TypeBuilderExtension이 그 역할을 한다.

Type을 생성하기 위해서는 생성자 하나 이상이 반드시 필요한데, Object를 상속하는 타입을 만들어야 한다. 아시다시피 public class Person 클래스는 암묵적으로 public class Person : Object 를 상속하게 된다. 그래서 타입을 생성하고 하나의 생성자를 만들고 나면, 부모 객체인 Object의 생성자(Constructor)를 호출을 해주어야 한다. 당연히 부모가 있어야 자식이 있는 것과 같다.

이 때 반드시 주의해야 하는 것이 있다. 생성자는 인스턴스를 생성하는 생성자가 있고, static 생성자가 있다. 만약 static 생성자인 경우는 부모 객체인 Object 생성자(Constructor)를 호출하면 안된다.

Object 생성자를 타입의 생성자 안에서 호출하려면 다음과 같은 코드를 이용하면 된다.

il.Emit(OpCodes.Ldarg_0);  
l.Emit(OpCodes.Call, typeof(object).GetConstructors([0\]);  

이제 IPerson의 프로퍼티(Property)를 구현한다.

IPerson의 프로퍼티 목록은 리플랙션(Reflection)을 이용하여 쉽게 얻어낼 수 있다. 간단히 typeof(IPerson).GetProperties(); 면 된다. (프레임워크 내부에선 더 복잡할 수 있음)

C#의 프로퍼티는 컴파일을 하게 되면 프로퍼티가 메서드로 치환된다. 예를 들어, public string Name { get; set; } 코드는 다음 처럼 컴파일러가 치환한다.

public string get_Name() { ... }  
public void set_Name(string name) { ... }  

그러므로, 다이나믹 프록시를 구현할 때도 프로퍼티를 선언해 준 후에 get, set 메서드를 구현해 주어야 한다. 이를 Umc.Core에서 다음고 같이 구현하였다.

public ICodeLambda Get()
{  
var type       = new TypeBuilderExtension(null, this.TypeLambda.TypeBuilder);  
var methodAttr = this.TypeLambda.MethodAccessor.MethodAttribute | MethodAttributes.NewSlot | MethodAttributes.Final | MethodAttributes.Virtual | MethodAttributes.SpecialName | MethodAttributes.HideBySig;  
var method     = type.CreateMethod(methodAttr, propertyBuilder.PropertyType, String.Concat("get_", propertyBuilder.Name), Type.EmptyTypes, null, false);  

propertyBuilder.SetGetMethod(method);  

return new CodeLambda(this.TypeLambda, method.GetILGenerator());
}  

public ICodeLambda Set()
{  
var type = new TypeBuilderExtension(null, this.TypeLambda.TypeBuilder);  

var methodAttr = this.TypeLambda.MethodAccessor.MethodAttribute | MethodAttributes.NewSlot | MethodAttributes.Final | MethodAttributes.Virtual | MethodAttributes.SpecialName | MethodAttributes.HideBySig;  
var method     = type.CreateMethod(methodAttr, typeof(void), String.Concat("set_", propertyBuilder.Name), new Type[] { propertyBuilder.PropertyType }, null, false);  
method.DefineParameter(1, ParameterAttributes.HasDefault, "value");  

propertyBuilder.SetSetMethod(method);  

return new CodeLambda(this.TypeLambda, method.GetILGenerator());

}  

그리고 get, set 메서드의 내부 코드는 다음과 같이 구현된다.

public ITypeLambda GetSet()
{  
this.TypeLambda.FieldAccessor.FieldAttribute = FieldAttributes.Private;  
var field = this.TypeLambda.Field(this.propertyBuilder.PropertyType, String.Concat("__", propertyBuilder.Name));  

var get = this.Get();
{
    get.Return(field);
}  

var set = this.Set();
{
    set.IL.Emit(OpCodes.Ldarg_0);
    set.IL.Emit(OpCodes.Ldarg_1);
    set.IL.Emit(OpCodes.Stfld, ( (IValuable<FieldBuilder>)field ).Value);

    set.Return();
}  

return this.TypeLambda;
}  

위의 코드가 그 흔한 프로퍼티의 구현부인 public string Name { get { return this._name; } set { this._name = value; } } 를 구현하는 코드가 되겠다. 별거 아닌 코드지만 내부적으로 프로퍼티와 메서드를 생성하고, 그 구현 코드를 IL 코드로 재구현 하면 역시 조금 난이도가 높아진다.

메모리에서 개체 포인터의 엑세스를 방지하기 완료 방법

지금까지는 메모리에 동적인 코드들을 IL 코드들로 구현하였다. 모든 구현이 완료되었으면 더 이상 메모리에서 IL 코드가 위변조 되거나 .NET 코드 정책에 위배되지 않도록 엑세스 접근을 막아야 한다.

이 코드는 Umc.Core.Dynamic.Proxy.Lambda.TypeLambda 클래스의 CreateType() 메서드가 완료시킨다. 이 코드는 다음과 같이 구현 되었다.

public Type ReleaseType()
{  
if (this.TypeBuilder == null)
{
    throw new NullReferenceException(this.TypeBuilder.GetType().Name);
}  

return this.TypeBuilder.CreateType();
}   

코드 구현의 완료를 알렸다면 이제 동적 타입(Dynamic Type) 개체가 완성이 된다. 즉, 맨 처럼 IPerson 인터페이스를 구현하는 동적 개체(Dynamic Object)인 Person 개체의 타입이 되는 것이다. 즉, 이 Person 개체는 런타임에서 메모리상에 만들어진 것이 되겠다.

이리하여 Activator.CreateInstance(type) 으로 메모리상에 만들어진 Person 클래스를 생성할 수 있게 되는 것이다.

다이나믹 프록시(Dynamic Proxy) 개체의 모습

메모리상에서 만들어진 Person 개체의 타입은 내부적으로 규칙을 정해서 만들었다. Person 객체를 생성하여 이 객체의 타입을 보면 괴상한 이름으로 지어졌다.

var type   = DynamicProxyObject.InterfaceImplementationType<IPerson>();  
var person = (IPerson)Activator.CreateInstance(type);  

// 결과 -> dynamic_46c8ecaab09b41cbaa814511f69f1974

이 타입이 속한 주소(Namespace)와 모듈(Module)을 직접 디스크에 저장할 수도 있는데, 이런 방법을 이용하여 코드 난독화(Code Obfuscation) 처럼 사용할 수도 있다.

또 다이나믹 프록시(Dynamic Proxy)를 활용해 중간에 로깅(Logging)을 하거나 트랜잭션(Transaction) 처리를 할 수 있는 AOP 를 구현할 수도 있는 것이다. (AOP 구현 기법 중 하나이며, 다른 방법이 더 있다.)

또, 사용 편의성을 위해 고안된 것이 체이닝(Chaining) 방법을 이용하여 런타임 코드를 더 쉽게 만드는 방법을 Umc Core 프레임워크에서 제공한다. 다음의 코드를 보면 쉽게 이해가 될 것이다.

using System;  
using System.Linq;  
using System.Reflection;  
using Umc.Core.Dynamic.Proxy.Lambda;  

namespace ConsoleApplication1
{  
internal class Program
{
    private static void Main(string[] args)
    {
        string typeName = Guid.NewGuid().ToString("N");
        string methodName = Guid.NewGuid().ToString("N");

        var assembly = new AssemblyLambda().Assembly();
        {
            var module = assembly.Module();
            {
                var type = module.Public.Class(typeName);
                {
                    var constructor1 = type.Public.Constructor();
                    {
                        constructor1.Emit.EmitWriteLine("This is constructor");
                        constructor1.Return();
                    }

                    var constructor2 = type.Private.Static.Constructor();
                    {
                        constructor2.Emit.EmitWriteLine("This is (private static) constructor");
                        constructor2.Return();
                    }

                    var method = type.Public.Static.Method(methodName);
                    {
                        method.Emit.EmitWriteLine("This is emitted writeline");
                        method.Return();
                    }
                }

                var releaseType = type.ReleaseType();
                var obj = System.Activator.CreateInstance(releaseType);
                var releaseMethod = releaseType.GetMethod(methodName, BindingFlags.Public | BindingFlags.Static);

                Console.WriteLine("Release type is {0}", releaseType.AssemblyQualifiedName);
                Console.WriteLine("Release method is {0}", releaseMethod.Name);

                releaseType.GetMethod(methodName).Invoke(null, null);

                Console.WriteLine("".PadLeft(50, '-'));

                releaseType.GetMethods().ToList().ForEach(m => Console.WriteLine("Method Name is " + m.Name));
            }
        }
    }
}
}



// 결과 ->  
This is (private static) constructor  
This is constructor  
Release type is bdfd27e5e7ed446d8702fe172733d937, 4a8f6dd24e1f4054b551cca95ad0870b, Version=0.0.0.0, Culture=neutral,  PublicKeyToken=null  
Release method is 389b4a43a1ba4dc1b1391b5b06633645  
This is emitted writeline  
Method Name is 389b4a43a1ba4dc1b1391b5b06633645  
Method Name is ToString  
Method Name is Equals  
Method Name is GetHashCode  
Method Name is GetType  

위의 코드와 같이 좀 더 직관적으로 동적 코드를 만드는 방법을 Umc Core에서는 제공해 주고 있다.

재미있는 것은 메서드의 이름이다. 결과 출력 중 Method Name is 389b4a43a1ba4dc1b1391b5b06633645 이 있는데, 놀랍게도 메서드의 이름이 숫자로 시작한다. C# 언어 사양 중 변수의 타입, 변수 등의 이름은 반드시 알파벳 문자로 시작해야 함에도 불구하고, 숫자로 시작하다니…

이는 C#의 언어 사양과 CIL(Common Intermediate Language) 언어의 사양이 다르기 때문이다. 심지어 숫자가 아닌 특수문자로 시작해도 된다. 앞서 말했다시피 이런 방법을 이용하여 코드 난독화(Code Obfuscation) 가 가능하다.

비록 대부분의 Umc Core 소스 코드를 공개하지 않았지만, 미공개 코드 중 코드 난독화 툴도 함께 포함이 되어있고, Junk Assembly를 만드는 툴, AOP based Compile 툴 등도 포함이 되어있다. ㅎㅎㅎ; 아쉽지만 여전히 미공개 분은 공개하지 않을 예정이다. 더불어, 관심있는 독자라면 CIL 언어 스팩의 사양을 살펴보는 것도 좋을 것이다.

결론

지금까지 살펴본 다이나믹 프록시(Dynamic Proxy)를 살펴보았다. 이 기법은 IoC, DI, AOP, ORM 등 최신 객체 제어 기술들의 가장 근간이 되는 기법이다. 여러분들이 최신 기술들로 IoC, DI, AOP 등을 구현하고 싶다면 당장 오픈소스를 이용하면 될 것이다.

아마 필자처럼 .NET 기반으로 다이나믹 프록시(Dynamic Proxy)를 직접 구현해서 쓰는 것은 매우 드문 일이다. 이미 검증된 오픈 소스들도 많기 때문에 굳이 이를 구현해서 쓸 필요는 없다.

하지만 이런 오픈 소스를 이용하여 쓰는 것은 그리 어렵지 않겠지만, 이런 오픈 소스를 이용하여 어떻게 코드를 만드느냐는 성능이나 내부적으로 동작하는 효율성에 영향을 미칠 수 있다. 즉, 자신이 오픈 소스를 이용하여 만든 코드가 효율적인 코드, 그리고 메모리상에서 Clean Code로 동작하느냐는 별개의 문제이다.

필자와 같이 다이나믹 프록시(Dynamic Proxy)를 구현해 보았다면 여러분들이 얼마나 위험한 코드를 많이 만드는지 알 수 있다. 즉, 오픈 소스를 써보기만 했다면 절대로 알 수 없는 고급 기술이다.

ASP.NET MVC 등과 같은 프레임워크에 IoC 등이 통합되면서 내부적으로 이와 유사한 방법을 쓴다. 특히 웹 개발에 있어 IoC와 같은 프레임워크는 굉장히 위험할 수 있다. 설명하자면 지금까지 쓴 내용보다 더 복잡하고 많은 내용으로 설명이 필요할지도 모른다.

만약 관리 언어(Managed Language) 등으로 만들어진(자바도 구현 기법이 유사함) 응용 프로그램의 고성능 튜닝, 트러블 슈팅, .NET 플랫폼에 관심이 많은 독자라면 반드시 이해하고 넘어가야 할 내용들이다. 그리고 오픈 소스를 이용하여 다이나믹 프록시(Dynamic Proxy)를 간접적으로 사용만 한다면 가볍게 읽고 넘어가도 좋다. 소소한 개발 일상의 이야깃 거리도 될 것이다.

필자는 이 외에도 다이나믹 프록시(Dynamic Proxy)를 바탕으로 이를 IoC와 통합하고 AOP, ORM 등을 구현하는 방법도 알아볼 것이다. Umc Core는 오픈 소스로 공개되어 있으며 위키 페이지를 만들겸 하나씩 정리하고자 한다. 

혹시 위의 CMD 에서 키보드를 잘못 누른경우 아래의 인터넷 옵션의 인증서 창에서 신뢰되지 않은 게시자를 지우기 바랍니다.

캐시 서버 시작

콘솔 프로젝트에 참조 추가

CTP2 에서 System.Data.Caching 이 Microsoft.Data.Caching 으로 네임스페이스가 변경되었습니다.

NamedCache 를 만듭니다.

New-Cache -CacheName NamedCache1 -Secondaries 1 -TTL 15

App.Config 의 설정입니다.

App.config

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<!--configSections must be the FIRST element -->

<configSections>

<!-- required to read the <dataCacheClient> element -->

<section name="dataCacheClient"

type="Microsoft.Data.Caching.DataCacheClientSection,

CacheBaseLibrary"

allowLocation="true"

allowDefinition="Everywhere"/>

<!-- required to read the <fabric> element, when present -->

<section name="fabric"

type="System.Data.Fabric.Common.ConfigFile,

FabricCommon"

allowLocation="true"

allowDefinition="Everywhere"/>

</configSections>

<!-- simple client -->

<dataCacheClient deployment="simple">

<!-- (optional) specify local cache

<localCache

isEnabled="true"

sync="TTLBased"

objectCount="100000"

ttlValue="300" />

-->

<!-- note: cache notifications are

not supported with simple client -->

<!-- cache host(s) -->

<hosts>

<host

name="DPOWERUMC"

cachePort="22233"

cacheHostName="DistributedCacheService"/>

</hosts>

</dataCacheClient>

</configuration>

아래는 간단한 샘플 소스 코드입니다.

Program.cs

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using Microsoft.Data.Caching;

namespace ConsoleApplication1

{

class Program

{

static void Main(string[] args)

{

//declare array for cache host(s)

DataCacheServerEndpoint[] servers = new DataCacheServerEndpoint[1];

//specify cache host(s)

servers[0] = new DataCacheServerEndpoint("DPOWERUMC",

22233, "DistributedCacheService");

//specify cache client configuration

DataCacheFactory mycacheFactory

= new DataCacheFactory(servers, true, true);

//get cache client for cache "NamedCache1"

DataCache myDefaultCache = mycacheFactory.GetCache("NamedCache1");

}

}

}

아래는 캐시 서버를 중지하는 방법입니다.

그리고 ShareFolder 로 설치하면 Compact 3.5 Database 인 .SDF 파일이 생깁니다. 캐시 서버가 동작할 경우 파일 공유가 불가능하여 데이터베이스의 내용을 볼 수 없습니다. 필자의 견해로는 Compact DB 가 아닌 SQL Server Database 로 설치할 것을 권장합니다.

설치를 수정하려면 C:\Program Files\Microsoft Distributed Cache\V1.0\Uninstall-128913592820152769.exe 를 실행하시면 됩니다. 단, 프로그램 추가/제거에서 찾을 수 없답니다. ^^

C:\Program Files\Microsoft Distributed Cache\V1.0 폴더를 모두 새로운 클러스터 서비스의 폴더로 이동합니다.

필자는 C:\VELOCITY\DPOWERUMC_CLUSTOR01 요기에다가 이동했습니다.

단, 등호와 값 사이에는 공백이 한 칸 있어야 한다. -_-; (잘보세요… 그렇지 않으면 오류가 납니다 ^^;)

클러스터링 할 데이터베이스도 만들 수 있습니다.

그리고 DistributeCache.exe.config 에서 아래의 항목을 수정하시면 됩니다.
cacheHostName 속성
Log location 속성의 경로
DB Connection 정보

필자는 로컬 머신에 클러스터를 추가했습니다. 아래와 같이 서비스 항목에 추가된 호스트가 등록이 되었고, 서비스를 시작해 주시면 됩니다.

먼저 이전 포스트의 "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 코드 플랙스에 공개합니다.

때는 바야흐로 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 타입을 정하시면 됩니다.

.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 코드 플랙스에 공개합니다.

안녕하세요. VSTS 2010 공식 팀에서 Twitter 를 시작했습니다. Twitter 를 통해 차마 시간이 없어 정리하지 못한 정보나 알아두면 좋은 팁과 정보 등을 단문 메시지로 여러분들에게 전달해 드릴 예정입니다.

차세대 플랫폼인 Visual Studio / Team System 2010 등 관심 있는 분들의 많은 Following 을 부탁 드립니다.

http://twitter.com/vsts2010