DevOps는 Development와 Operations의 합성어이며, 기존의 개발 업무와 관리 업무로 나눠진 두 역할 사이에서 커뮤니케이션, 협업, 통합을 강조하는 개념입니다.
전통적으로 그래왔듯 역할을 특정 업무에 대한 책임 관점으로 바라보는 것이 아니라, 두 역할이 상호 의존성을 가지고 있다는 것을 명확히 인지하고 이 두 역할을 하나의 팀이나 부서로 통합함으로써 서비스의 안정성을 유지하고 더 빠른 변화를 위한 방법론 중 하나입니다.
DevOps 등장 배경
최근 IT 트렌드의 핵심요소는 속도입니다. 페이스북(Facebook)은 ‘Move fast and Break Things’를 새로운 모토로 내세우고 있으며, 구글(Google) 또한 중요 철학 중 하나로 빠른 속도를 내세우고 있습니다.
기존에 주로 사용하던 폭포수(Waterfall) 모델 방법론은 단계별로 명확한 구현을 원칙으로 진행됩니다. 하지만 Dr. Winston W. Rovce, Steve McConnell 등의 저서에 따르면 실제적으로는 각 단계를 완벽히 마무리한 후 다음 단계를 진행하는 것은 많은 어려움이 따른다고 하는데요.
이에 따라 일정한 주기를 가지고 끊임없이 Prototype을 만들어내며 그때그때 필요한 요소를 진행하는 애자일 프로세스가 새로운 일하는 방식으로 대두되고 있습니다.
● 관점의 변화 – 개발 중심에서 운영 중심으로
그동안은 S/W 방법론의 변화과정에서 시스템 운영은 일반적인 소프트웨어 개발 수명 주기 활동 일부로만 생각되어 왔습니다. 그 근거로 ISO/IEC-12207, IEEE 1074-1991에 운영에 대한 언급이 없는 것과 Rational Unified Process (2003)에 대부분이 개발에 대한 언급만 있는 것을 볼 수 있는데요. 이러한 경향이 지속되면 새로운 프로세스를 도입하더라도 소프트웨어 라이프사이클에 완벽히 정착시킬 수 없기 때문에, 운영에 대한 고민도 함께 이루어져야 합니다.
더욱이 시스템 간 연결이 복잡해지고 기술과 요구사항이 지속적으로 변화하고 있는 시점에서 시스템 운영은 시장 경쟁력의 중요한 요소가 되어 가고 있습니다. 국내 S/W 사업의 형태도 SI 위주의 신규 사업보다는 운영 중심의 유지보수 사업에 대한 비중이 커지는 것도 운영을 기존과는 다른 시각으로 바라봐야 할 요소임을 보여 주고 있습니다.
● 개발자와 시스템 관리자의 Gap
IT 시스템에서 필요한 두 가지 큰 역할은 서비스를 만드는 개발자와 이 서비스를 운영하고 개선하는 시스템 관리자입니다.
시스템 관리자는 안정성을 보장하는 것이 기본 역할이고 이를 수행하기 위한 가장 기본적인 방법은 변화를 최소화하는 것이지만, 반대로 개발자는 변화를 만들어내는 사람이기에 이러한 기본적인 차이로 인해서 두 역할은 항상 대립 상태에 있고 단절이 심화되고 있습니다. 이로 인해 문제 발생 시에 문제 해결을 위해 서로 화합하지 못하고 서로를 탓하기만 하는 경우도 많으며 서로 간의 업무와 정보가 손쉽게 공유되지 않아 처리 속도도 느립니다.
그리고 시스템 관리자의 코드들은 관리의 사각지대에 있는 경우도 많은데요. 시스템 관리자의 주 역할은 서비스를 배포하고 관리하는 것이기 때문에 시스템 관리자가 진행하고 있는 작업은 반복적인 요소들이 많이 존재하므로, 이를 효율적으로 수행하기 위해서 시스템 관리자들도 개발자처럼 코드를 작성합니다.
그런데 일반적으로 개발자들의 코드는 그 정도는 달라도 지속해서 관리가 되지만, 시스템 관리자들에 의해 작성된 코드들은 그렇지 못한 경우가 많습니다. 이로 인해 서비스 자체의 오류가 아닌 운영 혹은 관리상의 오류가 지속해서 반복되고 있는 상황입니다.
● 기술의 진화
자동화는 신뢰성 있는 테스트와 빠른 빌드를 통해 DevOps를 가능하게 하는 기술적 요소이며, 개발자와 시스템 관리자가 업무와 정보를 쉽게 공유할 수 있는 기반이기도 합니다.
2014년에 발표된 HP 사례에 따르면 자체 테스트, 빌드 자동화 시스템 도입으로 빌드 주기를 1주에서 3시간으로, 회귀 테스트 주기를 6주에서 24시간으로 단축했고, 이로 인해 종전의 전체 과정 중 순수 개발 소요 비중을 5%에서 40%로 8배 정도 올릴 수 있었는데요. 또 Puppet에서 2017년 발표한 보고 자료에서는 고효율 그룹에서 수작업의 비율이 상대적으로 낮음을 확인할 수 있습니다.
클라우드의 가장 기본적인 정의는 ‘인프라를 프로비저닝할 수 있는 시스템’입니다. 이를 수행하기 위해서는 인프라를 코드나 템플릿으로 정의할 수 있어야 하고, 이러한 반복이 가능한 프로세스를 생성 가능케 하는 것이 클라우드 기술입니다.
클라우드 도구(Tool) 및 서비스를 이용하면 빌드 프로세스를 정의하고, 관리 및 프로비저닝 하는 것을 코드(IAC)를 통해 프로세스를 자동화 할 수 있습니다. 이로 인해서 개발 프로세스를 가속화고, 사람으로 인한 오류를 제거함으로써 완성도를 높일 수 있습니다.
DevOps를 주목하는 이유
위에서 언급한 바와 같이 비즈니스는 빠른 변화를 추구하는 방향으로 바뀌고 있지만, 개발과 운영의 화합이 원활하지 않고, 운영에 대한 고민도 부족해서 빠른 변화를 적용하기 쉽지 않았기 때문에 이를 해결하기 위해 DevOps가 주목받기 시작했습니다. 그리고 자동화 기술 또한 발전하면서 문화를 통한 해결 외에도 DevOps를 실질적으로 이루어낼 수 있는 기반이 이루어졌습니다.
DevOps에는 현재 시대가 요구하는 빠른 변화 대응을 측정하기 위한 요소로 다음 4가지가 있습니다.
- 배포 빈도(Deployment Frequency)
- 장애복구시간(MTTR-Mean Time to Recover)
- 변경 실패율(Change Failure Rate)
- 리드타임(Lead Time)
즉, 빌드 빈도는 높이고, 장애복구 시간은 줄이며, 결함률은 낮은 상태로 유지하고, 리드 타임을 줄여서 안정적인 시스템을 유지하고 이를 수치화해서 이를 중심으로 개선하겠다는 의도라고 볼 수 있습니다.
IT OPS&DEVOPS PRODUCTIVITY REPORT 2013에 따르면 DevOps 적용 기업이 상대적으로 더 낮은 복구 시간을 유지했고, 60분 이상의 대형 복구 작업의 빈도수는 매우 적은 것으로 발표했습니다.
또 DevOps 벤더 중 하나인 Puppet에서 2016년 발표한 자료에 따르면 DevOps를 효율적으로 적용한 기업이 그렇지 않은 기업에 비해 배포빈도는 200배 증가하고, 장애 복구 시간은 24배 빨라졌으며 결함률은 3배 낮아지고 리드 타임은 2,555배 낮아졌다고 하는데요. 이로 인해서 계획되지 않은 일이나 재작업에 22% 낮은 시간을 할애했으며, 보안 작업에는 50% 낮은 시간을 소요한 것으로 발표했습니다.
위 내용을 통해서 DevOps를 적용하고 이를 얼마나 잘 활용하느냐에 따라서 기업의 생산성 및 효율성이 극대화 될 수 있다는 것을 알 수 있습니다.
DevOps의 주요 원칙
DevOps는 사고방식, 문화, 그리고 기술의 집합체인데요. 이를 수행하기 위해서는 기본적인 원칙이 필요합니다.
일반적으로 문화(Culture), 자동화(Automation), 간소화(Lean), 측정(Measurement), 공유(Share) 이 다섯 가지를 주요한 원칙으로 제시하고 있습니다.
● 문화(Culture)
DevOps 문화는 한 단어로는 ‘협업’, 두 단어로는 ‘다기능 협업’이라고 요약할 수 있습니다. 이 세상의 모든 도구와 자동화 시스템은 개발 팀원과 IT/Ops 전문가가 진심으로 협력하고자 하는 마음이 없다면 쓸모가 없다고 할 수 있는데요. DevOps는 도구의 문제를 해결하는 것이 아니라, 사람 간의 문제를 해결하기 때문입니다.
성공한 회사 대부분은 모든 부서와 모든 조직 체계에 DevOps 문화를 적용하고 있습니다. 이러한 회사에서는 열린 커뮤니케이션 채널을 갖추고 정기적으로 대화를 진행하며, 모든 사람이 목표를 지정하고 필요에 따라 조정하고, 고객 만족은 제품관리팀과 개발팀 모두의 책임이라고 생각합니다. 즉, DevOps는 한 팀이 하는 일이 아니라 모든 팀이 함께하는 일이라는 것을 알고 있습니다.
● 자동화(Automation)
자동화는 개발, 테스트 및 지속적 배포의 핵심요소 입니다. 개발 사이클에 높은 수준의 자동화를 도입하 막대한 이점을 얻을 수 있는데요. 자동화를 처음 접하는 팀은 보통 지속적 배포로 시작합니다. 지속적 배포란 대부분 클라우드 기반 인프라로 촉진된 자동화 테스트를 통해 각 코드 변경 사항을 실행한 다음, 빌드를 패키징하고, 자동화 배포를 사용하여 생산을 추진하는 과정입니다. 지속적 배포는 쉽고 빠르게 만들어낼 수는 없지만, ROI는 충분한 가치가 있습니다.
시스템은 언제나 변화하지만 우리는 프로비저닝 코드를 사용하여 겉으로 보기에 시스템이 변하지 않는 것처럼 보이게 만들 수 있습니다. 이로써 손상된 서버를 수리하는 것보다 다시 프로비저닝하는 것이 더 빨라지며, 이는 더 안정적일 뿐만 아니라 위험도 줄어들게 됩니다.
개발팀 및 운영팀은 모두 프로비저닝 코드를 통해 새 언어 또는 기술을 통합하고, 서로 업데이트한 내용을 공유할 수 있는데요. 호환성 이슈는 릴리스 도중에 나타나는 것이 아니라 즉각적으로 분명하게 나타납니다.
● 간소화(Lean)
소프트웨어의 맥락에서 ‘Lean’이란 보통 가치가 낮은 활동을 없애고 빠르고 적극적이며 Agile하게 움직인다는 의미입니다. DevOps와 가장 관련 있는 개념은 지속적인 개선과 실패 인정입니다.
‘낭비를 제거하여 어떻게 하면 고객에게 가치를 빠르게 제공할 수 있을까?’를 고민하는 사고방식이며, 그 핵심은 끊임없이 문제를 해결하고 개선하는 것입니다. Lean Principle을 사용하면 지속적인 사이클을 가능하게 합니다.
● 측정(Measurement)
DevOps는 여러 가지를 측정하고, 측정결과를 사이클 정비 데이터로 사용합니다. 실제적으로 데이터가 없으면 지속적인 개선을 위한 노력이 실제 개선으로 이어진다고 증명하기가 어려운데요. 성공적인 측정은 피드백 프로세스의 중요한 부분입니다.
기초가 탄탄하면 기능의 사용, 고객 경험 및 SLA(서비스 수준 계약)와 관련된 더 복잡한 메트릭을 포착할 수 있습니다. 이렇게 얻게 되는 정보는 로드맵을 작성하고 다음 계획을 세부적으로 수립할 때 도움이 되며, 다른 팀, 특히 다른 부서의 팀과 공유될 때 더 강력한 힘을 발휘합니다.
● 공유(Sharing)
성공 여부와 상관없이 DevOps는 다른 사람들이 배울 수 있도록 경험을 공유합니다. 개발팀과 운영팀 간의 오랜 마찰은 주로 공유의 부족으로 인해 발생하는데요. DevOps는 애플리케이션을 빌드한 사람들이 애플리케이션의 출시와 실행에도 참여해야 한다는 아이디어를 중심으로 합니다.
이는 개발자 및 운영자가 애플리케이션 라이프사이클의 모든 단계를 함께한다는 것을 의미하는데요. 아이디어의 공동 작업 및 최적화, 문제 및 성공사례 이야기는 필수적이며, 아이디어 공유는 피드백 채널을 열어 개선에 이르게 합니다.
지금까지 DevOps의 등장 배경과 그로 인한 일하는 방식의 변화 그리고 DevOps를 주목하고 있는 이유와 수행하기 위한 다섯 가지 기본적인 원칙에 대해 알아봤습니다.
이어지는 다음 원고에서는 DevOps에서 빠르게 효과를 볼 수 있는 방법인 ‘DevOps Toolchain’과 성공적인 도입을 위한 요소에는 무엇이 있는지 알아보겠습니다.
글 l LG CNS CTO 아키텍처담당
