넓어진 제스처 영역, 정말 편리할까? - iOS 26의 새로운 스와이프 방식에 대한 고찰

지난 9월 16일, 애플의 iOS26가 공식적으로 릴리즈되었습니다. 세간의 주목을 받은 것은 리퀴드 글라스 디자인이었으나 제가 가장 주목한 것은 새로운 스와이프 방식이었습니다.

DB1(developer beta1)에서 예고된 것처럼, 이제는 화면 가장자리에서만 스와이프를 통해 이전 페이지(액티비티)로 돌아가는 제스처(이하 엣지 스와이핑)를 넘어, 화면 어느 곳에서 우측으로 스와이핑해도 이전 페이지로 전환되는 제스처(이하 유니버설 스와이핑)가 표준이 되었습니다. 이제 사용자는 화면 어느 위치에서든 오른쪽으로 스와이프하기만 하면 이전 화면으로 돌아갈 수 있습니다! (아직 iOS의 기본앱에서만 그렇긴 합니다만 점차 확장되겠죠?)

DB1에서 이 유니버설 스와이핑 기능이 소개될 당시 레딧의 개발자 사이에서도 호불호가 뚜렷히 갈렸었던 만큼(참고reddit.com (reddit.com, 새 창)), 저 역시 이러한 방향성이 애플이 그간 보여주었던 설계 철학과 달라 조금 당황스럽기도 합니다. 그래서 이 글에서는 접근성과 사용성 측면에서 iOS의 새로운 유니버설 스와이핑 방식을 돌아보고, 과연 좋은 개선이라고 할 수 있을지 제 개인적인 견해를 정리해 보고자 합니다.

디자인 휴리스틱 원칙으로 바라보기

제이콥 닐슨의 10대 휴리스틱 원칙은 사용자 경험을 평가할 때 널리 활용되는 지침입니다. 이번 iOS 26의 유니버설 스와이핑을 이 관점에서 살펴보면, 몇 가지 흥미로운 충돌 지점을 발견할 수 있습니다.

1. 통제권, 제어 자유 (User Control and Freedom) 유니버설 스와이핑은 사용자가 이전 화면으로 쉽게 돌아갈 수 있도록 돕지만, 의도치 않은 스와이프는 불필요한 이동을 발생시켜 오히려 통제권을 감소시킬 수 있습니다.

2. 일관, 표준성 (Consistency and Standards) 기존 iOS 앱에서는 엣지 스와이핑이 표준이었기 때문에, 화면 어디서나 스와이프가 가능해진 유니버설 스와이핑은 일관성을 깨는 변화로 느껴질 수 있습니다.

3. 오류 미연 방지 (Error Prevention) 사용자가 의도하지 않은 전환을 겪을 수 있는 만큼, 제스처의 민감도나 트리거 조건을 조절하지 않으면 오류 발생 가능성이 높아집니다.

4. 오류 파악, 수정 (Error Recovery) 사용자가 의도하지 않은 [뒤로가기]는 되돌리기 쉽지 않습니다. 긴 Form을 작성하고 있었다면? 입력해두었던 텍스트들이 모두 날아가있는 허탈한 상황과 마주할 뿐입니다.

5. 직관적 사용 (Recognition rather than Recall) 스와이핑은 탭 간 이동, 캐러셀 전환, 갤러리 이미지 넘기기처럼 “컨텐츠 내부 이동”에 더 자주 매핑되어 있습니다. 따라서 "페이지 이탈"이 갑자기 발생하면 예측이 어렵고, 사용자가 왜 이동했는지 즉각적으로 이해하기 힘듭니다.

즉, 유니버설 스와이핑은 편리성을 높이는 장점이 있는 반면, 몇몇 휴리스틱 원칙에서는 충돌 지점을 만들어낸다고 볼 수 있습니다. 편리함을 제공하는 동시에 기존의 예측 가능성과 안정성을 위협하는 양면성을 지니고 있는 것입니다.

WCAG 원칙으로 바라보기

웹 접근성 가이드라인(WCAG)는 단순히 웹에만 국한되지 않고, 제스처 기반 인터페이스를 포함한 모든 디지털 접근성 설계의 기준으로 참고할 수 있습니다. 유니버설 스와이핑을 이 원칙에 비추어 보면 다음과 같은 충돌 지점을 발견할 수 있습니다.

1. 2.1.1 Keyboard / Pointer Alternatives 모든 기능은 키보드 혹은 단일 포인터 입력으로도 수행할 수 있어야 합니다. 그러나 유니버설 스와이핑은 엣지 스와이핑과는 달리 화면 어디서나 발생할 수 있는 제스처이기 때문에, 예기치 않은 동작을 막을 수 있는 대체 입력 수단이 필요합니다. 예를 들어, [뒤로가기] 버튼처럼 명시적인 대체 UI가 항상 제공되지 않는다면 운동성 장애 사용자에게는 불리합니다.

2. 2.5.1 Pointer Gestures 복합적인 제스처보다는 단순 동작을 지원해야 합니다. 유니버설 스와이핑은 단순해 보이지만, 컨텍스트에 따라 “스크롤”, “캐러셀 이동”, “이미지 넘기기”와 같은 다른 수평 제스처와 충돌할 수 있습니다. 즉, 사용자가 의도하지 않아도 페이지 이탈이 발생할 수 있어 단순 제스처의 원칙을 위배합니다.

3. 운동성 장애 사용자에 대한 영향 손의 미세 조정이 어려운 사용자는 화면 중앙에서 콘텐츠를 조작하려다 무심코 스와이핑을 발동시킬 위험이 큽니다. 이 경우 원치 않는 화면 이탈로 이어지고, 앞서 작성 중이던 정보가 소실될 수 있습니다. 이는 곧 접근성뿐 아니라 사용성 전반에도 치명적인 문제를 야기합니다.

즉, WCAG 관점에서 유니버설 스와이핑은 “대체 수단 제공”과 “제스처 단순화”라는 원칙과 충돌할 수 있습니다. 이를 해소하기 위해서는 명시적 버튼 제공, 제스처 감도 조절, 상황별 제스처 차등 적용과 같은 보완책이 뒤따라야 한다고 볼 수 있습니다.

iOS의 설계 철학으로 바라보기

iOS는 초기부터 **물리적 직관(physical affordance)**을 중시해왔습니다. 사용자가 화면의 모서리를 잡아당기듯 제스처를 했을 때, 실제로 페이지가 넘어가는 듯한 시각적·물리적 반응을 제공해왔죠. 이러한 맥락에서 엣지 스와이핑은 사용자가 “화면의 끝”이라는 물리적 힌트를 통해 동작을 예측할 수 있게 해주는 중요한 설계였습니다.

그러나 유니버설 스와이핑은 이 **물리적 직관(affordance)**를 약화시킵니다. 화면 어디서든 스와이핑이 가능해지면서 사용자는 더 이상 “엣지에서 시작해야 한다”는 규칙을 기대할 수 없고, 제스처와 다른 인터랙션(스크롤, 캐러셀 이동 등)이 겹칠 위험이 생깁니다.

또한, **Apple HIG(Human Interface Guidelines)**가 강조하는 핵심 원칙 중 하나는 **명시적 피드백(explicit feedback)**입니다. 사용자의 입력이 시스템에 어떻게 반영되는지를 즉각적이고 명확하게 보여줘야 한다는 것이죠.

유니버설 스와이핑은 겉으로만 보면 ‘명시적 피드백’을 충실히 준수하는 듯 보입니다. 사용자가 스와이프를 시작하면 즉각적으로 화면이 밀리고, 손을 떼는 순간 전환 여부가 확정되는 애니메이션이 제공되니까요. 하지만 더 깊게 들어가면, 이 피드백은 예측 가능성과 맥락적 해석 면에서 어긋나는 부분이 존재합니다.

1. 사전 예측 가능성 부족 스와이프를 시도하기 전에는 이 화면이 ‘뒤로가기’ 제스처를 받아들일지 알 수 있는 단서가 없습니다. 엣지 스와이핑처럼 물리적 경계가 사라졌기 때문이죠.

2. 맥락적 해석의 모호성 스와이프 동작이 스크롤 제스처와 겹치는 경우, 화면이 움직이는 것이 단순 스크롤인지 ‘뒤로가기’ 전환의 시작인지 직관적으로 구분하기 어렵습니다.

즉, 겉으로는 명시적 피드백을 제공하지만, 사용자가 “왜 화면이 움직이고 있는지”를 즉각적으로 해석하기 어렵게 만든다는 점에서 애플 HIG의 본래 취지와는 어긋난다고 볼 수 있습니다.

결국, 유니버설 스와이핑은 iOS가 그간 쌓아온 설계 철학—물리적 직관성과 명시적 피드백—과 부딪히는 지점을 드러내고 있다고 볼 수도 있겠습니다. 그러나 동시에, 이는 사용자의 손 크기, 기기 크기, 사용 맥락이 달라진 시대적 요구에 맞춰 애플이 새로운 해석을 시도한 결과일지도 모릅니다. 작은 화면에서 출발했던 iOS는 이제 손바닥을 가득 채우는 대화면 기기로 확장되었고, 이에 따라 ‘손쉬운 뒤로가기’라는 과제가 더 중요해졌기 때문입니다.

따라서 이번 변화는 단순히 “기존 원칙을 어겼다”라기보다, 새로운 사용자 현실 속에서 애플이 철학을 재정립하려는 실험적 시도로 보는 것이 더 적절할지도 모릅니다. 앞으로 애플이 이 변화를 어떤 방식으로 다듬고, 사용자가 어떤 피드백을 내놓는지가 향후 iOS 제스처 디자인의 방향을 결정할 중요한 분기점이 될 것입니다.

⏱️ 째깍악어(웹) 🐊 에는 이미 있었다구요?

당근의 🥕Stackflowstackflow.so (stackflow.so, 새 창)를 확장한 전환 플러그인을 개발 및 적용하면서, 사실 째깍악어에는 유니버설 스와이핑 방식을 슬쩍 올려두고 사용자 피드백을 살피고 있었습니다. 적용 당시 기획, 개발, FE팀 사이에서도 의견이 일치되지 않았었거든요.

참 묘한 것은, 사용자 사이에서도 의견이 엇갈렸습니다. 의도하지 않았는데 화면이 밀려 당황스럽다는 의견과, 쉽게 이전 화면으로 돌아갈 수 있어 편하다는 의견이 모두 양립하고 있는 상태였습니다. 다만 애플의 큰 모바일 기기를 사용하시는 분들은 대체로 유니버설 스와이핑에 긍정적인 의견을 보내주셨는데, 좌측 상단에 위치하는 [뒤로가기] 버튼을 큰 기기에서는 터치하기 어려웠다고 해석이 가능해 보입니다. 이렇게 보면 점점 모바일 기기가 커져가는 현재 트렌드에 유니버설 스와이핑은 적절한 제안인 것 같기도 합니다.

다만 째깍악어의 앱은 애플의 유니버설 스와이핑과는 달리 일부 구간에 엣지 스와이핑을 활용하기도 했습니다. 째깍악어는 액티비티(화면)의 종류와 기능에 따라 다양한 전환 방식을 사용하고 있는데요, 풀스크린 모달의 기능을 하는 액티비티는 화면 하단에서 위로 올라오는 SlideUp 방식의 전환을 활용하고 있습니다.

해당 모달에서는 헤더 구간 영역에서 출발한 수직 스와이핑에 한해서 모달 닫기(뒤로가기)가 가능합니다. 액티비티(화면)가 아래에서 위로 포개진 상황에서 수평적인 스와이핑을 통해 이전 화면으로 돌아가는 상황, 조금 어색하지 않나요? 저희 째깍악어 디자인, 개발팀도 동일한 의견이었고, 해당 구간에는 수직 엣지 스와이핑을 적용해둔 상태입니다.

앞으로 화면 전환의 방향성이 어떻게 흘러갈지 모르겠지만 꼭 획일적인 규칙을 따르기보다 상황에 맞게 다양한 방식을 활용하는 것이 중요해 보입니다.

마무리하며

애플의 유니버설 스와이핑은 분명 편의성과 접근성 사이에서 균형을 찾아야 하는 과제를 안고 있습니다. 손이 큰 기기를 쓰는 사용자는 편리하다고 느끼지만, 의도치 않은 전환으로 불편을 겪는 사용자도 존재하기 때문입니다.

제가 째깍악어에서 활용했던 것처럼, 액티비티(화면)의 성격에 따라 스와이핑 방식을 달리 적용하는 접근도 좋은 완화책이 될 수 있습니다. 예컨대 풀스크린 모달은 수직 엣지 스와이핑으로만 닫히도록 하여 전환 맥락에 맞는 제스처를 제공하는 것이죠. 이러한 하이브리드 방식은 사용자가 예측 가능한 행동을 할 수 있도록 돕고, 불필요한 혼란을 줄여줄 수 있습니다.

애플이 앞으로도 실제 사용자 경험을 면밀히 관찰하면서 더 정교한 완화책(예: 제스처 범위 옵션, 민감도 조절, 맥락별 차등 적용 등)을 제시해주기를 기대해봅니다. 저 역시 프론트엔드 개발자로서 이 변화가 **“더 나은 사용 경험을 향한 진화”**로 이어질지 계속 지켜보려 합니다.