[기고] 협업을 위한 '데브옵스' 조직이란?

[IT동아]

급변하는 비즈니스 환경에서 경쟁에 뒤처지지 않으려면, 개인의 전문성을 뛰어넘는 무언가가 필요하다. 공동의 목표를 여러 조직이 함께 공유하고, 최대한 빠르게 달성하여 성과를 극대화하는 것. 이를 위해 기업이 당면한 숙제가 바로 '협업'이다.

협업은 이 시대 기업 문화의 최대 화두다. 애자일이나 데브옵스 형태의 조직 운영은 물론, 그룹웨어와 슬랙(slack) 같은 툴을 도입하는 것, 수평적인 호칭 문화를 개선하는 것도 모두 협업의 범주에 든다. 데브옵스(DevOps)는 이 가운데 최근에 주목받기 시작한 분야로, 많은 기업이 채택하고 있지만 아직까지 큰 성공 사례는 나오고 있지 않다.

데브옵스는 개발(Development)과 운영(Operation)을 결합한 것으로, 개발자와 운영자(엔지니어)가 긴밀히 협업하는 개발 문화를 의미한다. 의미는 그리 어렵지 않은 듯 하지만, 실제로는 데브옵스 문화 정착에 많은 기업이 어려움을 겪고 있다.

전문가들은 데브옵스 프로젝트의 가장 큰 실패 원인으로, 개발자와 엔지니어가 별도의 조직으로 운영되는 점을 꼽았다. 글로벌 클라우드 매니지드 서비스 업체인 '2nd Watch'가 발행한 2018년 리포트에 따르면, IT 조직의 78%가 개발과 인프라 운영 조직을 별도의 팀으로 유지하고 있는 것으로 나타났다. 조직이 분리되어있는 한 공동의 목표를 향해 나아가기란 결코 쉽지 않다.

성공적인 데브옵스 프로세스를 위한 조직 통합

개발 조직과 운영 조직은 근본적으로 다른 가치를 우선시한다. 개발 조직은 프로세스를 개선하고 끊임없이 새로운 시도를 하려는 반면, 운영 조직은 안정화에 최대한 집중한다. 개발자가 새로운 것을 시도, 배포하려고 하면, 엔지니어는 빠른 배포보다는 혹시 모를 장애에 대한 걱정이 앞서기 마련이다. 게다가 엔지니어에게는 운영에 관한 당면한 과제들이 있기 때문에, 개발 조직이 요구하는 것들을 우선 과제로 삼기 어렵다.

두 조직 간 커뮤니케이션의 문제도 있다. 각자 어떤 업무를 하고 있는지 서로 공유가 되지 않기 때문에, 개발자는 엔지니어에게 작업을 요청하기가 조심스럽고, 원하는 일정대로 진행되지 않더라도 독촉하거나 자세한 이유를 알기도 힘들다. 두 조직 간에 벽이 있는 셈이다.

IT기업인 가비아는 이를 해결하기 위해 2017년, 데브옵스 형태로 조직을 개편하고 개발자와 엔지니어를 한 팀으로 통합했다. 실험적인 데브옵스팀 운영에 성과가 보이자 규모를 키워 데브옵스 부서를 조직화했고, 시스템 구성을 잘 아는 엔지니어들을 개발팀 소속으로 발령했다. 개발자와 엔지니어는 이제 한 팀으로서 같은 목표를 갖고 진행 중인 업무에 대해 항상 공유하며, 서로 등을 맞대고 앉는다. 그러자 개발과 빌드, 배포, 운영에 이르는 속도가 놀라울 만큼 빨라졌다.

개발자들이 스크립트 개발을 끝내면 엔지니어들은 즉각 디버깅을 진행하고, 개발자들에게 피드백을 전달한다. 개발자가 피드백을 처리하는 즉시 테스트가 진행된다. 새로운 요청 사항이 생길 경우 어렵게 업무 협조를 요청하는 대신, 등을 돌려 대화로 문제를 해결할 수 있다. 개발 조직과 운영 조직 사이에 존재했던 '대기 시간'이 사라진 것이다.

일부에서는 데브옵스를 두고 Jenkins 같은 툴을 도입하는 것이나 CI/CD 활동만으로 한정 짓기도 한다. 데브옵스가 분명한 협업 문화다. 개발과 운영의 진정한 통합은 개발자와 엔지니어가 '서로 신뢰할 수 있을 만큼' 가까이 붙어있을 때 비로소 가능하다.

데브옵스를 통한 새로운 가치 창출

협업의 궁극적인 목표는 '1+1'을 했을 때 단순히 '2'를 도출하는 것을 넘어 부가 가치를 창출하는 것이다. 데브옵스 조직도 그런 기대를 받는다. 데브옵스는 빠른 서비스 출시를 도울 뿐만 아니라 서비스 품질을 높이는데 크게 기여한다. 이 가운데는 데브옵스가 아니면 불가능한 작업들도 있다.

가비아 시스템개발실은 데브옵스를 통해 테스트와 배포의 불필요한 절차를 줄이고, 서비스 출시 및 업데이트 일정을 앞당길 수 있게 됐다. 데브옵스 이전에는 개발 작업 후 스테이징 서버에 소스를 올리면, 엔지니어들이 소스를 가져와 서버 별로 각각 배포를 진행했다. 때문에 서버 별로 소스나 업데이트 내용이 다른 문제가 발생하곤 했다.

이제는 데브옵스 조직에서는 Git을 도입해 개발자가 서버에서 코드를 수정한 뒤 소스 저장소(gitlab)에 올리면, 엔지니어가 중앙관리서버를 통해 전체 서버에 최신 내용을 업데이트한다. 무결성 검증이 가능해져 테스트 및 배포가 쉬워졌을 뿐만 아니라, 개발자와 엔지니어 간의 신뢰도 더욱 커졌다.

서비스 품질도 주목할 만큼 개선됐음을 확인했다. 가비아 DNS는 구성 상의 문제로 인해 하드웨어 성능을 최대로 발휘하지 못하는 이슈가 있었다. 이를 개선하기 위해 네임서버가 동작하는 전체 아키텍처를 재설계하고, 싱글스레드 동작 제한이 있던 오픈소스(Bind)를 멀티스레드로 동작할 수 있게 구성했다. 이후 서비스 장애 발생 소지가 크게 줄어들었다.

데브옵스 이전의 환경이었다면 이 작업은 복잡한 실행 절차를 거쳐 테스트가 진행됐겠지만, 쉽게 작업할 수 있는 자동화 프로그램을 개발하고, 프로그램을 실행하면 누구나 복잡한 과정 없이 네임서버 관련 작업을 처리할 수 있도록 개선했다. 프로그램 개발은 기존에는 개발자의 고유 영역이었지만 이제 그런 직무 영역의 한계도 사라졌다. 엔지니어가 직접 업무에 필요한 개발에 참여하기도 하고, 개발자는 시스템에 대한 이해를 더 많이 쌓아 개발 작업을 진행한다. 데브옵스를 통해 직무 상의 한계가 보완되고, 최대의 시너지를 낼 수 있는 조직이 탄생한 것이다.

중요한 것은 협업이 조직 구성원들의 원활한 상호작용이라는 측면에서 고려돼야 한다는 사실이다. 어떤 제도나 어떤 툴을 도입할지 보다, 어떻게 협업 부서 및 직무에 공동의 목표를 부과하고 서로 원활히 대화하도록 만들지 고민해야 한다. 성공적인 협업은 구성원 자신들이 목표를 향해 진보하고 있으며, 각자의 역량이 계속 향상되고 있다는 성취감을 북돋아 준다.

글 / 가비아 시스템개발실 서광열
정리 / IT동아 이문규 (munch@itdonga.com)