이 논문은 **"인공지능 (LLM) 이 코드를 정리해 줄 때, 정말로 잘해내는가?"**라는 질문에 답하기 위해 진행된 대규모 실험 결과입니다.
쉽게 말해, **"AI 가 코드를 '예쁘게' 고쳐달라고 여러 번 시켰을 때, 어떻게 변하는지"**를 관찰한 연구입니다.
이 복잡한 연구를 일상적인 비유로 설명해 드리겠습니다.
🎨 비유: "AI 요리사"와 "요리 레시피"
이 실험은 AI 를 '요리사'로, 코드를 '레시피'로 상상하면 이해하기 쉽습니다.
실험 설정:
연구자들은 이미 잘 정리된 레시피 (좋은 코드) 와, 이름이 엉망이거나 설명이 없는 레시피 (나쁜 코드) 를 준비했습니다.
그리고 AI 요리사에게 **"이 레시피를 더 읽기 쉽게 고쳐줘"**라고 5 번 연속으로 시켰습니다. (처음엔 일반적인 지시, 나중엔 '이름을 잘 지어줘' 혹은 '설명문을 더 써줘'라고 구체적으로 지시하기도 했습니다.)
주요 발견 1: "초반엔 과감하게, 나중엔 안정적으로"
비유: AI 요리사가 처음 레시피를 받으면, "이건 너무 복잡하네!"라고 생각하며 재료를 다듬고, 양념을 바꾸고, 설명을 추가하거나 지우는 등 대대적인 리모델링을 합니다.
결과: 하지만 2~3 번 정도 고치면, 더 이상 큰 변화가 생기지 않고 일정한 형태에 도달합니다. 마치 "이 정도가 가장 깔끔한 상태구나"라고 AI 가 스스로 결론 내리는 것처럼요.
교훈: AI 는 처음엔 과하게 고치지만, 나중에는 안정화됩니다. 하지만 "이미 완벽한 레시피"를 줘도 AI 는 여전히 사소한 것들을 고치려 하므로, 언제 멈출지 정하는 기준이 필요합니다.
주요 발견 2: "다양한 시작점도 결국 하나로 모인다"
비유: 어떤 레시피는 "재료 이름이 'A', 'B', 'C'로 되어 있고 설명도 없는 상태"였다고 칩시다. 또 다른 레시피는 "설명만 다 지워진 상태"였습니다.
결과: AI 가 이 두 가지 엉망인 레시피를 각각 고쳐도, 마지막에 나온 결과물은 서로 매우 비슷해졌습니다. AI 는 "이게 진짜 맛있는 레시피의 표준 형태구나"라고 암기하고 있어서, 시작점이 달라도 결국 같은 방향으로 정리해버리는 것입니다.
교훈: AI 는 코드를 고칠 때 일관된 '스타일'을 가지고 있습니다.
주요 발견 3: "지시하는 말 (프롬프트) 에 따라 결과가 달라진다"
비유:
"이름을 잘 지어줘"라고 시켰을 때: AI 는 이름만 계속 바꾸다가 멈추지 않고 오르내리는 (oscillating) 현상을 보입니다. 마치 "이름을 '사과'로 할까, '과일'로 할까?" 하며 계속 고민하다가 다시 '사과'로 바꾸는 식입니다.
"설명문을 더 써줘"라고 시켰을 때: AI 는 처음에 설명문을 대폭 추가하지만, 그다음부터는 금방 안정됩니다. "이 정도면 충분하구나"라고 판단해서 더 이상 건드리지 않습니다.
교훈: AI 에게 무엇을 강조할지 정확히 말해주지 않으면, 원하는 방향으로 고쳐지지 않거나 계속 요동칠 수 있습니다.
💡 이 연구가 우리에게 주는 메시지
AI 는 훌륭한 '보정기'지만, '완벽한 해결사'는 아닙니다. AI 는 코드를 정리해서 일관된 스타일로 만들어주지만, 처음엔 너무 과하게 고치거나, 이미 좋은 코드를 고칠 때 불필요한 변화를 줄 수도 있습니다.
중요한 것은 '멈추는 타이밍'과 '명확한 지시'. AI 에게 코드를 맡길 때, "이름만 바꿔줘"라고 구체적으로 말해주거나, "이 정도면 충분해"라고 멈추게 하는 기준을 정해줘야 합니다. 특히 이름만 계속 바꾸는 악순환 (오실레이션) 을 막기 위해 주의가 필요합니다.
기능은 깨지지 않을까요? 연구진은 코드가 실행되는지 (기능이 깨지지 않는지) 도 확인했습니다. 결과는 거의 99% 이상 기능이 유지되었습니다. 하지만 아주 작은 실수가 발생할 수 있으므로, 사람이 최종 확인을 해주는 것이 좋습니다.
🚀 결론
이 논문은 **"AI 가 코드를 고칠 때, 처음엔 과감하게 리모델링하다가 나중엔 안정화된다"**는 사실을 증명했습니다. 하지만 AI 가 스스로 멈추지 않으므로, 사람이 적절히 지시하고 멈추게 하는 것이 가장 중요합니다.
마치 AI 가 훌륭한 건축 보조자인 셈입니다. 하지만 설계도를 너무 자주 고치게 하거나, "어디든 예쁘게 해줘"라고 막연히 말하면, 집이 계속 흔들릴 수 있으니 명확한 지시와 적절한 타이밍이 필요합니다.
1. 연구 배경 및 문제 정의 (Problem)
대규모 언어 모델 (LLM) 은 코드 생성 및 자동 리팩토링에 널리 사용되고 있지만, 그 결과물의 품질은 일관성이 부족하고 예측 불가능한 행동을 보일 수 있습니다. 특히, LLM 이 코드를 반복적으로 리팩토링할 때 어떤 패턴을 보이는지, 그리고 가독성 향상을 위해 반복적으로 프롬프트를 입력할 때 코드가 수렴 (convergence) 하는지 아니면 무의미한 변경이 계속되는지 (oscillation) 에 대한 체계적인 연구가 부족했습니다.
이 연구는 다음과 같은 핵심 질문을 던집니다:
LLM 이 이미 양호한 코드를 리팩토링할 때 불필요한 변경을 가하는가?
다양한 초기 상태 (가독성이 낮은 코드) 에서 시작하더라도 LLM 은 일관된 최종 형태로 수렴하는가?
특정 가독성 요소 (이름 지정, 주석 등) 를 강조하는 프롬프트가 리팩토링 동역학에 어떤 영향을 미치는가?
2. 연구 방법론 (Methodology)
저자들은 GPT-5.1 모델을 사용하여 대규모 실험을 수행했습니다.
데이터셋: GitHub 의 "The Algorithms – Java" 저장소에서 선별된 230 개의 Java 스니펫을 사용했습니다.
변형 (Variants): 각 원본 스니펫에 대해 두 가지 변형을 생성하여 총 3 가지 변형 (Original, Meaningless, NoComment) 을 만들었습니다.
Original: 원본 구현.
Meaningless: 식별자 (변수, 메서드, 클래스) 이름과 주석 내용을 무의미한 것으로 변경.
NoComment: 모든 주석을 제거.
실험 설계:
반복 횟수: 각 변형을 5 회 반복하여 리팩토링했습니다.
프롬프트 전략 (3 가지):
General (Unguided): "가독성을 위해 이 코드를 리팩토링하세요."
Meaning (Targeted): "식별자 명명 (identifier naming) 에 특히 초점을 맞춰 리팩토링하세요."
Comments (Targeted): "주석 (comments) 에 특히 초점을 맞춰 리팩토링하세요."
총 생성된 스니펫 수: 230 개 × 3 변형 × 3 프롬프트 × 5 반복 = 10,350 개.
분석 도구 (DiffParser):
시퀀스 기반, 토큰 기반, AST(추상 구문 트리) 기반 유사도 측정법을 통합한 커스텀 도구를 개발했습니다.
변경 사항을 구현 (Implementation), 구문 (Syntactic), 주석 (Comment) 수준으로 세분화하여 분류했습니다.
변경 유형: 리네임 (Rename), 구문만 변경 (SyntaxOnly), 주석 변경 (CommentChange), 혼합 변경 (MixedChange), 기능적 변경 (CodeChange) 등으로 분류했습니다.
3. 주요 연구 질문 (Research Questions)
RQ1 (반복적 리팩토링의 진화): 이미 모범 사례를 따르는 코드에 대해 LLM 이 어떻게 변화시키는가? (불필요한 변경 여부 및 수렴성)
RQ2 (코드 변형 간 수렴): 서로 다른 초기 상태 (의미 없는 이름, 주석 없음) 에서 시작하더라도 반복 리팩토링 후 유사한 형태로 수렴하는가?
RQ3 (명시적 프롬프트의 영향): 특정 가독성 요소를 강조하는 프롬프트가 리팩토링의 효과와 안정성에 미치는 영향은 무엇인가?
4. 주요 결과 (Key Results)
RQ1: 초기 재구조화 후 안정화 (Restructuring then Stabilization)
패턴: LLM 은 초기 반복 (v0→v1) 에서 상당한 재구조화 (이름 변경, 메서드 분해, 주석 제거 등) 를 수행하지만, 이후 반복에서는 변경 폭이 급격히 줄어들며 안정화 (Stabilization) 됩니다.
과도한 리팩토링: 입력 코드가 이미 양호하더라도 LLM 은 완벽한 유사도 (1.0) 에 도달하지 못하고 미세한 변경을 계속 가하며, 이는 '과도한 리팩토링 (over-refactoring)' 경향을 시사합니다.
주석 제거: 명시적 지시가 없어도 LLM 은 주석을 지속적으로 제거하는 경향을 보였습니다.
RQ2: 변형 간 수렴 (Convergence Across Variants)
강력한 수렴 현상: 의미 없는 이름이나 주석이 없는 코드 (Meaningless, NoComment) 로 시작하더라도, 반복 리팩토링을 거치면 Original 변형과 유사한 구조적 표현으로 수렴했습니다.
통계적 증거: 초기 변형 간 유사도 차이는 시간이 지남에 따라 줄어들어, 모든 변형이 최종적으로 유사한 유사도 점수 (약 0.87~0.90) 에 도달했습니다. 이는 LLM 이 내재된 '최적의 가독성' 개념을 가지고 있음을 시사합니다.
RQ3: 프롬프트 전략의 영향
이름 지정 프롬프트 (PromptMeaning): 식별자 이름을 강조할 경우, LLM 은 지속적인 오실레이션 (oscillation) 을 보였습니다. 즉, 이름을 계속 바꾸고 다시 바꾸는 행동을 멈추지 않아 수렴이 느리거나 불안정했습니다.
주석 프롬프트 (PromptComments): 주석을 강조할 경우, 초기 반복에서 주석이 추가되지만 이후에는 빠르게 안정화되었습니다.
통계적 유의성: 크루스칼 - 월리스 (Kruskal-Wallis) 검정 결과, 프롬프트 유형이 변경 유형 (리네임, 주석 변경) 에 통계적으로 유의미한 영향을 미치는 것으로 확인되었습니다.
기능적 정확성 및 견고성 (Robustness)
기능성 유지: 154 개의 스니펫에 대한 유닛 테스트 실행 결과, 리팩토링을 거치더라도 기능적 오류 (Functional Correctness) 는 1% 미만으로만 감소했습니다.
새로운 코드 견고성: LLM 의 학습 데이터에 포함되지 않은 2025 년 이후 생성된 새로운 Java 코드로 실험을 반복한 결과, 주요 경향성 (수렴, 초기 재구조화 등) 이 동일하게 나타났습니다.
5. 주요 기여 (Key Contributions)
실증적 증거: LLM 기반 리팩토링이 초기 재구조화 후 수렴하는 경향이 있음을 밝혔으며, 동시에 특정 프롬프트 하에서 역행 (back-and-forth) 변경이 발생할 수 있음을 증명했습니다.
프롬프트 엔지니어링 통찰: 명시적인 프롬프트가 리팩토링 경로를 어떻게 변화시키는지 (예: 이름 지정 프롬프트는 불안정성 유발) 를 규명하여 프롬프트 설계의 중요성을 강조했습니다.
재사용 가능한 프레임워크: 다양한 LLM 에 적용 가능한, 반복적 리팩토링 하의 코드 진화를 분석하는 LLM-중립적 프레임워크와 오픈 소스 리플리케이션 패키지를 제공했습니다.
정량적 메트릭: 코드 변경을 구현, 구문, 주석 수준으로 세분화하여 분석하는 정량적 메트릭을 도입했습니다.
6. 의의 및 결론 (Significance & Conclusion)
이 연구는 LLM 이 코드 리팩토링 도구로서 신뢰할 수 있는지에 대한 중요한 실증적 기반을 제공합니다.
실무적 시사점: 자동화된 리팩토링 도구를 사용할 때는 명시적인 정지 기준 (stopping criteria) 을 설정하여 과도한 리팩토링을 방지해야 합니다. 또한, 프롬프트를 작성할 때는 특정 요소 (예: 이름 변경) 를 지나치게 강조할 경우 불안정성을 초래할 수 있으므로 주의해야 합니다.
미래 연구 방향: LLM 의 수렴 동역학을 이해하기 위해 컨텍스트 유지 (stateful) 가 필요한지, 다양한 모델 간 비교 분석, 그리고 코드 냄새 (code smells) 나 복잡도 지표 등 추가적인 소프트웨어 품질 차원에 대한 체계적 평가가 필요합니다.
결론적으로, LLM 은 다양한 코드를 일관된 스타일로 정규화하는 강력한 능력을 가지고 있지만, 이를 효과적으로 활용하기 위해서는 인간의 감독과 신중한 프롬프트 설계가 필수적입니다.