Eric Lee
Microsoft Corporation
2005년 1월
요약: 코드의 품질을 개선하기 위해 Microsoft Visual Studio Team Edition for Software Developers에서 사용할 수 있는 기능에 대해 설명합니다.
참고 이 기사는 원래 .NET Developer's Journal 2005년 1월호에 게재된 내용이며, 발행사의 동의 하에 다시 쓰여진 것입니다.
1991년, Microsoft는 Visual Basic 1.0을 발표하여 개발자 생산성의 새로운 영역을 개척했습니다. 이로서 한때는 선택된 몇몇 개발자만의 영역이었던 Windows 응용 프로그램용 GUI(그래픽 사용자 인터페이스)의 구축이 일반 개발자에게도 가능한 일이 되었으며 시간이 흐르면서 Visual Basic은 Visual C++, Visual C# 및 Visual J#과 결합되어 Visual Studio 제품군을 이루었습니다. 데스크톱용 응용 프로그램에서 인터넷용 응용 프로그램으로 개발 대상은 변화되었지만 Visual Studio는 개발자 생산성을 극대화한다는 원래의 목적을 그대로 유지하고 있습니다.
오늘날에는 단순히 개인 수준이 아니라 팀 수준에서 개발자 생산성을 평가하는 것이 점차 일반화되고 매우 중요해지고 있습니다. 현재 글로벌 시장에 맞는 소프트웨어를 만들기 위해서는 다양한 분야의 인력이 팀을 이루어 함께 작업해야 하기 때문입니다.
1991년에 등장한 생산성에 대한 개념은 Visual Studio Team System이 도입되면서 더욱 확장되어, 이제는 개인 개발자가 아닌 여러 분야의 인력이 협력하는 팀 형태로 변화되고 있습니다. Visual Studio Team System은 오늘날 소프트웨어 개발에 참여하는 각 분야의 고유한 요구 사항뿐만 아니라, 이러한 분야의 개발자들이 함께 작업하기 위해 필요한 요구 사항까지 모두 인식할 수 있도록 설계되었습니다. 그림 1은 Visual Studio Team System을 구성하는 다양한 구성 요소를 보여 줍니다.
그림 1. Visual Studio Team System
Visual Studio Team System은 설계자, 개발자, 테스터 등 개별 분야의 인력을 위한 버전으로 나뉘어 있습니다. 각 버전은 일반적인 Visual Studio 2005를 기반으로 하고 있으며 각 버전마다 분야에 맞는 기능과 이러한 분야의 개발자들이 함께 작업하는 방식에 관련된 기능이 추가되어 있습니다.
이러한 각 분야의 작업을 함께 묶고자 하는 노력의 결실이 바로 Team Foundation Server입니다. Team Foundation Server는 개발자, 설계자, 테스터, 프로젝트 관리자가 효율적으로 협력하는 데 필요한 소스 코드 제어, 작업 항목 추적, 데이터 웨어하우징 및 보고 기능을 제공합니다.
각 분야 중심의 Team 버전과 Team Foundation Server는 함께 포괄적인 기술 제품군을 형성합니다. 또한 이 기술을 사용하는 최선의 방법을 이해하는 데 도움이 되도록 Visual Studio Team System을 사용하여 실제 문제를 해결할 수 있는 방법을 보여 주는 PAG(Process Architecture and Guidance) 콘텐츠가 마련되어 있습니다.
마지막으로 Visual Studio Team System은 협력업체에서 자체 기술을 개발하는 데 기반이 될 수 있는 플랫폼이 되어야 한다는 사실의 중요성을 인식하고 있습니다. VSIP(Visual Studio Industry Partners)는 오랫 동안 전통적인 Visual Studio 제공 서비스의 일부였습니다. Visual Studio Team System 역시 이 전통을 계속 유지하고 있습니다. 따라서 넓은 범위의 확장 가능 지점이 Visual Studio Team System에서 제공될 것입니다.
이 기사는 주로 Microsoft Visual Studio Team Edition for Software Developers의 기능에 초점을 맞추고 있습니다. 그러나 각 기능을 살펴보면서 Team System에서 사용할 수 있는 다른 기능에 대해 알아볼 것입니다.
가상의 회사: AdventureWorks
예를 들어 우리가 "AdventureWorks"라는 가상의 회사에서 일하는 개발자라고 가정해 보십시오. 그림 2에서 알 수 있듯이 이 회사는 웹 사이트를 통해 야외용 스포츠 상품을 판매합니다. 우리가 하는 일은 구매한 상품을 고객에게 배달하는 것이 아니라 고객이 실제 상점에서 구매해오던 상품을 웹 사이트에서 선택할 수 있는 기능을 구현하는 것입니다.
그림 2. AdventureWorks 웹 사이트
팀 작업
오늘날의 프로그래밍 환경에서, 어떤 코드를 작성할 것인지 결정하고 이를 팀에 알리는 것은 번거롭고 까다로운 일입니다. 일반적으로 소프트웨어 개발 팀은 자체적인 작업 항목 추적 도구를 사용하고, 테스터와 프로젝트 관리자는 이러한 작업 항목의 진행 상태를 추적하기 위해 가능한 한 최선을 다할 뿐입니다.
Visual Studio Team Edition for Software Developers와 Team Foundation Server의 통합은 이러한 워크플로를 더욱 자연스럽고 생산적으로 만들기 위한 것입니다. 작업 항목은 Team Foundation Server에 저장되며 Visual Studio Team Edition for Software Developers를 비롯한 여러 클라이언트에서 액세스할 수 있습니다. 프로젝트 관리자는 이러한 새 기능을 추적하기 위해 Microsoft Project와 Microsoft Excel을 사용하여 일정과 작업 항목 목록을 만들게 됩니다.
이러한 도구는 일반적인 개발 도구가 아니지만 Visual Studio Team System은 처음부터 소프트웨어 개발의 일부인 다양한 분야의 작업과 이러한 분야에서 사용하는 다양한 도구를 인식하도록 설계되었습니다.
Visual Studio Team System은 Microsoft Excel 플러그 인 및 Microsoft Project 플러그 인과 함께 제공될 것이므로 Microsoft Excel과 Microsoft Project에서 Team Foundation Server를 사용하여 작업 항목을 만들거나 수정하거나 삭제할 수 있습니다. 그림 3은 Team Foundation Server에 저장된 작업 항목을 Microsoft Excel로 가져와 사용하는 방법을 보여 줍니다. Excel 및 Project에 대한 확장 기능은 Visual Studio Team System의 확장성 프레임워크를 사용하여 만들어졌습니다.
그림 3. Microsoft Excel로 작업 항목 가져오기
일정과 작업 항목이 준비되었으면 개발 작업을 시작할 수 있습니다. 그림 4는 Visual Studio Team Edition for Software Developers를 사용하여 할당된 작업 항목을 표시하는 방법을 보여 줍니다.
그림 4. Visual Studio에서 작업 항목 보기
작업 항목을 분석하고 버그를 수정하는 등의 작업을 수행하고 이러한 작업 항목의 상태를 변경하면 프로젝트 관리자는 필요할 때마다 스프레드시트와 프로젝트 계획을 새로 고쳐 현재 상태를 업데이트할 수 있습니다. Visual Studio Team Edition for Software Developers에는 Team Foundation Server의 작업 항목이 변경될 때 알림을 보내는 기능도 있습니다. 그림 5는 이 기능을 사용하도록 설정하는 방법을 보여 줍니다. 이렇게 하면 작업을 수행하는 동안 작업 항목이 변경되는 즉시 알림을 받을 수 있습니다.
그림 5. 작업 항목의 상태 변경
코드 작성: 테스트 기반 접근 방식
Visual Studio Team System은 다양한 개발 방식에 활용될 수 있습니다. 근래 각광받고 있는 방식 중 하나는 테스트 기반 개발 방식입니다. 이 방식에서는 먼저 테스트를 위한 코드를 만들고, 그 다음에 실제 기능 코드를 만들게 됩니다. 이 기발한 접근 방식은 실제로 매우 효과적인 것으로 입증되었습니다.
Visual Studio Team System은 테스트 기반 개발에 매우 적합하므로 이 방식을 예로 사용할 것입니다. 그러나 이 기사에서 테스트 기반 개발 방식에 대해 깊이 있게 논의하지는 않을 것입니다. 이 개발 방식에 대해 더 자세히 알고 싶다면 http://msdn.microsoft.com/msdnmag/issues/04/04/ExtremeProgramming/(영어) 페이지를 참조하십시오.
우리의 첫 번째 작업 항목은 매장 내 제품 인수(in-store pickup)를 구현하는 것입니다. 테스트 기반 개발 접근 방식을 사용하고 있기 때문에 첫 번째 단계는 기능 자체보다는 이 기능을 테스트할 코드를 작성하는 것입니다.
테스트 코드로 시작하는 방식의 이점 중 하나는 무엇보다도 기능에 대해 가장 직관적인 인터페이스를 정의할 수 있다는 것입니다. 즉, 기능이 구현될 방식에 영향을 받지 않고 인터페이스를 정의할 수 있습니다. 여기서는 DoInStorePickup이라고 하는 비즈니스 논리 내의 함수를 통해 새 기능을 제공할 것입니다.
첫 번째 단위 테스트(그림 6 참조)는 C# 코드입니다. 이 코드는 특성으로 채워져 있는데, 이러한 특성들은 지정된 클래스의 메서드가 어떤 테스트를 나타내며 테스트가 어떻게 실행되어야 하는지 식별하는 데 사용됩니다.
그림 6. 테스트 특성을 정의하는 C# 코드
이 상태에서 빌드하면 아직 DoInStorePickup 메서드를 구현하지 않았기 때문에 테스트가 컴파일되지 않습니다. 그러나 이것은 의도된 동작이며 테스트 기반 개발 방식을 따르고 있으므로 다음 단계에서 테스트를 컴파일하기에 충분할 만큼의 코드만 작성하면 됩니다.
이 과정을 쉽게 진행하려면 Visual Studio 2005의 리팩터링 기능을 사용하여 새 메서드에 대한 스텁을 생성하면 됩니다. Visual Studio 2005에서는 소스 코드의 일부를 임의로 선택하여 메서드나 클래스와 같은 다양한 요소들로 리팩터링할 수 있습니다. 그림 7과 같이 이 기능을 사용하여 DoInStorePickup에 대한 메서드 스텁을 생성할 수 있습니다.
그림 7. 스텁 메서드 생성
DoInStorePickup 메서드에 대한 스텁을 생성했으면 Visual Studio Team Edition for Software Developers에서 테스트를 빌드하여 실행할 수 있습니다. 그림 8은 단위 테스트 프로세스를 구성, 실행, 모니터링할 수 있는 간단하고 사용이 편리한 사용자 인터페이스를 보여 줍니다. Visual Studio Team Edition for Software Testers에서는 보다 확장된 구성 기능을 사용할 수 있습니다.
그림 8. 단위 테스트 구성
그림 8에서 알 수 있듯이 테스트 실행의 첫 번째 시도가 실패했습니다. 그러나 이 역시 의도된 동작이며 테스트 기반 개발 방식의 특징에서 비롯됩니다. 이제 다음 단계로, 테스트를 성공할 수 있을 만큼의 기능을 InStorePickup에 추가하면 됩니다.
테스트 코드를 작성한 다음 테스트를 성공할 수 있을 만큼의 기능만 작성하는 이러한 프로세스를 반복해서 수행함으로써 상당히 복잡한 기능을 구축할 수 있습니다. 테스트 기반 개발 과정의 최종 결과로, 앞으로 발생할 수 있는 오류를 잡아낼 수 있는 모든 단위 테스트를 갖춘 완전한 기능이 구현될 것입니다. 이 과정을 진행하여 DoInStorePickup 메서드를 완성해 보겠습니다. DoInStorePickup 메서드의 완성된 코드는 그림 9와 같습니다.
그림 9. 완성된 DoInStorePickup 메서드
테스트 기반 개발 방식의 이점 중 하나는 기능 코드의 상당한 부분을 테스트에서 실행한다는 점입니다. 단위 테스트 실행의 일부로 구성할 수 있는 많은 특성 중 하나로 코드 검사 데이터를 자동으로 수집하는 특성이 있습니다. 그림 10은 코드 검사 데이터를 수집할 대상 아티팩트, 즉 Visual Studio 프로젝트나 이진 파일과 같은 아티팩트를 선택하는 방법을 보여 줍니다.
그림 10. 코드 검사를 위한 아티팩트 선택
코드 검사 결과는 네임스페이스, 클래스, 메서드로 이루어진 계층 구조로 구성됩니다. 이러한 형식의 코드 검사 데이터는 코드 실행 후 다음 실행 전에 병합하거나 더 큰 보고서의 일부로 게시하기에 매우 적합합니다. 그림 11은 코드 검사 결과가 테스트 결과의 또 다른 측면임을 보여 줍니다.
그림 11. 코드 검사 결과
일상적인 개발 작업에서뿐 아니라 즉각적인 피드백이 필요할 때마다 Visual Studio Team Edition for Software Developers를 통해 소스 코드에서 코드 검사를 확인할 수 있습니다. 그림 12는 코드 검사 결과가 소스 코드와 연결된 모습을 보여 줍니다.
그림 12. 소스 코드와 연결된 코드 검사 결과
실행된 줄은 녹색, 검사되지 않은 줄은 빨강, 부분적으로 검사된 줄은 파랑으로 표시되며 분기나 루프인 코드 줄이 가장 빈번하게 부분 검사됩니다. 이 화면을 보면 메서드 하나가 통째로 빠져 있음을 알 수 있습니다. 단위 테스트 검사는 소스 코드 환경에서도 수행할 수 있으므로 코드 편집기에서 테스트할 항목을 선택하고 자동으로 단위 테스트를 만들 수 있습니다. 이 기능은 Visual Studio의 코드 편집기에 통합되어 있으므로 그림 13과 같이 단위 테스트를 만들면 됩니다. 결과적으로 만들어진 단위 테스트는 직접 작성한 코드와 상당히 비슷합니다. 단위 테스트 모음을 생성하기 위한 기반 코드가 이미 있는 경우 단위 테스트의 자동 생성 기능이 매우 유용할 수 있습니다.
그림 13. 단위 테스트의 자동 생성
작업 간소화: 소스 코드 제어 사용
매장 내 제품 인수 기능을 작성했으면 다음 논리적 단계는 변경 내용을 체크 인하는 것입니다. Visual Studio Team System에서는 완전히 새로운 엔터프라이즈 수준의 소스 코드 제어 시스템을 제공합니다. 이 시스템은 Team Foundation Server의 필수적인 요소이기도 합니다. 그림 14는 새로운 이 시스템의 한 기능인 '보류 중인 체크 인' 대화 상자를 보여 줍니다.
이 대화 상자에서는 체크 인할 파일을 보는 것 외에도 체크 인과 연결할 작업 항목을 쿼리하여 찾을 수 있습니다. 이 방식으로 연결된 작업 항목은 자동으로 체크 인됩니다. 이 대화 상자의 체크 인 메모 페이지는 필요에 따라 사용자 지정하여 지정된 체크 인과 관련된 정보를 수집하는 데 사용할 수 있는 인터페이스입니다.
그림 14. 보류 중인 체크 인
이 대화 상자에서 Visual Studio Team Edition for Software Developers의 또 다른 기능을 확인할 수 있습니다. Team Foundation Server를 사용하여 각 체크 인에 대해 적용되는 정책을 구성하고, 필요한 경우 만들 수 있습니다. 적용할 수 있는 정책의 예로 체크 인 전에 정적 코드 분석이 실행되도록 지정하는 것을 들 수 있습니다.
자동 코드 검토
정적 코드 분석은 본래 자동화된 코드 검토이며, Visual Studio Team Edition for Software Developers의 경우 .NET과 C/C++ 소스 코드를 대상으로 사용할 수 있습니다. .NET의 경우 정적 코드 분석은 그림 15와 같이 구성 가능한 경고 집합을 기반으로 수행됩니다. 이러한 경고는 보안, 성능, 디자인 및 일반적인 품질과 관련한 문제를 나타냅니다. 이와 같이 Visual Studio Team System의 확장 가능 기능을 계속 활용하면 자신만의 플러그 인을 만들어 관리되는 코드 분석에 사용할 수도 있습니다.
그림 15. 구성 가능한 경고
이 예에서 코드 분석을 실행하면 소스 코드에 몇 가지 문제가 있다는 것을 알 수 있습니다. 코드 분석 경고는 Visual Studio의 작업 목록에 표시되므로 대부분의 개발자에게 친숙할 것입니다. 특히 C/C++에 대한 코드 분석은 버퍼 오버런과 같이 보안상 잠재적으로 취약한 부분을 표시해 줍니다. .NET 코드에서는 드문 이러한 유형의 오류에 대한 코드 경로는 Visual Studio 코드 편집기에 직접 강조 표시되므로 쉽게 확인할 수 있습니다. 그림 16은 버퍼 오버플로에 취약한 실행 경로를 보여 줍니다.
그림 16. 취약한 코드
어떤 경고에 대해서는 더 자세한 조사가 필요할 수도 있습니다. Team Foundation Server를 사용하면 이러한 경고에 대한 버그를 직접 저장하여 보관할 수 있습니다. 그림 17은 코드 분석 경고를 기반으로 버그를 생성하는 방법의 예를 보여 줍니다.
그림 17. 코드 분석에 따른 버그 생성
이러한 경고를 수정한 후 Team Foundation Server에서 이러한 변경 내용을 확인해 볼 수 있습니다. 소스 코드가 알려진 문제에 대한 엄격한 분석을 통과했다는 코드 분석 결과를 통해 자신감을 얻을 수 있을 것입니다.
마무리하기 전에, 수행할 마지막 단계는 작성한 코드의 성능을 확인하는 것입니다. 성능 확인을 시작하는 방식에는 여러 가지가 있지만 여기서는 단위 테스트로 돌아가 보겠습니다. 코드 검사 결과를 통해, 단위 테스트에서 소스 코드에 대한 테스트를 훌륭하게 해냈다는 것을 알 수 있습니다. 이제 이 단위 테스트를 사용하여 성능을 확인해 보겠습니다.
단위 테스트 결과에서 성능 세션을 직접 만들 수 있습니다. 그림 18은 성능 세션을 만드는 방법에 대한 예를 보여 줍니다.
그림 18. 성능 세션 만들기
효율적인 코드 작성
Visual Studio Team Edition for Software Developers 성능 도구의 기술적인 뿌리는 거의 10년 전의 Microsoft Research 연구실로 거슬러 올라갑니다. 그 당시 Microsoft Research는 Windows Server 2003, SQL Server 등의 제품을 최적화하도록 지원하기 위해 만들어진 성능 도구 세트를 담당하고 있었습니다. 훨씬 더 다듬어지고 덩치가 커지기는 했지만 지금의 Visual Studio Team Edition for Software Developers로 가는 길을 찾은 기술은 본래 이러한 노력에서 탄생되었습니다. Visual Studio Team Edition for Software Developers를 사용하면 다양한 수준에서 성능 데이터를 수집할 수 있습니다. 샘플링이라고 하는 프로파일링 방법을 사용하여 응용 프로그램의 핵심이 되는 부분을 요약하여 볼 수 있으며 이 보기에서 Visual Studio Team Edition for Software Developers를 사용하여 응용 프로그램에 타이밍 검색 지점을 삽입할 수 있는데, 이 프로세스를 계측(instrumentation)이라고 합니다. 이 프로파일링 방법을 사용하면 응용 프로그램의 특정 영역에 대한 성능 데이터를 매우 자세히 수집할 수 있습니다. .NET 응용 프로그램을 예로 들면, 응용 프로그램이 메모리를 어떻게 사용하고 있는지에 대한 데이터를 수집할 수 있습니다. 이러한 정보는 종종 응용 프로그램의 작동 방식을 결정하는 주요 요소가 됩니다.
Visual Studio Team Edition for Software Developers를 사용하면 프로파일링을 위해 응용 프로그램을 구성하는 모든 복잡한 과정을 그림 19와 같이 마법사를 통해 간단히 수행할 수 있습니다. 프로파일링은 .NET, ASP.NET 또는 C/C++ 응용 프로그램을 대상으로 수행할 수 있으며, Visual Studio Team Edition for Software Developers에서 응용 프로그램이 프로파일링을 위해 적절히 구성되도록 할 수 있습니다.
그림 19. 프로파일링을 위한 응용 프로그램 구성
Visual Studio Team Edition for Software Developers에서 응용 프로그램에 대한 데이터를 수집했으면 이제 이 데이터를 기반으로 성능 보고서를 만들 수 있습니다. 이 보고서는 함수 간 호출 방식, 이벤트 순서 또는 응용 프로그램에서 호출된 모든 함수 목록 등 확인하고자 하는 내용에 따라 여러 가지 다양한 방식으로 볼 수 있습니다.
응용 프로그램에 대한 수많은 성능 데이터를 수집하는 것은 매우 쉽습니다. 이 데이터를 다루는 코드를 작성하는 데 도움이 되도록 성능 확인을 시작할 주요 영역을 보여 주는 요약 내용을 만들 수 있습니다.
예를 들어 .NET 응용 프로그램에서 가비지 수집을 사용하고 있는지 보여 주기 위해 히스토그램을 렌더링할 수 있습니다. 이 히스토그램에서 의심스러운 패턴이 있을 경우 그림 20과 같은 할당 보기를 확인할 수 있습니다. 이는 응용 프로그램에서 할당한 모든 .NET 형식과 이 할당을 실행한 함수를 보여 줍니다. 이 보기를 통해 문제가 있는 가비지 수집 패턴의 원인이 되는 개체를 빨리 찾아낼 수 있습니다.
그림 20. 할당 보기
상태 전달
일어날 수 있는 성능 문제를 수정했거나 이에 관한 작업 항목을 Team Foundation Server에 입력했다면 이제 작업을 체크 인할 준비가 된 것입니다. 애초에 시작했던 작업 항목과 체크 인을 연결할 수 있습니다.
작업 항목은 자동으로 분석되며 이 작업 항목을 만든 AdventureWorks의 프로젝트 관리자는 진행 상황을 Excel 스프레드시트나 Project 계획으로 만들어 쉽게 확인할 수 있습니다. 그림 21은 완성된 초기 작업 항목을 모두 보여 줍니다.
그림 21. 완료된 초기 작업 항목
결론
Visual Studio Team Edition for Software Developers는 프로그래밍 언어, 디버거, 라이브러리 등 최상의 Visual Studio 2005 기능을 그대로 활용함과 동시에 팀으로 작업하는 개발자에게 필요한 기능을 추가하였습니다. Visual Studio Team Edition for Software Developers와 Team System의 전체 목표는 Visual Studio를 처음 만들었을 때의 생산성 비전을 변함 없이 지지하면서 엔터프라이즈 수준까지 확장하는 것입니다. 이 비전을 실현할 때 마주치게 되는 과제는 단지 개발자, 테스터, 프로젝트 관리자 및 설계자의 개별 작업에 있는 것만이 아니라, 이들이 함께 작업하는 방식에도 있으므로 Visual Studio Team System 2005는 각 분야의 인력이 모두 원활하게 협동할 수 있도록 주의 깊게 설계되고 철저히 검사되었습니다. 호된 시련을 거쳐 만들어진 결과인 Visual Studio Team System 2005는 먼 사촌뻘인 Visual Basic 1.0과 마찬가지로, 새로운 개발자 생산성 표준을 만들어나갈 것입니다.
저자 소개
Eric Lee는 1988년 University of Windsor Ontario를 졸업한 후 Microsoft에 입사했습니다. Eric은 Microsoft에서 테스터와 개발자로서의 경력을 쌓았으며, 현재는 Developer Tools Division의 제품 관리자로 일하고 있습니다. Eric은 이전에 Windows Server 2003 팀에서 일했으며, 여기서 Enterprise UDDI Services 개발에 기여한 바 있습니다.
