DORA

DORA 는 팀이 소프트웨어를 빠르고 안정적으로 내보내는지 재는 법을 연구해 알려 줍니다. 배포를 몇 번 하는지, 고친 코드가 서비스에 닿기까지 며칠 걸리는지 같은 값을 정해 둡니다. 이 값들을 지표라고 부릅니다. 팀은 그 지표를 가져다 자기 배포 흐름이 나아지고 있는지 봅니다.

쉽고 빠른 이해

DORA 는 소프트웨어를 내보내는 솜씨를 지표 다섯 개로 재자고 정한 연구입니다. 지표는 배포를 몇 번 했나, 고친 코드가 서비스에 닿기까지 며칠 걸렸나 같은 숫자입니다.

지표가 없으면 "요즘 배포가 빨라졌다"가 느낌으로 끝납니다. 나아졌는지 나빠졌는지 가릴 방법이 없습니다.

어떻게 쓰나:

지표를 두 묶음으로 봅니다. 빨리 내보내나, 내보낸 것이 자주 말썽을 부리나
서비스 하나를 정해 그 서비스의 지표를 꾸준히 잽니다
지난달의 우리 팀과 견줘 나아졌는지 봅니다

대가는 지표가 목표가 되기 쉽다는 것입니다. 지표를 올리라고 다그치면 팀은 일을 고치는 대신 숫자만 맞춥니다.

상세

건강검진을 떠올리면 됩니다. 몸 상태를 통째로 들여다볼 수는 없으니 혈압이나 혈당 같은 수치 몇 개로 가늠합니다. 수치 몇 개가 몸 전체를 말해 주지는 않습니다. 그래도 해마다 재면 어디가 나빠지는지는 보입니다.

DORA 는 DevOps Research and Assessment(데브옵스 연구·평가)의 줄임말입니다. 이름대로 데브옵스를 연구하고 평가하는 연구 프로그램입니다.

데브옵스는 개발하는 사람과 운영하는 사람이 함께 일하는 방식입니다. 코드를 만들어 서비스에 올리는 과정을 한 흐름으로 묶어 다룹니다.

DORA 는 그 방식이 잘 돌아가는지 무엇으로 잴지 파고듭니다. 지금은 Google Cloud 가 이 프로그램을 운영하고, 여러 조직을 조사한 결과를 해마다 State of DevOps Report 라는 보고서로 냅니다. 개발자들이 "DORA" 라고 말할 때는 대개 이 연구가 정한 지표를 가리킵니다.

지표가 필요한 까닭

배포 과정을 고쳤다고 해 봅시다. 테스트를 자동으로 돌리게 했습니다. 이게 팀을 나아지게 했는지 알려면 고치기 전과 뒤를 견줄 지표가 있어야 합니다. 지표가 없으면 "좀 빨라진 것 같다"는 느낌만 남습니다.

DORA 는 무엇을 지표로 삼을지 정했습니다. 코드를 몇 줄 썼나, 기능을 몇 개 만들었나 같은 활동량이 아닙니다. 변경이 서비스에 닿기까지의 결과를 봅니다.

다섯 지표가 함께 재는 것을 소프트웨어 배달 성능이라고 부릅니다. 만든 것을 사용자에게 잘 배달하나를 잰다는 뜻입니다.

연구가 되풀이해 보인 결과도 하나 있습니다. 흔히 빨리 내보내면 그만큼 자주 깨진다고 믿습니다. DORA 의 조사에서는 빨리 내보내면서 잘 깨지지도 않는 팀이 나왔습니다. 둘이 서로 맞바꾸는 관계가 아니라는 것입니다.

다섯 지표

DORA 는 지금 지표 다섯을 씁니다. 다섯은 두 묶음으로 나뉩니다. 처리량은 변경이 막힘없이 흘러가는 정도를 봅니다. 불안정성은 내보낸 변경이 말썽을 일으키는 빈도를 봅니다.

flowchart TD
    D["DORA 지표"] --> T
    D --> I
    subgraph T["처리량"]
        T1["변경 리드 타임"]
        T2["배포 빈도"]
        T3["실패한 배포 복구 시간"]
    end
    subgraph I["불안정성"]
        I1["변경 실패율"]
        I2["배포 재작업률"]
    end

그림에서 실패한 배포 복구 시간이 처리량 쪽에 선 것이 눈에 띕니다. 망가진 배포를 되살리는 동안에는 다음 변경을 내보내기 어렵습니다. 그래서 복구에 걸리는 시간이 짧을수록 변경이 막힘없이 흐른다고 봅니다.

표를 읽기 전에 낱말 하나를 풀어 둡니다. 「곧바로 손대야 하는」 배포는 내보낸 직후 문제가 드러나 급히 조치해야 했던 배포입니다. 변경을 되돌리는 롤백이나 문제를 급히 막는 핫픽스가 그런 조치입니다.

지표	재는 것
변경 리드 타임	변경이 [[버전관리
배포 빈도	일정 기간 동안 배포한 횟수, 또는 배포와 배포 사이의 간격
실패한 배포 복구 시간	곧바로 손대야 하는 실패를 낸 배포에서 되살아나기까지 걸린 시간
변경 실패율	전체 배포 가운데 배포 직후 곧바로 손대야 했던 배포의 비율
배포 재작업률	전체 배포 가운데 계획에 없이 프로덕션 인시던트 때문에 나간 배포의 비율

변경 실패율과 배포 재작업률은 둘 다 전체 배포에 대한 비율입니다. 갈리는 것은 세는 배포입니다. 변경 실패율은 문제를 낸 배포를 세고, 배포 재작업률은 그 문제를 고치러 급히 나간 배포를 셉니다.

지표가 바뀌어 온 과정

연구는 2014년에 시작했습니다. 처음 목표는 IT(Information Technology, 정보 기술) 성과가 조직의 성과와 이어지는지를 과학적으로 밝히는 것이었습니다.

연구진은 배포 빈도, 변경 리드 타임, 평균 복구 시간, 변경 실패율 넷을 후보로 놓았습니다. 평균 복구 시간은 지금의 실패한 배포 복구 시간의 옛 이름입니다. 그해 분석에서 변경 실패율은 나머지 셋과 함께 움직이지 않았습니다. 그래서 첫해에는 소프트웨어 배달 성능을 나머지 세 지표로만 정의했습니다.

그 뒤 해마다 바뀐 것은 아래와 같습니다.

2015년 지표를 두 묶음으로 나눴습니다. 처리량에는 배포 빈도와 변경 리드 타임을, 안정성에는 평균 복구 시간과 변경 실패율을 넣었습니다
2023년 평균 복구 시간을 실패한 배포 복구 시간으로 이름과 정의를 바꿨습니다. 소프트웨어 변경이 낸 실패와 데이터센터 정전 같은 바깥 요인이 낸 장애를 가르려는 것이었습니다
2024년 다섯째 지표인 배포 재작업률을 들였습니다. 실패한 배포 복구 시간은 처리량 묶음으로 옮겼습니다

그래서 지금의 두 묶음은 2015년의 두 묶음과 구성이 다릅니다. 안정성 묶음은 불안정성 묶음이 되었고, 그 안에는 변경 실패율과 배포 재작업률이 남았습니다.

쓸 때 지키는 선

이 지표들은 애플리케이션이나 서비스 하나 단위로 재도록 만들어졌습니다. 성격이 크게 다른 서비스끼리 견주면 잘못 읽힙니다. 하루에 수십 번 배포하는 웹 서비스와 분기마다 내보내는 결제 엔진은 같은 배포 빈도를 기대할 수 없습니다.

견주는 상대도 정해져 있습니다. 목표는 다른 팀이나 다른 회사를 이기는 것이 아니라 자기 팀이 시간이 지나며 나아지는 것입니다.

지표를 조직의 목표치로 못 박는 것도 피합니다. 지표가 평가 기준이 되면 팀이 일을 고치는 대신 숫자를 맞추기 쉽습니다. 예를 들어 배포 빈도를 목표로 걸면 한 번에 나갈 변경을 여러 번으로 쪼개 내보내는 식입니다.

같은 이름의 금융 규제

금융 분야에서 DORA 는 전혀 다른 것을 가리킵니다. 유럽연합(EU, European Union)이 금융 회사의 IT 시스템이 장애와 사이버 공격을 견디도록 정한 규제 Digital Operational Resilience Act 의 줄임말입니다. 이 문서가 다루는 배포 지표 연구와는 이름만 같습니다.

상세

지표가 필요한 까닭

다섯 지표

지표가 바뀌어 온 과정

쓸 때 지키는 선

같은 이름의 금융 규제

관련 항목

DORA 가 정한 지표

지표를 묶는 상위 분류

지표가 재는 배포 흐름의 단계

연구 결과를 싣고 계산하는 도구와 보고서

운영 건강을 재는 이웃 지표

지표를 쓸 때 부딪히는 함정

이름이 비슷해 헷갈리는 지표

이름이 겹치는 금융 규제