Rails는 게토다: 루비 커뮤니티에 대한 비판적 고찰

저자는 Rails 커뮤니티 내에서 겪었던 다양한 부정적인 경험들을 상세히 설명합니다.### Rails 커뮤니티의 문제적 인물들* Kevin Clark 사례: 저자에게 무료 기술 지원을 요구하고, 욕설을 퍼부었으며, 심지어 프로젝트의 핵심 configure 파일을 실수로 삭제하여 개발 흐름을 방해했습니다. 이는 저자가 Rails 커뮤니티를 ‘제대로 교육받지 못한 PHP 출신 바보들’로 여기게 된 계기가 됩니다.* Michael Koziarski (Koz) 비판: Rails 핵심 개발자 중 한 명인 Koz를 ‘무능한 패배자(fucktard loser)’로 지칭하며, 그의 부실한 코딩 실력과 비합리적인 디자인 결정(예: controller/action;edit 경로 파라미터 문제) 옹호를 비판합니다. Koz가 보안을 통해 통제력을 얻으려 하지만 실제로는 보안 코딩 지식이 부족하다고 지적합니다.* Alex Bunardzic (Raymond James) 사례: 저자를 다른 사람과 혼동하여 ‘재고용 불가’ 블랙리스트에 올리고 명예를 훼손하려 했던 사건을 폭로하며, 개발 관리자로서의 기본적인 역량 부족을 강조합니다.### Rails의 근본적 결함과 DHH의 기만* Rails의 창시자인 DHH(David H.)가 자신의 주요 Rails 애플리케이션이 하루에 약 400번 재시작될 정도로 극도로 불안정했음을 언급합니다. 이는 평균 4분마다 재시작이 필요했다는 충격적인 사실로, 저자는 이를 ‘모두를 속인 행위’로 규정합니다.* 저자가 가비지 컬렉션(GC), 스레드(Threads), I/O 관련 버그를 발견하고 Mentalguy가 fastthread로 해결했음에도 불구하고, Rails Core 개발자들이 이를 부정하고 저자를 소외시켰다고 비판합니다.### 컨설팅 업계의 허상과 ThoughtWorks의 사례* 저자는 기업들이 유능한 정규직 고용 대신 고비용의 컨설팅 펌에 의존하는 ‘집단 히스테리’를 비판합니다. 컨설팅 펌이 직원 임금의 5~6배에 달하는 비용을 청구하면서도 낮은 품질의 서비스를 제공한다고 지적합니다.* ThoughtWorks 비판:* ThoughtWorks가 Rails 시장에 진입하며 C# 및 Java 개발자들을 2주 단기 교육 후 ‘Rails 전문가’로 둔갑시켜 고객에게 고액의 프리미엄을 청구했다고 폭로합니다.* 이로 인해 프로젝트에 배치된 인력들은 Ruby 관용구나 좋은 디자인 원칙에 대한 이해 없이 형편없는 코드를 양산했다고 주장합니다.* 저자가 인수한 ThoughtWorks 프로젝트에서 코드 품질은 매우 낮았으며, 비효율적인 프로세스(과도한 페어 프로그래밍, 불필요한 테스트)로 인해 생산성이 저하되었음을 밝힙니다. 저자는 이러한 관행을 제거한 후 적은 인원으로 생산성을 두 배로 높였다고 증명합니다.* ThoughtWorks가 Rails를 Visual Basic이나 COBOL과 같은 ‘기술적으로 비난받는 언어’에 비유하며 그 가치를 훼손했다고 비판합니다.### Rails의 미래 예측* 저자는 Rails가 Java Portals의 전철을 밟을 것이라고 예측합니다. 스타트업에서 시작하여 기업 환경으로 확산되면서 실패를 거듭하고, 결국 정부 부문으로 밀려나 COBOL과 함께 정체될 것이라는 비관적인 전망을 제시합니다. 이는 ThoughtWorks와 같은 컨설팅 펌의 부실한 구현이 Rails의 명성을 실추시키는 주된 원인이 될 것이라고 강조합니다.