DevOps, 그 문화에 대해서...
은빛 탄환이 아니라 실천해야 할 개발 문화
개발 방법론이나 소프트웨어 개발과 관련된 은빛 탄환과도 같은 뉘앙스를 풍기는 접근법은 수없이 많았다. 이제는 최고의 화두로 떠오른 DevOps에 대해서 삐딱한 아키텍트의 생각으로 끄적거려 보자.
주변에 DevOps를 지향하는 개발회사들이 많다. 그리고, DevOps를 무슨 완전체인 것처럼 소개하는 칼럼이나 글들도 많다. 그렇다면, DevOps의 정체는 무엇이며, 우리 회사, 우리 개발팀이나 운영팀은 그런 준비가 되어 있는 것인지에 대해서 생각해봐야 한다.
사람들은 정말 DevOps가 어떤 의미이기에 사람들이 궁금해하고 있는 것일까?, 그리고. 과연 정말 내가 속한 조직과 팀이 DevOps를 지향할 수 있을까? DevOps에 대해서 삐딱한 아키텍트가 생각해보는 것이 이번 칼럼의 목적이다.
DevOps는 모든 팀, 모든 회사, 모든 곳에 사용되는 만병통치약이 아니다.
DevOps는 새로운 개념인가?
Culture와 movement에 대해서 먼저 이야기를 시작하는 것이 맞을 듯하다. Culture는 어떤 한 국가나 집단의 문화와 같은 것을 의미한다. 그리고, movement는 어떤 움직임을 의미하는 것으로 여기서 사용되는 의미로는 사람들이 조직적으로 어떤 것을 벌리는 운동을 의미한다.
일반적으로 문화란 어떤 옷, 음악, 형태를 가진 조형물 등을 포괄하는 것으로 무형, 유형의 것을 모두 포함하는 것이 문화라고 할 수 있다.
그리고, 이러한 문화는 해당 문명과 조직, 사회의 모든 것을 표현하고 있는 것이며, 그것에 대비하여 문화라는 형태를 통해서 표현한다. 그래서, 소프트웨어 개발의 조직이나 기업에서도 자체적인 개발자 문화라는 것이 존재하고 있다. 이는, 일반적으로 각 회사별로 그 형태나 상황, 사람들의 모습, 역사적인 배경과 발전과정을 통하고, 어떤 사람들이 그 조직을 거쳐갔느냐에 따라서 많은 부분에 있어서, 개발자들의 문화는 매우 다르다고 할 수 있다.
이처럼, 개발자 문화의 영향으로 소프트웨어 개발 방법론과 같은 무형의 것부터, 실제 산출물, 개발 소스와 같은 실제 눈에 보이는 것까지 개발자 문화란 눈에 보이는 것과 눈에 보이지 않는 것을 모두 포함한다고 할 수 있다.
이런 개발자 문화를 언급하기 전에, 개발자들의 운동과 운동을 위한 선언과 같은 것에 대해서 알아보자. 그중에서도 movement를 먼저 살펴보자. 개발자들 커뮤니티와 개발자들의 요즘 철학적인 움직임은 ‘요구사항’ 변동에 대해서 이제 관대한 생각을 가지기 시작했다고 볼 수 있다.
어차피, 요동치는 요구사항에 대해서 ‘완결된 요구사항’이 나올 것이라고 기대하지 않고, 요구사항은 사랑하는 애인의 변덕스러운 마음이라는 생각을 가지기 시작한 것이 DevOps의 원칙적인 기본 생각의 변화라고 먼저 이야기를 하고 싶다.
이제, 개발자들은 요동치는 사람들의 마음이나 사회적인 변덕을 소프트웨어로 반영하는 것을 매우 당연스럽고 자연스러운 과정이라고 인지하기 시작한 것이라고 볼 수 있다. 이처럼 기본적으로 요구사항이 변덕스러운 기획자나 고객의 마음이 당연한 것이라고 생각한다면, 오히려, 더 행복한 개발이 가능하도록 기준이나 계획을 잡을 수 있는 것 아닐까?
이것이 DevOps의 개념 전환의 기본적인 개념이라고 볼 수 있다. 오히려. 처음부터 요구사항이 잘 정해졌고, 더 이상 변하지 않을 것이라고 거짓말을 하고 있는 기획자와 고객들의 마음속에 변덕스러운 변화에 대해서 이제는 관대한 개발자가 되려는 마음을 가진 것이라고 생각할 수 있다고 소프트웨어 개발자들은 이해하기 시작한 것이다.
DevOps는 이러한 마음가짐의 변화와 movement가 먼저 필요하다. 기존의 개발 방법론이나 개발 문화에서 정의하려고 하였던, 뜬구름 잡는 ‘요구사항 명세’는 어차피 불가능한 것이니까, 그 부분을 매우 관대하게 받아들이고자 변화의 마음을 가지게 된 것이라고 생각한다. 그래서, 실제 고객을 만족시키는 요리사의 마음에다가 고객의 마음을 좀 더 가까이에서 이야기를 나눌 수 있는 웨이터의 마음을 가지고 시작해야 한다고 설명하는 것이 더 현명할 수 있다.
이러한 변화의 요소에는 다음과 같은 개발자들이 두려워하는 몇 가지 요소들에 대해서 이제는 정말 명확하게 이야기할 수 있기 때문에 DevOps는 가능하다고 생각한다.
DevOps의 내면에 깔려 있는 소프트웨어 개발자들의 두려움을 먼저 알아야 DevOps의 기본적인 원칙에 좀 더 접근할 수 있다. 그것은 다음에 나열된 내용들은 일반적으로 소프트웨어 개발자들이 어려워하는 것들이다.
1. 소프트웨어를 솔루션 형태의 디자인으로 만드는 것은 정말 어렵다
개발자들은 솔루션을 만들고 그것을 디자인하고 설계, 구현한다는 것은 정말 어려운 것이라고 인지하기 시작하였다. 솔루션을 만들고, 어떤 문제를 해결한다는 것은 정말 험난하고 고된 일이라고 이미 인지하였다.
2. 테스트 케이스를 작성한다는 것은 정말 어렵다
수많은 사용자의 환경을 인지하고, 그것에 대응하는 완벽한 테스트는 불가능하다는 것 또한 개발자들은 인지하였다. 그리고, 그 테스트를 만들기 위해서 쥐어뜯었던 머리카락과 수많은 시간들에 대해서 완전이란 불가능하다는 것을 인지한 것이다.
3. 개발 관련 문서작성 또한 매우 어려운 것이다
개발자들 간에 상호 소통하기 위한 문서의 작성과 다이어그램과 모델을 만든다는 것 또한 정말 어려운 일이다. 또한, 그것을 표준이나 변화해가는 기술적인 요청과 반영 내용을 모두 담는다는 것은 정말 어려운 일이라고 인지하였다.
4. 개발자 자신이 동의하지 않는 기능 구현을 허구 헌 날 해야 한다는 것
간혹이 아니라, 상당 부분 발생하는 동의하지 않는, 쓸모없다고 생각하는 기능 구현에 매달리고 있는 현실에 대해서 이제는 약간은 무덤덤하게 대응할 수 있는 개발자들의 마음가짐은 정말 관해하게 변화하였다.
5. 다른 사람이 작성한 코드를 다루는 것인 매우 당연하다는 것
생각 이상으로 다른 사람의 코드와 프레임워크에 가두어진 상태로 프로그래밍을 해야 한다는 것에 대해서 학교에서는 가르치지 않았다는 것을 매우 두려워하고, 원망한다. 타인이 만들어 놓은 코드에 대해서 읽는 방법에 대해서 가르쳐 주지 않은 교수님이 원망스러울 뿐이다.
6. 고객과 같이 비전문가와 커뮤니케이션해야 한다는 것
비전문가와 소통하는 방법에 대해서 아무도 가르쳐주지 않았다. 사실은 그들과 소통하고 그들을 설득하는 것이 최선의 방법인데, 왜? 그들과 소통하는 방법은 학교에서 가르치고 있지 않는가? 혹시. 교수님들도 그것을 포기한 것 아닌가 하는 의심이 든다? 그러한 마음이 생기기 시작하였고, 과거의 방법론이나 공학에 대해서 의심을 하기 시작하였다.
7. 업무 완료에 필요한 시간 예측은 필수가 되었다는 것
기능 단위의 시간 예측과 일정에 대해서 ‘감’이 필요하다는 것은 실제 현업에 나와서야 만 가능하다는 것을 이야기해준 선배와 교수가 없었다는 점도 실제 현업의 초기에 어려움을 느끼는 부분들이다.
8. 업무의 우선순위와 작업 할당이 애매하다는 것
도대체 누가 결정하는가? 그 순서에 대해서 아무도 모른다.
9. 이름을 만들고, 이름과 의미를 부여한다는 것은 매우 어렵다는 것
그냥, X, Y, I, j, k를 부여하면 안 된다고 하는데, 생각 이상으로 붙여야 할 이름과 규칙들이 너무도 많다.
이처럼, 소프트웨어 개발이 어려워지고 두려워지는 개발자들보다 더 어려운 것도 있다는 사실을 소프트웨어 개발자들은 경험으로 터득한다. 그것은 다음과 같은 상황이다. 그리고, 해결책도 없다는 점이다.
위의 두려운 상황은 ‘단단한 마음’으로 이겨낼 수 있지만, 정마로, 다음의 상황들은 가능하면 소프트웨어 개발자들이 피하고 싶어 진다. 하지만, 우리가 지금 당장, 어제, 그리고 내일도 만날 수 있는 상황이다.
1. 무능력한 경영진의 삽질
2. 멍청한 동료 개발자의 어설픈 코드
3. 특정 기술이 무슨 이유에서 쓰이는지도 모르고 강제로 배우거나 사용해야 하는 것
4. 재미있어 시작한 개발일이 정말 반복적인 작업에 의해서 재미없어졌을 때
5. 이제 쏟아지는 버그를 만나게 되었을 때
하지만 가장 두려운 상황의 최고봉은 역시, ‘개발자는 고객과 대화를 나누는 것이 가장 두렵다’라는 것이 정답일 것이다. 그리고, 두려운 것은 동료와의 커뮤니케이션과 소통이다. 아마도, 이러한 고객과 동료들 사이에 있다면, 개발자는 당연한 것이지만. ‘개발하는 것이 행복하지 않다’라고 느끼는 것은 매우 당연할 것이다.
여기서. DevOps는 출발한다.
이렇게 ‘개발하지 않는 것이 불행한 개발일’을 하지 않게 하기 위한 일종의 movement라고 생각하면 된다.
아이러니 하지만, 이러한 불행을 해결할 가장 좋은 방법은 행복의 최소 조건이나 개발자가 원하는 개발환경의 최소 조건을 만족하면 된다. 그것은 바로 자원(resource)이 충분한 환경을 만들면 가능하다. ‘돈’이 넉넉하면 부수적으로 대부분 따라오는 것들이다.
하지만, 실제 개발일을 이런 환경에서 할 수 있는 방법은, ‘취미’로 개발일을 하는 경우에만 100% 만족할 수 있을 것이다. 취미는 최종 개발완룐일을 언제든지 뒤로 미룰 수 있기 때문에 ‘무한정의 리소스’를 투입할 수 있는 유일한 방법일 것이다.
DevOps는 개발자가 행복하게 소프트웨어를 개발할 수 있는 환경을 만드는 것이 목표이다. 과거의 개발 방법론이나 문화, 운동들이 대부분 ‘소프트웨어 품질’을 위해서 개개인의 시간과 개개인의 능력 차이를 무시하고 진행되었다면, DevOps는 그 우선순위의 가장 높은 개념으로 ‘개발자의 행복’을 우선순위 위에 둔다.
결론적으로 ‘개발자가 행복’하다면,
자연스럽게 소프트웨어의 ‘품질’을 올라간다는 개념이다.
물론, ‘행복’이 아니라, ‘시간 낭비’라는 단어와 ‘물자와 자원 낭비’라는 결코, 개발자는 행복하지 않을 것이다. 대부분의 개발자들은 ‘시간과 자원의 낭비’를 가장 싫어한다. DevOps는 기본적으로 개발자들을 신뢰해야 형성된다.
DevOps는 소프트웨어 개발과 운영, 서비스의 효율적인 환경을 만들기 위해서 노력하는 개발 문화로써 간단하게 줄여서 설명하자면. ‘소비자, 사용자들의 서비스의 요구사항을 가장 빠르고 단순화하여 대응할 수 있는 신속한 서비스 지원 형태. 그리고, 그것을 지원하고 유지시켜주는 소프트웨어 개발 문화’라고 이야기할 수 있다. 그래서 Development / Operations를 합친 말이라고 본다.
물론, 이렇게 만들어진 환경은 당연하지만 개발자를 ‘행복’하게 할 것이다.
DevOps는 빠르고, 단순화, 신속함이라는 서비스 형태를 지향한다. 그리고, 그것을 지원하고 유지시켜주는 소프트웨어 개발 문화를 지향하고 있다. 실제, DevOps를 구현했다고 평가를 받고 있는 Netflix와 Flickr 등의 개발 성과물들은 정말 놀라울 정도로 효과적이다.
1만 개 이상의 AWS 인스턴스를 불과 10여 명의 DevOps팀이 운영하고, 초당 4만 장 이상의 업로드 부하를 버티고. 자동화된 상태에서 하루 10회 이상의 배포본이 반영되는 매우 효과적인 개발과 운영이 접목된 환경을 만들어 낸다는 사실에 개발자 문화의 최신화 경향을 만들어 냈다.
이렇든 엄청난 효율과 고속의 처리를 만들어 낸 것은 어떤 이유 때문에 가능한 것이었을까? 그리고, 이러한 DevOps의 성과물들은 일반적인 IT기업에서도 얻을 수 있는 환경일까? 가장 먼저 DevOps의 장점을 몇 가지 정리하고 넘어가자.
DevOps의 장점을 서술한다면 다음의 3가지로 선언할 수 있다.
1. 최소 인원으로의 개발과 운영이 가능한 환경을 지향한다
2. 서비스의 배포와 운영이 자유롭고, 서비스가 매우 신속하고 빠르게 운영된다.
3. 개발의 배포가 자동화되며, 그에 따라 고품질 서비스를 지향한다.
자, 그렇다면. 가장 중요한 것은 이러한 DevOps는 내가 속한 조직에서 만들 수 있는 문화와 개발형 태인가? 대부분의 개발 조직에서는 이러한 것에 대해서 가장 궁금할 것이다. 결론부터 이야기하자면 DevOps가 가동되고, 개발 조직의 문화가 되려면 다음의 두 가지가 필수이다.
1. 소프트웨어를 잘 만들어내는 개발자
2. 잘 동작하도록 운영하는 운영자
그리고, 이러한 두 가지의 조건을 만족시키기 위한 기본적인 환경적인 구성이 필요하다. 그것은 가장 먼저 소프트웨어 품질을 관리하는 제대로 된 품질관리 조직이 있어야 하며, 개발 조직이 빠르게 소프트웨어를 개발, 빌드, 테스트, 배포, 운영하게 할 수 있는 사이클을 신속하게 진행할 수 있는 개발환경을 갖추고 있어야 하고 업무 프로세스를 정의하고, 각 조직 간의 역할을 조율하는 프로세스들이 매우 자연스럽게 자동화되어지고 효율적으로 운영되고 있어야 한다. 그래야, ‘소프트웨어를 잘 만들어내는 개발자’와 ‘잘 동작하도록 운영하는 운용자’가 만들어지게 되고, 그 역할과 방법론이 효율적으로 가동되는 DevOps는 가동된다.
DevOps의 원칙
그렇다면, 이러한 DevOps을 세팅하고 구입하기 위해서 조직이 필요로 하는 비용적인 측면은 어떤 것들이 있을 것인지 가볍게 살펴보자. DevOps는 매우 큰 비용을 요구하는 것은 아니다. 다만, 그 비용이라는 것이 전반적으로 투자된 비용을 의미하는 것이지, 단기간에 투입되어 얻어지는 효과는 아니라는 점에 주목해야 한다.
가장 먼저, 개발자들은 기능 개발과 결함의 수정 등의 변화를 얼마나 자주 일으키고 있는지 체크하고 이를 관리하거나, 관리할 수 있는 포인트를 개발자들에게 제공하고 있는가? 하는 측면이 가장 먼저라고 할 수 있다.
두 번째는 운영자가 실제 서비스의 안전성과 성능의 향상을 위하여 취해지는 시스템 아키텍처 적인 변화에 대해서 얼마나 두려워하고 있으며, 이를 얼마나 수치화하여 관리하고있는지, 그리고. 그 선택을 할 수 있는지가 DevOps에 가장 중요한 측면이기도 하다.
세 번째는 이러한 개발집단과 운영 집단에서 선택과 운영, 개발의 우선순위 등을 고르고 선택할 수 있는 ‘권한과 책임’이 주어지고 있느냐 하는 점이다.
네 번째는 큰 조직, 큰 기업, 큰 프로세스의 운영 시에는 이러한 DevOps와 같은 콘셉트는 운영하기 매우 어렵다. 그러므로, 개발과 운영환경의 구분과 절차. 권한과 릴리즈 절차와 규칙 등에 대해서 얼마나 세분화하고 있는지, 그리고. 일에 대해서 얼마나 작은 규모로 산정하고 산출하고 있는지에 대해서도 정의되어야 한다.
아쉽게도 DevOps를 구현하고 싶지만, 착각하고 있는 개발자 조직의 경우의 사례를 살펴보면 다음과 같은 실제 일들이 벌어진다고 볼 수 있다.
1. 사용하지도 않는 기능을 도출하고, 이를 위하여 시간과 비용을 낭비하고 있는 경우
2. 개발 후 버그를 찾기 위해서 테스트를 하고 있다고 프로세스를 정형화하는 일이다. 실제 DevOps를 지향하는 개발 조직의 경우에는 내부적으로 개발 단계에서 충분하게 품질을 고려하여 디자인되고 개발을 진행하려 노력한다.
3. 예측을 위한 투자를 많이 하고 있는가?라는 질문에 소극적인 경우이다. 대부분은 그나마. 사건 발생 시에 빠르게 대처할 수 있는 환경이라고 가능한 구축하라고 권하는 경우가 태반이다.
4. 소프트웨어 공학을 잘 못 받아들여 정말 중요한 지표에 집중해야 하는데, 너무 많은 지표를 도출하기 위하여 삽질을 하는 경우가 대표적인 착각되어진 개발 조직의 경우라고 볼 수 있다.
DevOps을 좁게 보는 진정한 장점
DevOps는 ‘잦은 배포’를 수행하면서, 잦은 릴리즈를 수행하고, 잦은 릴리즈를 통해서 위험을 하향 균등화 시키는 것이 주목적이라고 작게 정의할 수 있기도 하다. 그래서, 애자일과도 아주 잘 맞는다. TimeBox를 2주로 맞추거나 1.5주로 맞추고 배포를 진행하는 경우도 빈번하게 필자는 상황을 참조한다.
하지만, 이러한 DevOps를 구현하는 데 있어서는 다음과 같은 최소한의 필요충분 요건이 필요하다.
1. 잦은 개발과 버그 픽스가 가능한 개발자 환경을 구현하라
2. 공유 소스 코드 버전 관리시스템도 없다면, 이러한 환경을 구성한 다는 것은 거의 불가능하지 않겠는가?
3. 빌드, 테스트, 배포 단계를 자동화하기 위하여 얼마나 노력하고 있는가?
4. 수작업의 실수와 반복을 어떻게 최소화하기 위해서 노력하는가?
5. 개발 조직과 운영조직의 협업을 위하여 빈번한 커뮤니케이션 소통 비용을 지불하고 있는가?
이러한 최소한의 필요충분조건을 만족한다면, 개발 조직은 다음과 같은 최소한의 목표를 이루기 위해서 준비를 한다고 볼 수 있다.
1. 개발과 품질관리, 운영을 교집합적으로 운영하기 위한 방법을 터득하였고, 그것을 개발 조직에 내재화하기 위하여 노력 중이다.
2. 신뢰성, 보안성, 개발과 배포 사이클을 보다 더 빠르게 개선하기 위해서 배포, 테스트, 세부 기능 개발, 릴리즈 관리를 목표로 조직이 운영 중이다.
3. 툴이 아니라, 문화와 일하는 방법에 대한 경험을 더 우선적으로 하고 있다.
DevOps의 가장 중요한 원칙
위에서 이야기한 필요조건과 환경에 대한 것이 준비가 된다면, 다음과 같은 DevOps의 원칙을 실현할 준비가 된 것이다. 그 원칙을 살펴보자
1. 주요 기능에 집중하고 있는가?
2. 품질을 내재화하기 위하여 노력하고 있는가?
3. 개발에 필요한 지식을 창출하기 위해서 과학적으로 접근하고 있는가?
4. 완벽한 명세서를 만들기 위한 비용보다, 명쾌한 협업을 중시하여 커뮤니케이션 비용을 지출하고 있는가?
5. 가능한 한 빨리 개발하기 위해서 시도하고 있는가?
6. 사람을 존중하는 개발자 문화를 만들고 있는가?
7. 최적화를 위한 방안을 고안하는데 회의나 토론을 아까워하지 않고 있으며, 그것에 대해서 투자를 아낌없이 하고 있는가?
이러한 과정은 DevOps에 대해서 실현하기 위해서 노력하는 행위와 절차라고 볼 수 있다. 가능하다면 DevOps의 성숙도 모델에 대한 설명과 실제 우리가 그러한 모델을 통해서 개발 조직에 DevOps의 사상을 표현할 수 있는지에 대해서 설명할 기회가 곧 다가올 것으로 기대해본다.
물론, 기술적 부채에 대해서도 한 번 거론한 다음에 그 이야기를 이야기하도록 하겠다.
DevOps는 애자일과 마찬가지로 선언이고 문화에 해당한다. 즐거운 개발을 지향하고 있다면 소프트웨어 품질은 매우 당연하게 좋아진다. 행복한 개발자가 훌륭한 소프트웨어를 만든다는 것을 잊지 말자. 그것이 DevOps의 시작이며, 출발이다.
