신현묵 오픈헬스데이터 이사가 블로그에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
개발 방법론이나 소프트웨어 개발과 관련된 은빛 탄환과도 같은 뉘앙스를 풍기는 접근법은 수 없이 많았다. 이제는 최고의 화두로 떠오른 ‘DevOps’에 대해서 삐딱한 아키텍트의 생각으로 끄적거려 본다.
주변에 DevOps를 지향하는 개발회사들이 많다. 그리고, DevOps를 무슨 완전체인 것처럼 소개하는 칼럼이나 글들도 많다. 그렇다면 DevOps의 정체는 무엇이며, 우리 회사, 우리 개발팀이나 운영팀은 그런 준비가 되어 있는 것인지에 대해서 생각해야한다.
DevOps가 어떤 의미이기에 사람들이 궁금해하고 있는 것일까? 그리고, 과연 정말 내가 속한 조직과 팀이 DevOps를 지향할 수 있을까?
DevOps는 모든 팀, 모든 회사, 모든 곳에 사용되는 만병통치약은 아니다.
DevOps는 새로운 개념인가?
‘Culture’와 ‘movement’에 대해서 먼저 이야기를 시작하는 것이 맞을 듯하다. ‘Culture’는 어떤 한 국가나 집단의 문화와 같은 것을 의미한다. 그리고, ‘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회 이상의 배포본이 반영되는 매우 효과적인 개발과 운영이 접목된 환경을 만들어 낸다는 사실에 개발자 문화의 최신화 경향을 만들어 냈다.
2부에서 ‘DevOps의 원칙과 장점에’에 대해 소개합니다.
