.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

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

필자는 일전에 이와 관련되어 상당한 분량의 포스팅을 올린 적이 있다. 총 5회의 아티클 중 마지막 회를 모두 작성하지는 못했지만, 지금 이 내용이 그 마지막 회의 내용과 어느 정도의 내용과 유사하다고 보면 된다.


그 중, 4회 아티클 ‘[실전 ASP.NET Session [4] - 세션상태 마이그레이션]5’의 내용은 본 아티클의 내용에서 매우 중요한 기초 내용이 된다. 이 글을 읽고 있는 독자 중 잘 이해가 되지 않는다면 필자가 이전에 작성한 포스팅을 반드시 읽어보기를 바란다.

그리고 위의 필자가 작성한 링크의 아티클은 5년전에 작성된 글임을 인지해 주길 바란다. 그 때는 필자가 지금보다도 더 실력이 형편 없었을 뿐더러 현재 추구하는 웹 개발의 트랜드와 상이한 면이 있을 수도 있을 것이다. .NET Framework 버전과 개발툴의 버전도 지금 사용하는 버전과는 한참 예전 버전이었다. 하지만 5년이 지난 글임에도 기초적인 내용은 모두 탄탄하게 짚고 넘어가므로 한번씩 보는 것도 나쁘지 않다.

ASP.NET이 지원하는 분산 세션 상태(Session State)

일반적으로 1대 1의 물리적인 관계는 분명 분산환경이긴 하지만 분산 환경이라고 말하지 않는다. 어떤 물리적인 환경에 배치하든, 통계학의 분산에 대한 기대값이나 편차의 해는 변하지 않기 때문이다.

분산 환경에서 더 나은 성능을 내기 위한 알고리즘과 휘발성인 메모리 안에서 데이터가 유실되지 않도록 원자성(Atomicity)을 유지할 수 있는 방법을 제공해야 한다. 또 웹 서버의 세션이라는 특징은 매우 빈번하게 엑세스 되고, 업데이트와 삭제 작업도 매우 많이 발생한다.

하지만, 안타깝게도 memcached[1]는 ‘get’ 명령의 원자성(Atomicity)를 보장하지 않는다고 한다.

A series of commands is not atomic. If you issue a 'get' against an item, operate on the data, then wish to 'set' it back into memcached, you are not guaranteed to be the only process working on that value. In parallel, you could end up overwriting a value set by something else.


하지만 괜찮다. 웹 서버의 세션은 동시다발적인 병렬 작업으로 요청이 들어올 수 없는 구조이다. 웹 서버로 사용자의 요청이 들어올 때, 사용자의 웹 브라우저에 가진 쿠키 값이 신원보증을 하는 값, 또는 해시된 세션의 키 값이다. 그러므로 한 세션에 대해 동시에 여러 클라이언트(사용자 웹 브라우저)의 요청은 있을 수 없는 일이다.

하지만 불가능한 것도 아니다. 예전에는 자바스크립트가 허용되는 게시판이나 이와 유사한 환경에서 악성 스크립트를 심어 놓으면, 그 글을 보는 누군가는 브라우저의 쿠키 값을 취득하여 해커에게 보내고, 해커는 세션이 만료되는 20분(일반적인 세션 만료 시간) 전에 취득한 세션 값으로 재 요청을 하게 되면 다시 세션이 연장되고, 세션이 로그인된 상태인 경우 해커도 로그인된 상태로 입장하는 것이 가능하다

때문에 완전히 같은 해시된 세션의 키 값으로 여러 클라이언트(사용자의 웹 브라우저)의 요청이 온다는 것은 사용자의 세션 값이 털려서, 누군가 악용하고 있다고 보는 것이 맞다.

그러므로 아주 정상적이고 일반적인 환경에서 원자성을 제공하지 않는 ‘get’ 명령은 전혀 문제가 되지 않으며, 오히려 원자성을 보장할 수 없는 문제로 더 좋은 Read 성능을 낼 수 있기 때문에, memcached 가 세션 서버로 사용하기에 redis[2] 보다 더 좋을 수 있다.

ASP.NET이 제공하는 세션 관리 요약

아무런 설정이 없다면 In-Proc, 즉 로컬 머신의 메모리를 사용하게 된다. 만약 불행히도, Win32 DLL을 참조하는 웹 응용 프로그램이라면 웹 서버의 메모리의 크기 따윈 무시하고 최대 2GB 밖에 사용할 수 없게 된다.

이를 극복하는 방법으로 윈도우 서비스로 백그라운드로 실행되는 ASP.NET Session State Service 서비스를 사용하면 좋다. 여러 웹 응용 프로그램이 하나의 Session State Service에 연결되더라도 웹 응용 프로그램마다 고유의 Identity Key(Guid)가 할당되고, 이를 Primary Key로 구분하게 된다. 이 NT Services가 다운되거나 재시작하지 않는 이상 웹 서버의 세션은 항상 유지할 수 있다.

긴급한 패치로 웹 응용 프로그램을 업데이트 해야 하는 경우, IIS가 재시작 되는 경우가 발생할 수 있는데 이 때 Worker Process에 의해 구동되는 In-Proc 세션 정보는 모두 초기화된다. 웹사이트에서 뭔가를 구매하려는 사용자가 있었다면 큰 사고로 이어질 수 있지만, Session State Service에 세션 정보가 저장이 되므로 IIS 재시작 후에도 웹 응용 프로그램은 세션 정보를 모두 안전하게 유지할 수 있다.

보통 웹 서버와 Session State Service간에 통신을 하기 위해 방화벽의 특정 포트를 개방해야 하고, 내부적으로 서로 간에 소켓 통신에 사용되는 전용 프로토콜이 존재하므로 Session State Service를 확장하기란 쉽지 않을 것이다.

이런 경우, ASP.NET에서 MS SQL Server를 이용하여 세션 정보를 저장하는 방법을 제공해 준다. 세션 정보에 추가하고 싶은 정보나 DB상에 기록되어질 특정 필드를 추가하여 사용할 수 있고, Oracle 또는 MySQL을 사용하여 세션 상태를 저장할 수도 있다.

위의 링크 중 ‘[실전 ASP.NET Session [4] - 세션상태 마이그레이션]13’에 예제로 구현된 Oracle Session Store Provider 예제가 있으니 참고하길 바란다.

memcached를 이용하는 세션 저장소

memcached를 세션 저장소로 이용하는 것은 ASP.NET Session State Services의 역할과 구현만 다를 뿐이지 매우 유사하다. memcached도 메모리를 저장소로 이용하여 빠르게 캐시하고 요청에 빠르게 응답할 수 있는 간결한 구조로 구현된 오픈소스이다.

특히 memcached를 이용할 경우 ASP.NET Session State Services로 불가능한 클러스트링이 가능하기 때문에 수평적으로 세션 서버를 확장할 수 있다. 한 대의 세션 서버만 있는 경우보다 로드벨런싱의 자유도가 더 높고, 세션 서버의 장애에도 대처가 가능하다. 또 하나의 장점이라면 저가형 장비를 병렬로 구성이 가능하기 때문에 세션 서버를 구성하기 위한 금전적이거나 물리적인 많은 제약이 사라지게 된다.

memcached와 redis, 두 가지 오픈소스를 고려하고 있었는데, 세션 서버에 memcached가 더 적합하다고 생각하여 memcached만 다룬다. memcached의 소스 코드가 더 가볍고 취향이나 요구사항에 따라 코드를 변형하기에 더 적합하지 않을까 생각한다. 그리고 자칫 복잡해질 수 있는 구조적인 아키텍처를 좀 더 간결한 memcached로 표현하는 것이 글을 보는 입장이나 쓰는 입장에서 편하다고 믿는다.

memcached는 C언어로 구현이 되어있고, GNU C 표준 라이브러리를 사용하므로 여러 운영체제에서 사용이 가능하다. (ASP.NET Session State Services는 윈도우 환경에서만 사용이 가능하다) 물론 필자는 맥킨토시, 리눅스, 윈도우에서 memcached를 컴파일, 구동이 잘 됨을 확인하였다.

간단하게 사용자의 세션 정보를 저장할 클래스를 하나 간단하게 만들었다. 외부에서는 오직 참조만 하여 사용할 수 있도록 internal 생성 메서드를 하나 가지고 있다.


다음은 ASP.NET MVC 프로젝트로 만든 간단한 예제이다.

web.config
1
2
3
4
5
6
<sessionState mode="Custom" customProvider="MemcachedSessionStateStore">
    <providers>
        <add name="MemcachedSessionStateStore"
             type="Umc.Core.Web.SessionState.Memcached.MemcachedSessionStateStore, Web.SessionState.Memcached, Version=1.0.0.0, PublicKeyToken=eed8f2bc3bfc4c7a, Culture=neutral"/>
    </providers>
</sessionState>

  

HomeController.cs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class HomeController : Controller   
{
   private static readonly string KEY_OF_USER_SESSION = "__USER_SESSION_KEY__";
   public UserIdentity SessionStore
    {
        get { return (Session[KEY_OF_USER_SESSION] as UserIdentity) ?? UserIdentity.Empty; }
        set { Session[KEY_OF_USER_SESSION] = value; }
    }
 
 
    public ActionResult Index()
    {
        Session[KEY_OF_USER_SESSION] = UserIdentity.New("POWERUMC"
                                                        , "Junil, Um"
                                                        , "powerumc at gmail.com");
 
 
         /*
          // 맴버쉽 사용자 인증 설정 생략...
        var ticket = new FormsAuthenticationTicket(...);
        var user = new GenericPrincipal(new FormsIdentity(ticket), ... )
         * */
 
 
        return View();
    }
}

 

위와 같이 클라이언트의 세션 키를 이용하여 memcached의 서버에 세션 키를 이용하여 세션 값을 저장한다.

telnet 'get' 명령 결과
MPOWERUMC:~ powerumc$ telnet 192.168.0.23 11211
Trying 192.168.0.23...
Connected to 192.168.0.23.
Escape character is '^]'.
get laaymm13uyu03bofhdydi4iq
VALUE laaymm13uyu03bofhdydi4iq 0 477
AAEAAAD/////AQAAAAAAAAAMAgAAAF1XZWIuU2Vzc2lvblN0YXRlLk1lbWNhY2hlZCwgVmVyc2lvbj0xLjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWVlZDhmMmJjM2JmYzRjN2EFAQAAAEpVbWMuQ29yZS5XZWIuU2Vzc2lvblN0YXRlLk1lbWNhY2hlZC5NZW1jYWNoZWRTZXNzaW9uU3RhdGVTdG9yZStTZXNzaW9uRGF0YQQAAAATPElkPmtfX0JhY2tpbmdGaWVsZBg8TG9ja0FnZT5rX19CYWNraW5nRmllbGQYPEV4ZmlyZXM+a19fQmFja2luZ0ZpZWxkFzxMb2NrSWQ+a19fQmFja2luZ0ZpZWxkAQAAAgwNAgAAAAYDAAAAGGxhYXltbTEzdXl1MDNib2ZoZHlkaTRpcQC8oGUBAAAAAPAWAzAi0IgJAwAAAAs=
END

 

 

ASP.NET의 세션이 실제로 저장이 되었는지 확인해보자. telnet을 통해 memcached 포로토콜의 명령을 입력하여 확인하면 된다.

현재 브라우저에서 연 세션 값은 쿠기에 저장이 되어 있다. 쿠키에 저장된 세션의 키 값은 ‘laaymm13uyu03bofhdydi4iq’ 이다.


telnet에 접속하여 memcached에 저장된 세션 키의 값을 조회된다.

memcached 세션 저장소로써 활용

memcached 오픈 소스 솔루션을 이용하여 메모리 캐시를 이용하여 ASP.NET 세션 상태를 저장할 수 있도록 구성해 보았다. 이제 얼마나 좋은 성능을 낼 수 있는지 측정이 필요한데 본 아티클에서는 memcached를 세션 서버로 활용할 때에 대한 성능의 문제는 다음에 기회가 되면 더 심도있게 다루어 보도록 하겠다.

그리고 ASP.NET 뿐만 아니라, JSP 또는 Servlet, 그 외에 여러 웹 개발 프레임워크에서 쉽게 사용할 수 있다. memcached는 C#, Java, Python 등 여러가지 언어로 memcached서버에 연결할 수 있는 클라이언트 라이브러리를 어렵지 않게 찾을 수 있다.

이번 아티클에서는 MemcachedSessionStoreProvider 소스 코드를 제공하지 않았다. 물론, 필자의 위 코드를 실행하기 위해 MemcachedSessionStoreProvider 소스 코드가 있어야 한다. 이 코드는 다음 아티클에서 조금씩 작성해 나갈 예정이다.

memcached 에 대한 자세한 내용은 아래 링크의 구글 코드에 들어가면 컴파일 및 실행 방법과 유지관리 방법에 대한 위키가 있다.

memcached wiki, https://code.google.com/p/memcached/wiki/NewStart



[1]: C언어로 구현된 고성능 분산 메모리 객체를 캐시하는 서버. Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.

[2]: 키/값을 저장할 수 있는 분산 서버로 데이터의 구조체 뿐만 아니라 문자열, lists, 빠른 검색을 위한 hashes 등을 지원. Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain stringshasheslistssets and sorted sets.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

최근 2년 동안 다양한 개발 분야의 기술들이 물망에 오르는 굉장히 뜻 깊은 해였습니다. 2년 전이면 Microsoft 강성재 차장과 함께 처음으로 "Visual Studio 한국 공식 팀"을 창설하면서 http://vsts2010.net 이 탄생한 시기이군요. 2008년 12월에 팀이 창설되고, 2009년 1월 5일이 팀 블로그 2주년이 되는 날이었군요.

바로 저희 "Visual Studio 한국 공식 팀" 블로그에서 한홀 한홀 정성스럽게 작성된 포스트들이 2년 여간의 기술 흐름을 대변해 주고 있으며, 그리고 2011년의 기술도 짐작해 볼 수 있는 짧지만 굵은 변화의 흐름과 함께 여기까지 온 것 같습니다.

우리 팀이 함께 해왔던 핵심 키워드의 태그는 무엇이었을까요?

  • Visual Studio 2010
  • .NET 4.0, .NET Framework 4.0
  • ASP.NET MVC
  • C# 4.0
  • C++0x, C++/CLI
  • Parallel Computing
  • WCF
  • Cloud
  • Application Lifecycle Management

   

그리고 위의 태그들에 대해 더 자세히 살펴보더라도 생소한 기술과 이름, 아키텍처, 환경 등이 2년 동안 격변을 일으키며 변화를 해왔다는 사실입니다.

2011년 이전까지는 여러분들에게 선택권이었던 것들이, 이제는 필수가 되어야 한다고 해도 과언이 아닐 겁니다. 비즈니스 요구사항의 단면을 보면 업무적인 요인, 시대적인 배경 등인데, 이 시대적인 배경에는 트랜드+시장+기술+… 이 있을테고요. 그리고 '우리가 이 시대적인 배경 중 '기술'에 한 배를 타고 흐르고 있는가…?' 에 다시 한번 생각해 볼만 합니다.

예전 2010년 6월 1일 REMIX10 세미나에서 여러분에게 말씀 드린 마지막 문구가 다시금 생각이 나네요.

http://www.techdays.co.kr/2010spring/remix10/session3_1.html

   

여러분의 생존전력은 바로 아래에 해답이 있습니다. 여러분들에게 필요한 것, 그리고 그 가능성이 있다고 판단하시면 2011년 생존을 위하여 달려보는 것은 매우 멋진 2011년 한 해가 될 것입니다.

   

.NET 프레임워크

.NET Framework .NET 의 과거와 현재, 그리고 미래
.NET Framework .NET Framework 4.0 의 특징
.NET Framework .NET Framework 4.0 마이그레이션 이슈
.NET Framework .NET 스마트클라이언트 한계 극복 [1]
.NET Framework .NET 스마트클라이언트 한계 극복 [2]
CLR 1. Hello 世界
CLR 2. CLR! CLR! CLR!
CLR 3. MSCorLib & Metadata
CLR 4. Assembly
CLR 5. Assembly - Strongly named assemblies
CLR 6. Assembly - GAC(Global Assembly Cache)
CLR 7. System.Object
CLR 8. System.Object (2)
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 1.
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 2-1.
CLR 닷넷4.0에서 네이티브코드와 매나지드코드의 동거 part 2-2. 네이티브 랩퍼 만들기
Managed Extensibility Framework [MEF] 1. Managed Extensibility Framework 이란?
Managed Extensibility Framework [MEF] 2. Parts 와 Contracts 선언
Managed Extensibility Framework [MEF] 3. Export 선언
Managed Extensibility Framework [MEF] 4. Import 선언
Managed Extensibility Framework [MEF] 5. Catalog 사용
Managed Extensibility Framework [MEF] 6. Lazy Exports
Managed Extensibility Framework [MEF] 7. Exports and Metadata
Managed Extensibility Framework [MEF] 8. Strongly Typed Metadata
Managed Extensibility Framework [MEF] 9. Recomposition
Managed Extensibility Framework [MEF] 10. Querying the CompositionContainer
Managed Extensibility Framework MEF Preview 6 공개
Managed Extensibility Framework MEF 는 Generic Type 을 지원하지 않는다!
Managed Extensibility Framework MEF 에 Generic Type 을 지원하기 위해서..?
Managed Extensibility Framework MEFGeneric 코드 플랙스에 공개합니다.

   

애자일 개발

Agile Development [Better Code]TDD의 개념이 완벽히 녹아 들어간 VSTS 2010
Agile Development [Better Code]Visual Studio 2010 Code Analysis Enhancements - 1.개요
Agile Development [Better Code]Visual Studio 2010 Code Analysis Enhancements - 2. Rule Sets Feature
Agile Development [Better Code]PEX, Automated Whitebox Testing for .NET - 1. 개요
Agile Development [Better Code]Visualize Code Relationships
Agile Development [Testing] TDD (Test-Driven Development-테스트 주도 개발)
Agile Development [Testing] BDD (Behavior-Driven Development?행위 주도 개발)
Agile Development [Testing] Moq.NET (T/B Driven Development)
Agile Development [Better Code]Visual Studio Code Analysis Enhancements - 3. Data Flow Rules and Phoenix Engine
Agile Development 애자일에 대한 고찰
Agile Development [ALM-Test] 1. 왜 단위 테스트를 해야 하는가?
Agile Development [ALM-Test] 2. 한국적인 애자일 모델의 필요성
Agile Development [협업 1] 협업 도구의 통일성과 협업 인프라 관리
Agile Development [ALM-Test] 3. 테스터에 대한 오해와 진실
Agile Development [ALM-Test] 4. 테스터(SDET) 의 역할
Agile Development [ALM-Test] 5. 테스트 계획
Agile Development [ALM-Test] 6. Load Runner vs Visual Studio 2010 테스팅 비교 분석 - http://willstory.tistory.com/4 제공
Agile Development [ALM-Test] 7. TDD vs 계약기반 테스트
Architect Development Architect Development ?
Architect Development 몽당연필과 함께하는 VSTS 2010 모델링 0/4
Architect Development 몽당연필과 함께 하는 VSTS 2010 모델링 1/4
Architect Development Windows Server AppFabric - Velocity 란?
Architect Development WCF=SOA 에 대한 고찰

   

ASP.NET 4.0

ASP.NET 4.0 [ASP.NET 4.0] 1. Core Service - Extensible Output Caching
ASP.NET 4.0 [ASP.NET 4.0] 2. AJAX - Declarative Client Template Rendering
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Dynamic Data(1)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Dynamic Data(2)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Designer & Deployment
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Core Services
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - New Features in the Microsoft Ajax Library
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(1)
ASP.NET 4.0 Razor in WebMatrix
ASP.NET 4.0 Razor in WebMatrix(2) 코드의 재 사용
ASP.NET 4.0 Razor in WebMatrix(3) ? WebMatrix Helper
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(2)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(3)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(4)
ASP.NET 4.0 ASP.NET 4 와 Visual Studio 2010 Web Development Beta 2 Overview - Web Forms(5)
ASP.NET MVC M, V 그리고 C의 각방생활(1) - ASP.NET MVC vs ASP.NET WEB FORM
ASP.NET MVC M, V 그리고 C의 각방생활(2) - ASP.NET MVC와 인사나누기
ASP.NET MVC M, V 그리고 C의 각방생활(3) - 초간단 사이트 만들기(1)
ASP.NET MVC M, V 그리고 C의 각방생활(4) - 유효성 검사
ASP.NET MVC M, V 그리고 C의 각방생활(5) - 초간단 사이트 만들기(2)
ASP.NET MVC M, V 그리고 C의 각방생활(6) - 유효성 검사(2)
ASP.NET MVC M, V 그리고 C의 각방생활(7) - 함께 즐겨요~ jQuery
ASP.NET MVC M, V 그리고 C의 각방생활(8) - jQuery와 탭메뉴 그리고 파샬뷰
ASP.NET MVC M, V 그리고 C의 각방생활(9) - jqGrid 사용해보자
ASP.NET MVC M, V 그리고 C의 각방생활(10) - jqGrid를 이용한 paging과 sorting
ASP.NET MVC ASP.NET MVC 3 Preview 1 이 릴리즈 되었습니다.
ASP.NET MVC M, V 그리고 C의 각방생활(11) - jqGrid로 데이터 추가,편집,삭제해보기
ASP.NET MVC M, V 그리고 C의 각방생활(12) - 테스팅 그거, 아무나 하나?
ASP.NET MVC JailBreak From Controllers and Actions
ASP.NET MVC VSTS2010 에서 Razor 코드 하이라이팅 지원하기

   

C# 4.0

C# [C# 4.0] Named and Optional Parameters
C# [C# 4.0] Duck Typing
C# [C# 4.0] New Extension Method "Zip"
C# [C# 4.0] Generic Covariance And Contra Variance
C# Welcome to Dynamic C#(1) - 첫만남.
C# Welcome to Dynamic C#(2) - Wanna be a polyglot.
C# Welcome to Dynamic C#(3) - 마음이 넒어진 C#
C# Welcome to Dynamic C#(4) - 극과극 비교체험.
C# Welcome to Dynamic C#(5) - Return to Dynamic.
C# Welcome to Dynamic C#(6) - Return to Dynamic (2)
C# Welcome to Dynamic C#(7) - 아낌없이 표현해 주는 나무
C# Welcome to Dynamic C#(8) - DLR이 나무를 사랑하는 이유
C# Welcome to dynamic C# 외전(1) - Generate From Usage.
C# Welcome to dynamic C# 외전(2) - Generic Method.
C# Welcome to dynamic C# 외전(3) - 감시하는 자와 감시당하는 자.
C# Welcome to Dynamic C#(9) - Dynamic Returns Again.
C# Welcome to Dynamic C#(10) - Dynamic Returns Again.(2)
C# Welcome to Dynamic C#(11) - The Phantom of The Dynamic
C# Welcome to Dynamic C#(12) - dynamic은 외로운 아이.
C# Welcome to Dynamic C#(13) - 아직도 가야할 길.
C# Welcome to Dynamic C#(14) - 철지난 만우절에 낚여서 파닥파닥.
C# Welcome to Dynamic C#(15) - A/S for dynamic.
C# Welcome to Dynamic C#(16) - dynamic이라도 이건 안되는 거임.
C# Welcome to Dynamic C#(17) - 필요한 말만 하고 삽시다.
C# Welcome to Dynamic C#(18) - 이름을 붙이면서 벌어진 일들.
C# Welcome to Dynamic C#(19) - 위너 고르기.
C# Welcome to Dynamic C#(20) - 어르신과 대화하는 법.
C# Welcome to Dynamic C#(21) - 인덱스의 힘.
C# Welcome to Asynchronous C#(0) - C#의 전설.
C# Parallel Programming [C# 4.0] Parallel Extension - [1] 병렬 처리
C# Parallel Programming [C# 4.0] Parallel Extension - [2] 병렬 처리 아키텍처
C# Parallel Programming [C# 4.0] Parallel Extension - [3] TPL(Task Parallel Library)
C# Parallel Programming Welcome to Parellel world(1) - Here comes a new challenger!
C# Parallel Programming Welcome to Parallel C#(1) - 굿바이, 그리고 안녕~~?
C# Parallel Programming Welcome to Parallel C#(2) - 계속 되는 개념 찾기.
C# Parallel Programming Welcome to Parallel C#(3) - 작업의 기본.
C# Parallel Programming Welcome to Parallel C#(4) - 작업의 기본 Part 2.
C# Parallel Programming Welcome to Parallel C#(5) - 병렬작업에서 예외가 생기면 어케...?
C# Parallel Programming Welcome to Parallel C#(6) - To be continue...
C# Parallel Programming Welcome to Parallel C#(7) - Excuse me.
C# Parallel Programming Welcome to Parallel C#(8) - 취소 쉽게 하기.
C# Parallel Programming Welcome to Parallel C#(9) - 백지장은 맞들지 말엉.
C# Parallel Programming Welcome to Parallel C#(10) - 이보게, 잠깐 뒤를 돌아보지 않겠나.

   

C++/CLI

C++/CLI C++/CLI는 미운 오리새끼 or 백조
C++/CLI .NET에서의 C++/CLI의 의미
C++/CLI [Step 01] 'C++/CLI가 뭐야?'에 답하기 && 가장 많은 프로그래밍 언어로 만드는 프로그램 만들기
C++/CLI [Step 02-1] 클래스(class), 핸들(^), 그리고 구조체(struct)
C++/CLI [Step.02-2] 클래스(class), 핸들(^), 그리고 구조체(struct)
C++/CLI [step.03] 배열
C++/CLI [Step. 04] nullptr, interior_ptr, pin_ptr
C++/CLI [Step. 05] 관리 코드의 array를 비관리 코드에 포인터로 전달
C++/CLI [Step. 06-1] 관리코드의 문자열과 비관리코드의 문자열 변환
C++/CLI [Step. 06-2] 관리코드의 문자열과 비관리코드의 문자열 변환
C++/CLI [Step. 07] 비관리 클래스에서 관리 클래스를 멤버로, 관리 클래스에서 비관리 클래스를 멤버로
C++/CLI [Step. 08] 프로퍼티 ( property )
C++/CLI [Step. 09] 델리게이트 (delegate)
C++/CLI [Step. 10] 이벤트 ( event )
C++/CLI [Step. 11] 열거형( enum )
C++/CLI [Step. 12] for each
C++/CLI [Step. 13] parameter array
C++/CLI [Step. 15] static 생성자, initonly, literal
C++/CLI [Step. 14] 인터페이스 ( interface )
C++/CLI [Step. 16] array 클래스에 non-CLI 오브젝트 사용
C++/CLI [Step. 17] 델리게이트에 비관리 함수를 할당하기 그리고 다음 예고
C++/CLI [Step. 18] 순수 가상 함수
C++/CLI [Step. 19] char* -> 관리코드, 관리코드 -> char*
C++/CLI [Step. 20] 닷넷에서 HalfNetwork를 사용하자 - 1
C++/CLI [Step. 21] 닷넷에서 HalfNetwork를 사용하자 - 2
C++/CLI [Step. 22] 닷넷에서 HalfNetwork를 사용하자 ? 3
C++/CLI [Step. 23] 닷넷에서 HalfNetwork를 사용하자 ? 4
C++/CLI [Step. 24] 닷넷에서 HalfNetwork를 사용하자 ? 5
C++/CLI [Step. 25] 닷넷에서 HalfNetwork를 사용하자 ? 6(마지막)

   

C++0x

C++0x [VC++] 1. 큰 변화가 기대되는 Visual C++( VC++ )
C++0x [VC++] 2. C++0x의 auto
C++0x [VC++] 3. static_assert
C++0x [VC++] 4. 우측 값 참조( RValue Reference ) - 첫 번째
C++0x [VC++] 5. 우측 값 참조( RValue Reference ) ? 두 번째
C++0x [VC++] 6. 우측 값 참조( RValue Reference ) - 세 번째
C++0x [VC++] 7. 우측 값 참조( RValue Reference ) - 네 번째
C++0x [VC++] 8. 우측 값 참조( RValue Reference ) ? 다섯 번째
C++0x [VC++] 9. Lambda ( 람다 ) - 첫 번째
C++0x [VC++] 11. Lambda - 두 번째
C++0x [VC++] 12. Lambda - 세 번째
C++0x [VC++] 13. Lambda - 네 번째
C++0x [VC++] 14. decltype
C++0x 대용량 파일 조작을 위한 C++0x의 변화
C++0x nullptr
C++0x VC++ 10에 구현된 C++0x의 코어 언어 기능들
C++0x C++0x 관련 책 "Visual C++ 10과 C++0x"
C++0x "Visual C++ 10과 C++0x" pdf 파일
C++0x [Plus C++0x] 람다(Lambda) 이야기 (1)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (2)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (3)
C++0x [Plus C++0x] 람다(Lambda) 이야기 (마지막회)
C++0x [STL] 1. What's new in VC++ 2010?
C++0x [STL] 2. unique_ptr (1/2)
C++0x [STL] 3. unique_ptr (2/2)
C++0x [STL] 4. make_shared
C++0x [STL] 5. 에 추가된 새로운 함수들 (1/5)
C++0x [STL] 6. 에 추가된 새로운 함수들 all_of, any_of, none_of (2/5)
C++0x VS2010에서 nullptr의 알려진 버그
C++0x RValue Reference에 의한 STL의 성능향상 테스트
C++0x [STL] 7. 에 추가된 새로운 함수들 copy_if, copy_n, find_if_not (3/5)
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [0]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [1]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [2]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [3]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [4]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [5]
VC++ 10 Concurrency Runtime C++ 개발자를 위한 병렬 프로그래밍 동영상 [6/7] 완결!
VC++ 10 Concurrency Runtime PPL task를 이용한 피보나치 수 계산
VC++ 10 Concurrency Runtime 인사 및 Multi Core, Multi Thread...그리고 VC++ 10
VC++ 10 Concurrency Runtime Concurrency Runtime
VC++ 10 Concurrency Runtime Parallel Patterns Library (PPL)
VC++ 10 Concurrency Runtime 양보할 줄 아는 Concurrency Runtime의 event
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - Task
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - 병렬 알고리즘
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_for 알고리즘
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_for_each 알고리즘
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - parallel_invoke
VC++ 10 Concurrency Runtime Asynchronous Agents Library로 Dining Philosophers 문제 해결하기 - 마지막회
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - combinable
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - task group에서의 병렬 작업 취소 - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - task group에서의 병렬 작업 취소 - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_vector - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_vector - 2
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_queue - 1
VC++ 10 Concurrency Runtime Parallel Patterns Library(PPL) - concurrent_queue - 2
VC++ 10 Concurrency Runtime Concurrency Runtime(ConcRT)의 디버그 모드에서 메모리 leak 문제
VC++ 10 Concurrency Runtime Asynchronous Agents Library 소개
VC++ 10 Concurrency Runtime Asynchronous Agents Library - agent. 1 ( 상태 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? agent. 2 ( 기능 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library - message 전달 함수. 1 ( 전송 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message 전달 함수. 2 ( 수신 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 1. ( 인터페이스 )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 2. ( unbounded_buffer )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 3. ( overwrite_buffer & single_assignment )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 4. ( call )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 5. ( transformer )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 6. ( choice )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 7. ( join & multitype_join )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 8. ( timer )
VC++ 10 Concurrency Runtime Concurrency Runtime ? 동기화 객체 1. ( critical_section & reader_writer_lock )
VC++ 10 Concurrency Runtime Concurrency Runtime ? 동기화 객체 2. ( event )
VC++ 10 Concurrency Runtime Asynchronous Agents Library ? message block 9. ( custom )
VC++ 10 Concurrency Runtime Concurrency Runtime - 만델브로트 프랙탈 ( Mandelbrot Fractal ) 예제
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 1. ( Scheduler )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 2. ( SchedulerPolicy )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 3. ( ScheduleGroup )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 4. ( ScheduleTask )
VC++ 10 Concurrency Runtime Concurrency Runtime ? Task Scheduler 5. ( Context blocking )
Visual C++ 10 About Visual C++ 10
Visual C++ 10 디버깅 모드에서 역어셈블리 코드 보기
Visual C++ 10 Visual C++ 10의 변화
Visual C++ 10 [Upgrade to VC++ 10] _WIN32_WINNT 버전 문제
Visual C++ 10 VS2010 C++ 프로젝트의 디렉토리 설정

   

클라우드 컴퓨팅

Cloud 구름 속의 미래 : Windows® Azure™ Platform [1]
Cloud SQL Azure - CTP1
Cloud SQL Azure 알아보기 (1) - 데이터베이스 개체 생성
Cloud SQL Azure 알아보기(2) ? 데이터베이스 스키마 마이그레이션, 데이터 전송
Cloud 구름 속의 미래 : Windows® Azure™ Platform [2]
Cloud SQL Azure 사용 시 주의점(1) - 방화벽 설정
Cloud SQL Azure 알아보기(3) ?SQL Server 2008 R2 Nov CTP
Cloud SQL Azure 알아보기(4) ? SQL Azure Cloud App
Cloud SQL Azure 알아보기 (5)- SQL Azure 이점과 T-SQL 지원
Cloud [MS@클라우드컨퍼런스] MS 클라우드 기술과 플랫폼
Cloud 클라우드 기반 분산 컴퓨팅을 위한 AppFabric (1) : 아하! App 분산!
Cloud Hello Windows Azure / Windows Azure Platform의 이해
Cloud Hello Windows Azure / Gallery of 'Powered by Windows Azure Platform'
Cloud Hello Windows Azure / Windows Azure 개발 환경의 구축
Cloud Hello Windows Azure / Understanding Windows Azure Development Process
Cloud Hello Windows Azure / Windows Azure Tools for Visual Studio 1.2 출시
Cloud Hello Windows Azure / Windows Azure Platform 최신 소식 업데이트 (종합) [수정]
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #1
Cloud Windows Azure Update: Microsoft Project Code-Named "Houston" CTP 1
Cloud SQL Azure와 Excel 2010의 PowerPivot
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #2
Cloud Windows Azure Update: CloudStorageAccount 클래스 사용 시 주의 사항
Cloud SQL Azure Update: Dynamic Management View
Cloud Hello Windows Azure / Twitter 스타일 방명록 만들기 #3
Cloud Windows Azure Update: myAzureStorage
Cloud SQL Azure 와 SQL Reporting Service
Cloud Windows Azure Update: Windows Azure CDN의 활용
Cloud [작업 중] Windows Azure Update: Adaptive Smooth Streaming with Windows Azure Storage

   

게임 개발

Direct3d Mobile [d3dm 기초] 1. wm6.x 개발환경 세팅
Direct3d Mobile .NET 기반에서 공개소스 게임엔진 포팅하기
DirectX 11 [JumpToDX11-1] 사라진 Direct3D 오브젝트를 찾아서...
DirectX 11 [JumpToDX11-2]DeviceContext...넌 누구냣!!
DirectX 11 [JumpToDX11-3] Feature Level
DirectX 11 [JumpToDX11-4] ID3D11View
DirectX 11 [DX11_#1]D3D Buffer( 1 / 2 )
DirectX 11 [DX11_#2]D3D Buffer( 2 / 2 )
DirectX 11 [DX11_#3]기본적인 설정
DirectX 11 [JumpToDX11-5] 새로운 시대를 여는 DirectX11...
DirectX 11 [JumpToDX11-6] 커맨드(Command)...
DirectX 11 [DX11_#4]텍스트, 버튼 출력
DirectX 11 [JumpToDX11-7] 간편해진 리소스 처리.
DirectX 11 [JumpToDX11-8] Deferred Contexts
DirectX 11 [JumpToDX11-9] Multi-threaded Rendering 을 위한 API.
DirectX 11 [JumpToDX11-10] GPGPU 를 위한 DirectCompute.
DirectX 11 [JumpToDX11-11] DirectCompute 를 위한 한걸음!
DirectX 11 [JumpToDX11-12] DirectCompute 의 절차.
DirectX 11 [JumpToDX11-13] Tessellation 등장.
DirectX 11 [DX11_#5]DirectX11의 활용 사례(1/3)
DirectX 11 [JumpToDX11-14] DirectX9 세대의 테셀레이션( ID3DXPatchMesh 편 )
DirectX 11 [JumpToDX11-15] DirectX9 세대의 테셀레이션( IDirect3DDevice9::DrawXXXPatch편 )
DirectX 11 [알콜코더의 미리 배워보는 DirectX 11 - 입문편] 0. 누구를 위한 연재인가
DirectX 11 [알콜코더의 미리 배워보는 DirectX11-입문편] 1.튜터리얼 01 : 다이렉트 3D 기초 #1
DirectX 11 [알콜코더의 미리 배워보는 DirectX11-입문편] 1.튜터리얼 01 : 다이렉트 3D 기초 #2
DirectX 11 [JumpToDX11-16] DirectX9 세대의 테셀레이션( D3DXTessellateNPatches편 )
DirectX 11 [알콜코더의 미리 배워보는 DX11 ? 입문편] DX11에서 무엇이 추가되었나?
DirectX 11 [JumpToDX11-17] DirectX9 세대의 테셀레이션( ATI 라이브러리편 )
DirectX 11 [발표자료] 예제로 느껴보는 다이렉트X 11의 매력
DirectX 11 [JumpToDX11-18] DirectX11의 테셀레이션 ( 테셀레이션을 위한 하드웨어의 등장편 )
DirectX 11 [알콜코더의 미리 배워보는DX11 입문편] DirectX 11의 특징들
DirectX 11 [알콜코더의 미리배워보는 DX11-입문편] 1. 튜터리얼01 : 디바이스와 스왑체인의 생성

   

F#

F# Welcome to F#(1) - 첫만남.
F# Welcome to F#(2) - 두번째 만남.
F# Welcome to F#(3) - 사소한 탐색전.
F# Welcome to F#(4) - 과거와 배경을 좀 더 알고싶어.
F# Welcome to F#(5) - 아주 조금씩 심화되는 탐색전.
F# Welcome to F#(6) - 비교본능.
F# Welcome to F#(7) - 클리프 행어.
F# Welcome to F#(8) - 은총알과 엄친아.
F# Welcome to F#(9) - 메이져 데뷰.
F# Welcome to F#(10) - 인도음식 카레.....?
F# Welcome to F#(11) - 차별을 권장하는 언어인거임?!?!
F# Welcome to F#(12) - 공동작업 좋치아니항가

   

MFC

MFC [MFC] 리스타트 매니저(Restart Manager) - (1/3) : 기능 소개
MFC [MFC] 리스타트 매니저(Restart Manager) - (2/3) : 사용하기
MFC [MFC] 리스타트 매니저(Restart Manager) - (3/3) : 활용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - (1/3) : 기능 소개
MFC [MFC] 태스크 대화상자(Task Dialog) - (2/3) : 사용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - (3/3) : 활용하기
MFC [MFC] 태스크 대화상자(Task Dialog) - 예제 코드 올립니다.
MFC [MFC/윈도우 7 멀티터치] #2 : 제스처(gesture)를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #3 : 제스처(gesture)를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #4 : WM_TOUCH 메세지를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #5 : WM_TOUCH 메세지를 이용한 구현()
MFC [MFC/윈도우 7 멀티터치] #6 : 예제 코드 올립니다

   

RIA

RIA Expression Blend3 preview - 1.인터페이스
RIA Expression Blend3 preview - 2. Photoshop import
RIA Silverlight 3 & Blend 3 RC 공개!!!
RIA Silverlight 4 Beta 공개
RIA .Net Ria Service + IIS6 + Silverlight 4 Troubleshooting!!
RIA 실버라이트 비하인드 코드에서 바인딩하기.
RIA .Net Ria Service 와 Entities 그리고 Stored Procedure 하다가 생긴일..
RIA 실버라이트 프로그래머가 할 수 있는 최소한의 블랜드 디자이너를 위한 배려

   

SharePoint 2010

SharePoint 2010 Visual Studio 2010 에게 바란다 - SharePoint 14 Development
SharePoint 2010 SharePoint 2010 Overview
SharePoint 2010 SharePoint 2010 개발 환경 구성
SharePoint 2010 SharePoint 2010 개발 환경- Hello World 웹 파트 생성 및 배포하기
SharePoint 2010 SharePoint 2010 Web Part 생성
SharePoint 2010 SharePoint 2010 Visual Web Part
SharePoint 2010 SharePoint 2010 Feature
SharePoint 2010 SharePoint 2010 Event Receiver
SharePoint 2010 SharePoint 2010 데이터 기술
SharePoint 2010 SharePoint 2010 Server Object Model
SharePoint 2010 Visual Studio 2010 출시에 따른 SharePoint Developer Tools
SharePoint 2010 SharePoint 2010 LINQ to SharePoint
SharePoint 2010 Client Object Model - .NET
SharePoint 2010 Client Object Model ? Silverlight (1)
SharePoint 2010 Client Object Model ? Silverlight (2)
SharePoint 2010 Client Object Model - Javascript(1)
SharePoint 2010 Client Object Model - Javascript(2)
SharePoint 2010 Client Object Model ? 정리
SharePoint 2010 SharePoint 2010 개발환경 구축 가이드
SharePoint 2010 REST -.NET
SharePoint 2010 REST ? Silverlight
SharePoint 2010 REST - jQuery
SharePoint 2010 SharePoint 2010 프로젝트 디버깅
SharePoint 2010 SharePoint 2010 Developer Dashboard

   

Team Foundation Server

Team Foundation Server Visual Studio Team System 2010 (CTP10) - 작업 항목 링크
Team Foundation Server TFS 2010 설치 하기
Team Foundation Server TFS 2010 Build Service 설치
Team Foundation Server TFS 2010 설치 과정 중에 TF255040 문제
Team Foundation Server Visual Studio 2010을 활용한 ALM (1-5) - ALM 이란 무엇인가
Team Foundation Server Team Foundation 트러블 슈팅 가이드
Team Foundation Server Visual Studio Team Foundation Server 2010 를 설치해보자
Team Foundation Server Visual Studio Team Foundation Server 2010 설치 전 할일
Team Foundation Server VS TFS 2010 설치편 - 설치전 IIS, .NET 설치
Team Foundation Server VS TFS 2010 설치편 - 설치 시작
Team Foundation Server VS TFS 2010 구성편 - 설치 후 TFS 구성으로 점심 얻어먹기 편
Team Foundation Server VS TFS 2010 사용편 - SourceSafe? 버려~
Team Foundation Server [HowTo] Team Foundation Server 의 로컬 매핑 캐시 제거하기
Team Foundation Server [HowTo] SharePoint 2010 Beta 깨끗하게 제거하기
Team Foundation Server [HowTo] SCVMM 의 Install Virtual Guest Service 작업 중 2941 오류
Team Foundation Server [HowTo] TFS2010 의 Tfs_Analysis 웨어하우스 데이터베이스가 망가졌을 경우
Team Foundation Server [PPT] 테스트와 가상화의 만남 - 테스트 가상화(Lab Management)
Team Foundation Server Team Foundation Server 2010으로 업그레이드, 마이그레이션, 동기화
Team Foundation Server Visual Source Safe 사용자를 위한 TFS2010 시리즈

   

Visual Studio 2010

Visual Studio 2010 Visual Studio Team System 2010 CTP 만료 해결하기
Visual Studio 2010 Visual Studio 2010 의 특징
Visual Studio 2010 Visual Studio 2010 내부 빌드 최신 동영상: C# 4.0 Language + IDE + WPF Shell + Editor
Visual Studio 2010 Visual Studio 2010 & .NET 4.0 참고 자료들
Visual Studio 2010 Visual Studio 2010 Beta 1 설치부터 살펴보기
Visual Studio 2010 멀티 모니터 사용
Visual Studio 2010 Visual Studio 2010 Beta 2 출시
Visual Studio 2010 Visual Studio 2010 Beta 2 설치 미리 보기
Visual Studio 2010 VS 2010 Beta 2 설치 과정에서 Silverlight SDK 문제
Visual Studio 2010 VS2010 베타2의 WPF & Silverlight 디자이너 성능 향상 팁
Visual Studio 2010 VS 2010 기능 소개 01 인텔리 센스 기능의 변화
Visual Studio 2010 Visual Studio 2010과 Blend Preview for .NET 4 통합 문제
Visual Studio 2010 VS 2010 기능 소개 02 - IDE의 기능 추가
Visual Studio 2010 VS 2010 기능 소개 03 - IDE의 변화
Visual Studio 2010 Visual Studio 2010 출시 일정
Visual Studio 2010 VS 2010 기능소개 04 - Visual C#&VB 개발자 IDE Tips & Tricks 첫번째
Visual Studio 2010 VS 2010 기능소개 05 - Visual C#&VB 개발자 IDE Tips & Tricks 두번째
Visual Studio 2010 Visual Studio 2010 RC 공개 임박!
Visual Studio 2010 Visual Studio 2010 RC 공개
Visual Studio 2010 C#에서 IntelliSense가 동작하지 않을 때 문제 해결 방법
Visual Studio 2010 똑똑한 검색을 지원하는 VSTS 2010의 "Navigate To" 검색
Visual Studio 2010 실버라이트4 RC와 블렌드 4 베타 공개
Visual Studio 2010 윈도우폰 7 개발환경 공개
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (2회) - VS IDE
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (3회) - Box Selection
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (4회) - Call Hierarchy
Visual Studio 2010 Visual Studio 2010 출시와 완소 정보 총 정리
Visual Studio 2010 Visual Studio 2010 e-book 무료로 다운로드 하세요
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (5회) - Navigate To
Visual Studio 2010 Visual Studio 2010 RTM 추가 완소 정보
Visual Studio 2010 Visual Studio 2010! 나랑 놀아보자 ? 기본편 (6회) - Generate from Usage
Visual Studio 2010 VS 2010 기능소개 05 - Visual C#&VB 개발자 IDE Tips & Tricks 두번째
Visual Studio 2010 Visual Studio 2010, 2008, 2005 에서 .NET Framework 1.1 개발하기
Visual Studio 2010 Visual Studio 2010, 2008, 2005 에서 .NET Framework 1.1 개발하기
Visual Studio 2010 Just for fun! / Visual Studio Express Edition
Visual Studio 2010 왜 Visual Studio 2010 이여야 하는가?
Visual Studio 2010 Visual Studio 2010 최신 PDF 자료를 MSDN 에서 다운로드 받으세요
Visual Studio 2010 Just for fun! / DreamSpark는 대학생 여러분을 위한 솔루션입니다.
Visual Studio 2010 VS2008 을 VS2010 에서 동시에 개발하기
Visual Studio 2010 VS2008 과 VS2010 동시에 개발하기 : 테스트 프로젝트가 포함 될 경우
Visual Studio 2010 Introducing Visual Studio LightSwitch! - Enjoy your development
Visual Studio 2010 Visual Studio Hotfix List
Visual Studio 2010 곧 다가올 기술, Microsoft Research [1/2]
Visual Studio 2010 곧 다가올 기술, Microsoft Research [2/2]
Visual Studio 2010 Visual Studio 31 (1) - 시작, 그리고 Intellisense
Visual Studio 2010 Visual Studio 31 (2) - Startpage
Visual Studio 2010 Visual Studio 31 (3) - Temp Project
Visual Studio 2010 Visual Studio 31 (4.1) - Visual Studio 2010 Productivity Power Tools, Part 1
VIsual Studio Extensibility [Blueprints] S+S Blueprints
VIsual Studio Extensibility Visual Studio 2010 SDK 와 Readme
VIsual Studio Extensibility Visual Studio 2010 Extension Manager
VIsual Studio Extensibility [VSIX] 1. What is different from before version?
VIsual Studio Extensibility [VSIX] 2-1. How to start VSIX programming
VIsual Studio Extensibility [VSIX] 2-2. How to start VSIX programming
VIsual Studio Extensibility MousePresentationTracker - MEF 세미나 예제
VIsual Studio Extensibility [VSX] 1. Visual Studio Extensibility,, 그 시작
VIsual Studio Extensibility Visual Studio 2010 확장 모델인 VSIX 버그
VIsual Studio Extensibility VSGesture v2.0 for VS2010 is now available for download

   

우리 블로그 소식

VSTS 2010 팀 블로그 Visual Studio Team System 2010 공식 팀 블로그 맴버소개
VSTS 2010 팀 블로그 Visual Studio Team System 2010 팀 블로그 소개
VSTS 2010 팀 블로그 VSTS 2010 팀 블로그/스터디 맴버를 모집합니다.
VSTS 2010 팀 블로그 VSTS 2010 팀 맴버 지원을 마감합니다
VSTS 2010 팀 블로그 Visual Studio Team System 2010 Beta 1 공개
VSTS 2010 팀 블로그 [MSDN 주간 세미나] 발표자료 / .NET Framework와 Visual Studio : 현재와 미래 1, 2
VSTS 2010 팀 블로그 VSTS 2010 팀 3분기 맴버 모집
VSTS 2010 팀 블로그 VSTS 2010 팀 세미나 동영상 - 6월 10일
VSTS 2010 팀 블로그 VSTS 2010 팀 맴버 추가 모집
VSTS 2010 팀 블로그 VSTS 2010 팀 트위터를 오픈하였습니다.
VSTS 2010 팀 블로그 TECH DAY 2009 행사 오픈!!!
VSTS 2010 팀 블로그 VSTS 2010 공식 블로그 Viva 2010팀 멤버 추가 모집 공고
VSTS 2010 팀 블로그 [세미나] 차세대 응용 프로그램 구축 방법 및 사례 소개 세미나
VSTS 2010 팀 블로그 Visual Studio 2010 팀에서 팀원 모집합니다.
VSTS 2010 팀 블로그 한국 Visual Studio 2010 사용자를 위한 트위터 커뮤니케이션
VSTS 2010 팀 블로그 C++ 개발자와 함께하는 Visual Studio 2010
VSTS 2010 팀 블로그 [무료 세미나] ReMIX 10
VSTS 2010 팀 블로그 6월 1일, 대한민국 웹 컨퍼런스의 지존 ReMIX 10가 개최됩니다!
VSTS 2010 팀 블로그 REMIX10 의 VS2010 팀 후기
VSTS 2010 팀 블로그 6월 1일, REMIX10 세미나 세션 공개
VSTS 2010 팀 블로그 [세미나] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나 후기] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나 발표 자료] Visual Studio Camp #1
VSTS 2010 팀 블로그 [세미나] Visual Studio Seminar #1 / 2010년 9월 28일
VSTS 2010 팀 블로그 9월 13일에 개최하는 KGC에서 강연을 합니다.
VSTS 2010 팀 블로그 KGC10에서의 VS2010 스터디 팀의 활약 모습
VSTS 2010 팀 블로그 [VSKOREA] Visual Studio 2010 정보가 한 눈에…
VSTS 2010 팀 블로그 [세미나 후기] Visual Studio Seminar #1
VSTS 2010 팀 블로그 [세미나 발표 자료] Visual Studio Seminar #1
VSTS 2010 팀 블로그 [후기] C++ & 게임 개발자를 위한 개발 생산성 및 퍼포먼스 향상 전략 세미나

   

WCF

WCF WCF란 무엇인가?
WCF 기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기
WCF 기본 WCF 프로그래밍 - 첫 WCF 서비스 만들기 2
WCF WCF의 기본 - Service Contract
WCF WCF의 기본 - Data Contract
WCF WCF 서비스의 동시성(Concurrency) - 1
WCF WCF 서비스의 동시성(Concurrency) - 2
WCF WCF - Serialization
WCF WCF Hosting - WAS를 이용한 Hosting
WCF 도메인을 여러개 등록했을때 WCF 서비스를 호스팅 할수 없어요 ㅠㅠ
WCF WCF Hosting(2) - ASP.NET 호환성(Compatibility)
WCF WCF Hosting (3) - Windows Service를 이용한 Hosting
WCF WCF Security (1) - SSL을 이용한 전송계층에서의 보안 설정
WCF WCF Security (2) - 전송 계층에서의 메세지 인증 (사용자 지정 인증)
WCF WCF Troubleshooting (1)
WCF WCF Service Configuration Editor
WCF WCF Troubleshooting (2)

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 아크몬드 2011.01.11 00:15 Address Modify/Delete Reply

    대박이군요!

  2. 구조신호 2011.06.03 18:09 Address Modify/Delete Reply

    오 한곳에 다 모여있으니 좋네요~~~~!!!!
    감사합니다!!