[지디넷코리아]최근 몇 해 사이에 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의 미래-1

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

티스토리를 본격적으로 시작한지 어언 21개월만에 구글애드센스 수익이 처음으로 $500을 돌파했습니다~
더보기
뭐 제 블로그를 보시면 아시겠지만, 좋게 말하면 엔터테이먼트이지만, 그냥 특별한 주제도 없고,
제가 본 책, 영화, 방송, 제가 가본 음식점, 구입한 물건의 리뷰, 궁금한것을 찾아본것 등 잡다한것들이
어언 10년에 이르면서 8천여개의 글이 되었고,
(개인홈페이지를 운영하다가, 2년전에 Tistory로 이사를 왔습니다)
다음뷰나 메타사이트에 의존없이 주로 네이버와 다음의 검색엔진으로 통해서 하루에 만오천명정도의 유입이 들어오고 있습니다.

뭐 다른 블로그에 댓글을 달아주고, 친구 맺기나 서로간 추천 같은 것도 없이
홀로 고전분투(?)를 하고 있는데, 갸륵한 성과가 아닐까 싶습니다....^^


뭐 블로그의 정체성이나 파워블로그가 되기 위한 글들을 보면 저와는 참 거리가 있는 내용들입니다.
어느 특화된 분야가 있는것도 아니고, 그저 보고, 듣고, 느끼는것을 블로그에 올리는것만으로도 이런 성과를 낼수 있다는것이 스스로 놀랍기도 하네요...^^

뭐 꼭 블로그가 남에게 보여지려는 목적이 아니여도 좋을것입니다.
예를 들어 인터넷에서 컴퓨터 모니터를 구입하면,
내 블로그에 오늘 구입을 했고, 어디서 구입을 했으며, 가격은 얼마며 몇일 사용을 해보니 소감이 어떻다 정도만 올려도, 남들도 조금은 구입시에 참고할수 있을것이며, 차후에 제품에 문제가 생겼을 경우 언제샀는지, 어디서 샀는지 블로그에 와서 검색 한번만 해보면 쉽게 찾아볼수 있어서 본인에게도 많은 도움이 될것입니다.

이런 구입관련 리뷰외에도 각종 정치, 사회, 문화에 대한 나의 의견이나 생각들을 올려놓고, 시간이 지나가면서 내 생각은 어떻게 바뀌어가고, 다듬어 보는 계기도 될수 있지 않을까 싶습니다.

여행이나 가족 사진과 같은 경우도 지인들의 이야기를 들어보면 하드에 보관하거나, DVD로 구워 놓는다고 하는 사람이 많던데, 나중에 찾아보는 경우는 거의 없더군요...
저같은 경우에는 사진을 몽땅 블로그에 올리고, 사진은 삭제를 해버리는데, 나중에 찾아보기도 좋고, 지난 추억을 돌이켜 보기에도 좋은듯 합니다.

티스토리 계정당 5개의 블로그를 만들수도 있으니,
전문 분야는 따로 주소를 만들어서 활용해 보면 어떨까 싶습니다.
(초대장이 7장 정도 있으니, 필요하신분은 비밀댓글로 이메일주소를 알려주세요)


뭐 블로그는 이래야 하고, 저래야 한다는 지침은 없지 않나 싶습니다.
그저 자신의 이야기, 자신의 주위의 이야기를 올리면서 블로그를 멋지게 활용해 보는것은 어떨까요?
 

중국에서 유래가 되었고, 주로 동아시아에서 쓰였다는 살 나이 방식
12월 31일에 태어나면 바로 한살이고, 1월 1일이 되면 바로 두살이 되는 살나이

외국에서도 사용을 할까? 불혹이라는 40은 만나이를 의미하는것일까?

이런것이 궁금해서 찾아보았는데, 중국에서 만들어졌지만, 중국에서는 문화대혁명후에 쓰이지않게 되었고, 일본은 법적으로 만나이를 공식화 하는 등... 전세계적으로 우리나라에서만 사용을 한다고 합니다.

불혹의 나이는 아무래도 살나이가 쓰이던 공자시대에 나온 용어이니,
우리가 사용하는 살 나이를 의미하는듯 하네요

참 애매하기도 하고, 가급적 우리나라도 만나이를 공식적으로 사용해야 하지 않을까 싶습니다.

재미있는것은 분명 아이들의 돌잔치를 할 때는 초를 하나만 사용을 하는데,
나이를 먹어가다 보면 만나이대신에 살나이를 사용하기 때문에, 어느순간 초가 하나 늘어납니다.

그 사라진 하나의 생일 초는 어디로 사라졌을까요....^^

회갑(환갑), 칠순, 팔순 잔치는 우리나이, 만나이중 어느것으로 할까?