[Software Engineering] Debugging

What is Debugging

디버깅(Debugging)은 테스트 과정에서 발견된 오류를 수정하는 과정이다.
디버깅 절차는 다음과 같이 진행된다:

• 테스트 케이스 실행 → 오류 발생 → 원인 추정 → 원인 확인 → 수정 → 회귀 테스트(Regression Test) → 새로운 테스트 케이스 실행

 

디버깅 과정에서 오류의 증상과 실제 원인은 반드시 동일한 위치에 있거나 직접적으로 연결되지 않을 수도 있다. 다음과 같은 상황이 발생할 수 있다:

1. 증상과 원인이 지리적으로 분리될 수 있음 (Symptom and cause may be geographically separated)
   • 프로그램의 한 부분에서 문제가 발생했지만, 실제 원인은 다른 모듈이나 시스템에 있을 수 있다.
   • 예: 클라이언트 애플리케이션에서 UI가 깨지는 문제가 발생했지만, 실제 원인은 서버에서 반환하는 잘못된 데이터 때문일 수 있다.
2. 다른 문제가 해결되면 증상이 사라질 수 있음 (Symptom may disappear when another problem is fixed)
   • 한 가지 문제를 수정하면, 예상치 못하게 다른 문제가 해결되는 경우가 있다.
   • 예: 메모리 누수 문제를 해결했더니, 이전에 발생했던 성능 저하 현상이 사라지는 경우.
3. 원인이 ‘비오류(non-error)’의 조합일 수 있음 (Cause may be due to a combination of non-errors)
   • 개별적으로는 문제가 없는 코드들이 특정 조건에서 조합되었을 때 오류가 발생할 수 있다.
   • 예: 여러 개의 스레드가 동시에 실행되면서 경쟁 조건(Race Condition)이 발생하는 경우.
4. 시스템 또는 컴파일러 오류일 가능성이 있음 (Cause may be due to a system or compiler error)
   • 문제의 원인이 애플리케이션 코드가 아니라 운영체제(OS), 하드웨어, 또는 컴파일러의 버그일 수도 있다.
   • 예: 특정 컴파일러 버전에서만 발생하는 최적화 버그.
5. 모두가 당연하게 여긴 가정이 원인일 수 있음 (Cause may be due to assumptions that everyone believes)
   • 개발자들이 공통적으로 가정하고 있던 내용이 실제로는 잘못된 경우, 오류가 발생할 수 있다.
   • 예: "배열의 길이는 항상 10 이상일 것이다"라는 가정 하에 작성된 코드가, 배열 크기가 5일 때 오류를 발생시키는 경우.
6. 증상이 간헐적으로 발생할 수 있음 (Symptom may be intermittent)
   • 항상 발생하는 것이 아니라, 특정한 상황에서만 문제가 발생하는 경우가 있다.
   • 주로 초기화 오류, 타이밍 이슈, 동기화 문제, 하드웨어 의존적 오류 등이 원인일 가능성이 높음.
   • 예: 네트워크 연결 상태에 따라 간헐적으로 데이터 전송이 실패하는 문제.

• 디버깅은 프로그래밍보다 더 어려움
  Brian Kingdom: "디버깅은 코딩보다 두 배 어렵다. 따라서 처음부터 최대한 복잡하게 작성하면 디버깅이 거의 불가능해진다."
• 디버깅에 걸리는 시간
  • 일부 프로젝트에서는 개발 시간의 50%까지 차지
  • 대부분의 버그는 단순 실수(오타, 논리적 오류 등)에서 비롯됨
  • 단순한 오류는 코드 목록을 확인하거나 디버거로 실행하며 쉽게 찾을 수 있음

 

Basic Debugging Approaches

 

• Brute Force Debugging (무차별 대입 디버깅)
  • 가장 흔하지만 비효율적인 방법
  • 실행 기록(memory dump), 런타임 트레이스(trace), 출력문 추가 등을 활용
  • 방대한 정보를 통해 오류를 찾을 수도 있지만, 시간 낭비가 많음
• Backtracking (역추적)
  • 오류 발생 지점에서 소스 코드를 거슬러 올라가며 원인을 찾는 방법
  • 소규모 프로그램에는 효과적이지만, 코드가 길어지면 경로가 기하급수적으로 증가해 비효율적
• Cause Elimination (원인 제거)
  • 귀납법과 연역법을 사용하여 문제의 원인을 찾음
  • 가능성 있는 원인을 리스트업한 뒤, 테스트를 통해 하나씩 제거하는 방식
  • ‘이진 분할(Binary Partitioning)’ 기법 활용: 특정 조건을 충족하는 경우와 아닌 경우를 비교하여 오류 원인을 좁혀나감
• Devil’s Guide to Debugging (잘못된 디버깅 접근법)
  • 추측 기반 디버깅: 코드 곳곳에 print 문을 넣고 실행 결과를 비교하는 방식
  • 문제 이해 없이 수정: 원인을 정확히 분석하지 않고 단순히 눈에 보이는 부분만 수정
  • 기록하지 않음: 원본 파일 백업 없이 직접 수정하고 변경 사항을 기록하지 않는 것
  • 가장 쉬운 해결책만 선택: 근본적인 문제를 해결하기보다 눈앞의 오류만 수정

 

 

An Effective Approach to Debugging

 

• 오류를 안정화(Stabilize the Error)
  • 오류가 일관되게 발생하도록 조정 (재현 가능성 확보)
  • 간헐적 오류는 초기화 문제, 타이밍 이슈, 포인터 관련 문제일 가능성이 큼
• 오류 원인 찾기 (과학적 방법)
  • 반복 가능한 실험을 통해 데이터를 수집
  • 수집한 데이터를 기반으로 가설 설정
  • 실험을 설계하여 가설을 검증
  • 가설을 입증 또는 반증하여 오류의 원인 규명
• 오류 수정 및 검증
  • 문제를 수정한 후, 반드시 회귀 테스트(Regression Test) 수행
  • 수정한 코드가 다른 부분에 영향을 미치는지 확인
• 유사한 오류 탐색
  • 비슷한 오류가 다른 부분에서도 발생할 가능성이 높음
  • 동일한 실수를 반복하지 않도록 패턴 분석 수행

 

 

• 여러 방식으로 오류 재현
  • 다양한 테스트 케이스를 적용해 문제가 발생하는 조건을 명확히 규명
  • "Triangulation(삼각 측량)" 기법: 여러 관점에서 오류를 분석해 정확한 위치를 파악
• 최후의 수단
  • 일정 시간 동안 해결되지 않으면 다른 사람의 도움을 받음

 

 

 

Debugging and Opportunities

 

• 프로그램의 구조 학습
  • 버그가 발생하는 이유를 분석하면 프로그램 설계상의 문제점을 이해할 수 있음
• 자신의 실수 유형 파악
  • 어떤 실수를 자주 하는지 분석하여 예방 가능
  • 동일한 실수를 반복하지 않기 위해 코딩 습관 개선
• 코드 품질 향상
  • 디버깅 과정에서 코드 가독성을 평가할 기회가 됨
  • 리팩토링(Refactoring)으로 코드 개선 가능
• 디버깅 방식 개선
  • 현재 디버깅 방식이 효과적인지 평가하여 효율적인 접근법 개발
  • 보다 체계적인 디버깅 기법을 적용하여 개발 시간을 단축할 수 있음
• 올바른 수정 방식 학습
  • 단순히 "증상"을 수정하는 것이 아니라, "근본적인 원인"을 해결하는 능력을 기름
  • 시스템적인 접근법을 활용하여 장기적으로 더 안정적인 코드를 작성할 수 있음