DevOps: 신속하고 신뢰 가능하게 앱을 전달하는 협업적 사고 방식


잘 설계되어 강력한 DevOps 적용으로 소프트웨어 배포 속도와 안정성이 증가하는 동시에 오류 복원 시간과 소프트웨어 업데이트 지연 시간이 줄어들고 있음을 보여주는 증거가 늘어가고 있습니다.
공유

왜 DevOps인가?

제품 출시 기간 단축

소프트웨어 중심 세상에서는 고객의 요구를 신속하게 파악해 소프트웨어를 빌드 및 릴리스함으로써 경쟁을 피해가는 것이 성공의 핵심입니다. 현대적 엔터프라이즈 애플리케이션의 분산형 구성 요소의 복잡한 상호 의존성을 고려했을 때 온전하게 DevOps를 구성하면 잘못된 의사소통과 지연을 피하고 개발자와 IT 운영자의 연합된 전문 기술을 통해 능률적으로 소프트웨어를 전달할 수 있습니다. 2016년 DevOps 현황 보고서 (2016 State of DevOps Report)에 따르면 DevOps를 구성한 조직들은 (평균) 200배 이상 배포 회수가 늘어났고, 지연 시간 (코드 배포 의도 시점과 코드 프로덕션 시점 간의 시간차) 처리는 1/2555로 짧아졌습니다. 아래 Gartner의 차트에서 보는 바와 같이 다른 산업 연구 결과에서도 비슷한 결과를 보이는데, DevOps 접근 방식으로 전환했을 때 늘어난 혜택들을 보여줍니다.


질문: 아래 결과들 가운데 DevOps는 귀하의 조직에 어떤 결과를 가져왔습니까?

응답자: n=95 DevOps를 사용하는 Gartner Research Circle 회원

[출처: Gartner; Five Questions I&O Leaders Should Ask Before Funding a DevOps Initiative; October 2016]

DevOps 관찰 결과




낮은 위험과 순조로운 배포

현대적 애플리케이션의 개발, 배포, 크기 조정, 보안, 패치, 고가용성을 조직하고 관리하는 일은 매우 복잡하고 잠재적으로 오류 가능성이 넘쳐나는 일입니다. 협업적 문화와 패키징, 배포, 모니터링, 관리 등에 대한 자동화로 구성된 DevOps 진행은 프로덕션에 새로운 코드와 업데이트 적용하기 위한 일관성과 속도를 제공합니다. DevOps 팀들은 지속적인 학습과 결부해 대부분의 문제 원인을 식별해 제거함으로써 더욱 강력하고, 효율적이며, 반복 가능하고 완벽한 릴리스 프로세스를 구축하고, 나아가 지속적으로 사건사고 없이 소프트웨어를 배포할 수 있습니다.


더욱 빠른 복구

프로덕션 도중 코드가 깨지거나 중단이 발생할 경우 DevOps 진행은 잘 준비된 진단을 수행하여 신속하게 복구에 들어갑니다. 대부분의 릴리스와 관리 프로세스를 작동시키는 훌륭한 자동화와 모니터링 기능 덕분에 DevOps 팀은 신속하게 협업해 오류 원인, 롤백 변경 또는 문제 해결책을 추적하고 확인할 수 있습니다. 실제로 2016년 DevOps 현황 보고서 (2016 State of DevOps Report)에 따르면 DevOps를 사용하는 조직에서는 예상치 못한 프로덕션 문제에 대해 평균 복구 속도보다 24배 빠르게 신속하고 구조적인 반응을 보였고, 변경 오류율은 1/3배 수준 이하를 보였다고 제시되어 있습니다.


고객 만족도 및 제품-시장 적합도 향상

신속하고 신뢰 가능하게 기능을 릴리스하고 버그를 수정하는 것은 높은 반응성과 그에 따른 고객 만족으로 이어질 뿐만아니라 대부분의 고객 관리 성능에 대해 신속한 피드백과 빠른 컨버전스로도 이어집니다. DevOps 진행은 그처럼 지속적인 전달과 빠른 주기 시간의 핵심입니다. 결과적으로 발생하는 복잡성을 관리하기 위해 개발자와 IT 운영자 간의 지속적이고 긴밀한 협업하지 않았다면 일관되고 신속하게 현대적이고 분산형이며 즉시 프로덕션 가능한 소프트웨어 기능을 개발, 테스트, 전달하는 것은 아예 불가능했을 것입니다.


DevOps vs. 기존의 접근 방식

DevOps는 소프트웨어 구성에 다른 사고 방식과 새로운 프로세스를 도입합니다. 아래에는 DevOps를 도입한 조직과 기존의 접근 방식을 유지하는 조직간의 주요 차이점이 일부 설명되어 있습니다.


차이점 비교: DevOps vs. 기존의 접근 방식
DevOps 진행
기존의 접근 방식
협업 중심. 성공적인 DevOps는 신속하고 신뢰성있는 소프트웨어의 개발과 전달을 보장하기 위해 개발팀과 IT 운영팀의 성공적이고 지속적인 협업 능력에 의존합니다. 사일로 중심. 기존의 접근 방식은 협업에 대해서는 “다짜고짜 떠넘기기” 메타포에 의존합니다. IT 운영자는 프로덕션 환경에서 소프트웨어 배포와 관리를 담당하며, 개발팀에는 최소한의 지원이나 인사이트를 제공합니다.
상당한 수준의 (또는 전체적) 구조화와 자동화. DevOps 진행은 개발 환경에서의 작동이 프로덕션 환경에서의 작동을 보장하는 환경 프로비저닝과 구성에서 속도, 일관성, 반복성을 제공하는 자동화에 의존합니다. 또한 구조적 접근 방식은 오류 복구를 반복 가능한 자동화만큼 빠르게 바꿔주므로 롤백과 복구가 편해집니다. 눈송이 중심 및 대부분 수동. 기존의 접근 방식은 (“눈송이"처럼 고유한 서버 환경에서) 스크립팅과 수동 프로세스의 즉석 조합에 의존해 인프라스트럭처를 프로비전하고 구성합니다. 이런 방식은 프로젝트를 제대로 수행하거나 신뢰 가능하게 반복하거나 신속하게 진행하기 어렵습니다. 또한 개발 및 프로덕션 인프라스트럭처와 구성 패리티를 신속하고 일관되게 프로비전하는 능력이 없으므로 많은 문제에 봉착하는 경향이 있습니다.
셀프 서비스 중심. DevOps 중심 조직은 협업 및 자동화 프레임워크를 구축해 개발자와 IT 운영자에게 상대방에게 방해되지 않고 독립적으로 일하도록 자율권을 줍니다. 예를 들어 개발자는 IT 운영자의 직접적인 프로비저닝을 기다리지 않고 신속하게 개발/테스트 환경을 자체적으로 프로비전할 수 있습니다. "정보 기술 (IT) 티켓" 중심. 기존의 엔터프라이즈 접근 방식에서 IT 운영자는 쉽게 자동화 가능한 IT 티켓 관리 작업을 수행하고 반복적이고 복잡한 수동 프로비저닝과 구성을 진행해야 합니다. 그 결과 프로비저닝, 배포, 크기 조정, 다른 소프트웨어 전달 및 관리 활동이 상당히 복잡해지고 지연됩니다.
비즈니스 중심. DevOps 조직은 공동으로 비즈니스 성공을 추진하는데 집중합니다. 그러므로 소프트웨어 전달 성공에 대한 책임도 공동으로 집니다. 기능 중심. 기존의 접근 방식은 개발자와 IT 운영자가 그들 기능에 집중하되 전체적인 성공에 대해서는 별다른 책임을 부여하지 않았습니다. 그 결과 문제와 오류가 발생해 수많은 비난을 받고 조직내에서 마찰이 발생합니다.
변경 맞춤형. DevOps 진행은 신속하고 반복 가능하게 자동화하도록 디자인됩니다. 신속한 오류 복구뿐만 아니라 신속한 변경 처리도 수행하게 빌드됩니다. 신속하게 진행하기 위해 빌드되는 것입니다. 변경 반대. 기존의 접근 방식에서는 손댔다가 빨리 복구할 수 없게 될까봐 프로덕션 배포를 변경하지 않습니다. 전통적인 접근 방식에서는 변경과 업데이트를 최소화하고 조직에게는 천천히 진행할 것을 간접적으로 권장합니다.