기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 전화 풀을 사용한 RCS에서 SMS로의 대체
<a name="rcs-sms-fallback"></a>

전화 풀은 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 전송 실패 방법
<a name="rcs-sms-fallback-how-rcs-fails"></a>

RCS 전송은 여러 가지 이유로 실패할 수 있습니다. 이러한 장애 모드를 이해하면 폴백 전략을 계획하는 데 도움이 됩니다.
+ **통신 사업자가 RCS를 지원하지 않음** - 수신자의 모바일 통신 사업자가 네트워크에서 RCS 메시징을 활성화하지 않았습니다.
+ **디바이스가 RCS를 지원하지 않음** - 수신자의 디바이스에 RCS 기능이 없습니다(예: 이전 Android 디바이스 또는 iOS 18 이전 버전을 실행하는 iPhone).
+ **통신 사업자에서 에이전트가 활성화되지 않음** - AWS RCS 에이전트가 아직 수신자의 통신 사업자의 승인을 받지 않았거나 에이전트가 해당 국가의 부분 상태에 있습니다.
+ **디바이스에 일시적으로 연결할 수 없음** - 수신자의 디바이스가 RCS를 지원하지만 일시적으로 오프라인 상태이거나 데이터 연결이 없습니다. RCS 메시지를 전송하려면 데이터 연결이 필요합니다.

이러한 조건 중 하나라도 발생하고 풀 기반 또는 계정 수준 전송을 사용하는 경우 AWS End User Messaging은 동일한 풀 또는 계정의 전화번호를 사용하여 자동으로 SMS 전송으로 돌아갑니다.

## SMS 대체가 가능한 이유
<a name="rcs-sms-fallback-what-makes-possible"></a>

SMS 대체에는 AWS RCS 에이전트와 동일한 풀에 있는 하나 이상의 SMS 전화번호가 모두 필요합니다. 풀에 메시지를 보내면 AWS End User Messaging은 먼저 RCS 전송을 시도합니다. RCS 전송에 실패하면 서비스는 동일한 풀의 전화번호를 사용하여 SMS를 통해 메시지를 재시도합니다. AWS RCS 에이전트(전화 번호 제외)만 있는 풀은 SMS 폴백을 지원하지 않습니다. RCS가 실패하면 메시지가 전송되지 않습니다.

**중요**  
SMS 폴백이 작동하려면 풀에 AWS RCS 에이전트와 하나 이상의 SMS 전화번호가 모두 포함되어야 합니다. 단일 자격 증명 유형만 있는 풀은 채널 간 대체를 제공하지 않습니다.

## 풀을 사용하는 이유
<a name="rcs-sms-fallback-why-pools"></a>

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 모델
<a name="rcs-sms-fallback-pool-per-use-case"></a>

사용 사례당 하나의 풀을 생성하는 것이 좋습니다. 각 풀에는 모든 전화번호와 단일 메시징 목적으로 사용되는 AWS RCS 에이전트가 포함되어야 합니다. 예제:
+ 트랜잭션 메시징에 등록된 AWS RCS 에이전트 및 10DLC 번호가 포함된 OTP 코드 및 계정 알림용 트랜잭션 **풀**입니다.
+ 동일한 AWS RCS 에이전트(또는 다른 에이전트)와 마케팅에 등록된 수신자 부담 전화번호가 포함된 프로모션 메시지용 마케팅 **풀**입니다.
+ AWS RCS 에이전트와 **약속 관련 메시지를 위한 전용 전화번호가 포함된 알림 예약을 위한 약속 알림 풀**입니다.

이 모델은 RCS 전송이 실패하고 서비스가 SMS로 돌아가면 동일한 사용 사례에 대해 등록되고 승인된 전화번호에서 대체 메시지가 전송되도록 합니다. 이렇게 하면 메시징이 통신 사업자 요구 사항 및 등록 조건을 준수할 수 있습니다.

## 계정 수준 전송과 관련된 규정 준수 위험
<a name="rcs-sms-fallback-compliance-risk"></a>

계정 수준에서 메시지를 전송하는 경우(풀 또는 발신 자격 증명을 지정하지 않음) AWS End User Messaging은 계정에서 사용 가능한 모든 자격 증명에서 발신 자격 증명을 선택합니다. 계정에 여러 사용 사례에 대해 등록된 전화번호가 여러 개 있는 경우 서비스는 메시지 내용과 일치하지 않는 전화번호를 선택할 수 있습니다.

**중요**  
사용 사례가 혼합된 계정 수준 전송은 규정 준수 위험을 초래합니다. 예를 들어 계정에 OTP 메시지에 등록된 10DLC 번호와 약속 알림에 등록된 수신자 부담 번호가 있는 경우 SMS로 돌아가는 OTP 메시지는 약속 알림 수신자 부담 전화번호에서 전송할 수 있습니다. 이로 인해 해당 번호의 등록 조건이 위반되고 통신 사업자 필터링 또는 번호 일시 중지가 발생할 수 있습니다.

이러한 위험을 방지하려면 사용 사례당 하나의 풀과 함께 풀 기반 전송을 사용합니다. `SendTextMessage` 요청에 풀 ID를 지정하면 서비스는 해당 풀에서 발신 자격 증명만 선택합니다. 풀의 모든 자격 증명이 동일한 사용 사례에 등록되므로 대체 메시지는 항상 적절한 번호에서 전송됩니다.


**전송 접근 방식 규정 준수 비교**  

| 전송 접근 방식 | SMS 대체 동작 | 규정 준수 위험 | 
| --- | --- | --- | 
| 풀 기반(권장) | 동일한 사용 사례에 등록된 동일한 풀의 전화번호로 돌아갑니다. | 낮음 - 대체 숫자가 메시지 사용 사례와 일치합니다. | 
| 계정 수준 | 계정에서 사용 가능한 전화번호로 돌아갑니다. | 높음 - 여러 사용 사례가 계정을 공유하는 경우 대체 번호가 메시지 사용 사례와 일치하지 않을 수 있습니다. | 
| 다이렉트(AWS RCS 에이전트 ARN) | SMS 대체 없음 | 없음 - 메시지가 RCS를 통해서만 전송되거나 전혀 전송되지 않음 | 

## 폴백 로직 및 우선 순위
<a name="rcs-sms-fallback-logic"></a>

 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 대체
<a name="rcs-sms-fallback-automatic"></a>

풀을 통해 또는 계정 수준에서 메시지를 보내면 RCS 전송이 불가능한 경우 AWS End User Messaging은 자동으로 SMS로 돌아갑니다. 폴백은 비동기식입니다.

 AWS End User Messaging이 RCS 메시지를 성공적으로 제출했지만 25초 이내에 전송 확인 또는 실패 신호를 받지 못하면 서비스가 SMS로 돌아갑니다. 이렇게 하면 RCS 인프라가 메시지를 수락하지만 전송이 중지되는 경우(예: 수신자의 디바이스에 일시적으로 연결할 수 없거나 통신 사업자가 RCS를 지원하지 않거나 디바이스가 RCS를 지원하지 않는 경우)가 처리됩니다.

**참고**  
직접 전송(AWS RCS 에이전트 ARN을 발신 자격 증명으로 지정)은 자동 SMS 대체를 지원하지 않습니다. SMS 대체가 필요한 경우 풀 기반 전송을 사용합니다.

### 고정 전송
<a name="rcs-sms-fallback-sticky"></a>

고정 전송은 전송 일관성을 개선하는 라우팅 최적화입니다. 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 후 자동으로 만료됩니다.

### 대체 중 전송 수신
<a name="rcs-sms-fallback-delivery-receipts"></a>

SMS 대체가 발생하면 AWS End User Messaging은 메시지를 전송한 최종 채널에 대해 단일 전송 영수증을 생성합니다. RCS 폴백 후 SMS를 통해 메시지가 전송되는 경우 전송 수신은 SMS를 전송 채널로 나타냅니다.

일반적인 상황에서 AWS End User Messaging은 SMS 대체 메시지가 전달되기 전에 RCS 메시지를 취소합니다. 이렇게 하면 수신자가 동일한 메시지를 두 번 수신하지 못합니다. 그러나 드문 경우지만 RCS 메시지와 SMS 대체 메시지가 모두 전달될 수 있습니다. 이는 RCS 메시지가 25초 제한 시간 이후이지만 취소가 완료되기 전에 전달되는 경우에 발생할 수 있습니다. 이러한 드문 이중 전송 시나리오에서는 두 채널 모두에 대한 전송 영수증을 받을 수 있습니다.

이중 전송이 결제에 미치는 영향에 대한 자세한 내용은 섹션을 참조하세요[RCS 결제 및 요금 모델](rcs-billing.md).

## SMS 대체의 결제 영향
<a name="rcs-sms-fallback-billing"></a>

메시지가 RCS에서 SMS로 떨어지면 실패한 RCS 시도가 아니라 SMS 전송에 대한 요금이 청구됩니다. RCS 메시지는 수신자의 디바이스로 성공적으로 전송된 경우에만 요금이 청구됩니다. RCS 전송이 실패하고 메시지가 SMS로 돌아가는 경우 해당 메시지에 대한 SMS 요금을 지불합니다.

드문 이중 전송 시나리오(RCS 메시지와 SMS 폴백 메시지가 모두 전송됨)에서는 두 전송 모두에 대해 요금이 부과될 수 있습니다. 전체 결제 세부 정보는 섹션을 참조하세요[RCS 결제 및 요금 모델](rcs-billing.md).

## SMS 대체 테스트
<a name="rcs-sms-fallback-testing"></a>

RCS 전송이 불가능한 경우 SMS 폴백 동작을 테스트하여 메시지가 SMS를 통해 전송되었는지 확인할 수 있습니다. 승인된 SMS 전화번호가 있는지 여부에 따라 SMS 대체를 테스트하는 두 가지 방법이 있습니다.

### 승인된 SMS 번호가 없는 테스트
<a name="rcs-sms-fallback-testing-without-sms"></a>

 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 번호로 테스트
<a name="rcs-sms-fallback-testing-with-sms"></a>

완전한 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 에이전트 관리
<a name="rcs-sms-fallback-pool-management"></a>

AWS RCS 에이전트를 사용하여 풀을 생성하고, 기존 풀에 에이전트를 추가하고, 풀 구성 요구 사항을 이해하고, 풀에서 에이전트를 제거하는 step-by-step 지침은 섹션을 참조하세요[풀에서 AWS RCS 에이전트 관리](phone-pool-rcs-agents.md).