Mojo 1.0 베타

(mojolang.org)

3P by GN⁺ 6시간전 | ★ favorite | 댓글 1개

Mojo는 “Python처럼 쓰고, C++처럼 실행”하는 언어를 표방하며, 현재 안정 버전으로 1.0.0b1 (May 7) 을 제공함
CPU부터 GPU까지 다양한 하드웨어에서 빠른 코드를 작성하되 특정 벤더에 종속되지 않는 것을 목표로 하며, 현대 AI 시스템을 위한 고성능 정적 타입 언어로 설계됨
Python 상호운용을 네이티브로 지원해 기존 코드를 전부 다시 쓰지 않고 성능 병목만 Mojo로 옮길 수 있으며, Mojo 코드의 Python import와 Python 라이브러리 import를 모두 지원함
같은 언어로 GPU 커널을 작성할 수 있고, 런타임 코드와 같은 언어를 쓰는 컴파일 타임 메타프로그래밍으로 하드웨어별 최적화와 비용 없는 추상화를 제공하려 함
Mojo 표준 라이브러리는 GitHub에서 완전 오픈소스로 공개되어 기여를 받고 있으며, Mojo 컴파일러는 2026년 오픈소스화를 계획함

버전과 시작 자료

현재 안정 버전은 1.0.0b1 (May 7), 최신 nightly는 May 9임
Mojo는 Python의 직관적 문법, Rust의 메모리 안전성, Zig의 강력하고 직관적인 컴파일 타임 메타프로그래밍에서 영감을 받음
컴파일되는 정적 타입 언어로서 에이전트형 프로그래밍에도 적합함
생산성과 성능 중 하나를 고르는 대신 둘 다 제공하는 것을 목표로 하며, 단순하고 익숙한 프로그래밍 패턴으로 시작해 필요할 때 복잡도를 추가할 수 있음
시작 경로로 Install Now, Quickstart, Releases, Roadmap, GitHub가 제공됨
Markdown으로 페이지를 보려면 URL에 .md를 붙일 수 있고, 전체 Mojo 문서 인덱스는 llms.txt에서 확인 가능함

GPU와 Python 상호운용

GPU 프로그래밍

Mojo는 벤더별 라이브러리나 별도 컴파일 코드 없이 GPU 프로그래밍에 접근할 수 있게 만드는 것을 목표로 함
CPU에 쓰는 동일한 언어로 고성능 GPU 커널을 작성할 수 있음

예시 커널 vector_add는 TileTensor를 받아 global_idx.x를 기준으로 result[i] = a[i] + b[i]를 수행함

def vector_add(  
    a: TileTensor[float_dtype, type_of(layout), element_size=1, ...],  
    b: TileTensor[float_dtype, type_of(layout), element_size=1, ...],  
    result: TileTensor[  
        mut=True, float_dtype, type_of(layout), element_size=1, ...  
    ],  
):  
    var i = global_idx.x  
    if i < layout.size():  
        result[i] = a[i] + b[i]

Python 상호운용
- Mojo는 Python과 네이티브로 상호운용되며, 기존 코드를 전부 다시 쓰지 않고 성능 병목을 제거할 수 있음
- 하나의 함수에서 시작해, 필요에 따라 성능이 중요한 코드를 Mojo로 옮기는 방식으로 확장할 수 있음
- Mojo 코드는 Python에 자연스럽게 import되고 배포용 패키지로 함께 묶일 수 있음
- 반대로 Mojo 코드 안에서 Python 생태계의 라이브러리를 import할 수도 있음
- 예시 함수 mojo_square_array는 PythonObject의 ctypes.data에서 포인터를 얻고, SIMD 폭을 컴파일 타임에 계산해 배열 원소를 제곱함
```
# SIMD-vectorized kernel squaring array elements in place.  
def mojo_square_array(array_obj: PythonObject) raises:  
    comptime simd_width = simd_width_of[DType.int64]()  
    ptr = array_obj.ctypes.data.unsafe_get_as_pointer[DType.int64]()  
    def pow[width: Int](i: Int) unified {mut ptr}:  
        elem = ptr.load[width=width](i)  
        ptr.store[width=width](i, elem * elem)  
    vectorize[simd_width](len(array_obj), pow)  
```

컴파일 타임 메타프로그래밍

Mojo의 메타프로그래밍은 런타임 코드와 같은 언어를 사용해 성능을 극대화하는 직관적 시스템을 제공함
조건부 컴파일로 하드웨어별 최적화를 만들고, 컴파일 타임 평가로 메모리 안전성을 보장하며, 비용이 큰 런타임 분기를 제거할 수 있음
의도를 명확히 드러내면서 비용 없는 추상화를 제공하는 것이 목표임

예시 __eq__ 구현은 컴파일 타임 리플렉션으로 구조체 필드 이름과 타입을 얻고, 모든 필드가 Equatable을 만족하는지 검사한 뒤 필드별 equality를 수행함

# Generic struct equality using compile-time reflection.  
@always_inline  
def __eq__(self, other: Self) -> Bool:  
    comptime r = reflect[Self]()  
    comptime names = r.field_names()  
    comptime types = r.field_types()  
    comptime for i in range(names.size):  
        comptime T = types[i]  
        comptime assert conforms_to(T, Equatable), "All fields must be Equatable"  
        if trait_downcast[Equatable](  
            r.field_ref[i](self)  
        ) != trait_downcast[Equatable](r.field_ref[i](other)):  
            return False  
    return True

로드맵과 오픈소스

Mojo는 2022년 말에 시작됐고, 아직 해야 할 일이 많음
Phase 0
- 초기 기반 구축 단계
- 핵심 파서, 메모리 타입, 함수, 구조체, 초기화자, 인자 규약, 기타 언어 기반을 구현하는 단계임
Phase 1
- 현재 진행 중인 단계
- CPU, GPU, ASIC에서 고성능 커널을 작성하기 위한 강력하고 표현력 있는 언어로 만들고, 개발자가 Python을 매끄럽게 확장할 수 있게 하는 것이 목표임
Phase 2
- 시스템 애플리케이션 프로그래밍 단계
- 보장된 메모리 안전성 모델과 시스템 프로그래밍 개발자가 기대하는 더 많은 추상화 기능을 지원하도록 확장하는 단계임
Phase 3
- 동적 객체 지향 프로그래밍 단계
- Python 코드와의 호환성을 최대화하기 위해 클래스, 상속, 타입 없는 변수 같은 Python의 동적 기능을 더 많이 지원하는 단계임
- 자세한 내용은 Mojo roadmap에서 확인 가능함
- Mojo 표준 라이브러리는 GitHub에서 완전 오픈소스로 공개되어 있으며 기여를 받고 있음
- Mojo 컴파일러는 2026년에 오픈소스화할 계획임
- Mojo 전체를 오픈소스화하겠다는 방침이 있지만, 언어가 아직 매우 젊기 때문에 공통 비전을 가진 밀접한 엔지니어 그룹이 커뮤니티 주도 방식보다 더 빠르게 움직인다고 판단함
- 참여 경로로 developer community가 제공됨

학습 및 커뮤니티 자료

Install 및 Quickstart guide: Mojo 시작 자료
Beginner tutorial: Game of Life를 만들며 Mojo 학습
GPU puzzles: 퍼즐을 풀며 Mojo로 GPU 프로그래밍 학습
Intro to Mojo: Mojo 언어 기능 전반 소개
Developer forum: Mojo 관련 질문과 업데이트
Events: 이벤트, 밋업, 발표, 해커톤 안내
Contributions: 열린 이슈, 문서 기여, 프로젝트 공유 안내

▲

GN⁺ 6시간전 [-]

Hacker News 의견들

지난 2년간 재미로 Mojo를 많이 써봤는데, 정말 멋진 언어임
Rust에 가까운 소유권 모델, Zig보다 강력한 컴파일 타임 실행, 풍부한 타입 시스템, 일급 SIMD 지원 등이 있음
성능 면에서도 오랜만에 단순한 LLVM 래퍼가 아닌 언어처럼 보임. LLVM은 여전히 쓰지만 Rust나 Zig와는 다른 방식으로 활용함
올해 말 오픈소스가 되면 Mojo가 매우 기대됨
- “Zig보다 강력한 컴파일 타임 실행”이라는 부분을 좀 더 설명해주면 좋겠음
  지금 Mojo 문서만 봐서는 그 결론에 도달하기 어려움
머신러닝을 하면서 성능에 관심 있는 입장에서는 Mojo가 성공하길 바람. 특히 같은 언어에서 GPU 코드와 CPU 코드를 섞을 수 있다는 점이 기대됨
다만 지금의 변화가 Python 개발자들을 멀어지게 만들지 걱정됨. 마지막으로 실행해봤을 때 기본적인 문자열 조작을 테스트하려고 var x = 'hello'; print(x[3])를 해봤는데 동작하지 않았고, len(x)도 안 돼서 한 시간을 헤맸음
알고 보니 바이트와 코드포인트 표현을 더 구체적으로 나누기로 한 것이었는데, 문서가 실제 구현과 모순됐음
일반적인 머신러닝에도 쓸 만한 상태가 되길 바라지만, 현재는 아직 꽤 제한적으로 느낌. Tensor 관련 괜찮은 기본 기능들도 일부 폐기했음
당분간은 JAX를 쓰면서 가끔 확인해볼 생각임
- 단순한 계산 중심 코드를 최소한의 추가 문법만으로 SIMD / 멀티스레드 / 멀티프로세싱 / GPU 코드로 바꿔주는 언어가 왜 아직 없는지 모르겠음
  이런 건 컴파일러와 언어 설계에 관심 있는 사람들이 꿈꿀 만한 일 아닌가 싶음
  어떤 상황에서도 효율을 보장하거나 최첨단 성능을 낼 필요는 없고, 그냥 존재하기만 해도 좋겠음
  이런 언어를 만들 수는 있다고 이해하지만, 만들 수 있는 사람의 흥미를 끌지 못한 것 같음
- Mojo는 멋지지만 Python 하위 호환성을 왜 붙잡는지 모르겠음. 그 때문에 스스로 발목을 잡고 있음
  Kotlin에서 떠오르는 단점들은 거의 Java 호환성 때문임. 여기서는 더 명시적인 방식으로 잘 풀 수도 있었겠지만, 현재 방식은 실패할 운명처럼 보임
- 오픈소스가 아니라면 별 의미 없음. 대부분의 Python 개발자는 어차피 오지 않을 것임
- 이 측면에서는 거의 Nim 프로그래밍 언어를 다시 만들려는 것처럼 보임
“Mojo를 2026년 가을에 오픈소스로 공개하겠다고 약속했다”고 되어 있음
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
- 실제 최첨단 MLIR 프로그램의 소스 코드를 볼 수 있다면 좋겠음
안타깝게도 그 사이 Nvidia도 가만히 있지 않았고, MLIR 기반의 비슷한 컴파일러 스택을 통해 Python용, 곧 C++용 CuTile이라는 차세대 CUDA를 만들었음
이식성은 없더라도 Nvidia가 강하게 밀고, 개발 도구에 통합되며, 기존 CUDA 코드와 함께 동작한다는 이유만으로 Mojo보다 훨씬 많이 쓰일 가능성이 큼
Tile IR은 Mojo보다는 Triton의 위협에 대한 대응에 가까웠을 가능성이 큼. 적당히 성능 나오는 LLM 커널을 얼마나 쉽게 작성할 수 있느냐는 관점에서 특히 그렇다고 봄
- 뒤처지지 않기 위해 Intel과 AMD도 비슷한 노력을 하고 있고, CPython JIT도 여러 번의 시도 끝에 드디어 현실화되고 있음
  GraalPy와 PyPy 같은 시도도 있음
  이런 노력들은 모두 현재 Windows에서 동작함. 회사에서 직원 대부분에게 Windows 장비가 배정되고 서버만 Linux 배포판을 쓰는 환경에서는 꽤 중요함
  이게 또 다른 Swift for Tensorflow 같은 결말이 되지 않을까 계속 생각하게 됨
- 몇몇 Tile IR 개발자들과 이야기해본 바로는, 주된 동기는 PTX보다 텐서 코어 프로그래밍의 이식성을 더 잘 제공하는 것이었음
  고객 피드백 외에 무언가에 대한 대응이라고 말한 사람은 없었음
- 사람들이 Mojo를 GPU 코드를 쓰기 좋은 문법 정도로 착각하고, Nvidia의 Python 프레임워크가 이미 그 역할을 한다고 생각하는 경우가 많음
  하지만 CuTile이 AMD GPU나 Apple Silicon에서도 동작할까? Nvidia가 뭘 하든 여전히 벤더 종속은 남음
- CuTile의 영향력이 얼마나 큰지 궁금함
처음 Mojo를 들었을 때는 기존 Python 코드와 호환되게 만들려는 줄 알았음
하지만 가까운 미래에는 그 목표와 매우 멀어 보임. Python과 Mojo 사이를 오가며 호출할 수는 있겠지만, Mojo 자체가 기존 Python 코드를 실행할 수는 없음
- 원래 홍보에서는 분명 그게 핵심 중 하나였음. Python 코드에 타입 힌트를 추가하면 큰 속도 향상을 얻는다는 식이었음
  하지만 실제로 만들어가면서 방향이 달라진 것처럼 보임
- 기억이 맞다면 동등한 Python 대비 36,000배 속도 향상도 광고했는데, 극단적인 엣지 케이스에서만 가능하다는 점을 전혀 명확히 하지 않았음
  Python 생태계를 개선하려는 정직한 시도라기보다는 펌프 앤 덤프식 암호화폐 계획처럼 느껴짐
- 아주 주의 깊게 봤다면 처음부터 아이디어는 차세대 시스템 언어를 만드는 것이었음이 분명했음
  Swift와 Rust의 교훈을 가져오고, CPU/GPU/이기종 타깃을 겨냥하며, MLIR을 중심에 둔 언어였음
  동시에 언젠가 Python을 비교적 쉽게 임베드하거나 확장할 수 있게 염두에 둔 구조였고, Python 프레이밍은 자금 조달에 거의 확실히 도움이 됐을 것임
  Chris Lattner는 Python과 Mojo의 관계보다 MLIR과 Mojo의 관계를 더 많이 이야기했음
- 원래 광고는 그랬음. Python에 대한 Kotlin 같은 존재가 되고 싶어 했지만 금방 방향을 틀었음
  그 점과 완전히 오픈소스가 아닌 개발 모델 때문에 항상 베이퍼웨어처럼 느껴졌음
- 사이트에는 이렇게 되어 있음
  Python 상호운용성: “Mojo는 Python과 네이티브로 상호운용되므로 모든 것을 다시 작성하지 않고도 기존 코드의 성능 병목을 제거할 수 있습니다. 함수 하나에서 시작해 필요에 따라 성능이 중요한 코드를 Mojo로 옮기며 확장할 수 있습니다. Mojo 코드는 자연스럽게 Python으로 임포트되고 배포용으로 함께 패키징됩니다. 마찬가지로 Python 생태계의 라이브러리를 Mojo 코드로 임포트할 수 있습니다”
Mojo는 괜찮아 보이지만, CPU와 GPU를 아우르는 고성능 수치 계산에서는 지금 Julia에 꽤 만족함
Python 같은 문법을 제외하면 이 틈새는 이미 대부분 해결된 느낌임. Python조차 Numba와 Triton처럼 덜 복잡하고 더 독립적인 유형의 문제에 효과적인 도구들이 있음
같은 목적이라면 Julia가 더 성숙했고, 작년부터 Nvidia는 CUDA에서 Python 도구와 C++ 도구의 기능 동등성을 맞추고 있음
Python cuTile JIT 컴파일러를 쓰면 순수 Python처럼 CUDA 커널을 작성할 수 있음
AMD와 Intel도 비슷한 접근을 따라가고 있음
Mojo가 더 넓은 채택을 얻을 만큼 제때 도착할지는 아직 봐야 함
- Python cuTile JIT 컴파일러가 순수 Python으로 CUDA 커널을 작성하게 해준다는 말은 맞지 않음. 현재도 순수 Python이 아니고 앞으로도 그럴 수 없음
  이런 “성능 친화적” Python 방언들, 즉 Triton, Pythran, CuTile, Numba, Pycell, cuPy 등은 겉보기에는 Python 같지만 표면만 긁어도 전혀 Python이 아님
  최적화와 타입 추론이 잘 되도록 만들어진 Python풍 DSL임. 실제로 써보면 그렇게 느껴짐. 각각에서 많은, 어쩌면 대부분의 Python 기능을 사용할 수 없는데도 Python 고유의 문제는 여전히 감수해야 함
  솔직히 Python은 효율과 성능에 본질적으로 좋지 않음
  이건 GIL을 훨씬 넘어서는 문제임. 동적 타이핑, 참조 의미론, 몽키 패치, 극도로 동적인 객체 모델, CPython ABI, 기본 BigInt, 런타임 모듈 시스템 등은 작은 스크립팅 언어에는 말이 되지만 고성능 컴퓨팅과 효율에는 매우 나쁨
  NumPy/SciPy 생태계 자체도 단순한 CPU 바운드 텐서 산술을 위해 Python의 한계를 우회하는 해킹에 가까움
  기본 Python 성능이 너무 나빠서 단순한 for 루프조차 Excel을 경주마처럼 보이게 만들기 때문임
  Mojo는 다름
  Mojo는 기존의 문제 많은 기반을 해킹하는 대신 깨끗한 출발점에서 시작하려고 함
  그리고 30년 넘은 Python이 아니라, 지난 언어 설계 경험 위에 잘 설계된 언어로 “Python 같은 경험”을 제공하려 함
  그 이유만으로도 성공하길 바람
요즘은 적어도 일부 사람들에게 AI native를 전면에 내세우는 광고가 필요한 것 같음
하지만 내게는 좀 거부감이 듦. 실제로 아무 말도 하지 않는 표현처럼 보이기 때문임
“컴파일되고 정적으로 타입이 지정된 언어이기 때문에 에이전트형 프로그래밍에도 이상적”이라는 말이 왜 그렇고, 무슨 뜻인지 AI에 열광하는 사람들이 설명해줄 수 있을까
- AI가 부각된 이후 이런 제품과 서비스들의 첫 화면에서 절박함이 보이는 게 정말 흥미로웠음
  개인적으로 가장 웃겼던 건 IBM DB2 제품 페이지를 열었더니 AI database라고 붙어 있던 장면이었음
  컴파일 시점에 더 많은 오류를 잡으면, 에이전트가 단위 테스트나 다른 테스트 없이도 정적으로 자기 작업을 빠르게 확인할 수 있다는 뜻으로 보임
- 현재 LLM은 과거 코드의 방대한 라이브러리로 학습됐음. 따라서 가까운 미래에는 새 언어보다 이미 자리 잡은 언어에서 더 잘 동작할 것임
  특히 Python처럼 사용 가능한 오픈소스 코드가 많은 언어가 유리함. 학습할 기존 코드가 없는 신규 진입자에게는 큰 문제임
  그래서 “에이전트형” 세계에서 관련 있어 보이려면 이런 절박한 AI native 마케팅이 필요할 수도 있음. 충분한지는 시간이 말해줄 것임
- AI 열성 사용자라고 생각하진 않지만 실제로 쓰기는 함
  에이전트는 피드백을 많이 받을수록 더 잘하는 경향이 있음. 타입 검사는 멍청한 실수들을 자동으로 꽤 많이 잡아내는 데 좋음
  요지는 에이전트에게 힌트가 많을수록 대체로 더 낫다는 것임
- 무슨 뜻으로 쓴 말인지는 모르겠고, 이런 프로그래밍 언어에서 “AI native”라는 표현이 다소 무의미하다는 생각에는 동의함
  컴파일과 정적 타이핑에 대해서는, 에이전트형 프로그래밍을 할 때 컴파일 시점에 문제를 잡을 수 있는 게 매우 도움이 됨
  그러면 런타임에서 마주치는 문제가 줄고, 에이전트가 해결하기 어려운 상황도 줄어듦. 단위 테스트가 어느 정도 간극을 메울 수는 있지만 완전히는 아님
  웹사이트에 적혀 있지 않은 점은, Mojo가 에이전트형 프로그래밍에는 오히려 나쁜 선택일 가능성이 크다는 것임. 아직 Mojo 학습 데이터가 많지 않기 때문임
- 이건 새로운 “...on the blockchain”임
  Python+ruff+pycheck와 TypeScript는 기계어가 아니라 바이트코드로 컴파일됨. Rust식 의미의 정적 타입도 아님
  그런데도 모델이 둘 다에서 꽤 좋은 유효한 코드를 만들어내는 걸 봤음. 엄격하게 “컴파일”되거나 “정적 타입”일 필요는 없었음
  결국 AI는 코드를 빠르게 확인하고 반복할 수 있는 좋은 도구만 있으면 그런 속성에는 별로 신경 쓰지 않음
Modular는 올해 말 컴파일러를 포함한 전체 Mojo SDK를 오픈소스로 공개할 예정임
“Mojo 1.0은 올해 말 확정되며, 컴파일러 공개와 언어 안정성 제공도 함께 진행된다”고 되어 있음
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
Mojo를 계속 지켜보고 있음. 솔직히 Python에서 가장 마음에 안 드는 건 문법임
여기서 다른 사람이 Julia를 언급했는데, 좋은 언어라고 생각함. 하지만 컴파일러 오류 메시지와 라이브러리 문서는 그 정도 성숙한 언어에서 기대하는 수준이 아님
예전에 읽은 블로그의 정확성 문제들도 걱정됨. 또한 바이너리 크기와 최초 실행 시간 때문에 원하는 형태의 Python 모듈을 Julia로 만들 수 있을 것 같지 않음
그렇다고 해도 Mojo가 선택지가 되길 바라고 있음. 다만 REPL을 좋아하고 Python의 동적인 성격도 좋아해서, 성능 때문에 NumPy 바깥으로 나가는 일은 결국 안 할 수도 있음
- 내게는 반대임. Python에서 유일하게 좋아하는 게 문법임
  그래서 Nim을 정말 좋아함. C 수준 속도, 컴파일 타임 실행, 메타프로그래밍, 강력한 타입 시스템, 메모리 안전성을 얻으면서 코드도 자주 짧고 우아함
  Mojo도 흥미롭지만 지금까지는 범용 프로그래밍보다 머신러닝 쪽에 주로 집중하는 것 같음. 그리고 컴파일러는 아직 오픈소스가 아닌 걸로 앎
- Mojo의 설계를 매우 좋아함. 결정적 메모리 관리가 있기 때문에 Julia와 비교할 수 없음
  Mojo가 산업용 강건한 언어가 되는 데 더 초점을 맞춘 것 같기도 함. Julia의 첫 사전 컴파일 구현이 파일 입출력을 제공하지 않는 걸 보고 충격받았음

답변달기

Mojo 1.0 베타

버전과 시작 자료

GPU와 Python 상호운용

GPU 프로그래밍

Python 상호운용

컴파일 타임 메타프로그래밍

로드맵과 오픈소스

Phase 0

Phase 1

Phase 2

Phase 3

학습 및 커뮤니티 자료

함께 보면 좋은 글 β

Hacker News 의견들