Claude가 짠 코드를 소리 내 읽었더니 수락률 40%로 뚝
한 개발자가 약 1년간 Claude가 만든 코드 를 대충 훑어보고 바로 수락하는 방식으로 작업해왔다. 빠르고 편했지만, 월요일에 받아들인 코드를 제대로 읽지 않은 탓에 목요일마다 그 코드를 디버깅하는 일이 반복됐다. 두 달 전부터 규칙을 하나 정했다: 코드를 수락하기 전에 바뀐 줄을 실제로 입으로 소리 내어 읽는 것이다.
그냥 눈으로 훑는 게 아니라 말로 설명하려다 보면 눈으로 스킵하던 문제들이 걸린다. 철자가 살짝 다른 변수명, 자신 있게 처리됐지만 틀린 (), 멀쩡히 동작하지만 애초에 필요 없던 문제를 푸는 함수 등이 그렇게 잡혔다. 이 습관을 들인 뒤 코드 수락률이 거의 100%에서 약 40%로 떨어졌고, 버그는 그보다 더 크게 줄었다.
나머지 60%는 모델이 나빠서가 아니라, 본인이 "왜 이런 방식으로 했지?"라고 되물으면서 대화에 다시 참여하게 됐고, 그 결과 더 나은 답을 받아냈기 때문이다.
핵심 포인트
- 약 1년간 Claude의 를 대충 훑고 바로 수락해오다 실제로 이해 못 한 코드 때문에 나중에 디버깅에 시달림
- 2개월 전부터 수락 전 변경된 코드를 소리 내어 읽는 규칙을 도입
- 코드 수락률이 거의 100%에서 약 40%로 하락, 버그는 그보다 더 크게 감소
- 거절된 60% 중 대부분은 모델 결함이 아니라 되물어서 더 나은 답을 얻어낸 경우
- 핵심 교훈: 모델이 좋아질수록 사람이 검토 과정에서 소외(rubber stamp화)되기 쉬우므로 의도적으로 개입 장치가 필요