앞의 일곱 회차에서 REST API 로 할 수 있는 일을 훑었습니다. 도구가 갖춰지면 자연스럽게 나오는 질문이 있습니다 — “그럼 프런트를 통째로 분리할까?” 이 회차는 그 질문에 대한 정직한 답입니다.
헤드리스가 실제로 주는 것
과장하지 않고 적으면 셋입니다. 첫째, 같은 데이터를 여러 소비자가 씁니다 — 웹사이트와 앱과 매장 키오스크가 한 콘텐츠를 봅니다. 둘째, 프런트엔드 팀이 자기 스택과 자기 배포 주기를 갖습니다. 셋째, 렌더링 계층을 워드프레스와 무관하게 고를 수 있습니다.
여기서 빠진 것이 하나 있습니다. “속도” 는 목록에 없습니다. 헤드리스로 빨라지는 경우가 있지만 그것은 프런트를 새로 잘 만들었기 때문이지 분리 자체의 효과가 아닙니다. 같은 노력을 캐시 계층과 자산 정리에 쓰면 대개 같은 결과에 훨씬 싸게 도달합니다.
가장 과소평가되는 것 — 미리보기
워드프레스의 미리보기는 테마가 그 글을 그려 보는 기능입니다. 테마가 없으면 그릴 것이 없습니다. 헤드리스에서 미리보기를 되살리려면 프런트엔드에 전용 경로를 만들고, 인증된 요청으로 초안을 받아오고, 그 경로가 공개 색인에 들어가지 않도록 막아야 합니다. 작은 프로젝트 하나가 통째로 생깁니다.
이것을 미루면 편집자는 “저장하고 실제 화면에서 확인” 하는 방식으로 일하게 되고, 그 방식은 발행 사고를 만듭니다.
편집 경험과 플러그인
블록 에디터의 가치는 편집 화면이 결과와 비슷하다는 것입니다. 프런트가 분리되면 그 유사성이 사라지고 에디터는 사실상 입력 폼이 됩니다. 블록이 만들어 내는 마크업도 프런트에서 다시 해석하거나 다시 만들어야 합니다.
더 실질적인 것은 플러그인입니다. 프런트에 무언가를 출력하던 플러그인은 전부 동작을 멈춥니다 — SEO 메타 태그와 구조화 데이터, 폼, 리다이렉트, 관련 글, 동의 배너. 각각을 프런트엔드에서 다시 만들거나, 그 플러그인이 REST 로 데이터를 내주는지 확인해야 합니다. 특히 SEO 는 통째로 프런트엔드의 책임이 됩니다.
운영 비용은 진짜 비용입니다
분리하면 배포 대상이 둘, 로그가 둘, 캐시가 둘, CI 파이프라인이 둘이 됩니다. 장애가 났을 때 어느 쪽이 원인인지부터 판단해야 하고, 두 쪽의 버전 호환도 관리 대상이 됩니다. 이것은 없앨 수 있는 비용이 아니라 구조가 만들어 내는 상시 비용입니다.
중간 지점도 있습니다. 테마는 그대로 두고 상호작용이 필요한 조각만 REST 로 붙이는 방식입니다. 검색 · 필터 · 신청 폼 · 대시보드 위젯 정도는 이 방식으로 충분하고, 미리보기와 SEO 와 플러그인 생태계를 그대로 유지합니다. 이 연재에서 다룬 것들이 그대로 쓰입니다.
다음 회차
개발자 대상 여섯 연재의 마지막 글입니다. 훅과 필터로 확장하는 법은 훅과 필터 제대로 쓰기에, 여기서 미룬 측정 이야기는 워드프레스 성능 프로파일링에 있습니다. 실제 사이트에서 이 판단들을 어떤 순서로 내리는지는 작업 과정에 그대로 적어 두었고, 업그레이드 · 최적화 · 보안 점검을 한 건으로 맡기는 방법은 최적화 지원 사업에 있습니다.