기성 템플릿처럼 보이지 않는 맞춤형 스토어프론트에서 쇼핑한 적이 있다면, 그 뒤에는 헤드리스 커머스 API가 작동했을 가능성이 높습니다. 헤드리스 커머스 API는 커머스 백엔드가 노출하는 인터페이스로, 모든 스토어프론트가 내장된 테마에 얽매이지 않고 제품을 읽고, 장바구니를 만들고, 주문할 수 있게 해줍니다. 이 설명서는 그것이 무엇을 의미하는지, 컴포저블 커머스 및 MACH와 어떻게 관련되는지, 그리고 스토어프론트 및 파트너 팀이 왜 이 API 계약에 따라 성패가 갈리는지에 대해 다룹니다. 이는 소프트웨어가 헤드리스화되고 있으며, 이제 API가 곧 제품이라는 아이디어를 기반으로 합니다.
커머스에서 "헤드리스"란 무엇인가
기존 커머스 플랫폼은 하나의 덩어리로 제공됩니다. 제품 카탈로그, 장바구니, 결제 및 이를 렌더링하는 HTML 페이지는 모두 동일한 시스템에 있습니다. 테마를 적용하고, 조정하고, 출시하는 식입니다.
헤드리스 커머스는 이를 두 가지로 나눕니다. 종종 커머스 엔진이라고 불리는 백엔드는 카탈로그, 가격, 재고, 장바구니 및 주문 로직을 유지합니다. 프런트엔드, 즉 스토어프론트는 원하는 방식으로 구축하는 별도의 앱이 됩니다. 이들을 연결하는 유일한 것은 API입니다.
따라서 "머리(head)"는 프레젠테이션 계층입니다. 헤드리스로 전환한다는 것은 고정된 머리를 제거하고 대신 API를 통해 본문, 즉 커머스 로직을 노출하는 것을 의미합니다. React 사이트, 네이티브 모바일 앱, 스마트 냉장고 화면 또는 음성 비서 모두 동일한 API를 사용하기 때문에 동일한 백엔드와 통신할 수 있습니다.
이러한 분리가 핵심입니다. 프런트엔드 팀은 자체 프레임워크를 선택하고 자체 일정에 따라 출시합니다. 백엔드 팀은 커머스 규칙을 소유합니다. API는 그들 사이의 경계선입니다.
단점은 더 많은 작업을 맡아야 한다는 것입니다. 기존 플랫폼은 즉시 작동하는 상점을 제공합니다. 헤드리스로 전환한다는 것은 스토어프론트를 직접 구축하고 호스팅해야 하므로 유연성에는 엔지니어링 비용이 따릅니다. 팀은 기성 테마가 필요한 경험을 제공할 수 없거나 단일 백엔드에서 여러 채널에 서비스를 제공하려 할 때 헤드리스를 선택합니다.
헤드리스 vs 컴포저블 vs MACH
이 세 가지 용어는 서로 바꿔가며 사용되지만, 서로 다른 범위를 설명합니다. 솔직한 분석은 다음과 같습니다.
| 용어 | 설명 | 범위 |
|---|---|---|
| 헤드리스 커머스 | 하나의 커머스 백엔드로부터 프런트엔드가 분리되고 API로 연결됨 | 하나의 백엔드, 하나 또는 여러 개의 프런트엔드 |
| 컴포저블 커머스 | 전체 스택이 교체 가능한 최상의 서비스(카탈로그, 검색, 결제, PIM, OMS)로 분리됨 | 여러 독립적인 서비스가 함께 조립됨 |
| MACH | 컴포저블 스택이 따르는 경향이 있는 아키텍처 원칙 집합 | 제품이 아닌 철학 |
헤드리스는 좁은 경우입니다. 스토어프론트가 API를 통해 통신하는 한, 하나의 모놀리식 백엔드로도 헤드리스가 될 수 있습니다.
컴포저블 커머스는 더 나아갑니다. 하나의 백엔드 대신, 독립적인 서비스를 조합하고 각 작업에 가장 적합한 도구를 선택합니다. 한 공급업체에서 검색을, 다른 공급업체에서 결제를, 별도의 제품 정보 관리자를 사용합니다. 각 서비스는 자체 API를 가진 독립적인 서비스이며, 이를 조합하여 하나의 경험을 만듭니다.
MACH는 대부분의 컴포저블 스택 뒤에 있는 원칙 집합입니다. 2020년에 설립된 산업 그룹인 MACH Alliance에 따르면, MACH는 마이크로서비스(Microservices), API-퍼스트(API-first), 클라우드 네이티브 SaaS(Cloud-native SaaS), 그리고 헤드리스(Headless)를 의미합니다. API-퍼스트가 바로 중앙에 위치한다는 점에 주목하세요. MACH 세계에서 API는 부가 기능이 아닙니다. API는 각 부분이 서로 통신하는 유일한 방법이며, 이는 API를 제품으로 취급하는 것과 동일한 이유입니다.
헤드리스 커머스 API가 실제로 노출하는 것
정확한 형태는 플랫폼에 따라 다르지만, 대부분의 헤드리스 커머스 API는 동일한 핵심 작업을 다룹니다.
- 카탈로그 및 제품. 스토어프론트가 목록 및 상세 페이지를 렌더링할 수 있도록 제품, 변형, 컬렉션 및 미디어를 읽습니다.
- 검색 및 탐색. 카탈로그를 쿼리하고, 필터링하며, 정렬합니다.
- 장바구니 및 결제. 장바구니를 생성하고, 품목을 추가 및 제거하며, 할인을 적용하고, 결제 단계로 진행합니다.
- 고객. 로그인하고, 계정을 관리하며, 주문 내역을 추적합니다.
- 재고 및 가격. 재고 수준과 올바른 상황에 맞는 가격을 표시합니다.
일부 플랫폼은 이를 고객 대면 스토어프론트 API와 백오피스 작업을 위한 별도의 관리 API로 나눕니다. 스토어프론트 API는 읽기 위주이며 고객 대면용입니다. 관리 API는 카탈로그 편집, 주문 관리 및 구성을 처리합니다.
프로토콜도 중요합니다. 많은 헤드리스 커머스 API는 GraphQL인데, 이는 스토어프론트가 한 번의 왕복으로 필요한 필드만 정확히 요청할 수 있게 해줍니다. 다른 API는 REST이며, 일부 플랫폼은 둘 다 제공합니다. 장단점을 고려하고 있다면 REST vs GraphQL을 참조하세요.
주요 플랫폼
헤드리스 커머스 분야는 대략 SaaS 엔진과 오픈 소스 엔진으로 나뉩니다. 몇 가지 익숙한 이름은 다음과 같습니다.
- commercetools. MACH Alliance의 창립 회원이며 가장 많이 언급되는 컴포저블 커머스 플랫폼 중 하나입니다. 설계부터 API-퍼스트 및 클라우드 네이티브입니다.
- Shopify. Storefront API를 통해 헤드리스 빌드를 제공하며, 이를 활용하기 위한 React 프레임워크로 Hydrogen을 사용합니다. Shopify를 이미 사용하고 있다면, 저희 Shopify API 튜토리얼이 좋은 시작점이 될 것입니다.
- BigCommerce. 카탈로그 위에 GraphQL Storefront 및 Checkout API를 사용하여 헤드리스 모드를 지원합니다. BigCommerce API 사용 가이드를 참조하십시오.
- Saleor. Python과 Django를 기반으로 구축된 오픈 소스, GraphQL-퍼스트 엔진입니다.
- Medusa. Node.js와 TypeScript를 기반으로 구축된 오픈 소스 엔진으로, 백엔드 전체 제어를 원하는 JavaScript 팀에게 인기가 많습니다.
가격, 호스팅 모델 및 API 범위는 변경될 수 있으므로 커밋하기 전에 플랫폼별 세부 정보를 확인하십시오. 모든 플랫폼의 패턴은 동일합니다. 엔진은 API를 통해 커머스 로직을 노출하고, 여러분은 헤드를 구축합니다.
팀이 커머스 API 계약에 의존하는 이유
스토어프론트가 분리되면 API는 단순한 파이프 역할을 멈추고 모두가 따르는 약속이 됩니다. 여기서 헤드리스의 진정한 의미가 나타납니다.
프런트엔드 팀은 제품 응답의 정확한 형태를 알기 전까지는 제품 페이지를 출시할 수 없습니다. 파트너 통합(로열티 앱, 세금 서비스, 마켓플레이스 피드)은 모두 동일한 엔드포인트에 연결됩니다. 모바일 팀은 웹 팀과 동일한 계약을 사용합니다. 경고 없이 응답 형태가 변경되면, 해당 소비자 모두가 한 번에 오류를 겪을 수 있습니다.
그것이 바로 위험이자 기회입니다. 명확하고 안정적이며 잘 문서화된 커머스 API 계약은 독립적인 팀들이 서로 방해하지 않고 빠르게 움직일 수 있도록 합니다. 모호하거나 불안정한 계약은 모든 릴리스를 혼란스러운 조정 작업으로 만듭니다. 계약 자체가 제품이므로, 계약 테스트를 포함하여 스토어프론트 자체와 동일한 수준의 주의를 기울여야 하며, 이는 출시 전에 파괴적 변경을 잡아내는 데 도움이 됩니다.
버전 관리도 이 계약의 일부입니다. 제품 응답을 변경하거나 필드 이름을 바꿔야 할 때, 단순히 엔드포인트를 편집하고 잘 되기를 바랄 수는 없습니다. 제어할 수 없는 소비자들이 이를 사용하고 있기 때문입니다. 따라서 헤드리스 팀은 계약을 공개적인 약속으로 간주합니다. 가능한 한 추가적인 변경을 하고, 명확한 사용 중단 기간을 두며, 파트너 통합에 도달하기 전에 문제가 될 수 있는 모든 것을 표시하는 테스트를 수행합니다.
Apidog의 역할
Apidog는 상점을 운영하지 않습니다. Apidog는 커머스 엔진, CMS 또는 게이트웨이가 아니며, 스택을 헤드리스 또는 컴포저블로 만들지 않습니다. Apidog가 하는 일은 이 모든 것의 API-퍼스트 기둥을 책임지는 것입니다. 즉, 다른 모든 것이 의존하는 계약을 설계하고, 테스트하고, 목업하고, 문서화하는 계층입니다.
이는 헤드리스 커머스 작업과 깔끔하게 연결됩니다.
- 계약을 먼저 설계합니다. 코드가 존재하기 전에 Apidog에서 스토어프론트 또는 관리 API를 OpenAPI 스펙으로 모델링하여 프런트엔드와 백엔드가 미리 형태에 동의하도록 합니다.
- 백엔드가 준비되기 전에 목업합니다. 스펙에서 목업 서버를 시작하여 커머스 엔진이 아직 연결 중인 동안 스토어프론트 팀이 실제와 같은 제품 및 장바구니 응답에 대해 구축하도록 합니다. 이는 분리 약속을 실용적으로 만든 것이며, 자세한 내용은 목업 API 설명서에서 확인할 수 있습니다.
- CI에서 계약을 테스트합니다. Apidog CLI는 GUI 없이 API 테스트를 실행하며, 파이프라인에 적합한 헤드리스 테스트 실행을 제공합니다. 이는 헤드리스 커머스와의 진정한 개념적 일치입니다. 프런트엔드가 필요 없이 계약만 검증됩니다.
- 파트너를 위해 문서화합니다. 자동 생성된 대화형 문서는 스토어프론트 및 파트너 팀에게 통합하려는 API에 대한 단일 진실의 원천을 제공합니다.
API가 유일한 인터페이스가 될 때 이것이 왜 중요한지에 대한 더 깊은 내용은 소프트웨어가 헤드리스화되고 있으며, 이제 API가 곧 제품을 참조하십시오. 워크플로우를 시도해 보려면 Apidog를 다운로드하고 기존 스펙을 가져오십시오.
자주 묻는 질문
헤드리스 커머스는 컴포저블 커머스와 동일한가요?
아닙니다. 헤드리스 커머스는 API를 통해 스토어프론트를 하나의 커머스 백엔드로부터 분리합니다. 컴포저블 커머스는 더 나아가 각각 자체 API를 가진 여러 독립적인 최상의 서비스를 하나의 경험으로 조합합니다. 모든 컴포저블 스택은 헤드리스이지만, 하나의 모놀리식 백엔드를 사용하는 헤드리스 설정이 반드시 컴포저블인 것은 아닙니다.
헤드리스 커머스 API에 GraphQL이 필요한가요?
아닙니다. GraphQL은 스토어프론트가 한 번의 호출로 필요한 필드만 정확히 요청할 수 있게 해주어 제품 및 장바구니 렌더링에 적합하기 때문에 흔히 사용됩니다. 그러나 많은 헤드리스 커머스 API는 REST를 사용하며, 일부 플랫폼은 둘 다 제공합니다. 프로토콜 자체보다 계약이 안정적이고 문서화되어 있는지가 더 중요합니다.
백엔드가 구축되기 전에 헤드리스 커머스 API를 테스트할 수 있나요?
네, 가능하며 이것이 디자인-퍼스트 접근 방식을 선택하는 주요 이유 중 하나입니다. API 계약을 스펙으로 모델링하면 실제와 같은 응답을 반환하는 목업 서버를 생성할 수 있습니다. 커머스 엔진이 아직 개발 중인 동안 스토어프론트 팀은 목업에 대해 구축하고 테스트한 다음, 나중에 실제 엔드포인트로 전환합니다.
MACH Alliance는 무엇인가요?
MACH Alliance는 2020년에 설립된 산업 그룹으로, 마이크로서비스, API-퍼스트, 클라우드 네이티브 SaaS 및 헤드리스 원칙을 기반으로 구축된 개방적이고 최상의 기술 스택을 홍보합니다. commercetools와 같은 공급업체가 창립 회원입니다. MACH는 구매하는 단일 제품이 아니라 아키텍처 원칙의 집합입니다.
계약이 곧 상점입니다
헤드리스 커머스는 가치를 테마에서 API로 옮깁니다. 스토어프론트가 분리되면, 커머스 API는 프런트엔드, 모바일, 파트너 팀이 실제로 구축하는 기반이 됩니다. 컴포저블 커머스와 MACH는 API-퍼스트를 선택 사항이 아닌 핵심 원칙으로 만들어 이를 더욱 발전시킵니다.
이 모든 것이 Apidog에 의존하는 것은 아니지만, 계약의 품질은 이를 설계, 목업, 테스트 및 문서화할 수 있는 공간으로부터 이점을 얻습니다. 헤드리스 프로젝트가 그 방향으로 향하고 있다면, Apidog는 그 아래 커머스 엔진인 척하지 않으면서 해당 계층을 제공합니다.