오류 부재의 궤변: 결함이 없어도 사용자 요구를 놓칠 수 있는 이유
오류 부재의 궤변을 통해 결함 제거와 사용자 요구사항 충족의 차이, 테스트와 품질의 역할을 정리한다.
2026-08-14 · 최초 발행 2026-04-17
결함이 없다는 말만으로는 충분하지 않다
소프트웨어 테스트 7원칙의 하나인 오류 부재의 궤변(Absence of Errors Fallacy)은 모든 결함을 찾아 수정했더라도 사용자 요구사항을 충족하지 못하면 품질이 낮은 제품이 될 수 있음을 말한다.
수천 개의 테스트 케이스를 통과하고 미결함 상태(Zero Bug)를 만들었더라도, 사용자가 필요로 하는 핵심 기능이 빠져 있거나 사용 과정이 지나치게 불편하다면 시장의 선택을 받기 어렵다. 테스트의 목적을 버그 발견에만 두면 이 지점을 놓치게 된다.
품질은 두 방향에서 봐야 한다. 하나는 명세서대로 동작하는지를 확인하는 일치성(Conformance)이고, 다른 하나는 사용자의 목적에 맞는지를 보는 적합성(Fitness for use)이다. 오류 부재의 궤변은 일치성만 좇다가 적합성을 잃는 상황을 경계한다.
테스트가 확인해야 할 대상은 사용자 가치다
테스트가 개발 막바지에서 결함을 걸러내는 필터에 머물면, 제품이 실제 목적에 맞는지는 검증하기 어렵다. 기획 단계부터 참여해 비즈니스 가치를 확인하는 가이드 역할까지 맡아야 하는 이유다.
기술적 안정성은 비즈니스 성공과 같은 뜻이 아니다. 버그가 하나도 없는 전자상거래 시스템을 가정해 보자. 결제 과정이 10단계이고 로딩 속도가 20초 이상 걸린다면, 사용자는 결함을 만나기도 전에 서비스를 떠날 수 있다. 시스템은 동작하지만 사용자가 기대한 빠르고 간편한 쇼핑 환경은 제공하지 못한 셈이다.
요구사항을 놓치면 다른 품질 특성도 의미를 잃는다
ISO/IEC 25010과 같은 품질 표준에서 기능 적합성(Functional Suitability)을 먼저 언급하는 배경도 여기에 있다. 필요한 기능이 제대로 구현되지 않았다면 다른 품질 특성만으로 제품의 가치를 설명하기 어렵다.
요구사항에는 문서로 표현된 명시적 요구사항과, 성능·사용성·보안처럼 사용자가 당연하게 기대하는 묵시적 요구사항이 있다. 오류 부재의 궤변은 이 요구사항 전체가 충족되어야 품질이 확보된다고 본다. 코드가 깨끗하고 로직에 오류가 없더라도 사용자가 기대한 결과가 아니라면 프로젝트는 실패할 수 있다.
결함 제거 이후에도 남는 검증 단계
결함 부재 상태는 성공의 종점이 아니라 중간 관문이다. 사용자 요구사항 충족 여부를 확인하지 않은 채 결함 제거 단계에만 머물면 오류 부재의 궤변에 빠질 수 있다.
요구사항과 사용 흐름을 테스트에 넣는 방법
테스터는 요구사항 정의 단계부터 참여해 정적 테스트로 모호성을 줄이고, 구현 가능한지와 사용자 의도에 맞는지를 확인할 수 있다. 개발이 끝난 뒤에야 요구와 다르다는 피드백을 받는 위험을 줄이는 접근이다.
UX 테스트와 사용성 테스트도 필요하다. 기능이 정상 동작하는지뿐 아니라 사용자가 목표를 달성하는 과정이 매끄러운지를 검증해야 한다. 기술적 오류가 없더라도 사용자가 인지적 부하를 느낀다면 잠재적인 결함과 다르지 않다.
애자일 방법론이 반복적인 릴리스를 강조하는 이유 역시 짧은 주기로 사용자 반응을 확인하고 요구사항과의 간극을 좁히기 위해서다. 한 번에 완벽한 제품을 만들려 하기보다, 사용자 요구에 맞춰 계속 변화시키는 과정이 필요하다.
개발과 테스트가 함께 판단해야 하는 품질
개발자가 구현 방법(How)에 집중한다면, 테스터는 무엇을 위해 구현하는지(What/Why)까지 함께 검토해야 한다. 이 원칙을 이해하는 팀에서 테스트는 단순 검수가 아니라 사용자를 대리하는 활동이 된다.
결함 수정도 전체 사용자 흐름의 맥락에서 판단해야 한다. 사소한 버그를 고치려는 변경이 사용자가 익숙한 UI를 훼손하거나 성능을 낮춘다면, 그 수정은 품질 측면에서 보류하는 편이 나을 수 있다. 컨텍스트를 고려한 테스팅(Context-driven Testing)이 필요한 이유다.
소프트웨어의 가치는 기술적 완벽함 자체가 아니라 사용자의 문제를 해결하는 데서 나온다. 결함 없는 상태와 사용자 기대에 맞는 동작이 함께 갖춰질 때 제품의 품질도 비로소 완성된다.
Sources
- International Software Testing Qualifications Board (ISTQB) Foundation Level Syllabus
- ISO/IEC 25010 System and Software Quality Models
- 소프트웨어 공학의 원칙과 실제 (정보관리기술사 도서 참고)
- Glenford J. Myers, The Art of Software Testing