macOS 26.5에서 Mac, iPad, Apple Watch의 RCS 메시지 전송 실패: 숨겨진 셀룰러 설정 수정 방법

이번 주 macOS Tahoe 26.5로 업데이트하고 나서 Android를 사용하는 친구에게 보내는 문자 메시지가 갑자기 밝은 빨간색 "메시지 전송 실패"로 실패하는 경우——그것도 Mac, iPad, 또는 Apple Watch에서 보낼 때만——그것은 착각이 아니고, 차단된 것도 아니며, 계정이나 하드웨어에 전혀 문제가 없습니다. 이것은 2026년 5월 11일에 출시된 macOS 26.5(iOS 26.5 빌드와 함께)에서 도입된 실제 회귀 현상이며, 업데이트가 공개된 지 몇 시간 만에 이 문제를 추적하는 MacRumors 포럼 스레드(스레드 2482378, 제목 "iOS 26.5 및 macOS 26.5에서 RCS 문제를 겪고 있는 분 있으신가요?")에는 400개가 넘는 답글이 달렸습니다. 사용자들의 불만은 거의 동일합니다. Mac에서 입력한 메시지에 빨간 느낌표가 표시되고, iPhone을 꺼내 같은 사람에게 같은 문자를 보내면 완벽하게 전송됩니다. iPhone 작성기에서도 메시지가 "RCS"로 표시됩니다. 즉, Mac과 iPhone 사이의 RCS 브리지가 끊어진 것이며, SMS와 iMessage의 Continuity 링크는 그대로이지만, 이미 노트북으로 타이핑하고 있는 상태에서 단순히 누군가에게 답장을 보내고 싶은데 기기를 바꿔야 하는 상황이 된 것입니다.

좋은 소식은 수정 방법이 있으며, 그것은 토글 하나뿐이라는 것입니다. 나쁜 소식은 그 토글이 iPhone의 세 단계 아래 메뉴에 숨겨져 있고, 겉보기에는 메시지와 전혀 관련이 없으며, 이 글을 쓰는 시점에 Apple이 어떤 릴리스 노트나 지원 문서에서도 이 회귀 현상을 인정하지 않았다는 것입니다. 이것은 프라이버시와 기능성 사이의 트레이드오프이며, 스위치를 바꾸기 전에 정확히 무엇을 끄는지 이해할 자격이 있습니다. 이 가이드에서는 수정 방법을 안내하고, 문제를 일으킨 기본 E2EE 핸드셰이크 변경을 설명하며, 통신사별 특이사항(T-Mobile 사용자들이 가장 큰 피해를 입고 있습니다)을 다루고, 주요 토글이 특정 상황을 해결하지 못할 경우의 대안적 수정 방법을 제공합니다.

핵심 요약

• 증상: macOS 26.5 / iOS 26.5에서 Mac, iPad, 또는 Apple Watch에서 RCS 메시지를 보낼 때 빨간색 "메시지 전송 실패"가 표시됩니다. 같은 메시지를 iPhone에서 직접 작성하면 정상적으로 전송됩니다.
• 토글 하나로 해결하는 방법: iPhone에서 설정 → 셀룰러 → 본인 회선 → 셀룰러 데이터 옵션으로 이동하여 RCS 메시지를 처리하는 SIM의 "IP 주소 추적 제한"을 끄기로 설정합니다.
• 원인: macOS 26.5의 새로운 E2EE(End-to-End Encrypted) RCS 핸드셰이크가 암호화된 페이로드를 Apple 릴레이를 통해 라우팅합니다. 이 릴레이는 셀룰러 회선의 iCloud 프라이빗 릴레이 방식의 IP 마스킹과 호환되지 않아, 메시지가 iPhone을 떠나기 전에 핸드셰이크를 조용히 중단시킵니다.
• 영향을 받는 사용자: T-Mobile US 고객이 가장 높은 실패율을 보고하고 있으며, 그 다음이 Verizon과 AT&T입니다. Google Fi 사용자는 Fi가 Apple이 아닌 Google의 RCS 경로를 사용하기 때문에 거의 영향을 받지 않습니다. E2EE RCS가 활성화된 국제 통신사는 사례별로 영향을 받습니다.
• 트레이드오프: "IP 주소 추적 제한"을 끄면 통신사(및 iPhone이 셀룰러로 방문하는 웹사이트)가 IP 주소를 더 명확하게 볼 수 있습니다. iMessage, FaceTime, 또는 iCloud 트래픽에는 영향이 없습니다——프라이빗 릴레이가 활성화된 경우 해당 트래픽은 계속 프라이빗 릴레이를 사용합니다.
• Apple의 예상 대응: E2EE 핸드셰이크를 IP 마스킹과 호환되도록 재구축하는 26.5.1 포인트 릴리스는 핸드셰이크 수준의 회귀에 대한 Apple의 최근 주기를 기반으로 5월 중순에서 6월 초 기간 내에 실현 가능합니다.
• 수정 확인 방법: Mac에서 알려진 RCS 연락처에 테스트 메시지를 보내면, 빨간 오류 대신 말풍선 아래 "전달됨"(그리고 상대방의 다음 답장 시 입력 표시기)이 표시되어야 합니다.

정확한 증상: 실제로 보고 있는 것

실패 모드에 대해 정확히 설명하겠습니다. 표면적으로는 비슷해 보이지만 이 버그와는 전혀 관련이 없는 경우가 최소 네 가지 있기 때문입니다.

Mac(또는 iPad, Apple Watch)의 메시지 앱에서 Android 기기 사용자인 연락처에게 메시지를 작성하면, 메시지 말풍선이 RCS 스타일의 녹색으로 나타납니다——iMessage 스타일의 파란색도, SMS/MMS의 구형 연한 녹색도 아닙니다. 전송을 누릅니다. 메시지가 스레드 위쪽으로 애니메이션됩니다. 그리고 1~3초 이내에 말풍선 옆에 느낌표가 있는 작은 빨간 원이 나타나고, 말풍선 아래 작은 빨간 텍스트로 "전달되지 않음" 또는 "메시지 전송 실패"가 표시됩니다. 빨간 느낌표를 탭하면 표준 "다시 시도" 또는 "문자 메시지로 보내기" 프롬프트가 표시됩니다. "문자 메시지로 보내기"를 선택하면 SMS를 통해 메시지가 전송됩니다——하지만 암호화, 읽음 확인, 입력 표시기, 고해상도 미디어, 그리고 RCS를 사용할 가치가 있게 만든 모든 것을 잃게 됩니다.

이것이 다른 Continuity 문제가 아닌 이 특정 회귀임을 확인하는 핵심이 있습니다. iPhone을 꺼내 메시지 앱을 열고, 같은 스레드를 찾아 같은 텍스트를 입력하고 전송을 누릅니다. 즉시 전송되어 "전달됨"이 표시되고, 전송 내내 작성기 하단에 RCS 레이블이 표시됩니다. 같은 Apple ID, 같은 iPhone, 같은 통신사 연결——하지만 Mac에서 실패한 메시지가 iPhone에서는 성공합니다. 이 비대칭이 macOS 26.5 RCS 핸드셰이크 회귀의 지문입니다. 네트워크 문제가 아니고(전화기가 같은 네트워크 또는 최소한 같은 통신사에 있습니다), 계정 문제도 아니며(두 기기에서 같은 사용자입니다), 연락처 문제도 아닙니다(수신자 번호는 전화기에서 전화할 때 완벽하게 작동합니다).

iPhone 자체에서도 메시지 전송이 실패하는 증상이 있다면, 그것은 다른 문제——아마도 통신사 프로비저닝 문제나 iMessage 활성화 문제——이며, 이 가이드로는 해결되지 않습니다. Mac에서 iMessage(파란 말풍선, Apple 간)도 실패한다면, 그것은 RCS 문제가 아닌 Continuity 인증 문제입니다. Android 친구들에게 보내는 메시지가 이미 26.5 업데이트 전부터 실패하고 있었다면, 그것도 여기서는 범위 밖입니다. 우리가 다루는 정확한 회귀는 macOS 26.5 + iOS 26.5, RCS 말풍선(녹색, iPhone에서 "RCS" 레이블 표시), 보조 기기에서 전송 실패, iPhone에서 직접 전송 성공입니다.

macOS에서 RCS가 작동하는 방식: Continuity 브리지

이 특정 토글이 특정 문제를 해결하는 이유를 이해하려면, RCS 메시지가 Mac에 어떻게 도달하는지에 대한 기본적인 정신 모델이 필요합니다. iMessage와 달리——iMessage는 자체 네이티브 프로토콜과 Apple의 자체 서버를 가지고 각 Apple 기기에서 직접 Apple의 iMessage 인프라에 연결합니다——Apple 기기의 RCS는 전화기가 기반인 프로토콜입니다. 통신사 관점에서 iPhone이 RCS 엔드포인트입니다. 통신사는 전화번호에 RCS가 프로비저닝된 하나의 기기(iPhone)만 알고 있습니다. Mac, iPad, Apple Watch에는 RCS가 전혀 프로비저닝되지 않았습니다——통신사는 그것들이 존재한다는 것조차 모릅니다.

macOS가 하는 것은 SMS/MMS 전달을 처리하는 것과 같은 Continuity 브리지를 통해 RCS 메시지를 라우팅하는 것입니다. Mac에서 메시지를 입력하고 전송을 누르면, 메시지 앱이 통신사에 직접 연락하지 않습니다. 대신 메시지를 패키징하고, Continuity 전송을 위해 암호화하여 Apple의 Continuity 인프라("문자 메시지 전달", iPhone 전화 릴레이, Handoff를 처리하는 것과 같은 채널)를 통해 iPhone으로 보냅니다. iPhone은 패키지를 수신하고 이것을 발신 RCS 메시지로 인식하여, iPhone의 RCS 자격 증명을 사용해 통신사의 RCS 서버를 통해 전송하기 위해 자체 셀룰러 라디오에 전달합니다.

이것이 Mac에서 RCS를 사용하려면 항상 필요한 것들인 이유입니다: (1) iPhone이 같은 Apple ID로 로그인되어 있을 것, (2) iPhone 설정 → 메시지 → 문자 메시지 전달에서 Mac에 대한 문자 메시지 전달이 활성화되어 있을 것, (3) iPhone이 켜져 있고 네트워크에서 연결 가능할 것. 이 세 가지 중 하나라도 없으면 Mac의 RCS가 작동하지 않습니다. Mac을 작성할 수 있게 해주는 얇은 클라이언트로 생각할 수 있지만, 실제 전송은 항상 iPhone에서 이루어집니다——Mac은 본질적으로 iMessage가 아닌 모든 트래픽에 대해 iPhone을 원격 모뎀으로 사용하고 있는 것입니다.

iOS 26.5와 미국 Apple 기기에서의 E2EE RCS 도입 이전에는, 이 브리지가 SMS, MMS, 비암호화 RCS에서 잘 작동했습니다. Continuity 패키지는 상당히 단순한 구조——발신자, 수신자, 본문, 메타데이터——였고, iPhone은 추가 처리를 거의 하지 않고도 통신사의 RCS 서버에 전달할 수 있었습니다. Mac과 iPhone 사이의 핸드셰이크는 Apple의 표준 Continuity 전송을 통해 이루어졌으며, 그 자체로 암호화되어 있지만 셀룰러 계층에 제약을 가하지는 않았습니다.

26.5에서 망가진 이유: E2EE RCS 핸드셰이크

여기서 26.5가 근본적인 것을 변경했습니다. iOS 26.5 및 macOS 26.5 릴리스부터, Apple은 GSMA의 E2EE RCS 사양(MLS — Messaging Layer Security를 사용하는 Universal Profile 3.0)을 지원하는 통신사에 대해 E2EE RCS 출시를 시작했습니다. T-Mobile US는 해당 릴리스에서 Apple 기기에 E2EE RCS를 완전히 활성화한 세계 최초의 주요 통신사 중 하나였으며, Verizon과 AT&T는 그 이후 지역별로 활성화하고 있습니다. Apple 지원 문서 HT127115(26.5 릴리스 노트)의 보안 업데이트 섹션에는 "지원되는 통신사의 RCS에 대한 E2EE 메시지 지원"을 언급하는 한 줄이 포함되어 있으며——핸드셰이크 아키텍처에 대한 추가 세부 정보는 없습니다.

E2EE RCS 핸드셰이크는 비암호화 버전보다 훨씬 복잡합니다. 메시지 본문을 E2E 암호화하는 키(Apple도 통신사도 읽을 수 없도록)를 협상하기 위해, 발신자의 기기와 수신자의 기기는 전용 핸드셰이크 서버를 통해 MLS 기반 키 자료를 교환합니다. iPhone이 직접 RCS를 보내는 경우, 이 핸드셰이크는 iPhone과 통신사의 MLS 핸드셰이크 엔드포인트 사이에서 이루어지며, Apple은 등록 계층에 위치합니다. 그러나 Continuity를 통해 RCS를 보내는 Mac의 경우, Apple은 릴레이 단계를 도입했습니다: Mac이 MLS 핸드셰이크 자료를 생성하고 패키징하여 Continuity 브리지를 통해 iPhone으로 보내고, iPhone은 이것을 Apple 릴레이 엔드포인트로 전달하며, 릴레이는 이것을 통신사의 핸드셰이크 서버로 전달합니다. 릴레이 단계는 26.5의 새로운 기능이며, iPhone이 일시적으로 오프라인이거나 저전력 상태일 수 있는 경우를 처리하는 깔끔한 방법을 Apple에게 제공합니다——릴레이는 핸드셰이크 자료를 잠시 버퍼링할 수 있습니다.

문제는 이 Apple 릴레이 엔드포인트가 iPhone의 셀룰러 인터페이스를 통해 연결된다는 것입니다. iOS 14부터 Apple은 "IP 주소 추적 제한"이라는 프라이버시 기능을 추가했습니다——iPhone이 셀룰러를 사용할 때 알려진 추적자로부터 IP 주소를 숨기는 회선별 셀룰러 설정입니다. 이것은 iCloud 프라이빗 릴레이와 유사한 Apple이 운영하는 프록시를 통해 특정 트래픽을 라우팅함으로써 작동합니다. SMS, MMS, 일반 웹 브라우징, 그리고 26.5 이전의 RCS에서는 이 프록시가 투명하게 작동하여 아무도 눈치채지 못했습니다. 하지만 새로운 E2EE RCS 핸드셰이크는 이전 프로토콜에는 없었던 방식으로 IP 계층에 민감합니다——구체적으로, 릴레이 엔드포인트의 인증이 연결 수준의 속성을 사용하며, 트래픽이 Apple의 IP 마스킹 인프라를 통해 프록시될 때 이 속성이 변경됩니다. 핸드셰이크가 릴레이의 인증 검사에서 조용히 실패하고, 메시지는 암호화할 키를 결코 받지 못하므로, iPhone은 Continuity 브리지를 통해 Mac에 일반적인 "전송 실패"를 반환합니다.

Mac에서 보면 실패는 불투명합니다: 빨간 느낌표, 유용한 오류 메시지 없음. iPhone 관점에서는 핸드셰이크가 실패했다는 것을 알지만, iPhone이 전송을 시작한 기기가 아니기 때문에 사용자에게 표시하지 않습니다. 그리고 통신사 관점에서는 메시지가 전혀 전송되지 않았으며——실패는 통신사의 RCS 서버보다 완전히 상류에서 발생합니다.

이것은 또한 iPhone에서 직접 같은 메시지를 보내면 잘 작동하는 이유를 설명합니다: iPhone이 메시지를 직접 작성할 때, 릴레이를 통하지 않는 다른 핸드셰이크 경로를 사용합니다(iPhone은 이미 통신사가 프로비저닝한 RCS 엔드포인트이므로, Apple 릴레이 없이 직접 통신사와 키를 협상합니다). "IP 주소 추적 제한" 프라이버시 프록시는 iPhone 직접 경로를 망가트리지 않는데, 통신사의 RCS 핸드셰이크 서버가 프록시된 연결을 허용하는 다른 인증 모델을 사용하기 때문입니다.

수정 방법: 숨겨진 셀룰러 토글

정확한 경로를 안내합니다. 비슷한 이름의 설정이 여러 개 있고 그 중 하나만 올바른 것이기 때문에 주의 깊게 읽어주십시오.

1. iPhone에서(Mac이 아닙니다——실패는 iPhone이 Apple 릴레이에 연결하기 위해 사용하는 셀룰러 인터페이스에서 발생하므로, 이것은 iPhone 측 설정입니다) 설정 앱을 엽니다.

2. 셀룰러를 탭합니다(듀얼 SIM 폰에서는 지역에 따라 "셀룰러" 또는 "모바일 데이터"로 표시될 수 있습니다).

3. "SIM" 섹션 아래에서 RCS 메시지를 처리하는 특정 회선을 탭합니다. SIM이 하나뿐이라면 항목이 하나뿐입니다——그것을 탭합니다. SIM이 두 개인 경우(물리 SIM과 eSIM, 또는 두 개의 eSIM), iMessage와 전화번호의 기본 회선으로 설정된 것을 탭합니다. 설정 → 메시지 → iMessage와 FaceTime으로 돌아가서 iMessage의 기본으로 어떤 전화번호가 나열되어 있는지 확인하여 올바른 회선인지 확인할 수 있습니다——그것이 RCS 설정이 중요한 회선입니다.

4. 회선 세부 화면에서 셀룰러 데이터 옵션을 탭합니다(이전 iOS 빌드에서는 "데이터 모드"로 표시될 수 있지만——26.5에서는 "셀룰러 데이터 옵션"입니다).

5. IP 주소 추적 제한이라는 레이블이 있는 토글과 아래에 간략한 설명이 표시됩니다: "메일과 Safari에서 알려진 추적자로부터 IP 주소를 숨겨 IP 주소 추적을 줄입니다." 이것을 끄기로 설정합니다.

6. 설정에서 완전히 나옵니다(위로 스와이프하여 닫거나 홈 표시기/버튼을 누릅니다).

7. Mac을 들고 메시지 앱을 열어 실패하던 스레드를 찾아 테스트 메시지를 보냅니다. 1~2초 이내에 말풍선 아래 "전달됨"이 표시되어야 하며, 빨간 느낌표가 다시 나타나지 않아야 합니다.

이것이 수정 방법입니다. iPhone의 올바른 SIM에서 토글 하나를 바꾸는 것입니다. 변경은 즉시 적용됩니다——어떤 기기도 재시작할 필요 없고, 어디에서도 로그아웃할 필요 없으며, 전파 기간을 기다릴 필요도 없습니다.

듀얼 SIM 참고 사항

SIM이 두 개이고 어느 것이 RCS를 처리하는지 확실하지 않은 경우, 규칙은 다음과 같습니다: iPhone의 RCS는 현재 iMessage 회선으로 설정된 회선에 연결되어 있습니다(설정 → 메시지 → iMessage와 FaceTime → 기본 번호). 또한 설정 → 앱 → 메시지 → RCS 메시지(또는 약간 더 오래된 빌드에서는 설정 → 메시지 → RCS 메시지)에서 RCS 메시지가 활성화된 회선에도 연결되어 있습니다——듀얼 SIM 폰에서는 회선별 토글이 표시됩니다. RCS 토글이 켜져 있고 iMessage 기본 번호와 일치하는 회선이 "IP 주소 추적 제한"을 꺼야 하는 회선입니다.

두 SIM 모두 RCS가 활성화된 경우(메시지에 두 개 모두 사용하는 경우 드물지만 가능), 두 개 모두에 대해 IP 주소 추적 제한을 끕니다. 데이터 전용 또는 핫스팟 SIM에는 켜둔 상태로 둘 수 있습니다.

솔직한 프라이버시 트레이드오프

이 토글을 바꿀 때 실제로 무엇을 포기하는지 알아야 합니다. 온라인의 일부 논의에서는 이 점이 모호하게 다루어졌지만 실제 답변을 받을 자격이 있습니다.

셀룰러 회선에서 "IP 주소 추적 제한"이 켜진 경우, iPhone은 셀룰러 트래픽의 일부——구체적으로 메일과 Safari의 알려진 추적자에 대한 트래픽, 그리고 Apple의 추적자 목록과 일치하는 특정 도메인에 대한 트래픽——를 Apple이 운영하는 프록시를 통해 라우팅하여 해당 목적지에서 실제 IP를 숨깁니다. 이것은 iCloud 프라이빗 릴레이가 하는 것의 하위 집합입니다(프라이빗 릴레이는 더 광범위하고 더 많은 트래픽을 커버하지만 iCloud+ 구독이 필요합니다). 셀룰러 수준의 토글은 iCloud+ 구독자만이 아닌 모든 사람에게 작동하며, 여러 iOS 버전에서 기본으로 켜져 있었습니다.

끄면, 해당 회선의 프록시가 우회됩니다. iPhone이 셀룰러를 통해 통신하는 추적자들(Safari 페이지에 내장된 분석 엔드포인트, 메일 추적 픽셀, 일부 앱 원격 측정)이 실제 셀룰러 IP 주소를 볼 수 있습니다. 통신사도 트래픽 패턴을 약간 더 명확하게 파악할 수 있지만, 통신사는 이 토글에 관계없이 이미 네트워크 계층에서 모든 셀룰러 트래픽을 볼 수 있습니다.

변경되지 않는 것들:

• iMessage: Apple의 iMessage 트래픽은 셀룰러 추적자 프록시를 전혀 사용하지 않습니다——iMessage는 자체 E2E 암호화와 자체 인프라 라우팅을 가지고 있습니다. IP 주소 추적 제한을 끄는 것은 iMessage에 아무런 영향이 없습니다.
• FaceTime: iMessage와 동일——별도의 라우팅, 영향 없음.
• iCloud 프라이빗 릴레이: iCloud+와 프라이빗 릴레이가 활성화된 경우, Safari 브라우징은 여전히 프라이빗 릴레이의 2홉 아키텍처를 통합니다. IP 주소 추적 제한은 별도의, 더 좁은 기능입니다.
• VPN 트래픽: VPN을 통해 라우팅한 모든 것은 영향을 받지 않습니다——VPN 트래픽은 IP 주소 추적 제한과 프라이빗 릴레이 모두를 우회합니다.
• 앱별 프라이버시 설정: 각 앱의 권한(위치, 연락처 등)은 영향을 받지 않습니다.

따라서 트레이드오프는 다음과 같습니다: Mac에서 RCS를 보내는 능력을 위해 셀룰러 회선에서 웹 추적자와 메일 추적자에 대한 IP 주소의 약간 더 넓은 노출입니다. 대부분의 사람에게 그것은 합리적인 거래입니다——특히 iCloud+ 프라이빗 릴레이가 이미 Safari를 커버하고 있다면 더욱 그렇습니다. 셀룰러에서의 IP 수준의 프라이버시가 중요한 상황(민감한 지역의 저널리스트, 활동가 등)에 있다면, 이것이 허용 가능한 트레이드오프가 아닐 수 있으며 아래의 대안적 수정 방법 중 하나를 사용하거나 Apple이 26.5.1을 출시할 때까지 iPhone에서 직접 RCS를 보내야 할 수 있습니다.

주요 토글이 작동하지 않을 경우의 대안적 수정 방법

IP 추적 토글은 T-Mobile, Verizon, AT&T의 대부분의 사용자 문제를 해결합니다. 하지만 소수의 경우——특히 지역 통신사 사용자, 비정상적인 iMessage 계정 상태의 사용자, 또는 Continuity 브리지가 이전에 잘못 설정된 사용자——는 토글을 끈 후에도 여전히 실패를 볼 수 있습니다. 제가 시도하는 순서로 추가 수정 방법을 제시합니다.

1. iPhone에서 iMessage 로그아웃 후 재로그인

RCS 브리지는 Apple이 완전히 문서화하지 않은 방식으로 iMessage 활성화 토큰에 의존합니다. iMessage가 이상한 상태가 되면, RCS도 종종 따라갑니다. iPhone에서: 설정 → 앱 → 메시지 → iMessage와 FaceTime → iMessage를 끄고, 정확히 30초(길수록 좋습니다——가능하다면 1분을 기다리세요)를 기다린 후 다시 켭니다. 전화번호를 다시 확인하라는 메시지가 표시될 수 있으며, 이것은 정상입니다. "다음에서 메시지를 받을 수 있습니다" 아래 전화번호 옆에 녹색 체크 표시가 표시되면, Mac에서 다시 보내기를 시도합니다.

2. Mac의 문자 메시지 전달 비활성화 후 재활성화

Mac의 Continuity 문자 전달 항목이 오래될 수 있습니다. iPhone에서: 설정 → 메시지 → 문자 메시지 전달. 목록에서 Mac을 찾아 끕니다. 15초를 기다립니다. 다시 켭니다——그러면 Mac에 6자리 코드가 표시되며, 이것을 iPhone에 입력하여 전달 링크를 다시 페어링합니다. 재페어링 후, Mac에서 테스트 메시지를 보냅니다.

3. 통신사 메뉴에서 RCS 재시작

RCS 자체를 iPhone에서 토글할 수 있으며, 이 토글은 통신사에 강제로 재등록합니다. iPhone에서: 설정 → 앱 → 메시지 → RCS 메시지 → 끄고, 상태가 "사용할 수 없음" 또는 유사한 상태로 떨어질 때까지 기다린 후(30-60초 걸릴 수 있습니다), 다시 켭니다. "등록 중"을 거쳐 "준비됨" 또는 "사용 가능"에 정착하는 것이 보일 것입니다. 이것은 iMessage에서 로그아웃하는 것보다 더 무거우므로 그 단계 후에 시도해야 합니다.

4. iPhone에서 네트워크 설정 재설정

이것은 더 파괴적입니다——저장된 Wi-Fi 암호와 VPN 설정이 지워집니다——하지만 멈춰있는 Continuity 관련 네트워크 상태를 지울 수 있습니다. 설정 → 일반 → iPhone 전송 또는 재설정 → 재설정 → 네트워크 설정 재설정. 전화기가 재시작됩니다. Wi-Fi 네트워크에 다시 연결해야 합니다. 돌아오면 Mac에서 테스트를 보냅니다.

5. 순서대로 두 기기 재시작

놀랍게도 많은 Continuity 문제가 순서가 지정된 재시작으로 해결됩니다: 먼저 Mac 전원을 끄고, 그 다음 iPhone 전원을 끄고, 그 다음 iPhone 전원을 켜서 셀룰러와 Wi-Fi에 완전히 연결될 때까지 기다리고(2분을 주세요), 그런 다음 Mac 전원을 켭니다. Mac은 iPhone에서 보이는 것을 기반으로 Continuity 링크를 다시 설정하기 때문에 순서가 중요하므로, iPhone이 먼저 완전히 온라인 상태여야 합니다.

6. 최후의 수단: 해당 연락처에 MMS로 전환

다른 방법이 작동하지 않고 보내야 할 긴급 메시지가 있는 경우, 특정 연락처 스레드에 대해 RCS를 비활성화할 수 있습니다——iPhone의 스레드 상단에서 연락처 이름을 길게 누르고, "문자 메시지로 보내기"를 탭하면 스레드가 MMS로 폴백합니다. 품질이 떨어지지만(고해상도 미디어 없음, 읽음 확인 없음, 문자 제한), 메시지가 Mac에서 안정적으로 전송되는데, MMS는 새로운 E2EE 핸드셰이크를 사용하지 않기 때문입니다.

RCS와 SMS 중 어느 것이 실패하는지 확인하는 방법

세 가지 빠른 시각적 확인으로 어떤 프로토콜이 사용 중인지 알 수 있습니다:

• 말풍선 색상: 녹색 RCS 말풍선은 녹색 SMS/MMS 말풍선보다 약간 더 어둡습니다. 음영 차이는 미묘하지만 일관됩니다——RCS 말풍선은 또한 순수 SMS 말풍선에는 없는 약간의 그라데이션이 있습니다. 말풍선을 길게 눌러 "정보"를 선택하면, 메시지 메타데이터에 "RCS" 또는 "SMS"가 명시적으로 표시됩니다.
• 작성기 레이블: iPhone의 텍스트 입력 필드 하단에 "RCS", "iMessage", "SMS/MMS", 또는 "문자 메시지"라고 적힌 작은 레이블이 표시됩니다. Mac에서는 이 레이블이 메시지 필드를 탭할 때 작성기 푸터에 나타납니다. 전송을 누르기 전에 레이블이 "RCS"라고 표시되는데도 전송 실패가 발생하면, 이 글에서 다루는 회귀를 경험하고 있는 것입니다.
• 암호화 표시기: E2EE RCS의 경우, iPhone 작성기의 RCS 레이블 옆에 작은 자물쇠 아이콘이 표시됩니다. 자물쇠는 핸드셰이크가 성공적으로 완료되어 메시지가 E2EE될 것임을 나타냅니다. 자물쇠가 없지만 RCS 레이블이 있으면, 핸드셰이크가 실패하여 메시지가 암호화되지 않고 전송될 것입니다(26.5 이후 T-Mobile US에서는 통신사가 E2EE를 강제하기 위해 암호화되지 않은 RCS를 거부합니다——이것이 실패를 복합시킵니다).

"RCS"가 전혀 표시되지 않고 "SMS/MMS" 또는 "문자 메시지"만 표시된다면, 이 글은 귀하의 상황에 적용되지 않습니다——연락처의 기기가 RCS를 지원하지 않거나, 회선에서 RCS가 활성화되지 않은 것으로, 이것은 별도의 문제 해결이 필요합니다.

통신사별 참고 사항

T-Mobile US

T-Mobile US는 Apple 기기에서 E2EE RCS 출시에 가장 적극적인 통신사이며, 그 결과 T-Mobile 고객들이 26.5 업데이트 후 가장 높은 실패율을 보고하고 있습니다. T-Mobile 커뮤니티 포럼과 지원 스레드는 5월 11일 이후 활발하며, 많은 사용자들이 처음에는 계정을 탓하거나 SIM 문제라고 가정했다가 IP 추적 수정을 발견했습니다. T-Mobile의 RCS 인프라는 어떤 RCS 메시지가 전송되기 전에 E2EE 핸드셰이크가 완료될 것을 요구합니다——비암호화 RCS로 우아하게 폴백하지 않습니다——즉, 핸드셰이크 실패가 부분적이 아닌 전체적입니다. T-Mobile에 있고 주요 토글이 해결되지 않는다면, 통신사 측 3단계(RCS 끄기 및 켜기)가 다른 통신사보다 도움이 될 가능성이 더 높습니다. T-Mobile의 MLS 등록은 등록 시 기기의 네트워크 상태에 민감하기 때문입니다.

Verizon

Verizon의 E2EE RCS 출시는 지역적이고 T-Mobile보다 덜 완성적입니다. 일부 Verizon 고객은 실패를 경험하고 있으며, 다른 고객은 같은 iOS 및 macOS 빌드에서도 경험하지 않고 있는데, 이는 셀 타워 지역이 아직 E2EE RCS를 활성화하지 않았기 때문입니다. Verizon에 있고 실패를 경험하지 않는다면, 지금은 IP 주소 추적 제한을 켜둔 상태로 둘 수 있습니다——해당 지역의 RCS가 아직 새 핸드셰이크를 사용하지 않습니다. 실패를 경험한다면, IP 추적 토글이 T-Mobile 사용자와 같은 방식으로 수정합니다.

AT&T

AT&T는 출시 곡선에서 T-Mobile과 Verizon 사이 어딘가에 있습니다. AT&T에서의 실패 보고는 실제이지만 덜 일반적이며, AT&T의 RCS 경로는 T-Mobile보다 더 많은 경우에 조용히 MMS로 폴백하는데, 이것이 때로는 근본적인 문제를 가립니다(메시지가 전송되지만 RCS 대신 MMS로). AT&T에서 Mac의 RCS 메시지가 성공하는 것처럼 보이지만 RCS 말풍선 대신 SMS/MMS 말풍선으로 표시된다면, 실패를 경험하지만 보이는 오류 대신 보이지 않는 폴백을 받고 있을 수 있습니다.

Google Fi

iPhone을 사용하는 Google Fi 고객들은 이 회귀에 대해 거의 문제를 보고하지 않습니다. Fi의 RCS 경로는 GSMA Universal Profile 3.0 E2EE 사양이 대상으로 하는 통신사 직접 경로가 아닌 Google의 RCS 서버(Jibe Mobile)를 사용하므로, Fi 메시지는 새 Apple 릴레이를 통과하지 않습니다. Fi는 Apple보다 앞서는 자체 E2EE 구현을 가지고 있으며, iPhones-on-Fi와 Apple의 Continuity 사이의 브리지는 다른 코드 경로를 통해 작동합니다. Fi에 있고 Mac에서 RCS 실패를 경험한다면, 그것은 거의 확실히 다른 문제——아마도 계정 관련——이며, 이 글은 도움이 되지 않습니다.

국제 통신사

미국 이외에서는 Apple 기기에서의 E2EE RCS 출시가 산발적입니다. 주요 유럽, 영국, 호주 통신사들은 2025년과 2026년 초 동안 특정 회선에서 이것을 활성화하고 있었지만, 대부분의 국제 통신사의 대부분의 고객들은 여전히 비암호화 RCS를 사용하고 있으며, 이것은 구 핸드셰이크를 사용하고 회귀의 영향을 받지 않습니다. 미국 이외에서 실패를 경험한다면, 통신사 지원에 연락하여 회선에서 E2EE RCS를 활성화했는지 확인하십시오. 그렇다면 IP 추적 수정이 적용됩니다. 그렇지 않다면, 이것은 아마도 다른 문제입니다.

Apple이 할 것으로 예상되는 것(그리고 언제)

핸드셰이크 수준의 회귀에 대한 Apple의 최근 실적——iOS 17.4 iMessage 전달 버그, iOS 18.2 FaceTime 인증 회귀, macOS Sequoia 15.1 AirDrop Continuity 중단, macOS 26.4 iPhone 미러링 중단——을 기반으로, 수정에 대한 현실적인 기대는 5월 중순에서 6월 초 기간 내의 26.5.1 포인트 릴리스입니다. Apple은 일반적으로 명확하게 식별된 회귀가 있고 사용자에게 영향을 미치는 가시적인 실패 모드가 있을 경우 .x 릴리스 후 10~21일 이내에 .x.1 패치를 출시하며, RCS 핸드셰이크 문제는 그 기준을 쉽게 충족합니다.

Apple 측의 수정은 IP 마스킹된 연결을 허용하도록 릴레이 측 인증을 재구축할 가능성이 가장 높습니다. 이를 달성하는 몇 가지 방법이 있습니다: (a) iCloud 트래픽이 이미 프라이빗 릴레이에서 면제된 것과 유사하게 RCS 릴레이 엔드포인트에 대한 연결에만 IP 추적 프록시를 우회; (b) 릴레이의 인증 모델을 연결 수준의 속성에서 기기 수준의 증명으로 변경; 또는 (c) Continuity 브리지 케이스에 대한 릴레이 단계를 완전히 제거하고 Mac의 핸드셰이크 자료가 iPhone의 통신사 직접 경로를 통해 직접 가도록 하는 방법. 옵션 (a)가 가장 쉽고 가능성이 높으며; (c)는 아키텍처적으로 가장 깔끔하지만 더 많은 테스트가 필요합니다.

그 동안에는 두 가지 경로가 있습니다: 영향을 받는 SIM에 대해 IP 주소 추적 제한을 끄고 프라이버시 트레이드오프를 수용하거나, 26.5.1이 출시될 때까지 iPhone에서 직접 RCS 메시지를 보내는 것입니다. Apple 지원 팀은(2026년 5월 15일 현재) 직접 지원 연락에 대한 표준적인 "인지하고 있으며 조사 중"이라는 응답 이외에 이 회귀에 대한 공개 인정을 발표하지 않았습니다. 다음 포인트 릴리스의 일반적인 명명 규칙인 HT127116에 대한 Apple 지원 릴리스 노트 페이지를 앞으로 몇 주 동안 주목하십시오.

26.5.1이 6월 초까지 출시되지 않으면, 가장 가능성이 높은 이유는 Apple이 핸드셰이크 아키텍처를 더 깊이 재구축하고 있는 것입니다(위의 옵션 c)——그것은 테스트하는 데 더 오래 걸립니다. 그 경우, 6월 말이나 7월 초에 26.5.1을 예상하고, 그때까지 IP 추적 트레이드오프를 유지할 가치가 있는지 고려하십시오. T-Mobile, Verizon, 또는 AT&T의 대부분의 사용자에게는 그 가치가 있습니다——프라이버시 노출은 적당하고 메시지 편의성은 중요합니다.

버그가 다른 Continuity 문제와 결합될 때

소수이지만 실제로 기존 Continuity 문제 위에 이 RCS 회귀를 경험하는 사용자들이 있으며, 겹쳐진 증상이 진단을 더 어렵게 만듭니다. 같은 Mac에서 iPhone 미러링 문제를 이미 경험하고 있다면, 그것은 macOS 26.4의 별도 회귀이며 macOS Tahoe 26.4에서 iPhone 미러링이 작동하지 않는 경우 수정 가이드에서 자세히 다루었습니다——미러링을 수정하면 RCS에 영향을 미칠 수도 있고 그렇지 않을 수도 있으며, 그 반대도 마찬가지이지만 독립적인 수정이 있는 독립적인 문제입니다. 마찬가지로, Mac과 iPhone 사이의 AirDrop이 불안정하다면, Mac에서 AirDrop이 작동하지 않는 경우 수정 가이드에서 다루고 있으며, AirDrop을 해결한다고 자동으로 RCS가 해결되지는 않습니다.

메시지 인접 문제 해결의 더 넓은 시각을 위해(메시지, 메일, 그리고 다양한 Apple ID 인증 문제 사이의 경계는 흐릿할 수 있습니다), Mac 메일이 작동하지 않는 경우 완전한 문제 해결 수정 가이드는 메시지 실패에서도 나타나는 기본 Apple ID와 Continuity 인증 패턴 많은 부분을 다루고 있습니다.

26.4에서 26.5에 도달했고 두 릴리스 사이에서 무엇이 변경되었는지 완전히 확신하지 못했다면, macOS Tahoe 26.4 / 26.4.1 완전한 업데이트 가이드가 이전 릴리스 주기와 26.5에 들어올 때 이미 망가졌거나 수정된 것을 요약합니다.

자주 묻는 질문

Q: "IP 주소 추적 제한"을 끄면 iMessage가 노출됩니까?

A: 아니요. iMessage는 IP 추적 프록시를 전혀 사용하지 않습니다——자체 E2E 암호화와 자체 인프라 라우팅을 가지고 있습니다. 이 설정은 Safari와 메일의 알려진 추적자에 대한 셀룰러 웹 트래픽에만 영향을 미칩니다. iMessage 내용, 연락처 목록, 메시지 메타데이터는 영향을 받지 않습니다.

Q: Mac, iPad, Apple Watch에서도 이 설정을 꺼야 합니까?

A: 아니요. "IP 주소 추적 제한"은 iPhone 전용 설정입니다(통상적인 의미에서 iPhone만 가지고 있는 셀룰러 인터페이스에 특화된 것입니다). 실패는 iPhone이 Apple 릴레이에 연결하려 할 때 셀룰러 계층에서 발생하므로, 수정은 iPhone에서만 이루어집니다. iPhone에서 꺼지면, 세 개의 보조 기기(Mac, iPad, Watch) 모두 다시 Continuity 브리지를 통해 RCS를 보낼 수 있게 됩니다.

Q: iPhone은 Wi-Fi에 있고 셀룰러 데이터를 사용하고 있지 않습니다——셀룰러 설정이 왜 중요합니까?

A: 릴레이 엔드포인트는 일반 브라우징에 셀룰러 데이터를 사용하고 있는지 여부에 관계없이 셀룰러 인터페이스를 통해 도달됩니다. iPhone의 셀룰러 라디오는 Wi-Fi가 아닌 통신사가 프로비저닝한 데이터 채널에서 RCS 핸드셰이크 트래픽을 처리합니다. RCS는 통신사의 RCS 서버에 등록해야 하는 통신사 기반 프로토콜이기 때문입니다. 따라서 집 Wi-Fi에 앉아 있더라도, 릴레이 핸드셰이크는 셀룰러 경로를 통해 이루어지며, 해당 회선의 IP 추적 설정이 적용됩니다.

Q: 설정을 껐는데도 여전히 작동하지 않습니다. 이제 어떻게 해야 합니까?

A: 대안적 수정 방법을 순서대로 시도하십시오: (1) iPhone에서 iMessage 로그아웃 후 재로그인, (2) Mac의 문자 메시지 전달 비활성화 후 재활성화, (3) 통신사 메뉴에서 RCS 메시지 끄기 및 켜기, (4) iPhone에서 네트워크 설정 재설정, (5) 순서대로 두 기기 재시작. 이것들 중 아무것도 작동하지 않는다면, 아마도 다른 문제——통신사 측 문제——를 경험하고 있을 것이며, 가장 좋은 방법은 통신사의 RCS 지원 팀에 직접 연락하는 것입니다. T-Mobile은 특히 전용 RCS 지원 채널을 가지고 있습니다.

Q: 이것이 안전합니까? 제 계정에 실제로 문제가 있습니까?

A: 계정, 하드웨어, SIM, Apple ID, 또는 통신사 프로비저닝에 아무런 문제가 없습니다. 이것은 macOS/iOS 26.5에서 도입된 소프트웨어 회귀이며 최종적으로 Apple 업데이트에 의해 수정될 것입니다. IP 주소 추적 제한을 끄는 것은 Apple이 제공하는 문서화된 사용자 설정입니다——탈옥하거나 지원되지 않는 것을 하는 것이 아닙니다. 프라이버시 영향은 위의 트레이드오프 섹션에서 설명한 것처럼 실제이지만 적당합니다.

Q: 이것이 iPhone 없이 Apple Watch가 독립적으로 메시지를 보내는 능력에 영향을 미칩니까?

A: Apple Watch의 RCS는 Mac RCS와 같은 Continuity 브리지를 통해——iPhone을 통해 릴레이됩니다. 따라서 iPhone에 수정을 적용하면, Apple Watch도 다시 RCS 메시지를 보낼 수 있어야 합니다. Watch가 셀룰러 모델이고 iPhone에서 떨어져 있는 동안 메시지를 보내고 있다면(Watch 자체 셀룰러 플랜 사용), 상황이 더 복잡하며 통신사가 Watch 회선에 특별히 RCS를 프로비저닝했는지에 달려 있습니다——대부분의 통신사는 하지 않으므로, 대부분의 Watch는 셀룰러 모드에서도 SMS로 폴백합니다.

Q: 설정을 변경하는 대신 Apple이 26.5.1에서 수정하기를 기다려야 합니까?

A: Mac/iPad/Watch에서의 메시지 양이 적고 보내는 몇 안 되는 RCS 메시지를 위해 iPhone을 편안하게 집을 수 있다면, 그것은 합리적인 선택입니다. 대기 시간은 아마도 몇 주입니다. Mac에서 하루에 수십 개의 RCS 메시지를 보내고 불편함이 상당하다면, 지금 수정을 적용하고 26.5.1이 출시된 후 되돌리는 것이 더 실용적인 경로입니다.

결론

macOS 26.5 RCS 회귀는 Apple 생태계 버그 중에서도 증상이 극적이고 가시적이며(모든 메시지에 밝은 빨간 오류), 원인이 보이지 않고 아키텍처적이며(관련 없는 프라이버시 설정과의 릴레이 수준 인증 불일치), 수정이 오류를 표시하는 기기가 아닌 다른 기기의 4개 메뉴 수준 아래에 묻혀 있는 좌절스러운 종류입니다. 그것은 귀하의 잘못이 아니고, 귀하의 사용자 기술을 반영하는 것도 아닙니다. MacRumors 포럼 독자들조차——Apple 사용자 기반의 기술적으로 더 잘 아는 쪽으로 기울어집니다——"IP 주소 추적 제한" 해결책이 일관된 수정으로 부상하기 전에 이틀 가까이 집합적으로 무엇이 일어나고 있는지 리버스 엔지니어링하는 데 보냈습니다.

수정을 적용하고 Mac에서 RCS 메시지가 다시 흐르고 있다면, 작은 호의를 하십시오: 5월 말 또는 6월 초에 26.5.1에 대한 Apple의 릴리스 노트를 확인하는 알림을 설정하고, 출시되면 IP 주소 추적 제한을 다시 활성화합니다. 프라이버시 트레이드오프는 지금은 공정했지만, Apple이 적절한 수정을 출시하면 복원하는 것이 좋습니다. 26.5.1이 출시되어 설정을 다시 켜면 RCS가 다시 망가진다면, 그것은 Apple의 수정이 릴레이/프록시 상호작용을 완전히 해결하지 못했다는 것을 의미하며, 단순히 다시 끄고 다음 포인트 릴리스에서 다시 시도할 수 있습니다.

관련된 Continuity 문제 해결——iPhone 미러링, AirDrop, RCS 실패를 반영하는 메일 인증 패턴——을 위해, iPhone 미러링 수정 가이드, AirDrop 수정 가이드, Mac 메일 문제 해결 가이드, 그리고 macOS Tahoe 26.4 / 26.4.1 업데이트 가이드를 참조하십시오. Apple 지원 페이지 HT127115는 26.5 릴리스 노트를 문서화합니다(이 회귀를 직접 인정하지 않고). MacRumors 포럼 스레드 2482378는 다른 사용자의 경험을 따르고 Apple이 응답하면서의 업데이트를 원하는 경우 최고의 커뮤니티 기반 추적 스레드로 남아 있습니다.

Android 친구들에게 보내는 문자는 중요하며, 스레드의 녹색 말풍선이 스트레스의 원인이 되어서는 안 되고, 단순히 메시지를 보내기 위해 앞에 두 개의 기기를 두어서는 안 됩니다. iPhone의 올바른 SIM에서 토글 하나——그러면 실제로 타이핑하고 싶은 키보드로 돌아갈 수 있습니다.