LLVM RISC-V에서 성능이 25% 떨어진 원인을 추적한 이야기

컴파일러 한 줄이 성능을 25%나 깎아먹는다고?

컴파일러 성능 회귀(regression)를 추적하는 건 정말 까다로운 작업이에요. 어제까진 잘 돌아가던 코드가 오늘 갑자기 25%나 느려졌는데, 내 코드는 한 줄도 안 바꿨다면? 이건 컴파일러 쪽에서 뭔가 바뀐 거예요. 한 개발자가 LLVM의 RISC-V 백엔드에서 발생한 25% 성능 회귀를 추적한 과정을 상세하게 공유했는데, 컴파일러 내부와 디버깅 방법론을 이해하는 데 정말 좋은 사례예요.

먼저 용어를 좀 정리하고 가면, LLVM은 컴파일러 인프라 프로젝트예요. 우리가 C, C++, Rust 같은 언어로 코드를 짜면 이걸 기계어로 바꿔주는 게 컴파일러잖아요. LLVM은 이 과정의 "뒷단(백엔드)"을 담당해요. 프로그래밍 언어에서 중간 표현(IR)이라는 공통 형태로 변환된 코드를 받아서, 실제 CPU가 이해하는 기계어로 바꿔주는 거죠. 그리고 RISC-V는 요즘 많이 들리는 오픈소스 CPU 아키텍처예요. ARM처럼 저전력 환경에서 쓰이는데, 설계가 공개되어 있어서 누구나 RISC-V 기반 칩을 만들 수 있어요.

어떻게 문제를 찾아냈나

이 개발자가 사용한 핵심 도구는 git bisect예요. git bisect가 뭐냐면, 문제가 없던 커밋과 문제가 있는 커밋 사이에서 이진 탐색을 해서 정확히 어떤 커밋이 문제를 일으켰는지 찾아주는 Git 기능이에요. 커밋이 1000개라고 해도 약 10번만 테스트하면 범인을 찾을 수 있죠. 이진 탐색이라는 게, 반씩 쪼개가면서 "이쪽이 문제인가, 저쪽이 문제인가" 좁혀가는 방식이에요.

LLVM 같은 거대한 프로젝트에서 bisect를 하려면 매번 전체 빌드를 해야 해서 시간이 엄청 걸리거든요. 이 개발자는 자동화 스크립트를 만들어서 빌드 → 벤치마크 실행 → 결과 비교를 자동으로 반복하게 했어요. 이렇게 해서 결국 원인이 되는 커밋을 특정한 건데요.

문제의 원인이 흥미로워요. LLVM의 명령어 스케줄링(instruction scheduling) 관련 변경이었거든요. 명령어 스케줄링이란, 컴파일러가 기계어 명령어들의 순서를 재배치해서 CPU가 더 효율적으로 실행할 수 있게 만드는 최적화 과정이에요. 현대 CPU는 파이프라인이라는 구조로 여러 명령어를 동시에 처리하는데, 명령어 순서가 안 좋으면 파이프라인에 빈 구멍(stall)이 생기면서 성능이 떨어져요.

문제가 된 변경은 다른 아키텍처(예를 들어 x86이나 ARM)에서는 성능을 개선하는 최적화였는데, RISC-V의 특정 마이크로아키텍처에서는 오히려 역효과가 난 거예요. 이게 컴파일러 최적화의 어려운 점이에요. 한 환경에서 좋은 최적화가 다른 환경에서는 나쁜 결과를 낳을 수 있거든요.

디버깅 방법론이 주는 교훈

이 사례에서 배울 수 있는 디버깅 방법론이 몇 가지 있어요.

첫 번째는 측정 먼저라는 원칙이에요. "느려진 것 같다"가 아니라 구체적인 벤치마크 숫자로 시작해요. 25%라는 수치가 있었기 때문에 bisect 과정에서 "이 커밋은 문제가 있는 쪽인가 없는 쪽인가"를 명확하게 판단할 수 있었어요.

두 번째는 문제 범위 좁히기예요. 전체 애플리케이션이 아니라, 성능이 떨어진 특정 함수를 먼저 식별하고, 그 함수의 어셈블리 출력을 비교해요. 컴파일러가 생성한 기계어가 어떻게 달라졌는지를 눈으로 확인하는 거죠.

세 번째는 자동화의 힘이에요. 수동으로 bisect하면 커밋 하나당 빌드에 수십 분이 걸리니까 사람이 하루 종일 앉아 있어야 해요. 스크립트로 자동화하면 밤새 돌려놓고 아침에 결과만 확인하면 돼요.

한국 개발자에게 주는 시사점

RISC-V는 한국에서도 관심이 커지고 있는 분야예요. 삼성, SK 같은 대기업들이 RISC-V 기반 칩 개발에 투자하고 있고, 학계에서도 연구가 활발하거든요. LLVM의 RISC-V 백엔드 품질은 이런 생태계 전체에 영향을 미치는 문제예요.

또한 이 글에서 보여주는 디버깅 방법론은 컴파일러 개발자가 아니어도 배울 게 많아요. git bisect는 일반 애플리케이션 개발에서도 "어느 커밋에서 버그가 생겼지?"를 찾을 때 엄청 유용하거든요. 그리고 "측정 → 범위 좁히기 → 자동화"라는 디버깅 흐름은 성능 문제를 추적할 때 보편적으로 적용할 수 있어요.

컴파일러 내부에 관심 있는 분이라면 LLVM의 RISC-V 백엔드 코드를 읽어보는 것도 추천해요. LLVM은 문서화가 잘 되어 있는 편이고, RISC-V는 아키텍처 자체가 단순해서 다른 백엔드보다 진입 장벽이 낮거든요.

정리하자면

하나의 컴파일러 최적화 커밋이 특정 아키텍처에서 25% 성능 회귀를 일으킬 수 있고, 이를 체계적으로 추적하는 과정 자체가 훌륭한 엔지니어링 교훈이에요.

여러분은 성능 회귀 문제를 겪어본 적 있나요? git bisect 같은 도구를 실무에서 얼마나 활용하고 계신가요?