프론트엔드 개발을 위주로 하는 입장에서 DevOps는 사실 단어는 너무나도 많이 들리지만 막상 아는 건 하나도 없는 가깝고도 먼 단어입니다.
최근 팀에서 DevOps 관련된 주제를 가지고 토론을 빙자한 수다를 좀 떨었는데 아주 흥미로운 내용이었습니다.
팀의 개발 문화를 측정하는 지표에 대한 이야기였죠.
DORA란?
DORA (DevOps Research and Assessment)
구글에서 개발한 DORA (DevOps Research and Assessment)는 제품 개발을 보다 효율적인 운영할 수 있도록 도와주는 지표입니다. 특히 요즘 개발 프로세스 중에서 가장 핫한 키워드인 "애자일(Agile)"과 아주 밀접한 관계를 가진 지표이기도 해서 실제 많은 기업들이 이 지표를 사용하고 있습니다.
DORA의 핵심 지표는 4가지입니다.
1. 배포 빈도 (Development frequency)
2. 리드 타임 (Lead time for changes)
3. 변경 실패율 (Change failure rate)
4. 서비스 복구 시간 (Time to restore sevice)
1. 배포 빈도 (Development frequency)
아주 직관적이죠. 배포를 얼마나 많이 하느냐 측정하는 것입니다. 이를 통해 개발팀의 속도와 역량, 자동화 수준을 측정하게 됩니다. 배포 빈도가 높을수록 팀은 피드백을 더 빨리 수집할 수 있고 그에 따른 기능 개선의 가능성이 더 높아지기 때문에 전반적인 효율성을 체크할 수 있습니다. 특히 요즘 같이 마이크로서비스 아키텍처(Micro Service Architecture)가 유행하는 시점에서는 다른 서비스의 영향을 받지 않고 독립적으로 배포가 가능하기에 배포 크기도 줄어들어 배포가 용이해진 만큼 배포 빈도는 단순하면서도 강력한 지표라고 할 수 있습니다.
2. 리드 타임 (Lead time for changes)
리드 타임은 팀이 기능 개발을 하겠다고 한 시점부터 실제 사용자에게 해당 기능이 제공되기까지 걸리는 속도를 측정합니다. 팀의 개발 역량, 코드의 복잡성, 환경 변화 등 다양한 변수에 대해 종합적으로 산출되는 결과의 지표이기에 팀 DevOps의 전반적인 능력을 나타냅니다.
3. 변경 실패율 (Change failure rate)
변경 실패율은 실제 프로덕션까지 진행했을 때 실패한 배포 또는 코드의 비율을 의미합니다. 배포 빈도와 리드 타임의 경우 해당 배포의 성공 여부와 상관없이 측정하게 됩니다. 이에 대한 견제 기능을 하는 것이 바로 변경 실패율 지표입니다. 속도도 중요하지만 이것이 얼마나 정확하게 배포가 진행되었고 안정적으로 동작하는지 속도 대비 안정성을 측정하는 항목입니다.
4. 서비스 복구 시간 (Time to restore sevice)
문제가 발생한 후 해결하는데 걸리는 평균 시간을 나타냅니다. 실제 프로덕션 중인 환경에서 문제가 발생하면 이에 대해 얼마나 빠르게 대처하는지는 정말 중요합니다. 문제가 빠르게 대처되지 않을 경우 유저 이탈 즉, 서비스의 매출 저하와 직결되기 때문이죠. 외부의 공격이든 코드의 버그든 이에 대해서 신속하게 대응할 수 있어야 합니다.
위의 지표들을 가볍게 테스트할 수 있도록 DORA 측은 Quick Check 서비스를 제공하고 있습니다.
위의 결과처럼 산업군의 평균, 표준편차와 나의 위치를 함께 보여줘서 간단하게 판단해 보기 아주 좋은 것 같습니다.
DORA 지표를 사용하지 않을 이유
하지만 해당 지표는 과연 절대적일까요? 당연히 아닙니다.
Goodhart's law라고 들어보셨나요? 영국의 경제학자 Goodhart의 격언이 있습니다.
"측정값이 목표가 되면 더 이상 좋은 측정값이 아니다."
단순히 DORA 지표 개선을 위한 개발이 되는 순간 DORA는 유의미한 결과를 불러일으키지 못합니다. 각각의 지표에 대해서 어떤 상황이 발생할 수 있는지 살펴보죠.
1. 배포 빈도 (Development frequency)
배포를 많이 하는 것은 팀이 기능 개발을 지속적으로 한다는 점에서 좋지만 실제 개선이 어떻게 달성되는지도 중요합니다. 결국 개발팀이 배포를 얼마나 많이 했는지보다 중요한 것은 사용자가 더 빈번한 배포로 인한 이점을 보고 있는지입니다. 특히 해당 개발 팀의 역량이 낮을 경우 단순히 더 열심히 개발해서 배포 빈도만을 높이게 되면 안정성에 큰 타격이 갈 것입니다.
2. 리드 타임 (Lead time for changes)
리드 타임을 단축시킨다는 것은 더 빠르게 기능 개발을 하는 것이고 릴리스를 자주 수행하기에 제품 개발 또는 완성 속도가 빨라지기에 좋다고 볼 수 있죠. 하지만 이 속도에 너무 몰두한 나머지 테스트를 안 하거나 대충 하는 등의 지름길을 택하여 개발을 진행시킬 수도 있습니다. 또는 코드 작성 시 무조건적으로 빠르게 기능"만" 완성시켜 보안에 대한 약점을 유발할 수도 있죠.
3. 변경 실패율 (Change failure rate)
변경 실패율의 통계 산출 방식을 통한 왜곡이 가능할 수도 있습니다. 변경 실패율은 통상적으로 배포 수 대비 버그 / 오류 발생 비율을 측정합니다. 기존에 10번 배포해서 1번 버그가 일어났던 것이 100번 배포해서 9번 버그가 일어나게 되면 팀의 변경 실패율 지표는 향상한 것으로 측정됩니다. 하지만 버그의 절대적인 횟수에서 차이가 나게 되죠. 수정해야 되는 기능의 크기가 어느 정도인지는 차이가 나겠지만 1번 버그가 일어나면 하나의 기능만 고치면 되지만 9번 버그는 결국 9개의 기능을 수정해야 한다는 뜻이 됩니다. 즉, 인위적으로 배포 횟수를 늘려 지표를 향상한 것처럼 눈속임이 가능할 수 있습니다.
4. 서비스 복구 시간 (Time to restore sevice)
서비스를 복구하는 가장 빠른 방법이 뭘까요? 가장 빠르면서 단순하게 이전에 안정적으로 동작했던 코드로 롤백을 시키는 것일 겁니다. 하지만 서비스 복구 전략이 롤백이 대부분인 경우 사용자 입장에서 문제가 발생하지 않으니깐 괜찮은 것이 아니라 오히려 최신 기능들에 대한 가치를 사용자로부터 빼앗는 꼴이 됩니다. 이렇게 되면 평균 복구 시간은 매우 짧지만 제품은 계속 그대로인 상태의 잘못된 민첩함을 가지게 되는 것이죠.
또 모니터링과 관련하여 통계의 왜곡이 일어날 수 있습니다. 문제 감지를 위한 모니터링이 부족하여 평균 복구 시간이 짧을 수도 있을 것입니다. 에러 발견 후 수정까지 1시간도 안 걸렸지만 그 에러를 발견한 시점이 이미 첫 발생부터 일주일이 지난 시점이라면 그 사이에 유저들은 이미 떠나가있겠죠.
결론
DORA 지표는 팀 개발 문화를 측정하는데 도움이 되는 도구인 것은 분명 사실입니다. 하지만 이 지표가 목표가 되는 순간 프로젝트 진행 상황에 대해서 오해가 커질 우려도 있다는 것 또한 부정할 수 없는 사실입니다. 특히, 저의 포함한 대다수의 한국인들이 겪어온 상황을 고려해 봤을 때 성적을 위한 공부를 했던 경험이 다들 있던 만큼 지표가 목표가 될 가능성이 결코 적지 않다고 보입니다.
또한 많은 공학이 그러하듯이 한 가지를 선택하면 한 가지를 포기해야 하는 경우가 있는 지표입니다. 배포를 자주 하다 보면 사람이기에 놓칠 수 있는 부분들이 더 많아지는 것은 어찌 보면 당연한 일일 수도 있습니다. 이에 따라 본질적인 문제해결이 아닌 어떤 수치적 이득을 취하는 것이 효과적일지 고민하게 되는 상황도 펼쳐질 수도 있을 거라 생각합니다.
물론 적절하게 사용할 경우 DORA 지표는 팀의 진행 상황을 보여주는 훌륭한 방법이고 비즈니스 가치를 설명하는 데도 아주 좋은 근거가 될 수 있을 것입니다. 개발자, 기획자뿐만 아니라 기타 이해관계자들도 개발 상황을 함께 개선시켜 나갈 수 있도록 판단하는 데 활용될 수 있죠. 해당 지표를 도입하게 된다면 개발의 목적이 "어떻게 좋은 수치를 내야지?"가 아니라 "어떻게 이 문제를 해결할까?" 임을 지속적으로 돌이켜볼 필요가 있을 것 같습니다.
참고
https://www.atlassian.com/devops/frameworks/dora-metrics - DORA metrics: How to measure Open DevOps success
https://www.infoq.com/articles/dora-metrics-anti-patterns/ - How Not to Use the DORA Metrics to Measure DevOps Performance