Liferay 7 CMS 리뷰

'CMS' Contents Management System

서비스를 운영하다보면 페이지를 추가한다거나 네비게이션바 구조 변경, 게시판 등의 모듈을 추가 혹은 단순한 정적 페이지의 DOM이나 텍스트를 변경하는 일은 정말 너무나도 흔한 일입니다. 그런데 위와 같이 단순한 작업을 할때마다 서비스 배포를 위해서 인건비가 비싼 개발자가 계속 투입되어야한다면?
그건 정말 비효율적인 구조가 아닐 수가 없습니다.
물론 CI/CD를 이용해서 서비스를 간편하게 배포 할 수 있지만 그럼에도 새로 배포한다는 것은 리스크가 동반되는 작업이라는 것은 자명한 일입니다. 만약 무중단 서비스가 구축되어 있지 않다면 서비스를 재배포 하는 순간 서비스가 재시작하여 완전히 로드 될때까지 일시적으로 멈출수도 있습니다. 그런데 매주 웹페이지의 구조가 변경되고 내용들도 계속 바뀐다면 유지보수를 하는 입장에서 정말 문제가 되지 않을 수 없습니다.

이러한 상황에서 CMS는 꽤나 괜찮은 선택일 수 있습니다.
대표적인 CMS로는 '워드프레스', '그누보드' , 'Liferay' 등이 있는데 워드프레스와 그누보드는 PHP기반이며 Liferay는 Java기반입니다.
대중적으로 사용되는 CMS는 모두 PHP 기반인데 그 이유는 PHP가 스크립트 언어인데 비해 Java는 compile이 되어야 하는 언어이기 때문에 속도가 느리고 모듈 단위로 기능을 구현하여 embedded할 수 있게 만드는게 스크립트 언어에 비해 용이하지 않기 때문인것 같습니다.

Liferay에서는 이러한 모듈 단위로 기능을 제공해주는 것을 'Portlet'을 통하여 제공하고 있습니다.
Liferay를 이해하기 위해서는 이 Portlet을 이해하는것이 무엇보다 중요한데 현재 Java의 웹서비스는 일반적으로 Servlet을 기반으로 개발하기에 많은 사람들에게 Portlet은 생소하게 들릴것입니다. '포틀릿'이란 Web Portal에서 pluggable한 플랫폼 독립적인 어플리케이션 인터페이스를 제공하는 컨포넌트입니다.
이렇게 정의를 풀어서 이야기하면 포틀릿이 무엇인지 이해하기 힘들수 있으니 예제를 통해 알아보도록 하겠습니다.

만약 독자가 '게시판' 기능을 포틀릿을 통해 컨포넌트로 만들었다면 그저 포틀릿 컨테이너에 포틀릿을 가져다 놓는 것만으로도 (Drag and Drop) 귀찮은 게시판 기능을 어느 페이지에서든 간단하게 사용할 수 있습니다. 이 말 뜻은 게시판 기능이 포틀릿으로 구현만 되있다면 개발자가 아닌 사람도 누구나 할 수 있다는 말입니다.

이뿐만 아니라 상속 구조의 계층형 사이트를 만들수 있으며 localization도 지원하여
[관리자 페이지 부분의 한국어 지원은 정말 엉망이다. 물론 관리자 페이지 부분은 서비스를 운영하는데 영향을 미치지 않으므로 그냥 영어로 세팅하고 사용하면 된다.]
정적 리소스도 쉽게 올리고 관리할수 있으며 정적 페이지 역시 Web Content라는 이름으로 쉽게 만들수 있습니다.
또한 에디터는 WYSIWYG(what you see is what you get)를 지원하는데 HTML을 모르는 사람도 그럴듯하게 DOM을 구축할 수 있는 것 역시 장점입니다.
물론 디테일하게 뷰를 컨트롤하고 싶다면 HTML을 편집해야하긴 하지만 HTML을 편집하지 않고도 높은 퀄리티의 글을 작성할수 있게 해주는 에디터인 것 같습니다.
그외에도 'Look And Feel'이라는 기능을 이용해서 포틀릿의 CSS를 동적으로 바꿀수 있으며 Javascript 소스도 동적으로 추가할수 있습니다.
CMS의 가장 큰 장점은 서비스를 재배포 할 필요 없이 컨텐츠를 추가 및 수정할 수 있으며 그 작업을 개발자가 아닌 사람이 할 수 있기에 운영의 장벽이 없다는 것입니다.

컨텐츠 관리 측면 외에도 여러 계정을 생성하여 계정별로 포틀릿 관리 등의 기능에 대한 권한을 위임 할수도 있으며 수 많은 리소스들을 쉽게 찾을 수 있도록 Elastic Search 기반의 SEO 기능도 제공하고 있습니다. (관리자 페이지 외에도 사용자 페이지에서도 사용 가능)

CMS나 포틀릿과 같은 모듈 프로그래밍 구조상 불필요한 DOM이 많이 들어가기도 하고 많은 기능을 지원하는 만큼 웹페이지가 느려지는것을 방지하기 위해 Liferay는 SPA(Single Page Application)방식의 컴포넌트 구성으로 웹 페이지가 돌아가며 데이터베이스로부터 데이터를 가져오는것 역시 Redis라는 인메모리 캐시를 지원하여 웹 페이지 속도를 높이고 있습니다.

이렇게만 보면 Liferay는 수많은 대한민국 SI시장에서 반복 작업을 없애줄수 있는 좋은 선택지처럼 보입니다.
하지만 득이 있다면 실도 있는 법이기에, Liferay를 사용해 본 입장에서 해당 프레임워크의 단점들에 대해 알아보도록 하겠습니다.

1. 패키징 메커니즘에 있어서 캡슐화 기능 지원 미약.

이것은 Liferay의 문제가 아닌 기존 Java 시스템의 문제점 중 하나입니다.
Java는 가시성 한정자(visibility modifier [ex: public, private])를 통해 캡슐화를 지원하는데 패키지를 넘어가면 올바른 캡슐화를 지원하지 못합니다.
게시판을 포함한 여러 모듈들은 데이터를 가져오기 위하여 데이터베이스에 접근하는데 Liferay의 포틀릿에서는 DB로부터 데이터를 가져오기 위하여 Service(DAO) 포틀릿을 구현 및 import하여 사용합니다. 이 경우 게시판 포틀릿은 데이터베이스에 접근하는 Service 포틀릿에 의존성이 생기게 됩니다.
또한 이 게시판 포틀릿은 광고 포틀릿 모듈을 embedded 하게 되는 경우가 있는데 이 경우에도 게시판 모듈은 광고 모듈에 대하여 의존성이 생기게 됩니다.
이렇게 포틀릿간 의존성이 얽힐수 있는 구조에서 포틀릿 내부 패키지간 공유를 위한 public 클래스와 메서드들이 불필요하게 다른 포틀릿과도 공유가 되는데 이로 인해 외부에 제공되는 API 뿐만 아니라 내부에서 패키지간 사용되는 API 마저 모두 외부에 공개되어 버려, 개발된 API를 사용하는 개발자에게 혼란을 야기할수 있습니다.
Liferay에서는 gradle을 이용하여 많은 메서드와 API들을 자동 생성하여 제공하는데 이러한 내부에서만 사용되는 메서드나 클래스 역시 include한 포틀릿에서 불필요하게 노출된다는 것은 개발자에게 상당히 불편함을 제공합니다.
이 부분을 해결하기 위해서 Liferay는 JDK 9에 포함 된 Jigsaw Project를 서둘러 도입해야한다 생각합니다.

2. IDE 지원 미약.

개발자에게 자신에게 편리한 IDE를 선택할 수 있는 선택지가 있다는 것은 매우 중요한데 현재 Liferay(7버전)는 IntelliJ 기반의 IDE를 지원하지 않으며 오로지 Eclipse기반의 IDE만 지원됩니다. 30일 무료로 제공되는 Liferay Studio가 있지만 이는 유료이며 Eclipse에서 Plugin을 설치해 세팅한 것과 차이가 없기 때문에 큰 의미가 없습니다.
필자의 경우 이클립스의 메모리를 충분히 늘렸음에도 자꾸 이클립스가 터져버리곤 하였는데 소스가 자동 저장되지 않는 이클립스에서 한창 작업하다가 터져버리면 굉장히 스트레스를 받곤 하였습니다. 이 부분은 Auto Deploy를 해제함으로써 어느정도 해결이 가능하였지만 그럼에도 완전한 해결책이 되지는 않았습니다.

3. 무거운 프레임워크.

CMS 특징상 많은 기능 지원으로 인해 프레임워크 자체가 정말 무거우며 서비스를 run하면 굉장히 오랜 시간이 걸립니다.
Liferay는 각 포틀릿이 모듈처럼 돌아가야 하기 때문에 Spring과 같이 컨포넌트를 싱글톤으로 관리하며 DI하는데 용이하지 않으며 이는 불필요한 컨포넌트들이 중복되게 구현될 수 있음을 야기합니다. 이는 IoC와 DI의 특징을 가지고 있는 Spring에 비해 더 많은 메모리와 자원을 소모하게 만듭니다.

4. 적은 사용자.

우선 필자가 Liferay를 사용하게 되었을 때 Liferay에 대해 구글링 하였을때 한국어 자료는 6버전이 마지막이었습니다.
Liferay 6과 7은 상당 부분 변경이 되었기 때문에 버전의 중요성이 큰데 한번도 7버전에 대한 자료를 찾은 적이 없었으며 영어로 검색하여도 문제 해결에 대한 자료가 많지 않았습니다. 스프링과 비교하였을 때는 자료의 양이 거의 전무한 정도라 하여도 무방할 정도이며 왜 다른 사람들이 많이 쓰는 프레임워크를 쓰라고 하는지 깨달을 수 있는 계기 였습니다. 명백한것은 인프라 자체가 다릅니다. (참고: Liferay 슬랙 채널이 하나 있긴 하지만 이 역시 활발한 느낌을 받을수 없습니다.)

5. 마켓 활성화가 되어 있지 않음.

Liferay에는 마켓이 있는데 이것은 워드프레스에서 템플릿을 주고 파는 것처럼 포틀릿을 사용자간에 오픈소스로 공개하거나 비용을 받고 파는 시장입니다.
만약 이 마켓이 활성화가 되어 포틀릿이 많이 공개 되어 있다면 개발을 하지도 않고 많은 기능을 가져다 쓸수 있어 메리트가 있으나 현재는 거의 활성화가 전혀 되있지 않습니다.

6. AOP 기능 부재와 Annotation 기능 미약.

스프링으로 개발 하다가 Liferay로 개발을 하게 되면 AOP와 다양한 Annotation의 부재로 인하여 중복 코드가 굉장히 많이 발생하게 되고 적지 않아도 될 코드들을 일일이 적어야 하는 불상사가 발생하게 되어 개발자에게 있어서 굉장히 많은 시간을 뺏어갑니다.

결론

프레임워크가 조금 더 가벼워지고 다양한 IDE 지원 및 개발 생산성을 높일 수 있는 기능이 지원된다면 사람들이 좀 더 유입될수 있는 계기가 되지 않을까 싶습니다.
사용자가 더 많이 유입된다면 마켓 역시 더 활성화가 되고, 이는 선순환으로 이루어질수도 있을것이라 생각합니다.

혹시 Liferay CMS를 도입하기 위해 이 글을 참고하게 된다면 제가 드릴 조언은 다음과 같습니다.

컨텐츠가 수시로 변경되는 서비스를 운영해야한다면 CMS는 좋은 선택지입니다. 하지만 개발자에게 언어는 그저 도구일 뿐 목표가 아니듯이 꼭 JAVA를 사용할 필요는 없습니다. 다양한 인프라가 구축되어 있는 PHP도 좋은 선택지일 수 있습니다.

사내에 새로운 프레임워크를 도입한다는 것은 기존의 프레임워크를 이용하여 개발하는것보다 비용이 더 발생되는 것이며 Liferay를 이용하여 개발하게 되면 초기 투자 비용이 다른 프레임워크보다 서비스 대비 더 발생되는 측면이 있습니다. (포틀릿을 전부 모듈로 만들어야 하기 때문에)
여러 프로젝트를 진행해야 하는 SI회사의 경우 Liferay에 대한 노하우가 생기고 개발된 포틀릿도 쌓이게 된다면 이상적으로 적은 비용으로 높은 퀄리티의 웹페이지를 찍어낼지도 모릅니다. 다만 그것은 이상일뿐 그게 옳은 방향이라고 할수 있을지는 모르겠습니다.

꾸준히 자기 개발하고 성장해야하는 개발자에게는 많은 제약이 발생되는 CMS라는 것이 독약이 될수도 있다고 생각합니다.