[번역] DevOps 로 전환 시의 ROI (The ROI of DevOps Transformation)
본 아티클은 DORA(DevOps Research and Assessment) 팀의 긴 연구 끝에 발표된 문서 The ROI of DevOps Transform 를 번역 및 각색하여 작성하였습니다
DevOps 로 전환 시의 ROI (Google Drive 에서 번역본 PDF 다운로드): 문서를 모두 읽기 힘드시다면, 프루퍼 Medium 을 구독하고 이 다음에 발행될 “DORA Metrics 에 관한 더 자세한 분석과 활용방법” 아티클을 확인해주세요!
DevOps 로 전환 시의 ROI
IT 로 가치 창출 및 혁신하기
“IT를 잘 활용하지 못하는 조직은 IT 업무를 제대로 수행하는 조직에게 뒤처지기 십상입니다.”
전통적으로 기업에서 IT 는 돈먹는 하마로 여겨져 왔기 때문에 사전에 비용과 투자대비 수익(ROI) 를 증명하길 강요받아왔습니다.
하지만, IT 업무를 제대로 수행한다면 가치를 창출하는 것 뿐만 아니라 가치 혁신까지 유도할 수 있습니다.
이렇게 혁신적이고 가치를 창출하는 IT의 힘을 잘 활용하지 못하는 조직은 IT 업무를 제대로 수행하는 조직에게 뒤처지기 십상입니다.
IT 업무를 제대로 수행하기 위해서 지금까지 우리에게 없었던 것은 바로 DevOps 전환에 대한 가치를 예측하고 투자를 정당화할 수 있는 분석 데이터 기반의 프레임워크입니다.
이 아티클은 지금까지 IT 업무를 제대로 수행하지 못하던 조직들이 앞으로 뒤처지지 않는데에 도움이 됩니다. 당연히 제시된 방법론을 적용하면 모든것이 바로 해결되는 것은 아니겠지만, 해결을 위한 매우 중요한 고려 사항들을 찾을 수 있게될 것입니다¹
Accelerate: State of DevOps Report²에서 서술된 DORA Metrics의 주요 지표와 업계 평균을 사용하여 엘리트, 높음, 중간, 낮은 IT 성과 조직으로 분류하고 각 초기성과 정도에 따라 DevOps 전환을 했을 때 얻을 수 있을 가치를 예측합니다. 또한 생산성을 계산하고/역량을 강화하고/종합적인 퍼포먼스를 개선하는 활동 등을 진행했을 때에 얻을 수 있는 잠재적인 ROI 를 DORA Metrics 의 지표를 사용하여 추정하는 방법을 알려 줍니다.
지표를 통해 알 수 있는 정보는 조직 내에서 기술 혁신을 추진하는 데 도움을 주는 CTO, 임원 및 재무 담당자들에게 특히 적합합니다. 자체적인 수치 데이터와 제공된 업계 벤치마크 데이터를 활용하여 지불되는 비용과 그로 인해 얻을 수익을 정량화함으로써 DevOps 에 투자하는 형태로 조직의 기술 혁신을 수행하고 결과적으로 강력한 비즈니스를 만들 수 있게 됩니다.
이 아티클은 또한 조직의 IT 를 지속적으로 개선하고 발전하면서 얻을 수 있는 이점에 대한 통찰력을 제공합니다.
이 아티클을 읽고 있는 분의 조직이 분류기준 상 낮은 성과조직, 중간 또는 높은 성과조직이라면 엘리트 성과조직이 설정 해놓은 기준을 참고하고 이 순간에도 IT 업계가 매년 발전하고 있음 을 인지해야 합니다. 지금부터라도 개선하지 않으면 계속 뒤처지게 될 것입니다.
만약 엘리트 성과조직이라면 다른 엘리트 성과조직들과 비교하여 지속적으로 개선하고 그 기준을 높이기 위해 노력하세요. DORA 팀이 보고한 자료에서 중간 성과조직을 기준으로 업계는 계속해서 개선되고 발전하고 있습니다. 특히 엘리트 성과조직들은 그 변화폭이 더 큽니다.³
소프트웨어 개발 속도 및 안정성 기준 조직분류
- 엘리트 성과조직
탁월한 퀄리티의 서비스 제공을 통해 최고의 성과를 실현하고 최고 수준의 소프트웨어를 제공합니다. 이들은 업무시간 대부분을 가치 있는 시간으로 만들었고, 모든 조직분류 중에서 가치가 없는 작업에 가장 적은 시간을 소비합니다. - 높은 성과조직
중간 성과조직보다 통계적으로 더 우수하지만 여전히 개선의 여지가 있습니다. 처리량과 안정성의 여러 측면에서 우수하지만 아직 충분하지 않습니다. 지금의 우수함을 최대한 활용하려면 처리량과 안정성의 측면을 지속적으로 개선해야 합니다. - 중간 성과조직
기술 부채를 줄이고 비용보다는 속도와 가치 창출에 집중하여 최대한의 이익을 얻으세요. 안정성 측면에서는 우수하지만 속도 측면에서는 높은 성과조직에 뒤처집니다. - 낮은 성과조직
쉽게 달성할 수 있는 성과를 가장 먼저 해결하고 측정 가능한 목표를 설정하여 개선할 수 있는 기회들을 최대한 확보하세요.
IT 와 조직의 성과
DORA 팀과 작성한 State of DevOps Reports 는 DevOps 분야에 중요한 정도에 따라 소프트웨어 개발 및 제공 팀의 기술 패턴을 분류합니다. 여기에는 개발 속도(또는 처리량) 및 운영 안정성이 포함됩니다. 우리는 코드 배포 빈도와 코드 배포에 걸리는 시간을 측정하여 속도를 정의했습니다. 또한 MTTR(Mean time to repair, 평균 복원 시간)과 변경 시 실패율(예: 코드 또는 인프라 변경 사항을 롤백하거나 핫픽스해야 하는 빈도)을 측정하여 운영 안정성을 파악했습니다.
위 항목들은 아래과 같은 이유들에 따라 선택되었습니다.
개발 속도를 측정하는 것은 개발자가 개발을 잘하기 위한 목표설정과 고객에게 기능을 제공하기 위해 빠르게 움직이는 것의 중요성을 강조하는 데 도움이 됩니다.
마찬가지로 운영 안정성을 측정하는 것은 IT 운영의 목표를 잘 설정하고 안정적인 코드의 중요성과 일정 구간의 인프라 필요성을 포착하는 데 도움이 됩니다.
두 접근 방식을 모두 사용할 때의 이점은 이러한 측정 값들이 서로 경합하여 팀이 “gaming” the metrics (역주: 측정치를 올리는것에만 치중하거나 임의로 조작함)하는 것을 방지하고 소프트웨어 개발 및 제공에 대한 팀의 전반적인 능력에 대한 통찰이 가능하도록 하는 관점을 제공한다는 것입니다.
각각의 조직은 분석에 따른 측정 값을 기준으로 별개의 그룹인 엘리트, 높음, 중간, 낮은 성과 조직 으로 분류됩니다. (자세한 내용은 2019 State of DevOps Reports 에서 확인할 수 있지만, 기본적인 정보는 표 1 에 요약되어 있습니다) 엘리트 성과 조직은 트레이드 오프 없이 처리량과 안정성 측면에서 가장 높은 성과를 보여 소프트웨어 개발 및 제공에서 곧바로 탁월한 퍼포먼스를 보여줍니다. 즉 이들은 이미 처리량과 안정성을 동시에 향상시킬 수 있는 원칙과 관행을 적용하고 있다는 뜻 입니다.
퍼포먼스 측정에 대한 중요한 참고 사항: 이 아티클을 보는 조직은 각자 서로 다른 길을 걷고 있습니다. 심지어 실제로 한 기업 내에서도 각각의 조직이 서로 다른 퍼포먼스 측정 기준을 가지는 경우도 있습니다.
자신의 조직이 지금 어느 성과조직에 속해 있는지를 먼저 파악함으로써 지속적인 개선을 위한 여정에서 현재 어느 단계에 있는지 확인하고 자신의 조직에 특화 된 목표를 설정할 수 있습니다.
만약 이 ROI 에 관한 내용을 자신의 조직 내에서 쉽게 사용할 수 없는 경우 업계 표준의 퍼포먼스 기준을 벤치마크할 수 있습니다. 예를 들어, 이 아티클 뒷 부분에서 다루게 될 불필요한 작업에 대한 측정기준이 있습니다. 그러나 우리는 이렇게 측정된 결과가 우리 조직과 큰 차이가 있을 수 있다는 점을 지적합니다. 따라서 조직이 자체 기준을 마련할 것을 강력히 권장합니다.
표 1.
2019 Accelerate: State of DevOps Report 의 통계
2019 State of DevOps Reports 외에도 IT 및 조직 성과에 대한 추가 정보와 지침, 개선 작업에 중요한 기술, 관리, 문화적 관행이 포함된 2017년 및 2018년 State of DevOps Reports 를 참조할 것을 독자에게 강력히 권장합니다.
(b) 버전에 변경 사항이 적용되는 시점이 프로세스를 여러 부분으로 나누는 구분점으로 봅니다. 여기에서는 코드 커밋에서 코드 배포까지의 시점을 기준으로 합니다. 작업의 첫 번째 단계에는 디자인과 개발이 포함되며 린 제품 개발(Lean Product Development)과 유사합니다. 이는 매우 가변적이고 불확실하며, 다시는 수행할 수 없는 창의성과 작업이 필요한 경우가 많아 프로세스 시간이 매우 가변적입니다. 이와 대조적으로 테스트 및 운영을 포함하는 작업의 두 번째 단계는 린 제조(Lean Manufacturing)와 유사합니다. 여기에도 창의성과 전문 지식이 필요하지만, 변동성을 최소화한 작업 결과(예: 짧고 예측 가능한 리드 타임, 거의 제로에 가까운 결함)를 목표로 테스트와 운영이 예측 가능하고 빠르며 기계적이어야 합니다.
분포가 정규적이지 않기 때문에 중앙값이 보고되었습니다.
모든 차이점은 달리 명시되지 않는 한 투키 테스트에 따라 크게 다릅니다.
(c,d,e) 투키 테스트에 따르면 크게 다를 수 있습니다. 중앙값은 기본 분포로 인해 차이를 나타내지 않습니다.
(f) 투키 테스트에 따르면 크게 다르지 않습니다.
엘리트 성과조직: 통계적으로 유의미한 수준에서 네 가지 지표 모두에서 우수했습니다. 그들은 코드를 가장 자주 그리고 가장 빠른 주기로 배포했으며, 오류가 발생했을 때 MTTR이 가장 짧았고, MTTR도 1시간 미만으로 가장 낮았습니다.
높은 성과조직: 대부분의 경쟁조직보다 더 나은 성능을 발휘합니다. 그들은 매우 빠르게 코드를 배포하고 오류를 수정하고 있지만 엘리트 성과조직에 비해서는 계속해서 개선해야 합니다.
중간 성과조직: 성과가 낮은조직은 지속적으로 발전하고 성과가 높은조직은 업계의 복잡성 증가에 굴복하기 때문에 분류 중 가장 큰 비율을 차지합니다. 중간 성과조직은 처리량 측면에서 지속적으로 개선되어야 하지만 안정성 측면에서는 좋은 성과를 거두고 있습니다.
낮은 성과조직: 통계적으로 유의미한 수준에서 4개 측정값 중 3개 측정값이 낮았습니다. 코드 배포 빈도가 가장 낮았고 릴리스하는 데 가장 오랜 시간이 걸렸습니다. 이들은 평균적으로 가장 긴 MTTR을 가집니다. 성과가 낮은조직일 경우 개선을 통해 재정적으로 가장 큰 이득을 얻을 수 있습니다.
무엇이 ROI 를 만들어 낼까?
시장에서 승리하기 위해 기술을 사용하는 선구적인 조직들은 비용보다 가치에 초점을 맞춥니다.
조직리더와 기술리더는 지속적인 개선이 가능할지에 초점을 맞춰 계획을 수행할지에 대한 여부를 평가할 때 종종 투자 수익(ROI)에 대해 질문합니다. 이 평가에는 두 가지 종류의 결정이 필요합니다.
- 투자: 기술, 프로세스, 교육 및 문화 개선에 얼마나 많은 돈과 자원(달러 금액으로 환산)을 투자할 것인가?
- 수익: 투자를 했을 때 얼마나 많은 돈과 자원을 기대하는가?
이 아티클 에서는 ROI의 수익 측면을 계산하는 데 중점을 두고 있지만 획득하는 기술 이상의 비용도 포함해야 한다는 점을 기억하세요.
투자 계산에 중요한 고려 사항에는 교육, 새로운 기술이나 작업 방식 학습 및 통합 과정에서의 생산성 손실, 장기적인 유지 관리 비용, 기존 시스템을 재설계하고 교체하는 데 소요되는 시간 손실 등이 포함됩니다. 이러한 투자에 포함되는 비용은 팀과 조직, 그리고 여정의 어느 단계에 있는지에 따라 달라집니다.
수익을 계산할 때 조직에서는 항상 고려해야 할 두 가지 분류가 있습니다. 첫 번째는 가치 중심의 분류입니다. 두 번째는 비용 중심의 분류입니다.
가치 중심의 접근
엘리트 성과를 내는 조직은 시장의 변화에 대한 요구에 대한 강한 이해와 이러한 요구(예: 고객 요구, 새로운 기술의 가용성과 경쟁사의 압력을 빠르고 안정적으로, 그리고 기술 팀의 큰 노력 없이도 인지할 수 있습니다. 비전이 있는 기술리더는 이를 이해하고 비용보다 특히 속도를 최적화하고 있습니다. 이는 사고방식에 상당한 변화가 필요합니다(DevOps 리더인 Courtney Kissler⁴가 인용한 전략).
가치 손실의 단편적인 예로 현재 부가가치를 만들어내지 못하는 작업(예: 불필요한 재작업 및 수동 테스트)에 지출하는 시간과 비용이 있지만 여기에 더해 부가가치를 만드는 작업(예: 새로운 기능 또는 추가 자동화 테스트)에 지출할 수 있는 기회 비용 또는 리소스까지 포함될 수 있습니다.
새로운 제품이나 기능출시를 연기함으로써 손실되는 가치도 주요 관심사이지만 이를 추정하기 어렵기 때문에 조직들은 이것을 종종 무시하게 됩니다. 이렇게 손실된 가치에는 조직이 얻지 못했지만 소프트웨어를 더 빨리 출시했다면 얻을 수 있었던 수익과 고객이 포함되어있었을 수 있습니다. 이는 기회 비용 또는 지연 비용, 즉 적시에 기능을 출시하지 않아 발생하는 비용으로 생각할 수 있습니다.
가치를 더 신속하게 발견하고 고객에게 제공하거나 윗선에 보고하는 능력은 린/애자일 패러다임의 주요 이점이며, 매년 분기별로 측정되는 데이터에서 지속적으로 높은 관련성을 보여주는 진정한 경쟁 우위입니다. 게다가 추정하기 어렵다고 해서 할 수 없다는 뜻은 아닙니다. 이 아티클에 서술된 계산식을 활용한다면 투자 수익을 계산하는 데 그렇게까지 높은 수준의 정밀도가 필요하지 않으며 더하여 이 숫자들에 대한 유용한 인사이트들도 얻어낼 수 있습니다.
2008년에 AOL은 프로덕션 배포에 점점 더 길어지는 설치시간으로 인해 어려움을 겪고 있었습니다. Gene Kim은 당시 AOL의 글로벌 엔지니어링 부문 수석 부사장이었던 Eric Passmore와 함께 일하고 있었습니다. Gene은 이 프로젝트에 대해 이렇게 말합니다. “운영팀이 Linux 커널을 2.4에서 2.6으로 업데이트하는 데 몇 달(!)이 걸렸고, 개발팀에서는 2.6 커널이 제공하는 멀티스레딩 지원이 필요했습니다. 회사 입장에서는 멀티스레딩 지원이 없다는 것이 코드 동결의 원인이었고 이는 회사를 약화시키는 일이었습니다. 즉, 개발팀은 새로운 소프트웨어 기능을 완성했지만 Ops가 커널 업그레이드를 완료할 때까지 고객은 이를 사용하거나 가치를 얻을 수 없습니다.”
Gene과 Eric은 이것이 Dev 또는 Ops 문제 그 이상이라는 것을 깨달았습니다. 고객에게 소프트웨어 기능을 제공하는 데 지연이 있는 것은 비즈니스 문제였습니다. 이는 사업상 손실된 실제 돈으로 증명되었습니다.
소프트웨어 개발 및 제공 프로세스를 개선함으로써 Eric과 그의 팀은 배포 시간을 6시간에서 45분으로 단축하고 프로세스의 병목 현상을 제거하여 AOL이 고객에게 기능과 가치를 더 빠르게 제공할 수 있었습니다.⁵
비용 중심의 접근
비용 중심 접근 방식에서는 DevOps 구현을 통해 실현되는 비용 절감 및 업무 효율성에 중점을 둡니다. 예를 들어 기술 구현을 통한 시간 절약, 수동 프로세스 자동화를 통한 실제 업무 시간 및 비용 절감 등이 있습니다. 시간 및 효율성과 같은 비용 절감은 눈으로 확인하기 쉽고 IT 에 대한 투자 대비 수익을 계산할 때 사용되는 유일한 범주인 경우가 많습니다. 여기에는 다운타임 시간 당 비용, 수동 작업과 자동화 작업 비용이 포함될 수 있습니다. 이러한 비용 절감은 린(Lean) 방식을 채택하고 지속적으로 작업을 개선하여 낭비 원인 제거 및 불필요한 재작업 제거 등으로 프로세스를 효율화 시켜 달성할 수 있습니다. 린한 사고방식은 향상된 경제성과 ROI 주장을 위한 강력한 기반입니다.
그러나 이러한 비용만을 고려하는 방향은 충분하지 않으며 체계적이고 장기적인 이익은 거의 얻지 못합니다. 조직이 개선된 비용 및 성과의 새로운 기준에 적응함에 따라 첫 1년차에 실현된 효율성은 2년차 이후에는 더 이상 계산할 수 없습니다.
더 나쁜 것은, 비용 절감에만 초점을 맞추었을 때 직원이 고된 업무에서 해방되기보다는 자신이 맡고있는 업무가 자동화되어 자신을 대체함으로써 비즈니스 성장을 촉진할 것이라고 오해하여 직원의 사기와 생산성에 추가적인 부정적인 영향을 미친다는 것입니다.
가치와 비용으로 수익을 계산해보기
기존 인재를 조직에 유지시키고 지속해서 교육하는 것은 조직 차원에서 비용 효율적이고, 조직의 내부 지식으로 보존되며, 스스로 참여하고 지속적으로 학습하는 강력한 기술 인력을 보유함으로써 조직에 장기적인 이점을 제공합니다.
기업이 회피하는 모든 비용은 기업에 대한 수익으로 간주된다는 점을 염두에 두고, ROI 가 가치와 비용 절감 측면에서 어떻게 분석되는지 살펴보겠습니다. 우리는 이러한 ROI 계산에 보수적인 추정치를 사용했습니다. 조직의 숫자는 조직의 특정 상황에 따라 더 높거나 낮을 수 있습니다. 우리는 조직이 스스로의 데이터를 사용하여 수익을 계산할 수 있도록 수치가 아닌 계산 방법을 제시합니다. 또한 조직이 보유하고 있지 않은 수치를 입력하는 데 도움이 되는 업계 벤치마크 및 추정치를 제공합니다.
핵심 아이디어: 비용과 수익의 모든 변화는 기준이 되는 시작 시점의 예산과 비교되기 때문에 이후에 기업이 회피하는 비용은 모두 수익으로 간주됩니다.
예를 들어, 기본 예산이 해당 연도 IT 지출 비용으로 1억 달러를 차지했지만 지표를 활용한 성과개선을 통해 IT 지출이 8,000만 달러로 줄어든 경우 추가로 2,000만 달러를 사용할 수 있게 됩니다. 따라서 이 추가 2천만 달러는 사업에 대한 수익입니다.
가치 계산
당장 실현할 수 있는 비용을 절감하는 방향 및 효율성 외에도 고객과 비즈니스에 제공할 수 있는 가치에 주목하여 기술 혁신을 이뤄내는 조직을 최고로 칩니다. 그러나 많은 기업에서는 단순히 비용 절감에만 초점을 맞추고 있습니다. 그 이유는 비용 절감이라는 개념이 일반적으로 잘 이해되고 일반적으로 기술 투자대비 수익을 손쉽게 계산하는 데 사용 되기 때문입니다.
비용 절감에 초점을 맞추는 것은 첫 단계로 좋을 수 있지만 그것만으로는 충분하지 않습니다. 비용 절감은 도입 초기에는 좋은 영향을 미칠 수 있지만 향후에는 그 효과의 폭이 감소할 수 있습니다.
또한, 비용이 절감되는 것 그 자체를 가치 있는 것으로 간주하는 것은 근시안적인 결정입니다. 시장에서 승리하기 위해 기술을 사용하는 선구적인 조직들은 비용보다 가치에 초점을 맞춥니다. 그들은 이러한 비용 절감으로 얻은 수익을 재 투자하여 새로운 고객을 발견하고 기존 고객에게 제공하는 가치를 높입니다. 비용 절감을 통해 얻은 우수한 소프트웨어를 개발하고 제공하는 능력을 활용하여 더 가치 있는 새로운 서비스와 기능을 지속적으로 제공하여 고객, 직원 및 투자자를 만족시킬 수 있습니다.
“만연한 혁신 문화를 정착시켜 세금부과 시즌 3개월 동안 165번의 실험을 진행했습니다. 우리의 사업 성과는? 고객 확보 퍼널에서 전환율이 50% 증가했습니다. 직원들의 평가? 새로운 아이디어가 시장에 출시될 수 있기 때문에 당연히 모두가 좋아했습니다.”
— Scott Cook, Intuit 의 창립자⁶
우리는 수익 계산에 두 가지 유형의 가치를 포함합니다.
첫 번째는 비효율적인 업무를 줄여서 얻는 가치입니다. 이러한 개선 작업은 지속적으로 낭비를 줄이고 효율성을 높이는 팀의 이니셔티브에서 비롯됩니다. 많은 조직에서는 이러한 유형의 개선 작업을 비용 절감으로 분류하지만 우리는 이를 가치 계산으로 간주합니다.
수익 계산에 포함되는 두 번째 유형의 가치는 새로운 개발 작업에서 얻은 비즈니스 수익에 기여하는 가치입니다. 이에 대해서는 아래에서 자세히 설명합니다.
불필요한 재작업을 하지 않음으로써 얻는 연간가치
매년 불필요한 재작업에 소비되고 손실되는 시간과 비용은 생산성과 전반적인 기술 경제에 큰 타격을 줍니다⁷. 그럼에도 불구하고 많은 조직에서는 이 비용을 간과하고 있습니다. 절감된 모든 비용은 비즈니스에 대한 수익을 의미하며 이것만으로도 상당한 가치를 창출할 수 있습니다.
불필요한 재작업은 업무 프로세스 개선을 통해 피할 수 있는 작업이기 때문에 일부 조직에서는 효율성 향상을 단순히 비용 절감으로만 계산합니다. 그러나 이러한 계산법은 비용을 완전하게 제거하는 경우에만 성립된다는 점을 지적합니다. 즉, 누적된 시간 절약만큼 인건비도 절약해야 완전한 절감인 셈입니다. 그러나 우리는 조직이 이 전략을 채택하지 않을 것을 강력히 권장합니다. 이는 직원들의 사기와 조직 문화에 부정적인 영향을 미치고 업무 효율성을 감소시킬 수 있으며 심지어 직원이 일부러 작업 프로세스를 개선하지 않도록 유도할 수도 있습니다.
조직은 절감된 비용을 회수하여 비즈니스에 재 투자하여 본질적으로 낭비되던 인력을 되돌려받을 수 있습니다. 기존 인재를 조직에 유지시키고 지속해서 교육하는 것은 조직 차원에서 비용 효율적이고, 조직의 내부 지식으로 보존되며, 스스로 참여하고 지속적으로 학습하는 강력한 기술 인력을 보유함으로써 조직에 장기적인 이점을 제공합니다.
기존 인력을 조직에 유지하고 비효율성을 줄여 확보한 시간을 재활용함으로써 조직은 가치를 얻습니다. 따라서 조직은 이를 불필요한 재작업을 방지하여 얻은 가치로 분류하여 매년 누적시켜야 합니다. 프로세스를 개선하고 효율성을 높이기 위해 취하는 정확한 단계는 각 조직, 심지어 각 팀마다 다르지만, 린 사고와 지속적인 개선을 사용하면 낭비를 줄이고 더욱 효율적인 조직이 될 수 있습니다.
“처음에우리는 우리 상품의 가격을 계속해서 낮추는 전략을 취해 시장을 장악했고 이제는 우리 상품이 필수품이 되었습니다. 앞으로 사업에서 성공하려면 고객과의 관계에 이전과는 다른 가치를 더하는 방향으로 나아가야 했습니다.”
- Charles Schwab⁸
핵심 아이디어: 비효율성을 줄여 추가로 확보할 수 있는 노동 시간의 가치를 인지합니다.
조직은 본질적으로 인력을 채용하거나 채용할 필요 없이 추가적인 리소스를 확보하게됩니다.
또한 우리의 연구에 따르면 프로세스 개선을 통해 DevOps 관행을 개선하면 직원 만족도가 높아지고 성과가 뛰어난 팀의 직원이 자신의 조직을 일하기 좋은 곳으로 추천할 가능성이 2.2배 더 높은 것으로 나타났습니다. 이는 현재 기술자에 대한 경쟁이 치열하고 이직 비용이 인재 유지 비용을 훨씬 능가하는 시대에 큰 성과를 얻어낼 수 있습니다.
Center for American Progress의 연구에 따르면 일반적인 이직 비용은 직원 연봉의 21%인 것으로 나타났습니다. https://www.americanprogress.org/wp-content/uploads/2012/11/CostofTurnover.pdf
연간 불필요한 재작업을 방지함으로써 얻은 가치를 계산하기 위해 다음 계산식을 사용합니다.
기술 인력 규모
불필요한 재작업은 개발, QA, 테스트부터 운영에 이르기까지 가치 사슬을 따라 모든 사람에게 영향을 미치기 때문에 조직은 보유하고 있는 ‘기술인력’의 총 인원수를 포함해야 합니다. 설명을 위해 다양한 규모의 조직에 대해 다음 그룹을 사용합니다.
- 대기업: 주요 사업이 주로 인하우스 소프트웨어 개발에 의존하고 있는 경우 기술 직원 수는 8,500명으로 추산됩니다.
- 중견 기술기업: 기술 직원 수는 2,000명으로 추산됩니다.
- 중소기업 및 비-기술 기업: 우리는 기술 직원을 250명으로 추산합니다.
물론 조직의 재작업 방지비용이 아닌 불필요한 재작업 비용을 계산할 때는 회사의 소프트웨어 개발 및 제공에 참여하는 기술 직원만을 포함해야 합니다.
평균 임금
Glassdoor의 2019년 보고서에 따르면 DevOps 전문가의 전체 평균 급여는 14.3만 달러입니다. 이 숫자는 팀 규모가 클수록 증가하고 지리적 위치와 생활비에 따라 달라지지만 아티클에서의 계산에는 이 숫자를 사용합니다. 자신의 목적에 따라 계산을 수행할 때는 조직의 기술 직원에게 적합한 일반적인 급여를 사용하십시오.
복지혜택 승수
보험, 휴가, 퇴직 등 직원 복리후생에는 기본급 이상의 비용이 듭니다. 급여 비용의 30% ~ 110% 범위의 혜택 승수(1.3~2.1의 혜택 승수)를 확인했지만 계산에는 보수적인 1.5 승수를 사용합니다.
불필요한 재작업에 소요된 시간 비율
본 연구를 위해 2018년 DevOps 주 설문 응답자가 보고한 불필요한 재작업에 소요된 시간의 평균 비율을 참조합니다. 이 수치는 비효율적인 작업을 통해 본질적으로 낭비되는 노동시간인 비-부가가치 작업에 소요된 시간을 나타냅니다.
물론 불필요한 재작업을 모두 제거할 수 있는 것은 아니지만 팀은 먼저 이것을 지속적으로 개선하기 위한 이니셔티브를 설정해야 합니다. 저희는 두 가지 출처를 기반으로 18%의 목표를 제안합니다.
첫째, 최종 배포 이전에 코드의 19%에서 40% 사이가 재작업된다는 연구 보고서¹⁰입니다.
둘째, 2018년 Accelerate: State of DevOps Report에서 자체 연구에 따르면 엘리트 성과조직은 19%의 불필요한 재작업을 보고합니다. 따라서 불필요한 재작업을 18%로 줄이는 것은 연구된 최고의 성능과 일치하는 목표로 보고 있습니다.
엘리트 성과조직의 경우 보고된 불필요한 재작업의 양은 19%입니다. 엘리트 성과조직은 업계의 우수성을 대변하지만 언제나 개선의 여지는 있습니다. 우리는 계획되지 않은 작업 1%를 개선하여 보고된 19%에서 18%로 줄이는 것을 목표로 합니다. 그들은 모든 지표에서 최고의 성능을 발휘하지만 중단, 오류 및 코드 버그에 대한 반응으로 인해 여전히 계획되지 않은 유동적인 작업이 있습니다. 엘리트 성과조직들은 하루 중 가장 많은 가치를 창출하는 시간을 가지며 모든 그룹 중에서 가치가 없는 작업에 가장 적은 시간을 소비합니다.
높은 성과조직의 경우 보고된 불필요한 재작업의 양은 19.5%입니다. 우리는 높은 성과조직이 여전히 업무를 개선해야 하며 엘리트의 반열에 오르기 위해 지속적으로 노력해야 한다고 믿기 때문에 보고된 재작업과 목표 간의 1.5% 차이를 계산에 사용합니다. 그러나 성숙한 프로젝트 유지 관리 업무와 같은 보다 정적인 프로젝트를 수행하는 팀은 불필요한 재작업에 대해 보다 공격적인 목표를 설정할 수 있습니다. 계획되지 않은 작업을 수행해야 하는 경우가 항상 있지만, 오류를 조기에 포착하고 빠른 피드백 루프를 확보한다면 불필요한 재작업을 최소화하는 데 도움이 됩니다. 여기서 좋은 소식은, 오류를 조기에 포착함으로써 이 높은 성과조직은 중간 및 저성과조직에 비해 새 작업에 약 10% 더 많은 시간을 사용할 수 있으며, 새 작업에 약 50%의 시간을 소비할 수 있다고 합니다.
중간 성과조직의 경우 업계에서 보고한 계획되지 않은 재작업의 양은 20%입니다. 동일하게 18% 목표를 설정하면 2%를 개선하고자 합니다. 중간 성과조직은 엘리트 또는 높은 성과조직처럼 많은 결함을 조기에 발견할 수 있는 자동화된 테스트 및 기타 메커니즘 수준이 없을 수 있으므로 불필요한 재작업에 더 많은 시간을 소비합니다. 이는 중간 성과조직이 기술 부채를 청산하기 위해 구현해야 하는 시간 소모적인 작업에 영향을 미칠 가능성이 높습니다. 그래도 중간 성과조직은 더 자주 배포하려 노력하고 파이프라인을 통해 코드를 빠르게 통합하며 과업을 낮은 성과조직보다 더 안정적으로 수행하고 있습니다.
낮은 성과조직의 경우에도 업계에서 보고한 불필요한 재작업의 양은 20%입니다. 중간 성과조직과 동일하게 2% 개선을 목표로 할 수 있습니다. 다만 낮은 성과조직은 불필요한 재작업을 포함한 추정치 모두에서 미성숙하고 신뢰할 수 없는 측정 방법을 사용할 가능성이 가장 높기 때문에 불필요한 재작업에 얼마나 많은 시간을 소비하는지에 대한 가시성이 떨어질 수 있습니다. 따라서 연구팀은 낮은 성과조직은 스스로 자신들이 얼마나 많은 시간을 낭비하고 있는지를 제대로 측정하지 못하기 때문에 이 추정치가 낮을 수 있다고 말합니다. 직접 측정된 수치에 따르면 낮은 성과조직은 대부분의 시간을 불필요하고 계획되지 않은 작업에 소비하며, 새로운 작업에 소요되는 시간은 약 30% 뿐에 불과합니다. 이중에서도 가장 성과가 낮은조직은 진행 중인 작업의 총량에 압도되어 계획되지 않은 유동적인 작업을 컨트롤하는 데 신경을 쓰지 않을 수 있습니다. 심지어 어떤 대가를 치르더라도 새로운 코드를 출시하는 것을 더 선호할 수도 있습니다. 비즈니스가 시장에서 전략적 위치를 확보하기 위해 새로운 차별점과 기능 배포에 우선순위를 두는 경우가 종종 있지만 이 전략은 지속 가능하지 않습니다. 새로운 작업을 수행하고 새로운 기능을 제공하는 것은 좋지만 결함을 무시하고 불필요한 재작업을 하는 것은 장기적으로 볼 때 손실이 되는 전략입니다. 기술 부채가 늘어나 기존 시스템 유지 비용이 증가하고 새로운 기능 제공 속도가 느려집니다. 낮은 성과조직에서 엘리트 성과조직으로의 여정에는 과거에 쌓인 기술 부채를 만회하고 자주 결함이 일어나는 지점을 조기에 발견할 수 있기까지 도달하는 데 많은 노력이 필요합니다.
Greger Wikstrand의 글에서 시간이 지남에 따라 기술 부채가 어떻게 늘어나고 처리량이 감소하는지 설명합니다. http://www.gregerwikstrand.com/technical-debt-reduction/
2019년 Accelerate: State of DevOps report 에 따르면 다음과 같습니다:
엘리트 성과조직: 이 분류에 속하는 조직은 7%에서 20%로 거의 3배나 증가했습니다. 이는 높은 성과조직이 아직도 충분히 개선할 여지가 있다는 것을 보여줍니다. 실행만 하면 됩니다.
높은 성과조직: 엘리트 성과조직과 비슷하게 해마다 성장해 왔으며 뛰어난 가용성을 보고하고 있습니다. 이는 소프트웨어 제공 퍼포먼스 수치와 상당한 상관관계가 있습니다.
중간 성과조직: 안정성 측면에서 높은 성과조직과 동등한 수준이지만 소프트웨어 제공 속도는 상대적으로 느립니다.
낮은 성과조직: 통계적으로 유의미한 수준에서 네 가지 지표 모두에서 낮았습니다. 그중에서도 코드 배포 빈도가 가장 낮았고 배포하는 데 가장 오랜 시간이 걸렸습니다. 이들은 평균적으로 가장 긴 MTTR을 보고하지만 재미있게도 중간 성과 조직보다 낮은 변경 실패율을 보고합니다.
위에 제공된 계산식을 사용하면 연간 불필요한 재작업 비용에 대해 다음과 같은 추정치가 제공됩니다:
표 2.
불필요한 재작업 비용 방지로 얻는 연간 수익
낮은 성과조직은 불필요한 재작업으로 인한 연간 비용이 개선비용보다 더 낮다고 생각하지만 이로 인해 기술 부채가 누적될 가능성이 높습니다. 이 전략은 시간이 갈 수록 문제를 일으킬 것입니다. 또한 중간 및 낮은 성과조직은 높은 성과조직 및 엘리트 성과조직에 비해 소프트웨어 개발 및 제공 환경에서 더 큰 예측 불가능성을 갖고 있어 서비스 운영에 불확실성이 발생합니다. 이러한 불확실성을 관리하여 예상할 수 없는 훨씬 더 큰 간접비 지출과 불필요한 Downstream rework(역주: 제조 및 생산 과정에서 사용되는 용어입니다. 이 용어는 특정 제품이나 부품이 초기 제조 단계를 거친 후 발견된 결함이나 문제를 수정하기 위해 추가적인 작업이 필요한 상황을 지칭합니다. 여기서 “downstream”은 제조 과정의 후반부를 의미하며, “rework”는 이미 제조된 제품이나 부품을 수정, 보정, 혹은 재가공하는 작업을 말합니다.) 를 방지하세요.
제품의 품질 향상 측면에서 지속적인 개선을 진행하면 불필요한 재작업과 관련 비용이 줄어듭니다. 이는 낭비비용 절감 전략이자 지속적인 전달(continuous delivery)을 도입하는 핵심 목표입니다. 이러한 비용을 방지한다면 비즈니스에 상당한 수익을 가져다줄 수 있다는 점에 유의하세요. 이러한 비용 절감은 표 2 에 표시된 계산에서 수익으로 분류됩니다. 조직은 인원 감축을 통해 이러한 비용을 실현하도록 선택할 수 있지만 이 전략을 채택하면 직원들의 사기에 부정적인 영향을 미치게 되기 때문에 얻어낸 이익을 가치 창출에 활용할 수 없습니다. 물론 제품 및 기술 환경에 기여하고 혁신을 이뤄낸 사람들은 이미 해당 분야의 전문가가 되어 감축할 필요가 없기도 합니다.
테스트, 인프라, 워크플로, 규정 준수 등 여러 이니셔티브에 걸쳐 자동화 노력을 통해 복구된 시간의 비율을 사용하여 자동화 등 다른 개선 이니셔티브에 대해서도 유사하게 비즈니스의 가치 계산을 수행할 수 있습니다. 자동화 개선 목표를 통해 얻을 수 있는 절감 효과와 가치에 대한 정확한 추정치가 아직 없기 때문에 분석에는 이러한 계산을 포함하지 않지만, 해당 분야에 적용할 때에는 자체 계산식을 만들어 포함해야 합니다.
새로운 기능에 대한 재투자로 인한 잠재적인 가치획득
예측하기는 어렵지만 기술 투자로 인한 비용 절감 및 효율성 수익을 계산할 때 매출 손실을 고려하는 것이 중요합니다.
손실을 고려한다면 해마다 조직의 서비스와 포트폴리오에 지속적으로 가치를 추가하고 경쟁사보다 앞서 나갈 수 있습니다. 최고의 조직은 이를 이해하고 ROI 계산에 기술 혁신의 가치를 포함합니다. 그러나 이 개념은 추정하고 전달하기가 까다롭기 때문에 우리는 여기서 고객에게 기능을 제공함으로써 실현되는 지속적인 가치를 대신 사용합니다. 또한 고객가치 제공을 통해 수익을 창출할 수 있는 여건을 조성하거나 원하는 비즈니스 가치를 창출하고자하고, 이를 정량화하는 데 도움이 되는 프레임워크를 제공합니다.
고객에게 새로운 기능을 제공하면 수익이 발생하지만 모든 기능이 성공하는 것은 아닙니다. 잘 설계되고 잘 연구된 성숙한 서비스의 기능 중 약 1/3만이 조직에 최고의 가치를 제공합니다. 신제품과 비즈니스 모델의 경우 통계가 상당히 나쁩니다¹¹. 따라서 Amazon과 같은 성과가 높은 조직은 자주 배포할 수 있는 환경을 활용하여 프로덕션 환경에서 바로 실험을 하고 있습니다. 가치를 제공하지 않는 기능들을 구축하고 유지하는 것을 사전에 피하기 위해 이렇게 합니다. 우리는 비즈니스의 현재 수익을 기준으로 새로운 기능의 수익 잠재력을 기반으로 계산합니다. 이러한 수익 잠재력은 기술 혁신을 시작함으로써 비즈니스에 대한 잠재적인 수익을 나타냅니다.
핵심 아이디어: 비효율적인 업무를 줄여 다시 확보한 시간을 활용하고 이를 가치로 전환하여 고객을 위한 새로운 기능을 제공해 수익을 창출합니다.
다음 계산식을 사용하여 재투자로 인한 잠재적 부가가치를 계산합니다:
새로운 기능에 재투자하기 위해 확보된 시간
이는 불필요한 재작업 감소로 인해 회복되고 새로운 기능에 재투자된 시간의 비율로 표시됩니다.
조정 시간, 거래 시간, 대기열 시간 등 다른 유형의 비-부가가치 시간을 제거하여 추가 시간을 확보할 수 있습니다. 업계 벤치마크를 이용할 수 없었기 때문에 이러한 범주는 포함하지 않았습니다. 가치 흐름 매핑과 같은 활동은 조직이 이러한 비효율성을 식별하고 제거하는 데 도움이 될 수 있습니다.
이 때 실험 빈도는 조직의 모든 시간이 새로운 기능을 작업하고 제공하는 데 소비된다고 가정합니다. 아예 새롭게 구성한 목적조직도 있겠지만, 이 분석에서는 기존 조직의 기술 혁신 목표를 통해 얻을 수 있는 이점과 개선을 통해 복구되는 시간 부분에만 중점을 둘 것입니다. 이는 추정치이며 각각의 결과는 조직 및 기술 성숙도에 따라 달라질 수 있습니다.
우리는 위와 동일한 방법론을 사용함으로 비효율성을 개선하여 복구할 수 있는 시간을 추정합니다. 그리고 이전에 명시한 불필요한 재작업 목표인 18% 를 사용하겠습니다.
이런 특별한 가치 상승은 불필요한 재작업 감소를 통해 실현된 효율성이 비즈니스에 재투자될 때만 가능합니다. 즉, 기술 전문가가 새로 확보한 여유 시간을 비즈니스 수익을 창출할 가능성이 있는 기능 작업에 전념할 수 있도록 하는 것입니다. 예를 들어, 확보한 시간이 프로세스 문서화 또는 테스트 자동화와 같은 작업에 사용된다면 조직은 확보한 여유시간을 노동시간으로 전환하는 것으로부터 여전히 이익을 얻지만 큰 수익을 실현할 가능성은 없습니다.
이 수치를 위해 2018년 Accelerate: State of DevOps 업계 벤치마크 데이터도 참조하는 것을 추천합니다:
엘리트 성과조직: 불필요한 재작업 시간을 부가가치가 나오는 작업으로 1% 정도 전환할 수 있습니다. (이 그룹은 불필요한 재작업에 시간의 19%를 소비한다고 보고했습니다. 목표 18%를 목표로 하면 기술 직원의 시간이 부가가치 작업에 소비되는 시간의 차이는 1%입니다.)
높은 성과조직: 부가가치가 나오는 작업으로 1.5% 정도 전환할 수 있습니다. (원래 19.5%를 보고한 이 그룹은 불필요한 재작업에 소요되는 시간 18%라는 제안 목표를 달성함으로써 기술 직원의 노력을 부가가치 작업으로 전환함으로써 부가가치 작업시간의 1.5% 증가를 실현할 수 있습니다.)
중간 성과조직: 부가가치가 나오는 작업으로 2% 정도 전환할 수 있습니다. (이 그룹은 불필요한 재작업에 시간의 20%를 소비한다고 보고했습니다. 목표 18%를 목표로 하면 기술 직원의 시간 중 현재 부가가치 작업에 소비할 수 있는 시간은 2%입니다.)
낮은 성과조직: 부가가치가 나오는 작업으로 2% 정도 전환할 수 있습니다.
(이 그룹은 불필요한 재작업에 시간의 20%를 소비한다고 보고했습니다. 불필요한 재작업을 18%로 줄임으로써 부가가치 활동에 시간을 2% 더 들일 수 있습니다.)
실험 빈도
조직이 A/B 테스트 등 정략적 또는 정성적인 사용자 연구를 통해 고객에게 직접기능을 테스트할 수 있는 능력은 객관적인 테스트를 원하는 조직에 큰 이점입니다. 그러나 팀이 정기적으로 코드를 배포할 수 없는 경우 소프트웨어 서비스에 고객의 피드백을 받는 것은 훨씬 더 어렵습니다. 즉, 낮은 배포 빈도로 인해 고객과 함께 기능을 실험하고 테스트할 수 있는 기회가 제한될 수 있습니다. 보수적으로 우리는 각 사업 부서별로 이 계산을 위한 조직 내 실험 빈도의 중간값인 주당 1회의 실험 빈도를 제안합니다
아래 State of DevOps 의 업계 벤치마크 데이터를 참조하여 각 부서에서 이것이 가능한지를 확인하세요:
엘리트 성과조직: 필요에 따라 코드를 배포할 수 있으며 하루에 여러 번 배포할 수 있습니다. 따라서 하루에 두 번 이상(또는 연간 730회)의 실험 빈도를 달성할 수 있다고 계산하였습니다.
높은 성과조직: 하루에 한 번에서 일주일에 한 번 사이에 코드를 배포할 수 있습니다. 이 분류에서는 일주일에 한번으로 계산하거나 하루/일주일 두 기간 중 높은 비율을 차지하는 기간을 실험에 사용했습니다.
중간 성과조직: 일주일에 한 번에서 한 달에 한 번 배포합니다. 이 분류에서는 한 달에 한번으로 계산하거나 일주일/1개월 두 기간 중 높은 비율을 차지하는 기간을 실험에 사용했습니다.
낮은 성과조직: 한 달에 한 번에서 6개월에 한 번 배포합니다. 이 분류에서는 6개월에 한번으로 계산하거나 1개월/6개월 두 기간 중 높은 비율을 차지하는 기간을 실험에 사용했습니다.
조직에 속한 부서
조직은 전략적 사업 단위 또는 사업 부서에서 소프트웨어를 만들고 배포합니다. 모든 사업 부서에는 고객에게 서비스를 제공할 수 있는 핵심 소프트웨어 제품 또는 서비스가 있습니다. 이 핵심 소프트웨어 제품 또는 서비스는 조직의 실험 장소입니다. 대규모 기술 조직은 더 많은 제품(사업 부문을 지원)을 보유하고 있으므로 더 많은 실험을 실행할 수 있습니다. 산업 및 회사 구조에 따라 각 조직이 보유한 사업 부문 수에는 상당한 차이가 있습니다. 각자에게 맞는 수치를 사용해야 하지만 여기에서는 설명을 위해 다양한 규모의 조직에 대해 다음 수치들을 사용합니다:
- 대기업: 약 8,500명의 기술 직원을 보유한 주요 사업이 주로 인하우스 소프트웨어 개발에 의존하고 있는 대기업의 경우(예: 금융 서비스) 사업 부서가 20개가 있다고 가정합니다.
- 중견기업: 약 2,000명의 기술 직원을 보유한 중견기업의 기술 조직의 경우 사업 부서가 8개가 있다고 가정합니다.
- 중소기업 및 비기술 기업: 약 250명의 기술 직원을 보유한 중소기업 및 비기술 기업의 경우 1개로 가정합니다.
아이디어 성공률
일반적으로 혁신성과 부가가치가 높은작업에 소요되는 시간은 조직에 이익이 되고 확실히 불필요한 재작업보다 시간을 더 효율적으로 사용하겠지만 이런 작업이 모두 수익을 창출하는 것은 아닙니다. 연구에 따르면¹² 수많은 실험을 통해 잘 설계된 기능의 1/3만이 주요 지표를 개선하는 것으로 나타났으므로 이 수치를 계산에 사용합니다. 이 지표는 기존 사용자 기반이 탄탄한 서비스에 적용됩니다. 신규 서비스의 경우 비즈니스에 높은 가치를 제공하는 작업을 할 수 있을 확률이 상당히 낮을 수 있습니다. 따라서 이 추정치는 상황에 따라 낙관적일 수 있으므로 자신이 처한 환경을 고려하여 적절한 비율을 사용해주세요.
아이디어 임팩트
각각의 아이디어나 기능은 우리의 수익에 기여할 수 있는 잠재력을 가지고 있습니다. 이 글을 보는 조직의 담당자들은 각자의 서비스에 적합한 아이디어 임팩트의 전환비율을 원할 것입니다. 우리는 계산을 위해 큰 변화는 없이 점진적인 기능 개선을 거치고 있는 이미 사업적으로 안정된 웹 소프트웨어를 제공하는 업체의 전문가들과의 대화를 기반으로 각각의 성공적인 아이디어 또는 기능이 수익에 평균 1% 까지 기여한다고 가정했습니다.
실제로 이는 수익에 대한 기여도를 0.01% 부터 200% 까지두고 아이디어를 나열한 백분율 분포에서 비롯됩니다. 우리 계산에서는 모든 아이디어의 수익에 대한 평균 기여도로 1%를 사용합니다.
서비스의 사업 규모
많은 조직에서 새로운 기능의 잠재 수익은 서비스나 비즈니스의 현재 수익에 따라 달라집니다. 우리는 이 계산에서 수익이 $100M인 서비스라고 가정했습니다.
위의 공식과 실제 수치들을 바탕으로 불필요한 재작업으로 인해 손실된 시간을 복구하고 이를 부가가치 활동에 재 투자함으로써 비즈니스에 추가되는 잠재적 가치를 표 3에서 볼 수 있습니다. 만약 작업 프로세스를 개선하지 않고 매년 새로운 기능에 재투자했을 때는 비즈니스에서 손실된 가치로도 간주될 수도 있습니다. 가장 훌륭하고 혁신적인 기업들이 그러하듯이 말이죠.
가치를 기반으로 수익을 추정하는 데 익숙하지 않은 조직의 경우 이러한 수치가 지나치게 높게 보일 수도 있습니다. 현재 수익을 고려하고 이로부터 잠재적인 수익을 추정하게 되었을때 놀라운 결과를 볼 수 있을 것입니다.
표 3.
새로운 기능에 대한 재투자로 인해 추가되는 잠재적 가치
비용 절감 계산
미리 계획된 비용이나 나중에 회피할 수 있는 일반적인 비용은 조직에 대한 수익을 나타냅니다.
비용 절감은 시간과 노력에 드는 비용을 줄이는 것부터 시작됩니다. 비즈니스 관점에서 볼 때 미리 계획된 비용이나 나중에 회피할 수 있는 일반적인 비용은 조직에 대한 수익을 나타냅니다. 즉, 사업에 새로 유입되는 자금이 아니더라도 수익으로 분류되는 것이고 우리는 보고서 전반에 걸쳐 이를 강조합니다.
연간 다운타임 비용
애플리케이션 및 인프라 가동이 중지 되어있는 시간은 상당한 비용을 수반하며, Steven Elliot과 IDC 팀의 최근 보고서에 따르면 Fortune 1000대 기업¹³의 경우 시간당 가동이 중지된 동안의 시간당 비용이 12억 5천만 달러에서 25억 달러에 이른다고 합니다. 다운타임 비용은 비즈니스의 성격에 따라 매우 다양하며, 대규모 금융 거래 기업은 단순히 고객에게 운영 시간을 알리기 위해 웹 존재를 유지하는 소규모 오프라인 기업보다 다운타임으로 인한 비용이 훨씬 더 높습니다. 또한 재가동을 위해 복구하는 방법은 인프라 설계에 따라 다릅니다. 이러한 계산은 예시로 제공되지만 자체 비용산정과 설계를 염두에 두고 비용을 계산하는 것이 좋습니다.
다운타임 수치는 서비스를 신속하게 복원하고 가능한 한 복원력 있는 시스템을 설계하여 실패를 방지하는 조직 능력의 중요성을 강조합니다. 다운타임 비용의 제거 또는 감소는 곧 비즈니스에 대한 수익을 의미합니다. 이 섹션에서는 엘리트, 높음, 중간, 낮은 성과조직이 매년 방지할 수 있는 다운타임의 양을 계산합니다.
핵심 아이디어: 다운타임 비용을 추정하는 방법을 찾으세요. 다운타임을 방지하면 비즈니스에 비용 절감 효과를 가져올 수 있기 때문입니다.
아래의 내용은 예시입니다.
연간 다운타임 비용을 계산하기 위하여 다음 계산식을 사용합니다:
배포 빈도
조직이 변경을 배포하는 빈도는 사고를 유발할 수도 있는 상황이 얼마나 자주 발생하는지에 영향을 미칩니다. 그러나 배포 빈도가 낮아지면 훨씬 더 크고 복잡한 코드 번들을 프로덕션 환경에 릴리스하게 되어 사고율 자체가 높아지거나 새로운 코드의 통합 및 지원이 어려워지고 발생한 오류에 대한 식별이 점점 더 어려워진다는 점을 기억하십시오
아래는 2019 Accelerate: State of DevOps 업계 벤치마크입니다:
엘리트 성과조직: 필요에 따라 코드를 배포할 수 있으며 하루에 여러 번 배포할 수 있습니다. 하루에 2번, 따라서 연간 730건의 배포로 계산하였습니다. 하루에 2번의 배포가 높은 것처럼 보일 수 있지만 Etsy는 하루에 80건 이상의 배포를 보고하고 있으며 Netflix와 Ama는 하루에 수천 번 배포하므로 굉장히 보수적인 수치입니다.
높은 성과조직: 하루에 한 번에서 일주일에 한 번 사이에 코드를 배포할 수 있습니다. 이 분류에서는 하루/일주일 두 기간 의 평균인 연간 209건의 배포로 계산합니다.
중간 성과조직: 일주일에 한 번에서 한 달에 한 번 배포합니다. 이 분류에서는 한 달에 한번으로 계산하거나 일주일/1개월 두 기간의 평균인 연간 32건의 배포로 계산합니다.
낮은 성과조직: 한 달에 한 번에서 6개월에 한 번 배포합니다. 이 분류에서는 6개월에 한번으로 계산하거나 1개월/6개월 두 기간의 평균인 연간 7건의 배포로 계산합니다.
코드 기반과 인프라를 젠가 탑이라고 상상해 보세요. 빈번한 배포는 타워에 젠가 조각 하나를 추가하는 것과 같습니다. 작은 추가 사항으로 빈번하게 배포를 하면 지원 관리가 용이하며 어떤 추가 기능이 중단을 일으켰는지 쉽게 식별할 수 있습니다. 또한 작은 추가 사항이 탑에 어떤 영향을 미치는지 확인하면서 기본 인프라를 계속 강화하고 지원할 수도 있습니다. 드물게 배포하는 것은 젠가 탑 꼭대기에 수백 개의 젠가 조각이 서로 붙어 있는 거대한 뭉치를 추가하는 것과 같습니다. 한번의 대규모 추가로 인해 탑 자체가 무너질 가능성이 훨씬 높으며 무너지고 나면 젠가 뭉치의 어떤 조각이 문제를 일으켰는지도 한참동안 파악해야 합니다.
변경 시 실패율
프로덕션에 도입된 모든 변경 사항은 오류, 사고 또는 서비스 저하가 발생될 가능성을 가지고 있습니다. 이러한 서비스 중단은 조직차원에서 해결해야 하며 더 큰 중단으로 이어질 가능성도 있습니다.
이 계산에서의 통계는 2019년 Accelerate: State of DevOps 의 업계 벤치마크를 참조하지만, 가능한 경우 자체 벤치마크를 사용하는 것이 좋습니다.
엘리트 성과조직: 변경 사항의 0~15%가 서비스 품질 저하를 초래하거나 수정이 필요하다고 보고합니다. 계산에는 다음 두 숫자의 평균인 7.5%를 사용합니다.
높은 성과조직: 변경 사항의 0~15%가 서비스 성능 저하를 초래하거나 수정이 필요하다고 보고합니다. 계산에는 두 숫자의 평균인 7.5%를 사용합니다.
중간 성과조직: 변경 사항의 0~15%가 서비스 성능 저하를 초래하거나 수정이 필요하다고 보고합니다. 계산에는 두 숫자의 평균인 7.5%를 사용합니다.
낮은 성과조직: 변경 사항의 46~60%가 서비스 성능 저하를 초래하거나 수정이 필요하다고 보고합니다. 계산에는 두 숫자의 평균인 53%를 사용합니다.
평균 복원 시간(MTTR)
우리는 복잡한 시스템을 사용하여 작업하므로 일부 오류와 가동 중지 시간의 발생은 불가피합니다. 핵심은 이런 상황이 발생 했을 때 시스템을 신속하게 정상으로 복원하는 능력입니다.
이 계산에는 2019년 Accelerate: State of DevOps 업계 벤치마크를 참조합니다.
엘리트 성과조직: 중단이 발생한 경우 1시간 이내에 서비스를 복원할 수 있다고 보고합니다. 엘리트 수행자는 가동 중단에 매우 민감하고 시스템 가동 시간의 우선 순위를 지정하므로 계산 시 이 범위의 중간점인 0.5시간을 사용합니다.
높은 성과조직: 하루 이내에 서비스를 복원할 수 있다고 보고합니다. 계산에는 이 범위의 중간점인 4시간을 사용합니다.
중간 성과조직: 중단이 발생한 경우 하루 이내에 서비스를 복원할 수 있다고 보고합니다. 계산에는 이 범위의 상한인 8시간을 사용합니다.
낮은 성과조직: 중단이 발생한 경우 1주일에서 1개월 사이에 서비스를 복원할 수 있다고 보고합니다. 계산에는 1개월의 중간값, 즉 15일(120시간에 해당)을 사용합니다.
가동 중단 비용
가동 중단상황은 조직에 많은 비용을 초래합니다. 그러나 가동 중단 비용은 매우 다양하며 특히 가동이 중단된 “폭발 반경”(전체 인프라가 중단 되었습니까, 아니면 업무상 중요하지 않은 단일 애플리케이션이 중단 되었습니까?) 및 서비스 저하 수준(전체 시스템을 사용할 수 없습니까? 아니면 특정 종류의 요청에 대한 응답 시간이 길어지고 있습니까?)에 따라 달라집니다. 이러한 계산을 구체화하려면 조직의 자체 데이터를 수집해야 합니다. 낮은 정밀도 수준에서 Stephen Elliot와 IDC 팀의 최근 보고서에 따르면 인프라 오류의 평균 시간당 비용은 100,000달러이고 주요 애플리케이션 오류의 평균 시간당 비용은 $500K에서 $1M 사이입니다¹⁴. DevOps는 핵심 애플리케이션 기능을 개발하고 제공하는 데 관여하므로 주요 애플리케이션 오류에 대해 제공된 수치를 사용합니다. 우리는 또한 보수적으로 추정치에 $500K를 사용할 것입니다. 그러나 소매업체, 금융 기관 등 일부 기업에서는 가동 중단 비용이 분당 수백만 달러에 달한다고 보고하므로 이러한 비용을 절대 간과해서는 안 됩니다. 가능한 경우 자체 평균 시간당 중단 비용을 사용하는 것이 좋습니다.
위 계산식과 설정한 수치들을 사용하여 연간 다운타임 비용을 계산합니다.
표 4.
다운타임 방지로 인해 회수할 수 있는 수익
위 계산에 따르면 낮은 성과조직은 연간 및 배포 기준으로 가장 높은 다운타임 비용을 발생시키는 것이 분명합니다. 높은 성과조직은 중간 성과조직에 비해 연간 다운타임 비용이 더 높습니다. 이는 높은 성과조직이 중간 성과조직보다 거의 6배 더 많은 배포 작업을 수행하고 이러한 변경 사항을 수정하기 위해 발생하는 후속 비용 때문일 것입니다. 또한 이 계산은 높은 성과조직이 중간 성과조직보다 배포당 지출이 더 낮다는 것을 보여줍니다. 실제로 엘리트 및 높은 성과조직은 가동 중단사태가 시스템 전체가 아닌 국지적으로 발생하고 시스템이 완전히 중단되기보다는 서비스 저하가 발생하도록 시스템을 설계하기 때문에 실제로는 이 수치가 계산보다 더 낮아야 합니다.
이러한 중요한 설계 특성은 가동 중지 시간이 비즈니스에 미치는 영향과 비용을 크게 줄여줍니다. 가동 중지 시간 비용을 줄이는 솔루션은 배포 빈도를 줄이는 것이 아니라 변경 실패율을 줄이고, MTTR을 줄이고, 시스템에 복원력을 구축하고, 오류 발생을 억제하여 시스템이 연속적인 글로벌 중단으로 이어지지 않고 점진적으로 성능이 저하되도록 방어하는 것입니다.
자주 배포하지 않음으로써 발생하는 숨겨진 비용에는 고객의 피드백을 받을 수 있는 기회가 줄어든다는 점도 있습니다. 이는 조직이 시장에서 실험하고, 조정하고, 지속적으로 승리할 때 우위를 점할 수 있는 요소이므로 줄어드는 것은 비용이라고 볼 수 있습니다.
절감된 다운타임 비용은 모두 비즈니스에 대한 수익을 의미합니다.
이 내용은 아래 계산에서 마저 볼 수 있습니다.
모두 적용하기
업무 참여도가 높고 행복한 직원은 IT 및 조직 성과에 기여하며 회사 성장과 높은 상관관계가 있는 것으로 나타났습니다.
이제 기술 혁신 및 개선 작업에 대하여 주요 비용 및 가치 구성 요소를 인지했으므로 이들을 모두 결합하여 DevOps 전환과 같은 기술 혁신을 수행했을 때의 잠재적인 수익을 찾아보겠습니다. 절감된 모든 비용은 비즈니스에 대한 수익을 의미한다는 점을 다시 한번 명심해주세요.
표 5.
$100M 규모 서비스를 가진 기업들의 잠재적 수익
계산된 잠재적인 연간 수익은 대부분의 사람들이 예상하는 것보다 훨씬 더 크며, 이는 진정한 변화와 지속적인 개선을 염두에 두고 기술에 투자하면 가치 있는 결과를 얻을 수 있음을 보여줍니다.
이제 위 계산에 포함되지 않은 추가적인 이득도 고려해보세요. 한 가지 예는 조직이 자원을 단순하게 다른 곳에 재투자함으로써 실현할 수 있는 가치입니다. 예를 들어, 불필요한 재작업을 줄여 절약된 시간을 다른 프로젝트에 재투자하여 회사의 가치를 창출하는 것입니다. 거의 절약된 만큼의 추가 인력을 새로 고용한 것이나 마찬가지인 직접적인 투자로 비유하여 계산해볼 수 있습니다.
또는 초과 자원을 전통적인 재투자 계산법에 적용하면 자본 투자로 분석할 수 있으며, 기준 수익률과 내부 수익률로 평가할 수 있습니다. 연구를 수행하며 진행한 미래 지향적인 기업과의 논의에서 그들은 정기적으로 비효율적인 것들을 해소하여 확보한 리소스를 활용하여 새로운 혁신과 가치를 실현할 계획을 세우고는 합니다.
이 아티클에서는 이러한 계산은 포함하지 않았지만, 또 다른 이점들을 스스로 생각해 보는 것이 좋습니다.
마지막으로, 직원과 조직 문화에 주는 이점을 무시할 수 없습니다. 재작업에 소요되는 시간을 줄이고 부가가치 개발에 더 많은 시간을 투자하는 팀의 사기 진작을 상상해보세요.
연구에 따르면 업무 참여도가 높고 행복한 직원은 IT 및 조직 성과¹⁵에 기여하며 회사 성장¹⁶과 높은 상관관계가 있는 것으로 나타났습니다. 또한 팀이 좋은 인재를 추가로 유치하고 유지하는 데 도움이 되어 선순환을 형성합니다.
투자 대비 수익 증명하기
이 아티클을 통해 기술 혁신으로 얻을 수 있는 이익에 대하여 금전적인 표현으로 무장할 수 있다면 투자 수익을 입증할 준비가 거의 완료되었습니다. 또한 이 변환에 대한 투자 비용도 계산해야 합니다. 이 아티클에서는 이러한 비용에 대해 간략하게 안내합니다.
계산에는 다음 비용들을 포함되어야 합니다:
- 취득비용: 자격증 취득, 라이센싱 등을 포함한 기술
- 교육비용: 기술 직원이 교육을 받는 동안 발생하는 생산성 손실 비용을 포함한 교육(혜택 승수 포함)
- 기회비용: 새로운 기술과 프로세스를 학습하는 동안의 가동 중지 시간(급여 및 복리후생 비용 포함)
- 컨설팅 비용
- 리팩토링, 재설계 등 기타 관련 비용
계산 샘플
$100M 가치의 서비스 보유한 대규모 기술 조직의 기술 혁신을 위해 $6.8M(모든 인수, 교육 및 인건비 포함)의 투자 가치를 사용하여 투자 회수 기간과 투자 수익이라는 두 가지 방법을 제시합니다.
총 $6.8M 투자 금액 상세내역의 예는 다음과 같습니다:
이 숫자가 비정상적으로 높은 것처럼 보일 수 있지만 이것보다 훨씬 더 높을 가능성이 많습니다. 기술 혁신은 노동력에 크게 의존합니다. 2000년대 연구에 따르면 인건비가 기술 비용의 2배에 달하는 것으로 나타났습니다¹⁷. 최근 사례에서 Forrester의 클라우드 앱 마이그레이션 비용 모델에 따르면 인건비가 서비스 및 인프라 비용을 훨씬 초과하는 것으로 나타났습니다¹⁸.
Patterson: Patterson, D. (2002, 2002년 11월 3–8일). 다운타임 비용을 추정하는 간단한 방법. 펜실베니아주 필라델피아에서 열린 대규모 설치 시스템 관리자 컨퍼런스(LISA ‘02)에서 발표된 논문.
Forrester: https://www.forrester.com/report/Brief+The+Cost+Of+Migating+An+Enterprise+Application+To+A+Public+Cloud+Platform/-/E-RES132801
회수 기간
투자 수익률을 설명하는 방법 중 가장 간단한 것은 투자 회수 기간을 계산해보는 것입니다. 간단히 말해, 이 방법은 투자를 했을 때에 이익이나 절감 측면에서 회수되는 데까지 시간이 얼마나 걸리는지 묻는 것입니다.
종종 투자 회수 기간을 돈과 재투자의 시간 가치를 무시하고 감에 의존하여 설정하는 경우가 많습니다. 투자 회수 기간 계산은 일반적으로 현금 기반으로 계산하기도 하지만 여기에 표시된 것처럼 모든 투자 및 수익을 추정하는데에 사용할 수도 있습니다.
이번 계산의 케이스에서는 투자가 수익을 충당하는 데 걸리는 시간입니다. 계산의 결과는 연도 단위로 표기합니다.
엘리트 성과조직의 규모가 큰 사업에서 나오는 잠재적 수익을 활용하여 이 계산에서는 $6.8M의 비용을 들여서 연간 $80.6M의 수익을 창출하는 투자를 고려하고 있습니다. 연간 현금 흐름이 동일하다고 가정하여 투자금을 수익으로 나누어 투자 회수 기간을 계산합니다:
투자 회수 기간은 0.085년, 즉 약 31일입니다. 이는 이 투자가 매우 빠르게 “자가 회수”된다는 것을 의미합니다. 이 계산에서는 이 기간이 짧을수록 좋습니다. 투자 회수 기간은 투자가 회사에 얼마나 오랫동안 위험을 초래할 것인지를 보여주기 때문에 위험 분석 관점에서 유용하게 사용되곤 합니다. 이는 특히 빠르게 발전하는 기술 산업에 투자할 때 유용합니다. 이 분석 방법의 장점은 누구에게나 쉽게 이해되고 전달된다는 것입니다. 조직은 회수 기간을 계산하는 이 방법에서 현금 흐름이 동일하다고 가정한다는 점을 유의해야 합니다. 현금 흐름이 투자수급 등으로 가속되거나 시장 상황에 따라 고르지 않은 경우 계산 시 이를 반드시 고려해야 합니다.
투자 수익
프로젝트의 수익성을 계산하여 투자 대비 수익률을 백분율로 나타냅니다. 이 비율은 투자자와 사업가들이 해당 투자를 다른 기업의 투자와 비교할 때에 유용합니다.
위의 예시의 계산에서 $6.8M의 비용을 들여 연간 수익(반올림)으로 $80.6M을 창출하는 투자를 고려하고 있습니다. 투자 수익은 수익에서 투자 금액을 빼고 그 숫자를 다시 투자 금액으로 나누어 계산합니다:
이 투자의 ROI는 10.832입니다. 계산결과에 따라 기술 혁신 목표에 투자한 1달러당 약 10.83달러를 벌었다고 말할 수 있습니다.
아마 이 ROI 수치가 잘 나온 것인지에 대해 궁금해할 수 있을 것입니다. 그것은 조직의 기준에 따라 다릅니다. 조직의 다른 투자 자산과 비교하여 ROI 비율을 생각해 볼 수도 있습니다. 현재 조직이 주식, 채권 등 회사 외부에 투자하여 수익을 얻고 있나요? 다양한 주식 포트폴리오에 투자하는 것은 위험이 덜합니다. ROI가 큰 자신의 회사에 투자하는 것도 수익 기회를 높이는 좋은 방법이 될 수 있습니다. 즉, 자체 기술 혁신에 투자하여 외부 투자와 비등한 수익(또는 더 나은 수익)을 얻을 수 있는데다가 시장에서 승리하는 데까지 도움이 되기 때문에 조직이 이 전략을 취했을 때 좋은 결과를 얻을 수 있을 것입니다.
결론: 기술 혁신은 성과를 낸다.
앞서 설명한 것처럼 기술 혁신 이니셔티브를 수행하면 대부분의 조직에서 상당한 수익을 얻을 수 있습니다. 물론, 비용을 추정할 때 비용이 과대평가되거나 과소평가될 수 있는 위험뿐만 아니라 예상 기간 내에 수익이 실현되지 않거나 고객 선호도 또는 이자율이 변화하거나 시장 상황이 변화할 수 있는 위험도 분명 있습니다. 그럼에도 비용 및 가치 추정은 여전히 가치가 있으며 팀 구성원과 리더십에게 의사 결정의 기반을 제공합니다.
우리는 이 아티클을 통해 각 유형의 성과조직들으로부터 배워야 할 교훈을 찾을 수 있었습니다.
데이터에 따르면 중간 성과조직은 지속적으로 기술 부채를 소진하고 비용보다 속도와 가치를 최적화함으로써 가장 많은 이익을 얻을 수 있었습니다. 우리는 중간 성과조직이 이 작업을 계속하고, 열심히 일한 후에도 진전이 없다고 생각하고 이전 방식으로 돌아가 단기적인 개선에 안주하고 기술 부채를 다시 쌓는 지점에 도달하지 않기를 바랍니다. 중간 성과조직은 처리량과 안정성 모두에서 지속적으로 높은 성능을 달성하기 위해 지속적인 통합, 자동화된 테스트, 버전 제어와 같은 지속적인 전달의 스마트한 기술 관행을 구현하여 운영 효율성을 향해 지속적으로 발전해야 합니다.
낮은 성과조직은 역설에 직면했습니다. 이들은 복잡한 레거시 시스템과 보수적인 문화로 인해 경쟁사보다 훨씬 뒤떨어져 있습니다. 하지만 이러한 조직에는 이를 발견하고 개선해내려는 의지만 가진다면 다른 조직들보다 더 쉽게 얻을 수 있는 열매들이 많이 있습니다. 다른 목표들과 마찬가지로 측정 가능한 비즈니스 목표를 설정하고 조직 전체의 이해관계자들과 협력하여 결과를 달성하기 위한 아이디어들을 공격적으로 실험하는 것이 중요합니다. 변화에 대한 역량과 열망이 있을 가지고 리더로부터 지원을 받아, 작은 임팩트라도 괜찮으니 몇 달이 아닌 몇 주 안에 측정 가능한 결과를 빠르게 제공할 수 있는 방향을 찾아 보세요.
기술 혁신을 시작하는 모든 팀의 경우 많은 개선 이니셔티브가 “J 커브”를 따른다는 점을 기억하고 미미한 초반 결과에 실망하지 않도록 대비하십시오. J 커브는 개선을 위해 새로운 구성원이 팀에 합류하거나 새로운 프로세스가 시행되었지만 상황이 개선되기 전에 도입 초기 성과에 부정적인 영향이 생겼을 때 성과를 추구하는 팀이 자주 경험하는 현상입니다. Julia Wester가 지적했듯이 변화의 규모는 진행하는 도중의 부정적인 반응의 정도에 영향을 받는 경우가 많습니다. 기술 혁신 이니셔티브는 큰 변화이므로 당장 성능이나 생산성에 타격이 생겼다고 해서 지레 겁먹고 포기하지 마세요. 초기에 오히려 하락하는 이러한 패턴은 조직이 기술 부채를 처리함에 따라 불필요한 재작업 비율이 높아지면서 그려지는 낮은 성과조직에서 엘리트 성과조직으로 이동하는 데이터 그래프에서 찾을 수 있었습니다. 조직이 이를 감내하고 고수하면 다른 연구에서 보고된 것과 동등한 뛰어난 소프트웨어 개발 및 제공 기능과 불필요한 재작업 비율을 낮출 수 있는 것으로 보상을 받게 될 것입니다.
기술혁신의 J 커브
원문 저자소개
Nicole Forsgren 박사는 기술 전문가와의 작업으로 가장 잘 알려진 IT 영향 전문가이자 현재까지 가장 큰 DevOps 연구의 수석 연구원입니다. 그녀는 지식 관리, IT 채택 및 영향, DevOps 분야의 컨설턴트, 전문가 및 연구원입니다. Nicole은 DORA의 CEO이자 수석 과학자입니다. 이전에 그녀는 교수, 시스템 관리자, 하드웨어 성능 분석가였습니다. 그녀는 공공 및 민간 연구 보조금(NASA 및 NSF를 포함한 기금 제공자)을 받았으며 그녀의 연구는 다양한 언론 매체와 여러 동료 검토 저널 및 컨퍼런스에 소개되었습니다. 그녀는 경영 정보 시스템 박사 학위와 회계 석사 학위를 보유하고 있습니다.
Jez Humble은 The DevOps Handbook, Lean Enterprise 및 Jolt Award를 수상한 Continuous Delivery의 공동 저자입니다. 그는 세 대륙에 걸쳐 다양한 규모의 회사에서 코드, 인프라 및 제품 개발을 다루며 경력을 쌓았으며 가장 최근에는 18F의 미국 연방 정부에서 근무했습니다. 그는 현재 Google Cloud의 Staff Developer Advocate이며 UC Berkeley에서 강의하고 있습니다.
김진(Gene Kim)은 여러 상을 받은 CTO이자 연구원이자 작가입니다. 그 1999년부터 고성능 기술 조직을 연구해왔습니다. 그는 Tripwire의 창립자이며 13년 동안 CTO로 재직했습니다. 그는 The Phoenix Project: A Novel About IT, DevOps, Helping Your Business Win(2013), The DevOps Handbook(2016), The Visible Ops Handbook(2004) 등 4권의 책을 공동 집필했습니다.
브레나 워싱턴(Brenna Washington)은 Google의 제품 마케팅 관리자입니다. 그녀는 개발자 마케팅을 담당하고 Google Cloud에서 가장 많이 사용되는 개발자 도구에 대한 제품 스토리 작성을 담당하고 있습니다. Google Cloud에서 일하기 전에 Brenna는 YouTube와 협력하여 인지도부터 획득에 이르기까지 마케팅 유입경로 전반에서 YouTube가 수행하는 중요한 역할을 이해하도록 광고주의 인지도를 높였습니다. Brenna는 University of Southern California에서 빅 데이터 분석 자격증을 취득하고 경영학 및 영화 예술 학사 학위를 취득했습니다.
Nikhil Kaul은 Google Cloud에서 DevOps 제품 마케팅을 총괄하며 DevOps 제품 및 솔루션의 포지셔닝, 메시징, 시장 진출을 담당하고 있습니다. Google에 입사하기 전에 Nikhil은 소프트웨어 엔지니어링 및 제품 관리를 포함한 다양한 기술 역할에서 시간을 보냈습니다. Nikhil은 조지타운 대학교에서 경영학 석사(MBA)를 취득했습니다.
Dustin Smith 박사는 Google의 인간 요인 심리학자이자 직원 사용자 경험 연구원입니다. 그는 소프트웨어 엔지니어링, 무료 게임, 의료 등 다양한 맥락에서 사람들이 주변 시스템과 환경에 어떻게 영향을 받는지 연구합니다. Google에서 진행한 연구에서는 소프트웨어 개발자가 개발 과정에서 더 행복하고 생산적으로 느낄 수 있는 영역을 식별하는 데 중점을 두었습니다. Dustin은 위치타 주립대학교에서 인간 요인 심리학 박사 학위를 받았습니다.
DORA 팀에 대하여
DORA(DevOps Research and Assessment)는 Nicole Forsgren 박사, Jez Humble 및 Gene Kim이 소프트웨어 개발 맥락에서 고성능을 이해하고 이러한 고성능을 예측하는 요인에 대한 연구를 수행하기 위해 설립되었습니다. 2018년에는 DORA가 Google에 인수되었습니다. Google Cloud의 일부인 DORA는 데이터 기반 통찰력을 통해 개발자와 운영자를 위한 즐거운 경험을 계속해서 만들고 있습니다. 또한 지난 6년 동안 31,000명 이상의 전문가를 대상으로 한 DORA의 연구는 기술 조직을 평가하고 벤치마킹하기 위한 증거 기반 도구 세트의 기초가 됩니다.
https://cloud.google.com/devops 에서 더 자세히 알아보세요.
조직에서 기술 혁신을 평가하고 계십니까?
우리가 직접 귀하의 조직을 평가해드립니다.
camp-info@google.com으로 데모를 요청하세요.
원문의 레퍼런스 목록
- Kim, G. (n.d.) The Amazing DevOps Transformation of The HP LaserJet Firmware Team (Gary Gruver).
Retrieved from https://itrevolution.com/the-amazing-devops-transformation-of-the-hp-laserjet-firmware-team-gary-gruver/ - DevOps Research and Assessment & Google Cloud. (n.d.).2019 Accelerate: State of DevOps Report (Rep.)
- DevOps Research and Assessment & Google Cloud. (n.d.).2019 Accelerate: State of DevOps Report (Rep.)
- DevOps Enterprise Summit 2014. (2014, October 29). DOES14 — Courtney Kissler — Nordstrom — Transforming to a Culture of Continuous Improvement Retrieved from https://www.youtube.com/watch?v=0ZAcsrZBSlo
- Earnshaw, A. (2013, July 18). DevOps Solves Business Problems: Gene Kim’s Top Aha Moments. Retrieved from https://puppet.com/blog/devops-solves-business-problems-gene-kim%E2%80%99s-top-aha-moments
- Divine, C. (2011, April 20). Leadership in an Agile Age: An Interview With Scott Cook. Retrieved from https://web.archive.org/web/20160205050418/http://network.intuit.com/2011/04/20/leadership-in-the-agile-age/
- Ippolito, B., & Murman, E. (2001, December). Improving the Software Upgrade Value Stream. In 43rd AIAA Aerospace Sciences Meeting and Exhibit (p. 1252).
- Chron 200 / Interview with CEO of the Year Charles Schwab. (2007, April 9).
Retrieved from https://www.sfgate.com/business/article/Chron-200-Interview-with-CEO-of-the-Year2603664.php
https://dspace.mit.edu/bitstream/handle/1721.1/83541/REP_0101_Ippo.pdf?sequence=1 - Hainzinger, Brittany. “DevOps Salary Report for 2019 Is Here.” App Developer Magazine, 22 Jan. 2019, https://appdevelopermagazine.com/devops-salary-report-for-2019-is-here
- Morozoff, E. (2009, September 4). Using a Line of Code Metric to Understand Software Rework.
Retrieved from https://ieeexplore.ieee.org/document/5232799/ - Kohavi, R., Crook, T., Longbotham, R., Frasca, B., Henne, R., Ferres, J., Melamed, T. (2009). Online Experimentation at Microsoft. Retrieved from http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf
- Kohavi, R., Crook, T., Longbotham, R., Frasca, B., Henne, R., Ferres, J., Melamed, T. (2009). Online Experimentation at Microsoft.
Retrieved from http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf - Elliot, S. (2014). DevOps and the Cost of Downtime: Fortune 1000 Best Practice Metrics Quantified.
Retrieved from https://info.appdynamics.com/DC-Report-DevOps-and-the-Cost-of-Downtime.html - Shimel, A. (2015, February 11). The real cost of downtime. Retrieved from https://devops.com/real-cost-downtime/
- DevOps Research and Assessment, LLC. (n.d.). 2019 Accelerate: State of DevOps Report (Rep.)
- Reichheld, F. F. (2003, December). The One Number You Need to Grow. Retrieved from https://hbr.org/2003/12/the-one-number-you-need-to-grow
- Patterson, D. (2002, Nov 3–8, 2002). A Simple Way to Estimate the Cost of Downtime. Paper presented at the Large Installation System Administrator’s Conference (LISA ‘02), Philadelphia, PA
- Rymer, J. R., Bartoletti, D, Martorelli, B, Mines, C, Tajima, C. (2016, March 9). Brief: The Cost Of Migrating An Enterprise Application To A Public Cloud Platform.
Retrieved from https://www.forrester.com/report/Brief%20The%20Cost%20Of%20Migrating%20An%20Enterprise%20Application%20To%20A%20Public%20Cloud%20Platform/RES132801 - Wester, J. (2016, February 6). Why improvement initiatives fail. Retrieved from http://www.everydaykanban.com/2013/02/26/why-improvement-initiatives-fail/
