버그라고 부르는 것의 정체 — 오류·결함·실패·이상

개념

'버그'는 표준 용어가 아니다

모듈 1 레슨 2에서 오류(error)·결함(defect)·실패(failure)를 구분하고 전파 구조를 배웠다. 사람이 실수하면(오류) 산출물에 결함이 남고, 그 결함이 실행되면 실패가 나타난다.

그 지식 위에서 이 레슨이 묻는 것은 하나다. 그럼 우리가 매일 쓰는 '버그'는 그중 무엇인가?

답은 "맥락에 따라 다 다르다"이다. 그리고 그게 문제다.

"버그 등록했어요"          → 결함(defect)을 가리킨다
"버그 났어요"              → 실패(failure)를 목격했다는 뜻이다
"이거 버그 아니에요?"       → 이상(anomaly)인지 의도된 동작인지 묻는 것이다
"그 버그 원인이 뭐예요?"    → 결함의 위치를 묻는다
"버그 세 건 수정"          → 결함 세 건을 고쳤다는 뜻

한 단어가 다섯 가지를 가리킨다. 팀 안에서는 맥락으로 통하지만, 리포트와 지표에서는 이 뭉뚱그림이 비용이 된다.

표준 용어 다섯 개

이 정의들은 ISO/IEC/IEEE 24765(시스템·소프트웨어 공학 어휘)와 ISO/IEC/IEEE 29119 계열, 그리고 IEEE 1044(소프트웨어 이상 분류)에 근거한다. 모듈 8에서 29119를 다뤘는데, 29119의 동적 테스트 프로세스에 '인시던트 보고' 라는 활동이 있는 것이 이 체계 때문이다.

왜 '이상(anomaly)'이 따로 있는가

여기가 실무적으로 가장 쓸모 있는 구분이다.

테스터가 뭔가 이상한 걸 봤다
        ↓
     이상(anomaly)  ← 이 시점에는 이게 정확한 이름이다
        ↓
     조사한다
        ↓
   ┌────┴─────┬──────────┬──────────┐
결함이다    의도된 동작   환경 문제   테스트 오류
(defect)   (as designed) (environment) (test error)

발견 시점에는 그것이 결함인지 알 수 없다. 그래서 표준은 중립적인 이름을 준다. 조사 후에야 결함인지 아닌지가 정해진다.

이 구분을 아는 팀과 모르는 팀의 차이:

[모르는 팀]  "버그 등록했는데 개발자가 '이건 버그 아니다'라고 반려함"
             → 등록한 사람이 틀린 것처럼 느껴진다
             → 반려율이 개인 평가처럼 작동한다
             → 애매하면 등록을 안 하게 된다  ← 가장 나쁜 결과
 
[아는 팀]   "이상 보고했고 조사 결과 의도된 동작으로 분류됨"
             → 정상적인 절차의 한 갈래일 뿐이다
             → 애매해도 일단 보고한다

반려(Rejected)가 실패가 아니라 분류 결과가 된다. 모듈 6 레슨 1에서 본 결함 생명주기의 Rejected 상태가 이 관점에서 다시 읽힌다.

관계를 한 그림으로

 [사람]              [산출물]                [실행]            [보고]
  오류        →       결함          →         실패      →      인시던트
 (error)          (defect/fault)          (failure)        (incident)
  실수           코드·문서에 남은 결점       관찰된 사건       조사 대상 기록
 
                      ↑                        ↓
                  조사로 도달             테스터가 목격
                      └────── 이상(anomaly) ──────┘
                          "뭔가 어긋난 것"의 중립적 이름

리포트에 적는 것은 실패의 증상이고, 고치는 것은 결함이다. 이 둘을 섞으면 리포트가 모호해진다.

리포트에서 정확한 대상 가리키기

용어를 아는 것의 실익은 문장에서 나온다.

✗  "로그인 버그"
     → 무엇을 가리키는지 모호하다
 
✓  제목(실패의 증상): 비밀번호 20자 입력 시 로그인 실패
   원인(결함의 위치): 인증 API의 입력 길이 검증이 16자로 하드코딩됨
   영향(실패의 범위): 20자 이상 비밀번호 사용자 전원 로그인 불가

제목은 실패로 쓰고, 원인은 결함으로 쓴다. 이 구조가 모듈 6에서 배운 "개발자가 되묻지 않는 결함 리포트"의 언어적 토대다.

지표가 달라진다

용어를 섞어 쓰면 숫자의 뜻이 흔들린다.

결함 1건이 실패 50건을 만들 수 있다
  → "실패 50건"과 "결함 1건"은 같은 상황의 다른 숫자다
  → 둘을 섞어 "버그 51건"이라고 보고하면 아무 의미가 없다

경영진에게 보고하는 숫자가 이 셋 중 무엇인지 를 정하지 않으면 품질 추세 그래프가 활동량 그래프가 되기도 하고 품질 그래프가 되기도 한다. 모듈 26에서 다룬 품질 커뮤니케이션이 여기서 무너진다.

그럼 '버그'를 쓰지 말라는 건가

레슨 1의 "말과 글을 분리한다" 그대로다.

말할 때·팀 채널        "버그"  → 그대로 둔다. 자연스럽고 빠르다
이슈 트래커 이슈 타입   "Bug"   → 도구 기본값이다. 바꿀 실익이 적다
결함 리포트 본문       구분해서 쓴다 → 제목은 실패, 원인은 결함
대외 문서·성적서       "결함"  → 표준 용어를 쓴다
지표·보고서           정의를 명시 → "결함 건수(조사 확정 기준)"

고칠 곳은 리포트 본문·대외 문서·지표 정의 셋뿐이다.

한국어 대역어의 함정

영어 원어와 한국어 번역이 1:1로 안 붙는 경우가 있다.

fault 를 '오류'로 번역하는 문서를 만나면 특히 조심한다. 표준의 error와 정반대 위치를 가리키게 된다.

ISTQB 용어집도 'bug' 를 결함의 비공식 동의어로 다루고 'anomaly' 를 기대와 어긋난 조건 전반으로 둔다. 다만 규격과 용어집은 판·번역본마다 문구가 조금씩 다르므로, 문서에 인용할 때는 원문 정의를 확인한다. 번역본의 한 문장을 근거로 팀 규칙을 정하면 나중에 되돌려야 한다.

'하자'·'장애' — 다른 세계에서 온 두 단어

대역어 표의 다섯 줄 중 실무에서 실제로 사고를 내는 것은 '하자'와 '장애' 다. 둘은 QA 용어 체계 밖에서 들어온 말이다.

'하자'   ← 계약·검수의 언어.  하자보수·하자담보책임 조항과 묶여 있다
'장애'   ← 운영의 언어.       서비스가 멈춘 사건과 그 등급을 가리킨다
'결함'   ← 품질 공학의 언어.  산출물 안에 정적으로 존재하는 결점

세 단어가 가리키는 대상의 범위가 다르다. 결함은 아무도 겪지 않았어도 결함이고, 장애는 사용자가 겪어야 장애이고, 하자는 계약이 약속한 수준에 못 미친 것이다. 고쳐야 할 코드가 하나여도 세 문서가 세 가지로 센다.

계약서의 '하자' 는 특히 조심한다. 검수 회의에서 "결함 12건" 이라고 말한 숫자가 상대 회의록에 "하자 12건" 으로 적히면, 그 줄은 품질 보고가 아니라 의무의 범위에 관한 진술이 되어버린다. 숫자를 그대로 넘기는 대신 집계 기준을 함께 적는다.

경계 문구 — 계약상 '하자' 의 법적 범위와 책임은 법무·계약 담당자가 판단할 영역이다. 이 레슨은 "QA 의 '결함' 과 같다고 가정하지 말라" 까지만 말한다. 실제 해석이 필요한 자리에서는 전문가 확인을 받는다.

대외 문서 세 종류에 어떤 말을 쓰나

레슨 1의 "말과 글을 분리한다" 를 이 용어 체계에 적용하면 문서 유형별로 답이 갈린다.

두 번째 줄이 레슨 1의 원칙과 반대로 보인다. 대외 문서는 표준 용어로 쓰라고 했는데 여기서는 상대의 용어를 따르라고 한다. 차이는 그 문서가 누구의 문서인가 다. 우리가 발행하는 성적서는 우리가 용어를 고르고, 상대가 발행한 계약서의 용어는 우리가 바꿀 권한이 없다. 바꿔 적으면 그것 자체가 해석 행위가 된다.

'장애' 와 '결함' 을 한 표에 넣으면 숫자가 둘 다 거짓이 된다

가장 비싼 혼용이 이것이다. 두 집계는 모집단도 단위도 닫히는 조건도 다르다.

결함 1건(인증 토큰 만료 처리 누락)
  → 장애 3건(3월 2일·3월 9일·3월 16일 각각 로그인 불가)
  → 하자 0건 또는 1건(계약의 판단 기준에 따라 다르다)
 
같은 하나를 세 문서가 1 · 3 · 0~1 로 센다. 전부 맞는 숫자다.

둘을 한 대시보드에 올리면 양쪽이 동시에 거짓이 된다. 장애를 결함 표에 넣으면 결함 밀도가 부풀고(모듈 6 레슨 5), 결함을 장애 표에 넣으면 가동률 집계가 망가진다. 한쪽만 고쳐도 다른 쪽은 그대로 거짓으로 남는다.

섞였는지 확인하는 질문이 하나다. "이 표의 한 행이 닫히는 조건이 무엇인가?" 수정 완료와 서비스 복구가 한 열에 섞여 있으면 그 표는 이미 두 가지를 세고 있다.

도구의 이슈 타입과 용어 체계는 어디까지 맞추나

도구에서 이 다섯 용어를 그대로 구현할 필요는 없다. 손댈 자리가 정해져 있다.

이슈 타입 이름을 Anomaly 로 바꾸는 것은 거의 항상 손해다. 이름을 바꿔도 사람들은 '버그' 라고 부르고, 연동된 자동화·대시보드·필터만 깨진다. 모듈 6 레슨 4의 필드 설계 원칙이 그대로 적용된다 — 이름보다 값과 구조가 집계를 만든다.

효과가 나는 지점은 해결 값과 큐 분리 둘이다. 해결 값이 Fixed·Won't Fix 둘뿐이면 의도된 동작과 환경 문제가 전부 Won't Fix 로 들어가고, 그러면 집계에서 이 셋을 나눌 수 없다. 원인을 제품·테스트 자산·환경으로 나누는 분류 절차 자체는 모듈 8 레슨 5가 다루고, 이 레슨에서 할 일은 그 분류가 들어갈 칸을 도구에 만들어 두는 것 이다.

용어를 바꾼 날을 기록한다

지표의 이름이나 집계 기준을 바꾸면 그 전후의 숫자가 비교 불가능해진다 — 레슨 2(판 개정)·레슨 7(등급 체계)과 같은 문제다.

과거 데이터를 다시 라벨링하지 않는다. 재판정 비용이 얻는 것보다 크고, 재판정 자체가 또 하나의 기준 변경이 된다. 그래프에 세로선 하나와 "3월부터 확정 기준" 한 줄이면 충분하다.

사례 — 결함과 장애가 한 큐에 있던 11개월

공공 시스템 운영 이관 후의 SM 팀이다. Jira 프로젝트 하나에 결함과 장애를 같이 등록 했고, 11개월간 누적 1,860건 이 쌓였다.

실패. 분기 품질 보고에 "결함 건수 감소 추세" 로 올렸는데, 발주처 운영 점검에서 "같은 장애가 세 번 났는데 집계에 1건으로 보인다" 는 지적을 받았다.

원인. 1,860건 중 장애 기원이 412건 이었다. 결함 운영 규칙이 "같은 원인의 재발은 중복 병합" 이어서, 장애 재발이 병합되어 사라졌다. 반대 방향의 오염도 있었다 — 서비스 복구와 함께 Closed 로 닫힌 건이 87건 있었고, 그중 코드가 수정되지 않은 것이 대부분이었다.

바꾼 것. 큐를 둘로 나눴다(결함 프로젝트 / 운영 인시던트 프로젝트). 둘을 잇는 링크 타입 caused by 를 하나 만들었다. 해결 값에 As Designed·Environment·Test Asset 을 추가했다. 과거 1,860건은 손대지 않고 전환일 주석 한 줄 만 남겼다.

결과. 다음 분기에 장애 재발이 9건으로 집계 됐고(이전 기준으로는 3건이었다), 결함 쪽 Closed 중 미수정 건이 87건에서 4건 으로 줄었다. 그리고 링크가 쌓이자 장애 412건의 원인 결함이 71건 이라는 것이 보였다.

• 거짓이었던 쪽은 둘 다였다. 결함 추세는 부풀고 장애 재발은 지워졌다. 한쪽만 고치면 다른 쪽은 그대로 거짓으로 남는다
• 링크 타입 하나가 분리의 비용을 갚았다. 큐를 나누면 "그럼 둘의 관계는" 이 남는데, caused by 한 줄이 그 질문을 데이터로 만든다
• 용어 문제로 보였던 것이 자리 문제였다. 단어를 고르는 대신 표를 나누는 것 이 답이었다

실무에서 왜 필요한가

반려가 개인 평가로 작동하지 않는다

'이상 → 조사 → 분류'라는 구조를 팀이 공유하면 반려가 정상 절차가 된다. 그러면 애매한 것도 일단 보고하게 되고, 그게 발견율을 올린다. 반대로 반려를 실패로 취급하는 팀에서는 테스터가 확신 없는 관찰을 삼키게 되는데, 그중에 진짜가 섞여 있다.

지표가 의미를 갖는다

"이번 스프린트 버그 40건"이 무엇을 뜻하는지 아무도 모른다. "이상 보고 40건, 그중 결함 확정 28건, 의도된 동작 9건, 환경 3건"은 세 가지를 동시에 말한다 — 테스트 활동량, 제품 품질, 요구사항 명세의 모호함(의도된 동작이 많다는 것은 명세가 불명확하다는 신호다).

개발과의 대화가 짧아진다

"이거 버그예요"로 시작하는 대화는 "버그 아닌데요"로 이어진다. "이 동작이 명세와 어긋나 보여서 이상으로 등록했습니다. 의도된 동작이면 명세에 추가해 주세요"로 시작하면 논쟁이 아니라 확인 작업 이 된다.

채용시장에서의 위치

이 주제는 용어 퀴즈처럼 물어오지만 답에서 운영 경험이 드러나는 자리다. 정의를 외운 답과 집계를 책임져 본 답이 한 문장에서 갈린다.

네 번째가 가장 변별력이 크다. 앞의 셋은 용어집을 읽으면 답할 수 있지만, 네 번째는 두 집계를 동시에 책임져 본 사람만 하는 걱정이다. "구분이 안 된다" 는 답은 틀리지 않았지만 불편함을 말한 것이고, "양쪽이 동시에 거짓이 된다" 는 답은 그 표를 보고 의사결정하는 사람이 있다는 것을 안다 는 신호다. 면접관이 이어서 "그럼 어떻게 나누셨어요" 를 물으면, 큐 분리와 링크처럼 설정 수준의 구체성 이 나올 수 있어야 한다.

세 번째도 같은 역할을 한다. 결함 건수를 묻는 질문에 숫자 하나로 답하는 사람과 "어느 시점 기준으로 말씀드릴까요" 를 되묻는 사람의 차이는, 그 숫자가 경영 보고로 올라가 본 적이 있는지에서 온다. 그 다음에 거의 반드시 "반려된 건은 어디로 가나요" 가 따라오는데, 반려 사유를 갈래로 나눠 둔 경험 이 있으면 대화가 개선 활동 이야기로 넘어간다.

공고 표현으로는 "결함 관리 프로세스 수립", "품질 지표 정의·보고", "운영 품질 관리" 가 이 레슨에 걸린다. 특히 개발과 운영을 함께 보는 포지션 (SM·서비스 운영 인접 QA)에서는 장애와 결함을 분리해 본 경험이 그대로 평가 항목이 된다.

실습 과제

과제 1 — 최근 리포트 30건 재분류

최근 등록된 이슈 30건을 열어 각각이 실제로 무엇을 가리키는지 분류한다.

"혼재"가 몇 건인지 세어본다. 제목에 원인 추정이 섞여 있는 경우가 전형적인 혼재다.

과제 2 — 리포트 문장 다시 쓰기

과제 1에서 혼재로 분류된 것 5건을 본문의 3단 구조로 다시 쓴다.

제목(실패의 증상):
원인(결함의 위치):
영향(실패의 범위):

원인을 모르면 "원인: 미확인"이라고 적는다. 추정을 사실처럼 적지 않는 것 이 이 과제의 핵심이다.

과제 3 — 지표 정의서 만들기

우리 팀이 쓰는 품질 지표의 정의를 명시적으로 적는다.

"세는 시점" 칸이 중요하다. 등록 시점으로 세면 활동량이고, 조사 확정 시점으로 세면 품질이다. 둘 중 무엇을 보고할지 정한다.

과제 4 — 반려 사유 분류 체계 만들기

반려(Rejected)를 한 덩어리로 두지 말고 갈래를 나눈다.

의도된 동작 (as designed)      → 명세에 반영할 것인가?
재현 불가 (not reproducible)   → 조건이 부족했는가?
환경 문제 (environment)        → 환경 관리 개선 대상
테스트 오류 (test error)       → 테스트 케이스 수정
중복 (duplicate)               → 원본에 병합

각 갈래가 어떤 개선 활동으로 이어지는지 한 줄씩 적는다. 반려가 버려지는 데이터가 아니라 개선 입력이 된다.

과제 5 — 용어 번역 규칙 정하기

본문의 대역어 표를 우리 팀 기준으로 확정한다. 특히 다음을 결정한다.

• failure 를 '실패'로 쓸 것인가 '장애'로 쓸 것인가 (문서 유형별로 달라도 된다)
• anomaly 를 도입할 것인가, 아니면 '이슈'로 대체할 것인가
• incident 를 운영 장애와 어떻게 구분 표기할 것인가

결정을 레슨 8의 용어집에 반영한다.

자가 체크리스트

• '버그'가 맥락에 따라 무엇을 가리키는지 다섯 가지로 나눠 설명할 수 있다
• 오류·결함·실패·이상·인시던트의 정의를 각각 말할 수 있다
• 다섯 용어의 관계를 그림으로 그릴 수 있다
• '이상(anomaly)'이 별도 용어로 필요한 이유를 설명할 수 있다
• 반려가 실패가 아니라 분류 결과인 이유와, 그 인식이 팀에 주는 효과를 안다
• 리포트 제목은 실패로, 원인은 결함으로 쓰는 이유를 설명할 수 있다
• 이상·결함·실패 건수가 각각 무엇을 재는 지표인지 구분할 수 있다
• 결함 1건이 실패 여러 건을 만들 수 있다는 것과, 그것이 지표에 주는 영향을 안다
• 어느 문서에 어느 용어를 쓸지 결정할 수 있다
• fault 를 '오류'로 번역하면 안 되는 이유를 안다
• '하자'·'장애'·'결함'이 가리키는 범위가 어떻게 다른지 설명할 수 있다
• 계약서의 '하자'를 QA의 '결함'과 같다고 가정하면 안 되는 이유를 알고, 법적 판단은 어디에 맡길지 안다
• 문서 유형별로 어느 단어를 쓸지 정할 수 있고, 상대가 발행한 문서에서는 용어를 바꾸지 않는 이유를 안다
• 결함 집계와 장애 집계의 모집단·재발 처리·닫히는 조건이 어떻게 다른지 말할 수 있다
• "이 표의 한 행이 닫히는 조건은 무엇인가" 라는 질문이 무엇을 진단하는지 안다
• 이슈 타입 이름을 바꾸는 것보다 해결 값과 큐를 손대는 것이 효과적인 이유를 안다
• 집계 기준을 바꿀 때 과거 데이터를 다시 라벨링하지 않는 이유와, 대신 남길 한 줄을 안다

흔한 실수

제목에 원인 추정을 적는다. "캐시 문제로 목록이 안 뜸"이라고 적었는데 실제 원인은 다른 것이면, 그 리포트는 개발자를 틀린 방향으로 보낸다. 제목은 관찰한 것만 적는다.

반려를 테스터의 실패로 취급한다. 반려율을 개인 지표로 쓰는 조직이 있는데, 이러면 확신 없는 관찰이 보고되지 않는다. 놓치는 결함이 늘어난다.

'버그 건수'로 품질을 보고한다. 무엇을 센 숫자인지 정의가 없으면 추세가 올라가도 내려가도 해석할 수 없다.

실패 건수와 결함 건수를 더한다. 같은 사건을 두 번 세는 것이다.

용어 통일을 위해 팀 대화까지 통제한다. 슬랙에서 "버그"라고 못 쓰게 하면 반발만 산다. 리포트 본문과 지표 정의만 고친다.

fault 를 '오류'로 번역한 문서를 그대로 인용한다. 표준 체계에서 error와 fault는 정반대 위치다. 번역된 자료를 쓸 때는 원어를 확인한다.

'장애'와 '결함'을 한 큐에 등록한다. 닫히는 조건이 달라서 두 집계가 동시에 거짓이 된다. 이름을 통일하는 것으로는 해결되지 않고 자리를 나눠야 한다.

계약서의 '하자'를 '결함'으로 바꿔 적는다. 상대가 발행한 문서의 용어를 우리가 바꾸면 그 자체가 해석 행위가 된다. 집계 기준을 각주로 붙이는 것이 안전하고, 법적 범위 판단은 법무 검토의 영역 이다.

이슈 타입 이름을 Anomaly 로 바꾼다. 사람들은 계속 '버그'라고 부르고, 연동된 필터·대시보드만 깨진다. 손댈 곳은 해결(Resolution) 값과 큐 다.

집계 기준을 바꾸고 과거를 다시 라벨링한다. 재판정 비용이 얻는 것보다 크고, 재판정 자체가 또 하나의 기준 변경이다. 전환일 주석 한 줄 이면 된다.

참고 자료

• ISO/IEC/IEEE 24765 — 시스템·소프트웨어 공학 어휘. error·defect·fault·failure·anomaly의 표준 정의를 찾는 1차 사전
• IEEE 1044-2009 — 소프트웨어 이상(anomaly) 분류 표준. '이상'을 중심 개념으로 두고 조사·분류 절차를 규정한다
• ISO/IEC/IEEE 29119-1 — 개념과 정의. 테스트 맥락에서의 인시던트 개념
• ISTQB 용어집(Glossary) — 한국어 대역어를 확인할 수 있다. 번역 규칙을 정할 때 기준으로 삼기 좋다
• 모듈 1 레슨 2 검증과 확인, 오류·결함·실패의 구분과 전파 — 세 용어의 기초와 전파 구조
• 모듈 6 결함 관리와 보고 — 생명주기와 리포트 작성. 이 레슨은 그 문장의 언어적 토대를 다룬다
• 모듈 8 ISO/IEC/IEEE 29119 — 동적 테스트 프로세스의 인시던트 보고 활동
• IEEE 1044-2009 — Standard Classification for Software Anomalies — 이상 분류 표준의 서지 정보. 분류 속성의 정확한 목록은 원문에서 확인한다
• ISTQB Glossary — anomaly·defect·error·failure의 공식 정의와 한국어 대역어. 'bug'는 결함의 비공식 동의어로 다룬다
• 이 모듈 레슨 7 심각도와 우선순위 — 결함에 붙이는 두 속성. IEEE 1044가 다시 등장한다

이 커리큘럼 안에서

• 이 모듈 레슨 1 — 말과 글을 분리한다. 이 레슨이 그 원칙의 가장 직접적인 적용 자리다
• 이 모듈 레슨 2 — 판이 바뀌면 과거 문서가 어긋난다. 용어 전환과 같은 문제
• 이 모듈 레슨 5 — 측정량과 성적서 항목명. 어느 단어로 등재하는가
• 이 모듈 레슨 7 — 심각도·우선순위 필드 설계. 체계를 바꿀 때의 과거 데이터 문제가 같다
• 이 모듈 레슨 8 — 팀 용어집과 이행. 여기서 정한 번역 규칙이 거기에 쌓인다
• 모듈 1 레슨 2 — 오류·결함·실패의 기초와 전파 구조
• 모듈 6 레슨 1 — 결함 생명주기. Rejected 상태를 이 레슨의 관점으로 다시 읽는다
• 모듈 6 레슨 2 — 결함 리포트 작성. 제목·원인·영향 3단 구조의 실제 문장
• 모듈 6 레슨 4 — 이슈 추적 도구. 이슈 타입·해결 값·큐 설계가 용어 체계를 떠받친다
• 모듈 6 레슨 5 — 품질 지표. 결함 밀도·탈출률이 집계 기준에 어떻게 흔들리나
• 모듈 8 레슨 5 — 인시던트 삼분법. 제품·테스트 자산·환경으로 원인을 나누는 절차는 거기서 다룬다
• 모듈 10 레슨 4 — 비결정적 요소. 재현되지 않는 실패가 결함이 아닐 수 있는 기술적 이유
• 모듈 4 레슨 5 — 릴리즈 Go/No-Go. 어느 집계를 판정 기준으로 쓰는가
• 모듈 26 레슨 7 — 경영진 보고. 세 숫자 중 무엇을 올릴지 정하는 자리

한 줄 정리 — '버그'는 다섯 개를 한 단어로 부른 것이고, 비용은 숫자와 대외 문서에서 발생한다. 오류는 사람에게, 결함은 산출물에, 실패는 실행에, 이상과 인시던트는 관찰과 기록에 있다. 고칠 곳은 대화가 아니라 리포트 본문·대외 문서·지표 정의 셋이고, 가장 비싼 혼용은 '장애'와 '결함'을 한 표에 넣는 것 이다 — 그러면 두 숫자가 동시에 거짓이 된다. 그리고 바꿀 때는 과거를 다시 쓰지 말고 바꾼 날을 적는다.