.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

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

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 와 호환이 전혀되지 않습니다.

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