LLM은 엔터프라이즈급 코드를 생성할 수 있는가?
📺 원본 영상: Can LLMs generate Enterprise Quality Code? — Prasenjit Sarkar, Sonar 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-06-01 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
코딩 에이전트가 개발 현장을 빠르게 재편하는 가운데, 이제 진짜 질문은 “LLM이 코드를 생성할 수 있느냐”가 아니라 “그 코드가 엔터프라이즈 환경에서 실제로 신뢰할 수 있느냐”이다. Sonar의 Prasenjit Sarkar는 AI Engineer 컨퍼런스에서 53개 이상의 LLM을 4,444개의 Java 프로그래밍 과제로 평가한 결과를 공개하며, 기능적 정확성 이면에 숨겨진 보안 취약점·코드 비대화·유지보수성 문제를 정량적으로 제시한다. 아울러 이 문제를 해결하기 위해 Sonar가 개발한 ACDC(Agent-Centric Development Cycle) 프레임워크도 함께 소개한다.
AI 코딩 에이전트의 시대 — 개발 패러다임의 전환
Andrej Karpathy는 강연 시점으로부터 약 두 달 전 “소프트웨어 개발 영역에서 많은 것이 바뀌었다”고 선언했다. 과거에는 개발자가 VS Code나 JetBrains 같은 IDE를 열고 직접 코드를 작성하는 방식이 표준이었지만, 이제는 에이전트에게 자연어로 지시를 내리고 결과물을 검토하는 방식으로 전환되고 있다는 것이다. 그 유명한 표현대로 “영어가 새로운 프로그래밍 언어”가 되어가고 있다.
도구의 진화 궤적도 이 흐름을 뒷받침한다. VS Code, JetBrains 같은 전통 IDE에서 Cursor, Windsurf 같은 AI 우선 편집기를 거쳐, 이제는 OpenAI Codex, Claude Code, Devin, Gemini CLI처럼 완전히 에이전트 기반으로 동작하는 코딩 플랫폼으로 이동하고 있다. 이 변화의 속도는 수치로도 확인된다. The Pragmatic Engineer가 2026년 3월에 실시한 설문에 따르면, 개발자의 55%가 이미 AI 에이전트를 정기적으로 활용하고 있다고 응답했다.
그러나 Sarkar는 바로 이 지점에서 핵심 질문을 던진다. “당신은 LLM이 생성한 그 코드를 신뢰합니까?” 에이전트가 작성한 코드를 결국 인간이 검토해야 한다면, 유지보수성과 보안과 가독성이 얼마나 보장되어 있는지가 생산성과 직결된다. 이 물음에 답하는 것이 이번 강연의 핵심 목적이다.
기존 벤치마크가 놓치고 있는 것
현재 LLM 업계는 코드 생성 능력을 주로 HumanEval, MBPP(Mostly Basic Programming Problems), SWE-bench 같은 벤치마크로 평가한다. 각 모델 회사들은 “패스율 80% 이상”을 경쟁적으로 발표하며 82%, 83%, 84% 등의 수치를 내세운다. Sarkar는 이 수치들이 거짓이 아니라고 인정하면서도, 이것이 기능적 정확성(Functional Correctness), 즉 테스트 케이스 통과 여부만을 측정한다는 점을 강조한다. 말하자면 “코드가 실행되느냐”만 묻고, “그 코드와 함께 살아갈 수 있느냐”는 묻지 않는 셈이다.
그 결과 아래와 같은 차원들이 평가에서 체계적으로 누락된다.
- 보안 측면(Security Aspects): 생성된 코드에 취약점이 포함되어 있는지
- 실세계 신뢰성(Real-World Reliability): 실제 운영 환경에서 안정적으로 동작하는지
- 엔지니어링 설계 원칙(Engineering Architecture): 적절한 추상화, 모듈화, 의존성 관리가 이루어지는지
- 유지보수성과 기술 부채(Maintainability & Tech Debt): 시간이 지남에 따라 관리 가능한 코드인지
- 컨텍스트 인식(Context-Aware Analysis): 기업의 코드베이스와 아키텍처를 고려한 코드인지
이 갭이 바로 Sonar가 독자적인 평가 프레임워크를 구축한 이유다. 패스율 숫자만 보고 LLM을 선택하는 것은 마치 연비만 보고 자동차를 구매하는 것과 같다. 실제 주행 환경에서의 내구성, 안전성, 유지보수 비용은 전혀 다른 이야기일 수 있다.
💡 [영상 참조] 강연자는 이 시점에서 슬라이드를 통해 기존 벤치마크가 측정하는 항목과 누락된 항목을 시각적으로 대비하여 설명합니다. 📺 원본 영상에서 확인하세요.
Sonar의 평가 방법론
Sonar는 공개된 오픈소스 데이터셋에서 4,444개 이상의 Java 프로그래밍 과제를 선별하고, 이를 각 LLM에게 풀도록 했다. 생성된 코드는 SonarQube Enterprise로 분석되었으며, 단순한 테스트 통과 여부를 넘어 코드 품질의 다양한 차원을 정량적으로 측정했다. 현재 이 평가 결과는 sonar.com/leaderboard에 공개되어 있으며, 53개 이상의 모델과 다양한 버전별 데이터를 누구나 확인할 수 있다.
07:25 - sonar.com/leaderboard 화면 — 53개 이상 모델 평가 결과, Gemini 3.1 Pro High 최고 패스율 표시
측정 지표는 기능적 패스율(SWE-bench 기준), 생성된 총 코드 라인 수(Lines of Code), 순환 복잡도(Cyclomatic Complexity), 인지 복잡도(Cognitive Complexity), 백만 라인당 버그 수, 백만 라인당 보안 취약점 수를 포함한다. 이 중 두 가지 복잡도 지표의 차이를 이해하는 것이 중요하다. 순환 복잡도는 코드 내 분기의 수, 즉 if/else, for/while 반복문 등 제어 흐름 경로의 개수를 세는 전통적인 지표다. 반면 **인지 복잡도(Cognitive Complexity)**는 Sonar가 독자적으로 개발한 지표로, 인간이 코드를 읽고 이해하고 유지보수하기 얼마나 어려운지를 측정한다. 구조적으로 단순해 보이는 코드도 인지 복잡도가 높을 수 있으며, 이것이 실무에서의 유지보수 비용과 더 직접적으로 연결된다.
모델별 코드 품질 비교 분석
03:49 - 5개 주요 LLM 비교 테이블/차트 — 패스율, 총 LoC, 순환 복잡도, 버그 밀도, 보안 취약점 밀도
강연에서 공개된 주요 모델별 데이터를 정리하면 다음과 같다.
| 모델 | 패스율 (SWE-bench) | 총 LoC (4,444개 과제 기준) | 순환 복잡도 | 버그 (건/백만 LoC) | 보안 취약점 (건/백만 LoC) |
|---|---|---|---|---|---|
| Gemini 3.1 Pro High (thinking) | 84.17% | 307,000 | 234 | 614 | 210 |
| Claude Sonnet 4.6 | 미언급 | 627,000 | 미언급 | 미언급 | 300 (최고) |
| GPT-5.2 High | 미언급 | ~1,000,000 | 미언급 | 미언급 | 미언급 |
| GPT-5.4 / GPT-5.4 Pro High | 미언급 | 1,200,000 | 미언급 | 미언급 | 미언급 |
| GPT-4o | 미언급 | <250,000 | 미언급 | 미언급 | 미언급 |
“미언급” 항목은 강연 음성에서 구체적으로 언급되지 않아 확인 불가. 상세 데이터는 sonar.com/leaderboard 참조.
04:14 - Gemini 3.1 Pro High 세부 지표 — 순환 복잡도 234, 버그 614건/백만 LoC, 보안 취약점 210건/백만 LoC
이 데이터에서 가장 눈에 띄는 첫 번째 패턴은 모델 성능 향상과 코드 비대화(Code Bloat)의 동반 심화다. GPT-4o가 4,444개 과제를 25만 줄 미만으로 해결한 반면, 더 최신 모델인 GPT-5.2 High는 약 100만 줄, GPT-5.4 계열은 무려 120만 줄을 생성했다. Gemini 3.1 Pro High는 상대적으로 간결한 30만 7천 줄을 기록했지만, Claude Sonnet 4.6은 62만 7천 줄에 달했다. 같은 문제를 더 많은 코드로 푼다는 것은 그만큼 불필요한 중복, 과도한 추상화, 잠재적 버그 노출 면적이 넓어진다는 의미다. 고성능 모델이 “영리하게 간결하게” 쓰기보다 오히려 “장황하게 많이” 쓰는 경향이 나타나고 있다는 점은 주목할 만하다.
05:09 - GPT-5.4 / GPT-5.4 Pro High의 120만 줄 코드 생성 — 코드 비대화의 극단 사례
09:18 - 모델 세대별 LoC 증가 추세 — GPT-4o < 250K 대비 GPT-5.2 High ~1M 비교
두 번째로 중요한 패턴은 기능적 정확성 순위와 보안 안전성 순위의 불일치다. 이번 평가에서 Claude Sonnet 4.6이 백만 라인당 300건의 보안 취약점으로 가장 높은 위험 수준을 기록한 반면, 가장 높은 기능적 패스율(84.17%)을 보인 Gemini 3.1 Pro High는 보안 취약점 밀도가 210건으로 상대적으로 낮았다. 이는 “벤치마크에서 가장 잘 푸는 모델”이 반드시 “가장 안전한 코드를 생성하는 모델”은 아님을 정량적으로 보여준다. 모델 선택 시 용도에 따라 어떤 지표를 우선시할지 판단이 필요하다.
세 번째 통찰은 버그 질의 변화다. Sarkar는 전체 모델들을 시계열로 분석했을 때, 총 취약점 수는 감소하는 추세지만 남아있는 버그들이 점점 더 미묘하고 탐지하기 어려운 유형으로 바뀌고 있다고 지적한다. 강화학습(Reinforcement Learning)을 통해 이미 알려진 패턴의 문제들은 빠르게 개선되고 있지만, 그 과정에서 인간이 발견하기 어려운 새로운 논리적 오류들이 생겨나고 있다는 것이다. 이는 단순한 패턴 기반 정적 분석만으로는 AI 생성 코드를 완전히 검증하기 어려워지고 있다는 것을 시사한다.
LLM 코드 품질 저하의 근본 원인
이러한 품질 문제가 발생하는 이유에 대해 Sarkar는 네 가지 구조적 원인을 제시한다. 이를 이해하는 것은 단순히 “어떤 모델이 더 낫냐”를 넘어서, 왜 어떤 구조적 개선이 필요한지를 파악하는 데 필수적이다.
첫째, **혼합 품질의 학습 데이터(Mixed Quality Training Data)**다. 오픈소스와 여러 출처에서 수집한 학습 데이터에는 고품질 코드와 저품질 코드가 혼재되어 있다. 모델은 “좋은 코드”뿐 아니라 “나쁜 코드”의 패턴도 학습하게 되며, 이것이 출력 품질의 일관성을 떨어뜨린다. 특정 프로그래밍 패턴이 데이터셋에 얼마나 많이 등장하느냐가 그 패턴이 올바른지와 무관하게 생성 확률에 영향을 미친다.
둘째, **학습 데이터에 내재된 보안 결함(Built-in Security Flaws)**이다. 학습에 사용된 코드베이스 자체에 이미 보안 취약점이 포함되어 있었고, 모델은 이 불안전한 코드 예시를 안전한 예시와 함께 학습하게 된다. 결과적으로 모델은 보안 취약점이 포함된 코드 패턴을 “정상적인 코딩 방식”으로 학습할 위험이 있으며, 이는 생성 코드에 구조적으로 재현된다.
셋째, **데이터 내 숨겨진 버그(Hidden Bugs in Data)**다. 표면적으로는 기능적으로 올바르게 보이지만 특정 조건에서 오동작하는 논리적 오류가 학습 풀에 포함되면, 모델은 그 미묘한 오류 패턴까지 학습하게 된다. 이런 종류의 버그는 표준 테스트 케이스에서는 통과하지만 프로덕션 환경의 엣지 케이스에서 실패하기 때문에 발견이 특히 어렵다.
넷째, **LLM의 본질적 확률성(Probabilistic Nature)**이다. LLM은 확률적 모델이기 때문에, 동일한 프롬프트를 오늘과 내일 전달해도 다른 코드를 생성한다. 또한 기업 고유의 코드베이스, 아키텍처 컨벤션, 비즈니스 로직을 이해하지 못하며, 생성된 결과물이 왜 그런 방식으로 만들어졌는지 추적하기 어렵다(Not Explainable). 이는 문제가 발생했을 때 진단과 개선을 어렵게 만드는 근본적인 제약이다.
ACDC 프레임워크 — Sonar의 해결 전략
이 문제들에 대응하기 위해 Sonar는 ACDC(Agent-Centric Development Cycle) 프레임워크를 제안한다. 강연자는 이 이름이 “재미있다”고 본인도 인정했다. ACDC는 **Guide(안내) → Verify(검증) → Solve(해결)**의 세 단계로 구성되며, 이너 루프(Inner Loop)와 아우터 루프(Outer Loop)를 통해 코드가 저장소에 병합되기 전 여러 겹의 품질 게이트를 통과하도록 설계되었다.
10:53 - ACDC(Agent-Centric Development Cycle) 프레임워크 다이어그램 — Guide / Verify / Solve 3단계 이너·아우터 루프 구조
Guide 단계 — 좋은 코드의 출발점을 높이다
Guide 단계의 목표는 LLM이 코드를 생성하기 시작하기 전에 입력 품질과 컨텍스트를 개선하는 것이다. 여기에는 두 가지 도구가 투입된다. Sonar Sweep은 현재 프라이빗 베타 상태로, LLM 학습에 사용될 데이터 자체를 전처리하는 역할을 담당한다. 학습 데이터에 문제가 있으면 생성되는 코드도 문제가 있을 수밖에 없다는, 문제의 근원을 직접 다루는 역방향 접근이다. Sonar Context Augmentation은 기업의 전체 코드베이스를 LLM의 컨텍스트에 주입함으로써, 에이전트가 회사의 코딩 컨벤션, 기존 아키텍처, 코드 패턴을 인식하며 코드를 생성하도록 돕는다. 이는 LLM의 “컨텍스트 무지” 문제를 직접적으로 보완하는 접근이다.
Verify 단계 — 커밋 전 실시간 정적 분석
Verify 단계는 SonarQube의 에이전트 중심 분석 기능으로 구현되며, 현재 오픈 베타로 누구나 참여할 수 있다. 핵심 아이디어는 CI/CD 파이프라인이 실행되기 훨씬 전, 개발자가 코드를 커밋하기 전 단계에서 분석을 완료하는 것이다. 일반적인 CI 실행에는 1~5분이 소요되는 반면, 이 단계의 분석은 1~5초 내에 완료된다. 이 속도 차이가 워크플로우를 본질적으로 바꾼다.
12:04 - Verify 단계 SonarQube 에이전트 중심 분석 흐름 — MCP 연동, 커밋 전 1~5초 분석 루프 설명
작동 방식은 다음과 같다. Claude Code, Codex, Gemini CLI 등 MCP(Model Context Protocol)를 지원하는 에이전트 플랫폼에서 코드를 생성한 후, 커밋 전에 분석 명령을 실행한다. 분석 결과는 에이전트에게 다시 전달되고, 에이전트는 발견된 문제를 즉시 수정하여 재분석 결과가 통과할 때까지 이 루프를 반복한다. 개발자가 PR을 열기도 전에 기본 품질 기준을 통과한 코드만 커밋되는 구조가 만들어지는 것이다.
Solve 단계 — 기술 부채의 자동 해소
Verify 단계를 통과하지 못하고 PR까지 올라온 이슈, 또는 이미 코드베이스에 누적된 기술 부채를 처리하는 것이 Solve 단계다. SonarQube Remediation Agent가 이를 담당하며, 현재 오픈 베타로 제공 중이다. 개발자는 SonarQube 대시보드에서 처리하고 싶은 이슈들을 선택하고 “에이전트에 할당”하면, 에이전트가 이슈별로 별도의 PR을 생성하여 수정 사항을 제시한다.
특히 주목할 부분은 이 에이전트의 자체 검증 루프다. Remediation Agent는 수정 코드를 생성한 후 다시 정적 분석과 컴파일을 실행하여, 수정 사항이 회귀(Regression)를 유발하지 않는지 스스로 검증한다. 만약 수정이 새로운 문제를 발생시킨다고 판단되면 해당 수정을 폐기하고 개발자에게 제출하지 않는다. Sarkar의 표현대로 “회귀를 만들어내는 코드는 제공하지 않는다”는 원칙이 설계에 내재된 것이다. 개발자는 에이전트가 검증 완료한 수정 사항만 검토하면 되므로, 불완전한 AI 생성 코드를 직접 디버깅해야 하는 인지 부담이 크게 줄어든다.
마무리 / 핵심 정리
Sarkar의 발표에서 얻을 수 있는 핵심 메시지는 명확하다. LLM이 생성하는 코드는 벤치마크가 보여주는 것보다 훨씬 복잡한 품질 문제를 안고 있으며, “패스율 80%“라는 숫자는 엔터프라이즈 환경에서의 신뢰성을 보장하지 않는다. 특히 최신 고성능 모델일수록 더 많은 코드를 생성하는 비대화 현상이 심화되고 있고, 보안 취약점의 양상도 탐지하기 더 어려운 방향으로 진화하고 있다는 점은 단순히 “더 좋은 모델로 업그레이드”하는 것으로 해결되지 않는다는 것을 시사한다.
Sonar의 접근 방식은 이 문제를 “LLM을 믿지 말자”는 방향이 아니라, “LLM을 구조적으로 검증하고 보완하는 시스템을 구축하자”는 방향으로 해결하려 한다. 에이전트 시대에도 개발자가 코드를 검토해야 하는 현실은 당분간 변하지 않겠지만, 그 검토 부담을 줄이기 위해 정적 분석과 자동화된 수정 루프를 결합한 것이 ACDC 프레임워크의 본질이다.
53개 이상의 모델을 동일한 기준으로 평가한 Sonar의 리더보드 데이터는 모델 선택의 근거로도 유용하다. 기능적 정확성뿐 아니라 보안, 유지보수성, 코드 크기까지 종합적으로 고려해야 하며, 자신의 아키텍처와 보안 요구 수준에 맞는 모델을 선택하는 것이 중요하다. 이 데이터는 sonar.com/leaderboard에서 직접 비교해볼 수 있다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Can LLMs generate Enterprise Quality Code? — Prasenjit Sarkar, Sonar |
| 채널 | AI Engineer |
| 강연자 | Prasenjit Sarkar (Sonar) |
| 리포트 작성 | 2026-06-01 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.