대부분의 책에서 인터페이스와 추상 클래스에 기반한 프로그래밍이란 얘기가 너무 많이 나와서 흔히 인터페이스를 사용하는게 목적처럼 되어 버리는 경우가 있다. 

인터페이스를 사용하는 것은 수단일뿐 그 자체로 목적이 아니다. 그럼 인터페이스를 사용하는 목적은 무엇일까에 대해 의문을 가져야 한다. 그 답을 알기전에 먼저 인터페이스는 절대선이 아니라는 것을 이해해야 한다. 오히려 인터페이스는 프로그램의 문서화처럼 존재 자체의 손해 보다 더 많은 이득을 얻기 위한 필요악같은 존재이다. 

아이러니하게도 인터페이스는 복잡함을 감소시키기 위한 추가적인 복잡함의 장치이다. 인터페이스를 사용한다는 것은 관리해야 할 파일 하나가 늘어다는 것이므로 그 자체로 복잡함이 증가한다. 다만 인터페이스를 사용함으로서 구현자는 "인터페이스의 책임"의 구현에만 집중할 수 있고 호출자는 별로 관심없는 상세 구현보다 책임 그 자체에 집중할 수 있게 함으로서 "구현자과 호출자 사이의 복잡함"을 감소시킨다. 

여기서 ~사이의 복잡함이란 시간과 공간이라는 차원을 포함하고 있다. 애초에 구현자와 호출자가 같은 시간과 공간에 존재한다면 얻는 복잡함의 감소보다 잃는 복잡함의 증가가 더 크다. 


일단 "공간"에 대해서 말하자면 서울과 LA의 거리라는 물리적 감각보다는 나와 나 이외의 생각의 거리라는 의미가 강하다. 만약 혼자 하는 프로젝트라면 혹은 아주 마음이 잘 맞는 팀이라면 공간 사이의 거리가 크지 않을 수도 있다. 

그러나 "시간"의 거리는 시간이 갈수록 엔트로피처럼 항상 늘어나고 혼자하는 프로젝트라도 시간의 거리는 생긴다. 그래서 나는 인터페이스의 가장 큰 목적은 이 시간의 거리 복잡함을 줄이는 것이라고 생각한다. 다시 말해서 복잡함이란 현재의 특정 상황 혹은 시점에서의 복잡함만을 뜻하는 것이 아니라 지속적으로 변함으로써 생기는 복잡함이 더욱 많다는 말이다. 



시간의 거리로 생기는 복잡함이 보다 복잡한 이유는 이렇게 생긴 복잡함은 지속적인 파동의 다른 변화를 일으키고 이로인해 더욱더 복잡해지기 때문이다.. 게다가 앞날이라는 것은 본질적으로 예측하기 어렵기 때문에 미래를 대비하는 것 작체가 불필요한 복잡합이 야기될수 있다. 


특정 객체가 변해야 할 이유는 그 자체가 아니라 그가 사용하는 객체가 변해야 할때도 일어나고 이때문에 객체는 그 자신보다 보다 덜 변하는 것에 의존하여야 한다. (보다 덜 이라는 의미는 <=(작거나 같다) 의미인데 당연히 < (작다) 로 할수있으면 하는게 더 낫다. ) 

쉬워보이지만 이 원칙은 의외로 지키기 어렵다. 

이에 관해서 첫번째 알려진 것은 벽돌형 layer 아키텍쳐에서 상위 레이어는 하위 레이어에 의존해야 하고 하위 레이어는 상위 레이어에 의존해서는 안된다 라는 것인데 종종 이를 위반하는 것은 상위 레이어와 하위 레이어를 같은 시간에 혹은 같은 사람이 만들기 때문인데 주의하지 않으면 처음 생각보다 쉽지 않다. 

보통의 프로그램에서 하나의 새로운 레이어를 만드는 일은 그리 많지 않지만 하나의 레이어에서도 "보다 덜 변하는 것에 의존해야 한다는 원칙"은 중요한 것은 이것이 단순히 레이어간의 이야기만이 아니기 때문이다.


'Framework > 아키텍쳐 일반' 카테고리의 다른 글

Second Program Effect  (0) 2009.07.17
여섯번째 계  (0) 2009.07.14
호출의 빈도  (0) 2009.07.08
한줄짜리 함수  (0) 2009.07.06
예언?  (0) 2009.06.12
Posted by bleujin

" 설계자의 첫번째 작업은 절제되고 깔끔한 편이 많다. 그는 자신이 하는 일을 아직 잘 모르는 상태라는 것을 인식한다. 그래서 매우 조심스럽고 절제하는 태도를 가진다. 

그가 첫번째 작업을 설계하는 과정에서 다양한 꾸밈과 장식이 떠오르지만 이것들은 "다음번"에 사용할 것으로 일단 옆으로 제쳐놓는다. 머지않아 첫번째 시스템은 끝이 나고 일정한 수준의 시스템을 달성했다는 것을 입증한 설계자는 자신감이 충만한 상태로 두번째 시스템을 구축할 준비에 나서게 된다. 

이 두번째 시스템이 누구에게나 가장 위험한 시스템이다. ~ 두번째 시스템에서는 첫번째 시스템에서 옆으로 제쳐두었던 모든 아이디어와 치장들을 사용하여 과도하게 설계하는 경향이 나타나게 된다.  "


브룩스는 두번째 시스템 효과에 대해 말하면서 성공한 제품의 두번째 제품은 과도한 설계로 과도하게 복잡한 시스템이 될 가능성이 많음을 경고하였다. 여기서 과도하게 복잡하다는 것은 시스템을 세련되게 만들기 위한 장치가 시스템의 기본 장치보다 더 앞서가게 되는 것을 말한다. 

보통의 경우 두번째 시스템은 첫번째의 그것보다 기능이 더 많다. 그리고 이것들은 적절히 분류 관리되거나 절제되어 있지 않음으로서 UI가 복잡해지고 옵셔널한 기능이 많아지면서 설정이 많아지는 등이다. 

솔류션 시스템의 경우 첫번째 시스템에서는 직접적으로 고객과 맞닿는 일이 많지 않다. 대부분 실험실에서 소수 인원의 설계로 인해 통일되고 간결한 형태를 지닌다. 첫번째 버전이 고객에게 팔리게 된 이후에 많은 추가 요구사항이 생기게 되고 그것들의 일부는 서로 이율배반적이다. 

설계자는 그것들을 잘 조절하려고 노력하겠지만 그러함에도 많은 요구사항을 어쩔수없이 받아들임으로서 두번째 시스템은 500라인짜리 XML 설정 파일을 가지게 되는 경우는 흔하다. 아마도 그 설정파일의 대부분 사용되지 않을 옵션 기능을 설정하고 활성화 시키는 역할들을 담당하지만  너무도 길고 복잡해서 그에 관심을 쏟는 사용자는 거의 없다. 

이후 이것들은 문제가 생겼을 경우에 문제의 해결에 장애가 되고 덧데기와 IF 코드로 빠르게 부패되는 시스템이 된다. 

이러한 것이 근본적으로 피할수 없는 문제는 아니다. 브룩스는 그 해결방법의 하나로 두개 이상의 시스템 작업을 한, 노련한 설계자를 선택하는 것을 들었지만 사실 최근 대부분의 프로젝트는 과거와 같이 오랜 시간동안 초기 설계자가 이후에도 꾸준히 참여하는 경우는 극히 드물다. 프로젝트는 대부분 1년 이내이며 그동안 인원이 바뀐다. 첫번째 시스템이 성공하든 실패하든 말이다. 

개인적으로 시스템의 발전 방향은 기능의 개수를 늘리는데 집착할 것이 아니라 좀더 똑똑한 시스템이 되어야 한다고 생각한다. 기존의 기능과 상충되는 요구사항이 들어왔을 경우 혹은 목적은 같지만 처리가 달라질 경우에 이후에 개발자도 까먹을 유연성(?)을 이유로 XML 설정 파일을 늘리는 것은 해결책이 될 수 없다. 

똑똑한 시스템이란 사용자의 행동에 주목하는 시스템을 말한다. 사용자가 말하는 것이 아니라 원하는 것을 하는 시스템을 만들어라 라는 말이 있는데 아웃룩의 메일관리와 지메일의 메일관리의 차이이다. 아웃룩은 메일을 분류하기 위해 4단계 이상의 설정을 거치지만 지메일은 달랑 제목을 파싱해서 링크해주는 것 하나이지만 앞의 관점에서 지메일의 관리방식이 좀더 똑똑하다. 


'Framework > 아키텍쳐 일반' 카테고리의 다른 글

일곱번째 계 - 호출의 빈도(1)  (0) 2009.07.24
여섯번째 계  (0) 2009.07.14
호출의 빈도  (0) 2009.07.08
한줄짜리 함수  (0) 2009.07.06
예언?  (0) 2009.06.12
Posted by bleujin
Framework/Another Lore2009. 7. 15. 02:26

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배의 시간이 걸린다면 아마도 내가 잘못 선택을 한것이다. 


'Framework > Another Lore' 카테고리의 다른 글

언젠가...  (0) 2009.08.14
레이어의 속도  (0) 2009.07.05
read & write  (0) 2009.06.25
최근에 책을 읽다가..  (0) 2009.06.11
AL : Permission  (1) 2009.04.30
Posted by bleujin