기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # RCS 메시징 AWS End User Messaging의 비즈니스용 Rich Communication Services(RCS)를 사용하면 미국 및 캐나다의 수신자에게 검증된 브랜드 텍스트 메시지를 보낼 수 있습니다. RCS는 별도의 채널이 아닌 SMS의 차세대 진화입니다. RCS 메시지는 수신자가 이미 SMS에 사용하는 것과 동일한 네이티브 메시징 앱으로 전송되므로 설치할 새 앱이 아닌 현재 위치 업그레이드입니다. 검증된 브랜드 자격 증명은 신뢰를 높이고, 대화를 장려하고, 더 나은 비즈니스 성과를 창출합니다. RCS 전송이 불가능한 경우 AWS 최종 사용자 메시징이 자동으로 SMS로 돌아갈 수 있습니다. **Topics** + [RCS란 무엇입니까?](rcs-overview.md) + [RCS 시작하기](rcs-getting-started.md) + [RCS 에이전트 관리](rcs-agents.md) + [RCS 메시지 테스트](rcs-testing.md) + [전화 풀을 사용한 RCS에서 SMS로의 대체](rcs-sms-fallback.md) + [RCS 메시지 전송](rcs-send-message.md) + [인바운드 RCS 메시지 수신](rcs-inbound.md) + [국가에서 RCS 시작](rcs-country-launch.md) + [RCS CloudWatch 지표 및 모니터링](rcs-monitoring.md) + [RCS 결제 및 요금 모델](rcs-billing.md) # RCS란 무엇입니까? 비즈니스용 Rich Communication Services(RCS)는 검증된 브랜드 자격 증명으로 기존 SMS를 개선하는 메시징 프로토콜입니다. AWS End User Messaging을 사용하면 RCS를 지원하지 않는 디바이스 또는 통신 사업자에 대한 자동 SMS 폴백을 통해 미국 및 캐나다의 수신자에게 RCS 문자 메시지를 보낼 수 있습니다. RCS 메시지는 수신자가 SMS에 사용하는 것과 동일한 메시징 앱에 표시되지만 확인된 브랜드 이름, 로고 및 색상을 포함합니다. 따라서 RCS는 채택할 새 채널이 아닌 현재 위치 업그레이드가 됩니다. `SendTextMessage` API를 사용하는 고객은 코드 변경을 최소화하거나 변경하지 않고 RCS 사용을 시작할 수 있으며, 최종 사용자는 메시징 흐름을 변경하지 않습니다. 확인된 자격 증명은 신뢰를 높이고, 대화를 장려하고, 기존 메시징 사용 사례를 개선하고, 대화형 경험과 같은 새로운 사용 사례를 위한 문을 엽니다. **중요** Google은 RCS 메시지를 전송하기 위한 메시지 전송 체인의 일부입니다. 따라서 AWS 최종 사용자 메시징에서 RCS 메시징 채널을 사용하는 경우 [Google이 RCS 메시지 콘텐츠를 사용하는 방법에 대한 정보를 포함하는 Google RCS for Business Terms of Service](https://developers.google.com/business-communications/rcs-business-messaging/terms-and-policies/tos)도 적용됩니다. **Topics** + [RCS의 주요 이점](#rcs-overview-benefits) + [RCS와 SMS의 차이점](#rcs-overview-how-rcs-differs) + [SMS 대체가 필요한 이유](#rcs-overview-sms-fallback) + [지원되는 RCS 기능](#rcs-overview-phase1-scope) + [2단계 자격 증명 모델 이해](#rcs-overview-identity-model) ## RCS의 주요 이점 AWS End User Messaging을 통한 RCS 메시징은 기존 SMS에 비해 다음과 같은 이점을 제공합니다. **검증된 브랜드 자격 증명** RCS 메시지는 Android 디바이스에서 확인된 배지와 함께 브랜드 로고, 이름 및 색상을 표시합니다. 수신자는 메시지가 조직의 메시지인지 확인할 수 있으므로 피싱 위험을 줄이고 참여를 개선할 수 있습니다. **전송 영수증(DLRs)** RCS는 메시지가 수신자의 디바이스로 전송된 시기를 확인하는 디바이스 수준 전송 영수증을 제공합니다. 전송 확인이 통신 사업자 네트워크에서 오는 SMS와 달리 RCS DLRs 디바이스에서 직접 보고하므로 실제 전송을 더욱 확실하게 보장할 수 있습니다. 이는 결제와도 관련이 있습니다. RCS를 사용하면 디바이스로 배달된 것으로 확인된 메시지에 대해서만 비용을 지불하지만 통신사가 메시지를 수락하면 SMS 요금이 발생합니다. **메시징 성능 개선** 확인된 브랜드 자격 증명은 수신자의 신뢰와 참여를 높이기 때문에 RCS를 통해 전달되는 메시지는 SMS에 비해 더 나은 비즈니스 결과를 달성하는 경향이 있습니다. RCS는 아직 SMS처럼 보편적으로 사용할 수 없지만 RCS를 통해 전달되는 메시지의 하위 집합은 일반적으로 더 높은 공개율과 변환을 볼 수 있습니다. 디바이스 또는 통신 사업자가 RCS를 지원하지 않는 수신자의 경우 자동 SMS 폴백을 사용하면 메시지가 여전히 RCS에 도달할 수 있습니다. **자동 SMS 대체** AWS RCS 에이전트와 SMS 전화번호가 모두 포함된 전화 풀을 통해 메시지를 보내면 RCS 전송이 불가능한 경우 AWS End User Messaging은 자동으로 SMS로 돌아갑니다. 이렇게 하면 RCS에 대한 디바이스 또는 통신 사업자 지원과 관계없이 메시지가 수신자에게 전달됩니다. ## RCS와 SMS의 차이점 다음 표에서는 AWS End User Messaging의 RCS 및 SMS 메시징 기능을 비교합니다. **RCS와 SMS 비교** | 기능 | RCS | SMS | | --- | --- | --- | | 브랜드 자격 증명 | 확인된 브랜드 이름, 로고, 색상 및 배지 | 전화번호 또는 발신자 ID만 | | 전송 확인 | 디바이스 수준 전송 영수증: 수신자의 디바이스가 직접 보고하여 실제 전송을 확인합니다. 확인된 배송에 대해서만 요금이 청구됩니다. | 통신사 수준 확인: 통신사 네트워크가 수신을 승인하지만 메시지가 디바이스에 도달했음을 보장하지는 않습니다. 통신사가 메시지를 수락하면 요금이 청구됩니다. | | 메시지 콘텐츠 | 문자 메시지 | 문자 메시지, 미디어용 MMS | | 디바이스 지원 | RCS가 활성화된 Android 디바이스, iOS 18 이상이 설치된 iPhone | 모든 모바일 디바이스 | | 지원되는 국가 | 미국 및 캐나다 | 200개 이상의 국가 및 리전 | ## SMS 대체가 필요한 이유 일부 모바일 디바이스 및 통신 사업자는 RCS를 지원하지 않습니다. 예를 들어 이전 Android 디바이스, 일부 통신 사업자 및 18 이전의 iOS 버전을 실행하는 iPhones RCS 메시지를 수신할 수 없습니다. 대부분의 사용 사례에서는 디바이스 또는 통신사에 관계없이 모든 수신자에게 연락할 수 있는 신뢰할 수 있는 방법이 필요합니다. 전화 풀은이 문제를 해결합니다. 풀은 API 요청과 발신 자격 증명 간에 추상화 계층을 제공하는 메시징 자격 증명의 컨테이너입니다. 애플리케이션에 SMS 대체 번호 선택 로직을 적용하는 대신 풀에 RCS 에이전트와 전화번호를 추가하고 AWS End User Messaging이 나머지를 처리합니다. 이렇게 하면 세 가지 이점이 있습니다. + 어떤 번호가 어떤 국가에서 작동하는지 걱정하지 않고 RCS-to-SMS 대체가 쉽습니다. 자격 증명을 풀에 추가하면 서비스가 적절한 자격 증명을 자동으로 선택합니다. + 숫자 및 에이전트 선택 로직은 애플리케이션 코드에서 벗어나 easy-to-manage 구성으로 유지됩니다. 전송 통합을 변경하지 않고도 자격 증명을 추가하거나 제거할 수 있습니다. + 간단하게 설정할 수 있지만 풀을 사용하면 규정 준수 안전 라우팅을 위한 per-use-case 풀을 포함하여 숫자와 RCS 에이전트를 함께 사용하는 방법을 완벽하게 제어할 수 있습니다. SMS 폴백을 사용하려면 AWS RCS 에이전트와 하나 이상의 SMS 전화번호가 모두 포함된 전화 풀을 생성합니다. 풀을 사용하여 메시지를 보내면 AWS End User Messaging은 먼저 RCS 전송을 시도하고 필요한 경우 자동으로 SMS로 돌아갑니다. 애플리케이션 코드를 수정하지 않고 발신 ID를 추가하거나 변경할 수 있는 유연성을 제공하므로 RCS뿐만 아니라 모든 메시징 사용 사례에 풀 기반 전송을 사용하는 것이 좋습니다. **참고** (풀을 사용하지 않고) AWS RCS 에이전트에 직접 메시지를 보내는 경우 SMS 폴백을 사용할 수 없습니다. RCS-or-nothing 전송이 필요하거나 AWS 최종 사용자 메시징 외부에서 폴백 로직을 관리하는 경우에만 직접 전송을 사용합니다. ## 지원되는 RCS 기능 AWS End User Messaging에서 RCS의 최초 시작은 미국 및 캐나다에서 텍스트 전용 메시징을 지원합니다. SMS에 사용하는 것과 동일한 `SendTextMessage` API를 사용하여 일반 텍스트 RCS 메시지를 보내고 받을 수 있습니다. AWS End User Messaging의 RCS는 현재 다음을 지원합니다. + RCS를 통한 문자 메시지 전송 및 수신 + 확인된 브랜드 자격 증명(로고, 이름, 색상 및 확인된 배지) + 전송 영수증(DLRs) + 풀 기반 전송을 사용한 자동 SMS 대체 + 양방향 메시징(인바운드 RCS 문자 메시지 수신) + 자동 응답을 위한 키워드 관리 + RCS 메시지 모니터링을 위한 CloudWatch 지표 + 미국 및 캐나다에서 국가 출시 + 통신 사업자 승인 없이 테스트할 RCS 테스트 에이전트 + 디바이스에서 브랜드가 어떻게 표시되는지 미리 보기 위한 콘솔의 전화 모형 + 미국과 캐나다 모두에 대한 국가별 등록을 관리하는 단일 AWS RCS 에이전트 리소스 + 국가별 사용자 지정을 통해 여러 국가에서 등록 세부 정보 공유 + 구성 세트, 전화 풀, 옵트아웃 목록 및 키워드를 포함한 모든 AWS 최종 사용자 메시징 기능 **참고** RCS 테스트 에이전트는 일반적으로 며칠 또는 몇 주가 걸릴 수 있는 SMS 전화번호 등록과 비교하여 몇 분 내에 생성되고 승인됩니다. 이렇게 하면 RCS 메시징 테스트를 빠르게 시작할 수 있습니다. ## 2단계 자격 증명 모델 이해 AWS End User Messaging의 RCS는 **AWS RCS 에이전트**(생성 및 관리하는 컨테이너)와 하나 이상의 **RCS for Business IDs**(등록 중에 생성된 국가별 에이전트 자격 증명)라는 두 가지 수준의 자격 증명 모델을 사용합니다. 수명 주기 상태 및 비교 테이블을 포함하여 이러한 자격 증명의 관계에 대한 전체 세부 정보는 섹션을 참조하세요[2단계 자격 증명 모델 이해](rcs-agents.md#rcs-agents-identity-model). # RCS 시작하기 이 안내서에서는 AWS End User Messaging에서 첫 번째 RCS 에이전트를 설정하고 첫 번째 RCS 메시지를 보내고 받는 방법을 안내합니다. 결국에는 RCS 테스트 환경이 작동하게 됩니다. 예상 완료 시간: 15\$130분. 이 가이드에서 다루는 내용은 다음과 같습니다. 1. AWS RCS 에이전트 생성 및 테스트 등록 제출 1. 테스트 디바이스 추가 및 테스터 초대 수락 1. 첫 번째 아웃바운드 RCS 메시지 전송 1. 키워드를 사용하여 인바운드(양방향) 메시징 테스트 2단계 자격 증명 모델(AWS RCS 에이전트 및 RCS for Business ID)을 포함하여 AWS 최종 사용자 메시징에서 RCS가 작동하는 방식에 대한 배경 정보는 섹션을 참조하세요[RCS란 무엇입니까?](rcs-overview.md). IDs ## RCS 설정 및 테스트 이 섹션에서는 AWS RCS 에이전트를 생성하고, 테스트 디바이스를 등록하고, 첫 번째 RCS 메시지를 보내고, 전송을 확인하는 방법을 안내합니다. 이 단계를 완료한 후 프로덕션 국가에서 RCS를 시작할 수 있습니다. ### 사전 조건 시작하기 전에 다음 항목이 준비되었는지 확인합니다. + ** AWS End User Messaging 액세스 권한이 있는 AWS 계정** - AWS End User Messaging을 사용하려면 권한이 있는 AWS 계정이 필요합니다. 계정이 없는 경우 [AWS 계정 설정 가이드를](https://docs.aws.amazon.com/accounts/latest/reference/welcome-first-time-user.html) 참조하세요. + **RCS가 활성화된 휴대폰 **- 기본 메시징 앱에서 RCS 메시징이 활성화된 Android 휴대폰 또는 iOS 18 이상을 실행하는 iPhone이 필요합니다. 이 전화는 RCS 메시지를 수신하기 위한 테스트 디바이스 역할을 합니다. + **(선택 사항) AWS CLI 구성** - 콘솔 대신 API를 사용하여 테스트하려면 AWS CLI를 설치 및 구성하거나 boto3 for Python과 같은 AWS SDK를 사용합니다. ### 1단계: AWS RCS 에이전트 생성 및 테스트 등록 제출 첫 번째 단계는 AWS RCS 에이전트를 생성하고 테스트 등록을 제출하는 것입니다. 테스트 등록은 통신 사업자 승인 없이 등록된 테스트 디바이스에 메시지를 보내는 데 사용할 수 있는 RCS for Business ID(테스트 에이전트)를 생성합니다. 에이전트 수명 주기 및 API 작업을 포함하여 AWS RCS 에이전트 관리에 대한 자세한 내용은 섹션을 참조하세요[RCS 에이전트 관리](rcs-agents.md). #### AWS RCS 에이전트 생성(콘솔) **AWS RCS 에이전트를 생성하고 테스트 등록을 제출하려면** 1. [AWS End User Messaging 콘솔](https://console.aws.amazon.com/sms-voice/home)을 엽니다. 1. 탐색 창의 **구성**에서 **RCS 에이전트**를 선택합니다. 1. **RCS 에이전트 생성을** 선택합니다. 그러면 AWS RCS 에이전트가 생성되고 즉시 단일 워크플로에서 테스트 등록을 생성하는 과정을 안내합니다. 1. 다음 화면에서는 RCS를 소개하고 설정 프로세스를 설명합니다. 정보를 검토하고 **다음을** 선택하여 계속합니다. 1. **에이전트 세부 정보** 페이지에서 다음을 설정합니다. + **표시 이름** - AWS RCS 에이전트의 콘솔 전용 레이블입니다. 참조의 내부 이름(태그로 저장됨)이며 수신자의 전화에 표시되는 이름이 아닙니다. API를 통해 표시 이름을 사용할 수 없습니다. + **삭제 방지** - (선택 사항) 에이전트가 실수로 삭제되지 않도록 하려면를 활성화합니다. + **태그** - (선택 사항) 태그를 추가하여 에이전트를 구성하고 식별합니다. 1. 동일한 페이지의 **브랜드 정보** 섹션에 다음을 입력합니다. + **표시 이름** - 수신자가 RCS 메시지와 함께 보는 브랜드 이름입니다. + **설명** - 브랜드 또는 비즈니스에 대한 간략한 설명입니다. + **사용 사례** - RCS 메시징의 기본 사용 사례(예: 트랜잭션 알림, 마케팅 또는 고객 지원)를 선택합니다. 1. 동일한 페이지의 **브랜드 자산** 섹션에서 다음을 업로드합니다. + **로고** - 224 × 224픽셀, 투명도가 있는 PNG, 50KB 미만. + **배너 이미지** - 1440 × 448픽셀, PNG 또는 JPEG, 200KB 미만. + **브랜드 색상** - 흰색 배경에 대한 최소 대비 비율이 4.5:1인 16진수 색상 코드(예: `#1A73E8`)입니다. **중요** 일부 브랜드 자산은 에이전트가 등록을 위해 제출된 후에는 변경할 수 없습니다. 에이전트를 생성하기 전에 최종 브랜드 자산을 준비합니다. 먼저 실험하려는 경우이 흐름을 사용하여 테스트 에이전트를 빠르게 생성한 다음 나중에 완료된 브랜드 자산이 있는 새 AWS RCS 에이전트를 생성할 수 있습니다. 1. **규정 준수 키워드** 페이지에서 키워드와 자동 응답 메시지를 구성합니다. 1. **검토** 페이지에서 모든 설정을 확인합니다. 1. **검증 및 제출**을 선택하여 AWS RCS 에이전트를 생성하고 테스트 등록을 제출합니다. **참고** AWS RCS 에이전트를 성공적으로 생성하고 테스트 등록을 제출했습니다. 테스트 에이전트는 일반적으로 몇 분 내에 승인됩니다. 이제 디바이스에 대한 테스트 메시징을 활성화해 보겠습니다. #### AWS RCS 에이전트 생성(CLI) AWS CLI를 사용하여 AWS RCS 에이전트를 생성할 수도 있습니다. 먼저 에이전트를 생성한 다음 테스트 등록을 제출합니다. 1단계: AWS RCS 에이전트 생성: ``` aws pinpoint-sms-voice-v2 create-rcs-agent \ --deletion-protection-enabled ``` 2단계: 에이전트에 대한 테스트 등록을 제출합니다. RCS 테스트를 위한 등록 유형과 함께 `CreateRegistration` API를 사용합니다. `DescribeRegistrationFieldDefinitions` API를 사용하여 제출하기 전에 사용 가능한 모든 등록 양식 필드를 프로그래밍 방식으로 검색할 수 있습니다. 등록 양식 필드의 일부로 브랜드 자산, 설명 및 연락처 세부 정보를 제공합니다. 등록 API에 대한 자세한 내용은 섹션을 참조하세요[RCS 에이전트 관리](rcs-agents.md). ### 2단계: 테스트 디바이스 추가 테스트 등록이 승인되면 테스트 에이전트로부터 RCS 메시지를 받을 수 있도록 휴대폰을 테스트 디바이스로 추가합니다. **참고** 테스트 디바이스를 추가한 후에는 테스터 초대가 즉시 전송되지 않습니다. 시스템은 최소 120초 동안 활성화를 지연하며 초대가 도착하는 데 최대 20분이 걸릴 수 있습니다. 콘솔에는 대략적인 활성화 시간이 표시됩니다. 디바이스를 추가하기 전에 기다릴 필요가 없습니다. 시스템이 지연을 자동으로 처리합니다. ------ #### [ Console ] **테스트 디바이스를 추가하려면** 1. AWS End User Messaging 콘솔에서 AWS RCS 에이전트로 이동하여 **테스트** 탭을 선택합니다. 1. **테스트 디바이스 추가**를 선택합니다. 1. 테스트 디바이스의 전화번호를 E.164 형식(예: `+12065550100`)으로 입력합니다. 1. **추가**를 선택합니다. ------ #### [ AWS CLI ] `--rcs-agent-id` 파라미터와 함께 `CreateVerifiedDestinationNumber` API를 사용하여 AWS RCS 에이전트에 테스트 디바이스를 등록합니다. ``` aws pinpoint-sms-voice-v2 create-verified-destination-number \ --destination-phone-number +12065550100 \ --rcs-agent-id rcs-a1b2c3d4 ``` ------ 테스트 디바이스를 추가한 후 AWS End User Messaging은 테스터 초대를 전화번호로 보냅니다. 초대는 **RBM Tester Management라는 RCS** 에이전트가 제공하며 수락하거나 거부할 수 있는 두 개의 버튼**, 즉 테스터로 설정** 및 **거부가** 포함되어 있습니다. 수신자가 확인을 완료하려면 **테스터로 만들기**를 탭해야 합니다. **참고** iOS 디바이스(iPhone iOS 18 이상)에서는 기본 받은 편지함이 아닌 메시지 앱의 **알 수 없는 발신자** 폴더에 테스터 초대가 표시될 수 있습니다. 초대가 표시되지 않으면 알 수 없는 발신자 폴더를 확인합니다. API 접근 방식 및 문제 해결을 포함하여 테스트 디바이스 관리에 대한 자세한 내용은 섹션을 참조하세요[RCS 메시지 테스트](rcs-testing.md). ### 3단계: 첫 번째 RCS 메시지 전송 테스트 디바이스가 테스터 초대를 수락한 후 첫 번째 RCS 메시지를 보낼 수 있습니다. AWS End User Messaging 콘솔 또는 API를 사용할 수 있습니다. ------ #### [ Console ] **콘솔을 사용하여 테스트 메시지를 보내려면** 1. AWS End User Messaging 콘솔에서 AWS RCS 에이전트로 이동하여 **테스트** 탭을 선택합니다. 1. **아웃바운드 테스트 메시지를** 선택합니다. 콘솔에는 메시지가 수신자의 디바이스에서 렌더링되는 방식에 대한 미리 보기와 JSON 요청 본문 및 CLI 명령이 표시됩니다. 1. 목록에서 확인된 테스트 디바이스를 선택합니다. 1. 메시지 텍스트를 입력합니다. 1. **문자 메시지 전송**을 선택합니다. **참고** 선택적으로 메시지 이벤트에 대한 구성 세트를 설정할 수 있습니다. 구성 세트를 사용하면 선택한 이벤트 대상에서 세분화된 전송 수신(DLRs) 및 기타 메시지 이벤트를 사용할 수 있습니다. 이는 테스트에는 선택 사항이지만 프로덕션용으로 권장됩니다. 자세한 내용은 [RCS CloudWatch 지표 및 모니터링](rcs-monitoring.md)을 참조하세요. ------ #### [ AWS CLI ] `send-text-message` 명령을 사용하여 테스트 메시지를 보냅니다. AWS RCS 에이전트 ARN을 발신 자격 증명으로 지정합니다. ``` aws pinpoint-sms-voice-v2 send-text-message \ --destination-phone-number +12065550100 \ --origination-identity arn:aws:sms-voice:us-east-1:123456789012:rcs-agent/rcs-a1b2c3d4 \ --message-body "Hello from RCS! This is my first test message." ``` `send-text-message` 명령은 SMS에 사용하는 것과 동일한 명령입니다. AWS RCS 에이전트 ARN을 발신 자격 증명으로 지정하면 AWS End User Messaging은 RCS를 통해 메시지를 전송합니다. ------ ### 4단계: 인바운드(양방향) 메시징 테스트 자동 응답으로 키워드를 구성한 다음 테스트 디바이스에서 해당 키워드와 일치하는 메시지를 전송하여 인바운드 RCS 메시징을 테스트할 수 있습니다. **자동 응답 키워드를 사용하여 인바운드 메시징을 테스트하려면** 1. AWS End User Messaging 콘솔에서 AWS RCS 에이전트로 이동하여 키워드를 구성합니다. 예를 들어 `RCSINBOUNDTESTING`"인바운드 테스트 성공\$1 메시지가 수신되었습니다.” 1. **테스트** 탭에서 **인바운드 딥 링크를** 선택합니다. 1. **기본 메시지 본문** 필드에 구성한 키워드(예: `RCSINBOUNDTESTING`)를 입력합니다. 1. **링크 생성을** 선택합니다. 콘솔은 GSMA 표준 `sms:` URI 체계를 사용하여 인바운드 딥 링크 URL을 생성합니다. 이 딥 링크는 화면에 표시된 QR 코드에 포함되어 있습니다. 1. 확인된 테스터 전화로 QR 코드를 스캔합니다. 그러면 AWS RCS 에이전트로 전송되는 미리 채워진 메시지가 있는 네이티브 메시징 앱이 열립니다. 1. 테스트 디바이스에서 메시지를 전송합니다. 1. 테스트 디바이스에서 자동 응답 메시지를 수신하는지 확인합니다. 자동 응답 키워드를 테스트할 때는 이벤트 대상 또는 Amazon SNS 주제를 설정할 필요가 없습니다. 자동 응답은 AWS RCS 에이전트의 키워드 구성을 기반으로 AWS End User Messaging에서 전적으로 처리됩니다. 임의의 인바운드 메시지(키워드 일치 항목뿐만 아니라)를 수신하고 처리하려면 양방향 메시징을 위한 Amazon SNS 주제를 구성해야 합니다. 자세한 내용은 [인바운드 RCS 메시지 수신](rcs-inbound.md)을 참조하세요. ### 달성한 성과 이 가이드의 단계를 완료하면 다음을 수행할 수 있습니다. + 브랜드 자산으로 AWS RCS 에이전트를 생성하고 테스트 등록을 제출했습니다. + 테스트 디바이스를 등록하고 테스터 초대를 수락했습니다. + 첫 번째 RCS 메시지 전송 및 전송 확인 + 자동 응답 키워드를 사용하여 테스트된 인바운드 메시징 이제 테스트 환경이 준비되었습니다. RCS 메시징을 애플리케이션에 통합하거나 RCS 메시징의 작동 방식을 미세 조정하는 방법은 다음과 같습니다. + **인바운드 메시지 수신 및 처리**: 인바운드 RCS 메시지를 수신하고 Lambda 함수를 사용하여 처리하도록 Amazon SNS 주제를 구성합니다. [인바운드 RCS 메시지 수신](rcs-inbound.md)을(를) 참조하세요. + **전송 이벤트 추적**: 선택한 이벤트 대상에서 세분화된 전송 수신(DLRs) 및 기타 메시지 이벤트를 소비하도록 구성 세트를 설정합니다. [RCS CloudWatch 지표 및 모니터링](rcs-monitoring.md)을(를) 참조하세요. + **SMS 폴백 활성화**: RCS 전송이 불가능할 때 자동으로 SMS로 폴백되도록 AWS RCS 에이전트 및 SMS 전화번호로 전화 풀을 생성합니다. [전화 풀을 사용한 RCS에서 SMS로의 대체](rcs-sms-fallback.md)을(를) 참조하세요. + **프로덕션 국가에서 시작**: 국가 시작 등록을 제출하여 미국 및 캐나다의 모든 수신자에게 RCS 메시지를 보냅니다. [국가에서 RCS 시작](rcs-country-launch.md)을(를) 참조하세요. ## RCS 설정을 위한 AI 에이전트 프롬프트 생성형 AI 코딩 어시스턴트 또는 AI 에이전트를 사용하는 경우 다음 프롬프트를 사용하여 AWS RCS 에이전트를 생성하고, 테스트 등록을 제출하고, AWS CLI를 사용하여 첫 번째 테스트 메시지를 보내는 데 도움을 받을 수 있습니다. **참고** 다음 프롬프트를 복사하여 AI 에이전트 또는 코딩 어시스턴트에 붙여 넣습니다. ``` ## RCS Setup Assistant Prompt Help me set up RCS messaging in AWS End User Messaging using the AWS CLI. The service is `pinpoint-sms-voice-v2`. Walk me through each step with exact CLI commands. Ask me for all required details before generating any commands. **Important rules for generating commands:** - All commands use the `pinpoint-sms-voice-v2` service. - Use `create-rcs-agent` exactly as spelled — NOT `create-r-c-s-agent`. - Use the term "testing" — NOT "sandbox". - There is NO `describe-messages` API. Do not generate it. - `create-rcs-agent` does NOT accept brand asset parameters (no display name, no logo, no banner, no color). Brand assets are registration fields only. - `create-verified-destination-number` uses `--rcs-agent-id`, NOT `--origination-identity`. ### Step 1: Create an RCS Agent Use `create-rcs-agent`. This creates the agent resource only. Optional parameters: `--deletion-protection-enabled`, `--opt-out-list-name`, `--tags`. The response returns `RcsAgentId` and `RcsAgentArn` — save both. ### Step 2: Create and submit a testing registration This configures brand assets and submits for approval. It requires multiple API calls in sequence: a. `create-registration --registration-type TEST_RCS_LAUNCH_REGISTRATION` → returns `RegistrationId`. Save it. b. `create-registration-association --registration-id --resource-id ` → links the registration to the agent. c. Upload images as attachments (two calls): `create-registration-attachment --attachment-body fileb://` `create-registration-attachment --attachment-body fileb://` → each returns `RegistrationAttachmentId`. Save both. d. Set ALL required registration fields using `put-registration-field-value` with `--registration-id`, `--field-path`, and the appropriate value flag (`--text-value`, `--select-choices`, or `--registration-attachment-id`). Required fields (ALL must be set or registration will be DENIED): - `agentDetails.brandName` (text, 2-65 chars) - `agentDetails.serviceName` (text, 1-100 chars) - `agentDetails.senderDisplayName` (text, 1-40 chars) - `agentDetails.useCase` (select: OTP, TRANSACTIONAL, PROMOTIONAL, MULTI_USE) - `agentDetails.agentDescription` (text, 1-100 chars) - `agentDetails.logoImage` (attachment ID from step c, 224x224 PNG) - `agentDetails.bannerImage` (attachment ID from step c, 1440x448 PNG/JPEG) - `agentDetails.accentColor` (text, hex code e.g. #0066CC) - `agentDetails.privacyPolicyUrl` (text, valid URL) - `agentDetails.termsAndConditionsUrl` (text, valid URL) - `agentDetails.averageMonthlyRcsFrequency` (select: 10, 100, 1000+) - `agentDetails.monthlyRcsVolume` (text, 1-100000) - At least ONE contact method WITH its label: agentDetails.contactWebsite + agentDetails.contactWebsiteLabel, OR agentDetails.contactPhoneNumber + agentDetails.contactPhoneLabel, OR agentDetails.contactEmailAddress + agentDetails.contactEmailLabel e. Verify all fields: `describe-registration-field-values --registration-id ` Any field showing `DeniedReason: MISSING_REQUIRED_FIELD` must be set. f. Submit: `submit-registration-version --registration-id ` g. Poll status: `describe-registrations --registration-ids ` Wait for `RegistrationStatus: COMPLETE`. **Error recovery:** If registration is DENIED, you must: 1. `create-registration-version --registration-id ` (creates new draft) 2. Re-populate ALL fields from scratch (new versions do NOT inherit values) 3. Fix the issue noted in `DeniedReasons` 4. Re-submit ### Step 3: Add a test device **Prerequisite:** Step 2 must be COMPLETE and the agent's `TestingAgent.Status` must be `ACTIVE` (check with `describe-rcs-agents`). Then wait at least 120 seconds after the agent becomes ACTIVE. Use `create-verified-destination-number --destination-phone-number --rcs-agent-id `. The device status will be `PENDING`. The user must accept the RCS tester invitation on their physical device. Check status with `describe-verified-destination-numbers` — wait for `VERIFIED`. ### Step 4: Send a test RCS message **Prerequisite:** Step 3 device must be `VERIFIED`. Use `send-text-message --destination-phone-number --origination-identity --message-body "" --message-type TRANSACTIONAL`. Returns `MessageId`. ### Step 5: Verify delivery For testing: check the test device — the message appears from the branded RCS agent. For production monitoring: set up event destinations BEFORE sending messages using `create-event-destination` (SNS, CloudWatch Logs, or Firehose). Event destinations do not retroactively capture events for already-sent messages. CloudWatch metrics in the `AWS/SMSVoice` namespace provide aggregate stats. --- **Before generating commands, ask me for:** - Brand name, service name, and sender display name - Agent description (what the agent does, what messages users receive) - Use case type: OTP, TRANSACTIONAL, PROMOTIONAL, or MULTI_USE - Logo file path (224x224 PNG) and banner file path (1440x448 PNG/JPEG) - Brand accent color hex code (e.g. #0066CC) - Privacy policy URL and terms & conditions URL - One contact method with label: website URL, phone number, or email - Estimated monthly RCS volume and per-user message frequency - Test device phone number in E.164 format (e.g. +12065550100) ``` # RCS 에이전트 관리 AWS RCS 에이전트는 RCS 메시징용 브랜드를 나타내는 AWS 최종 사용자 메시징의 최상위 리소스입니다. 테스트 에이전트와 국가 시작 에이전트(RCS for Business IDs. 키워드 및 양방향 메시징 구성은 AWS RCS 에이전트에서 정의됩니다. 브랜드 자산은 각 등록(테스트 에이전트 또는 국가 출시 에이전트)에 정의됩니다. AWS RCS 에이전트가 RCS for Business IDs[RCS란 무엇입니까?](rcs-overview.md). AWS RCS 에이전트는 다음 수명 주기를 따릅니다. 1. AWS RCS 에이전트를 **생성합니다**. 1. **테스트 에이전트를 추가합니다**(콘솔 생성 흐름에 포함됨, CLI를 통해 선택 사항). 1. 등록된 **테스트** 디바이스를 사용하여 RCS 메시징을 테스트합니다. 테스트에는 통신 사업자 승인이 필요하지 않습니다. 1. 프로덕션 RCS 메시지를 보내려는 각 국가에 대해 국가 **시작 등록을 제출합니다**. 1. **부분적으로 승인**됨: 하나 이상의 통신 사업자가 에이전트를 승인했습니다. 승인된 통신 사업자의 수신자에게 전송을 시작할 수 있습니다. 1. **완전히 승인**됨: 해당 국가의 모든 통신사가 에이전트를 승인했습니다. 해당 국가의 전체 범위입니다. 하나의 AWS RCS 에이전트는 하나의 테스트 에이전트(RCS for Business ID)와 여러 국가 시작 에이전트(국가당 하나의 RCS for Business ID)에 매핑됩니다. 콘솔에서 AWS RCS 에이전트를 생성하면 워크플로가 즉시 테스트 에이전트를 생성하도록 안내합니다. 그런 다음 테스트 에이전트의 브랜드 구성을 사용하여 국가 시작 등록 양식을 미리 채워 중복 데이터 입력을 줄입니다. **Topics** + [AWS RCS 에이전트 이해](#rcs-agents-concept) + [2단계 자격 증명 모델 이해](#rcs-agents-identity-model) + [AWS RCS 에이전트 생성](#rcs-agents-create) + [AWS RCS 에이전트 업데이트](#rcs-agents-update) + [AWS RCS 에이전트 보기](#rcs-agents-view) + [테스트 에이전트 검토](#rcs-agents-review-test-agent) + [국가 시작 상태 보기](#rcs-agents-country-launch-status) + [AWS RCS 에이전트 삭제](#rcs-agents-delete) ## AWS RCS 에이전트 이해 AWS RCS 에이전트는 관리하는 RCS for Business IDs 다릅니다. 다음 표에는 차이점이 요약되어 있습니다. **RCS for Business ID와 비교한 AWS RCS 에이전트** | 속성 | AWS RCS 에이전트 | RCS for Business ID | | --- | --- | --- | | 관리 주체 | AWS 최종 사용자 메시징 콘솔 또는 API를 통해 | AWS 등록 프로세스 중 최종 사용자 메시징 | | Scope | 브랜드당 또는 사용 사례당 1개 | 국가 시작당 1개 및 테스트 에이전트 1개 | | 구성 | 표시 이름, 삭제 방지, 옵트아웃 목록, 태그, 키워드, 양방향 메시징 대상 | 등록 중에 정의된 브랜드 자산 및 기타 설정 | | 식별자 | rcs-a1b2c3d4 형식 | RCS 인프라 공급자가 내부적으로 관리 | ### 에이전트 ID 및 ARN 각 AWS RCS 에이전트에는 형식의 고유 식별자`rcs-a1b2c3d4`(접두사 `rcs-` 뒤에 16진수 문자열)가 있습니다. `UpdateRcsAgent` 및와 같은 API 작업을 호출할 때이 ID를 사용합니다`DeleteRcsAgent`. 각 AWS RCS 에이전트에는 다음 형식의 AWS 리소스 ARN도 있습니다. ``` arn:aws:sms-voice:region:account-id:rcs-agent/rcs-agent-id ``` AWS RCS 에이전트를 `SendTextMessage` API의 발신 자격 증명으로 지정하거나 에이전트를 전화 풀에 추가할 때 ARN을 사용할 수 있습니다. ### 수명 주기 상태 AWS RCS 에이전트는 다음 수명 주기 상태를 전환합니다. **생성됨** AWS RCS 에이전트 리소스가 AWS 최종 사용자 메시징에서 생성되었지만 아직 등록이 제출되지 않았습니다. 이 상태에서 브랜드 자산 및 구성을 업데이트할 수 있습니다. **PENDING** 등록이 제출되었으며 처리를 기다리고 있습니다. 에이전트를 아직 메시지 전송에 사용할 수 없습니다. **테스트** 테스트 등록이 승인되었습니다. 에이전트에는 테스트 에이전트(RCS for Business ID)가 있으며 등록된 테스트 디바이스로 메시지를 보낼 수 있습니다. 국가 시작 등록이 완료되지 않았습니다. **부분** 하나 이상의 국가 시작 등록이 완료되었지만 제출된 모든 국가 시작이 활성 상태인 것은 아닙니다. 에이전트는 승인된 국가에서 메시지를 보낼 수 있지만 에이전트를 승인한 특정 통신 사업자(들)의 수신자에게만 메시지를 보낼 수 있습니다. 한 국가의 `CountryStatus`는 해당 국가의 한 개 이상의 통신 사업자가 활성화되는 즉시 부분으로 이동합니다. **ACTIVE** 제출된 모든 국가 시작 등록이 완료되고 활성 상태입니다. 에이전트는 등록된 모든 국가에서 완전히 작동합니다. 새 국가가 아직 승인되지 않았으므로 새 국가 시작 등록이 제출되면 ACTIVE 에이전트가 부분 상태로 돌아갈 수 있습니다. **삭제됨** AWS RCS 에이전트가 삭제되었습니다. 연결된 모든 RCS for Business IDs(테스트 및 국가 시작 에이전트)가 비활성화됩니다. 이 작업은 실행을 취소할 수 없습니다. ## 2단계 자격 증명 모델 이해 AWS End User Messaging의 RCS는 **AWS RCS 에이전트**와 하나 이상의 **RCS for Business IDs**라는 두 가지 수준의 자격 증명 모델을 사용합니다. **AWS RCS 에이전트** AWS RCS 에이전트는 AWS 최종 사용자 메시징에서 생성하고 관리하는 최상위 리소스입니다. 테스트 에이전트와 국가 시작 에이전트를 함께 바인딩하는 통합 리소스 역할을 합니다. 키워드 및 양방향 메시징 구성은 AWS RCS 에이전트에서 정의됩니다. 브랜드 자산은 각 등록에 정의됩니다. 각 AWS RCS 에이전트에는 형식의 고유 식별자`rcs-a1b2c3d4`와 리소스 ARN이 있습니다 AWS . RCS를 시작하는 모든 국가에서 AWS RCS 에이전트를 브랜드에 대한 통합 자격 증명으로 생각하십시오. **RCS for Business ID** RCS for Business ID는 등록 프로세스 중에 RCS 인프라 공급자를 사용하여 생성되는 국가별 에이전트 자격 증명입니다. 각 국가 시작은 AWS RCS 에이전트 아래에 별도의 RCS for Business ID를 생성합니다. RCS for Business IDs 직접 관리하지 않습니다. AWS End User Messaging은 등록 프로세스의 일부로 생성 및 수명 주기를 처리합니다. 하나의 AWS RCS 에이전트에는 다음과 같은 RCS for Business IDs. + **테스트 에이전트 1**개 - 테스트 등록 단계에서 생성된 RCS for Business ID입니다. 테스트 에이전트는 등록된 테스트 디바이스에서 작동하며 프로덕션에서 시작하기 전에 RCS 통합을 검증할 수 있습니다. 테스트 메시지는 표준 요금으로 청구됩니다. + **여러 국가 시작 에이전트** - RCS를 시작하는 각 국가는 별도의 RCS for Business ID를 생성합니다. 예를 들어 미국과 캐나다 모두에서를 시작하는 경우 AWS RCS 에이전트에는 테스트 에이전트 외에도 두 개의 국가 시작 에이전트(미국 RCS for Business ID 하나와 캐나다 RCS for Business ID 하나)가 있습니다. 다음 다이어그램은 이러한 자격 증명 간의 관계를 보여줍니다. ``` AWS RCS Agent (rcs-a1b2c3d4) ├── Testing agent (RCS for Business ID) ├── US country launch agent (US RCS for Business ID) └── CA country launch agent (Canada RCS for Business ID) ``` 키워드 및 양방향 메시징 대상은 AWS RCS 에이전트에서 구성되며 연결된 모든 RCS for Business IDs에 적용됩니다. 브랜드 자산은 각 등록(테스트 에이전트 또는 국가 출시 에이전트)마다 다릅니다. AWS RCS 에이전트에는 표시 이름, 삭제 방지 및 옵트아웃 목록과 같은 계정 수준 설정도 있습니다. ## AWS RCS 에이전트 생성 AWS End User Messaging 콘솔 또는 `CreateRcsAgent` API를 사용하여 AWS RCS 에이전트를 생성할 수 있습니다. 에이전트를 생성할 때 콘솔에 표시 이름(태그로 저장되고 API를 통해 볼 수 없거나 수신자의 전화에 표시되지 않는 콘솔 전용 레이블)을 제공하고 삭제 방지 및 옵트아웃 목록 연결과 같은 선택적 설정을 구성합니다. 브랜드 자산은 AWS RCS 에이전트 자체가 아닌 등록에 정의됩니다. ### 브랜드 자산 요구 사항 브랜드 자산은 RCS 메시지와 함께 수신자에게 표시됩니다. 브랜드 자산은 테스트 등록의 일부로 제출되며, 콘솔은 에이전트 생성 워크플로의 연속으로 제공됩니다. AWS RCS 에이전트를 생성할 때 다음 자산이 필요합니다. **로고** 브랜드를 나타내는 정사각형 이미지입니다. 로고는 메시지와 함께 메시징 앱에 표시됩니다. + 차원: 224 × 224픽셀 + 형식: 투명도가 있는 PNG + 최대 파일 크기: 50KB **배너 이미지** 메시징 앱의 에이전트 프로필 상단에 표시되는 와이드 이미지입니다. 배너 이미지는 Android 디바이스에만 표시됩니다. + 차원: 1440 × 448픽셀 + 형식: PNG 또는 JPEG + 최대 파일 크기: 200KB **브랜드 색상** 메시징 앱에서 액센트 색상으로 사용되는 16진수 색상 코드(예: `#1A73E8`)입니다. 접근성 요구 사항을 충족하려면 색상 대비 최소 대비 비율이 흰색 배경에 대해 4.5:1이어야 합니다. 대비 비율이 제대로 설정되지 않으면 에이전트가 승인되지 않을 수 있습니다. **중요** 브랜드 자산에는 에이전트가 생성된 후 변경 사항에 대한 제한이 있습니다. 에이전트가 등록을 위해 제출된 후에는 일부 브랜드 자산을 수정할 수 없습니다. AWS RCS 에이전트를 생성하기 전에 최종 브랜드 자산을 준비합니다. ------ #### [ Console ] AWS End User Messaging 콘솔은 AWS RCS 에이전트 생성 및 테스트 등록을 단일 안내 워크플로로 제공합니다. step-by-step 콘솔 지침은 단원을 참조하십시오[1단계: AWS RCS 에이전트 생성 및 테스트 등록 제출](rcs-getting-started.md#rcs-getting-started-create-agent). ------ #### [ AWS CLI ] `create-rcs-agent` 명령을 사용하여 AWS RCS 에이전트를 생성합니다. 브랜드 자산(표시 이름, 설명, 로고, 배너 및 브랜드 색상)은이 명령의 파라미터가 아닙니다. 테스트 등록을 생성할 때 등록 필드로 제출됩니다. ``` aws pinpoint-sms-voice-v2 create-rcs-agent \ --deletion-protection-enabled ``` 다음과 같은 선택적 파라미터를 사용할 수 있습니다. + `--deletion-protection-enabled` - 삭제 방지 기능이 비활성화될 때까지 에이전트가 삭제되지 않도록 합니다. + `--opt-out-list-name` - 기존 옵트아웃 목록을 에이전트와 연결합니다. + `--tags` - AWS RCS 에이전트를 구성하고 식별하기 위한 키-값 페어입니다. ------ ## AWS RCS 에이전트 업데이트 `UpdateRcsAgent` API를 사용하여 기존 AWS RCS 에이전트의 설정을 수정합니다. 다음 설정을 업데이트할 수 있습니다. + **삭제 방지** - 에이전트에 대한 삭제 방지를 활성화하거나 비활성화합니다. + **옵트아웃 목록** - 옵트아웃 목록을 에이전트와 연결하거나 연결 해제합니다. + **양방향 메시징 대상 -** 인바운드 메시지가 전달되는 Amazon SNS 주제 및 IAM 역할을 구성합니다. 양방향 메시징은 RCS에 대해 항상 활성화됩니다. 고객에게는 모든 인바운드 RCS 메시지에 대해 표준 요금이 부과됩니다. 이 설정은 수신 여부가 아니라 인바운드 메시지가 전달되는 위치를 제어합니다. **참고** API를 통한 AWS RCS 에이전트 설정 변경은 즉시 사용할 수 있습니다. 그러나 브랜드 자산(로고, 배너 및 표시 이름과 같은 등록 필드)에 대한 업데이트는 RCS 인프라 공급자가 검토하며 수신자의 디바이스에 표시되는 데 시간이 걸릴 수 있습니다. API 변경 사항이 적용되었는지 확인하려면 `DescribeRcsAgents` API를 사용하여 AWS End User Messaging에서 현재 에이전트 구성을 확인합니다. ## AWS RCS 에이전트 보기 AWS End User Messaging 콘솔 또는 `DescribeRcsAgents` API를 사용하여 AWS RCS 에이전트를 볼 수 있습니다. ------ #### [ Console ] 콘솔에서 AWS RCS 에이전트를 보려면 탐색 창의 **구성**에서 **RCS 에이전트** 페이지로 이동합니다. 목록 페이지에는 현재 수명 주기 상태, 에이전트 ID 및 표시 이름을 포함하여 계정의 모든 AWS RCS 에이전트가 표시됩니다. 브랜드 자산, 구성 설정 및 관련 등록을 포함한 세부 정보를 보려면 에이전트를 선택합니다. ------ #### [ AWS CLI ] `describe-rcs-agents` 명령을 사용하여 계정의 모든 AWS RCS 에이전트를 나열합니다. ``` aws pinpoint-sms-voice-v2 describe-rcs-agents ``` 특정 에이전트에 대한 세부 정보를 검색하려면 `--rcs-agent-ids` 파라미터를 사용합니다. ``` aws pinpoint-sms-voice-v2 describe-rcs-agents \ --rcs-agent-ids rcs-a1b2c3d4 ``` ------ ## 테스트 에이전트 검토 국가 시작 등록을 제출하기 전에 테스트 에이전트 구성을 검토하여 브랜드 자산, 키워드 및 메시징 설정이 올바른지 확인합니다. 테스트 에이전트는 국가 시작 등록을 위한 템플릿 역할을 하므로 진행하기 전에 문제를 해결해야 합니다. 테스트 에이전트를 검토하려면 AWS End User Messaging 콘솔에서 AWS RCS 에이전트로 이동하여 **등록** 탭을 선택합니다. 테스트 등록에는 로고, 배너 이미지, 브랜드 색상 및 수신자의 디바이스에 표시되는 표시 이름을 포함하여 현재 브랜드 구성이 표시됩니다. `DescribeRegistrationFieldValues` API를 사용하여 테스트 등록에 대한 현재 필드 값을 프로그래밍 방식으로 검색할 수도 있습니다. ## 국가 시작 상태 보기 AWS RCS 에이전트에 대한 국가 시작 등록을 제출한 후 해당 국가의 각 통신 사업자에 대한 승인 상태를 추적할 수 있습니다. ------ #### [ Console ] 콘솔에서 국가 시작 상태를 보려면 AWS RCS 에이전트의 세부 정보 페이지로 이동하여 **국가 시작 상태** 탭을 선택합니다. 이 탭에는 시작 등록을 제출한 각 국가의 각 통신 사업자에 대한 승인 상태가 표시됩니다. ------ #### [ AWS CLI ] `describe-rcs-agent-country-launch-status` 명령을 사용하여 캐리어별 시작 상태를 검색합니다. ``` aws pinpoint-sms-voice-v2 describe-rcs-agent-country-launch-status \ --rcs-agent-id rcs-a1b2c3d4 ``` 응답에는 시작 등록을 제출한 각 국가의 각 통신 사업자에 대한 승인 상태가 포함됩니다. ------ 각 통신 사업자는 에이전트를 독립적으로 검토하고 승인합니다. AWS RCS 에이전트는 해당 국가의 통신사가 에이전트를 승인하는 즉시 해당 국가의 메시지를 보낼 수 있습니다. RCS 메시지 전송을 시작하기 전에 모든 통신사가 승인할 때까지 기다릴 필요는 없습니다. 추가 통신사가 에이전트를 승인하면 해당 국가의 연락이 늘어납니다. **참고** 국가 시작 상태 화면에서 추가 국가 시작을 요청할 수 있습니다. 각 새 국가 출시는 별도의 등록을 생성하고 자체 통신 사업자 승인 프로세스를 거칩니다. ## AWS RCS 에이전트 삭제 `DeleteRcsAgent` API를 사용하여 AWS RCS 에이전트를 영구적으로 삭제합니다. 에이전트를 삭제하면 연결된 모든 RCS for Business IDs(테스트 에이전트 및 모든 국가 시작 에이전트 포함)가 비활성화됩니다. **주의** AWS RCS 에이전트 삭제는 영구적이며 실행 취소할 수 없습니다. 에이전트와 연결된 모든 등록, 국가 시작 및 테스트 구성이 손실됩니다. AWS RCS 에이전트를 삭제하려면 먼저 모든 관련 등록(테스트 및 국가 시작 등록 모두)을 삭제한 다음 삭제 방지를 비활성화해야 합니다. 삭제 방지가 활성화된 경우 `DeleteRcsAgent` API는 오류를 반환합니다. 삭제 방지를 비활성화하려면 삭제 방지가 로 설정된 `UpdateRcsAgent` API를 사용합니다`false`. **AWS RCS 에이전트를 삭제하려면** 1. 삭제 방지 기능이 활성화된 경우 삭제 방지 기능이 로 설정된 `UpdateRcsAgent` API를 호출하여 삭제 방지 기능을 비활성화합니다`false`. 1. 삭제하려는 AWS RCS 에이전트의 에이전트 ID 또는 ARN을 사용하여 `DeleteRcsAgent` API를 호출합니다. 1. `DescribeRcsAgents` API를 호출하여 에이전트가 삭제되었는지 확인합니다. 에이전트가 더 이상 결과에 표시되지 않거나 상태가 삭제되어야 합니다. # RCS 메시지 테스트 프로덕션 환경에서 RCS 메시징을 시작하기 전에 테스트 에이전트를 사용하여 통합을 테스트할 수 있습니다. 테스트 에이전트는 AWS RCS 에이전트에 대한 테스트 등록을 제출할 때 생성되는 RCS for Business ID입니다. 프로덕션과 동일한 전체 API 액세스를 제공하지만 등록된 테스트 디바이스로만 메시지 전송을 제한합니다. 테스트에는 통신 사업자 승인이 필요하지 않습니다. 이 장에서는 테스트 디바이스를 관리하는 방법과 일반적인 문제를 해결하는 방법을 포함하여 테스트 에이전트 자체에 중점을 둡니다. 첫 번째 AWS RCS 에이전트 생성 및 테스트 메시지 전송에 대한 step-by-step 연습은 섹션을 참조하세요[RCS 시작하기](rcs-getting-started.md). AWS RCS 에이전트 생성 및 테스트 등록 제출에 대한 자세한 내용은 섹션을 참조하세요[RCS 에이전트 관리](rcs-agents.md). **중요** 테스트 메시지는 표준 RCS 요금으로 청구됩니다. 테스트 에이전트는 통합을 검증하기 위한 테스트 환경을 제공하지만 테스트 디바이스에 대한 메시지 전송에는 프로덕션 메시지와 동일한 요금이 발생합니다. **Topics** + [테스트 에이전트란 무엇입니까?](#rcs-testing-what-is) + [테스트 디바이스 추가](#rcs-testing-add-devices) + [테스터 초대 흐름](#rcs-testing-tester-invitation) + [테스트 디바이스 보기](#rcs-testing-view-devices) + [테스트 메시지 전송](#rcs-testing-send-messages) + [SMS 대체 테스트](#rcs-testing-sms-fallback) + [RCS 테스트 문제 해결](#rcs-testing-troubleshooting) ## 테스트 에이전트란 무엇입니까? 테스트 에이전트는 AWS RCS 에이전트에 대한 테스트 등록을 제출할 때 AWS End User Messaging이 생성하는 RCS for Business ID입니다. 테스트 에이전트를 사용하면 다음을 수행할 수 있습니다. + 통신 사업자 승인 없이 등록된 테스트 디바이스에 RCS 메시지 전송 + `SendTextMessage` API를 사용하여 프로덕션에서 사용하는 것과 동일한 API인 테스트 메시지를 보냅니다. + 테스트 워크플로에 대한 풀, 구성 세트, 옵트아웃 목록, 키워드 및 기타 AWS 최종 사용자 메시징 기능 구성 + 자동 응답 키워드로 메시지를 전송하여 양방향 메시징 테스트 + 승인된 SMS 전화번호를 사용하거나 사용하지 않고 SMS 대체 동작 테스트 테스트 에이전트에 등록한 테스트 디바이스는 해당 AWS RCS 에이전트의 모든 국가에서 작동합니다. 국가별로 테스트 디바이스를 별도로 등록할 필요는 없습니다. 반대로 테스트 에이전트는 해당 국가의 국가 시작 등록을 제출했는지 여부에 관계없이 모든 국가의 테스트 디바이스에 메시지를 보낼 수 있습니다. ## 테스트 디바이스 추가 테스트 RCS 메시지를 전송하려면 먼저 하나 이상의 테스트 디바이스를 확인된 대상 번호로 등록해야 합니다. AWS End User Messaging 콘솔 또는 `CreateVerifiedDestinationNumber` API를 사용하여 테스트 디바이스를 추가할 수 있습니다. ------ #### [ Console ] 콘솔에서 테스트 디바이스는 AWS RCS 에이전트 생성 워크플로의 일부로 추가됩니다. step-by-step 콘솔 지침은 단원을 참조하십시오[2단계: 테스트 디바이스 추가](rcs-getting-started.md#rcs-getting-started-add-test-device). ------ #### [ AWS CLI ] `create-verified-destination-number` 명령을 `--rcs-agent-id` 파라미터와 함께 사용하여 AWS RCS 에이전트에 테스트 디바이스를 등록합니다. ``` aws pinpoint-sms-voice-v2 create-verified-destination-number \ --destination-phone-number +12065550100 \ --rcs-agent-id rcs-a1b2c3d4 ``` **참고** `--origination-identity` 파라미터는 필요하지 않습니다. `--rcs-agent-id`를 지정하면 명령은 해당 에이전트에 대한 RCS 테스트를 위해 전화번호를 등록합니다. 생략`--rcs-agent-id`하고 `--origination-identity` 대신를 사용하면 명령은 SMS 확인을 위해 OTP SMS를 전송합니다. 두 파라미터는 상호 배타적입니다. ------ ## 테스터 초대 흐름 테스트 디바이스를 추가하면 AWS End User Messaging은 RBM Tester Management라는 RCS 에이전트로부터 테스터 초대를 보냅니다. 초대에는 수락하거나 거부할 수 있는 버튼이 포함되어 있습니다. 120초 대기 요구 사항 및 iOS별 동작을 포함하여 테스터 초대 흐름에 대한 자세한 내용은 섹션을 참조하세요[2단계: 테스트 디바이스 추가](rcs-getting-started.md#rcs-getting-started-add-test-device). ## 테스트 디바이스 보기 AWS End User Messaging 콘솔 또는 `DescribeVerifiedDestinationNumbers` API를 사용하여 AWS RCS 에이전트에 등록된 테스트 디바이스를 볼 수 있습니다. ------ #### [ Console ] 콘솔에서 등록된 테스트 디바이스를 보려면 AWS RCS 에이전트의 세부 정보 페이지로 이동하여 **테스트** 탭을 선택합니다. 탭에는 확인 상태 및 전화번호를 포함하여 에이전트와 연결된 모든 확인된 대상 번호가 표시됩니다. ------ #### [ AWS CLI ] `describe-verified-destination-numbers` 명령을 사용하여 AWS RCS 에이전트의 테스트 디바이스를 나열합니다. 와 함께 `--filters` 파라미터를 사용하여 RCS 테스트 디바이스만 `rcs-agent-id` 표시합니다. ``` aws pinpoint-sms-voice-v2 describe-verified-destination-numbers \ --filters Name=rcs-agent-id,Values=rcs-a1b2c3d4 ``` ------ 테스트 에이전트에 등록한 테스트 디바이스는 해당 AWS RCS 에이전트에 대해 전역적으로 작동합니다. 한 AWS 리전에 등록된 테스트 디바이스는 AWS RCS 에이전트를 사용할 수 있는 모든 AWS 리전에서 전송된 테스트 메시지를 수신할 수 있습니다. ## 테스트 메시지 전송 테스트 디바이스가 테스터 초대를 수락한 후 RCS 메시지를 보낼 수 있습니다. AWS End User Messaging 콘솔 또는 `SendTextMessage` API를 사용하여 테스트 메시지를 보낼 수 있습니다. ------ #### [ Console ] **콘솔을 사용하여 테스트 메시지를 보내려면** 1. AWS End User Messaging 콘솔을 엽니다. 1. 탐색 창의 **구성**에서 **RCS 에이전트**를 선택합니다. 1. 테스트할 AWS RCS 에이전트를 선택합니다. 1. **테스트** 탭을 선택합니다. 1. **테스트 메시지 전송** 섹션의 목록에서 확인된 테스트 디바이스를 선택합니다. 1. 메시지 텍스트를 입력합니다. 1. **문자 메시지 전송**을 선택합니다. ------ #### [ AWS CLI ] `send-text-message` 명령을 사용하여 확인된 대상 번호로 테스트 메시지를 보냅니다. AWS RCS 에이전트 ARN을 발신 자격 증명으로 지정합니다. ``` aws pinpoint-sms-voice-v2 send-text-message \ --destination-phone-number +12065550100 \ --origination-identity arn:aws:sms-voice:us-east-1:123456789012:rcs-agent/rcs-a1b2c3d4 \ --message-body "Hello from RCS testing!" ``` ------ ## SMS 대체 테스트 RCS 전송이 불가능한 경우 SMS 폴백 동작을 테스트하여 메시지가 SMS를 통해 전송되었는지 확인할 수 있습니다. 승인된 SMS 번호가 없는 테스트 및 전체 end-to-end 흐름을 포함하여 SMS 폴백 테스트에 대한 전체 지침은 섹션을 참조하세요[SMS 대체 테스트](rcs-sms-fallback.md#rcs-sms-fallback-testing). ## RCS 테스트 문제 해결 다음 섹션에서는 RCS 메시지를 테스트할 때 발생할 수 있는 일반적인 문제와 이를 해결하는 방법을 설명합니다. ### 테스트 디바이스가 RCS 메시지를 수신하지 않음 테스트 디바이스가 RCS 메시지를 수신하지 않는 경우 다음을 확인합니다. + 테스트 디바이스가 테스터 초대를 수락했는지 확인합니다. `DescribeVerifiedDestinationNumbers` API를 `rcs-agent-id` 필터와 함께 사용하여 디바이스의 확인 상태를 확인합니다. + 테스트 디바이스에 RCS가 활성화되어 있는지 확인합니다. Android에서는 RCS 또는 Chat 기능에 대한 메시징 앱 설정을 확인합니다. iPhone에서 RCS에는 iOS 18 이상이 필요합니다. + 테스트 디바이스에 활성 데이터 연결이 있는지 확인합니다. RCS 메시지는 SMS 채널이 아닌 데이터를 통해 전달됩니다. + E.164 형식으로 올바른 전화번호로 전송하는지 확인합니다. ### RCS 대신 SMS로 전송된 메시지 테스트 메시지가 RCS 대신 SMS로 전달되는 경우 다음을 확인하세요. + AWS RCS 에이전트 ARN 또는 AWS RCS 에이전트를 발신 자격 증명으로 포함하는 풀을 사용하여 메시지를 전송하는지 확인합니다. SMS 전화번호만 지정하면 SMS를 통해 메시지가 전송됩니다. + 테스트 디바이스가 테스터 초대를 수락했고 올바른 AWS RCS 에이전트의 확인된 대상 번호로 등록되었는지 확인합니다. + 전송 이벤트를 확인하여 메시지가 처음에 RCS를 통해 시도되었고 SMS로 다시 전송되었는지 또는 SMS를 통해 직접 전송되었는지 확인합니다. ### 테스터 초대를 받지 못함 테스트 디바이스가 테스터 초대를 받지 못하면 다음을 확인하세요. + 테스트 디바이스를 추가한 후 테스터 초대가 도착하는 데 최대 20분이 걸릴 수 있습니다. 20분 후에도 초대가 도착하지 않으면 테스트 디바이스를 제거하고 다시 추가합니다. + 전화번호가 올바른 E.164 형식이고 유효한 휴대폰 번호인지 확인합니다. + 테스트 디바이스에 활성 데이터 연결이 있고 RCS가 활성화되어 있는지 확인합니다. ### iOS: 알 수 없는 발신자의 테스터 초대 iOS 디바이스(iPhone iOS 18 이상)에서는 RBM Tester Management의 테스터 초대가 메시지 앱의 알 수 **없는 발신자** 폴더로 필터링될 수 있습니다. 이는 알 수 없는 연락처의 메시지에 대한 기본 iOS 동작입니다. 초대를 찾으려면: **iOS에서 테스터 초대를 찾으려면** 1. iPhone에서 메시지 앱을 엽니다. 1. 왼쪽 상단 모서리에서 **필터를 탭합니다**(또는 메시지 목록에서 오른쪽으로 살짝 밀기). 1. 알 수 **없는 발신자를** 탭합니다. 1. RBM 테스터 관리 메시지를 찾아 **테스터로 만들기**를 탭하여 초대를 수락합니다. # 전화 풀을 사용한 RCS에서 SMS로의 대체 전화 풀은 AWS RCS 에이전트 및 SMS 전화번호와 같은 메시징 자격 증명의 컨테이너로, API 요청과 기본 발신 자격 증명 간에 추상화 계층을 제공합니다. 풀은 구성 변경, 숫자 유형 마이그레이션 및 RCS-to-SMS 간소화합니다. 풀에 단일 API 호출을 보내면 AWS End User Messaging이 채널 선택을 처리합니다. 이 장에서는 RCS 전송이 실패하는 방법, SMS 대체가 가능한 이유, 대체 로직 및 우선 순위, 결제 영향에 대해 설명합니다. 또한 pool-per-use-case 모범 사례와 풀에서 AWS RCS 에이전트를 추가 및 제거하는 방법을 다룹니다. 전화 풀에 대한 일반적인 내용은 섹션을 참조하세요[AWS 최종 사용자 메시징 SMS의 전화 풀](phone-pool.md). AWS RCS 에이전트 관리에 대한 자세한 내용은 섹션을 참조하세요[RCS 에이전트 관리](rcs-agents.md). **Topics** + [RCS 전송 실패 방법](#rcs-sms-fallback-how-rcs-fails) + [SMS 대체가 가능한 이유](#rcs-sms-fallback-what-makes-possible) + [풀을 사용하는 이유](#rcs-sms-fallback-why-pools) + [Pool-per-use-case 모델](#rcs-sms-fallback-pool-per-use-case) + [계정 수준 전송과 관련된 규정 준수 위험](#rcs-sms-fallback-compliance-risk) + [폴백 로직 및 우선 순위](#rcs-sms-fallback-logic) + [SMS 대체의 결제 영향](#rcs-sms-fallback-billing) + [SMS 대체 테스트](#rcs-sms-fallback-testing) + [풀에서 AWS RCS 에이전트 관리](#rcs-sms-fallback-pool-management) ## RCS 전송 실패 방법 RCS 전송은 여러 가지 이유로 실패할 수 있습니다. 이러한 장애 모드를 이해하면 폴백 전략을 계획하는 데 도움이 됩니다. + **통신 사업자가 RCS를 지원하지 않음** - 수신자의 모바일 통신 사업자가 네트워크에서 RCS 메시징을 활성화하지 않았습니다. + **디바이스가 RCS를 지원하지 않음** - 수신자의 디바이스에 RCS 기능이 없습니다(예: 이전 Android 디바이스 또는 iOS 18 이전 버전을 실행하는 iPhone). + **통신 사업자에서 에이전트가 활성화되지 않음** - AWS RCS 에이전트가 아직 수신자의 통신 사업자의 승인을 받지 않았거나 에이전트가 해당 국가의 부분 상태에 있습니다. + **디바이스에 일시적으로 연결할 수 없음** - 수신자의 디바이스가 RCS를 지원하지만 일시적으로 오프라인 상태이거나 데이터 연결이 없습니다. RCS 메시지를 전송하려면 데이터 연결이 필요합니다. 이러한 조건 중 하나라도 발생하고 풀 기반 또는 계정 수준 전송을 사용하는 경우 AWS End User Messaging은 동일한 풀 또는 계정의 전화번호를 사용하여 자동으로 SMS 전송으로 돌아갑니다. ## SMS 대체가 가능한 이유 SMS 대체에는 AWS RCS 에이전트와 동일한 풀에 있는 하나 이상의 SMS 전화번호가 모두 필요합니다. 풀에 메시지를 보내면 AWS End User Messaging은 먼저 RCS 전송을 시도합니다. RCS 전송에 실패하면 서비스는 동일한 풀의 전화번호를 사용하여 SMS를 통해 메시지를 재시도합니다. AWS RCS 에이전트(전화 번호 제외)만 있는 풀은 SMS 폴백을 지원하지 않습니다. RCS가 실패하면 메시지가 전송되지 않습니다. **중요** SMS 폴백이 작동하려면 풀에 AWS RCS 에이전트와 하나 이상의 SMS 전화번호가 모두 포함되어야 합니다. 단일 자격 증명 유형만 있는 풀은 채널 간 대체를 제공하지 않습니다. ## 풀을 사용하는 이유 RCS뿐만 아니라 모든 메시징 사용 사례에 전화 풀을 사용하는 것이 좋습니다. 풀은 다음과 같은 이점을 제공합니다. + **자동 SMS 대체** - 풀에 AWS RCS 에이전트와 SMS 전화번호가 모두 포함된 경우 AWS End User Messaging은 먼저 RCS 전송을 시도합니다. RCS 전송에 실패하면(예: 수신자의 디바이스 또는 통신사가 RCS를 지원하지 않음) 서비스는 동일한 풀의 전화번호를 사용하여 SMS를 통해 메시지를 자동으로 재시도합니다. 애플리케이션에서 대체 로직을 구현할 필요가 없습니다. + **지능형 라우팅** - 서비스는 대상, 채널 가용성 및 고정 전송 기록을 기반으로 풀에서 최상의 발신 자격 증명을 선택합니다. 이 라우팅은 `SendTextMessage` 호출할 때마다 투명하게 수행됩니다. + **단일 API 호출** - 풀 ID를 `SendTextMessage` 요청의 발신 자격 증명으로 지정합니다. 서비스는 사용자 측에서 추가 로직 없이 RCS 또는 SMS를 통해 전송할지 여부를 결정합니다. + **향후 변경에 대한 유연성** - 애플리케이션 코드를 변경하지 않고도 언제든지 풀에서 전화번호 및 AWS RCS 에이전트를 추가하거나 제거할 수 있습니다. 예를 들어 전송 통합을 수정하지 않고 SMS 폴백에 수신자 부담 전화번호를 추가하거나 10DLC 번호를 교체할 수 있습니다. + **비용 또는 단점 없음** - 풀을 생성하고 풀에 발신 자격 증명을 추가해도 추가 요금이 발생하지 않습니다. 단일 전화번호 또는 단일 AWS RCS 에이전트를 사용하더라도 풀을 사용하면 애플리케이션 변경 없이 나중에 더 많은 자격 증명을 추가할 수 있습니다. **참고** 항상 풀을 메시징에 사용하는 것이 좋습니다. 단일 발신 자격 증명이 있더라도 풀 사용에 따른 비용이나 단점은 없습니다. RCS-to-SMS 폴백의 경우 풀에 AWS RCS 에이전트와 하나 이상의 SMS 전화번호가 모두 포함되어야 합니다. 처음부터 풀로 시작하면 전송 코드를 수정하지 않고도 나중에 SMS 대체 번호 또는 추가 AWS RCS 에이전트를 추가할 수 있습니다. ## Pool-per-use-case 모델 사용 사례당 하나의 풀을 생성하는 것이 좋습니다. 각 풀에는 모든 전화번호와 단일 메시징 목적으로 사용되는 AWS RCS 에이전트가 포함되어야 합니다. 예제: + 트랜잭션 메시징에 등록된 AWS RCS 에이전트 및 10DLC 번호가 포함된 OTP 코드 및 계정 알림용 트랜잭션 **풀**입니다. + 동일한 AWS RCS 에이전트(또는 다른 에이전트)와 마케팅에 등록된 수신자 부담 전화번호가 포함된 프로모션 메시지용 마케팅 **풀**입니다. + AWS RCS 에이전트와 **약속 관련 메시지를 위한 전용 전화번호가 포함된 알림 예약을 위한 약속 알림 풀**입니다. 이 모델은 RCS 전송이 실패하고 서비스가 SMS로 돌아가면 동일한 사용 사례에 대해 등록되고 승인된 전화번호에서 대체 메시지가 전송되도록 합니다. 이렇게 하면 메시징이 통신 사업자 요구 사항 및 등록 조건을 준수할 수 있습니다. ## 계정 수준 전송과 관련된 규정 준수 위험 계정 수준에서 메시지를 전송하는 경우(풀 또는 발신 자격 증명을 지정하지 않음) AWS End User Messaging은 계정에서 사용 가능한 모든 자격 증명에서 발신 자격 증명을 선택합니다. 계정에 여러 사용 사례에 대해 등록된 전화번호가 여러 개 있는 경우 서비스는 메시지 내용과 일치하지 않는 전화번호를 선택할 수 있습니다. **중요** 사용 사례가 혼합된 계정 수준 전송은 규정 준수 위험을 초래합니다. 예를 들어 계정에 OTP 메시지에 등록된 10DLC 번호와 약속 알림에 등록된 수신자 부담 번호가 있는 경우 SMS로 돌아가는 OTP 메시지는 약속 알림 수신자 부담 전화번호에서 전송할 수 있습니다. 이로 인해 해당 번호의 등록 조건이 위반되고 통신 사업자 필터링 또는 번호 일시 중지가 발생할 수 있습니다. 이러한 위험을 방지하려면 사용 사례당 하나의 풀과 함께 풀 기반 전송을 사용합니다. `SendTextMessage` 요청에 풀 ID를 지정하면 서비스는 해당 풀에서 발신 자격 증명만 선택합니다. 풀의 모든 자격 증명이 동일한 사용 사례에 등록되므로 대체 메시지는 항상 적절한 번호에서 전송됩니다. **전송 접근 방식 규정 준수 비교** | 전송 접근 방식 | SMS 대체 동작 | 규정 준수 위험 | | --- | --- | --- | | 풀 기반(권장) | 동일한 사용 사례에 등록된 동일한 풀의 전화번호로 돌아갑니다. | 낮음 - 대체 숫자가 메시지 사용 사례와 일치합니다. | | 계정 수준 | 계정에서 사용 가능한 전화번호로 돌아갑니다. | 높음 - 여러 사용 사례가 계정을 공유하는 경우 대체 번호가 메시지 사용 사례와 일치하지 않을 수 있습니다. | | 다이렉트(AWS RCS 에이전트 ARN) | SMS 대체 없음 | 없음 - 메시지가 RCS를 통해서만 전송되거나 전혀 전송되지 않음 | ## 폴백 로직 및 우선 순위 AWS End User Messaging은 메시지에 대한 발신 자격 증명을 선택할 때(풀 또는 모든 계정 자격 증명에서) 다음 우선순위에 따라 자격 증명을 평가합니다. 1. **고정 자격 증명** - 대상 전화번호에 고정 전송 페어링이 존재하고 자격 증명을 계속 사용할 수 있는 경우 서비스는 해당 자격 증명을 사용합니다. 1. **AWS RCS 에이전트** - 고정 페어링이 없는 경우 서비스는 사용 가능한 AWS RCS 에이전트를 통해 RCS 전송을 시도합니다. 1. **SMS 단축 코드** - RCS를 사용할 수 없는 경우 서비스는 SMS 단축 코드를 선택합니다. 1. **SMS 10DLC** - 단축 코드를 사용할 수 없는 경우 서비스는 10DLC 번호를 선택합니다. 1. **SMS 수신자 부담 전화번호 -** 10DLC 번호를 사용할 수 없는 경우 서비스는 수신자 부담 전화번호를 선택합니다. 1. **SMS 발신자 ID** - 다른 자격 증명을 사용할 수 없는 경우 서비스는 발신자 ID를 선택합니다. 이 우선 순위는 사용하는 전송 패턴의 범위 내에서 적용됩니다. 풀 기반 전송의 경우 서비스는 지정된 풀의 자격 증명만 고려합니다. 계정 수준 전송의 경우 서비스는 계정의 모든 자격 증명을 고려합니다. ### 자동 SMS 대체 풀을 통해 또는 계정 수준에서 메시지를 보내면 RCS 전송이 불가능한 경우 AWS End User Messaging은 자동으로 SMS로 돌아갑니다. 폴백은 비동기식입니다. AWS End User Messaging이 RCS 메시지를 성공적으로 제출했지만 25초 이내에 전송 확인 또는 실패 신호를 받지 못하면 서비스가 SMS로 돌아갑니다. 이렇게 하면 RCS 인프라가 메시지를 수락하지만 전송이 중지되는 경우(예: 수신자의 디바이스에 일시적으로 연결할 수 없거나 통신 사업자가 RCS를 지원하지 않거나 디바이스가 RCS를 지원하지 않는 경우)가 처리됩니다. **참고** 직접 전송(AWS RCS 에이전트 ARN을 발신 자격 증명으로 지정)은 자동 SMS 대체를 지원하지 않습니다. SMS 대체가 필요한 경우 풀 기반 전송을 사용합니다. ### 고정 전송 고정 전송은 전송 일관성을 개선하는 라우팅 최적화입니다. AWS End User Messaging이 특정 발신 자격 증명을 사용하여 대상 전화번호로 메시지를 성공적으로 전송하면 서비스는 해당 페어링을 25시간 동안 기억합니다. 25시간 기간 내에 동일한 대상으로 전송되는 후속 메시지는 풀 또는 계정에서 계속 사용할 수 있는 경우 동일한 발신 자격 증명을 통해 라우팅됩니다. 고정 전송은 RCS 및 SMS 전송 모두에 적용됩니다. 예를 들어 메시지가 AWS RCS 에이전트를 통해 RCS를 통해 전송되는 경우 25시간 이내에 동일한 대상으로 전송되는 다음 메시지도 동일한 에이전트를 통해 RCS를 통해 시도됩니다. 이전 메시지가 SMS를 통해 전송된 경우(RDS 대체 후) 동일한 전화번호를 통해 SMS를 통해 다음 메시지가 시도됩니다. 고정 자격 증명이 SMS 전화번호인 경우에도 서비스는 주기적으로 RCS 전송을 재시도합니다. 이렇게 하면 디바이스가 RCS 지원을 받는 수신자(예: 통신 사업자 롤아웃 또는 디바이스 업그레이드 후)가 수동 개입 없이 RCS 메시지 수신을 시작할 수 있습니다. 고정 전송의 주요 특성: + **25시간 TTL -** 고정 페어링은 마지막으로 성공적으로 전송된 후 25시간 후에 만료됩니다. 만료 후 서비스는 다음 메시지에 대한 발신 자격 증명 우선 순위 순서를 재평가합니다. + **자동 RCS 재시도** - 고정 자격 증명이 SMS 전화번호인 경우에도 서비스는 주기적으로 RCS 전송을 시도하여 수신자가 이제 RCS를 지원하는지 확인합니다. + **수동 플러시 없음** - 고정 전송 페어링을 수동으로 플러시하거나 재설정할 수 없습니다. 페어링은 25시간 TTL 후 자동으로 만료됩니다. ### 대체 중 전송 수신 SMS 대체가 발생하면 AWS End User Messaging은 메시지를 전송한 최종 채널에 대해 단일 전송 영수증을 생성합니다. RCS 폴백 후 SMS를 통해 메시지가 전송되는 경우 전송 수신은 SMS를 전송 채널로 나타냅니다. 일반적인 상황에서 AWS End User Messaging은 SMS 대체 메시지가 전달되기 전에 RCS 메시지를 취소합니다. 이렇게 하면 수신자가 동일한 메시지를 두 번 수신하지 못합니다. 그러나 드문 경우지만 RCS 메시지와 SMS 대체 메시지가 모두 전달될 수 있습니다. 이는 RCS 메시지가 25초 제한 시간 이후이지만 취소가 완료되기 전에 전달되는 경우에 발생할 수 있습니다. 이러한 드문 이중 전송 시나리오에서는 두 채널 모두에 대한 전송 영수증을 받을 수 있습니다. 이중 전송이 결제에 미치는 영향에 대한 자세한 내용은 섹션을 참조하세요[RCS 결제 및 요금 모델](rcs-billing.md). ## SMS 대체의 결제 영향 메시지가 RCS에서 SMS로 떨어지면 실패한 RCS 시도가 아니라 SMS 전송에 대한 요금이 청구됩니다. RCS 메시지는 수신자의 디바이스로 성공적으로 전송된 경우에만 요금이 청구됩니다. RCS 전송이 실패하고 메시지가 SMS로 돌아가는 경우 해당 메시지에 대한 SMS 요금을 지불합니다. 드문 이중 전송 시나리오(RCS 메시지와 SMS 폴백 메시지가 모두 전송됨)에서는 두 전송 모두에 대해 요금이 부과될 수 있습니다. 전체 결제 세부 정보는 섹션을 참조하세요[RCS 결제 및 요금 모델](rcs-billing.md). ## SMS 대체 테스트 RCS 전송이 불가능한 경우 SMS 폴백 동작을 테스트하여 메시지가 SMS를 통해 전송되었는지 확인할 수 있습니다. 승인된 SMS 전화번호가 있는지 여부에 따라 SMS 대체를 테스트하는 두 가지 방법이 있습니다. ### 승인된 SMS 번호가 없는 테스트 AWS End User Messaging이 승인된 SMS 전화번호 없이 대체 메커니즘을 올바르게 트리거하는지 확인할 수 있습니다. 승인된 번호가 없더라도 SMS를 통해 재시도 및 실패 이벤트를 볼 수 있으며, 이는 폴백이 작동하고 있음을 확인합니다. **승인된 SMS 번호 없이 SMS 폴백을 테스트하려면** 1. 모바일 데이터 및 Wi-Fi를 비활성화하여 테스트 디바이스를 오프라인으로 전환하거나 비행기 모드를 활성화합니다. 1. AWS RCS 에이전트 ARN을 발신 자격 증명으로 사용하여 `SendTextMessage` API를 사용하여 RCS 메시지를 테스트 디바이스로 전송합니다. 1. CloudWatch 또는 이벤트 대상에서 메시지 이벤트를 확인합니다. RCS 전송이 불가능하고 서비스가 SMS 대체를 시도했음을 나타내는 전송 실패 이벤트가 표시됩니다. 대체할 수 있는 SMS 전화번호가 없으므로 SMS 전송도 실패합니다. 그러나 이벤트는 AWS End User Messaging이 폴백 메커니즘을 올바르게 트리거했는지 확인합니다. ### 승인된 SMS 번호로 테스트 완전한 end-to-end SMS 폴백 테스트를 위해 승인된 SMS 전화번호와 AWS RCS 에이전트를 동일한 전화 풀에 추가합니다. 이렇게 하면 RCS를 사용할 수 없을 때 SMS를 통해 메시지가 전달되는지 확인할 수 있습니다. **승인된 SMS 번호로 SMS 폴백을 테스트하려면** 1. AWS RCS 에이전트와 승인된 SMS 전화번호(예: 10DLC, 수신자 부담 또는 단축 코드 번호)가 모두 포함된 전화 풀을 생성합니다. 1. 모바일 데이터 및 Wi-Fi를 비활성화하여 테스트 디바이스를 오프라인으로 전환하거나 비행기 모드를 활성화합니다. 1. 풀 ID가 발신 ID인 `SendTextMessage` API를 사용하여 메시지를 전송합니다. 1. SMS를 통해 테스트 디바이스로 메시지가 전송되었는지 확인합니다. 1. 전송 이벤트를 확인하여 RCS 폴백 후 SMS 채널을 통해 메시지가 전송되었는지 확인합니다. ## 풀에서 AWS RCS 에이전트 관리 AWS RCS 에이전트를 사용하여 풀을 생성하고, 기존 풀에 에이전트를 추가하고, 풀 구성 요구 사항을 이해하고, 풀에서 에이전트를 제거하는 step-by-step 지침은 섹션을 참조하세요[풀에서 AWS RCS 에이전트 관리](phone-pool-rcs-agents.md). # RCS 메시지 전송 AWS End User Messaging은 RCS 및 SMS 전송 모두에 동일한 `SendTextMessage` API를 사용합니다. 서비스가 메시지를 라우팅하는 방법은 요청에서 지정한 발신 자격 증명에 따라 달라집니다. 전화 풀(권장), 계정 수준에서 또는 AWS RCS 에이전트 ARN을 통해 직접 메시지를 보낼 수 있습니다. 이 섹션에서는 세 가지 전송 패턴, 전송 영수증을 해석하는 방법을 설명하고 코드 예제를 제공합니다. 고정 전송, 발신 자격 증명 우선 순위 및 자동 SMS 폴백에 대한 자세한 내용은 섹션을 참조하세요[전화 풀을 사용한 RCS에서 SMS로의 대체](rcs-sms-fallback.md). AWS RCS 에이전트 관리에 대한 자세한 내용은 섹션을 참조하세요[RCS 에이전트 관리](rcs-agents.md). **Topics** + [전송 패턴](#rcs-send-message-patterns) + [고정 전송, 우선 순위 및 SMS 대체](#rcs-send-message-fallback-summary) + [코드 예제](#rcs-send-message-examples) + [RCS 메시지 전송을 위한 AI 에이전트 프롬프트](#rcs-send-message-ai-prompt) + [전송 수신 처리](#rcs-send-message-delivery-receipts) ## 전송 패턴 AWS End User Messaging은 RCS 메시지 전송을 위한 세 가지 패턴을 지원합니다. 각 패턴은 서비스가 발신 자격 증명을 선택하는 방법과 자동 SMS 대체를 사용할 수 있는지 여부를 결정합니다. **RCS 전송 패턴** | 패턴 | 작동 방식 | SMS 대체 | 사용해야 하는 경우 | | --- | --- | --- | --- | | 풀 기반(권장) | 풀 ID를 발신 자격 증명으로 지정합니다. 이 서비스는 풀에서 최상의 자격 증명을 선택합니다. | 예 | 모든 사용 사례. 규정 준수 안전 라우팅을 통해 자동 채널 선택 및 SMS 폴백을 제공합니다. | | 계정 수준 | 발신 자격 증명을 생략합니다. 서비스는 계정에서 사용 가능한 모든 자격 증명 중에서 선택합니다. | 예 | 단일 사용 사례를 사용한 간단한 설정. 사용 사례가 여러 개인 계정에는 권장되지 않습니다. | | 직접 전송 | AWS RCS 에이전트 ARN을 발신 자격 증명으로 지정합니다. 메시지는 RCS를 통해서만 전송됩니다. | 아니요 | RCS-or-nothing 사용 사례 또는 AWS 최종 사용자 메시징 외부에서 SMS 대체를 관리하는 경우. | ### 풀 기반 전송(권장) 풀 기반 전송은 모든 RCS 사용 사례에 권장되는 접근 방식입니다. 풀 ID를 `SendTextMessage` 요청의 발신 자격 증명으로 지정하면 AWS End User Messaging은 대상, 채널 가용성 및 고정 전송 기록을 기반으로 풀에서 최상의 발신 자격 증명을 선택합니다. 풀에 AWS RCS 에이전트와 SMS 전화번호가 모두 포함된 경우 서비스는 먼저 RCS 전송을 시도합니다. RCS 전송에 실패하면 서비스는 동일한 풀의 전화번호를 사용하여 자동으로 SMS로 돌아갑니다. 풀의 모든 자격 증명이 동일한 사용 사례에 등록되므로 대체 메시지는 항상 적절한 번호에서 전송됩니다. AWS RCS 에이전트를 사용하여 풀을 생성하고 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[전화 풀을 사용한 RCS에서 SMS로의 대체](rcs-sms-fallback.md). ### 계정 수준 전송 `SendTextMessage` 요청에서 발신 자격 증명을 생략하면 AWS End User Messaging은 계정에서 사용 가능한 모든 자격 증명에서 발신 자격 증명을 선택합니다. 서비스는 발신 자격 증명 우선 순위를 사용하여 사용할 자격 증명을 결정합니다. 자세한 내용은 [폴백 로직 및 우선 순위](rcs-sms-fallback.md#rcs-sms-fallback-logic)을 참조하세요. **중요** 계정에 다른 사용 사례에 등록된 전화번호가 포함된 경우 계정 수준 전송은 규정 준수 위험을 초래합니다. RCS 전송이 실패하고 서비스가 SMS로 돌아가면 메시지 내용과 일치하지 않는 전화번호를 선택할 수 있습니다. 예를 들어 OTP 메시지는 예약 알림에 등록된 수신자 부담 전화번호로 돌아가 해당 전화번호의 등록 조건을 위반할 수 있습니다. 이러한 위험을 방지하려면 사용 사례당 하나의 풀과 함께 풀 기반 전송을 사용합니다. 자세한 내용은 [계정 수준 전송과 관련된 규정 준수 위험](rcs-sms-fallback.md#rcs-sms-fallback-compliance-risk)을 참조하세요. ### 직접 전송(RCS만 해당) AWS RCS 에이전트 ARN을 `SendTextMessage` 요청의 발신 자격 증명으로 지정하면 AWS End User Messaging은 RCS를 통해서만 메시지를 전송합니다. 자동 SMS 대체는 없습니다. RCS 전송이 실패하면 메시지가 다른 채널에서 재시도되지 않습니다. 다음과 같은 경우 직접 전송을 사용합니다. + RCS-or-nothing 전송을 원합니다. 메시지는 RCS를 통해서만 전송되어야 하며 SMS 전송을 통한 전송을 선호하지 않습니다. + AWS 최종 사용자 메시징 외부에서 SMS 대체를 관리합니다. 애플리케이션은 RCS 전송 실패를 감지하고 다른 시스템 또는 공급자를 통해 별도의 SMS를 보내는 등 폴백 로직을 독립적으로 처리합니다. **참고** 직접 전송은 모든 SMS 폴백 로직을 우회합니다. 수신자의 디바이스 또는 통신사가 RCS를 지원하지 않는 경우 메시지가 전송되지 않습니다. 대부분의 사용 사례에서는 추가 비용 없이 자동 SMS 폴백을 제공하므로 풀 기반 전송이 권장됩니다. ## 고정 전송, 우선 순위 및 SMS 대체 풀을 통해 또는 계정 수준에서 메시지를 전송할 때 AWS End User Messaging은 고정 전송(25시간 라우팅 최적화), 발신 자격 증명 우선 순위 및 자동 SMS 폴백을 사용하여 각 메시지에 가장 적합한 채널과 자격 증명을 선택합니다. 자동 폴백, 폴백 중 배송 영수증, 결제 영향 등 이러한 메커니즘의 작동 방식에 대한 전체 세부 정보는 섹션을 참조하세요[전화 풀을 사용한 RCS에서 SMS로의 대체](rcs-sms-fallback.md). ## 코드 예제 다음 Python 예제에서는 세 가지 전송 패턴 각각을 사용하여 RCS 메시지를 전송하는 방법을 보여줍니다. 모든 예제에서는 boto3 `pinpoint-sms-voice-v2` 클라이언트와 `SendTextMessage` API를 사용합니다. ### 풀 기반 전송 예제 다음 예제에서는 전화 풀을 통해 메시지를 보냅니다. 서비스는 풀에서 최상의 발신 자격 증명을 선택하고 RCS 전송이 불가능한 경우 자동으로 SMS로 돌아갑니다. ``` import boto3 client = boto3.client('pinpoint-sms-voice-v2') response = client.send_text_message( DestinationPhoneNumber='+12065550100', OriginationIdentity='pool-a1b2c3d4e5f6g7h8i', MessageBody='Your appointment is confirmed for tomorrow at 2:00 PM.', MessageType='TRANSACTIONAL' ) print(f"Message ID: {response['MessageId']}") ``` ### 계정 수준 전송 예제 다음 예시에서는 발신 자격 증명을 생략하여 계정 수준에서 메시지를 보냅니다. 서비스는 우선 순위에 따라 계정에서 사용 가능한 모든 자격 증명에서 자격 증명을 선택합니다. ``` import boto3 client = boto3.client('pinpoint-sms-voice-v2') response = client.send_text_message( DestinationPhoneNumber='+12065550100', MessageBody='Your verification code is 123456.', MessageType='TRANSACTIONAL' ) print(f"Message ID: {response['MessageId']}") ``` **중요** 계정에 다른 사용 사례에 등록된 전화번호가 포함된 경우 계정 수준 전송은 메시지 콘텐츠와 일치하지 않는 번호를 통해 SMS 대체를 라우팅할 수 있습니다. 규정 준수 위험을 방지하려면 사용 사례당 하나의 풀과 함께 풀 기반 전송을 사용합니다. ### 직접 전송 예제 다음 예제에서는 AWS RCS 에이전트 ARN을 통해 직접 메시지를 보냅니다. 메시지는 SMS 대체 없이 RCS를 통해서만 전달됩니다. ``` import boto3 client = boto3.client('pinpoint-sms-voice-v2') response = client.send_text_message( DestinationPhoneNumber='+12065550100', OriginationIdentity='arn:aws:sms-voice:us-east-1:123456789012:rcs-agent/rcs-a1b2c3d4', MessageBody='Welcome to our RCS channel! Reply HELP for assistance.' ) print(f"Message ID: {response['MessageId']}") ``` **참고** 수신자의 디바이스 또는 통신사가 RCS를 지원하지 않는 경우 메시지가 전송되지 않습니다. SMS 대체는 시도되지 않습니다. RCS-or-nothing 전송을 원하거나 AWS 최종 사용자 메시징 외부에서 SMS 폴백을 관리하는 경우에만이 패턴을 사용합니다. ## RCS 메시지 전송을 위한 AI 에이전트 프롬프트 생성형 AI 코딩 어시스턴트 또는 AI 에이전트를 사용하는 경우 다음 프롬프트를 사용하여 AWS CLI 또는 SDK를 사용하여 RCS 메시지를 보내는 데 도움을 받을 수 있습니다. **참고** 다음 프롬프트를 복사하여 AI 에이전트 또는 코딩 어시스턴트에 붙여 넣습니다. ``` ## RCS Messaging Assistant Prompt Help me send RCS messages using AWS End User Messaging SMS with the `pinpoint-sms-voice-v2` service. Show me exact CLI commands and Python/boto3 examples. Ask me for my details before generating any commands. **Important rules for generating commands:** - The API is `send-text-message` — the same command used for SMS. There is NO separate RCS send API. - There is NO `describe-messages` API. Do not generate it. - The boto3 method is `send_text_message` on the `pinpoint-sms-voice-v2` client. - Use the term "testing" — NOT "sandbox". **Prerequisites:** I have an existing RCS agent (created via the setup process) and a verified test device. ### Pattern 1: Direct RCS sending (simplest, good for testing) Send directly through my RCS Agent ARN. RCS-only delivery, no SMS fallback. If the recipient's device doesn't support RCS, the message is not delivered. CLI: `send-text-message --destination-phone-number --origination-identity --message-body "" --message-type ` Returns `MessageId`. ### Pattern 2: Pool-based sending (recommended for production) Send through a phone pool containing my RCS agent (and optionally SMS phone numbers for fallback). The service tries RCS first, then falls back to SMS asynchronously if no RCS signal within 25 seconds. This is NOT synchronous fallback — the SMS is sent as a separate attempt after the timeout. To set up a pool: - `create-pool --origination-identity --message-type TRANSACTIONAL` → returns `PoolId` - Optionally add SMS numbers: `associate-origination-identity --pool-id --origination-identity ` CLI: `send-text-message --destination-phone-number --origination-identity --message-body "" --message-type ` ### Pattern 3: Account-level sending Send without specifying `--origination-identity`. The service auto-selects the best identity from the account. CLI: `send-text-message --destination-phone-number --message-body "" --message-type ` **Compliance warning:** If the account has multiple RCS agents, SMS numbers, or different use cases, the service picks an identity automatically — which may not be the intended one. Use pool-based or direct sending for explicit control over which identity is used. ### Delivery verification - For testing: check the test device directly — the message appears from the branded RCS agent. - For production: configure event destinations BEFORE sending using `create-event-destination` (SNS, CloudWatch Logs, or Firehose). Event destinations do not retroactively capture events for already-sent messages. - CloudWatch metrics in `AWS/SMSVoice` namespace provide aggregate delivery statistics. ### Behavioral notes - Sticky sending: the service remembers the last successful identity per destination number for 25 hours. - Pool-based sending is recommended for production because it provides automatic SMS fallback. - All three patterns use the same `send-text-message` API — the only difference is what you pass (or don't pass) as `--origination-identity`. --- **Before generating commands, ask me for:** - Which sending pattern I want to use (direct, pool-based, or account-level) - My RCS Agent ARN - My pool ID (if using pool-based sending) - Destination phone number in E.164 format - Message type (TRANSACTIONAL or PROMOTIONAL) - Message text ``` ## 전송 수신 처리 AWS End User Messaging은 Amazon EventBridge 및 구성 세트 이벤트 대상을 통해 RCS 메시지에 대한 전송 수신을 제공합니다. 전송 수신은 메시지의 최종 상태와 전송에 사용된 채널을 나타냅니다. 전송 수신 및 기타 메시지 이벤트를 캡처하도록 이벤트 대상을 설정하는 방법은 섹션을 참조하세요[AWS End User Messaging SMS의 이벤트 대상](configuration-sets-event-destinations.md). ### 전송 상태 값 RCS 메시지에는 다음과 같은 전송 상태 값이 적용됩니다. 전송됨 메시지가 수신자의 디바이스로 성공적으로 전송되었습니다. PENDING RCS 인프라에서 메시지를 수락했지만 전송 확인을 아직 받지 못했습니다. 메시지가 계속 전달될 수 있습니다. EXPIRED 메시지가 허용된 기간 내에 전송되지 않았습니다. SMS 폴백이 있는 RCS 메시지의 경우이 상태는 폴백이 발생하기 전에 RCS 시도에 적용됩니다. 전송할 수 없음 메시지를 전송할 수 없습니다. 이는 수신자의 디바이스에 영구적으로 연결할 수 없거나 전화번호가 유효하지 않을 때 발생할 수 있습니다. REJECTED RCS 인프라 또는 통신 사업자가 메시지를 거부했습니다. 이는 콘텐츠 정책 위반 또는 통신 사업자 수준 필터링으로 인해 발생할 수 있습니다. ### 채널 어트리뷰션 전송 수신에는 메시지가 RCS 또는 SMS를 통해 전송되었는지 여부를 나타내는 채널 속성이 포함됩니다. 이는 전송 혼합을 이해하고 결제를 위해 중요합니다. + 메시지가 RCS를 통해 전송되면 전송 수신은 RCS를 전송 채널로 표시하고 AWS RCS 에이전트 자격 증명을 포함합니다. + 메시지가 SMS로 돌아가면 전송 수신은 SMS를 전송 채널로 표시하고 전송에 사용된 SMS 전화번호 자격 증명을 포함합니다. + 직접 전송(AWS RCS 에이전트 ARN)이 실패하면 전송 수신에 RCS가 실패 상태의 시도된 채널로 표시됩니다. SMS 폴백 수신이 생성되지 않습니다. RCS CloudWatch 지표 및 모니터링 전송 패턴에 대한 자세한 내용은 섹션을 참조하세요[RCS CloudWatch 지표 및 모니터링](rcs-monitoring.md). 전송 채널이 결제에 미치는 영향에 대한 자세한 내용은 섹션을 참조하세요[RCS 결제 및 요금 모델](rcs-billing.md). # 인바운드 RCS 메시지 수신 AWS End User Messaging은 양방향 RCS 메시징을 지원하므로 고객으로부터 문자 메시지를 받을 수 있습니다. 인바운드 RCS 메시지는 SMS 양방향 메시징과 동일한 패턴을 따릅니다. 수신 메시지는 구성한 Amazon SNS 주제로 전송되며 Lambda 함수 또는 다른 SNS 구독자를 사용하여 처리합니다. **중요** 인바운드 RCS 메시지를 사용하려면 AWS RCS 에이전트에서 양방향 메시징 SNS 주제를 설정해야 합니다. 양방향 메시징은 에이전트를 생성할 때 기본적으로 비활성화됩니다. 활성화하고 SNS 주제를 구성하면 인바운드 메시지가 해당 주제로 전달됩니다. 고객에게는 모든 인바운드 RCS 메시지에 대해 표준 요금이 부과됩니다. 이 섹션에서는 양방향 RCS 메시징의 작동 방식, AWS RCS 에이전트에 대해 이를 활성화하는 방법, 인바운드 메시지 페이로드 형식, 키워드 관리 방법을 설명합니다. AWS RCS 에이전트 관리에 대한 자세한 내용은 섹션을 참조하세요[RCS 에이전트 관리](rcs-agents.md). RCS 메시지 전송에 대한 자세한 내용은 섹션을 참조하세요[RCS 메시지 전송](rcs-send-message.md). **Topics** + [양방향 RCS 메시징 작동 방식](#rcs-inbound-how-it-works) + [양방향 메시징 대상 구성](#rcs-inbound-enable) + [인바운드 메시지 페이로드 형식](#rcs-inbound-payload) + [지원되는 메시지 유형](#rcs-inbound-text-only) + [RCS에 대한 키워드 관리](#rcs-inbound-keywords) + [Lambda를 사용하여 인바운드 메시지 처리](#rcs-inbound-lambda) + [인바운드 RCS 메시징 모범 사례](#rcs-inbound-best-practices) ## 양방향 RCS 메시징 작동 방식 고객이 AWS RCS 에이전트에 문자 메시지를 보내면 AWS End User Messaging은 메시지를 수신하여 사용자가 지정한 Amazon SNS 주제에 게시합니다. 여기에서 Lambda 함수, Amazon SQS 대기열 또는 HTTP/HTTPS 엔드포인트와 같은 SNS 구독자를 사용하여 메시지를 처리할 수 있습니다. 양방향 RCS 메시징 흐름은 다음과 같이 작동합니다. 1. 고객이 RCS 지원 디바이스에서 AWS RCS 에이전트로 문자 메시지를 보냅니다. 1. AWS End User Messaging은 인바운드 메시지를 수신하고 구성된 키워드를 기준으로 평가합니다. 메시지가 키워드와 일치하면 서비스는 구성된 자동 응답(있는 경우)을 전송합니다. 1. AWS End User Messaging은 AWS RCS 에이전트에서 양방향 메시징을 위해 구성한 Amazon SNS 주제에 메시지 페이로드를 JSON 객체로 게시합니다. 1. SNS 구독자(예: Lambda 함수)는 메시지 페이로드를 수신하고 애플리케이션 로직에 따라 처리합니다. AWS End User Messaging의 RCS는 현재 인바운드 문자 메시지를 지원합니다. 고객이 AWS RCS 에이전트에 미디어 메시지(예: 이미지 또는 비디오)를 보내면 메시지가 IGNORED 상태로 로깅됩니다. 애플리케이션이 SNS 주제를 통해 미디어 메시지를 수신하지 않습니다. ## 양방향 메시징 대상 구성 애플리케이션에서 인바운드 RCS 메시지를 수신하고 처리하려면 양방향 메시징을 활성화하고 AWS RCS 에이전트에서 대상을 구성해야 합니다. 양방향 메시징은 기본적으로 비활성화되어 있습니다. 활성화할 때 AWS End User Messaging이 인바운드 메시지를 전송하는 Amazon SNS 주제를 지정합니다. AWS End User Messaging 콘솔 또는 API를 사용하여 대상을 구성할 수 있습니다. ------ #### [ Console ] **콘솔을 사용하여 양방향 메시징 대상을 구성하려면** 1. AWS End User Messaging 콘솔을 엽니다. 1. 탐색 창에서 **RCS 에이전트**를 선택합니다. 1. 구성하려는 AWS RCS 에이전트를 선택합니다. 1. **양방향 메시징** 탭을 선택합니다. 1. **설정 편집**을 선택합니다. 1. 전환 **양방향 메시징을 **켜도록 설정합니다. 1. **SNS 주제**에서 기존 Amazon SNS 주제를 선택하거나 새 주제를 생성합니다. 인바운드 메시지가 게시되는 주제입니다. 1. **저장**을 선택합니다. ------ #### [ AWS CLI ] API를 사용하여 양방향 메시징 대상을 구성하려면 다음 파라미터를 사용하여 `UpdateRcsAgent` API를 호출합니다. + `two-way-enabled` - 양방향 메시징을 활성화`true`하려면 로 설정합니다. + `two-way-channel-arn` - 인바운드 메시지가 게시되는 Amazon SNS 주제의 ARN입니다. + `two-way-channel-role` - SNS 주제에 메시지를 게시할 수 있는 AWS End User Messaging 권한을 부여하는 IAM 역할의 ARN입니다. 다음 예제에서는 AWS CLI를 사용하여 양방향 메시징 대상을 구성합니다. ``` aws pinpoint-sms-voice-v2 update-rcs-agent \ --rcs-agent-id rcs-a1b2c3d4 \ --two-way-enabled \ --two-way-channel-arn arn:aws:sns:us-east-1:123456789012:MyRCSInboundTopic \ --two-way-channel-role arn:aws:iam::123456789012:role/SMSVoiceSNSPublishRole ``` ------ ### SNS 주제 권한 양방향 RCS 메시징에 대해 구성하는 Amazon SNS 주제는 AWS End User Messaging이 메시지를 게시하도록 허용해야 합니다. 액세스 권한을 부여할 수 있는 두 가지 옵션이 있습니다. #### 옵션 1: IAM 역할 사용 AWS End User Messaging이 SNS 주제에 메시지를 게시하기 위해 맡을 수 있는 IAM 역할을 생성합니다. 역할에는 신뢰 정책과 권한 정책이 모두 필요합니다. 다음은 IAM 역할에 대한 **신뢰 정책**입니다. *accountId*를 해당 AWS 계정의 고유한 ID로 바꿉니다. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "SMSVoice", "Effect": "Allow", "Principal": { "Service": "sms-voice.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "accountId" } } } ] } ``` 다음은 IAM 역할에 대한 **권한 정책**입니다. `SMSVoiceAllowSNSPublish` Sid를 사용하면 Amazon SNS 주제에 게시할 수 있으며 암호화된 Amazon SNS 주제의 경우 `SMSVoiceAllowEncryptedSNSTopics` Sid는 선택 사항입니다. 다음과 같이 변경합니다. + *파티션*을 AWS End User Messaging을 AWS 사용하는 파티션으로 바꿉니다. + *리전*을 AWS End User Messaging AWS 리전 을 사용하는 로 바꿉니다. + *accountId*를 해당 AWS 계정의 고유한 ID로 바꿉니다. + *snsTopicName*을 인바운드 메시지를 수신하는 Amazon SNS 주제의 이름으로 바꿉니다. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "SMSVoiceAllowSNSPublish", "Effect": "Allow", "Action": "sns:Publish", "Resource": "arn:partition:sns:region:accountId:snsTopicName", "Condition": { "StringEquals": { "aws:ResourceAccount": "accountId" } } }, { "Sid": "SMSVoiceAllowEncryptedSNSTopics", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey*" ], "Resource": "*", "Condition": { "StringEquals": { "kms:EncryptionContext:aws:sns:topicArn": "arn:partition:sns:region:accountId:snsTopicName", "aws:CalledViaLast": "sns.amazonaws.com" } } } ] } ``` #### 옵션 2: SNS 주제 정책 사용 또는 AWS End User Messaging이 메시지를 게시할 수 있도록 허용하는 정책 설명을 SNS 주제에 직접 추가합니다. *snsTopicArn*을 SNS 주제의 ARN으로 바꿉니다. ``` { "Effect": "Allow", "Principal": { "Service": "sms-voice.amazonaws.com" }, "Action": "sns:Publish", "Resource": "snsTopicArn" } ``` ## 인바운드 메시지 페이로드 형식 AWS RCS 에이전트가 인바운드 문자 메시지를 받으면 AWS End User Messaging은 구성된 Amazon SNS 주제에 JSON 페이로드를 게시합니다. RCS 인바운드 메시지 페이로드는 SMS 양방향 메시징과 동일한 형식을 사용합니다. ``` { "originationNumber": "+14255550182", "destinationNumber": "+12125550101", "messageKeyword": "JOIN", "messageBody": "EXAMPLE", "inboundMessageId": "cae173d2-66b9-564c-8309-21f858e9fb84", "previousPublishedMessageId": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" } ``` 인바운드 메시지 페이로드에는 다음 필드가 포함됩니다. **인바운드 RCS 메시지 페이로드 필드** | 필드 | 설명 | | --- | --- | | `originationNumber` | 인바운드 메시지를 보낸 전화번호(고객의 전화번호). | | `destinationNumber` | 메시지를 수신한 AWS RCS 에이전트의 식별자입니다. | | `messageKeyword` | 인바운드 메시지와 일치하는 등록된 키워드가 있는 경우 키워드는 메시지 본문의 시작 부분에 대해 평가됩니다. | | `messageBody` | 인바운드 메시지의 텍스트 콘텐츠입니다. | | `inboundMessageId` | 인바운드 메시지의 고유 식별자입니다. | | `previousPublishedMessageId` | 인바운드 메시지가 이전 아웃바운드 메시지에 대한 응답인 경우 고객이 응답하는 아웃바운드 메시지의 고유 식별자입니다. | ## 지원되는 메시지 유형 AWS End User Messaging의 RCS는 현재 인바운드 문자 메시지 수신을 지원합니다. 고객이 AWS RCS 에이전트에 문자 메시지를 보내면 해당 메시지가 구성된 Amazon SNS 주제로 전송되어 처리됩니다. 고객이 AWS RCS 에이전트에 미디어 메시지(예: 이미지, 비디오 또는 파일)를 보내는 경우 AWS End User Messaging은 메시지를 IGNORED 상태로 기록합니다. 미디어 메시지는 SNS 주제로 전송되지 않으며 애플리케이션에서 처리되지 않습니다. 발신자에게 오류가 반환되지 않습니다. ## RCS에 대한 키워드 관리 키워드를 사용하면 고객이 AWS RCS 에이전트에 특정 단어나 문구를 보낼 때 자동 응답을 구성할 수 있습니다. 인바운드 메시지가 구성된 키워드와 일치하면 AWS End User Messaging은 연결된 자동 응답 메시지를 고객에게 다시 보냅니다. RCS의 경우 키워드는 AWS RCS 에이전트에서 구성되며 연결된 모든 RCS for Business IDs(테스트 에이전트 및 국가 시작 에이전트)에 적용됩니다. AWS RCS 에이전트당 최대 30개의 키워드를 구성할 수 있습니다. AWS RCS 에이전트의 키워드를 관리하려면 AWS End User Messaging 콘솔 또는 API를 사용합니다. 키워드 관리에 대한 일반적인 내용은 섹션을 참조하세요[AWS 최종 사용자 메시징 SMS의 키워드](keywords.md). **참고** AWS RCS 에이전트에 구성된 키워드는 모든 관련 등록에 적용됩니다. 테스트 에이전트와 국가 시작 에이전트에 대해 서로 다른 키워드를 독립적으로 설정할 수 없습니다. ## Lambda를 사용하여 인바운드 메시지 처리 인바운드 RCS 메시지를 처리하는 일반적인 패턴은 양방향 메시징을 위해 구성된 Amazon SNS 주제에 Lambda 함수를 구독하는 것입니다. Lambda 함수는 인바운드 메시지 페이로드를 수신하고 고객 문의 응답, 명령 처리 또는 다른 시스템으로 메시지 라우팅과 같은 애플리케이션 로직을 구현할 수 있습니다. 다음 Python 예제는 인바운드 RCS 메시지를 처리하고 `SendTextMessage` API를 사용하여 응답을 전송하는 Lambda 함수를 보여줍니다. ``` import json import boto3 sms_client = boto3.client('pinpoint-sms-voice-v2') def lambda_handler(event, context): # Parse the SNS message for record in event['Records']: sns_message = json.loads(record['Sns']['Message']) origination_number = sns_message['originationNumber'] message_body = sns_message['messageBody'] keyword = sns_message.get('messageKeyword', '') print(f"Received message from {origination_number}: {message_body}") # Process the message and determine a response if keyword.upper() == 'HELP': response_text = 'Available commands: HELP, STATUS, STOP' elif keyword.upper() == 'STATUS': response_text = 'Your account is active. No action needed.' else: response_text = ( f'Thanks for your message. ' f'Reply HELP for available commands.' ) # Send a response back to the customer try: response = sms_client.send_text_message( DestinationPhoneNumber=origination_number, OriginationIdentity='pool-a1b2c3d4e5f6g7h8i', MessageBody=response_text, MessageType='TRANSACTIONAL' ) print(f"Response sent. Message ID: {response['MessageId']}") except Exception as e: print(f"Failed to send response: {str(e)}") return {'statusCode': 200} ``` 이 예제에서 Lambda 함수는 다음과 같습니다. 1. SNS 이벤트의 인바운드 메시지 페이로드를 구문 분석합니다. 1. `messageKeyword` 필드를 확인하여 고객의 의도를 결정합니다. 1. `SendTextMessage` API를 통해 풀 기반 전송(권장)을 사용하여 응답을 전송합니다. 풀은 채널 선택을 자동으로 처리합니다. **참고** 인바운드 메시지에 대한 응답을 전송할 때 고객의 디바이스가 더 이상 RCS를 지원하지 않는 경우 풀 기반 전송을 사용하여 자동 SMS 폴백을 보장합니다. 전송 패턴에 대한 자세한 내용은 섹션을 참조하세요[RCS 메시지 전송](rcs-send-message.md). ## 인바운드 RCS 메시징 모범 사례 양방향 RCS 메시징을 구현할 때는 다음 모범 사례를 따르세요. + **오류 처리 구현** - Lambda 함수 또는 SNS 구독자가 오류를 정상적으로 처리해야 합니다. 함수가 메시지를 처리하지 못하면 SNS 구독에서 DLQ(Dead Letter Queue)를 구성하여 나중에 다시 시도할 수 있도록 처리되지 않은 메시지를 캡처합니다. + **폴백 응답 전송** - 애플리케이션에서 처리할 수 없는 메시지를 수신하면 응답 없이 고객을 떠나지 말고 유용한 폴백 응답을 전송합니다. 예를 들어 사용 가능한 명령으로 응답하거나 고객을 대체 지원 채널로 안내합니다. + **응답에 풀 기반 전송 사용** - 인바운드 메시지에 응답을 전송할 때 풀 기반 전송을 사용하여 자동 SMS 폴백을 보장합니다. 이렇게 하면 디바이스가 더 이상 RCS를 지원하지 않더라도 응답이 고객에게 전달됩니다. + **메시지 처리 모니터링** - Amazon CloudWatch 지표를 사용하여 인바운드 메시지 볼륨 및 처리 성공률을 모니터링합니다. 인바운드 메시지의 갑작스러운 증가 또는 높은 처리 실패율과 같은 비정상적인 패턴에 대한 경보를 설정합니다. RCS 지표에 대한 자세한 내용은 섹션을 참조하세요[RCS CloudWatch 지표 및 모니터링](rcs-monitoring.md). + **키워드 응답을 일관되게 처리** - 키워드 자동 응답과 애플리케이션의 프로그래밍 방식 응답이 충돌하지 않도록 합니다. 특정 키워드에 대한 키워드 자동 응답을 구성해도 Lambda 함수는 여전히 메시지를 수신합니다. 이미 자동 응답이 구성된 키워드에 대해 중복 응답을 보내지 않도록 함수를 설계합니다. # 국가에서 RCS 시작 테스트 에이전트를 사용하여 RCS 메시징 통합을 테스트한 후 다음 단계는 하나 이상의 국가에서 AWS RCS 에이전트를 시작하는 것입니다. 각 국가 출시는 해당 국가의 각 통신 사업자에 대해 승인된 별도의 RCS for Business ID를 생성합니다. AWS End User Messaging은 미국 및 캐나다에서 RCS 국가 출시를 지원합니다. 국가 시작 프로세스는 다음 경로를 따릅니다. AWS RCS 에이전트를 생성하고 테스트 등록을 제출하여 테스트 에이전트를 가져온 다음 하나 이상의 국가 시작 등록을 제출합니다. 각 국가 시작 등록은 해당 국가의 각 통신 사업자에 대해 별도의 승인 프로세스를 거칩니다. **참고** AWS End User Messaging 콘솔은 AWS RCS 에이전트 생성 및 테스트 등록을 단일 안내 워크플로로 제공합니다. API 사용자는 AWS RCS 에이전트를 별도로 생성할 수 있으며 기술적으로 테스트 등록을 건너뛸 수 있지만 국가 시작 등록을 제출하기 전에 테스트를 완료하는 것이 좋습니다. AWS RCS 에이전트가 RCS for Business IDs[RCS란 무엇입니까?](rcs-overview.md). AWS RCS 에이전트 생성 및 관리에 대한 자세한 내용은 섹션을 참조하세요[RCS 에이전트 관리](rcs-agents.md). **Topics** + [등록 테스트](#rcs-country-launch-testing-registration) + [국가 출시를 위한 템플릿으로 에이전트 테스트](#rcs-country-launch-template) + [미국에서 출시](#rcs-country-launch-us) + [캐나다에서 출시](#rcs-country-launch-ca) + [사용 사례 선택](#rcs-country-launch-use-cases) + [등록 상태 관리](#rcs-country-launch-registration-states) + [캐리어별 시작 상태](#rcs-country-launch-carrier-status) + [통신 사업자 승인 타임라인](#rcs-country-launch-timelines) + [일반적인 등록 문제 및 문제 해결](#rcs-country-launch-troubleshooting) ## 등록 테스트 국가 시작 등록을 제출하려면 먼저 AWS RCS 에이전트에 대한 테스트 등록을 완료해야 합니다. 테스트 등록은 프로덕션으로 이동하기 전에 통합을 검증하는 데 사용할 수 있는 테스트 에이전트(RCS for Business ID)를 생성합니다. AWS RCS 에이전트 생성 및 테스트 등록 완료에 대한 step-by-step 지침은 섹션을 참조하세요[RCS 시작하기](rcs-getting-started.md). 테스트 디바이스 관리 및 테스트 메시지 전송에 대한 자세한 내용은 섹션을 참조하세요[RCS 메시지 테스트](rcs-testing.md). **중요** 테스트 메시지는 표준 RCS 요금으로 청구됩니다. ## 국가 출시를 위한 템플릿으로 에이전트 테스트 **중요** 테스트 에이전트는 모든 국가 시작 등록을 위한 템플릿 역할을 합니다. 테스트 등록 중에 설정하는 브랜드 구성은 각 국가 시작 양식에 미리 채워집니다. 국가 출시를 제출하기 직전에 테스트 에이전트 구성을 가져오는 데 시간을 할애하세요. 국가 시작 등록을 제출하면 AWS End User Messaging 콘솔이 테스트 에이전트의 브랜드 구성으로 등록 양식을 자동으로 채웁니다. 여기에는 브랜드 이름, 로고, 배너 이미지, 브랜드 색상, 설명 및 웹 사이트 URL이 포함됩니다. 각 국가 시작에 대해 필드를 사용자 지정할 수 있습니다. 예를 들어 소비자 대면 에이전트 이름, 로고, 배너 이미지 또는 연락처 정보를 현지 요구 사항에 맞게 조정할 수 있습니다. 국가마다 브랜드 자산이 다를 수 있습니다. 테스트 에이전트는 시작점을 제공하지만 각 국가 시작은 독립적으로 사용자 지정할 수 있습니다. ## 미국에서 출시 미국에서 AWS RCS 에이전트를 시작하려면 등록 유형을 사용하여 국가 시작 `US_RCS_LAUNCH` 등록을 제출하세요. 미국 시작 등록에는 테스트 등록에 제공한 정보 이외의 추가 정보가 필요합니다. ### 미국 등록 요구 사항 미국 시작 등록에는 다음 정보가 필요합니다. + **브랜드 정보** - 테스트 에이전트 구성에서 자동으로 채워집니다. 브랜드 이름, 설명, 웹 사이트 URL 및 연락처 정보를 검토하고 조정할 수 있습니다. + **사용 사례 선택** - RCS 메시징의 사용 사례 범주를 선택합니다. 사용 가능한 범주에는 OTP(일회성 암호), 트랜잭션, 프로모션 및 다중 용도가 포함됩니다. + **화면 녹화** - RCS 메시징 경험을 보여주는 화면 녹화를 제공해야 합니다. 녹음에는 RCS 메시지를 수신하고 상호 작용하는 최종 사용자 경험이 표시되어야 합니다. 이는 미국 출시와 관련된 요구 사항입니다. + **개인 정보 보호 정책 및 서비스 약관** - 개인 정보 보호 정책 및 서비스 페이지의 URLs입니다. **중요** 화면 녹화 요구 사항은 미국 시작 등록에만 적용됩니다. RCS 메시징 사용 사례를 명확하게 보여주는 녹음을 제공해야 합니다. 유효한 화면 녹화 없이 제출된 등록은 거부됩니다. ## 캐나다에서 출시 캐나다에서 AWS RCS 에이전트를 시작하려면 등록 유형을 사용하여 국가 시작 `CA_RCS_LAUNCH` 등록을 제출하세요. 캐나다 시작 등록에는 미국 시작과 다른 양식 필드 요구 사항이 있습니다. ### 캐나다 등록 요구 사항 캐나다 시작 등록에는 다음 정보가 필요합니다. + **브랜드 정보** - 테스트 에이전트 구성에서 자동으로 채워집니다. 캐나다 시장용 브랜드 이름, 설명, 웹 사이트 URL 및 연락처 정보를 검토하고 조정할 수 있습니다. + **사용 사례 선택** - RCS 메시징의 사용 사례 범주를 선택합니다. 사용 가능한 범주에는 OTP(일회성 암호), 트랜잭션, 프로모션 및 다중 용도가 포함됩니다. + **개인 정보 보호 정책 및 서비스 약관** - 개인 정보 보호 정책 및 서비스 페이지의 URLs입니다. **참고** 캐나다 시작 등록에는 화면 녹화가 필요하지 않습니다. 양식 필드 요구 사항은 미국 시작 등록과 다릅니다. 등록 양식을 주의 깊게 검토하여 캐나다 시장에서 모든 필수 필드가 작성되었는지 확인합니다. ## 사용 사례 선택 국가 시작 등록을 제출할 때 RCS 메시징을 사용하는 방법을 설명하는 사용 사례 범주를 선택해야 합니다. 사용 사례 범주는 승인 프로세스의 일부로 통신 사업자가 검토합니다. 사용 사례 범주는 다음과 같습니다. **중요** 에이전트를 시작하려면 사용 사례 예제를 제공해야 합니다. 에이전트의 구성 및 기능이 결정되므로 적절한 사용 사례를 선택합니다. 잘못 선택하면 배포가 지연되거나 문제가 발생할 수 있습니다. **OTP(일회용 암호)** 계정 인증 또는 보안 트랜잭션 확인에 사용됩니다. **허용되지 않음:** 제품 업데이트, 제안 또는 프로모션. **트랜잭션** 고객의 제품 또는 서비스와 관련된 알림 및 업데이트(예: 알림, 확인, 계정 업데이트)를 전송합니다. **허용되지 않음:** 제안, 프로모션, 할인 또는 업그레이드. **프로모션** 미완료 거래에 대한 알림을 포함하여 판매를 늘리기 위한 제안, 프로모션 및 마케팅 메시지에 사용됩니다. **허용되지 않음:** OTPs, 2FA 또는 긴급 트랜잭션 알림. **다중 사용** 메시징에 트랜잭션 및 프로모션 메시지가 모두 포함된 경우(예: 구매 확인 전송 후 관련 제안 전송) 사용됩니다. **허용되지 않음:** OTP/2FA, 암호 재설정 또는 순수 트랜잭션 또는 순수 프로모션 사용. ## 등록 상태 관리 국가 시작 등록은 다단계 승인 프로세스를 거칩니다. 등록 상태 및 등록 버전 상태라는 두 가지 상태 세트를 사용하여 등록 진행 상황을 추적할 수 있습니다. ### 등록 상태 등록 상태는 국가 시작 등록의 전체 상태를 추적합니다. **생성됨** 등록이 생성되었지만 아직 제출되지 않았습니다. 이 상태에서 등록 양식 필드를 편집할 수 있습니다. **SUBMITTED** 등록이 제출되었으며 검토를 기다리고 있습니다. **검토** 통신 사업자가 등록을 검토 중입니다. 등록이이 상태인 동안에는 수정할 수 없습니다. **완료** 등록이 승인되었으며 국가 시작 에이전트(RCS for Business ID)가 활성 상태입니다. AWS RCS 에이전트는이 국가에서 메시지를 보낼 수 있습니다. **REQUIRES\$1UPDATES** 등록을 승인하려면 먼저 변경해야 합니다. 제공된 피드백을 검토하고 필수 필드를 업데이트한 다음 등록을 다시 제출합니다. **닫힘** 등록이 종료되었습니다. 연결된 리소스가 제거되었습니다. **삭제됨** 등록이 삭제되었습니다. ### 등록 버전 상태 각 등록에는 여러 버전이 있을 수 있습니다. 버전 상태는 특정 버전의 등록 상태를 추적합니다. **초안** 버전이 준비 중이며 제출되지 않았습니다. 이 상태에서 양식 필드를 편집할 수 있습니다. **SUBMITTED** 버전이 검토를 위해 제출되었습니다. **검토** 통신 사업자가 버전을 검토 중입니다. **APPROVED** 버전이 승인되었습니다. 이 국가에서는 국가 시작 에이전트가 활성 상태입니다. **거부됨** 버전이 거부되었습니다. 피드백을 검토하고 필요한 변경 사항이 포함된 새 버전을 제출합니다. **취소됨** 이전에 승인된 버전이 취소되었습니다. 국가 시작 에이전트가 더 이상 활성 상태가 아닙니다. **아카이빙됨** 버전이 아카이브되었습니다. 더 이상 활성 버전이 아니지만 기록 참조를 위해 유지됩니다. **폐기됨** 제출 전에 버전이 삭제되었습니다. ## 캐리어별 시작 상태 국가 시작 등록을 제출한 후 해당 국가의 각 통신 사업자는 AWS RCS 에이전트를 독립적으로 검토하고 승인합니다. 개별 통신 사업자 수준과 국가 집계 수준 모두에서 승인 상태를 추적할 수 있습니다. ### 통신 사업자 상태 한 국가의 각 통신 사업자에는 다음 승인 상태 중 하나가 있습니다. **PENDING** 통신 사업자가 에이전트를 검토하고 있습니다. 아무 조치도 필요하지 않습니다. **ACTIVE** 통신사가 에이전트를 승인했습니다. AWS RCS 에이전트는이 통신 사업자 네트워크의 수신자에게 RCS 메시지를 보낼 수 있습니다. **거부됨** 통신 사업자가 에이전트를 거부했습니다. 거부 이유를 검토하고 필요한 변경 사항이 포함된 새 등록 버전을 제출합니다. ### 국가 집계 상태 국가 수준 집계 상태는 한 국가의 모든 운송업체에 대한 운송업체 승인 상태를 요약합니다. **PENDING** 해당 국가의 모든 통신 사업자가 여전히 에이전트를 검토하고 있습니다. 아직 에이전트를 승인하거나 거부한 통신 사업자가 없습니다. **부분** 하나 이상의 통신사가 에이전트를 승인했지만 모든 통신사가 검토를 완료한 것은 아닙니다. AWS RCS 에이전트는 승인된 통신사의 수신자에게 메시지를 보낼 수 있습니다. **ACTIVE** 해당 국가의 모든 통신사가 에이전트를 승인했습니다. AWS RCS 에이전트가이 국가에 완전히 연결되어 있습니다. **거부됨** 해당 국가의 모든 통신사가 에이전트를 거부했습니다. AWS RCS 에이전트는 해당 국가의 통신사가 에이전트를 승인하는 즉시 해당 국가의 메시지를 보낼 수 있습니다. RCS 메시지 전송을 시작하기 전에 모든 통신사가 승인할 때까지 기다릴 필요는 없습니다. 수신자가 아직 에이전트를 승인하지 않은 통신 사업자에 있는 경우 풀 기반 또는 계정 수준 전송을 사용하는 경우 AWS End User Messaging은 자동으로 SMS로 돌아갑니다. 추가 통신사가 에이전트를 승인하면 해당 국가의 RCS 도달 범위가 증가합니다. AWS RCS 에이전트의 캐리어별 시작 상태를 보려면 `DescribeRcsAgentCountryLaunchStatus` API를 사용하거나 AWS End User Messaging 콘솔의 에이전트 세부 정보 페이지에서 **국가 시작 상태** 탭으로 이동합니다. ## 통신 사업자 승인 타임라인 RCS 국가 출시에 대한 운송업체 승인은 대상 국가의 각 운송업체가 검토하는 다단계 프로세스입니다. 승인 타임라인은 통신 사업자와 등록의 완전성에 따라 달라집니다. 미국과 캐나다의 경우 국가 시작 등록을 제출한 시점으로부터 몇 개월이 걸릴 것으로 예상합니다. 타임라인에는 초기 검토, 필요한 업데이트 및 운송업체별 롤아웃이 포함됩니다. 원활한 승인 프로세스를 보장하려면: + 제출하기 전에 모든 필수 등록 필드를 정확하게 작성합니다. + 미국 출시의 경우 RCS 메시징 사용 사례를 보여주는 명확하고 완전한 화면 녹화를 제공합니다. + 검토 프로세스의 REQUIRES\$1UPDATES 피드백에 즉시 응답합니다. + 개인 정보 보호 정책 및 서비스 URLs에 액세스할 수 있고 최신 상태인지 확인합니다. ## 일반적인 등록 문제 및 문제 해결 다음 섹션에서는 국가 시작 등록 프로세스 중에 발생할 수 있는 일반적인 문제와 이를 해결하는 방법을 설명합니다. ### 등록하려면 업데이트가 필요합니다. 등록이 REQUIRES\$1UPDATES 상태가 되면 등록 세부 정보에 제공된 피드백을 검토합니다. 일반적인 이유는 다음과 같습니다. + 불완전하거나 부정확한 브랜드 정보입니다. + 화면 녹화가 누락되었거나 유효하지 않습니다(미국만 시작). + 액세스할 수 없거나 요구 사항을 충족하지 않는 개인 정보 보호 정책 또는 서비스 URLs의 약관입니다. + 의도한 메시징 목적을 명확하게 설명하지 않는 사용 사례 설명입니다. 필수 필드를 업데이트하고 등록을 다시 제출합니다. 등록이 제출됨 상태로 돌아가고 다시 검토됩니다. ### 통신 사업자가 에이전트를 거부함 통신 사업자가 AWS RCS 에이전트를 거부하는 경우 통신 사업자 상태 세부 정보에 제공된 거부 이유를 검토합니다. 일반적인 거부 이유는 다음과 같습니다. + 운송업체의 품질 표준을 충족하지 않는 브랜드 자산입니다. + 통신 사업자의 메시징 정책을 준수하지 않는 사용 사례입니다. + 비즈니스 또는 메시징 목적에 대한 정보가 충분하지 않습니다. 거부 피드백을 처리하고 새 등록 버전을 제출합니다. 한 통신 사업자의 거부는 동일한 국가의 다른 통신 사업자의 승인 상태에 영향을 주지 않습니다. ### 장기간 등록 검토 중 미국 및 캐나다의 운송업체 승인 타임라인은 일반적으로 몇 개월입니다. 등록이 예상보다 오래 검토 중 상태인 경우: + 등록에 누락된 REQUIRES\$1UPDATES 상태가 없는지 확인합니다. + `DescribeRcsAgentCountryLaunchStatus` API를 사용하여 운송업체별 상태를 확인하여 일부 운송업체가 이미 승인했지만 다른 운송업체는 아직 검토 중인지 확인합니다. + 비정상적으로 장기간 검토 중인 등록에 대한 지원이 필요한 경우 AWS Support에 문의하세요. ### 등록 거부 이유 등록이 거부되면 AWS End User Messaging은 등록이 승인되지 않은 이유를 설명하는 거부 이유를 제공합니다. 다음 표에는 모든 RCS 등록 거부 이유와 각각에 대한 권장 작업이 나와 있습니다. **RCS 등록 거부 이유** | 거부 이유 | 설명 | 권장 조치 | | --- | --- | --- | | REQUIRES\$1OFFLINE\$1REVIEW | 이 등록에는 수동 오프라인 검토가 필요합니다. | 지원 센터에서 AWS 지원 사례를 생성합니다. RCS 에이전트 지원 범주를 선택하고 등록 ID를 포함합니다. [를 통해 등록 문제에 지원 대한 자세한 정보 가져오기](registrations-request-support.md)을(를) 참조하세요. | | CANNOT\$1UPDATE\$1REGISTRATION | 특정 RCS 에이전트 필드는 기존 등록에서 수정할 수 없습니다. | 수정된 필드를 사용하여 새 테스트 등록을 생성합니다. | | IMAGE\$1URL\$1INACCESSIBLE | 제공된 이미지 URL은 공개적으로 액세스할 수 없습니다. | 인증 없이 액세스할 수 있는 URL을 제공합니다. 등록을 업데이트하고 다시 제출합니다. | | IMAGE\$1FORMAT\$1INVALID | 이미지는 JPEG 또는 PNG 형식이어야 합니다. | 이미지를 올바른 형식으로 업로드하고 다시 제출합니다. | | IMAGE\$1RESOLUTION\$1INVALID | 이미지가 필요한 해상도를 충족하지 않습니다. 로고는 224 x 224픽셀이어야 하며 배너는 1440 x 448픽셀이어야 합니다. | 이미지 크기를 필요한 차원으로 조정하고 다시 제출합니다. | | IMAGE\$1SIZE\$1EXCEEDED | 이미지 파일 크기가 허용된 제한을 초과합니다. 로고는 50KB를 초과할 수 없으며 배너는 200KB를 초과할 수 없습니다. | 파일 크기를 줄이고 다시 제출합니다. | | ACCENT\$1COLOR\$1CONTRAST\$1INSUFFICIENT | 액센트 색상은 흰색에 비해 4.5:1 이상의 대비 비율을 가져야 합니다. | 대비 요구 사항을 충족하는 어두운 액센트 색상을 선택하고 다시 제출합니다. | | PRIVACY\$1POLICY\$1INACCESSIBLE | 제공된 개인 정보 보호 정책 URL에 액세스할 수 없거나 유효하지 않습니다. | 공개적으로 액세스할 수 있는 개인 정보 보호 정책 URL을 제공하고 다시 제출합니다. | | TERMS\$1AND\$1CONDITIONS\$1INACCESSIBLE | 제공된 이용 약관 URL에 액세스할 수 없거나 유효하지 않습니다. | 공개적으로 액세스할 수 있는 이용 약관 URL을 제공하고 다시 제출합니다. | | CONTACT\$1DETAILS\$1MISSING | 에이전트 프로필에는 하나 이상의 연락 방법(전화, 이메일 또는 웹 사이트)이 필요하며 각 연락 값에는 해당 레이블이 있어야 합니다. | 에이전트 프로필에 하나 이상의 연락 방법을 추가합니다. 각 연락처 값에 해당 레이블이 있는지 확인합니다(예: 전화번호를 제공하는 경우 전화 레이블도 제공). 등록을 업데이트하고 다시 제출합니다. | AWS 지원 지원이 필요한 거부 이유가 있는 경우 지원 [AWS 센터에서 지원](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase) 사례를 생성합니다. 사례 설명에 AWS RCS 에이전트 ID와 등록 ID를 포함합니다. # RCS CloudWatch 지표 및 모니터링 AWS End User Messaging은 `AWS/SMSVoice` 네임스페이스의 CloudWatch에 RCS 메시징 지표를 게시합니다. 이러한 지표를 사용하여 RCS 메시지 전송을 모니터링하고, RCS에서 SMS로의 대체 동작을 추적하고, 전송 패턴이 변경될 때 알림을 받도록 경보를 설정할 수 있습니다. RCS 지표는 동일한 네임스페이스에 기존 SMS 및 MMS 지표와 함께 게시됩니다. **Topics** + [RCS 메시징 지표](#rcs-monitoring-rcs-metrics) + [OriginationIdentityType 차원으로 기존 지표 수정](#rcs-monitoring-modified-metrics) + [RCS 지표 차원](#rcs-monitoring-dimensions) + [인바운드 RCS 메시지 지표](#rcs-monitoring-inbound) + [RCS 모범 사례 모니터링](#rcs-monitoring-best-practices) ## RCS 메시징 지표 `AWS/SMSVoice` 네임스페이스에는 RCS 메시징과 관련된 다음 지표가 포함됩니다. 이러한 지표는 RCS 메시지 전송, 전송 및 SMS 대체를 추적합니다. **RCS 메시징 지표** | 지표 | 설명 | 단위 | 의미 있는 통계 | | --- | --- | --- | --- | | RCS.MessagesSent | 전송된 RCS 메시지 수입니다. 이 지표는 AWS End User Messaging이 수락하고 RCS를 통해 전송하려고 시도한 메시지를 계산합니다. 보호 또는 서비스 제한으로 차단된 메시지는이 수에서 제외됩니다. | 개수 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sms-voice/latest/userguide/rcs-monitoring.html) | | RCS.MessagesDelivered | 수신자의 디바이스로 성공적으로 전송된 RCS 메시지 수입니다. AWS End User Messaging이 RCS 인프라로부터 전송 확인을 수신하면 메시지가 전송된 것으로 계산됩니다. | 개수 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sms-voice/latest/userguide/rcs-monitoring.html) | | RCS.MessagesFallenBackToSMS | RCS를 통해 처음 시도되었지만 SMS 전송으로 다시 떨어진 메시지 수입니다. 이 지표는 수신자가 RCS 전송을 사용할 수 없는 빈도를 이해하고 시간 경과에 따른 폴백 속도를 추적하는 데 사용할 수 있습니다. | 개수 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sms-voice/latest/userguide/rcs-monitoring.html) | ## OriginationIdentityType 차원으로 기존 지표 수정 RCS를 추가하면 `AWS/SMSVoice` 네임스페이스의 여러 기존 지표가 이제 `OriginationIdentityType`차원을 지원합니다. 이 차원을 사용하면 AWS RCS 에이전트를 포함하여 메시지를 전송하는 데 사용되는 발신 자격 증명 유형을 기준으로 지표를 필터링할 수 있습니다. 이제 다음과 같은 기존 지표에 `OriginationIdentityType`차원이 포함됩니다. + `NumberOfTextMessagePartsSent` - 발신 자격 증명 유형을 기준으로 필터링하여 각 채널(전화 번호, 발신자 ID, AWS RCS 에이전트 또는 풀)을 통해 전송된 텍스트 메시지 파트 수를 확인합니다. + `NumberOfTextMessagePartsDelivered` - 발신 자격 증명 유형을 기준으로 필터링하여 채널 간 전송률을 비교합니다. + `NumberOfMediaMessagePartsSent` - 발신 자격 증명 유형을 기준으로 필터링하여 채널별로 미디어 메시지 전송을 추적합니다. + `NumberOfMediaMessagePartsDelivered` - 발신 자격 증명 유형을 기준으로 필터링하여 채널 간 미디어 메시지 전송을 비교합니다. + `TextMessagesBlockedByProtect` - 발신 자격 증명 유형을 기준으로 필터링하여 보호 규칙에 의해 차단된 메시지가 있는 채널을 확인합니다. + `MediaMessagesBlockedByProtect` - 발신 자격 증명 유형을 기준으로 필터링하여 채널별 보호 차단을 추적합니다. 값이 인 `OriginationIdentityType`차원을 사용하여 AWS RCS 에이전트`RCS_AGENT`를 통해 전송된 메시지에 대한 지표를 격리합니다. 사용 가능한 차원 값에 대한 자세한 내용은 섹션을 참조하세요[RCS 지표 차원](#rcs-monitoring-dimensions). ## RCS 지표 차원 다음 차원을 사용하여 RCS 지표를 필터링하고 그룹화할 수 있습니다. 이러한 차원은 새 RCS별 지표와 이전 섹션에 설명된 수정된 기존 지표 모두에 사용할 수 있습니다. ### OriginationIdentityType 차원 `OriginationIdentityType` 차원은 메시지를 보내는 데 사용되는 발신 자격 증명 유형을 기준으로 지표를 필터링합니다. **OriginationIdentityType 차원 값** | 값 | 설명 | | --- | --- | | PHONE\$1NUMBER | 전화번호(긴 코드, 단축 코드 또는 수신자 부담 전화번호)를 사용하여 전송된 메시지입니다. | | SENDER\$1ID | 발신자 ID를 사용하여 전송된 메시지입니다. | | RCS\$1AGENT | AWS RCS 에이전트를 사용하여 전송된 메시지입니다. | | POOL | 전화 풀을 사용하여 전송된 메시지입니다. 풀을 통해 전송할 때 AWS End User Messaging은 적절한 발신 자격 증명(AWS RCS 에이전트 또는 전화번호)을 자동으로 선택합니다. | ### MessageType 차원 `MessageType` 차원은 메시지 유형별로 지표를 필터링합니다. **MessageType 차원 값** | 값 | 설명 | | --- | --- | | TEXT | RCS 또는 SMS를 통해 전송되는 문자 메시지입니다. | | MEDIA | 미디어 메시지(MMS). AWS End User Messaging의 RCS는 현재 문자 메시지만 지원합니다. | | DELIVERY\$1REPORT | 메시지 전송 상태를 확인하는 전송 보고서 메시지입니다. | **참고** AWS End User Messaging의 현재 RCS 릴리스에서는 읽기 수신이 지원되지 않으므로 `READ_REPORT` 메시지 유형을 사용할 수 없습니다. ## 인바운드 RCS 메시지 지표 이제 `AWS/SMSVoice` 네임스페이스의 기존 `NumberOfMessagesReceived` 지표에 인바운드 RCS 메시지가 포함됩니다. 값이 인 `OriginationIdentityType`차원을 사용하여 AWS RCS 에이전트`RCS_AGENT`를 통해 수신된 인바운드 메시지를 필터링할 수 있습니다. 인바운드 RCS 메시지 지표에 사용할 수 있는 차원은 다음과 같습니다. + `OriginationIdentityType` - 인바운드 RCS 메시지를 필터링`RCS_AGENT`하는 데 사용합니다. + `IsoCountryCode` - 인바운드 메시지 발신자의 국가 코드를 기준으로 필터링합니다. + `MessageType` - RCS를 통해 수신된 텍스트 메시지를 필터링`TEXT`하는 데 사용합니다. 현재 릴리스에서 AWS End User Messaging의 RCS는 인바운드 문자 메시지만 지원합니다. ## RCS 모범 사례 모니터링 다음 모범 사례를 사용하여 RCS 메시징 작업을 모니터링하고 전송 문제를 조기에 식별합니다. ### RCS 및 SMS 전송 속도 추적 `RCS.MessagesDelivered`와 비교하여 RCS와 SMS`RCS.MessagesFallenBackToSMS`를 통해 전송되는 메시지의 비율을 파악합니다. 폴백 비율이 높으면 많은 수신자가 RCS를 지원하지 않는 통신 사업자 또는 디바이스에 있음을 나타낼 수 있습니다. 다음 공식을 사용하여 키 요금을 계산합니다. ``` RCS delivery rate = 100 * SUM(RCS.MessagesDelivered) / SUM(RCS.MessagesSent) SMS fallback rate = 100 * SUM(RCS.MessagesFallenBackToSMS) / SUM(RCS.MessagesSent) ``` RCS에 대한 통신 사업자 및 디바이스 지원이 확장됨에 따라 시간 경과에 따른 이러한 속도를 추적하여 추세를 식별합니다. 감소하는 폴백 속도는 더 많은 수신자가 RCS를 통해 메시지를 수신하고 있음을 나타냅니다. ### RCS 지표에 대한 CloudWatch 경보 설정 CloudWatch 경보를 생성하여 RCS 메시징 패턴이 예기치 않게 변경될 때 알려줍니다. 다음 조건에 대한 경보를 설정하는 것이 좋습니다. + **높은 폴백 속도** -의 임계값 백분율을 `RCS.MessagesFallenBackToSMS` 초과할 때 경보를 설정합니다`RCS.MessagesSent`. 폴백이 갑자기 증가하면 AWS RCS 에이전트에 문제가 있거나 통신 사업자가 중단된 것일 수 있습니다. + **전송 속도 감소** - `RCS.MessagesDelivered`의 비율이 예상 전송 속도 아래로 `RCS.MessagesSent` 떨어질 때 경보를 설정합니다. + **인바운드 메시지 볼륨** - 양방향 RCS 메시징을 사용하는 경우 경보를 켜서`NumberOfMessagesReceived`(에 의해 필터링됨`OriginationIdentityType = RCS_AGENT`) 인바운드 메시지 볼륨의 예기치 않은 변경을 감지합니다. # RCS 결제 및 요금 모델 AWS End User Messaging의 RCS 메시징은 메시지 요금과 마크업 없이 전달되는 통신사 요금이라는 AWS 두 가지 비용 구성 요소가 있는 요금 모델을 사용합니다. 이 장에서는 RCS 메시징의 요금 구조를 설명합니다. 현재 요금은 [AWS 최종 사용자 메시징 요금을](https://aws.amazon.com//end-user-messaging/pricing/) 참조하세요. AWS End User Messaging은 수신자의 디바이스로 성공적으로 전달된 경우에만 RCS 메시지에 대해 요금을 부과합니다. 실패한 전송 시도에 대해서는 요금이 부과되지 않습니다. RCS 메시지가 실패하고 SMS로 돌아가는 경우 실패한 RCS 시도가 아닌 전송된 SMS 메시지에 대한 요금이 청구됩니다. **Topics** + [결제 개요](#rcs-billing-overview) + [미국 요금 모델](#rcs-billing-us-pricing) + [캐나다 요금 모델](#rcs-billing-ca-pricing) + [등록 수수료](#rcs-billing-registration-fees) + [이중 배달 결제](#rcs-billing-double-delivery) + [콘텐츠 위반 수수료](#rcs-billing-content-violations) + [청구서 투명성](#rcs-billing-transparency) ## 결제 개요 AWS End User Messaging의 RCS 결제에는 다음과 같은 구성 요소가 있습니다. + **메시지 요금** - 메시지 세그먼트를 기준으로 한 아웃바운드 및 인바운드 RCS 메시지에 대한 메시지당 요금입니다. + **통신 사업자 요금** - AWS 마크업 없이 통신 사업자의 패스스루 요금입니다. + **등록 수수료** - 에이전트 설정, 브랜드 심사 및 유지 관리에 대한 일회성 및 반복 요금입니다. 각 구성 요소는 AWS 청구서에 별도의 항목으로 표시되므로 RCS 메시징 비용을 파악할 수 있습니다. ## 미국 요금 모델 미국의 RCS 메시징은 **Rich RCS**라는 메시지 유형을 사용합니다. 리치 RCS 메시지는 SMS와 마찬가지로 160자 세그먼트별로 측정됩니다. 160자를 초과하는 메시지는 여러 세그먼트에 대해 요금이 부과됩니다. 각 아웃바운드 또는 인바운드 Rich RCS 메시지에는 두 가지 비용 구성 요소가 있습니다. **메시지 전송 요금** RCS 메시지 처리 및 전송에 AWS 대해에서 부과하는 세그먼트별 요금입니다. **통신 사업자 요금(패스스루)** 통신 사업자가 RCS 메시지 전송에 대해 부과하는 세그먼트당 요금입니다. AWS 는이 요금을 마크업 없이 전달합니다. 통신 사업자 요금은 메시지 전송 비용과는 별개입니다. 메시지당 총 비용은 메시지 전송 요금과 통신 사업자 요금입니다. 인바운드 RCS 메시지(최종 사용자가 AWS RCS 에이전트로 보낸 메시지)는 동일한 두 구성 요소 요금 구조를 따릅니다. **참고** RCS 메시지는 배달된 메시지에 대해서만 요금이 부과됩니다. 이는 요청된 메시지에 대해 요금을 부과하는 SMS와 다릅니다. 현재 세그먼트별 요금은 [AWS 최종 사용자 메시징 요금을](https://aws.amazon.com//end-user-messaging/pricing/) 참조하세요. ## 캐나다 요금 모델 캐나다의 RCS 메시징은 두 가지 메시지 유형을 사용합니다. **RCS 기본** 메시지는 최대 160자입니다. 메시지당 요금이 부과됩니다. **RCS 단일** 160자를 초과하는 메시지. 여러 세그먼트가 아닌 단일 메시지로 청구됩니다. 이는 SMS와 유사한 160자 세그먼트당 160자를 초과하는 리치 RCS 메시지가 측정되는 미국과 다릅니다. 캐나다의 각 아웃바운드 또는 인바운드 RCS 메시지에는 메시지 전송 요금과 통신사 전달 요금이라는 두 가지 비용 구성 요소가 있습니다. **참고** RCS 메시지는 배달된 메시지에 대해서만 요금이 부과됩니다. 이는 요청된 메시지에 대해 요금을 부과하는 SMS와 다릅니다. 현재 요금은 [AWS 최종 사용자 메시징 요금을](https://aws.amazon.com//end-user-messaging/pricing/) 참조하세요. ## 등록 수수료 AWS RCS 에이전트를 시작하려면 RCS 인프라 공급자에 등록해야 합니다. 등록 프로세스에는 다음 통신 사업자 패스스루 요금이 적용됩니다. **일회성 에이전트 설정 요금** AWS RCS 에이전트를 생성하고 등록할 때 일회성 요금이 부과됩니다. 여기에는 RCS 인프라 공급자를 사용한 에이전트의 초기 설정 및 확인이 포함됩니다. **연간 브랜드 심사 요금** 브랜드 자격 증명 확인에 대한 연간 요금입니다. 브랜드 심사는 조직이 합법적이고 브랜드 이름으로 RCS 메시지를 보낼 권한이 있는지 확인합니다. **월별 에이전트 유지 관리 요금** RCS 인프라 공급자에 대한 활성 AWS RCS 에이전트 등록을 유지하기 위한 월 기본 요금입니다. 이러한 등록 수수료는 통신 사업자 패스스루 요금입니다. 현재 등록 수수료 금액은 [AWS 최종 사용자 메시징 요금을](https://aws.amazon.com//end-user-messaging/pricing/) 참조하세요. **중요** RCS 등록 수수료는 엔터프라이즈 할인 프로그램(EDP) 할인에서 제외됩니다. 이러한 요금은 RCS 인프라 공급자의 패스스루 요금이며 AWS 대량 구매 할인을 받을 수 없습니다. 등록 수수료는 AWS 청구서에 별도의 항목으로 표시됩니다. 요금이 분류되는 방법에 대한 자세한 내용은 AWS 비용 및 사용 보고서를 참조하세요. ## 이중 배달 결제 AWS End User Messaging이 SMS 폴백이 활성화된 RCS 메시지를 보내면(풀 기반 또는 계정 수준 전송을 통해) 서비스가 먼저 RCS 전송을 시도합니다. RCS 전송에 실패하면 서비스가 SMS로 돌아갑니다. 일반적인 상황에서는 SMS 대체 메시지가 전송되기 전에 RCS 메시지가 취소됩니다. 이 경우 성공적으로 전송된 SMS 메시지에 대해서만 요금이 부과됩니다. 드문 경우지만 RCS 메시지와 SMS 대체 메시지가 모두 수신자에게 전달될 수 있습니다. 이는 RCS 메시지가 취소 기간 이후에 SMS 메시지가 도착하기 전에 전달되는 경우에 발생할 수 있습니다. 이중 전송이 발생하면 RCS 메시지와 SMS 메시지 모두에 대해 요금이 부과됩니다. **참고** 이중 전송은 흔하지 않습니다. AWS End User Messaging은 SMS 폴백을 시작하기 전에 RCS 메시지를 취소하도록 설계되었습니다. 전송 수신 및 CloudWatch 지표를 모니터링하여 전송 채널 어트리뷰션을 추적합니다. RCS 지표에 대한 자세한 내용은 섹션을 참조하세요[RCS CloudWatch 지표 및 모니터링](rcs-monitoring.md). ## 콘텐츠 위반 수수료 메시징에 대한 국가 법률 및 규정과 통신 사업자 정책을 준수하는 것은 모든 RCS 메시지 발신자의 책임입니다. 통신 사업자는 메시지 콘텐츠 정책을 위반하는 RCS 메시지에 대해 페널티 요금을 부과할 수 있습니다. 이러한 페널티는 통신 사업자가 메시지 콘텐츠 정책을 위반한 것으로 표시하는 RCS 메시지를 보내는 고객에게 전달 AWS 될 수 있는 통신 사업자 부과 요금입니다. 통신 사업자는 일반적으로 콘텐츠 위반을 다음 계층으로 분류합니다. **티어 1 - 피싱, 스미싱 및 소셜 엔지니어링** 소셜 엔지니어링은 신용카드 번호 또는 주민등록번호와 같은 비공개 정보를 공개하도록 조작하는 방식으로 개인을 대상으로 하는 관행을 말합니다. **티어 2 - 잘못된 콘텐츠** 콘텐츠는 50개 주 및 연방 모두에서 합법적이어야 합니다. 불법 콘텐츠에는 대마초, 마리화나, CBD, 불법 처방 및 요청 등이 포함되며 이에 국한되지 않습니다. **티어 3 - 기타 위반** 금지된 콘텐츠에 대한 연방, 주 또는 현지 법률, 규정 또는 통신 사업자 행동 규범을 위반하는 기타 모든 상용 메시징 위반. 콘텐츠 위반 수수료 금액에 대한 자세한 내용은 [AWS 최종 사용자 메시징 요금을](https://aws.amazon.com//end-user-messaging/pricing/) 참조하세요. ## 청구서 투명성 RCS 요금은 AWS 청구서에 별도의 항목으로 표시되므로 다음 비용 범주를 구분할 수 있습니다. + RCS 메시지 요금(AWS 요금) + RCS 통신 사업자 요금(통과 요금) + RCS 등록 수수료(패스스루 요금) + SMS 메시지 요금(RDS에서 SMS로 반송된 메시지의 경우) 이렇게 분리하면 메시징 비용을 이해하고 지출을 최적화할 기회를 식별할 수 있습니다. 자세한 결제 정보는 AWS 비용 및 사용 보고서를 참조하세요.