데브옵스 알아가기(2) : 그럼 데브옵스가 뭔데..?

지난 편에 이어 이번에는 데브옵스에 대해 본격적으로 알아보도록 하겠습니다.
1편인 “애자일과 데브옵스”에 대한 글을 포스팅하면서 데브옵스의 내용이 제가 예상했던 것보다 상당히 방대하고 심오하다는 생각이 들었습니다. 데브옵스에 대한 기본적인 도서로 추천받는 『데브옵스 핸드북』이란 책을 처음 보면서 참 두껍다고 생각했는데, 저자 입장에서 어떻게 해야 데브옵스를 제대로 할 수 있는지에 대해 그 이유와 설명을 납득시키려다 보니 그처럼 두꺼워지지 않았나 싶네요.

데브옵스에 대하여 검색하다 보면 많은 이미지와 자료들을 찾아볼 수 있는데 그 중 다음과 같이 데브옵스 코끼리로 표현하는 그림이 있습니다. 그림에서 알 수 있듯이 데브옵스라는 개념이 덩치가 크다보니 각자의 입장에서 부분적으로 이해하고 경험한 것을 마치 전부인 양 인식하는 오해와 혼돈이 있다는 것을 반증하고 있습니다. 데브옵스의 전체 모습을 그만큼 이해하기 어렵다는 뜻이지요.

필자의 경우도 수년전에 수행했던 프로젝트에서 처음으로 데브옵스를 접하였을 때에는 단순히 개발+운영을 위한 협업 도구라고만 여겼던 기억이 납니다. 당시 데브옵스를 세일즈하던 조직에서도 데브옵스 관련된 몇개의 제품들을 가지고 와서 설치 후 사용하면 된다라는 정도의 설명만 하였기에, 그렇게 오해하기가 쉽상이었지요.

이후 프로젝트 조직에서 전사 애자일 코치로 활동 영역을 바꾸며 본격적인 데브옵스 공부를 하게 되면서는, 데브옵스는 단순 도구를 넘어서 조직 전반의 문화와 철학까지 아우르는 개념으로, 오히려 알면 알수록 배울 게 더 많고 데브옵스를 온전히 이해하기가 어렵다는 것을 알게 되었습니다.

정의

구글링으로 검색하여 보면 수많은 정의들이 나오는데, 공통적으로 나오는 핵심 키워드를 추려서 대략 다음과 같은 내용으로 정리해볼 수 있습니다.

알다시피 DevOps라는 용어는 Development + Operation의 두 단어에서 조합된 용어입니다. 1편에서도 언급하였듯이 “데브옵스”라는 용어는 벨기에의 IT컨설턴트 패트릭 드보아에 의해 devopsdays 컨퍼런스가 최초 개최되면서 공식적으로 사용되기 시작했습니다. 비지니스 변화에 민감하여 빠르게 대응해야 하는 개발자 입장과 장애없이 안정적 운영을 위해 변화를 지양하는 운영자들 사이의 심화된 갈등을 해소하기 위해서, 드보아는 새로운 체계와 규칙 및 인프라 환경 등이 필요하다고 생각하였습니다. 드보아에 의해 비록 공식화되긴 하였지만, 개발-운영간의 갈등과 해결방법에 대해서는 이미 구글 및 플리커를 포함한 상당히 많은 조직에서 고민을 하고 있었기에 빠른 시간 내에 그 개념이 정립될 수 있었다고 보아야 합니다.

위 정의에서 확실히 알 수 있는 것은 데브옵스는 “문화, 또는 철학이자, 전문적인 운동“이라는 것입니다. 정의 자체가 추상적이고 개념적인 것이라 데브옵스를 배우는 입장에서는 그 실체를 단번에 파악하기가 어렵지만, 이러한 사상이 데브옵스의 근간이 됨으로써, IT 개발-운영 환경이 형식적이고 외형적인 변경만이 아닌 IT 가치관과 일하는 태도와 습성을 바꿀 수 있게 하는 원동력이 된다고 볼 수 있습니다. 아울러 일회적인 변화가 아니라 지속적으로 발전하고 개선해 나갈 수 있는 여지를 제공합니다.

핵심 개념

다음 그림은 데브옵스를 상징하는 이미지로 가장 많이 사용되고 있는 것입니다. 위에 정의에서 데브옵스를 문화이자 철학, 전문적인 운동이라고 하였는데, 이러한 정의는 현실 세계에서 적용하기에는 사실 모호한 면이 있습니다.
아래 그림과 같이 개발-운영간 프로세스간 통합 및 협업체계라 표현해주는 것이 우리같은 IT 엔지니어에게는 좀 더 쉽게 와닿기 때문에 대표 이미지로 사용되는 것이 아닐까 생각됩니다.

데브옵스 하면 항상 따라오는 용어인 CI/CD라고 부르는 “지속적 통합, 지속적 전달” 개념이 있습니다. 애자일에도 이러한 원칙이 있지요. 애자일 실천하기 위한 12가지 원칙 중에 다음과 같은 내용이 있습니다.

1. 우리의 최고 우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달함으로써 고객을 만족시키는 것이다.”
2. …
3. 작동하는 소프트웨어를 자주 전달하라. 

애자일에서는 고객의 가치를 빠르게 전달하기 위해 더 자주, 더 빨리 완성된 제품을 릴리즈하는 것을 목표로 합니다. 여기서 완성된 제품이란 전체 모든 기능의 완성을 의미하는 것이 아니라 제품의 증분(Increment)을 말하는데, 제품의 부분 기능을 점진적으로 완성하여 고객에게 빨리 자주 전달하는 것을 의미하지요.
결과적으로 CI/CD는 애자일 개발 방식이 운영에까지 확장된 개념이며, 이제 “지속적 통합 및 지속적 전달”의 개념은 요즘 IT개발-운영 환경에서 가장 중요하게 여기는 주요한 프랙티스가 되었습니다.

데브옵스 초기에는 이처럼 CI/CD가 크게 부각되었는데, 점차적으로 CI/CD를 제대로 하기 위해서는 지속적 테스트, 지속적 모니터링 또한 중요하며 필요하게 여겨지며 추가적인 프랙티스들이 더해지고 있습니다.

위의 그림에서는 6가지로 프랙티스를 구분하였지만 기업의 데브옵스 실무적 구현 기술에 대해서 다룬 『엔터프라이즈 데브옵스 플레이북(Enterprise DevOps Playbook)』에서는 데브옵스의 핵심 프랙티스를 7가지 영역으로 소개하고 있습니다. 프랙티스를 6가지로 구분하였든 또는 그 이상으로 소개하였든지간에 핵심적인 사상과 개념은 대부분 비슷합니다. 지속적으로 통합하고 전달하기 위해 테스트 및 측정을 위한 모니터링도 지속적으로 이루어져야 하며, 이를 위한 자동화가 필수라는 것이 주된 내용입니다. 데브옵스 플레이북은 핸드북보다 양이 적고 읽기도 간편하므로 한번 읽어보시면 각 프랙티스별 개념과 구체적 가이드라인에 대한 내용을 얻을 수 있습니다. 아쉬운 점은 아직 한국어로 번역되지 않아서 영어로 읽어보셔야 합니다.

※ 참고로 Continuous를 지속적인이라 번역하여 사용하고 있는데 “지속”이라는 말은 어떤 상태가 유지되고 있다는 뜻에 가깝습니다. 개인적인 견해로 지속적인보다는 “계속적인” 또는 “끊임없는“이라는 단어가 원문에 더 가깝다고 생각합니다.

데브옵스 생태계

데브옵스의 핵심 개념인 CI/CD 및 주요 프랙티스를 구현하기 위해서는 필연적으로 자동화된 도구 사용이 따라와야 합니다.
개발된 소스의 통합이 끊임없이 이루어지고 테스트와 배포 역시 신속하게 수행되기 위해서는 많은 프로세스와 절차들이 자동화되는 것은 당연한 것이지요. 자동화를 지원하기 위한 갖가지 도구를 통칭하여 “데브옵스 생태계”라고 하는데 Git이나, Junit, Docker와 Kubernetes와 같은 도구들도 데브옵스 생태계에 포함됩니다. 흥미로운 점은 데브옵스 생태계나 클라우드 생태계에서 사용되는 도구가 유사하다는 점입니다.
클라우드 네이티브 환경을 구축하기 위해서는 데브옵스가 필요하고, 온전한 데브옵스 구현을 위해서는 클라우드 환경이 필요한 셈이지요.

성공적인 데브옵스를 이루기 위해서는 자동화가 핵심이기 때문에, 클라우드를 통한 IaC(Infrastructure as Code) 구현을 포함하여 데브옵스 생태계를 이루는 도구들은 앞으로도 계속 변화하고 발전할 것입니다.

당사에서는 데브옵스의 핵심 라인업을 다음과 같이 정리한 바가 있습니다. 데브옵스 체계로 전환하기 위한 도구를 고려하는 중이라면 다음 그림을 참고해서 보시기 바랍니다.

도구를 사용하게 되면 쉽게 가시적인 성과물로 보여질 수 있기 때문에, 데브옵스를 구현시 가장 흔하게 범하는 실수가 바로 위와 같은 도구를 도입 및 사용하는 것만으로 데브옵스 전환이 완료되었다고 보는 경우입니다.

다시 강조하건데 솔루션과 도구의 도입은 단지 시작일 뿐이며, 문화 및 철학이자 전문적인 운동이라고 하였던 정의와 핵심개념을 바탕으로 개발+운영의 조화로운 협력, 그 이상의 넓은 영역에서 절차와 프로세스를 자동화함으로써 고객에게 지속적인 가치 전달이 되도록 하는 것이 데브옵스임을 기억하시기 바랍니다.

정리

이상에서 데브옵스란 무엇인지 그 정의와 핵심 개념 등에 대해 필자의 관점에서 정리해보았습니다. 막상 정리하고 나니, 전체의 모습을 이해하기에 상당히 내용이 미흡하네요. 수박 겉핥기식이지만 그래도 시작은 해보았으니 나머지는 독자의 노력에 맡기겠습니다.
지난 10년간 수많은 컨퍼런스와 기업 실무에서 벌어진 수천 번의 토론과 고민, 케이스 스터디, 정반합의 진화를 통해 쌓여가는 지식과 프랙티스들을 모두 파악하고 납득하여 따라 가기란 쉬운 게 아닙니다. 이미 경험하였다고 할지라도 제품을 공급하는 벤더, IT개발과 운영을 전문으로 하는 회사 및 스타트업 등에서 끊임없이 더 나은 데브옵스 체계를 위하여 실험하고 적응시키며 발전해 나가고 있기에 앞으로도 주구장창 배워야 할 것이 많을 것입니다.
그러니 어쩌면 우리에게 필요한 것은 끊임없이 학습하는 능력이 필요한 것이겠지요. 제즈 험블은 데브옵스 핸드북에서 지속적으로 학습하고 실험하는 문화를 만드는 것이 성숙한 데브옵스의 3번째 방법이라고 하였습니다.

마지막으로 DevOps is … & DevOps is Not… 이란 자료를 인용해 보겠습니다. 이미 한번씩 언급했던 내용인데, 한번씩 곱씹어 보셨으면 합니다. 이만 데브옵스 개념에 대한 글을 마칩니다. 😄

DevOps is …	DevOps is Not…
• … is a movement, a philosophy, a way of thinking • … is people who perform both Dev/Ops roles and job title • … is continuous delivery • … is automation • … is process for integrating, testing, deploying and monitoring • … set of tools and infrastructure for collaborative working between dev and ops	• … is not just tools • … is not just processes • … is not just automation • … is not a trendy job title

< EOF >