강의 번호
L055
Modular (Chris Lattner / 전 LLVM, Swift, Tensorflow 핵심) 가 만든 Mojo 라는 새 언어 — Python 의 surface syntax 를 유지하면서 MLIR 위에서 lowering 해 CPU + GPU + 다양한 가속기 를 같은 코드로 다룬다는 야심. 그 디자인의 의도와 실제 도달한 위치, 그리고 CUDA/Triton 과의 차이의 학습 노트. 본 페이지는 transcript 가 실패해 Modular 공식 문서, Chris Lattner 의 talk, Mojo 공개 코드로 재구성됐다 — speaker 정보가 누락되어 비워둠.
ML 가속기 생태계는 — 같은 알고리즘을 NVIDIA 위에서 (CUDA), Apple 위에서 (Metal), AMD 위에서 (ROCm), Intel 위에서 (OneAPI), Google TPU 위에서 (XLA) 따로따로 짠다. 한 언어로 모두를 다룬다 는 야심을 가진 도구가 Mojo — 그 의도를 어디까지 실현했는가.
강의의 출발 질문 셋.
본 노트는 transcript 실패로 — Modular 공식 문서 (docs.modular.com/mojo), Chris Lattner 의 talk (LLVM dev meetings, ASPLOS), Mojo 공개 standard library 의 코드로 재구성. speaker 정보가 누락되어 발표자 인용 형식 안 씀.
Mojo 의 디자인은 두 축으로 본다. (1) 언어 자체의 야심 — Python 의 친숙함 + C++ 의 zero-overhead + Rust 의 안전성. (2) 컴파일 인프라의 야심 — MLIR 위에서 모든 가속기를 같은 IR 로. 둘이 같이 가야 의미 있고, 둘이 따로 가면 “또 하나의 언어”.
Mojo 가 풀려는 핵심 문제는 “하나의 언어로 high-level Python 과 low-level kernel 을 모두” — 즉 two-language problem 의 해소. ML 엔지니어가 Python 으로 모델을 짜고, kernel 엔지니어가 CUDA 로 가속기를 짜는 두 세계가 분리된 자리.
Mojo 의 디자인 결정.
# Mojo 코드 예시 — Python 처럼 보이지만 type 명시
fn matmul(
a: Tensor[DType.float32],
b: Tensor[DType.float32]
) -> Tensor[DType.float32]:
var c = Tensor[DType.float32](a.shape[0],
b.shape[1])
@parameter
fn compute_row(i: Int):
for j in range(b.shape[1]):
var acc: Float32 = 0
for k in range(a.shape[1]):
acc += a[i, k] * b[k, j]
c[i, j] = acc
parallelize[compute_row](a.shape[0])
return c위 코드의 인상 — Python 과 거의 같지만 fn, var, type annotation, @parameter, parallelize 같은 추가 요소. 이게 “Python superset” 의 의미. 같은 파일에서 dynamic Python 부분과 strict-typed kernel 부분이 섞인다.
Mojo 의 의도된 사용법 — “Python 코드를 그대로 가져와서, hot loop 만 type 추가하면 빨라진다”. 사용자가 처음부터 모든 걸 새로 배울 필요 없이 점진적으로 깊이 들어갈 수 있게.
def 대신 fn 으로 정의. type 명시 강제. AOT 컴파일 가능. C 와 비슷한 속도.
10~100×
SIMD[DType, width] type 사용. CPU vector instruction 직접 매핑. 메모리 alignment 까지 통제.
+ 4~8×
parallelize[fn] 으로 multi-thread 실행. 같은 코드를 thread pool 위에서.
+ N cores
@target("nvptx") 같은 attribute. 같은 함수가 GPU 위에서 컴파일 + 실행.
+ GPU
Mojo 는 같은 파일에 두 모드를 둔다. def 는 dynamic Python 호환 함수 — 자유롭지만 느림. fn 은 strict-typed Mojo 함수 — type 강제, 컴파일, 빠름. 사용자가 명시적으로 어느 모드를 쓸지 결정.
type 시스템의 한 가지 흥미로운 점 — parametric type. C++ 의 template 과 비슷하지만 type 과 const value 를 같은 mechanism 으로 generic. SIMD[DType.float32, 8] 의 8 은 compile-time const — vector width 가 type 의 일부.
Mojo 의 진짜 차별점은 — MLIR 위에서 동작한다는 점. MLIR 은 LLVM 프로젝트 안의 “여러 dialect 를 같이 다루는 IR 인프라”. Mojo 는 자기 dialect 를 정의하고, 그 dialect 가 MLIR 의 다른 dialect (gpu, nvgpu, vector, linalg 등) 로 lowering.
.mojo 파일. Python-like syntax + type system.
human
parametric 가 그대로 유지.
MLIR
MLIR 의 의미 — “여러 IR 를 한 frame 안에서”. dialect 라는 단위로 nested IR 를 두고, 한 단계의 lowering 이 다른 dialect 로 점진적으로 변환.
이게 왜 의미 있는가 — 새 가속기 backend 를 만들 때 새 언어를 만들 필요가 없다. MLIR 의 한 dialect 를 정의하고, 그 dialect 가 기존 generic dialect 로 lowering 하면 — 자동으로 위에서 내려오는 ML 워크로드 모두를 받을 수 있음.
CUDA 는 single-target language — NVIDIA GPU 만 지원. Mojo (MLIR) 는 — 같은 source 가 여러 backend 로 동시에. 이론적으로는. 실제로는 backend 별로 추가 작업 필요.
Mojo 의 약속 — 같은 source 가 CPU/GPU 모두 컴파일된다. 실제로는 두 가지 패턴. (1) 동일 코드 — generic 한 vectorize/parallelize 가 CPU/GPU 별로 다른 backend 로 lowering. (2) target-specific 분기 — @target("gpu") 으로 GPU-only 코드 작성.
“같은 코드” 가 정말 같으려면 — algorithm 이 두 hardware 에서 같은 모양이어야 함. matmul 같은 경우 가능. 그러나 attention 같은 경우 — GPU 의 SRAM 위에서 SOTA 인 알고리즘 (FA) 은 CPU 위에선 다른 모양이 더 좋음 (block matmul + bigger cache). 결국 두 hardware 에서 진짜 SOTA 를 내려면 target-specific 코드 가 필요. Mojo 도 예외 아님.
# 같은 코드가 CPU 와 GPU 양쪽에서 컴파일
fn vector_add[size: Int](a: SIMD[DType.float32, size],
b: SIMD[DType.float32, size]
) -> SIMD[DType.float32, size]:
return a + b
# GPU only — target attribute
@target("nvptx")
fn matmul_tiled_gpu(...):
# shared memory · sync · MMA 지원
var tile = stack_alloc[shared, ...]()
...
# CPU only — 다른 algorithm
@target("x86_64")
fn matmul_tiled_cpu(...):
# cache-aware blocking · AVX
...실전 모델의 일반적 분기.
vectorize + parallelize.@parameter 로 target-aware tile 결정.Mojo 의 가치는 — 분기 자체가 아니라 “분기의 인프라 가 통합” 되어 있다는 점. 사용자는 같은 type system, 같은 lifetime, 같은 syntax 로 두 코드를 짠다. 새 언어 두 개 안 배워도 된다.
Mojo 의 가장 실용적 결정 — CPython 의 모든 라이브러리를 그대로 import. from python import Python, 그 다음 NumPy 든 PyTorch 든 그대로. 새 생태계를 zero 부터 만들 필요 없음.
# Mojo 안에서 Python 모듈 import
from python import Python
fn main():
np = Python.import_module("numpy")
arr = np.array([1, 2, 3])
var mean = arr.mean()
print(mean) # 2.0
# Pytorch 도 그대로
torch = Python.import_module("torch")
t = torch.randn(10, 10)
print(t.shape)이 interop 의 의미 — 사용자가 “기존 PyTorch 코드의 hot loop 만 Mojo 로” 쓸 수 있음. 점진적 진입의 핵심 자리.
그러나 한계 — Python 객체와 Mojo 객체는 boundary 에서 변환. numpy.ndarray → Mojo Tensor 는 zero-copy 가능 (DLPack), 그러나 일반 Python 객체는 복사. boundary 가 hot path 에 있으면 손해.
(1) 기존 Python 코드의 outer 부분은 그대로. (2) hot kernel 만 Mojo fn 으로. (3) numpy/torch tensor 의 내부 buffer 를 zero-copy 로 받고 결과 buffer 도 zero-copy 로 돌려줌. 이 boundary 가 깔끔하게 안 잡히면 interop 비용이 큼.
다른 시도 — Modular 의 MAX engine. PyTorch / TensorFlow 모델을 받아서 Mojo 로 컴파일된 inference engine 으로 변환. 사용자는 Mojo 안 봐도 가능. 즉 “Mojo 가 뒤에서 도는 것” 도 의도된 사용 패턴.
Mojo 의 채택 단계는 — language 가 2023 년에 발표되었고, 2024 년에 open source 일부, 2025 년 시점에서도 “early adopter” 단계. 실전 production 사용 사례는 많지 않지만 몇 군데 명확히 있다.
Mojo 는 — “기술적으로는 흥미롭지만 production 도입은 일부”. CUDA / Triton / PyTorch 의 강력한 incumbent 가 있어 — 새 language 의 진입 장벽이 큼. 그러나 MAX engine 이 충분히 빠르다면 — 사용자가 Mojo 를 직접 보지 않고도 그 효과를 누릴 수 있음. 이 “invisible adoption” 이 가장 가능성 높은 시나리오.
Mojo 와 Triton/CUDA 를 “경쟁자” 로 봐야 하는지 — 사실 셋이 차지하는 자리가 다르다. 같이 쓰일 수 있는 도구들.
(1) 전체 program — kernel 뿐 아니라 host code 까지. (2) cross-target — CPU + GPU + 미래의 가속기. (3) Python superset — 점진적 진입. 이 셋이 합쳐지는 지점에서 — Mojo 가 차지하려는 자리는 “PyTorch + Triton + CUDA 가 셋 다 들어가야 하는 자리를 한 언어로”.
그러나 — “하나로 다 한다” 는 야심은 종종 “여러 자리에서 약간씩 부족하다” 로 끝난다. Triton 의 GPU kernel 을 Mojo 로 짜는 것이 진짜 Triton 만큼 빠른가? CUDA 의 디테일한 통제가 Mojo 에 다 있는가? 산업의 검증이 더 필요한 자리.
Mojo 가 직접 사용자에 노출되기보다 — MAX inference engine 같은 형태로 “뒤에서” 동작. 사용자는 PyTorch 모델을 그대로 쓰고, 그 모델이 Mojo 로 컴파일되어 빠르게 추론. 이 시나리오라면 — Mojo language 의 직접 채택은 부수적이고, MLIR 인프라의 가치가 본질적.
SIMD[DType, width] 같이 type 과 const 를 함께 generic. C++ template 보다 일반적.Mojo 는 빠르게 발전 중인 언어 — 본 노트의 spec 과 사용 패턴은 강의 시점 (2024) 의 모습. 2025 년 이후 — open source 진행, language 의 stable spec 도달, MAX engine 의 production 채택 — 이 셋의 진행에 따라 본 노트의 평가가 갱신될 필요. Mojo 공식 docs 와 GitHub release notes 를 직접 확인 권장.