DevOps 텍스트 교육
DevOps란 무엇인가요?
DevOps는 소프트웨어를 개발하고 제공하고 운영하는 프로세스입니다. 말은 간단해도 DevOps가 실제로 무엇인지 이해하는 일을 가볍게 여겨서는 안 됩니다. 책과 인터넷에는 자신의 이해관계를 반영하거나, 기껏해야 불완전하고 혼란스러운 정의가 많습니다.
일부 상업적인 정의는 DevOps를 특정 빌드 및 제공 도구 또는 클라우드 인프라 플랫폼과 강하게 결부합니다. 도구와 플랫폼이 DevOps로 IT 및 조직 목표를 달성하는 데 큰 도움이 될 수는 있습니다. 그렇지만 직접 작성하지 않아 통제하기 어려운 도구를 하나 더 연결하거나 소프트웨어를 클라우드 플랫폼으로 옮긴 뒤, 이제 조직이 DevOps로 제공한다고 선언할 수는 없습니다. 잘 알려지지 않은 옛말을 빌리면 까마귀도 웃을 일입니다.
조금 낫지만 여전히 오해를 부르는 정의도 있습니다. DevOps를 IT 조직의 업무와 인력이 교차하는 지점으로 보고, 소프트웨어 개발자, 테스터, 프로덕션 운영 엔지니어를 한데 모으는 방식으로 설명합니다. 이 책을 끝까지 읽으면 이 정의가 얼마나 피상적인지 느끼실 것입니다.
DevOps를 정의하는 가장 좋은 방법은 Scrum, 린, ITIL, IDEAL(시작, 정의, 수립, 실행, 학습), Six Sigma DMAIC(정의, 측정, 분석, 개선, 관리) 같은 반복적 애자일 소프트웨어 개발 및 프로세스 개선 프레임워크와 비교해 보는 것입니다.
애자일 Scrum, 린, ITIL, IDEAL, Six Sigma DMAIC가 DevOps를 효과적으로 지원할 수는 있습니다. 다만 DevOps는 이 방법론과 기법을 하나로 합쳐 개선한 상위 개념이 아닙니다. 이유는 간단합니다. 애자일 Scrum을 제외하면 어느 것도 소프트웨어 산업의 문제를 해결하거나 그 산업에 기여할 목적으로 도입되지 않았기 때문입니다.
DevOps 실무와 원칙 상당수는 린 운동에서 나왔으며, 소프트웨어 개발, 제공, 운영에 맞게 조정하고 실험하며 검증하고 다듬었습니다. 또한 지속적 제공 운동, Toyota Improvement Kata, 제약 이론, 애자일 선언 및 애자일 인프라의 여러 기법과 철학을 도입해 적용했습니다.
린 운동:
린 운동은 일곱 가지 원칙으로 요약할 수 있습니다.
- 전체를 보고 시스템 사고를 통해 고객 가치를 창출합니다.
- 품질을 내장하고 흐름을 만들며, 밀어내는 방식 대신 당겨오는 방식을 사용합니다.
- 가능한 한 빠르게 제공합니다. 원자재를 완제품으로 바꾸는 리드 타임, 소프트웨어에서는 아이디어를 프로덕션 시스템에서 작동하는 기능과 실제 혜택으로 바꾸는 리드 타임을 줄입니다.
- 학습을 확대하고 과학적 사고를 받아들입니다.
- 팀에 권한을 주고 겸손하게 이끌며 한 사람 한 사람을 존중합니다.
- 도구, 시스템, 특히 비생산적 활동에 쓸 수 있는 시간의 낭비를 없앱니다.
- 결정을 가능한 한 늦춥니다. 필요한 때 적시에 결정합니다.
지속적 제공 운동:
배포 파이프라인으로 지속적 제공을 구현합니다. 파이프라인에는 가시성, 피드백, 지속적 배포라는 세 가지 중요한 역할이 있습니다.
- 가시성 — 빌드, 배포, 테스트, 릴리스 등 제공 시스템의 모든 측면을 본인과 다른 팀의 모든 구성원이 볼 수 있게 합니다. 이렇게 하면 팀의 협력이 늘고 고객과 이해관계자에게 투명성이 생깁니다.
- 피드백 — 본인과 팀원은 문제가 발생하는 즉시 알게 됩니다. 이미 무너진 구조에 벽돌을 더 쌓기 전에 문제를 빠르게 해결할 수 있습니다.
- 지속적 배포 — 완전히 자동화된 프로세스로 소프트웨어의 어느 버전이든 테스트 및 프로덕션을 포함한 모든 환경에 배포하고 릴리스합니다.
Toyota Improvement Kata:
Toyota Improvement Kata를 일상적인 절차로 사용해 현재 상태에서 새로운 상태로 창의적이고 방향성 있게, 의미 있는 방식으로 나아갑니다. 네 부분으로 이루어진 모델입니다.
- 더 큰 비전이나 나은 방향을 염두에 둡니다…
- 현재 상태를 파악합니다.
- 다음 목표 상태를 정의합니다.
- 끝으로 목표 상태에 다가가도록 지속적으로 반복해 시도합니다. 과정에서 해결할 장애물을 발견하고 이를 정리합니다.
다른 개선 방식에서는 경로를 예측하고 구현에 집중했다면, Toyota Improvement Kata는 과정에서 발견한 사실로부터 배우고 그 위에 다음 단계를 쌓습니다. 본인과 팀은 목표 상태에 이르려 노력하면서 배우고, 배운 내용에 맞게 적응합니다.
제약 이론:
소프트웨어를 제공하는 조직이라면 어디든, 여러분의 조직도 마찬가지로 IT와 비즈니스 사이에 갈등이 계속됩니다. 사업 요구에 빠르게 대응하면서도 안정적이고 예측 가능한 프로덕션 환경을 확보하는 것은 IT가 계속 해결해야 하는 절충 과제입니다. 위험이 전혀 없는 프로덕션 릴리스는 없다는 점을 이미 알고 계실 것입니다. 복잡한 시스템에서는 낮은 위험을 보장하려면 충분히 빨리 릴리스하기 어렵고, 프로덕션에 빨리 릴리스하려면 낮은 위험을 보장하기 어렵습니다.
다음과 같은 방식으로 이 갈등에 대처할 수 있습니다.
- IT 조직을 작고 자율적이고 독립적이며 자립할 수 있고 서로 긴밀히 협력하는 여러 팀으로 나눕니다. 팀을 사명을 가진 ‘지적인 단위’로 보기 시작해야 합니다.
- 각 팀에 배정하는 배치 크기, 즉 진행 중인 작업량을 줄입니다.
- 리드 타임을 줄입니다. 이는 아이디어와 요구사항을 프로덕션 시스템에서 작동하는 기능과 실제 혜택으로 바꾸는 시간입니다.
- 더 빠르고 신뢰할 수 있는 지속적 피드백 루프를 만들어 배포 준비 상태를 확보합니다.
애자일 선언:
DevOps에서는 애자일 선언의 핵심 가치를 따릅니다.
- 프로세스와 도구보다 개인과 상호작용을 더 중요하게 여깁니다.
- 포괄적인 문서보다 작동하는 소프트웨어를 더 중요하게 여깁니다.
- 계약 조건과 협상보다 고객과의 협력을 더 중요하게 여깁니다.
- 계획을 따르는 것보다 변화에 대응하는 것을 더 중요하게 여깁니다.
애자일 인프라:
규모에 관계없이 많은 조직이 퍼블릭 및 프라이빗 클라우드에 전용 서버를 결합한 하이브리드 클라우드 인프라에 의존합니다. 여러분의 조직도 그럴 수 있습니다. 코로케이션 시설의 보안과 퍼블릭 클라우드의 유연성 및 확장성을 함께 누릴 수 있습니다.
애자일 인프라가 DevOps에 유익한 주요 이유는 다음과 같습니다.
- 투명하고 단순한 가격 책정에 따라 사용한 만큼 지불합니다.
- 코드베이스에서 테스트 및 프로덕션 환경을 신속하게 프로비저닝하거나 해제할 수 있습니다(IaC, 코드형 인프라).
- 아키텍처가 유연합니다.
- 다른 지역으로 쉽게 확장할 수 있습니다.
- 보안이 더 나을 가능성이 있습니다.
- 감사나 추가 비용 없이 규정을 준수합니다.
결론
이 절에서는 무엇이 DevOps이고 무엇이 아닌지 설명하고, DevOps의 토대가 된 주요 운동과 원칙도 살펴봤습니다.
한 가지 주의할 점이 있습니다. 많은 애자일 실무자가 수년간 안타깝게도 그랬듯, 고정불변의 DevOps 정의에 매달려 조직, 제품, 서비스, 무엇보다 팀에 DevOps 사용 방식을 강요해서는 안 됩니다. 애자일에도 DevOps에도 모두에게 통하는 단일 해법은 없습니다.
핵심은 학습, 실험, 적응임을 잊지 마세요. DevOps는 많은 도움을 줄 수 있지만, 우리에게 맞는 방식과 수준을 찾아내는 것은 사람의 가장 큰 책임입니다. Google, Amazon, Facebook, Netflix, Apple을 포함해 성공한 DevOps 조직은 모두 그렇게 해 왔습니다.
