큰 화면만 보던 iOS 앱을 작은 iPhone에서 다시 보기
iPhone 17 Pro Max 중심 테스트에서 놓친 작은 화면의 불편함을 기기·언어별 시각 QA로 바꾼 기록.
한동안 한강자리 iOS 앱을 확인할 때 가장 많이 쓴 기기는 iPhone 17 Pro Max였다. 화면은 넓고, 텍스트는 여유 있게 들어가고, 첫 화면의 정보도 시원하게 보였다. 그래서 “테스트했다”는 감각이 있었다.
그런데 작은 iPhone에서 다시 보니 다른 앱처럼 느껴지는 순간이 있었다. 숫자는 들어가지만 리듬이 어색했고, 문장은 화면 안에 있지만 의미가 끊겼고, 위젯은 모든 정보를 담았지만 한눈에 읽히지 않았다.
문제는 특정 레이아웃 하나가 아니었다. 내가 보는 화면이 테스트 매트릭스 전체라고 착각한 것이 문제였다.
큰 화면만 보고 있었다
출시 후보를 다듬던 중 iOS 쪽 테스트 기록을 다시 훑어봤다. 테스트가 부족했던 것은 아니었다. 단위 테스트도 있었고, 스크린샷 캡처도 있었고, 실기기 설치와 실행 확인도 있었다. 다만 내가 반복해서 직접 확인한 실기기가 큰 화면에 치우쳐 있었다.
특히 손에 들고 계속 보던 기기가 iPhone 17 Pro Max였다. App Store용 스크린샷도 큰 화면을 기준으로 만들고 있었다. 그러다 보니 큰 화면에서 괜찮아 보이는 상태가 자연스럽게 정상 기준처럼 굳었다.
기록을 시간순으로 다시 보니 이유가 더 분명했다. 당시 릴리스 검증은 “빌드가 실기기에 설치되고 실행되는가”, “지원 OS 경로가 깨지지 않는가”에 가까웠다. 이것도 중요한 확인이지만, 작은 화면에서 문장과 정보 밀도가 유지되는지는 다른 문제다. 나는 그 둘을 같은 확인으로 묶어 생각했다.
이 조합은 위험했다. 큰 화면에서 깨지지 않는 UI는 작은 화면에서 의미까지 보존된다는 보장이 없다.
| 확인 축 | 기존 확인 방식 | 바꾼 확인 방식 |
|---|---|---|
| 실기기 확인 | iPhone 17 Pro Max 위주로 반복 확인 | iPhone 12 mini와 iPhone 13 Pro를 최종 확인 축으로 둠 |
| 스크린샷 | App Store용 큰 화면 캡처 중심 | SE, mini, 표준, Pro Max 계열을 함께 봄 |
| 검증 의미 | 설치와 실행 성공을 화면 품질 확인처럼 받아들임 | OS 경로 확인과 화면 밀도 확인을 분리함 |
| 언어와 모드 | 대표 화면을 빠르게 확인 | 5개 언어와 차량 모드, 일반 모드를 조합해 확인 |
| 산출물 | 통과 로그와 캡처 이미지 | 캡처 이미지와 측정 기록을 함께 남김 |
이전 방식도 쓸모는 있었다. 큰 화면에서 전체 정보 구조와 기본 동작을 빠르게 확인하기 좋았다. 하지만 그것만으로는 충분하지 않았다. 작은 화면은 같은 UI를 더 엄격하게 만든다. 여백, 줄바꿈, 버튼 위치, 접근성 크기, 위젯의 밀도가 모두 동시에 좁아진다.
작은 화면에서는 버그의 모양이 달라진다
작은 화면에서 발견한 문제들은 단순히 “잘림”으로 정리되지 않았다. 오히려 더 불편한 문제는 화면 안에 들어가는데도 사용성이 낮아지는 경우였다.
홈 히어로에서는 네 자리 주차 수와 단위 라벨이 한 줄에 안정적으로 붙어 있어야 했다. 하지만 숫자가 들어가는 것만으로는 끝나지 않았다. 좁은 화면의 히어로 값 영역에서 공원 표시점과 큰 문장 사이가 벌어지자, 첫 화면의 세로 리듬이 느슨해졌다.
이 문제는 픽셀 숫자만으로 보지 않았다. iOS 화면은 물리 픽셀보다 point(pt)라는 논리 단위로 레이아웃을 잡는다. 그래서 실제 기기에서 나온 3x 스크린샷을 point로 환산했다. 조정 전에는 표시점과 큰 문장 사이가 86-87px, 즉 28.7-29.0pt였다. 조정 뒤에는 74-75px, 즉 24.7-25.0pt로 들어왔다. 목표는 픽셀을 정확히 맞추는 일이 아니라, 작은 iPhone에서도 22-26pt 안쪽의 자연스러운 간격을 유지하는 일이었다.
알림 설정에서는 더 직접적인 문제가 있었다. 즐겨찾기 알림 행을 펼친 작은 화면에서 주차면 임계값 문장이 숫자 조절기와 떨어졌다. 사용자는 “빈자리가 대 이하로 남으면 알려요.”처럼 빈 문장을 보게 됐다. 값이 사라진 것이 아니라, 문장의 의미가 레이아웃 때문에 사라진 것이다.
일반 모드 중간 크기 위젯은 또 달랐다. 오른쪽 좁은 영역에 날씨, 미세먼지, 초미세먼지, 이벤트 세 줄, 날짜, 하단 액션 버튼이 들어갔다. 모든 정보가 들어가 있더라도 위젯의 목적은 빠르게 훑어보는 것이다. 작은 홈 화면에서 한눈에 읽히지 않는다면, 정보가 많은 것이 아니라 읽기 어려운 것이다.
| 사례 | 놓친 것 | 바꾼 것 | 검증한 것 |
|---|---|---|---|
| 홈 히어로 | 큰 화면에서는 숫자와 큰 문장이 여유 있게 보였지만 좁은 화면의 세로 간격이 느슨해짐 | 네 자리 주차 수와 단위 라벨을 안정화하고 히어로 값 영역의 위쪽 간격을 좁힘 | 5개 언어, 차량 모드와 일반 모드, iPhone 12 mini와 iPhone 13 Pro 실기기 pt 간격 측정 |
| 알림 설정 | 375pt, 390pt 화면에서 임계값 문장이 숫자 조절기와 떨어져 의미가 끊김 | 좁은 화면용 문장을 완성형으로 바꾸고, 선택지와 스크롤 여백을 조정 | SE, mini, 표준, Pro Max 시뮬레이터 캡처와 필수 실기기 최종 확인 |
| 일반 모드 위젯 | 중간 크기 위젯 오른쪽 영역이 과밀해 한눈에 읽기 어려움 | 날씨와 대기질을 작은 지표 묶음으로 줄이고 이벤트를 두 줄로 제한 | WidgetKit #Preview 크기, 접근성 글자 크기, 위젯 집중 테스트, 실기기 최종 확인 |
이 세 사례가 좋았던 이유는 모두 같은 방향을 가리켰기 때문이다. “작은 화면에서도 보이게 만들자”가 아니라, “작은 화면에서도 같은 의미와 우선순위로 읽히게 만들자”가 기준이 됐다.
시각 QA를 릴리스 게이트로 만들었다
그 다음에는 확인 방식을 바꿨다. 눈으로 한 번 더 보는 수준이면 다시 같은 실수를 반복할 가능성이 높았다. 그래서 작은 화면을 릴리스 전에 반드시 지나야 하는 게이트로 만들었다.
홈 화면 쪽은 캡처와 측정을 하나의 확인 흐름으로 묶었다. 먼저 같은 데이터 상태로 앱을 열고, 기기·언어·모드 조합마다 화면을 저장했다. 그런 다음 첫 화면에서 중요한 위치를 재서 측정 기록으로 남겼다.
여기서 중요한 단위는 픽셀이 아니라 point였다. 캡처 파일은 PNG라서 픽셀 너비와 높이를 가진다. 하지만 iOS 레이아웃은 point 기준으로 잡힌다. 그래서 캡처된 픽셀 좌표를 iOS의 point 단위로 바꿔 읽었다.
PPI와 기준 픽셀 해상도도 함께 기록했지만, 그 값으로 간격 공식을 만들지는 않았다. 화소 밀도는 어떤 기기의 캡처인지 설명하는 정보이고, 화면 안에서 UI가 차지하는 공간은 point와 화면 높이 대비 위치로 판단했다.
매트릭스는 이렇게 잡았다.
- 실기기: iPhone 12 mini, iPhone 13 Pro
- 시뮬레이터: iPhone SE 3, iPhone 12 mini, iPhone 17, iPhone 17 Pro Max
- 언어: 한국어, 영어, 일본어, 중국어 간체, 중국어 번체
- 모드: 차량, 일반
이 조합으로 60장의 홈 화면 밀도 점검용 스크린샷을 만들었다. 그런 다음 표시점과 히어로 문장 사이의 간격, 히어로가 시작되는 위치, 예보 영역과 첫 번째 섹션이 시작되는 위치를 point와 화면 높이 대비 비율로 측정했다. 기준은 모든 픽셀을 똑같이 맞추는 일이 아니었다. 작은 화면, 표준 화면, 큰 화면에서 정보 밀도와 위계가 일관되는지가 중요했다.
숫자 기준도 완전히 없애지 않았다. 예를 들어 표시점과 히어로 문장 사이의 간격은 22-26pt 안쪽에 들어오도록 봤다. 다만 모든 값을 절대 규칙으로 만들지는 않았다. 언어에 따라 텍스트 높이가 달라지고, 어떤 위치 비율은 1%p를 살짝 넘을 수 있다. 그때는 캡처를 직접 보고 잘림, 의도하지 않은 줄바꿈, 첫 화면 맥락 손실이 있는지 확인했다.
자동화는 판단을 대신하지 않는다. 대신 판단해야 할 화면을 빠뜨리지 않게 해준다.
테스트 종류마다 잡는 실패가 달랐다
이번에 다시 느낀 것은 SwiftUI와 WidgetKit UI에서는 하나의 테스트 방식이 전체를 커버하지 못한다는 점이다.
단위 테스트는 표시 상태와 큰 숫자 입력을 잡는 데 좋았다. 네 자리 주차 수, 모드별 히어로 값 영역, 위젯 표시값을 만드는 규칙처럼 화면을 만들기 전의 규칙은 테스트로 고정할 수 있었다.
#Preview와 시뮬레이터 스크린샷은 화면 크기와 Dynamic Type 조합을 빠르게 늘리는 데 좋았다. 특히 중간 크기 위젯은 329x155pt, 338x158pt, 364x170pt 같은 작은 point 크기와 XXXL, Accessibility2 글자 크기에서 확인해야 문제가 보였다. 이 문제는 고해상도 화면용 이미지를 더 준비하는 일이 아니었다. 작은 point 공간 안에서 정보량을 줄이는 일이었다.
실기기는 마지막에 남는 의심을 줄여줬다. 시뮬레이터가 화면 계열을 넓게 커버해도, 실제 기기에서 설치하고 열어본 최종 확인은 여전히 필요했다. 이번에는 iPhone 12 mini와 iPhone 13 Pro를 필수 실기기로 두고, 큰 화면 실기기는 자동 최종 확인 경로에서 제외했다. 내가 매일 쓰는 기기는 편하지만, 릴리스 기준으로는 너무 관대했다.
이렇게 나누고 나니 “테스트가 많다”보다 “각 테스트가 무엇을 못 잡는지 알고 있다”가 더 중요해졌다.
내 메인 기기는 테스트 매트릭스가 아니다
이번 일의 결론은 단순하다. 내가 자주 보는 기기는 테스트 매트릭스가 아니다.
큰 화면에서 통과한 UI는 실제로 통과한 것이 아니라, 큰 화면에서만 통과한 것일 수 있다. 특히 한강자리처럼 홈 화면, 설정, 위젯에 정보가 많이 들어가는 앱에서는 작은 화면이 더 정직한 기준이 된다. 작은 화면에서 의미가 유지되면 큰 화면은 대체로 여유를 얻는다. 반대로 큰 화면에서만 맞춘 UI는 작은 화면에서 문장, 밀도, 위계가 동시에 무너질 수 있다.
앞으로 iOS 쪽 릴리스 후보를 볼 때는 가장 대표적인 화면 크기보다 실패하기 쉬운 화면 크기를 먼저 볼 생각이다. 좋은 테스트 매트릭스는 평균 사용자를 상상하는 데서 끝나지 않는다. 내가 놓치기 쉬운 사용 환경을 강제로 보게 만드는 장치여야 한다.