DevOps의 과거, 현재 미래에 대한 Q and A

Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

yundream
2023-11-23
2023-11-22
1494

### 소개
원문은 [Q&A: Patric Debois on the Past, Present and Future of DevOps](https://thenewstack.io/qa-patrick-debois-on-the-past-present-and-future-of-devops/) 입니다. DevOps 엔지니어로써 생각해볼 지점들이 많아서 번역을 했습니다. 다만 제 경험에 맞게 많은 부분들을 수정했습니다.

저(yundream)는 99년부터 기업에서 개발 경력을 시작했습니다. 새로운 것을 배우는 것에 관심이 많았던 성향으로 웹 애플리케이션 개발에서 시작해서, 시스템/네트워크 개발, 보안 솔류션 개발, 품질관리, 검색엔진 개발, 클라우드 엔지니어, DevOps 엔지니어 경력을 쌓았습니다. 개발자, QA, 시스템관리자 그리고 프로젝트 관리 업무도 수행했습니다. DevOps 업무는 2016년 부터 시작했습니다.
### 가능한 짧고 간결하게 DevOps를 정의한다면
DevOps는 사일로 간의 마찰을 제거하는 것입니다. 장벽을 제거한다고 할 수는 없습니다. 업무 성격의 차이에서 오는 장벽은 있습니다. 장벽을 부드럽게해서 마찰을 제거하는 것이죠. 모든 엔지니어링은 이를 위해서 수행하는 것입니다.

### 너무 광범위 합니다. 어떤 사일로를 제거해야 할까요.
처음에는 개발(dev) 과 운영(ops)의 협업 사일로를 제거하는데 중점을 뒀습니다. 당시에 개발자는 그들만의 세계에서 살았고, 운영자도 마찬가지였습니다. 더 많은 QA, 보안 등 더 많은 조직들이 생겼는데 이들 모두 그들만의 세계에서 살고 있었습니다.

"마찰을 제거한다는" 광범위하고 모호한 언어로 DevOps를 정의하는 것은, 실제 모든 조직들 사이에서는 마찰이 발생하고 이는 결국 제품의 출시를 늦추는 방향으로 작동하기 때문입니다. 예를 들어서 관리자와 개발자 사이의 일정과 품질에 대한 마찰이 있습니다. 운영자와 재무팀 사이에는 비용용 가시성과 관련된 이슈가 있습니다. 운영자와 개발팀 사이는 말 할 것도 없죠.

DevOps 활동으로 이러한 마찰을 제거 혹은 완화 할 수 있습니다.

에를 들어 일정과 품질에 대한 마찰은 CI/CD 파이프라인을 구축하는 것으로 많은 부분 개선 할 수 있다. 빌드/배포 과정에서 자동으로 버전을 관리하고 품질 테스트를 수행하고, 자동으로 배포하고 간단하게 롤백 할 수 있습니다. 이러한 시스템을 구축하려면, 개발 환경과 개발 관행도 달라져야 되겠죠. 이런 일련의 활동을 통해서 사일로를 제거하는 겁니다.

DevSecOps, DevBizOps가 만들어지는 이유입니다.

### 왜 마찰을 제거해야 할까요.
기업의 목표는 제품을 만드는 것입니다. 제품을 만들기 위해서 제품 파이프라인을 만듭니다. 이 제품 파이프라인은 본질적으로 컨테이너벨트입니다. 미완성된 제품이 컨테이너 벨트를 통해서 각 조직과 조직사이로 이동을하면서 완성된 제품으로 시장에 출시되는 겁니다. 마찰은 컨테이너의 흐름을 방해하고 벨트의 중단을 만들어냅니다. 코드의 가시성이 확보되지 않아서, 보안 요구사항을 지키지 않아서, 비용 충돌이 발생해서 여러 가지 문제로 중단이 될 수 있죠.

아래는 제품 배포까지의 파이프라인에서 발생하는 일을 단적으로 보여주고 있습니다.
![Pipeline](https://docs.google.com/drawings/d/e/2PACX-1vQKav6uVuTjDarqCObB3UwNw9BoR5mFfxTslMUw1DEUYGO65xwBFqfrYSZuR7J4ijNRqkfzRDfIhjf3/pub?w=1209&h=201)
대부분의 비용이 컨테이너 벨트의 다음단계로 넘어가는 시점에서 발생하는 것을 알 수 있습니다. 마찰을 제거해야 고객가치를 시장에 올바른 시간에 전달할 수 있습니다.

### 개발자는 DevOps에서 배제되는 느낌을 받습니다.
DevOps 가 시작될 때, 클라우드 전환도 함께 시작했습니다. 그러면서 인프라와 운영 분야에 더 큰 혁명이 일어났습니다. 개발 영역에서는 비즈니스 관점에서 제품을 개발 환경을 구축해야 하는 **애자일** 이 있었습니다. 애자일은 개발자의 영역이었죠.

인프라와 개발 둘 영역에서 모두 좌절과 도전이 있었고 각자의 방식으로 도전을 해결하기 위해 노력했습니다.

### 플랫폼 엔지니어링이 주목받고 있습니다. DevOps는 죽는 걸까요 ?
플랫폼 엔지니어링은 DevOps의 다른 표현입니다. 둘 중 하나가 아닙니다. 사실 오래되지도 새롭지도 않은 개념입니다. 대형 IT 기업의 경우에는 플랫폼 엔지니어링이라는 용어가 나오기 전에 이미 플랫폼 엔지니어링을 하고 있었습니다. 플랫폼 대시보드를 개발자에게 제공하면, 대시보드로 서비스를 전개하기 위한 플랫폼을 만들 수 있습니다. 여기에는 로깅, 보안, 모니터링 등이 함께 제공되고요.

지금은 클라우드를 기반으로 하는 DevOps 팀이 있습니다. DevOps 팀이 플랫폼팀이 될 수도 있고, 새로운 플랫폼팀이 조직될 수도 있습니다. 요즘에는 SRE와 플랫폼 팀으로 구성된 DevOps 조직을 볼 수 있습니다. 이와 달리 플랫폼과 DevOps 팀을 가진 SRE 조직이 구성되는 경우도 있죠.

### 최근 플랫폼엔지니어링이 개발 생산성과 관련된 주요 주제가 된 이유는 무엇일가요.
조직의 형태가 달라진 것 아닐까요 ?

예전에는 개발자로 이루어진 큰 그룹과 운영자로 이루어진 큰 그룹이 있었습니다. 그리고 그들만의 방식으로 팀을 조직하기 시작하고 이들 팀에 자율성을 부여했습니다. 하지만 분리된 팀에 자율성을 부여해서는 제대로 작동하지 않을 수 있다는 것을 깨달았습니다.

DevOps를 통해서 마찰을 제거하고 사일로가 무너지면서, 문제를 해결하기 위한 새로운 방법이 필요하다는 것을 인정하게 됐습니다.

클라우드로의 전환이 시작됐을 때 중요한 것은 **셀프 서비스**였습니다. 플랫폼 엔지니어링은 기술적인 인프라를 자동화하고 일원화함으로써 조직내의 높은 자율성을 제공하는데, 자율성이라는 것은 결국 사용자가 스스로 서비스를 설정하고 이용할 수 있을 때 달성이 됩니다. 개발 생산성과 관련된 주제인 것이지요.

### 별도의 플랫폼 팀과 DevOps 팀이 필요할까요 ?
앞서 잠깐 언급했습니다. 저는 그렇게 생각하지 않습니다. 플랫폼엔지니어링은 DevOps 팀을 다른 공간으로 리브랜딩하는 것과 같다고 말하고 싶습니다. 생각해보면 회사에는 어디든지 플랫폼이 있습니다. 데이터 플랫폼이 있고, 중간에는 애플리케이션 플랫폼이 있습니다. 이런 관점에서 보자면 플랫폼은 더 광범위한 개념으로 DevOps는 이 플랫폼의 구성요소라고 볼 수 있겠죠.

다만 요즘에는 확실히 **DevOps** 팀이라고 하면 인프라에 좀 더 가까운 엔지니어가 머무르는 영역이라는 관점이 있습니다.

플랫폼팀은 제품 개발을 위한 셀프 서비스를 만들게 됩니다. 그렇게 되면 미들웨어 계층을 구현할 사람, 프런트 엔드를 구성할 사람, 인프라를 구성해야 할 사람이 필요하게 되죠. 여기에 DevOps가 있을 것이고 플랫폼 팀의 일부가 될 수 있습니다.

DevOps가 발전하면서 좀 더 추상화가 이루어졌고, 플랫폼 팀이 좀 더 높은 추상화를 제공하므로 플랫폼 팀 소속이 될 수 있다는 의미입니다.

### DevSecOps에 대해서 어떻게 생각하시나요.
저는 보안전문가는 아닙니다. 하지만 인프라(클라우드 & 온-프레미스)에 대한 오랜 경험을 하면서 보안영역도 경험할 수 있었습니다.

Dev와 Ops가 능숙하게 협력하게 되면 **속도**가 높아지게 됩니다. 속도가 증가하면 불만을 가지는 그룹이 나타납니다. **보안이죠** 보안은 속도와는 상충되는 조직입니다. 모든 것이 확인 되고 심사 되어야 합니다. 그런데 갑자기 확인해야 할 더 많은 애플리케이션, 서비스, 라이브러리, 더 많은 릴리즈가 발생했습니다. 보안팀에서는 말도 안되는 상황인거죠.

이와 동시에 클라우드 환경에서 보안업무를 수행하는 방법을 배워야 했습니다. 결과적으로 보안업무가 사일로 전반에 걸쳐서 협업하는 DevSecOps 모델이 만들어졌습니다.

보안측면에서의 방향은 **left shift** 입니다. 프로젝트의 왼쪽 즉 시작 단계에서 보안 및 품질관리를 강화하는 접근 방식이고요. 소프트웨어 개발에서는 오류를 최소화하고 품질을 향상시키기 위해 개발 초기에 테스트 및 검증 활동의 수행이 정착되고 있는데, 보안에 대한 개념으로 사용하고 있습니다.

또 다른 움직임도 있습니다. 일부 기업에서는 left sift 만으로 충분하다고 생각하고 있습니다. 하지만 스타트업 처럼 클라우드 보안을 운영해 본 적이 없는 기업은 아직 보안 가시성을 확보하지 못한 상태이기 때문에 **가시성** 과 **left sift** 를 동시에 수행해야 하는 부담이 있습니다.

### 보안은 인기가 없습니다. 이 상태에서 DevSecOps 전략을 어떻게 적용할 수 있을까.
[Report on the 202 FOSS Contributer Survey](https://8112310.fs1.hubspotusercontent-na1.net/hubfs/8112310/2020FOSSContributorSurveyReport_121020.pdf) 에 따르면 개발자 중 3% 만이 보안 책임을 맡고 싶어하는 것으로 나타났습니다. 요즘 스타트업이 늘어나고 있는데 아무래도 초반에는 보안 제품 출시가 중요하기 때문인 것 같습니다.

플랫폼 엔지니어링팀은 left shift 전략을 따르면서 개발에서 배포까지의 파이프라인에 현재 제품의 보안 상태를 모니터링하고 보고하는 툴 셋을 시스템에 내장해야 합니다.

CI/CD 파이프라인은 보안을 내장하기 위한 좋은 출발점이 될 수 있습니다. 커밋되는 코드의 취약성, 도커 이미지 취약성, 정적 및 동적 분석 등 다양한 툴들이 자동으로 실행되게 할 수 있기 때문입니다.
 
이러한 툴 셋을 이용해서 플랫폼 팀은 보안에 대한 **가시성**을 확보 할 수 있습니다. 물론 "여기 이런 보안 취약점이 있습니다."라는 레포트를 발행한다고 해서, 그 문제가 즉시 해결되는 것은 아닙니다.

하지만 가시성을 확보하는 것은 그 자체로 의미가 있습니다. 개선은 측정에서 부터 시작되는 것이기 때문입니다. 개발팀에서 오류 예산을 세우는 것과 마찬가지로 보안 예산을 세우는 구체적인 활동을 할 수 있는 "근거"가 되기 때문입니다. 그리고 할 수 있는 것 부터 점진적으로 수행해 나가면 되는 거죠.

이것은 클라우드 보안에서도 일상적인 관행이기도 합니다. 예를 들어 AWS 클라우드 기반으로 보안활동도 가장 먼저 Trust Advisor 등으로 가시성을 확보하는 것 부터 진행한다. 그럼 수백가지의 보안권고 사항이 나오는데, 할 수 있는 것 부터 시작해서 점진적으로 개선해 나가는 겁니다.

Search For:

BY TAGS

Recent Posts

Archive Posts

Tags

About

Get in Touch

Categories