"루비는 진지한 프로그래밍 언어가 아니다"에 대한 응답
(robbyonrails.com)- 루비(Ruby) 를 ‘진지하지 않은 언어’로 보는 시각에 반해, 루비는 프로그래밍을 인간적이고 즐겁게 만드는 언어임
- 초기 루비 커뮤니티는 작고 유쾌한 반란처럼 출발했으며, 복잡함보다 명료함과 접근성을 중시
- Shopify, Doximity, GitHub 등 실제 대규모 서비스들이 루비로 운영된 사례를 들어, 실질적 성과를 증명
- 루비의 핵심은 코드를 쓰는 사람의 경험과 지속 가능한 개발 문화에 있으며, 이는 단순한 향수가 아닌 감사와 존중의 태도임
- 미래의 소프트웨어 개발에서도 가독성, 유지보수성, 즐거움이 더 중요해질 것이며, 루비의 가치가 여전히 의미 있는 기준점으로 남게될 것
루비와 ‘진지함’의 개념
- “루비는 진지한 언어인가?”라는 질문은 프로그래밍이 어떤 감정을 가져야 하는가에 대한 인식 차이를 드러냄
- 일부는 사용하기 즐거운 도구를 ‘진지하지 않다’고 간주하지만, 루비는 그런 정의에 동의하지 않음
- 루비의 초창기 시절은 작은 커뮤니티와 장난기 있는 에너지로 가득했으며, 프로그래밍이 위압적이지 않아도 된다는 가능성을 보여줌
- 당시 비판자들은 주로 Java 아키텍트나 전통적 엔터프라이즈 개발자들이었고, 루비 커뮤니티는 이에 개의치 않고 실제 제품 개발에 집중
접근성과 생산성을 중시한 언어
- 루비는 단순함이 아닌 접근성(approachability) 을 추구해 초보자와 소규모 팀이 빠르게 성장할 수 있도록 도움
- 복잡한 이론보다 모멘텀과 명료함을 중시해 불안감 없이 개발을 지속할 수 있게 함
- 이러한 특성 덕분에 부트캠프와 스타트업들이 루비를 채택했고, 이는 속도와 창의성을 중시하는 환경에 적합했음
- 트위터 사례처럼, 루비는 기업이 성장하는 데 충분히 기여했으며, 이후 다른 기술로 전환된 것은 성공의 결과로 제시
실무에서의 신뢰성과 실제 사례
- 수십 년간의 컨설팅 경험에서 루비 선택으로 실패한 팀은 없었음, 오히려 복잡성·우유부단함·과도한 ‘진지함’ 이 실패 요인이었음
- 루비는 개발자가 핵심 업무에 집중할 수 있도록 방해하지 않는 언어로 평가
- Shopify, Doximity, GitHub 등 주요 서비스가 루비로 운영되며, 이는 감정이 아닌 실질적 증거(proof) 로 제시됨
루비 문화와 인간 중심의 개발 철학
- 루비는 코드를 쓰는 감각과 읽는 경험을 중시하는 사람들을 끌어들이며, 이는 향수가 아닌 지속 가능한 소프트웨어 제작 방식임
- 루비 커뮤니티는 표현력과 인간 중심성을 중시하며, 프로그래밍이 사람을 위한 행위임을 상기시킴
- 다른 언어를 선호하는 사람들과의 차이는 취향의 문제이며, 루비는 모든 사람을 설득하려 하지 않음
미래의 프로그래밍과 루비의 역할
- 미래의 소프트웨어 개발은 단일 언어·패러다임·이념이 지배하지 않고, 혼합적이고 유연한 형태로 전개될 것임
- AI가 코드를 작성하는 시대에는 가독성과 유지보수성이 더욱 중요해지고, 번아웃이 일상화된 환경에서는 즐거움이 핵심 가치로 부상
- 루비의 가치인 명료함·공감·인간 중심성은 과거의 유산이 아니라 미래의 기준점이 될 것
‘진지함’보다 공명하는 코드
- 사회와 비즈니스는 ‘진지함’보다 공명(resonance) 과 명확함, 인간성을 보상함
- 진지한 후보·음악가·예술가·스타트업·엔지니어가 항상 성공하는 것은 아님
- 루비는 팀을 위한 코드, 사람을 위한 프로그래밍을 지향하며, 이러한 접근이 산업을 더 인간적으로 유지시킴
- 호기심 많고 유쾌한 개발자들이 미래 기술 생태계에서 중요한 역할을 할 것이며, 루비는 그 흐름 속에서 여전히 의미 있는 언어로 남음
결론
- “루비는 진지한 언어인가?”라는 질문은 잘못된 질문임
- 더 적절한 질문은 “루비가 다음 세대의 소프트웨어에 여전히 의미 있는 기여를 할 수 있는가” 이며, 그 답은 그렇다임
- 만약 그것이 ‘진지하지 않다’는 뜻이라면, 그 점이야말로 루비가 대화에 포함되어야 하는 이유
Hacker News 의견
- 나는 Ruby를 싫어하는 이유로 자주 나오는 Twitter 사례가 부적절하다고 생각함
Ruby가 원인이었다 하더라도, 그 선택 덕분에 사업이 시작되고 첫 성공을 거둘 수 있었음
Twitter의 문제는 언어 때문이 아니라 대규모 팬아웃(celebrity tweet → 수백만 팔로워) 이라는 특수한 상황 때문이었음
또, “처음부터 확장 가능한” 언어를 썼지만 실패한 스타트업들은 아무도 이야기하지 않음 — 전형적인 생존자 편향임
Wired의 해당 작가 페이지를 보면 논란을 유발하는 글쓰기를 전략적으로 하는 듯함
나는 여전히 Ruby로 유용한 소프트웨어를 만드는 조용한 다수 중 하나로 돌아감- “Ruby가 아니었다면 더 나은 언어로 같은 사업을 시작해도 문제를 피할 수 있었을 것”이라는 반론도 있음
- 시간이 많이 흘렀고, 지금의 Ruby는 그때와 완전히 다름
- 원문 기사에서는 저자가 Ruby를 싫어한 이유를 구체적으로 설명하지 않았음
단지 과거의 한계를 나열했을 뿐이며, 실제로는 자신이 맡은 코드베이스의 문제였을 가능성이 큼
첫 번째 글의 핵심은 “2025년에 Ruby를 새로 선택할 이유는 없다”였고, 그게 논의의 중심이 되었어야 함
이번 글은 감정에 호소하는 방향으로 갔고, 아이러니하게도 Ruby가 감성으로 움직인다는 전 글의 주장을 스스로 입증한 셈임
Elixir를 좋아하는 사람들 중 다수가 Ruby를 ‘비진지하다’고 보지만, Elixir 역시 Ruby의 영향을 강하게 받았음- 나는 Elixir를 여러 해 써왔고, 초반에는 Ruby도 했음
많은 사람들이 Ruby의 친숙한 문법과 함수형 기반을 결합한 Elixir에 끌림
특히 BEAM 런타임 덕분에 운영 특성이 완전히 다름
BEAM은 단순한 언어가 아니라 시스템을 위한 시스템이라는 느낌을 줌 — 모든 것을 추적, 재시작, 관찰할 수 있음 - Ruby에서 영감을 받은 컴파일 언어 Crystal이 언급되지 않은 게 의외였음
다만 Crystal은 Elixir보다 인기도 부족 문제가 더 심함
TIOBE 순위 기준으로 Elixir는 상위 50위 안에 있음 - macOS에는 Ruby가 기본 설치되어 있어서, 별도 설치 없이 스크립트를 짜려면 Perl, Bash, AppleScript 아니면 Ruby를 써야 함
- 두 기사 모두 실속이 없다고 느낌
첫 글은 StackOverflow 통계와 Twitter 얘기만 하고, 두 번째 글은 그저 향수와 미학 이야기뿐임
LLM이 아니라 사람이 쓴 글이라는 게 오히려 더 우울함
- 나는 Elixir를 여러 해 써왔고, 초반에는 Ruby도 했음
- 내가 좋아하는 언어를 판단하는 기준은 “이 언어로 코드를 쓰는 걸 좋아하느냐”가 아니라
“운영 중인 시스템이 이 언어로 작성되어 있기를 바라느냐”임
두 질문의 답이 같은 사람은 많지 않음- 코드 작성과 비즈니스 운영은 별개의 문제임
나는 Ocaml을 좋아하지만, 생태계가 약하고 인력 확보가 어려워서 운영 시스템에는 쓰고 싶지 않음 - 언어의 시대와 팀의 코딩 문화에 따라 다름
타입 주석과 검사 도구가 있는 Python은 유지보수하기 좋지만, 그렇지 않다면 문서화 문화가 필수임 - 시스템을 단순히 유지할지, 계속 발전시킬지에 따라 답이 달라짐
전자라면 COBOL, 후자라면 다른 선택이 흥미로워짐 - 내가 직접 만든 시스템이라면 어떤 언어든 괜찮음, 아니면 다른 사람에게 넘기겠음
- Forth로 코딩하는 건 즐기지만, 그걸로 생업을 하고 싶지는 않음
- 코드 작성과 비즈니스 운영은 별개의 문제임
- 나는 Ruby를 정말 좋아함
감성 때문이 아니라, 단순히 작성하는 즐거움이 큼 — 특히 JavaScript보다 훨씬 즐거움
Ruby를 공격하는 글들은 이상하게 느껴짐
Github, Twitter, Coinbase, Shopify 같은 성공 사례가 있는데, 확장성 문제는 성공의 부산물일 뿐임
Ruby는 훌륭한 도구이며, 다음 프로젝트에서 적합한지 직접 판단해보길 권함 - 원문 기사도, 그에 대한 반박도 정의가 불분명함
“Ruby는 영원히 확장되지 않는다”는 주장이라면 대부분의 언어도 마찬가지임
결국 두 글 모두 “Ruby는 영원히 동작하지 않는다”는 점에서는 일치함
흥미로운 건, 원문이 Ruby의 StackOverflow 순위를 18위라고 깎아내리면서
실제로는 2024년 기준 14위이고, 자신이 칭찬한 Scala는 그보다 9단계 아래라는 점임
StackOverflow 2024 설문 링크- “Ruby는 영원히 동작하지 않는다”는 말에 동의하지 않음
내가 10년 전에 쓴 Ruby 코드, 예를 들어 WebKit의 offlineasm 컴파일러는 아직도 잘 돌아감 - Java를 비꼬면서 Scala를 칭찬하는 것도 웃김 — Scala의 강점 대부분은 Java 덕분임
- “Ruby는 영원히 동작하지 않는다”는 말에 동의하지 않음
- 많은 사람들이 Ruby를 “인간을 위한 언어”라고 표현하지만, 사실 모든 언어는 인간을 위해 만들어졌음
Ruby는 문법이 깔끔하고 표현력이 좋지만, 동적 타이핑과 매직(암묵적 동작) 때문에 쓰기 어렵게 느껴짐
나에게는 맞지 않지만, 어떤 사람들에게는 완벽히 맞는 언어임- Rails가 “마법 같은 객체” 개념을 대중화했음
팬들은 이를 놀랍고 즐겁다고 하지만, 어떤 사람에게는 무섭게 느껴짐
Python의 Flask도 비슷하게 context local proxy를 사용함
반면 Zig나 Go는 “모든 것은 명시적이어야 한다”는 반발로 등장했고, Rust는 그 중간쯤에 위치함
Rust는 엄격하지만, DSL 같은 표현력을 깨끗하게 제공함
- Rails가 “마법 같은 객체” 개념을 대중화했음
- 나는 10년 전 Ruby에서 Elixir로 전환했음
알고리즘 성능이 10배 향상되었고, 불변성 덕분에 버그가 줄었으며, 동시성 지원도 훌륭했음
패턴 매칭과 가드 덕분에 보일러플레이트가 사라졌고, GIL이 없고 프로세스별 GC가 있음
학습 곡선은 약간 있지만, Elixir는 장기 유지보수나 부하 측면에서 훨씬 잘 확장됨
Ruby 커뮤니티는 여전히 훌륭함
단지 Elixir가 네이티브 실행 파일로 컴파일되거나 브라우저에서 돌 수 있으면 좋겠음- 나도 비슷한 경험을 했음
여전히 “Ruby로 사고”하지만, 개인 프로젝트는 Elixir/Erlang으로 함
회사에서는 Golang과 Python을 쓰지만 즐겁지 않음
개인 스크립트는 여전히 Ruby로 작성함
- 나도 비슷한 경험을 했음
- 이 글은 마치 누군가 자기 언어를 방어하는 느낌임
인기나 익숙함보다, 언어의 특성이 코드 품질에 미치는 영향을 냉정하게 분석하는 논의가 더 가치 있다고 생각함
그런 논의는 종종 모나드나 어플리커티브 같은 개념 때문에 사람들을 멀어지게 하지만, 그게 진짜 유익한 토론임- 코드 품질, 생산성, 안정성은 객관적으로 측정하기 어려워서 결국 경험의 차이로 귀결됨
- 코드 품질만이 아니라 단순성, 가독성, 표현 속도도 중요함
타입과 제약이 많을수록 품질은 올라가지만, 개발 속도와 유연성은 떨어짐 - 이런 주제에 관심 있다면 Eloquent Ruby 같은 책을 참고할 만함
- “대규모 시스템 구축에 어떤 언어 기능이 유리한가”를 분석한 논문이나 글이 있다면 정말 읽어보고 싶음
- 나는 Ruby 팬은 아니지만, Wired의 원문은 순도 100% 클릭 유도형 분노 콘텐츠였음
이런 글은 HN에서 언어 싸움을 유발하는 독소 같은 존재임
진지하게 받아들일 필요 없음 - 나는 Ruby의 표현력과 완전한 객체지향성, 읽기 쉬운 문법 때문에 좋아했음
하지만 지금은 Kotlin이 더 잘 맞음 — 정적 타이핑과 문법의 인체공학적 설계 덕분임
Ruby는 프로젝트가 커질수록 불안하지만, 여전히 작은 작업에는 사랑스러운 언어임- 예전에 Ruby로 세션 관련 변수를 잘못 써서 사용자 계정이 뒤섞이는 사고를 본 적 있음
언어 탓이 아닐 수도 있지만, 안전장치가 적은 언어일수록 위험한 코드가 모이는 경향이 있음 - Ruby가 완전한 객체지향이라고 하지만, 예를 들어
if.class를 실행해보면 완전히 그렇지는 않음
그래도 대중 언어 중에서는 가장 가까운 수준임
- 예전에 Ruby로 세션 관련 변수를 잘못 써서 사용자 계정이 뒤섞이는 사고를 본 적 있음