Rails는 왜 그토록 빠르게 인기를 얻었을까요?
단순함이 한몫했습니다. 특히 Java, XML, 엔터프라이즈 개발 세계에서 온 사람들에게는 더욱 그랬죠. 마케팅도 놀라울 정도로 잘 되었습니다. 하지만 그게 전부는 아닙니다.
스타트업 세계에서 Rails가 성공한 데에는 하나의 단순한 사실이 자리하고 있습니다. 바로 기업들이 겪는 문제는 그리 독특하지 않다는 것입니다. Rails는 유연성을 잃지 않으면서도 CRUD 사이트를 만드는 데 탁월했습니다. 그리고 수많은 기업에게 필요한 것은 사실상 그게 전부입니다. 특히 초기 단계에서는 더욱 그렇습니다.
그런데 이는 기업에만 해당되는 이야기가 아닙니다. 소프트웨어 개발자로서 우리가 직면하는 많은 문제는 변하지 않습니다. 물론 해결책은 진화하고 순환하며, 우리도 실력이 늘어납니다. 하지만 이전 세대 개발자들이 발견한 해결책이 오늘날에도 여전히 큰 도움이 됩니다.
그렇다면 미래에 직면할 문제의 답을 알고 싶으신가요? 가장 좋은 방법은 과거를 돌아보는 것입니다.
과거를 돌아보라
Martin Fowler의 웹사이트에는 흔한 문제들에 대한 훌륭한 해결책이 믿기 힘들 만큼 방대하게 축적되어 있습니다. 개발자들이 Event Sourcing에 대해 이야기하는 것을 들어보셨나요? 그는 무려 10년 전에 이미 이 주제에 관한 결정적인 글을 써두었습니다. 새로 만든 REST API나 서비스 지향 아키텍처(SOA)에서 성능과 신뢰성 문제를 고민하고 계신가요? 그 답은 15년 가까이 전에 정리된 그의 '분산 객체 제1법칙'에 있습니다.
Avdi Grimm은 이렇게 말했습니다. "기술 곡선을 앞서고 싶다면, Martin Fowler가 10년 전에 쓴 글부터 조사하기 시작하라." 전적으로 맞는 말입니다. 그의 웹사이트에 있는 패턴들을 읽는 데 투자하는 시간은 프로그래밍 커리어의 미래를 위한 훌륭한 투자가 될 것입니다. 리팩토링 패턴까지는 말할 것도 없습니다.
더 나아가, 애자일 선언문(Agile Manifesto) 저자들이 집필한 책이나 글은 거의 모두 읽을 가치가 있습니다. 15년 전 그들은 오늘날 우리가 부딪히는 똑같은 소프트웨어 아키텍처 문제를 다루고 있었으니까요.
C2 위키에서도 그들의 논의 상당수를 찾아볼 수 있습니다. TDD가 가장 빛을 발하는 시점은 언제인가에 대한 우리의 논쟁 말이죠? 전부 거기에 있습니다. 그것도 한참 전부터요. 이 위키는 오랫동안 존재해 왔고, 지금도 여전히 환상적인 학습 자료입니다.
1990년대 후반부터 2000년대 초반에 출간된 책들 역시 큰 도움이 됩니다. 저는 『Smalltalk Best Practice Patterns』와 『Patterns of Enterprise Application Architecture』(Rails에 지대한 영향을 준 책입니다)를 읽으면서 내내 미소를 지었습니다. 제가 겪어온 문제들을 너무나 정확하게 묘사했기 때문입니다.
개발 트렌드는 순환한다
디자인 유행처럼 소프트웨어 개발 방식도 끊임없이 순환합니다. 분산형에서 중앙집중형으로, 클라이언트 측에서 서버 측으로, 동적 타이핑에서 정적 타이핑으로 말이죠.
경쟁자보다 앞서고 싶으신가요? 다가올 변화를 미리 이해하고, 어쩌면 그 흐름을 직접 이끌고 싶으신가요? 과거를 돌아보세요. 현재의 해결책이 장차 야기할 문제들에 대한 해결책을 연구하세요. 그리고 지난 세대 소프트웨어 개발자들이 남긴 좋은 관습을 다음 세대에 전달하는 데 동참해 보세요.