vimdiff를 고집하는 한 명을 제외하고 GitHub를 도입한 NetOps

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

그 밖에도 NetDevOps 2016년 가을 설문조사에서 얻은 인사이트를 소개합니다. 이 설문조사는 NetworkToCode 커뮤니티에서 실시했습니다.

NetworkToCode 커뮤니티에는 네트워킹과 코드에 열정적인 사람들이 가득합니다. 진부하게 들릴 수도 있지만, 이들은 네트워크 자동화가 주목받기 시작하고 경영진의 필수 과제가 되기 훨씬 전부터 이를 실천해 왔습니다.

2016년 가을, 커뮤니티는 네트워킹과 코드를 중심으로 다양한 질문을 담은 설문조사를 실시했습니다. 원시 결과(위 링크)는 공개되어 있습니다. 온라인 설문조사 도구의 특성상 데이터를 정규화하지 않으면 결과 데이터 세트를 분석하기 어려울 수 있으며, 정규화에는 상당한 작업이 필요합니다. 다행히도 독자 여러분을 위해 제가 그 작업을 마쳤으며, 이제 그 결과에서 얻은 인사이트를 더욱 시각적이고 다채로운 방식으로 소개해 드릴 수 있습니다.

예리한 독자라면 제가 일반적으로 네트워크에 ‘DevOps’ 원칙을 적용해야 한다고 오랫동안 주장해 왔다는 점을 알아차릴 것입니다. 따라서 이 데이터를 자세히 살펴보면서 당연히 이 부분에 많은 노력을 기울였습니다.

코드와 네트워킹에 중점을 둔 그룹에서 DevOps에 대한 인식이 대체로 긍정적이었다는 것은 놀라운 일이 아닙니다. DevOps에 “관심이 없다”고 답한 비율은 6.75%에 불과한 반면, 25.74%는 이미 프로덕션 환경에 도입했다고 답했습니다. 나머지 응답자 대부분은 평가 중이거나(28.27%), 적어도 도입을 고려하고 있었습니다(39.24%).

이 설문조사를 훌륭하게 진행한 이들은 코드형 인프라에 대한 NetOps의 관점을 비롯해 이 주제에 관해 상당히 세부적인 질문을 던졌습니다. 여기에는 다소 더 무관심한 반응이 나타나, 거의 10%가 “관심 없음”이라고 답했습니다. 흥미로운 점은 코드형 인프라가 “이미 프로덕션 환경에 적용되어 있다”고 답한 비율은 19.35%에 불과했지만, 응답자의 무려 54%가 구성 배포에 자동화를 사용한다고 밝혔고, 66%는 구성 보관을 자동화하고 있다는 것입니다. 구성 관리를 자동화하고 있는 NetOps 담당자는 정확히 한 명입니다(그리고 구성 변경을 관리하는 데 vimdiff를 쓴다고 자랑스럽게 밝힌 그 NetOps 담당자는 아니라고 확신합니다).

보통 가장 먼저 떠오르는 질문은 “도대체 코드형 인프라(Infrastructure as Code)란 무엇인가?”입니다. 아마도 많은 사람이 스스로는 주로 이를 “평가 중”이거나 “고민 중”이라고 여기면서도 실제로는 이미 “실행”하고 있는 이유가 바로 여기에 있을 것입니다. 여러분, 정의 피로감은 실제로 존재합니다. 요즘처럼 명확한 정의가 제시되지 않는 상황에서는 금세 사라지는 용어를 두고 결론을 내리기가 어렵습니다(물론 그래도 결론을 내리겠지만요. 그게 우리가 하는 일이잖아요, 그렇죠?).

그렇다면 NetOps는 무엇을 자동화하고 있을까요? 우리는 디지털 혁신이 지연 없이 순조롭게 진행되도록 하려면 자동화가 필요하다고 계속 강조합니다. 하지만 특히 엔터프라이즈 네트워크는 자동화를 가볍게 시험해 볼 수 있는 환경이 아니라는 점도 잘 알고 있습니다. 오늘날 비즈니스 전체가 의존하는 핵심 네트워크이기 때문입니다. 그런데 알고 보니 NetOps는 상당히 많은 부분을 자동화하고 있습니다.

구성 생성, 보관 및 배포는 현재 자동화가 가장 활발하게 이루어지는 세 가지 작업입니다. 데이터 수집과 보고도 점차 탄력을 받고 있는 것으로 보입니다.

실제로 구성 관리(그리고 이를 자동화한 한 곳의 과감한 NetOps 조직)를 제외하면, 상당수 응답자의 조직에서 모든 운영 작업이 자동화된 것으로 보입니다.

하지만 구성 관련 작업의 자동화는 당연히 이런 질문을 낳습니다. 해당 작업은 얼마나 자주 발생하며, 그렇다면 자동화할 만한 가치가 있을까요? 저는 (이 주제에 대한 현재의 통념과는 다를 수 있지만) 프로덕션에 변경 사항을 배포하는 빈도가 낮을수록 자동화의 가치가 더 커진다고 생각합니다. 물론 자전거 타는 법을 절대 ‘잊어버리지는’ 않지만, 몇 달 또는 몇 년 만에 다시 안장에 오르는 첫 경험은 말하자면 고통스럽고 실수투성이일 수 있습니다. 배포도 마찬가지입니다. 하지만 그건 다음에 다룰 주제입니다.

실제로 NetOps는 상당히 정기적으로 배포를 진행하고 있습니다. 거의 절반(50.92%)이 프로덕션 환경에 하루 한 번 이상 소규모 변경 사항을 배포하고 있으며, 37.59%는 한 달에 1~5회 대규모 변경 사항을 배포합니다. 웹 네이티브 기반으로 주로 단일 애플리케이션을 지원하는 기술 기업(Netflix, PayPal, Facebook 등)이 내세우는 놀라운 수준의 ‘하루 200회’에는 훨씬 못 미치지만, 자체 ‘애플리케이션 딜리버리 현황’ 설문조사에 따르면 평균 200개 이상의 애플리케이션을 지원하는 기업으로서는 여전히 상당히 빠른 속도로 애플리케이션을 배포하고 있습니다.

마지막으로, 이 모든 변경 사항을 어떻게 관리하는지 궁금하지 않을 수 없습니다. 제목에서 언급했듯이, 실제로 변경 사항을 관리하는 데 vimdiff만 사용한다고 당당히 밝힌 NetOps 담당자가 단 한 명 있었습니다. 데이터 구조상 이를 프로덕션 환경의 변경 빈도와 연관 짓기는 어렵지만, 외부의 압박에도 아랑곳하지 않고 자신에게 잘 맞는 방식을 당당히 고수하는 이분은 저의 영웅이기에 꼭 한번 이야기를 나눠 보고 싶습니다.

그렇다면 나머지 NetOps는 무엇에 의존할까요? 알고 보니 상당수가 Github를 사용하고 있습니다. 정확히는 47%입니다. 또 다른 큰 집단(39%)은 Rancid/Oxidized를 사용합니다. Rancid(1991년 캘리포니아주 버클리에서 결성된 미국 펑크 록 밴드와 혼동하지 마세요)는 구성 백업을 관리하는 네트워크 도구입니다. Oxidized 역시 구성 백업을 관리하는 네트워크 도구로, 흔히 RANCID를 대체할 도구로 소개됩니다. 더 자세히 알아보고 싶다면 이 도구들을 다루는 전용 서브레딧도 있습니다.

놀랍게도 8%는 구성 변경 사항을 전혀 추적하지 않고 있습니다. 저도 예전에 실험실에서 그렇게 했다가 한쪽 방향은 100Mbps, 반대쪽은 1.5Mbps인 끔찍한 비대칭 네트워크 간 링크를 만든 적이 있습니다. 그렇습니다. 거의 11년 전 그린베이의 한 실험실에서 실수로 현대식 케이블 광대역 모델을 재현한 셈입니다. 안타깝게도 로열티는 받지 못하지만, 다행히 항의 메일도 받지 않습니다. 다시 말하지만, 조직 규모와 교차 분석할 수 없다면 그 이유를 이해하기 어렵습니다. 흥미롭게도 11.91%는 0~50대의 네트워크 장치를 관리하고 있으므로, 앞서 언급한 8%는 관리 가능한 수의 장치를 맡고 있어 별문제 없이 운영하고 있다고 추측해 볼 수 있습니다. NetOps에서 가장 큰 비중을 차지하는 그룹(38.63%)은 1,000대가 넘는 장치를 관리하고 있으며, 또 다른 28.23%는 251~1,000대를 관리하고 있습니다. 따라서 대다수의 NetOps가 수많은 장치(거의 확실히 이기종 장치)를 담당하고 있다고 봐도 무방하며, 구성 변경 사항을 추적하는 일은 네트워크를 지속적으로 안정적인 상태로 유지하는 데뿐만 아니라 운영자의 정신 건강을 지키는 데도 필수적입니다.

전반적으로, 스스로를 NetDevOps라고 부르는 이들의 세계를 깊이 들여다보고, 비록 5만 피트 상공에서 뼈대만 훑어보는 수준이긴 했지만 그들이 무엇을 사용하고 무엇을 중요하게 여기며 어떤 환경에서 일하는지 살펴볼 수 있어 정말 흥미로웠습니다.

NetOps는 IT 조직의 중추이며, 기업이 네트워크와 이를 안전하게 운영하는 담당자들의 부담을 가중시킬 것으로 예상되는 디지털 혁신을 추진하는 동안 모든 시스템이 원활하게 작동하도록 유지하는 책임을 점점 더 많이 맡고 있습니다.

기존의 전통적인 모델에서 보다 민첩한 DevOps형 모델로 네트워크 운영을 전면 개편하는 것은 불가능하다고 생각합니다. 비즈니스의 디지털 전환과 마찬가지로 IT의 디지털 전환도 비즈니스 운영에 차질을 빚을 수 있는 기존 프로세스를 중단시키지 않도록 유의하면서 단계적으로 이루어집니다. 이 설문조사는 분명 변화가 진행되고 있음을 보여줍니다. 비록 이를 ‘DevOps’라고 부르지 않거나 그 개념에 대한 순수주의자들의 기준을 완전히 충족하지는 못할지라도, 엔터프라이즈 네트워크가 자체적인 디지털 전환 여정에서 확실히 앞으로 나아가고 있습니다.

작성자 소개

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

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

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