네트워크 자동화에서 규모는 중요하다(하지만 그리 중요하지는 않다)

F5 에코시스템 | 2018년 8월 06일

데이터가 이를 뒷받침합니다.

조직의 규모(그리고 그에 따른 수요)를 고려하면 상당한 노력이 필요한 네트워크 자동화를 도입할 필요가 없다고 주장하며 그 중요성을 쉽게 간과할 수도 있습니다.

아무리 그래도 조직에 사람이 100명뿐이라면 수요가 그렇게 많을 리는 없겠죠. 정말 그럴까요?

그렇습니다. 충분히 그럴 수 있습니다.

조직 규모별 자동화 SOAD18

클라우드와 그 파트너인 DevOps는 많은 것을 뒤흔들었지만, 기업을 분류할 때 사용하는 기존의 ‘조직 규모’ 구분에 대해서는 좀처럼 이야기하지 않습니다. 흔히 말하는 SMB, SME, 대기업 같은 구분입니다.

전통적으로 목표 시장은 오랫동안 직원 수를 기준으로 구분되어 왔습니다. 각국에는 거버넌스와 법률 적용을 위한 법적 정의가 있지만, 소프트웨어 공급업체가 시장을 세분화하는 데는 그다지 유의미하지 않습니다. 이러한 시장 세분화에 따라 공급업체가 여러분의 관심과 예산을 확보하려 적극적으로 나설지가 결정됩니다. 기본 전제는 사람이 많을수록 조직 구성원을 지원하는 데 더 많은 자원이 필요하다는 것입니다. 기술이 많아질수록 복잡성도 커지고, 복잡성이 커질수록 모든 것이 더 많이 필요해집니다.

소프트웨어 공급업체 업계에서는 데이터 센터의 규모와 프로세스의 복잡성이 매우 중요합니다. 편의상 이 두 요소는 일반적으로 조직의 규모(직원 수)와 연계됩니다.

하지만 클라우드와 DevOps는 조직 규모에 대해, 가상화가 데이터 센터 내 ‘서버’ 밀도에 일으킨 것과 같은 변화를 가져오고 있습니다. 가상 서버가 폭발적으로 늘어났던 때를 기억하시나요? 애플리케이션마다 물리 서버 한 대를 사용하던 모델에서, 물리 서버 한 대에 가상 서버 10대 또는 20대를 호스팅하며 애플리케이션마다 가상 서버 한 대를 사용하는 환경으로 전환되었습니다. 애플리케이션이 폭발적으로 증가하면서 ‘데이터 센터’의 서버 수는 100대에서 1,000대 이상으로 늘어났습니다. 하지만 데이터 센터의 실제 물리적 규모는 변하지 않았습니다. 많은 경우 운영자 수도 그대로였습니다.

엔지니어 인력 배치

실제로 다양한 인력 수준을 추적하는 Computer Economics에 따르면, 불과 1년 만에 엔지니어 1인당 담당 기기 수가 크게 증가했습니다. 2014년에는 엔지니어 한 명이 36대의 기기를 담당했습니다. 1년 후에는 어땠을까요? 같은 엔지니어가 59대의 기기를 관리해야 했습니다.

애플리케이션 인프라 영역에서도 이와 비슷한 증가세가 나타나고 있었습니다. 이는 부분적으로 가상화와 제한적인 수준의 유용한 자동화 덕분에 가능했습니다.

우리가 한 일은 물리적 서버와 효율성 물리적 서버와 이를 직접 운영하는 작업자 모두의 효율성을 높인 것이었습니다.

이제 오늘날로 돌아와 보겠습니다. 클라우드와 DevOps, 그리고 새롭게 합류한 NetOps는 가상화를 통해 서버에 적용했던 것과 같은 변화를 IT 조직 규모에도 가져올 것이며, 이미 그러한 변화가 시작되었습니다. 자동화를 클라우드(및 컨테이너)와 함께 활용함으로써 운영 효율성을 획기적으로 높이고 있습니다. 이는 인력을 크게 늘리지 않고도 현재보다 10배 또는 20배 많은 애플리케이션과 운영 업무를 지원할 수 있다는 의미입니다.

우리는 ‘소규모 기업’ 예산으로 ‘대기업’을 운영할 수 있습니다*.

직원 수만 보고 특정 제품이나 솔루션이 적합한지 판단하는 것은 거의 불가능합니다. 직원이 30명인 조직은 시장이나 법률상 거의 모든 정의에서 중소기업(SMB)에 해당하지만, 클라우드나 자체 데이터 센터에서 애플리케이션 인스턴스 수천 개를 운영하고 있을 수도 있기 때문입니다.

자동화는 퍼블릭 클라우드 덕분이든 DevOps 덕분이든 실제로 운영 효율성을 10배나 높여 주기 때문입니다.

네트워크 자동화에서는 규모가 (대체로) 중요하지 않습니다

따라서 네트워크 자동화에 대한 관점과 도입 동기, 도입 수준이 조직 규모에 따라 거의 차이가 없다는 점은 놀랍지 않습니다. 직원 수가 100명 미만인 조직 중 9%가 프로덕션 환경에서 자동화를 전면적으로 사용하고 있는 것으로 나타났습니다. 반대편에 있는 직원 수 5,000명 초과 조직에서도 8%가 동일하게 답했습니다. 주요 변경 사항을 프로덕션 환경에 배포할 때 자동화를 사용하는 방식과 관련해서는 직원 수가 100명 미만인 조직 중 23%가 항상 자동화를 사용한다고 답했습니다. 직원 수가 5,000명을 초과하는 조직에서는 이 수치가 25%로 소폭 상승하는 데 그쳤습니다. 그 중간 규모의 기업들도 21~23%로 큰 차이를 보이지 않았습니다.

조직 soad18의 도구 세트 크기

조직 규모에 따른 차이는 네트워크 및 운영 자동화에 사용되는 도구와 기술에서 나타났습니다. 그중에서도 가장 두드러진 점은 Python 스크립트 사용률에서 소규모 조직과 대규모 조직 간에 상당한 격차가 있었다는 것입니다. 대기업(직원 수 5,000명 이상)의 대다수는 이 기술을 도입한 것으로 보이는데, 이는 필요한 인재를 확보하기가 비교적 쉽고 다양한 운영 프로세스에 맞춘 맞춤형 자동화의 필요성이 더 크기 때문인 것으로 추정됩니다.

반면, 직원 수 100명 미만의 초소형 조직 중 Python 스크립트를 사용하는 곳은 3분의 1을 조금 넘는 36%에 불과했습니다. 또한 이러한 조직에서 ‘아무것도 사용하지 않음’을 선택한 비율은 33%로, 초대형 조직의 20%보다 훨씬 높았습니다.

네트워크 자동화 분야에서도 이러한 차이는 여전했습니다. 초대형 조직의 63%가 사용하는 Cisco는 초소형 조직에서는 35%만 사용하고 있었습니다. OpenStack 역시 그 격차를 좁혀 초소형 기업의 29%와 초대형 조직의 36%가 사용했으며, VMware도 마찬가지였습니다. 이 가상화 업계의 거대 기업 제품은 초소형 조직의 63%, 초대형 조직의 73%가 사용하고 있습니다.

네트워크 자동화에 ‘아무것도 사용하지 않는다’고 답한 조직 규모별 비율 차이는 자동화 도구 세트를 사용하지 않는 조직의 비율 차이보다 놀라울 정도로 작았습니다. 네트워크 자동화에 아무것도 사용하지 않는 비율은 초소형 조직의 경우 8%에 불과했으며, 초대형 기업은 단 5%였습니다.

이 모든 것이 흥미로운 이유는 결국 자동화에는 어떤 형태로든 소프트웨어가 필요하기 때문입니다. 맞춤형 소프트웨어(사용자 지정 Python 스크립트), 프레임워크(Chef, Puppet), 또는 엔진 기반 소프트웨어(Ansible, Cisco, OpenStack, VMware) 등이 이에 해당합니다. 자동화 도입으로 운영 효율성이 높아지는 상황에서, 소프트웨어 공급업체가 직원 수를 기준으로 조직을 분류해 온 기존 관행은 더 이상 큰 의미가 없습니다.

네트워크(그리고 IT 전반) 자동화를 촉진하는 가장 큰 요인 중 하나는 운영 규모입니다. 이는 더 많은 기술을 활용한다는 뜻이지 직원을 더 늘린다는 뜻이 아닙니다. 결국 이것이 바로 우리가 원하는 바입니다. 우리는 기술을 활용해 브룩스의 법칙에 어긋나는 상황을 피하고, 인력을 계속 늘릴 필요성을 줄여 일상적인 운영을 더욱 효율적으로 만들고자 합니다.

그렇다면 이제 조직의 규모를 기준으로 특정 기술과의 관련성을 피상적으로 판단해 온 방식을 재고할 때가 되었는지도 모릅니다. 마크 트웨인이 한 말로 유명하지만 실제로는 아닐 수도 있는 표현을 빌리자면, 중요한 것은 싸움에 나선 개의 크기가 아니라 그 개 안에 있는 투지의 크기이기 때문입니다.

자동화의 힘을 얻은 그 작은 개는 겉보기보다 훨씬 더 강한 투지를 지니고 있다.

공유
태그: 2018

작성자 소개

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

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

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

관련 블로그 게시물

성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5 에코시스템 | 2023. 07. 13.

성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A

F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.

TLS 검사에서 피터 파커 원칙 다루기
F5 에코시스템 | 2019. 12. 09.

TLS 검사에서 피터 파커 원칙 다루기

“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.

Venafi와 F5를 통한 머신 아이덴티티 보호
F5 에코시스템 | 2018. 12. 11.

Venafi와 F5를 통한 머신 아이덴티티 보호

‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.

마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
F5 에코시스템 | 2018. 07. 23.

마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다

물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...

내 클라우드에서 나가!
F5 에코시스템 | 2016. 10. 12.

내 클라우드에서 나가!

F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.

Shift(웹 앱) 보안 레터
F5 에코시스템 | 2015. 07. 06.

Shift(웹 앱) 보안 레터

웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.