Matz가 만든 거라면 Ruby semantics의 한계도 잘 알고 있을 테니 신뢰가 감
제 석사 논문도 AOT JS compiler였는데, 돌아가긴 했지만 입력 데이터 제약이 커서 결국 접었음
당시 JS 개발자들은 스스로 제약을 잘 지키는 쪽에 익숙하지 않았고, JSON.parse처럼 본질적으로 알 수 없는 입력이 걸림돌이었음
지금은 TypeScript 덕분에 그때보다 훨씬 현실적일 수도 있음
일반적인 lambda calculus만 봐도 타입 추론의 한계는 분명하고, Matt Might 쪽 논문이나 Shed-skin Python 작업에서도 비슷한 제약이 드러남 eval, send, method_missing, define_method가 실제 Ruby 코드에서 얼마나 흔한지 궁금하고, 타입 없는 파싱, 예를 들어 JSON 입력은 보통 어떻게 처리하는지도 궁금함
이 설계는 꽤 pragmatic해 보임
Ruby 파싱은 번역 자체보다 더 어려울 정도라서 Prism을 쓰고, 결과는 C를 생성함
기본적인 Ruby semantics 자체는 구현이 그렇게까지 어렵지 않음
반대로 나는 순수 Ruby로 만든 오래된 self-hosting AOT compiler를 붙들고 있는데, 자체 파서를 쓰겠다고 고집해서 일부러 훨씬 힘든 길을 탔음
초반 80%는 대충 만들어도 Ruby 코드 상당수가 돌아간다는 걸 일찍 배웠고, 진짜 어려운 "두 번째 80%"는 Matz가 이번 프로젝트와 mruby에서 뺀 것들, 예를 들면 인코딩이나 온갖 주변 기능들에 몰려 있음
솔직히 Ruby에는 실제 코드에서 한 번도 못 본 기능도 꽤 있어서, 몇몇은 deprecated돼도 이상하지 않다고 봄 send, method_missing, define_method는 아주 흔함
제약은 mruby와 비슷하고, 그런 제약 아래에서도 쓸 곳은 있음 send, method_missing, define_method 지원은 비교적 쉬운 편임
반면 eval() 지원은 엄청 고통스러움
다만 Ruby에서 eval()의 큰 비율은 정적으로 instance_eval의 block 버전으로 환원 가능해서, 그런 경우엔 AOT 컴파일이 꽤 쉬워짐
예를 들어 eval()에 들어가는 문자열을 정적으로 알 수 있거나 분해할 수 있으면 해결 여지가 큼
실제로 많은 eval() 사용은 불필요하거나 단순한 introspection 우회에 가까워서, 정적 검사로 처리 가능함
내 컴파일러도 그게 병목이 되면 거기부터 손댈 생각임
이런 기능이 꽤 많아야 Rails식 magic을 만들 수 있음
타입 없는 JSON ingestion도 아마 그런 메커니즘을 쓸 가능성이 큼
그걸 걷어내면 Crystal만큼 강한 타입은 아니지만 공식 Ruby만큼 메타프로그래밍에 기대지도 않는, 작고 읽기 쉬운 언어가 남음
그래서 잠재력은 꽤 커 보이지만, 결국 시간 지나야 판단 가능함
Ruby를 Objective-C로 컴파일하는 방식이라면 Ruby 기능을 전부 지원하면서도 인터프리터 Ruby보다 더 빠를 수 있을 것 같음
나는 eval을 자주 쓰는 쪽임
안 쓸 수도 있겠지만, 내겐 그게 더 ergonomic함
내 경험상 흥미로운 건 eval, exec, define_method, 그리고 Class.new, Struct.new로 새 클래스를 만드는 패턴임
이들 사용 대부분은 앱 boot 시점이나 파일을 require하는 동안 몰려 있고, 어떤 면에선 이미 컴파일 단계와 비슷함
이건 RubyKaigi 2026에서 Matz가 방금 발표한 것임
실험적이긴 하지만 Claude 도움을 받아 약 한 달 만에 만들었고, 라이브 데모도 성공했음
이름은 Matz의 새 고양이에서 따왔고, 그 고양이 이름은 Card Captor Sakura의 고양이 이름에서 왔으며, 거기서 또 Ruby라는 이름의 캐릭터와 짝을 이룸
사람들이 AI가 프로그램을 처음부터 끝까지 다 만든다는 얘기를 많이 하지만, 더 현실적인 시나리오는 10x programmer를 100x programmer로 만들어 주는 쪽이라고 봄
Matz 같은 사람에겐 100x를 500x로 밀어 올리는 셈일 수도 있음
내 머릿속 최신 Spinel은 Steven Universe 쪽이라서 Spinel/Ruby (Moon) pun은 전혀 못 알아봤는데, 알고 나니 하루가 즐거워졌음
그 고양이 이름 유래 얘기는 Ruby Central drama와 Spinel.coop 창립자들과의 관계를 생각하면 꽤 수상해 보임
프로젝트 이름도 감정적으로 지은 것처럼 느껴짐
분명 엄청 인상적이지만, AI agent 없이는 유지보수 불가능해 보임 spinel_codegen.rb가 2만 1천 줄이고, 어떤 메서드는 중첩이 15단계까지 감
원래 컴파일러 코드는 예쁘기 어렵지만, 이건 그 기준으로도 사람이 관리하기 매우 힘들어 보임
컴파일러 코드는 시간만 있으면 충분히 예쁘게 만들 수 있음
컴파일러는 서브시스템 경계가 뚜렷하고 단계별 handoff도 명확해서, 오히려 가장 modular하게 만들기 쉬운 축에 듦
문제는 대개 일단 돌아가게 만든 뒤 리팩터링할 시간이 없다는 데 있고, 그러면 지저분함이 계속 불어남
spinel_codegen.rb는 거의 eldritch horror 수준임
Claude를 쓰면 나도 늘 이런 스파게티 코드가 나오는데, 내가 뭘 잘못하고 있나 싶었음
그런데 최고 수준 프로그래머라고 생각하는 사람이 만든 진짜 흥미로운 프로젝트에서도 코드 질이 군데군데 꽤 나쁜 걸 보니, 나만 그런 건 아니었음
예를 들어 infer_comparison_type()은 최악의 사례까진 아니고 읽기 어렵지도 않지만, 훨씬 더 단순하고 명확한 구현이 있는데도 Claude가 거기로 못 감 Set으로 비교 연산자를 모아두고 include?로 처리하면 더 짧고 빠르고 읽기 쉽고 유지보수도 쉬움
그런데 Claude는 늘 if-return 연쇄로 흘러가고, 심지어 if-else조차 낯설어하는 느낌임
내 Claude 코드베이스도 그런 패턴으로 가득한데, 이제 나만 그런 게 아니라는 걸 알겠음
반면 다른 파일들은 훨씬 낫고, 특히 lib 디렉터리는 메인 Ruby repo의 ext 디렉터리와 대응되는 듯하며 품질이 괜찮음
API도 MRI Ruby 영향을 분명히 받았고, 구현은 꽤 다르더라도 Matz가 원본 API 일부를 닮게 유도해서 출력이 더 정돈된 것 같음
[1] https://github.com/matz/spinel/blob/98d1179670e4d6486bbd1547...
지금 단계에선 사람이 손으로 유지보수 가능한지가 그렇게 중요하진 않다고 봄
테스트와 벤치마크만 통과하면 일단 만족함
다만 거대한 파일이 AI에게도 다루기 쉬운지는 의문임
나는 파일을 300줄 안쪽으로 제한하려고 하고, 사람이 이해하기 쉬운 코드가 coding agents에게도 쉬울 거라고 생각함
제약은 이렇다고 함 No eval: eval, instance_eval, class_eval No metaprogramming: send, method_missing, define_method(동적) No threads: Thread, Mutex(Fiber는 지원) No encoding: UTF-8/ASCII 가정 No general lambda calculus: [] 호출을 동반한 깊은 중첩 -> x { }
UTF-8/ASCII 가정은 개인적으로 큰 제약이 아니지만, 나머지는 꽤 많은 프로그램에서 실제 제약이 될 듯함
그리고 이걸 다시 넣으려면 상당한 작업이 필요해 보임
이러면 Ruby의 magic 상당 부분이 사라짐
Ruby를 오래 써 왔고, 나열된 기능을 전부 활용해 본 입장에서 보면, 오히려 내가 진화 끝에 원하게 된 건 이런 버전의 단순한 Ruby임
더 단순하고 이해하기 쉬운데도 Ruby 특유의 미적 감각은 남아 있음
이제는 LLM 덕분에 코드 생성 생산성이 워낙 높아서, 예전처럼 개발자 생산성을 위해 메타프로그래밍으로 boilerplate를 줄일 필요가 덜함
개발자가 직접 코드를 쓰는 비중 자체가 줄고 있기 때문임
그게 원하는 게 단지 Ruby aesthetic이라면 Crystal도 잘 맞을 수 있음
문법은 비슷하고 정적 타입 시스템이 있어서, 더 효율적인 컴파일 코드로 이어짐
eval이 없는 건 차라리 낫다고 보지만, threads와 mutexes까지 없는 건 아쉬움 define_method 부재는 용도를 생각하면 이해가 감
하지만 send와 method_missing은 기존 라이브러리에서 흔하고, 구현도 메모리 lookup table을 컴파일 시점에 구성하는 식으로 아주 어렵진 않을 것 같음
그래서 의도적으로 뺀 건지, 아직 거기까지 못 간 건지 모르겠음
내 바람은 후자지만, 최소한 당장은 호환성 때문에 실무 투입은 어려울 듯함
메타프로그래밍의 장점은 원래 코드를 덜 쓰는 것이 아니었음 읽어야 할 코드를 줄이는 것이었음
이거 정말 멋지고, 나는 오랫동안 Ruby용 AOT compiler를 기다려 왔음
다만 eval이나 메타프로그래밍 fallback이 없는 건 아쉽고, 그래도 작은 고성능 subset에 집중하려고 그렇게 한 것 같음
이 AOT 컴파일러로 만든 gem이 MRI와 잘 상호작용하면 좋겠음
표준 Ruby와 gem을 패키징하거나 번들링하는 쪽은 여전히 tebako, kompo, ocran이 필요하고, 예전엔 ruby-packer, traveling ruby, jruby warbler 같은 프로젝트들도 있었음
선택지가 하나 더 생긴 건 좋지만, 더 나은 개발자 UX를 갖춘 결정판이 나오길 바라고 있음
맞음, 나도 최근에 warbler를 포크해야 했음
너무 오랫동안 업데이트가 없었기 때문임
왜 no threads인지 궁금함
Ruby scheduler와 밑단의 pthread 구현은 C 영역에서도 잘 동작할 것 같은데, 혹시 zero dependency를 노린 건가 싶음
optional extension을 나중에 넣을 계획이거나 아직 뺀 상태가 아니라면, 이 선택은 좀 이상하게 느껴짐
이걸 의도적으로 지원 안 하기로 결정했다는 근거는 아직 못 봤음
아마 그냥 아직 거기까지 못 간 것 아닐까 싶음
멀티스레딩은 원래 제대로 만들기 아주 어려움
한 달 조금 넘는 기간에 만들었다니 놀라움
AI에 대해 뭐라 하든, 실력 있는 개발자 손에 들어가면 엄청난 속도 향상을 만들어 냄
업계 전체는 agent harness, SOUL.md, 권한 설정, skills, MCPs, hooks, env 다 깔고 시작하는데
Matz는 그냥 gem env|info랑 find면 충분한 느낌임
이게 Matz가 만든 만큼, 앞으로 Ruby core의 일부가 될 가능성이 얼마나 현실적인지 궁금함
그리고 그렇게 되면 Crystal에 얼마나 위협적일지도 궁금함
Crystal은 명시적인 static type system이 있고, 언어 차원에서 AOT 컴파일에 최적화돼 있음
이런 특성은 큰 프로그램을 컴파일하고 유지하는 데 사실상 필수에 가까움
반면 이건 제한된 Ruby subset용이라서, 인기 있는 Ruby gem 대부분은 그대로는 돌아가지 않을 것임
C 컴파일을 지향하는 언어 subset이라는 점에서 PreScheme에 더 가까워 보임
지금 단계에선 둘이 같은 영역에서 직접 경쟁한다고 보지 않음
완전한 Ruby는 거의 확실히 JIT가 필요함
[1]: https://prescheme.org/
다른 관점으로 보면, 결국은 LLM이 우리가 원하는 어떤 언어로든 formal specification을 쏟아내는 지점에 도달할 것 같음
Rational Unified Process, Enterprise Architect 같은 도구들의 복수전이 벌어지는 셈임
차이가 있다면 UML 다이어그램 대신 markdown 파일이 온다는 정도임
이건 infrastructure tools 쪽에서 유용할 것 같음
예를 들어 Ruby로 쓰였지만 정적으로 컴파일되는 bundler가 있어서, RVM 같은 Ruby 설치 도구 역할까지 같이 해 준다고 상상해 볼 수 있음
기존 Ruby buildpack은 Ruby로 작성돼 있지만 부트스트랩을 bash로 해야 해서 짜증나고 edge case도 생김
CNB는 그 문제를 피하려고 Rust로 쓰였고, 의존성 없는 단일 바이너리를 배포할 수 있다는 발상은 정말 강력함
Hacker News 의견들
Matz가 만든 거라면 Ruby semantics의 한계도 잘 알고 있을 테니 신뢰가 감
제 석사 논문도 AOT JS compiler였는데, 돌아가긴 했지만 입력 데이터 제약이 커서 결국 접었음
당시 JS 개발자들은 스스로 제약을 잘 지키는 쪽에 익숙하지 않았고,
JSON.parse처럼 본질적으로 알 수 없는 입력이 걸림돌이었음지금은 TypeScript 덕분에 그때보다 훨씬 현실적일 수도 있음
일반적인 lambda calculus만 봐도 타입 추론의 한계는 분명하고, Matt Might 쪽 논문이나 Shed-skin Python 작업에서도 비슷한 제약이 드러남
eval,send,method_missing,define_method가 실제 Ruby 코드에서 얼마나 흔한지 궁금하고, 타입 없는 파싱, 예를 들어 JSON 입력은 보통 어떻게 처리하는지도 궁금함Ruby 파싱은 번역 자체보다 더 어려울 정도라서 Prism을 쓰고, 결과는 C를 생성함
기본적인 Ruby semantics 자체는 구현이 그렇게까지 어렵지 않음
반대로 나는 순수 Ruby로 만든 오래된 self-hosting AOT compiler를 붙들고 있는데, 자체 파서를 쓰겠다고 고집해서 일부러 훨씬 힘든 길을 탔음
초반 80%는 대충 만들어도 Ruby 코드 상당수가 돌아간다는 걸 일찍 배웠고, 진짜 어려운 "두 번째 80%"는 Matz가 이번 프로젝트와 mruby에서 뺀 것들, 예를 들면 인코딩이나 온갖 주변 기능들에 몰려 있음
솔직히 Ruby에는 실제 코드에서 한 번도 못 본 기능도 꽤 있어서, 몇몇은 deprecated돼도 이상하지 않다고 봄
send,method_missing,define_method는 아주 흔함제약은 mruby와 비슷하고, 그런 제약 아래에서도 쓸 곳은 있음
send,method_missing,define_method지원은 비교적 쉬운 편임반면 eval() 지원은 엄청 고통스러움
다만 Ruby에서
eval()의 큰 비율은 정적으로 instance_eval의 block 버전으로 환원 가능해서, 그런 경우엔 AOT 컴파일이 꽤 쉬워짐예를 들어
eval()에 들어가는 문자열을 정적으로 알 수 있거나 분해할 수 있으면 해결 여지가 큼실제로 많은
eval()사용은 불필요하거나 단순한 introspection 우회에 가까워서, 정적 검사로 처리 가능함내 컴파일러도 그게 병목이 되면 거기부터 손댈 생각임
타입 없는 JSON ingestion도 아마 그런 메커니즘을 쓸 가능성이 큼
그걸 걷어내면 Crystal만큼 강한 타입은 아니지만 공식 Ruby만큼 메타프로그래밍에 기대지도 않는, 작고 읽기 쉬운 언어가 남음
그래서 잠재력은 꽤 커 보이지만, 결국 시간 지나야 판단 가능함
eval을 자주 쓰는 쪽임안 쓸 수도 있겠지만, 내겐 그게 더 ergonomic함
eval,exec,define_method, 그리고Class.new,Struct.new로 새 클래스를 만드는 패턴임이들 사용 대부분은 앱 boot 시점이나 파일을 require하는 동안 몰려 있고, 어떤 면에선 이미 컴파일 단계와 비슷함
이건 RubyKaigi 2026에서 Matz가 방금 발표한 것임
실험적이긴 하지만 Claude 도움을 받아 약 한 달 만에 만들었고, 라이브 데모도 성공했음
이름은 Matz의 새 고양이에서 따왔고, 그 고양이 이름은 Card Captor Sakura의 고양이 이름에서 왔으며, 거기서 또 Ruby라는 이름의 캐릭터와 짝을 이룸
Matz 같은 사람에겐 100x를 500x로 밀어 올리는 셈일 수도 있음
https://en.wikipedia.org/wiki/Spinel
영상은 아직 라이브가 아닌 것 같고, 여기 채널에 하나씩 올라오는 듯함
https://www.youtube.com/@rubykaigi4884/videos
프로젝트 이름도 감정적으로 지은 것처럼 느껴짐
분명 엄청 인상적이지만, AI agent 없이는 유지보수 불가능해 보임
spinel_codegen.rb가 2만 1천 줄이고, 어떤 메서드는 중첩이 15단계까지 감원래 컴파일러 코드는 예쁘기 어렵지만, 이건 그 기준으로도 사람이 관리하기 매우 힘들어 보임
컴파일러는 서브시스템 경계가 뚜렷하고 단계별 handoff도 명확해서, 오히려 가장 modular하게 만들기 쉬운 축에 듦
문제는 대개 일단 돌아가게 만든 뒤 리팩터링할 시간이 없다는 데 있고, 그러면 지저분함이 계속 불어남
spinel_codegen.rb는 거의 eldritch horror 수준임Claude를 쓰면 나도 늘 이런 스파게티 코드가 나오는데, 내가 뭘 잘못하고 있나 싶었음
그런데 최고 수준 프로그래머라고 생각하는 사람이 만든 진짜 흥미로운 프로젝트에서도 코드 질이 군데군데 꽤 나쁜 걸 보니, 나만 그런 건 아니었음
예를 들어
infer_comparison_type()은 최악의 사례까진 아니고 읽기 어렵지도 않지만, 훨씬 더 단순하고 명확한 구현이 있는데도 Claude가 거기로 못 감Set으로 비교 연산자를 모아두고include?로 처리하면 더 짧고 빠르고 읽기 쉽고 유지보수도 쉬움그런데 Claude는 늘 if-return 연쇄로 흘러가고, 심지어 if-else조차 낯설어하는 느낌임
내 Claude 코드베이스도 그런 패턴으로 가득한데, 이제 나만 그런 게 아니라는 걸 알겠음
반면 다른 파일들은 훨씬 낫고, 특히
lib디렉터리는 메인 Ruby repo의ext디렉터리와 대응되는 듯하며 품질이 괜찮음API도 MRI Ruby 영향을 분명히 받았고, 구현은 꽤 다르더라도 Matz가 원본 API 일부를 닮게 유도해서 출력이 더 정돈된 것 같음
[1] https://github.com/matz/spinel/blob/98d1179670e4d6486bbd1547...
테스트와 벤치마크만 통과하면 일단 만족함
다만 거대한 파일이 AI에게도 다루기 쉬운지는 의문임
나는 파일을 300줄 안쪽으로 제한하려고 하고, 사람이 이해하기 쉬운 코드가 coding agents에게도 쉬울 거라고 생각함
제약은 이렇다고 함
No eval:
eval,instance_eval,class_evalNo metaprogramming:
send,method_missing,define_method(동적)No threads:
Thread,Mutex(Fiber는 지원)No encoding: UTF-8/ASCII 가정
No general lambda calculus:
[]호출을 동반한 깊은 중첩-> x { }UTF-8/ASCII 가정은 개인적으로 큰 제약이 아니지만, 나머지는 꽤 많은 프로그램에서 실제 제약이 될 듯함
그리고 이걸 다시 넣으려면 상당한 작업이 필요해 보임
Ruby를 오래 써 왔고, 나열된 기능을 전부 활용해 본 입장에서 보면, 오히려 내가 진화 끝에 원하게 된 건 이런 버전의 단순한 Ruby임
더 단순하고 이해하기 쉬운데도 Ruby 특유의 미적 감각은 남아 있음
이제는 LLM 덕분에 코드 생성 생산성이 워낙 높아서, 예전처럼 개발자 생산성을 위해 메타프로그래밍으로 boilerplate를 줄일 필요가 덜함
개발자가 직접 코드를 쓰는 비중 자체가 줄고 있기 때문임
문법은 비슷하고 정적 타입 시스템이 있어서, 더 효율적인 컴파일 코드로 이어짐
eval이 없는 건 차라리 낫다고 보지만, threads와 mutexes까지 없는 건 아쉬움define_method부재는 용도를 생각하면 이해가 감하지만
send와method_missing은 기존 라이브러리에서 흔하고, 구현도 메모리 lookup table을 컴파일 시점에 구성하는 식으로 아주 어렵진 않을 것 같음그래서 의도적으로 뺀 건지, 아직 거기까지 못 간 건지 모르겠음
내 바람은 후자지만, 최소한 당장은 호환성 때문에 실무 투입은 어려울 듯함
읽어야 할 코드를 줄이는 것이었음
이거 정말 멋지고, 나는 오랫동안 Ruby용 AOT compiler를 기다려 왔음
다만
eval이나 메타프로그래밍 fallback이 없는 건 아쉽고, 그래도 작은 고성능 subset에 집중하려고 그렇게 한 것 같음이 AOT 컴파일러로 만든 gem이 MRI와 잘 상호작용하면 좋겠음
표준 Ruby와 gem을 패키징하거나 번들링하는 쪽은 여전히 tebako, kompo, ocran이 필요하고, 예전엔 ruby-packer, traveling ruby, jruby warbler 같은 프로젝트들도 있었음
선택지가 하나 더 생긴 건 좋지만, 더 나은 개발자 UX를 갖춘 결정판이 나오길 바라고 있음
너무 오랫동안 업데이트가 없었기 때문임
왜 no threads인지 궁금함
Ruby scheduler와 밑단의 pthread 구현은 C 영역에서도 잘 동작할 것 같은데, 혹시 zero dependency를 노린 건가 싶음
optional extension을 나중에 넣을 계획이거나 아직 뺀 상태가 아니라면, 이 선택은 좀 이상하게 느껴짐
아마 그냥 아직 거기까지 못 간 것 아닐까 싶음
멀티스레딩은 원래 제대로 만들기 아주 어려움
한 달 조금 넘는 기간에 만들었다니 놀라움
AI에 대해 뭐라 하든, 실력 있는 개발자 손에 들어가면 엄청난 속도 향상을 만들어 냄
Matz는 그냥
gem env|info랑find면 충분한 느낌임이게 Matz가 만든 만큼, 앞으로 Ruby core의 일부가 될 가능성이 얼마나 현실적인지 궁금함
그리고 그렇게 되면 Crystal에 얼마나 위협적일지도 궁금함
이런 특성은 큰 프로그램을 컴파일하고 유지하는 데 사실상 필수에 가까움
반면 이건 제한된 Ruby subset용이라서, 인기 있는 Ruby gem 대부분은 그대로는 돌아가지 않을 것임
C 컴파일을 지향하는 언어 subset이라는 점에서 PreScheme에 더 가까워 보임
지금 단계에선 둘이 같은 영역에서 직접 경쟁한다고 보지 않음
완전한 Ruby는 거의 확실히 JIT가 필요함
[1]: https://prescheme.org/
Rational Unified Process, Enterprise Architect 같은 도구들의 복수전이 벌어지는 셈임
차이가 있다면 UML 다이어그램 대신 markdown 파일이 온다는 정도임
이건 infrastructure tools 쪽에서 유용할 것 같음
예를 들어 Ruby로 쓰였지만 정적으로 컴파일되는 bundler가 있어서, RVM 같은 Ruby 설치 도구 역할까지 같이 해 준다고 상상해 볼 수 있음
기존 Ruby buildpack은 Ruby로 작성돼 있지만 부트스트랩을 bash로 해야 해서 짜증나고 edge case도 생김
CNB는 그 문제를 피하려고 Rust로 쓰였고, 의존성 없는 단일 바이너리를 배포할 수 있다는 발상은 정말 강력함