MLIR의 탄생 배경과 설계 철학, Google 안팎에서의 확산, AI 방언의 난립과 거버넌스 과제, CUDA 락인 해체가 좌초된 이유, 그리고 커뮤니티와 인프라 구축에서 얻은 교훈을 다룹니다.
시리즈의 모든 글 보기 (11)
2018년 무렵, AI 소프트웨어는 시스템 단편화 문제에 직면해 있었다. TensorFlow, PyTorch, JAX, Glow, ONNX, TensorFlow-Lite, XLA, TVM—목록은 끝없이 늘어났고, 각 프레임워크는 서로 다른 “op”를 가진 저마다의 복잡한 “AI 그래프”를 발명했다. 생태계는 각기 다른 하드웨어에 최적화하려는 경쟁 속에 동일한 아이디어를 미묘하게 바꿔가며 재발명하는 사일로로 쪼개지고 있었다. 복잡성은 폭발적으로 증가했고, 무언가가 바뀌어야 했다.
그때 나는 TensorFlow를 지원하기 위해 Google의 TPU(그리고 여러 내부 ASIC) 확장을 돕고 있었고, 프로젝트마다 컴파일러 인프라를 매번 처음부터 다시 만드는 방식으로는 버틸 수 없다는 게 분명했다. 더 나은 토대가 필요했다. 다행히도 나는 LLVM을 수년간 만들어 온 경험이 있었고, 매니저로 Jeff Dean이 있었다. Jeff는 전설적인 엔지니어이자 스스로 컴파일러 박사 학위 소지자로서 같은 문제의식을 갖고 있었다.
1:1 대화에서 Jeff는 대략 이렇게 말했다:
“Chris, 나도 우리가 컴파일러 문제를 안고 있다고 생각해. 이 난장판을 통합할 새 컴파일러를 한번 만들어보면 어떨까?”
그렇게 해서 MLIR가 탄생했다. 혼돈 속에 질서를 가져오기 위해 설계된, 모듈식이고 확장 가능한 컴파일러 인프라였다. MLIR은 하드웨어 플랫폼, 소프트웨어 프레임워크, 그리고 빠르게 진화하는 머신러닝의 요구를 모두 아우를 수 있는 토대를 제시했다. 다양한 시스템을 통합하고, 여러 하드웨어 제조사의 연산을 조화롭게 연결할 수 있는 기술 플랫폼을 목표로 했다.
하지만 통합은 어렵다. 기술 프로젝트로 출발한 일은 곧 오픈소스 거버넌스, 기업 간 경쟁, 상충하는 비전이 격돌하는 전장으로 변했다. 단순한 엔지니어링의 승리가 되었을 수도 있는 일이 훨씬 복잡한 양상으로 전개되었다.
오늘날 MLIR은 CUDA를 포함해 거의 모든 주요 AI 스택에 내장되어 있다. 그럼에도 불구하고, AI 연산의 민주화라는 꿈은 아직 완전히 실현되지 못했다.
이 글은 MLIR의 이야기—어떻게 시작되었고 무엇을 바꾸었으며 그 과정에서 어떤 권력 다툼이 있었는지—를 다룬다.
현대 AI 시스템은 행렬 곱, 합성곱, 어텐션 메커니즘 등 복잡한 연산들을 연결한 그래프에 의존한다. 이를 효율적으로 최적화하고 변환하려면 6편에서 논의했듯 탄탄한 컴파일러 토대가 필요하다.
하지만 2018년 당시 대부분의 AI 프레임워크는 컴파일러 기술을 다시 발명하고 있었고, 그마저도 종종 형편없었다. SSA(Static Single Assignment) 같은 기본 기법조차 여럿에서 빠져 있었고, 각 프레임워크는 임기응변식 그래프 시스템을 꼼수로 덧대어 확장성 없이 굴리고 있었다. 그 결과는 중복투성이의 단편화되고 비효율적인 생태계였다.
나는 더 나은 접근이 필요하다고 판단했고, 뜻이 맞는 네 사람과 함께 Google의 작은 방에 모였다. 우리는 며칠 동안 화이트보드에 아이디어를 쏟아내며, AI를 위한 현대적이고 확장 가능한 컴파일러 인프라가 어떤 모습이어야 하는지 구상했다. 중심 질문은 이것이었다. **대수적 단순화에서 다면체 분석에 이르기까지 모든 최적화를 지원하면서, 모든 AI 프레임워크와 모든 하드웨어 백엔드를 아우를 수 있는 통합 표현을 만들 수 있을까?
2018년경: 필자와 네 명의 동료가 화이트보드 앞에 모여 차세대 컴파일러를 브레인스토밍
우리가 도출한 돌파구는 오늘날 **MLIR 방언(dialect)**으로 알려져 있다. 즉, 컴파일러의 핵심 인프라와 도메인 특화 관심사를 깔끔히 분리하는 방식이다. LLVM 같은 기존 컴파일러들이 단일의 경직된 중간 표현(IR)을 강요하는 대신, MLIR은 컴파일러 엔지니어가 자신들의 도메인에 맞춘 표현—커스텀 op, 타입, 의미론—을 정의할 수 있도록 했다.
덧붙임: 이 글에서 MLIR의 동작 원리를 깊게 파고들지는 않는다. 궁금하다면 원래의 기술 키노트 나 온라인 튜토리얼들 을 참고하자.
당시로서는 대부분의 컴파일러 구축 방식과 결을 달리하는 급진적 전환이었다. 전통적 인프라는 단일하고 경직된 모델 안에 모든 프런트엔드와 패스를 밀어 넣었다. 반면 MLIR은 첫날부터 이질성을 껴안았다. 여러 추상화 수준이 공존하고, 변환되며, 상호 운용되도록 했다.
이 모듈성이 핵심이었다. 같은 인프라를 되풀이해서 재구현하는 대신, MLIR은 TensorFlow 그래프든 PyTorch IR이든 맞춤형 TPU op든 상관없이 개발자들에게 공통 토대를 제공했다. 덕분에 바닥부터 시작하지 않고도 특화된 컴파일러를 구축할 수 있었고, AI 컴파일러 스택 전반에서 진정한 조합성을 가능케 했다.
MLIR은 또 하나의 컴파일러가 아니었다. 그것은 수많은 컴파일러를 만들기 위한 프레임워크였다.
MLIR은 Google Brain 내부에서, AI 컴파일러의 방식을 재고하려는 소수 정예 팀의 연구 프로젝트로 출발했다. 우리 팀은 IR 설계, 변환 구현, 핵심 아이디어의 실효성 검증 같은 기본기에 집중했다. 한편 Google의 개방적 문화와 MLIR의 모듈식 설계 덕분에 다른 팀들이 쉽게 가져가 실험할 수 있었다. 그렇게 MLIR은 곧 스스로 생명력을 갖기 시작했다.
Google 전반에서 맞춤형 ASIC을 개발하던 팀들이 가능성을 보았다. MLIR은 하드웨어 특화 연산을 구조적으로 표현하고 최적화하는 수단을 제공했다. 애플리케이션 중심 팀은 모바일 AI에 활용하기 시작했고, TensorFlow 팀은 MLIR을 TensorFlow Lite에 도입했다. 심지어 개별 연구자들도 MLIR의 유연성에 매료되어 새로운 컴파일러 기법을 프로토타이핑하기 시작했다.
이후 작은 폭발이 일어났다. 새로운 적용 사례가 나올 때마다, 우리가 아직 한창 반복개선 중일 때에도, 신선한 피드백이 쏟아졌다. 이는 우리의 방언 우선 접근법을 결정적으로 검증해 주었다. 엣지 디바이스에서 데이터센터 가속기에 이르기까지 극도로 다른 도메인 전반에 걸쳐 MLIR이 확장 가능하다는 사실이 입증된 것이다. 마침내 임계점에 도달했다. MLIR은 많은 프로젝트에서 핵심 인프라가 되어가고 있었다.
우리 중 많은 이들은 MLIR이 Google의 1자(퍼스트파티) 사용 사례를 넘어, 그 잠재력을 온전히 발휘하기를 바랐다.
위: MLIR 커뮤니티에서 잘 알려진 밈(제공: Mehdi Amini)
그래서 우리는 도약했다. MLIR을 오픈소스로 공개하고 LLVM 재단에 기여하여 업계 전체가 사용할 수 있게 했다. 채택을 돕기 위해 정기적인 “오픈 설계 미팅”을 열어, 외부 기여자들이 MLIR의 진화에 참여하고 그 뒤의 엔지니어링 투자 혜택을 공유할 수 있도록 했다. 이러한 개방적 협업은 현대적 인프라를 갈망하던 컴파일러 개발자들 사이에서 MLIR의 글로벌 모멘텀을 촉발했다.
이 연료를 바탕으로 MLIR은 이륙했다. 이제 MLIR은 수많은 주요 AI 프로젝트의 토대가 되었다. OpenXLA, Triton, 심지어 CUDA의 일부에도 쓰인다. 양자 컴퓨팅, 하드웨어 설계(CIRCT 경유), 그 밖의 많은 영역에서 컴파일러를 구동하고 있다. 전 세계의 기업들—스타트업부터 하이퍼스케일러까지—이 차세대 컴파일러를 MLIR 위에 구축하기 시작했다. MLIR의 초기 성장과 성공의 상당 부분은 Google의 리더십과 개방적 접근 덕분이었다—업계가 아직 충분히 평가하지 못한 점이라 생각한다.
그럼에도 큰 비전은 여전히 손에 닿지 않는다. 생태계는 여전히 갈라져 있다. CUDA는 여전히 최강자다. 진정한 의미의 AI 연산 민주화라는 꿈은 아직 꿈에 머문다.
무슨 일이 있었을까? 왜 MLIR은 기술적으로는 성공했지만, CUDA 락인을 깨지 못했을까?
이를 이해하려면 MLIR의 진화를 좌우한 정치, 권력 투쟁, 그리고 타협을 이야기해야 한다.
처음부터 MLIR은 범용 컴파일러 인프라—즉 도메인 특화 컴파일러를 만들 수 있게 하는 프레임워크—로 구상되었다. 목표는 유연성과 모듈성이었고, MLIR은 결코 머신러닝에만 국한된 것이 아니었다. 사실 MLIR의 “ML”은 머신러닝이 아닌 모든 것을 뜻했다(그렇다, 컴파일러 농담은 꽤 너디하다!). 하지만 AI 커뮤니티는 그 이상을 갈망했다. AI 세계는 TensorFlow나 PyTorch 모델을 폭넓은 하드웨어에 깔끔히 매핑하는 엔드투엔드 컴파일러를 원했다.
처음으로 MLIR 기반 엔드투엔드 AI 솔루션을 구축하려는 경쟁이 시작되었다
MLIR의 채택이 늘자, Google 안팎의 팀들이 그 위에 엔드투엔드 AI 솔루션을 올리려는 경쟁에 뛰어들었다. OpenXLA, TritonLang 등 다른 프로젝트들은 자신들의 스택을 강화하기 위한 구현 디테일로 MLIR을 채택했다. 질문이 생겼다. 모두가 차세대 AI 스택이 되기를 원한다. 그렇다면 누가 먼저 도착할까?
경쟁은 본격화되었다. 수년이 지난 지금, 불행한 답은 분명하다. 아무도 아니다.
LLVM 재단에 MLIR을 기여한 일은 채택을 가속했다. 기업들에 공통 토대를 제공했고, 컴파일러 엔지니어들이 조직 내에서 실질적 임팩트를 입증할 기회를 열어줬다. LLVM 재단은 감독과 법적 이슈를 도와주지만, 기술 설계에는 개입하지 않는다. 기술 방향은 커뮤니티가 스스로 정해야 한다.
업계 전반의 엔지니어들(선도 역할을 한 Google 포함)이 AI 특화 방언—arith, linalg, tensor 등—을 기여하기 시작했다. 현대 AI 컴파일러 스택을 만드는 데 유용한 부품 일부였다. 초기에는 MLIR에 먼저 접근한 Google 연구팀이 주도했지만, 선례가 만들어졌다. “잠재적으로 유용해 보이는” 기여들이 상류 트리에 올라갔고, 프로젝트 리더가 원칙에 따라 “아니오”라고 말할 수 있도록 하는 제한적 거버넌스가 있었을 뿐이다.
불행히도, 이 폭발은 MLIR 설계의 매우 초기 단계에서 일어났고, 이러한 방언들에 담긴 많은 설계 결정은 진화하는 생성형 AI(GenAI) 요구에는 최적이 아니었다. 예컨대 초기 작업의 상당수는 TensorFlow 개선과 OpenXLA 구축에 초점이 맞춰졌고, 그 결과 이 방언들은 1급의 PyTorch 및 생성형 AI 지원을 염두에 두고 설계되지 않았다(이는 이 연재 이전 글에서도 다뤘다).
이들 노력 상당수는 원래 목표를 달성했지만, 세상은 그 사이 변했다.
여러 이유로, 초기 MLIR 개발자들(나를 포함해) 대부분이 Google을 떠나 하드웨어 기업으로 갔다. MLIR 지식이 퍼진 것은 긍정적 결과였다. 기술이 널리 뻗어나갈 수 있었기 때문이다. 하지만 새로운 도전도 가져왔다.
문제는, MLIR의 성공과 함께 핵심 개발자들이 업계 전반으로 흩어졌다는 점이다. 예전에는 동지이자 동료였던 사람들이 경쟁사로 이직해, 공유된 MLIR 방언 위에 각자의 독점 AI 스택을 쌓기 시작했다. 개방 협업으로 시작한 일이 곧 상업 경쟁과 충돌했다. 중앙 조정이 부족하자 팀 간 소통이 무너졌다. 우선순위가 충돌했고, MLIR에 대한 한때의 통합 비전은 균열을 보이기 시작했다.
MLIR의 정체성 위기: 머신러닝 솔루션인가, 컴파일러 프레임워크인가?
이제 MLIR은 정체성의 위기에 서 있다. 어떤 도메인에도 쓸 수 있는 범용 컴파일러 프레임워크인가, 아니면 AI 솔루션인가? 오늘날 MLIR은 범용 재사용 인프라로는 비할 데 없이 강력하며, 하드웨어 설계부터 양자 컴퓨팅까지 다양한 분야를 구동한다. 반면 내장된 AI 관련 방언들은 논쟁적이고 불완전하지만, 여전히 많은 오픈/상용 다운스트림 스택에 필수적이다.
분위기는 마치OpenCL의 재현 같아졌다. 레퍼런스 스택은 없고, 하드웨어 벤더들은 경쟁하며, 매우 공손한 전장이 펼쳐졌다—예전의 Khronos 위원회처럼.
긴장 상태는 수년간 지속되었고, 더 넓은 LLVM과 MLIR 커뮤니티 전반에서 깊이 체감되었다.
다행히 새로운 희망이 있다. LLVM은 공로주의(meritocracy)에 기반을 둔 커뮤니티로, 시장에서 회사들이 전쟁을 벌일 때조차 엔지니어들의 방향을 일치시켜 온 훌륭한 실적이 있다. MLIR 커뮤니티에는 프로젝트 개선을 위해 수년의 열정과 노력을 쏟아부은 훌륭한 엔지니어들이 가득하며, 지금도 진전이 일어나고 있다!
MLIR에는 진화를 이끌 새로운 Area Team이 생겼고, 새 조직 구조와 헌장, 거버넌스 그룹도 마련되었다. 헌장은 영역을 분리한다. MLIR Core(도메인 독립적 인프라)와 방언(예: 머신러닝 특화 조각들)로 말이다. MLIR을 개선하고 문제를 풀기 위해 시간을 들이는 모든 분들께 깊이 감사한다. 이러한 노력은 생태계에 구축하는 모든 이들과 다운스트림 사용자들에게 지대한 영향을 미친다.
내 소망이 하나 있다면, “MLIR”이 도메인 독립적 컴파일러 인프라를 명확히 가리키고, 해당 방언들은(아마 “TensorIR” 같은) 새로운 이름을 얻는 것이다. 이렇게 하면 “MLIR”이 실제로 무엇인지에 대한 혼란을 줄일 수 있다!
MLIR에서 얻은 가장 큰 교훈은, 핵심 토대가 충분히 굳기 전에 너무 일찍 스케일하면 오래 가는 문제가 생긴다는 점이다. 초기 관심과 기여의 폭발은 흥미진진했지만, 명확한 가이드와 정렬 없이 병렬로 내려진 설계 결정이 많아졌다는 뜻이기도 하다. 우리는 “각 계층에서 뛰어난 무언가”를 얻는 대신 “많은 것을 빨리” 얻었고, 그 결과 Hyrum의 법칙의 함정에 빠졌다.
또 하나는 매니지먼트에 관한 교훈이다. 똑똑한 엔지니어가 너무 많이, 제각각 다른 방향으로 전력질주하면, 나중에 배를 돌리기가 매우 어렵다—설령 그 배가 아름답게 설계된 IR로 만들어졌다고 해도 말이다. 이번 경우, 내가 LLVM/MLIR 커뮤니티에서 영향력을 유지하고 있음에도, 기여자의 고용주의 급여가 영향력을 능가한다는 사실을 배웠다. 급여는 그들이 자신의 작업을 트리에 올려놓고 다음 버그 수정이나 프로젝트로 넘어가게 만드는 방향으로 흐른다.
또 다른 교훈은 야심을 품은 인프라에 관한 것이다. MLIR의 목표는 컴파일러 구현을 통합하는 것이었고, 이는 내 기대를 넘어 성공했다. 하지만 나는 또한 공동체 주도의 프로젝트가 세상을 전진시킬 수 있다는 낙관을 공유하며, 그 이상을 향해 다른 이들을 독려하고 촉발했다. 그건 잘 풀리지 않았다. 그리고 이는 내가 참여한, 업계에 큰 영향을 준 다른 프로젝트들—LLVM, Clang, Swift, 그리고 “MLIR Core”—에서도 본 교훈을 다시금 확인시켜 주었다. 나는 그 어느 때보다, 작은 팀이 단일한 성공 비전에 맞춰 정렬하고 이를 추진하는 데 최적이라는 것을 배웠다. 프로젝트의 정체성이 단단히 자리 잡은 뒤에야 더 넓은 커뮤니티로 스케일하는 게 타당하다.
MLIR에는 방언이 많지만, 많은 방언이 논쟁적이거나 미완성이다.
이전 세편의글에서 해온 전통대로, 차세대 AI 솔루션에 바라는 요건 목록을 기준으로 MLIR AI 방언을 평가해 보겠다. 내 최선의 견해는 다음과 같다.
결국 앞서 논의했듯, 이것은 **컴파일러 제작 툴킷으로서의 “MLIR Core”**를 평가하는 데 몹시 불공정한 잣대다. MLIR은 수십 개 시스템에 널리 쓰이며 원래의 임무를 확실히 성공했다. MLIR의 AI 방언 성공은 그것이 활용되는 무수한 다운스트림 AI 구현에 끼친 영향으로 측정해야 할 텐데—그 방법을 나도 잘 모르겠다.
이 시점에서 패턴이 보일 것이다. OpenCL/OneAPI, TVM/XLA, MLIR, 혹은 다른 어떤 선의의 약어들이든 간에, AI 인프라를 통합하려는 강력한 시도가 있어 왔다. 하지만 어느 것도 개발자들이 사랑하는 솔루션을 제공하지 못했다. 프로젝트는 분열되고, 약속은 희미해지며, 대안 하드웨어 사용자들은 “그냥 잘 작동하는” 도구 없이 남겨졌다.
냉정한 진실은 이것이다. 진짜 답을 찾아낸 회사는 단 하나, NVIDIA뿐이라는 것. CUDA는 인프라일 뿐 아니라 전략이다. 수직 통합, 현장 애플리케이션 엔지니어, 실제 세계 성능에 대한 집요한 집착이 뒷받침한다. 열려 있지도, 아름답지도 않지만, NVIDIA에겐 놀랍도록 잘 작동한다—비록 혁신가의 딜레마가 산타클라라에서도 살아 숨 쉬고 있긴 하지만.
그렇다면 왜 다른 하드웨어 기업들은 이걸 해내지 못할까? 왜 업계에서 가장 똑똑한 사람들이 수십억의 자금을 등에 업고도 아무도 쓰고 싶어 하지 않는 소프트웨어를 계속 만들까? 기득권 수직 통합 리더와 경쟁할 땐 판이 기울어져 있고, 업계와 조직 내부의 인센티브가 결과를 좌우하기 때문이다.
“인센티브를 보여 달라. 그러면 결과를 보여 주겠다.”
– Charlie Munger
이 주제는 다음 편에서 더 깊이 파헤치겠다. 그때까지, 어떤 방언도 정규화되지 않은 채로 두지 말자! 🛠
-Chris
