템플릿 엔진에서의 모델-뷰의 엄격한 분리

며칠 전 블로그에서 김창준님의 추천으로 Enforcing Strict Model-View Separation in Template Engines이라는 논문을 봤습니다. 이거 웹 프로그래밍으로 논문까지 쓰고.. 역시 연구하는 사람은 어디든 있군요~

그동안 써본 템플릿 엔진 albatross, DTML, HTML::Template::Sigma, Quixote PTL 이 다섯은 처음 쓸 때는 아주 신세계가 열린 듯한 기분이 들었다가도 쓰다보면 금방 답답함을 느꼈습니다. 그 이유를 대충 정리해 보자면,

• albatross: HTML 태그 형태로 명령을 지원하는데 태그와 본문 간의 간격을 줄이기 위해서 어트리뷰트를 더 쓴다던지 하는 아주 지저분한 트윅이 필요하고, 특히 루프 돌릴 때 루프 변수를 조작하기가 매우 까다로워서 템플릿에 코딩까지 해야할 정도.

• DTML: 알바트로스보다는 훨씬 깔끔한 루프 변수를 지원하고, 여러모로 디자인이 잘 된 HTML 태그 모양의 템플릿이긴 하지만, 템플릿 쪽에서 제어 코드를 넣어야지만 처리가 가능한 경우가 너무 많다.

• HTML::Template::Sigma: 아주 단순한 블럭, 인클루드를 만을 지원하는 언어라, 진짜로 템플릿에는 데이터만 들어갈 수 있도록 만들어 주기는 했지만, 너무 단순해서 에러 보고가 제대로 안 되는 바람에 에러가 나면 제대로 잡기가 거의 불가능. -O- 일일이 하나하나 다 바꿔가며 디버깅을.. ㅠ.ㅠ

• Quixote PTL: 템플릿 언어계의 반항아! 다른 템플릿 언어들과는 완전히 다른 위젯 개념으로 코드가 템플릿을 감싸 안는 방식을 채택했다. 굉장히 혁신적이고 신선하긴 하지만, 아무래도 템플릿에 코드가 덕지덕지 붙은 이상은 디자이너들한테 쓰라고 하는 것은 불가능한터라, 개발자가 만들어서 개발자들만 보는 관리 프로그램등에나 쓸 수 있을 듯.

흐흐~ 그래 웹 프로그래밍은 다 이런거야 하고 좌절을 하고 있었는데, 이 논문을 보고 원래 다 그런 건 아니구나 하고 실낱같은 희망을 얻게 되었습니다. 이 논문에서는 템플릿에서 완전히 로직을 제거하는 게 단지 이상향으로만 존재하는 게 아니라는 것을 여러가지 증명으로 보여주고 있는데, 실제로 템플릿에 마구 로직이 섞여서 결국은 디자이너들이 감히 템플릿에 손을 못 대도록 만드는 문제의 원인이 템플릿 언어들이 파워를 잃어버릴까봐 템플릿 언어 안에 코드를 섞어 쓰는 것을 허용하는 것 때문이라고 합니다. 실제로 대부분의 템플릿 언어에서는 테일러 급수로 sin(x)를 전개하는 것이 가능하다는군요. (-ㅇ-;) 그래서 머피의 법칙 “if it can be done wrong, it will be done wrong,”에 의해 결국은 마감에 쫓기는 코더들은 임시 방편으로 코드를 마구 복사해서 여기저기 템플릿에 붙여서, 다음 개발자가 로직을 고칠때 여기저기 흩어져 있는 것을 일부 고치다가 뻑나서 다같이 망하거나, 디자이너가 디자인 고치다가 로직이 같이 뻑나거나 이런 상황이 올 수 있다고 합니다. 흐흐흐;

그래서, 저자는 템플릿 언어 차원에서의 로직과 템플릿의 강제적인 분리를 이렇게 강조하고 있습니다.

• 캡슐화: 사이트 모양은 완전히 템플릿에 있고, 로직은 모두 데이터 모델 (코드)에 모두 있다. 각각은 완전한 별도의 개체다.

• 명료성: 템플릿은 HTML을 뽑아 내는 프로그램이 아니다. 템플릿은 디자이너와 코더가 바로 읽을 수 있는 HTML 파일일 뿐이다.

• 작업의 분리: 그래픽 디자이너와 코더의 개발은 병렬적으로 일어날 수 있어야 한다. 이렇게 작업이 분리가 되면 코더들이 디자인을 고치기 위해 신경 쓸 필요가 없고, 디자이너와 코더의 커뮤니케이션을 위한 비용이 현저히 줄어든다. 디자이너들은 프로그래머와 얘기하지 않고도 디자인을 마음대로 고칠 수 있다.

• 컴포넌트 재사용: 프로그래머들이 보통 명료성과 재사용성을 높이기 위해 큰 메쏘드를 작은 여러개의 메쏘드로 분리하듯이, 디자이너들도 템플릿을 여러개의 서브 템플릿으로 분리할 수 있다. 즉, 로그인 상태, 네비게이션바, 검색창, 데이터 목록 등등.. 코드가 템플릿에 얽혀있는 경우에는 리팩터링을 통해 분리하기 매우 어렵고, 재활용하기도 어렵다.

• 고칠 곳은 한군데만 (single-point-of-change): 템플릿을 정리함으로써, 디자이너들은 링크 목록, 사용자 기록 뷰같은 여러 개념적인 원소들로 템플릿들을 분리할 수 있다. 이렇게 돼서, 나중에 사이트의 공통적인 한 부분을 고치는 경우 진짜로 한 파일의 한 군데에서만 고치면 되게 된다. 이렇게 하면, 하나를 고치기 위해 여러 부분을 고치다가 뻑나는 경우를 피할 수도 있기 때문에 이것은 아주 중요하다. “관리자인가” 같은 로직은 여러개의 템플릿에서 항상 반복되기 때문에 템플릿 안에 로직을 넣는 것은 절대 피해야 한다.

• 유지보수: 사이트의 모양을 바꾸는 것은 템플릿만 바꿔야지, 절대 프로그램을 바꾸는 작업이어서는 안 된다. 프로그램을 바꾸는 것은 템플릿을 바꾸는 것에 비해 훨씬 위험한 작업이고, 템플릿을 바꾸는 것은 새로운 삶을 시작할 필요도 없다. (즉, 사용되고 있는 서버 애플리케이션을 재컴파일하거나 새로 띄울 필요가 없다.)

• 바꿀 수 있는 뷰: 몽땅 뭉쳐서 쓰는 데이터 모델에서는 디자이너들은 “스킨”이나 “테마”같은 기능을 지원하기 위해서 디자인을 직접 입힐 수가 없다. jGuru.com 사이트에서는 “그룹”이라고 불리는 템플릿 모듬이 있다. “그룹”은 단순히 색깔이나 스타일 시트를 바꾸는 정도가 아니라, 사이트의 전체적인 모양을 바꿀 수 있다. 이렇게 모양이 달라져도 단순히 코드에서는 한 가지 방법으로 데이터를 전달해 주고, 어느 템플릿을 사용할 지 정해주기만 하면 된다.

• 보안: 블로그 사이트들에서는 이제 템플릿을 사용자가 직접 바꿀 수 있는 것이 흔한 것이 되었다. Microsoft Word에서 매크로 쓰는 것처럼 템플릿의 제한되지 않은 기능은 매우 심각한 보안 결함이다. 블로그 템플릿에서 클래스 로더를 띄워버리는 여러 보안 사건이 일어난 이후 squarespace.com은 Velocity와 StringTemplate를 사용하기 시작했다. 가장 쉽게 생각할 수 있는 공격은 무한 루프다. 모델을 뷰에서 완전히 독립하고, 페이지 제어를 금지함으로써 보안성을 얻을 수 있다.

그 외에도 그동안 생각 못했던 여러가지 이유들이 들어있습니다. 웹 프로그래밍에 염증을 느껴보신 분이라면 꼭 한번 읽어보세요. –;