2026 BigCommerce 체크아웃에서 Safari 장바구니가 사라지면 어떻게 해야 할까요?

BigCommerce의 Catalyst 체크아웃 도메인 안내는 도메인 간 이동이 Safari에서 고객 세션이나 장바구니를 이어 가지 못하는 원인이 될 수 있다고 설명합니다. 따라서 BigCommerce Safari 체크아웃에서 장바구니가 사라지면, 우선 스토어프런트와 체크아웃의 실제 호스트명을 확인하고 장바구니와 로그인 상태를 각각 추적하세요. 마지막으로 같은 흐름을 실제 macOS Safari에서 재현해야 원인을 좁힐 수 있습니다. 체크아웃 도메인 안내

이 글은 사용자 지정 스토어프런트에서 체크아웃으로 넘어갈 때 상품이 사라지는 BigCommerce 운영자를 위한 안내입니다.
재현 경로를 기록하려는 운영 담당자와 도메인·세션 인계를 점검하는 기술 협업자도 활용할 수 있습니다.

첫 번째 점검: 스토어프런트와 체크아웃 도메인 확인

먼저 사용 중인 체크아웃 방식부터 구분하세요. 일반 호스팅 스토어, Headless Checkout, Catalyst, Embedded Checkout은 같은 방식으로 동작한다고 가정하면 안 됩니다. 한 구현의 도메인 조건을 다른 구현에 그대로 적용하지 말고, 해당 흐름에 맞는 공식 안내를 확인하세요.

브라우저 주소창에서 스토어프런트와 체크아웃 페이지의 호스트명을 각각 기록합니다. 예를 들어 앞 단계는 사용자 지정 도메인인데 체크아웃은 다른 호스트명으로 열리는지 확인하세요. 경로 전체를 복사할 필요는 없지만, 호스트명은 생략하거나 축약하지 않아야 합니다.

BigCommerce의 Embedded Checkout 개요는 해당 방식의 전제와 도메인 관련 요구사항을 설명합니다. Catalyst를 사용한다면 체크아웃 도메인 설정 문서를 따로 확인하세요. 요구사항이 구현마다 다를 수 있으므로, 도메인이 다르다는 사실만으로 오류 원인을 확정하지 마세요.

BigCommerce 무헤드 스토어와 체크아웃 도메인이 다르면 어떤 점을 확인해야 하나요?

BigCommerce Headless Checkout에서는 스토어프런트와 체크아웃 사이에 장바구니와 고객 상태가 어떻게 이어지는지 확인해야 합니다. 도메인이 다르면 Safari에서 상태가 이어지지 않는 문제가 생길 수 있지만, 도메인 차이만으로 모든 빈 장바구니 현상을 설명할 수는 없습니다. 사용 중인 구현의 도메인 조건과 실제 이동 경로를 함께 대조하세요. Headless Checkout의 체크아웃 흐름 안내

장바구니 상태를 나누어 관찰하세요

상품이 사라진 시점은 원인을 구분하는 기준입니다. 상품 추가 직후 비어 있다면 프런트엔드에서 장바구니가 생성되지 않았을 수 있습니다. 장바구니 페이지에는 상품이 보이지만 체크아웃에서 사라진다면, 상태 인계나 잘못 연결된 체크아웃 경로를 확인해야 합니다.

BigCommerce의 장바구니 생성 API 문서는 장바구니 생성과 관련된 요청·응답 정보를 안내합니다. 기술 담당자는 여기서 장바구니 식별자가 생성되는지, 다음 요청에서 같은 장바구니가 이어지는지 확인할 수 있습니다. 브라우저 화면만 보지 말고, 가능한 경우 민감 정보를 가린 네트워크 기록도 함께 확보하세요.

다음처럼 각 지점의 결과를 따로 적어 두면 재현 과정이 명확해집니다.

상품 페이지에서 상품을 추가한 직후 장바구니에 보이는지 기록합니다.
장바구니 페이지를 열어 상품이 유지되는지 확인합니다.
체크아웃 시작 버튼을 눌러 이동 전후의 주소와 상품 상태를 기록합니다.
호스팅 체크아웃이 열린 뒤 장바구니가 비었는지 확인합니다.
같은 흐름을 다시 실행해 결과가 반복되는지 확인합니다.

스토어프런트에서 체크아웃으로 이동한 뒤 장바구니가 비는 현상은 어떻게 좁히나요?

상품이 처음 사라진 지점을 찾으세요. 체크아웃 페이지에 도착하기 전부터 비었다면 스토어프런트의 장바구니 생성이나 표시를 먼저 살펴봅니다. 체크아웃으로 넘어간 뒤에만 사라진다면, 전달되는 장바구니와 체크아웃 링크가 서로 맞는지 확인합니다. BigCommerce의 Embedded Checkout 튜토리얼은 해당 구현의 설정과 흐름을 점검할 때 참고할 수 있습니다.

고객 세션은 방문자와 로그인 상태를 나누어 비교하세요

방문자 결제와 로그인 고객의 동작을 같은 테스트로 묶지 마세요. 방문자 흐름은 정상인데 로그인 고객만 이탈한다면 계정 이동이나 세션 동기화 과정에 초점을 맞춰야 합니다. 반대로 두 흐름 모두 체크아웃에서 장바구니를 잃는다면 도메인이나 장바구니 전달을 먼저 조사할 수 있습니다.

재현할 때는 로그인, 로그아웃, 계정 페이지 이동이 일어난 시점을 기록하세요. 테스트 계정을 사용하고, 화면 캡처나 요청 기록에는 이메일 주소와 인증 정보가 노출되지 않도록 가립니다.

Catalyst 기반 Headless Checkout이라면 세션 동기화 설명에 따라 세션 인계를 점검하세요. 한 번 로그인 테스트가 통과해도 모든 고객 유형과 모든 브라우저 상태에서 문제가 해결됐다고 단정할 수는 없습니다.

Safari에서 로그인한 뒤 체크아웃으로 가면 로그아웃되는 경우는 어떻게 확인하나요?

먼저 방문자 상태와 로그인 상태를 각각 같은 상품·같은 결제 경로로 재현합니다. 다음으로 로그인이나 계정 페이지 이동 직후 세션이 끊기는지, 체크아웃에 도착한 뒤 끊기는지 구분합니다. 이 결과를 해당 구현의 세션 동기화 방식과 대조하세요. Safari의 추적 방지 기능을 끄거나 우회하는 것은 수정 방법으로 삼지 마세요.

브라우저 재현은 같은 조건으로 맞추세요

Safari에서만 문제가 보인다고 바로 브라우저 결함으로 결론 내리지 마세요. 상품, 체크아웃 경로, 로그인 여부를 동일하게 맞춘 뒤 실제 macOS Safari와 다른 지원 브라우저를 비교해야 합니다. 브라우저마다 저장 상태가 달라질 수 있으므로 테스트마다 새로 시작했는지, 기존 로그인 상태를 유지했는지도 기록하세요.

WebKit의 추적 방지 안내는 웹 추적과 저장소 제한이 브라우저 동작에 영향을 줄 수 있는 배경을 설명합니다. 이는 특정 스토어의 결함을 증명하는 자료가 아닙니다. Safari에서만 재현되더라도 도메인 구성, 세션 인계, 체크아웃 방식과 함께 조사해야 합니다.

Safari에서 Embedded Checkout을 점검할 때는 무엇을 비교해야 하나요?

BigCommerce Embedded Checkout을 쓰는 경우, 공식 문서의 해당 구현 조건과 실제 페이지 호스트명을 먼저 맞춰 보세요. 이어서 상품 추가부터 체크아웃 표시까지 같은 경로로 재현하고, Safari와 다른 지원 브라우저에서 장바구니와 로그인 상태를 나누어 기록합니다. 화면이 열린다는 사실만으로 장바구니 전달이나 거래가 정상이라고 판단하지 마세요.

주문 결과는 화면 표시와 분리해 검증하세요

체크아웃 페이지가 로드되는 것과 주문이 정상적으로 완료되는 것은 서로 다른 결과입니다. 테스트 결제는 BigCommerce와 결제 서비스가 지원하는 테스트 방식을 사용하고, 주문 상태도 관리 화면이나 공식 절차에 따라 별도로 확인하세요. 실제 고객 결제를 시험 삼아 진행하지 말고, 테스트 과정의 화면과 결과 기록은 개인정보를 가린 상태로 보관합니다.

테스트 완료 여부는 다음 항목별로 판정합니다.

상품이 스토어프런트 장바구니에 유지되는지
체크아웃 페이지가 의도한 경로로 열리는지
고객 정보가 예상한 방식으로 이어지는지
테스트 주문 상태가 시스템에서 확인되는지

관찰 결과	먼저 확인할 영역	다음 조치
상품 추가 직후 장바구니가 비어 있음	스토어프런트의 장바구니 생성·표시	생성 요청과 응답을 확인합니다
장바구니에는 상품이 있지만 체크아웃에서 사라짐	체크아웃 경로와 장바구니 인계	호스트명과 이동 전후 상태를 대조합니다
방문자는 정상이고 로그인 고객만 실패함	고객 세션과 계정 이동	로그인·로그아웃 시점을 나누어 재현합니다
같은 흐름에서 Safari만 반복 실패함	Safari의 저장소·도메인 조건	실제 macOS Safari와 다른 브라우저 기록을 비교합니다
체크아웃은 열리지만 주문 상태가 확인되지 않음	테스트 결제와 주문 검증	화면 표시와 주문 결과를 별도로 확인합니다

조건에 따라 다음 점검 경로를 선택하세요

스토어프런트와 체크아웃 호스트가 다르고 사용 중인 구현 문서의 조건을 충족하는지 불확실하다면, 우선 해당 구현의 도메인 요구사항과 배포 설정을 대조하세요. 조건이 맞지 않으면 브라우저 설정을 바꾸기보다 도메인 구성부터 검토합니다.
상품이 체크아웃으로 넘어가기 전부터 보이지 않는다면, 브라우저 간 비교보다 장바구니 생성과 프런트엔드 표시를 먼저 점검하세요.
방문자 흐름은 정상이고 로그인 고객만 실패한다면, 계정 이동 시점과 세션 동기화를 추적하세요.
같은 조건에서 실제 macOS Safari에서만 반복 재현된다면, 페이지 호스트명·장바구니 상태·로그인 상태가 담긴 비식별 기록을 준비해 기술 담당자와 원인을 좁히세요.
테스트 주문 결과까지 확인되지 않았다면, 체크아웃 화면의 로딩만으로 해결 판정을 내리지 말고 지원되는 테스트 절차로 주문 상태를 검증하세요.

선택지	장점	한계와 적합한 경우
실제 Mac에서 Safari 테스트	실제 macOS Safari 동작을 확인할 수 있습니다	팀에 테스트용 Mac과 접근 권한이 있을 때 적합합니다
다른 브라우저와 비교	Safari에서만 나타나는 차이를 찾는 데 도움이 됩니다	Safari 자체의 동작을 대신 검증하지는 못합니다
원격 Mac에서 재현	Mac을 보유하지 않은 팀도 실제 Safari 테스트 환경을 마련할 수 있습니다	점포 설정이나 장바구니 인계 문제를 자동으로 수정하지 않으며 거래 결과도 보장하지 않습니다

실제 Mac을 이미 보유하고 있다면 그 장비로 재현하는 편이 간단합니다. 다만 팀에 Mac이 없고 Safari 동작을 확인해야 한다면, 테스트할 상품 경로와 계정 상태, 필요한 접근 방식이 준비됐는지 먼저 정리하세요. VpsKeep의 원격 Mac 환경 안내를 검토하면 테스트 환경을 선택할 때 확인할 조건을 살펴볼 수 있습니다. 원격 환경과 다른 이용 방식을 함께 살펴보려면 원격 Mac 이용 방식 비교도 참고하세요. 원격 Mac은 실제 Safari 재현을 돕는 수단이지, BigCommerce 구성이나 결제 문제를 해결하는 보증 수단은 아닙니다.