이번 포스트에서는 만들고자 하는 플러그인 엔진에 대한 개략적인 컨셉을 적고자 합니다.

워드프레스 플러그인 제작을 시작한 것은 2014년입니다. 그동안 몇몇 플러그인을 제작하였고, 몇 번의 플러그인 강의를 한 적이 있습니다. 몇 번의 플러그인 개발을 해 보며 느낀 것이 있습니다. 워드프레스는 훌륭한 CMS이지만, 훌륭한 웹 프레임워크는 아닌 것 같다는 겁니다. 다른 웹 프레임워크와 비교하면 솔직히 좀 아쉬운 것들이 많은 것이 사실이죠.

사실 워드프레스를 위한 개발 프레임워크들이 여럿 있지만, 저는 그냥 제 플러그인 엔진을 만들기로 결심했습니다. 네, 바퀴를 재발명하는 것 같은 어리석은 일일 수도 있겠습니다. 사실 거창한 이유는 아닙니다. 워드프레스 플러그인 개발자로 지내며 제 나름대로 고민한 것을 정리하고 싶었고, 제가 저의 결과물을 얼마만큼 체계적으로 정리할 수 있는지 궁금했습니다.

프레임워크 비슷한 것을 만드는 것은 사실 처음이 아닙니다. 아마 아무도 모르시겠지만 “Axis”라는 프레임워크라는 이름을 붙이기도 민망한 것을 만들고 처참히 실패가 적이 있었습니다. 지금도 마찬가지입니다. 제가 무슨 깊은 경험이 있어서 프레임워크를 운운하겠습니까. 그저 해보면서 성장하기를 바라는 것이겠죠. 여전히 민망하고 또 어려움을 느낍니다.

실무에서 배움

현재 워드프레스 개발자로 지내고 있으며, 실무를 접하며 겪게 되는 문제들은 상당히 흥미롭습니다.  어떤 일들은 지엽적이지만, 때때로 클라이언트들은 지금껏 접해보지 못한 상황을 문제로 가져옵니다. 저는 제가 흥미로운 다양한 경험을 해 볼 수 있는, 나름대로 좋은 환경에 있다고 생각합니다.  그리고 이런 문제들은 제가 상상할 수 있는 가장 우아한 방법으로 해결하고 싶습니다.

물론 당장 그런 최상의 결과를 내는 것은 매우 어려운 일입니다. 그런 좋은 코드는 거저 만들어지는 것이 아닙니다. 꾸준히, 정말 꾸준히 여러 이슈를 거쳐 제련되어야 합니다.

불행히도 클라이언트들을 위해 만드는 소위 ‘남을 위해 짜는 코드’들은 그렇게 지속적인 관심을 쏟기 어렵습니다. 빠른 시간에 만들어야 하고, 또 한 번 데드라인에 맞춰 완성된 결과는 적절히 유지보수하는 것 말고는 지속적으로 업데이트하여 쓰기가 어렵습니다. 클라이언트에게 최상의 코드를 제공해 드리지 못하는 점 죄송하게 생각합니다. 그러나 저도 사람인지라, 만들고 나서야 결과를 아니까요. 사람의 최선에는 늘 한계가 있더군요.

엔진은 우선 저희 경험을 최대한 완성도 있게, 재활용될 수 있도록 레거시 코드를 정돈한다는 느낌으로 작성할 것입니다. 자주 반복되는 요소들은 그 다음에는 더욱 효율적인 방법으로, 간결하게, 이전보다 더욱 잘 작성될 것이라는 희망을 가지고 코드를 작성합니다.

MTIV 패턴의 도입

‘MTIV’는 제가 생각한 플러그인을 위한 MVC류의 개발 패턴입니다.

저는 Axis라는 구작을 만들 때부터 워드프레스 플러그인에 최대한 MVC 패턴을 도입하려고 애를 썼습니다. 솔직히 지금도 MVC의 정수를 이해하지는 못한다고 생각하며, 타 프로그래머에 비해 오히려 많이 부족하다고 생각합니다. 그럼에도 불구하고 이것을 고집하는 이유는, 이것이 더 나은 방법이라고 생각하기 때문입니다.

개발을 하면서 코드를 이렇게 되도록 노력하고 있습니다. “처음에는 힘들고 귀찮지만, 한 번 짜 둔 코드는 유지보수하기 극도로 쉽게.”

확실히 MVC 류의 프로그래밍 패턴이 뛰어난 유연성을 가지고 있고, 유지보수하기 좋은 구조를 가지고 있습니다. 많은 웹 프레임워크들도 MVC, 또는 이에서 파생된 패턴을 사용하고 있습니다.

그런데 이 MVC를 바로 워드프레스 플러그인이나 테마 개발에 사용하려고 하면, 그다지 쉽지 않을 것입니다. 적어도 저는 그랬습니다. 이 부분은 저의 개발 엔진에 있어 가장 중요한 부분이기 때문에, 몇 가지 이유를 들어 그 이유를 자세히 설명해 보고자 합니다.

우선 워드프레스 코어 자체가 이런 패턴을 직접적으로 사용하지 않기 때문에,  좋은 코드 교범을 보기가 힘듭니다.

그리고 다른 웹 프레임워크와는 다른 워드프레스의 특성에서도 기인한다고 생각합니다. 다른 웹 프레임워크들은 사용자가 전달한 request 부터 서버가 도로 보낼 response까지의 작업을 온전히 개발자에게 맡깁니다. 웹 프레임워크들은 그 작업을 보다 편리하게 지원해주는 역할을 맡았죠. 설계도와 지휘봉은 모두 개발자에게 있습니다.

그러나 워드프레스는 그렇지 않습니다. 이미 코어가 request를 받아 response를 대부분 처리하는 상태입니다. 플러그인, 테마 개발자는 코어에 이미 코어 개발자가 만들어 둔 고리, 훅(hook)에 자신의 콜백을 등록하는 방법으로, 즉 이미 완성된 코어를 확장하는 방법으로 개발을 진행합니다. 이것이 워드프레스식 웹 개발입니다.

통상적인 웹 프레임워크들의 동작

여기서의 예는 조금 복잡하니, 어려운 분들은 뛰어넘어도 됩니다.

보통 웹 프레임워크는 URL 라우팅 규칙을 설정하고, 그 라우팅 규칙에 따라 하나의  request를 하나의 함수로 대응하는 구조로 되어 있습니다.

여기서 제가 자주 사용하던 웹 프레임워크인 Django를 예를 들면, 장고는 MVC의 변종인 MTV 패턴을 사용합니다. Django의 URL 라우팅은 주로 각 앱의 urls.py 라는 파일에서 정합니다. 아래 코드는 그 예입니다.

from django.conf.urls import url

from . import views

urlpatterns = [
    url(r'^$', views.index, name='index'),
]

어떤 도메인의 ‘/’ 경로로 접근한 request는 views.index라는 View 함수가 처리를 합니다.

from django.http import HttpResponse

from .models import Question


def index(request):
    latest_question_list = Question.objects.order_by('-pub_date')[:5]
    output = ', '.join([q.question_text for q in latest_question_list])
    return HttpResponse(output)

index라는 View 쪽 함수 예입니다. 모델을 불러와 request가 원하는 방식으로 자료를 가공하여 response를 만들어내는 것입니다.

워드프레스 코어의 동작

워드프레스의 주 진입점은 워드프레스 디렉토리 최상위의 index.php와 wp-admin 디렉토리의 index.php, edit.php, post.php 등등이 있습니다. 일반적인 프론트 화면의 진입점인 최상위의 index.php를 보면 wp-blog-header.php 파일을 읽어들이는 코드가 있습니다.

wp-blog-header.php 에서 WP 클래스의 main() 메소드가 실행됩니다. 이 메인 메소드는 아래처럼 되어 있습니다.

public function main($query_args = '') {
    $this->init();
    $this->parse_request($query_args);
    $this->send_headers();
    $this->query_posts();
    $this->handle_404();
    $this->register_globals();

    /**
     * Fires once the WordPress environment has been set up.
     *
     * @since 2.1.0
     *
     * @param WP &$this Current WordPress environment instance (passed by reference).
     */
    do_action_ref_array( 'wp', array( &$this ) );
  }

 사용자의 request를 받아서 일괄적으로 처리하는 구조입니다. 여기서 우리가 코드를 함부로 변경할 수 없는 대신 action, filter를 사용하여 코어의 동작을 살짝살짝 변경시킵니다.

MTIV의 I (initiator, 전수자)

장고의 MTV라는 컨셉이 플러그인 개발에는 더 적절하다고 생각했습니다. M은 모델(Model)입니다. 데이터를 다루는 영역입니다. T는 템플릿(template)을 의미합니다. 화면을 어떻게 보여줄 지를 결정하는 시각적인 영역입니다. V는 뷰(View)로서 request를 받아 reponse를 생성하는 역할을 맡습니다. 뷰는 모델과 템플릿사이에 위치하며, 모델이 전하는 자료를 요청에 맞게 처리 가공하여 템플릿에게 넘겨주는 역할을 합니다. 템플릿은 뷰가 전해준 자료를 바탕으로 HTML 문서 등을 결과로 찍어냅니다.

물론 MTV 같은 패턴을 워드프레스에 도입할 수 없는 것은 아니지만, 그것이 약간은 껄끄럽습니다. 앞서 이야기하였듯 워드프레스는 타 웹프레임워크처럼 request 부터 자연스럽게 로직을 처리하는 구조가 아니기 때문이라고 생각합니다.

워드프레스 플러그인은 그 특성이 있습니다. 계속 이야기하였듯, 훅과 콜백입니다. 통상의 웹 개발자는 request에 초점을 맞추고 request에 맞춰 response를 작성하는데 온 힘을 기울인다면, 플러그인 개발자들은 코어에서 제공하는 (혹은 타 플러그인이 정의한) 훅에 관심을 두고, 원하는 기능을 작성하기 위해 적절한 훅을 탐색하고, 그 훅에 맞춰 적절한 콜백을 작성하는 데 노력을 기울입니다.

저는 Axis 때무터 이 훅과 콜백에 천착해 왔습니다. 이 훅과 콜백의 특성상 기존의 MVC나 MTV들을 여타 웹 프레임워크 처럼 플러그인에 쓰기 쉽지 않다고 생각하였습니다. 그 대안이 “MTIV“입니다. ‘I’가 하나 추가된 것이죠. 저는 이 ‘I’를 전수자, 또는 이니시에이터(initiator)라고 부릅니다. 

전수자의 가장 기본적인 역할은 콜백을 문맥에 맞게 정리하는 것입니다. 그리고 전수자가 잘 정돈한 콜백 함수에서 비로소 MTV의 패턴 도입이 이루어집니다.

보통 어떤 구성 요소(component)들은 적어도 하나 이상의 액션, 필터를 조합하여 이뤄집니다. 그런데 이 액션과 필터들은 “어떤 상황에 대한 대응”을 설정하는 것이지 그 자체로 어떠한 구성 요소를 설명하는 것이 아니라, 차후 유지보수시 기능 분석이 약간 힘든 측면이 있습니다.

예를 들어

add_action( 'a_action', 'my_a_action_callback');
function my_a_action_callback () {
...
}

add_action( 'b_action', 'my_b_action_callback');
function my_b_action_callback () {
...
}

add_action( 'c_action', 'my_c_action_callback');
function my_c_action_callback () {
...
}

...

 이런 식으로 평면적인 액션 선언 및 콜백 함수로만 코드를 짜게 된다고 생각해 보세요. 또 구성 요소에 쓰이는 훅들이 겹치지 않으리란 보장이 있나요? 어떤 훅이 어떨 때 쓰이는지 쉽게 추적이 가능할까요?

전수자는 이런 문제를 해결하기 위해 생각해 내었습니다. 한 구성 요소에 필요한 훅과 콜백을 의미 있게 하나의 클래스로 묶어 관리합니다. 훅, 콜백 선언이 한 클래스에 의미 있게 관리되므로 코드 유지보수에 더욱 편리합니다.

물론 전수자를 쓰는 것도, 또 전수자의 콜백에서 MTV를 사용해야 하는 것은 강제 사항이 아닙니다. 예를 들어 워드프레스에서 메일을 보낼 때 본문에 html 코드를 삽입하고 싶다면 아래 같은 코드를 쓰는데, 아무리 봐도 이런 콜백 때문에 뷰를 쓰는 건 닭 잡는 칼에 소 잡는 칼 쓰는 격입니다.

add_filter( 'wp_mail_content_type', 'set_content_type' );
function set_content_type( $content_type ) {
  return 'text/html';
}

이럴 때는 그냥 전수자 콜백에서 그냥 처리해도 무방합니다.

또 이미 많은 사람들이 저와 같이 생각을 하고 있고 비슷하게 의미 있는 훅과 콜백을 클래스로 묶거나 적절히 모듈화 하는 것으로 알고 있습니다. 그것과 전수자는 거의 동일합니다. 그러나 제가 생각하는 전수자 개념의 핵심은 “모듈화”만을 위한 것이 아닙니다. 워드프레스 플러그인 구조에서 원할 때 제대로 MTV를 사용할 수 있도록 길을 연다는 점, 이것이 중요합니다.

제 경험에 미루어 보면 MTV 패턴은 플러그인 개발자가 원한다면 어떻게든 구현하여 사용할 수 있는 부분인 것 같더군요. 그러나 구현을 하게 되면 도대체 어디에서부터 뷰를 생성하고 그 로직을 전개할지 난감해질 때가 있었습니다. 모든 콜백에 대해 ‘뷰’라는 패턴을 가진 객체를 생성해야만 할까요?  애초에 훅, 콜백과 뷰는 잘 어울릴 수 있는 구조인걸까요? 설령 가능하다면 어떻게 뷰를 정돈된 형태로 유지할 수 있을까요?

다행히 MTIV 구조에서는 전수자가 가장 먼저 기능별로 훅과 콜백을 정리해 두고 있습니다. 그 콜백을 처리하는 것이 뷰이기 때문에, 자연스럽게 뷰의 생김새도 전수자의 파일 구성을 따라 갑니다. 그래서 기능별로 만들어진 전수자 파일 구조 및 코드를 따라가면 자연스럽게 해당 심화 로직인 뷰 코드를 추적할 수 있습니다. 코드의 흐름을 쫓아가기 매우 쉬우며, 따라서 유지보수도 어렵지 않게 될 수 있습니다.

전수자 예제

아주 간단한 전수자 예제 인터페이스 코드를 작성해 보았습니다.

interface Initiator
{
    public function init_hooks($main);
}

 $main으로는 플러그인 메인 파일이 입력됩니다. 훅 작성시 때때로 저 메인 파일이 필요하거든요.

플러그인 활성화 때 어떤 역할(role)을 생성해야 한다고 가정합니다. 그러면 이 때 필요한 전수자를 작성한다면

class Roles_Caps implements Initiator {

  public function init_hooks( $main = '' ) {
    register_activation_hook( $main, array( $this, 'callback_activation_hook' ) );
    register_deactivation_hook( $main, array( $this, 'callback_deactivation_hook' ) );
  }

  public function callback_activation_hook() {
    $this->add_role();
  }

  public function callback_deactivation_hook() {
    $this->remove_role();
  }

  private function add_role() {
    add_role(...);
  }

  private function remove_role() {
    remove_role(...);
  }
  // (이하생략)
}

 이렇게 클래스를 작성하고, 메인 파일에서는

$initiator = new Roles_Caps();
$initiator->init_hooks(__FILE__);

처럼 실행할 수 있습니다.

보다 뷰와 템플릿 로직이 강화되어야 하는 경우를 생각해 봅시다. 아주 간단히 전수자 클래스의 내부 코드를 이렇게 작성할 수 있습니다.

class Menu_Initiator implements Initiator {

  public function init_hooks($main = '') {
    $this->view = new Menu_View();
    add_action('admin_menu', array($this, 'callback_admin_menu'));
   ...
  }

  public function callback_admin_menu()
  {
    add_menu_page('title', 'title', 'manage_options', array($this, 'dispatch'));
  }
}

뷰 코드를 간단하게 설명하자면 이렇습니다.

class Menu_View {
  public function dispatch() {
    $context = array(
      'title' => 'Hello!';
      ...
    );
    ...
    render('menu.php', $context);
  }
}

 menu.php 는 템플릿 파일입니다. 콘텍스트에 따라 내용을 찍어냅니다.

<div class="wrapper">
...
<h2><?php echo esc_html($title); ?></h2>
...
</div>

이렇게 전수자부터 그 틀을 잡고 시작하면 이 이후의 MTV는 보다 형태를 잡기 쉬워집니다.

이밖에도 전수자만이 가진 독특한 기능들이 있습니다. 이걸 설명하고 싶어 손이 근질거리만, 분량이 너무 많아지니 다음 포스팅으로 미루도록 할께요.

MU Plugin, Plugin, 그리고 3rd Party Library

이제는 이런 개발 프레임워크가 더 등장할지 모르겠지만, 개발을 위한 프레임워크가 또다른 형태의 플러그인으로 제공되는 것이 있습니다. Piklist나 Genesis 같은 것들이 그 예입니다.

저의 플러그인 엔진은 사이트 동작을 위해 반드시 필요하고, 운영시 절대 비활성화 되어서는 안 되는 경우가 대부분이라 기본적으로는 엔진은 MU Plugin 형태로 동작되기를 권장합니다. 그러나 MU 플러그인이나 일반 플러그인이나 큰 차이가 없기 때문에 제작 자체는 일반 플러그인처럼 하고 있습니다.

그러나 개발 엔진 같은 라이브러리 같은 코드들을 플러그인으로 제공하게 되면 버전 충돌 문제를 피할 수 없습니다.

가령 제 플러그인 엔진이 굉장히 유명해져서 많이 사용된다는… 아주 즐거운 가정을 해 보자구요. A 플러그인은 제 엔진 1.8 버전을 사용합니다. B 플러그인은 제 엔진 2.0 버전을 사용한다고 해요. 그런데 1.8과  2.0버전은 엄청난 차이가 있어서 이 둘을 같이 사용할 수 없어요. 1.8 방식으로 코드를 쓰면 2.0에서는 오류를 뿜어내고, 그 반대로도 마찬가지입니다. 이 사이트는 A, B 플러그인을 둘 다 필요로 하는데… 어쩌죠?

이런 경우에 엔진은 서드파티 라이브러리처럼 쓸 수 있도록 할 것입니다. 해당 플러그인이 각 버전의 플러그인을 충돌하지 않도록 각자 독자적인 라이브러리로 내장할 수 도 있게 만들어 저의 엔진을 사용할 수 있도록 만들 것입니다.

여기까지! 이만 줄임!

개발에 관해 심각하게 글을 쓰려고 한 건 아닌데… 내용이 많이 길어집니다. 저도 가볍게 제 플러그인 엔진에 대한 컨셉을 정리하고, 기왕 정리한 거 여럿에게 보여 주는 것이 어떨까 싶었습니다. 딱딱하고 지루하게 컨셉을 쓰다 보면 아예 글을 작성할 수 없게 될 것만 같아 설렁설렁 대충대충 블로그 포스팅으로 남깁니다. 플러그인 엔진 버전이 거듭되어 제련되듯, 이러한 설명 자료들도 차차 탄탄하게 기록되었으면 좋겠습니다.