지속적 제공: 비즈니스 가치, 이점, 과제 및 메트릭

1. 속도

자동화된 소프트웨어 제공 파이프라인으로 조직이 시장 변화에 더 효과적으로 대응할 수 있습니다. 새 기능의 유통 기한을 줄이려면 속도가 가장 중요합니다. 시장 출시 속도가 짧으면 조직은 경쟁에서 앞서고 비즈니스를 유지할 가능성이 더 높습니다.

속도 자체는 성공 메트릭이 아니라는 것을 기억하세요. 품질이 없으면 속도는 소용이 없습니다. 지속적 제공 파이프라인이 잘못된 코드를 빠른 속도로 프로덕션에 보내는 것은 아무 소용이 없습니다.

2. 생산성

생산성은 만족으로 이어지고 만족도가 높은 팀은 참여도가 더 높습니다.

발견된 모든 결함에 대해 버그 보고서를 작성하는 것과 같이 지루하고 반복적인 작업을 수동이 아니라 파이프라인을 통해 수행할 수 있으면 생산성이 높아집니다. 파이프라인이 실행을 하는 동안 팀은 비전에 집중할 수 있습니다. 게다가 모두 어려운 일을 도구에 맡기고 싶을 것입니다.

팀은 파이프라인에서 보고된 문제를 조사하고 수정 사항을 커밋한 후에는 파이프라인을 다시 실행하여 문제가 수정되었는지, 의도치 않게 새로운 문제가 발생했는지 검증합니다.

3. 지속 가능성

기업은 스프린트뿐만 아니라 마라톤에서도 이기고 싶어 합니다. Atlassian은 앞서가는 데는 투지가 필요하다는 것을 알고 있습니다. 지속적으로 앞서가는 것은 훨씬 더 어려울 수 있습니다. 규율과 엄격함이 필요합니다. 연중무휴 24시간 열심히 일하면 빠르게 번아웃이 발생할 것입니다. 그 대신 스마트하게 일하고 반복적인 작업은 커피를 마실 휴식 시간이 필요하지도 않고 말대꾸도 하지 않는 기계에 맡기세요.

기술 회사든 아니든 모든 조직은 기술을 사용하여 차별화하고 있습니다. 자동 파이프라인은 수작업을 줄이고 인건비가 도구보다 비싸기 때문에 궁극적인 비용 절감으로 이어집니다. 가파른 선행 투자로 인해 경험이 부족한 리더십에 대한 우려가 생길 수 있지만 잘 설계된 파이프라인은 조직이 고객의 요구를 충족하기 위해 더 빠르고 효과적으로 혁신해야 합니다. CD는 기업에 기능과 수정 사항을 더 유연하게 제공합니다. 설계된 대로 작동하고 확장하기 위해 특정 기능 세트를 특정 고객이나 일부 고객에게 릴리스할 수 있습니다. 기능을 테스트하고 개발하되 제품에 휴면 상태로 두었다가 여러 릴리스에 적용할 수 있습니다. 마케팅 부서가 매년 열리는 업계 대회에서 "큰 인기"를 끌고 싶어 합니까? 지속적 제공이 있다면 가능할 뿐만 아니라 간단한 요청입니다.

예산이 너무 적습니까?

지속적 제공 파이프라인 구축에는 최고의 인력이 소모됩니다. 카펫 밑에 깔아놓을 수 있는 사이드 프로젝트가 아닙니다. 저는 신규 팀원을 할당하고 최신 도구를 구입하는 데서 시작하는 조직이 있다는 사실에 항상 놀랍니다. 그런 조직에서도 나중에는 결국 방향을 수정하고 아키텍처 디커플링 및 탄력적인 지속적 제공 파이프라인에 투자하도록 선임 아키텍트를 할당합니다.

지나치게 낮은 금액을 책정하지 말고 비전에 따라 실행이 중단되지 않도록 적절한 금액을 따로 마련해 두세요. 지속적 제공 파이프라인 MVP(최소 실행 가능한 제품)를 제공한 다음 조직 전체로 확장하세요.

미래 지향적인 팀원이 있습니까?

예산이 있더라도 결국 실행은 팀원과 관련된 문제가 될 수 있습니다.

팀은 두려움 없이 자동화하여 업무를 중단하고 새 프로젝트로 넘어가야 합니다. 원래 수동으로 하던 작업을 에이전트가 자동화하는 것에 대해 걱정하는 팀원이 있다면 잘못된 팀원을 두고 있는 것입니다.

멈췄다고 느껴질 경우에는 기어를 변속하세요. 팀원이 더 빠르게 달리는 말만 요구해도 자동차를 제공하는 방법을 알아보세요! 첫 번째 장애물을 헤쳐나갈 수 있도록 도와줄 경험이 풍부한 챔피언의 도움을 받아 시작하세요. 결국 가장 큰 자산은 팀원이며 팀원이 옳은 일을 하도록 교육시키세요. 옳은 일을 하기 쉽게, 그리고 잘못된 일을 하기 어렵게 만들면 결과에 기분 좋게 놀라게 될 것입니다.

우선 순위 부족

“코드 줄 작성을 멈추고 지속적 제공 파이프라인을 구축합시다!”라고 말하는 제품 소유자는 한 명도 없습니다.

제품 소유자의 입장에서 변호하자면 이들은 세상을 놀라게 하는 새로운 기능으로 경쟁에서 앞서가는 데 집중하고 있습니다. 그와 동시에 모든 스프린트 플래너에서 파이프라인이 제품 기능에 대해 가중치가 부여되고 절충되면 문제가 있다는 것을 알 수 있습니다.

일부 제품 백로그에서는 파이프라인이 있기는 하다면 맨 밑에서 간신히 매달려 있습니다. 근시안적인 리더십은 파이프라인과 관련된 업무를 팀에 도움이 될 투자가 아니라 비용이라고 분류합니다. 자신이 야기한 장기적인 피해에 대해서는 여전히 부정하며 가끔은 아무런 책임도 지지 않습니다.

파이프라인은 위생과도 같습니다. 계속 비즈니스를 유지하고 싶다면 스스로 “위생이 중요한지” 물어보세요. 분명히 중요할 것입니다!

파이프라인에는 대량의 트랜잭션 데이터가 보입니다

소프트웨어 개발 팀의 평범한 하루를 상상해 보세요. 팀은 모든 변경 사항이 자동으로 배포되도록 비즈니스 우선 순위가 지정된 기능을 커밋하고 기능에 대한 테스트를 커밋하고 배포를 지속적 제공 파이프라인과 통합합니다. 팀에서는 새 기능을 추가한 후 애플리케이션 속도가 느려졌다는 사실을 깨닫고 성능 문제에 대한 수정을 커밋합니다. 팀은 또한 애플리케이션을 테스트에서 스테이징 단계로 승격하기 전에 잘못된 응답 시간을 포착하도록 성능 테스트를 추가합니다.

각 커밋을 트랜잭션이라고 생각하세요. 소프트웨어 개발 팀은 세상을 깜짝 놀라게 하는 제품이 탄생할 때까지 이렇게 트랜잭션을 하나씩 배포합니다. 그리고 다시 반복합니다. 조직 내 모든 엔지니어링 팀에 걸쳐 이렇게 하면 대량의 트랜잭션 데이터를 마음대로 사용할 수 있습니다.

파이프라인의 트랜잭션 데이터 분석

트랜잭션 데이터를 분석하여 엄청난 양의 정보를 추출할 수 있습니까? 물론 그렇습니다!

모든 트랜잭션 데이터가 그렇듯이 양이 너무 많으면 이해할 수 없습니다. 그래서 집계하고 분석을 수행하여 조직에 대한 인사이트를 얻어야 합니다. 분석을 통해 나무 사이로 숲을 볼 수 있으며 파이프라인 분석과 인사이트를 바탕으로 관행을 개선한 세 가지 예시는 다음과 같습니다.

매주 진행되는 수백 건의 배포 중에서 애플리케이션 A의 배포 실패 건수가 애플리케이션 B의 배포 실패 건수보다 3배나 많다는 사실을 알게 되었습니다. 이 사실을 발견하여 환경 안정성과 구성 관리에 대한 애플리케이션 A의 설계 선택을 조사하게 되었습니다. 애플리케이션 B가 컨테이너화되는 동안 팀은 데이터 센터의 불안정한 가상 머신을 사용하여 배포했다는 사실을 알게 되었습니다. 변경 불가능한 인프라에 대한 투자를 우선시하고 한 달 후에 투자 대비 효과가 좋은지 확인해 봤습니다. 당연히 효과가 좋았습니다. 측정할 수 있다면 고칠 수 있습니다.

또 다른 예는 애플리케이션 B의 정적 코드 분석 오류가 지난 몇 분기 동안 꾸준히 상승 추세를 보였다는 사실을 알게 되었을 때입니다. 애플리케이션 B를 담당하는 팀이 더 나은 코드를 작성하려면 (다시) 교육을 받아야 한다는 뜻일 수도 있습니다. 또한 정적 코드 분석기가 오탐을 보고했다는 것도 발견했습니다. 즉, 코딩 위반 사항이 없는데 플래그를 지정했다는 뜻입니다. 그래서 Atlassian에서는 팀의 분석기를 잘 알려진 업계 표준 도구로 업그레이드하고 오탐을 어느 정도 줄였습니다. 코딩 워크숍을 구성하여 합리적인 정적 분석 오류에 대해 논의하고 해결했습니다. 끝날 무렵에는 팀원이 다시 콧노래를 부르고 있었습니다.

또 다른 흥미로운 사실은 애플리케이션 A의 단위 테스트가 애플리케이션 B와 C보다 코드 커버리지가 적었는데도 작년에 프로덕션 문제가 가장 적었던 것은 애플리케이션 A였다는 사실입니다. 단위 테스트를 작성하고 코드 커버리지를 측정하는 것은 괜찮지만 너무 많이 하면 팀에는 비생산적이고 고객에게는 쓸모가 없습니다. 교훈을 배운 셈입니다.

핵심 성과 지표(KPI)

조직을 올바른 방향으로 이끄는 데 있어서는 의견에 의존할 수 없습니다. 먼저 성공이 어떤 모습인지를 기반으로 KPI를 정의해야 합니다. 두 번째로는 월, 분기 및 연도에 걸친 KPI를 분석하여 데이터에 기반한 결정을 내려야 합니다.

조직 KPI와 부서별 KPI 비교

개별 부서에서 자체 성공 메트릭을 정의하는 것을 여러 번 봤습니다. 메트릭이 조직의 목표와 연결되는 한 부서 차원에서 성공이 어떤 모습인지 이해하는 것은 좋은 일입니다.

테스트, 스테이징, 프로덕션에서의 실패 비교

몇몇 조직에서는 개발자가 테스트 환경을, QA가 스테이징을, 운영 팀이 프로덕션을 소유하도록 요구합니다. 개발자는 테스트 환경에서 실행되는 단위 테스트에 대한 코드 커버리지 보고서 속에 파묻히는 대신 한 걸음 물러서서 자체 소유 여부와 관계없이 모든 환경을 전체적으로 보는 것이 중요합니다.

스테이징에서 성능 테스트로 인한 실패 비율이 높을 수 있고 그 원인은 잘못된 성능 벤치마크나 느린 코드 때문일 수 있습니다. 비교 분석에 따르면 프로덕션 환경의 통합 스모크 테스트에서 파이프라인이 가장 많이 실패하는 것으로 밝혀질 수 있으며 그러면 조사가 필요합니다. 근본 원인은 제품의 실제 버그일 수도 있고 버그가 있는 테스트 코드, 부정확한 테스트 데이터, 잘못된 테스트 구성, 제품 팀과 엔지니어링 팀 간의 오해 등일 수도 있습니다.

더 자세히 살펴보면 잘못된 테스트 구성이 만연하다는 것을 알 수 있으며 잦은 통합 실패를 해결하기 위해 이 문제를 해결하는 데 우선 순위를 둘 수 있습니다. 또한 개발자가 코드 소유권을 프로덕션까지 유지하는 것도 DevOps 패러다임에 부합합니다.

안정성 지수

KPI를 정의하고 나면 단일 KPI에 편향이 있고 특정 방향으로 크게 치우쳐 있는지 이해하는 것이 중요합니다. 그럴 경우를 대비하여 무게 중심을 중앙에 가깝게 놓는 다른 KPI와 균형을 맞춰야 합니다. 그 KPI가 바로 안정성입니다.

개발자는 하나의 기능이 프로덕션에 구현되는 데 걸리는 시간인 FeatureLeadTime으로 안정성을 측정합니다. 기능은 여러 커밋으로 구성되기 때문에 FeatureLeadTime을 더 세밀하게 측정하는 것은 체크인이 프로덕션에 적용되는 데 걸리는 시간인 CheckIn2GoLive입니다.

CheckIn2GoLive는 파이프라인이 테스트에서 스테이징, 프로덕션으로 코드를 승격시키는 데 걸리는 시간과 비슷할 수 있으므로 파이프라인을 통해 Checkin2GoLive를 측정합니다. 게다가 버그 수정은 테스트에서 스테이징, 프로덕션까지 동일한 파이프라인을 거치므로 CheckIn2GoLive는 MTTR(평균 해결 시간) 결함도 반영합니다.

흥미롭게도 운영 팀에 물었을 때 팀은 위험을 회피하도록 장려되기 때문에 속도는 부정적인 의미를 내포하는 경우가 많습니다. 실패를 반영하기 위해 눈치채지 못한 결함의 수를 측정하고 눈치채지 못한 결함이 아니라 파이프라인에서 감지된 결함의 백분율로 안정성을 정의합니다.

비즈니스는 고객 만족도나 반복 고객의 수로 안정성을 정의합니다. 주관적인 것처럼 들리지만 고객이 제기한 결함의 수나 고객 피드백 설문조사를 통해 이 메트릭의 근사치를 낼 수 있습니다.

전형적인 예는 개발, 운영, 비즈니스 각자의 관점에서 의견을 내세우는 안전성 지표지만 조직은 어느 하나에 의존하기보다는 조화를 이루는 것이 더 낫습니다. 따라서 안정성을 위한 공정한 조직적 지표를 만드세요.

코드 품질 지수

다양한 관점을 고려해야 하는 또다른 예는 코드 품질입니다. 어떤 팀원은 코드의 품질이 단위 테스트로 측정된 코드 커버리지에 반영된다고 하는 반면 다른 팀원은 코드의 품질이 순환적 복잡성이라고 말하기도 합니다. 표준 정적 분석기는 코드 중복, 보안 취약성, 잠재적 메모리 누수를 보고합니다. 모든 것은 코드 품질의 진정한 척도이며 따라서 이 모든 것과 다른 것도 역할을 하는 지표가 만들어집니다.

비즈니스 KPI와 기술 KPI 비교

조직이 주목하는 또 다른 인기 KPI는 스프린트에서 제공하는 가치입니다. 흔한 나쁜 습관은 릴리스 횟수를 기록하는 것이며 그 자체로는 가치를 더하지 못합니다. 비즈니스를 위해 눈에 띄는 성과를 내지 않고도 A 지점에서 B 지점으로 이동할 수 있으며 그것으로는 충분하지 않습니다. 어떤 조직에서는 해당 스프린트에 새로 추가된 테스트 수나 실행된 총 테스트 수를 측정하는데 그런 경우에도 비즈니스 성과가 반영되지 않고 엔지니어링 노력만 반영됩니다. 스프린트에서 제공되는 가치는 비즈니스와 관련이 있어야 합니다.

비즈니스 KPI의 예로는 지난 분기에 확보한 고객의 수와 지난 달 광고 클릭 수가 있습니다. 파이프라인은 비즈니스 메트릭에 직접적인 영향을 미치지 않습니다. 비즈니스 KPI를 기술 KPI에 매핑하려고 하는 유일한 이유는 기술적 장인 정신과 비즈니스 목표의 관계를 이해하기 위해서입니다.

파이프라인에 매핑할 때의 비즈니스 KPI로 파이프라인의 ROI(투자 대비 효과)도 계산할 수 있습니다. 리더십 팀은 이 메트릭을 사용하여 개선이 가능한 영역을 파악하고 예산을 계획합니다.

여정을 시작하세요