[The DevOps Handbook] (1) 데브옵스를 위한 세 가지 방법

2000년대에 이르러 기술의 진보와 애자일 원칙, 애자일 실천 방법의 도입으로 새로운 기능을 개발하는 데 필요한 시간이 수주 또는 수개월로 줄어들었다. 하지만 여전히 프로덕션 환경으로 배포하는 데는 수주에서 수개월이 소요돼서 때때로 치명적인 결과를 초래했다.

 

2010년에는 데브옵스의 도입, 하드웨어와 소프트웨어의 지속적인 상용화로 지금과 같은 클라우드 환경과 서비스를 몇 주 내로 만들고, 프로덕션 환경으로 단 몇 시간 또는 몇 분 만에 배포할 수 있게 됐다. 오늘날 데브옵스 원칙과 실천 방법을 도입한 조직은 보통 수백, 수천 개의 변경 사항을 매일 배포하고 있다. 이런 조직들은 실험을 통해 비즈니스 아이디어를 테스트하고, 어떤 아이디어가 고객과 조직 전체에 도움이 되는지를 발견할 수 있다. 또한 신속하고 안전하게 프로덕션 환경으로 배포할 수 있는 기능을 개발할 수도 있다.

 

데브옵스는 단순히 기술이 아니다. 데브옵스에 기반한 아키텍처, 문화적인 실천 방법은 많은 철학과 경영 운동의 융합을 의미한다. 이 글에서는 데브옵스에서 유도될 수 있는 세 가지 방법을 소개한다.

 

가치 흐름

1997년 린 기업 연구소는 린을 서비스 산업과 의료 서비스와 같은 다른 가치 흐름에 적용하기 위한 연구를 시작했다. 여기서 탄생한 린 원칙은 일관된 목적 생성, 과학적 사고 수용, 흐름과 풀 생성, 원천 품질의 보장과 겸손한 리더, 모든 개인을 존중하는 시스템을 통해 고객을 위한 가치를 어떻게 창출할 것인지에 중점을 둔다.

 

린 원칙의 가장 근본적인 개념 중 하나는 '가치 흐름'이다. 가치 흐름의 정의는 다음과 같다.

조직이 고객의 요구에 맟줘 출시에 착수하는 일련의 활동

 

가치 흐름은 제조 공정에서 쉽게 목격할 수 있는데, 고객의 주문이 접수되면 가치 흐름이 시작되고, 원자재가 생산 현장으로 출고된다. 우리는 지속적인 시스템 최적화를 통해 부드럽고 균형잡힌 흐름을 만들기 위해 끊임없이 노력해야 한다.

 

개발 작업이 시작된다고 가정해보자. 애자일 프로세스를 따르는 개발 팀들은 아이디어들을 기능 명세로 작성한다. 그 후, 서비스를 코드로 구현한다. 그리고 코드는 나머지 소프트웨어 시스템과 함께 각각의 변경 사항이 통합되고 테스트되는 버전 관리 저장소에 체크인된다.

 

가치는 서비스가 프로덕션 서버에서 동작할 때만 생성되므로 빠른 흐름을 제공할 뿐 아니라 서비스 중단이나 장애, 보안 실패, 규정 위반과 같은 혼란 없이 배포가 진행될 수 있도록 해야 한다. 여기서 우리의 목표는 빠른 흐름이 가능하게 하고, 높은 품질을 얻는 것이다.

 

일반적인 시나리오: 몇 달씩 소요되는 배포 리드타임

 

일상적인 비즈니스 상황에서는 배포 리드타임이 몇 달씩 걸리기도 한다. 특히, 이런 상황은 높은 결합도를 가진 애플리케이션, 통합 테스트 환경, 수동 테스트에 대한 높은 의존도, 복수의 승인 프로세스를 가지고 작업하는 복잡한 대형 조직에서 흔히 발생한다.

 

이상적인 데브옵스: 몇 분이면 충분한 배포 리드 타임

 

이상적인 데브옵스 환경에서 개발자는 자신의 작업에 대해 신속한 피드백을 받는다. 그 덕분에 개발자는 빠르고 독립적으로 코드를 실행하고 통합할 수 있고, 코드의 유효성을 검증할 수 있다.

 

첫 번째 방법: 흐름 원칙

기술 가치의 흐름은 개발에서 운영으로, 비즈니스와 고객 사이의 기능 영역들로 이어진다. 첫 번째 방법은 고객에게 가치를 신속히 전달하기 위해 개발에서 운영으로 빠르고 부드러운 작업 흐름을 요구한다. 또한 기능 개발 완료율, 테스트 발견 및 수정 비율, 운영 가용성 측정과 같은 지엽적인 목표 대신, 전체적인 목표를 최적화한다.

 

1. 업무 시각화하기

 

업무를 시각화함으로써 작업이 원활하게 진행되고 있는 부분과 작업이 대기 중이거나 중단된 부분을 확인할 수 있다. 이를 수행하는 가장 좋은 방법은 칸반 보드나 스프린트 계획 보드와 같은 시각적인 작업 보드를 활용해 실물 카드나 전자 카드에 상세히 표현하는 것이다. 이를 통해 모든 이해 당사자가 작업의 우선순위를 보다 쉽게 정할 수 있다.

 

2. 진행 중인 작업(WIP) 제한하기

 

WIP을 제한하면 작업 완료를 방해하는 문제를 쉽게 발견할 수 있다. 예를 들어, WIP을 제한하면 다른 누군가의 작업을 기다리고 있기 때문에 아무런 작업도 하지 못하고 있었다는 사실이 드러난다. 새로운 일을 시작하는 것에 대한 유혹이 있을 수 있지만, 지연을 유발하는 원인을 찾아 문제를 해결하는 것이 훨씬 더 좋은 방법이다. 사람들이 여러 프로젝트에 배정된 경우에는 잘못된 멀티태스킹과 우선순위와 관련된 문제가 많이 발생하기 마련이다.

 

3. 배치 작업의 크기 줄이기

 

소규모 배치는 더 적은 WIP, 더 빠른 리드타임과 신속한 오류 감지를 통해 재작업을 줄이는 결과를 가져온다. 이에 비해 대규모 배치는 높은 수준의 WIP와 함께 워크센터의 막대한 혼란을 야기한다. 결과족으로, 좋지 못한 작업 흐름과 품질 저하를 가져온다. 이것은 프로덕션 환경에 적용되는 변화의 양이 커질수록 프로덕션 오류의 진단과 수정이 어렵고, 오류를 해결하는 시간이 오래 걸린다는 사실을 입증한다.

 

4. 핸드오프 횟수 줄이기

 

작업이 팀에서 팀으로 넘어갈 때마다 요청, 지정, 일정 계획, 분쟁 회피, 테스트, 확인과 같은 유형의 의사소통이 필요하다.  이 과정에서 기술 명세서 작성과 회의, 이메일, 전화를 통한 커뮤니케이션 그리고 파일 시스템 공유와 같은 서로 다른 시스템을 사용해야 할 수도 있다.

 

최선의 상황이라 하더라도 핸드오프 작업 시에는 필연적으로 일부 지식이 손실된다. 이런 유형의 문제를 해결하기 위해 업무의 상당 부분을 자동화하거나 팀을 재구성해야 한다. 이를 통해, 해당 팀에서 자체적으로 고객에게 가치를 제공할 수 있도록 함으로써 핸드오프의 횟수를 줄여야 한다. 결과적으로, 대기열에서 작업을 기다리는 시간을 줄일 수 있다.

 

5. 제약조건을 지속적으로 확인하고 향상시키기

 

모든 가치 흐름에는 언제나 흐름의 방향과 제약조건이 있다. 제약조건은 일반적으로 다음과 같은 과정을 따른다.

• 환경 생성: 항상 프로덕션 환경과 테스트 환경을 몇 주에서 몇 달씩 기다려야 한다면, 온디맨드 배포를 수행할 수 없다.
• 코드 배포: 프로덕션 코드 배포 시마다 몇 주에서 몇 개월이 걸린다면, 온디맨드 배포를 수행할 수 없다.
• 테스트 설정 및 실행: 모든 코드 배포시, 테스트 환경과 데이터 세트 설정에 2주, 회귀 테스트의 수동 실행에 4주가 더 걸린다면, 온디맨드 배포를 수행할 수 없다.
• 과도하게 타이트한 아키텍처: 코드를 변경하려고 할 때마다 엔지니어를 여러 위원회 회의 보내 해당 코드 변경에 대한 승인을 받아야 한다면, 온디맨드 배포를 수행할 수 없다.

이런 모든 제약조건이 제거되면 남은 제약조건은 개발 팀이나 제품 관리자가 될 것이다.

 

6. 가치 흐름에서 어려움과 낭비 제거하기

 

소프트웨어 개발 흐름에서의 낭비와 어려움은 '결과에 영향을 미치지 않고 우회할 수 있는 활동처럼 고객에게 지연을 초래하는 모든 것' 이다. 일반적인 범주는 다음과 같다.

• 미완성 작업: 가치 흐름 내의 작업 중 완료되지 않았거나 대기열에 놓여 있는 모든 작업.
• 추가 프로세스: 프로세스 수행 중 고객에게 가치를 제공하지 않는 모든 추가 작업.
• 추가 작업: 조직이나 고객이 필요로 하지 않는 기능을 서비스로 구현하는 것.
• 작업 전환: 사람들이 여러 프로젝트와 가치 흐름에 배정돼, 작업 사이의 컨텍스트 전환 및 의존성 관리를 필요로 하게 되고, 가치 흐름에 부가적인 노력과 시간을 추가하는 것.
• 대기: 현재 작업을 완료할 수 있을 때까지 대기하도록 만드는 작업 사이의 모든 지연.
• 동작: 하나의 워크센터에서 다른 워크센터로 정보와 자료를 이동시키기 위한 노력의 양.
• 결함: 정보, 자료 및 제품이 부정확하거나, 누락될 때 낭비가 발생.
• 비표준 및 수동 작업: 재구축되지 않은 서버, 테스트 환경 및 구성의 사용과 같이 외부의 비표준 작업이나 수동 작업에 의존하는 것.

 

우리는 빠른 흐름이라는 목표를 달성하기 위해 이런 부담과 고난을 완화하고 제거해야한다.

 

두 번째 방법: 피드백 원칙

두 번째 방법에서는 가치 흐름의 모든 단계에서 상호 간 신속하고 지속적인 피드백을 가능하게 하는 원칙을 설명한다. 우리의 목표는 더 안전하고 탄력적인 작업 시스템을 만드는 것이다.

 

1. 복잡한 시스템에서 안전하게 작업하기

 

복잡한 시스템은 일반적으로 컴포넌트들의 상호 연결성이 높으며, 시스템 수준의 동작은 시스템 구성 요소의 동작 측면만으로 단순하게 설명하기 어렵다. 이러한 특징은 단일 사용자의 능력으로는 확인하기 어렵다는 점이다. 복잡한 시스템을 완벽하게 안전한 시스템으로 설계하는 일은 어려운 일이지만, 다음과 같은 네 가지 조건을 만족한다면 복잡한 시스템에서 더 안전하게 작업할 수 있다.

• 복잡한 작업이 관리된다. 따라서 설계 및 운영상의 문제점이 드러난다.
• 문제점이 넘쳐나고 해결됨으로써 새로운 지식을 빠르게 구축할 수 있다.
• 새로운 지역적 지식을 전사적으로 활용한다.
• 리더는 이런 유형의 역량을 지속적으로 성장시키는 또 다른 리더를 만든다.

 

2. 문제를 발생 시점에 확인하기

 

문제를 빠르게 찾아 수정하고 학습 및 혁신할 수 있는 능력은 작업 시스템에 피드백과 피드포워드 루프를 생성할 수 있다. 빠른 피드백 루프와 포워드 루프의 생성은 자동화된 빌드, 통합, 테스트 프로세스를 생성하는 역할을 한다. 따라서 올바른 기능과 배포 가능한 상태를 벗어나는 변경 사항이 발생하면 곧바로 감지할 수 있다.

 

피드백 루프는 문제의 신속한 탐지와 복구를 가능하게 할 뿐 아니라 향후 같은 문제가 발생하는 것을 방지하는 방법도 알려둔다. 이를 통해, 작업 시스템의 품질과 안정성이 높아지고 조직 학습이 생성된다.

 

3. 새로운 지식 축적을 위한 문제의 스워밍과 해결

 

예상치 못한 상황이 발생했을 때, 단순히 문제를 감지하는 것만으로는 충분하지 않다. 문제가 발생하면 스워밍해서 문제 해결에 필요한 사람을 동원해야 한다. 여기서 스워밍의 목적은 문제가 확산되는 것을 방지하고, 문제를 진단하고 해결해 잽잘을 막는 것이다. 스워밍이 필요한 이유는 다음과 같다.

• 문제가 다운 스트림으로 전파되는 것을 방지한다.
• 워크센터에서 새로운 작업이 시작되는 것을 방지한다.
• 문제가 해결되지 않으면, 워크센터의 다음 공정에 동일한 문제가 발생해 더 많은 수정과 작업이 필요할 수도 있다.

 

스워밍은 희도적으로 한 부분의 문제가 전체 작업에 혼란을 주는 것을 허용함으로써 일반적인 관리 관행에는 반하는 것처럼 보인다. 그러나 스워밍은 학습을 가능 하게 한다. 그리고 기억과 환경 변화로 인한 중요한 정보의 손실을 방지한다. 이러한 정보 손실 방지는 사람, 프로세스, 제품, 장소나 환경의 예상치 못한 상호작용으로 문제가 많이 발생하는 복잡한 시스템에서 특히 더 중요하다.

 

4. 품질 활동을 원천에 더 가깝게 유지하기

 

품질 활동의 효율성은 의사결정정 단계가 실제 작업이 수행되는 단계에서 더 멀리 떨어뜨릴수록 감소한다. 예를 들면, 의사 결정 단계가 작업 단계와 더 멀리 있을수록 의사결정의 질이 낮아질 뿐 아니라 의사결정의 주기 시간이 늘어나 원인과 결과 사이의 피드백 인과관계가 낮아지고, 성공과 실패를 통한 학습 능력이 저하된다. 비효율적인 품질 관리의 예는 다음과 같다.

• 쉽게 작업할 수 있는 일임에도 불구하고 다른 팀에게 미룬다.
• 실제 작업과 멀리 떨어져 있는 사람에게 승인을 요구하거나, 자세한 검토 없이 단순히 승인 도장만 찍게 한다.
• 작성되고 나면 금방 쓸모가 없어지거나, 꼭 필요한지 의심스러운 세부 사항이 담긴 대량의 문서를 만든다.
• 대규모 배치 작업을 팀과 팀과 특별 위원회가 승인하고 처리하도록 밀어붙인 후, 응답을 기다린다.

 

이와 같은 비효율적인 품질 관리를 해결하려면 가치 흐름상에 있는 사람이 필요하다. 멀리 있는 임원의 승인에 의존하기보다는 업무가 수행되는 곳에서 품질과 안전에 대한 책임을 담당하고, 의사결정을 해야한다. 이때 동료평가가 좋은 방법이 될 수 있다.

 

세 번째 방법: 지속적인 학습과 실험 원칙

세 번째 방법은 지속적인 학습과 실험 문화를 생성하는 데 중점을 둔다. 이 원칙은 팀과 조직의 지식으로 확장되는 개인 지식의 끊임없는 생성을 가능하게 한다. 기술 가치 흐름에서 우리의 목표는 모두가 일상 업무에서 위험을 감수해야 하는 평생 학습자임을 강조하고, 높은 신뢰의 문화를 생성하는 것이다. 이를 위해 시간을 할당해 학습을 보장하고, 지속적인 개선을 위해 시스템에 끊임없이 스트레스를 가해야하며, 탄력성을 높이기 위해 통제된 조건에서 프로덕션 서비스의 실패를 시뮬레이션하고 오류를 주입해야 한다. 

 

1. 조직적 학습과 안전 문화 활성화하기

 

기술 가치 흐름에서는 안전한 작업 체계를 구축하려는 노력을 통해 생성적 문화의 토대를 마련한다. 사고나 고장이 발생하면 실수한 사람을 찾는 대신, 사고가 다시 발생하지 않도록 시스템을 재설계할 수 있는 방법을 찾는다.

 

예를 들어, 사고가 발생한 후에 '비난 없는 포스트모템'을 진행할 수 있다. 이를 통해 사고의 발생 원인을 가장 잘 이해하고, 시스템을 개선하기 위한 최선의 대응책이 무엇인지 합의할 수 있다. 이상적으로는 문제의 재발 방지와 신속한 감지 미 복구도 가능하다.

 

2. 일상 업무 개선을 제도화하기

 

기술 가치 흐름에서 문제 해결을 회피하고 일상적인 작업에 의존하면 문제와 기술 부채가 누적된다. 일상 업무를 개선하기 위해서는 기술 부채 청산, 결함 수정, 코드와 환경 문제 영역의 리팩토링 및 개선 시간의 명시적인 확보가 필요하다. 이를 실천하면 모든 사람이 일상 업무 수행 시 통제 영역 내에서 문제를 발견하고 수정할 수 있다. 

 

3. 지역적인 발견을 조직 전체의 개선으로 전환하기

 

개인이나 팀에서 새롭게 학습한 내용이 발견되면, 반드시 조직의 다른 구성원들이 해당 지식을 사용하고 혜택을 얻을 수 있도록 만드는 메커니즘이 있어야 한다. 이를 통해, 누군가 어떤 작업을 하는 경우, 조직 내에서 해당 작업과 동일한 작업을 했던 모든 사람의 누적된 집단 경험을 활용해 작업을 수행할 수 있다.

 

4. 일상 업무에 탄력성 패턴 적용하기

 

기술 가치 흐름에서 항상 배포 리드타임을 감소시키는 방법을 찾고, 테스트의 적용 범위를 늘리며, 테스트 실행 시간을 줄이고, 갭잘자 생산성과 안정성을 높이려면, 아키텍처를 재설계해 동일한 유형의 긴장을 시스템에 도입해야 한다. 예를 들면 전체 데이터센터의 전력 차단과 같은 대규모의 실패를 연습하는 "게임 데이"를 실행할 수도 있다. 그리고 원하는 만큼의 탄력성을 확보하기 위해 프로덕션 환경에 대규모 오류를 주입할 수도 있다.

 

5. 리더가 학습 문화를 강화하기

 

전통적인 의미에서 리더는 목표를 설정하고, 해당 목표 달성을 위한 자원 배분과 적절한 인센티브의 조합 설정을 책임지는 사람이다. 다시 말해, 리더는 "모든 올바른 결정을 내린다."라는 원칙을 갖고 조직을 이끌었다. 하지만 진정한 위대함을 창출하기 위해서는 상호 의존적인 리더와 팀원이 필요하다.

 

리더는 학습과 훈련된 문제 해결의 가치를 높여야 한다. 예를 들어, 리더가 실험을 수행하는 사람을 코칭하는 데 도움이 되는 질문은 다음과 같다.

• 마지막 단계는 무엇이며, 어떤 일이 일어났는가?
• 무엇을 배웠는가?
• 현재의 상태는 어떠한가?
• 다음 목표 상태는 무엇인가?
• 작업하는 데 있어 장애 사항은 무엇인가?
• 다음 단계는 무엇인가?
• 예상되는 결과는 무엇인가?
• 언제 확인할 수 있는가?

 

Reference

https://product.kyobobook.co.kr/detail/S000001804670

데브옵스 핸드북 | 진 킴 - 교보문고