우리는 WordPress에서 wp_posts를 사용하지 않고 80K+ 페이지를 제공하는 Programmatic SEO Engine을 어떻게 구축했는가

Source: Dev.to

우리가 startup‑cost.com 을 만들기 시작했을 때, 기존의 WordPress만으로는 부족하다는 것을 알았습니다. 우리는 79 000개 이상의 고유 페이지—479개 도시와 167개 사업 유형의 모든 조합마다 하나씩—를 실제 비용 데이터, 실시간 계산, 그리고 견고한 성능과 함께 제공해야 했습니다.

대부분의 사람들은 “WordPress에 80 K 페이지” 라고 하면 우리가 미쳤다고 생각합니다. WordPress는 블로그 플랫폼이라고요? 네, 맞습니다—하지만 그 이면에는 강력한 리라이트 엔진을 갖춘 유연한 PHP 프레임워크가 있습니다. 우리는 확장되지 않는 부분을 버리고 자체적으로 구축하기만 하면 되었습니다.

다음은 wp_posts에 단 한 행도 사용하지 않고 구현한 이야기를 전합니다.

wp_posts 규모에서의 문제

WordPress는 모든 콘텐츠를 wp_posts라는 단일 테이블에 저장합니다. 몇 백 개의 페이지가 있는 블로그나 소규모 비즈니스 사이트라면 괜찮지만, 수만 개의 행을 해당 테이블에 넣기 시작하면 상황이 급격히 악화됩니다:

우리는 근본적으로 다른 접근 방식을 필요로 했습니다.

왜 정적 사이트 생성기나 다른 CMS를 사용하지 않을까?

당연한 질문입니다. 우리는 Hugo, Next.js, 그리고 맞춤형 Node.js 앱을 평가했습니다. 하지만 WordPress가 여전히 우리에게 구체적인 장점을 제공했습니다:

• 호스팅 비용이 매우 저렴함 – 공유 WordPress 호스팅은 월 몇 달러에 불과하며 트래픽을 문제없이 처리합니다.
• 플러그인 생태계 – 우리는 여전히 SEO, 캐싱 및 기타 작업을 위한 유틸리티 플러그인을 사용합니다.
• 익숙한 배포 – 우리 팀은 WordPress를 속속들이 알고 있습니다. 학습 곡선이 없고 새로운 CI/CD 파이프라인이 필요하지 않습니다.
• PHP는 충분히 빠름 – OpCache와 깔끔한 쿼리 패턴을 사용하면 PHP 8이 페이지를 두 자릿수 밀리초 안에 제공합니다.

핵심 인사이트: 우리는 WordPress를 설계된 대로 사용할 필요가 없습니다. 데이터를 원하는 방식으로 저장하면서 라우팅 및 렌더링 프레임워크로 활용할 수 있습니다.

The Architecture – High Level

우리는 wp_posts를 완전히 우회하는 맞춤형 WordPress 플러그인을 만들었습니다. 이 개념은 세 가지 기둥에 기반합니다:

Custom Database Tables

모든 데이터를 posts와 postmeta에 넣는 대신, 적절한 스키마, 데이터 타입, 인덱스를 갖춘 전용 테이블을 만들었습니다. 이는 WordPress MySQL 인스턴스 내부에 존재하는 작은 애플리케이션 데이터베이스라고 생각하면 됩니다.

• 엔터티당 하나의 테이블 (도시, 사업 유형, 비용 지표).
• 컬럼은 실제 데이터 모델과 일치 – 일반적인 키‑값 쌍이 없습니다.
• 적절한 인덱싱, 정규화, 그리고 필요한 데이터만 정확히 조회하는 쿼리.

결과: 메타 기반 조회로 80 K 게시물을 검색하면 수백 밀리초가 걸릴 수 있지만, 목적에 맞게 구축된 테이블에 대한 직접 인덱스 조회는 한 자릿수 밀리초 안에 반환됩니다.

Virtual URL Routing

WordPress의 rewrite API는 강력하지만 활용도가 낮습니다. 대부분의 개발자는 퍼머링크 설정 화면을 통해서만 이를 사용합니다. 실제로는 완전히 사용자 정의 URL 패턴을 등록하고 자체 렌더링 로직에 매핑할 수 있습니다.

• WordPress가 인식하도록 URL 패턴을 정의합니다.
• 요청이 들어오면 WordPress가 URL을 매칭하고 슬러그를 추출한 뒤 플러그인에 제어를 넘깁니다.
• wp_posts에 게시물이 생성되지 않으며, 행도 전혀 건드리지 않습니다 – URL은 우리가 WordPress에 인식시키도록 지정했기 때문에 존재합니다.

이를 통해 WordPress의 요청 라이프사이클, 캐시 훅, 플러그인 호환성을 유지하면서 URL 구조를 완전히 제어할 수 있습니다.

Dynamic Content Generation

프로그래매틱 SEO는 각 페이지가 실제 가치를 제공할 때만 효과가 있습니다. 우리는 단순히 템플릿에 도시 이름만 바꾸는 것이 아니라, 실제 비용 수치, 실제 계산, 실제 비교를 각 페이지에 보여줍니다.

• 렌더링 레이어가 커스텀 테이블에서 데이터를 가져옵니다.
• 각 도시‑사업 조합에 특화된 계산을 수행합니다.
• 고유한 타이틀, 메타 설명, 스키마 마크업 등을 포함한 완전한 HTML을 출력합니다.

Google은 얇고 템플릿화된 콘텐츠를 감지합니다. 각 페이지에 데이터 기반의 진정한 가치가 있을 때 프로그램matic SEO가 장기적으로 효과를 발휘합니다.

성능 결과

Benchmarks were run on the same server (shared hosting, PHP 8.1, MariaDB 10.6).

차이는 극적입니다. 적절한 인덱스를 가진 커스텀 테이블은 워드프레스를 목적에 맞게 구축된 애플리케이션처럼 동작하게 합니다.

사이트맵 전략

Google의 제한: 파일당 50 000 URL 및 압축되지 않은 50 MB. 80 K 페이지가 있으므로 여러 개의 사이트맵과 인덱스가 필요합니다.

• URL을 관리 가능한 파일로 나누어 프로그램matically 사이트맵을 생성합니다.
• 모든 청크를 참조하는 사이트맵 인덱스를 만듭니다.
• 주간 cron 작업으로 생성합니다.
• Google Search Console이 문제 없이 이를 수집하며, 사이트맵 청크별 인덱싱 진행 상황을 추적할 수 있습니다.

내부 링크

80 K 페이지가 있는 상황에서, 내부 링크는 SEO와 사용자 탐색을 돕는 데 모두 중요합니다:

• 각 도시 페이지는 해당 도시에서 이용 가능한 모든 사업 유형에 연결됩니다.
• 각 사업 페이지는 해당 사업 유형에 대한 상위 도시들에 연결됩니다.
• 각 상세 페이지는 지리적 및 주제적 근접성을 기반으로 관련 페이지에 연결됩니다.
• 조밀한 내부 링크 그래프는 검색 엔진이 사이트 구조를 발견하고 이해하는 데 도움을 줍니다.

캐싱

우리는 다계층 캐싱 전략을 사용합니다:

• 모든 80 K 페이지가 동일한 트래픽을 받는 것은 아닙니다.
  • 인기 있는 도시/비즈니스 조합은 더 긴 TTL로 사전 캐시됩니다.
  • 롱테일 페이지는 짧은 TTL로 필요에 따라 캐시됩니다.
• 또한 자주 접근되는 집계에 대해 데이터베이스 쿼리 수준에서도 캐시합니다.

우리가 배운 점

• WordPress는 대규모 트래픽을 처리할 수 있다 – 하지만 기본 콘텐츠 모델을 벗어날 때만 가능합니다. 이 플랫폼은 사람들이 생각하는 것보다 훨씬 유연합니다.
• 커스텀 테이블은 “해킹”이 아니다 – 데이터가 포스트/메타 패턴에 맞지 않을 때 적절한 도구입니다. WordPress 자체도 댓글, 사용자, 옵션을 위해 커스텀 테이블을 사용합니다.
• 가상 라우팅은 강력하다 – WordPress 리라이트 규칙으로 복잡한 URL 패턴을 처리할 수 있습니다. URL이 포스트에 매핑되지 않는다고 해서 별도의 프레임워크를 만들 필요는 없습니다.
• 프로그래밍 SEO는 실제 가치를 제공해야 한다 – Google은 얇고 템플릿화된 콘텐츠를 감지합니다. 모든 페이지는 진정으로 다르고 유용한 데이터를 제공해야 합니다. 이것이 스팸과 실제 제품을 구분하는 기준입니다.
• 데이터 모델부터 시작하라 – 우리는 렌더링 코드를 작성하기보다 데이터베이스 스키마 설계에 더 많은 시간을 투자했습니다. 좋은 데이터 모델링은 모든 계층에서 효과를 발휘합니다.
• 모니터링 후 최적화 – 처음에는 캐싱 없이 시작했고, 모니터링을 통해 병목 현상이 발견된 부분에만 캐싱을 추가했습니다. 조기 최적화는 필요 없는 복잡성을 초래했을 수 있습니다.

결과물을 확인해 보세요: startup-cost.com – 전 세계 479개 도시의 167가지 사업 유형에 대한 창업 비용 추정치.

Kavela Ltd가 제작 – 우리는 규모에 맞는 데이터 기반 웹 도구를 구축합니다.