오류 이름보다 관찰한 증상으로 시작합니다
“로그인 버그”처럼 원인을 추측한 이름으로 시작하면 처음부터 조사 범위가 좁아집니다. “로그인 버튼을 누르면 10초 뒤 오류 문구가 표시됨”처럼 사용자가 본 현상, 발생 시점과 예상 결과를 적으세요. 시작 노드 다음에는 버전, 기기, 계정 상태, 오류 시각처럼 재현에 필요한 정보를 확인하는 과정을 둡니다.
| 확인 항목 | 기록 예시 | 용도 |
|---|---|---|
| 환경 | Windows 11, Chrome 140 | 환경별 차이를 분리합니다. |
| 입력 순서 | 로그인 → 저장 → 새로고침 | 같은 동작을 반복할 수 있습니다. |
| 실제 결과 | 저장한 노드가 사라짐 | 예상 결과와 비교합니다. |
| 발생 빈도 | 5회 중 3회 | 간헐 오류인지 판단합니다. |
재현 여부를 해결 여부와 혼동하지 않습니다
한 번 재현되지 않았다고 오류가 없다고 결론 내리지 마세요. 재현 성공이면 원인 분리로, 실패이면 정보 보완이나 관찰 로그 확보로 연결합니다. 재현 불가 경로에도 다음 행동과 종료 기준이 있어야 제보가 방치되지 않습니다. 예를 들어 “동일 환경에서 3회 확인 후 로그 요청”처럼 횟수와 담당자를 적습니다.
한 번에 변수 하나만 바꿔 원인을 분리합니다
브라우저, 네트워크, 계정, 데이터처럼 가능한 원인을 목록으로 만든 뒤 영향이 크고 확인이 쉬운 항목부터 검사합니다. 여러 설정을 동시에 바꾸면 증상이 사라져도 무엇이 원인이었는지 알 수 없습니다. 각 과정 노드에는 실행한 조치, 조건 노드에는 조치 후 증상이 계속되는지를 적습니다.
- 모든 사용자에게 발생하는지 특정 계정에만 발생하는지 확인합니다.
- 다른 브라우저나 기기에서도 같은지 비교합니다.
- 새 데이터와 기존 데이터에서 결과가 다른지 확인합니다.
- 직전 배포나 설정 변경과 발생 시점이 겹치는지 살펴봅니다.
- 가설 하나를 검증한 뒤 결과를 기록하고 다음 가설로 이동합니다.
임시 조치와 근본 해결을 별도 결과로 둡니다
캐시 삭제나 재시작으로 당장 사용할 수 있게 된 것은 임시 조치일 수 있습니다. 차트에서 “사용 가능 상태 복구”와 “원인 수정 및 배포”를 분리하면 임시 해결 후 결함이 잊히는 일을 막을 수 있습니다. 사용자가 직접 수행할 조치는 데이터 손실 위험, 적용 범위와 되돌리는 방법도 함께 검토해야 합니다.
조치 후에는 처음 증상을 같은 방식으로 재검증합니다
수정한 기능만 눌러보는 것으로 끝내지 말고 처음 기록한 입력 순서를 그대로 반복합니다. 정상 사례, 오류 사례, 경계값을 각각 확인하고 결과를 남기세요. 다시 발생하면 원인 분리 단계로 되돌아가되 연결선에 “재검증 실패”라고 적어 단순 반복과 구분합니다.
현장에서 따라갈 수 있는지 마지막으로 점검합니다
- 전문 용어를 모르는 사람도 첫 확인 항목을 이해하는가?
- 각 조건에 예·아니오 경로가 모두 연결됐는가?
- 재현 불가일 때 요청할 정보와 재확인 시점이 있는가?
- 위험한 조치 전에 백업이나 승인 단계가 있는가?
- 해결, 임시 복구, 추가 조사 결과가 구분되는가?