UMC 와 함께하는 .NET 플랫폼 이야기

애자일에 대한 고찰

엄준일(땡초) — Fri, 12 Mar 2010 11:05:14 +0900

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

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) 을 도입한다고 해서 대시보드와 붙이는 메모지를 준비하고, 매일 매일 스크림 미팅을 할 필요는 없습니다. 스크럼 미팅이라는 형식에 갇히는 순간부터 자멸의 길이라는것을 뒤늦게 깨닳게 될 것입니다. 즉 스크럼 미팅은 매일할 필요도 없으며 어떤 다른 모습으로 바뀔 수 있고, 동료와 담배를 피거나 커피를 먹으면서 알게 모르게 나타날 수도 있습니다. 어떤 경우는 상대편 알게 모르게 하는것이 자연스러운 참여에 도움이 되는 경우도 있지요.

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

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

UMC 와 함께하는 ASP.NET 해킹하기 #1

엄준일(땡초) — Fri, 12 Mar 2010 11:04:51 +0900

YouTube 로 보기

Daum 의 TV 팟으로 보기

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[세미나] 닷넷엑스퍼트와 함께하는 차세대 응용 프로그램 구축 방법 및 사례 소개 세미나

엄준일(땡초) — Wed, 10 Mar 2010 11:15:23 +0900

최근에 많은 기술이 쏟아지고, .NET 의 생태계에도 새로운 국면을 맞이했습니다. 바로 Microsoft 에서 야심차게 준비하고 있는 .NET 4.0 플랫폼과 Team Foundation Server 기술은 상상과 생각을 현실로 이루어주는 강력한 밑거름이 되기 때문입니다.

지금이 아마 우리도 함께 변화할 수 있는 최고의 시점이며, 본 세미나는 그 길을 열어주는 가장 효과적인 세미나가 될 것입니다.

본 세미나는 프로젝트를 주도하는 관리자나 프로젝트 매니저를 위한 세미나입니다. 세미나 신청은 아래 "세미나 등록하기" 버튼을 클릭하십시오.

ALM 의 도입과 그 필요성

여러분의 조직은 효율적이라고 생각하나요? 바꾸어 보십시오. 국내 최고 아키텍처겸 컨설턴트인 닷넷엑스퍼트의 안재우 수석님의 많은 경험을 전수해드립니다. Team System MVP 엄준일 선임은 ALM 을 이용하여 효과적인 관리 방법, 팀과 조직이 한발 앞의 미래를 바라보는 노하우를 알려드립니다.

기업용 LOB 프로그램의 테스트 환경 구축
"왜 소프트웨어에 결함이 발생할까?" 라는 80년대의 구세대적이고 형식적인 질문은 버리십시오. 오늘날 소프트웨어 개발부터 운영까지 최신의 테스팅 기법과 기술을 직접 눈으로 확인하십시오. 테스트 자동화와 테스트 가상화는 분명 여러분들의 감탄과 탄성을 자아낼 것입니다.

WPF 기반 스마트클라이언트 적용 고객 사례
국내에 한번 있을까 말까한 최대 규모의 .NET 프로젝트를 닷넷엑스퍼트에서 수행하였습니다. 최신 프레젠테이션 기술인 WPF 를 이용하여 UX 컨설턴트 김선구 책임이 직접 참여한 프로젝트입니다. 최신 기술과 UX 와의 교감, 개발까지 아우르는 현장감있는 그들의 고민과 재미있는 경험을 들을 수 있을 것입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

MEFGeneric 코드 플랙스에 공개합니다.

엄준일(땡초) — Tue, 16 Feb 2010 17:16:15 +0900

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

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

[.NET/.NET Framework] - MEF 에 Generic Type 을 지원하기 위해서..?
[.NET/.NET Framework] - MEF 는 Generic Type 을 지원하지 않는다!

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 사이트를 통해 공개하였으니, 아래의 사이트를 참고하세요. ^^

MEFGeneric is a framework to support CLR Generic types in MEF (Managed Extensibility Framework).

http://mefgeneric.codeplex.com

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

좀 더 UX 에 다가가기

엄준일(땡초) — Tue, 16 Feb 2010 08:30:00 +0900

이전 포스트
[UMC/엄씨 생각] - 당신이 생각하는 UX 란?

이전 포스트에서 필자 나름대로 UX 에 대한 여러 가지 생각을 정리하고 나름대로 분류하기를 아래와 같이 정리하였습니다.

Web Service UX
Desktop UX
Mobile UX
RIA UX
Surface UX
Enterprise UX

물론 위와 같이 분류한 장르의 기준은 IT 기준이며, 좀 더 세세하게 분류하지는 않았습니다. 이미 위의 정도의 분류라도 필자 또한 어떻게 재분류를 해야할지 막막하기도 합니다.

하지만, 위와 같이 분류한 UX 의 장르에 대해 문제가 있습니다. 분명 UX 디자이너는 UX 향상을 위해 많은 고민을 했음에도 불구하고 말입니다. 분명 UX 는 기존의 경험보다 나은 경험을 선사하기 위함이지만 혹시 그것은 개발 팀이나 디자인 팀 내부적인 경험이 아닐런지요.

UX 의 향상 어떻게 평가하나?

이 질문은 UX 를 하는 사람이라면 누구나 고민해야 할 질문입니다. 이미 이전 포스트에서 언급한 내용이지만, 새로운 기술의 발전으로 RIA 와 같은 기술로 사용자에게 새로운 경험을 줄 수 있지만, 과연 그것을 어떤 기준으로 평가하느냐 입니다. 기존 HTML 을 RIA(Silverlight, Flash 등) 으로 바꾸었다고 과연 사용자 경험이 좋아졌다라는 것입니다.

필자의 간단한 경험을 예를 들어봅니다. 이전의 버튼 방식의 휴대폰과 터치 방식의 휴대폰이 있습니다. 분명 터치 방식의 휴대폰은 사용자에게 커다란 LCD 화면과 직관성을 제공해 줍니다. 그리고 지금의 대부분의 휴대폰은 이런 터치 방식의 휴대폰을 선호합니다. 하지만, 필자는 터치 방식의 휴대폰을 처음 구매하였을 때 분명 좋은 UX 를 얻었지만, 이로 인하여 선호하던 UX 를 잃어버렸습니다.

바로 터치 방식은 운전하는 사람에게는 치명적인 UX 임이 분명합니다. 예전의 버튼 방식의 휴대폰은 휴대폰 버튼을 보지 않고서도 문자를 충분히 보낼 수 있을 정도였지만, 터치 방식의 휴대폰은 운전 중 전방의 시선을 때지 않고서는 도저히 문자를 보낼 수 없었습니다. 사실 저는 이게 너무나도 불편했습니다. 터치 방식이라 사용성은 편해졌지만, 운전할 때 만큼은 도저히 휴대폰을 쳐다볼 수 없게 만든 UX 이기도 합니다. 또한 기존의 사용자를 전혀 배려하지 않았습니다. 적어도 저희 부모님은 터치 방식의 휴대폰을 전혀 조작할 수 없을 지경이니 말입니다.

최근에는 일본 식민지 시절의 문화를 타파하고자 지하철에서 "우측 보행" 을 시행하고 있습니다. 이 정책에 지하철마다 포스터 몇 장과 바닥 안내문이 전부라는 것이죠. 나름대로 잘 지키고 싶지만, 과연 모든 사람들이 그것을 직관적으로 받아들이느냐 입니다. 이미 방송에서 언급했었지만, 이러한 문화가 정착되기까지 충분한 시간이 없었다는 것도 문제일 것입니다.

마찬가지로, 필자가 이미 언급한 Web Service UX, Desktop UX, Mobile UX 등등 어떤 기준으로 UX 향상을 평가하냐 입니다. 특정 집단은 자신에게 다가온 UX 에 대해 낙관적일지 몰라도, 일부 집단은 오히려 방해만 될 뿐일 수 있다는 것입니다.

UX 에 대한 고찰

분명 UX 의 향상은 누군가에게 이로움을 주지만, 누군가에게는 정신적인 스트레스가 될 뿐입니다. 이미 관심있었던 누리꾼이라면 네이버가 2009년도 새해에 개편을 했던 기억을 말입니다.

참고 문헌
http://offree.net/entry/Open-Naver

많은 찬반 세력들이 "예전 네이버 메인을 돌려달라", "다신 네이버 안쓰겠다" 라는 심오한 의문을 남겼지만, 이제는 평화로워졌지만...

즉, UX 를 생각한다면 UX 를 위한 전략이 필요하다는 것입니다.

감각형 UX
측정 기준 : 오감(五感) 만족

아마도 가장 사용자가 느끼기 쉬운 UX 입니다. 사람의 인체의 5가지 감각을 이용한 UX 로써 보고, 느끼는 여러 가지 감각적인 활동들이 바로 이 분류에 속할 것입니다. 그리고 감각형 UX 는 디자인 측면에 매우 근접해 있습니다. 그리고 비교적 쉽게 얻을 수 있는 UX 입니다.

하지만 인간은 특히 이런 감각적인 반응에 빠르게 적응한다는 것입니다. 영화 '트랜스포머'가 보여준 변신 로봇의 향수와 영화 '아바타' 가 보여준 판도라 행성의 자극적인 자연의 3D 영상 기술은 시간이 지남에 따라 그 자극이 줄어들 수 밖에 없다는 것이죠.

바꾸어 얘기하면, 언제까지 인간의 이런 자극적인 감각에 의존할 것이냐는 것입니다. 매번 새로운 것을 원하고 자극적인 UX 를 원하는 것이 당연하다고 하지만, 이러한 UX 는 이미 국한된 사용자의 취향에 맞추는 것일 뿐이지, UX 자체의 향상을 가져오기 힘들다는 것입니다.

지능형 UX
측정 기준 : 사용자의 피드백, 지표 데이터

지능형 UX 는 아마도 가장 현실적인 지표 데이터가 될 것입니다. 지능형 UX 는 TV 시형률을 조사하는 것과 같이, 특정 집단이나 특정 표준 편자를 감안하여 절대 수치를 얻는다는 것입니다. 즉, 다수결의 원칙이 적용된 가장 UX 에 대해 시각적이고 신뢰할 수 있는 지표 데이터를 제공해 줍니다.

이러한 방식의 UX 는 아마도 설문 조사, 사용자 피드백, 사용자 행동 반경 데이터를 조합하여 얻을 수 있을 것입니다.

특히 지능형 UX 는 UX 향상에 대한 평가 기준이 될 것입니다. 지능형 UX 는 누군가에게 UX 향상에 대해 근거할 수 있는 자료를 지시할 수 있다는 것이기 때문입니다.

"기존보다 어떻게 나아졌는데?"

이미 이 질문에서 답은 나왔다고 생각합니다. 누군가 정책의 '결정권자'가 묻는다면 어떻게 하시겠습니까? 바로 지능형 UX 의 정확한 수치적인 데이터를 우선시 할 것입니다.

아마도 대부분의 사용자들은 기존의 UX 를 비판하는 사람은 굉장히 드물기도 합니다. 왜냐하면 자신에게 가장 익숙한 UX 이기 때문입니다. 특히 주의할 것은 자신의 욕심이 오히려 UX 를 망가뜨릴 수 있다는 것입니다. 자신을 위한 UX 인지, 자신이 만든 구렁텅이로 냇물 흐르듯이 사용자가 따라오길 바라는 UX 인지, 진정 사용자를 위한 UX 인지 말입니다.

적어도 필자가 생각하는 UX 는 "사용자는 큰 고민 없이 의도하는 대로 따라가기 쉬운 UX" 가 좋은 UX 가 아닌가 생각합니다. 그것이 지능형 UX 든 감각형 UX 든 상관 없이 말입니다.

하지만 반대로, 이러한 UX 의 향상을 어떻게 표현할 것인지는 누군가에게 "UX 도입의 효과"에 대해서 심각하게 고민할 수 있는 근거 자료가 될 것입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

.NETXPERT 의 트위터 오픈

엄준일(땡초) — Tue, 09 Feb 2010 18:18:18 +0900

우리 회사는 트위터를 오픈하여 회사의 소식과 .NET 뉴스를 전하고 있습니다.

http://twitter.com/dxnews

저희 이건복 대표 이사님께서 관리하시는 이 트위터를 통해 좋은 정보 많이 얻어가시고, 여러분들과의 좋은 소통의 장이 되길 기대해 봅니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Visual Studio 2010 RC 공개

엄준일(땡초) — Tue, 09 Feb 2010 11:45:27 +0900

금일 2010년 2월 9일이 MSDN Subscription 을 통해 공개가 되었습니다. (미국 시간 2월 8일)

Visual Studio 2010 RC(Release Candidate) 공개
http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx

이전 Visual Studio 2010 Beta 2 에서 발생하는 가상 메모리와 성능 관련된 문제에 대해서 이번 RC(Release Candidate) 버전에서는 상당히 개선이 되었다는 인터넷 블로거들의 반응이 보입니다.

이미 Visual Studio 2010 RC 버전을 설치한 외국의 블로거의 말에 의하면, Microsoft 는 이런 문제를 해결하는 것에 대해 용기있고 현명함에 칭찬을 아끼지 않고 있네요. 필자 또한 이번 RC 버전에 대해 Microsoft 대한 찬사를 아끼지 않습니다.

일반적으로 RC(Release Candidate) 버전은 더 이상의 기능이나 사용자의 피드백의 반영이 없고, RC 에 안정성을 확보하여 RTM(Release to Manufacture) 버전으로 정식 제품이 공개가 됩니다. 이전의 Beta 버전을 설치하기 꺼려하셨던 분들도 크리티컬한 이슈가 해결된 RC 버전을 설치하셔서 미리 공부하시면 될 것 같습니다.

앞으로 다가오는 4월달 정식 제품이 더욱 기대가 되는 하루입니다. ^^

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

당신이 생각하는 UX 란?

엄준일(땡초) — Mon, 08 Feb 2010 08:30:00 +0900

※ 아래의 글은 필자의 경험과 필자 나름대로 분류하고 정리한 자료이므로 잘못된 부분은 조언 부탁드립니다. 그리고 필자의 개인적인 견해와 자료는 상업/비상업적인 용도로 인용할 수 없습니다.

얼마 전 UX 에 대해 이야기를 나눌 수 있는 기회가 생겼습니다. 그의 이야기를 정리하면 저 또한 아래와 같은 의문이 생기네요.

'같은 UX 일을 하는 사람끼리도 괴리감이 생긴다'

그럼 이런 의문에서 출발해서 UX 에 대해 다시 한번 고민해 보고, 문제를 분석해 보도록 합시다.

UX 란 무엇인가?

많은 사람들은 UX 에 대해 많은 오해가 있는 것 같습니다. UX(User eXperience) 는 직역대로 "사용자 경험"을 향상하기 위함입니다. UX 는 바로 디자인(Design) 요소만의 추구가 아닌, 접근성, 편의성, 사용성 등의 구성 요소가 포함이 됩니다.

하지만, UX 를 접근하려고 시도하는 많은 UX 전문가는 이미 공통된 UX 라는 의미에서 이미 시작점을 잘 찍지 못하기도 합니다. UX 라는 단어는 이렇게 굉장히 많은 요소와 포괄적인 의미를 포함하고 있습니다. 즉, UX 와 관련된 전문적인 일을 하고 있지만, UX 전문가 사이에서도 굉장히 괴리감이 있다는 것입니다.

UX 의 잘못된 출발. RIA=UX ?

과연 RIA=UX 인가? 일부 실버라이트(Silverlight) 나 플래시(Flash) 와 관련된 일을 하고 계신다면, 충분히 오해의 소지가 발생할 수 있는 등호식입니다. 이와 유사하게 오해의 소지가 있는 것이 RIA=Silverlight 라는 것이죠. RIA 를 하기 위해서는 실버라이트 또는 플래시 등의 기술이 필요하다는 잘못된 관념을 가지고 있습니다.

다시 질문하자면 RIA(Rich Internet Application) 은 무엇인가.? RIA 를 묻는 다면 필자는 트랜드한 용어라고 하고 싶습니다. 이미 예전에 X-Internet 이라는 용어로 인터넷의 접근성, 사용성, 그리고 다양한 디바이스(Device) 를 확장시키기 위한 기술이며, Fat Application 또는 Thin Application 이라고 부르기도 하였습니다. 그리고 .NET 플랫폼의 기술로써 스마트클라이언트(Smartclient) 가 이러한 X-Internet 기술에 포함이 됩니다. 타 플랫폼에서는 X-Internet 기술로 투비소프트(Tobesoft) 의 마이플랫폼(MiFlatform) 과 어도비의 플랙스(Flex) 등이 있지요.

X-Internet 과 RIA 는 무엇이 다를까란 생각을 해보면, 그다지 다른게 없다는 것입니다. 이러한 용어는 시대적인 배경이 따른 것 뿐이지, 추구하고자 하는 목표와 이상은 큰 차이를 보이지 않습니다. 즉, X-Internet 은 기능적인 요소를 초점으로 마케팅했다는 것이고, RIA 는 UX 를 초점으로 마케팅했다는 것 뿐입니다. 새로운 기술을 대중에게 얘기할 때, 무엇을 1번으로 말하느냐는 그 시대와 그 시대의 시장에서 요구하는 것이 달랐다는 것을 알 수 있습니다.

하지만, X-Internet 의 시작은 좋았으나 유행을 일으키지는 못했습니다. 그 대안으로 실버라이트와 어도비(Adobe) 의 기술들은 RIA 와 UX 를 이용하여 마케팅을 함으로써 많은 사용자와 전문가 층에서 각광받고 있습니다. 하지만, X-Internet, RIA, UX 등 이미 범람하는 용어들 속에서 제대로 개념을 찾기란 참 힘들기도 합니다.

UX 는 개발과 디자인의 공통 영역?

특히 일부 UX 를 전문적으로 하시는 분의 말을 빌리면, UX 는 개발 영역과 디자인 영역의 공통 분모라고 말을 합니다. 하지만 정말 그럴까요? UX 를 하려면 개발과 다자인을 둘 다 알아야 하는 걸까요? 그리고 UX 를 하려면 개발과 디자인의 올바른 협업이 필요한 걸까요? 다시 한번 UX 에 대해 고민해 볼 필요가 있습니다.

하지만, 필자는 왼쪽 그림과 같은 말을 하는 것부터가 이미 잘못된 UX 개념에 사로잡힌 사람들이라고 말하고 싶습니다. (그렇다고 오른쪽이 정답이라는 말은 아닙니다) 다시 얘기하면, 개발과 디자인 영역간의 협업은 UX 를 수행하는 과정일 뿐이지, UX 자체가 개발과 디자인의 공통 분모가 될 수 없다는 것입니다. 거꾸로, 웹 디자이너가 웹 개발 프로젝트에 투입되었다면 어쩔 수 없이 개발자와 조율하고 협업하는 과정이 불가피 할 테니까요.

결국, UX 는 너무도 많은 의미를 포괄하고 있고, 자신이 생각하는 UX 에 대해 시작점을 잘못 찍음으로써 UX 의 본질에 대해 다시 원점으로 돌아간다는 겁니다. RIA=UX, UX=RIA 라는 잘못된 개념은 결국 자신의 제한적인 생각의 범위와 제한적인 경험에서 나온 오해일 여지가 큽니다.

UX 가 개발과 디자인의 공통 영역이란 것은 좋은 UX 를 위한 과정일 뿐이지(필요할 수도, 필요 없을 수도), 절대 목표나 의미가 아니라는 의미입니다. 아마도 개발과 다지안의 공통 영역이란 것은 자신의 UX 는 그만큼의 범위 밖에 안된다는 의미겠지요?

일부 UX 세미나를 듣고 있자면, 마치 UX 전문가는 개발 영역과 디자인을 조율해야 하는 선도적이고, 개발 영역 기술까지 알아야 한다는, 다소 권위적인 얘기로까지 들리기도 합니다. 아마도 그런 UX 전문가는 XAML 과 Expression Blend 도구를 이용해서 디자인 해봤다는 말로만 들립니다. XAML(Extensible Application Markup Language) 이 프로그래밍적인 요소의 OOP 와 표현 요소인 Presentation 을 포함하는 기술이니, UX = XAML 로 혼돈하는 것이 아닐까란 생각도 듭니다.

UX 도 분석이 필요하다.

일단, 현재 통용되고 있는 UX 라는 의미가 너무 광범위합니다. 좀 더 UX 에 가까이 가기 위해 좀 더 분석이 필요할 것 같네요. 그렇다면 UX 를 좀 더 잘게 쪼개기 위해 우리가 실제로 겪을 수 있는 UX 로 나누어 봅시다.

Web Service UX
쟁점 : 데이터의 효율적 배치, 검색, 직관성
아마도 인터넷을 통해 가장 먼저 접할 수 있는 UX 일 것입니다. 공통된 관심을 집중할 수 있는 방법이나 데이터의 효율적인 배치와 검색 등이 관건일 것입니다. 더불어 서비스에 대해 사용자의 재방문을 유도하기 위해 사용자의 지속적인 좋은 콘텐트와 접근성이 가장 중요할 것입니다.

Desktop UX
쟁점 : 안정성, 시스템 리소스의 가시성
컴퓨터의 전원을 켜기 시작하면서 경험할 수 있는 UX 입니다. 기본적으로 운영체제(OS) 가 포함이 될 것이고, 운영체제 안에서 돌아가는 브라우저나 보조 응용 프로그램 등, 모든 응용 프로그램이 이 범주에 포함이 될 것입니다.

Mobile UX
쟁점 : 단순함, 직관성, 데이터의 중요도 분리 및 표현
최근 아이폰(iPhone) 의 국내 발매로 불붙기 시작한 UX 입니다. 특히 단순하면서도 복잡하지 않는 UX 가 필요로 할 것입니다. 아마도 필자가 Windows Mobile 6.1 을 쓸 때의 느낌은, "이거 데스크탑 OS 와 비슷한데?" 라는 복잡함을 느꼈다면 적어도 필자에게는 좋은 Mobile UX 가 아니었다는 것입니다.

RIA UX
쟁점 : 가볍고 빠른 응답성, 상호작용 향상, 표현력
최근 각광 받고 있는 UX 입니다. HTML 로 표현하기 힘은 콘텐트나 데이터, 그리고 화려함을 더해줄 수 있는, 진정한 Rich 함이 필요로 하는 UX 입니다. 잘 알고 있는 Microsoft 의 실버라이트(Silverlight) 와 Adboe 의 플래시(Flash) 가 대표적인 RIA 기술입니다.

Surface UX
쟁점 : 제한된 입력장치로 사용자 접근성, 효율성
아직은 크게 주목 받고 있지는 않지만, 장차 큰 범주의 UX 가 될 것입니다. 제한적인 입력장치로 인해 특히 사용자의 사용성을 크게 고려해야 할 것입니다. 아마도 필자는 일부 Surface UX 를 경험하면서 '이게 누르는 버튼인건가?', '어떻게 쓰는 거지?' 라는 괴리감을 줄이는 것도 좋은 UX 가 될 수 있는 길일 것입니다.

Enterprise UX
쟁점 : 데이터의 배치, 복잡성을 단순화할 방안, 데이터 표현의 표준적인 방안
아마도 좋은 UX 를 만들기 가장 힘든 환경이 아닐까 합니다. 특히 데이터 중심의 복잡한 환경에서 데이터를 어떻게 배치할 것인지, 특히 복잡성을 어떻게 줄일 것인지의 고민이 필요합니다. 그리고 데이터와 표현의 올바른 정의가 절실하기도 합니다.

올바른 UX 향상을 위하여

위의 여러 가지 UX 의 장르로 구분하였지만, 각각의 UX 는 독립적인 UX 는 아닙니다. 예를 들어, Web Service UX 를 향상하기 위해 RIA UX 가 필요할 수 도 있다는 것입니다. Enterprise UX 에서 복잡한 데이터를 단순화 하기 위해 RIA UX 가 필요한, 즉, 각 UX 는 각 장단점을 보완할 수 있는 UX 라는 겁니다.

아래는 각각의 UX 의 단점을 보완할 수 있는 예 입니다.

	Web Service UX	RIA UX	Enterprise UX
단점을 보안하기 위해	RIA UX Mobile UX	Mobile UX Web Service UX	RIA UX Web Service UX

그리고 자신의 UX 장르가 무엇을 필요로 하냐는 것입니다. 즉, 각 UX 장르별로 무엇이 UX 를 떨어뜨리는 요인이 되냐는 것입니다. 그 문제의 요인을 제거하는 것이 근본적인 문제이며, 다른 장르의 UX 의 사례를 적용하여 UX 를 향상한다면 더할나위 없을 것입니다.

결론적으로, 현재 자신의 UX 위치를 잘 알고 그 UX 를 향상시키기 위해 무엇이 필요하냐는 것이 UX 향상의 쟁점이 될 것입니다. 필자 나름대로, Web Service UX, RIA UX, Enterprise UX 등으로 분류하였지만 자기 나름대로의 큰 범위의 UX 를 정립하기 위해서는 그것을 이루는 구성 요소를 정리, 정의해야만 올바른 UX 향상의 지름길이 될 것입니다.

개발자 출신인 필자도 개발에 필요한 구성 요소의 기반 기술의 이해가 부족할 때는, 스스로의 시야를 자신의 경험에 가려버렸던 적이 많습니다.

많은 UX 전문가에게도 말하고 싶은 것은, 당신이 실버라이트와 플래시를 해서 UX 디자이너, UX 전문가 인가요? 그렇다면 다시 묻겠습니다.

UX 란 무엇인가요?
좋은 UX 란 무엇인가요?
좋은 UX 를 위해 무엇이 뒷받침이 되어야 할까요?
그렇다면 좋은 UX 를 위해 무엇을 실천했나요?

위의 물음에 자신만의 올바른 정의가 없다면, UX 가 아닌 당신은 단지 디자이너(Degisner) 일 뿐입니다. 저는 개발자를 분류하길 핵심 개발자(Core Dev), 일반 개발자(Dev) 로 분류합니다. 개발자인 필자의 눈에는 마찬가지로, UX 디자이너와 일반 디자이너 두 가지 밖에 없습니다.

하지만 다행인 것은, 마치 .NET 기술이 처음 나왔을 때 처럼, UX 또한 아직 많은 정보를 접하기 힘든 황량한 사막과도 같다는 것입니다. 끊임 없는 고민과 노력은 분명 UX 성숙기 시대에 접어들 때, 빛을 발하리라 의심치 않습니다.

다음 글
[UMC/엄씨 생각] - 좀 더 UX 에 다가가기

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[ALM-Test] 왜 단위 테스트를 해야 하는가? [2]

엄준일(땡초) — Fri, 05 Feb 2010 08:30:00 +0900

이전 글
[Software Development/Agile] - [ALM-Test] 왜 단위 테스트를 해야 하는가? [1]

이미 이전 포스트에서 얘기 했듯이, 똑같은 "단위 테스트"라는 단어를 가지고 개발자, 테스터, 고객은 각자 그 의미를 전혀 다르게 생각하고 있습니다. 이런 단어의 해석 조차 각자 틀린데, 애자일(Agility)하게 어떻게 소프트웨어를 만들 수 있을까요. 이미 "단위 테스트" 라는 작은 주제를 가지고 벌써부터 고객과 개발 조직간의 불화음이 발생합니다.

아니, 이미 개발 팀 내부에서부터 어디서 부터 시작해야 할지 어디둥절 할 수 있습니다. 그렇다면 과연 "단위 테스트" 가 결함의 발생을 줄이는 약이 될지, 팀 간의 커뮤니케이션 장애를 발생시키는 독이 될지, 그것은 아마 이 글을 읽는 독자 분들의 실천에서부터 시작될 것입니다.

이렇게 말도 많고 탈도 많은 단위 테스트를 왜 꼭 해야 하는지부터 짚고 넘어가 봅니다. 단위 테스트는 기능 또는 단위 별로 결함을 조기에 발견하기 위한 테스트 방법입니다. 하지만 "단위 테스트" 라는 단어만으로는 그 이해는 너무나도 상이하게 틀리다는 것입니다.

개발자 - 단위 테스트 코드를 만드는 것
테스터 - 개발중인 웹 어플리케이션 또는 클라이언트 어플리케이션 등을 만져보면서 기능 결함을 발견 하는 것
고객 - 문서!! 기능에 대한 산출물 또는 보고서

일단 "단위 테스트" 에 대한 이해가 달라도 현재까지는 상관이 없습니다. 왜냐하면 단위 테스트가 가지는 의미를 제대로 이해하고, 공감대를 형성하는 것이지 어떻게 수행할 지는 적어도 지금은 중요하지 않습니다.

단위 테스트에 대해, 국내에는 번역본이 대부분이라 사실 우리 나라 실정에 정말 맞는지에 대해 많은 고민을 하였고, 적어도 필자는 이런 고민을 방관하고 싶지는 않습니다. "NO" 를 외치고 싶을 때는 외쳐야 하지 않겠습니까?

왜 버그가 발생하는가?

일반적으로 버그나 소프트웨어의 결함은 어떻게든 발생할 수 밖에 없습니다. 아무리 기계적이고 단순한 코드를 개발한다고 하더라도, 코드 간의 상호 연동, 클래스 간의 연동, 컴포넌트(Components) 간의 연동, 레이어(Layer) 간의 연동, 더 나아가 시스템 간의 연동.. 즉, 연동 또는 상호 종속적인 관계가 발생하는 시점부터 버그는 이미 예견될 수 밖에 없습니다. 쉽게 얘기하면, A 란 코드와 B 란 코드가 있습니다. 이 두 개의 코드는 분명히 다른 목적에 의해 개발이 되었지만, 목적 자체가 틀린 코드가 상호 연동 또는 종속적인 관계가 발생하게 된다면, 과연 어떨까요? 이것은 코드 자체에서 발생되는 결함이라기 보다 상호 연관 관계에 놓이면서 발생하는 결함이라고 볼 수 있습니다. 그리고 대부분의 중요한 또는 큰 버그는 이러한 얽히고 설키게 되는 연동/종속 이란 문제로 발생됩니다.

만약 버그가 발생되지 않는 상황이라도 A와 B 코드는 언제든지 업그레이드가 될 수 있습니다. 기능이 변경될 수 도 있고, 기능이 추가될 수 도 있습니다. 아무것도 모르는 최종 사용자(End user) 는 잘 되던 기능이 갑자기 안된다면 좀 어이없어 할 것입니다. 일부 이러한 코드가 최종 사용자의 요구에 의해, 그리고 최종 사용자를 위해 변경되지만, 최종 사용자는 결함을 발생시킨 원인을 알고 싶지도 않고, 단지 개발 팀을 신뢰할 수 없을 뿐입니다.

즉, 이러한 버그가 조기에 발견되지 않는다면 버그는 지속적으로 증식을 하게 됩니다. 가장 대표적인 예라면, 월별, 년별 정산해 주는 기능이겠죠. 이곳에서 만약 버그가 발생한다면 몇 일, 아니 몇 주를 이 버그를 해결하기 위해 많은 시간을 소비해야 할 것입니다. 실제로도 필자는 주변에서 이와 유사한 버그로 인해 고생하는 동료 개발자들을 많이 보아왔습니다. 결과적으로 모든 코드에는 버그가 발생할 가능성이 있고, 그것은 바로 연동/종속적인 관계가 시작되면서 집중적으로 발생하게 됩니다. 그리고 잠재적인 모든 코드가 버그의 대상이 되고, 잠재적인 버그가 가장 위험하다는 것입니다. 잠재적인 버그는 지금의 나도, 너도, 우리 모두가 모르는, 언제 발생할 지 모르는 버그이기 때문입니다.

이러한 주제로 필자는 이미 Techday 2009 에서 온라인 세미나를 한 적이 있습니다. 아래의 링크를 통해 간략한 단위 테스트 기술에 대해 미리 익히는 것도 좋습니다.

http://www.techdays.co.kr/Sessions/View.aspx?Id=40&mSeq=43

단위 테스트가 주는 의미

단위 테스트는 많은 곳에서 장점을 이야기 합니다. 예를 들어, "결함을 줄이고, 잠재적인 버그를 줄이고, 코드를 리팩토링 하게 하며…." 등등… 단위 테스트가 실제로 이러한 많은 장점이 있는 것은 필자 또한 강력하게 권장하고 싶습니다. 하지만, 아시다시피 "단위 테스트" 에 대해 개발자, 테스터, 고객과의 공감대가 형성되지 않은 이 마당에, 저런 소리를 하면 정말 비즈니스적인 가치가 있을까요? 아마도 고객은 단위 테스트를 한답시고 비용과 시간이 늘어난다는 것을 절대 용납하지 않을 것입니다.

그렇다면 단위 테스트가 우리에게 주는 의미는 무엇일까요? 단위 테스트를 형용할 수 있는 모든 단어를 떠올려 보십시오. 참 많습니다. 하지만 고객과 개발 조직, 그리고 비즈니스 측면에서 어떤 단어가 가장 잘 어울릴까요.

바로 단위 테스트는 "신뢰" 입니다. 개발 조직에서 개발자와 개발자간의 코드에 대한 신뢰! 개발 조직과 테스트 팀간의 신뢰! 그리고 단위 테스트의 결과는 매우 명확해서 고객과의 신뢰로 이어질 수 있습니다. 이러한 단위 테스트로 인해 장기적인 비용이나 리소스 절감 효과 등은 잠재적인 비즈니스적인 신뢰로 이어질 수도 있습니다. 만약, 개발 팀 내의 단위 테스트는 다른 개발자가 만든 코드와 연동해야 할 때 대한 최소한의 신뢰를 가지는 매우 신사적인 행위입니다.

즉, 개발자, 테스터, 고객과의 단위 테스트에 대한 이해가 틀리다고 하더라도, 최소한 단위 테스트라는 것을 했고, 그 결과가 명확했을 때 그 관계에서 "신뢰" 가 형성될 수 있습니다. 젊은 개발자가 아닌 고객은 자신의 과거의 경험에 빗대로 단위 테스트라는 것이 어떤 것인지 잘 모르더라도, 매번 명확하게 결과를 보여준다면 비록 버그가 발생하였더라도, 버그의 발생 시점이 명확하고 이 버그의 해결 결과 또한 명확하다면 "버그" 라는 단어로 절대 날뛰는 일은 없을 테니까요.

애자일(Agile) 한 팀 모델! 무엇이 문제인가...

자! 이제 단위 테스트에 대해 어느 정도 확신을 갖게 되었다면, 이것을 수행하기 위한 팀 모델이 필요합니다. 하지만 이러한 팀 모델을 구축하기 위한 시도는 매우 말이 많고 신중해야 할 부분입니다. 애자일을 도입하여 실패했다는 많은 히스토리와 사례들이 범람하면서 과연 애자일이 좋은 것일까라는 고민을 해 보아야 할 시기인 것입니다.

애자일이라고 하면 일반적으로 통용되는 XP(eXtreme Programming) 의 팀 모델과 스크럼(Scrum) 의 팀 모델은 현저하게 차이가 납니다. 그리고 글로벌 소프트웨어 개발 업체 중 단연 1위인 Microsoft 의 정보 기술 솔루션인 MSF(Microsoft Solution Framework) 의 팀 모델은 모두 다 다르다는 것입니다.

일단 현재 우리나라의 팀 모델의 특색은 매우 다양하고 변칙적이며, 상하 수직적인 관계입니다. 예를 들어, 개발자를 동일 선상의 개발자가 아닌 "대리급", "과장급", 일부 "부장급" 도 코딩을 하기도 합니다. 그리고 단순히 "개발 조직"이라는 단어 조차 어색하게 사수, 부사수 달랑 두 명이 개발을 하기도 합니다. 편의상 아래와 같은 형태가 되는군요. (이 부분은 조직마다 매우 다른 형태를 띌 수 있습니다)

어떤 모델에서는 개발자, 아키텍처, 테스터로 구분하지만 필자는 이러한 팀 모델이 전혀 한국적이지 않다고 생각합니다. 애자일과 MSF(Microsoft Solution Framework) 에서도 언급하지만 개발 팀에서는 우두머리, 즉 대장을 두지 말라고 조언합니다. 위의 그림에서 PL(Project Leader) 는 바로 개발 팀의 우두머리이며, 가장 테크니컬 하거나 경력, 또는 업무 도메인 지식이 뛰어나야 합니다. 그리고 한국형 조직이나 문화 특성상, 윗사람 또는 상사에게 코드나 아키텍처적인 문제를 언급하는 것은 매우 조직력이 부족한 사람으로 비추어지기도 합니다.

예를 들어, 한국의 개발자는 코드에 굉장히 민감하고, 곧 코드가 자신의 자존심이라고 생각하는 경향이 짙습니다. 적어도 필자 또한 마찬가지 입니다. 개발자는 자신의 사수에게 코드적인 문제를 언급한다면 충분히 문제의 소지가 발생할 수 있습니다. 데이터베이스 개발자일 경우 자신의 사수에서 SQL 쿼리에 대한 성능적인 문제를 지적한다면 자신의 부사수가 잘난 체 한다거나, "경력도 얼마 안되는 놈이 좀 안다고 까부네" 라고 생각하기도 합니다. 상사와의 관계가 아닌, 동등한 개발자 간에서도 다른 사람이 자신의 코드에 대해 지적하는 것은 '거의 인간 관계를 포기한 것'과 다름이 없다고 봐도 무리는 아닐 것입니다. (물론 어떻게 얘기를 잘 하느냐는 문제도 있겠지만요)

결론적으로 애자일 또는 MSF 가 언급한 팀 모델은 굉장히 이상적이지만, 전혀 우리나라의 특성을 적용하기가 힘이 들 수 있습니다. 위에서 예를 든, 단편적인 예만 봐도 애자일 또는 MSF 의 자유분방한 팀 모델은 우리나라 현실에 도입되기는 매우 힘이 듭니다. 작은 조직이라면 모를까, 거대한 엔터프라이즈 프로젝트의 경우 많은 점점 더 큰 팀과 또는 다른 업체와 함께 일을 하는 경우가 발생하기 때문에, 팀 내부가 아닌 팀 외부로 까지 애자일한 행위는 절대 금물입니다.

한국적인 애자일(Agile) 한 팀 모델

많은 사람들이 오해하는 것 중에 하나가 애자일의 XP 와 스크럼을 도입하기 위해 그것이 요구 또는 원칙, 권장하는 방법들을 반드시 따라야만 한다고 생각합니다. 이미 지난 포스트에서도 언급했듯이 고객은 명확한 일정을 요구하는 폭포수 모델(Waterfall Model) 을 요구하는데, 팀 내외부적으로 애자일(Agile) 을 외치고 있다가는 고객이 원하는 어떠한 일정과 조건에도 맞출 수가 없습니다. 우리는 이 시점에서, 애자일이라는 단어가 주는 의미를 다시 한번 상기해 볼 필요가 있습니다. 어떠한 애자일, MSF 에서도 그것을 반드시 이행하라고 명시하지 않습니다. 다만, '이렇게 이렇게 해보니 좋으니 너희들도 이런 방법을 써봐라' 라는 권장의 의미이지 강요가 아니라는 것입니다.

어쨌든, 개발자라고 하면 아래와 같이 두 가지 형태의 개발자가 있을 것입니다. 유지보수 인력인 SM(System Management) 이 있겠고, 개발 인력이 있습니다. 두 형태는 같은 개발은 하는 것이 맞지만, 깊은 내막은 전혀 다른 개발을 하고 있습니다. 일반적으로 개발 인력은 개발이 마치면 유지 보수 팀 또는 인력에게 인수가 됩니다. 그리고 인도적인 차원에서 각종 산출물을 뽑아내어 유지 보수 인력에게 모든 추후 버그나 추가적인 기능 개발이 떠넘겨지게 됩니다. 즉, 유지 보수 인력은 1년 365일 전산 시스템이 잘 운영되고, 지속적인 국가 정책이나 기업 정책, 그리고 고객의 요구를 시스템에 반영하는 역할을 하게 됩니다. 이 과정에서 일부 개발 인력이 유지 보수 인력으로 자연스럽게 전환되기도 합니다.

하지만, 좀 더 큰 기업에서는 개발 팀만해도 매우 복잡한 형태를 띄게 됩니다. 일단 내부 개발자, 외부 개발자가 분리가 되며 기업의 내부적인 정보를 공유할 수 있는 권한이 있느냐 없느냐로 볼 수 있습니다. 뭐 이러한 경우 사적인 자리에 까지 이어져, 점심을 함께 먹는 동료가 정해지기도 합니다. ^^; 외부 개발자는 일반적으로 프리랜서나 개인 사업자를 등록한 사람들이 됩니다. 하지만 대부분 프리랜서나 개인 사업자는 기업의 하청 업체를 통해 계약이 되는 경우다 더 많죠.

필자 또한 이러한 팀 모델과 현실과의 많은 고민을 하면서, 과연 어떠한 것이 한국적인 팀 모델이 될 것인가에 대한 고민을 끝없이 하고 있습니다. 마찬가지로, 필자가 좀 더 성숙해 지면 아래에 언급하는 팀 모델에 대한 생각이 바뀔 수 도 있습니다. 어쨌든 필자의 경험상 아래와 같이 팀 모델을 권장합니다.

위의 선은 직접적으로 커뮤니케이션 할 수 있는 범위입니다. 자세한 롤 모델(Role Model) 까지는 언급하지 않겠지만, 대충 커뮤니케이션의 통로와 작은 하위 팀을 보면 이해가 갈 것입니다. 특히 핵심 개발자 팀은 그 관리자나 일반 개발자와만 커뮤니케이션이 이루어지며, 이 핵심 개발자 팀은 외부 또는 타 업체가 될 수 도 있습니다. 일반 개발자에서 파생되는 여러 종류의 개발자는 모두 일반 개발자로 들어갑니다. 그리고 고객은 오직 관리자와 직접적으로 커뮤니케이션이 이루어지며, 경우에 따라서 품질 유지 팀에 의해 보고를 받을 수 도 있습니다. 애자일의 자유분방한 커뮤니케이션의 트랜잭션(Transaction) 을 넓은 범위에서 최소한으로 우리나라의 실정에 맞도록 줄이는 것이고, 관리자가 권한을 일부 위임해 주는 형태가 되는 것입니다.

또 하나, 필자가 애자일(Agile) 에 대해 공부를 시작하면서, 가장 답답했던 것이 바로 "고객의 자발적인 참여"를 기대한다는 것입니다. 일반적으로 개발 팀 입장에서 느끼는 고객은 굉장히 권위적이며, 상하 수직적인 관계입니다. 과연 애자일하게 프로젝트를 하면서 점진적인 릴리즈(Release) 를 통해 1달에 한번의 반복(Iteration) 으로 총 1년 동안 12번의 반복을 통해 점진적으로 최종 릴리즈에 도달한다고 가정해 봅시다. 이 릴리즈마다 고객의 자발적인 참여와 의견을 교류하는 이상을 생각하며, 첫 번째 릴리즈를 보여줬을 때, 과연 고객은 소프트웨어 개선을 위해 적극적인 참여를 할까 아니면 "내가 원하는 소프트웨어는 이게 아닌데?" 라고 할까요.

과연 그렇다면 여러분은 애자일의 의미에 대해 고객에게 세미나를 할 것인가요, 아니면 어떻게든 설득을 할 것인가요? 이미 고객의 경향을 알고 있는데, 그러한 고객을 설득하고 이해시키는 계몽(啓蒙)을 할 수 있을지 의문입니다. 그렇다면 이미 답은 나왔습니다. 고객을 변화시키지 못할 바엔, 차라리 우리가 변하는 것입니다. 즉, 개발 조직 내에서 불필요한 소음을 줄이기 위해, 어디에서 문제가 발생하는지, 그리고 소통이 어떻게 이루어지는지에 대한 트랜잭션(Transaction) 에 대한 관찰이 필요하다는 것입니다.

그리고 위의 그림과 같이 필자는 최종적인 트랜잭션의 소통이 현재 한국적인 가장 이상적인 애자일이 아닐까 생각합니다.

각 역할 별로 간단히 정리하자면, 아래와 같은 마음 가짐과 자세가 필요하겠군요. 물론 모든 조건을 완벽하게 갖추기보다는 최소한의 자세와 지식이 갖는 것이 유리할 듯 합니다. 자신이 부족한 부분이 있다면, 팀 동료가 이것을 뒷받침 해 주어야 겠지요. (유지 보수 팀은 복잡성을 줄이기 위해 여기에서 제외합니다)

관리자	고객을 이해하고 개발 조직을 관리 소프트웨어 품질을 지속적으로 유지 및 팀 조율
핵심 개발 팀 (Core Developer)	기술적인 기반 지식 프레임워크 업무 도메인의 이해 개발자 보호(Care) 및 지원(Support)
품질 유지 팀 (Test Team)	업무 도메인의 이해 테스트 도구 사용 전반적인 테스트 시스템 인프라 와 운영체제(OS) 의 이해
일반 개발자	기본적인 개발 지식 할당된 개발 업무에 대한 책임감

품질 좋은 소프트웨어를 위한 단위 테스트

필자가 단위 테스트에 대한 필요성을 얘기하다가 뜬금없이 버그와 팀 모델에 대해서 이야기 하는 것이 의문일 수 있을 것입니다. 하지만 이 내용 또한 이전 포스트에서 이야기 했듯이, 소프트웨어 품질이 떨어지는 것에 대해 어느 누구에게 몰빵(?)할 수도 없는 문제이며, 단위 테스트에 대한 공감대가 없다면 절대 할 수 없는 것이기 때문입니다. 애자일이 우리에게 많은 자율성(Autonomy) 와 타이트함(Tightly) 를 주는 것은 매우 환영할 일이지만, 일부 정책적인 강제가 없다면 애자일은 우리나라에서 이미 실패한 방법론 또는 프로세스일 뿐입니다. 왜냐하면 우리나라의 고객은 아직까지는 변하지 않을 테니까요.

어쨌든, 단위 테스트를 위한 팀 모델의 세팅을 이쯤에서 마칩니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[ALM-Test] 왜 단위 테스트를 해야 하는가? [1]

엄준일(땡초) — Thu, 04 Feb 2010 08:30:00 +0900

애자일(Agile) 프로그래밍 기법 등이 대중화 되면서, 특히 XP(eXtreme Programming) 에서는 단위 테스트의 코드를 먼저 작성하라고 합니다. 그것이 바로 TDD(Test Driven Development) 입니다.! 그 이유는 다들 아시다시피 간단합니다. 바로 코드를 작성할 때 설계부터 하라는 것입니다. 좀 직설적으로 얘기하자면, 생각 좀 하고 만들라는 것이죠. 생각 없이 만들 코드를 나중에 리팩토링(Refectoring) 할 바에는 처음부터 리팩토링 비용을 줄이고, 좀 더 세련된 디자인으로 코드를 작성하라는 의미입니다.

단위 테스트(Unit Test) 라는 의미에서도 사실 개발자와 테스터, 고객과는 굉장히 괴리감이 있는 단어이기도 합니다. "단위 테스트" 라는 똑같은 단어를 사용하지만 그것을 받아들이는 사람의 직책이나 파트(Job) 이 어디냐에 따라 틀리기도 합니다. 아마도 애자일(Agile) 이라는 트랜드를 아느냐 모르느냐의 기준이 될 수 도 있습니다.

개발자 - "테스트 코드를 만들라는 의미군!"
테스터 - "나더러 테스트 코드를 만들라거야? 아니면 각 기능별로 테스트를 하라는거야?"
고객 - "기능별 테스트를 어떻게?"

단위 테스트에 대한 개발자의 입장

우선 개발자를 봅시다. 필자는 개발자에게 TDD 를 강요하기란 굉장히 어려운 문제라고 생각합니다. 테스트 코드를 작성하는 것은 만들어진 코드의 양에 비례하여 추가적인 테스트 코드를 작성해야 합니다. 테스트 코드를 만드는 것이 문제가 아니라, 시간이 아깝다는 것이죠. 테스트 코드를 만들 시간에 더 생산성 있는(폼-Form 빼는 작업) 이 훨씬 더 나을 것입니다. 사실 우리나라 SI 프로젝트의 문제가 일단 소프트웨어를 만들고 난 다음에, 유지 보수 계약으로 버그를 잡아 치웁니다.

이런 구조는 실제 개발했던 사람과 유지 보수 하는 사람이 교체되면서, 유지 보수 인력은 이미 떠난 개발 인력들에게 "뭐 이런 쓰레기 코드를..!" 이라는 말을 할 수 밖에 없죠. 다시 개발했던 당사자의 입장으로 돌아가 보면, 빨리 빨리 대충 돌아가는 기능을 만드느냐, 느릿 느릿하지만 완벽한 기능을 만드느냐라는 기로에 설 수 밖에 없습니다. 여기서 고객은 언제나 쉽게 맘이 변합니다. 기존의 기능이 추가되거나 변경되면서 이미 완성된 기능에 지속적으로 덧칠을 할 수 밖에 없습니다.

그럼 TDD 를 왜 해야 하는가에 대한 의문점을 가질 수 밖에 없습니다. 단위 테스트조차 여유로운 작업이 아님이 분명한데, 테스트를 먼저하라니!!! 만약 누군가가 그것을 저에게 강요한다면 충분히 해명하거나 변경의 근거가 다분할 것입니다. 아마도 필사적으로 반대 입장에서 논의를 할 지도 모릅니다. 잘 차려놓은 테스트 코드를 돌려보는 관리자의 입장에서는 완벽한 프로세스일지 몰라도 적어도 개발자의 입장에서는 테스트 코드, 아니 TDD 마저 그저 먼 산일 뿐입니다.

단위 테스트에 대한 테스터의 입장

일반적으로 엔터프라이즈 어플리케이션(Enterprise Application) 은 기반이 되는 어플리케이션 프레임워크(Application Framework) 를 구축합니다. 범용 프레임워크를 이용하여 개발자가 사용하거나 소프트웨어나 업무 구조에 맞도록 도메인 집약적인 프레임워크로 파생하거나 전환됩니다. 이 과정은 진정한 기반 프레임워크에서 파생될 수 도 있고, 단순한 라이브러리 형태로 파생될 수 도 있습니다.

일단 팀의 구성원은, 개발 팀, 테스트 팀으로 구분합니다. 개발 팀은 오직 기능을 구현하고, 테스트 팀은 구현된 기능을 수동 테스트(Manual Test) 를 하거나 단위 테스트 코드를 작성하여 테스트를 수행합니다. 즉, 역할이 완벽히 분리되어 개발 인력은 개발에만, 테스트 인력은 원칙에 따른 테스트만 수행하는 형태입니다. 테스터가 테스트를 진행하면서 개발자가 구현해 놓은 기능에 결함이 발견되면, 개발자에게 이것을 알리고 반복적으로 테스트만 전담합니다. 이 프로세스에서 팀 간의 커뮤니케이션은 문서가 될 수 도 있고, 메신저가 될 수 도 있고, 메일이 될 수도 있습니다. 그것은 테스터에게 그리 중요한 것이 아닙니다.

하지만, 점점 더 고객은 특정 프레임워크나 아키텍처에 종속되길 원하지 않습니다. 그 이유는 과거의 잘못된 방법론이나 Non OOP(Object Oriented Programming) 의 확장성에 매우 민감합니다. 즉 기존에 어떤 아키텍처를, 어떤 프레임워크를 쓰던지 간에 현재와 미래가 더 중요할 수 밖에 없습니다. 이러한 과도기에서 과연 테스터는 무엇을 할 수 있을까요?

OOP 기반 프로그래밍은 추상화입니다. 그리고 추상화를 하다 보면 다형성을 따라가게 됩니다. 개발자나 아키텍처에게는 박수를 쳐줘야 하겠지만, 테스터의 입장에서는 전혀 그렇지 않을 수 있습니다. 즉, 테스터는 테스트 코드를 작성하기 위해 전체적인 아키텍처까지 이해해야 하는 어처구니 없는 상황이 발생할 것입니다. 아마도 잘 나가는 개발자들은 Mockup 을 이야기 할 것입니다. 그런데 누가 Mockup 을 할 겁니까? 아무것도 모르는 테스터? 아니면 코드를 작성한 개발자?

Mockup 에 대해서 아래의 링크를 참고 하세요.

http://blog.powerumc.kr/222

단위 테스트에 대한 고객의 입장

얼마 전에 엔터프라이즈 시스템의 확장성과 안정성에 대해서 고객과 미팅을 한 적이 있습니다. 고객은 현재의 프레임워크는 특정 프레임워크에 종속되어 확장이 불가능하며, 다른 프레임워크로 교체마저 불가능하다고 합니다. 그리고 과거의 기술을 사용하기 때문에 특정 벤더의 지원이 부족하고 그것을 이해하는 내부 직원도 없을 뿐더러, 시스템이 간혈적으로 다운되기도 한다고 합니다. 시스템이 돈(Money) 과 직결되는 문제라면 어느 누구도 나서서 고치겠다고 할 사람 없지 않겠습니까?

차세대 시스템에 대한 목표를 언급하면서 SOA(Service Oriented Architecture) 의 구현 산출물인 ESB(Enterprise Services Bus) 에 대해서 열심히 설명하면서, 단위 테스트에 대해서 언급을 한적이 있습니다. 그리고 대부분 고객의 관리자가 젊은 개발자가 아니기에, 이러한 최신 트랜드의 아키텍처와 방법론(?) 을 설명하면 기대 반, 의심 반으로 기대 심리를 갖기도 합니다.

하지만, 고객에게 단위 테스트에 대한 이야기를 언급할 때는 전형적인 과거의 산출물을 상상합니다. 바로 테스트의 이력을 볼 수 있는 문서이죠. 하지만 현재는 이미 그런 단위 테스트의 자동화와 산출물은 자동화가 되었음에도 불구하고 오히려 고객은 과거의 자신의 경험이 비추어 이해합니다. 이미 현재 시스템도 단위 테스트를 수행했고, 철저히 감사했음에도 불구하고 현재 이지경에 이르렀다는 것이죠.

즉, "단위 테스트" 라는 똑같이 형용하는 문자임에도 불구하고, 서로의 이해가 너무나도 부족합니다. 아마도 단위 테스트의 개념조차 없었던 코볼(Cobol), 포트란(Fortran) 의 원시 언어로 돌아가는 기분이 들었습니다. (학문적으로 고급 언어에 속하지만 과연 현재도 고급 언어일까?…) 즉, 그들과 눈높이를 맞출 수 있는 방법은 목표대로 보여주던가, 아니면 우리를 믿지 못하고 과거의 경험에 빗대어 비교할 것인가…

그렇다면 누가 단위 테스트를 수행해야 하는가?

아마도 이 섹션은 특히 필자의 개인적인 생각이기도 합니다. 어쨌든 "단위 테스트"에 대해 이렇게 이해 관계가 얽히는 풀기 힘든 문제이기도 합니다.

그럼 결론적으로 과연 누가 테스트를 수행해야 하는가 입니다. 아마도 필자의 개인적이고 경험적인 부분이므로, 다른 의견이 있다면 조언 부탁 드립니다.

우선 개발 팀과 테스터 팀의 조직적인 분할이 필요합니다. 즉, 팀 별로 역할 범위를 정확하게 명시함으로써 프로세스적인 측면에서 해결해야 할 문제라고 생각합니다. 이러한 문제는 Microsoft Solution Framework(MSF) 에서 잘 설명을 하고 있습니다.

아래의 필자의 분류는 우리나라의 전형적인 프로젝트 진행 구조를 고려하였습니다.

개발 팀	코드 개발, 단위 테스트 코드 개발
테스트 팀	매뉴얼 테스트(Manual Test), 테스트 인프라 관리
관리자	코드 및 테스트 조율 및 소프트웨어 품질 조율
고객	소프트웨어 품질에 대한 논의 및 제안

즉, 필자가 이렇게 구분한 의도는 어느 누군가에게 책임을 소프트웨어의 품질에 대해 소위 몰빵(?) 할 수 없다는 것입니다. 결국 가장 유연해야 할 책임과 역할의 구분이 명확하지 않는다는 것은 스스로의 무덤을 파는 것과 다를 바가 없습니다.

단위 테스트에 대한 적절한 대안은 있는가?

필자는 위와 같은 이유로 팀과 역할을 구분하여 단위 테스트를 수행하는 것을 권장합니다. 물론 위의 팀별 역할은 정답은 아니고, 조직의 형태에 따라 유연하고 적절하게 배분이 되어야 할 것입니다.

필자는 "단위 테스트" 라는 주제로 개인적인 견해를 이야기했지만, 더 나아가 소프트웨어를 개발하기 위한 방법론(SDLC-Software Development LifeCycle) 과 고객이나 기업의 거버먼스와 비즈니즈 가치가 결합되지 않으면, 좋은 소프트웨어를 절대 나올 수 없다고 생각합니다. 즉, 절대적인 방법론이 있고, 방법론을 적용한 경험이 있다고 해서 좋은 소프트웨어가 나올 수 없습니다. 극단적으로, 전산화가 제대로 되지 않은 업무 부처가 있음에도 불구하고 SOA 를 적용한다고 해서 절대 통합과 공유라는 컨셉을 가질 수 없는 것과 마찬가지 입니다.

애자일(Agile)의 대가인 켄트 백(Kent Back)은 아래와 같은 이야기를 한 바 있습니다.

Individuals and interactions over processes and tools
프로세스와 도구보다는 개인과 상호작용을

대부분은 애자일 선언의 이러한 용어로 인해, 매우 혼란스러워하거나 기존의 프로세스를 갈아치우려고 합니다. 마치 애자일의 XP 에서 이야기하는 원칙에서 하나라도 빠트리면 애자일이 아닌 것처럼 말입니다. 애자일의 주요 키워드는 "변화" 이지, 절대 강요가 아닙니다. 만약, 고객은 철저한 기간 엄수를 요구하는 폭포수 모델(Waterfall Model) 을 강요하지만, 개발 팀은 애자일(Agile) 만 고집한다면 그것은 서로 파멸로 가는 길이며, 애자일의 진정한 의미를 이해하지 않았다고 볼 수 있습니다.

켄트 백(Kent Back) 은 아래의 링크를 통해 위의 원칙에 대한 오해를 풀어내고 있습니다.

Tools for Agility - A White paper by Kent Beck, Three Rivers Institute

http://www.microsoft.com/downloads/details.aspx?FamilyId=AE7E07E8-0872-47C4-B1E7-2C1DE7FACF96&displaylang=en

필자의 회사인 .NETXPERT 의 안재우 수석님께서 저에게 조언을 주신 문서입니다.

오늘은 "단위 테스트" 에 대한 주제로 언급을 했습니다. 점차적으로 개발, 테스트에 대한 괴리감을 어떻게 줄이고 진정한 통합이라는 큰 주제를 통해 조금씩 파해쳐 보기로 하겠습니다.

다음 글
[Software Development/Agile] - [ALM-Test] 왜 단위 테스트를 해야 하는가? [2]

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

DISK2VHD 로 파티션이 여러 개인 물리 디스크 문제 해결

엄준일(땡초) — Wed, 03 Feb 2010 08:30:00 +0900

Disk2Vhd 는 물리적인 저장소를 Hyper V 의 가상 하드 디스크로 만들어주는 도구입니다. 헌데, 이 도구를 이용하여 실제 부팅 가능한 가상 하드 디스크로 만들기 위해서 한 가지 주의해야 할 점이 있습니다.

파티션이 여러 개인 하드 디스크의 문제

만약 물리 디스크가 여러 개의 드라이브로 파티션이 나누어져 있을 경우 아래와 같이 파티션 0 인 C 드라이브만 가상 하드 디스크로 만들 경우 문제가 발생합니다.

아마도 파티션 정보가 모두 포함되지 않아 아래와 같은 현상이 발생하는 것 같습니다.

파티션이 여러 개인 경우 모두 가상 하드 디스크로 변환

이런 문제가 발생할 경우, 실제 C 드라이브의 부팅 가능한 OS 가 있음에도 부팅이 되지 않습니다. 아래와 같이 모든 파티션을 선택한 후 Disk2Vhd 를 이용하여 가상 하드 디스크로 만들면, 부팅 가능한 가상 하드 디스크로 만들 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Windows Server AppFabric - Velocity 시작하기

엄준일(땡초) — Thu, 28 Jan 2010 09:00:00 +0900

혹시 위의 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" ?>

<section name="dataCacheClient"

type="Microsoft.Data.Caching.DataCacheClientSection,

CacheBaseLibrary"

allowLocation="true"

allowDefinition="Everywhere"/>

<section name="fabric"

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

FabricCommon"

allowLocation="true"

allowDefinition="Everywhere"/>

</configSections>

<!-- (optional) specify local cache

<localCache

isEnabled="true"

sync="TTLBased"

objectCount="100000"

ttlValue="300" />

-->

<!-- note: cache notifications are

not supported with simple client -->

<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 를 실행하시면 됩니다. 단, 프로그램 추가/제거에서 찾을 수 없답니다. ^^

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Windows Server AppFabric - 호스트 추가하기

엄준일(땡초) — Thu, 28 Jan 2010 09:00:00 +0900

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

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

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

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

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

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

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Internet Explorer 8 성능 향상

엄준일(땡초) — Thu, 28 Jan 2010 09:00:00 +0900

외국의 ZDNET 기사에 Internet Explorer 8 의 성능 향상 방법을 소개 하고 있습니다. 많은 분들이 Microsoft 의 Internet Explorer 의 성능 문제로 불만도 많은 분들이 계실텐데요, 아마도 이 방법을 통해 성능이 웹 서핑 성능이 향상 되길^^

특히 이미 이 기사에서 언급한 내용이지만, Internet Explorer 의 성능 저하의 주요 원인은 각종 Add-on 과 특히 Adobe Flash Player 가 주요 원인이라고 합니다. 실제로 가장 많이 사용되고 있는 브라우저인 만큼 피드백도 많겠죠. 좋은 피드백이든 나쁜 피드백이든…

Internet Explorer 8 의 성능을 향상하는 단계는 아래와 같이 수행하라고 합니다.

Step 1. 현재 설치된 Adobe Flash Player 를 제거하라.

프로그램 추가/제거로 제거하지 말고 아래의 링크를 통해 제거하라고 합니다.
How to uninstall the Adobe Flash Player plug-in and ActiveX control.

웹 사이트 방문이 귀찮으신 분은 이 링크(uninstall_flash_player.exe) 를 클릭해서 설치하세요.

Step 2. Internet Explorer 기본 설정으로 변경해라.

도구->인터넷 옵션에서 원래대로 버튼을 클릭합니다.

최소한 이 버튼 클릭만으로 상당한 효과가 있을 듯 하군요. 각종 더미 add-on 까지 모두 싸그리 사용하지 않는 상태로 만들어 버릴테니까요.

Step 3. Flash Player 를 다시 설치하라.

Adobe Flash Player 를 설치하는 링크 페이지 입니다.
웹 사이트를 방문하기 귀찮으신 분은 이 링크(Install_flash_player.exe) 를 클릭하여 실행하세요. 설치 중에 오류가 발생한다면, 열려있는 Internet Explorer 를 종료하고 "다시 시도"를 클릭하세요.

아무래도 구형 Flash Player 보다 최신의 것이 보안 취약이나 성능이 개선이 되었을 듯 합니다.

Step 4. Internet Explorer Add-on 을 다시 활성화해라.

주로 사용하거나 필요한 Add-on 만 찾아서 활성화 하시면 됩니다.

원문 기사의 댓글을 보면 Flash Player 와 Adobe 는 이미 상당한 안티 팬을 거느리고 있네요.^^;

그리고 필자가 위의 과정을 수행한 후 테스트해 본 결과, Internet Explorer 성능이 상당히 빨라진 것 같습니다. 크롬 아이콘 버튼을 클릭하고 메인 홈 페이지(네이버) 가 HTML 랜더링이 완전히 끝나는 시간과, Internet Explorer 에서도 이와 같이 아이콘 클릭하는 시간부터 체크를 했는데... 거의 흡사하네요 ^_^; (제가 좀 관대한가...)
(뭐 크롬은 HTML 텍스트부터 뿌려주고 이미지는 비동기식으로 랜더링하는 방식이라 체감상 차이는 있을 수 있습니다)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Team Foundation Client 연결 오류 문제

엄준일(땡초) — Wed, 27 Jan 2010 14:18:08 +0900

Team Foundation Object Model 을 이용하여 별도의 TFS Client 를 개발하는 경우가 종종 있습니다. 개발자라면 "Visual Studio 에 Team Explorer 가 있는데 왜~?" 라고 묻기도 하지만, 비개발자들 예를 들면, 관리자, 비즈니스 담당자들이 Team Foundation Server 에 접속하기 위해서는 Visual Studio 를 실행해야 합니다. 왜냐하면, Team Explorer 의 필수 구성 요소가 바로 Visual Studio Shell 이기 때문이죠.

Team Foundation Web Access 와 같은 제품이 있긴 하지만, TFS 를 사용해 보지 않은 사람은 사용법도 익히기 어려울 뿐만 아니라 특정한 프로세스를 강요할 수 없는 이유이기도 합니다. 이런 이유로 개별적인 TFS Client 제품을 선호하는 경우가 있기도 합니다.

Team Foundation Client (예를 들면 Team Explorer) 등은 Visual Studio 에 매우 종속적인 제품입니다. 그래서 TFS Server 의 정보를 Visual Studio 하위의 레지스트리에 관리합니다.

아래는 그 예를 보여주는 오류 시나리오 입니다.

오류 발생 조건

1. Visual Studio 에서 특정 TFS 서버를 제거한다

2. 독립 TFS Client 에서 TFS 에 접속이 안된다.

오류 해제 조건

1. Visual Studio 에서 특정 TFS 서버로 연결한다

2. 독립 TFS Client 에서 TFS 탭 접속이 된다.

오류가 발생하는 예외 메시지 입니다.

처리되지 않은 예외: Microsoft.TeamFoundation.TeamFoundationInvalidServerNameException: TF30076: 제공한 서버 이름 dxtfs2008a이(가) 검색된 서버 URI와 일치하지 않습니다. 서버 이름이 올바른지 확인하십시오.

위치: Microsoft.TeamFoundation.Client.TeamFoundationServer.GetUriForName(String name)

위치: Microsoft.TeamFoundation.Client.TeamFoundationServer.get_Uri()

위치: Microsoft.TeamFoundation.Client.CheckAuthenticationProxy..ctor(TeamFoundationServer server)

위치: Microsoft.TeamFoundation.Client.TeamFoundationServer.Authenticate(Boolean useProvider, ICredentialsProvider provider)

위치: Microsoft.TeamFoundation.Client.TeamFoundationServer.EnsureAuthenticated()

위치: ConsoleApplication1.Program.Connection() 파일 C:\Users\엄준일\Documents\Visual Studio 2008\Projects\TFSSample\ConsoleApplication1\Program.cs:줄 43

위치: ConsoleApplication1.Program.Main(String[] args) 파일 C:\Users\엄준일\Documents\Visual Studio 2008\Projects\TFSSample\ConsoleApplication1\Program.cs:줄

계속하려면 아무 키나 누르십시오 . . .

위 문제를 해결하기 위해서는 반드시 서버 주소가 팀 탐색기에 등록이 되어야 합니다. 이는 곧 팀 탐색기에 등록이 되어야 한다는 말이며, 이는 Visual Studio 관련 레지스트리에 등록이 되어야 한다는 의미입니다.
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers

위의 레지스트리에 TFS 서버 주소를 넣어주시면, 독립 TFS Client 에서도 잘 접속이 되는 것을 확인할 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

MEF 에 Generic Type 을 지원하기 위해서..?

엄준일(땡초) — Wed, 27 Jan 2010 09:00:00 +0900

먼저 이전 포스트의 "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 에게 모두 의존하는 방법입니다. 우선 아래의 링크를 참고하세요.

MEF + Factories Using an Export Provider
http://blog.eworldui.net/post/2008/11/MEF-2b-Factories-Using-an-Export-Provider.aspx

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

1: public interface IService { }

2: public interface IUserService : IService { }

4: [Export]

5: public class UserController {

6: [ImportingConstructor]

7: public UserController(IUserService userService) { }

8: }

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가지 방법을 정리해보도록 하죠.

	장점	단점
MEF Factory Export Provider	구현이 쉽다	Factory 의 관리가 힘들다 Factory 의 확장이 힘들다 모든 Factory 를 Catalog 로 관리해야 한다.
MEF Contrib Type Mapping	합리적이다	Type Mapping 코드가 복잡하다 Mapping/Locator/Context 클래스를 구현해야 한다 상속 기반이다
MEF + Unity Integrated	합리적이고 , 구현이 쉽다	Injection 기법이 서로 달라진다 Injection 코드가 서로 달라진다 Injection 이 호환되지 않는다 각각의 객체간의 Composite 이 불가능하다

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

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

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Windows Server AppFabric - Velocity 란?

엄준일(땡초) — Wed, 27 Jan 2010 09:00:00 +0900

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

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

MEF 는 Generic Type 을 지원하지 않는다!

엄준일(땡초) — Tue, 26 Jan 2010 12:35:40 +0900

.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 에 대한 아티클을 볼 수 있습니다.

Managed Extensibility Framework
http://blog.powerumc.kr/tag/Managed%20Extensibility%20Framework

우선 이러한 원인은 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 프레임워크에 종속되지 않는 코드입니다)

var container = new Container();
container.Register<IUMC<>>();

var obj = container.Resolve<IUMC<string>>();
obj.SayHello();

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 로는 전혀 불가능한 코드입니다^^;)

public interface IUMC<T>
{

void SayHello<T>();
}

[Export(typeof(IUMC<>))]
public class UMC<T> : IUMC<T>
{
public void SayHello()
{
// TODO Impl...
}
}

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

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

TFS 2010 설치 하기

엄준일(땡초) — Fri, 22 Jan 2010 08:30:00 +0900

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 에 연결된 모습입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

TFS 2010 Build Service 설치

엄준일(땡초) — Fri, 22 Jan 2010 08:30:00 +0900

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 설치가 완료된 화면입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

TFS 2010 설치 과정 중에 TF255040 문제

엄준일(땡초) — Fri, 22 Jan 2010 08:30:00 +0900

설치 과정 중에 TF255040 문제

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

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

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

[Error @12:07:34.650] Microsoft.TeamFoundation.Admin.TfsAdminException: TF255040: Install SQL Server Reporting Services or at a minimum SQL Client Connectivity Tools on the application tier to ensure Analysis Services object model is present for warehouse processing. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.AnalysisServices, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. 지정된 파일을 찾을 수 없습니다.

at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)

at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks)

at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)

at System.Reflection.Assembly.Load(String assemblyString)

at Microsoft.TeamFoundation.Admin.UIHelper.CheckAnalysisInstanceLoad(String analysisInstance)

--- End of inner exception stack trace ---

at Microsoft.TeamFoundation.Admin.UIHelper.CheckAnalysisInstanceLoad(String analysisInstance)

at Microsoft.TeamFoundation.Management.Controls.WizardCommon.ServerTestControl.m_testWorker_DoWork(Object sender, DoWorkEventArgs e)

at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)

at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)

그래서 Microsoft.AnalysisServices, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 어셈블리가 GAC 에 등록이 되어 있는지 확인을 해 보았습니다. 역시나 문제는 위의 어셈블리가 설치가 되지 않아서 발생한 문제입니다.

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 에 접근할 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

거버먼트 2.0 - 개방, 공유, 활용

엄준일(땡초) — Thu, 21 Jan 2010 08:30:00 +0900

* 아래는 2009-12-01 거버먼트 2.0 이라는 주제로 한국정보화진흥원에서 주최한 세미나 입니다. 아래의 링크를 통해 발표 자료를 다운로드 할 수 있습니다. (현재 다운로드 오류가 발생하고 있네요^^;)

http://www.webkoreaforum.or.kr/government2.0/agenda.htm

마치 Web 2.0 의 물결 흐름에 따라 국가 및 관계기관 들은 거버먼트 2.0 을 키워드로 새로운 변화를 준비하고 있습니다. 예전에는 정보화, 전산화를 위한 데이터 중심의 시스템이었다면, 최근에는 데이터의 활용, 즉 개방, 공유, 활용이라는 세 가지의 큰 키워드를 가지고 국정 운영이 변화되어 가고 있습니다.

거버먼트 2.0 은 결국 Web 2.0, Social Network, Service Technology 라는 세 가지 고민을 해야 합니다. (하지만 커버먼트 2.0 에는 이 세 가지를 명시되어 있지는 않다고 합니다) 거버먼트는 기업과 고객 대상의 B2B, B2C 와 같은 컨셉으로 G2B, G2C 를 이루고자 합니다.

정부는 축적된 데이터를 통해 국가, 연계기관, 산하기관, 국민을 대상으로 대국민 서비스를 시행하기 위한 발판으로 삼고자 합니다. 또한, 거버먼트 2.0을 통해 인적자원의 활용을 끌어올리고, 비용을 절감하기 위한 의지도 보이고 있는 것 같습니다.

하지만 현재까지 구축되어온 정부 시스템은 상호 연동을 위해 기술적, 정책적으로 어려움을 겪고 있으며 이러한 숙제는 SOA 와 클라우드 컴퓨터 이야기로 자연스럽게 흘러갑니다.

서비스 기반 거버먼트 2.0 모델

정부는 재사용 가능한 서비스를 이용한 세 가지 전략을 보이고 있습니다.

Public Service for Full Functionality (SaaS)
Public Service for Unit Functionality (CaaS)
- Mash-up
- Open API
Public Service for Sharing Information
- Web
이러한 세 가지 전략과 사용자와 인터렉션 어플리케이션(Web Browser, Client Application) 에 따라 Interaction Patterns 을 도출할 수 있으며, 이렇게 도출된 8 가지 유형별로 아키텍처는 달라질 수 있다고 합니다.

거버먼트 2.0 은 아래와 같이 정리가 되네요.
서비스 지향적이고
공감대, 철학적 (용어의 차이는 있을 듯 합니다)
국가 차원의 아키텍처
Priorities 정의

국가 차원의 서비스 통합을 위해 SOA 가 언급이 됩니다. 예전과 같은 어플리케이션 단위별로 서비스의 제공은 바로 제공자와 소비자가 굉장히 근접해 있습니다. 하지만 SOA 는 그 서비스가 내 서비스가 아님을 강조하며 서비스 기반 거버먼트 2.0 모델 단원은 마무리가 되었습니다.

SOA 와 클라우드 컴퓨팅

최근에 가장 트랜드한 기술이 바로 클라우드와 SOA 입니다. 이제 SOA 는 자리잡아 가고 있는 아키텍처인 듯 합니다만, 클라우드는 현재까지도 기대치가 높고 오래가지 않아 조만간 그 거품은 빠진다고 예언합니다.

이것을 추진하려는 정부의 목표는
대국민 서비스 통합
업무 효과,효율 향상
민간산업활성화
중복투자방지
신속한 변화대응력

결국 조직의 비즈니스를 확대하고 새로운 서비스를 창출하는 것이 그 중심에 있고, 조직 내부의 고도화와 조직간의 연계를 위한 개방의 의지도 보이고 있습니다.

실제로 독일의 http://dvdv.de 서비스는 연방 산하 5,246개의 행정 업무를 통합하여 서비스를 공유하고 있다고 합니다. 곧이어 우리나라도 2013년 까지 교통정보나 취업 정보 등 100가지의 서비스를 공유하기로 하는 목표를 추진하고 있다고 합니다.

기타

그 외의 세션들은 IBM 의 클라우드 기술과 ORACLE 의 SOA 특히 ESB 쪽으로 편향되어 설명을 해서 그다지 흥미를 느끼지는 못했습니다. 약간의 자사 제품 홍보 스타일?? -_-;

나름대로 관심 갖고 있던 분야에 대해 세미나를 듣게 되어 좋았고, 특히 세미나 참석자는 다양한 공공 분야의 사람들이 관심을 갖고 세미나에 참석을 한 것을 보면 많은 기대를 할 만하다고 생각이 듭니다.

그리고 무료 세미나임에도 불구하고, 점심 식사가 양식 코스 요리로 제공이 되어 좋았던 기억이 남습니다. ^_^

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Hyper-V 가상 서버간의 PING 오류 문제

엄준일(땡초) — Fri, 15 Jan 2010 09:00:00 +0900

Hyper-V 의 가상 서버의 Active Directory 서버 간에 발생한 발생한 문제에 대한 내용입니다.

오류 문제

예전 Team Foundation Server 2008 을 VMWare Server 를 이용하여 3-Virtual Machine 으로 구성했던 적이 있습니다.

Server 1 - Active Directory Server
Server 2 - MSSQL 2008 Server
Server 3 - Team Foundation Server 2008 and Sharepoint and Web Server

최근에 이와 같은 환경으로 Team Foundation Server 2010 Beta 2 를 구성하였고, 도메인으로 구성된 서버간에 MSSQL 2008 설치 시에 인증과 관련된 문제가 발생하였습니다. MSSQL 2008 이 설치가 되지 않는 시점에서 Team Foundation Server 설치는 꿈도 꾸지 못할 문제이기도 합니다.

아래는 오류가 발생하여 여러 가지 방법으로 문제를 해결하기 위해 테스트를 진행했었습니다.

Hyper-V 1 (AD) : Windows Server 2003 64비트, Active Directory, DNS (정방향, 역방향)

Hyper-V 2 (SQL2008): Windows Server 2003 64비트, SQL 2008 (SqlServer 계정 도메인 로그인->SQL 설치)

Error 1 : 사용자 식별자 매핑 오류 – 계정에 CER 인증서를 매핑하여 오류 안남

Error 2 : 아래의 스크린 샷

Test 1 : SqlServer 계정 + 로컬 Administrator 계정으로도 설치 실패

Test 2 : AD 서버 설치시 Windows 2008, 2003, 2000 호환 모드로 환경에서 각각 SQL 2008 설치 실패

Test 3 : 로컬 Administrator 계정으로도 설치 실패

Test 4 : SqlServer 도메인 계정으로 설치 실패

이와 관련된 문제를 해결하기 위해 많이 노력하였으나, 결국 몇 달 동안 해결하지 못한 채 단일 서버로 구성하여 쓰고 있다가 최근에 VPC 와 Hyper-V 용으로 단일 서버로 설치된 버전이 나와서 이것으로 사용하고 있었습니다.

하지만, 이런 미스터리를 해결하지 못한 나를 원망하면서 머리만 쥐어짜고 있는 와중에 중요한 단서를 하나 얻게 되었습니다. 바로 Active Directory 로 묶인 서버간에 PING 이 정상적으로 되지 않고 오류가 발생했던 것입니다. 이 문제는 정말 다행인지 중요한 단서가 되었고 결국에는 문제를 해결할 수 있었습니다.

즉, Active Directory 로 묶인 Hyper-V 간의 가상 서버 간에 PING 을 날리면 아래와 같은 오류가 발생했습니다. 가상 서버의 IP 로 PING 을 날리면 정상이지만, NetBios 이름으로 PING 을 날릴 경우에만 발생한다는 것입니다.

IP 드라이버를 찾을 수 없습니다. - 에러 코드 5

저는 시스템이나 서버를 전문적으로 관리해 본 적이 없기 때문에, 머리를 쥐어짜면서 해결을 하기 위해 몸부림을 쳤던 것이지요.

오류의 원인

문제는 바로 Hyper-V 의 가상 서버간의 도메인 계정의 SID 가 원인인 것으로 밝혀졌습니다. 예전에 필자는 TFS 백업을 신규 도메인에서 복원하기 에서 설명했듯이 도메인 계정은 내부적으로 SID 와 매핑이 되어 있다는 것입니다. 쉽게 얘기하면, SID 는 도메인간에 같은 이름이나 계정이라도 "그때 그때 달라요" 라는 것이죠.

이런 문제를 재연하는 방법은 아래와 같이 하시면 됩니다. (굳이 Hyper-V 가 아니더라도)

Hyper-V (또는 기타 가상화 머신) 에서 Windows Server 200x 를 설치한다.
설치된 Windows 의 .VHD 파일을 복사한다.
최초 설치된 윈도우에 Active Directory 를 설치한다
복사한 .VHD 서버는 Active Directory 에 도메인 가입한다.
PING 을 날리면 "IP 드라이버를 찾을 수 없습니다 - 에러 코드 5" 에러가 나온다.

참 쉽죠?? 윈도우의 SID 에 대해서는 제가 자세히 설명하기 힘드므로, 아래의 블로그를 참고 하시면 됩니다.

Windows 서버에서의 SID 란 무엇인가?

즉, 에러의 원인을 유추해보면

첫 번째, Active Directory 의 도메인 계정은 가상 서버간에 SID 를 제대로 식별할 수 없으므로 오류가 난다거나
두 번째, 윈도우 내부적으로 고유의 SID 를 갖고 설치가 된다거나
세 번째, 첫 번째와 두 번째 원인이 복합적이거나…

오류 해결 방법

오류의 해결 방법은 의외로 간단했습니다. 그렇게 발버둥 칠 때는 검색을 해봐도 해결 방법을 찾을 수 없었지만, 뭔가 느낌이 온 이후에는 한방에 검색하니 해결 방법이 검색되더군요..

Ping gives - Unable to contact IP driver - Error Code 5

즉, 윈도우의 SID 를 초기화하고 재할당하기 위해서 "sysprep" 도구를 이용하는 방법입니다. 아래와 같이 반드시 "일반화(Generate)" 를 체크하셔야 합니다.

이런 해결 방법으로 유추해보면 아마도 위의 두 번째 방법인, 윈도우 내부적으로 SID 를 갖고 있는 것이 아닐까라는 생각이 듭니다. 아마도 가장 유력한 것이 Microsoft 에서 윈도우 라이선스 인증을 위한 데이터베이스에서 라이선스 정책을 따르기 위해 고유 윈도우 SID 를 생성하는 것이라는 생각이 듭니다.

VHD 이미지로 윈도우 설치의 귀차니즘을 때우기 위한 꽁수가 Active Directory 에서의 큰 문제로 발생하니 무척 허무하기도 합니다. 하지만 이렇게 지식을 쌓아가도 어차피 언젠가는 한줌의 재가 될 미래를 생각하니, 판도라 행성에서 다시 태어나길 바라며 ^_^ (영화 아바타 증후군을 앓고 있습니다 +_+)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Visual Studio 2010 출시 일정

엄준일(땡초) — Fri, 15 Jan 2010 08:30:00 +0900

오늘 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월이 정말 기대가 됩니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

TAEYO.NET - 2010 신년 세미나

엄준일(땡초) — Tue, 12 Jan 2010 23:50:52 +0900

태오 닷넷에서 ASP.NET 4.0 를 과 JQuery 와 WCF REST 서비스에 대한 종합 선물 세트 세미나를 진행합니다.
신청하는 방법은 아래의 링크로 이동하셔서 댓글만 달아주시면 됩니다. ^^

http://taeyo.net/Forum/Content.aspx?TBL=NOTICE&SEQ=372&PGN=1

참석하실 분들은 리플에 자신의 이름(혹은 아이디)를 기입해주시기 바랍니다.







날짜 : 2010년 1월 30일 토요일 오후 2시



장소 : 선릉역 근처 포스코빌딩 서관 5층 마이크로소프트 세미나 룸



지도 : 











세션 시간 : 오후 2시부터 6시까지



세션 개요 : 







2:00 - 2: 50    ASP.NET 4.0 New Features ? Part 1



3:00 - 3: 50    ASP.NET 4.0 New Features - Part2 : URLRouting



4:00 - 4: 50    ASP.NET Web Service와 jQuery Ajax 유형별 소개 및 Pager 플러그인으로 방명록 만들기



5:00 - 5: 50    WCF를 사용한 REST 서비스 구현







구체적인 내용은 다음과 같습니다.







세션 1



시간 :  14:00 - 14:50  (50분)



발표자 : 최지훈 MVP (드원테크놀로지 컨설턴트)



제목 : ASP.NET 4.0 New Features ? Part 1



설명 : 



.NET Framework 4.0 Beta의 공개와 함께 ASP.NET 4.0에서도 많은 흥미로운 변화가 생겼습니다. 



ASP.NET 4.0에서 새롭게 등장한 기능 및 이전의 ASP.NET과 비교하여 달라진 기능들을 이해함으로써, 



보다 효과적으로 ASP.NET 4.0을 사용하는 방법을 알아보는 시간을 갖습니다.







세션 2



시간 :  15:00 - 15:50  (50분)



발표자 : 한상훈 MVP (한빛소프트)



제목 : ASP.NET 4.0 New Features - Part2 : URLRouting



설명 :



알기 쉬운 URL에 대한 정의와 어떠한 장점을 가지고 있는지에 대해 알아보고,



ASP.NET WebForms 환경에서의 URL Routing에 대한 전반적인 소개 및 구현을 해보도록 한다.







세션 3



시간 :  16:00 - 16:50  (50분)



발표자 : 박용준 MVP (프리랜서, 전문강사 )



제목 : ASP.NET Web Service와 jQuery Ajax 유형별 소개 및 Taeyo jQuery Pager 플러그인으로 방명록 만들기



설명 : 



jQuery Ajax 기능을 사용하여 ASP.NET Web Service에서 반환되는 여러가지 데이터 형식을 처리하는 유형을 



정리하여 설명한 후 이를 적용한 간단한 웹 응용 프로그램을 만들어 본다. 



 



세부 내용 : 



- ASP.NET + jQuery Ajax +  JSON : 단일값 반환



- ASP.NET + jQuery Ajax + JSON : Object(개체값) 반환



- ASP.NET + jQuery Ajax + JSON : DateTime(날짜값) 반환



- ASP.NET + jQuery Ajax + JSON : List값 반환 



- 페이징 처리시 Taeyo jQuery Pager 플러그인 적용 







세션 4



시간 :  15:00 - 15:50  (50분)



발표자 : 김경균 MVP (드원테크놀로지 컨설턴트)



제목:  WCF를 사용한 REST 서비스 구현



설명 : 



SOAP기반의 웹 서비스에 비해 가볍고 구현이 쉬운 REST에 대해 알아보고 WCF를 통해 REST 서비스를 구현해 



보도록 한다. 그리고 .NET Framework 4에서 추가된 WCF의 새로운 기능 중 REST와 관련된 부분에 대하여 



알아보도록 한다.







참석하실 분들은 리플에 자신의 이름(혹은 아이디)를 기입해주시기 바랍니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

WCF 성능 향상 팁

엄준일(땡초) — Fri, 20 Nov 2009 08:30:00 +0900

WCF Performance Optimization Tips

.NET Framework 3.0 부터는 Enterprise Services 를 잘 구현할 수 있는 WCF(Windows Communication Foundation) 라이브러리를 제공합니다. 특히 최근 .NET Framework 3.5 SP1 에서는 서비스의 통합 뿐만 아니라 Enterprise Services Bus 를 구현하여 최상의 SOA(Services Oriented Architecture) 를 구현할 수 있는 프레임워크입니다.

그렇기 때문에 기존에 .NET 이 제공하던 XML Web Services 와 WCF 를 동일 선상에서 비교하거나 생각하는 것은 굉장히 위험할 수 있습니다. 가끔 BasicHttpBinding 이나 WSHttpBinding 등을 사용하여 IIS 에 호스팅 할 경우 성능에 대해 고민을 해 보신 분들도 계실 겁니다. 예전에 XML Web Service 로 잘 수행했던 프로젝트를 WCF 를 사용하여 만들었을 경우 서버가 자주 뻗는 경우도 있었을 것입니다.

Web Based Performance Optimization Tips

즉, 일반적으로 IIS 에 호스팅되는 Web Application 이나 XML Web Service 의 성능을 향상시키기 위해서는 Thread 나 Connection 을 늘려주는 방법으로 성능 튜닝을 할 수 있었습니다. ( default 는 .NET Framework 1.1 기준 )

Max Connection - default 2
Max IO Threads - default 20
Max Worker Threads - default 20
Min Free Threads - default 8
Min Local Request Free Threads - default 4

잘 모르시겠다구요~? MSDN 에 보시면 나옵니다. 각각 항목은 단지 권장 값이고 튜닝을 하기 위해서는 "추천 수치 * CPU 개수" 가 바로 최상의 성능을 낼 수 있는 Threads 나 Connection 이 됩니다. 사실 기본 값으로 서버 성능을 최상으로 발휘하기에는 무리가 있습니다.

WCF Based Performance Optimization Tips

하지만 WCF 에서는 이러한 성능 튜닝 방법은 전혀 다른 차원의 이야기 입니다. 왜냐하면 Web Application 이나 XML Web Service 와 달리 WCF 는 ASP.NET Pipeline(파이프라인) 을 거치지 않기 때문입니다.

Microsoft 의 WCF 개발 팀은 이런 부분에서 참 아이러니한 이야기를 합니다.

"DDos 공격을 방지하기 위함이다!" 라고...

틀린 이야기는 아니죠. ASP.NET HttpRuntime 환경을 그대로 WCF 환경으로 적용하기에는 WCF 프레임워크의 아키텍처와는 너무나 비호환적이기 때문인 것 같습니다. 다시 바꾸어 말하면, WCF 는 내부적인 ASP.NET 파이프라인을 타지 않습니다. 그렇기 때문에 기본 옵션의 Session 이나 Call 옵션으로 Service Host 가 락(Lock) 에 걸리는 상황이 옵니다.

MaxConcurrentSessions 는 Default 가 10 이므로, Closing 되지 않은 클라이언트의 세션이 이를 초과하게 되면 Lock 이 걸리게 됩니다. 아래는 간단한 예제이지만, Closing 을 잘해주더라도 Multi Thread 로 테스트를 해 보시면 금방 Lock 이 걸리게 할 수 도 있답니다.

namespace WcfService1Console

{

class Program

{

static void Main(string[] args)

{

for (int i = 0; i < 20; i++)

{

ServiceReference1.Service1Client client = new WcfService1Console.ServiceReference1.Service1Client();

Console.WriteLine(i + " " + client.GetData(3));

}

WCF 서비스는 기본값이 Max Session 이 10개에 도달하면 클라이언트의 연결을 거부합니다. Session Lock 이 걸리고 이전의 세션이 끝나야 다른 Session 의 연결을 수락하게 됩니다. WCF Session 은 HTTP Session 과 다르며, 클라이언트와 서버의 인스턴트를 연결하는 인증 매커니즘과 비슷합니다. WCF 의 SessionMode 를 NotAllowed 로 동작하도록 세션 사용을 하지 않도록 설정해도 되지만, 이러한 방법으로는 클라이언트와 서버간의 연결을 보장하지 않을 뿐이지, 실제로 세션이 연결이 되지 않는 것은 아니기 때문에, 퍼포먼스 향상을 위한 좋은 방법이라고 볼 수는 없습니다.

그리하여 WCF 의 퍼포먼스를 향상시키기 위해서는 ASP.NET 과는 별도의 Throttling 환경의 조정이 필요합니다.

<serviceThrottling maxConcurrentCalls="50"

maxConcurrentSessions="50"

maxConcurrentInstances="100"/>

</behavior>

</serviceBehaviors>

</behaviors>

그리고 다시 테스트를 해보시면 Lock 이 걸리지 않는 것을 확인할 수 있습니다.

이 옵션은 아래와 같은 튜닝하는 것이 좋다고 가이드 합니다. 단지 권장 값이기 때문에 더 높은 값을 주어도 상관은 없습니다. 특히 MaxConcurrentInstances 는 Int32.MaxValue 값을 주셔도 됩니다. WCF 어플리케이션 서버의 배치와 Load-Balancing 을 고려하여 적절하게 주시면 됩니다.

	기본 값	권장 값	예 (4-Core)
MaxConcurrentSessions	10	기본 값 * CPUs	40
MaxConcurrentCalls	16	기본 값 * CPUs	64
MaxConcurrentInstances	26	권장 값의 MaxConcurrentSessions + MaxConcurrentCalls	104

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

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

엄준일(땡초) — Thu, 19 Nov 2009 08:30:00 +0900

앞서 얘기한 DxEF Dynamic Proxy 를 통해 WCF 서비스 확장 프레임워크가 탄생되었습니다. SoaServices 라는 이름에서도 알 수 있듯이 SOA(Services Oriented Architecture-서비스 지향 아키텍처) 를 구현하도록 도와주는 SOA 프레임워크입니다.

먼저 SOA, 그리고 SOA 를 구현하는 ESB(Enterprise Services Bus) 의 이해를 돕기 위해 아래의 링크를 참고하세요.

Enterprise Service Bus를 이용한 서비스의 연결
http://www.oracle.com/technology/global/kr/tech/soa/mastering-soa-series/part2.html

바로 SOA 를 구현하는 ESB 의 핵심 키워드는 아래와 같이 3개로 뽑을 수 있습니다.

서비스 가상화
중앙 집중적
정책 (Policy)

즉, SOA 인프라스트럭처로 전환하기 위해서는 많은 노력이 필요한데, DxEF.Proxy.Dynamic.SoaServices 는 개발 초기부터 SOA 기반으로 개발이 용이하도록 도와주는 프레임워크입니다.

실제로 대규모의 시스템에서 서비스의 확장을 고민하고, 서비스를 물리적/논리적으로 아무리 갈기 갈기 찢어 놓아봐야 결국 서비스 지향 아키텍처로 눈을 돌릴 수 밖에 없는 것이 현실입니다. 그렇지 않으면 지속적인 서비스 확장에 중복적인 비용이 들어갈 수 밖에 없으니까요.

DxEF.Proxy.Dynamic.SoaServices 프레임워크는 바로 개발 단계와 운영 단계별로 Provider 가 완벽하게 분리가 되어있습니다. 개발자는 서버의 물리적인 배치, 서비스의 종류, 서비스 제공자를 전혀 알지 못해도 개발이 가능하고, 이런 서비스는 즉시 운영 단계에서 서비스가 가능합니다. 그야말로 How 가 아닌, 좀 더 중요한 What 이라는 비즈니스 관점에서 개발과 운용이 가능하다는 점입니다.

개발 초기부터 Interface Contract 를 통해 완벽하도록 느슨하게 서비스가 결합되고, 프레임워크에서 제공하는 Interface Metadata 로 빠르게 서비스의 Delivery 가 가능합니다.

DxEF SOA Services 프레임워크에 대해서는 좀 더 베일에 가려놓도록 하고, 다음에 기회가 되면 다시 언급하도록 하겠습니다. ^__^

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

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

엄준일(땡초) — Wed, 18 Nov 2009 08:30:00 +0900

최근 .NET 에서도 오픈 소스 프레임워크가 상당히 대세이고, 많은 오픈 소스 프레임워크가 공개되고 있습니다. 개발자들은 선택의 폭이 굉장히 넓어졌고, 참고할 수 있는 레퍼런스의 양도 이제는 헤어릴 수 없을 정도입니다. 심지어 .NET Framework 소스 코드까지 디버그 심볼로 그 내부를 볼 수 도 있으며, 최근 .NET Framework 4.0 에 포함되는 일부 라이브러리는 아예 오픈 소스로 공개하고 있습니다.

이러한 프레임워크 홍수 속에서 어떤 프레임워크를 선택하느냐 또한 큰 고민이 아닐 수 없습니다. 예전 Pattern & Practice 스터디를 할 때 토론했던 내용 중에 '왜 돈주고 프레임워크를 쓰느냐! 오픈 소스를 써라' 라는 질문에 굉장히 좋은 비유의 답변을 들은 적이 있었습니다.

"내가 미국을 가기 위해서 조립 설명서를 보고 비행기를 조립해서 갈 수 도 있지만, 이미 만들어진 비행기를 타고 가는 방법이 있다. 선택은 자유다!"

필자는 오픈 소스 프레임워크를 반대하는 사람은 아닙니다. 저 또한 좋은 레퍼런스를 너무 감사하게 생각하고 있습니다. 대부분의 오픈 소스 프레임워크는 범용적으로 사용되기 위한 목적이기 때문에 도메인 집약적인 큰 프로젝트에서는 오픈 소스 프레임워크의 내부적인 파이프라인을 모르고서는 원활하게 쓰기가 힘이 들 수 도 있습니다. 특히 장애 발생 시 장애 추적의 범위가 훨씬 넓어지며, 문제 해결 또한 쉬운 작업은 아닐 것입니다.

어쨌든 나의 Dynamic Proxy 프레임워크 개발은 이러한 범용성이 강한 오픈 소스 프레임워크로는 도저히 불가능했습니다. 일부 검증되지 않은 오픈 소스 프레임워크와 돌아다니는 코드를 조합하여 원하는 기능을 만들자니 내 기분은 짜증이 나기 시작했습니다.

처음에는 P&P Unity Application Block 과 몇몇 오픈 소스를 사용하고자 했으나 제가 원하는 스팩 미달이었습니다. 일단 Unity Block 의 Dynamic Proxy 는 대략 아래와 같은 스팩을 제공해 줍니다.

종류	설명	비고
Interface Proxy	인터페이스를 구현한 객체의 Proxy 를 만듦	반드시 인터페이스를 구현해야 함
Virtual Method Proxy	Virtual 로 선언된 Method 의 Proxy 를 만듦 (.NET 에서는 명시적인 virtual 선언 없이는 불가능 하기 때문에 좀 불편하죠. 참고로 Java 에서는 명시적인 virtual 이 없이도 virtual 메서드로 컴파일 됩니다)	반드시 virtual 로 선언해야 함
Transparent Proxy	.NET Remoting 의 Real Proxy 를 이용하여 Proxy 를 만듦	성능이 느림
Interceptor Extension	프락시 객체에 AOP 와 같이 위빙(Weaving) 처리

결국 내가 하고자 하는 Dynamic Proxy + Mock 와 같은 좀 더 로우 레벨로 제어하기 힘들었습니다. 특히 Unity Application Block 에서는 IoC Container 와 함께 사용해야 하는 Extension 형태로 Dynamic Proxy 와 Interceptor 가 제공이 되기 때문에 단독적인 Proxy Framework 로는 사용하기에 적합하지 않았습니다.

DxEF.Proxy.Dynamic - Dynamic Proxy 프레임워크

결국 Interface 계약 기반의 Dynamic Proxy 와 Mock Object Proxy 를 생성이 가능한 프레임워크가 필요로 했습니다. 그리고 여기에 Interception 기능을 추가하여 Dynamic AOP 가 가능해졌습니다.

DxEF Dynamic Proxy 의 약간의 샘플을 보여드립니다. 어떤 느낌인지 감이 오셨는지요~?

[TestClass]

public class ProxyTest

{

[TestMethod]

public void TestMethod1()

{

InterfaceImplementationDynamicProxy<ILogger, Logger> proxy =

new InterfaceImplementationDynamicProxy<ILogger, Logger>();

var proxyObject = proxy.CreateProxy();

proxyObject.Write("A");

}

public interface ILogger

{

[SampleInterceptor]

void Write(string msg);

}

public class Logger

{

}

public class SampleInterceptorAttribute : InterceptorAttribute

{

public override IInterceptor CreateInterceptor()

{

return new SampleInterceptorHandler();

}

public class SampleInterceptorHandler : IInterceptor

{

#region IInterceptor 멤버

public InterceptorReturnMessage Invoke(InterceptorInputMessage input, InvokeRealMethod invoke)

{

Console.WriteLine("Before Action...");

var returnMsg = invoke(input);

Console.WriteLine("After Action...");

return returnMsg;

}

#endregion

}

이러한 Interface 계약 기반으로 C# 4.0 에서 제공하는 Duck Typing 을 Dynamic Proxy 만으로도 가능해집니다. 더 나아가 Mock Object 로 단위 테스트(Unit Test) 의 확장이 가능하고, PostSharp 과 같은 Assembly Rewrite AOP 방식으로도 활용이 가능합니다.

또한 빠른 성능을 위해 Proxy Object 는 Caching 이 되고, 특히 런타임에서 JIT 컴파일이 되지 않기 때문에 빠른 성능을 보장할 수 있습니다.

지금까지 단순히 DxEF Dynamic Proxy 에 대해서 주절주절 했는데, 이 프레임워크를 확장하여 훨씬 기가 막힌 재미있는 것은 다음 편에 계속 됩니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

파워포인트로 프레젠테이션 목차 만들기

엄준일(땡초) — Fri, 23 Oct 2009 08:30:00 +0900

일전에 모 xx 의 제안서 작업을 하기 위해 많은 양의 프레젠테이션을 만들었습니다. 제안서 총 페이지는 수백 페이지에 달할 만큼 굉장히 큰 규모의 프로젝트였고, 제안서에 포함되는 콘텐트의 양은 말할 것도 없었습니다. 그러는 중 프레젠테이션의 목차를 만들어달라는 요청이 들어왔고, 순간 나는 눈앞이 캄캄해졌습니다.

"이 많은 걸 언제 목차로 만들지??? OTL"

저에게는 딱 두 가지 방법이 떠올랐습니다. 첫 번째는 손수 목차에 페이지의 제목과 페이지 번호를 직접 타이핑하는 방법이고, 두 번째는 뭔지는 모르겠지만 자동화 도구를 이용하는 방법입니다. 일단 시작하는 마음은 무겁지만 최대한 즐겁다고 스스로 주문을 외운 뒤에 하나 하나 목차를 타이핑하여 만들어 가기 시작했으나, 이게 왠 끝이 보이지 않는 겁니다. ㅠ

제안서를 마무리 해야 할 시간은 점점 다가오고, "에라 모르겠다 VSTO 든 스크립트로 하던,,, 도저히 손으로는 못하겠다"

각설하고, 많은 양의 프레젠테이션의 목차를 만드는 방법을 알려드리지요.

파워포인트로 프레젠테이션 목차 만들기

PowerPoint 옵션의 리본 메뉴에 숨어있던 개발 도구 탭 을 활성화

그럼 리본 메뉴에 "개발 도구" 항목이 생깁니다. Visual Basic 을 클릭하여 VBAProject 에서 새로운 사용자 폼을 추가 합니다.

그리고 대충 아래와 같이 화면을 디자인 하고, Button 을 더블 클릭하여 클릭 이벤트에 코드를 넣습니다. 텍스트박스의 속성 중 MultiLine 을 True 로 지정합니다.

Private Sub CommandButton1_Click()

Dim title As String
For i = 1 To ActivePresentation.Slides.Count
    If ActivePresentation.Slides(i).Shapes.HasTitle Then
      If ActivePresentation.Slides(i).Shapes.title.HasTextFrame Then
        If ActivePresentation.Slides(i).Shapes.title.TextFrame.HasText Then
          title = title + ActivePresentation.Slides(i).Shapes.title.TextEffect.Text & " .......... " & ActivePresentation.Slides(i).SlideNumber & vbCrLf
        End If
      End If
    End If
Next

Me.TextBox1.Text = title

End Sub

그리고 스크립트를 실행하면 아래와 같이 멋진 결과를 얻을 수 있다. 보안상 이미지를 흐리게 처리하였습니다.

그리고 위의 결과로 프레젠테이션을 조금만 다듬으면 아래와 같이 멋진 결과를 얻을 수 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Team Foundation Server Object Model 로 Shelve 할 때 주의할 점

엄준일(땡초) — Fri, 23 Oct 2009 08:30:00 +0900

이전 Team Foundation Server (이하 TFS) 를 이용하여 통합 소스 관리 프로젝트를 수행한 적이 있습니다. TFS Object Model 이 참 잘 되어 있기 때문에 특별한 레퍼런스 없이도 쉽게 API 를 제어할 수 있었습니다. 허나 이상하게 Shelve(보류 기능) 과 관련하여 한참을 삽질을 한 적이 있는데요, 지금에 와서도 왜 이런지 이해할 수 없는 문제이기도 합니다.

다른 TFS Object Model 객체에서도 이러한 도메인 네이밍과 관련된 룰이 모두 통일되어 있다면 그냥 '그런가부다!!!' 할텐데, Shelve 에서만 이러한 문제가 발생한답니다. 이건 뭐~

var vcs                        = GetVersionControlServer();
var sourceController        = ObjectFactory.CreateObject<ISourceController>();
var workspace               = vcs.GetWorkspace(checkoutFilePath);

Shelveset set        = new Shelveset(vcs, title, owner);
set.Comment        = description;

PendingChange[] pendingChanges = workspace.GetPendingChanges(checkoutFilePath, RecursionType.None);
workspace.Shelve(set, pendingChanges, ShelvingOptions.None);

오류 내용은 아래와 같습니다.

테스트 메서드 TestProject.TfsControllerTest.SaveShelvesetTest에서 예외를 throw했습니다. Microsoft.TeamFoundation.VersionControl.Client.VersionControlException: 다른 사용자가 소유한 보류 집합을 만들 수 없습니다.

Microsoft.TeamFoundation.VersionControl.Client.Workspace.ShelveInternal(Shelveset shelveset, PendingChange[] changes, ShelvingOptions options)

Microsoft.TeamFoundation.VersionControl.Client.Workspace.Shelve(Shelveset shelveset, PendingChange[] changes, ShelvingOptions options)

GConfigurationAssistant.SourceControl.TfsController.SaveShelveset(String title, String description, String owner, String checkoutFilePath) : C:\DxTFS2008\GMarket\GConfigurationAssistant\SourceControl\TfsController.cs: 줄 158

TestProject.TfsControllerTest.SaveShelvesetTest() : C:\DxTFS2008\GMarket\GConfigurationAssistant\TestProject\TfsControllerTest.cs: 줄 185

이런 코드가 있을 때, 빨간색의 owner 는 반드시 DOTNETXPERT\XXX 와 같은 계정 형태로 지정해 주어야 합니다. 만약 xxx@dotnetxpert.com 와 같은 사용자 계정은 맥 없이 Shelve 할 수 없다는 오류가 발생한답니다. 뭐 여기까지면 이해하겠습니다만… 쩝...

더 이해할 수 없는 건 dotnetxpert\xxx 처럼 도메인명과 계정명의 대소문자가 틀려도 오류가 난답니다. 줸장~

사소한 문제일 수도 있지만, 풀리지 않는 미스테리인지, 아니면 명백한 TFS Object Model 의 버그인지...

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.