셋째, 의심 지점을 특정합니다.
전제를 확인했다면 의심 지점을 특정하기 위해 구체화된 다음과 같은 질문을 던질 수 있어야 합니다.
• 이 전제가 깨질 수 있는 구간은 어디인가?
• 이 함수와 이 함수 사이에 다른 실행 흐름이 끼어들 여지는 없는가?
이 단계에서는 모든 코드를 다 의심하지 않습니다. 문제가 발생할 수 있는 구간을 좁혀 가며 가설을 세웁니다. 예를 들어 용이의 경우, is_pod_available()과 assign_request() 사이가 바로 그런 지점이었습니다. 상태를 읽는 시점과 상태를 바꾸는 시점이 분리되어 있었고, 그 사이에 다른 요청이 들어올 수 있었습니다. 이 지점을 특정하지 못하면, 디버깅은 끝없는 시도와 실패의 반복이 됩니다.