- Python은 뛰어난 생태계 덕분에 AI에서 우위를 점하고 있지만, GIL, 동적 타이핑, 인터프리터는 성능을 저해합니다.
- MLIR 기반의 Mojo는 컴파일, 진정한 병렬화, Python 라이브러리와의 호환성을 제공합니다.
- 모듈식은 통합 가속 및 양자화를 통해 PyTorch와 TensorFlow의 런타임을 통합합니다.
- 엄청난 속도 향상(만델브로트, SIMD)이 가능합니다. 과제는 그 이점을 프로덕션과 여러 하드웨어에 적용하는 것입니다.
Mojo와 Python의 성능 논쟁이 뜨거운 이유는 현대 AI의 핵심인 실제 속도, 사용 편의성, 하드웨어 지원과 직결되기 때문입니다. 최근 몇 년 동안 이론상으로는 공상 과학처럼 들리는 가속 성능 수치들이 등장했지만, 이는 컴파일러와 CPU, GPU, AI 가속기에서 코드가 실행되는 방식의 근본적인 변화에 기반한 것입니다.
이 글에서는 파이썬, 파이썬의 성능 한계, 그리고 크리스 래트너(LLVM, Clang, Swift)가 주도하는 모듈러 기반의 언어인 Mojo의 접근 방식에 대해 다양한 출처에서 발표된 모든 내용을 종합적으로 정리했습니다. 또한 MLIR, GIL 병목 현상의 원인, CUDA와 MPS의 차이점, 파이썬 생태계와의 호환성, 그리고 앞으로 남아 있는 도입 과제에 대해서도 설명합니다.
AI는 파이썬이 주도하지만, 그 아키텍처는 성능 향상에 도움이 되지 않는다
파이썬이 인공지능의 보편적인 언어라는 것은 놀라운 일이 아닙니다 . 간단한 구문, 수천 개의 라이브러리, 수많은 튜토리얼, 그리고 거대한 커뮤니티 덕분입니다. 하지만 이러한 인기는 불편한 현실을 수반합니다. 파이썬은 인터프리터 방식 이고 동적 타입 언어이며, GIL(Global Interpreter Lock) 의 적용을 받기 때문에 순수 파이썬 코드의 동시 실행이 단일 스레드로 제한됩니다.
이러한 설계 방식은 개발 속도를 높여주지만, C/C++, Swift, Rust와 같은 컴파일 언어에 비해 속도와 메모리 효율성이 떨어집니다 . 특히 1밀리초도 중요한 머신러닝/딥러닝 작업 환경에서는 하드웨어 성능이 매우 중요하기 때문에 이러한 성능 저하가 두드러지게 나타납니다.
이를 보완하기 위해 생태계는 NumPy (C 및 Fortran으로 작성된 부분 포함), 네이티브 코드 로 위임하는 라이브러리 , 핵심 연산을 위한 C/C++ 확장 기능 등의 해결책을 사용해 왔습니다. 이러한 방식은 효과는 있지만, 여러 계층과 의존성을 야기하고, 버전, 프레임워크, 백엔드가 뒤섞인 프랑켄슈타인 같은 구조를 만들어 프로덕션 환경에서 유지 관리가 까다로워질 수 있습니다.
또한, 파이썬의 병렬 처리는 종종 멀티프로세싱이나 라이브러리가 네이티브 섹션에서 GIL을 해제하는 방식에 의존합니다. 결과적으로, 작업 부하가 C/C++ 또는 GPU에 잘 분산되지 않는 한, 파이썬의 순수 성능이 병목 현상이 됩니다.
NumPy 및 기타 "패치": 필수적이지만 제한 사항이 있음
NumPy는 대표적인 예입니다. NumPy의 핵심 연산 대부분은 C나 Fortran 으로 작성되어 순수 Python보다 훨씬 빠릅니다. 그러나 정밀한 병렬 처리, 멀티 코어 확장, 또는 새로운 가속기와의 통합과 관련해서는 Python의 한계가 다시 드러나는데 , 특히 제어 흐름이 인터프리터로 자주 돌아올 때 더욱 그렇습니다.
이러한 계층적 접근 방식(Python → C/C++ 확장 → 드라이버/하드웨어)은 효과적이지만 디버깅 및 배포가 복잡합니다 . 학습, 추론 및 후처리 파이프라인을 갖춘 대규모 AI 환경에서는 이러한 운영 복잡성이 가용 FLOPS만큼이나 중요한 요소입니다.
CUDA, MPS 및 이식성 문제
CUDA 가속 (NVIDIA) 은 매우 유용하지만, 동시에 제약이 따르기도 합니다. 일부 모델과 최적화는 NVIDIA 스택에 전적으로 의존하기 때문입니다. 동일한 코드를 Metal Performance Shaders(MPS)가 탑재된 Apple Silicon 이나 AMD GPU 에서 실행하려고 하면 지원되지 않는 명령어 나 불완전한 연산 경로 오류가 발생할 수 있습니다 .
가장 흔한 비교는 명확합니다. CUDA를 사용하면 마치 "페라리"를 운전하는 것과 같다고 하는 반면, MPS는 특정 작업 부하에서 다소 제한적인 느낌을 줄 수 있습니다. 그럼에도 불구하고 업계는 표준화와 이식성을 향해 나아가고 있는데 , 이는 누구도 꼭 필요한 경우가 아니라면 특정 하드웨어 공급업체에 사업을 종속시키고 싶어하지 않기 때문입니다.
MLIR: 새로운 컴퓨팅 시대에 필요한 다리
Mojo가 제안하는 내용을 이해하려면 LLVM 생태계 내에서 탄생한 프로젝트인 MLIR(Multi-Level Intermediate Representation) 에 대해 이야기해야 합니다. MLIR은 고성능 및 머신 러닝을 위해 설계된 중간 표현을 추가합니다 . 기존 LLVM 파이프라인과 달리 MLIR은 데이터 그래프, 벡터화, 테셀레이션, DMA 삽입 및 명시적 캐시 관리를 처리합니다.
쉽게 말해, MLIR은 고수준 코드를 대상 하드웨어(CPU, GPU, TPU, NPU, FPGA 등)에 매우 가까운 구현으로 변환할 수 있게 해주고, 기존 컴파일러가 이러한 영역에서 제대로 지원하지 못했던 병렬 처리 및 HPC 최적화를 적용할 수 있게 해줍니다.
모조란 정확히 무엇인가요?
Mojo는 파이썬의 상위 집합 으로 여겨지는 언어입니다 . 익숙한 구문을 유지하고, 동일한 라이브러리를 활용할 수 있으며, MLIR에서 지원하는 최신 컴파일 모델을 통합하고 있습니다. 2023년에 처음 출시되었으며, 초기에는 필요에 따라 접속할 수 있는 웹 플레이그라운드 형태로 제공되었고 , 이후 GNU/Linux 및 macOS에서 로컬 실행이 가능해졌습니다. 2025년 2월에는 표준 라이브러리가 오픈 소스로 공개되었지만, 컴파일러는 현재까지도 비공개로 유지되고 있습니다.
목표는 야심찹니다. 파이썬의 단순함에 C/C++의 성능을 더하고, Rust나 Swift 같은 언어에서 볼 수 있는 보안성과 사용자 친화성을 갖추는 것입니다. 다시 말해, 고수준의 코드로 작고 빠르며 배포하기 쉬운 바이너리를 생성하는 것입니다.
디자인 키: 타이핑, 메모리, 구조체 및 함수
가장 눈에 띄는 특징으로는 강력한 타입 지정 (필요한 경우 정적 타입 지정 포함), 불변 및 가변 요소를 선언하기 위한 let/var 사용, 그리고 컴파일 정의 디자인을 가진 구조체 지원 등이 있으며, 이는 최적의 기계어 코드 생성을 용이하게 합니다.
Mojo는 `def` 외에도 `fn`을 사용하여 함수를 선언할 수 있도록 합니다 . 일반적으로 `fn`은 더 많은 제약 조건을 내포하므로 컴파일러 최적화에 더 유리 합니다. 또한 "제로 코스트 추상화" 및 자체 튜닝 기능을 자랑하며 , 컴파일러가 대상 플랫폼에 맞는 효율적인 매개변수를 자동으로 선택합니다.
GIL 없이 실제 병렬화 사용
파이썬과 달리 Mojo는 GIL( Global Interpreter Lock) 에 의존하지 않습니다 . 런타임과 컴파일러는 개발자가 인터프리터의 기본적인 병렬 처리 문제를 신경 쓰지 않고도 스레드, 벡터, 가속기를 활용할 수 있도록 설계되었습니다 . 실제로 이는 파이썬에서 GIL에 걸리는 작업들이 Mojo에서는 진정한 병렬 처리가 가능하다는 것을 의미합니다.
이 점은 고성능 컴퓨팅에서 매우 중요합니다. 문제를 하위 작업으로 분해하고 이를 네이티브 방식으로 동시에 실행할 수 있다면 성능 향상은 점진적인 것이 아니라 완전히 새로운 차원으로 도약할 수 있습니다.
성능: Mandelbrot에서 벡터화된 버전까지
성능 향상을 측정하기 위해 반복적으로 사용되는 테스트는 병렬 처리에 적합한 계산 집약적인 프랙탈 생성기인 만델브로트 집합입니다. 순수 파이썬으로 구현했을 때는 1000초가 넘는 시간이 보고되었지만, Mojo를 사용한 구현은 여러 차례 최적화를 거쳐 약 0,03초 까지 단축되었습니다.
다음과 같은 개선 과정이 기록되어 있습니다: 단순 파이썬 버전 → 넘파이 → 단순 모조 버전 → SIMD를 사용한 벡터화된 모조 . 이러한 개선 파이프라인을 통해 최대 35.000배에서 특정 시나리오에서는 최대 68.000배에 이르는 엄청난 속도 향상이 관찰되었습니다. 이러한 놀라운 수치는 항상 그렇듯이 알고리즘, 하드웨어, 그리고 최적화에 쏟는 노력에 따라 달라집니다.
간단한 컴파일 및 배포
Mojo는 바이너리 빌드 방식을 따릅니다 . 빌드하면 실행 파일이 생성되고, 이를 배포하면 됩니다 . 파이썬 사용자라면 가상 환경 , 휠 파일 , 그리고 호환성이 떨어지는 라이브러리 버전 조합으로 인한 골칫거리를 피할 수 있다는 장점이 있습니다.
예를 들어, "Hello World"는 간단한 mojo 파일인 hello.mojo 로 컴파일하고 실행할 수 있습니다 . 또한, 이 파일들은 .mojo 확장자를 가지고 있어 (불꽃 이모티콘이 윙크를 나타내는 데에도 널리 사용되고 있습니다), 하이브리드 프로젝트 내에서 쉽게 식별할 수 있습니다.
Python 호환성 및 생태계
Mojo의 매력 중 하나는 기존에 가지고 있는 것을 버리도록 강요하지 않는다는 점입니다 . 파이썬 생태계와의 호환성 덕분에 NumPy, Pandas, Matplotlib 같은 라이브러리를 계속 사용하면서 필요에 따라 더 효율적인 구조와 데이터 유형을 채택할 수 있습니다.
실제로 이러한 "Python++" 전략은 도입 곡선을 완만하게 만듭니다. 기존 코드베이스를 유지하고 , 자주 사용하는 부분을 Mojo로 옮기고, 컴파일러와 MLIR을 활용하여 익숙한 구문을 버리지 않고 성능을 극대화할 수 있습니다.
모듈식: PyTorch와 TensorFlow를 통합하는 런타임
Modular는 언어 외에도 PyTorch와 TensorFlow 스택을 모두 설치할 필요 없이 두 모델을 실행할 수 있는 범용 프레임워크/런타임을 도입했습니다. 소식통에 따르면, Modular의 아키텍처는 TensorFlow 실행 속도를 최대 3배 , PyTorch 실행 속도를 최대 2,5배 까지 향상시킬 수 있으며, 양자화 도구를 통합하여 AI 확장성에 기여합니다.
우리의 비전은 단일 프로그래밍 계층과 모든 하드웨어와 통신 하고 매일 모델을 다시 작성하지 않고도 모든 플랫폼에서 최상의 성능을 끌어낼 수 있는 백엔드를 통해 "3계층 구조의 지옥"(Python → C/C++ → 특정 하드웨어) 을 피하는 것입니다.
양자화: 정확도를 희생하지 않고 크기를 줄이는 것
모델 양자화는 신경망을 위한 MP3 파일과 같습니다. 특정 가중치/레이어의 정확도를 낮추는 대신, 모델 크기를 줄이고 추론 속도를 향상 시킵니다 . 정확도 손실은 일반적으로 미미하며(예: 분류기에서 94%에서 91%로 감소), 배포 및 속도 향상이라는 이점이 이를 충분히 상쇄합니다.
이러한 접근 방식은 개인 정보 보호를 존중하면서 모델을 로컬 기기 로 가져오는 데 핵심적입니다 . 실제로 Core ML 과 같은 스택과 Apple의 NPU (MPS/Accelerate를 통해)와 같은 가속기는 데이터를 클라우드로 전송하지 않고도 iPhone이나 Mac에서 원활하게 실행되는 압축 모델을 지향하고 있습니다.
TensorFlow를 위한 Swift에서 Mojo까지: Lattner의 여정
이 지점에 도달하기까지의 과정은 우연이 아닙니다. 애플(LLVM, Clang, Swift ) 에서 근무한 후 , 크리스 래트너는 테슬라와 구글 브레인에서 일하며 텐서 플로우용 Swift 개발을 주도했습니다 . 현대 언어와 머신러닝을 결합하려는 이 시도는 결국 무산되었지만, 그 과정에서 얻은 교훈은 현재 MLIR과 Mojo 설계에 고스란히 반영되었습니다.
Modular 프로젝트 이전에 Lattner는 RISC-V (SciFive) 분야 에도 손을 댔는데 , 이는 미래의 AI는 다양한 유형의 하드웨어를 포함하며 이러한 모든 하드웨어에 빠르게 적응할 수 있는 컴파일러와 런타임이 필요하다는 생각과 일맥상통합니다.
프로젝트 상태, 지원 및 채택
Mojo는 2023년에 출시되었으며, 빠르게 발전하고 있지만 여전히 성숙 단계 에 있습니다 . 표준 라이브러리는 2025년 2월에 공개되었지만 컴파일러는 여전히 비공개입니다 . 인기도(TIOBE 지수) 측면에서 Mojo는 상위 50위권 밖에 있는데, 출시된 지 2년밖에 안 된 언어임을 감안하면 당연한 결과입니다.
"주요 참여 기업" 섹션에서는 아마존, AMD, NVIDIA, Inworld 등 의 지원이 언급되었습니다 . 하지만 파이썬과 경쟁하려면 커뮤니티, 문서, 패키지, 그리고 다른 기업들의 벤치마크가 될 만한 실제 사용 사례들이 필요할 것입니다.
과제: 커뮤니티, 반성 및 역동적 특성
성능 외에도 파이썬은 커뮤니티, 리소스 및 생태계 측면에서 우위를 점합니다 . Mojo는 특정 리플렉션 메커니즘이나 널리 사용되는 동적 패턴 과 같이 파이썬이 강점을 보이는 영역에서 격차를 줄여야 할 것입니다 . 또한 파이썬에서 Mojo로의 전환이 완전히 매끄럽게 이루어지도록 사용자 친화성을 지속적으로 개선해야 합니다.
기술적인 관점에서 " 모든 것을 위한 컴파일 " 이라는 약속은 매우 매력적이지만, 각 백엔드(CUDA, ROCm, MPS, TPU, FPGA 등)는 저마다 미묘한 차이가 있습니다. 런타임에서 모든 백엔드에 걸쳐 일관된 기능 과 성능을 유지하는 것은 단거리 경주가 아니라 마라톤과 같습니다.
Mojo와 GPU: NVIDIA를 넘어서
Mojo와 MLIR의 강점 중 하나는 CUDA 생태계뿐만 아니라 NVIDIA와 AMD의 GPU 모두를 대상으로 서비스를 제공 할 수 있다는 점입니다 . 이러한 지원이 최신 상태를 유지하고 경쟁력을 갖춘다면, 많은 기업들이 특정 벤더에 종속되지 않는다는 전략적 이점을 누릴 수 있을 것입니다.
동시에, 애플 환경( MPS 사용 )과 기타 특수 가속기(NPU, FPGA )는 적절한 컴파일 경로와 라이브러리를 요구합니다. "한 번 작성하면 어디서든 빠르게 실행된다"는 약속은 야심차지만, 제대로 구현된다면 판도를 바꿀 만한 혁신이 될 것입니다.
토론: 새로운 언어인가, 아니면 "Python++"인가?
기술 포럼에서는 Mojo가 "파이썬의 또 다른 변형"인지 아니면 구문만 공유하는 새로운 언어 인지에 대한 논쟁이 있습니다 . 일상적인 사용에 있어 중요한 점은 코드와 라이브러리를 재사용 하면서 동시에 더 풍부한 데이터 유형과 구조를 사용하여 성능 향상 요소를 작성할 수 있다는 것입니다.
이러한 이중성은 최신 MLIR 컴파일러와 결합되어 "hello world"를 사용자 친화적으로 만들면서도 벡터화된 시나리오에서 컴퓨팅 커널이 C/C++의 성능에 근접하거나 심지어 능가할 수 있도록 합니다.
리소스, 커뮤니티 및 학습
인공지능 분야에 처음 발을 들여놓는다면, 개방형 학습 커뮤니티는 매우 귀중한 자산입니다. 학생과 교사 모두를 위한 이러한 공간은 질문하고, 자료를 공유하고, 기초부터 고급 기술까지 발전해 나갈 수 있는 기회를 제공합니다. 또한, 연습하고, 다양한 접근 방식을 비교하고, 실제적인 해답을 얻기에 더할 나위 없이 좋은 곳입니다.
전문가들(예: 제레미 하워드)의 모조 출시 요약 영상부터 비용 부담 없이 코딩을 배울 수 있는 무료 파이썬 강좌까지, 다양한 홍보 활동이 모조 도입에 도움이 됩니다 . 모조를 둘러싼 커뮤니티가 강해질수록 기업과 개발자들이 모조를 더 쉽게 채택할 수 있을 것입니다.
실용적인 노트와 흥미로운 세부 사항
사소하지만 중요한 편의성을 제공하는 디테일들이 모여 큰 차이를 만들어냅니다. 예를 들어 .mojo 파일 , fn / def 지원 , mojo 명령어를 이용한 직접 실행 , 배포가 용이한 바이너리 제공을 명시적으로 고려하는 것 등이 있습니다 . 이러한 것들은 평범해 보이지만 프로젝트 규모가 커질수록 그 차이가 더욱 두드러집니다.
동시에 타입 설계, 메모리 안전성, 제로 코스트 추상화에 대한 Rust와 Swift 의 영향력을 인정해야 합니다 . 이는 우연이 아닙니다. Lattner는 Swift를 개발하고 LLVM/Clang을 관리했던 경력이 있으며, 이러한 배경은 컴파일러 설계에 분명하게 드러납니다.
연구실에서 생산까지: 기대할 수 있는 것
오늘 Mojo를 사용해 보려면 연산 커널, 고강도 변환 또는 반복문과 같은 핵심 모듈 에서 사용하는 것이 좋습니다. 오케스트레이션 및 툴링은 Python으로 유지하고, 사용량이 많은 구성 요소를 Mojo로 마이그레이션하여 실제적인 성능 향상을 측정해 보세요.
분석된 보고서에 따르면, 만델브로트 유형 작업이나 SIMD 커널은 엄청난 속도 향상을 달성했습니다 . 실제 파이프라인에서는 I/O, 전처리 및 타사 라이브러리를 사용하더라도 상당한 성능 향상을 확인할 수 있지만, 그 정도는 더 미미하고 주요 병목 현상에 따라 달라집니다.
통합된 계층: "프랑켄스택"과의 작별
모듈형 스택의 핵심적인 장점은 계층 통합입니다. 분산된 Python + C/C++ + 특정 백엔드 대신, 세 가지 계층 모두에 단일 언어를 제공하고 하드웨어와 상호 작용하는 런타임을 제공합니다 . 이를 통해 계층 간 연결이 줄어들고, 호환성 문제가 감소하며, 유지보수 부담도 줄어듭니다.
이러한 비전이 실현된다면, 학습 및 추론 프로세스는 프로젝트를 완전히 재프로그래밍할 필요 없이 NVIDIA, AMD, Apple Silicon, TPU 또는 NPU 간에 자유롭게 이동할 수 있게 됩니다. 이는 단순한 기술적 세부 사항을 넘어, 비용, 가용성 또는 에너지 효율성을 기준으로 하드웨어를 선택할 수 있는 비즈니스 전략 이기도 합니다.
음성 모델 및 전사에 대한 참고 사항
실제 구현에서, Whisper (전사)와 같은 모델을 Python에서 네이티브 경로 또는 다른 API(MPS/Accelerate)로 포팅할 때 호환성 문제가 발생합니다. 특정 명령어가 CUDA에는 있지만 MPS에는 없거나, 그 반대의 경우도 있습니다. 이러한 문제를 해결하기 위해 통합 백엔드 와 MLIR을 지원하는 컴파일러가 매우 유용합니다.
공통된 연결 고리가 없으면 코드 분기 와 수동 포팅이 발생하여 프로젝트 발전 속도가 느려집니다. 하지만 이를 활용하면 한 번만 코드를 작성하여 지원되는 모든 플랫폼에서 효율적인 라우팅을 구현할 수 있습니다.
"메타" 컨텍스트: 홍보, 후원 및 기술 커뮤니티
이 논쟁에 불을 지피는 자료 중 일부는 교육 콘텐츠와 스폰서십, 커뮤니티(심지어 상품 판매까지)를 결합한 팟캐스트와 기술 블로그 에서 비롯됩니다. (강좌, 앱, 트위치, 배경 음악, 팟캐스트 네트워크 지원 등) 일화적인 사례를 넘어 흥미로운 점은 이러한 기술적 논쟁이 특정 분야에 국한되지 않고 광범위한 청중에게 공감을 불러일으키고 있다는 것입니다.
그러한 소음은 긍정적인 것입니다. 어려운 질문, 실제 사용 사례 , 다양한 하드웨어에 대한 경험을 제공하기 때문입니다. MLIR 및 Mojo에 대한 논의 범위를 넓히면 버그 발견, 마이그레이션 가이드, 그리고 우리 모두가 재사용할 수 있는 레시피 제작이 가속화됩니다.
전반적인 상황은 명확합니다. 파이썬은 앞으로도 AI의 관문 역할을 하겠지만 , 성능이 최우선인 경우에는 이미 실용적인 대안이 존재합니다. Mojo는 파이썬을 대체하려는 것이 아니라, 최신 컴파일러 , 진정한 병렬 처리, 그리고 현재와 미래의 가속기를 모두 이해하는 런타임 레이어를 통해 파이썬의 성능을 향상시키는 것을 목표로 합니다. 머신러닝/딥러닝 분야에서 추론이나 학습 에포크당 시간/비용이 중요한 개발자라면, 자신의 데이터와 하드웨어로 Mojo를 사용해 볼 가치가 있습니다.
