머천트 API 전환 완벽 가이드, 놓치면 안 되는 설정 총정리

결론부터 말하면 이렇다. 구글 쇼핑 Content API는 2026년 8월 18일 완전히 종료된다. 자동 연동으로 상품 데이터를 구글 쇼핑에 밀어 넣던 쇼핑몰이라면, 후속 서비스인 머천트 API(Merchant API) 로 옮기지 않는 이상 이 시점부터 상품 등록·가격·재고 갱신이 멈춘다.

문제는 "전환해야 한다"는 사실만 알고 정작 무엇을 어떤 순서로 바꿔야 하는지는 막막한 경우가 많다는 점이다. API 구조 자체가 달라졌고, 상품 ID 형식도 바뀌었고, 피드 설정도 다시 잡아야 한다. 순서를 잘못 잡으면 전환 도중 상품 노출이 오히려 끊기는 사고로 이어질 수 있다.

이미 종료 소식만 짧게 다룬 글은 많다. 이 글은 그보다 한 걸음 더 들어가, 실제로 손을 움직여 전환을 끝내는 데 필요한 절차·설정값·오류 대응을 전부 묶은 실전 가이드다. 개발자가 직접 코드를 고치는 경우는 물론, 쇼핑몰 운영자가 담당 개발사에 정확히 무엇을 요청해야 하는지 확인하는 용도로도 쓸 수 있게 정리했다.

이 글의 핵심은 다음과 같다.

• Content API 최종 종료일은 2026년 8월 18일이고, 베타 사용자 마감(2월 28일)은 이미 지났다.
• 전환은 한 번에 스위치를 바꾸는 일이 아니라 점검 → 병행 설치 → 병행 테스트 → 전환 실행 → 정리의 5단계로 진행한다.
• 가격 형식, 상품 ID 구조, 배치 처리 방식이 전부 바뀌어 코드 수정 없이는 그대로 옮겨 붙일 수 없다.
• 상품 피드는 데이터 소스 확인부터 피드 레이블 재설정까지 별도로 다시 점검해야 한다.
• notFound, enum 대소문자 불일치 같은 오류는 전환 과정에서 거의 모든 사업자가 겪는 흔한 문제이며, 원인이 정해져 있어 미리 알면 시간을 아낄 수 있다.

머천트 API 전환, 정확히 언제까지 무엇을 해야 하나?

최종 기한은 2026년 8월 18일이다. 이 날짜를 넘기면 기존 Content API 엔드포인트로 보내는 요청은 더 이상 처리되지 않는다. 이미 등록된 상품이 검색 결과에서 그 즉시 사라지는 것은 아니지만, 신규 등록·가격 변경·재고 갱신·프로모션 반영 같은 데이터 흐름이 그 시점부터 끊긴다.

사실 마감은 두 단계로 나뉘어 있었다. 머천트 API를 미리 도입한 베타(v1beta) 사용자는 2026년 2월 28일까지 전환을 마쳤어야 했고, 이미 지난 기한이다. 아직 Content API를 쓰고 있는 나머지 모든 사업자에게 남은 마지막 기한이 바로 8월 18일이다.

구분	기한	대상
베타 사용자 전환 마감	2026년 2월 28일	머천트 API v1beta 조기 사용자
전체 서비스 종료	2026년 8월 18일	Content API 전체 사용자

머천트 API 정식 버전(v1)은 2025년 7월 일반 공개됐고, 그 이후로 v1beta 자체도 단계적으로 정리되는 중이다. 지금 새로 연동을 시작한다면 v1 버전을 기준으로 작업하는 것이 맞다. v1alpha는 아직 실험적인 기능을 시험하는 용도이므로, 운영 환경에는 정식 버전인 v1을 쓰는 편이 안전하다.

마감 이후 구체적으로 무엇이 멈추는지 정리하면 다음과 같다.

• 신규 상품 등록 중단: 새로 추가한 상품이 구글 쇼핑에 반영되지 않는다.
• 가격·재고 갱신 중단: 할인가나 품절 상태를 바꿔도 예전 값이 계속 노출된다.
• 프로모션 반영 중단: 할인 배지나 특가 표시가 갱신되지 않는다.
• 리포트 접근 제한: 성과 데이터를 API로 자동 수집하던 대시보드가 갱신을 멈춘다.
• 자동화 도구 오류: Content API를 호출하도록 짜둔 스크립트·배치 작업이 실패 응답을 계속 받는다.

CSV·XML 파일을 손으로 올리거나 쇼핑몰 빌더의 자동 연동 기능만 쓰고 있다면 직접 대응할 일은 없다. 다만 서드파티 피드 관리 툴을 쓴다면, 그 업체가 이미 머천트 API로 전환을 마쳤는지부터 확인해야 한다.

Content API와 머천트 API, 구조가 어떻게 달라지나?

이름만 바뀐 것이 아니라 데이터 구조 자체가 달라졌다. 이 차이를 모르고 기존 코드를 그대로 옮기면 대부분 오류가 난다. 가장 크게 바뀐 지점은 네 가지다.

첫째, API 구성 방식이 단일 API에서 기능별 서브 API로 나뉘었다. 상품(Products), 재고(Inventories), 계정(Accounts), 리포트(Reports), 데이터 소스(Data Sources), 프로모션(Promotions), 리뷰(Reviews), 주문 추적(Order Tracking), 이슈 해결(Issue Resolution), 비교 쇼핑 서비스(CSS) 등으로 나뉘어 있어, 필요한 기능만 골라 붙일 수 있다. 예전에는 상품 하나 조회하려 해도 거대한 단일 API 문서를 뒤져야 했다면, 지금은 "상품 관련 작업은 Products 서브 API"처럼 목적별로 문서와 엔드포인트가 분리돼 있어 오히려 찾기 쉬워졌다는 평가도 있다.

둘째, 상품 식별 방식이 숫자 ID에서 계층형 이름으로 바뀌었다. 예전 방식이 channel:language:country:offerId 형태(예: online:ko:KR:sku123)였다면, 머천트 API는 accounts/{계정ID}/products/{리소스ID} 같은 리소스 이름(name) 필드로 상품을 가리킨다.

셋째, 가격 표기가 소수점 문자열에서 마이크로 단위 정수로 바뀌었다. 기존에는 price.value(예: "19900")와 price.currency(예: "KRW")를 문자열로 넣었다면, 이제는 amountMicros(정수, 100만 배율)와 currencyCode를 쓴다.

항목	Content API(기존)	머천트 API(신규)
가격 표기	price.value: "19900" (문자열)	amountMicros: 19900000000 (정수)
통화 표기	price.currency: "KRW"	currencyCode: "KRW"
상품 ID	channel:language:country:offerId	accounts/{id}/products/{리소스ID}
일괄 처리	customBatch 메서드	비동기·병렬 개별 호출
페이지당 최대 상품 수	250개	1,000개

가격 필드를 그대로 복붙하면 100만 배 차이가 나는 값이 들어가는 사고가 흔하다. "19900"을 그대로 amountMicros에 넣으면 사실상 0원에 가까운 가격으로 등록되는 셈이다.

넷째, 일괄 처리 방식이 사라졌다. 기존 customBatch 메서드로 여러 상품을 한 번에 처리하던 방식은 머천트 API에 없다. 대신 비동기·병렬 호출로 여러 요청을 동시에 보내는 방식을 쓴다. 페이지당 최대 상품 수도 250개에서 1,000개로 늘어, 한 번에 더 많은 데이터를 주고받을 수 있게 됐다.

다섯째, 평면 구조였던 필드가 객체 단위로 묶였다. 예전에는 title, price 같은 속성이 최상위 필드로 나열돼 있었다면, 머천트 API에서는 이런 속성 대부분이 productAttributes라는 하나의 객체 안으로 들어간다. 필드 이름도 일부 바뀌었다.

Content API 필드	머천트 API 필드	비고
id	name	REST 리소스 형식, 특수문자 포함 시 base64url 인코딩
title, price 등 최상위 속성	productAttributes 객체 내부	속성들이 하나의 객체로 묶임
targetCountry	feedLabel	머천트 센터 용어에 맞춰 이름 변경
feedId	dataSource 쿼리 파라미터	모든 쓰기 요청에 필수

프로토콜 측면에서는 기존 REST 방식에 더해 gRPC가 새로 지원된다. 대량 데이터를 빠르게 처리해야 하는 경우 gRPC가 권장되지만, 기존 REST 연동 코드를 유지하면서 필드 구조만 맞춰도 전환은 가능하다. 처리량이 크지 않은 중소 쇼핑몰이라면 REST를 그대로 쓰고 데이터 구조만 새 형식에 맞추는 편이 작업량을 줄이는 길이다.

결국 이번 전환은 API 이름표만 바뀌는 일이 아니라, 데이터 모델 자체를 새로 짜는 작업이다.

전환 전 무엇부터 점검해야 하나?

가장 먼저 할 일은 코드를 고치는 게 아니라 지금 어떻게 연동돼 있는지부터 확인하는 것이다. 구조를 모른 채 손부터 대면 어느 부분이 문제인지 나중에 추적하기 어렵다.

점검 순서는 다음과 같다.

• 연동 방식 확인: 구글 머천트 센터의 설정(Settings) → 데이터 소스(Data sources) 메뉴에서 API로 연결된 피드인지, 파일 업로드 방식인지 먼저 확인한다.
• 코드 전수 조사: 백엔드 코드나 연동 로그에서 shoppingcontent.googleapis.com을 호출하는 지점을 전부 찾아 목록으로 문서화한다. 어디서 상품을 등록하고, 어디서 가격을 갱신하고, 어디서 리포트를 조회하는지 구분해 둔다.
• 서드파티 의존성 확인: 카페24·아임웹·식스샵 같은 플랫폼이나 별도 피드 관리 솔루션을 쓰고 있다면, 담당 업체가 머천트 API 전환을 이미 마쳤는지부터 물어본다. 플랫폼이 이미 대응했다면 사업자가 직접 할 일은 크게 줄어든다.
• 작업 기간 역산: 국가 하나, 피드 하나짜리 단순 구조는 약 8주, 복잡도가 중간이면 약 12주, 다국가·다피드처럼 구조가 복잡하면 16주에서 20주까지 걸릴 수 있다는 것이 업계에서 통용되는 추정치다. 남은 기간과 비교해 우선순위를 정한다.
• OAuth 권한 범위 재확인: 머천트 API는 새로운 OAuth 스코프를 요구하는 경우가 있어, 전환 전 사용자 재동의 절차가 필요할 수 있다.

역할별로 나눠 정리하면 점검이 훨씬 수월하다.

담당	점검 항목
개발 담당자	API 호출 코드 전수 조사, 클라이언트 라이브러리 버전 확인, OAuth 스코프 점검
운영·마케팅 담당자	데이터 소스 유형 확인, 서드파티 플랫폼 고객센터 문의, 작업 일정 공유
의사결정권자	남은 기간 대비 작업량 판단, 외부 개발사 투입 여부 결정

역할을 나눠 정리하는 이유는 단순하다. 전환 작업은 코드만 고치면 끝나는 일이 아니라, 데이터 소스 확인 같은 운영 영역과 코드 수정 같은 개발 영역이 동시에 맞물려 돌아가기 때문이다. 한 사람이 전부 떠안으면 점검 항목이 누락되기 쉽고, 마감이 임박한 상황에서는 그 누락이 곧바로 오류로 이어진다.

점검 단계에서 가장 자주 빠뜨리는 항목이 서드파티 의존성 확인이다. "우리는 직접 API를 안 쓴다"고 생각했다가, 실제로는 쓰고 있는 플랫폼이 뒷단에서 Content API를 그대로 물려 쓰고 있던 경우가 적지 않다.

실제 전환은 어떤 순서로 진행하나?

한 번에 전부 바꾸는 방식은 위험하다. 기존 연동을 살려둔 채 새 API를 옆에 붙이고, 검증을 마친 뒤 단계적으로 옮기는 순서가 안전하다. 실무에서 권장되는 절차는 5단계다.

1. 사용 현황 점검: 앞서 정리한 코드·연동 로그 조사를 문서로 남긴다. 어떤 엔드포인트를 어디서 호출하는지 팀 전체가 볼 수 있게 공유한다.
2. 신규 라이브러리 설치: 머천트 API 클라이언트 라이브러리를 기존 Content API 코드와 병행 설치한다. 두 API는 같은 프로젝트 안에서 공존할 수 있으므로, 기존 코드를 지우지 않고 새 코드를 옆에 추가하는 방식으로 시작한다.
3. 병행 테스트: 1주에서 2주 정도 두 API를 동시에 돌려 응답값을 비교한다. 같은 상품 조회 결과가 두 API에서 일치하는지, 가격이나 재고 수치가 정확히 변환됐는지 이 단계에서 확인한다.
4. 전환 실행: 운영 환경의 읽기(조회) 트래픽부터 새 API로 전환한다. 쓰기(등록·수정) 트래픽은 최소 1주일 더 두 API에 동시에 보내며, 문제가 생기면 곧바로 기존 API로 되돌릴 수 있는 여지를 남긴다.
5. 기존 API 정리: 안정성이 확인되면 Content API로의 쓰기 요청을 끄고, 옛 클라이언트 라이브러리와 관련 코드를 제거해 마무리한다.

이 순서를 지키면 전환 도중 데이터가 끊기는 사고를 대부분 피할 수 있다. 나쁜 예와 좋은 예를 비교하면 차이가 분명하다.

나쁜 예: 마감이 임박했다는 이유로 점검 없이 바로 코드를 바꾸고 운영 환경에 배포한다. 상품 ID 매핑이 틀어진 채로 반영돼 상품이 대량으로 거부되고, 원인을 찾는 데 오히려 더 많은 시간이 든다.

좋은 예: 병행 테스트 기간에 응답값을 하나하나 비교하며 검증한 뒤, 읽기부터 단계적으로 전환한다. 문제가 생겨도 기존 API로 즉시 되돌릴 수 있어 서비스 중단 시간이 거의 없다.

안전한 전환의 핵심은 속도가 아니라 언제든 되돌릴 수 있는 여지를 남겨두는 것이다.

상품 피드 설정, 어떻게 다시 잡아야 하나?

API 코드만 바꾼다고 끝나는 게 아니다. 피드 자체의 설정값도 새 구조에 맞춰 다시 점검해야 한다. 실제 전환에서 누락이 가장 잦은 지점이 바로 이 부분이다.

• 데이터 소스 재확인: 머천트 센터의 데이터 소스 목록에서 API 기반 소스가 올바르게 인식되고 있는지 확인한다. 전환 직후 소스 유형이 잘못 표시되는 경우가 있다.
• 상품 ID 재매핑: 기존 channel:language:country:offerId 형식으로 관리하던 상품 ID를 새 리소스 이름 구조로 전부 다시 매핑한다. 이 작업을 건너뛰면 이후 모든 갱신 요청이 notFound 오류로 실패한다.
• 가격 필드 변환: price.value(문자열)를 amountMicros(정수)로 변환하는 로직을 코드에 넣는다.

원래 가격	변환 전(Content API)	변환 후(머천트 API)
19,900원	value: "19900", currency: "KRW"	amountMicros: 19900000000, currencyCode: "KRW"
129,000원	value: "129000", currency: "KRW"	amountMicros: 129000000000, currencyCode: "KRW"

• 피드 레이블 재설정: 전환 과정에서 가장 자주 누락되는 항목이다. 국가·언어별로 나눠둔 피드 레이블이 새 구조에서도 동일하게 인식되는지 반드시 확인한다.
• 필수 속성 점검: GTIN, 브랜드, 상품 카테고리 같은 필수 속성값이 새 API 응답에서도 빠짐없이 채워지는지 확인한다. 구조화 데이터를 함께 정비해두면 전환 이후 상품 노출 품질을 높이는 데도 도움이 된다. 관련 내용은 AI가 인용하는 스키마 마크업 가이드에서 더 다루고 있다.
• 웹사이트 소유권 재확인: 상품 URL이 머천트 센터에 등록된 도메인과 일치하는지 다시 확인한다. 일치하지 않으면 승인 거부의 흔한 원인이 된다.
• 특수문자 인코딩: 상품명이나 리소스 이름에 %, ., +, /, :, ~ 같은 URL 예약 문자가 들어 있다면 base64url 인코딩이 필요할 수 있다. 인코딩을 빠뜨리면 요청 자체가 거부된다.
• 데이터 소스 소유권 확인: 상품을 갱신하거나 삭제하기 전에 products.get으로 해당 상품이 어느 데이터 소스에 속하는지 먼저 확인한다. 이 확인을 건너뛰면 다른 데이터 소스의 상품 정보를 실수로 덮어쓰는 이른바 "오퍼 스틸링" 사고가 날 수 있다.
• 제출값과 처리값 구분: 머천트 API는 내가 제출한 데이터(ProductInput)와 구글이 실제로 처리해 반영한 결과(Product)를 별도 리소스로 구분한다. 두 값이 일치하는지 전환 직후 반드시 대조해야 한다.

상품 ID 재매핑과 피드 레이블 재설정, 이 두 가지만 놓치지 않아도 전환 과정에서 발생하는 오류의 상당수를 미리 막을 수 있다.

전환 중 자주 나는 오류는 무엇이고 어떻게 고치나?

전환 과정에서 만나는 오류는 대부분 몇 가지로 정해져 있다. 원인을 미리 알아두면 당황하지 않고 바로 대응할 수 있다.

오류	흔한 원인	해결 방법
notFound	상품 ID 형식이 예전 방식 그대로 남아 새 구조와 불일치	ID 매핑을 새 리소스 이름 구조로 다시 확인
not_inserted	이미 존재하는 상품을 삽입(insert)으로 요청	갱신은 삽입이 아니라 업데이트(update) 메서드로
validation/invalid_value(destinations)	상품 URL이 등록된 도메인과 불일치	머천트 센터에 등록된 도메인과 URL을 다시 맞춤
quota/too_many_items	계정 등록 한도 초과	만료일 설정으로 무효 상품 자동 삭제(기본 30일)
enum 대소문자 불일치	상태값이 소문자에서 대문자로 변경(approved→APPROVED)	문자열 비교 로직을 대문자 기준으로 수정
페이지네이션 토큰 오류	기존 API에서 저장한 토큰을 그대로 사용	전환 시점에 토큰을 새로 발급받아 사용

오류 메시지는 낯설어 보여도 실제로는 상품 ID 형식·가격 형식·상태값 표기, 이 몇 가지 구조 변경에서 비롯된 것들이다. 위 표를 전환 체크리스트에 함께 붙여두면 디버깅 시간을 크게 줄일 수 있다.

OAuth 재동의 관련 오류도 종종 나타난다. 사용자 인증 토큰이 새 스코프를 포함하지 않은 채로 남아 있으면 권한 오류가 발생하므로, 전환 초기 단계에서 재동의 절차를 한 번 거치는 것이 안전하다.

마감을 놓쳤다면 어떻게 해야 하나?

전환 작업을 이미 시작했지만 8월 18일까지 마치기 어렵다고 판단되면, 구글이 마련해 둔 공식 연장 신청 양식을 통해 추가 기간을 요청할 수 있다. 다만 신청한다고 자동으로 승인되는 것은 아니므로, 신청과 별개로 전환 작업 자체는 지금 바로 진행하는 것이 안전하다.

시간이 촉박한 상황이라면 전체 마이그레이션을 한 번에 끝내려 하기보다, 데이터가 끊기지 않도록 최소한의 연결 고리부터 살려두는 것이 현실적이다. 지금 당장 할 수 있는 일은 다음 세 가지로 좁혀볼 수 있다.

• 자체 개발 연동이라면 개발 담당자에게 오늘 안으로 진행 상황을 확인한다.
• 플랫폼을 이용 중이라면 고객센터에 전환 완료 여부를 문의한다.
• 연장이 필요하다고 판단되면 공식 신청 양식을 먼저 접수해 시간을 벌어둔다.

마감을 넘긴 이후에는 기존 Content API 엔드포인트로 보내는 요청이 처리되지 않는다고 알려져 있다. 정확한 응답 방식은 계정과 상황에 따라 다를 수 있으므로, 마감이 임박했다면 연장 신청 여부와 무관하게 전환 작업을 최우선으로 두는 편이 안전하다.

전환을 마쳤다면 무엇을 추가로 확인해야 하나?

전환 작업이 끝났다고 바로 손을 떼면 안 된다. 데이터 흐름이 실제로 정상화됐는지 최소 1주에서 2주는 지켜봐야 안심할 수 있다.

• 승인 상태 점검: 머천트 센터의 진단(Diagnostics) 화면과 이슈 해결(Issue Resolution) 서브 API를 함께 확인해, 전환 이후 새로 발생한 거부 사유가 없는지 살핀다.
• 노출 현황 대조: 전환 전후로 쇼핑 검색 결과에서 상품 노출 수나 클릭 수가 급격히 줄지 않았는지 비교한다.
• 가격·재고 실시간 확인: 실제 사이트에서 가격을 바꿔보고, 머천트 센터에 반영되는 시간이 예전과 비슷한지 확인한다.
• 리포트 정합성 확인: 새 Reports 서브 API로 가져오는 성과 데이터가 기존 대시보드 수치와 크게 어긋나지 않는지 대조한다.

상품 데이터 흐름이 정상화됐는지 확인이 끝나면, 쇼핑 검색 결과에서 실제 노출이 유지되는지도 함께 살핀다. 쇼핑몰 SEO 전반을 함께 점검하고 싶다면 쇼핑몰 AI 오버뷰 노출 관련 글도 참고할 만하다. 종료 소식 자체를 빠르게 다시 확인하고 싶다면 구글 쇼핑 Content API 종료 임박 정리에서 핵심만 짧게 볼 수 있다.

자주 묻는 질문

CSV·XML 파일을 손으로 올리기만 해도 전환 대상인가?

아니다. 파일을 수동으로 업로드하거나 정기적으로 자동 가져오기(scheduled fetch)만 쓰는 경우는 이번 API 종료와 무관하다. 이번 전환은 Content API를 코드로 직접 호출해 상품 데이터를 주고받는 경우에만 해당한다.

카페24·아임웹 같은 플랫폼을 쓰면 직접 전환해야 하나?

플랫폼이 이미 대응을 마쳤다면 사업자가 직접 할 일은 거의 없다. 다만 어떤 방식으로 연동돼 있는지는 반드시 고객센터를 통해 확인해야 한다. 플랫폼별로 대응 완료 시점이 다를 수 있다.

전환에는 보통 얼마나 걸리나?

구조 복잡도에 따라 다르다. 국가 하나, 피드 하나짜리 단순한 구조는 약 8주, 다국가·다피드처럼 복잡한 구조는 16주에서 20주까지 걸릴 수 있다. 남은 기간이 짧다면 전체 완료보다 데이터 흐름을 끊기지 않게 하는 최소 작업부터 우선한다.

머천트 API 사용에 별도 비용이 드나?

머천트 API 자체의 호출 비용은 기존 Content API와 마찬가지로 별도 과금 없이 무료 사용량 안에서 운영할 수 있는 구조다. 다만 대규모 트래픽을 처리하는 대형 쇼핑몰이라면 할당량(쿼터) 정책은 별도로 확인하는 것이 좋다.

REST와 gRPC 중 어떤 방식을 써야 하나?

기존 REST 연동을 유지해도 전환에는 문제가 없다. 대량 데이터를 빠르게 처리해야 하는 대형 쇼핑몰이 아니라면 REST로 필드 구조만 새 형식에 맞춰도 충분하다. gRPC는 처리량이 특히 큰 경우에 유리한 선택지다.

전환 후 검색 노출이나 순위에 영향이 있나?

전환 자체가 순위를 올리거나 내리는 요인은 아니다. 다만 전환 과정에서 필수 속성값이 누락되거나 URL 불일치 오류가 방치되면 상품이 승인 거부돼 노출 자체가 줄어들 수 있다. 전환 후 며칠간 승인 상태와 노출 현황을 함께 점검하는 것이 안전하다.

여러 국가에 판매 중이면 국가별로 따로 전환해야 하나?

국가·언어별로 나눠둔 피드 레이블은 전환 후에도 그대로 유지된다. 다만 국가마다 데이터 소스가 따로 등록돼 있다면, 각 데이터 소스별로 상품 ID 재매핑과 피드 레이블 확인을 빠짐없이 반복해야 한다. 다국가 쇼핑몰일수록 작업 기간을 넉넉히 잡는 이유가 여기에 있다.

머천트 API 전환은 단순한 API 이름 교체가 아니라, 상품 ID·가격·배치 처리 구조까지 함께 바뀌는 작업입니다. 코드 전환뿐 아니라 쇼핑몰 홈페이지 전체의 검색 노출 구조까지 함께 점검이 필요하시다면, 이루웹의 SEO 최적화 홈페이지 제작 서비스에서 상품 스키마부터 사이트 구조까지 살펴봐 드리고 있습니다. 이루웹의 다른 서비스도 참고해 보시고, 전환 일정이 촉박하신 경우 문의 주시면 우선순위를 함께 정리해 드리겠습니다.