요즘 DevOps를 정의하는 데 어려움을 겪고 있는 이유는 DevOps가 초기에 해결했던 문제가 오래 전에 사라졌기 때문입니다.

최근 일부 회사에서는 문제가 실제로 존재하지 않았습니다! 그들은 모든 일을 올바르게 수행하고 있지만 대신 소프트웨어 엔지니어링 환경이 너무 빠르게 발전하여 도구 및 클라우드 엔지니어링이 그 격차를 메웠습니다.

우리는 DevOps의 원래 시대와는 거리가 멀고 Dev와 Ops 사이의 사일로를 깨는 것을 목표로 하는 문화 변화가 있습니다.

개발 및 운영 사일로

2008년 당시, 패트릭 뒤부아 DevOps에 대해 처음 생각했을 때 그는 프로젝트 관리가 폭포수에서 Agile로 옮겨간 상황에서 개발과 운영 간의 비효율적인 협업을 살펴보고 있었습니다.

당시 운영팀은 네트워킹, 서버, 가상머신, OS, 소프트웨어 업데이트까지 모든 것을 관리했다. 이로 인해 많은 수동 작업이 효과적으로 숨겨졌습니다. 모든 것이 수동으로 이루어진 것은 아니지만 Puppet, Chef, Ansible 또는 심지어 Terraform이 존재하기 전이었습니다.

서버 및 소프트웨어 릴리스를 관리하는 것은 결코 간단하지 않았으며 많은 전문 지식이 필요했습니다. 새로운 소프트웨어 릴리스를 빠르고 안정적으로 제공하는 것을 방해하는 것입니다.

클라우드, 사일로가 사라지는 첫 번째 신호

2006년에 탄생한 AWS는 최초의 주요 클라우드 제공업체였습니다. DevOps는 2008년에 만들어졌으며 클라우드 관리 문제를 해결하기 위한 것이 아니라 온프레미스 인프라 운영 간의 실제 사일로를 해결하기 위한 것입니다. 이것이 DevOps가 무엇인지에 대한 혼란의 근원입니다. 소프트웨어 엔지니어링 환경에 두 가지 주요 변화가 거의 같은 시기에 시작되었습니다.

클라우드 컴퓨팅과 관련하여 우리는 SaaS(Software as a Service), PaaS(Platform as a Service), IaaS(Infrastructure as a Service)라는 세 가지 주요 모델을 사용합니다. 우리는 이러한 높은 수준의 구성을 사용했기 때문에 OPS(시스템 관리)가 거의 사라졌습니다. 이는 마치 DevOps의 아버지들이 확인한 원래의 문화 문제가 더 이상 존재하지 않는 것과 같습니다.

각 모델은 기본 인프라에 대해 서로 다른 제어, 유연성 및 관리 수준을 제공하며 온프레미스 인프라를 유지 관리하는 회사는 거의 없습니다.

따라서 DevOps 운동이 Dev와 Ops 간의 "사일로트" 문제를 해결 하려고 노력하는 동안 클라우드 인프라는 이미 Ops를 쓸모 없게 만들어 문제의 일부를 사라지게 했습니다.

운영 없음, 사일로 없음

DevOps의 주요 모토는 "왼쪽으로 이동"과 "빌드하고 실행"입니다. 이는 Ops 작업이었던 것을 Devs로 이전하는 것으로만 이어질 수 있습니다. 클라우드는 IaaS 모델을 제공하여 시스템 관리자(Ops)의 필요성을 줄여 개발자가 애플리케이션을 직접 관리하고 배포하는 노력을 줄였습니다.

더 좋게 들리도록 다시 표현해 보겠습니다! Ops는 소프트웨어 통합 및 배포를 단순화하는 도구를 제공하여 개발자에게 힘을 실어주었으며, 이를 통해 운영 팀이 인프라를 유지 관리하는 데 필요한 부담을 줄였습니다. 결과적으로 우리는 시스템 관리(Ops)가 필요하지 않은 상황에 이르렀습니다.

그러나 이러한 "소프트웨어 통합 및 배포를 단순화하는 도구"를 유지 관리할 사람이 필요합니다.

이 새롭게 떠오르는 역할은 이전 Ops가 "DevOps 담당자"로 이름을 바꾸었기 때문에 아직 이름이 없습니다. DevOps 엔지니어라고 부르겠습니다. 아마 누군가가 어느 시점에 그런 말을 했는데, 그게 멈췄을 거예요.

DevOps 자체를 재정의함

DevOps는 결코 도구에 관한 것이 아닙니다. 그것은 문화에 관한 것이 었습니다. 소프트웨어 엔지니어링도 더욱 "린(Lean)"해질 수 있고 적시에 소프트웨어 제공이 완료될 수 있다는 아이디어입니다. DevOps의 초기 문제는 오래 전에 사라졌을지 모르지만 소프트웨어 엔지니어링에서 가장 중요한 아이디어인 지속적인 전달이 탄생했습니다.

저는 DevOps가 역할이나 팀이 아니라고 주장하는 사람들을 오랫동안 지지해 왔는데, 그렇게 부르신다면 잘못된 일을 하고 있는 것입니다. 나중에 나는 상황이 더 복잡하다는 것을 깨달았습니다. 우리는 "소프트웨어 통합 및 배포를 단순화하는 도구를 유지 관리하는 사람"이라는 역할을 부적절하게 만들었지만 그에 대한 이름은 없었습니다.

생각해 보면 모든 것이 클라우드 서비스인 경우 "소프트웨어 통합 및 배포를 단순화하는 도구를 유지 관리하는 사람"이 정말로 필요합니까? 완전 관리형? 버튼을 클릭하면 작동합니까?

이는 대부분의 클라우드 제공업체와 많은 DevOps SaaS 제품(예를 들어 GitLab을 생각해 보세요)의 꿈입니다. 진실은 그렇게 간단하지 않습니다. 이론적으로는 모든 것이 간단할 수 있었고 Ops 작업은 자동화되고 서비스가 완벽하게 관리되는 등의 작업이 가능했습니다. 실제로 우리는 괴물을 만들었습니다.

결과적으로, 대부분의 운영/인프라 팀(즉, Ops)의 과제는 수많은 도구와 서비스의 지도를 탐색하고, 이러한 도구를 이해하고, 배포하고, 개발자가 사용할 수 있는 일관된 인프라와 도구에 연결하는 것입니다.

DevOps 정체는 DevSecOps, FinOps, GitOps, MlOps 등으로 쉽게 파생될 수 있는 핵심 전문 용어입니다.

하지만 눈치채면 남는 향은 언제나 옵스다. 재미있는 부분은 각 접근 방식이 방정식의 Ops를 제거하는 것을 목표로 한다는 것입니다. Ops는 "시스템에 로그인하여 시스템이 작동하도록 작업을 수행하는 사람"이라고도 합니다.

TL;DR

DevOps가 해결하려고 시작한 원래 문제는 클라우드 인프라의 증가로 인해 더 이상 존재하지 않을 수도 있습니다. 그러나 DevOps는 지속적인 제공이라는 중요한 아이디어를 탄생시켰고 소프트웨어 엔지니어링에 문화 변화를 가져왔습니다.

"DevOps"라는 용어는 전문 용어로 남아 있지만 DevSecOps, FinOps 및 GitOps와 같은 새로운 접근 방식의 개발로 이어졌으며 모두 기존 Ops 작업의 필요성을 제거하는 것을 목표로 합니다.

궁극적으로 DevOps 및 클라우드 인프라의 환경은 지속적으로 발전하므로 최신 상태를 유지하고 올바른 도구를 선택하는 것이 어렵습니다. 아이러니하게도 DevOps는 처음에는 Dev와 Ops 간의 협업을 의미했지만 방정식에서 Ops를 제외하는 방향으로 이동했습니다.