본 원고는 월간 마이크로소프트 2010년 3월호에 기고한 원문입니다.
Visual Studio 2010을 활용한 ALM(Application Lifecycle Management)
-
ALM 이란 무엇인가?
-
효율적인 프로젝트를 위한 애자일한 프로세스 – 프로세스 강요
-
명확한 작업의 관리와 지속적인 통합 – 추적성
-
과거와 현재를 알면 미래가 보인다 – 가시성
-
ALM 과 가상화의 만남 – Test and Lab Management |
|
 엄준일 : 닷넷엑스퍼트(.NETXPERT) 에 선임 컨설턴트로 재직 중이며, Microsoft Team System MVP 로 활동하고 있다. 많은 대기업 프로젝트와 컨설팅 경험을 바탕으로 좀 더 좋은 소프트웨어를 만들기 위한 기반을 만들며, .NET 은 우리의 미래 동반자임을 확신하고 꾸준히 새로운 기술을 전파하고 있다. (http://blog.powerumc.kr)
|
작성자: 엄준일 선임/ Microsoft MVP
감수자:안재우 수석/Microsoft MVP
ALM(Application Lifecycle Management) 의 개요
최근 몇 해 사이에 ALM(Application Lifecycle Management)라는 용어를 자주 듣게 되었고, ALM에 대해 논의를 하게 되고, ALM 을 해야 한다라는 말을 자주 듣게 됩니다. 최근 들어, 실제로 많은 기업이나 조직에서 ALM 도입을 검토하고 있고, 왜 ALM에 대해 열광하는지에 대해서도 궁금한 부분이 아닐 수 없습니다. 그렇다면 우리는 이제 ALM이 무엇이고, 왜 등장하였으며, ALM에 대한 오해와 진실에 대해서 충분히 이야기를 나눌 가치가 있다고 생각합니다.
ALM 이란?
ALM(Application Lifecycle Management, 이하 ALM)을 한글로 번역하면 "응용프로그램 수명주기 관리" 라고 합니다. 현대 사회는 문화, 언어, 가치관, 기술 등이 빠르게 발전하고 있습니다. 문명의 발전이 없다면 죽은 문명이고, 마찬가지로 소프트웨어가 변화하고 발전하지 않으면 죽은 소프트웨어나 마찬가지 입니다. ALM 을 쉽게 말하면 바로 이런 소프트웨어가 생산되고 릴리즈, 유지, 관리하기 위한 기술을 총칭합니다.
ALM 등장배경
예전부터 소프트웨어를 개발하는 방법이 꾸준히 연구되었으며, 그 중 가장 대표적인 방식이 SDLC(Software Development Lifecycle) 입니다.
SDLC 의 대표적인 개발 방법론 중에 폭포수 모델(Waterfall Model)이 있는데, 로이스(Royce) 라는 사람에 의해 정의된 폭포수 모델은 요구사항, 디자인, 구현, 통합, 테스트, 릴리즈, 유지보수라는 단계로 구분이 되며, 각 단계는 순차적으로 진행되게 됩니다. 요구 사항이 없으면, 디자인을 할 수 없고, 디자인을 하지 않으면 구현을 할 수 없는 형태의 개발 방법으로 현 단계에 문제나 오류가 발생하게 반드시 위험 요소를 제거한 후에 다음 단계로 이동하게 됩니다. 이러한 개발 방법은 각 단계별로 상하 연관성이 없고 명확하게 구분되어 있으며, 최근에도 이러한 개발 방법으로 많은 프로젝트가 진행됩니다.
그림 1 일반적인 폭포수(Waterfall) 모델
하지만 최근 이러한 Top-Down 방식의 수직적인 개발 방식에 많은 비판을 받고 있습니다. 초기 계획이 완벽하지 않으면 전체 일정 또는 계획이 완벽하지 않다는 의미이기 때문입니다. 고객도 자신의 정확한 요구 사항을 알지 못합니다. 이런 과정에서 프로토타입(Prototype) 을 고객에게 시연하고 고객의 정확한 요구 사항을 도출해야 합니다. 하지만 고객의 요구 사항은 언제나 변할 수 있습니다. 즉, 완벽한 요구 사항을 정의한 후에, 다음 단계로 넘어간 이후에도 고객의 요구 사항은 변할 수 있고, 그렇다면 어찌되었건 초기 계획이 잘못될 수 밖에 없습니다. 이미 구현과 테스트로 검증이 끝난 기능에도 기능적인 기능의 추가 및 변경, 디자인 요소의 변경 등을 이유로 고객의 요구 사항은 변할 수 있고, 그렇다면 다시 원점으로 돌아가 이전의 계획은 수정이 되어야 하며, 이미 이러한 경우는 최초 계획이 잘못되었다고 생각할 수 밖에 없습니다.
그 이외에도 초기 계획을 얼마나 정확하게 수립할 것인지는 굉장히 민감한 문제이기도 합니다. 초기 계획 단계를 지나치게 명확하게 강조할 경우 그만큼의 비용이나 시간이 추가되는데, 전체 프로젝트의 일정과 대비하여 그것이 지나칠 경우 실제로 구현이나 테스트를 해야 할 시간은 촉박해 질 수 밖에 없습니다. 프로젝트의 기간은 6개월인데 정확한 프로젝트의 계획 수립을 위해 3개월의 시간을 소비한다면 분명 구현이나 테스트를 여유 있게 할 수 없을 것입니다. 고객을 이해시킬 수 있는 신뢰된 계획안을 보여줄 수 있겠지만, 오히려 불필요한 문서의 양산할 수 있을 가능성이 충분합니다. 이런 경우 프로젝트의 단계별로 거꾸로 기간을 산정하는 역산법 등을 이용하기도 합니다.
폭포수 모델(Waterfall Model)은 여러 가지의 문제 제기를 통해 다양하게 변형된 모델로 발전해 왔습니다. 여기에서는 설명하지 않을 예정이지만, 소프트웨어 개발 방법론은 여러 가지 변형된 형태로 발전해왔음을 알 수 있습니다.
그렇다면, ALM 의 등장 배경을 얘기 하기 위해 왜 이렇게 긴 SDLC(Software Development Lifecycle) 이야기를 했을까요? 위의 이야기에서 볼 때 SDLC 는 바로 소프트웨어를 개발하기 위한 방법론이라는 것입니다. SDLC 는 소프트웨어 공학에서 정의하는 용어로써, 소프트웨어를 효과적으로 개발하기 위한 다양한 방법을 이야기 한다는 것입니다. 즉, SDLC 은 소프트웨어를 개발하는 기술적인 관점을 이야기 합니다.
ALM 은 바로 소프트웨어를 개발하기 위한 기술적인 관점과 더불어 비즈니스적인 가치를 융합하도록 합니다. 소프트웨어의 개발은 기술적이거나 방법적인 문제와 더불어, 실제로 조직 간의 이해 관계, 그리고 비즈니즈 관계의 영역까지 확대됩니다. 소프트웨어를 개발하기 위해 프로젝트의 비전이나 목표 그리고 이것을 이행하기 위한 여러 방법론적인 단계는 통합되고 유기적인 관계입니다. 단지 기술적인 관점에서 바라보는 것이 아닌, 비즈니스 관점에서의 이해 관계나 조직의 측면도 ALM 에서 포괄하고 있습니다.
그렇다면 ALM 은 전혀 새로운 기술이 아님을 알 수 있습니다. ALM 은 이미 오래 전부터 조직적으로 알게 모르게 수행하였고, ALM 을 수행하기 위해서는 어떠한 프로세스적인 요소를 강제하고 있었습니다. 마치 군대에서 기상->아침 구보->보고(점호)->아침 식사-> … -> 저녁 식사->청소->보고(점호)->취침 과 같이 매일 반복되는 프로세스와도 유사할 수 있습니다. 그리고 이런 프로세스가 잘 진행되는지의 여부를 알기 위해 상사에게 "보고" 하는데 소프트웨어 개발 측면에서는 각종 산출물이나 보고서가 필요합니다. 그리고 병사들이 야간 근무를 교대하고 활동을 추적하기 위해 교대 시간마다 기록을 하게 됩니다.
|
프로세스 강요(Process Enactment) |
일관된 프로세스를 강요해야 함 |
|
가시화(Visibility) |
모든 전반적인 활동에 대한 진행 상황을 볼 수 있어야 함 |
|
추적성(Traceability) |
모든 활동이나 산출물 등 연관 관계를 추적할 수 있어야 함 |
표 1 ALM 의 3대 구성 요소
하지만, 이러한 일련의 통일되고 융합된 활동을 한다는 것은 쉽지 않습니다. 문서화나 정형화된 프로세스조차 없는 팀이나 조직이 있는 경우도 있고, 암묵적인 프로세스가 존재하지만 어쨌든 이런 프로세스를 강요한다는 것은 쉽지 않습니다. 또한 팀의 매니저 또는 PM(Project Manager) 나 그 위의 상부 조직은 일이 잘 진행되는지 궁금해 하기 때문에, 이러한 이유로 개발자는 팀장 또는 상사에게 일일 보고서나 주간 보고서를 작성하고, 이것을 다시 취합하여 최종 보고서로 작성합니다. 프로젝트의 단계가 진행될수록 보고서의 양은 늘어나고, 그 종류도 다양해질 것입니다. 어찌 보면, 프로젝트를 위한 프로젝트가 아닌, 보고서를 위한 프로젝트가 되어버리는 셈입니다.
이젠 활동이나 작업을 추적하는 것도 어려울 것입니다. 수십 수백의 여러 가지 종류의 보고서는 이제 버전 관리 하기 조차 버거워질 수 있습니다. 또한 각 역할 담당자들은 결과물, 인도적 차원, 유지보수 차원에서 다양한 산출물을 양산해 냅니다. 필요에 의해 과거의 산출물을 찾는 것도 어렵고, 산출물 자체를 유지 보수 하는 것도 어려워 집니다. 그 외에도 변화하는 모든 활동들은 어떻게 변화했는지조차 알 길이 없습니다. 다양한 산출물과 활동, 그리고 변화에 대한 추적이 불가능 하다면 이미 양산된 문서를 관리하는 것은 결국 의미 없는 활동일 수 있습니다. 실제로 컨설팅 의뢰로 기업을 방문하여 문제를 진단하기 위해 몇 가지 산출물을 요청하여 받은 적이 있으나, 아키텍처가 실제 시스템과 너무 달랐고, 언제, 어떻게 달라졌는지 아는 사람은 아무도 없었던 적도 다반사이기도 합니다.
ALM 의 3대 구성 요소를 조직 전반적으로 융합하기 위해서는 ALM 솔루션이 필요합니다. 관리가 어렵고 정확성을 요구하는 ALM 을 좀 더 쉽게 실현할 수 있는 도구가 필요하다는 것입니다. 초기의 ALM 은 마케팅적인 용어로 사용되면서 초기 ALM 솔루션도 매우 난해했습니다. 단순히 이슈 추적 기능과 소스 제어 기능을 합하여 ALM 이라고 하였으며, 어떤 ALM 솔루션은 테스팅 도구만을 통합하여 ALM 솔루션이라고 하기도 하였습니다.
그림 2 ALM 의 전체적인 컨셉
최근에 ALM 이 정착하는 단계에 들어서면서, 현재의 ALM 과 미래의 ALM 을 분류하기도 합니다. 그리고 아직 이러한 분류 단계는 미성숙한 단계이므로 여러 방면으로 각기 해석을 하고 있습니다. 내용을 정리해 보면 아래와 같이 요약할 수 있습니다.
|
ALM 0.5 (미성숙 단계) |
단순히 여러 가지 소프트웨어 개발 도구를 통합한 제품 |
|
ALM 1.0 |
개발 프로세스의 일관성과 소프트웨어 개발 도구를 통합하고, ALM 실현이 가능한 제품 |
|
ALM 2.0 |
다양한 플러그인의 조합 가능하고 크로스 플랫폼 간의 표준적인 방안을 제시.
조직 내부 뿐만 아니라 시장에서의 각종 요구 사항 또는 변화에 대응 |
표 2 ALM 의 단계별 정의
위의 내용으로 볼 때, 앞으로 알아볼 Visual Studio 2010 과 Team Foundation Server 2010 은 이미 ALM 2.0 에 매우 근접해 있습니다. 기본적인 ALM 1.0 요소를 충분히 충족하고 있으며, 각 제품은 확장성이 뛰어나고 다양한 클라이언트를 지원하기 위한 크로스 플랫폼을 실현하였습니다.
ALM 의 오해와 진실
ALM 은 아직까지도 많은 오해와 진실 속에 자주 언급되는 용어입니다. 사실 ALM 을 알고 보면 SDLC(Software Development Lifecycle) 처럼 정형화된 어떤 유형의, 또는 무형의 지식으로 갑자기 나타난 기술이 아닙니다. 그리고 무언가를 해결하기 위한 완벽한 솔루션도 아닙니다. 아직도 마치 ALM 에 대해 뜬 구름 잡는 듯한 느낌이 든다면 아래의 몇 가지 질문 답변 형식으로 좀 더 ALM 에 대해 오해와 진실을 이야기 해보도록 하겠습니다.
Q: 그럼 도대체 ALM 은 무엇인가요?
A: 마치 Web 1.0 과 Web 2.0 을 비교하는 것과 같습니다. 기존 Web 1.0 은 기업이나 서비스 제공자에 의해 제공되고 그 주체가 바로 기업이나 서비스 제공자였습니다. 하지만 Web 2.0 의 컨셉은 개방, 협력, 참여, 공유라는 요소를 중심으로 차츰 주체가 사용자에게로 이동하는 트랜드화된 용어이기도 합니다. Web 2.0 의 대표적인 것이 바로 UCC 나 위키피디아(Wikipedia) 와 같은 것들이 있습니다.
ALM 도 이런 트랜드에 크게 벗어나지 않는 용어입니다 ALM 은 궁극적으로 3대 구성 요소를 쉽게 실현할 수 있도록 하였지만, 이것을 실현하기 위해 설계, 개발, 테스트, 유지 보수 등 개발 조직, 운영 조직, 비즈니스 조직 등 여러 조직간에 의사 소통이나 각 단계별로 독립적인 활동을 유기적으로 통합하고 신뢰할 수 있는 데이터를 제공할 수 있도록 ALM 솔루션은 여러 가지 도구와 연동하거나 통합하고 자동화하였습니다.
최종 소프트웨어를 사용할 고객은 품질 좋은 소프트웨어를 사용하길 기대합니다. 요구 사항, 아키텍처, 개발, 테스트, 릴리즈, 유지 및 관리, 추적 등 모든 과정을 ALM 솔루션 안에서 이루어 집니다. 이후에 설명한 Visual Studio 2010 과 Team Foundation Server 2010 을 이용하여 개발 프로세스가 어떻게 개선되고 편리해지며, 어떻게 ALM 을 실현하는지에 대해 천천히 짚고 넘어갈 예정입니다.
Q: 그럼 ALM 을 실현하려면 ALM 솔루션이 필요한가요?
A: 아닙니다. ALM 을 실현하기 위해서 반드시 ALM 솔루션이 필요하지 않습니다. 위에서 군대를 예로 든 ALM 의 3대 구성 요소를 설명한 바 있습니다.
실제로 여러 프로젝트를 경험하면서 ALM 과 유사한 경험을 많이 해 보았을 것입니다. UML 도구를 사용하고 엑셀로 요구 사항이나 개발 진행 관리, 그리고 엑셀의 함수나 스크립트를 이용하여 보고서를 만들고, 테스트와 테스트 문서 및 코드 리뷰 과정을 수동적으로 한 바 있습니다. 사실 관리적인 부분만 본다면 엑셀만큼 뛰어난 도구도 없을 것입니다.
하지만 실제로 수동적인 ALM 실현은 많은 어려움이 따릅니다. 가장 먼저 문서를 매번 업데이트해야 하는 시간적인 문제와 문서의 버저닝(Versioning), 변화에 따른 계획의 수정 및 문서 수정, 테스트를 위한 테스트 케이스 관리 및 테스트 결과 문서화, 그리고 수동적인 코드 리뷰는 사실상 있으나 마나 한 단계이기도 합니다. 특히 반복적인 짧은 릴리즈는 밤을 새게 하는 주요 원인 중의 하나이기도 합니다. 릴리즈 계획도 문제였지만, 버그의 발생은 곧바로 버그의 상황을 문서로 만들어져야 하는 산출물이 되기도 하기 때문입니다.
분명 ALM 솔루션은 여러 가지 어려웠던 요소들을 통합하고 자동화하였습니다. 결과적으로 ALM 은 도구가 없이도 가능하지만, 실현하기 위해서 훨씬 많은 노력이 필요하다는 것입니다.
Q: 우리 팀은 형상 관리(소스 제어) 만으로도 프로젝트가 잘 됩니다. 과연 ALM 솔루션이 필요한가요?
A: 맞습니다. 현재 자신의 팀이나 조직에서 정형화된 프로세스나 암묵적인 프로세스가 존재하고, 개별적인 문서 관리와 소스 제어만으로 ALM 을 실현할 수 있습니다. 그렇다면 현재 자신의 조직이나 팀은 ALM 레벨은 ALM 0.5 세대에 있다고 보시면 됩니다.
소프트웨어의 품질을 높이기 위해서는 많은 노력이 필요합니다. 소스 코드나 문서의 버전 관리, 테스트, 보고서, 빌드, 이슈나 작업의 추적은 한 두 명의 개인이 수행하기는 매우 힘듭니다. 그렇기 때문에 보다 도구를 통합하고 자동화된 솔루션을 통해 ALM 을 수행한다면 훨씬 많은 이점이 있습니다.
Q: 그럼 ALM 을 원활하게 수행하기 위해서는 통합된 ALM 솔루션이 필요한가요?
A: 그렇지 않습니다. 현재 소프트웨어를 개발에 필요한 많은 도구들이 오픈 소스 또는 무료로 제공이 되고 있습니다.
아래는 오픈 소스 중에 .NET 환경에서 사용할 수 있는 도구들을 정리한 표입니다.
표 3 Team Foundation Server 와 오픈 소스 기반의 도구를 통한 ALM 도구 비교
하지만 오픈 소스를 사용하는 것은 저렴하게 ALM 환경을 갖출 수 있지만, 이음매 없는 매끈한 끈과도 같습니다. 도구들 간에 서로 연관성이 없거나 업그레이드가 되지 않는 것들도 상당히 존재하기 때문입니다. 통합되지 않은 각 도구들은 누가 관리를 할 것이며, 연관성이 없는 각 도구들 간의 프로세스를 어떻게 강요할 것인가도 고민해 보아야 할 부분입니다.
