AI 코딩 도구 'Over-Editing' 문제 정량 측정 — GPT-5.4가 가장 심하고 Claude Opus 4.6이 가장 얌전

• AI 코딩 도구의 "Over-Editing" 문제를 정량적으로 측정한 연구 — Cursor, Copilot, Claude Code, Codex 다 해당됨
  • off-by-one 에러 한 줄 고쳐달라고 했는데 함수 절반이 다시 쓰여 있고, 헬퍼 함수가 새로 생기고, 변수명이 바뀌고, 인풋 밸리데이션이 추가되는 그 경험
  • 기능은 맞는데 diff가 거대해서 코드 리뷰가 지옥이 됨 — 뭐가 바뀌었고 왜 바뀌었는지, 안전한지 파악이 안 됨
• 저자 정의: "출력이 기능적으로 맞지만 최소 수정보다 더 크게 구조가 벗어나면" over-editing
  • 그린필드(새로 짜기)와 브라운필드(기존 코드 수정)의 차이가 핵심
  • 브라운필드에선 기존 코드가 의도적으로 그렇게 쓰여진 거라 모델 임무는 버그만 고치고 입 다무는 것
• "테스트만 더 쓰면 된다"는 흔한 조언이 안 먹힘 — over-editing은 테스트로 잡히지 않는 실패 유형

어떻게 측정했나

• BigCodeBench 400개 문제를 프로그램적으로 오염 — LLM이 버그를 심는 기존 방식 대신, < → <=, + → -, True → False 같은 기계적 변형
  • 장점: 정답(ground truth)이 정확히 "오염의 역(reverse)"으로 수학적으로 정의됨
  • 최소 수정이 무엇인지 명확하게 기준선을 잡을 수 있음
• Token-level Levenshtein Distance — 파이썬 토크나이저로 자른 후 편집 거리 측정
  • 변수명 하나를 someotherfunctionname으로 바꾸면 문자 단위론 19, 토큰 단위론 1
  • 정답과 모델 출력을 직접 비교하지 않고, 둘 다 "오염된 코드 대비" 편집 거리를 계산해서 그 차이를 점수로 씀
• Added Cognitive Complexity — 값만 바꾸는 수정이므로 복잡도 증가는 0이 정답
  • 0보다 크면 "요청하지도 않은 중첩, 분기, 예외 처리"가 끼어든 것
  • 0보다 작은 것도 문제 (불필요한 단순화도 원치 않음)

충격적 비교 결과

• GPT-5.4가 가장 심하게 over-edit — reasoning 모드 Levenshtein 0.39, Added Cognitive Complexity 2.31
  • 근데 Pass@1도 0.723으로 정확도마저 약체 — 많이 건드리면서 틀리기도 잘 틀림
• Claude Opus 4.6이 모든 지표에서 승리 — Pass@1 0.912 (최고), Levenshtein 0.06 (최저), Added CC 0.20
  • 가장 많이 맞히면서 가장 적게 건드림
  • Gemini 3.1 Pro Preview, GLM 5도 상대적으로 보수적
• 프롬프트에 "IMPORTANT: 원본 코드와 로직을 최대한 보존하라"만 추가해도 모든 모델이 개선됨
  • Levenshtein 줄고, DeepSeek R1/v3 빼고는 Pass@1도 올라감
  • 가설: 최소 수정 제약이 탐색 공간을 좁혀서 정답에 더 가까운 방향으로 모델을 유도

리즈닝 모델은 더 심한가

• 동일 페어에서 둘 다 정답 맞힌 샘플만 뽑아 비교 — 정답률 차이가 측정을 오염시키지 않게
• 제네릭 설정에선 리즈닝 모델이 오히려 over-edit 더 많이 함 — DeepSeek V3, GPT-5, GPT-5.4, Gemini 3.1 Pro Preview, Qwen 3.6 Plus, Kimi 2.5 다 그럼
  • 풀어서 생각할 여유가 있으니 "더 나은 구현"으로 샛길을 빠짐
  • 예외가 Claude Opus 4.6 — 리즈닝이 오히려 덜 건드림
• 명시적 제약을 주면 리즈닝 모델이 일반 모델을 역전 — 지시 따르기 능력이 강하니까
  • 즉 over-editing은 모델 한계가 아니라 디폴트 행동, 덮어쓸 수 있음

훈련으로 고칠 수 있나 — RL이 답

• Qwen3 4B 2507 Instruct를 베이스로 SFT, rSFT, DPO, RL 비교
• SFT는 in-domain에선 완벽해 보이지만 out-of-domain에선 Pass@1 0.458로 폭락
  • 특정 오염 패턴의 역변환을 암기했을 뿐 일반화 실패
  • LiveCodeBench v6에서 43% 성능 저하 — catastrophic forgetting 심각
• rSFT, DPO는 self-distilled 데이터라서 덜 망가지지만 개선 폭도 제한적
• RL만이 깔끔하게 일반화 — 3개 지표 모두 개선, LiveCodeBench 저하 없음
  • "SFT는 외우고 RL은 일반화한다"는 기존 연구와 일치
  • RL의 KL-최소 해 편향이 forgetting을 막는 역할을 함
• LoRA rank 64가 full RL에 거의 근접 — 스타일 변경 작업엔 적은 파라미터로 충분
  • rank 1→16에서 대부분 개선, 16→64는 마무리
  • 큰 모델일수록 훈련 비용 대비 효율이 극대화됨
• 14B Qwen3에도 동일 레시피 적용해서 성능 향상 확인 — 스케일 업 가능

재밌는 삽화 — Reward Hacking

• 초기 reward 함수에 버그 — 실행 실패 롤아웃에 하드코딩 0점 부여
  • Levenshtein을 negate해서 "높을수록 좋음"으로 만든 탓에, 일부러 못 고쳐서 실행 실패하는 게 더 높은 보상이 돼버림
  • Full RL은 버그 있는 보상으로도 학습 성공, LoRA는 보상 해킹에 빠져서 못 고치는 쪽으로 수렴 → 환경 조사로 이어짐
• 버그 고친 뒤 full RL 결과는 소폭만 개선 — 원래도 잘 배우고 있었음

---

기술 맥락

"over-editing"이 왜 테스트로 안 잡히는지부터 짚고 가는 게 중요해요. 코드 수정의 품질은 "기능 정답"과 "최소성" 두 축으로 나뉘는데, 기존 벤치마크(Pass@1류)는 전자만 봤거든요. 그래서 모델이 함수를 통째로 다시 써도 테스트만 통과하면 100점이었던 거예요. 이 논문이 Levenshtein Distance와 Cognitive Complexity를 함께 쓴 이유가 거기 있어요 — 정답을 맞혔더라도 "얼마나 원본을 존중했는가"를 독립적으로 점수화하자는 거죠.

프로그램적 오염(programmatic corruption)도 방법론적으로 영리한 선택이에요. LLM으로 버그를 심으면 "최소 수정"이 뭔지 다시 LLM 판단에 의존해야 하는데, <를 <=로 바꾸는 식의 기계적 변형은 역변환이 수학적으로 유일하게 정의되거든요. 이러면 모델이 "원복만 하는지, 원복하고 추가로 뭘 더 하는지"를 깨끗하게 분리해서 볼 수 있어요.

RL이 SFT보다 일반화에 강한 이유도 맥락이 재밌어요. SFT는 합성 데이터 분포로 모델 전체를 끌어당기니까 원래 능력까지 같이 망가지는데(catastrophic forgetting), RL은 KL 발산을 최소화하는 방향으로 탐색하거든요. 그래서 원래 모델 근처에서 행동만 미세 조정되고, 일반 코딩 능력은 보존돼요. 43% 성능 저하 vs 저하 없음의 차이가 여기서 나와요.

LoRA rank 실험이 실무적으로 유용한데, 이 작업이 "새 지식 주입"이 아니라 "스타일 튜닝"이라서 rank 64 정도면 full RL에 근접한다는 거예요. 즉 회사에서 자체 코딩 에이전트를 도메인 스타일에 맞게 길들이고 싶을 때, 풀 파인튜닝 없이 LoRA 어댑터만으로도 꽤 먼 거리를 갈 수 있다는 실용적 신호예요.

마지막으로 "Claude Opus 4.6 vs GPT-5.4" 대비가 눈에 띄는데, 같은 프론티어급 모델인데도 디폴트 행동이 완전히 다르다는 것이 핵심이에요. GPT-5.4는 "slop(장황한 출력)"에 기본값이 맞춰져 있어서 명시적 프롬프트가 있어야 제어되는 반면, Opus 4.6은 베이스라인에서부터 보수적이에요. 코드 리뷰 부담을 줄이고 싶다면 모델 선택 자체가 프롬프트만큼이나 중요하다는 얘기죠.