쿠팡 OpenAPI 7월 31일 전 브랜드 식별값 점검법

2026년 6월 15일 쿠팡 Developer Center 공식 FAQ는 쿠팡 브랜드 관리 강화와 관련해 OpenAPI 연동을 쓰는 판매자와 개발사에게 2026년 7월 31일 전까지 시스템 검토와 연동 업그레이드를 완료하라고 안내했습니다.

이 글은 그 공지를 기준으로, 쿠팡에 직접 OpenAPI로 상품을 등록하거나 외부 솔루션으로 API 연동 등록하는 셀러가 무엇을 확인해야 하는지 정리합니다. 결론은 마지막에 있는 네 가지 질문을 내부 개발자, ERP 담당자, 상품등록 솔루션 고객센터에 보내는 것입니다.

먼저 할 일은 세 단계입니다.

첫째, 내 상품 등록 경로가 WING 수기 등록인지, 직접 OpenAPI 연동인지, ERP·상품등록 솔루션을 통한 API 연동인지 구분합니다. WING에서 직접만 등록하는 셀러는 WING 안내와 수정 경로 확인이 중심이고, 솔루션/API로 신규 등록하는 셀러는 연동 담당자 확인이 중심입니다.

둘째, 상품명에 보이는 브랜드명과 쿠팡 시스템이 쓰는 브랜드 식별값이 별도로 저장되고 전송되는지 확인합니다. 공식 FAQ에 나온 brandId는 보이는 브랜드 글자와 매핑되는 별도 식별값으로 이해하면 됩니다.

셋째, 브랜드별로 식별코드가 필요한지 먼저 확인한 뒤, 필요한 브랜드에만 MPN 또는 GTIN 준비를 붙입니다. isUIDRequired는 브랜드 검색 결과에서 식별코드 필요 여부를 알려주는 값입니다. 이 값이 참이면 MPN 또는 GTIN이 필요하고, 거짓이면 필수 입력 대상이 아닙니다.

중요한 점은 “브랜드가 보인다”와 “브랜드 처리가 끝났다”가 같지 않다는 것입니다. 또 “브랜드 상품이면 모두 GTIN이 필요하다”도 아닙니다. 이 글은 바코드 발급 일반론이 아니라, 7월 31일 전 연동 담당자에게 물어야 할 질문을 만드는 데 초점을 둡니다.

내 상품 등록 경로가 이번 점검 대상인가?

가장 먼저 볼 것은 상품 자체가 아니라 등록 경로입니다. 쿠팡 WING에서 판매자가 직접 화면을 열어 상품을 하나씩 등록하고 수정한다면, 개발자가 OpenAPI 요청을 바꾸는 문제와는 거리가 있습니다. 이 경우에는 WING 공지, 상품 조회·수정 화면, 누락 속성 안내를 확인하는 것이 우선입니다.

반대로 자사몰, ERP, 상품 대량 등록 도구, 마켓 통합 관리 솔루션을 통해 쿠팡 상품을 등록한다면 이야기가 달라집니다. 셀러가 화면에서 브랜드명을 입력하더라도, 실제로 쿠팡에 전달되는 요청은 솔루션 또는 내부 개발 시스템이 만듭니다. 이때 보이는 브랜드명, 쿠팡 표준 브랜드 식별값, 브랜드별 식별코드 필요 여부, MPN·GTIN 전달 위치가 서로 맞아야 합니다.

그래서 첫 질문은 “우리 회사에서 쿠팡 상품 등록 요청을 누가 만들고 있는가?”입니다. 내부 개발팀이 직접 만들 수도 있고, 외부 개발사가 맡고 있을 수도 있습니다. 월 이용료를 내는 상품등록 솔루션이라면 고객센터나 기술 담당자가 소유자입니다. 이 소유자를 찾지 못하면 7월 31일 전 점검은 막연한 공지 읽기로 끝납니다.

이 글은 2026년 6월 15일 쿠팡 공식 FAQ와 제공된 공개 자료를 기준으로 합니다. 쿠팡이 이후 별도 정정, 연기, WING 개별 안내를 냈는지는 이 자료만으로 단정할 수 없으므로, 실제 변경 전에는 자신의 Coupang Developer Center와 WING 공지를 함께 확인하세요.

그래도 지금 할 일은 변하지 않습니다. 내 등록 경로와 연동 담당자를 먼저 확인하고, 외부 솔루션을 쓴다면 이 글 마지막의 네 질문을 그대로 보내면 됩니다.

수기 등록 셀러도 완전히 무관하다고 보면 안 됩니다. 기존 상품에 누락된 필수 속성 안내가 WING에 뜨는 경우에는 WING 화면에서 직접 처리해야 할 수 있습니다. 다만 “내가 API 문서를 읽고 필드를 고쳐야 하나?”라는 질문은 연동 경로를 쓰는 셀러에게 우선적으로 해당합니다.

따라서 점검은 상품 수량이 많은 순서가 아니라 등록 경로가 자동화되어 있는 순서로 잡는 편이 현실적입니다. 새 상품을 계속 올리는 채널, 쿠팡 등록 실패가 곧 매출 일정에 영향을 주는 카테고리, 외부 솔루션 의존도가 높은 계정을 먼저 확인하세요.

상품명에 브랜드가 보이면 브랜드 처리가 끝난 것인가?

아닙니다. 상품명에 브랜드가 들어가 있다는 사실은 구매자나 운영자가 보는 텍스트 정보에 가깝습니다. 쿠팡 공식 FAQ가 설명하는 brandId는 기존 텍스트 형태의 brand, 즉 브랜드명과 매핑되는 별도 식별값입니다. 셀러 입장에서는 “화면에 보이는 이름”과 “쿠팡 시스템이 표준 브랜드로 인식하는 값”을 나누어 보는 것이 출발점입니다.

예를 들어 상품명에 브랜드명이 들어 있고, 솔루션의 상품 카드에도 브랜드명이 보인다고 해도, 쿠팡 등록 요청에 별도 브랜드 식별값이 실려 있는지는 다른 문제입니다. 솔루션이 브랜드명을 단순 글자로만 보관하고 있을 수도 있고, 쿠팡 브랜드 검색 결과에서 찾아온 표준 식별값까지 함께 저장하고 있을 수도 있습니다.

실무 질문은 “우리 상품 데이터에는 브랜드명과 쿠팡 브랜드 식별값이 따로 있나요?”입니다. 이 질문을 개발자에게 던질 때는 필드명만 묻기보다, 화면에서 보이는 이름이 쿠팡의 표준 브랜드 정보와 어떻게 연결되는지 설명해 달라고 요청하는 편이 좋습니다.

공식 FAQ는 상품명에는 브랜드명이 포함되어 있는데 brand 필드를 비워두면 상품 승인이 거절되거나 노출이 크게 제한될 수 있다고 경고합니다. 이 문장은 쿠팡 공식 문서의 경고로 이해해야 합니다. 다만 브랜드 정보를 맞춘다고 해서 심사 통과나 노출이 자동으로 보장되는 것은 아닙니다.

브랜드가 객관적으로 없거나 식별코드가 존재하지 않는 상품도 있을 수 있습니다. 공식 FAQ는 그런 상품은 해당 값을 비워둘 수 있다고 설명합니다. 하지만 이 예외를 “잘 모르겠으면 비워도 된다”로 받아들이면 위험합니다. 상품명, 상세페이지, 제조사 표기, 공급사 자료에 브랜드가 보이는지 먼저 확인해야 합니다.

중급 셀러라면 상품 목록을 네 칸으로 나눠 보세요. 판매자가 쓰는 브랜드명, 쿠팡 표준 브랜드 식별값, 식별코드 필요 여부, MPN 또는 GTIN 보유 여부입니다. 실제 엑셀을 만들지 않더라도 이 네 칸을 섞지 않는 것이 중요합니다.

내 브랜드는 식별코드가 필요한 브랜드인가?

이번 공지를 GTIN 공지로만 읽으면 중요한 순서가 바뀝니다. 공식 FAQ의 핵심은 모든 상품에 무조건 MPN 또는 GTIN을 넣으라는 말이 아닙니다. 먼저 브랜드 검색 결과에서 식별코드 필요 여부를 확인하고, 그 브랜드가 필수 대상인지 판단하라는 구조입니다.

isUIDRequired는 영어 필드명이지만 셀러에게 필요한 뜻은 단순합니다. “이 브랜드는 고유 식별코드가 필수인가?”입니다. 값이 참이면 MPN 또는 GTIN을 반드시 준비해야 하는 브랜드입니다. 값이 거짓이면 필수 입력 대상이 아니며, 선택 정보로 볼 수 있습니다.

여기서 MPN은 제조사 품번, GTIN은 국제 상품 식별번호로 이해하면 됩니다. 개발 문서의 영문 이름을 외우는 것보다 중요한 것은 “브랜드가 요구하는 경우에만 필수 점검으로 올린다”는 순서입니다. 필요 여부를 보지 않은 채 모든 상품에 바코드나 품번을 채우려 하면, 불필요한 업무가 커지고 실제로 막히는 브랜드를 놓칠 수 있습니다.

실무에서는 브랜드별로 세 묶음을 만들면 됩니다. 첫째, 식별코드 필요 여부가 참이고 MPN 또는 GTIN이 이미 준비된 상품입니다. 이 묶음은 전송 위치와 형식만 확인하면 됩니다. 둘째, 참이지만 식별코드가 없는 상품입니다. 이 묶음은 제조사, 수입사, 공급사 자료를 확인하거나 상품 운영 방식을 다시 정해야 합니다. 셋째, 거짓인 상품입니다. 이 묶음은 필수 누락 문제로 과하게 처리하지 않도록 구분합니다.

같은 브랜드와 같은 모델인데 색상이나 사이즈만 다른 옵션은, 해당 FAQ 기준으로 일반적으로 동일한 식별코드 사용이 허용될 수 있습니다. 다만 상세한 유효성 검사는 정식 배포 후 OpenAPI 응답 오류로 확인하라고 안내되어 있으므로, 대량 옵션 상품의 예외 검토로만 다루는 편이 안전합니다.

외부 솔루션을 쓴다면 “GTIN 입력칸이 있나요?”보다 “브랜드 검색 결과의 식별코드 필요 여부를 먼저 확인하나요?”라고 물어야 합니다. 입력칸이 있다는 것과 필요한 브랜드에만 필수 검사를 적용한다는 것은 다릅니다. 셀러가 원하는 것은 빈칸을 늘리는 기능이 아니라, 어떤 상품을 반드시 보완해야 하는지 가려내는 흐름입니다.

기존 상품과 신규 상품은 같은 방식으로 봐도 되는가?

기존 등록 상품과 신규 등록 상품은 같은 방식으로 보면 안 됩니다. 공식 FAQ는 기존 등록 상품의 경우 6월 1일 이후 필수 식별코드 정보가 입력되지 않았다는 이유만으로 즉시 판매 중지되거나 노출 종료되지는 않는다고 설명합니다. 이 문장은 기존 상품을 당장 무시해도 된다는 뜻이 아니라, “즉시 중지”로 과장하지 말라는 뜻에 가깝습니다.

기존 상품에서 할 일은 WING 안내를 확인하고, 누락된 필수 속성이나 식별코드 입력 대상이 뜨는지 보는 것입니다. 이미 판매 중인 상품의 브랜드 관련 속성을 OpenAPI로 직접 수정할 수 있는지는 별도 문제입니다. 2026년 6월 15일 공식 FAQ 기준으로는 OpenAPI 인터페이스로 기존 상품의 brandId 같은 속성 필드를 직접 수정하거나 업데이트하는 기능을 지원하지 않는다고 설명합니다.

신규 상품은 더 민감합니다. 새로 등록하는 상품은 심사 단계에서 필수 속성 누락이 영향을 줄 수 있습니다. 특히 브랜드 식별값과 식별코드 필요 여부가 제대로 처리되지 않으면, 셀러는 화면에서 입력했다고 생각했는데 실제 쿠팡 등록 요청에서는 빠지는 상황을 만날 수 있습니다.

그래서 기존 상품은 “WING에서 보완 안내가 뜨는가?”를 중심으로 보고, 신규 상품은 “등록 요청이 새 필드와 조건부 식별코드 규칙을 반영하는가?”를 중심으로 봐야 합니다. 한 문장으로 줄이면, 기존 상품은 수정 경로 점검, 신규 상품은 등록 경로 점검입니다.

우선순위도 이 기준으로 잡으세요. 먼저 매일 신규 등록이 발생하는 카테고리와 곧 출시할 핵심 상품군을 확인합니다. 다음으로 WING 보완 안내가 뜬 기존 상품을 처리합니다. 마지막으로 비활성 상품이나 업데이트 빈도가 낮은 상품은 앞의 두 흐름이 정리된 뒤 점검해도 늦지 않습니다.

이 차이를 모르면 팀 안에서 서로 다른 답을 하게 됩니다. 운영자는 “기존 상품이 바로 중지되는 건 아니래요”라고 말하고, 개발자는 “그럼 연동 수정 안 해도 되나요?”라고 묻습니다. 하지만 공식 FAQ는 기존 상품의 즉시 중지 여부와 신규 상품 등록 심사 영향을 분리해서 설명합니다. 둘 중 하나만 읽으면 의사결정이 흐려집니다.

API 키 발급 시점은 왜 확인해야 하는가?

공식 FAQ는 신규 상품 처리에서 API 키 발급 시점을 나누어 설명합니다. 2026년 6월 1일 이후 API 키를 새로 발급받은 이용자는 필수 속성이 누락될 경우 상품 등록 심사 단계에서 즉시 반려될 수 있다고 설명합니다. 이 경우에는 “나중에 고치자”가 아니라 등록 전 점검이 우선입니다.

반면 2026년 6월 1일 이전에 API 키를 발급받은 기존 이용자는 단기적으로 신규 상품 등록 시 즉시 오류가 나거나 차단되지는 않지만, 2026년 7월 31일 전까지 API 업그레이드를 완료해야 한다고 안내되어 있습니다. 업그레이드를 완료하지 않을 경우 2026년 7월 31일 이후 신규 상품 등록이 심사 단계에서 반려 또는 차단될 수 있다고 안내되어 있습니다.

따라서 담당자에게는 “우리 API 키가 언제 발급됐나요?”를 먼저 물어야 합니다. 셀러가 직접 모르면 내부 개발자나 외부 솔루션사에 확인 요청하면 됩니다. 중요한 것은 같은 쿠팡 계정이라도 연동 키의 발급 시점에 따라 신규 상품 검증 흐름을 다르게 봐야 한다는 점입니다.

여기서도 7월 31일을 만능 날짜로 쓰면 안 됩니다. 이 날짜는 공식 FAQ가 시스템 검토와 연동 업그레이드를 완료하라고 안내한 기준일입니다. 모든 상품이 그날 동시에 판매 중지된다는 뜻도 아니고, 그날 전까지 아무 영향도 없다는 뜻도 아닙니다. API 키 발급 시점, 신규 등록 여부, 필수 속성 누락 여부를 함께 봐야 합니다.

실무 점검 문장은 이렇게 바꿔 보세요. “우리 솔루션은 API 키를 언제 발급받았는지에 따라 새 상품 심사 전 점검을 다르게 하나요?” 이 질문은 단순히 날짜를 아는 것보다 낫습니다. 날짜를 기준으로 실제 검증 흐름이 달라지는지 확인하게 만들기 때문입니다.

만약 외부 솔루션사가 “브랜드 입력은 지원합니다”라고만 답한다면 한 단계 더 물어야 합니다. 브랜드 입력 지원, 브랜드 식별값 조회, 브랜드별 식별코드 필요 여부 확인, API 키 발급 시점별 신규 등록 검증은 모두 다른 기능입니다. 판매자는 각 기능이 어디까지 공개적으로 지원되는지 확인해야 합니다.

WING에서 고칠 일과 API에서 확인할 일은 어떻게 나누는가?

기존 상품 보완과 신규 상품 등록 연동은 처리 장소가 다릅니다. 공식 FAQ는 기존 판매 중인 상품의 정보를 수정하려면 WING 대시보드 수정 방식을 안내하라고 설명합니다. 방법은 개별 상품 수정과 엑셀 대량 업로드입니다.

개별 수정은 WING > 상품 관리 > [상품 조회/수정] 메뉴로 이동한 뒤, 상단의 “정보 업데이트하고 매출 올리기” 영역에서 “누락된 필수 옵션 정보 입력” 또는 “필수 속성 입력” 대상 상품을 확인하는 흐름입니다. 이후 상품 수정을 클릭해 누락된 식별코드를 입력하고 저장합니다.

대량 작업은 WING > 상품 관리 > [상품 조회/수정] 메뉴의 “정보 업데이트하고 매출 올리기” 영역 하단에서 [누락된 필수 속성 정보 일괄 입력] 버튼을 클릭하는 방식입니다. [1단계]에서 엑셀 템플릿을 내려받아 누락된 속성이나 식별코드를 입력해 저장하고, [2단계]에서 파일을 업로드해 반영합니다.

여기서 AI 추천이 보이는 경우도 있을 수 있습니다. 공식 FAQ는 추천이 노출되는 경우 검토 후 반영할 수 있지만, 판매자가 직접 검토하고 저장해야 최종 적용된다고 안내합니다. 따라서 추천값이 보인다는 사실을 자동 수정으로 말하면 안 됩니다. 셀러의 검토와 저장이 빠지면 적용됐다고 볼 수 없습니다.

API에서 확인할 일은 다릅니다. 신규 상품 등록 요청이 쿠팡의 브랜드 식별값을 담을 수 있는지 봐야 합니다. 또 브랜드 검색, 등록 브랜드 목록, 브랜드 ID 조회 같은 새 API를 어떤 순서로 쓰는지 확인해야 합니다. 마지막으로 GTIN 또는 MPN은 상품 속성 입력값 안에서 요구되는 형식으로 전달되는지 점검해야 합니다.

업무 분리는 단순합니다. 기존 상품 보완은 WING의 개별 수정 또는 엑셀 대량 업로드로 안내되는지 확인하세요. 신규 상품 등록은 API 연동에서 브랜드 식별값과 식별코드 조건을 반영하는지 확인하세요. 이 둘을 섞으면 기존 상품을 API로 고치려 하거나, 신규 등록 실패를 WING 사후 보정으로만 해결하려는 혼선이 생깁니다.

Selzy 같은 외부 상품등록 도구를 쓰는 셀러도 같은 원칙으로 물어야 합니다. Selzy 공개 기능 페이지는 쿠팡 상품 등록·편집, 상품 일괄 업로드, 등록상품 일괄 수정 같은 기능을 소개합니다. 그러나 제공된 공개 자료만으로는 이번 쿠팡 브랜드 API 변경 대응 완료, 브랜드 식별값 자동 점검, GTIN·MPN 필요 여부 자동 판정, 자동 보정을 확인할 수 없습니다.

따라서 도구 이름만 보고 안심하지 말고, 자신이 쓰는 기능이 이번 공지의 어느 부분을 지원하는지 확인해야 합니다. 이 확인은 특정 솔루션을 불신하라는 뜻이 아니라, 공개 기능 소개와 실제 연동 대응 범위를 구분하라는 뜻입니다.

7월 31일 전 담당자에게 무엇을 물어야 하는가?

마지막으로 질문을 문장으로 만들어야 합니다. 공지는 개발 문서처럼 보이지만, 셀러의 일은 문서를 번역하는 것이 아니라 책임 있는 담당자에게 확인 가능한 질문을 던지는 것입니다. 아래 네 질문은 내부 개발자, 외부 개발사, ERP 담당자, 상품등록 솔루션 고객센터에 그대로 보낼 수 있습니다.

첫째, “우리 상품 등록 요청에서 보이는 브랜드명과 쿠팡 브랜드 식별값을 별도 필드로 저장하고 전송하나요?” 이 질문은 상품명에 브랜드가 보이는지보다 한 단계 깊습니다. 쿠팡 표준 브랜드와 매핑되는 별도 식별값이 있는지 확인하게 합니다.

둘째, “브랜드 검색 결과의 식별코드 필요 여부를 확인해 true인 브랜드에만 MPN 또는 GTIN 필수 검사를 적용하나요?” 여기서 true는 식별코드가 필요한 브랜드라는 뜻입니다. 모든 상품에 GTIN을 요구하는지 묻는 것이 아니라, 브랜드별 조건을 먼저 보는지 묻는 질문입니다.

셋째, “2026년 6월 1일 이후 발급된 API 키와 그 이전 API 키를 구분해 신규 상품 등록 검증 흐름을 다르게 처리하나요?” 이 질문은 날짜를 단순 일정으로 보지 않게 만듭니다. 공식 FAQ가 나눈 신규 API 키와 기존 API 키의 차이를 실제 등록 흐름에 반영하는지 확인하는 질문입니다.

넷째, “기존 등록 상품의 브랜드 관련 수정이 필요할 때 OpenAPI가 아니라 WING 개별 수정 또는 WING 엑셀 입력으로 안내하나요?” 기존 상품 보완을 신규 등록 API 수정과 섞지 않기 위한 질문입니다. 특히 이미 판매 중인 상품이 많은 셀러에게 중요합니다.

이 네 질문에 대한 답이 모호하면, 7월 31일 전에는 새 상품 등록 실패가 발생했을 때 원인을 찾는 데 시간이 오래 걸릴 수 있습니다. 브랜드명이 빠진 것인지, 브랜드 식별값이 없는 것인지, 그 브랜드가 식별코드 필수 대상인지, MPN 또는 GTIN 값이 준비되지 않은 것인지 분리해서 봐야 하기 때문입니다.

담당자에게는 샘플 묶음을 함께 보내세요. 최근 등록한 SKU, 다음 출시 예정 SKU, 브랜드가 있는 상품 예시, 객관적으로 브랜드가 없는 상품 예시, 같은 모델에 색상이나 사이즈만 다른 옵션 상품 예시, API 키 발급일 확인 요청을 한 번에 묶으면 됩니다. 담당자는 실제 사례가 있어야 연동 흐름을 확인하기 쉽습니다.

마지막으로 이 점검은 승인, 노출, 판매, 정책 준수를 보장하는 작업이 아닙니다. 다만 등록 요청이 2026년 6월 15일 공식 FAQ의 브랜드 관리 강화 방향과 어긋나는지 미리 확인하는 작업입니다. 7월 31일 전까지 해야 할 일은 불안한 상품을 모두 바코드 작업으로 몰아넣는 것이 아니라, 보이는 브랜드명, 브랜드 식별값, 브랜드별 식별코드 필요 여부, MPN 또는 GTIN 준비 상태를 차례로 분리하는 것입니다.

그 순서가 잡히면 담당자와의 대화도 짧아집니다. “브랜드 입력 되나요?”가 아니라 “브랜드명과 식별값을 분리해 전송하나요?”, “필요 브랜드만 MPN 또는 GTIN을 필수로 보나요?”, “기존 상품은 WING 보완 경로로 안내하나요?”라고 물을 수 있습니다. 이 정도까지 확인하면 이번 공지를 셀러의 실제 운영 체크리스트로 바꿀 수 있습니다.