소프트웨어 개발 과정에서 우리는 "버그 터졌어!", "서버 에러 났어!" 와 같은 말을 흔히 사용합니다. 하지만 문제 해결의 효율성을 높이고 팀원들과 명확하게 소통하기 위해서는, 우리가 '버그'라고 뭉뚱그려 부르는 것들의 정체를 명확히 구분할 필요가 있습니다.
ISTQB(International Software Testing Qualifications Board)를 비롯한 소프트웨어 공학에서는 문제의 발생 과정을 오류(Error), 결함(Defect), 장애(Failure)라는 세 단계로 구분합니다. 이 세 용어의 차이와 인과 관계를 이해하는 것은, 품질 문제에 체계적으로 접근하는 첫걸음입니다.
1. 세 가지 용어의 정의
1) 오류 (Error)
정의: 사람이 저지르는 실수. 모든 문제의 근원이자 시작점입니다. 이는 시스템에 아직 반영되지 않은, 사고 또는 행동상의 실수를 의미합니다.
예시
- 개발자가 요구사항을 잘못 이해하고 코드를 작성하는 것.
- x > 5라고 코딩해야 할 것을 x < 5라고 잘못 타이핑하는 것.
- 기획자가 요구사항 명세서의 특정 조건을 누락하거나 모호하게 작성하는 것.
- 구두로 전달된 지시사항이 잘못 이해되는 것과 같은 모호한 커뮤니케이션.
2) 결함 (Defect)
정의: 시스템(코드, 문서, 설계 등)에 내재된 문제. 사람의 '오류'가 만들어낸 결과물입니다. 우리가 흔히 '버그'라고 부르는 것이 바로 이 결함입니다.
핵심: 아직 실행되지 않아 사용자에게 아무런 영향을 미치지 않고, 코드나 문서 속에 조용히 숨어있는 '흠집'과 같습니다. 테스트를 수행하더라도 해당 로직이 실행되지 않으면 결함은 발견되지 않을 수 있으며, 이것이 바로 테스트 설계와 커버리지의 중요성을 말해줍니다.
예시
- x < 5라고 잘못 작성된 바로 그 코드 라인.
- 요구사항이 누락된 명세서의 해당 페이지.
- 잘못 설계된 데이터베이스 스키마.
3) 장애 (Failure)
정의: 시스템이 기대된 동작을 하지 못하는 현상. 내재되어 있던 '결함'이 특정 조건에서 실행될 때 외부로 드러나는 결과입니다.
핵심: 사용자가 직접 목격하거나 운영 로그, 모니터링 알람, 사용자 제보 등으로 식별할 수 있는, 명세와 다른 동작입니다.
예시
- x에 10을 입력했을 때, x < 5라는 결함이 있는 코드가 실행되어 "유효한 값입니다"라는 잘못된 메시지를 화면에 표시하는 현상.
- 사용자가 특정 버튼을 클릭했을 때, 시스템이 응답하지 않거나 비정상적으로 종료되는 것.
- 월말 정산 리포트에서 합계 금액이 틀리게 나오는 것.
2. 인과 관계: 어떻게 문제가 전파되는가?
이 세 가지 용어는 명확한 인과 관계의 사슬을 형성합니다.
사람의 오류(Error)가 코드에 결함(Defect)을 만들고, 그 결함이 특정 조건에서 실행될 때, 사용자에게 장애(Failure)로 나타납니다.
마치 도미노가 쓰러지는 과정과 같습니다. 첫 번째 도미노인 사람의 '오류'를 바로잡는 것이 시간과 비용 측면에서 가장 저렴하며, 이것이 바로 'Shift-Left' 개념의 핵심입니다.
중요한 점은, 모든 결함이 반드시 장애로 이어지지는 않는다는 것입니다. 특정 조건이 충족되지 않아 실행되지 않는 코드 속의 결함은, 마치 아무도 건드리지 않는 줄 속에 잘못 서 있는 도미노와 같습니다.
데드 코드 (Dead Code) 속 결함:
예시: 과거 이벤트 기간에만 사용되었고, 현재는 어디에서도 호출되지 않는 calculate_special_discount() 함수 내에 치명적인 계산 결함이 있습니다. 이 코드는 시스템에 존재하지만 실행될 일이 없으므로 장애를 일으키지 않습니다.
드문 엣지 케이스 (Rare Edge-Case)의 결함:
예시: 시스템이 2월 29일(윤년)에만 날짜 계산을 잘못하는 결함이 있습니다. 이 결함은 4년에 단 하루만 실행될 수 있으므로, 대부분의 시간에는 장애로 나타나지 않습니다.
기능 플래그 (Feature Flag)로 비활성화된 결함:
예시: 아직 정식 출시되지 않은 '새로운 결제 기능' 코드에 결함이 있지만, 기능 플래그가 off 상태라서 사용자에게는 노출되지 않습니다. 이 결함은 플래그가 on으로 바뀌기 전까지는 장애를 유발하지 않습니다.
3. 왜 이 구분이 중요한가?
이 용어들을 구분하는 것은 단순히 학문적인 말장난이 아닙니다. 문제 해결의 접근 방식을 완전히 바꾸기 때문입니다.
테스트의 역할 재정의
- 동적 테스트 (Dynamic Testing): 시스템을 실행하고 결과를 관찰하여 의도적으로 장애를 발생시키고, 이를 통해 숨어있는 결함의 존재를 증명하는 활동입니다.
- 정적 테스트 (Static Testing): 코드를 실행하지 않고 소스 코드나 명세서를 검토하고 분석하여, 장애를 일으키기 전의 결함을 직접 찾아내는 활동입니다.
체계적인 문제 해결 프로세스
-
장애 식별: 사용자가 "로그인이 안 돼요!"라는 장애를 보고합니다.
-
결함 분석 (디버깅): 개발팀은 로그를 분석하고 디버깅하여, 이 장애를 유발한 코드 내의 결함을 찾아냅니다. (예: password_hash() 함수 로직의 문제)
-
오류 근본 원인 분석 (RCA - Root Cause Analysis): "왜 이런 결함이 만들어졌을까?"를 파고듭니다. 이때 다음과 같은 기법을 활용할 수 있습니다.
5 Whys: "왜?"라는 질문을 다섯 번 반복하여 문제의 근본 원인에 도달하는 간단하지만 강력한 기법입니다.
- 왜 1? 패스워드 해시값이 일치하지 않았다.
- 왜 2? 새로운 해싱 라이브러리가 적용되었기 때문이다.
- 왜 3? 기존 데이터 마이그레이션이 누락되었기 때문이다.
- 왜 4? 마이그레이션 담당자가 요구사항을 전달받지 못했기 때문이다.
- 왜 5? (근본 원인) 배포 전 체크리스트에 '데이터 마이그레이션 확인' 항목이 없었다.
피시본 다이어그램 (Fishbone Diagram / Ishikawa Diagram): 문제의 원인을 여러 카테고리로 나누어 시각적으로 분석함으로써, 다양한 측면의 원인을 놓치지 않도록 돕는 기법입니다. '물고기 뼈' 모양과 비슷하여 이런 이름이 붙었습니다.
(예시: '로그인 장애'에 대한 피시본 다이어그램 분석)- 머리(결과): 로그인 장애 발생
- 뼈대(원인 카테고리):
- 사람 (People):
- 담당 개발자의 신규 라이브러리 이해 부족
- QA와 개발자 간의 테스트 범위 소통 부재
- 프로세스 (Process):
- 배포 전 체크리스트 부재 (근본 원인 중 하나)
- 요구사항 변경 시 관련자에게 알리는 절차 미비
- 코드 리뷰 시 마이그레이션 스크립트 검토 누락
- 기술/시스템 (Technology/System):
- 신규 해싱 라이브러리의 복잡성
- 테스트 환경과 운영 환경의 데이터 불일치
- 마이그레이션 스크립트 실행의 어려움
- 환경 (Environment):
- 긴급 배포로 인한 충분한 테스트 시간 부족
- 재택근무로 인한 비동기 커뮤니케이션의 한계
- 사람 (People):
이처럼 피시본 다이어그램은 5 Whys가 단일 경로의 깊은 원인을 찾는 데 강점이 있는 반면, 문제에 영향을 미쳤을 수 있는 다양한 측면의 원인들을 종합적으로 식별하는 데 매우 유용합니다.
-
개선 조치: 단순히 결함을 수정하는 것에서 그치지 않고, 재발 방지를 위한 프로세스 개선(예: 배포 체크리스트에 '데이터 마이그레이션 확인' 항목 추가)과 해당 케이스를 검증하는 자동화 테스트 케이스를 추가하여 시스템을 더욱 견고하게 만듭니다.
