Continuous Delivery and ITIL: Change Management by Hubert Shin

원문보기

대규모 조직은 대부분 무거운 변경 프로세스들을 가지고 있다. 이 변경 프로세스들은 일반적으로, 변경을 요청하고 실제 그 변경에 대한 디플로이가 일어날때까지 일주일 또는 그 이상의 리드타임이 걸린다. 이러한 현상은 지속적인 딜리버리를 하려는 조직에 매우 큰 병목이다. ITIL같은 프레임웍들은 종종 이러한 병목 문제들로 비난의 대상이 된다

하지만 ITIL의 원칙들과 기법들을 모두 따르면서도 가볍게 프로세스를 수행하여 빠르고 신뢰할만한 딜리버리를 수행하고 효과적인 서비스 관리의 목표를 성취할 수도 있다. 이번 씨리즈에서는 보다 가벼운 ITIL 프로세스의 수행을 어떻게 이룰 수 있는지를 이 이야기하려고 한다. 여러분의 피드백과 실제 경험들을 언제나 환영하겠다.

난 다음의 두 가지 이유 때문에 변경관리를 관찰하며, 이 씨리즈를 시작하려고 한다. 첫 번째로 정상 변경관리 프로세스는 숙련된 팀들이 지속적인 딜리버리를 하려는데 자주 발목을 잡는 요인이 된다. 왜냐하면 이것은 개발팀과 운영을 수행하는 세계 사이의 접점이 되기 때문이다. 두 번째로 변경 프로세스는 ITIL 라이프사이클에서 서비스가 전이되는 프로세스의 첫 번째 부분이다. 이 변경 프로세스를 진행할 때는 특정 순서에 따라 프로세스들을 수행하는 것이 좋다. 

ITIL의 변경 프로세스

ITIL 세계에서는 3가지의 변경종류가 있다. 표준(standard), 정상(normal) 그리고 긴급(emergency) 이다. 일단 긴급 변경은 잠시 고려하지 말자. 그리고 다른 두 타입의 변경이 어떻게 다른지 구별해보자. 정상 변경은 정해진 변경 관리 프로세스를 수행하며 관리되는데, 정해진 프로세스란 검토, 평가, 승인, 거부되거나 하는 RFC를 만드는 것에서 시작하여 이후 계획을 세우고 실제 변경을 수행하는 일련의 작업들이다.

표준 변경들은 위험성이 낮은 변경으로, 사전에 이미 승인된 변경 들이다. ITIL의 용어집에 따르면 표준변경은 "영향이 낮은 일반적인 어플리케이션 변경으로 마치 계절이 바뀌면 해야 하는 일(service Transition p48)"이라고 한다. 각 조직은 그 조직이 결정한 "표준"이라고 명명할 변경에 대한 가이드라인을 통하여 표준 변경들을 결정할 것이다. 그리고 변경들을 승인하는 프로세스를 수행할 것이다. 이 과정은 정상 변경과 동일하다. 표준 변경 또한 정상변경과 마찬가지로 기록되고 승인되어야 한다. 하지만 표준변경의 경우 승인을 하는 주체가 조직 내 승인 후 실제 변경 작업을 수행할 인력과 매우 가까운 경우가 대부분이다. 이런 경우 굳이 복잡한 관리 단계를 거칠필요는 없다.

하지만 심지어 정상 변경들도 변경관리 프로세스의 복잡도를 달리하여 보다 가볍게 다루어질 수 있다. 여러 조직 부서들이 동시에 영향을 받는 주요 서비스 변경의 경우 RFC 뿐만이 아니라 매우 상세한 변경 제안내역을 필수적으로 작성하고 이후 IT 관리 담당자들에게 승인을 받아야 한다. 만약 매우 비용이 높거나 위험성이 높은 경우는 비즈니스 임원 담당자들까지도 승인을 받을 필요가 있다. 하지만 위험이 낮은 경우 CAB(change advisory board)에게만 승인을 받으면 된다.

하지만 CAB의 승인마저도 시간이 걸리고 힘든 프로세스가 될 수 있다. 그러나 반드시 이렇게 힘들 필요가 있는 것은 아니다. ITIL v3 서비스 전이 책에서는 CAB 담당자는 경우에 따라 전자 승인을 수행할 수도 있다고 이야기 한다. 또한 CAB에 있는 모든 인력들이 모든 변경에 대해 하나하나 승인해야 할 필요는 없다고 덧붙인다.(pp58~59) 주어진 변경에 대해 승인할 필요가 있는 누군가에게 동의를 얻는 것, 그리고 그들이 승인해야 할지 말지에 대해 결정할 수 있게 사전 정보를 알 수 있도록 해주는 것 등을 적절히 수행한다면, JIT(just-in-time)방식으로도 전체적으로 만족스러운 승인 프로세스를 진행할 수 있다.

CAB과 딜리버리 팀사이의 협업은 승인 프로세스를 효과적으로 만들기 위해 매우 중요한 조건이다. 내 동료 Tom Sulston은 다음과 같은 제안을 했다. 만약 당신이 매 이터레이션 마지막에 실제 릴리즈를 하기를 원한다면, 이터레이션 플래닝 미팅(필요하다면 컨퍼런스 콜로)때에도 CAB의 구성원들을 초대하라. 그래서 그들이 파이프라인을 통해 무엇이 나올지 정확하게 기대할 수 있도록 하여 릴리즈를 수행하게 될 때 불편함 없이 승인을 할 수 있도록 하라.

ITIL은 가벼운 변경관리 프로세스가 가능하게 할 수 있는 몇 가지 매커니즘을 제공하는 것을 알 수 있다.
  • 사전 승인된 표준변경
  • CAB 승인 시 실제 만나 수행하는 것보다 전자승인 수행 
  • CAB 구성원들의 일부 인원들이 각 변경의 종류를 승인할 수 있도록 사전 조율수행 

우리는 얼마나 많은 변경에 대해 이 매커니즘을 사용할 수 있을까?

변경 위험을 줄이기 위한 지속적인 딜리버리 사용

ITIL은 각 변경이 위험과 비즈니스 가치 두 가지 모두로 평가되어야 하도록 하는 원리를 따르고 있다. 그래서 변경 관리 프로세스를 보다 가볍게 할 수 있는 가장 최선의 방법은 각 변경에 대항 위험을 줄이고 비즈니스 가치를 높이는 것이다. 지속적인 딜리버리는 딜리버리 프로세스의 이른 시점부터 규칙적으로 릴리즈를 수행하게 만드는 체계이므로, 사용자의 피드백을 기반으로 딜리버리팀이 주어진 시간안에 가장 가치있는 일에 집중할 수 있게 해준다. 

Figure 1: Traditional delivery

전통적인 방식으로 수행하는 라이프사이클에서뿐만이 아니라 심지어 애자일을 수행한다는 프로젝트에서도, 딜리버리 리듬이 그림 1 처럼 나타난다. 요구사항을 받아 실제 릴리즈까지 수행하는데 꽤나 많은 시간이 걸린다. 대규모 프로젝트의 경우 심지어 몇년이 걸리는 경우도 있고, 작은 프로젝트에서도 6개월 이상 걸리는 경우가 잦다. 한번 릴리즈 이후에는 그래도 비교적 규칙적인 리듬으로 릴리즈를 수행한다. 하지만 여전히 느리다. 주요 릴리즈에 대해서는 몇달에 한번, 작은 릴리즈에 대해서는 한 달에 한번정도만 수행된다.

특히 지속적인 디플로이를 할 수 있는 지속적인 딜리버리를 수행하는 환경에서는 이전 경우와 매우 다른 일들이 일어난다. 프로젝트 인셉션(프로젝트 초기 요구사항의 베이스라인을 수립하는 단계)때부터 새로운 프로젝트의 딜리버리 환경을 준비한다. 그리고 딜리버리 프로세스에서 최대한 빨리 릴리즈를 시작한다. 때로는 심지어 서비스가 실제 만들어져 사용자가 사용할 수 있는 상태 훨씬 전일 수도 있다. 한번 릴리즈 이후의 어떠한 변경들에 대해서도 가능한 한 자주 릴리즈를 수행 할 수 있는 환경을 만든다. 주요 릴리즈 뿐만 아니라 매우 작은 마이너 릴리즈 또는 심지어 아주 작은 마이크로 릴리즈까지도 항상 릴리즈가 가능하도록 해준다. 프로젝트 관리자들은 사이클타임을 최적화하는 것에 초점을 맞추면서, 변경에 의한 시스템의 변화가 실제 시스템에서 기장 빨리 잘 동작할 수 있도록 작업할 수 있다. 이 프로세스는 그림2와 같다

Figure 2: Continuous delivery

지속적인 딜리버리를 수행하기 위해서는 딜리버리 프로세스 뿐만이 아니라 조직 전체적인 구조에 여러가지 중요한 변화들이 필요하다. 먼저, 지속적인 딜리버리를 이루려면 프로젝트 초기부터 운영팀이 개발 팀과 매우 가깝게 일한도록 해야 한다. 마치 한 팀처럼 협업을 할 수 있는 팀들이 함께 디플로이 파이프라인의 부분들을 책임지며, 최초 만들어지는 어플리케이션을 디플로이하면서 필요한 설정들을 관리하기 위한 릴리즈 환경, 테스트 환경, 자동화된 프로세스등을 함께 준비한다.

생각해보라. 만약 운영팀이 개발 초기부터 어플리케이션이 실제로 어떻게 만들어 질지 알게 되면 어떠한 변화가 생겨날까? 아마 그들에게 필요한 모니터링 관련 요구사항들을 개발 프로세스에 담을 수 있을 것이다. 마찬가지로 만약 개발팀이 실제 릴리즈 될 제품이 어떤 모습이어야 할 지 알게되면 어떠한 변화가 일어날까? 아마도, 개발시기부터 릴리즈 시 필요한 실제 비기능 요구사항(cross-functional)을 고려한 어플리케이션 아키텍쳐를 구축하고, 실제 요구사항에 맞는지 조기에 성능 테스트를 할 수도 있을 것이다. 이러한 협업을 통해, 조기에 주기적인 릴리즈를 수행할 수 있게 만들면, 프로젝트 구성원 모두에게 프로젝트 라이프사이클 전반에 걸쳐 언제든 출시 가능한 제품을 만들게 하는 강한 압박이 될 것이다.

지속적인 딜리버리는 실제 사용자들이 시스템에 억세스하기 훨씬 전에, 첫 번째 릴리즈가 가능할 수 있는 손쉬운 변경 프로세스를 가능하게 해준다. 이 변경 프로세스가 가동된 이후에는 더 자주 릴리즈를 수행할 수 있게 되는데, 심지어 하루에 수차례가 될 수도 있다. 어쨌든 적어도 이터레이션 내 1회 이상은 가능하게 한다. 이것은 결과적으로 하나하나의 릴리즈의 리스크를 감소시키면서, 동시에 실패한 변경에 대한 회복을 빠르게 한다 즉, 변경의 delta(변수)를 감소시킨다. 게다가 지속적인 딜리버리는 각 릴리즈에 대해 출시와 거의 동일한 환경하에서 충분히 테스트 되는 것을 의무화하여, 이후에 수행할 릴리즈의 리스크까지도 감소시킨다.

내가 앞서 이야기 한 것처럼, 지속적인 딜리버리의 가치는 보다 효과적으로 비즈니스의 가치를 전달 하는데 있다. 하지만 누군가가 이렇게 질문을 할 수도 있을 것 같다. 딜리버리 프로세스 내에서 이렇게 빨리 릴리즈를 하는 것이 프로젝트에 무슨 가치를 주는가? 이는 실제 시스템의 비즈니스적 가치가 발생하기 훨씬 전인 너무나 빠른 시점인데도 말이다. 지속적인 딜리버리의 가치제안을 보면 지속적인 딜리버리에 대하여 개발과 운영 사이클을 통하면서도 시스템이 동작하게 만들면서, 다음의 3가지의 가치를 한번에 얻을 수 있는(필자는 threefold라고 표현함) 방식으로 설명한다. 첫번째로, 선별된 일부 대상일 수는 있겠지만, 조기에 사용자가 시스템을 볼 수 있게 해준다. 이것은 사용자가 어떤 시스템을 자신들이 쓰게 될 지에 대해 매우 뚜렷한 그림을 얻게 해준다. 또한 시스템을 더 가치 있게 만들기 위한 큰 변경을 사용자가 발견할 수 있게 만들어준다. 두 번째로, 점증적 릴리즈는 통합 단계에 오는 빅뱅 릴리즈보다 훨씬 적은 리스크가 존재한다. 마지막으로 프로젝트 관리자들에게 프로젝트 진척의 실질적인 지표를 관리하게 해준다.

변경관리와 디플로이 파이프라인

디플로이 파이프라인은 변경관리 프로세스를 여러 가지 방식으로 효율화 시킨다.

무엇보다, 변경할 내용들에 대해 분석 및 평가가 가능하도록 여러 가지 적용 가능한 매커니즘을 제공한다. 어플리케이션이든, 인프라든, DB스키마든, 빌드, 테스트, 디플로이 프로세스 자체이든 당신에 시스템에 제안된 변경은 소스 콘트롤을 통해 제어/관리 되어야 한다. 이후 디플로이 파이프라인은 자동화 테스트를 통해 이 변경 때문에 시스템에 다른 기능이 망가지지는 않는지 확인하고, 이 변경들 자체에 대해서도 자동화 테스트 및 메뉴얼 테스트를 통해 문제가 없는지 확인한다. 또한 적절한 제어권한을 부여하면서 버튼 하나로 출시 환경에 디플로이 할 수 있는 시스템을 제공한다.

훌륭한 파이프라인의 구현이란 지난 디플로이 이후로 무엇이 변경되었는지 정확하게 당신이 알 수 있도록 하는 리포트를 제공하는 것이다. 사람들이 디플로이에 대해 승인할 때는 변경 리포트와 디플로이 파이프라인안의 자동화/매뉴얼 테스트 수행 리포트 그리고, 지난 번경이후 얼마나 시간이 지났는지 등의 측정 지표들이 필요하다. 이들을 통해 변경에 대한 올바른 평가를 할 수 있게 해준다.

파이프라인은 딜리버리 프로세스를 제어하는 것이므로, 궁극적인 감독(audit)과 컴플라이언스 툴이 될 수 있다. 이러한 관점에서, 디플로이 파이프라인을 제어하는 릴리즈 관리 툴은 다음과 같은 정보들을 제공해야 한다.

  • 각 어플리케이션의 어떤 버젼이 현재 수행 환경 각각에 디플로이 되어 있는지
  • 파이프라인상 각 부분부분 마다 어플리케이션의 어떤 버젼이 현재 진행상황으로 되어 있고 그 결과가 무엇인지
  • 누가 매 빌드/테스트/디플로이 프로세스를 승인하는지. 그리고 이들 각각이 언제 실행되고, 어떤 로그를 남기고, 입/출력 값이 무엇인지 
  • 이전 디플로이로부터 현재 버젼 콘트롤 시스템상에 존재하는 향후 디플로이된 산출물들과의 추적성은 어떻게 되어 있는지
  • 리드타임과 사이클 타임과 같은 주요 프로세스 측정 지표는 어떤지 

만약 당신의 툴이 위와 같은 정보를 제공해 주지 않는다면, 내가 제품 관리자로 참여하고 있는 제품인 ThoughtWorks StudiosGo와 비슷한 툴을 얻는 것이 좋다.

이러한 정보들은 수행할지/말지의 의사결정 수행을 위해 측정된 지표를 모으는 것의 일환으로 반드시 필요한 내용으로, 변경이 실패할 때 수행하는 주요원인분석(root cause analysis), 그리고 지속적인 개선의 일환으로 수행하는 변경 컨트롤 프로세스의 효과를 결정하는데에도 도움이 된다. 

표준 변경에는 어떠한 도움이 되는가

난 표준 변경이 현재보다 훨씬 더 많이 쓰여야 한다고 생각한다. 특히나 모든 디플로이가 실제 출시 환경과 다른 곳으로 먼저 디플로이가 이루어지는 경우라면, 모든 변경들이 표준 변경으로 구분되어야 한다고 생각한다. 하지만, 내 주장은 현실적으로 잘못된 디플로이를 했을 때 이를 제대로 복구하는게 너무나 어려운 현실을 감안하면 그다지 상식적이지 않다. 이러한 현실 때문에, 운영 담당자들은 자연스레 디플로이에 대해 방어적이 되고, 디플로이 전에 그들이 제어할 수 있는 환경에서 문제가 발생하지 않을 것이라는 증거들을 확보하려고 노력한다.

이 문제를 이야기하려면 두 가지 방면의 접근이 필요하다. 첫째로, 운영환경에 맞는 빌드를 수행하기 모든 수준에 걸맞는 충분한 자동화 테스팅이 수행되어야 한다. 이 말은 단위테스트, 콤포넌트 테스트, 인수 테스트(기능 및 비기능 테스트)등이 제품 출시 환경과 비슷한 수준의 환경에서 테스트 되도록 하는 디플로이 파이프라인이 구축되어야 한다는 의미이다. 만약 이를 구축한 상황에서 디플로이 버튼을 눌렀을때 어떤 기능이 망가질 지 몰라 걱정된다면? 이것은 당신의 자동화 테스트와 디플로이 프로세스가 좀 더 보완되어야 한다는 의미이다.

두 번째로, 만약 무엇인가가 잘못되었을 때 디플로이를 복구하는 것이 쉬워야만 한다. 실제 제품 출시환경에 디플로이하는 경우가 아니라면, 굳이 다운타임이 0일 필요는 없다. 즉, 롤백이나 재구축이 가능할 수 있다. 내게는, 점점 더 많은 프로젝트를 접할수록 점점 더 확신이 드는 것이 있다. 그것은 모든 팀들이 Puppet, Chef, BladeLogic 또는 System Center 같은 가상화 및 데이터센터 관리 툴들을 조합하여 완전히 자동화된 방식으로 새로운 개발환경을 구축할 수 있도록 딜리버리 프로세스가 개선되어 햔다는 것이다. 만약 당신의 어플리케이션이 패키지화 될 수 있다면 데이터 센터 관리 툴을 통해 당신의 패키지를 언인스톨하여 롤백할 수 있어야 하고, 이전 버전으로 재설치 또한 가능해야 한다.

한번 자동화가 수행되면, 긍정적인 피드백 사이클을 시작하는 것이 가능하다. 위험이 낮아지면서 더 자주 디플로이를 수행할 수 있게 되고, 디플로이가 더 자주 수행되면서 딜리버리 싸이클의 문제점을 빨리 도출하여, 쉽게 고치고 결과적으로 디플로이의 위험을 더 줄일 수 있다. 

결론

지속적인 딜리버리와 디플로이 파이프라인은 변경관리를 위해 보다 가벼운 ITIL 매커니즘의 효과적인 사용을 가능하게 해준다. 하지만 우리는 딜리버리 팀과 변경을 승인하는 CAB구성원들사이에 신뢰를 구축하는 것에서 이 효과가 시작한는 것을 알아야 한다. 지속적인 딜리버리는 실제 서비스가 사용자에게 쓰이기 전부터 많은 연습과 테스트를 할 수 있도록 해준다. 하지만, 반드시 지속적 개선 프로세스의 일부로써 변경관리와 딜리버리 프로세스가 계속해서 모니터링되고, 프로세스의 효율성 여부가 측정되어야 한다. 이 프로세스는 빈번히 릴리즈가 되면서 보다 훌륭한 피드백을 받을 수 있는 프로세스가 된다.

마지막으로, 지속적인 딜리버리가 비용과도 연관되어 있다는 사실도 매우 중요한 논란거리이다. 지속적인 딜리버리를 수용한다는 것은 결국 비용이 많이 드는 환경을 딜리버리 프로세스 초기에 구축한다는 의미일 수 있다 (가상화와 클라우드 컴퓨팅이 이들 비용을 줄일수 있음에도 불구하고). 게대가 고객부터 개발자, 운영 담당자 모두가 초기부터 서비스 관리 라이프사이클에 관련되어야 한다. 이 시점으로 부터, 이들 모두가 전체 라이프사이클을 통해 개발과 운영 서비스를 담당해야 한다는 의미이다.(주1) 이를 위해서는 많은 커뮤니케이션과 피드백이 필요하고 이는 많은 부담을 피할 수 없게 한다. 때문에, 지속적인딜리버리는 임베디드 시스템에서 SaaS까지 대부분의 소프트웨 딜리버리 프로젝트에 적용할 수 있음에도 불구하고, 실질적으로 전략적인 IT 프로젝트에 보다 적절하다.

전략 프로젝트에서의 지속적인 딜리버리 사용을 위해, 내가 추천하고 싶은 내용은 다음과 같다.
  • 최대한 빠르게 당신의 시스템을 위한 디플로이 파이프라인을 만들어 낸다. 자동화된 빌드, 테스트, 디플로이, 인프라 관리 이들 모두를 지속적인 딜리버리 프로세스를 개선하는 것의 일환으로 계속해서 진화시킨다.
  • 라이프사이클안에 최대한 빠르게 당신의 서비스를 릴리즈 한다. 이 시점은 실 사용자에게 사용가능한 시기보다 훨씬 빨라야 한다. 이는 운영 담당자들을 프로젝트 시작부터 관여하게 한다는 의미이다.
  • 이후 개발해야 할 기능들을 아주 작은 단위로, 점증적이고, 위험이 낮은 변경들도 나누어 변경 프로세스를 많이 테스트 할 수 있게 해야 한다. 이러한 행위는 딜리버리에 관련된 모든이들 사이에(CAB 인원을 포함) 신뢰를 쌓고 각 변경에 대한 가치에 대해 빠른 피드백을 주도록 한다.
  • 사람들은 변경을 조기에 식별하고 프로젝트 계획상에 항상 모든 상태를 업데이트 해야 한다
  • 모든이가 위험을 알고 승인되기 전에도 각 변경의 가치에 대해 이해할 수 있어야 한다. 짧은 리드타임은 CAB 구성원들에게 파이프라인 상에서 빨리 승인해줘야 한다는 것을 잊지 않게 해준다.
  • 변경 승인을 위한 권한은 각 변경들의 위험과 함께 딜리버리 조직간에 동등하게 나뉘어져야 한다. 
  • 변경 승인을 위해 필요한 시기에 수행하는(just-in-time) 전자 시스템을 사용한다.
  • 표준 변경들은 적절할 때 사용한다.
  • 변경관리 프로세스를 계속 모니터링하고 개선하여 효율성을 증진시키고 효과적으로 만든다. 

내가 정말 추천하고 싶지 않는 것들은 CAB 승인을 그냥 넘어가거나 직접 만나는 CAB 미팅을 아예 없애는 것이다. 직접 만나는 CAB 미팅은 감독, 모니터링, 관리 프로세스를 포함한 중요한 목적으로 활용된다. 그리고 모든 변경은 CAB의 일부 구성원들(만약 그들만이 의사결정 할 수 없다면 더 많은 CAB구성원들에게 질문하기 위해 의사결정을 보류할 수 있는)에게 승인되어야 한다.


Tom Sulston 에게 피드백 및 제안에 감사한다.
________________________________________
주1) 서비스 딜리버리를 위해 가장 효과적인 매커니즘은 서비스 생성부터 사라지는 순간까지 전문가들의 협업이 극대화되는 팀(cross-functional product teams)이 이 서비스를 책임지는 것이다. 만약 이 비전이 현실화되지 않으면 아주 기본적인 변경도 조직간 협업해야 할 대상이 된다. 거버넌스 구조에서 아주 기본 수준까지도 말이다. 이것은 이 글에서 다루는 것 밖의 이야기이다.


핑백

덧글

  • 2014/12/12 13:47 # 삭제 답글

    모두 굿나잇. 필자가 글을 읽는 동안 지출하고 훌륭한 포럼을 발견 기쁘게 생각합니다
댓글 입력 영역