DevOps 성과 측정하기 1편: 좋은 지표는 좋은 행동을 만든다

DevOps를 공부하다 보면 CI/CD, Infrastructure as Code, 컨테이너, 자동화 같은 기술적인 요소에 먼저 눈이 갑니다. 하지만 DevOps는 단순히 도구를 잘 쓰는 것이 아니라, 조직이 더 빠르고 안정적으로 소프트웨어를 전달할 수 있도록 계속 개선하는 방식입니다.

그리고 개선을 하려면 먼저 현재 상태를 알아야 합니다.

이번 Coursera 강의에서는 DevOps를 성공적으로 실천하기 위해 무엇을 측정해야 하는지를 다뤘습니다. 특히 인상 깊었던 점은 측정이 단순한 보고용 숫자가 아니라, 조직의 행동을 바꾸는 기준이 될 수 있다는 점이었습니다.

잘못된 지표는 잘못된 행동을 만들고, 좋은 지표는 좋은 행동을 만듭니다.

이번 1편에서는 DevOps에서 측정이 왜 중요한지, 잘못된 지표가 어떤 문제를 만들 수 있는지, 그리고 허영 지표와 실행 가능한 지표의 차이를 중심으로 정리해보겠습니다.

1. 측정하는 것이 행동을 만든다

강의에서 인상 깊었던 표현 중 하나는 다음과 같은 개념이었습니다.

A를 보상하면서 B를 기대하는 어리석음

조직에서 어떤 것을 측정하고 보상하느냐에 따라 사람들의 행동은 달라집니다.

예를 들어 개발자의 생산성을 코드 라인 수로 측정한다고 가정해보겠습니다. 그러면 개발자는 더 많은 코드를 작성하려고 할 수 있습니다. 하지만 코드가 많다고 해서 반드시 좋은 소프트웨어가 되는 것은 아닙니다.

오히려 불필요하게 복잡한 코드가 늘어나고, 유지보수하기 어려운 구조가 될 수도 있습니다.

또 다른 예로, 사람을 순위로 평가하면 어떤 일이 생길까요?

개인의 순위를 높이는 데 집중하게 되면서 협력보다 경쟁이 강해질 수 있습니다. 심한 경우 지식 공유를 꺼리거나, 다른 사람을 돕는 행동이 줄어드는 반사회적 행동이 나타날 수도 있습니다.

즉, 잘못된 지표는 잘못된 행동을 만듭니다.

DevOps에서 측정이 중요한 이유는 단순히 숫자를 보기 위해서가 아닙니다. 우리가 원하는 행동이 무엇인지 정하고, 그 행동을 강화할 수 있는 지표를 선택해야 하기 때문입니다.

2. 협업을 만들려면 협업을 측정해야 한다

DevOps는 개발과 운영의 벽을 허물고, 팀 전체가 함께 품질과 배포 결과를 책임지는 문화를 지향합니다.

그렇다면 개인의 산출량만 측정하는 방식은 DevOps 문화와 잘 맞지 않을 수 있습니다.

강의에서는 개발자를 단순히 코드 작성량으로 평가하기보다, 사회적 상호작용과 코드 및 지식 공유를 기준으로 보는 것이 더 협력적인 문화를 만드는 데 도움이 된다고 설명합니다.

예를 들어 다음과 같은 지표를 생각해볼 수 있습니다.

• 누가 내 코드를 활용하는가?
• 나는 누구의 코드를 활용하는가?

이런 지표는 코드 공유와 재사용을 촉진할 수 있습니다.

좋은 코드는 혼자만 쓰고 끝나는 코드가 아니라, 다른 팀원이나 다른 서비스에서도 활용할 수 있는 코드일 수 있습니다. 또한 다른 사람의 코드를 적극적으로 이해하고 재사용하는 것도 조직 전체의 생산성을 높이는 행동입니다.

물론 이런 지표도 사람을 감시하거나 순위를 매기기 위한 방식으로 사용되면 부작용이 생길 수 있습니다. 중요한 것은 개인을 압박하는 것이 아니라, 조직이 협업과 지식 공유를 얼마나 잘하고 있는지 이해하는 것입니다.

3. DevOps 측정은 현재 상태에서 시작한다

DevOps의 목표는 지속적인 개선입니다.

지속적인 개선을 하려면 먼저 현재 상태를 알아야 합니다. 현재 상태를 측정하고, 이를 기준선으로 삼은 뒤, 개선 목표를 설정해야 합니다.

예를 들어 현재 배포에 평균 2일이 걸린다고 가정해보겠습니다. 이 상태를 모르면 개선이 되었는지 판단할 수 없습니다.

하지만 현재 배포 시간이 2일이라는 기준선이 있다면, 다음 목표를 세울 수 있습니다.

• 배포 시간을 2일에서 1일로 줄이기
• 테스트 자동화를 통해 결함 발견 시점을 앞당기기
• 장애 발생 후 복구 시간을 줄이기
• 배포 실패율을 낮추기

이처럼 DevOps 측정은 “우리가 잘하고 있는가?”를 막연하게 묻는 것이 아니라, 현재 상태를 수치로 확인하고 조금씩 개선하는 과정입니다.

4. 실패를 막는 것에서 빠르게 복구하는 것으로

전통적인 운영 방식에서는 장애를 최대한 막는 것에 집중하는 경우가 많았습니다.

물론 장애를 예방하는 것은 중요합니다. 하지만 복잡한 시스템에서는 모든 실패를 완벽하게 막기 어렵습니다. 특히 마이크로서비스, 컨테이너, 클라우드 환경처럼 시스템이 분산되고 동적으로 변하는 환경에서는 장애 가능성을 완전히 제거하기 어렵습니다.

DevOps에서는 실패를 완전히 없애는 것보다, 실패가 발생했을 때 얼마나 빠르게 감지하고 복구할 수 있는가도 중요하게 봅니다.

예를 들어 컨테이너 기반 환경에서는 특정 인스턴스에 문제가 생기면 새로운 컨테이너를 빠르게 띄우거나, 장애가 발생한 서비스를 교체하는 방식으로 복구할 수 있습니다.

이런 관점에서는 다음과 같은 질문이 중요해집니다.

• 장애가 발생했을 때 얼마나 빨리 알 수 있는가?
• 장애 원인을 얼마나 빠르게 파악할 수 있는가?
• 복구까지 얼마나 걸리는가?
• 같은 문제가 반복되지 않도록 어떤 개선을 했는가?

DevOps의 측정은 단순히 실패 횟수를 줄이는 데서 끝나지 않습니다. 실패가 발생했을 때 조직이 얼마나 빠르게 배우고 회복하는지도 함께 봐야 합니다.

5. 허영 지표(vanity metrics)와 실행 가능한 지표(actionable metrics)

측정할 때 주의해야 할 개념이 있습니다.

바로 허영 지표와 실행 가능한 지표입니다.

구분	의미	예시	한계
허영 지표 vanity metrics	보기에는 좋아 보이지만 실제 의사결정에 큰 도움이 되지 않는 지표	웹사이트 방문 수, 다운로드 수, 조회수	왜 증가했는지, 무엇을 해야 하는지 알기 어려움
실행 가능한 지표 actionable metrics	원인과 결과가 명확해 다음 행동을 결정할 수 있는 지표	A/B 테스트 결과, 배포 시간 감소, 결함 발견 비율	개선 행동과 연결 가능

예를 들어 웹사이트 방문 수가 증가했다고 해서 반드시 서비스가 좋아졌다고 말할 수는 없습니다.

방문자는 늘었지만 실제 가입이나 구매로 이어지지 않을 수도 있습니다. 또는 광고를 많이 집행해서 일시적으로 방문자가 늘어난 것일 수도 있습니다.

반면 실행 가능한 지표는 다음 행동을 결정하는 데 도움이 됩니다.

예를 들어 A/B 테스트를 통해 새로운 결제 화면이 기존 화면보다 전환율을 높였다는 결과가 나왔다면, 그 기능을 확대 적용할 근거가 됩니다.

즉, 좋은 지표는 단순히 숫자가 올라가는 것을 보여주는 것이 아니라, 왜 그런 결과가 나왔고 다음에 무엇을 해야 하는지 알려줘야 합니다.

마무리

이번 글에서는 DevOps에서 측정이 왜 중요한지 살펴봤습니다.

측정은 단순히 숫자를 모으는 일이 아닙니다. 조직이 어떤 행동을 중요하게 생각하는지 보여주는 신호이며, 팀의 일하는 방식을 바꾸는 기준이 될 수 있습니다.

코드 라인 수처럼 겉으로 보기에는 생산성을 보여주는 것 같지만 실제 품질과는 거리가 먼 지표도 있고, 웹사이트 방문 수처럼 보기에는 좋아 보이지만 다음 행동을 결정하기 어려운 허영 지표도 있습니다.

반대로 실행 가능한 지표는 원인과 결과가 비교적 명확하고, 팀이 어떤 개선을 해야 할지 판단하는 데 도움을 줍니다.

결국 DevOps에서 중요한 것은 “많이 측정하는 것”이 아니라, 팀이 더 빠르게 배우고 더 안정적으로 가치를 전달하도록 돕는 지표를 선택하는 것입니다.

다음 글에서는 DevOps에서 실제로 활용할 수 있는 핵심 지표들, Nicole Forsgren이 제시한 DevOps 성과 지표, 팀 문화 측정, 그리고 SRE와의 관계까지 이어서 정리해보겠습니다.