DevOps란

이전 포스트에서도 간단히 설명을 했지만 DevOps는 개발(Development)과 운영(Operation)이 합쳐진 형태를 말한다.

2020/02/05 - [DevOps] - 마이크로 서비스 아키텍처와 거버넌스 모델(+ 진화형 모델, DDD)   

 

이번에는 조금 더 깊이 DevOps가 나타난 환경과 특징에 대해 알아보려고 한다.

 

기존 개발 체계의 문제

전통적인 개발 운영 체계는 개발팀에 의해 개발이 끝나면 시스템은 테스트를 거쳐 운영팀으로 이관되고 운영팀은 해당 시스템을 배포/관리/운영한다.

 

시스템을 운영하다보면 장애가 반드시 생기기 마련이다. 문제는 여기에 있다.

개발팀에서는 애플리케이션에 대한 이해가 있지만, 인프라 시스템에 대한 이해는 없다.

반대로 운영팀은 인프라 시스템에 대한 이해는 있지만, 애플리케이션에 자체에 대한 이해는 부족하다.

 

그렇기에 문제 발생시에 책임전가가 발생하며 "Fingerpointyness" 상황 즉, 누가, 어떤 문제를 해결해야 하는지 정의되지 않은 상태에서 엉뚱한 방향으로 흘러가게 되는 일이 발생한다.

 

또한, 개발팀은 개발이 끝나 운영팀으로 시스템이 이관된다면 시스템에 대한 관심을 더 이상 가지지 않는다. 고객과의 접점 또한 없다.

하지만 운영팀은 서비스를 지속적으로 관여하며 사용자들과의 접촉이 끝임없이 발생한다. 따라서 시스템의 개선이 필요하다고 생각하지만 이미 개발팀은 개발이 끝났다고 판단하기에 추가적인 개선을 수용하지 않는게 대부분이다.

 

해결책?

위의 글만 본다면 개발팀과 운영팀은 앙숙관계로 보일 수 있다. 그렇다면 이 둘의 관계에서 발생하는 문제는 어떻게 해결할 수 있을까?

 

1. 기획과 개발을 합친다.

간단하다. 기획, 개발, 운영팀간의 많은 대화와 좋은 관계를 형성한다면 된다. 이러한 방법이 반영된 것이 애자일 방법이다.

기획과 개발팀을 하나의 팀으로 합쳐 요구사항을 빠르게 반응하도록 구조를 만든다.

 

2. 개발과 운영을 합친다.

조금 더 최적화 시키기 위해, 기획과 개발을 합치듯이 서로 앙숙관계인 개발과 운영팀을 합친다.

 

왜 이제서야 도입되었는가?

오픈소스의 발전

개념 그대로 적용을 한다면 개발과 운영이 합쳐진 DevOps 팀은 개발과 운영 즉, 개발자가 인프라에 대한 개념까지 알아야 한다. 반대로 운영에 대해서만 아는것이 아닌 개발에 대한 이해가 필요하다.

 

오픈소스가 발전하게 되면서 많은 엔터프라이즈 제품을 활용하면서 사용할 수 있게 되었다.

 

좋은 도구

오픈소스의 발전으 연장으로 좋은 도구(Tools) 또한 많아졌다. 개발관련 도구 뿐만 아니라 빌드, 배포, 모니터링에 관한 도구도 많아졌기 대문에 운영관련 부분을 상당수 자동화 할 수 있게 되었다.

 

클라우드의 등장

클라우드 컴퓨터가 등장하면서 사용자가 직업 인프라를 구성하지 않아도 간단히 웹 사이트에서 서버, 스토리지, 네트워크 구성이 가능해졌다.

이는 오픈소스를 조합하여 시스템에 필요한 모듈을 만들고, 좋은 도구를 가지고 빌드 배포를 간단히 클라우드 환경에서 할 수 있다는 말이다.

한마디로 위의 등장으로 개발&운영을 할 수 있는 환경이 마련된 것이다.

 

DevOps의 특징

1. Cross Functional Team  - 한 팀은 기획, 개발, 운영 등 서비스의 필요한 모든 것을 할 수 있는 구조로 구성된다.

2. Widely Shared Metirc - 팀 전체가 기준으로 삼을 수 있는 서비스에 대한 공통지표(Matrix)가 필요하다. 이 공통 지표을 팀 전체가 공유 함으로써 팀 전체가 서비스에 대해 상태인지와 개선 작업 등을 효율적으로 할 수 있다.

3. Automating Repetitive Tasks - 반복적인 작업은 도구를 이용해서 자동화 한다.