앱 MVP 폴더블 전환: 접힘·펼침에도 작업을 이어 가는 5가지 기준
앱 MVP 폴더블 전환: 접힘·펼침에도 작업을 이어 가는 5가지 기준
앱 MVP를 폰 화면 하나만 기준으로 만들면, 폴더블에서 접었다 펴는 순간 사용자가 보던 항목·작성하던 입력·열어 둔 도구가 어디로 갔는지 알기 어려워질 수 있습니다. “큰 화면용 두 칸을 추가하자”는 결정만으로는 부족합니다. 현재 창의 공간, 힌지로 가려지는 영역, 화면 전환 뒤에도 이어져야 할 작업, 그리고 실제 자세별 테스트를 분리해야 합니다.
먼저 답하면, Android 폴더블 MVP는 기기 모델이 아니라 현재 앱 창에 배정된 공간을 기준으로 레이아웃을 고르고, 접힘·펼침을 새 화면으로 이동시키지 않으며, 사용자가 하던 작업 상태를 보존하는 범위부터 정하는 편이 좋습니다. 힌지나 폴드가 화면을 실질적으로 나누는 경우에는 조작 요소와 핵심 텍스트를 그 근처에 두지 않는지도 별도로 확인하세요.
이 글은 Android 폴더블에서 한 작업을 접힘과 펼침 사이에 이어 가는 MVP 판단에 한정합니다. 창 크기 조절과 멀티윈도우 자체의 범위는 앱 MVP 멀티윈도우 기준, 시스템 바·키보드와 제스처 영역은 앱 MVP 엣지투엣지 화면 기준에서 따로 확인하세요. 특정 화면 구성이 모든 기기에서 같은 경험을 만들거나 출시 심사를 통과시킨다고 보장하지 않습니다.
기준 1: ‘폴더블 기기’가 아니라 현재 앱 창의 공간을 봅니다
접힌 화면은 일반 휴대폰처럼 보이고, 펼친 안쪽 화면은 더 넓은 공간처럼 보일 수 있습니다. 하지만 같은 펼친 기기라도 회전하거나 분할 화면으로 실행하면 앱이 실제로 쓸 수 있는 폭과 높이는 달라집니다. Android Developers는 물리 화면 크기보다 앱에 배정된 현재 창 영역을 기준으로 반응형·적응형 레이아웃을 판단하도록 안내합니다.
그래서 MVP 기획서에는 “폴더블 지원”이라는 한 줄 대신, 좁은 창에서는 무엇을 한 열로 유지하고 넓어진 창에서 무엇을 보조 영역으로 함께 보여 줄지 적으세요. 예를 들어 목록과 상세를 동시에 보여 주는지, 입력 폼 옆에 안내를 둘지, 넓어져도 그대로 한 열을 유지할지를 기능별로 결정합니다. 기기명이나 화면 인치만 기록하면 분할 화면·데스크톱 창·회전 같은 실제 조건을 놓치기 쉽습니다.
중요한 것은 넓은 공간을 빈 카드로 채우는 일이 아닙니다. 사용자가 지금 하려는 다음 행동을 더 빠르게 하게 하는 보조 정보만 추가하세요. 넓은 화면에 두 번째 패널을 넣더라도, 좁은 화면에서 같은 목적지를 열었을 때 사용자가 보던 항목과 맥락이 사라지면 안 됩니다.
기준 2: 힌지는 장식이 아니라 ‘배치하면 안 되는 경계’인지 확인합니다
모든 폴더블의 가운데 선이 같은 성격은 아닙니다. Android의 fold-aware 안내는 폴드·힌지의 방향, 접힘 상태, 그리고 해당 영역이 내용을 가리는지 여부를 따로 다룹니다. 두 화면 사이를 실제로 분리하는 힌지라면 그 위의 내용은 보이지 않거나 조작하기 어려울 수 있습니다.
따라서 MVP에서 먼저 피할 것은 중앙 힌지 위의 저장 버튼, 결제 확정, 다음 단계, 오류 메시지, 긴 문장입니다. 책처럼 세로로 접히는 자세에서는 좌우에 내용을 나눌지, 탁자처럼 가로로 접히는 자세에서는 위쪽에 결과를 두고 아래쪽에 조작을 둘지처럼 기능의 성격에 맞춰 판단하세요. 단지 화면을 반으로 나눈다는 규칙을 모든 화면에 적용할 필요는 없습니다.
이때 남길 기록은 기기 브랜드가 아니라 ‘현재 자세·힌지 방향·가림 여부·배치 결과’입니다. 그래야 QA에서 중앙에 걸친 요소를 발견했을 때, 디자인 문제인지 기기별 창 조건 문제인지 다시 확인할 수 있습니다. 폴더블을 쓰지 않는 사용자에게도 동일한 창 크기가 생길 수 있으므로, 힌지 감지는 보조 신호이고 기본 레이아웃 판단을 대체하지 않습니다.
기준 3: 접힘·펼침을 새 페이지 이동으로 만들지 않습니다
넓어졌다고 상세 화면으로 자동 이동하거나, 접혔다고 목록 첫 화면으로 되돌리면 사용자는 기기 동작 때문에 자신의 작업 맥락을 잃게 됩니다. Android Developers는 창 크기 변화에 맞추기 위해 서로 다른 콘텐츠 목적지를 만들거나, 크기 변경을 내비게이션의 부수 효과로 만들지 말라고 안내합니다.
대신 한 목적지 안에서 배치만 바뀌는지부터 정하세요. 목록에서 선택한 항목, 입력 중인 단계, 열어 둔 필터, 재생 중인 미디어처럼 사용자가 계속 인식해야 하는 상태를 먼저 적습니다. 펼쳤을 때 보조 패널을 추가하더라도 선택 상태는 그대로 두고, 접었을 때는 그 패널의 정보가 원래 화면에서 다시 접근 가능해야 합니다.
이 기준은 개발 구현 지시가 아니라 출시 범위의 질문입니다. “전환 뒤 무엇이 유지되어야 하는가”, “같은 작업을 계속한다는 것을 사용자에게 어떻게 보일 것인가”, “배치만 바뀌고 목적지는 유지되는가”를 화면별 완료 조건에 넣으면, 단순 화면 캡처보다 실제 경험을 검토하기 쉬워집니다.
기준 4: 입력·선택·진행 상태를 화면 크기와 분리해 보존합니다
접힘과 펼침 사이에서 앱이 중지되거나 다시 만들어질 수 있다는 점은 MVP에서도 무시하기 어렵습니다. Android 공식 안내는 이 전환에서 상태를 보존·복원해 사용자 연속성을 유지하도록 설명합니다. 그러므로 화면 폭에 따라 어떤 컴포넌트를 보일지는 레이아웃 규칙에 두고, 사용자가 진행하던 일은 별도 상태로 다루는 것이 좋습니다.
예를 들어 신청서를 쓰는 앱이라면 현재 단계, 이미 입력한 값, 선택한 첨부 항목, 검증 오류를 구분해 확인합니다. 콘텐츠 앱이라면 선택한 항목과 읽던 위치, 미디어 앱이라면 재생 여부와 현재 조작 가능 상태를 따로 봅니다. 민감한 값은 화면 전환을 핑계로 불필요하게 저장하거나 로그에 남기지 말고, 제품의 개인정보 처리 원칙과 실제 보관 범위를 함께 검토해야 합니다.
“전환 뒤 화면이 다시 열렸다”는 관찰만으로 연속성이 검증되지는 않습니다. 사용자가 전에 누른 선택이 유지됐는지, 저장 전 입력이 어떻게 처리됐는지, 실패했다면 어떤 복구 선택지를 보여 주는지까지 확인해야 합니다. 글자 크기 변화까지 겹칠 수 있으므로 앱 MVP 글자 크기 기준도 같은 핵심 흐름에서 함께 보세요.
기준 5: 접힘·펼침·회전·분할 실행을 같은 작업으로 끝까지 테스트합니다
폴더블 지원은 넓은 화면 스크린샷 한 장으로 확인할 수 없습니다. Android의 품질 안내는 접힘·펼침 상태와 자세에서 UI 요소가 적절한 위치로 전환되는지 보는 테스트를 제시합니다. MVP의 검증도 ‘화면 전환이 된다’가 아니라, 같은 사용자가 하던 과업을 끝낼 수 있는지로 구성하는 편이 낫습니다.
테스트 기록에는 시작 자세와 창 상태, 사용한 핵심 흐름, 전환 시점, 전환 뒤 선택·입력·오류 상태, 힌지 주변의 조작 가능 여부, 최종 완료 결과를 남기세요. 필요하면 실제 지원 기기와 에뮬레이터의 결과를 분리해 기록합니다. 어떤 자세를 첫 출시 범위에서 지원할지와 어떤 조건에서는 한 열 레이아웃으로 안전하게 돌아갈지도 명시해야, 지원하지 않는 동작을 성공한 기능처럼 보이지 않게 할 수 있습니다.
판단 칸 | 먼저 답할 질문 | 확인할 증거 |
|---|---|---|
창 공간 | 현재 앱에 배정된 공간에서 한 열·두 패널 중 무엇을 쓸까? | 창 크기별 핵심 화면 결과 |
힌지 경계 | 가운데 영역이 가리는가, 조작하기 어려운가? | 자세·방향·가림 여부와 배치 화면 |
목적지 | 전환이 새 페이지 이동처럼 보이지 않는가? | 선택 항목과 뒤로가기 흐름 |
작업 상태 | 입력·선택·진행 중 무엇을 유지하거나 안내할까? | 전환 전후 상태와 복구 결과 |
QA | 실제 과업을 접힘·펼침·회전에서 끝낼 수 있는가? | 시작 조건·전환·완료 기록 |
출시 전 5분 점검표
기기명 대신 현재 앱 창의 공간을 기준으로 한 열·보조 패널 규칙을 정했는가?
힌지나 폴드가 가리는 영역에 핵심 조작·텍스트를 놓지 않았는가?
접힘·펼침이 새 목적지 이동이나 맥락 초기화로 이어지지 않는가?
입력·선택·진행 상태와 화면 배치 규칙을 분리해 확인했는가?
같은 핵심 과업을 접힘·펼침·회전 또는 분할 실행에서 실제로 끝까지 확인했는가?
폴더블 MVP의 핵심은 특별한 두 화면을 많이 만드는 일이 아니라, 창의 모양이 바뀌어도 사용자가 하던 일을 알아볼 수 있게 하는 것입니다. 유인어스는 민간 사업 지원 서비스이며, 이 글은 특정 앱의 호환성·장애 예방·심사 통과를 보장하지 않습니다. 실제 출시 범위는 최신 Android 공식 문서, 대상 기기와 앱의 실제 동작을 함께 확인해 결정하세요.
자주 묻는 질문
폴더블 앱은 무조건 두 패널 화면을 만들어야 하나요?
아닙니다. 넓어진 창에서 두 패널이 사용자의 다음 행동을 돕는 경우에만 검토하세요. Android 공식 안내도 기기명이 아니라 현재 앱 창에 배정된 공간을 기준으로 레이아웃을 판단하도록 설명합니다. 한 열 레이아웃이 더 명확한 기능은 그대로 유지할 수 있습니다.
접힘과 펼침 때 새 화면으로 이동하면 안 되나요?
창 크기 변화 자체를 새 목적지 이동의 부수 효과로 만들지 않는 편이 좋습니다. 같은 목적지에서 배치가 바뀌되, 선택한 항목·입력·현재 단계처럼 사용자가 인식하는 작업 맥락이 이어지는지 확인하세요.
힌지 중앙에 모든 콘텐츠를 피해야 하나요?
폴드와 힌지의 성격은 기기와 현재 자세에 따라 다릅니다. 실제로 내용을 가리거나 조작을 어렵게 하는 분리 영역인지 먼저 확인하고, 그 경우 핵심 조작과 긴 텍스트를 그 근처에 두지 마세요. 기본 레이아웃은 창 공간을 기준으로 설계합니다.
폴더블 테스트는 화면 캡처만 있으면 충분한가요?
충분하지 않습니다. 같은 핵심 과업을 시작한 뒤 접힘·펼침·회전 또는 분할 실행으로 바꾸고, 선택·입력·오류 상태와 최종 완료 결과를 확인해야 합니다. 실제 지원 기기 결과와 에뮬레이터 결과도 구분해 기록하세요.
확인한 공식 출처
Android Developers · Make your app fold aware — 2026-09-19 확인
Android Developers · Support different display sizes — 2026-09-19 확인
Android Developers · Build responsive navigation — 2026-09-19 확인
Android Developers · Learn about foldables — 2026-09-19 확인
Android Developers · Foldables quality guidelines — 2026-09-19 확인