DevOps 조직 체제에는 다양한 종류가 있으며, 형태 또한 하나가 아닙니다. DevOps를 도입하는 Goal과 이미지를 갖기 위해서는 Bottom-Up 방식의 접근법 또는 Top-Down 방식의 접근법과 관계없이 어떤 작업을 할 것인지, 이를 위해 어떤 조직이 구성되어야 하는지를 생각해야 합니다. DevOps 도입 후 조직 구성에 대한 사례 연구를 통해 배우고 자신의 조직에 맞는 형태로 바꿀 수 있도록 준비해야 합니다.
프로비저닝 도구인 Puppet의 블로그 포스트에는 ‘What’s the Best Team Structure for DevOps Success?(DevOps의 성공을 위한 최고의 팀이란 무엇인가?)’라는 주제로 다음과 같은 DevOps 체제가 3개로 분류되어 소개되고 있습니다.
• Type 1 : Close-Knit Collaboration Between Dev & Ops
• Type 2 : Dedicated DevOps Team
• Type 3 : Cross-functional teams
Type 1부터 설명하면 다음과 같습니다.
Type 1 : Close-Knit Collaboration Between Dev & Ops
Close-Knit는 “단단히 결합되어 있다”라는 뜻입니다. 개발 및 운용을 단단히 묶어 높은 수준의 협력 체제를 구축할 수 있도록 개발 및 운용 팀을 재구성한 것을 소개하고 있습니다. 개발은 개발, 운용은 운용을 담당하지만, 이 협력적인 체제를 통해 조직이 필요로 하는 소프트웨어 기술과 깊은 시스템의 이해를 최대한 혼합하는 것이 가능합니다.
체제를 유지함으로써 응용 프로그램 개발이 가능하고 인프라에 응용 프로그램을 실행시키기 위해 필요한 최소한의 지식이 있는, 스타트업에는 없어서는 안 될 인재를 발굴할 수 있습니다. 이 조직 구성에서는 초기 계획(planning)에서 제품(Production) 출시(Release)까지의 라이프 사이클에 개발과 운용 각각의 팀이 포함되기 때문에 예를 들어, 개발을 하는 사람이 프로덕션에서 서비스가 작동하는 것을 의식하게 되고 이것으로 인해 개발·운용의 입장에서 “우리 일이 아니다”라는 인식이 없어져 갑니다.
Type 2 : Dedicated DevOps Team
Dedicated는 “전문”이라는 뜻으로, Dedicated DevOps Team은 이 책에서 소개하고 있는 도구와 기법에 대한 지식을 가진 엔지니어를 모아 처음부터 전문 DevOps 팀을 편성하여 인프라를 코드로 작성하고 지속적 통합을 이루어 버전 관리를 하는 팀을 말합니다.
이 책의 내용들을 익히고 모두 실습한 인재가 모여 만든 조직, DevOps 도구의 배경을 알고 자동화에 임하여 더욱 간소화하는 것을 목표로 하는 뛰어난 팀이라고 할 수 있습니다.
최근 트렌드로써 Web 업체에서는 위와 같은 DevOps 인재를 모으고 DevOps라는 팀 자체를 만드는 움직임이 있습니다.
Type 3 : Cross-functional teams
Cross-functional은 “교차 기능”을 의미하며, 상품의 기획부터 Release까지 모든 공정에서 각 전문 대표자를 모아 팀을 구성하는 방식입니다. 애자일 개발의 경우는 개발 체제로써 제품 소유자(Production Owner)부터 테스터까지 포함하여 최소 한 명씩 참석한 팀으로 구성됩니다. 이와 마찬가지로 비즈니스 기획·설계·개발·테스터·운용 등의 대표자가 참가하여 팀을 구성합니다.
이러한 Cross-functional 팀은 각 프로세스 간 전달 오버헤드 및 의견의 상충이 적고 담당을 넘은 지식의 공유도 뛰어나 보다 효과적인 성과를 거둘 수 있습니다. 개발·운용하는 틀이 확실히 규정되어 있는 것은 아니기 때문에 속도감 있는 사업에 만능인 최적의 솔루션으로도 보이지만 서비스·제품의 규모에 따라 팀이 커지고 컨트롤이 어렵기 때문에 일률적으로 우수한 조직 구성이라고는 할 수 없습니다.
기존 조직을 바꾸지 않고 도입하는 방식
앞서 3개의 조직 체계에 대해서 알아보았습니다. 사실 조직적인 구성 자체는 DevOps화를 가속화할 수 있지만, 그것이 전부인 것은 아닙니다. 임시적인 팀 구성과 기술적인 해결책에 의해 진정한 DevOps화를 만들어 낼 수 있습니다.
DevOps 도구는 Infrastructure as Code의 개념으로 인프라의 모든 것을 코드화하려는 흐름이 있는데, 이 덕택에 운용팀/개발팀 체제는 그대로일 수 있습니다. 예를 들어 운용팀에서 운영하는 인프라에 Infrastructure as Code로 자유롭게 사용할 수 있는 인프라를 정비하고, 사용자 매뉴얼을 만들어 개발팀에 공개하는 것을 생각해 봅시다.
도입 후 운용 측면에서 볼 때 개발 쪽을 돌보는 기회는 줄어들고, 개발 측면에서 볼 때도 운용 측에 부탁하는 오버헤드 또한 줄어듭니다. 게다가 선택은 증가하고 단숨에 시스템 개발 및 운용을 간소화할 수 있게 됩니다. 이것은 체제나 조직의 변화라기보다는 단순한 방식의 변혁으로 DevOps를 실현하는 것입니다. 이처럼 Dev와 Ops, 양쪽의 커뮤니케이션 인터페이스를 도구에 의지하는 것은 유효한 수단입니다. 무언가 문제가 되는 인프라와 개발의 범위는 AWS 및 OpenStack 같은 IaaS API를 경계로 하여 구성 관리 도구 사용을 허용할 수 있는 환경을 만들고 기술적인 해결책도 생각해 나갑니다.
소규모의 DevOps 전담 팀이 개발팀과 운용팀 전반에 활약하는 체제를 만드는 방식도 생각할 수 있습니다. 개발·운용 각각의 전문가가 상담하는 대상을 DevOps 전담팀에 맡기고 전담팀은 인프라 코드를 통한 구성 관리·Deploy 자동화·지속적 통합 세팅·모니터링의 정비 등에 주력하는 방식입니다. DevOps 전담팀은 임시로 만들어지기 때문에 출시 완료와 동시에 해산하더라도, 각 팀에서 상담했던 사람에게 DevOps의 노하우가 남아 있기 때문에 체제의 변경 없이 도입이 진행될 수 있습니다.
《IT 운용 체제 변화를 위한 데브옵스》
'IT 정보' 카테고리의 다른 글
| 인공지능 수학 공부, 꼭 알아야 할 극한과 미분편! (0) | 2021.02.01 |
|---|---|
| AI에 필요한 수학을 공부하고 싶다면? 이 책을 꼭 읽어보세요! (0) | 2021.01.19 |
| DevOps의 도입 실패했나요? Anti-pattern에 빠져있는건 아닌지 확인해보세요! (0) | 2021.01.08 |
