맨위로가기

데브옵스

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

데브옵스(DevOps)는 개발(Development)과 운영(Operations)의 합성어로, 소프트웨어 개발자와 IT 운영 팀 간의 협업과 자동화를 통해 제품 출시 기간을 단축하고 서비스 품질을 향상시키는 것을 목표로 한다. 2000년대 후반 소프트웨어 개발 및 IT 커뮤니티에서 개발과 운영의 분리로 인한 문제 제기에서 시작되었으며, 2009년 벨기에에서 열린 DevOpsDays 컨퍼런스를 통해 널리 알려졌다. 데브옵스는 애자일 방법론, 린 생산 방식, 사이트 신뢰성 엔지니어링(SRE) 등에서 영감을 받았으며, 린, 애자일, DevSecOps와 같은 다양한 접근법과 깃(Git), 젠킨스(Jenkins), 도커(Docker) 등의 툴체인을 활용한다. 데브옵스는 릴리스 관리, 자동화, 모니터링을 통해 제품 출시 시간 단축, 릴리스 실패율 감소, 복구 시간 단축 등의 효과를 가져오지만, 조직 문화의 변화를 수반하며, DORA 지표를 통해 성과를 측정한다.

더 읽어볼만한 페이지

  • 애자일 소프트웨어 개발 - 유스 케이스
    유스 케이스는 시스템과 액터 간 상호작용을 통해 시스템 목표 달성에 기여하는 동작들을 나타내는 요구 사항 캡처, 모델링, 명세 기법으로, 객체 지향 소프트웨어 공학에서 기능 요구 사항을 캡처하는 데 중요한 역할을 하며 다양한 분야에서 활용된다.
  • 애자일 소프트웨어 개발 - 스크럼 (애자일 개발 프로세스)
    스크럼은 제품 개발을 위해 반복적, 점진적 접근 방식을 사용하는 애자일 소프트웨어 개발 방법론의 프레임워크로, 제품 책임자, 개발자, 스크럼 마스터로 구성된 팀을 중심으로 투명성, 검사, 적응의 원칙을 따른다.
  • 소프트웨어 개발 프로세스 - 버전 관리
    버전 관리는 파일 변경 이력을 체계적으로 관리하는 시스템이며, 다양한 구조와 소스 관리 모델을 통해 협업을 지원하고, 비즈니스 등 다양한 분야에서 활용된다.
  • 소프트웨어 개발 프로세스 - 소프트웨어 개발 수명 주기
    소프트웨어 개발 수명 주기(SDLC)는 시스템 설계자와 개발자가 따르는 일련의 단계로, 예비 분석부터 폐기까지 여러 단계를 거치며, 폭포수 모델, 시스템 분석 및 설계(SAD), 객체 지향 분석 및 설계(OOAD) 등 다양한 방법론을 포함한다.
  • 정보 기술 관리 - 전사적 자원 관리
    전사적 자원 관리(ERP)는 기업의 자원과 업무 프로세스를 통합하여 효율성을 높이는 시스템이며, 재무, 인사, 제조, 공급망 관리 등 다양한 기능을 다루고, 기업의 의사 결정, 투명성, 세계화를 지원한다.
  • 정보 기술 관리 - 고객 지원
    고객 지원은 기업이 고객의 문의, 불만, 문제 해결 요청 등에 대응하는 활동으로, 자동화와 다양한 방식을 통해 효율성을 높여 고객 만족도 및 충성도를 강화하는 데 기여한다.
데브옵스
DevOps 개요
명칭DevOps (데브옵스)
정의소프트웨어 개발 방법론 및 문화적 변화
특징개발(Development)과 운영(Operations) 간의 협업 및 통합 강조
DevOps 상세
목표소프트웨어 제품 개발 및 배포 속도 향상, 안정성 및 품질 향상
핵심 원칙협업 강화
자동화
지속적인 개선
고객 중심
주요 활동지속적 통합 (CI)
지속적 전달 (CD)
인프라 자동화 (Infrastructure as Code)
모니터링 및 피드백
관련 기술컨테이너 (Docker)
쿠버네티스
클라우드 컴퓨팅
구성 관리 도구 (Ansible, Chef, Puppet)
지속적 통합 도구 (Jenkins, GitLab CI)
DevOps 장점
개발 속도 향상자동화를 통해 개발 및 배포 시간 단축
안정성 향상지속적인 테스트 및 모니터링을 통해 오류 감소
협업 강화개발팀과 운영팀 간의 원활한 소통
고객 만족도 향상빠른 릴리스 주기를 통해 고객 요구사항에 신속하게 대응
DevOps 단점
초기 도입 비용자동화 시스템 구축 및 팀 교육에 투자 필요
문화적 변화 필요조직 전체의 협업 문화 정착 중요
보안 문제자동화된 시스템의 보안 취약점 관리 필요
관련 정보
관련 기술Infrastructure as code

2. 정의

데브옵스(DevOps)는 개발(Development)과 운영(Operations)의 혼성어로, 소프트웨어 개발자와 IT 운영 팀 간의 유기적인 협력과 자동화를 통해 제품 출시 기간(time to market)을 단축하고 서비스 품질을 향상시키는 것을 목표로 한다.[66] 학계와 실무에서는 데브옵스에 대한 보편적인 정의가 아직 확립되지 않았지만,[4][5][6] 공유된 소유권, 워크플로우 자동화, 신속한 피드백 등의 핵심 원칙을 공유한다.[8]

렌 배스, 잉고 웨버, 리밍 주는 데브옵스를 "시스템에 변경 사항을 커밋하는 것과 해당 변경 사항을 정상적인 프로덕션 환경에 적용하는 시간 사이를 줄이면서 높은 품질을 보장하기 위한 일련의 실천 방법"으로 정의할 것을 제안했다.[7][55]

3. 역사

소프트웨어 개발 방법론과 배포 및 운영 개념을 결합하려는 제안은 1980년대 후반과 1990년대 초반에 나타나기 시작했다.[9]

2007년과 2008년경, 소프트웨어 개발 및 IT 커뮤니티 내에서, 소프트웨어를 작성하고 생성하는 부문과 소프트웨어를 배포하고 지원하는 부문이 완전히 분리되어 산업 내에 치명적인 수준의 기능 장애를 초래한다는 우려가 제기되었다.[10]

2008년 애자일 컨퍼런스에서 앤드루 클레이 셰퍼와 패트릭 드부아가 "애자일 인프라스트럭처"에 대해 논의했다. 그리고 DevOps라는 용어는 2009년 벨기에에서 처음 개최된 "DevOpsDays"에서 널리 퍼졌으며, 이후 전 세계 많은 국가에서 "DevOpsDays" 컨퍼런스가 개최되고 있다.[57]

2009년, 최초의 데브옵스 데이즈(DevOps Days) 컨퍼런스가 벨기에 겐트에서 개최되었다. 이 컨퍼런스는 벨기에 컨설턴트, 프로젝트 매니저이자 애자일 실무자인 패트릭 드부아(Patrick Debois)가 설립했다.[11][12] 이 컨퍼런스는 현재 다른 국가로 확산되었다.[13]

2012년, 퍼펫 랩스의 알라나 브라운(Alanna Brown)이 "데브옵스의 현황(State of DevOps)"이라는 보고서를 처음으로 발표했다.[14][15]

2014년 기준으로, 연례 "데브옵스의 현황" 보고서는 니콜 포르스그렌, 진 킴, 제즈 험블 등에 의해 발표되었다. 그들은 데브옵스의 채택이 가속화되고 있다고 밝혔다.[16][17] 또한 2014년, 리사 크리스핀과 자넷 그레고리는 테스팅과 데브옵스에 관한 챕터를 포함한 "더 많은 애자일 테스팅(More Agile Testing)"이라는 책을 저술했다.[18][19]

2016년, 처리량(배포 빈도, 변경 소요 시간)과 안정성(평균 복구 시간, 변경 실패율)에 대한 DORA 지표가 "데브옵스의 현황" 보고서에 발표되었다.[14] 그러나, 이 연구 방법론과 지표는 전문가들의 비판을 받았다.[20][21][22][23] 이러한 비판에 대한 대응으로, 2023년 "데브옵스의 현황" 보고서[24]는 이전 지표가 야기한 혼란을 인지하여 안정성 지표 "평균 복구 시간"을 "실패한 배포 복구 시간"으로 업데이트하는 변경 사항을 발표했다.[25]

3. 1. 한국에서의 데브옵스 역사

한국에서는 2010년대 초반부터 대기업과 스타트업을 중심으로 데브옵스 도입이 시작되었다. 초기에는 주로 해외 솔루션을 도입하거나 자체적으로 도구를 개발하여 적용하는 방식으로 진행되었다. 2010년대 중반 이후, 클라우드 컴퓨팅 확산과 함께 데브옵스 도입이 가속화되었으며, 국내 기업들도 자체적인 데브옵스 플랫폼 및 솔루션을 개발하기 시작했다. 현재는 금융, 통신, 제조, 공공 등 다양한 산업 분야에서 데브옵스 도입이 확산되고 있으며, 정부 차원에서도 데브옵스 확산을 위한 지원 정책을 추진하고 있다.

4. 목적

데브옵스는 운영 프로세스의 예측 가능성, 효율성, 보안, 유지보수 가능성을 극대화하는 것을 목표로 한다.[66] 자동화는 이러한 목표를 지원하는 중요한 수단이다.[66]

데브옵스의 통합은 제품 출시, 지속적인 테스트, 품질 테스트, 기능 개발 또는 유지보수 릴리스를 대상[62]으로 하며, 다음과 같은 목표를 가진다.


  • 제품 출시까지 걸리는 기간(time to market) 단축[66][62]
  • 새로운 판의 더 낮은 실패율[66][62]
  • 픽스 간 짧아진 리드 타임(상품 생산 시작부터 완성까지 걸리는 시간)[66][62]
  • 복구 시 더 빠른 평균 시간 (새로운 릴리스의 충돌 및 그 밖에 현재의 시스템를 비활성화하는 상황에서)[66][62]


단순한 프로세스들은 데브옵스 접근을 사용하여 더 프로그래밍 가능하게 되고 유동적으로 되고 있다.[66] 개발 환경을 표준화함으로써, 데브옵스는 조직의 소프트웨어 애플리케이션 릴리스 관리를 지원한다. 릴리스 이벤트를 쉽게 추적할 수 있으며, 문서화된 프로세스 제어와 상세한 보고서 문제를 해결할 수 있다. 데브옵스 접근 방식을 통해, 개발자는 환경을 보다 자세하게 제어할 수 있으며, 인프라를 통해 애플리케이션 중심적인 이해를 반영할 수 있다.

DevOps를 시도하는 회사 및 조직에서는 다음과 같은 큰 이점을 보고하고 있다.

  • 시장 출시 시간 단축
  • 높은 고객 만족도
  • 개선된 제품 품질
  • 개선되고 신뢰성 높은 릴리스
  • 향상된 생산성 및 효율성
  • 빠른 실험을 통한 적절한 제품 구축 능력

5. 핵심 원칙 및 관련 접근법

데브옵스(DevOps)의 기본 아이디어 중 다수는 린 및 데밍의 계획-실행-확인-조치 사이클, 도요타 방식에 이르기까지 구성 요소 및 배치 크기를 세분화하는 애자일 접근 방식과 유사하거나 이에서 영감을 받았다.[28] 1990년대 ITIL의 "탑다운" 규범적 접근 방식 및 엄격한 프레임워크와 달리, 데브옵스는 소프트웨어 엔지니어가 자체 요구 사항에 맞춰 만든 "바텀업" 방식이며 유연하다.[29]

특정 부서(또는 개인)의 성과가 아닌 시스템 전체의 성과에 중점을 둔다. 초점은 IT를 다루는 모든 비즈니스 가치 흐름에 있다. 이 프로세스는 선형적으로 흐르므로 결함이 통과하지 않도록 보장한다.

관련된 모든 팀의 피드백과 이해를 향상시키는 데 중점을 둔다. 그 결과 고객(내부 및 외부)과의 소통과 응답을 개선하고, 피드백 루프를 단축, 증폭하며, 지식을 필요한 곳에 전달한다.

실험과 실천은 마찬가지로 중요하다. 리스크로부터 배우는 것, 반복, 또는 연습을 직장 문화에 통합하는 것은 숙련의 열쇠이다. 리스크를 감수하고 실험하거나, 개선과 습득을 촉진함으로써, 실수를 만회하기 위해 필요한 기술을 습득할 수 있다.

5. 1. 애자일(Agile)

현대 데브옵스는 1990년대 비공식적으로, 2001년에 공식적으로 시작된 애자일 소프트웨어 개발에서 비롯되었다.[30] 자동 빌드 및 테스트, 지속적 통합, 지속적 전달과 같은 여러 표준 데브옵스 관행이 애자일 방법론에서 나왔다. 익스트림 프로그래밍과 같은 방법을 사용하던 애자일 개발팀은 운영 및 인프라에 대한 책임을 지고 작업의 많은 부분을 자동화해야 했다.[30] 2000년대 초반, 스크럼이 지배적인 애자일 프레임워크로 부상하면서 운영 및 인프라 자동화 움직임은 애자일에서 분리되어 현대 데브옵스로 확장되었다.

DevOps와 린 생산 방식은 배경으로 하고 있기 때문에 DevOps와 지속적 전달은 종종 혼동된다. 비슷하지만, 서로 다른 개념이다.[61] DevOps는 조직 개혁을 통해 소프트웨어 전달과 관련된 팀(개발, IT 운영, 품질 보증・QA, 관리 등)의 협력을 증진하고, 소프트웨어 전달 프로세스를 자동화한다.[61] 지속적 전달은 전달 프로세스를 자동화하여 다양한 프로세스를 신속하고 빈번하게 실행하는 것을 목표로 한다. DevOps와 지속적 전달은 공통의 목표를 달성하기 위해 함께 사용되기도 한다.

작은 변경 사항을 빈번하게 릴리스하는 애자일 소프트웨어 개발에서는 개발 담당자와 운영 담당자의 긴밀한 연계가 필요하며, 이러한 개발 방법의 보급과 함께 DevOps의 개념이 확산되었다. DevOps의 목표 중 하나는 더욱 신뢰성 높은 앱이 더 빠르고 빈번하게 릴리스되는 환경을 만드는 것이다. 이 목표를 달성하기 위해 릴리스 관리자는 지속적인 딜리버리 방법을 채택하고, 애플리케이션 릴리스 자동화나 지속적인 통합 도구 등을 활용한다.

5. 2. 린(Lean)

린 생산 방식은 낭비 제거, 지속적인 개선, 빠른 피드백을 강조하며, 데브옵스의 효율성 향상에 기여한다. 도요타 생산 방식은 린 사고의 영감이 되었으며, 지속적 개선, 개선, 흐름 및 소량 생산에 중점을 둔다. 특히, 문제 해결을 위해 신속한 피드백을 생성하는 안돈 코드 원칙은 도요타 생산 방식에서 비롯되었다.

5. 3. 사이트 신뢰성 엔지니어링(SRE)

구글은 우수한 최종 사용자 경험을 유지하면서 대규모 고가용성 시스템에 새로운 기능을 지속적으로 출시하기 위한 접근 방식인 사이트 신뢰성 엔지니어링(SRE)을 2003년에 개발했다.[35] SRE는 데브옵스 개발보다 먼저 나왔지만, 일반적으로 서로 관련이 있는 것으로 간주된다. 이 분야의 원래 저자 중 일부는 SRE를 데브옵스의 구현으로 여긴다.[36]

5. 4. DevSecOps

'''DevSecOps'''는 데브옵스(DevOps)를 확장하여 보안 관행을 데브옵스 접근 방식에 통합한 것이다. 전통적인 중앙 집중식 보안 팀 모델과 달리, 각 전달 팀은 소프트웨어 전달에 적절한 보안 제어를 포함할 수 있다. 보안 관행과 테스트는 개발 수명 주기 초기에 수행되므로 "시프트 레프트"라는 용어가 사용된다.[40] 보안은 정적, 소프트웨어 구성 요소, 동적의 세 가지 주요 영역에서 테스트된다.

정적 애플리케이션 보안 테스트(SAST)를 통한 소프트웨어 정적 검사는 보안에 특별히 초점을 맞춘 화이트 박스 테스트이다. 프로그래밍 언어에 따라 이러한 정적 코드 분석을 수행하는 데 다른 도구가 필요하다. 소프트웨어 구성 요소, 특히 라이브러리를 분석하고 각 구성 요소의 버전을 CERT 및 기타 전문가 그룹에서 게시한 취약성 목록과 대조하여 확인한다. 고객에게 소프트웨어를 제공할 때 라이브러리 라이선스 및 배포된 소프트웨어의 라이선스와의 일치 여부가 중요하며, 특히 카피레프트 라이선스가 중요하다.

블랙 박스 테스트라고도 하는 동적 테스트에서 소프트웨어는 내부 기능을 알지 못한 채 테스트된다. DevSecOps에서는 이 관행을 동적 애플리케이션 보안 테스트(DAST) 또는 침투 테스트라고 할 수 있다. 목표는 크로스 사이트 스크립팅 및 SQL 삽입 취약성을 포함한 결함을 조기에 감지하는 것이다. 위협 유형은 오픈 웹 애플리케이션 보안 프로젝트 (예: TOP10)[39] 및 기타 기관에서 게시한다.

DevSecOps는 보안 교육, 설계에 따른 보안 및 보안 자동화를 통합하여 안전한 소프트웨어를 생산하는 전체론적 접근 방식을 포함하는 문화적 변화로도 설명되어 왔다.[40]

6. 데브옵스 툴체인

데브옵스는 특정 도구를 지칭하는 것이 아니라, 여러 도구로 구성된 "데브옵스 툴체인"을 활용한다. 데브옵스 툴체인은 소프트웨어 개발 및 배포 프로세스의 각 단계를 지원하며, 다음과 같은 범주로 분류된다.[58][59]

DevOps와 아키텍처

  • 코드: 코드 개발 및 검토, 버전 관리 도구, 코드 병합
  • 빌드: 지속적 통합(CI) 도구, 빌드 상태
  • 테스트: 성능을 결정하기 위한 테스트 및 결과
  • 패키징: 아티팩트 저장소, 앱 배포 전 스테이징
  • 릴리스: 변경 관리, 릴리스 승인, 릴리스 자동화
  • 구성: 인프라 설정 및 관리, 코드형 인프라 도구
  • 모니터링: 애플리케이션 성능 모니터링, 최종 사용자 경험


데브옵스 연구원 라비 테자 야를라가다(Ravi Teja Yarlagadda)는 "데브옵스를 통해 모든 기능이 단순한 코드를 사용하여 중앙에서 수행, 제어 및 관리될 수 있다는 가정이 있습니다."라고 가설을 세웠다.[47]

데브옵스의 실현에는 구성 관리 도구인 Docker (컨테이너화), Jenkins (지속적 통합), Puppet (코드형 인프라), 또는 Vagrant (가상화 플랫폼) 등이 사용되기도 한다.[60]

6. 1. 주요 도구 (한국 사례 포함)

데브옵스는 소프트웨어 개발과 운영을 통합하여 효율성을 높이는 방법론으로, 다양한 도구를 활용한다. 주요 도구는 다음과 같다.[32][33][47]
버전 관리: Git, GitHub, GitLab 등을 통해 코드 변경 사항을 추적하고 관리한다. 이를 통해 여러 개발자가 동일한 코드베이스에서 작업할 때 발생할 수 있는 충돌을 방지하고 코드베이스 기록을 유지할 수 있다.[48]
CI/CD (지속적 통합/지속적 배포): Jenkins, GitLab CI, Jenkins X, CircleCI 등을 사용하여 빌드, 테스트, 배포 과정을 자동화한다.
컨테이너화: Docker, Kubernetes 등을 통해 애플리케이션을 격리된 환경에서 실행하고 관리한다.
구성 관리: Ansible, Puppet, Chef 등을 사용하여 인프라스트럭처 구성을 자동화하고 관리한다. IaC(Infrastructure as Code) 도구를 활용한다.
모니터링: Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana) 등을 통해 애플리케이션 성능을 모니터링하고 문제를 진단한다.

7. 문화적 변화

데브옵스(DevOps)는 기업의 IT 운영과 소프트웨어 개발자, 소프트웨어 테스팅 담당자들이 개발 및 배포 과정에서 협업하는 방식을 변화시켜 기업의 문화적 변화를 창출할 수 있다.[42] 이러한 집단들이 함께 유기적으로 일하도록 만드는 것은 기업의 데브옵스 도입에 있어 매우 중요한 과제이다.[43][44] 데브옵스는 툴체인 만큼이나 문화에 관한 것이기도 하다.[45]

DevOps를 실현하기 위해서는 단순한 도구나 프로세스의 변경뿐만 아니라, 본질적인 조직 문화의 전환이 필요하다. 각 부서가 가진 역할과 성격이 상반되므로, 조직 문화의 변화는 특히 어렵다.


  • 운영 담당자는 조직의 안정을 추구한다.
  • 개발자는 변화를 추구한다.
  • 테스터는 위험 감소를 추구한다.


DevOps의 원칙은 강력한 부서 간의 의사 소통을 요구하기 때문에, 팀 빌딩 및 기타 직원 참여 활동이 자주 활용된다. 팀 빌딩 활동에는 보드 게임, 신뢰 활동, 직원 참여 세미나 등이 있다. 강력한 부서 간의 의사 소통을 길러 문화 변화를 촉진하는 환경을 만들 수 있다.

매우 많은 릴리스를 가진 기업에서는 데브옵스(DevOps)의 의식 고취 프로그램이 필요할 수 있다. 예를 들어, 데브옵스라는 단어는 2009년 오라일리가 주최한 이벤트 "Velocity 2009"에서 이미지 호스팅 웹사이트 Flickr의 엔지니어에 의해 처음으로 공적인 자리에서 사용되었다. 이 프레젠테이션에서는 "개발과 운영이 협력함으로써 하루에 10번 이상의 속도로 릴리스가 가능해진다"라는 발표와 함께 데브옵스라는 단어가 사용되었다. 매일의 배포 사이클은 멀티 포커스 또는 멀티 펑션 애플리케이션을 만드는 조직에서 많을 것이다. 그것은 지속적인 배포 또는 지속적인 딜리버리라고 불리며, 린 스타트업 방법론과 연관되어 있다. 2009년 회의 이후, 워킹 그룹, 전문적인 협회 및 블로그에서 화제가 되고 있다.

8. 도입 시 고려 사항

데브옵스 도입은 조직의 IT 부서 외에도 데브옵스 이니셔티브에 중요한 참여가 필요하다고 권고하는 기사가 있다. "DevOps는 기업 전체에 적용된 애자일 원칙이다"라는 메시지가 있다.[64] 또 다른 광범위한 참여의 예로는 내부 자금 조달 프로세스 변경이 있다. "자금 조달은 일반적으로 폭포수 방식으로 제공된다. 그러나 지속적 딜리버리 모델에는 적합하지 않은 확정 날짜(월, 분기, 회계 연도 등)라는 관문이 있으므로 자금 조달도 지속적이어야 한다."[65]

데브옵스 도입은 다음과 같은 여러 요소에 의해 추진되고 있다.


  • 애자일과 같은 개발 프로세스 및 방법 사용
  • (애플리케이션 및 비즈니스 유닛 관계자로부터의) 프로덕션 릴리스 증가에 대한 수요
  • (내부 및 외부 제공자로부터의) 가상 및 클라우드 인프라의 광범위한 사용 가능성
  • 데이터 센터 자동화 및 구성 관리 도구 사용 증가
  • 테스트 자동화 및 지속적 통합 방법의 중점
  • 공개된 방대한 최선의 조치


제약 조건 이론은 데브옵스 도입에 적용된다. 단일 제약은 기업 내 부서의 변화에 대한 선천적인 혐오감이다. 증분 도입에서는 제약 이론의 방법론을 구현하고 "5가지 초점 단계"로 알려진 제약을 극복하기 위한 단계를 제공한다.

증분 도입 방식은 기업 전체에 광범위한 구현을 성공시키기 위해 필요한 사내 기술과 추진력을 구축하면서 데브옵스 도입의 위험과 비용을 최소화한다는 생각을 중심으로 한다. 진 킴(Gene Kim)의 "세 가지 기본 원칙"은 다양한 방식으로 데브옵스를 증분 적으로 도입하고 있다.

9. 관련 지표

DORA (DevOps Research and Assessment) [측정 지표](https://cloud.google.com/devops/capabilities/metrics)는 소프트웨어 개발 효율성과 신뢰성을 측정하는 데 도움이 되는 핵심 지표 집합이다.


  • 배포 빈도: 코드 배포 간의 시간.
  • 변경 소요 시간: 코드 커밋과 배포 사이의 시간.
  • 변경 실패율: 프로덕션 문제를 일으키는 배포의 비율.
  • 평균 복구 시간: 프로덕션 문제를 해결하는 데 걸리는 시간.
  • 신뢰성(2021년 추가): 운영 성능을 측정하며, 가용성 및 사용자 기대치 준수에 중점을 둔다.


이러한 지표는 적절하게 관련 컨텍스트 내에서 적용될 때 데브옵스 [성과](https://cloud.google.com/devops/capabilities/performance)에 대한 통찰력을 제공하여 팀이 배포 속도, 신뢰성 및 품질을 최적화하여 소프트웨어 개발 프로세스를 개선하기 위한 데이터 기반 의사 결정을 내릴 수 있도록 한다.

10. 비판 및 한계

참조

[1] 웹사이트 What Is DevOps? The Ultimate Guide https://www.techtarg[...] 2023-01-22
[2] 서적 Fundamentals of Software Architecture: An Engineering Approach O'Reilly Media
[3] 서적 Building Evolutionary Architectures: Automated Software Governance
[4] 서적 2015 IEEE/ACM 3rd International Workshop on Release Engineering IEEE 2015-05-19
[5] 간행물 What is DevOps?: A Systematic Mapping Study on Definitions and Practices Association for Computing Machinery 2016-05
[6] 간행물 A Qualitative Study of DevOps Usage in Practice https://ris.utwente.[...] 2017-06
[7] 서적 DevOps: A Software Architect's Perspective Addison-Wesley
[8] 간행물 A guidance to implement or reinforce a DevOps approach in organizations: A case study 2021-04
[9] 문서 Chapman, M., Gatti, N: A model of a service life cycle, Proceedings of TINA '93, pp. I-205–I-215, Sep., 1993.
[10] 웹사이트 History of DevOps https://www.atlassia[...] 2023-02-23
[11] 웹사이트 The Origins of DevOps: What's in a Name? https://devops.com/t[...] devops.com 2019-05-06
[12] 웹사이트 Agile 2008 Toronto http://www.jedi.be/b[...] Just Enough Documented Information 2015-03-12
[13] 웹사이트 DevOps Days http://www.devopsday[...] DevOps Days 2011-03-31
[14] 웹사이트 2016 State of DevOps Report https://dora.dev/res[...] Puppet Labs, DORA (DevOps Research 2024-04-24
[15] 웹사이트 Puppet - Alanna Brown https://puppet.com/p[...] Puppet Labs 2019-04-27
[16] 웹사이트 2014 State of DevOps Report https://dora.dev/res[...] Puppet Labs, IT Revolution Press and ThoughtWorks 2024-04-24
[17] 웹사이트 2015 State of DevOps Report https://dora.dev/res[...] Puppet Labs, Pwc, IT Revolution Press 2024-04-24
[18] 웹사이트 More Agile Testing https://agiletester.[...] 2019-05-06
[19] 서적 More Agile Testing https://www.oreilly.[...] Addison-Wesley 2019-05-06
[20] 뉴스 Report: Software Engineers Face Backlash for Reporting Wrongdoing https://www.digit.fy[...] 2024-01-05
[21] 뉴스 Software engineers worry about speaking out - Computer Weekly https://www.computer[...] 2024-01-05
[22] 뉴스 75% of software engineers faced retaliation the last time they reported wrongdoing - ETHRWorldSEA https://hrsea.econom[...]
[23] 웹사이트 Holly Cummins on X https://twitter.com/[...] 2024-01-05
[24] 웹사이트 2023 State of DevOps Report https://cloud.google[...] Google Cloud DevOps Research and Assessment 2024-04-24
[25] 웹사이트 2023 State of DevOps Report: Culture is everything https://cloud.google[...] 2024-04-24
[26] 서적 Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
[27] 간행물 DORA Accelerate State of DevOps 2021 2021
[28] 간행물 The DevOps: A Concise Understanding to the DevOps Philosophy and Science https://www.osti.gov[...] 2021-05-01
[29] 웹사이트 The History and Evolution of DevOps {{!}} Tom Geraghty https://tomgeraghty.[...] 2020-11-29
[30] 웹사이트 Principles behind the Agile Manifesto https://agilemanifes[...] 2020-12-06
[31] 서적 Software Architecture 2018-09-15
[32] 서적 Continuous Delivery: reliable software releases through build, test, and deployment automation Pearson Education Inc. 2011
[33] 간행물 Continuous Delivery: Huge Benefits, but Challenges Too
[34] 서적 Mobile DevOps: Deliver continuous integration and deployment within your mobile applications Packt Publishing 2018
[35] 서적 Site Reliability Engineering O'Reilly Media 2016-04
[36] 웹사이트 Interview with Betsy Beyer, Stephen Thorne of Google https://driftboatdav[...] 2018-10-09
[37] 기사 Analyzing the DNA of DevOps https://opensource.c[...] 2018-11-14
[38] 서적 The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations 2016
[39] 웹사이트 OWASP TOP10 https://owasp.org/To[...] 2023-06-08
[40] 서적 'DevSecOps: A leader''s guide to producing secure software with compromising flow, feedback and continuous improvement' Rethink Press 2020-12
[41] 보고서 Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology Gartner
[42] 웹사이트 What is DevOps? http://radar.oreilly[...] O'Reilly Media 2012-06-07
[43] 웹사이트 Gartner IT Glossary {{ndash}} devops http://www.gartner.c[...] 2015-10-30
[44] 서적 Proceedings of the 2nd International Workshop on Quality-Aware DevOps - QUDOS 2016 https://ueaeprints.u[...] 2016-07-21
[45] 웹사이트 Building a DevOps culture https://www.oreilly.[...] O'Reilly 2015-09-25
[46] 컨퍼런스 2014 IEEE/IFIP Conference on Software Architecture IEEE 2014
[47] SSRN DevOps and Its Practices 2021-03-09
[48] 학위논문 DevOps: development of a toolchain in the banking domain https://webthesis.bi[...] 2021-04-16
[49] 웹사이트 What is GitOps? https://www.redhat.c[...] 2023-03-30
[50] 서적 Serverless Architectures on AWS Manning
[51] 서적 Pipeline as Code Continuous Delivery with Jenkins, Kubernetes, and Terraform Manning
[52] 서적 Continuous Delivery Reliable Software Releases Through Build, Test, and Deployment Automation
[53] 웹사이트 ITproまとめ - DevOps https://xtech.nikkei[...] 日経BP|ITpro 2013-11-15
[54] 웹사이트 いまさら聞けない「DevOps」 https://atmarkit.itm[...] ITmedia|@IT 2013-07-02
[55] 서적 DevOps: A Software Architect's Perspective
[56] 웹사이트 Surprise! Broad Agreement on the Definition of DevOps https://devops.com/s[...] 2015-05-13
[57] 웹사이트 キーワード「DevOps」 https://xtech.nikkei[...] 日経BP|ITpro 2013-09-18
[58] 웹사이트 Integrating DevOps tools into a Service Delivery Platform http://dev2ops.org/2[...]
[59] 웹사이트 Exploring the ENTIRE DevOps Toolchain for (Cloud) Teams http://www.infoq.com[...]
[60] 웹사이트 ［運用を自動化する「Chef」］Rubyベースの手順書で管理 https://xtech.nikkei[...] 日経BP|ITpro 2013-09-17
[61] 웹사이트 Agile Infrastructure http://www.infoq.com[...] InfoQ
[62] 웹사이트 Gartner IT Glossary {{ndash}} devops http://www.gartner.c[...]
[63] 컨퍼런스 Towards Architecting for Continuous Delivery https://doi.org/10.1[...] IEEE
[64] 웹사이트 DevOps is Agile for the Rest of the Company https://devops.com/d[...] DevOps.com
[65] 학술지 10 Ways DevOps is Changing the Enterprise http://www.datamatio[...] 2017-01-09
[66] 웹인용 What is DevOps? http://newrelic.com/[...] NewRelic.com 2014-10-21


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com