DORA 지표

개발팀이 잘 굴러가고 있는지를 밖에서 알 방법이 오래 없었습니다. 영업은 계약 건수로, 마케팅은 유입 수로 이야기할 수 있는데 개발은 그럴 숫자가 마땅치 않았습니다. 그래서 세기 쉬운 것부터 세기 시작했습니다. 짠 코드의 줄 수, 올린 커밋 수, 닫은 티켓 수 같은 것들입니다.

세 값에는 공통점이 있습니다. 노력의 양은 보여 주지만 그 노력이 사용자에게 닿았는지는 말해 주지 않는다는 점입니다. 그리고 재기 시작하면 그 숫자만 오릅니다. 줄 수를 재면 같은 기능이 더 긴 코드로 만들어지고, 티켓 수를 재면 하나로 끝낼 일이 셋으로 쪼개집니다. 반년 뒤에는 표가 위로 향하는데 사용자가 쓰는 화면은 그대로인 상태가 됩니다.

여기에 오래된 믿음이 하나 겹쳐 있었습니다. 빨리 내보내면 위험하고 안전하게 가려면 느려야 한다는 것입니다. 이 믿음 위에서 세운 규칙이 한 달에 한 번 몰아서 배포하기, 금요일에는 배포하지 않기, 배포 전에 결재 세 단계 받기 같은 것들입니다. 페이지덱도 초기에는 한 달치 변경을 한꺼번에 올렸습니다. 대표 규원이 "지난달에 개발팀이 뭘 했는지" 물으면 개발자 태오가 기능 목록을 읽어 주는데, 무엇이 언제 사용자에게 닿았는지는 목록만으로 알 수 없었습니다. 한 달을 모아 한 번에 올리니 그날 밤에는 늘 무언가가 터졌고, 스무 가지 변경 중 어느 것이 원인인지 찾는 데만 서너 시간이 걸렸습니다.

DORA 지표는 이 두 문제를 같이 겨냥합니다. DORA 는 소프트웨어 개발 조직의 성과를 여러 해에 걸쳐 조사한 연구 프로그램의 이름이고, 수천 개 조직의 응답을 모아 본 결과는 통념과 달랐습니다. 자주 내보내는 조직이 사고도 적었습니다. 한 달치를 한 번에 올리는 팀이 하루에 여러 번 올리는 팀보다 더 자주 크게 터졌습니다. 변경 덩어리가 작으면 터져도 원인이 하나뿐이고 되돌리기도 쉽기 때문입니다.

네 값을 고른 기준도 같은 데서 나옵니다. 조사에서 상위권 조직과 하위권 조직을 실제로 갈라낸 항목만 남기고 나머지를 버렸습니다. 그래서 목록에 없는 것들이 눈에 띕니다. 팀 인원, 쓰는 언어, 코드 줄 수, 회의 횟수 같은 것은 성과와 뚜렷한 관계가 나오지 않아 빠졌습니다. 재고 싶은 것을 모아 둔 목록이 아니라 남은 것을 적어 둔 목록이라는 점이 이 네 값의 성격입니다.

그래서 남은 네 값은 노력이 아니라 결과를 잽니다. 무엇을 얼마나 열심히 만들었는지가 아니라, 만든 것이 사용자에게 얼마나 빨리 닿았고 닿는 과정에서 얼마나 깨졌는지를 봅니다. 엔지니어링 축의 지형에서 이 갈래는 돌아가는 동안을 보는 운영 쪽에 놓입니다. 관측성이 시스템 안에서 지금 무슨 일이 벌어지는지를 본다면, DORA 지표는 조직이 변경을 내보내는 흐름 자체를 봅니다.

DORA 지표 아래 용어는 네 갈래이고, 각 갈래가 지표 하나씩입니다. 넷은 두 쌍으로 묶여 서로를 견제합니다. 앞의 둘은 속도를, 뒤의 둘은 안정성을 잽니다. 한쪽만 보면 반드시 다른 쪽이 망가지기 때문에 넷을 한 묶음으로 둡니다.

속도 쪽 두 지표는 변경이 사용자에게 닿는 흐름을 봅니다.

1. 배포 빈도 — 정해진 기간에 운영 환경으로 몇 번 내보냈는지를 셉니다. 한 달에 두 번인 팀과 하루에 다섯 번인 팀은 같은 기능을 만들어도 사용자가 그것을 받는 시점이 다릅니다. 이 값이 낮다는 것은 대개 한 번 내보내는 데 사람 손이 많이 든다는 뜻이고, 손이 많이 들면 사람들은 자연히 모아서 한꺼번에 내보내게 됩니다. 페이지덱이 한 달에 한 번 올리던 시절의 이 값은 1 이었고, 지금은 주에 여덟 번쯤입니다. 세는 대상은 운영 환경에 실제로 반영된 것만입니다. 개발용 서버에 올린 것이나 기능을 꺼 둔 채 코드만 넣어 둔 것은 사용자에게 닿지 않았으므로 빼고 셉니다.
2. 변경 리드 타임 — 코드를 다 쓴 시점부터 그 변경이 운영에 반영된 시점까지 걸린 시간입니다. 보통 평균이 아니라 중앙값으로 봅니다. 한 건이 휴가 때문에 3주 걸리면 평균이 통째로 흔들리기 때문입니다. 이 값이 긴 팀에서는 기다리는 시간이 대부분입니다. 코드 리뷰를 기다리고, 테스트가 도는 것을 기다리고, 배포 승인을 기다립니다. 사람이 손으로 짜는 시간은 그 사이에 몇 시간뿐인 경우가 흔합니다. 페이지덱에서 이 값을 처음 재 봤을 때 중앙값이 6일이었는데, 그중 4일이 리뷰를 기다린 시간이었습니다. 개발자를 더 뽑아도 줄지 않는 종류의 6일이었던 셈입니다.

안정성 쪽 두 지표는 그 흐름이 얼마나 깨지는지를 봅니다.

1. 변경 실패율 — 내보낸 배포 중 장애로 이어져 되돌리거나 급히 고쳐야 했던 것의 비율입니다. 스무 번 내보내 한 번을 되돌렸으면 5퍼센트입니다. 여기서 늘 걸리는 것은 실패의 기준입니다. 되돌린 것만 셀지, 긴급 수정까지 셀지, 사용자가 눈치채지 못한 오류도 셀지를 팀이 미리 정해 두지 않으면 분기마다 다른 잣대로 잰 값이 한 표에 섞입니다.
2. 복구 시간 — 장애가 시작된 시점부터 서비스가 정상으로 돌아온 시점까지 걸린 시간입니다. 원인을 완전히 밝힌 시점이 아니라 사용자가 다시 쓸 수 있게 된 시점까지입니다. 이 구분이 중요한 이유는 둘이 자주 다르기 때문입니다. 문제를 일으킨 배포를 되돌려 10분 만에 서비스를 살리고, 원인은 다음 날 찾는 편이 그 자리에서 원인을 파느라 두 시간을 멈춰 두는 것보다 낫습니다. 이 값을 줄이려면 장애 대응 절차가 미리 정해져 있어야 합니다.

네 값을 한 묶음으로 두는 이유는 짝이 없으면 각자가 망가지기 때문입니다. 배포 빈도만 목표로 걸면 팀은 아무것도 바꾸지 않는 빈 배포를 하루에 열 번 올릴 수 있습니다. 변경 실패율만 목표로 걸면 아무것도 내보내지 않는 쪽이 가장 좋은 성적을 받습니다. 속도 둘과 안정성 둘을 함께 놓으면 이 편법이 서로에게 막힙니다.

좋은 수준은 절대값보다 방향으로 읽습니다. 조사에서 상위권 조직은 하루에도 여러 번 내보내고, 리드 타임이 하루를 넘지 않고, 실패율이 한 자릿수이고, 복구가 한 시간 안에 끝납니다. 아래쪽은 같은 값이 각각 몇 달에 한 번, 몇 달, 수십 퍼센트, 며칠 단위로 나옵니다. 구간 기준은 조사 회차마다 조금씩 바뀌므로 특정 숫자를 외우기보다 우리 팀의 지난 분기와 이번 분기를 견주는 쪽이 쓸모 있습니다.

네 값을 실제로 움직이는 장치는 대개 하나입니다. CI/CD, 즉 코드 변경을 자동으로 검사하고 문제가 없으면 서버까지 올리는 체계입니다. 배포가 자동으로 돌면 빈도가 오르고 리드 타임이 줄고, 나가기 전에 테스트가 자동으로 돌면 실패율이 내려가고, 되돌리기 한 번으로 이전 상태로 돌아갈 수 있으면 복구 시간이 줄어듭니다. 그래서 네 값이 나쁜 팀을 만나면 대개 이 체계가 없거나 사람 손을 많이 타는 상태입니다. 순서를 뒤집어 말하면, 네 값을 올리려고 따로 할 일을 찾을 필요가 없다는 뜻이기도 합니다. 배포 과정에서 사람이 손으로 하는 단계를 하나씩 없애면 네 값이 따라옵니다. 지표를 목표로 삼는 대신 지표가 가리키는 병목을 손보는 쪽이 이 묶음을 쓰는 제대로 된 방법입니다.

"지난 분기 배포 빈도가 주 2회였는데 이번 분기에 주 8회로 올랐어요. 실패율은 그대로입니다."

더 자주 내보내면서도 깨지는 비율이 늘지 않았다는 보고입니다. 두 값을 붙여 말하는 것이 핵심이고, 빈도만 말하면 위험을 감추고 말한 것이 됩니다.

"리드 타임 중앙값이 6일인데 그중 4일이 리뷰 대기예요."

느린 원인이 개발 속도가 아니라 리뷰가 밀리는 데 있다는 뜻입니다. 사람을 더 뽑는 대신 리뷰 규칙을 고쳐야 한다는 말이 뒤에 붙습니다.

"이번 장애 복구 시간 47분으로 기록할게요. 원인 분석은 내일 이어서 합니다."

서비스가 정상으로 돌아온 시점까지만 이 지표에 넣는다는 확인입니다.

페이지덱에서 이 네 값은 분기마다 한 번, 기술 조직 회고 자리에서 함께 올라옵니다. 태오가 표를 띄우면 규원이 가장 먼저 보는 것은 값의 높낮이가 아니라 네 값이 같은 방향으로 움직였는지입니다. 빈도만 오르고 실패율이 함께 올랐으면 무리하게 밀어낸 분기이고, 실패율만 내려가고 빈도가 같이 내려갔으면 몸을 사린 분기입니다. 둘 다 좋은 신호가 아닙니다.

지현은 이 자리에 제품 쪽 숫자를 들고 들어오지 않습니다. 대신 리드 타임이 길어진 달에 어떤 일이 있었는지를 함께 되짚습니다. 급한 요청이 몰려 작업이 잘게 끼어들었는지, 리뷰할 사람이 휴가였는지에 따라 다음 분기에 손볼 곳이 달라집니다. 숫자가 원인을 말해 주지는 않고, 어디를 들여다볼지만 알려 줍니다.

이 자리에서 나오는 결정은 대개 사람이 아니라 절차에 걸립니다. 리뷰 대기가 길면 리뷰어를 지정하는 규칙을 바꾸고, 복구가 느리면 되돌리기를 한 번에 하는 방법을 먼저 만듭니다. 누가 느렸는지를 묻는 회고는 다음 분기에 숫자를 더 좋아 보이게 만들 뿐 실제 흐름을 바꾸지 못합니다.

네 값을 팀별 성적표로 읽는 경우가 가장 많습니다. 숫자가 네 개로 깔끔하게 떨어지니 팀을 나란히 놓고 싶어지는 것이 자연스럽습니다. 하지만 이 값들은 팀이 맡은 시스템의 성격에 크게 좌우됩니다. 결제를 다루는 팀은 같은 실력으로 일해도 배포 전에 확인할 것이 많아 빈도가 낮게 나오고, 화면 문구를 고치는 팀은 하루에 열 번도 올립니다. 이 값으로 평가를 시작하면 팀들은 배포 단위를 잘게 쪼개 빈도를 올리고 장애 판정 기준을 느슨하게 잡아 실패율을 낮춥니다. 1년 뒤에는 표의 네 칸이 모두 좋아졌는데 실제로 사용자가 겪는 장애는 그대로인 상태가 됩니다. 같은 팀의 지난 분기와 이번 분기를 견주는 용도로만 쓰면 이 문제가 거의 생기지 않습니다. 비교 대상이 자기 자신이면 기준을 느슨하게 바꿀 이유가 사라지기 때문입니다.

속도와 안정성이 서로를 깎아 먹는다고 믿는 것도 흔합니다. 빨리 가면 대충 하게 된다는 경험이 실제로 있으니 그렇게 생각하기 쉽습니다. 다만 그 경험은 큰 덩어리를 빨리 밀어낼 때의 일입니다. 조사 결과가 뒤집은 것은 속도의 방향이 아니라 덩어리의 크기입니다. 한 달치 스무 가지 변경을 한 번에 올리면 터졌을 때 원인 후보가 스무 개이고 되돌리면 멀쩡한 열아홉 개도 함께 사라집니다. 같은 변경을 스무 번에 나눠 올리면 터진 그 한 번만 되돌리면 되고 원인은 하나로 좁혀집니다. 그대로 두면 팀은 배포를 두려워하게 되고, 두려우면 더 모아서 올리게 되고, 더 모으면 더 크게 터집니다. 네 값이 나빠지는 경로는 대개 이 고리입니다.