DevOps 메트릭으로 CI/CD 성능 측정

CI/CD 파이프라인을 처음 만들 때, 자동 테스트를 작성하는 것부터 사전 프로덕션 환경이 자동으로 새로 고쳐지도록 설정하는 것까지 수많은 작업을 수행해야 합니다. 이 단계에서 어떻게 프로세스를 개선할 수 있을지 아이디어를 찾는 중이라면 CI/CD 모범 사례 가이드를 읽어 보세요.

자동화된 파이프라인을 구성하고 실행 중이라면 이제는 이 파이프라인의 효율성을 높일 차례입니다. 이 단계는 CI/CD 파이프라인의 메트릭을 활용한 지속적 개선의 주기가 시작되는 지점입니다.

Peter Drucker는 "측정할 수 없으면 관리할 수도 없다"고 말했습니다. 지속적 개선에 메트릭은 필수적입니다. 이 데이터를 활용하여 가치를 더할 수 있는 지점이 어디인지 식별하고 변경 사항의 영향을 측정하기 위한 베이스라인을 얻을 수 있습니다.

중요한 DevOps 메트릭을 모니터링하면 자동화된 테스트 커버리지 확장, 처리량 증가 또는 개발 작업 세분화 중에서 CI/CD 파이프라인의 성능에 가장 큰 영향을 주는 것은 무엇일지 판단할 수 있습니다.

CI/CD 파이프라인의 각 단계를 최적화할 때마다 이 피드백 루프의 효과는 배가됩니다. 이렇게 개선하면 변경 사항을 더욱 자주 릴리스하면서도 품질은 유지하고 불량률은 낮출 수 있습니다.

자주 릴리스하면 계속해서 주요 기능을 개선하고, 가설을 검증하기 위해 실험을 진행하고, 문제가 발생하면 즉각적으로 해결할 수 있습니다. 시장이 진화하고 기능에 대한 수요가 변화하면 빠르게 대응하면서 경쟁자들과 나란히 가거나 앞서갈 수도 있습니다.

게다가 CI/CD 메트릭을 모니터링하는 것은 파이프라인의 가치를 이해 관계자나 다른 개발 팀을 포함한 전사에 증명하기에 좋은 방법입니다.

배포 빈도는 CI/CD 파이프라인을 사용하여 프로덕션으로 배포하는 횟수를 기록합니다. 높은 배포 빈도는 배포마다 변경 사항이 적다는 의미이므로 DORA는 배포 빈도를 배치 크기의 프록시로 선택하였습니다.

크기가 작은 변경 사항을 배포하면 예상치 못한 결과를 내는 변수의 조합이 줄기 때문에 릴리스와 관련된 위험이 줄어듭니다. 자주 배포하면 작업에 관한 피드백을 더욱 즉각적으로 받을 수 있습니다.

배포 빈도가 낮다는 것은 파이프라인에 정기적으로 커밋이 들어오지 않는다는 의미일 수 있으며, 이는 작업을 충분히 세분화되지 않았기 때문일 수 있습니다. 모든 팀원이 CI/CD의 장점을 이해하는 DevOps 문화를 만들면 팀이 일을 세분화하여 작업하는 데 쉽게 적응할 수 있습니다.

종종 지속적인 배포 전략의 일환으로 변경 사항을 대규모 릴리스 배치로 처리하면 배포 빈도가 낮아지기도 합니다. 비즈니스상의 이유(예: 사용자의 기대)로 인해 변경 사항을 배치로 처리해야 하는 경우 스테이징 사이트로 배포되는 빈도를 대신 측정하는 것을 고려해 보세요.

리드 타임(또는 전달에 걸리는 시간 또는 시장에 도달하는 시간)은 기능 제작을 시작한 시점부터 사용자에게 출시될 때까지의 시간을 의미합니다. 그러나 아이디어 구상, 사용자 연구 및 프로토타입 제작에 걸리는 시간은 크게 달라질 수 있습니다.

이러한 이유로 DORA는 마지막 코드 커밋에서 배포까지 걸리는 시간을 측정합니다. 이 시간 동안에는 CI/CD 파이프라인에 속한 스테이지에 집중할 수 있습니다.

리드 타임이 길다는 것은 사용자에게 코드 변경 사항이 정기적으로 전달되지 않는다는 의미입니다. 이러한 상황에서는 사용 통계나 다른 피드백을 활용하여 빌드 중인 기능을 개선할 수 없게 됩니다.

다수의 수동 단계가 포함된 파이프라인에서 리드 타임이 길어지는 것은 흔한 일입니다. 이러한 단계에는 다수의 수동 테스트나 수동으로 환경을 새로 고쳐야 하는 배포 프로세스가 포함될 수 있습니다.

자동화된 테스트와 CI 서버에 투자하여 빌드, 테스트 및 배포 작업을 조율하면 소프트웨어를 전달하는 데 걸리는 시간이 줄어듭니다. 이와 동시에 CI 서버를 활용하여 투자 대비 수익률을 보여주는 메트릭을 수집할 수 있습니다.

지속적 통합 및 배포 프로세스를 이미 자동화하기 시작했으나 아직 여러 단계가 느리거나 불안정한 경우를 가정해 보겠습니다. 이때 빌드 시간 메트릭을 사용하면 병목이 발생하는 지점을 찾을 수 있습니다.

출시할 때마다 위험 평가나 변경 검토 위원회가 필요하다면, 배포하는 데 며칠 또는 몇 주가 더 걸릴 수 있습니다. 메트릭을 활용하여 프로세스의 신뢰도를 증명하면 이해 관계자의 신뢰를 얻고 수동 승인 절차의 필요성을 없앨 수 있습니다.

변경 실패율은 프로덕션으로 배포되는 변경 사항 중 중단 또는 버그를 발생시키고 롤백이나 핫픽스가 필요한 변경 사항의 비율을 의미합니다. 여기에는 프로덕션으로 코드가 배포되기 전에 발견된 문제는 포함되지 않습니다.

이 메트릭의 장점은 적용된 변경의 양적 측면에서 실패한 배포를 볼 수 있다는 것입니다. 낮은 변경 실패율은 파이프라인의 신뢰도를 높입니다. 이는 이전 단계가 제 역할을 하고 있고 코드가 릴리스되기 전에 대부분의 결함을 잡아낸다는 의미입니다.

변경 실패율이 높다면 자동화된 테스트 커버리지를 점검해 보아야 합니다. 테스트가 가장 일반적인 사례를 포함하나요? 테스트를 신뢰할 수 있나요? 테스트 구성을 자동화된 성능 또는 보안 테스트로 강화할 수 있나요?

평균 복구 혹은 해결 시간(MTTR)은 프로덕션 오류를 해결하는 데 걸리는 시간을 측정합니다. MTTR을 강조한다는 것은 변수가 많은 복잡한 시스템의 경우 프로덕션에서 일부 오류는 불가피하다는 것을 고려하는 것입니다. 완벽을 추구하기보다는(그러면서 잦은 릴리스의 장점을 포기하기보다) 문제에 빠르게 대응할 수 있는지에 집중하세요.

MTTR을 낮게 유지하려면 프로덕션을 선제적으로 모니터링하여 문제가 발생하면 이를 경고하도록 하고, 변경 사항을 롤백하거나 파이프라인을 통해 핫픽스를 배포할 수 있어야 합니다.

이와 관련된 메트릭인 평균 탐지 시간(MTTD)은 변경 사항이 배포된 후 모니터링 시스템이 해당 변경사항으로 인해 발생하는 문제를 탐지할 때까지 걸리는 시간을 측정합니다. MTTD와 빌드 시간을 비교하면 어느 영역에 투자하여 MTTR을 줄일 수 있을지 판단할 수 있습니다.

CI/CD 파이프라인의 자동화된 테스트는 대부분의 테스트 커버리지를 제공합니다. 자동화된 테스트의 첫 번째 레이어는 실행이 가장 빠르고 즉각적인 피드백을 주는 유닛 테스트여야 합니다.

코드 커버리지는 대부분의 CI 서버가 제공하는 메트릭으로서 유닛 테스트에 포함된 코드의 비율을 계산합니다. 이 메트릭을 모니터링하여 코드를 작성할 때 적절한 테스트 커버리지를 유지하고 있는지 확인하는 것이 좋습니다. 코드 커버리지가 떨어지기 시작한다면 이 가장 중요한 피드백에 신경을 써야 할 때입니다.

빌드 시간은 자동화된 파이프라인의 다양한 단계를 완료하는 데 걸리는 시간을 측정합니다. 프로세스의 각 단계에 소요되는 시간을 분석하면 테스트 결과를 얻거나 프로덕션에 배포할 때까지 걸리는 시간을 지연시킬 수 있는 문제 또는 병목 지점을 찾는 데 도움이 됩니다.

테스트 통과율은 해당 빌드에서 테스트를 성공적으로 통화한 사례의 비율입니다. 합리적인 수준의 자동화된 테스트를 시행하는 한, 이는 각 빌드의 품질을 측정하는 좋은 메트릭입니다. 이 데이터를 활용하면 코드 변경 사항이 얼마나 자주 새로운 버그를 일으키는지 파악할 수 있습니다.

자동화된 테스트로 오류를 식별하는 것이 수동 테스트나 프로덕션에서 문제를 발견하는 것보다 좋지만, 자동화된 테스트 중 특정 세트가 주기적으로 실패한다면 이러한 오류의 근본 원인을 살펴봐야 합니다.

테스트 수정 시간은 빌드에서 테스트 실패가 보고될 때부터 다음 빌드에서 해당 테스트가 통과할 때까지의 시간입니다. 이 메트릭을 활용하면 파이프라인에서 식별된 문제에 얼마나 빠르게 대응할 수 있는지 알 수 있습니다.

짧은 해결 시간은 파이프라인을 효율적으로 사용하고 있다는 의미입니다. 변경 사항을 아직 기억하고 있을 때 문제를 발견한 즉시 해결하는 것이 더 효율적입니다. 문제를 빠르게 해결하면 본인과 팀원이 안정적이지 않은 코드를 바탕으로 기능을 더 빌드하는 상황을 피할 수 있습니다.

배포가 실패하면 의도치 않은 중단이 발생할 수 있고, 배포를 롤백해야 하거나 긴급하게 수정해야 할 수도 있습니다. 실패한 배포의 수는 변경 실패율을 계산하는 데 사용됩니다.

전체 배포수에서 실패하는 비율을 모니터링하면 SLA 대비 성능을 측정하는 데 도움이 됩니다.

그러나 실패하는 배포를 0건(또는 매우 적은 수)으로 만들겠다는 목표는 별로 현실적이지 않으며 이로 인해 팀이 지속적으로 좋은 제품을 제공하기보다 확실성을 우선하게 될 수 있습니다. 이러한 생각을 가지면 변경 사항을 모아 배치로 처리하게 되기 때문에 리드 타임이 늘어나고 배포 크기도 커집니다. 대규모 배포에는 변수가 많기 때문에 프로덕션에서 수정하기 힘든(점검해야 하는 변경 사항이 더 많기 때문에) 실패가 발생할 확률이 높습니다.

실패한 배포 메트릭과 달리 결함 개수는 백로그상에서 버그로 분류된 열린 티켓의 수를 의미합니다. 이 CI 메트릭은 테스트, 스테이징 및 프로덕션 단계에서 발견된 문제로 세분화됩니다.

결함의 개수를 모니터링하면 결함 개수가 증가할 때 버그가 통제 불능 상태에 빠질 수 있음을 가리키는 경고를 받을 수 있습니다. 그러나 이 메트릭을 목표로 삼으면 팀이 티켓을 해결하기보다 분류하는 데 집중하게 될 수도 있으니 유의하세요.

빌드나 릴리스에 포함된 스토리 포인트 개수로 측정되는 배포 크기는 배포 빈도의 결과로서 특정 팀 내에서 배치 크기를 모니터링하는 데 사용할 수 있습니다.

배포 크기가 작게 유지된다는 것은 팀이 자주 변경 사항을 커밋하고 그에 수반되는 이점을 잘 활용하고 있다는 의미입니다. 그러나 개발 팀 간에 스토리 예상 시간은 직접 비교할 수 없으므로 이 지표를 사용하여 전체 배포 크기를 비교하면 안 됩니다.

이러한 DevOps 메트릭을 활용하면 배포 속도나 소프트웨어 품질 측면에서 CI/CD 파이프라인이 제 성능을 내고 있는지 더 명확하게 이해할 수 있습니다.

메트릭을 추적하면 프로세스에서 주의해야 하는 영역이 어디인지 식별할 수 있습니다. 변경 사항을 만든 후에는 관련 메트릭을 지속적으로 모니터링하여 의도한 효과가 나타나는지 검증하세요.

단, 메트릭은 성능을 나타내는 수치로는 유용하지만, 맥락을 고려하여 수치를 이해해야 하며 특정 메트릭이 어떠한 동작을 촉진할 수 있는지 고려해야 합니다.

목표는 수치 자체가 아니라 파이프라인을 빠르고 안정적으로 유지하여 사용자들에게 가치를 지속적으로 전달하고 조직의 목표를 지원하는 것임을 유념해야 합니다.