📈 AI 코드 과잉 수정, 지시문 한 줄로 줄어들었다

AI에게 버그 하나를 고쳐달라고 부탁했는데, 돌아온 것이 파일 절반을 새로 쓴 결과물이었던 경험이 있을 것이다. 테스트는 통과한다. 동작도 한다. 그런데 리뷰를 하려니 어디가 바뀐 건지 알 수가 없고, 결국 처음부터 다시 읽게 된다. 이 현상에 이름을 붙이고 숫자로 재본 연구가 나왔다. 저자들은 이를 과잉 수정(over-editing)이라고 부른다.

정답을 알고 채점하는 시험지를 만들었다

이 문제를 재려면 걸림돌이 하나 있다. "최소한의 수정"이 무엇인지 아무도 모른다는 것이다. 사람이 짜준 패치도 최소라는 보장이 없다.

연구진은 문제를 거꾸 뒤집어 풀었다. BigCodeBench의 문제 400개에서 정답 코드를 가져온 뒤, 여기에 AST(추상 구문 트리, 코드의 문법 구조를 나무 모양으로 표현한 것) 수준에서 통제된 손상을 일부러 주입했다. 어디를 어떻게 망가뜨렸는지 연구진이 알고 있으니, 각 수리 과제마다 "정확히 이만큼만 되돌리면 된다"는 최소 패치가 처음부터 확정되어 있다. 채점 기준이 있는 시험지를 만든 셈이다.

잘하는 모델도 예외가 아니었다

결과는 분명했다. 과잉 수정은 최신 모델 전반에서 광범위하게 나타났고, GPT-5.5처럼 강한 모델도 예외가 아니었다. 특히 눈에 띄는 것은 높은 Pass@1과 불필요하게 큰 편집이 함께 나타났다는 점이다. 정답률이 높다고 편집이 깔끔한 것이 아니었다. 늘어난 코드에는 인지 복잡도, 즉 사람이 읽고 이해하는 데 드는 부담의 증가도 함께 따라왔다.

그런데 완화책은 의외로 간단했다. 원본 구현을 최대한 보존하라는 취지의 지시문 한 줄이었다.

수정 범위를 좁혔더니 정답률이 떨어지기는커녕 2.3%포인트 올랐다는 대목이 흥미롭다. 손을 덜 대는 게 안전하기도 하다는 뜻이다.

돈으로 해결되지 않는 문제

여기서 이 논문의 가장 실용적인 발견이 나온다. 이 개선은 추론 예산을 늘리거나 더 큰 모델을 쓴다고 따라오지 않았다.

이것이 왜 중요한가. 우리는 보통 AI 결과물이 마음에 안 들면 더 비싼 모델로 바꾸거나 생각할 시간을 늘려서 해결하려 한다. 편집 충실도는 그 축에 놓여 있지 않았다. 모델을 키운다고 얌전해지지 않는, 별개의 성질이라는 뜻이다. 저자들이 편집 충실도를 코드 수리 품질의 독립된 축으로 자리매김하자고 제안하는 이유다.

이어서 연구진은 최소 편집을 사후 학습으로 가르칠 수 있는지 물었다. 지도 미세조정(SFT)은 학습 때 본 손상 패턴에 과적합했다. 즉 훈련에서 본 유형의 버그는 얌전하게 고치지만 처음 보는 유형에서는 다시 벌어졌다. 반면 강화학습은 도메인 밖 편집 충실도와 성능 유지 사이에서 가장 나은 절충을 보였다.

그래서 진짜 의미하는 것

과장하기 쉬운 지점부터 정리하자. 이 논문은 "AI 코딩 도구를 쓰지 말라"고 말하지 않는다. Pass@1은 여전히 높다. 모델은 버그를 실제로 고친다.

논문이 말하는 것은 정답률이라는 지표 하나로 코드 수리 도구를 고르면 놓치는 것이 있다는 쪽이다. 실무에서 패치의 가치는 동작 여부만으로 정해지지 않는다. 리뷰할 수 있어야 하고, 되돌릴 수 있어야 하고, 나중에 문제가 생겼을 때 원인을 좁힐 수 있어야 한다. 200줄이 바뀐 패치는 그 셋을 모두 어렵게 만든다.

한계도 짚어두는 것이 공정하다. 이 평가는 인위적으로 주입한 AST 손상을 되돌리는 과제이고, 실제 버그 수정과 완전히 같지는 않다. 현실의 버그는 최소 패치가 하나로 정해지지 않는 경우가 많고, 때로는 주변까지 손보는 것이 옳은 판단이기도 하다. 이 연구의 숫자는 "최소 패치가 명확한 상황에서도 모델이 필요 이상으로 고친다"는 것을 보인 것이지, 모든 확장 편집이 잘못이라는 뜻은 아니다.

실무에 어떤 의미인가

당장 적용할 수 있는 것은 두 가지다.

첫째, 프롬프트에 보존 지시를 명시하는 것이다. 필요한 최소한만 수정하고 나머지 구현은 그대로 두라는 문장 하나가 논문의 실험에서는 편집량과 인지 복잡도를 함께 줄이면서 정답률까지 올렸다. 비용은 사실상 없다.

둘째, 코드 수리 도구를 비교할 때 정답률 옆에 편집량을 함께 놓는 것이다. 팀에서 쓰는 도구가 여럿이라면, 같은 이슈를 던졌을 때 나오는 diff 크기를 기록해두는 것만으로도 비교 기준이 생긴다.

출처

Tongyao Zhu, Wei Hern Lim, Min-Yen Kan, "When Models Edit Too Much: On the Fidelity of Minimal Code Edits", arXiv:2609.04061, 2026년 9월 3일.