DevOps 도입을 가로막는 세 가지 요인

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

아니요, 당신 말고요. 바로 당신이요. 경영진은 현장에서 일하는 사람들만큼 DevOps에 열광하지 않으며, 그 이유는 다음 세 가지 핵심 우려 사항 중 하나에서 찾을 수 있습니다.

높은 성과를 내는 조직들은 DevOps를 단순히 도입하는 데 그치지 않고 적극적으로 수용했습니다. Puppet Labs의 기념비적인 DevOps 현황 보고서는 지난 2년간 이를 보여주었으며, 내년에도 이러한 상관관계를 다시 한번 뒷받침할 것으로 생각합니다. 여러 업계 설문조사와 연구에 따르면 조직들은 DevOps를 도입하고 있습니다. 하지만 과거에 애자일 및 린 애플리케이션 개발 방법론을 도입했을 때와 마찬가지로, 도입이 항상 우리가 생각하는 의미와 일치하는 것은 아닙니다. 실제로 조직들이 애플리케이션 개발에 ‘애자일을 도입한다’고 말한 것은 전체 프로젝트 중 비교적 적은 비율에만 애자일을 적용한다는 의미였습니다. 모든 프로젝트에 전면적으로 적용하며 과감히 뛰어들었다는 뜻은 아니었습니다.

DevOps도 마찬가지인 것으로 보입니다. 설문 응답자들은 이를 적극적으로 도입해 성과를 거두고 있지만, 경영진은 전반적으로 여전히 이 접근 방식에 미온적인 듯합니다. 실제로 당사의 애플리케이션 제공 현황 설문조사에 따르면, ‘전략적 영향력’은 2016년 15%에서 2017년 17%로 전년 대비 불과 2%포인트 상승하는 데 그쳤습니다. 클라우드 아키텍트와 스스로를 ‘DevOps’ 역할로 규정한 이들은 DevOps 이니셔티브를 전력으로 추진하고, 심지어 장벽을 넘어 프로덕션 환경에까지 적용하고 있을지 모르지만, 경영진은 여전히 이 접근 방식을 수용하는 데 뒤처져 있습니다. 이는 결국 ‘조직’ 전체가 반드시 DevOps를 전적으로 받아들이고 있는 것은 아니라는 뜻입니다.

IT 및 비즈니스 경영진이 DevOps를 마땅히 받아야 할 만큼 진심으로 환영하지 못하게 하는 데에는 세 가지 주요 우려 사항이 있는 것으로 보입니다.

1. 시간. 기존 환경에서 클라우드로, 모놀리스에서 마이크로서비스로, 수동에서 자동화로 전환하는 경우처럼 마이그레이션 관점이 필요한 모든 종류의 사내 IT 프로젝트는 때때로 시간 낭비에 불과한 것으로 여겨집니다. 이러한 프로젝트는 비즈니스 성장에 직접 기여하지 않으므로, 비즈니스 이해관계자 입장에서는 여기에 시간을 투입하는 것을 지지하기가 부담스러울 수 있습니다. DevOps를 지지하는 사람들은 이러한 프로젝트를 추진함으로써 달성할 명확한 목표와 기대 효과를 비즈니스 리더에게 제시해야 합니다. 비용 절감이든 IT 대응력 향상이든, 비즈니스 측이 예상 투자 수익을 이해해야 프로젝트의 필요성에 공감하고 이를 지원할 수 있습니다. 한 푼을 아끼면 한 푼을 버는 셈이지만, 한 푼을 투자하면 열 푼을 벌기도 합니다. 지금 DevOps에 투자하면 조직은 나중에 그 결실을 거둘 것입니다.
   
2. 중단. 어떤 IT 리더도 비즈니스 중단의 원인이 되고 싶어 하지는 않습니다. 지금 DevOps 이니셔티브에 투자하면 업무에 차질이 생길 수 있으며, 특히 모두가 프로덕션 파이프라인의 속도를 높여야 한다고 생각하는 상황에서 오히려 속도가 느려진다면 더욱 그렇습니다. 자동화와 오케스트레이션이 가능하도록 프로덕션 환경을 정비하려면 일상적인 비즈니스를 담당하는 시스템을 손대야 하는 경우가 많으므로, 이를 필요로 하는 모든 이니셔티브는 원치 않는 중단을 초래할 수 있습니다. 하지만 시스템을 프로비저닝하고 확장하며 관리하는 데 낡은 수동 방식을 계속 사용하는 것이야말로 실질적인 중단의 원인이 될 수 있습니다. 오늘이 아니라면 내일이라도 말입니다. 마찰 없는 프로덕션 환경의 주요 특징 중 하나는 용량과 서비스 수요에 온디맨드로 대응할 수 있다는 것입니다. 디지털 트랜스포메이션으로 인해 증가하는 수요의 무게에 IT가 짓눌릴수록 이를 실현하기는 점점 더 어려워집니다. 위험 없이는 보상도 없습니다. 애플리케이션 포트폴리오가 두 배 이상 늘어난 뒤보다 지금 위험을 감수하는 편이 오히려 위험 부담이 더 적을 가능성이 큽니다.
   
3. 종속성 선택으로 인해 특정 기술에 “종속되는 것”은 IT 리더들이 흔히 우려하는 문제입니다. 다행히 자동화와 오케스트레이션을 지원하는 대다수의 네트워크 장치와 시스템은 HTTP, REST, JSON과 같은 개방형 표준 프로토콜 및 개념을 기반으로 합니다. 바로 이 부분에서 사전에 시간을 들여 API와 템플릿을 최대한 활용하도록 시스템을 설계하고 아키텍처를 구성한 노력이 나중에 빛을 발합니다. API를 통해 CLI 명령을 단계별로 재현해야 하는 장치나 시스템과 통합하면 거의 확실하게 특정 기술에 종속됩니다. 템플릿의 가장 큰 이점 중 하나는 장치 및 시스템별 API에 대한 의존도를 낮춰, 향후 새로운 시스템이나 앱으로 쉽게 이전할 수 있는 소수의 명령에만 의존하도록 제한한다는 것입니다. 인프라가 REST 기반 API를 지원하는지 확인하고, 가능하면 항상 템플릿을 사용하여 나중에 시스템과 환경에서 쉽게 분리해 낼 수 있도록 하십시오.

물론 다른 우려 사항도 있지만, 기술과 방법론을 도입할 때 데이터 센터에서 시대를 막론하고 주로 되풀이되는 핵심 우려는 이 세 가지입니다. 시간이 걸리고, 업무 중단을 초래할 수 있으며, 특정 기술이나 공급업체에 종속될 가능성이 매우 높다는 것입니다. 철저한 사전 검토와 신중한 구현 방식, 그리고 지금 투자해 나중에 혜택을 얻겠다는 자세는 이러한 우려를 완화하고, 현재와 미래의 비즈니스 성장에 필요한 디지털 혁신을 가능하게 할 뿐 아니라 가속하는 견고하면서도 유연한 기반을 성공적으로 마련할 가능성을 높여 줍니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물