데브옵스
더 많은 작업
- DevOps; Development + Operations
- 소프트웨어 개발자와 정보 기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 방법론(기조)
소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 함
- 2007년 벨기에의 프리랜서였던 Patrick Debois가 정부 IDC 마이그레이션 프로젝트에 참여
- 프로젝트 수행 과정에서 개발 조직과 운영 조직 사이에서 고생
- 2009년 O'Reilly Velocity 2009 Conference에서 Flickr에서 개발 조직과 운영조직의 협업과 관련된 "10+ Deploys a Day: Dev and Ops Cooperation at Flickr" 발표
- Patrick Debois가 이에 영감을 받아 2009년 10월 "DevOpsDays"라는 컨퍼런스 개최
- 이후 DevOpsDays는 전세계적으로 확산되고 개발조직과 운영조직의 바람직한 협업과 관련된 각종 발표와 관련하여 #DevOps 라는 해시태그 유행
- devopsdays 공식 사이트에 따르면 첫 행사는 2009년 벨기에 겐트(Ghent)에서 열렸고, Patrick Debois가 창립자로 소개되어 있다.
- Damon Edwards, John Willis, Jez Humble
- Culture
- Automation
- Lean
- Measurement
- Sharing
| 가치 | 뜻 | 실천 예 |
|---|---|---|
| Culture (문화) | 개발과 운영이 책임을 함께 지고, 실패를 비난하지 않고 배우는 문화 | 공동 목표, 비난 없는 사후 검토(blameless postmortem) |
| Automation (자동화) | 빌드, 시험, 배포, 인프라 구성을 사람 손 대신 도구로 반복 가능하게 함 | CI/CD 파이프라인, 코드형 인프라 |
| Lean (린) | 낭비를 줄이고 작은 단위로 자주 전달 | 작은 배치, 짧은 피드백 주기 |
| Measurement (측정) | 전달 성과와 운영 상태를 데이터로 측정 | DORA 메트릭, 서비스 모니터링 |
| Sharing (공유) | 지식·도구·책임을 팀 사이에 공유 | 공용 도구, 문서화, 순환 근무 |
- DevQAOps
- DevSecOps
- DevOpsSec
- BizDevOps
- PrivacyOps
| 구분 | 폭포수 모델 | 애자일 | 데브옵스 |
|---|---|---|---|
| 범위 | 요구사항 → 설계 → 구현 → 시험 → 배포의 순차 단계 | 개발 과정을 짧은 반복으로 나눔 | 개발부터 배포·운영까지 전체 전달 흐름 |
| 주기 | 길다 (단계별 완료 후 다음 단계) | 짧은 반복(스프린트) | 변경 단위로 지속적 배포 |
| 운영 조직 | 개발 완료 후 인계받음 | 대개 별도 조직 | 개발과 한 팀처럼 협업, 운영 책임 공유 |
| 보안 활동 시점 | 단계 끝의 검토·시험에 몰리기 쉬움 | 반복마다 넣을 수 있음 | 파이프라인에 자동화해 변경마다 수행 |
| 변경 대응 | 어렵고 비용이 큼 | 쉬움 | 쉬움, 배포 위험은 자동화와 작은 배치로 낮춤 |
데브옵스는 애자일을 대체하는 것이 아니라, 애자일이 개발 안에서 이룬 짧은 주기를 배포와 운영까지 넓힌 것으로 보는 편이 정확하다. 대규모 조직에서 애자일과 데브옵스를 함께 확장하는 틀로 SAFe가 있다.
데브옵스가 하루에도 여러 번 배포하는 속도를 만들면서, 배포 직전에 보안팀이 한 번 검토하던 방식은 병목이 되거나 아예 생략되기 쉬워졌다. 그래서 보안 활동을 개발·운영 흐름 안에 넣는 데브섹옵스(DevSecOps)가 나왔다. 위 '개념의 확장'의 DevSecOps와 DevOpsSec가 이 흐름이다.
- 시프트 레프트(shift left): 보안 활동을 개발 수명 주기의 앞쪽(왼쪽)으로 옮긴다. 요구사항 단계의 보안 요구사항 정의, 설계 단계의 위협 모델링, 코딩 단계의 IDE 보안 점검과 정적 분석처럼 결함을 일찍 찾을수록 고치는 비용이 적다.
- 파이프라인 보안 점검: CI/CD 파이프라인에 정적 분석(SAST), 소프트웨어 구성 분석(SCA), 비밀 정보 탐지, 컨테이너 이미지 검사, 동적 분석(DAST)을 넣고, 기준을 넘는 결함이 있으면 빌드를 멈춘다. 자세한 도구는 애플리케이션 보안 테스트 참고.
- 파이프라인 자체의 보호: 저장소와 빌드 서버가 뚫리면 모든 배포물이 오염된다. 접근 통제, 빌드 서명, 산출물 무결성 검증, SBOM 생성이 필요하다(개발 환경 보안 참고).
- 운영 단계: 런타임 모니터링, 로그와 경보를 개발팀도 함께 보고, 취약점이 발견되면 같은 파이프라인으로 빠르게 고쳐 배포한다.
- 변경 통제: 자동 배포도 변경 관리의 대상이다. 코드 리뷰와 병합 승인, 파이프라인 기록이 변경 요청·승인 기록 역할을 한다.
NIST SP 800-204C는 마이크로서비스 기반 클라우드 네이티브 애플리케이션에서 데브섹옵스를 구현하는 방법을, NIST SP 800-218(SSDF)은 개발 방식과 관계없이 적용할 보안 개발 실천 항목을 다룬다.
데브옵스 성과는 감이 아니라 지표로 본다. 구글의 DORA(DevOps Research and Assessment) 연구가 제시한 소프트웨어 전달 성과 지표가 널리 쓰인다. DORA는 원래 네 가지 핵심 지표(four keys)로 시작했으며, 현재 공식 안내는 다섯 가지 지표를 처리량(throughput)과 불안정성(instability)으로 나누어 설명한다.
| 구분 | 지표 | 의미 |
|---|---|---|
| 처리량 | 변경 리드 타임 (change lead time) | 버전 관리에 커밋된 변경이 운영에 배포되기까지 걸린 시간 |
| 처리량 | 배포 빈도 (deployment frequency) | 일정 기간 동안의 배포 횟수 |
| 처리량 | 실패한 배포 복구 시간 (failed deployment recovery time) | 즉시 조치가 필요한 실패 배포에서 복구하는 데 걸린 시간 |
| 불안정성 | 변경 실패율 (change fail rate) | 배포 후 즉시 조치(롤백, 긴급 수정)가 필요했던 배포의 비율 |
| 불안정성 | 배포 재작업률 (deployment rework rate) | 운영 사고 때문에 계획에 없이 이루어진 배포의 비율 |
DORA는 속도와 안정성이 서로 맞바꾸는 관계가 아니라 함께 좋아지는 경향이 있다고 보고한다. 자세한 내용은 DORA 메트릭 참고.
- 데브옵스는 개발과 운영의 협업, 자동화, 지속적 배포를 강조한다. 보안을 그 흐름에 넣은 것이 데브섹옵스이다.
- 시프트 레프트는 보안 활동을 수명 주기 앞쪽으로 옮겨 결함을 일찍, 싸게 고치는 것이다.
- 빠른 배포 환경에서도 변경 관리와 직무 분리는 필요하다. 자동화된 파이프라인 승인·기록이 그 수단이 된다.
- 폭포수는 순차 단계, 애자일은 짧은 반복, 데브옵스는 개발부터 운영까지의 지속적 흐름으로 구분한다.
- CI/CD 파이프라인 자체가 공격 대상이다. 저장소·빌드 서버 보호와 산출물 무결성 검증을 고른다.