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

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



[출처] 링크


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

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

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

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

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

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

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

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

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

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

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

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

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

/out:simple.exe
simple.obj

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Posted by 땡초 POWERUMC

댓글을 달아 주세요

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • 땡초 2015.08.09 00:17 Address Modify/Delete

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

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

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

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

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

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

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

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

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

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

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

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

    괜히 Groovy가 나왔겠습니까.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

팀 파운데이션 서버(Team Foundation Server) 는 2005년 처음 시장에 공개되었다. 이 시기에 많은 버그와 설치 자체가 매우 난이도가 높아서 많은 사람들의 원망을 샀다.

참고 - TFS를 쓰지 말아야 하는 진짜 이유 #1 (링크)

TFS를 쓰지 말아야 하는 진짜 이유 #1을 정리해 본다.

  • 통합? 모든 것을 만족할 수 있지만, 어느 것도 만족할 수 없다.
  • 특정 제품(Visual Studio)에 완벽하게 통합되어 외부와 완벽하게 격리된 솔루션이다
  • 우리나라에는 전문가가 없다
  • 전문가적인 서비스를 제공하는 업체도 없다
  • 마이크로소프트 제품으로 발라야 한다
  • 예측할 수 없는 잦은 장애, MS 제품에 잔지식이 많아야 한다
  • 제대로 된 기능이 하나도 없다

TFS를 쓰지 말아야 하는 이유 중 기능적인 요소로는 다음과 같다. (차후에 자세히 다루겠다)

  • 데이터베이스에 소스 코드가 저장되다보니 DB 로그 사이즈는 DB 용량(데이터)의 수십 배가 넘어간다
  • 모든 서버 통신은 SOAP 프로토콜을 사용하므로 매우 느리다
  • 작업 항목(WorkItem) 관리, 이슈/버그/개발 등을 관리하기에 매우 비효율적이고 쓰는 것 자체가 스트레스로 발전할 수 있다. (다른 이슈 관리 툴에 비해)
  • 모든 기능에 제한이 너무 많다

1. 팀 파운데이션 서버(Team Foundation Server)[1]

구글 트랜드(Google Trends)는 아래의 그래프와 같이 새로운 버전이 나올 때 조금씩 치고 올라가는 것을 알 수 있다. 하지만, 시간이 지날수록 이탈하는 사용자가 많을 것이고, 현재는 엉망으로 만들었던 TFS 2005 버전보다 더 관심이 줄어든 것으로 보인다.



2. TFS vs SVN

필자도 사실 이걸 보고는 깜짝 놀랬다. SVN(아파치 서브버전)이 알려진 시기는 TFS 2005와 몇 년 차이가 나지 않지만, SVN은 그야말로 LTE처럼 뻥 뚫린 고속도로처럼 고속으로 성장을 했다. 반면에 Team Foundation Server는 바닥에서 지렁이 기듯이 기어다닌다.



3. TFS vs SVN vs GIT

SVN과 GIT이 끼니 더이상 TFS에 대해서 할말을 잃게 만든다. 이쯔음 되면 TFS를 쓰는 사람들은 분명 M빠거나 멋모르고 쓰는 것이 분명하다.



4. TFS vs SVN vs GIT vs Mercurial

따로 TFS는 해설이 없어도 될 것 같다. 아래의 그래프가 여실히 보여주고 있으니 말이다.



결론

99% 중에 1%라면 매우 희소성이 있고 가치가 있어 보일 수도 있다. 필자가 그랬다. 스스로 가치 있다고 판단한다면 분명 그것은 가치가 있는 것이다.

하지만 소스 제어를 비롯한 ALM은 혼자만 가치를 느껴서는 절대로 공존할 수 없는 도구의 집합이다. 통합이 완벽해서 완전히 격리된 ALM 제품은 소프트웨어에 생명을 불어 넣기에 바라보는 안목을 작아지게 만든다. 툴에 종속되어 생각을 제한해서는 안된다.

100명 중 99명이 No 라고 말할 땐 그만한 이유가 있다. TFS는 2005년부터 시작되었고 현재 2013년이다. 횟수로 8년이 되었지만, TFS는 여전히 고질적인 문제를 해결하고자 하는 노력을 하지 않는 것 같다. 현재의 TFS 2012/2013 은 TFS 2005 초기 버전 그 이상을 아직도 뛰어 넘지 못했고, 앞으로도 뛰어 넘지 못할 것이다.

  • 성능
    점점 느려진다. 28GB 넘는 바이너리가 없는 소스코드를 인트라넷 네트워크에서 10시간 넘게 받은 적이 여러번이다.

  • 확장성
    SDK로 깨잘되는 것 말고 할 수 있는 확장 포인트가 거의 없다.

  • 사용성
    애자일보드/칸반(Kanban), 드래그&드롭, 이런거 보여주면서 사용성이 좋다고 하면 오류다. 실무에서 거의 쓸 일도 없고 더 불편하다.

  • 크로스플랫폼
    Team Explorer EveryWhere 가 크로스플랫폼을 지원한다고? 만약 이클립스를 안쓰면 어쩔건데…? 답이 없다. 다양한 개발툴 대부분이 TFS를 지원해 주는 플러그인이 없고, 지원이 된다고 해도 소스 제어 수준에서만 지원을 한다. 그러므로 통합의 의미 자체가 희석되어 버린다.


  1. ‘TFS’ 트랜드 검색 시 merida/matts 등의 통계에 방해되는 데이터가 포함되어 Team Foundation Server 로 탐색을 하였음.  ↩


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 조경민 2014.05.14 18:36 Address Modify/Delete Reply

    참 안타까운 현실이네요.. 안타까운 마음에 글 남겨봅니다..
    저희 회사에서는 아직도 TFS 2010을 사용하고 있습니다. 물론 제가 서버 구축(MOSS연동까지..)부터 관리까지 다 하고 있는 상태이구요. 용도는 이슈(요구사항, 버그) 및 개발작업(릴리즈, 로드맵, 사이트모듈, 회의록, QA요청) 관리 위주로 사용하고 있습니다. 소스관리는 시도를 했다 결구 SVN으로 갈아탔지요.. 요즘 SVN은 AD와 연동이 되서 그나마 다행이었네요.
    제가 기존 TFS에 매력을 크게 느꼈던 부분은 양식의 커스터마이즈와 한글화 때문이었습니다.
    위에 언급한 이슈(요구사항, 버그) 및 개발작업(릴리즈, 로드맵, 사이트모듈, 회의록, QA요청)모두 양식을 커스터마이즈 해서 사용하고 있습니다. 필드까지 싹 변경 할 수 있기 때문에 저에게는 엄청난 강점으로 느껴졌었습니다. 아주 심플한 혹은 강제화 할 수 있는 양식으로 탈바꿈할 수 있다는 부분은 큰 매력이였네요. 지금도 물론 잘 사용하고는 있지만 근래 JIRA 등의 동향을 보고 싶어 검색하다 여기까지 오게 됬네요.
    지금으로써 제일 불편한점은 간트차트를 사용하지 못한다는 것 외에는 크게 없는데.. JIRA를 데모해보면 또 어떻게 바뀔지 모르겠네요.
    환경적인 내용 외에 위 언급드린 내용 기준으로 비교되는 글이 더 있음 정말 좋을 듯 합니다. ^^

    아 그리고 한글화는 아직도 TFS가 최고라고 생각되네요 ㅋㅋ이넘의 짧은 영어는 언제나 발목이..

    좋은 글 잘 읽었습니다. 앞으로도 좋은 정보 부탁드립니다.
    감사합니다.

  2. 남뉴 2014.07.02 11:21 Address Modify/Delete Reply

    재밌는 글 감사합니다. 전 오히려 개발소스버젼관리시스템 자체에 회의감이 듭니다. 여러 사람이 쉽게 소스를 관리하는건 장점이고 권한에 따른 제한도 있어서 장점일 것 같지만, 오히려 잘못된 버젼 관리로 인한 문제가 더 많아 질때가 있습니다.(이건 직급이 높아도 경험이 많아도 문제가 발생합니다. )
    덕분에 압축과 시스템을 병행하고 있습니다. 마치 종이로 인쇄하고 다시 PDF나 문서파일로 웹에도 올리는
    형상이죠

  3. 지나가는이 2015.04.20 16:06 Address Modify/Delete Reply

    훌륭한 정보 잘보고 갑니다. 감사합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

image-1
이미지 링크

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#1의 결론

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

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

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

Posted by 땡초 POWERUMC

댓글을 달아 주세요

$tf 폴더

팀 파운데이션 서버(Team Foundation Server) 2012 버전부터 로컬 워크스페이스(local workspace) 에 매핑된 폴더 중 $tf 파일이 생긴 것을 알 수 있다. 이 폴더는 숨김(hidden) 속성이 적용되어 있어 안보인다면 숨김 폴더도 보이도록 윈도우 익스플로어(Windows Explorer) 에서 설정을 변경하면 된다.

이 폴더는 여러분이 주로 작업하는 작업 영역(Workspace)일 경우 생각하는 것 보다 훨씬 많은 용량을 차지하고 있다. 이 폴더는 특성상 늘어나면 늘어나지 절대 줄어들 일이 없다. 대부분의 시간이 지날수록 코드의 라인은 늘어나고 변경이 일어나는 부분도 많아진다.

이 폴더가 내심 꺼림직해서 지워도 또 다시 생긴다. 이 폴더는 Team Foundation Server 2012 버전을 쓰고 + 로컬 작업 영역(Local Workspace)로 매핑된 폴더에 생긴다. 이게 의외로 골치 이프기도 하고 문제가 되기도 한다.

$tf 폴더, 왜 생기나…

이 폴더은 네트워크가 오프라인(offline) 상태로 중앙 서버에 연결할 수 없는 경우 스텐바이(standby)하고 있다. 물론 오직 오프라인(offline)을 위한 폴더는 아니다.

팀 파운데이션 서버(Team Foundation Server) 2012 + 로컬 작업 영역(local workspace) 조합이면 백퍼 생기는 폴더다. 일종의 소스 코드의 스냅샷(snapshot) 과 메타데이터(Metadata) 정보를 가지고 있다. [1]

image-1
[이미지 참조 링크]

이 폴더가 생기는 주된 이유 중 하나가 네트워크가 오프라인(offline)이 될 때 서버로 연결할 수 없으므로 이 로컬 작업 영역을 참조하게 된다. 팀 파운데이션 서버(Team Foundation Server)는 변경집합(change set) 단위로 데이터베이스(MSSQL)에 저장하는데, $tf 안에 변경집합(change set) 정보를 데이터베이스 처럼 활용하여 저장하게 된다.

image-2
[이미지] $tf 폴더 내부 구조, 각 파일은 zip 압축이 되어있다.

정체성을 잃은 TFS 소스 제어

이런 오프라인 기능을 지원하는 건 반갑다만 팀 파운데이션 서버(Team Foundation Server) 는 처음부터 오프라인을 고려하고 만들어지지 않았다. 전략적으로 비주얼 스튜디오(Visual Studio) 를 사용하는 기업이나 단체를 대상하기 때문에 오프라인(Offline) 가능성이 매우 낮은 환경을 대상으로 하는 솔루션이다.

필자의 경우 예전부터 작업하던 모든 $tf 폴더의 용량이 1GB를 훨씬 넘었고, 이런 빈번하게 작업하는 폴더를 여럿 가지고 있다. (최근 용량이 많이 차지해서 과감하게 $tf 를 지워버렸다.)

SVN 또한 .svn 이라는 숨김 폴더가 있는데 이를 ‘Administrative Directory’ 라고 부른다. 이 관리 디렉토리는 SVN을 사용하면서 변경되는 파일의 정보를 저장한다. SVN도 마찬가지로 .svn 폴더의 용량이 증가하게 되는데, 이런 경우 작업 중인 디렉토리를 복사할 때 .svn 디렉토리도 함께 복사가 된다. 최근 SVN은 이 폴더가 최상위 루트에 하나만 생기도록 변경되어 작업 디렉토리마다 .svn 폴다를 신경써야 할 필요가 사라졌다.

git 으로 잘 알려진 대표적인 분산 제어 방식의 소스제어(Distributed Version Control) 또한 로컬의 스테이징 저장소(Staging Area)를 이용한다.

사실 팀 파운데이션 서버(Team Foundation Server) 는 애시당초 오프라인에 대한 대안이 없었다. 네트워크가 오프라인이 되고 파일을 체크아웃을 하면 로컬 작업 파일이 읽기 전용(Read Only) 파일 속성이 해제되고 서버와 연결이 끊겨도 수정이 가능하다. 다시 네트워크가 사용이 가능할 때 ’온라인 상태’로 변경할 수 있는데, 이 때 체크이웃된 사실을 서버에 통보하게 되고 서버는 이 때 체크이웃 상태로 변경한다. 오프라인 상태일 때의 변경 집합은 온라인 상태에서 병합하게 되는 시나리오를 가지게 되는데, 로컬에 저장했던 변경 기록은 병합할 때 충돌(conflict)를 줄일 수가 있다.

하지만 좋은 오프라인 정책이 있더라도 경험적으로 알 수 있은 것은 오프라인(서밋이 일어나지 않는)이 오래될 수록 충돌(conflict)은 피할 수 없다. 비교적 간단하게 병합(merge)할 수 있는 어느 정도의 단계를 넘어서면 병합 도구는 변경이 일어난 부분과 일어나지 않은 부분을 제대로 분간하지 못하는 상황까지 온다.

$tf 폴더는 생기는데, 이를 제한할 수 있는 방법이 없어…

어떤 이유던 간에 $tf의 용량은 점점 커진다. 그러나 이 폴더의 용량을 제한할 수 있는 설정은 존재하지 않는다. 그리고 git 을 함께 사용하는 개발자는 소스 코드가 보관된 폴더에서 .gitignore 에 $tf 를 제외할 수 있도록 설정을 하기 바란다.

다만, $tf 폴더가 가지는 몇 가지 장점이 있다. 그러나 오프라인(offline) 일 때 굳이 파일의 버전을 비교할 예외적인 상황도 없었고, 오프라인 일 때 파일 이름을 변경한 경우도 있으나 다시 온라인일 때 무리 없이 파일의 상태가 반영이 되었다. 그러므로 필자는 수 년을 사용하면서 이 장점을 얻기 위한 예외적인 상황을 거의 몇 번밖에 만나보지 못했다.

MSDN 에서 $tf 폴더에 대해 자세하게 기술이 되어 있지 않으나 참고가 필요한 분은 이 링크[2]를 통해 확인하기 바란다.


  1. References - Team Foundation Server - Trying to understand Server versus Local Workspaces
    http://blogs.msdn.com/b/willy-peter_schaub/archive/2011/11/30/team-foundation-server-trying-to-understand-server-versus-local-workspaces.aspx  ↩

  2. References - Team Explorer Everywhere의 새로운 기능
    http://msdn.microsoft.com/ko-kr/library/jj155781.aspx%23local  ↩


Posted by 땡초 POWERUMC

댓글을 달아 주세요

들어가기 앞서

팀 파운데이션 서버(Team Foundation Server) 는 구성과 운영이 매우 까다로운 ALM(Application Lifecycle Management) 솔루션 중의 하나다. 그간 오류에 대해 정리하는 의미로 팀 파운데이션 서버(Team Foundation Server) 를 운영하면서 겪을 수 있는 여러 가지 경우의 오류를 리스트업 해본다.

앞서, 마이크로소프트(Microsoft)의 제품이 가지는 여러 통합 제품은 공통적인 단점을 가지는데 그것은 통합되는 요소들이 모두 자사 제품임에도 불구하고 환경적인 요소에 매우 민감하다는 점이다.

image–1

통합된 만큼 오류 유형도 광범위

팀 파운데이션 서버(Team Foundation Server)는 윈도우 서버, SQL 서버, 웹 응용 프로그램 서버(IIS, Inernet Information Services), 그리고 쉐어포인트(SharePoint) 등과 통합이 되는데 심각한 경우 매우 작은 요소들로 인해 일부 서비스의 작동 자체가 멈춰버린다.

예를 들어 엑티브 디렉토리(Active Directory)나 데이터베이스 서버가 변경되거나 백업(Backup), 복원(Restore) 계획, 그리고 서버간의 인증이나 그룹, 맴버, 역할 그리고 시스템의 환경적인 변수 등 큰 범위부터 작은 범위까지 다양하게 나타난다.

때문에 매우 구체적으로 자원을 운용할 수 있는 장점과 함께 운영 규모가 커질수록 통합된 각 제품에 대해 매우 깊은 솔루션 지식이 요구된다. 대부분 상세한 오류 메시지를 제공하지 않고 추상적인 메시지를 제공하기 때문에 통합된 제품의 상호 관계를 확실히 이해하고 ‘감(Feeling)’으로 잘 때려 맞춰야 하는 경우도 생기게 된다.

단, 필자가 나열한 것 보다 더 많은 오류 발생과 해결이 있었으나 사소하거나 기억할 필요가 없다고 생각한 것들은 블로그에 올리지 못한 것도 다수 있다.

팀 파운데이션 서버(Team Foundation Server) 오류 해결

팀 파운데이션 서버(Team Foundation Server) 운영 정보


Posted by 땡초 POWERUMC

댓글을 달아 주세요


최근 Git이나 Mercurial 과 같은 분산제어 방식의 소스 제어 제품을 무조건 맹신하고 찬양하거나 분산제어 방식보다 중앙집중형 소스제어 방식을 무조건 배척하는 현상이 일부 나타나고 있다.

리누스 토발즈(Linus Tovalds)와 같은 공산주의(Communism) 사상의 이상을 강조하는 철학이 담긴 Git은 GitHub.com을 통해 소스 코드를 공유함으로서 오픈 소스 진영에 매우 발전적인 기여를 하고 있음은 확실하다. 리누스 토발즈(Linus Tovalds)가 만든 것이라 그런지 훨씬 더 주목받고 있는 것 같다.

중앙집중 소스제어와 분산제어 소스제어 방식은 그 원칙과 근본적인 가치에 차이가 있는, 방법론으로 접근해야 할 것이다. 따라서 각 소스 제어의 방식마다 특징과 장단점이 있으며 ‘좋은 게 좋은 것 아닌가~’ 라는 간단한 답을 얻길 바란다.

필자는 중앙집중 소스제어와 분산제어 소스제어 방식의 장단점을 5가지의 관점에서 살펴보자. 중앙집중 소스제어(이하 중앙제어 방식)은 분산제어 소스제어 방식을 사용하는 몇 가지 소프트웨어를 제외한 대부분으로 보면 된다.

  • 중앙통제력
  • 정책주입력
  • 분기용이성
  • 사용편의성
  • 성능

그 외에 도움이 될만한 위키피디아(Wikipedia) 링크를 참고하기 바란다.

내용상 비교하는 대상은 중앙제어 방식은 ‘팀 파운데이션 서버(Team Foundation Server)’와 SVN을 많이 참조하였고, 분산제어 방식은 ‘Git’을 많이 참조하였다.

중립적인 관점에서 글을 작성하였으나 어느 한 쪽으로 편향이 되었다면 미리 그 점에 대해 양해를 구하는 바이다.

중앙통제력

이름에서도 알 수 있는 것 처럼 중앙집중적인 통제력은 기존의 중앙집중 방식이 분산제어 방식보다 유리한 점이 많다. 분산제어 방식은 자신이 서버로의 통제를 받는 동시에 제 3자에게 있어 자기 자신이 서버가 된다. 반면, 중앙집중 방식에서는 서버가 오직 물리적인 한 곳에 위치해 있다.

때문에 중앙집중 방식은 조직에 있어 정책적인 부분을 클라이언트에게 강제로 주입할 수 있는 여지가 많다. (물론 분산제어 방식도 가능하다) 중앙 서버 한 곳의 설정만으로 많은 클라이언트를 통제할 수 있다.


이미지 참조

그리고 모든 히스토리는 중앙 서버의 데이터베이스에 저장이 되기 때문에 클라이언트에게는 단지 소스 밖에 없지만, 분산제어 방식은 그렇지가 않다. Git의 스테이징 스토리지가 바로 클라이언트가 가지고 있는 데이터를 저장하는 (임시?)스토리지다.

조직에서 소스코드가 변경되는 주요 변경 이력은 매우 민감한 부분이고, 영업비밀과 직결되는 요소들이 많다. 응용프로그램이 연결되는 데이터베이스의 컬럼이나 테이블의 사소한 변경에도 응용프로그램은 수정되어야 할 수 있고, 이것이 응용프로그램의 소스코드에 반영이 되면서 소스제어에 이력을 남기게 된다.

정책주입력

정책적인 주입력은 중앙통제력과 유사한 부분이 많다. 중앙통제력이 크면 클수록 정책주임력은 향상된다. 중앙 서버의 정책적인 설정만으로 여러 클라이언트는 중앙 서버에 의해 통제받을 수 있다.

특히 ALM(Application Lifecycle Mamangement) 제품과 개발 IDE 제품간에 얼마나 긴밀하게 잘 통합이 되었느냐에 따라 정책주입력에 영향을 미친다. 통합이란 것이 양날의 검과 같아서 좋게 말하면 ‘All in One’이라 표현할 수 있겠고, 나쁘게 말하면 구성요소간에 강한 응집력으로 인해 제한된 확장이라 말할 수 있겠다.

ALM 통합의 장점

  1. 한 번의 구성으로 모든 것을 사용할 수 있다.
  2. 새로운 업그레이드도 한 번의 구성으로 모든 것을 구성할 수 있다.
  3. 개발툴과 통합되어 사용하기 쉽다.

ALM 통합의 단점

  1. 설치/구성 환경은 벤더에 의해 결정된다.
  2. 기능이 하나 하나가 완성도가 높지 않아 기업 및 도메인 환경에서는 추가 개발이 필요한 경우가 많다. (범용성을 위해…)
  3. 오픈 소스 ALM 도구보다 쓸 수 있는 도구들이 적다. (애드인/플러그인)
  4. 다양한 외부 도구와 연동이 제한된다.

분기용이성

분기(Branch)는 나무에서 여러 가지(Branch)로 뻗어 나가는 것을 일컬어, 하나의 소스 코드에서 여러 가지(Branch)로 소스 코드를 키울 수 있다. 특히 분산 제어 방식에서 분기가 얼마나 유용하고 효율적으로 사용할 수 있는지 잘 알 수 있다.

중앙 제어 방식에서의 분기는 곧 변경 이력으로 반영되어 영구적으로 분기 이력이 남게 된다. 때문에, 분기를 개인적인 용도로 사용하는 것이 힘들다. 소스 제어의 파일 시스템 구조를 복잡하게 만들 수 있고 구성원 개개인이 이를 핸들링 하기에는 전체 제품의 소스 코드에 좋지 않은 영향을 미칠 수 있다.


이미지 참조

반면, 분산 제어 방식의 경우 분기는 반드시 알아야 할 매우 효과적인 기능 중 하나로 볼 수 있다. 위에서 언급 했듯이 서버에게는 클라이언트가 되지만, 제 3자에게는 곧 서버가 된다. 즉, 로컬 서버(클라이언트)에서 자체적으로 분기가 가능해진다. 클라이언트에서 분기와 서버로 Push되는 정보는 다르므로 서버의 정책이나 구조에 영향을 최소한으로 적게 미치게 된다.

하지만, 중앙 제어 방식에서도 이런 단점은 충분히 극복할 수 있다. 분기는 병합(Merge)이라는 조건을 전제로 수행되는데, 만약 병합이라는 전제 조건이 없다는 가정하에 이와 유사하게 문제를 해결할 수 있는 방법이 있다.

중앙 집중 방식의 소스 제어 제품마다 기능적으로 다른 점이 있겠지만, 다중 작업 영역(Workspace) 또는 보류(Shelve) 기능을 이용하여 로컬 분기(Local Branch) 기능을 유사하게 흉내낼 수 있다. (물론 진정한 의미에서의 분기 목적과는 다소 차이가 있다)

사용편의성

사용편의성은 소스 제어를 사용하는 사용자가 얼마나 소스 제어를 편하게 사용함을 의미한다. 이를 언급하기 전에 사용편의성은 개개인의 경험적인 부분에서 다를 수 있다.

먼저, 분산제어 방식의 대표적인 Git을 험오하는 이유 10가지에 대해 쓴 블로그 내용을 참고하자.

Git is the source code version control system that is rapidly becoming the standard for open source projects. It has a powerful distributed model which allows advanced users to do tricky things with branches, and rewriting history. What a pity that it’s so hard to learn, has such an unpleasant command line interface, and treats its users with such utter contempt.
이하 생략…
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/

대부분의 소스 제어 명령은 GUI(그래픽 인터페이스)와 CMD(명령줄 인터페이스) 방식을 제공한다. 주로 GUI 방식은 개발툴과 연동이 되는 확장 또는 플러그인 방식으로 제공되고, CMD 방식은 소스 제어 제품 자체에서 제공하는 고유의 기능으로 제공이 되는 것이 대부분이다. 그래서 소스 제어를 사용하는 개발자가 어떤 환경에서 개발하느냐에 따라 GUI 또는 CMD 방식으로 갈리는 경우가 많다.

먼저, 이클립스(Eclipse) 또는 비주얼 스튜디오(Visual Studio)와 같이 비주얼을 강조하는 개발툴에서는 GUI 방식의 소스 제어 플러그인을 사용하는 경우가 대부분이다. 이런 환경에서는 키보드와 마우스를 함께 사용하는 경우이고 아이콘(icon)으로 수정된 파일을 바로 확인할 수 있다.

반면, SVN 또는 Git 의 CMD 도구의 사용이 익숙해질 경우 상당히 빠르게 명령을 사용하거나 결과를 확인할 수 있다. 그리고 개인용 컴퓨터의 성능에 거의 영향을 받지 않고 소스 코드를 개발할 수 있고, 손이 마우스와 키보드로 번갈아가며 사용할 필요가 없어 익숙한 사람에게는 더할 나위 없이 편리하다. 더불어, SSH와 같은 단순 Plain Text 환경에서도 제어가 가능하기 때문에 사용에 있어 거의 제한도 없다.

하지만 대체적으로 두 방식 모두 GUI 도구를 제공하거나 GUI 공개 소프트웨어가 많기 때문에 취향에 맞에 사용할 수 있다.

성능

중앙제어 방식은 모든 동작이 서버 측의 허가 없이는 불가능하거나 반드시 서버와 연결이 되어야 한다. 인트라넷이라면 크게 성능의 손실은 없겠지만, 지역이 다른 사람과 오픈 소스 개발을 하거나 클라우드 소스 컨트롤을 사용하는 경우 매우 느리다.

분산제어 방식은 모든 동작이 대부분 로컬에서 이루어 진다. Push, Fetch 같은 동작만이 서버와 연결이 필요하다. 때문에 성능이 매우 좋은 것이 특징이다. 하지만, 중앙제어 방식과 다르게 많은 데이터를 로컬에 저장해야 하므로 중앙제어 방식보다 로컬에 충분한 용량이 확보되어야 한다.

결론

몇 가진 기본적인 관점에서 깊지 않은 내용으로 중앙제어 방식의 소스제어 컨트롤과 분산제어 방식의 소스 컨트롤을 살펴보았다.

필자에게 어떤 것을 사용할지 묻는다면, 작은 개발 조직과 기업 환경에서는 중앙제어 방식을 권장하고 싶다. 많은 소프트웨어 개발 조직에서 여전히 통제하에 소프트웨어 개발을 하기를 원한다. 그리고 암묵적인 소프트웨어 개발 프로세스를 명시적인 프로세스로 개선하고자 하는 곳도 과거보다 많이 생겼다. 이런 환경은 중앙제어 방식이 더 효과적이라 믿는다.

반대로 분산제어 방식은 패키지를 개발하는 기업이나 IT 컨설팅, 국지적 개발 환경이 필요한 경우 효과적일 것이라 생각한다. 물론 기업 환경과 맞지 않는다는 것이 아니며, 통상적인 경우를 말한다.

필자는 우연히 Stack Overflow에서 매우 흥미로운 주제를 발견하였다. 바로 [Git vs Team Foundation Server [closed]]11 인데, 어느 개발팀의 분산제어 방식과 중앙제어 방식의 대결 구도에서 어떤 것을 선택해야 할 것인가에 대한 논의였다. (참고로 필자는 최근 git을 더 좋아한다.)

내용인 즉, 자신의 개발팀에 Git를 도입시켰으나, 개발 팀원들은 팀 파운데이션 서버(Team Foundation Server)로 바꾸길 원했다. 이 질문에 추천 답변의 내용은 ’Git을 버려라. Git을 계속 쓰다가는 계속 비난을 받고 싸우게 될거다’고 한다.

결론은 소스제어 컨트롤(Source Control)은 개인이 아무리 좋고 훌륭한 소스제어라고 생각하더라도 다른 사람들은 그렇게 생각하지 않을 수 있고, 선택에 있어서 다수의 의견에 귀 귀울이는 것이 좋을 것 같다.

I think, the statement

everyone hates it except me

makes any further discussion waste: when you keep using Git, they will blame you if anything goes wrong.
Apart from this, for me Git has two advantages over a centralized VCS that I appreciate most (as partly described by Rob Sobers):
automatic backup of the whole repo: everytime someone pulls from the central repo, he/she gets a full history of the changes. When one repo gets lost: don’t worry, take one of those present on every workstation.
offline repo access: when I’m working at home (or in an airplane or train), I can see the full history of the project, every single checkin, without starting up my VPN connection to work and can work like I were at work: checkin, checkout, branch, anything.
But as I said: I think that you’re fighting a lost battle: when everyone hates Git, don’t use Git. It could help you more to know why they hate Git instead of trying them to convince them.
If they simply don’t want it ’cause it’s new to them and are not willing to learn something new: are you sure that you will do successful development with that staff?

Does really every single person hate Git or are they influenced by some opinion leaders? Find the leaders and ask them what’s the problem. Convince them and you’ll convince the rest of the team.

If you cannot convince the leaders: forget about using Git, take the TFS. Will make your life easier.


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 이성훈 2018.05.10 14:53 Address Modify/Delete Reply

    분산제어 서버를 이용하면 프라이빗 블록체인과 차이가 없는건가요..?!

[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [1/2]

[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [2/2]





 
예전에 인터넷에서 자료를 찾는 중에 Team Foundation Server를 무척 혐오한다는 사람의 글을 읽게 되었다. 매우 잘못된 정보로 Team Foundation Server와 Visual Studio를 바라보는 것을 매우 안타깝게 생각한다. 이 글을 작성된 지 1년 정도 되었는데, 필자는 오늘에야 비로서 이 내용을 바로 잡고자 한다.

필자는 Microsoft 제품과 직접적으로 관련되지도 않았고, 더 이상 Microsoft MVP도 아니다. 그러므로 필자의 답변은 최대한 중립적인 입장에서 작성하였다. 물론, 필자는 Team Foundation Server를 사용한다. 하지만, 반드시 Team Foundation Server만 사용하지는 않는다.

그리고 글의 작성자는 Team Foundation Server의 기능과 Visual Studio IDE 기능을 모두 Team Foundation Server의 문제로 지적하고 있다. 이런 툴의 기능에 대한 혼돈이 있어 필자의 답변 또한 편의상 글 작성자의 의도에 맞게 Team Foundation Server로 통일하였다.

아래의 원문의 글을 작성하신 분의 글은 검은색이고,
필자가 답변한 글은 어두운 붉은 색으로 표시하였다.




원문 : 
http://imjuni.tistory.com/464 


 

단순한 거부 반응이 아니라 왜 TFS를 쓰기 싫을까? 개인적으로 TFS를 정말 오랫동안 써보고 또 TFS를 이용하여 공동 작업을 해보기도 한 결과 TFS는 정말 사용해서는 안될 도구라는 사실을 지속적으로 느꼈고, TFS를 제발 쓰지 않았으면 하는 생각을 계속 하게 되었다. 하지만 TFS는 생각보다 사용되는 곳이 많다. 그 이유는 가장 적은 비용으로 ALM 도구를 도입할 수 있다는 것 때문에 TFS를 도입하게 된다. 그런데, 가장 큰 문제는 ALM을 위해서 TFS를 도입하면 반대 급부로 TFS 때문에 개발자의 생산성이 저하되어 TFS를 도입한 비용만큼 개발자의 생산성이 저하된다. 그리고 제발 TFS가 가지는 ALM 기능이 VCS에 포함된다는 착각은 하지말자. Work item을 생성하거나 체인지 셋을 묶거나 추적하는 등의 기능은 ALM이면서 Issue Tracker이기 때문에 가능한 기능들이다. 이러한 기능은 Jira 또는 Code Beamer, Trac, Launchpad 와 같은 도구에서 제공하는 기능이지 SVN이나 Mercurial에서 제공하는 기능이 아니다. 정말 이런 대착각은 하지말자. 또한 Martin Fowler가 조사한 Vcs Survey에 따르면 TFS의 인지도는 0%다. 정말로 0%다. 링크를 따라가면 확인할 수 있다. 설마 Martin Fowler가 이름 없는 사람이고 그래서 그 조사를 믿을 수 없다는 이야기는 하지말자. Martin Fowler는 그 유명한 Refactoring의 저자이자, 애자일과 관련하여 아주 유명하신 분이다.


왜 TFS를 쓰면 안될까? 번역과 경험을 토대로 이 글을 써보자.

1. 크기: 이 부분은 MS가 참 미쳤다. SVN은 TortoiseSVN을 쓰면 15MB 많아야 20MB면 충분하다. 심지어 자체 웹서버가 내장된 tortoiseHg도 24MB면 충분하다. 웹서버도 없고 아무것도 없는 TFS는 Visual Studio Extension이라는 이유로 VS 필수 구성요소를 모두 설치해야 되기 때문에 200MB가 넘는다. 솔직히 요새 200MB면 껌이기 때문에 그리 부담도 되지 않지만 타 시스템과 비교하였을 때 10배 이상 크기가 큰 것은 확실하다. 넷북이나 가벼운 시스템에서 구동시키는 것은 확실히 부담되는 크기임이 자명하고, 부인해서도 안될 것이다. 뿐만 아니라 덩치가 크다는 것은 그만큼 메모리를 많이 소비한다는 뜻과 동일하다. TFS는 그만큼 가볍지도 않고, 용량도 많이 차지하는 거대 도구라는 것을 인정해야 한다.

SVN의 용량과 TFS의 설치 용량을 비교하는 것은 의미가 없다.

 
Team Foundation Server(이하 TFS)는 설치 시에 소스제어 기능만 선택적으로 설치할 수 없다. 그래서 설치 시에 모든 기능이 포함하여 설치하게 되는데, 이 중에는 소스제어, 작업항목, 빌드, 팀 탐색기(소스제어 클라이언트) 등이 모두 포함된다. 그리고 이 기능이 원활하게 동작하기 위해서 VC++ 재배포 패키지, .NET Framework 재배포 패키지 등이 설치 파일에 모두 포함이 된다.

 
마찬가지로 SVN을 소스제어로 이용하고, 그 외에 빌드, 이슈 트래킹 툴  등을 모두 갖추고 설치한다면 TFS보다 설치 용량이 더 많아질 지도 모른다.


그래서 용량이 크다는 이유로 TFS가 싫다는 이야기는 이야기의 논재에 벗어난 것 같다.





2. 읽기 전용 파일: 왜 이런 구조로 개발 되었는지 이해할 수 없지만 TFS에서 관리하는 모든 파일은 읽기 전용이다. 파일을 고쳤다고 하더라도 실제로 체크 아웃을 한 것이 아니라면 전혀 반영되지 않으며 이를 알 수 있는 방법은 Visual Studio 탭에 표시된 잠금 표시와 저장할 때가 되어서야 나오는 읽기 전용이므로 이를 해제해 달라는 말을 보았을 때다. 이 경우 일단 저장을 하고 다시 체크인을 한 뒤 다시 또 저장을 해야 한다. 만약 이 와중에 충돌이 발생하면 끔찍한 결과를 초래 한다. 읽기 전용 파일이 문제가 되지 않는다고 주장하는 사람은 빈번하게 충돌이 발생하는 환경에서 개발을 해보지 않은 것으로 판단 된다.

TFS의 소스를 파일을 내려받은 클라이언트의 파일은 읽기 전용이라는 점은 필자로 여러모로 불편한 점이 있다고 생각한다. SVN과 비교하자면 불편한 점이 확실히 맞다. 

 
TFS는 윈도우 탐색기나 커맨드 라인을 통해 파일을 수정하려 한다면 읽기 전용 파일이기 때문에 수정하여 저장할 수 없다. 이 경우 읽기 전용 파일 속성을 해제해 주어야 한다. 하지만, 수정하려는 파일을 체크인 하려고 한다면, 먼저 체크아웃을 해 주어야 한다. 체크 아웃을 하지 않으면 체크인 시에 수정된 파일로 간주하지 않기 때문에 변경 집합에서 제외되므로 체크인을 할 수 없다.

반면, SVN또는 기타 소스제어에서는 윈도우 탐색기 등에서 파일을 수정하면 알아서 체크아웃을 시키거나 체크아웃 과정을 자연스럽게 유도한다. 

이 부분에서 불만을 주장하신 분은 '일단 저장을 하고 다시 체크인을 한 뒤에 다시 저장을 해야 한다'는 방법은 잘 이해하기도 어렵거니와 잘못된 방법이다. 이 경우 필자가 이야기 한 것처럼 강제로 수정한 파일은 언제든지 다시 체크아웃을 한 후에 체크인을 하면 된다. 단, 특정 버전 받기를 하게 되면 모든 파일을 덮어씌우기 떄문에(Overwrite) 체크인 전에 특정 버전 받기를 실행하면 안된다. 물론 이런 경우는 극히 드물겟다. (최신 버전 받기는 변경된 파일만 덮어씌우므로 최신 버전 받기는 강제로 수정한 파일이 안전하게 수정된 내용으로 보존된다.)

하지만, 불만을 주장하신 분의 이야기 처럼 빈번하게 충돌이 발생하는 환경이라면 어떤 소스제어 솔루션을 사용하더라도 빈번하게 충돌이 발생하게 되어있다. 이런 충돌 상황을 빈번하게 겪어 충돌을 피할 수 있는 경험적인 감각을 익힐 수 있을 정도의 지능을 가진 사람이라면 대부분의 충돌이 발생하는 상황을 최대한으로 피할 수 있다.





3. 솔루션 파일 수정 무한 반복: 몇 가지 상황이 되면 이 경우를 만나게 된다. 예를 들면 VPN으로 사내 망에 접근할 때 TFS 서버 이름이 변경되는 경우 이다. 이 때 VPN으로 접근한 사람이 솔루션 파일에 TFS 이름을 바꾸면 나머지 사람은 그 솔루션 파일을 받은 뒤 다시 바꿔야 하고, VPN 작업자는 또 바꾸고, 이러한 무한 반복이 실행 된다. 또 다른 경우로는 솔루션 파일이 바인딩 되지 않은 경우 솔루션 파일을 바인딩 하기 위해서 솔루션 파일을 변경하고 다른 사람은 그 바인딩 정보를 솔루션 파일에 기록하기 위해서 변경하고 그러면서 자신에게 바인딩 하는 과정을 또 거치는 등 역시 무한 반복이 실행 된다. 발생하는 일 자체는 그리 짜증나지 않지만 무한한 반복으로 인해서 체인지셋 관리에 어려움을 겪게 된다. Subversion 또는 Mercurial은 근본적으로 이러한 일이 발생하지 않는다. 두 VCS에서 프로젝트 파일이란 단순히 관리가 필요한 텍스트 파일에 불과하기 때문이다.

이 부분은 글을 작성하신 분의 의견에 공감한다.


다만, SVN의 경우는 소스제어 바인딩 정보가 .svn 숨김 폴더에 저장되기 때문에 이런 문제가 발생하지 않지만, 폴더마다 .svn 숨김 폴더에 캐시된 데이터가 쌓이는 문제도 함께 가지고 있다. SVN 최신 버전에서는 폴더마다 .svn 숨길 폴더가 만들어 지는 문제를 최상의 폴더 한 곳에만 생기게 하도록 수정되었다고 한다.




4. .net 안쓰는 사람: Java 또는 PHP, Ruby, Python 등을 이용하여 개발할 경우 TFS로 인해서 얻는 반사 이익이 급격히 줄어든다. 솔루션 파일을 통한 간편한 프로젝트 추가 기능을 사용할 수 없고 디렉토리를 통채로 삽입할 경우 바이너리 파일이나 의미 없는 파일을 일일히 GUI로 제거해 주어야 한다. 반면 TortoiseSVN 또는 TortoiseHg는 Ignore list를 편집하여 간편하게 복수 파일을 관리하지 않을 수 있다. 또한 다른 도구와 다르게 비교 도구를 자체적으로 지정할 수 없고, 체인지셋 간 비교가 원활하지 않다. 이와 같은 단점으로 인해서 생산성이 저하 된다. 또한 Maven, Ant와 같은 오픈 소스 빌드 도구를 사용할 수 없고 MSBuild와 같은 도구만 사용가능하여 TFS 장점을 취하기 힘들다. 만약 Eclipse, Aptina 등과 같은 도구를 사용할 때는 2개의 IDE를 사용하거나 Teamprise를 사용해야 하는데 Teamprise는 MSDN Account가 있을 때 무료이다. Visual Studio Ultimate with MSDN 라이센스가 필요하다. 따라서 .net을 사용하지 않는 사람은 추가 비용이 발생할 수 있다는 것을 확실히 인지해야 한다.

필요 없는 파일의 확장자를 필터링하여 통채로 소스제어에 바인딩 또는 체크인할 수 있는 기능은 예전부터 TFS에 있는 기능이다. 그리고 비교 도구로 파일이나 체인지 셋, 폴더 등 비교하는 기능도 사용자가 별도로 설정할 수 있는 기능이 예전부터 존재한다.

그리고 라이센스 부분에서 TFS가 상용 솔루션인 점을 감안하면 당연히 클라이언트 라이센스 정책이 있다는 점은 당연하지 않을까?

이 부분도 다시 확인해 보시길...





5. Same Directory Archive: 사용자 디렉토리 경로와 TFS 경로를 일치 시키는 일을 한다. 사실 SVN과 Mecurial, Git와 같은 도구는 Point to Point, Central Repository의 특정 지점과 지점을 프로젝트로 연결함으로서, TFS 처럼 경로를 강제하지 않는다. TFS가 경로를 강제한다는 말은, Repository에 만들어진 Directory structure가 실제 사용자 Directory structure와 일치시킨다는 것이다. 일반적인 VCS에서는 프로젝트 단위로 연결하기 때문에 프로젝트 하위 Directory structure는 관리되지만 프로젝트 상위 Directory structure는 따로 관리하지 않는다. 관리하지 않더라도, VCS 자체에서 branch 별로 Directory를 만들거나 구조적인 관리가 가능하지만 사용자는 최종적으로는 프로젝트와 프로젝트가 연결되는데 반해 TFS는 프로젝트 상위, 하위 모든 Directory structure를 일치 시킴으로서 불편을 유발한다. 예를 들면, A, A', A'' 프로젝트가 있다고 가정하면 A'와 A''는 A 프로젝트 branch일 때 TFS는 관리자가 만든 구조로 세 프로젝트를 관리해야 하지만 SVN 또는 Mercurial은 A와 branch내부에 A'와 A''를 둘 수 있다. 개발자가 원하는 방식으로 프로젝트를 관리할 수 있다.

말씀하신 것처럼 소스제어의 폴더 구조를 반드시 따를 필요가 없다. 사용자가 작업영역(Workspace)를 이용하여 폴더 구조를 정의할 수 있다. 그리고 유용한 것 중, 공개 작업영역을 이용하면 누군가가 정의해 놓은 구조를 모든 사람이 공개 작업영역을 이용하여 같은 개발 구조를 가져갈 수도 있다.

이 부분도 다시 확인해 보시길...





6. 충돌 처리 미흡: 충돌이 일어날 때 TFS는 일반적으로 3가지 선택지를 준다. 다른 사람의 소스를 원복 하는 것, 내 소스를 원복하는 것, 자동으로 머지를 하는 것 3가지 선택지가 있다. 일반적으로 어떠한 도구라도 자동 머지는 믿을 수가 없고, 나 살자고 다른 사람이 작업한 결과물을 버리게 할 수 없기 때문에 내 소스를 버리게 된다. 이 경우 지금까지 작업한 것이 모두 사라지게 되는데 이를 방지하기 위해서는 Local Workspace를 제외한 또 다른 사본이 필요하게 된다. 이는 이중으로 머지를 하게 만드는 수고를 하게 함으로서 정말 고통 스러운 작업을 지속적으로 유발한다. 정말 이 과정에서 수없이 많은 충돌과 누락을 발생시키는데 도저히 이 방식을 용납하기 힘든 정도이다.

이렇게 고생하면서 충돌 처리를 하시는 점이 이해가 가지 않는다. 이런 소스의 버저닝 문제로 소스 제어를 사용하는데, 그 자체가 용납하기 힘들 정도이면 소스제어 기능을 충분히 활용하지 못하는 것 같다.




7. offline 상태에서 완벽한 무력화: 일반적으로 오프라인 상태에서 유효한 SCM은 분산 SCM인 Git, Mecurial을 제외하면 SVN도 유효하다고 보기는 힘들다. 다만, TFS와 SVN이 근본적으로 다른 점이라면, TortosieSVN을 이용한다면 어떤 파일이 수정되었는지 알 수 있다. 또한 작업 이전에 프로젝트를 모두 복사한 뒤 자유롭게 작업하고 그 결과물이 마음에 든다면 그 소스를 바로 커밋할 수 있다. 커밋한다면 실제 Repository에 반영된다. TFS로 동일작업을 해야 한다면 일단 사본을 만들고, 그 사본으로 작업한 뒤 원래 Local Workspace에서 수정한 파일을 "기억을 더듬어서" 일일히 Check out을 한 뒤 하나씩 복사해야 한다. 완벽하게 Check out이 끝난 뒤라면 통채로 복사해도 상관은 없지만 중요한 것은 Check out을 한 뒤 해야 하는 것이다. 만약 당신이 30개의 파일을 수정했다면 30번 Check out을 해야 한다. 만약 Git, Mercurial을 사용한다면 Local Repository에서 revision을 관리하며 작업을 지속하는 것이 가능하다.

TFS와 Visual Studio에서 온라인 상태로 바인딩된 소스제어가 오프라인으로 변경이 되고, 코드 변경 작업이 완료된 후 다시 온라인 상태로 전환이 되면 변경된 파일은 체크 아웃 상태를 유지한다. 그리므로 일일이 기억을 더듬어서 작업할 필요는 없다.

이 부분도 다시 확인해 보시길...





8. 비용: TFS는 단점만 가진 SCM이지만, 자체적으로 ALM 기능을 포함하고 있기 때문에 비용이 수반된다. ALM이 반드시 필요한 경우라면 가장 저렴한 비용으로 구축할 수 있지만 TFS를 사용함으로서 얻는 불이익이 ALM 도입 비용을 상회할 지 모른다. 또한 TFS 사용을 위해서 VS가 전혀 필요하지 않는 사람도 VS를 TFS 라이센스로 모두 구입해야 하므로 사실 비용이 썩 저렴하다고 보기 힘들다. 만약 Issue Tracker 또는 ALM이 필요하다면 Jira와 같은 도구를 도입하고 SCM을 따로 구축하거나 Trac + Mercurial, Launchpad + Mecurial 같은 솔루션을 사용하는 것이 현명한 방법이라 생각한다. 이를 통해서 VS가 필요없는 사람에게 TFS VS를 구입 해줄 필요가 없으므로 비용을 절감할 수 있고, 또한 VS 역시 TFS 버전으로 구매할 필요가 없으므로 비용을 절감할 수 있다. 심지어 SCM 서버도 리눅스 등을 이용하여 구축할 수 있으므로 서버 비용도 절감할 수 있다. (다만 리눅스 엔지니어를 채용하는 비용이 추가적으로 발생할 수 있습니다)

TFS 라이센스 부분에서 TFS를 사용하려는 사용자가 모두 Visual Studio를 구매할 필요가 없다. CAL(Client Access License)만 구입하면 된다.

그리고 오픈 소스를 이용하여 ALM 환경을 구성하는 것은 그 조직이나 그 사람의 자유이다. 그것이 관리하기 편하고, 사용자가 원한다면 오픈 소스를 사용하는 것도 좋은 방법이다. 다만, 오픈 소스를 이용하여 모든 ALM 환경이 구성된 경우, JRE 버전, 새로운 버전으로 업그레이드와 데이터 마이그레이션, 오류 등으로 자유 소프트웨어 진영에서 어떠한 지원도 받을 수 없을 것이다. 이런 점에서 상용 솔루션은 어떤 지원을 받거나, 책임의 소지를 확실히 구분할 수 있다.

이 부분도 다시 확인해 보시길...





 



Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 안들이 2013.01.11 02:25 Address Modify/Delete Reply

    일단 닷넷에서 자바로 넘어 온 입장해서 적자면..

    1. 윈도우 플랫폼이 너무 고가정책이다.
    어떤 걸 도입하든 MS제품으로 도배가 되는데 제품 라이센스 체계가 굉장히 복잡하고 비용또한 유닉스보다 저렴한 정도이지 리눅스의 무료(오픈소스)에 비하면.. 넘사벽입니다.

    흔히 유지비용을 MS에서 더 저렴하다고 하지만 리눅스기반에 오픈소스 제품군에 부분적으로 컨설팅이나 유료제품군을 사용하는게 훨씬 더 저렵합니다.

    2. 사용자 수가 절대적으로 적고 참고할 만한 자료가 없다.(멘토 부족..)
    라이센스 정책이 고가에 인증부분이 강화되면서 불법라이센스가 거의 사라졌지만 비례적으로 관련 정보나 생태계도 같이 사라지고 있습니다.
    (최근 윈도우 서버 2012가 출시 되었지만 네이버에서 검색해보면 아직도 MS에서 출시 이벤트를 한건지 출시 이벤트 정보만이 C&P 하듯이 몇페이지외에 실질적인 정보가 거의 없습니다..)

    3. 리눅스/자바/이클립스 체계가 충분한 개발장비가 되고 있다..
    VS 2012를 잠깐 써본 적이 있는데.. 정말 좋아졌더군요.(사실 경쟁자가 없을정도로 잘 만들었죠.. 무겁다는 것만 빼면..) 하지만 리눅스든 윈도우든 맥이든 자바에 이클립스만 있어도 충분히 개발환경을 만드는데 충분하더군요. 버전업이 되었다고 자바버전이 올라갔다고 이클립스를 갈아 치우지 않아도 되고..
    VS의 경우 이제 매년 갱신해야 하지요..(얼터밋이 1900만원이던가..매년..)


    안드로이나 애플이의 IOS 나 OSX 든 운영체재는 무료나 아주 저렴하게 풀고 개발환경도 무료나 저렴하게 풀고 플랫폼을 확산하는데 주력하고 있는데.. 또 제품들도 충분히 나와주고 있고요.. 그런데 비싼 OS에 개발환경을 갖출 이유는 없겠지요..자바로 만들어도 윈도우 대응도 되고요..-_-

    MS가 부활하려면 OS비용을 아주 낮은 비용으로 책정하고 (연 19800원? 이나 무료) 윈도우 스토어와 모바일 스토어를 통합해서 스토어를 통해서 수익을 적극적으로 만드는게 현실적으로 보입니다..
    하지만 MS는 포기하지 않겠지요.. 점유율이 떨어진 만큼 비용을 올려서 수익을 만들고 있으니까요.. 지금도..

  2. 안들이 2013.01.11 02:33 Address Modify/Delete Reply

    윈도우 블루(차기버전)가 무료정책이고 윈도우 서버도 비용이 실 웹서비스나 웹서버로 도입가능할 정도로 저렴해지고 비주얼 스튜디오가 10만원 이하로 책정 되면 다시 윈도우 플랫폼을 써보고 싶네요..

    (도대체 받지도 않을 기술지원은 왜 포함하는건지.. msdn 문서도 문서화 제공부분에서 필수적인 것인데.. 장점이라며 비싸게 책정되고 있는 msdn 구독료는 이해하기 힘드네요..-__- 요즘 게임업체들도 모바일로 전환하거나 외국으로 나가면서 리눅스 플랫폼에 오픈소스 제품군을 적극적으로 준비하는 업체가 많더군요.)

  3. 아름드리 2013.01.11 09:36 Address Modify/Delete Reply

    3번 항목의 .svn 숨김 폴더는 근래에 최상위 폴더에만 생성되도록 변경되었습니다.

  4. 공도 2013.01.13 08:42 Address Modify/Delete Reply

    7번에 덧붙여서, Git의 로컬 커밋과 개념이 다르지만 Shelve 기능을 활용하면 팀에 영향주지 않고 개인적으로 커밋하는 효과를 얻을 수 있죠. 몇 번이든지 Shelve Set으로 저장했다가 다시 복원했다가 하다가 메인 트리에 올릴 수 있을 때 체크인 하는 방식으로 쓸 수 있고 또는 아직 체크인 하기 전의 코드를 팀원이 리뷰하는 용도로 쓸 수도 있고요.

문제 발생

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

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

   

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

   

문제 해결

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

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

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

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

   

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

   

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

   

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

   

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

   

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

   

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

   

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

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

   

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

   

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

Posted by 땡초 POWERUMC

댓글을 달아 주세요

협업이 필요한 이유

최근의 소프트웨어 개발은 점차적으로 엔터프라이즈화 되어 가고 있습니다. 대용량/대규모화 되어가고 있는 현대의 소프트웨어 생태계에서 마치 새로운 트랜드로 자리잡고 있는 엔터프라이즈 2.0 이 자리를 잡고 그 규모를 넓혀가고 있습니다. 엔터프라이즈 2.0 은 Web 2.0 과 결합된 의미로써 즉, Enterprise social software(http://en.wikipedia.org/wiki/Enterprise_2.0) 라고 보아도 크게 의미는 다르지 않습니다.    

엔터프라이즈 소프트웨어는 대용량/대규모/보안 등의 핵심 키워드로 그 아키텍처가 매우 민감한 부분이기도 합니다. 하지만 엔터프라이즈 2.0은 기존 엔터프라이즈에 개방/공유 등을 강조하면서 바로 협업과 맞물리는 부분이기도 합니다. 그리고 이러한 움직임은 국가적인 차원의 거버먼트 2.0(http://blog.powerumc.kr/252)과 매우 유사하기도 합니다.    

즉, 중요한 것 중 현대의 소프트웨어 개발은 더 이상 폐쇄적인 환경을 거부하며, 최소한의 자원과 리소스를 아끼고, 남은 자원을 극대화하여 새로운 가치를 생산하고자 한다는 것입니다. 단지, 소프트웨어 개발은 개발자 역량만 훌륭하다고 되는 것이 아니며, 개발자간의 원활한 커뮤니케이션, 각 팀과의 원활한 커뮤니케이션, 더 나아가 조직과의 커뮤니케이션과도 연관 고리가 존재하게 됩니다.    

콩 심은 곳엔 콩이 나고, 팥 심은 곳엔 팥이 나야 하지만, 실제 프로젝트에서는 콩 심은 곳에 팥이 나기도 합니다. 협업을 하다 보면 협업 자체가 어려운 것이 아니라, 사람을 대하는 것이 가장 어렵다는 것을 느낄 수 있을 것입니다. 그래서 애자일(Agile) 한 방법론이 최근 팀과 조직에서 관심의 대상이 되는 것과 같은 이치입니다. 애자일 방법론을 잘 하기 위해서는 사람과 인간성을 이해하고 신뢰를 쌓는 것이지만, 그렇게 애자일하게 너그러운 사람과 팀, 조직은 그리 흔하지 않습니다.    

그렇다면 뭐가 문제일까요? 사람을 대하는 것이 어렵고, 고로 협업을 하는 것이 어렵고, 고로 전체 프로젝트를 수행하는게 어렵습니다. 개개인의 인격과 인간성을 존중하기엔 시간이 넉넉치 않을 뿐더러, 그들 간의 업무를 조율하는 것은 더 어려워지고, 점점 위태로운 프로젝트가 되기도 합니다. 물론 필자 또한 이런 문제의 발원지가 되기도 해보았고, 이것을 조율하는 입장도 되어 본 경험입니다.    

그럼 이미 답은 나왔습니다. 바로 "강제성" 을 부여하는 것입니다. 강제성이라고 하면 오히려 비 애자일하다고 할 수 있겠지만, 바꾸어 말하면 "당신 하나 때문에~" 애자일을 하는 것이 아니라는 것입니다. 가장 표준적이면서도 쉬운 방법을 통해 목표의 방향성을 가지고 간다는 것이 더 중요할 수 있기 때문입니다.

      

어떻게 커뮤니케이션을 할 것인가?

사람과 사람, 팀과 팀, 조직과 조직, 기업과 기업, 이들 간의 커뮤니케이션은 매우 다양합니다. 메신저, 이메일, 그 밖에 다양한 방법이 존재합니다.    

   

사람마다 선호하는 방법은 틀리겠지만, 개인적으로는 메신저야말로 가장 업무적으로 방해가 되는 커뮤니케이션 방법이라고 생각합니다. 언제나 급한 분들에게는 가장 좋은 커뮤니케이션 방법이 메신저가 될 수 도 있을 것입니다.    

제가 가장 좋아하는 커뮤니케이션 방법은 이메일입니다. 제가 이메일을 열람하고 싶을 때 보고 업무를 처리하면 되니까요. 하지만 이메일은 기록되고 보관되기 때문에 가장 책임감을 발휘해야 하는 커뮤니케이션 방법이기도 합니다. 하지만 요즘 스마트폰의 열풍으로 직장이든 가정이든 이메일을 볼 수 밖에 없는 현실이 되었죠^^;    

최근에는 SNS 와 같은 방법으로 커뮤니케이션을 하기도 합니다. 우리가 흔히 알고 있는 트위터(Twitter) 와 같은 Public SNS 도 존재하지만, 기업 내에서 사용할 수 있는 Private SNS 도 있습니다. 간단 명료한 메시지라는 강점으로 최근 유행하는 방식이기도 합니다.    

 

Team Foundation Server 의 구성 요소를 통한 커뮤니케이션

Team Foundation Server(이하 TFS) 는 단독적으로 사용할 때 보다 여러 가지 구성 요소를 갖출 때 비로소 가장 효과적인 커뮤니케이션 방법을 제공해 줍니다.    

최소한으로 TFS 는 SQL Server 를 필요로 하며, SQL Server 는 TFS 를 통해 소스 제어(Source Control), 리포팅(Reporting) 서비스를 제공해 줍니다. Team Foundation Server 를 사용하는 목적으로 SQL Server 라이선스를 일부 무료로 제공하기 때문에 가장 저렴한 비용으로 커뮤니케이션을 할 수 있는 방법입니다.

이를 이용하여 최소한으로 이행할 수 있는 여러 가지 기능이 있습니다.

  • 소스 제어(Source Control)
  • 소스 코드 브랜치(Branch)
  • 리포팅 서비스 및 데이터 웨어하우스(Reporting Services and Data Warehouse)
  • 일부 오피스(Office) 제품 연동

       

   

하지만 위의 방법으로는 조금 부족한 감이 있습니다. 마찬가지로 Team Foundation Server 를 사용하게 되면, SQL Server, Sharepoint Server 의 일부 라이선스를 무료로 제공하기 때문에 더욱 효과적인 커뮤니케이션 인프라를 구축할 수 있습니다. 특히 SharePoint 는 팀 포털과 문서 관리의 이점 뿐만 아니라, 팀 워크플로우를 개선할 수 있는 다양한 방법을 제공합니다. 특히 큰 규모에서는 의사 결정권이라는 막강한 권한이나 프로세스가 존재하게 되는데, SharePoint 는 이러한 워크플로우를 상당히 효과적으로 개선할 수 있는 솔루션이기도 합니다.

  • 소스 제어(Source Control)
  • 소스 코드 브랜치(Branch)
  • 리포팅 서비스 및 데이터 웨어하우스(Reporting Services and Data Warehouse)
  • 다양한 오피스(Office) 제품 연동
  • 팀 포털, 문서 관리, 팀 프로세스 개선

   

최근 가상화(Virtualization) 를 기반으로 클라우드 서비스가 매우 큰 개발 및 비즈니스 영역으로 자리잡고 있습니다. 소프트웨어 가상화는 물론이고 우리가 흔히 알고 있는 하드웨어 가상화 등 이러한 서비스 가상화를 통해 이전에는 상상하기 힘들거나 환경을 구성하기 힘든 영역까지 모두 커버하고 있습니다. Microsoft 에서는 이것을 가리켜 Dynamic IT 라고 칭하고 있습니다.

   

그 중, System Center 솔루션은 매우 다양한 역할을 수행합니다. 가상화 인프라와 서버 모니터링을 위해 다양한 솔루션은 아래와 같습니다.

솔루션

설명

SCVMM

(System Center Virtual Machine Manager)

물리적인 서버 또는 가상화의 서버를 관리, 배포, 최적화하는 솔루션이다. Hyper-V 또는 VMWare 등 여러 가상화 플랫폼을 지원한다.

SCOM

(System Center Operation Manager)

데이터센터의 운영을 중앙 관리를 위한 솔루션이다. 분산되어 있는 서버의 상태, 성능 정보, 구성 또는 보안 상태를 감지한다. 윈도우 운영체제와 리눅스(Linux), 유닉스(Unix) 운영체제 의 리소스나 그 하위 구성요소를 모니터링 할 수 있다.

SCCM

(System Center Configuration Manager)

운영체제 배포, 보안 패치, 서버/데스크탑 정책, 모바일 정책 등 총체적인 서버 및 클라이언트의 구성을 관리하는 솔루션이다. 기업의 네트워크 내의 모든 컴퓨터를 대상으로 강제 업데이트, 필수 구성 요소 등을 정책적으로 강제화 할 수 있다.

   

SCVMM(System Center Virtual Machine Manager) 은 가상화를 통한 동적 서버 관리, 가상화를 통한 유지 관리 계획, 가상화를 통한 테스트 및 개발 환경 의 작업을 관리하고 단순화 위한 가상화 관리 솔루션입니다. 가상화 서버를 관리를 용이하게 하고, 물리적인 서버를 가상화로 쉽게 전환하거나 가상 호스트에 여러 개의 물리적 서버를 통합할 수 있습니다.

특히 이 솔루션은 ALM(Application Lifecycle Management) 솔루션 중 Team Foundation Server 2010 에서 테스트 가상화를 사용하기 위해 필요한 구성 요소이기도 합니다.

   

SCOM(System Center Operation Manager) 는 분산되어 있는 데이터 센터를 통합 관리를 하며 윈도우 운영체제 뿐만 아니라 다양한 리눅스, 유닉스 기반의 운영체제를 지원합니다. 이 솔루션을 이용하면 특정 장애나 서비스 성능, 가용성을 보장하기 위해 자동으로 조치를 취하도록 할 수 있습니다.

   

SCCM(System Center Configuration Manager) 는 네트워크 인프라에 존재하는 클라이언트 컴퓨터, 서버 컴퓨터 등의 구성을 중앙에서 관리합니다. 예를 들어, 일부 클라이언트 사용자의 컴퓨터는 윈도우의 업데이트를 꾸준히 사용하지 않는 경우가 있습니다. 이러한 경우 강제적으로 업데이트를 수행하도록 정책적으로 관리를 할 수 있습니다. 그 밖에 윈도우 방화벽 설정, 자동 업데이트 및 백신 프로그램 등을 정책적으로 설치되거나 구성하도록 강제화 할 수 있습니다.

   

   

현재 협업을 위한 기본적인 기반 환경은?

단지, 필자가 오늘 하고 싶은 이야기는 여러분들에게 여러 가지 솔루션이 이를 대체할 것이라는 암시를 주는 것이 아닙니다. 단지 협업은 혼자만의 노력으로는 불가능 한 것이며, 이것을 뒷받침해 줄 수 있는 도구가 있다는 것에 감사할 뿐입니다.    

대부분의 우리나라 조직은 상하 수직적인 관계입니다. 일을 던져주고, 그것을 받고 일을 하는 수직적인 줄타기 방식은 작업의 결과를 매우 가시적이고 평가하기 쉬운 방법입니다. 그리고 이런 방식에 저 또한 매우 길들여져 있으며, 일을 수행하는 입장에서도 매우 수월합니다. 수행 결과를 보여주기도 쉽고, 처리하기도 쉽습니다.    

다만 수평적인 조직(절대적인 수평은 없을 것이지만)에서는 오히려 상하 수직적인 방식과는 다릅니다. 항상 중간 과정에 서로의 동의와 협력이 필요하며, 그 성과 또한 개인의 성과가 아닌 우리의 성과가 될 테니까요.    

하지만, 여러 조직과 기업이나 프로젝트에서 일을 해 본 경험으로, 절대적인 상하 수직적, 수평적인 조직은 없다는 것입니다. 그리고 필자 또한 어떤 것이 바람직한지 아직은 확신을 하기 어렵습니다. 다만, "그때 그때 잘~" 이라는 것밖에는 ^^    

팀워크(Team Work) 란 팀이 무너지지 않고 존재할 수 있는 가장 큰 힘을 발휘합니다. 반대로 팀 워크가 수년간 같은 방식이고 개선되지 않고 제자리에 머물러 있다면 썩은 우물과도 같습니다. 왜냐하면 시대가 변함에 따라 개개인의 커뮤니케이션 방식은 바뀔 것이며, 점차적으로 개선되어 지지 않는다면 팀 워크가 아닌 커뮤니케이션 자체의 문제의 한계에 부딪히게 될 것입니다.    

일단 오늘은 협업에 대해 썰을 풀어 보았습니다. 그리고 협업을 위한 많은 노하우를 여러분들에게 알려드리고 개선해 나가고자 합니다. 언제든지 불편한 내용이나 피드백을 주시면 참고하여 개선하고자 하도록 하겠습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 2010.07.18 12:23 Address Modify/Delete Reply

    비밀댓글입니다

  2. 2010.07.18 20:05 Address Modify/Delete Reply

    비밀댓글입니다

Team Foundation Object Model 을 이용하여 별도의 TFS Client 를 개발하는 경우가 종종 있습니다. 개발자라면 "Visual Studio 에 Team Explorer 가 있는데 왜~?" 라고 묻기도 하지만, 비개발자들 예를 들면, 관리자, 비즈니스 담당자들이 Team Foundation Server 에 접속하기 위해서는 Visual Studio 를 실행해야 합니다. 왜냐하면, Team Explorer 의 필수 구성 요소가 바로 Visual Studio Shell 이기 때문이죠.

Team Foundation Web Access 와 같은 제품이 있긴 하지만, TFS 를 사용해 보지 않은 사람은 사용법도 익히기 어려울 뿐만 아니라 특정한 프로세스를 강요할 수 없는 이유이기도 합니다. 이런 이유로 개별적인 TFS Client 제품을 선호하는 경우가 있기도 합니다.

Team Foundation Client (예를 들면 Team Explorer) 등은 Visual Studio 에 매우 종속적인 제품입니다. 그래서 TFS Server 의 정보를 Visual Studio 하위의 레지스트리에 관리합니다.

   

아래는 그 예를 보여주는 오류 시나리오 입니다.

오류 발생 조건

1. Visual Studio 에서 특정 TFS 서버를 제거한다

2. 독립 TFS Client 에서 TFS 에 접속이 안된다.

   

오류 해제 조건

1. Visual Studio 에서 특정 TFS 서버로 연결한다

2. 독립 TFS Client 에서 TFS 탭 접속이 된다.

   

오류가 발생하는 예외 메시지 입니다.

처리되지 않은 예외: Microsoft.TeamFoundation.TeamFoundationInvalidServerNameException: TF30076: 제공한 서버 이름 dxtfs2008a이(가) 검색된 서버 URI와 일치하지 않습니다. 서버 이름이 올바른지 확인하십시오.

위치: Microsoft.TeamFoundation.Client.TeamFoundationServer.GetUriForName(String name)

위치: Microsoft.TeamFoundation.Client.TeamFoundationServer.get_Uri()

위치: Microsoft.TeamFoundation.Client.CheckAuthenticationProxy..ctor(TeamFoundationServer server)

위치: Microsoft.TeamFoundation.Client.TeamFoundationServer.Authenticate(Boolean useProvider, ICredentialsProvider provider)

위치: Microsoft.TeamFoundation.Client.TeamFoundationServer.EnsureAuthenticated()

위치: ConsoleApplication1.Program.Connection() 파일 C:\Users\엄준일\Documents\Visual Studio 2008\Projects\TFSSample\ConsoleApplication1\Program.cs:줄 43

위치: ConsoleApplication1.Program.Main(String[] args) 파일 C:\Users\엄준일\Documents\Visual Studio 2008\Projects\TFSSample\ConsoleApplication1\Program.cs:줄

22

계속하려면 아무 키나 누르십시오 . . .

   

위 문제를 해결하기 위해서는 반드시 서버 주소가 팀 탐색기에 등록이 되어야 합니다. 이는 곧 팀 탐색기에 등록이 되어야 한다는 말이며, 이는 Visual Studio 관련 레지스트리에 등록이 되어야 한다는 의미입니다.
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers

위의 레지스트리에 TFS 서버 주소를 넣어주시면, 독립 TFS Client 에서도 잘 접속이 되는 것을 확인할 수 있습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

Configure Team Foundation Build Service 에서 Start Wizard 를 클릭합니다.

   

아래는 Build Service 설치 안내 페이지 입니다. 다음을 클릭합니다.

   

Team Build 를 수행한 Team Project Collection 을 지정해야 합니다. Browser 를 클릭하여 Team Project Collection 을 선택합니다. 만약 Team Foundation Server 와 연결되지 않은 상태일 경우 Team Foundation Server 와 연결해야 합니다.

   

   

기본 설정대로 Recommended 를 선택하고 다음을 클릭합니다.

   

Team Build 를 수행할 계정과 포트를 입력합니다. 필자는 TFSBUILD 계정으로 사용하였고, 환경에 따라 NETWORK SERVICE 등으로 사용하셔도 됩니다.

   

모든 설정이 완료 되었고, Verify 를 클릭하여 Team Build 환경을 점검합니다.

   

모든 점검이 완료되면, Configure 를 클릭하여 설치를 진행합니다.

   

아래는 Team Foundation Build Service 설치가 완료된 화면입니다.

   

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

이전 Team Foundation Server (이하 TFS) 를 이용하여 통합 소스 관리 프로젝트를 수행한 적이 있습니다. TFS Object Model 이 참 잘 되어 있기 때문에 특별한 레퍼런스 없이도 쉽게 API 를 제어할 수 있었습니다. 허나 이상하게 Shelve(보류 기능) 과 관련하여 한참을 삽질을 한 적이 있는데요, 지금에 와서도 왜 이런지 이해할 수 없는 문제이기도 합니다.

다른 TFS Object Model 객체에서도 이러한 도메인 네이밍과 관련된 룰이 모두 통일되어 있다면 그냥 '그런가부다!!!' 할텐데, Shelve 에서만 이러한 문제가 발생한답니다. 이건 뭐~

var vcs                        = GetVersionControlServer();
var sourceController        = ObjectFactory.CreateObject<ISourceController>();
var workspace               = vcs.GetWorkspace(checkoutFilePath);

Shelveset set        = new Shelveset(vcs, title,
owner);
set.Comment        = description;

PendingChange[] pendingChanges = workspace.GetPendingChanges(checkoutFilePath, RecursionType.None);
workspace.Shelve(set, pendingChanges, ShelvingOptions.None);

   

오류 내용은 아래와 같습니다.

테스트 메서드 TestProject.TfsControllerTest.SaveShelvesetTest에서 예외를 throw했습니다. Microsoft.TeamFoundation.VersionControl.Client.VersionControlException: 다른 사용자가 소유한 보류 집합을 만들 수 없습니다.

Microsoft.TeamFoundation.VersionControl.Client.Workspace.ShelveInternal(Shelveset shelveset, PendingChange[] changes, ShelvingOptions options)

Microsoft.TeamFoundation.VersionControl.Client.Workspace.Shelve(Shelveset shelveset, PendingChange[] changes, ShelvingOptions options)

GConfigurationAssistant.SourceControl.TfsController.SaveShelveset(String title, String description, String owner, String checkoutFilePath) : C:\DxTFS2008\GMarket\GConfigurationAssistant\SourceControl\TfsController.cs: 줄 158

TestProject.TfsControllerTest.SaveShelvesetTest() : C:\DxTFS2008\GMarket\GConfigurationAssistant\TestProject\TfsControllerTest.cs: 줄 185

이런 코드가 있을 때, 빨간색의 owner 는 반드시 DOTNETXPERT\XXX 와 같은 계정 형태로 지정해 주어야 합니다. 만약 xxx@dotnetxpert.com 와 같은 사용자 계정은 맥 없이 Shelve 할 수 없다는 오류가 발생한답니다. 뭐 여기까지면 이해하겠습니다만… 쩝...

더 이해할 수 없는 건 dotnetxpert\xxx 처럼 도메인명과 계정명의 대소문자가 틀려도 오류가 난답니다. 줸장~

사소한 문제일 수도 있지만, 풀리지 않는 미스테리인지, 아니면 명백한 TFS Object Model 의 버그인지...

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 2009.10.23 11:47 Address Modify/Delete Reply

    비밀댓글입니다

에피소드

오래 전 집 컴퓨터를 서버로 운영하면서 Virtual Server 를 이용하여 Team Foundation Server 를 구성하였습니다. 3-Tire 로 구성된 Team Server 는 Windows Server 2003 에서 2008 로 업그레이드를 하였고, Virtual Server 는 Hyper-V 로 교체를 하기 위해 Team Foundation Server 의 데이터베이스를 백업을 해두고 간직해 두고 있었습니다.

사실 Team Foundation Server 를 사용하면서 손에 익으면 익을수록 정말 잘 만든 ALM 솔루션이라는 것을 느꼈지만, 이번에 그 환상은 홀딱 깨지고 말았습니다. 속내를 알면 알수록 잘된 것인지 잘못된 것인지는 현기증이 날 정도로, 고리타분한 구석이 상당히 많기로도 유명합니다. 예를 들어, 소스 제어에서 체크인을 할 수록 데이터베이스는 기하급수적으로 늘어나기도 합니다. 실제로 지난 프로젝트에서는 갑자기 Team Foundation Server 의 운영이 중단되었는데, 그 원인은 바로 하드 디스크의 용량이 부족한 탓이었답니다. Tracking 을 위해 어쩔 수 없다라고 쳐도 데이터베이스의 용량 증가는 무지막지할 정도로 빠르게 진행되기도 합니다. 그 밖에, 도메인 계정을 삭제를 하면 엑세스가 정상적이지 못한 문제 등도 발생하기도 합니다.

각설하고, TFS 의 데이터베이스 백업 파일만 달랑 남은 상황에서 다른 것은 몰라도 소스 코드만은 반드시 건져야 할 상황이 닥쳤습니다. 왜냐하면 제가 만든 소프트웨어 들이 모두 TFS 데이터베이스 백업 파일에 모두 존재했기 때문이죠. TFS 데이터베이스 백업 파일을 복원하고 데이터베이스만으로 소스 코드를 취득하려고 했으나 쉽지 않았습니다.

그 이유는, 소스 제어 데이터베이스의 소스 코드는 GZIP+(암호화?)+Encoding 되어 있습니다. Team Foundation Server 의 소스 코드의 텍스트를 GZIP 압축하는 것은 익히 알고 있었으나, 실제 복원하는 과정에서는 추가적인 알고리즘이 적용이 되어 있어 이것을 복원할 좋은 방법은 없어 보입니다. Reflector 로 코드를 거꾸로 분석부터 해보려고 했지만, 지름길이 아닌 것을 직감하고 진작부터 시도하지는 않았답니다.

또 하나, 사용자 계정으로 체크인 된 소스 코드는 TFS 계정 정보와 매핑이 되기 때문에 무작정 복원했다가 다시 처음부터 다시 복원을 해야 하는 낭패를 볼 수 도 있습니다.

아래는 복원하는 모든 과정을 설명하지 않고, 일부 시행 착오를 격은 부분만 설명하니 주의하시기 바랍니다.

   

새로운 도메인과 컴퓨터에서 복원하기

우선 Virtual Server 에서 가동 중이던 가상 서버는 데이터베이스만 백업 받아놓은 상태로 모두 지워버렸습니다. ㅡ,.ㅡ 만약 같은 도메인과 컴퓨터라면 백업은 크게 문제가 될 것이 없었지만, 제가 처했던 상황은 생각보다 중대한 상황이라는 것을 뒤늦게 알게 되었습니다.

우선 친절하게 MSDN 에서는 이 과정을 잘 설명해 주고 있습니다.

Team Foundation Server 데이터 백업 복원

http://msdn.microsoft.com/ko-kr/library/ms253080(VS.80).aspx

   

방법: 하드웨어 구성에서 다른 하드웨어 구성으로 Team Foundation Server 이동

http://msdn.microsoft.com/ko-kr/library/ms404869(VS.80).aspx

   

계정의 SID 매핑 하기

우선 데이터베이스의 .bak 파일을 복원합니다. 일부 데이터베이스는 동시에 복원되는 것을 추천하기 때문에, 되도록이면 한꺼번에 데이터베이스를 복원하시면 됩니다.

아래의 Command Line 과 같은 폴더에 TfsAdminUtil 를 실행해보면 엑세스 오류가 발생합니다.

 

만약 위와 같이 데이터베이스 엑세스 오류가 발생하면 아래의 절차를 수행하여, [TfsIntegration].[dbo].[tbl_database] 테이블의 servername 컬럼에 자신의 컴퓨터 이름으로 변경해 줍니다.

 

참고 자료

Server Restore

http://social.msdn.microsoft.com/Forums/en-US/tfssetup/thread/c8d49d80-5966-42de-8115-efc23eedf554

그리고 다시 TfsAdminUtil Sid 를 실행하면 아래와 같은 결과가 나오며, 정상적으로 데이터베이스에 엑세스 할 수 있습니다. 이제 이전 서버의 도메인의 계정과 신규 서버의 도메인 계정을 TfsAdminUtil 로 사용자 매핑이 완료될 때 까지 반복해 주시면 됩니다.

TfsAdminUtil - Team Foundation Admin Utility

Copyright (c) Microsoft Corporation. All rights reserved.

   

Account Name Found Equal to Windows SID

--------------------------------------------------------------------

POWERUMC\Episode2 False False

POWERUMC\episode3 False False

POWERUMC\umc False False

POWERUMC\episode1 False False

POWERUMC\TFSSETUP False False

POWERUMC\TFS2008 False False

POWERUMC\TFSService True False

POWERUMC\TFSReports False False

POWERUMC\Admin False False

 

사용 권한이 유효하지 않을 때

기존에 데이터베이스의 스키마는 이전 TFS 가 설치된 도메인의 TFSService 계정의 스키마이므로, 신규 서버로 도메인을 이전하였다면 TFSService 계정의 데이터베이스 스키마는 계정의 SID 가 달라지게 되므로, 더 이상 유효하지 않게 됩니다. 사실 이 부분에서 시행 착오를 많이 겪었던 것으로 기억합니다.

우선 백업을 복원한 데이터베이스의 TFSService 사용자 계정과 스키마를 삭제하고, 아래와 그림과 같이 관리->로그인 에서 다시 매핑을 하면 됩니다.

 

그리고 로그인에서 사용자 매핑으로 복원된 모든 데이터베이스에 사용자와 스키마를 매핑합니다.

 

팀 탐색기에서 사용 권한 문제

여기 까지 잘 따라왔다면 이제 Team Explorer 를 통해 Team Foundation Server 에 접속해 보면, 아래와 같이 권한 관련 문제가 발생합니다.

 

이러한 경우 TfsSecurity 명령 도구를 이용하여 해결 할 수 있습니다. 하지만 아래와 같은 오류가 발생하는데, RunAS 명령으로 인증된 계정으로 명령을 실행하면 가능할 것으로 예상이 됩니다.

 

참고 자료

No user is licensed

http://social.msdn.microsoft.com/forums/en-US/tfsadmin/thread/01fe1307-abd8-4d65-9f17-3a428f4431e3/

현재까지 성공했다면 적어도 TFSService 계정으로 Team Foundation Server 에 접속을 할 수 있습니다. 드디어 Team Explorer 로 소스 제어의 최신 소스 코드를 다운로드 받을 수 있게 되었습니다. ^___^

Posted by 땡초 POWERUMC

댓글을 달아 주세요