개요
Over-Editing은 모델이 버그를 고치는 데 필요한 최소 수정 범위를 넘어, 함수 전체 재작성이나 보조 로직 추가, 시그니처 변경까지 해버리는 현상입니다.
테스트는 통과할 수 있지만, brown-field 코드베이스에서는 리뷰 가능성, 변경 안전성, 유지보수성이 크게 떨어질 수 있습니다.
한 줄 요약
“Over-Editing은 정확성 실패가 아니라 편집 충실도 실패이며, 테스트 통과만으로는 잘 드러나지 않는다.”
왜 문제인가
green-field에서는 더 나은 구현이 도움이 될 수 있지만, 기존 코드베이스에서는 이미 팀이 이해하고 운영하는 구조를 존중하는 편이 더 중요합니다.
과도한 편집이 생기면:
- diff가 불필요하게 커짐
- 리뷰어가 무엇이 왜 바뀌었는지 파악하기 어려워짐
- 변경 안전성 판단이 어려워짐
- 불필요한 복잡성이 조용히 누적됨
즉, 정답을 맞혔는가와 좋은 방식으로 고쳤는가는 다른 문제입니다.
측정 방법
연구는 BigCodeBench 문제 400개를 프로그램적으로 손상시켜, 정답 수정이 사실상 하나뿐인 최소 수정 문제를 만들었습니다.
핵심 지표:
- 토큰 단위 Levenshtein Distance
- 상대 패치 점수
- Added Cognitive Complexity
특히 Added Cognitive Complexity는 구조를 건드리지 않아도 되는 문제에서 복잡도가 증가하면, 그 자체를 과도한 편집의 신호로 봅니다.
결과 해석
모델들은 실제로 Over-Edit하는가
- 최신 frontier 코딩 모델 전반에서 과도한 재작성 경향이 확인됨
- 정확성과 최소 수정성은 별개 축으로 드러남
- Claude Opus 4.6은 정확성과 최소 수정성 조합이 강함
- GPT-5.4는 상대적으로 과도한 편집 경향이 두드러짐
즉, 코딩 모델 평가는 단순 Pass@1만으로는 부족합니다.
프롬프트로 줄일 수 있는가
원본 코드와 로직을 최대한 보존하라는 명시적 지시가 diff를 줄임- 특히 추론 모델에서 효과가 더 크게 나타남
기본 행동은 과도하게 손대는 쪽이지만, 제약을 주면 더 충실한 편집으로 이동할 수 있다는 뜻입니다.
학습으로 개선할 수 있는가
- SFT는 특정 손상 유형엔 강했지만 일반화와 일반 능력 유지에서 실패
- RL은 최소 편집 행동을 익히면서 일반 코딩 성능을 해치지 않음
- LoRA 기반 RL도 상당 부분 효과적
즉, 최소 편집성은 단순 프롬프트 기교가 아니라 학습 가능한 편집 스타일로 보입니다.
실무적 의미
이 연구가 실무에 주는 메시지는 명확합니다.
- 테스트 통과만으로 충분하지 않음
- brown-field 작업에서는
얼마나 적게 바꿨는가도 봐야 함 - 코드 에이전트 평가는 정확성 + diff 크기 + 복잡도 증가를 함께 봐야 함
- 하니스와 프롬프트에 최소 수정 지시를 넣는 것이 실질적 개선책이 될 수 있음
연결되는 주제
Hashline: 편집 포맷이 수정 충실도에 영향을 줌AGENTS.md: 원본 보존 규칙을 명시적으로 넣을 수 있음코드 리뷰: 변경량과 복잡도 증가를 별도 기준으로 봐야 함RL for coding: 정확성뿐 아니라 편집 스타일도 학습 대상이 됨