성능 사각지대: AI 에이전트는 느린 코드를 작성합니다

코드는 모든 테스트를 통과했습니다. 린터도 깨끗했습니다. 타입 체커도 만족했습니다. 코드 리뷰도 승인되었습니다. 그런데 그 함수는 필요한 것보다 446배 느렸습니다.¹

코드 성능 최적화 도구인 Codeflash가 Claude Code로 완전히 생성된 두 건의 풀 리퀘스트를 분석했습니다: Java 언어 지원 모듈과 React 프레임워크 통합에 걸쳐 76,000줄의 코드였습니다.¹ 심각한 성능 문제가 있는 118개의 함수를 발견했습니다. 성능 저하는 3배에서 446배까지 다양했습니다. 가장 심각한 사례는 타입 추출 함수로, 순회 결과를 캐싱하는 대신 매번 호출할 때마다 전체 AST를 다시 스캔하고 있었습니다. 동작은 정확했지만, 성능은 치명적이었습니다.

이 발견은 이상치가 아닙니다. NumPy, Pandas, SciPy와 같은 저장소에서 498개의 최적화 작업을 벤치마킹한 SWE-fficiency에 따르면, 최고 성능의 LLM 에이전트가 동일한 작업에서 전문 개발자가 달성한 속도 향상의 0.15배에도 미치지 못했습니다.² Claude 3.5, OpenAI o1, Llama 3.2를 26개의 고성능 컴퓨팅 코드로 테스트한 별도의 연구에서는, Claude 3.5가 직렬 최적화에서 1.02배 속도 향상(사실상 개선 없음)을 달성했으며, 30%의 경우에서 잘못된 코드를 생성한 것으로 나타났습니다.³ Codeflash의 자체 분석에서는 100,000개의 오픈소스 함수를 대상으로 했을 때, AI가 제안한 최적화의 90%가 부정확하거나 측정 가능한 이점을 제공하지 못했으며, 올바른 최적화 중에서도 73%는 5% 미만의 성능 향상에 그쳤습니다.⁴

성능은 AI 코딩 도구가 보지 못하는 차원입니다. 모든 표준 품질 게이트(린터, 타입 체커, 테스트 스위트, 코드 리뷰)는 정확성을 검증합니다. 효율성을 검증하는 것은 없습니다. 그 결과: AI가 생성한 모든 코드 줄에 보이지 않는 세금이 붙어, 모든 검사를 통과하면서도 그것이 투입되는 모든 시스템의 성능을 저하시킵니다.

요약

AI 에이전트는 정확하지만 느린 코드를 작성합니다. Codeflash는 Claude Code 출력물 76,000줄에서 3배부터 446배까지의 성능 저하를 보이는 118개의 성능 문제를 발견했습니다.¹ 학술 벤치마크도 이 패턴을 확인합니다: LLM는 최적화 작업에서 전문가 속도 향상의 0.15배에도 미치지 못합니다.² 원인은 구조적입니다: 학습 데이터가 정확성에 보상을 주고, 표준 품질 게이트는 성능을 측정하지 않습니다. 이를 돌파하려면 성능 인프라가 필요합니다: 유닛 테스트와 함께하는 벤치마크, 훅에서의 AST 기반 패턴 탐지, 그리고 표준 워크플로우 단계로서의 프로파일링이 그것입니다.

핵심 요점

개별 개발자를 위해. 핫 패스에 있는 모든 AI 생성 함수에 대해 검증 단계에서 time 또는 프로파일러를 추가하세요. 446배 성능 저하는 모든 테스트와 모든 린터를 통과했습니다. 그것을 잡을 수 있는 유일한 게이트는 벤치마크뿐이었습니다. “작동한다”를 필요조건이지 충분조건은 아닌 것으로 취급하세요. “얼마나 빨리 작동하는가?”를 표준 후속 질문으로 삼으세요.

팀 리드를 위해. 성능 회귀는 적당히 괜찮은 수준의 안주의 보이지 않는 형태입니다. 모든 기능 테스트를 통과하는 AI 생성 코드는 거짓된 완결감을 만들어냅니다. 유닛 테스트와 함께 CI에 성능 벤치마크를 추가하세요. Faros AI 데이터에 따르면 AI 지원 팀은 21% 더 많은 작업을 완료하면서 개발자당 9% 더 많은 버그를 생성합니다.⁵ 성능 버그는 아무도 측정하지 않기 때문에 그 9%에 포함되지 않습니다.

플랫폼 엔지니어를 위해. 누락된 게이트를 구축하세요. 린터는 스타일을 검사합니다. 타입 체커는 계약을 검사합니다. 테스트 스위트는 동작을 검사합니다. 표준 CI 파이프라인에서 알고리즘 복잡도나 런타임 특성을 검사하는 것은 아무것도 없습니다. AST 기반 패턴 탐지(Semgrep 규칙, ast-grep 패턴, 또는 커스텀 훅)로 가장 흔한 성능 안티패턴인 중복 순회, 누락된 메모이제이션, 불필요한 복사를 잡을 수 있습니다.

118개의 버그는 어떤 모습인가

Codeflash의 두 건의 Claude Code PR 분석은 AI 생성 성능 문제에 대한 가장 세분화된 공개 데이터셋을 제공합니다.¹ 두 건의 PR은 총 76,000줄이었습니다: Java 언어 지원 52,000줄, React 프레임워크 지원 24,000줄. 둘 다 기능적으로 동작했습니다. 둘 다 테스트 스위트를 통과했습니다. 둘 다 실제 부하에서 성능이 저하될 코드를 포함하고 있었습니다.

근본 원인은 네 가지 범주로 분류됩니다:

비효율적 알고리즘. 가장 지배적인 범주입니다. 바이트 오프셋을 줄 위치로 변환하는 함수가 사전 계산된 조회 테이블을 이용한 O(log n) 이진 탐색 대신 O(n) 스캔을 사용하고 있었습니다. 코드는 가독성이 좋았습니다. 변수명은 설명적이었습니다. 로직은 정확했습니다. 복잡도 클래스가 잘못되었습니다.

중복 계산. 캐싱할 수 있는 값을 다시 파싱하고, 다시 순회하고, 다시 계산하는 함수들입니다. 헬퍼 함수 파인더는 매번 호출할 때마다 동일한 소스 파일을 다시 파싱했습니다. 메모이제이션 데코레이터 하나면 첫 번째 호출 이후 74배의 오버헤드를 0으로 줄일 수 있었을 것입니다.

캐싱과 메모이제이션 누락. 중복 계산과 밀접하게 관련되어 있지만, 데이터가 더 넓은 범위에서 사용 가능했다는 점에서 구별됩니다. 타입 정의 추출기는 첫 번째 접근 시 인덱스를 구축하는 대신 매번 전체 AST를 순회했습니다. 패턴은 이렇습니다: 에이전트가 각 함수를 루프에서 어떻게 호출될지 고려하지 않고 개별적으로 작성합니다.

부적절한 데이터 구조. 집합이나 딕셔너리가 O(1) 조회를 제공할 수 있는 곳에서의 리스트 스캔. 익스포트 체커는 멤버십을 테스트하기 위해 리스트를 순회했습니다. 집합으로 변환하면 9배의 오버헤드를 완전히 제거할 수 있었습니다.

에이전트가 느린 코드를 생성하는 이유

성능 사각지대는 특정 모델의 버그가 아닙니다. 원인은 구조적이며, 학습 데이터, 평가 기준, 워크플로우 가정이라는 세 가지 수준에서 작용합니다.

학습 데이터가 가독성에 보상을 줍니다

LLM는 학습 데이터에 있는 코드의 분포로부터 학습합니다. 모든 알고리즘의 가장 흔한 구현은 나이브한 구현입니다. 튜토리얼 코드는 명확성을 우선시합니다. Stack Overflow 답변은 정확성을 우선시합니다. 오픈소스 코드에는 성능 최적화된 버전이 포함되어 있지만, 직관적인 구현에 비해 수 배나 적은 수입니다.

이 패턴은 성능을 넘어 확장됩니다. 스탠퍼드 연구에 따르면 AI 지원 개발자는 5개의 보안 작업 중 4개에서 더 자주 보안에 취약한 코드를 작성했으며, 같은 개발자들이 자신의 코드가 안전하다고 믿을 가능성이 더 높았습니다.⁸ 이 확신의 격차는 성능에도 동일하게 적용됩니다: 코드가 깔끔해 보이고, 잘 읽히고, 올바른 결과를 생성하기 때문에 개발자가 신뢰하게 됩니다. SWE-fficiency 연구자들은 에이전트가 최적화 기회를 파악하고 함수 간 실행을 추론하는 데 어려움을 겪는다는 것을 발견했습니다.² LLM는 알고리즘 개선보다는 작고 입력에 특화된 편집을 수행합니다. 최적화를 요청하면, 모델은 알고리즘적 접근 방식을 재고하기보다 가장 가까운 올바른 변환(캐시 추가, 함수 인라인)에 손을 뻗습니다. 결과적으로 근본적으로 비효율적인 구조 위에 마이크로 최적화가 겹겹이 쌓이게 됩니다.

성능을 측정하는 평가 게이트가 없습니다

표준 품질 게이트는 설계된 대로 검증합니다:

업계가 표준화한 모든 게이트는 정확성에 초점을 맞추고 있습니다. 성능 테스팅은 존재합니다(프로파일러, 벤치마킹 프레임워크, 부하 테스트 도구). 하지만 대부분의 팀이 CI 파이프라인에 통합하지 않는 별도의 워크플로우에 머물러 있으며, AI 에이전트가 자발적으로 호출하는 일은 없습니다.

10% 생산성 벽을 설명하는 검증 공백은 기능적 정확성보다 더 깊이 확장됩니다. 공백은 “코드가 작동하는가?”뿐 아니라 “코드가 성능을 내는가?”이며, 어떤 표준 게이트도 두 번째 질문을 하지 않습니다.

에이전트는 함수를 작성하지, 시스템을 작성하지 않습니다

가장 근본적인 원인은 아키텍처적입니다. AI 에이전트는 한 번에 하나의 함수, 하나의 파일, 하나의 작업을 생성합니다. 각 생성의 범위는 즉각적인 요구사항입니다. 성능 문제는 경계에서 발생합니다: 단일 호출용으로 작성된 함수가 루프에서 호출될 때, 작은 입력용으로 작성된 파서가 큰 파일을 받을 때, 정확성을 위해 작성된 조회가 모든 요청마다 실행될 때입니다.

에이전트 실패 분류법의 터널 비전 실패 모드는 기능 수준에서 이 패턴을 설명합니다: 에이전트가 통합 지점을 확인하지 않고 하나의 컴포넌트를 완벽하게 만듭니다. 성능 사각지대는 런타임 특성에 적용된 터널 비전입니다. 함수는 독립적으로는 완벽합니다. 시스템이 저하되는 이유는 함수의 성능 특성이 맥락 속에서 평가된 적이 없기 때문입니다.

보이지 않는 세금

AI 생성 코드가 프로덕션 시스템의 작은 부분에 불과하다면 성능 사각지대는 사소한 문제일 것입니다. 현재 수치는 이를 시스템적 위험으로 만듭니다.

DX는 AI 작성 코드가 병합된 프로덕션 코드의 26.9%를 차지하며 계속 증가하고 있다고 측정합니다.⁶ DevOps 분석 벤더인 Faros AI는 AI 지원 팀이 AI 이전 기준 대비 154% 더 큰 PR을 병합하고, 21% 더 많은 작업을 완료하며, 개발자당 9% 더 많은 버그를 생성한다는 것을 발견했습니다.⁵ 9%라는 수치는 기능적 결함을 계산한 것입니다. 성능 회귀는 대부분의 팀이 회귀를 판단할 성능 기준선 자체가 없기 때문에 이 지표에서 완전히 빠져 있습니다.

복리 효과가 중요합니다. METR의 무작위 대조 시험에서 경험 많은 개발자들이 AI 도구를 사용했을 때 19% 더 오래 걸렸지만, AI가 20% 빠르게 해준다고 믿었습니다.⁹ 개발자 자신이 영향을 정확하게 평가할 수 없다면, 성능 부채는 감지되지 않은 채 축적됩니다. 병합된 코드의 26.9%가 잠재적 성능 부채를 안고 있고 조직에 성능 게이트가 없다면, 부채는 매 스프린트마다 복리로 쌓입니다. DORA 2025 보고서에 따르면 AI 도입은 처리량이 개선되었음에도 불구하고 딜리버리 불안정성 증가와 상관관계가 있었습니다.⁷ 보고서는 불안정성을 성능에 구체적으로 귀인하지는 않지만, 그 메커니즘은 부합합니다: 더 많은 코드가, 더 빠르게 병합되고, 성능 특성은 한 번도 측정되지 않았습니다.

Codeflash가 설문한 엔지니어링 리더의 52%가 AI 사용 증가가 코드베이스의 성능 문제로 이어진다고 보고했습니다.⁴ 이 수치는 자가 보고이며 벤더(Codeflash는 성능 최적화 도구를 판매)로부터 나온 것이지만, 방향성은 모든 독립 데이터셋과 일치합니다. 표준 품질 게이트로 병합되는 더 많은 AI 생성 코드는 올바르게 작동하면서 느리게 실행되는 시스템을 만들어냅니다.

10% 생산성 벽에는 원래 데이터가 드러내지 못하는 성능 차원이 있습니다. AI가 코드 생성을 10% 가속하지만 생성된 코드가 수 주 또는 수개월 후 프로덕션 인시던트로 표면화되는 성능 부채를 안고 있다면, 순 생산성 이득은 더욱 줄어듭니다. 벽은 단지 “AI가 개발자를 더 빠르게 만들지 못한다”가 아닙니다. 벽에는 “AI가 아무도 측정하지 않는 방식으로 코드를 느리게 만든다”도 포함됩니다.

탐지는 어떤 모습인가

AI 생성 코드에 대한 성능 탐지에는 대부분의 조직이 갖추지 못한 인프라가 필요합니다. 도구는 존재합니다. 통합이 되어 있지 않을 뿐입니다.

CI에서의 벤치마크 게이트

가장 직접적인 해결책: 핵심 경로를 벤치마킹하고 회귀 발생 시 빌드를 실패시키는 것입니다. 모든 주요 언어에 프레임워크가 존재합니다: Python용 pytest-benchmark, Java용 JMH, Rust용 criterion, JavaScript용 benchmark.js. 문제는 도구가 아니라 관행입니다. 벤치마크에는 기준선이 필요하고, 기준선에는 AI 생성 코드가 회귀를 일으키기 전에 누군가가 초기 벤치마크를 작성해야 합니다.

최소 실행 가능한 구현: 핫 패스에 있는 10-20개의 함수를 식별하고, 그것들에 대한 벤치마크를 작성한 후, CI에 추가합니다. Codeflash가 발견한 118개의 버그는 파서와 AST 순회 함수, 즉 글루 코드가 아닌 계산 핵심부에 집중되어 있었습니다. 성능 문제는 매번 같은 곳에 집중됩니다.

AST 기반 패턴 탐지

정적 분석은 코드를 실행하지 않고도 가장 심각한 패턴을 잡을 수 있습니다. Semgrep과 ast-grep은 다음을 탐지하는 커스텀 규칙을 지원합니다:

• 내부 컬렉션이 변하지 않는 다른 루프 안의 리스트 컴프리헨션이나 루프 (캐시 후보)
• 집합이 될 수 있는 리스트에 대한 .index() 또는 in 검사
• 배칭 없이 루프 안에서의 파일 I/O 또는 네트워크 호출
• 동일한 인수로 반복되는 함수 호출 (메모이제이션 후보)

이 규칙들은 프로파일링을 대체하지 않습니다. 118개 버그의 대다수를 차지하는 패턴인 중복 계산, 캐싱 누락, 잘못된 데이터 구조를 잡아냅니다.

훅 기반 성능 인식

Claude Code 사용자의 경우, PreToolUse 훅이 에이전트의 워크플로우에 성능 인식을 주입할 수 있습니다. 이 접근 방식은 정확성을 위해 사용되는 에비던스 게이트 패턴과 유사합니다:

check_performance_patterns() {
    local file_path="$1"
    local ext="${file_path##*.}"

    case "$ext" in
        py)
            # Detect nested loops with repeated computation
            if grep -Pn 'for .+ in .+:\n.*for .+ in .+:' "$file_path" 2>/dev/null; then
                echo "WARNING: Nested loops detected in $file_path"
                echo "Verify inner loop does not recompute invariant values."
            fi
            # Detect list membership checks that should be sets
            if grep -n '\bin\b.*\[' "$file_path" 2>/dev/null | grep -v '#'; then
                echo "WARNING: List membership check in $file_path"
                echo "Consider converting to a set for O(1) lookup."
            fi
            ;;
        js|ts)
            # Detect Array.includes or indexOf in loops
            if grep -n '\.includes\|\.indexOf' "$file_path" 2>/dev/null; then
                echo "NOTE: Array search detected in $file_path"
                echo "If called in a loop, consider a Set or Map."
            fi
            ;;
    esac
}

이 훅은 프로파일러가 아닙니다. 인식을 높이는 것입니다. 목표는 다른 모든 품질 게이트와 동일합니다: 보이지 않는 것을 보이게 만들어서 개발자(또는 이후 반복에서의 에이전트)가 코드를 배포하기 전에 해결할 수 있도록 하는 것입니다.

누락된 인프라

모든 데이터 포인트에 걸친 패턴은 10% 생산성 벽과 7가지 실패 모드를 설명하는 것과 동일합니다: AI는 존재하는 인프라를 증폭시키며, 인프라의 부재도 함께 증폭시킵니다.

CI에 성능 벤치마크가 있는 조직은 인간이 생성한 성능 회귀를 잡는 것과 같은 방식으로 AI 생성 성능 회귀를 잡을 것입니다. 없는 조직은 성능 부채를 보이지 않게 축적할 것입니다. DORA의 “증폭기” 발견이 직접적으로 적용됩니다: AI가 성능 사각지대를 만드는 것이 아닙니다. AI가 그것을 확대시킵니다.⁷

세 가지 최소한의 투자로 이 격차를 해소할 수 있습니다:

1. AI가 코드를 생성하기 전에 핵심 경로를 벤치마킹하세요. 벤치마크가 기준선입니다. 이것 없이는 어떤 회귀도 감지할 수 없습니다. 대부분의 계산 시간을 차지하는 10-20개의 함수를 식별하고 그것들에 대한 벤치마크를 먼저 작성하세요.

2. CI 파이프라인에 AST 기반 성능 린팅을 추가하세요. 네 가지 주요 안티패턴(중복 계산, 캐싱 누락, 잘못된 데이터 구조, 불필요한 복잡도)을 플래그하는 Semgrep 또는 ast-grep 규칙. 이 규칙들은 가볍고 기존 린팅 단계와 조합 가능합니다.

3. 에이전트 워크플로우에 성능 인식을 주입하세요. Claude Code의 경우: 수정된 파일에서 성능 관련 패턴을 플래그하는 훅. 다른 도구의 경우: “알고리즘 복잡도를 검증하라”를 표준 지침에 포함하는 프롬프트. 목표는 자동화된 최적화가 아니라 인식입니다: 현재 묻지 않는 워크플로우에서 “이것이 충분히 빠른가?”라는 질문을 표면화하는 것입니다.

사각지대는 AI가 아닙니다. 사각지대는 성능 인프라의 부재입니다. 업계가 구축한 모든 표준 품질 게이트는 정확성을 검증합니다. 효율성을 검증하는 것은 없습니다. 이 격차는 AI 이전에 존재했습니다. AI가 이를 프로덕션 코드의 26.9% 문제로 만들었습니다.

출처