개발의 신개념, Visual Studio 2005 맛보기

새로운 제품을 내놓을 때마다 세상을 떠들썩하게 하는 MS가 VS.NET 2003 이후 2년 만에 새 버전의 비주얼 스튜디오(Visual Studio, 이하 VS)를 내놓고 있다. 사실 일선의 개발자들은 다 아는 사실이지만 VS의 6.0 이후 버전들-즉 VS.NET 및 VS.NET 2003-은 그렇게 큰 호응을 받지 못했다.

물론 VS.NET 2003은 닷넷 프레임워크를 지원하는 managed code를 사용하고 인터페이스나 도구 등에 여러 가지 새로운 기능들을 추가했지만 그것만으로는 부족했다는 생각이 든다. 누군가 얘기했듯이 개발자는 이런 면에서 의외로 보수적으로, 새로운 버전이 어지간히 좋지 않으면 웬만해서는 자신의 손에 익은 도구를 바꾸려 하지 않는다.

VS.NET은 이런 이유로 인해 덩치는 크고 구동하기에는 무겁지만 큰 실익이 없는 제품으로 간주되어 1998년 발표된 VS 6.0을 아직도 가장 많이 사용하고 있는 것이 현장의 분위기인 것이다. 이것은 VS6.0이 그만큼 훌륭한 패키지이기 때문이기도 하다. 거의 10년이 다 되어가는 제품이 아직도 활발하게 사용된다는 점을 생각하면 개발도구가 그 동안 별로 진화하지 않은 것 같은 기분이 들기도 한다.

하지만 이번에 발표되는 비주얼 스튜디오 2005(이하 VS2005)는 이런 상황을 바꾸기에 충분한 파워를 지니고 있다. 어떤 면이 그렇게 강력한가? 라고 묻는다면 여러 가지 대답을 할 수 있겠지만 필자라면 이렇게 대답하겠다. VS2005의 최대 강점은 팀시스템이다.

왜 팀 시스템인가?

이전까지의 VS들을 살펴본다면 정도는 다르지만 어디까지나 ‘개발도구’라는 인상이 강했다. 실제로 비주얼 스튜디오를 사용하다 보면 포함된 Visual C++, Visual Basic, SQL Server등의 패키지를 이용해서 Win32에서 원하는 모든 개발 업무를 거의 커버하는 일이 가능했다. 거기에 풍부한 도움말과 예제까지 포함하는 MSDN이 같이 들어있으니 개발자 입장에서는 특별히 다른 패키지를 구입하지 않아도 VS만 갖고 있으면 개발에 필요한 모든 도구를 한번에 갖게 되는 셈이다.

말하자면 MS는 운영체제를 쥐고 있다는 것을 무기로 개발자들의 개발 환경을 표준화한 셈인데 이것은 MS의 시장 지배력과 독점을 더욱 공고히 한다는 문제점이 있지만 실질적으로 개발자에게는 상당한 이익을 가져다준다. 개발 환경이 표준화되었다는 것은 다른 개발자와 협업하기가 더 쉬워지며, 자료도 더 많이 풍부하게 찾을 수 있다는 의미이다. 개발자 커뮤니티에서 답을 찾는 것도 더 수월해질 것이며 관련 서적도 더 많이 발간된다.

하지만 이전 버전의 VS는 어디까지나 ‘개발자 개인’이 사용하는 개발도구였다. 최근의 소프트웨어는 아주 복잡하고 많은 기능을 지원해야 하기 때문에 혼자서 작업하기는 어렵다. 이런 경우 불가피하게 팀작업을 해야 하는데 그러기 위해서는 일정관리, 이슈 트랙킹, 소스 관리 등 여러 가지 별도의 도구들이 필요해진다. 물론 VS에 Visual Source Safe가 포함되어 있기는 했으나 이것은 프로젝트 관리의 가장 기본적인 부분인 소스 관리만을 해주는 것에 불과했다.

VS2005는 이제 단순한 개발도구에서 벗어나 이러한 팀작업을 하는데 필요한 도구와 방법까지 모두 제안하고 있는 것이다. 최근에 많은 지침서와 텍스트북들이 나오고 있지만 그래도 여전히 프로젝트 관리는 어렵다. VS2005에서는 특히 팀시스템에 관련된 패키지들을 모두 포함한 에디션을 Visual Studio Team System(이하 VSTS)이라 하는데 이 패키지는 마이크로소프트가 수년간 내부적으로 사용하던 협업도구들을 묶어서 내놓는 것이다. 말하자면 마이크로소프트가 그동안 사용했던 빠르고 기민한 개발방법론의 근간이 되는 패키지를 공개한다는 것이다.

즉 VS로 개발자의 환경을 통일했듯이 VSTS로 개발팀의 협업 환경도 표준화하겠다는 것이 MS가 VSTS에서 갖고 있는 비전이다. 만약 이것이 실현될 수 있다면, MS는 VS에 이어 또 다시 개발자들에게 절대적인 영향력을 행사할 수 있는 위협스러운 존재가 될 수도 있다.

VSTS의 빛과 그림자

하지만 VSTS에 장점만 있는 것은 아니다. VSTS를 제대로 사용하려면 Windows 2003을 OS로 사용하는 별도의 서버(Team Foundation Server, TFS)가 있어야 하며 여기에는 Active Directory를 위시해서 부하가 높은 소프트웨어를 다수 설치해야 한다. 당연히 이 서버는 최소사양만로도 상당한 스펙의 하드웨어를 요구하며 지금까지 사람들이 익히 알고 있듯이 MS 제품을 최소사양으로 구동시킨다는 것은 정신건강에 매우 좋지 않은 일이다.

필자가 테스트한 시스템은 P4 2.4GHz Dual CPU에 램을 2GB 장착했지만 이것도 모든 컴포넌트를 한번에 설치한다면 TFS에 충분한 스펙이라고 할 수 없다(진짜다). 또한 각 팀원들은 자신의 역할에 맞게 Visual Studio Team Suite를 자신의 PC에 구성/설치해야 하는데 Team Suite는 VS2005의 네 가지 버전 중 가장 무거운 것이다. 가격도 제일 비싸다. 거기다가 TFS서버의 라이선스와 클라이언트용 Team Explorer의 CAL은 사용자 수만큼 별도 구매해야 한다.

그러나 무엇보다도 가장 문제가 되는 것은, VSTS를 사용하기 위해서는 상당한 양의 선수지식이 요구된다는 사실이다. 일례로 beta 1의 VSTS에서 프로젝트를 시작할 때는 MSF for Agile development와 MSF for CMMI 둘중의 한 template를 선택해야 했는데-beta 2에서는 MSF for CMMI template가 삭제되었다-많은 개발자들은 당장 MSF와 CMMI라는 용어부터가 생소할 것이다.

MSF는 Microsoft Solution Framework의 약자로 MS에서 제안하는 개발을 위한 프로세스, 원칙 등을 포함하는 개발방법론(methology)이라 할 수 있으며 VSTS에는 4.0버전이 적용되었다. CMMI는 뭔가? CMMI는 Code Maturity Model Integration의 약자로 얼마전까지 개발 프로세스의 성숙도를 평가하는 기준이었던 CMM의 후신이다. 부연하자면 MSF for Agile Development는 전체 프로세스를 짧은 몇 개의 주기(Interation)로 나누어서 이를 반복하여 빠르게 개발하는 방식이며 MSF for CMMI는 CMMI 레벨 3에 부합하는, 기민하기보다는 좀더 엄격한 개발방식이다. 말하자면 적은 규모의 팀으로 날렵하게 개발하려면 전자가 적합하겠지만 어느 정도 크기를 갖춘 팀이 장기간 프로젝트를 운영하려면 후자를 선택하는 편이 낫다는 것이다.

이런 선수지식이 없는 상태에서 어떤 template를 선택해야 할지 판단할 수 있겠는가? 아니 아무거나 찍어서 한가지 template을 선택했다고 하더라도 과연 그 틀안에서 원활하게 프로젝트 관리가 가능할 것인가?

이건 단지 시작이고 한가지 예일뿐이다. Unit Test, Code Coverage, Work Item Tracking 등 많은 개발자들에게 익숙하지 않은 용어들이 계속해서 튀어나온다. 현재 서점에는 빠르고 효율적으로 프로젝트를 진행하기 위한 가이드북들이 많이 출간되어 있는데 이 책들을 읽고서 VSTS를 구동시켜보면 책에서 말하는 ‘발전된 개발방법론’이 VSTS에 고스란히 녹아있는 것을 알 수 있을 것이다. 뒤집어 말하자면 VSTS는 지금 얘기되고 있는 첨단의 개발방법론들을 툴 안에 그대로 녹여 넣어서 개발자들에게 이를 표준적인 프로세스로서 어느 정도 강제했다고 말할 수 있다. 이렇기 때문에 VSTS를 제대로 사용하려면 최소한 이러한 최신 개발방법론들에 대해서 익숙하지는 않아도 대강 알 수 있을 정도의 지식이 없어서는 안 된다.

하지만 역으로 생각해보면 VSTS를 도입하는 것은 그 동안의 비효율적인 개발 방식을 벗어던지고 빠르고 기민한 개발조직으로 탈바꿈하는 계기가 될 수도 있다. 앞서 언급한대로 서점가에는 효율적인 프로젝트 관리를 위한 서적들이 쌓여있지만 그 책들을 읽고나면 많은 사람들이 ‘아 참 훌륭한 말씀이야’라고 생각할 뿐 이제 어떻게 하면 효율적으로 개발할 수 있지?라는 질문에 대한 구체적인 답을 얻은 것 같지는 않다. 책에서는 CMMI에 레벨이 5단계까지 있고 각 단계마다 무엇이 필요한지에 대해서 설명하기는 하지만 실제 어떤 환경을 구축해서 프로세스를 개선해야 하는지에 대해서는 구체적으로 말해주지 않는다는 것이다.

VSTS는 새로운 개발 방법론에 필요한 여러 가지 도구들을 모두 포함하고 있으므로 VSTS에서 강제하는대로 따라가기만 하면 이러한 최신의 개발 방법론을 자연스레 사용하고 몸에 익히게 되는 것이다.

누가 사용해야 하는가?

이렇게 해서 VSTS가 기획된 의도와 장단점에 대해서 설명했다. 그러면 이 제품을 누가 사용해야 하는가에 대해서 말할 차례인데 솔직히 모든 사람들에게 필요하지는 않을 것 같다.

이미 말한 대로 VSTS는 상당한 양의 선수지식을 필요로 하고 “매우 무거운” 시스템이며 가격도 비싸기 때문에 필요한 조직이 아니라면 도입은 상당한 오버가 된다. 또한 VSTS를 사용한다고 하더라도 꼭 TFS를 써야 하는 것은 아니다.

물론 TFS를 VSTS Suite와 같이 사용할 때 얻어지는 무시 못할 장점들이 있지만 TFS를 설치할 때의 오버헤드, 네트워크 구성, 사용에 필요한 지식의 학습 등을 생각하면 작은 조직에서는 그로 인해 얻어지는 효율성보다 비용이 더 클 것 같다는 생각이 들기도 한다. TFS로 관리를 통합하지 않더라도 VSTS에는 VS Professional에 포함되어 있지 않은 여러 관리도구가 있기 때문에 작은 규모의 팀이라면 다른 도구 몇가지로 보조해가면서 충분히 효율적으로 사용할 수 있을 것 같다. VSTS에 포함된 발전된 도구들은 팀작업을 하지 않더라도 프로젝트에 많은 도움을 줄 수 있다.

여기서 잠깐 VS2005의 패키지에 대해 소개하자면 Express, Standard, Professional, Team Suite의 네 가지 에디션으로 구분되는데 Express가 가장 저렴하고 기능이 적은 버전이며 상위로 올라 갈수록 하위 버전의 기능을 모두 포함하고 거기에 +alpha가 되는 형식이다. 이 다음은 어떤 사용자에게 어떤 버전이 필요한가? 에 대한 내용이다.

- 학생, 취미 개발자, 초보 개발자

VS Express를 쓰면 된다. VS Express는 MS가 내놓은 Express 시리즈의 하나로 Visual Studio를 아주 컴팩트하고 가볍게 만든 것인데 각 패키지별 50MB 이하의 용량이며 Visual C++ Express, Visual Basic Express, Visual C# Express, Visual J# Express, Visual Web Developer에 SQL Server Express, 심지어 MSDN까지 포함하고 있다.

물론 여기서의 MSDN은 개발에 필요한 내용들만을 넣은 아주 간략한 것(역시 Express버전)이다. 전부 해도 CD 1장의 용량이 안된다. 싸다고 모두 비지떡은 아니지만-MS는 각 패키지를 별도 판매할 경우 무료로 배포되는 SQL Server Express를 제외하고 개당 $49 정도의 가격을 생각하고 있다고 한다-이 경우 가벼운 패키지와 저렴한 가격에 따르는 기능 미지원은 감수해야 한다는 점도 알아두기 바란다.

Visual C++ Express에는 심지어 MFC와 ATL도 포함되어 있지 않지만 그래도 managed code와 native code를 모두 작성할 수 있다.

- 1인 프로젝트를 할때가 많은 일반 개발자

VS2005 Standard를 사용하면 된다. 특히 웹개발이나 VB 관련한 업무가 많은 사람이라면 이 패키지가 최적이다. 만약 서버사이드에서 개발하고 디버깅해야 한다면 VS2005 Professional이 더 적합하다. 참고로 말하자면 VS2005 Standard나 VS2005 Professional에서도 Team Explorer의 CAL을 구입하면 TFS에 접속해서 프로젝트 관리기능을 사용할 수 있다. VS.NET 2003에서도 Team Explorer를 쓸 수 있지만 버전 컨트롤이나 WIT등, 제한된 사용만이 가능하다.

- 작은 규모의 팀

TFS를 사용하지 않는 VSTS Suite를 권장한다. TFS와 VSTS는 Exchange Server와 Outlook같은 관계이므로 TFS를 사용하지 않는다면 자동으로 강제되는 협업시스템은 작동하지 않지만 그래도 VSTS에 포함된 여러 가지 클라이언트 도구(Profiler나 테스트 도구등)들은 사용할 수 있다.

이 경우는 Visual Source Safe나 MS Project와 같은 별도 도구를 이용해서 필요한 만큼만 프로젝트를 관리하는 편이 좋다. TFS의 시스템에 대한 선수지식이 많이 필요하지 않다는 장점이 있으나 통합적으로 관리하지 않으므로 프로젝트 관리가 상대적으로 느슨해지는 단점이 있다. TFS를 쓰지 않더라도 VSTS Suite의 여러 패키지들은 닷넷 기반인 것들이 많으므로 쾌적하게 작업하려면 클라이언트의 하드웨어 사양은 상당히 높아진다.

- 중규모 이상의 팀

TFS를 사용하는 VSTS Suite가 좋다. TFS를 사용하므로 일정, Issue, 소스, 빌드등 프로젝트의 전반적인 내용들이 TFS에 저장되며 프로젝트에 대한 모든 것이 중앙집중적으로 관리될 수 있다. 관리자와 팀원들은 TFS의 시스템에 대해 최소한의 선수지식을 갖고 있어야 하며 개발 프로세스는 정해진 방식으로 어느 정도 강제된다.

참고로 VSTS의 project template의 하나인 MSF for Agile Development는 5~20명 정도의 팀에 맞도록 구성된 템플릿이라고 한다. 생각보다 큰 팀을 타겟으로 해서 만들어진 패키지는 아님을 알 수 있다.