체계적 디버깅
황금률
"근본 원인 없이 수정 금지"
추측에 기반한 빠른 수정은 새로운 문제를 만들 뿐입니다.
4단계 프로세스
1단계: 근본 원인 조사
code
필수 확인 항목: ☐ 에러 메시지와 스택 트레이스 정확히 읽기 ☐ 문제를 일관되게 재현할 수 있는지 확인 ☐ 최근 코드 변경사항 검토 ☐ 복잡한 시스템: 각 계층의 입출력 데이터 기록
2단계: 패턴 분석
code
비교 분석: ☐ 작동하는 유사 코드 찾기 ☐ 정상 코드와 문제 코드 비교 ☐ 모든 차이점 나열
3단계: 가설과 테스트
code
검증 방법: ☐ 구체적 가설 수립 (추측 ❌) ☐ 최소한의 변경으로 테스트 ☐ 한 번에 하나의 변수만 변경
4단계: 구현
code
수정 절차: ☐ 실패하는 테스트 케이스 먼저 작성 ☐ 근본 원인만 수정 (관련 없는 코드 건드리지 않기) ☐ 테스트 통과 확인 ☐ 3번 이상 실패하면 아키텍처 재검토
주의 신호
다음 생각이 들면 1단계로 돌아가기:
- •"하나의 빠른 수정만 해보자"
- •"그냥 시도해보자"
- •"이게 문제일 것 같은데"
- •"아마 이거면 될 거야"
금지 사항
| ❌ 금지 | ✅ 대신 |
|---|---|
| 추측으로 코드 수정 | 근본 원인 확인 후 수정 |
| 여러 곳 동시 수정 | 한 번에 하나만 변경 |
| "일단 해보자" | 가설 수립 후 검증 |
| 에러 메시지 무시 | 스택 트레이스 정확히 분석 |
디버깅 체크리스트
code
시작 전: ☐ 문제 재현 가능? ☐ 에러 메시지 완전히 읽음? ☐ 최근 변경사항 확인? 수정 전: ☐ 근본 원인 파악됨? ☐ 실패 테스트 작성됨? ☐ 가설이 구체적? 수정 후: ☐ 테스트 통과? ☐ 다른 기능 영향 없음? ☐ 유사 문제 재발 방지?