헤드리스 상거래의 더러운 비밀: 일부 공급업체가 의도적으로 말하지 않는 것

헤드리스 상거래 솔루션의 더러운 비밀: 일부 공급업체가 (의도적으로) 말하지 않는 것은 비용이 많이 들 수 있습니다.

헤드리스 커머스, 간단히 말해서 "헤드리스"는 현재 B2C 세계에서 가장 사랑받는 기술입니다. Google 트렌드에 따르면 헤드리스 상거래에 대한 검색 요청은 2020년 초부터 기하급수적으로 증가했습니다. 전자 상거래 관점에서 보면 그 이유를 쉽게 알 수 있습니다.

소비자들은 전염병 동안 소셜 미디어 피드에 묶여 집에 갇혔습니다. D2C(Direct-to-Consumer) 브랜드는 Instagram, TikTok 또는 Facebook과 같은 미디어를 활용하여 의도한 잠재고객에게 제품을 바로 전달할 수 있습니다. 헤드리스 상거래 솔루션은 간단합니다.

헤드리스 아키텍처는 뛰어난 유연성을 제공합니다. 프론트엔드와 백엔드(및 API의 가용성)의 분리로 인해 헤드리스를 지원하는 플랫폼을 사용하여 새로운 채널에 상거래를 배포하려는 조직이 훨씬 더 쉽습니다.

헤드리스 상거래 솔루션은 또한 프런트엔드와 백엔드가 별도로 배포되므로 더 큰 민첩성을 제공합니다. 민첩성이 비즈니스 차별화 요소가 되면서 헤드리스에 대한 관심이 급증하고 있습니다.

헤드리스 커머스 솔루션: 과대 광고 제거

그러나 헤드리스 커머스가 정확히 무엇입니까? 기술 및 마케팅 분야에서 흔히 볼 수 있는 것처럼 최근 유행하는 유행어(몇 년 전 빅 데이터 또는 인공 지능/머신 러닝을 떠올려 보세요)에 집착하여 가능한 한 많은 대화에 삽입하는 경향이 있습니다. .

그러나 사람들이 사물이 무엇인지 정말로 정의할 수 없을 때, 그 사물 주변의 물은 꽤 탁해지는 경향이 있습니다. 이것이 바로 헤드리스 커머스에서 일어나고 있는 일입니다.

우리는 마케터에게 너무 가혹할 수 없습니다. 물을 더럽히는 것은 그들만이 아닙니다. 많은 공급업체가 의도적이든 아니든 헤드리스, 클라우드, API 및 마이크로서비스를 결합하여 혼합에 추가하고 있습니다. 그들에게는 의제가 있으므로 이러한 것들 사이의 경계를 흐리게 하는 것이 그들에게 유리합니다. 그리고 분명히 말해서, 그들 중 어느 것도 동일하지 않습니다.

간단히 말해서 헤드리스 커머스는 다음을 의미합니다.

1. 프론트엔드/스토어프론트/유리는 상거래 엔진(즉, 백엔드)에서 분리됩니다.
2. 분리되어 있기 때문에 API 호출을 통한 가격 책정 및 프로모션과 같은 백엔드 기능을 사용합니다.
3. 따라서 정의에 따라 상거래 플랫폼이 헤드리스 배포를 지원할 수 있으려면 상거래 백엔드 기능에 대한 API 범위가 필요합니다.

헤드리스가 정확히 무엇인지(그리고 무엇이 아닌지), 어디서 왔는지, 누구를 위한 것인지 자세히 살펴보겠습니다.

헤드리스 커머스는 새로운 것이 아닙니다.

용어 자체가 지난 몇 년 동안에야 비로소 활기를 띠기 시작했을 수도 있지만 헤드리스의 개념은 그다지 새로운 것이 아닙니다. 위에서 언급했듯이 프론트 엔드/프레젠테이션 레이어/유리가 API를 사용하여 코어에서 분리되는 API 우선 접근 방식입니다.

예를 들어 SAP(이전의 Hybris)에서는 10년 넘게 Restful API 계층(Omni-Commerce 연결)을 통해 상거래 기능을 활성화해 왔습니다. SAP Commerce(온프레미스 및 클라우드)를 실행하는 3,500개 이상의 고객 중 약 절반이 타사 CMS 또는 분리된 맞춤형 매장을 통해 헤드리스 방식으로 실행합니다.

요점은 소문에 속지 말라는 것입니다. 헤드리스는 이제 막 등장한 것이 아닙니다.

순수한 헤드리스 상거래 솔루션이 모든 사람을 위한 것은 아닙니다.

다른 모든 것과 마찬가지로 헤드리스도 모든 사람을 위한 것은 아닙니다. 처음에는 복잡합니다. 개발자는 여러 코드베이스에 걸쳐 깊이 있고 폭넓은 기술을 보유해야 합니다.

하지만 그게 다가 아닙니다. 맞춤형 프레젠테이션 계층/상점은 프론트엔드 프레임워크 및 라이브러리(예: Angular/React/Vue)를 사용하거나 최소한의 파트너 솔루션을 통해 처음부터 완전히 구축해야 하므로 IT 성숙도와 개발 능력이 필요합니다. 이러한 사용자 정의 프런트엔드는 일반적으로 공급업체에서 지원하지 않습니다.

게다가, 맞춤형 프런트엔드는 일반적으로 비즈니스 실무자가 IT의 도움 없이 프런트엔드를 설계하고 업데이트할 수 있는 능력을 제한합니다. 이것이 비즈니스에 중요한 고려 사항이라면 헤드리스 전용 상거래 솔루션이 적합하지 않을 수 있습니다.

좋은 소식: 공급업체는 처음부터 구축할 필요 없이 100% API 적용 범위와 분리된 상점 전면을 통해 "헤드리스 및 정면" 기능을 제공합니다. 이 접근 방식은 프론트엔드 개발 및 전체 프로젝트 제공 일정을 가속화합니다.

헤드리스는 마이크로서비스와 같지 않습니다.

처음에 언급했듯이 일부 공급업체는 헤드리스를 마이크로서비스와 결합하여 의도적으로 물을 혼란스럽게 만들고 있습니다. 기록을 바로 세우자.

아니요, 마이크로서비스는 API와 동일하지 않습니다. 그리고 아니요(여기서 "외부" 목소리를 사용하려고 합니다). 마이크로서비스 기반 아키텍처는 헤드리스의 전제 조건이 아닙니다(반면 API는 그렇습니다).

Martin Fowler에 따르면 "마이크로서비스 아키텍처 스타일은 각각 자체 프로세스에서 실행되고 종종 HTTP 리소스 API인 경량 메커니즘과 통신하는 작은 서비스 모음으로 단일 애플리케이션을 개발하는 접근 방식입니다."

마이크로서비스는 API를 통해 기능을 노출하므로 상호 보완적인 개념이 아니라 상호 보완적인 개념입니다. 마이크로 서비스 기반 아키텍처를 전체 애플리케이션이 "한 조각"의 코드로 구성되는 모놀리식 아키텍처와 비교하십시오. 현실 세계에서 완전히 마이크로서비스 기반이거나 완전히 모놀리식인 애플리케이션은 거의 없습니다. 그들은 일반적으로 중간 어딘가에 떨어집니다.

마이크로서비스는 많은 일을 할 수 있지만 비용도 많이 들고(많은 오버헤드) 민첩성을 위한 은총알이 아닙니다. 각 아키텍처 패턴의 장단점을 살펴보지 않고 마이크로서비스 기반 아키텍처의 주요 이점은 대규모 개발 조직 이 소프트웨어를 구축할 수 있는 속도와 민첩성이라는 점에 주목할 가치가 있습니다. 모놀리식 아키텍처에서 코드를 개발하는 시간에 비해 오버헤드가 적습니다.

따라서 일반적으로 수백 명의 개발자가 작업하는 Amazon과 같은 상거래 플랫폼 공급업체에 매우 가치가 있습니다. 그러나 이러한 종류의 아키텍처는 모든 사람에게 적합하지 않습니다. IT 전문가와 이에 상응하는 상거래 개발 리소스가 없는 조직에는 특히 적합하지 않습니다.

Gartner가 구성 가능한 비즈니스 아키텍처라고 부르는 것을 고려하는 것이 좋습니다. 이 상호 교환 가능한 빌딩 블록 모델을 사용하면 고객 가치의 변화 또는 공급망 또는 자재의 급격한 변화와 같은 요인에 따라 필요에 따라 비즈니스를 재배치할 수 있습니다. 이러한 빌딩 블록 또는 모듈은 마이크로일 수 있지만 매크로 서비스일 수도 있습니다.

Gartner에 따르면 이 아키텍처는 발견을 통한 속도, 모듈화를 통한 더 큰 민첩성, 오케스트레이션을 통한 더 나은 리더십, 자율성을 통한 복원력을 제공합니다. 이것은 조직이 며칠 만에 비즈니스 모델을 완전히 재고하고 전환해야 하는 팬데믹 기간 동안보다 더 중요할 수 없었습니다. 그렇지 않으면 파산 위험이 있습니다.

이제 일부 공급업체가 헤드리스를 마이크로서비스와 혼동하는 이유가 궁금하다면 엔터프라이즈 소프트웨어 시장 자체만큼이나 오래된 해답이 있습니다. 새롭고 빛나는 기능을 강조함으로써 신흥 공급업체가 플랫폼 및 기능 견고성과 같이 부족한 기능에서 초점을 전환할 수 있습니다.

그리고 현대적인 아키텍처는 상거래 플랫폼을 선택할 때 확실히 중요한 고려 사항이지만 기능적 풍부함이나 비즈니스 사용자에게 권한을 부여하는 능력을 희생해서는 안 됩니다.

헤드리스가 여기에 있습니다

터치포인트의 수가 계속 증가함에 따라 헤드리스 상거래는 아무데도 가지 않을 것입니다. 플랫폼을 선택할 때 현재뿐만 아니라 미래에도 비즈니스에 적용할 수 있는 모든 기능적 및 비기능적 요구 사항을 고려하십시오.

오늘날의 일을 할 수는 있지만 향후 성장을 지원하지 않는 플랫폼을 선택하는 것은 ( 예: 국제 현지화 ) 근시안적이며 속담을 걷어차게 만드는 결과를 낳을 뿐입니다.

마지막으로 일부 공급업체에서 밝고 반짝이는 물체를 보기를 원한다고 해서 다른 요구 사항이 갑자기 중요하지 않다는 의미는 아닙니다. 상품 정보 관리, 웹 콘텐츠 관리, 주문 관리, B2B 기능, B2C 기능, 개인화는 필수입니다.

일부 공급업체의 말에도 불구하고 강력한 기능과 레거시 아키텍처를 병합하는 함정에 빠지지 마십시오.