01 ▸ 워크플로우 위치
[버그 발생]
│
▼
┌─────────────────────────────┐
│ Systematic Debugging (ACTIVE)│
│ 재현 ▸ 가설 ▸ 테스트 ▸ 수정 │
└──────────────┬──────────────┘
│
▼
[해결됨]
02 ▸ 언제 사용하나요?
버그, 테스트 실패, 예상치 못한 동작 — 무엇이든 고쳐야 할 때 사용합니다.
주요 트리거
- 런타임 에러, 테스트 실패, 예기치 않은 동작
- Run Plan 또는 Long Run 실패 시 자동 전환
- "이 테스트가 불안정해", "버그 있어" 등의 보고
03 ▸ 어떻게 동작하나요?
핵심 원리: 재현 없으면 수정 없습니다. 가설 없으면 수정 없습니다. 한 번에 하나의 가설만 검증합니다.
7단계 디버깅 워크플로
- 문제 정의 (한 문장): "무엇이 기대와 다른가"를 명확히 기술합니다.
- 재현 또는 계측: 최소 재현 경로를 확보하거나 계측 로그를 추가합니다.
- 증거 수집: 컴포넌트 경계에서 입력/출력을 추적하여 실패 지점을 좁힙니다.
- 단일 가설 수립: "A가 B 때문에 실패한다"는 구체적인 가설을 세웁니다.
- 실패 테스트 작성: 가설을 증명하는 (수정 전에는 실패하는) 테스트를 작성합니다.
- 단일 수정 적용: 해당 가설을 해결하는 최소한의 코드만 수정합니다.
- 검증 및 종료: 테스트 통과를 확인합니다. 3회 실패 시 구조적 문제를 의심합니다.
04 ▸ 하드 게이트
강력 규율: 아래 규칙을 위반하는 디버깅은 금지됩니다.
- 재현 금지: 재현(또는 명확한 관측) 없이는 수정을 시작하지 않습니다.
- 가설 금지: 명확한 근본 원인 가설 없이는 코드를 고치지 않습니다.
- 동시 수정 금지: 한 번에 여러 가설을 테스트하거나 여러 곳을 고치지 않습니다.
- "하면서" 금지: 버그를 고치면서 리팩토링이나 코드 정리를 병행하지 않습니다.