Bug bashing, Microsoft 1990s의 버그 사냥 행사

한 줄로

팀 전체가 하루 시간을 내서 의도적으로 버그를 찾는 행사입니다. 1990년대 마이크로소프트에서 시작된 의식입니다.

어디서 왔나

1990년대 마이크로소프트의 Windows·Office 팀 안에서 비공식적으로 시작된 관행입니다. 출시 직전 마지막 검증 단계에서, 개발자·디자이너·PM·마케팅이 모두 함께 하루를 비워 제품을 사용하면서 버그를 찾습니다.

"Bug bash"에서 bash는 "강타하다, 부수다"의 의미입니다. 버그를 사냥해 부수는 의식이라는 비유입니다.

규칙입니다.

• 한정된 시간 (보통 4~8시간).
• 모든 부서 참여: QA 전담이 아니라 전사적.
• 인센티브: 가장 많이/심각한 버그를 찾은 사람에게 상.
• 즉시 기록: 발견 즉시 티켓 발행.
• 공유 화면: 큰 모니터에 실시간 발견 버그 표시.

이 관행이 산업으로 퍼진 건 2000년대 초입니다. Google, Facebook, Amazon이 비슷한 형태로 도입했습니다.

왜 효과적인가

• 다양한 관점: PM은 마케팅 관점, 디자이너는 시각적 관점, 개발자는 엣지 케이스 관점. QA만으로는 못 보는 영역이 드러납니다.
• 집중: 하루를 비워 집중하면 평소 흩어진 테스트보다 발견율이 높습니다.
• 소속감: 모두가 제품에 책임감을 느낍니다. "내가 못 찾았으면 사용자가 봤겠지"의 인식입니다.

1인 랩에서

혼자라면 bug bash가 의미 없을까요? 아닙니다. 변형이 가능합니다.

• "하루 사용자 모드": 하루를 본인 도구의 사용자로 보냅니다. 개발자 모드 끄고요.
• 친구 5명 초대: 점심 사면서 30분씩 보게 합니다.
• 베타 테스터 모집: 트위터/디스코드에서 5~10명.

한국 사례

토스, 카카오, 네이버 같은 회사들이 분기마다 "Quality Day" 또는 "Buddy Test"라는 이름으로 비슷한 행사를 운영합니다. 한국식 변형은 점심·간식이 같이 제공되는 게 특징입니다.

바이브 메이커가 챙길 한 가지

새 버전 출시 직전 하루 정도 본인 제품을 진짜 사용자처럼 써봅시다. 가입부터 시작해서 핵심 기능 전부. 평소 안 보이던 작은 어색함이 다 드러납니다. 이 습관 하나가 사용자 첫 인상의 품질을 크게 바꿉니다.

관련

Hallway testing · Dogfooding · Beta testing