버그 수정인데도 코드 전체를 다시 쓰는 과잉 편집을 잽니다 | DAKER 커뮤니티

2026년 9월 3일 코드 과잉 편집(over-editing) 논문이 arXiv에 공개되었습니다. LLM 코드 수정에서 정답만으로는 부족하고, 최소·리뷰 가능·원본에 충실한 패치가 필요하다고 적습니다. 과잉 편집은 버그 수정에 필요한 범위를 넘어 코드를 다시 쓰는 경향입니다. BigCodeBench 문제 400개에서 AST 수준 제어 오류를 넣어, 과제마다 알려진 최소 패치를 둡니다. 프론티어 LLM에서도 과잉 편집이 흔하며, 강한 모델(예: GPT-5.5)도 높은 Pass@1과 불필요하게 큰 편집·인지 복잡도 증가가 공존한다고 보고합니다. 보존 지시(preservation instruction)로 평균 excess Levenshtein이 0.195에서 0.131로 줄고, 추가 인지 복잡도는 26.6% 감소하며, Pass@1은 2.3포인트 오른다고 적습니다. 이득이 더 큰 추론 예산이나 더 큰 모델만으로 따라오지 않으며, 지도 미세조정은 본 오류 패턴에 과적합하고 강화학습이 도메인 밖 편집 충실도에서 최선이라고 보고합니다.

논문은 2026-09-03 arXiv에 올라왔습니다. 초록은 arXiv:2609.04061에서 확인할 수 있습니다. 영문 제목은 When Models Edit Too Much: On the Fidelity of Minimal Code Edits입니다. 저자는 Tongyao Zhu, Wei Hern Lim, Min-Yen Kan입니다. PDF는 같은 번호의 pdf입니다. 오늘 본문은 초록에서 확인한 범위만 옮깁니다. 없는 숫자는 쓰지 않습니다.

최소 편집을 별도 축으로 두는 이유

초록은 LLM이 기존 코드를 수정하는 데 쓰이지만, 정답만으로는 부족하다고 적습니다. 유용한 수리는 최소이고, 리뷰 가능하며, 원본 구현에 충실해야 한다고 적습니다. 과잉 편집은 버그를 고치는 데 필요한 범위를 넘어 코드를 다시 쓰는 경향입니다.

평가 틀은 BigCodeBench 문제 400개에서 참고 해답에 AST 수준 제어 오류를 넣어 만듭니다. 과제마다 알려진 최소 패치가 있으므로, 모델이 그 범위를 얼마나 넘는지를 잴 수 있습니다. Pass@1이 높아도 편집이 크고 인지 복잡도가 늘 수 있다고 적습니다.

DACON·DAKER에서 코드 수정 데모를 낼 때도, “테스트 통과”와 “편집 크기·원본 보존”을 같은 줄에 두지 마십시오. Pass@1만으로 패치 품질을 끝내지 않습니다.

보존 지시와 학습 방식

보존 지시(preservation instruction)를 쓰면 평균 excess Levenshtein이 0.195에서 0.131로 줄고, 추가 인지 복잡도는 26.6% 감소하며, Pass@1은 2.3포인트 오른다고 적습니다. 초록은 이 이득이 더 큰 추론 예산이나 더 큰 모델만으로 따라오지 않는다고 적습니다.

최소 편집을 사후학습으로 직접 배울 수 있는지에 대해, 지도 미세조정은 본 오류 패턴에 과적합한다고 적습니다. 강화학습이 도메인 밖 편집 충실도와 성능 유지의 균형에서 최선이라고 보고합니다. 해커톤 README에 숫자를 옮길 때는 “BigCodeBench 400”, “excess Levenshtein 0.195→0.131”, “인지 복잡도 −26.6%”, “Pass@1 +2.3포인트”만 한 줄에 고정합니다.

빌더 팀에 옮기는 점검

코드 수정 평가에 최소 패치 diff와 모델 diff를 나란히 둡니다. excess Levenshtein과 인지 복잡도 증가를 Pass@1 옆에 적습니다. 보존 지시 문장을 프롬프트 템플릿에 고정합니다.

지도 미세조정 데이터에 본 오류 패턴만 넣지 않았는지 점검합니다. 도메인 밖 오류로 편집 충실도를 따로 잽니다. API 키를 프롬프트나 공개 저장소에 넣지 않습니다.

DAKER 월간 해커톤 데모라면 배포 주소와 함께 “최소 패치 기준”과 “보존 지시 여부”를 README 상단에 둡니다. 초록에 없는 GitHub 주소를 만들지 마십시오. 배포가 제출입니다. 올린 링크가 제출입니다.

편집 충실도를 별도 축으로 잽니다

초록은 유용한 수리가 최소이고 리뷰 가능하며 원본에 충실해야 한다고 적습니다. 정답(Pass@1)만으로는 부족합니다. 과잉 편집은 버그 수정에 필요한 범위를 넘어 코드를 다시 쓰는 경향입니다.

BigCodeBench 문제 400개에서 AST 수준 제어 오류를 넣어 과제마다 알려진 최소 패치를 둡니다. 프론티어 LLM에서도 과잉 편집이 흔하다고 적습니다. 강한 모델 예로 GPT-5.5를 들며, 높은 Pass@1과 불필요하게 큰 편집·인지 복잡도 증가가 공존한다고 보고합니다.

보존 지시로 평균 excess Levenshtein이 0.195에서 0.131로 줄고, 추가 인지 복잡도는 26.6% 감소하며, Pass@1은 2.3포인트 오른다고 적습니다. 이 이득이 더 큰 추론 예산이나 더 큰 모델만으로 따라오지 않는다고 적습니다. 세 숫자를 한 셀에 두고 추론 예산 실험과 섞지 마십시오.

최소 편집을 사후학습으로 배울 때, 지도 미세조정은 본 오류 패턴에 과적합한다고 적습니다. 강화학습이 도메인 밖 편집 충실도와 성능 유지의 균형에서 최선이라고 보고합니다. SFT와 RL을 표의 서로 다른 행에 둡니다.

코드 수정 평가에 최소 패치 diff와 모델 diff를 나란히 둡니다. excess Levenshtein과 인지 복잡도 증가를 Pass@1 옆에 적습니다. 보존 지시 문장을 프롬프트 템플릿에 고정합니다.

이 글이 아닌 것입니다

모든 프론티어 모델이 같은 비율로 과잉 편집한다는 뜻이 아닙니다. 초록이 든 평가 틀과 예(GPT-5.5) 범위만 옮깁니다.

보존 지시만으로 항상 Pass@1이 오른다는 보증이 아닙니다. 보고된 0.195→0.131, −26.6%, +2.3포인트만 둡니다.

강화학습이 모든 코드 과제에서 최선이라는 뜻이 아닙니다. 도메인 밖 편집 충실도 축에서의 보고만 옮깁니다.

DACON·DAKER 공식 채점 규칙이 아닙니다. 빌더가 옮길 수 있는 측정 안내입니다.

숫자만 다시 고정합니다

오늘 본문은 초록 범위만 옮깁니다. 없는 숫자는 쓰지 않습니다. 위 절에 적은 계정·과제·통과율·개선폭·벤치 이름만 표에 남깁니다. DACON 알고리즘 대회와 DAKER 바이브코딩 해커톤 README에 옮길 때도 같은 표 형식을 씁니다. 배포가 제출입니다. 올린 링크가 제출입니다. 초록에 없는 GitHub 주소를 만들지 마십시오. API 키를 프롬프트나 공개 저장소에 넣지 않습니다. 평가 설정 파일과 결과 CSV 첫 열에 벤치 이름과 분할 이름을 고정합니다. 거절·통과·편집 크기·닫힌 루프 점수를 한 줄에 섞지 마십시오. 팀 회의 메모 첫 줄에 arXiv 번호와 제출일을 적습니다.

빌더가 오늘 점검할 공통 항목은 다음과 같습니다. 초록과 PDF를 같은 탭에 둡니다. 출처 링크는 abs와 pdf만 둡니다. 합니다체로 내부 메모를 쓰고, 없는 성능을 만들지 않습니다. 선택 배치와 전수 배치, 학습 하네스와 평가 하네스, 인식과 행동처럼 초록이 나눈 축을 표에서 합치지 않습니다. 데모 주소와 설정 파일을 함께 올립니다.

오늘 할 일

첫째, 초록과 PDF를 직접 여십시오. arXiv:2609.04061와 pdf를 같은 탭에 둡니다. 제출일 2026-09-03을 메모 첫 줄에 적습니다.

둘째, BigCodeBench 400 과제와 최소 패치를 표로 고정하십시오. AST 오류 주입 방식을 메모합니다.

셋째, Pass@1과 excess Levenshtein을 나란히 적으십시오. 정답만으로 끝내지 않습니다.

넷째, 보존 지시 전후 숫자 세 개를 한 셀에 두십시오. 0.195→0.131, −26.6%, +2.3포인트를 같이 둡니다.

다섯째, 추론 예산·모델 크기만으로 이득을 설명하지 마십시오. 초록의 부정을 그대로 적습니다.

여섯째, SFT 과적합과 RL 도메인 밖 충실도를 비교표로 만드십시오. 학습 레시피를 설정 파일에 고정합니다.

일곱째, 데모와 최소 패치 기준을 공개 주소로 올리십시오. 배포가 제출입니다. 올린 링크가 제출입니다.

출처: arXiv:2609.04061 — When Models Edit Too Much: On the Fidelity of Minimal Code Edits (2026-09-03) · PDF