xOps의 부상 - 오늘날 기술 운영의 총체적인 책임성

개발(Dev)과 운영(Ops)을 결합한 데브옵스의 개념은 2000년대 초에 그 뿌리를 두고 있습니다. 하지만 '데브옵스'라는 용어는 2009년 애자일 2008 컨퍼런스에서 패트릭 드보이스와 앤드류 클레이 셰이퍼가 처음 사용했습니다. 그 이후로 많은 추종자를 끌어모으며 IT 업계에서 거의 종교와도 같은 존재가 되었습니다. 많은 기업이 배포 주기와 전반적인 효율성을 개선하기 위해 데브옵스 관행과 도구를 채택하면서 데브옵스는 현대 소프트웨어 개발 및 IT 운영의 필수적인 부분이 되었습니다. 또한 보안 및 네트워킹과 같은 IT의 다른 영역에서도 동일한 개념을 따르기 시작했고 SecOps, DevSecOps, NetOps 등이 탄생했습니다.

외부에서 IT를 바라보면서 저는 이러한 DevOps가 기능 간/부서 간 통합을 더 빠르게 촉진하는 대신 사일로를 만들고 서로를 가리키기 시작했다는 사실을 알게 되었습니다. 새로운 애플리케이션이 필요한 경우 티켓을 열면 DevOps 팀이 VM 또는 클러스터를 '스핀'하지만, 그 다음에는 NetOps 및 DevSecOps 팀으로 넘어가서 각자의 작업을 수행하거나 DevOps가 잘못한 부분에 대해 불만을 제기해야 하는 등의 문제가 발생하게 됩니다. 결과적으로 이 방법론으로 의도한 민첩성과 속도의 열반은 이러한 사일로에 의해 무너지고 있었습니다. '자동화된' 프로세스는 실제로 매우 수동적이고 운영자에 따라 달라지는 경우가 많았기 때문에 모든 팀원이 프로세스에 뛰어들어 인수할 수 있는 것은 아니었습니다.

저는 고객 중 한 곳인 대형 자동차 제조업체의 연구 부서에서 도움을 요청하기 전까지는 이런 불가피한 상황이 계속될 것이라고 생각했습니다. 그 사람의 서명에 "소프트웨어 애플리케이션 개발자"라고 적혀 있었고, 네트워크 설정에 대한 도움을 요청하고 있다는 사실에 놀랐습니다. 며칠 동안 그 사람과 함께 일한 후 저는 새로운 유형의 IT 전문가가 있다는 것을 깨달았습니다. xOps. 이 새로운 유형의 전문가들은 고도로 자동화된 시스템(예: iPhone)을 가지고 태어난 세대의 일부이며, 전달해야 할 내용을 전달하기 위해 필요한 많은 기능을 수행하기 위해 정교한 도구를 사용할 줄 알고 기대합니다. 이들은 다른 분야에서 원하는 것을 이해하기에 충분한 정보를 가지고 있지만 실제로 CLI를 사용하지는 않습니다. 이들의 사고방식은 GSD(get s... done)를 통해 빠르게 처리하고 비핵심적인 기능에 신경 쓰지 않으려는 것입니다.

기술을 활용해 일하고 삶의 질을 향상시키되, 그 기술의 거대한 규모에 신경 쓰지 않는 것은 아름다운 일입니다. 우리 대부분은(아미쉬에게는 미안하지만) 모바일 사용자인데, 저는 제 디바이스와 기지국 또는 와이파이 핫스팟 간에 교환되는 8~10개의 서로 다른 프로토콜에 대해 궁금한 적이 한 번도 없었습니다. 디바이스가 알아서 해준다는 것을 알고 있는데 엔터프라이즈 및 데이터센터 네트워킹에서 왜 다를까요? 모든 라우팅 테이블을 설정해야 하는 이유는 무엇일까요? 오케스트레이션 플랫폼이 패브릭의 디바이스 수에 상관없이 몇 분 만에 모든 라우팅 테이블을 설정할 수 있습니다.

xOps에서 중요한 것은 결과, 결과를 얻기까지 걸린 속도, 그리고 그 결과의 신뢰성이며, 이 모든 것은 해당 작업의 구체적인 목표와 비교됩니다.