데브옵스(DevOps)란?

개요

대규모 기업과 웹 기반 조직들 모두 빠르게 데브옵스를 도입하고 있는 추세지만, 데브옵스가 정확히 무엇을 의미하는지 모르는 사람이 많습니다. 데브옵스는 문화, 운동, 접근 방식, 철학일까요? 아니면 이러한 여러 가지 요소가 융합된 것이거나 사람마다 다른 의미가 있을까요?

데브옵스를 어떻게 정의하느냐에 상관없이, 데브옵스의 성공을 위해서는 반드시 일련의 여정을 거쳐야 합니다. 기업이 데브옵스를 향한 여정의 어느 단계에 있든, 뉴렐릭은 다음과 같은 몇 가지 기본적인 질문에 답을 할 수 있도록 지원합니다.

• 데브옵스(DevOps)란?
• 어디서 유래했나요?
• 어떤 문제 때문에 데브옵스가 생겨났을까요?
• 데브옵스는 어떤 원리로 작동되나요?
• 데브옵스는 현재 얼마나 보편적으로 사용되고 있나요?
• 사람들이 데브옵스를 도입하는 이유는 무엇인가요?
• 어떤 혜택을 얻을 수 있나요?

1장: 데브옵스(DevOps)란?

‘데브옵스(DevOps)’는 패트릭 드보이스(Patrick Debois)가 2009년에 처음 소개한 용어로 이후 그는 이 분야의 전문가로 부상했습니다. 이 용어는 개발(development)’과 ‘운영(operations)’을 결합한 말로, 사람들이 데브옵스가 무엇을 의미하는지 이해할 수 있는 시작점을 제공합니다. 데브옵스는 프로세스, 기술 또는 표준이 아닙니다. 많은 추종자들은 데브옵스를 하나의 ‘문화’라고 언급하는데, 뉴렐릭도 이러한 의견에 동의합니다. 도입률, 미래를 위한 추세 같은 주제를 언급할 때 '데브옵스 운동’이라는 용어가 사용되고, 데브옵스 문화를 도입한 IT 조직을 지칭하는 의미로 ‘데브옵스 환경’이라는 용어가 사용되기도 합니다.

이 가이드에서는 데브옵스에 대해 훨씬 더 자세히 설명하겠지만, 먼저 사용할 수 있는 정의가 필요합니다. 뉴렐릭은 시장조사기관 가트너(Gartner)의 정의를 선호합니다.

“데브옵스는 시스템 위주의 접근 방식이라는 문맥에서 민첩하고 효율적인 관행을 도입함으로써, IT 서비스를 신속하게 제공하는 데 초점을 맞춘 IT 문화의 변화를 나타냅니다. 데브옵스는 사람(과 문화)을 강조하며, 운영 팀과 개발 팀 간의 협업을 개선하고자 합니다. 데브옵스 구현에는 기술, 특히 수명주기 관점에서 프로그래밍 가능한 동적 인프라를 활용할 수 있는 자동화 툴을 활용합니다.”

중요한 것은, 데브옵스의 의미가 확장되어 기능, 패치, 업데이트를 자주 제공할 수 있도록 빠른 피드백 루프를 사용하여 소프트웨어 개발 주기를 단축하는 데 사용되는 프로세스, 문화 및 사고 방식을 포괄하는 용어가 되었다는 사실입니다.

2장: 데브옵스의 기원

데브옵스의 기원에 대해서는 의견이 분분하지만, 처음부터 완전한 개념은 아니었다는 점은 확실합니다. 데브옵스라는 씨앗이 오래 전에 심어졌고, 여러 분야의 미래 지향적인 IT 전문가들이 지속적으로 이를 키워왔다고 말할 수 있습니다. 지금의 데브옵스를 있게 한 두 가지 주요 요인은 다음과 같습니다.

• 엔터프라이즈 시스템 관리(ESM). 데브옵스의 초기 정의에 관여한 사람들은 대부분 시스템 관리자였습니다. 이 운영 전문가들은 설정 관리, 시스템 모니터링, 자동화된 프로비저닝, 툴체인 접근 방식 등 데브옵스에 ESM의 주요 모범 사례를 적용했습니다.
• 애자일 개발. 한 업계 전문가의 말을 빌자면, "데브옵스는 애자일(Agile)의 결과물로 해석될 수 있습니다. 애자일 소프트웨어 개발은 고객, 제품 관리, 개발자 및 QA의 긴밀한 협업을 통해 서로의 격차를 해소하고, 더 나은 제품을 빠르게 개발할 수 있도록 신속하게 반복하는 것으로 규정될 수 있습니다. [데브옵스는] 서비스 제공과 앱 및 시스템의 상호 작용은 클라이언트에게 제공하는 가치 제안의 토대가 되는 부분이기 때문에, 제품 팀은 이러한 문제를 우선순위에 두어야 합니다. 이러한 관점에서 데브옵스는 애자일 원칙을 코드의 경계를 넘어 전체 제공 서비스로 확장하고 있습니다.”

3장: 데브옵스가 생긴 이유

개발자와 시스템 관리자는 많은 것에 대해 의견을 달리 하지만, 비즈니스 측면에서 고객들을 위한 목표가 서로 다르다는 점에는 동의합니다. 한 편, 비즈니스 사용자들은 새로운 기능, 새로운 서비스, 새로운 수익 흐름 등 빠른 변화를 요구합니다. 동시에, 안정적이고 정전 및 중단되지 않는 시스템을 원합니다. 이는 기업이 변화를 신속하게 제공하고, 불안정한 운영 환경을 해결하거나, 안정적이지만 오래된 환경을 유지해야 하는 것 사이에서 선택을 해야만 하는 결과를 낳습니다.

당연히 경영진에게는 둘 다 용납할 수 없는 선택입니다. 더 중요한 것은, 두 가지 선택 모두 기업이 고객에게 최상의 솔루션을 제공할 수 있도록 만들어 주지 않는다는 것입니다.

개발자들은 소프트웨어를 더 빠르게 출시하기를 원합니다. 애초에 개발자가 필요한 이유도 바로 이 때문입니다. 반면, 운영자들은 적절한 안전 조치가 마련되지 않은 상태에서 빠른 변화를 도입하는 것이 시스템을 불안정하게 만들 수 있다는 사실을 알고 있으며, 이는 용납할 수 없는 상황입니다.

데브옵스는 이러한 딜레마를 해결하기 위해 만들어졌습니다. 비즈니스 사용자, 개발자, 테스트 엔지니어, 보안 엔지니어, 시스템 관리자 등 소프트웨어 개발 및 배포와 관련된 모든 사람을 고도로 자동화된 단일 워크플로우로 통합하고, 전체 시스템의 무결성과 안정성을 유지하면서 모든 사용자 요구 사항을 충족하는 고품질 소프트웨어를 신속하게 제공하는 데 초점을 둡니다.

이러한 다양한 그룹들이 어떻게 서로 협력할 수 있을까요? 부서라는 기존의 틀과 역할을 뛰어넘는 공통적인 원칙을 도입하면 됩니다. 예를 들면,

• 기대치와 우선순위, 그리고 이를 위한 지침이 되어줄 근본적인 신념을 정립합니다.
• 문제 해결을 위해 팀 내에서 또 팀 간에 협업을 합니다.
• 일상적이고 반복적인 프로세스는 자동화하여 더 높은 수준의 작업을 위한 시간을 확보합니다.
• 작업에 피드백을 통합하여 운영 단계로 이동하는 모든 것을 측정합니다.
• 관련된 모든 사람과 데이터를 공유하여 여러 기술 및 전문 지식을 아우르는 보다 효과적인 협력 문화를 조성합니다.

4장: 데브옵스, 애자일(Agile), SRE

기업들은 데브옵스로의 전환, 사이트 안정성 엔지니어(SRE) 고용, 민첩성 향상에 대해 자주 언급을 합니다. 이러한 용어들이 서로 어떤 관련이 있을까요?

민첩성과 효율성은 팀이 짧은 개발 주기와 빠른 피드백을 통해 반복하는 방식입니다. 민첩성은 문화에 초점을 맞추며 어떤 툴을 사용하는가와는 무관합니다.

데브옵스는 엔지니어링 조직이 교차 기능 팀을 활용해 협업하는 방식입니다. 데브옵스는 문화로 시작해서 툴을 갖추는 일로 나아갑니다.

사이트 안정성 엔지니어는 엔지니어링 조직이 자동화를 하는 방식으로, 소프트웨어 엔지니어링의 사고방식을 가진 사람에게 고도로 확장된 운영을 맡깁니다. SRE는 툴을 갖추는 것에서 시작해서 문화를 조성하는 방향으로 나아갑니다.

데브옵스의 변종(예: “SecDevOps”)은 소프트웨어 개발 수명 주기 초기에 다른 조직/관행을 삽입 또는 추가하는 것으로, 이러한 다양한 데브옵스 유형이 확산되었다는 것은 현대 조직에서 기능 부서의 통합이 증가하고 있다는 사실을 말해줍니다.

5장: 데브옵스의 작동 원리

모든 문화와 마찬가지로 데브옵스도 다양한 변종들을 통합합니다. 그러나 대부분의 업계 전문가들은 다음의 역량들이 협업, 자동화, 연속 통합, 연속 배포, 연속 테스트, 연속 모니터링, 신속한 문제 해결 등 거의 모든 데브옵스 문화에 공통 요소라는 데 동의할 것입니다.

협업

개발 및 IT 운영 팀이 서로에게 책임을 전가하는 것이 아니라 함께 작업을 수행합니다. 애초에 이 두 그룹이 분리되어 있었기에 데브옵스가 생겨나게 되었지만, 데브옵스는 IT 조직 그 이상으로 확장됩니다. 협업의 필요성은 소프트웨어 배포에 관여된 모든 사람(개발 팀과 운영 팀 간뿐만 아니라 테스트, 제품 관리, 경영진 등 모든 직원)으로 확장되기 때문입니다.

“데브옵스의 성공은 팀과 개인이 기업 전반에서 얼마나 잘 협업하여 작업을 보다 빠르고 효율적으로 수행할 수 있느냐에 달려 있습니다.”

—토니 브래들리(Tony Bradley), “Scaling Collaboration in DevOps,” DevOps.com

자동화

데브옵스는 자동화에 크게 의존하기 때문에 툴이 필요합니다. 자체 구축한 툴. 구매한 툴. 오픈 소스 툴. 독점 툴. 이러한 툴들이 기업 전반에 아무렇게나 분산되어 있지는 않습니다. 데브옵스는 툴 망을 사용해 전체 소프트웨어 개발 및 배포 프로세스의 많은 부분을 자동화합니다.

주의해야 할 것은, 데브옵스 툴들이 매우 뛰어나기 때문에 데브옵스를 툴 모음이라고 보는 경향이 있다는 것입니다. 데브옵스가 툴에 의존하는 것은 사실이지만 툴 그 이상입니다.

연속 통합

데브옵스는 애자일 문화에서 등장했기 때문에 데브옵스 문화에서는 보통 연속 통합을 발견할 수 있습니다. 연속 통합은 애자일 접근 방식의 기본 원칙입니다.

“데브옵스의 토대는 연속 통합(CI)입니다. CI는 그래디 부치(Grady Booch)가 설계하고 명명한 기술로, 팀의 모든 개발자로부터 얻은 소스 코드 업데이트를 공유되는 단일 메인라인으로 지속적으로 병합하는 것입니다. 이러한 연속적인 통합은 개발자의 소프트웨어 프로젝트에 대한 로컬 사본이, 다른 사람의 새 코드가 추가되어도 고립되는 것을 막음으로, 병합 시 발생하는 치명적인 충돌을 방지합니다.”

—아론 코이스(Aaron Cois), “Continuous Integration in DevOps”, DevOps Blog, Software Engineering Institute, Carnegie Mellon

연속 통합의 애자일 개발 원칙은 개발 그룹에 문화적인 의미가 있습니다. 개발자가 자신의 작업을 다른 개발자의 작업과 자주(적어도 매일) 통합하도록 만듬으로써, 통합 문제나 충돌을 워터폴(waterfall) 방식의 개발보다 훨씬 더 일찍 노출시킬 수 있습니다. 그러나 이러한 이점을 얻기 위해서는 개발자들이 서로 더 자주 소통을 해야 합니다. 이는 세상으로 모듈을 내보낼 수 있을 때까지 몇 주 또는 몇 개월 동안 작업에 매진하는 천재 개발자의 이미지에는 걸맞지 않은 프로세스입니다. 그러한 개방된, 잦은 소통이라는 씨앗은 데브옵스에서 활짝 피어납니다.

연속 테스트

데브옵스의 테스트 영역은 쉽게 간과될 수 있습니다. 가트너는 "소프트웨어 장애로 인한 비용과 영향이 커짐에 따라, 기존 사용자 환경을 저해하거나 조직을 새로운 보안, 안정성 또는 규제 준수 위험에 노출시킬 수 있는 새로운 기능을 도입하는 릴리스는 허용할 수 없게 되었다"라고 설명합니다. 연속 통합과 연속 배포가 가장 중요하기는 하지만, 연속 테스트도 데브옵스의 중요한 일부로 자리를 잡아가고 있습니다.

연속 테스트는 단순한 QA 기능이 아니며, 개발 환경에서 시작됩니다. 개발자들이 코드를 QA 팀에 던져주고 ‘이제 마음대로 하세요’라고 말할 수 있었던 날은 이제 지났습니다. 데브옵스 환경에서의 품질은 모든 사람의 책임입니다. 개발자는 높은 품질의 코드를 구축하고 테스트 데이터 세트를 제공합니다. QA 엔지니어는 자동화 테스트 사례와 테스트 환경을 설정합니다.

QA 측면에서 필요한 것은 속도입니다. QA 주기가 며, 몇 주가 걸리면 워터폴 방식의 긴 일정과 다름이 없게 됩니다. 테스트 프로세스의 대부분을 자동화하고 테스트 방법을 재정의함으로써, 테스트 엔지니어는 빠른 시간 내에 테스트를 완료할 수 있습니다.

“연속 테스트를 도입하면, 각 애플리케이션이 조직에 미치는 비즈니스적 위험을 평가하는 데 도움이 되는 중앙화된 의사 결정 시스템이 만들어집니다. 지속적으로 적용하면, 개발 팀은 비즈니스의 기대치를 충족하고, 관리자는 정보에 입각해 비교 결정을 내리는 데 필요한 가시성을 확보하여, 잠재적 릴리스의 비즈니스 가치를 최적화할 수 있습니다."

—Continuous Testing for IT Leaders, Parasoft

의외라고 생각될 수도 있지만, 운영 팀은 테스트 및 QA에서 중요한 역할을 합니다. 운영 팀은 모니터링 툴이 있고 테스트 환경이 제대로 설정되었는지 확인할 수 있습니다. 또한 기능, 부하, 스트레스, 누출 테스트에 참여하여 유사한 애플리케이션을 운영 환경에서 실행한 경험을 바탕으로 분석을 제공할 수 있습니다.

연속 테스트를 통해 얻어지는 혜택은 노력할 만한 가치가 있습니다. 데브옵스 환경에서 테스트 팀은 개발자들이 품질과 속도의 균형을 유지하는 데 도움을 줍니다. 자동화된 툴을 사용하면, 테스트 비용이 절감되고 테스트 엔지니어가 시간을 보다 효율적으로 활용할 수 있게 됩니다. 가장 중요한 것은 연속 테스트는 프로세스 초기에 통합 테스트를 가능하게 함으로써 테스트 주기를 단축시킨다는 것입니다.

또한 연속 테스트는 가상화된 독립된 서비스들을 통해 테스트 병목 현상을 제거할 수 있으며, 시스템이 변경되면 손쉽게 구현, 공유 및 업데이트할 수 있는 가상화된 테스트 환경을 간편하게 생성할 수 있습니다. 이러한 역량은 테스트 환경의 프로비저닝 및 유지 관리 비용을 절감해주며, 수명 주기 초기에 통합 테스트를 수행할 수 있게 해줌으로써 테스트 주기 시간을 단축해줍니다.

연속 배포

아마존 웹 서비스(Amazon Web Services) 팀은 연속 배포를 ‘데브옵스 소프트웨어 개발 관행’으로 정의합니다. 이러한 관행에서는 코드 변경이 자동으로 구축 및 테스트되고 운영을 위해 준비가 됩니다. 이는 빌드 단계 이후에 모든 코드 변경 사항을 테스트 환경 및/또는 운영 환경에 배포함으로써 연속 통합으로 확장됩니다. 연속 배포가 제대로 구현되면, 개발자들은 표준화된 테스트 프로세스를 통과한 배포 가능한 빌드 아티팩트를 상시 보유하게 됩니다.

실제 릴리스 빈도는 기업의 전략이나 목표에 따라 크게 달라질 수 있습니다. 데브옵스를 사용해 높은 성과를 내는 조직은 하루에 수차례를, 중간 정도의 성과를 내는 조직은 일주일에 한 번 또는 한 달에 한 번 정도 릴리스를 합니다.

정확히 무엇을 릴리스하는지 또한 다릅니다. 일부 조직의 경우 QA 및 운영 팀에서 잠재적 릴리스를 분류합니다. 많은 릴리스는 사용자들에게 직접 배포되고, 일부는 개발 팀으로 돌아가며, 또 어떤 일부는 전혀 배포되지 않습니다. 다른 기업들은 개발자들의 모든 작업을 사용자들에게 제공하고 실시간 모니터링과 신속한 문제 해결을 통해 드물게 발생하는 장애의 영향을 최소화합니다. 각 업데이트의 사이즈가 더 작기 때문에, 장애를 일으킬 가능성이 크게 줄어든다는 사실도 주목할 만 합니다.

연속 모니터링

연속 배포 환경에서는 릴리스 수가 많기 때문에, 워터폴 개발 접근 방식에 일반적으로 요구되는 엄격한 테스트를 수행할 수가 없습니다. 데브옵스 환경에서는 오류를 실시간으로 찾아 해결해야 합니다. 어떻게 할까요? 바로 연속 모니터링을 통해서 입니다.

팀은 연속 모니터링을 통해 소프트웨어의 성능 및 가용성을 측정하고 안정성을 개선합니다. 연속 모니터링은 문제의 근본 원인을 신속하게 파악하여 가동 중단을 예방하고, 사용자 문제를 최소화할 수 있도록 해줍니다. 일부 모니터링 전문가들은 서비스의 정의에 모니터링이 포함되어야 한다고 주장하기도 하는데, 이는 모니터링이 서비스 제공에 핵심 요소라고 생각하기 때문입니다.

테스트와 마찬가지로, 모니터링은 개발 단계에서 시작됩니다. 운영 환경을 모니터링하는 데 사용하는 툴을 개발 과정에 사용하면 운영 환경에 들어가기 전에 성능 문제를 파악할 수 있습니다.

데브옵스는 서버 모니터링과 애플리케이션 성능 모니터링이라는 두 가지 종류의 모니터링이 필요합니다. 모니터링에 대한 대화는 툴에 대한 대화로 직결됩니다. 적절한 툴이 없으면 효과적으로 모니터링을 할 수 없기 때문입니다. 데브옵스 툴(및 더 많은 데브옵스 관련 컨텐츠) 목록을 확인하시려면, New Relic DevOps Hub를 방문하시기 바랍니다.

6장: 데브옵스를 도입하는 조직

초기 스타트업부터 100년 이상 된 기업으로까지, 데브옵스는 전 세계 IT 조직으로 확산되고 있습니다. 한 설문 조사에 따르면 기업 중 74%가 어떤 방식으로든 데브옵스를 구현하고 있는 것으로 나타났습니다.

어떤 기업들이 데브옵스를 수용하고 있을까요? Etsy, Facebook, Amazon, Netflix와 같은 웹 기반 ‘유니콘’ 기업들이 손꼽히는 데브옵스 리더들이긴 하지만, 오늘날은 사실 모든 유형의 기업들이 데브옵스를 활용합니다. 주요 미디어 회사인 Sony Pictures, 금융 서비스 업계의 거물 Barclays Bank, 빌딩 제품 제조업체 USG는 자주 회자되는 데브옵스의 주요 성공 사례입니다.

놀랍게도, 81%의 대기업들이 자사 조직 내 어디에선가 데브옵스를 도입하고 있는 것으로 나타났습다. 70%의 중소기업들도 데브옵스를 활용하며 그 혜택을 누리고 있습니다. 주목할 것은, 기업의 규모와 데브옵스의 성공은 큰 관계가 없다는 것입니다.

심지어 정부 및 준정부 조직들도 데브옵스를 수용하고 있습니다. 예를 들어 Fannie Mae는 데브옵스를 사용해 비즈니스를 혁신하고 느린 속도로 변화하던 조직을 빠른 속도로 변화하는 조직으로 전환했습니다.

미국 특허청도 데브옵스로 전환해, 현재 주당 평균 1,000건의 자동화된 빌드를 생성하고 있습니다. 미국 연방조달청에서는 프로젝트를 더 빠르게, 더 높은 품질로 제공하기 위해 운영 컨테이너, 자동화된 워크플로우, 마이크로서비스 등을 사용해 IT 운영을 현대화하고 있습니다.

데브옵스 전문가이자 작가인 진 킴(Gene Kim)은 클라우드 및 컨테이너 기술의 등장으로 데브옵스가 전 세계적으로 확산되고 있지만, 데브옵스는 여전히 더 성장할 여지가 있다고 말합니다. 이미 데브옵스가 자리를 잡고 있는 조직이라면, 이는 새로운 개발 노력을 추진하는 형태로 나타날 수 있습니다.

“이제 데브옵스가 Google, Amazon, Facebook, Netflix 같은 유니콘 기업뿐만 아니라, 모든 기술 조직, 특히 크고 복잡한 조직에 적합하다는 것을 입증할 증거를 확보했습니다. 정말 흥분되는 일은 이 조직들이 보통 유니콘에서만 볼 수 있는 결과를 얻고 있다는 것입니다.”

—진 킴(Gene Kim), DevOps expert

7장: 조직들이 데브옵스를 도입하는 이유

데브옵스는 개발 팀, 운영 팀, 테스트 팀 등 소프트웨어 망의 모든 사람들에게 혜택을 제공합니다. 또한 데브옵스는 소프트웨어의 수익화를 담당하는 관리자와 수익률을 우려하는 경영진 등 기업의 비즈니스 측면에도 영향을 줍니다. 다음은 각 그룹이 언급한 몇 가지 혜택입니다.

개발자

자동화된 프로비저닝은 프로그래머들에게 큰 도움이 됩니다. 문서 작업이나 긴 승인 주기가 없고, IT 팀이 서버 프로비저닝할 때까지 기다리지 않고도 개발 환경을 구축할 수 있기 때문입니다. 개발자가 컴퓨팅 성능, 스토리지, 네트워크, 애플리케이션 등 적절한 리소스를 모두 활용해 몇 분 내에 작업 환경을 프로비저닝할 수 있게 되면 작업 방식이 바뀝니다. 훨씬 더 창의적이고 혁신적이 될 수 있습니다. 더 쉽게 여러 옵션을 사용해 보고, 다양한 시나리오를 실행하며, 코드를 더 철저하게 테스트할 수 있습니다.

많은 개발자들이 데브옵스 환경에서 처음 작업을 시작하면서 놀라게 되는 사실 중 하나는, 운영 팀이라는 테두리 안에서 정확이 어떤 일이 벌어지고 있는지를 이해하게 된다는 것입니다. 이러한 지식은 개발자들이 공동으로 문제를 해결한다는 모드로 작업을 효과적으로 수행하는 데 도움이 됩니다. 문제가 더 빨리 해결되고 방해 요소도 줄어듭니다. 무엇보다도, 사이트가 다운되어 다급해진 운영 팀이 밤늦게 전화를 거는 일이 사라집니다. 이는 개발자의 직업 만족도와 삶의 질 향상으로 직결됩니다.

운영

시스템 관리자는 시스템 안정성에 대해 끊임없이 집착한다는 인식이 널리 퍼져 있습니다. 그러한 인식은 사실입니다. 최악의 시나리오는 소프트웨어 릴리스를 운영에 배포하고 몇 초 후에 시스템이 다운된 상황에서, 사용자들은 불만을 터뜨리는데 개발자는 자신의 책임이 아니라며 책임 전가를 하고, 빠르고 효과적인 해결을 위한 명확한 경로도 없는 경우입니다.

데브옵스 방식을 조기에 채택한 사람들은 개발자의 참여도를 높임으로써 시스템 안정성이 향상된다는 사실을 깨닫게 되었습니다. 무엇보다, 소규모로 자주 릴리스를 하면, 시스템의 변동성이 감소하여 치명적인 오류의 위험이 낮아지는 것으로 나타났습니다. 게다가, 이러한 한정된 릴리스는 한밤 중이나 주말이 아니라 모든 사람이 근무를 하며 함께 문제를 해결할 수 있는 주중에 생성될 수 있습니다.

또한 자동화는 수동 작업에서 흔히 발생하는 인적 오류를 제거하여 일상적인 작업에 소요되는 시간을 줄여주는 추가적인 이점을 제공합니다. 시스템 관리자에게는 새로운 기술, 경력 기회, 그리고 중단 없는 수면과 사생활이라는 측면에서 고려해야 하는 삶의 질 문제도 있습니다. 데브옵스 환경에서 운영 팀은 기존 환경보다 훨씬 더 많은 툴들에 의존합니다. 종종 구현 프로세스의 일부를 자동화하는 스크립트를 자체적으로 작성하고 툴을 구축하기도 합니다.

이 모든 것을 종합해 보면, 최근 데브옵스 엔터프라이즈 서밋(DevOps Enterprise Summit)에 참석한 사람들 중 가장 많은 직책이 운영 책임자’라는 것은 놀라운 일이 아닙니다.

테스트 엔지니어

데브옵스가 내부 테스트 측에 미치는 영향은 아주 큽니다. 한 업계 관련자는 이렇게 말합니다..

“지금은 며칠, 심지어 몇 분 내에 거의 연속적으로 여러 차례 반복해서 릴리스를 여러 다른 환경으로 푸시하는 세상입니다. 모든 것이 요금을 지불하며 많은 요구를 하는 고객들이 있는 최종 운영 환경으로 푸시됩니다. 릴리즈는 많은데, 테스트할 시간은 부족하고 품질에 대한 부담도 엄청납니다. 이론적으로, 이보다 더 완벽하게 자동화된 테스트가 필요한 사례가 있을까요?”

데브옵스는 소프트웨어를 테스트할 새로운 방법이 필요하며, 이는 테스트 엔지니어들이 혁신하도록 만들고 있습니다. 자동화된 프로비저닝을 통해 테스트 엔지니어는 운영 환경과 거의 동일한 테스트 환경을 프로비저닝하여, 보다 정확하게 테스트를 수행하고 새로운 릴리스의 성능을 예측할 수 있는 역량을 향상시킬 수 있습니다. 다른 그룹들과 마찬가지로 자동화 및 협업 덕분에 테스트 엔지니어들의 생산성이 향상됩니다.

제품 관리자

기술적으로 데브옵스는 기업의 IT 부서와 유사합니다. 그러나 제품 관리자는 마케팅 및 비즈니스 담당자와 함께 다음과 같은 엄청난 혜택을 누릴 수 있습니다.

• 더 빠른 피드백: 새로운 제품이나 기능이 고객에게 제공되는 순간, 제품 관리자는 실제 피드백을 받기 시작합니다.
• 응답성 향상: 데브옵스는 연속 배포를 통해 고객의 니즈에 대응하여 새로운 기능의 출시 기간을 대폭 단축합니다.
• 낭비 및 위험 감소: 개발 리소스는 다음 공식 릴리스가 나올 때까지 기다리지 않고 문제를 해결하거나 새로운 기능에 대한 작업을 수행할 수 있습니다.

조금 더 자세히 알아보도록 하겠습니다. 데브옵스 환경에서 비즈니스 이해 관계자들은 개발 프로세스에 더 큰 영향을 미칩니다. 데브옵스의 협업 정신 덕분에, 개발자들은 비즈니스 요구 사항에 관심을 갖고 제품 관리자와의 관계를 돈독히 합니다. 또한 데브옵스는 제품 관리자에게 새로운 가격, 기능 및 제품 번들이 어떤 영향을 미치고 있는지에 대한 즉각적인 피드백을 제공하여, 제품 관리자가 변경 사항을 테스트하고 그 효과를 평가할 수 있도록 합니다.

각 부서의 관리자들은 소프트웨어가 더 빨리 출시되어 경쟁력을 갖게 되기 때문에 데브옵스를 좋아합니다. 데브옵스는 시스템의 안정성을 향상시키므로 고객 경험이 중단되는 경우도 줄어 충성도가 향상됩니다. 이는 높은 이탈률을 방지할 수 있는 완벽한 방법입니다.

임원

패트릭 드보이스와 다른 IT 인재들이 데브옵스를 처음 시작할 때는 기업 이사회가 어떻게 데브옵스를 받아들일지는 전혀 신경을 쓰지 않았을 것입니다. 그러나 데브옵스는 이제 같은 경영진에게도 중요한 문제입니다.

경영진은 데브옵스의 어떤 점을 마음에 들어할까요? 한 가지는 데브옵스가 기업이 고품질 제품을 제공하고, 기존 소프트웨어 개발 방식에 의존하는 경쟁업체보다 훨씬 빠르게 제품을 시장에 출시할 수 있도록 해준다는 것인데 이는 수익에 영향을 미치고 브랜드 가치를 향상시킵니다. 또 다른 이유는 최고의 인재를 유치하고 유지할 수 있다는 점입니다. 능력 있는 개발자, 시스템 관리자 및 테스트 엔지니어는 언제나 가장 현대적이고 생산적인 방식으로 작업하기를 원하기 때문입니다. 마지막으로, 개발자, 운영 및 QA 담당자가 함께 작업을 하면, 경영진이 부서간 분쟁에 휘말리는 경우가 거의 없기 때문에 함께 성공적으로 도달하기 위해 노력하는 비즈니스 목표를 수립하는 데 더 많은 시간을 할애할 수 있습니다.

“성과가 높은 (데브옵스) 팀의 직원들은 자신이 일하는 조직을 좋은 직장으로 친구에게 추천할 확률이 2.2배 더 높았고, 자신의 팀을 훌륭한 근무 환경으로 친구에게 추천할 확률은 1.8배 더 높았습니다. 조사 결과, 직원 몰입도가 높은 기업의 매출이 그렇지 않은 기업보다 2배 반 이상 증가했다는 사실은 주목할 만합니다."

—2016 State of DevOps Report, Puppet Inc. and DORA

8장: 데브옵스의 이점

데브옵스를 통해 얻을 수 있는 몇 가지 놀라운 혜택들이 있습니다. 그러나 주의가 필요합니다. 누군가 “리터당 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개월마다 한 번씩 배포를 합니다.

결론

“데브옵스는 목표가 아니라 지속적인 개선을 위한 끊임없는 프로세스입니다.”

—제즈 험블(Jez Humble), Founder and CTO, DevOps Research and Assessment

지난 10년간 데브옵스에 대한 실험을 해본 결과, 확실해진 사항은 데브옵스는 지속될 것이고, 그만한 이유가 있다는 것입니다. 데브옵스는 많은 사람들이 불가능하다고 생각했지만, 비즈니스 사용자, 개발자, 테스트 엔지니어, 보안 엔지니어 그리고 시스템 관리자를 고객 요구 사항을 충족하는 데 중점을 둔 단일 워크플로우로 통합하는 데 성공했습니다. 그들은 왜 기꺼이 그렇게 하는 걸까요? 모든 사람이 혜택을 얻기 때문입니다. 개발자와 시스템 관리자는 논쟁을 중단하고 서로가 돕기 시작합니다. 비즈니스 관리자는 제품 및 서비스를 판매하는 데 필요한 소프트웨어를 확보합니다. 경영진은 매출, 고객 만족, 시스템 안정성 등 중요한 대시보드 지표가 계속 상승되는 것을 봅니다. 즉, 모든 사람들이 최고의 성과와 최상의 고객 경험을 제공할 수 있습니다.

그러나 이러한 혜택은 쉽게 얻어지지 않습니다. 시스템을 원활하게 유지하면서 코드를 보다 자주 배포하려면, 사용자 환경에서 발생하는 모든 변경 사항을 정확하게 모니터링할 수 있어야 합니다. 뉴렐릭 플랫폼은 통합 알림 및 대시보드를 통해 개발자와 운영자들에게 디지털 고객 경험에서 애플리케이션 및 동적 인프라까지, 전체 스택에 대한 가시성을 제공합니다. 이는 조직 내 모든 사람들이 소프트웨어 배포 및 실행 방식을 실시간으로 이해하는 데 도움을 줍니다.