XpressEngine 1.11.6을 PHP 8.0으로 마이그레이션

프로젝트의 필요에 의해서 XpressEngine 1.11.6을 PHP 8.0으로 마이그레이션했습니다.

XE 로고
XE 로고

아래의 페이지에서 PHP 8.0에 포팅된 XpressEngine 1.11.6을 살펴보시고 다운로드하실 수 있습니다.

https://github.com/singleview-co-kr/xe-sv-core

1. 싱글뷰가 XE를 계속 사용하는 이유는?

한국인에게 익숙한 UI 구조 때문입니다.

한국의 CMS 관련 논의를 살펴보면 크게 두 가지 흐름인 것 같습니다.

WordPress가 최고! vs. XpressEngine 지원 종료?

*. 확장성과 개발자 커뮤니티, 디자인 자원 기준에서는 WordPress가 절대적으로 우수합니다.

그런데 WordPress는 서양 문화권에서 설계했기 때문에 여러가지 UI 구조가 한국인의 습관과 다소 맞지 않는 문제가 있습니다.

그래서 WordPress로 만든 한국 회사의 홈페이지들은 매우 세련됬지만 활성화되지 않은 경우가 많습니다.

물론 WordPress로 만든 수 많은 개인 블로그들이 매우 활성화되어 있습니다.

*. XpressEngine을 비난할 이유는 WordPress를 칭송할 이유만큼 많아 보입니다.

저희 싱글뷰가 국내 프로젝트를 성공시키기 위해 XpressEngine을 반복하여 선택하는 이유는 네이버라는 한국 회사에서 설계했기 때문에 여러가지 UI 구조가 한국인에 매우 익숙하다는 딱 한 가지 장점 때문입니다.

한국적 게시판 에디터 UX
한국적 게시판 에디터 UX

– 지금은 낡은 감이 있지만 기본에 충실한 XE CK Editor입니다.

네이버가 XpressEngine에 열심히 투자할 때에 네이버 블로그 에디터와 댓글 쓰레드 방식을 XpressEngine과 매우 유사하게 유지했습니다.

한국적 댓글 UX 예시
한국적 댓글 UX 예시

그리고 지금까지도 많은 한국인들이 네이버 앱을 인터넷 브라우저 앱과 구별하지 않습니다.

그래서 네이버가 밑그림을 그려준 XE의 UI 구조는 한국인에게 절대적으로 익숙할 수 밖에 없고 특히, 사이트 방문자와 상호 작용을 최대한 이끌어 내야 하는 프로젝트에서는 저희는 XpressEngine만한 CMS를 아직 찾지 못했습니다.

XpressEngine의 Core 유지 보수도 싱글뷰가 자체적으로 진행할 수 있기 때문에 공식 지원이 종료되었다 해도 큰 문제는 없습니다.

하지만 뭔가 허전하고 서글픈 마음은 가시지 않습니다.

단지, 네이버가 손을 떼서 XE 1.0이 좌초한 것일까요?

2. 싱글뷰가 마이그레이션한 XE core는 PHP 8.0까지만 지원합니다.

PHP 8.1부터는 $GLOBALS라는 특수한 전역 변수를 아예 없애 버렸는데 XE v1이 이 $GLOBALS라는 전역 변수에 매우 심하게 의존하여 작동하기 때문에 XpressEngine이 이 전역 변수를 사용하지 않도록 하는 과정은 처음부터 재설계에 가깝습니다.

PHP8 로고
PHP8 로고

그래서 만약 저희 싱글뷰가 우연히 필요에 의해 XE를 PHP 8 1로 포팅한다면 더 이상 XpressEngine이라고 부르기 어려울 것 같습니다.

그런데 이런 방향의 작업은 네이버로부터 XE를 인수한 업체에서 이미 열심히 진행하는 것으로 보이지만 안타깝게도 그다지 희망적으로 보이지 않습니다.

3. 다른 모듈을 PHP 8.0으로 마이그레이션하는 작업도 어렵지 않습니다.

PHP 8의 요구는 간단합니다.

이해할 수 있고 명시적인 문법을 이제는 지키자는 것 뿐입니다.

PHP 7까지는 지극히 느슨한 문법 체계여서 혼란스럽거나 모호한 코드가 매우 많았습니다.

십수년전에는 사용자가 폭발적으로 증가했지만 이제는 낡고 비효율적인 언어의 상징이 대상이 되었습니다.

저희 싱글뷰가 자주 사용하는 XpressEngine조차도 $GLOBALS라는 모호한 전역 변수에 과도하게 의존하여 많은 복잡한 문제를 간단히 해결했지만 그 만큼 내부 처리가 비효율적이고 동일 실행 환경에서 처리 속도가 매우 느리며 상대적으로 보안에 취약한 부분이 여전히 남아있습니다.

그래서 PHP 7 코드를 PHP 8로 마이그레이션하는 노력은 아래와 같이, 사실은 당연한 상식에 불과합니다.

관료적인 규약이 아니고 지키면 결국 개발자에게 더 좋은 코딩 습관입니다.

  • 클래스의 static 메소드를 명시적으로 사용하자.
  • 변수형은 명시적으로 정의해서 사용하자.
  • create_function()은 이제는 쓰지 말자.

교과서적인 코딩의 표준을 준수했다면 PHP 7 이하에서 작성한 코드도 PHP 8에서 아무런 이상없이 작동하는 경우도 있습니다.

다만, ExpressEngine의 core는 $GLOBALS 변수에 다양한 정보를 기록하여 개발 편의성을 향상시켰습니다. 그런데 PHP 8.1부터 $GLOBALS 변수에 쓰기 금지라서, ExpressEngine을 PHP8.1 이상에서 작동시키려면 core의 $GLOBALS 변수 사용 방식을 바꿔줘야 합니다.

4. XpressEngine은 한국 CMS의 밝은 빛을 제시했습니다.

그런데 안타깝게도 2019년 10월 말에 1.11.6 버전을 발표한 후 사실 상 오픈소프 프로젝트를 종료했습니다.

XpressEngine 운영진의 내부 사정이나 XpressEngine Core의 장단점, 혹은 미래 방향성은 저희 따위가 함부로 논의할 문제가 아니지만 XpressEngine을 버리기에는 왠지 서글픕니다.

일부 Forked CMS는 XpressEngine보다 기술적으로 더 진보했지만 자신들의 근간인 XE 1을 필요 이상으로 비난하며 적대시하고 기존 XE 1 운영진은 유능한 사용자 집단과 대화를 거부하는 것 같습니다.

기술적으로 더 진보한 Forked XE에서는 XpressEngine 1에서 작동하던 다수의 창의적인 모듈과 사이트 레이아웃의 작동을 보장하지 않습니다.

기존 XE 운영진이 버전업한 XE 3는 XE 1과 호환성을 전혀 고려하지 않았고 알아서 마이그레이션하라고 권고합니다.

그 결과, XE 3와 Forked XE 양쪽의 사용자는 모두 다 감소하고 Wix나 아임웹과 같은 임대형 유료 CMS로 이탈한 분위기입니다.

이와 같은 분위기에서 XE 3와 Forked XE에서 모두 개발자와 디자이너 참여도 침체된 것 같습니다.

저희 싱글뷰도 XpressEngine은 PHP 8.0까지만 사용하고 WordPress에서 한국적인 UI를 구현하는 방법을 연구해야 할 때가 곧 올 것 같습니다.

Leave a Comment