네이버 커머스 API: 그룹상품 관부가세 부과 여부 입력 방식 변경 안내 (2026년 6월 24일 적용)

한 줄 결론

2026년 6월 24일부터 네이버 커머스 API를 통한 그룹상품 등록 및 관리 시, 관부가세 부과 여부를 기존의 ‘그룹상품 일괄 단위’가 아닌 ‘개별 판매옵션 조합 단위’로 각각 지정하도록 데이터 입력 방식이 전면 변경되었으며, 기존 방식은 예고 없이 지원이 종료될 예정입니다.

적용 대상 빠른 판별

공식 자료로 확인된 변경 내용

네이버 커머스 API는 2026년 6월 24일(한국 표준시 기준)을 기점으로 그룹상품의 관부가세 부과 여부 입력 방식을 변경했습니다. 핵심은 기존 그룹상품 단위의 일괄 지정 방식에서 판매옵션 조합 개별 단위 지정 방식으로의 전환입니다. 이 설정 내용은 대상이 되는 판매옵션 조합에만 한정적으로 적용되어 실제 구매자에게 표시되므로, 정확한 데이터 연동이 필수적입니다.

1. 대상 API 목록

• [상품] 그룹상품 등록 (POST /v2/standard-group-products)
• [상품] 그룹상품 전환 (POST /v2/standard-group-products/convert-products)
• [상품] 그룹상품 조회 (GET /v2/standard-group-products/:groupProductNo)
• [상품] 그룹상품 수정 (PUT /v2/standard-group-products/:groupProductNo)

2. 데이터 구조 변경 상세

신규 추가 (판매옵션 조합 단위): specificProducts 필드의 차일드 노드에 customsTaxType 필드가 새롭게 추가되었습니다. 이 필드는 대상이 되는 개별 판매옵션 조합(원상품)의 관부가세 부과 여부를 명확하게 표현합니다.

지원 종료 예정 (그룹상품 단위): 기존에 제공되던 groupProduct 필드 차일드 노드의 customsTaxType 필드는 지원 종료(Deprecation) 계획이 확정되었습니다.

3. 필드 값 범례 (데이터 타입: String Enum)

• NOT_APPLICABLE: 관부가세 부과 대상 아님
• INCLUDED: 관부가세 포함 (상품 가격에 관부가세가 이미 포함되어 있음)
• EXCLUDED: 관부가세 미포함 (구매자가 통관 시 별도로 부담해야 함)

※ 기존 필드 값 범례와 동일하게 유지됩니다.

4. API 요청 JSON 페이로드(Payload) 적용 예시 및 해석

네이버 커머스 API 공지사항에서 제공한 예시 구조를 살펴보면 변경된 정책의 작동 방식을 명확히 이해할 수 있습니다. 만약 API 요청 본문(JSON)이 다음과 같이 구성되어 있다고 가정해 보겠습니다.

그룹상품 최상위 노드인 groupProduct 하위의 customsTaxType에는 EXCLUDED(관부가세 미포함)가 설정되어 있고, 개별 판매옵션 조합을 의미하는 specificProducts 배열 내의 특정 객체 하위 customsTaxType에는 INCLUDED(관부가세 포함)가 설정된 상황

이러한 구성으로 API를 호출할 경우, 네이버 커머스 API 서버는 다음과 같은 규칙을 적용하여 데이터를 처리합니다. 첫째, 판매옵션 조합 단위(groupProduct.specificProducts[n].customsTaxType)에 설정한 ‘관부가세 포함(INCLUDED)’ 데이터를 최종적으로 채택하여 실제 서비스에 적용합니다. 둘째, 그룹상품 단위(groupProduct.customsTaxType)에 설정한 ‘관부가세 미포함(EXCLUDED)’ 데이터는 시스템에서 완전히 무시 처리합니다. 이는 해당 필드가 지원 종료 예정(Deprecated) 상태이기 때문입니다.

5. 특수 조건에 따른 예외 처리 규칙

해외직구 쇼핑윈도 연동 상품: 네이버쇼핑 해외직구 쇼핑윈도에 연동되는 상품은 정책상 반드시 INCLUDED(관부가세 포함) 값으로만 연동이 가능합니다. 다른 값을 입력할 경우 연동에 실패하거나 정책 위반이 될 수 있습니다.

국내 출고 상품: 상품의 출고 주소지가 대한민국 내 주소지인 경우, API 요청 데이터에 customsTaxType 필드 값이 포함되어 있더라도 시스템에서 이를 모두 무시하며 데이터베이스에 저장하지 않습니다.

실무자가 오해하기 쉬운 부분

오해 1: 기존 API 필드를 당분간 계속 써도 문제가 없을 것이다.
가장 위험한 오해입니다. 네이버 측은 판매옵션 조합 단위에 관부가세 부과 여부가 설정되지 않은 경우에 한하여, 기존 그룹상품 단위의 설정을 ‘임시로’ 적용한다고 밝혔습니다. 그러나 이는 어디까지나 한시적 적용이며, 향후 별도의 예고 없이 완전한 지원 종료가 이루어질 수 있습니다. 또한, 공지사항에 따르면 기존 필드의 설정 값은 실제 서비스에 반영되지 않거나 신규 필드 설정 값 대비 낮은 우선순위로 처리될 수 있으므로 기존 방식 유지는 매우 위험합니다.

오해 2: 해외직구 쇼핑윈도 상품에 관부가세 미포함(EXCLUDED)을 설정할 수 있다.
불가능합니다. 해외 주소지 출고 그룹상품의 판매옵션 조합 중 ‘네이버쇼핑 해외직구 쇼핑윈도’ 연동 상품은 customsTaxType 필드 값을 반드시 ‘관부가세 포함(INCLUDED)’으로만 연동해야 정상적으로 처리됩니다.

오해 3: 국내 배송 상품도 API 스펙에 맞춰 관부가세 필드를 정확히 전송해야 한다.
출고지가 국내인 경우 네이버 커머스 API 서버가 해당 필드 자체를 무시하고 저장하지 않으므로, 국내 배송 전용 상품에 대해서는 관부가세 필드 전송 로직에 리소스를 투입할 필요가 없습니다. 불필요한 데이터 전송을 줄이는 것이 권장됩니다.

오해 4: 한시적 적용 기간 동안에는 기존 방식과 신규 방식을 혼용해도 시스템이 알아서 최적화해 줄 것이다.
공지사항 원문에 따르면, 기존 필드의 설정 값은 실제 서비스에 반영되지 않거나 신규 필드 설정 값 대비 ‘낮은 우선순위’로 처리될 수 있다고 명확히 경고하고 있습니다. 즉, 시스템이 알아서 최적화해 주는 것이 아니라, 데이터 충돌이나 누락의 위험을 판매자가 고스란히 안게 되는 구조입니다. 가급적 판매옵션 조합 단위별 별도 설정으로 빠른 대응을 하는 것만이 유일한 해결책입니다.

지금 할 일

해외 주소지 출고 상품을 취급하는 크로스보더 판매자와 시스템 개발 담당자는 다음 사항을 즉각적으로 이행해야 합니다. 기존 필드의 호환성은 한시적으로만 유지되므로, 변경 적용일(2026년 6월 24일)에 맞춰 변동 내용을 API 연동에 신속히 반영하는 것이 중요합니다. 단순한 코드 수정을 넘어, 실제 상품 데이터베이스와 API 연동 모듈 간의 정합성을 맞추는 작업이 필요합니다.

• 현황 파악: 자사 쇼핑몰 솔루션 또는 ERP 시스템에서 네이버 스마트스토어로 전송하는 그룹상품 데이터베이스 구조를 점검하고, 현재 관부가세 데이터가 어느 노드에 매핑되어 있는지 확인하십시오.
• 데이터 매핑 변경: 기존에 상품 마스터(Master) 테이블 기준으로 일괄 전송하던 관부가세 설정 값을, 개별 단품/옵션(SKU) 테이블 기준으로 전송할 수 있도록 데이터 매핑 아키텍처를 재설계해야 합니다. 기존 groupProduct.customsTaxType 필드를 사용하는 코드를 식별하여 지원 종료(Deprecated) 예정임을 주석 처리하고, 새로운 specificProducts 하위 노드로 데이터를 매핑하는 개발 일정을 수립하십시오.
• 예외 처리 로직 구현: 상품 출고지가 국내인 경우 해당 필드를 API 요청에서 제외하는 로직을 추가하여 불필요한 데이터 전송을 방지하십시오.
• 쇼핑윈도 전용 검증: 해외직구 쇼핑윈도 카테고리로 매핑된 상품이 전송될 때, customsTaxType 값이 INCLUDED가 아닌 다른 값(EXCLUDED 또는 NOT_APPLICABLE)으로 설정되어 있다면 API 호출 전 단계에서 에러를 발생시키는 자체 유효성 검사(Validation) 로직을 도입하십시오.
• 확인 강화: API 응답 로그를 확인하여 기존 필드 사용으로 인한 데이터 누락이나 우선순위 저하 문제가 발생하지 않는지 배포 후 집중적으로 점검하십시오.