▲

머신러닝에는 새로운 프로그래밍 언어가 필요함 – Chris Lattner 인터뷰

 (signalsandthreads.com)
3P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • Chris Lattner는 LLVM과 Swift 언어의 핵심 개발자이며, 최신 ML 하드웨어의 성능을 최대한 활용하기 위해 새로운 언어 Mojo를 개발하고 있음
  • Mojo는 사용성과 하드웨어 세부 제어를 모두 제공하는 언어 설계가 목표이며, 타입 안전 메타프로그래밍을 활용해 하드웨어 세부사항을 효율적으로 다룰 수 있도록 지원함
  • GPU, TPU, ASIC 등 AI 가속기 생태계의 분절화 문제를 해결하고, 특정 벤더 의존성을 줄이기 위한 통합 컴퓨팅 플랫폼을 구축하는 것이 핵심 배경임
  • 기존 GPU 소프트웨어 스택(CUDA, ROCm, XLA 등)의 호환성 및 복잡성 문제 때문에 차세대 고성능/이식성 언어 개발이 필수적임
  • Modular는 Mojo를 무료로 제공하고, 통합 하드웨어 지원과 엔터프라이즈 서비스 등 실질적인 문제 해결에 초점을 맞추는 비즈니스 모델을 추진 중임

Chris Lattner 소개와 커리어

  • Chris Lattner는 LLVM, Clang, MLIR, Swift, Mojo 등 컴퓨팅 분야의 여러 핵심 프로젝트를 이끌어온 경험을 보유함
  • Apple, Tesla, Google, SiFive, Modular 등 다양한 기관에서 근무하며 컴파일러 및 프로그래밍 언어 설계에 폭넓은 실전을 경험함
  • 초기에는 BASIC 같은 단순한 언어와 PC 환경에서 출발했으며, 게임/그래픽스를 통해 하드웨어 성능 극대화에 관심을 갖게 되었음
  • 대학 시절 우연히 컴파일러 전공 교수의 영향으로 시스템과 대규모 소프트웨어 구조의 매력을 느꼈음

컴파일러와 언어 설계 사이의 오가며

  • Chris Lattner는 컴파일러 엔지니어링과 언어 설계를 모두 경험하며, 이 두 영역의 접점에서 큰 성취를 이룸
  • 예를 들어 LLVM은 다양한 언어가 사용할 수 있는 중간 언어로, C++ 구현뿐만 아니라 Rust, Julia 등 광범위한 적용 사례를 창출함
  • Swift 개발 역시 기존 C++ 구현의 한계와 피로감을 극복하려는 시도에서 시작되었으며, 패턴 매칭 등 실용적 기능의 필요성을 중시함
  • 프로그래밍 언어 혁신은 수학 이론보다는 실제 문제 해결과 유틸리티에 근거하여 설계하는 접근법을 선호함

프로그래밍 언어 이론과 실용성

  • Chris는 수학적 엄밀성보다는 문제 해결 중심 사고를 추구하며, PL 논문에서 이론 자체보다는 실용적 예제와 활용 사례에 관심을 가짐
  • 수학적 기초가 강한 언어 기능은 일관성과 조합성에서 장점이 있음을 인정하지만, 실제 도입/채택은 사용상의 가시적 효용이 원동력임
  • 새로운 언어나 기술은 복잡성의 "모래알(grain of sand)" 을 최대한 줄여 설계의 단순화와 확장성을 추구하는 것이 중요하다고 언급함

AI 하드웨어 생태계의 구조적 문제

  • 전통적인 컴파일러 인프라(LLVM) 는 CPU 중심이었으나, AI/머신러닝은 GPU, TPU, ASIC, FPGA 등 다양한 전용 하드웨어를 요구함
  • 각 벤더가 고유의 소프트웨어 스택(CUDA, ROCm, XLA 등) 을 개발하며, 이는 호환성 결핍과 생태계 분열을 초래함
  • ML 소프트웨어(예: PyTorch 등)는 하드웨어 벤더별로 별도의 최적화가 필요해 유지/확장이 매우 어려워지는 문제 발생
  • 하드웨어마다 스택과 언어, 도구 생태계가 상이하여, 소프트웨어 개발자 입장에서 생산성 및 이식성 저하가 만연함

Modular와 Mojo의 역할

  • Modular 팀은 이러한 문제를 해결하기 위한 범용적이고 통합적인 소프트웨어 플랫폼을 구축하는 데 초점을 맞추고 있음
  • Mojo는 최신 GPU 아키텍처(템서 코어 등)의 성능 특화는 물론, 다양한 하드웨어에 이식 가능한 커널 작성을 목표로 설계됨
  • Mojo, MAX(고성능 LLM 서빙 등), Mammoth(클러스터/쿠버네티스 관리) 등 다계층 구조를 통해 통합적 AI 인프라를 제공함

Mojo가 필요한 배경 및 언어 설계 결정

  • 기존 언어로는 고성능 ML 커널의 이식성과 벤더 최적화라는 두 가지 요구가 동시에 충족되지 않음
  • Mojo는 하드웨어 세부 구조, 예를 들어 각종 데이터 타입(8비트 floating point 등) 및 텐서 코어와 같이 혁신적으로 빠르게 변화하는 하드웨어에 동적 대응이 가능해야 함
  • 타입 안전성을 확보한 메타프로그래밍 모델로 복잡한 하드웨어 제어를 보다 효율적이고 공유 가능한 방식으로 변환함

하드웨어와 커널 설계의 변화

  • 현대 데이터센터의 CPU는 다수의 코어로 확장됐지만, GPU는 SM(Streaming Multiprocessor) 구조, Warp(32개 쓰레드 동작) 등 병렬처리 특화 설계로 급격히 발전함
  • 텐서 코어 등 AI 전용 연산 유닛이 하드웨어로 도입되면서 전통적 CUDA와 완전히 다른 하드웨어 프로그래밍 패러다임이 필요해짐
  • 동일 벤더 내에도 아키텍처 세대별 호환성 변화가 잦아짐(예: Nvidia Volta/Hopper/Blackwell 변화), 소프트웨어 스택이 이를 따라가지 못함

비즈니스 모델과 오픈 생태계 전략

  • Modular는 언어 자체 판매에 집중하지 않고, Mojo를 무료로 공개함
  • 핵심 수익 모델은 통합된 하드웨어 관리와 엔터프라이즈 대상의 플랫폼/서비스 제공에 기반함
  • 이로써 벤더 락인 없는 공용 생태계 구축을 도전하며, 다양한 하드웨어 지원과 효율적 인프라 관리를 동시에 추구함

결론

  • Chris Lattner와 Modular의 Mojo 프로젝트는 머신러닝 고도화, AI 하드웨어 혁신, 생태계 분절 극복을 위한 새로운 프로그래밍 언어 및 플랫폼 구축의 의의를 가짐
  • 혁신적 언어 설계와 오픈 생태계 확산으로 AI 생태계의 민주화 및 생산성 향상에 기여할 전략임
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 많은 분들이 Mojo와 팟캐스트에 관심을 가져줘서 감사함을 전하고 싶음. Mojo에 대해 더 궁금하다면 FAQ에서 자주 묻는 질문을 볼 수 있음(‘왜 Julia를 더 좋게 만들지 않느냐’에 대한 답변도 있음). 문서 역시 여기에서 확인할 수 있고, 오픈소스 코드도 수십만 줄 규모로 공개되어 있음. Mojo 커뮤니티도 정말 훌륭하니, 디스코스 포럼이나 디스코드 채팅에 함께해주면 좋겠음 - Chris Lattner 의견임

    • 팬임을 밝힘. Mojo에 대한 여러 발표를 시청했는데, Mojo가 첨단 컴파일러 기술을 활용한다고 하지만 구체적인 예시는 들어본 적이 없음. 컴파일러 개발자가 아니라도 20% 정도만 이해한다 해도 첨단 기술의 진면목을 느껴보고 싶으니, 정말 깊고 기술적인 블로그 글을 작성해줬으면 좋겠음

    • FAQ에서 "Mojo Playground가 여전히 사용 가능한가?"라고 묻자 해당 플레이그라운드로 안내했는데, 정작 그 곳에선 '다음 25.6 릴리즈에서 Playground를 제거한다'고 안내되고 있음. '이것이 사용 가능한가'에 대한 FAQ 답변이 곧 제거될 기능으로 안내하는 것은 핵심을 놓친 것 같음. 실제로는 '오래 못 쓴다'가 답인 듯함

    • Chris, 이곳에서 만나서 반가움. 예전에 Light Table을 통해 투자도 했는데 혹시 업데이트가 있는지 궁금함. (진지하게 묻는 것은 아니고, Mojo가 멋지게 보이긴 함) 이러한 프로젝트의 장기적 지속 가능성은 어떤지, 신뢰할 만한 근거가 있는지 궁금함

  • Python이 ML 분야를 지배하는 이유는 현대 ML 애플리케이션이 단순 계산용 스크립트가 아니라 광범위한 기능과 견고한 생태계를 요구하기 때문임. 각종 데이터 전처리(ETL), 다양한 형식의 데이터 처리, 고성능 컴퓨팅 클러스터 분산 처리, 시각화와 GUI/DB 연동 등 모두를 포괄하는 언어는 Python 외엔 없음. 수치 연산은 NumPy, PyTorch, JAX 등에서 내부적으로 C/C++/FORTRAN을 사용해서 매우 빠르고, 성능이 중요한 코드만 별도로 C/C++로 구현하기도 쉬움. Python의 C/C++ FFI 시스템도 다른 언어에 비해 충분히 실용적임. 다른 언어(Julia 등)에서 생태계 전체를 다시 구현하는 것보다 훨씬 장점이 많음

    • Python 생태계는 타의 추종을 불허하지만, Elixir/Nx 조합도 Mojo가 약속하는 상당 부분을 이미 수행하고 있음. EXLA를 통해 GPU/TPU 컴파일도 가능하고, Explorer/Polars로 데이터프레임 작업, Pythonx로 Python 라이브러리 임베딩도 가능함. 차이점이라면 Elixir는 처음부터 분산 시스템 구축을 겨냥해서 BEAM/OTP는 막대한 동시 요청 및 GPU 노드 간 조정도 가능함. 실제 ML 서비스를 구축한다면 Phoenix, LiveView, Nx까지 하나의 견고한 스택으로 극한 내결함성과 확장성을 얻는 것이 소소한 하드웨어 성능보다 더 중요할 수 있음

    • 나는 추론(inference) 쪽에서 조금 다른 입장임. CUDA 커널을 직접 손봐서 만드는게 쉽고, 최신 CUTLASS 3나 현대 C++가 많이 편리해짐. 그 위에 Torch가 얇게 올라가 있는데 이 부분이 빌드도 어렵고, 레퍼런스 카운팅 비롯한 여러 문제로 복잡성만 더함. 진짜 핵심 구현은 아래 커널에 있는데, 곧 이런 ‘torch 커버’ 부분을 걷어내고 깨끗한 C++ 프로그램으로 명확하게 연결해서 쓸 생각임

    • 이 문제는 GPU 커널 걱정인데, 그런 커널은 애초에 Python으로 작성하지 않음. Python은 ML을 위한 ‘접착(glue)’ 언어임. “Python만이 모든 기능을 제공한다”는 주장엔 동의하지만, 더 좋은 언어가 아닌 Python 위주로 생태계가 자라난 게 살짝 아쉽기도 함

    • Python이 ML 대표 언어가 된 건 ‘선순환’임. 이미 선택됐기에 생태계가 커졌을 뿐, 최초 선택 이유는 따로 설명이 필요함. 지금은 넘을 수 없어 보일 정도로 커졌으나, 왜 처음부터 Python이었는지 논거로 삼기엔 부족함

    • 아이러니하게도 Python은 언급한 모든 작업에 최악의 언어임. 패키징이나 바이너리(wheel) 모두 고통이고, 항상 무언가가 깨짐. 단독 스크립트엔 괜찮지만, ML 메인 언어가 되는 걸 목표로 Python을 설계했다면 이런 모습은 누구도 원치 않았을 것임

  • 에피소드를 듣고 충격을 받았음. 2025년 9월이 되어도 아직 클래스 지원이 중기 목표란 얘기는 놀라웠음. 예전엔 Mojo가 ‘Python의 상위 호환’이라고 많이 홍보됐는데, 현재 진척 속도로선 이상적인 목표로만 보임

    • 사실 ‘Python 상위 호환’이 목표였던 적은 없음. 사람들의 관심을 모으기 위한 슬로건일 뿐, 초반에만 강조하다 조용히 거뒀음

    • 속도 문제가 아니라 OOP 자체를 좋아하지 않아서 그런 게 아닌가 싶음

    • 항상 장기 목표였음

  • 좀 흔한 질문일지 모르겠지만, 왜 Lisp는 아니었는지 궁금함. 미래 ML 코드가 결국은 머신(혹은 자연어 기반 자동 변환 시스템)이 작성하게 될 것이라고 가정할 때, Lisp S-Expression은 사실상 AST와 같으니 머신에 가장 자연스러운 언어임. REPL 환경도 보통 완비되어 있으니, Python 대체로서도 아주 잘 맞아떨어질 것 같음

    • Yann LeCun 등은 Lush라는 ML용 Lisp를 만들었었음. 2000년대엔 최고였고 Python( Theano)이나 Lua(Torch)가 나오기 전까지 대안이 없었음. 요즘도 Lisp가 다시 주목 받았으면 하는 바람임. Python은 라이브러리는 훌륭하지만 언어 자체는 보완할 부분이 많음

    • LLM(대형 언어 모델)은 괄호 개수 세기가 아직 약함 ;)

    • 과거 AI 붐 때 Lisp가 외면받은 경험이 있어서, 많은 개발자들이 여전히 Emacs + SBCL만 씀. 실제로는 LispWorks, Allegro, Clozure 같은 다른 고급 Lisp 구현체도 있지만 경험해보지 않은 경우가 많음

  • Mojo의 라이선스부터가 마음에 들지 않음

    • 나도 확인해봤는데, Mojo 라이선스는 CPU나 Nvidia 용도와 기타 ‘가속기’(TPU, AMD 등)에 대해 구분하여 상업적 용도면 별도 라이선스가 필요하다고 밝힘 블로그 참고

    • 내 입장에서 특정 회사가 절대적으로 통제하는 언어(Mojo)라면 비즈니스에 채택할 이유가 전혀 없음. Java 라이선스 변화 때 이미 많은 기업들이 문제를 겪은 사례가 있음. Python 대신 Mojo에 사업을 올리는 건 지나치게 위험함

  • Mojo FAQ를 보면 엄밀한 의미에서 Python 상위 호환을 지향한다고 하지만, 로드맵에서는 “Python 코드와 익숙함을 제공하지만 완전한 상위 호환이 될 수는 없다”고 해 혼란만 커짐. Python 호환이 목표가 아니라면 왜 계속 Python을 언급하는지 모르겠음. 또, 파일 확장자로 이모지를 쓴다는 얘기가 실제로 있는지 궁금함

    • 내가 알기론 Mojo는 Python 스타일 문법과 Python과의 상호운용성만 추구함. 그 이상으로 Python과 비슷하단 어필은 마케팅용이 큼

    • 이모지 확장자에 대해선, 확실함. U+2615(커피 이모지)임

  • Mojo가 Julia보다 뛰어난 점이 무엇인지 알고 싶은데, Julia도 인터페이스나 생태계 한계는 있지만 Python과 연동도 충분히 잘 되고 있어 Mojo가 딱히 더 좋다고 느껴지지 않음

    • 특히 Julia는 JuliaGPU, Reactant 같은 GPU 생태계가 잘 갖춰져 있음 Reactant.jl 참고

    • Python과의 호환성이 Mojo가 좀 더 나을 수도 있으나 실제로 PythonCall.jl을 통해 Julia에서도 Python 라이브러리 호출이 꽤 안정적임. ML 프레임워크(Lux.jl, Flux.jl)도 Julia 내에서 잘 돌아감. Mojo에는 비슷한 수준의 네이티브 ML 프레임워크가 아직 없는 것 같음

    • Mojo는 훨씬 저수준 언어 느낌과 더 많은 제어권, 그리고 견고함을 목표로 하는 듯함. Julia는 의미나 성능면에서 예측 가능하지 않아 핵심 소프트웨어 기반으론 부적합한 반면, Mojo는 그 점에서 우위가 있음

    • Python 모듈을 Julia로 만들려 했으나 아직 지원이 부족하다고 느낌. Mojo는 이 부분이 핵심 기능임

    • Julia 코드를 완전 네이티브 바이너리로(마치 Rust나 C++처럼) 컴파일하는 기능은 아직 부족함

  • Mojo가 엄청난 주목을 못 받고 PyTorch 사용이 여전한 점은 라이선스 이슈가 실제로 기대 이상으로 크다는 단서일 수 있다고 느낌

    • Mojo가 자신들의 영역을 너무 낙관적으로 잡은 듯함. Julia도 실제 상용 사용이 점진적으로 늘고 있고 GPU 지원도 잘 됨. Python의 JIT 컴파일러가 미흡하더라도 Nvidia, Intel 등이 Python DSL로 GPGPU 프로그래밍을 어지간히 최적화하고 있어서, Python 내에서 C++ 수준에 가깝게 쓸 수 있음. 결국 Mojo는 차별점이 약함

    • 시스템 쪽 관점에선 Chris와 팀이 Mojo로 다중 언어 FFI 문제를 싹 개선하려는 시도가 인상적임. 다만 오픈소스가 되기 전까진 투자건 논의건 시작할 수 없겠음

    • 아직 범용 프로그래밍 언어로 쓸 준비가 안 됨. Modular도 MAX 엔진에 Mojo API를 적용해 보려 했으나 언어 변화가 너무 빨라 투자 포기함. 로드맵상 1단계 완성 이후에야 본격 도입이 기대됨

    • 진짜 공개된 게 맞는지 모르겠음. 최근까지 오픈소스화가 되지 않아 상용 독점 소프트웨어에 의존하기 꺼려졌음

    • 글 첫머리에 보면 ‘최첨단 커널’을 쓸 수 있다고 함. 결국 Mojo는 커널 개발에서 C++와 경쟁하려는 것 같음. PyTorch나 Julia에선 커널을 직접 작성하지 않고 주로 고수준 코딩만 하게 됨

  • Chris Lattner가 참여한 Lex Fridman 팟캐스트 에피소드들이 있음:

  • Mojo 시도 자체는 대담하고 흥미롭지만, Matlab처럼 폐쇄적 언어라면 나뿐만 아니라 많은 이들에게 심각한 결격 사유임

    • Chris가 다양한 팟캐스트에서 자세히 설명했듯, Mojo는 반드시 오픈소스화할 예정임. 다만 Swift 오픈소스 프로젝트 경험에서 얻은 교훈 덕분에, 초기에는 오픈 개발방식이 언어 성장단계에선 역효과가 있다고 판단함. 그래서 현재는 단계적으로 공개 중이며, 현재는 표준 라이브러리가 오픈돼 있고 컴파일러도 조만간 공개 계획임
답변달기