여기 댓글들이 이 커뮤니티에서 기대한 것보다 훨씬 가혹하게 느껴짐
Lua 같은 다른 언어로도 충분했을 가능성은 있음. 작성자가 거대한 yak shaving에 빠졌을 가능성도 있음
그래도 실력이 뛰어나고 아주 즐기고 있다는 건 분명하고, 글 안에 흥미로운 기술 내용도 있음
게임 엔진용 스크립트 언어를 또 하나 설계하는 동료 너드의 글이라면 기꺼이 즐겁게 읽겠음. vibecoding으로 만든 SaaS 쓰레기가 세상을 구하고 작성자를 부자로 만들어 준다는 AI 생성 잡글 하나를 피할 수 있다면, 이런 글은 하루에 천 개라도 읽을 수 있음
“Lua 또는 다른 JIT 컴파일 스크립트 언어는 표준 선택지지만 샌드박싱이 정말 어렵다”는 건 정말 이해하기 어려운 주장임 Lua의 샌드박싱이 쉽다는 점은 가장 큰 장점 중 하나고, 모드나 플러그인 말고도 큰 이점을 줌. 내가 본 어떤 언어도 여기에 근접하지 못했음
그 문단 전체가 “이 언어에 대해 읽어보긴 했지만, 지난 20년간 표준 선택지였는데도 몇 시간 조사할 생각은 없다”처럼 읽힘 Lua 버전 문제는 어느 정도 일리가 있지만, 실제로 사람들이 크게 분통 터뜨리는 건 별로 못 봤음. “현대적” Lua를 어떤 용도로 쓰다가 다른 작업 때문에 5.1/5.2로 내려가야 하는 경우가 아니라면, 대부분은 둘 중 하나만 쓰는 듯함
“흔한 가능성”이 애초에 Lua와 C++ 뿐이라는 게 꽤 이상함. 존재하는 언어 부류가 딱 두 가지뿐이라는 건가 싶음
“내 언어를 만들고 싶다”를 합리화하기 위해 조사한 느낌이 강함. 그 자체는 괜찮지만, 기존 선택지에 대해 완전히 틀린 주장을 하기보다는 솔직한 편이 낫다
이 글에서 또 걸리는 점은 언어 설계를 배우고 싶다면, 맨바닥까지 내려가기보다 기존 가상 머신이나 런타임을 대상으로 하는 호스트 언어용 컴파일러를 작성하는 쪽이 훨씬 좋다는 것임
가상 머신 설계나 더 낮은 수준의 부분에 관심이 있다면 글에서 설명한 방식도 물론 가능함. 하지만 언어 설계를 배우는 최고의 방법과는 거리가 멂
실력 있는 프로그래머들이 만든 게임들도 Lua 샌드박스 탈출을 겪은 적이 꽤 있음. Factorio, Binding of Isaac, 그리고 클라우드 프로그래밍을 모두가 지는 괴상한 게임으로 본다면 ~~Redis~~도 그렇고, 그래서 API가 제시되는 방식에 뭔가 문제가 있는지 의심됨
가장 쉬운 예는 바이트코드 탈출임. 존재를 알면 비활성화하면 되지만, 이런 일이 반복된다는 사실은 더 넓은 문제를 드러냄. Lua 명세의 서로 떨어진 부분들이 상호작용하는 방식을 이해해서 샌드박싱 규칙을 조립해야 하지, 어떤 추가 상호작용을 허용하는지 명확한 기본 요소들로 프로그램을 안전하게 합성할 수 있는 구조가 아님
더 억지스러운 예로는 같은 Lua VM 안의 서로 다른 환경 사이에서 일어나는 프로토타입 오염이 있음. Redis에서는 string의 metatable을 오염시킬 수 있었고, 그러면 Lua 기능을 쓰는 다른 데이터베이스 사용자 권한으로 코드를 실행할 수 있었음. Lua는 JavaScript 같은 것보다 프로토타입 오염 표면이 천문학적으로 작지만, 전역 프로토타입이 대략 2개뿐인데도 그중 하나로 똑같은 일을 할 수 있다는 게 웃김
그렇긴 해도 Luau는 이 문제에 꽤 유능한 해법을 갖고 있고, 작성자가 새 샌드박스를 만들면 왜 같은 문제들을 암묵적으로 모두 피할 수 있다고 보는지는 잘 모르겠음
“내 게임은 시뮬레이션 비중이 매우 높다. 커스텀 ECS 엔진으로 수십만 개 엔티티를 시뮬레이션한다. 이상적으로는 모딩 언어가 여러 컴포넌트 포인터를 받아 C의 for 루프처럼 순회할 수 있으면 좋겠다”는 부분은 더 나은 이상을 가질 수 있음
특히 Unity, Unreal, Blender, Godot 같은 렌더링 엔진들이 이 문제를 어떻게 다루는지 비교해볼 만함. 외부 반복은 초당 메가픽셀 단위를 논하기엔 충분히 빠르지 않고, 초당 수십만 엔티티에도 맞지 않을 수 있음. 여기서는 병렬성을 생각해야 함
대형 엔진들은 모두 GPU 친화적이고 대개 당황스러울 정도로 병렬화 가능한 분기 없는 알고리즘의 데이터플로 서술을 사용함. 작성자가 시각 편집기를 싫어할 수는 있고, 그런 생각도 흔하지만, 그렇다고 for 루프가 답이라는 뜻은 아님
만약 작성자가 ECS가 본질적으로 관계형 패러다임이고, 비교 대상으로 삼아야 할 역사적 짐이 많은 언어가 SQL이라고 언급했다면 좀 더 너그럽게 봤을지도 모르겠음
Lobste.rs 의견들
여기 댓글들이 이 커뮤니티에서 기대한 것보다 훨씬 가혹하게 느껴짐
Lua 같은 다른 언어로도 충분했을 가능성은 있음. 작성자가 거대한 yak shaving에 빠졌을 가능성도 있음
그래도 실력이 뛰어나고 아주 즐기고 있다는 건 분명하고, 글 안에 흥미로운 기술 내용도 있음
게임 엔진용 스크립트 언어를 또 하나 설계하는 동료 너드의 글이라면 기꺼이 즐겁게 읽겠음. vibecoding으로 만든 SaaS 쓰레기가 세상을 구하고 작성자를 부자로 만들어 준다는 AI 생성 잡글 하나를 피할 수 있다면, 이런 글은 하루에 천 개라도 읽을 수 있음
“Lua 또는 다른 JIT 컴파일 스크립트 언어는 표준 선택지지만 샌드박싱이 정말 어렵다”는 건 정말 이해하기 어려운 주장임
Lua의 샌드박싱이 쉽다는 점은 가장 큰 장점 중 하나고, 모드나 플러그인 말고도 큰 이점을 줌. 내가 본 어떤 언어도 여기에 근접하지 못했음
Lua 버전 문제는 어느 정도 일리가 있지만, 실제로 사람들이 크게 분통 터뜨리는 건 별로 못 봤음. “현대적” Lua를 어떤 용도로 쓰다가 다른 작업 때문에 5.1/5.2로 내려가야 하는 경우가 아니라면, 대부분은 둘 중 하나만 쓰는 듯함
“내 언어를 만들고 싶다”를 합리화하기 위해 조사한 느낌이 강함. 그 자체는 괜찮지만, 기존 선택지에 대해 완전히 틀린 주장을 하기보다는 솔직한 편이 낫다
가상 머신 설계나 더 낮은 수준의 부분에 관심이 있다면 글에서 설명한 방식도 물론 가능함. 하지만 언어 설계를 배우는 최고의 방법과는 거리가 멂
가장 쉬운 예는 바이트코드 탈출임. 존재를 알면 비활성화하면 되지만, 이런 일이 반복된다는 사실은 더 넓은 문제를 드러냄. Lua 명세의 서로 떨어진 부분들이 상호작용하는 방식을 이해해서 샌드박싱 규칙을 조립해야 하지, 어떤 추가 상호작용을 허용하는지 명확한 기본 요소들로 프로그램을 안전하게 합성할 수 있는 구조가 아님
더 억지스러운 예로는 같은 Lua VM 안의 서로 다른 환경 사이에서 일어나는 프로토타입 오염이 있음. Redis에서는 string의 metatable을 오염시킬 수 있었고, 그러면 Lua 기능을 쓰는 다른 데이터베이스 사용자 권한으로 코드를 실행할 수 있었음. Lua는 JavaScript 같은 것보다 프로토타입 오염 표면이 천문학적으로 작지만, 전역 프로토타입이 대략 2개뿐인데도 그중 하나로 똑같은 일을 할 수 있다는 게 웃김
그렇긴 해도 Luau는 이 문제에 꽤 유능한 해법을 갖고 있고, 작성자가 새 샌드박스를 만들면 왜 같은 문제들을 암묵적으로 모두 피할 수 있다고 보는지는 잘 모르겠음
“내 게임은 시뮬레이션 비중이 매우 높다. 커스텀 ECS 엔진으로 수십만 개 엔티티를 시뮬레이션한다. 이상적으로는 모딩 언어가 여러 컴포넌트 포인터를 받아 C의 for 루프처럼 순회할 수 있으면 좋겠다”는 부분은 더 나은 이상을 가질 수 있음
특히 Unity, Unreal, Blender, Godot 같은 렌더링 엔진들이 이 문제를 어떻게 다루는지 비교해볼 만함. 외부 반복은 초당 메가픽셀 단위를 논하기엔 충분히 빠르지 않고, 초당 수십만 엔티티에도 맞지 않을 수 있음. 여기서는 병렬성을 생각해야 함
대형 엔진들은 모두 GPU 친화적이고 대개 당황스러울 정도로 병렬화 가능한 분기 없는 알고리즘의 데이터플로 서술을 사용함. 작성자가 시각 편집기를 싫어할 수는 있고, 그런 생각도 흔하지만, 그렇다고 for 루프가 답이라는 뜻은 아님
만약 작성자가 ECS가 본질적으로 관계형 패러다임이고, 비교 대상으로 삼아야 할 역사적 짐이 많은 언어가 SQL이라고 언급했다면 좀 더 너그럽게 봤을지도 모르겠음