AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

Claude는 최소한으로, GPT-5.4는 과도하게, AI 코딩 편집 스타일 비교 실험

버그 하나 고쳐달라고 했는데, 함수 전체가 바뀌어 돌아온 경험이 있으신가요? 없던 헬퍼 함수가 생기고, 멀쩡한 변수명이 바뀌고, 입력 검증 코드까지 새로 추가된 채로요. 이게 AI 코딩 도구의 흔한 문제인지, 모델마다 얼마나 다른지 실제로 측정한 실험 결과가 나왔습니다.

사진 출처: nrehiew.github.io — GPT-5.4(High)가 range() 한 줄 수정으로 끝날 버그에 함수 전체를 재작성한 예시

싱가포르국립대 연구자 nreHieW가 AI 코딩 모델의 “과도한 편집(Over-Editing)” 문제를 정량적으로 측정하고, 이를 줄이기 위한 파인튜닝 실험 결과를 공개했습니다. 최신 프론티어 모델 17종을 대상으로 얼마나 많이, 불필요하게 코드를 수정하는지 비교했고, Claude Opus 4.6이 정확도와 수정 최소성 모두에서 가장 좋은 결과를 냈습니다.

출처: Coding Models Are Doing Too Much – nrehiew.github.io

버그 수정에서 ‘적게 고치는 것’이 왜 중요한가

AI 코딩 도구의 실패를 이야기할 때 보통은 틀린 코드를 떠올립니다. 하지만 이 연구가 주목하는 실패는 다릅니다. 테스트를 통과하면서도, 요청받은 것보다 훨씬 많이 고쳐버리는 경우입니다.

기존 코드베이스에서 작업하는 상황을 생각해 보세요. 팀이 의도를 갖고 작성한 코드, 이미 이해한 코드에서 버그 하나를 수정할 때, 모델의 역할은 그 버그만 고치는 겁니다. 그런데 모델이 함수 구조를 뜯어고치고, 없던 방어 로직을 추가하고, 변수명까지 바꿔버리면 어떻게 될까요? 테스트는 통과했지만, 리뷰어는 뭐가 바뀐 건지 파악하기 위해 처음부터 다시 읽어야 합니다. 코드 리뷰가 이미 병목인 상황에서, 과도한 편집은 그 부담을 더 키웁니다.

어떻게 측정했나

“최소한의 수정”이 얼마나 잘 지켜지는지를 측정하려면, 정답이 명확한 데이터셋이 필요합니다. 연구팀은 BigCodeBench의 400개 문제를 프로그래밍적으로 오염시켰습니다. 비교 연산자 뒤집기(<<=), +-로 바꾸기, 불리언 값 변경처럼 구조는 그대로이고 값만 바뀐 버그들입니다. 이렇게 하면 정답 수정은 그 변경을 되돌리는 것 하나뿐이라는 게 보장됩니다.

평가 지표는 두 가지입니다. 첫째는 토큰 레벨 Levenshtein Distance로, 모델이 실제로 얼마나 많은 코드를 바꿨는지를 측정합니다. 둘째는 인지 복잡도(Cognitive Complexity) 증가량인데, 오염 자체가 코드 구조를 바꾸지 않으므로 올바른 수정이라면 이 값이 0이어야 합니다. 0보다 높으면 요청받지 않은 구조 변경이 추가된 것입니다.

모델마다 얼마나 다른가

결론부터: 모든 프론티어 모델이 과도하게 편집하지만, 정도는 크게 다릅니다.

모델정확도(Pass@1) ↑Levenshtein ↓인지 복잡도 증가 ↓
Claude Opus 4.6 (추론)0.9120.0600.200
Gemini 3.1 Pro Preview (추론)0.8580.1450.501
GPT-5.4 (추론)0.7230.3952.313

Claude Opus 4.6은 정확도 1위(0.912)이면서 수정량도 가장 적습니다(Levenshtein 0.060). GPT-5.4는 정반대입니다. 정확도는 모델 중 하위권이면서(0.723), 인지 복잡도는 2.3이나 올라갑니다. 버그 수정보다 ‘더 좋은 코드’를 만들려는 쪽으로 작동하는 겁니다.

추론 모델과 비추론 모델을 비교하면 또 다른 패턴이 나옵니다. 기본 설정에서는 추론 모델이 더 많이 과도하게 편집합니다. 더 길게 생각할수록 ‘이 코드를 더 개선할 수 있겠다’는 방향으로 흐르는 것입니다. 예외는 Claude Opus 4.6으로, 추론 모드에서 오히려 수정량이 줄었습니다.

프롬프팅 한 줄이면 달라진다

연구자는 “원본 코드와 로직을 최대한 보존하세요”라는 지시 한 줄을 추가했을 때 결과가 어떻게 변하는지도 확인했습니다. 17종 모두 Levenshtein Distance가 줄었습니다. 추론 모델에서 효과가 더 컸는데, 이 지시가 검색 공간을 좁혀 오히려 버그를 정확히 찾아내는 데도 도움이 됐습니다. 실제로 Pass@1도 대부분 소폭 올랐습니다.

즉, 과도한 편집은 능력의 한계가 아니라 기본 동작의 문제입니다. 추론 모델일수록 이 지시를 더 잘 따릅니다.

훈련으로 고칠 수 있을까

프롬프팅보다 근본적인 해결책, 파인튜닝도 실험했습니다. Qwen3 4B 기반으로 SFT, DPO, RL 네 가지 방식을 비교했는데, 핵심 결과는 분명합니다.

SFT는 동일한 버그 유형에서는 거의 완벽하지만, 새로운 버그 유형에서는 Pass@1이 0.735에서 0.458로 무너집니다. 특정 패턴만 외웠을 뿐, 일반적인 최소 편집 능력을 학습하지 못한 겁니다. RL(강화학습)만이 새로운 유형의 버그에서도 성능이 유지되고, 일반 코딩 능력의 저하도 없었습니다. 14B 모델에서도 같은 패턴이 확인됐습니다.

“SFT는 암기하고, RL은 일반화한다”는 기존 연구의 결론과 맞닿는 결과입니다.

이 실험이 보여주는 것

AI 코딩 도구가 더 많이 쓰일수록, 코드를 ‘얼마나 바꿨는가’가 중요한 품질 기준이 됩니다. 정확도만 보던 기존 벤치마크로는 이 차이가 보이지 않습니다. 이 연구는 그 차이를 수치로 보여준 첫 시도 중 하나입니다.


AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다