[지디넷코리아]비주얼 스튜디오 2005는 새로운 기능으로 무장하여 닷넷 개발자들의 최대 관심 대상으로 부각되고 있다. 특히 ‘비주얼 스튜디오 2005’ 제품군의 최상위 제품인 ‘비주얼 스튜디오 2005 팀 시스템’은 설계, 개발, 배포 주기 등을 지원하며 명실상부한 IT 라이프사이클 개발 도구임을 내세우고 있다.

응용 시스템 모델링부터 코드 구현 및 테스트 관리까지 비주얼 스튜디오 2005에서 지원되는 모든 기능을 한 눈에 확인해 볼 수 있는 엔터프라이즈급 응용 시스템 구현을 위한 ‘비주얼 스튜디오 2005 팀 시스템’을 눈여겨 보자.

XML 웹 서비스, 데스크탑, 모바일 및 웹 기반 응용 프로그램 등 모든 종류의 응용 프로그램 개발, 구축 및 실행을 가능케 해주는 MS의 새로운 프로그래밍 모델인 닷넷 프레임워크를 처음 소개했던 비주얼 스튜디오 닷넷은 기존의 InterDev를 알고 있던 개발자들에게는 가히 충격이 아닐 수 없었다.

그리고 비주얼 스튜디오 닷넷 2003 이후 닷넷 개발자들의 최대 관심의 대상으로 부각되고 있는 ‘비주얼 스튜디오 2005(코드명 ‘위드비(Whidbey)’)는 코드 커버리지, 전문적인 소스코드 제어, 64비트 컴파일러, 배포 도구, 테스트 케이스 관리 및 프로젝트 관리 기능 등으로 무장하여 또 한번의 충격을 예고하고 있다.

과거 InterDev와 비주얼 스튜디오 닷넷 2003은 응용 시스템 자체를 구현하는 소프트웨어 개발 부분에 보다 초점을 맞춘 개발 환경을 제공했다. 이에 비해 비주얼 스튜디오 2005는 아직 닷넷을 접해보지 못한 초보 닷넷 개발자는 물론 취미 삼아 소프트웨어를 개발하는 사람들을 위한 제품, 응용 시스템 자체를 구현하기 위한 소프트웨어 개발 환경만을 지원하는 제품, 엔터프라이즈급 응용 시스템 구현을 위한 제품까지 다양한 환경의 개발자를 위한 폭 넓은 제품 구성을 제시하고 있다.

IT 라이프사이클 도구, 비주얼 스튜디오 2005
비즈니스 환경이 복잡하고 빠르게 변화하는 오늘날의 기업들은 보다 다양한 응용 시스템을 보유하게 되었고, 신규로 구축되는 응용 시스템들은 기존 시스템과의 연계, 통합 등 더욱 향상된 서비스를 기대하는 사용자의 요구를 고려해야만 한다. 이러한 응용 시스템의 개발 프로젝트는 종종 복잡하고, 대규모로 진행됨에 따라 많은 인력들이 개발팀에 합류하게 되고 이들 구성원간의 정보 공유와 향상된 품질 및 비용 감소를 추구하는 시스템 설계는 성공적인 응용 시스템 구축을 위한 기본 요건이 되었다.

이러한 시대적 변화에 대응하며 개발자들이 필요로 하는 보다 효율적인 응용 시스템 개발을 위한 ‘비주얼 스튜디오 2005’ 제품군의 최상위 제품인 ‘비주얼 스튜디오 2005 팀 시스템(이하 팀 시스템)’은 응용 프로그램의 복잡성 증대를 해결하고, 빠르게 변화하는 개발 환경 및 기술에 대처할 수 있는 능력을 제공한다.

팀 시스템은 IT 라이프사이클 도구로 설계(디자인), 개발, 배포 주기 등을 지원해 생산성 향상 및 개발팀원간의 협업 환경을 제공하며, MS의 DSI(Dynamic Systems Initiative) 전략의 중요한 부분을 제공한다.

비주얼 스튜디오 2005 Team System
팀 시스템은 윈도우 서버 시스템 환경에서 조직이 핵심 솔루션 제공의 예측 가능성과 안정성을 향상시킬 수 있도록 검증된 프로세스 지침, 규범적 아키텍처 지침 및 솔루션 액셀러레이터를 포함한다. 팀 시스템은 전체 소프트웨어 개발팀을 지원하는 다음과 같은 도구를 제공한다.

<그림 1> 비주얼 스튜디오 2005 팀 시스템 제품 구성

궁극적으로 팀 시스템을 통해 설계자나 개발자는 ‘운영을 위한 디자인(design for operations)’을 수행할 수 있고, 개발 환경에서 동일한 기반 구조에 대한 정보를 사용할 수 있다. 이를 통해 실제 배포할 때 발생할 수 있는 문제점들을 초기 디자인 단계부터 실질적으로 파악할 수 있다. 또한 서비스 지향 솔루션을 제공할 때 발생하는 복잡성을 감소할 수 있다.

비즈니스 사용자, 프로젝트 관리자, 작업 관리자, 설계자, 개발자 및 테스터를 비롯한 모든 소프트웨어 개발팀원은 구성원간의 공동 작업을 촉진할 수 있다. 이것이 팀 시스템을 통해 얻을 수 있는 이점이며 팀 시스템이 추구하는 목표이기도 하다. 이제 각각에 대해 좀 더 자세한 내용을 살펴보자.

Team Architect
일반적으로 모델링 도구를 사용하여 소프트웨어 시스템을 설명하려 할 때마다 막대한 시간과 비용 투자 문제에 직면하게 된다. 그리고 대개 결과로 만들어지는 다이어그램은 처음에는 매우 훌륭하게 보이지만 개발이 한창 진행됨에 따라 코드와의 비동기화로 무용지물이 되거나 번거로운 추가 작업을 필요로 하게 된다.

일부 다이어그램과 코드간의 동기화를 제공하는 도구가 이용되기도 하지만 이러한 도구를 익히기 위해 드는 비용과 시간 때문에, 다이어그램을 제작하는 일이 주 업무가 아닌 경우를 제외하면 대개의 많은 사용자들이 모델링 도구 사용법을 익히는 것을 미루고 있다. 이 외에도 시스템 디자인과 이것이 배포되는 환경 특성 사이의 불일치 문제가 있다.

언제나 그러하듯 솔루션이 다이어그램에서 훌륭하게 표현되고 코드화된 다음 배포 시점이 다가올 때쯤이면, 모델이 운영 환경에 정확하게 맵핑되지 않아 발생하는 문제들을 해결하기 위한 작업들이 새로 추가되곤 한다. 또한 설계자, 디자이너, 개발자 및 IT 인프라 운영 부서 직원의 견해 차이로 인해 충돌이 발생할 수도 있다.

이러한 경우 대개 충돌에 대한 제약 조건은 시작 단계에서 조정되는 것이 바람직하며, 실제 서버 보안과 같은 제약 조건은 새로운 시스템을 성공적으로 배포?구현하는 데 장애가 되기도 한다. 중앙의 메인프레임 전용 시스템에서 클라이언트/서버 모델 및 분산 시스템으로 발전해 현재의 IT 환경을 더욱 복잡하게 만든 것도 이러한 문제를 증폭시키고 있다.

다양한 플랫폼과 네트워크 환경에서 사용자의 높은 요구 수준을 충족시키기 위해 응용 프로그램들은 서로 상호작용하며 효율적으로 운영되기 위해 하나의 완전한 서비스로서 존재하는 동시에 메시지 교환을 통하여 서로 연결될 수 있어야 한다. 이러한 서비스 지향 애플리케이션을 만들기 위해 오늘날 매우 널리 사용되고 있는 환경은 서비스 지향 아키텍처(SOA)이며, 이 SOA는 서비스 제공, 메시지 사용 통신 및 종종 신뢰할 수 있는 경계선을 넘나드는 느슨한 결합으로 구성된 자체 응용 프로그램으로 구축된다.

팀 아키텍트는 기술이 발전함에 따라 사용자가 손쉽게 SOA 기반의 시스템을 구축하고 관리하며 기본 플랫폼의 능력을 확장할 수 있는 다양한 기술 및 새로운 그래픽 디자인 도구를 제공한다.

새로운 그래픽 디자인 도구 제공
새로운 디자인 도구는 클래스 디자이너(Class Designer)와 분산 시스템 디자이너(Distributed System Designers)로, 분산 시스템 디자이너는 긴밀하게 통합된 네 개의 도구 그룹으로 구성된다. 이들 네 개의 도구는 응용프로그램 연결 디자이너(Application Connection Designer), 논리적 데이터센터 디자이너(Logical Datacenter Designer), 시스템 디자이너(System Designer), 배포 디자이너(Deployment Designers)이다.

네 개의 도구 중 응용 프로그램 디자이너와 클래스 디자이너는 시스템 및 구성 요소의 그래픽 디자인 지원과 코드 생성 지원 등 주요 특성을 공유한다. 이러한 디자이너들은 양방향 동기화를 지원하므로, 다이어그램이 시스템 및 구성 요소를 나타내지 않는다고 해도 염려할 필요가 없으며, 기존 모델링 시스템의 전형적인 문서 중심의 보기를 능가하는 점에서 모델링 분야에서의 르네상스 시대를 열었다고 할 수 있다.

이러한 디자이너 도구의 사용이 주는 또 다른 이점은 응용 시스템 개발 완료 후 배포 단계에서 발생할 수 있는 오류 또는 변경 사항을 시스템을 설계하는 초기 단계부터 발견하고 대처함으로써 예상치 못한 추가 비용의 발생을 제거하는 것이다.

서비스 지향 시스템을 디자인하고 즉각적으로 이 시스템의 운영 인프라에 대한 유효성 검사를 실행할 수 있는 능력을 ‘운영을 위한 디자인(Design for Operations)’이라고 한다. 응용 프로그램은 대개 하나의 환경에서 디자인되는 경우가 많지만, 그 밖의 다른 환경이나 여러 환경에 배포되도록 설계된다. 대상 데이터센터 모델과 대조하여 디자인 유효성 검사를 수행하는 능력은 배포 과정을 더욱 매끄럽게 만들어 주며, 동시에 연결된 시스템의 개발, 배포, 운영의 단순화 및 자동화를 추구하여 설계자의 관점에 맞추어 작업을 수행할 수 있다.

또한 제약 조건은 양쪽 부분에서 모두 강제 실행될 수 있으므로, 프로젝트 시작 단계부터 유효성 검사 메커니즘을 통해 의사소통을 강제함으로써 시스템이 성공적으로 배포되도록 보장할 수 있다. 그럼 분산 시스템 디자이너를 사용하여 간단한 시스템을 작성하면서 디자인 도구에 대해 살펴보자.

응용 프로그램 연결 디자이너
새로운 솔루션을 만들 때 접하게 되는 첫 번째 디자이너가 응용 프로그램 연결 디자이너로, 웹 서비스 응용 프로그램 및 클라이언트 웹 또는 윈도우 기반 응용 프로그램을 정의하기 위한 디자인 화면을 제공한다. 이 디자이너를 사용하면 응용 프로그램을 연결할 수 있고 코드 내에서 지원돼야 하는 통신 경로를 정의할 수 있다. 또한 구현을 위해 개발자용 기본 골격 구현을 생성하기 전에 응용 프로그램 설정 및 디자인으로 자유롭게 시험해 볼 수 있다.

응용 프로그램 연결 디자이너가 제공하는 비주얼 스튜디오 도구 상자는 윈도우 기반 응용 프로그램, 웹 서비스 및 데이터베이스를 나타내는 구성 요소 집합을 제공한다(<화면 1>). 드래그 앤 드롭 기능을 적용하여 쉽게 시스템을 배치할 수 있다.

예를 들어, 데이터베이스 연결이 필요하다고 지정하려면 ExternalDatabase 구성 요소를 디자인 화면으로 끌어서 놓은 다음 udio의 표준 속성 창에서 데이터베이스에 대한 연결 문자열을 설정한다. 데이터 소스가 결정된 경우에는 웹 서비스의 형식으로 데이터 액세스 층을 추가한다. 웹 서비스를 디자인 서비스로 끌어온 다음에는 둘 사이의 연결을 끌어와 웹 서비스를 이전에 정의한 데이터 소스로 바인딩할 수 있다.

<화면 1> 도구상자

다음 단계는 웹 서비스 인터페이스를 통해 데이터를 표시하는 것으로, 이렇게 하려면 기본으로 생성된 웹 서비스의 종점을 클릭한 다음 종점 정보 창에서 공용 진입점을 정의한다. 새 웹 서비스 프로젝트가 솔루션에 추가되고, IIS의 로컬 인스턴스가 구성되며 언어별 소스 집합과 구성 파일이 생성된다.

솔루션 탐색기에서 코드 폴더를 열면 두 개의 클래스 파일이 표시되는데, 하나는 웹 서비스 구현을 위한 것이고 다른 하나는 web.config 파일에 생성되는 데이터베이스 연결 문자열을 검색하는 데 유용한 유틸리티 클래스이다. 이 시점에서 코드의 공용 진입점에 대해 수정 또는 조정 작업이 이루어질 경우 수행된 변경 사항은 시스템 다이어그램과 자동으로 동기화된다. 초기 디자인을 테스트하는 작업은 비주얼 스튜디오의 초기 버전에서 수행된 것처럼 간단히 키만 누르면 된다.

모든 것이 잘 작동되었다면 이제 프론트 엔드를 웹 서비스에 추가해 보자. 응용 프로그램 연결 디자이너의 도구상자에서 ‘ASP.NET 웹 응용 프로그램’을 디자이너 화면으로 끌어서 놓는다. 이전과 마찬가지로 구성 요소를 모두 바인딩해야 하며, 표시된 웹 서비스의 진입점을 클릭하고 웹 서비스 및 웹 응용 프로그램 사이의 연결 링크를 끌어오면 된다.

그런 다음 웹 응용 프로그램에서 마우스 오른쪽 단추를 클릭하고 구현을 선택한다. 그러면 비주얼 스튜디오가 새 웹 응용 프로그램 프로젝트를 솔루션에 추가하고 웹 서비스에 대한 웹 참조를 생성한다. 그런 다음 새 항목 추가 명령을 사용하여 이전 버전에서와 마찬가지로 기본 웹 페이지를 추가한다.

웹 폼 디자이너를 사용하여 웹 서비스를 UI(웹 페이지의 GridView 컨트롤)에 연결하는 ObjectDataSource 구성 요소를 추가한다. ObjectDataSource는 웹 서비스의 표시된 메쏘드 호출을 처리하며, 이 경우 어떠한 코드도 작성할 필요가 없다. 단지 GridView 컨트롤의 속성을 약간 조정한 다음 웹 브라우저에 있는 웹 서비스에서 데이터를 표시하기 위해 키를 누르기만 하면 된다. <화면 2>는 응용 프로그램 연결 디자이너에서 완료된 응용 프로그램이다.

<화면 2> 분산 솔루션의 응용 프로그램

논리적 데이터센터 디자이너
다음으로는 배포 환경 내 네트워크의 논리 모델과 실제적인 서버 유형을 정의해야 하는데, 이 단계는 이미 운영 팀에서 완료했을 수 있다. 이러한 경우, 데이터센터의 응용 프로그램 호스팅 기능에 대한 논리 모델을 표현하는 다이어그램을 만드는 데 이용되는 논리적 데이터센터 디자이너를 사용할 수 있다.

이 디자이너를 사용하면 인프라 설계자가 데이터베이스 서버, 웹 서버, 논리 보안 영역 및 통신 끝점과 같은 시스템 엔터티를 표시하여 데이터센터 토폴리지를 지정할 수 있다. 또한 제약 조건은 데이터센터의 요구 사항을 기반으로 한 응용 프로그램 구성에 대해 적용될 수 있다.

<화면 3> 유형

그럼 논리적 데이터센터 디자이너 도구 상자에 표시된 특정 요소를 사용하여 새로운 논리 데이터센터 다이어그램을 만들어 보자. <화면 3>은 현재의 논리 서버 목록 및 지원되는 끝점 유형을 보여준다. 이제 다이어그램에 DMZ(DeMilitarized Zone)를 나타내고 네트워크의 보안 내부 영역을 나타내는 두 개의 영역을 추가해 보자. 그런 다음 DMZ에 견고한 IIS 웹 서버를 정의하고, 내부 영역에는 ‘AppServer’라는 IIS 웹 서버와 SQL 서버를 실행하는 컴퓨터를 추가하자.

IIS 웹 서버의 경우 미리 정의된 입력 및 출력 끝점이 있다. 연결 도구를 사용하면 AppServer와 SQL 서버 컴퓨터 사이의 연결을 포함한 다양한 입출력 채널을 연결할 수 있다. <화면 4>는 완료된 논리 데이터센터 다이어그램이다. 다이어그램을 정의하고 나면 논리 서버에 제약 조건을 추가할 수 있다. 예를 들어 AppServer가 SSL(Secure Socket Layer)을 사용하도록 해야 할 수도 있는데, AppServer를 선택한 후 Settings and Constraints 편집기를 열어 작업하면 된다.

<화면 4> 완료된 논리 시스템 아키텍처

시스템 디자이너
시스템 디자이너를 활용하여 응용 프로그램 연결 디자이너에서 이미 정의된 응용 프로그램의 시스템을 조직하고 구성할 수 있다. 분산 시스템 디자이너에서 시스템은 배포의 기본 단위이고, 하나 이상의 응용 프로그램이나 다른 시스템의 구성 단위로 인식된다. 하나의 시스템은 다른 시스템의 하위 시스템으로 구성될 수도 있기 때문에 매우 큰 분산 시스템을 정의할 수 있다.

응용 프로그램 설계자는 시스템의 nested 구조를 이용하여 복잡한 다중 시스템정의를 만들 수 있으며, 이러한 시스템 정의의 경우 응용 프로그램 연결 디자이너에서 표기된 개발 구성과 별도로 배포 구성을 정의할 수 있다. 즉 시스템 정의는 솔루션에 정의된 응용 프로그램 구성과 서로 다르게 디자인될 수 있고, 각기 다른 데이터센터 구성, 다른 지리적 배포 환경, 다른 고객에 대해서 계획된 다른 배포 구성을 정의할 수 있다.

<화면 5> 다중 시스템 정의 다이어그램

배포 디자이너
프로세스의 마지막 단계는 이전에 정의한 응용 프로그램을 새로 정의한 논리 시스템 아키텍처로 맵핑하는 작업이다. 개발 환경에서 사용된 구성이 배포에 필요한 구성이라 전제하고 시험 배포(Trial Deployment)가 되는 대상을 정의할 수도 있고, 계획한 배포에 맞는 특정한 설정을 구성할 수 있는 새로운 시스템을 명시적으로 만들 수도 있다.

대부분의 경우 먼저 시험 배포를 통하여 심각한 문제들을 제거한 다음 구성을 고정시키는 최종 단계로 시스템을 만든다. 그러면 시스템이 좀 더 안정적인 정의로 구성될 수 있어 대규모의 아키텍처 디자인에서 다시 사용될 수 있다.

이제 시험 배포를 만들어 보자. 응용 프로그램 연결 다이어그램에서 시험 배포 정의(Define Trial Deployment)를 선택한 다음, 팝업 대화 상자에서 이전에 만든 논리적 데이터센터 디자인을 선택한다. 논리적 데이터센터를 배경으로 나타내는 새로운 배포 다이어그램에서 배포 디자이너를 사용해 각 응용 프로그램을 논리 서버로 바인딩하고 배포할 서버의 유형을 나타낼 수 있다.

이렇게 하려면 간단하게 개요 컨트롤 또는 응용 프로그램 연결 다이어그램에서 직접 응용 프로그램을 끌어서 놓으면 된다. 만약 바인딩하려는 응용 프로그램과 서버가 호환되지 않는다면 no-drop 기호가 표시될 것이고, 프로세스가 각 응용 프로그램에서 반복되면서 시스템의 가상 배포를 만든다. 일단 모든 구성 요소를 해당 호스트로 맵핑하면 <화면 6>에 나타난 대로 맵핑의 유효성을 검사할 수 있다.

유효성 검사는 모든 바인딩을 검사하여 양쪽 다이어그램에 정의된 제약 조건을 확인하고, 응용 프로그램에 필요한 경로와 프로토콜을 지원하는 논리적 데이터센터에 통신 경로가 있는지를 확인한다. 오류가 발생할 경우 작업 항목이 비주얼 스튜디오 작업 목록에 추가되며, 오류 목록에서 해당 항목을 두 번 클릭하면 오류가 발생한 다이어그램과 구성 요소로 이동하게 된다.

예를 들어, AppServer가 ASP.NET을 사용하도록 하기 위해 논리적 데이터센터 디자이너에 제약 조건을 설정한다. 이 때 유효성 검사를 실행하면 오류가 발생하는데, 오류 항목을 두 번 클릭하면 선택한 끝점이 잘못되어 있는 응용 프로그램 연결 다이어그램으로 이동하게 된다. Settings 편집기에서 정확한 속성을 조정한 후, 값이 자동으로 web.config 파일에 기록되고 유효성을 다시 검사하면 모든 작업이 완료된다.

개발한 응용 프로그램을 실제로 운영하기 전 극도의 압박감에 시달리는 대신, 이러한 과정을 통해 배포하기 전(가능하면 핵심 개발이 시작되기 전)에 배포 관련 문제점을 발견할 수 있는 이점을 얻을 수 있다.

<화면 6> 하위 시스템 맵퍼

클래스 디자이너
이제 시스템의 외부와 내부를 세밀하게 계획하기 위해 클래스 디자이너를 사용하여 작업할 수 있는 개발자에게 디자인 작업을 넘겨줄 차례이다.

대부분의 객체지향 개발자들은 응용 프로그램 디자인을 위한 다이어그램을 만들고자 할 때 UML 문서 양식을 종종 사용한다. UML은 응용 프로그램을 모델링하는 데 사용할 수 있는 여러 유형의 다이어그램을 정의한다. 일반적으로 가장 많이 사용되는 다이어그램 유형은 응용 프로그램의 각 클래스와 함께 다른 클래스에 대한 관계를 표시하는 클래스 다이어그램이며, 각 클래스는 필드와 메쏘드가 나열된 상자에 표시된다.

하지만 불행히도 UML은 닷넷 프레임워크와 같은 현재 기술에 뒤쳐지는 경향이 있다. 예를 들어, UML에는 비주얼 베이직 닷넷 및 C#의 내부 범위와 Friend에 대한 규정이 없다. 또한 닷넷 클래스에 대한 인터페이스의 핵심적인 부분인 속성 메쏘드 또는 이벤트를 나열하기 위한 적절한 방법도 없다.

클래스 디자이너는 비주얼 스튜디오 2005를 사용하는 객체지향 디자이너와 개발자를 위한 아주 좋은 도구이다. 클래스 디자이너는 닷넷 환경에서 비주얼 베이직 닷넷 및 C#의 모든 언어 기능을 반영할 수 있는 UML과 유사한 클래스 다이어그램을 제공한다. 이 클래스 디자이너를 사용하면 정확한 다이어그램을 만들 수 있을 뿐만 아니라 실시간으로 다이어그램과 코드의 동기화를 유지할 수 있다.

<화면 7>은 다이어그램을 위해 생성된 코드와 함께 비주얼 스튜디오 2005의 클래스 다이어그램 도구를 보여준다. 다이어그램이나 코드 중 어떤 것을 변경해도 양쪽 모두 자동으로 동기화 상태로 유지된다. 클래스 디자이너를 사용하려면 비주얼 스튜디오 2005에서 클래스 다이어그램을 프로젝트에 추가해야 하며, 이렇게 하려면 새 항목을 프로젝트에 추가하고 클래스 다이어그램 템플릿을 선택하면 된다.

Class Details 창에서 클래스의 인터페이스를 보고 변경할 수 있다. 이러한 작업에는 메쏘드, 필드, 속성 및 이벤트의 추가와 제거가 포함된다. 또한 이러한 요소들의 범위, 매개변수 및 반환 형식을 변경할 수도 있다. Class Details 창에서 이루어진 모든 변경 사항은 코드에 즉시 적용된다.

<화면 7> 클래스를 Class View에서 클래스 다이어그램으로 끌기

Team Developer
팀 디벨로퍼는 개발자가 제품의 개발 주기 내 초기 단계 또는 주기 내내 언제라도 품질 향상을 위해 코드 버그나 성능 문제들을 발견하고 보완할 수 있도록 통합된 분석 도구들을 제공한다. 개발팀은 이를 통해 SDLC(Software Development Life Cycle)를 효과적으로 관리할 수 있다.

분석 도구의 필요성
여러 다양한 분석 도구들 중에서 소프트웨어 분석 요건을 충족하는 동시에 예산 범위를 벗어나지 않는 도구를 선택하는 것은 항상 쉬운 일만은 아니다. 게다가 이러한 도구는 비주얼 스튜디오 IDE에 통합되지 않을 수도 있고, 능숙하게 사용할 수 있으려면 일반적으로 별도의 시간을 투자해 사용 방법을 습득해야 한다.

별도의 사용자 지정 분석 도구를 구현하는 작업도 쉽지 않은 작업으로 이를 위해서는 자원, 기술 및 경험이 요구된다. 하지만 현실적으로 대부분의 개발팀이 이 모든 것을 갖추기란 어려운 일이며, 이러한 방법으로 분석 도구를 선택할 수 있는 회사는 거의 없을 것으로 생각된다.

촉박한 마감 시간과 한정된 예산을 핑계로 분석을 수행하지 않고 코드를 제공하는 것 또한 현실적으로 타당한 방법처럼 보일 수 있으나, 응용 프로그램이 배포된 후에 오류가 발생하면 이를 수정하기 위해 필요한 비용은 배포 전 소요되는 비용보다 더 많은 비용이 들어갈 수 있다. 견고하고 안정적인 응용 프로그램 개발을 위해 팀 디벨로퍼는 다음 두 가지 범주의 분석 도구를 제공한다.

◆ 코드 분석 도구
◆ 성능 도구

코드 분석 도구
코드 분석 도구의 목표는 개발자가 응용 프로그램 개발 중 정적 분석을 통해 코드 결함을 발견하고 수정할 수 있도록 하는 것으로, 이를 위해 PREfast와 FxCop이라는 두 가지 도구가 제공된다.

Prefast는 C/C++ 소스코드에서 있을 수 있는 결함에 대한 정보를 개발자에게 제공해 주는 정적 분석 도구이다. Prefast가 보고하는 일반적인 코딩 결함에는 버퍼 오버런, 초기화되지 않은 메모리, null 포인터 역참조, 메모리 및 리소스 누수 등이 있으며, 개발자의 생산성 증대 측면에서 보다 편리하고 자연스럽게 분석 도구를 사용할 수 있도록 Prefast는 IDE 내에 통합된다.

<화면 8>에서 보는 바와 같이 개발자는 프로젝트의 ‘Property Pages’에서 ‘Yes(/prefast)’를 선택하여 Prefast를 간단하게 활성화할 수 있다.

FxCop는 관리되는 코드 어셈블리를 분석하고 어셈블리에 대한 정보(예 : 닷넷 프레임워크 디자인 지침 명시된 프로그래밍 및 디자인 규칙의 위반)를 보고하는 정적 분석 도구이다. FxCop는 분석 도중에 수행하는 검사를 규칙으로 나타낸다. 규칙은 어셈블리를 분석하고 발견된 사항에 대한 메시지를 반환하도록 관리되는 코드이다. 규칙 메시지는 관련된 모든 프로그래밍 및 디자인 문제를 식별하고, 가능한 경우 문제를 수정하는 방법에 대한 정보를 제공한다.

<화면 8> PREfast 활성화

<화면 9> FxCop활성화

성능 분석 도구
성능 도구를 사용하여 코드에 존재하는 성능 관련 문제들을 측정, 평가, 해결할 수 있다. 이러한 도구들은 IDE에 통합되어 사용자가 편리하고 원활하게 사용할 수 있으며, 샘플링 및 계측이라는 두 가지 프로파일링 방법을 지원한다.

샘플링 동안 데이터 수집 인프라는 실행되는 응용 프로그램을 정기적으로 중단하여 실행 중인 함수를 확인한 후 해당 함수의 샘플 계산을 증가시키며, 함수 호출에 이르기까지의 호출 스택에 대한 정보를 저장한다. 응용 프로그램이 종료하면 수집된 모든 데이터가 보고서 파일로 생성되며, IDE에 통합된 보고 기능을 사용하여 이 보고서를 편리하게 볼 수 있다.

샘플링은 응용 프로그램이 정기적으로만 중단되기 때문에 오버헤드가 적다는 이점이 있다. 따라서 응용 프로그램이 실제 사용에서와 흡사하게 동작할 수 있으나 이 방법은 샘플링된 함수에 대한 상대적인 성능 데이터만 얻을 수 있다는 단점도 있다.

계측은 응용 프로그램의 특정 부분에 대한 정확한 성능 데이터를 얻을 수 있다는 이점을 제공한다. 계측 도중에 응용 프로그램의 함수에 ‘시작’ 및 ‘종료’ 프로브(probe)가 삽입되는데, 이러한 프로브는 데이터 수집 인프라에 다시 보고됨으로써 함수를 실행하는 데 걸린 시간과 다른 수치를 사용자가 정확하게 파악할 수 있게 해준다.

응용 프로그램을 프로파일링하기 위해 선호되는 방법은 먼저 샘플링을 수행한 다음 샘플링으로 생성된 결과를 기반으로 응용 프로그램의 특정 측면을 계측하는 것이다. 응용 프로그램을 프로파일링하는 절차는 새 성능 세션을 만드는 간단한 방법으로 시작할 수 있으며, 성능 세션 마법사(Performance Session Wizard)를 사용하여 새 성능 세션을 손쉽게 만들 수 있다. 새 성능 세션은 수작업으로도 생성 가능하며 메뉴에서 ‘New Performance Session’ 명령을 사용하면 된다.

성능 세션을 만든 결과는 <화면 11>과 같이 성능 익스플로러(Performance Explorer)에 시각적으로 표시된다.

성능 익스플로러는 계층적 구조로 사용자에게 제공되며, 계층의 루트 노드는 성능 세션을 나타낸다. 이 노드의 속성은 성능 세션을 만들 때 사용자가 설정한 속성으로 사용자가 성능 세션 마법사를 사용하여 세션을 만든 경우 이러한 속성은 사용자가 마법사를 진행하면서 선택한 값이 반영된다. 사용자가 성능 세션을 수동으로 만든 경우 이러한 속성은 기본 값을 포함한다.

응용 프로그램 실행이 끝나면 성능 세션 보고서가 Reports 노드에 자동으로 추가되며, 보고서는 응용 프로그램을 실행하는 동안 가장 비용이 많이 드는 함수를 표시한다. 보고서는 요약 보기, 함수 보기, 호출자/호출 수신자 보기, 호출 스택 보기, 형식 보기 등을 통해 세부 정보를 제공한다.

<화면 10> Performance Wizard 시작

Team Test
팀 테스트는 새로운 테스트 도구 그룹으로 MS 내부에서 사용됐던 테스트 도구들이다. 이 새로운 테스트 도구들은 비주얼 스튜디오에 통합되어 자체 테스트 프레임워크뿐 아니라 완전한 SDLC 솔루션이 제공하는 확장된 프레임워크에도 사용될 수 있다.

품질 보증
모든 응용 프로그램과 웹 페이지의 품질 및 성능 목표치 달성을 위해서는 엄격한 테스트가 우선 선행돼야 한다. 최근 들어 많은 관심을 받고 있는 테스팅 분야는 과거 고급 개발자보다는 초급 개발자의 업무 영역으로 분류되어 가치를 제대로 평가받지 못했으나, 소프트웨어 공학의 전문화와 품질의 중요성이 부각되며 전 개발 공정 중 제일 비용을 효율화할 수 있는 과정으로 인식되고 있다.

<화면 11> Performance Explorer

비주얼 스튜디오는 소프트웨어 개발자를 위주로 하는 제품으로 개발 과정의 테스트 지원 기능을 중점적으로 제공하지는 않았다. 테스터로서 비주얼 스튜디오를 활용해 본인이 원하는 테스트를 수행하기 위한 코드를 작성할 수도 있겠으나, 특별한 목적의 테스트나 테스트를 관리하기 위해서는 써드파티의 전문 테스트용 제품을 필요로 했을 것이다.

더욱이 전문 테스터로서 자료 모델링, 발표, 지원 문서 체계화, 버그 트랙킹, BVT(Build Verification Test) 같은 테스트 세트를 생성해야 한다면 문제는 더욱 복잡해질 것이다. 테스트 툴셋들이 제공하는 결과물은 일반적으로 다양한 도구와 정보 공유를 위한 저장소간에 공유되지 못하는 불편을 준다.

팀 테스트는 비주얼 스튜디오 IDE에 통합되어 테스트를 생성하고 운영하는 데 보다 높은 생산성을 보장한다. 또한 테스트 결과물의 데이터베이스 저장, 경향 분석, 기록 보고서 생성 및 결과 자료의 차이를 비교할 수 기능을 지원한다.

팀 테스트가 지원하는 테스트 형식은 다음과 같다. 팀 테스트는 기존의 테스트 방식을 계속해서 사용할 수 있게 하거나 비주얼 스튜디오에 플러그인해 커스텀 형식의 테스트를 진행할 수 있도록 충분한 확장성을 제공한다.

◆ 단위 테스트 : 프로젝트의 함수나 메쏘드를 실행시키는 코드들로 구성되어 작은 단위의 소스코드를 테스트하는 데 사용됨

◆ 웹 테스트 : 브라우저 세션에서 만들거나 레코딩된 일련의 HTTP URL을 테스트함

◆ 일반 테스트 : 팀이 기존에 쓰고 있던 자동화 테스트와 도구를 사용할 수 있도록 함

◆ 부하 테스트 : 많은 사용자를 시뮬레이트하여 자동화 테스트를 실행함

◆ 매뉴얼 테스트 : 자동화하지 않은 테스트 과정을 단계적으로 수행하는 테스트

테스터 인터페이스
◆ 테스트 뷰 창 : 테스트 네비게이션 및 편집 기능 제공으로 테스트 작성 지원

◆ 테스트 탐색기 창 : 각각의 테스트를 분류하여 관리하는 기능 제공

◆ 실행 환경 설정 대화창 : 정확한 테스트 방법을 정의(<화면 13>)

◆ 테스트 결과 창 : 현재 진행 중인 테스트의 현황(대기, 진행, 미결, 통과, 실패)을 표시, 부하 테스트의 경우는 완료된 상황만을 표시(<화면 14>)

◆ 코드 커버리지 창 : 실행 환경 설정 대화창에서 코드 커버리지를 사용하면, 코드 커버리지 창을 통해 테스트가 진행되는 소스코드 모듈의 파일명, 네임스페이스, 클래스, 메쏘드 및 진행 범위를 표시

<화면 12> 테스트 환경 설정 창

<화면 13> 테스트 결과 창

Team Foundation
개발하는 소프트웨어의 규모가 커질수록 SDLC 초기에 정의한 요구사항이 설계, 개발, 배포, 유지보수 단계에서 제대로 이행되고 있는지 추적하는 것은 매우 어렵고 힘든 일일 것이다. SCM(Software Configuration Management)은훈련, 정책, 절차의 세트로 소스 파일의 제어, 작업 아이템의 생성과 관리, 제품 빌드 제작, 제품 배포 관리 등을 위해 사용되는 전략으로 SDLC에서 주요한 역할을 수행한다.

효과적인 SCM 전략은 마치 자신에게 편하게 잘 맞는 신발과도 같다. 시간이 지날수록 특정 프로젝트팀만의 독특한 필요에는 부합하나 다른 조직과는 공유할 수 없으며 그것이 없어지기 전에는 존재의 가치를 잊고 지내기 때문이다.

팀 시스템은 유연한 SDLC의 엔드 투 엔드 도구로서 설계자, 개발자, 테스터, 프로젝트 매니저, 문서 작성자 등이 함께 일할 수 있도록 도와주어 생산성을 극대화해 주고, 프로젝트의 상태와 결과를 예측 가능하게 한다. 팀 시스템의 중심은 SCM의 절차와 프로젝트팀 고유의 요구사항을 개발자의 일상적인 워크플로우에 반영하는 변경 관리 컴포넌트의 통합이다.

작업 아이템 추적, 소스코드 제어, 정책 지원, 통보와 리포트 생성 등을 지원하는 팀 파운데이션이 제공하는 기능은 크게 변화 관리, 보고서 관리, 통합 서비스, 작업 아이템 추적, 프로젝트 사이트, 프로젝트 관리로 구분된다.

작업 아이템 추적과 소스 코드 제어의 통합
팀 파운데이션은 개발 프로젝트 팀원들이 작업 아이템과 다른 시스템 구성 아이템 또는 산출물과 연관짓게 함으로써 소스코드 제어, 작업 아이템 추적, 빌드 관리간의 격리 현상을 제거했다. 작업 아이템은 프로젝트 팀원에게 할당되는 작업 단위로 적절한 권한을 가진 사람이 수정하거나 할당할 수 있다. 또한 개발 프로젝트마다 고유한 특성에 적합하도록 작업 아이템의 필드, 폼, 상태 변화와 규칙 등의 형식을 정의할 수 있다.

작업 아이템은 리포트로 보고되고 ‘마이크로소프트 프로젝트’를 이용하여 스케줄되며, 분석을 위해 작업 목록을 엑셀로 내보낼 수도 있다. 프로젝트팀원은 자신에게 주어진 일의 우선순위를 설정하거나 연관되는 것에 대한 참고 사항을 만들 수 있다. 버그 수정 완료 후에는 테스터에게, 기타 다른 정보가 필요할 때는 관련자에게 필요한 내용을 통보할 수 있다.

설계자, 개발자, 테스터, 문서 작성자 등은 이슈 사항을 관리하기 위하여 프로젝트 구성 아이템으로 작업 아이템을 만들고 할당할 수 있으며 이슈 사항을 결론짓기 위해 진행 상황을 추적할 수 있다. 팀 파운데이션 서버에 들어가는 일반적인 작업 아이템은 버그, 요구사항, 태스크, 리스크, 작업 스케줄 등이 해당된다.

소프트웨어 개발 프로젝트에서 성공적으로 협업하기 쉬운 방법 중의 하나는 공유 개발 리소스를 제어하는 것이다. 소스 제어는 팀 리소스가 사고로 지워진다든지 실수로 덮어쓰는 것을 막아주고, 여러 개발자가 같은 프로젝트 아이템을 작업하거나, 프로젝트를 동시에 여러 가지로 나누고, 모든 프로젝트 아이템을 버전별로 유지보수할 수 있게 해준다.

팀 파운데이션은 새로운 엔터프라이즈 수준 소스 제어 도구로, 안정적이고 빠르며 대용량 지원 및 보안이 강화됐다. 또한 확장이 가능하고 이미 널리 사용되는 비주얼 소스세이프의 거의 모든 기능을 포함하고 있다. 개발자는 IDE을 벗어나거나 다른 응용 프로그램을 열지 않고도 모든 소스의 제어 작업을 수행할 수 있다. 팀 파운데이션의 소스코드 제어 모듈은 SCM을 위해 독립적으로 사용될 수도 있고, 변화 관리를 위한 팀 시스템의 구성 항목으로 통합 사용될 수도 있다.

소프트웨어 프로젝트 관리
프로젝트 관리의 중요성은 소프트웨어 개발 경험을 갖고 있는 사람이라면 누구나 공감하는 사항일 것이다. 납기를 맞추고 한정된 예산 범위에서 초기 설정된 목표를 달성하기 위해서는 지속적인 모니터링과 적절한 시기에 적절한 리소스의 투입을 필요로 하게 된다.

팀 파운데이션의 프로젝트 관리 도구는 보다 나은 계획 수립, 일정 관리, 협업, 의사소통, 보고 및 프로세스 제어를 위한 도구로 IDE와 통합뿐 아니라 엑셀, 프로젝트, 워드, 셰어포인트 서버 등 프로젝트 관리자가 이미 익숙히 잘 활용하고 있는 제품들과도 통합되어 사용될 수 있다. 팀 파운데이션의 세 가지 주요한 기능은 다음과 같다.

◆ 팀원간 의사 교류 및 협업 : 프로젝트팀원간의 원만한 의사 교류 및 협업을 위해 작업 아이템 데이터베이스를 중앙에 유지하여 항상 작업 아이템의 최신 상태가 유지될 수 있다, 또한 체크인, 체크아웃 기능을 도입하여 해당 작업 아이템의 진행 상태를 모니터링할 수 있고 각 팀원의 작업 결과가 즉시 반영될 수 있도록 한다.

◆ 소프트웨어 프로세스 관리 : 소프트웨어 프로세스를 관리 도구에 반영하여 작업 할당과 작업 완료 여부가 자동화되어 프로젝트팀원간에 공유된다. 소프트웨어 프로세스 구성 항목은 문서 템플릿, 작업 아이템, 워크플로우, 보고서, 보안 그룹, 체크인 정책 및 프로세스 가이드 등으로 이들 항목들은 방법론 템플릿 형식으로 제공된다.

◆ 풍부한 리포트 관리 : 각 작업 아이템에 대한 진행 상황을 리포트로 생성하고, 해당 작업 아이템이 완료되었는지 추적하거나 결과가 어떻게 되었는지에 관련된 코드를 볼 수도 있다. 개발자는 또한 코드 체크인을 작업 아이템이나 그것이 필요한 빌드와 연관지을 수 있다.

만약 어떤 버그가 테스트에서 실패했다면 팀 파운데이션에서 테스트하는 동안 무엇이 잘못되었는지를 보여주고, 개발자가 손쉽게 수정 보완할 수 있도록 테스트 코드를 보여주며, 수정한 것이 테스트를 통과하는지 확인할 수 있다. 테스터가 버그를 올린 것에 대해 현재 버그가 어느 정도 발생되고 있는지, 계획한 분포를 따르고 있는지를 추적할 수 있으며, 성능 검사를 하거나 테스트 케이스를 실행했을 때 결과에 대한 정보를 그래프로 볼 수 있어 프로젝트 상태를 즉시 확인해 볼 수 있다.

프로젝트 매니저는 프로젝트가 정해진 날짜에 완료될 수 있는지 검사할 수 있으며, 이 모든 것이 한 곳에서 처리될 수 있다.

Do more with less
지금까지 팀 시스템이 제공하는 새로운 다양한 기능에 대해서 살펴봤다. 비용 측면뿐 아니라 효율적이고 생산적인 리소스 활용 측면에서 운영을 고려한 시스템 설계(디자인)가 중요하게 인식되고, 성공적인 소프트웨어 개발을 위해 프로젝트 팀원간의 다이나믹한 정보 공유 및 협업이 부각되며, 빈번하게 요청되는 다양한 보고서 생성을 위한 번거로운 수작업으로 불필요한 리소스를 소비하고 있다면 팀 시스템이 바로 문제의 답일 것이다.

기존의 비주얼 스튜디오 제품이 코드를 작성하는 개발 업무에 보다 초점을 두었다면 팀 시스템은 설계(디자인), 개발, 배포 주기 등 IT 라이프사이클 전 공정에서 개발 프로젝트팀원 전체를 위해 도구로 상호운영성과 개방형 표준을 지향하는 MS의 사상이 반영된 제품이기도 하다. ‘Do more With less(더 적은 자원으로 더 많은 것을)’, 이제는 실행에 옮겨야 할 때이다. @

* 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다.