Visualizations of Continuous Delivery by Hubert Shin


Risk Management Theatre: On Show At An Organization Near You by Hubert Shin

원문보기

현재 쓰고 있는 새로운 책에 들어갈 컨셉 중 “위험 관리 극장(risk management theatre)” 이라는 것이 있다. 이 명칭은 내가 보아온 콘트롤(제어) 중심의 상명하복식의 조직에서 죄가 없는 사람들의 삶을 고통스럽게 만들면서 어떻게 앞으로 죄 짓는 것을 피해갈 수 있는지 알려주는 관리방식을 표현하기 위해 쓴 말이다. (이 말은 보안 극장(security theatre)과 유사하게 만들어졌다.) 위험 관리 극장은, 누군가는 반드시 멍청하거나 나쁜 짓을 할 것이라는 가정하에 프로세스를 최적화 하는 경우인데(Bjarte Bogsnes가 관리에 대해 이야기 한 것에서 인용), 다시 말하면, 신뢰할 수 없는 누군가가 있을 수 있다는 의미이다. 즉, 그 몇몇을 위해 조직 구성원 모두에게 예방 차원의 콘트롤을 수행하는 전략이다.

안타깝게도 위험 관리 극장은 큰 조직들내에 어디에나 있다. 이 이론의 지배하에 X 이론 패러다임이 지속적으로자리잡고 있다. 상명하복 식의 콘트롤의 대안을 난 적응적 위험 관리(adaptive risk management)라 부르는데, 이것은 인간 중심관리 이론들(Ohno, Deming, Drucker, Denning, Dweck 등이 수행한 연구)과 복잡한시스템이 어떻게 동작하는지에 대한 연구 등에서 나온 것이다. 적응적 위험 관리는 고민하고, 투명화하고, 실험하고, 빠르게 피드백하는 반복을 통해 이루어진다.

여기에 두 가지 접근의 차이에 대한 몇 가지 예제가 있다.

적응적 위험 관리(사람들이 투명성과 피드백을 향상 시키면서 문제를 식별하고 즉흥성과 실험성을 통해 그 문제를 해결하는 방법)
위험 관리 극장 (죄가 없는 사람들에게 콘트롤(제어)과 프로세스를 통해 그들의 삶을 고통스럽게 만들면서 어떻게 하면 향후 죄 짓는 것을 피해갈 수 있는 지 가르쳐주는 방법)
지속적 코드 리뷰 : 엔지니어 사이에서 체크인 전에 자신의 코드를 확인해 달라고 부탁하는 기술 리더는 팀이 체크인한 모든 코드에 대해 검토하고 코드 리뷰 툴을 통해 Trunk 존재하는 코드에 대해 코멘트   있도록 하는 것이다.

필수적 코드 리뷰 : 툴을 통해 Trunk  코드가 병합되는 변경이 진행   누군가에 의해 승인을 받는 체크인 게이트가 존재하는 것이다 이것은 비효율적이고 성능을 포함한 중요한 회귀 테스트 피드백의 지연을 야기한다.
빠르고, 자동화된 유닛과 인수 테스트 : 몇분안에 완료되는 유닛테스트와 몇 십분 정도 소요되는 인수 테스트를 통해 Trunk로 커밋 되기 전에 자신의 워크스테이션에서 수정된 내용을 검증할 수 있도록 하는 것이다. 
메뉴얼 테스팅 : 특히 다른 팀이 수행하거나 분산 환경에서 수행되는 경우 필수적 코드리뷰와 마찬가지로 시스템 전체 변경 결과에 대해 피드백을 늦추게 되는 테스트 방식이다. 
디플로이 파이프라인 : 체크인된 내용부터 모든 릴리즈까지의 변경을 추적할  있는 시스템으로 위험한 변경을 찾아내고 거부할  있고 자동화된 테스트와 매뉴얼 검증을 동시에 수행   있다.
종합적 문서 꾸러미 : 복잡하지 않은 시스템에서 장애가 발생하는 경우장애의 주요 원인이  사람이  에러를 찾아낼  있도록 매커니즘 또는 카테시안 패러다임 안을 발견할  있는 것이다.
상황적 인지 : 보다 쉽게 모니터링 하기 위해 툴을 통해 상황을 이해하고 관련된 데이터를 분석하고 연관지을 수 있는 것으로 프로세스, 비즈니스, 시스템 레벨의 측정 지표 뿐만이 아니라 특정 이벤트에 대한 토의 내용까지도 모두 포함하는 인지 방법이다. 
의무들의 분리 : 지식 고유, 피드백, 협업을 방해하는 장벽으로 움직이게 되는 것으로 각 이벤트에 대한 효과적 대처를 필수로 할 수 있는 효과적인 반응에 대한 상황 인지를 감소시킨다.

하지만, 반대의 경우가 적절한 환경이 있다는 것을 강조하고 싶다. 만약 당신의 조직이 딜리버리와 운영 프로세스가 문제가 많고 숙련되지 않았다면, 콘트롤(제어)을 수행하는게 개선을 위해 보다 효과적일 수 있다. 하지만 이것은 끝까지 지속할 수 있는 대책이라기 보다는 잠시 동안쓸 수 있는 방법이고, 함께 일할 사람의 동의하에 진행하는 것이 좋다.

여기에 IT 분야에서 두 접근의 차이점이 존재한다.

적응적 위험 관리(사람들이 투명성과 피드백을 향상 시키면서 문제를 식별하고 즉흥성과 실험성을 통해 그 문제를 해결하는 방법)
위험 관리 극장 (죄가 없는 사람들에게 콘트롤(제어)과 프로세스를 통해 그들의 삶을 고통스럽게 만들면서 어떻게 하면 향후 죄 짓는 것을 피해갈 수 있는 지 가르쳐주는 방법)
원칙 기반 역학 : 원칙들이 만들어질 때 구상되지 않은 상황에 원칙들이 적용되는 것이다.  규칙 기반 정역학 : 새로운 기술과 프로세스들(예를들어 클라우드 컴퓨팅)을 만났을 때 규칙을 다시 적도록 하는 것이다. 
 투명성을 이용하여 사고나 나쁜 행위들을 예방 : 모두가 하는 일을 모두가 쉽게 알 수 있다면, 모두두가 조심을 하게 된다. Louis Brandeis가 말했듯이 "공공성은 사회 및 산업 질명들에 꼭 맞는 제제 수단이다. 햇살이 가장 좋은 전염병을 막는 도구이듯이, 전기불은 가장 효율적인 경찰이다"  콘트롤(제어)를 이용하여 사고나 나쁜 행위를 예방 : 이 접근법은 큰 문제에 대한 반응으로 법제정자들이 액션을 취하는 방법이다. 그러나 콘트롤은 예상못한 문제들에 재빠르게 대처해야 할 때 제한되는 경우가 많다. 이것은 새로운 위험들을 야기하고, 표준화된 변경 프로세스가 매우 느린 경우 긴급한 경우에도 프로세스에 의존하게 되는 경우를 만든다. 
시스템이 실패할 수 있다는 것을 수용 :  모든 시스템과 환경은 지속적으로 변화한다. 그리고 모두가 이성적으로 받아들일 의사결정을 내리는데에는 항상 정보가 부족하다. 사람들은 문제를 해결하고 우리는 판단하는 사람에 의존해야만 한다.  사람이 문제라는 것을 가정 : 만약 사람들이 프로세스를 올바르게 따른다면 나쁜일이 전혀 일어나지 않을 것이라는 생각이다. 콘트롤(제어)는 "나쁜 사과"를 찾아내기 위해 존재한다. 현실에서 프로세스는 해석과 적응이 필요하다는 것을 무시하는 경우이다. 
협업, 실험 시스템 레벨의 개선하는 사람들에게 보상 :  사람들은 시스템 레벨 지표를 개선하려고 협업한다. 예를들어 리드 타임이나 서비스 복구 시간 따위의 지표를 말이다. 개인의 "생산성"이나 기능 수준의 보상은 없다. 지엽적으로 이성적인 의사결정을 내리고  시스템 레벨의 장애들을 또한 받아들일 수 있다.  개인의 "생산성"에 기준한 보상과 지엽적 최적화 : 예를들어, 운영 담당자들이 쓰루풋에 대한 지출이나 품질에 대한 지출에 의한 속도를 위해 개별자들이 최적화 하는 것을 말한다. (심지어 이것이 잘못된 고전적 이분법인데도 말이다) 
지속적으로 배우고 실험하는 문화를 만듬 : 사람들은 배울 수 있는 실수에 대해 열러진 토의를 수행하고 시스템을 개선하기 위한 목적으로 화가 났던 문제나 고객 서비스 문제 이후 어떤 피드백을 받고 싶은지 포스트 모텀(post-mortems)을 수행한다. 사람들은 서로 나아지기 위한 새로운 시도와 실험을 서로 장려한다(많은 가정들이 실패할 수 도 있다는 기대 하에서도 말이다)  두려움과 불신의 문화를 만듬 : 에러 대한 책임 부족, 생략, 완료 실패에 대해 지적을 장려한다. 만약 누가 이야기 전에 난 아무것도 안 한다면, 문제간 생긴 경우 책임을 질 필요가 없다고 생각하게 된다. 
실패들은 배울 수 있는 기회 :  이것은 콘트롤된 환경이 필요하고 결과가 적절히 완화될 수 잇어야 한다. 이러한 상황에서 실패라는 개선하기 위한 기회를 장려한다.  실패는 사람의 에러에 의한 것임 :  (어떤 프로세스를 올바로 따르는 것에 대한 실패) 그리고 첫번째 반응은 책임질 사람을 찾고, 그들을 벌주기 위해서이고, 추가적인 프로세스나 제어 방식으로 미래의 문제를 해결한다.  

위험 관리 극장은 그저 고통스럽고 지속적인 딜리버리의 적용을 막기만 하는 것은 아니다 (물론 일반적인 지속적인 개선 또한 방해한다). 이것은 실제로 위험하다. 왜냐하면 첫째로 두려움과 불신의 문화를 만든다. Bogsnes는 이에 대해 다음과 같이 말한다. "만약 전체 관리 모델이 불신과 잘못된 행위에 대한 콘트롤(제어)이 중심이라면, 이 관리의 결과는 우리가 무언가를 예방하는 것 이상의 무엇인가가 될 것이다. 사람들이 점점 더 범죄자처럼 대해지면, 그들의 행동이 점점 더 범죄자 스러워 질 수도 있다." 

이러한 조직 문화는 우리가 직장을 잃을까봐 겁먹은 사람들을 볼 때나, 뭔가 잘못된 것으로부터 스스로를 보호하려 행동하는 사람들을 볼 때나, 또는 정보를 독식하여 스스로가 반드시 필요해지도록 만드는 사람들을 볼 때 주로 나타난다.

물론 콘트롤(제어)라는 IT 거버넌스 프레임웍의 큰 축을 안팍으로 모두 나쁘게만 보려는 의도는 아니다. 정말고 제대로 적용한다면, 그들은 효과적인 위험 관리에 필수적인 요소로 받아들여질 수도 있다. 예를들어 ITIL이 가벼운 변경 프로세스를 위하여 위험 관리에 적응적 접근을 수행할 수 있는 것처럼 말이다. 우리가 이것을 결정할 수 있는 것은 결국 이들 프레임웍이 어떻게 수행하느냐이다. 조직문화와 오랫동안 엮여 이러한 프레임웍과 같은 방법이 조직 문화의 영속성을 결정되고 사용된다.

Continuous Delivery: The Case of Apple by Hubert Shin

원문보기

지속적인 딜리버리와 린 스타트업 관련된 이야기가 애플에서 제기되었다. 예를들어 Richard Durnall 이 소개한 애플의 전략을 트위터에서 보면 다음과 같다.

소수의 훌륭한 사람들로 부터 만들어진 변경하기 어려운 제품이 커다란 세레모니와 함께 가끔 시장에 출시되는 것

이것은 지속적인 딜리버리와 린 스타트업등의 개념과는 정반대의 이야기처럼 보인다. 애플 내부의 제품 프로세스는 비밀에 붙여지고 있기 때문에, 도대체 무슨일이 일어나고 있는지 알 길이 없다. 게다가 뭐가 어떻게 돌아가서 어떤 정보가 정확하게 보여지는지 알 수 없다. 하지만 애플의 과거 역사를 보면 초창기에 지속적인 딜리버리와 린 스타업 컨셉에 맞는 방식으로 일을 했다는 것을 알 수 있다.

아래 그림 1의 Apple I을 보자. Steve Wozniak의 부모님 집 차고에서 만들어진 이 제품은 키보드, 모니터, 파워 케이플 없이 팔렸다. 이는 Eric Ries가 린스타트업에서 언급한 MVP(Minimum viable product)의 훌륭한 예이다.
Apple I on display at the Smithsonian, taken by Ed Utahan

그림 B는 "맥킨토시 정신" 으로 folklore.org 에서 온 것이다. 이 내용은 실제 구축에 참여한 담당자들이 맥 최초 모습을 만들어 낼 때에 대해 작성한 훌륭한 글이다.

이 글의 서두 부분은 "맥킨토시의 정신이 깃든 팀의 태도 및 가치"에 대해 표현하고 있는데, 이것은 간결하고 시간을 투자하여 전체를 읽을 만한 내용이다.(만약 시간이 더 있다면, 책으로 찾아 볼 수도 있다.) 바로 이것이 맥킨토시 팀의 제품 개발 프로세스에 대해 표현한 내용이다.

애플에 있는 대부분의 다른 그룹들은 형식적인 제품 개발 프로세스로 개발을 수행한다. 정해진 길이의 제품 요구사항 문서를 만들고 개발이 들어가기 전에 상세화된 엔지니어링 문서를 작성한다. 반면에 맥을 개발한 팀은 보다 창의적이고, 유연하고, 이터레이션을 수행하며 프로토타입을 훌륭하게 정제/개선해 나가는 방식을 택했다. Burrel Smith는 프로그램이 가능한 배열 논리 칩(PAL팁)을 기반한 하드웨어 설계를 수행했다. 이것은 전통적인 접근방식보다 훨씬 빠른 수정을 가능하도록 해주었다. 거의 소프트웨어의 유동성과 동일했다. 소프트웨어 아이디어에 대해 논쟁하기 보다, 우리는 빠른 프로토타입을 만들어 보는 것으로 가장 잘 동작하는 아이디어를 유지하고 불필요한 것들을 걷어내는 방식으로 작업했다 (Busy Being Born 확인). 우리는 현 상태에서 가장 훌륭한 아이디어를 표현할 수 있는 방식으로 작업할 수 있었다.

우리가 이야기 했던 20년전에 경험했던 이벤트들을 고려해 본다면, 임베디드시스템에 지속적인 딜리버리를 어떻게 수행하고 이를 통해 개선할 지 설명하는 것은 매우 어려운 일이다. 하지만 이 예제는 잘못된 판단을 가져올 수 있다. 커다란 세레모니와 함께 시장에 제품을 가끔 출시한다는 것이 지속적인 딜리버리를 할 수 없다는 것을 의미하지는 않는다. (이것이 왜 내가 지속적인 딜리버리와 지속적인 디플로이를 구별하려는지에 대한 이유이다. 또한 디플로이와 릴리즈의 용어 차이도 있다). 제대로 개발하면서, 세레모니를 혹시나 망칠 수도 있는 위험 높은 기술적 작업들이 일들이 제품 런칭 훨씬 전에 처리할 수 있다면 당연히 지속적인 딜리버리가 "규모큰 세레모니"를 수행하는데 도움이 되지 않을까? 때문에, 맥킨토시의 경우 역사상 가장 멋진 광고 사례 중 한 가지가 된 것이다.
’1984′ commercial for the launch of the Macintosh

주1) 보다 최근의 사례를 보고 싶다면, HP의 레이저젯 펌외어 팀이 지속적인 딜리버리 모델로 변화한 사례를 보면 된다. 이들은 Trunk에 지속적인 통합으로 체크인 한 것을 수행하면서 자동화된 기능성 테스트 또한 알고리즘과 타이밍을 고려한 실제 로직 보드를 이용하여 수행 하였다.

Voke report: Agile delivers higher customer satisfaction and quality by Hubert Shin

원문보기

Voke사가 출판한 "애자일의 현실"이라는 보고서에 대해 현재까지 많은 논란이 있다. 이 때문인지 SDTimes는 내게 그 보고서 안의 글들에 대해 논평을 해주길 원했고, 이것을 동기로 난 보고서의 전체 내용을 읽게 되었다. 한 가지를 덧붙이면 이 보고서 가격자체가 너무 비싸, 한 번 구입하면 모조리 읽을 수 밖에 만든 것도 또 다른 동기가 되었다. 결국, 난 내용을 잘 파악 할 수 있었고 리뷰 또한 올바로 쓸 수 있게 되었다고 생각한다. 그럼 이제부터 내가 읽은 견해를 표현해 보겠다. 위 내용에 대한 전체적인 총평을 한다면, 애자일에 대한 결론을 너무 쉽게 내려버린듯한 느낌이고, 심지어 가장 중요한 결론들조차 제대로된 자료 수집 과정을 거치지 않았다.

이번에 릴리즈 된 내용을 보면, 우리는 Voke 사가 연구 활동을 통해 다음과 같은 결론들을 내렸다는 것을 알 수 있다: 

  • "소규모 팀들이 훨씬 짧은 기간동안 프로젝트를 수행하는데 불구하고, 소프트웨어 프로젝트들의 평균비용이 크게 오르고 있다" - 이것은 애자일 적용 때문에 비용이 올랐다는 것을 함축한다.
  • "조사에 참여한 참가자들의 말에 따르면, 애자일은 이익을 주기 보다, 굳이 현실의 더 많은 문제들을 알게 하여 프로젝트내에 혼란을 준다라고 증언한다."
  • "그들이 경험한 재앙과도 같은 소프트웨어의 실패들을 고려한다면, 우리는 현재상태에서 품질을 올리기 위해 무엇인가를 해야 한다." - 애자일은 낮은 품질의 제품을 만들기 때문에 무엇인가를 해야 한다는 것을 의미한다.
  • 임원들이 애자일을 추진하려는 목표는 애자일이 비즈니스 어질리티이나 때문이나, Voke사의 보고서 내용은 마치 ,애자일이 애자일 커뮤니티가 진행한 유인 상술일 뿐이라고 생각하는 것으로 보인다. 
실제 보고서 내용에 보면, Voke사는 크게 다음의 3가지의 주장을 하고 있다. 첫째, 애자일은 소프트웨어 개발 프로세스 상에서 개발자들이 효과적으로 프로세스를 제어할 수 있도록 만드는 트로이의 목마와 같다. 즉, 개발자들이 생각하는 지겨운 일들 즉, 문서화, 설계 그리고 계획 등 을 효과적으로 피할 수 있게 해준다. 둘째로, 나 같은 컨설턴트들이 효과적으로 서비스, 트레이닝 그리고 책 따위를 팔도록 도와준다. 마지막으로, 가장 핵심적인 애자일의 가치는 빠른 프로토타입을 수행하는 것 이상으로 도움이 되지도 않는다. 때문에 이것은 전혀 새로울 것이 없다. 이들을 종합하여 이야기 하면, Voke 사는 그다지 열심히 애자일에 대해 열심히 공부해본 것 같지는 않다.(위 견해들에 대해 다른 말로 표현하고는 있지만, 난 원본 그대로의 뉘앙스를 그대로 이야기하려고 노력하고 있다.)
Voke 사는 그 많은 회사들이 애자일에 의해 혼란스러워 한다고 말하고 있다. 하지만, 이런 류의 보고서를 작성하는 것 같이, 정작 스스로의 비즈니스 조차도 제대로 하고 있지 못한 듯 하다. Voke는 애자일, 린, DevOps 에 대한 토의를 시작할 때 아주 기본적인 실수들(또는 잘못된 이해)을 저질렀다. 그리고, 그들이 저지른 가장 큰 실수는 바로, 애자일 수행 시 품질의 역할에 대한 것이다. 그들은 QA 즉, 품질을 높이는 역할에 대해 아예 언급하지 않았다.

이를 뒷받침하는 근거로, 그들은 애자일선언이나 DevOps 내용 어디에도 품질이 가장 중요하다는 논의가 없다는 것을 이야기 한다. 이 주장은 린, 애자일 관련 모든 훌륭한 토의들의 중심에 품질을 높여야 한다는 사실이 엄연히 존재 한다는 것을 무시하고 있다. 실제 애자일에서는, 애자일 방법론을 수행하는 것 자체 뿐만이 아니라, 더불어 분석자, QA 그리고 운영담당자들이 함께 지속적인 협업을 한다는 것 또한 강조한다. 그리고 애자일을 시작하는 사람들에게도 TDD나 지속적인통합 그리고 리팩토링 같이 결함을 조기에 발견하고 수정하여 비용을 잠재적으로 줄이는 방법(논문에서 알 수 있듯이)을 사용하도록 독려한다.

또 한 가지에 대해 짚고 넘어가보자: 2008년 이후 "애자일의 현실"이라는 보고서가 나오기 전까지 과연 소프트웨어 개발 비용이 계속 증가해왔는가? 사실은 프로젝트 기간이 짧아지면서, 평균적으로(주2) 프로젝트 비용은 거의 비슷하게 사용된 것을 알수 있다. 이것은, Voke사가 많은 기업들과 마찬가지로 IT가 많은 비용이 들게 하는 주요 원인으로 보는 실수를 저지르고 있다는 것을 의미한다. 즉, 투자에 대한 이익보다, 개발 비용 자체에 대해 초점을 맞추고 있는 것이다. "무엇이든 측정할 수 있다"의 저자인 Douglas Hubbard는 다음과 같이 언급한다. "프로젝트 안에 매우 불확실한 개발 비용들이 산정되어있음에도 불구하고, 이 비용의 규모로 투자를 할 지 안 할지를 결정하는 가장 중요한 요소는 프로젝트를 취소하게 되는 의사결정이다. 그 다음으로 프로젝트 투자에 가장 중요한 요소는 시스템의 활용도이며, 이는 얼마나 빨리 설치하고 사용자들이 활용할 수 있을지를 포함한다. " 그의 의견을 고려한다면, 같은 가격으로 고객의 피드백을 받으면서 훌륭한 품질의 제품을, 보다 짧은 시간에 만들 수 있다는 것은 굉장한 일이다. Voke사가 밝힌 자료에서 보더라도, 애자일 방법론을 사용한 프로젝트에서는 개발 후 버려지는 프로젝트가 없다고 한다.

Voke 사가 32페이지의 보고서 끝에 숨겨놓은 진실은 기술 중심의 회사든 아니든 간에 애자일 방법론을 쓸 때 결과적으로 더 높은 수준의 고객 만족을 가져왔고 해결되지 않은 결함(애자일 품질 문제와 밀접하게 연관될)또한 적었다는 것이다. 하지만, 대부분 기업들은 기술중심의 회사들보다 더 낮은 퍼포먼스를 보이고 있다. 때문에, 기술 회사들의 많은 수가 애자일 방법론을 사용할 때 다른 기업(주3)과 비교할 때 더 많은 고객 만족을 얻고 있다.

불행히도, 이 글의 작가들은 보다 넓은 폭의 거시경제 이슈를 언급하지 않았다. 1958년과 현재를 비교하면 S&P 500 회사의 생애는 평균 61년에서 18년으로 현저히 줄었다. 그리고 이 기간동안 동시에 발생한 이벤트를 이야기 하면, 바로 제조업이 지고, 소프트웨어 업이 성장한 것이다. 또한 린과 애자일 방법론을 중심으로 스타트업을 수행한 기술 중심의 신생회사들은 새로운 경쟁력으로 기본 회사들에 위협으로 자라났다. (대부분의 벤처 투자자들은 애자일 스타트업 방식이 아닌 경우 투자하지 않는다.) 사실 이 때문에 많은 기업들이 애자일 방식을 점점 더 많이 쓰려고 하고, 많이 쓰다 보니, 작가들이 말한 것처럼 심각한 문제들을 일으키는 것이다. 하지만 내 논지는 10년점의 애자일은 문서나 설계를 믿지 않는다는 FUD(Fear, Uncertainty and Doubt)를 반복하자는 것은 아니다.

이 문서의 데이터는 (위와 같은 이유로) 흥미를 위해 만들어진 것 같다. 난 보다 통계학적인 분석, 연관관계 그리고 그래프 같은 것들을 보고 싶은데도 불구하고 말이다. 안타깝게도 이 분석 내용은 작가가 원하는 결론을 내기 위해 약간 조작하는 것 외의 그다지 가치가 없어보인다.
--------------------------------------------
주1) 애자일 선언에 "품질"이라는 단어는 없지만, 9번째 원칙에서 "훌륭한 기술력을 위해 지속적으로 노력하고 어질리티를 높이기 위해 훌륭한 디자인을 해야 한다" 라는 말이 있다. Voke 사가 주장한 말중에 애자일 선언은 애자일을 수행하는데 부적절한 가이드라는 말이 있다. 이것은 사실이다 왜냐하면 애자일 선언의 의도는 애자일을 수행하는 방법을 정의하거나 가이드 하는 것이 아니기 때문이다. 이 의도는 2001년에 관심을 같게된 여러가지 "가벼운"접근의 방법론들의 핵심 메시지들을 도출해 낸 것이다. (마틴 파울러와 짐 하인스미스는 선언에 대한 배경을 이야기 할때, 품질에 대해서도 함께 이야기했다. 여기이 방법론들이 바로 Voke사의 작가들이 빠트린 수준의 상세 내용들이다. 마틴 파울러는 그의 블로그에서 다음과 같이 이야기 한다. "애자일은 가치와 원칙들로 이루어진 마음가짐이다. 애자일은 대부분의 사람들이 이해하듯이 기법들과 산출물들로 이루어진 방법론이 아니다" - 그의 블로그에서 더 확인할 수 있다.

주2) Voke는 그들이 제공한 데이터에 대해 평균이나 표준편차 또는 연관관계 같은 것을 전혀 제공하지 않고 있다. 게다가 어떤 그래프도 없다.

주3) 대신에, 내가 실제 숫자가 있는 보고서를 제공하겠다. 제대로된 보고서를 작성하려면 이정도 투자는 해줘야 한다.


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)이 이 서비스를 책임지는 것이다. 만약 이 비전이 현실화되지 않으면 아주 기본적인 변경도 조직간 협업해야 할 대상이 된다. 거버넌스 구조에서 아주 기본 수준까지도 말이다. 이것은 이 글에서 다루는 것 밖의 이야기이다.


1 2