Mojo🔥 ?? Mojo🔥 를 알려줘!!

Mojo🔥를 사용해 보십시오.

Mojo 언어는 아직 매우 어리지만, 우리는 당신의 피드백을 원합니다!

Mojo 표준 라이브러리, 컴파일러, 런타임은 아직 로컬 개발에 사용할 수 없기 때문에 사용해 볼 수 있는 호스팅된 개발 환경을 만들었습니다.우리는 그것을 모조 놀이터라고 부릅니다!

최상의 경험을 제공하기 위해, 모조 놀이터는 현재 제한된 수의 사람들을 지원합니다.시간이 지남에 따라 모든 사람이 액세스할 수 있도록 신속하게 확장할 계획입니다.

Mojo🔥가 필요한 이유

Modular를 시작했을 때, 우리는 새로운 프로그래밍 언어를 만들 의도가 없었습니다.그러나 전 세계의 ML/AI 인프라를 통합하기 위한 목적으로 플랫폼을 구축하면서 전체 스택에 걸친 프로그래밍이 너무 복잡하다는 것을 깨달았습니다.게다가, 우리는 손으로 많은 MLIR를 쓰고 있었고 즐거운 시간을 보내고 있지 않았습니다.

우리가 원했던 것은 AI 분야에 만연한 가속기와 기타 이질적인 시스템을 대상으로 할 수 있는 혁신적이고 확장 가능한 프로그래밍 모델이었습니다.이것은 강력한 컴파일 타임 메타프로그래밍, 적응형 컴파일 기술의 통합, 컴파일 흐름 전체의 캐싱 및 기존 언어에서 지원되지 않는 다른 기능을 포함하는 프로그래밍 언어를 의미합니다.

그리고 액셀러레이터도 중요하지만, 가장 보편적이고 때로는 간과되는 "액셀러레이터" 중 하나가 호스트 CPU입니다. 요즘 CPU에는 텐서 코어와 같은 액셀러레이터 블록과 기타 AI 액셀러레이터 장치가 많이 있지만, 데이터 로드, 사전 및 p와 같이 전문 액셀러레이터가 처리하지 않는 작업에 대한 "폴백" 역할도 합니다.ost-processing 및 외부 시스템과의 통합.따라서 특정 프로세서에서만 작동하는 "가속기 언어"만으로는 AI를 들어올릴 수 없다는 것이 분명했습니다.

응용 AI 시스템은 이 모든 문제를 해결해야 하며, 우리는 하나의 언어로 수행할 수 없는 이유가 없다고 판단했습니다.이렇게 해서 모조가 태어났습니다.

 

차세대 컴파일러 기술을 위한 언어

기존 언어가 AI 컴퓨팅의 과제를 해결할 수 없다는 것을 깨달았을 때, 우리는 문제를 해결하기 위해 프로그래밍 언어가 어떻게 설계되고 구현되어야 하는지에 대해 다시 생각하는 첫 번째 원칙에 착수했습니다.다양한 가속기에 대한 고성능 지원이 필요하기 때문에 LLVM 및 GCC와 같은 기존 컴파일러 기술은 적합하지 않았습니다(그리고 이를 기반으로 하는 언어 및 도구로는 충분하지 않습니다).다양한 CPU와 일반적으로 사용되는 GPU를 지원하지만 이러한 컴파일러 기술은 수십 년 전에 설계되었으며 현대의 칩 아키텍처를 완전히 지원할 수 없습니다.오늘날 특화된 기계 학습 가속기의 표준 기술은 MLIR입니다.

MLIR은 기계 학습 가속기 커뮤니티 전반에 걸쳐 널리 채택된 구글(그의 리드가 모듈러로 이동됨)에서 시작된 비교적 새로운 오픈 소스 컴파일러 인프라입니다.MLIR의 강점은 도메인별 컴파일러, 특히 AIASICS, 양자 컴퓨팅 시스템, FPGA 및 사용자 지정 실리콘과 같이 기존 CPU 및 GPU가 아닌 이상한 도메인에 대한 빌드 기능입니다.

모듈러에서 차세대 AI 플랫폼을 구축하려는 목표를 고려할 때, 우리는 이미 일부 인프라에 MLIR를 사용하고 있었지만, 스택 전반에 걸쳐 MLIR의 모든 잠재력을 실현할 수 있는 프로그래밍 언어가 없었습니다.현재 많은 다른 프로젝트들이 MLIR을 사용하고 있지만, Mojo는 MLIR을 위해 특별히 설계된 최초의 주요 언어입니다. Mojo는 AI 워크로드를 위한 시스템 레벨 코드를 작성할 때 고유하게 강력합니다.

 

파이썬 계열의 일원

Mojo에 대한 우리의 핵심 임무는 컴파일러 내부의 혁신과 현재 및 새롭게 부상하고 있는 가속기에 대한 지원을 포함하지만 언어 구문이나 커뮤니티에서 혁신할 필요성은 전혀 없습니다.그래서 우리는 파이썬 생태계를 받아들이기로 결정했습니다. 왜냐하면 파이썬은 매우 널리 사용되고 AI 생태계에 의해 사랑받고 있고, 우리는 파이썬이 정말 좋은 언어라고 믿기 때문입니다.

Mojo 언어는 높은 목표를 가지고 있습니다. 우리는 파이썬 생태계와의 완전한 호환성, 예측 가능한 낮은 수준의 성능 및 낮은 수준의 제어, 그리고 코드의 하위 집합을 가속기에 배포할 수 있는 기능을 원합니다.또한 우리는 단편적인 소프트웨어 에코시스템을 만들고 싶지 않습니다. Mojo를 채택하는 Python 사용자가 Python 2에서 3으로의 고통스러운 마이그레이션과 비교하는 것을 원하지 않습니다.이것들은 작은 목표가 아닙니다!

다행히 Mojo는 완전히 새로운 코드 기반이지만 개념적으로 처음부터 시작하는 것은 아닙니다.대부분의 구문이 이미 지정되어 있으므로 Python을 수용하면 설계 작업이 크게 간소화됩니다.대신 Mojo의 컴파일 모델과 시스템 프로그래밍 기능을 구축하는 데 노력을 집중할 수 있습니다.또한 개발자를 새로운 컴파일러 및 언어로 마이그레이션한 이전 경험에서 얻은 다른 언어(Rust, Swift, Julia, Zig, Nim 등)에서 얻은 엄청난 교훈을 활용하고 기존 MLIR 컴파일러 에코시스템을 활용합니다.

또한 Mojo의 올바른 장기 목표는 Python 슈퍼셋(즉, Mojo가 기존 Python 프로그램과 호환되도록 만드는 것)을 제공하고 긴 꼬리 생태계 지원을 위한 CPython 구현을 수용하는 것이라고 결정했습니다.Python 프로그래머라면 Mojo가 즉시 익숙해지기를 바라며, 그렇지 않으면 Python 아래에 C와 C++이 필요할 안전하고 성능이 뛰어난 시스템 수준 코드를 개발하기 위한 새로운 도구를 제공하기를 바랍니다.

우리는 "정적인 것이 최고" 또는 "동적인 것이 최고"라고 세상을 설득하려는 것이 아닙니다.오히려, 우리는 둘 다 올바른 응용 프로그램에 사용할 때 좋다고 생각하기 때문에 프로그래머인 당신이 정적 또는 동적 사용 시기를 결정할 수 있도록 Mojo를 설계했습니다.

 

Python을 선택한 이유

파이썬은 ML과 수많은 다른 분야에서 지배적인 힘입니다.중요한 프로그래머 집단에 의해 알려진 그것은 배우기 쉽고, 놀라운 커뮤니티를 가지고 있고, 많은 귀중한 패키지를 가지고 있으며, 다양한 좋은 도구들을 가지고 있습니다.Python은 동적 프로그래밍 기능을 통해 아름답고 표현력 있는 API의 개발을 지원하며, 이는 TensorFlow 및 PyTorch와 같은 머신 러닝 프레임워크가 Python을 C++에 구현된 고성능 런타임의 프런트 엔드로 채택하도록 했습니다.

오늘날 Modular의 경우 Python은 API 표면 스택에서 협상할 수 없는 부분이며, 이는 고객에 의해 결정됩니다.우리 스택의 다른 모든 것이 협상 가능하다는 점을 고려할 때, 우리가 "파이썬 우선" 접근법에서 시작해야 한다는 것은 타당합니다.

좀 더 주관적으로, 우리는 파이썬이 아름다운 언어라고 믿습니다.단순하고 구성 가능한 추상화로 설계되었으며, 들여쓰기와 중복되는 불필요한 구두점을 피하고 강력한 (동적인) 메타프로그래밍 기능으로 구축되었습니다.이 모든 것은 모듈러에서 필요한 언어로 확장할 수 있는 활주로를 제공합니다.Python 생태계의 사람들은 Mojo에 대한 우리의 방향이 Python과 경쟁하는 것이 아니라 Python을 한 단계 앞서가는 것, 즉 완성하는 것이라고 생각하기를 바랍니다.

 

Python과의 호환성

우리는 Python 에코시스템과의 완벽한 호환성을 계획하고 있지만 실제로는 두 가지 유형의 호환성이 있습니다. 따라서 현재 이 두 가지 모두를 기반으로 합니다.

• 기존 Python 모듈을 가져와서 Mojo 프로그램에서 사용할 수 있는 능력에 있어서, Mojo는 상호 운용성을 위해 CPython을 사용하기 때문에 100% 호환됩니다.
• 파이썬 코드를 Mojo로 마이그레이션할 수 있다는 점에서 아직 완전히 호환되지는 않습니다.Mojo는 이미 비동기/대기, 오류 처리, 변수 등을 포함하여 Python의 많은 핵심 기능을 지원합니다.하지만 Mojo는 아직 어리고 Python의 많은 다른 기능들을 놓치고 있습니다.Mojo는 아직 수업도 지원하지 않습니다!

해야 할 일이 많지만, 우리는 그것을 달성할 수 있을 것이라고 확신하며, 우리 팀은 자체적인 호환성 여정을 통해 다른 주요 기술을 구축한 경험을 바탕으로 합니다.

• Crang 컴파일러(C, C++, Objective-C, CUDA, OpenCL 등의 컴파일러)로의 여정은 GCC, MSVC 및 기타 기존 컴파일러의 "호환 가능한 대체"입니다.직접 비교하기는 어렵지만, Clang 문제의 복잡성은 Python에 대한 호환 가능한 대체를 구현하는 것보다 훨씬 큰 것으로 보입니다.
• 목표-C 런타임 및 언어 생태계를 수용하고 수백만 명의 프로그래머(그리고 엄청난 양의 코드)를 점진적으로 마이그레이션한 스위프트 프로그래밍 언어로의 여정.Swift를 사용하여 "런타임 호환성"을 유지하고 기존 런타임과 협력하는 방법에 대한 교훈을 얻었습니다.

Python과 Mojo 코드를 혼합하려는 상황에서는 Mojo가 Cython 런타임과 직접 협력하고 코드 자체를 컴파일할 필요 없이 CPython 클래스 및 개체와 통합할 수 있도록 유사한 지원을 제공할 것으로 예상합니다.이를 통해 플러그인은 기존 코드의 대규모 에코시스템과 호환되며 Mojo로의 점진적인 마이그레이션이 점진적인 이점을 제공하는 점진적인 마이그레이션 접근 방식을 가능하게 합니다.

전반적으로, 우리는 언어 설계와 Python과의 완전한 호환성을 향한 점진적인 발전에 초점을 맞추면 우리가 제 시간에 필요한 곳에 도달할 것이라고 믿습니다.

그러나 순수 Mojo 코드를 작성할 때 기존 Python 기술을 사용하는 구현, 컴파일 또는 런타임에는 아무것도 없다는 것을 이해하는 것이 중요합니다.그 자체로, 그것은 완전히 새로운 컴파일과 런타임 시스템을 가진 완전히 새로운 언어입니다.

 

Python과의 의도적인 차이

Python 호환성과 마이그레이션 가능성이 Mojo 성공의 핵심이지만, Mojo가 최고 수준의 언어(다른 언어에 의존하는 것이 아니라 독립형 언어임을 의미)가 되기를 원합니다.단지 호환성을 유지하기 위해 새로운 키워드나 문법을 도입하는 능력에 제한을 받아서는 안 됩니다.따라서 호환성에 대한 NAT의 접근 방식은 두 가지로 구분됩니다.

1. 우리는 CPython을 사용하여 모든 기존 Python 3 코드를 수정 없이 실행하고 전체 생태계와의 완벽한 호환성을 위해 수정되지 않은 런타임을 사용합니다.이러한 방식으로 코드를 실행하는 것은 Mojo의 이점을 제공하지 않지만, 이 생태계의 존재와 가용성은 Mojo의 성장을 빠르게 가속화하고 Python이 이미 높은 수준의 프로그래밍에 매우 유용하다는 사실을 활용할 것입니다.
2. 우리는 파이썬에서 Mojo로 코드를 마이그레이션하려는 사람들에게 매우 좋은 호환성을 제공하는 기계적 마이그레이션 도구를 제공할 것입니다.예를 들어 Mojo 키워드와 일치하는 식별자 이름을 사용하는 Python 코드의 마이그레이션 오류를 방지하기 위해 Mojo는 모든 키워드가 식별자로 동작할 수 있는 백틱 기능을 제공합니다.

이를 통해 Mojo는 대부분 CPython 세계에서 잘 통합할 수 있지만 Mojo 프로그래머는 코드(한 번에 모듈 또는 파일)를 Mojo로 점진적으로 이동할 수 있습니다.이것은 Apple이 수행한 Objective-C에서 Swift로의 마이그레이션에서 검증된 접근 방식입니다.

모조의 나머지 부분과 이주 지원을 구축하는 데 시간이 좀 걸리겠지만, 우리는 이 전략이 우리의 에너지를 집중하고 산만함을 피할 수 있게 해준다고 확신합니다.또한 CPython과의 관계는 양방향으로 구축될 수 있다고 생각합니다. CPython 팀이 결국 Cython이 아닌 Mojo로 통역사를 재구현한다면 멋지지 않습니까? 🔥

 

파이썬의 문제

Mojo를 Python의 슈퍼셋으로 만드는 것을 목표로 함으로써, 우리는 Python의 많은 기존 문제를 해결할 수 있다고 믿습니다.

Python에는 몇 가지 잘 알려진 문제가 있습니다. 가장 분명한 것은 낮은 수준의 성능과 Python을 단일 스레드로 만드는 GIL(Global Interpreter Lock)과 같은 CPython 구현 세부 사항입니다.이러한 과제를 개선하기 위해 많은 적극적인 프로젝트가 진행 중이지만, 파이썬이 가져온 문제는 더 깊이 들어가고 AI 분야에서 특히 영향력이 큽니다.이러한 기술적 한계에 대해 자세히 이야기하는 대신 2023년에 여기서 그 의미에 대해 이야기하겠습니다.

이 섹션에서 Python을 참조하는 모든 곳은 CPython 구현을 참조합니다.다른 구현에 대해서는 나중에 설명하겠습니다.

 

이세계의 문제.

다양한 이유로 Python은 시스템 프로그래밍에 적합하지 않습니다.다행히 Python은 접착제 레이어로서 놀라운 강점을 가지고 있으며, C와 C++에 대한 낮은 수준의 바인딩을 통해 C, C++ 및 더 나은 성능 특성을 가진 많은 언어로 라이브러리를 구축할 수 있습니다.이것이 바로 NumPy, TensorFlow, PyTorch와 같은 것들을 생태계에서 가능하게 한 것입니다.

불행히도, 이 접근 방식은 고성능 Python 라이브러리를 구축하는 효과적인 방법이지만, 이러한 하이브리드 라이브러리를 구축하는 것은 매우 복잡하다는 비용이 수반됩니다.이는 CPython의 내부에 대한 낮은 수준의 이해를 요구하고, C/C++ (또는 다른) 프로그래밍에 대한 지식을 요구하며(애초 Python을 사용하는 원래 목표 중 하나를 훼손함), 큰 프레임워크를 진화시키는 것을 어렵게 하며, (ML의 경우) 세계를 "그래프 기반" 프로그래밍 모델로 밀어넣습니다.기본적인 유용성이 "사용자 모드" 시스템보다 더 나쁜 경우.TensorFlow와 PyTorch 모두 이와 관련하여 중요한 과제에 직면했습니다.

두 세계의 문제가 어떻게 시스템의 복잡성을 만들어내는지에 대한 근본적인 본질을 넘어서, 생태계의 다른 모든 것들을 더 복잡하게 만듭니다.디버거는 일반적으로 Python과 C 코드, 그리고 널리 받아들여질 수 없는 코드를 건너갈 수 없습니다.Python 패키지 생태계가 Python 외에도 C/C++ 코드를 처리해야 하는 것은 고통스럽습니다.상당한 C++ 투자를 한 PyTorch와 같은 프로젝트는 유용성을 얻기 때문에 의도적으로 코드베이스를 Python으로 더 많이 옮기려고 합니다.

 

3세계와 N세계의 문제

두 세계 문제는 파이썬 생태계 전반에서 일반적으로 느껴지지만, 머신 러닝 프레임워크 개발자들에게는 상황이 더욱 심각합니다.AI는 널리 가속화되고, 이러한 가속기는 CUDA와 같은 맞춤형 프로그래밍 언어를 사용합니다. CUDA는 C++의 친척이지만 고유의 특별한 문제와 한계가 있으며, 디버거나 프로파일러와 같은 일관된 도구가 없습니다.또한 단일 하드웨어 제조업체에 효과적으로 고정되어 있습니다.

AI 세계는 하드웨어 분야에서 엄청난 양의 혁신을 가지고 있으며, 그 결과 복잡성이 걷잡을 수 없이 증가하고 있습니다.이제 가속기를 위한 제한된 프로그래밍 시스템(OpenCL, Sycl, OneAPI 등)을 구축하려는 여러 시도가 있습니다.이러한 복잡성의 폭발적 증가는 계속되고 있으며, 이러한 시스템 중 어떤 것도 업계에 심각한 타격을 주고 있는 툴과 에코시스템의 근본적인 단편화를 해결하지 못하고 있으며, 단편화를 가중시키고 있습니다.

 

모바일 및 서버 구축

Python 에코시스템의 또 다른 과제는 구축입니다.종속성을 제어하는 방법, 기밀로 컴파일된 "a.out" 파일을 배포하는 방법, 멀티 스레드 및 성능을 향상시키는 방법 등 다양한 측면이 있습니다.이러한 영역에서 Python 에코시스템이 상당한 진전을 이루길 바랍니다.

 

관련업무

우리는 파이썬을 개선하기 위한 다른 많은 노력을 알고 있지만, 그것들은 우리가 Mojo로 해결하고자 하는 근본적인 문제를 해결하지 못합니다.

Python을 개선하기 위한 지속적인 노력에는 Python의 속도를 높이고 GIL을 대체하기 위한 작업, Python과 유사하지만 하위 집합인 언어를 구축하기 위한 작업, Python과 통합되지만 일류 언어가 아닌 임베디드 도메인 특정 언어(DSL)를 구축하기 위한 작업이 포함됩니다.모든 노력의 전체 목록을 제공할 수는 없지만, 이러한 프로젝트에서 직면한 몇 가지 과제와 Mojo가 수행하는 문제를 해결하지 못하는 이유에 대해 이야기할 수 있습니다.

Python 및 JIT 컴파일 Python 개선

최근 커뮤니티는 CPython 성능 및 기타 구현 문제를 개선하는 데 상당한 에너지를 소비하고 있으며, 이는 엄청난 결과를 보여주고 있습니다.이 작업은 현재 CPython 구현을 점진적으로 개선하기 때문에 환상적입니다.예를 들어 Python 3.11은 내부 개선을 통해 Python 3.10에 비해 성능이 10-60% 향상되었으며, Python 3.12는 추적 최적화기로 한 단계 더 나아간 것을 목표로 합니다.많은 다른 프로젝트들은 GIL을 길들이기 위해 시도하고 있으며, PyPy와 같은 프로젝트들은 Python의 속도를 높이기 위해 JIT 컴파일 및 추적 접근법을 사용했습니다.

우리는 이러한 큰 노력의 팬이며 커뮤니티에 가치 있고 흥미롭다고 생각하지만 모듈러의 요구 사항을 충족하지 못합니다. 이는 통합된 언어를 가속기에 제공하는 데 도움이 되지 않기 때문입니다.오늘날 많은 가속기는 매우 제한적인 동적 기능을 지원하거나 성능이 좋지 않습니다.또한 시스템 프로그래머는 "성능"만을 추구하는 것이 아니라 일반적으로 예측 가능성이 높고 계산이 수행되는 방식을 제어하기를 원합니다.

우리는 Python 라이브러리에서 C 또는 C++를 사용할 필요성을 없애고, 가능한 최고의 성능을 추구하며, 경우에 따라 동적 기능을 전혀 수용할 수 없습니다.따라서 이러한 접근 방식은 도움이 되지 않습니다.

Python 하위 집합 및 기타 Python 유사 언어

PyTorch 프로젝트의 TorchScript와 같이 "배포 가능한" Python을 구축하려는 시도가 많습니다.이러한 솔루션은 종속성이 낮은 배포 솔루션을 제공하는 경우가 많고 때로는 성능이 우수하기 때문에 유용합니다.그들은 파이썬과 같은 구문을 사용하기 때문에 새로운 언어보다 배우기가 더 쉬울 수 있습니다.

반면, 이 언어들은 Python의 하위 집합이기 때문에 일반적으로 Python 에코시스템과 상호 운용되지 않으며(디버거와 같은) 환상적인 툴링이 없으며, 종종 Python에서 일방적으로 불편한 동작을 변경하여 호환성을 깨뜨리고 생태계를 더욱 파괴합니다.예를 들어, 이들 중 많은 수가 파이썬 호환 수학을 생성하는 대신 랩으로 단순 정수의 동작을 변경합니다.

이러한 접근 방식의 문제는 Python의 약점을 해결하려고 시도하지만 Python의 강점을 잘 다루지 못한다는 것입니다.기껏해야 이것들은 C와 C++의 새로운 대안을 제공할 수 있지만, Python의 동적 사용 사례를 해결하지 않으면 "두 개의 세계 문제"를 해결할 수 없습니다.이러한 접근 방식은 단편화를 촉진하고 비호환성은 마이그레이션을 불가능하게 만듭니다. Python 2에서 Python 3으로 마이그레이션하는 것이 얼마나 어려웠는지 기억해 보십시오.

C 호환성을 갖춘 Python 슈퍼셋

Mojo는 향상된 시스템 프로그래밍 기능을 갖춘 Python의 슈퍼셋으로 설계되었기 때문에 Pyrex 및 Cython과 같은 다른 Python 슈퍼셋과 높은 수준의 아이디어를 공유합니다.Mojo와 마찬가지로 이 프로젝트들은 파이썬 언어도 지원하는 자체 언어를 정의합니다.이를 통해 Python 및 C 라이브러리와 상호 운용되는 Python을 위한 더 많은 성능 확장을 작성할 수 있습니다.

이러한 Python 슈퍼셋은 일부 종류의 애플리케이션에 매우 적합하며 일부 유명한 Python 라이브러리에 의해 매우 효과적으로 적용되었습니다.그러나 그들은 파이썬의 2세계 문제를 해결하지 못하고 핵심 의미론을 CPython에 의존하기 때문에 그것 없이는 작동할 수 없는 반면, Mojo는 기존 파이썬 코드와의 호환성을 제공하기 위해 필요한 경우에만 CPython을 사용합니다.Pure Mojo 코드는 기존 런타임 또는 컴파일러 기술을 사용하지 않고 MLIR 기반 인프라를 사용하여 광범위한 하드웨어에서 고성능 실행을 가능하게 합니다.

Python의 임베디드 DSL

또 다른 일반적인 접근 방식은 일반적으로 Python 데코레이터와 함께 설치되는 Python에 포함된 DSL(도메인별 언어)을 구축하는 것입니다.이에 대한 많은 예가 있습니다.@tf.functionTensorFlow의 데코레이터,@triton.jit공개된AI의 Triton 프로그래밍 모델 등).이러한 시스템의 주요 이점은 Python 툴 생태계와의 호환성을 유지하고 Python 로직에 기본적으로 통합되어 내장된 미니 언어가 동적 사용 사례를 위해 Python의 강점과 공존할 수 있다는 것입니다.

불행하게도, 이러한 시스템에서 제공하는 내장된 미니 언어는 종종 놀라운 한계를 가지고 있으며, 디버거 및 기타 워크플로우 툴링과 잘 통합되지 않습니다.또한 이기종 컴퓨팅을 통합하고 대규모 커널 및 시스템을 작성하는 주요 방법인 언어를 찾는 네이티브 언어 통합 수준을 지원하지 않습니다.

Mojo와 함께, 우리는 일을 단순화하고 더 일관성 있게 함으로써 전체 시스템의 유용성을 진전시키기를 희망합니다.임베디드 DSL은 데모를 시작하고 실행하는 편리한 방법이지만, 우리는 사용 사례에 더 나은 사용 편의성과 예측 가능성을 제공하기 위해 기꺼이 추가적인 노력과 노력을 기울입니다.