.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

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

소프트웨어 테스트 후진국 "대한민국"

최근 여러 달 동안 블로그를 관리하지 않아 이렇게 다시 글을 올리는 것이 약간은 부담이 되네요. 거의 1년이나 방치해둔 제 블로그에 '어떤 글을 첫 번째 글로 올려야 하나?' 라는 기본적인 것부터 시작해서 앞으로 어떤 주제를 가지고 지속적으로 블로그를 해야 하는지도 말입니다. 이미 마음속으로는 "테스트"라는 소프트웨어 공학적인 주제를 가지고 첫 번째 글을 쓸 것이라고 마음은 먹었지만, 그 동안 느낀 많은 것들 또한 천천히 블로그로 포스팅 하리라 약속을 드립니다.

소프트웨어 테스트 후진국 "대한민국"

소프트웨어 개발 중 테스트는 소프트웨어 개발 라이프사이클의 중요한 과정 중으로 하나임을 전산과를 전공하였다면 이미 알고 있을 것입니다. 그 만큼 소프트웨어 개발 과정 중 "테스트" 단계는 일련의 모든 이전 단계, 즉 분석, 설계, 개발이라는 범위의 기나긴 여정의 과정을 검증하는 단계이고, 그리고 이 과정에서 상당한 분량을 지식을 얻을 수 있는 과정이 테스트 과정이기도 합니다.

필자가 현재 회사로 이직을 하고 약 1여 년간 소프트웨어 테스트라는 Sub Job을 맞게 되면서, 초기에 가볍게 시작한 테스트 활동이 이제는 어느 정도 정착된 소프트웨어 테스트 프로세스를 수립하게 되었고, 이것을 올바르게 판단할 수 있도록 데이터를 시각화하기 위한 다양한 시도를 해 보았습니다. 그리고 테스트를 대하는 우리들의 자세에 대해서도 매우 비판적인 요소들이 많지만, 즉 이것은 아무도 올바른 테스트를 시도하지 않았고 경험해 보지 못한 것이라는 반증이기도 합니다.

사실 우리나라에서는 "테스트"라는 용어가 피부에 와 닿게 된 시점이 바로 "애자일" 개발 프로세스(방법론이라고 칭하지 않음) 덕분에 여러 사람들의 입방아에 가장 자주 오른 용어이기도 합니다. "애자일 프렉티스", "애자일 소프트웨어", "애자일 개발" 이라는 일파만파적인 용어와 수식어 들이 생겨나면서 우리나라의 현실적인 소프트웨어 개발 생태계에서 "테스트"가 재조명 받는 시기가 바로 "애자일"의 영향이 매우 컸음을 의미합니다.

물론, 자사의 솔루션이나 소프트웨어를 전문적으로 개발하는 진정한 소프트웨어 개발 업체에서는 정직하고 잘 동작하는 소프트웨어를 출시하기 위해 테스트에 상당한 노력을 기울이고 있습니다. 높은 단가로 팔리는 소프트웨어에 결함이 있다는 것은 고객에게 매우 치명적이기 때문에 이들의 업체들은 소프트웨어 테스트 전문 인력을 확보하고 꾸준히 품질 유지를 위해 노력하고 있으니까요.

특히 20세기 후반부터 큰 규모의 소프트웨어 개발을 일컬어 "엔터프라이즈 급"의 제품이 개발되고 이것은 즉, 혼자서 잘 동작하는 소프트웨어가 아닌, 다른 시스템, 소프트웨어, 컴포넌트와 잘 동작해야 하는 이식성 때문에 압도적으로 비중 있게 다루는 것 또한 테스트 입니다.

엔터프라이즈 급의 소프트웨어는 상하수직 관계와 팀간의 범위 등이 잘 조직화가 잘 된 우리나라에서 특히 가장 높은 퍼포먼스를 보여주기도 합니다. (높은 퍼포먼스가 그에 걸 맞는 품질을 보장하는 것이 아님을 주의해 주세요) 그리고 테스트는 1단계에서 2,3 단계까지 체계적으로 이루어지기도 합니다. "단위 테스트", "기능 테스트", "통합 테스트"라는 폴더를 만들고 수십 가지 문서를 양산해내면 테스트 단계는 통과하게 되는 것이지요^^. 테스트 이후 단계에서 문제가 발생하면 유지보수 계약에서 추가적으로 지원하면 되니까요..;; (물론, 그 과정이 단순한 과정이 아닌 것도 잘 아는 바이지만…)

흔히 모든 사람들이 문제라는 것을 인지하고, 테스트가 중요하다는 공감대가 형성이 되어야 비로서 저와 함께 논의가 될 수 있으리라 생각합니다.

개발자가 아닌 돌팔이를 주도적으로 양산

일단 개발자의 정식 명식은 "소프트웨어 기술자" 입니다. 일반적으로 우리나라에서는 개발자의 등급을 분류하기를 다음과 같이 분류하는 것을 좋아합니다.

자세한 개발자 등급 기준은 다음의 링크를 참고 하세요 (http://career.sw.or.kr/hrdict/front/guide/renew/sub1-4_popup.jsp)

  • 초급 기능사 : 기능사 자격증을 취득한 자
  • 중급 기능사 : 기능사 자격 취득 3년 경과 및 산업기사 취득한 자
  • 고급 기능사 : 기사, 산업기사 취득하고 기사 취득 후 7년 경과한 자
  • 초급 기술사 : 기사 취득, 산업 기사 이상 취득, 지식경제부장관이 고시한 공인민간자격을 취득한 자
  • 중급 기술사 : 기사 취득 및 그 후 3년 업계 종사 …
  • 고급 기술사 : 중급 기술사 취득 후 3년 이상 업계 종사
  • 특급 기술사 : 고급 기술사 취득 후 3년 이상 업계 종사
  • 기술사 : 기술사

참 문제가 많은 등급 분류 제도이지요? 대충 밑바닥부터 특급 기술사가 되려면 어림잡아 20년은 넉넉히 업계에 종사해야 하고, 빨리 빨리 자격을 취득하는 것이 상책인 제도인 것 같습니다. 이것도 저것도 싫다면 몇 가지 제한이 있긴 하지만, 양반으로 승진하는 방법은 "기술사"가 유일한 방법이네요. 석사, 박사 과정을 이수하고 좀 놀다가 기술사를 따면 초고속으로 "기술사"로 승진할 수 도 있지요. 이런 등급 제도를 싸잡아 대략 4등급으로 나누면 "초급", "중급", "고급", "특급", 이렇게 네 부류의 개발자(사)로 나뉘어 지는데, Microsoft 제품과 Borland 제품을 가지고 논지 20년이 훌쩍 넘는 필자 또한 아직은 초급을 벗어날 수 없는 운명에 처해있네요.

저렇게 등급화한 것이 문제가 아니라, 닷컴 열풍으로 소프트웨어 개발자 양산을 주도한 정부로써 진정한 엔지니어를 양산하려는 시도가 아닌 "초급 기능사"를 너무 많이 양산한 것이 문제이고, 일단 현업으로 뛰어든 초급 기능사는 현실적으로 다음 등급을 넘기 위해 다시 학교로 돌아가는 것이 가장 빠른 방법인 것이 더욱 문제이고, 더욱 문제는 막 현업에 뛰어든 기능사 개발자들이 더 높은 고지로 갈 수 있는 문턱은 당시 이미 닫혀버렸다는 것이 가장 큰 문제입니다. 덕분에 수 많은 일자리를 창출하고 당시 청년 실업률이 낮은 편이었으며, 누구에게나 개발자의 길이 열려있었다는 것이 지금 현재의 개발자 구인난의 대표적인 정책 실패라고 봅니다. 정책만이 실패한 것이 아닙니다. 닷컴 열풍 이후 지금의 소프트웨어 생태계는 이미 파괴되어버렸고, 지속적인 정책이 뒷받침 되지 않아 많은 수의 개발자들이 소프트웨어 업계를 떠났습니다.

소프트웨어를 공부하려고 뛰어는 사람들이 아닌, 단지 특정 플랫폼과 개발 언어를 가르치면서, 그 시장이 원하는 플랫폼과 개발 언어의 문턱을 넘지 못하면 그대로 낙오될 수 밖에 없으니, 학원 문턱을 통해 현업에 종사할 수는 있어도, 잘 할 수 없는 반복적으로 순환되는 구조적인 문제점을 아직도 그 때의 문제들을 우리 현업 종사자들이 짊어지고 가고 있습니다.

3년 후, 5년 후, 10년 후, 20년 후 개발자의 미래

어떤 개발자가 좋은 개발자인가부터 시작해 봅시다. 10점 만점 중에 각 개발자에게 점수를 주어보았습니다.

  1. 개발자는 코딩을 잘 하면 좋은 개발자입니다. (1점 드립니다)
  2. 개발자가 코딩을 잘하는데 커뮤니케이션 스킬이 좋으면 좋은 개발자 입니다.(4점 드립니다)
  3. 개발자가 신기술에 거부반응 없이 잘 소화하면 좋은 개발자 입니다. (5점 드립니다)
  4. 문서화, 시각화 역량이 좋으면 더 없이 써 먹을 데가 많은 개발자 입니다 (SI에서 쓰는 문서 제외) (8점 드립니다)
  5. 부하직원을 잘 부리고 성격도 좋으면 금상 첨화 입니다 (10점 드립니다)

이것이 무언인가 잘 생각해 보시면, 신입 사원이 팀장까지 가기 위한 스킬북이라고 보셔도 좋습니다. 전형적으로 우리나라에서 요구하는 개발자 구인 스킬이지요. 결국 코딩 하다가 커뮤니케이션 스킬을 인정받으면 5~10년 후 팀장 명함은 따놓은 당상입니다. 즉, 이것이 대다수의 개발자의 커리어가 될 수 도 있다는 의미입니다.

  • 이렇게 궁극의 개발자는 바로 관리자인 것인가…?
  • 개발도 제대로 못해본 사람들이 어떻게 좋은 소프트웨어를 만들 것인가…?

코드+코드+코드…+컴파일=소프트웨어
개발자+개발자+개발자…+야근=소프트웨어

아마도 필자가 수 년 전에 사용했던 이력카드의 스킬 인벤토리는 여러 개발자들도 낯설지만은 않을 것입니다.

우리나라 소프트웨어 산업의 80%인 SI(System Integration) 프로젝트가 모두 이런 형식의 이력카드를 사용하고, 고객사들도 원하는 것이 이런 형태의 이력카드이며, 여기에 근무기간을 합산하여 개발자 등급을 분류하여 페이(월급)을 지급합니다. 내가 저 프로젝트에서 뭘 하든 개발자를 바라보는 자세가 한낮 스타크래프트의 SCV, 그 이상이 아니다는 의미이기도 합니다.

저 또한 저러한 이력카드를 채우지 않은지 오래되었지만, 최근에는 제 스킬 인벤토리를 페이스북에 올려놓고 꾸준히 업데이트를 하고자 노력하기도 합니다. (http://www.facebook.com/profile.php?id=100000339676463&sk=info ) 좋은 예가 될지는 모르겠지만, 제 스킬 인벤토리는 최대한 특정 플랫폼에 종속적이지 않도록 작성했고, 제가 수행한 업무를 잘 소개하려고 노력 하였습니다. (물론 제 진짜 이력서가 아닌 제 간략한 정보임을 인지하고 봐주세요) 그리고 제가 개발자로써 어떤 활동을 하며, 어떤 에반젤리즘을 하는지도 http://powerumc.codeplex.com/ 를 통해 게시하고 있습니다.

이러한 필자의 발버둥은 SCV 이상이 되고 싶음을 갈망하는 것일지도 모릅니다. 하지만 개발자는 개발자 다워야 합니다. 개발자는 개발이 기본이 되어야겠지요.

애자일 개발 프로세스에서는 함께 하는 팀간에 비즈니스 모델이나 비전을 제시하고 함께 공감대를 형성하여 최상의 퍼포먼스와 팀워크를 구축하는 것이 첫 번째 단계입니다. 그래야 반복이고 머고 잘 됩니다. 애자일 개발 프로세스는 몰라도 됩니다. 팀원이 "이것이야 말로 애자일 프로세스로 돌아가는 프로젝트구나!!!" 라는 것을 느끼게 할 필요도 없습니다. 첫 단추를 잘 꿰면 굳이 애자일 프로세스가 아니더라도 마치 자연의 생태계의 흐름처럼 애자일리티할 수 밖에 없기 때문입니다.

즉, 필자가 이 섹션에서 하려는 말은 개발자는 개발이 기본이 되어야지, 회사나 프로젝트의 비즈니스는 그 다음 단계라는 것입니다. 회사나 프로젝트의 이익을 창출하는 비즈니스의 모델과 프로세스를 잘 이해하면 좋지만 개발자의 기본적인 소양을 갖추지 못한 사람이 그 비즈니스를 구현하게 되면 그것처럼 서포트하기 힘든 것도 없습니다.

결국은 좋은 테스트를 하기 부적격한 개발자들

이야기가 삼천포로 갔습니다만, 필자는 앞으로 테스트에 대한 연재는 계속될 것입니다. 그런데 다시 한번 우리나라 소프트웨어 생태계를 구성하는 많은 사람들을 보고 느낄 때는, 테스트가 문제가 아니라 개발자 한 명 한 명이 갖는 커리어와 목표 의식이 없는 것이 더 큰 문제입니다. 이러한 우리나라 소프트웨어 개발에 대한 입방아는 책 한 권으로도 모자랄지도 모릅니다. 그리고 이를 공감하는 분들도 제 주변에 꽤 많은 편이고요.

결국 마치 필자가 우리나라 소프트웨어 생태계를 전반적으로 싸잡아 몰아가는 것처럼 보이지만, 꼭 그렇지는 않습니다. 왜냐하면 한 동안 테스트를 Sub Job으로 수행하면서 이러한 개발자의 근본적인 자세, 테스트를 대하는 자세, 테스트에 대한 편견, 테스트 결과가 개발자 자신에게 미치는 영향 등 여러 가지 경험을 하면서 결국 근본적인 문제에 대한 생각을 한 것 뿐입니다. 즉, 테스트라는 일련의 소프트웨어 개발 단계에 들어가기도 전에 많은 수행 착오를 거치면서 테스트의 기술적인 문제가 아니라 그 이전에 테스트를 바라보고 이해하는 사람들의 문제 라고도 바꾸어 이야기 할 수 있습니다.

다시 말해,

  • 대다수의 개발자는 테스트는 필요하지만 내가 알 바는 아니라고 생각하고 있습니다.
  • 그리고 자신에게 부정적인 영향을 주는 테스트에 대한 적대적인 반감을 드러내는 것은 개발자로써가 아닌 감정적으로 대응하는 개발자들의 문제점들이 내포하고 있습니다.
  • 더 문제인 것은 테스트를 단 한번도 생각해 본적 없는 사람들이 테스트에 대해 펌하하고 논하는 것도 참 안타깝습니다.
  • 이보다 더 큰 문제는 테스트를 수행하는 사람 또한 소프트웨어/테스트 공학 1장도 읽어 보지 않은 사람들이 대부분이라는 것도 테스트를 수행하는데 큰 걸림돌입니다.
  • 종합해보면 테스트라는 일련의 단계에 대한 최소한의 이해가 부족하고, 스스로 부족한 것을 알고 받아들일 줄 아는 이해심도 부족합니다.

소프트웨어 개발 사이클에서 초기 분석과 설계를 잘 하는 것이 중요하고 그것을 잘하는 사람이 있음으로써 개발에 까지도 영향을 미치는 것은 "애자일 개발 프로세스"든 "전통적인 개발 프로세스"든 마찬가지 입니다. 테스트도 마찬가지 입니다.

라이브 서비스를 하는 소프트웨어 서비스 업체들도 성능, 버그, 결함, 오류, 해킹 등에 많은 투자를 하고 심도 있게 다루는 부분입니다. 테스트는 분명 매우 민감하고 기본적이며 중요한 단계입니다.

테스트는 개발을 염두하고 테스트를 하지만, 개발자는 테스트를 염두하고 개발하지 않습니다. 그렇기 때문에 테스트는 개발자에게 언제나 불리할 수 밖에 없습니다. 아무런 이음매가 없는 개발 단계에서 테스트 단계까지 자연스러운 이음매를 맺기 위해서 기술적인 것은 기본이 되어야 할 것이며, 그 근본적인 공학적인 지식도 앞으로 꾸준히 다루어 보고자 합니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. asd 2011.10.24 11:05 Address Modify/Delete Reply

    asdasdasd

  2. demum 2011.10.24 12:42 Address Modify/Delete Reply

    오랜만에 좋은글 잘 봤습니다.

  3. 김용규 2011.12.21 10:38 Address Modify/Delete Reply

    품질 보증의 중요성은 개발만큼 중요하다고 생각합니다.

    고객들은 그 제품의 코드가 얼마나 잘 짜여있다는 것을 보는것이 아니라

    완성된 제품을 보고 평가를 하는 것이니깐요..

    좋은글 정말 잘 읽었습니다^_^

 

오늘 훈스 닷넷에서 조금 짜증이 나는 글을 읽었습니다.

http://www.hoons.kr/board.aspx?Name=free&Mode=2&BoardIdx=32994&Key=&Value=

 

운전하다가 접촉사고가 일어나면 목소리 큰 사람이 이긴다는 하지만, 이 글을 읽으면서 사실 '이건 아니다!' 라는 생각부터 듭니다. "나쁜 관리자" 라는 것이 무엇인지는 감을 잡았지만, 무엇이 나쁘다는 것인지 도저히 저는 이해할 수 없네요.



업계를 보면 관리자의 자격이 전혀 없는 사람이 관리를 맡고 있는 경우가 무척 많다. 나쁜 관리의 비용은 엄청나다. 단지 팀 구성원들의 작업에 지장을 주는 정도가 아니라, 조직의 목표 달성에 해악을 미치며 결국 상당한 대가를 치르게 만들고 프로젝트를 완전히 망치는 경우가 빈번하다.

필자는 단지 관리자를 잘못 배정했기 때문에 수백억 원의 손해를 본 어느 대기업의 프로젝트를 경험한 적이 있다. 팀원들은 모두 유능했고 각자의 마음 속에 일을 잘하고자 하는 열정이 있었지만, 관리자의 무능과 변덕과 학대로 인해 팀원들은 모두 좀비가 되어갔다. 일부는 떠났고 일부는 일을 하지 않았고 일부는 하는 척을 했다. 결국 수년간 프로젝트를 진행했으나 결과는 나오지 않았고 프로젝트는 취소됐다. 몇 가지 추가적인 원인이 없었던 것은 아니지만, 가장 주요한 요인은 ‘나쁜 관리자의 존재’ 그 자체였다.

나쁜 관리자는 팀원들이 무엇을 하고 있는지 알지 못하며(또는 관심이 없으며), 팀원들의 능력을 제대로 파악하지 못한 채로, 원칙 없이 업무를 지시하며, 부적절한 인력을 배치하고, 팀원들과 제대로 대화를 나누지 않으며, 펫프로젝트(pet project, 고위층 또는 자신의 개인적인 관심으로 만들어낸 프로젝트)로 인해 업무 우선순위를 마구 바꾸고, 결과가 나와도 잘했는지 못했는지 제대로 판단하지 못한 채 자신의 기호에 따라 결과를 재단한다. 한마디로 그들은 조직의 목표와 팀원의 성장에는 아무런 관심이 없으며 단지 자신의 안위만 생각하는 사람들이다.

그러한 나쁜 관리자의 존재가 지극히 예외적인 경우라고 생각하는가? 만일 그렇다면 당신은 조직 생활의 경험이 많지 않든가, 아니면 억세게 운이 좋은 경우일 것이다. 그런 나쁜 관리자로 인하여 젊은 시절의 소중한 경험을 빼앗기는 팀원들이 몹시 많다. 나쁜 관리자의 해악은 단지 프로젝트의 실패로 나타나는 것뿐만 아니라, 사람들의 인생에서 그 시기에 필히 겪어야 할 소중한 경험까지 앗아가 버리는 것에 있다. 좋은 관리를 받아보지 못한 사람은 좋은 관리를 할 수가 없다.
[출처:IT컬럼니스트 류한석님 글 일부 발췌]

 

일단 저는 류한석님의 극단적인 내용에 조금 반대 의견이네요 ^^;

일단 이 답글을 적는데, 보시는데 조금 비위가 나쁘다면 일단 양해를 구합니다.

 

프로젝트 관리자란?? 일단, 프로젝트를 발주하는 고객(또는 발주처)와 프로젝트를 구현을 진행하는 개발자들과의 조율이 필요합니다. 엄밀히 R&R 을 따지자면 관리자는 개발자가 무었을 하는지 알 필요가 없습니다. 관리자의 입장에서는 단지, 개발자는 해야할 일을 정확하게 구현을 완료 했는지가 중요합니다. 개발자가 역량에 미치지 못했다면 그 개발자를 뽑은 사람이 잘못이겠지요.

 

프로젝트 개발자란?? 고객에 의해 정의된 요구사항을 순차적으로 구현하는 사람이 개발자입니다. 고객과 관리자는 개발자의 역량을 측정하는 방법은 요구하는 시간내로 기능을 구현했는지가 중요합니다. 가장 좋은 개발자는 재시간에 기능을 구현할 수 있는 역량을 갖춘 사람입니다.

 

그냥 간단하게 프로젝트 관리자와 개발자를 정의했습니다. 제 상식으로는 위의 류한석님 글을 이해하기에는 부연 설명이나 설득력이 너무 부족하기만 합니다.

 

첫번째로, 자! 제가 정의한 내용에 대해, 과연 개발자의 입장에서 관리자를 평가한 것인지, 관리자의 입장에서 관리자를 평가한 것인지 애매하네요. 프로젝트가 실패하는 원인을 여러가지입니다. 관리자는 고객의 파워나 변덕이 너무 심해 그것을 받아줄 수 밖에 없을 수 있습니다. 반대로 관리자가 고객의 요구에 대해 방어적인 태세만 취한다면 고객의 입장에서는 좋은 프로젝트 관리자가 아닙니다. 즉, 관리자와 고객간의 비하인드 스토리는 전혀없고 단지, 개발자 입장에서만 불평을 나열한 것 같습니다. 잘 아시겠지만, 고객은 자신의 요구하는 정확한 요구사항을 알지 못합니다. 그것을 잘 정의하는 사람이 아키텍처나 설계자가 되겠지요.

 

두번째로, 이미 얘기했지만 엄밀히 따지자면 관리자는 개발자가 무었을 하고 있는지까지 알 수 없고 알 필요도 없습니다. 관리자는 소수이지만 개발자는 다수일 수 있습니다. 부적절한 인력 배치란 무엇인가요? 그리고 왜 프로젝트 관리자(PM) 이 개발자와 이야기를 나누어야 한다고 생각하나요? 실질적인 개발자와 협업하는 사람은 프로젝트 리더(PL) 일 가능성이 큽니다. 즉, 류한석님이 말씀하시는 프로젝트 관리자란 진정 프로젝트 관리자인가요? 아니면 개발팀의 관리자 인가요?

 

세번째, 프로젝트 관리자(PM) 는 프로젝트 전반을 관리하거나 매개체 역활을 합니다. 프로젝트 관리자는 다수의 개발자의 결과물을 보증하는 QA(Quality Assurance) 가 아닙니다. 순차적인 원인은 관리자의 잘못에서 비롯되는 것이 아닙니다. 따지자면 요구사항을 제대로 이해하지 못했거나 변덕스런 요구사항에 짜증이 날만한 개발자로부터 비롯되거나, 제대로 된 기능을 만들지 못한 개발팀 내부적인 문제가 되겠지요. 

 

결국 좋은 프로젝트 관리자란 개발자의 비유에 맞추어야 할 필요가 없습니다. 프로젝트 관리자는 자신의 위치에서 최선을 다하면 될 뿐입니다. 그것을 단지 몇명의 개발팀의 개발자에 의해 평가될 문제가 아닙니다. 아마도 프로젝트 관리자는 단지 개발만 하는 개발자보다 더 많은 고민을 가지고 있을 것입니다.

 

대체적으로 이러한 불만은 개발자인 자신의 요구가 반영이 되지 않거나, 자신의 입지를 넓히려고 하지만 그렇게 되지 않을 경우에 개발자들은 위와 같은 불평을 하게 됩니다. 가령, 동영상 플레이어가 필요하다고 한다면, 동영상을 재생하기 위해 미디어 플레이어 객체로 단지 몇줄로 재생하는 것과, Silverlight 로 동영상 플레이어를 만드는 것은 효율성을 따지면 극과 극입니다. 또는 설계가 일부 잘못되었다고 하더라도 시간 vs 비용 을 따지면 하고 싶어도 못하는 경우가 많습니다.

 

프로젝트 관리자가 일부 소수 인원을 중심으로 움직이지 않는다는 것이 오히려 좋은 프로젝트 관리자인 경우가 많습니다. 제한된 공정에 좋은 소프트웨어를 Delivery 하기 위한 것은 개발자가 프로젝트 관리자를 무언가로 평가하는 것보다 더 좋요하기도 합니다. 즉, 개발자의 입장에서 가장 좋은 대책은 설계대로 프로젝트의 구현을 개발하는 것이고, 그것이 잘못되었을 때는 프로젝트 관리자의 책임을 묻는 것이 맞습니다.

 

프로젝트가 성공하건 실패하건 그것은 단지 한명이 몰빵할 수 없는 문제입니다. 고객, 프로젝트 관리자, 기타 개발 인원이 골고루 잘못된 것이지, 성공과 실패를 프로젝트 관리자에게 몰빵한다는 것은 이미 자신부터 잘못되었다고 해석하는 것이 맞습니다.

 

이해할 수 없는 개발자의 감성만 자극하는 이러한 글을 오히려 개발자에게 프로젝트 관리자에 대해 잘못된 인상만 심어줄 뿐입니다. 이 글을 보니 관리자가 무엇을 잘못했는지 전혀 나타내지 않았군요.

 

만약, 비난의 대상이 프로젝트 관리자(PM) 가 아닌 개발 팀장 등이라고 하더라도 똑같은 비난을 했을 것입니다. 왜냐하면 자신은 잘못이 없다는 것을 전재로 했을테니까요. 오히려 필자는 이러한 문제를 인지하고 있으면서도 슬기롭게 대체하지 못한 개발자에게도 문제의 소지가 다분하다고 생각합니다. 이런 형식의 회고는 전혀 자신과 타인에게 도움이 되지 않을 뿐입니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 한진수 2010.03.26 16:02 Address Modify/Delete Reply

    http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039162121
    http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039164072
    2007년도 지디넷 컬럼의 극히 일부분의 내용으로 괜한 자극을 드린점 사과드리구요.(_-_);; 괜히 타겟 아닌 타겟이 된 류한석님에게도 사과의 말 전합니다. 제가 링크 두개를 드렸는데요. 전체 내용을 살펴보게 되면 그저 좋은관리자, 좋은개발자에 대한 이야기를 하고 싶었던 것으로 보이며, "나쁜 관리자가 프로젝트를 망치고 있다!" 라는 소제목이 "프로젝트를 망치는 것은 나쁜 관리자다!" 라는 것은 아닐 것입니다. 일부 글에 너무 즉각 반응하신것은 아니셨나 하는 생각을 해 봅니다.(^^)

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

      그러게요. 2007년도 글이었네요. ^-^;
      원본을 보니 글의 일부를 게시판에 올리셔서
      오해를 많이 했답니다.

      제가 글을 쓰는 속도가 늘었나보네요. 즉각 반응까지는 아니였는데~ ^_^
      아무튼 좋은 글 보고 갑니다.

  2. 심순덕sjbj 2010.04.02 11:46 Address Modify/Delete Reply

    음~ 글을 논리적을 잘 쓰시네요
    아마도 생각이 깊으신듯....
    우연히지만 좋은 의견 보고 갑니다.