Claude가 같은 버그를 고치려고 4번이나 헛다리를 짚었네요. 팀원은 30분 만에 해결했습니다.
Claude tried 4 wrong fixes for the same bug. My teammate found it in 30 min.
핵심 요약
Claude가 잘못된 원인을 가정하고 헛수고를 하는 동안, 팀원은 데이터 확인을 통해 30분 만에 버그를 해결했습니다.
- AI의 한계 — AI는 지시받은 문제에만 집중하며 근본 원인을 스스로 파악하는 데 취약함
- 문제 해결 방식 — 데이터의 유효성을 먼저 확인하는 것이 네트워크 오류를 가정하는 것보다 효율적임
- 새로운 규칙 — 데이터가 보이지 않는 버그 발생 시 무작정 추측하기 전에 데이터 샘플부터 확인해야 함
저는 Claude를 코딩 도우미로 활용해 앱을 만들고 있습니다. 어제 앱이 고장 났는데, 사용자들이 데이터를 볼 수 없는 상태였습니다. Claude에게 수정을 요청했죠.
Claude는 로그에서 "too many requests" 오류를 발견하고는 그게 문제라고 판단했습니다. 그래서 4가지 다른 수정안을 내놓았죠. 각각 깔끔하게 배포까지 됐습니다. 하지만 그중 무엇도 실제로 버그를 고치지는 못했습니다.
진짜 문제는 완전히 다른 곳에 있었습니다. 저희가 사용하는 라이브러리가 레이블 지정 방식을 바꿨는데, 앱은 여전히 예전 레이블을 읽고 있었던 겁니다. 그래서 모든 데이터가 빈칸으로 나왔던 거죠. 제 팀원은 데이터 하나를 출력해보고는 "잠깐, 왜 이게 비어있지?"라고 말하며 30분 만에 문제를 찾아냈습니다.
나중에 Claude에게 왜 이걸 놓쳤냐고 물어보니, 솔직한 답변은 이랬습니다. 원인처럼 보이는 첫 번째 단서에만 매몰되어 의심조차 하지 않았다는 겁니다. 데이터 조각 하나를 먼저 보고 "이게 말이 되나?"라고 묻는 가장 간단한 확인조차 하지 않았던 거죠.
교훈은 이렇습니다. AI는 당신이 지목한 문제를 해결하는 데는 정말 뛰어나지만, 어떤 문제를 살펴봐야 할지 선택하는 데는 서툽니다. 만약 제가 "네트워크 문제라고 가정하기 전에 먼저 데이터가 제대로 나오는지부터 확인해봐"라고 말했다면, 버그를 금방 잡아냈을 겁니다.
"데이터가 안 보여요"라는 버그에 대한 저의 새로운 규칙은 이렇습니다. 먼저 깨진 데이터 중 하나를 직접 확인하세요. 그러고 나서 추측을 시작하세요.
세 줄 요약: AI에게 무엇을 먼저 검증해야 할지 알려주지 않으면, 아주 효율적으로 엉뚱한 것만 고치게 될 겁니다.
