Hacker News 2026.03.26 33

컴파일러 최적화의 두 가지 사례: 우리가 쓰는 코드가 실제로 어떻게 바뀌는지

컴파일러가 내 코드를 고쳐준다고?

우리가 C나 C++, Rust 같은 언어로 코드를 작성하면, 컴파일러가 이걸 기계어로 번역해주잖아요. 그런데 컴파일러는 단순히 번역만 하는 게 아니에요. 코드를 분석해서 "이거 이렇게 바꾸면 더 빠르게 돌아가겠는데?" 하고 자동으로 최적화를 해주거든요. H. Cabral이 공개한 글에서는 컴파일러 최적화가 실제로 어떻게 동작하는지 두 가지 구체적인 사례를 통해 보여주고 있어요.

이런 주제가 왜 중요하냐면, 성능에 민감한 코드를 짤 때 컴파일러가 뭘 해주고 뭘 못 해주는지 아는 게 결정적이거든요. 때로는 개발자가 "최적화"라고 생각하며 짠 코드가 오히려 컴파일러의 최적화를 방해하는 경우도 있어요. 컴파일러의 시각에서 코드를 이해하면, 더 깔끔하면서도 더 빠른 코드를 작성할 수 있게 돼요.

사례 1: 루프 불변 코드 이동(Loop Invariant Code Motion)

첫 번째 사례는 LICM이라고 부르는 최적화예요. 이름이 어렵게 들리지만 원리는 간단해요. 루프 안에서 매번 같은 계산을 반복하고 있으면, 컴파일러가 그 계산을 루프 밖으로 빼주는 거예요.

예를 들어볼게요. 배열의 각 원소에 어떤 값을 곱하는 루프가 있다고 해봐요. 그 "어떤 값"이 루프 안에서 절대 변하지 않는다면, 굳이 매번 다시 계산할 필요가 없잖아요. 컴파일러가 이걸 감지하고, 계산을 루프 시작 전에 한 번만 하도록 코드를 재배치해요. 루프가 만 번 도는 거라면, 만 번 하던 계산을 한 번으로 줄이는 거니까 효과가 엄청나죠.

그런데 여기서 미묘한 부분이 있어요. 포인터(pointer)가 개입하면 컴파일러가 이 최적화를 못 할 수도 있거든요. 이게 뭐냐면, 포인터를 통해 메모리에 접근하면 컴파일러 입장에서는 "이 값이 루프 안에서 변할 수도 있고 안 변할 수도 있다"고 판단할 수밖에 없어요. 이걸 앨리어싱(aliasing) 문제라고 하는데요, 두 개의 포인터가 같은 메모리를 가리킬 수도 있으니까 컴파일러가 안전하게 "변할 수 있다"고 가정하는 거예요.

C에서 이 문제를 돕기 위해 restrict 키워드가 존재해요. "이 포인터는 다른 포인터와 겹치지 않아요"라고 컴파일러에게 알려주는 건데, 이걸 적절히 사용하면 컴파일러가 더 공격적인 최적화를 할 수 있게 되죠. Rust는 언어 차원에서 이런 앨리어싱을 방지하는 구조를 가지고 있어서, 이론적으로 더 나은 최적화가 가능한 것으로 알려져 있어요.

사례 2: 자동 벡터화(Auto-vectorization)

두 번째 사례는 자동 벡터화예요. 이게 뭐냐면, CPU에는 SIMD(Single Instruction, Multiple Data)라는 명령어 세트가 있어요. 한 번의 명령으로 여러 데이터를 동시에 처리할 수 있는 기능인데, 예를 들어 4개의 숫자를 동시에 더하는 게 가능해요. 보통 하나씩 4번 더하는 것보다 훨씬 빠르죠.

컴파일러의 자동 벡터화는 개발자가 일반적인 반복문으로 작성한 코드를 분석해서, SIMD 명령어로 변환할 수 있는 부분을 자동으로 바꿔주는 거예요. 배열의 원소를 하나씩 처리하는 루프를 4개씩(또는 8개씩, 16개씩) 묶어서 한꺼번에 처리하도록 바꾸는 거죠.

글에서는 이 자동 벡터화가 성공하는 경우와 실패하는 경우를 비교하고 있어요. 루프 안의 제어 흐름이 복잡하거나, 데이터 간 의존성이 있으면 벡터화가 안 되거든요. 예를 들어 "이전 원소의 계산 결과를 다음 원소 계산에 쓰는" 패턴은 병렬화가 불가능해요. 각 계산이 순서대로 진행돼야 하니까요.

GCC와 Clang(LLVM) 컴파일러가 같은 코드에 대해 다른 최적화를 적용하는 경우도 흥미로워요. 한쪽은 벡터화에 성공하는데 다른 쪽은 실패하거나, 같은 벡터화를 하더라도 레지스터 사용 방식이 달라서 성능이 차이 나기도 하거든요.

업계 맥락: 왜 지금 컴파일러 최적화에 관심을 가져야 할까

최근 몇 년간 컴파일러 기술은 크게 발전했어요. 특히 LLVM 프로젝트를 중심으로 한 컴파일러 인프라가 성숙해지면서, Rust, Swift, Zig 같은 새 언어들이 고성능 최적화의 혜택을 누리고 있어요. Clang의 최적화 파이프라인은 수십 개의 패스(pass)로 구성돼 있는데, 각 패스가 코드를 조금씩 더 효율적으로 바꿔나가는 구조예요.

또 하나 주목할 트렌드는 PGO(Profile-Guided Optimization)예요. 프로그램을 한번 실행해서 "어디가 많이 호출되고, 어디가 병목인지" 프로파일 데이터를 모은 다음, 그 정보를 바탕으로 다시 컴파일하는 거예요. 최근에는 Chromium, Firefox 같은 대규모 프로젝트에서 PGO를 적용해 눈에 띄는 성능 향상을 보고하고 있어요.

그리고 AI를 활용한 컴파일러 최적화 연구도 활발한데요, Google의 MLGO 프로젝트처럼 머신러닝으로 인라이닝 결정을 내리는 시도가 이미 프로덕션에 적용되기 시작했어요.

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

"나는 웹 개발자인데 컴파일러가 나랑 무슨 상관이야?"라고 생각할 수도 있는데요. JavaScript의 V8 엔진, Java의 JIT 컴파일러(C2, Graal) 등도 비슷한 최적화 기법을 사용하거든요. 핫 루프에서 성능 이슈가 있을 때 이런 원리를 이해하고 있으면 원인을 훨씬 빠르게 파악할 수 있어요.

성능 크리티컬한 시스템을 다루는 분들, 예를 들어 게임 서버, 실시간 데이터 처리, 임베디드 시스템 개발자에게는 더 직접적으로 유용한 지식이에요. Compiler Explorer(godbolt.org)라는 도구를 사용하면 내가 짠 C/C++/Rust 코드가 어떤 어셈블리로 변환되는지 바로 확인할 수 있으니, 한번 직접 실험해보시는 걸 추천해요.