DevOps는 소프트웨어 개발 및 IT 운영 팀의 작업을 결합하고 자동화함으로써 고품질의 소프트웨어를 보다 빠르게 제공합니다.

DevOps는 근본적으로 더 우수한 품질의 소프트웨어를 더 신속하게 딜리버리하기 위한 소프트웨어 개발 프로세스이자 조직 문화적 변화를 가리킵니다. 이를 위해 개발 팀과 IT 운영 팀의 활동을 자동화하고 통합합니다. 이 두 조직은 지금까지 개별적으로, 즉 각자의 사일로 내에서 작업하곤 했습니다.

현실적으로 최상의 DevOps 프로세스 및 문화는 개발 및 운영의 영역에 머무르지 않고 모든 애플리케이션 이해 관계자, 이를테면 플랫폼/인프라 엔지니어링, 보안, 컴플라이언스, 거버넌스, 위험 관리, LOB(line-of-business), 최종 사용자, 고객 등의 의견을 소프트웨어 개발 라이프사이클에 반영합니다.  

DevOps는 수 개월 또는 수 년마다의 거대한 애플리케이션 전체 코드 릴리스에서부터 매일 또는 하루에 몇 번씩 빈번하게 릴리스되는 반복적인 작은 특성 또는 기능적 업데이트에 이르기까지 과거 20년이 넘는 동안의 소프트웨어 딜리버리 사이클의 진화의 현재 상태를 나타냅니다.

궁극적으로, DevOps는 빈번하고 혁신적인 새로운 기능과 중단 없는 성능 및 가용성에 대한 소프트웨어 사용자의 끊임없이 증가하는 요구사항을 충족시키는 것입니다.

2000년 이전까지만 해도, 대부분의 소프트웨어는 대규모 개발 프로젝트에 대한 선형 접근법인 폭포수 방법론을 사용하여 개발되고 업데이트되었습니다. 소프트웨어 개발 팀은 대부분 또는 모든 애플리케이션에 영향을 주는 새 코드의 대형 본문을 개발하는 데 몇 달을 사용합니다. 변경사항이 너무 광범위하기 때문에, 이들은 이러한 새 코드를 코드 베이스에 통합하는 데 몇 개월을 더 사용했습니다. 

그 다음에는 품질 보증(QA), 보안 및 운영 팀이 여전히 코드를 테스트하는 데 수 개월을 더 사용했습니다. 결과적으로 소프트웨어 릴리스 사이에는 수 개월 또는 심지어는 몇 년이 걸렸으며, 종종 릴리스 간의 여러 중요 패치나 버그 수정사항의 경우도 이와 마찬가지였습니다. 그리고 기능 딜리버리에 대한 이 "빅뱅 접근법"은 종종 복잡하고 위험한 배치 계획, 업스트림 및 다운스트림 시스템과의 상호잠금을 스케줄하기가 어려움, 그리고 프로덕션 "활성화"로 이어지는 몇 달 동안 비즈니스 요구사항이 급격하게 변화되지 않는다는 IT의 "커다란 희망"을 특징으로 합니다.

개발 속도를 빠르게 하고 품질을 향상시키기 위해 개발 팀은 애자일 소프트웨어 개발 방법론을 채택하기 시작했으며, 이는 선형이 아니라 반복적이며 애플리케이션 코드 베이스에 대한 보다 작고 빈번한 업데이트에 집중합니다. 이들 방법 중 가장 중요한 것은 지속적 통합 및 지속적 딜리버리 또는 CI/CD입니다. CI/CD에서 새 코드의 소형 청크는 1주 또는 2주마다 코드 베이스에 병합된 후에, 프로덕션 환경으로의 배치를 위해 자동으로 통합, 테스트 및 준비됩니다. 애자일은 '빅뱅' 접근 방법을 역시 리스크를 구획화하는 일련의 '보다 작은 스냅'으로 진화시켰습니다.

이러한 애자일 개발 관행이 소프트웨어 개발 및 제공을 더 효과적으로 가속화할수록, 소프트웨어 제공 라이프사이클의 다음 병목 지점인 여전히 사일로화된 IT 운영(시스템 프로비저닝, 구성, 수용성 테스트, 관리, 모니터링)을 더 많이 노출시킵니다. 

그래서 DevOps는 더 이상 애자일하지 않습니다. 이는 CI/CD의 지속적 반복과 자동화를 소프트웨어 딜리버리 라이프사이클의 나머지로 확장하는 새로운 프로세스와 툴을 추가했습니다. 그리고 이는 프로세스의 모든 단계에서 개발과 운영 사이의 긴밀한 협업을 구현했습니다.

DevOps 라이프사이클(선형 방식으로 표현할 경우, 종종 지속적 딜리버리 파이프라인이라고도 함)은 고품질 소프트웨어의 신속한 딜리버리를 최적화하도록 설계된 더 크고 자동화된 반복적 개발 라이프사이클 내에서 실행되는 일련의 반복적이고 자동화된 개발 프로세스 또는 워크플로우입니다. 워크플로우의 이름과 수는 누구에게 요청하느냐에 따라 다를 수 있지만, 이는 일반적으로 다음의 여섯 가지로 귀결됩니다.

• 계획(또는 구상). 이 워크플로우에서 팀은 우선순위가 지정된 일반 사용자 피드백 및 사례 연구는 물론 모든 내부 이해 당사자의 의견을 바탕으로 다음 릴리스의 새로운 특성과 기능을 자세히 살펴봅니다. 계획 단계의 목표는 전달 시에 가치가 있는 원하는 결과를 생성하는 기능의 백로그를 생성하여 제품의 비즈니스 가치를 극대화하는 것입니다.
  
  
• 개발. 이는 개발자가 백로그의 사용자 스토리 및 작업 항목을 기반으로 새롭고 향상된 기능을 테스트, 코딩 및 빌드하는 프로그래밍 단계입니다. 무엇보다도 테스트 기반 개발(TDD), 쌍 프로그래밍 및 피어 코드 검토 등의 사례들의 조합은 일반적입니다. 개발자는 종종 로컬 워크스테이션을 사용하여 지속적 딜리버리 파이프라인 아래로 전송하기 전에 코드 쓰기 및 테스트의 "내부 루프"를 수행합니다.
  
  
• 통합(또는 빌드, 또는 지속적 통합 및 지속적 딜리버리(CI/CD)). 위에서 언급한 바와 같이, 이 워크플로우에서 새 코드는 기존 코드 베이스에 통합된 후 배치를 위해 테스트되고 실행 파일로 패키지화됩니다. 공통 자동화 활동에는 "마스터" 사본으로 코드 변경사항 병합, 소스 코드 저장소에서 해당 코드의 체크아웃 및 컴파일, 단위 테스트의 자동화 및 실행 파일로의 패키징이 포함됩니다. 우수 사례는 다음 단계를 위해 2진 저장소에 CI 단계의 출력을 저장하는 것입니다.
  
  
• 배치(일반적으로 지속적 배치라고 부름). 여기에서 (통합으로부터의) 런타임 빌드 출력이 런타임 환경에 배치됩니다. 런타임 환경은 보통 품질, 규정 준수, 보안을 위해 런타임 테스트가 실행되는 개발 환경입니다. 오류 또는 결함이 발견되면, 개발자는 일반 사용자가 발견하기 전에 문제점을 가로채고 수정할 수 있는 기회를 갖습니다. 일반적으로 개발, 테스트 및 프로덕션을 위한 환경이 있으며, 각 환경은 점진적으로 "보다 엄격한" 품질 게이트를 필요로 합니다. 프로덕션 환경에 배치하기 위한 좋은 방법은 일반적으로 일반 사용자의 서브세트에 먼저 배치한 후에, 일단 안정성이 설정되면 결국 모든 사용자에게 배치하는 것입니다.
  
  
• 운영. 프로덕션 환경으로 기능을 전달하는 일이 "1일차"로 여겨지는 경우, 일단 기능이 프로덕션에서 실행 중이면 "2일차" 운영이 이루어집니다. 기능 성능, 작동 및 가용성을 모니터링하면 기능이 최종 사용자에게 부가 가치를 제공할 수 있도록 보장합니다. 운영은 네트워크, 스토리지, 플랫폼, 컴퓨팅 및 보안 상태가 모두 정상인지 확인하여 기능들이 원활하게 실행되고 서비스가 중단되지 않도록 합니다. 문제점이 발생하는 경우, 운영 팀은 인시던트가 식별되고, 해당 직원에게 경보가 전달되며, 문제점이 판별되고, 수정이 적용되도록 보장합니다.
  
  
• 학습(때로는 지속적 피드백이라고 부름). 이는 특성, 기능, 성능 및 비즈니스 가치에 대한 최종 사용자와 고객의 피드백을 수집하여 다음 릴리스의 특성과 개선사항에 대한 계획으로 돌려보냅니다. 여기에는 또한 운영 활동의 모든 학습 및 백로그 항목이 포함되며, 이는 미래에 다시 발생할 수 있는 과거의 사건을 사전에 방지할 수 있도록 개발자의 역량을 강화합니다. 이것이 바로 계획 단계에 대한 "랩어라운드"가 발생하고 "지속적 개선"이 실행되는 지점입니다!

세 가지 다른 중요한 연속 워크플로우가 이러한 워크플로우 사이에 발생합니다.

지속적 테스트: 전통적인 DevOps 라이프사이클에는 통합 및 배치 사이에 발생하는 개별 "테스트" 단계가 포함됩니다. 그러나, DevOps는 테스트의 특정 요소들이 계획(행동 기반 개발), 개발(단위 테스트, 계약 테스트), 통합(정적 코드 스캔, CVE 스캔, 린팅), 배치(스모크 테스트, 침투 테스트, 구성 테스트), 운영(혼돈 테스트, 규제 준수 테스트) 및 학습(A/B 테스트)에서 발생할 수 있도록 발전되었습니다. 테스트는 강력한 위험 및 취약성 식별 양식이며, IT가 위험을 수용, 완화 또는 해결할 수 있는 기회를 제공합니다.

보안: 폭포수 방법론과 애자일 구현이 딜리버리 또는 배치 후에 보안 워크플로우를 '덧붙이는' 반면, DevOps는 보안 문제를 해결하기 가장 쉽고 가장 적은 비용이 드는 때인 처음부터(계획) 그리고 개발 주기의 나머지 기간 내내 보안을 통합하려고 노력합니다. 보안에 대한 이러한 접근 방식을 왼쪽 이동(shifting left)(그림 1을 보면 이해가 용이함)이라고 합니다. 일부 기업들의 왼쪽 이동은 다른 기업들보다 성공적이지 않았으며, 이에 따라 DevSecOps(아래 참조)가 부상했습니다.

규제 준수. 규제 준수(거버넌스 및 리스크)는 조기에 그리고 개발 라이프사이클 내내 가장 잘 해결됩니다. 규제된 산업은 종종 런타임 운영 환경에서 기능이 전달되고 관리되는 방식에 대한 특정 수준의 관찰가능성, 추적성 및 액세스를 제공하도록 규정되어 있습니다. 이를 위해 지속적 딜리버리 파이프라인과 런타임 환경에서 정책의 계획, 개발, 테스트 및 실행이 필요합니다. 규제 준수 조치에 대한 감사 가능성은 써드파티 감사자에게 규제 준수를 입증하기 위해 매우 중요합니다.

DevOps 방식은 DevOps 문화에 대한 헌신 없이는 작동할 수 없다는 것이 일반적으로 받아들여지며, 이는 소프트웨어 개발에 대한 다른 조직적 및 기술적 접근 방식으로 요약될 수 있습니다.

조직적 수준에서 신속하게 그리고 지속적으로 혁신하고 처음부터 소프트웨어의 품질을 보장하려면 DevOps는 모든 소프트웨어 제공 이해 관계자(당연히 소프트웨어 개발 및 IT 운영 팀이 포함되며, 보안, 규제 준수, 거버넌스, 리스크 및 LOB(line-of-business) 팀도 포함됨) 간의 커뮤니케이션, 협업, 책임 공유를 요구합니다.

대부분의 경우 이를 달성하는 가장 좋은 방법은 이러한 사일로를 해소하여 다른 팀에게 일을 넘기거나 다른 팀의 승인을 기다리지 않고 처음부터 끝까지, 즉 계획부터 피드백까지 코드 프로젝트에 참여할 수 있는 자율적인 부서 간 DevOps 팀으로 재구성하는 것입니다. 애자일 개발의 맥락에서 보면, 공유된 책임과 협업은 가치 있는 결과를 내는 공유된 제품 초점 보유의 기반입니다.

기술적 수준에서, DevOps는 워크플로우 내에서와 이들 간에 프로젝트를 지속적으로 이동시키는 자동화 및 팀들이 주기를 지속적으로 가속화하고 소프트웨어 품질과 성능을 향상시킬 수 있도록 하는 피드백 및 측정 에 대한 헌신을 요구합니다.

DevOps 및 DevOps 문화의 요구사항은 비동기 협업을 지원하고, DevOps 워크플로우를 완벽하게 통합하며, 전체 DevOps 라이프사이클을 최대한 자동화하는 툴링을 중시합니다. DevOps 툴의 카테고리에는 다음이 포함됩니다.

• 프로젝트 관리 툴 - 팀이 코딩 프로젝트를 형성하는 사용자 스토리(요구사항)의 백로그를 빌드하고, 이를 더 작은 태스크로 구분하며, 태스크를 완료 시점까지 추적할 수 있도록 하는 툴입니다. 다수는 개발자가 DevOps에 제공하는 Scrum, Lean 및 Kanban 등의 애자일 프로젝트 관리 사례를 지원합니다. 유명한 오픈 소스 옵션에는 GitHub Issues 및 Jira 등이 있습니다.
  
  
• 협업 소스 코드 저장소 - 여러 개발자들이 동일한 코드 베이스에서 작업할 수 있도록 허용하는 버전 제어 코딩 환경입니다. 코드 저장소가 저장소로 커미트될 때 자동으로 다음 단계로 이동할 수 있도록, 코드 저장소는 CI/CD, 테스트 및 보안 툴과 통합되어야 합니다. 오픈 소스 코드 저장소에는 GiHub 및 GitLab이 포함됩니다.
  
  
• CI/CD 파이프라인 - 코드 체크아웃, 빌드, 테스트 및 배치를 자동화하는 툴입니다. Jenkins는 이 카테고리에서 가장 인기 있는 오픈 소스 툴입니다. CircleCI 등의 많은 이전의 오픈 소스 대안들은 현재 상용 버전으로만 제공됩니다. 지속적 배치(CD) 툴에 관한 한, Spinnaker는 애플리케이션과 IaC(Infrastructure as Code) 계층 간에 걸쳐 있습니다. ArgoCD는 Kubernetes 네이티브 CI/CD의 또 다른 유명한 오픈 소스 선택사항입니다.
  
  
• 테스트 자동화 프레임워크 - 이들에는 유닛, 계약, 기능, 성능, 사용성, 침투 및 보안 테스트를 자동화하기 위한 소프트웨어 툴, 라이브러리 및 베스트 프랙티스가 포함됩니다. 이러한 툴 중 최고는 여러 언어를 지원하며, 일부는 인공지능(AI)을 사용하여 코드 변경사항에 대한 응답으로 테스트를 자동으로 재구성합니다. 테스트 툴과 프레임워크의 범위는 매우 넓고 광범위합니다! 유명한 오픈 소스 테스트 자동화 프레임워크에는 Selenium, Appium, Katalon, Robot Framework 및 Serenity(이전의 Thucydides)가 포함되어 있습니다.
  
  
• 구성 관리(IaC(Infrastructure as Code)) 툴 - 이 툴을 사용하면 DevOps 엔지니어는 스크립트를 실행하여 완전 버전화되고 완전 문서화된 인프라를 구성 및 프로비저닝할 수 있습니다. 오픈 소스 옵션에는 Ansible(Red Hat), Chef, Puppet 및 Terraform이 포함됩니다. Kubernetes는 컨테이너화된 애플리케이션에 대해 동일 기능을 수행합니다(아래의 'DevOps 및 클라우드 네이티브 개발' 참조).
  
  
• 모니터링 툴 - 이 툴은 DevOps 팀이 시스템 문제를 식별하고 해결하는 데 도움을 줍니다. 또한 실시간으로 데이터를 수집하고 분석하여 코드 변경사항이 애플리케이션 성능에 어떤 영향을 주는지를 밝혀냅니다. 개방형 소스 모니터링 툴에는 Datadog, Nagios, Prometheus 및 Splunk가 포함됩니다.
  
  
• 지속적인 피드백 툴 - 히트맵(화면에서 사용자의 조치를 기록함), 설문조사 또는 셀프 서비스 문제 티켓팅을 통해 사용자의 피드백을 수집하는 툴입니다.

클라우드 네이티브는 토대가 되는 클라우드 컴퓨팅 기술을 활용하는 애플리케이션 빌드 접근 방법입니다. 클라우드 네이티브의 목표는 퍼블릭, 프라이빗 및 멀티클라우드 환경에서 일관된 최적의 애플리케이션 개발, 배치, 관리 및 성능을 지원하는 것입니다. 

오늘날 클라우드 네이티브 애플리케이션은 일반적으로 다음과 같은 특징이 있습니다.

• 자체 자급식 스택을 보유하고 REST API, 이벤트 스트리밍 또는 메시지 브로커를 통해 서로 간에 통신하는 느슨하게 결합되고 독립적으로 배치 가능한 컴포넌트인 마이크로서비스를 사용하여 빌드됩니다.
  
  
• 애플리케이션을 실행하는 데 필요한 모든 코드, 런타임, 운영 체제 종속성 항목을 포함한 코드의 실행 가능한 단위인 컨테이너로 배치됩니다. (대부분의 조직은 '컨테이너'를 Docker 컨테이너와 같은 의미로 사용하지만, 다른 컨테이너 유형도 존재합니다.)
  
  
• 컨테이너화된 애플리케이션의 배치, 관리 및 확장을 스케줄링 및 자동화하기 위한 오픈 소스 컨테이너 오케스트레이션 플랫폼인 Kubernetes를 사용하여 (규모에 맞게) 운영됩니다.

여러 가지 측면에서, 클라우드 네이티브 개발과 DevOps는 서로 잘 맞습니다. 

예를 들면, 마이크로서비스를 개발하고 업데이트하는 것, 즉 작은 코드 단위를 작은 코드 베이스에 반복적으로 제공하는 것은 DevOps의 빠른 릴리스 및 관리 주기와 완벽하게 맞아떨어집니다. 그리고 DevOps 배치와 운영이 없이는 마이크로서비스 아키텍처의 복잡성에 대처하기가 매우 어렵습니다. 개발자 및 IT 임원에 대한 최근 IBM 설문조사에 따르면 현재 마이크로서비스 사용자의 78%가 아키텍처에 투자한 시간, 비용 및 노력을 늘릴 것으로 예상하며, 비사용자의 56%가 향후 2년 내에 마이크로서비스를 채택할 가능성이 큽니다. 

모든 통합, 테스트 및 배치가 동일 환경에서 발생하므로, 컨테이너는 모든 OS 종속성 항목을 패키징하고 영구적으로 고정하여 빠른 CI/CD 및 배치 사이클을 가능하게 합니다. 그리고 Ansible, Puppet 및 Chef가 비컨테이너화된 애플리케이션을 위해 지속적인 구성 태스크를 수행하듯이, Kubernetes는 컨테이너화된 애플리케이션을 위해 동일한 태스크를 수행합니다.

AWS, Google, Microsoft Azure 및 IBM Cloud와 같은 대부분의 선도적인 클라우드 컴퓨팅 제공업체는 일종의 매니지드 DevOps 파이프라인 솔루션을 제공합니다.

DevSecOps는 시작부터 끝까지, 즉 계획에서 피드백 그리고 다시 계획까지 DevOps 라이프사이클 전체에서 보안을 지속적으로 통합하고 자동화하는 DevOps입니다.

이를 다른 방식으로 설명하자면, DevSecOps는 DevOps가 처음부터 의도하고자 했던 모습입니다. 그러나 DevOps 채택의 두 가지 초기의 중요한(그리고 당분간은 극복할 수 없는) 과제는 보안 전문 지식을 교차 기능 팀에 통합(문화적 문제)하는 것과 보안 자동화를 DevOps 라이프사이클에 적용(기술적 문제)하는 것이었습니다. 보안은 "'아니요'의 팀"으로 간주되었으며, 다수의 DevOps 관행에서 비용이 많이 드는 병목 지점으로 인식되었습니다.

DevSecOps는 원래 의도한 대로 보안을 통합하고 자동화하기 위한 구체적인 노력으로 나타났습니다. DevSecOps에서 보안은 개발 및 운영과 함께 "1등급" 시민이자 이해 관계자이며, 제품에 집중하며 개발 프로세스에 보안을 제공합니다.

'DevSecOps란?'을 보고 DevSecOps의 원칙, 이점 및 사용 사례에 대해 알아보세요.

사이트 신뢰성 엔지니어링(site reliability engineering, SRE)은 시스템 관리자가 수작업으로 수행했을 IT 운영 작업(예: 프로덕션 시스템 관리, 변경 관리, 인시던트 대응, 심지어 긴급상황 대응도 포함)을 자동화하기 위해 소프트웨어 엔지니어링 기법을 사용합니다. SRE는 기존의 시스템 관리자를 엔지니어로 전환시키고자 합니다.

SRE의 궁극적 목표는 DevOps의 목표와 유사하지만, 더 구체적으로 말하면 SRE의 목표는 빠른 애플리케이션 개발에 대한 조직의 욕심과 고객 및 최종 사용자와 체결한 서비스 수준 계약(SLA)에 명시된 성능 및 가용성 수준을 충족해야 할 필요성 사이의 균형을 유지하는 것입니다. 

사이트 신뢰성 엔지니어는 애플리케이션이 유발하는 운영 리스크의 허용 가능한 수준(이를 오류 예산('error budget')이라고 부름)을 결정하고 이러한 수준을 충족하는 운영을 자동화하여 이러한 균형을 달성합니다. 

교차 기능 DevOps팀에서 SRE는 개발과 운영 간의 가교 역할을 수행할 수 있으며, 기업 SLA의 내용을 '위반'하지 않고 가능한 한 신속하게 DevOps 파이프라인을 통해 코드 변경사항과 신규 기능을 푸시하기 위해 팀에 필요한 메트릭과 자동화를 제공합니다. 

사이트 안정성 엔지니어링 자세히 보기

DevOps 는 소프트웨어 개발 팀과 IT 운영 팀의 작업을 결합하고 자동화하여 소프트웨어를 제공하는 프로세스입니다. 반면 MLOps는 머신러닝 프로젝트에만 적용됩니다.

그러나 MLOps는 애플리케이션 작성 및 업데이트에 대한 신속하고 지속적인 접근 방식이라는 DevOps 원칙을 차용합니다. 두 경우 모두의 목표는 소프트웨어이든 머신러닝 모델이든 관계없이 프로젝트를 보다 효율적으로 프로덕션에 적용하는 것입니다. 두 경우 모두 목표는 더 빠른 수정, 더 빠른 릴리스, 그리고 궁극적으로 고객 만족도를 높이는 더 높은 품질의 제품입니다.