도구 이름 나열에 머무는지, 본인이 실제로 어떤 절차로 원인을 좁히고 재현을 고정하는지 일관된 루프로 설명할 수 있는지를 가른다.
효과적인 디버깅은 "증상을 빨리 없애는 것"이 아니라 재현 조건을 고정하고 원인 범위를 단계적으로 좁히는 일이다. 로그·트레이스·메트릭으로 사실을 모으고, 최근 변경과 정상 케이스를 비교해 가설을 세운 뒤 코드 구간·설정·데이터 차원에서 이분 탐색으로 가설을 하나씩 반증한다. 진짜 원인을 짚었다면 동일한 절차로 재현되는지 다시 확인한 뒤 고치고, 원인·재현 방법·재발 방지책을 기록해 같은 버그를 두 번 만나지 않게 만든다.
간헐 버그를 최소 재현 예제로 좁혀본 경험이 있다면 재현 고정 단계의 중요성을 본인 사례로 풀 수 있다
정상 케이스와 실패 케이스의 입력·환경을 나란히 놓고 차이를 찾아낸 경험이 있다면 가설 세우기 원리로 일반화해 설명할 수 있다
팀에 디버깅 노트·포스트모템 문화를 만들어본 경험이 있다면 "디버깅을 자산으로 쌓는" 이야기로 자연스럽게 이을 수 있다
AI가 제안한 원인이 실제론 다른 곳이었던 경험이 있다면 "검증을 사람이 들고 가는 이유"를 본인 사례로 풀 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.