지속적 통합의 미래를 넘어선 ALM의 미래-2

오늘 날 모든 기업은 서류 종이를 버리고, 데이터베이스를 통한 전산화가 되었듯이, 오늘 날 팀 프로젝트는 과거를 회고하고, 현재의 내 위치를 알 수 있으며, 그리고 미래를 계획할 수 있는 ALM 을 통한 프로젝트로 점차 발전하고 있습니다. 한 기업 내의 조직마다 서로 다른 업무 프로세스는 ALM 을 통해 체계적으로 통합을 지속할 수 있습니다.

■계획 수립

프로젝트는 최초 계획 수립을 위한 과정이 필요합니다. 즉 비용과 가용 가능한 리소스라는 측면에서 프로젝트의 진행 여부가 결정이 되고 기간을 수립하게 됩니다. 그리고 프로젝트가 진행되는 기간에는 수 많은 이슈가 생겨나기 마련입니다. (일반적으로 이슈는 계획 되지 않은 추가적인 작업이나 리소스가 필요하게 됩니다)

1981년, 배리 뵘(Barry Boehm) 은 아래와 같은 그래프를 그렸고, 이 그래프는 이후 스티브 맥코널(Steve McConnell) 이란 사람에 의해 '불확실성의 원추(cone of uncertainty)' 라는 이름이 붙여졌습니다. 이 그래프는 일반적으로 불리우는 폭포수 모델(Waterfall) 이라고 불리는 순차적인 개발 방법(sequential development process) 을 쓸 경우 초기 프로젝트의 계획과 일정에 대한 오차가 최대 4배까지 벌어질 수 있다고 합니다. 고객은 마케팅 또는 제품의 릴리즈, 사내 교육, 예산 편성 등을 이유로 초기에 정확한 계획을 요구하며, 이러한 계획이 최대 4배 까지 지연이 된다면 고객은 실패한 프로젝트라고 생각할 수 도 있는 중요한 문제이기도 합니다.

애자일의 점진적이고 반복적인 개발 방법은 계획 자체보다는 계획하는 과정에 집중하고 있으며, 변경이 쉬운 계획을 하도록 합니다. 이미 이러한 반복적인 개발 방법은 애자일(Agile Development Process) 개발 프로세스에서 잘 설명하고 있으며, Team Foundation Server 는 애자일 개발 프로세스를 충실히 이행할 수 있는 MSF for Agile Software Development 을 지원하고 있습니다.

MSF for Agile Software Development v5.0 은 제품 백로그(Product Backlog) 와 반복 백로그(Iteration Backlog) 를 통해 최종 제품의 목표를 정의하고 제품의 목표에 도달하기 위한 상세 항목을 정의하게 됩니다. 이러한 계획 과정을 통해 대략적인 프로젝트 또는 소프트웨어의 제품의 규모를 파악하고 릴리즈를 정의하는 중요한 과정이기도 합니다.

■요구 사항

요구 사항은 고객이 원하는 최종 적인 제품의 목표와 동시에 제품의 명세이기도 합니다. CHAOS 라는 연구 결과(Standish 2001) 에 의하면 '성공적인 프로젝트'란 '초기에 명시한 일정과 예산, 그리고 기능을 모두 만족시킨 프로젝트' 라고 정의하였지만, 아이러니하게 애자일의 대가인 마이크 콘(Mike Cohn) 은 '실패한 프로젝트'란 '초기 정의한 요구 사항 보다 더 나은 아이디어가 개발 과정에 나오지 않는 프로젝트가 실패한 프로젝트이다' 라고 말한바 있습니다.

하지만 우리나라의 소프트웨어 개발 실태는 고객의 요구 사항의 발언권은 언제나 권위적이고, 또 이런 고객의 목소리를 가장 강력하게 차단하는 PM(Project Manager) 이 개발 팀 내에서 우상이 되기도 합니다.

앞의 계획 수립에서 언급한 바, 초기에 완벽하게 계획을 하는 것이 아닌 계획하는 과정에 집중한다고 언급하였습니다. 초기에 완벽하게 정의된 계획은 개발 팀이 계획에만 푹 빠지도록 만들게 되며, 제품의 가치를 전달하는 고객의 목소리를 차단하도록 만들게 됩니다. 그리고 요구 사항 정의서는 분석가, 아키텍처, 개발자, 그리고 프로젝트가 종료되었다는 상징적은 문서로만 존재한다는 것이 가장 큰 문제이기도 합니다.

Team Foundation Server 는 요구 사항 뿐만 아니라, 아키텍처, 테스터 등 IT 조직의 전 분야에 걸친 모든 작업 항목(Work Item) 을 관리할 수 있습니다. 작업 항목은 데이터베이스 웨어하우스(Database Warehouse) 를 통해 지표를 제공하는 보고서로 활용할 수도 있습니다.

■설계

통합 개발 도구(IDE) 에 UML 을 지원한다는 것은 굉장히 환영할 만 합니다. 요구 사항에 대한 Diagram 을 만들고 이것을 작업 항목과 연동하여 개발, 테스트, 버그, 빌드 등 일관된 연결이 가능하며, Diagram 을 통해 작업 항목을 추적할 수 있습니다. 개발자는 UML 과 연결된 작업 항목을 통해 작업의 시나리오나 아키텍처를 이해하고 코드를 개발하기에 유용할 수 있습니다.

또 다른 경우, UML 을 통해 코드를 개발하는 동안 UML 의 설계가 잘못되었을 경우 작업과 링크된 UML 의 잘못된 부분을 지적하거나 잘못된 부분을 고칠 수 있는 경우도 있을 것입니다. 즉, 통합 개발 도구(IDE) 의 UML 지원은 설계 따로 개발 따로인 고질적인 문제를 개선할 수 있는 좋은 방안이 될 수 있습니다.

Layer Diagram 은 물리적인 코드나 어셈블리와 연동이 되어, 관련된 컴포넌트를 쉽게 확인할 수 있습니다. Layer Diagram 과 연결되는 클래스나 어셈블리를 확인할 수 있기 때문에, 설계자 뿐만 아니라 비설계자들도 Diagram 을 이해하고 전체적인 솔루션의 구조를 이해하는데 큰 도움이 될 것입니다.

그 중 Directed Graph document 를 이용한 Dependency Graph 를 표현할 수 있게 되어 컴포넌트간의 관계를 훨씬 시각적으로 표현하였습니다.

■코드

요구 사항을 수집하고 분석하고 설계하는 모든 단계는 바로 기능이 잘 작동하는 코드를 생산하기 위해 만들어지는 것이라고 볼 수 있습니다. 초기의 여러 IDE 제품은 코드를 쉽게 만들 수 있는 에디터와 코드를 디버깅 할 수 있는 기능이 초점이었다면 최근의 IDE 제품은 개발의 편의성과 디버깅의 통합에 포커스를 맞추었다고 볼 수 있습니다.

진화된 디버그 경험은 어플리케이션의 중대한 오류나 잘못된 값의 전달로 진화되는 오류 등을 찾기 위해 기계적으로 반복하는 디버깅은 더 이상 필요하지 않습니다. 향상된 디버그 기능은 어플리케이션의 이벤트나 동작을 기록하여 보여주며, 메모 등을 기록할 수 있습니다.

그리고 디버깅 기록은 로그 파일로 기록할 수 있습니다. 디버깅의 로그는 테스트 팀에서 발생한 오류가 개발팀으로 로그 파일과 함께 통보 되면 개발 팀에서는 Trace Log 파일을 이용하여 재생이 가능함으로써 오류의 원인을 분석할 수 있습니다. 또는 개발자간에 코드상의 문제의 원인을 파악하는데 도움을 줄 것입니다.

그리고 코드를 개발하기 위해 정책적인 강제화를 할 수 있어야 합니다. 체크인(Check-in)을 통해 소스 코드가 저장소로 저장이 되기 전에 팀의 코드 정책을 만족하지 않으면 체크인 동작을 수행할 수 없도록 합니다. 예를 들어, 코드 분석(Code Analysis) 기능을 통해 성능 저하가 발생하는 코드나 SQL 인젝션(Injection) 가능성이 있는 코드, 단위 테스트를 통과하지 못한 코드는 체크인을 할 수 없도록 할 수 있습니다.

아래는 팀 작업에 있어 대표적인 체크인 정책의 예입니다.

이 이외에도 코드 분석 규칙이나, 체크인 정책은 다양하게 확장이 가능하며, CodePlex 사이트 등에서 코드 커버러지 정책(Code Coverage Policy), 코드 주석 정책(Code Comment Policy), 코드 리뷰 정책(Code Review Policy) 등을 무료로 제공합니다.

http://www.codeplex.com/site/search?projectSearchText=checkin%20policy

특히, 지속적으로 유지되고 관리되는 소스 코드는 그 변경 이력을 추적하는 것이 어려워질 수 있습니다. 그렇기 때문에 코드 상에 이력의 흔적을 남기는 주석을 추가하는 등 실제 로직의 코드를 변경하기 위해 주석 등으로 이력을 남기는 등의 작업은 코드를 매우 산만하게 보이게 하기도 합니다. 이러한 경우 정확한 추적 기능은 코드의 이력을 명확하고 시각적으로 보여줄 수 있어야 합니다.

■빌드

통합 빌드 작업은 솔루션 또는 솔루션 집합을 분산 환경에서 빌드할 수 있어야 합니다. 팀 빌드는 어플리케이션을 빌드 하기 위한 여러 가지 작업이 포함이 될 수 있기 때문입니다.

통합 빌드는 여러 조직 또는 팀, 개발자 간에 분산된 소스 코드를 동기화하여 어플리케이션 빌드를 수행합니다. 빌드를 수행 하는 과정에서 단위 테스트를 실행하고 실패한 테스트가 있을 경우 팀 빌드는 즉시 중단이 가능합니다. 그리고 빌드 된 어셈블리의 코드 분석을 실시하여 정책적으로, 또는 보안에 취약한 코드를 검사할 수 있습니다.

특히 어플리케이션의 배포는 매우 번거롭거나 정확성을 요구하는 작업입니다. 예를 들어, n-Tier 아키텍처의 어플리케이션은 여러 시스템으로 분산적인 배포가 가능해야 하는데, 정확성을 요구하는 작업은 자동화된 팀 빌드를 이용하여 수동적인 배포 작업의 오류를 최소화 할 수 있습니다.

통합 빌드는 지속적인 통합(Continuous Integration-CI) 이라는 관점은 어플리케이션을 생산하고 유지하는데 매우 중요한 의미를 시사합니다. 여러 개발자들에 의해 만들어지고 변형되는 소스 코드를 통합하는 것은 필요악이 아닌 개발 프로세스의 일부이며 지속적인 통합을 통해 소프트웨어 개발의 위험성을 줄여나갈 수 있습니다.

Team Foundation Server 2010 의 팀 빌드는 WF 4.0(Windows Workflow Foundation) 을 도입함으로써 빌드 프로세스의 개선이 매우 쉽습니다. 기존에 MSBuild 를 이용하여 스크립트 형태로 팀 빌드 작업을 확장하거나 변형할 수 있었으나, Team Foundation Server 2010 부터는 워크플로우를 통해 빌드 프로세스의 작업 순서나 종속 관계를 표현할 수 있습니다.

■테스트

테스트는 기존에 불필요하게 소비되었던 개발과 테스트 주기에서의 낭비를 줄 일 수 있는 가상 랩 (Virtual Lab) 환경을 제공해 주어야 합니다. 그러기 위해서는 통합 개발 환경(IDE) 과 별도의 테스트 전문 도구가 필요할 수 있습니다. 테스트와 가상 랩 환경에서 테스트를 수행하기 위해 Microsoft 의 Test Professional 과 Lab Manager 제품이 대표적입니다.

Lab Management 는 빠르게 테스트를 수행하고 빌드 자동화를 신속하게 수행할 수 있으며, 테스트 시나리오를 관리하거나 스냅샷(Snapshot) 을 통해 테스트를 재연할 수 있습니다. 테스터는 시스템이나 n-Tier 계층의 어플리케이션의 테스트를 위해 테스트 환경을 구성하지 않고도 랩 환경을 여러 개로 복제하여 사용할 수 있으며, 각 환경 별로 병렬적인 테스트를 진행할 수 있습니다.

과거의 방식은 개발자 별로 로컬 테스트를 진행하고 중앙의 개발 또는 테스트 서버를 이용하여 최종 테스트를 진행하였지만, Lab Manager 는 가상화(Virtualization) 기술을 이용하여 테스트 환경을 분산시키거나 통합, 또는 복제하는 등 여러 가지 방법으로 테스트 관리가 가능합니다. 즉, 동일한 시스템 사양과 테스트 환경을 가상화를 통해 여러 개의 테스트 시스템을 관리함으로써, 성능이나 부하 측정과 같은 다양한 변수가 존재하는 테스트를 위해 다양한 시나리오로 테스트를 진행할 수 있습니다.

그리고 가상화(Virtualization) 기술에 포함되는 스냅샷(Snapshot) 기능 등을 이용하여 원하는 테스트 지점으로 이동할 수 있으므로 최상의 테스트 결과를 얻도록 유도합니다. Lab Manager를 통해 실제 운영 시스템과 테스트 시스템간에 가장 유사한 환경을 구축할 수 있습니다.

특히 테스트 시스템은 주기적으로 운영 시스템과 동기화를 해야 할 필요가 있습니다. 지속적으로 유지 관리 되는 시스템을 개발하기 위해서 최신의 데이터나 실제 운영 환경을 필요로 할 수 있기 때문입니다. 특히 이러한 운영 시스템과 테스트 시스템간의 동기화는 매우 섬세하고 안정성을 요구하는 작업입니다. 이러한 경우 실제 운영 시스템의 환경을 복제하여 테스트 시스템으로 활용하는 등 기존에 상상하기 힘들었던 정교한 작업을 가능하게 합니다.

Test Professional 은 테스터가 테스트 완료 목표를 설정하고 테스트 시나리오를 작성하여 테스트를 수행합니다. 테스트가 실행되는 도중에 모든 화면은 비디오(Video) 로 녹화를 할 수 있으며, 화면을 캡춰(Capture) 하거나 테스트가 수행되는 시스템 환경을 저장할 수 도 있습니다. 이 과정에서 테스트를 진행하는 어플리케이션에서 버그나 오동작가 발생되면 중앙 서버를 통해 개발자에게 비디오나 화면 캡춰 정보 등을 함께 포함하여 개발 팀에게 전달할 수 있습니다. 그리고 개발 팀은 테스트 팀에서 진행한 테스트 케이스의 비디오를 재생하거나 테스트 케이스 단계를 재연할 수 있습니다.

테스트 결과는 비디오(Video) 녹화, 화면 캡춰, 시스템 환경 등을 정보를 포함하여 저장할 수 있기 때문에, 시스템 사양이나 환경이 달라서 발생하는 오류나 테스터가 잘못된 테스트 케이스 시나리오로 실패한 테스트일 경우 이러한 정보는 매우 유용하게 사용할 수 있습니다.

테스트 팀은 통합 개발 도구인 IDE 가 필요하지 않으며, Test and Lab Management 를 통해 쉽게 매뉴얼 테스트(Manual Test), UI 테스트, 테스트 자동화를 진행할 수 있습니다. 테스트 시나리오와 테스트 결과는 서버에 저장이 되며, 개발 팀은 IDE 를 통해 테스트 팀에서 발생한 버그의 알림이나 추적으로 통해 소스 코드나 작업에 신속하게 반영할 수 있습니다.

그리고 코드 또는 로직의 테스트 뿐만 아니라 UI 테스트가 가능해야 합니다. 기존의 UI Automation 라이브러리를 이용하여 복잡한 UI 제어 코드를 작성하여 테스트를 수행하였습니다. 하지만 최근의 어플리케이션은 클라이언트, 웹 브라우저, 모바일 등 다양한 환경으로 확장되면서 데이터 중심의 테스트와 표현상의 테스트가 가능해야 합니다.

ALM 도구를 이용하여 계획 수립과 요구 사항, 설계, 개발, 테스트 등 프로젝트가 시작되고 종료되고 유지되는 동안 모든 일련의 과정을 통합하여 관리를 할 수 있습니다. ALM 이 잘 알려지지 않았던 때에는 프로젝트 팀은 대부분 분석, 설계, 개발, 테스트, 배포 등 모든 과정이 독립적이고 연관성이 없었습니다. 왜냐하면 각 단계별로 팀이 틀리거나 문서마다 저장소가 틀리거나, 커뮤니케이션의 문제, 투입되는 인력의 시간적인 공백, 그리고 사람에 의존하는 수동적인 작업 등이었기 때문입니다. 이러한 순차적인 개발 방법과 수동적인 작업에 의해 프로젝트의 진행 과정은 언제나 반복되고 초기 계획과 다른 결과와 산출물이 나오거나 기간이 지연되기도 하였습니다.

Team Foundation Server 의 협업 시스템은 이해 관계가 다른 조직이나 팀 간의 불협화음을 줄이고 벽을 낮추어 팀 프로젝트에 보다 투명하게 만들 수 있습니다. 순차적인 개발 방법은 좀 더 병렬적으로 전환할 수 있고, 고질적으로 반복되는 프로젝트 진행의 문제는 점차적으로 개선할 수 있습니다. 계획을 수립하고, 설계 및 개발, 테스트, 빌드 등의 여러 단계가 명확하고 체계적으로 연결이 되어 있고, Team Foundation Server 를 통해 복잡한 과정을 단순화하고 추적이나 관리를 쉽게 할 수 있습니다.

■가시성

최근의 소프트웨어 개발 프로세스는 매우 빠르게 변화하고 요구 사항도 빈번하게 변해가고 있습니다. 기존의 순차적이고 수직적인 Waterfall 방식의 소프트웨어 개발 방법론은 요즘의 빠른 변화에 능동적으로 대처할 수 없는 구조이기도 합니다. 예를 들어, 개발 단계에서의 고객의 변경 또는 추가적인 요구 사항은 기존의 분석/설계된 구조를 크게 벗어나거나 영향을 크게 미칠 수 도 있습니다.

프로젝트 진행은 최종 릴리즈를 목표로 하여 대부분의 기능이 구현되어야 합니다. 예를 들어 최초 10개의 시나리오로 100 개의 작업을 완료하는 것이 프로젝트의 릴리즈 목표입니다. 하지만 일반적으로 작업이 릴리즈가 완료될 때까지 시나리오나 작업의 개수가 프로젝트 초기와 똑같거나 비슷하게 유지될 수 없습니다. 그 이유는 고객의 요청 사항이나 팀의 비즈니스 또는 버그, 이슈 등으로 초기 시나리오나 작업은 늘어날 수 밖에 없기 때문입니다.

과거의 대부분의 프로젝트에서의 PM(Project Manager) 는 자신의 과거의 프로젝트 경험과 고객과의 경험을 잣대로 프로젝트를 계획하고 추정하기도 하였습니다. 초기 계획이 잘못 되었거나, 변화를 능동적으로 대처하지 못할 경우 프로젝트는 자칫 위험에 빠질 수 있습니다.

고객은 언제나 프로젝트가 진행되는 상태를 알고 싶어 합니다. 요구했던 기능이 얼마나 구현이 되었는지..? 그리고 언제 프로젝트가 종료되어 완성된 소프트웨어를 사용할 수 있는지..? 프로젝트의 매니저는 고객의 이러한 궁금증에 매번 개발 현황 보고서 등을 주기적으로 만들기 위해, 팀원 별로 개발 진행 상태를 확인하고, 테스트를 하여 검증하는 등 보고서를 만들기 위한 프로젝트가 되는 웃지 못할 일들이 빈번하게 발생이 되곤 합니다.

과거를 돌아보고, 현재 일어나고 있는 변화를 바라보면, 미래의 일도 예견할 수 있다. 왜냐하면 미래에 일어날 일도 분명히 과거와 동일한 형태를 취할 것이며, 현재 일어나고 있는 일의 질서로부터 벗어날 수는 없기 때문이다. 그러므로 인생을 40년동안 관찰하든 1만면 동안 관찰하든 마찬가지다. 그 이상 무엇을 더 볼 수 있겠는가?-아우렐리우스 <명상록> 제 7장

특히 Team Foundation Server 은 뛰어난 확장성과 호환성이 장점입니다. 주로 업무에 사용되는 Microsoft Office 제품과 호환이 가능하여, 작업 항목을 Microsoft Excel 로 내보내거나 Team Foundation Server 와도 양방향 연동이 가능합니다. 실제로 조직 내부에서 특정 양식으로 보고서를 보길 원하고 있기 때문에, Microsoft Excel 등을 이용하여 Team Foundation Server 의 데이터 웨어하우스(Data Warehouse) 와 연결하여 데이터를 가져와서 원하는 형태의 양식으로 표현할 수 도 있습니다. 또는 조직 내 그룹웨어 등의 시스템과 연동하여 보고서를 조회하거나 웹을 통해 게시하는 등 다양한 형태로 보고서를 활용할 수 있습니다.

보고서는 현재의 위치를 알고, 미래를 예측하기 위한 중요한 데이터로 주로 사용되지만, 의외로 고객을 설득 시키거나 이해시키는데 중요한 역할을 하기도 합니다. 예를 들어, 빈번하게 고객의 요구 사항이 변경되거나 추가되는 상태라면 프로젝트의 일정이 지연이 될 수 있을 것임을 예상할 수 있습니다.

대부분 고객의 요청 사항은 사소한 변경 사항이거나 추가적인 기능일 경우, 고객은 그 기능을 소스 코드로 반영하는데 단순 작업이거나 아주 작은 업무의 양이라고 생각하는 경향이 있지만, Team Foundation Server 의 보고서를 통해 작업이 증가함에 따라 작업의 시간이 증가되는 것을 시각화 하여 고객을 이해시킴으로써 팀에게 있어 방어적인 데이터가 될 수도 있습니다.

■정리하며….

지금까지 ALM(Application Lifecycle Management) 를 이용하여 품질 좋은 소프트웨어를 고객이 만족하도록 긴 프로젝트 여정을 무사히 완료한다는 것은 혼자가 아닌 프로젝트의 팀원 전체가 노력하여 맺은 결실일 것입니다.

품질 좋은 소프트웨어를 생산 하기 위해 ALM 이라는 큰 주제를 가지고 많은 이야기를 전해드렸습니다. 그리고 그렇게 하기 위해서는 멋진 설계나 좋은 개발만으로 가능한 것이 아니라는 것도 충분히 이해를 하셨을 것입니다.

즉, 노력의 결실을 맺기 위해서는 적절한 방법론을 선택하고 적절한 프로세스를 강요해야 하며, 이 보다 더 중요한 것은 바로 구성원들의 의지라는 것입니다. 아무리 값 비싼 개발 도구를 쥐어준다고 하더라도 노트패드(NotePad) 로 개발하는 것과 별반 다를 것이 없다면, 값 비싼 개발 도구는 노트패드의 값어치와 별반 다를 것이 없습니다. 거꾸로 말하면, 당장 우리 팀에 ALM 도구를 준다고 하더라도, 그것을 사용하기 위한 기본적인 지침이나 참여가 없다면 값비싼 소스 컨트롤(Source Control) 과 다를 것이 없습니다.

2001년 애자일 선언문의 아래와 같은 일부는 최근 매우 오해되어 해석이 되고 있기도 합니다.

-Individuals and interactions over processes and tools(프로세스와 도구보다는 개인과 상호작용을)

이러한 오해에 대해서 켄트 백(Kent Beck) 은 아래의 글을 통해 도구에 대한 오해를 풀어냅니다.

Tools for Agility - A White paper by Kent Beck, Three Rivers Institute

http://www.microsoft.com/downloads/details.aspx?FamilyId=AE7E07E8-0872-47C4-B1E7-2C1DE7FACF96&displaylang=en

즉, 프로젝트의 기간은 제한적이고, 마지막 완료 시점까지 언제나 불확실성의 연속입니다. 즉 개인과 상호 작용을 아무리 잘해봤자 적절한 프로세스나 도구가 없이는 불가능 합니다. 적절한 도구나 프로세스가 뒷받침되지 않는다면 소프트웨어나 프로젝트의 전체적인 투명성을 입증하기 힘들고, 시간이 지나면서 점점 복잡해지는 소프트웨어나 프로젝트는 팀 구성원의 잦은 컨텍스트 전환(Context Change)에 점점 더 큰 비용이 들어가고 결국 협업 자체가 어려워질 수 있습니다.

만약 이러한 도구나 프로세스가 필요 없을 만큼 기술력이 있는 경우라면 제외합니다.

이제 능동적으로 변화에 대처 가능한 소프트웨어를 만들기 위해서는 도구와 프로세스는 선택이 아닌 필수라는 것입니다. 도구나 프로세스가 뒷받침이 되었을 때 좀 더 애자일(Agile)한 개발을 할 수 있지 않을까요? 인간에게 있어 의식주가 해결되어야 문학, 철학, 예술 등의 활동이 가능한 것처럼, ALM 은 도구가 뒷받침되지 않으면 개인과 상호 작용이라는 활동은 힘들 수 밖에 없습니다.

분명한 것은 ALM 도구를 이용한다는 것은 프로세스와 도구에 치중하는 것이 아닌 ALM 도구를 통해 개인과 상호 작용을 극대화 할 수 있는 협업 시스템이 될 것입니다.