Traditional development team vs Continuous Delivery team by Hubert Shin

XebiaLabs 에서 출간한 The IT Manager's Guide to Continuous Delivery 를 보고 의미가 있을 것 같아 번역을 하게 되었습니다. 

전통적인 방식의 딜리버리 팀과 Continuous Delivery 팀의 차이가 어떤 것일까요?
아래 글을 읽고 한번 확인해 보시죠 


전통적인 방식의 딜리버리  
  • 요구정의: 우리는 모든 것을 알고 있어요(We know everything)
    • 기간: 몇 주에서 몇 달
    • 낭비: 상세화된 불필요한 기능들. 잘못 상세화된 기능들. 불필요하게 많이 상세화된 기능들. 고객 피드백 부재. 대규모 사전 설계. 개발자에게 실행가능성에 대한 피드백을 전달 받지 못함
    • 설명
      • 대규모의 일을 하거나, 자주 릴리즈를 못하는 상황에서 BA는 기능을 먼저 모두 정의하려고 한다. 모호함과 해석의 차이를 사전에 제거하기 위해, 상세한 문서화를 통해 그들이 상상할 수 있는 모든 유스케이스와 시나리오를 찾아내려고 한다. 이러한 방식은 고객이 실제로 무엇을 원하는지 뿐만이 아니라, 그 이상의 것을 상상하여 만들게 한다. 이렇게 요구정의를 하면 고객들의 기대에 맞지 않는 다른 기능까지 정의하게 된다. 
      • 이것은 비즈니스 가치를 전달하는 측면서 볼 때, 이미 만들어지기 전부터 시장에 늦은 타이밍에 전달하게 되는 것이다. 한 개의 기능 개발을 실제로 하기 전에 너무 많은 충분한 기능 리스트를 모아야 하기 때문이다.
  • 코딩: 지연된 문제들(Postponing problems)
    • 기간: 몇 주
    • 낭비: 중복된 노력, 개발자 간 커뮤니케이션 부재
    • 설명: 기능 요구사항의 상세화가 모두 끝나면, 한 개 또는 더 많은 개발팀에게 기능 요구사항들이 한 개씩 전달된다. 개발자들은 홀로 일하게 되고, 그들의 동료들과 중복된 일을 할 수도 있게 되는 상황에서 어플리케이션 코드의 변경을 수행한다. 몇 주 뒤, 특정한 기능에 관련한 일은 마무리 된다.
  • 통합: 머지 지옥(Merge hell) 
    • 기간: 며칠
    • 낭비: 머지 시 발생한 모든 팀들이 함께 해결해야할 문제들 
    • 설명
      • 홀로 작업한 코드들을에 대한 작업이 끝난 몇 주 후 이 새로운 코드들은 한 개의 코드 베이스로 통합되어야 한다. 머지 전, 더 길게 이 코드의 작업이 걸릴 수록, 더 많은 개발팀들이 관여할 수록, 더 많은 문제가 발생한다. 
      • 늦은, 자주하지 않는 통합은 납기를 준수하지 못하게 되는 중요한 리스크이다.
  • 설치: 에러가 나기 쉬운 수작업 디플로이(Error-prone manual deployment)
    • 기간: 1주
    • 낭비: 디플로이 수행을 위해 기다리는 시간, 잘못된 디플로이 설명을 수정하는 시간, 잘못된 디플로이를 수정하는 시간, 디플로이 해야 할 환경을 준비하는 시간, QA가 테스트 가능한 시점을 기다리는 시간, 여러 팀간의 핑퐁 게임 
    • 설명
      • 개발 환경에서 몇 주간 수작업으로 만들어져 어플리케이션이 동작하게 된 후, 개발 팀은 운영 환경에 디플로이 하게하기 위한 설치 매뉴얼을 준비하고, 테스트 환경 또한 준비한다. 이 설치 메뉴얼은 개발자들이 기억하는 모든 단계 단계들을 작성해 놓으나, 보통은 완전히 테스트된 시나리오에 대해 표현하지는 않는다.
      • 설치 메뉴얼과 어플리케이션 바이너리는 공유된 네트워크 드라이브를 통해 운영에 전달된다. 운영팀의 담당자가 시간이 날 떄 테스트 환경에서 테스트 될 수 있도록 운영을 위한 시스템 상의 티켓(이슈)을 만든다. 이 운영팀에 전달된 티켓은 만약 5일 내에 운영팀이 접수해야 한다면, 그 5일에 매우 근접한 시점에 운영팀으로부터 접수된다. 그리고 한 운영 담당자는 메뉴얼에 따라 디플로이를 실시한다. 몇개의 스텝을 진행한 후, 운영자는 에러를 발견하게 된다. 이 에러는 티켓에 작성한 코멘트와 함께 개발팀에 전달된다.
      • 다음 날 아침 QA팀은 테스트를 하려고 준비하고 있으나 어플리케이션은 심지어 동작하지 않는다. 선임 개발자는 코멘트가 작성된 티켓을 보고 작성된 설치 메뉴얼에 에러를 발견한다. 이를 수정하고 다시 네트워크 드라이브에 공유한다. 그리고 다시 그 티켓을 운영팀에 넘긴다.
      • 결과적으로 운영자는 그 일은 다시 수행하고 마침내 테스트 환경에 설치를 마친다. 
  • 테스팅: QA 수작업 테스트에 의한 품질 기준 낮추기(Lowering the bar after manual QA 
    • 기간: 3주
    • 낭비: 요구사항을 테스트로 만들지 못한 것, 수정 전 모든 테스트가 끝나길 기다린 것, 개발한 기능이 동작하지 않는 것, 당장 필요하지 않은 시나리오 까지 정의된 것, 멀쩡한 기능까지 3개의 결함 때문에 릴리즈 되지 못하고 대기 상태가 된 것, 요구사항 해석에 따라 달리 오해가 발생하는 것, 여러 팀들간의 전달 시간 
    • 설명
      • QA팀은 이제 인수 테스트를 시작할 수 있다. 개발 단계 동안 팀은 상세한 요구사항에 대해 이미 확장한 테스트 계획을 세워놓았다. 이 중 어떤 요구사항들은 테스트 자동화를 하면 좋은 것들이다. 하지만 상세화된 요구사항을 테스트 자동화 스크립트로 바꾸는 것은 쉬운 일이 아니다. 많은 요구사항이 잘못 쓰여졌거나 자동화 스크립트에 걸맞지 않는 경우가 많다.
      • 다양한 프로세스로 테스트 계획을 수핸한다. 이 모든 과정이 완료 되고, QA팀은 보고 할 때 15개의 실패한 테스트 시나리오를 발견한다. 이것은 릴리즈를 하지 못하는 수준이다. 15개의 실패한 테스트는 다수의 중요 기능들과 연관되어 있다. 이들을 지연시키게 되면 이는 시장에 제품을 내어 놓을 수 없을 수준이다. 
      • 이들은 결함 중 3개만 빨리 패치를 수행하도록 한다. 개발팀에 이 3개에 대한 패치에 대해 QA테스트를 완료하고 이들은 마지못해 Pass 사인을 준다.
      • 릴리즈 매니저는 이 패치된 버젼에 대한 티켓을 만들어 프로덕션 버젼을 만든다. 12개의 시나리오는 실패한 상태로 말이다. 이들은 유지보수 단계에 매우 빠르게 수정하기로 암묵적으로 합의한다.
  • 릴리즈 준비: 사전 프로덕션의 병목 (The Pre-production bottleneck) 
    • 기간: 4주
    • 낭비: 사전 프로덕션 환경이 준비되길 기다리는 대기, 납기 준수 실패, 프로세스 마지막에나 발견된 에러 
    • 설명
      • 새로운 버젼이 릴리즈되기 전 사전 프로덕션 환경에서 최종 테스트를 거쳐야만 한다. 이것은 실제 운영이 잘 돌아가는 상황을 만들기 위해 반드시 수행해야 하는 단계이다. 가장 큰 문제는 실제 운영과 이전 환경들이 매우 상이하다는 것이다. 
      • 이 바쁜 사전 프로덕션 환경을 위한 배타적인 슬롯을 얻는 것은 사전에 잘 계획되어야 한다. 왜냐하면 다음 슬롯은 2주 후에나 있기 때문이다. 
      • 한번 어플리케이션이 설치되면, QA는 제품 통합, 안정성, 회귀 테스트를 실시한다. 일주일 후, 이 팀은 두 개의 에러를 발견하고, 개발팀으로 부터 이틀 후 이 내용이 수정된 내용을 다시 전달 받는다. 실패한 테스트를 다시 수행 후  프로덕션을 위한 릴리즈를 승인한다. 
  • 운영(Go-Live): 분기마다 릴리즈되는 사이클(The Quarterly Release Cycle)
    • 기간: 3주
    • 낭비: 정기 릴리즈까지 대기하는 시간, 야근, 주말근무 
    • 설명
      • 새로운 어플리케이션 버젼은 정기 분기 릴리즈 기간에 맞출 수 있게 겨우 승인된다. 3주 후 릴리즈를 수행할 수 있다. 평소와 비슷하게 이것은 매우 바쁘고 스트레스를 주는 일이다. 토요일에서 일요일 사이에 릴리즈가 일어나고, 운영팀은 수작업을 통해 9개의 새로운 어플리케이션 버젼을 릴리즈 해야 한다. 다양한 메뉴얼에 작성되어 있는 다양한 스텝들을 4시간동안 모이 수행해본 뒤, QA 분서는 4.5 시간을 들여 이 릴리즈를 검토하고 승인한다. 
      • Go/No-Go 납기 직전에 QA는 테스트를 완료하고 드디어 어플리케이션은 동작하게 된다.


Continuous Delivery 를 하는 조직의 일하는 방식 
  • 협업: 기능의 처음부터 끝까지 함께 하는 팀 (End to End Feature Teams) 
    • 설명
      • 새로운 아이디어가 만들어지고 딜리버리 스트림에 포함되는 것을 준비하는 것은 모든 관련된 그룹이 포함된 팀에 의해 가능한한 빨리 일어난다. 분석자, 개발자, 테스터와 운영팀이 함께 결정한다. 이 접근은 아이디어에 대해 공유된 시간을 갖도록 하여 효과적으로 아이디어를 구현할 수 있도록 한다. 이러한 애자일 팀은 서비스 딜리버리의 모든 스펙트럼의 일들을 수행하고, 성공적인 작업을 수행 할 수 있게 한다.
  • 정의: 명세를 자동화 인수 테스팅으로 (Specifications Become Automated Accepting Tests) 
    • 기간: 0.5일
    • 설명
      • 아무리 애자일 팀이라도 변경에 대해서는 구현되기 전에 명세화가 되어야 한다. 물론 이것은 앞서 말한 팀의 명세와는 차이가 있다. 스펙들은 전체 딜리버리 팀에 의해 형태가 정해지고, 분석자나 QA가 비즈니스 적으로 확인할 수 있는 말들로 작성된 수행이 가능한 테스트를 쓴다. 
      • 이것은 효율을 증가시키고 오해의 가능성을 한방에 없앨 수 있다. 왜 종이 문서에 스펙을 쓰고 이후 코드에 이것을 옮겨야 하는가? 그것도 다른 누군가가 말이다. 한번에 실행가능한 테스트를 만들면 되는 것이 아닌가?
  • 코딩: 테스트 먼저, 코딩을 이후에 (Test first, Then code)
    • 기간: 0.5일 
    • 설명
      • 기능을 구현하기 전, 개발자는 코드를 짜기 전이기 때문에 실패하는 Unit 테스트를 작성해 놓는다. 이후 이 테스트를 성공시키는 코드를 짠다. 이러한 프랙티스틑 의도에 맞는 코드를 만들고, 이 프랙티스가 팀에 녹아들면 모든 코드가 의도한 대로 만들어 진다.
      • 새로운 코드가 만들어 져 버젼 컨트롤 레파지터리에 들어오기전 모든 테스트는 성공해야 한다. 이렇게 함으로 개발자들이 일하는 모든 코드의 베이스는 동일해진다. 업데이트 된 코드 또한 지속적인 통합을 통해 다시 제대로 돌아간다는 것을 확인하게 된다. 이는 다른 개발자들의 어떤 작업과도 문제가 발생하지 않는 다는 것을 확인시켜준다. 
      • 만약 빌드가 실패하면, 모든 팀이 이를 확인하게 되고, 빌드가 다시 성공할 때까지 모든 문제보다 우선적으로 이를 먼저 해결한다. 
  • Off It Goes: Continuous Delivery Pipeline 
    • 기간: 0.5일
    • 설명
      • 통합 빌드는 CD Pipeline의 첫번째 관문이다. 이것은 우리가 스펙으로 작성한 자동화 인수 테스트를 통과한 것 뿐만이 아니라, 보안, 성능, 가용성 부분의 테스트도 모두 통과한 것이다.
      • 이러한 테스트들은 자동화된 것으로 수행되어 “Hands Off” 환경으로 전달된다. 여기에는 사람의 손이 닿을 수 없다. 만들어진 기능은 테스트들이 잘 수행완료됨과 동시에 이들 환경으로 디플로이 된다.
      • 스피드와 자동 프로비저닝의 신뢰성 그리고 운영 환경과 같이 설정된 테스트 환경은 파이프라인에서 매우 중요한 요소이다. 
      • 이것은 다양한 형태의 테스트를 동시에 이루어지도록 할 수 있고, 높은 품질의 파이프라인은 팀 스스로 품질에 대한 자신감을 높일 수 있게 만든다.
  • Go-Live: 제품 책임자가 버튼을 누른다 (The Product Owner hits the button)
    • 기간: 1시간 
    • 설명
      • 만약 새로운 기능이 파이프라인을 지나가는 동안 어떠한 문제도 일으키지 않으면, 비즈니스 책임자는 새로운 버젼의 어플리케이션에 대한 승인을 요청할 수 있다. 
      • 이것은 이미 수천개의 지난 밤 내내 진행된 수천개의 인수 테스트를 통과한 뒤이다. 모든 테스트 결과는 요약 정리되어 품질 대쉬보드에 보이고, 만약 원한다면 상세내역 또한 확인할 수 있다.
      • 새로운 기능의 승인 후, 비즈니스 책임자는 완전히 자동화 된 프로덕션 디플로이 환경에 이 기능을 추가한다. 이 디플로이는 정해진 시간에 늘 돌아가는 환경으로 개발자나 운영자가 필요하지 않은 작업이다. 새로운 기능을 추가하는 것은 Contents management system에 새로운 컨텐츠를 추가하는 것만큼 쉽다. 
      • 비즈니스 담당자들은 파이브라인 내에서 진행되는 어떠한 테스트의 내용도 신뢰한다. 왜냐하면 작성하는데, 이미 함께 도움을 주었기 때문이다. 자동으로 돌아가더라도 특별한 차이는 없다. 
      • 이후 새로운 변경은 일부 사용자들에게 노출된다. 만약 심각한 문제가 발생했다면 이 “카나리아 부분집합”은 다시 자동으로 롤백된다. 

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) 대신에, 내가 실제 숫자가 있는 보고서를 제공하겠다. 제대로된 보고서를 작성하려면 이정도 투자는 해줘야 한다.


1 2