며칠 전 solnic님이 더 이상 Rails를 쓰지 않는 이유를 글로 정리했습니다. solnic 이 글과 관련 토론을 재미있게 읽었습니다. 그래서 제 느낀 점만 짧게 남겨 두려고 합니다.

저는 Ruby와 Rails를 좋아합니다. 동시에 solnic님의 Rails 비판에 공감하는 부분도 많습니다. 그분의 글은 한마디로 Rails의 tight-coupling을 지적하는 글입니다. 조금 더 풀어 보면 다음 세 가지를 비판하고 있다고 생각합니다. 첫째, 매우 복잡한 로직을 “쉬운” 인터페이스 뒤에 숨긴다는 점. 둘째, 앱의 도메인 로직이 Rails core features에 tight-coupling된다는 점. 셋째, ActiveSupport는 나쁘다는 점입니다.

지적에는 공감하지만 저는 여전히 Rails가 좋습니다. 오히려 그분이 지적한 부분이 Rails의 장점이라고 생각하는 면도 있습니다.

solnic님은 User.create(params[:user])라는 코드가 “쉬운 인터페이스 뒤에 복잡한 로직을 숨겨 둔 사례"라고 지적합니다. Rails의 ORM인 ActiveRecord는 실제로 그분의 지적대로 매우 많은 일을 하고, 여러 곳에 의존하며, 심지어 웹 폼 데이터까지 그대로 받아들입니다. 결벽스러운 소프트웨어 공학자라면 비명을 지를 만한 설계입니다. 도메인 로직과 프레임워크가 loose-coupling일수록 더 좋은 소프트웨어인 것은 맞습니다. 다만 제가 이해하는 Rails way는 loose-coupling을 지향하지 않습니다. Rails는 simple보다 ease-of-use를 지향합니다. tight-coupling한 결정이라도 그것이 쉽고 편하다면 Rails는 그 길을 택합니다.

물론 저도 simple한 모듈들을 조합하는 방식이 이상적이라고 생각합니다. 하지만 매우 loose-coupling되고 모듈화된 프레임워크가 장점만 있지는 않았습니다. 프로그래머마다 조합하는 방식에 일관성이 없고, 여러 사람의 손을 거치면서 오히려 복잡해지고 유지보수가 힘들어지는 경우를 자주 봤습니다. 그래서 저는 Rails way를 좋아하고, 개인 프로젝트에는 Rails를 씁니다.

User.create는 프레임워크와 제가 만드는 앱 사이의 일종의 API입니다. API가 사용하기 쉽고 내부에서 복잡한 일을 한다는 점은 그렇게 중요한 문제가 아니라고 생각합니다. DB 엔진 내부가 복잡하고 자세히 몰라도 우리는 SQL이라는 인터페이스로 손쉽게 조회를 합니다. 문이 어떻게 열리는지 내부 구조를 몰라도 손잡이를 돌려 문을 엽니다.

정작 중요한 문제는 내부 구조를 확장해야 할 만큼 앱이 복잡해졌을 때입니다. 예를 들어 MySQL의 내부 구조는 전혀 모르고 SQL 인터페이스로 사용만 해 오다가, SELECT 문에 특정 기능을 추가해야 한다면 어떻게 할까요. MySQL 내부 구조를 연구해서 쪼개고 직접 수정해야 할까요. Rails는 이런 상황에 우아한 해결책을 주는가, 묻게 됩니다. 제가 보기에 Rails는 이 부분을 고려해서 만들어졌거나, 또 그리 중요하게 여기는 프레임워크는 아닙니다. 다만 제 경험에 한정하면, Rails의 내부 구조를 쪼개서 기능 변경을 해야 할 만큼 비즈니스 로직이 복잡해진다면 일단 제 설계를 의심해 왔고, 그렇게 해서 풀리지 않는 문제는 지금까지 없었습니다.

ActiveRecord.suppress와 ActiveSupport가 나쁜 접근이라는 점에는 동의합니다. 저도 가능하면 쓰지 말아야 한다고 생각합니다. 다들 쓴다는 점에서 조금 우울하긴 합니다.

저는 무엇보다도 사용자가 필요로 하는 기능을 빨리 만들고 빨리 바꾸는 일을 중요하게 생각합니다. MVC, SOLID, 디자인 패턴, DDD 같은 것을 따져 가며 완벽한 소프트웨어를 만드는 일은 나중에 해도 됩니다. 그런 일은 학교에서 열심히 연구하면 됩니다. 저는 quick and dirty로 사용자가 원하는 것을 구현하고 나중에 리팩토링하는 길을 선호합니다. quick and dirty에 가장 최적화된 언어는 PHP입니다. Facebook이나 Tumblr 같은 곳이 성공한 이유도 거기에 있다고 생각합니다. 다만 PHP에는 더러운 코드가 그대로 굳어질 가능성이 높다는 결정적인 단점이 있습니다. 그런 면에서 저는 Rails를 쓰면서 만족하고 있습니다.

사실 제가 Rails를 쓰는 가장 큰 이유는 테스트 코드 작성이 쉽다는 점입니다. 저는 Java 진영에서 직업으로서의 프로그래밍을 오랫동안 해 왔는데, 제가 거쳐 온 프로젝트들에서는 만족스러운 테스트 코드를 좀처럼 만나지 못했습니다. 사람은 쉬우면 하고 어려우면 잘 하지 않게 됩니다. 테스트 코드 없이 리팩토링을 하거나 반복된 로직을 줄이는 일은 매우 어렵습니다.

한 발 더 나아가, 요즘에는 테스트 코드 작성과 기존 로직의 “변경"이 어려운 언어나 프레임워크를 쓰는 서비스는 결국 실패한다는 편견까지 생겼습니다.