Advanced Custom Fields 는 수백만 명이 사용하는 훌륭한 플러그인으로, WordPress를 풀스택 CMS로 변환하여 무제한의 커스텀 필드 그룹과 유형을 생성하고 모든 종류의 커스텀 포스트 타입에 추가할 수 있게 해줍니다.
하지만 Advanced Custom Fields의 확장성 한계에 대해 아는 사람은 많지 않습니다.
GeoDirectory가 리스팅의 커스텀 필드를 관리하는 데 Advanced Custom Fields를 사용하는지 묻는 질문을 꽤 자주 받습니다.
하기로 했냐고 의아해합니다.
저희에게 그 답은 명확합니다. Advanced Custom Fields는 디렉토리를 구축하는 데 있어 확장성이 상당히 제한적입니다.
사용자로서, 내부에서 어떤 일이 일어나는지, 그리고 웹 디렉토리가 제기할 수 있는 확장성 문제를 인식하지 못할 수도 있다고 생각했습니다.
그러던 중 얼마 전, 저희는 Facebook의 인기 WordPress 그룹를 투표하는 선택지에는 GeoDirectory, 인기 마켓플레이스에서 제공되는 몇 가지 다른 디렉토리 테마, 그리고 ACF + FacetWP.
결과를 보고 저희는 적잖이 당혹스러웠습니다. ACF + FacetWP가 예상보다 훨씬 많은 표를 받았기 때문입니다.
투표한 사람들은 단순한 일반 사용자가 아니라 웹사이트 개발자와 WordPress 전문가들이었습니다.
이러한 이유로, 저희는 Advanced Custom Fields를 디렉토리에 사용하는 것이 왜 좋지 않은 생각인지 설명할 때가 됐다고 판단했습니다.
그리고 왜 웹 개발자들은 고객에게 지속적으로 성장 가능한 빠르고 확장성 있는 솔루션을 제공하는 것에 관심이 없지 않는 한, 그 솔루션을 누구에게도 제안해서는 안 되는지도 설명하고자 합니다.
WordPress 커스텀 필드 확장성의 한계
WordPress는 기본적으로 wp_postmeta 데이터베이스 테이블을 사용하여 커스텀 필드 데이터를 저장하며, 게시물에 사용된 각 커스텀 필드마다 1개의 행을 생성합니다.
그 외에도 WordPress는 각 게시물에 대해 이 테이블에 많은 추가 데이터를 저장하며, 각각 테이블의 1개 행을 차지합니다.
SQL 쿼리 최적화에 시간을 투자해 보셨다면, 디렉토리나 필터링 같은 기능에는 그것이 이상적인 구조가 아님을 아실 것입니다.
실제로 기본 데이터베이스 구조는 게시물과 커스텀 필드가 많은 웹사이트에 잠재적으로 심각한 병목 현상을 일으킬 수 있습니다.
이는 WordPress의 약점 중 하나로 꼽힙니다.
커스텀 필드로 게시물을 필터링하려면 쿼리에서 wp_post 테이블과 wp_postmeta 테이블을 조인해야 하기 때문입니다.
테이블이 커질수록 쿼리 속도는 느려집니다.
더 심각한 문제는, 두 개의 메타 값으로 필터링하려면 하나의 쿼리에서 post_meta 테이블을 두 번 조인해야 한다는 점입니다.
이는 시스템 메모리를 과도하게 소모하여 소규모 디렉토리가 아닌 경우 성능을 크게 저하시킬 수 있습니다.
Advanced Custom Fields 확장성의 한계
Advanced Custom Fields 플러그인은 게시물, 페이지, 커스텀 필드 수가 적거나 보통 수준인 웹사이트에는 완벽한 솔루션입니다.
그러나 극히 드문 경우를 제외하면, 디렉토리는 정반대의 특성을 가집니다.
디렉토리는 게시물 수가 매우 많고 커스텀 필드 수 역시 매우 많을 수 있습니다.
Advanced Custom Fields의 주요 확장성 문제는 리스팅에 추가된 각 커스텀 필드마다 데이터베이스의 wp_postmeta 테이블에 2개의 행을 생성한다는 것입니다.
또한 자체 설정에 속하는 여러 postmeta 행도 추가합니다.
즉, 기본 WordPress 커스텀 필드 시스템을 사용할 때에 비해 데이터베이스의 wp_postmeta 테이블에 두 배 이상의 행을 추가하게 됩니다.
이 문제를 좀 더 명확하게 설명하기 위해 간단한 테스트를 진행했습니다.
새로운 WordPress 웹사이트를 만들고, hello world 게시물과 샘플 페이지를 삭제한 뒤 Advanced Custom Fields를 설치했습니다.
1개의 그룹과 5개의 커스텀 필드를 만들고, 5개의 커스텀 필드를 사용하는 게시물 3개를 발행했습니다.
그 결과, wp_postmeta 테이블의 행 수가 이미 83개에 달했습니다.
정말 말도 안 되는 수치입니다.
300,000개의 리스팅과 5개의 커스텀 필드가 있는 디렉토리의 행 수를 상상해 보세요.
ACF를 사용하면 wp_postmeta 테이블의 행 수가 최소 3,000,000개가 됩니다
GeoDirectory는 어떻게 확장될까요?
매우 간단합니다. 각 커스텀 포스트 타입마다 별도의 커스텀 테이블을 생성합니다.
예시: wp_gd_gd_place_detail
이 테이블에는 모든 커스텀 필드와 해당 데이터를 각 포스트마다 한 행으로 저장합니다.
또한 WordPress가 기본 wp 데이터베이스 테이블을 쿼리하기 위한 자체 PHP API를 갖추고 있는 것처럼, 저희도 커스텀 테이블을 쿼리하기 위한 자체 PHP API를 구축했습니다.
이는 GD가 대부분의 경우 포스트 테이블과 저희 테이블만 조인하면 된다는 것을 의미합니다.
그런 다음 임의의 커스텀 필드로 결과를 필터링할 수 있습니다.
20개의 커스텀 필드로 필터링할 수 있는 반면, ACF는 facetWP(속도를 높여주지만 여전히 핵심적인 한계가 있음)를 사용하더라도 하나의 쿼리에서 동일한 작업을 수행하기 위해 여러 테이블을 반복해서 조인해야 하며, 동일한 쿼리에 훨씬 더 많은 서버 메모리를 사용하게 됩니다.
결론
GeoDirectory와 WordPress 또는 WP + Advanced Custom Fields를 비교하면 다음과 같습니다:
WordPress
1) 필터링하려는 커스텀 필드마다 추가적인 테이블 JOIN이 필요합니다.
2) wp_postmeta가 빠르게 커져서 쿼리 속도가 느려집니다
WP + ACF
1) 필터링하려는 커스텀 필드마다 추가적인 테이블 JOIN이 필요합니다.
2) wp_postmeta가 WordPress 단독 사용 시보다 두 배 더 커집니다
GeoDirectory
1) 조인이 필요하지 않습니다
2) GD는 wp_postmeta에 데이터를 추가하지 않으므로 불필요한 용량 낭비가 발생하지 않습니다.
3) 리스팅 데이터를 저장하는 데이터베이스는 포스트당 1개의 행만 사용합니다
WordPress는 데이터를 저장하는 방식에 이러한 한계가 있는 것으로 잘 알려져 있습니다. 대부분의 경우 이 시스템은 문제없이 작동하지만, 대규모 디렉토리를 다룰 때는 적합한 솔루션이 아닙니다.
바로 그렇기 때문에 GeoDirectory를 사용하면 수백만 개의 리스팅이 있는 디렉토리를 만들 수 있는 반면, WP + Advanced Custom Fields로는 심각한 성능 문제가 나타나기 전에 겨우 수백 개의 리스팅으로 디렉토리를 만드는 것도 운이 좋아야 가능합니다.
이것이 바로 Advanced Custom Fields의 확장성 한계로 인해 저희가 GeoDirectory에 이를 사용하지 않기로 결정한 이유이며, 여러분도 사용하지 않아야 하는 이유입니다.
궁금한 점이 있으시면 아래 댓글에 자유롭게 질문해 주세요.