마츠모토 유키히로의 프로그래밍 여정과 루비의 미래

[Euruko 2025] “My favorite things” – Yukihiro "Matz" Matsumoto (Creator of Ruby, Japan)

작성자
EuRuKo
발행일
2025년 10월 13일

핵심 요약

  • 1 루비 창시자 마츠모토 유키히로(Matz)는 BASIC으로 시작해 파스칼을 거쳐 자신만의 언어를 만들겠다는 꿈을 키웠으며, 프로그래밍 언어에 대한 깊은 사랑과 자유 소프트웨어 철학을 바탕으로 루비를 탄생시켰습니다.
  • 2 루비는 초기 '즐거움'을 중시하는 디자인 철학에서 시작했으나, YARV, YJIT, ZJIT 등 커뮤니티와 기업의 기여를 통해 성능을 지속적으로 개선하고 있으며, AI 시대에 더욱 빛을 발할 간결한 언어로서의 잠재력을 강조합니다.
  • 3 Matz는 유닉스 철학과 객체지향의 장점을 결합한 루비의 설계, Emacs와 AI(Cloud Code)를 활용한 개인적인 개발 경험을 공유하며, 루비의 부침 속에서도 공동체의 가치와 지속적인 발전을 최우선으로 삼는 비전을 제시합니다.

도입

마츠모토 유키히로(Matz)는 유로코(Eurokco) 컨퍼런스에서 자신의 프로그래밍 여정과 루비에 대한 깊은 애정을 공유합니다. 어린 시절 BASIC 프로그래밍의 한계에서 좌절을 겪었으나, 파스칼을 통해 추상화와 사용자 정의 기능의 중요성을 깨닫고 자신만의 프로그래밍 언어를 만들겠다는 꿈을 꾸게 됩니다. 이 강연은 그가 프로그래밍 언어를 사랑하게 된 배경과 루비 탄생의 철학을 탐구합니다.

프로그래밍 언어에 대한 사랑과 루비의 탄생

Matz는 루비뿐만 아니라 모든 프로그래밍 언어를 사랑한다고 밝히며, 15세에 BASIC으로 프로그래밍을 시작했습니다. 당시 사용했던 샤프 포켓 컴퓨터의 BASIC은 매우 제한적이었고, 그는 프로그래밍이 원래 좌절스러운 것이라고 생각했습니다. 그러나 파스칼을 접하며 더 나은 문법과 추상화, 사용자 정의 함수, 데이터 구조, 재귀 등 프로그래밍의 광대한 세계를 발견했습니다. 17세에 자신만의 언어를 만들겠다는 꿈을 꾸었으나, 당시 인터넷과 오픈소스 소프트웨어가 없던 환경에서 컴파일러 관련 서적은 너무 어려웠습니다. 결국 10년 후 27세에 루비를 만들기 시작했으며, 이는 심리학, 인간 공학, 언어학, 프로그래밍에 대한 그의 열정이 교차하는 지점이었습니다. 특히 스몰토크(Smalltalk)를 통해 객체지향 프로그래밍의 아름다움과 추상화의 힘에 매료되었습니다. 그는 프로그래밍이 ‘창조의 기쁨’, ‘설계의 기쁨’, ‘힘의 즐거움’을 선사한다고 강조합니다.

자유 소프트웨어와 루비의 자유

대학 시절 인터넷을 통해 자유 소프트웨어(Free Software)를 접하며 큰 영향을 받았습니다. 자유 소프트웨어는 ‘자유로서의 무료(free as in freedom)’를 의미하며, 사용, 학습, 수정, 재배포의 자유를 보장합니다. Matz는 교과서 속 예제 코드와 달리 실제 프로덕션 수준의 견고한 소프트웨어(Emacs, Lisp 인터프리터 등)를 통해 프로그래밍을 배웠고, 이에 대한 보답으로 자신이 만드는 소프트웨어는 자유 라이선스로 배포하겠다고 결심했습니다. 루비가 자유 소프트웨어인 이유도 여기에 있습니다. 그는 자유의 가치를 매우 중요하게 생각하며, 다른 소프트웨어를 강제로 자유롭게 만들지는 않지만, 자신이 만든 소프트웨어는 모두가 자유를 누릴 수 있도록 배포합니다.

루비 성능 개선의 여정

Matz는 개인적으로 ‘성능’보다 ‘즐거움’을 우선시하는 철학을 가지고 루비를 설계했습니다. 이로 인해 루비는 최적화하기 어려운 언어로 알려지기도 했습니다. 그러나 2007년 코이치 사사다(Koichi Sasada)가 YARV(Yet Another Ruby Virtual Machine)를 개발하여 루비 1.8에서 1.9로 전환하며 성능이 3~50배 향상되었습니다. 이후 Shopify의 기여로 YJIT 컴파일러가 도입되어 루비 3.0은 루비 2.0보다 3배 빨라졌습니다. 작년에는 ZJIT 컴파일러로의 교체가 제안되었는데, 이는 더 높은 수준의 중간 표현(Intermediate Representation)을 도입하여 최적화 기회를 늘리고, 프로세스 간 네이티브 코드 캐싱을 통해 재컴파일 없이 성능을 획기적으로 개선하려는 시도입니다. Matz는 루비가 V8(Chrome), JVM(Java)과 같은 최상위 VM에는 미치지 못할지라도, VM 기반 언어 중 가장 빠른 언어 중 하나가 될 것이라고 기대합니다.

유닉스 철학과 루비의 통합, AI 시대의 개발 도구 활용

Matz는 유닉스 철학인 ‘각 프로그램은 한 가지 일을 잘하고, 도구들의 조합을 허용하라’를 좋아하지만, 이는 ‘임피던스 불일치(impedance mismatch)’와 수많은 작은 언어(awk, find 옵션 등)를 학습해야 하는 단점이 있다고 지적합니다. 이에 반해 펄(Perl)의 ‘키친 싱크(kitchen sink)’ 접근 방식, 즉 하나의 언어 안에 많은 도구와 기능을 담는 방식을 높이 평가하며, 루비는 이러한 펄의 아이디어를 계승한 ‘객체지향 유닉스’라고 설명합니다. 개인적으로 Emacs를 고집하며 Emacs 바인딩이 몸에 뱄다고 고백합니다. 최근에는 AI 도구(Cloud Code, Claude, Gemini)를 활용하여 코딩을 하고 있으며, AI를 통한 코드 조사(code investigation), 편집 도구(editing tool) (리팩토링, 함수 이름 변경 등), 텍스트 생성기(text generator) (README, 문서, 커밋 메시지)로서의 잠재력을 높이 평가합니다. 이를 통해 영어 작성을 피하고 ‘내면의 평화’를 얻었다고 유머러스하게 말합니다.

‘어쩌면 지켜봐야죠(Maybe we’ll see)’ 철학

중국 고사 ‘새옹지마’를 인용하며 루비의 여정을 설명합니다. 1993년 개발되어 1995년 공개된 루비는 처음에는 천재적인 언어로 칭송받았으나, 10년간 큰 주목을 받지 못했습니다. (불운? 어쩌면 지켜봐야죠.) 2004년 루비 온 레일즈(Ruby on Rails) 출시로 폭발적인 인기를 얻었으나 (행운? 어쩌면 지켜봐야죠.), 2010년 이후 정적 타입 언어의 부상으로 상대적으로 인기가 하락했습니다. (불운? 어쩌면 지켜봐야죠.) Matz는 AI 시대에는 간결한 프로그래밍 언어가 다시 인기를 얻을 것이며, 루비가 다시 주목받을 것이라고 예측합니다.

결론

Matz는 루비의 인기도와 상관없이, 가치 창출과 끊임없는 개선에 집중할 것이라고 강조합니다. 가상 머신 교체, JIT 컴파일러 도입 및 개선(MJIT, YJIT, ZJIT) 등 루비는 지속적으로 발전해 왔으며, 특히 Shopify와 같은 기업들의 성능 개선 투자는 루비의 안정성과 속도 향상에 크게 기여했습니다. 루비 커뮤니티는 Matz에게 가장 큰 보물이며, 그는 개발자들이 루비를 통해 프로그래밍을 즐기고 가치를 창출하는 모습을 보는 것이 가장 큰 기쁨이라고 말합니다. 루비는 공동체의 힘으로 더욱 훌륭한 언어가 될 것이라는 비전을 제시하며, 참가자들이 루비를 즐기기를 바랍니다.

댓글 1

댓글 작성

0/1000
정중하고 건설적인 댓글을 작성해 주세요.
이원섭
14일 전
본문에서 말하는 '임피던스 불일치'는 유닉스 철학처럼 여러 독립적인 도구(grep, awk, find 등)를 파이프(|)로 엮어 쓸 때 발생하는 문제점을 뜻합니다.
데이터 형식의 불일치: A 프로그램이 출력한 텍스트를 B 프로그램이 이해할 수 있는 형태로 계속 파싱하고 변환해야 하는 번거로움.
패러다임의 불일치: find 명령어의 복잡한 옵션과 awk의 스크립트 문법이 다르듯, 각 도구의 사용법을 따로 배우고 머릿속에서 계속 바꿔야 하는 인지적 부담.
Matz는 이런 '마찰 비용' 없이, 루비라는 하나의 언어 안에서 데이터와 기능이 매끄럽게 통합되는 방식을 더 선호한다는 의미로 이 용어를 사용한 것이죠.
원래 전자공학에서의 의미: "에너지 손실 현상"
원래 '임피던스'는 교류 전기의 흐름을 방해하는 정도를 뜻하는데, '임피던스 불일치'는 에너지를 보내는 쪽(소스)과 받는 쪽(부하)의 임피던스가 달라 에너지가 100% 전달되지 못하고 일부가 튕겨 나가는(반사되는) 현상을 말합니다.
쉬운 비유: 굵기가 다른 두 밧줄을 묶고 한쪽에서 파동을 보내면, 연결 지점에서 파동 일부가 튕겨 나가고 일부만 전달되는 것과 같습니다. (굵기가 같다면=임피던스 일치, 파동은 매끄럽게 전달됩니다.)
실생활 예시: 오디오 앰프와 스피커의 임피던스를 맞춰야 제소리가 나는 것도 같은 원리입니다.
소프트웨어 컴포넌트 간 데이터가 매끄럽게 흐르지 못하는 상황을, 전기 에너지가 손실되는 물리 현상에 빗댄 아주 멋진 비유라고 생각합니다. 다른 분들께도 도움이 되었으면 좋겠습니다!