소프트웨어 업계의 존경 받는 현자 로버트 L. 글래스는 “문제의 복잡성이 25% 증가하면, 소프트웨어 솔루션의 복잡성은 100% 증가한다”는 주장을 하였는데, 그것은 정말 진실이다. 아니, 후자의 100%라는 수치는 어쩌면 더 큰 숫자로 조정되어야 할 지도 모르겠다.

소프트웨어 개발 도구는 지난 수십 년 동안 개선되어 왔지만, 개발자의 노동 강도는 결코 줄어들지 않았다. 그 이유는 도구의 개선보다 훨씬 더 빠른 속도로, 해결해야 하는 문제점의 복잡성이 증가되었고 그에 따라 UI 및 로직의 복잡성 또한 증가되어 왔기 때문이다.

필자가 처음 프로그래밍을 시작했던 1983년에는 카세트 레코더를 보조 기억장치로 활용하고, 베이직과 어셈블리어를 이용하여 단순한 애플리케이션을 제작하는 정도였다. 개발 도구라고 해봐야 지금과 비교하면 형편없이 저급한 수준이었지만, 그 당시에 필요로 하는 애플리케이션을 만드는데 있어서는 그리 불편하게 느껴지지 않았다.

사실 그 이전까지만 해도 그 불편한 천공 카드(punch card)를 이용하여 프로그래밍 하였으니, 모니터와 키보드를 이용해 프로그래밍을 할 수 있다는 사실만 해도 얼마나 가슴 벅찬 일이었겠는가? 필자보다 먼저 1970년대에 프로그래밍을 시작한 한 IT 선배는 디버깅을 하기 위하여, 옥상에 천공 카드 수백 장을 일렬로 깔아놓고 뛰어다니며 보면서 디버깅을 했었다는 얘기를 하곤 했다.

세월이 흐르고 흘러 2005년 11월, 새로운 소프트웨어 시대를 대비하기 위한 개발 도구인 Visual Studio 2005가 출시된다. 이것은 차세대 UI를 제공하는 윈도우 비스타(코드명 롱혼)용 애플리케이션 개발을 본격적으로 지원할 수 있는 개발 도구라고 할 수 있다. 하지만 아직 윈도우 비스타는 출시되지 않았고, 윈도우 비스타를 위한 프레임워크들도 Visual Studio 2005에 충분하게 통합된 상태는 아니다. 그러므로 아직은 이것을 윈도우 비스타와 연관 지어 생각하기 보다는, 현재 곧바로 혜택을 받을 수 있는 .NET 2.0 기반의 개발 생산성 향상과 협업 환경의 대폭적인 개선의 관점에서 살펴보는 것이 좋을 것이다.

곧 정식 출시될 Visual Studio 2005의 가장 중요한 기능은 소프트웨어 개발의 복잡성을 감소시키기 위한 모델링 도구들이 대폭 늘어났다는 것이며, 또한 개발 팀의 커뮤니케이션과 협업을 증진시킬 수 있는 개발 환경을 제공한다는 것이다.

사실 Visual Studio 2005는 소프트웨어 개발과 관련된 아주 방대한 분야를 커버하고 있다. 과거의 제품이 주로 개발자를 위한 코딩 위주의 기능을 제공한 것에 비하여, Visual Studio 2005는 개발자뿐만 아니라 프로젝트 관리자, 아키텍트, 테스터가 필요로 하는 기능을 포괄적으로 제공하는 것을 목표로 삼고 있다. 그러한 이유로 Visual Studio라는 동일한 브랜드 하에 상당히 많은 도구들이 포함되어 있어서, 대형 프로젝트의 개발 경험이 부족하거나 소프트웨어공학에 익숙하지 않는 사용자들로서는 이해하는데 있어 어려운 점도 있을 것이다.

IT는 언제나 개발자들의 자기계발 수준을 훨씬 뛰어넘어 발전한다. 그것이 바로 우리가 일하는 소프트웨어 업계의 현실이다. 개발자들조차도 헷갈리고 이해하기 쉽지 않는 수많은 도구와 그것의 기능들. 하지만 새로운 혁신의 시기가 다가오고 있으므로, 정신을 바짝 차릴 필요가 있다. Visual Studio 2005 에디션은 익스프레스 에디션, 스탠다드 에디션, 프로페셔널 에디션, 팀 시스템으로 구분되며 각각의 에디션에는 여러 가지 도구가 포함되어 있다.

[그림1]은 Visual Studio 2005의 가장 최상위 에디션이라고 할 수 있는 Visual Studio 2005 Team System의 전반적인 구성 요소를 하나의 그림으로 표현한 것이다.

[그림1] Visual Studio 2005 Team System의 구성 요소 (출처: Microsoft TechEd 2005)

필자는 Visual Studio 2005가 제공하는 여러 기능을 쭉 나열하여 살펴보려고 하는 것은 아니다. 그것은 다른 필자가 맡은 섹션에서 제공될 것이다. 필자는 Visual Studio 2005에 대한 MS의 주장을 그대로 나열하는 것 보다는, 필자가 재해석한 소프트웨어공학적인 관점에서 이것을 사용해야 하는 이유에 대해 12가지로 정리하여 살펴보려고 한다.

팀 커뮤니케이션과 협업을 촉진시킬 수 있는 개발 환경의 구축은 필수적이다.
첫 번째로 살펴볼 이유는, 소프트웨어 프로젝트의 복잡성 증대에 따라 팀 커뮤니케이션과 협업을 촉진할 수 있는 개발 환경의 필요성이 그 어느 때보다 더욱 요구되고 있다는 것이다. 프로젝트는 점점 대형화 되어 가고 있고, 팀원들의 역할과 숫자도 늘어가고, 해결해야 하는 문제점은 더욱 복잡해지고 있다. 현대의 소프트웨어 환경에서는 다양한 이해관계자들간의 효과적인 커뮤니케이션이 무척 중요함에도 불구하고, 과거의 Visual Studio 제품은 인상적인 협업 도구를 제공해주지 못했다.

오늘날 소프트웨어 개발은 점점 더 어려워지고 있다. 또한 많은 경우, 폭주하고 통제 불능에 빠지는 프로젝트가 늘어나고 있다. 그렇기 때문에 소프트웨어에 잠재된 리스크를 감소시키기 위하여, 팀원들간의 효과적인 커뮤니케이션과 협업을 촉진시킬 수 있는 개발 환경의 도입이 필수적인 것이다. 이것은 MS 뿐만 아니라 IBM과 Borland 등 개발 도구를 판매하는 여타의 업체 또한 동일하게 추구하고 있는 방향이다.

이제는 ALM(Application Lifecycle Management)과 PM(Project Management)의 개념 하에서 좀 더 체계적으로 소프트웨어가 개발되어야 한다(하지만 필자는 여전히 개발자의 크리에이티브가 가장 중요한 요소라고 생각한다). 소프트웨어 개발 프로세스의 관점에서는 ALM을 위한 역할과 도구가 요구되고, 프로젝트 관리의 관점에서는 PM을 위한 역할과 도구가 요구되는 것이다.

그러한 업계의 니즈를 충족시키기 위해 MS는 Visual Studio 2005 Team System을 통해 인프라 아키텍트, 솔루션 아키텍트, 개발자, 테스터, 프로젝트 관리자가 함께 협업할 수 있는 환경을 제공해 주기 시작하였다. 이제 MS가 제공하는 개발 환경에서도 제대로 된 ALM과 PM이 가능해졌다는 사실은 무엇보다 중요한 점이다.

마지막으로 한가지 짚고 넘어갈 점이 있다. 필자는 경험상, 실패할 소프트웨어 프로젝트가 도구와 프로세스에 의해 성공할 수 있다고는 생각하지 않는다. 새롭게 출시되는 Visual Studio 2005가 제공하는 개발 환경이 매력적인 것은 사실이지만, 인적 자원의 역할 문제는 여전히 남아있다. 국내와 같이 제대로 된 아키텍트와 품질 관리자가 거의 없는 상황에서는(사실은 직종 자체가 불분명하다) 도구와 프로세스가 아무리 좋다고 하더라도, 인적 자원의 문제로 인하여 이러한 개발 환경의 도입이 아무런 효과가 없거나 또는 혼란을 가중시킬 수도 있다. 모델링 도구가 아무리 뛰어나다고 할 지라도, 누가 그것을 수행할 것인가?

도구와 프로세스에 대한 환상은 경계해야 한다. 그것은 유능한 인적 자원을 보조하는 것일 뿐, 인적 자원을 대체할 수 없다. 무에서 유를 창조하는 소프트웨어 개발의 특성상, (그 본질이 변하지 않는 한) 인적 자원의 자질이 프로젝트의 성공 요인 중 가장 중요한 요소라는 것에는 여전히 변함이 없다.

그러한 인적 자원(피플웨어)의 문제를 배제하고 본다면, Visual Studio 2005는 아주 매력적인 도구이다. 소중한 인적 자원들의 프로젝트 수행을 좀 더 합리적이고 좀 더 편하게 지원할 수 있기 때문이다. Visual Studio 2005는 그것을 위해 중요한 첫발을 내딛는 제품이다. 경쟁 제품인 IBM Rational 및 Borland 제품 군과 비교해서 아직까지는 일부 부족한 부분도 있지만, 새로운 소프트웨어 개발의 시대를 맞이하여 현재의 지향점은 명백히 올바른 것으로 보인다. @

필자 류한석님은 소프트웨어 개발 13년의 경력을 가진 Microsoft MVP (Solutions Architect), .NET Advisor, PMP이며, 아키텍처와 프로젝트 관리에 많은 관심을 갖고 있다. 또한 CISA, CISM이며 한국CISSP협회 연구이사로서, 개발 프로세스에서의 보안 고려사항에 대해서도 지속적으로 연구하고 있다.