데브옵스 소개
대규모 기업과 웹 기반 조직들 모두 빠르게 데브옵스를 도입하고 있는 추세지만, 데브옵스가 정확히 무엇을 의미하는지 모르는 사람이 많습니다. 데브옵스는 문화, 운동, 접근 방식, 철학일까요? 아니면 이러한 여러 가지 요소가 융합된 것이거나 사람마다 다른 의미가 있을까요?
데브옵스를 어떻게 정의하느냐에 상관없이, 데브옵스의 성공을 위해서는 반드시 일련의 여정을 거쳐야 합니다. 기업이 데브옵스를 향한 여정의 어느 단계에 있든, 뉴렐릭은 다음과 같은 몇 가지 기본적인 질문에 답을 할 수 있도록 지원합니다.
- 데브옵스의 정의
- 데브옵스의 원리
- 데브옵스의 중요성
- 데브옵스를 도입하는 조직
- 데브옵스의 이점
- 데브옵스의 도전과제
- 데브옵스의 모범 사례
- 데브옵스와 뉴렐릭을 시작하는 방법
데브옵스의 정의
데브옵스는 소프트웨어 개발 수명 주기를 가속화하는 데 사용되는 프로세스, 문화 및 사고 방식을 포괄하는 용어입니다. 데브옵스 모델에서는 보통 테스트, 품질 보증, 배포 등 서로 격리되어 운영되던 팀들이 빠른 피드백 루프와 기타 방법을 사용해 신속하게 기능, 수정 및 업데이트를 제공하는 포괄적인 생태계에 통합됩니다.
또한 데브옵스는 제품 팀이 기간을 단축할 수 있도록 새로운 툴과 프로세스를 사용합니다. 시장 출시 시간은 오늘날 비즈니스의 중요한 측면입니다. 새로운 제품과 업데이트의 출시가 기업의 경쟁력을 좌우할 수 있기 때문입니다. 데브옵스는 팀이 효율성을 높이고 소프트웨어 제품을 더 빨리 제공할 수 있도록 만들기 위해 구상되었습니다.
‘데브옵스(DevOps)’는 패트릭 드보이스(Patrick Debois)가 2009년에 처음 소개한 용어로 이후 그는 이 분야의 전문가로 부상했습니다. 이 용어는 개발(development)’과 ‘운영(operations)’을 결합한 말로, 사람들이 데브옵스가 무엇을 의미하는지 이해할 수 있는 시작점을 제공합니다. 데브옵스는 프로세스, 기술 또는 표준이 아닙니다. 많은 추종자들은 데브옵스를 하나의 ‘문화’라고 언급하는데, 뉴렐릭도 이러한 의견에 동의합니다. 도입률, 미래를 위한 추세 같은 주제를 언급할 때 '데브옵스 운동’이라는 용어가 사용되고, 데브옵스 문화를 도입한 IT 조직을 지칭하는 의미로 ‘데브옵스 환경’이라는 용어가 사용되기도 합니다.
데브옵스의 기원
데브옵스의 기원에 대해서는 의견이 분분하지만, 처음부터 완전한 개념은 아니었다는 점은 확실합니다. 데브옵스라는 씨앗이 오래 전에 심어졌고, 여러 분야의 미래 지향적인 IT 전문가들이 지속적으로 이를 키워왔다고 말할 수 있습니다. 지금의 데브옵스를 있게 한 두 가지 주요 요인은 다음과 같습니다.
- 엔터프라이즈 시스템 관리(ESM). 데브옵스의 초기 정의에 관여한 사람들은 대부분 시스템 관리자였습니다. 이 운영 전문가들은 설정 관리, 시스템 모니터링, 자동화된 프로비저닝, 툴체인 접근 방식 등 데브옵스에 ESM의 주요 모범 사례를 적용했습니다.
- 애자일 개발. 한 업계 전문가의 말을 빌자면, "데브옵스는 애자일(Agile)의 결과물로 해석될 수 있습니다. 애자일 소프트웨어 개발은 고객, 제품 관리, 개발자 및 QA의 긴밀한 협업을 통해 서로의 격차를 해소하고, 더 나은 제품을 빠르게 개발할 수 있도록 신속하게 반복하는 것으로 규정될 수 있습니다. [데브옵스는] 서비스 제공과 앱 및 시스템의 상호 작용은 클라이언트에게 제공하는 가치 제안의 토대가 되는 부분이기 때문에, 제품 팀은 이러한 문제를 우선순위에 두어야 합니다. 이러한 관점에서 데브옵스는 애자일 원칙을 코드의 경계를 넘어 전체 제공 서비스로 확장하고 있습니다.”
소프트웨어는 복잡합니다. 설계 규모가 클수록 한층 더 복잡해집니다. 새로운 기능을 제공하기 위해 자주 변경을 하다보면 시스템이 불안정해질 수 있습니다. 모든 사람에게 좋지 않은 일입니다.
고객은 업무에 도움이 되는 새로운 기능을 원합니다. 비즈니스 관리자는 더 많은 수익을 창출하기를 원합니다. 소프트웨어 개발자는 혁신적인 기능을 제공하기를 원합니다. 그러나 신속한 배포는 새 코드를 통합하고 관리해야 하는 시스템 관리자에게 훨씬 더 큰 부담을 줄 수 있습니다. 변경으로 인해 고객의 기존 설치나 구성에 문제가 발생할 경우, 문제 해결에 필요한 시간, 수익 및 평판 손실이 발생할 수 있습니다.
소프트웨어를 개발하고 비즈니스를 관리하는 기존 방식은 업무를 분산하고, 비즈니스 관리자와 고객이 팀의 기능을 정의하는 것이었습니다. 소프트웨어 개발자는 코드를 만들고, 테스트 엔지니어가 이를 검증합니다. QA 팀이 확인을 하고, 현장 엔지니어가 이를 배포합니다. 각 단계에서 병목 현상이 발생할 수 있습니다. 데브옵스는 이러한 모든 기능을 통합해, 개발자가 때론 여러 역할을 수행하도록 함으로써 팀을 더욱 민첩하게 만들고, 고객의 요구에 더 빠르게 대응하는 동시에 새로운 코드가 시스템에 장애를 일으키지 않도록 보장합니다. 결과적으로 더 빠르고 성공적으로 제품을 출시할 수 있게 됩니다.
데브옵스의 원리
모든 문화와 마찬가지로 데브옵스도 다양한 변종들을 통합합니다. 그러나 대부분의 업계 전문가들은 다음의 역량들이 협업, 자동화, 연속 통합, 연속 배포, 연속 테스트, 연속 모니터링, 신속한 문제 해결 등 거의 모든 데브옵스 문화에 공통 요소라는 데 동의할 것입니다.
팀들을 서로 분리하는 기존 운영 방식을 제거함으로써, 소통 루프가 짧아지고 대응 속도가 빨라집니다. 예를 들어, 팀에서 매일 스탠드업 회의를 개최하여 누가 언제 무엇을 하고 있는지 파악할 수 있습니다. 이러한 회의는 팀원들에게 문제를 논의하고 협력해 문제를 해결할 수 있는 포럼을 제공합니다.
데브옵스 팀은 Git, 칸반(Kanban), 컨테이너, 클라우드 서비스 등의 툴을 사용하여 프로세스를 자동화하고 가속화합니다. 전체 툴 스택은 팀이 연속 통합, 배포, 협업 및 자동화를 보다 효과적으로 구현할 수 있도록 해줍니다.
AI는 데브옵스에 중요한 영향을 미치고 있습니다. 머신 러닝(ML)과 기타 AI 방법론을 사용하면 소프트웨어 개발과 배포를 자동화하고 최적화할 수 있습니다. 데브옵스에서 AI는 프로세스의 효율성을 높여 개발 수명 주기의 속도, 정확성 및 신뢰성을 향상할 수 있습니다.
데브옵스, 애자일 및 시스템 신뢰성 엔지니어링(SRE) 요약 정보
기업들은 데브옵스로의 전환, 사이트 안정성 엔지니어(SRE) 고용, 민첩성 향상에 대해 자주 언급을 합니다. 이러한 용어들이 서로 어떤 관련이 있을까요?
민첩성과 효율성은 팀이 짧은 개발 주기와 빠른 피드백을 통해 반복하는 방식입니다. 민첩성은 문화에 초점을 맞추며 어떤 툴을 사용하는가와는 무관합니다.
데브옵스는 엔지니어링 조직이 교차 기능 팀을 활용해 협업하는 방식입니다. 데브옵스는 문화로 시작해서 툴을 갖추는 일로 나아갑니다.
사이트 안정성 엔지니어링(SRE)은 엔지니어링 조직이 자동화하는 방식으로, 소프트웨어 엔지니어링의 사고방식을 가진 사람에게 고도로 확장된 운영을 맡깁니다. SRE는 툴을 갖추는 것에서 시작해서 문화를 조성하는 방향으로 나아갑니다.
데브옵스의 변종(예: “SecDevOps”)은 소프트웨어 개발 수명 주기 초기에 다른 조직/관행을 삽입 또는 추가하는 것으로, 이러한 다양한 데브옵스 유형이 확산되었다는 것은 현대 조직에서 기능 부서의 통합이 증가하고 있다는 사실을 말해줍니다.
데브옵스의 중요성
오늘날 경쟁력은 비즈니스의 원동력입니다. 데브옵스는 기업이 경쟁력을 유지하며 새로운 소프트웨어 제품의 시장 출시 시간을 단축하여 제품 품질을 유지하고 혁신을 실현할 수 있도록 지원합니다. 데브옵스는 팀이 제품을 더 빨리 출시하는 동시에 안정성을 보장할 수 있도록 지원합니다. 잘 설계된 데브옵스 프로그램은 여러 다른 프로젝트와 팀의 요구를 수용할 수 있도록 확장이 가능합니다.
데브옵스를 도입하는 조직
초기 스타트업부터 100년 이상 된 기업으로까지, 데브옵스는 전 세계 IT 조직으로 확산되고 있습니다. 한 설문 조사에 따르면 기업 중 74%가 어떤 방식으로든 데브옵스를 구현하고 있는 것으로 나타났습니다.
어떤 기업들이 데브옵스를 수용하고 있을까요? Etsy, Facebook, Amazon, Netflix와 같은 웹 기반 ‘유니콘’ 기업들이 손꼽히는 데브옵스 리더들이긴 하지만, 오늘날은 사실 모든 유형의 기업들이 데브옵스를 활용합니다. 주요 미디어 회사인 Sony Pictures, 금융 서비스 업계의 거물 Barclays Bank, 빌딩 제품 제조업체 USG는 자주 회자되는 데브옵스의 주요 성공 사례입니다.
놀랍게도, 81%의 대기업들이 자사 조직 내 어디에선가 데브옵스를 도입한 것으로 나타났습니다. 70%의 중소기업들도 데브옵스를 사용하며 그 혜택을 누리고 있습니다. 주목할 것은, 기업의 규모와 데브옵스의 성공은 큰 관계가 없다는 것입니다.
심지어 정부 및 준정부 조직들도 데브옵스를 수용하고 있습니다.예를 들어, Fannie Mae는 데브옵스를 사용해비즈니스를 혁신하고 변화를 보다 빠르게 수용할 수 있게 되었습니다.
미국 특허청도 데브옵스로 전환해, 현재 주당 평균 1,000건의 자동화된 빌드를 생성하고 있습니다. 미국 연방조달청에서는 프로젝트를 더 빠르게, 더 높은 품질로 제공하기 위해 운영 컨테이너, 자동화된 워크플로우, 마이크로서비스 등을 사용해 IT 운영을 현대화하고 있습니다.
클라우드 및 컨테이너 기술의 등장으로 데브옵스가 전 세계적으로 확산되고 있지만, 데브옵스는 여전히 더 성장할 여지가 있습니다. 이미 데브옵스가 자리를 잡고 있는 조직이라면, 이는 새로운 개발 노력을 추진하는 형태로 나타날 수 있습니다.
데브옵스의 이점
데브옵스를 통해 얻을 수 있는 몇 가지 놀라운 혜택들이 있습니다. 그러나 주의가 필요합니다. 누군가 “리터당 13km를 달린다”라고 말하는 것을 우연히 들었다고 가정해 보겠습니다. 만약 대형 SUV가 오프로드 주행을 할 때 얘기라면, 수치가 너무 높아 믿을 수 없을 것입니다. 반면, 고속도로에서 하이브리드차가 그 정도 연비를 낸다면 실망스러울 것입니다. 그래서 맥락이 중요합니다. 데브옵스와 관련된 개선 사항에 대한 요구가 있을 때마다 결과가 달라질 수 있다는 점에 유의해야 합니다.
DevOps Research and Assessment(DORA)의 2018년 데브옵스 현황(2008 State of DevOps) 보고서에 따르면, 높은 데브옵스 성과를 내는 기업은 그렇지 않은 기업보다 46배나 더 자주 소프트웨어를 출시하며 리드 타임도 2,555배나 더 빠른 것으로 나타났습니다. 소프트웨어 제품의 품질 역시 더 높았으며, 변경 실패율은 7배 더 낮았습니다. 이외에도, 시스템 안정성에 미치는 효과가 매우 긍정적입니다. 플랫폼이 다운되면 높은 데브옵스 성과를 내는 기업은 2,604배 더 빠르게 서비스를 복원합니다.
한 가지는 분명한 사실은, 데브옵스를 성공적으로 도입한 IT 전문가들은 데브옵스의 열렬한 지지자가 된다는 것입니다. Puppet Labs에서 실시한 설문 조사에서 기업이 어떤 점들을 개선했는지를 보면, 그 이유가 쉽게 이해됩니다.
- 안정성: 높은 성과를 내는 조직은 계획되지 않은 작업과 재작업에 22% 더 적은 시간을 소비합니다. 그 결과, 새로운 기능이나 코드 같은 새로운 작업에 29% 더 많은 시간을 투자할 수 있게 됩니다.
- 보안: 높은 성과를 내는 기업은 성과가 저조한 기업보다 보안 문제를 해결하는 데 50% 더 적은 시간을 할애합니다.
- 앱 배포 속도: 높은 성과를 내는 기업은 하루에 여러 차례 배포를 했고, 그렇지 않은 기업은 한 달에 한 번, 매 6개월마다 한 번씩 배포를 합니다.
데브옵스는 소프트웨어 체인에 존재하는 모든 이들에게 혜택을 제공합니다.
데브옵스는 소프트웨어 업데이트 작업을 하는 개발자와 테스트 엔지니어부터 수익을 생각하는 경영진에 이르기까지, 조직 전반에서 모든 사용자에게 혜택을 제공합니다. 데브옵스가 소프트웨어 제품의 개발과 릴리스를 담당하는 여러 그룹에 어떤 이점을 제공하는지 살펴보겠습니다.
- 개발자: 새로운 툴과 프로세스는 개발자의 워크플로우를 가속화하고 간소화해줍니다. 자동화된 프로비저닝을 통해 개발자는 승인과 서류 작업 절차를 거치지 않고 서버를 프로비저닝할 수 있습니다. 운영 팀과 직접 협력함으로써 개발자들의 세상에서는 흔히 볼 수 없는 고유한 협업이 가능해져 문제 해결과 혁신이 가속화됩니다.
- 운영 팀: 배포와 관련해 개발자의 관여가 증가하여 실질적으로 시스템의 안정성이 향상됩니다. 소규모의 빈번한 릴리스는 변동성을 줄여 치명적인 장애의 위험을 낮춰줍니다. 또한 보다 제한된 릴리스의 경우 한밤중이나 주말이 아니라 모든 사람이 근무하며 함께 문제를 해결할 수 있는 주중에 이뤄질 수 있습니다.
운영 팀은 다른 부서보다 훨씬 더 많은 툴에 의존합니다. 자동화는 사람의 실수를 없애고 일상적인 작업에 소요되는 시간을 줄여줍니다. 시스템 관리자는 새로운 기술과 경력 기회는 물론 중단 없는 수면과 개인 시간을 확보할 수 있습니다. - 테스트 엔지니어: 데브옵스는 소프트웨어를 테스트할 새로운 방법이 필요하며, 이는 테스트 엔지니어들이 혁신하도록 만들고 있습니다. 자동화된 프로비저닝을 통해 테스트 엔지니어는 운영 환경과 거의 동일한 환경을 프로비저닝하여, 보다 정확하게 테스트를 수행하고 새로운 릴리스의 성능을 예측할 수 있는 역량을 향상할 수 있습니다
- 제품 관리자: 데브옵스는 엔지니어링과 운영에 직접적인 영향을 미치지만 제품 관리자는 마케팅 및 비즈니스 담당자와 함께 다음과 같은 많은 이점을 누릴 수 있습니다.
더 빠른 피드백: 새로운 제품이나 기능이 고객에게 제공되자마자, 실질적인 피드백을 받을 수 있습니다.
응답성 향상: 연속 배포를 통해 고객의 니즈에 신속하게 대응이 가능해져 새로운 기능의 출시 기간이 대폭 단축됩니다.
낭비 및 위험 감소:개발 작업자는 다음 공식 릴리스가 나올 때까지 기다리지 않고 문제를 해결하거나 새로운 기능에 대한 작업을 수행할 수 있습니다.
데브옵스의 협업 환경에서는 비즈니스 이해관계자들이 개발 프로세스에 더 큰 영향을 미치고, 개발자는 비즈니스의 대(對)고객 측면에 더 많이 관여하게 됩니다. 또한 제품 관리자는 새로운 가격, 기능 및 제품 번들이 어떤 영향을 미치고 있는지에 대한 즉각적인 피드백을 받아 변경 사항을 테스트하고 그 효과를 평가할 수 있습니다. 단축된 소프트웨어 출시 기간은 사업부 관리자에게 경쟁력을 제공합니다. 또한 시스템 안정성이 향상됨에 따라 중단이 최소화되어 고객의 이탈을 줄이고 충성도를 높일 수 있습니다.
- 임원: 고품질 제품을 더 짧은 시간에 출시하여 수익에 영향을 미치고 브랜드 가치를 구축할 수 있습니다. 데브옵스는 최고의 인재를 유치하고 유지하는 데에도 도움이 됩니다. 역량 있는 개발자, 시스템 관리자 및 테스트 엔지니어는 가능하면 가장 현대적이고 생산적인 방식으로 작업할 수 있길 원합니다. 데브옵스는 긴밀한 협업이 가능하기 때문에, 최고 경영진이 부서 간 문제에 휘말리는 일이 거의 없으며 중요한 비즈니스 목표를 수립하는 데 더 많은 시간을 할애할 수 있습니다.
데브옵스의 도전과제
데브옵스의 가장 큰 도전과제 중 하나는 오래된 사고 방식을 바꾸는 것입니다. 팀과 운영을 구조 조정하려면 최고 경영진의 주도로 조직의 모든 사람이 데브옵스에 사용되는 새로운 프로세스와 툴 세트를 수용하는 것이 필요합니다. 의사 결정권자와 사용자가 데브옵스의 이점과 가치를 알게 되면, 조직은 첫 번째 장애물을 넘었다고 할 수 있습니다.
사고 방식을 바꾸고 구조 조정을 하는 데는 시간이 걸리며, 이는 제품 출시 일정과 충돌할 수 있습니다. 워크플로우는 각 조직의 고유한 구조와 연동되는 방식으로 설계되어야 합니다. 새로운 프로세스를 도입하려면 문서화와 교육이 수반되어야 하고, 새로운 툴 세트에 대한 조사, 설치 및 교육도 수행되어야 합니다.
중요한 것은 이점이 도전과제보다 훨씬 더 많다는 사실입니다. 긴밀하게 협업하며 새롭고 보다 효과적인 툴 세트를 사용하면 개발과 혁신에 박차를 가할 수 있습니다.
데브옵스의 모범 사례
데브옵스는 협업, 자동화, 연속 테스트 및 모니터링을 포함하는 인적 및 기술 모범 사례의 조합입니다. 이러한 모든 요소가 결합되면, 완전한 제품 개발 및 제공 프로세스가 완성되어 출시 기간을 단축하고 제품을 혁신하며 최종 고객과 긴밀하게 연결 및 협업할 수 있습니다.
협업
개발 팀과 IT 운영 팀은 서로에게 책임을 전가하는 것이 아니라 함께 작업을 수행합니다. 애초에 이 두 그룹이 분리되어 있었기에 데브옵스가 생겨나게 되었지만, 데브옵스는 IT 조직 그 이상으로 확장됩니다. 협업의 필요성은 소프트웨어 배포에 관여된 모든 사람(개발 팀과 운영 팀 간뿐만 아니라 테스트, 제품 관리, 경영진 등 모든 직원)으로 확장되기 때문입니다.
자동화
데브옵스는 자동화에 크게 의존하기 때문에 툴이 필요합니다. 자체 구축한 툴. 구매한 툴. 오픈소스 툴. 독점 툴. 이러한 툴들이 기업 전반에 아무렇게나 분산되어 있지는 않습니다. 데브옵스는 툴체인을 사용해 전체 소프트웨어 개발 및 배포 프로세스의 많은 부분을 자동화합니다.
주의해야 할 것은, 데브옵스 툴들이 매우 뛰어나기 때문에 데브옵스를 툴 모음이라고 보는 경향이 있다는 것입니다. 데브옵스가 툴에 의존하는 것은 사실이지만 툴 그 이상입니다.
연속 통합
데브옵스는 애자일 문화에서 등장했기 때문에 데브옵스 문화에서는 보통 연속 통합을 발견할 수 있습니다. 연속 통합은 애자일 접근 방식의 기본 원칙입니다.
코드 섹션을 전체 프로젝트 빌드에 지속적으로 병합함으로써, 각 개발자는 프로젝트의 로컬 복사본을 사용할 수 있습니다. 이렇게 하면 프로젝트가 원래 목표에서 크게 벗어나는 것을 방지하고 치명적인 병합 충돌을 피할 수 있습니다.
연속 통합의 애자일 개발 원칙은 개발 그룹에 문화적인 의미가 있습니다. 개발자가 자신의 작업을 다른 개발자의 작업과 자주(적어도 매일) 통합하도록 만듬으로써, 통합 문제나 충돌을 워터폴(waterfall) 방식의 개발보다 훨씬 더 일찍 노출시킬 수 있습니다. 그러나 이러한 이점을 얻기 위해서는 개발자들이 서로 더 자주 소통을 해야 합니다. 이는 세상으로 모듈을 내보낼 수 있을 때까지 몇 주 또는 몇 개월 동안 작업에 매진하는 천재 개발자의 이미지와는 걸맞지 않은 프로세스입니다. 그러한 개방된, 잦은 소통이라는 씨앗은 데브옵스에서 활짝 피어납니다.
연속 테스트
데브옵스의 테스트 영역은 쉽게 간과될 수 있습니다. 소프트웨어 장애는 비용이 많이 듭니다. 운영 중단을 유발하는 코드가 릴리스되면 사용자 경험과 잠재적으로 고객의 비즈니스 운영에 심각한 영향이 갈 수 있습니다. 연속 테스트는 코드 문제가 공개되기 전에 해결하도록 설계되었습니다. 연속 통합과 연속 배포가 가장 중요하기는 하지만, 연속 테스트도 데브옵스의 중요한 일부로 자리를 잡아가고 있습니다.
연속 테스트는 단순한 QA 기능이 아니며, 개발 환경에서 시작됩니다. 개발자들이 코드를 QA 팀에 던져주고 ‘이제 마음대로 하세요’라고 말할 수 있었던 날은 이제 지났습니다. 데브옵스 환경에서의 품질은 모든 사람의 책임입니다. 개발자는 높은 품질의 코드를 구축하고 테스트 데이터 세트를 제공합니다. QA 엔지니어는 자동화 테스트 사례와 테스트 환경을 설정합니다.
QA 측면에서 필요한 것은 속도입니다. QA 주기가 며, 몇 주가 걸리면 워터폴 방식의 긴 일정과 다름이 없게 됩니다. 테스트 프로세스의 대부분을 자동화하고 테스트 방법을 재정의함으로써, 테스트 엔지니어는 빠른 시간 내에 테스트를 완료할 수 있습니다.
연속 테스트는 개발의 각 단계에서 소프트웨어 개발에 대한 포괄적인 관점을 제공합니다. 모든 이해 관계자가 프로젝트의 상태를 볼 수 있으므로 팀 전체가 정보에 기반해 의사 결정을 내릴 수 있습니다.
의외라고 생각될 수도 있지만, 운영 팀은 테스트 및 QA에서 중요한 역할을 합니다. 운영 팀은 모니터링 툴이 있고 테스트 환경이 제대로 설정되었는지 확인할 수 있습니다. 또한 기능, 부하, 스트레스, 누출 테스트에 참여하여 유사한 애플리케이션을 운영 환경에서 실행한 경험을 바탕으로 분석을 제공할 수 있습니다.
연속 테스트를 통해 얻어지는 혜택은 노력할 만한 가치가 있습니다. 데브옵스 환경에서 테스트 팀은 개발자들이 품질과 속도의 균형을 유지하는 데 도움을 줍니다. 자동화된 툴을 사용하면, 테스트 비용이 절감되고 테스트 엔지니어가 시간을 보다 효율적으로 활용할 수 있게 됩니다. 가장 중요한 것은 연속 테스트는 프로세스 초기에 통합 테스트를 가능하게 함으로써 테스트 주기를 단축시킨다는 것입니다.
또한 연속 테스트는 가상화된 독립된 서비스들을 통해 테스트 병목 현상을 제거할 수 있으며, 시스템이 변경되면 손쉽게 구현, 공유 및 업데이트할 수 있는 가상화된 테스트 환경을 간편하게 생성할 수 있습니다. 이러한 역량은 테스트 환경의 프로비저닝 및 유지 관리 비용을 절감해주며, 수명 주기 초기에 통합 테스트를 수행할 수 있게 해줌으로써 테스트 주기 시간을 단축해줍니다.
연속 배포
연속 배포는 릴리스 후보로 테스트할 수 있도록 전체 코드 빌드를 반복적으로 유지합니다. 실제 릴리스 빈도는 기업의 전략이나 목표에 따라 크게 달라질 수 있습니다. 데브옵스를 사용해 높은 성과를 내는 조직은 하루에 수차례를, 중간 정도의 성과를 내는 조직은 일주일에 한 번 또는 한 달에 한 번 정도 릴리스를 합니다.
정확히 무엇을 릴리스하는지 또한 다릅니다. 일부 조직의 경우 QA 및 운영 팀에서 잠재적 릴리스를 분류합니다. 많은 릴리스는 사용자들에게 직접 배포되고, 일부는 개발 팀으로 돌아가며, 또 어떤 일부는 전혀 배포되지 않습니다. 다른 기업들은 개발자들의 모든 작업을 사용자들에게 제공하고 실시간 모니터링과 신속한 문제 해결을 통해 드물게 발생하는 장애의 영향을 최소화합니다. 각 업데이트의 사이즈가 더 작기 때문에, 장애를 일으킬 가능성이 크게 줄어든다는 사실도 주목할 만 합니다.
연속 모니터링
연속 배포 환경에서는 릴리스 수가 많기 때문에, 워터폴 개발 접근 방식에 일반적으로 요구되는 엄격한 테스트를 수행할 수가 없습니다. 데브옵스 환경에서는 오류를 실시간으로 찾아 해결해야 합니다. 어떻게 할까요? 바로 연속 모니터링을 통해서입니다.
팀은 연속 모니터링을 통해 소프트웨어의 성능 및 가용성을 측정하고 안정성을 개선합니다. 연속 모니터링은 문제의 근본 원인을 신속하게 파악하여 가동 중단을 예방하고, 사용자 문제를 최소화할 수 있도록 해줍니다. 일부 모니터링 전문가들은 서비스의 정의에 모니터링이 포함되어야 한다고 주장하기도 하는데, 이는 모니터링이 서비스 제공에 핵심 요소라고 생각하기 때문입니다.
테스트와 마찬가지로, 모니터링은 개발 단계에서 시작됩니다. 운영 환경을 모니터링하는 데 사용하는 툴을 개발 과정에 사용하면 운영 환경에 들어가기 전에 성능 문제를 파악할 수 있습니다.
데브옵스는 서버 모니터링과 애플리케이션 성능 모니터링이라는 두 가지 종류의 모니터링이 필요합니다. 모니터링에 대한 대화는 툴에 대한 대화로 직결됩니다. 적절한 툴이 없으면 효과적으로 모니터링을 할 수 없기 때문입니다. 데브옵스 툴(및 더 많은 데브옵스 관련 컨텐츠) 목록을 확인하시려면, New Relic DevOps Hub를 방문하시기 바랍니다.
데브옵스와 뉴렐릭을 시작하는 방법
지난 10년간 데브옵스에 대한 실험을 해본 결과, 확실해진 사항은 데브옵스는 지속될 것이고, 그만한 이유가 있다는 것입니다. 데브옵스는 많은 사람들이 불가능하다고 생각했지만, 비즈니스 사용자, 개발자, 테스트 엔지니어, 보안 엔지니어 그리고 시스템 관리자를 고객 요구 사항을 충족하는 데 중점을 둔 단일 워크플로우로 통합하는 데 성공했습니다. 그들은 왜 기꺼이 그렇게 하는 걸까요? 모든 사람이 혜택을 얻기 때문입니다. 개발자와 시스템 관리자는 논쟁을 중단하고 서로가 돕기 시작합니다. 비즈니스 관리자는 제품 및 서비스를 판매하는 데 필요한 소프트웨어를 확보합니다. 경영진은 매출, 고객 만족, 시스템 안정성 등 중요한 대시보드 지표가 계속 상승되는 것을 봅니다. 즉, 모든 사람들이 최고의 성과와 최상의 고객 경험을 제공할 수 있습니다.
그러나 이러한 혜택은 쉽게 얻어지지 않습니다. 시스템을 원활하게 유지하면서 코드를 보다 자주 배포하려면, 사용자 환경에서 발생하는 모든 변경 사항을 정확하게 모니터링할 수 있어야 합니다. 뉴렐릭 플랫폼은 통합 알림 및 대시보드를 통해 개발자와 운영자들에게 디지털 고객 경험에서 애플리케이션 및 동적 인프라까지, 전체 스택에 대한 가시성을 제공합니다. 이는 조직 내 모든 사람들이 소프트웨어 배포 및 실행 방식을 실시간으로 이해하는 데 도움을 줍니다.