Do AI Models Dream of Faster Code? An Empirical Study on LLM-Proposed Performance Improvements in Real-World Software
이 논문은 알고리즘 퍼즐이 아닌 실제 Java 프로젝트의 성능 민감 코드를 대상으로 한 실증 연구를 통해, 대규모 언어 모델 (LLM) 이 인간 개발자보다 평균적으로 낮은 성능 개선을 보이며 과도한 변동성을 가진다는 사실을 규명하고, 이를 해결하기 위해 정적 코드 생성을 넘어 런타임 프로파일링이 가능한 에이전트 기반 시스템의 필요성을 강조합니다.
상상해 보세요. 거대한 레스토랑 (실제 소프트웨어 프로젝트) 이 있습니다. 여기에는 **미슐랭 셰프 (경험 많은 인간 개발자)**가 있고, 이제 막 영입된 **천재 요리 견습생 (AI 모델)**이 있습니다.
연구자들은 이 견습생에게 "이 요리를 더 빨리, 더 맛있게 만들어줘"라고 시켰습니다. 결과는 어땠을까요?
1. 실험 내용: "요리 실력 테스트"
연구진은 **65 가지의 실제 요리 레시피 (Java 코드)**를 준비했습니다. 이 레시피들은 이미 미슐랭 셰프가 "이걸 이렇게 고치니 요리 속도가 10 배 빨라졌다!"라고 증명해 둔 것들입니다. 그리고 AI 모델들에게 이 레시피를 고쳐달라고 시켰습니다.
단순한 퀴즈가 아님: 학교 시험지 같은 간단한 문제 (알고리즘 퀴즈) 가 아니라, 실제 레스토랑에서 매일 돌아가는 복잡한 요리 과정이었습니다.
정확한 측정: 단순히 "맛있어 보인다"가 아니라, **스톱워치 (JMH 벤치마크)**로 정확히 몇 초가 걸리는지 측정했습니다.
2. 주요 발견: "재능은 있지만, 예측 불가능하다"
① AI 는 가끔 천재가 되지만, 대체로 셰프보다 느립니다.
AI 는 대부분의 경우 요리를 더 빠르게 만들었습니다. 하지만 미슐랭 셰프가 만든 최적의 속도에는 미치지 못했습니다.
놀라운 점: 가끔은 AI 가 셰프가 생각지 못한 새로운 비법 (예: 재료를 손질하는 순서를 바꾸는 것) 을 찾아내어, 셰프보다 훨씬 더 빠르게 요리를 만들기도 했습니다.
무서운 점: 반대로, AI 가 요리를 더 느리게 만들거나 (성능 저하), 아예 망쳐버리는 경우도 꽤 많았습니다. 마치 "더 빨리 하려고 칼을 더 많이 휘둘러서 손가락을 다친" 상황과 비슷합니다.
② "무엇을 고쳐야 하는지" 알려주지 않으면 AI 는 헤매요.
AI 에게 "이 요리를 빨리 해"라고만 말하면 (지시 없이), AI 는 대충 고쳐서 별 효과가 없거나 오히려 느려진 경우가 많았습니다.
하지만 "이 부분이 너무 느려서 병목 현상이야"라고 구체적으로 알려주면, AI 는 그 부분을 집중적으로 고쳐서 꽤 좋은 결과를 냅니다.
비유: AI 는 훌륭한 '손'을 가졌지만, '눈' (어디가 문제인지 파악하는 능력) 이 약합니다. 어디가 문제인지 알려주면 그 부분을 아주 잘 고치지만, 스스로 찾아내기는 어렵습니다.
③ AI 는 복잡한 레시피를 좋아합니다.
인간 셰프는 요리를 빠르게 하려면 불을 줄이거나 (구조 단순화) 재료를 줄이는 등 간단하고 깔끔한 해결책을 찾습니다.
반면 AI 는 "이걸 더 빠르게 하려면 이 함수를 3 개 만들고, 조건문을 5 개 추가하고..."라며 너무 복잡하고 지저분한 코드를 만들어내는 경향이 있습니다. 결과적으로 코드는 느려지고 유지보수도 힘들어집니다.
3. 결론: AI 는 '도구'일 뿐, '주인'이 될 수 없습니다
이 연구는 현재 AI 평가 기준이 너무 낙관적이라고 경고합니다. 학교 시험 (간단한 퀴즈) 에서 100 점 맞은 AI 가, 실제 레스토랑 (복잡한 현실) 에서도 미슐랭 스타일 요리사를 대체할 수는 없습니다.
이 연구가 우리에게 주는 교훈:
AI 는 '조력자'입니다: AI 가 스스로 문제를 찾아서 해결하게 하기보다, 인간이 "여기가 문제야"라고 알려주고 AI 가 그걸 구현하게 하는 것이 가장 좋습니다.
새로운 접근이 필요합니다: 앞으로는 AI 가 코드를 짤 때, 단순히 코드를 보는 것을 넘어 실제 실행 속도를 측정하고 (프로파일링), 데이터를 분석하는 '스마트 에이전트' 시스템이 필요하다는 것입니다. 마치 요리 견습생에게 스톱워치와 온도계를 직접 쥐여주어 스스로 상황을 판단하게 하는 것과 같습니다.
📝 한 줄 요약
"AI 는 가끔 천재적인 아이디어를 내지만, 대체로 인간 전문가보다 느리고 불안정합니다. AI 가 스스로 '어디가 느린지' 찾아내는 능력은 부족하니, 인간이 방향을 잡아주고 AI 가 그걸 실행하게 하는 '팀워크'가 가장 중요합니다."
1. 연구 배경 및 문제 제기 (Problem)
현황: 대규모 언어 모델 (LLM) 은 코드 생성, 리팩토링, 테스트 생성 등 소프트웨어 공학 전반에 걸쳐 널리 사용되고 있습니다. 그러나 생성된 코드의 성능 효율성 (Performance Efficiency) 에 대한 우려가 존재합니다.
기존 연구의 한계: 기존 LLM 성능 평가 벤치마크 (HumanEval, CoderEval 등) 는 주로 작고 격리된 알고리즘 문제 (알고리즘 퀴즈) 에 초점을 맞추고 있습니다. 이는 실제 산업 환경의 복잡성 (동시성 모델, 메모리 할당, 대규모 코드베이스 간의 의존성 등) 을 반영하지 못합니다.
핵심 질문: LLM 이 복잡한 알고리즘 문제뿐만 아니라, 실제 프로덕션 환경의 성능 민감도 (Performance-sensitive) 코드를 최적화할 수 있는가? 그리고 그 성능은 인간 개발자의 개선안과 비교하여 어떤 수준인가?
2. 연구 방법론 (Methodology)
저자들은 실제 Java 오픈소스 프로젝트에서 채취한 고품질 데이터셋을 기반으로 한 실증 연구를 수행했습니다.
데이터셋 (PerfOpt):
소스: Apache Kafka, Netty, Presto, RoaringBitmap 등 4 개의 성능 민감도 Java 오픈소스 프로젝트.
구성: 개발자가 실제로 성능 문제를 해결한 커밋 65 건을 수집. 각 커밋에는 원본 코드, 개발자 개선 코드, JMH (Java Microbenchmark Harness) 기반의 성능 벤치마크, 단위 테스트, 문제 설명이 포함됨.
선정 기준: 통계적으로 유의미한 성능 향상 (Wilcoxon signed-rank test, p<0.05) 이 확인된 경우만 포함.
실험 설정:
모델: 상업적 모델 (OpenAI o4-mini, Gemini 2.5 Pro) 과 오픈 가중치/추론 모델 (DeepSeek-V3, DeepSeek-R1) 총 4 종 평가.
프롬프트 전략: 4 가지 조건으로 실험.
No Hint: 코드만 제공.
Benchmark: 코드 + JMH 벤치마크 코드 제공.
Problem: 코드 + 성능 문제 설명 제공.
Both: 코드 + 벤치마크 + 문제 설명 모두 제공.
자동화 파이프라인: 생성된 패치가 컴파일 및 단위 테스트를 통과하는지 확인 (Plausibility) 후, JMH 를 통해 실제 성능 측정. 실패 시 자동 수정 루프 (Error-Guided Repair) 적용.
평가 지표:
Patch Performance Score (pss): 개선된 코드의 성능 점수와 원본 코드의 점수 비율. (1.0 이상은 개선, 1.0 미만은 저하).
통계적 분석: Wilcoxon 부호 순위 검정 및 Vargha-Delaney A^12 효과 크기 분석.
전략 분류: 개발자 솔루션과의 유사도에 따라 '전략 일치 (Match)', '전략 정렬 (Alignment)', '전략 이탈 (Divergence)'로 분류.
3. 주요 결과 (Key Results)
RQ1: LLM 은 실제 소프트웨어 성능을 얼마나 효과적으로 최적화하는가?
전반적 성과: LLM 은 대부분 경우 성능을 개선할 수 있었으나, 인간 개발자가 제안한 개선안에는 평균적으로 미치지 못함.
변동성 (Volatility): 성능 개선 폭이 극도로 불안정함. 일부 태스크에서는 인간을 능가하는 획기적인 최적화를 발견하기도 했으나, 다른 태스크에서는 성능이 급격히 저하 (Regression) 되기도 함.
프롬프트의 영향:
문제 설명 (Problem Description) 의 중요성: 성능 문제의 맥락 (문제 설명) 을 명시적으로 제공하는 것이 성능 개선의 가장 큰 동인이었음.
벤치마크 코드의 한계: 벤치마크 코드만 제공하는 것은 문제 설명만큼 효과적이지 않았음.
모델별 차이: Gemini 2.5 Pro 가 전반적으로 가장 높은 성능을 보였으며, DeepSeek-R1 은 초기 성공률은 높았으나 자동 수정 루프에서의 회복력은 Gemini 보다 낮았음.
통계적 유의성: 인간 개발자의 솔루션이 모든 설정에서 LLM 보다 우세함 (대부분의 경우 중간~큰 효과 크기).
RQ2: LLM 이 제안하는 최적화 전략은 인간과 유사한가?
코드 복잡도: LLM 이 생성한 패치는 인간 개발자의 패치보다 더 국소화 (Localized) 되어 있지만, 순환 복잡도 (Cyclomatic Complexity) 는 더 높은 경향이 있음. 즉, 구조적 단순화보다는 복잡한 로직 추가를 통해 최적화를 시도함.
전략 분류 결과:
전략 일치 (Match): LLM 이 인간과 동일한 로직을 구현한 경우. 성능 개선폭이 가장 큼 (중앙값 2.27 배).
전략 정렬 (Alignment): 동일한 병목 지점을 찾았으나 다른 알고리즘을 사용한 경우. 개선폭이 중간 (중앙값 1.11 배).
전략 이탈 (Divergence): 잘못된 지점을 최적화하거나 관련 없는 코드를 변경한 경우. 성능 개선이 거의 없거나 오히려 저하됨 (중앙값 1.01 배).
통찰: LLM 은 문제 설명을 제공받으면 '전략 이탈'은 줄어들지만, 인간이 찾은 '최적의 해결책 (Match)'을 정확히 복제하지는 못하고 '타당한 하지만 최적은 아닌 해결책 (Alignment)'을 제시하는 경향이 강함.
4. 주요 기여 (Key Contributions)
PerfOpt 데이터셋 구축: 실제 오픈소스 프로젝트에서 채취한 65 개의 성능 최적화 태스크와 JMH 벤치마크를 포함한 최초의 대규모 실증 데이터셋 제공.
현실적 평가 프레임워크: 알고리즘 퀴즈가 아닌, 실제 프로덕션 코드와 개발자 작성 벤치마크를 활용한 엄격한 성능 평가 방법론 제시.
LLM 성능 평가의 재정의: 기존 알고리즘 벤치마크 기반의 LLM 성능 평가가 실제 성능 최적화 능력을 과도하게 낙관적으로 평가하고 있음을 입증.
한계점 규명: LLM 이 성능 병목 지점을 자율적으로 식별 (Profiling) 하는 능력과, 최적의 알고리즘적 개선을 합성 (Synthesize) 하는 능력에서 인간에 비해 열위임을 확인.
5. 의의 및 시사점 (Significance)
실무 적용: 현재 LLM 은 성능 최적화 분야에서 자율적인 엔지니어라기보다는 고변동성 (High-variance) 탐색 도구로 보는 것이 타당함. LLM 의 최적 역할은 인간 개발자가 병목 지점과 방향을 진단하면, LLM 이 구현을 제안하는 협업형 가속기 (Collaborative Accelerator) 입니다.
미래 방향: 정적 코드 생성을 넘어, 런타임 프로파일링 (Profiling) 및 벤치마킹 도구를 통합한 에이전트 기반 시스템 (Agent-based Systems) 개발이 필요함. LLM 이 실행 시 행동을 관찰하고 피드백을 받아 최적화할 수 있는 구조가 요구됩니다.
에너지 효율성: 소프트웨어 성능 향상은 에너지 소비 감소와 직결되므로, LLM 을 통한 효율적인 성능 최적화 연구의 중요성이 부각됩니다.
결론
이 연구는 LLM 이 복잡한 실제 소프트웨어의 성능을 개선할 수 있는 잠재력을 보여주지만, 현재 기술 수준에서는 인간 개발자의 직관과 진단 능력에 비해 불안정하고 종종 미흡함을 밝힙니다. 따라서 LLM 을 성능 최적화에 효과적으로 활용하기 위해서는 단순한 코드 생성을 넘어, 런타임 정보를 활용한 에이전트 시스템으로의 진화와 더 현실적인 벤치마크의 확장이 필수적입니다.