Framework 2.1: RubyOnRails vs. TurboGears, Part 2

Panel discussion - 장혜식, 황대산, 강문식, 김형용, 이정민

패널 토론의 첫번째 주제는 테스팅이었다. Rails는 unit testing, functional testing, integration testing을 제공하고 fixture에서 Model을 사용해서 DB상의 테스트 데이터를 준비할 수 있었다. Django도 거의 유사했는데 unit testing과 테 스트 데이터를 준비하는 방법을 제공하고 Web client를 사용해서 response 내용을 직접 확인하는 방법을 사용할 수 있었다. 실제 예를 보지 않고 말로 설명을 듣는 것만으로는 차이점이 그다지 부각되지 않는 것 같았다.

두번째 주제는 각각이 제공하고 있는 ORM이 어느 정도 customizable한 가였다. Rails의 경우에는 Model의 find 메서드의 여러가지 parameter를 통해 유연성을 제 공하고 custom SQL까지 활용할 수 있도록 해주었다. Django에서는 Model의 filter 메서드를 통해서, 특정 조건에 해당하는 iterable 객체를 얻을 수 있는데, filter 메서드를 통해서 얻어지는 객체는 일종의 proxy 객체인 모양으로 Model 객체를 fetch할 때 실제 query가 이루어진다고 했다. 약간 신기했던 것은,

와 같은 코드에서 '[:5]'와 같은 것은 primitive한 language constructs로 보 이는데도 (아마도) proxy 객체의 메서드로 다른 proxy 객체를 return하는 메서드 처럼 동작한다는 것이다. (ruby에서도 가능한가?)

첫번째와 두번째 패널 토론 주제는 토론자들이 미리 준비해온 것들이었고, 그 다음부터는 두 세션 이후에 적어서 제출한 질문서에서 장혜식 님이 뽑아서 토론자 들에게 질문을 던지는 방식이었다.

첫번재 질문은 내가 써 낸 '기본 웹프레임워크와의 본질적인 차이는 무엇인가' 하는 것이었다. 사실 후속 질문으로 '그 차이가 각각의 언어에 얼마나 기반하고 있는가'라는 질문도 적혀있었는데, 적당히 생략된 것 같았다.

Rails의 경우에는 역시 'Convention over Configuration'이라는 답변이 나왔다 . Django측에서는 Python의 feature들을 잘 살린 것 같다는 답변이 나왔다. 더불 어 여러가지 다른 웹 어플리케이션 개발 프레임워크들을 써본 경험이 없으나 C CGI 보다는 낫다는 답변을 하셨다. 개인적으로는 '대안'을 모색하기 위해서는 기 존의 것들을 더욱 잘 알고 이해하고 있어야한다고 생각하기 때문에, 이런저런 웹 프레임워크들의 '본질'이 무엇인가에 대단히 관심이 많은데, 대안 웹프레임워크에 는 (참여하는 개개인은 그렇지 않을지언정) 내용상으로는 아직 그러한 점이 부족 한 것 같다.

그 다음으로 나온 질문은 각 프레임워크에서 활용할 수 있는 IDE에 관한 것이 었다. Rails 경우에는 RCP위에 만들어진 RadRails가 있고, MacOS 환경에서는 screencast들에서 많이 보였던 것처럼 console과 TextMate를 조합해서 쓰는 방법 도 있다고 했다. Django를 발표하신 분들은 주로 gvim이나 Python용 IDE, 그리고 console을 활용해서 Django를 사용하신단다.

세번째 질문은, Model 디자인으로부터 DB schema를 생성해내는 Django의 방식 을 Rails에서 사용하면 좋지 않을까 하는 것이었다. Migration의 이점을 잃어버리 게 된다는 답변이었으나, 분명 높은 수준의 언어로 Model을 기술하는 Django의 방 식에도 이점이 있는 것이 분명하다. 두가지 방식의 이점을 모두 얻는 방법은 없을 까?

네번째 질문은 과연 MVC로 가야하는가, MVC의 단점은 무엇인가, MVC만이 웹 어 플리케이션 개발 프레임워크의 해결책인가 하는 MVC에 대한 총체적인 의문이었는 데, 대안 웹 어플리케이션 개발 프레임워크를 고민하는데 있어서 상당히 중요한 질문이었다고 생각한다. 질문자 분의 논지 중 하나는 business logic을 빼놓은 Model은 Entity에 불과한데 과연 Model을 고수할 필요가 있는가 하는 것이었다. MVP라는 단어를 언급하셨고, Naked object, Morphic 같은 것도 예로 드셨는데, 제 대로 이해를 못했다. MVC에서 각 요소에 해당하는 Model, View, Controller 사이 의 구분이 웹 어플리케이션에서는 매우 모호하다는 것도 문제점 중의 하나로 지적 되었다.

개인적으로는 MVC로 웹 어플리케이션의 복잡성을 야기시키는 몇가지 문제를 해 결하더라도 근본적으로 View의 복잡성이 다른 요소에 비해 너무 크고, 그 복잡성 을 관리하기 힘든 것이 난제라고 생각한다. 웹 어플리케이션의 View에 해당하는 Markup 언어의 rendering이 현재와 같이 Model이나 Model의 일부를 템플릿 엔진에 넘겨주고 Helper 객체의 도움을 받는 정도로 이루어지는 것은, 그러한 복잡성을 해결하는데 한계가 있다고 생각한다. 시야를 돌려 다시 데스크탑 어플리케이션을 보면, View의 component화, 즉 widget 개념이 GUI에서 어느 정도 성공을 거두고 있다. 웹 어플리케이션도 이를 통해 View의 복잡성 문제를 상당한 부분 해결할 수 있지 않을까 생각한다. 또한 이러한 방향의 노력이 몇몇 프레임워크나 상용 솔루 션, 표준 들에서 보이고 있는 것도 사실이다.

TurboGears - 이만용

TurboGears는 다른 프레임웍들과는 달리 서로 다른 프로젝트의 프로덕트들의 조합으로 이루어져 있다. 이러한 기어들(gears)은 Javascript 라이브러리인 Mochkit, 템플릿 시스템에 해당하는 Kid, Servlet 엔진 내지는 Controller 역할을 하는 것으로 보이는 CherryPy, ORM을 제공하는 SQL Object로 이루어져 있다. 이들 은 모두 Python의 미적 취향을 가장 잘 살릴 수 있는 (Pythonic) 기어들(gears)이 고, 필요하다면 이를 다른 프로덕트로 대체할 수 있다고 한다. 이를테면 Kid의 경 우에는 block의 끝을 명시하는 programming constructs가 없는 Python 언어에 부 합하기 위해서 div element의 property로 템플릿 내에 들어가는 코드를 표현하고, 이를 통해서 Well-formed XML을 유지하게 해주기도 한다.

TurboGears는 "explicit is better than implicit"이라는 철학을 가 지고 있다고 한다. 개인적으론 "should be explicit where it should be"이어야 한다고 생각하지만.

Seaside - 김승범

Seaside는 Smalltalk로 만들어진 웹 어플리케이션 개발 프레임워크다. 김승범 님의 유창한 설명을 들으며 청중들은 계속 놀라며 신기해 했는데, 그 중 하나는 바로 페이지 별로 코드를 만드는 것이 아니라, business logic의 흐름을 하나의 코드로 써놓으면 여러 페이지로 동작하는 것이었다. 이는 Smalltalk의 continuation 때문에 가능한 것이라고 했다.

Squick 개발 환경도 상당히 흥미로왔는데, 개발 방식이 항상 실행할 때 존재하 지 않는 메서드 에러가 나면, 디버그를 하고, 코드 수정해서 메서드를 추가하고, 중단한 지점부터 계속 실행하는 방식으로 이루어진다고 한다. 이 때문에 프로그램 개발 자체가 디버깅이라고 한다.

Seaside의 개발도 이와 마찬가지로 웹 페이지에서 바로 디버그, 코드 보기, CSS 수정등이 가능했다.

다른 특이한 점은 Widget을 component 형태로 제공한다는 점이었다. 어느 분이 말씀하신대로 Seaside가 아마 웹 어플리케이션 개발 프레임워크 전쟁에서 주도권 을 잡지는 않겠지만, 여러가지 새롭고 유효한 아이디어를 제공해준다는 면에서 매 우 흥미로웠다.

총평

행사 도중 메모한 것들 만으로 글을 꾸며내려니 행사의 여러가지 면들을 모두 표현하지 못한 것 같다. 웹 어플리케이션 개발 프레임워크에 조금이라도 관심이 있는 사람으로서 같은 관심사를 가진 뛰어난 분들과 함께 자리하게 되어서 매우 재미있는 시간이 되었던 것 같았다. 한국의 개발자 커뮤너티에 대해서 대단히 비 관적인 편인데, 이러한 행사에 직접 참가하고 보니 그렇지만도 아니라는 사실을 깨달았던 것 같다. 단지 지식만을 얻고 가게된 모임이 아니라 여러가지 많은 생각 도 하게되고 좀 더 열심히 해서 이렇게 뛰어난 분들과 함께 일하고 싶다는 동기부 여도 받은 경험이었다.