코딩 에이전트가 오류가 발생하는 지점(line)을 수정하는 경향에 대한 고찰

에이전트에게 스택 트레이스(stack trace)를 주고 어디서 수정이 이루어지는지 관찰해 보세요. 거의 항상 오류가 발생한 바로 그 라인에서 수정됩니다. 널 체크(null check), 기본값 설정, try/except 구문, 조기 반환(early return) 등이 그렇죠. 오류는 사라지고 테스트는 통과하지만, 그것을 유발했던 잘못된 값은 여전히 어딘가의 상위 단계(upstream)에서 생성되고 있으며, 이제는 크게 실패하는 대신 조용히 처리됩니다.

오류가 발생한 라인이 에이전트가 가진 유일한 증거이기 때문에, 그곳을 수정합니다. 값이 잘못된 곳까지 추적하려면, 지시받지 않은 코드를 읽어야 하는데, '이 오류를 고쳐라'라는 요청에는 그런 내용이 포함되어 있지 않습니다.

제가 버그를 수정하기 전에 추가하는 것:
어떤 것도 편집하기 전에, 잘못된 값을 그것이 생성된 곳까지 추적합니다. 파일과 라인 번호를 명시하며 근본 원인(root cause)을 한 문장으로 진술합니다. 그런 다음만 수정을 제안하고, 오류가 발생한 라인이 아니라 근본 원인에서 수정합니다.

그리고 지침 파일에 규칙으로 추가할 내용:
만약 당신의 수정이 오류가 발생한 라인에서의 널 체크, 기본값 설정 또는 예외 처리라면, 실제 원인이 상위 단계(upstream)에 있지 않은 이유를 설명하세요. 만약 할 수 없다면 계속 추적하세요.

두 번째 항목이 대부분을 잡아냅니다. '원인이 상위 단계가 아닌 이유를 설명하라'는 질문은 에이전트가 실제로 살펴보지 않으면 보통 답할 수 없으며, 일단 살펴보기 시작하면 원인을 찾아냅니다.

반복되는 버그에 도움이 되는 또 다른 방법:
코드베이스에서 이 동일한 값이 흘러 들어가는 다른 장소들을 검색합니다. 그 목록을 작성하세요. 그곳들도 같은 방식으로 실패할까요?

이 목록은 종종 수정 사항보다 더 길습니다.

저는 AI Toolbox에 근본 원인 프롬프트(root-cause prompt)를 저장해 두고, 에이전트가 아닌 ChatGPT나 Claude 채팅에서 디버깅할 때 사용합니다. 그곳에서는 동일한 증상 패치(symptom-patching)가 발생하기 때문입니다.

/u/Ok_Negotiation_2587 님이 제출했습니다. [link] [comments]