Devops by 황순삼

Devops를 아시나요? 2011.11.30일자 CIO코리아 기사에 커리어에서 "놓지지 말아야 할 5 가지 IT 프로젝트" 중 3번째로 디봅스(Devops)팀 관리를 뽑고 있습니다. 우선 디봅스는 개발과 운영의 합성어 입니다.

Devops
: Development +Operations

소프트웨어가 서비스를 지향함에 따라 보다 신속하게 개발하고 지속적인 릴리즈를 제공할 필요성이 강조되고 있습니다. 특히 최근의 클라우드로 변해 가는 개발 환경에서는 소프트웨어 개발과 운영 관리 간의 협업과 통합을 더욱 필요로 합니다.  

일반적으로  개발자와 운영자는 다른 조직에 속할뿐만 아니라 존재하는 목적도 다릅니다. 개발자에게 기능 개발이나 결함 수정 등 변화가 필요한 반면 운영자에게는 서비스의 안정성과 성능에 영향을 미칠 수 있는 변화가 반가울리 없습니다. 
일반적으로 기업이 클수록 개발과 운영 환경을 구분하고 절차와 권한을 정하여 이에 따라 릴리즈가 되도록 관리하게 마련입니다. 개발환경에서 수정하여 넘긴 코드가 운영환경에서는 예상못한 결함을 만들어 내기도 합니다. 야후에서도 개발자 그룹과 운영자 그룹은 조직을 구분하는데, 글로벌 프러덕트들은 릴리즈 주기에 따라 신청하고 리뷰하고 허가가 이루어지는 과정이 매우 긴 편입니다. 한국 사용자에게 심각한 불편을 주는 국내 서비스 장애도 수정은 다 끝났지만 글로벌 릴리즈로 몇 주를 기다려야만 하는 경우도 있고, 반대로 국내에서는 아무것도 수정한 것이 없는데 글로벌 릴리즈 영향으로 오동작이 발생하는 경우도 있습니다. 이런 사건이 발생할수록 그룹간에 복잡한 절차와 통제가 더해지고 릴리즈는 더욱 느려지게 됩니다.   
좀더 빠르고 안정적으로 서비스를 제공하여 조직 목표를 달성하기 위해서는 개발과 운영이 공동의 비지니스 목표를 가진 전체 개발 과정의 협력자라는 인식이 필요하며 이것이 Devops가 필요한 배경이 됩니다.  애자일 개발은 개발 우선순위를 고객의 가치에 두고 짧은 반복 개발과 지속적 통합을 통하여 언제든 고객에게 필요한 기능을 릴리즈할 수 있도록 하여 Devops를 반영시켜 줍니다. 
애자일이 도입되었다고  Devops가 이루어지는 것은 아닙니다.  개발은 애자일을 지향하고 지속적 통합과 2주 릴리즈를 강조하더라도, 전체 조직은 여전히 폭포수 방식의 관리 방식에 따라 움직이는 경향이 있습니다. 결함 수정이나 코드 리팩토링과 같은 눈에 띄지 않는 변화들은 무시되기 쉽고 릴리즈는 전체 개발이 다 이루어지고 난 뒤로 연기되기도 하죠. 그러나 마이너한 수정을 릴리즈하는 것이 쉽지 않다면 메이저 버전 릴리즈 시점에도 문제가 발생하기 쉽습니다. 
Devops를 구현하기 위해서는 먼저, 조직문화가 변화를 수용하도록 보상시스템을 마련할 필요가 있습니다. 팀별 성과가 아니라 전체 개발 차원에서 성과를 측정하고 보상해주는 것입니다.  하나의 프로젝트에서 개발팀은 릴리즈에 막혀 쩔쩔매다 일정 놓쳐 실패하고, 운영팀은 릴리즈를 막아내어 안정성 유지로 보너스를 받는 보상은 팀간 장벽만 높여놓게 됩니다. 
또한  개발에서 운영까지를 하나의 통합된 프로세스로 묶어내고 툴과 시스템을 표준화하고 통합하여  의사소통의 효율성을 확보하고 매뉴얼 작업을 가능한 자동화하여  코드 통합, 테스트, 릴리즈 과정이 자동화될 수 있도록 만들어 줍니다. 

Devops는 기존의 조직에 이름만 바뀌어서 혹은 새로운 역할로 담당자를 채용한다고 이루어지지 않습니다. 이는 기존에 있던 조직 문제를 그냥 다른 조직으로 바뀌 부르는 것에 불과하기 때문입니다. Devops는 개발과 품질 보증, 운영이 겹치는 cross-functional한 역할로써 기능간의 협업과 의사소통을 이끌고, 프로젝트 성공을 위하여 경영진의 지원을 받아낼 수 있어야 합니다. 

덧글

댓글 입력 영역