지속적인 통합을 넘어선 ALM의 미래-1

최근 몇 해 사이에 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) 라는 사람에 의해 정의된 폭포수 모델은 요구사항, 디자인, 구현, 통합, 테스트, 릴리즈, 유지보수라는 단계로 구분이 되며, 각 단계는 순차적으로 진행되게 됩니다.

요구 사항이 없으면, 디자인을 할 수 없고, 디자인을 하지 않으면 구현을 할 수 없는 형태의 개발 방법으로 현 단계에 문제나 오류가 발생하게 반드시 위험 요소를 제거한 후에 다음 단계로 이동하게 됩니다. 이러한 개발 방법은 각 단계별로 상하 연관성이 없고 명확하게 구분되어 있으며, 최근에도 이러한 개발 방법으로 많은 프로젝트가 진행됩니다.

하지만 최근 이러한 Top-Down 방식의 수직적인 개발 방식에 많은 비판을 받고 있습니다. 초기 계획이 완벽하지 않으면 전체 일정 또는 계획이 완벽하지 않다는 의미이기 때문입니다. 고객도 자신의 정확한 요구 사항을 알지 못합니다. 이런 과정에서 프로토타입(Prototype) 을 고객에게 시연하고 고객의 정확한 요구 사항을 도출해야 합니다. 하지만 고객의 요구 사항은 언제나 변할 수 있습니다.

즉, 완벽한 요구 사항을 정의한 후에, 다음 단계로 넘어간 이후에도 고객의 요구 사항은 변할 수 있고, 그렇다면 어찌되었건 초기 계획이 잘못될 수 밖에 없습니다. 이미 구현과 테스트로 검증이 끝난 기능에도 기능적인 기능의 추가 및 변경, 디자인 요소의 변경 등을 이유로 고객의 요구 사항은 변할 수 있고, 그렇다면 다시 원점으로 돌아가 이전의 계획은 수정이 되어야 하며, 이미 이러한 경우는 최초 계획이 잘못되었다고 생각할 수 밖에 없습니다.

그 이외에도 초기 계획을 얼마나 정확하게 수립할 것인지는 굉장히 민감한 문제이기도 합니다. 초기 계획 단계를 지나치게 명확하게 강조할 경우 그만큼의 비용이나 시간이 추가되는데, 전체 프로젝트의 일정과 대비하여 그것이 지나칠 경우 실제로 구현이나 테스트를 해야 할 시간은 촉박해 질 수 밖에 없습니다.

프로젝트의 기간은 6개월인데 정확한 프로젝트의 계획 수립을 위해 3개월의 시간을 소비한다면 분명 구현이나 테스트를 여유 있게 할 수 없을 것입니다. 고객을 이해시킬 수 있는 신뢰된 계획안을 보여줄 수 있겠지만, 오히려 불필요한 문서의 양산할 수 있을 가능성이 충분합니다. 이런 경우 프로젝트의 단계별로 거꾸로 기간을 산정하는 역산법 등을 이용하기도 합니다.

폭포수 모델(Waterfall Model)은 여러 가지의 문제 제기를 통해 다양하게 변형된 모델로 발전해 왔습니다. 여기에서는 설명하지 않을 예정이지만, 소프트웨어 개발 방법론은 여러 가지 변형된 형태로 발전해왔음을 알 수 있습니다.

-Spiral model

-Iterative and incremental development

-Iterfall development

-V-Model

-Agile software development

■ALM 의 목적과 필요성

그렇다면, ALM 의 등장 배경을 얘기 하기 위해 왜 이렇게 긴 SDLC(Software Development Lifecycle) 이야기를 했을까요? 위의 이야기에서 볼 때 SDLC 는 바로 소프트웨어를 개발하기 위한 방법론이라는 것입니다.

SDLC 는 소프트웨어 공학에서 정의하는 용어로써, 소프트웨어를 효과적으로 개발하기 위한 다양한 방법을 이야기 한다는 것입니다. 즉, SDLC 은 소프트웨어를 개발하는 기술적인 관점을 이야기 합니다.

ALM 은 바로 소프트웨어를 개발하기 위한 기술적인 관점과 더불어 비즈니스적인 가치를 융합하도록 합니다. 소프트웨어의 개발은 기술적이거나 방법적인 문제와 더불어, 실제로 조직 간의 이해 관계, 그리고 비즈니즈 관계의 영역 까지 확대됩니다. 소프트웨어를 개발하기 위해 프로젝트의 비전이나 목표 그리고 이것을 이행하기 위한 여러 방법론적인 단계는 통합되고 유기적인 관계입니다. 단지 기술적인 관점에서 바라보는 것이 아닌, 비즈니스 관점에서의 이해 관계나 조직의 측면도 ALM 에서 포괄하고 있습니다.

그렇다면 ALM 은 전혀 새로운 기술이 아님을 알 수 있습니다. ALM 은 이미 오래 전부터 조직적으로 알게 모르게 수행하였고, ALM 을 수행하기 위해서는 어떠한 프로세스적인 요소를 강제하고 있었습니다. 마치 군대에서 기상->아침 구보->보고(점호)->아침 식사-> … -> 저녁 식사->청소->보고(점호)->취침 과 같이 매일 반복되는 프로세스와도 유사할 수 있습니다.

그리고 이런 프로세스가 잘 진행되는지의 여부를 알기 위해 상사에게 보고 하는데 소프트웨어 개발 측면에서는 각종 산출물이나 보고서가 필요합니다. 그리고 병사들이 야간 근무를 교대하고 활동을 추적하기 위해 교대 시간마다 기록을 하게 됩니다.

위의 군대를 예로 든 활동들을 정리하면 ALM 의 3대 구성 요소는 아래와 같습니다.

하지만, 이러한 일련의 통일되고 융합된 활동을 한다는 것은 쉽지 않습니다. 문서화나 정형화된 프로세스조차 없는 팀이나 조직이 있는 경우도 있고, 암묵적인 프로세스가 존재하지만 어쨌든 이런 프로세스를 강요한다는 것은 쉽지 않습니다.

또한 팀의 매니저 또는 PM(Project Manager) 나 그 위의 상부 조직은 일이 잘 진행되는지 궁금해 하기 때문에, 이러한 이유로 개발자는 팀장 또는 상사에게 일일 보고서나 주간 보고서를 작성하고, 이것을 다시 취합하여 최종 보고서로 작성합니다. 프로젝트의 단계가 진행될수록 보고서의 양은 늘어나고, 그 종류도 다양해질 것입니다. 어찌 보면, 프로젝트를 위한 프로젝트가 아닌, 보고서를 위한 프로젝트가 되어버리는 셈입니다.

이젠 활동이나 작업을 추적하는 것도 어려울 것입니다. 수십 수백의 여러 가지 종류의 보고서는 이제 버전 관리 하기 조차 버거워질 수 있습니다. 또한 각 역할 담당자들은 결과물, 인도적 차원, 유지보수 차원에서 다양한 산출물을 양산해 냅니다. 필요에 의해 과거의 산출물을 찾는 것도 어렵고, 산출물 자체를 유지 보수 하는 것도 어려워 집니다.

그 외에도 변화하는 모든 활동들은 어떻게 변화했는지조차 알 길이 없습니다. 다양한 산출물과 활동, 그리고 변화에 대한 추적이 불가능 하다면 이미 양산된 문서를 관리하는 것은 결국 의미 없는 활동일 수 있습니다. 실제로 컨설팅 의뢰로 기업을 방문하여 문제를 진단하기 위해 몇 가지 산출물을 요청하여 받은 적이 있으나, 아키텍처가 실제 시스템과 너무 달랐고, 언제, 어떻게 달라졌는지 아는 사람은 아무도 없었던 적도 다반사이기도 합니다.

ALM 의 3대 구성 요소를 조직 전반적으로 융합하기 위해서는 ALM 솔루션이 필요합니다. 관리가 어렵고 정확성을 요구하는 ALM 을 좀 더 쉽게 실현할 수 있는 도구가 필요하다는 것입니다. 초기의 ALM 은 마케팅적인 용어로 사용되어 지면서 초기 ALM 솔루션도 매우 난해했습니다. 단순히 이슈 추적 기능과 소스 제어 기능을 합하여 ALM 이라고 하였으며, 어떤 ALM 솔루션은 테스팅 도구만을 통합하여 ALM 솔루션이라고 하기도 하였습니다.

최근에 ALM 이 정착한 단계에 들어서면서, 현재의 ALM 과 미래의 ALM 을 분류하기도 합니다. 그리고 아직 이러한 분류 단계는 미성숙한 단계이므로 여러 방면으로 각기 해석을 하고 있습니다. 필자 또한 이러한 내용을 바탕으로 아래와 같이 정의하였습니다.

최근 ALM 솔루션은 ALM 2.0 을 추구합니다. 조직이나 팀 별도 가장 최적화된 특정 벤더나 제품을 사용하는 것은 ALM 을 수행하기 위한 유지보수의 비용적인 증가와 더불어, 장기적으로 팀과 조직간의 어떠한 프로세스도 통합할 수 없다는 것을 의미할 수 도 있기 때문입니다. 이러한 의미에서 ALM 2.0 의 확장성과 크로스 플랫폼의 실현은 현대의 소프트웨어 개발에 있어서 가장 현실적인 대안이 될 것입니다.

■ALM 을 통한 체계적인 프로세스 통제

이전 ALM 에 대해서 살펴 보았듯이, 소프트웨어를 개발 하기 위해서는 SDLC(Software Development Leftcycle) 과 같이 효율적인 개발 방법을 적용하기 위한 방법론들이 연구되어 왔습니다. 최근에 이러한 개발 방법이나 프로세스는 여러 형태로 변형되고 개선이 되면서 Agile(애자일) 이라는 개발 방법 또는 프로세스 형태로 발전해 왔습니다.

Microsoft 에서도 소프트웨어 공학적인 측면에서 여러 가지 방법론적인 시도를 MSF(Microsoft Solution FRAMEwork) 라는 이름으로 지속해 왔습니다. Microsoft Solution FRAMEwork(이하 MSF) 는 소프트웨어를 개발하기 위해 비전, 원칙, 모델, 개념 등을 체계화시켜 가이드라인을 제공하는 지침입니다. 프로젝트의 수명 주기를 관리하기 위해서 아키텍처, 개발, 테스트, 릴리즈, 관리 등의 다양한 측면에서 적절한 행동 지침을 제공하고 프로세스의 흐름을 가이드 합니다.

특히 MSF 는 특정한 개발 방법론, 예를 들어 폭포수 모델(Waterfall Model) 이나 애자일(Agile) 과 같은 특정한 방법론을 강요하지 않는다는 점입니다. 즉, 현재의 자신의 인프라 내에 존재하는 프로세스를 완전히 바꾸기 보다는 각 역할별 행동이나 프로세스를 개선하거나 좀 더 명확히 할 수 있는 좋은 지침이 된다는 것입니다. 반대로 자신의 인프라의 프로세스가 비효율적이거나 합리적이지 않았다면, MSF 를 통해 좀 더 세련되도록 개선할 수 있는 가능성을 제시해 줍니다.

현대의 소프트웨어 개발은 협업이 필수 아닌 조건이 되었습니다. 예를 들어, 예전에는 게임을 개발하기 위해 소수의 정예 팀원이 기획, 개발, 사운드, 그래픽, 테스트 등 소위 팀원이 모두 다재다능 하였으나 지금은 더 이상 그러한 형태로 개발할 수 없습니다. 현대의 소프트웨어는 점점 엔터프라이즈화 되어 가고 대용량화 되어 갑니다. 조직은 분명하게 정의되고 MSF 와 같은 정보 기술 솔루션을 채택하는 것이 현명한 협업 솔루션의 시작이라고 할 수 있습니다.

■대표적인 상용 ALM 솔루션

-Microsoft - Team Foundation Server

Team Foundation Server 는 유연하고 확장하기 용이한 프로세스 모델을 기반으로 RDBMS 에 모든 데이터를 저장합니다. 작업 항목(Work Items) 을 기반으로 변경 관리, 버전 관리, 구성 관리, 코드, UML, 테스트 등을 Visual Studio 개발 도구와 웹을 이용하여 사용할 수 있으며, Microsoft Office 제품과도 통합이 되어 있습니다.

그리고 Team Foundation Proxy 를 이용하여 글로벌(Global) 한 대규모 분산 환경을 구축하기가 용이합니다. 특히, 최근 Team Foundation Server 2010 제품은 데이터의 시각화와 크로스 플랫폼 지원, 워크플로(Workflow) 통합, Test and Lab 도구를 이용하여 QA 팀을 위한 테스트 전문 도구, 가상화에 대한 테스트, 배포, 관리 부분에서 강력한 기능을 제공합니다.

-Borland - StarTeam

StarTeam 은 유연하고 확장하기 쉬운 구조로 되어있습니다. 특히 StarTeam 은 다양한 클라이언트의 관리 도구를 지원하고 있으며, 이미 잘 알려진 Waterfall, Agile, RUP 등의 개발 프로세스를 지원합니다. 또한 Team Foundation Server 와 마찬가지로 지리적인 문제로 인한 성능 향상을 위해 웹 프로바이더(Web Provider) 를 통해 원격 캐싱(Remote Caching) 을 지원하여 분산 환경 구축과 중앙 집약적인 운용이 가능합니다.

IBM - ClearCase, ClearQuest

Rational Software 의 ALM 솔루션으로 다른 여러 가지의 개발 프로세스를 지원하고 통합할 수 있습니다. ClearQuest 는 워프플로 자동화 도구로써 결함, 기능 개선, 문제 문서 변경 등 모든 유형의 변경 요청을 관리합니다. ClearCase 는 소스 코드 관리 도구로써 코드 이력, 복제, 추적, 통합 등의 기능을 제공합니다. 특히 ClearCase 는 MultiVersion File system(MVFS) 이라고 하는 가상 파일 시스템(Virtual File system) 을 통해 로컬과 원격 파일 간에 손쉽게 작업할 수 있는 다이나믹 뷰(Dynamic View) 환경을 제공합니다.

■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 솔루션 안에서 이루어 집니다. 소프트웨어가 한번의 릴리즈 이후에 변하지 않는다는 것은 죽은 소프트웨어나 마찬가지 입니다. 즉, ALM 은 지속 가능한 소프트웨어를 위해 소스 코드 뿐만 아니라, 변화 관리, 팀 관리, 지속적인 통합은 더욱 품질 좋은 소프트웨어를 릴리즈하기 위한 가치와 노력을 최소화 할 수 있도록 도와주는 솔루션 입니다.

Q: 그럼 ALM 을 실현하려면 ALM 솔루션이 필요한가요?

A:아닙니다. ALM 을 실현하기 위해서 반드시 ALM 솔루션이 필요하지 않습니다. 위에서 군대를 예로 든 ALM 의 3대 구성 요소를 설명한 바 있습니다.

실제로 필자는 여러 프로젝트를 경험하면서 ALM 과 유사한 경험을 많이 해 보았습니다. UML 도구를 사용하고 엑셀로 요구 사항이나 개발 진행 관리, 그리고 엑셀의 함수나 스크립트를 이용하여 보고서를 만들고, 테스트와 테스트 문서 및 코드 리뷰 과정을 수동적으로 한 바 있습니다. 사실 관리적인 부분만 본다면 엑셀만큼 뛰어난 도구도 없을 것입니다.

하지만 실제로 수동적인 ALM 실현은 많은 어려움이 따릅니다. 가장 먼저 문서를 매번 업데이트해야 하는 시간적인 문제와 문서의 버저닝(Versioning), 변화에 따른 계획의 수정 및 문서 수정, 테스트를 위한 테스트 케이스 관리 및 테스트 결과 문서화, 그리고 수동적인 코드 리뷰는 사실상 있으나 마나 한 단계이기도 합니다. 특히 점진적이고 반복적인 짧은 릴리즈는 밤을 새게 하는 주요 원인 중의 하나이기도 합니다. 릴리즈 계획도 문제였지만, 릴리즈 행위 또는 그에 따른 버그의 발생은 곧바로 그 상황을 문서로 만들어져야 하는 산출물이 되기도 하기 때문입니다.

분명 ALM 솔루션은 여러 가지 어려웠던 요소들을 통합하고 자동화하였습니다. 결과적으로 ALM 은 도구가 없이도 가능하지만, 실현하기 위해서 훨씬 많은 노력이 필요하다는 것입니다.

Q: 우리 팀은 형상 관리(소스 제어) 만으로도 프로젝트가 잘 됩니다. 과연 ALM 솔루션이 필요한가요?

A: 맞습니다. 현재 자신의 팀이나 조직에서 정형화된 프로세스나 암묵적인 프로세스가 존재하고, 개별적인 문서 관리와 소스 제어만으로 ALM 을 실현할 수 있습니다. 그렇다면 현재 자신의 조직이나 팀은 ALM 레벨은 ALM 0.5 세대에 있다고 보시면 됩니다.

소프트웨어의 품질을 높이기 위해서는 많은 노력이 필요합니다. 소스 코드나 문서의 버전 관리, 테스트, 보고서, 빌드, 이슈나 작업의 추적은 한 두 명의 개인이 수행하기는 매우 힘듭니다. 그렇기 때문에 보다 도구를 통합하고 자동화된 솔루션을 통해 ALM 을 수행한다면 훨씬 많은 이점이 있습니다.

■통합 ALM 솔루션과 오픈 소스 비교

이미 잘 통합된 ALM 솔루션을 사용하기 위해 제품별로 라이선스 정책이나 비용이 천차만별 입니다. 이러한 면에서 오픈 소스 ALM 은 비용이 적고 운용에 익숙한 도구를 선택함으로써 장점이 될 수 있습니다.