** 아래 글은 개인의 조사를 바탕으로 주관적으로 작성되었습니다. 잘못된 부분은 댓글로 남겨주시면 수정하겠습니다.
DevOps ?
최초 데브옵스의 개념은 2009년 O'Reilly에서 주회한 Velocity 컨퍼런스에서 등장했다고 한다.
당시 루디코프 사의 엔지니어 2명이 '10+ Deploys per Day : Dev and Ops Cooperation at Flickr' 라는 이름으로 프레젠테이션했다.
이 발표에선 전통적인 조직의 개발과 운용 부서는 서로 대립되는 구도에 놓인다고 했다.
가장 큰 이유는 각 부서의 입장 차이인데 개발 부서는 변화를 원하지만 운용 부서에서는 서비스의 안정을 위해 시스템의 큰 변화를 원치 않기 때문이다. 하지만 이런 대립 관계가 심화되면 아래의 과정을 거쳐 음의 무한반복 사이클(악순환)이 생기 때문에 조직에 많은 문제가 발생한다.
1. 운용 부서에서는 안정성을 이유로 개발 부서의 변화 의견을 거부한다.
2. 개발 부서는 임의로 내용을 변경하고 해당 내용을 운용 부서에 전달하지 않는다.
3. 운영 부서가 인지하지 못한 변화로 서비스에 예기치 못한 사고가 발생한다.
4. 위 과정이 반복되면 갈등이 더 심화되며, 심화된 갈등으로 더 깊의 음의 무한 반복 상태에 놓인다.
이런 문제를 해결하기 위해 발표에선 몇가지 도구와 문화, 그리고 변화에 대응하기 위한 지표를 제시하였지만 초반엔 기존의 기업 문화가 남아있어 많은 비난을 받았었다. 하지만 변화의 흐름이 빠른 현재는 DevOps 적용에 대한 긍정적인 신호들이 많이 보인다.
DevOps는 Development 팀과 Operations 팀 간의 원활하고 지속적인 커뮤니케이션, 협업, 통합, 가시성 및 투명성(Continuous Integration)을 추구한다. 이런 노력들은 추가 개선, 개발, 테스트 및 구축에 대한 지속적인 고객 피드백 루프를 추진하는 원동력이 되며, 필요한 기능의 변경 및 추가 작업을 더 빠르고 지속적으로 배포(Continuous Deployment)할 수 있게 된다.
DevOps 와 Agile 방법론
위의 이미지는 위키피디아에서 가져왔다. 개인적으로 DevOps의 위치를 가장 잘 요약한 그림이라고 생각한다.
방법론에 대한 자료를 조사하면서 Agile 방법론에 대한 내용을 많이 볼 수 있었는데 대부분은 DevOps가 Agile의 발전된 버전이라는 예시를 들었다. (정확한 비교는 아니라고 생각하지만 초반에 개념 이해에 도움을 줬다.)
소프트웨어 개발 방법론은 말 그대로 소프트웨어 만드는 방법에 대한 이론이다.
규모가 큰 소프트웨어의 개발을 위해서는 기획 의도와 구성, 절차 등을 미리 작성해둘 필요가 있기 때문에 전통적인 방법론(waterfall, CBD, 객체지향)들이 연구되고 프로젝트에 적용되었다. 하지만 전통적인 방법론들은 절차를 중시하여 설계 되었기 때문에 빠른 변화에 민첩하게 대응하기 어려웠다.
여기서 빠른 변화에 대한 대응을 위해 계약과 절차보다는 고객과의 상호작용과 협력을 더 중시하는 Agile 방법론이 발생하게 된다.
Agile과 DevOps의 지향점은 근본적으로 같지만 각 방법론의 목표와 실천 방식은 차이가 있다.
Agile은 빠른 프로토타입, 반복과 피드백을 통한 지속적인 퀄리티 향상을 추구하며 고객과의 상호작용에 초점을 두는 반면 DevOps는 상호작용을 포함하여 개발팀과 운영팀 간의 긴밀한 협력 관계를 구현할 수 있는 도구(파이프라인)의 구축을 추구한다. 또한 Agile은 각 상황별 장단점이 있는 다양한 방법론을 사용하는 등 여러 케이스를 나누고 각 케이스별 실천법을 다루지만 DevOps는 각 실천법들의 장점을 채택하여 하나의 체계로 녹여낸다는 차이점이 있다.
Agile은 눈에 보이지 않는 형이상학적 개념을 강조한다. DevOps 또한 동등한 개념과 가치를 중요하게 생각하지만, 도구와 프로세스 정규화 등을 통해 눈에 보이는 성과를 만들어 낼 수 있다. (이런 부분들 때문에 DevOps가 Agile의 발전형이라는 말이 나온 것 같다.) 하지만 업무 프로세스를 정규화하고 다양한 도구들을 사용해 환경을 구축한다고 하더라도 결국은 그걸 사용하는 사람들의 적극성과 이해도가 가장 중요하다.
그러므로 DevOps는 개발-운영팀은 물론 조직 내의 공통된 문화로 정착 되어야 하며, DevOps의 파이프라인은 각 부서의 특성과 문화를 고려하여 설계, 구축한 뒤에도 꾸준한 관리와 교육 훈련이 진행되어야 한다.
Why ?
DevOps는 문화이자 방법론이다. 최근의 공고를 보면 DevOps 엔지니어를 구한다는 글도 꽤 자주 보인다.
그런데 위의 엔지니어가 DevOps 방법론을 적용하고 조직에 어떤 문화를 만들어 주는 사람이나 역할을 지칭한다면 뭔가 이상하다. Agile 엔지니어 또는 객체지향, CBD 엔지니어라는 말은 들어본 적 없기 때문이다.
DevOps 엔지니어는 왜 필요할까?
당연히 정답은 없겠지만 여러 자료를 찾아보고 고민하면서 내가 내린 결론은 단순했다.
DevOps 자체로도 업무 범위가 넓고, 개발자나 운영자가 기존의 업무와 병행해서 하기 어렵기 때문이다. (팀의 능력이 뛰어나다면 가능은 하겠지만, 기존 팀의 업무에 추가로 적지 않은 양의 업무가 부여된다면 많은 문제가 생길 것 같다.) 또한 파이프 라인이 존재하기 때문에 기존의 방법론들보다는 해야할 일이 명확하고 가시성이 좋다.
DevOps 에서 파이프 라인은 자동화된 프로세스의 세트(CI/CD, 인프라와 툴체인 등)를 의미한다.
이런 파이프 라인은 소프트웨어의 생명 주기의 전체 과정에 관여하게 되는데, 이런 환경을 구성하려면 다양한 도구들을 다뤄야 한다. 또한 그렇게 환경을 만든 이후에도 해당 인프라를 안정적으로 관리, 모니터링하며 지속적인 교육과 홍보를 해야한다.
위 모든 업무를 기존의 업무와 병행하며 하기엔 물리적으로 힘들어보인다.
기존 팀에게 해당 업무를 부여할 경우, 효율을 올리기 위해 하는 업무가 오히려 팀의 발목을 잡는 것이다.
How ?
DevOps를 직접 구현해야 한다면 핵심 과제는 크게 문화와 파이프 라인이라는 2가지 범주로 나눠진다고 생각한다.
문화를 구현하는 방법은 (많은 실천법들이 있긴하지만) 너무 추상적이다. 하지만 이 중 파이프라인을 구현할 도구들은 이미 많이 있다. 아래 이미지는 소프트웨어 생명 주기의 각 단계 별로 해야하는 역할과 그 역할을 수행할 수 있는 툴들을 NetApp 이라는 업체에서 정리한 내용이다. 각 툴들이 하나의 연결 고리를 이루며, 모든 체인이 엮어 유기적으로 작동하면 'DevOps 툴체인'을 이룬다.
DevOps 팀은 각 도구들을 조직의 환경에 맞게 적절히 활용하여 툴체인을 현실에 구현하고 유지, 관리 해야한다.
또한 이러한 툴들을 개발-운영 부서가 적극적으로 사용할 수 있도록 지속적으로 사용법을 교육, 문서화하고 장기적으로는 이러한 업무 방식을 조직내에 문화화(enculturation) 시켜야한다.
하지만 구체적인 방법들을 여기서 전부 작성하기엔 여백이 부족하다. 문화화를 위한 여러 실천법 (칸반과 스크럼 등) 과 파이프 라인을 구축하기 위한 툴의 사용법 등은 하나씩 공부하면서 앞으로 다른 글들을 통해 다뤄보겠다.
참고 자료 링크
- https://ko.wikipedia.org/wiki/%EB%8D%B0%EB%B8%8C%EC%98%B5%EC%8A%A4
- https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=ydot&logNo=22153632304
- https://m.blog.naver.com/sundooedu/221193074730
- https://engineering-skcc.github.io/devops/DevOps1-%EC%95%A0%EC%9E%90%EC%9D%BC%EA%B3%BC%EB%8D%B0%EB%B8%8C%EC%98%B5%EC%8A%A4/
- https://multicore-it.com/46
- https://www.netapp.com/ko/devops-solutions/what-is-devops/
'Computer Science > 소프트웨어 공학' 카테고리의 다른 글
| [SE] SDLC (Software Development Life Cycle) (0) | 2022.09.12 |
|---|---|
| [SE] XP (eXtreme Programming) (2) | 2022.07.10 |
| [SE] MSA (Micro Service Architecture) (0) | 2022.06.26 |
댓글