데브옵스 DevOps(Development + Operations)

군전역후 동대문에서 패션·IT 스타트업을 할 때 알게 된 개념이다. 

전체 인원이라 해봐야 기껏해야 6명이 전부인 상황. 그 중에서 운영진(2명), 패션팀(2명), IT팀(2명) 나뉘어 있었는데 각 그룹간 의사소통에 어려움을 느꼈다. 패션팀과 IT팀 서로 쓰는 용어도 달랐고 생각하는 방식도 다르니 협업을 할 때에도 불편함을 느꼈고, 운영진과도 마찬가지였다. 또한 나름 패션(?)계 였기에 유저들의 반응 모니터링도 중요했고 이런저런 이유로 방법을 찾던중 DevOps를 처음 알게 되었다.

즉, 개발과 운영에는 관점의 차이가 존재하고, 이러한 차이가 효율적인 IT 운영을 저해하므로 이 차이를 없애보자는 것이다.

당시 기존에 갖춰진 시스템이 없던 상황이었기에 DevOps가 나름대로는 잘 받아들여졌다. 이후 다른 그룹에 DevOps 도입 시도를 하였으나 실패하였다. 이유는 뒤에 나온다. 

DevOps WIKI적 의미

 데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

애자일 and 폭포수 모델

 DevOps를 이해하기 전에 애자일과 폭포수 모델을 잠깐 짚고 넘어가자.

폭포수모델 - 타당성 조사, 요구조건 분석, 외부 설계 문서 작성, ....., 테스트, 제작 같은 일련의 단계를 순차적으로 진행. 

일련의 차례와 탄탄한 계획을 기반으로 개발을 진행한다. 이해도 쉽고 사용도 쉬운 기법이다. 하지만 이로 인해 납기일 전 철야, 철야에도 불구한 납기일 지연 등의 부작용이 있었다.

애자일 - 폭포수 모델의 부작용이 개발 프로세스 접근법이 잘못된 것으로 판단, 접근법을 반대로 바꿔버린다. 앞을 길게 예측해 개발을 하지 않고, 일정한 주기로 끊임없이 프로토타입을 만들어낸다. 프로토타입의 반응을 통해 요구를 더하고 수정하여 전체적인 S/W를 만들어 간다.

애자일 12가지 원칙

우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.

비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.

동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

작동하는 소프트웨어가 진척의 주된 척도이다.

애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.

기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.

최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.

팀은 정기적으로 어떻게 더 효과적이 될지숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

이렇듯 애자일은 끊임없는 변화를 도모하고 이것이 더 발전하여 DevOps가 된다. 끊임 없는 변화를 자동화하고 수많은 기능들을 이용하여 전체 개발 주기를 아우른다.

Tool 관점의 DevOps

<Marketplace for DevOps apps>

DevOps를 자동화의 관점에서 보았을 때 정말 많은 Tools의 도움을 받을 수 있다.

크게 CI(Continuous Integration), CD(Continuous Delivery), Monitoring을 꼽는다.

CI 각 개발자의 소스 통합을 주기적으로 수행함으로써 통합에서 발생하는 오류를 사전에 해결한다. 

CD User에게 최대한 빠르고 효율적으로 새로운 기능을 제공하는 것이 목표. 딜리버리 파이프라인을 구축하면 배포 횟수가 total cost에 큰 영향을 미치지 않는다. 지속적으로 릴리즈가 검증되니 품일이 낮거나 오류가 많은 릴리즈가 발생할 위험이 감소된다. 이는 제품의 전체적인 품질을 높인다.

Monitoring Server의 상태부터 각 제품 상태, 제품의 시장반응 등을 관찰한다.

대표 Tool: Jenkins, Travis, Docker, Git, Slack, NewRelic, Zapier

Git, Docker, Jenkins 등을 이용하여 CI/CD를 구축하고 NewRelic 등을 통해 서버 모니터링, Zapier 등을 통해 시장반응(ex. Instagram)을 모니터링 할 수 있다. 그리고 이 모든 것을 협업 tool인 Slack 내에서 알림을 받고 각 팀간 소통할 수 있다. Slack에서 정말 많은 App들을 Integration있어 매우 좋아한다. New Relic에서 오는 서버 위험 경고, 인스타에 우리 제품이 태그된 알림 등을 다 슬랙으로 몰아 받을 수 있어 슬랙내에서 간략한 전체관리가 가능해진다. 또한 슬랙 채널이라는 기능도 잘 쓰면 슬랙 자체만으로도 강력한 도구가 될 수 있다.

Top Continuous Integration Tools: 51 Tools to Streamline Your Development Process, Boost Quality, and Enhance Accuracy

Slack App

DevOps는 문화

 DevOps를 단순히 Tool을 통해 자동화를 구축하여 이점을 구할 수 있다라고 생각한다면 오산이다. 단순히 내부인원에게 DevOps를 설명하고 이러한 이점이 있으니 오늘부터 당장하자! 라고 하면 아무도 하지 않는다. 기존에 일하던 방식과도 큰 차이가 있으며 내부인원 스스로 필요성을 느끼지 못하기 때문에 DevOps 도입에 에너지만 낭비하는 꼴이 된다. 타국에 한국의 문화를 전파하듯, 문명에서 타국에 문화를 전파하여 문화정복을 하듯 해야한다. 

잠깐 랩실에 들어갔을때 랩실 연구원들이 두개의 건물에 나뉘어져 있었다. 프로젝트별로 랩실을 나눠서 인원을 배치 하였지만 한 랩실의 인원이 찢어진 상황이었기에 교수님은 소통의 부재를 느꼈고 이 상황을 타파하기 위해 DevOps라는 개념을 제시하고 랩실전체모임에서 발표까지 하였다. 물론 그 당시 미숙한 부분도 있었겠지만..도입 이후 몇몇만이 DevOps의 변화에 참여해주었고 이 마저도 시간이 흐를수록 미미해졌다. 결정권자에 의해 DevOps가 도입이 되어서? 아니 구성원 모두가 DevOps의 필요성을 느끼지 못해서라고 추측한다. 이것이 앞서 말한 DevOps 도입 실패 사례다.

구성원 모두가 DevOps의 필요성을 느끼게 해야한다. 평소에 DevOps를 설명하거나 이러한 점이 더 편해지고 빨라지는 등의 장점을 설명하여 DevOps의 벽을 허물어야한다. 그리고 단계적으로 DevOps를 구축해 나간다. 그렇다면 성공적으로 DevOps를 구축할 수 있을 것이다.

DevOps는 단순한 자동화가 아니며 협업의 문화이다. DevOps Team을 따로 두는 기업도 있지만 DevOps가 별도의 분야라는 생각을 벗어나야 한다. 개발자로서 본인과 다른 분야 사람들과 협업할 줄 아는 힘인 것이다.

DevOps를 처음 알았을때만 해도 국내인지도는 미미했으며 외국에서 각광받기 시작했다. 지금 글을 쓰는 현재 시점에서 국내 DevOps 관련 사례 및 일자리 등 많이 찾아 볼 수 있다. 

- 최근에는 AIOps라는 용어도 등장했다. 시간난다면 써보도록 하겠다.