DevOps 란?



최근 IT 업계에서 지속적인 소통을 통한 협업 문화가 중시되고 있는데요, 이를 위해 여러 가지 방법론 또한 등장하고 있습니다. 오늘은 이러한 소통과 협업 방식인 디봅스(DevOps)를 주제로 유용한 정보를 공유해드릴까 합니다.
 
 



[출처] DevOps
 
DevOps는 소프트웨어개발(Development) 그리고 운영(Operations)의 합성어로, 일반적 정의는 개발과 운영을 하나의 조직으로 합쳐서 팀을 운영하는 문화이자 방법론입니다.
 
[출처] Dev vs Ops

개발자들은 고객에게 검토를 요청한 변경 사항을 빨리 확인하길 원합니다. 반면 운영진은 안정성에 더 무게 중심을 두고 싶어 합니다. 일반적인 업무 프로세스상 이 둘 간의 타협은 쉽게 이뤄지지 않게 되고 시장과 고객에 대처하는 속도 또한 더딜 수밖에 없습니다. 하지만 DevOps는 이 둘의 공통 지표를 맞추고 지속적인 커뮤니케이션을 통해 차이를 줄이며 설계부터 배포까지 하나의 조직으로 협업하여 빠르게 변화하는 고객 중심의 시장에 맞춰 효율적으로 신속하게 대처할 수 있도록 하는 "문화" 라고 할 수 있겠습니다.
 




[출처] DevOpsCycle

1. 속도 : 배포까지의 작업 속도가 빨라져 고객을 위해 더 빠르게 혁신하고 시장 변화에 빠르게 대처하여 더 효율적인 비즈니스 성과를 창출할 수 있습니다
2. 신속한 제공 : 빌드에서 배포까지 소프트웨어 릴리스 프로세스를 자동화하여 새로운 기능의 배포와 이슈에 대한 대처 속도를 개선하여 고객에게 제공한 제품을 더 빠르게 혁신, 개선하여 시장 경쟁 우위를 차지할 수 있습니다.
3. 안전성 : 소프트웨어 업데이트와 변경 시의 품질 보장, 지속적인 통합과 전달을 통해 변경 사항이 안전하고 정확하게 작동하는지 테스트하고 모니터링과 로깅 방식을 통해 실시간으로 성능에 대한 정보를 얻을 수 있습니다.
4. 확장 : 자동화와 일관성이 지원되어 안전성을 보장하며 복잡한 시스템 또는 변화하는 시스템을 효율적으로 관리할 수 있습니다.
5. 협업 강화 : 개발부서와 운영부서의 긴밀한 협력을 통해 비효율성을 줄이고 시간을 절약할 수 있습니다.
6. 보안 : 자동화된 규정 준수 정책, 세분화된 제어 및 관리 기술을 사용하여 DevOps 모델을 도입할 수 있습니다.
 



1. Cross Functional Team : 팀 하나에서 개발부터 운영까지 전부 할 수 있는 인원으로 채우는 것이 아닌 각 프로세스의 담당자들을 하나씩 팀원으로 구성하는 뜻으로 서비스 기획부터 개발, 테스트, 운영 배포 등 모든 제품 개발 프로세스를 하나의 팀에서 할 수 있도록 해야 한다는 것입니다.
2. Widely Shared Metrics : 팀 구성원 전체가 기준으로 삼을 수 있는 서비스 제품에 대한 공통적인 지표를 통해 개발 후 잘 운영되고 있는지, 사용자의 반응은 어떤지 등 서비스 진행 상태를 인지할 수 있어야 한다는 것입니다.
3. Automating repetitive tasks : 반복적인 일들을 CI(Continuous Integration)/CD(Continuous Delivery) 를 이용하여 프로세스를 자동화해야 한다는 것입니다. 반복적 작업에 투입되는 시간을 줄여 작업의 효율을 높이고 빠른 서비스 업데이트가 가능하며 전체 시스템에 대한 이해도를 높일 수 있습니다.
4. Post Mortem : 서비스의 장애나 이슈가 있을 때, Fix 후 팀 전체가 공유하여 이러한 이슈들의 심각도를 판단하고 차후 같은 이슈에 대해 예방을 할 수 있습니다.
5. Regular Release : 서비스 릴리즈는 개발, 테스트 배포 과정을 거치게 되고 릴리즈가 끝난 후엔 다음 릴리즈를 위한 기능 정의 등의 과정을 거쳐야 하므로 불필요한 많은 시간이 소요될 수 있습니다. 정기적으로 릴리즈를 하게 되면 팀의 협업시점이 명확해지고 서비스의 기능을 빠르게 개선하여 고객의 VOC(Voice Of Customer)를 반영해 나갈 수 있다는 것입니다.

[출처] CI,CD,CD

1. Continuous Integration : 개발자들이 개별적으로 개발한 프로그램 소스 코드를 하나로 모아 빌드하는 통합 빌드의 과정을 특정 시점에 하는 것이 아니라 주기적으로 수행하여 통합에서 발생하는 충돌 등의 오류를 각기 다른 레벨의 자동화 테스트(단위 및 통합 테스트가 일반적)를 통해 변경 사항이 잘 통합되었는지 확인하고 이슈 발생 시 사전에 해결, 복잡성을 제거하자고 시간을 단축하기 위한 기법을 말합니다. Agile 방법론이 대두하면서 더욱 주목받게 되었고 빌드, 테스트 단계 등에서 걸리는 시간을 절약하여 빠른 시장에서의 경쟁력을 확보할 수 있습니다. CI 시스템을 구축하기 위한 핵심 구성요소는 Jenkins,Travis CI등의 CI Server,subversion,Git 등의 소스 코드 형상 관리 시스템(Source code Management), Maven, Gradle, Ant 등의 Buil Tool, 그리고 테스트 코드에 따라 자동으로 테스트를 수행해주는 JUnit, Mocha 등의 Test Tool이 있습니다.

2. Continuous Delivery : 프로그램에 적용된 사항들을 자동을 빌드, 단위 및 통합 테스트 진행에 이어서 하나의 리포지토리에 (예를 들면 Git)에 업로드되는 것을 말합니다. 이를 통하면 운영부서는 리포지토리의 프로그램을 실시간으로 프로덕션 환경에 배포가 가능할 것입니다. 이것이 효율적인 방법이 되려면 앞서 언급했던 CI의 자동화 프로세스가 제대로 구축하고 작동하여야 가능할 것입니다.
 

3. Continuous Deployment : Continuous Delivery와 개념이 유사하여 살짝 헷갈릴 수 있는 부분이지만 쉽게 말씀드리자면 Continuous Delivery는 프로덕션은 수동으로 배포하고 Continuous Deployment는 프로덕션까지 자동으로 배포하는 것입니다.
 



조직이 오래 지속하였거나 프로젝트 중간에는 이런 DevOps 방식의 "문화"를 도입하기는 쉽지 않을 것입니다. 경영자 또는 PM이 DevOps에 대해 이해가 없다면 도입하더라도 단기성, 일회성에 불과하리라 생각합니다. 이미 다른 방법론인 애자일 방법론을 도입하려 한 수많은 기업의 실패도 앞서 말씀드린 내용에 근거가 됩니다. 물론 실패한 사례만 있는 것은 아닙니다. DevOps는 아니지만 한 소셜커머스 업체에서는 애자일 방법론을 성공적으로 도입한 조직이 하나가 되어 문화를 바꾼 의미 있는 사례도 있습니다.
"한 사람의 꿈은 꿈이지만 만인의 꿈은 현실이 된다."는 말이 있습니다. 이러한 문화, 방법론 도입을 수동적으로 도입하는 것보다는 직급을 떠나 조직 전체가 이를 공감하고 이해하여 능동적으로 받아들이고 형성할 자세가 되어 있어야 한다고 생각합니다. 고객 중심으로 빠르게 변화하는 시장에 알맞게 대응하기 위해 Google, Facebook, Netflix 등 세계 유명 기업들도 개선된 개발 방법론들을 도입하여 시장에 발맞춰 나가고 있습니다. DevOps를 잘 적용했을 때 이전보다 배포주기 46배, 개선속도 440배, 복구시간 96배, 매출 20% 신장 등 좋은 효과를 얻고 있는 사례들이 있는 만큼 조직에 알맞게 DevOps, 또는 개선된 개발 방법론을 도입하여 업무의 효율성과 만족도 향상 그리고 빠르게 변화하고 있는 시장에서의 경쟁력을 가져보는 것은 어떨까요.


Posted by 人Co

2020/05/07 08:16 2020/05/07 08:16
Response
No Trackback , No Comment
RSS :
https://post-blog.insilicogen.com/blog/rss/response/344

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

« Previous : 1 : ... 13 : 14 : 15 : 16 : 17 : 18 : 19 : 20 : 21 : ... 51 : Next »