"철저한 준비만이 살 길" 주의해야 할 또 다른 데브옵스 실수 10가지

'데브옵스 통합 과정에서 벌어지는 10가지 실수, 미연에 방지하기'라는 최근 기사에서 필자는 소프트웨어 개발 작업을 지연시킬 수 있는 10가지 데브옵스 "함정"을 살펴봤다. 하지만 여러 전문가 인터뷰를 통해 알게 된 함정이 너무 많아 기사 하나에 다 담지 못했다. 여기서는 데브옵스팀과 IT 책임자가 피해야 할 잠재적인 장애물을 10가지 더 알아본다. 
 

변화에 대한 거부 

데브옵스 실행 과정에서는 마찰이 발생할 수 있다. 팀원 중에는 변화를 받아들이는 데 어려움을 겪는 경우도 있다. 데브옵스를 추진하려면 의사 결정을 하는 경영진뿐만 아니라 개발 및 운영팀의 동의도 끌어내야 한다. 

신발 판매업체 365 크록스(365 Crocs)의 소프트웨어 개발자이자 창업자인 안 응우옌은 "사람은 기존의 일하는 방식에 익숙해져 있으므로 데브옵스는 저항에 직면할 수 있다. 파일럿 프로젝트부터 작게 시작해서 이점을 직접 보여줘야 한다"라고 말했다. 

안전 장치 관리를 위한 클라우드 기반 제품을 제공하는 인스펙트NT랙(InspectNTrack)의 수석 소프트웨어 개발자이자 파트너인 숀 스피틀은 개발자, 운영자, 보안 담당자 및 기타 팀 모두 새로운 프로세스와 툴 도입에 거부감을 가질 수 있다면서 "경영진이 데브옵스의 이점을 명확하게 전파해서 전반적인 동의를 끌어내야 한다. 교육을 제공하고 성공적인 결과를 알리고 각 팀에 데브옵스 챔피언을 지정하면 문화적 변화를 이끄는 데 도움이 될 수 있다"라고 조언했다. 

필요한 기술의 부재 

성공적인 데브옵스를 위해서는 폭넓은 기술이 필요하지만, 그런 기술을 갖춘 인력을 보유하지 못한 기업이 많다. 

IT 전문가 지원 단체인 컴퓨터기술산업협회(CompTIA)에 따르면 데브옵스 엔지니어에게는 리눅스 기본 요소, 스크립팅, 관련 툴 및 기술에 대한 지식, 그리고 클라우드 서비스, 코딩, 자동화, 테스트, 보안, 선제적 모니터링, 컨테이너화, 지속적 통합, 버전 관리 등에 대한 기술이 필요하다. 

리눅스 재단 산하 클라우드 네이티브 컴퓨팅 재단(Computing Technology Industry Association, CNCF)의 CIO이자 생태계 책임자인 테일러 도레자이는 "필요한 지식을 갖춘 전문가를 찾거나 교육을 통해 갖추도록 하는 데는 시간과 노력이 필요하다"라고 언급했다. CNCF는 오픈소스 개발자 컨퍼런스를 열고 쿠버네티스와 같은 핵심 소프트웨어 스택 구성요소르 호스팅한다. 

이어 "책임자는 교육 프로그램을 통한 기존 팀 업스킬, 데브옵스 서비스 제공업체와의 파트너십, 지속적인 학습 문화 장려에 투자해야 한다. 개발팀과 운영팀 간의 긴밀한 협업을 장려하는 것도 기술 공유, 데브옵스 관행에 대한 더 전체적인 이해를 촉진하는 데 효과적"이라고 말했다. 

데브옵스 구현에 필요한 기술을 제공하는 데 도움이 될 수 있는 여러 데브옵스 관련 자격증이 있지만 기업은 공식적인 교육 및 자격증 외에, 필요한 기술을 습득할 다른 방법도 찾아봐야 한다. 

SD-WAN 및 사이버보안에 특화된 마켓플레이스인 네티파이(Netify)의 정보 보안 리더 타이무르 일잘은 "공식적인 교육이 전부가 아니다. 평가 및 테스트 프로젝트를 통해 학습하면 시간이 지나면서 지식이 쌓이게 된다. 가장 도움이 되는 것은 업무 수행 방식의 변화를 위한 명확한 비전"이라고 설명했다. 

섀도우 IT 

섀도우 IT는 중앙 IT 부서가 아닌 개별 부서나 그룹에서 배포한 IT 시스템으로, 여전히 기업에 큰 위험 요소다. 특히 클라우드가 성장하면서 기업 내의 많은 사람이 기술 리더의 감독을 벗어나 SaaS 또는 기타 제품을 조달할 수 있게 됐다. 

게임 개발 및 발행사인 워게이밍(Wargaming)의 데브옵스 엔지니어 막심 무라베브는 "많은 기업이 복잡한 레거시 시스템, 문서화되지 않은 프로세스, 무단 애플리케이션에 발이 묶여 있다. 이런 시스템은 단순히 기술적 요소를 넘어 기업의 문화와 운영 구조 내에 깊이 연관된다"라고 지적했다.  

무라베브는 어려운 부분은 섀도우 시스템을 없애는 것이 아니라 "그 목적을 이해하고 가능한 경우 통합하고 필요에 따라 더 우월하고 규정에 부합하는 대안을 제공하는 것"이라며 "이를 위해서는 기술자일 뿐만 아니라 인류학자, 심리학자 역할까지 하면서 복잡한 인적 네트워크와 이들의 시스템 사용 습관에 대응할 수 있는 데브옵스 리더가 필요하다"라고 말했다. 

양자 복잡성 

데브옵스에는 움직이는 부분과 그 사이의 연결 고리가 많다. 즉, 한 지점에서의 변경이 다른 여러 곳에 예기치 못한 방식으로 영향을 미칠 수 있으므로 의사 결정이 복잡해진다. 

무라베브는 "데브옵스 환경에서 의사 결정은 물리학의 양자 얽힘 원리와 비슷하다. 시스템의 어느 한 부분에서 내린 의사 결정이 기업 전체에 즉각적인 영향을 미칠 수 있다. 특히 대규모 환경에서 이런 상호연결성은 얼핏 단순해 보이는 의사 결정에서 예상하지 못한 결과를 초래하기도 한다"라고 언급했다. 

이 문제를 해결하기 위해서는 무라베브가 말하는 "양자 리더십", 즉 다양한 결과와 그 확률을 고려해 정보에 근거한 의사 결정을 내리는 역량이 필요하다. 무라베브는 "예측 분석에 투자하고 지속적 학습 문화를 조성하고 빠르고 예상치 못한 결과에 적응할 수 있는 탄력적 사고방식을 개발해야 한다"라고 조언했다. 

모니터링과 관찰가능성 사이의 간극 

문제가 개발 프로젝트 큰 영향을 미치기 전에 신속하게 포착하기 위해서는 데브옵스 시스템에서 앞서 언급한 '움직이는 부분'에 대한 지속적인 관리 감독이 필요하다.  

스피틀은 "데브옵스에서는 변경 사항이 프로덕션에 배포되는 빈도가 훨씬 더 높다. 따라서 문제를 선제적으로 탐지하기 위해서는 강력한 모니터링이 필수적이다. 그러나 시중에는 동적이고 분산된 애플리케이션에 맞지 않는 모니터링 툴이 많다"라고 말했다. 

스피틀은 애플리케이션과 인프라를 계측해서 세부적인 지표와 로그를 수집해야 한다면서, AIOps 플랫폼(IT 운영 분석 역량을 강화하는 ML 분석 기술)과 같은 솔루션은 데이터를 상호 연계해서 문제의 근본 원인을 신속하게 파악하는 데 도움이 될 수 있다며 "목표는 스택 전반을 포괄하는 통합된 관찰가능성"이라고 덧붙였다. 

저품질 결과물 

데브옵스는 소프트웨어 개발 프로세스를 확실히 개선해 준다. 그러나 최종 제품이 품질 요건을 충족한다는 보장은 없다. 특히 사용자가 자신이 구매하는 제품에 대해 높은 안목을 갖춘 지금 시대에는 더욱 그렇다. 

클리블랜드 연방 준비은행의 수석 소프트웨어 개발자인 댄 섀퍼는 "중앙화된 데브옵스 팀 내에 만연한 문제점은 기능은 하지만 최적화와 재사용성 측면에서 최적의 표준에 못 미치는 결과물"이라고 설명했다.

섀퍼는 "이 문제의 근본 원인은 문제 해결에 대한 접근 방식에 있는 경우가 많다. 장기적인 영향이나 재사용 가능성에 대한 고려 없이 눈앞의 문제를 해결하기 위한 솔루션이 만들어진다. 이 같은 관행은 유지관리와 확장이 어려운 코드베이스로 이어진다"라고 지적했다. 

섀퍼는 이는 데브옵스 관행의 효율성과 민첩성에 영향을 미칠 뿐만 아니라 소프트웨어 개발 라이프사이클의 전체적인 품질과 지속가능성도 저하시킨다면서 "명료성, 구성 가능성, 재사용성을 위해 코드형 인프라와 파이프라인 코드를 리팩터링할 수밖에 없는 경우가 많다"라고 말했다. 

통제 불능 비용 

클라우드, 온프레미스 또는 하이브리드 시스템을 포함하면서 갈수록 복잡성과 다양성이 증가하는 데브옵스 환경은 비용 초과로 이어져 결과적으로 데브옵스를 통해 얻는 이점이 일부 무효화될 수 있다. 

IT 컨설팅 및 소프트웨어 개발 서비스 제공업체인 사이언스 소프트(Science Soft)의 IT 디렉터 앤디 립니츠키는 "데브옵스 관행을 통합하는 경우 재무적 과제가 따를 수 있으며 특히 비용이 빠르게 증가할 수 있는 클라우드 환경에서 이 같은 문제가 두드러지게 나타난다"라고 강조했다. 

립니츠키는 "우리는 엄격한 모니터링과 예산 관리를 통해 비용을 통제한다. 또한 수요에 따라 동적으로 리소스를 조정하고 클라우드 리소스 크기를 적절히 맞추고 적절한 스토리지 유형을 선택하는 등의 솔루션을 활용해서 성능 또는 확장성을 희생하지 않으면서 운영 비용을 최적화한다"라고 설명했다. 

계속 커지는 백로그 

섀퍼는 또 다른 큰 과제는 방대한 백로그 관리라고 말했다. 이 문제는 중앙화된 데브옵스팀이 여러 이해관계자의 요청을 수용해야 하는 데서 비롯된다. 여기에는 다양한 개발팀, 경영진, 제품팀이 포함된다. 섀퍼는 "이로 인해 전략적 비즈니스 목표와 가장 밀접하게 관련된 요청이 아니라 가장 목소리가 큰 사람의 요청이 먼저 처리되는 우선순위의 꼬임이 발생할 수 있다"라고 지적했다.

섀퍼에 따르면, 이런 시나리오는 부적절한 우선순위화, 프로젝트 지연, 그리고 자신의 프로젝트가 경시된다고 느끼는 팀원들의 전반적인 불만으로 이어질 수 있다.

인적 영향 간과 

많은 기업에서 소프트웨어 개발 및 제공 프로세스에 자동화를 도입하는 것이 데브옵스의 큰 부분을 차지한다. 그러나 무라베브는 여기서 시스템 상호작용의 인적 요소에 대한 이해와 대응 측면의 어려움이 발생할 수 있다고 진단했다.

무라베브는 "각 코드 라인과 배포 파이프라인, 자동화된 프로세스는 서로 다른 방식으로 사람과 접촉하면서 이들의 작업 루틴과 직업 안정성, 사기에 영향을 미친다"라고 말했다. 

이어 이 문제에 대처하기 위해 기업은 "자동화 공감 능력", 즉 자동화가 인간에 미치는 영향에 대한 심층적인 이해를 육성해야 한다면서 "여기에는 모든 수준에서 이해관계자와의 소통, 자동화에 대한 정서적 반응을 측정하는 피드백 루프 도입, 인간 대체가 아닌 인간 가치 강화를 위한 자동화 전략의 조정이 포함된다"라고 언급했다. 

경영진의 뒤처짐 

전자 테스트 및 측정 장비와 소프트웨어를 제공하는 키사이트 테크놀로지(Keysight Technologies)의 CIO 댄 크란츠는 "경영진은 내년의 세부적인 프로젝트 계획을 수립하는 데 반년을 소비하고, 폭포수 프로젝트팀은 작년의 약속을 실행에 옮기느라 시간을 소비한다"라고 설명했다. 

크란츠는 "이 방법론에서는 상황에 따른 주 또는 월 단위의 민첩한 방향 전환이 안 된다. 퓨전 프로젝트팀으로 전환하려면 경영진이 자신들에게 익숙한, 연간 프로젝트 포트폴리오를 규정해서 각 디지털 제품의 주요 비즈니스 성과를 정의해온 관행을 버려야 한다"라고 지적했다. 

크란츠에 따르면, 이 말은 각 팀에 대한 KPI 목표를 설정하고 KPI 달성을 정기적으로 검토하고 필요에 따라 개발자 업무량을 조정해야 함을 의미한다. 크란츠는 "데브옵스팀은 경영진이 지속적으로 검토하고 조정하는 정해진 목표를 달성하기 위해 스프린트를 자체적으로 조직해야 한다"라고 강조했다.
editor@itworld.co.kr