Shopify의 2026년 12월 1일 규정 대비 완료: 셀프서비스 반품 및 교환 앱은 Customer Account API로 이전 필수
Shopify의 2026년 12월 1일 규정 대비 완료: 셀프서비스 반품 및 교환 앱은 Customer Account API로 이전 필수
Shopify의 2026년 12월 1일 규정 대비 완료: 셀프서비스 반품 및 교환 앱은 Customer Account API로 이전 필수

빠른 답변: Revize는 이미 Built for Shopify 앱이며, 배송 전 셀프 서비스 고객 계정과 함께 연동됩니다. 이와 별개로, Shopify의 2026년 12월 1일 규정에 따라 구매자 대상 셀프 서비스를 제공하는 반품 및 교환 앱은 Customer Account API를 인증 수단으로 사용해야 하며, 그렇지 않을 경우 Built for Shopify 상태를 잃을 위험이 있습니다. 구매 후 주문 수정의 92.2%는 지원 담당자의 개입 없이 고객이 직접 완료합니다 (Revize, 2026).
이 마감일이 중요한 이유는 모든 셀프 서비스 반품 또는 교환의 시작 단계에 인증 프로세스가 위치하기 때문입니다. 마이그레이션에 실패하더라도 백엔드 앱 자체가 중단되지는 않을 수 있지만, 반품 성수기 동안 Built for Shopify 상태와 구매자 경험이 위험에 처할 수 있습니다.
이 가이드는 해당 규정을 설명하고, 대상 앱을 식별하며, 반품과 배송 전 주문 수정을 구분하고, 대행사가 12월 1일 이전에 완료해야 할 7단계 감사 프로세스를 제공합니다.

Built for Shopify Customer Account API 필수 요구사항의 변경 사항
2026년 12월 1일부터 구매자 대상 셀프 서비스를 제공하는 반품 및 교환 앱은 Built for Shopify 상태를 유지하기 위해 Customer Account API를 기본 고객 인증 방법으로 사용해야 합니다. Shopify는 2026년 6월 17일에 이 변경 사항을 발표하여, 대상 앱 개발자들에게 마이그레이션에 필요한 약 5개월 반의 기간을 부여했습니다.
또한 공식 Shopify 개발자 변경 로그에는 구독 앱도 포함되어 있습니다. 반품 팀의 경우 핵심 문구는 구매자 대상 셀프 서비스(buyer-facing self-service)입니다. 즉, 직원의 개입 없이 고객이 직접 반품을 시작하거나 관리하고, 교환을 추적하는 등의 작업을 수행할 수 있는 기능을 의미합니다.
이로 인한 결과는 일부 마감일 요약본에서 제시하는 것보다 더 제한적입니다. Shopify는 규정을 준수하지 않는 앱이 Built for Shopify 상태를 잃을 위험이 있다고 명시하고 있습니다. 대상 앱이 모두 작동을 멈추거나, App Store에서 사라지거나, 자정에 판매자의 워크플로를 차단한다는 의미는 아닙니다.
감사 질문 | 2026년 11월 30일까지 | 2026년 12월 1일부터 |
|---|---|---|
필수 기본 구매자 인증 | 기존 방식 유지 가능 | Customer Account API |
해당 카테고리 | 반품, 교환, 구독 | 동일 카테고리 |
구매자 대상 셀프 서비스 필수 여부 | 규정 적용에 필수적임 | 규정 적용에 필수적임 |
명시된 즉각적인 영향 | 마이그레이션 기간 진행 중 | Built for Shopify 상태 상실 위험 |
판매자 조치 사항 | 개발사에 증빙 요청 | 프로덕션 환경 동작 검증 |
12월 1일을 자동적인 스토어프런트 중단이 아닌, 벤더 거버넌스 마감일로 다루십시오. 대행사는 지금 즉시 이 문제를 해결해야 합니다. 인증 방식 변경이나 성급하게 출시된 인증 릴리즈로 인해 연말 반품 성수기 동안 피할 수 있는 리스크가 발생할 수 있기 때문입니다.

Built for Shopify 요구사항 적용 대상
앱이 반품, 교환 또는 구독 카테고리에 속하고, 구매자 대상 셀프 서비스를 제공하며, 2026년 12월 1일 이후에도 Built for Shopify 상태를 유지하고자 하는 세 가지 조건이 겹칠 때 해당 앱이 영향을 받습니다. 판매자의 전체 앱 스택이 자동으로 범위에 포함되는 것은 아닙니다.
모든 구매 후 관련 앱에 대해 다음 의사결정 체크리스트를 사용하십시오.
앱 카테고리 확인. 기능 이름으로 카테고리를 추정하지 말고, Shopify와 벤더가 앱을 어떻게 분류하는지 확인하십시오.
구매자 대상 워크플로 파악. 반품 시작, 교환 추적, 구독 업데이트 및 해당 작업을 수행하는 모든 고객 포털을 포함하십시오.
현재 인증 방식 확인. Shopify의 Customer Account API가 이미 프로덕션 환경의 기본 방식인지 문의하십시오.
벤더의 Built for Shopify 획득 목표 확인. 배지가 없는 앱은 잃을 배지도 없지만, 운영상 고객 계정 호환성은 여전히 중요할 수 있습니다.
배송 전 및 배송 후 조치 구분. 배송되지 않은 주문을 변경하는 것은 주문 수정(order editing)입니다. 배송 완료된 제품을 돌려보내는 것은 반품입니다. 고객이 사용하는 유사한 표현으로 인해 이를 동일한 워크플로로 혼동해서는 안 됩니다.
마지막 구분은 가장 흔한 감사 오류를 방지합니다. 구매자가 사이즈 변경을 '교환'이라고 부를 수 있지만, 배송 전에 옵션을 변경하는 것은 역물류 자체를 완전히 방지합니다. 배송 후 교환에는 반품 라이프사이클, 수령 또는 검수 로직, 대체품 발송이 필요합니다.
당사 데이터에 따르면 1,000만 건 이상의 Shopify 주문 중 약 19건 중 1건(5.2%)이 결제 후 수정됩니다 (Revize, 2026). 따라서 대행사는 두 레이어를 모두 감사하되, 12월 필수 요구사항은 Shopify가 실제로 지정한 카테고리에만 적용해야 합니다.
Customer Account API의 실제 역할
Customer Account API는 구매자를 인증하고 앱에 해당 구매자의 Shopify 계정 데이터에 대한 통제된 액세스 권한을 부여합니다. API(애플리케이션 프로그래밍 인터페이스)는 시스템 간의 규정된 관문입니다. 앱이 인증된 요청을 전달하면 Shopify는 해당 요청에 허용된 데이터만 반환합니다.
이는 앱이 일반적으로 판매자를 대신하여 작동하는 Admin API와 다릅니다. Shopify의 Customer Account API 레퍼런스에 따르면, 고객 대상 API는 주문, 프로필, 주소를 포함한 구매자 본인의 정보를 읽고 업데이트합니다.
2026년 8월 29일 기준, Shopify 레퍼런스에는 최신 버전으로 2026-07이 표시되어 있습니다. 또한 하나의 도메인을 하드코딩하는 대신 각 상점에 맞는 올바른 인증 및 GraphQL 엔드포인트를 앱이 획득할 수 있도록 검색 엔드포인트를 문서화하고 있습니다.
인증은 인터페이스 배치와 다릅니다. Customer Account UI 확장은 고객 계정 내부에서 경험이 표시되는 위치를 제어합니다. Customer Account API는 고객 데이터에 대한 인증된 액세스를 제어합니다. 앱이 완성도 높은 계정 페이지 컴포넌트를 갖추고 있더라도, 벤더에게 필수 API가 기본 인증 방식인지 확인받아야 합니다.
대행사는 다음 네 가지 기술적 질문에 대한 서면 답변을 요청해야 합니다.
프로덕션 환경의 구매자 플로우가 Customer Account API를 통해 인증됩니까?
계정 페이지, 주문 이메일, 딥 링크, 외부 포털을 포함하여 어떤 진입 경로가 이를 사용합니까?
마이그레이션이 모든 판매자에게 적용되었습니까, 아니면 일부 테스트 집단에만 적용되었습니까?
마이그레이션 평가 후 벤더의 Partner Dashboard에 어떤 증빙이 표시됩니까?
경고: '새 고객 계정 지원'이라는 답변을 완전한 규정 준수 증빙으로 받아들이지 마십시오. 해당 환경을 지원하는 것과 인증 요구사항을 준수하는 것은 서로 관련이 있지만 동일한 의미는 아닙니다.
12월 감사에서 Revize의 위치
Revize는 배송 전 고객 셀프 서비스 레이어를 담당하며, 12월 1일 규정은 배송 후 전용 반품 및 교환 앱을 대상으로 합니다. Shopify는 현재 이 주문 수정 앱을 Built for Shopify 앱이자 Customer 계정과 호환되며, 반품 및 교환이 아닌 주문 수정 카테고리로 분류하고 있습니다.
고객은 배송 전에 주소, 옵션, 수량을 변경하거나 대상 주문을 수정하기 위해 셀프 서비스 주문 수정 포털을 사용할 수 있습니다. 이 플로우는 Shopify의 주문 상태 페이지에 표시되며, 판매자가 수정 가능 기간을 제어합니다.
이러한 카테고리 구분은 강력한 장점입니다. 배송 전에 주문을 바로잡으면 피할 수 있는 반품이 역물류 시스템으로 유입되는 것을 방지합니다. 배송 후 반품은 별도의 작업이므로, 주문량이 많은 스토어는 시스템 간 무리한 통합 없이 주문 수정 앱과 전용 반품 플랫폼을 병행하여 사용할 수 있습니다.
고객 니즈 | 운영 단계 | 적절한 시스템 | 12월 규정 관련성 |
|---|---|---|---|
배송 주소 수정 | 배송 전 | 주문 수정 앱 | 카테고리 자체로는 대상 아님 |
발송 전 사이즈 변경 | 배송 전 | 주문 수정 앱 | 카테고리 자체로는 대상 아님 |
해당 주문 취소 | 배송 전 | 주문 수정 앱 | 카테고리 자체로는 대상 아님 |
배송 완료 제품 반품 | 배송 후 | 반품 앱 | 구매자 셀프 서비스 포함 시 대상 |
대체품 배송 추적 | 반품 또는 교환 라이프사이클 | 교환 앱 | 구매자 셀프 서비스 포함 시 대상 |
Plus, Advanced, Grow 스토어를 감사하는 대행사의 실질적인 조치는 이러한 구분을 유지하는 것입니다. 배송 전 수정 작업은 주문 수정 레이어에서 처리하도록 하고, 반품 벤더에게는 별도의 규정 준수 증빙을 요구하십시오. Square Enix, Venchi, Shelly, Nude Project, AYBL, TheGameCollection 등의 브랜드는 다양한 제품 카테고리에서 고객 셀프 서비스 모델을 사용하고 있습니다.
귀사의 스택이 여전히 주소, 옵션 변경, 취소 요청을 고객 지원 부서로 전달하고 있다면, 반품 벤더가 12월 마이그레이션을 완료하는 동안 배송 전 셀프 서비스 레이어를 추가하십시오.

대행사가 Customer Account API 요구사항을 감사하는 방법
2026년 12월 1일 이전에 셀프 서비스 반품, 교환 또는 구독을 제공하는 모든 클라이언트를 대상으로 이 7단계 감사를 실행하십시오. 최종 결과물은 벤더가 마이그레이션을 약속했다는 기록에 그치지 않고, 각 구매자 진입 지점에서의 실제 프로덕션 동작을 입증해야 합니다.
대상 앱 인벤토리 구축. 각 앱의 Shopify 카테고리, Built for Shopify 상태, 고객 대상 기능, 비즈니스 소유자, 기술 소유자 및 갱신일을 기록하십시오. 주문 수정, 추적, 반품, 교환, 구독, 고객 센터 및 창고 기능을 구분하십시오.
벤더 서면 답변 요청. 해당 앱이 Shopify가 발표한 카테고리 요구사항에 포함되는지, 그리고 Customer Account API가 프로덕션 환경의 기본 인증 방법인지 서면으로 확인하십시오. 아직 준비가 되지 않았다면 릴리즈 예정일을 요청하십시오.
모든 고객 진입 경로 매핑. 계정 탐색, 주문 상태 페이지, 확인 이메일, 반품 링크, 교환 추적, QR 코드 목적지, 모바일 브라우저 및 헤드리스 스토어프런트 링크를 테스트하십시오. 메인 계정 메뉴에서는 인증이 완료된 것처럼 보여도 이전 딥 링크가 여전히 별도의 포털을 열 수 있습니다.
인증 전환 과정 점검. 구매자가 이미 로그인된 상태, 로그아웃된 상태 또는 이전 북마크를 통해 재방문할 때 발생하는 상황을 확인하십시오. 리디렉션, 반복적인 로그인 요청, 소실된 주문 콘텍스트 및 별도의 포털 자격 증명을 요구하는 경로가 있는지 기록하십시오.

반품 및 교환 전체 테스트 실행. 제어된 테스트 주문을 사용하여 반품 대상 품목, 반품 불가 품목, 부분 반품, 교환, 취소 및 진행 도중 이탈 후 재개하는 고객의 케이스를 테스트하십시오. Shopify 및 모든 후속 운영 시스템에서의 최종 상태를 검증하십시오.
양방향 증빙 자료 수집. 구매자 플로우 기록, Shopify 주문 타임라인, 벤더 릴리즈 노트, 지원 확인 내용 및 각 테스트 날짜를 저장하십시오. 가능한 경우 앱 개발사로부터 자체 Built for Shopify 평가 증빙 자료를 제공받으십시오.
롤백 및 에스컬레이션 계획 수립. 확실한 증빙을 제공하지 못하는 앱을 대체하기 위해 클라이언트 담당자, 대행사 담당자, 벤더 연락처, 대체 지원 프로세스 및 교체 결정일을 문서화하십시오. 이 결정일은 성수기 시스템 변경 동결(freeze) 이전에 완료되도록 예약하십시오.
배지가 변경될 때까지 테스트를 미루지 마십시오. 가장 큰 비용이 발생하는 실패는 배지 유실 자체가 아닙니다. 고객이 자신의 주문을 식별하지 못하거나, 교환을 재개할 수 없거나, 익숙했던 계정 경로가 다르게 동작하여 겪게 되는 불편입니다.
12월 1일 이후 실제로 중단되는 것은 무엇인가?
Shopify가 명시적으로 밝힌 12월 1일의 유일한 영향은 규정을 준수하지 않는 대상 앱이 Built for Shopify 상태를 잃을 위험이 있다는 것입니다. App Store에서의 자동 삭제나 반품 포털의 즉각적인 폐쇄와 같은 과장된 주장은 게시된 공지사항 범위를 벗어납니다.
그럼에도 불구하고 판매자는 다음과 같은 세 가지 실질적인 위험을 평가해야 합니다.
신뢰성 위험: 앱 도입 및 스택 검토 중에 판매자가 활용하는 품질 신호인 배지를 유실할 수 있습니다.
릴리즈 위험: 뒤늦은 인증 마이그레이션으로 인해 로그인 루프, 리디렉션 오류 또는 주문 콘텍스트 누락이 발생할 수 있습니다. 정상 작동을 예단하지 말고 테스트 주문을 통해 직접 검증하십시오.
지원 위험: 셀프 서비스 경로가 불안정해지면, 고객은 가장 바쁜 반품 기간에 이메일이나 채팅 문의로 돌아설 것입니다.
배지는 Shopify가 지정한 제재 조치입니다. 구매자 여정은 판매자가 직접 테스트해야 하는 비즈니스 핵심 메커니즘입니다.
팁: 벤더의 주장과 실제 테스트 증빙을 동일한 감사 기록에 보관하십시오. 로드맵 일정은 의지를 증명할 뿐이지만, 완료된 구매자 여정은 준비 상태를 증명합니다.
Plus 운영자를 위한 핵심 요약
8월 29일 기준으로 마감일까지 94일이 남은 상황에서 대행사는 9월 중에 현황 파악을 마치고, 10월에는 프로덕션 테스트를 실행하며, 11월 시스템 변경 동결 이전에 문제 해결 결정을 완료해야 합니다. 12월 1일 마감일은 명확하고 검증 가능하며, 구매 후 스택 전체를 교체하지 않고도 충분히 감사할 수 있는 좁은 범위입니다.
이번 주에 수행해야 할 작업은 다음과 같습니다.
구매자 대상 반품, 교환 및 구독 앱의 인벤토리를 파악하십시오.
각 벤더에게 Customer Account API 인증이 프로덕션 환경의 기본 방식인지 문의하십시오.
제어된 테스트 주문으로 모든 구매자 진입 경로를 테스트하십시오.
배송 전 주문 수정과 배송 후 반품을 구분하십시오.
증빙, 담당자, 기한 및 대체 경로를 기록하십시오.
목표는 보여주기식 마이그레이션이 아닙니다. 대행사가 보증할 수 있는 객관적인 증빙을 바탕으로, 구매 후 여정 전반에 걸쳐 신뢰할 수 있는 일관된 고객 식별 프로세스를 확보하는 것입니다.

자주 묻는 질문 (FAQ)
이 답변들은 대행사와 Plus 운영자가 2026년 12월 1일 이전에 해결해야 할 10가지 질문을 다룹니다. 발표된 규정은 간결하므로, 가장 안전한 접근법은 Shopify의 정확한 요구사항과 여전히 벤더 증빙 및 테스트 주문이 필요한 운영상의 결론을 명확히 구분하는 것입니다.
2026년 12월 1일에 무엇이 변경되나요?
해당 반품, 교환 및 구독 앱은 Built for Shopify 상태를 유지하기 위해 Customer Account API를 기본 고객 인증 방법으로 사용해야 합니다. 이 규정은 앱이 구매자 대상 셀프 서비스 환경을 제공할 때 적용됩니다. Shopify는 2026년 6월 17일에 이 마감일을 발표했습니다.
반품 앱이 12월 1일에 작동을 멈추나요?
Shopify는 대상 앱이 12월 1일에 자동으로 작동을 멈춘다고 밝히지 않았습니다. 공식적으로 발표된 결과는 요구사항을 충족하지 못한 앱이 Built for Shopify 상태를 잃을 위험이 있다는 것입니다. 판매자는 서비스 지속성에 대해 벤더에 문의하고, 가동 중단을 추측하기보다는 테스트 주문을 통해 고객 여정을 검증해야 합니다.
이 요구사항이 모든 Shopify 앱에 적용되나요?
아니요, 발표된 요구사항은 모든 Shopify 앱에 적용되지 않습니다. Shopify는 구매자 대상 셀프 서비스를 제공하는 반품 및 교환 앱과 구독 앱을 지정했습니다. 배송 추적, 고객 센터, 주문 수정, 창고 및 기타 카테고리는 Shopify나 벤더가 카테고리별 증빙을 제공하지 않는 한 대상 범위에 포함되지 않는 것으로 간주해야 합니다.
판매자가 API 마이그레이션을 담당해야 하나요?
API 마이그레이션은 앱 개발사가 구현하며, 판매자는 벤더 및 운영 리스크 관리를 담당합니다. 대행사는 벤더의 프로덕션 적용 상태를 확인하고, 영향을 받는 구매자 플로우를 테스트하고, 대체 계획을 문서화해야 합니다. 판매자가 Shopify 관리자 설정에서 서드파티 앱의 인증 아키텍처를 직접 수정할 수는 없습니다.
Customer Account API란 무엇인가요?
Customer Account API는 계정 데이터에 대해 인증된 구매자 액세스를 제공하는 Shopify의 인터페이스입니다. 이를 통해 앱은 로그인한 고객의 주문, 프로필 정보, 주소 등의 정보와 연동하여 작업할 수 있습니다. Shopify는 이를 고객 계정, 스토어프런트 및 연결된 앱 전반의 공통 인증 레이어로 규정하고 있습니다.
이 API는 Customer Account UI 확장과 동일한가요?
아니요, 인증과 인터페이스 배치는 서로 다른 개념입니다. Customer Account API는 인증된 데이터 액세스를 제어합니다. Customer Account UI 확장은 Shopify 계정 영역 내에 앱 경험을 표시하므로, 앱은 두 가지가 모두 필요할 수 있으며 그럼에도 해당 API가 기본 인증 수단인지 확인해야 합니다.
반품 포털 전체가 마이그레이션되어야 하나요?
발표된 12월 규정은 구체적으로 Customer Account API를 기본 인증 방법으로 사용할 것을 요구합니다. 모든 화면이 하나의 Shopify 인터페이스 내부에서 재구축되어야 한다고 명시하고 있지는 않습니다. 대행사는 어떤 인터페이스와 백엔드 컴포넌트가 변경되는지 벤더에 확인하고, 인증이 모든 후속 단계에 영향을 미치므로 전체 플로우를 테스트해야 합니다.
비회원(Guest) 주문은 어떻게 테스트해야 하나요?
벤더가 지원하는 실제 링크와 인증 상태를 통해 비회원 주문을 테스트하십시오. 확인 이메일 인입 경로, 로그아웃 상태의 브라우저, 세션 만료, 다른 기기에서의 재방문 등을 포함하십시오. 로그인 계정 테스트 성공이 비회원 또는 사전 인증된 모든 경로의 준비 상태를 보장한다고 가정하지 마십시오.
판매자가 현재 사용 중인 반품 앱을 계속 유지할 수 있나요?
네, 벤더가 신뢰할 수 있는 규정 준수 경로를 제시하고 프로덕션 워크플로 테스트를 통과한다면 가능합니다. 마감일 자체가 판매자에게 앱 교체를 요구하는 것은 아닙니다. 교체는 벤더가 증빙을 제공하지 못하거나, 합의된 일정을 맞추지 못하거나, 통제된 구매자 여정 테스트에 실패할 때 내리는 운영상의 결정입니다.
대행사는 규정 준수 증빙 자료로 무엇을 보관해야 하나요?
벤더 서면 답변, 테스트 날짜, 구매자 플로우 기록, 테스트 주문 ID, 최종 Shopify 상태 및 에스컬레이션 담당자를 보관하십시오. 벤더가 공유할 수 있는 경우, 앱의 현재 Built for Shopify 상태 스크린샷과 관련 Partner Dashboard 증빙을 추가하십시오. 기록에는 계획된 작업뿐만 아니라 실제로 관측된 동작이 포함되어야 합니다.
관련 아티클
이 3가지 가이드는 Built for Shopify Customer Account API 요구사항과 연관된 고객 계정, 결제 및 주문 운영 변경 사항을 다룹니다.
지금 증빙 수집을 완료하고, 각 시스템이 고유의 운영 단계에 집중되도록 보장하며, 막연한 추측이 아닌 검증된 고객 여정을 가지고 12월 1일을 대비하십시오.
빠른 답변: Revize는 이미 Built for Shopify 앱이며, 배송 전 셀프 서비스 고객 계정과 함께 연동됩니다. 이와 별개로, Shopify의 2026년 12월 1일 규정에 따라 구매자 대상 셀프 서비스를 제공하는 반품 및 교환 앱은 Customer Account API를 인증 수단으로 사용해야 하며, 그렇지 않을 경우 Built for Shopify 상태를 잃을 위험이 있습니다. 구매 후 주문 수정의 92.2%는 지원 담당자의 개입 없이 고객이 직접 완료합니다 (Revize, 2026).
이 마감일이 중요한 이유는 모든 셀프 서비스 반품 또는 교환의 시작 단계에 인증 프로세스가 위치하기 때문입니다. 마이그레이션에 실패하더라도 백엔드 앱 자체가 중단되지는 않을 수 있지만, 반품 성수기 동안 Built for Shopify 상태와 구매자 경험이 위험에 처할 수 있습니다.
이 가이드는 해당 규정을 설명하고, 대상 앱을 식별하며, 반품과 배송 전 주문 수정을 구분하고, 대행사가 12월 1일 이전에 완료해야 할 7단계 감사 프로세스를 제공합니다.

Built for Shopify Customer Account API 필수 요구사항의 변경 사항
2026년 12월 1일부터 구매자 대상 셀프 서비스를 제공하는 반품 및 교환 앱은 Built for Shopify 상태를 유지하기 위해 Customer Account API를 기본 고객 인증 방법으로 사용해야 합니다. Shopify는 2026년 6월 17일에 이 변경 사항을 발표하여, 대상 앱 개발자들에게 마이그레이션에 필요한 약 5개월 반의 기간을 부여했습니다.
또한 공식 Shopify 개발자 변경 로그에는 구독 앱도 포함되어 있습니다. 반품 팀의 경우 핵심 문구는 구매자 대상 셀프 서비스(buyer-facing self-service)입니다. 즉, 직원의 개입 없이 고객이 직접 반품을 시작하거나 관리하고, 교환을 추적하는 등의 작업을 수행할 수 있는 기능을 의미합니다.
이로 인한 결과는 일부 마감일 요약본에서 제시하는 것보다 더 제한적입니다. Shopify는 규정을 준수하지 않는 앱이 Built for Shopify 상태를 잃을 위험이 있다고 명시하고 있습니다. 대상 앱이 모두 작동을 멈추거나, App Store에서 사라지거나, 자정에 판매자의 워크플로를 차단한다는 의미는 아닙니다.
감사 질문 | 2026년 11월 30일까지 | 2026년 12월 1일부터 |
|---|---|---|
필수 기본 구매자 인증 | 기존 방식 유지 가능 | Customer Account API |
해당 카테고리 | 반품, 교환, 구독 | 동일 카테고리 |
구매자 대상 셀프 서비스 필수 여부 | 규정 적용에 필수적임 | 규정 적용에 필수적임 |
명시된 즉각적인 영향 | 마이그레이션 기간 진행 중 | Built for Shopify 상태 상실 위험 |
판매자 조치 사항 | 개발사에 증빙 요청 | 프로덕션 환경 동작 검증 |
12월 1일을 자동적인 스토어프런트 중단이 아닌, 벤더 거버넌스 마감일로 다루십시오. 대행사는 지금 즉시 이 문제를 해결해야 합니다. 인증 방식 변경이나 성급하게 출시된 인증 릴리즈로 인해 연말 반품 성수기 동안 피할 수 있는 리스크가 발생할 수 있기 때문입니다.

Built for Shopify 요구사항 적용 대상
앱이 반품, 교환 또는 구독 카테고리에 속하고, 구매자 대상 셀프 서비스를 제공하며, 2026년 12월 1일 이후에도 Built for Shopify 상태를 유지하고자 하는 세 가지 조건이 겹칠 때 해당 앱이 영향을 받습니다. 판매자의 전체 앱 스택이 자동으로 범위에 포함되는 것은 아닙니다.
모든 구매 후 관련 앱에 대해 다음 의사결정 체크리스트를 사용하십시오.
앱 카테고리 확인. 기능 이름으로 카테고리를 추정하지 말고, Shopify와 벤더가 앱을 어떻게 분류하는지 확인하십시오.
구매자 대상 워크플로 파악. 반품 시작, 교환 추적, 구독 업데이트 및 해당 작업을 수행하는 모든 고객 포털을 포함하십시오.
현재 인증 방식 확인. Shopify의 Customer Account API가 이미 프로덕션 환경의 기본 방식인지 문의하십시오.
벤더의 Built for Shopify 획득 목표 확인. 배지가 없는 앱은 잃을 배지도 없지만, 운영상 고객 계정 호환성은 여전히 중요할 수 있습니다.
배송 전 및 배송 후 조치 구분. 배송되지 않은 주문을 변경하는 것은 주문 수정(order editing)입니다. 배송 완료된 제품을 돌려보내는 것은 반품입니다. 고객이 사용하는 유사한 표현으로 인해 이를 동일한 워크플로로 혼동해서는 안 됩니다.
마지막 구분은 가장 흔한 감사 오류를 방지합니다. 구매자가 사이즈 변경을 '교환'이라고 부를 수 있지만, 배송 전에 옵션을 변경하는 것은 역물류 자체를 완전히 방지합니다. 배송 후 교환에는 반품 라이프사이클, 수령 또는 검수 로직, 대체품 발송이 필요합니다.
당사 데이터에 따르면 1,000만 건 이상의 Shopify 주문 중 약 19건 중 1건(5.2%)이 결제 후 수정됩니다 (Revize, 2026). 따라서 대행사는 두 레이어를 모두 감사하되, 12월 필수 요구사항은 Shopify가 실제로 지정한 카테고리에만 적용해야 합니다.
Customer Account API의 실제 역할
Customer Account API는 구매자를 인증하고 앱에 해당 구매자의 Shopify 계정 데이터에 대한 통제된 액세스 권한을 부여합니다. API(애플리케이션 프로그래밍 인터페이스)는 시스템 간의 규정된 관문입니다. 앱이 인증된 요청을 전달하면 Shopify는 해당 요청에 허용된 데이터만 반환합니다.
이는 앱이 일반적으로 판매자를 대신하여 작동하는 Admin API와 다릅니다. Shopify의 Customer Account API 레퍼런스에 따르면, 고객 대상 API는 주문, 프로필, 주소를 포함한 구매자 본인의 정보를 읽고 업데이트합니다.
2026년 8월 29일 기준, Shopify 레퍼런스에는 최신 버전으로 2026-07이 표시되어 있습니다. 또한 하나의 도메인을 하드코딩하는 대신 각 상점에 맞는 올바른 인증 및 GraphQL 엔드포인트를 앱이 획득할 수 있도록 검색 엔드포인트를 문서화하고 있습니다.
인증은 인터페이스 배치와 다릅니다. Customer Account UI 확장은 고객 계정 내부에서 경험이 표시되는 위치를 제어합니다. Customer Account API는 고객 데이터에 대한 인증된 액세스를 제어합니다. 앱이 완성도 높은 계정 페이지 컴포넌트를 갖추고 있더라도, 벤더에게 필수 API가 기본 인증 방식인지 확인받아야 합니다.
대행사는 다음 네 가지 기술적 질문에 대한 서면 답변을 요청해야 합니다.
프로덕션 환경의 구매자 플로우가 Customer Account API를 통해 인증됩니까?
계정 페이지, 주문 이메일, 딥 링크, 외부 포털을 포함하여 어떤 진입 경로가 이를 사용합니까?
마이그레이션이 모든 판매자에게 적용되었습니까, 아니면 일부 테스트 집단에만 적용되었습니까?
마이그레이션 평가 후 벤더의 Partner Dashboard에 어떤 증빙이 표시됩니까?
경고: '새 고객 계정 지원'이라는 답변을 완전한 규정 준수 증빙으로 받아들이지 마십시오. 해당 환경을 지원하는 것과 인증 요구사항을 준수하는 것은 서로 관련이 있지만 동일한 의미는 아닙니다.
12월 감사에서 Revize의 위치
Revize는 배송 전 고객 셀프 서비스 레이어를 담당하며, 12월 1일 규정은 배송 후 전용 반품 및 교환 앱을 대상으로 합니다. Shopify는 현재 이 주문 수정 앱을 Built for Shopify 앱이자 Customer 계정과 호환되며, 반품 및 교환이 아닌 주문 수정 카테고리로 분류하고 있습니다.
고객은 배송 전에 주소, 옵션, 수량을 변경하거나 대상 주문을 수정하기 위해 셀프 서비스 주문 수정 포털을 사용할 수 있습니다. 이 플로우는 Shopify의 주문 상태 페이지에 표시되며, 판매자가 수정 가능 기간을 제어합니다.
이러한 카테고리 구분은 강력한 장점입니다. 배송 전에 주문을 바로잡으면 피할 수 있는 반품이 역물류 시스템으로 유입되는 것을 방지합니다. 배송 후 반품은 별도의 작업이므로, 주문량이 많은 스토어는 시스템 간 무리한 통합 없이 주문 수정 앱과 전용 반품 플랫폼을 병행하여 사용할 수 있습니다.
고객 니즈 | 운영 단계 | 적절한 시스템 | 12월 규정 관련성 |
|---|---|---|---|
배송 주소 수정 | 배송 전 | 주문 수정 앱 | 카테고리 자체로는 대상 아님 |
발송 전 사이즈 변경 | 배송 전 | 주문 수정 앱 | 카테고리 자체로는 대상 아님 |
해당 주문 취소 | 배송 전 | 주문 수정 앱 | 카테고리 자체로는 대상 아님 |
배송 완료 제품 반품 | 배송 후 | 반품 앱 | 구매자 셀프 서비스 포함 시 대상 |
대체품 배송 추적 | 반품 또는 교환 라이프사이클 | 교환 앱 | 구매자 셀프 서비스 포함 시 대상 |
Plus, Advanced, Grow 스토어를 감사하는 대행사의 실질적인 조치는 이러한 구분을 유지하는 것입니다. 배송 전 수정 작업은 주문 수정 레이어에서 처리하도록 하고, 반품 벤더에게는 별도의 규정 준수 증빙을 요구하십시오. Square Enix, Venchi, Shelly, Nude Project, AYBL, TheGameCollection 등의 브랜드는 다양한 제품 카테고리에서 고객 셀프 서비스 모델을 사용하고 있습니다.
귀사의 스택이 여전히 주소, 옵션 변경, 취소 요청을 고객 지원 부서로 전달하고 있다면, 반품 벤더가 12월 마이그레이션을 완료하는 동안 배송 전 셀프 서비스 레이어를 추가하십시오.

대행사가 Customer Account API 요구사항을 감사하는 방법
2026년 12월 1일 이전에 셀프 서비스 반품, 교환 또는 구독을 제공하는 모든 클라이언트를 대상으로 이 7단계 감사를 실행하십시오. 최종 결과물은 벤더가 마이그레이션을 약속했다는 기록에 그치지 않고, 각 구매자 진입 지점에서의 실제 프로덕션 동작을 입증해야 합니다.
대상 앱 인벤토리 구축. 각 앱의 Shopify 카테고리, Built for Shopify 상태, 고객 대상 기능, 비즈니스 소유자, 기술 소유자 및 갱신일을 기록하십시오. 주문 수정, 추적, 반품, 교환, 구독, 고객 센터 및 창고 기능을 구분하십시오.
벤더 서면 답변 요청. 해당 앱이 Shopify가 발표한 카테고리 요구사항에 포함되는지, 그리고 Customer Account API가 프로덕션 환경의 기본 인증 방법인지 서면으로 확인하십시오. 아직 준비가 되지 않았다면 릴리즈 예정일을 요청하십시오.
모든 고객 진입 경로 매핑. 계정 탐색, 주문 상태 페이지, 확인 이메일, 반품 링크, 교환 추적, QR 코드 목적지, 모바일 브라우저 및 헤드리스 스토어프런트 링크를 테스트하십시오. 메인 계정 메뉴에서는 인증이 완료된 것처럼 보여도 이전 딥 링크가 여전히 별도의 포털을 열 수 있습니다.
인증 전환 과정 점검. 구매자가 이미 로그인된 상태, 로그아웃된 상태 또는 이전 북마크를 통해 재방문할 때 발생하는 상황을 확인하십시오. 리디렉션, 반복적인 로그인 요청, 소실된 주문 콘텍스트 및 별도의 포털 자격 증명을 요구하는 경로가 있는지 기록하십시오.

반품 및 교환 전체 테스트 실행. 제어된 테스트 주문을 사용하여 반품 대상 품목, 반품 불가 품목, 부분 반품, 교환, 취소 및 진행 도중 이탈 후 재개하는 고객의 케이스를 테스트하십시오. Shopify 및 모든 후속 운영 시스템에서의 최종 상태를 검증하십시오.
양방향 증빙 자료 수집. 구매자 플로우 기록, Shopify 주문 타임라인, 벤더 릴리즈 노트, 지원 확인 내용 및 각 테스트 날짜를 저장하십시오. 가능한 경우 앱 개발사로부터 자체 Built for Shopify 평가 증빙 자료를 제공받으십시오.
롤백 및 에스컬레이션 계획 수립. 확실한 증빙을 제공하지 못하는 앱을 대체하기 위해 클라이언트 담당자, 대행사 담당자, 벤더 연락처, 대체 지원 프로세스 및 교체 결정일을 문서화하십시오. 이 결정일은 성수기 시스템 변경 동결(freeze) 이전에 완료되도록 예약하십시오.
배지가 변경될 때까지 테스트를 미루지 마십시오. 가장 큰 비용이 발생하는 실패는 배지 유실 자체가 아닙니다. 고객이 자신의 주문을 식별하지 못하거나, 교환을 재개할 수 없거나, 익숙했던 계정 경로가 다르게 동작하여 겪게 되는 불편입니다.
12월 1일 이후 실제로 중단되는 것은 무엇인가?
Shopify가 명시적으로 밝힌 12월 1일의 유일한 영향은 규정을 준수하지 않는 대상 앱이 Built for Shopify 상태를 잃을 위험이 있다는 것입니다. App Store에서의 자동 삭제나 반품 포털의 즉각적인 폐쇄와 같은 과장된 주장은 게시된 공지사항 범위를 벗어납니다.
그럼에도 불구하고 판매자는 다음과 같은 세 가지 실질적인 위험을 평가해야 합니다.
신뢰성 위험: 앱 도입 및 스택 검토 중에 판매자가 활용하는 품질 신호인 배지를 유실할 수 있습니다.
릴리즈 위험: 뒤늦은 인증 마이그레이션으로 인해 로그인 루프, 리디렉션 오류 또는 주문 콘텍스트 누락이 발생할 수 있습니다. 정상 작동을 예단하지 말고 테스트 주문을 통해 직접 검증하십시오.
지원 위험: 셀프 서비스 경로가 불안정해지면, 고객은 가장 바쁜 반품 기간에 이메일이나 채팅 문의로 돌아설 것입니다.
배지는 Shopify가 지정한 제재 조치입니다. 구매자 여정은 판매자가 직접 테스트해야 하는 비즈니스 핵심 메커니즘입니다.
팁: 벤더의 주장과 실제 테스트 증빙을 동일한 감사 기록에 보관하십시오. 로드맵 일정은 의지를 증명할 뿐이지만, 완료된 구매자 여정은 준비 상태를 증명합니다.
Plus 운영자를 위한 핵심 요약
8월 29일 기준으로 마감일까지 94일이 남은 상황에서 대행사는 9월 중에 현황 파악을 마치고, 10월에는 프로덕션 테스트를 실행하며, 11월 시스템 변경 동결 이전에 문제 해결 결정을 완료해야 합니다. 12월 1일 마감일은 명확하고 검증 가능하며, 구매 후 스택 전체를 교체하지 않고도 충분히 감사할 수 있는 좁은 범위입니다.
이번 주에 수행해야 할 작업은 다음과 같습니다.
구매자 대상 반품, 교환 및 구독 앱의 인벤토리를 파악하십시오.
각 벤더에게 Customer Account API 인증이 프로덕션 환경의 기본 방식인지 문의하십시오.
제어된 테스트 주문으로 모든 구매자 진입 경로를 테스트하십시오.
배송 전 주문 수정과 배송 후 반품을 구분하십시오.
증빙, 담당자, 기한 및 대체 경로를 기록하십시오.
목표는 보여주기식 마이그레이션이 아닙니다. 대행사가 보증할 수 있는 객관적인 증빙을 바탕으로, 구매 후 여정 전반에 걸쳐 신뢰할 수 있는 일관된 고객 식별 프로세스를 확보하는 것입니다.

자주 묻는 질문 (FAQ)
이 답변들은 대행사와 Plus 운영자가 2026년 12월 1일 이전에 해결해야 할 10가지 질문을 다룹니다. 발표된 규정은 간결하므로, 가장 안전한 접근법은 Shopify의 정확한 요구사항과 여전히 벤더 증빙 및 테스트 주문이 필요한 운영상의 결론을 명확히 구분하는 것입니다.
2026년 12월 1일에 무엇이 변경되나요?
해당 반품, 교환 및 구독 앱은 Built for Shopify 상태를 유지하기 위해 Customer Account API를 기본 고객 인증 방법으로 사용해야 합니다. 이 규정은 앱이 구매자 대상 셀프 서비스 환경을 제공할 때 적용됩니다. Shopify는 2026년 6월 17일에 이 마감일을 발표했습니다.
반품 앱이 12월 1일에 작동을 멈추나요?
Shopify는 대상 앱이 12월 1일에 자동으로 작동을 멈춘다고 밝히지 않았습니다. 공식적으로 발표된 결과는 요구사항을 충족하지 못한 앱이 Built for Shopify 상태를 잃을 위험이 있다는 것입니다. 판매자는 서비스 지속성에 대해 벤더에 문의하고, 가동 중단을 추측하기보다는 테스트 주문을 통해 고객 여정을 검증해야 합니다.
이 요구사항이 모든 Shopify 앱에 적용되나요?
아니요, 발표된 요구사항은 모든 Shopify 앱에 적용되지 않습니다. Shopify는 구매자 대상 셀프 서비스를 제공하는 반품 및 교환 앱과 구독 앱을 지정했습니다. 배송 추적, 고객 센터, 주문 수정, 창고 및 기타 카테고리는 Shopify나 벤더가 카테고리별 증빙을 제공하지 않는 한 대상 범위에 포함되지 않는 것으로 간주해야 합니다.
판매자가 API 마이그레이션을 담당해야 하나요?
API 마이그레이션은 앱 개발사가 구현하며, 판매자는 벤더 및 운영 리스크 관리를 담당합니다. 대행사는 벤더의 프로덕션 적용 상태를 확인하고, 영향을 받는 구매자 플로우를 테스트하고, 대체 계획을 문서화해야 합니다. 판매자가 Shopify 관리자 설정에서 서드파티 앱의 인증 아키텍처를 직접 수정할 수는 없습니다.
Customer Account API란 무엇인가요?
Customer Account API는 계정 데이터에 대해 인증된 구매자 액세스를 제공하는 Shopify의 인터페이스입니다. 이를 통해 앱은 로그인한 고객의 주문, 프로필 정보, 주소 등의 정보와 연동하여 작업할 수 있습니다. Shopify는 이를 고객 계정, 스토어프런트 및 연결된 앱 전반의 공통 인증 레이어로 규정하고 있습니다.
이 API는 Customer Account UI 확장과 동일한가요?
아니요, 인증과 인터페이스 배치는 서로 다른 개념입니다. Customer Account API는 인증된 데이터 액세스를 제어합니다. Customer Account UI 확장은 Shopify 계정 영역 내에 앱 경험을 표시하므로, 앱은 두 가지가 모두 필요할 수 있으며 그럼에도 해당 API가 기본 인증 수단인지 확인해야 합니다.
반품 포털 전체가 마이그레이션되어야 하나요?
발표된 12월 규정은 구체적으로 Customer Account API를 기본 인증 방법으로 사용할 것을 요구합니다. 모든 화면이 하나의 Shopify 인터페이스 내부에서 재구축되어야 한다고 명시하고 있지는 않습니다. 대행사는 어떤 인터페이스와 백엔드 컴포넌트가 변경되는지 벤더에 확인하고, 인증이 모든 후속 단계에 영향을 미치므로 전체 플로우를 테스트해야 합니다.
비회원(Guest) 주문은 어떻게 테스트해야 하나요?
벤더가 지원하는 실제 링크와 인증 상태를 통해 비회원 주문을 테스트하십시오. 확인 이메일 인입 경로, 로그아웃 상태의 브라우저, 세션 만료, 다른 기기에서의 재방문 등을 포함하십시오. 로그인 계정 테스트 성공이 비회원 또는 사전 인증된 모든 경로의 준비 상태를 보장한다고 가정하지 마십시오.
판매자가 현재 사용 중인 반품 앱을 계속 유지할 수 있나요?
네, 벤더가 신뢰할 수 있는 규정 준수 경로를 제시하고 프로덕션 워크플로 테스트를 통과한다면 가능합니다. 마감일 자체가 판매자에게 앱 교체를 요구하는 것은 아닙니다. 교체는 벤더가 증빙을 제공하지 못하거나, 합의된 일정을 맞추지 못하거나, 통제된 구매자 여정 테스트에 실패할 때 내리는 운영상의 결정입니다.
대행사는 규정 준수 증빙 자료로 무엇을 보관해야 하나요?
벤더 서면 답변, 테스트 날짜, 구매자 플로우 기록, 테스트 주문 ID, 최종 Shopify 상태 및 에스컬레이션 담당자를 보관하십시오. 벤더가 공유할 수 있는 경우, 앱의 현재 Built for Shopify 상태 스크린샷과 관련 Partner Dashboard 증빙을 추가하십시오. 기록에는 계획된 작업뿐만 아니라 실제로 관측된 동작이 포함되어야 합니다.
관련 아티클
이 3가지 가이드는 Built for Shopify Customer Account API 요구사항과 연관된 고객 계정, 결제 및 주문 운영 변경 사항을 다룹니다.
지금 증빙 수집을 완료하고, 각 시스템이 고유의 운영 단계에 집중되도록 보장하며, 막연한 추측이 아닌 검증된 고객 여정을 가지고 12월 1일을 대비하십시오.



