데브옵스(DevOps)

1. 데브옵스의 시작:

1990년대로 넘어오면서 기존의 복잡하고 무거운 개발 방법론에서 벗어나 좀 더 가볍고 유연한 접근 방법을 시도하면서 다양한 SW 개발 방법론들이 본격적으로 소개되기 시작되었다.

이러한 경량화 개발 방법론을 논의하기 위해 당대 내노라 하는 이들 개발자들이 모여 경량화 방법론에서 논의한 끝에 애자일 소프트웨어 개발의 목적과 가치를 애자일 선언문 형식(Agile Manifesto, 2001)으로 발표하면서 본격적으로 탄생하였다.

애자일은 전통적이지만 무거운 폭포수 방법론 대신 빠르게 개발하는 접근 방식으로 2000년대 IT 전성시대를 구가하는데 이바지하였다.

< 프로세스와 조직 관점에서의 애자일 수행방법 >

그러나 시스템 규모가 커지고 복잡해지면서 보다 안정적인 운영을 필요로 하게 되고 빠른 개발 방식에도 태클이 걸리기 시작하였고, 빠르고 새로운 변화를 시도하는 개발과 장애없고 안정적인 운영이라는 서로의 입장은 너무 달라 개발과 운영 간에 깊은 갈등이 빚어짐

• 변경이라는 한 가지 요소만 놓고 생각해 봐도 차이는 분명해진다. 개발팀은 변경이 자신의 가치를 증명하는 것이라고 생각하며 새로운 것을 계속 만들어내지 않으면 개발팀은 존재의 의미가 없어진다. 하지만 운영팀에게 변경은 적 그 자체인데 변경은 운영팀의 지상과제인 안정적인 운영을 방해하는 요소이기 때문이다.

< 개발팀과 운영팀과의 마찰 >

2007년 패트릭 드보아라는 IT 컨설턴트가 애자일 방법론으로 대규모 정부 사업을 컨설팅하게 되었는데 개발팀과 운영팀간 견해 차이로 협업이 어렵자 이 문제를 해결하기 위한 고민을 하기 시작하였으며, 벨기에 겐트(Ghent) 지역에서 DevOpsdays 컨퍼런스를 개최하면서 공식적으로 "DevOps라는 용어가 공식적으로 쓰이기 시작

2. 데브옵스의 정의 및 핵심개념

앞서 언급하였듯이 데브옵스라는 용어는 벨기에의 IT컨설턴트 패트릭 드보아에 의해 devopsdays 컨퍼런스가 최초 개최되면서 공식적으로 사용되기 시작되었다. 비지니스 변화에 민감하여 빠르게 대응해야 하는 개발자 입장과 장애없이 안정적 운영을 위해 변화를 지양하는 운영자들 사이의 심화된 갈등을 해소하기 위해서 드보아는 새로운 체계와 규칙 및 인프라 환경 등이 필요하다고 생각하였다.

< 다양한 데브옵스에 대한 정의 >

데브옵스라는 개념이 덩치가 크다보니 각자의 입장에서 부분적으로 이해하고 경험한 것을 마치 전부인 양 인식하는 오해와 혼돈이 있는데 데브옵스의 전체 모습을 그만큼 이해하기 어렵다는 뜻이다.

< 데브옵스의 정의 >

데브옵스는 단순히 데브 + 옵스가 아니며 단순 도구를 넘어서 조직 전반의 문화와 철학까지 아우르는 개념이다. 데브옵스의 정의는 위와 같이 문화이자 철학, 전문적인 운동이라고 하였는데, 이러한 정의는 현실 세계에서 적용하기에는 사실 모호한 면이 있고 아래 그림과 같이 개발-운영간 프로세스간 통합 및 협업체계라 표현해주는 것이 IT 엔지니어에게는 좀 더 쉽게 와닿을 수 있다.

애자일에서는 고객의 가치를 빠르게 전달하기 위해 더 자주, 더 빨리 완성된 제품을 릴리즈하는 것을 목표로 한다. 여기서 완성된 제품이란 전체 모든 기능의 완성을 의미하는 것이 아니라 제품의 증분(Increment)을 말하는데, 제품의 부분 기능을 점진적으로 완성하여 고객에게 빨리 자주 전달하는 것을 의미한다.

결과적으로 데브옵스에서 말하는 CI/CD는 애자일 개발 방식이 운영에까지 확장된 개념이며, 이제 “지속적 통합 및 지속적 전달”의 개념은 요즘 IT개발-운영 환경에서 가장 중요하게 여기는 주요한 프랙티스가 되었으며 이를 위해 "자동화"가 핵심적인 성공요소이다.

 

일반적으로 아래와 같은 DevOps정의가 자주 사용된다.

 

"DevOps는 대규모 SW 시스템 운영 효율화를 위해 등장한 개념이다. 지속적 통합(CI)과 지속적 배포(CD)를 운영 과정에 도입해 개발 주기 단축, 배포 속도 증가, 안정적인 출시와 같은 효과를 낸다."

3. 데브옵스 생태계

데브옵스의 실무적 구현 기술의 핵심 개념인 CI/CD 및 주요 추가적인 프랙티스를 구현하기 위해서는 필연적으로 자동화된 도구 사용이 따라와야 한다.

< 데브옵스 핵심 프랙티스 >

개발된 소스의 통합이 끊임없이 이루어지고 테스트와 배포 역시 신속하게 수행되기 위해서는 많은 프로세스와 절차들이 자동화되는 것은 당연하며, 자동화를 지원하기 위한 갖가지 도구를 통칭하여 “데브옵스 생태계”라고 하는데 Git이나, Junit, Docker와 Kubernetes와 같은 도구들도 데브옵스 생태계에 포함된다.

< 데브옵스 툴 체인 >

4. 데브옵스 엔지니어 역할

기존 개발 프로세스 중 폭포형 모델을 사용한 시스템 개발에서는

1. 애플리케이션 실행 환경 구축(인프라)은 네트워크나 하드웨어에 능통한 인프라 엔지니어가 담당
2. 애플리케이션 개발 부분은 업무 지식, 프로그래밍, 테스트 방법과 같은 기술을 잘 아는 애플리케이션 엔지니어가 담당

• 그러나 클라우드의 등장으로 온프레미스 환경에서 가동 시키던 서버들을 클라우드 상의 인스턴스로 옮기고, 데이터베이스나 네트워크와 같은 클라우드 서비스를 이용함으로써 실행 환경의 구축 범위가 극도로 줄어들어 짧은 사이클로 릴리스를 반복하는 스타일로 변경되었다.
• 또한, 이와 같은 분산 환경에서는 인프라 엔지니어가 수동으로 운용을 하지 않고 자동화된 툴을 사용하여 오케스트레이션으로 관리할 수 있다. 그 결과 개발팀이 세부적인 인프라 환경에 대한 최소한의 이해로 배포, 통합, 유지관리, 업데이트 등의 작업을 수행할 수 있게 되었다.

DevOps 모델에서는 개발팀과 운영팀이 더 이상 "사일로"에 묶여 있지 않으며, 이 두 팀이 단일팀으로 병합되어 엔지니어가 개발에서 테스트, 배포, 운영에 이르기까지 전체 애플리케이션 수명 주기에 걸쳐 작업하고 단일 기능에 한정되지 않은 광범위한 기술을 개발한다.

또한, 애플리케이션을 안정적으로 빠르게 운영하고 개선하는 데 도움이 되는 기술 스택과 도구를 사용하여 엔지니어는 이전 같았으면 다른 팀의 도움이 필요했을 코드 배포 또는 인프라 프로비저닝과 같은 작업을 독립적으로 수행할 수 있다.

References:

[1] SK C&C, 데브옵스 알아가기 (1), (2): https://engineering-skcc.github.io/devops/DevOps2-%EB%8D%B0%EB%B8%8C%EC%98%B5%EC%8A%A4is/
[2] https://www.itworld.co.kr/news/85130

[3] https://www.econovill.com/news/articleView.html?idxno=384047
[4] https://hrbulletin.net/organizational-culture/%EC%99%9C-%EA%B8%B0%EB%AF%BC%ED%95%9Cagile-%EC%A1%B0%EC%A7%81%EC%9D%B4%EC%96%B4%EC%95%BC-%ED%95%98%EB%8A%94%EA%B0%80/
[5] https://velog.io/@xonic789/%EB%8C%80%EC%B2%B4-DevOps%EA%B0%80-%EB%AD%90%EB%83%90
[6] https://aws.amazon.com/ko/devops/what-is-devops/

[7] http://www.aitimes.com/news/articleView.html?idxno=139432