DORA

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

쉽고 빠른 이해

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

잴 방법이 없으면 배포 과정을 고친 뒤에 나아졌는지 확인할 길이 없습니다. 코드 줄 수 같은 작업량은 늘려도 성과가 나아졌다는 뜻이 아닙니다.

어떻게 쓰나:

1. 지표 두 묶음을 함께 봅니다. 변경을 막힘없이 내보내나, 내보낸 것이 자주 말썽을 부리나
2. 서비스 하나를 정해 그 서비스의 지표를 꾸준히 잽니다
3. 지난번의 우리 팀과 견줘 나아졌는지 확인합니다

대가는 지표가 목표가 되기 쉽다는 것입니다. 지표를 목표치로 걸면 팀이 일을 고치는 대신 숫자를 맞추려 들 수 있습니다.

상세

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

DORA 는 DevOps Research and Assessment(데브옵스 연구·평가)의 줄임말입니다. 일하는 방식이 조직의 목표와 구성원의 안녕으로 어떻게 이어지는지 밝히는 연구 프로그램입니다. 행동과학의 방법으로 조사합니다. 그 결과는 해마다 보고서로 냅니다.

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

팀에게 자기 성과를 잴 방법이 필요한 때는 셋입니다. 지금 어떤지 가늠할 때, 무엇부터 고칠지 정할 때, 고친 것이 효과가 있었는지 확인할 때입니다.

DORA 는 그 잴 방법으로 지표 다섯을 정했습니다. 다섯이 함께 재는 것을 소프트웨어 배달 성능(software delivery performance)이라고 부릅니다. 팀이 소프트웨어 변경을 안전하게, 빨리, 효율적으로 내보내는 능력을 뜻합니다. 이 지표 묶음을 흔히 DORA 지표라고 부릅니다.

지표는 활동량이 아니라 결과를 잽니다. 코드를 몇 줄 썼나가 아니라 변경이 프로덕션에 닿기까지 걸린 시간을 셉니다. 프로덕션은 실제 사용자가 쓰는 운영 환경입니다. DORA 의 연구에서 이 지표는 조직의 성과와 구성원의 안녕을 미리 알려 주는 신호로 나타났습니다.

두 묶음과 다섯 지표

다섯 지표는 두 묶음으로 나뉩니다. 처리량(throughput)은 일정 기간 동안 변경이 몇 개나 시스템을 지나 프로덕션에 닿을 수 있나를 잽니다. 여기서 세는 변경에는 정상 변경뿐 아니라 실패에 대응해 낸 변경도 들어갑니다. 그래서 실패한 배포에서 되살아나는 시간도 처리량 묶음에 듭니다.

불안정성(instability)은 배포가 잘 되나를 잽니다. 배포가 잘 되면 팀은 더 많은 변경을 자신 있게 프로덕션에 내보낼 수 있습니다. 사용자도 배포 직후에 문제를 겪을 가능성이 낮아집니다.

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

인시던트는 운영 중인 서비스에 난 장애입니다.

불안정성 묶음을 반대말인 안정성(stability)으로 부르는 문서도 있습니다. DORA 가 2024년에 낸 보고서가 그렇습니다. 같은 두 지표를 반대쪽에서 부르는 이름입니다.

속도와 안정성의 관계

처리량은 얼마나 빨리 내보내나, 곧 속도를 봅니다. 불안정성이 낮을수록 안정성은 높습니다. 흔히 빨리 내보내면 그만큼 자주 깨진다고 믿습니다. DORA 의 연구는 속도와 안정성이 맞바꾸는 관계가 아니라는 결과를 되풀이해 보였습니다.

대부분의 팀에서 다섯 지표는 서로 상관되어 함께 움직입니다. 상위 팀은 다섯 지표 모두에서 잘합니다. 하위 팀은 모두에서 못합니다.

같은 이름의 금융 규제

금융 분야에서 DORA 는 전혀 다른 것을 가리킵니다. 유럽연합(EU, European Union)이 금융 회사의 디지털 회복력을 높이려고 들인 규제 Digital Operational Resilience Act 의 줄임말입니다. 법령 번호는 Regulation (EU) 2022/2554 입니다. 이 문서가 다루는 배포 지표와는 이름만 같습니다.

배경

소프트웨어 팀의 성과를 잴 때 흔히 저지르는 실수가 있습니다. 결과(outcome) 대신 산출량(output)을 세는 것입니다. 팀 전체 대신 개인이나 한 부분만 재는 것도 같은 실수입니다. 자주 쓰이는 산출량 잣대는 코드 줄 수, 벨로시티, 가동률 셋입니다.

벨로시티는 애자일 방식으로 일하는 팀이 쓰는 값입니다. 이런 팀은 일을 스토리라는 단위로 쪼갭니다. 스토리마다 끝내는 데 드는 예상 품을 점수로 매깁니다. 이 점수가 스토리 포인트입니다. 스프린트(일을 끊어 하는 짧은 주기)가 끝날 때 고객이 승인한 점수를 더한 값이 벨로시티입니다.

세 잣대를 성과로 읽으면 이렇게 어긋납니다.

산출량 대신 결과를 재려면 무엇을 결과로 볼지부터 정해야 합니다. 2014년에 시작한 첫 조사는 IT(Information Technology, 정보 기술) 성과가 조직의 성과와 이어지는지를 과학적으로 밝히려 했습니다. 그러려면 IT 성과를 숫자로 정의해야 했습니다.

IT 성과는 하나의 값으로 바로 잴 수 없었습니다. 행복이나 직무 만족처럼 바로 잴 수 없는 것은 통계에서 잠재 구성 개념(latent construct)으로 잽니다. 서로 관련된 변수 여럿을 재서 그 뒤에 숨은 하나를 가늠하는 방법입니다. 연구진은 IT 성과도 이렇게 재려 했습니다.

flowchart TD
    subgraph V["2014년의 후보 변수 넷"]
        V1["배포 빈도"]
        V2["변경 리드 타임"]
        V3["평균 복구 시간"]
        V4["변경 실패율 · 함께 움직이지 않아 빠짐"]
    end
    V1 --> L["IT 성과 · 바로 잴 수 없는 하나"]
    V2 --> L
    V3 --> L

연구진은 배포 빈도, 변경 리드 타임, 평균 복구 시간, 변경 실패율 넷을 후보 변수로 놓았습니다. 평균 복구 시간(mean time to recover)은 실패에서 되살아나기까지 걸린 평균 시간입니다. 통계로 다듬어 보니 변경 실패율은 나머지 셋과 통계적으로 의미 있는 상관을 보이지 않았습니다. 그래서 첫해의 IT 성과는 남은 셋으로 정의했습니다. 이 틀이 해마다 다듬어져 지금의 소프트웨어 배달 성능 지표가 되었습니다.

예시

지표가 실물로 나타나는 곳은 셋입니다. 연구 보고서가 설문에서 얻은 값이 하나입니다. 같은 지표를 저장소와 배포 기록에서 계산하는 도구가 둘입니다.

Accelerate State of DevOps 2024 보고서

DORA 는 해마다 설문 응답자에게 주로 맡은 애플리케이션이나 서비스의 배달 성능을 묻습니다. 응답은 군집 분석으로 묶습니다. 군집 분석은 서로 비슷한 응답끼리 모으고 다른 무리와 가르는 통계 방법입니다. 무리의 수와 경계는 미리 정하지 않고 응답에서 드러나게 둡니다.

2024년 판에서는 응답이 네 무리로 갈렸습니다. 지난해들의 분석과 맞추려고 원래 지표 넷으로만 묶었습니다. 그래서 아래 표에 배포 재작업률이 없습니다.

응답자 비율 옆 괄호는 그 비율이 89% 확률로 들어 있으리라 보는 범위입니다. 이 범위를 89% 불확실성 구간이라고 부릅니다.

표를 보면 중간 무리의 변경 실패율(10%)이 높음 무리(20%)보다 낮습니다. 중간 무리는 처리량이 높음 무리보다 낮습니다. 대신 배포가 덜 깨집니다. 보고서는 더 빨리 내보내는 쪽을 높음, 그보다 느리지만 덜 깨지는 쪽을 중간이라 부르기로 했습니다.

엘리트 무리와 낮음 무리를 견주면 차이가 큽니다. 엘리트 쪽의 리드 타임이 127배 짧습니다. 배포는 해마다 182배 더 많이 합니다. 변경 실패율은 8배 낮습니다. 실패한 배포 복구 시간은 2293배 짧습니다.

이 보고서는 불안정성 묶음을 안정성(stability)이라는 이름으로 부릅니다.

GitLab

GitLab 은 DORA 지표를 자기 배포 기록과 인시던트 기록에서 계산합니다. 2024년 개편 전의 지표 넷을 셉니다. 묶음 이름도 처리량 대신 속도(Velocity), 불안정성 대신 안정성(Stability)을 씁니다.

머지 리퀘스트는 브랜치의 변경을 합쳐 달라는 요청입니다. 배포 빈도만 평균을 쓰고 나머지 셋은 중앙값을 씁니다.

변경 리드 타임은 재기 시작하는 때가 다릅니다. DORA 의 정의는 변경이 커밋된 때부터 잽니다. GitLab 은 머지 리퀘스트를 머지한 때부터 잽니다.

변경 실패율은 모든 인시던트를 프로덕션 인시던트로 칩니다. 같은 인시던트가 겹쳐 올라오면 따로 셉니다. 하루 한 번씩 열 번 배포하는 동안 첫날 인시던트가 둘, 마지막 날 하나가 나면 변경 실패율은 0.3 입니다.

서비스 복구 시간은 인시던트와 배포가 일대일로 이어진다고 가정합니다. 인시던트 하나는 프로덕션 배포 하나에만 이어집니다. 프로덕션 배포 하나에 이어지는 인시던트도 많아야 하나입니다.

배포 기록은 저장소에서 밀어 넣는 푸시 방식 배포에만 생깁니다. 에이전트로 컨테이너 이미지를 당겨 가는 풀 방식 배포는 기록이 안 생깁니다.

GitLab 에는 이름이 비슷한 리드 타임이 하나 더 있습니다. 밸류 스트림 애널리틱스의 리드 타임은 이슈를 만든 때부터 닫은 때까지라 변경 리드 타임과 다릅니다.

Four Keys

Four Keys 는 DORA 의 지표 넷을 재는 프로젝트입니다. GitHub 의 dora-team 조직 아래 공개되어 있습니다. GitHub 나 GitLab 같은 개발 환경에서 이벤트를 모아 지표 넷을 대시보드로 보여 줍니다. 지금은 유지보수를 하지 않는 저장소입니다.

이벤트는 풀 리퀘스트나 새 이슈처럼 개발 환경에서 잴 수 있는 일입니다. 이벤트가 대시보드에 닿기까지 지나는 길은 아래와 같습니다.

flowchart TD
    E["개발 환경 이벤트 · GitHub · GitLab"] --> W["웹훅 대상 · Cloud Run 에서 돎"]
    W --> P["Pub/Sub 토픽"]
    P --> C["변환 인스턴스 · Cloud Run 에서 돎"]
    C --> B["BigQuery 테이블"]
    B --> V["BigQuery 뷰"]
    V --> D["대시보드"]

웹훅 대상은 개발 환경이 보낸 이벤트를 받는 곳입니다. 받은 이벤트를 전부 Pub/Sub 토픽으로 발행합니다. Pub/Sub 은 메시지를 발행하고 구독하는 서비스입니다.

변환 인스턴스는 그 토픽을 구독하고 있습니다. 데이터를 가볍게 바꿔 BigQuery 테이블에 넣습니다. BigQuery 는 데이터를 테이블에 담아 두고 조회하는 서비스입니다. 남은 변환은 BigQuery 뷰가 마치고 대시보드에 넘깁니다.

웹훅 대상과 변환 인스턴스는 둘 다 Cloud Run 에서 돕니다. Cloud Run 은 컨테이너로 만든 프로그램을 띄워 돌려 주는 서비스입니다.

Four Keys 에 딸린 스크립트는 이벤트를 변경(changes) · 배포(deploys) · 인시던트(incidents) 셋으로 가릅니다. 인시던트에 「incident」 말고 다른 라벨을 쓰면 이 분류를 고칠 수 있습니다. 가르는 일이 위 길의 어느 단계에서 일어나는지는 자료에 없습니다(미확인). 배포로 가른 이벤트는 위 그림의 BigQuery 테이블 단계에서 four_keys.deployments 테이블에 담깁니다. 거기에는 성공한 배포만 들어갑니다.

배포 없이 릴리스만 내는 프로젝트에는 잘 맞지 않습니다. 라이브러리가 그런 프로젝트입니다. 트렁크로 머지할 때 스쿼시 머지를 쓰면 트렁크의 커밋과 브랜치의 커밋 사이 연결이 끊깁니다. 그러면 그 커밋들의 리드 타임을 잴 수 없습니다.

갈래

다섯 지표는 두 축으로 갈립니다. 하나는 처리량입니다. 정상 변경이든 실패에 대응한 변경이든, 변경을 내는 속도를 잽니다. 다른 하나는 불안정성입니다. 배포가 뜻하지 않게 곧바로 일을 더 부르는 가능성을 봅니다. 세는 변경에는 코드 변경뿐 아니라 설정 변경도 들어갑니다.

묶음 구성은 해마다 같지 않았습니다. 2015년에는 둘째 묶음을 안정성이라 불렀습니다. 그 묶음에는 평균 복구 시간과 변경 실패율이 들어 있었습니다. 2014년 정의에서 빠졌던 변경 실패율이 이때 다시 들어온 것입니다. 다시 넣은 까닭은 미확인입니다.

아래 그림은 2015년의 묶음과 2024년 개편 뒤의 묶음을 위아래로 견줍니다. 복구 시간은 안정성 묶음에서 처리량 묶음으로 옮겼습니다. 둘째 묶음에는 배포 재작업률이 새로 들어왔습니다.

flowchart TD
    subgraph Y15["2015년"]
        subgraph T15["처리량"]
            A1["배포 빈도"]
            A2["배포 리드 타임"]
        end
        subgraph S15["안정성"]
            A3["평균 복구 시간"]
            A4["변경 실패율"]
        end
    end
    subgraph Y24["2024년 개편 뒤"]
        subgraph T24["처리량"]
            B1["변경 리드 타임"]
            B2["배포 빈도"]
            B3["실패한 배포 복구 시간"]
        end
        subgraph I24["불안정성 · 2024 보고서는 안정성"]
            B4["변경 실패율"]
            B5["배포 재작업률 · 새로 들어옴"]
        end
    end
    A1 --> B2
    A2 --> B1
    A3 -->|"2023 이름과 정의를 바꿈"| B3
    A4 --> B4

변경 리드 타임

변경 하나가 커밋된 때부터 프로덕션에 배포되기까지 걸린 시간입니다. 처리량을 재는 지표입니다. 2014년 첫 조사부터 들어 있었습니다. 2015년 묶음에서는 배포 리드 타임(deployment lead time)이라는 이름으로 불렀습니다.

배포 빈도

일정 기간 동안 배포한 횟수로 세거나, 배포와 배포 사이의 간격으로 셉니다. 이것도 처리량에 듭니다. 변경 리드 타임과 함께 2014년 첫 정의부터 빠진 적이 없는 지표입니다.

실패한 배포 복구 시간

실패해서 곧바로 손대야 하는 배포에서 되살아나기까지 걸린 시간입니다. 옛 이름은 평균 복구 시간(mean time to recover) 또는 서비스 복구 시간(time to restore service)입니다. 2015년에는 안정성 묶음에 있었습니다. 2024년에 처리량 묶음으로 옮겼습니다.

2023년에는 이름과 함께 정의도 바꿨습니다. 옛 정의는 소프트웨어 변경이 낸 실패와 데이터센터 정전 같은 바깥 요인이 낸 장애를 가르지 않았습니다. 새 정의는 프로덕션에 낸 변경이 서비스를 망가뜨렸을 때 되살리는 시간만 셉니다. 그래서 다른 배달 지표와 통계로 더 잘 맞물립니다.

변경 실패율

배포 가운데 배포 직후 곧바로 손대야 했던 배포의 비율입니다. 불안정성에 드는 두 지표 가운데 하나입니다. 실패로 치는 배포는 프로덕션에 닿은 뒤 최종 사용자가 겪을 수 있는 문제를 낸 배포뿐입니다. 프로덕션으로 가는 길에 걸러진 변경은 실패가 아닙니다. 배포 과정이 오류를 잡아냈다는 증거로 봅니다.

네 지표의 분석에서 변경 실패율은 오래 이상값이었습니다. 다른 셋과 한 요인으로 묶이지 않는 지표였다는 뜻입니다. 2014년 첫 조사에서는 나머지 셋과 의미 있는 상관도 없었습니다. 설문에서 이 문항에 답하는 방식을 바꾸자 다른 지표와의 연결이 나아졌습니다. 2024년 보고서 기준으로는 나머지 셋과 강하게 상관됩니다. 그런데도 통계 검정상 넷을 한 요인으로 묶을 수는 없었습니다.

연구진은 이 지표가 팀이 떠안는 재작업의 양을 대신 보여 준다는 가설을 세웠습니다. 배포가 실패하면 팀은 그 변경을 고쳐야 합니다. 대개 또 다른 변경을 내서 고칩니다.

배포 재작업률

배포 가운데 계획에 없었는데 프로덕션 인시던트 때문에 나간 배포의 비율입니다. 2024년에 위의 가설을 시험하려고 들인 다섯째 지표입니다. 설문 문항은 이렇습니다. 「주로 맡은 애플리케이션이나 서비스에서 지난 여섯 달 동안 계획에 없이 사용자가 겪는 버그를 고치려고 한 배포는 대략 몇 번입니까?」

분석해 보니 재작업률과 변경 실패율은 서로 이어져 있었습니다. 둘이 함께 믿을 만한 한 요인을 이뤘습니다. 둘 다 배포 수에 대한 비율입니다. 갈리는 것은 세는 배포입니다. 변경 실패율은 문제를 낸 배포를 셉니다. 배포 재작업률은 프로덕션 인시던트 때문에 계획에 없이 나간 배포를 셉니다.

운영 성능을 재는 신뢰성

신뢰성(reliability)은 다섯 지표에 들지 않습니다. 2018년에 운영 건강을 재려고 가용성(availability)이 들어왔습니다. 2021년에 지연 · 성능 · 확장성까지 아우르는 신뢰성으로 넓혔습니다. 신뢰성은 소프트웨어 배달 성능보다 운영 성능을 재는 지표에 가깝습니다.

운영

다섯 지표를 팀에 들여올 때 빠지기 쉬운 함정은 일곱입니다. 재는 단위, 목표치와 경쟁, 지표의 수와 소유, 측정에 드는 품의 네 소절로 나눠 차례로 셉니다.

재는 단위

다섯 지표는 어떤 기술로 만든 소프트웨어에도 쓸 수 있습니다. 대신 한 번에 애플리케이션 하나나 서비스 하나를 잴 때 가장 잘 맞습니다. 애플리케이션마다 조직과 사용자 같은 맥락이 다르기 때문입니다.

여러 팀이나 조직 전체의 지표를 한데 섞고 싶어질 수 있습니다. 맥락이 서로 달라 섞으면 문제가 될 수 있습니다.

첫째 함정은 성격이 크게 다른 애플리케이션끼리 견주는 것입니다. 모바일 앱과 메인프레임 시스템의 지표를 나란히 놓으면 잘못 읽힐 수 있습니다.

목표치와 경쟁

둘째 함정은 지표를 목표로 거는 것입니다. 굿하트의 법칙은 지표가 목표가 되면 더는 그 지표 노릇을 못 한다는 관찰입니다. 이를 무시하고 「모든 애플리케이션은 연말까지 하루에 여러 번 배포한다」 같은 목표를 내걸면 팀이 숫자를 맞추려 들 가능성이 커집니다.

셋째는 다른 팀이나 다른 조직과 겨루는 것입니다. 지표의 목적은 자기 팀이 시간이 지나며 나아지는 것입니다. 남과 겨루는 데 쓰라는 것이 아닙니다.

성능 무리를 대할 때도 같습니다. 연구진은 어느 무리에 드느냐보다 나아지는 것을 더 중요하게 봅니다. 가장 나은 팀은 나아지는 폭이 엘리트급인 팀입니다. 꼭 엘리트 성능을 내는 팀은 아닙니다.

넷째는 업계를 방패로 삼는 것입니다. 규제가 센 업계의 팀은 규제 준수 요구 때문에 지금 방식을 바꿀 수 없다고 말하기도 합니다. DORA 의 연구는 업계가 배달 성능을 예측하는 경우를 드물게만 찾습니다. 2024년 조사에서도 성능이 높은 팀은 모든 업계에서 나왔습니다.

지표의 수와 소유

다섯째는 지표 하나만 중요하다고 보는 것입니다. 복잡한 시스템은 지표 하나로 다 재지 못합니다. 권고는 지표를 여럿 고르는 것입니다. 그 가운데 일부는 서로 적당한 긴장 관계에 있는 지표로 넣습니다. 어느 측정 틀을 쓸지는 조직의 목표에 맞춰 고릅니다.

여섯째는 지표를 팀마다 떼어 맡기는 것입니다. 개발 팀과 운영 팀과 릴리스 팀이 다섯 지표를 함께 보는 것은 협업과 배달 과정의 공동 책임을 북돋웁니다. 팀마다 특정 지표만 맡기면 마찰과 서로 탓하기가 생길 수 있습니다.

측정에 드는 품

일곱째는 재는 데 매달려 고치는 일을 뒤로 미루는 것입니다. 지표에 쓸 데이터는 여러 시스템에 흩어져 있습니다. 정확한 값을 얻으려고 여러 시스템을 잇는 연동을 만들면 처음 들이는 품만큼 값을 못 할 수 있습니다. 팀이 대화부터 시작하거나, 연동이 미리 갖춰진 제품을 쓰는 쪽이 나을 수 있습니다.

관련 항목

DORA 가 정한 다섯 지표와 옛 이름

변경 리드 타임 · 배포 빈도 · 서비스 복구 시간 · 변경 실패율 · 배포 재작업률 · 평균 복구 시간

이 지표들이 속하는 상위 분류

소프트웨어 배달 성능 · 처리량 · 운영 성능 · 데브옵스 · 릴리스 엔지니어링

DORA 연구가 쓰는 통계 방법

잠재 구성 개념 · 군집 분석 · 상관관계 · 불확실성 구간 · 행동과학

DORA 가 성과 잣대에서 뺀 산출량 지표

코드 줄 수 · 벨로시티 · 스토리 포인트 · 가동률 · 큐잉 이론 · 스프린트

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

버전관리 · 커밋 · 머지 리퀘스트 · 스쿼시 머지 · 지속적 통합 · 지속적 배포 · 배포 · 프로덕션 환경 · 롤백 · 핫픽스 · 인시던트

연구 결과를 싣는 보고서와 책

State of DevOps Report · Accelerate · DORA Quick Check · DORA Core Model

이 지표를 계산하는 도구

Four Keys · GitLab · 대시보드 · 웹훅 · BigQuery · Cloud Run

운영 건강을 재는 이웃 지표

가용성 · 신뢰성 · 오류율 · SLO

지표를 쓸 때 부딪히는 함정

굿하트의 법칙 · 허영 지표 · 지표 조작 · 규제 준수

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

리드 타임 · 사이클 타임 · 밸류 스트림 애널리틱스

이름이 겹치는 금융 규제

Digital Operational Resilience Act · 운영 회복력 · 사이버 보안 · EIOPA