Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
개발자

글로벌 칼럼 | 데브옵스 시대는 끝났다

Scott Carey | InfoWorld 2022.08.25
소프트웨어 개발 작업이 점점 더 복잡해짐에 따라 개발(dev) 전문가와 운영(ops) 전문가를 다시 한번 분리해야 할 때가 다가오고 있다. 이번에는 과거의 실수를 반복하지 않고 해낼 수 있을까?
 
ⓒ Getty Images Bank

2000년대 후반 소프트웨어가 세상을 집어삼키기 시작하면서 애자일 방법론과 클라우드 컴퓨팅의 부상과 함께 데브옵스(Devops)가 등장했다. ‘개발’과 ‘운영’을 근사하게 결합한 데브옵스는 과거에는 분리돼 있던 소프트웨어 구축, 배포 담당인 두 그룹을 하나로 모으는 것이 핵심이다. 이에 따라 소프트웨어 엔지니어가 사용자 피드백에 대한 대응을 개선해 제품을 더 자주 업데이트해야 할 필요성이 부상했다.

많은 기업이 데브옵스를 통해 이전에는 불가능했던 속도로 문제를 해결해 나갔고, 일부 기업은 개발자에 운영 작업에 대한 책임까지 담당하는 방법으로 데브옵스를 활용했다. 풀 스택 개발자로 구성된 일종의 슈퍼 팀을 만들려고 했던 셈이다.

그러나 데브옵스 포 더미즈(Devops for Dummies)의 저자이자 아마존 웹 서비스의 커뮤니티 참여 책임자인 에밀리 프리먼은 트위터를 통해 “개발자는 대부분 운영 문제를 다루고 싶어 하지 않는다”라고 문제를 제기했다. 이 트윗을 본 많은 개발자가 수백 개 자기 생각을 답장으로 보냈다. 예를 들어 패스트푸드 회사 치포틀레(Chipotle)의 소프트웨어 엔지니어인 스콧 팬탈은 “맞다. 나 역시 개발자이고 운영 문제를 다루고 싶지 않다”라고 썼다. SUSE의 개발자 에반젤리스트인 앤드루 그레이시는 “개발자와 운영진은 서로 다른 역할을 맡아 긴밀하게 협력해야 한다. 팀 간의 공감이 가장 중요하다”라고 말했다.

더 많은 운영, 보안 문제를 소프트웨어 전체 수명 주기의 ‘왼쪽’으로 이동시켜 소프트웨어 개발자의 영역으로 옮기는 데브옵스 개념은 분명히 많은 장점이 있지만 위험한 병목 현상으로 이어질 가능성도 있다. 쿠버네티스(Kubernetes) 스토리지 전문업체 온닷(Ondat)의 제품 책임자인 제임스 브라운은 “개발자를 너무 많이 다른 영역으로 끌어들이면 결국 사달이 나기 마련이다. 실제로 개발과 운영은 그 기반 기술에서 큰 차이가 있다”라고 말했다.
 

책임의 폭증

엔터프라이즈 소프트웨어 개발자의 중요성은 그 어느 때보다 커지는 사이, 운영자는 업무의 증가에도 불구하고 오히려 그 전문성을 제대로 평가받지 못하고 있다. 데브옵스 엔지니어이자 전 시스템 관리자인 매튜 더건은 "애플리케이션의 가용성, 모니터링, 보안 및 규정 준수를 책임지는 운영자의 부담은 데브옵스가 도입된 현재도 이전과 차이가 없다. 오히려 소프트웨어 배포 파이프라인을 구축하고 유지 관리하는 역할까지 하고 있다. 수작업 없이 코드를 빠르고 안전하게 배포하는 작업이 대표적이다"라고 말했다.

이처럼 책임이 확장되자 엔지니어링 팀 전체적으로 클라우드 엔지니어링과 코드로서 인프라(infrastructure as code) 기술에 대한 대규모 재교육이 중요해졌다. 더건은 “상황이 이보다 더 암울한 적은 없었다. 책임 범위가 크게 늘었지만 속도에 대한 경영진의 비현실적인 기대감으로 인해 전체 개발에 대한 압박이 감당하지 못할 지경에 다다랐다”라고 말했다.

이런 압박은 결국 하나둘씩 외부로 터져 나오고 있다. 델 테크놀로지 캐피탈(Dell Technologies Capital)의 전무 이사인 타일러 주웰은 “기업이 이 정도 수준의 반복적인 개발 주기를 조화롭게 꾸준히 유지하는 것은 매우 어렵다. 시스템이 복잡해지고 최종 사용자 피드백이 증가함에 따라 실무자가 코드 변경 사항이 시스템에 미칠 영향을 가늠하는 것도 점점 더 힘들어지고 있다”라고 말했다.
 

명확한 문제

어쩌면 실제 상황은 더건을 포함해 일부에서 우려하는 것만큼 절망적이지 않을지도 모른다. 그러나 엔지니어링 팀 간에 책임을 재조정할 필요가 있음은 분명해 보인다.

하네스(Harness)의 더킨은 “가장 중요한 것은 개발자에게 부담을 지우는 것이 아니라 개발자에게 적시에 올바른 정보를 제공하도록 권한을 부여하는 것이다. 그들은 모든 것을 구성하고 싶지는 않지만 운영과 보안, 인프라팀이 적절하게 작업할 수 있도록 제때 해당 시스템의 정보를 확보하고자 한다. 개발팀은 실제 문제가 발생하기 전까지는 움직이지 않는 것이 좋다"라고 말했다. 월트 디즈니 컴퍼니(Walt Disney Company)의 엔터프라이즈 기술 전략 책임자인 나이젤 심슨은 "기업은 이런 문제를 인식하고 개발자가 장비 운용에 대한 걱정에서 벗어나 개발자가 원래 가장 잘하는 것, 즉 소프트웨어 만드는 업무로 집중할 수 있도록 해야 한다"라고 말했다.

실제로 데브옵스는 여러 팀 간의 유기적인 연결이고, 이를 구현하는 방법마다 기업마다 다를 수밖에 없다. 개발자가 일부 운영 작업을 할 수 있다는 것이 곧 개발자가 항상 반드시 운영 작업을 해야 한다는 것을 의미하는 것은 아니다.

가트너의 애널리스트 리디아 레옹은 “개발자의 인프라 관리 문제는 전부냐, 아니냐의 문제가 아니다. 전체 애플리케이션 수명주기에 걸쳐 관리 책임을 분산하면, 개발자를 야생의 황무지에 몰아넣고 '운이 좋으면 아무런 문제가 없겠지' 행운을 빌지 않고도 데브옵스에서 기대했던 혜택을 누릴 수 있다. 즉, 개발자에게 개발 및 테스트 환경에 대한 완전한 셀프서비스 액세스를 허용하고 프로덕션을 위한 코드 템플릿으로 인프라를 구축할 수 있도록 하면 된다”라고 말했다.

온닷(Ondat)의 브라운도 여기에 동의했다. 그는 "예를 들어 쿠버네티스를 이용한 컨테이너 오케스트레이션은 개발팀, 운영팀의 관리 책임을 구분하는 역할을 한다. 즉, 개발팀은 코드에 집중할 수 있고, 운영팀은 기반 인프라와 파이프라인이 이 코드를 실행하는 데 최적화하는 데 주력할 수 있다. 이렇게 하면 굳이 팀끼리 서로 소통이 없던 데브옵스 이전 시대로 돌아가지 않고도 현재 제기된 데브옵스 관련 문제를 해결할 수 있다”라고 말했다. 실제로 VM웨어의 ‘2022년 쿠버네티스 현황’ 보고서에 따르면, 응답자 776명 중 54%가 쿠버네티스를 도입한 이유로 개발자 효율성 향상을 지목했다. 3분의 1 이상(37%)은 운영 효율성 개선을 꼽았다.

단, 휴머니텍(Humanitec)의 설립자인 카스파 폰 그룬베르크는 기업이 모든 직원을 전문가로 만들려는 오류에 빠져서는 안 된다고 지적했다. 그는 "성과가 높은 팀에 쿠버네티스 전문가가 있는 경우는 거의 없다. 대신 모든 실무자가 인지 부하(cognitive load)를 낮게 유지할 수 있도록 높은 수준의 추상화 레이어가 그 역할을 한다"라고 말했다.
 

데브옵스는 죽었다

일부의 지적대로 데브옵스의 시대가 실제로 끝나간다면, 혹은 그 의미가 퇴색하기 시작했다면 그다음은 무엇일까? 최근 많은 전문가가 주목하는 것이 바로 구글의 사이트 안정성 엔지니어링(SRE)이다. 구글의 엔지니어링 담당 부사장이자 'SRE의 대부'로 불리는 벤 트레이너는 “SRE는 근본적으로 소프트웨어 엔지니어가 운영 기능을 설계할 때 유용하다"라고 말했다.

뱅가드(Vanguard)와 모건 스탠리(Morgan Stanley) 등 2개의 대형 금융기관을 예로 들어보자. 이들 은행은 더 많은 기존 인프라를 클라우드 네이티브로 전환함에 따라 개발 및 운영 책임의 균형을 맞추는 데 애를 먹었다. 이때 활용한 것이 SRE였다. 중앙 운영 수준과 개별 개발팀 내에 SRE를 추가해 두 은행 모두 개발 속도와 운영 안정성 간에 적절한 균형을 이룰 수 있다.

물론 SRE에 대한 한계도 있다. 모건 스탠리의 데브옵스 및 엔터프라이즈 기술 아키텍처 책임자인 트레버 브로스넌은 "SRE 원칙을 수립하는 것이 때때로 운영팀의 리브랜딩으로 오해된다”라고 말했다. 뱅가드의 사이트 신뢰성 엔지니어인 크리스티나 야코민은 “미묘한 문제다. SRE를 도입하면 일부 직원은 우리가 다시 그 역할에 메이는 것처럼 느낀다. 그래서 우리는 개발자와 운영 전문가가 보안에 대한 책임을 공유하고 공유 플랫폼을 갖춘 팀이 전적으로 운영 책임을 지도록 했다"라고 말했다
 

플랫폼 엔지니어링의 시대

이와 같은 내부 개발자 플랫폼 또는 플랫폼 엔지니어링에 대한 아이디어는 기업이 개발자가 최고의 성과를 낼 수 있도록 필요한 툴을 부여하는 방법으로도 주목받고 있다. 내부 개발자 플랫폼은 일반적으로 개발자가 코드를 프로덕션에 배포하는 데 필요한 API, 도구, 서비스, 지식 및 지원으로 구성된다. 전담 전문가팀 또는 제품 소유자가 유지 관리하는 기업 표준 플랫폼으로 통합되기도 한다.

소프트웨어 엔지니어이자 데브옵스 해설자인 시드 팔라스는 트위터를 통해 “데브옵스는 죽었고 플랫폼 엔지니어링은 계속될 것이다. 개발자는 인프라를 다루는 것을 좋아하지 않지만, 기업은 성장함에 따라 인프라에 대한 통제가 필요하다. 플랫폼 엔지니어링을 통해 부조화 문제를 해결할 수 있다”라고 말했다.

소프트웨어 컨설팅 기업인 소트웍스(Thoughtworks)의 기술 책임자인 브랜든 바이어스는 "플랫폼 엔지니어링이 잘 작동하면 개발자의 불만을 없애면서 기존 운영 방향을 바꿀 수 있는 가능성이 열린다. 기존에는 개발자에게 중앙집중식 전문 지식과 도구 지원 없이 모든 작업을 수행하도록 요청할 수밖에 없었다"라고 말했다.

결국 데브옵스를 기업 내 엔지니어링 팀 전반에 적용해 온 기업이라면 앞으로 소프트웨어 개발팀과 운영팀 간의 균형 조정 문제가 뜨거운 감자가 될 것이다. 클라우드 네이티브 시대를 맞아 복잡성이 더 커지는 가운데 해결해야 할 까다롭고 위험한 숙제다.
editor@itworld.co.kr
 Tags 데브옵스 DevOps
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.