XE 그만두고 하던 워드프레스로 돌아갑니다.

0. 서론

안녕하세요.
최근에 뉴비로 들어와서 제작의뢰 게시판이나 문의게시판에 뻘글 올리던 사람입니다.

결론부터 쓰자면, 이제, 아마도 평생, 적어도 한동안은 XE 안 쳐다볼 것 같습니다.
XE였으면 몇십만원 들여 개발자 구해 실현했어야 할 뷰들이 WP에서는 테마 한 개 사서 혼자 5시간 작업하니까 얼추 나오는 걸 보고 화도 안 나고 그냥 허탈합니다.

그래서 하소연이라도 하려고 포럼 들어와 보니 방금 어떤 분이 "검색중 XE와 워드프레스 관련 글이 있어서 공유"하신 걸 봤습니다.
저는 그 내용과는 좀 안 겹치는 얘기를 해 볼까 합니다.
무슨 프로그램이든 무대포 돌격으로 이것저것 만지면서 적용 위주로 배워 써먹던 한 초짜 개발자가, 그렇게 WP는 공략해 놓고 XE는 그렇게 못하게 된 얘기입니다.
한때는 XE를 어떻게든 잘 활용해 보려고 안간힘을 썼던 한 사람의 주관적인 의견이니 무시하셔도 좋습니다.

1. 레이아웃

음 글쎄... 그 개념 자체가 좀 촌스럽다는 생각이 가장 먼저 들었습니다.
어쨌든 스태틱 파일인 layout.html 하나를 가지고 모든 뷰를 다 만든다(만들 수 있다)라는 개념 말입니다.
무슨 티스토리도 아니고 말이죠.
MVC 프레임워크를 도입하는 것 자체가 '가급적 코드들을 분산 관리한다'의 철학을 채택하는 것을 의미하지 않던가요?
XE는 다른가 보죠? *.class.php 파일은 그토록 많이 필요하지만, 레이아웃은 단 하나의 페이지로 통제되는 것이 best practice인 건가요?
잘 모르겠습니다. 코드이그나이터, 라라벨, 익스프레스, 워드프레스, 제가 아는 어느 MVC CMS도 그렇게 하지 않는데 말이죠. 텍스트큐브 정도라면 모를까. (텍스트큐브는 차라리 블로깅 툴임을 선언하고 있기라도 합니다. 결론부에서 좀더 말하겠습니다.)

그보다 더 심각하게 물어보고 싶은 건 XE템플릿언어라는 것 자체에 대한 의문입니다.
include 태그로 각종 템플릿 파일들을 조각조각 끌어다 쓸 수 있는 걸 보고 처음엔 어이가 없었습니다.
이럴 거면 앗싸리 그냥 다 php로 하지 않고?

생각을 해 봤습니다. XE core 개발팀이 바보는 아닐 테고 여기에는 무슨 깊은 뜻이 있을 것이다.
그게 뭘까...
크게 두 가지를 추측해 봅니다.
1. "php를 모르는 일반인도 자기만의 레이아웃을 만들 수 있도록 도와주자!"
또는,
2. "괜히 코드 꼬여서 에러 나지 않도록 서버가 몽땅 다 컴파일하게 만들어주자!"
그런 배려심에서 나온 것이 layout.html 개념인 것 아닐까, 라고요.

먼저, 진입 장벽의 문제.

글쎄요, php를 모르는 일반인들의 장래를 위해 우리가 택해야 할 방침은 어떤 것일까요?
오직 XE 코어 밑에서만 굴러가는 {$layout_info->header_text} 같은 걸 공부시키는 것일까요,
<?php echo $layout_info->header_text(); ?>처럼 전세계 php 포럼에서 모두 이해하는 표준 코드를 이해시키는 것일까요?
나중에 이 일반인이 ->가 뭘 의미하는지 알고 싶을 때, 그는 이게 php의 지시자라는 것을 짐작이나 할 수 있을까요?
그리고 그가 열심히 배운 XE 템플릿 언어의 규칙들이, 정신없는 개발 여건 변화에 적응이나 할까요?
왜 멀쩡한 코어는 또 업데이트해서 호환성 안 맞게 만드냐고 괜히 열이나 내지 않을까요?

그리고 더 심각하게, 서버 컴파일 원칙의 문제.

좀 과격하게 짧게 물어보겠습니다.
레이아웃 안에서 php 코드가 실행되었다가 에러가 날 수 있다고 합시다. 그래서요? 뭐가 어떻단 말입니까? 뷰 개발자가 에러를 볼 일이 없는 MVC가 과연 best intention인가요?

예전에 온라인 매거진 사이트를 만들어야 할 일이 있어서,
이제 막 include() 함수랑 $_GET 변수 가지고 신기해하던 시절에 다짜고짜 워드프레스 개발을 한 적이 있었습니다.
%s 변수 잘못 썼다가 head 이하 아무것도 출력 안 되는 버그도 겪어 보고 정말 별별 에러케이스를 다 본 것 같습니다.
그러다 보니까 '아... 내가 지금 뭘 하고 있구나'라든가 '음 여기서 이걸 입력하면 높은 확률로 에러가 나겠구나' 같은 감이 옵디다.

XE는 그런 게 전무하더군요.
내가 어디서 뭘 잘못했는지, 이 <block> 안에서 뭐까지 끌어올 수 있는지가 도통 직관되지가 않습니다.
그 에러의 경향이라도 좀 읽어보고, 이 함수 저 변수 시도해 볼 수 있으면 참 좋을 텐데, 그게 어려웠습니다.
그럴 수밖에 없죠. 어쨌든 우리가 보는 건 layout.html이 아니니까요. 그걸 매 request 때마다 일일이 읽어서 빈칸을 채워 제출하는 index.php니까요.

과연 이렇게 php의 현관을 잠그고 XE템플릿의 창문만 열어놓는 것이 향후 발전과 시장 확대로 걸어나가는 최선의 방침인가?
아니라고 생각합니다.
레이아웃에서든 모듈에서든 어디서든, php 기반 웹프레임워크라면 표준 php 코드는 (적정한 권한과 조건이 갖춰질 때) 언제나 굴러야 한다고 생각합니다.
에러가 나든 유니콘이 만들어지든 그건 그 개발자의 잠재력과 의도에 의한 것이어야 하지, XE템플릿이라는 언어에 의해서는 안 된다고 생각합니다.
그런 점에서 XE 레이아웃은 정말 적응하기 어려운, 멀고 낯선 세계였습니다. 분명 php 기반이라고 하는데도요.