워드프레스를 더 이상 싸우지 않기로 했습니다… 그래서 사용 방식을 다시 구축했습니다

Source: Dev.to

소개

나는 충분히 많은 워드프레스 프로젝트를 구축하면서 패턴을 발견했다. 모두 깨끗하게 시작하지만 점점:

• 플러그인이 쌓인다
• 로직이 템플릿에 스며든다
• API가 흩어지게 된다

“그냥 동작하게 해라”가 아키텍처가 되고, 어느 순간 시스템을 만드는 것이 아니라 혼돈을 관리하고 있다.

워드프레스가 혼란스러운 이유

워드프레스는 모든 것이 되려고 한다:

• CMS
• 백엔드
• 프론트엔드
• 플러그인 시스템
• 템플릿 엔진

자연스럽게 모든 것이 뒤섞인다. 라우트가 너무 많은 정보를 알고, 데이터, 동작, 실행 사이에 명확한 경계가 없다. 여기서 문제가 발생한다.

새로운 관점: 워드프레스를 데이터 소스로 다루기

워드프레스를 애플리케이션처럼 다루는 대신 데이터 소스로 다루기 시작했다. 이 한 가지 변화가 모든 것을 바꾼다.

• WordPress는 콘텐츠를 관리한다.
• 내 시스템은 동작을 관리한다.
• 프론트엔드는 완전히 유연해진다.

KiwiPress – 워드프레스 위에 얹은 애플리케이션 레이어

KiwiPress는 워드프레스를 대체하지 않는다; 사용 방식을 정리한다. 목표는 간단하다: 워드프레스가 저장하는 것과 앱이 동작하는 방식을 분리한다.

책임 분리

• Seltzer → 라우트와 요청 라이프사이클을 처리한다
• Nectarine → 설정과 API 구조를 파싱한다
• KiwiPress → 워드프레스 전용 동작을 담당한다

KiwiPress 내부 서비스

각 파트는 하나의 작업만 담당한다. 누수가 없다.

로직을 삽입하는 대신 위임하기

// wpread.js
const wpread = new WPRead();

const route = {
  method: "GET",
  path: "/users/:email",
  handler: () => wpread.getUserByEmail()
};

라우트는 워드프레스가 어떻게 동작하는지 알 필요가 없으며, 단지 데이터를 요청한다.

장점

명확성

로직이 어디에 있는지 항상 알 수 있다.

유연성

프론트엔드는 무엇이든 될 수 있다: 맞춤 UI, SPA, 정적 사이트, 혹은 하이브리드.

이식성

워드프레스를 떠나더라도 앱이 무너지지 않는다.

유지보수성

플러그인과 템플릿을 뒤져가며 동작을 이해하려 애쓸 필요가 없다.

결론

나는 워드프레스를 대체하려는 것이 아니라 현대 시스템에서 올바르게 사용하려는 것이다. 워드프레스는 콘텐츠 관리, 관리자 워크플로, 생태계 면에서 여전히 뛰어나지만, 애플리케이션 로직은 그 안에 존재해서는 안 된다.

KiwiPress는 다음에 초점을 맞춘 더 큰 시스템의 일부이다:

• 계약 기반 아키텍처
• 모듈형 앱 엔진
• 벤더 중립 시스템

워드프레스가 고장 난 것이 아니다—우리가 너무 많은 일을 시키고 있을 뿐이다. 책임을 분리하면 모든 것이 훨씬 간단해진다.