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