데브옵스?
개발자로 지내다보면 DevOps라는 개념이 자주 들린다. ‘Development’와 ‘Operations’의 합성어로 개발과 운영을 아울러 전체 소프트웨어 생명주기를 서로 긴밀하게 통합하여 관리.. 한다는 이야기인거 같다.
소프트웨어 개발 생명주기 (Software Development Life Cycle, SDLC)
시작부터 어떤 용어가 등장하고 말았다..
대개 소프트웨어를 개발함에 있어 아래의 단계를 따른다고 한다.
요구사항 분석 → 설계 → 개발 → 테스트 → 운영
이러한 과정을 소프트웨어 개발 생명주기라고 하는 모양인데, 당연하다면 당연한 내용 같지만.. 이 생명주기를 관리하기 위한 개발방법론들이 많다. 일은 혼자하는게 아니니, 체계를 갖추고자 함일 것이다. 이러한 방법론을 대표적으로 꼽자면 폭포수 방법론, 애자일 방법론이 있을 수 있겠다.
폭포수 (Waterfall) 방법론
폭포수처럼 떨어진다
공업에서 사용하는 정형적 프로세스 제어 모델로부터 시작했다고 하며, 위의 생명주기를 일련의 차례와 탄탄한 계획을 기반으로 하여 개발을 진행한다. 따라서 굉장히 체계적이라 문서화를 통하여 진행사항을 쉽고 확실하게 파악할수도 있고, 당연히 프로젝트 관리 또한 용이할 것이다. 괜히 전통 공업에서부터 이 방법론이 대두된 게 아니다. 90년대까지 아주 열일 했다고 한다.
허나 고객의 요구사항이 명확하지 않을 때가 많고(…많은 수준이 아니라 거의 대부분이다), 프로젝트 규모가 커질 수록 과정을 체계화하거나 이해하기 어렵게 된다. 구현할 작업들의 난이도 짐작이 어렵게 되기 때문에 계획 자체에 차질이 생기는 경우가 있을 수 있고, 나중에 운영 과정에 들어서더라도 발생하는 피드백도 반영하기 어려울 것이다.
애자일 (Agile) 방법론
계속하여 이어지는 돼지꼬리의 연속
http://agilemanifesto.org/iso/ko/manifesto.html
- 애자일 선언문 (2001)
그래서 대두된 것들 중 하나가 애자일 방법론이라 할 수 있겠다. 계획이나 문서가 아닌 실질적인 코딩 중심으로, 빠르고 잦은 피드백을 통하여 빠른 개발, 빠른 릴리즈를 도모한다. 우선 피드백을 받으려면 기능이 있어야 할테니, 개발 대상을 우선 다수의 작은 기능으로 분할해서 하나의 기능을 위 생명주기 내에 개발한다. 이러한 생명주기를 반복해 나가며 기능을 하나씩 추가하는 방법이라 할 수 있겠다. 꼭 기능이 아니더라도 대략적인 틀 부터 진행할 수도 있고.. 여튼 이러한 방법은 당연히 요구사항의 추가/변화, 버그 등에 빠르게 대처 가능할 것이다.
요즘은 대부분 이런식으로 개발을 진행하고 있는 듯 하다…만 이런 그럴듯한 방법론에서도 문제는 발생했는데, 시스템이 날로 복잡해지면서 개발이 빠른건 운영 집단 쪽에선 달가워할 일이 아니었다. 기존 시스템에 익숙해졌더니 새로운 기술이 도입되어 또다른 적응 문제를 일으키고, 개인 컴퓨터에서 웹 서비스로 옮겨오며 거대해지는 운영 환경에 익숙하지 않은 채로 개발을 진행하려니 이 또한 버그 양산의 원인.. 빠른 개발과 안정적 운영의 가치 사이에 충돌이 발생하게 되었다.
데브옵스 (Development&Operations, DevOps)
그럴싸해 보이는 무한대 기호
- 2009 오렐리 벨로시티 컨퍼런스(O’Reilly Velocity Conference)
10+ Deploys per Day: Dev and Ops Cooperation at Flickr
플리커(Flickr)의 존 얼스퍼(John Allspaw)와 폴 해먼드(Paul Hammond)는 컨퍼런스에서 개발팀과 운영팀이 티격태격하는 연기를 선보였다고 한다. 이들의 명연기는 IT업계의 심금을 울려 개발 집단과 운영 집단의 통합 필요성을 화두로 던지게 되었고, 여기에 감명받은 패트릭 드부아(Patrick Debois)라는 양반에게서 이듬해 DevOps라는 용어가 탄생했다고 한다.
개념을 따지자면 개발과 운영, 즉 소프트웨어 개발자와 서버, 네트워크, 데이터베이스 등의 정보 기술 전문가들과의 긴밀한 소통, 협업, 통합을 강조하는 방법론이라 할 수 있다. 애자일 방법론중 하나의 분류로 이야기하는 사람도 있고 더 발전된 방법론이라 말하는 사람도 있고 해서 약간 갈리지만 결국 키워드는 소통, 협업, 통합이다. 이를 위한 프로세스 구축, 도구 사용 등등을 통틀어 다 데브옵스라 이야기하고 있는 듯하다.
허나 여기서도 또 논란거리는 있다. 데브옵스가 기업들의 수직적 구조와 맞고 기존 레거시 운영 방식, 레거시 코드 등이 협업과 정면충돌 한다는 점이 있다. 데브옵스가 딱히 비용절감을 의미하는 것도 아니라 꺼리는 곳이 있는 한편, 여기서 비용절감을 쏠쏠히 챙기는 모양인지 소위 헬적화..라고 할수 있을까? 개발/운영간의 업무 불균형이 발생, 개발자가 운영 업무까지 떠안게 되는 경우가 발생하는가 하면 여기에서 또 DBA 등 운영 전문가들의 자리가 줄고 있다는 시각도 있는 모양이다.
CI / CD
무한대 기호의 좌/우익이 각각 CI / CD
여튼 이런 데브옵스를 구현하기 위하여, 개발 단계를 자동화하여 소프트웨어/어플리케이션을 짧은 주기로 제공하는데 이게 즉 CI / CD이다.
Continuous Integration (지속적 통합)
개발자를 위한 프로세스로, 코드 변경 사항이 있을 경우 자동으로 병합 및 정기적으로 테스트, 빌드되어 여러 개발자가 동시에 어플리케이션 개발 작업을 할 경우 서로 코드가 충돌할 수 있는 위험을 해결할 수 있다.Continuous Delivery (지속적 제공/전달)
개발자들이 적용한 변경 사항의 테스트를 거친 이후 Repository (저장소) 등에 지속적으로 업로드하여, 운영팀이 이 저장소를 통하여 실시간 운영 환경으로 구축할 수 있게끔 한다.Continuous Deployment (지속적 배포)
개발자의 변경 사항을 실시간 운영 환경으로까지 자동으로 배포하는 일련의 과정으로, 수동 작업을 줄여서 프로세스의 과부하를 해결한다.
대략적으로 이렇게 나누는 듯 하며, 2와 3의 내용은 혼합되어 한단계로 줄여 사용하기도 하는거 같다. 결국은 수동으로 일일이 하던 작업을 자동화하여 편하게 하자는 일이라 할 수 있겠다. 그렇지만 직접 이 프로세스를 구현하자면 수많은 협의와 스크립트 만들기 등등 꽤 많은 작업량을 가지게 되기에, 대부분은 이런 파이프라인을 툴로써 극복하고 있는 것처럼 보인다. 우선은 툴 사용법을 알고 볼 일이다.
데브옵스 툴은 굉장히 많은 종류가 있는 모양인데,,
조만간에 CI/CD 툴도 한번 다루어 보아야 하겠다. 저중에서 제법 유명한 젠킨스를 한번 다뤄보고 싶다.