Sonar 보고서로 보는 주요 LLM의 코딩 성향과 숨은 리스크

AI 코딩 도구는 이제 개발 현장에서 빠르게 확산되고 있습니다. GitHub Copilot, Cursor, Claude Code와 같은 도구는 개발자가 더 빠르게 코드를 작성하고, 반복적인 작업을 줄이며, 복잡한 문제 해결을 지원하는 데 활용되고 있습니다.

SonarSource가 발표한 The Coding Personalities of Leading LLMs 보고서는 중요한 시사점을 제공합니다. 
이 보고서는 주요 LLM이 생성한 코드를 분석해, 각 모델이 단순히 문제를 얼마나 잘 푸는지를 넘어 실제 엔터프라이즈 개발 환경에서 얼마나 안전하고 유지보수 가능한 코드를 생성하는지 살펴봅니다.

핵심 메시지는 명확합니다.
AI 코딩 모델은 기능적으로 동작하는 코드를 빠르게 만들어낼 수 있지만, 그 코드가 반드시 안전하고 유지보수하기 쉬운 좋은 코드라는 의미는 아닙니다.

Sonar는 어떻게 LLM 생성 코드를 평가했을까?

Sonar는 기존의 성능 벤치마크를 넘어, LLM이 생성한 코드를 평가하기 위한 자체 분석 프레임워크를 개발했습니다. 이 분석에는 SonarQube Enterprise의 정적 분석 엔진이 활용되었습니다.
SonarQube Enterprise는 엔터프라이즈급 소프트웨어에서 복잡한 버그, 보안 취약점, 코드 스멜을 탐지해 온 경험을 바탕으로 코드 품질을 분석합니다.

이번 보고서에서는 두 가지 유형의 모델을 평가했습니다.
첫 번째는 Anthropic의 Claude Sonnet 4 및 Claude 3.7 Sonnet, OpenAI의 GPT-4o, Meta의 Llama 3.2 90B, 오픈소스 모델인 OpenCoder-8B 등 5개의 비추론형(non-reasoning) LLM입니다.
두 번째는 새로운 추론형(reasoning) 모델인 GPT-5입니다.

직접적인 비교를 위해 GPT-5는 다른 비추론형 모델들과 유사하게 비교할 수 있는 minimal reasoning mode에서 평가되었습니다.
각 모델은 MultiPL-E-mbpp-java, MultiPL-E-humaneval-java, ComplexCodeEval 등에서 가져온 4,442개 이상의 Java 프로그래밍 과제를 수행했습니다.

이 분석의 목적은 단순히 “어떤 모델이 가장 성능이 좋은가”를 보여주는 것이 아닙니다. 각 모델이 어떤 방식으로 코드를 작성하고, 어떤 유형의 리스크를 만들어내며, 실제 개발 조직에서 어떻게 활용되어야 하는지에 대한 보다 현실적인 기준을 제시하는 데 있습니다.

공통 강점: LLM은 코드를 잘 만든다

LLM이 개발 현장에서 빠르게 활용되는 이유는 분명합니다. 대부분의 모델은 문법적으로 유효한 코드를 생성하고, 알고리즘 문제를 해결하며, 추상적인 로직을 다양한 프로그래밍 언어 환경에 맞게 변환하는 데 강점을 보입니다.

• HumanEval, MBPP, Weighted test Pass@1 평균을 모델별로 비교한 표
• Claude Sonnet 4와 GPT-5-minimal은 높은 기능 통과율을 보였지만, 이 수치만으로 코드 품질 전체를 판단하기는 어렵습니다.

예를 들어 HumanEval 기준으로 Claude Sonnet 4는 95.57%, GPT-5-minimal은 약 92%의 성공률을 기록했습니다. 이는 두 모델이 실행 가능한 코드를 생성하는 데 높은 역량을 가지고 있음을 보여줍니다.
또한 “Weighted test Pass@1” 기준에서도 Claude Sonnet 4는 77.04%, GPT-5-minimal은 75.37%를 기록했습니다. 즉, 주요 LLM들은 단순한 문법 생성기를 넘어 실제 문제 해결 능력을 갖춘 코딩 도구로 볼 수 있습니다.

하지만 이 지점에서 중요한 질문이 남습니다. 기능 테스트를 통과한 코드는 정말 좋은 코드일까요?

공통 약점 1: 보안 의식의 부족

보고서에 따르면 모든 모델은 보안 측면에서 공통적인 약점을 보였습니다. 특히 비추론형 모델들은 ‘BLOCKER’ 심각도에 해당하는 취약점을 높은 비율로 생성하는 경향이 있었습니다.

GPT-5-minimal은 다른 모델에 비해 취약점 밀도가 3~6배 낮은 코드를 생성했습니다. 그러나 이것이 곧 “안전한 코드”를 의미하지는 않습니다. 
GPT-5-minimal은 일반적이고 잘 알려진 취약점을 줄이는 대신, 더 미묘하고 구현 방식에 특화된 취약점을 만들어내는 경향을 보였습니다.

예를 들어 GPT-5-minimal은 여전히 “Path-traversal & Injection(경로 탐색 및 인젝션)” 취약점을 20% 수준으로 생성했으며, 다른 모델보다 “Inadequate I/O error-handling(부적절한 I/O 오류처리)” 관련 취약점 비율이 높게 나타났습니다.

이는 LLM의 보안 문제가 단순히 가끔 발생하는 환각의 문제가 아니라, 모델의 학습 방식과 구조적 한계에서 비롯될 수 있음을 보여줍니다.
인젝션 취약점을 방지하려면 신뢰할 수 없는 입력 지점에서 민감한 처리 지점까지 데이터 흐름을 추적하는 taint-tracking이 필요합니다. 이는 일반적인 LLM의 문맥 처리 범위를 넘어서는 비국소적 데이터 흐름 분석에 가깝습니다.

공통 약점 2: 엔지니어링 원칙 적용의 어려움

보안 취약점 외에도 LLM은 소프트웨어 엔지니어링 원칙이 필요한 영역에서 한계를 보였습니다.
예를 들어 리소스 누수, 예외 처리 미흡, API 계약 위반, 타입 안정성 문제, 동시성/스레딩 문제 등이 발생할 수 있습니다. 이러한 문제는 단순히 테스트를 통과하는지만으로는 충분히 확인하기 어렵습니다.

특히 추론형 모델은 흥미로운 트레이드오프를 보입니다. GPT-5처럼 더 높은 추론 능력을 가진 모델은 “Control-flow mistakes”와 같은 기본적인 논리 오류를 줄일 수 있습니다.
하지만 모델이 더 복잡한 해결책을 시도하면서 “Concurrency / Threading” 버그와 같은 고급 결함은 오히려 증가할 수 있습니다.

즉, 더 뛰어난 모델이 항상 더 안전한 코드를 만든다고 단정하기는 어렵습니다. 리스크가 줄어드는 것이 아니라, 더 복잡하고 발견하기 어려운 형태로 이동할 수 있기 때문입니다.

• 제어 흐름 오류, API 계약 위반, 예외 처리, 리소스 누수, 동시성/스레딩 문제 등 버그 유형 비교
• LLM은 기능 구현에는 강점을 보이지만, 실제 운영 코드에서 중요한 엔지니어링 품질을 일관되게 보장하지는 못합니다

공통 약점 3: 코드 스멜과 기술부채

보고서에서 가장 주목할 부분 중 하나는 LLM이 생성한 이슈 중 대부분이 코드 스멜이라는 점입니다.
코드 스멜은 당장 프로그램 실행을 막는 오류는 아닙니다. 하지만 코드 구조가 복잡하거나, 중복이 많거나, 불필요한 코드가 포함되어 있거나, 유지보수하기 어려운 형태로 작성되었다는 신호입니다.

• 모델별 버그, 취약점, 코드 스멜 비중
• 모든 모델에서 코드 스멜이 전체 이슈의 대부분을 차지했습니다.

보고서에 따르면 모든 모델에서 코드 스멜은 전체 이슈의 대부분을 차지했습니다. 특히 GPT-5 계열은 다른 모델보다 ‘CRITICAL’ 등급의 코드 스멜 비중이 높게 나타났습니다. 이는 높은 기능 성능에 따르는 비용, 즉 심각한 기술부채의 증가로 볼 수 있습니다.
아래표는 유지보수성 측면의 상충 관계를 가장 직접적으로 보여주는 근거입니다. AI를 활용하면 초기 개발 속도는 빨라질 수 있습니다. 하지만 코드 스멜이 누적되면 이후 코드 리뷰, 기능 추가, 버그 수정, 신규 개발자 온보딩, 리팩토링에 더 많은 시간이 필요해집니다.
결국 AI로 얻은 초기 생산성 향상이 장기적인 유지보수 비용으로 상쇄될 수 있습니다.

• 사용되지 않는 코드, 설계/프레임워크 모범 사례 위반, 복잡도, 네이밍/문서화 등 코드 스멜 유형 비교
• 코드 스멜도 단일 문제가 아니라, 모델별로 서로 다른 방식으로 나타납니다.

LLM마다 다른 “코딩 성향”이 있다

그렇다면 모든 LLM이 공통적인 강점과 약점을 가진다면, 왜 실제 개발 환경에서 각 모델이 작성한 코드는 서로 다르게 느껴질까요?
Sonar 보고서는 각 LLM이 고유하고 측정 가능한 “코딩 성향”을 가지고 있다고 설명합니다. 이러한 성향은 단순한 인상이 아니라, 생성된 코드의 구조적 지표를 통해 정량적으로 확인할 수 있습니다.

• X축: 기능 성능
• Y축: 인지 복잡도
• 버블 크기: 코드량

보고서는 모델의 코딩 스타일을 세 가지 주요 특성으로 분류했습니다.

첫째, 장황성(Verbosity)입니다. 이는 주어진 작업을 해결하기 위해 모델이 생성하는 코드의 전체 분량을 의미합니다.
둘째, 복잡도(Complexity)입니다. 생성된 코드의 구조적·논리적 복잡성을 의미하며, 순환 복잡도와 인지 복잡도 같은 지표로 측정됩니다.
셋째, 커뮤니케이션 및 문서화(Communication and documentation)입니다. 코드 내 주석의 밀도를 통해 모델이 자신의 작업을 얼마나 설명하려는 경향이 있는지를 보여줍니다.

예를 들어 GPT-5-minimal은 490,010 LOC를 생성하며 매우 장황한 성향을 보였습니다. 반면 OpenCoder-8B는 동일한 문제를 해결하기 위해 120,288 LOC만 생성했습니다. 이는 단순히 코드 길이의 차이가 아니라, 문제 해결 방식의 차이를 보여줍니다.
GPT-5-minimal은 인지 복잡도에서도 111,133을 기록하며 가장 복잡한 솔루션을 생성했습니다. 이는 OpenCoder-8B의 13,965보다 12배 이상 높은 수치입니다.
문서화 성향에서도 차이가 나타났습니다. Claude 3.7 Sonnet은 16.4%의 높은 주석 밀도를 보였지만, GPT-5-minimal은 2.1%에 그쳤습니다. 이는 모델마다 협업과 유지보수성에 영향을 줄 수 있는 서로 다른 커뮤니케이션 스타일을 가지고 있음을 의미합니다.

• 모델별 LOC, 주석 비율, 순환 복잡도, 인지 복잡도 비교
• LLM마다 단순히 성능 차이만 있는 것이 아니라, 코드 작성 방식 자체가 다르게 나타납니다.

주요 LLM의 코딩 아키타입

Sonar 보고서는 각 모델의 코딩 성향을 바탕으로 여섯 가지 아키타입을 정의했습니다.

기준 성능형 [GPT-5-minimal]

이는 GPT-5의 기본적인 추론 모드에 해당합니다. 대부분의 비추론형 모델보다 우수한 강력한 성능을 제공합니다. 

이 모델의 성향은 더 고도화된 모델들과 비교했을 때 상대적으로 “전통적인” 리스크 프로필을 가진다는 점으로 정의할 수 있습니다. 

예를 들어 “경로 탐색 및 인젝션(Path-traversal & Injection)” 취약점이 상당한 비율인 20%로 나타나며, “제어 흐름 오류(Control-flow mistake)”와 같은 기본적인 버그도 생성합니다.

동시에 높은 장황성과 복잡도로 인해 새로운 유형의 리스크도 만들어냅니다. 그 결과, 평가된 모든 모델 중 ‘CRITICAL’ 등급 코드 스멜의 비중이 가장 높게 나타났습니다.

시니어 아키텍트형 [Claude Sonnet 4]

이 LLM은 엔터프라이즈급 시스템 구축을 맡은 숙련되고 야심 있는 아키텍트처럼 코드를 작성합니다. 벤치마크 테스트의 77.04%를 통과하며 가장 높은 기능 역량을 보였습니다.

이 모델의 스타일은 장황하고 매우 복잡합니다. 정교한 안전장치, 오류 처리, 고급 기능을 지속적으로 구현하려고 하며, 이는 시니어 엔지니어의 행동 방식과 유사합니다.

하지만 바로 이 정교함이 함정이 될 수 있습니다. 코드는 고급스럽고 안전해 보일 수 있지만, 실제로는 리소스 누수와 같은 더 복잡하고 심각도 높은 버그를 만들어낼 가능성이 있습니다.

모델의 정교함은 복잡하고 상태를 관리하는 시스템에서 자주 발생하는 고위험 버그가 생길 여지를 많이 만듭니다. 이 모델의 고유한 버그 프로필을 보면, 동시성 및 스레딩 버그가 전체 버그의 9.81%로 비교적 높게 나타났고, 리소스 관리 누수도 전체 버그의 15.07%를 차지했습니다.

즉, 이 모델의 강점인 정교한 코드 생성 능력이 동시에 약점과 연결되어 있습니다.

균형 잡힌 이전 세대형 [Claude 3.7 Sonnet]

이 모델은 이전 세대의 유능하고 균형 잡힌 개발자에 가깝습니다. 벤치마크 통과율 72.46%로 강력한 기능 역량을 보입니다.

이 모델을 가장 잘 정의하는 성향은 커뮤니케이션 방식입니다. Claude 3.7 Sonnet은 뛰어난 문서화 성향을 보이며, 16.4%라는 높은 주석 밀도의 코드를 생성했습니다.

이는 후속 모델보다 거의 세 배 높고, 평가된 모든 모델 중 가장 높은 수치입니다. 덕분에 이 모델이 작성한 코드는 사람이 읽고 이해하기에 상대적으로 쉽습니다.

하지만 균형 잡힌 이전 세대형에도 한계는 있습니다. 더 야심적인 후속 모델보다 안정적이고 덜 무모해 보일 수는 있지만, 결코 “안전한” 모델이라고 보기는 어렵습니다.

여전히 높은 비율의 ‘BLOCKER’ 취약점, 즉 56.03%를 생성하며, 다른 모델들과 동일한 근본적 결함을 가지고 있습니다.

효율적인 범용형 [GPT-4o]

이 LLM은 신뢰할 수 있는 중간 지점의 개발자에 가깝습니다. “시니어 아키텍트형”만큼 장황하지도 않고, “빠른 프로토타입형”만큼 간결하지도 않습니다. 여러 작업에 두루 활용할 수 있는 범용형 모델이며, 일반적인 코딩 지원 용도로 자주 선택될 수 있는 유형입니다.

이 모델의 코드는 적당한 수준의 복잡도를 가지며, 기능 성능도 안정적입니다.

다만 이 모델의 독특한 성향은 실수의 유형에서 드러납니다. 일반적으로 가장 심각한 ‘BLOCKER’ 또는 ‘CRITICAL’ 버그는 비교적 잘 피하는 편이지만, 논리적 정밀성에서는 눈에 띄는 부주의함을 보입니다.

이를 잘 보여주는 것이 가장 흔한 버그 유형입니다. GPT-4o의 전체 버그 중 “제어 흐름 오류(Control-flow mistakes)”가 48.15%를 차지합니다.

이는 전체 목표는 올바르게 파악하지만, 코드를 견고하게 만들기 위해 필요한 세부 사항에서 자주 실수하는 개발자의 모습과 유사합니다.

의도한 시나리오에서는 코드가 동작할 가능성이 높지만, 시간이 지날수록 품질과 신뢰성을 저해하는 지속적인 문제가 나타날 수 있습니다.

기대에 못 미친 잠재형 [Llama 3.2 90B]

모델의 규모와 배경을 고려하면, 이 모델은 최상위권 경쟁자가 되어야 할 것처럼 보입니다. 하지만 이번 분석에서 나타난 성능은 그 잠재력이 충분히 실현되지 않았음을 보여줍니다.

기능 역량은 보통 수준으로, 벤치마크 통과율은 61.47%였습니다. 이는 테스트한 훨씬 작은 오픈소스 모델보다 약간 나은 수준에 그쳤습니다.

그러나 이 모델에서 가장 우려되는 특징은 매우 취약한 보안 상태입니다. Llama 3.2 90B는 심각한 보안 사각지대를 보였으며, 생성한 취약점 중 70.73%가 ‘BLOCKER’ 심각도에 해당했습니다. 이는 평가된 모든 모델 중 가장 높은 비율입니다.

이러한 보안 프로필은 강력한 외부 검증 체계 없이 이 모델을 운영 환경에 배포할 경우 상당한 리스크가 따를 수 있음을 시사합니다.

빠른 프로토타입형 [OpenCoder-8B]

이 LLM은 뛰어나지만 규율이 부족한 주니어 개발자에 가깝습니다. 최대한 빠르게 아이디어를 구현하는 데 적합한 모델입니다.

이 모델의 스타일은 간결함으로 정의됩니다. 기능적 결과를 만들기 위해 가장 적은 양의 코드인 120,288 LOC를 생성했습니다. 따라서 첫 결과물을 빠르게 얻는 것이 가장 중요한 해커톤, 개념 검증, 빠른 프로토타이핑에 적합한 선택지가 될 수 있습니다.

하지만 즉각적인 생산성 향상은 분명한 반면, 그 대가로 가장 높은 이슈 밀도를 보입니다. 이는 프로젝트 안에 기술부채를 쌓아 장기적인 생산성과 유지보수성을 저해할 수 있습니다.

이 모델은 사실상 기술부채 생성기에 가깝습니다. 평가된 모든 모델 중 가장 높은 이슈 밀도인 KLOC당 32.45개의 이슈를 보였습니다. 가장 두드러지는 성향상 결함은 죽은 코드, 사용되지 않는 코드, 중복 코드 등을 남기는 경향입니다. 이러한 항목은 전체 코드 스멜의 42.74%를 차지했습니다.

이는 정리와 정제 과정 없이 급하게 반복 개발을 진행했을 때 나타나는 전형적인 신호입니다. 프로토타입에는 적합할 수 있지만, 운영 환경에 적용하려면 시니어 개발자의 상당한 리팩토링 노력이나 강력한 거버넌스 도구를 통한 검증이 필요합니다.

왜 “더 뛰어난” 모델이 더 위험할 수 있을까?

이번 보고서의 가장 흥미로운 발견 중 하나는 모델 업그레이드가 실제 환경에서의 리스크 증가를 가릴 수 있다는 점입니다.
최신 모델은 기능 성능이 향상될 수 있습니다. 하지만 그 과정에서 리스크의 양상이 일반적이고 잘 알려진 결함에서, 더 미묘하고 발견하기 어려운 구현상의 문제로 이동할 수 있습니다.

예를 들어 Claude Sonnet 4는 Claude 3.7 Sonnet보다 성능 벤치마크에서 개선을 보였지만, 생성하는 버그와 보안 취약점은 BLOCKER 심각도에 해당할 가능성이 더 높았습니다.
GPT-5는 더 복잡한 트레이드오프를 보여줍니다. GPT-5는 대부분의 비교 모델보다 기능적으로 정확하고, BLOCKER 취약점 비중을 크게 낮췄습니다. 그러나 동시에 동시성/스레딩 버그와 같은 더 복잡한 유형의 리스크를 높은 비율로 생성했습니다.

즉, 더 뛰어난 모델은 단순한 실수를 줄일 수 있지만, 그 대신 더 복잡하고 발견하기 어려운 문제를 만들어낼 수 있습니다.

• Claude 3.7 Sonnet, Claude Sonnet 4, GPT-5-minimal 비교
• 벤치마크 통과율, BLOCKER 취약점 비중, 동시성/스레딩 버그 비중 비교
• 모델 업그레이드는 기능 성능 향상과 동시에 새로운 유형의 리스크를 동반할 수 있습니다.

마무리

AI 코딩 시대의 핵심 전략: Trust, but Verify

AI 코딩 도구는 개발 생산성을 높이는 강력한 수단입니다. 하지만 AI가 생성한 코드를 그대로 신뢰하는 것은 위험할 수 있습니다.
코드를 개발자가 작성했든 LLM이 작성했든, “신뢰하되 검증하라(Trust, but Verify)”는 접근 방식은 그 어느 때보다 중요해졌습니다. 특히 새로운 세대의 모델에서는 검증이 더욱 엄격해야 합니다.
개발자는 겉으로 보기에는 더 깔끔해 보이는 코드가 주는 잘못된 안도감에 빠져서는 안 됩니다. 그 아래에는 동시성 버그, 보안 취약점, 심각한 기술부채와 같은 구조적 문제가 숨어 있을 수 있기 때문입니다.

SonarQube는 이러한 검증 체계를 구축하는 데 중요한 역할을 할 수 있습니다. 개발자가 직접 작성한 코드뿐만 아니라 AI가 생성한 코드 역시 동일한 품질 기준으로 분석하고, 보안·신뢰성·유지보수성 측면에서 문제를 조기에 발견할 수 있도록 지원합니다.
AI 코딩 도구 사용이 확대될수록 조직에는 다음과 같은 체계가 필요합니다.

• AI 생성 코드에 대한 일관된 품질 기준
• 보안 취약점과 버그의 조기 탐지
• 코드 스멜과 복잡도 기반의 기술부채 관리
• 품질 게이트를 통한 배포 전 검증
• 개발자 워크플로우 안에서의 지속적인 코드 품질 피드백

출처:

https://www.sonarsource.com/the-coding-personalities-of-leading-llms/

The Coding Personalities of Leading LLMs Report  by SonarSource