'umc'에 해당되는 글 162건

  1. 2011.06.09 [Visual Studio 2010 SP1] 실버라이트 4 지원
  2. 2011.06.08 [Visual Studio 2010 SP1] Help Viewer 1.1 (2)
  3. 2011.05.30 Visual Studio Korea 팀의 무료 온라인 백서 공개 (1)
  4. 2011.01.18 VSS 마이그레이션 전략
  5. 2011.01.07 Visual Source Safe 사용자를 위한 TFS2010 시리즈
  6. 2011.01.05 Team Foundation Server 2010으로 업그레이드, 마이그레이션, 동기화
  7. 2011.01.04 [ALM] 8. TDD vs 계약기반 테스트
  8. 2010.12.22 [PPT] 테스트와 가상화의 만남 - 테스트 가상화(Lab Management) (1)
  9. 2010.11.09 곧 다가올 기술, Microsoft Research [2/2]
  10. 2010.11.04 곧 다가올 기술, Microsoft Research [1/2]
  11. 2010.10.12 [세미나 후기] Visual Studio Seminar #1 (2)
  12. 2010.10.12 [세미나 발표 자료] Visual Studio Seminar #1
  13. 2010.09.06 [세미나] Visual Studio Seminar #1 / 2010년 9월 28일
  14. 2010.09.06 [세미나 발표 자료] Visual Studio Camp #1
  15. 2010.09.02 [ALM] 7. Load Runner vs Visual Studio 2010 테스팅 비교 분석 - http://willstory.tistory.com/4 제공
  16. 2010.08.30 [세미나 후기] Visual Studio Camp #1
  17. 2010.08.16 심리학으로 풀어보는 개발자의 성향 [1] (2)
  18. 2010.08.16 심리학으로 풀어보는 개발자의 성향 [2] (1)
  19. 2010.08.16 [HowTo] TFS2010 의 Tfs_Analysis 웨어하우스 데이터베이스가 망가졌을 경우
  20. 2010.08.10 [ALM] 6. 테스트 계획
  21. 2010.08.04 [ALM] 5. 테스터(SDET) 의 역할 (1)
  22. 2010.07.28 [세미나] Visual Studio Camp #1
  23. 2010.07.19 .NET 스마트클라이언트 한계 극복 [2/2] (5)
  24. 2010.07.19 .NET 스마트클라이언트 한계 극복 [1/2] (1)
  25. 2010.07.07 ASP.NET 의 WebMatrix & Razor 신 기술 소개 (1)
  26. 2010.06.29 VS2008 과 VS2010 동시에 개발하기 : 테스트 프로젝트가 포함 될 경우 (3)
  27. 2010.06.24 VS2008 을 VS2010 에서 동시에 개발하기 (1)
  28. 2010.06.17 [HowTo] SCVMM 의 Install Virtual Guest Service 작업 중 2941 오류
  29. 2010.06.16 [HowTo] SharePoint 2010 Beta 깨끗하게 제거하기
  30. 2010.06.16 [HowTo] Team Foundation Server 의 로컬 매핑 캐시 제거하기

Visual Studio 2010 SP1 의 실버라이트 4 개발 환경

Visual Studio 2010 SP1은 실버라이트 4 개발자 툴 킷이 포함이 되어 바로 실버라이트 4 개발을 할 수 있습니다.

 

그림 4 실버라이트 프로젝트 템플릿 선택

 

기존의 실버라이트 프로젝트 템플릿을 선택하여 프로젝트를 생성하면, 실버라이트 버전을 선택하여 원하는 실버라이트 버전으로 개발을 할 수 있습니다.

그림 5 실버라이트 버전 선택

 

실버라이트 4는 많은 사용자의 요구 사항과 코어의 변화가 있습니다. 자세한 내용은 아래의 링크를 ㅋ통해 MSDN 을 참고하십시오

참고

Silverlight 4의 새로운 기능 http://msdn.microsoft.com/ko-kr/library/dd772166(v=vs.95).aspx

 

실버라이트 4 의 새로운 기능

  • 컨트롤
  • 브라우저 외부에서 실행
  • 미디어
  • 네트워킹
  • 인쇄
  • 사용자 인터페이스
  • XAML
  • 데이터
  • 응용 프로그램 모델
  • 코어
  • Silverlight 디자이너
  • Windows Forms 플랫폼 지원
  • 관련 항목
Posted by 땡초 POWERUMC

댓글을 달아 주세요

웹 브라우저 도움말이 데스크탑 응용 프로그램으로 변경

Visual Studio 2010 이전의 도움말 설명서(Help Documentation) 은 별도의 클라이언트 응용 프로그램으로 구동되었습니다. 하지만 Visual Studio 2010버전에서는 웹 브라우저를 통해 MSDN Online과 같은 화면으로 도움말 설명서가 로컬 웹 서버를 통해 구동이 되었습니다.

 

그림 1 Visual Studio 2008 도움말 설명서

 

그림 2 Visual Studio 2010 로컬 웹 도움말 설명서

 

두 가지 방식의 장단점은 다르겠지만, Visual Studio 2010 로컬 웹 도움말 설명서는 입력한 내용의 인덱스를 보여주지 않아 매우 불편했었습니다. 클래스 이름이나 네임스페이스 이름으로 검색할 때 AJAX 기술로 키워드의 인덱스를 보여주었더라면 그나마 좋았을 텐데 하고 불편함을 감수하기도 하였습니다.

 

Visual Studio 2010 SP1 에서는 로컬 웹이 구동되고 키워드가 인덱스 되지 않는 부분을 개선하여 기존의 로컬 도움말 설명서로 개선이 되었습니다.

 

그림 3 Visual Studio 2010 SP1 의 로컬 도움말 설명서

 

기존의 Visual Studio 2008 과 유사한 로컬 도움말 설명서 응용 프로그램으로 구동이 됩니다. 다만, 필자는 색인 창을 오른쪽에 도킹하여 쓰는데, 현재 Visual Studio 2010 SP1 에서는 도킹 기능은 제공하지 않습니다.

 

개선해야 할 점

기존의 웹 브라우저 방식보다 Help Viewer 1.1 이 낫긴 하지만, 여전히 사용자의 측면에서 불편하기는 마찬가지 입니다.

첫 번째, 여전히 로컬 웹 서버가 동작하여 도움말이 구동됩니다. 닫아버리고 싶은 왠지 모를 강박감…!

두 번째, 도움말의 폰트 크기가 제각각 입니다. 폰트도 작은데, 크게 키우면 너무 크고...
좌측은 Help Viewer 1.1, 우측은 MSDN 온라인 도움말.


세 번째, 샘플 코드 구조가 사정없이 깨집니다.
좌측, Help Viewer 1.1, 우측은 MSDN 온라인 도움말

 

네 번째, 개인적으로 인덱스 창을 오른쪽에 도킹하는데, 도킹 기능이 없네요^^;

다섯 번째, MSDN Documentation 2008 에서는 고유 URL 이 있는데, 지금은 도움말 에이전트의 URL 도 보여주지 않네요.
좌측은 MSDN Documentation 2008, 우측은 Help Viewer 1.1

 

그 밖에, 사용자 경험은 여러분께 맡기겠습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. kkamsean 2011.08.03 10:34 Address Modify/Delete Reply

    덕분에 Help Viewer 잘사용하고 있습니다.
    도움말-도움말설정관리 - 온라인 업데이트 확인 - 업데이트 하니 샘플 코드 구조가 깨지는현상은 해결 되네요

    • 땡초 2011.08.05 09:29 Address Modify/Delete

      와... 좋은 정보 감사합니다.^^

      그치만 저희 회사는 개발장비가 폐쇄망이라 업뎃이 불가능 ㅠㅠ

그간 저희 Visual Studio Korea 팀에서 2010년 6월 1일 REMIX10 무료 온라인 백서를 참석 전원에게 드린 적이 있었습니다.

http://vsts2010.net/338
Visual Studio 2010 최신 PDF 자료를 MSDN 에서 다운로드 받으세요

그리고 지난 2011년 4월 18일, 그 두 번째 온라인 무료 백서를 공개하게 되었습니다.

 

VISUAL STUDIO KOREA 팀의 온라인 백서 다운로드 사이트

http://msdn.microsoft.com/ko-kr/gg620748

Visual Studio 응용 프로그램 모델링 완전 정복 백서

엄준일 MVP (엔씨소프트) – 다운받기

 

"Visual Studio 응용 프로그램 모델링 완전 정복 백서" 개발자에서 뛰어난 개발자로 안내하는 효과적인 백서입니다. 최종 산출물인 동작하는 소스 코드를 위해, 모델링에 대한 배경과 방법을 개발자의 관점에서 설명합니다. 그리고 Visual Studio 2010 이용하여 개발자가 효과적으로 모델링을 있는 환경을 제시합니다.

개발자들이여, 이제는 "개발자는 코드로 말한다" 관념을 버리십시오.현대의 소프트웨어 개발에서는 언제까지 당신의 코드가 나오기까지 기다려주지 않습니다.선택과 집중의 개발 생태계에서 당신이 올바른 방향을 바라보고 발을 내딛는다는 것을 아무도 믿어주지 않습니다.

코드로 말하기 이전에 자신의 목적과 목표를 명확하게 시각화하여 말하는 것이야 말로 우리 시대가 원하는 뛰어난 개발자임이 확신합니다.

 

ASP.NET MVC - M, V 그리고 C 각방생활

박세식 (유니위스) - 다운받기

  

ASP.NET 가려운 곳을 긁어줄 대안의 프레임워크가 나왔으니 바로 ASP.NET MVC 프레임워크입니다. MVC 각각 담당하고 있는 일이 있습니다. 컨트롤러는 사용자 요청의 흐름을 제어하고 그에 따른 모델과 뷰를 선택하는 , 모델은 데이터와 유효성 검사, 비즈니스 로직을 담당하는 , 뷰는 컨트롤러에서 전달받은 데이터를 UI에서 처리하는 일을 합니다. 이렇게 모델, , 컨트롤러로 명확하게 분리된 구조가 여느 복잡한 어플리케이션도 구조적으로 쉽게 개발할 있도록 도와줍니다. 여기 백서를 통해 개발의 도움을 주는 M, V 그리고 C 각방생활을 소개합니다.

남자의 Visual Studio 2010 TDD(Test Driven Development)이야기

강보람 MVP (IT Flow 선임 컨설턴트), 박세식 (유니위스) - 다운받기

  

TDD(Test Driven Development), 테스트 주도 개발은 애자일한 개발을 지원하기 위한 하나의 실천적 도구입니다. 하지만, 단순히 세부적으로 어떻게 해야 되는 것인지를 묻는 'How'만으로는 TDD 제대로 이해할 수가 없습니다. 어째서 TDD 소개되었으며, TDD 통해서 어떤 장점을 얻을 있는지를 이야기 하는 'Why' 'What' 동반되어야 TDD 이해할 있는 기반을 마련하는 것이시죠. 여기 개발자가 TDD 대해 나눈 대화를 흥미롭게 재구성해 기록한 백서가 있습니다. 백서를 통해서 TDD 대한 'Why', 'What' 그리고 Visual Studio 2010 개발에 TDD 적용한 'How' 같이 얻으시기 바랍니다.

  

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 맨날맑음 2011.05.30 08:36 Address Modify/Delete Reply

    좋은 백서 감사합니다^.^

Visual Source Safe 마이그레이션 이전에

많은 분들이 예전에 Visual Source Safe(이하 VSS) 를 사용하시면서, 현재는 이 VSS가 많은 골치거리라고 느끼시는 분들이 많이 계실 겁니다. 사실 소스 제어를 떠나서 VSS는 안정성 면에서 굉장히 불리하죠. 가장 흔하게 겪는 안전성의 문제는 파일 시스템 기반의 소스 제어 데이터베이스가 꼬이는 겁니다. 왜 꼬이는지는 알고 싶지 않지만, 오래 쓰면 쓸수록 꼬입니다.

제가 겪었던 꼬이는 대표적인 문제가 체크인 상태가 다른 사람에겐 체크인 상태가 아니라는 것이죠. 아무리 다른 사람이 최신 버전을 가져와도 그 소스 코드는 예전에 체크인 되었던 소스 코드이고, 불가피하게 강제로 다시 체크인해야 하기도 합니다. 뭐, 여기까지는 정말 가벼운 일상적인 문제이죠? 더 심한 경우는 복구 불능..!

최근 들어서, VSS의 이런 문제 때문에 많이 고생하시는 분들이 다른 소스 제어 제품으로 갈아타려는 준비를 많이 하십니다.

   

왜 VSS에서 이런 문제가 발생하나…?

사실 어쩔 수 없습니다. 지금에야 VSS가 실컷 얻어터질 수 밖에 없지만, 사실 예전에도 뚜렷한 대안이 있었던 것도 아닙니다.

VSS아니면 CVS(Concurrent Versions System) 인데, 이 CVS도 그 기능 자체의 구현이 충실하지 않아 문제점을 얘기하자면 VSS나 크게 별반 다를 것이 없었습니다. 참고로 Wikipedia 의 과거 소스 제어 제품을 보면 다음과 같지요. 즉, 당시에 VSS 보다 더 뛰어난 제품도 찾기 힘들었고, 현대의 이슈인 안정성과 성능, 보안의 요소는 어디를 뒤져봐도 없었습니다. 즉, 당시에는 어떤 제품을 선택하든 똑같은 문제를 겪었을 테니까요.

   

다만, VSS 제품은 VSS 2005 버전까지 오면서 많은 부분에서 보완이 되었지만, 사용자의 요구사항에 매우 소극적으로 대응했던 점에서 아쉬움이 남습니다.

아래는 조만간 나오게 될 백서의 내용 중의 일부이니 참고하세요.

   

 

일반적으로 '형상관리'라는 의미의 소스 제어는 소스 제어(Source Control), 버전 컨트롤(Version Control), 소프트웨어 환경 관리(Software Configuration Management)라고 불립니다. 향후 소스제어는 서버/클라이언트 아키텍처로 변경되면서 개발 조직에서 소스를 공동으로 개발하고 공유할 수 있게 되었습니다.

초기 Microsoft 에서는 소스 제어를 위한 소프트웨어로 Visual SourceSafe(비주얼 소스세이프) 를 내놓게 되었습니다. Visual SourceSafe는 처음 One Tree Software 라고 불리는 회사에서 여러 운영체제를 지원하는 소스 제어 솔루션을 만들었는데, Microsoft 는 이를 1994년에 인수하여 즉시 Visual SourceSafe 3.1 버전을 내놓았습니다. 그 이후로, Visual SourceSafe 4.0, 5.0, 6.0, 2005 버전까지 지속적으로 지원을 하다가, Visual SourceSafe 2005버전을 마지막으로 이 제품의 업데이트는 이루어 지지 않고 있습니다.

Microsoft는 그 이후에 내부적으로 소스 제어 뿐만 아니라 버그 추적/품질 관리/제품 계획에 사용되는 솔루션을 만들었고, 그 이름은 "Product Studio" 라는 제품입니다. 이 제품은 Microsoft 내부적으로 사용하기 위한 제품이었고, 이 제품을 통해 노하우를 발전시켜 비즈니스 프로세스, 개발 등 전반적인 모든 개발 활동을 아우를 수 있는 "Visual Studio Team System, Team Foundation Server" 를 시장에 내놓게 되었습니다.

   

VSS to TFS2010 마이그레이션 전략

일단 아쉽지만 VSS와 같은 제품 군은 TFS(Team Foundation Server)에 100% 마이그레이션이 힘들 수 있습니다. 왜냐하면 VSS는 파일 시스템의 파일 단위 체크인 방식인데, TFS제품은 변경 집합(ChangeSet) 기반의 소스 제어 구조를 가집니다. 변경 집합은 변경이 일어난 묶음의 세트를 얘기하며, 이 변경 집합 덕분에 분기(Branch)/병합(Merge)/이력/관리가 매우 용이합니다. 덕분이 3-ways 방식의 병합이 매우 안정적으로 동작할 수 있고요.

VSS to TFS로 마이그레이션이 100% 보장할 수 없는 예를 들자면, 고객의 데이터베이스 스키마에 "주소"가 없는데, "주소" 컬럼이 생겼다고 주소를 가짜 데이터로 입력할 수 는 없는 노릇입니다. 게임을 예로 들면, 게임 시스템에 새로운 스킬이 생겼다고 종족/레벨/서버를 막론하고 모두가 이 스킬을 습득할 수 없는 것과 마찬가지입니다.

기존의 VSS는 레이블(Labeling) 방식의 이력 관리를 하였기 때문에, 이것을 변경 집합(ChangeSet) 기반으로 바꿀 수는 없습니다. 그래서 100% 마이그레이션이 힘든 한 가지 원인이기도 합니다. 그렇게 때문에 VSS to TFS로 마이그레이션을 결심하였다면, "퀑 대신 닭", "짜장면 대신 짬뽕","아이폰 대신 블랙베리" 라는 심정으로 100%를 기대하시면 오히려 독이 될 수 있답니다.^^

아래는 VSS to TFS 마이그레이션 전략을 메트릭스로 표현해 보았습니다. 물론, 이것 보다 더 많은 고려 사항이 있습니다만, 대략 아래의 정보에 답할 수 있다면 마이그레이션은 가능하다고 말씀 드리고 싶네요.

   

   

Team Foundation Server 및 .NET 플랫폼 기술 문의

언제든지 저희 Visual Studio Korea 공식 팀 블로그에 문의를 주시기 바랍니다. 저희가 모든 것을 가이드해 드릴 수는 없지만, 저희 팀의 다양한 분야의 기술 전문가들이 성의껏 여러분들을 도와드리고 있습니다. 저희 팀은 언제나 새로운 기술에 목말라있고, 먼저 고민하고 뼈저리고 값진 노하우를 경험한 컨설팅/개발/교육 및 강사 출신의 분들과 Microsoft MVP 활동을 하고 계신 많은 분들이 계십니다.

더불어, Microsoft 의 Social Forums 인 http://social.msdn.microsoft.com/Forums/ko-kr/categories/ 에 오시면 많은 전문가들의 생생한 고급 답변을 들을 수 있습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

 

여러분에게 안타까운 소식과 좋은 소식 가지를 전해 드리고자 합니다. 먼저 안타까운 소식을 하나 전해드리도록 하겠습니다.

 

안타까운 소식, Microsoft 내놓은 초기 소스 제어(Source Control) 제품인 VSS(Visual Source Safe) 지원이 중단 되었습니다. 들어가기 앞서, 일반적으로 '형상관리'라는 의미의 소스 제어는 소스 제어(Source Control), 버전 컨트롤(Version Control), 소프트웨어 환경 관리(Software Configuration Management)라고 불립니다. 향후 소스제어는 서버/클라이언트 아키텍처로 변경되면서 개발 조직에서 소스를 공동으로 개발하고 공유할 수 있게 되었습니다.

초기 Microsoft 에서는 소스 제어를 위한 소프트웨어로 Visual SourceSafe(비주얼 소스세이프) 내놓게 되었습니다. Visual SourceSafe 처음 One Tree Software 라고 불리는 회사에서 여러 운영체제를 지원하는 소스 제어 솔루션을 만들었는데, Microsoft 이를 1994년에 인수하여 즉시 Visual SourceSafe 3.1 버전을 내놓았습니다. 이후로, Visual SourceSafe 4.0, 5.0, 6.0, 2005 버전까지 지속적으로 지원을 하다가, Visual SourceSafe 2005버전을 마지막으로 제품의 업데이트는 이루어 지지 않고 있습니다.

 

하지만, Microsoft 이후에 내부적으로 소스 제어 뿐만 아니라 버그 추적/품질 관리/제품 계획에 사용되는 솔루션을 만들었고, 이름은 "Product Studio" 라는 제품입니다. 이 제품은 Microsoft 내부적으로 사용하기 위한 제품이었고, 이 제품을 통해 노하우를 발전시켜 비즈니스 프로세스, 개발 전반적인 모든 개발 활동을 아우를 있는 "Visual Studio Team System, Team Foundation Server" 를 시장에 내놓게 되었습니다.

 

즐거운 소식은, VSS 사용자를 위한 TFS2010 시리즈가 나왔다는 것입니다. 한국 MSDN 페이지에 대문짝만하게 걸려있는 문서가 바로 그것입니다.

 

 

 

 

 

이런 이음매가 없는 것을 연결시키는 하나가 영화에서 "To be continue…" 자막이죠… ^^ 마치 지금과 같은 VSS TFS2010 과의 이음매처럼 말입니다. Microsoft 에서 지원이 중단된 제품은 최대한 빨리 최신 버전으로 옮기는 것이 좋습니다. 유예기간과 지원에도 불구하고 버전을 쓴다는 것은 장애에 대해 이상 Microsoft 지원을 받지 않는다는 것과 마찬가지이고, 어떤 솔루션을 사용하든 이러한 절차는 대부분 통용되기 때문입니다. (물론 장애에 대해 그에 상응하는 비용을 지불하면 지원은 받을 있을 것입니다.)

 

 

그럼 간단히 "VSS사용자를 위한 TFS2010 시리즈" 목차를 살펴볼까요?

 

1. 일단 설치부터 해야 하겠지요?

1.        Visual Studio Team Foundation Server 2010 개요

2.1        Team Foundation Server 소개

2.2        Team Foundation Server 논리적 구조

2.3        Team Foundation Server 물리적 구조

2.        Visual Studio Team Foundation Server 2010 설치

3.1        설치 준비

3.1.1        Visual Studio Team Foundation Server 2010 설치에 필요한 필수 소프트웨어

3.1.2        Visual Studio Team Foundation Server 2010 필요한 최소 하드웨어 구성        

3.2        설치 전 필요 소프트웨어 구성

3.3        인터넷 정보 서비스(IIS 7.X) 설치하기

3.4        .NET Framework 3.5 설치하기

3.5        Visual Studio Team Foundation Server 2010 설치

3.6        Visual Studio Team Foundation Server 2010 Basic(기본) 구성

4.        사용자 계정 관리

4.1        Visual Studio Team Foundation Server 2010 보안

4.2        Visual Studio Team Foundation Server 2010 사용자 이해

4.3        Visual Studio Team Foundation Server 2010 역할

4.4        Visual Studio Team Foundation Server 2010 사용자 권한

4.5        Visual Studio Team Foundation Server 2010 사용자 추가하기        

4.5.1        Visual Studio Team Foundation Server 2010 사용자

4.5.2        팀 프로젝트 모음 사용자 추가

4.6        Visual Studio Team Foundation Server 2010 사용자 삭제하기

4.7        Windows 사용자 그룹 활용하기

4.7.1        Windows의 사용자를 그룹으로 연결하기

4.7.2        Visual Studio Team Foundation Server 2010 그룹 이용하기

 

 

2. 그럼 VSS TFS2010으로 마이그레이션도 해야하는데… 다음 목차를 보시죠.

1.        Visual Source Safe 개요        

1.1        Visual Source Safe 소개        

1.2        소스관리와 소스코드 형상관리

1.3        사용자 계정 및 보안

1.4        Visual Source Safe 사용과 개발환경 변화

2.        Visual Studio Team Foundation Server 2010 개요

2.1        Team Foundation Server 소개

3.        Visual Source Safe 마이그레이션 작업하기

3.1        Visual Source Safe 에서 Visual Studio Team Foundation Server 2010 이전

3.2        Visual Source Safe 사용자 정보 이전하기

3.3        자동화 마이그레이션 VSSConverter 사용

3.4        Visual Source Safe 정보 자동 이전하기

3.4        Visual Source Safe 소스 코드만 이전하기

3.4        Visual Source Safe 마이그레이션 주의사항과 문제 해결

 

 

3. 이제 적극적으로 활용해 봅시다.

1.        사용자 계정 관리

1.1        Visual Studio Team Foundation Server 2010 사용자 계정관리

1.2        Visual Studio Team Foundation Server 2010 사용자 이해

1.3        Visual Studio Team Foundation Server 2010 역할

1.4        Visual Studio Team Foundation Server 2010 사용자 권한

1.5        Visual Studio Team Foundation Server 2010 사용자 추가하기

1.5.1        Visual Studio Team Foundation Server 2010 사용자

1.5.2        팀 프로젝트 모음 사용자 추가

1.6        Visual Studio Team Foundation Server 2010 사용자 삭제하기

1.7        Windows 사용자 그룹 활용하기

1.7.1        Windows의 사용자를 그룹으로 연결하기

3.7.2        Visual Studio Team Foundation Server 2010 그룹 이용하기

2.        팀 프로젝트 구성

2.1        팀 프로젝트 소개

2.2        Visual Studio Team Foundation Server 2010 “팀 프로젝트 모음” 만들기

2.3        Visual Studio Team Foundation Server 2010 팀 프로젝트 만들기

2.4        Visual Studio Team Foundation Server 2010 팀 프로젝트 삭제하기

3.        작업 항목

3.1.        작업 항목 소개

3.1.1        작업 항목 이용하기

3.2.        Visual Studio Team Explorer 내 작업 항목

3.3.        Visual Studio Team Explorer 팀 작업 항목

3.4.        작업 항목 만들기

4.        소스 코드 관리

4.1.        소스 코드 관리소개

4.2.        소스 제어 탐색기 사용하기

4.3.        소스 코드 체크인 / 체크아웃

4.3.1        Visual Studio 에서 소스 코드 체크아웃

4.3.2        Visual Studio 에서 소스 코드 체크 인

4.4.        소스 코드 버전관리

4.5.        소스 코드 최신 버전 가져오기

4.6.        소스 코드 체크인과 작업 항목 연결

4.7.        소스 코드 체크인 정책

Posted by 땡초 POWERUMC

댓글을 달아 주세요

Team Foundation 2010 으로 업그레이드? 마이그레이션? 동기화?

많은 원성을 샀던 Team Foundation 2005 버전과 안정화된 Team Foundation 2008, 그리고 놀라우리만큼 강력해진 Team Foundation 2010… 약 5년 동안 Team Foundation Server 제품은 상당히 안정화되었고 테스트 분야에 상당히 공을 많이 들인 제품이 Team Foundation 2010 버전입니다. 더불어 함께 어울려야 하는 Microsoft SQL Server 2008 R2, SharePoint 2010, 그리고 함께 어울리면 간지나는 SCVMM 2008 R2(System Center Virtual Machine Manager), SCCM 2007 R3(System Center Configuration Manager) 등 모두 새로운 마이너버전으로 업그레이드 되었습니다.

특히 최근에 새롭게 Team Foundation 2010 을 도입하는 곳과, 이전에 쓰던 하위 버전에 대해서도 상위 버전으로 옮기기 위해 많은 문의를 주고 계십니다.

Team Foundation 2010 을 도입하거나 상위 버전으로 갈아타기 위해 업그레이드를 선택할지, 마이그레이션을 선택할지 현명한 선택을 위해 가이드해 드립니다.

   

제한 사항

본 포스팅에서 다루는 범위는 소스 제어에 국한된 범위입니다. SharePoint, MSSQL Reporting Services는 추가적인 업그레이드/마이그레이션 작업이 필요할 수 있습니다.

   

Team Foundation 2010 으로 업그레이드

가장 쉬운 방법이고, 데이터손실을 크게 걱정하지 않는 것이 업그레이드 입니다. 업그레이드는 TFS와 연동되는 SQL 서버의 데이터베이스 스키마가 일부 변경이 되면서, 이 범위의 데이터를 TFS2010 용 SQL 데이터베이스 스키마로 자동으로 변환하여 줍니다.

기존의 데이터베이스의 스키마를 변경하는 작업이므로 이전에 저장되었던 변경 집합(Changeset), 분기 및 병합(Branch and Merge) 의 정보를 그대로 안정하게 상위 버전으로 업그레이드할 수 있습니다.

이전에 사용하던 TFS AT(Application Tier) 는 없어도 무관하며, SQL Server의 데이터베이스만 있으면 업그레이드를 진행할 수 있습니다. 이 방법은 일전에 필자의 블로그에 포스팅으로 자세하게 가이드 하였으니 아래의 필자 포스팅을 참고하시기 바랍니다.

[HowTo] TFS 2005/2008 데이터베이스를 TFS 2010 으로 마이그레이션
http://blog.powerumc.kr/276

단, 업그레이드는 단어에서 의미하듯이 1회의 업그레이드 작업으로 상위 버전으로 업그레이드가 완료됩니다. 하위 버전에서 발생하는 추가적인 데이터의 업그레이드는 업그레이드 작업을 처음부터 다시 시작해야 한다는 의미이기도 합니다. 그렇기 때문에 전사적으로 TFS를 적용한 조직에서의 업그레이드는 일정시간의 TFS가 중지가 필요할 수 있습니다.

   

Team Foundation 2010 으로 마이그레이션

일단 골치 아픈 부분이 바로 마이그레이션 입니다. TFS 이전 버전의 AT(Application Tier)와 DT(Database Tier)가 모두 고스란히 존재해야 합니다. 양측의 TFS AT의 TFS API를 호출하여 서로간의 데이터를 마이그레이션하기 때문에 여차하면 일부 데이터 손실이 있을 수 도 있다고 합니다. (너무 겁먹지는 마시고요^^)

다만 이 마이그레이션은 One-Way 방식이기 때문에, TFS의 원본 서버(Source Server)와 대상 서버(Target Server)로 구분하여 진행하면 됩니다.

 글로벌 팀인 Visual Studio Ranger 에서 이 마이그레이션 작업을 쉽게 할 수 있는 도구를 CodePlex 사이트에 공개를 하였습니다. (http://tfsintegration.codeplex.com/) 이 TFS Integration 사이트에서 Download 로 이동하신 후에 설치 패키지를 설치하시면, 마이그레이션을 도와주는 도구를 설치하셔서 사용하시면 됩니다.

 마이그레이션은 TFS로 마이그레이션 이외의 File System, IBM Rational, SVN 제품간의 마이그레이션도 지원합니다.

   

   

   

Team Foundation 버전간의 동기화

Visual Studio Ranger 팀이 동기화까지 지원해 줄지는 몰랐습니다만, 참으로 기쁘기도 하네요. 동기화는 양측 TFS 서버간의 변경 이력이 생기면 이 데이터를 주기적으로(변경 즉시 동기화가 아님) 대상 TFS 서버와 동기화를 시도합니다.

 기존의 TFS<->TFS 간의 동기화도 지원하지만, File System, IBM Rational 제품, 그리고 SVN 간의 동기화도 지원합니다. 일전에 TFS<->TFS, TFS<->File System 간의 동기화는 잘 동작하는 것으로 확인을 하였습니다. (소스 제어 및 작업 항목간의 동기화)

   

참고

아래의 붉은 마킹을 한 다운로드 문서는 마이그레이션/동기화 작업을 하기 전에 반드시 필독하시기 바랍니다.

 

 

 

   

   

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

TDD vs 계약기반 테스트

단위 테스트를 어떻게 해야 잘 하나…?

단위 테스트를 어떻게 해야 잘 하는지는 사실 논란의 여지가 굉장히 많습니다. 왜냐하면

  • TDD를 해본 사람 vs 안해본 사람
  • TDD가 능숙한 사람 vs 능숙하지 않은 사람
  • 개발 툴에서 TDD를 제공하는 환경 vs 제공하지 않는 환경
  • 테스트 지식이 있는 사람 vs 없는 사람

어쨌든 목표는 동일합니다. 작성된 코드에 대한 테스트를 수행하는 것이죠. 일반적으로 테스트의 목표에 따라 테스트 방법이 달라질 수 있지만, 흔히 단위 테스트는 기능 범위에 한하여 테스트 코드를 작성하는 방법입니다. 어떻게 코드가 변경이 되든, 어떤 데이터소스 이든지 간에 성공해야 할 테스트는 반드시 성공하고, 실패해야 할 테스트는 반드시 실패해야만 기능이 올바르게 동작한다는 것을 최소한으로 보장할 수 있다는 것입니다.    

무엇이 단위 테스트를 어렵게 하나?

단위 테스트는 어떻게든 하는 것은 매우 쉽지만, 어떻게 해야 잘 할 수 있고, 시간을 단축하는 방법도 매우 중요합니다. 맹목적인 단위 테스트는 테스트의 목표를 상실하게 만들 수 있고, 의미 없는 더미(Dummy) 테스트 코드가 되기가 매우 쉽습니다. 그리고 더미(Dummy) 단위 테스트 코드를 양산하는 방법도 매우 쉽습니다.

  • 테스트에 대한 지식이 없는 경우
  • 처음부터 목적/목표가 없는 테스트 코드 작성
  • 테스트 방향이 잘못 설정된 경우
  • 단위 테스트 관리 방안이 없는 경우
  • 처음부터 잘못된 디자인이나 구현 도중 발생하는 디자인 결함

그리고 일반적으로 인간의 생각의 흐름은 매우 순차적입니다. 복잡한 생각 등을 결국은 순차적으로 나열을 하게 되지요. 그 대표적인 것이 자신의 머리 속에만 존재하던 사건을 도식화하는 것이 바로 육하원칙(5W1H) 입니다. 이런 육하원칙과 같이 테스트 대상을 명확하게 테스트 코드로 구현하는 것도 매우 중요한 부분입니다.

  • Who - 누가
  • When - 언제
  • Where - 어디서
  • What - 무엇을
  • Why - 왜
  • How - 어떻게

그리고 마지막으로 단위 테스트를 하는 것 중 "무엇을 테스트해야 하나?" 입니다. 테스트 대상을 어떻게 쪼개어 테스트를 해야 가장 생산적이고, 중복되지 않는 테스트를 작성하는가는 즉시 테스트의 관리 비용과도 영향을 미치는 중요한 부분이기도 합니다. 즉, 테스트 코드가 중복이 되면, 관리되는 테스트 코드의 양이 늘어나고, 그 테스트 결과가 반드시 성공/실패해야 함에도 그렇지 않게 될 수 도 있습니다.

흔히 열광하는 TDD(Test-Driven Development) 도 마찬가지입니다. 이론적으로 그 용이성은 필자도 인정하지만, 사실은 매우 실용적이지도 않고, 효과적이지도 않습니다. 더불어 위의 나열한 테스트 지식, 목표, 테스트 방향, 관리 방안, 디자인 측면에서도 명확하지 않는다면 쥐약과도 다름이 없습니다. 즉, 테스트라는 것에 집중되어 그 목표, 방향을 제시하기 힘들며, 객체지향적인 코드를 만들기도 어려우며, 실제로 지저분한 코드를 만들기 매우 쉬운 방법이기도 합니다.

즉, 인간의 생각은 매우 복잡한데, 순차적인 도식화 작업을 하지 않은 채로 순차화를 시키려 하니 테스트 코드의 품질과 소스 코드의 품질은 기대 이하가 대부분이었습니다.    

계약 기반의 테스트

최근에는 계약 기반(Contract-Based)의 아키텍처 또는 패턴의 개발이 매우 활발합니다. 코드적으로 추상화를 통해 매우 명확하며, 이런 추상화된 모형을 통해 완벽하게 모형의 인터페이스를 통해 시그너처를 구현해 나가는 방식입니다. 정확하게 계약 기반의 개발도 아니며, TDD, BDD(Behavior-Driven Development)도 아닌 그 중간적인 형태를 취하는 방법입니다.

계약 기반(Contract-Based)의 개발 방식은 이전에 자주 세미나에 언급을 하였습니다. 자동차보험의 경우 계약서와 아래와 같은 계약 명세가 존재 합니다. 이 명세가 바로 인터페이스의 모형과 시그너처에 해당한다고 봐도 무방합니다.

아래는 자동차보험의 계약 명세에 대한 상세적인 약관입니다. 이 약관은 계약 명세에 대해 자세하게 약관을 명시하고 있으며, 이것을 인터페이스의 구현이라고 보셔도 무방합니다.

즉, 인터페이스의 모형과 시그너처는 단순히 객체지향적인 인터페이스를 넘어, 계약(Contract)적인 관점의 신뢰를 이루기도 합니다. 바로 그 계약을 잘 설명했던 TechDays 2010 Spring 의 슬라이드를 몇 장 재활용해보면^^

 

계약 기반의 개발과 테스트의 장점

물론 이 계약 기반의 개발과 테스트의 장점이 없다면, 필자 또한 이렇게 침을 튀기며 얘기하지는 않을 겁니다. 이전에 얘기했듯이 테스트는 하면 할수록 어려워지고, 또한 관리하기도 무척 버거워집니다. 그 과정에 의지와 다르게 테스트의 목적과 목표가 소실되고, 테스트의 방향성을 상실하는 경우가 허다합니다. 그리고 잘못된 초기 디자인이 특히 돌이키기 힘든 어려움이 될 수 있습니다.

사실 어떤 기가 막힌 테스트 기법도 명세(인터페이스의 모형, 시그너처)가 변경이 되면 많은 노가다(?)를 감수해야 할 수 밖에 없습니다. 바로 리팩토링(Refactoring) 작업인데, 좀 더 나은 코드/디자인을 위한 것이긴 하지만, 너무 많은 리소스나 비용이 필요하다면 이 리팩토링 작업이 전혀 즐겁지 않는 작업이 되기도 합니다.

하지만 절대 변하지 않는 진리 중 하나는, 쪼개진 것을 합치는 것은 쉬워도, 합쳐 놓은 것을 쪼개기는 매우 어렵기 때문입니다.

각설하고, 계약 기반 테스트가 TDD보다 좀 더 효과적인 이유는

  • 허술하게 하는 TDD는 테스트 목적/목표가 불명확한데 테스트 코드를 먼저 짠다?
  • 보험의 약관을 가지고 명세를 만들어 간다? 무지 어렵겠는걸…?
  • 디자인 목표가 없는 추상화가 과연 올바른 추상화인가…?
  • 코드는 생각을 먼저 하고 짜는 것이 방어적/효과적/객체지향적인데, 타이핑 먼저…?

위의 나열한 몇 가지 이유만으로, 필자는 TDD를 싫어하는 이유이기도 하지만 특히 싫은 이유는 리팩토링부터 시작하는 코드는 죽어라 리팩토링으로 끝나기 마련입니다. (리팩토링을 반드시 그 자체의 의미에 두고 하는 얘기는 아닙니다) 뒤돌아서면 내심 찜찜한 기분도 들고, 좀 더 완벽함에 가깝게 디자인하려 하지 않은 것이 어찌 완벽함에 가까워지겠습니까.

물론 어떤 테스트 기법이든지 "경우에 따라 잘 맞을 때가 있고 안맞을 때"가 있습니다. 다만, 이런 TDD 기법 하나로 찬양하다시피 어떠한 올바른 방향을 제시하지 않는 것은 매우 위험한 발상이기도 합니다. 필자는 TDD 의 울타리에서 벗어나야만 올바른 TDD 를 할 수 있다고 생각을 하며 이만^^

Posted by 땡초 POWERUMC

댓글을 달아 주세요

테스트 가상화...

몇 해 전부터 클라우드(Cloud) 붐이 일어나면서 굉장히 다양한 클라우드 인프라와 서비스가 여러 벤더에 의해 발전해 왔습니다. 그 중 Microsoft 는 가상화 기술을 기반으로 플랫폼, 인프라 서비스 등이 결합하여 Azure 라는 훌륭한 클라우드 서비스 환경을 구축하였습니다. 이런 클라우드 서비스의 가능성은 가장 최하위 기반이 되는 가상화 기술이 바로 그것입니다.

필자는 처음에는 클라우드라는 것이 도대체 GREEN IT 를 마케팅 용어로 벗삼고, TOC 절감과 관리적인 요소들에 그저 불편한 심기를 내비쳤습니다. 왜냐하면 늘 그래왔듯이 거품이 빠지고, 걸음마 수준의 기술과 마케팅으로 수 많은 것들이 기억 속에서 사라진 것들이 더 많기 때문입니다.

다시 본론으로 돌아와서, 테스트 가상화란…? 가상화 기술은 여러 가지 기술이나 트랜드와 접목시킬 수 있습니다. 그 중 하나가 바로 테스트 가상화 기술입니다. 현대의 소프트웨어는 다양한 방면에서 애자일(Agility) 하길 원합니다. 개발 팀은 당연하고 소프트웨어를 사용하는 사용자도 매우 능동적이며 한층 눈높이가 높아졌습니다. 즉, 기존의 개발 방식이 변하듯이 기존의 테스트 방식도 이제 진화해야 할 시기입니다. 그리고 이것을 가능하게 해 주는 것이 바로 테스트 가상화 입니다.

------------------------------------- 절취선 ^^ ------------------------------------

서두는 이쯤 마무리 하고(^^), 아래의 자료는 Microsoft 고객사를 대상으로 하는 Visual Studio Ultimate 맴버쉽 세미나에서 발표할 예정이었던 프레젠테이션 자료입니다. 2010년 12월 22일 예정이었던 세미나를 위해 급하게 만들었던 프레젠테이션인데 일정이 변경되면서 먼저 공유해 드리겠습니다. (나중에 더 알차게 만들어 드리겠습니다 ^___^;)

그림만 있어서 내용은 이해하는데 충분히 설명을 드릴 수 없습니다만, 다음 기회에 더 좋은 내용으로 정보를 공유하도록 하겠습니다.

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. dotnetpower 2010.12.22 09:13 Address Modify/Delete Reply

    좋은 자료 잘 보았습니다. 22일이면 오늘이군요 세미나 무사히 잘 하시기 바랍니다. 좋은 하루 되세요 :)

새로운 시대, 새로운 기술, 접근성을 높인 기술, Microsoft Research!!

이전 포스트에서 잠깐 알아보았듯이, Microsoft Research 프로젝트는 꾸준히 그 개수가 늘어나고 있으며, 지금 여러분이 사용하는 기술과 크게 동떨어진 기술이 아니라는 것을 알았습니다. .NET을 감싸주는 탄탄한 인프라가 그것을 증명해 주고 있으며, 이제는 Microsoft Research 에서 실험적이고 미래지향적인 기술을 꾸준히 연구를 하고 있습니다.

오늘 소개해 드릴 기술도 마찬가지로, 없어도 개발하는데 지장은 없는 그런 그저 그런 기술이 될 수 도 있습니다. 하지만, 기술자로서 기술을 떠나서 미래의 트랜드를 짐작해본다는 의의로 보시면 좋을 것 같습니다.^^

   

i2i - 3D Visual Communication

http://research.microsoft.com/en-us/projects/i2i/

요즘은 3D 가 대세죠. 영화에서부터 게임, TV 까지 입체영상으로 감상하는 3D 기술이 무척 빠르게 발달해왔던 것 같습니다. 하드웨어적으로 3D를 지원하지 않아도, 소프트웨어적으로 3D 로 변환하는 인코더도 나와있는 상태이며, 이런 기술에 Microsoft Research 가 꾸준히 기술을 개발하고 있습니다.

   

이런 3D 기술은 비디오 촬영을 3D 카메라로 촬영하여 하는 방식이 있고, 소프트웨어로 실시간 3D 로 랜더링 또는 변환하는 기술이 있습니다.

현재 "i2i - 3D Visual Communication" 는 이런 기술을 사용하기 위한 SDK(Software Development Kit) 을 이미 Microsoft Research 에서 내놓았습니다. 완성된 것은 아닌 듯 한데, 실험 정신이 강하신 분들은 미리 체험을 해 보셔도 좋을 겁니다.

   

Infer.NET

http://research.microsoft.com/en-us/projects/infernet/

베이시안 확률(Bayesian probability)은 통해 추론과 확률을 통해 해석하는 연구 분야입니다. 저도 이 분야에 대해서는 잘 알지는 못합니다만, 아래의 링크에서 이미 어느 정도의 개발 킷을 공개하고 있습니다. 관심 있는 분들은 사용해 보시고 트랙백 부탁 드립니다. ^^

http://research.microsoft.com/en-us/um/cambridge/projects/infernet/

   

   

Microsoft Visualization Language - The Vedea Project

http://research.microsoft.com/en-us/projects/vedea/

시각화 언어라는 새로운 실험적인 프로젝트입니다. Computational Science Laboratory 에서 이와 유사한 분야에 대해 연구하는 활동이 활발해 보입니다. 이 프로젝트는 더 나아가 자연과학, 생물학 등 다양한 분야까지 연구를 진행하는 프로젝트인 것 같습니다.

   

Moles - Isolation framework for .NET

http://research.microsoft.com/en-us/projects/moles/

Moles 는 일명 Mock-up 과 같은 가상의 객체를 사용하여 테스팅을 하거나 객체를 만드는 Dynamic Runtime 또는 Dynamic Proxy 등의 기술과 접목됩니다. 이 부분에서 예전에 포스팅을 한 내용을 참고하시기 바랍니다.

[Testing] Moq.NET (T/B Driven Development)
[Testing] BDD (Behavior-Driven Development–행위 주도 개발)
[Testing] TDD (Test-Driven Development-테스트 주도 개발)

이 기법들을 이용하면 완벽한 TDD(Test Driven Development) 가 가능해 집니다. 설계가, 구현이.. 안된 객체를 대상으로 계약된 인터페이스를 이용하여 Mock Object 를 생성하는 기법들입니다. Lightweight Framework이라고 설명하긴 하지만, Pex 등과 궁합이 잘 맞는 프레임워크이기도 합니다.

   

Object Class Recognition

http://research.microsoft.com/en-us/projects/ObjectClassRecognition/

이 기술은 이미지 처리 기술로, 물체를 인식하는 기술입니다. 헐~~ 왜 헐~이냐고요? 아마도 이 분야에 바로 기술을 적용하려면 Microsoft 역사상 선도 기술 업체를 인수해 버렸지만, 이번 기술은 그 기반부터 연구를 진행하는 프로젝트네요. 아마도 HD Viewer 등과 더불어 이미지 처리 기술의 노하우를 쌓으려는 작정인가 봅니다.

물론 이런 비슷한 기술은 이미 선도 업체에서 구현하였습니다만, Microsoft Research 에서 직접 연구하는 것은 참으로 반갑네요. 아마도 Microsoft 도 인터넷 서비스에 뛰어든 만큼 새로운 서비스와 모바일과 결합된 서비스가 나오리라 생각이 됩니다.

   

Qex - Symbolic SQL Query Exploration

http://research.microsoft.com/en-us/projects/qex/

Qex 는 Pex 의 SQL Query 버전인가 봅니다. Pex 는 코드 구분을 분석해서 자동적으로 테스트 파라미터 등을 선정하여 테스트를 진행하는데, Qex 는 그 대상이 SQL Query 인 것 같습니다. 정확한 산출물은 없지만, 이미 공개된 다른 파생 프로젝트에서 문서를 보시면 이해하시는데 도움이 될 것 같습니다.

   

Publications

   

Microsoft Research 를 둘러보세요^^

http://research.microsoft.com/en-us/default.aspx

Microsoft Research 에는 여러분의 상상력과 지적 호기심을 자극할 만한 많은 프로젝트가 진행 중입니다. 이미지 처리, Embedded, 과학, 공학 등등…

그리고 좋은 내용이 있으면 함께 공유 부탁 드립니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

Microsoft Research 프로젝트로 알아보는 새로운 세대의 시작

Microsoft Research 프로젝트는 Microsoft 에서 진행하는 오픈된 기술과 연구를 하는 R&D 조직으로, 새로운 비즈니스와 기술을 결합하는 프로젝트입니다. 최근 들어 Microsoft Research 사이트의 프로젝트는 작년과 비교해 엄청나게 늘어났습니다. 작년까지만 해도 불과 10~30개의 오픈된 프로젝트가 현재 수백 개의 프로젝트로 늘어난 것이 굉장히 놀랍니다. 그만큼 기술의 트랜드가 빠르게 변한다는 반증이 되겠지요.

Microsoft Research 프로젝트를 열람해 보는 것은 매우 중요합니다. 왜냐하면 당장 2~3년 내에 현실화되는 기술들도 있으며, 현재의 기술이 작년의 Microsoft Research 프로젝트와 통합된 것이 많기 때문이죠. 앞으로 나와는 상관 없는 것들도 있지만, 간접적으로 영향권에 들게 될거라고 생각합니다. 과연 스마트 폰이 어느샌가 내 호주머니 속에 들어가게 될지 모르는 것 처럼 말이죠^^

그럼 Microsoft Research 프로젝트에서 진행하고 있는 재미있는 프로젝트를 소개해 드립니다. 말씀 드렸다시피 이 프로젝트들은 언제 사라질지 모르는 것들이지만, 가치가 있는 것들은 모조리 비즈니스/웹/개발 영역에 접목이 될 수 있습니다.

   

Microsoft Research 진행 프로젝트 소개

A programming language for composable DNA circuits

http://research.microsoft.com/en-us/projects/dna/

이 프로젝트는 프로그래밍 언어의 핵심 로직을 시각화(Visualization)해 주는 프로젝트입니다. 가령 아래와 같은 로직이 있다고 치면, 참 답답하죠. 왜냐하면 제가 무슨 뜻인지 모르니까요^^

directive sample 20000.0 1000

directive plot <kkks t^ kkksr>; <kkppl t^ kkpp x^>; <kpp t^ kppr>;

<kkk t^ kkkr>; <kkl t^ kk x^>; <k t^ kr>; <kkpl t^ kkp x^>; <kp t^ kpr>

directive scale 10.0

def bind = 0.0003 (* /nM/s *)

def unbind = 0.1126 (* /s *)

def Init = 50

def Low = 1

def Excess = 100

   

new x@ bind,unbind

new t@ bind,unbind

   

def SpeciesL(N,al,a) = N * <al t^ a x^>

def SpeciesR(N,a,ar) = N * <a t^ ar>

def BinaryLRxLR(N,al,a,b,br,cl,c,d,dr) = (* A + B ->{N} C + D *)

new i

( constant N * t^*:[a x^ b]<i cl t^ i t^ dr>:t^*

| constant N * Excess * x^*:[b i]:[cl t^]<c x^>:[i]:<d>[t^ dr]

)

   

new e1l new e1 new kkk new kkkr new kkl new kk new k new kr

new e2l new e2 new kkpase new kkpaser new kpasel new kpase

new kkks new kkksr new kkpl new kkp new kkppl new kkpp

new kp new kpr new kpp new kppr

   

( SpeciesL(1,e1l,e1) (* E1 *)

| SpeciesR(10,kkk,kkkr) (* 10 KKK *)

| SpeciesL(100,kkl,kk) (* 100 KK *)

| SpeciesR(100,k,kr) (* 100 K *)

| SpeciesL(1,e2l,e2) (* E2 *)

| SpeciesR(1,kkpase,kkpaser) (* KKPase *)

| SpeciesL(1,kpasel,kpase) (* KPase *)

| BinaryLRxLR(Init,e1l,e1,kkk,kkkr,e1l,e1,kkks,kkksr) (* E1 + KKK ->{r} E1 + KKKs *)

| BinaryLRxLR(Low,e2l,e2,kkks,kkksr,e2l,e2,kkk,kkkr) (* E2 + KKKs ->{r} E2 + KKK *)

| BinaryLRxLR(Init,kkl,kk,kkks,kkksr,kkpl,kkp,kkks,kkksr) (* KK + KKKs ->{r} KKP + KKKs *)

| BinaryLRxLR(Init,kkpl,kkp,kkks,kkksr,kkppl,kkpp,kkks,kkksr) (* KKP + KKKs ->{r} KKPP + KKKs *)

| BinaryLRxLR(Low,kkppl,kkpp,kkpase,kkpaser,kkpl,kkp,kkpase,kkpaser) (* KKPP + KKPase ->{r} KKP + KKPase *)

| BinaryLRxLR(Low,kkpl,kkp,kkpase,kkpaser,kkl,kk,kkpase,kkpaser) (* KKP + KKPase ->{r} KK + KKPase *)

| BinaryLRxLR(Init,kkppl,kkpp,k,kr,kkppl,kkpp,kp,kpr) (* KKPP + K ->{r} KKPP + KP *)

| BinaryLRxLR(Init,kkppl,kkpp,kp,kpr,kkppl,kkpp,kpp,kppr) (* KKPP + KP ->{r} KKPP + KPP *)

| BinaryLRxLR(Low,kpasel,kpase,kpp,kppr,kpasel,kpase,kp,kpr) (* KPase + KPP ->{r} KPase + KP *)

| BinaryLRxLR(Low,kpasel,kpase,kp,kpr,kpasel,kpase,k,kr) (* KPase + KP ->{r} KPase + K *)

)

어찌되었건 이런 코드는 다양한 방법으로 시각화를 해줍니다. 아래는 제가 시뮬레이션해 보니 이런 결과가 나오네요.

중요한 것은 이런 형태의 시각화(Visualization)은 지속적으로 발전하고 있습니다. 모델링(Modeling) 과 DSL(Domain Specifically Language) 의 중요성과 함께 지속적으로 발전하게 될 테니까요.

이 데모는 실버라이트로 작성되어 웹에서 직접 테스트해 보실 수 있습니다. http://lepton.research.microsoft.com/webdna/

   

   

Ajax View

http://research.microsoft.com/en-us/projects/ajaxview/

AJAX 기술로 직격타를 받고 성장한 것이 바로 Web 2.0 입니다. 그리고 Web 2.0을 넘어 Web 3.0이 언급이 되었고, 더 나아가 SNS(소셜 네트워크 서비스)로 발전한 가운데, 가장 영향력을 미친 기술이 AJAX 입니다. 기술적으로 트래픽의 라운드 트립을 줄이고, 분산 아키텍처에 지대한 영향을 미쳤으며, 더 나아가 브라우징(Browsing) 사용성을 극대화한 기술입니다.

하지만 사실상, AJAX 기술은 불필요한 라운드 트립을 증가시킬 수 있는 가장 적절한 수단이기 때문에 잘 사용하는 것이 어려운 기술이기도 합니다. Ajax(Asynchronous JavaScript and XML) 는 순수한 자바스크립트 기술로써 많은 부분을 클라이언트에 의존하지만 자바스크립트와 더불어 HTML CodeDom, XML, DHTML 까지 확장되어 그 영역이 상당하게 복합된 기술이라고 보셔도 됩니다.

   

그렇다면 과연 AJAX 를 어떻게 잘 쓸 것인가에 대한 고민을 이 Ajax View 프로젝트가 도움을 줄 것 같습니다. 이 기술을 중심으로 파생되어 AJAX Performance Profiling, Monitoring 기술의 기반이 되는 것 같습니다. 자세한 내용은 위의 사이트 링크를 참고하세요.

   

Automated Test Generation (ATG)

일찍이 Microsoft 는 1990년대 이후부터 테스팅 기술에 대한 연구를 꾸준히 해온 정통 소프트웨어 기업입니다. 코드 레벨의 테스트는 물론이며, Windows 95 시절에 지원되기 시작한 Plug-and-Plug(하드웨어를 꽂으면 인식하는 기술) 등 상상하지도 못했던 많은 기능을 자동화 테스팅한 기업이기도 합니다. 지금 우리 세대에서 맛보고 있는 테스팅 기술은 Microsoft 의 실제 내부의 기술과는 매우 격차가 있지요. (인정합니다.^^;)

처음 공식적으로 나온 White Box Automation Test 도구인 PEX 가 Visual Studio 2008 시절부터 나오긴 하였지만, 완성된 기술은 아니며 계속 발전하는 기술입니다. PEX 와 관련하여 온라인 세미나를 찍은 것이 있는데 못찾겠군요.;; 대신 아래의 테스팅과 관련된 내용을 참고 하세요.

[ALM-Test] 6. Load Runner vs Visual Studio 2010 테스팅 비교 분석 - http://willstory.tistory.com/4 제공
[ALM-Test] 5. 테스트 계획
[ALM-Test] 4. 테스터(SDET) 의 역할
[ALM-Test] 3. 테스터에 대한 오해와 진실
[ALM-Test] 2. 왜 단위 테스트를 해야 하는가? [2]
[ALM-Test] 1. 왜 단위 테스트를 해야 하는가? [1]
[Testing] Moq.NET (T/B Driven Development)
[Testing] BDD (Behavior-Driven Development–행위 주도 개발)
[Testing] TDD (Test-Driven Development-테스트 주도 개발)

아무튼 이런 테스팅을 위해서 Dynamic Proxy 기술과 Dynamic MSIL Injection 같은 기술이 필요한데, 이미 이런 부류의 닷넷 기술이 존재하긴 합니다. 그 중에 대표적인 것이 Microsoft.CCI 와 Code Contract, Castle Dynamic Proxy, Mono Cecil, Moles 등등등…

하지만 이번 이 프로젝트는 이 기반 기술 들을 통합하려는 의지를 보이는 것 같습니다. 개인적으로 굉장히 기대를 하고 있는 프로젝트이기도 합니다.

   

Code Contracts

http://research.microsoft.com/en-us/projects/contracts/

Code Contracts 는 이미 유명한 기술입니다. 초기에 Microsoft Research 프로젝트로 진행 중이다가 Visual Studio 2008 시절에 릴리즈가 되었으며, .NET Framework 4.0 와 Visual Studio 2010 에는 아예 탑재 시켜버렸습니다. Code Contract 를 직역하면 코드 계약(Code Contract) 인데, 코드간의 명확한 명세를 코드 레벨에서 작성하는 것입니다. 이것도 예전에 온라인 세미나를 했었는데 못찾겠군요;;

명확한 코드 계약이 왜 필요하냐…? 라고 물으신다면 당시 세미나에서 예시를 든 것이, "당신이 회사를 다닌다면 회사와 계약을 합니다. 계약서에는 연봉 정보도 있고, 근태 규칙도 있고 여러 가지가 있습니다..." 마찬가지로 내가 만든 코드를 누군가 써야 할 때 바로 그 명세가 되는 것이 Code Contract 입니다.

이 기술로 파생될 수 있는 기술은 상당히 많습니다. 명확하게 코드를 계약하게 되면 테스트에 굉장히 용이하며, 더 나아가 자동화 테스트(PEX 와 같은)에서 훨씬 여유로워 집니다. 그리고 정적 분석(Static Analytics) 기술과 접목하여 잠재적인 코드의 계약 관계를 파악하여 미리 경고나 오류를 발생해 줄 수 도 있고요.

하지만 저의 경우는 그리 톡톡히 효과를 보지는 못했습니다. 왜냐하면 명확한 계약은 1:1 계약에서 효과가 있지만, 1:N, N:N 간의 계약에서는 그 계약 조건이 명확해 질 수가 없습니다. 현재 나온 PEX 기술과 Code Contract 를 조합하여 계약을 파생시키는 기술적인 부분이 부족하며, 계약의 제약 조건 등 아직은 적극적으로 사용하기에는 부족해 보입니다.

하지만 이 기술을 근간으로 하여 더 효과적인 많은 방법들이 위의 Automated Test Generation (ATG) 프로젝트 등으로 활발히 연구 중이며, 앞으로도 지속적으로 관심을 가질 기술은 분명합니다.

   

Composable Virtual Earth

http://research.microsoft.com/en-us/projects/cve/

제가 설명드릴 만큼 깊이 이해를 못하고 있기 때문에, 참고하세요^^; 중요한 것은 이미지 프로세싱 등의 기술로 효과적으로 운용을 하고자 하는 것 같습니다.

   

DryadLINQ

http://research.microsoft.com/en-us/projects/dryadlinq/

이 프로젝트는 C#의 LINQ+Parallel 기술을 접목하여 분산된 데이터의 접근성을 극대화한 기술입니다. 이미 잘 알고 있는 LINQ 와 .NET 4.0부터 제공되는 TPL(Task Parallel Library)를 이용하여 단순한 분산 데이터에 접근하는 방법입니다. 기존의 LINQ to SQL, Entity Framework 과 같이 단일 데이터 소스가 아닌 클러스터링 된 분산 데이터에 대상이 됩니다.

이 프로젝트는 기존에 존재하는 기술을 접목하여 새로운 기술의 탄생의 근원이기도 합니다. 하지만 생각해보면 분산된, 클러스터링된 데이터를 왜 DryadLINQ 를 써야 할까. 그만큼 대규모의 데이터면 '데이터베이스 관리자를 따로 둘텐데' 말이죠.

제 짧은 소견으로는 분명히 이 기술은 Microsoft Cloud 기술인 Azure 에 접목될 가능성이 농후합니다. 즉, Azure 기반의 클라우드 기술을 엔터프라이즈(Enterprise) 급으로 끌어올릴 수 있는 전략적인 기술이기도 합니다. 이런 부분에서 아직 Azure 는 완성된 기술은 아닙니다. 계속 발전하는 기술이지…

   

Doloto

http://research.microsoft.com/en-us/projects/doloto/

이 프로젝트는 정말인지 기대가 됩니다. 아까 말씀 드린 'Ajax View' 프로젝트와 연관이 있어 보이지만, 이 프로젝트는 나름대로 효과를 톡톡히 보여줄 것 같습니다.

문제는 Web 2.0 은 말씀 드린대로 AJAX 기술과 떨어질 수 없는 관계이기도 합니다. 그런데 데이터 처리를 서버&클라이언트로 분산하면서 결국은 서버를 거치게 되고, 원치않던 라운드 트립은 증가하게 되고, 결국은 사용자의 사용성(광범위한…)은 저하될 수 있습니다. 뭐가 문제일까요? AJAX 가 문제일까, Web 2.0 이 문제일까, 코드가 문제일까, 시스템이 문제일까….

Doloto 는 과분하게도 이런 문제를 큰 고민 없이 해결해 줍니다. 아래는 그래프는 Doloto 를 적용하면 대략 50%에 근사하게 성능이 개선되는 수치입니다. 성능을 개선하기 위해 특별히 코드를 변경할 필요도 없다고 합니다. 그렇다면 연관된 기술은 서버 코드/클라이언트 코드 분석 기술 이외에 캐싱(Caching) 일 텐데…

일단 기대가 됩니다.

   

ExtendedReflection - Dynamic Analysis Framework for .NET

http://research.microsoft.com/en-us/projects/extendedreflection/

이 기술은 'Automated Test Generation (ATG)' 과 없지 않아 연관이 될 수 있을 것 같습니다. 여기에서는 분석 도구라고 설명하지만, 이런 Low-Level의 구현이 가장 잘 되어 있는 프레임워크는 Mono.Cecil입니다. 그러고 보면 약간은 중복성이 있어 보이는 프로젝트이기도 합니다.

적어도 Microsoft.CCI 는 그렇다쳐도 Microsoft.Unity.ObjectBuilder, Castle.DynamicProxy와 Mono.Cecil은 .NET 오픈 소스 중에 가장 대표적인 Dynamic Proxy 및 MSIL 기술인데, 어찌될지 그냥 지켜보고 있습니다.

단순히 기존 존재하는 오픈 소스 대체용도인지, 다양한 기술을 접목하고자 하는 진정한 프레임워크 기반 기술인지는 두고 볼 일입니다.

   

F#

http://research.microsoft.com/en-us/projects/fsharpproj/

깜놀하셨죠? 바로 F# 도 Microsoft Research 에서 태생한 언어입니다. 그냥 그렇다구요^^

   

Graphical tools for text analysis

특별히 아래의 그림만으로 이해하시리라 믿고, 패스!

   

HD View

예전에 Silverlight 의 딥줌(DeepZoom) 을 기억하십니까? 저는 사실 결과물에 대해 다른 것은 없지만, 뭔가 이미지 프로세싱 측면에서 다른 접근 방식을 가지고 가는 것 같습니다. 워낙 자료도 적어서 뭐라고 설명 드리기는 힘들 것 같아요.

다만, 아래의 그림을 보시면 딥줌과 유사하지만, 그래도 유사할 것 같아요^^… 어떤 알고리즘인지가 궁금할 뿐;;

   

HD View SL

위의 'HD View' 의 실버라이트 버전입니다. 참고^^

   

   

정리

Microsoft 는 소프트웨어 개발 기업으로 세계에서 1위 기업입니다. 그 중, Microsoft Research 프로젝트는 여러분들에게 오픈된 프로젝트일 뿐이며, 내부적으로 더 많은 연구가 계속되고 있습니다. 예를 들어, http://codeplex.com 은 여러분들에게 공개된 오픈 소스 커뮤니티지만, Microsoft 내부에는 더 많은 프로젝트들이 수백 개씩 오픈 되어 있습니다. (제가 어떻게 아냐구요? Microsoft 직원이 쓴 책에 그렇다고 말하더군요^^)

다만, 그 중에서 저희에게 오픈된 기술 R&D 영역이 Microsoft Research 프로젝트입니다. 그리고 관심이 없으셔도 상관은 없답니다. 최근 기술 트랜드는 너무나도 빨리 나오고, 변하기 때문에 모두 따라가기가 벅차기도 합니다. 그리고 이 모든 것을 자세하게 알 수 없게 되었습니다. 중요한 것은 내가, 여러분들이 받아들일 기술/트랜드를 준비할 수 있겠지요. 모르고 아는 것과 알고 아는 것은 상당히 다릅니다.

직접적으로 이런 기술들이 나에게는 관련이 없지만, Microsoft 는 비즈니스/웹/시각화/클라우드에 지속적으로 시도를 하는 것을 알 수 있으며, 장차 알게 모르게 도움이 될 거라고 믿습니다. 그리고 이 서비스/기술을 이용하는 사람은 여러분들이 될 수도….^^

Posted by 땡초 POWERUMC

댓글을 달아 주세요

지난 2010년 9월 28일, Visual Studio Korea 에서 처음으로 진행한 Visual Studio Seminar #1 이 있었습니다. 이 날 세미나를 위해 많은 분들이 ONOFFMIX 사이트를 통해 등록을 해 주셨고, 모든 분들이 오신 것은 아니지만 재미있는 주제로 세미나를 진행하였습니다.

세미나 아젠다

시간

세션 내용

19:00 ~ 19:30

등록

19:30 ~ 20:10

현실적인 클라우드 컴퓨팅 이야기

남정현 C# MVP

20:20 ~ 21:00

Expression Blend 와 함께하는 윈도우 폰 7 개발 입문

조진현

21:10 ~ 21:50

Razor 로 열어가는 새로운 ASP.NET

김시원 ASP.NET MVP

     

 

 

     

발표 내용 소개

현실적인 클라우드 컴퓨팅 이야기 / 남정현 C# MVP

클라우드 컴퓨팅, 말로만 들어봤지 실제로 어디에 어떻게 사용이 될 수 있는지 알려주는 사람이 없어 답답할 때가 많습니다. 이번 세션에서는 클라우드 컴퓨팅에 관한 실질적인 이야기, 그 중에서도 특별히 마이크로소프트의 윈도 애저 플랫폼에 대한 이야기를 나누면서, 클라우드 컴퓨팅의 현실적인 사례를 간단히 들어보기로 하겠습니다.

   

Expression Blend 와 함께하는 윈도우 폰 7 개발 입문 / 조진현

윈도우 폰7 개발에 대한 간단한 소개와 방법에 대해서 살펴본다. 그리고 더 쉽고 편한 개발을 위한 고민을 해보며, 이를 위해서 Expression Blend 의 활용에 대해서 고민해 본다.

   

Razor 로 열어가는 새로운 ASP.NET - 김시원 ASP.NET MVP

Razor 는 차세대 ASP.NET 의 새로운 View Engine 으로써 , 이것 때문에 요즈음 ASP.NET 이 한창 주목 받고 있습니다. 이번 시간에는 Razor 의 등장배경과 함께 Razor 로 인해 개발 환경이 어떻게 변화하였는지 살펴보고 , 기본적인 Razor 의 사용법을 익혀보도록 하겠습니다.

  

   

첫 번째 세션인 남정현님의 '현실적인 클라우드 컴퓨팅 이야기' 입니다. 우리 나라에서 클라우드라는 큰 주제로 Windows Azure 플랫폼 기술을 전파하시고 계시는 MVP 분입니다.

 

세미나를 하시면서도 표정 관리에 들어가시고, 사진을 요염하게 의식하시는 모습이 역시 프로답습니다. ^^

   

두 번째 세션은 게임 개발자이신 조진현님의 'Expression Blend 와 함께하는 윈도우 폰 7 개발 입문' 세션입니다. 게임 영역이 아닌 윈도우 폰과 Expression Blend 세션인데, 처음으로 윈도우 폰7에 입문하시는 분을 위해 개인적으로 공부하셨던 부분을 발표해 주셨습니다.

 

조진현님은 KGC와 같은 큰 무대에 여러 번 발표를 해 보신, 경험이 많으신 분인데 이 날 데모 귀신이 왔다 갔다 했다는 후문이… ^^

   

마지막 세션은 김시원 ASP.NET MVP 님이 새로운 뷰 엔진인 Razor 에 대해 매우 재치있고 재미있게 발표를 해 주셨습니다. ASP.NET을 줄곧 파 오셨고, 새로운 기술과 실전 경험에 이미 도가 트신 분이죠^^ 

 

오잉.. 김시원님도 카메라를 요염하게 의식하고 계시군요..

   

   

세미나 접수대에서는 저희 운영진 두 분이 항시 대기 중입니다. (좌측 ASP.NET 4.0 박종혁님, 우측 WCF의 오태겸님)

   

그리고 많은 분들이 참여해 주셔서 이 날 모두 알차게 세미나를 준비했고 마친 것 같습니다. 이하 사진 더 공유하고 마칩니다.^^

   

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 남정현 2010.10.12 14:04 Address Modify/Delete Reply

    음.. 요염하게 의식했던거군요. 저도 몰랐던 사실인데. ㅋㅋㅋ

지난 2010년 9월 28일, Visual Studio Korea 에서 처음으로 진행한 Visual Studio Seminar #1 이 있었습니다. 이 날 세미나를 위해 많은 분들이 ONOFFMIX 사이트를 통해 등록을 해 주셨고, 모든 분들이 오신 것은 아니지만 재미있는 주제로 세미나를 진행하였습니다.

이 날 발표했던 자료를 공유해 드립니다. 세미나 후기가 궁금하신 분은 여기를 클릭하세요^^

   

발표 내용 소개

현실적인 클라우드 컴퓨팅 이야기 / 남정현 C# MVP

클라우드 컴퓨팅, 말로만 들어봤지 실제로 어디에 어떻게 사용이 될 수 있는지 알려주는 사람이 없어 답답할 때가 많습니다. 이번 세션에서는 클라우드 컴퓨팅에 관한 실질적인 이야기, 그 중에서도 특별히 마이크로소프트의 윈도 애저 플랫폼에 대한 이야기를 나누면서, 클라우드 컴퓨팅의 현실적인 사례를 간단히 들어보기로 하겠습니다.

   

Expression Blend 와 함께하는 윈도우 폰 7 개발 입문 / 조진현

윈도우 폰7 개발에 대한 간단한 소개와 방법에 대해서 살펴본다. 그리고 더 쉽고 편한 개발을 위한 고민을 해보며, 이를 위해서 Expression Blend 의 활용에 대해서 고민해 본다.

   

Razor 로 열어가는 새로운 ASP.NET - 김시원 ASP.NET MVP

Razor 는 차세대 ASP.NET 의 새로운 View Engine 으로써 , 이것 때문에 요즈음 ASP.NET 이 한창 주목 받고 있습니다. 이번 시간에는 Razor 의 등장배경과 함께 Razor 로 인해 개발 환경이 어떻게 변화하였는지 살펴보고 , 기본적인 Razor 의 사용법을 익혀보도록 하겠습니다.

     

발표자 소개

   

남정현 C# MVP

(주)코아뱅크에 재직 중이며, Microsoft Visual C# MVP로 활동 중입니다. DEVPIA C# Forum SYSOP, Windows Azure Cafe SYSOP을 맡고 있습니다. 여러 커뮤니티와 개인 블로그, 트위터 (@rkttu)를 통하여 윈도 애저 플랫폼에 대한 다양한 이야기를 전파하고 있습니다.

   

조진현

현재 게임 개발자로 재직 중이며  Visual Studio 2010 공식 팀 블로그 (http://vsts2010.net) 에서 DirectX 관련 분야에서 활동 중이다. 최근에는 '김탁구'와 '나는 전설이다' 라는 드라마에 빠져서 살고 있다.

   

   

   

김시원 ASP.NET MVP

ASP/ASP.NET MVP를 2009년 부터 계속 유지해오고 있으며 다양한 형태의 웹 어플리케이션 개발 경험과 세미나 경험을 가지고 있다. 현재 Hugeflow 웹 솔루션 개발팀에서 개발의욕을 불사르고 있다. 세상을 풍요롭게 하고 사람들에게 강한 종속성을 부여하는 프로그램을 개발하는 것이 목표이다.

   

[[김시원]]

   

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

   

   

  • 주최 : 한국 Visual Studio 공식 팀
  • 일시 : 2010년 9월 28일 오후 7시 ~ 10시
  • 장소 : 한국 마이크로소프트 - 포스코 센터 5층
  • 참가비 : 무료
  • 최근 쏟아지는 기술의 홍수 속에서 '아차~' 하고 눈 깜빡할 순간 신기술에 낙오되기 쉽습니다. 한 번은 괜찮지만, 두 번은 기술 트랜드를 따라잡기가 더 힘들어 집니다. 저희 팀에서 기술을 먼저 접해보고, 먼저 고민해본 살아있는 경험을 여러분들에게 전수해 드립니다.

   

세미나 아젠다

시간

세션 내용

19:00 ~ 19:30

등록

19:30 ~ 20:10

현실적인 클라우드 컴퓨팅 이야기

남정현 C# MVP

20:20 ~ 21:00

Expression Blend 와 함께하는 윈도우 폰 7 개발 입문

조진현

21:10 ~ 21:50

Razor 로 열어가는 새로운 ASP.NET

김시원 ASP.NET MVP

   

   

발표 내용 소개

현실적인 클라우드 컴퓨팅 이야기 / 남정현 C# MVP

클라우드 컴퓨팅, 말로만 들어봤지 실제로 어디에 어떻게 사용이 될 수 있는지 알려주는 사람이 없어 답답할 때가 많습니다. 이번 세션에서는 클라우드 컴퓨팅에 관한 실질적인 이야기, 그 중에서도 특별히 마이크로소프트의 윈도 애저 플랫폼에 대한 이야기를 나누면서, 클라우드 컴퓨팅의 현실적인 사례를 간단히 들어보기로 하겠습니다.

  

Expression Blend 와 함께하는 윈도우 폰 7 개발 입문 / 조진현

윈도우 폰7 개발에 대한 간단한 소개와 방법에 대해서 살펴본다. 그리고 더 쉽고 편한 개발을 위한 고민을 해보며, 이를 위해서 Expression Blend 의 활용에 대해서 고민해 본다.

  

Razor 로 열어가는 새로운 ASP.NET - 김시원 ASP.NET MVP

Razor 는 차세대 ASP.NET 의 새로운 View Engine 으로써 , 이것 때문에 요즈음 ASP.NET 이 한창 주목 받고 있습니다. 이번 시간에는 Razor 의 등장배경과 함께 Razor 로 인해 개발 환경이 어떻게 변화하였는지 살펴보고 , 기본적인 Razor 의 사용법을 익혀보도록 하겠습니다.

   

발표자 소개

남정현 C# MVP

(주)코아뱅크에 재직 중이며, Microsoft Visual C# MVP로 활동 중입니다. DEVPIA C# Forum SYSOP, Windows Azure Cafe SYSOP을 맡고 있습니다. 여러 커뮤니티와 개인 블로그, 트위터 (@rkttu)를 통하여 윈도 애저 플랫폼에 대한 다양한 이야기를 전파하고 있습니다.

조진현

현재 게임 개발자로 재직 중이며  Visual Studio 2010 공식 팀 블로그 (http://vsts2010.net) 에서 DirectX 관련 분야에서 활동 중이다. 최근에는 '김탁구'와 '나는 전설이다' 라는 드라마에 빠져서 살고 있다.

  

김시원 ASP.NET MVP
ASP/ASP.NET MVP를 2009년 부터 계속 유지해오고 있으며 다양한 형태의 웹 어플리케이션 개발 경험과 세미나 경험을 가지고 있다. 현재 Hugeflow 웹 솔루션 개발팀에서 개발의욕을 불사르고 있다. 세상을 풍요롭게 하고 사람들에게 강한 종속성을 부여하는 프로그램을 개발하는 것이 목표이다.

   

오시는 길

한국 마이크로소프트 - 포스코 센터 5층

   

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

안녕하세요. 지난 2010년 8월 28일, '한국 Visual Studio 공식 팀(Visual Studio Korea)' 에서 주최한 Visual Studio Camp #1 세미나의 발표 자료를 공개해 드립니다. (세미나의 후기는 [세미나 후기] Visual Studio Camp #1 를 참고하세요)    

※ 세미나 발표 자료의 저작권과 권리는 발표를 진행한 스피커와 Visual Studio Korea(한국 Visual Studio 공식 팀) 에 있으므로, 영리/비영리/변경하실 수 없습니다.

PDF 문서 다운로드

   

XPS 문서 다운로드

 

세미나 아젠다

  

Native 트랙

.NET 트랙

Enterprise 트랙

14:00 ~ 14:50

Visual Studio 2010 : C++0x와 Windows 7
최성기

그것이 알고싶다 - C# 4.0의 변화, 그 진실은 무엇인가. 희망인가? 또 다른 혼란인가?
강보람 C# MVP

VS Team Foundation Server 2010 의 새로운 변화
김병진 ALM MVP

15:00 ~ 15:50

비주얼 스튜디오 2010 의 Concurrency Runtime 을 이용한 멀티 코어 제대로 활용하기
임준환

좋은 프레임워크 있으면 소개시켜줘 - ASP.NET MVC
박세식

소프트웨어 품질 향상을 위한 다양한 테스트 기법
엄준일 ALM MVP

16:00 ~ 16:50

DirectX11 을 기다리며..
조진현

Beginnig WCF
오태겸

SharePoint 2010 Enterprise 솔루션 개발
정홍주 SQL Server MVP

   

발표 내용 소개 및 세미나 PPT 자료

Native 트랙

Visual Studio 2010 : C++0x와 Windows 7
그 동안 .NET 영역으로 적잖이 편중되었던 Visual Studio의 버전업에 비해 이번 2010 버전에서는 Native Code 개발환경에서도 많은 변화가 찾아왔다. C++0x 표준 반영에 의한 문법의 변화, 새로운 라이브러리 제공(Concurrency Runtime Library), Windows 7의 최신 기능들을 제어하기 위한 SDK의 업데이트 등이 그것이다. 본 세션을 통해 C++의 문법적인 변화와 Windows 7 기능 구현을 위한 SDK의 업데이트 사항들을 정리해본다.

 

비주얼 스튜디오 2010 의 Concurrency Runtime 을 이용한 멀티 코어 제대로 활용하기
요즘 가정의 PC 에 멀티 코어 프로세서가 많이 보급되어 있습니다. 하지만 실제로 PC 에 설치된 코어들을 모두 사용하는 애플리케이션들은 많지 않습니다. 이렇게 낭비되는 자원을 C++ 개발자가 쉽게 사용할 수 있도록 도와주는 Concurrency Runtime 을 비주얼 스튜디오 2010에서 제공합니다. 이 Concurrency Runtime 을 어떻게 시작해야 할지 알아보겠습니다.

 

DirectX11 을 기다리며...
조금씩 정보가 공개되면서 많은 변화를 예고하고 있는 DirectX11 에 대해서 살펴 볼 것입니다. 특히나 Tessellation, DirectCompute, Multi-threading 을 위한 기본 개념과 작업들에 대해서 체크해 볼 것입니다.

조진현님 PPT 는 현재 비공개이며, 추후 공개하도록 하겠습니다.

.NET 트랙

그것이 알고싶다 - C# 4.0의 변화, 그 진실은 무엇인가. 희망인가? 또 다른 혼란인가?
PDC 2008에 울려 퍼진 C# 4.0의 소식. 그 소식을 듣고 많은 사람들은 기대와 혼란을 가지게 되었다. C#은 분명히 정적 언어인데, 동적 언어에나 있을 법한 기능을 추가한다니? 이제 와서 뒷북일 수도 있는 C# 4.0의 변화에 대한 진실, 그 마지막 시리즈가 이제 시작된다. :)

   

좋은 프레임워크 있으면 소개시켜줘 - ASP.NET MVC
그 동안 아주 미묘하게 아쉬웠던 ASP.NET. 가려운 곳을 긁어줄 대안의 프레임워크가 나타났다. 웹 개발자들 한테 참~ 좋은데, 웹 개발자들 한테 정말 좋은데, 이걸 말로 그냥 할 수 없어서, 이번 기회에 소개한다.

   

Beginnig WCF
WCF는 서비스 지향 프로그래밍을 위해 마이크로소프트에서 개발 및 지원하는 기반 기술이며, 기존의 .NET 웹 서비스에 비해 유연성과 확장성이 뛰어나 최근 많은 관심을 받고 있습니다. 본 세션에서는 WCF가 무엇인지? 어떤 장점이 있는지? 그리고, WCF 를 이용하기 위해선 무엇이 필요한지? 에 대해 함께 알아보고, 마지막으로, WCF의 활용 예를 알아보도록 하겠습니다.

Enterprise 트랙

VS Team Foundation Server 2010 의 새로운 변화
V
isual Studio Team Foundation Server 2010의 혁신적인 변화와 개선 부분, 프로젝트 및 형상관리와 Agile의 Scrum 을 이용한 방법론을 알아보고, 단지 소스 체크인/아웃만 하는 Visual Source Safe에서 업그레이드 하는 방법에 대하여 알아봅니다.

   

소프트웨어 품질 향상을 위한 다양한 테스트 기법
소프트웨어는 개발 및 릴리즈 과정까지 수 많은 과정을 겪는데, 소프트웨어가 점진적으로 진화함에 따라 결함의 발생률이 증가합니다. 이를 개선하기 위한 테스트 기법 중 단위 테스트, WhiteBox 테스트, 화면 테스트, 성능 테스트, 부하 테스트 등 다양한 테스트 기법을 알아봅니다.

   

SharePoint 2010 Enterprise 솔루션 개발
SharePoint 2010은 기업 협업 플랫폼으로 개발자들은 VS 2010을 이용하여 더 생산성 있고 효과적인 SharePoint 2010 개발을 진행할 수 있습니다. 본 세션에서는 SharePoint 2010 개발에 대한 가장 필요한 내용을 구체적으로 알아보며 이를 통해 가장 많은 요구사항에 대한 실무 솔루션을 구성하는 방법에 대한 내용을 알아보겠습니다.

   

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

2010년 8월 28일, Visual Studio Camp #1 에서 발표한 "Enterprise Track : [2] 소프트웨어 품질 향상을 위한 다양한 테스트 기법 - 엄준일 ALM MVP" 세션을 들어주신 분 중에 어느 테스트 전문가를 만나 뵙게 되었습니다. 최근 테스트 공학과 테스트 프로세스에 푹 빠져있는 저에게 매우 단비와도 같은 분이시고, 특히 테스트 전문 도구인 Load Runner 제품을 실제로 사용하고 계신 분이셨습니다.

(http://willstory.tistory.com/4)

제 세션의 내용과 현재 사용하고 계신 Load Runner 제품에 대해 경험적으로 비교를 해 주신 후기를 작성해 주셔서, 여러분들에게 도움이 될까 싶어 @will_story 님의 동의를 얻어 저희 팀 블로그에 게시하게 되었습니다.

가격에서 상당히 차이가 나는 Load Runner 와 Visual Studio 2010 Ultimate(테스팅 기능에 한하여) 비교해 주셨는데, 역시 비싸다고 좋은 도구는 아닌가 봅니다.^^ 이 두 도구에 대해 냉철하게 비교해 주신 @will_story 님께 감사 드리며, @will_story 님의 글을 보기 쉽게 편집하여 전문을 공개해 드립니다.

참고로, Visual Studio 2010 은 매우 광범위한 테스트 영역을 지원하고 있습니다. 테스트 공학에서 접근하는 대부분의 테스트 기능이 Visual Studio 2010 하나의 통합 도구에서 제공하는 것입니다.

[그림1] 테스트 기법 정리(Visual Studio Camp #1 의 세션 내용 중)

아래의 글은 http://willstory.tistory.com/4 의 글쓴이의 동의 하에 제공되어, 약간의 편집하였으나, 원문의 의미상 변형이 전혀 없음을 알려드립니다. 좋은 글을 제공해 주셔서 감사의 마음을 전해 드립니다. ^^

비주얼 스튜디오 2010 팀 블로그에서 Visual Studio Camp를 진행하였다. 여러가지 세션이 있었지만 나의 관심사항만 세미나를 경청하고 퇴장하였다. 유익한 정보였고 너무나도 소중한 시간이었다. 혹시 세미나 후기에 대한 내용에 대하여 자세한 정보를 알고 싶다면 아래의 링크를 따라갔으면 좋겠다.

Load Runner 의 버전은 8.1이다. 나에게는 아직 Windows 7이 없어 XP에서 잘 돌아가는 8.1 버전으로 작성하였다. Windows 7 에서 Load Runner 10.1을 해보고 싶었지만 OS가 없기에 아쉽게도 XP기준으로 작성한다.

세미나 후기, Visual Studio Camp #1

Enterprise Track : [2] 소프트웨어 품질 향상을 위한 다양한 테스트 기법 - 엄준일 ALM MVP – 땡초[엄준일]

소프트웨어 개발의 이전의 사례를 바탕으로 테스팅의 중요성과 그 기법과 방법을 공부하면서 경험한 내용을 전달하였습니다. 소프트웨어 개발 프로세스 중 테스팅의 매력에 푹 빠져 있답니다.

소프트웨어는 개발 및 릴리즈 과정까지 수 많은 과정을 겪는데, 소프트웨어가 점진적으로 진화함에 따라 결함의 발생률이 증가합니다. 이를 개선하기 위한 테스트 기법 중 단위 테스트, WhiteBox 테스트, 화면 테스트, 성능 테스트, 부하 테스트 등 다양한 테스트 기법을 알아봅니다.

사실 PPT 자료만 올라오면 이미지를 Load Runner 와 비교하고 싶었지만 아쉽게도 자료를 받지 못한 것이 아쉽다. 먼저 Load Runner 이미지로 비교 분석을 하고자 한다. 나중에 추후 VS2010 팀에서 자료를 받으면 추후 업그레이드를 하도록 하겠다.

자아.. 이제 내 Tistory의 첫 포스팅이자 첫 블로그 운영이 내가 관심이 있는 분야라서 매우 즐겁다. 이제 이야기를 보따리를 풀어보자.

Visual Studio Camp #1은 예전부터 신청하였다. 전에도 SW Testing Bar Camp 때 주최하였던 곳에서 그리 멀지 않은 곳이기 때문에 가기까지는 무리 없이 도착하였다. 이전에 Sten에서 Razar라는 제품[베타 테스트로 참석하여 경품을 받게 되었다.]으로 테스트한 경험을 공유한다고 하여 10시에 일정이 있었는데, 필요인원 부족으로 무산이 되어 집에서 피파온라인으로 열심히 게임을 하다가 세미나 시간에 맞추어 참석하였다.



도착하였을 때 깔끔한 신청 절차 간편한 입장이 인상적이다. 누가 발표자인지 누가 경청자인지 알 수 있는 이름표는 좋았다는 생각이 들었다. 하지만 이름표에 자신의 맡고 있는 MVP 분야를 적어 두었다면 경청자가 추후 질문을 하는데 있어 생각하는 수고를 덜어줄 수 있지 않았을까? 라는 생각을 하게 된다. 1시간 정도의 짧은 만남 물론 얼굴과 이름은 질문자가 당연히 갖추어야 할 기본 예의지만 … 그냥.. 뭐 아쉽다는 거다.

난 엔터프라이즈 Enterprise Track : [2] 소프트웨어 품질 향상을 위한 다양한 테스트 기법 - 엄준일 ALM MVP 님의 세미나를 들었다. 들으면서 Load Runner 와 흡사하기 보다는 오히려 'Load Runner 를 뛰어 넘을 수도 있겠다'라는 생각과 전율이 마음 깊숙히 전해져 왔다. 이미지가 있다면 전달이 쉽겠지만 아쉽다.. 아쉬워….

첫 번째, 비교[다양한 옵션 VS 심플함]

  • Load Runner 의 강점! 다양한 옵션
    다양한 옵션을 포함하고 있어 스크립트 작성 시 웹 페이지에 맞도록 작성이 용이하다.

    이외에 다양한 옵션이 존재한다. 좀…. 복잡하다. 잘못 설정했다가 원하는 결과를 얻기 어렵다.

  • Visual Studio 2010 강점
    • Simple 하다. 너무도 쉽게 심지어 Load Runner 보다 쉽다. Load Runner 의 사용자 매뉴얼은 너무도 이론적이며 복잡하다.
    • 하지만 Visual Studio 안내 설명은 매우 쉽게 설명하여, 특히 Visual Studio 2010 공식 팀 블로그에서도 자세하게 설명을 해주고 있다. 직접 경험을 기반으로 작성을 해주니 이보다 친절하고 절실하게 와닿은 설명이 어디 있겠는가!(소통과 공유가 존재하는 것)
    • 일반 사용자가 특히 개발자가 바로 바로 성능 테스트를 수행 할 수 있도록 되어있다.

두 번째, 비교[성능 테스트 시나리오]

  • 스케줄이 편리한 강점
    원하는 대로 인원도 증가 시킬 수 있다. 예약시간도 존재한다. 성능을 위하여 새벽2시에 기다려 테스트하지 않고 예약시간을 설정하면 알아서 돌아 간다. 랜덤으로 oo명에서 0명까지 물결 치듯 설정도 가능

  • 편리한 스케줄 일정
    Load Runner 와 마찬가지로 스케줄이 변경이 동일하다. 랜덤으로 oo명에서 0명까지 물결 치듯 설정도 가능한지는 짧은 세미나 내용으로 언급되지 못한 것이 아쉬운 점이다. 하지만 예상으로는 될 것으로 보인다.     세 번째, 비교[성능 모니터링]

  • Load Runner 의 모니터링
    Load Runner 는 Web/HTML만 반영하는 것이 아니며 DB/Oracle도 성능 테스트가 가능하기 때문에 매우 다양한 모니터링 지원이 가능하다[물론 돈이 많은 기업이라면 유로로 라이선스를 사야 한다.]

  • Visiual Studio 2010의 모니터링
    가장 아쉬운 부분 중에 하나이다. Load Runner 처럼 다양한 모니터링을 제공할 수 있을까[?] 라는 의문이 든다.

    하지만 강점도 있다. Load Runner 모니터링보다 심플하고 깔끔하며 원하는 정보만 보여준다. 로드러너 처럼 4개 정도의 모니터링 그래프를 제공하는 형식은 비슷하지만 디자인 면에서나 컴퓨터를 오래 사용하는 사용자의 입장에서 생각하는 UI는 Microsoft 의 Windows 7 로고처럼 심플하면서도 편안한 이미지로 되어있다. Load Runner 는 보고서를 출력하면 중복되는 내용이 많은데 Visual Studio 2010은 깔끔함과 심플함 원하는 정보와 불필요한 중복을 피하는 듯한 느낌을 받았다.     네 번째, 비교[리포트 및 보고서 출력]

  • Load Runner 의 모니터링
    Load Runner 는 2가지 방식으로 보고서를 출력할 수 있다. HTML, *.doc(docx) 방식이다. 알아서 목차도 만들어주고 내용도 작성해 준다. 물론 아쉽지만 영어로만 제공된다. 나는 그래서 주로 그래프만 이용한다.     

  • Visiual Studio 2010의 모니터링
    내가 보았을 경우에는 *.execl 형식으로 출력을 하는 것을 보았다. 조금은 아쉬운 점이다. 보고서를 다른 발주처에 보내었을 때 엑셀보다는 워드파일로 만약 공공기관이라면 *.hwp 파일로 보내야 하지만 *.execl은 조금은 뽀대[?]가 부족하다. 작성한 문서를 워드로 다시 편집 해야하는 수고를 덜어야 한다.

    물론 99% 성능 전문가들과 각 회사마다 프로젝트 성능 담당자들은 회사에서 쓰는 양식을 이용하여 템플릿에 맞게 보고서를 작성할 것이다. 나 또한 회사 템플릿으로 작성한다. 하지만 보고서로 출력하여 바로 줄 수 있을 정도의 수준이라면 이제는 로드러너는 내 손을 떠나 보내고 Visual Studio 2010 을 사용하지 않을까 생각한다.     Visual Studio 2010 Camp #1 짧은 후기

세션을 들으면서 엄준일[땡초]님과 10정도의 대화를 나누었다. 테스트에 재미를 붙이신 듯 호기심 어린 모습과 열정에 박수를 보내주고 싶다. [테스트의 세계로 오신 것을 환영합니다. 쿠쿠쿠쿠.ㅋ]

Visual Studio 2010 Camp #1 를 진행하셨던 어느 기술전도사님이 예전에 나도 스탭으로 다른 몇몇 분들과 함께 진행한 SW Testing Camp 와 함께 진행하였으면 좋겠다고 제안하였을 때 당장 "그럽시다" 라고 대답하고 싶었지만 아쉽게도 나 혼자만의 결정할 사안이 아니기에 대답을 회피했다. 아쉽 아쉽… Windows 7 운영체제에 Visiual Studio 2010 을 설치한 제품과 Load Runner 를 비교하면 나의 객관적인 입장에서는 Load Runner 에게 8.5점을 Visual Studio 2010 에게는 9.0점을 주고 싶다.

1시간만 들었던 세미나였지만 너무나 강렬한 인상이 아직도 기억 속에 남는다. 엄준일님이 함께하자는 말과.. 기술전도사님이 Visual Studio 2010 팀에서 함께 하자는 말 들이.. "기술전도사님 사실 저는 Windows 7이 없어요.. Visual Studio 2010도 없어요. ㅠㅠ;;; 빌려주시면.. 해보고는 싶어요.ㅠㅠ". 흑흑 2010년도는 일만 벌린다.. 담 주는 대학원 개강이구나

Windows 7에 Visiual Studio 2010 설치해주는 회사로 이직 옵션의 하나로 정해야겠다.. 좋은 회사 있음 소개시켜줘~ *_*/

많은 정보를 공유하고 싶지만 방화벽으로 text로만 해야 하는 회사에 아쉬움을 던지며 이만 작성 끝~~~

필자는 Load Runner 를 써보지 않고, 오직 Visual Studio 만으로 테스팅 공학과 분야에 흥미를 갖고 공부를 하고 있습니다. 이번 Visual Studio Camp #1 을 통해서 오히려 저에게 좋은 정보를 제공해 주시고, 의견을 공유할 수 있어서 너무 뜻 깊은 자리였습니다.

좋은 글을 저희 팀 블로그에 기고에 동의해 주신 http://willstory.tistory.com/4 님께 감사합니다.


Posted by 땡초 POWERUMC

댓글을 달아 주세요

2010년 8월 28일, 웹 타임 교육센터에서 Visual Studio Camp #1 이 개최되었습니다. 이 날 세미나는 저희 한국 Visual Studio 팀에서 주최하고, 웹 타임 교육센터와 Visual Studio 2010 이 후원한 행사입니다.

저희가 주변에서 흔히 접할 수 있는 .NET 트랙의 C#, ASP.NET MVC, WCF 세미나도 재미있는 내용으로 알차게 준비를 했습니다. 그리고 흔히 접하기 힘든 Enterprise 트랙과 Native 트랙도 가뭄의 단비와도 같은 트랙입니다.

원래 웹 타임 교육센터는 각 자리에 교육 PC 가 비치된 환경으로 책상 위에 컴퓨터 모니터와 키보드, 마우스가 비치되어 있었으나, 세미나 참가자의 쾌적한 환경을 위해 오전 10시부터 책상 위의 모니터를 치우는 작업을 하였답니다. 그리하여 아래와 같이 깨끗한 책상이 되었군요^^

  

   

이 날, 저희 팀에서 세미나를 진행하기 위해 많은 요원들이 일찍 모여 준비하고 세미나를 준비하고 접수를 받고 있습니다.

  

   

즐거운 토요일 주말에 비가 오다마다를 반복하는 짓궂은 날씨에서 불구하고 세미나에 참석해 주신 여러분들을 위해 푸짐한 경품도 준비를 하였습니다.

경품은

  • 엄준일 ALM MVP 님의 MSDN Subscription 1년 구독권 2매
  • 김병진 ALM MVP 님의 무선 마우스 3개, 무선 키보드 3개
  • Microsoft Korea 의 강성재 차장님과 Visual Studio 2010 에서 Visual Studio 2010 Professional 정품 1개

누가 경품을 가져갈 진 모르겠지만, 기뻐하실 분들을 생각하면 벌써부터 가슴이 설레입니다.^^

   

오홋.. 드디어 세미나가 오후 2시부터 시작 되었습니다.

   

.NET Track : [1] 그것이 알고싶다 - C# 4.0의 변화, 그 진실은 무엇인가. 희망인가? 또 다른 혼란인가? - 강보람 C# MVP

재미있는 블로그 아티클과 세미나 진행으로 이번 세미나에서도 유감없이 C# 4.0 의 내용을 재미있게 풀어주셨습니다. 현재는 집필 활동에 주력하고 계시는군요.

PDC 2008에 울려 퍼진 C# 4.0의 소식. 그 소식을 듣고 많은 사람들은 기대와 혼란을 가지게 되었다. C#은 분명히 정적 언어인데, 동적 언어에나 있을 법한 기능을 추가한다니? 이제 와서 뒷북일 수도 있는 C# 4.0의 변화에 대한 진실, 그 마지막 시리즈가 이제 시작된다. :)

   

   

.NET Track : [2] 좋은 프레임워크 있으면 소개시켜줘 - ASP.NET MVC - 박세식

ASP.NET MVC 를 실무적으로 사용하기 위해 정말 쉽고 재미있는 내용으로 채워졌습니다.

그 동안 아주 미묘하게 아쉬웠던 ASP.NET. 가려운 곳을 긁어줄 대안의 프레임워크가 나타났다. 웹 개발자들 한테 참~ 좋은데, 웹 개발자들 한테 정말 좋은데, 이걸 말로 그냥 할 수 없어서, 이번 기회에 소개한다.

   

   

.NET Track : [3] Beginnig WCF - 오태겸

"WCF 는 어렵다!!!" 라는 선입관을 깨주신 오태겸 님의 세미나를 들으신다면 'WCF 는 쉽구나^^' 라고 느끼실 겁니다.

WCF는 서비스 지향 프로그래밍을 위해 마이크로소프트에서 개발 및 지원하는 기반 기술이며, 기존의 .NET 웹 서비스에 비해 유연성과 확장성이 뛰어나 최근 많은 관심을 받고 있습니다. 본 세션에서는 WCF가 무엇인지? 어떤 장점이 있는지? 그리고, WCF 를 이용하기 위해선 무엇이 필요한지? 에 대해 함께 알아보고, 마지막으로, WCF의 활용 예를 알아보도록 하겠습니다.

   

   

   

Native Track : [1] Visual Studio 2010 : C++0x와 Windows 7 - 최성기

NCsoft 에 근무하시는 최성기님의 세션입니다. 여러 매체를 통해서 C++0x 와 Windows 7 의 기술을 전파하셨고, Windows 7 with C++0x 에 경험도 풍부하십니다.

그 동안 .NET 영역으로 적잖이 편중되었던 Visual Studio의 버전업에 비해 이번 2010 버전에서는 Native Code 개발환경에서도 많은 변화가 찾아왔다. C++0x 표준 반영에 의한 문법의 변화, 새로운 라이브러리 제공(Concurrency Runtime Library), Windows 7의 최신 기능들을 제어하기 위한 SDK의 업데이트 등이 그것이다. 본 세션을 통해 C++의 문법적인 변화와 Windows 7 기능 구현을 위한 SDK의 업데이트 사항들을 정리해본다.

   

   

Native Track : [2] 비주얼 스튜디오 2010 의 Concurrency Runtime 을 이용한 멀티 코어 제대로 활용하기 - 임준환

임준환님은 좋은 내용을 여러분들에게 전해드리려고 일찍부터 나오셔서 리허설도 진행하신 투혼(^^) 을 발휘해 주셨답니다.

요즘 가정의 PC 에 멀티 코어 프로세서가 많이 보급되어 있습니다. 하지만 실제로 PC 에 설치된 코어들을 모두 사용하는 애플리케이션들은 많지 않습니다. 이렇게 낭비되는 자원을 C++ 개발자가 쉽게 사용할 수 있도록 도와주는 Concurrency Runtime 을 비주얼 스튜디오 2010에서 제공합니다. 이 Concurrency Runtime 을 어떻게 시작해야 할지 알아보겠습니다.

   

   

Native Track : [3] DirectX11 을 기다리며… - 조진현

클라이언트 게임 프로그램을 개발하고 계신 조진현님의 DX11 에 대한 세션입니다. KGC 등 여러 세미나 경험을 가지고 계시지요.

조금씩 정보가 공개되면서 많은 변화를 예고하고 있는 DirectX11 에 대해서 살펴 볼 것입니다. 특히나 Tessellation, DirectCompute, Multi-threading 을 위한 기본 개념과 작업들에 대해서 체크해 볼 것입니다.

   

   

   

Enterprise Track : [1] VS Team Foundation Server 2010 의 새로운 변화 - 김병진 ALM MVP

Team Foundation Server 2010 을 이용하여 컨설팅과 실무에서 많은 경험을 토대로 세션을 진행하였습니다. 웹 타임 교육센터와 큰 기업 등에서 교육을 했던 경험도 있으시답니다.

Visual Studio Team Foundation Server 2010의 혁신적인 변화와 개선 부분, 프로젝트 및 형상관리와 Agile의 Scrum 을 이용한 방법론을 알아보고, 단지 소스 체크인/아웃만 하는 Visual Source Safe에서 업그레이드 하는 방법에 대하여 알아봅니다.

   

   

Enterprise Track : [2] 소프트웨어 품질 향상을 위한 다양한 테스트 기법 - 엄준일 ALM MVP

소프트웨어 개발의 이전의 사례를 바탕으로 테스팅의 중요성과 그 기법과 방법을 공부하면서 경험한 내용을 전달하였습니다. 소프트웨어 개발 프로세스 중 테스팅의 매력에 푹 빠져 있답니다.

소프트웨어는 개발 및 릴리즈 과정까지 수 많은 과정을 겪는데, 소프트웨어가 점진적으로 진화함에 따라 결함의 발생률이 증가합니다. 이를 개선하기 위한 테스트 기법 중 단위 테스트, WhiteBox 테스트, 화면 테스트, 성능 테스트, 부하 테스트 등 다양한 테스트 기법을 알아봅니다.

   

   

Enterprise Track : [3] SharePoint 2010 Enterprise 솔루션 개발 - 정홍주 SQL Server MVP

SharePoint 2010 으로 엔터프라이즈 환경에 필요한 실무 사례와 경험을 이 세션에서 전달하였습니다. 웹 타임교육 센터의 전임 강사이십니다.^^

SharePoint 2010은 기업 협업 플랫폼으로 개발자들은 VS 2010을 이용하여 더 생산성 있고 효과적인 SharePoint 2010 개발을 진행할 수 있습니다. 본 세션에서는 SharePoint 2010 개발에 대한 가장 필요한 내용을 구체적으로 알아보며 이를 통해 가장 많은 요구사항에 대한 실무 솔루션을 구성하는 방법에 대한 내용을 알아보겠습니다.

   

  

   

드디어 경품 추첨 시간

더 많은 분들에게 경품을 드리고 싶었지만, 자비로 경품을 준비하느라 많은 분들에게 드리지 못해서 아쉽습니다.^^ 다음엔 더 비싸고(^^), 풍성하고, 유용한 경품을 많이 준비할게요^^

   

경품은 이 날, 세미나를 위해 발표해 주신 스피커 분들께서 추첨을 통해 전달해 드렸습니다.

   

MSDN Subscription 1년 구독권 2매

이 경품으로 MSDN 을 통해서 Windows 7, Windows Server 2008, SQL Server 2008, Team Foundation Server 2010, Visual Studio 2010 Ultimate, Office 2010 등의 제품을 모두 모두 사용할 수 있답니다.

   

무선 키보드 3개

  

   

무선 키보드 3개

  

   

   

대망의 Visual Studio 2010 Professional 정품 1개 ^^

Visual Studio 2010 Professional 정품은 Microsoft Korea 의 강성재 차장님과 Microsoft Korea 의 Visual Studio 제품 관련 팀에서 후원해 주신 오늘 쵝오의 경품입니다. 강성재 차장님께서 직접 추첨을 해 주셨습니다.

   

Visual Studio Camp #1 을 마치며

저희 팀의 많은 분들께서 이 날 행사와 좋은 내용의 세미나를 준비해 주셔서 무사히 세미나를 마치게 되었습니다. Native 트랙은 C++ 개발자와 게임 개발자에게 정말 단비와도 같은 세미나였고, 많은 분들의 좋은 피드백을 받았습니다. .NET 트랙과 Enterprise 트랙도 여러 분들의 기술 트랜드가 뒤쳐지지 않도록 부지런히 기술 전파를 위해 팀 블로그를 통해 노력했고, 이번 세미나를 통해 저희 Visual Studio 팀도 매우 기뻤고, 더 많은 용기를 얻은 것 같습니다.

특히 저희 한국 Visual Studio 팀에서는 아무도 먼저 가보지 않은, 아무도 접해보지 않은 많은 기술과 트랜드의 홍수 속에서 항상 긴장감을 늦추지 않고 노력해 주셔서 오늘의 세미나가 있지 않았나 생각합니다. 앞으로도 저희 Visual Studio Korea 팀의 많은 응원 부탁 드립니다.

더 좋은 내용을 블로그 내용과 세미나, 각종 매체를 통해 여러분들에게 다시 찾아 뵙도록 하겠습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

문제 발생

얼마 전, 집에서 몇 번의 누전 사고로 인해 집 서버의 컴퓨터가 여러 번 꺼지는 충격을 받았습니다. 그 이후로 잘 동작하는 줄 알았지만, Team Foundation Server 의 웨어하우스가 제대로 동작하지 않았습니다.

Team Foundation Administration Console 을 통해 확인해 본 결과 Warehouse Database 의 구성이 올바르지 않아 Rebuild 가 되지 않는 현상을 발견했습니다.

   

SQL Server 의 DT(Database Tier) 에서 확인해 본 결과, 아래와 같이 웨어하우스 파일에 오류가 발생하였습니다.

   

문제 해결

여러 번 집 서버 컴퓨터가 꺼지는 현상이 발생하여 이 파일을 복구 하기에는 좀 힘들어 보였습니다. 그래서 Tfs_Analysis 웨어하우스 데이터베이스를 새로 생성하는 방법이 어떨까 하고 검색을 해 보았습니다.

Failed to Process Analysis Database 'Tfs_Analysis'
http://social.msdn.microsoft.com/Forums/en/tfsgeneral/thread/9a2e4292-a719-43df-8757-dd90d5f60ab0

위 내용에서 확인할 수 있듯이, 기존 웨어하우스 데이터베이스를 삭제하면 자동으로 다시 만들어준다고 합니다. 하지만 위와 같은 오류가 나면 삭제도 안됩니다. 다른 데이터베이스 이름을 사용하기도 싫군요^^; 선뜻 데이터베이스를 삭제하기도 그렇고, 백업 오류도 발생하여 Hyper-V 의 스냅샷을 찍어두고 데이터베이스를 삭제하고 다시 만들어 보았습니다.

1. SQL Analysis 데이터베이스를 정지합니다.

   

2. 아래의 폴더로 이동한 후, Tfs_Analysis.0.db 폴더의 이름을 변경합니다.
%ProgramFiles%\Microsoft SQL Server\MSAS10.MSSQL2008\OLAP\Data

   

3. 다시 MSSQL Analysis 서비스를 시작합니다.

   

4. Tfs_Analysis 데이터베이스에서 마우스 오른쪽 버튼을 클릭한 후, 삭제를 선택합니다.

   

5. 개체 삭제에서 확인을 클릭합니다.

   

6. Team Foundation Administration Console 의 Application Tier-Reporting 메뉴로 이동한 후, Edit 를 클릭합니다.

   

7. 각 탭 메뉴에서 Test Connection 을 클릭하면, '기존의 데이터베이스가 없는 경우 새로 생성된다는' 메시지와 함께 테스트가 성공합니다.

   

8. 모든 구성을 완료하였으면, OK 버튼을 클릭합니다. 그럼, 새로운 Analysis Database 가 생성이 되는 작업을 진행합니다. 
   

9. MSSQL Analysis 서버에 Tfs_Analysis 데이터베이스가 새로 생성된 것을 확인할 수 있습니다.

   

10. Team Foundation Administration Console 의 Reporting 메뉴에서 Start Job 과 Start Rebuild 메뉴를 차례로 클릭해 줍니다.

   

11. 모든 웨어하우스와 관련된 서비스가 정상적으로 동작하는 것을 확인하고 작업을 완료합니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

심리학은 인간의 잠재적인 내면을 이해하는 매우 중요한 학문입니다. 여러 가지 질병을 이해하고 치료함에 있어서 심리학은 치료를 목적으로 하는 것이 아닌, 그 근본을 이해해야 하는 매우 섬세하고 중요한 것이 틀림이 없습니다. 그리고 심리학에서 최초 인간의 성향을 두 가지로 분류를 하였고, 이를 바탕으로 개발자의 성향을 알아보고 그리고 앞으로 나아갈 방향을 제시해 보고 싶네요.

   

외향성과 내향성

융의 심리유형론(Psychological Type Theory) 은 인간의 성향을 처음으로 "외향성"과 "내향성"으로 구분하였습니다. 외형성은 에너지가 외부로 향하는 경향이고, 내향성은 에너지가 내부로 향하는 경향입니다.

특히 재미있는 것은, 동서양을 막론하고 "외향성"과 "내향성" 중, 외향성은 매우 긍정적으로 묘사하고 있으며, "내향성"은 부정적으로 묘사하고 있습니다. 아래의 네이버 사전을 통해 각 성향에 대한 정의를 알아 봅니다.

외향성이란?

내향성이란?

외향성은 능동적이고, 판단이 종합적이고, 명랑하고 적극적이라는 매우 활동적인 단어를 사용하여 묘사를 하고 있습니다. 반면 내향성은 결단적 부족, 실행력 부족, 회의적, 비판적, 친구가 적다는 부정적인 단어들을 사용하여 묘사를 하고 있습니다.

결론은 외향적인 사람은 성격이 좋은 사람이지만, 내향적인 사람은 성격이 안 좋은 사람으로 비춰지기 매우 쉽습니다. 인간을 단 두 가지 성향으로 사람을 구분하는 것도 무리겠지만, 재미있는 것은 일반인들도 "외향적, 내향적"인 상대방의 성향을 판단하기 매우 쉽다는 것입니다.

   

어린이 시절의 외향적, 내향적인 성향

어린이는 이런 성향을 관찰하기 매우 쉬운 집단입니다. 왜냐하면 사회화가 잘 되지 않은 집단이기도 하며, 자신의 성향을 그대로 표출하려는 경향이 많은 집단이기 때문에 이들을 관찰하면 흥미로운 결과를 얻을 수 있습니다.

외향적인 아이의 특징은 활동 수준이 높습니다. 이는 매우 적극적이며, 한 가지 일을 하는 것보다 여러 호기심을 자극시킬 수 있는 여러 활동을 하고 싶어합니다. 내향적인 아이의 특징은 활동 수준이 낮습니다. 이는 소극적이며, 복잡하거나 시끄러운 환경에 놓이게 되면 "엄마, 정신 없어." 라고 하는 아이들의 집단입니다.

 

외향적인 아이 : 주의 집중력이 낮음

내향적인 아이 : 주의 집중력이 높음

위의 아이의 실험에서 알아볼 수 있는 결과로, 외향적인 아이는 주변의 환경뿐만 아니라 성향적으로 주위 집중력이 굉장히 낮다는 것을 알 수 있습니다. 반대로 내향적인 아이는 주위의 간섭을 받겠지만, 주위 집중력이 매우 높은 아이라는 것을 알 수 있습니다.

   

과연 이 아이들의 성향이 선천적일까요? 후천적일까요?

생후 36개월 된 아이의 가정 학습 시간을 관찰한 결과, 외향적인 아이는 쉽게 지루해하며, 어머니와의 공부에 집중을 오랫동안 하지 못합니다. 반면에 내향적인 생후 36개월 된 아이는 주변의 영향을 받지 않고, 어머니와의 공부를 몇 시간 동안 집중하며 할 수 있는 높은 집중력을 보이고 있다고 합니다.

이는 생후 36개월 뿐만 아니라, 생후 30개월 된 아이에게도 똑같은 행동 성향을 보입니다.

이는 "종단 연구" 에 대상이 되는 아이들을 장기적으로 관찰하는 방법으로 실험이 진행됩니다. 종단 연구는 성향으로 분류되는 아이들이 나중에도 성향이 변하는지, 안 변하는지 등을 오랜 시간 동안 관찰하는 연구입니다. 국내에서는 종단 연구는 생후 18개월 된 아이들을 400명을 표본 대상을 모집하여 연구를 진행하였다고 합니다. 생후 48개월 까지는 6차례 관찰을 하며, 48개월 이후로는 1년 동안 한번씩 관찰하는 방법입니다. 즉, 종단 연구는 5년간 아이들을 지속적으로 관찰하여 그들의 성장이 지속적으로 어떻게 변하는지를 연구입니다.

이 "종단 연구"를 통하여 아이들의 성향이 변하는가, 또는 변하지 않는가의 결과는 아래와 같다고 합니다. 즉, 생후 18개월 이후 한번 결정되는 성향은 쉽게 변하지 않는다는 결론을 얻을 수 있습니다.

   

생후 1개월 전의 아이로 보는 성향

재미있는 결과 입니다. 생후 16주가 되는 아이들을 대상으로, '알코올 냄새 반응', '풍선 터트리기 반응' 등으로 연구한 결과입니다. 외향적인 집단의 아기는 알코올 냄새나 풍선 터트리기 등의 반응에 매우 호감을 느끼며, 거부 반응을 느끼지 않지만, 반대로 내향적인 집단의 아기는 이런 검사에 울음을 터뜨리거나 냄새를 피하거나 깜짝 놀라는 등의 거부 반응을 보였다는 것입니다.

이는 생후 48시간 되는 아이들에게도 비슷한 결과가 있다고 합니다. 이 아이에게 간호사들이 몸을 닦거나 머리를 감기는 행동에, 외향적인 아이는 별 반응이 없지만, 내향적인 아이는 매우 거부하거나 울기도 한다고 합니다.

이는 더 거슬러 올라가 뱃속에 있는 엄마의 뱃속부터 타고난다고 합니다. 정말 신기하죠.

태아의 외향적인 성향은 움직임이 태동이 매우 활발하여 심박수가 157회 정도가 되며, 내향적인 아이는 118회 정도라고 합니다.

정말 과연 성향의 연관은 어떤 관계가 있을까요?

뱃속의 태아의 태동으로도 외향적인 아이와 내향적인 아이는 이미 결정되었다고 합니다.

더 재미있는 것은, 아이를 두 번 가져본 산모의 경험으로, 첫 번째 아이는 태동이 매우 활동적이지만, 두 번째 아이는 태동이 비활동적이라는 것입니다. 이를 보아, 성향의 결정은 태아 시절 그 이전 이라는 것을 알 수 있는 대목이기도 합니다. 활동적인 태아는 스포츠나 빠른 음악에 태동이 반응하는 한편, 내성적인 태아는 클래식이나 조용한 분위기에서 아이 엄마는 태동을 느낀다고 합니다.

   

인간의 성향은 DNA 부터 시작된다고 한다.

여러 가지 실험을 바탕으로 학계에서는 인간의 성향이 결정되는 바로 유전적이고 DNA 의 영향을 받는다고 합니다. 이런 가장 확실한 예가, 마약 탐지견입니다. 마약 탐지견을 만들기 위해 용맹성, 적극성, 집중력 등 검사에서 통과해야 하는데, 이런 탐지견을 만들기 위해 한 마리 당 4000만원의 비용이 필요하다고 합니다. 그리고 그것은 기본적인 개가 용맹성, 적극성, 집중력 등의 성향을 만족해야 하는 약 30%의 성공률을 가지고 있었습니다. 하지만 복제를 통해 똑같은 성향의 개를 우리 나라에서 배출했습니다.

통계적으로 인간에게는 60~70%는 선천적인 성향이고, 나머지 30%~40%는 사회적으로 길러지는 성향이라고 합니다. 즉, 내성적인 성향이 외형적 성향이 될 수 있으며, 외형적 성향이 내형적 성향의 집중력의 장점을 갖을 수 있다는 것입니다.

즉, 인간의 성향을 심리학적인 방향 외에 유전학적인 방향으로 연구가 활발하게 진행되고 있습니다.

   

왠 뜸금 없는 인간의 성향과 DNA?

이 내용은 다음 편에 얘기 하고자 합니다. 일반적으로 내향적인 성향보다 외향적인 성향에 매우 관심 있어하며, 사회는 내향적인 성향은 매우 부정적인 시각을 가지고 있기도 합니다.

이것은 비단 사회적인 이슈 뿐만 아니라, 개발 또는 IT 세계에서도 통용될 수 있습니다. 사회는 왜 외향적인 적극적이고 진취적인 사람을 원하는가? 바로 이러한 물음에서 시작된 것입니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 진희쩜넷 2010.08.16 19:45 Address Modify/Delete Reply

    흥미로운 이슈입니다. 다음편이 기대됩니다 ^^

개발자와 프로그래머는 말로 설명하거나 회의를 통해 결론을 이끌어내는 능력이 매우 부족한 것이 필자의 경험입니다. 바로 개발자나 프로그래머는 내향적인 성향을 가진 사람이 많더군요. 누군가와 함께 고민해서 결론을 이끌어 내는 것 보단, 이러한 공유되는 정보 없이 스스로 해결하기를 바라니까요.

   

세계를 이끌어가는 리더는 내향적인 성향의 사람이 많다.

가장 대표적인 인물이 버럭 오마바와 빌 게이츠일 것입니다. 특히 빌 게이츠는 유아기 시절에 '자폐증'을 의심할 정도로 매우 소극적이지만, 현대에 들어서 세계적인 글로벌 기업인 Microsoft 최전방에서 이끌었던 리더가 되었습니다. 과연 어떻게 내향적인 빌 게이츠가 세계적인 리더가 되었을 까요?

여러분들이 잘 아는 '주의력 결핍증'은 주의가 산만하며, 점차적으로 폭력적으로 변하는 사회적으로 문제가 되는 병 중의 하나 입니다. 주의력 결핍증은 외적으로 도를 넘어선 외향성을 보이며, 잠시도 가만히 있질 못하고 주위가 산만하며, 사회적으로 적응력이 부족한 사람이라는 인식이 강합니다.

주의력 결핍증의 대표적인 인물은 누구일까요? 바로 토마스 에디슨(Thomas Alva Edison) 입니다. 어떻게 주의력 결핍증인 에디슨이 높은 집중력을 요구하는 과학계에서 역사에 남는 과학자가 되었을까요?

주의력 결핍증은 매우 사회적으로 심각한 정신병에 해당되지만, 실제로는 그렇지 않습니다. 단지 사회적인 관념과 반대될 뿐이지만, 개인적인 능력을 발휘하기에 매우 훌륭한 병이 '주의력 결핍증'입니다. 주의력 결핍증은 평소 관심의 대상을 쉽게 실증 내며 주위가 산만하지만, 자신에게 관심이 있는 부분에서는 매우 놀라는 집중력을 보여줍니다.

조금은 다르지만, 자폐적인 증상을 보였던 빌 게이츠가 어렸을 땐 사회적으로 곱지 않은 시선인 '자폐증' 의심 증상의 아이였지만, 지금은 이미 세계적으로 이름을 널리 알린 인물입니다. 어려서 컴퓨터 프로그래밍을 즐겼고, 하버드 대학 수학과에서 SAT ( 미국대학 수학능력시험) 에서 800점을 받을 정도로 영재였습니다. 여러 기종의 BASIC 언어를 만들었고, IBM 개인용 컴퓨터 시대에서 16비트 프로세서용 BASIC 과 QDOS 를 개량한 MS-DOS 운영 체제를 만든 천재 프로그래머이기도 합니다. 또한 내향적이었던 사람이지만 Microsoft 기업을 세계적인 기업으로 만들어 놓은 인물이기도 합니다.

   

개발자는 대부분 내성적인 사람이더라.

필자의 경험상 대부분의 개발이나 IT 계통의 사람들이 내성적인 성향을 띈 사람들이었습니다. 작은 모임이나 오프라인 스터디를 진행하거나 참석해본 필자로써 대부분 내향적인 사람이 대부분이었습니다. 먼저 발표를 하거나 의견을 내기 보다는 그 사람의 이야기를 듣거나, 발표를 하더라도 매우 비중이 낮기도 합니다.

외형적인 사람은 낯선 사람과 쉽게 친해지고 사교적이지만, 경험상 내향성이 높은 사람들이 더 많았던 것 같습니다.

미국에서 진행한 어떤 실험에서 '대한민국'은 매우 내향성이 강한 국가였습니다. 반대로 미국은 '외향성'이 강한 국가로써 80%가 외향적인 사람이며, 20%가 내향적인 사람이라는 놀라운 결과가 나오기도 하였습니다.

더불어, 우리 나라의 개발자는 시끄럽거나 활기찬 개발 환경을 선호하기도 하지만, 자신의 직무 분야에 집중할 수 있는 환경을 선호하기도 합니다. 주변이 시끄러운 환경에서는 업무 능률이 오르지 않고, 되려 스트레스를 받는 악영향이 미치기도 합니다.

필자 또한 예전 회사에서, 규정된 업무 시간(오후 6시) 이후에, 휘파람을 불거나 음악을 크게 틀어 놓고 일하는 사람 때문에 너무 스트레스를 받은 경험이 있습니다. 그 사람이 싫은 것이 아니라, 시끄러운 환경이 업무에 악영향을 미쳤기 때문입니다. 이런 이유 때문에 저는 이어폰의 음악 또한 꺼려했었죠. 좋아하는 음악을 이어폰으로 귀에 꼽아 보았지만 집중력을 분산시키는 것 조차 업무에 방해가 되었기 때문입니다.

반대로 하루 종일 가만히 앉아서 일하는 외향성이 높은 사람은 대부분의 사람이 퇴근한 뒤에 영화를 감상하면서 소리를 크게 틀어놓거나, 좋아하는 음악을 아랑곳하지 않고 크게 틀어놓기도 합니다. 아마도 자신의 억압된 스트레스를 푸는 방법일겁니다.

 

  

외향성

내향성

성향

적극적이다

소극적이다

환경

활기차다

조용한 것을 좋아한다

집중력

산만하다

집중력이 뛰어나다

사교성

친구가 많다

친구가 적다

사교성의 깊이

친구가 많지만, 서로 소중한 친구라고 생각하는 사람이 적다

친구가 적지만, 서로 소중한 친구라고 생각하는 삶이 많다

이해관계

말로 하거나 메신저로 하는 것이 편하다

글로 표현하는 것이 편하다

표현력

말로 적극적으로 표현한다

글로 적극적으로 표현한다

   

왜 사회는 외향적인 사람을 선호하는가?

대부분 여러분들은 면접 경험이 있을 것입니다. 특히 공채에서 강한 사람들이 외향성을 띈 사람들입니다. 반면 내향성이 강한 사람은 면접에 매우 약하기도 합니다.

이는 고등학교 실험에서도 드러납니다. 외향적인 선생님의 교육은 학생의 발표를 유도하고, 재미있는 분위기를 만들어 갑니다. 하지만 내향적인 학생은 외향적인 선생님의 지도에 매우 부담을 느낀다는 결과가 나왔습니다. 외향적인 선생님의 교육은 주변이 시끄러우며(또는 활기차며) 적극적인 발표를 유도해냅니다. 내향적인 학생에겐 선생님이 천천히 다가와 얘기를 걸 땐 말을 잘하지만, 지목해서 발표를 시킬 때 내향적인 학생은 엄청난 스트레스를 받는다고 합니다. 물론 외향적인 학생은 그런 것을 재미있어 하고 즐기겠죠.

반대로, 내향적인 선생님의 교육에서는 외향적인 학생이 매우 따분함을 느끼지만, 내향적인 학생은 교육 방식에 매우 만족하는 결과가 나왔다고 합니다.

 

외향적인 사람 : 자신을 드러내거나 알리는 것을
즐깁니다.

내향적인 사람 : 면접에서 자신의 순서가 올 때까지의
시간이 무척 긴장되며, 자신을 적극적으로 표현하는데
서툽니다.

왜 기업은 외향적인 사람을 선호하는가? 사실 필자는 내향성을 지닌 사람들에 대한 "편견"이라고 말하고 싶습니다. 이런 인간의 성향은 외적으로 판단하기 쉽지만, 내적으로 판단하기 매우 어려운 문제입니다. 그렇기 때문에 외향적인 사람을 선호하는 것 같습니다. 그리고 기업은 외향적으로 대인관계가 좋은 사람에게 부족한 지식을 가르치는 비용은 적지만, 내향적인 소극적 사람의 지식이 높아도, 대인관계나 성향을 바꾸는데 높은 비용이 들기 때문이라고 하기도 합니다.

그래서 내향성이 높은 사람이 살아가기 힘든 사회이기도 합니다. 재미있는 결과 중에 회사에서 "내향적"인 사람들이 "외향적"인 사람들 보다 능력이 뛰어나다고 생각한다고 합니다. 외향적인 사람은 표현을 하지만, 내향적인 사람은 그들의 이야기를 듣고 그들의 능력의 깊이를 잰다는 것이죠.

   

   

하지만 외향적이어야 한다

필자는 처음 세미나를 진행했던 것이 "온라인"을 대상으로 촬영한 세미나였습니다. 나에게 뭐라 할 사람도 없지만 손 까지 떨어 마우스가 떠는 것까지 느낄 정도로 카메라가 부담스러웠습니다. 이를 대비해, 1년 정도 혼자 동영상 강좌를 촬영했지만, 마이크와 화면 캡춰가 완료되는 순간 식은 땀이 줄줄 흘러 내렸습니다. 큰 연습의 성과가 없었던 거죠^^;

많은 글로벌 CEO 들은 내향적인 사람이 많지만, 내향적인 장점을 바탕으로 외향적을 극복하는 산 증인과도 같습니다. 개발 실력도 중요합니다. 개발을 위해 분석하고 결론을 추론하는 것도 중요합니다. 그리고 그것을 해결하는 것이 중요합니다.

하지만 이런 여러 가지 활동에 외향적인 성격이 부족하다면 서로 간에 이해를 좁히는 것에는 실패할 것입니다. 많은 글로벌 CEO 들이 내향적이지만 외향적으로 노력을 했기 때문에 성공한 사례라고 할 수 있습니다.

서울과학고등학교의 성향 측정 결과, 일반 고등학생들보다 정보의 자각 능력과 분석, 관찰 능력이 뛰어나다고 합니다. 그만큼 영재의 성향은 내향적인 경우가 많다고 합니다.

성향의 평균 60~70%는 선천적이지만, 20~30%는 후천적으로 성향이 형성된다고 합니다. 그래서 기존의 자신의 성향을 바꾸는 것은 매우 힘들고, 그런 사례 또한 매우 적습니다. 내향성의 특징인 높은 집중력과 분석력이 장점이지만, 이것을 공유하고 개선하고자 하는 의지가 없다면 내향적인 성향은 조직과 팀에서 의미가 없기 때문입니다.

조직과 사회는 외향성을 원합니다. 이것을 바꾸는 것은 매우 힘들지만, 분명 당신에게는 도움이 될 수 있는 노력임은 틀림이 없습니다. 다른 사람들이 알아 주길 기대하지 마시고, 스스로의 노력이 자신을 알아보고 허들을 넘을 수 있는 중요한 것임을 분명히 기억하시기 바랍니다.

누군가 자신의 실력을 알아주고 떡 하나 더 주길 기다리는 사람은 감 나무에서 감이 떨어지길 기다리는 곰과도 같습니다. 분명 내향성이 높은 사람에게 주어지는 이점이 있으나, 그 이점을 활용하기 위해서는 외향성의 비중이 필요합니다. 반드시 외향성이 필요한 것은 아니지만, 내향성의 단점을 슬기롭게 극복하는 것은 앞으로 한 걸음을 도약하는데 내향성의 사람에게 주어진 과제가 아닐까 생각합니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 망벨 2010.09.29 12:06 Address Modify/Delete Reply

    재미있는 글입니다. 뭐 저도 개발 회사에 있다보니 주변 사람들을 많이 보지만 내향적인 사람들이 많더군요. 하지만 꼭 그사람의 성향이 개발실력에 영향을 미치는 것은 아니라고 봅니다. 하지만 회사생활을 함에 있어 분명 외향적인 성향은 필요하지요. 좋은 의도의 글 잘 읽었습니다.

테스트 계획

테스트 계획은 테스트 작업을 시작하기 위한 가장 기초적인 명세서입니다. 테스트를 어떻게 진행하고 어떻게 결함을 발견할 것인지 계획을 갖고 테스트에 진입하는 것이죠. 테스트 계획 없이 테스트를 한다는 것은 아키텍처 없이 머리 속의 청사진으로 프로그램을 코드를 짜는 것과 마찬가지입니다. 그만큼 테스트 계획은 테스트에 있어서 첫 발을 내 딛는 중요한 작업입니다.    

테스트 계획은 좋은 소프트웨어의 첫 걸음

아마 독자 여러분들 중에 개발 프로젝트를 한 두 번쯤 리딩(Leading) 해 보신 경험이 있다면 아실 겁니다. 좋은 설계과 좋은 계획만으로 좋은 소프트웨어가 나오는 것이 아니라는 것을…. 물론 좋은 소프트웨어를 위해 밑거름이 바로 계획입니다. 그리고 계획이 좋거나 나쁘다고 해서, 소프트웨어의 품질과 직결되는 문제는 아닐 수도 있습니다.

실제로 엉터리 계획을 가지고 소프트웨어를 만들어도, 정말 잘 되는 케이스(대외적으로)도 많습니다. 심지어 계획 없이 시작한 프로젝트도 좋은 소프트웨어(절대적으로 좋다는 것은 아닙니다)가 나올 수 도 있습니다. 반대로 아주 철저한 계획을 가지고 시작하더라도 소프트웨어의 품질이 엉망이기도 합니다.

최근 애자일(Agile) 방법론은, 설계 단계를 코딩(Coding) 으로 대체하기도 합니다. 계획 자체가 불필요한 산출물로 직결되는 경향이 많기 때문에, 바로 최종 산출물을 코드(Code) 로 바라보는 매우 간결한 방법론입니다. 그리고 설계 단계를 뛰어넘음으로써 발생하는 여러 가지 문제를 XP(eXtreme Programming) 에서 애자일 선언문 중 12가지 원칙으로 커버를 하고자 합니다.  

깜놀~ MSDN 에서 애자일 방법론에 대한 설명이 있네요. (MSF v5.0과 관련된)
http://msdn.microsoft.com/ko-kr/library/dd997578.aspx   하지만 실제 현실에서는 어떤 특정한 계획 작업이 반드시 필요한 경우에 대부분입니다. 왜냐하면 지속적으로 소프트웨어가 운영되기 위해서는 과거의 이력이 쓸모 없기 보다는 적어도 필요 있는 경우가 대부분입니다. 설령 이력 관리가 되지 않은 문서라도 말입니다.   고객사의 소프트웨어의 산출물은 왜 관리가 안되는가?
몇 번의 컨설팅에 참여한 경험으로, 고객사의 산출물이 제대로 관리가 되지 않은 곳이 대부분이었습니다. 컨설팅을 수행하기 위해서 낯선 소프트웨어의 구조를 알기 위해, 산출물을 검토하면 실제로 현재와 다른 아키텍처나 구조를 가지고 있는 경우가 허다합니다.

왜 현재의 소프트웨어와 산출물이 일치하지 않는가에 대한 물음을 가질 수 있습니다. 산출물이 업데이트가 되지 않은 과거의 산출물이라면 특히 아키텍처나 구조를 파악하기 힘들 수 있거든요.

하지만, 굳이 산출물이 업데이트 되지 않더라도 누구를 탓할 수 있는 노릇은 아닙니다. 왜냐하면 업데이트가 되지 않은 산출물이라도 그 시대적인 배경과 당시의 이슈 등에 대해서 충분히 검토가 가능하기 때문입니다. 산출물이 업데이트 되지 않는 것은 무의미한 산출물이라고 말하는 사람들도 있지만, 꼭 나쁜 것은 아닙니다. 오히려 업데이트 되지 않은 산출물이 그 조직의 프로세스나 조직 구조를 파악하는데 더 도움이 되기도 하기 때문입니다.

테스트 계획, 어떻게 세워야 하나?

만약, 당신에게 소프트웨어의 특정 컴포넌트를 테스트를 해야 한다면, 바로 테스트의 계획을 어떻게 시작하냐 입니다. 필자의 생각으로는 개발보다 더 중요한 것이 바로 테스트라고 생각합니다. 잘못된 코딩을 검증할 수 있는 방법이 바로 테스트이기 때문입니다. 코드적인 오류나 비즈니스 프로세스적인 오류, 기술적인 오류 등 다양한 개발 코드에 잠재적인 오류가 내포되어 있습니다. 그것을 찾아내고 올바르게 검증하는 단계가 바로 테스트 단계입니다.

즉, 테스트를 하기 위한 목적과 목표가 뚜렸해야 합니다. 테스트 케이스는 테스트를 진행한 테스터(SDET) 에 의해 명확한 비전을 제시하며, 커뮤니케이션을 증진할 수 있습니다. 그렇기 때문에 테스트 케이스가 없는 테스트는 커뮤니케이션을 포기한 테스트와 다름 없습니다.

그럼 다음과 같은 단계로 테스트 계획을 진행할 수 있습니다.

  • 테스트 이름
    한 문장에 테스트에 대한 모든 요약 내용을 함축할 수 있어야 합니다.
  • 테스트 문제
    테스트 이름에 대한 설명입니다. 예를 들어, Stack Overflow 가 발생할 수 있다는 추측이나 테스트 목표를 서술합니다.
  • 분석
    개발자와 테스터의 업무는 전혀 다릅니다. 개발자는 문제 발생에 간과하여 넘어가는 경향이 있지만, 테스터는 그 문제를 밝혀내는 업무를 수행합니다. 문제가 되는 부분에 대해 왜 문제가 되는지 정곡을 찌르는 설명이나 추측을 서술합니다.
  • 설계
    실제 테스트가 수행될 경우, 어떤 파라메터와 결과 기대값을 갖는지에 대한 서술입니다. 테스트를 실제로 진행하게 될 과정을 서술하면 됩니다.
  • 오라클
    예상되는 결과에 대한 설명입니다. 즉, 설계 단계에서 왜 결과가 이렇게 나오게 될지에 대한 서술입니다.
  • 예제
    왜 결과 값이 이렇게 나오는지에 대한 예제나 코드 등을 나열하면 됩니다.
  • 함정과 계약
    예를 들면, 테스트에 사용된 파라메터가 항상 옳을 수는 없습니다. 즉, 업무 지식이 있는 사람과 없는 사람간에 테스트를 진행할 경우 테스트 결과에 대한 오차를 서술합니다. 왜냐하면 테스트 계획을 테스터와 비즈니스 업무 분석가 간에 시각 차이가 있을 수 있기 때문입니다.
  • 관련된 패턴
    이전에 말씀 드렸다시피 테스팅 패턴을 다양합니다. 어떤 테스팅 기법의 패턴으로 접근했는지에 대한 요약입니다.

위와 같이 테스트 계획을 수립할 수 있습니다. 하지만, 간결한 프로세스를 위해 몇 가지 항목은 건너뛰어도 괜찮다고 생각합니다. 필자가 테스팅 아티클을 쓰는 이유도 바로 이것 때문이죠. 우리나라 실정에 맞게 불필요 한 것은 제거하자.

필자의 경험으로 반드시 필요한 항목은 아래와 같습니다. 물론 필요한 경우 더 추가하셔도 좋습니다.

  • 테스트 이름
  • 테스트 문제
  • 함정과 계약

그렇다면 테스트 하는데 얼마나 걸리는데?

가장 민감한 사항입니다. 개발된 코드를 이용하여 테스트를 진행하는데 얼마만큼의 시간이 소요되는지에 대한 추정은 테스팅을 도입함에 있어서 비용과 직결되는 민감한 부분입니다. 왜 테스트를 진행해야 하는지조차 불분명하다면 차라리 전통적인 방법(수직적인 개발 방법론) 의 가장 마지막 단계에서 진행하는 것과 별반 다를 것이 없기 때문입니다.

개발자(SDE)가 자신의 코드를 테스트 하는 것과, 테스터(SDET) 가 테스트하는 것과 품질의 차이가 없다면 정말 테스트는 불품 없는 작업이기도 합니다. 하지만 분명한 것은 개발자의 시각과 테스터의 시각은 현저하게 다릅니다. 예를 들어, 개발자는 '사용자'가 이런 어처구니 없는 값을 입력하지 않을 거라고 단정하고 개발을 하지만, 테스터는 그렇지 않기 때문이죠. 이해하시죵? ^^

일반적으로 Microsoft 에서는 개발과 테스트의 시간을 1:1 로 봅니다. 즉, 개발 시간이 3시간이 걸리면, 테스트 시간도 3시간으로 예측합니다. 테스트에 소비되는 시간은 고객이 사용하는 소프트웨어의 결함에 대한 불쾌지수와 다름이 없습니다. 테스트가 적절한 패턴으로 정합적으로 수행되었다면, 그만큼 잠재적인 결함과 버그도 줄어들 것입니다.    

테스트 산출물이 필요하다.

테스터(SDET) 가 테스트를 수행했더라도 잠재되어 있는 결함이나 버그는 여전할 수 있습니다. 테스트 패턴이 잘못된 접근법이나 방법을 사용했다면 잠재적인 치명적인 결함이나 버그로 이어질 수 있기 때문입니다. 그래서 특히 테스트에 대한 산출물이 테스터에게는 방어적이고 효율적인 수단이 될 수 있습니다.

가장 기본적으로 테스트는 코드의 모든 부분을 검증해야 합니다. 입력 값이 잘되었든, 잘못되었든 말이죠. 그리고 그 결과를 이력으로 저장하여 지속적으로 테스트의 검증이 올바르거나 효과적으로 진행되었다는 것도 기록이 필요합니다.

즉, 테스트를 진행해서 뭐가 좋아 졌는지의 수치적인 측정이 필요합니다.

  • 테스트 결과
  • 코드 커버러지
  • 스펙 종료 상태
  • 결함율 추이
  • 성능 테스트 결과

위의 항목에 대해서는 차근 차근 알아볼 예정입니다. 특히 주의할 사항은, 코드 커버러지가 100% 라도 테스트가 완전히 완료된 것은 아니라는 것입니다. 차후에 테스트 패턴에 대해서 알아보면서 다룰 예정입니다. 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

샘플 프로그램으로 시작해보자고!!

아주 간단한 Windows Forms 어플리케이션을 작성해 보았습니다. 실제로 실무에서는 이렇게 간단한 프로그램을 만드는 개발자도 없겠지만, 아주 간단한 것 부터 시작하여 테스트의 필요성과 테스터의 역할이 얼마나 중요한지 알 수 있는 시간이 되길 바랍니다.    

아래의 윈폼 어플리케이션은 숫자A와 숫자B 를 더하여 결과를 보여주는 프로그램입니다. 아래와 같이 간단하게 디자인을 하였습니다.

   

소스 코드는 더할나위 없이 간단합니다. 특별한 설명은 하지 않겠습니다.

이 프로그램으로 1과 2 값을 입력하면 당연히 3이라는 결과가 출력되어야 합니다 아래와 같이 말이죠.

프로그램이 완벽하지요?? 정말일까요?? 특히 프로그램을 개발하는 개발자의 시각은 테스터와 매우 다릅니다. 일반적으로 개발자에게 스팩(Spec)을 구현하는 명세서가 전달이 됩니다. 아래는 간단한 구현 명세서 입니다. (단, 화면 명세서가 아닙니다)

   

구현 명세서

제목

두 숫자를 입력 받고 합을 구하는 기능

기능

1. 테스트 박스 1에 숫자를 입력할 수 있다.
2. 텍스트 박스 2에 숫자를 입력할 수 있다.
3. 새로운 텍스트 박스에 텍스트 박스 1과 텍스트 박스 2의 합을 출력한다.

   

테스터(SDET) 의 힘이 발휘되는 순간!

개발자는 위의 명세서를 보고 두 숫자를 입력 받아 출력하는 프로그램을 아래와 같이 구현합니다.

사실상 동작에 아무런 문제점이 없지만, 테스터의 시각에서는 전혀 다릅니다. (물론 구현 명세서가 부정확하긴 합니다) 즉 숫자의 입력 범위가 매우 불확실합니다. 정수만 입력되는 Integer 값인지, 32Bit 부동 소수점을 표현하는 Float 인지 아무런 정보가 없기 때문이겠지요.

테스터는 바로 버그를 발생시킬 수 있는 프로그램의 코드나 사용성에 대해 즉각 테스트를 수행합니다. 개발 소스 코드가 제공이 된다면 해결 방안까지 제시할 수 있겠지만, 그렇지 않는다면 오로지 테스터의 경험과 실력에 의존할 수 밖에 없습니다. 그렇기 때문에 SDET 는 개발자(SDE) 와 동등한 기술 능력을 갖추거나 그 이상의 능력을 필요로 하게 됩니다.

위의 간단한 프로그램을 테스트하기 위해서는 SDET 는 테스트 케이스(Test Case) 를 작성합니다. 테스트 케이스(Test Case) 를 작성하는 목적은 기능이 올바르게 동작한다는 가정하에 잠재적인 버그(Bug) 를 유도하는 작업입니다. 그리고 테스트 케이스에 대해서는 차후에 자세히 다루도록 하겠습니다.

만약, SDET 가 아래와 같은 값을 입력했다면 어떻게 될까요? 즉시 프로그램은 오류를 뱉고 말 것입니다. 아래와 같이 말이죠.

   

물론, SDET 는 소프트웨어 버전이 매번 릴리즈 될 때마다 위와 같이 무식하게 수동 테스트(Manual Test) 를 수행하지 않을 것입니다. 이 수동 테스트를 개선하기 위해 자동화 테스트를 수행할 것이며, 이 부분 또한 차후에 설명할 예정입니다. 간단히 설명하자면 반복적으로 테스트를 수행한 가치나 목적이 있다는 자동화 테스트 대상이 될 수 있습니다.

위의 무식한 테스트 과정을 자동화 하기 위해 단위 테스트(Unit Test) 를 사용하여 아래와 같이 작성할 수 있습니다. (아래의 UI 테스트와 관련된 부분이며 마찬가지로 차후에 상세히 설명할 예정입니다, 단, 자동화 테스트 이외의 비기능 테스트가 무식하다는 것은 아닙니다.)

   

이 테스트는 아쉽지만, 무자비하게 오류를 발생합니다. 프로그램 소스 코드의 int.Parse 는 정수 값만 변환 가능하므로, 소수점이 포함된 "1.1" 값은 FormatException 을 발생하게 됩니다.

이런 결함에 대한 버그 리포트를 개발자에게 할당하게 되면, 아마도 아래와 같이 프로그램의 소스 코드가 int.Parse 에서 float.Parse 로 변경될 수 도 있겠지요.

위와 같이 코드를 수정하면 프로그램을 정상적으로 동적을 합니다. 아래와 같이 말이죠^^

   

정말 버그가 해결된 것일까?

FormatException 에 대해 SDET 가 테스트한 테스트 코드를 통해 개발자(SDE) 가 코드를 수정하였습니다. 그리고 원하는 테스트는 다행스럽게도 통과(Pass) 했습니다.

   

모든 소프트웨어는 그 품질을 향상하기 위해 테스트를 진행합니다. 하지만, 버그가 없는 소프트웨어란 있을 수가 없습니다. 위와 같은 다행스럽게 SDET 가 버그나 결함을 발견하였더라도 앞으로 발견될 잠재적인 버그는 언제나 소프트웨어가 내포하고 있습니다. 즉, 완벽한 소프트웨어는 없다는 것이지요. SDET 는 이러한 버그와 잠재적인 버그를 효과적으로 발견 해야하는 매우 중대한 업무를 수행하는 직군입니다.

현대의 소프트웨어는 인터넷의 발달로, 언제나 제작사에게 피드백을 건의하고 버그를 건의하는 시스템이 구축이 되어 있습니다. 그 중 Microsoft 의 대표적인 것이 아래와 같습니다.

  • CEIP(Customer Experience Improvement Program)

    고객 또는 사용자의 동의하에 고객 경험 개선 프로그램에 참여할 수 있습니다. 이 정보는 고객의 피드백을 수집하기 위한 정보로 활용이 됩니다.

  • WER(Windows Error Reporting)

    Microsoft Windows 제품은 실제 매우 광범위한 영역과 자원과 비용이 할당된 제품입니다. 이 제품에서 발생하는 오류나 버그를 수집하기 위해서 WER 프로그램이 윈도우 내부에 탑재가 되어 있습니다. 이 정보를 기반으로 윈도우의 차기 버전이나 패치 버전에서 우선 순위로 할당되는 중요한 정보로 활용이 됩니다.

  • CER(Corporate Error Reporting)

    일반 고객이 아닌 기업 대상으로 소프트웨어를 사용한다면, 기업 내부에서는 오류 정보가 Microsoft 로 전송되는 것을 원치 않을 경우가 많습니다. 왜냐하면 기업의 시스템의 배치, 소프트웨어의 활동 등이 기밀 정보가 될 수 있고, 매우 조심스러운 부분이기 때문입니다. CER 은 Microsoft 로 정보가 전송되지 않고 기업 내부에서 관찰할 수 있는 프로그램입니다.

  • 스마일 전송 프로그램 : 추후에 설명할 예정입니다. 간략하게 고객이나 사용자의 감성을 데이터베이스화 하고자 하는 Microsoft 사용성 향상을 위한 프로그램 입니다.

   

개발자 보다 더 똑똑한 테스터!

위의 int.Parse 를 float.Parse 로 바꿈으로써 버그가 해결되었다고 볼 수 있습니다. 하지만 진정으로 버그가 해결되었다고 볼 수 없기도 합니다. 왜냐하면 테스트 케이스를 만족하지만 다양한 부류 집단인 '베타 테스트'에서는 전혀 다른 결과가 나올 수 도 있으니까요. 그리고 테스터는 바로 이러한 버그의 발생을 아키텍처/코드/기능적인 부분을 고려하여 버그를 유도할 수 있습니다.

만약, 유능한 SDET 라면 Float 으로 인한 결과 값 버그를 아래와 같은 테스트 케이스로 작성할 수 있습니다.

   

왜 결과 값이 당연이 1이 되어야 하지만, 1.000054 라는 황당한 값이 나왔을까요? 바로 컴퓨터의 내부 연산이 2진수로 이루어 진다는 것을 모르는 개발자나 테스트는 위와 같은 오류를 예감하지 못할 것입니다. 저 또한 제니퍼소프트의 정성태 과장님을 통해 이러한 문제를 처음 알게 되었으니까요.

정성태 과장님의 설명에 의하면,

"2진수의 소수점 표현들이 자리수에 따라서 1/2, 1/4, 1/8, 1/16, 1/32, 1/64 와 같은 식으로 표현이 되는데, 십진수 0.5 는 다행히 정확하게 1/2 에 맞아 떨어지지만, 십진수 0.6 은... 겨우 0.1 차이일 뿐인데 0.10011001100110011001 와 같은 2진수로 되어 버립니다. 근데 이것도 근사치일 뿐이지 1001 패턴이 계속 무한 반복 되어버리죠. 정밀도를 높이면 0.6 은 0.010011001100110011001100110011001100110011001100110011 로 표현이 되어버립니다."
더 자세한 내용은 http://k.daum.net/qna/view.html?qid=3wykn&aid=3xIOa 참고하세요.

만약, 이러한 문제가 회계 업무나 우주 공학에 적용이 된다면, 수억, 수십, 수 조원이 투입된 프로젝트에서 불에 뻔하듯 우주선이 폭발하거나 궤도를 이탈할 수 도 있는 심각한 문제를 발생할 수 있습니다. 실제로 이러한 문제로 일부 고객은 손해 금액에 대하여 마이크로소프트를 대상으로 법적인 대응을 한 사례도 있습니다.

Microsoft 가 이 문제를 몰라서 그랬을까요? 그렇지는 않습니다. IEEE(Institute of Electrical and Electronics Engineers) 표준으로 사용되었던 C 언어와 Pascal 언어간의 원활한 데이터 전달을 위해 C# 의 Float 도 같은 방식의 연산이 사용된 것입니다. 더 자세한 내용은 http://support.microsoft.com/kb/42980/ko 를 참고하세요.

   

그럼 어떻게 해결하나?

위와 같이 int.Parse 는 결함을 유발하기 매우 쉽지만, float.Parse 의 경우 더 깊은 이해가 필요합니다. 만약 테스트 케이스(Test Case) 가 이것을 유추하지 못한다면 얼마 되지 않아 소송에 휘말릴 수 있는 충분한 근거가 되겠지요. 만약 구현 명세서를 간파한 SDET 라면 이 수치에 대한 근거를 요구할 것이며, 테스트 과정에서 IEEE 745에 대한 테스트를 수행했을 테니까요.

현명한 테스터라면 float.Parse 의 타입을 Decimal 로 변경하기를 권장할 것입니다. Decimal 은 부동 소수점의 오류나 반올림에 대한 이슈를 해결할 수 있는 구조체(Struct) 입니다. 즉, 아래와 같은 구현이 회계 업무에 버그가 없는 코드가 될 것입니다.

   

테스터의 역할

테스터(SDET) 는 위의 간단한 예시와 같이 다양한 테스트를 진행하는 역할을 수행합니다. 그리고 그 역할이 매우 단순하고 초보 개발자가 수행할 수 있는 단순한 작업이 아님을 알 수 있습니다.

테스트 케이스(Test Case) 를 만들고, 다양한 테스트 시나리오를 계획하는 테스트 계획(Test Planning) 을 함으로서 소프트웨어의 잠재적인 버그를 하나씩 제거하는 매우 막중한 임무를 수행하는 직군입니다. 그리고 SDET 의 역할이 개발자(SDE) 의 코드적인 목적을 정확하게 간파하지 못하거나, 제품 전체적인 아키텍처, 프로세스를 이해하지 못한다면 더욱 더 많은 문제에 봉착하게 됩니다.

본 회에서 SDET 가 가지는 역할을 강조하기 위한 것이며, 추후에 테스트를 수행하기 위한 공학적인 기법에 대해서 차근 차근 알아보도록 할 예정입니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 지송 2010.08.06 15:47 Address Modify/Delete Reply

    잘보고 갑니다. float 연산관련해서는 글보고 처음 알았네요.

    다음에 또 들리겠습니다. 더운 여름 잘 보내세요.

 

저희 "한국 Visual Studio 공식 " 에서 세미나를 주최합니다.

 

저희 "한국 Visual Studio 공식 " 온라인 블로그(http://vsts2010.net) 통해 다양한 분야의 전문가들이 활동하고 있습니다. 그리고 동안 저희 팀원들은 다양한 세미나 경험을 바탕으로 많은 강사진을 구축하였습니다. 경험을 바탕으로 저희 팀에서 주최하는 세미나를 진행하게 되었습니다.

 

다가오는 2010/08/28일에 Visual Studio Camp #1 진행하오니 많은 성원 부탁 드립니다.

 

 

 

세미나 등록은 아래의 링크를 통해 신청할 있습니다.

http://onoffmix.com/event/1676

 

 

 


Visual Studio Camp #1

- 주최 : 한국 Visual Studio 공식 팀
- 일시 : 2010년 8 28 토요일 오후 1:30~5
- 장소 : 타임 교육 센터
- 참가비 : 무료


세미나 아젠다

 

Native 트랙

.NET 트랙

Enterprise 트랙

14:00 ~ 14:50

Visual Studio 2010 : C++0x와 Windows 7

 

 

 

최성기

그것이 알고싶다 - C# 4.0의 변화, 그 진실은 무엇인가. 희망인가? 또 다른 혼란인가?

 

강보람 C# MVP

VS Team Foundation Server 2010 의 새로운 변화

 

 

김병진 Team System MVP

15:00 ~ 15:50

비주얼 스튜디오 2010 의 Concurrency Runtime 을 이용한 멀티 코어 제대로 활용하기

 

임준환

좋은 프레임워크 있으면 소개시켜줘 - ASP.NET MVC

 

 

 

박세식

소프트웨어 품질 향상을 위한 다양한 테스트 기법

 

 

 

엄준일 Team System MVP

16:00 ~ 16:50

DirectX11 을 기다리며...

 

 

조진현

Beginnig WCF

 

 

오태겸

SharePoint 2010 Enterprise 솔루션 개발

 

정홍주 SQL Server MVP

 




발표 내용 소개
Native 트랙 Visual Studio 2010 : C++0x와 Windows 7
동안 .NET 영역으로 적잖이 편중되었던 Visual Studio의 버전업에 비해 이번 2010 버전에서는 Native Code 개발환경에서도 많은 변화가 찾아왔다. C++0x 표준 반영에 의한 문법의 변화, 새로운 라이브러리 제공(Concurrency Runtime Library), Windows 7의 최신 기능들을 제어하기 위한 SDK의 업데이트 등이 그것이다. 본 세션을 통해 C++의 문법적인 변화와 Windows 7 기능 구현을 위한 SDK의 업데이트 사항들을 정리해본다.

비주얼 스튜디오 2010 의 Concurrency Runtime 을 이용한 멀티 코어 제대로 활용하기
요즘 가정의 PC 에 멀티 코어 프로세서가 많이 보급되어 있습니다. 하지만 실제로 PC 에 설치된 코어들을 모두 사용하는 애플리케이션들은 많지 않습니다. 이렇게 낭비되는 자원을 C++ 개발자가 쉽게 사용할 수 있도록 도와주는 Concurrency Runtime 을 비주얼 스튜디오 2010에서 제공합니다. 이 Concurrency Runtime 을 어떻게 시작해야 할지 알아보겠습니다.

DirectX11 을 기다리며...
조금씩 정보가 공개되면서 많은 변화를 예고하고 있는 DirectX11 에 대해서 살펴 볼 것입니다. 특히나 Tessellation, DirectCompute, Multi-threading 을 위한 기본 개념과 작업들에 대해서 체크해 볼 것입니다.
.NET 트랙 그것이 알고싶다 - C# 4.0의 변화, 그 진실은 무엇인가. 희망인가? 또 다른 혼란인가?
PDC 2008에 울려 퍼진 C# 4.0의 소식. 그 소식을 듣고 많은 사람들은 기대와 혼란을 가지게 되었다. C#은 분명히 정적 언어인데, 동적 언어에나 있을 법한 기능을 추가한다니? 이제 와서 뒷북일 수도 있는 C# 4.0의 변화에 대한 진실, 그 마지막 시리즈가 이제 시작된다. :)

좋은 프레임워크 있으면 소개시켜줘 - ASP.NET MVC
동안 아주 미묘하게 아쉬웠던 ASP.NET. 가려운 곳을 긁어줄 대안의 프레임워크가 나타났다. 웹 개발자들 한테 참~ 좋은데, 웹 개발자들 한테 정말 좋은데, 이걸 말로 그냥 할 수 없어서, 이번 기회에 소개한다.

Beginnig WCF
WCF는 서비스 지향 프로그래밍을 위해 마이크로소프트에서 개발 및 지원하는 기반 기술이며, 기존의 .NET 웹 서비스에 비해 유연성과 확장성이 뛰어나 최근 많은 관심을 받고 있습니다. 본 세션에서는 WCF가 무엇인지? 어떤 장점이 있는지? 그리고, WCF 를 이용하기 위해선 무엇이 필요한지? 에 대해 함께 알아보고, 마지막으로, WCF의 활용 예를 알아보도록 하겠습니다.
Enterprise 트랙 VS Team Foundation Server 2010 의 새로운 변화
Visual Studio Team Foundation Server 2010의 혁신적인 변화와 개선 부분, 프로젝트 및 형상관리와 Agile의 Scrum 을 이용한 방법론을 알아보고, 단지 소스 체크인/아웃만 하는 Visual Source Safe에서 업그레이드 하는 방법에 대하여 알아봅니다.

소프트웨어 품질 향상을 위한 다양한 테스트 기법
소프트웨어는 개발 및 릴리즈 과정까지 수 많은 과정을 겪는데, 소프트웨어가 점진적으로 진화함에 따라 결함의 발생률이 증가합니다. 이를 개선하기 위한 테스트 기법 단위 테스트, WhiteBox 테스트, 화면 테스트, 성능 테스트, 부하 테스트 다양한 테스트 기법을 알아봅니다.

SharePoint 2010 Enterprise 솔루션 개발
SharePoint 2010은 기업 협업 플랫폼으로 개발자들은 VS 2010을 이용하여 더 생산성 있고 효과적인 SharePoint 2010 개발을 진행할 수 있습니다. 본 세션에서는 SharePoint 2010 개발에 대한 가장 필요한 내용을 구체적으로 알아보며 이를 통해 가장 많은 요구사항에 대한 실무 솔루션을 구성하는 방법에 대한 내용을 알아보겠습니다.



발표자 소개
Native 트랙 최성기 / Visual Studio 공식 팀
엔씨소프트에서 온라인 게임 서버를 개발하고 있으며, 비주얼 스튜디오 2010 공식 팀 블로그 (http://vsts2010.net) 에서 MFC와 윈도우7 카테고리를 맡아 스터디를 하고 있다. 최근 UX 시장의 핫이슈인 ‘멀티터치’에 대해 많은 관심을 갖고 있다.
임준환 / Visual Studio 공식 팀
Visual Studio 2010 공식 팀 블로그( http://vsts2010.net ) 에서 C++, 게임 관련 필자로 활동하고 있다.
조진현 / Visual Studio 공식 팀
현재
 클라이언트 게임 프로그래머로써 재직 중입니다. Visual Studio 2010 공식 블로그(http://vsts2010.net에서 DirectX11 부분에서 활동 중입니다.
.NET 트랙 보람 / Visual Studio 공식 팀 시삽 / Microsoft C# MVP
Visaul Studio 공식
팀의 닷넷 파트 시삽을 맡고 있으며, Visual C# MVP이다. MSDN 주간 세미나, Techdays 2009, 2010 Spring, REMIX 10에 참여했으며, '그것이 알고싶다'를 2004년 부터 거의 빼놓지 않고 다 본 경력의 소유자이다. 개인 블로그 '워너비의 소프트웨어 팩토리'(http://blog.naver.com/netscout82)를 운영 중이며, 프로그래밍과 전혀 상관없는 이야기를 쓰고 있다.
박세식 / Visual Studio 공식 팀
아직까지는 꿈
많은 유부남 청년이다. 아이가 생기면 시간이 없다는 말에 몸서리 치면서 노력 중이다. Visual Studio 공식 팀 블로그에서 ASP.NET MVC 관련 포스팅을 하고 있고, 개인 블로그 sses's blog(http://sses.tistory.com)를 운영 중이다.
오태겸 / Visual Studio 공식 팀
오태겸, 현재 Hostway 에서 근무하고 있으며, 개인 블로그(
http://ruaa.tistory.com)와 Visual Studio 2010 공식 팀 블로그(http://vsts2010.net)에서 WCF 카테고리를 통해 있는 지식, 없는 지식 총 동원해가며, WCF에 관한 포스팅을 하고 있다.
Enterprise 트랙 김병진 / Visual Studio 공식 팀 시삽 / Microsoft Team System MVP / MCT
김병진 MCT/Microsoft MVP로 Visual Studio 2010 팀 블로그(
http://vsts2010.net)에서 활동하고 있으며, ALM 교육과 컨설팅을 통해 Microsoft 의 기술과 플랫폼기반의 개발과 설계 관련하여 강의과 컨설팅을 하고 있으며, 우리나라 소프트웨어 공학의 발전을 위해 열심히 노력하고 있습니다.
엄준일 / Visual Studio 공식 팀 대표 시삽 / Microsoft Team System MVP
엄준일 Microsoft Team System MVP 로 활동 하고 있으며, 개인 블로그(http://blog.powerumc.kr) 와 트위터(@powerumc) 를 통해 .NET 기술을 전파하고 있다. 그리고 Visual Studio 2010 공식 팀 블로그(http://vsts2010.net) 의 대표 시삽으로 팀 블로그와 트위터(@vsts2010) 를 운영하고 있다.
정홍주 / Visual Studio 공식 팀 / Microsoft SQL Server MVP
웹타임 교육센터에서 SQL, .NET 강의와 .NET, SharePoint 컨설팅을 하고 있다.
Microsoft SQL Server MVP 로 활동 하고 있으며 데브피아의 SQL Server 2005 시샵이다. SharePoint 2010 책을 집필하고 SharePoint 2010 관련 동영상과 미니클립을 서비스하고 있으며 현재 Visual Studio 2010 공식 팀 블로그(http://vsts2010.net) 에서 SharePoint 2010 관련 블로깅을 하고 있다. 향후 SharePoint 2010 개발 관련 여러 내용을 Open Source 할 예정이다.


오시는 길



경품 안내
Microsoft USB 키보드 3
Microsoft 무선 마우스 3
MSDN 1년 구독권 2개


후원
웹 타임 교육 센터

Posted by 땡초 POWERUMC

댓글을 달아 주세요

지난 회 차에 여러 가지 문제로 .NET 스마트클라이언트가 가진 문제점을 살펴 보았습니다. 그 중, 주된 이슈는 이미 로드된 어셈블리는 업데이트/갱신이 불가능하다는 것과, 메모리의 사용률이 지속적으로 증가한다는 문제입니다. 이러한 문제는 사내 정책적인 서버를 도입하여 해결 가능하지만, 대부분의 조직과 기업은 이러한 정책 서버를 도입하지 않는 것으로 알고 있습니다.    

이미 얘기 했다시피, 평소에도 .NET 에서 이러한 문제를 가지고 고민을 했었지만, 최근 이러한 문제가 이슈가 되었을 때 더 이상 필자 또한 방관할 수 없었습니다. 왜냐하면 "안된다!" 라는 것 자체가 .NET 의 많은 매리트를 배제한다는 의미가 될 수 있기 때문입니다. 이러한 문제로 '목숨거는' 고객이라면 차라리 '지금은 곤란하다. 조금만 기다려달라' 라는 답이 훨씬 나아 보입니다. 물론 이런 문제가 가능하다는 전제 조건으로 말입니다.

   

문제 해결 방안

일단, 몇 날 몇 일을 고민하며 생각한 끝에 아래와 같은 아키텍처링을 하게 되었습니다. 물론 최선의 방법도, 최적의 방법도 아니지만, 문제가 된다면 저에게 피드백을 주시기 바랍니다. 저 또한 짧은 지식으로 이러한 고민을 하게 되었으니 저도 많이 답답하네요^^;    

   

위의 아키텍처링은 논리적인 아키텍처입니다. 이 방법을 통해 이전 아티클을 통해 골치 아픈 .NET 어플리케이션의 메모리 릭(Memory Leak) 을 해결할 수 있을 것으로 기대합니다.

   

어플리케이션과 AppDomain 의 분리

.NET 어플리케이션은 기본적으로 하나의 프로세스(Process) 를 차지하게 됩니다. 그것이 독립 프로세스든, IEHost.DLL 또는 IEExec.EXE 든 간에 말이죠. 이 독립 프로세스는 독립적인 하나의 어셈블리에서 관장하게 됩니다. 기본적인 이 부분의 컨셉은 어플리케이션의 재시작을 방지하기 위한 방법이기도 합니다.    

기존의 어플리케이션의 프로세스와 AppDomain 을 분리함으로써 최소한으로 AppDomain 이 안전하게 언로드될 수 있는 환경을 제공하는 것입니다. 그리고 위해 AppDomain Manager 는 이것을 관장하는 최상위 Manager Layer 가 됩니다.

   

MVVM 으로 구현부와의 분리

MVVM(Model View ViewModel) 패턴의 가장 큰 특징은 View 와 ViewModel 을 분리한 것입니다. 이것을 분리함으로써 View 와 ViewModel 의 종속 관계를 완전히 해결하고, ViewModel 은 격리된 AppDomain 으로 제한함으로써 언제든지 AppDomain 이 언로드될 수 있게 합니다.    

이 부분을 구현하기 가장 이상적인 환경은 바로 WPF(Windows Presentation Foundation) 이 되겠네요.

   

Views 의 교체

MVVM 으로 구현부와의 분리를 통해 당연히 Views 는 언제든지 교체가 가능합니다. 서버/로컬에서 Views 가 교체된다면 ViewModels 을 언로드하고 새로운 Isolated AppDomain 을 생성하여 View 와 ViewModel 간에 연결하는 방법입니다.    

특히 이 통신 구간은 View 와 ViewModel 간의 Interface Contract 를 통해 크리티컬한 자원의 관리를 최소화하는 것에 있습니다. 이로써 이미 로드된 사용자 화면과 어셈블리라도 서버/로컬의 갱신이 있다면 언제든지 갈아치울 수 있는 구간입니다. 이 부분이 앞서 얘기한 .NET 스마트클라이언트의 문제를 해결할 수 있는 핵심 구간입니다.

   

업데이트 기능을 재작성

이 아키텍처링의 가장 큰 문제지만, .NET 스마트클라이언트의 NTD(No Touch Deployment) 기능을 그대로 사용할 수 없습니다. .NET 의 NTD 는 이미 실행되는 AppDomain 에 어셈블리를 로드하기 때문에 .NET 의 NTD 를 그대로 사용한다면 이 아키텍처링을 적용할 수 없습니다.

NTD 기능 뿐만 아니라, ClickOnce 의 자동 버전 감지 기능도 사용할 수 없습니다. ClickOnce 는 주기적으로 서버의 Application Manifest 를 확인하는 과정으로 새로운 버전을 감지하고 업데이트하는데, 이 기능을 그대로 사용한다면 위의 아키텍처링은 사실상 무의미하고, 결국 메모리 사용 증가는 해결할 수 없기도 합니다.

   

제한 사항

하지만 필자가 제안한 .NET 스마트클라이언트의 문제를 해결하기 위한 방법은 제한적인 방법으로 수행이 가능합니다. 물론 모든 경우라도 제안이 가능한 방법이라면 좋겠지만, .NET 의 기본 아키텍처가 해결하지 못한 이상, 필자 또한 제한적인 방법으로 .NET 스마트클라이언트의 문제점을 해결할 수 있습니다.

그 제한적인 방법의 한계는 아래와 같습니다.

  • 개발 표준을 완벽하게 MVVM 기반으로 개발되어야 한다.
  • MVVM 패턴으로 완벽하게 분리가 되어야 한다.
    • WPF 를 사용할 경우 MVVM 패턴으로만 작성되어야 한다.
    • 윈도우 폼(Windows Forms) 또는 ActiveX 컨트롤 일 경우, MVVM 로 작성할 수 없다.
    • 이 경우, View와 ViewModels 를 분리하도록 별도 프레임워크 개발이 필요하다.
  • Marshaling 을 통한 통신
    • Marshaling 은 AppDomain 간의 원격 통신을 해야 한다.
    • 원격 통신으로 인한 성능 저하
  • WPF 개발
    • Binding Expression 을 확장한 Binding Marshaling Expression(단지, 예임) 으로 바인딩을 해야 한다.
    • 원격 바인딩으로 성능 저하 예상

   

결론

필자는 .NET 어플리케이션이 업데이트될 경우 왜 반드시 최적의 방법이 어플리케이션 쉘을 재시작하느냐에 시작한 고민으로부터 시작됩니다. .NET 아키텍처를 이해못하는 것은 아니지만, 고객은 언제나 더 향상된 방법을 제안합니다. 그리고 필자는 그런 고민을 극복하고자 제안한 방법입니다.

물론 위의 아키텍처링을 효율적인 면과 성능적인 면을 더 자세히 테스트해 보아야 하겠지만, 분명한 것은 끊임없이 고객의 요청은 진화하지 퇴화하지는 않을 거라고 생각합니다.

예전에 필자는 위와 같은 문제를 문의할 때, ".NET 에서는 안된다" 라고 답했습니다. 맞아요. 안됩니다. 하지만 문득, '안되면 되게 해야지!' 라는 생각이 들더군요. 짧은 소견이지만 잘못된 부분이 있으면 언제든지 피드백 주시기 바랍니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 남정현 2010.07.20 14:12 Address Modify/Delete Reply

    좋은 글 잘 읽었습니다. 늘 그렇지만 "안되는 것을 가능하게 만드는 것"은 쉽지만, 그것을 다른 사람들에게 전달하고 공유하도록 만드는 것 (문서를 쓰는것부터 설명에 이르기까지)이 사실은 훨씬 더 어려운 작업이지 않나 생각하게 되네요. :-)

    • 땡초 POWERUMC 2010.07.20 23:26 신고 Address Modify/Delete

      오늘 뵙게 되어 너무 반가웠습니다.
      저는 사실 항상 정현님을 모티브로 본받으려고 노력하고 있답니다.^^
      언제나 겸손하시고 솔선수범해 주시는 모습..
      제 곁에 있어 주실꺼죠? ^^

    • 남정현 2010.07.28 23:53 Address Modify/Delete

      오우.. 댓글을 늦게 봤네요. =_=

      저야 말로 여러모로 앞으로 엄준일 MVP님께 많은것을 배워야 할것 같아요. 언젠가 인사드렸었지만 그래도 다시한번 잘 부탁드립니다. ㅎㅎ

  2. lancers 2010.07.21 09:07 Address Modify/Delete Reply

    어차피 별도 AppDomain을 사용하는 방법이 유일한 해결책인데,
    이 아키텍처의 착상은 나쁘지 않으나 실제로 진행하다 보면 많은 문제에 부딪칠 거야.
    지금 상황에선 예상하지 못한 문제들을 많이 겪게 될 거고..

    이론 상으로 볼 때는 이런 방향으로 가는 게 맞는데,
    실질적으로 사용자가 원하는 건 굳이 이런 방식이 아니어도 된다는 것도 알게 될 거고..

    회사 내부에서 이미 진행하고 있는 내용의 결론이 조만간 나올 듯..

    • 땡초 POWERUMC 2010.07.22 04:52 신고 Address Modify/Delete

      저도 그 많은 문제가 제가 생각하는 이상으로 많을 것 같아요.
      말씀하신 ShadowCopy 가 좀 더 현실적으로 가까운 것 같습니다.^^
      말씀해주신 힌트가 큰 도움이 되었습니다.
      ---------- Updated ----------
      다만, AppDomain 의 ShadowCopy 는 AppDomain 당 1회성이 아닐까요?
      테스트 해 보지는 않았지만, 논리적으로 본다면 AppDomain 당 ShadowCopy 폴더를 둔다는 것은 1회에 한한 제한적인 방법인 것 같습니다.
      ------------------------------

      DX 의 멋진 솔루션이 기대됩니다용^^

개요

.NET 에서 윈도우 어플리케이션을 개발해 본 독자라면 한번 쯤은 .NET 스마트클라이언트라는 용어를 많이 들어보았을 것입니다. 스마트클라이언트는 배포(Deployment), 플랫폼 독립 모델을 제공함으로써 다양한 클라이언트를 지원하는 것이 특징입니다.

예전에 필자가 UX 라는 주제로 쓴 포스트 중 "당신이 생각하는 UX 란?" 에서도 언급하였듯이, .NET 스마트클라이언트는 X-Internet 이라는 트랜드로 기술적인 부분을 초점으로 마케팅한 용어로 발전하였습니다. 이와 반대로 RIA(Rich Internet Application) 는 UX(User eXperience) 초점에서 마케팅한 용어라고 보셔도 좋습니다.

   

사전 지식

하지만 .NET 스마트클라이언트는 사실상 매번 나오는 이슈가 있습니다. 아니, 이것은 .NET 스마트클라이언트의 문제라기 보다는 .NET 자체의 아키텍처와 관련된 문제이기도 합니다.

결혼부터 말하자면, .NET 어플리케이션은 로드된 어셈블리(Loaded Assemblies) 는 언로드(Unload) 가 되지 않습니다. 간단하게 아래와 같이 .NET 어플리케이션의 모델을 보면 알 수 있습니다. .NET 어플리케이션은 하나의 AppDomain(Application Domain) 을 갖는 것을 알 수 있습니다.

   

AppDomain 은 어플리케이션 간의 CAS(Code Access Security) 라는 임계 영역에 존재하게 됩니다. 말 그대로 CAS(Code Access Security) 이 CAS는 어플리케이션간의 엑세스를 제한함으로써 신뢰할 수 없는 코드나 어플리케이션은 사용자의 컴퓨터에서 실행할 수 없도록 한 보안 모델입니다.    

즉, 이메일이나 인터넷, 사용자 그룹 및 권한 등 신원이 확인되지 않은 어플리케이션을 실행했을 때, 악의적인 목적으로 사용자의 로컬 자원을 엑세스할 수 없도록 제한하는 모델이라고 보시면 됩니다.    

이 코드 보안 모델은 .NET 의 어떤 어플리케이션이든 모두 이 보안 정책 안에 있다고 보시면 됩니다. ASP.NET 도 마찬가지로 아래와 같이 AppDomain 의 임계 영역 안에서 어플리케이션이 동작하게 됩니다. AppDomain 이 하나의 웹 어플리케이션을 동작하게 하고, HttpRuntime 에 의해 HttpContext 가 관리됩니다. 그리고 각각의 요청에 의해 HttpContext 는 별도의 스레드(Thread) 로 사용자의 요청을 응답하게 되는 구조라고 보시면 됩니다.

 예를 들어, 아래와 같은 코드 보안을 위한 선언적인 방법을 이용하여 악의적으로 사용될 수 있는 코드 쓰기, 수정 등을 할 수 없도록 합니다. 어셈블리, 클래스, 구조체, 생성자에서 사용할 수 있습니다. 물론 사용자가 이 보안 수준을 변경할 수 도 있지요.

문제 1

여태까지 이것을 말하기 위해 설명을 한 것입니다. 바로 .NET 어플리케이션은 어셈블리를 로드할 수 는 있지만, 언로드할 수 는 없습니다.

그러니까 더 자세하게 얘기하면, 아무리 가비지 컬렉션(Garbage Collection) 을 호출하고 CLR Runtime(Common Language Runtime) 이 이것을 대신 수행해 준다고 해도, 로드된 어셈블리 자체는 이 대상에서 예외라는 것입니다. 결론은 .NET 어플리케이션을 오래 쓰면 쓸 수록 메모리 사용이 증가할 가능성이 있습니다.

플러그인 모델(Plugin Model) 기반의 어플리케이션도 확장 기능이 많아지면 많아질 수록 메모리 점유율이 높아지고, 특히 엔터프라이즈 기업용 어플리케이션은 반드시 피해갈 수 없는 문제이기도 합니다.    

개인적으로 플러그인 모델과 엔터프라이즈 어플리케이션의 중간 영역이라고 생각되는 Visual Studio 를 한 1주일 정도 닫지 않고 써보셨나요? 쓰지 못할 정도는 아니지만, 괜히 버벅되고 느려지는 현상이 나타나게 된답니다.^^; 이런 현상은 Visual Studio 뿐만이 아니라 .NET 으로 작성된 모든 어플리케이션은 모두 영향을 받게 됩니다.

   

그 이유는, .NET 은 로드된 AppDomain 의 어셈블리를 언로드할 수 있는 방법을 제공해 주지 않습니다. AppDomain 이 참조하는 관계는 기본적으로 로컬 자원의 어셈블리를 참조하겠지만, 코드 베이스(Code Base-코드의 출처) 가 인트라넷이나 인터넷이라면 그 코드 베이스로부터 어셈블리를 다운로드 하게 됩니다.    

문제 2

결론부터 말하면, .NET 어플리케이션은 참조 또는 다운로드한 어셈블리는 다운로드 캐시(Download Cache) 에 보관하게 됩니다. 어셈블리를 참조 또는 다운로드하는 판정 조건은 어셈블리의 버전, 토큰 등 복잡한 과정을 거치기 때문에, 제대로 된 정책을 갖고 있지 않는다면, 이미 다운로드된 어셈블리는 다운로드 캐시로부터 어셈블리를 재사용합니다.    

그렇기 때문에, 다운로드된 어셈블리는 File Lock(파일 잠김)이 발생하므로, 동일한 파일 이름의 어셈블리를 다운로드 받는 것은 불가능 합니다. 하지만 해결책이 없는 것은 아닙니다. Assembly.Load 시리즈의 메서드에는 byte[] 로 읽을 수 있는 오버로드된 메서드가 존재하기 때문입니다.    

즉, 아래와 같이 File Lock 을 방지할 수 있습니다. 하지만 어셈블리는 로드할 수 있으나, 기존의 로드된 어셈블리를 갈아치우지는 못합니다.

 

결국, 하나의 어플리케이션을 오래 사용하면 할수록 메모리의 점유율을 증가할 수 있게 될 가능성이 큽니다. 특히 엔터프라이즈 기업용 어플리케이션은 단위 업무별로 적절한 파일 크기, 업무간의 연간 관계 등을 고려하여 어셈블리를 모듈화하는데, 사실상 메모리 사용률 증가의 문제는 여전히 해결할 수 없는 문제입니다. 그 이유는, 앞서 말했듯이 어셈블리를 언로드할 수 있는 방법은 AppDomain 을 언로드하는 것이고, AppDomain 을 언로드하면 메인 어플리케이션을 재시작해야 된다는 문제입니다.

   

문제 3

이 섹션은 문제 2와 연관된 정책적인 문제입니다. 다운로드된 어셈블리는 다시 다운로드 받을 수 없기 때문에 선행적으로 몇 가지 정책적인 강제가 필요할 수 밖에 없습니다.

  • 어플리케이션 쉘(Shell)
    • 어플리케이션 쉘이 업데이트되면 어플리케이션을 재시작 해야 한다.
  • 어플리케이션 실행 중 단위 어셈블리
    • 단위 어셈블리가 한 번 다운로드되면 서버/로컬의 어셈블리가 갱신되도 다운로드 받지 못한다.
    • 단위 어셈블리가 다운로드 되고 서버/로컬 어셈블리가 갱신되어도 알림 받을 수 없다.
    • 이럴 경우, 어플리케이션 쉘을 서버에서 갱신하여 업데이트 알림을 받을 수 있고, 어플리케이션을 재시작 해야한다.

즉, 어떠한 경우라도 갱신된 어플리케이션을 적용하기 위해서는 메인 어플리케이션 쉘을 재시작해야 한다는 결론을 얻을 수 있습니다.

   

문제 4

더욱 문제인 것은 .NET Framework 4.0 기반의 일부 스마트클라이언트는 이 문제와 상관없이 불가능합니다. 그 이유는 이미 닷넷엑스퍼트의 안재우 수석님의 블로그 중 "[.NET 4.0] IE Embedded WinForm(Smart Client) 지원 중단" 를 참고하세요.

이유의 요지는, IEHost.DLL 과 IEExec.EXE 파일이 .NET Framework 2.0 으로 강력한 이름의 서명이 되었다는 것입니다. 이것은 즉, IEHost.DLL 과 IEExec.EXE 를 통하는 .NET 스마트클라이언트의 경우 GAC(Global Assembly Cache) 를 통해 활성화가 되는데, .NET Framework 4.0 의 스마트클라이언트 어플리케이션은 어셈블리 리디렉트(Assembly Redirect)를 통하지 않고서는 이것을 활성화할 수 있는 방법이 없습니다. 어셈블리 리디렉트를 통한다고 하더라도 Dependency Assemblies 는 .NET Framework 2.0 을 바라보기 때문에 .NET Framework 4.0 의 기능을 사용한다면 절대 불가능하기도 합니다.

하지만 .NET 어셈블리의 바이트 코드 조작을 통해서 가능하긴 합니다.

  • IEHost.DLL, IEExec.exe 의 바이트 코드를 수정하여 강력한 서명을 지운다
  • IEHost.DLL, IEExec.exe 의 바이트 코드를 수정하여 .NET 4.0 으로 저장한다
  • GAC(Global Assembly Cache) 에서 IEHost.DLL 과 IEExec.EXE 를 제거한다.

어셈블리의 바이트 코드 조작은 Mono 프레임워크를 통해서 아주 쉽게 할 수 있습니다. 하지만 IEHost.DLL 과 IEExec.EXE 를 사용하는 모든 사용자 클라이언트를 해킹하는 무자비한 방법입니다. 하지만 된다는 것만으로도 만족한다면 이 방법이 최선의 방법이 될 것 같네요.

   

.NET 스마트클라이언트의 고찰

.NET 스마트클라이언트는 .NET 엔터프라이즈 어플리케이션에 많은 기여를 하였습니다. 그리고 .NET 스마트클라이언트를 사용하는 기업 또는 인트라넷 환경은 매우 많기도 합니다.    

필자 또한 얼마 전에 이러한 고민으로 Microsoft 의 의뢰를 받은 적이 있습니다. 그리고 개인적으로 아주 많이 고민했습니다.    

왜냐하면 자바의 클래스 로드(Class Loader) 는 .NET 의 스마트클라이언트와 유사한 점이 굉장히 많습니다. 하지만 다른 점이 하나 있다면, 자바의 클래스 로더는 GC(Garbage Collection) 의 대상이 된다는 것이죠. 다시 말하면, 어플리케이션의 재시작 없이 마음만 먹으면 메모리 사용률이 증가하지 않도록 아키텍처링이 가능하다는 것입니다.    

필자가 결론적으로, .NET 의 AppDomain 과 자바의 클래스 로더는 각기 특색은 있지만, 어느 것이 정답인지는 모르겠습니다. 다만, 고객이 어플리케이션의 재시작 없이 어플리케이션 업데이트/갱신이 가능해야 한다는 전제 조건이라면 자바의 클래스 로더가 장점이긴 합니다.    

하지만, 필자는 이 문제로 몇 일 동안 고민했습니다. 왜냐하면 세상에는 불가능한 것이 없다라는 것이 필자의 신념이기도 하며, 어떤 문제든 최선의 방법이라는 것이 존재한다고 믿습니다. 그리고 결국 "빙고" 를 찾았습니다. ^^

다음 회 차에서는 .NET 스마트클라이언트의 이러한 문제를 개선할 수 있는 방법을 알아보도록 하겠습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. lancers 2010.07.21 09:08 Address Modify/Delete Reply

    문제2의 File Locking 문제는 굳이 저렇게 하지 않고 Shadow Copy 기능을 쓰면 됨..

오늘 Microsoft 의 Scottgu's Blog 를 통해 WebMatrix & Razor 기술이 소개되었습니다.    

우선 간단하게 용어를 정리해봅시다.

WebMatrix

경량화한 웹 개발 도구

Razor

ASP.NET 의 뷰(View) 엔진

즉, WebMatrix&Razor 는 빠르게 웹 개발 환경을 구성하고 Razor 의 뷰(View) 엔진을 이용하여 신속하게 웹 페이지를 개발하고자 합니다. 웹 환경/웹 개발/데이터베이스/웹 개발 도구 등 WebMatrix&Razor 에 모두 포함이 되어 있습니다.

아마도 처음 웹 개발에 접하시는 분들이 처음 갖는 고민은..? 웹 환경 구성/웹 프로토콜 및 통신의 이해/호스팅 등 복잡했던 초기 작업을 매우 효과적이고 간소화하여 신속하게 작업을 진행할 수 있는 장점이 있습니다.

   

WebMatrix 란 무엇인가요?

WebMatrix 는 약 15MB 의 용량으로 빠르게 웹 개발 환경을 갖출 수 있습니다. (단, .NET Framework 4.0 이 인스톨 되지 않았을 경우 약 50MB). 현재 WebMatrix 는 Beta 버전이며 이 링크를 클릭하시면 다운로드 받으실 수 있습니다.

이 웹 WebMatrix 에는 다음의 구성 요소가 포함이 되어 있습니다.

  • IIS Express
  • SQL Compact Edition
  • ASP.NET Extensions

그리고 Visual Studio 2010 또는 Visual Web Development 2010 Express 개발 도구를 이용하여 웹 개발 또는 커스터마이징을 하실 수 있습니다.

   

WebMatrix 는 쉽게 사용할 수 있게 설계가 되었습니다.

초기 웹 개발 환경은 웹 페이지를 만들기 위해 해야 할 일들이 많았습니다. 환경 구성/개발 환경 구성 등 말이죠.

WebMatrix 는 아래와 같이 매우 심플한 디자인으로 웹 개발의 시작을 빠르고 쉽게 수행할 수 있습니다. Site from Web Gallery 는 오픈 소스 웹 어플리케이션을 바로 설치하여 사용할 수 있고, Site From Template 으로 최적화된 환경에서 개발을 시작할 수 도 있습니다.

Site From Web Gallery 는 온라인에서 인기 있는 다양한 오픈 소스 웹 어플리케이션이 포함되어 있답니다. ASP.NET, PHP 의 오픈 소스 웹 어플리케이션이 포함되어 있으며, 설치나 배포가 매우 간단합니다.


그 중, Scott 님은 BlogEngine.NET 으로 예제를 보여주시네요. BlogEngine.NET 는 이미 예전부터 CodePlex 를 통해 오픈 소스로 공개가 되고 현재도 인기 있는 블로그 웹 어플리케이션입니다.

BlogEngine.NET 을 선택하고 Next 버튼을 클릭하면 이것을 설치하기 위한 컴포넌트를 체크하거나 다운로드 받습니다. 즉, 원클릭(One-Click) 으로 어플리케이션이 동작하기 위한 모든 환경을 스스로 구성한다는 얘기죠^^

PHP 어플리케이션의 경우 WordPress, Drupal, Joomla, Sugar CRM 등은 MySQL 이 필요한데, 개별적인 설치 없이 이런 환경도 자동으로 다운로드 받아 설치를 합니다.

간단하게 소프트웨어 사용권 동의(EULA) 를 클릭하면 바로 설치와 구성 작업을 시작합니다.

   

그리고 금새 설치와 구성이 완료가 되었지요^^

   

모든 구성이 완료되면, 아래와 같은 Overview 페이지가 나타납니다.

   

설치된 BlogEngine.NET 을 실행하기 위해서 아래의 Run 버튼을 클릭합니다. 인터넷 익스플로러, 크롬, 파이어폭스로 실행할 수 있고, Open in all browsers 로 여러 브라우저로 한꺼번에 실행할 수 있습니다.

   

자! 여태까지 클릭 클릭만 했는데, 아래와 같이 BlogEngine.NET 이 설치되고, 구성되고, 모든 구성이 완료가 됩니다.

   

초기 관리자 아이디와 비밀번호는 admin/admin 입니다. 관리자로 로그인 하셔서 블로그의 이름을 달아주시고, 블로그 저자 소개 등을 입력해 주시면, 곧바로 블로그를 운영을 준비하셔도 될 것 같습니다.^^

WebMatrix 는 오픈 소스 웹 어플리케이션을 커스터마이징 할 수 있는 약간의 개발 환경도 제공해 줍니다. 아래와 같이 소스 코드를 변경할 수 도 있고, Files 버튼으로 파일을 편집하거나 추가, 삭제를 할 수 있습니다.

   

이제 블로그를 운영하기 위해 배포와 호스팅을 해야 합니다.

WebMatrix 의 특징은 매우 경량화되었고 작업 환경이 통합된 장점을 갖습니다. 로컬 또는 원격 웹 서버로 배포할 때, FTP 또는 FTP/SSL 또는 Microsoft Web Deploy(MSDeploy) 를 이용하여 쉽게 배포가 가능합니다.

아래의 Publish 버튼을 클릭하면 배포 준비가 시작됩니다.

   

배포 세팅 화면은 아래와 같습니다. 서버의 기본 정보를 입력하고, 데이터베이스의 연결 문자열을 입력한 후에, Publish 버튼을 클릭합니다.

   

모든 준비가 완료되었고, Publish 버튼을 누르면 이제 배포를 시작할 준비가 완료 되었습니다.

   

이하.. 금일 Microsoft Korea 의 김대우 과장님께서 진행하는 WebMatrix&Razor 세미나에 참석하기 위해 이만 줄입니다. 다른 분들께서 더 알차고 재미있게 포스팅 해 주시리라^^

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 드란 2010.09.03 13:56 Address Modify/Delete Reply

    툴은 vs 를 사용중이니 안부러운데.. 문법강조 색은 좋아보이네요 vs는 그냥 가끔 파랑 녹색 회색 밖에 안보여서 -_-;;
    설정하자니 귀찮고... 구글 어딘가.. 저 색들을 vs에 마춰서 올려줄것도 같은데.. 구글링도 귀찮고 ㅜㅜ;;;

지난 아티클에서 Visual Studio 2008 과 Visual Studio 2010 을 동일한 소스 코드와 프로젝트로 개발하기 위한 환경을 구성하는 방법을 알아보았습니다.

문제 원인

하지만 지난 시간에 언급한 듯이 테스트 프로젝트가 포함된 경우는 VS2008 과 VS2010 을 동시에 사용할 수 없는 문제가 발생합니다. 그 이유는 Microsoft.VisualStudio.Quality 프레임워크가 개선이 되고, Microsoft.VisualStudio.TestTools 프레임워크가 도입되면서 기존의 테스트 프레임워크와 비호환적인 부분이 존재하게 됩니다.

아래와 같이 VS2008 에서 작업한 테스트 프로젝트가 있을 경우,

지난 아티클의 방법으로 프로젝트를 변환하게 되면 아래의 오류가 발생합니다.

기존 프로젝트는 기존의 .NET Framework 버전을 그대로 사용할 수 있지만, 테스트 프로젝트는 반드시 .NET Framework 4.0 으로만 사용할 수 있습니다.

만약 하위 프레임워크 버전인 .NET Framework 3.5 로 변경하고자 할 경우 아래와 같은 오류 메시지가 나타나고, 다시 .NET Framework 4.0 버전으로 변경이 됩니다.

일부 이미 완성된 테스트 프로젝트인 경우 이것보다 더 다양한 오류 메시지를 볼 수 있습니다.^^;

어쨌든, Microsoft.VisualStudio.QualiltyTools 프레임워크가 .NET Framework 4.0 버전으로 고정되어 자칫 테스트 프로젝트가 굉장히 큰 우범을 저지를 수 있는 문제가 될 수 있습니다.

반대로 Visual Studio 2010 에서 만든 테스트 프로젝트는 .NET Framework 4.0 이 기본이고 Microsoft.VisualStudio.QualityTools 프레임워크와 Microsoft.VisualStudio.TestTools 프레임워크가 기본 참조(RTM 에서는 제외 됨)이며, 이 프레임워크의 버전도 4.0.xxxxx 버전이라 하위 버전과 호환되지 않습니다.

VS2010 이든 VS2008 이든 테스트 프로젝트가 한번 VS2010 으로 업그레이드 되었다면, VS2008 에서 테스트 프로젝트를 사용하기 위해서는 다운그레이드는 그리 쉽지 만을 않습니다. 왜냐하면 VS2008 에서 테스트 프로젝트를 로드하면 프로젝트의 참조가 깨져있습니다.

그 이유는 .csproj 파일을 열어보면 답이 나오는데요. 아예 Microsoft.VisualStudio.QualityTools 프레임워크의 버전 번호를 명시하여 해당 VS2008 에서는 어셈블리 리디렉션(Assembly Redirection) 을 시키기가 좀 애매해 집니다.

   

문제 해결 기본 지식

이 문제를 해결하기 위해서는 테스트 프로젝트간의 비 호환적인 테스트 프레임워크로 인한 문제이므로, 문제를 해결하기 위한 접근 측면에 제한을 둘 수 밖에 없습니다. Visual Studio 2010 에서는 Coded UI, Test Impact 등 새로운 기능이 추가되었고, 기존 테스트 또한 비주얼한 부분이 개선이 되면서 강제적으로 테스트 프레임워크의 버전을 .NET Framework 4 로 고정을 시키는 것 같습니다.

이 문제는 MSBuild 를 통해 해결하기 위한 기본적인 지식을 알려드립니다. 여러분이 알다시피 MSBuild 는 Microsoft 의 통합 빌드 솔루션입니다. 예전에는 "빌드"라는 말 대신 "컴파일"이라는 단어를 사용했었죠. 컴파일이란 소스 코드를 목적 파일 또는 실행 파일로 변환하는 과정을 "컴파일"이라고 합니다.

컴파일과 빌드를 비교하는 아주 간단한 그림 입니다.
컴파일은 목적은 소스 코드를 목적 파일로 변환하여 실행 파일 또는 라이브러리로 만들기 위한 목적입니다.

빌드는 컴파일의 일련의 과정을 플로우(Flow) 로 처리하여 컴파일 중에 더 많은 작업을 하기 위한 목적입니다.
가장 대표적인 빌드 솔루션이 MSBuild 이며, 이 외에 Ant 또는 NAnt 등이 바로 이러한 솔루션입니다. 그리고 Team Foundation Server 의 팀 빌드도 바로 MSBuild 에 기반하고 있다는 것입니다.

필자 또한 MSBuild 를 접하면서 나의 지식의 끝을 무한하게 확장해 주었던 것이 MSBuild 입니다. MSBuild 는 정적인 컴파일 방식에서 동적인 방식의 빌드로 거듭나면서 굉장히 많은 가능성을 보여주는 부분이기도 합니다. Microsoft 의 MSBuild 의 대략적인 구조는 아래와 같습니다.

기본적으로 MSBuild 는 Task 의 집합이라고 해도 과언이 아닙니다. 그리고 이 Task 중에 빌드와 연관된 Task 도 있습니다. 이 Task 를 .NET Framework 버전에 따라 Project References(프로젝트 참조)를 변형시키는 방법입니다.

 

해결 방법

이 테스트 프로젝트를 VS2008, VS2010 양 쪽에서 사용하도록 하기 위해서는 이 어셈블리 참조를 동적으로 변화시킬 필요가 있습니다. 이 방법도 MSBuild 의 Choose 라는 조건문으로 제어를 분기할 수 있는 방법입니다.

1. 먼저 솔루션 탐색기에서 열려 있는 프로젝트를 언로드 한 후, 편집을 클릭합니다.

2. 그럼 아래와 같이 참조와 관련되어 있는 부분이 ItemGroup 요소에 있는 것을 확인할 수 있습니다.

3. 이 ItemGroup 에서 VS2008, VS2010 에서 공통적인 참조 어셈블리를 별도의 ItemGroup 으로 분리합니다. 그럼 아래와 같은 형태가 되겠지요?

4. 테스트와 관련된 ItemGroup 에 Choose 조건 분기 요소를 사용하여 조금 변형해 봅시다. .NET Framework 의 버전 별로 말이죠.

위의 $(MSBuildBinPath) 는 실제로 빌드가 수행할 때의 MSBuild 의 경로를 나타냅니다. 하지만 여기에는 한 가지 함정이 있습니다. Visual Studio 2008 에서는 <Message Text="$(MSBuildBinPath)" /> 가 아래와 같이 C:\Windows\Microsoft.NET\Framework\v2.0.50727 로 나타납니다. 하지만 내부적으로 이 MSBuild 는 v3.5 경로의 MSBuild.exe 를 실행하게 됩니다. 자세한 이유와 내막은 Microsoft.Common.targets 파일을 뒤져보시면 아실거라고 생각합니다.

그리고 Choose 조건 분기 요소는 if ~ else 와 같은 구문입니다. ItemGroup 요소는 하나의 항목을 담는 필드라고 보시면 되고, PropertyGroup 은 한 Property 에 여러 항목을 담는 속성이라고 보시면 됩니다. 이 부분은 MSBuild 를 공부해 보시면 어렵지 않는 기본적인 부분이니 자세한 설명은 여기에서 하지 않겠습니다.

5. 모두 완료 되었습니다. 각각의 VS2008, VS2010 에서 테스트 프로젝트를 모두 사용할 수 있게 되었습니다.

만약 Coded UI 와 같은 VS2010 의 새로운 기능을 사용할 경우 아래와 같이 추가적인 어셈블리를 참조하게 됩니다.

이 경우도 위의 4번과 같이 ItemGroup 의 VS2010 용 어셈블리를 아래와 같이 넣어버리면 됩니다.

그럼 VS2008 인지 VS2010 인지에 따라서 참조 어셈블리가 완벽하게 분리가 됩니다.

하지만 VS2008 에서 빌드를 할 경우 아래와 같이 오류가 발생하게 됩니다. 당연히 VS2008 에서는 Coded UI 등에서 필요한 Microsoft.VisualStudio.TestTools 프레임워크가 존재하지 않고, 이 프레임워크를 재사용하기 힘들기 때문입니다.

하지만 이 문제로 해결해 볼까요? 위에서 Property 를 재정의한 구문이 생각나실 겁니다. 전처리 지시문의 상수 값으로 사용되는 <DefineConstants> 에 NET4.0 빌드인지, NET3.5 빌드인지 알 수 있도록 상수 값을 선언하였습니다.

이 상수 값을 이용하여 CodedUI 등 VS2010 에서 새로 추가된 부분에, #if ~ #endif 지시문을 사용하여 감싸 주시면 됩니다.

   

이제 Visual Studio 2008 이든 Visual Studio 2010 이든 테스트 프로젝트를 양 쪽 어떤 도구를 사용하든 테스트가 가능하도록 구성하는 방법을 완료하였습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. file recovery software 2010.07.06 14:15 Address Modify/Delete Reply

    이건 정말 좋은하고 유용한 정보를 비주얼 스튜디오 2008비주얼 스튜디오 2010에 대한 기사입니다

  2. 박진혁 2010.10.19 14:30 Address Modify/Delete Reply

    우와..고민하고 있던것을..감사합니다!!^^

6월 1일 REMIX10 행사를 기점으로 Visual Studio 2010 한글판이 대중에 공개가 되었습니다. Visual Studio 2010 의 영문 버전은 그 이전에 출시가 되었지만 한글판이 출시된 이후에 더 많은 관심을 받게 되었습니다.

Visual Studio 2010 으로 개발 환경을 업그레이드를 진행하는 곳이 특히 해외에서 많습니다. 제가 그걸 어떻게 다 아냐구요? 항상 트위터 검색을 통해 해외에서 Visual Studio 2010 를 어떻게 사용하고 있는지 매일 매일 관심 있게 보고 있답니다. ^^

어쨌든 Visual Studio 2008 을 쓰고 있지만, Microsoft MVP 이거나 회사에서 MSDN Subscription 라이선스가 있다면 Visual Studio 2008, Visual Studio 2010 개발 도구가 혼합해서 사용될 경우가 있습니다. 이런 경우 두 개발 도구에서 쌍방 개발 가능하게 구성을 할 수 있습니다.

이 방법은 제니퍼소프트의 정성태 과장님의 블로그에서 예전에 소개했던 VS2005, VS2008 혼합해서 사용하는 방법과 동일합니다.

1. 간단한 예제로 Console Application 을 Visual Studio 2008 에서 생성했습니다.

   

2. 기존의 솔루션 파일의 복사본을 하나 만듭니다.

   

3. 솔루션 파일을 노트패드로 ConsoleApplication - VS2010.sln 파일을 열어 다음의 항목을 수정합니다.

   

4. 프로젝트 파일을 열어 ToolsVersion 의 '3.5' 를 '4.0' 으로 수정합니다. 'ConsoleApplication1.csproj'

  

만약 다수의 프로젝트일 경우, 위의 3번에서 수정한 솔루션 파일을 열면 프로젝트를 변환하는 마법사로 진행하면 쉽게 변경이 됩니다.

   

5. 모두 완료 되었습니다. Visual Studio 2010 와 Visual Studio 2008 에서 각각의 솔루션 파일로 동시에 작업을 할 수 있습니다.

   

위의 방법을 이용하여 Visual Studio 2008 과 Visual Studio 2010 에도 모두 개발이 가능합니다. 하지만 만약 테스트 프로젝트가 포함이 되어 있다면 두 개발 도구에서 사용할 수 없습니다. 왜냐하면 .NET Framework 4.0 에서는 테스트와 관련된 Microsoft.VisualStudio.Quality 프레임워크가 개선되고, Microsoft.VisualStudio.TestTools 프레임워크가 추가되면서 이전 Visual Studio 2008 과 프로젝트가 호환이 되지 않습니다.    

하지만 불가능할 것 같은 테스트 프로젝트도 Visual Studio 2008과 Visual Studio 2010에서 동시에 사용할 수 있는 방법이 있습니다. 이것은 다음에 알아보도록 하겠습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 2013.05.12 17:35 Address Modify/Delete Reply

    비밀댓글입니다

문제 발생

SCVMM 에서 Install Virtual Guest Services(가상 게스트 서비스 설치) 작업 시 2941 오류가 나는 경우가 발생 합니다..

해결 방법 1

이 문제는 HTTP 통신 (80, 443 포트) 가 방화벽으로 제한된 경우에 발생합니다.
본 문제로 아래의 URL 을 통해 문제가 해결되지 않는 경우가 발생합니다.
http://srvcore.wordpress.com/2010/04/11/error-2941-when-moving-vms-accross-hyper-v-servers/

해결 방법 2

이 문제를 해결하기 위해 여러 가지 방법을 수행해 보았으나, 아래의 작업으로 해결되지 않았습니다.

  • 가상 네트워크 삭제 및 재설정
  • 네트워크 위치(Network Location) 삭제 및 재설정

아무리 생각해 봐도, 방화벽, WS-Management 서비스 및 네트워크 문제가 발생할 소지가 없음에도, 제대로 기능이 실행되지 않았습니다.

이 경우 Active Directory 기반의 호스트를 제거한 후, 다시 호스트를 추가하고, 다시 Install Virtual Guest Services(가상 게스트 서비스 설치) 작업을 시작합니다.

아래와 같이 올바르게 작업이 진행된다.

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

SharePoint 2010 Beta 버전은 아쉽게도 SharePoint 2010 RTM 버전으로 마이그레이션을 할 수 없습니다. Microsoft 에서도 이 버전의 Beta 를 RTM 으로 공식적으로 지원하지 않는다고 합니다.

저처럼 SharePoint 2010 Beta 버전이 Go-Live 로 알고 있었던 분이라면 좀 난감하겠네요, Beta 버전을 삭제하는 방법이 아마도 가장 빠른 방법일 겁니다. 하지만 인터넷을 찾아보시면 강제로 Beta to RTM 으로 마이그레이션 하는 방법이 있습니다. http://blogs.breezetraining.com.au/mickb/2010/04/23/UpgradingFromSharePoint2010Beta2ToRTM.aspx

하지만 필자는 위의 방법을 사용하지 않고 기존 SharePoint 2010 Beta 버전을 말끔하게 삭제하는 방법으로 RTM 버전을 설치하고자 합니다.

1. 기존의 SharePoint 2010 RC 버전을 프로그램 추가/제거에서 삭제합니다.

   

2. 레지스트리 편집기(regedit.exe) 를 실행하여, HKLM\Software\Microsoft\Shared Tools\Web Server Extensions 키를 삭제합니다.

   

3. C:\Program Files\Microsoft Office Servers 폴더를 삭제합니다.

   

4. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions 폴더를 삭제합니다.

   

5. SQL Server 의 다음의 데이터베이스를 삭제합니다.

   

6. 모든 과정을 정상적으로 삭제 되었으면, SharePoint 2010 RTM 버전을 설치합니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

발생 문제

Team Foundation Server 2010 을 재설치 한 후에, 로컬에서 소스 코드를 바인딩 하기 위해 작업 영역(Workspace) 를 매핑하고자 합니다.

하지만 아래와 같은 메시지로 작업 영역과 로컬 폴더간의 매핑이 이루어 지지 않습니다.

   

   

발생 원인

이 문제는 Team Foundation Server 의 정보의 일부를 로컬에 Cached 하고 있습니다. 로컬 컴퓨터에 Cached 가 되는 이유는 서버가 접속할 수 없는 경우 또는 오프라인일 경우에도 매핑 정보를 유지하기 위함입니다.    

매핑 파일의 정보는 아래의 경로에서 찾을 수 있습니다.
C:\Users\사용자 폴더\AppData\Local\Microsoft\Team Foundation\3.0\Cache

   

해결 방법 

이 문제를 해결 하기 위해 로컬에 Cached 된 정보를 삭제합니다. 아래의 경로로 이동합니다.
C:\Users\umc\AppData\Local\Microsoft\Team Foundation\3.0\Cache

   

이동한 폴더의 VersionControl.config 파일을 아래와 같이 삭제합니다.

또는

VersionControl.config 파일의 repositoryGuid 등을 현재의 Guid 로 변경해 주시거나, 매핑하고자 하는 TFS 서버의 정보만 삭제한다면 기존의 매핑 정보를 그대로 사용할 수 있습니다.

또는 아래와 같이 문제가 발생되는 선택 영역의 부분의 XML Element 만 삭제하시면 됩니다.

위와 같은 방법으로 해결 된 경우, Visual Studio 를 재시작하지 않고 바로 적용이 가능합니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요