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

공유

DevOps란?

DevOps는 Lean 사고 및 Agile 개발과 함께 시작된 확장된 범위의 애플리케이션과 일련의 움직임이 정점을 이루어 표현된 것으로서, 궁극적으로는 신속하게 고성능 소프트웨어를 제공하는 것이 목적입니다. 일반적으로 Agile 개발은 소프트웨어 엔지니어가 중심 역할을 맡으며, 빠르고 점증적인 소프트웨어 개발에 집중합니다. 클라우드 시대의 소프트웨어는 (직접 설치되는 방식이 아니라) 하나의 서비스로 소비되는 추세입니다. 소프트웨어는 더 이상 전달 대상이 아니라 프로덕션 환경에서 실제 사용되는 대상입니다. Agile 철학을 유지하되 소프트웨어 기능의 지속적이고 점증적이며 신속한 제공을 강화하는 추세입니다. 따라서 Agile에는 필연적으로 코드 완성에서 프로덕션 지원 (예를 들어 빌드, 테스트, 프로비저닝, 구성, 배포, 지속적인 관리)에 이르는 소프트웨어 변환 활동을 아우르는 운영 측면의 속도와 품질이 확장 포함되어 왔습니다. 이처럼 빠르게 소프트웨어를 전달하려면 개발자 (Dev)와 IT 운영자 (Ops) 쌍방이 공동으로 협업해야 합니다.

DevOps 이동은 이러한 요구를 인정하고 그에 부응하는 것입니다. 그러므로 DevOps는 유연하며, 더 높은 수준의 협업, 의사 소통, 공동 책임을 통해 제품 개발측 (개발자 및 QA)과 IT 운영측 간에 존재했던 수많은 기존의 전달 갈등과 지연을 상당 부분 방지함으로써 소프트웨어의 성공적인 전달을 추구합니다.


Devops Cartoon

역사적 맥락

DevOps는 기존의 엔터프라이즈 소프트웨어 전달 사고 방식과 뚜렷하게 대비됩니다. 일반적으로 별개의 소프트웨어 개발 및 IT 운영 조직들이 구성되어 독립적으로 일하는 대부분의 기업에서는 개발자와 IT 운영자가 단절하게 되고 신속하게 소프트웨어를 전달하기 어려운 상황에 놓입니다. 예를 들어 대부분의 기업 개발자들은 (IT Ops의 통제를 받도록) 구성된 인프라스트럭처를 쉽게 프로비저닝할 수 없고, 그러므로 반복 가능하고 표준화된 환경을 제시할 수 없습니다. 결과적으로 개발자들은 효율적으로 개발하고 테스트할 수 있도록 특별하게 구성된 개별 환경에서 담당 코드 부분만 개발하고 끝내게 됩니다. 그러면 해당 코드는 (다양한 환경의 여러 개발자들이 개발하고 테스트한) 다양한 소프트웨어 아티팩트를 다루는 IT 운영자에게 전달되어 고가용성, 확장성, 보안 등 바람직한 엔터프라이즈 특성을 가진 실행 중인 애플리케이션 배포판에 적용됩니다.
View More

이런 경우는 대체로 개발팀에서 지원해주지 않을 경우 IT 운영자에게는 복잡하고, 손이 많이 가고, 느리고, 오류 발생이 잦은 프로세스입니다. 소프트웨어 배포 시에 발생하는 문제들은 보통 당사자들 간의 마찰과 불신으로 이어집니다. 이 경우 현대적이고 지속적인 제품 제공 환경은 악화됩니다. 개발자들은 기능을 빠르게 구현하라는 압박을 받는 반면 IT 운영자들은 안정성 확보에 대한 압박을 받습니다. 현실적으로 (현대식 자동화 프로세스를 거치지 않고) 양쪽의 요구사항을 모두 구현할 유일한 방법은 변경을 제한하는 것 뿐입니다.


기본 요소

DevOps 진행 방식에는 특별한 규범이 있지는 않습니다. 하지만 성공적으로 우수한 기능을 보이는 DevOps 진행들은 몇 가지 공통된 특징들을 나타내고 조직의 문화, 프로세스, 도구에 영향을 미칩니다.

문화

공동 성공, 협업, 공동 책임을 가치있게 여기는 문화는 성공적인 DevOps 진행에 스며듭니다. 개발자들과 IT 전문가들은 공동으로 성공적인 애플리케이션 전달을 책임집니다. 이는 조직적 변화를 통해서 가능합니다. 예를 들어 서비스를 빌드/실행하는 개발 및 운영 직원을 함께 배치하기 위해 직원을 프로젝트에 매트릭스화하고 거기에 전담시키는 기능적 사일로가 있습니다.
View More

또한 DevOps는 서로의 역할을 더 잘 이해함으로써 상대방과 편하게 협조하고 효과적으로 협업해 업무를 조정할 수 있도록 공감을 강조하고 개발자와 IT 운영자들을 격려합니다. 예를 들어 개발자들은 프로덕션 배포 환경을 이해하면 잠재적인 운영 오류와 관련 디자인 문제를 더 잘 이해하게 됩니다. 반대로 IT 운영자들은 애플리케이션 디자인과 목적을 더 잘 이해하여 배포 구성 최적화를 도울 수 있습니다.

성공적으로 DevOps를 진행하면 잘못 조정된 정책들 (예를 들어 개발자들에게는 신속한 기능의 배포를, IT 운영자들에게는 프로덕션 배포 변경을 최소화를 장려하는 것)로 인한 잠재적인 마찰 원인들을 적극적으로 제거할 수 있습니다.

프로세스

실제 DevOps 문화를 뿌리내리려면 개발자와 IT 운영자가 만나 의견을 나누고 신속하고 구조적 소프트웨어 전달과 오류 복구에 필요한 전문 지식과 명확한 협업 프레임워크를 공유하는 공동의 프로세스를 거쳐야 합니다. 예를 들어 관련 프레임워크를 통해 개발자가 API 용량을 프로비저닝하고 IT 운영자는 이를 구현 및 지원할 의무를 지정할 수 있습니다. 또는 API가 개발, 테스트 또는 프로덕션 환경을 구분하지 않음으로써 지연과 문제 발생의 원인인 환경적 패리티 이슈를 제거하도록 합의/계약할 수도 있습니다.

공동 프로세스의 다른 사례로는 공동 개발된 스크립트로 현행 유지되는 소프트웨어 종속성에 대한 중앙 저장소 합의 및 사용이 있습니다. 시간이 지나면서 그와 같은 협업은 학습, 반복 개선, 프로덕션에 대해 반복 가능하되 중단 위험이 없는 점증적이고 빈번한 소프트웨어 변경 적용 능력을 일궈 냈습니다.

자동화 및 공유 도구

신속하고 신뢰 가능한 소프트웨어 전달에는 불필요한 직접 개입을 배제하도록 간소화된 프로세스 일관성과 반복성이 요구됩니다. 예를 들어 기업에서는 일상적으로 용량 할당, 개발 및 프로덕션 환경 간의 격차, 복잡한 수동 컴파일/테스트 단계들과 관련된 둔화 현상때문에 만성적으로 고심하고 있습니다.

고성능 DevOps 진행에서는 공유 도구를 사용해 협업 프로세스 확립과 간소화를 돕게 되므로 전체 소프트웨어 전달 프로세스에 대해 공통적으로 이해하고 있어야 합니다. 그래야만 일관성 및 자동화 추진을 통해 프로덕션 중에 발생하는 배포나 오류 복구에 더욱 빠르게 즉각 대응하고 시간 낭비를 줄일 수 있습니다. 많은 기업 공급업체들은 이제 지속적인 통합이나 인프라스트럭처 자동화 및 구성 도구를 제공합니다. 그러나 이질적인 솔루션 간의 통합은 주요한 오버헤드를 추가하되 기업의 결산에는 거의 영향을 미치지 않는 복잡한 업무입니다.




“이제 DevOps는 확실히 주류로 자리 잡았습니다... 더 이상 DevOps는 가지고 있으면 좋다거나 차별화 요소 수준이 아니라 효과적인 시장 경쟁력을 갖추기 위해 필수적인 요소입니다.”

Ovum Research; Changes Within and Driven by DevOps; June 2016




Next Section
Why DevOps?