데브옵스 알아가기(1) : 애자일과 데브옵스

Updated:

애자일과 데브옵스…
요즘 가장 핫(Hot)하다고 이야기하기에는, 이미 초 시대의 뉴 노멀(New Normal)로 자리잡은지도 꽤 되었습니다. 필자의 느낌에는 애자일 프로젝트, 애자일 조직, 애자일하게 일하는 방식 등에 대해 이야기하다가 지금은 데브옵스로 훅 넘어와 버린 것 같기도 합니다. 그래서인지 어느 조직에서는 애자일은 건너 뛰고 우린 바로 데브옵스로 간다면서 관련된 시스템과 도구들을 불쑥 도입하는 곳도 늘어나고 있습니다.

그런데 애자일과 데브옵스는 도대체 어떤 차이가 있는 것일까? 무엇이 먼저일까? 궁금증이 일었고, 이 포스팅을 준비하는 계기가 되었네요.

10억명 이상이 사용한다는 Samsung Account개발 프로젝트 책임자였으며, AWS 히어로 Ten에 속하는 송주영 엔지니어가 당사 OpenLab 강연에서 “애자일은 change thinking이며, 데브옵스는 change doing이다”라는 말을 남긴 적이 있습니다. 애자일과 데브옵스를 잘 나타내는 멋진 표현이라 생각합니다.
한가지 아쉬운 점은 이러한 표현은 애자일과 데브옵스의 영역을 이분법적으로 보게 된다는 것입니다. 비록 Agile Aliance에서 발간한 애자일 가이드북에서 애자일은 마인드셋이라 언급한 바가 있고, 데브옵스의 경우에도 대부분 사람들이 도구나 프로세스 위주로 인지하는 경향이 있지만, 애자일과 데브옵스 모두 생각과 행동의 변화 모두를 필요로 하는 것은 분명합니다.

사실 필자도 처음 데브옵스를 접하였을 때, 데브옵스는 단순히 도구적인 측면을 의미하는 줄로 알았습니다. 본격적인 애자일 코치 역할을 시작하면서 데브옵스를 다시 대면하게 되었을 때에는 오히려 혼란스러웠는데, 특히 조직 관점에서 애자일 트랜스포메이션을 먼저 해야 하는 것인지, 데브옵스 트랜스포메이션을 먼저 해야 할지 동시에 추진을 해야 하는 것인지 등 각각의 목표와 접근방법의 차이는 무엇인지 좀더 체계적인 설명이 있으면 좋겠다는 생각이 들었습니다.

지금 생각해보니 체계적인 설명이 부족해서가 아니라 굳이 데브옵스가 아니더라도 어떤 새로운 개념을 만나게 되면 처음에는 원래 헤매게 되는 게 당연지사가 아니었나 합니다. 지난 몇 년 동안 뜨거운 토픽이었던 클라우드, 블록체인, 빅데이터 등 Digital Transformation에 대해서도 시간을 두고 알아나가면서 사용도 해보고 경험을 해보고 나서야 비로소 알 수 있게 된 것처럼…
결과적으로 데브옵스에 대한 혼란스러움도 데브옵스를 직접 사용해보고 경험을 해보고 나서야 그 안개 속의 실체를 마주할 수 있을 거라 생각합니다.

서두가 길었네요.

본 글은 필자처럼 애자일, 데브옵스를 한꺼번에 와락 접하게 되면서 혼란스러움을 느끼는 사람들, 데브옵스 초보자를 위해 쓴 글입니다.
새로운 내용도 아니며 체계적, 학술적 지식도 아닌, 개인의 학습과 경험을 스스로 다지기 위해 정리한 글 정도로 보심이 합당할 것 같습니다.
(따라서, 이미 데브옵스를 잘 알고 있는 분들은 제발 스킵해 주시기 바랍니다.😅)

애자일과 데브옵스의 역사

새로운 개념, 사상, … 또는 미술이든, 음악이든 역사와 컨텍스트를 알면 그 부분에 대해 조금 더 쉽게 이해할 수 있습니다. 애자일과 데브옵스에 대해서도 먼저 히스토리를 통해 접근해보도록 하겠습니다.

알다시피, 애자일은 2001년 17명의 소프트웨어 개발자들이 모여 그 유명한 애자일 개발 선언문(Agile Manifesto)을 발표하면서부터 시작되었습니다. 그 17명에는 켄트 백(Kent Beck), 워드 커닝엄(Ward Cunningham), 마틴 파울러(Martin Fowler), 제프 서덜랜드(Jeff Sutherland), 켄 슈웨버(Ken Schwaber)와 같은 쟁쟁한 개발자들이 포함되어 있었지요.
이미 1990년대로 넘어오면서 기존의 복잡하고 무거운 개발 방법론에서 벗어나 좀 더 가볍고 유연한 접근 방법을 시도하면서 다양한 SW 개발 방법론들(RAD, UP, DSDM, 스크럼, 크리스털 클리어, XP, FDD 등)이 본격적으로 소개되기 시작했는데, 이러한 경량화 개발 방법론을 논의하기 위해 당대 내노라 하는 이들 개발자들이 유타 주 스노우버드 리조트에 모여 경량화 방법론에서 논의한 끝에 애자일 소프트웨어 개발의 목적과 가치를 애자일 선언문 형식(Agile Manifesto)으로 발표하면서 본격적으로 탄생하게 된 것입니다.

애자일은 전통적이지만 무거운 폭포수 방법론 대신 빠르게 개발하는 접근 방식으로 2000년대 IT 전성시대를 구가하는데 이바지하였습니다. 그러나, 시스템 규모가 커지고 복잡해지면서 보다 안정적인 운영을 필요로 하게 되고, 빠른 개발 방식에도 태클이 걸리기 시작했습니다. 빠른 개발은 종종 장애를 일으켰고, 기존 시스템에 익숙한 운영자들은 새로운 기술을 도입하여 변화하는 것에 부담을 느끼기 시작했습니다. 반대로 개발자들은 공룡처럼 비대해진 기존 시스템을 파악하기 어려웠고 운영자의 도움을 충분히 얻지 못한 상태에서 새로운 기술을 구현하다 보니 예상치 못한 문제가 발생할까봐 노심초사하게 되었습니다. 빠르고 새로운 변화를 시도하는 개발과, 장애없고 안정적인 운영이라는 서로의 입장은 너무 달랐고, 개발과 운영 간에 깊은 갈등이 빚어졌습니다.

2007년 패트릭 드보아라는 IT 컨설턴트가 애자일 방법론으로 대규모 정부 사업을 컨설팅하게 되었는데 개발팀과 운영팀간 견해 차이로 협업이 어렵자 이 문제를 해결하기 위한 고민을 하기 시작하였습니다. 2008년 토론토에서 열린 애자일 컨퍼런스에서 피보탈의 앤드류 쉐이퍼와 “애자일 인프라스트럭쳐”라는 주제에 대해 토의하게 되면서, 이후 본격적으로 “애자일 시스템 관리”의 개념을 발전시켜 나가게 됩니다.
한편 2009년 오렐리 벨로시티에서 열린 컨퍼런스에서도 플리커의 존과 폴이 데브옵스의 초기 개념을 담은 “10+ Deploys per Day: Dev & Ops Cooperation at Flickr” 를 발표하였는데, 이 프리젠테이션에서 영감을 얻은 패트릭 드보아가 벨기에 겐트(Ghent) 지역에서 DevOpsdays 컨퍼런스를 개최하면서 공식적으로 “DevOps“라는 용어가 공식적으로 쓰이기 시작했습니다.

아래는 플리커의 devopsday 발표 자료에 나오는 것으로 개발-운영간 갈등을 나태냅니다.

이듬해 2010년는에 미국 마운틴 뷰, 호주 시드니 등 4개 국가 주요 도시에서 2011년에는 마닐라, 보스톤, 멜버른 등 7개 지역, 2016년에는 32개, 2019년에는 80개 지역에서 컨퍼런스를 개최하며 급속도로 IT 개발-운영 문화와 환경에 대한 변화를 확산해 나가고 있습니다. (2020년에는 코로나19로 인해 47개 지역으로 축소)

안타까운 것은 지난 10년간 수백 번의 컨퍼런가 열리는 동안 한국에서 개최한 이력이 없으며, 2021년까지 예정된 컨퍼런스 일정에도 언급되어 있지 않다는 점입니다. IT 강국의 대표 주자로써 세계가 인정하는 대한민국에서 데브옵스 컨퍼런스 개최 이력이 없다는 사실이 좀 아이러니컬하네요.
데브옵스가 한국에서 아직 확산되지 못하고 있는 이유는 여러가지가 있겠지만,한편으로는 향후 이 분야가 본격적으로 논의가 된다면 이미 잘하고 있는 IT 분야가 한층 더 성숙해질 동력을 찾을 수 있을 것 같다는 생각도 듭니다.
참고로 데브옵스 컨퍼런스에 대한 자료는 https://devopsdays.org/events에서 찾아볼 수 있으며, 각 컨퍼런스의 강의 컨텐츠는 vimeo를 가입해야 시청이 가능합니다.

애자일과 데브옵스의 차이

애자일이 경량화 방법론에서 출발하였기 때문에, 보통 “애자일 방법론”이라는 용어로 애자일이 소개되는 경우가 많다. 하지만, 애자일은 방법론 그 이상의 것으로 발전해왔으며 선언문에서도 알 수 있듯이 변하지 않는 S/W 개발의 가치를 최우선으로 하고, 그 가치를 이루기 위한 다양한 실천법을 수렴해가는 일종의 사상 체계이며, 마인드셋으로 봅니다. 이와 같은 개념을 잘 나타내는 것이 애자일 나무(Agile Tree) 또는 애자일 우산(Agile Umbrella)으로 표현되는 그림입니다.

재미있는 것은 애자일 진영에서는 데브옵스가 애자일로 대변되는 개발 생태계에서 파생된 하나의 새로운 실천 방법으로 보는 반면, 데브옵스 진영 측에서는 데브옵스 실천을 위한 구성 요소 중의 하나로 조직 변화를 위한 애자일 프로세스가 필요하다고 여기는 시각이 있습니다.

또 어떤 이들은 애자일과 데브옵스를 별개의 방법으로 보고 다음과 같은 식으로 비교하기도 합니다.

비교 자료에서 볼 수 있는 큰 특징 중 하나는 애자일은 고객과의 상호작용에, 데브옵스는 개발팀과 운영팀간의 긴밀한 협력 관계 구축에 집중한다는 것입니다. 또한 애자일은 반복(Iteration)과 피드백을 통해 지속적인 개선을 추구하는 반면 데브옵스는 지속적인 통합과 배포, 이를 위한 자동화와 이러한 CI/CD/Automation을 위해 프로세스 및 도구간 물흐르듯 연결하는 파이프라인(Pipline)을 추구합니다.
애자일과 데브옵스의 차이점에 대한 여러가지 자료를 찾아보면서 필자가 느낀 생각은 애자일이 핵심 가치를 바탕으로 하여 여러가지 케이스별 방법과 프랙티스가 나오면서 갈래가 나누어지는 반면, 데브옵스는 핵심 목표를 향하여 여러가지 실천방법들이 통합되어 간다는 것입니다. 즉, 애자일 방법은 XP, 칸반, 린, 스크럼 등 상황에 따른 실천법들이 나오지만, 데브옵스에서는 린, 스크럼, 칸반의 좋은 점을 채택하여 데브옵스 체계로 통합하고 있는 것으로 보입니다. 예를 들어 다음은 옵시디안(Opsidian)이라는 프로젝트 방법론 컨설팅 회사에서 소개하는 방법론인데, 그림에서 왼편 위쪽에 보면 애자일 방법론인 스크럼을 사용하고 있습니다.

이 밖에도 인터넷에서 “애자일과 데브옵스”로 직접 검색을 해보면, 더 많은 내용을 알아볼 수 있을 것입니다.

애자일과 데브옵스의 유사점

애자일과 데브옵스를 이분법적으로 나누고 싶지 않지만, 애자일 활동은 고객가치, 자율성, 자기주도성 등 약간 형이상학적인 개념이 강조되는 반면, 데브옵스는 도구를 활용하여 조직의 개발-운영 프로세스와 규칙을 정규화한다는 점에서 형이하학적인 성과물로 보여지는 측면이 있습니다.
그래서인지 Digital Transformation을 추구하는 조직에서는 애자일보다는 가시적으로 결과물을 보여줄 수 있는 데브옵스를 선호하며, 프로세스/도구 및 관련 시스템을 구축하는 것만으로 데브옵스 전환이 완성되었다고 보는 시각이 상당한 듯 합니다.

그러나, 위에서 밝혔듯이 데브옵스의 시초는 애자일 가치에 근거하며, 그 가치인 공유와 개방성, 자율과 자기주도성, 약속에 대한 헌신 등 내면적인 변화를 수반하지 않으면 겉으로 나타나는 프로세스, 도구, 시스템만으로 결코 데브옵스를 완성할 수 없습니다.
애자일과 데브옵스는 변화에 기민하게 대응하고, 시장에 신속히 제품을 릴리즈하기 위하여 짧은 배포(Release) 주기를 가지며, 대신에 Small Product를 지향한다는 점에서 동일한 지향점을 가지며, 또한 이러한 프랙티스들이 실천되기 위해서 조직 내에 합의된 문화와 관습이 뿌리내리기까지 조직 구성원의 헌신이 필요합니다.


정리

데브옵스는 “애자일 선언”에 뿌리를 둔 여러가지 실천법 중 하나로 처음 소개되었지만, 애자일 방법론이 커버하지 못하는 운영 영역의 변화 필요성이 대두되면서 데브옵스 철학 역시 빠르게 발전하였습니다. 이제는 오히려 온전한 데브옵스 실현을 위한 요소 중 하나로써 애자일 방법이 필요한 것으로 보는 것 같습니다. 애자일보다 훨씬 뒤에 나온 데브옵스가 개발 외에 단순히 S/W를 유지보수하는 운영 측면을 넘어서 인프라까지 고려하여 IT개발-운영 생태계 전반을 다루고 있다는 점에서 필자의 생각도 데브옵스가 애자일보다 더 큰 범위를 망라하고 있다고 생각됩니다.
궁극적으로, 무엇이 선-후든 애자일과 데브옵스 모두 VUCA 시대에 고객의 비지니스를 빠르게 대응하기 위한 것입니다. 비지니스 기민성을 확보하기 위하여 고객을 포함한 개발-운영자의 마인드와 프로세스, 도구 등 조직 자원을 전방위적으로 변화시키는 것이 IT Agility 확보입니다.

아쉬운 점은 애자일이란 용어를 오인하여 지나치게 “민첩성과 신속한 변화 추구”라고만 생각해버린 조직 상부와 고객의 기대 덕분에 많은 조직의 IT 엔지니어는 애자일과 데브옵스 자체를 빛과 같은 속도로 변화해내야 하는 현실에 당면해 있다는 점입니다.
전광석화같은 속도로 칼을 휘두르는 무림고수가 되기 위해서는 먼저 마당쓸기 3년, 물긷기 3년, 설겆이 3년 등의 훈련을 통해 최적화된 근육과 이를 참아낼 오랜 인내심이 필요합니다. 고도로 훈련된 근육은 다양한 상황에서 무의식적으로 반응할 수 있습니다. 변화에 민첩하게 반응하고 결과를 만들어내기 위해서는 조직 내에서도 오랜 인내심과 훈련을 통해 애자일과 데브옵스 근육을 키워 나가야 할 것입니다.

여기 소개한 내용은 애자일과 데브옵스를 모두 설명하기에는 한없이 부족하지만, 일단 그 시작이 어디서부터 비롯되었고 두 개념의 차이와 유사점은 무엇인지 알아봄으로써, 그 이해의 첫 단추를 끼워보고자 하였습니다. 기존 IT 조직과 질서에 새로운 변화의 바람을 몰고 온 이 두 사상과 개념이 향후 어떻게 발전하고 진화하고 있는지 따라잡는 데에 독자들에게 도움닫기가 되었다면 더 바랄 나위가 없을 것 같습니다. 다음 편에서는 데브옵스가 무엇인지 조금 더 다가가 보도록 하겠습니다.

< EOF >