'비주얼 스튜디오'에 해당되는 글 23건

  1. 2013.09.24 [마이크로소프트의 몰락] .NET 개발자가 .NET 플랫폼을 떠나는 이유 (53)
  2. 2013.06.18 [TFS] 팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1
  3. 2013.06.05 윈도우 8, 무서운 드라이버와 궁합
  4. 2013.05.31 [ALM] 13. 불완전한 통합, 팀 파운데이션 서버(Team Foundation Server)
  5. 2013.05.27 Roslyn 프로젝트오 Visual Studio의 미래, 그리고 Mono Project (2)
  6. 2012.08.02 개발자도 알아야 할 응용 프로그램 모델링 7/7 - 결론 및 저자 소개 (1)
  7. 2012.08.02 개발자도 알아야 할 응용 프로그램 모델링 6/7 - 모델링 확장 (SDK)
  8. 2012.08.02 개발자도 알아야 할 응용 프로그램 모델링 5/7 - Visualization & Features Pack
  9. 2012.08.02 개발자도 알아야 할 응용 프로그램 모델링 4/7 - 모델링 다이어그램
  10. 2012.08.02 개발자도 알아야 할 응용 프로그램 모델링 3/7 - 모델링의 표기
  11. 2012.08.02 개발자도 알아야 할 응용 프로그램 모델링 2/7 - 왜 모델링인가? (2)
  12. 2012.08.02 개발자도 알아야 할 응용 프로그램 모델링 1/7 - 들어가기에 앞서...
  13. 2012.08.01 [월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012를 마치며 (1)
  14. 2012.08.01 [월간 마이크로소프트 5월호 특집기사] C++ 매트로 앱 개발을 위한 C++/CX 언어
  15. 2012.06.06 Windows 8 SDK 에는 이것이 빠져있다? (2)
  16. 2012.05.06 크로스 플랫폼 개발 환경 만들기 - (7/11) 우분투 OS를 개발자 스타일로 최적화
  17. 2012.03.15 Visual Studio 11, SOLUTION EXPLORER 스마트하게 사용하기 (1)
  18. 2010.09.06 [세미나] Visual Studio Seminar #1 / 2010년 9월 28일
  19. 2010.09.06 [세미나 발표 자료] Visual Studio Camp #1
  20. 2009.10.20 Visual Studio 2010 Beta 2 설치 미리 보기
  21. 2009.10.20 Visual Studio 2010 Beta 2 출시
  22. 2009.10.06 Visual Studio 2010 확장 모델인 VSIX 버그
  23. 2009.10.06 Visual Studio 2008 단위 테스트는 x64 어셈블리를 사용할 수 없다 (1)

.NET 플랫폼이 나오고 십 여년 동안 마이크로소프트(Microsoft)는 .NET 플랫폼 시장을 개척하고 활성화 하기 위해 많은 투자를 아끼지 않았다. 많은 사람들이 주저 없이 .NET 개발에 뛰어 들었고, 비주얼 스튜디오(Visual Studio) 편리한 개발 도구는 .NET 플랫폼 개발에 필수 도구가 되었다.

하지만, 이제 한 때 과거의 이야기가 되어가고 있다. .NET은 새로 익히기 꺼려지는 플랫폼 중 하나가 되었고, 사회에 진출하는 새로운 .NET 개발자는 더 이상 예전처럼 양성 되지 않고 있다. 여기에 근거하는 사실을 매우 구체적으로 적고 싶으나 단순히 구체적인 한 두 가지의 문제라기 보다 복합적인 문제이므로 이를 읽는 독자는 넓은 시야로 가볍게 읽어주길 바란다.



[출처] 링크


그리고 본문에 잘못된 내용이나 사실에 근거를 대라고 지적하시는 것도 좋으나 그 정보는 직접 찾아 보고 반론을 제기해 주면 필자가 굳이 구구절절 같은 설명을 할 필요가 없어지므로 발전적인 토론이 될 것이라 생각한다.

1. .NET 플랫폼에 너무 많은 투자를 한 것

그야말로 .NET 개발 언어 중 대표적인 C#은 많은 다양한 프로그래밍 언어의 장점을 수용했다. 루비(Ruby), 파이썬(Python), 스몰 토크(Smalltalk)와 오브젝트 C(Objective C), 리스프(Lisp) 등의 프로그래밍 언어의 장점을 C# 언어에 녹아냈다. 이로써 C# 2.0, C# 3.0 시절엔 .NET 플랫폼의 춘추전국시대라고 해도 과언이 아닐 정도이다. (좋게 말하면 개방적인 언어가 되겠고, 나쁘게 말하면 줏대 없는 잡탕이라고 볼 수 있겠다.) 그와 함께 WCF(Windows Communication Foundation), WPF(Windows Presentation Foundation) 등 새로운 기술의 쏟아내는 기염을 토해냈다.

하지만 다른 측면에서 다른 분야의 기술과 그걸 밥벌이 하는 개발자들은 결국 소외될 수 밖에 없다. 그리고 그런 기술들은 기술 발전이 정체 되고, 지원이 끊기거나 지원 규모가 작아지게 된다. 대표적으로 비주얼 베이직(Visual Basic)과 ASP(Active Server Page), 실버라이트(Silverlight) 등이 사망 선고를 받게 된다.

다음은 각각 사망할/사망한 날짜이다.

최근 .NET 개발마저 침체기임이 틀림없다. .NET 플랫폼의 기본은 .NET 프레임워크(.NET Framework)이지만, 이 기본 라이브러리마저 파편화가 되고 있다. 엄밀히 말해 실버라이트, 윈도우 RT(Windows Runtime), .NET 프레임워크는 전혀 다른 메모리 공간에 로드 되는 외형만 비슷한 라이브러리이다. 자바처럼 JRE, JVM을 기초로 모든 코드가 실행되는 것과 다르다. 따라서 실버라이트, 윈도우RT, .NET 프레임워크는 각각 코걸이, 귀걸이 등 물리적으로 전혀 다른 구성 요소로 본다. 이는 마이크로소프트가 1년 앞도 염두하지 않고 급하게 설계하고 개발한 것이며, 아직 까지도 이런 릴리즈가 꾸준히 계속 되고 있다. 이는 뭔가 새로운 버전이 출시할 때마다 하위 호환성을 버리는 악순환이 된다.

2. 네이티브(Native)를 죽여버린 것

지난 수 십여년간 네이티브(Native) 기술의 암흑기였다. 더 이상 Visual C/C++ 6.0 컴파일러는 멀티 코어 CPU에 대응하기 힘들어지고 울며 겨자 먹기로 상위 버전으로 업그레이드를 할 수 밖에 없었다. VC 6.0에서 VC 2008/2010으로 약 십여년의 시간적인 격차가 벌어진 개발 도구와 개발 환경으로 옮겨야 했다.

UPDATE 2013-10-04
참고로 'Visual C/C++'이라 표기한 것은 C 언어 프로그래밍과 C++ 프로그래밍이 모두 가능하다는 의미이다. 아시다시피 Visual C/C++ 의 컴파일러는 다음처럼 Microsoft C/C++ Compiler 라고 표기되어 있기 때문에, 이를 통용하여 Visual C/C++이라고 표현하였다. 'Visual C 라는 것은 없다'고 하시는 분이 계셔서, 이 부분에서 오해의 소지가 없도록 하였으면 한다. 

또한, MSDN 의 일부 문서는 C/C++ 언어를 모두 다루는 문서가 있으니 MSDN의 C/C++ Languages 섹션을 참고하면 된다. 정확한 표기는 'Microsoft C/C++'로 표기하는 것이 정확하지만, Visual Studio IDE와 연관된 부분은 'Visual C/C++'이라 표기하는 것이 더 어울리지 않을까 생각한다.

참고: C 프로그램 컴파일 - http://msdn.microsoft.com/ko-kr/library/bb384838(v=vs.90).aspx

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

simple.c
Microsoft (R) Incremental Linker Version 9.00
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:simple.exe
simple.obj

업그레이드는 컴파일러 뿐만 아니라 개발 도구마저 상위 버전으로 바꾸는 것은 매우 불합리하다. 컴파일러만 바꾸면 되지만 개발 도구까지 상위 버전으로 바꾸어야 하는 비합리적인 개발 환경은 오직 Visual C/C++ 밖에 없을 것이다. (그 외 윈도우 폰, 윈도우 8 앱 개발 환경도 마찬가지다)

그렇게 .NET 플랫폼이 춘추전국시대를 맞이하는 동안 마이크로소프트의 대부분의 SDK의 APIs 들은 .NET 용으로만 제공되었다. Visual C/C++로 만들고 싶어도 만들 수 없는 것이 더 많아지게 되었다. 아니, 만들 수는 있겠지만 ‘만들고 싶지 않다’는 표현이 맞을 것이다.

3. 실험적인 기술을 너무 서둘러 릴리즈 한 것

웹 2.0과 함께 떠오른 ASP.NET 기술 중 AJAX.NET 이 되겠다. 당시 AJAX 대표 라이브러리 중 prototype과 script.aculo.us 등이 대세임에도 불구하고 ASP.NET 서버 랜더링 모델을 고수하는 AJAX.NET을 내놓았다. 결국, 채 2년도 되지 않고 ASP.NET 웹 프레임워크는 jQuery를 공식적으로 지원하고 기존의 AJAX.NET은 어떤 언급도 없이 그렇게 버려졌다.

실버라이트(Silverlight). 이 기술은 애당초 세상에 나오지 말았어야 하는 기술이라 본다. 돌이켜보면 실버라이트 3.0 버전을 실버라이트 1.0 버전으로 나왔어야 경쟁력이라도 있었고 시장에서 기술적인 신뢰를 얻을 수 있었다. 물론 마이크로소프트(Microsoft)는 서둘러 어도비(Adobe)를 따라잡고 싶은 심정은 십분 이해된다. 하지만 이 실버라이트 기술 하나 믿고 시작한 개인과 회사는 시간, 인력, 기타 리소스의 금전적인 규모가 치명적인 타격을 주기에 충분하다. 한 마디로, 실버라이트 쇼크(shock)다.

실버라이트는 아직 까지 윈도우 폰 개발, (그 외 쉐어포인트(SharePoint))에 필요한 기술이다. 아직까지 실버라이트 개발을 하고 있는 분들에겐 미안하지만, 브라우저를 기반으로 하는 실버라이트 응용 프로그램은 거의 모조리 자취를 감췄다.

윈도우 폰 7. 조심스러운 부분이다. 다만 필자의 생각은 이 윈도우 폰 7이 정상적인 스마트 폰인지, 아니면 프로토타입 폰인지 아직도 구분하기 힘들다. 그리고 필자는 후자라고 생각한다. 다음의 인용을 보면 윈도우 폰 7은 Windows CE/Compact 7 커널 기반이지만, 윈도우 폰 8은 Windows NT 커널을 사용한다.

Windows Phone 7 is based on the Windows Embedded CE kernel – the next generation of the Windows Embedded CE platform will be Windows Embedded Compact 7 when released, and the current version is Windows Embedded CE 6.0 R3. Although Windows Phone 7 was built on the Windows Embedded CE kernel at its core, the Windows Phone team has incorporated innovative features and functionality on top of the platform to develop an OS specifically designed to meet the needs of mobile phone manufacturers. [2]

여기서 예상할 수 있는 것은 윈도우 폰 7은 이미 버린 카드이다. 왜냐하면, 윈도우 폰 7은 윈도우 폰 7.8 버전까지 업데이트를 할 수 있는데, 윈도우 폰 7과 8은 서로 전혀 다른 커널을 사용하므로 윈도우 폰 7 사용자는 윈도우 폰 8 운영체제로 업데이트를 할 수 없기 때문이다. 한 가지 재미있는 것은, 업데이트 ‘7.8’ 버전 번호를 보고 유머러스 한건지, 약올리는 건지 분간이 안된다. ㅎ

윈도우 8. 윈도우 8의 앱 개발 기반은 진흙 위에 빌딩을 세우는 것과 같을 정도로 안정적이지 못한 릴리즈이다. 결국 윈도우 8.1에서는 또 윈도우 8과 하위 호환성을 상당 부분 포기해야 했다. 이는 윈도우 폰 8도 마찬가지다. 윈도우 8 앱의 기반은 WinRT(Windows Runtime)인데, 이 WinRT도 완성도 면에서 프로토타입이라고 확신한다. 여기에 대해서는 아래의 필자의 글을 참고하기 바란다.

4. 플랫폼 사용자를 플랫폼에 가두는 것

물리적인 측면에서 .NET 플랫폼의 확장은 돈으로 직결되고 돈으로 귀결된다. 아주 간단한 예로 .NET 플랫폼이 클라우드에서 동작 가능한 Auto Scaling 환경이라고 치자. 서비스에 부하가 가중되면 필요에 따라 이를 분산하기 위해 스케일 아웃(scale out)이 필요할 때가 있는데, 이때 당장 윈도우 라이선스 부과라는 문제부터 해결해야 할 것이다.

마이크로소프트 윈도우즈(Windows) 서버 제품을 사용하는 순간부터 마이크로소프트의 제품을 사용해야 하는 처지에 놓이고 만다. 다음과 같이 말이다.

  • LDAP, Authentication, Certification -> 엑티브 디렉토리,(Active Directory)
    DNS -> 윈도우즈(Windows) DNS 서버
  • 웹 서버 -> IIS(Internet Information Services)
  • 가상화 -> Hyper-V
  • 응용 프로그램 서버 - COM+, WCF(Windows Communication Foundation)
  • 스크립트 언어 -> PowerShell

.NET 플랫폼과 매우 친숙하게 어울릴 수 있는 구성 요소들이다. 물론, 반드시 선택하지 않아도 되는 차선책은 있지만, 그렇게 되면 아름다운 아키텍처를 절대 만들 수 없게 된다. 솔루션 도입에서도 마찬가지로 사내 클라우드(Private Cloud) 구축에 Hyper-V과 결합하는 System Center 제품군은 최선책이고, 차선책은 없다.

위의 경우는 단적인 일부 예일 뿐이다.

.NET 플랫폼 또한 '그들만의 리그(League)' 일 뿐이다. 그들만의 리그 속에서는 환상적인 조합이지만, 조금만 밖에서 지켜보면 하나의 당이 모든 것을 통제하는 공산당 아키텍처와 다를 바가 없다.

5. 개발자를 경청하지 않는 마이크로소프트의 By Designed 철학

마이크로소프트의 모든 최종 답변은 이것으로 통한다. 바로 “BY DESIGNED-의도된 설계”.

섣부른 릴리즈(Release), 구조적인 아키텍처의 결함, 비효율적인 사용자 경험(UX) 등의 고객이나 사용자의 이의에 대해 마지막 (비)공식적인 마이크로소프트의 답변은 "by designed-의도된 설계" 라고 한다. 로드맵(roadmap)에서는 보여주지 않는 By designed 때문에 개발자와 회사들을 곤란한 상황에 빠트린다.

재미있는 일이 벌어졌는데, 마이크로소프트는 일방적으로 Microsoft SQL Server 라이선스 기준을 변경했다. 필자는 이것도 큰 범주에서 "By Designed" 철학과 전혀 무관하지 않다고 본다. 원래 CPU 라이선스(per cpu license)를 코어 라이선스(per core license)로 일방적으로 변경하는 바람에 SQL Server를 사용하는 멀쩡한 회사들을 불법 사용자로 취급 되어 라이선스가 부과되고, 이를 뒤늦게 안 영세(?)한 곳에서는 마른 하늘에 날벼락이 떨어지는 꼴이다. 합법적인 절차라 하더라도 충분히 고객들에게 분노를 살 수 있을 것이다. 이 라이선스 정책에 대해서는 다음의 링크를 참고하기 바란다.

"BY DESIGNED", 오리발 내밀기에 최고의 답변이자 최악의 답변이다. 필자도 이 말을 (불리할 때?) 쓰는 것을 좋아하지만, 반대로 또 가장 싫어 한다.

6. 개발자의 스스로 성장할 자생력을 죽여버린 것

제국 마이크로소프트는 개발자 생태계를 너무나 심각하게 교란 시킨다. 모든 개발 환경은 통제된 환경 하에서만, 그리고 통제된 방법으로 사용되길 원한다.

.NET 플랫폼 환경은 최선책은 있지만 차선책은 없다. 웹 개발만 예를 들어 보아도 자바(Java)는 스트럿츠(Struts), 스프링 MVC(Spring MVC), 플레이 프레임워크(Play Framework) 등 충분히 시장에서 검증된 웹 개발 프레임워크가 있다. 여기에 자바 언어보다 더 심플하고 강력한 언어인 스칼라(Scala), 그루비(Groovy)를 결합하면 폭발적인 생산력을 낼 수 있다.

하지만, ASP.NET은 ASP.NET MVC 이외에 차선책은 없다. 참고로 ASP.NET 웹 폼은 최선도, 차선도 아니다. 자세한 이야기는 다음의 필자의 글을 참고하기 바란다. 더불어 필자가 2009년에 쓴 글임을 감안하고 읽어 주길 바란다.

ASP.NET 웹 폼을 제외한 이유는 ASP.NET 웹 폼은 생산성 향상을 할 수 있는 기능 요소를 보여주기 위한 ASP.NET이 제공하는 기능의 일부이다. 그러므로 ASP.NET 웹 폼이 ASP.NET 전체 아키텍처에 영향을 주는 요소가 절대 아니므로 ASP.NET 웹 폼을 ASP.NET 웹 플랫폼과 동일 선상에서 비교하는 오류를 범하면 안되는 것을 당부한다. 즉 ASP.NET은 반드시 ASP.NET 웹 폼으로 개발하지 않아도 된다. 이 웹 폼은 사용자 정의 컨트롤로 구현된 컨트롤에 불과한 것이다. 자세한 내용은 MSDN 링크를 참고 하기 바란다. [3]

따라서 자바 플랫폼 웹 개발자들을 만나게 되면 다양한 기술과 경험에 대한 이야기를 들을 수 있고 충분히 토론할 만한 주제가 있는데 반면, .NET 웹 개발자들의 주요 관심사는 ASP.NET MVC 코드 조각을 찾아서 해결한 문제나 트러블 슈팅하는 팁 공유가 대부분이다. 그러므로 일반적인 .NET 웹 개발자는 자바 웹 개발자의 열린 사고 방식을 따라갈 수 없다고 결론을 내렸다.

뽀송뽀송한 .NET 플랫폼 테두리에 갇혀 있다면 우물 안의 물이 원래 당연히 썩는다고 생각할 거다. 하지만, 테두리 밖에서 바라보면 우물 안의 물이 원래 썩는 게 아니라 흐리지 않기 때문에 썩는 다는 걸 깨닿게 될 것이다.

7. 모든 것을 심각하게 통합한 것

.NET 개발자는 비주얼 스튜디오(Visual Studio) 없이는 단 한 줄도 코드를 만들어 내지 못한다. 단 한 줄, 과장된 표현이긴 하지만 비주얼 스튜디오(Visual Studio) 이외에 다른 대안이 없다.

통합은 곧 깡패다. 팀 파운데이션 서버(Team Foundation Server)에 체크인(Checkin)된 소스 코드를 받으려면 어이없게도 비주얼 스튜디오가 반드시 필요하다. 팀 탐색기(Team Explorer)가 설치된 비주얼 스튜디오 쉘(Visual Studio Shell)이 없으면 TFS Power Tools 같은 것도 무용지물이다. 왜냐하면 TFS 클라이언트 도구는 팀 탐색기에 포함된 필수 런타임이 반드시 필요하기 때문이다. 그 외 더 자세한 내용은 다음의 필자의 글을 참고 하기 바란다.

만약 마이크로소프트가 망한다면 기술의 기반, 개발 환경, 기타 솔루션 등 모든 것은 그저 한 줌의 재가 될 것이다. 소스 코드를 공개한다고 해도 그 일부는 더 장래가 밝은 1인자에게 기부될 것이다.

현재까지 100년 이상 된 IT 기업은 전세계에도 없다.  "영원히 위대한 기업, 영원히 호황을 누리는 산업은 없다. 다만 영원히 뛰어난 전략적 움직임만 존재할 뿐이다." [4] 마이크로소프트가 100주년이 된다면 IT 기업이 아닌 애플에 부품을 대주는 ‘제조업’ 회사일 수도, 플레이 스테이션을 유통 시키는 ‘무역업’ 회사일 수도, 그 아무도 모른다.

UPDATE 2013-10-04
IT 기업 중 100년 이상이 된 기업은 IBM으로 2011년도에 100주년이 되는 해였다. 댓글로 정보를 제공해 주셔서 감사합니다.

언젠가 (차선책이 없는) 통합된 제품을 쓰는 이들은 엄청난 대수술을 받아야 할 지 모른다. 마치 흔들리는 이빨만 뽑을 수 없고 잇몸 전체를 들어내야 할 수도...


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 이전 댓글 더보기
  2. 지나가던사람 2014.08.19 15:36 Address Modify/Delete Reply

    글 잘 읽었습니다.
    닷넷 개발만 10년넘게 하다가 최근 1년정도 php, java, python 등등 하고 있는 사람인데,
    저는 잘 모르겠습니다. 방금 언급한 언어들이 아직은 닷넷보다 미숙한 탓도 크겠지만,
    vs에 비해 개발 툴(이클립스, 인텔리제이)에서 느껴지는 답답함과 생산성, 유지보수의 불편함
    개발 프레임워크의 복잡성,, 이런 것들이 너무 크게 자리잡고 오히려 이런 것들이 쌓이니
    개발이 재미가 없어지고 있습니다.
    너무 닷넷에(편한 개발환경에) 익숙해져 말씀하신대로 변화에 적응력이 떨어진 거 같은 생각도 듭니다.
    닷넷이 망한(?) 원인은 여러 설명을 해주셨지만 제가 보기엔 기술의 흐름(ria, 오픈소스)에 대한 대응이 실패한 것이 크고 플랫폼 독립성이라는 주제에 대해 간과한 점, MS 제품군에 종속성을 유지하려 한점,
    라이센스에서의 독재성(?) 뭐 이런것들이 주요 원인이라 생각이 드네요.
    전 그래도 닷넷을 사랑합니다.
    10년넘게 개발해 오면서 닷넷이 아닌 다른 걸 선택했다면 쓸데없는 스트레스를 너무 많이 받았을 거 같네요..ㅎ 그만큼 닷넷이라는 기술에 있어서는 자바나 다른 언어들과 비교해도 뛰어나다고 생각합니다.

  3. 일단 공감, 그리고. 2014.08.24 22:32 Address Modify/Delete Reply

    MS는 MS DOS / Windows로 굳어진 OS 개발회사라는 틀을 벗어나는 것이 가장 시급하지 않은가라고 생각합니다. 90년 초반 MS-DOS를 사용하다 DR-DOS로 옮겨가던 사람들이 오피스 때문에 다시 Window 3.1를 다시 돌아보던 기억이 납니다. 그 때도 많은 사람들이 MS 욕은 엄첨 했었지만, 그건 특정 업체에만 국한되었던 것은 아니었죠. MS에서 느끼는 답답함은 그 시절과 크게 다르지 않은 것 같습니다. 오히려 닷넷때문에 이미지가 호전되었었다고나 할까요. :-) IBM, Oracle... 모두 다 사활을 건 생존경쟁에 서 있는 "업자"들일 뿐. 회사는 솔루션에 적합한 개발 플랫폼을 고르면 그만, 개발자는 회사에서 선택한 플랫폼이 머든 제발 리펙토링이라도 제대로 했으면 하는 쿨럭 -ㅁ- ㅋ

  4. 흠.. 요즘에는.. 2014.09.29 00:23 Address Modify/Delete Reply

    아주 새로운 데에서 닷넷이 풀리고 있습니다.
    혹시라도 닷넷을 망해가는 언어로 생각해서 더이상 배우는 사람이 나오지 않을까 몇 자 적어봅니다.

    마이크로소프트 닷넷 프레임워크를 멀티 플랫폼에서 돌릴 수 있도록 변환하는 작업이 오픈 진행되고 있습니다.

    Xamarin Studio 가 대표적인데, 닷넷으로 구현된 프로그램이 안드로이드, IOS, 윈도우 모두 돌아갈 수 있도록 합니다. 그 언어는 C#이고요..

    그 Xamarin studio 의 기본 툴이 MonoDevelop인데, 이건 요즘 각광받는 유니티에서 사용되고 있습니다.
    닷넷 관련 소스 및 커뮤니티도 상당히 크고요.

    MS가 전면에 나서서 하지는 못하지만 (회사 특성상) 멕시코 개발자가 시작한 MonoDevelop은 큰 반향을 일으키고 있습니다.

  5. feel 2014.11.14 11:19 Address Modify/Delete Reply

    어제자 발표입니다.
    우리의 목소리를 MS가 들은 걸까요? 이제 정신차리려고 하나 봅니다.

    http://news.microsoft.com/2014/11/12/microsoft-takes-net-open-source-and-cross-platform-adds-new-development-capabilities-with-visual-studio-2015-net-2015-and-visual-studio-online/

  6. 병팔이 2015.04.14 00:11 Address Modify/Delete Reply

    내용 중 7번에 공감 100% 입니다. SDK만 가지고 IDE 없이 빌드를 해보고자 했으나 너무나 큰일이더군요. 스케줄 빌드 같은 것은 대체 어떻게 하란 말인지? 그리고 SDK 설치했는데 나오는 경로명에 Visual Studio 뭐 이런 게 왜 섞여 나와야 하는건지. .NET 설치하는데 SQL Server 공짜로 깔아줘서 고맙다고 박수칠 줄 알고 넣어준건지. 하여간 너무 바보같고 monolithic한 덩어리를 만들어버렸습니다. 더 이상 기술향상은 안해도 좋으니 하루라도 빨리 깨끗이 나눠만 줬으면 좋겠습니다.

  7. 놔놔2 2015.06.18 08:02 Address Modify/Delete Reply

    저는 1984년에 마이크로 소프트 베이직을 보기 시작하여 비주얼툴로 자리를 잡았었는데요.
    엠에스가 욕을 많이 먹어도 왜 그러는지 몰랐다가.. 어느 순간부터 제가 욕을 하던데..ㅋㅋ 또 언제부턴가 기대도 안하고 그냥 기대를 포기했달까요.. 머하나 성공하는 모습을 못보게 되고 자만과 오만, 독선은 심지어 시작버튼 제거라는 지상 최대의 산업생산성에 역효율성의 극대화를 낳는등.. 사회와 국가와 세계에 미치는 악영향이 장난이 아니었죠. 만드는 것마다 자충수들 뿐이라 이제는 최고의 부자가 어떻게 잘근잘근 망해가는 가를 두고 강건너 불구경만 하고 있습니다. 왜 애플과 삼성이 발전을 하는데 엠에스는 스스로를 두고 우리는 개발사가 아니다 라고 말을 했을까 무척이나 씁쓸하고 안타까웠습니다. VB6.0의 기술지원단종도 산업에 끼친 악영향은 장난 아니며 IE의 버전별 버그는 또 어떻습니까.. 이젠 어떤 기술이 나와도 또 하나 시끄럽게 홍보하다가 또 사라지겠구나 합니다.

  8. 놔놔2 2015.06.18 08:02 Address Modify/Delete Reply

    저는 1984년에 마이크로 소프트 베이직을 보기 시작하여 비주얼툴로 자리를 잡았었는데요.
    엠에스가 욕을 많이 먹어도 왜 그러는지 몰랐다가.. 어느 순간부터 제가 욕을 하던데..ㅋㅋ 또 언제부턴가 기대도 안하고 그냥 기대를 포기했달까요.. 머하나 성공하는 모습을 못보게 되고 자만과 오만, 독선은 심지어 시작버튼 제거라는 지상 최대의 산업생산성에 역효율성의 극대화를 낳는등.. 사회와 국가와 세계에 미치는 악영향이 장난이 아니었죠. 만드는 것마다 자충수들 뿐이라 이제는 최고의 부자가 어떻게 잘근잘근 망해가는 가를 두고 강건너 불구경만 하고 있습니다. 왜 애플과 삼성이 발전을 하는데 엠에스는 스스로를 두고 우리는 개발사가 아니다 라고 말을 했을까 무척이나 씁쓸하고 안타까웠습니다. VB6.0의 기술지원단종도 산업에 끼친 악영향은 장난 아니며 IE의 버전별 버그는 또 어떻습니까.. 이젠 어떤 기술이 나와도 또 하나 시끄럽게 홍보하다가 또 사라지겠구나 합니다.

  9. hewon 2015.06.21 16:13 Address Modify/Delete Reply

    2015년 6월에 이 컬럼을 보는데 정말 정확하게 찍어보신것 같습니다.
    특히 윈도우폰이나 RT의 미래에 대해서는요.
    닷넷 개발하는 개발자 입장에서는 자기가 개발했던 제품이 언제 단종되나 두근두근하면서 개발하고 있습니다.

  10. MonoDevelop 2015.08.08 19:34 Address Modify/Delete Reply

    MonoDevelop 한글판이 익숙치 않아 영어로 놓고 있었는데 언제부터인가 언어 설정을 english로 해도 계속 한글이 튀어나와서 아주 괴롭습니다. 이거 어떻게 방법 없을까요?

    • 땡초 2015.08.09 00:17 Address Modify/Delete

      맥 버전을 사용하신게 맞나요?
      확인 차 여쭤봅니다.

  11. Yuhan 2016.04.05 11:22 Address Modify/Delete Reply

    옛날 게시물이니 그려려니하다 2015년도 글도 보여서 얕은 지식과 의견 몇자 적어봅니다.

    상당히 MS를 까기위한 편견만 가지고 접근하시는듯 한 부분이 많이 보입니다만.

    언어적인 측면에서는 2015년에는 이미 C#이 Java를 뛰어넘었다고 볼 수 있습니다.

    LINQ, Lambda Expression 등 현재는 Java가 언어적인 측면에서 오히려 .Net을 따라가고 있는 인상을 주고 있죠.

    사실 저도 원래 .Net 개발자이지만, 최근들어 Java로 프로젝트를 계속 진행하고 있습니다.

    Java가 좋아서도 아니고, 그저 국내 시장에 자바를 선호하는 경향이 강할 뿐 사실

    자바 4~5년 / 닷넷 6년 개발 해본 입장에서 어마어마하게 많은 중괄호와

    인터페이스 오히려 간결하지 못한 코드, 뭐 할려고만 하면 추가해야되는 플러그인이나

    아주 사소한것까지 추가해야되는 다양한 프레임워크로 스트레스 많이 받습니다.

    (StringUtils라는 클래스가 몇개의 라이브러리에 중복되어 섞여있습니까.)

    괜히 Groovy가 나왔겠습니까.

    그렇다면 Java를 버리고 Groovy를 배우는게 맞을까요? 이러면 자바 개발자가 아닌게 되는건가요?

    언어적 완성도 측면에서는 Java는 더이상 C#의 상대가 되지 않습니다. 2013년에도 말이죠.

    C#을 쓰지 않아도 배워야 하는 이유는 이것 하나만으로도 충분합니다.

    4번 제외하고는 사실상 진짜 닷넷에 대해 편파적으로 바라보는 자바개발자가 쓴 글 처럼 느껴지는데.

    이거랑 똑같이 자바도 단점 끄집어 내면 한도 끝도 없습니다.

    • 땡초 POWERUMC 2016.04.05 13:44 신고 Address Modify/Delete

      맞는 말씀입니다.
      굉장히 편파적으로 바라보면서 쓴 글입니다.

      하지만 자바 진영은 오픈 커뮤니티로 합의에 의해 주도되지만,
      MS는 상업적 기업이니 같은 시각으로만 바라보기 힘들기도 합니다.

      좋은 의견 주셔서 고맙습니다.

  12. 설마 2016.06.17 01:21 Address Modify/Delete Reply

    MS가 이 글을 본걸까요.. 3년이 지난 지금은 이 글에서 꼬집은 문제점이 대부분 해결되었다는 점이 신기하네요 ㄷㄷ

  13. John 2016.07.08 13:46 Address Modify/Delete Reply

    많은부부에서 공감을 얻고갑니다 자바 개발로 시작해서 현재 닷넷 개발을 하고있는데 위에 말씀하신분이 적으신것 처럼 언어적 편의성 은 C# 이 훨씬 우월하긴 합니다 , 그 편의성때문에 가끔 가독성이 떨어질때에도 있는데 작성하는 입장에서는 엄청 좋기도하고,, 그리고 닷넷이 정확히는 CORE 닷넷출시하면서 위에 말씀하시는 모든 문제들을 대부분 해결하거나 제안을 제시했습니다 마소가 좋은녀석들이라서 그런것은 아니고 , 시장경쟁력에서 워낙 많이 밀리고 또 대세가 그러하니 변경한것 같습니다 좋은 글 잘읽고 갑니다

  14. 요원009 2016.10.27 15:31 신고 Address Modify/Delete Reply

    엔지니어 출신 이사들 내쫓음 -> MBA 출신들 데려옴 -> 말아먹은 게 한 두개가 아님.

    말아먹은 것들이 저 위에 다 나오네요. 정신차리고 엔지니어 출신들 다시 모셔오니 정상 궤도로 올라오는 느낌입니다. 요즘 C# 너무 강력해요 ㅎㅎㅎ

  15. 나그네 2017.02.05 21:45 Address Modify/Delete Reply

    요즘 Java가 마소 보다 악질인 오라클 놈들 때문에 정나미가 떨어져서 C#으로 왔습니다. 나중에 ClojureCLR 프로젝트에나 참여하고 싶네요. 요즘 마소가 제공하는 자료도 너무나 많고(MSDN, Visual Academy 등) 리눅스 지원에 오픈소스 프로젝트도 많이 해서 진짜 많이 변한 것 같네요. 그놈의 윈도우의 괴상한 구조(특히 레지스트리)는 변함이 없지만 윈10이 마지막이라고 하니 다음 OS는 제발 개발자나 서버 관리자들에게도 일반 유저에게도 편리한 OS로 나오길...

  16. 얌전맨 2017.06.20 09:53 Address Modify/Delete Reply

    MS가 정말로 이 글을 읽고 반성한것처럼 저 시기 이후로 많이 달라졌습니다. 글 쓰신분의 예리한 통찰력에 감탄하구요. 자마린이 통합된 VS2017 출시로 다시 한번 C#에 희망을 걸어봅니다.

  17. 지나가다 2017.07.15 18:56 Address Modify/Delete Reply

    잘 읽었습니다.
    그런데, 외국을 보면 Java 가 우리나라 처럼 이렇게 융성하지도,
    .Net 이 한국처럼 저조하지도 않아요.

    이유는 딱 하나입니다.
    자기 돈 아닌 돈으로 프로젝트 하는 공무원들과
    국가 공인 프레임웍을 Java 로 만들어 놓은 사람들.

    아마 본인이 회사 사장인데,
    본인 회사 프로젝트를 전자정부 프레임웍을 써서 프로젝트 하라고 하면 하겠습니까?

    그리고, Java 진영에서 떠들던 MVC...
    숙련자들이 모이고, 원활한 커뮤니케이션이 되야
    중급이하의 개발자들이 모여서 대충 개발할 수 있는
    PHP, .Net 언어들만큼의 퍼포먼스가 나온다고 한다면...

    이건 공무원이 자기 돈 아닌 자금으로 진행하고,
    업자들은 그 열매를 받아 먹는 구조에서만 가능한겁니다.

  18. ㅇㅇ 2019.03.05 15:27 Address Modify/Delete Reply

    비교하려면 객관적인 도표자료는 필수인데 내용이 너무 주관적이고, 정보 신뢰도 그닥..
    실버라이트가 2021년에 사망이라.. 2010년에 이미 개발중단입니다. 2021년에는 웹브라우저에서 지원이 중단되는겁니다.
    사람들이 여기서 논쟁을 많이 하는 이유는 글을 이따구로 써놓으셔서 인거 같습니다.
    그럼 20000

    • 땡초 POWERUMC 2019.03.05 16:16 신고 Address Modify/Delete

      객관적인 자료는 본문 중에도 링크에 있습니다.
      https://support.microsoft.com/ko-kr/lifecycle/search/?ln=en-us&c2=12905
      2011년 12월에 출시한 SL5 가 있는데 2010년에 개발 중단이라뇨.
      그리고 10년이면 강산도 변한다고 하는데, 이미 6년이나 지난 글에 너무 큰 의미를 두지 않으셨으면 합니다.

  19. 그럼 글을 내리거나 수정하시는게 낫지 않나요? 2019.03.27 13:32 Address Modify/Delete Reply

    그럼 글을 내리거나 수정하시는게 낫지 않나요?

    분쟁 유도글 같아 보여서 올려봅니다.

    • 해구름 2019.04.08 12:40 신고 Address Modify/Delete

      2013년에 작성된 글이니 감안하고 보면 될 것 같습니다. 저도 2013년에는 마소에 대해 감정이 좋지 않았습니다. 폐쇄적이고 멋대로인데다가 제대로 되는 것도 별로 없었거든요. 샤티아 나델라가 지금의 마이크로소프트로 만들지 못했다면, 이 글은 좀더 공감 받았을지도 모르죠.

  20. 천하귀남 2019.04.18 10:19 Address Modify/Delete Reply

    최근 닷넷을 시작하면서 과거와 현재의 차이가 많아 뭐가 뭔지를 이해하기 힘들었는데
    당대의 상황을 이해 가능하게 해주는 글이라 많은 도움 받았습니다.

    문제를 언급하는것도 훌륭한 자료입니다. 불편하다고 지운다면 자료가 아니지요.

  21. 공부중입니다 2019.04.24 19:53 Address Modify/Delete Reply

    지금은 닷넷 전망을 어떻게 생각하시나요??

팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1

필자는 얼마 전에 다음과 같은 글을 썼다. TFS를 그다지 좋아하지 않는 분의 글을 검색 중에 우연히 찾게 되었고, 이에 대해 필자의 의견을 남긴 적이 있다.

개인적인 의견에 필자가 반박한 것이기도 했지만, 필자는 기능적인 면에서 반박을 한 것이라 상대방의 마음이 상할지 몰랐으나, 다시 돌이켜보면 미안한 맘이 계속 든다.

과거 필자는 MS Visual Studio ALM MVP 로서 이 제품을 써야할 이유를 말할 수 있었으나, 지금은 중간적인 입장에서 TFS를 쓰지 말아야 하는 진짜 이유도 써보고 싶었다. 최근 필자는 TFS 이외의 다양한 제품을 접하면서 TFS를 쓰지 말아야 하는 이유에 대해 더욱 확신이 들었다.

우리나라에는 전문가가 없다

우리나라에 팀 파운데이션 서버(Team Foundation Server) 전문가가 없다. 그러므로 당신에게 도움이 될 만한 전문가의 손길은 없을 것이다. 팀 파운데이션 서버(Team Foundation Server) 는 모든 것을 통합한 ALM(Application Lifecycle Management) 제품이다. ALM(Application Lifecycle Management)을 이해하려면 가장 먼저 소프트웨어 공학부터 시작하고 이해해야 한다. 그리고 사용자 측면과 관리적 측면 모두를 이해하고 솔루션 환경을 제공해야 한다.

ALM 제품을 쓰기전에 소프트웨어 공학을 설명하지 못하면 왜 팀 파운데이션 서버(Team Foundation Server)를 써야 하는지도 설명할 수 없다. 소프트웨어 공학은 50년도 되지 않는 짧은 역사를 가졌지만 공학적인 분야에서 이만큼 빠르게 변화하고 발전한 공학도 없을 것이다. 그래서 소프트웨어 공학이란 것이 정확한 기준을 섣불리 경계를 짓기도 애매한 학문이다.

그리고 소프트웨어 공학과 최근 빠르게 확산되는 애자일(agile)에도 많은 시간을 쏟아서 경험을 축척해야 한다. 소프트웨어 공학은 정량적인 측정이 가능하지만 애자일은 다르다. 팀원간의 관계와 팀이 축척한 또는 개개인의 경험이 큰 작용을 하고 애자일이란 툴적인 측면에서도 적극적이어야 한다. 필자도 소프트웨어 공학과 애자일을 공부하면서 처음 블로그에 쓴 글로부터 불과 4년 밖에 채 되지 않는다. 학문이라는 것은 알면 알수록, 배우면 배울수록 모르는 것이 점점 더 많아지는 것은 왜그럴까 ^^;

TFS 전문가는 골고루 다 알아야 한다. 이것 저것 모두 통합된 제품이므로 당연한 것이다. Team Foundation Server, Visual Studio Ultimate 외에 알아야 할 것들이 더 많다.

전문가적인 서비스를 제공하는 업체도 없다

한 마디로, 팀 파운데이션 서버(Team Foundation Server) 기술을 서비스하는 업체들은 다 망했다. 그러므로 만약 당신의 회사에서 TFS 컨설팅이나 서비스를 받고자 한다면, TFS 전문가가 올 확률은 거의 없다고 봐도 된다.

실제로 운영하다 장애가 생겨도 우리나라에서는 제대로 된 서비스를 받기 힘들다. 국내 팀 파운데이션 서버(Team Foundation Server) 전문가가 있는 업체가 한 군데도 없다. 한 곳의 전문 업체가 있었지만 TFS 사업을 접었다고 전해들었다.

필자의 과거 전 회사에서는 TFS 컨설팅을 했었고, 그런 업체가 몇 군데 더 있었지만 지금은 TFS의 수요도 없을 뿐더러 한 번 도입하면 다른 솔루션으로 갈아탈 수 없는 폐쇠성을 가지고 있어 도입의 실효성에 대해서도 논란이 있다.

image-1
이미지 링크

마이크로소프트 제품으로 발라야 한다

TFS 도입을 결정하는 순간 마이크로소프트(Microsoft)의 제품으로 완전히 발라버려야 한다.

가장 먼저 발라야 하는 것은 윈도우 서버(Windows Server) 이다. 가장 최신의 버전인 Team Foundation Server 2012는 윈도우 서버 2008 R2 부터 설치할 수 있다. 항상 최신 버전에 잘 적응을 하는 것이 이로울 것이다.

두 번째로 발라야 하는 것은 엑티브 디렉토리(Active Directory; AD)이다. 다른 LDAP(Lightweight Directory Access Protocol; 경량 디렉터리 액세스 프로토콜)의 OpenLDAP 은 전혀 지원하지 않는다. 예를 들어, 사내에서 리눅스(Linux) 서버에 OpenLDAP을 쓴다면 당장 OpenLDAP 데이터를 Active Directory로 마이그레이션을 해야할 지도 모른다. 좀 더 똑똑한 방법으로는 Active Directory와 OpenLDAP을 동기화 하는 방법도 있지만, 결국 유지 관리의 피로도는 급격하게 늘어날 것이다. (물론, AD 없이 쓸 수도 있지만, 없이 쓸 생각을 하면 앞이 캄캄하다)

세 번째로 발라야 하는 것은 Microsoft SQL Server 데이터베이스 제품이다. 왜 MySQL을 지원하지 않는지 기술적으로 이해하기가 힘들다. 물론 이 제품에서 분석 서비스(Analysis Services)와 리포팅 서비스(Reporting Services)를 제공하는데, 이거 안쓰고 싶어도 써야 한다. 이거 안쓰면 TFS가 매우 초라해 지기 때문이다.

네 번째로 발라야 하는 것은 IIS(Internet Information Services; 인터넷 정보 서비스)이다. 너무도 당연한 이야기지만…

다섯 번째로, 옵션으로 쉐어포인트(SharePoint)를 바를 수 있다. 이것을 바르려고 하는 순간 전용 서버를 고려해야 할 것이다.

예측할 수 없는 잦은 장애, MS 제품에 잔지식이 많아야 한다

모든 것이 통합된 TFS 구동하는 환경은 또 매우 복잡하고 오류의 원인을 찾는 것이 매우 힘들 수도 있다. 그러므로 MS 제품 이것 저것을 알아야 하고 계속…….. 배워야 하는 악순환이 계속된다.

필자는 6년이 넘게 거의 논스톱으로 직접 운영하는 TFS 서버가 있다. 서버도 직접 구매했었고, 소음 때문에 코로케이션으로 쓰다가 서버는 팔고, 결국 규모를 데스크탑 두 대로 줄여서 집에서 돌린다. 자동 업데이트가 설정이 되었는지 원인은 모르겠으나 서버 재부팅 후에 TFS 서비스들이 먹통이 되는 경우가 많았다.

실무에서도 많이 겪는 문제 중 하나가 윈도우 업데이트(Windows Update) 서비스이다. 필자가 몸담았던 회사 중에 운영 조직에서 윈도우 서버 전문가들이 직접 관리했지만, 가끔은 윈도우 업데이트 후에 정상적인 서버 작동이 되지 않아 윈도우 업데이트를 롤백(rollback) 하는 경우가 다반사였다.

대충이라도 모르면 어디서 튀어나온 트러블인지도 예측할 수 없다. 권한 구성만 해도 엑티브 디렉토리, IIS, MSSQL, 쉐어포인트 다 따로 해줘야 하는데 이 제품들이 서로 자기 오류가 아니라는 듯한 메시지만 보여준다.

제대로 된 기능이 하나도 없다

얼마 전에 필자가 쓴 글이다. 글의 요지는 ‘모든 것을 만족할 수 있지만, 어느 것도 만족할 수 없다.’ 이다.

[ALM] 13. 불완전한 통합, 팀 파운데이션 서버(Team Foundation Server)

크로스 플랫폼(Cross Platform)을 지원하는 Atlassian 의 제품 몇 개와 비교해 보자.

  • TFS 이슈관리 vs JIRA (atlassian)  
    음.. 이건 알만한 사람이면 다 안다. TFS를 JIRA와 비교하는 것이 실례이다. redmine과 같은 오픈된 제품에 비해서도 TFS는 장점보다는 단점이 더 많다. TFS 이슈관리가 MS OFFICE 플러그인을 제공하긴 하지만, MS OFFICE에서 플러그인으로 다루는 것이 더 불편하다. 플러그인을 너무 대충 만들어놓고 OFFICE 통합이라고 하는 것은 좀 무리수다.

  • TFS 코드뷰어 vs STASH (atlassian)
    이것도 TFS는 STASH에 비교하는 것이 실례이다. STASH의 특성이 조금 다르긴 하지만, github 의 인트라넷 버전이라고 봐도 무방할 것이다. 그만큼 TFS 코드뷰어에 비해 잘 만들어 졌다.

  • TFS 팀 빌드 vs BAMBOO (atlassian)
    TFS 팀 빌드는 할 수 있는 것이 거의 없다. BAMBOOJenkins에 비교 자체가 실례이므로 넘어간다. 이미 BAMBOO는 Amazon EC2 같은 클라우드와 통합이 되었다. 이에 비해 TFS는 이제 베타 버전으로 인터넷을 통해 서비스를 테스트 중이다. 특히 BAMBOO는 다양한 소스 제어를 지원하는 것도 장점이다.

Atlassian의 통합성은 TFS의 복잡한 구성보다 더 간단하다. Atlassian 제품은 각 제품간에 긴밀하게 통합이 되어있으며, 다른 3rd party 제품까지 다양하게 통합할 수 있다. Atlassian 은 제품마다 REST 형태의 API 를 제공하는데, 제품간에 응용 프로그램 수준의 인증이나 Oauth 인증 등 다양하게 각 제품을 연결할 수 있다.

필자는 Atlassian 제품은 모든 제품을 라이센스를 직접 구매하여 집에서 호스팅을 하면서 공부하는데, 서로 간에 긴밀하게 잘 통합되어 있으며, 상당히 많은 Addon이 제공되어 매우 쉽게 기능을 확장할 수 있다.

#1의 결론

이번 #1에서 이야기한 ‘팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #1’은 주로 TFS의 외적인 부분에서 언급하였다. 앞으로 TFS 제품을 Atlassian과 다른 오픈된 ALM 솔루션과 기능적인 면으로도 비교해 볼 예정이다.

이슈 관리/ 소스제어/ 빌드/ 테스팅/ 릴리즈, 그 외에 다양한 면에서 비교해 보면서 진짜 이유를 조금씩 파헤쳐 볼 것이다.

image-2
이미지 링크, 이런 것도 통합인가?

Posted by 땡초 POWERUMC

댓글을 달아 주세요

윈도우 8, 무서운 드라이버와 궁합

최악의 궁합, 윈도우 8

윈도우를 여지껏 사용하면서 드라이버와 충돌이 나면 이런 참사가 발생하는지 처음 알았다. 아니, 이렇게 발생할 수도 있는 것 자체가 신기하다.

SONY VPCZ115 시리즈를 사용하는데 SONY 노트북은 전통적으로(?) 그래픽 드라이버를 새로운 운영체제에 맞게 업데이트 안해준다. 그렇다고 공식 NVIDIA 사이트에서 받아서 설치하면 좋겠지만, 설치가 안된다. 드라이버 sys 엎어쳐도 보고 별짓을 다 해봤지만…

어느 날, 이 광경을 보자마자 순간 멍~~~

[이미지] 윈도우 잠금 상태가 한 쪽 모니터에서 풀린 사진

위 이미지의 증거 샷은

  • 점심 시간이라 CTRL+ALT+DEL 키를 눌러서 윈도우를 잠궜다.
  • 윈도우 8이 설치된 노트북으로 외부 모니터를 연결하고 쓰고 있는 중이다.
  • 외부 모니터에는 원격 서버 연결해서 서비스 중인 서버를 관리 중이었다.
  • 점심 먹고 오니, 저런 꼴이 되었다.
  • 외부 모니터는 마우스 커서도 움직인다.!

그 이후, 몇 일에 한 번 꼴로 계속 발생해서, 노트북 집 구석에 모셔다 놓았다.

윈도우 8 문제인가? 드라이버 문제인가?

사실, 그래픽 드라이버 문제인지 확실히 증명할 수는 없다. 증명해야 할 이유도 없거니와…

내 SONY 노트북 모델이 공식적으로 윈도우 8 드라이버를 공급해 주지 않기 때문에, 하위 호환성에 의지해서 모든 드라이버를 설치했다. 노트북 사용자는 어느 정도 어쩔 수 없지 않던가.

예전에 쓰던 노트북에 윈도우 XP 드라이버를 악평으로 악명 높은 윈도우 비스타(Windows Vista) 에 설치해서 잘 쓰던 때와 비교하면 윈도우 8은 너무나 관대하다.

드라이버가 안맞아서, 되지 말아야 할 것을, 얼마나 관대한지 잠금 상태에서도 모니터를 활짝 보여주니 말이다.

사용자 입장에서 SONY 노트북에선 드라이버 공식 업데이트가 없고, 윈도우 8에서는 하위 드라이버 호환성을 버리면, 뭐 노트북 갖다 버리라고? (이럴 때 윈도우 8 안쓰면 되겠지만 개발 환경 맞춰야 하는 경우가 대부분이라)

맥킨토시(Macintosh)의 OSX 운영체제와 리눅스 X-Windows 를 쓰면서 이런 적은 없었다. 물론 수 십년을 윈도우를 쓰면서 이런 적은 처음이다.

그나마 다행인 것이 일할 때 빼면(젠장 비주얼 스튜디오) 윈도우를 구동할 일도 없지만, 켤 때마다 윈도우를 써야 하는 내 상황에 그저 쓴 웃음만 나온다.

용도를 알 수 없는 매트로 시작 화면

또 하나, 방금 내가 뭘 설치하긴 했는데, 뭘 설치했지? 하고 매트로 시작 화면에 가서 찾아보려 해도 찾을 수 없다. (설치한 프로그램 이름이랑 개발사를 대충 보고 설치해서 기억이 안났다)

깨알 같은 아이콘과 텍스트로 어찌 찾는단 말인가. 찾다 찾다 못 찾아 다시 웹 사이트 방문해서 다시 다운로드 받고, 다시 설치하는 것이 훨씬 빨랐다.

또, 자주 쓰지 않는, 아주 가끔 돌리는 디스크 청소 프로그램이나 Disk Inventory X 같은 디스크를 스캔하여 비주얼로 보여주는 유틸리티는 반드시 이름을 외워야 한다. 못 외우면 깨알 같은 아이콘과 텍스트로 뒤져야 한다.

이런 경험을 여러 번 하게 되니 정신적인 안정을 위해 Star8 이라는 시작 메뉴 소프트웨어를 $4.99 주고 샀다.

다가오는 윈도우 8.1도 시작 메뉴로 장난질을 한다던데… 시작 메뉴의 부활이라고 하는데, 시작 메뉴 클릭하면 매트로 시작 화면으로 가는 바로 가기 버튼이란다. (ZDNET 및 IT 미디어 매체에 의하면…)

물론 매트로에서 재미를 즐기는 분들도 있겠지만, 그저 필자에게는 데스크탑으로 가기 위해 봐야하는 스팸 화면 정도? 윈도우 키를 잘못 누르기라도 하면 스팸 화면으로…

'O/S > Windows 8' 카테고리의 다른 글

윈도우 8, 무서운 드라이버와 궁합  (0) 2013.06.05
윈도우 8, 반토막짜리 WinRT와 WinRT SDK  (1) 2012.10.30
Posted by 땡초 POWERUMC

댓글을 달아 주세요

불완전한 통합, 모든 것을 만족할 수 있지만, 어느 것도 만족시킬 수 없다.

팀 파운데이션 서버(Team Foundation Server)는 모든 것을 통합한 마이크로소프트(Microsoft)의 ALM(Application Lifecycle Management) 솔루션이다.

통합… 모든 것을 만족할 수 있지만, 어느 것도 만족시킬 수 없다.이 통합이라는 것은 이 시대엔 단점으로 작용될 수도 있다는 생각이 든다. 지난 2005년부터 2010년까지 ‘통합’ 이라는 것이 장점이라고 생각했었다. 모든 것을 올인원(All in One) 해 놓았다는 것만으로 주목을 끌 수 있었지만, 2013년 최근에는 이제 더 이상 ‘통합’이 장점이 될 수 없다는 결론을 내렸다.


[이미지] 통합... 현실적인 통합과 이상적인 통합


(현실적인 통합?)
출처 : 이미지 링크

(이상적인 통합?)
출처 : 이미지 링크


필자는 비주얼 스튜디오 팀 시스템(Visual Studio Team System) 2005 버전부터 팀 파운데이션 서버(Team Foundation Server)를 사용해왔다. 필드에서는 이와 관련된 다수의 기업 컨설팅과 강의를 진행하였고, 그 외 레거시 개발 환경과 소스 컨트롤(Source Control)을 커스터마이징한 소프트웨어를 납품하는 등 대략 8년을 넘게 비주얼 스튜디오(Visual Studio)와 팀 파운데이션 서버(Team Foundation Server)와 동거동락하며 지냈다. 물론, 8년을 넘게 사용하면서 좋은 점도 많지만 그렇지 않은 점도 확실히 있다.

그 동안 한 가지 ALM 솔루션만 사용할 때는 미처 몰랐던 것들이 많았지만, 여러 가지 ALM 제품을 접하면서 ALM 솔루션 간에 장/단점을 필자의 기준에 좀 더 객관적으로 판단할 수 있는 계기가 되었다.

과거 ALM은 오픈 소스 진영을 중심으로 조금씩 발전해 왔다. SVN 소스 제어 컨트롤을 중심으로 각각 독립적인 유닛(Unit)으로 배포가 되고 플러그인 등을 활용하여 조금씩 연동을 할 수 있었다. 그런 와중에 마이크로소프트(Microsoft)는 개발툴과 ALM을 통합한 ‘팀 시스템(Team System)’ 발표하였고, 그 당시 여러 오픈 소스가 가진 것들을 한 곳에 통합하여 사용할 수 있었다. 이 때까지는 ‘통합’ 이라는 것 자체가 장점이던 시대이다.

하지만, 최근 ALM은 조직의 성숙도에 맞는 전문적인 ALM 툴을 사용하는 추세이다.

아쉽게도 팀 파운데이션 서버(Team Foundation Server)는 각각의 모든 기능들이 전문성을 갖추기에는 매우 부족한 것도 사실이다. ‘이슈 관리, 빌드, 소스 제어’, 아마도 딱 떠오르는 대표적인 벤더 및 오픈 소스들이 있을 것이다. 이슈 관리(Issue Managements), 빌드(Builds), 소스 제어(Source Control) 등, 타 벤더의 전문적인 툴과 비교하면 각각의 기능은 타 벤더에 비해 열악하다.

대표적인 ALM 벤더들과 차이가 나는 것은 마이크로소프트(Microsoft)의 팀 파운데이션 서버(Team Foundation Server)는 범용성을 추구하고, 전문적인 것들은 SDK(Software Development Kit)를 사용하여 커스터마이징을 하거나, 3rd party 벤더의 몫으로 남긴다. 대인배적인 모습이긴 하지만, 현재까지도 여전히 팀 파운데이션 서버(Team Foundation Server)를 중심으로 한 생태계가 형성되지 않았다는 것 또한 단점으로 작용한다.

필자는 최근 아틀라시안(Atlassian)의 ALM 제품에 매력을 느끼고 있다. 각각의 기능들이 매우 뛰어나고, 필요하다면 언제든지 필요한 기능의 소프트웨어와 통합이 가능하다. 설치부터 통합까지 매우 간단하다. 그리고 어떤 운영체제에서도 설치와 운영이 가능한 ‘크로스 플랫폼(Cross-Platform)’ 이라는 점은 팀이나 조직에서 선택의 폭이 넓고, 또 하나, 데이터베이스, 웹 서버 등 선택의 폭도 넓다. (반면, 팀 파운데이션 서버(Team Foundation Server)는 설치는 쉽지만 구성(Configuration)이 복잡하고 운영(Operation)에 더 많은 리소스가 필요하다)

그리하여 앞으로 필자는 여러 ALM 솔루션을 벤치 마킹하면서 ALM 솔루션들 간에 장단점 등을 비교/분석하여 함께 공유할 예정이다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Roslyn(로즐린)의 구성 요소

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


  1. Refrences  ↩

  2. CorFlags 변환 도구를 사용하면 이식 가능한 실행 이미지 헤더의 CorFlags 섹션을 구성할 수 있습니다.  ↩

  3. Reference : http://visualstudiomagazine.com/articles/2012/03/20/10-questions–10-answers-on-roslyn.aspx  ↩

  4. Cecil is a library written by Jb Evain to generate and inspect programs and libraries in the ECMA CIL format. It has full support for generics, and support some debugging symbol format.  ↩

  5. This documents the features available in the C# interactive shell that is part of Mono’s C# compiler. An interactive shell is usually referred to as a read eval print loop or repl. The C# interactive shell is built on top of the Mono.CSharp library, a library that provides a C# compiler service that can be used to evaluate expressions and statements on the flight as well as creating toplevel types (classes, structures, enumerations).  ↩

  6. Ahead of Time Compilation or AOT is a feature of the Mono runtime code generator.  ↩

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 김아동 2015.05.13 08:38 Address Modify/Delete Reply

    닷넷으로 윈도우 응용 프로그램을 개발하고 있고, wpf를 사용해서 편리하게 개발을 하고 있지만 많이 투자해서 배울 만한 엔진은 아닌 거 같다라는 생각이 많이 들긴 합니다.
    자바로는 뭔가 부족하고, Qt가 답인가 .. 생각해봅니다.

    • 땡초 2015.05.13 16:31 Address Modify/Delete

      네 말씀하신 것에 공감합니다.
      기술이 벤더에 너무 국한되어 있고,
      최근 Xamarin 유니버셜 앱 개발에 XAML 이 쓰이지만,
      WPF 와 호환이 전혀되지 않습니다.

      많이 배울 수는 있지만, 활용할 수 있는 범위가 너무 국한되어 있는 것 같아요.

본 아티클은 MSDN 에 eBook으로 공개된 문서를 블로그 아티클로 편집하였습니다. VSTS 팀블로그에 의해 작성된 문서의 원문 및 여러 가지 기술 문서는 아래의 링크에서 PDF로 다운로드 받을 수 있습니다. 그리고 본문의 특정 버전을 지칭하는 개발툴 버전 번호는 모두 Visual Studio로 변경되었음을 참고하십시오. (예- Visual Studio 20xx는 Visual Studio로 표기함 )

VSTS 팀블로그 MSDN 기술 문서 : http://msdn.microsoft.com/ko-kr/gg620748 

필자 소개

Microsoft Visual Studio ALM MVP 엄준일
http://blog.powerumc.kr

 

Visual Studio Korea Team Blog
http://vsts2010.net

감수 : 강성재 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

   

도움주신 분 : 김남영 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

 

[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 1/7 - 들어가기에 앞서...
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 2/7 - 왜 모델링인가?
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 3/7 - 모델링의 표기
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 4/7 - 모델링 다이어그램
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 5/7 - Visualization & Features Pack
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 6/7 - 모델링 확장 (SDK)
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 7/7 - 결론 및 저자 소개

 

8. 결론

백서에서 지금까지 Visual Studio을 활용하여 어플리케이션을 모델링하고 그리고 모델링을 확장하여 잘 이용할 수 있는 여러 가지 기능과 방법을 설명하였습니다. 혹여 이 백서를 읽는 독자가 회사에서 UML 또는 모델링을 하는 업무나 직책을 갖지 않더라도 분명히 모델링은 개발자 사이에도 어느 정도 필요로 합니다.

소위 개발자들은 "코드로 말한다" 라고 강조하기도 합니다. 하지만 코드로 말하기 전에 자신의 의도와 노력을 시각적으로 표현하기 위해 노력하는 방법도 매우 중요합니다. 그것은 코드가 완성이 되기 전에 서로 간의 커뮤니케이션을 할 수 있으므로 이해 관계가 복잡해 질 때 먼저 자신의 의도와 노력을 상대에게 이해시킬 수 있는 좋은 방법이 바로 모델링이기 때문입니다.

이러한 모델링 습관은 매우 좋은 현상입니다. 예전에 값 비싼 도구로 모델링을 할 수 있었지만 이제는 Visual Studio으로 시스템의 설계나 코드의 설계, 그리고 기존 코드를 시각화 함으로써 서로 간에 시스템이나 어플리케이션의 설계 또는 코드를 쉽게 이해하고 접근하는 좋은 방법이기도 합니다.

더불어 Visual Studio의 모델링은 지속적으로 발전하고 있고 다양한 모델링 확장 기능을 Visual Studio Gallery 사이트에서 제공하고 있습니다. 모델링은 통합 개발 도구와 통합하여 보다 기존보다 좀더 생산성 있고 가치 있는 활동을 하나의 도구에서 모두 할 수 있으며, 이러한 여러분의 노력이 한 걸음 더 뻗어 나갈 수 있는 좋은 스킬이 되리라 필자는 확신을 합니다.

 

  • 저자 소개
    현재 필자는 NCSOFT에 재직하지 않음을 참고하기 바랍니다.


  • 오픈 소스 개발

1) MEFGeneric (2010년) - http://mefgeneric.codeplex.com/
.NET Framework 4.0에 포함된 MEF 라이브러리가 제공하지 않는 제네릭(Generic) 타입을 지원하도록 개선한 프로젝트

2) VSGesture for Visual Studio (2010년~) - http://vsgesture.codeplex.com/
Visual Studio에서 마우스 제스처를 통해 빌드, 디버깅, 화면 제어를 하는 확장 도구 프로젝트

3) Umc.Core Enterprise Framework(2012년~) - http://umccore.codeplex.com/
IoC, AOP, Build, Mapping 등의 오픈 소스를 직접 구현하여, 하나의 엔터프라이즈 프레임워크로 제공하는 프로젝트

4) vutpp for Visual Studio (2011년~) - http://vutpp.codeplex.com/
Visual C++ 에서 단위 테스트를 지원하는 확장 도구 프로젝트

5) jQuery DateTimePicker Plugin (2012년) - http://umcdatetimepicker.codeplex.com/
jQuery Plugin 중 DatePicker에 시간 선택 기능을 추가한 jQuery 플러그인 프로젝트

6) 설치형 블로그 (2007년) – http://blog.powerumc.kr/30
ASP.NET 국내 최초로 오픈 소스로 공개된 설치형 블로그 프로젝트

 

  • MSDN (개발자 네트워크) 기술 자료 제공 (PDF)

1) MSDN 게시: Visual Studio 응용 프로그램 모델링 완전 정복 백서
2) MSDN 게시 및 출판 : Visual Studio 2010 을 활용한 ALM(Application Lifecycle Management)
3) MSDN 게시: Team Foundation Server 2010 설치 가이드 (단일 서버)
4) MSDN 게시: Team Foundation Server 2010 설치 가이드 (다중 서버)
5) MSDN 게시: Team Foundation Server 2010 설치 가이드 (Lab 구성)
6) MSDN 게시: Team Foundation Server 2010 활용 가이드 (FQDN 설정)
7) 7) MSDN 게시: VSS 사용자를 위한 Team Foundation Server 2010 시리즈 (WORKGROUP 설치가이드)
8) MSDN 게시: VSS 사용자를 위한 Team Foundation Server 2010 시리즈 (활용가이드)
9) MSDN 게시: VSS 사용자를 위한 Team Foundation Server 2010 시리즈 (마이그레이션가이드)

 

  • 월간 마이크로소프트 비정기 기술 자료 기고

1) 2008년 10월호 : Visual Studio 2008 Service Pack 1 with .NET Framework 3.5 SP1
2) 2009년 08월호 : Visual Studio 2010
3) 2010년 03월호 : 닷넷 길라잡이 | ALM의 정의와 세 가지 요소
4) 2010년 04월호 : 닷넷 길라잡이 | Visual Studio 2010을 활용한 ALM
5) 2010년 05월호 : 닷넷 길라잡이 | 명확한 작업의 관리와 지속적인 통합 - 추적성
6) 2010년 06월호 : 닷넷 길라잡이 | 과거와 현재를 알면 미래가 보인다 - 가시성
7) 2010년 07월호 : 닷넷 길라잡이 | 테스트와 가상화의 만남
8) 2012년 05월호 : 비주얼 스튜디오 11, 윈도우8 시대를 대비하자, C++/CX 이해하기

 

  • ZDNET Korea 비정기 기술 자료 기고

1) 2010년 04월 28일 : 지속적인 통합을 넘어선 ALM의 미래-1
2) 2010년 05월 01일 : 지속적인 통합을 넘어선 ALM의 미래-2

 

  • 세미나

1) Visual Studio Camp #1 : (2010/08/28) 소프트웨어 품질 향상을 위한 다양한 테스트 기법
2) REMIX10 : (2010/06/01) : 혁신적인 프로그램을 만드는 .NET 4 와 비주얼 스튜디오 2010
3) TECHDAYS 2010 : NET Framework 4.0, MEF(Managed Extensibility Framework)
4) TECHDAYS 2009 : Visual Studio Team System 2010 With Agile
5) DEVDAYS 2008 : 개발자가 꼭 알아야 할 .NET 프레임워크 하이라이트 – 2.0에서 3.5 SP1 까지
6) Microsoft MVP 대상 기술 세미나 : (2009/01/14) Visual Studio Team System 2010
7) Visual Studio 팀 세미나 : MEF(Managed Extensibility Framework) within .NET Framework 4.0
8) 첨단 기업 연구소를 위한 무결점 소프트웨어 세미나 : (2012/04/24)

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 1 2013.03.27 20:20 Address Modify/Delete Reply

    프로그래머와 작업의뢰인의 거래사이트 "오투잡"

    오투잡은 현재 하루 접속자 3000명이 접속하는 재능거래 사이트 입니다.
    오픈한지 얼마되지 않았지만 부업분야 전체 점유율 2위, 국가지원을 받고있습니다.

    오투잡에서 판매자 대모집 중입니다.
    카테고리 활성화가 시작 되니, 많은 판매 등록 바랍니다.
    오투잡은 네이버에서 "오투잡" 으로 검색 하세요.

본 아티클은 MSDN 에 eBook으로 공개된 문서를 블로그 아티클로 편집하였습니다. VSTS 팀블로그에 의해 작성된 문서의 원문 및 여러 가지 기술 문서는 아래의 링크에서 PDF로 다운로드 받을 수 있습니다. 그리고 본문의 특정 버전을 지칭하는 개발툴 버전 번호는 모두 Visual Studio로 변경되었음을 참고하십시오. (예- Visual Studio 20xx는 Visual Studio로 표기함 )

VSTS 팀블로그 MSDN 기술 문서 : http://msdn.microsoft.com/ko-kr/gg620748 

필자 소개

Microsoft Visual Studio ALM MVP 엄준일
http://blog.powerumc.kr

 

Visual Studio Korea Team Blog
http://vsts2010.net

감수 : 강성재 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

   

도움주신 분 : 김남영 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

 

[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 1/7 - 들어가기에 앞서...
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 2/7 - 왜 모델링인가?
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 3/7 - 모델링의 표기
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 4/7 - 모델링 다이어그램
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 5/7 - Visualization & Features Pack
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 6/7 - 모델링 확장 (SDK)
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 7/7 - 결론 및 저자 소개

 

7. Visual Studio Modeling SDK

Vual Studio 2010 SDK(Software Development Kit)은 기존의 Visual Studio의 기능을 확장할 수 있는 도구를 지원해 주고 있습니다. 이 내용에 대해 자세한 내용은 필자의 블로그의 다음의 글을 참고 하십시오.

참고

[VSX] 1. Visual Studio Extensibility,, 그 시작

http://blog.powerumc.kr/232

 

7.1. 개발 환경 및 설치 요구 사항

Visual Studio 모델링 프로젝트를 확장하기 위해 먼저 Visual Studio SDK를 설치해야 합니다. Visual Studio SDK 는 아래의 다운로드 주소를 통해 다운로드 받으실 수 있습니다.

Visual Studio SDK 다운로드

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5&displaylang=en

 

시스템 요구 사항

  • Supported Operating Systems: Windows 7;Windows Server 2003 R2 (32-Bit x86);Windows Server 2003 R2 x64 editions;Windows Server 2003 Service Pack 2;Windows Server 2008 R2;Windows Server 2008 Service Pack 2;Windows Vista Service Pack 2;Windows XP Service Pack 3
    • Windows XP (x86) with Service Pack 3 - all editions except Starter Edition
    • Windows Vista (x86 & x64) with Service Pack 2 - all editions except Starter Edition
    • Windows 7 (x86 and x64)
    • Windows Server 2003 (x86 & x64) with Service Pack 2 - all editions
    • Users will need to install MSXML6 if not already present
    • Windows Server 2003 R2 (x86 and x64) - all editions
    • Windows Server 2008 (x86 and x64) with Service Pack 2 - all editions
    • Windows Server 2008 R2 (x64) - all editions

 

Visual Studio 2010 요구 사항

  • Visual Studio 2010 Professional or better

 

7.2. Layer Diagrams 확장하기

Visual Studio  SDK와 Visual Studio 2010 Visualization & Modeling Features Pack을 설치하면 Layer Diagrams을 확장할 수 있는 프로젝트 템플릿이 설치가 됩니다.

새 프로젝트 만들기에서 모델링 프로젝트->Extensibility 를 선택하면 세 가지의 새로운 템플릿이 생성이 된 것을 확인할 수 있습니다.

각 템플릿은 Layer Diagrams을 확장하기 위해 아래와 같은 기능을 수행하는 템플릿입니다.

  • Command Extension
    Layer Diagrams에 특정 컨텍스트 메뉴를 통해 명령을 수행할 수 있는 확장 기능을 만들 수 있습니다.

  • Gesture Extension
    Layer Diagrams으로 끌어오기 동작 등의 확장 기능을 만들 수 있습니다.

  • Validation Extension
    Layer Diagrams과 코드의 구조가 유효한지 검사하는 확장 기능을 만들 수 있습니다.

 

7.2.1. 레이어 개수를 세는 Command Extension 만들기

 

7.2.1.1. Layer Diagrams Command Extension 프로젝트 생성

우선 간단한 Command Extension을 만들기 위해 Command Extension 템플릿으로 프로젝트를 생성합니다. 프로젝트의 이름을 CustomLayerCommand (또는 희망하는 이름으로) 프로젝트를 생성합니다.

 

간단히 생성된 프로젝트를 실행 또는 디버깅 하기 위해서 생성된 Command Extension 프로젝트를 선택하여 마우스 오른쪽 버튼을 클릭하여 시작 프로젝트로 설정합니다.

 

그런 다음 F5 키를 눌러 디버깅을 시작합니다. F5키를 눌러 디버깅을 시작하면 Visual Studio 2010은 별도의 레지스트리를 사용하는 Experimental 모드로 실행을 하게 되어 기존의 Visual Studio 2010에 영향이 없도록 동작하게 됩니다.

 

7.2.1.2. Layer Diagrams에 명령 코드 만들기

Visual Studio 의 새로운 확장 기능은 .NET Framework 4.0에 포함되는 MEF(Managed Extensibility Framework)를 사용하여 확장 기능을 만들 수 있습니다. 모델링 확장 기능 또한 MEF를 사용하여 확장할 수 있으며 MEF에 대한 자세한 내용은 필자의 블로그를 참고 하시기 바랍니다.

참고

MEF(Managed Framework Extensibility) 연제
http://blog.powerumc.kr/189

 

우선 클래스의 선언은 다음과 같이 되어 있습니다 아래와 같이 ExportAttribute을 사용하여 ICommandExtension 형식을 Visual Studio 모델링에서 인식할 수 있도록 컴포넌트 계약을 합니다. 그리고 LayerDesignerExtensionAttriburte을 추가하면 Layer Diagrams에서 ICommandExtension 확장 기능을 사용할 수 있도록 합니다.

[Export(typeof(ICommandExtension))]
[LayerDesignerExtension]
public partial class CustomLayerCommandExtension : ICommandExtension 


클래스 내부에 Import된 IDiagramContext는 현재 다이어그램의 컨텍스트 개체로 이 개체를 이용하여 특정 명령을 내릴 때 다양한 작업을 수행할 수 있습니다.

[Export(typeof(ICommandExtension))]
[LayerDesignerExtension]
public partial class CustomLayerCommandExtension : ICommandExtension
{
    [Import(typeof(IDiagramContext))]
    public IDiagramContext DiagramContext { getset; } 


ICommandExtension의 인터페이스는 Text 속성을 구현해야 하는데 이 속성은 다이어그램 컨텍스트 메뉴에서 표시되는 메뉴 이름입니다.

public string Text
{
    get	
    {
        return "레이어 개수";
    } 
} 


ICommandExtension의 인터페이스는 QueryStatus를 구현해야 하는데, 현재 상태에서 컨텍스트에 표시될 수 있는지 여부를 나타내게 됩니다. 조건에 따라 다른 표시/보이기 등의 동작이 필요하다면 아래의 코드를 수정하시면 됩니다.

public void QueryStatus(IMenuCommand command)
{
            command.Visible = true;
            command.Enabled = true} 


마지막으로 ICommandExtension의 Execute 메서드를 구현합니다. 이 메서드는 Layer Diagrams의 레이어 개수를 계산하기 위해 재귀 호출을 통해서 레이어 요소의 개수를 카운트합니다.

public void Execute(IMenuCommand command)
{
    int layerCount = 0;
    this.VisitDiagramElement(this.DiagramContext.CurrentDiagram.Diagram.ChildShapes, ref layerCount);

 

    MessageBox.Show(String.Format("레이어의 개수는 모두 {0}  입니다.", layerCount));            
}

 

private void VisitDiagramElement(IEnumerable<IShape> shapes, ref int layerCount)
{
    foreach (var shape in shapes)
    {
        if (shape != null && shape.GetLayerElement() is ILayer)
        {
            layerCount++;

 

            if( shape.ChildShapes.Count() > 1) 
                this.VisitDiagramElement(shape.ChildShapes.Skip(1), ref layerCount);
        }
    } 
} 


7.2.1.3. Layer Diagrams 코드 실행 결과

먼저 작성된 코드를 실행하기 위해 Visual Studio 에서 Command Extension을 시작 프로젝트로 설정한 후에 F5 키를 눌러 Visual Studio Experimental 모드로 실행을 할 수 있습니다. 만약 디버깅이 필요하지 않다면 Ctrl+F5 키를 눌러 디버깅 없이 실행하여 실행 속도를 높일 수 있습니다.

위의 코드는 다음과 같이 Layer Diagrams에서 마우스 오른쪽 버튼을 눌러서 활성화할 수 있습니다. 다음과 같이 Text 속성의 반환 값이 메뉴의 이름이 되는 것을 확인할 수 있습니다.

 

해당 메뉴를 클릭하면 Execute 메서드가 실행이 되고 메시지 상자에 Layer Diagrams에 포함된 모든 레이어의 개수를 표시해 줍니다.

 


7.2.2. 폴더 구조를 DRAG&DROP 하는 Gestures Extension 만들기

7.2.2.1. Geatures Extension 프로젝트 만들기

새로운 프로젝트를 생성하는 메뉴에서 모델링 프로젝트->Extensibility 항목에서 Layer Designer Gesture Extension 을 선택하고 확인을 클릭합니다.

 

이 후 설정은 Layer Diagrams Command Extension 프로젝트 생성 항목을 참고하십시오.

 

7.2.2.2. 폴더를 Drag&Drop 하는 코드 만들기

Gesture Extension 은 IGestureExtension 인터페이스를 구현합니다. 이 인터페이스를 상속하는 클래스를 만든 후에 ExportAttribute을 통해 Visual Studio 2010의 모델링 Geature Extension과 계약 관계를 형성합니다.

[Export(typeof(IGestureExtension)), LayerDesignerExtensionpublic partial class CustomLayerGestureExtension : IGestureExtension 


폴더를 Drag&Drop 하는 코드 전체는 다음과 같습니다.


[Export(typeof(IGestureExtension)), LayerDesignerExtension]
partial class CustomLayerGestureExtension : IGestureExtension
{

        [Import(typeof(IDiagramContext))]
        public IDiagramContext DiagramContext { getset; }

 

        public void OnDoubleClick(IShape target) { }

 

        public bool CanDragDrop(IShape target, IDataObject data)
        {
            var folders = data.GetData(DataFormats.FileDrop) as String[];
            if (folders == null)
            {
                MessageBox.Show("가져올 데이터가 없습니다.");
            }

 

            var isValidate = true;
            foreach(var folder in folders)
            {
                if( System.IO.Directory.Exists(folder) == false )
                {
                    isValidate = false;
                    break;
                }
            }

 

            return true;
        }

 

        public void OnDragDrop(IShape target, IDataObject data)
        {
            var folders = data.GetData(DataFormats.FileDrop) as String[];

 

            foreach (var folder in folders)

            {                 var dirInfo = new System.IO.DirectoryInfo(folder);                 target.Diagram.GetLayerModel().CreateLayer(dirInfo.Name);             }         } }

 


7.2.2.3. 폴더를 Drag&Drop 하는 Gesture Extension 코드 실행 결과

먼저 테스트로 진행할 모델링 프로젝트를 생성한 후에 Layer Diagrams 항목을 추가 합니다.

그리고 윈도우 탐색기를 열어 드래그할 폴더를 다음과 같이 선택합니다.

 

선택할 폴더 항목을 Visual Studio 2010의 다이어그램 디자이너에 Drag하여 Drop합니다.

 

Drop 결과 해당하는 폴더의 이름대로 Layer Diagrams의 레이어 요소가 생성이 되는 결과를 확인할 수 있습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

본 아티클은 MSDN 에 eBook으로 공개된 문서를 블로그 아티클로 편집하였습니다. VSTS 팀블로그에 의해 작성된 문서의 원문 및 여러 가지 기술 문서는 아래의 링크에서 PDF로 다운로드 받을 수 있습니다. 그리고 본문의 특정 버전을 지칭하는 개발툴 버전 번호는 모두 Visual Studio로 변경되었음을 참고하십시오. (예- Visual Studio 20xx는 Visual Studio로 표기함 )

VSTS 팀블로그 MSDN 기술 문서 : http://msdn.microsoft.com/ko-kr/gg620748 

필자 소개

Microsoft Visual Studio ALM MVP 엄준일
http://blog.powerumc.kr

 

Visual Studio Korea Team Blog
http://vsts2010.net

감수 : 강성재 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

   

도움주신 분 : 김남영 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

 

[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 1/7 - 들어가기에 앞서...
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 2/7 - 왜 모델링인가?
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 3/7 - 모델링의 표기
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 4/7 - 모델링 다이어그램
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 5/7 - Visualization & Features Pack
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 6/7 - 모델링 확장 (SDK)
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 7/7 - 결론 및 저자 소개

 

6. Visual Studio Visualization & Modeling Features pack

Visual Studio Visualization & Modeling Features Pack(이하 Modeling Features Pack)은 2010년 12월 4일 MSDN 구독자에게 공개가 되었습니다. 이 Modeling Features Pack은 기존의 모델링 프로젝트에서 지원하지 않았던 몇 가지 기능을 보강하는 도구로써 Modeling Features Pack과 Modeling Features Pack Runtime을 제공해 줍니다.

 

6.1. Modeling Features Pack 개요

Visual Studio의 Modeling Features Pack은 다음과 같은 기능을 제공해 줍니다.

  • C++ 및 ASP.NET 프로젝트의 종속성 그래프 지원
  • C++ 코드에서 Layer Diagrams의 아키텍처 유효성 지원
  • UML Class Diagrams을 코드로 변환하거나 코드를 UML 다이어그램으로 변환
  • XMI 2.1 파일로 내보내기 기능
  • 다이어그램의 요소와 Team Foundation Server의 작업 항목 연동 강화
  • Layer Diagrams 확장

 

6.2. ASP.NET 웹 프로젝트의 종속성 그래프 분석

기존에 종속성 그래프 분석은 닷넷의 어셈블리나 클래스를 기준으로 분석이 되어 웹 프로젝트의 경우 ASPX 파일이나 그에 해당하는 종속성을 분석하기란 사실상 불가능 하였습니다. 다만 웹 프로젝트를 클래스나 어셈블리 수준에서 분석이 가능하였으나 웹 프로젝트 특성을 잘 반영한 종속성을 분석하기는 어려움이 많았습니다.

이번 ASP.NET 종속성 그래프는 웹 프로젝트라는 특성을 잘 반영하여 페이지 파일이나 공통되는 마스터 페이지 등 종속성 분석이 한결 자연스러워졌습니다.

ASP.NET 종속성 그래프 생성은 다음과 같은 웹 프로젝트 형식을 지원합니다.

  • ASP.NET 웹 사이트
  • ASP.NET 웹 프로젝트
  • ASP.NET MVC 웹 프로젝트

 

6.2.1. 웹 프로젝트 종속성 그래프를 만들려면?

  1. 종속성 그래프를 분석할 웹 프로젝트를 로드 합니다.
  2. 아키텍처->종속성 그래프 생성에 By Web Site 외 모두 두 가지 항목이 새로 생겼습니다. 코드 종속성과 함께 ASP.NET 웹 프로젝트를 분석하려면 By Web Site with Code Dependencies 를 선택합니다.


  3. 솔루션에서 웹 프로젝트의 종속성을 분석합니다.

     

  4. 다음은 웹 프로젝트의 전체를 코드 종속성 분석과 함께 분석된 결과 입니다.

     

 

6.2.2. 종속성 그래프를 분석하려면?

다음과 같이 종속성 그래프를 확대하면 각 페이지 간의 종속성을 보여줍니다.

이 종속성 그래프는 DGML(Directed Graph Markup Language)로써 웹 프로젝트 뿐만 아니라 Visual Studio의 전반적인 분석에 사용되는 전용 마크업 언어이기도 합니다.

만약 특정 페이지가 어떤 모듈이나 페이지간에 종속성을 미치는지 확인하기 위해서 해당 노드를 선택하면 됩니다. 예를 들어 아래의 AccountController 클래스가 가지는 종속적인 관계는 ChangePassword.aspx, ChangePasswordSuccess.aspx 등의 각 페이지들과 인증과 관련된 FormAuthenticationService, ChangePasswordModel 클래스 등에 종속적인 관계를 갖는 것을 확인할 수 있습니다.

 

이 AccountController 클래스의 내부를 좀더 자세히 보기 위해서는 AccountController 노드의 오른쪽 상단의 화면표 아이콘을 선택합니다.

 

그럼 AccountController가 구현하는 메서드나 프로퍼티 정보를 표시합니다.

 

만약 이 메서드들이 어떤 종속성을 갖는지 알기 위해서 메서드의 하나의 노드를 선택하면 됩니다. 예를 들어 아래의 get_MembershipService (원래는 속성(Property)임)은 다양한 메서드에서 호출되는 속성인 것을 확인할 수 있습니다.

 

이러한 종속성 정보는 얼마나 복잡하게 서로간에 영향력을 미치는지 알 수 있습니다. 예를 들어, 화살표를 많이 받으면 받을수록 그 코드의 변경이 주는 전파력은 상당히 높아지며, 코드에 버그가 있다면 그 버그의 전파력은 종속성이 갖는 크기만큼인 것이 될 것이라 예상할 수 있습니다.

 

종속성 그래프에서 화살표를 더블 클릭하여 분석할 종속성의 레벨을 지정할 수 있습니다.

 

만약 웹 프로젝트를 코드 레벨에서 분석을 하길 원한다면 종속성 그래프의 컨텍스트에서 마우스 오른쪽 버튼을 클릭하여 Get Code Dependencies 를 선택합니다.

 

그럼 웹 프로젝트의 노드를 확장하면 웹 프로젝트의 페이지 등의 종속성의 분석이 아닌 코드 레벨에서 종속성을 분석해 줍니다.

 

코드 레벨의 종속성을 분석하면 다음 그림과 같이 해당 노드와 종속되는 페이지를 확인할 수 있습니다.

 

 

6.3. UML 다이어그램과 코드 간의 상호 변환

 

6.3.1. Class Diagrams을 코드로 변환하기

Class Diagrams을 코드로 변환하기 위해서 모델링 프로젝트에서 UML Class Diagrams을 새로 추가 합니다.

 

  1. 간단하게 다음과 같이 클래스 모델링을 해 봅시다. 각각 Member, Phone, Address 클래스 요소를 추가 합니다.


  2. Member 클래스 요소를 Phone, Address 클래스 요소와 연결(Association) 관계로 만듭니다. 연결 관계로 만들기 위해서 Member 클래스 요소를 마우스 오른쪽 버튼으로 클릭한 후 추가->연결(Association) 항목을 클릭하여 각각 Phone, Address 클래스 요소와 연결합니다.


  3. 다음의 그림은 연결(Association) 을 Phone, Address 클래스 요소와 연결한 그림입니다.


  4. 모든 작업이 완료 되었으면 Class Diagrams의 컨텍스트 메뉴에서 Generate Code 를 클릭합니다.


  5. 다음과 같이 새로운 프로젝트가 생성이 되고, GenerateCode 폴더에 Class Diagrams의 클래스 요소들이 코드로 변환이 됩니다.


  6. Member.cs 클래스 파일은 다음과 같이 Phone, Address 클래스와 연결 관계가 속성으로 변환이 된 것을 확인할 수 있습니다.

 

 

6.3.2. 코드를 Class Diagrams으로 변환하기

마찬가지로 Visual Studio Modeling Features Pack은 기존에 존재하는 코드를 UML Class Diagrams으로 변환할 수 있습니다.

 

  1. 아래와 같이 간단하게 코드를 작성합니다. 기존 코드가 있으시면 기존 코드를 사용하셔도 무방합니다.

     

  2. 만약 모델링 프로젝트가 현재 솔루션에 없다면 모델링 프로젝트를 생성합니다. 아키텍처->새 다이어그램을 선택하여 UML Class Diagrams을 생성합니다.

  3. 아키텍처->창->아키텍처 탐색기를 선택합니다.



  4. 아키텍처 탐색기에서 UML Class Diagrams으로 변환할 코드를 찾아 선택합니다.


  5. 선택한 클래스 또는 코드 파일을 UML Class Diagrams 디자이너로 드래그&드랍 합니다.


  6. 그럼 기존의 코드가 아래와 같이 UML Class Diagrams으로 변환이 완성되었습니다.

 

 

6.4. XMI 가져오기

XMI(XML Metadata Interchange)는 메타데이터를 통해 정보를 교환하기 위한 표준으로 XML 형식의 데이터를 사용합니다. 다양한 모델링 프레임워크나 도구에서 독자적인 포멧을 사용하지만 XMI 내보내기 등의 기능으로 다양한 모델링 도구에서 모델링 정보를 교환하거나 공유할 수 있습니다. (참고 http://en.wikipedia.org/wiki/.xmi)

이 표준 모델링 다이어그램의 XMI 를 Visual Studio에서 불러올 수 있는 기능을 제공합니다. XMI 파일을 가져오려면 다음과 같이 진행하시면 됩니다.

만약 사용할 수 있는 .XMI 파일이 없다면 다음의 전자정부 표준 프레임워크 사이트에서 샘플을 다운로드 받으실 수 있습니다. (http://open.egovframe.go.kr/scm/viewvc.php/trunk/DEV_IDE_PLUGIN/egovframework.dev.imp.codegen.modeltest/xmi_sample/sample.xmi?diff_format=s&logsort=cvs&sortby=log&view=markup&root=egovframedev)

 

  1. 아키텍처->Import XMI… 을 선택합니다.



  2. 확장명이 .XMI 인 파일을 찾아 선택한 후 확인을 클릭합니다.


  3. 가져온 XMI 요소의 형식을 확인하려면 아키텍처->창->UML 모델 탐색기를 선택합니다.


  4. UML 모델 탐색기에 XMI 파일에서 가져온 요소가 나타납니다.

 

 

6.5. Team Foundation 2010 연동

기존의 Visual Studio 모델링 프로젝트는 Team Foundation Server 작업 항목과의 연동을 이미 지원했습니다. 하지만 UML 다이어그램의 요소와 작업 항목과의 연결이나 관리 작업 부분에서 불편한 점이 있었습니다.

이번 Modeling Features Pack 은 Team Foundation Server와 연동하면서 바로 작업을 연결하거나 만들고, 또는 추적할 수 있는 부분이 강화되어 다이어그램과 작업 간의 관리가 훨씬 용이해 졌습니다.

 

6.5.1. 다이어그램의 요소와 작업 연결

모델링 프로젝트의 다이어그램의 모든 요소는 Team Foundation Server에 작업을 만들거나 연결할 수 있습니다. 가령, 모델리한 컴포넌트를 특정 개발자에게 작업을 할당하거나 그 작업의 진척율을 확인하고 보고를 받을 수 있습니다.

 

6.5.1.1. 모델링 프로젝트에서 작업을 만들려면?

  1. 먼저 작업과 연결할 모델링 다이어그램을 엽니다. 작업과 연결할 요소에 마우스 오른쪽 버튼을 클릭하여 작업 항목 만들기-><작업항목형식> 을 선택합니다.



  2. 작업 항목 만들기 화면에서 필요한 항목을 입력한 후 작업 항목 저장 버튼을 클릭합니다.



  3. Class Diagrams의 요소에 작업 항목이 연결되었음을 의미하는 아이콘이 표시되고, 요소의 속성 창에 1개의 작업 항목이 연결된 표시가 나타납니다.

 

6.5.1.2. 다이어그램 요소에 연결된 작업 항목을 보려면?

요소에 작업 항목이 연결이 되면 요소의 오른쪽 상단에 작업 항목이 연결되었음을 의미하는 아이콘이 표시됩니다. 이 아이콘이 표시된 다이어그램의 요소는 어떤 작업 항목이 연결되었는지 확인할 수 있습니다.

  1. 다이어그램 요소와 작업 항목이 연결된 요소에 마우스 오른쪽 버튼을 클릭하여 작업 항목 보기를 선택합니다.



  2. 다이어그램 요소와 연결된 작업 항목 목록이 나타납니다.

 

6.5.1.3. 다이어그램의 요소와 연결된 작업 항목을 제거하려면?

다이어그램의 요소와 연결된 작업 항목을 삭제하기 위해서 다음의 순서로 진행하십시오.

  1. 다이어그램 요소와 작업 항목이 연결된 요소에 마우스 오른쪽 버튼을 클릭하여 작업 항목 제거를 선택합니다.



  2. 작업 항목 제거 대화 상자에서 연결을 해제할 작업 항목의 체크 박스를 해지합니다. 체크 박스 해지 작업이 완료되면 확인을 클릭합니다.

     

  3. 다이어그램의 요소가 작업 항목에서 제거되어 작업 항목 연결을 의미하는 아이콘이 삭제된 것을 확인합니다.

 

6.6. Visual Studio Layer Diagram Extension

Visual Studio Modeling Features Pack은 Layer Diagrams의 유효성을 검사하거나 아키텍처 유효성을 검증하는 기능이 포함되어 있습니다. 이 Layer Diagrams의 유효성 검증과 명령 등을 확장하기 위해서 추가적인 Visual Studio SDK가 필요합니다.

이 단원은 [Visual Studio Modeling SDK] 단원을 참고 하십시오.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

본 아티클은 MSDN 에 eBook으로 공개된 문서를 블로그 아티클로 편집하였습니다. VSTS 팀블로그에 의해 작성된 문서의 원문 및 여러 가지 기술 문서는 아래의 링크에서 PDF로 다운로드 받을 수 있습니다. 그리고 본문의 특정 버전을 지칭하는 개발툴 버전 번호는 모두 Visual Studio로 변경되었음을 참고하십시오. (예- Visual Studio 20xx는 Visual Studio로 표기함 )

VSTS 팀블로그 MSDN 기술 문서 : http://msdn.microsoft.com/ko-kr/gg620748 

필자 소개

Microsoft Visual Studio ALM MVP 엄준일
http://blog.powerumc.kr

 

Visual Studio Korea Team Blog
http://vsts2010.net

감수 : 강성재 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

   

도움주신 분 : 김남영 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

   

[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 1/7 - 들어가기에 앞서...
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 2/7 - 왜 모델링인가?
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 3/7 - 모델링의 표기
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 4/7 - 모델링 다이어그램
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 5/7 - Visualization & Features Pack
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 6/7 - 모델링 확장 (SDK)
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 7/7 - 결론 및 저자 소개

 

5. Visual Studio Modeling

Visual Studio의 모델링 다이어그램은 여러 가지 요구 사항 및 코드를 이해하고 명확하게 의견을 교환하는데 도움을 줍니다. 예를 들면, 사용자의 요구 사항을 Use Case Diagram이나 Sequence Diagram은 개발자에게 매우 유용합니다. 또한 시스템적으로는 Component Diagram, Activity Diagram, Layer Diagrams을 사용합니다.

이러한 여러 가지 다이어그램은 이해 관계자를 이해하고 큰 틀을 표현하는데 매우 효과적이지만, 가장 중요한 것은 이것들을 코드로 표현하는 것이며, 특히 Visual Studio Modeling은 개발자가 올바르게 모델을 구현할 수 있는 수단이 됩니다. 애자일에서 소스 코드가 산출물이라는 잘못된 강박관념에서 벗어나, 오히려 적절한 시점에 초기에 모델링을 하는 것은 매우 효과적이기도 합니다.

 

위의 그림에 정말로 아름다운 보름달이 있습니다. 하늘에 구름 한 점 없는 추석에 볼 수 있는 보름달이죠. 지금 독자 여러분은 모두 이 보름달을 바라보고 있지만, 사실 현실세계에서는 반드시 저 보름달을 모두 함께 바라보리라는 보장을 할 수 없을 겁니다.

필자와 독자 여러분들과 함께 저 보름달에 가기 위해서 여러 가지 이야기를 나누면서 제가 저 보름달을 손가락으로 가리키고 있습니다. 전자인 경우 몇몇의 대부분은 저 보름달에 가기 위한 목표로 즐거운 대화를 나눌 수 있지만, 어떤 누군가는 전혀 그렇지 않을 수도 있습니다. 아쉽게도 후자의 몇몇의 사람들은 보름달을 가리키고 있는 제 손가락 끝의 손톱 때를 보면서 잡담을 나누기도 합니다.

이런 현상은 개발하는 조직에서 특히 쉽게 찾아볼 수 있는 현상입니다. 우리 팀이 나아갈 방향과 목표, 그리고 개발해야 할 이상적인 구조를 이야기 할 때, 어떤 누군가는 어떻게 구현할지 머리 속으로 코드만 생각하는 사람들도 있습니다. 반대로 올바른 코드를 작성하고 적절한 리팩토링에 대해 이야기를 할 때, 발전적인 개선할 점에 대한 내용이 아닌 그 이상의 무언가가 잘못됐다고 불평을 하는 사람들도 있습니다. 왜 그럴까요? 서로가 주제에 대한 문제점에 대해서 인식을 하고 있지만, 그것을 바라보는 시각은 전혀 다르기 때문입니다.

분명 필자가 보름달을 가리키면서 야망에 사로잡혀 허황된 꿈을 꾸는 것처럼 보일 수 있지만, 만약 위와 같은 목표를 이룰 수 있는 우주선 설계 도면과 같은 계획을 한다면 필자의 손가락 끝의 손톱 때가 아닌 더 발전적인 방향의 이야기가 될 가능성이 충분하다는 것입니다. (물론 처음부터 완벽한 설계 도면을 만들기란 어렵겠지요.)

분명 개발자와 개발자 또는 개발자와 관리자 간에 발생할 수 있는 이러한 커뮤니케이션의 실수 가운데 모델링을 통하여 서로 공감대를 이루기 쉬운 커뮤니케이션을 할 수 있는 수단이 됩니다. 머릿속에 있는 자신만의 생각을 뚝딱 뚝딱 코드로 완성하여 "짜잔~" 하고 보여주더라도, 완벽한 코드가 아닐 수 있으며 얼마든지 리팩토링 대상이 될 수 있습니다. 자신의 생각을 코드로만 표현할 수 있는 개발자는 안타깝지만 현재의 시대가 원하는 개발자가 아니라고 필자는 생각이 듭니다.

최근의 대부분 개발 도구는 통합 개발 환경을 제공하고 있으며, 특히 Visual Studio부터는 UML 다이어그램도 지원을 해 주고 있습니다. 다음 단원부터 이런 UML을 통해 독자 여러분들이 어떻게 활용할 수 있을지도 함께 생각하면서 보시면 더욱 이 백서가 빛을 발휘할 것이라고 생각합니다.

 

5.1. UML Activity Diagrams (동작 다이어그램)

Activity Diagrams은 소프트웨어의 일련의 프로세스나 업무/비즈니스 프로세스에 대한 일련의 워크플로우를 나타냅니다. 이런 프로세스나 워크플로우의 흐름을 제어하거나 분기, 조인 등의 프로세스를 기술할 수 있습니다. 또한 소프트웨어에서 사용되는 프로토콜을 정의하거나 컴포넌트 상호간에 상호작용을 이해하거나 기술하는데 사용할 수 있습니다.

이러한 Activity Diagrams을 사용하면 여러 가지 이점이 있습니다.

  • 시스템 내부 동작과는 별개로 외부 동작에 집중할 수 있습니다.
  • 자연어를 사용하는 것에 의한 모호성을 줄일 수 있습니다.
  • 사용자/개발자/테스트 등 일관적인 용어를 정의할 수 있습니다.
  • 요구 사항의 차이점의 불일치를 줄일 수 있습니다.
  • 요구 사항 변경을 처리하는 시간을 줄일 수 있습니다.

 

5.1.1. Activity Diagrams 만들기

Activity Diagrams은 모델링 프로젝트에서 새로운 항목을 추가하여 생성할 수 있습니다.

  1. 솔루션 탐색기에서 모델링 프로젝트에서 마우스 오른쪽 버튼을 클릭하여 추가-> 새 항목을 클릭합니다.

     

  2. 새 항목 추가 창에서 "UML Activity Diagrams"을 선택하고 추가 버튼을 클릭하여 완료합니다.

     

  3. Activity Diagrams이 완성되었습니다.


5.1.2. 간단한 흐름 제어

Activity Diagrams에서 하나의 요소는 하나의 작업을 의미하게 됩니다. 그리고 요소를 연결선으로 연결함으로써 흐름의 제어를 구성할 수 있습니다.

 

 

도구 상자에 여러 가지 요소가 포함이 되어 있고, 이 요소를 Activity Diagrams의 디자인 화면에 추가하기 위해서 도구 상자에서 요소를 선택하고 디자인 화면으로 드래그&드랍 동작을 수행합니다.

아래의 간단한 제어 흐름 예제는 한 동작에서 다음 동작의 흐름을 나타냅니다. 순차적으로 흐름이 전달되는 방식으로 일반적으로 이전 동작이 완료된 후에 다음 동작을 수행합니다. Activity Diagrams은 동작에 대한 흐름을 기술하지만 동작이 실행되거나 동작 사이의 제어가 전달되는 방식은 기술하지 않습니다.

위의 간단한 제어 흐름에서 초기 노드를 시작하여 동작 최종 노드까지 하나의 비즈니스 프로세스가 완료되는 것을 알 수 있습니다. 그 중 의사 결정 요소를 통해 조건에 대한 흐름이 분기가 되며, 병합 노드는 분기된 흐름을 병합하는 역할을 수행합니다.

 

5.1.3. 동시 흐름

동시 흐름은 동시에 동작하는 요소를 기술할 수 있습니다. 다음은 동시 흐름을 기술하는 다이어그램의 예 입니다.

 

처음의 분기 노드는 분기되는 요소에 대해 각 토큰을 생성하여 마지막 병합 노드에서 들어오는 각 토큰에 대해 동시 흐름을 단일 흐름으로 병합하게 됩니다.

"주문서"에 해당하는 신호 보내기 동작은 메시지의 신호를 보냅니다. "금액 지불" 이베트 적용 동작은 다음 동작을 계속하기 전에 메시지나 신호를 기다리는 동작을 수행합니다.

 

5.1.4. 데이터 흐름

데이터 흐름은 각 동작간에 데이터 흐름을 기술하게 됩니다. 다음은 데이터 흐름의 예 입니다.

 

 

위의 개체 노드는 흐름에 따라 전달되는 데이터를 의미 합니다. 이 개체 노드는 입력 핀과 출력 핀을 통해 데이터를 입력 받거나 작업의 처리에 대해 출력을 나타내며, 동작 매개 변수 노드는 동작에 의해 데이터를 생성하거나 받을 때 사용합니다.

 

5.2. UML Use Case Diagrams (사용 사례 다이어그램)

Activity Diagrams에 정의되는 시스템 내부적인 워크플로우나 업무/비즈니스 등을 정의하는 것이 초점이라면, Use Case Diagrams은 시스템이 구현할 업무/비즈니스 프로세스를 다루는 것이 다릅니다.

Use Case Diagrams은 어플리케이션 또는 사용자가 어플리케이션의 시스템으로 수행할 수 있는 작업에 대해 요약합니다. 특히 Use Case Diagrams은 사용자의 요구 사항을 기술하기 위한 중심 역할을 하게 됩니다. 하지만 이러한 요소 사항은 너무 자세하게 기술하지 않으며 별도의 다이어그램으로 세부적인 내용을 기술할 수 있습니다.

Use Case Diagrams을 사용하면 다음과 같은 이점이 있습니다.

  • 시스템이나 어플리케이션이 사용자/조직 또는 외부 시스템과 상호 작용하는 흐름의 이해가 쉽습니다.
  • 해당 행위자가 달성해야 하는 목표를 쉽게 이해할 수 있습니다.
  • 시스템의 범위를 이해할 수 있습니다.

 

5.2.1. Use Case Diagrams 만들기

 

  1. 메뉴의 아키텍처->새 다이어그램을 클릭합니다.

     

  2. 새 다이어그램 추가 창에서 "UML Use Case Diagrams"을 선택하고 확인 버튼을 클릭합니다.

 

Use Case Diagrams이 제공하는 도구 모음은 다음과 같습니다.

 

5.2.2. 행위자, 사용 사례, 하위 시스템

행위자, 사용 사례, 하위 시스템은 행위자가 하위 시스템에 참여하여 사용 사례를 만드는 예제입니다.

각 행위자인 고객, 레스토랑 중 고객은 레스토랑이 제공하는 음식점 시스템에 참여하게 됩니다. 레스토랑 행위자 또한 음식점 시스템에 참여하여 메뉴를 주문 받고, 고객 행위자에게 적절한 서비스를 제공한다는 사용 사례를 나타냅니다.

 

5.2.3. 사용 사례 구성

사용 사례 구성은 사용 사례 요소 간에 흐름이 연결되거나 상속, 포함, 아티펙트에 대한 예를 보여 줍니다.

 

일반 고객과 VIP 고객은 "일반화" 요소를 이용하여 상속을 구성합니다. 음식 주문은 음식 주문과 연관되는 사용 사례를 포함하도록 구성하였고, 메뉴 필터는 메뉴 선택 사례를 확장하고 메뉴 필터는 각 요리 필수사항과 요리법을 상속하게 됩니다.

그리고 사용 사례의 아티팩트는 다른 다이어그램이나 외부 링크를 제공합니다. 또는 솔루션 폴더에서 솔루션 항목을 드래그&드랍하게 되면 그 문서에 대한 아티팩트가 자동으로 생성합니다.

이러한 형태로 시스템을 작동하는 방법과 이 시스템과 교류하는 흐름을 나타내며, 구현 레벨의 좀 더 상위 고수준의 관계를 이해하는데 도움이 됩니다.

 

5.2.4. 시스템의 버전 정보 기술하기

시스템의 버전 정보를 기술하기 위해 단계적으로 기능 또는 사용자 측면의 사례를 기술할 수 있습니다.

아래와 같이 Release 1에서는 메뉴 주문 기능을 구현한다는 것으로 이해할 수 있습니다. 음식 주문을 위해 메뉴를 선택하고 주문을 완료하는 단순한 기능의 범위만 제공한다는 것을 알 수 있으며, 이는 설계자 외에 사용자도 명확하게 Release 1의 시스템을 이해할 수 있을 것입니다.

 

아래와 같이 Release 2에서는 기존의 메뉴 주문 기능을 포함하도록 기능을 확장한다는 내용이 포함이 됩니다. 점주에 의해 레스토랑의 메뉴와 레스토랑 관리 기능을 포함시켜 레스토랑의 시스템을 이용하여 메뉴를 선택하고 금액을 지불하거나 메뉴를 관리하는 범위임을 이해할 수 있습니다.

 

아래와 같이 Release 3에서는 기본적인 기능을 확장하고 모바일 디바이스를 통해 메뉴를 제공하는 시스템의 기능을 범위로 한다는 것을 알 수 있습니다.

이렇게 Use Case Diagrams을 이용하여 시스템의 버전 정보를 기술하기 위한 용도로 사용이 가능하며 이렇게 함으로써 점진적인 시스템 구축의 전체 윤곽을 이해 관계자 간에 이해하는데 많은 도움을 줄 수 있습니다.

 

5.2.5. 아티펙트의 문서를 열기 및 연결

아티펙트는 다양한 방법으로 연계되는 다이어그램 및 문서, 그리고 웹 문서 등을 포함시킬 수 있습니다. 다음은 여러 가지 방법으로 아티펙트를 연결하거나 추가하는 방법입니다.

  1. 아티팩트의 연결된 문서를 열려면?
    아티펙트의 요소에서 마우스를 두 번 클릭합니다.

  2. 솔루션에 포함된 문서를 아티펙트로 추가하려면?
    솔루션에 포함된 항목을 Use Case Diagrams으로 드래그&드랍합니다.

  3. Word 및 PowerPoint 문서를 추가하려면?
    아티펙트를 선택하여 속성 창에서 하이퍼링크 항목을 클릭하여 추가하고자 하는 문서를 찾아 선택합니다.


  4. HTTP/HTTPS 또는 공유 문서를 열려면?
  1. 아티펙트를 선택하여 속성 창에서 하이퍼링크를 선택합니다. "URL 또는 파일에 링크" 창에서 링크하고자 하는 HTTP/HTTPS 링크를 입력합니다. 만약 OneNote 의 공유 문서에 링크를 원하면 onenote:// 의 링크를 입력하면 됩니다.

 

5.3. UML Component Diagrams (구성 요소 다이어그램)

Component Diagrams은 소프트웨어 시스템의 각 구성 요소를 디자인할 수 있습니다. 시스템 구조에 따른 컴포넌트와 인터페이스를 확인하고 이들 컴포넌트간에 서비스의 동작을 이해하는데 중요한 역할을 합니다.

Component Diagrams을 이용하면 다음과 같은 이점이 있습니다.

  • 기존 디자인을 이해하거나 새로운 디자인을 하는데 용이합니다.
  • 시스템이 제공하는 인터페이스와 필요한 인터페이스가 잘 정의되면 구성 요소를 분리하여 개선하거나 변경에 쉽게 대처할 수 있습니다.

 

5.3.1. Component Diagrams 만들기

  1. 모델링 프로젝트에서 마우스 오른쪽 버튼을 클릭한 후, 추가->새 항목을 클릭합니다.

    2. 새 항목 추가 대화 상자에서 UML Component Diagrams을 선택하고 추가를 클릭합니다.
  1.  

Component Diagrams이 제공하는 도구 상자의 요소는 다음과 같습니다.

 

5.3.2. 음식점 Component Diagrams 만들기

간단하게 어떤 구성 요소가 필요한지 간단하게 다음과 같이 구성 요소를 배치 합니다. 주방 서버는 파트로 구성되어있습니다.

파트 구성 요소를 만들려면?

도구 상자에서 구성 요소를 클릭하고 디자인에 포함된 구성 요소 하나를 클릭합니다. 그러면 구성 요소 안에 파트가 아래와 같이 파트가 추가됩니다.

 

각 구성 요소간에 인터페이스 포트가 필요한데, 이 인터페이스 포트는 다른 구성 요소간의 흐름과 데이터를 표현하는데 사용합니다.

웹 브라우저 구성 요소는 필요한 인터페이스로 HTTP 인터페이스를 생성하였습니다. 음식점 웹사이트와 고객 웹 서비스의 제공된 인터페이스를 통해 웹 브라우저가 음식점 웹서비스에 접근할 수 있도록 구성합니다.

 

고객 웹 서비스는 필요한 인터페이스가 필요하며, 이 컴포넌트를 외부 시스템과 연결하기 위해 음식점 웹서비스도 지불 인증에 대한 필요한 인터페이스가 존재합니다. 고객 웹 서비스는 이 필요한 인터페이스를 통해 외부에서 결제 시스템을 제공하는 인터페이스로 연결하기 위해 이 필요한 인터페이스간에 위임을 통해 연결합니다.

 

고객 웹 서비스는 주방 서버가 제공하는 인터페이스가 필요합니다. 고객 웹 서비스에 필요한 인터페이스를 추가하고, 주방 서버는 제공된 인터페이스를 추가하여 이 둘 간에 파트 어셈블리를 이용하여 연결합니다. 연결된 파트 어셈블리는 구성 요소에 따라 다르게 구현될 수 있음을 의미하지만, 이 연결된 파트는 동일한 부모 구성 요소를 필요로 합니다.

주방 서버는 필요한 인터페이스로 주방작업 큐를 추가하여 주방 웹 사이트의 제공된 인터페이스를 위임을 통해 연결하여 주방 서버의 작업을 완료합니다.

 

5.4. UML Class Diagrams (클래스 다이어그램)

Class Diagrams은 컴포넌트 또는 어플리케이션의 내부적으로 사용하는 개체 정보에 대한 구조를 기술합니다. 데이터베이스 테이블이나 XML, 또는 개체의 관계를 표현할 수 있습니다. Class Diagrams은 데이터의 형식이나 관계를 구현 및 분리할 수 있습니다. Class Diagrams은 주로 논리적인 측면에 중점을 두어 정의합니다.

Class Diagrams을 이용하면 다음과 같은 이점이 있습니다.

  • 시스템 간에 전달되는 요소에 대한 구현과 독립적인 설명을 제공
  • 어플리케이션과 사용자 간의 통신에 사용되는 용어를 명확하게 정의

 

5.4.1. Class Diagrams 만들기


      1. 모델링 프로젝트에서 마우스 오른쪽 버튼을 클릭한 후, 추가->새 항목을 선택합니다.

      2. 새 항목 추가 대화 상자에서 "UML Class Diagrams"을 선택한 후 추가를 클릭합니다.

 

다음은 Class Diagrams의 도구 상자에서 지원하는 요소입니다.

 

5.4.2. 메뉴 및 주문 Class Diagrams

메뉴와 주문에 필요한 클래스를 도구 상자에서 끌어와 각 클래스를 만듭니다.

 

그리고 Menu와 MenuItem은 집합체로 구성하기 위해 Menu를 선택하고 에서 추가->집합체를 선택합니다.

 

집합체의 MenuItem을 Menu의 1:* 관계를 만들기 위해 MenuItem을 선택한 후 속성 창에서 "복합성"을 * 로 선택합니다. 그리고 탐색 가능을 False 로 설정하여 단방향 탐색이 가능하도록 합니다.

 

 

Menu와 Order 클래스간의 연결 관계를 만듭니다.

 

Order클래스는 연결 요소의 속성 창에서 복합성을 * 로 선택하고 탐색 가능을 False 로 설정합니다.

 

Menu클래스도 연결 요소의 속성 창에서 탐색 가능을 False 로 설정합니다.

 

다음은 위와 같은 방법으로 관계를 완성한 Class Diagrams 입니다.

 

이제 각 클래스에 속성과 메서드 등의 작업을 추가합니다. 메서드(작업)에 아래와 같이 임의로 정의한 매개 변수를 추가를 할 수 있습니다.

 

Order클래스의 DeleteItem을 선택한 후 속성 창에서 매개 변수를 클릭하여 대화 상자를 엽니다.

 

작업 매개 변수 컬렉션 편집기 대화 상자에서 매개 변수의 이름을 입력한 후 형식에서 MenuItem 형식을 선택하여 확인을 클릭합니다.

 

그럼 다음과 같이 MenuItem 형식의 매개 변수를 갖는 메서드를 추가할 수 있습니다.

 

다음은 완성된 메뉴 및 주문 Class Diagrams입니다.

 

5.5. UML Sequence Diagrams (시퀸스 다이어그램)

Sequence Diagrams은 클래스나 구성 요소, 인스턴스, 시스템 간의 메시지 동작의 순서를 나타내는 다이어그램입니다. 일반적으로 Sequence Diagrams은 위에서 아래로 시간적인 흐름을 갖고 있습니다. Sequence Diagrams의 수평선의 상호 작용 참가자 간의 이벤트를 나타냅니다.

Sequence Diagrams을 사용하면 다음과 같은 이점이 있습니다.

  • 구성 요소간의 작업이 진행되는 흐름을 쉽게 확인할 수 있습니다.
  • 어플리케이션에서 상호 작용을 어렵게 하는 패턴을 식별할 수 있습니다.

 

5.5.1. Sequence Diagrams 만들기

      1. 모델링 프로젝트의 항목에서 마우스 오른쪽 버튼을 클릭하여 추가->새 항목을 선택합니다.

      2. 새 항목 추가 대화 상자에서 "UML Sequence Diagrams"을 선택하고 추가를 클릭합니다.

 

다음은 Sequence Diagrams이 제공하는 대화 상자의 요소입니다.

 

5.5.2. 음식 제공 서비스 Sequence Diagrams

우선 각 메시지 이벤트를 송수신하는 주체인 참가자를 추가해야 합니다. 도구 상자의 수평선을 이용하여 세 개의 참가자를 추가합니다.

비동기 요소를 이용하여 알 수 없는 특정 메시지를 고객 타임라인에 추가 합니다.

손님이 주문을 하기 위해 주문 타임라인에 주문에 대한 메시지를 보내야 합니다.

비동기 메시지를 통해 주문 타임라인에 주문한 내용을 추가하는 메시지를 보냅니다.

주문을 받으면 메뉴 관리자에게 주문 내역이 요리 가능한지 확인을 하는 동기 메시지를 보내고, 메뉴 관리자는 메시지의 응답을 기다리는 호출자에게 어떤 메시지를 콜백합니다. 그럼 주문 타임라인은 그 주문에 대해 최종적으로 정리 작업을 진행하고 주문을 하기 위한 모든 작업을 완료 합니다.

여러 개의 주문에 대해 처리를 할 경우 주문 추가 비동기 메시지부터 루프 코드를 감싸도록 합니다.

 

그리고 루프 코드의 가드를 이용하여 루프가 벗어나게 되는 조건을 기술해 줍니다.

 

주문에 대한 루프 작업이 완료되었다면, 루프가 완료되는 시점의 상호 작용 요소를 추가합니다.

 

상호 작용 요소는 다른 다이어그램과 연결할 수 있는 요소입니다. 현재 Sequence Diagrams과 연결된 새로운 시퀸스를 만들려면 "새 시퀸스 만들기"를 선택합니다. 새로운 시퀸스 만들기를 선택하면 새로운 Sequence Diagrams 파일이 생성이 됩니다.

또는 시퀸스에 연결을 선택하면 이미 존재하는 Sequence Diagrams과 연결을 할 수 있습니다.

 

마지막으로 비동기 메시지를 이용하여 재고 및 매출 업데이트 메시지를 보내고, 시퀸스는 종료됩니다.

 

 

5.6. Layer Diagrams (레이어 다이어그램)

Layer Diagrams은 시스템의 논리적인 아키텍처를 시각화할 수 있습니다. Layer Diagrams은 물리적인 아티펙트를 논리적인 추상 그룹으로 구성합니다.

Layer Diagrams은 논리적인 아키텍처를 시각화하는 것 이외에, 실제 Visual Studio에서는 동작하는 코드와 논리적 아키텍처간의 충돌을 검사하기도 합니다. 시스템을 리팩토링하거나 업데이트 시에 변경에 미치는 영향을 분석하며 체크인 또는 빌드 작업에 충돌에 대한 유효성을 검사하도록 하여 기존의 계획을 강화할 수 있는 방법으로 사용할 수 있습니다.

 

5.6.1. Layer Diagrams 만들기

      1. 솔루션 탐색기의 모델링 프로젝트에서 마우스 오른쪽 버튼을 클릭하여 추가->새 항목을 선택합니다.

      2. 새 항목 추가 대화상자에서 Layer Diagrams을 선택하고 추가를 클릭합니다. 


Layer Diagrams은 도구 상자에 다음과 같은 요소를 제공합니다.

 

5.6.2. Layer Diagrams

Layer Diagrams으로 논리적인 3-tier 어플리케이션을 다음과 같이 구성할 수 있습니다.

 

각 레이어에 종속되는 레이어를 추가 하기 위해서 레이어를 선택하여 마우스 오른쪽 버튼을 클릭한 후 추가->레이어를 선택하여 종속된 레이어를 추가할 수 있습니다.

 

다음은 완성된 Layer Diagrams의 예입니다.

 

5.6.3. 코드와 Layer Diagrams 연동

실제 물리적인 코드와 Layer Diagrams 간의 연관 관계를 만들어 아키텍처를 분석하고 유효성을 검사할 수 있습니다.

  1. 솔루션 안에 간단한 논리적인 3 tier 를 구현한 프로젝트를 각 레이어에 맞게 드래그&드랍 합니다.

     

  2. 각 레이어에 추가된 프로젝트의 개수가 표시되는지 확인합니다.

     

  3. 레이어 탐색기에 추가된 프로젝트가 존재하는 것을 확인할 수 있습니다.

     

  4. 레이어 디자이너에서 마우스 오른쪽 버튼을 클릭하여 "아키텍처 유효성 검사"를 클릭합니다.


    5. 출력 창에 아키텍처 유효성 검사 결과가 표시됩니다.

     

5.6.4. 네임스페이스로 실제 코드의 유효성 검사

  1. 레이어를 선택하여 속성 창을 확인합니다.

     

  2. 사용할 수 없는 네임스페이스 또는 사용할 수 없는 네임스페이스 종속성에 적절한 네임스페이스를 입력합니다.

  3. Layer Diagrams에서 마우스 오른쪽 버튼을 클릭하여 아키텍처 유효성 검사를 클릭합니다.

     

  4. 출력 창에 아키텍처 유효성 검사 결과가 표시됩니다.

 

5.6.5. 명령 프롬프트로 유효성을 검사

Visual Studio에서 명령 프롬프트를 이용하여 빌드를 수행할 때 Layer Diagrams의 아키텍처 유효성을 검사할 수 있습니다.

이 방법을 이용하면 개발 도구가 없는 경우, 그리고 Team Foundation의 Team Build 시 아키텍처 유효성을 검사할 때 유용하게 사용할 수 있습니다.

 

5.6.5.1. MSBUILD 명령 프롬프트로 아키텍처 유효성을 검사하려면?

Visual Studio명령 프롬프트를 실행한 수 다음과 같이 MSBUILD 명령 옵션으로 모델링 프로젝트의 아키텍처 유효성을 검사합니다.

C:\> msbuild <FilePath+ModelProjectFileName>.modelproj /p:ValidateArchitecture=true

 

또는 전체 솔루션 중 모델링 프로젝트의 아키텍처 유효성을 검사하려면 다음과 같이 솔루션 파일을 입력한 후 옵션을 지정합니다.

C:\> msbuild <FilePath+SolutionName>.sln /p:ValidateArchitecture=true

 

 

5.6.5.2. Team Foundation 의 Team Build로 아키텍처 유효성을 검사하려면?

Team Foundation 의 Team Build에서 아키텍처 유효성을 검사하려면 다음과 같은 방법으로 MSBUILD 옵션을 지정해 줄 수 있습니다.

  1. 팀 프로젝트를 연결하고 아키텍처 유효성을 검사할 빌드 항목을 선택한 후 빌드 정의 편집을 선택합니다.

     

  2. 프로세스 탭으로 이동한 후 3. 고급 탭으로 이동한 후 MSBUILD 인수 항목에 /p:ValidateArchitecture=true 인수를 입력한 후 저장합니다.


Posted by 땡초 POWERUMC

댓글을 달아 주세요

본 아티클은 MSDN 에 eBook으로 공개된 문서를 블로그 아티클로 편집하였습니다. VSTS 팀블로그에 의해 작성된 문서의 원문 및 여러 가지 기술 문서는 아래의 링크에서 PDF로 다운로드 받을 수 있습니다. 그리고 본문의 특정 버전을 지칭하는 개발툴 버전 번호는 모두 Visual Studio로 변경되었음을 참고하십시오. (예- Visual Studio 20xx는 Visual Studio로 표기함 )

VSTS 팀블로그 MSDN 기술 문서 : http://msdn.microsoft.com/ko-kr/gg620748 

필자 소개

Microsoft Visual Studio ALM MVP 엄준일
http://blog.powerumc.kr

 

Visual Studio Korea Team Blog
http://vsts2010.net

감수 : 강성재 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

   

도움주신 분 : 김남영 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

   

[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 1/7 - 들어가기에 앞서...
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 2/7 - 왜 모델링인가?
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 3/7 - 모델링의 표기
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 4/7 - 모델링 다이어그램
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 5/7 - Visualization & Features Pack
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 6/7 - 모델링 확장 (SDK)
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 7/7 - 결론 및 저자 소개

 

4. 모델링을 하기 앞서

다음 회차에서 Visual Studio 모델링을 배우기 앞서, 많은 개발자들은 모델링을 어떻게 시작하면 좋은지에 대해 고민을 하시는 분들도 많습니다. 모델링의 목적이 복잡하고 추상적인 것으로부터 명확하게 요소를 구분하여 표현하는 것이긴 하지만, 무엇을 명확하게 표현해야 할 지도 고민해야 할 부분 입니다.

예를 들어, 구현을 하기 위해 모델링을 하는 것인지… 아니면 그 상위 시스템과 비즈니스 워크플로우를 명확하게 하고자 하는 것인지… 모델링이라는 도구를 잡는 사람들마다 그 목적이 다르고 사용하는 방법도 다를 것이라고 생각합니다.

한 가지 UML에 대해 잠깐 동안 되집어 생각해 볼 것이 있습니다. 왜 UML 이 성공했는가? 라는 물음입니다. UML이 추구하고자 했던 것은 UML 을 이용하여 소프트웨어를 설계하거나 객체지향적인 설계에 등의 어떠한 노하우도 포함시키지 않았습니다. 다시 말해, UML은 [모델의 표기 방법]만을 규정하였습니다.

어떠한 소프트웨어를 만들던지 그 소프트웨어에 포함되는 구성요소나 설계가 완전히 틀릴 수 있지만, UML을 이용하여 표기법이 통일 된다면 이해 관계자간에 의사소통은 쉬워질 것입니다.

다음 회차에서 다룰 모델링의 표현 방법 등은 잠시 뒤로 미루고 무엇을 모델링할 것인지에 대해 먼저 함께 고민해야 할 것 같습니다.

 

4.1. 모델링의 관점 및 측면

모델러(모델링의 하는 주체)는 어떤 관점과 어느 측면을 바라보고 다양한 방법으로 모델링을 할 수 있습니다. 이런 모델러의 관점과 측면을 이해할 수 있다면 정확하게 정보를 전달할 수 없을지도 모릅니다.

 

모델러가 생각하는 관점과 측면으로 올바르게 모델링의 정보가 전달되지 않는다면, 위와 같은 그림을 해석은 매우 달라질 수 있을 것입니다. 마치 착시현상을 일으키는 것처럼, 오히려 잘못된 정보로 논쟁의 대상이 될 수 도 있기 때문입니다. 그렇기 때문에 모델러는 자신의 의도를 명확하게 모델링 하는 것이 좋습니다.

 

모델링은 다양한 측면으로 나뉠 수 있지만, 아래와 같이 4개로 정의하기도 합니다.

  • 정적인 측면
    단지 오브젝트들의 구조적인 관계를 나타냅니다. 정적인 측면은 이름에서도 알 수 있듯이 시간적인 흐름은 전혀 포함되지 않습니다.

  • 기능적인 측면
    시스템이 할 수 있는 행동적인 것을 표현하고자 합니다.

  • 동적인 측면
    오브젝트가 시간의 흐름이나 이벤트에 의해 어떻게 상태가 변화해 가는지에 대해 나타냅니다.

  • 물리적인 측면
    시스템이 동작하기 위해 필요한 물리적인 것들을 나타냅니다. 서버나 데이터베이스 간의 관계를 어떻게 기술 할지에 대해 나타내기도 합니다.

 

그리고 모델링을 하려는 관점이 있을 수 있습니다. 이는 보통 "관점(Perspective)" 또는 "레벨(Level)" 이라고 부르기도 합니다. 이러한 관점은 추상화 정도에 따라서 3가지로 구분을 합니다.

  • 개념적 관점
    개념적인 관점은 구현 등의 영역을 전혀 고민하지 않은 채, 실질적인 큰 범위의 영역을 해석하는 관점입니다. 범위에 포함되는 여러 가지 문제를 깊이 있게 이해하는 것이 목적입니다.

  • 사양적 관점
    사양적 관점은 문제를 해결하여 완성시키기 위해 필요한 기능 등을 효과적으로 이행할 수 있는 방안을 찾기 위한 관점입니다.

  • 구현적 관점
    구현적 관점은 사양적 관점에서 고안된 방안을 실질적으로 구현하기 위한 관점에서 작성합니다.

 

이러한 관점은 완벽히 독립적인 것은 아닙니다. 필요에 따라 사양적 관점/구현적 관점이 동시에 진행될 수 있습니다.

위와 같은 모델링의 관점과 측면은 개개인에 따라서, 또는 모델링에 참여하는 사람에 따라서 전혀 목적이 일치하지 않을 수 있는 문제가 있습니다. 그렇기 때문에 모델링 이전에 정확하게 목적을 설정하고 개념적 관점의 모델을 작성하는 것이 올바른 시작이라고 할 수 있습니다.

 

4.2. 모델의 표기 방법

기본적으로 모델링을 하기 위해 모델을 표현하는 공통적인 표기법을 알아보겠습니다. 매우 기본적이고 공통적인 표기 방법이므로 모델링에 들어가기 앞서 가장 중요한 부분이기도 합니다. 기본적인 모델링의 표기 방법을 알아야 모델을 통해 전달하고자 하는 메시지를 최소한 이해할 수 있을 것입니다.

4.2.1. 공통적인 표기 방법

공통적인 표기 방법의 기본적인 도형은 4가지 입니다. 즉, 이 4가지만 알면 UML 다이어그램을 읽는 것이 한결 쉽겠지요.

  1. 주석(Comment)

    제약 조건이나 주석이나 정보를 표시하는데 사용하는 기호입니다. 이 기호는 한쪽 귀퉁이가 접혀진 직사각형을 사용합니다. 특정한 모델의 요소와 연관이 되는 주석인 경우 점선으로 연결 됩니다.

     

  2. 패키지

    모델 요소들을 하나로 묶어주는 것으로 폴더 아이콘과 유사하게 표시됩니다. 비슷한 요소의 집합이나 연관성이 있는 요소들을 묶어주는 역할로 주로 사용하기도 하지만, Use Case Diagram 등에서 하위 패키지나 하위 시스템 등을 표현할 때 사용하기도 합니다.

     


    3. 의존 관계

  3. 모델 요소간의 의존 관계를 표기하는 방법으로 사용이 됩니다. 모델 요소가 다른 모델의 내부를 알고 있다거나 의존의 방향을 나타내는데 사용합니다.

    아래와 같은 속이 비었는지 색이 채워졌는지에 따라서 Aggregation(집합체) 인지 Composition(합성) 관계인지 알 수 있습니다. 예를 들어, Composition(합성) 관계는 Class1의 정보가 소멸될 때 Class2의 정보도 함께 소멸되는 것을 미리 짐작할 수 있습니다.

     

4.2.2. 표기 방법의 확장

UML에서는 표기 방법을 확장할 수 있는 많은 장치들이 존재합니다. 이런 표기 방법의 확장은 모델링을 좀 더 정확하게 세세하게 정의할 수 있으며, 확장 표기 방법을 통해 유효성을 검증할 수 있는 수단이 될 수 있습니다.

그 중 가장 많이 사용되는 한 가지를 소개할 예정이며, 이것을 아느냐 모르느냐는 모델링의 퀄리티에 큰 차이가 있을 수 있습니다. 그 밖에 Constrains(제약) 도 모델 요소 간의 성립 관계를 나타낼 수 있습니다.

  1. Stereotype(스테레오 타입)

    모델 기호의 의미를 새롭게 재정의 하는 방법으로 Stereotype을 사용할 수 있습니다. 기존적인 Stereotype 은 <<type>>, <<interface>>, <<implementation>> 등이 있으며, 이런 Stereotype을 요구사항에 따라 새롭게 정의할 수 있습니다.

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

본 아티클은 MSDN 에 eBook으로 공개된 문서를 블로그 아티클로 편집하였습니다. VSTS 팀블로그에 의해 작성된 문서의 원문 및 여러 가지 기술 문서는 아래의 링크에서 PDF로 다운로드 받을 수 있습니다. 그리고 본문의 특정 버전을 지칭하는 개발툴 버전 번호는 모두 Visual Studio로 변경되었음을 참고하십시오. (예- Visual Studio 20xx는 Visual Studio로 표기함 )

VSTS 팀블로그 MSDN 기술 문서 : http://msdn.microsoft.com/ko-kr/gg620748 

 

필자 소개

Microsoft Visual Studio ALM MVP 엄준일
http://blog.powerumc.kr

 

Visual Studio Korea Team Blog
http://vsts2010.net

감수 : 강성재 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

   

도움주신 분 : 김남영 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

 

[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 1/7 - 들어가기에 앞서...
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 2/7 - 왜 모델링인가?
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 3/7 - 모델링의 표기
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 4/7 - 모델링 다이어그램
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 5/7 - Visualization & Features Pack
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 6/7 - 모델링 확장 (SDK)
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 7/7 - 결론 및 저자 소개


3. 모델링 시작하기

 

3.1. 모델링인가?

일반적으로 UML이라고 하면 Unified Modeling Language(통합 모델링 언어)라고 부르는 소프트웨어 공학의 표준화된 언어를 일컫는 용어입니다. 과거 1980년과 1990대 사이에 많은 객체 지향 모델링 기법이 생겨났었지만, 여러 사람들에 의해 다양한 모델링 기법과 표기법을 사용하였으며 어플리케이션을 위한 모델링, 또는 데이터베이스만을 위한 모델링 등 특정한 목표에 의해 사용되어 왔습니다.

1990년대 중반 Rational Software에서 여러 가지 노력 끝에 모델링 방법(Unified Method) 버전 0.8을 내놓았고 그 이후 컨소시엄 형태로 여러 기업이 합류하게 되었습니다. 이들은 1997년에 UML(Unified Modeling Language)로 이름을 바꾼 버전 1.0을 OMG 에 제출하면서 지속적으로 UML을 이끌어 왔습니다.

 

 

참고 : http://en.wikipedia.org/wiki/Unified_Modeling_Language

 

이전에는 여러 가지 독립적인 표기법을 사용했던 것과 달리, UML은 많은 업체 전문가들, 소프트웨어 개발 회사 등이 함께 만들어 오면서 소프트웨어 개발을 위한 전세계적인 표준 언어 모델링 역사가 시작된 것입니다.

모델링은 어떤 다이어그램을 선택하느냐에 따라서 그 내용과 추상화 정도가 달라지게 되지만, 일반적으로 어떤 특정한 개체를 나타내고자 할 때, 그리고 어떤 디자인(목표)를 정의할 때, 목표에 대한 예시(예제)등을 표현할 때 매우 적절하기도 합니다.

 

일상생활에서도 이러한 모델링 속에 우리가 살고 있다고 해도 과언이 아닙니다. 지하철 운행 정보와 지하철 노선도, 자동차 운전시에 네비게이션, 체계적으로 교통을 통제하는 신호등 같은 것들이 대표적이기도 합니다. 이런 생활 속의 모델링은 직접적으로 나에게 어떤 작용을 하는 것은 아니지만, 이러한 모델들은 나에게 의사 소통을 도와주고, 복잡한 것들은 단순화 시켜줍니다.

 

 

3.2. 모델링을 해야 하는가?

아래와 같이 초등학교 교과서에 나올법한 전기 도면이 있습니다. 스위치를 누르면 불이 들어오는 도면입니다.

사실 위와 같은 간단한 전기 도면은 도면 자체로써 크게 가치가 없을지도 모릅니다. 하지만 더 복잡한 전기 도면은 실제로 도면을 통해 시뮬레이션을 하여 큰 오류를 미리 알아낼 수 있기도 합니다. 아래와 같은 표기법 등은 공통된 이해 관계자간에 어떻게 회로가 설계 되었는지, 어떻게 작동하는지 쉽게 이해할 수 있는 것입니다.


다음과 같은 악보도 마찬가지 입니다. 이 악보는 음악을 어떻게 표현하는지에 대한 표기법으로 구성되어 있습니다. 음악의 느낌과 연주 방법을 말로 하는 것보다 아래의 악보를 통해 연주자는 어떻게 연주를 해야 하는지 일관성 있게 알려줄 수 있는 표기법입니다.


 

우리가 모델링을 해야 하는 것도 이런 이유들과 크게 다르지 않습니다. 단순한 기능, 요구 사항의 구현에서는 이와 같은 모델링이 필요하지 않을 수 있겠지만, 이런 기능 명세나 요구 사항, 그리고 시스템, 아키텍처적인 측면에서는 완성되기 이전에 올바르게 그 목표를 정의하고 이해하는지 소통할 수 있는 방법은 모델링이라는 것입니다.

이러한 모델링은 여러 이해 관계자나 업무의 형태에 따라 매우 효과적으로 이용될 수 있습니다.

업무적인 측면에서 모델링은 업무의 프로세스를 표현하거나 이해하는데 매우 도움이 됩니다. 업무의 흐름에서 각 작업의 흐름을 파악할 수 있으며, 전체적으로 나와 관련되는 조직 체계를 이해하는데 효과적입니다.

아키텍처 측면에서 모델링은 구축하고자 하는 시스템의 추상화된 이해와 다른 연계 시스템과의 데이터나 연계적인 흐름을 정의하여 시스템 관리자 및 설계자, 개발자 간에 의사 소통에 용이합니다.

어플리케이션 측면에서 모델링은 시스템 자체에서 동작되는 방식을 정의하여 추상화된 아키텍처를 저수준에서 이해하는데 효과적입니다.

데이터베이스 측면에서 모델링은 데이터베이스에서 데이터의 구조를 정의하고 어플리케이션과 어떻게 교류하는지에 대해 이해하는데 효과적입니다.

 

 

3.3. 모델링을 위해 어떤 다이어그램이 있는가?

UML은 구조 다이어그램(structure diagram)과 행동 다이어그램(behavior diagram) 이라는 두 가지의 기본적인 다이어그램을 포함합니다. 구조 다이어그램은 시스템의 정적인 구조를 나타냅니다. 다양한 구조 다이어그램들은 다음과 같습니다.

  • Class diagram(클래스 다이어그램)은 UML 모델링에서 사용되는 가장 일반적인 다이어그램으로 시스템, 그 구조 그리고 그들의 상호 관계 내에 존재하는 정적인 것을 나타냅니다. 시스템의 논리적 및 물리적 설계를 나타내는 데 주로 사용됩니다.
  • Component Diagram(컴포넌트 다이어그램)은 컴포넌트집합 내의구성과 의존관계를 보여줍니다. 구현되는 시스템과 시스템 내에서 부품들이 어떻게 상호 작용하는지를 보여줍니다.
  • Object Diagram(개체 다이어그램)은 시스템 내의일련의 개체들 사이의 관계를 보여 주는데, 특정시점에 시스템의 스냅샷을 보여줍니다
  • Deployment Diagram(배치 다이어그램)은 물리적 시스템의 실행 시점의 아키텍처를 보여줍니다. 배치 다이어그램은 하드웨어와 이 하드웨어 내에 있는 소프트웨어의 설명을 포함할 수 있습니다.

 

UML 2.0은다음과 같은 구조 다이어그램을 추가되었습니다.

  • Composite Structure Diagram(복합체 구조 다이어그램)은 모델링 요소들의 내부적 구조를 보여줍니다.
  • Package Diagram(패키지 다이어그램)은 패키지 사이의 의존 관계를 나타냅니다. (패키지는 다른 모델 요소들을 그룹화하는데 사용되는 모델 요소입니다).

Behavior Diagram (행동 다이어그램)은 시스템 내 요소들의 동적인 행동을 나타냅니다. 다양한 행동 다이어그램들은 다음과 같습니다.

  • Activity Diagram(활동 다이어그램)은 시스템 내의 활동들의 흐름을 보여준다. 여러 업무 프로세스들을 설명하는데 자주 사용됩니다.
  • Use Case Diagram(사용 사례 다이어그램)은 시스템이 구현할 업무 프로세스를 다룹니다. Use Case Diagram은 시스템이 작동하는 방법과 시스템과 교류하는 사람들을 나타냅니다.
  • Statechart Diagram(상태 다이어그램)은 개체의 상태와, 이 개체가 상태들 사이를 어떻게 전이하는지 보여줍니다. 상태 다이어그램은 상태, 전이, 이벤트, 그리고 활동을 포함할 수 있습니다. 상태 다이어그램은 동적 뷰를 제공하며, 이벤트 중심의 행동을 모델링할 때 매우 중요하죠. 예를 들어, 전화 교환 시스템 내의 스위치를 나타내기 위해 상태 다이어그램을 사용할 수 있습니다. 이 스위치는 여러 이벤트들에 기초하여 상태를 바꾸며, 어떻게 이 스위치가 작동하는지를 이해하기 위해 상태 다이어그램에서 이 이벤트들을 모델링할 수 있습니다. UML 2.0에서는 State Machine Diagram(상태 기계 다이어그램)이라고 합니다.
  • Collaboration Diagram(협력 다이어그램)은 Sequence Diagram(순차 다이어그램) 처럼 Interaction Diagram(교류 다이어그램)의 일종입니다. 협력 다이어그램은 개체들이 어떻게 협력하고 교류하는지를 강조합니다. UML 2.0 에서 협력 다이어그램과 대등한 것은 Communication Diagram(통신 다이어그램)입니다.
  • Sequence Diagram(순차 다이어그램)은 또 다른 종류의 교류 다이어그램입니다. Sequence Diagram은 시스템의 다른 요소들 사이의 메시지들의 시간 순서를 강조합니다.

UML 2.0은 다음과 같은 행동 다이어그램을 추가합니다.

  • Timing Diagram(타이밍 다이어그램)은 또 다른 종류의 교류 다이어그램이다. 세부 타이밍 정보와, 교류하는 요소들의 상태 또는 조건 정보에 대한 변경 사항을 나타냅니다.
  • Interaction Overview Diagram(교류 개요 다이어그램)은 Interaction Sequences(교류 순차)들 사이의 제어 흐름에 대한 개요를 보여주는 데 사용되는 고수준의 다이어그램입니다.

 

3.4. Visual Studio 모델링 지원

Visual Studio부터 지원하는 모델링은 다음과 같은 제품에서 지원합니다. 더 자세한 내용은 Visual Studio 제품 페이지를 참고하십시오. (http://www.microsoft.com/visualstudio/ko-kr/products)

Visual Studio버전의 모델링은 현재 UML 2.0 기준의 13가지의 모든 다이어그램을 제공하지 않습니다. Visual Studio에서 제공하는 다이어그램은 다음과 같습니다.

  • UML Activity Diagrams
  • UML Use Case Diagrams
  • UML Sequence Diagrams
  • UML Class Diagrams
  • Layer Diagrams

 

제품 기능

Professional
(MSDN Essentials
포함)

Professional
(MSDN
포함)

Premium
(MSDN
포함)

Ultimate
(MSDN
포함)

Test Professional
(MSDN
포함)

아키텍처 모델링

아키텍처 탐색기

   

 

UML® 2.0 규격 다이어그램(활동, 사용 사례, 시퀀스, 클래스, 구성 요소)

   

 

Layer Diagrams 종속성 유효성 검사

   

 

읽기 전용 다이어그램(UML, 레이어, DGML 그래프)

  

  

 

 

3.5. 모델링 프로젝트 생성

Visual Studio에서는 모델링을 위한 프로젝트 형식을 지원해 줍니다. 모델링 프로젝트 형식은 여러 가지 다이어그램을 만들 수 있는 아이템 템플릿을 제공을 해줍니다. 우리가 다이어그램을 만들기 전에 먼저 모델링 프로젝트를 어떻게 만드는지 아래의 단계를 따라 하면서 살펴봅시다.

 

모델링 프로젝트를 생성하기 위해 Visual Studio을 실행합니다.

  1. 파일->새로 만들기-> 프로젝트를 선택합니다.

     

  2. 프로젝트 템플릿에서 "모델링 프로젝트"를 선택하고, 프로젝트의 이름과 솔루션 이름을 입력하고 확인 버튼을 클릭합니다.

     

  3. 솔루션 탐색기에 모델링 프로젝트가 생성된 것을 확인합니다.

 

모델링 프로젝트를 정상적으로 생성이 완료가 되었다면 이제부터 모델링을 할 수 있는 환경이 모두 완료되었습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 박대식 2012.08.02 14:29 Address Modify/Delete Reply

    좋은 글 잘 읽었습니다.
    한 가지 아는 척 좀 할게요. ^^
    UML에는 Layer Diagram이 없죠. 그래서, 글 중에 VS 2010이 제공하는 UML 다이어그램 목록에서 Layer Diagram 대신 UML Component Diagram이 들어가야 할 것 같습니다.
    앞으로도 좋은 글 부탁 드립니다.

    • 땡초 POWERUMC 2012.08.03 00:08 신고 Address Modify/Delete

      아하 좋은 지적 감사합니다.
      다만, 제가 Layer Diagram의 접두어에 UML을 붙이지 않은 이유가 박대식 수석님께서 말씀하신 이유 때문이랍니다.
      오해의 소지가 있었네요 ^^

본 아티클은 MSDN 에 eBook으로 공개된 문서를 블로그 아티클로 편집하였습니다. VSTS 팀블로그에 의해 작성된 문서의 원문 및 여러 가지 기술 문서는 아래의 링크에서 PDF로 다운로드 받을 수 있습니다. 그리고 본문의 특정 버전을 지칭하는 개발툴 버전 번호는 모두 Visual Studio로 변경되었음을 참고하십시오. (예-Visual Studio 20xx는 Visual Studio로 표기함)

VSTS 팀블로그 MSDN 기술 문서http://msdn.microsoft.com/ko-kr/gg620748 


필자 소개

Microsoft Visual Studio ALM MVP 엄준일
http://blog.powerumc.kr


Visual Studio Korea Team Blog
http://vsts2010.net

감수 : 강성재 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

 

도움주신 분 : 김남영 부장
한국마이크로소프트 개발자 및 플랫폼 사업 총괄

  

[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 1/7 - 들어가기에 앞서...
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 2/7 - 왜 모델링인가?
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 3/7 - 모델링의 표기
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 4/7 - 모델링 다이어그램
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 5/7 - Visualization & Features Pack
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 6/7 - 모델링 확장 (SDK)
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 7/7 - 결론 및 저자 소개

 


1. 들어가기에 앞서…

문서는 모델링의 기본적인 이해와 더 나아가 어플리케이션이나 기능을 Visual Studio 통합 개발 도구로 어떻게 만들어 나가는지 여러분들에게 보여주며 개발자를 대상으로 하는 문서입니다. 모델링이 어렵거나 모델링 작업이 매우 비효율적인 작업이라고 느끼셨던 분들은 문서에서 각 UML 다이어그램의 완성된 모델링을 통해 얼마나 더 이해하기 쉬운지 관전 포인트를 두는 것도 나쁘지 않을 것입니다. 더 나아가 명세서라는 글로 표현되는 모든 것들은 주로 사용하는 용어나 지식, 문장의 흐름에 따라 이해하기 힘들기도 하지만, UML 다이어그램을 통해 여러 사람들과 오해의 소지 없이 올바른 소통이 가능한지도 관전 포인트를 두는 것도 좋습니다.

Visual Studio 통합 개발 도구는 여러분이 개발하기 쉬운 환경을 제공해 주지만, UML 다이어그램 기능으로 여러분들의 개발/설계 능력과 생각의 폭을 한껏 높여줄 것이라 믿어 의심치 않습니다. 혹시 독자 여러분들이, '모델링은 나와 거리가 멀어!', '모델링은 관심 없어' 라고 느끼시는 분들은 특히 관심 있게 보시길 부탁 드리며, 좀 더 개발을 잘 하기 위해 안내해 드리는 백서임을 다시 한번 강조 드립니다.

자! 이제 Visual Studio 응용 프로그램 모델링 완전 정복 백서를 함께 시작해 봅시다.

 

2. Visual Studio Visualization & Modeling 개요

 

2.1. 통합 개발 환경

일반적으로 Visual Studio와 같은 도구를 일컬어 통합 개발 환경(IDE-Integrated Development Environment)이라고 부르며, 최근에는 대부분의 언어적/플랫폼적인 환경에서 이러한 통합 개발 환경의 도구를 지원해 주고 있습니다. 이것은 단순히 개발을 하기 위한 도구가 필요한 것을 넘어 개발자 친숙한 도구와 다양한 어플리케이션의 개발에 필수적인 요소라고 할 수 있습니다.

최근 Visual Studio은 통합 개발 환경을 넘어 어떻게 초기에 설계를 잘 할 것이며, 테스트와 릴리즈를 잘 할 수 있도록 많은 부분을 지원해 주기도 합니다. 개발 영역뿐만 아니라 그 외적인 생산성/협업성/품질관리 등 Visual Studio는 다른 통합 개발 도구에 비해 굉장히 진보하였으며, 점차적으로 개발 도구는 이러한 추세로 더욱 발전하리라 의심치 않습니다.

 

2.2. 개발 프로세스 속의 모델링

어떤 프로젝트를 할 때 얼마나 설계에 비중을 둘 것인지는 매우 중요한 문제입니다. 전체 일정이 6개월일 때 에서 요구사항과 현황을 분석하고 설계를 하는 기간을 3개월로 잡는다면, 실제로 구현을 할 기간은 나머지 3개월 밖에 없습니다. 하지만, 초기에 좀 더 잘 설계를 하는 것이 구현에 이점이 되기도 하지만, 실제로 구현과 테스트, 릴리즈, 그리고 인수인계(또는 서비스 되는 시점) 등 초기 설계에 많은 시간을 투자하여 정작 제대로 동작하는 소스 코드 산출물이 제때 나오지 못할 수 있습니다. 반대로, 초기 요구사항과 현황 분석 및 설계를 1개월의 일정으로 잡는다면 막상 구현은 제대로 설계가 되지 않은 문제로 원하는 어플리케이션의 결과를 얻기 힘들 수 있으며, 그 개발 과정은 제대로 컨텍스트 공유가 되지 않아 많은 불화음이 발생할 수 있을 것입니다.

특히 분석-설계-개발의 과정 동안 설계되는 다양한 문서와 모델링은 실제로 각 단계별로 생산적으로 도움이 되는 경우는 매우 드물기도 합니다. 우리 나라의 SI 와 같은 프로젝트의 특성상 인력의 이동이 매우 빈번하게 일어나기도 하며, SI 프로젝트가 아니더라도 분석/설계 인원이 개발까지 적극적으로 참여하여 올바른 어플리케이션의 개발에 도움이 되는 경우도 드물기도 합니다.

즉, 소프트웨어는 설계-분석도 중요하지만 어떻게 잘 개발할지에 대한 고민도 필요합니다. 설계자는 개발자가 잘 이해하고 설계를 이행할 수 있는 모델이 필요하며, 개발자는 모델을 올바르게 이해하고 직/간접적으로 개발에 도움이 되는 그런 모델을 추구합니다. 기존의 많은 통합 개발 도구는 개발에 필요한 기능을 통합하였을 뿐, 이러한 각 역할간의 통합이 매우 부족했던 것이 사실입니다.

Visual Studio의 모델링 기능은 이런 여러 가지 괴리감을 상당히 좁혔습니다. 모델링을 통해 서로가 이해할 수 있는 다양한 형태의 UML 다이어그램을 제공하고 있으며, 여러 가지 UML 다이어그램은 그저 감상용이 아닌, 개발자가 사용할 수 있는 코드로 변환이 되거나, 의도대로 코드를 작성하는데 도움이 됩니다.


Posted by 땡초 POWERUMC

댓글을 달아 주세요

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 


[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012
[월간 마이크로소프트 5월호 특집기사] C++ 매트로 앱 개발을 위한 C++/CX 언어
[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012를 마치며


본 글 이외에 Visual Studio 팀 블로그를 함께 운영하는 강보람 MVP님의 "Welcome to Metro User Interface" 컬럼과 남정현 MVP님의 "Windows Server 8 미리 보기" 컬럼은 필자의 블로그에 기재하지 않은 점 또한 참고하기 바라며, 저작자의 동의하에 추후에 공개가 될 수 있습니다.



시대가 바뀌면서 Windows도 전통적인 모습에서 벗어나서 새로운 흐름을 만들고자 하는 노력이 시작된 것 같다. 물론 기존의 데스크 탑은 여전히 널리 사용될 것이다. 일상적인 업무에서 사용하는 응용 프로그램이 굳이 메트로 사용자 인터페이스 형태를 띌 필요는 전혀 없을 테니 말이다. 그리고 앞으로도 계속해서 기존의 데스크 탑을 타겟으로 하는 윈폼이나, WPF의 개발도 지속될 것이다. 하지만, 새로운 기회는 작은 틈에서 나오는 것이니 이 틈새를 잘 이해하기 위해서는 Windows 8의 메트로 환경을 잘 이해할 필요가 있다.

 

Windows 8과 Visual Studio 2012은 그야말로 N스크린에 감히 필수적인 환경이라고 말하고 싶다. 그 어떤 플랫폼도 데스크 탑과 테블릿, 모바일 등의 모든 기기와 환경 모두를 지원하는 것은 매우 어려운 일이다. 일반 사용자가 기기마다 사용하는 용도와 스타일이 다르고, 모바일 기기마다 해상도와 특징이 다르기 때문이기도 하지만, 하나의 개발 도구로 모든 상황을 대응할 수 있는 통합 개발 도구가 없는 것도 한 몫을 한다. 아니라고 말하는 독자도 있겠지만, 필자는 데스크 탑 환경까지 확장하는 N스크린을 말하는 것이고, 모든 N개의 스크린에서 똑같은 사용자 경험을 제공하는 것을 말한다. 이런 관점에서 Windows 8과 Visual Studio 2012은 그 해답을 제시하고 있으며, 충분히 가치 있고, 도전해 볼만하다. 이런 이유로 벌써부터 필자는 매우 흥분이 된다.

 

그리고 이 글에서 모두 소개하기는 어려웠지만, Windows Server 8은 그 동안의 Windows 운영 체제가 보여주었던 정적인 모습을 탈피하여 대규모 데이터 센터가 아닌 비용 문제 때문에 고민이 많은 수 많은 중소 규모의 IT 인프라에서도 효율적으로 시스템을 운영하고 애플리케이션 개발자들이 핵심에만 접근할 수 있도록 도와줄 방법을 제공하고 있다. 또한 메트로 스타일의 앱은 단순히 사용자 인터페이스에 관한 새로운 접근일 뿐만 아니라 데스크톱 가상화나 서버 관리자를 위한 새로운 종류의 서비스로 자리잡을 수 있다. 여전히 Charm Bar의 기능은 유용하게 사용할 수 있으며, Application Contract를 정확하게 지원하는 서버용 메트로 앱을 만들어 서버 관리자의 일을 덜어내거나 전혀 새로운 경험의 터치 기반 KIOSK를 손쉽게 만들 수도 있을 것이다. 이것은 전적으로 여러분의 선택에 달려있는 일이 될 것이다. 더 나아가서, Windows Server 8의 여러 기술들이 각종 호스팅 환경은 물론 Windows Azure나 Amazon과 같은 Public Cloud Computing 환경에도 전면적으로 도입이 된다면 더 멋지고 유용한 서비스들이 대거 등장하지 않겠는가 하는 것이 개인적인 생각이다.

 

참고 자료


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 아크몬드 2012.08.02 10:05 Address Modify/Delete Reply

    재밌게 읽고 갑니다.

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 그리고 현재 필자는 NCSOFT에 재직하지 않음을 참고하기 바랍니다.


[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012
[월간 마이크로소프트 5월호 특집기사] C++ 매트로 앱 개발을 위한 C++/CX 언어
[월간 마이크로소프트 5월호 특집기사] Windows 8 시대를 준비하는 Visual Studio 2012를 마치며


엄준일 – 현재 NCSOFT에 재직 중이며, Microsoft ALM MVP와 한국 Visual Studio 팀과 블로그를 운영하고 있다.. 주로 .NET 기술을 전파하고 있고, 마이크로소프트가 지향하는 소프트웨어 개발 프로세스와 통합 및 테스팅 분야를 4년 동안 공부해왔다. 그 외에 CodePlex 오픈 소스 사이트를 통해 프레임워크, 툴 그리고 라이브러리 등을 공개하여 운영 중이다.

 

 


C++ 매트로 앱 개발 준비 사항

C++ 매트로 앱을 개발하기 위해 C++ 개발자는 당장 개발하기 앞서 몇 가지 숙지해야 할 지식과 개념들이 있다. 그리 어려운 것들은 아니지만, 이것을 모르고 접근하려고 하면 어디서부터 시작해야 할지 매우 혼란스러울 것이다. 필자는 과거에 C와 PASCAL을 주로 사용하였고, PC통신이라는 커뮤니케이션을 통해 여러 가지 액션 게임과 대전 게임, 어드벤처 게임을 개발하여 공개해 본 적은 있으나, 최근에 사용되는 C++과 DirectX로 개발해 본 경험은 전무하다. 대신 C라는 언어와 윈도우8이라는 공통 분모를 바탕으로 최대한 C++ 개발자에게 매트로 앱을 쉽게 개발하기 위해 설명할 것이다.

 

C++/CX 란?

첫 번째 준비사항은, C++ 매트로 앱 개발의 위해 C++/CX를 이해해야 한다. C++/CX는 C++ Components Extension(C++ 컴포넌트 확장)이라는 의미로 그 문법은 C++/CLI와 매우 흡사하다. C++/CLI의 대부분은 .NET의 MSIL 형태의 목적 파일로 컴파일 되기 때문에, C++/CLI 응용 프로그램이 동작하기 위해서는 .NET Framework가 설치가 되어야 했었다. 이는 곧, C++/CLI의 gcnew 객체는 .NET 가비지컬렉션의 대상이 되기 때문에 .NET에 매우 가까운 구조였다. 반면, C++/CX은 간단하게 정의하자면 간결한 COM 프로그래밍 언어이다. 그 문법이 C++/CLI와 같지만, 완벽하게 네이티브 형태로 컴파일 된다. 이 말은 즉, .NET Framework이 필요가 없고, .NET 가비지컬렉션의 대상이 되지도 않는다.

앱 개발에 필수 런타임인 WinRT(Windows Runtime)를 이용하여 구현을 하기 위해선 IInspectable 인터페이스를 구현해야 한다. COM 프로그래밍에 직간접적으로 IUnknown 인터페이스를 구현하는 것과 같다. 왜냐하면 IInspectable 인터페이스는 IUnknwon 인터페이스를 상속하기 때문이다.

IInspectable 인터페이스는 곧 COM 개념과 같다. 컴포넌트를 다양한 언어와 공유하고 통합할 수 있는데 WinRT 프로그래밍에서 C#, VB.NET, 그리고 JavaScript에서 IInspectable을 구현하는 객체를 사용할 수 있게 된다. (단, IInspectable 인터페이스는 컴파일러에 의해 구현될 수 있다)

MIDL_INTERFACE("AF86E2E0-B12D-4c6a-9C5A-D7AA65101E90")

IInspectable : public IUnknown    

{

public:

virtual HRESULT STDMETHODCALLTYPE GetIids(

/* [out] */ __RPC__out ULONG *iidCount,

/* [size_is][size_is][out] */ __RPC__deref_out_ecount_full_opt(*iidCount) IID **iids) = 0;

 

virtual HRESULT STDMETHODCALLTYPE GetRuntimeClassName(

/* [out] */ __RPC__deref_out_opt HSTRING *className) = 0;

 

virtual HRESULT STDMETHODCALLTYPE GetTrustLevel(

/* [out] */ __RPC__out TrustLevel *trustLevel) = 0;

 

};

Code 1 IInspectable 인터페이스 정의

COM 프로그래밍 중 가장 빈번하게 사용되는 것 중 하나가 참조 카운팅인데, ^ 기호로 참조 카운팅을 관리하는 개체를 ref new로 인스턴스를 생성하면 더 이상 귀찮은 AddRef와 Release메서드를 호출해 줄 필요가 없다. 예를 들어, Platform::WeakReference 등을 이용하여 생성된 객체에 대해 수명 관리를 위임할 수 있는 방법들이 제공된다.

정리해보면, WRL(Windows Runtime Library)가 C#, VB.NET, JavaScript로 개발할 수 있는 환경을 제공하는 것이 바로 COM이며, 이를 쉽게 개발할 수 있는 언어가 C++/CX인 것이다.

 

프로퍼티(Property) 사용

C++/CX는 프로퍼티를 사용할 수 있는 키워드를 제공한다. C++/CX 프로퍼티는 .NET 프로퍼티와 내부적으로 똑같이 동작한다. 이 프로퍼티는 컴파일 시에 get/set 메서드를 자동으로 생성해 준다. 프로퍼티는 읽기 전용/쓰기 전용, 그리고 이 두 가지 모두를 지원하도록 구현할 수 있다.

이 프로퍼티는 매트로 앱을 개발하면서 상당히 자주 만나게 될 것이다. 왜냐하면 XAML과 함께 앱을 구현하면서 바인딩(Binding) 개념에 프로퍼티 구현이 필수적이기 때문이다. 그래서 XAML 바인딩에서 INotifyPropertyChanged 인터페이스를 구현하여 데이터 모델과 바인딩된 데이터간에 데이터 변경에 대해 알려줌으로써 1-way 또는 2-ways 바인딩을 사용한다.

#include "pch.h"

 

public ref class Person sealed

{

private:

    Platform::String^ name;

    int age;

 

public:

    Person(Platform::String^ name)

    {

        this->name = name;

    }

 

    // 읽기 전용 프로퍼티

    property Platform::String^ Name

    {

        Platform::String^ get() { return this->name; }

    }

 

    // 읽기 쓰기 프로퍼티

    property int Age

    {

        int get() { return this->age; }

        void set(int age)

        {

            if( age <=0 ) throw ref new Platform::InvalidArgumentException();

 

            this->age = age;

        }

    }

};

Code 2 C++/CX 프로퍼티

이 프로퍼티는 내부적으로 생성되는 get/set 매서드를 사용하는 것이 아니라 선언된 프로퍼티를 마치 맴버 변수처럼 사용이 가능하다. 일반적인 C++ 에서는 get/set 메서드를 구현하는 방식으로 person->setName(L"Junil Um"); 이런 코드를 이상 사용하지 않는다.

아래의 코드와 같이 프로퍼티로 선언한 이름으로 직접 엑세스할 수 있다.

Person^ person = ref new Person("Junil Um");

person->Age = 20;

 

필자는 매크로를 사용하여 좀 더 빠르고 쉽게 프로퍼티를 선언하여 사용하는 방식을 권하고 싶다. 아래의 코드는 프로퍼티의 get 또는 set, get/set 을 매크로로 대체한 것이다.

#define __PROPERTY_GET_FUNC(TYPE, NAME) TYPE get() { return m_##NAME; }

#define __PROPERTY_SET_FUNC(TYPE, NAME) void set(TYPE value) { m_##NAME = value; }

#define DEFINE_PROPERTY(TYPE, TYPENAME) property TYPE TYPENAME

#define __PROPERTY(TYPE, NAME, IMPL) \

private: \

    TYPE m_##NAME; \

public: \

    DEFINE_PROPERTY(TYPE, NAME) \

    { \

    IMPL \

    } \

 

#define PROPERTY_GET(TYPE, NAME) __PROPERTY(TYPE, NAME, __PROPERTY_GET_FUNC(TYPE, NAME))

#define PROPERTY_SET(TYPE, NAME) __PROPERTY(TYPE, NAME, __PROPERTY_SET_FUNC(TYPE, NAME))

#define PROPERTY(TYPE, NAME) __PROPERTY(TYPE, NAME, __PROPERTY_GET_FUNC(TYPE, NAME) __PROPERTY_SET_FUNC(TYPE, NAME))

 

 

안전한 포인터 사용, 대리자(Delegate)

포인터 함수는 C++에서 흔히 사용되지만, WinRT 프로그래밍에서는 직접적인 포인터 연산이 그리 좋은 코드는 아닐 수 있다. 이유는 간단하다. WinRT APIs (내장 라이브러리)들이 인자 값으로 포인터가 아닌 대리자(Delegate)를 즐겨 전달 받는다. 그리고 이벤트(Events) 프로그래밍에서 대리자를 공통적으로 사용한다.

void ShowMessageBox(Platform::String^ str)

{

    auto dialog = ref new Windows::UI::Popups::MessageDialog(str);

    dialog->ShowAsync();

}

 

 

void App::OnLaunched(LaunchActivatedEventArgs^ pArgs)

{

    auto ptr = &ShowMessageBox;

 

    ptr("Hello Metro App with C++");

}

Code 3 함수 포인터

.NET 에서는 대리자(Delegate)를 안전한 포인터 함수라고 정의한다. 포인터 함수를 사용하든, 대리자를 사용하든 결과는 똑같지만 이왕이면 안전하게 제어할 수 있는 대리자를 사용하라는 것이다. 사실, .NET 에서 대리자는 일반적인 클래스(Class)와 똑같이 취급한다. 대리자는 컴파일이 되면 일반적인 클래스로 정의되기 때문이다.

어쨌든 위의 포인터 함수를 대리자로 바꾸어보면 다음과 같다.

delegate void ShowMessageBoxHandler(Platform::String^ str);

void ShowMessageBox(Platform::String^ str)

{

    auto dialog = ref new Windows::UI::Popups::MessageDialog(str);

    dialog->ShowAsync();

}

 

void BlankPage::OnNavigatedTo(NavigationEventArgs^ e)

{

    auto msghandler = ref new ShowMessageBoxHandler(&ShowMessageBox);

    msghandler("Hello Metro App with C++");

}

Code 4 C++/CX 대리자

C++/CX 매트로 만들기 첫 걸음

이제 매트로 앱 코드를 작성하고 이해하기 위한 어느 정도의 준비는 된 것 같다. 매트로 앱은 처음 앱의 처음 진입점이 App클래스의 OnLaunched 메서드이다.

void App::OnLaunched(LaunchActivatedEventArgs^ pArgs)

{

    auto sampleData = ref new SampleDataSource();

 

    auto rootFrame = ref new Frame();

    TypeName pageType = { GroupedItemsPage::typeid->FullName, TypeKind::Metadata };

    rootFrame->Navigate(pageType, sampleData->ItemGroups);

 

    Window::Current->Content = rootFrame;

    Window::Current->Activate();

}

Code 5 앱 진입점인 App 클래스

 

위의 코드의 LaunchActivatedEventArgs 인자는 main 함수의 인자 값이라고 생각해도 좋다. 단지 다른 점을 찾는다면 LaunchActivatedEventArgs 객체는 COM Proxy 개체로써, 앱 실행시 인자 값 등을 전달 받을 수 있다. .

이곳에서 앱의 초기화를 수행한 후에 Frame->Navigate 메서드로 사용자 인터페이스를 가지고 있는 화면으로 이동한다. C#,VB.NET 그리고 C++ 매트로 앱은 XAML(Extensible Application Markup Language)을 이용한다. 처음 .NET Framework 3.0에서 WPF 응용 프로그램에서 XAML을 주로 사용하였으나, .NET Framework 4.0에 와서는 별도의 구성요소로 분리가 되었고, 현 버전에서는 완전히 독립된 컴포넌트로 구성되었다. XML은 언어의 분류상 객체지향언어로 구분하게 되는데 XAML은 객체지향언어와 상호작용이 가능하여 그 확장의 가능성이 무한대로 볼 수 있다.

매트로 앱과 친해지기 위해서는 C++/CX도 이해해야겠지만, XAML도 항상 벗처럼 삼아야 한다. XML 프로그래밍에 익숙한 독자라면 XAML이 어렵지 않을 것이다. XML 프로그래밍은 책 몇 권의 분량으로도 모두 담지 못할 것이다. 그리고 XAML 또한 책 한 권 분량 이상으로 그 내용이 방대하므로 더 자세한 내용은 MSDN을 통해 천천히 익히길 바란다.

Figure 1 Blend for Visual Studio 2012

 

XAML을 처음부터 거부감을 느낄 필요는 없다. 당장은 앱을 만들기 위해 디자인을 해야 하는데, Blend for Visual Studio 2012 (과거 Expression Blend) 라는 디자인 도구가 있다. XAML은 이 도구를 이용하여 디자인을 하면 개발자도 쉽게 사용자 인터페이스를 완성할 수 있다.

지면으로 모든 것을 설명하지 못하니, 다음의 링크를 반드시 확인하기 바란다.

http://msdn.microsoft.com/en-us/windows/apps/br229516

이 링크에서 매트로 앱을 만들기 위한 개발 도구 및 SDK와 샘플 앱을 C#, C++, JavaScript로 구현해 놓았고, 마이크로소프트가 제공하는 품질 좋은 디자인 파일도 있다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

협정 세계시(UTC) 시간으로 2012/06/01, Windows 8 Release Preview와 Visual Studio 2012 Release Candidate 버전이 MSDN Subscription을 통해 공개가 되었다. 이번 버전에는 Windows 8 Consumer Preview(CP) 버전과 Visual Studio 11 Beta 버전에 비해 잔존하는 버그가 상당히 줄어들었다. Windows 8 CP 버전을 쓰면서 가장 사용하기 불편했던 점은 데스크톱 응용 프로그램들이 이유 없이 멈추고, Visual Studio 11 Beta 의 IDE가 자주 뻗어 버리는 현상이 눈에 띄게 사라졌다. 더불어 이 두 가지 Release의 성능도 눈에 띄게 향상되었다. 마이크로소프트의 많은 노고에 박수를 보내고 싶다.

   

Windows 8 Release Preview와 Visual Studio 2012 Release Candidate 피드백

Windows 8 Release Preview에서 조금 변화를 원한다면, Metro 시작화면에는 Metro 응용 프로그램만 나열되었으면 한다. 그리고 폴더 기능이나 같은 카테고리 앱끼리 정렬할 수 있으면 더 좋겠다. 데스크톱 응용 프로그램과 Metro 앱이 마구 섞여 있으니 검색 기능 없이 찾기가 힘들다.

   

Visual Studio 2012 Release Candidate 버전에서는 아이콘의 컬러를 흑백에서 컬러로 바꾸었다고는 하지만, 필자 개인적으로는 솔루션 탐색기부터 산만해진 것은 변함이 없다. 컬러를 넣으려면 넣고 빼려면 빼지 말이다. 아이콘 컬러를 넣어달라는 수많은 사용자 피드백에도 불구하고 또 이렇게 산만해진 컬러링은 정말 최악이다.

결론은 둘 중 하나인 것 같다 사용자 피드백을 씹는다거나, 사용자 피드백이 좀 약했다던가...

   

   

Windows 8 SDK, 이빨 빠진 호랑이 격!

자! 이제 본론으로 들어가서 Windows 8 SDK(Software Development Kit)과 Visual Studio 2012에 매우 중요한 것이 변경되었다. 이미 pcworld.com 에서 Release 제품이 나오기 이전에 예고를 했다. Windows 8 SDK 에는 Command-Line 과 관련된 대부분의 실행 파일들이 포함되지 않는다. Windows 8 SDK는 이 링크에서 다운로드 받을 수 있다.

   

위의 Windows 8 SDK 링크를 참고하면 다음과 같은 문구를 찾을 수 있다. 이번 SDK가 DirectX SDK와 통합된 것은 그다지 관심이 없다. 다만, 빌드와 관련된 모든 Command-Line(명령줄)을 제거했다는 것이 중요하다.

   

Windows 8 SDK를 이용하여 단독으로 아무것도 할 수 없다. 일반적으로 마이크로소프트에서 제공하는 Software Development Kit(SDK)에는 개발에 필요한 대부분의 기능들이 포함되어 있다. 가장 중요한 것이 SDK 에 포함되어 있는 Compiler(컴파일러)이다. Visual C++, Visual C#, Visual Basic.NET 으로 작성된 소스 코드를 컴파일하기 위해서는 Compiler가 필요한데, Windows 8 SDK 에서는 제공해 주지 않는다. 그리고, 복잡한 워크플로우로 빌드되는 최근의 개발 환경에서 MSBuild.exe가 필요하다. MSBuild.exe는 인증 작업, 링크 작업, 리소스 병합 등 복잡한 작업을 순차적으로 처리해주는 매우 훌륭한 도구이다. Windows 8 SDK 에서는 이것도 빠져있다.

   

이제 좀 현실감이 올 것이다. 가장 먼저 타격을 받는 것이 바로 통합 빌드 시스템이다. 빌드 서버에 Visual Studio 2012를 설치하지 않으면 Windows 8 Metro App이나 .NET Framework 4.5, 그리고 최신 버전의 Visual C++ 소스 코드를 컴파일하거나 배포할 수 없다. 이는 좀 더 복잡해지는 라이선스 정책과도 교묘해진다. 일반적으로 Visual Studio의 라이선스는 개발자당 1 Copy의 Per User 라이선스이다. 그렇다면 빌드 서버에서 빌드를 하기 위해 Visual Studio를 설치했다면, 이는 Per User 라이선스를 적용 받는 것일까?

   

물론, 무료로 사용할 수 있는 Visual Studio 2012 Express 버전이 있다. 무료이고 상용으로 사용해도 제약이 없는 버전이지만, 제품 자체가 매우 최소한의 기능만 제공한다. Visual Studio Gallery 웹 사이트와 Visual Studio Extension Manager(확장 관리자)에서 제공하는 확장 기능을 사용할 수 없다. (단, Templates(템플릿), ToolBox(툴박스)와 관련된 것들만 수동으로 설치가 가능하다). 협업이나 형상 관리를 위해 SVN Source Control Provider(SVN 소스 제어 기능)나 Team Explorer(팀 탐색기)도 설치되지 않는다. 교육용으로는 적합할 지 모르겠으나, 실제로 기업 현장의 필드에서 사용하기엔 있으나 마나...

   

다시 원점으로 돌아가서 Visual Studio 2012과 .NET Framework 4.5의 새로운 기능을 살펴보자.

   

필자가 어림 잡아 새롭다거나 눈에 띄는 Features를 아래와 같이 아주 간단하게 정리해보았고, 나름대로 간략한 소감을 적어본다.

  • Visual Studio 2012
    • 매트로 앱 개발 - Visual Studio 2012는 매트로 앱 개발을 위한 툴 그 이상 이하도 아니다.
    • C++ Editor 개선 - 개선이 되었더라도 3rd-party 제품인 Visual Assist 를 $99 에 사서 쓰는 것이 더 좋다.
    • Graphics Tools - AutoDesk, Pixel Shader를 만들고 수정하기 편리해졌다. 그런데 이런 기능은 사용하기 늘 부족하기 때문에 NVIDIA Parallel Nsight 2.1 같은걸 쓰는 것이 이로울 것이다. 항상 느끼는 것이지만, 만들다가 만 Features가 Visual Studio에는 너무 많다.
  • .NET Framework 4.5
    • Portable Class Libraries - 마이크로소프트 BCL Team이 Visual Studio 2010 버전으로 공개했다. 그다지 새롭지 않다.
    • Parallel Computing - 가려웠던 부분을 상당부분 긁어줄 것 같다. Parallel 라이브러리에는 찬사를 보내고 싶다.

   

이 외에는 대부분이 성능적인 개선과 기능적으로 보강한 것들이 대부분이다.

   

   

이제 대략적인 결론이 나온다. 매트로 앱만 개발하기 위해서 굳이 Visual Studio 2012를 사용하는 것은 비용적으로 비효율적일지도 모른다. 매트로 앱은 Visual Studio 2012 Express for Windows 8 을 쓰고, 그 외의 시스템적으로 변경사항을 최소화하기 위해 Visual Studio 2010이나 Visual Studio 2008을 사용하고, 더불어 Windows 7 SDK and .NET Framework 4 또는 Windows 7 SDK and .NET Framework 3.5 SP1 을 사용하는 것이 좋겠다. 그리고 필자는 이번 SDK 에 Compiler 배포를 모두 제거한 것을 이해하기 힘들다. 사실상 .NET 환경의 개발자 또는 기업을 대상으로 돈 내놓으라는 것과 다를 바 없다. 그리고 마이크로소프트의 기술은 점점 발전하는데, 기술 이외의 것들은 퇴보적인 경향을 보인다.

   

참고로 다시 한번 상기하자면, 아래는 Windows 7 SDK for .NET Framework 4의 설치 화면이다. 이번 Windows 8 SDK 에는 아래의 대부분이 빠진다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 네모 2012.06.07 00:19 Address Modify/Delete Reply

    컬러부분은. 계속 수정중이라 하니 좀더 지켜봐야 할 듯 합니다.
    기본테마는 더 밝아졌으면 좋겠고 다크는 괜찮더군요. 하지만 사용하는 시간이 줄어드니 무료로 버텨보고 그 돈으로 맥이나 알아봐야 겠네요.

  2. 네모 2012.06.07 00:20 Address Modify/Delete Reply

    컬러부분은. 계속 수정중이라 하니 좀더 지켜봐야 할 듯 합니다.
    기본테마는 더 밝아졌으면 좋겠고 다크는 괜찮더군요. 하지만 사용하는 시간이 줄어드니 무료로 버텨보고 그 돈으로 맥이나 알아봐야 겠네요.

여기까지 따라오시면서 우분투의 사용자 인터페이스와 몇 가지 명령어가 어느 정도 자연스러워 지셨는지요? 몇 번 우분투를 사용해 보시면 알겠지만, "우분투 소프트웨어 센터"에서 필요하신 소프트웨어를 편하게 모두 다운로드 받으실 수 있답니다. 급하신 분들은 먼저 개발 도구와 툴 들을 설치하셔도 됩니다. ^^*

어제 오늘 할 것은 우분투의 테마를 좀 바꾸어볼까 합니다. 기본 테마가 나쁘지는 않지만, 제가 주로 사용하는 개발 툴은 아이콘을 크기를 줄이고, 더 넓은 화면으로 쓰고 싶습니다. 이럴 때 유용한 소프트웨어가 있으니, 다음의 링크를 참고하시기 바랍니다.

   

Gnaom Classic 테마입니다. 다음의 링크에 자세한 내용을 소개하고 있습니다.

http://ioriy2k.pe.kr/archives/4357

   

   

자! 그럼 설치 후 재 부팅을 하면 로그인 화면이 나타납니다. 여기에서 아래의 그림과 같이 사용자 이름 오른쪽의 아이콘을 클릭해 보세요.

   

Gnome Classic 테마를 선택하시고 로그인을 합니다.

   

   

호호~! 아래와 같이 예쁘게 테마가 바뀌었습니다. 약간 MAC OS와 같은 스타일 비슷하네요.

좌측 상단의 영역은 윈도우의 "시작" 과 비슷한 기능으로 소프트웨어의 목록을 볼 수 있습니다.

오른쪽 상단은 뭐 그 전과 지금과 마찬가지고요.

좌측 하단에 아이콘을 DRAG&DROP 하시면 빠른 아이콘으로 등록하실 수 있습니다. 아이콘을 우측 하단쪽으로 등록하시면 좌측/우측으로 정렬하여 빠른 아이콘을 등록할 수 있답니다.

그리고 마지막으로 오른쪽 하단은 4개의 네모 상자가 보이는데요. 이것은 가상 윈도우로 윈도우 화면을 너 넓게 쓸 수 있답니다. 단축키를 쓰는게 더 빠르겠죠? CTRL+ALT+상/하/좌/우 로 빠르게 쓸 수 있습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

Visual Studio 11의 솔루션 탐색기는 이전 버전에 비해 매우 독특한 구조를 가지게 되었습니다. 그 중에서 Visual Studio 11에서 솔루션 탐색기 기능을 최대한 활용하는 방법을 살펴볼텐데요, 그냥 가볍게 보시면 될 것 같습니다.

1. 다중 인스턴스로 사용하기

다중 인스턴스는 솔루션 탐색기를 하나가 아닌 여러 개로 띄울 수 있는데요. 단, 현재 로드된 솔루션의 솔루션 탐색기 인스턴스를 생성할 수 있습니다. 만약, Visual Studio 11에서 여러 솔루션을 하나의 Visual Studio 11 인스턴스에서 실행할 수 있다면 다중 인스턴스의 솔루션 탐색기가 더욱 편리할 거라는 아쉬움이 있네요.

아래의 그림과 같이 우측 끝에 있는 아이콘을 클릭하면 똑같은 인스턴스를 생성한답니다.

여러 솔루션 탐색기의 인스턴스를 사용하여 프로그래을 작성하는 프로젝트에 스크롤을 위치시키고, 또 하나는 단위 테스트 프로젝트에… 또 하나는 전체 솔루션이 훤히 보이도록 띄어놓았습니다.

이제 하나의 솔루션 탐색기에서 마우스 스크롤 쫙쫙~ 올리고 내리고 할 필요가 없어졌네요. 더불어 멀티 모니터를 사용한다면 효과가 금상첨화겠지요?

   

2. 코드 파일 미리보기

중간에 보이는 아이콘의 이름 "Preview Selected Items"은 말 그대로 코드 파일을 미리 보는 기능이랍니다. 이 옵션은 Visual Studio 11을 설치하면 기본적으로 선택되는 옵션입니다.

이 기능은 솔루션 탐색기에 파일을 한 번 클릭할 때마다 에디터 창이 열립니다. 좌측의 빨간색 탭은 솔루션 탐색기에서 코드 파일을 더블 클릭하거나 F7을 누를 때 일반적으로 좌측부터 정렬되는 에디터입니다.

오른쪽의 노란색의 탭 하나가 바로 한 번 클릭할 때마다 열리는 미리 보기 탭입니다. (필자는 개인적으로 이 옵션을 껐답니다 ^^;)

   

3. 솔루션 탐색기를 격리시키기

솔루션 탐색기를 격리시키는 방법(용어는 필자가 나름대로 칭하였습니다)입니다. 이 방법이 꽤나 쓸만한 기능인데, 솔루션 탐색기의 선택된 항목이 솔루션 탐색기의 최상위 루트가 되는 기능입니다. 예를 들어, 아래와 같이 Core 프로젝트를 펼치면 굉장히 길어지는데요, 단위 테스트도 같이 하려면 Core.Tests 프로젝트도 펼쳐져 있어야 합니다. 이러다가 대부분 솔루션 탐색기가 위아래 정신 없이 스크롤하게 됩니다.

   

그럼 솔루션 탐색기 다중 인스턴스를 이용해서 좀 더 스마트하게 사용해 볼까요? 바로 "Scope to This" 기능입니다.

   

이 기능을 이용해서 아래와 같이 스마트하게 솔루션 탐색기를 배치할 수 있습니다. 자주 코딩하는 Core 프로젝트랑 Core.Tests 프로젝트랑 각각 최상위 루트에 배치해서 귀찮은 스크롤도 없어지고 하위 여러 자식의 트리구조를 없애서 보기에 깔끔해 졌네요.

   

이런 경우는 인터페이스 프로그래밍을 할 때도 매우 유용합니다. 인터페이스를 선언하고 이를 구현하면 서로간에 왔다 갔다 하는 경우가 매우 많거든요. "Scope to This" 기능으로 좌측에 인터페이스 파일 하나만 배치시키고, 우측에서는 인터페이스를 구현하고 파생되는 구현 클래스가 뭉쳐있는 폴더만 격리시켰습니다.

 

어때요? 이제 솔루션 탐색기를 스마트하게 사용할 수 있겠지요?

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 희정 2012.03.26 17:31 Address Modify/Delete Reply

    아. Scope to This 기능은 정말 좋네요. :D

   

   

  • 주최 : 한국 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

댓글을 달아 주세요

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

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

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

   

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

   

라이선스 동의 화면

   

설치 패키지 선택 화면

   

설치 시작 화면

   

설치되는 구성 요소 목록

   

   

   

   

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

   

   

Visual Studio 2010 Beta 2 의 Splash 화면

   

   

Visual Studio 시작 페이지 화면

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

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

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

 

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

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

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

기존 제품

Beta 2 부터 적용되는 제품

Visual Studio Team Suite

Visual Studio Ultimate

Visual Studio Test Edition
Visual Studio Database Edition
Visual Studio Architecture Edition Visual Studio Development Edition

Visual Studio Premium

Visual Studio Professional

Visual Studio Professional

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

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

이전에 MousePresentationTracker 를 예제로 만들어서 공개한 적이 있습니다. 몇 번 사용해 보면서 Visual Studio 2010 의 새로운 확장 모델인 VSIX 에서는 좀 사소한 버그가 있었습니다. 이 문제 때문에 심히 불편했습니다만, 정식 버전에서는 반드시 고쳐지길 바랄 뿐입니다. ^_^;

문제는 VSIX 의 어셈블리명(DLL) 이 Umc.Core.Tools.MousePresentationTracker.dll 처럼 '.' 이 들어가면 Visual Studio 2010 이 제대로 로드하지 못합니다. 그렇기 때문에 아래와 같이 Assembly Name 은 반드시 "파일명.확장자" 와 같은 이름을 주어야 합니다.

 

기타 확장 기능 참고 

 
Posted by 땡초 POWERUMC

댓글을 달아 주세요

Visual Studio 의 단위 테스트의 문제

최근 가장 트랜드한 개발 방법론 중의 XP 에서는 단위 테스트 코드를 작성하도록 권장하고 있습니다. 단위 테스트는 그 코드를 작성하기에 많은 노력이 필요하지만, 그 이상의 가치와 편리함, 그리고 중요성 등을 잘 알고 있기 때문에 프로젝트의 대부분의 코드 또는 테스트 등은 단위 테스트를 작성합니다.

하지만 Visual Studio 의 단위 테스트에 치명적인 문제가 있었네요. 바로 Visual Studio 의 단위 테스트는 x64 를 지원하지 않습니다. 단위 테스트를 수행할 대상 프로젝트나 어셈블리가 x64 라면 단위 테스트를 수행할 수 없습니다. 만약 프로젝트의 속성의 빌드가 Any Cpu 또는 x86 이 아닌 x64 라면 테스트는 오류가 나고 맙니다.

먼저 단위 테스트 코드를 작성하여 단위 테스트를 수행하였습니다. 테스트를 실시하는 어셈블리는 x64 로 빌드된 어셈블리이고, 이것을 단위 테스트에 참조하여 사용하였습니다. 그리고 제가 사용하는 OS 는 Windows 7 x64 버전입니다.

이미 언급했지만, 프로젝트의 빌드 타입이 Any CPU 또는 x86 에서는 잘 돌아갑니다. 하지만 Unit Test 는 64비트 어플리케이션에 대해 BadImageFormatException 을 내뱉습니다. 일반적으로 BadImageFormatException 이라고 하면 어셈블리의 헤더 정보 등이 잘못되었거나 말 그대로 잘못된 이미지의 어셈블리일 경우 발생합니다.

테스트 메서드 MseServiceCatalogTest.ServicesImportTest.ServicesImportUnitTest.ServicesImportTest에서 예외를 throw했습니다. System.BadImageFormatException: 파일이나 어셈블리 'Microsoft.MSE.Tools.MetadataLoader.Module, Version=7.1.33.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' 또는 여기에 종속되어 있는 파일이나 어셈블리 중 하나를 로드할 수 없습니다. 프로그램을 잘못된 형식으로 로드하려고 했습니다.

   

Visual Studio 단위 테스트는 x86 만 지원한다~?   

이리저리 검색해보니 Visual Studio 의 Unit Test 에서는 x32 어셈블리만을 로드할 수 있다고 합니다. 아마도 Unit Test Framework 가 x86 으로 빌드가 된 모양새입니다. 테스트 대상 프로젝트를 Any Cpu 로 맞추고 테스트 프로젝트를 x64 로 빌드하고 테스트를 수행해도 마찬가지 결과입니다.    

MseServiceCatalogTest.ServicesImportTest.ServicesImportUnitTest, MseServiceCatalogTest 형식을 가져올 수 없습니다. 오류: System.BadImageFormatException: 파일이나 어셈블리 'MseServiceCatalogTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' 또는 여기에 종속되어 있는 파일이나 어셈블리 중 하나를 로드할 수 없습니다. 프로그램을 잘못된 형식으로 로드하려고 했습니다.

파일 이름: 'MseServiceCatalogTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
위치: System.RuntimeTypeHandle._GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, Boolean loadTypeFromPartialName)
위치: System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark)
위치: System.RuntimeType.PrivateGetType(String typeName, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark)
위치: System.Type.GetType(String typeName)
위치: Microsoft.VisualStudio.TestTools.TestTypes.Unit.UnitTestExecuter.GetType(UnitTestElement unitTest, String type)
위치: Microsoft.VisualStudio.TestTools.TestTypes.Unit.UnitTestExecuter.ResolveMethods()

   

테스트 대상 어셈블리의 소스 코드가 없으면 어떡해~?    

그렇습니다. 소스 코드가 없으면 빌드 플랫폼을 변경할 수 없어서 단위 테스트를 수행하기가 참 곤란해 지겠지요. 하지만 뭐 방법은 없겠습니까만은 일부 제한적인 방법으로 x64 어셈블리를 x86 어셈블리로 변경할 수 있습니다.    

닷넷 어셈블리는 헤더 정보에 빌드 플랫폼 정보가 포함이 되어 있는데, 이것을 변경하면 됩니다. 그리고 .NET Framework SDK 에는 이러한 헤더를 변경할 수 있는 도구가 제공이 됩니다. 이 도구는 CorFlags.exe 로 CLR 버전을 업그레이드 하거나 x64 어셈블리를 x86 어셈블리로 헤더를 변경할 수 있습니다. 반대로 x64 어셈블리를 x32 어셈블리로 되돌릴 수 있습니다.    

덧붙여, .NET 1.1 어셈블리를 .NET 2.0 어셈블리로 변경하고 싶다면 이 방법으로 가능합니다. 또는 64비트 운영체제에서 32비트로 어셈블리를 변경하여 테스트 용도 등으로 사용할 수 도 있습니다.    

x64 어셈블리를 아래와 같이 x86 어셈블리로 변경할 수 있습니다.

C:\>CorFlags ClassLibrary.DLL /32BIT+

   

강력한 이름으로 서명된 x64 어셈블리는 어떻게?    

강력한 이름으로 서명된 어셈블리는 유감스럽게 CorFlags 로 헤더를 변경한 후에 다시 한번 강력한 이름으로 서명하면 됩니다. 유감스럽게도 만약 키 파일이 없다면 어셈블리를 사용할 수 없게 됩니다. 위에서 얘기 했듯이 이러한 이유로 제한적인 방법이라고 언급을 했습니다. ^_^;    

아무튼 저 같은 경우는 이 키 파일이 없어서 그만 OTL
그나마 다행인 것은 Visual Studio 2010 버전에서는 x64 어셈블리도 단위 테스트를 할 수 있다고 하네요.  

참고 문헌
CorFlags 변환 도구(CorFlags.exe)
http://msdn.microsoft.com/ko-kr/library/ms164699.aspx

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 강영수 2011.04.28 17:11 Address Modify/Delete Reply

    좋은글 잘 보구 갑니다.