DevOps란?
DevOps는 Lean 사고 및 Agile 개발과 함께 시작된 확장된 범위의 애플리케이션과 일련의 움직임이 정점을 이루어 표현된 것으로서, 궁극적으로는 신속하게 고성능 소프트웨어를 제공하는 것이 목적입니다. 일반적으로 Agile 개발은 소프트웨어 엔지니어가 중심 역할을 맡으며, 빠르고 점증적인 소프트웨어 개발에 집중합니다. 클라우드 시대의 소프트웨어는 (직접 설치되는 방식이 아니라) 하나의 서비스로 소비되는 추세입니다. 소프트웨어는 더 이상 전달 대상이 아니라 프로덕션 환경에서 실제 사용되는 대상입니다. Agile 철학을 유지하되 소프트웨어 기능의 지속적이고 점증적이며 신속한 제공을 강화하는 추세입니다. 따라서 Agile에는 필연적으로 코드 완성에서 프로덕션 지원 (예를 들어 빌드, 테스트, 프로비저닝, 구성, 배포, 지속적인 관리)에 이르는 소프트웨어 변환 활동을 아우르는 운영 측면의 속도와 품질이 확장 포함되어 왔습니다. 이처럼 빠르게 소프트웨어를 전달하려면 개발자 (Dev)와 IT 운영자 (Ops) 쌍방이 공동으로 협업해야 합니다.
DevOps 이동은 이러한 요구를 인정하고 그에 부응하는 것입니다. 그러므로 DevOps는 유연하며, 더 높은 수준의 협업, 의사 소통, 공동 책임을 통해 제품 개발측 (개발자 및 QA)과 IT 운영측 간에 존재했던 수많은 기존의 전달 갈등과 지연을 상당 부분 방지함으로써 소프트웨어의 성공적인 전달을 추구합니다.
역사적 맥락
DevOps는 기존의 엔터프라이즈 소프트웨어 전달 사고 방식과 뚜렷하게 대비됩니다. 일반적으로 별개의 소프트웨어 개발 및 IT 운영 조직들이 구성되어 독립적으로 일하는 대부분의 기업에서는 개발자와 IT 운영자가 단절하게 되고 신속하게 소프트웨어를 전달하기 어려운 상황에 놓입니다. 예를 들어 대부분의 기업 개발자들은 (IT Ops의 통제를 받도록) 구성된 인프라스트럭처를 쉽게 프로비저닝할 수 없고, 그러므로 반복 가능하고 표준화된 환경을 제시할 수 없습니다. 결과적으로 개발자들은 효율적으로 개발하고 테스트할 수 있도록 특별하게 구성된 개별 환경에서 담당 코드 부분만 개발하고 끝내게 됩니다. 그러면 해당 코드는 (다양한 환경의 여러 개발자들이 개발하고 테스트한) 다양한 소프트웨어 아티팩트를 다루는 IT 운영자에게 전달되어 고가용성, 확장성, 보안 등 바람직한 엔터프라이즈 특성을 가진 실행 중인 애플리케이션 배포판에 적용됩니다.
이런 경우는 대체로 개발팀에서 지원해주지 않을 경우 IT 운영자에게는 복잡하고, 손이 많이 가고, 느리고, 오류 발생이 잦은 프로세스입니다. 소프트웨어 배포 시에 발생하는 문제들은 보통 당사자들 간의 마찰과 불신으로 이어집니다. 이 경우 현대적이고 지속적인 제품 제공 환경은 악화됩니다. 개발자들은 기능을 빠르게 구현하라는 압박을 받는 반면 IT 운영자들은 안정성 확보에 대한 압박을 받습니다. 현실적으로 (현대식 자동화 프로세스를 거치지 않고) 양쪽의 요구사항을 모두 구현할 유일한 방법은 변경을 제한하는 것 뿐입니다.
기본 요소
DevOps 진행 방식에는 특별한 규범이 있지는 않습니다. 하지만 성공적으로 우수한 기능을 보이는 DevOps 진행들은 몇 가지 공통된 특징들을 나타내고 조직의 문화, 프로세스, 도구에 영향을 미칩니다.
문화
공동 성공, 협업, 공동 책임을 가치있게 여기는 문화는 성공적인 DevOps 진행에 스며듭니다. 개발자들과 IT 전문가들은 공동으로 성공적인 애플리케이션 전달을 책임집니다. 이는 조직적 변화를 통해서 가능합니다. 예를 들어 서비스를 빌드/실행하는 개발 및 운영 직원을 함께 배치하기 위해 직원을 프로젝트에 매트릭스화하고 거기에 전담시키는 기능적 사일로가 있습니다.
또한 DevOps는 서로의 역할을 더 잘 이해함으로써 상대방과 편하게 협조하고 효과적으로 협업해 업무를 조정할 수 있도록 공감을 강조하고 개발자와 IT 운영자들을 격려합니다. 예를 들어 개발자들은 프로덕션 배포 환경을 이해하면 잠재적인 운영 오류와 관련 디자인 문제를 더 잘 이해하게 됩니다. 반대로 IT 운영자들은 애플리케이션 디자인과 목적을 더 잘 이해하여 배포 구성 최적화를 도울 수 있습니다.
성공적으로 DevOps를 진행하면 잘못 조정된 정책들 (예를 들어 개발자들에게는 신속한 기능의 배포를, IT 운영자들에게는 프로덕션 배포 변경을 최소화를 장려하는 것)로 인한 잠재적인 마찰 원인들을 적극적으로 제거할 수 있습니다.
프로세스
실제 DevOps 문화를 뿌리내리려면 개발자와 IT 운영자가 만나 의견을 나누고 신속하고 구조적 소프트웨어 전달과 오류 복구에 필요한 전문 지식과 명확한 협업 프레임워크를 공유하는 공동의 프로세스를 거쳐야 합니다. 예를 들어 관련 프레임워크를 통해 개발자가 API 용량을 프로비저닝하고 IT 운영자는 이를 구현 및 지원할 의무를 지정할 수 있습니다. 또는 API가 개발, 테스트 또는 프로덕션 환경을 구분하지 않음으로써 지연과 문제 발생의 원인인 환경적 패리티 이슈를 제거하도록 합의/계약할 수도 있습니다.
공동 프로세스의 다른 사례로는 공동 개발된 스크립트로 현행 유지되는 소프트웨어 종속성에 대한 중앙 저장소 합의 및 사용이 있습니다. 시간이 지나면서 그와 같은 협업은 학습, 반복 개선, 프로덕션에 대해 반복 가능하되 중단 위험이 없는 점증적이고 빈번한 소프트웨어 변경 적용 능력을 일궈 냈습니다.
자동화 및 공유 도구
신속하고 신뢰 가능한 소프트웨어 전달에는 불필요한 직접 개입을 배제하도록 간소화된 프로세스 일관성과 반복성이 요구됩니다. 예를 들어 기업에서는 일상적으로 용량 할당, 개발 및 프로덕션 환경 간의 격차, 복잡한 수동 컴파일/테스트 단계들과 관련된 둔화 현상때문에 만성적으로 고심하고 있습니다.
고성능 DevOps 진행에서는 공유 도구를 사용해 협업 프로세스 확립과 간소화를 돕게 되므로 전체 소프트웨어 전달 프로세스에 대해 공통적으로 이해하고 있어야 합니다. 그래야만 일관성 및 자동화 추진을 통해 프로덕션 중에 발생하는 배포나 오류 복구에 더욱 빠르게 즉각 대응하고 시간 낭비를 줄일 수 있습니다. 많은 기업 공급업체들은 이제 지속적인 통합이나 인프라스트럭처 자동화 및 구성 도구를 제공합니다. 그러나 이질적인 솔루션 간의 통합은 주요한 오버헤드를 추가하되 기업의 결산에는 거의 영향을 미치지 않는 복잡한 업무입니다.
왜 DevOps인가?
제품 출시 기간 단축
소프트웨어 중심 세상에서는 고객의 요구를 신속하게 파악해 소프트웨어를 빌드 및 릴리스함으로써 경쟁을 피해가는 것이 성공의 핵심입니다. 현대적 엔터프라이즈 애플리케이션의 분산형 구성 요소의 복잡한 상호 의존성을 고려했을 때 온전하게 DevOps를 구성하면 잘못된 의사소통과 지연을 피하고 개발자와 IT 운영자의 연합된 전문 기술을 통해 능률적으로 소프트웨어를 전달할 수 있습니다. 2016년 DevOps 현황 보고서 (2016 State of DevOps Report)에 따르면 DevOps를 구성한 조직들은 (평균) 200배 이상 배포 회수가 늘어났고, 지연 시간 (코드 배포 의도 시점과 코드 프로덕션 시점 간의 시간차) 처리는 1/2555로 짧아졌습니다. 아래 Gartner의 차트에서 보는 바와 같이 다른 산업 연구 결과에서도 비슷한 결과를 보이는데, DevOps 접근 방식으로 전환했을 때 늘어난 혜택들을 보여줍니다.
낮은 위험과 순조로운 배포
현대적 애플리케이션의 개발, 배포, 크기 조정, 보안, 패치, 고가용성을 조직하고 관리하는 일은 매우 복잡하고 잠재적으로 오류 가능성이 넘쳐나는 일입니다. 협업적 문화와 패키징, 배포, 모니터링, 관리 등에 대한 자동화로 구성된 DevOps 진행은 프로덕션에 새로운 코드와 업데이트 적용하기 위한 일관성과 속도를 제공합니다. DevOps 팀들은 지속적인 학습과 결부해 대부분의 문제 원인을 식별해 제거함으로써 더욱 강력하고, 효율적이며, 반복 가능하고 완벽한 릴리스 프로세스를 구축하고, 나아가 지속적으로 사건사고 없이 소프트웨어를 배포할 수 있습니다.
더욱 빠른 복구
프로덕션 도중 코드가 깨지거나 중단이 발생할 경우 DevOps 진행은 잘 준비된 진단을 수행하여 신속하게 복구에 들어갑니다. 대부분의 릴리스와 관리 프로세스를 작동시키는 훌륭한 자동화와 모니터링 기능 덕분에 DevOps 팀은 신속하게 협업해 오류 원인, 롤백 변경 또는 문제 해결책을 추적하고 확인할 수 있습니다. 실제로 2016년 DevOps 현황 보고서 (2016 State of DevOps Report)에 따르면 DevOps를 사용하는 조직에서는 예상치 못한 프로덕션 문제에 대해 평균 복구 속도보다 24배 빠르게 신속하고 구조적인 반응을 보였고, 변경 오류율은 1/3배 수준 이하를 보였다고 제시되어 있습니다.
고객 만족도 및 제품-시장 적합도 향상
신속하고 신뢰 가능하게 기능을 릴리스하고 버그를 수정하는 것은 높은 반응성과 그에 따른 고객 만족으로 이어질 뿐만아니라 대부분의 고객 관리 성능에 대해 신속한 피드백과 빠른 컨버전스로도 이어집니다. DevOps 진행은 그처럼 지속적인 전달과 빠른 주기 시간의 핵심입니다. 결과적으로 발생하는 복잡성을 관리하기 위해 개발자와 IT 운영자 간의 지속적이고 긴밀한 협업하지 않았다면 일관되고 신속하게 현대적이고 분산형이며 즉시 프로덕션 가능한 소프트웨어 기능을 개발, 테스트, 전달하는 것은 아예 불가능했을 것입니다.
DevOps vs. 기존의 접근 방식
DevOps는 소프트웨어 구성에 다른 사고 방식과 새로운 프로세스를 도입합니다. 아래에는 DevOps를 도입한 조직과 기존의 접근 방식을 유지하는 조직간의 주요 차이점이 일부 설명되어 있습니다.
DevOps 진행
|
기존의 접근 방식
|
---|---|
협업 중심. 성공적인 DevOps는 신속하고 신뢰성있는 소프트웨어의 개발과 전달을 보장하기 위해 개발팀과 IT 운영팀의 성공적이고 지속적인 협업 능력에 의존합니다. | 사일로 중심. 기존의 접근 방식은 협업에 대해서는 “다짜고짜 떠넘기기” 메타포에 의존합니다. IT 운영자는 프로덕션 환경에서 소프트웨어 배포와 관리를 담당하며, 개발팀에는 최소한의 지원이나 인사이트를 제공합니다. |
상당한 수준의 (또는 전체적) 구조화와 자동화. DevOps 진행은 개발 환경에서의 작동이 프로덕션 환경에서의 작동을 보장하는 환경 프로비저닝과 구성에서 속도, 일관성, 반복성을 제공하는 자동화에 의존합니다. 또한 구조적 접근 방식은 오류 복구를 반복 가능한 자동화만큼 빠르게 바꿔주므로 롤백과 복구가 편해집니다. | 눈송이 중심 및 대부분 수동. 기존의 접근 방식은 (“눈송이"처럼 고유한 서버 환경에서) 스크립팅과 수동 프로세스의 즉석 조합에 의존해 인프라스트럭처를 프로비전하고 구성합니다. 이런 방식은 프로젝트를 제대로 수행하거나 신뢰 가능하게 반복하거나 신속하게 진행하기 어렵습니다. 또한 개발 및 프로덕션 인프라스트럭처와 구성 패리티를 신속하고 일관되게 프로비전하는 능력이 없으므로 많은 문제에 봉착하는 경향이 있습니다. |
셀프 서비스 중심. DevOps 중심 조직은 협업 및 자동화 프레임워크를 구축해 개발자와 IT 운영자에게 상대방에게 방해되지 않고 독립적으로 일하도록 자율권을 줍니다. 예를 들어 개발자는 IT 운영자의 직접적인 프로비저닝을 기다리지 않고 신속하게 개발/테스트 환경을 자체적으로 프로비전할 수 있습니다. | "정보 기술 (IT) 티켓" 중심. 기존의 엔터프라이즈 접근 방식에서 IT 운영자는 쉽게 자동화 가능한 IT 티켓 관리 작업을 수행하고 반복적이고 복잡한 수동 프로비저닝과 구성을 진행해야 합니다. 그 결과 프로비저닝, 배포, 크기 조정, 다른 소프트웨어 전달 및 관리 활동이 상당히 복잡해지고 지연됩니다. |
비즈니스 중심. DevOps 조직은 공동으로 비즈니스 성공을 추진하는데 집중합니다. 그러므로 소프트웨어 전달 성공에 대한 책임도 공동으로 집니다. | 기능 중심. 기존의 접근 방식은 개발자와 IT 운영자가 그들 기능에 집중하되 전체적인 성공에 대해서는 별다른 책임을 부여하지 않았습니다. 그 결과 문제와 오류가 발생해 수많은 비난을 받고 조직내에서 마찰이 발생합니다. |
변경 맞춤형. DevOps 진행은 신속하고 반복 가능하게 자동화하도록 디자인됩니다. 신속한 오류 복구뿐만 아니라 신속한 변경 처리도 수행하게 빌드됩니다. 신속하게 진행하기 위해 빌드되는 것입니다. | 변경 반대. 기존의 접근 방식에서는 손댔다가 빨리 복구할 수 없게 될까봐 프로덕션 배포를 변경하지 않습니다. 전통적인 접근 방식에서는 변경과 업데이트를 최소화하고 조직에게는 천천히 진행할 것을 간접적으로 권장합니다. |
[DevOps] 고려 시 염두에 두십시오.
DevOps는 문화, 프로세스, 도구를 결합해 소프트웨어 전달 주기를 향상시키는 새로운 접근 방식을 지지합니다. 시작하기는 너무 버거울 수 있으므로 여기서는 DevOps 진행을 통한 사고와 기획을 도울 일부 우수 사례들을 살펴봅시다.
여러분이 가진 근본적 요구 사항을 확실히 정하십시오. DevOps 진행은 조직의 구조, 팀 인센티브, 현행 소프트웨어 수명 주기, 지연 원인, 자동화 기회 등을 모두 고려한 끝에 조직의 고유한 요구 사항을 충족시키도록 구조화되어야 합니다.
자동화와 새로운 프로세스에 투자하십시오. “현대적인 서비스 제공에는 지속적인 자동화가 뒷받침되어야 합니다.” [출처: Forrester Brief: 우수한 DevOps에 필요한 것: 협업, 자동화, 문화적 변화 (Good DevOps Requires Collaboration, Automation, And Cultural Change); 2016년 6월]. 대체로 DevOps는 자동화 도구를 통해 향상됩니다. 대부분의 경우 완전히 새로 적용되는 자동화 과정은 성공적인 DevOps가 필수 전제입니다. 협업, 신규 프로세스 구축, 새로운 도구 사용 관련 팀 교육 훈련은 투자할 가치가 있습니다.
리서치업체인 Forrester가 제출한 상기 보고서에 따르면 조사에 참여한 I&O 전문가 82%는 릴리스 관리, 구성 관리, 변경 관리 중 최소 한 군데 이상에 자동화 솔루션을 구성하는 중이라고 응답했습니다.
팀 구성과 문화적 사안에 대한 현실을 인식하십시오. 개발자와 IT 운영팀 간의 인센티브와 목표를 잘 배열해 협업의 신뢰와 정신을 구축하는 것은 매우 중요합니다. 예를 들어 단일 프로젝트에 직원을 제공하도록 조정되어 적극적으로 협업하고 있어서 모든 측면에서 종합적으로 성공적이라 평가되는 팀인 경우 기능적 책임과 (안정성 유지나 신속한 기능 전달과 같은) 인센티브는 공유하되 성공적으로 소유하는 것이 없는 개발자, 운영자 또는 양팀 동시 구성 팀보다 협업에 효과적으로 몰입했습니다. 구입하기는 쉽겠지만 도구만으로는 DevOps 진행 혜택이 보장되지 않습니다. DevOps는 협업과 공동 책임에 기반한 문화 철학의 맥락에서 사용되어야 합니다.
조직의 역학을 이해하는 것은 방해가 될 수 있습니다. 새로운 프로세스와 도구가 적용되면 현행의 프로세스는 파괴되며, 기존의 조직 권한, 특히 준수, 보안, 감사 기능에 대한 위협은 불가피합니다. 이러한 부문에서 좀더 거시적인 비전을 가지고 적극적으로 나서 주는 것이 매우 중요합니다. 그렇지 않으면 선의로 단순화한 DevOps 진행이 인위적인 지연으로 시달리게 됩니다. 하향식 실행을 지원하고 다중 구성 팀을 투입하면 이처럼 복잡한 조직 역학을 꿰뚫는데 도움이 될 수 있습니다. 사실 2015년 Gartner 연구 조사 응답자 가운데 절반 이상이 조직이 DevOps 사용에 가장 큰 문제로 인사를 꼽았습니다.
통합 오버헤드와 복잡성 문제를 인식하십시오. 솔루션 공급업체의 수를 고려했을 때 디자인 단계에 있는 전체 DevOps 진행의 각 측면에 대해 문제의 여지가 있는 솔루션을 구입하기 쉽상입니다. 이 경우 무난하게 사용기 위해 기업들이 다른 도구를 통합하려 들면서 중대한 오버헤드와 복잡성이 야기될 수 있습니다. 최적 진행 사례에 근거해 강력한 의견을 제시하고, 애플리케이션 런타임 플랫폼과 통합하고, 동시에 조직의 고유한 요구에 자동화 특성까지 제공하는 괄목할만 한 유연성을 제공하십시오. 이렇게 단일화된 접근 방식만이 위험에서 벗어나 강력한 기반에서 시작하는 것을 도울 수 있습니다.
작게 시작하십시오. DevOps를 진행할 때 실험과 미세 조정이 필요할지도 모릅니다. 작게 시작하는 것이 합리적입니다. 의미있는 결과를 유도하려면 너무 큰 규모이거나 결과가 매우 중요한 핵심 비즈니스를 수행하지는 않는 실제 애플리케이션으로 시작하십시오.
기존의 작업을 고려하십시오. DevOps는 새로운 작업만을 대상으로하는 것이 아닙니다. 팀들은 기존 작업의 현대화와 통합을 고려하므로 DevOps 원칙과 자동화를 수명 주기에 적용해 넣을 방법을 고려하십시오. 기존 작업은 릴리스 주기와 배포 신뢰성/안정성 측면에서 DevOps로부터 상당한 혜택을 얻을 수도 있습니다.
DevOps는 일종의 여행입니다. DevOps는 진행 철학입니다. 팀과 진행이 정해지면 정적인 상태를 유지할 수 없다는 점을 기억하십시오. 작업, 요구 사항, 운영 환경이 전환되므로 소프트웨어를 신속하고 신뢰 가능하게 전달하기 위한 DevOps의 존재 이유를 지속적으로 충족시키고자 끊임없이 성장/진화해야 합니다.