라라벨은 워드프레스에 필수가 아니다 — 그런데도 '많이 쓴다'고 들리는 이유

▶ 동영상 개요 — 라라벨은 워드프레스에 필수가 아니다 — 그런데도 '많이 쓴다'고 들리는 이유

6분 37초 — 워드프레스 코어는 라라벨을 쓰지 않는다 — 라라벨은 필수가 아니라 개발자가 고르는 선택지다. '많이 쓴다'는 말의 실체는 Roots의 Sage·Acorn으로 워… — NotebookLM 동영상 개요로 생성

🎧 오디오 개요 — 라라벨은 워드프레스에 필수가 아니다 — 그런데도 '많이 쓴다'고 들리는 이유

15분 31초 — 워드프레스 코어는 라라벨을 쓰지 않는다 — 라라벨은 필수가 아니라 개발자가 고르는 선택지다. '많이 쓴다'는 말의 실체는 Roots의 Sage·Acorn으로 워…. 화면은 이 글의 인포그래픽 한 장 고정 — NotebookLM 오디오 개요로 생성

워드프레스로 개인 사이트를 만들다가 "요즘 워드프레스 판에서는 라라벨을 많이 쓴다"는 말을 들었다. 그럴싸하게 들려서 워드프레스 코어를 뒤져 봤다. wp-includes 폴더를 열고, 로딩 순서를 좇고, 함수들을 따라가 봤다. 그런데 라라벨이 없다. 워드프레스 코어 어디에도 라라벨의 흔적이 없었다. 그럼 그 "많이 쓴다"는 말은 대체 무엇을 가리키는 걸까.

먼저 사실부터 못박자. 라라벨(Laravel — PHP로 웹 애플리케이션을 만드는 가장 널리 쓰이는 프레임워크, 2011년 첫 공개)은 워드프레스(2003년 첫 공개, 오늘날 전 세계 웹사이트의 약 43%가 사용)의 필수 부품이 아니다. 두 소프트웨어는 8년 터울로 태어난 남남이고, 워드프레스는 지금도 라라벨 없이 혼자 완결적으로 돈다. 그런데도 "워드프레스에서 라라벨을 쓴다"는 말이 계속 도는 데는 이유가 있다. 그 말이 실제로 가리키는 것은 워드프레스 코어가 아니라, 워드프레스로 개발하는 방식이다. 이 글은 그 오해를 풀고, 라라벨이 워드프레스 일에 실제로 어떻게 끼어드는지를 지도로 그린다.

먼저 결론 — 워드프레스 코어는 라라벨을 쓰지 않는다

워드프레스는 2003년에 태어난 소프트웨어다. 당시 PHP 세계에는 프레임워크라는 개념이 지금처럼 자리 잡기 전이었고, 워드프레스는 절차적(procedural — 함수를 순서대로 호출하며 흐름을 짜는 옛 방식) PHP로 짜였다. have_posts()로 글이 있는지 묻고 the_post()로 하나씩 꺼내 화면에 뿌리는, 전역 상태에 기대는 구조다. 반면 라라벨은 2011년에 객체지향과 의존성 주입(dependency injection — 필요한 부품을 밖에서 넣어 주어 갈아 끼우기 쉽게 만드는 설계)을 전제로 설계됐다. 뿌리가 다르다.

그래서 워드프레스는 라라벨을 필요로 하지 않는다. 플러그인 하나 없이 워드프레스만 깔아도 블로그가 돌고, 테마를 바꿔도 돌고, 커머스를 붙여도 돈다. "라라벨이 없으면 워드프레스가 안 뜬다"는 명제는 코어 기준으로는 거짓이다. 라라벨은 선택이다 — 그것도 워드프레스를 쓰는 사람이 아니라 워드프레스를 만드는 개발자가 개발 경험을 바꾸려고 얹는 선택이다.

그런데 왜 '많이 쓴다'고 들리나 — 세 갈래

라라벨이 워드프레스 일에 등장하는 방식은 크게 셋으로 갈린다. 셋은 서로 목적도, 결합 강도도 다르다. 하나로 뭉뚱그려 "워드프레스에서 라라벨을 쓴다"고 말하면 정확히 무엇을 말하는지 흐려진다.

위 다이어그램은 하나의 워드프레스 프로젝트에서 출발해 라라벨이 끼어드는 세 갈래를 보여준다. "부품만 빌려 얹기"는 워드프레스는 그대로 두고 라라벨의 부속만 꺼내 개발 편의를 높이는 길이다. "역할을 나눠 붙이기"는 워드프레스에 콘텐츠 관리만 맡기고 화면 렌더링이나 API 응답은 별도 라라벨 앱이 맡는 headless(머리 없는 — 관리 화면과 표시 화면을 분리하는 구성) 방식이다. "아예 갈아타기"는 워드프레스를 버리고 라라벨로 새로 만드는, 사실은 워드프레스와 무관한 선택이다. 이 글이 파고들 것은 첫 번째 갈래다 — "많이 쓴다"는 말의 대부분이 여기서 나오고, 오해도 여기서 자란다.

가장 흔한 갈래 — Roots 스택이 워드프레스를 라라벨처럼 만든다

첫 번째 갈래의 주인공은 Roots라는 독립 조직이 만든 도구 묶음이다. 그중 Sage(세이지 — 라라벨식 개발 방식을 얹은 워드프레스 스타터 테마, 현재 v11.2.1, 깃허브 별 약 1만 3천 개)가 입구다. Sage는 워드프레스 테마이면서 내부적으로 라라벨의 Blade(블레이드 — 라라벨의 템플릿 엔진) 문법으로 화면을 짜게 해 준다. 왜 굳이 이런 게 필요했는지는, 전통 워드프레스 템플릿이 어떻게 생겼는지 보면 바로 납득된다.

<?php
// 전통 워드프레스 템플릿 — 한 파일이 조회·분기·출력을 다 떠안는다
if ( have_posts() ) :
    while ( have_posts() ) : the_post();   // 루프를 돌며 글을 하나씩 꺼낸다
        $author = get_the_author();        // 데이터 조회가 화면 코드 한복판에 끼어든다
        ?>
        <article>
          <h2><?php the_title(); ?></h2>    <!-- HTML 태그와 PHP 코드가 뒤섞인다 -->
          <p>글쓴이: <?php echo esc_html( $author ); ?></p>
        </article>
        <?php
    endwhile;
endif;

위 코드는 워드프레스가 기본으로 제시하는 템플릿 방식이다. 핵심 문제는 한 파일이 세 가지 일을 동시에 한다는 것이다 — 데이터를 조회하고(get_the_author()), 조건을 따지고(if·while), HTML을 출력한다. 규모가 작을 땐 편하지만, 화면이 복잡해지면 조회 로직과 마크업이 한 덩어리로 엉겨 어디를 고쳐야 할지 찾기 어려워진다. 라라벨을 써 본 개발자에게 이건 10년 전 방식으로 돌아가는 느낌이다. Sage는 바로 이 뒤엉킴을 푼다.

Sage가 제안하는 방식은 데이터 준비와 화면 그리기를 두 파일로 쪼개는 것이다. 데이터는 View Composer(뷰 컴포저 — 특정 화면에만 데이터를 꽂아 주는 라라벨의 장치)가 준비하고, 화면은 Blade 템플릿이 순수하게 표시만 맡는다.

// app/View/Composers/Post.php — 데이터 준비는 여기서 (화면과 분리)
class Post extends Composer
{
    protected static $views = ['partials.post'];  // 이 화면에만 데이터를 꽂는다

    public function with(): array
    {
        return [
            'author' => get_the_author(),  // 워드프레스 함수를 그대로 쓴다
        ];
    }
}

그리고 화면 파일은 조회 로직이 사라진 채 표시만 남는다.

{{-- resources/views/partials/post.blade.php — 화면은 화면만 그린다 --}}
<article>
  <h2>{{ $title }}</h2>
  <p>글쓴이: {{ $author }}</p>   {{-- 데이터가 어디서 왔는지는 화면이 몰라도 된다 --}}
</article>

위 두 코드는 같은 결과를 만들지만 관심사가 분리돼 있다. 데이터를 어디서 어떻게 가져오는지는 Composer가 알고, 화면은 이미 준비된 $author·$title을 받아 자리에만 꽂는다. 이렇게 나누면 화면 디자인을 고칠 때 조회 로직을 건드릴 위험이 없고, 반대로 데이터 소스를 바꿀 때 마크업을 뒤지지 않아도 된다. 눈여겨볼 점은 get_the_author() 같은 워드프레스 함수를 그대로 쓴다는 것이다 — 라라벨을 얹었다고 워드프레스를 버리는 게 아니라, 워드프레스 위에 라라벨의 정리 정돈 습관을 덧입히는 것이다. 이것이 "워드프레스를 라라벨처럼 쓴다"는 말의 실체다.

요청 하나 안에서 두 프레임워크가 함께 산다 — Acorn

그런데 Blade 문법을 워드프레스가 알아들을 리 없다. 워드프레스는 {{ $author }} 같은 Blade 표현을 이해하지 못한다. 이 간극을 메우는 것이 Roots의 세 번째 도구 Acorn(에이콘 — 워드프레스 프로젝트 안으로 라라벨 부품을 들여오는 라이브러리, 현재 v6.0.0, 2025년 3월 출시, 라라벨 v13 기반, PHP 8.3 이상 요구)이다. Acorn은 플러그인도 테마도 아니라 composer.json에 한 줄로 앉는 라이브러리 묶음으로, 내부에 라라벨을 기능별로 쪼갠 illuminate/* 패키지 20여 개를 담고 있다. 이것이 매 요청마다 하는 일을 그림으로 보면 이렇다.

위 다이어그램은 브라우저 요청 하나가 처리되는 동안 벌어지는 일을 순서대로 보여준다. 핵심은 Acorn이 워드프레스를 대체하거나 가로채지 않는다는 점이다 — 워드프레스는 평소 그대로 시동을 걸고, Acorn은 그 흐름에 조용히 올라타 라라벨의 서비스 컨테이너(service container — 부품들을 등록해 두고 필요할 때 꺼내 주는 라라벨의 중심 장치)를 함께 띄운다. 그 결과 워드프레스의 훅(hook)이 계속 발동하는 동안 라라벨의 Blade·검증·캐시 같은 기능이 나란히 쓸 수 있게 된다. "요청 하나 안에서 두 프레임워크가 함께 산다"는 문장이 과장이 아닌 이유다.

여기서 함정 하나를 짚고 넘어가자. 이 그림만 보면 "그럼 워드프레스가 라라벨 위에서 도는 거 아닌가"라고 오해하기 쉽다. 순서가 반대다. 워드프레스가 먼저 뜨고, 라라벨이 그 안으로 들어온다. 주인은 여전히 워드프레스이고 라라벨은 손님이다. 이 방향을 뒤집어 이해하면 뒤에 나오는 트레이드오프가 통째로 헷갈린다.

그래서 필수불가결한가 — 값을 하는 자리와 아닌 자리

이제 처음 질문으로 돌아가자. 라라벨은 워드프레스에 필수불가결한가? 아니다. 앞서 봤듯 워드프레스 코어는 라라벨 없이 완결적으로 돌고, Roots 스택은 어디까지나 개발자가 고르는 편의다. 그렇다면 이 편의는 언제 값을 하고 언제 못 하는가? 손님을 들이는 데는 대가가 따르기 때문에 이 판단이 중요하다.

값을 하는 자리는 복잡하고 오래 유지보수할 사이트다. 화면 구조가 복잡하고, 여러 사람이 오래 손대고, 재사용할 UI 조각이 많을수록 Blade의 관심사 분리와 컴포넌트화가 유지보수 비용을 확실히 낮춘다. 라라벨에 익숙한 팀이 워드프레스 프로젝트를 맡을 때, 익숙한 방식 그대로 일할 수 있다는 것도 실질적인 이득이다.

반대로 값을 못 하는 자리도 분명하다. 첫째, 비용이 공짜가 아니다. Acorn이 매 요청마다 라라벨 컨테이너를 부팅하는 데 요청당 약 1~3밀리초가 더 든다 — 대부분의 사이트에선 무시할 수준이지만 존재하는 비용이다. 둘째, 의존성 충돌 위험이 있다. 워드프레스는 Composer(PHP의 표준 의존성 관리 도구)를 기본 지원하지 않아, 라라벨 부품을 자체 번들하는 다른 플러그인과 버전이 어긋나면 충돌이 난다. 셋째, 진입 장벽이다. 이 스택을 굴리려면 Composer·Blade·서비스 프로바이더를 알아야 하는데, 이건 워드프레스만 알던 사람에게는 새로 배워야 할 세계다. 단순 블로그나 소규모 사이트라면 이 모든 대가를 치르고 얻는 게 별로 없다.

정리하면, 라라벨은 워드프레스에서 망치가 아니라 선택 가능한 전동공구다. 못 몇 개 박는 데는 망치가 낫고, 집을 짓는 데는 전동공구가 낫다. 문제는 도구의 우열이 아니라 지금 내가 짓는 게 무엇이냐다.

정리 — 없어도 되지만, 있으면 달라지는 것

"워드프레스에서 라라벨을 많이 쓴다"는 말은 절반만 맞다. 워드프레스 코어는 라라벨을 쓰지 않고, 앞으로도 쓰지 않을 것이다. 라라벨이 등장하는 건 워드프레스로 개발하는 방식을 바꾸고 싶은 개발자의 선택지 안에서다 — 그중 가장 흔한 길이 Roots의 Sage·Acorn으로 워드프레스 위에 라라벨의 정리 정돈 습관을 덧입히는 것이다. 라라벨은 워드프레스에 필수불가결하지 않다. 다만 복잡한 사이트를 오래 다뤄야 한다면, 없어도 되는 그것이 있고 없고가 유지보수의 결을 바꾼다. 내 사이트가 정적 문서 몇 장이라면 이 스택은 과분하고, 언젠가 화면이 수십 개로 불어난다면 그때 다시 꺼내 볼 카드다. 도구를 고르기 전에 물어야 할 것은 언제나 "남들이 많이 쓰나"가 아니라 "지금 내가 짓는 게 무엇인가"다.

---

참고한 공개 자료:

• Sage — Roots (WordPress starter theme with Laravel Blade)
• Acorn — Integrate WordPress & Laravel (Roots)
• Using Blade Templates in Sage — Acorn Docs
• View Composers in Sage — Sage Docs
• roots/acorn — Integrate Laravel functionality into WordPress projects (GitHub)
• Laravel vs WordPress: A Head-to-Head Comparison — Kinsta
• WordPress and Laravel — Laravel News

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.