XUL 단상

AL Client를 XUL(ThinLet)를 사용해서 약 한달간 만들었는데. 브라우저가 아닌 Java에서의 XUL은 2% 부족하다는 느낌이다. 

XUL(XML User-Interface Language)은 단순히 IDL 이므로 다양한 Client에서(물론 이전에 클라이언트가 XUL을 인지해야 한다. Firefox와는 달리 대표적인 브라우저인 ie는 XUL을 지원하지 않는다. ) 별도의 UI 로직를 고심할 필요가 없다는 것은 크나큰 장점이다. (https://developer.mozilla.org/Ko/The_Joy_of_XUL 모질라의 XUL Page)

그러나 XUL이 세상에 나온지 5년이 넘게 지났지만 생각보다 그 영향력은 매우 미비하다. 개인적으로는 XUL을 써보면서 lightweight Framework는 lightweight 하다라는 사실을 새삼스럽게 느꼈다. 

XUL의 Java OpenSource인 ThinLet(http://thinlet.sourceforge.net/component.html)는 매우 훌륭한 프레임워크였다. 무엇보다 놀란것은 그 간결한 구조였다. ThinLet은 XML을 Object Array Tree 형태로 관리하여 개별적인 컴포넌트의 paint를 구현한다는 것은 복잡한 머리속을 순식간에 관통하게 만드는 Simple 미학을 보여준다. Java의 Swing에 의존하지 않기 때문에 오히려 역으로 확장이 쉬운 아키텍쳐이다. 

XUL의 장점은 대표적으로 

    Based on existing standards, 

    Platform portability, 

    Separation of presentation from application logic, 

    Easy customization, localization, or branding 

등을 들 수 있다. 특히나  HTML 처럼 XUL은 플랫폼 중립적(platform-neutral)하기 때문에 비교적 단순하게 portable하고 cross platform application UI를 만들수 있다는 점에 매료되었다. 

문제가 됐던것은 바로 Lightweight 하다는 점이다. 어느정도 익숙해지고 난후 ThinLet은 Draggable한 Panel을 지원하지 않았기 때문에 ThinLet의 단순한 아키텍쳐에 감탄하면서 ThinBean 형태로 확장해서 만들었다. 얼마 지나지 않아서 다시 Draggable한 Table이 필요했고 역시 또 만들었다. 이 과정에서 ThinLet의 이벤트 처리 과정을 대폭 수정해야 했다. 왜냐하면 기본적인 Action Handler로는 너무 부족함이 많았고 결정적으로 Drag할수 있도록 Table의 Cell을 프로그램이 인지해야 했다. ThinLet에서 모든 객체는 paint된 pixel에 불과했기 때문에 Mouse Event가 발생한 곳의 객체를 인지하게 만드는 과정은 매우 복잡했고(zindex가 있음을 생각해보자) 어려웠다. 

나를 결국 손을 들게 만든건 Draggabl한 TreeTable이다. AL은 저장 구조상 TreeTable UI가 꼭 필요했다. 1주일이 넘게 삽질하면서 XUL에서 독립적인 Draggable한 TreeTable UI를 만들기는 아주아주 어렵다는 사실을 알았고 더 큰 문제는 설사 만든다고 하더라도 더 이상 그것은 XUL이 아니라는 사실을 깨닫게 됐다는 점이다. 

이른바 추상화의 함정에 빠진것이다. 

XUL은 일종의 새로운 추상층(Abstraction Layer)이다. 소프트웨어는 마치 양파와도 같이 겹겹이 층을 이루고 있는데, 각층은 그 아래충 위에 조심스럽지만 다소 불안정하게 쌓여있다. 새로운 층이 쌓일때마다 뭔가 복잡하고 지엽적인 것이 좀더 직관적이고 보편적인 것으로 대체되기 때문에 컴퓨터 공학에서는 추상을 여러개의 조그만 프로세스를 묶어 하나의 큰 프로세스로 만드는 과정이라고 정의한다. 

조엘의 말에 따르면 모든 추상화는 완벽하지 않고 함정이 있다고 하는데 예컨데 우리가 Java나 C#을 쓰지만 여전히 point에 대해서 알아야 한다는 것이다. VC++의 MFC 혹은 Delphi의 VCL만 쓰면서 Win32 API에 대해 전혀 알 필요가 없다면 정말 좋겠지만 조금만 더 깊이 들어가려 하면 바로 포인터와 관련된 지식을 만나게 되는 것과 같다. 사실 나는 기꺼이 Open된 ThinLet 코드를 볼수 있고, 가지고 있었기 때문에 사다리를 오르락 내리락 하며 문제를 수정했고 이러한 구멍에 대해서 충분히 이해를 하고 있었다.

그러나 결정적으로 수정에 수정을 거듭하다보니 수정된 프로그램은 XUL이라고 부르기에는 부끄러울 정도로 너덜너덜 해졌다. ThinLet의 마지막 버전은 2005년이고 코드를 작성하는 내내 왜 아무도 Draggabe한 Panel이나 Table을 만들지 않았을까가 궁금했었다. 그 의문은 그동안 겪었던 많은 문제들처럼 오랜동안 헤딩을 하고서야 깨달았는데, 쉽게 말하면 HTML에서 Draggable한 Table을 만들지 않는 이유와 같다. HTML처럼 XUL은 View를 하기 위한 Markup Language인데 Drag Action은 View가 아닌 영역에도 발을 걸칠수 밖에 없다. 즉 이전처럼 Model를 단지 View하기만 했던 구조와 달리 Drag등의 Action이 들어가는 순간 VIew는 Model을 인지하지 않으면 View를 할 수 없게 되었다. 그리고 Model과 Controller가 혼합되면서 Draggable한 TreeTable을 만든다고 하더라도 이게 그건 VIew역할을 하는 XUL이 아니고 오히려 더 복잡해진 정체를 알수 없는 혼합물이 되어버린 것이다. 

사실 프로그래밍 언어에 한해서는 이제 거의 이런 추상화의 문제로부터 벗어나 보인다. 우리는 수십년전의 어셈블리 개발자의 포트란 개발자에 대한 비난을 이젠 역사서에서나 읽을 수 있으니 말이다. 그러나 아직 개별적인 프레임워크에 있어서 그러한 함정은 너무나 많다. 

물론 이것이 XUL은 단지 VIew이기 때문에 XUL의 잘못이라고는 할 수 없다. 그러나 Helloworld를 만드는 것은 버튼 하나로 만들수 있지만 10만줄 짜리 프로그램을 만드는 데는 2배의 시간이 걸린다면 아마도 내가 잘못 선택을 한것이다.