DevOps 텍스트 교육

DevOps 업무 흐름을 어떻게 원활하게 만드나요?

DevOps에서 흐름은 아이디어부터 프로덕션 시스템에서 실행되는 코드까지 이어지는 소프트웨어의 엔드투엔드 생산 과정을 뜻합니다. 본인과 DevOps 팀은 신뢰할 수 있고 일관되며 빠른 흐름을 구축하고 유지하여 조직 목표를 달성하고 뛰어넘으며 해당 시장의 다른 제품과 서비스보다 앞설 책임이 있습니다.

DevOps 전환의 사명 정하기

DevOps 팀을 구성했다면 다음 단계는 사명을 정하는 것입니다. 공통 사명이 있어야 팀이 제대로 기능합니다. 사명이 없으면 핵심 업무에 우선순위를 부여하거나 진행을 막는 중대한 문제와 잡무를 구분하지 못합니다. 사명은 도전적이고 인상적이면서도 주어진 시간 내에 달성할 수 있어야 합니다.

사명은 각 DevOps 팀에 맞춰야 합니다. 팀과 상호작용하는 내부 및 외부 고객을 지원할 수 있도록 조직의 특징, 과제, 목표를 바탕으로 정합니다.

DevOps 전환을 시작할 때 사용할 수 있는 사명 선언문의 예는 다음과 같습니다.

• 3개월 안에 코드 체크인부터 프로덕션 가동까지의 평균 리드 타임을 75% 줄입니다.
• 6개월 안에 요청부터 프로덕션 가동까지의 평균 리드 타임을 33% 줄입니다.
• 12개월 안에 프로덕션 인시던트 수를 50% 줄입니다.

가치 흐름은 무엇이며 누가 참여하나요?

업무를 개선하려면 가치 흐름을 알아야 합니다. 정보기술 시스템에서 가치 흐름은 특정 소프트웨어 제품과 서비스를 설계하고 구축하고 운영하는 데 필요한 활동의 연속입니다. 또한 흐름에 필요한 인력, 지식, 설비 및 자재를 정의합니다.

복잡한 조직에서는 한 사람이 엔드투엔드 가치 흐름 전체를 파악할 수 없습니다. 따라서 DevOps 팀원 전체, 이해관계자, 공급업체, 고객 대표, 가능하다면 고객 본인까지 참여해 가치 흐름을 파악해야 합니다.

가치 흐름 지도를 그려 개선 기회 찾기

가치 흐름 지도를 이용하면 본인과 DevOps 팀이 소프트웨어 개발 및 제공 조직에서 일반적인 업무가 어떻게 수행되는지 시각화할 수 있습니다. 목적은 모든 업무 단계를 빠짐없이 문서화하는 데 있지 않습니다. 일반적인 작업 흐름을 충분히 파악하여 주요 비효율, 제약, 문제, 시간과 자원의 낭비가 있는 위치를 찾는 것이 목적입니다.

소프트웨어 개발 및 운영 엔지니어가 처음 모여 가치 흐름 지도를 그리면, 운영 엔지니어는 잘못 구성되어 테이블스페이스가 없는 데이터베이스 서버가 개발팀에 미치는 악영향을 처음 이해하는 경우가 많습니다. 마찬가지로 개발 엔지니어는 모니터링, 가용성, 테스트 가능성, 구성 기능을 내장하지 않은 채 소프트웨어를 제공했을 때의 결과를 처음 보는 경우가 많습니다.

인계, 제약 및 낭비를 최대한 없애기

인계, 낭비, 제약은 효율에 매우 중요한 영향을 주지만 간과되기 쉽습니다. 한 팀에서 다른 팀으로 활동을 인계할 때는 알림, 요청, 일정 조정, 우선순위 지정과 조정, 갈등 해결이 필요합니다.

팀 간에 업무가 넘어갈 때마다 정보가 사라질 뿐 아니라 가치 흐름의 전체 리드 타임도 늘어납니다.

이러한 문제를 해결하려면 다음을 시도하세요.

• 각 인계에 걸리는 시간이 적절한지 따져봐야 합니다. 예를 들어 위 가치 흐름 지도에서 테스트에 성공한 코드를 배포팀이 가져가기까지 80시간이 걸립니다. 왜 그럴까요? 이 과정을 자동화할 수 없을까요? 물론 가능합니다.
• 반복적인 인계에서 발생하는 낭비를 없애야 합니다. 위의 가치 흐름 지도 예에서 테스트팀은 기능의 65%를 개발팀에 되돌려 보냅니다. 일부 결함 수정은 테스터가 승인할 때까지 최대 3번 제공해야 합니다. 개발팀과 테스트팀이 더 잘 통합되도록 하여 반복 작업을 앞당길 수 있지 않을까요? 결함이 많다는 것은 개발팀의 일부 작업이 최적으로 이루어지지 않는다는 뜻입니다. 품질 문제의 원인을 찾고 해결해야 합니다.
• 인계가 필요한지 따져보고 가능한 한 없애야 합니다. 위의 가치 흐름 지도 예에서는 요청을 구체화한 뒤 승인권자가 처리할 때까지 320시간이 걸립니다. 조직에 왜 이 승인권자가 필요할까요? 가치 흐름에 어떤 가치를 줄까요? 좋은 결정을 내리는 데 충분한 정보와 관점을 갖고 있나요? 승인권자가 요청을 구체화하는 팀에 참여하면 무엇을 승인하는지 훨씬 잘 알고, 320시간이 걸리는 인계를 한 건 줄일 수 있지 않을까요? 흐름을 늦추는 제약과 장벽을 없애지 않으면 DevOps에 많은 것을 기대하기 어렵습니다.

DevOps에서는 현 상태를 바꾸기 위해 이런 질문을 던집니다. 조직의 모든 사람이 질문을 반가워할 리는 없지만, 여러분은 이미 준비되어 있습니다.

누구나 업무 흐름을 볼 수 있게 하기

업무가 왼쪽에서 오른쪽으로 원활히 흐르고 DevOps 조직이 목표를 이루려면 흐름을 가시화하는 도구와 장치가 필요합니다. IT에서는 마우스 클릭 한 번이면 가치 흐름의 한 팀에서 다른 팀으로 일을 배정할 수 있습니다. 하지만 작업이 미완료 상태이거나 종속성이 일치하지 않거나 오해가 있어, ‘한 걸음 전진하고 두 걸음 후퇴’하듯 팀 사이에서 일이 오갑니다. 아예 멈추거나 매우 느리게 진행되는 일이 일상입니다.

따라서 팀뿐 아니라 모두가 흐름을 볼 수 있어야 합니다. DevOps는 제품 백로그, 스프린트 계획 백로그, 칸반 보드로 흐름을 시각화합니다. 자체 DevOps 팀에 속한 작업만 담기보다 제품 및 서비스의 아이디어 구상부터 운영, 유지보수 및 서비스 종료까지의 전체 흐름을 가시화해야 합니다. 그러면 업무가 막힐 때 모두가 신속히 파악할 수 있습니다. 장애물을 제거해 업무가 지속적으로 원활하게 흐르도록 하는 일은 모두의 공동 책임입니다.

배치 크기와 진행 중 작업량 제한하기

다음 기관에서 Stanford University 실시한 연구에 따르면 여러 일을 동시에 하면 한 번에 하나씩 할 때보다 생산성이 낮습니다. 여러 전자 정보에 늘 노출되는 사람은 한 번에 한 작업을 하는 사람보다 집중하고, 정보를 기억하고, 다른 일로 전환하는 능력이 떨어진다는 점도 발견했습니다.

DevOps 팀에는 어떤 의미인가요? 진행 중 작업을 줄이고 코드 제공 배치 크기를 제한해야 한다는 뜻입니다. 예를 들어 팀은 작업을 계속 바꾸지 않고 눈앞의 일에 집중할 수 있도록 동시에 개발할 작업을 최대 6개로 제한할 수 있습니다. 또는 피보나치 수(0, 1, 2, 3, 5, 8, 13, 21, 34, …)를 사용한 스토리 포인트로 작업을 추정하고, 한 기간(스프린트)에 일정한 총 스토리 포인트(속도)만 처리할 수 있습니다.

제공 배치를 작게 하면 품질과 생산성이 높아지고 문제의 근본 원인도 더 빨리 찾아 해결할 수 있습니다. 작업을 끝내면 공통 코드 저장소에 체크인하고 지속적 통합 플랫폼에서 검증한 뒤 프로덕션에 배포합니다. 배치가 작으면 코드 제공으로 생긴 프로덕션 문제를 더 쉽게 파악하고 필요할 때 덜 번거롭게 롤백할 수 있습니다. 또한 프로덕션에 계속 제공하면서 팀은 조직의 사명에 기여한다는 자부심을 계속 느낍니다. 이 방식과 8개월 동안 코드를 만들면서도 한 줄도 프로덕션에 제공하지 않는 팀의 사기, 동기, 기술적 어려움을 비교해 보세요.

시간의 20%를 기술 부채를 줄이는 데 쓰기

조직이 기술 부채를 줄일 시간을 확보하지 않은 채 임시방편을 계속 덧붙이면 결국 모든 엔지니어가 문제를 고치는 데 시간을 전부 쓰게 됩니다. 재정적 부채에 비유하면 이자만 갚는 셈입니다.

결론

이 장에서는 DevOps의 가치 흐름과 업무 흐름이 무엇이고 왜 중요한지, 업무가 가치 흐름을 따라 진행되도록 어떻게 하는지 다뤘습니다.