DevOps 수명 주기란 무엇인가요?

DevOps 프로세스는 개발 팀과 운영 팀이 하나의 협업 조직으로 함께 작업하면서 소프트웨어가 아이디어 단계에서 시작해 운영과 피드백을 거쳐 다시 아이디어 단계로 순환하는 과정을 설명합니다. 이는 DevOps 팀이 소프트웨어 릴리스를 계획, 개발, 운영 및 최적화하는 데 활용할 수 있는 엔드투엔드 방식의 실무와 자동화 워크플로로 구성됩니다.

DevOps 수명 주기의 단계는 종종 왼쪽에는 개발 활동, 오른쪽에는 운영 활동이 위치하고 하나의 연속된 경로로 연결된 “무한 루프” 형태로 표현됩니다.

“계획 → 코드 → 빌드 → 테스트” 구간에서는 팀이 소프트웨어 요구 사항을 작은 사용자 스토리로 세분화하고 코드를 코드 저장소에 점진적으로(그러나 자주) 커밋하며, 지속적 통합(CI) 툴을 사용하여 모든 코드 변경을 자동으로 빌드하고 테스트합니다.

“릴리스 → 배포 → 운영 → 모니터링” 구간에서는 자동화 워크플로가 변경 사항을 IT 환경에 적용하고 사용자에게 전달합니다. 한편 관측 가능성 툴은 시스템 상태, 소프트웨어 성능 및 사용자 행동을 추적하여 문제를 감지하고 전체적인 영향을 측정합니다.

무한 루프는 DevOps 수명 주기의 각 단계가 서로에게 영향을 미친다는 점을 강조합니다. 팀은 사일로 간에 업무를 넘기는 대신 작업, 지식 및 책임을 공유합니다. 이 루프는 DevOps 워크플로가 소프트웨어 전달 및 최적화 프로세스를 어떻게 간소화하는지 보여줍니다. 이상적으로는 각 반복 주기가 이전보다 더 빠르고 안전하며 자동화되어야 합니다.

따라서 DevOps 수명 주기는 기업이 사람, 프로세스 및 툴을 정렬하여 고품질 소프트웨어 애플리케이션과 원활한 사용자 경험을 제공할 수 있도록 합니다.

DevOps 수명 주기의 각 단계는 서로 영향을 주고 겹치지만, 각 단계는 명확한 목적과 관련 활동을 가지고 있습니다. 단계는 다음과 같습니다.

계획 단계에서는 DevOps 팀이 비즈니스 요구 사항과 사용자 피드백을 명확하고 우선순위가 지정된 일정 기반 작업 계획과 프로젝트 관리 워크플로로 변환하여 이후 단계의 개발 및 운영 활동을 안내합니다. 이 단계에서는 소프트웨어 릴리스 또는 시스템 구축에 대한 비전, 범위 및 로드맵을 명확히 하여 모든 구성원이 무엇을 만들고 있는지, 왜 중요한지, 그리고 성공을 어떻게 측정할 것인지 이해하도록 합니다.

일반적인 계획 활동에는 다음이 포함될 수 있습니다.

• 제품 백로그(신규 기능, 버그 수정, 기술 부채 등)를 정제하고 우선순위를 조정합니다.

• 이해관계자의 의견을 분석하여 사용자 요구 사항과 제약 조건을 파악합니다.

• 작업을 태스크, 사용자 스토리(사용자 관점에서 작성된 기능 설명), 에픽(단일 반복 주기에서 처리하기 어려운 대규모 사용자 스토리)으로 세분화하여 리소스 요구 사항을 추정하고 의존성을 식별합니다.

• 핵심 성과 지표(KPI), 서비스 수준 지표(SLI) 및 서비스 수준 목표를 정의하여 이후 단계에서 목표 기준을 명확히 합니다.

코딩 단계에서는 개발자가 품질 보증과 향후 운영을 고려하여 계획된 인프라 및 소프트웨어 요구 사항을 실제로 작동하는 소스 코드로 구현합니다. 이는 단순히 새로운 코드를 작성하는 것에 그치지 않습니다. 또한 이후 파이프라인에서 자동화된 빌드, 테스트, 통합 및 배포를 수행하기 위한 모든 필수 구성 요소를 준비하는 과정이기도 합니다.

코딩 프로세스에는 다음이 포함됩니다.

• 새로운 기능을 구현하고 결함을 수정하며 비기능적 요구 사항(예: 보안)을 해결하기 위한 코드를 작성합니다.

• 코드 변경 사항을 작고 점진적으로 작성하여 Git 및 GitHub와 같은 버전 관리 시스템의 공유 저장소에 커밋하고 검토를 진행합니다.

• 코드 변경 사항이 원활하게 빌드되고 코드베이스와 통합될 수 있도록 테스트합니다.

• 향후 CI 실행 시 각 커밋 이후 코드 동작을 자동으로 검증할 수 있도록 자동화된 단위 테스트 및 구성 요소 테스트를 추가하거나 업데이트합니다.

빌드 단계에서는 소스 코드 변경 사항이 자동으로 컴파일되고 검증되며 배포 가능한 빌드 산출물로 패키징됩니다. DevOps 툴은 버전 관리 시스템에서 코드 변경 사항을 가져오고 자동화된 검사를 수행한 뒤 Docker 컨테이너 이미지나 컴파일된 바이너리와 같은 패키지를 생성하며, 이는 버전 관리되어 배포 또는 추가 테스트에 사용할 수 있습니다.

구체적으로는 다음과 같습니다.

• 자동화된 스크립트와 빌드 툴은 소스 코드를 컴파일하고 라이브러리, 프레임워크 및 모듈을 포함한 의존성을 해결 및 다운로드한 뒤 이를 실행 파일 또는 이미지로 결합합니다.

• 기본적인 자동화 테스트는 빌드 과정의 일부로 실행됩니다. 빌드가 실패하면 해당 상태는 실패로 표시되며 빌드 단계에 머무르게 됩니다. 빌드가 성공하면 다음 수명 주기 단계로 진행됩니다.

테스트 단계(검증 단계라고도 함)는 코드 변경 사항이 실제 환경에서 예상대로 작동하는지 확인하는 것을 목표로 합니다. DevOps 팀은 다양한 고급 테스트 툴을 사용하여 각 변경 사항이 기능적이고 안전하며 성능 요구를 충족하는지 지속적으로 검증한 후 파이프라인 다음 단계나 운영 환경으로 이동시킵니다.

일반적으로 테스트 프로세스는 지속적 통합/지속적 전달(CI/CD) 파이프라인에 밀접하게 통합되어 개발자가 코드 품질에 대해 빠르고 빈번한 피드백을 받을 수 있습니다.

소프트웨어 테스트의 주요 목적은 결함을 가능한 한 조기에 식별하여(수정 비용과 난이도가 낮은 시점) 문제가 있는 빌드가 릴리스 단계로 진행되는 것을 방지하는 것입니다. 테스트는 또한 새로운 변경 사항이 기존 기능을 손상시키지 않는지 검증하여 소프트웨어가 발전하는 동안 전체 시스템 안정성을 유지하는 데 도움을 줍니다.

릴리스 단계는 “테스트 완료된 빌드”와 “실제 배포” 사이의 통제된 관문 역할을 하며, 코드 변경 사항이 운영 환경에 승인되고 대상 사용자에게 공개됩니다. 개발 팀은 검증된 테스트 코드를 패키징하고 운영 환경에 적합한지 확인하며 스테이징 및 운영 환경으로 언제 어떻게 이동할지 조율하여 배포를 준비합니다.

일반적인 릴리스 프로세스에는 다음이 포함됩니다.

• 사전에 정의된 승인 기준에 따라 최종 품질, 보안 및 규정 준수 검사를 수행합니다.

• 특정 릴리스 버전에 빌드 산출물을 연결하고 변경 로그 및 문서를 생성합니다.

• 다가오는 릴리스에서 취약점을 식별하고 문제 해결을 위한 완화 전략(예: 롤백)을 계획합니다.

배포 단계에서는 테스트되고 패키징된 코드가 대상 환경(스테이징 또는 운영 환경)에 자동으로 전달됩니다. 구성 관리 및 코드형 인프라(IaC) 툴은 구성 파일과 고수준 선언형 코딩 언어를 사용하여 소프트웨어 릴리스를 위한 인프라 프로비저닝과 오케스트레이션을 자동화함으로써 DevOps 팀이 소프트웨어를 안정적이고 반복 가능한 방식으로 제공할 수 있도록 지원합니다.

배포는 일반적으로 지속적 전달(CD)과 컨테이너화 플랫폼(예: Kubernetes)에 의해 이루어지며, 이러한 플랫폼은 빌드 산출물 가져오기, 컨테이너 및 바이너리 업데이트, 최종 테스트 실행 및 트래픽을 새 버전으로 전환하는 등 소프트웨어 배포 프로세스를 오케스트레이션합니다.

DevOps 팀은 새로운 버전을 점진적으로 도입하고 필요 시 신속하게 롤백할 수 있도록 다양한 배포 전략을 활용합니다.

예를 들어 블루-그린 배포에서는 애플리케이션이 두 개의 병렬 운영 환경에 배포되며 각 환경은 서로 다른 릴리스를 실행합니다. “블루” 환경은 실제 애플리케이션을 실행하고 “그린” 환경은 새로운 애플리케이션 버전에 대한 테스트와 검증을 수행합니다. 새로운 버전이 검증을 통과하면 그린 환경이 운영 환경으로 전환되고 블루 환경은 유휴 상태로 유지되지만 롤백을 위해 사용할 수 있습니다.

카나리아 배포에서는 애플리케이션을 전체 사용자에게 배포하기 전에 일부 사용자 그룹(“카나리아”)에게 먼저 배포하여 실제 환경에서 모니터링과 테스트를 수행합니다.

광산에서 카나리아가 유독 가스를 경고하는 데 사용된 것처럼, 카나리아 배포는 모든 사용자에게 영향을 미칠 수 있는 대규모 성능 문제 없이 애플리케이션 결함을 개발 팀에 알려줍니다. 애플리케이션이 카나리아 그룹에서 정상적으로 작동하면 개발자는 점진적으로 더 큰 사용자 그룹으로 배포를 확장하여 결국 전체 사용자에게 제공됩니다.

운영 단계는 실제 사용자와 실제 워크로드 환경에서 시스템이 안정적이고 성능이 뛰어나며 안전하고 가용성을 유지하도록 하는 데 초점을 맞춥니다. 이 단계는 애플리케이션 수명 주기의 “끝”이 아닙니다. 오히려 이 단계는 데이터와 인사이트를 이전 단계로 다시 전달합니다.

이 단계에서 DevOps 팀은 다음과 같은 작업을 수행합니다.

• 운영 환경에서 애플리케이션과 관련 인프라, 서비스 및 의존성을 실행하고 관리합니다.

• 트래픽 흐름이 저하되지 않도록 용량 계획 및 확장 프로세스를 관리합니다.

• 문제를 탐지하고 분류하며 성능 병목을 해결하고 필요에 따라 버그 수정 또는 롤백을 수행합니다.

• 보안 패치를 적용하고 액세스 제어 및 규정 준수 감사와 같은 거버넌스 정책을 시행하여 시스템 보안을 강화합니다.

모니터링 단계에서는 팀이 운영 환경의 애플리케이션과 인프라를 지속적으로 관찰하여 문제를 감지하고 실제 사용자 행동을 이해하며 그 인사이트를 개발 및 운영 단계로 전달합니다.

DevOps 팀은 애플리케이션, 서버, 네트워크 및 데이터베이스에서 지표, 로그 및 추적과 같은 관측 가능성 데이터를 수집하여 성능을 실시간으로 추적합니다. 이들은 임계값과 경고를 설정하여 높은 API 지연이나 의심스러운 액세스 패턴과 같은 이상 징후가 발생하면 신속한 조사와 대응을 위한 알림이 트리거되도록 합니다.

모니터링 툴이 소프트웨어 결함이나 사용성 문제를 발견하면 해당 정보를 이슈 추적 시스템과 백로그로 전달하여 팀이 이후 반복 주기를 조정할 수 있도록 합니다.​

무한 루프에는 “보안” 단계가 명시적으로 포함되어 있지는 않지만 DevOps 파이프라인은 수명 주기 전반에 걸쳐 보안 조치를 포함하는 실무와 기술을 활용합니다.

이 지점에서 DevSecOps가 프레임워크에 포함됩니다.

DevSecOps(개발, 보안 및 운영의 약어)는 보안 프로토콜을 개발 수명 주기의 오른쪽(끝)에서 왼쪽(시작)으로 이동시키는 소프트웨어 개발 실무입니다. 시프트 레프트 방식에서는 개발자가 코드를 작성하는 단계에서 데이터 암호화, 입력 검증, 역할 기반 액세스 제어 및 다중 요소 인증과 같은 보안 프로토콜을 구현합니다.

DevSecOps는 또한 “시프트 라이트” 활동을 포함하여 배포 이후의 운영 환경까지 보안 실무를 확장합니다. 시프트 라이트 실무는 실제 환경에서 런타임 중 애플리케이션을 모니터링하고 테스트하며 보호하는 데 중점을 둡니다. 이들은 운영 환경에서 발견된 보안 문제가 이전 개발 단계에 반영되도록 하는 지속적인 피드백 루프를 형성하여 시프트 레프트 보안을 보완합니다.

시프트 레프트와 시프트 라이트 보안을 함께 활용하면 기업은 DevOps 수명 주기의 모든 단계에 보안 제어를 통합할 수 있습니다. 이중 “시프트 에브리웨어” 보안 전략은 DevOps 팀이 초기 예방과 배포 이후 위협 탐지 및 대응을 모두 구현할 수 있도록 지원하며, 전반적인 보안 태세를 강화하고 지속적인 개선을 촉진합니다.

DevOps 수명 주기는 워터폴 및 애자일과 같은 보다 전통적인 소프트웨어 개발 방식의 발전된 형태를 나타냅니다.

워터폴은 수명 주기의 각 단계(요구사항 수집, 설계, 구현, 테스트, 배포 및 유지보수)가 다음 단계로 넘어가기 전에 완전히 완료되고 승인되어야 하는 선형적이고 순차적인 프로세스를 따르는 개발 방법론입니다. 이 방법론은 선제적 계획, 상세한 문서화 및 예측 가능성을 중시하며, 요구사항이 안정적이고 명확하며 변경이 거의 예상되지 않는 프로젝트(예: 정부 및 의료 관련 프로젝트)에 적합합니다.

워터폴은 강력한 프로세스 통제를 제공하지만 개발 팀이 사일로화되는 단점이 있습니다. 단계가 완료된 이후 변경을 수행하는 것은 비용과 시간이 많이 소요됩니다. 요약하면 워터폴은 민첩성 측면에서 한계가 있습니다.

애자일은 짧은 주기(“스프린트”)를 통해 작고 기능적인 작업 단위를 반복적으로 제공하는 개발 방법론입니다. 이 방법론은 적응형 계획, 조기 전달 및 이해관계자 피드백 기반의 지속적 개선을 중시하며, 개발 팀이 변화하는 요구사항과 환경에 신속하게 대응할 수 있도록 합니다.

애자일 방법론은 스타트업과 같은 변화가 빠른 환경에서 효과적일 수 있습니다. 이 방법론은 소프트웨어 기능을 포괄적인 문서보다 우선시하는 크로스 기능 팀을 통해 워터폴 방식의 선형적 경직성을 완화합니다. 그러나 애자일 방식은 운영 프로세스를 제외하고 소프트웨어 개발 프로세스에 집중하는 경향이 있습니다. 

DevOps는 개발 팀과 운영 팀을 통합하는 현대적인 문화적 및 기술적 실무로, GitLab과 같은 CI/CD 툴을 활용하여 테스트, 배포 및 모니터링을 자동화합니다. 애자일 및 워터폴과 달리 DevOps 실무는 기업이 소프트웨어 릴리스를 가속화하고 오늘날의 매우 동적인 마이크로서비스 아키텍처 및 클라우드 기반 IT 환경에서 성능과 민첩성을 유지하는 애플리케이션을 구축할 수 있도록 지원합니다.

7C는 DevOps 수명 주기를 7개의 지속적인 프로세스의 결과로 개념화하는 또 다른 방식입니다.

지속적 개발은 소프트웨어를 계획하고 코딩하는 과정으로, 개발자가 이를 더 작고 관리 가능한 반복 단위로 나누어 수행합니다. 개발자는 변경 사항을 버전 관리 시스템에 저장하고 코드가 이해관계자 요구사항과 지속적으로 일치하도록 유지하여 팀이 위험을 최소화하고 변화에 빠르게 대응할 수 있도록 합니다.

지속적 통합은 여러 개발자의 코드 변경 사항을 공유 저장소에 병합하고 각 커밋 이후 자동으로 빌드를 트리거합니다. 이를 통해 DevOps 팀은 소프트웨어를 지속적으로 개선하고 일관된 피드백을 받으며 오류가 성능에 영향을 미치기 전에 발견 및 수정하고 더 예측 가능한 일정으로 고품질 소프트웨어를 제공할 수 있습니다.

지속적 테스트는 개발자가 코드 리뷰 및 테스트 프로토콜(예: 단위 테스트)을 자동으로 시작할 수 있도록 합니다. 테스트 툴을 사용하여 통합된 코드를 지속적으로 검사하여 버그, 사용성 문제 및 성능 문제를 식별합니다. 지속적 테스트는 개발자가 수명 주기를 지연시키지 않고 소프트웨어를 개선할 수 있도록 빠른 피드백을 제공합니다.

지속적 전달은 애플리케이션과 검증된 코드베이스 변경 사항(업데이트, 버그 수정 및 신규 기능)을 추가 테스트를 위해 필요한 모든 인프라 환경에 자동으로 전달합니다. 모든 통합 테스트와 검증 단계를 통과한 코드 빌드는 패키징되어 코드 저장소에 전달되며, 이 저장소는 배포 가능한 상태로 코드 패키지를 중앙에서 관리하고 저장합니다.

지속적 배포는 전달 단계를 한 단계 더 확장하여 승인된 모든 변경 사항을 사람의 개입 없이 자동으로 운영 환경에 배포합니다. 코드 업데이트가 테스트되고 검증되며 승인되면 지속적 배포 툴이 소프트웨어 아티팩트를 사전 운영 스테이징 환경 또는 사용자가 액세스할 수 있는 공개 서버 및 배포 플랫폼(예: 애플리케이션 스토어)으로 전달합니다.

지속적 피드백은 DevOps 팀이 모니터링 데이터, 사용자 경험 데이터 및 이해관계자 의견에서 인사이트를 도출하여 제품 백로그를 개선하고 각 개선 사항의 우선순위를 결정하도록 요구합니다.

지속적 모니터링은 애플리케이션과 인프라 성능을 실시간으로 추적하여 문제를 사전에 식별하고 시스템 신뢰성을 유지합니다. 대부분의 모니터링 툴은 대시보드를 통해 CI/CD 파이프라인 데이터를 시각화하여 기술 스택 가시성을 높이고 데이터 기반 최적화를 가능하게 합니다.

자동화 툴은 인프라 프로비저닝, 리소스 확장, 데이터 백업, 트래픽 라우팅 및 시스템 유지보수를 처리하여 DevOps 팀이 새로운 애플리케이션 반복 주기에 지속적으로 피드백을 반영할 수 있도록 합니다.

DevOps 모범 사례를 활용하면 기업은 다음과 같은 다양한 이점을 얻을 수 있습니다.