5.1

5.1 누락된 결함률과 품질 누락

개요 및 동기

누락된 결함률은 이 책의 4부에서 모두 다룬, 테스트, 코드 리뷰, 혹은 정적 분석을 통해 더 일찍 잡힌 결함과 구별되는, 프로덕션에 도달해 실제 사용자에게 영향을 미치는 결함을 측정한다. 그 구분은 엄청나게 중요하다: 코드 리뷰에서 잡힌 결함은 고치는 데 몇 분이 들고 어떤 사용자도 결코 그것을 보지 못한다. 같은 결함이 프로덕션으로 누락되면, 몇 시간의 인시던트 대응, 실제 고객 피해, 신뢰에 측정 가능한 손상을 초래할 수 있다. 이 메트릭은, 실제적인 의미에서, 4부가 다루는 모든 것에 대한 최종 성적표인데, 강한 내부 품질 메트릭(복잡도, 커버리지, 정적 분석)에도 불구하고 상승하는 누락된 결함률은 보통 그 내부 신호들이 실제 사용자에게 중요한 실패 양상을 실제로 잡아내지 못하고 있다는 것을 의미하기 때문이다.

이 주제는 원시 개수를 단순한 점수판으로 취급하고 싶은 유혹에 저항하면서 누락된 결함을 그 비용이 받을 자격이 있는 진지함으로 다룬다. 모든 결함이 동등한 것은 아니다: 거의 보지 않는 도움말 텍스트의 오타와 금융 거래 시스템의 데이터 손상 버그는 둘 다, 기술적으로는, 누락된 결함이며, 그것들을 동일하게 취급하는 것은 행동에 옮기기에는 너무 시끄럽거나, 더 나쁘게는, 실제 위험이 어디에 사는지에 대해 적극적으로 오도하는 메트릭을 만들어 낸다. 결함이 어떻게 분류되는지에 대한 세심한 주의를 가진 심각도 가중 추적인 이 주제의 핵심 권장 사항은 바로 그 문제를 직접 겨냥한다.

대규모 팀에게 누락된 결함률은 이 책의 내부 엔지니어링 메트릭과 5부 전체가 관심을 가지는 고객 대면 세계 사이의 가장 명확한 다리 중 하나다. 엔터프라이즈 조직은 그것을 사용해 4부의 테스트 및 리뷰 관행에 대한 투자를 정당화한다. 정부 조직은, 누락된 결함이 잘못된 혜택 계산이나 실패한 공공 서비스 상호작용을 의미할 수 있는 곳에서, 그것을 단순한 내부 엔지니어링 통계가 아니라 공공 신뢰와 법적 노출에 대한 직접적인 측정치로 취급한다.

핵심 원칙

  • 누락된 결함률은 내부 품질 관행에 대한 최종 성적표다. 강한 4부 메트릭에도 불구하고 상승하는 비율은 그 메트릭들이 중요한 것을 잡아내지 못하고 있다는 것을 의미한다.
  • 심각도가 원시 개수보다 더 중요하다. 모든 누락을 동일하게 취급하는 대신 실제 고객이나 비즈니스 영향으로 결함에 가중치를 두라.
  • 분류 일관성이 필수적이다. 심각도를 다르게 분류하는 두 팀은 공정하게 비교할 수 없는 수치를 만들어 낸다.
  • 이 메트릭은 정확히 변경 실패율(주제 2.10)처럼 정의 게임에 노출된다: 무엇이 “결함”으로 집계되는지를 좁히는 것은 실제 고객 피해를 줄이지 않으면서 수치를 치장한다.
  • 근본 원인 범주화는 개수를 진단 도구로 바꾼다. 몇 개나 누락되었는지만 아는 것보다 왜 결함이 누락되는지 아는 것이 더 실행 가능하다.

권장 사항

일관되고 문서화된 척도를 사용해 누락된 결함에 심각도로 가중치를 두라

실제 고객이나 비즈니스 영향에 근거한 고정된 심각도 척도(흔히 치명적, 주요, 사소, 혹은 번호가 매겨진 등가물)를 사용해 모든 누락된 결함을 분류하라: 데이터 손실이나 손상, 보안 노출, 완전한 기능 이용 불가능성은 최상단에 자리하고, 기능적 영향이 없는 미적 문제는 최하단에 자리한다. 사소한 문제의 급증이 더 작지만 훨씬 더 결과가 큰 치명적인 문제의 증가를 시각적으로 압도하지 않도록, 원시 개수가 아니라 심각도 가중 추세를 추적하라.

팀 전반에 걸쳐 분류 기준을 표준화하라

독립적으로 심각도를 분류하도록 남겨진 다른 팀들은 서로 다른 기준으로, 일부는 보수적으로, 일부는 관대하게 드리프트할 것이며, 이는 팀 간 비교를 무의미하게 만들고, 더 나쁘게는, 팀 자체의 수치를 더 좋아 보이게 유지하기 위해 관대하게 아래로 분류하려는 유인을 만들어 낸다(주제 1.2의 정의 게임의 한 변형). 명확하고 사례에 기반한 분류 기준을 발행하고, 일관성을 확인하기 위해 팀 전반에 걸쳐 분류의 표본을 주기적으로 감사하라.

개수와 심각도뿐 아니라 근본 원인을 추적하라

모든 누락된 결함에 대해, 왜 그것이 누락되었는지 기록하라: 테스트 간극, 요구 사항에서 놓친 경계 사례, 스테이징과 프로덕션 사이의 환경 차이, 그 문제를 놓친 리뷰. 이 근본 원인 데이터를 시간에 따라 집계하여 체계적인 패턴을 찾아라. 특정 범주(가령 환경 차이 결함)가 당신의 누락을 지배한다면, 그것은 “더 많이 테스트하라”는 막연하고 일반적인 요청이 아니라 구체적이고 고칠 수 있는 프로세스 간극을 직접 가리킨다.

누락된 결함을 그 근원이 되는 내부 품질 신호로 다시 연결하라

가능한 곳에서는, 누락된 결함을 그것이 나온 코드 영역으로 거슬러 추적하고 그 영역이 4부의 메트릭에서 경고 신호를 보였는지 확인하라: 그것은 복잡도 핫스팟이었는가(주제 4.1, 주제 4.3), 낮은 뮤턴트 제거율을 가졌는가(주제 4.2), 근처에서 정적 분석이 무언가를 표시했는가(주제 4.4). 이 연결이야말로 당신의 내부 품질 메트릭이 실제 고객 대면 결함에 대해 실제로 예측적인지, 아니면 당신의 특정 맥락에서 고객이 실제로 경험하는 것과 상관관계가 없는 무언가를 측정하고 있는지를 검증한다.

결함 분류가 비난 훈련이 되지 않도록 경계하라

주제 1.1의 진단적 프레이밍에 따라 결함 근본 원인 분석을 개인 비난 훈련이 아니라 명시적으로 시스템 질문으로 프레이밍하라. 누락된 결함에 대해 비난을 두려워하는 팀은 과소 보고하거나, 아래로 잘못 분류하거나, 철저한 근본 원인 분석에 저항할 강한 유인을 가지며, 이 모두는 이 주제가 의존하는 바로 그 데이터를 타락시킨다. 주제 6.2에서 더 깊이 다루는 비난 없는 포스트모템 관행이 여기에 직접 적용된다.

트레이드오프: 장단점

접근법장점단점
원시 누락된 결함 개수보고하기 단순함오타와 데이터 손상 버그를 동일하게 취급함; 시끄럽고 오도함
심각도 가중 추적실제 고객 영향을 더 정확하게 반영함일관되고 규율 있는 분류가 필요함
팀 독립적인 분류 기준유연하고, 낮은 조정 오버헤드팀 간 비교할 수 없는 수치를 만들어 냄; 관대한 드리프트를 초래함
표준화되고 감사된 분류공정하고, 비교 가능하며, 게임에 저항함지속적인 거버넌스와 주기적인 감사 노력이 필요함

핵심 긴장은 지역적 유연성 대 팀 간 비교 가능성이다. 각 팀이 자신의 맥락에 맞는 방식으로 결함 심각도를 분류하게 두는 것은 구현하기 더 단순하지만 조직 수준에서 공정하게 비교하거나 집계할 수 없는 수치를 만들어 내며, 팀이 자신의 메트릭을 보호하기 위해 관대하게 분류하려는 조용한 유인을 만든다. 이 메트릭이 실제 고객 영향에 얼마나 직접적으로 연결되는지를 고려할 때, 이것을 투자할 가치가 있는 거버넌스 작업(주제 1.4)으로 취급하며, 표준화되고 문서화된 분류 기준과 주기적인 팀 간 감사에 투자함으로써 이 긴장을 해결하라.

팀과 논의할 질문

  1. 우리는 심각도별로 누락된 결함을 추적하는가, 아니면 원시 개수가 사소한 미적 문제를 치명적인 데이터 문제와 동일하게 취급하는가? 당신의 실제 대시보드를 가져와 확인하라. 심각도 가중치가 아직 자리 잡지 않았다면, 이것이 이 주제가 권장하는 단일한 가장 가치 높은 변화다.

  2. 두 다른 팀이 같은 결함의 심각도를 같은 방식으로 분류할까, 아니면 분류가 조직 전반에 걸쳐 서로 벌어졌는가? 실제이고 모호한 과거의 결함을 골라 두 다른 팀의 대표자가 독립적으로 그것을 분류하게 하라. 그 결과를 정직하게 비교하라.

  3. 우리의 누락된 결함에 대한 가장 흔한 근본 원인은 무엇이며, 우리의 현재 절차는 실제로 그것을 다루는가, 아니면 그저 개별 인시던트가 발생할 때마다 계속 대응하는가? 지난 몇 달간의 근본 원인 데이터를 집계하고 지배적인 패턴을 찾아보라.

  4. 우리의 누락된 결함이 우리의 내부 품질 메트릭(복잡도, 커버리지, 정적 분석)이 이미 위험하다고 표시한 영역으로 거슬러 추적된 적이 있는가? 이 연결은 당신의 4부 메트릭이 당신의 특정 맥락에서 진정으로 예측적인지, 아니면 실제로 중요한 실패 양상을 놓치고 있는지 검증한다.

  5. 우리의 결함 분류 절차는 안전하게 느껴지는가, 아니면 엔지니어가 자신과 연관된 결함을 보고하거나 분류할 때 비난을 두려워하는가? 비난하기 쉬운 문화는 과소 보고와 관대한 분류를 통해 체계적으로 이 데이터를 타락시킨다. 여기서 당신의 현재 문화에 대해 정직해져라.

  6. 우리의 누락된 결함률이 테스트나 리뷰 관행의 상응하는 변화 없이 의심스러울 만큼 빠르게 개선된 적이 있는가? 변경 실패율(주제 2.10)과 마찬가지로, 이것은 실제 위험이 아니라 분류 기준이 움직였다는 가장 명확한 신호다.

분야별 관점

스타트업. 공식적인 심각도 분류는 소량의 결함과 각각을 직접 논의할 수 있는 소규모 팀에서는 흔히 불필요하다. 일찍 채택할 가치가 있는 습관은 단순히 비공식적일지라도 처음부터 일관되게 결함을 추적하는 것이며, 그래야 팀이 더 공식적인 분석이 필요할 만큼 충분히 성장했을 때 역사적 데이터가 존재한다.

중소기업. 지원과 버그 트리아지를 담당하는 사람이 일관되게 적용하는 단순하고 공유된 심각도 척도, 심지어 세 단계(치명적, 주요, 사소)만으로도, 정교한 도구나 전담 품질 기능 없이도 이 주제의 가치 대부분을 포착한다.

엔터프라이즈. 팀 간 분류 일관성이 여기서 가장 레버리지가 높은 투자인데, 수십 개 팀에 걸친 일관성 없는 기준은 조직 전체의 품질 비교를 무의미하게 만들기 때문이다. 문서화되고 사례에 기반한 분류 기준과 주기적인 감사에 투자하고, 당신의 조직에서 어떤 신호가 실제로 예측적인지 검증하기 위해 체계적으로 누락된 결함을 4부의 내부 품질 신호에 다시 연결하라.

정부. 대민 서비스나 혜택 계산 시스템에서의 누락된 결함은 그 엔지니어링 비용을 넘어선 법적이고 공공 신뢰적인 무게를 지닌다. 시민 대면 서비스에 영향을 미치는 결함에 대해 특별한 엄격함으로 심각도 분류를 다루고, 분류 결정이 외부 정밀 조사에 직면할 준비를 하라. 이는 즉흥적인 판단 호출보다 문서화되고, 감사되고, 일관된 기준에 대한 강력한 논거다.

사례

엔터프라이즈. 한 구독 소프트웨어 회사의 누락된 결함 수는 두 분기 동안 상승해 왔고, 초기 우려는 원시 수치에 집중되었다. 심각도 가중 분석은 그 증가가 거의 전적으로 최근의 UI 재설계와 일치하는, 사소하고 미적인 문제에 있었던 반면, 치명적이고 주요한 결함은 같은 기간 동안 실제로 약간 감소했다는 것을 드러냈다. 사소한 문제 급증에 대한 근본 원인 분석은 특별히 새로운 UI 구성 요소에 대한 시각적 회귀 테스트의 간극을 가리켰으며, 이는 만약 팀이 원시의, 가중치 없는 수치를 미분화된 품질 위기로 받아들여 대응했더라면 완전히 놓쳤을, 목표를 겨냥한 저비용의 수정이었다.

정부. 한 주 실업 기관의 혜택 계산 시스템은 탐지되기까지 몇 달 동안 그렇지 않으면 자격이 있었을 청구의 작은 비율을 잘못 거부한 누락된 결함을 가지고 있었다. 근본 원인 조사는 그 결함이 18개월 전 내부 품질 리뷰에서 이전에 복잡도 핫스팟(주제 4.1, 주제 4.3)으로 표시된 코드 영역에서 비롯되었다는 것을 발견했지만, 그 핫스팟은 그 위험을 구체화할 결함이 아직 발생하지 않았기 때문에 개선 우선순위로 매겨진 적이 없었다. 그 기관의 개정된 절차는 이제 내부 복잡도 신호와 실제 누락된 결함 위험 사이의 이 입증되고 검증된 연결 때문에 특별히 핫스팟으로 표시된 영역에 테스트와 리뷰 우선순위에서 더 높은 가중치를 둔다.

비즈니스 사례: 동기, ROI, TCO

심각도 가중치와 근본 원인 분석으로 누락된 결함률을 엄격하게 추적하는 것의 수익은 사소한 문제와 심각한 문제를 무분별하게 섞는 미분화된 개수에 반응하는 대신 품질 투자를 실제로 고객 대면 피해를 줄일 곳으로 이끄는 능력이다. 위의 구독 소프트웨어 사례는 이것을 명확하게 보여 준다: 원시 개수 반응은 광범위하고 초점 없는 품질 이니셔티브를 촉발했을 것이지만, 심각도 가중되고 근본 원인에 정보를 받은 대응은 구체적이고 저렴하며 목표를 겨냥한 수정을 식별했다.

총 소유 비용은 분류 규율(일관된 기준, 주기적인 감사)과 근본 원인 추적 노력을 포함하며, 둘 다 주로 도구 비용이 아니라 프로세스 투자다. 그 투자는 품질 노력을 누락된 결함 위험의 실제이고 검증된 출처로 이끔으로써 예방된 고객 피해와 인시던트 대응의 비용에서 직접 그 자체 비용을 회수한다.

안티패턴과 함정

  • 원시 결함 개수를 메트릭으로 취급하기: 사소한 문제와 심각한 문제를 뒤섞고 실제 신호를 흐린다.
  • 팀 전반의 일관성 없는 심각도 분류: 팀 간 비교를 무의미하게 만들고 관대한 분류 드리프트를 초래한다.
  • 근본 원인 추적 없음: 개수를 아무런 진단 가치도 없는 수치로 바꾸고, 체계적인 패턴을 보이지 않게 남긴다.
  • 비난하기 쉬운 보고 문화: 과소 보고와 관대한 분류를 통해 데이터를 타락시키며, 이는 정확히 주제 1.2가 경고하는 인센티브 노출 위험이다.
  • 누락된 결함을 내부 품질 신호로 결코 다시 연결하지 않기: 4부의 예측적 메트릭을 실제 결과에 비추어 검증하거나 무효화할 기회를 놓친다.
  • 그 배후의 프로세스 변화 없이 의심스러울 만큼 빠른 개선: 실제 위험이 아니라 분류 기준이 이동했다는 가장 명확한 신호.

성숙도 모델

  • 1단계, 시작: 누락된 결함이, 추적된다면, 심각도 가중치나 근본 원인 분석 없이 원시 개수로 추적된다.
  • 2단계, 개발: 일부 심각도 분류가 존재하지만, 기준이 팀 전반에 걸쳐 다양하고 근본 원인 추적이 일관성이 없다.
  • 3단계, 표준화: 심각도 분류가 조직 전체에서 표준화되고 문서화되며, 근본 원인 범주화가 일관되게 적용된다.
  • 4단계, 관리: 누락된 결함이 그 예측적 가치를 검증하기 위해 체계적으로 내부 품질 신호로 거슬러 추적되며, 분류가 일관성을 위해 주기적으로 감사된다.
  • 5단계, 조율: 조직은 내부 품질 신호에 비추어 검증된, 목표를 겨냥하고 근본 원인에 정보를 받은 품질 투자로 거슬러 올라가는 누락된 결함률의 구체적이고 측정 가능한 감소를 제시할 수 있다.

논의를 위한 아이디어

  1. 지난 분기의 우리의 상위 누락된 결함은 다른 팀에 의해 같은 방식으로 분류되었을까?
  2. 우리의 누락된 결함에 대한 가장 흔한 근본 원인은 무엇이며, 우리는 실제로 그것을 다루고 있는가?
  3. 누락된 결함이 우리의 내부 메트릭이 이미 표시한 영역으로 거슬러 추적된 적이 있는가?
  4. 우리 팀은 그들이 야기한 결함을 보고하고 정직하게 분류하는 것이 안전하다고 느끼는가?
  5. 우리의 현재 결함 개수에 대한 심각도 가중 관점은 원시 개수가 숨기는 무엇을 드러낼까?

핵심 요약

  • 누락된 결함률은 내부 품질 관행에 대한 최종 성적표다. 강한 4부 메트릭에도 불구하고 상승하는 비율은 그 메트릭들이 중요한 것을 잡아내지 못하고 있다는 것을 의미한다.
  • 일관되고 문서화되고 감사된 분류 척도를 사용해 심각도로 가중치를 두고, 결코 원시 개수 홀로 사용하지 마라.
  • 메트릭을 진정한 진단 도구로 바꾸기 위해 개수와 심각도뿐 아니라 근본 원인을 추적하라.
  • 그 신호들이 실제로 예측적인지 검증하기 위해 누락된 결함을 내부 품질 신호(복잡도, 커버리지, 정적 분석)로 다시 연결하라.
  • 과소 보고와 관대한 드리프트를 통해 보고와 분류를 타락시키는 비난하기 쉬운 문화를 경계하라.

참고 문헌 및 추가 자료

  • Beyer, Betsy, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media, 2016.
  • Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
  • McConnell, Steve. Code Complete: A Practical Handbook of Software Construction. Microsoft Press, 2004.
  • Dekker, Sidney. The Field Guide to Understanding Human Error. CRC Press, 2014.