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 기반이라고 하는데도요.
2. XMLQuery
제가 보알못(보안은 알지도 못하는넘)이라서 죄송합니다. 그냥 무식이 배짱이라고 갈 때 가더라도 할 말은 하고 가겠습니다.
이게 도대체 뭔가요???
너무 궁금해서 여기저기 찾아봤습니다.
사실 내가 모르는 것일 뿐 이것도 엄연한 쿼리 질의 표준 방식이었던 것은 아닐까... 하고요.
적어도, 각종 조건절이 담겨 있는 .xml 파일을 가지고 통신하는 규약이, 대세가 아님은 분명해 보입니다.
개발 중인 웹서비스에서, 전체 게시물 중 특정 태그를 가진 글들을 뽑아오고 싶었습니다.
XE에서는 xml파일과 콘텐츠위젯 코드 수정 작업 의뢰를 해야 구현되는 것이었습니다.
전문가님이 열심히 개발해 주신 코드를 위로 읽고 아래로 읽어봤지만 그 로직이 이해가 되지 않았습니다.
워드프레스에서는, 다들 아시겠지만, 두 줄이면 됩니다.
$args = array('tag' => 'foobar', 'showposts'=>5, 'caller_get_posts'=>1);
$my_query = new WP_Query($args);
물론 '태그는 XE에서 잘 안 쓰는 것이다' 등의 반론이 있을 수 있겠습니다.
그럼 또 물어보고 싶습니다. 태그든 뭐든, 왜 .xml 파일 없이는 아무 질의도 하지 못하는 거죠?
1. 다양한 DB 호환의 문제
xml쿼리 규약을 채택한 이유가 "다양한 DB에 호환되게 하기 위해서"라고 들었습니다.
그런데 솔직히 까놓고 얘기해서, php 굴리는 한국 리눅스 웹서버가 몽고DB를 씁니까, NoSQL을 씁니까? 그냥 phpMyAdmin 깔아서 쓰잖아요.
그리고 막말로, 앞으로 제가 살면서 DB를 바꾸면 얼마나 바꾸겠습니까?
서버가 어떤 종류의 DB를 채택했는지는 CMS가 알아서 기억해 뒀다가, 그 설정값 따라서 XEquery() 따위의 함수가 자동 동작하게 만드는 것만으로는 부족한가요?
아닌 게 아니라 Cubrid, mysqli, innodb 등등에 대한 .class.php가 각각 다 있더군요.
왜 이 파일들이 한번 일하고 XML이 한 번 더 일하는 건가요? 그런데 왜 다른 CMS들은 제게 이런 걸 시킨 적이 없는 거죠?
그렇게 생각해 보면 이건 정말 과한 표준규격이라는 생각이 듭니다. 거의 XE를 쓰지 못하게 하는 규제에 가깝습니다.
제가 그 마크업을 배우는 데 들어가는 시간에 비해 앞으로의 활용성이 너무 떨어집니다. (그래서 안 배울 생각입니다.)
2. 보안의 문제
잘 몰랐는데, xml 쿼리 방식 덕분에 XE이 보안이 "철옹성"임을 알게 되었습니다.
그런데요, 대한민국 개발자의 절대다수에 속할 제 입장에서는, 현재 XE의 DB 통신 규약은 구더기 무서워 장 못 담그는 꼴입니다.
모 콘텐츠 위젯의 /queries 폴더 목록입니다.
getCategories.xml
getDocument.xml
getMids.xml
getNewestCommentList.xml
getNewestDocuments.xml
getNotices.xml
이게 비합리, 비효율, 반직관, 불편, 시대착오로 보이는 건 저뿐입니까? 진지하게 궁금합니다.
보안이 중요하지 않다는 게 아닙니다.
하지만 그 보안 지키느라 써야 할 열쇠가 너무 많아지면, 보안이 문제가 아니라 사람 출입이 끊기게 되는 겁니다.
보안이 정 필요하면 암호화를 하든 접근 차단을 하든 다른 방식을 강구할 일이지, 쿼리 인젝션 막아보자고 DB에 뭐 물어볼 거 있을 때마다 기나긴 통행증을 작성해야 하는 이런 체계는... 무슨 전자정부 홈택스도 아니고 말이죠...
3. 위젯
서버가 컴파일하는 layout.html과는 또 다른 의미에서 이거 아주 골때리는 놈이더군요.
결론부터 쓰자면, <img class="zbxe_widget_output" widget="myWidget" start="3" end="9"> 따위 어쭙잖은 유사 html 태그가 아니라 그냥 <?php myWidget(3,9); ?> 코드로 가야 합니다. 지금도 <img>태그라는 위젯 형태는 대관절 아무 존재 의미가 없으니까요.
왜 존재의미가 없느냐? 간단합니다.
쉽고 편한 기능을 만들어준다는 소스가 비직관적이고 자의적이기 짝이 없습니다.
차라리 php 클래스나 함수를 다루는 코드라면 원리 공부를 하든 소스를 뜯어고쳐서 써먹든 하기라도 하지.
초보자를 위한 XE 강좌 목록에 빠지지 않고 나오는 게 '위젯 코드 생성하기'입니다.
모두 초보자 입장에서 엄청나게 허탈한 결론으로 끝납니다. "생성된 img 태그를 모두 복사해 붙여넣으세요."
어떤 기분이냐면, 과자 공장 견학 가서 과자 굽는 기계 속을 못 보고 나오는 기분입니다.
어떤 마법이 있어서 이 꼬부랑 외국어를 위젯으로 샤라락 변신시켜 주는 것일 뿐이라면, 이런 코드 체계는 없는 게 낫습니다.
그 마법을 할 줄 아는 사람들은 더더욱 전업 전문가로만 나서게 되고, 그 마법을 간파하지 못한 사람들은 점점 일반 의뢰자로만 전락할 뿐이기 때문이죠.
과자 굽는 기계 뭐 별거 있겠습니까? 초대형 오븐이겠지요. 가정용 오븐을 사면 집에서 간단한 쿠키 정도는 누구나 구울 수 있게 됩니다. 하지만 이런 식으로 과자 굽는 기계 자체를 자의적이고 신비하고 난해한 것으로 만들어 놓으니, 가정용 오븐을 사거나 만들거나 할 일이 영 없어지는 게 지금 XE 마켓 상황이고 위젯 개발 업계라고 생각됩니다. 묻고 싶습니다. 이게 XE 개발 생태계 확장에 도움이 되는 거냐고요.
뭐, 공장을 건설할 재력과 지력이 있는 사람들에게는 도움이 될 겁니다. 과자 굽는 기계 제작을 자연 독점하게 될 테니까요.
모든 프로젝트가 기트헙에 올린다고 소셜 코딩이 되는 건 아닙니다.
애당초 이렇게 꽉 막힌 체계에서 제가 뭘 더 개선할 게 있다고 브랜치 풀 리퀘스트를 넣겠습니까?
앞으로도 이런 식일 거라면 XE의 소셜코딩은 그저 꿈이기만 할 겁니다.
4. 내부 설계 및 개발자 편의
이쯤 되니 화가 나더군요.
DB 테이블이든 내장함수든 그냥 내가 처음부터 다 뜯어보고 하나부터 열까지 새로 쓰는 게 낫겠다 싶어졌습니다.
그리고 XE는 심지어 그렇게도 못 하는 상황입니다.
1. 가끔 보이는 황당한 내부 코드
document 모듈 아래 document.item.php 에 이런 함수가 정의돼 있습니다.
function getRegdateTime() {
$regdate = $this->get('regdate');
$year = substr($regdate,0,4);
$month = substr($regdate,4,2);
$day = substr($regdate,6,2);
$hour = substr($regdate,8,2);
$min = substr($regdate,10,2);
$sec = substr($regdate,12,2);
return mktime($hour,$min,$sec,$month,$day,$year);
}
이렇게 용감하게 전제조건을 많이 깔고 있는 공식 배포 코드는 처음 봅니다. $regdate는 14자리 숫자로 이루어진 string이며, 그것은 항상 첫 네 숫자가 년도를, 다음 두 숫자가 월을, 다음 두 숫자가 일을... 마지막 두 숫자가 초를 지시하리라는 굳건한 믿음이 없으면, 저 같은 사람이라도, 이런 걸 작성할 배짱은 없을 듯합니다.
그래서 DB는 굉장히 체계적인가 보다, 하고 들어가서 보니 xe_layout 테이블에 이런 게 보입니다.
`extra_vars`, `text`, `O:8:"stdClass":4:{ s:3:"GNB";i:64;s:11:"LAYOUT_TYPE";s:9:"MAIN_PAGE"; s:10:"VISUAL_USE";s:3:"YES"; s:14:"menu_name_list";a:1:{i:64;s:12:"Welcome menu";}}`
음... 그러니까 지금 이건 레이아웃 설정값 일체를 object 하나로 묶어서 string 처리해 넣어놓은 것인데...
혹시 게시물 하나하나마다 태그도 이런 식으로 배열 내지 객체로 달아놓는 걸까 그래서 전체검색이 어려운 걸까 하고 찾아보니...
...이쯤 되면 xe_ 붙은 모든 DB 테이블에 대한 의심이 막 생기는 겁니다. 어느 테이블 어느 열을 뒤져야 내가 원하는 게 있을까가 오리무중인 것입니다...
2. 몹시 미비한 documentation
그러지 말고 차분하게 뭐라도 배워 보자, 하고 여기 포럼의 Learn, 개발자 가이드, API 모두 눌러 봤습니다.
개발자 가이드 쪽에 pdf 링크가 있길래 덥석 눌렀습니다. 35페이지에 이런 안내가 있습니다.
위젯은 관리자가 수동으로 페이지 모듈에 입력하고 <img/> 요소에 저장합니다. 출력할 웹 페이지를
호출할 때 widgetController::triggerWidgetCompile() 트리거가 widgetproc()를 사용해서 <img/> 요소의
코드를 실행하고 올바른 HTML 코드로 변환합니다.
...제가 궁금한 건 "밀가루와 초코칩이 과자 굽는 기계로 들어가면 전력을 동력과 화력으로 바꿈으로 인해 제품이 생산됩니다." 같은 게 아닙니다.
어떻게 밀가루와 초코칩을 섞어서 어떤 온도로 뭘 하면 그게 "구워지는" 건지 그 과정을 좀 설명해 달라는 것이지요.
전문가 분들께는 우스워 보일지 모르지만 저 같은 초보자들에게는 절실한 문제입니다.
어디 있는지도 모르겠는 widgetproc() 함수 따위 아무래도 좋단 말이다 그러니...!
아니지 잠깐만, API 메뉴를 보니 XE 내장함수나 설계에 관해서 굉장히 자세하게 documentation을 해놨던 모양이던데 그걸 읽어볼까?
하고 검색을 해봅니다. 이런 곳에서 함수명을 검색하면 당연히 함수 관련 정보가 뜨리라고 기대합니다. codex이길 기대하는 것이지요.
음... 제가 너무 많은 것을 기대한 걸까요...
그리고 다시 돌아와서 Learn을 들어가 보면, 여전히 혼자 진도를 무섭게 나가고 기말고사를 보자는 노교수의 수업을 듣는 1학년 학부생의 기분이 됩니다.
기초를 알아야 겨우 그 진가를 조금 알 수 있는 수업을, 기초만 빼놓고 듣고 있는 기분 말이죠.
네, 이리하여 저는 XE와의 씨름에서 장렬하게 패했습니다.
5. 결론
저는 워드프레스 예찬론자가 아닙니다.
사실 php라는 언어 자체를 마지못해 하는 편입니다. 할 수만 있다면 당장이라도 node.js가 굴러가는 헤로쿠나 AWS로 탈출하고 싶은 심정입니다. (배워 보니, 특히 parse.com처럼 여러 API를 차분하게 잘 만들어 놓은 baas의 경우에는 정말 거의 노력이 필요가 없더군요. 이해가 필요할 뿐이지. 그리고 그 이해의 방편도 여기저기 준비가 돼 있었고요.)
XE는, 그 언어가, DB 설계가, 개발 철학이 전혀 '아니올시다'였습니다.
가뜩이나 미래 없는 php의 앞날을 더욱 어둡게 만들고 있다는 생각이 드는 것입니다.
처음에는 길길이 날뛰며 화를 내려고 했습니다. 그래도 국내 최고 최초의 CMS라는데 믿고 써 봐야지 싶어서 그 긴 시간 노력 투자한 결과가 결국 원점이니까요.
일은 일대로 마감이 닥치고 있고 저는 반쯤 미쳐서 이런 장문의 뻘글을 쌔우고 있고...
근데 이제는 별로 화는 나지 않습니다. 그냥 제가 현재까지의 XE를 오해하고 있었습니다.
XE는 콘텐츠 매니징 솔루션이 아니고 그냥 BBS입니다.
그렇게 이해하니 속이 편하더군요.
일단 설계 자체가 단위콘텐츠 개념이 아니라 글 개념이더군요.
그러니 이를테면 여러 게시판에 퍼져 있는 글들을 하나의 태그, 작성자 따위로 모아볼 필요가 없지요.
게시판은 다 용도가 있고, 거기서 회원들이 용도에 맞게 잘 활동하면 포인트(←XE를 선택했던 결정적 이유 1) 올려서 높은 레벨의 회원(←XE를 선택했던 결정적 이유 2)으로 만들어주면 될 뿐이니까요.
그러다가 가끔 뭐 팔아야 할 일이 생기면 "프리미엄" 게시판 하나 만들어서 결제(←XE를 선택했던 결정적 이유 3) 받고 장사하면 되니까요.
그래요, XE를 가장 잘 활용하고 있는 일간베스트닷컴이 그렇게 하듯이 말입니다.
사용자는 오직 글과 코멘트를 읽고 쓸 뿐이고,
그 글들은 오직 게시판의 형태로만 활용되며,
관리자는 오직 그들의 게시판 활동만을 지원하는
그런 로직의 웹 서비스가 필요하다면,
XE를 따라올 CMS는 없습니다.
하지만 그 이상 아주 약간 다른 '일관된 키-값 쌍을 가지는 데이터들'을 다루는 CMS이기만 해도,
XE는 속수무책인 것 같습니다.
정말 꼭 필요한 기능과 DB테이블만 마련해서 독립 MVC로 만드는 게 가장 올바르고 적절한 방식이지만 그렇게 할 수 없을 때,
워드프레스는 그나마 도움이 되고,
XE는 제게 실망만을 안겨 주었습니다.
글 개념에서 약간만 벗어나더라도,
XE는 굉장히 많은 코딩과 규칙 준수를 요구합니다.
그러다 보니,
그런 건 네이버 지식인에 치면 나오는 정보가 아니게 되고(스택오버플로는 말할 것도 없지요),
재능마켓에서 쉽게 거래되는 능력도 아니게 되며,
유감스럽게도,
XpressEngine 서포트 메뉴, 바로 여기서만 유통되는
우물 안 개구리 실력이 되고 말았습니다.
적어도 제게는 그렇게 보입니다.
다시 일하러 가겠습니다.
가는 마당에 훈계조가 너무 길었습니다.
하지만 훈계는 아닙니다. 제가 무슨 주제라고 훈계를 합니까.
그냥 전 이런 이유로 XE를 그만둔다고 어딘가에 적어 두고 싶었습니다.
저 같은 사람이 적지 않을 것이라고 생각하므로.
PS.
11월에 XE3을 발표하는 컨퍼런스가 있는 모양이군요.
그런데 만약 그때도 여전히 XE템플릿 언어가 건재하고, XML 쿼리가 포기되지 않은 그대로라면,
그걸 본 제가 그 귀한 자리에서 어떤 깽판을 칠지는 저도 잘 모르겠으니,
전 그냥 안 가겠습니다.
0. 서론 안녕하세요. 최근에 뉴비로 들어와서 제작의뢰 게시판이나 문의게시판에 뻘글 올리던 사람입니다. 결론부터 쓰자면, 이제, 아마도 평생, 적어도 한동안은 XE 안 쳐다볼 것 같습니다. XE였으면 몇십만원 들여 개발자 구해 실현했어야 할 뷰들이 WP에서는 테마 한 개 사서 혼자 5시간 작업하니까 얼추 나오는 걸 보고 화도 안 나고 그냥 허탈합니다. 그래서 하소연이라도 ...
