본문으로 이동
메뉴 여닫기
환경 설정 메뉴 여닫기
개인 메뉴 여닫기
로그인하지 않음
지금 편집한다면 당신의 IP 주소가 공개될 수 있습니다.
(DevOps에서 넘어옴)
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가 창립자로 소개되어 있다.

핵심 가치 CALMS

편집 원본 편집
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 지표

편집 원본 편집

데브옵스 성과는 감이 아니라 지표로 본다. 구글의 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 파이프라인 자체가 공격 대상이다. 저장소·빌드 서버 보호와 산출물 무결성 검증을 고른다.