Mojo 완벽 정리 - Python superset이자 MLIR 기반 AI 시스템 언어

이 글은 "AI 스택은 왜 10년째 두 언어로 쪼개져 있고, Mojo는 그것을 어떤 아키텍처로 한 언어 안에 합치려 하는가, 그리고 어디까지 쓰고 어디부터는 쓰면 안 되는가"를 한 번에 정리합니다. Mojo는 LLVM·Clang·Swift·MLIR을 만든 Chris Lattner가 Modular Inc.에서 시작한, Python의 superset이자 systems 프로그래밍 언어입니다. Python 문법을 그대로 받되 fn·struct·SIMD[T,N]·borrow 같은 시스템 키워드를 추가해 인터프리터 없이 MLIR로 컴파일하고, GIL이 없으며, GPU 커널을 같은 파일에 같은 문법으로 작성합니다. 즉 PyTorch wrapper(Python) + CUDA kernel(C++) 두 언어로 갈라지던 AI 스택을 한 언어 안에 통합합니다.

1. Mojo 기술이란?

1-1. 왜 필요한가 — "AI 스택은 10년째 두 언어로 쪼개져 있다"

2010년대 초 NumPy 등장 이후, AI·과학 계산의 사실상 표준은 "Python으로 모델 그래프를 그리고, 핵심 수치 연산은 C/C++/CUDA로 미리 컴파일된 라이브러리에 위임한다"는 패턴이 됐습니다. PyTorch·TensorFlow·JAX·NumPy·SciPy 모두 이 구조입니다. 사용자는 Python을 보지만 실제로 도는 것은 libtorch.so·cudnn.so·cuBLAS·cuDNN·FlashAttention.cu입니다.

"PyTorch에서 새 attention 연산자를 추가하려면 (1) Python 클래스를 짜고 (2) C++ extension binding을 만들고 (3) .cu로 CUDA 커널을 다시 짜고 (4) Triton DSL로 한 번 더 짠다. 같은 알고리즘을 네 번 표현한다. backward는 또 따로다. 디버거는 한 언어밖에 못 본다. 빌드 한 번에 30분."

이 구조의 통증은 4가지로 정리됩니다.

통증	정체
Two-language problem	UX 언어(Python)와 성능 언어(C++/CUDA)가 분리. ABI·binding·빌드 시스템이 모두 이중화
GIL	Python은 진정한 멀티스레딩 불가. 멀티코어 추론은 multiprocessing 메모리 N배 또는 C++ escape
인터프리터 오버헤드	작은 텐서 연산은 dispatcher·dtype·shape check가 GPU 연산보다 비싼 Eager mode tax
커널 작성의 폐쇄성	새 GPU·TPU·Trainium·MTIA에 한 번만 짜면 도는 표준 부재. CUDA·ROCm·SYCL·Metal로 갈라짐

업계는 이 통증을 우회하려 Cython·Numba·CuPy(부분 가속), Triton(GPU 커널 DSL), JAX/XLA·torch.compile(그래프 컴파일), TVM·Halide·MLIR(컴파일러 인프라) 등 수많은 도구를 만들었습니다. 모두 같은 원칙을 공유합니다 — "Python은 못 바꾸니까, Python 위·아래에 보조 컴파일러를 붙이자". Mojo는 정반대 방향을 택했습니다.

1-2. 기술 정의

Mojo는 Modular Inc.가 만든, Python의 superset을 지향하는 컴파일 시스템 프로그래밍 언어입니다. ① Python 문법 호환 — def·들여쓰기·동적 타이핑·comprehension·데코레이터를 그대로 인식, 같은 파일에서 Python.import_module("numpy")로 진짜 CPython 호출 가능. ② Systems 확장 — fn(엄격 모드)·struct(POD)·var(타입 추론)·borrowed/owned/inout(ownership)·SIMD[DType.float32, 16]·컴파일타임 메타프로그래밍. ③ MLIR 1급 통합 — LLVM IR로 직행하지 않고 MLIR로 lowering, tensor·linalg·gpu·nvgpu dialect를 자유롭게 섞어 호스트 코드와 GPU 커널을 같은 언어로 표현.

창시자 Chris Lattner의 이력 자체가 Mojo의 근거입니다 — LLVM(2003), Clang, Swift(2014, Apple), MLIR(2019, Google). Mojo는 이 넷의 직계 후손입니다. "AI를 위한 Swift"라고 보면 가장 정확하되, Python 호환을 약속한 Swift입니다.

2. Mojo의 특징

특징	설명
Python superset (점진 호환)	파일 확장자 .mojo / .🔥. 순수 Python을 거의 그대로 실행하고 fn·struct·타입을 점진 도입
GIL 없음	인터프리터 없음 → GIL 없음. 진짜 멀티스레드, parallelize·async 1급
1급 SIMD 타입	SIMD[DType.float32, 16] 언어 내장. AVX-512·NEON·SVE를 추상 width로 표현, 컴파일러가 타깃 ISA에 맞게 lowering
Ownership 모델	owned·borrowed·inout으로 Rust 류 borrow checker. GC 없이 메모리 안전
컴파일타임 메타프로그래밍	@parameter·alias·@always_inline로 컴파일 시 코드 생성. C++ 템플릿보다 가독적
MLIR 직접 노출	stdlib 내부에서 __mlir_op."..."(...)로 dialect 직접 호출 가능. 라이브러리 작성자용
GPU 커널 동일 언어	2024년 말부터 NVIDIA GPU 커널 작성 가능. 같은 파일에 호스트 함수와 @kernel 디바이스 함수 공존
MAX 엔진 동봉	Modular의 추론 엔진 MAX가 함께 배포. ONNX/PyTorch/TF 모델을 MLIR로 컴파일·서빙, CPU·GPU 동일 API

2-1. Python·C++·Rust·Mojo 비교

항목	Python (CPython)	C++	Rust	Mojo
실행 모델	인터프리터 + 부분 JIT	AOT 컴파일	AOT 컴파일	AOT/JIT, MLIR 기반
GIL	있음	없음	없음	없음
메모리 모델	refcount + GC	수동·RAII	borrow checker	ownership + 선택 ARC
SIMD	NumPy 우회	intrinsic·라이브러리	std::simd(unstable)	1급 SIMD[T,N]
GPU 커널	외부 (CUDA/Triton)	CUDA C++	외부 (rust-CUDA·candle)	같은 언어, 같은 파일
Python 호환	네이티브	pybind11 필요	PyO3 필요	superset, 직접 import
러닝 커브	낮음	매우 높음	높음	중간 (Python 출신엔 낮음)

3. Mojo 동작 방식 — 구성 요소와 데이터 흐름

3-1. 구성 요소

레이어	구성 요소	역할
프론트엔드	Mojo Parser / Sema	Python 문법 + Mojo 확장 파싱, 타입 추론, ownership 검사
중간 표현	MLIR (다중 dialect)	kgen·pop·tensor·linalg·gpu·nvgpu·llvm 등으로 점진 lowering
백엔드	LLVM IR / NVVM / SPIR-V	CPU(x86·ARM)·GPU(NVIDIA·AMD)·Apple Silicon 코드 생성
런타임	Mojo runtime + MAX	스레드풀, allocator, async executor, MLIR 그래프 실행기
표준 라이브러리	stdlib (Apache 2.0)	SIMD·Tensor·List·String·algorithm·parallelize
Python 인터럽	Python.import_module	같은 프로세스에서 CPython 임베딩, NumPy/Pandas 그대로 사용
패키지 / 툴체인	magic / pixi CLI	Conda + PyPI 통합 매니저, 가상환경·SDK·CUDA toolkit 일괄 관리

3-2. 데이터 흐름 — "한 언어가 어떻게 GPU까지 도달하는가"

사용자가 Mojo로 행렬 곱 함수 한 개를 작성하면, 같은 텍스트가 다음 경로로 컴파일됩니다.

1. Parse — Python AST + Mojo 확장
2. Type / borrow check — fn 함수는 모든 타입과 소유권을 정적으로 확인
3. MLIR lowering (high-level) — tensor·linalg dialect로 표현, 도메인 의미 보존
4. 최적화 패스 — fusion · tiling · vectorization · autotune
5. Target lowering — CPU 경로는 llvm dialect → LLVM IR. GPU 경로는 gpu/nvgpu → NVVM(PTX)/SPIR-V/Metal IR
6. Codegen — 머신 코드 또는 PTX
7. Link / Load — Mojo 런타임이 호스트와 디바이스를 묶어 실행, MAX는 그래프 노드 단위 캐시

핵심은 "같은 알고리즘이 dispatch 없이 한 IR 위에서 표현되고 fusion된다"는 점입니다. PyTorch에서 보던 op-by-op overhead가 사라집니다.

4. Mojo 구성 및 흐름도 — 단계별 처리 흐름

4-1. 전체 흐름도 (개념도)

┌─────────────────────────────────────────────────────────────────┐
│ 1) 사용자 Mojo 소스 (.mojo)                                     │
│    - Python 호환 def / class                                    │
│    - fn / struct / SIMD / @parameter / @kernel                  │
└──────────────┬──────────────────────────────────────────────────┘
               │ Parser + Sema
               ▼
┌─────────────────────────────────────────────────────────────────┐
│ 2) MLIR (high-level)                                            │
│    dialects: tensor, linalg, affine, kgen, pop                  │
│    - 텐서·루프·SIMD 의미 보존                                   │
└──────────────┬──────────────────────────────────────────────────┘
               │ optimization (fusion, tiling, vectorize, autotune)
               ▼
┌─────────────────────────────────────────────────────────────────┐
│ 3) MLIR (target-aware)                                          │
│    CPU 경로 → llvm dialect                                      │
│    GPU 경로 → gpu/nvgpu/spirv/rocdl dialect                     │
└──────────────┬───────────────────────┬──────────────────────────┘
               │                       │
               ▼                       ▼
       ┌───────────────┐        ┌────────────────┐
       │ 4a) LLVM IR   │        │ 4b) NVVM/SPIR-V│
       │  (CPU/Apple)  │        │   (GPU)        │
       └──────┬────────┘        └───────┬────────┘
              │ llc                     │ ptxas
              ▼                         ▼
       ┌───────────────┐       ┌──────────────────┐
       │ 5a) 호스트 .o │       │ 5b) PTX/cubin    │
       └──────┬────────┘       └────────┬─────────┘
              └──────────────┬─────────────┘
                             ▼
            ┌──────────────────────────────────┐
            │ 6) Mojo runtime + MAX engine     │
            │    스레드풀·allocator·그래프캐시 │
            │    Python interop bridge         │
            └─────────────┬────────────────────┘
                          ▼
                ┌──────────────────────┐
                │ 7) CPU/GPU 실행      │
                │  (Eager 또는 Graph)  │
                └──────────────────────┘

4-2. 단계별 설명

단계	내용	하는 일
1	작성	Python처럼 작성, 점진적으로 fn·타입·SIMD 도입
2~3	High-level MLIR	행렬·텐서·affine 루프 의미가 살아 있어 fusion 기회 큼
4	Target-aware lowering	같은 그래프가 CPU·GPU·Apple Silicon으로 분기. @parameter로 SIMD width·tile size를 컴파일타임에 선택
5	코드 생성	CPU는 LLVM IR → 머신 코드, GPU는 PTX/SPIR-V
6	런타임	Mojo runtime이 스레드·메모리·async 관리. MAX는 그래프 컴파일 결과를 캐시해 콜드스타트 단축
7	실행	Eager(즉시) 또는 Graph(전체 그래프 컴파일) 모드. torch.compile의 fullgraph 캡처와 유사하나 사용자가 명시적으로 통제

4-3. 실제 처리 흐름 — 행렬 곱 한 줄

아래 짧은 코드가 Python 같은 외형과 시스템 언어의 동작이 어떻게 한 파일에 공존하는지 보여줍니다.

from algorithm import vectorize, parallelize
from math import sqrt

alias dtype = DType.float32
alias nelts = simdwidthof[dtype]()  # 컴파일타임에 결정

fn matmul(C: Tensor[dtype], A: Tensor[dtype], B: Tensor[dtype]):
    @parameter
    fn calc_row(m: Int):
        for k in range(A.dim(1)):
            @parameter
            fn dot[nelts: Int](n: Int):
                C.simd_store[nelts](
                    m * C.dim(1) + n,
                    C.simd_load[nelts](m * C.dim(1) + n)
                        + A[m, k] * B.simd_load[nelts](k * B.dim(1) + n),
                )
            vectorize[dot, nelts](C.dim(1))
    parallelize[calc_row](C.dim(0), C.dim(0))

핵심 트릭은 두 가지입니다 — @parameter로 인라인되는 컴파일타임 함수를 정의하고, vectorize·parallelize가 그 인라인 함수를 SIMD lane 수와 코어 수로 자동 펼칩니다. 같은 코드가 ARM에선 NEON, x86에선 AVX-512, GPU 모드에선 PTX로 lowering됩니다.

5. Mojo 설치 방법

Mojo는 Modular의 환경 매니저 magic(현재 pixi로 점진 통합)으로 설치하는 것이 표준입니다. Python·CUDA·LLVM 버전 매트릭스를 SDK가 함께 관리해야 하므로 시스템 패키지 매니저로 직접 설치하지 않는 게 권장입니다.

5-1. Linux / macOS — 권장 경로

# 1) Modular CLI 설치 (Linux/macOS, x86_64/aarch64)
curl -fsSL https://magic.modular.com | bash

# 2) 셸 재시작 후
magic --version

# 3) 새 프로젝트 생성
magic init my-mojo-app --format mojoproject
cd my-mojo-app

# 4) Mojo SDK 설치 (lockfile 기준)
magic install

# 5) Mojo 진입
magic shell
mojo --version

5-2. 단일 파일 실행 / 컴파일

echo 'fn main(): print("hello, mojo!")' > hello.mojo

# 인터프리터처럼 즉시 실행 (JIT)
mojo hello.mojo

# AOT 빌드 → 단일 바이너리
mojo build hello.mojo -o hello
./hello

5-3. GPU 사용 (NVIDIA)

pixi add cuda-toolkit=12.* mojo
pixi run mojo run gpu_example.mojo

5-4. Docker / Windows

# Docker 이미지
docker run --rm -it modular/max-openai-api:latest mojo --version

# Windows: 네이티브는 일반 가용 아님. WSL2 + Ubuntu에서 위 절차 사용

5-5. 설치 시 흔한 함정

• 오래된 libc++ — RHEL7/CentOS7에서는 사전 컴파일된 SDK가 동작하지 않음.
• Apple Silicon — macOS 14+ 필요.
• NVIDIA Driver — SDK가 요구하는 CUDA 호환 버전이어야 함.
• pip로 직접 설치 금지 — 의존성 충돌 잦음. 반드시 magic/pixi 사용.

6. Mojo 사용 방법 — 코드/설정과 운영 시 고려사항

6-1. 점진적 타이핑 — Python에서 시작해 Mojo로 진화

# step 0: pure Python — 그대로 .mojo에 넣어도 동작
def add(a, b):
    return a + b

print(add(1, 2))

# step 1: fn으로 엄격 모드 + 타입 어노테이션
fn add(a: Int, b: Int) -> Int:
    return a + b

# step 2: 제네릭 + SIMD
fn add_simd[nelts: Int](a: SIMD[DType.float32, nelts],
                        b: SIMD[DType.float32, nelts]) -> SIMD[DType.float32, nelts]:
    return a + b

6-2. Python 라이브러리 그대로 호출

from python import Python

fn main() raises:
    var np = Python.import_module("numpy")
    var arr = np.array([1.0, 2.0, 3.0, 4.0])
    print(np.sum(arr))  # NumPy가 그대로 동작

6-3. MAX로 PyTorch 모델 추론

from max.engine import InferenceSession
from max.dtype import DType

fn main() raises:
    var session = InferenceSession()
    var model = session.load("resnet50.onnx")
    var input = Tensor[DType.float32](1, 3, 224, 224)
    # ... 입력 채우기 ...
    var output = model.execute("input", input)
    print(output["logits"])

6-4. 운영 시 고려사항 — 트레이드오프 체크리스트

축	장점	유의 / 비용
성능	인터프리터 제거, MLIR fusion, GPU 1급	잘못 짠 def는 여전히 느림 — 핫패스는 fn 의무
안전성	borrow checker가 컴파일 타임에 경합 차단	Rust류 ownership 학습 곡선
호환성	NumPy/Pandas 즉시 사용	메타클래스·decorator-heavy 코드는 superset 경계 케이스
이식성	x86·ARM·Apple Silicon·NVIDIA GPU·일부 AMD	Windows 네이티브, AMD GPU, TPU는 단계적 지원
운영	MAX로 그래프 캐시, 단일 컨테이너 서빙	MAX 라이선스/컴포넌트별 OSS 진척 단계 확인 필요
생태계	stdlib + community modules 빠른 성장	PyPI 만큼은 아님. 의존성은 Python 인터럽으로 우회

"느린 def" 함정 — 모든 함수를 def로 두는 게 흔한 실수입니다. def는 Python 호환을 위해 dynamic dispatch / object box / 예외 propagate 비용이 듭니다. 핫패스에선 반드시 fn을 쓰고 인자에 타입을 주어야 컴파일러가 SIMD/inline 결정을 할 수 있습니다.

7. Mojo 자주 쓰는 명령어와 사례

7-1. 핵심 CLI

명령어	역할
mojo run hello.mojo	JIT 즉시 실행 — 스크립트 워크플로
mojo build hello.mojo -o hello	AOT 단일 바이너리 빌드 — 배포·serverless
mojo package mypkg/ -o mypkg.mojopkg	모듈 패키지 빌드 — 라이브러리 배포
mojo format file.mojo	코드 포매터 (black 류)
mojo doc	API 문서 추출 (JSON/Markdown)
mojo test	유닛 테스트 러너 — def test_* 자동 수집
mojo debug	LLDB 기반 디버거 — 네이티브 백트레이스
magic shell	SDK 환경 진입 — conda + Mojo 통합
magic add max	MAX 추론 엔진 설치
max-openai-api	OpenAI 호환 LLM 서빙 — Llama·Mistral 등 GGUF 가속

7-2. 사례 ① — MAX로 LLM 서빙 (OpenAI 호환 API)

# Llama-3 8B GGUF 모델을 OpenAI 호환 API로 서빙
magic add max
max-openai-api serve \
  --model meta-llama/Meta-Llama-3-8B \
  --quantization q4_k

# 클라이언트
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3","messages":[{"role":"user","content":"hi"}]}'

7-3. 사례 ② — 사용자 정의 GPU 커널 (벡터 합)

from gpu import thread_idx, block_idx, block_dim
from gpu.host import DeviceContext

@kernel
fn vec_add(a: DTypePointer[DType.float32],
           b: DTypePointer[DType.float32],
           c: DTypePointer[DType.float32], n: Int):
    var i = block_idx.x * block_dim.x + thread_idx.x
    if i < n:
        c[i] = a[i] + b[i]

fn main() raises:
    var ctx = DeviceContext()
    # ... 메모리 할당, 호스트→디바이스 복사 ...
    ctx.enqueue_function[vec_add](
        grid_dim=(n + 255) // 256,
        block_dim=256,
        args=(a_dev, b_dev, c_dev, n),
    )
    ctx.synchronize()

7-4. 사례 ③ — Python ↔ Mojo 점진 전환

큰 PyTorch 코드베이스 전체를 한 번에 옮길 필요가 없습니다. 핫패스(커스텀 attention·토큰 샘플러·커스텀 loss)만 .mojo로 빼고 import합니다.

# Python 측
import importlib
mojo_kernels = importlib.import_module("my_kernels")  # .mojopkg
y = mojo_kernels.fast_softmax(x)

7-5. 사례 ④ — "행렬 곱이 NumPy보다 35,000배" 데모의 의미

Modular launch 데모가 보여준 35,000× 수치는 순수 Python 3중 for 루프 대비입니다. 이미 BLAS를 호출하는 NumPy와 비교하면 차이는 한 자릿수~두 자릿수 수준입니다. 강조 포인트는 절대 배수가 아니라 "NumPy를 안 쓰고도, 한 언어로, 컴파일러가 SIMD·tile·parallel을 자동으로 깔아줘서 그 성능에 도달했다"는 것 — 즉 커스텀 커널을 같은 언어로 짤 수 있다는 신호입니다.

8. Mojo 활용 방안 — 대안 비교와 "언제 쓰면 안 되는가"

8-1. 적합한 시나리오

• 커스텀 LLM 추론 커널 — RoPE·attention·sampler를 PyTorch C++ extension 없이 같은 파일에서 작성·튜닝.
• 온디바이스 / Edge 추론 — ARM CPU·Apple Silicon용 단일 바이너리. CPython 의존 제거.
• 고처리량 데이터 전처리 — Pandas의 GIL/메모리 한계를 피해야 하는 ETL 핫패스.
• 이종 액셀러레이터 — 같은 코드를 NVIDIA/AMD/Apple로 lowering (단계적 지원).
• 학술용 컴파일러 실험 — MLIR pass를 직접 작성·삽입해 새 op fusion·새 양자화 전략 시연.

8-2. 대안 기술 비교 — "왜 굳이 Mojo인가"

대안	강점	한계	Mojo가 우월한 지점
CPython + NumPy/PyTorch	생태계 거대, 학습 곡선 낮음	GIL·op 오버헤드·두 언어 분열	한 언어로 호스트+커널, GIL 없음
Numba	Python 함수에 @jit 한 줄	타입 추론 한계, GPU 제한, 디버깅 난해	제대로 된 컴파일 언어, ownership 검사
Cython	C 호출이 자연스러움	두 파일(.pyx/.pxd)·빌드 복잡·CUDA 약함	한 파일, GPU 1급
Triton (OpenAI)	GPU 커널 DSL로 강력	호스트는 여전히 Python, 커널만 부분 가속	호스트+커널을 한 언어로 통합
JAX / XLA	function transform, autodiff 우아	Pure function 가정, dynamic Python 캡처 어려움	imperative 코드 그대로 컴파일, side effect 허용
PyTorch torch.compile	기존 코드 변경 최소	graph break 빈번, 디버깅 난해	전체 언어가 컴파일 타깃, graph break 개념 없음
C++/CUDA	최대 성능, 성숙	두 언어 분열, 빌드·바인딩 지옥	같은 언어로 같은 성능을 노림
Rust + PyO3 / candle	안전성·성능 모두 우수	Python 호환 비-1급, AI/MLIR 통합 약함	Python superset + MLIR 직접 노출
Julia	JIT, 다중 디스패치, 과학 계산	커뮤니티/배포·LLM 인프라 미성숙	Python 생태계와 직접 연결
Zig	C 대체로 깔끔, comptime	AI/MLIR/Python 통합 지향이 아님	AI 도메인 특화, 텐서/SIMD 1급

8-3. 문제 해결 + 아키텍처 + 트레이드오프 — 한 장 정리

관점	내용
해결한 문제	① Two-language problem(Python+CUDA 분열) → 한 언어. ② GIL → 제거. ③ Eager op overhead → MLIR fusion·AOT. ④ 액셀러레이터 파편화 → MLIR dialect 분기.
아키텍처 베팅	"MLIR을 사용자 언어로 끌어올린다"는 베팅. LLVM처럼 백엔드만 표준화하지 않고 dialect를 사용자 코드의 일부로 노출. AI 컴파일러 표준 IR을 점유하려는 전략적 포지션.
대가	① Modular 사 의존(현재 단계). ② OSS 전환은 stdlib(2024)부터 진행 중, 컴파일러 코어는 점진. ③ 패키지 생태계 작음. ④ 1.0 이전 — 문법·라이브러리 변동.
업계 컨텍스트	NVIDIA의 CUDA 락인, OpenAI의 Triton, AMD의 ROCm, Apple의 MLX, Google의 JAX — 모두가 같은 통증을 다른 각도로 친다. Mojo는 그 통증을 언어 차원에서 친다는 점이 차별.

8-4. 언제 Mojo를 쓰면 안 되는가

• 일반 웹/앱 백엔드 — Django/FastAPI 충분, Mojo 도입 이득 적음.
• 모델 정의·실험 단계 — PyTorch eager가 디버깅·생태계·문서 모두 우월.
• 1.0 미만 위험을 못 받는 운영 — 의료·금융 critical path는 안정 1.0과 LTS를 기다리는 편이 안전.
• CUDA 외 GPU에 즉시 광범위 지원이 필요한 경우 — AMD/Intel/TPU/Trainium은 단계적 지원이라 시점에 따라 누락 가능.
• 거대 Python 의존 그래프(SciPy 풀세트, NLTK, 비주류 OS-bound 라이브러리) — 인터럽으로 호출은 되지만 native Mojo 전환 가치는 케이스별 평가.
• 학습 인력 부족 — Rust류 ownership·SIMD·MLIR 개념을 짧은 시간에 흡수해야 함. 1명만 알면 사일로 위험.

8-5. 도메인별 도입 권장

도메인	적합도	이유
LLM 추론 사이드카	강추천	커스텀 attention·sampler·tokenizer 핫패스. MAX로 단일 바이너리 서빙
임베디드 AI / Edge	강추천	CPython 미포함, ARM/Apple Silicon 단일 바이너리
HPC 수치 계산	추천	SIMD 1급·parallelize·MLIR fusion. Fortran/C++ 대체 후보
데이터 ETL 핫패스	선별	Polars/DuckDB가 이미 강함. 비표준 변환에서만 가치
학습 파이프라인 전체	대기	backward graph·optimizer 생태계는 아직 PyTorch 우월
웹/앱 백엔드	비추	Mojo의 강점 대부분이 활용되지 않음
학술 컴파일러 연구	강추천	MLIR pass를 사용자 언어 수준에서 검증 가능한 드문 환경

9. 마치며 — "AI를 위한 Swift"는 약속을 지킬 수 있을까

2014년 Swift가 Objective-C 시대를 종료시키는 데 5년이 걸렸습니다. Mojo가 Python 시대를 종료시키지는 않을 것입니다 — Python의 생태계는 너무 거대합니다. 그러나 Mojo가 노리는 자리는 "Python의 자리"가 아니라 "Python과 CUDA C++ 사이에 끼어 있던 두 번째 언어의 자리"입니다. 그 자리는 지금 Triton·Cython·CuPy·Numba·C++ extension·Rust+PyO3가 분점하고 있고, 그 분점이 곧 AI 산업의 빌드/운영 비용입니다. Mojo가 그 자리를 통합하는 데 성공한다면, 다음 10년의 AI 시스템 코드가 어떻게 보일지에 대한 가장 강력한 후보가 됩니다.