엔지니어링 철학: 마츠모토 유키히로(Matz)

핵심 요약

• 기계가 아니라 사람을 위해 설계한다. Matz는 프로그래머의 기쁨을 목적 함수로 삼았고, 그 대가는 실리콘이 치르게 했어요. 모든 구문 선택은 “바이트가 얼마나 빨리 움직일까”보다 먼저 “사람이 이것을 읽으며 어떻게 느낄까”에 답해요.
• 최소 놀람이란 ‘나’의 놀람이 최소라는 뜻이에요. 이 원칙은 초보자의 기대를 모아 평균 낸 것이 아니에요. 한 명의 능숙한 작성자가 자신의 좌절을 최소화한 것이며, 그 척도는 Ruby를 충분히 잘 배운 ‘후에’ 측정돼요.
• MINASWAN: 문화는 설계의 산물이에요. “Matz는 친절하고 그래서 우리도 친절하다”라는 말은, 언어의 커뮤니티가 문법에서 흘러나온 우연이 아니라 설계할 수 있는 표면임을 보여줘요.
• Ruby는 하나의 취향을 끈질기게 적용한 결과예요. 그 일관성은 종합에서 나와요——Perl, Smalltalk, Lisp, Ada, Eiffel을 위원회의 평균값이 아니라 하나의 목소리로 조화시킨 거예요.

원칙

“저에게 삶의 목적 가운데 하나는 기쁨을 누리는 것입니다. 프로그래머는 프로그래밍의 창의적인 면에 집중할 수 있을 때 흔히 기쁨을 느끼므로, Ruby는 프로그래머를 행복하게 만들도록 설계되었습니다.” – Yukihiro Matsumoto¹

대부분의 언어 설계는 기계에 맞춰 최적화돼요. 컴파일 속도, 메모리 배치, 명령어 수처럼 실리콘이 신경 쓰는 것들이죠. Matz는 그 우선순위를 뒤집었어요. 키보드 앞에 있는 사람이야말로 중요한 대상이며, 기계의 일은 그 사람을 섬기는 것이라고 결정했어요. “기계는 인간을 섬겨야 합니다”라고 그는 말해요. “프로그래머는 흔히 무의식적으로 기계를 섬깁니다. 기계가 당신을 섬기게 하십시오.”²

여기서 말하는 기쁨은 공학으로 포장한 막연한 감상이 아니라, 엄격한 설계 제약이에요. 사람의 기쁨이 목적 함수라면, 모든 구문 선택, 모든 메서드 이름, 모든 기본값은 “바이트가 얼마나 빨리 움직일까”가 아니라 “사람이 코드를 읽고 쓰며 어떻게 느낄까”라는 질문이 돼요. Matz는 이 절충을 명시적이고 정직하게 드러냈어요——Ruby는 기계의 사이클을 들여 프로그래머의 편안함을 산다는 거죠. 같은 신념이 취향을 장식이 아니라 구조적 시스템으로 만들어요——일하는 사람의 경험이, 마지막에 덧붙이는 뒷생각이 아니라 무게를 떠받치는 핵심 관심사가 되는 거예요.

하나의 결정이 그 뒤의 모든 것을 지배해요——기계가 아니라 사람을 위해 설계한다. 구문도, 문화도, 커뮤니티의 좌우명도 모두 그 아래에 놓여 있어요. 이 글의 나머지는, 한 사람이 자신의 행복을 좇은 일이 어떻게 방어 가능한 공학적 입장으로 굳어졌는지——그리고 왜 “사람을 섬긴다”가 “기계를 섬긴다”에서 물러난 것이 아니라 그만큼 엄격한 입장으로 드러나는지를 따라가요.

맥락

Yukihiro Matsumoto는 1965년 4월 14일 일본 오사카부에서 태어나, 네 살 때부터 돗토리에서 자랐어요.³ 그는 자신을 언어 괴짜라고 말해요——언어학자가 아니라 ‘프로그래밍’ 언어 괴짜요. 고등학교를 마칠 때까지 독학으로 프로그래밍을 익혔고, 쓰쿠바 대학교에서 정보과학 학위를 받았으며, 그곳에서 프로그래밍 언어와 컴파일러를 다루는 연구실에 몸담았어요.³ 매혹이 먼저였고, Ruby는 그 끝에 나온 결과물이었어요.

그는 1993년 2월에 Ruby라는 이름을 붙였어요——그 이름은 코드가 한 줄도 작성되기 전에, 동료 이시쓰카 게이주와의 온라인 채팅에서 떠올랐어요——그리고 이후 몇 년에 걸쳐 만들어 나갔어요.¹³ 동기는 불만이었어요. “저는 진짜 객체지향이면서 쓰기 쉬운 스크립트 언어를 정말로 원했습니다”라고 그는 설명해요. “찾아봤지만 찾을 수 없었습니다.”⁴ Perl은 강력했지만, 그의 취향으로는 진정한 객체지향이 아니었어요. Python은 객체지향이었지만, 그의 취향으로는 충분히 즐겁지 않았어요. 그래서 그는 자신이 직접 쓰고 싶은 언어를 만들었어요. 최초의 공개 버전을 1995년 12월 21일에 내놓았어요.³

그 이름은 작은 농담이었어요. 두 사람은 보석으로서의 Ruby로 정했는데, Ruby가 부분적으로 응답하던 언어인 Perl에 대한 윙크였어요. 진주(pearl) 다음에 루비(ruby)——점진적 업그레이드처럼 이름 붙인 후계자였죠.⁴ 여러 해 동안 Ruby는 주로 일본 내의 현상이었고, 메일링 리스트와 문서가 일본어였어요. 세계적 도약은 나중에, 그것도 바깥에서 왔어요——David Heinemeier Hansson이 Ruby 위에 Ruby on Rails를 만들었고, Rails가 2000년대 중반에 Ruby를 세계 곳곳으로 실어 날랐어요.⁴ 한 사람이 자신의 행복을 위해 만든 언어가 한 세대의 웹 애플리케이션의 토대가 되었어요.

작업

Ruby의 설계: 기쁨과 최소 놀람의 원칙

Ruby에 관해 가장 많이 인용되는 생각이 “최소 놀람의 원칙”이에요——언어는 당신이 기대하는 대로 동작해야 하며, 그래야 도구가 아니라 문제에 주의를 쏟을 수 있다는 거죠. Matz는 이 원칙을 지지하면서도 흔한 오독을 바로잡아요. “최소 놀람의 원칙이란 ‘나’의 놀람이 최소라는 원칙을 뜻합니다”라고 그는 말해요. “그리고 그것은 Ruby를 아주 잘 배운 후의 최소 놀람의 원칙을 뜻합니다.”⁵

그 정정이 철학 전체를 한 문장에 담고 있어요. 그는 프로그래머에게 설문을 돌려 기대치를 평균 내지 않았어요. ‘나’의 좌절을 최소화하도록 언어를 설계했고, 자기 자신인 작성자를——유창하고 까다로운 한 명의 사용자를——기쁘게 하는 언어라면 다른 이들도 유창함에 이르면 기뻐하리라는 데에 걸었어요. “저는 프로그래밍 중 제 좌절을 최소화하고 싶었고, 그래서 프로그래밍에 드는 노력을 최소화하고 싶습니다”라고 그는 말해요. “저 자신이 프로그래밍에서 재미를 느끼고 싶습니다.”⁵ Ruby는 규모를 키운 개인적인 언어예요. 그 일관성은 위원회의 일관성이 아니라, 하나의 취향을 끈질기게 적용한 일관성이에요.

기계가 아니라 사람을 위한 설계

Matz는 소프트웨어를 하드웨어를 향한 명령의 집합이 아니라 사람을 위한 매체로 다뤄요. “인간이라는 요소를 과소평가하지 마십시오”라고 그는 말해요. “우리가 컴퓨터 앞에 있더라도, 그것들은 매체입니다. 우리는 인간을 위해, 인간과 함께 일합니다. 결국 우리의 작업 대부분은 인간과 관련됩니다.”⁵ 그는 이 주장을 구호 너머로 밀어붙여요——Matz에게 인터페이스는 곧 제품 전체예요. “시스템의 인터페이스가 나쁘면 아무도 쓰지 않을 것입니다. 그래서 사용자에 대해서든 다른 기계에 대해서든, 시스템의 인터페이스 곧 표면은 매우 중요합니다.”²

그 따름정리는 기계의 선호에 종속되기를 거부하는 거예요. 인간과 컴퓨터의 관계를 묻자 Matz는 단도직입적으로 답했어요——“우리가 주인입니다. 그들은 노예입니다.”⁶ 기계는 프로그래머의 의도를 섬기기 위해 존재하며, 사람에게 CPU처럼 생각하라고 강요하는 언어는 그 관계를 거꾸로 뒤집은 거예요. Ruby의 블록, 모든 것이 객체라는 모델, 읽기 좋은 메서드 이름——Array#each, Integer#times, String#upcase——은 모두 구현의 복잡함을 들여서 표면이 의도처럼 읽히게 만들어요.

MINASWAN: 설계의 산물로서의 문화

Ruby의 가장 특이한 산물은 기능이 아니라 커뮤니티의 규범이에요. Matz는 친절하고 인내심 있는 태도로 유명한데, 그 기질이 하나의 좌우명으로 퍼졌어요——MINASWAN——“Matz는 친절하고 그래서 우리도 친절하다.”⁷ Ruby 초창기, 메일링 리스트에서 토론이 격해지면, 커뮤니티 구성원들은 이 말을 꺼내 더 따뜻한 분위기를 만들었어요. 그것은 퍼져 나가 결국 정체성이 되었어요.⁸

대부분의 언어 설계자가 놓치는 교훈은, ‘문화’ 역시 설계 표면이라는 거예요. 언어는 문법 그 이상이에요——질문을 던지면 너그러운 답이 돌아오는 경험이고, 당신이 이해하기를 마음 쓴 작성자의 라이브러리를 읽는 경험이에요. Matz는 구문을 설계했고, 본보기를 통해 그 주위의 사회적 태도까지 설계했어요. 프로그래머를 행복하게 만들려고 지은 언어가 친절함에 헌신하는 커뮤니티를 길러 냈는데, 같은 가치가 둘 다를 움직였기 때문이에요——커뮤니티는 사람에게 적용된 최소 놀람의 원칙이에요.

mruby: 제약된 공간 속의 철학

2012년 4월, Matz는 mruby를 오픈소스로 공개했어요——완전한 Ruby로는 너무 무거운 곳, 즉 마이크로컨트롤러, 임베디드 시스템, 소비자 기기에서 돌도록 만든 가볍고 임베드 가능한 Ruby 구현체예요.⁹ 이것은 ISO/IEC 30170 Ruby 명세의 부분집합을 따르며, 바이트코드 컴파일러와 가상 머신을 갖춘 작은 인터프리터로 제공되어, Lua가 그러하듯 C나 C++에 임베드할 수 있어요.¹⁰

mruby가 흥미로운 까닭은 바로 철학을 압력 아래에서 시험하기 때문이에요. RAM이 수 킬로바이트뿐이고 사이클에 여유가 없을 때, “사람을 위해 설계한다”가 살아남을까요? Matz의 답은 Ruby의 표현력은 지키되 런타임의 무게는 덜어 내는 것——임베디드 개발자를 C 수준으로 끌어내리는 대신, Ruby를 쓰는 기쁨을 펌웨어 계층으로 가져오는 것이었어요. 사람 중심의 내기는 그것에 가장 적대적인 곳에서도 버텨 냈어요.

방법

Matz의 방법은 공감을 설계의 규율로 형식화한 거예요. 거듭 나타나는 동작은 “기계에 무엇이 옳은가?”가 아니라 “사람은 무엇을 느낄까?”를 묻고——그 답이 요구하는 구현 비용을 얼마든 치르는 거예요.

두 번째 동작은 종합이에요. Ruby는 드러내 놓고 파생적이에요——Perl의 실용성과 정규 표현식, Smalltalk의 순수 객체 모델과 메시지 전달, Lisp의 유연성, Ada와 Eiffel의 조각들이죠.⁴ Matz는 새로운 패러다임을 발명하지 않았어요. 그는 자신이 흠모하던 언어에서 가장 좋은 아이디어를 훔쳐, 그것들을 하나의 일관된 목소리로 조화시켰어요. 그런 취향을 발휘하는 설계자는 드물어요——발명하기보다 가져오는 규율, 그리고 빌려 온 부분을 충돌시키지 않고 어우러지게 만드는 더 어려운 규율이죠. 최소 놀람의 원칙은 부분적으로 ‘내적’ 일관성이에요——Ruby의 한 귀퉁이를 배우고 나면, 다음 귀퉁이는 첫 번째가 가르친 대로 동작해요.

세 번째 동작은 절충에 대한 정직함이에요. Matz는 따뜻함을 내세우면서 몰래 벤치마크를 최적화하는 대신, Ruby가 빠른 선택지라고 결코 가장하지 않았고 그 점을 또렷이 말했어요. 비용은 실재하고 구체적이에요——Ruby에서는 모든 것이 객체이고 정수조차 일급 객체이므로, 산술은 날것의 기계 명령을 실행하는 게 아니라 그 객체에 + 메시지를 보내어 일어나요.¹⁴ 5.times나 (1..n).map의 편리함——숫자를 말을 걸 수 있는 객체로 다루는 것——은 C의 int라면 결코 부담하지 않을 디스패치와 할당 오버헤드로 치러져요. Matz는 읽기 좋은 표면을 택했고 그 청구서는 런타임이 떠안게 했는데, 이것이 바로 또렷이 진술된 그 내기예요.

영향의 사슬

그를 빚은 사람들

Larry Wall과 Perl. Ruby는 Perl의 실용적이고 일을 해내는 감각과 정규 표현식 DNA를 물려받았어요. Matz 자신이 Ruby를 Perl에 대한 응답으로 규정했어요——실용성은 지키되 그가 보기에 빠져 있던 진짜 객체지향을 바로잡는 것으로요. (직접적 영향)⁴

Smalltalk. ‘모든 것’이 객체이며——정수도, 클래스도, nil도——계산은 메시지를 보내어 일어난다는 신념은 Smalltalk에서 왔어요. 그것은 Ruby의 객체 모델에서 가장 깊은 구조적 유산이에요. (직접적 영향)⁴

Lisp, Ada, Eiffel. Lisp는 유연성과, 언어가 프로그래머에게 맞춰 휘어야 한다는 감각을 더했어요. Ada와 Eiffel은 구문과 설계의 다른 구체적인 조각들을 더했어요. Ruby는 그 종합이에요. (형성적 영향)⁴

그가 빚은 사람들

Rails 시대의 웹. Ruby on Rails는 Ruby를 한 세대 스타트업의 기본 언어로 만들었고 “개발자의 행복”에 상업적 논거를 안겼어요——더 행복한 프로그래머가 더 빨리 출시했으므로, 사람 중심의 언어는 느낌만이 아니라 경제성으로도 프로젝트를 따냈어요.

한 세대의 기준 기대. Ruby 이후 프로그래머는 언어가 ‘즐겁기를’ 기대하게 됐어요——산문처럼 읽히고, 너그럽고, 기쁘게 하기를요. 그 기대는 새로운 언어가 진지하게 받아들여지려면 넘어야 할 기준을 다시 빚었어요.

Crystal과 Elixir. Crystal은 LLVM 백엔드를 통해 네이티브 코드로 컴파일하면서도 Ruby의 구문을 거의 통째로 빌려 와요.¹¹ José Valim이 BEAM을 위해 만든 함수형 언어 Elixir는 Ruby의 인체공학적 감각을 동시성의 세계로 가져가요. Valim은 그 빌려 온 구성 요소 다수에 대해 자신의 “이전 Ruby 경험”을 꼽아요.¹² Ruby의 미학은 그 런타임보다 오래 살아남았어요. (양식적 계보)

관통하는 줄기

여기에 생산적인 긴장이 있어요. Matz는 사람의 행복에 최적화하고, 그러기 위해 기계의 사이클을 들인다고 정직하게 인정해요. 공학의 다른 극은 기계에 최적화해요——John Carmack은 프레임이 예산에 들어맞을 때까지 사이클을 세고, Linus Torvalds는 특수한 경우를 사라지게 하는 자료 구조로서 “좋은 취향”을 옹호해요. Carmack과 Torvalds는 하드웨어가 무엇을 받을 자격이 있는지 묻고, Matz는 사람이 무엇을 받을 자격이 있는지 물어요. 어느 극도 틀리지 않았어요. 가장 좋은 시스템은 둘 사이의 논쟁 속에 살아요——사람이 쓰며 즐길 만큼 표현력이 풍부하고, 기계가 모욕당하지 않을 만큼 규율 있는 것이죠. Matz는 “사람을 위해 설계한다”가 한낱 위안이 아니라 정당하고 엄격한 공학적 입장임을 보여 주는 증거예요. (시리즈 가교)

내가 여기서 얻는 것

저는 개발자 도구와 AI 에이전트 하네스를 만드는데, Matz의 내기가 바로 제가 거듭 거는 그것이에요——루프 안의 사람이야말로 중요한 대상이라는 거죠. 코딩 에이전트는 프로그래밍 언어처럼 사람의 의도와 기계의 실행 사이의 인터페이스예요. 그것이 당신을 놀라게 하거나, 맞서거나, 문제 대신 기계처럼 생각하게 만든다면, 내부가 아무리 영리해도 그것은 실패한 거예요——내부의 존재 이유는 바로 경험을 사람이 읽어 낼 수 있게 만드는 데에 있으니까요. 그래서 저는 표면을 정직하게, 스택을 얇게 유지해요——노 빌드 선언은 도구 사슬에 적용된 최소 놀람의 원칙이에요. 그리고 Matz가 Ruby를 빠르다고 가장하기를 거부했듯, 저도 절충을 숨기기보다 정직하고 싶어요——품질이 유일한 변수이며, 프로그래머의 행복은 품질에 맞서는 것이 아니라 그 일부예요.

자주 묻는 질문

Yukihiro Matsumoto의 공학 철학은 무엇인가요?

Matz는 기계의 효율이 아니라 사람의 행복과 생산성을 위해 프로그래밍 언어를 설계해요. 그가 밝힌 목적은 이래요——“Ruby는 프로그래머를 행복하게 만들도록 설계되었습니다.”¹ 그는 프로그래머의 경험——읽기 쉬움, 기쁨, 최소 놀람——을 일차적인 설계 제약으로 다루며, 그것을 섬기기 위한 정직한 대가로 더 느린 런타임을 받아들여요. “기계는 인간을 섬겨야 합니다”라고 그는 말해요. “기계가 당신을 섬기게 하십시오.”²

Ruby에서 최소 놀람의 원칙이란 무엇인가요?

그것은 언어가 숙련된 사용자가 기대하는 대로 동작하여 마찰을 최소화해야 한다는 생각이에요. Matz는 그것이 “‘나’의 놀람이 최소라는 원칙”을 뜻한다고 분명히 해요——그는 유창한 사용자로서 자기 자신의 좌절을 최소화하도록 Ruby를 설계했으며, 첫날의 초보자를 위한 놀람이 아니라 “Ruby를 아주 잘 배운 후의 최소 놀람의 원칙”이에요.⁵

MINASWAN은 무슨 뜻인가요?

MINASWAN은 “Matz는 친절하고 그래서 우리도 친절하다”를 나타내요——Matsumoto의 친절하고 인내심 있는 태도에서 자라난 Ruby 커뮤니티의 좌우명이에요. 초기의 Ruby 사용자들은 메일링 리스트에서 너그러운 분위기를 만들려고 이 말을 꺼냈고, 그것은 Ruby의 문화적 정체성의 일부가 되었어요.⁷⁸ 이는 언어의 커뮤니티 그 자체가 설계 표면이라는 생각을 반영해요.

어떤 언어가 Ruby에 영향을 주었나요?

Ruby는 의도적인 종합이에요. Perl의 실용적 감각과 정규 표현식, Smalltalk의 순수 객체 모델과 메시지 전달, Lisp의 유연성, 그리고 Ada와 Eiffel의 요소를 끌어왔어요. Matz는 새로운 패러다임을 발명하는 대신, 자신이 흠모하던 기능들을 하나의 일관된 언어로 결합했어요.⁴

출처