An Upper Bound on the Probability That a User Encounters an Undiscovered Defect

거대한 버그 사냥: 왜 버그의 개수를 세는 것만으로는 충분하지 않은가

당신이 수천 명의 손님에게 거대한 연회를 대접하려는 셰프라고 상상해 보십시오. 문을 열기 전, 당신은 음식을 맛보고 "이 수프는 너무 짜요!"라거나 "케이크 안에 돌이 들어 있어요!"라고 외치는 맛 테스터들(베타 테스터) 팀을 보유하고 있습니다. 당신은 그들이 찾아낸 문제들을 해결합니다. 하지만 여기서 무서운 질문이 하나 생깁니다. 만약 지금 바로 문을 연다면, 무작위로 들어오는 손님이 당신이 놓친 돌을 씹게 될 확률은 얼마나 될까요?

이것이 바로 컴퓨터 과학에서 "소프트웨어 신뢰성(software reliability)"이라고 불리는 문제의 핵심입니다. 수십 년 동안 개발자들은 이 질문에 답하기 위해 '계수(counting)'를 시도해 왔습니다. 그들은 "주방에 돌이 몇 개나 남았는가?"라고 묻습니다. 그들은 숨겨진 버그의 총 개수를 추측하기 위해 복잡한 수학을 사용합니다. 하지만 여기 함정이 있습니다. 남은 돌이 열 개라는 것을 아는 것이, 그 돌들이 모두 (단 한 사람만이 발견할 법한) 뒷방 찬장에 있는지, 아니면 하나의 거대한 바위가 정문 바로 앞에 놓여 있는지(모두가 걸려 넘어질 곳)를 알려주지는 않는다는 점입니다. 기존의 방식들은 종종 돌의 개수를 세는 데 매몰되어, 그 돌들이 어디에 있느냐에 따라 얼마나 더 위험할 수 있는지를 간과하곤 합니다.

이 문제를 해결하기 위해, 우리는 돌의 개수를 세는 것을 멈추고 사람의 수를 세기 시작해야 합니다. 우리는 무작위의 사람이 실제로 문제에 부딪힐 확률을 알아야 합니다. 이 논문은 바로 그 질문을 다룹니다. "남은 버그가 몇 개인가?"라고 묻는 대신, "사용자가 이전에 본 적 없는 버그를 마주칠 확률은 얼마인가?"라고 묻습니다. 알고 보니, 테스터들이 동일한 버그를 두 번 이상 발견하는 빈도를 살펴보는 기법을 통해 이를 추측할 수 있는 놀랍도록 간단한 방법이 존재합니다.

---

논문의 핵심 아이디어: "원타임 원더(One-Time Wonder)" 법칙

저자인 카를로스 M. 헤르난데스-수아레스(Carlos M. Hernández-Suárez)와 카를라 헤르난데스-쿠에바스(Karla Hernández-Cuevas)는 영리한 지름길을 제안합니다. 그들은 사용자가 숨겨진 버그를 만날 위험을 예측하기 위해, 버그의 총 개수를 알 필요도, 소프트웨어가 어떻게 만들어졌는지 알 필요도, 심지어 얼마나 많은 사람이 사용하는지도 알 필요가 없다고 제主張합니다. 단지 버그 보고서를 살펴보고 매우 구체적인 것을 세기만 하면 됩니다. 바로 정확히 한 번만 보고된 버그들입니다.

비유를 들어보겠습니다. 당신이 마을을 방문 중인 외계인의 종류가 얼마나 다양한지 파악하려는 탐정이라고 상상해 보십시오. 당신에게는 목격 기록부가 있습니다.

• 만약 "조그(Zog)"를 50번 보았다면, 조그는 흔한 외계인임을 알 수 있습니다.
• 만약 "실(Xyl)"을 3번 보았다면, 실은 조금 더 희귀한 존재입니다.
• 하지만 만약 "블롭(Blorp)"을 정확히 한 번만 보고했고 다시는 보지 못했다면, 그것은 무엇을 의미할까요?

이 논문은 이 "블롭들"—즉, 단 한 번만 보고된 버그들—이 핵심이라고 주장합니다. 저자들은 이러한 단일 목격 횟수($s$)를 전체 목격 횟수($n$)로 나눈 값을 "보수적 상한선(conservative upper bound)"이라고 부릅니다. 쉬운 말로 설명하자면: 버그가 정확히 한 번만 보고된 비율은, 사용자가 처음 보는 버그를 마주치게 될 비율에 대한 안전하고 "최악의 경우"를 가정한 추측치입니다.

이것이 작동하는 이유 ("닫힌 문"의 논리)

여러분은 이렇게 의문을 가질 수 있습니다. "만약 다른 버그 뒤에 버그가 숨겨져 있다면 어떡하죠? 마치 잠긴 문 뒤에 비밀의 방이 있는 것처럼 말입니다." 저자들은 이 점을 탁월한 논리로 해결합니다.

소프트웨어를 많은 방이 있는 거대한 저택이라고 상상해 보십시오. 어떤 버그들은 복도에 있습니다 (찾기 쉽습니다). 어떤 버그들은 잠긴 문 뒤의 비밀의 방에 있습니다 (찾기 어렵습니다).

• 사용자가 잠긴 문(버그)에 부딪히면, 그 뒤의 비밀의 방으로 들어갈 수 없습니다.
• 따라서, 비밀의 방에 도달할 수 있는 사람의 수는 그 문을 치게 될 사람의 수보다 항상 적거나 같습니다.

저자들은 이러한 "중첩된(nested)" 구조 덕분에, 숨겨진 방들을 걱정할 필요가 없음을 보여줍니다. 우리가 실제로 발견한 "단일 보고" 버그들이 이미 숨겨진 것들의 위험을 설명해 줍니다. 만약 어떤 버그가 한 번 보고되었다면, 그것은 그 뒤에 있는 모든 것의 위험을 제한하는 "문" 역할을 합니다. 따라서 단일 보고를 세는 것만으로도 집 전체를 커버하기에 충분합니다.

그들이 수행한 작업과 발견한 사실

저자들은 단순히 추측만 한 것이 아니라, "캐노니컬 폼(Canonical Form)"(색깔이 있는 공들이 담긴 특수한 형태의 항아리나 단지로 생각하면 됩니다)이라는 수학적 모델을 구축했습니다. 그들은 버그 보고를 이 항아리에서 공을 뽑는 과정처럼 취급한다면, 단 한 번 나타나는 공의 비율($s/n$)이 "미발견된 질량(missing mass, 즉 보이지 않는 버g들)"에 대한 **정확한 최대 가능도 추정치(maximum-likelihood estimate)**임을 수학적으로 증명했습니다.

결정적으로, 그들은 이 추정치가 **보수적(conservative)**이라는 것을 보여주었습니다. 이는 이 방식이 위험을 과소평가하기보다는 과대평가하는 경향이 있다는 뜻입니다.

• 이것이 좋은 이유: 소프트웨어 출시 여부를 결정하는 개발자라면, 안전을 기하고 싶을 것입니다. 수학이 "버그가 발생할 확률이 5%입니다"라고 하고 실제 확률이 3%라면, 당신은 안전합니다. 만약 수학이 3%라고 했는데 실제가 5%였다면, 당신은 곤경에 처하게 될 것입니다. 이 방법은 항상 주의를 기울이는 방향으로, 즉 보수적인 쪽으로 편향되도록 보장합니다.

그들은 컴퓨터 시뮬레이션(알려진 정답을 가진 가상의 버그 집단을 생성)을 통해 이 아이디어를 테스트했습니다.

• 20개의 버그가 있는 한 테스트에서, 그들은 "테스트"하는 사용자(표본 크기를 25에서 400으로 증가시킴)가 늘어남에 따라, 추정치($s/n$)가 항상 실제 보이지 않는 버그의 수보다 크거나 같다는 것을 발견했습니다.
• 예를 들어, 100명의 테스트 사용자가 있을 때, 실제 보이지 않는 위험은 0.0059였고, 그들의 추정치는 0.0063이었습니다. 추정치가 약간 높게(보수적으로) 나왔지만, 결코 낮게 나오지는 않았습니다.

이것이 '아닌' 것 (게임의 규칙)

이 논문은 이 방법이 무엇을 할 수 없는지에 대해 매우 명확히 밝히고 있으며, 이를 정확히 이해하는 것이 중요합니다:

1. 이것은 버그의 개수를 세기 위한 것이 아닙니다. "버그가 50개 남았다"라고 말해주지 않습니다. 대신 "사용자가 버그를 만날 확률이 2%이다"라고 말해줍니다.
2. 이것은 공개적인 버그 리스트용이 아닙니다. 저자들은 일반적인 버그 데이터베이스(인터넷에 있는 것들)에 이 방법을 사용하는 것을 명시적으로 금지합니다. 왜냐하면 그러한 리스트에서는 보통 한 사람이 보고했더라도 실제로는 1,000명이 발견한 버그일 수 있기 때문입니다. 즉, "카운트"가 유실됩니다. 이 방법을 사용하려면, 단순히 "이 버그가 보고됨"이 아니라, "이 버그가 50명의 서로 다른 사용자에게 발생함"과 같은 데이터가 필요합니다.
3. 이것은 미래를 보는 마법의 수정구가 아닙니다. 이것은 지금 당장의 위험을 보여주는 스냅샷입니다. 버그를 수정하고 다시 테스트한다면, 반드시 다시 계산해야 합니다.

결론

이 논문은 출시 결정에 대해 직접적이고 군더더기 없는 답을 제공합니다. "어둠 속에 얼마나 많은 버그가 숨어 있는지 걱정하지 마십시오. 대신 테스터들이 정확히 한 번 발견한 버그가 몇 개인지만 보십시오. 그 숫자를 전체 테스트 횟수로 나눈 값이, 당신이 놓친 버그로 인해 사용자가 곤경에 처할 확률에 대한 안전한 상한선 추측치입니다."

이 도구는 복잡하고 두려운 불확실성을 단순하고 안전한 숫자로 바꾸어 줍니다. 이를 통해 소프트웨어가 출시될 때, 개발자들이 사용자에게 미칠 위험에 대해 명확하고 보수적인 관점을 가질 수 있도록 보장합니다.