전 시간에 멍청한 고래 아니 도커에 대해서 다뤄 보았다.
이전 게시글에서 마무리 하면서 잠깐 데브옵스 에 대해서 언급을 하며 끝이 났었는데
그런 의미로, 오늘은 데브옵스에 대해서 다뤄볼 예정이다.
데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다.
데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.
기존에는 개발자가 개발을 완료하면 운영자에게 전달해야하는게 일반적인 루트였다. 개발을 완료하더라도 운영자를 통해 배포되어야만 했고, 운영자는 개발자가 만든 프로그램을 이해하는데 시간이 필요했다. 이러한 과정 속에서 개발자와 운영자 간의 소통이 원활하지 않다면 시간이 더 지체되었다.
데브옵스는 이러한 개발 생태계를 더욱 효율적으로 바꾸고자 파생된 문화라고 할 수 있다.
앞서 언급한 것 처럼 데브옵스가 탄생하게 된 계기는 개발팀과 운용팀의 소통장벽 때문이다. 이 소통장벽을 '혼란의 벽(Confusion of Wall)'이라고 표현한다. 개발팀과 운용팀은 각자 나름대로 철학이 있기 때문에 혼란의 벽이 생긴다. 대표적인 소프트웨어 개발 방법론을 하나씩 알아보면서, 데브옵스가 어떻게 대두되었는지 알아보겠다.
학부 시절에 소프트웨어 공학 수업을 들어봤거나, 혹은 정보처리기사 시험을 준비해본 적이 있다면
소프트웨어 개발 방법론 중 대표적인 워터폴 모델과 애자일 모델에 대해 들어본 적이 있을 것이다.🙄
폭포수 모델은 1980년대 처음 도입된 상당히 무거운 프로젝트진행 공정이다. 다음과 같은 7단계로 구성되어있다. 기획, 문제정의, 설계, 개발, 테스트, 릴리즈, 운용의 프로세스을 동기식 진행으로 밟아나간다. 이 프로세스는 모든 단계가 끝나야만 일련의 프로세스가 새롭게 시작할 수 있다. 예상할 수 있듯이 제품에 이슈가 발생하면, 해결하기까지 상당히 오래걸린다. 신속하고 유연한 대처가 어렵다는 단점이 있다.
애자일 방식은 폭포수 모델의 단점을 보완한 방식으로, 모듈식 개발의 지속적통합이 이루어진다.
폭포수 모델처럼 큰 계획을 만들지 않고, 기능 구현을 함에 있어서, 문제정의(요구사항)를 시행하고, 개발단위를 모듈(잘게 나눈 기능단위)을 먼저 개발한 후, 시제품에 통합하는 과정을 반복한다.
애자일 개발방법론의 도입은 개발팀에서 많은 변화를 촉발하였다. 더 빨라진 소프트웨어 배포, 더 소소하고 빈번해진 소프트웨어 빌드, 새로운 요구 조건에 대한 빠른 개발과 응대 등..!
하지만 이러한 개발방법론의 도입은 운영팀에게 많은 부하와 운영적인 문제점을 촉발하게 되었다.😥
이로 인해 개발팀과 운영팀 간의 충돌과 이슈가 발생하게 되었다. 이에 대한 개선의 요구로 배포, 테스트, 빌드 등 개발과 운영의 전반적인 주기 자동화에 대한 필요성이 대두되었고, 데브옵스(DevOps)가 등장하게 된다.
데브옵스 툴체인(DevOps Toolchain)은 데브옵스를 위해 적용 가능한 툴들을 묶어 하나의 체인 형식으로 만드는 개념이다.
데브옵스 문화를 효과적으로 적용하기 위한 방법론으로 기획-코드-빌드-테스트-패키지-릴리스-구성-모니터링의 단계로 이루어진다.
지금까지 데브옵스의 개념에 대해서 간략하게 알아봤으며, 한마디로 정리하자면 아래와 같다.
개발팀과 운영팀의 경계를 허무는 파격적인 환경 조성을 통해 좀 더 효율적인 개발문화를 형성.
다음 포스팅에서는 더 알찬 IT 지식으로 찾아오도록 하겠다.😁