워드프레스 대신 Next.js + Payload CMS — 왜 이 조합으로 갈아탈까

워드프레스로도 잘 되는데, 왜 굳이

워드프레스는 여전히 훌륭한 도구입니다. 전 세계 웹사이트의 상당수가 워드프레스로 돌아가고, 관리자 화면에서 클릭 몇 번으로 글을 쓰고 플러그인을 붙일 수 있습니다. 코드를 몰라도 사이트를 운영할 수 있다는 게 가장 큰 강점이죠. 이 글에서 살펴볼 Payload CMS는, 바로 그 워드프레스의 자리를 다른 방식으로 채우는 도구입니다.

그런데 요즘 새로 만드는 사이트, 특히 개발자가 직접 짓는 사이트에서는 다른 조합이 부쩍 늘었습니다. Next.js라는 웹 프레임워크에 Payload CMS를 얹는 방식입니다. 워드프레스가 혼자 하던 일을 둘로 쪼개는 구조인데, 언뜻 보면 일을 더 복잡하게 만드는 것 같습니다. 왜 이렇게 할까요.

이 글은 Payload CMS가 무엇인지, 이 조합이 워드프레스보다 유리한 경우는 언제이고 오히려 불리한 경우는 언제인지를 코드 없이 정리합니다.

Payload CMS가 무엇인가 — "헤드리스" 워드프레스

Payload CMS도 워드프레스처럼 콘텐츠를 관리하는 **CMS(콘텐츠 관리 시스템)**입니다. 글·이미지·데이터를 저장하고 관리하죠. 결정적 차이는 **"헤드리스(headless)"**라는 점입니다.

• 워드프레스: 콘텐츠 관리와 화면에 보여주는 일까지 한 몸입니다. 글을 쓰면 워드프레스가 그 글을 웹페이지로 그려 방문자에게 바로 보여줍니다.
• Payload (헤드리스): 콘텐츠를 저장·관리하는 뒷단(백엔드)만 맡고, 방문자가 보는 화면(프론트엔드)은 분리합니다. "머리(화면)가 없다"고 해서 헤드리스입니다. 화면은 Next.js가 담당하죠.

또 하나의 차이는 관리 방식입니다. 워드프레스가 관리자 화면에서 클릭으로 설정한다면, Payload는 콘텐츠 구조를 코드로 정의합니다. TypeScript라는 언어로 "이 사이트에는 어떤 데이터가 있고 어떤 모양인지"를 코드로 적어두는 방식이에요. 개발자에게는 익숙하고 강력하지만, 비개발자에게는 진입 장벽이 됩니다. 이 지점이 뒤에서 다룰 트레이드오프의 핵심입니다.

Next.js와 Payload가 한 몸이 되는 이유

원래 헤드리스 CMS는 콘텐츠를 관리하는 서버와 화면을 그리는 서버를 따로 운영해야 했습니다. 관리할 게 둘이라 번거로웠죠.

Payload가 주목받은 계기가 여기 있습니다. Payload 3 버전부터, Payload가 Next.js 앱 안에 그대로 들어가서 함께 돌아갑니다. 콘텐츠 관리 뒷단과 관리자 화면이 Next.js 프로젝트 폴더 안에 통째로 설치되는 거죠. 이 변화가 2024년 말에 정식으로 나오면서, "Next.js + Payload"가 하나의 프로젝트로 묶이는 지금의 조합이 자리 잡았습니다.

정리하면 이렇습니다.

역할	담당
콘텐츠 저장·관리 (뒷단)	Payload CMS
방문자가 보는 화면 (앞단)	Next.js
두 가지가 사는 곳	하나의 코드·하나의 프로젝트

이 조합이 유리한 이유

1. 관리할 덩어리가 하나로 줄어든다

뒷단·앞단·관리자 화면이 한 프로젝트 안에 있으니, 배포도 한 번에 끝납니다. 서버를 둘로 나눠 관리하던 번거로움이 사라집니다. (다만 데이터를 담는 데이터베이스는 여전히 따로 두고 관리해야 합니다 — "완전히 하나"는 아니라는 점은 정직하게 알아두는 게 좋습니다.)

2. 데이터의 모양이 어긋나지 않는다

Payload는 콘텐츠 구조를 코드로 정의하면 그에 맞는 타입 정보를 자동으로 만들어줍니다. 쉽게 말해, 뒷단에서 "이 글에는 제목과 날짜가 있다"고 정해두면 앞단 화면 코드도 그 약속을 그대로 공유합니다. 데이터의 모양이 앞뒤로 어긋나서 생기는 버그를 처음부터 줄여주는 거죠. 개발자와 데이터가 같은 그림을 그리도록 강제하는 구조입니다.

3. 화면을 마음대로, 그리고 빠르게

화면을 Next.js가 전담하니 디자인과 동작을 원하는 대로 짤 수 있습니다. 워드프레스 테마의 틀에 맞출 필요가 없죠. 게다가 Next.js는 검색엔진 최적화(SEO)와 빠른 화면 로딩에 강한 프레임워크라, 성능과 검색 노출 면에서 유리합니다.

4. 특정 회사에 묶이지 않는다

Payload는 오픈소스(MIT 라이선스)입니다. 원하는 서버 어디에든 직접 올려서 쓸 수 있고, 특정 서비스 업체에 종속되지 않습니다. 데이터와 코드를 내가 온전히 소유하는 구조죠.

참고로 Payload는 2025년 6월 디자인 도구 회사 Figma(피그마)에 인수됐는데, 인수 후에도 오픈소스로 유지된다고 공식 발표했습니다. 큰 회사가 뒤를 받치게 됐다는 신호이기도 합니다.

그런데 언제는 오히려 불리한가

여기서 균형을 잡아야 합니다. 이 조합이 항상 정답은 아닙니다. 워드프레스가 여전히 나은 경우가 분명히 있습니다.

• 비개발자가 직접 운영해야 한다면: Payload는 코드로 다루는 도구입니다. 개발자가 없으면 시작조차 어렵습니다. 클릭만으로 사이트를 꾸리고 싶다면 워드프레스가 압도적으로 낫습니다.
• 빨리, 저렴하게 띄우고 싶다면: 워드프레스는 설치형 서비스가 많아 반나절이면 사이트가 뜹니다. Next.js + Payload는 개발 공수가 듭니다.
• 플러그인 생태계가 필요하다면: 워드프레스에는 수만 개의 플러그인이 있습니다. 예약, 결제, 쇼핑몰 같은 기능을 클릭으로 붙일 수 있죠. Payload는 성장 중이지만 생태계 규모는 아직 워드프레스에 한참 못 미칩니다.
• 직접 운영·관리가 부담이라면: 오픈소스를 직접 올려 쓴다는 건, 서버와 유지보수를 내가 책임진다는 뜻이기도 합니다.

Payload가 얼마나 자리 잡았는지도 냉정하게 볼 필요가 있습니다. 깃허브 별 4만여 개, 누적 내려받기 수백만 회로 빠르게 성장하는 도전자인 것은 맞지만, 아직 "가장 널리 쓰이는 CMS"는 아닙니다. 헤드리스 시장에서도 더 큰 경쟁자들이 있고, 전체 CMS 시장은 여전히 워드프레스가 압도합니다.

정리 — 무엇을 우선하느냐의 문제

Next.js + Payload CMS가 워드프레스보다 "더 좋은" 게 아닙니다. 우선순위가 다른 선택입니다.

• Payload가 맞는 경우: 개발자가 있고, 화면을 마음대로 짜고 싶고, 성능과 코드 소유권이 중요하고, 데이터 구조가 복잡한 서비스형 사이트.
• 워드프레스가 맞는 경우: 비개발자가 운영하고, 빨리 띄워야 하고, 기성 플러그인으로 충분한 콘텐츠·블로그형 사이트.

기술 스택 선택은 "무엇이 트렌드인가"가 아니라 "내 상황에서 무엇을 우선하는가"의 문제입니다. 이런 선택을 할 때는 왜 그렇게 정했는지를 한 장에 남겨두면, 나중에 "그때 왜 이 스택을 골랐더라?" 하고 헤매지 않습니다.

도구에 "정답"은 없습니다. 내 팀의 실력, 사이트의 성격, 감당할 수 있는 관리 비용 — 이 세 가지를 저울에 올리면, 어느 쪽이 나에게 맞는지가 보입니다.

---

참고 출처

• Payload 3.0 공식 발표 (payloadcms.com, 2024년 11월)
• Payload GitHub 저장소 — MIT 라이선스, 별 4만여 개 (github.com/payloadcms/payload, 2026-07-31 확인)
• "Welcoming Payload to the Figma Team" (figma.com/blog, 2025-06-17)
• Next.js 공식 사이트 (nextjs.org) — 현재 16 버전대, 2024년 15 출시