나는 루비가 충분히 동적이지 않다고 생각한다…
Source: Dev.to
Introduction
이 글은 솔직히 말하면 기술적인 기사라기보다 개인적인 잡담에 가깝습니다.
몇 년 동안 저는 어느 정도 크리스탈(Crystal) 신자가 되었습니다. 그 관점에서 최근 루비(Ruby)의 움직임을 바라보면 가끔 “그게 바로 크리스탈 사람들이 수년간 파고들어 온 영역이고, 루비의 진정한 강점은 그쪽에 있지 않은가…?” 라는 생각이 듭니다. 이 느낌을 많은 사람들과 나누지 못해서 답답했습니다.
저는 루비와 크리스탈만을 제대로 이해하고 있기 때문에 제 생각에 대한 확신이 부족했고, 다소 막연한 상태로 시간을 보냈습니다. 이런 생각들을 글로 적어두면 정리하는 데 도움이 되니, 용기를 내어 이 개인 에세이를 쓰기로 했습니다.
Missing Reversibility in Ruby
제가 루비에서 느끼는 불완전함은 많은 연산에 역전 가능성(reversibility) 이 부족하다는 점입니다. 변수를 정의할 수는 있지만, 깔끔하게 삭제하기는 어렵습니다. 모듈을 include 할 수는 있지만 de‑include 은 없습니다. remove_method, remove_const, undef_method, UnboundMethod, define_method 와 같은 메커니즘은 존재하지만, 메서드나 행동을 한 구조에서 빼내어 다른 객체 구조에 안전하게 옮기는 일에 일관된 역전 모델이 없는 듯합니다.
루비는 동적 언어(dynamic language)로 간주되며 런타임에 모든 종류의 변화를 허용합니다. 하지만 그 자유는 주로 “나중에 무언가를 추가한다”는 방향으로 강하게 작용하는 것 같습니다. 추가된 것을 제거하거나, 구조를 분해해 다른 형태로 재조립하거나, 그런 변화를 되돌리는 메커니즘은 크게 체계화되지 않은 듯합니다.
아마도 루비는 동적 언어가 가져야 할 충분한 특성을 갖추지 못했을지도 모릅니다.
A More Dynamic Ruby?
이상적으로는 머신러닝처럼 입력 데이터와 기대 출력만 주어지면 메타‑레벨에서 런타임에 객체 구조를 최적화하는 방법을 탐색할 수 있는 루비 구현이 있으면 흥미로울 것입니다. 이를 위한 기반으로는 자신이 만든 객체를 관찰하고, 변형하고, 재구성할 수 있는 메커니즘이 필요할 것이라 상상하지만, 그런 것이 실제로 가능한지는 잘 모릅니다.
그런 것이 실현된다 하더라도 실제로는 두 단계로 나뉘게 될 가능성이 있습니다:
- 학습이나 컴파일을 통한 객체 구조 생성
- 생성된 구조의 실행
그렇게 되면 꽤 지루할 것 같습니다.
Comparison with Crystal
저는 크리스탈에 깊이 빠져 있어 루비와는 조금 거리를 두게 되었습니다. 어떤 사람들은 루비가 크리스탈 같은 일을 더 많이 할 수 있게 되어야 한다고 생각할지도 모릅니다. 하지만 실제로 필요한 것은 그 반대입니다. 크리스탈은 탈피할 수 없는 구조적 제약을 가지고 있습니다. 루비와 같은 유연성에 제약을 두어 속도와 낮은 메모리 사용량을 달성합니다. 저는 크리스탈 신자로서, 언어가 크리스탈‑같은 일을 하길 원한다면 크리스탈이 더 적합하다고 생각합니다. 루비가 같은 일을 하려는 건 흥미롭지 않으며, 저는 오직 루비만이 할 수 있는 일을 보고 싶습니다.
루비는 크리스탈에 비해 산업용 프로그래밍 언어이기 때문에 자유롭게 움직일 수 없는 부분이 있습니다. 런타임에 객체 구조를 자유롭게 변형할 수 있는 언어는 위험하고 산업계에서 환영받지 못할 가능성이 높습니다. 그럼에도 불구하고, 주류 언어들 중에서 루비가 마치 가장 동적인 언어인 것처럼 취급되는 것이 이상하지 않나요? 루비보다 더 동적인 언어 세계가 아직도 넓은 미지의 영역으로 남아 있다는 느낌을 떨칠 수 없습니다.
Conclusion
언젠가 프로그래밍 자체의 세계를 더욱 동적인 영역으로 확장하려는 시도가 나오기를 바랍니다.
이 게시물은 일본어를 영어로 번역한 뒤, ChatGPT를 이용해 한국어로 번역되었습니다.