개발(development)과 운영(operations)의 합성어인 데브옵스(devops)는 과거 각기 개별적으로 소프트웨어 구축과 배포를 담당했던 두 그룹을 하나로 묶기 위해 등장한 방법론이다.
과거에는 개발자(데브)가 코드를 작성한 다음 시스템 관리자(옵스)에게 넘기면 옵스에서 배포와 통합을 맡는 형태가 보편적이었다. 그러나 업계가 애자일 개발과 클라우드 네이티브 컴퓨팅으로 방향을 틀면서 많은 조직이 더 빠르고 더 나은 릴리스를 위해 현대적인 클라우드 네이티브 방식으로 재편됐다.
이를 위해서는 더 능률적이고 효율적이며 응집력 있게 주요 기능을 수행할 새로운 방법, 과거 개발과 운영 기능의 분리에서 비롯된 마찰이 없는 방법이 필요했다. 두 그룹이 협력하면 개발자는 ‘빅뱅’ 방식의 제품 릴리스에 몇 년을 매달리는 것이 아니라 지속적 통합과 지속적 제공을 통해 작은 코드 개선을 빠르게 배포할 수 있다.
데브옵스는 페이스북, 넷플릭스, 스포티파이, 아마존과 같은 클라우드 네이티브 기업에서 탄생했지만 지난 10년에 걸쳐 현대 소프트웨어 개발의 틀을 형성한 수많은 변화를 이끌면서 기술 산업을 정의하는 핵심 트렌드가 됐다.
애자일 개발과 클라우드 네이티브 컴퓨팅이 보편화됨에 따라 데브옵스는 업계 전체의 소프트웨어 개발 주기를 가속화했다. 결과적으로 데브옵스는 특히 은행, 항공사, 소매업체와 같이 소프트웨어에 의존해 비즈니스를 운영하는 조직을 중심으로 기업에 깊게 뿌리내렸다. 데브옵스를 기반으로 여러 가지 다른 ‘옵스’도 탄생했다.
데스옵스 프랙티스
데브옵스는 개발과 운영, 양쪽 모두에서 사고방식의 전환을 요구한다. 개발팀은 애자일 프로세스 학습과 도입, 플랫폼 표준화, 운영 효율성 지원에 집중해야 하고, 운영팀은 이제 안정성과 속도를 개선하는 데 초점을 맞추되 개발팀과 협력해 비용도 절감해야 한다.
전반적으로 이 두 팀은 공통의 언어를 사용해야 한다. 데브옵스가 성공하기 위해서는 공유된 목표와 각자의 핵심 역량에 대한 상호 이해가 필요하다.
엔지니어인 데이먼 에드워즈와 존 윌리스는 보편적으로 데브옵스의 핵심 원칙으로 인식되는 여러 요소를 모아 CALMS 모델을 만들었다.
- - 문화(Culture) : 애자일 방법론을 수용하고 변화와 지속적 개선, 소프트웨어의 종단간 품질에 대한 책임을 받아들이는 문화
- - 자동화(Automation) : 고된 작업의 자동화는 모든 데브옵스 팀의 주요 목표
- - 린(Lean) : 소프트웨어가 주요 단계를 최대한 신속하고 원활하게 흐르도록 보장
- - 측정(Measurement) : 측정할 수 없는 대상을 개선할 수는 없다. 데브옵스는 지속적인 측정과 피드백 문화를 추구하며, 이를 통해 필요할 때 즉시 개선하고 방향을 전환할 수 있다.
- - 공유(Sharing) : 조직 전반에 걸친 지식 공유는 데브옵스의 핵심 요소
데브옵스 옹호자 진 킴은 “노트북 환경을 프로덕션 환경과 똑같이 보이게 구성할 방법을 고민하던 예전 방식으로 돌아갈 사람은 아마 없을 것이다. 더 나은 방법이 존재한다는 사실이 명확하게 드러났기 때문이다. 지속적 통합, 지속적 제공 등을 한 번 경험하면 과거 방식으로 다시 돌아가기는 매우 어렵다”라고 말했다.
데브옵스 엔지니어란 무엇인가?
데브옵스가 등장하면서 자연스럽게 새로운 여러 직책도 생겨났다. 그중에서도 가장 눈에 띄는 직책은 데브옵스 엔지니어다.
일반적으로 말하면 이 역할은 기존의 시스템 관리자가 진화한 형태로, 개발자와 운영자가 긴밀히 협력해 더 나은 소프트웨어를 제공하는 세계에 존재한다. 데브옵스 엔지니어는 팀의 양쪽 사이를 잇는 가교 역할을 효과적으로 수행하기 위해 프로그래밍과 시스템 관리자 역량을 모두 갖춰야 한다.
이를 위해서는 기술적 역량보다 사회적 역량이 더 필요하다. 킴은 “데브옵스는 30~40년 동안 해왔던 방식을 고수하고자 하는 견고한 과거의 질서를 전복하는 일종의 반란이며, 이를 위한 가장 중요한 역량은 비즈니스 쪽 사람들과 마주 앉아 문제를 해결할 수 있는 교차 직무 역량”이라고 설명했다.
또한 데브옵스 엔지니어는 개인이든 팀이든 최적화를 책임지면서 더 나은 방식을 도입하고 병목 지점을 제거하거나 자동화를 적용해 소프트웨어 제공 과정을 원활하게 함으로써 팀의 소프트웨어 제공 속도와 품질을 지속적으로 개선하는 역할을 한다.
좋은 소식은 이런 역량이 기업에 가치가 있다는 점이다. 데브옵스 엔지니어 연봉은 지난 몇 년 동안 꾸준히 올라 2020년 미국 데브옵스 실무자의 95%가 연간 7만 5,000달러 이상을 받아 갔다. 전반적으로 미국에 비해 연봉이 낮은 유럽과 영국에서도 연봉 5만 달러 이상을 받는 비율이 2019년의 67%에서 2020년 71%로 증가했다. 코세라에 따르면, 2025년 7월 기준 미국 데브옵스 엔지니어의 평균 기본 연봉은 약 13만 9,000달러, 추가 보상까지 포함한 전체 연봉은 약 14만 2,104달러에 이르는 것으로 집계된다.
주요 데브옵스 툴
데브옵스는 본질적으로 문화적인 변화지만, 기업에서 데브옵스 프랙티스를 도입하는 데 도움이 툴도 다양하게 나와 있다. 이런 툴의 스택에는 일반적으로 코드형 인프라, 구성 관리, 협업, 버전 제어, CI/CD, 배포 자동화, 테스트, 모니터링 툴이 포함된다.
2025년 현재 더 중요해지고 있는 툴/범주는 무엇이고, 어떤 점이 변화하고 있는지 살펴보자.
- - CI/CD 및 전달 자동화 : 많은 스택에 여전히 젠킨스와 같은 전통적인 툴이 남아 있지만 새로운 오케스트레이션 툴과 CLI 기반 또는 깃옵스(GitOps) 중심 플랫폼의 중요성이 계속 커지고 있다. 예를 들면 아르고CD(ArgoCD), 플럭스(Flux), 테크톤(Tekton) 등이 있다. 또한 모니터링, 비밀 정보 관리, 드리프트 탐지, 정책 집행과 더 긴밀하게 통합되는 플랫폼이 주목받고 있다.
- - 보안, 규정 준수, 데브섹옵스 툴 : 보안 툴이 데브옵스 파이프라인에 통합되는 추세가 확산되고 있다. 정적 분석(SAST), 동적 테스트(DAST), 종속성 및 공급망 스캔(SCA), 비밀 정보 관리, 코드형 정책 사용이 증가할 것으로 전망된다. 보안을 더 조기에 내재화하고 개발, 보안, 머신러닝 팀 사이의 간극을 줄이는 방향으로 나아가고 있다.
- - AI와 자동화 증강 : CI/CD에서의 자동 제안, 이상 탐지, 예측 확장, 지능형 테스트 모음 선택 등 점점 더 많은 AI 지원 툴이 스택에 편입되는 추세다. 이런 툴은 수동 개입을 줄이고 신뢰성을 높여줄 것으로 기대된다. ‘AI에 준비된’ 툴, 즉 AI와 잘 통합되거나 성숙한 내장 자동화 및 보조 기능을 갖춘 툴이 점점 더 차별화되고 있다.
데브옵스 과제
데브옵스가 광범위하게 채택되고 있지만 진전 속도를 늦추거나 파급 효과를 제한할 수 있는 현실적인 장애물도 여전히 존재한다. 주요 과제 중 하나는 지속적으로 나타나는 기술 공백이다. 현대의 데브옵스 엔지니어(또는 팀)은 소스 제어, CI/CD, 스크립팅뿐만 아니라 클라우드 아키텍처, 코드형 인프라, 보안 베스트 프랙티스, 관찰가능성, 강력한 팀 간 커뮤니케이션까지 마스터해야 한다. 조직마다 이런 역량은 산발적으로 분포돼 있어 뛰어난 팀이 있는가 하면 뒤처지는 팀도 있다. 2024년 설문조사에 따르면, 개발자 83%가 데브옵스 활동에 참여한다고 답했지만, 여러 CI/CD 툴 사용은 오히려 성과를 저해하는 요인이 되는 것으로 나타났다. 이는 심층적인 전문성이 동반되지 않은 복잡성 증가가 역효과를 낼 수 있음을 보여준다.
툴체인의 단편화와 복잡성도 이와 관련된 문제다. 데브옵스 툴체인은 버전 제어, CI 빌드/테스트, 보안 스캔, 아티팩트 관리, 모니터링, 관찰가능성, 배포, 비밀 정보 관리 등 패키지와 기법이 어지럽게 혼재돼 있어 마스터하기가 어렵다. 툴이 많아질수록 깔끔하게 통합하고, 각각의 버전을 관리하고, 호환성을 보장하고, 중복 작업을 피하기가 어렵다. 다양한 팀이 선택한 툴, 레거시 시스템, 중복되는 기능으로 인한 무분별한 툴 확산에 갇히는 조직이 많으며, 이는 마찰과 유지보수 부담, 때로는 취약성을 초래한다.
마지막으로, 데브옵스가 광범위하게 보급됐다고 하지만 문화적 저항과 조화의 문제는 여전히 남아 있다. 데브옵스는 단순히 툴과 프로세스만으로 구성되는 것이 아니라 협업, 공동 책임, 지속적 피드백도 중요하다. 전통적인 사일로(개발과 운영의 대립, 혹은 보안의 분리)에 뿌리를 둔 팀은 역할과 워크플로우의 변화를 거부할 수 있다. 경영진의 지원, 공동 목표에 대한 커뮤니케이션, 신뢰, 그리고 지속적 학습을 허용하는 환경이 모두 필요하다.
많은 CIO가 조직 문화와 행동보다는 툴 또는 구현에 지나치게 집중한다. 그러나 문화 문제에 대처하지 않으면 최고의 툴이나 프로세스라 해도 기대했던 속도, 품질, 신뢰성을 제공하지 못할 수 있다. 이 부분에서 성공하는 기업은 대부분 선제적인 전략을 실행하는 조직이다. 즉, 전용 교육 프로그램, 멘토토십, 내부 ‘길드’, 초급 엔지니어와 숙련된 엔지니어의 페어링, 일회성 부트캠프가 아닌 지속적 학습에 대한 경영진 지원을 실천하는 조직이 성공한다.
데브옵스를 하는 이유
데브옵스에 대해 물어보면 누구나 조직에 있어 대대적인 문화적 변화라고 말할 것이다. 그렇다면 굳이 고통을 감수하면서 하는 이유가 무엇일까?
데브옵스의 목표는 과거 상충했던 개발자와 시스템 관리자의 목표를 결합하는 데 있다. 이 원칙 아래 모든 소프트웨어 개발은 비즈니스 요구를 충족하고 기능을 추가하고 애플리케이션의 사용성을 개선하는 동시에 안정성, 보안, 신뢰성을 보장하는 데 목표를 둔다. 이것이 제대로 실행되면 결과물의 속도와 품질이 개선될 뿐 아니라 그 결과물을 만드는 사람의 삶도 함께 개선된다.
데브옵스는 비용을 절감하는가, 아니면 더하는가?
데브옵스팀은 속도와 민첩성은 성공의 일부에 불과하다는 점을 인식하고 있다. 미처 확인하지 못한 클라우드 비용과 낭비는 장기적인 지속가능성을 약화시킨다. 데브옵스에서 낭비는 많은 경우 ‘데브옵스 부채’의 형태, 즉 유휴 클라우드 용량, 죽은 코드, 보안 오경보 등으로 나타난다. 최근 여러 자바 환경 연구에서는 이를 두고 “혁신에 대한 숨은 세금“으로 표현하기도 했다.
핀옵스(FinOps) 프랙티스를 내재화하면 이런 비용을 줄이는 데 도움이 된다. 팀은 비용의 시프트 레프트를 통해. 새로운 환경 가동 시 비용을 추정하고 인스턴스 크기를 조정하고 사용되지 않는 리소스를 줄여 통제 불능의 비용 발생을 사전에 차단해야 한다.
데브옵스를 시작하는 방법
킴의 데브옵스 핸드북을 포함해 데브옵스를 시작하는 데 도움이 되는 리소스는 많고, 외부 컨설턴트의 도움을 받을 수도 있다. 그러나 기업 전반에서 지속적인 동의를 확보하기 위해서는 체계적인 접근 방식으로 툴과 기술보다 사람에 집중해야 한다.
이 목표를 달성하는 검증된 방법은 ‘착륙 후 확장’ 전략이다. 이 전략에서는 먼저 소규모 그룹이 핵심 가치 흐름을 매핑하고 단일 제품 팀이나 워크로드를 선정해 데브옵스 프랙티스를 시험한다. 이 소규모 팀이 변화의 가치를 입증하는 데 성공하면 다른 팀과 경영진도 관심을 갖게 될 가능성이 높다.
현재 데브옵스 여정의 시작 단계에 있다면 이와 같은 큰 변화가 조직에 가져올 혼란에 대비해야 하며, 더 우수하고 빠르고 강력한 소프트웨어를 구축하는 것이 궁극적인 목표임을 잊지 말아야 한다.
dl-itworldkorea@foundryco.com
Scott Carey editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.