'Ruby on Rails' 검색 결과 1건

  1. 2007.11.12 Javascript on Rails? (2)
오늘 갑자기 Javascript on Rails가 있다면 어떨까 하는 생각을 해봤는데, 상당히 좋을 것 같습니다.

웹 애플리케이션이라는 것은 위로는 HTTP/HTML/CSS/Javascript/DOM 과 같은 기술들의 영향을 받고, 아래로는 RDB의 영향을 받습니다. 위/아래에서 상당히 강력하게 침범해오는 테크니컬 도메인의 어휘/개념들을 효과적으로 막아내고 비즈니스 도메인의 어휘/개념들로 이루어진 중간 지점을 최대한 확보하는 것이 좋은 설계의 관건이죠(사실은 모든 애플리케이션이 이와 유사합니다. 이에 대해서는 다음 기회에 자세히...). 하지만 언어의 장벽 - 하단에서는 SQL, 중간에는 Java/Ruby/Python/PHP, 상단에는 Javascript - 으로 인해 비즈니스 로직의 중복 및 분산이 생기게 마련입니다.

하단의 RDB 쪽에서 중간 레이어로 올라오는 침범을 막기 위해서는 보통 OR-Mapper를 사용합니다. 하지만 완벽한 추상화란 말처럼 쉬운 일이 아니고 결국 하위 레이어로 내려가야 하는 경우가 있게 마련인데, 이 때 문제가 되는 것은 언어의 장벽입니다. 중간 레이어에서는 자바/루비 등의 언어를 쓰고, 아래에서는 SQL을 쓰기 때문에 비즈니스 로직의 중복 및 분산이 생깁니다.

이러한 문제를 극복 혹은 완화하기 위해 언어를 통일하려는 다양한 노력을 하게 됩니다. 예를 들어 Hibernate은 HQL이라고 하는 변형된 SQL을 개발하였고, Rails는 Ruby의 동적인 특성을 잘 활용한 eDSL을 적극 지원하고 있고, .NET Framework의 일부 언어들은 LINQ(Language Integrated Query)라는 개념을 도입하고 있습니다.

SQL을 직접 접할 일이 점점 줄어들고 있고, 비즈니스 도메인의 어휘들이 하단의 테크니컬 도메인의 어휘들 - SQL, RDB 등 - 을 압도하고 있습니다. 좋은 현상입니다.

한편, 상단과의 인터페이스는 어떨까요?

HTTP Request/Response를 추상하기 위해 Action이라는 개념이 만들어지기도 하고, Spring Web Flow 같은 Continuation 기반 프레임워크로 추상화 단계를 더 끌어 올리기도 합니다. ASP.NET의 Web Forms는(뒤이어서 JSF 등) HTTP Request/Response를 상당히 추상화하여 이벤트 기반 아키텍쳐로 바꿔버립니다.

훌륭합니다.

하지만 HTTP만 어찌 한다고 문제가 해결되는 것은 아닙니다. 프로토콜은 프로토콜이고, 그 위를 돌아다니는 HTML/Javascript/CSS에 대해서는 무엇이 이루어진 상태일까요? 특히, Ajax 애플리케이션에서의 자바스크립트 문제는?

대부분은 자바스크립트를 직접 다루게 되는데, 비즈니스 로직과 관련된 자바스크립트 코드를 직접 만지게 되면 또다시 "비즈니스 로직의 중복 및 분산 문제"를 만나게 됩니다. 이를테면 form validation은 클라이언트와 서버 양측에서 모두 수행되어야 하는 비즈니스 로직입니다.

해결책은? ORM과 비슷한 종류의 프레임워크가 자바스크립트 코드를 자동으로 생성해주면 되겠죠. 사실 이러한 방향의 해결책을 제시하고 있는 프레임워크들이 이미 많이 있습니다. ZK나 GWT, 혹은 ASP.NET AJAX 등의 프레임워크를 이용하면 자바스크립트를 자동으로 생성하거나, 서버 사이드 언어를 자바스크립트로 변환할 수 있습니다.

하지만 Relation Algebra만 잘 처리해주면 그럭저럭 쓸만해지는 ORM 프레임워크와는 달리 자바스크립트 자동 생성/변환 문제는 그리 간단하지가 않습니다(에.. 물론 ORM도 복잡한 이슈들이 많겠지만 상대적으로 그렇다는 얘기입니다 ^^). 게다가 Ajax 라는게 나온지 얼마 되지도 않아서 그나마 있는 라이브러리/프레임워크도 아직 기초적인 수준입니다.

현실적이고 쉬운 길은? 서버 사이드 코드로부터 자바스크립트를 자동 생성하는게 아니라, 아예 서버 사이드 코드를 자바스크립트로 짜는 것이죠. (긴 서론 끝에 드디어 Javascript on Rails 얘기가 시작됩니다 ㅎㅎ)

자바스크립트의 가장 큰 장점 하나는 "어디에나 존재하는 언어"라는 점입니다. 클라이언트의 경우 모든 웹 브라우저에 들어 있고, 서버의 경우 윈도 머신이라면 Windows Scripting Host에 들어 있으며(JScript), .NET Framework에는 JScript.NET이 있고, JVM에는 Rhino가 있습니다.

예를 들어 앞서 얘기한 Form Validation을 살펴보면, 서버에서 쓰이는 바로 그 코드가 클라이언트에서 그대로 실행될 수 있습니다(사실 Microsoft는 최소 8~9년 전부터 자사의 제품 - IIS Web Admin, Commerce Server 등 - 에 이런 방식을 활용해 왔습니다. ASP 스크립트 언어를 VBScript가 아니라 JScript로 바꾸면 됩니다). 자바스크립트 코드를 생성하거나, 서버 측 언어로부터 변환할 필요 조차 없는거죠.

이 방식의 또다른 장점은 지금 활발히 진행되고 있는 Google Gears 방식의 On/Off-line 통합 추세와도 잘 맞는다는 점입니다. Google Gears의 동작 방식은 서버측 코드와 동일한 로직의 자바스크립트 코드를 만들고, 이 코드가 클라이언트 상의 DB에 접근하도록 하는 식인데 서버 코드가 이미 자바스크립트로 되어 있다면 아주 쉽게 Google Gears를 지원할 수 있게 됩니다.

On/Off-line 통합과 더불어 또 하나의 유행은 Web/Desktop 통합인데(Mozilla Prism, Adobe AIR 등) 이 또한 쉽게 지원될 수 있습니다. Prism도 그렇고 AIR도 그렇고 Javascript가 바로 쓰일 수 있기 때문이죠.

마지막으로, 현재 한참 개발중인 Javascript 2(ECMAScript 4th edition) 또한 Javascript on Rails에 힘을 실어주는 요소 중 하나입니다. Javascript 2의 주요 목표 중 하나가 "큰 사이즈의 애플리케이션 개발에도 적합한 언어"이라는 점, 그리고 보너스로 메타 프로그래밍이 상당히 강화되었다는 점 등에서 그렇습니다.

이렇게 장점이 많은데, 아무도 이렇게 해볼 생각을 안했을리는 없죠. 구글에서 20% 프로젝트로 Rhino On Rails라는 걸 개발했다는 이야기도 들리고, TrimJunction이라는 오픈 소스 프로젝트도 이미 만들어져 있습니다(예제를 보니 그리 좋아보이지는 않았습니다만 어쨌든).

재미있을 것 같습니다. 그렇지 않나요?
신고
< Newer     Older >

티스토리 툴바