[테크월드=배유미 기자] 개발과 IT 운영 간 원활한 협업은 이상적인 일이다. 이 두 팀 간의 사일로(Silo) 현상을 없애고, 보다 신속하게 소프트웨어를 구현, 테스트, 배포할 수 있도록 설계된 것이 데브옵스(DevOps)다. 하지만 데브옵스는 이 같은 철학과 단어가 표명하는 것보다 더 많은 의미를 내포하고 있으며, 구조를 구성하는 요소들도 더욱 깊고 포괄적이다. 소프트웨어 구조가 개발 조직의 커뮤니케이션 구조를 닮게 된다는, 콘웨이의 법칙(Conway’s Law)을 생각하면 좋을 것이다.
이상적인 협업을 돕는 데브옵스. 그렇다면, 이상적인 데브옵스 팀의 구조는 무엇일까? 몇 가지 고려해야 할 사항이 있다. 기존 구조가 제대로 작동하는지 확인할 수 있는 유일한 방법은 개발(Dev)과 운영(Ops) 팀이 협력하고 있는지, 그리고 비즈니스 목표를 달성 또는 초과하는지를 보고 느낌적으로만 알 수 있을 뿐이다. 기준은 각 회사마다 조금씩 다르기 때문에, 각기 다른 모델을 분석하는 것이 도움이 된다. 각 장단점을 살펴보고, 콘웨이의 법칙을 고려해 해당 팀에 가장 적합한 것을 찾아보자.
대표적으로 팀 구조에 영향을 미치는 요소는 ▲기존의 사일로 ▲기술 리더십 ▲IT 운영 ▲지식 격차다.
사일로 이해하기
팀 토폴로지스(Team Topologies) 공동 저자 매튜 스켈턴(Matthew Skelton)은 데브옵스 시나리오 중에서도 몇 가지 사일로 유형과 이에 따라 조직에 미치는 영향에 대해 설명했다.
▲ 완전히 분리된 개발과 운영 팀
스켈턴은 이를 전통적으로 ‘사전 협의 없이 다른 부서로 프로젝트를 넘겨주는(throw it over the wall)’ 팀 구조로 간주하고 있으며, 이는 가장 효과적인 데브옵스 전략이 아니라고 언급하고 있다. 두 팀은 모두 거품이 있는 상태로 일하고 있으며, 다른 팀의 작업 플로우에 대한 이해가 부족하다. 이처럼 완전히 분리된 구조는 협업, 가시성, 이해가 결여될 수밖에 없다. 결과적으로 그들은 서로 무엇을 하는지 알지 못하고, 각자에게 책임을 떠넘기며 상호 비난하는 패턴이 드러나게 될 것이다.
콘웨이의 법칙으로 다시 돌아가면, 의사소통이 원활하지 않은 조직은 같은 문제에 봉착하는 구조를 만들게 된다. 이는 좋은 데브옵스라 할 수 없다.
▲ 데브옵스 중재자가 존재하는 경우
이러한 팀 구조는 여전히 개발과 운영 팀이 분리되어 있지만, 일종의 촉진자 역할을 하는 ‘데브옵스’ 팀을 중간에 배치할 수 있다. 스켈턴은 “이는 반드시 나쁜 것은 아니다”라며, “향후 보다 응집된 개발이나 운영 팀을 만드는 것을 목표로 이를 임시 솔루션으로 사용한다면, 좋은 중간 전략이 될 수 있다”며 이와 같은 방식을 적용한 일부 사례들도 언급했다.
▲ 분리된 운영 팀
이 시나리오에서 개발 팀과 데브옵스는 서로 융합되어 있지만 운영 팀은 여전히 사일로 상태에 있다. 이와 같은 조직은 여전히 운영 팀을 그 자체의 가치를 보지 않고, 소프트웨어 개발 계획을 지원하는 팀으로 간주하고 있다. 이러한 조직은 기본적인 운영상의 실수를 겪게 된다. 따라서 운영 팀의 가치를 이해하고 기여할 수 있도록 한다면 훨씬 더 성공적일 수 있다.
리더십의 중요성
데브옵스 구조 개선을 위해서는 의사소통이 매우 중요하다. 이를 위해서는 큰 변화가 필요하다. 또한, 이에 따른 변화와 문제를 극복할 수 있는 핵심 열쇠는 ‘리더십’이 쥐고 있다.
조직의 변화를 도모하는 것은 상당히 어려운 작업이다. 회사 전체가 이를 받아들여야 하고, 많은 부서들이 이러한 조치 과정에 동의해야 한다. 특히나 애초에 의사소통이 잘 되지 않는 조직이라면, 가장 이상적인 시나리오라 하더라도 변화하기는 쉽지 않다.
가장 큰 실패 예측 변수는 ▲변화에 대한 저항 ▲변화에 대한 준비 부족 ▲직원들의 저조한 참여도 등이 있을 것이다. 이 때 혁신적인 리더십은 팀 구성원이 데브옵스 변화에 대해 프로세스와 기술, 역할, 사고방식 등 다방면에서 대응하도록 직접적인 영향을 미친다.
한 예시로, 오픈 소스 소프트웨어 형상 관리 도구인 퍼핏(Puppet) 팀은 특정 역할과 기능을 규정할 때, 몇 가지 사항을 권장한다. 먼저, IT 매니저는 다른 팀의 상대방과 신뢰를 구축하고, 지속적인 개발과 학습 환경을 조성하고, 팀원들에게 권한을 위임하도록 한다. 개발 매니저는 운영 팀과 신뢰를 구축하고, 계획 단계의 초기에 운영 팀을 참여시키며, 시스템 엔지니어는 수동으로 진행되던 어려운 작업들을 자동화하도록 한다. 또한, 품질 엔지니어는 규모와 성능, 그리고 스테이징 환경에 대한 의견을 제시한다. 마지막으로 개발자는 운영 팀의 피드백을 기반으로 새로운 기능에 대한 배포 계획을 수립하고, 배포 프로세스에서 운영 팀과 협력한다.
운영 팀의 참여유도
운영은 자체 방법론을 갖춘 전문분야다. 최신 클라우드 호스팅을 통해 SCSI(주변 기기를 컴퓨터에 연결할 때, 직렬 방식으로 연결하기 위한 표준) 케이블 전반에 대한 지식이 없어도 보다 쉽게 서버를 배포할 수 있게 됐다고 해서 모든 사람들이 운영 마스터가 되는 것은 아니다. 운영 팀이 SDLC(데이터 링크 프로토콜의 일종)에 제공하는 것은 신뢰성, 보안, 안정성이다. 개발 팀은 자신의 기술을 이용해 프로세스를 자동화하고 생산 환경을 지원할 수 있으며, 진정한 데브옵스는 이런 각각의 강점을 활용하는 것이다.
데브옵스는 개발자가 생산을 관리한다는 의미가 아니다. 가용성을 강조하는 운영 팀과 기능 배포에 중점을 두는 개발 팀은 매우 다른 방식으로 인센티브가 주어지기 때문에 개발팀과 운영 팀은 서로 충돌할 수 있다. 가용성은 주의가 필요하고, 신중함은 속도와 대치될 수 있기 때문에 두 팀은 서로 배우고, 상대방의 경험을 통해 이익을 얻을 수 있다. 기억해야 할 점은, SDLC에서 운영 팀은 장벽이 아니라 동맹이다.
차이 인식의 필요성
보다 효율적인 데브옵스 팀을 구성하기 위해 현재 필요한 것은 무엇일까? 콘웨이의 법칙으로 다시 돌아가면, 현재 팀의 의사소통이 어떻게 이뤄지고 있는지 분석하고, 보다 나은 방법과 원하는 것을 객관적으로 생각하는 것이 중요하다.
조직은 목표를 달성하기 위해 새로운 구조를 받아들이고, 새롭게 개발한 조직적 구조와 소프트웨어 간의 연결을 이해해야 한다. 예를 들어, 넷플릭스(Netflix)와 아마존(Amazon)은 여러 소규모 팀을 중심으로 구성돼 있으며, 각 팀은 시스템의 작은 영역에서 자율적으로 기능한다. 보다 획일적인 코드베이스 기반의 팀은 이런 방식으로 운영될 수 없으며, 넷플릭스의 데브옵스 모델을 채택하려면, 마이크로서비스 아키텍처 또한 적용해야 한다.
마이크로서비스와 컨테이너(Container)는 빠르게 반복되는 데브옵스 모델을 가능하게 하고, 특정 그룹 내에 더 많은 자율성을 제공한다. 코드 환경의 아키텍처는 팀의 협력방식에 큰 영향을 미친다.
깃랩(GitLab)은 단일 애플리케이션으로 제공되는 데브옵스 플랫폼으로, 개발 팀은 그룹 검증, 그룹 생성 등 단계별로 조직화돼 있다. 이는 다른 회사에서는 별도의 제품이 되기 때문에 자체적인 자율성이 요구된다. 또한, 제품의 다른 측면을 관리하는 다른 기능적 데브옵스 그룹도 있다. 먼저, 깃랩은 운영시간과 안정성을 관리하는 SRE 팀을 꾸려 운영하고 있다. SDLC 전반에 걸쳐 가시성과 투명성을 확보하기 위한 노력을 통해 이 모든 것들을 조화롭게 운영하고 있다. 또한, 컨테이너와 쿠버네티스(Kubernetes)를 통한 클라우드 네이티브 개발에 주력함으로써 보다 빠르게 배포할 수 있다.
프로세스를 자동화하는 도구뿐만 아니라, 개발과 운영 팀 간의 협업과 가시성을 용이하게 하는 팀 구조는 이상적인 데브옵스 라이프사이클을 위한 핵심 요소다. 좋은 데브옵스는 모든 사람이 모든 일을 하는 것을 의미하지 않는다. 개발자가 운영 팀의 일을 해야 하는가? 그렇지 않다.
처음에는 많은 사람들이 데브옵스의 목표가 개발, QA, 운영 부서를 단일 팀으로 결합해 모든 사람들이 모든 일을 하고, 즉각적으로 혁신을 일으키는 것이라고 생각했다. 하지만 이러한 전략은 당연히 실패했다. 전문가들은 부가가치를 창출할 수 있지만, 개발과 운영 프로세스 간의 응집력이 부족하면 시간이 지남에 따라 불필요한 역기능이 발생하게 된다.
이는 곧 나와 그들이 아니라, 우리가 돼야 함을 의미한다. 의사소통을 하는 조직은 필연적으로 같은 방식으로 운영되는 구조를 구축할 것이다. 이상적인 데브옵스 팀 구조는 효과적으로 팀들이 협력할 수 있고, 코드와 생산 간의 장벽을 제거할 수 있는 구조다. 이제 보다 나은 데브옵스 구조를 구축할 준비가 됐다면, 바로 실행하면 된다.
저자명: 크리시 뷰캐넌(Chrissie Buchanan)
자료제공: 깃랩(GitLab)
그래도 삭제하시겠습니까?