SemiAnalysis Weekly · 팟캐스트 Ep. 14MUST ASSET — 유튜브 매거진

LLM이 컴파일러 버그를 찾는다 — 단 며칠, 단 $1,000

퍼징도 코드 리딩도 이제 AI가 한다. Nvidia·AMD·x86 컴파일러에서 수십 건의 버그를 뽑아낸 현장 보고

2025년 6월 4일출연: Justin Lebar (컴파일러 엔지니어) · 테마: LLM 기반 버그 발굴, 컴파일러 품질, GPU 소프트웨어 인프라

3줄 요약

퍼저 작성부터 코드 직독(direct code reading)까지 LLM 에이전트 전면 위임으로, 혼자 수 주가 걸렸을 컴파일러 버그 탐색을 며칠로 단축.
Claude Opus 4.8 + Ultra Code 모드는 토큰 소비를 1/10로 줄이면서 버그 품질을 올림 — 스캔 비용이 회당 ~$1,000 수준으로 내려왔다.
x86 백엔드에서 원자 연산 → 비원자 연산 분리라는 고위험 버그를 포함해 30건+ 확인. "AI 슬롭" 담론과 달리, LLM은 버그를 만드는 게 아니라 찾아내는 쪽에서도 실질적이다.

한눈에 — 다룬 컴파일러·테마

종목/테마	발언자	톤	핵심 한 줄
Nvidia PTXAS (클로즈드소스)	Justin Lebar	Buggy	퍼저로 40건+ 재현 가능 버그, 소스 없어서 루트콜즈 파악 불가
LLVM AMD GPU 백엔드	Justin Lebar	Bearish	다수 미스컴파일 확인, AMD 팀에 이관 중
LLVM x86 백엔드	Justin Lebar	Bearish	30건+ 검토, 원자→비원자 분리 고위험 버그 포함
LLM 보조 버그 발굴	Justin Lebar	Bullish	퍼징 한계를 코드 직독으로 돌파, 4.8+Ultra Code로 비용 1/10
AI 슬롭 담론	Justin Lebar	중립	코드 미관은 떨어지나, 버그 밀도가 실제 높다는 근거는 없다

LLM 보조 버그 발굴Bullish

퍼징의 벽을 LLM 코드 직독으로 넘다

Justin Lebar · SemiAnalysis Weekly Ep. 14 ·

💡 핵심 통찰

퍼저(fuzzer)는 초반에 빠르게 버그를 쏟아내지만, 탐색 공간이 넓어질수록 속도가 떨어지고 동일 버그를 반복 발굴하는 문제에 부딪힌다. Justin은 이 한계를 "LLM에게 컴파일러 소스코드를 직접 읽히는 것"으로 돌파했다. 코드 직독은 인간에게는 사실상 불가능한 작업이지만, LLM 에이전트는 수십만 줄을 훑으며 실질적인 버그를 짚어낸다.

퍼저 작성 소요 시간

며칠 (기존 수 주 예상)

초기 스캔 비용

~$10,000 1회 오후

Ultra Code 적용 후

~$1,000 토큰 1/10 수준

재현 가능 버그 (Nvidia)

40건+ 매우 명확한 것만

x86 버그 검토 수

30건+ 고우선순위 다수 수정 완료

두 가지 접근법: ① 퍼징(fuzzing) — LLM이 정형 무작위 프로그램을 생성하고, 컴파일 전후 동작이 같은지 비교. ② 코드 직독 — 에이전트가 컴파일러 소스(또는 어셈블리)를 직접 읽고 의심스러운 패턴을 찾는다. Anthropic이 보안 취약점 탐색에 쓴 방법과 같다.

퍼징의 세 가지 한계: (1) 탐색 공간이 커질수록 새 버그 발굴 속도 저하, (2) 이미 찾은 버그 패턴을 제외하기가 갈수록 복잡해짐, (3) 알 수 없는 루트콜즈로 인해 "이게 얼마나 큰 버그인가"를 평가하기 어렵다. 이 세 문제가 겹치면서 코드 직독 방식으로 전환하게 됐다.

하네스(harness)의 진화: 2024년 12월~2025년 1월 시도 때는 Codex에서 모델이 버그 한두 개 찾고 "다 했어요"라고 멈추는 일이 잦았다. 이제는 /goal 같은 기능이 에이전트 하네스에 기본 탑재돼 있어, 모델 지능 향상만큼이나 툴링 자체의 성숙이 체감 품질을 끌어올렸다는 게 Justin의 분석이다.

"저는 40건의 버그 목록을 그냥 쭉 가지게 됐고, 그 중 제가 살펴본 네다섯 개는 전부 명확한 버그였어요. max, subtract를 네 번 반복하면 틀린 답이 나오는 식으로요."

쉽게 풀어보기 — 퍼저와 미스컴파일이란?

퍼저(Fuzzer): 무작위 입력을 대량으로 만들어 프로그램에 던져보고 이상한 반응을 잡아내는 테스트 도구. 여기서는 "잘 구성된 랜덤 코드를 컴파일러에 넣어 결과가 올바른지 확인"하는 방식으로 사용.
미스컴파일(Miscompile): 컴파일러가 소스 코드를 잘못 번역해, 실행 결과가 원래 의도와 달라지는 현상. 실제 런타임 버그의 숨은 원인이 될 수 있다.
PTX / PTXAS: Nvidia GPU용 중간 어셈블리(PTX)를 실제 GPU 기계어로 변환하는 Nvidia 클로즈드소스 컴파일러. 소스가 공개되지 않아 버그를 찾아도 수정은 Nvidia 몫.

LLVM x86 백엔드Bearish

원자 연산이 둘로 쪼개진다 — 가장 위험한 버그

Justin Lebar · SemiAnalysis Weekly Ep. 14 ·

💡 핵심 통찰

x86 백엔드에서 발견된 최고 위험 버그는 특정 방식으로 작성된 원자 연산(atomic operation)을 컴파일러가 두 개의 비원자 연산으로 쪼개버리는 것. 단일 스레드·저경합 환경에선 증상이 없어 발견이 어렵지만, 경합이 생기는 순간 1%의 확률로 잘못된 결과를 낸다. 소리 없이 데이터를 망가뜨리는 유형이라 특히 위험하다.

검토한 x86 버그

30건+ LLM 식별 후 Justin 트리아지

Justin 수정 기여율

~50% 나머지 모델이 직접 수정

왜 이런 버그가 숨어있나: CPU 세계에선 수십억 줄의 코드가 컴파일러를 거치기 때문에, 버그가 있으면 누군가 빠르게 마주친다. GPU·ML 컴파일러는 코드 볼륨 자체가 훨씬 적어 같은 버그도 수면 아래에 훨씬 오래 머문다.

수정 과정: LLM이 버그를 찾고, LLM이 패치 초안을 작성한다. Justin이 패치를 수정할 경우(약 50%)에는 다시 LLM에게 검토를 맡긴다. LLVM 커뮤니티의 리뷰 턴어라운드가 빠른 편이어서 고우선순위 버그 대부분은 이미 수정이 완료됐다.

"30개 이상을 살펴봤는데 거의 전부, 100줄 안에 버그가 있다고 알려줘도 저 혼자였으면 절대 못 찾았을 거예요."

Nvidia PTXASBuggy

소스가 없어도 퍼저는 버그를 찾는다

Justin Lebar · SemiAnalysis Weekly Ep. 14 ·

💡 핵심 통찰

Nvidia PTXAS는 클로즈드소스라 내부 코드를 볼 수 없다. 그러나 퍼저를 통한 블랙박스 테스트로 40건 이상의 재현 가능 버그를 확인했다. 루트콜즈 파악도, 직접 수정도 불가능하지만 버그 리포트를 공개하는 것만으로도 Nvidia에 압력을 가하고 생태계 투명성을 높이는 효과가 있다.

한계: 어느 입력 패턴이 진짜 루트콜즈를 건드리는지 알 수 없다. "max-subtract를 네 번 반복하면 틀린다"는 건 알아도, 그게 극히 특정한 패턴인지 아니면 훨씬 광범위한 버그인지 판단이 어렵다. 따라서 "PTXAS는 쓰레기 컴파일러"라는 식의 결론을 내리기는 조심스럽다.

다음 단계 아이디어: 코드 직독 방법을 PTXAS에 적용하되, 이번엔 소스 대신 어셈블리 출력을 읽히는 방식. Opus 4.8이나 클로즈드소스 프론티어 모델(Cloud Mythos 언급)이라면 충분히 시도해볼 만하다고 Justin은 봤다.

LLVM AMD GPU 백엔드Bearish

미스컴파일 다수 확인 — 단, 비교는 조심스럽다

Justin Lebar · SemiAnalysis Weekly Ep. 14 ·

💡 핵심 통찰

AMD GPU 백엔드에서도 여러 건의 미스컴파일이 확인됐다. 그러나 Justin은 "AMD 백엔드가 x86 백엔드보다 더 버그 투성이"라는 결론을 내리지 않겠다고 못 박는다. 찾은 버그 수는 탐색 도구·탐색 시간의 함수이지, 컴파일러 품질 그 자체가 아니기 때문이다.

이관 현황: AMD 관련 버그는 AMD 개발팀에 전달해 직접 처리하도록 했다. Justin이 x86보다 AMD 버그를 덜 깊이 분석한 이유도 여기에 있다.

왜 GPU 컴파일러가 더 취약할 수 있나: HIP/CUDA 코드 베이스는 C++ 코드 베이스에 비해 절대 볼륨이 훨씬 작다. 예컨대 LLM 하나에 들어가는 GPU 커널 수는 Google 검색에 들어가는 코드 전체에 비하면 미미하다. 즉, 동일한 버그가 노출될 기회 자체가 적다.

AI 슬롭 담론중립

"AI 코드가 더 버그 많다"는 증거, 아직 없다

Justin Lebar · SemiAnalysis Weekly Ep. 14 ·

💡 핵심 통찰

AI가 작성한 코드를 "슬롭(slop)"이라고 부르는 담론에 대해 Justin은 미관(美觀) 문제와 버그 밀도를 분리해야 한다고 주장한다. AI 코드는 읽기 불편하고 인간 최고 협업자 수준보다 설계가 떨어지는 건 맞지만, 실제 버그가 더 많다는 데이터는 없다는 것.

뒤집힌 활용법: AI가 버그를 만든다는 걱정보다, AI가 버그를 찾아내고 수정하는 도구로 먼저 쓰여야 한다는 게 Justin의 시각이다. 버그를 직접 찾는 것보다 고객이 발견한 버그에 반응하는 쪽에 보상이 주어지는 인센티브 구조가 문제지, 도구 자체의 문제가 아니라는 것.

"AI 슬롭 캐논이 실제로 인간 슬롭 캐논보다 버그가 많다는 증거를 저는 못 봤어요. 자기가 버그를 한 번도 안 썼다고 생각하는 사람들이 어떻게 AI 코드를 못 믿냐고 하는 건 좀 웃긴 얘기죠."

한 줄 현실론: 코드 라인 당 버그 수는 AI가 더 많을 수도 있다. 하지만 개발자 하루치 생산량 기준으로 보면 AI 보조가 버그를 줄이는 쪽일 가능성도 충분하다 — 더 빠르게 기능을 배포하고, 더 빠르게 수정하기 때문에.