F5 DevOps 및 NetOps 설문조사 보고서: 자동화가 디지털 격차 해소의 핵심
DevOps와 NetOps 간의 전형적인 관계는 자주 화제가 됩니다. 우리는 양측을 서로 대립시키고, 이들을 가르는 장벽 너머로 애플리케이션과 비난을 주고받게 하는 수많은 ‘우리 대 그들’ 식의 주장에 끊임없이 시달리고 있습니다. 앱을 더 빠르고 더 자주 제공해야 한다는 압박이 커지면서, 이 장벽은 앱 경제의 승자와 나머지를 가르는 디지털 격차가 될 수 있습니다.
다행히도 IT 자동화와 오케스트레이션 덕분에 이러한 디지털 격차는 줄어들고 있습니다. NetOps와 DevOps 각 그룹을 대상으로 기술 활용 방식, 서로에 대한 인식, 제공하는 애플리케이션을 심층적으로 조사한 결과, 양측 모두 이 디지털 격차를 해소하기 위해 협력하고자 한다는 사실을 확인했습니다. 이는 자동화와 오케스트레이션을 통해서만 효과적으로 달성할 수 있는 규모와 속도가 필요한 디지털 혁신을 추진하는 기업에 갈수록 더 반가운 소식입니다. 이미 업무 부담이 큰 직원들의 더 많은 관심이 필요한 멀티 클라우드 환경으로 어려움을 겪는 조직에도 좋은 소식입니다. 자동화를 통해 온프레미스 업무 부담을 줄이면 클라우드 관련 프로젝트에 투입할 리소스를 확보할 수 있습니다.
2017년 여름에 실시된 온라인 설문조사에 NetOps 및 DevOps 전문가 884명이 참여했습니다. 일반적인 애플리케이션과 NetOps 또는 DevOps의 상대 팀에 대한 인식 관련 질문을 여러 가지 제시했으며, 배포 빈도와 성공률에 대한 인식을 묻는 질문도 포함했습니다.
결과에 따르면 두 집단 사이의 장벽은 여전히 존재하지만, 각 커뮤니티 내부의 논의나 다른 업계 보고서에서 주장하는 것만큼 높거나 불투명하지는 않습니다. 규모와 업종을 막론하고 여러 조직에서 프로덕션 파이프라인 자동화의 중요성과 필요성에 대해 상당한 공감대가 형성되어 있었으며, 두 집단이 개발하고 배포하고자 하는 애플리케이션의 보안, 성능 및 안정성에 대해서도 공통된 신뢰를 보였습니다.
자동화는 NetOps와 DevOps를 하나로 묶어 주는 힘으로 보입니다. 구체적인 구현 세부 사항까지는 아니더라도, 적어도 원칙적으로는 그렇습니다.
DevOps와 NetOps는 셀프서비스와 자동화를 통해 파이프라인에 어느 정도까지 액세스할 수 있도록 해야 하는지를 두고 여전히 의견이 엇갈리지만, 대체로 양측 모두 상대방이 올바른 방향으로 나아가고 있다고 봅니다. DevOps의 82%와 NetOps의 76%는 상대방이 ‘올바른 사안’을 우선시한다는 데 동의합니다. 조직도상으로는 항상 그렇지 않더라도, 적어도 목표와 중점 사항에 있어서는 디지털 격차를 넘어 분명한 공통점이 있습니다.
NetOps 측의 반대 의견을 가진 응답자들은 DevOps가 충분히 우선시하지 않는 요소로 보안을 가장 많이 꼽았습니다. 또한 안정성 역시 NetOps 담당자들이 DevOps에 대해 느끼는 불만의 원인으로 자주 언급되었습니다.
예상대로, NetOps의 우선순위 설정과 관련해 DevOps 측에서 자주 제기한 불만 중 하나는 자동화에 관한 것이었습니다. 정확히 말하면 자동화의 부재였습니다.
이러한 견해 차이는 다음 주요 조사 결과의 근본 원인일 가능성이 높습니다. 이 조사 결과는 개발자와 DevOps가 자동화 및 셀프서비스를 통해 프로덕션 파이프라인에 접근하지 못하는 것이 클라우드와 IT 외부 솔루션의 도입에 미치는 영향을 보여주었습니다.
자동화가 클라우드 도입에 미치는 영향
이제 그들도 여러분의 목소리를 듣고 있습니다. 비즈니스 및 DevOps 이해관계자 모두가 클라우드를 도입하는 주요 요인 중 하나는 프로덕션 배포 파이프라인에 대한 셀프서비스 접근이 부족해 배포 주기가 길어진다는 점이라고 오랫동안 여겨져 왔습니다. 그다지 반갑지 않은 소식은 이번 설문조사가 이러한 인식을 뒷받침한다는 것입니다. DevOps 응답자의 27%는 이 문제가 클라우드 기반 솔루션을 선택하는 데 “큰” 영향을 미친다고 답했고, 38%는 “어느 정도” 영향을 미친다고 답했습니다. 좋은 소식은 NetOps도 이러한 영향을 잘 알고 있다는 것입니다. NetOps 응답자의 65% 이상은 프로덕션 파이프라인을 자동화하고 셀프서비스 접근을 제공하려는 의지가 DevOps의 클라우드 도입 결정에 “어느 정도” 또는 “큰” 영향을 받는다고 답했습니다.
주요 결과
- 자동화에 대한 확고한 지지. 딜리버리 및 배포 파이프라인 자동화의 중요성에 대해 확고한 공감대가 형성되어 있으며, 5점 척도 기준 중요도 평균 평점은 DevOps가 4.0점, NetOps가 3.5점이었습니다. 전반적으로 응답자들은 프로덕션 파이프라인의 자동화율이 50%를 넘을 때 애플리케이션의 안정성, 성능 및 보안에 대해서도 더 큰 신뢰를 보였습니다. 또한 두 그룹 모두 상대 그룹이 “올바른 사안에 우선순위를 두고 있다”는 데 압도적으로 동의했습니다.
- 자동화는 클라우드 도입에 영향을 미치며, 그 반대도 마찬가지입니다. 이러한 공감대에도 불구하고 두 그룹 간에는 분명한 견해 차이가 있으며, 이는 실제 결과로 이어집니다. 그중 하나는 프로덕션 파이프라인 액세스에 대한 상반된 견해로, 이는 멀티클라우드의 확산에 기여하는 요인으로 보입니다. DevOps 측에서는 응답자의 65%가 프로덕션 파이프라인에 액세스할 수 없다는 점이 클라우드 및 외부 솔루션을 모색하기로 한 결정에 영향을 미쳤다고 답했습니다. 반대로 NetOps의 절반에 가까운 응답자(44%)는 DevOps가 클라우드로 전환하기로 한 결정이 해당 파이프라인 액세스를 제공하려는 의향에 “어느 정도” 영향을 미친다고 답했으며, 또 다른 21%는 “매우 큰” 영향을 미친다고 인정했습니다.
- 파이프라인 액세스를 둘러싼 의견 불일치. 내부 효율성과 외부 참여를 개선하기 위한 애플리케이션 제공에 초점을 맞춘 디지털 혁신 활동은 개발과 운영 환경 사이의 간극을 넘어야 합니다. 하지만 두 영역 사이의 장벽은 여전히 존재하며, 개발자와 DevOps에 운영 파이프라인 액세스를 어느 정도까지 허용해야 하는지를 두고 의견이 엇갈리고 있습니다. DevOps 응답자 중 가장 많은 비율은 운영 파이프라인의 75% 이상을 셀프서비스와 자동화를 통해 이용할 수 있어야 한다고 생각합니다. NetOps는 이보다 다소 보수적이지만, 일반적인 인식만큼 두 집단의 견해 차이가 크지는 않습니다.
- 현재 배포 빈도는 적절합니다. DevOps와 NetOps 모두 현재의 배포 빈도가 "충분히 적절하다"는 데 압도적으로 동의했습니다. 두 그룹 간에 괴리가 있다는 일반적인 인식과 마찬가지로, NetOps가 배포 빈도를 “지나치게 잦다”고 판단할 가능성은 DevOps보다 두 배 높았습니다. DevOps 측에서는 소수(4%)만이 “지나치게 잦은” 릴리스가 있을 수 있다고 답했습니다.
자동화에 대한 확고한 지지
책임 공방은 끝났습니다. 사고 발생 후 NetOps와 DevOps가 끝없이 서로에게 책임을 떠넘긴다는 통념과 달리, 조사 결과 두 그룹 모두 상대방을 훨씬 더 긍정적으로 바라보는 것으로 나타났습니다.
파이프라인에 접근하지 못해 불만을 느낀 이들이 클라우드로 눈을 돌리면서 멀티 클라우드가 확산되고 있으며, 그에 따른 보안 및 성능 문제도 크게 늘고 있습니다. 이는 그 결과로 생겨난 ‘섀도 IT’로 어려움을 겪는 이들이 자주 지적하는 문제이기도 합니다. NetOps가 프라이빗 클라우드 또는 클라우드와 유사한 시스템에서 자동화와 셀프서비스를 통해 접근성을 제공하려는 노력을 계속하고 있지만, 이미 상당한 투자가 이루어진 외부 클라우드 솔루션을 외면하기는 어렵습니다. 이에 따라 조직은 여러 클라우드 솔루션과 환경을 관리하고 모니터링하며 보호해야 하므로, 디지털 경제에서의 운영 복잡성이 더욱 커지고 있습니다.
이제 중요한 질문은 “프로덕션 파이프라인에 대한 셀프서비스 액세스를 제공할 것인가?”가 아니라 “어디까지 공개할 것인가?”입니다.
파이프라인 접근을 둘러싼 의견 충돌
어느 정도면 충분할까요? 자동화/셀프서비스 기능을 통해 개발자와 DevOps에 어느 정도의 파이프라인 접근 권한을 부여하는 것이 적절한지를 두고 의견이 크게 엇갈렸습니다. DevOps는 NetOps가 허용해도 괜찮다고 생각하는 수준보다 더 폭넓은 프로덕션 파이프라인 접근 권한을 원하고 있습니다.
NetOps가 DevOps에 더 폭넓은 파이프라인 액세스 권한을 제공하기를 꺼리는 이유를 묻지는 않았지만, 그 답은 이를 가능하게 하는 역량의 보유 여부에서 찾을 수 있을지도 모릅니다. NetOps 응답자들은 대체로 업무 수행에 필요한 역량과 현재 보유한 교육 수준 및 지식 사이에 격차가 있다고 생각합니다.
실제로 스스로를 ‘개발자’라고 인식하는 NetOps와 DevOps 모두, 현재와 비슷한 책임과 기술 역량이 유지된다는 전제하에 5년 후에도 자신의 직무가 여전히 유효할 것이라고 믿는 경향이 더 강했습니다. 반면 양측 모두에서 자신을 네트워크 운영자라고 인식하는 이들의 확신이 가장 낮았습니다.
NetOps 측의 현재 프로덕션 파이프라인 자동화 수준은 이러한 기술 격차의 영향을 반영하는 것으로 보입니다. DevOps의 딜리버리 파이프라인에 비해 크게 뒤처져 있다는 사실은 놀랍지 않았습니다. NetOps의 11%가 프로덕션 파이프라인을 전혀 자동화하지 않았다고 답한 반면, 애플리케이션 딜리버리 파이프라인에 대해 같은 답변을 한 DevOps는 5%에 불과했습니다.
파이프라인 자동화와 성공적인 배포 빈도 사이에 양의 상관관계가 있다는 조사 결과를 고려할 때, 파이프라인 자동화 현황에 주목할 필요가 있습니다. 파이프라인 자동화 비율이 높은(75% 이상) NetOps의 86%는 매우 성공적인 배포(성공률 90% 이상)의 빈도도 더 높다고 응답했습니다.
하지만 이것만이 유일한 요인은 아닙니다. 애플리케이션 변경 빈도 역시 성공적인 배포 빈도에 영향을 미치는 것으로 보입니다.
현재 배포 빈도는 적절함
저희는 지금도 충분합니다. 아마도 가장 큰 문화적 차이는 여전히 배포 빈도에서 나타납니다. 일부 DevOps 팀은 매우 빠른 속도로 앱을 프로덕션 환경에 배포하지만(12%는 하루에 두 번 이상 변경 사항을 프로덕션 환경에 배포), NetOps는 더 느리지만 꾸준한 속도로 변경 사항을 배포하는 방식을 훨씬 더 편하게 여기는 것으로 보입니다.
전반적으로 다수의 응답자가 월간 및 주간 배포 주기에 어느 정도 의견을 같이하는 것으로 보입니다. 예상대로 DevOps는 NetOps보다 더 자주 배포하는 것을 선호합니다. 구체적으로, 더 자주 배포하기를 원하는 DevOps 응답자 26% 중 28%는 일주일에 한 번 배포하고 있으며, 26%는 이미 하루에 두 번 이상 배포하고 있습니다.
변경 사항이 전달되는 속도가 적절한지에 대한 인식은 그룹마다 다릅니다. 하지만 두 그룹 모두 대다수(DevOps의 70%, NetOps의 74%)가 변경 빈도를 “우리에게 충분히 적절하다”고 평가했다는 점은 주목할 만합니다.
공통점은 여기까지입니다. 현재 일정이 “너무 잦다”고 답한 DevOps는 4%에 불과했지만, 변경 사항의 배포 빈도가 “너무 잦다”고 답한 NetOps의 비율은 그 두 배였습니다. DevOps의 4명 중 1명 이상(26%)은 속도를 더 높이길 원하는 반면, NetOps에서 속도를 높이길 원하는 비율은 5명 중 1명 미만(18%)이었습니다.
하지만 희망 사항은 배제하고 결과를 살펴보면 속도와 성공률 사이의 균형을 맞추는 데 ‘이상적’일 수 있는 배포 빈도가 드러납니다. 배포 성공률이 90%를 넘는 NetOps의 65%와 DevOps의 57%는 변경 사항을 ‘주 1회’ 프로덕션 환경에 배포합니다.
결론
애플리케이션이 제공 단계에서 배포 단계로 넘어가기 위해 극복해야 하는 디지털 격차는 여전히 존재합니다. 배포 파이프라인의 상당 부분이 여전히 수동으로 운영되고 있어, 애플리케이션의 클라우드 전환은 계속될 것입니다. 이에 따라 DevOps가 클라우드 전환을 결정하면 NetOps는 그 여정을 가속하는 데 필요한 셀프서비스 접근 기능을 더 많이 제공하게 될 것입니다.
자동화는 NetOps와 DevOps가 더 힘들게 일하는 대신 더 스마트하게 협업하고, 비즈니스 요구에 맞춰 운영을 확장할 수 있도록 지원하므로 이러한 디지털 격차를 해소하는 핵심 요소입니다.
방법론
이 보고서의 데이터는 2017년 7월에 별도로 실시된 두 건의 온라인 설문조사를 통해 수집되었습니다. 두 설문조사는 개발부터 배포까지의 애플리케이션 수명 주기에서 자동화가 어떻게 활용되는지와 관련된 두 주요 집단의 인식을 조사하기 위해 설계되었습니다. 두 집단의 응답자에게는 참여에 대한 보상이 제공되었습니다.
부록: 설문조사 발췌문
아래에는 NetOps 및 DevOps 응답자들이 설문조사 질문에 답한 내용 중 일부를 추가로 선별해 수록했습니다. 전체 응답을 망라한 목록은 아니며, 접수된 피드백의 유형을 보여주는 예시로 제시합니다. 제품명은 정확성을 위해 수정했지만, 그 외의 의견은 접수된 그대로 편집 없이 게시하는 것을 원칙으로 했습니다.
NetOps
"개발팀이 업무의 우선순위를 적절하게 정하고 있습니까?"라는 질문에 “아니요”라고 답하셨다면, 어떤 업무의 우선순위를 다르게 정했으면 하십니까?
- 안정성, 품질, 비전입니다. 너무 자주 사람들이 일정에 맞추려고 서두르다 보니 품질이 가장 큰 희생양이 됩니다. 또한 현재 작업 너머를 내다보지 않으면 결국 대대적인 재작업과 최선에 못 미치는 해결책으로 이어집니다(조잡하게 짜깁기한 결과물이 작동할 수는 있지만, 어떤 면에서도 최적이거나 이상적이지는 않습니다).
- 개발팀과 시스템 관리자팀 간의 협업을 강화해야 합니다. 수동 관리 방식에서 벗어나는 속도가 충분히 빠르지 않습니다.
- 개발팀이 운영 안정성, 아키텍처의 일관성, 그리고 서로 다른 개발팀 간의 협업에 더 많은 관심을 기울였으면 합니다.
- 앱 개발자는 네트워크나 보안을 고려하지 않고, 보안팀은 개발 상황을 피상적으로만 파악하며, 네트워크팀은 개발이 완료된 후에야 운영상의 변경 사항을 알게 됩니다.
이상적인 환경이라면 개발팀과 운영팀 간의 상호작용, 소통, 협업 등을 어떻게 개선하시겠습니까?
- 양측 모두 성능 현황을 파악할 수 있도록 메트릭, 모니터링 및 가시성을 개선합니다. 서비스 제공 속도를 높이기 위해 파이프라인을 자동화합니다. 제공 시간이 길어지지 않도록 충분한 용량을 확보합니다.
- 그들을 더 똑똑한 사람들로 교체하세요
- 서로를 걸림돌로 여기지 말고, 모든 팀이 가장 큰 가치를 더할 수 있는 분야에 기여하도록 하세요. 자동화는 훌륭하지만 어느 정도의 감독이 없으면 작동은 하더라도 더 나은 최적의 방식으로 구현할 수 있었던 솔루션이 그대로 도입되는 경우가 많습니다.
- 개발팀과 운영팀 간의 경계를 더욱 허물어야 합니다. 가용 인프라에서 최소한의 오버헤드로 확장성과 우수한 성능을 확보할 수 있는 방식으로 애플리케이션을 제공한다는 공동의 목표를 가진 "하나의 팀"으로 간주해야 합니다.
- 넥타이를 맨 돌멩이나 다름없는 사람과 이야기하고 있다면 소통은 아무 의미가 없다.
- 개발 주기에서 F5 팀이 프로세스에 더 일찍 참여하도록 합니다.
- 개발 주기 초기에 운영팀 참여시키기
- 코드 공유 및 파이프라인 가시성 확보. 코드로 관리할 수 있는 도구가 많을수록 좋습니다(예: F5 BIG-IP은 코드로 적절히 관리하기 어려우며, 이는 현재 프로세스의 취약점입니다).
DevOps
"운영팀이 업무의 우선순위를 적절하게 정하고 있습니까?"라는 질문에 “아니요”라고 답하셨다면, 운영팀이 어떤 업무의 우선순위를 다르게 정했으면 하십니까?
- 운영팀이 클라우드 환경에서 자동화되고 특정 클라우드에 종속되지 않는 리소스 생성을 우선시했으면 합니다. 버튼 하나로 구축할 수 있는 인프라는 충분히 실현 가능하며 개발자, QA 및 운영팀에도 유용합니다.
- 자신이 다루는 모든 것을 자동화하는 방식에 적응하고 일자리를 잃을까 봐 두려워하지 말아야 합니다
- 수작업이 너무 많고 자동화가 이루어지지 않으며 핵심 기술 문제에 대한 이해가 부족합니다. 개발자에게 권한을 부여하세요.
- 이들은 문제를 해결하기 위해 돈을 쏟아붓는 경향이 있습니다. 더 많은 (고가의) 장비를 도입하고, 자동화하는 대신 단순 반복 작업을 수행할 인력을 더 충원합니다.
이상적인 환경이라면 개발팀과 운영팀 간의 상호작용, 의사소통, 협업 등을 어떻게 개선하시겠습니까?
- 운영 환경의 세부 사항을 추상화할 수 있도록 운영팀에서 더 많은 도구를 제공해 주었으면 합니다.
- 저는 개발자이며, 인프라를 배포하고 자동화해야 합니다. 운영팀은 자동화 방법과 관련 도구를 익혀야 합니다.
- 운영팀을 인프라 관리를 자동화하는 인프라 지원 조직에 가깝게 개편합니다. 그러면 개발자는 업그레이드, 서버 관리 등을 운영팀에 의존하는 대신 인프라를 서비스처럼 이용할 수 있습니다. 또한 애플리케이션을 더 쉽게 관리할 수 있도록 지원하기 위해 운영팀 구성원을 연락 담당자로 다른 그룹에 배치하겠습니다.
- 운영팀을 확대하고 개발 및 테스트에 직접 참여시켜야 합니다. 요청을 처리하는 창구라기보다는 현장에서 함께하는 통합 파트너가 되어야 합니다.