인터넷 회사에는 중요한 직종이 하나 있는데, 그것은 "운영"이라고 합니다.

"운영"의 영어는 Operations로, Ops로 줄여서 부르며, 직역하면 "작동"이라는 뜻으로, 여러 서버 작동을 의미합니다.

간단히 말해, 운영 엔지니어는 서버를 관리하고 코드 실행 환경을 보장하는 사람입니다.

이는 매우 중요한 일이며, 회사는 이를 매우 중요하게 생각해야 합니다. 하지만 실제로는 이几年来, 운영 직종이 계속 줄어들고 있으며, Ops 엔지니어는 DevOps 엔지니어로 전환을 요구받고 있습니다. 내가 알기로는, 많은 운영 엔지니어들이 실제로 고통받고 있습니다.

이런 변화를 어떻게 바라볼 수 있을까요? 운영은 미래가 있을까요? 앞으로 어떻게 발전할 것일까요?

최근에, 저는 외국인이 쓴 글을 읽었습니다. 제목이 바로 《운영의 미래는 플랫폼 엔지니어링》이라고 합니다.

"Ops의 미래는 플랫폼 엔지니어링이다."

작가는 위에 제기된 질문에 체계적으로 답하며, 운영은 결국 사라지고 새로운 직종으로 발전하게 될 것이라고 생각하며 "플랫폼 엔지니어링"(platform engineering)이라고 말한다.

저는 그의 글이 많은 영감을 주었고, 운영에 대한 이해를 훨씬 명확하게 해주어 많은 분들과 공유하고 싶다.

1. 운영의 유래

가장 처음에는 운영이 없었고, 프로그래머는 소프트웨어를 작성하고 실행하는 모든 작업을 동시에 담당했다.

하지만 소프트웨어를 작성하는 것과 소프트웨어를 실행하는 것은 사실 두 가지 다른 기술이다:前者는 코드에 익숙해야 하고, 후자는 서버에 익숙해야 한다.

인터넷 소프트웨어가 발전하면서 이 두 가지 기술은 점차 분리되었다.

개발 엔지니어는 코드를 작성하고, 운영 엔지니어는 코드를 실행한다(즉, 서버 실행 환경을 보장).

두 번째, 운영의 쇠퇴

증명되었습니다, 개발과 운영이 분리되었다는 것은 큰 실수입니다.

코드를 작성하는 사람이 서버 환경을 모르고, 서버를 관리하는 사람이 코드가 무엇을 하는지 모른다는 것은 우수한 제품을 만들고 문제를 진단하는 데 불리합니다.

따라서 일부 회사는 개발과 운영을 다시 합치도록 촉진합니다: 소프트웨어를 작성하는 사람도 소프트웨어를 실행하는 책임을 져야 합니다.

이것이 바로 DevOps의 기원입니다. 이는 Dev(개발) + Ops(운영)의 합입니다.

한편으로, 인터넷 회사의 핵심 자산과 경쟁력은 더 많이 코드에 있지 않고 운영에 있습니다. 따라서 회사는 더 많은 힘을 개발에 투자하고, 전문적인 운영 팀을 점진적으로 압축하며, 가능한 한 많은 인프라를 적극적으로 아웃소싱할 의향이 있습니다.

이 두 가지 요인은 운영이 독립적인 직종으로서 점차 사라지고 있음을 결정합니다.

3. DevOps의 문제점

그러나, DevOps는 실제로 운영을 대체할 방법이 없습니다.

점점 복잡해지는 비즈니스는 시스템과 인프라가 더욱 복잡해지고, 동시에 안정적이고 신뢰할 수 있어야 합니다.

평범한 개발 엔지니어는 이를 할 수 없습니다. 모든 인프라를 이해하지 못하고 전문적인 운영 수준의 시스템 관리를 달성할 수 없습니다.

이런 상황에서 회사는 외주를 선택하거나 외부 클라우드 서비스를 구매하며, 인프라를 전문적인 클라우드 서비스 제공업체에 외주하고, 자체 비용을 최대한 압축합니다.

4. 운영의 책임

전반적으로 운영은 서버를 관리하지만, 두 가지 책임으로 세분화할 수 있습니다: 기반 인프라 구축 + 실행 환경 관리.

"기본 인프라 구축"은 하드웨어 구매, 설치, 시설 배치, 네트워킹과 같은 작업을 의미합니다.

"운영 환경 관리"는 비즈니스 소프트웨어의 실행을 보장하는 것을 의미합니다.

DevOps가 등장한 후, "기본 인프라 구축"이라는 책임은 점차 사라지고 클라우드 서비스 구매로 변화되었으며, "운영 환경 관리"라는 책임은 DevOps 엔지니어에게 넘겨졌습니다.

그래서 새로운 문제가 나타났습니다: 누가 클라우드 서비스를 구매하고 통합할 책임을 가지는가?

5. 플랫폼 엔지니어링이란 무엇인가?

적절한 클라우드 서비스를 구매하는 것은 간단한 일이 아닙니다.

클라우드 서비스는 복잡하며 다양한 API, SDK 및 관련 도구들이 눈을 증오게 만들 정도로 많아서, 경험 많은 운영 엔지니어조차 명확하게 설명하기 어렵습니다.

따라서 필요한 전문 인력이 올바른 결정을 내리고, 요구사항을 충족하는 클라우드 서비스를 선택하며, 모든 구매한 클라우드 서비스를 통합하여 비즈니스 개발을 위해 사용할 수 있도록 도구를 작성하고 관리해야 합니다.

이런 역할을 플랫폼 엔지니어링이라고 합니다. 그는 다양한 클라우드 서비스를 평가하고 구매하며 통합하여 자신의 인프라로 사용하고, 외부 클라우드 서비스를 기반으로 자신의 플랫폼을 구축하여 개발 엔지니어가 이 위에서 자체적으로 서비스를 제공하고 코드를 생산에 투입할 수 있도록 합니다.

위의 정의에는 몇 가지 핵심 포인트가 있습니다.

(1) 인프라는 외부 위탁하여 비용과 개발 주기를 최소화하기 위해 사용됩니다.

(2) 플랫폼 엔지니어는 외부 위탁된 인프라를 통합하여 플랫폼을 구축합니다.

(3) 개발 엔지니어는 이 플랫폼 위에서 자체적으로 실행 환경을 구축하고 관리하며 코드를 실행합니다.

6. 플랫폼 엔지니어링과 운영의 차이

플랫폼 엔지니어링과 운영은 몇 가지 눈에 띄는 차이점이 있습니다.

（1）플랫폼 엔지니어링은 소프트웨어를 개발해야 하며, 테스트 작성과 코드 리뷰를 포함합니다. 팀의 작동 방식은 개발 팀과 매우 유사하며, 제품 매니저, 심지어 디자이너와 프론트엔드 엔지니어가 있습니다.

운영팀은 일반적으로 애플리케이션 소프트웨어를 개발하지 않으며, 최대한 자동화 스크립트를 작성할 뿐입니다.

과거에는 어떤 엔지니어가 코드를 작성하고, 어떤 엔지니어가 코드를 실행했습니다. 앞으로는 모든 엔지니어가 코드를 작성하고 자신의 코드를 실행하며, 개발 엔지니어, DevOps 엔지니어 또는 플랫폼 엔지니어가 어떤 경우든, 차이점은 계층이나 기능에 따라 분류된 책임 범위가 다를 뿐입니다.

（2）플랫폼 엔지니어링은 클라우드 네이티브이며, 모든 작업은 클라우드에 존재합니다.

운영은 클라우드 네이티브가 아니며, 하드웨어를 직접 관리해야 하므로, 클라우드를 지원할 뿐입니다.

（3）플랫폼 엔지니어링은 클라우드 서비스를 구매하지만, 운영은 하드웨어를 구매합니다.

7. 운영 엔지니어의 미래

전통적인 운영 역할이 사라지면서 현재의 운영 엔지니어들은 필연적으로 전환을 마주하게 되며, 세 가지 경로를 선택할 수 있습니다.

(1) 비즈니스 소프트웨어 개발을 좋아한다면 DevOps 엔지니어가 될 수 있습니다.

(2) 플랫폼 소프트웨어 개발을 좋아한다면 플랫폼 엔지니어링을 선택하여 인프라 통합에 집중할 수 있습니다.

(3) 하드웨어와 하드웨어에 더 관심이 있다면 "인프라即服务" (IaaS) 클라우드 회사에 합류하여 인프라에 대한 심층적인 연구를 할 수 있습니다.

(끝)