Apple은 2026년 9월 9일, 첫 폴더블 아이폰인 아이폰 듀오를 발표했습니다. 사전예약은 10월 16일부터 시작되고 10월 23일 정식 출시되며, iOS 27.1을 탑재합니다. 이상한 점은 순서입니다. Apple은 같은 날 레이아웃 규칙 문서를 공개했지만, Duo 시뮬레이터가 포함된 SDK는 “9월 중 늦게” 나온다고 밝혔습니다. 문서는 이미 있는데 실물 기기는 아직 없는 지금이야말로, 여러분의 앱에 조용히 깨져버린 레이아웃 전제를 찾아낼 수 있는 시간입니다. 이커머스, 게임, 핀테크 등 다양한 업종의 국내 앱 개발팀에게도 이는 남의 이야기가 아닙니다.
이 글은 기기 자체에 대한 리뷰는 다루지 않습니다. 그런 글은 이미 수백 개가 나올 예정이니까요. 푸시 알림 자체는 시스템이 그려주므로 바꿀 것이 없습니다. 문제는 앱이 직접 그리는 모든 것, 즉 세션이 진행되는 도중에도 모양과 비율이 바뀌는 화면에서 살아남아야 하는 인앱 메시지, 리치 미디어, 푸시 권한 요청 화면, 로더입니다. Apple이 새 규칙을 마련한 대상도 바로 이 영역이고, 대부분의 팀이 그대로 지나칠 위험이 있는 부분도 여기입니다.
iOS 27이 폴더블 아이폰에서 실제로 바꾼 것
아이폰 듀오는 거의 동일한 화면 비율을 가진 2개의 디스플레이를 탑재합니다. 안쪽 디스플레이는 7.6인치로 아이폰 18 프로 맥스보다 화면 면적이 약 50% 더 넓고, 바깥쪽 디스플레이는 5.4인치로 아이폰 18 프로 화면 면적의 약 90% 수준입니다. 두 비율은 비슷하지만 완전히 같지는 않으므로, 특정 비율을 전제하기보다 사이즈 클래스를 기준으로 레이아웃을 설계해야 할 이유가 하나 더 늘어난 셈입니다.
모든 앱은 Split View에 참여하게 됩니다. Duo는 앱 UI의 여러 인스턴스를 동시에 실행하는 최초의 아이폰이며, 여러분의 인앱 메시지가 다른 앱과 화면을 절반씩 나눠 쓰게 될 수도 있다는 뜻입니다.
그리고 화면 형태는 세션 도중에도 바뀝니다. 모달이 떠 있는 상태에서 사용자가 기기를 펼치거나 반쯤 접을 수 있습니다. 레이아웃은 더 이상 실행 시점에 한 번 정하고 끝나는 것이 아닙니다.
3단계 호환성 수준과 대부분의 앱이 위치한 지점
Apple의 규칙은 명확합니다. 앱은 재컴파일 없이 Duo에서 실행됩니다. 문제는 화면을 얼마나 활용하느냐이며, 이는 어떤 SDK로 빌드했는지에 따라 달라집니다.
- 구버전 SDK: 실행은 되지만, 콘텐츠는 일반 폰 크기의 영역 안에 갇힙니다.
- iOS 27 SDK: 안쪽 디스플레이에서 UI가 상태 표시줄 영역 왼쪽까지 확장됩니다.
- iOS 27.1 SDK: UI가 화면 끝까지 도달하고, 기본 내비게이션과 툴바 버튼이 세로로 배치됩니다.
즉, 아무것도 하지 않은 팀은 7.6인치 화면에서 폰 크기의 박스 안에 인앱 메시지를 그대로 노출하게 됩니다. 깨지는 것은 아니지만, 손을 댄 경쟁사들 옆에서 눈에 띄게 방치된 모습으로 남습니다.
인앱 메시지 레이아웃이 작동하지 않게 되는 이유
이유는 3가지이며, 서로 겹쳐서 작용합니다.
화면 비율. 대부분의 인앱 및 리치 미디어 템플릿은 일반 아이폰의 비율에 맞춰 제작되었습니다. 안쪽 디스플레이의 비율은 이와 다르므로, 기존 비율로 만든 템플릿은 의도한 위치에 맞아떨어지지 않습니다.
방향(orientation)은 잘못된 신호입니다. 안쪽 디스플레이는 두 사이즈 클래스 모두에서 regular이며, 지원되는 인터페이스 방향을 따르지 않습니다. 방향을 기준으로 분기하는 레이아웃은 안쪽 디스플레이가 무시하는 신호를 읽고 있는 셈입니다. Apple의 지침도 명확합니다. 방향이 아니라 사이즈 클래스로 레이아웃을 결정하라는 것입니다.
세이프 에어리어는 비대칭입니다. Duo의 인셋과 레이아웃 여백은 양쪽이 서로 다른 경우가 많으므로, 대칭 프레임을 가정하지 말고 각 가장자리를 개별적으로 처리해야 합니다. 그런 다음 프레임이 다시 좁아지는 Split View에서도 테스트해야 합니다.
폰이 펼쳐질 때 열려 있는 인앱 메시지
이 케이스는 짚고 넘어갈 가치가 있습니다. 아직 어떤 시뮬레이터로도 지켜본 사람이 없기 때문입니다. 모달 형태의 인앱 메시지가 화면에 떠 있는 상태에서 사용자가 폰을 펼치는 경우, 이미 표시된 뷰 아래에서 프레임이 바뀝니다.
Apple은 여기서 2가지 도구를 제공하며, 이 둘을 혼동하는 것이 가장 흔한 실수입니다.
힌지 API인 SwiftUI의 onHingeChange와 UIKit의 UIHingeInteraction은 이산적 상태(닫힘, 부분적으로 열림, 완전히 열림)와 연속적인 각도를 알려줍니다. 이는 실시간으로 관찰하며 인터랙션과 이펙트를 구동하기 위한 것입니다. Apple의 자체 데모에서도 폴드 각도로 가상 악기의 음높이를 조절합니다. 버튼 위치를 옮기는 용도가 아니라, 바로 그런 용도를 위한 API입니다.
레이아웃은 다른 경로를 거칩니다. Apple은 “Strike a pose with adaptive layouts on iPhone Duo” 세션에서 소개한 배치(arrangement) 및 영역(region) API를 안내합니다. 여기에는 reserved region, split·overlay 레이아웃을 갖춘 arrangement view, 그리고 displacement(기기가 닫힐 때 실제로 사용 가능한 공간으로 기존 요소를 재배치해 콘텐츠가 계속 보이고 접근 가능하게 만드는 기능)가 포함됩니다. iOS 27.1에서는 SwiftUI에 ReservedRegion, UIKit에 UIViewReservedRegion이 추가되어, 커스텀 UI가 시스템 UI와 충돌하지 않고 필요한 공간을 확보할 수 있습니다. 이는 reservedRegions(kind:)로 조회하며, .division은 힌지 자체를, .occlusion은 카메라 영역을 가리킵니다.
모달의 경우 결론은 하나의 규칙으로 정리됩니다. 힌지 각도로 위치를 다시 잡으려 하지 마십시오. arrangement와 reserved region에 반응하도록 두면, 화면이 열렸을 때 콘텐츠가 사라진 프레임에 매달리는 대신 있어야 할 자리에 놓입니다.
Split View에서의 인앱 알림
이제 모든 앱이 멀티태스킹 풀에 속하게 되므로, 인앱 알림은 낯선 앱과 화면을 절반씩 나눠 쓰게 될 수 있습니다. 이는 안쪽 디스플레이 전체보다 훨씬 좁은 프레임이며, 바로 그렇기 때문에 절반 너비에서 테스트해야 합니다. 전체 화면에서는 문제없어 보이는 모달도 공간이 절반으로 줄면 잘리거나 답답해 보일 수 있습니다.
또 하나 알아둬야 할 확실한 제약이 있습니다. 바깥쪽 디스플레이에서는 새 창을 열 수 없으며, 이 영역은 안쪽 화면의 경험을 위해 예약되어 있습니다. 창을 생성하는 표시 로직이 있다면 이 점을 반드시 고려해야 합니다.
외부 디스플레이: 컴팩트 레이아웃과 위젯, 라이브 액티비티
바깥쪽 디스플레이는 일반적인 아이폰 화면과 동일하게 동작합니다. 앱은 그곳에서도 실행되며, 인앱 메시지를 포함해 앱이 그리는 모든 것이 표시됩니다. Apple은 바깥쪽 디스플레이를 일반 아이폰과 같은 compact-width 레이아웃으로, 안쪽 디스플레이는 두 방향 모두 regular로 규정합니다. 5.4인치인 바깥쪽 디스플레이는 이 기기에서 인앱 메시지가 가장 좁은 전체 화면 프레임을 갖는 곳이므로, “해당 없음” 목록이 아니라 테스트 매트릭스에 포함해야 합니다.
그 위에 또 하나의 표면이 있습니다. Duo에서는 충전 중이 아니어도 양쪽 디스플레이 모두에서 StandBy가 동작합니다. 폰을 내려놓으면 바깥쪽 화면이 켜진 채로 방을 비추게 됩니다. 위젯도 라이브 액티비티도 없는 앱은 이 순간에 그냥 존재하지 않는 셈입니다. 이 자리에서 존재감을 가지려면 위젯이나 라이브 액티비티가 필요하며, 이는 잠금 화면과 Dynamic Island를 위해 이미 해두었을 작업과 동일합니다. 라이브 액티비티를 이미 구축했다면 이곳이 그 투자가 다시 빛을 발하는 두 번째 지점이고, 아직 구축하지 않았다면 여기 또 하나의 이유가 생긴 셈입니다.
이커머스, 게임, 핀테크 앱이 이미 잠금 화면과 Dynamic Island를 위해 라이브 액티비티에 투자하고 있었다면, StandBy는 그 투자를 한 번 더 활용할 수 있는 기회입니다.
이전에 다룬 iOS 라이브 액티비티 글에서 기본기를 확인할 수 있고, iOS 27 스팸 방지 정책 글에서는 라이브 액티비티에 어떤 내용을 담을 수 있는지 다룹니다.
10월 23일 전에 준비할 폴더블 아이폰 호환성 체크리스트
기기는 아직 손에 넣을 수 없지만, 그 외의 모든 것은 지금 바로 처리할 수 있습니다.
- 인앱 및 리치 미디어 템플릿을 전수 조사하세요. 프레임, 화면 비율, 폰 크기 박스를 하드코딩한 템플릿을 모두 찾아냅니다.
- 16:9 크리에이티브를 점검하세요. 고정 비율로 제작된 콘텐츠는 안쪽 디스플레이를 위한 대응 방안이 필요합니다.
- 방향(orientation) 기준 분기를 찾으세요. 인터페이스 방향을 기준으로 한 레이아웃은 안쪽 디스플레이가 무시하는 신호를 읽고 있으므로, 사이즈 클래스 기준으로 옮깁니다.
- 세이프 에어리어의 각 가장자리를 개별적으로 점검하세요. 비대칭을 전제하고, 대칭 인셋을 가정하지 마세요.
UIScreen.main사용처를 검색하세요. 듀얼 디스플레이 기기에서는 값이 모호하며, Apple은 지원 중단을 예고했습니다. 화면은window?.windowScene?.screen에서, 스케일은traitCollection.displayScale에서 읽어오세요.- 펼친 상태뿐 아니라 컴팩트 너비에서도 테스트하세요. 바깥쪽 디스플레이는 인앱 메시지가 가장 좁은 공간을 갖는 실제 표면입니다.
- Device Hub 테스트를 준비하세요. Xcode 27.1 베타가 출시되면 Duo 시뮬레이터는 Device Hub에 있습니다. 메시지가 떠 있는 상태로 열고, 닫고, 회전시키고, 반쯤 접어보세요.
- 기기 모델별로 세그먼트를 설정하세요. Duo 사용자가 실제로 등장했을 때 별도로 타겟팅해 테스트할 수 있는 방법을 마련해 두세요.
- 푸시 알림 및 온보딩 권한 요청 문구를 재검토하세요. 온보딩 중 사용자가 보는 권한 요청 화면 자체는 여전히 시스템이 그리지만, 그 앞에 배치한 커스텀 사전 권한 화면은 인앱 메시지와 동일한 레이아웃 규칙을 따릅니다.
기기가 없어도 할 수 있는 일들입니다. 기기가 사용자 손에 들어가기 전에 끝내야 할 일이지, 그 이후에 할 일이 아닙니다.
Duo에 대비해 인앱 메시지 준비를 마치세요
인앱 메시지, 리치 미디어, 푸시 권한 요청 화면을 사용자가 가진 모든 화면에서 하나하나 수작업으로 고치는 것보다, 하나의 통합 플랫폼에서 관리하는 편이 여섯 곳을 따로 관리하는 것보다 훨씬 수월합니다. 인앱 메시지와 푸시 알림을 하나의 모바일 인게이지먼트 플랫폼에서 관리해야 하는 이유가 바로 여기에 있습니다. Pushwoosh는 SOC 2 Type I, ISO 27001:2022 인증을 획득한 옴니채널 플랫폼으로, 무료로 시작하거나 10월 23일 전에 메시징을 Duo에 맞게 준비할 수 있도록 상담을 신청해 보세요.