Ruby on Rails의 진화, 그리고 웹 개발의 미래

예전에 연구자로서 개발(programming)을 한다는 것에 대한 글을 쓴적이 있지만, 박사 논문 Proposal 등을 준비하느라 코드에 한동안 손을 대지 못하다가 최근에야 다시 시작할 수 있었습니다. 예전 글에서도 파트타임 개발자(?)의 어려움을 이야기한적이 있지만, 1년 전에 작성한 코드를 다시 읽고 기능을 추가하는 일은 역시 난감했습니다. 코드를 다시 머리에 넣는 것도 문제였지만, 예전에 작성한 코드가 문제투성이로 보이는 바람에, 처음부터 새로 짤까 고민하기 시작했습니다. (개발자라면 이런 고민 해보셨을 겁니다 ;)

또 하나의 문제는, 제가 사용하는 웹 프레임웍인 Ruby on Rails (Rails)가 3.0으로 버전업되면서 기존에 작성한 코드를 상당 부분 고쳐야 한다는 것이었습니다. Rails 2.0이 나왔을 때도 비슷한 일을 겪었었는데, 이처럼 프레임웍의 진화가 역설적으로 이에 기반하는 애플리케이션의 유지보수에 어려움을 주는 것이 큰 문제라고 생각했습니다. 하지만, Rails 3.0의 변경 내용을 구체적으로 살펴보면서 이런 불만은 탄성으로 바뀌었습니다. 애자일(agile) 웹 프레임웍의 대표격으로 인정받는 Rails이지만, 변화하는 웹 환경에 발맞추기 위해 끊임없이 혁신을 지속하는 점이 놀라웠기 때문입니다. Rails 3.0이 나온지는 꽤 시간이 지났지만, 이번 글에서는 Rails의 변화된 모습과 이에 관련된 웹 개발의 동향에 대해 알아볼까 합니다.

모듈화 및 플러거블 아키텍쳐

우선 가장 눈에띄는점은 Model-View-Controller로 이루어진 웹 프레임웍의 각 부분을 모듈화해 상호간의 인터페이스를 최소화했다는 점입니다. 이는 단순히 프레임웍의 유지보수를 편하게 하는 차원을 넘어, MVC의 각 구성요소를 사용자 편의에 맞게 바꾸는 것을 가능하게 합니다. 예컨데, Model쪽에서 기본으로 제공되는 ActiveRecord라는 데이터베이스 어댑터 대신 NoSQL 류를 포함한 다른 데이터 소스(persistence layer)를 사용할 수 있게 되었고, View측면에서 Prototype이라는 자바스크립트 프레임웍 대신에 JQuery를 사용할 수 있게 되었습니다. 유닛 테스팅에도 기본으로 제공되는 Test/Unit 대신에 BDD(Behavior-driven Development)에 기반을 둔 RSpec을 사용할 수 있습니다.

이런 변화가 웹 개발환경 자체의 특성과 어떤 관련이 있을까요? 웹은 끊임없이 신기술이 명멸하고, 근본적인 패러다임이 몇 년을 주기로 변화하는 다이나믹한 환경입니다. 이런 상황에서 웹 프레임웍이 특정한 컴포넌트의 사용을 강요하는 것은 사용자의 선택을 제약할 뿐 아니라, 프레임웍 자체의 가치를 위협하는 요소인 것입니다. 예컨데, Rails에 처음 Javascript 프레임웍이 채택되었을때, Prototype은 단연 우뚝선 존재였으나, 몇년 사이에 JQuery가 더 인기를 끌게 되었습니다. 백엔드 역시 모두가 MySQL등 RDBMS를 사용하는 환경에서, NoSQL이라는 이름의 Schema-free 어프로치가 세력을 키워가고 있습니다. 

이 모두가 최근 2-3년간 생긴 변화이고 앞으로도 이러한 추세는 계속될 것이기에, 프레임웍에 더 많은 기능과 제약을 부여하기보다는 프레임웍의 크기를 줄이고 모듈화하는 Rails의 변화는 환영할만합니다. 개발자 입장에서 모듈화에 따른 또다른 장점은 Rails 프레임웍의 소스 코드를 이해하기가 훨씬 편해졌다는 점입니다. 본격적인 애플리케이션 개발을 하다 보면 많은 경우 프레임웍 자체에 어느 정도 수정을 가해야 한다는 점을 고려하면 이 역시 작은 장점은 아닙니다.

REST(레스트) 프로토콜 지원

웹 사용이 일반화되면서 꾸준히 제기된 개념이 '기계가 사용하는 웹'입니다. 그리고, 이를 실현하기 위해 근 10년간 Semantic Web이라는 이름으로 다양한 스펙이 제안되었지만, 아직 널리 사용되지는 않고 있습니다. 반면에 Web 2.0로 불리우는 웹의 실제 진화 과정에서 웹 서비스의 일부를 API형태로 제공하는 사례가 일반화되었습니다. API는 프로그램에 의해 사용된다는 측면에서 Semantic Web과 같은 개념이지만, 개발 과정에서 복잡한 스펙에 얽매일 필요가 없습니다. 문제는 API의 정의 및 개발이 쉽지 않으며 이에 대한 표준안 역시 없다는 점입니다. 

REST(Representational State Transfer)는 이처럼 웹 서비스의 일부를 표준화된 (따라서 기계가 사용할 수 있는) 형태로 제공하게 해주는 프로토콜입니다. 좀더 구체적으로, REST는 복잡한 스펙대신에 표준화된 URL과 HTML Verb (GET, PUT, POST, DELETE)를 사용하여 웹 서비스를 구성하는 각 객체를 접근하고 수정하는 API를 정의합니다. 서비스 제공자의 입장에서는 복잡한 Semantic Web 프로토콜을 구현하거나 오류를 범하기 쉬운 커스텀 API를 구현하는 대신에, 훨씬 간편한 방식으로 표준 API를 구현할 수 있으며, API 이용자 측면에서는 웹에 존재하는 임의의 객체를 동일한 방식으로 접근할 수 있습니다. 

Rails에서는 1.2버전부터 모든 객체에 대해 RESTful한 (REST 표준에 따르는) API를 제공할 수 있게 하였으며, 2.0버전부터는 컨트롤러에서 RESTful한 API를 제공하는 것을 기본으로 채택하였습니다. 이는 웹 서비스의 모든 구성요소를 최종 사용자에게 제공하는 동시에, 개발자의 추가적인 노력을 전혀 들이지 않고 표준화된 API로도 제공할 수 있다는 것을 의미합니다. 제가 Rails 2.0으로 코드를 업그레이드할 당시에 이런 변화에 대해 불평했던 기억이 나는데, 돌이켜 생각해보면 옳은 결정이라는 생각입니다. 

이밖에도 Rails 3.0은 View에서 HTML5에 호환되는 Mark-up을 지원한다고 합니다. 또한 관련 패키지를 설치하고 관리하는 훨씬 단순한 방법을 제공합니다. 기타 자잘한 변화는 여기서 확인하실 수 있습니다. 

Rails와 웹의 미래는?

이처럼 프레임웍이 개발 생태계에 (혹은 개발 생태계가 프레임웍에) 미치는 영향은 지대합니다. Rails와 같이 영향력있는 웹 프레임웍이 이미 표준화되었거나 가까운 장래에 표준화될 기술의 사용을 적극 지원하고 장려하는 것은 개방과 공유를 근간으로 하는 웹 생태계의 발전에 크게 이바지할 것입니다. 요약하면, 다음 세대의 웹은 지금보다 서비스 각각이 더 유기적으로 결합되어 마치 거대한 하나의 애플리케이션을 사용하는 듯한 느낌을 주게 되지 않을까요. 

끊임없이 바뀌는 프레임웍에 맞춰 애플리케이션 소스를 수정하는 것은 이런 의미에서 가치있는 일일지도 모릅니다. 자신이 사용하는 프레임웍이 환경 변화에 맞추어 발전하지 못한다면, 언젠가 자신의 애플리케이션 역시 시대에 뒤안길로 밀려날지도 모르니까요. 개발자 각각의 그 모든 기술 변화를 이해하고 자신의 애플리케이션의 적용하는 것은 훨씬 더 큰 노력이 필요할테니, 어떤 의미에서 프레임웍의 사용은 변화하는 환경에 적응하는 노력을 최소화해준다고나 할까요.

이제 개발이 본업은 아니지만, 이처럼 새로운 기술이 쏟아지고 모든 면에서 끊임없이 진화하는 웹 개발 환경을 바라보는 것은 흥분되는 일입니다. 이제 다시 TextMate를 켜고 코딩을 할 생각입니다. 요즘 NoSQL류 데이터베이스 중에 MongoDB가 대세라는데 한번 써 봐야겠군요 ;)

p.s. 여러분은 요즘 어떤 웹 프레임웍을 쓰시나요? 한때 우리나라에도 활발한 Ruby / Rails 커뮤니티가 있었던 걸로 아는데요, 검색을 해보니 많이 없어진 모양이네요. 어떻게 된 일인지 아시는 분?