▲

Luau – 빠르고, 작고, 안전하며 점진적 타입을 지닌 Lua 기반 스크립팅 언어

 (luau.org)
3P by GN⁺ 15시간전 | ★ favorite | 댓글 1개
  • Luau는 Lua 5.1에서 파생된 빠르고 안전하며 점진적 타입을 지원하는 임베디드 스크립트 언어임
  • Roblox 플랫폼의 복잡한 게임과 대규모 코드베이스를 지원하기 위해 성능, 언어 도구, 타입 시스템을 강화하여 발전함
  • 기본 Lua와 달리 샌드박싱 기능을 갖추어 권한이 다른 코드가 나란히 실행될 수 있도록 설계됨
  • 문법은 Lua 5.1과 호환되지만, 추가 구문 확장과 분석 도구(linter, 타입 체커) 를 제공해 코드 품질을 높임
  • 성능 최적화, 맞춤형 바이트코드, JIT 지원 등으로 LuaJIT 수준의 실행 속도를 목표하며, Roblox를 넘어 다양한 임베디드 환경에서도 활용 가능성이 큼

Motivation (등장 배경)

  • 2006년경 Roblox는 게임 스크립팅 언어로 Lua 5.1을 도입함
  • 시간이 흐르면서 Roblox 플랫폼의 게임 수준이 높아지고 팀 규모가 커짐에 따라 기존 Lua의 한계를 극복하기 위해 언어와 구현을 대폭 개선함
  • 플랫폼의 성장에 따라 성능 최적화, 사용자 친화성, 언어 관련 툴 개발에 많은 투자를 진행했음
  • 특히 2020년 기준 1백만 라인 이상의 대규모 코드베이스를 관리하면서 점진적 타입 시스템의 도입이 필수적임을 인식함
  • 이런 필요성에 기반해 Roblox는 Lua에서 파생된 Luau라는 언어를 개발했으며, 빠르고, 작고, 안전하면서도 점진적으로 타입을 적용할 수 있는 기능을 제공
  • 더 자세한 설명은 Why Luau 문서에 제공

Luau 개요

  • Luau는 Lua 5.1을 기반으로 한 임베디드 스크립트 언어
    • 빠르고 가벼운 런타임 제공
    • 점진적 타입 시스템을 지원하여 동적·정적 분석 병행 가능
  • Roblox Studio에 통합되어 있으며, --!strict 플래그로 엄격 모드 활성화 가능
  • 개발자는 Luau Creator Docs에서 Roblox와 연계된 문서를 확인할 수 있음

Sandboxing (샌드박스 기능)

  • Luau는 노출되는 표준 라이브러리를 제한하고 추가 샌드박싱 기능을 제공함
  • 이를 통해 일반 개발자가 작성한 비권한 코드와 플랫폼 내부의 권한 코드를 안전하게 병렬 실행 가능
  • 이로 인해 기본 Lua와는 다른 실행 환경을 가짐
  • 세부 내용은 Sandbox 설명에서 확인 가능

Compatibility (호환성)

  • 가능한 한 Lua 5.1과의 하위 호환성을 유지하며, 이후 버전의 기능도 일부 반영
  • 하지만 Luau는 Lua의 모든 설계 결정을 수용하지 않음, Roblox 특유의 사용 사례와 제약을 반영함
  • Lua 5.1 이후 버전 기능의 지원 현황은 Compatibility 문서에서 제공됨

Syntax (문법)

  • Lua 5.1 문법과 완전 호환됨
  • 추가적으로 현대적이고 친숙한 구문 확장을 제공하여 개발 편의성을 높임
  • 전체 문법은 Syntax 문서에서 확인 가능

Analysis (분석 도구)

  • 올바른 코드 작성을 돕기 위해 스크립트 분석 도구 제공

  • 구성 요소:

    • Linter: 일반적 오류 탐지
    • Type Checker: 타입 검증

  • luau-analyze CLI 도구로 실행 가능

  • 린트 규칙은 Lint 문서, 타입 체크 가이드는 Typecheck 문서 참조

Performance (성능)

  • 파서, 린터, 타입 체커가 포함된 커스텀 프런트엔드와 최적화된 바이트코드, 인터프리터, 컴파일러 제공
  • 경우에 따라 LuaJIT 인터프리터와 경쟁할 수 있는 성능 제공
  • x64·ARM64 플랫폼에서 수동 JIT 컴파일러 지원, 특정 프로그램 성능을 크게 향상 가능
  • 지속적으로 런타임을 최적화하고 일부를 재작성하여 효율성을 개선 중
  • 성능 세부 특성은 Performance 문서에서 제공됨

Libraries (라이브러리)

  • 언어 자체는 Lua 5.1의 완전한 상위 집합
  • 표준 라이브러리에서는 일부 함수 제거 및 일부 신규 함수 추가
  • 애플리케이션에 내장될 때는 앱별 확장 라이브러리에도 접근 가능
  • 전체 라이브러리 문서는 Library 문서에서 확인 가능
▲
GN⁺ 15시간전  [-]
Hacker News 의견
  • Lumix Engine에서 Lua와 LuaJIT을 사용하다가 타입 시스템 때문에 Luau로 전환한 경험이 있음, 하지만 Roblox 외 프로젝트에서 사용하기 어렵다는 것을 느낌, 문서가 부실하고 커뮤니티가 거의 없어 문제 해결에 도움이 전혀 없음, Lua나 LuaJIT에 비해 사이즈가 커서 컴파일 속도가 7배 느려짐, API의 비동기 처리도 실질적으로는 동기적으로 막혀있고, STL을 사용하는 등 불편함이 많음, 분석 및 LSP 관련 버그도 자주 겪고 있음, 이래서 다른 대안을 찾을까 고민 중임
    • Roblox 팀에서 앞으로 Luau를 Roblox 외부에서도 더 쉽게 활용할 수 있도록 중점을 두고 있음, Remedy Entertainment(Alan Wake 2), Digital Extremes(Warframe), GIANTS Software(Farming Simulator 25) 등 다양한 곳에서 이미 잘 쓰고 있음, 현재 투자와 지원이 Roblox 내부에 집중되어 있었으나 앞으로 일반적인 용도의 독립 런타임인 Lute를 개발 중이며, 다양한 Luau 기반 개발자 도구도 만들어서 에코시스템을 확장하려 함, 아직은 초기 단계지만 외부 사용과 다양한 케이스를 지원하면서 활발하게 투자 중임, 루아우의 건강한 성장을 위해 더 다양한 사용자와 활용 사례를 유치하는 것이 중요하다고 믿음
    • Unity 게임의 전체 플레이 코드(6만 줄 이상)에 Luau를 사용 중임, 문서 특히 커스텀 연동 관련 내용이 보완되었으면 하고, 새로운 타입 시스템과 LSP도 아직 궁합이 별로라고 느낌, zeux가 팀을 떠난 뒤 장기 방향이 조금 걱정되긴 함, 하지만 개발 경험 자체는 매우 마음에 듬, Luau 코드는 게임이 실행 중일 때도 거의 즉시 핫 리로드되고, C++ 프로젝트도 빠르게 컴파일 가능함, 모딩 지원 위해 샌드박스 환경 제공하는 점도 좋음, 공식 Discord 커뮤니티도 어느 정도 활발함
    • 컴파일이 늦어진다고 했는데, 스크립트 언어라면 원래 코드를 컴파일할 필요 없지 않나 궁금함, 혹시 Luau VM 자체의 컴파일을 의미하는지 질문함
  • Roblox가 Node.js 스타일의 데스크톱용 Luau 런타임을 개발 중이라는 점이 정말 흥미로움: https://github.com/luau-lang/lute
    • 이미 더 완성도가 높은 Luau 런타임 Lune이 있음, 빌드 스크립트 및 Roblox place 파일 자동화 작업에 활용 중이고 자신의 사용 목적엔 충분히 만족스럽게 작동함
    • 또 다른 독립형 Luau 런타임으로 Lune이 존재함
  • Luau가 Lua보다 훨씬 복잡한 것으로 보임, 코드를 기준으로 보면 Luau는 C++로 12만 줄이고 Lua 5.1은 C로 1만4천 줄임, 점진적 또는 정적 타입 시스템이 들어가면 복잡해지는 것은 피할 수 없다고 생각함, 어느 정도 완비된 타입 시스템이 있으면 동적 스크립트 언어보다 결국 클 수밖에 없음
    • Lua(그리고 Luau도 어느 정도)는 코드 줄수가 아니라 언어 자체를 습득할 때는 작은 편임, 실행에 필요한 런타임은 Analysis에 전적으로 의존하지 않아도 됨, Analysis에는 두 개의 완전한 타입 시스템이 들어있는데, 최근 3년간 근본적 한계를 해결하기 위해 새 타입 시스템을 개발해 왔고, 이제 오래된 것은 곧 걷어낼 예정임, 그러면 코드도 3만 줄 정도 줄일 수 있음
    • 나는 Lua와 Luau가 작은 언어나 단순한 언어라고 생각하진 않음, 복잡함이 반드시 필요한 것도 아닐 수 있음, Bau라는 더 간단하면서 표현력 있는 언어 작업을 하고 있으며 Lua 스타일의 VM도 개발 중임, 이런 소규모 언어는 Reddit에서도 종종 화제가 됨 Bau, Bau VM, r/ProgrammingLanguages
    • 정적 타이핑이나 점진적 타이핑이 복잡성은 높이지만 그 증가 폭은 생각보다 작음, 오히려 동적 스크립팅 언어가 더 복잡할 때도 많음, Hindley–Milner 타입 체커는 코드 한 페이지로 구현 가능한데, 지금 얘기하는 2천 페이지급 복잡함은 과하다고 느낌, H–M은 고차 함수, 제네릭(파라메트릭 다형성), null 포인터도 다루지 않고도 완전하고, 전체 추론이 가능함, 확장도 가능하고, 기본만으로도 C나 Java 1.7 타입 시스템보다 훨씬 강력함
    • Lua의 타입 체커를 직접 작성해 보고 소스도 많이 읽어봤는데, Lua의 1만4천 줄은 코드 밀도가 매우 높은 편임, 보통 수준의 스타일로 쓰면 3-4만 줄 정도 됨, 즉 Lua는 본질적으로 작은 게 아니라 굉장히 간결하게 짜여짐
    • tokei로 분석한 라인 수를 더 세부적으로 나열하면, Analysis 디렉토리가 C++ 6만2천 줄, C 헤더 9천2백 줄, Ast는 C++ 8천4백 줄, CodeGen C++ 2만1천 줄 등, Lua 5.1은 src 전체에서 C 코드가 1만1천 줄, 헤더 1,900줄임
  • Teal과 Luau의 차이가 궁금함, 둘 다 "정적 타입의 Lua 방언"이라고 소개되어 있어서 비교하고 싶음 https://teal-language.org/
    • Teal은 Teal 파일을 Lua로 컴파일해서 JS와 TS의 관계처럼 장단점이 모두 적용됨, Luau는 Lua를 상위호환하는 자체 런타임이 있는데, 타입 시스템만이 아니라 개발 경험 자체를 개선해줌, 따라서 둘은 꽤 다름, Teal은 어디서든 Lua를 쓸 수 있는 장점이 있음, 반면 Luau는 루아우 전용 런타임에서만 돌아가지만 별도의 컴파일 단계가 없어서 개발자 입장에서는 더 나은 사용성이 가능함, 타입 정보도 날리지 않고 활용할 수 있음
    • Teal은 Lua로 트랜스파일되지만 Luau는 Lua의 포크임, 자체 인터프리터 성능, 보안, 문법 확장성 등 폭넓게 변화 가능함, Roblox가 시가총액 1천억 달러에 달할 만큼 크고, 전담 개발자도 여러 명 상주 중임
    • Luau는 "Lua에 타입만 더한 것"이 아니라, 점진적 타입 시스템과 타입 추론에 많은 힘을 싣고 언어 자체도 점진적으로 개선 중임, 개발자 경험과 도구 지원 중심으로 설계하며 바이너리 크기 등은 신경쓰지만, Lua와 같은 엄격한 단순성을 우선순위에 두진 않음, 대규모 C 프로젝트를 Lua에 묶는 용도보다는 개발자가 직접 언어로 좋은 경험을 하게 하는 데 더 초점이 있음
  • Lua가 더 과거와의 호환성을 유지하며 진화하지 못한 점이 아쉬움, 2000년대 후반에 Roblox를 비롯한 여러 프로젝트가 Lua 5.1을 채택했고 현재 Lua는 5.4에 왔지만 구버전 호환성이 잘 유지되지 않았음, LuaJIT 등은 5.1만 지원함, Python 2.x/3.x의 상황과 비슷하지만 Lua 커뮤니티는 대부분 5.1을 계속 쓰는 경향이 있음
    • 실제로는 더 심함, luau와 luaJIT도 공식 lua 프로젝트와 각기 다른 방향으로 발전해서 이제는 서로 미묘하게 호환이 되지 않음, 모두 Lua 5.1에서 분기했지만 이제는 공식 표준이 없어진 듯한 느낌임
    • 큰 차이점은 Lua 커뮤니티는 하위 호환성 유지에 대해 공개적으로 비난하지 않아 다양한 버전별로 코드를 쓰기가 상당히 쉬움
    • 공식 통계를 구하기 어렵지만 체감상 5.1, 5.2 사용자가 5.4보다 많고 5.3도 넘지 못한 것 같음, LuaJIT은 관심은 많지만 실제로 자주 보이진 않음
    • LuaJIT은 Lua 최신 버전(5.2, 5.3)의 기능도 일부 포함하고 더 많은 기능이 있음 https://luajit.org/extensions.html
  • Luau 인터프리터가 LuaJIT과 맞먹는 경우가 있다는 게 제일 흥미로웠음, 성능 페이지에 좋은 설명이 있는데 Roblox의 엔지니어링 역량을 느낄 수 있음 https://luau.org/performance
  • 13살 자녀가 Roblox Studio에 관심을 가지면서 Luau를 알게 되었고 luau.org도 방문해 봤음, Roblox의 엔지니어링이 정말 인상적임
    • Arseny Kapoulkine이 뛰어난 엔지니어임, 그의 블로그나 SNS를 팔로우하면 좋겠음, luau와 Roblox의 렌더링 엔진 외에 meshoptimizer를 만들어서 그래픽 업계에서는 거의 필수로 접하는 라이브러리이고, volk은 Vulkan SDK에도 포함될 정도임
  • Second Life가 기존 Linden Scripting Language에서 Luau로 넘어가는 중임, 전에는 Mono 기반 컴파일이었는데 Mono가 더 이상 유지되지 않아 새 언어가 필요했음, Luau 지원뿐 아니라 기존 LSL 컴파일러가 Luau 실행 엔진을 타겟팅하도록 바뀌었음, 퍼포먼스도 소폭 개선됨, Second Life는 수십만 개의 이벤트 기반 스크립트가 서버에서 돌아가는 독특한 환경이라 리소스 관리가 쉽지 않은데, 비활성 프로그램이 프레임마다 1마이크로초씩 쓰는 게 누적되면 큰 문제가 될 수 있음
    • Luau 베타 환경이 열렸을 때 직접 사용해보니 기존 Mono 시스템보다 성능이 크게 향상됨을 체감했음, 특히 저장(Save) 시 스크립트 검사 속도가 10초에서 즉시로 줄어 개발 효율이 크게 오름, 다만 FiveM에서처럼 코루틴을 간편하게 다루는 CreateThread(fn), Wait(ms) 같은 헬퍼 함수와 Await/Promises 기능이 있으면 더 좋겠음(Luau Promise 구현), FiveM에서는 이런 래퍼 덕분에 스크립트 최적화와 코루틴 관리를 쉽게 함, FiveM의 Lua 스케줄러 예시
    • VM을 바꾼 후 즉시 눈에 띄는 건 기존 오버헤드가 스케줄링, 컨텍스트 전환, 라이브러리 함수 구현에 많았던 점임, Luau는 설계상 프리엠티브 스케줄링이 자연스럽게 지원되어 단순 glue 코드 조율이 훨씬 쉬움, VM 상에서 이를 처리하는 게 AST나 바이트코드 단계에서 상태머신 변환하는 것보다 훨씬 저렴하고 구현도 용이함, idle 프로그램의 마이크로초 단위 오버헤드도 결국 스케줄러가 최적화해야 할 대상임
  • 원래 Lua의 미니멀한 매력이 type inference 때문에 손상된 부분이 있는데, 타입 안전성과 맞교환이니 장단점임, 그런데 --!strict로 선언한 후에도 명백한 타입 위반이 발생해도 아무런 오류나 경고가 없이 코드가 실행되어 당황스러웠음, 기대한 동작과 달랐음
    • 현재 Luau의 타입 시스템은 "필수(strict)"가 아님, 타입 체크 없이 코드를 실행할 수 있고, 데모나 luau 실행 파일로 곧장 실행하면 타입 검사가 적용되지 않음, 만약 임베디드 환경에서 모든 코드를 컴파일 전에 강제로 타입 체크하도록 하면, 기대한 대로 타입 에러가 잡히는 경험을 할 수 있음, 이는 수백만 줄의 Lua 5.1 코드를 한 번에 Luau로 바꿨기에 필연적인 설계임
  • Typed Lua를 늘 원했지만, 동적 언어에 타입체커와 LSP를 완전하게 구현하는 게 꽤 어려웠음, 동적 언어마다 비슷한 구조적 타이핑 문제(TypeScript에서 겪는 문제와 유사함)가 있음, 만약 TypeScript 엔진을 재활용해 Luau 코드도 부분적으로 TypeScript로 변환하고 tsc로 검사한 뒤 다시 오류/결과를 Luau로 매핑한다면, 다양한 동적 언어에 빠른 타입체커를 만들 수 있지 않을까 궁금함
    • 마치 LLVM이 컴파일러를 위한 공통 IR인 것처럼, 타입 시스템용 "중간 언어"로 TypeScript type system을 공통 백엔드로 삼는 것도 가능할 듯함, 나는 다이나믹 언어를 선호하진 않지만 TypeScript 수준의 타입 검사와 도구 지원이 가능하다면 관심이 커질 것임, 안 되는 부분은 포기하고 그게 점진적 타입의 본질이라 생각함, TypeScript 타입 시스템이 Lua 런타임에 들어간다면 꼭 써볼 의향 있음, 루아우 행보에도 관심이 많음
    • Luau에는 이미 훌륭한 Luau Language Server가 있어서 vscode, nvim, zed 등에서 뛰어난 진단과 오토컴플리트, 엄격한 타입 체크가 적용됨, Ruby, Python에서 느꼈던 것보다 훨씬 좋은 개발 경험임, 나는 shell scripting이나 전체 프로그래밍에 루아우를 활용 중이고 seal이라는 node-styled 자체 런타임도 만들었음, Roblox 개발자들은 CI/CD, 테스팅 등에 더 인기 있는 Lune을 쓴다 함
    • TypeScript로 동적 언어의 구석구석까지 타입화하려면 시스템이 너무 복잡해지므로, Rescript나 Gleam처럼 타겟 언어에 일부 제한을 두고 Hindley–Milner 타입 시스템으로 가는 게 더 낫다고 생각함, HM 타입 시스템은 오랜 경험과 이론이 쌓인 덕분에 견고하고 실용적임, 개인적으로 lua로 코드를 내보내는 작은 ML 계열 언어 프로젝트가 없다는 게 의외임, Gleam이 백엔드를 Lua로 지원하면 정말 잘 어울릴 것 같음
    • 이미 존재하는 프로젝트로 TypeScriptToLua가 있음, Love2D에서 꽤 괜찮게 써본 경험 있음
답변달기