해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 3 - High-performing engineering teams and the Holy Grail
1. 소프트웨어 딜리버리가 중요한 이유
CI 도입이 확대되면서 많은 팀들이 '어떻게든 성장하자'라는 식의 사고방식을 가져왔다.
하지만 소프트웨어 시스템이 복잡해짐에 따라, 모든 시스템을 유지관리해야하는 인지 부하가 개발자와 운영팀 모두에게 너무 커졌다.
이로 인해, 팀들이 절차를 생략하기 시작하는 상황이 발생하였고, 안정성 문제가 일어나기 시작했다. 따라서, DevOps 팀은 복잡성을 일부 덜어내고, 발생할 수 있는 장애로부터 시스템이 신속하게 복귀될 수 있도록 지원할 수 있는 위치에 있어야하며, 이런 역할을 기대하기 위해 많은 회사들이 플랫폼 팀을 도입하게 되었다.
해당 강의에서는 성공에 대해 단 하나의 정답이 있다고 믿지 않는다고 한다.
하지만, 고성과를 이룬 데이터 및 벤치마크들을 참고하여 자신들만의 원칙을 세우는 것이 중요하다고 강조하였다.
2. 성과 높은 팀을 측정하는 4가지 지표
2-1. Duration (빌드 및 테스트 시간)
기간이란, 작업 단위 하나를 Pipeline을 통해 이동시키는 데 필요한 평균 시간이다.
이는 파이프라인이 코드의 상태와 품질에 대한 피드백을 얼마나 효율적으로 전달하는지에 대한 지표로 보는 것이 가장 좋다.
Agile 부터 DevOps에 이르기까지 대부분의 소프트웨어 딜리버리의 핵심전제는 고객이나 관계자로부터 정보를 받아 빠르고 효과적으로 대응하는 능력인 '속도'이다.
이러한 빠른 피드백과 딜리버리 주기는 조직과 사용자의 이익만 제공하는 것이 아닌, 개발자들을 행복하게 하며 '중단 없는 몰입' 상태를 유지할 수 있도록 돕는다.
하지만, 너무 속도에만 집중하게 되면 안정성이 희생이 된다. 따라서, 속도와 안정성 둘다 잡기 위해서는 파이프라인이 모든 잠재적인 실패지점으로부터 보호되어야 하며, 프로덕션에 도달하기 전에 결함을 즉시 수정할 수 있는 실행가능한 정보를 제공해야 한다.
강의에서 이상적인 Duration은 10분 이내 (빌드를 10분 이내로 유지)라고 하였으며 , 빌드가 3~40분 이상이 걸리게 된다면 효율성을 잃고 개발자의 몰입 상태를 방해하게 되어 결국에는 생산성이 저하되게 된다.
따라서, Duration의 수치를 개선하기 위해서는 '테스트 스위트 (Test Suite : 테스트 케이스의 집합)를 개선하고 더 강력한 테스트 커버리지를 확보'해야 한다. 즉, 속도때문에 테스트를 2순위로 미루지 않고 균형을 이루는 것이 중요하다는 의미이다.
2-2. Mean Time to Recovery (평균 복구 시간)
평균 복구 시간이란, 실패한 빌드 신호에서 성공적인 파이프라인 실행까지 걸리는 평균시간이다.
해당 지표는 팀의 회복탄력성과 CI 시스템으로부터 받은 피드백에 빠르고 효과적으로 대응하는 능력을 나타내며, 이는 DevOps 조직이 얼마나 성숙했는지 보여주는 지표가 된다.
마틴 파울러 (Martin Fowler)
"지속적인 빌드의 핵심은 메인라인 빌드가 실패하면 즉시 수정해야 한다는 것이다."
따라서, 어떤 브랜치에서든 깨진 빌드를 60분 이내에 수정하는 것을 목표로 삼는 것이 좋다.
복구 시간을 줄이기 위한 첫 단계는 기본 브랜치를 조직과 회사의 생명선으로 여겨 빌드가 실패하였을때 성공으로 되돌리는 것이 모두의 최우선이 되어야 한다. 이러한 문화를 갖추고 주의를 기울이면, 조직은 오류로 인해 발생할 수 있는 위험을 크게 줄일 수 있다.
두번째로는, 평균 해결 시간을 단축할 수 있는 가장 짧은 시간은 다음 파이프라인 실행시간과 같으므로, 파이프라인 시간을 단축하기 위한 최적화를 고려하는 것이다.
2-3. Success Rate (성공률)
성공률의 벤치마크는 '기본 브랜치에서 90% 이상을 유지'하는 것이다.
비록 실제 보고서 데이터에는 기본 브랜치 성공률이 평균 77%라고 하지만, 이상적인 성공률을 위해 개발 브랜치에서 새로운 시도 및 개발을 진행하고, 실제 프로덕션을 위한 기본 브랜치의 성공률을 높이기 위해 노력해야한다고 강조한다.
하지만, 성공률도 중요하나 훨씬 더 중요한 사안은 팀이 '기간(Duration) 지표를 통해 신호를 빠르게 받아들이고 오류는 효과적으로 수정하는 평균 해결시간' 능력이다.
2-4. Throughput (처리량)
처리량은 개발자들이 24시간동안 코드베이스에 커밋하는 변경 사항의 수를 반영한다.
CI 시스템을 통해 얼마나 많은 작업 단위가 이동하는지를 추적하므로 팀의 Flow를 측정하는데 유용하다.
강의에서 제시하는 보고서 데이터에서는 하루에 약 1.5회의 워크플로우 실행이 중앙값이었으며, 상위 5%는 하루에 7회 이상 실행한다고 한다.
사실 성공률과 기간이 뒷받침되어야 높은 처리량이 빛을 볼 수 있으며, 품질이 낮은 코드를 자주 사용자에게 푸시한다면 높은 처리량은 아무 의미가 없다.
따라서, 임의의 처리량 목표를 설정하는 대신, 비즈니스 요구를 반영하는 목표를 설정하고, 기준 측정치를 확보하고, 현재 작업 중인 것이 무엇인지 이해하고, 팀의 작업 방식 변화를 나타내는 변동을 모니터링한 다음, 조정할 수 있는 방법을 찾는 것이 정말 중요하다.
3. 결론: 지속적인 개선을 향해 나아가야 한다.
강의에서는 모든 팀과 조직이 다르기 때문에 '모든 경우에 적용되는 단 하나의 정답은 없다'고 강조한다. 아마존의 빌드 횟수를 우리 팀의 목표로 삼을 수 없는 것처럼, 각자의 비즈니스 상황과 목표에 맞는 전략이 필요하다.
따라서, 가장 중요한 첫 단계는 우리 팀의 현재 상황을 4가지 핵심 지표를 통해 측정하고 Baseline을 설정하는 것이다.
4가지 핵심지표는
- Duration (빌드 및 테스트 시간)
- Mean Time to Recovery (평균 복구 시간)
- Success Rate (성공률)
- Throughput (처리량)
으로, 해당 지표들은 독립적인 것이 아니라 서로 긴밀하게 연결되어있다.
궁극적으로 이 지표들을 개선하여 '개발 과정의 마찰을 줄이고, 개발자들이 몰입상태에서 행복하게 일할 수 있는 환경을 만들어야 한다.'
