블로그 | IT 생애주기 관리, '이면의 진실'

IT 부문이 라이프사이클 관리, 즉 생애주기 관리를 잘 하는 경우란 생각보다 드물다. 그럴만한 이유가 있다. 먼저 라이프사이클 관리의 정의를 찾아보면 다음과 같다. 
 

‘개념화부터 수명 종료까지, 프로비저닝(Provisioning)부터 운영을 거쳐 퇴역까지 애플리케이션 또는 플랫폼의 라이프 사이클 관리에 대한 전략적 접근방식.’

이러한 정의대로라면 라이프사이클 관리 업무가 전혀 구체적이지 않다. 새로운 플랫폼이나 애플리케이션을 도입하는 데 도움이 되지 않는다. 앱 개발 및 변화 관리 방법론의 목적이 바로 그것인 데도 그렇다.

일상 운영에도 도움이 되지 않는다. 애플리케이션 또는 플랫폼 퇴역에도 마찬가지다. 어쩌면 IT는 개념화 단계에서 수명 종료 시까지 특정 애플리케이션이나 플랫폼의 라이프사이클을 관리하는데 시간과 에너지를 투입할 이유를 없을 수도 있다. 
 

버전 통용 관리 IT에 필요한 라이프사이클 관리
하지만 IT 부문에게 중요한 라이프사이클 관리 활동이 있다. IT에 필요한 라이프사이클 관리는 플랫폼과 상용 애플리케이션을 최신 상태, 즉 제공업체가 현재 판매하는 것보다 1~2버전 이상 뒤쳐지지 않은 상태로 유지하기 위한 일련의 신뢰할 수 있는 접근법이다. 흔히 ‘버전 통용 관리’(version currency management)라 부르기도 한다.

이 개념을 일반적인 라이프사이클 관리와 비교하기 위해, 애플리케이션 중 일부가 EGSL(EnGarde Secure Linux) 위에서 구동되는 상황을 살펴보자. 인가드(EnGarde)는 수명이 한참 전에 끝났다. 단순히 죽은 것이 아니라 완전히 죽었다.

인가드가 수명이 끝난 서버에서 구동한다고 해서 수명이 끝난 서버가 만료된 서버가 될 때 구매 선택권 없이 새로운 하드웨어에 설치해야 한다는 뜻은 아니다. 구동하는 플랫폼 중 하나에 대한 업데이트 또는 이에 의존하는 애플리케이션에 대한 업데이트를 통해 호환될 것이라는 뜻도 아니다.

인가드는 다른 쓸모 없고 지원되지 않는 기술과 마찬가지로 끝까지 지속적으로 구동할 것이다. 그리고 마침내 종말이 오면 IT가 대응해야 한다.

플랫폼 포트폴리오에서 인가드는 없애는 것은 라이프사이클 관리가 아니다. 왜냐하면 이전에도 관리할 라이프사이클이 없었기 때문이다. 인가드가 리눅스 배포판을 도입했을 때 비즈니스 및 제품 계획에 퇴역 날짜를 설저하지 않았다. IT가 이것을 선택했을 때도 마찬가지였다. IT가 인가드를 플랫폼 포트폴리오에 통합했을 때 처분은 유지 또는 연장이었다.

IT의 아키텍트의 관점에서 인가드의 단종은 이벤트였다. 이런 안타까운 이벤트로 인해 인가드의 ‘제공업체 및 제품 생존 가능성’ 점수는 IT 아키텍트가 마지막으로 확인했던 것에서 -2(가능한 최악의 점수)가 되었고 처분은 이 기능이 여전히 필요한 경우 교체하거나 더 이상 구동하는 애플리케이션 또는 플랫폼이 없는 경우 퇴역시키는 것이었다.

이를 애플리케이션 통합 플랫폼으로서 비즈토크 2016(BizTalk 2016)를 활용했던 기업과 비교해보자. 비즈토크 2016이 퇴역하기 훨씬 전에 마이크로소프트는 후속작인 비즈토크 2020이 2019년 중반에 출시될 것이며 비즈토크 2016의 수명 종료 날짜(월)는 2022년 11월이 될 것이라고 발표했다.

이런 발표에 따라 적절한 버전 통용 관리 활동이 마련되어 있는 IT 아키텍트는 비즈토크 2016의 처분을 업데이트로 변경하고 이에 따라 비즈토크 업데이트 프로젝트를 회사의 프로젝트 마스터 일정 및 예산에 추가하여 플랫폼 포트폴리오에서 지원이 종료된 기술을 지속적으로 사용하는 비용과 위험을 방지했을 것이다.

즉, 버전 통용 관리가 IT에 필요한 라이프사이클 관리이다. 여기에는 다음이 포함된다.

• 효과적인 버전 통용 관리가 없는 경우 ‘사용 중인 버전’이 ‘사용 중인 버전’이 되겠지만 구성요소의 사용 중인 버전을 추적하는 애플리케이션 및 기술 포트폴리오.
• 각 구성요소에 대해 제공업체가 발표한 버전 업데이트 및 지원 종료 일정.
• 구성요소를 최신 버전으로 업데이트하기 위해 알고리즘에서 파생된 프로젝트 일정 및 예산.
• 구성요소를 기능적으로 동등하지만 전반적으로 뛰어난 대안으로 대체하기 보다는 업데이트가 최적의 처분인지 확인하는 대안 검토.
• IT가 예산과 관련하여 한 번만 싸우기 위해 임원진 또는 이사회 수준에서 구성요소를 최신 상태로 유지, 검토, 승인하도록 하는 기술 아키텍처 원칙 및 정책.

시사점
버전 통용 관리의 개념이 특별히 복잡하지는 않다. 하지만 몇 가지 장애물에 대비해야 한다.

우선, 플랫폼을 업데이트할 때 어디에 파급효과가 미칠지 파악해야 한다. 업데이트가 이전 버전과 하위 호환되는 경우는 드물다. 또한 소프트웨어 품질 확보팀이 자동화된 회귀 테스트를 최신 상태로 유지하도록 확인해야 한다.

둘째, 애플리케이션을 최신 버전으로 업데이트하려면 의존하는 플랫폼 중 일부를 업데이트해야 하는 경우가 있다. 이를 위해 플랫폼 업데이트 발견사항으로 되돌아가야 한다.

셋째, 애플리케이션 계층 버전 통용 관리의 경우 스케일링으로 인해 단점이 부각된다.

수백 또는 포트폴리오에 따라 수천 개의 애플리케이션을 생산에 배치하고 기술 아키텍처 관리 시스템에서 제공업체 버전 업데이트 일정을 최신 상태로 유지하는 것이 어렵다. 이런 다양한 문제에 직면했을 때, 많은 IT 부서가 포기하고 구성요소의 버전이 쓸모 없어지면서 위기가 발생할 때까지 미루게 된다. 미루게 되면 결국 더 이상 미룰 수 없는 상황이 발생한다는 점에서 이것은 끔찍한 결정이다.

애플리케이션 계층 버전 통용 관리는 힘든 만큼 중요하다. 가장 좋은 것은(아마도 ‘최선은’이라는 표현이 좀 더 정확한 것이다) 분리하고 정복하며 포트폴리오의 모든 애플리케이션에 IT 제품 관리자가 할당되어 할당된 애플리케이션의 건전성, 관리, 지원을 담당하는 것이다. 여기에는 제공업체 버전 계획 데이터베이스를 최신 상태로 유지하는 것이 포함된다.

버전 통용 관리가 있다고 실무자들이 면죄부를 받지는 못할 것이다. 대부분은 나쁜 소식을 가져온 사람 취급을 받을 것이다. 다행인 것은 이렇게 하지 않았을 때 전하게 되는 나쁜 소식보다는 이 나쁜 소식을 전하는 것이 낫다는 점이다.

* Bob Lewis는 IT 및 비즈니스 효과성 분야를 전문으로 하는 IT 컨설턴트다. ciokr@idg.co.kr