AI가 시키지도 않은 코드를 왜 고칠까? '최소 편집' 학습법 이야기

시키지도 않은 리팩터링, 다들 겪어보셨죠

커서(Cursor)나 클로드 코드(Claude Code) 같은 AI 코딩 도구를 쓰다 보면 한 번쯤 답답했던 순간이 있을 거예요. 분명 "이 함수에서 null 체크 하나만 추가해줘"라고 요청했는데, 돌아온 diff를 열어보니 함수 이름이 바뀌어 있고, 주변 변수도 camelCase에서 snake_case로 변경돼 있고, 심지어 관련 없는 import까지 정리돼 있는 경험이요. 커밋 하나에 온갖 변경이 섞여 있으니 리뷰도 힘들고, 롤백도 껄끄럽죠.

이 현상을 업계에서는 오버에디팅(Over-editing) 이라고 불러요. 말 그대로 "필요 이상으로 고친다"는 뜻인데요, 최근 한 연구자의 블로그에서 왜 LLM이 이런 버릇을 갖게 됐는지, 어떻게 학습 과정에서 고칠 수 있는지 체계적으로 분석한 글이 올라왔어요. AI 코딩 도구를 매일 쓰는 개발자라면 꽤 흥미로운 주제예요.

왜 모델은 "더 많이" 고치고 싶어할까

저자의 분석은 훈련 데이터 자체의 편향에서 출발해요. 생각해보면, LLM을 훈련시키는 데이터는 대부분 깃허브(GitHub) 커밋 로그예요. 그런데 실제 개발자들의 커밋을 보면, "버그 수정" 커밋 안에 리팩터링과 포맷팅 변경이 뒤섞여 있는 경우가 정말 많거든요. 린터가 자동으로 공백을 고쳤다거나, IDE가 import를 재정렬했다거나, 눈에 거슬리는 변수명을 겸사겸사 바꿨다거나요.

모델 입장에선 이게 "정상적인 편집 패턴"으로 보이는 거죠. 그래서 "null 체크 추가"라는 요청을 받았을 때, 학습된 대로 주변 코드까지 손대는 걸 자연스럽게 받아들여요. 이게 바로 오버에디팅의 근본 원인이에요.

저자가 제안하는 해결책은 미니멀 에디팅(minimal editing) 기반 강화학습이에요. 같은 문제를 해결하는 여러 개의 diff 후보를 모델에게 만들게 한 뒤, 그중 변경 라인 수가 적으면서도 요구사항을 정확히 만족하는 diff에 더 높은 보상을 주는 방식이죠. 비유하자면, 같은 수술을 해도 절개선이 짧은 쪽에 점수를 더 주는 거예요. 실험 결과 미니멀 에디팅으로 튜닝된 모델은 동일한 버그를 고치면서도 불필요하게 주변을 건드리는 비율이 크게 줄었다고 해요.

업계는 이미 이 방향으로 움직이고 있어요

이 이슈는 특정 도구만의 문제가 아니에요. 깃허브 코파일럿, Aider, 클로드 코드 같은 에이전트형 코딩 도구 전반의 공통 과제거든요. 앤트로픽은 클로드에 "surgical editing(외과 수술처럼 정확한 편집)" 개념을 시스템 프롬프트에 녹여 넣고 있고, 커서도 최근 평가 지표에 "edit locality(편집의 국소성)"를 추가했어요. OpenAI의 Codex CLI도 비슷한 방향으로 튜닝되는 중이고요.

즉, AI 코딩 도구의 다음 경쟁 포인트는 "얼마나 많은 걸 해주느냐"에서 "얼마나 요청한 만큼만 정확히 해주느냐"로 옮겨가고 있어요.

실무에서 당장 써먹을 수 있는 팁

학습 과정을 바꿀 수 없는 일반 개발자라도 지금 바로 써먹을 수 있는 방법이 있어요. 첫째, 프롬프트에 범위를 명시하세요. "이 함수 외에는 수정 금지", "기존 네이밍 스타일 유지", "import 정리 금지" 같은 가드를 걸어두면 오버에디팅이 꽤 줄어요. 둘째, diff를 승인하기 전에 반드시 변경 범위를 눈으로 확인하는 습관을 들이세요. 셋째, 사내에 자체 파인튜닝 모델을 운영한다면, 학습 데이터를 "커밋 단위"가 아니라 "하나의 의도 단위"로 쪼개 큐레이션하는 게 중요해요.