Drupal Commerce가 Shopify를 이기는 순간

Drupal Commerce는 대부분의 온라인 쇼핑몰에게 잘못된 답입니다. 이는 십오 년 동안 탄탄하게 설계되어 온 프로젝트에 대한 비판이 아닙니다. 대부분의 쇼핑몰이 어떤 모습인지에 대한 진술일 뿐입니다. 수백 개의 SKU, 하나의 통화, 소비자 고객, 그리고 마지막에 카드 결제 한 번. 이런 형태의 사업이라면 중요한 모든 축에서 호스팅형 플랫폼이 이기고, 논쟁은 시작되기도 전에 끝납니다.

그런데 계산이 완전히 뒤집히는 소수가 존재하며, 그것은 수익성이 높은 소수입니다. 변형 표로는 표현할 수 없는 구성형 제품. 협상된 가격표를 가진 거래처 계정. 카탈로그 자체가 편집 콘텐츠인 사이트. 재고와 가격을 소유하고 웹사이트를 표시면으로만 취급하는 ERP. 이런 사업에서 호스팅형 플랫폼은 저렴하지 않습니다. 그것은 앱과 우회 방법, 그리고 바꿀 수 없는 것들의 형태로 계속 내는 영구적인 세금입니다.

이 글은 그 경계선이 실제로 어디에 놓여 있는지를 양쪽의 숫자와 함께 보여줍니다. Shopify 절을 읽다가 자기 사업을 알아봤다면 거기서 멈추십시오. 큰돈을 아끼게 될 것이고, 이 글은 제 몫을 다한 것입니다.

Drupal Commerce는 언제 Shopify를 이길까요? 제품을 단순한 변형 표로 모델링할 수 없을 때, 같은 SKU에 대해 고객마다 다른 가격을 볼 때, 카탈로그와 편집 콘텐츠가 같은 것일 때, 또는 ERP가 진실의 출처이고 쇼핑몰이 그것을 들여다보는 창일 때입니다. 통화 한두 개로 끝나는 평범한 소비자용 카탈로그라면 삼 년 총액에서 Shopify가 더 저렴하고 전환도 더 잘합니다. 갈림길은 제품과 가격 책정의 복잡도이지 트래픽이나 매출이 아닙니다.

Drupal Commerce의 정체

Drupal Commerce는 쇼핑몰 제품이 아닙니다. Drupal의 엔티티와 필드 시스템 위에 얹힌 엔티티 타입의 묶음이며, 이 글에서 이어지는 모든 내용이 그 한 문장에서 따라 나옵니다.

Drupal Commerce의 제품은 노드와 똑같이 번들을 가진 엔티티입니다. 제품 변형, 주문, 주문 항목, 결제, 프로모션, 스토어도 마찬가지입니다. 그 전부가 임의의 필드를 받아들이므로 변형 하나가 배치 번호, 인증서 참조, 영업일 단위 리드타임, 그리고 가격 계산에 쓰이는 치수를 함께 가질 수 있습니다. 이것들은 고정된 스키마 옆에 덧붙인 커스텀 필드가 아닙니다. 그 자체가 스키마입니다.

구매 대상은 제품이 아니라 변형입니다. 제품은 보여주기 위한 껍데기이고, SKU와 가격을 가진 품목이 변형이며, 속성이 선택 가능한 조합을 만들어냅니다. 제품 타입은 제품이 어떤 필드를 가질지 정하고, 변형 타입은 그 변형이 어떤 속성을 가질지 정합니다. 이 구조 어디에도 의류나 물리적 상품, 혹은 선택지 개수가 고정되어 있다는 가정은 없습니다.

그 결과 Drupal Commerce는 당신이 무엇을 파는지에 대해 거의 아무 의견도 갖지 않습니다. 그 자유의 대가는 결정도 거의 제공하지 않는다는 점이며, 그 모든 결정을 누군가는 내려야 한다는 점입니다.

Drupal Commerce의 현재 위치

현재 권장 릴리스는 2026년 7월 17일에 공개된 Drupal Commerce 3.3.8이며, Drupal 10.3 이상과 Drupal 11에서 동작합니다. 안정 릴리스는 Drupal 보안 권고 정책의 적용을 받는데, 이는 들리는 것보다 중요합니다. 공개된 취약점이 GitHub 이슈가 아니라 조율된 릴리스로 처리된다는 뜻이기 때문입니다.

Drupal Commerce 프로젝트 페이지는 이 모듈을 사용하는 사이트를 35,870곳으로 보고합니다. Commerce 3.0.0은 3.x 계열의 첫 안정 릴리스로 2025년 1월에 나왔고 Drupal 9 지원을 끊었습니다. 그 주변에는 크지 않은 기여 모듈 생태계가 있습니다. Commerce Shipping은 3.0.3이고 설치 수는 약 15,200이며, 아래에서 다루는 전문 모듈들은 수천 단위에 머뭅니다.

이를 WooCommerce와 비교해 보십시오. 활성 설치 수가 700만 회를 넘는다고 보고하며 WordPress 6.9와 PHP 7.4 이상을 요구합니다. 설치 규모로 보면 Drupal Commerce가 약 200배 작습니다.

그 비율이 이 글에서 가장 중요한 숫자이며, 자랑이 아니라 경고입니다. 그것은 이 일에 쓸 모듈이 이미 있느냐는 물음에 대한 답이 자주 없다는 뜻이기 때문입니다.

Shopify를 정직하게 평가하기

Shopify는 자체 호스팅 쇼핑몰 대부분을 가라앉히는 네 가지 문제를, 당신이 코드 한 줄을 쓰기도 전에 해결합니다.

호스팅형이므로 가동률, 확장, 패치가 더 이상 당신의 예산 항목이 아닙니다. 카드 데이터를 대신 다루므로 당신이 떠안는 규정 준수 범위는 원래의 몇 분의 일에 그칩니다. 그 결제 흐름은 어떤 에이전시도 재현할 수 없는 양의 실제 거래로 검증되었고, 그런 규모에서의 작은 전환 차이는 어떤 아키텍처 취향보다도 값집니다. 그리고 앱 생태계 덕분에 대부분의 요구사항은 프로젝트가 아니라 구독의 형태로 도착합니다.

수천 개의 SKU, 통화 한두 개, 협상 가격이 없는 소비자용 카탈로그라면 이 글 뒷부분에서 설명하는 이점은 하나도 해당되지 않습니다. 지금 월 65파운드에 얻고 있는 것을 에이전시에 돈을 주고 더 못하게 다시 만드는 셈입니다.

분명히 말해 두겠습니다. 이 글의 나머지는 반대 방향을 주장하기 때문입니다. 대부분의 쇼핑몰은 Shopify에서 멈춰야 합니다. 당신의 쇼핑몰이 그중 하나라면, Shopify와 맞춤 구축을 비교한 글이 이 페이지보다 그 결정을 더 자세히 다룹니다.

영국에서 Shopify의 비용

Shopify는 영국 가격을 파운드로 공개하므로 환산이 필요 없습니다. 2026년 9월 기준 Shopify 요금 페이지에 따르면 Basic은 월 결제 시 월 25파운드, 연 결제 시 19파운드이고, Grow는 65파운드 또는 49파운드, Advanced는 344파운드 또는 259파운드, Plus는 월 1,800파운드부터입니다. POS Pro는 매장 한 곳당 월 69파운드가 더해집니다.

구독료보다 카드 수수료가 더 중요합니다. Shopify Payments를 통한 온라인 카드 수수료는 Basic에서 2%에 25펜스, Grow에서 1.7%에 25펜스, Advanced에서 1.5%에 25펜스입니다. 대부분이 놓치는 항목은 Shopify Payments 이외의 게이트웨이를 쓸 때 부과되는 서드파티 결제 제공업체 수수료로, Basic 2%, Grow 1%, Advanced 0.6%, Plus 0.2%입니다.

이 수수료는 게이트웨이 자체 수수료 위에 얹힙니다. 연 매출 100만 파운드에 Advanced를 쓰면서 외부 매입사를 이용하는 쇼핑몰이라면, 서드파티 수수료만으로 연 6,000파운드, 삼 년이면 18,000파운드입니다. Shopify Payments를 쓰지 않는 대가입니다.

Shopify가 한계에 부딪히는 지점

한계는 공개되어 있고 구체적입니다. 변형 추가에 관한 Shopify 문서는 제품 하나당 옵션은 최대 세 개, 변형은 최대 2,048개까지이며, 둘 중 하나를 넘기면 서드파티 앱이나 라인 아이템 속성을 잡아내는 테마 코드가 필요하다고 명시합니다.

가장 먼저 걸리는 상한은 옵션 세 개입니다. 창호, 인쇄 패널, 맞춤 제작 블라인드, 구성된 기계는 서로 독립적인 선택지를 여섯 개나 여덟 개 갖는 것이 보통이고, 세 개를 넘어서는 순간 플랫폼은 당신의 제품을 모델링하기를 그만두고 근사하기 시작합니다.

두 번째 벽은 결제 화면입니다. 정보, 배송, 결제 단계를 위한 Shopify의 체크아웃 UI 확장은 Plus 요금제에서만 쓸 수 있습니다. Plus 미만에서는 결제 화면에 브랜드를 입힐 수는 있어도 로직을 끼워 넣을 수는 없고, 그래서 배송 시간대 선택, 거래 여신 확인, 필요한 시점의 규정 확인이 배제됩니다.

세 번째는 누적입니다. 모든 빈틈은 앱으로 메워지고, 앱은 하나같이 월 비용과 업그레이드 의존성을 동반하며, 앱 스무 개를 안은 쇼핑몰은 예전에 떠나온 그 유지보수 문제와 놀랍도록 닮은 것을 떠안게 됩니다.

WooCommerce의 장점과 힘겨워지는 지점

WooCommerce는 평소 받는 평가보다 더 공정한 대접을 받을 만합니다. 무료이고, 월 수십 파운드짜리 호스팅에서 돌아가며, 데이터는 당신 것이고, 확장 기능 목록은 전자상거래에서 압도적으로 가장 큽니다. 팀이 이미 WordPress를 아는 중소 규모 소비자용 쇼핑몰이라면 이것이 정답이자 가장 저렴한 답인 경우가 많습니다.

힘겨워지는 곳은 셋이고 모두 예측 가능합니다. 첫째는 데이터 모델입니다. 제품은 WordPress 게시물 타입이고 속성은 직렬화된 메타로 저장되므로, 속성이 많은 대형 카탈로그를 걸러내려면 진짜 컬럼이 아니라 키와 값 테이블을 조회하게 됩니다. 제품 1,000개에서는 견딜 만하고 5만 개에서는 고통스럽습니다.

둘째는 변형 개수에 따른 성능이며, WooCommerce 스토어가 느리게 느껴지는 가장 흔한 이유입니다. 그 원리는 WooCommerce 스토어가 느린 이유에서 자세히 다뤘고, 짧게 말하면 가변 상품은 행이 아니라 쿼리를 늘립니다.

셋째는 플러그인 난립입니다. WooCommerce는 무언가를 설치해서 문제를 풀기 때문에, 사 년이 지나면 그 스토어는 당신이 아니라 서른 개 업체의 릴리스 일정으로 정의됩니다.

복잡한 제품 모델링, 첫 번째 진짜 갈림길

Drupal Commerce에 가장 명확하게 들어맞는 경우는 고르는 제품이 아니라 구성하는 제품입니다. 재단비를 포함해 미터 단위로 파는 원단. 가로에 세로를 곱해 값이 정해지고 최저 요금이 있는 유리. 옵션 그룹이 여덟 개이고 그중 일부가 다른 것을 무효로 만드는 기계. 수량 구간 단가 곡선과 작업 건별 셋업 비용이 있는 인쇄물.

이 중 어느 것도 변형 표가 아닙니다. 호스팅형 플랫폼에서는 앱과 라인 아이템 속성 묶음으로 근사하게 되고, 그러면 고객에게 보이는 가격이 플랫폼 자체의 가격 로직 바깥에서 계산되어 언젠가는 대사해야 합니다.

Drupal Commerce에서는 가격이 당신이 쓴 코드로 해석됩니다. 가격 리졸버가 변형과 수량과 현재 컨텍스트를 받아 가격을 돌려줍니다. 여기에 특별한 것은 없지만, 이는 구성된 가격이 어디에서나 진짜 가격이 된다는 뜻입니다. 장바구니에서도, 주문에서도, 세금 계산에서도, ERP로 내보낼 때도 그렇습니다.

적용할 시험은 단순합니다. 카탈로그를 구매 가능한 것 하나당 한 줄인 스프레드시트로 쓸 수 있다면 이것은 필요 없습니다. 쓸 수 없다면 이 글의 나머지 전부가 관련됩니다.

B2B 가격, 가격표, 협상된 조건

두 번째 갈림길은 같은 SKU에 대해 두 고객이 서로 다른 가격을 보는 일이 있느냐입니다. 소비자용 쇼핑몰의 답은 없다입니다. 거래처 대상 사업의 답은 있다이고, 그 답이 대개 사업 그 자체입니다.

Shopify에도 B2B가 있고, B2B 요금제별 기능 문서는 Basic, Grow, Advanced, Plus에서 쓸 수 있음을 확인해 줍니다. 세부는 제한에 있습니다. Plus 미만에서는 모든 B2B 마켓을 합쳐 활성 카탈로그가 최대 세 개이고, 회사에 직접 연결된 카탈로그는 Plus 전용이며, 예치금과 분할 결제, 이행 건별 결제 요청도 Plus 전용입니다. 카탈로그 세 개는 가격 등급 세 단계에는 충분하고 협상된 마흔 개 거래처에는 쓸모가 없습니다.

Drupal 쪽에서 대응하는 것은 Commerce Price List 모듈로, 현재 8.x-2.16이고 보고된 설치 수는 약 1,662이며 보안팀의 관리 대상입니다. 사용자별 또는 역할별로 가격을 정하고, 수량 구간과 기간을 지원하며, CSV에서 가져올 수 있습니다.

실무에서 효과를 내는 것은 마지막 항목입니다. 각자 합의된 가격표를 가진 마흔 개 거래처를 두고 분기마다 ERP에서 갱신하는 도매업체에게, 그것은 플랫폼 이전이 아니라 CSV 가져오기 작업입니다.

하나의 코드베이스로 다중 스토어, 다중 통화, 다중 언어

Drupal Commerce에서 스토어는 일급 엔티티이고, 제품은 그것을 팔아도 되는 스토어에 배정됩니다. 작은 설계 결정이지만 결과는 큽니다. 여러 스토어프론트가 하나의 카탈로그, 하나의 주문 파이프라인, 하나의 관리 화면을 공유하면서도 각기 다른 통화, 세금 설정, 결제 게이트웨이, 배송 규칙을 가질 수 있습니다.

흔한 형태는 영국 사이트, EU 사이트, 거래처 포털을 하나의 배포에서 돌리는 것입니다. 제품 데이터 입력은 한 번뿐입니다. 가격표는 거래처 스토어에만 적용됩니다. 스토어가 자기 청구 국가와 등록 정보를 갖기 때문에 세금은 스토어별로 해석됩니다.

Drupal 코어는 언어별 URL 별칭, 번역된 엔티티, 대체 언어 링크를 갖춘 진짜로 강한 다국어 계층도 제공합니다. Drupal이 고등 교육과 공공 부문에서 존재감이 큰 이유가 여기에 있습니다.

Shopify Markets가 이제 이 중 상당 부분을 다루지만, Markets를 통한 맥락 기반 결제와 스토어프론트 커스터마이징은 Advanced와 Plus 요금제로 제한됩니다. 그래서 비교 대상은 월 25파운드가 아니라 최소 월 259파운드입니다.

카탈로그가 곧 편집 콘텐츠일 때

어떤 카탈로그는 콘텐츠 그 자체입니다. 제품 페이지에 구매 가이드, 비교표, 기술 해설, 리뷰어의 메모를 싣는 전문 소매업체는 결제도 받는 출판물을 운영하고 있는 것입니다.

호스팅형 플랫폼에서 그것은 두 개의 시스템입니다. CMS가 글을 갖고 쇼핑몰이 SKU를 가지며, 둘은 링크 하나와 야간 내보내기로 이어집니다. 편집자는 두 곳에서 일하고, 검색 색인은 두 번 만들어지며, URL 구조에는 한가운데로 이음매가 생깁니다.

Drupal Commerce에서 제품은 모든 글과 같은 시스템 안의 엔티티이므로 편집 워크플로, 리비전 이력, 분류 어휘, 미디어 라이브러리, 검색 색인, 접근 제어 모델을 함께 씁니다. 제품 페이지가 글 세 편을 참조할 수 있고 글 하나가 제품 아홉 개를 참조할 수 있으며, 둘 다 붙여 넣은 링크가 아니라 진짜 엔티티 참조입니다.

이것은 원래라면 Shopify로 충분했을 사업에 Drupal을 정당화하는 가장 흔한 논거이자, 편집 팀이 관리 화면 두 개를 오가며 일 년을 보내기 전까지는 있으면 좋은 것 정도로 치부되는 일이 가장 잦은 논거이기도 합니다.

규제 대상 제품과 속성이 많은 제품

규정 준수 데이터를 지닌 제품이 네 번째 경우입니다. 안전보건자료가 따라붙는 화학품. 인증서 번호와 유효기간을 갖는 의료기기. 알레르기 유발 물질 표를 갖는 식품. 적합성 선언서를 갖는 전기 제품. 배치 추적이나 판매 제한 표시가 필요한 모든 것입니다.

요구되는 것은 그 값을 저장하는 일만이 아닙니다. 검증하고, 버전을 남기고, 고객이 실제로 받은 배치에 맞는 것을 보여주고, 특정 날짜에 무엇이 공개되어 있었는지를 나중에 증명하는 일입니다. Drupal의 필드 API와 리비전 체계는 판촉이 아니라 콘텐츠 거버넌스를 위해 만들어졌기 때문에 이것을 해냅니다.

강제하는 쪽도 그만큼 중요합니다. 주문 프로세서는 연령 제한 상품을 금지된 국가로 보내게 될 결제나, 함께 운송해서는 안 되는 두 품목을 묶은 결제를 거부할 수 있습니다. 그것도 테마 템플릿이 아니라 주문 파이프라인 안에서 할 수 있습니다.

호스팅형 플랫폼에서는 그런 확인 하나하나가 앱이 되는데, 앱은 서로 조합되지 않습니다. 장바구니를 수정하는 앱이 둘이면 그 둘은 언젠가 어긋납니다.

ERP가 진실의 출처일 때

다섯 번째 경우는 구조적인 것입니다. 유통이나 제조 사업에서는 ERP가 재고, 가격, 고객 여신, 주문 상태를 소유하고, 웹사이트는 장바구니가 달린 표시면입니다. 문제는 쇼핑몰이 무엇을 할 수 있느냐가 아니라, 실제로 주도권을 쥔 시스템과의 일치를 얼마나 싸게 유지할 수 있느냐입니다.

Drupal Commerce가 여기서 편한 이유는 연동이 당신 자신의 프로세스 안에서 돌기 때문입니다. 큐 API가 비동기 작업을 맡고, 마이그레이트 API가 반복 가능하고 멱등한 가져오기를 맡으며, 건당 요금을 물리거나 동기화 시간을 조이는 중개자도 없습니다. 매일 밤 가격과 재고 20만 행을 가져오는 일은 크론 작업 하나입니다.

호스팅형 플랫폼에서는 같은 연동이 앱 구독이거나 미들웨어 구독이 되고, 플랫폼의 API 속도 제한은 사소한 세부가 아니라 설계로 우회해야 하는 아키텍처 제약이 됩니다. 그래도 굴러가고, 많은 사업에는 그것이 옳은 거래입니다. 옳지 않게 되는 때는 동기화가 크고 잦으면서 동시에 사업에 결정적일 때입니다.

쇼핑몰 자체보다 연동 작업이 프로젝트의 대부분을 차지한다면, 그것은 스토어프론트가 딸린 소프트웨어 개발 사업이며 처음부터 그렇게 범위를 잡아야 합니다.

세금은 호스팅형이 더 이상 싸지 않은 지점

세금은 국경을 넘는 전자상거래의 조용한 비용 센터이고, 월 구독료 비교가 오해를 부르기 시작하는 지점입니다. 두 개의 기준선이 대부분을 결정합니다.

영국 VAT 등록선

GOV.UK의 VAT 등록 시점 안내는 과세 대상 매출 합계 90,000파운드를 기준선으로 둡니다. 등록을 촉발하는 시험은 둘입니다. 하나는 최근 십이 개월 롤링 시험으로, 매출이 90,000파운드를 넘긴 달의 말일부터 30일 안에 등록해야 합니다. 다른 하나는 미래 예측 시험으로, 앞으로 30일 안에 매출이 90,000파운드를 넘으리라는 것을 깨달은 즉시 등록해야 합니다.

성장하는 쇼핑몰을 붙잡는 것은 미래 예측 시험 쪽입니다. 등록일이 돈이 들어온 날이 아니라 깨달은 날이기 때문입니다.

EU VAT와 원스톱 숍

유럽연합 집행위원회의 과세지 안내는 역내 물품 원격 판매와 통신, 방송, 전자적 서비스를 합쳐 연간 합계 기준선을 10,000유로로 정합니다. 그 아래에서는 과세지가 발송이나 운송이 시작되는 곳입니다. 그 위에서는 과세가 운송이 끝나는 곳, 즉 고객 국가의 세율로 옮겨 갑니다.

원스톱 숍을 쓰면 그 전부를 한 회원국에서 한 장의 신고서로 처리할 수 있고, 제출은 분기마다이며 기한은 4월, 7월, 10월, 1월의 말일입니다. 수입 원스톱 숍은 EU 밖에서 수입되며 한 건의 가액이 150유로를 넘지 않는 화물을 다룹니다.

Drupal Commerce가 기본으로 하는 일

Commerce는 유럽연합 VAT 세금 플러그인을 부가 상품이 아니라 코어에 담아 배포합니다. 27개 회원국과 모나코의 세율을 담고 있고, 표준, 경감, 중간, 초경감, 영세율을 구분하며, 단일 세율표가 걸려 넘어지는 특별 영역까지 다룹니다. 코르시카, 아조레스, 마데이라, 그리스 도서 지역, 오스트리아의 월경지 융홀츠 등입니다.

세율만이 아니라 규칙도 적용합니다. 디지털 상품에 대한 도착지 과세, 그리고 유효한 세금 번호가 제시된 경우 역내 기업 간 공급에 대한 영세율입니다. 호스팅형 플랫폼에서 그 동작은 대개 거래 건당 비용이 붙는 앱입니다.

결제, PCI DSS, 그리고 카드를 받는 방식

카드 번호를 어떻게 수집하느냐가 규정 준수 부담을 결정하는데, 그 규칙이 최근 널리 오해되는 방식으로 바뀌었습니다.

PCI 보안 표준 협의회의 SAQ A 적격 요건 해설은 2025년 4월 1일부터 발효된 요건을 설명합니다. 가맹점은 자사 사이트가 가맹점의 전자상거래 시스템에 영향을 줄 수 있는 스크립트 공격에 취약하지 않다는 점을 확인해야 하며, 이는 PCI DSS 요구사항 6.4.3과 11.6.1의 기법을 구현하거나, 결제 제공업체로부터 그 임베드 방식에 해당 보호가 포함되어 있다는 확인을 받아 충족합니다.

사람들이 잘못 짚는 부분이 바로 그 적용 범위입니다. 이 요건은 자사 페이지에 제공업체의 결제 폼을 대개 iframe으로 임베드한 가맹점에만 적용됩니다. 협의회는 HTTP 리다이렉트든 메타 리프레시든 JavaScript든 고객을 제공업체 쪽으로 넘기는 가맹점에는 적용되지 않는다고 명시하며, 결제 기능을 전부 외부에 위탁한 가맹점에도 적용되지 않는다고 밝힙니다.

그래서 호스팅형 리다이렉트는 노출면을 작게 유지합니다. 전환이 더 잘 되고 사실상 모두가 실제로 원하는 임베드형 입력란은, 결제 페이지에서 도는 모든 스크립트의 무결성을 당신의 규정 준수 논의 안으로 끌고 들어옵니다.

Shopify의 진짜 강점은 여기에 있습니다. 결제 화면이 그들 것이고 그 위의 스크립트도 그들 것이기 때문입니다. Drupal Commerce에서는 결제 화면이 당신 것이므로 답을 설계해 내야 합니다. 엄격한 콘텐츠 보안 정책, 하위 리소스 무결성, 결제 페이지에서 실행되는 모든 스크립트의 목록, 그리고 그중 하나가 바뀌었을 때의 탐지입니다. 이 작업은 어렵지도 않고 선택 사항도 아니며, 감사 도중에 발견될 것이 아니라 예산에 들어가 있어야 합니다.

접근성은 법적 위험이자 상업적 위험

전자상거래의 접근성 결함은 결제 화면에 몰려 있는데, 그곳은 모든 결함이 곧바로 돈으로 이어지는 자리이기도 합니다.

참고할 기준은 2024년 12월 12일에 공개된 W3C 권고안 WCAG 2.2입니다. 쇼핑몰에서 실제로 물리는 성공 기준은 구체적입니다. AA 등급의 1.3.5 입력 목적 식별은 주소와 카드 입력란의 자동 완성과 관련됩니다. A 등급의 3.3.7 중복 입력은 결제 단계에서 배송 주소를 다시 입력하게 하는 결제 흐름이 매번 위반하는 기준입니다. AA 등급의 3.3.8 접근 가능한 인증은 계정 생성과 로그인을 다룹니다. AA 등급의 2.5.8 대상 크기는 수량 증감 컨트롤과 장바구니에서 빼는 버튼을 잡아내고, AA 등급의 1.4.3 명도 대비는 실제로는 눌리는데 회색으로 비활성처럼 보이는 버튼을 잡아냅니다.

주문 자체를 둘러싼 것이 둘 더 있습니다. A 등급의 3.3.1 오류 식별, 그리고 AA 등급의 3.3.4 법률적, 금전적, 데이터 거래에 대한 오류 방지이며, 뒤엣것은 정확히 주문을 넣는 행위에 관한 것입니다.

영국의 법적 상황은 자주 과장됩니다. 민간 소매업체가 WCAG 준수 수준을 명시한 제정법에 매여 있는 것은 아닙니다. 적용되는 것은 2010년 평등법 제20조가 정한 의무, 즉 보조 수단 제공을 포함해 장애인이 실질적으로 불리해지지 않도록 합리적인 조치를 취할 의무입니다. 준수 수준을 명시한 규정, 곧 2018년 공공기관 웹사이트 및 모바일 애플리케이션 접근성 규정(제2호)은 쇼핑몰이 아니라 공공 기관에 적용됩니다.

상업적 논점이 법적 논점보다 더 날카롭습니다. 호스팅형 테마에서는 앱이 결제 화면에 집어넣은 것을 늘 고칠 수 있는 것은 아닙니다. 당신이 통제하는 플랫폼에서는 고칠 수 있습니다.

삼 년 동안 실제로 드는 비용

사람들이 흔히 하는 비교는 월 구독료 대 월 호스팅비인데, 그것은 표에서 가장 덜 중요한 줄입니다. 지배적인 것은 구축비와 유지보수비이고, 거래액이 커지면 결제 수수료율이 지배합니다.

아래 구간은 영국 중견 시장 쇼핑몰에 대한 Mecanik의 내부 추정치입니다. 다만 Shopify의 구독료와 수수료 숫자만은 Shopify가 공개한 그대로의 파운드 표시입니다. 나머지는 우리가 제시할 만한 금액이며, 각 줄 안의 폭이 낮은 쪽에서의 플랫폼 간 차이보다 넓습니다.

표의 각 줄이 실제로 사는 것

말로 풀어 보겠습니다. Shopify Advanced는 연 단위로 약정하느냐에 따라 삼 년 구독료가 9,324에서 12,384파운드가 되고 호스팅을 포함하지만, 같은 기간에 현실적으로 5,400에서 14,400파운드의 앱 구독이 더해집니다. WooCommerce는 플랫폼에는 한 푼도 쓰지 않고 호스팅에 3,600에서 14,400파운드를 쓰며, 확장 기능은 삼 년에 3,000에서 9,000파운드입니다. Drupal Commerce는 라이선스 비용이 없고, 셋 중 가장 무거운 애플리케이션이라 호스팅에 가장 많은 5,400에서 21,600파운드를 쓰며, 부가 기능에는 가장 적게 0에서 3,000파운드쯤 씁니다. 대응되는 기능이 상용이 아니라 기여 모듈이기 때문입니다.

플랫폼이 갈리는 곳은 구축비입니다. Shopify에서 8,000에서 25,000파운드짜리 구축은 테마를 입히고 표준 연동을 붙인 스토어를 사는 것이고, WooCommerce에서는 10,000에서 35,000파운드입니다. 같은 요구사항을 Drupal Commerce에서 만들면 35,000에서 120,000파운드입니다. 결제, 가격 로직, 연동이 모두 설정이 아니라 작성되기 때문입니다. 유지보수도 같은 모양이라 연간으로 Shopify가 3,000에서 9,000파운드, WooCommerce가 4,000에서 12,000파운드, Drupal Commerce가 12,000에서 30,000파운드이며, 이는 Drupal 개발자 단가 안내서에서 다룬 대략 600에서 900파운드의 영국 에이전시 일당을 반영합니다.

삼 년 합계가 어디에 떨어지는가

삼 년 합계는 Shopify가 대략 32,000에서 79,000파운드, WooCommerce가 29,000에서 94,000파운드, Drupal Commerce가 76,000에서 235,000파운드에 떨어집니다. 카드와 게이트웨이 수수료는 이 셋 모두 위에 얹히고 거래액에 따라 커집니다. 그래서 Advanced에서 0.6%인 Shopify의 서드파티 게이트웨이 수수료가 연 매출 100만 파운드 쇼핑몰에서 삼 년간 18,000파운드의 무게를 갖습니다.

표를 정직하게 읽으면 Drupal Commerce는 두세 배의 비용입니다. 그것이 정당화되는 것은 대안이 실제로는 존재하지 않을 때뿐이며, 그것이 앞선 다섯 절 전부의 요점입니다.

헤드리스와 디커플드 Drupal Commerce

Drupal Commerce를 분리하는 것은 좁은 범위의 경우에는 진짜 요구사항이고 나머지 대부분에서는 유행입니다. 정직한 시험은 웹사이트가 아닌 무언가가 같은 카탈로그를 필요로 하는가입니다.

진짜 요구사항이 되는 때는 네이티브 모바일 앱과 웹사이트가 하나의 제품 및 가격 모델을 공유해야 할 때, 다른 팀이 만든 기존 프런트엔드를 교체하지 않을 때, POS 단말이나 키오스크가 같은 장바구니를 쓸 때, 또는 디자인 시스템이 프로젝트 밖에서 관리되어 Twig로 표현할 수 없을 때입니다. 그런 경우에는 API가 제품이고 CMS는 의도적으로 보이지 않게 됩니다.

유행인 때는 이유로 성능이 제시될 때입니다. 캐시가 잘 된 전통적인 Drupal 프런트엔드는 익명 사용자의 제품 페이지를 엣지에서 내보내고, 쇼핑몰을 느리게 만드는 원인이 렌더링 방식인 경우는 드뭅니다.

비용은 한 곳에 몰립니다. Drupal 코어는 설정 없이 JSON:API로 콘텐츠를 공개하고 Commerce Cart API 모듈이 장바구니를 REST 인터페이스 뒤에 두므로, 카탈로그를 읽고 장바구니를 만드는 일은 거의 공짜입니다. 결제는 그렇지 않습니다. 주소 처리, 세금 표시, 배송 선택, 프로모션, 결제 요소 연동, 주문 확인을 모두 프런트엔드에서 다시 만들어야 하고, 그것이 보통 전체 구축의 40% 이상을 차지합니다.

오 분 결정 규칙

당신의 카탈로그에 대해 여섯 가지 질문에 답해 보십시오. 그렇다 하나가 1점입니다.

옵션이 세 개를 넘거나 구매 가능한 조합이 2,048개를 넘는 제품이 있습니까? 서로 다른 두 고객이 같은 SKU에 다른 값을 내는 일이 있습니까? VAT 처리가 다른 둘 이상의 국가에 판매하거나 OSS 신고를 하게 될 것 같습니까? 카탈로그가 같은 팀이 쓰고 관리하는 편집 콘텐츠이기도 합니까? 가격과 재고의 권위가 ERP나 PIM이고 쇼핑몰이 그 하류에 있습니까? 결제 화면에 브랜드만 입히는 것이 아니라 자체 로직을 끼워 넣어야 합니까?

0점이나 1점이면 Shopify를 고르십시오. 이 글에서 설명한 이점은 당신에게 해당되지 않고, 지금 빌려 쓰는 것을 다시 만드느라 돈을 내게 됩니다.

2점이면 결정은 정말로 열려 있고, 팀이 이미 WordPress를 운영한다면 특히 WooCommerce가 더 나은 중간 경로인 경우가 많습니다.

3점 이상이면 Drupal Commerce를 제대로 견적 낼 가치가 있습니다. 다른 곳에서 필요해질 우회 방법이 삼 년이면 플랫폼보다 비싸지기 때문입니다. 5점이나 6점이면 호스팅형 플랫폼은 더 싼 선택지가 아니라, 그 일을 해내지 못하는 다른 제품입니다.

Drupal Commerce 프로젝트가 흔히 잘못되는 곳

가장 흔한 실패는 잘못된 이유로 그것을 고르는 것입니다. 우리는 이미 Drupal을 쓴다는 말은 커머스 요구사항이 아닙니다. 콘텐츠 사이트와 거래 사이트는 요구되는 가동률도, 테스트도, 배포가 잘못됐을 때의 결과도 다릅니다. 쇼핑몰을 기존 사이트의 또 하나의 섹션처럼 다루는 것이, 작은 전자상거래 프로젝트가 계획에 없던 플랫폼 팀을 떠안게 되는 경로입니다.

둘째는 유지보수를 적게 잡는 것입니다. 설치 35,870이라는 생태계는 유지보수자가 몇 명뿐인 모듈을 쓰게 될 만큼 작고, 보안 권고를 지켜보며 업데이트를 잡아 줄 사람이 당신 쪽에 있어야 합니다. 그 일을 맡은 사람이 없는 Drupal Commerce 사이트는 시간차를 둔 보안 사고이며, 이 점은 Drupal이 실제로 요구하는 호스팅 조건과 함께 더 자세히 다룹니다.

셋째는 모듈이 있으리라 가정하는 것입니다. 범위를 잡기 전에 확인하십시오. 없다면 그 작업은 맞춤 웹사이트 개발 과제이고, 항목 한 줄이 아니라 진짜 견적이 필요합니다.

넷째는 메이저 버전 규율입니다. Commerce 3은 Drupal 10.3 이상을 요구하고, 코어에서 뒤처진 사이트는 결국 커머스 모듈이 먼저 앞서가 버렸음을 알게 됩니다. 2026년 Drupal 개발 안내서와 이전 비용과 기한을 다룬 글이 모두 그 주기를 깊이 들여다봅니다.

결정을 제대로 내리기

선택을 결정하는 것은 제품과 가격 책정의 복잡도이지 트래픽이나 매출이나 취향이 아닙니다. 먼저 카탈로그를 종이 위에서 모델링하십시오. 모든 옵션, 모든 협상 가격, 그리고 다른 시스템과 일치를 유지해야 하는 모든 연동을 포함해서 말입니다. 그 모델이 변형 표에 들어간다면 호스팅형 플랫폼을 사고, 아낀 예산을 상품 기획에 쓰십시오.

Mecanik은 두 종류의 스토어를 모두 만들고 유지보수하며, 견적을 내기 전에 당신이 이 선의 어느 쪽에 있는지 먼저 말씀드립니다. 답이 Drupal Commerce라면 그 일은 상당한 연동 요소를 포함한 웹사이트 개발 사업입니다. ERP 쪽 작업이 스토어프론트를 넘어선다면 그것은 소프트웨어 개발에 속합니다. 답이 Shopify라면 그렇게 말씀드리겠고, 재구축이 열여덟 달 진행된 뒤보다 지금 말씀드리는 편이 낫다고 봅니다.

자주 묻는 질문

Drupal Commerce가 Shopify보다 나은가요? 대부분의 쇼핑몰에는 그렇지 않습니다. Shopify는 삼 년으로 보면 더 저렴하고 PCI 준수와 호스팅을 대신 처리하며, 어떤 에이전시도 따라갈 수 없는 규모로 검증된 결제 흐름을 갖추고 있습니다. Drupal Commerce가 이기는 경우는 좁습니다. 옵션이 세 개를 넘거나 변형이 2,048개를 넘는 제품, 고객별 협상 가격, 편집 콘텐츠이기도 한 카탈로그, 그리고 ERP가 가격과 재고를 소유하는 쇼핑몰입니다.

영국에서 Drupal Commerce 구축 비용은 얼마인가요? 초기 구축에 35,000에서 120,000파운드, 유지보수에 연 12,000에서 30,000파운드를 예상하십시오. 영국 에이전시 일당은 대략 600에서 900파운드입니다. 삼 년이면 Drupal Commerce 쇼핑몰은 호스팅을 포함해 보통 76,000에서 235,000파운드에 들어오고, Shopify Advanced는 대략 32,000에서 79,000파운드입니다. 이는 내부 추정치이지 견적이 아닙니다.

어떤 버전의 Drupal Commerce를 써야 하나요? Drupal Commerce 3이며, 현재는 2026년 7월 17일에 공개된 3.3.8입니다. Drupal 10.3 이상과 Drupal 11에서 동작하고, 안정 릴리스는 Drupal 보안 권고 정책의 적용을 받습니다. Commerce 2는 Drupal 9와 10을 지원한 이전 릴리스 주기이므로 새 프로젝트는 3.x에서 시작해야 합니다.

Drupal Commerce가 EU VAT와 OSS를 처리하나요? 세금 규칙은 부가 상품으로 팔리는 것이 아니라 Commerce 코어에 내장되어 있습니다. 유럽연합 VAT 플러그인은 27개 회원국과 모나코의 세율을 담고, 표준과 경감, 중간, 초경감, 영세율을 구분하며, 특별 영역을 다루고, 디지털 상품에 도착지 과세를 적용하며, 유효한 세금 번호에 대해 역내 B2B 공급을 영세율로 처리합니다. OSS 신고서 제출은 여전히 회계 업무로 남습니다.

헤드리스 Drupal Commerce는 언제 가치가 있나요? 웹사이트가 아닌 무언가가 같은 카탈로그를 쓸 때입니다. 네이티브 앱, POS 단말, 또는 다른 팀이 소유한 프런트엔드 같은 경우입니다. 속도만을 위해서라면 가치가 없습니다. 캐시된 전통적 프런트엔드는 이미 충분히 빠르기 때문입니다. 결제 화면을 다시 만드는 비용을 예산에 넣으십시오. 디커플드 구축에서 보통 40% 이상을 차지합니다.