ALM은 ‘Application Lifecycle Management’의 약자이기도 하고, 한글로 번역하자면 ‘응용프로그램 수명주기 관리’라고 합니다. 그럼 도대체 ALM이라는 게 등장하게 된 계기는 무엇일까요?
처음 시발점을 말하면, ALM이라는 단어는 사실 Web 2.0이라는 단어와 마찬가지로 마케팅 용어라고 할 수 있습니다. 완전히 새롭게 등장한 용어도 아니며, 소프트웨어 개발 프로세스와 프로젝트 관리적인 내용을 결합한 것에 그냥 이름을 가져다 붙인 것에 불과합니다. 좀 더 정확하게 말하자면, 예전 개발 플랫폼이나 솔루션 회사들이 개발 도구나 모델링 도구를 각각 단품으로 제공하던 것에 비해 개발 전반에서 사용되는 도구들을 한꺼번에 묶어서 ALM 솔루션이라는 명칭을 가져다 붙인 것입니다. 여기다가 또 마케팅적인 용어로 그냥 개별 도구들을 집합시켜 놓기만 한 것을 1세대 ALM 솔루션이라고 부르고, 각 도구들을 통합시키고 일관성을 부여한 것을 2세대 ALM 솔루션이라고 부르기도 합니다.
그런데, ALM은 완전히 새롭게 튀어 나온 것이 아닙니다. 그런데도 아직도 ALM을 하지 않는 회사가 있냐느니, 우리도 몇 년 뒤에 ALM 도입을 검토하겠다라는 황당한 단어들이 나옵니다. 심지어 모 회사는 CMMI 레벨 5를 달성했다고 자랑하면서도 ALM 도입을 검토하고 있다라는 얘기가 나옵니다. (이런 얘기들을 보면 CMMI 레벨이라는 게 정말 믿을 수 있는 건지 의문이 가지요.)
요점은 ALM과 ALM 도구를 혼동해서는 안 된다는 것입니다. 결국 위에서 얘기하는 ALM 도입이라는 것은 특정 회사의 ALM 솔루션을 구입하겠다는 얘기입니다(마치 ALM 솔루션을 구입하지 않으면 ALM을 안 하는 것처럼 되어 버리죠). ALM 솔루션 회사들 역시 통합, 일관성을 강조하면서 소프트웨어 개발 프로세스에서 사용하는 제품을 자사의 제품으로 다 통일해야 한다고 역설합니다.
이러할 경우, 자칫 ALM 솔루션을 도입하기만 하면 ALM이 자동적으로 다 되는 것처럼 오해하게 될 수도 있습니다(사실 일부 ALM 솔루션 회사들은 이렇게 선전하기도 합니다). 물론 ALM 솔루션과 같이 좋은 도구가 있을 경우 ALM이 더 효율적으로 이루어질 가능성이 높긴 합니다만, 반드시 필수불가결한 것은 아닙니다.
지금까지 얘기들을 좀 더 쉽게 예를 들어보기 위해 Microsoft Office나 한컴 오피스 등과 같은 사무용 소프트웨어들을 살펴보도록 합시다. 예전에는 문서를 워드프로세서, 스프레드시트, 프리젠테이션 소프트웨어를 단품으로 각각 구매해야 했습니다. 그런데 언제부터 이러한 것들을 묶어서 Office 소프트웨어라는 명칭으로 묶어서 패키지로 판매하기 시작했습니다. 구매자 입장에서는 단품으로 구매하는 것보다 묶어서 패키지로 사는 게 가격이 싸고, 판매자 입장에서는 다양한 제품을 판매하는 것이 아무래도 유리하니 이러한 방법을 선택하게 됩니다.
그리고, Office 소프트웨어는 시간이 지나면서 단순한 묶음이 아니라 서로 간의 연동이 필요해지게 됩니다(예: 문서 안에 스프레드시트를 집어 넣기와 같은 다른 유형의 문서 간의 Copy & Paste). 그래서 사무용 소프트웨어 회사들은 UI를 일관성 있게 통합시키고 각 소프트웨어들이 서로 연동해서 동작하게 만듭니다. 이러면서 명칭 역시 통합 사무용 소프트웨어 등으로 진화해갑니다. 이제 업체들은 워드나 스프레드 시트 단품에는 관심이 없고, 통합 제품을 판매하기 위해서 열을 올립니다. 그리고 통합 제품을 사용하지 않으면 안 되는 것처럼 선전하기 시작합니다(사실 개별 제품의 기능이 좋은 것보다는 다른 제품과의 연동과 통합성이 더 중요하게 되긴 하죠).
아이러니컬한 것은 그렇다고 해서 통합 사무용 소프트웨어, 심지어 개별 사무용 소프트웨어가 없던 시절에도 회사에서 문서를 작성하지 않았던 것은 아닐 겁니다. 워드프로세서 대신에 타자기를 사용했고, 스프레드시트 대신에 장표와 계산기(혹은 주판), 프리젠테이션 소프트웨어 대신에 괘도를 사용해서 진행을 했을 겁니다.
눈치를 채셨겠지만 개별 사무용 소프트웨어는 소프트웨어 개발 프로세스에서의 다양한 도구를 말하며, 통합 사무용 소프트웨어가 바로 ALM 솔루션을 가리킵니다. 그리고 중요한 것은 ALM 솔루션이나 개별 도구가 없던 시절에도 우리는 사실 ALM을 이미 해왔었다는 것입니다.
그래서 우선 이 연재에서는 ALM 얘기에서 특정한 도구는 배제시키고자 합니다. 물론 나중에 ALM을 실제적으로 적용하는데 있어서는 Microsoft의 Visual Studio Team System이라는 도구를 설명하긴 하겠지만, 어디까지나 그건 적용의 차원에서 드는 예에 불과한 것입니다. 따라서 VSTS에 대한 얘기를 기대하시는 분이 있다면, 그 얘기가 나올 때까지는 한참 기다리셔야 할 듯 합니다.
ALM 관련 내용이나 ALM 관련 솔루션들을 읽다 보면, ALM의 등장 배경에 대해서 장황한 설명을 하고 있습니다. 그러면서 ALM이 가져다 줄 수 있는 혜택에 대해서 늘어놓습니다.
저는 그냥 짧게 가겠습니다. ALM이라는 게 대체 왜 등장했느냐고 물어본다면…
“소프트웨어 X뺑이 덜 치면서 잘 만들기 위해서”