이미 잘 돌아가는 코드에 언어 모델을 풀어놓으면 심심찮게 코드를 망가뜨린다. arXiv에 올라온 새 보고서가 그 직관에 숫자를 붙였다. 한 설정에서 자동 수리 루프는 정상 프로그램의 약 26%를 망가뜨린 반면, 실제로 고장 난 프로그램은 2.3%가량만 고쳤다. 열 배 넘게 틀린 방향으로 기울어진 비율이다.
핵심 요약
- 경쟁 프로그래밍 제출 코드로 측정한 결과, LLM 수리 루프의 정상 코드 손상률은 0.261, 버그 코드 수리율은 0.023에 그쳤다.
- 반복을 그대로 두자 모델은 같은 수정을 넣었다 뺐다 무한히 되풀이하는 유사 버그 수정 사이클에 빠졌다. 전체 파일 재작성보다 검색·치환 방식 편집에서 사이클이 더 많이 나왔다.
- 프로빙 결과 편집 성향을 예측하는 내부 방향이 나왔고, 19층 부근에서 거의 완벽하게 갈렸다. 이 방향을 억제하자 파괴적 루프는 완전히 멈췄다. 대신 진짜 수리도 전부 멈췄다.
무엇을 쟀나
시에타오 왕린, 안톤 이소푸수, 루이 마혼이 쓴 논문 If It's Not Buggy, Don't Fix It은 저자들이 맹목적 반복 사용이라 부르는 방식을 들여다본다. 모델에 프로그램을 주고, 돌아온 수정을 그대로 받아들이고, 다시 반복하는 흐름이다. 점점 많은 팀이 코드 리뷰에 수리 봇을 연결하는 방식과 정확히 겹친다.
실험대는 CodeContests+였다. 문제 20개, 문제당 C++ 제출 40건, 문제마다 평균 23개 테스트 케이스를 Google의 Gemini 2.5 Flash-Lite와 알리바바의 Qwen2.5-7B-Instruct에 돌렸다. 그리디 디코딩과 검색·치환 편집 조건에서 Gemini의 수리율은 0.023 ± 0.002, 손상률은 0.261 ± 0.032로 나왔다. 다른 설정에서는 손상률이 0.293 ± 0.011까지 올라갔다. 저자들의 요약은 짧고 단호하다. 손상률이 수리율보다 훨씬 높아질 수 있다는 것이다.
이 수치에는 단서 두 가지가 따라붙는다. 시험 대상 모델은 최전선 시스템이 아니라 작고 빠른 축이다. 경쟁 프로그래밍 제출 코드도 자체 테스트 스위트와 리뷰 게이트, CI를 갖춘 실서비스 코드베이스와는 다르다. 이 벤치마크가 재는 것은 종료 조건도 사람도 없는 루프다. 그게 논문의 의도이긴 하나, 잘 계측된 수리 파이프라인을 잰 것과 같지는 않다.
가라앉지 않는 루프
더 불편한 대목은 그 과정을 계속 돌렸을 때 벌어지는 일이다. 모델은 안정된 버전으로 수렴하는 대신, 논문이 유사 버그 수정 사이클이라 부르는 상태에 자주 빠졌다. 같은 변경을 넣고, 빼고, 다시 넣으면서 프로그램이 통과와 실패 사이를 오간다. 검색·치환 블록은 전체 파일 편집보다 이런 사이클을 훨씬 많이, 그리고 더 길게 만들어냈다.
운영 관점에서 이게 문제인 이유는 사이클에 빠진 에이전트가 겉보기엔 바빠 보이기 때문이다. diff를 만들고, 활동을 보고하고, 토큰을 쓴다. 루프 안에 테스트 오라클이 물려 있지 않으면, 출력만 봐서는 전진 중인지 제자리를 도는지 구분할 단서가 없다.
"버그처럼 보인다"를 담은 내부 방향
논문이 정말 흥미로워지는 지점은 메커니즘 분석이다. 저자들은 모델 활성값을 프로빙해 편집 성향을 추적하는 조향 벡터를 만들었다. 분리도는 초기 층에서 AUC 0.7~0.8이다가 19층 무렵 1.0에 가깝게 올라갔다. 모델이 '버그 있는 코드'라는 내부 표상을 지니고 있고, 그 표상이 멀쩡한 프로그램에서도 잘못 발화한다는 뜻이다. 신경망 안에 주소가 찍힌 환각인 셈이다.
γ = -0.5로 그 방향을 거슬러 조향하자 파괴적 루프는 완전히 멎었고 정상 제출은 모두 보존됐다. 동시에 고친 것도 하나 없었다. 바로 쓸 수 있는 조절 손잡이라기보다, 편집하려는 성향과 수리하는 능력이 이 모델들 안에서 얽혀 있음을 깔끔하게 보여준 결과다. 거짓 양성만 낮추고 참 양성을 남기는 선택은 불가능했다.
수리 봇을 굴리는 팀에 무엇이 달라지나
실무적으로 읽으면 자동 수리가 쓸모없다는 이야기가 아니다. 종료 조건이 곧 제품이라는 이야기다. '여기엔 고칠 게 없다'를 판정할 믿을 만한 오라클이 없는 수리 도구는 편집의 대부분을 손댈 필요가 없던 코드에 쓰게 된다. 위 계산은 그 편집들이 순손실이라고 말한다.
이미 출시된 도구들에서 보이는 설계 흐름에도 힘이 실린다. 초안과 작업 트리 사이에 독립 비평자를 끼워 넣는 리뷰-수정 패턴이 그것이다. 본지가 Project HydraFusion 보도에서 다룬 GitHub의 신규 프리뷰 오케스트레이션 계층에 들어간 교차 모델 비평 단계도 같은 갈래다. 이런 장치는 논문이 측정한 맹목적 루프를 끊으려고 존재한다. 손상이 수리를 열 배 앞지르는 상황에서, 반복 횟수 제한과 도구 없는 리뷰어, 안전 실패형 패치 적용은 더 이상 보수적인 설계 취향이 아니다.
전망
이 비율이 실제 저장소에서 최전선 모델에도 똑같이 성립하는지가 당연한 후속 질문이고, 이번 보고서가 거기까지 답하지는 않는다. 다만 이 실패 양상이 우발적이 아니라 구조적이라는 점은 분명히 세웠다. 편집하려는 성향이 내부에 표상돼 있고, 그것이 멀쩡한 코드에서 발화하며, 반복이 이를 씻어내기는커녕 증폭한다. 완전 자율 수리를 만드는 쪽이라면 다음 모델이 알아서 해결해 주기를 기다릴 게 아니라 이 조건을 전제로 설계해야 한다.
FAQ
연구는 어떤 모델을 시험했나?
Gemini 2.5 Flash-Lite와 Qwen2.5-7B-Instruct다. 둘 다 최전선 시스템이 아니라 작고 저렴한 모델이다. 따라서 보고된 수치를 최상위 코딩 모델의 성능으로 읽어서는 안 된다.
그럼 AI 코드 리뷰 도구가 코드를 더 나쁘게 만든다는 뜻인가?
그것만으로는 아니다. 연구가 잰 것은 종료 조건도 사람 리뷰도 없는 맹목적 반복이며, 이는 일반적인 운영 형태라기보다 최악의 경우다. 수리 도구를 자율적으로 굴릴수록 이 결과의 무게도 커진다.
잘못된 버그 탐지만 꺼버릴 수는 없나?
깔끔하게는 안 된다. 저자들이 찾은 조향 벡터는 파괴적 편집 루프를 없앴지만, 적용하는 순간 성공적인 수리도 전부 사라졌다. 같은 내부 표상이 두 행동을 함께 몰고 간다는 뜻이다.
