아이패드는 망가졌습니다

아이패드는 처음부터 맥을 닮은 기기가 아니었습니다. 아이패드의 강점은 키보드와 마우스를 전제로 한 데스크탑 문법이 아니라 손가락과 애플펜슬로 화면을 직접 만지며 빠르게 처리하는 단순한 흐름에 있었습니다. 그래서 오랜 시간 아이패드를 핵심 작업 도구로 써 온 입장에서 복잡한 윈도우 관리보다 방해받지 않는 집중과 즉시성을 생산성으로 바꿔 왔습니다. 그런데 최근 몇 년 동안 아이패드는 점점 맥과 비슷한 모습으로 바뀌었습니다. 특히 iPadOS 16에서 스테이지 매니저가 추가되며 여러 앱을 겹치는 윈도우로 띄우고 윈도우 크기를 바꾸며 앱을 묶어 작업을 전환하는 방식이 핵심 멀티태스킹 경험으로 등장했습니다. 스테이지 매니저는 여러 크기의 겹치는 윈도우를 한 화면에서 다루고 독에서 앱을 열어 앱 그룹을 만들고, 외부 모니터에서 최대 6K 해상도로 확장해 아이패드 화면과 외부 모니터에서 각각 여러 앱을 동시에 쓰는 것을 목표로 만들어졌습니다[^iPadOS 16 takes the versatility of iPad even further with powerful new productivity and collaboration features]. 이 변화는 분명히 어떤 사용자에게는 반가운 소식이었을 겁니다. 아이패드를 책상 위에 올려두고 키보드와 트랙패드를 연결해 외부 모니터까지 붙여 거의 컴퓨터처럼 쓰고 싶은 사용자들에게는 스테이지 매니저가 강한 무기가 될 수 있습니다. 동시에 이 변화는 다른 사용자에게는 불편의 시작이기도 했습니다. 아이패드는 화면을 직접 만지고, 제스처로 빠르게 넘기고 스플릿 뷰와 슬라이드 오버로 필요한 만큼만 앱을 겹쳐 쓰는 흐름이 강했는데 스테이지 매니저는 그 흐름을 윈도우 관리 중심으로 바꿔 버렸기 때문입니다. 스플릿 뷰는 두 앱을 나란히 놓아 동시에 쓰게 하고, 슬라이드 오버는 한 앱 위에 작은 윈도우를 띄워 보조 앱처럼 쓰게 만드는 방식입니다[^Use multitasking on your iPad].

여기서 중요한 문제는 기능이 늘었다와 사용성이 좋아졌다가 같은 말이 아니라는 점입니다. 스테이지 매니저는 새로운 멀티태스킹 경험을 내세웠지만, 실제로는 아이패드 사용자 중 이 기능을 켜서 쓰는 비율이 낮게 나타난 조사도 있습니다. 예를 들어 한 설문에서는 아이패드에서 스테이지 매니저를 사용한다는 응답이 8%로 집계된 적이 있습니다[^Do You Use It? Stage Manager Sees Weak Adoption]. 이 수치는 스테이지 매니저가 쓸모 없다를 증명하는 숫자라기보다 아이패드 전체 사용자에게 기본값이 되기엔 아직 멀다는 신호로 읽는 편이 더 정확합니다.​ 오늘 이야기하고 싶은 주제는 바로 여기에 있습니다. 아이패드가 맥OS의 인터페이스를 상당 부분 가져오면서도 맥만큼 편해지지 못한 이유는 무엇인지 그리고 그 과정에서 왜 기존 아이패드 해비 사용자들의 작업 파이프라인이 더 자주 끊기게 되었는지를 시간 순서대로 정리해 보려 합니다. 또한 아이패드의 맥OS화가 충분한 고민 없이 추진된 면이 있다고 봅니다. 아이패드와 맥은 사용 목적이 다르고 그 차이를 존중한 채로 두 기기의 인터페이스를 설계해야 한다고 생각합니다. 특히 오늘은 아이패드를 맥처럼 만들어 달라는 목소리가 항상 아이패드 해비 사용자의 대표 의견이었는지 따져보려 합니다. 영향력 큰 유튜브 채널과 리뷰어들이 강조해 온 아이패드는 맥이 되어야 한다는 주장에 맞춰 제품 방향이 움직이면서 정작 아이패드를 아이패드답게 써서 성과를 내던 사람들의 경험이 흔들렸다는 느낌이 커지고 있기 때문입니다. 이 부분은 사실이라기보다 문제 제기이며 뒤에서 실제로 어떤 불편이 반복해서 나타나는지 구체적으로 설명해 보겠습니다.

아이패드의 첫 인터페이스를 이해하려면 애플이 처음부터 맥 같은 윈도우에 기반한 인터페이스를 만들려 하지 않았다는 점부터 확인하고 가야 합니다. 아이패드 초기 운영체제는 아이폰 OS 3.2를 기반으로 했고, 화면이 커졌다고 해서 데스크탑처럼 마우스로 윈도우를 여닫는 방식이 아니라 터치로도 자연스럽게 쓸 수 있는 큰 화면 전용 UI 규칙을 새로 만든 쪽에 가까웠습니다[^iPad turns 10: Why did it take a decade for Apple's tablet to get its own operating system?]. 이 시기에 핵심이 된 개념은 팝오버와 스플릿 뷰였습니다. 팝오버는 작은 화면에서라면 화면을 통째로 바꿔야 했던 설정이나 선택을 큰 화면에서는 작은 패널처럼 띄워서 처리하게 하는 방식이었고 스플릿 뷰는 목록과 내용을 한 화면에서 동시에 보여주는 방식이었습니다. 이 두 가지는 아이패드는 큰 아이폰이지만 단순 확대가 아니라 큰 화면에서 덜 움직이게 만드는 기기라는 방향을 분명히 보여줬습니다[^What's New in iPhone SDK 3.2]. 당시 개발 도구가 공개되던 시점부터 스플릿 뷰와 팝오버가 아이패드 전용 요소로 확인됐다는 기록도 있습니다. 즉 애플은 초기에 아이패드를 데스크탑을 축소한 것으로 보지 않았고 터치 기반 기기에서 큰 화면을 쓰는 법을 따로 설계했다고 보는 편이 맞습니다[^iPhone SDK calls out nonexistent iPad cam, confirms split views and popovers are iPad-specific]. 여기서 중요한 결과가 하나 나옵니다. 아이패드의 초기 생산성은 ‘여러 윈도우를 동시에 띄우는 능력’이 아니라, 같은 앱 안에서 목록과 내용을 나누어 보여주거나(스플릿 뷰), 필요한 옵션만 잠깐 띄워 처리하는(팝오버) 방식으로 만들어졌다는 점입니다. 그래서 초기 아이패드의 작업 흐름은 지금처럼 앱을 여러 개 겹쳐 놓고 계속 관리하는 형태가 아니라, 한 앱에 집중하되 화면 이동을 줄여 끊김을 줄이는 형태로 자리잡기 쉬웠습니다[^What's New in iPhone SDK 3.2].

또 하나 눈여겨볼 점은, 이 시기의 ‘터치 우선’ 철학이 개발 수준에서도 매우 강했다는 사실입니다. 아이패드가 등장하던 때에 제스처 인식기 같은 기능이 아이패드와 함께 들어왔고, 화면을 직접 쓸어 조작하는 방식이 앱 인터페이스의 기본 전제가 되었습니다. 이 전제는 훗날 포인터 중심 조작이 강해질 때 왜 많은 사용자가 어색함을 느끼는지 이해하는 데도 연결됩니다[^Mail app style Split View Controller with a sliding master view]. 2010년 말의 iOS 4.2 업데이트는 초기 아이패드 인터페이스의 성격을 한 단계 더 굳혔습니다. 이 업데이트로 아이패드는 멀티태스킹과 폴더를 공식 지원하게 됐고 유니파이드 인박스 에어프린트 같은 기능도 포함됐습니다. 여기서 말하는 멀티태스킹은 윈도우처럼 여러 앱을 한 화면에 올려놓는 것이라기보다 앱 전환을 빠르게 하고 백그라운드에서 일부 기능을 허용하는 방향에 가까웠습니다[^iOS 4.2 Software Update for iPad]. 폴더 역시 단순 기능 같아 보이지만 홈 화면을 정리해서 앱 접근 비용을 줄이고 작업 앱과 생활 앱을 분리해 놓는 습관을 만들며 ‘작업 도구’로서의 준비를 갖추게 했습니다[^iOS 4.2 available today, brings the iPad into the multitasking era (update: it's live)]. 2011년의 iOS 5 시기에는 화면 크기 때문에 생기는 입력 문제를 해결하려는 변화도 이어집니다. 대표적으로 분리 키보드는 두 손 엄지 입력에 맞춘 설계로, 화면을 직접 붙잡고 쓰는 상황을 전제로 한 아이패드다운 개선이었습니다[^Move the iPad onscreen keyboard]. 이 시기까지의 큰 흐름을 정리하면, 아이패드는 맥처럼 되기보다 큰 터치 화면에서 덜 움직이고 더 빨리 처리하기를 목표로 인터페이스를 쌓아 올렸다고 말할 수 있습니다[^What's New in iPhone SDK 3.2].

초기 아이패드는 윈도우를 늘려서 생산성을 만드는 기기라기보다 큰 화면에서 덜 이동하게 하는 방식으로 흐름을 만들었습니다. 이 흐름이 2013년 iOS 7을 거치면서 한 번 더 크게 바뀌는데 이번에는 기능이 아니라 화면의 생김새와 조작감을 바꾸는 변화였습니다. iOS 7은 인터페이스를 전면 재설계하면서 글꼴, 아이콘, 버튼, 레이어 표현을 모두 바꿨고 반투명과 움직임 같은 시각 효과를 적극적으로 쓰기 시작했습니다. 이 변화는 아이패드에도 그대로 들어왔기 때문에 아이패드를 오래 쓰던 사람일수록 익숙한 가죽 질감 UI가 사라지고, 하얀 바탕과 얇은 글씨가 중심이 된 화면을 갑자기 마주하게 됐습니다[^Apple Unveils iOS 7]. 이 시기 아이패드 사용 경험을 바꾼 핵심은 제어 센터였습니다. 화면 아래에서 한 번 쓸어 올리면 와이파이, 블루투스, 방해금지 모드, 화면 밝기, 음악 재생 같은 자주 쓰는 조작을 한 화면에서 바로 만질 수 있게 됐습니다. 이전에는 설정 앱이나 별도 화면을 왔다 갔다 해야 했던 일이, 화면 전환 없이 한 번의 제스처로 해결되기 시작했고 이 변화는 아이패드의 즉시성을 강화하는 쪽으로 작동했습니다. 하지만 디자인 혁명은 늘 양면을 갖습니다. iOS 7의 플랫 디자인은 화면을 깔끔하게 만들었지만, 버튼과 링크가 ‘버튼처럼 보이지 않게’ 되는 순간도 많아졌고, 사용자가 눌러야 할 지점을 더 많이 추측하게 만들었습니다[^iOS 7 User-Experience Appraisal]. 아이패드처럼 화면이 큰 기기에서는 콘텐츠가 넓게 펼쳐지는 만큼, 눌러야 할 단서가 약해졌을 때 길을 잃는 느낌도 커지기 쉬웠습니다. 이때부터 아이패드는 제스처를 아는 사람이 빠르게 쓰는 기기로 더 강하게 굳기 시작했습니다. 제어 센터처럼 화면 가장자리에서 쓸어 올리는 동작은 직관적이기도 하지만 ‘처음 보는 사람에게는 숨어 있는 기능’이기도 합니다. 이 문제는 나중에 멀티태스킹이 복잡해졌을 때 더 크게 터지는데 그때의 씨앗이 이미 iOS 7 시절부터 자라기 시작했다고 봐야 합니다[^iOS 7 User-Experience Appraisal].

2014년 무렵에는 아이패드에서 두 개 앱을 동시에 더 적극적으로 쓰고 싶다는 기대가 커졌고, 아이패드에 스플릿 화면 멀티태스킹이 들어갈 수 있다는 전망이 계속해서 나타났습니다[^Apple plans to match Microsoft Surface with split-screen iPad multitasking in iOS 8]. 또한 아이패드 사용자들은 작은 화면이라도 동시에 두 가지를 하고 싶다는 욕구를 반복해서 드러냈습니다[^Split-screen multitasking in iOS 8?]. 이 흐름이 중요한 이유는, 아이패드가 작업 기기가 되길 바라는 요구가 단순히 성능이 좋아져서 나온 게 아니라 실제로 iOS 7 이후 아이패드가 더 자주 더 오래 쓰이는 기기가 되면서 자연스럽게 생겨난 수요였기 때문입니다. 정리하면, 2013~2014년은 아이패드가 맥을 닮기 시작한 시기가 아니라 아이패드가 제스처 중심의 숨은 인터페이스를 더 깊게 받아들이며 사용 습관을 바꾼 시기였습니다. 이때 강화된 즉시성은 분명 장점이었지만, 동시에 기능이 숨어서 배우기 어렵다는 약점도 같이 키웠습니다[^iOS 7 User-Experience Appraisal].

iOS 7 이후 아이패드는 제스처 기반 조작이 더 강해졌고, 기능이 화면 어딘가에 숨어 있는 방식도 늘었습니다. 2015년 iOS 9에서 등장한 스플릿 뷰와 슬라이드 오버는 그 흐름을 그대로 이어받았지만 결과는 정반대에 가까웠습니다. 즉 배우기 어려움이라는 약점도 있었지만 한 번 익히면 아이패드를 작업 도구로 만드는 힘은 엄청나게 커졌습니다. iOS 9에서 애플은 슬라이드 오버, 스플릿 뷰, 화면 속 화면을 아이패드 멀티태스킹의 핵심 기능으로 소개했습니다. 슬라이드 오버는 지금 쓰고 있는 앱을 떠나지 않은 채로 두 번째 앱을 화면 오른쪽에서 불러오는 기능이고, 스플릿 뷰는 두 앱을 나란히 놓고 동시에 조작할 수 있게 해 주는 기능이며, 화면 속 화면은 영상을 작은 윈도우로 띄워 다른 일을 하면서도 계속 보게 해 주는 기능입니다[^iOS 9 Available as a Free Update for iPhone, iPad & iPod touch Users September 16]. 여기서 중요한 점은, 이 멀티태스킹이 ‘맥처럼 윈도우를 여러 개 띄우는 방식’이 아니라는 사실입니다. 스플릿 뷰는 화면을 정확히 두 개의 공간으로 나눠 각각을 한 앱이 차지하게 했고, 사용자는 화면의 분할선을 움직여 어느 쪽을 더 크게 보여줄지 조절할 수 있었습니다. 즉 윈도우가 아니라 화면을 나눴고 화면의 가장자리를 어지럽히지 않았습니다. 이 차이가 아이패드 해비 사용자에게는 결정적이었습니다. 손가락으로 하는 터치 조작은 마우스처럼 정밀한 픽셀 단위 제어가 어렵습니다. 따라서 화면을 윈도우가 아니라 ‘영역’으로 나눠서 딱 붙여 주는 방식은, 터치의 장점과 약점을 동시에 고려한 설계였습니다.​ 슬라이드 오버가 특히 강력했던 이유는 보조 앱이라는 개념을 아주 빠르게 구현했기 때문입니다. 문서를 쓰다가 메신저를 잠깐 열어 답장을 보내고, 다시 문서로 돌아오는 흐름이 자연스럽게 만들어졌습니다. 슬라이드 오버는 어디까지나 옆에서 잠깐 끼어드는 역할이었고, 사용자는 원할 때 화면 오른쪽에서 쓸어 불러오고, 필요 없으면 밀어서 다시 숨기면 됐습니다. 스플릿 뷰가 ‘동시 작업’을 위한 구조라면, 슬라이드 오버는 ‘잠깐 처리’에 특화된 구조였다는 점이 중요합니다[^Get to know the iPad's new 'split-view' feature in iOS 9].

이때 아이패드 해비 사용자들의 작업 방식이 눈에 띄게 바뀌었습니다. 대표적인 변화는 주 앱 하나에 집중하면서 보조 앱을 끼워 넣는 습관이 생겼다는 점입니다. 예를 들어 글을 쓰는 사용자들은 왼쪽에 사파리나 참고 자료를 띄우고, 오른쪽에 글쓰기 앱을 두는 식으로 작업을 정착시켰습니다. 공부하는 사용자들은 강의 영상은 화면 속 화면으로 띄우고 필기 앱은 화면을 크게 쓰는 형태를 만들었습니다. 메신저는 슬라이드 오버로만 처리하고 본 작업 화면을 가능한 한 건드리지 않는 방식도 널리 퍼졌습니다. 이 흐름은 지금도 아이패드는 한 앱에 깊게 몰입할 때 강하다는 평가로 이어집니다. 이 구조를 황금기라고 부를 수 있었던 이유는 멀티태스킹의 규칙이 매우 단순했기 때문입니다. 스플릿 뷰는 두 앱이 나란히 있고 둘 다 동시에 ‘활성화’됩니다[^Inside iOS 9: Split-Screen Multitasking for the iPad]. 슬라이드 오버는 ‘잠깐’ 옆에서 작동하며, 필요하면 슬라이드 오버 안에서 앱을 바꿀 수도 있었습니다. 화면 속 화면은 화면 위에 영상만 작게 떠 있을 뿐, 나머지 작업 흐름을 거의 방해하지 않았습니다. 이 세 가지 조합은 한 번에 세 가지까지도 가능하게 만들었지만, 사용자가 ‘창을 겹쳐 놓고 정리’하는 부담은 거의 만들지 않았습니다[^How to Split Screen Apps on iPad]. 반대로 한계도 분명했습니다. 스플릿 뷰가 되는 기기 조건이 제한적이었고, 모든 앱이 바로 지원한 것도 아니었습니다. 스플릿 뷰는 당시 iPad Air 2, iPad mini 4, iPad Pro 같은 비교적 최신 기기에서만 가능했고 구형 기기에서는 슬라이드 오버만 되는 경우가 많았습니다[^Inside iOS 9: Split-Screen Multitasking for the iPad]. 또한 앱 개발자가 멀티태스킹을 지원해야 제대로 쓸 수 있었기 때문에 초반에는 하고 싶은데 안 되는 앱이 자주 나왔습니다. 하지만 아이패드 해비 사용자 관점에서 이 한계는 불만이면서도 안전장치이기도 했습니다. 왜냐하면 멀티태스킹이 되는 앱은 대체로 화면을 나눠도 쓸 만하게 만들어졌고 안 되는 앱은 억지로 쪼개지지 않았기 때문입니다. 당시에는 그 단순함이 오히려 사용 경험을 안정적으로 유지해 줬습니다.​ 이 시기의 커뮤니티 평가는 대체로 아이패드는 아이패드 방식으로 멀티태스킹을 푼 것에 가까웠습니다. 맥처럼 수십 개 윈도우를 띄우는 방식이 아니라, 터치 조작에 맞춘 제한된 구조로도 실제 작업이 가능해졌다는 점이 긍정적으로 받아들여졌습니다. 동시에 더 많은 자유에 대한 요구도 커졌습니다. 한 화면에 두 개만 놓는 걸 넘어 세 번째, 네 번째 앱을 더 자연스럽게 섞고 싶어 하는 욕구가 쌓였고, 외부 모니터를 붙이면 더 넓게 쓰고 싶다는 기대도 점점 커졌습니다.

그런데 iOS 9의 멀티태스킹은 어디까지나 화면을 나누는 방식이었고 파일을 다루는 방식은 여전히 약했습니다. 많은 사용자가 아이패드를 작업 기기로 쓰기 시작한 순간부터 멀티태스킹보다 더 자주 발목을 잡은 것은 파일이 어디에 있는지, 이 파일을 다른 앱에서 어떻게 쓰는지, 파일을 한 번에 옮길 수 있는지 같은 문제였습니다. 이때 등장한 iOS 11 for iPad는 방향이 분명했습니다. 애플은 아이패드에서 멀티태스킹을 더 강하게 만들겠다고 말했고, 그 수단으로 독과 파일 앱과 드래그 앤 드롭을 묶어서 제시했습니다[^iOS 11 brings powerful new features to iPhone and iPad this fall]. 먼저 독은 아이패드 사용 습관을 크게 바꿨습니다. 이전에도 하단 바 같은 것은 있었지만, iOS 11의 독은 ‘어디서나’ 불러올 수 있는 형태로 바뀌었습니다. 화면 아래에서 살짝 쓸어 올리기만 하면 독이 나타나고, 홈 화면으로 나가지 않아도 앱을 바꿀 수 있게 된 것입니다. 이 변화는 작업 흐름을 끊는 횟수를 줄였고, 앱 전환 자체가 작업이던 아이패드 경험을 작업 중에 자연스럽게 도구를 꺼내 쓰는 경험으로 바꿔 놓았습니다[^iOS 11: How multitasking and the Dock work on the iPad]. 그런데 독이 단순히 앱을 모아놓는 서랍이었다면, 여기까지는 ‘편해졌다’ 정도로 끝났을지도 모릅니다. iOS 11의 독은 멀티태스킹의 출발점으로 설계됐습니다. 앱 아이콘을 독에서 끌어올려 화면 왼쪽이나 오른쪽 가장자리에 놓으면 곧바로 스플릿 뷰가 시작되고, 조금 더 중앙 쪽에 놓으면 슬라이드 오버가 ‘떠 있는 윈도우’처럼 동작합니다. 이때부터 슬라이드 오버는 단순히 오른쪽에서 밀려 들어오는 패널이 아니라, 화면 위에 떠 있는 보조 윈도우 같은 인상이 강해졌습니다[^iOS 11: How multitasking and the Dock work on the iPad]. 이 변화는 보조 앱을 잠깐 끼우는 철학을 유지하면서도, 더 빠르게 띄우고 더 빠르게 바꾸는 방향으로 아이패드 멀티태스킹을 정리해 준 점에서 의미가 있었습니다.​

다음으로 드래그 앤 드롭은 아이패드가 ‘진짜’ 작업 기기가 되는 순간을 만들었습니다. iOS 11에서 드래그 앤 드롭은 사파리 링크, 사진, 텍스트, 파일 같은 것들을 앱 사이로 직접 끌어 옮기는 방식으로 설계되었습니다[^Hands-On With iOS 11's iPad Features: Dock, Drag and Drop, App Switcher and More]. 특히 멀티터치로 여러 개를 한 번에 집어 들 수 있다는 점이 아이패드에 맞는 설계였고, 손가락이 여러 개인 기기의 장점을 그대로 이용한 방식이었습니다[^Move and copy items with drag and drop on iPad]. 이 경험이 왜 중요한지 쉽게 설명하자면, 예전에는 자료를 옮길 때 ‘공유 버튼 → 앱 선택 → 붙여넣기’ 같은 단계를 밟아야 했는데 이때부터는 그냥 잡고 옮기면 끝이 되는 순간이 많아졌습니다[^Using Drag and Drop in iOS 11]. 드래그 앤 드롭이 만들었던 가장 큰 변화는 작업의 중심이 앱이 아니라 콘텐츠가 된다는 점이었습니다. 아이패드가 스플릿 뷰와 슬라이드 오버로 ‘앱 두 개’를 동시에 보여주는 건 가능했지만, 그 두 앱 사이에서 텍스트와 이미지와 파일이 오가는 방식은 여전히 불편했습니다. iOS 11 이후에는 사파리에서 이미지 몇 장을 집어서 메일로 끌어다 놓고, 다시 파일 앱에서 PDF를 집어 메일로 끌어다 놓는 식으로 흐름이 이어졌습니다[^iOS 11 brings drag-and-drop, windows and a file system to iPad]. 즉 아이패드가 한 앱씩 쓰는 기기에서 콘텐츠를 조합하는 기기로 변하는 구체적인 손맛이 생겼습니다.​

여기서 파일 앱이 결정적인 역할을 합니다. 애플은 iOS 11에서 파일 앱을 모든 파일을 한 곳에 모으는 중앙 공간으로 소개했고 로컬, iCloud Drive, 그리고 드랍박스 같은 외부 저장공간까지 한 화면에서 보게 했습니다[^iOS 11 brings powerful new features to iPhone and iPad this fall]. 파일 앱이 갖는 의미는 단순히 파일을 보여주는 앱 하나가 늘었다는 것이 아니라 아이패드가 ‘파일’을 사용자에게 정면으로 보여주기 시작했다는 점입니다. iOS 11 이전에도 파일은 있었지만 대체로 앱 안에 숨겨져 있거나 사용자에게 문서라는 형태로만 보였습니다. 파일 앱은 최소한 이 파일이 어디에 있고, 어떤 저장공간에 있고, 어떻게 옮길 수 있는지를 사용자 눈앞으로 끌어올렸습니다[^iOS 11: How to use the new Files app]. 이 시기에 아이패드 해비 사용자의 작업 파이프라인은 꽤 선명하게 정리됩니다. 글을 쓰는 사람은 사파리에서 자료를 끌어와 문서에 붙이고 파일 앱에서 이미지를 끌어와 문서에 넣고 메일로 결과물을 보내는 흐름을 아이패드 하나로 만들 수 있게 됐습니다. 자료 정리 습관도 바뀌었습니다. 예전에는 앱별로 파일이 흩어져 있어 정리하는 의미가 약했지만 파일 앱이 생기면서 폴더를 먼저 만들고 작업 파일을 모으는 방식이 가능해졌습니다[^iOS 11 brings drag-and-drop, windows and a file system to iPad]. iOS 11은 아이패드를 맥처럼 만들기 시작한 것처럼 보이지만, 실제로는 아이패드다운 방식으로 작업성을 끌어올린 성격이 더 강했습니다. 독은 터치 제스처로 부르는 도구였고 드래그 앤 드롭은 손가락으로 집어 옮기는 제스처였으며 파일 앱도 맥의 파인더처럼 무한히 자유로운 세계가 아니라 아이패드의 구조 안에서 ‘보이게’ 만든 도구였습니다. 이 차이가 나중에 스테이지 매니저 같은 윈도우 기반 경험이 들어왔을 때 왜 반발이 더 크게 나타나는지와 연결됩니다. iOS 11은 작업을 가능하게 만들었지만 동시에 사람들의 기대치를 올렸습니다. 이제 많은 사용자가 그럼 더 해도 되지 않나를 생각하게 됐고, 그 기대는 iPadOS의 독립으로 이어집니다.​

앞에서 iOS 11 for iPad가 독, 파일 앱, 드래그 앤 드롭으로 작업 문법을 만들었다고 말씀드렸습니다. 그런데 이 변화는 동시에 한 가지 사실을 드러냈습니다. 아이패드는 이미 아이폰과 같은 운영체제라는 틀 안에서는 더 이상 자연스럽게 성장하기 어려운 단계에 들어섰다는 점입니다. 그래서 2019년 iPadOS라는 이름이 등장합니다. 애플은 iPadOS를 iOS와 같은 기반 위에 만들되, 아이패드의 큰 화면과 활용 방식에 맞는 기능을 더하는 운영체제로 소개했습니다[^The new iPadOS powers unique experiences designed for iPad]. 이 시기의 변화는 아이패드가 맥처럼 된다라기보다 아이패드만의 방향을 인정받는다에 더 가까웠습니다. 홈 화면은 위젯을 더 적극적으로 보여주는 방향으로 바뀌었고 오늘 보기 위젯을 홈 화면에 고정해 정보가 한눈에 보이게 만들었습니다. 아이패드 해비 사용자에게 이 변화가 의미 있었던 이유는 단순합니다. 작업을 시작하기 전에 ‘오늘 할 일’과 ‘현재 상태’를 보는 시간이 줄어들었기 때문입니다. 기기를 켜는 순간에 일정, 메모, 날씨, 배터리 같은 정보가 보이면, 그만큼 작업으로 진입하는 단계가 줄어듭니다.​ 멀티태스킹도 한 단계 확장됩니다. iPadOS는 여러 개의 윈도우를 말하기 시작합니다. 같은 앱을 두 개 윈도우로 띄우고 그 두 윈도우를 스플릿 뷰로 나란히 놓는 흐름이 가능해졌습니다. 이 변화는 겉으로는 작아 보이지만 실제로는 아이패드 작업 흐름을 크게 바꿉니다. 예를 들어 사파리 윈도우를 두 개 열어 한쪽에는 참고 자료를, 다른 쪽에는 문서 도구를 띄워놓는 식의 동일 앱 멀티 윈도우 작업이 가능해지면서 예전처럼 앱을 여러 개 왔다 갔다 할 필요가 줄었습니다. 사파리는 iPadOS 13에서 데스크탑급 브라우징을 지원하며, 기본적으로 데스크탑 사이트를 보여주는 방향으로 바뀌었습니다[^Safari on iPadOS 13: The best new features]. 이 변화는 아이패드가 ‘웹 중심 작업’을 더 자주 맡게 되는 계기가 됩니다. 예전에는 웹에서 불편했던 작업이 아이패드에서도 그냥 할 수 있게 되면 사용자는 더 많이 아이패드를 꺼내게 됩니다.​ 또 하나 중요한 흐름은 애플펜슬 중심 작업의 확대입니다. iPadOS 14에서 스크리블이 도입되며, 텍스트 입력이 필요한 거의 모든 곳에서 애플펜슬로 글씨를 쓰면 곧바로 텍스트로 바뀌는 방식이 들어왔습니다[^iPadOS 14 introduces new features designed specifically for iPad]. 이 기능은 타이핑이 불편한 상황에서도 아이패드로 작업을 계속할 수 있게 해 준다는 점에서 아이패드다운 생산성을 밀어줬습니다. 키보드를 꺼내기 어려운 자리에서 검색창에 손글씨로 검색하고, 메신저에 손글씨로 답장하고 주소를 손글씨로 입력하는 흐름이 자연스러워졌습니다.

하지만 2019-2021년에 멀티태스킹이 커지면서, 아이패드가 늘 안고 있던 문제가 본격적으로 드러나기 시작합니다. 멀티태스킹이 강해질수록 어떻게 쓰는지가 점점 더 숨겨졌고 그 결과 ‘기능이 있는데도 못 쓰는 사람’이 늘어나는 문제가 나타났습니다. 이 문제는 iPadOS 15에서 애플이 직접 인정하듯 다루게 됩니다. iPadOS 15는 멀티태스킹을 더 쉽게 발견하게 만들기 위해, 화면 상단에 점 세 개 버튼을 넣고 그 버튼을 누르면 스플릿 뷰나 슬라이드 오버 같은 모드를 바로 선택하게 했습니다. 이 변화는 제스처 기반 인터페이스는 발견성과 기억성에서 문제가 생긴다는 지적을 전제로 하고 있습니다[^iPadOS 15 Finally Makes Multitasking Discoverable]. 흥미로운 점은, 이 개선이 동시에 또 다른 불편을 만들었다는 사실입니다. 점 세 개 버튼이 화면 상단에 생기면서, 애플펜슬로 화면 상단에 글씨를 쓰거나 제스처를 할 때 실수로 멀티태스킹 메뉴가 튀어나오는 문제가 생겼습니다. 화면 상단 텍스트 입력창 근처에서 스크리블을 쓰다가 점 세 개 버튼을 자꾸 건드려 작업이 끊긴다는 불만이 나왔습니다[^iOS 15 three dots/multitasking]. 이 사례는 뒤에서 더 크게 다룰 터치와 포인터의 충돌 문제를 이해하는 데 좋은 예시입니다. 눈에 보이는 버튼은 발견성은 높이지만, 그 버튼이 작업 영역을 침범하면 오히려 방해가 됩니다.​ 이 시기 커뮤니티 평가는 대체로 iPadOS라는 독립은 맞는 방향이라는 기대와 근본 제한은 그대로라는 불만이 동시에 커지는 형태로 정리됩니다. 홈 화면 위젯과 사파리 데스크탑급 브라우징, 스크리블 같은 변화는 아이패드를 더 아이패드답게 만들었습니다[^The new iPadOS powers unique experiences designed for iPad][^iPadOS 14 introduces new features designed specifically for iPad]. 반면 멀티태스킹은 기능이 늘어날수록 조작법이 복잡해지고, 실수로 기능이 튀어나오는 상황이 늘어 작업을 방해한다는 불만이 같이 커졌습니다[^iPadOS 15 Finally Makes Multitasking Discoverable].

iPadOS 16은 이 문제를 조금 더 쉽게 만드는 것이 아니라, 아예 다른 모델로 바꿔서 해결하려고 했습니다. 그 모델이 스테이지 매니저입니다. 스테이지 매니저의 핵심은 분명합니다. 이제 아이패드에서도 여러 앱을 겹치는 윈도우로 띄우고 윈도우 크기를 바꾸고 윈도우를 겹치게 놓고, 윈도우를 앱 그룹으로 묶어 작업 단위로 전환하게 만들겠다는 것입니다[^iPadOS 16 takes the versatility of iPad even further with powerful new productivity and collaboration features]. 애플이 공개적으로 내세운 도입 목표 역시 매우 직설적입니다. 겹치는 윈도우를 여러 개 배치하고, 독에서 앱을 불러와 함께 그룹으로 만들고, 외부 디스플레이를 단순 미러링이 아니라 확장 화면으로 써서 아이패드 화면과 외부 모니터에서 각각 여러 앱을 동시에 쓰게 한다는 방향이었습니다[^iPadOS 16 is available today]. 구체적으로는 아이패드 화면에 최대 4개 앱, 외부 디스플레이에 최대 4개 앱을 동시에 띄울 수 있다고 설명했고, 외부 디스플레이는 최대 6K 해상도까지 지원한다고도 했습니다. 이 목표만 보면, 많은 사람이 상상하던 아이패드로도 진짜 멀티태스킹이 된다에 가장 가까운 변화처럼 보입니다.​ 실제로 스테이지 매니저를 켰을 때 화면은 확실히 달라집니다. 현재 작업 중인 앱이 앞으로 나오고 나머지 열려 있는 앱은 왼쪽에 최근 앱 목록처럼 쌓이며 사용자는 윈도우를 옮기고 크기를 바꾸고 겹치게 배치할 수 있습니다. 또한 작업별로 앱을 그룹으로 묶어 전환할 수 있습니다[^Organize windows with Stage Manager on iPad]. 이 설명만 보면 아이패드가 맥을 닮았다는 말이 자연스럽게 나옵니다.​

하지만 스테이지 매니저가 아이패드 경험을 바꾼 방식은 기능의 추가만으로 설명하기 어렵습니다. 스플릿 뷰와 슬라이드 오버가 쌓아 올린 멀티태스킹은 아이패드 화면을 어떻게 나눌까에 가까웠습니다. 반면 스테이지 매니저는 이제부터는 사용자가 윈도우를 관리해야 한다로 중심을 옮겼습니다. 그 순간부터, 아이패드의 멀티태스킹은 단순히 ‘동시에 보인다’가 아니라 ‘정리한다’가 포함된 일이 됩니다. 이 변화가 왜 큰 갈등을 만들었는지, 커뮤니티 반응을 보면 바로 드러납니다. 스테이지 매니저는 자동 정리를 어느 정도 전제로 합니다. 윈도우를 마음대로 쌓아두는 대신 시스템이 어느 정도 보기 좋게 배치해 주고 사용자는 그 틀 안에서 작업 공간을 관리하는 방식입니다. 그런데 이 방식은 두 부류 모두를 불편하게 만들기 쉽습니다. 나는 내가 원하는 대로 어지럽혀도 된다는 데스크탑식 사용자에게는 제약처럼 느껴지고 나는 애초에 어지럽히는 걸 원하지 않는다는 아이패드식 사용자에게는 불필요한 복잡함처럼 느껴집니다. 이 모순은 iPadOS 16 출시 시점에 스테이지 매니저가 윈도우를 관리하는 문제를 해결한 게 아니라, 윈도우 대신 작업 공간 목록을 관리하게 만든 것이라는 비판으로 이어졌습니다[^Stage Manager in iPadOS 16: At the Intersection of Bugs, Missing Features, and Flawed Design]. 여기서 한 단계 더 중요한 비판이 나옵니다. 스테이지 매니저는 초보자에게 직관적이지 않았고, 파워 사용자에게도 충분히 유연하지 않았다는 평가가 동시에 나왔습니다. 작업 공간을 만들고 전환하는 방식이 자연스럽게 발견되지 않고 왼쪽 스트립과 앱 전환기에서도 윈도우를 직접 끌어 합쳐 작업 공간을 만드는 같은 직접 조작이 빠져 있다는 지적도 있었습니다. 이 문제는 아이패드가 원래 잘하던 부분 즉 직접 만져서 조작하는 느낌을 스테이지 매니저가 충분히 살리지 못했다는 뜻이기도 합니다.​

불편함은 안정성과 완성도 문제로 더 커졌습니다. iPadOS 16 공개 직후에는 스테이지 매니저가 과하게 설계됐고, 제대로 테스트되지 않았으며, 버그와 빠진 기능이 많다는 비판이 공개적으로 나왔습니다[^Stage Manager Criticized as 'Poorly Tested' Feature With 'Plethora of Bugs' Still Unfixed as iPadOS 16 Released]. 이 비판이 의미 있는 이유는, 단순히 불편하다가 아니라 아이패드 멀티태스킹의 방향을 바꿀 만큼 중요한 기능인데 이런 상태로 내면 안 된다는 문제의식이 깔려 있었기 때문입니다. 또 다른 형태의 불만은 아이패드 소프트웨어 전체와 따로 논다는 느낌입니다. 스테이지 매니저가 켜져 있을 때와 꺼져 있을 때의 멀티태스킹 경험이 너무 다르고 스테이지 매니저는 사실상 켜거나 끄는 ‘올 오어 낫싱’ 설정처럼 동작한다는 지적이 반복됐습니다. 이 지적은 iPadOS 17 시점에도 스테이지 매니저는 여전히 iPadOS의 다른 부분과 잘 섞이지 않는다는 평가로 이어졌습니다[^In iPadOS 17, Apple fixed the worst thing about Stage Manager]. 즉 스테이지 매니저는 아이패드의 기본 멀티태스킹을 자연스럽게 확장한 게 아니라 별도의 ‘다른 모드’를 추가한 느낌이 강했고, 이 점이 사용자 경험을 분열시키는 원인이 됐습니다.​ 그렇다고 모든 것이 실패였다고 말하기도 어렵습니다. iPadOS 17에서는 스테이지 매니저가 윈도우 배치를 너무 공격적으로 강제하던 문제를 완화하는 식으로 개선이 이뤄졌고, 윈도우를 움직일 때 더 자연스럽게 배치되도록 바뀌었다는 평가도 있습니다[^With iPadOS 17, Stage Manager Is (Finally) Moving in the Right Direction]. 즉, 애플도 초기 설계가 주던 마찰을 인정하고, 덜 간섭하는 방향으로 조금씩 바꾸고 있다는 뜻입니다. 그럼에도 iPadOS 16 이후의 가장 큰 결과는 분명합니다. 아이패드는 이제 두 가지 멀티태스킹 철학을 동시에 갖게 됐습니다. 하나는 스플릿 뷰와 슬라이드 오버가 만든 빠르고 단순한 아이패드식 멀티태스킹이고 다른 하나는 스테이지 매니저가 들여온 윈도우과 작업 공간 중심의 데스크탑식 멀티태스킹입니다. 그리고 이 둘은 서로 자연스럽게 이어지기보다, 사용자가 설정을 바꾸며 모드를 선택해야 하는 배타적 형태로 공존합니다[^Organize windows with Stage Manager on iPad].

이 다음 이어진 변화는 흥미롭게도 ‘더 맥처럼’이 아니라 ‘더 개인적인’ 방향으로 보입니다. iPadOS 18은 기능 목록만 보면 생산성도 포함하지만, 인터페이스의 표면에서 가장 크게 보이는 키워드는 개인화입니다. 홈 화면과 잠금 화면, 제어 센터를 사용자가 원하는 방식으로 배치하고 꾸밀 수 있게 하고 사진 앱은 구조 자체를 크게 바꾸며, 애플펜슬 중심 입력을 다시 전면에 세우는 변화가 같이 들어왔습니다[^iPadOS 18 업데이트에 관하여]. 먼저 홈 화면의 변화는 아이패드가 드디어 화면을 사용자가 통제하게 됐다는 성격이 강합니다. 아이패드 해비 사용자 입장에서 홈 화면은 보기 좋으라고 꾸미는 공간이라기보다 일감을 꺼내기 위한 작업대였습니다. 그런데 iPadOS 18에서는 앱 아이콘과 위젯을 더 자유롭게 배치하고 아이콘과 위젯 색을 한 톤으로 맞추는 식의 개인화가 가능해졌습니다[^iPad 홈 화면에서 앱 및 위젯 사용자화하기]. 이 변화는 꾸밈 이상으로 작업 시작의 마찰을 줄이는 쪽으로도 작동합니다. 가령 배경화면의 중요한 영역을 가리지 않게 아이콘을 피해서 놓고, 자주 쓰는 위젯을 손이 가는 위치에 고정하면 기기를 켰을 때 눈이 헤매는 시간이 줄어듭니다. 아이콘을 원하는 위치에 놓고 색조를 바꿀 수 있다는 설명도 이런 방향으로 정리할 수 있습니다[^How to perfect your home screen with iPadOS 18 customization options]. 제어 센터의 변화는 ‘개인화’가 단순한 꾸미기가 이상으로 시스템 조작의 구조를 바꾸는 수준으로 들어왔다는 점에서 중요합니다. iPadOS 18에서는 제어 센터에 그룹을 추가하고, 컨트롤의 크기를 조절하고, 여러 페이지처럼 넘겨가며 쓰는 형태가 가능해졌습니다. 또한 서드파티 앱 컨트롤을 제어 센터에 넣을 수 있게 하는 방향도 강조됐습니다[^How to customize Control Center on iPhone or iPad | Apple Support]. 이것은 아이패드 해비 사용자 관점에서 설정 앱을 열어 조작한다는 오래된 습관을 줄여주는 변화입니다. 작업 중에 화면을 바꾸지 않고도 더 많은 조작을 바로 처리할 수 있다면 멀티태스킹 자체를 늘리지 않아도 체감 생산성이 올라갑니다. 그래서 이 변화는 스테이지 매니저처럼 한 화면에 더 많이 띄우자가 아니라, 띄우지 않고도 더 많이 처리하자에 가깝습니다.

또 하나의 큰 흐름은 ‘앱 내 내비게이션’의 변화입니다. iPadOS 18에서는 탭 바를 새롭게 바꾸고, 탭 바가 필요할 때 사이드바처럼 바뀌는 구조를 제공해 앱 콘텐츠 영역을 더 넓게 쓰게 하는 방향이 들어왔습니다. 이 변화가 중요한 이유는 스테이지 매니저가 화면 전체를 윈도우 관리로 바꾸는 동안 앱 내부 UI는 오히려 복잡해져 화면을 더 잡아먹는 일이 자주 생겼기 때문입니다. 탭 바가 접히고 펼쳐지는 방식은 큰 화면에서 콘텐츠를 더 크게 보여주고 필요할 때만 조작을 드러내는 방식입니다. 이 방식은 아이패드 초기에 팝오버가 하던 역할과 닮아 있습니다. 즉, 큰 화면을 윈도우로 쪼개기보다, ‘내용을 크게’ 두고 ‘조작은 필요할 때만’ 보이게 하는 방향으로 돌아온 셈입니다[^Elevate your tab and sidebar experience in iPadOS]. iPadOS 18이 애플펜슬 경험을 다시 전면에 내세운 점도 의미가 큽니다. 애플은 iPadOS 18이 애플펜슬을 활용한 작업 방식을 새롭게 만들었다고 강조했고, 계산기 앱의 수학 메모처럼 손글씨 기반 상호작용을 핵심 요소로 소개했습니다[^iPadOS 18 업데이트에 관하여]. 이 흐름은 아이패드는 맥을 따라갈수록 좋은가라는 질문에 다른 답을 줍니다. 아이패드가 잘하는 것은 트랙패드로 윈도우를 움직이는 것이 아니라, 손글씨와 직접 조작을 중심으로 한 입력 경험이라는 메시지이기 때문입니다.​ 그렇다면 이 챕터의 주제인 ‘정체성 회복 시도’는 성공했을까요. iPadOS 18의 변화는 분명히 스테이지 매니저식 복잡도를 그대로 밀어붙이는 느낌과는 다릅니다. 홈 화면, 제어 센터, 앱 내 내비게이션, 애플펜슬 기능 모두가 사용자가 원하는 대로 바꾼다는 방향으로 모였습니다. 하지만 이 변화가 스테이지 매니저 논쟁을 끝내지는 못합니다. 왜냐하면 아이패드 해비 사용자가 겪는 불편의 핵심은 홈 화면이 예쁜지, 제어 센터가 편한지가 아니라, 멀티태스킹과 작업 흐름의 안정성, 그리고 ‘터치 중심 작업’이 방해받지 않는가에 있기 때문입니다. iPadOS 18이 표면적인 인터페이스의 만족을 높였더라도, 스테이지 매니저가 만들어낸 두 개의 철학이 공존하는 상태는 그대로 남아 있습니다.

앞에서 스플릿 뷰와 슬라이드 오버가 아이패드 해비 사용자의 작업 흐름을 주 앱에 집중하면서 보조 앱을 잠깐 끼워 넣는 방식으로 굳혔다고 말씀드렸습니다. 이 방식의 핵심은 멀티태스킹 자체가 목적이 아니라, 본작업을 끊지 않고 잡무를 빨리 처리하는 것이었습니다. 슬라이드 오버는 화면 위에 얇은 윈도우를 띄워 메시지 답장, 계산, 검색 같은 일을 빠르게 끝내고 다시 원래 화면으로 돌아가게 해주는 구조였고 이 구조는 주 앱을 방해하지 않는 보조 앱이라는 역할이 분명했습니다[^Multitasking On an iPad Is Tricky. This New Feature Has Simplified It]. 그런데 스테이지 매니저가 들어오면서, 이 보조 앱의 지위가 흔들리기 시작합니다. 스테이지 매니저를 켠 상태에서는 스플릿 뷰와 슬라이드 오버 같은 전통적인 멀티태스킹이 제공되지 않고, 대신 스테이지 매니저 방식의 윈도우 구성을 사용하게 됩니다[^Unable to find Split screen view on my iPad]. 즉 예전에는 슬라이드 오버로 해결하던 잠깐 끼워넣기가 스테이지 매니저에선 같은 규칙으로 동작하지 않거나 최소한 사용자가 기대하던 느낌으로 이어지지 않을 수 있습니다.​ 이 변화가 실제 작업을 어떻게 방해하는지, 가장 흔한 시나리오로 설명해 보겠습니다. 예전에는 문서 앱을 전체 화면으로 켜고 글을 쓰다가, 슬라이드 오버로 메시지를 불러 10초 만에 답장을 보내고, 다시 글쓰기 화면으로 돌아오는 흐름이 매우 자연스러웠습니다. 슬라이드 오버는 화면 위에 떠 있는 좁은 패널이라서 지금 내 작업은 계속 문서 작성이고 메시지는 잠깐 처리하는 일이라는 심리적 구조가 유지됐습니다[^Multitasking On an iPad Is Tricky. This New Feature Has Simplified It]. 그런데 스테이지 매니저 중심 환경에서는 메시지 앱이 보조 패널이 아니라 윈도우 관리 대상이 되기 쉽고 윈도우가 겹치고 포커스가 옮겨가면서 ‘본작업이 잠깐만 멈췄다가 이어지는 느낌’이 약해집니다.​ 이때부터 보조 앱 처리에 들어가는 시간이 늘어나는 이유는 보통 기능이 부족해서가 아니라 ‘정리 비용’이 생기기 때문입니다. 스테이지 매니저는 화면 왼쪽에 최근 앱을 쌓아두고 윈도우를 여러 개 겹쳐 놓는 모델이기 때문에, 보조 앱을 꺼내는 순간부터 사용자는 은근히 이 윈도우가 어디에 떠야 덜 가릴까를 신경 쓰게 됩니다. 화면에서 차지하는 UI가 커서 작업 공간이 줄어든다는 불만도 꾸준히 나옵니다[^5 Reasons I Don't Use Stage Manager on iPad or Mac]. 보조 앱은 원래 작고 빠르게 꺼냈다 넣는 것이 장점인데, 그 보조 앱을 쓰기 위해 화면이 좁아지고 정리할 것이 늘어나면 보조 앱의 존재 이유가 약해집니다.​

또 다른 문제는 슬라이드 오버는 슬라이드 오버만의 독립된 앱 모음이 있었다는 점입니다. 슬라이드 오버는 그 자체로 하나의 보조 앱 공간이어서, 주 앱이 무엇이든 상관없이 동일한 방식으로 꺼내 쓰는 느낌이 강했고, 필요한 보조 앱들을 그 공간에서 돌려 쓰는 흐름이 가능했습니다. 슬라이드 오버가 스테이지 매니저에는 없는 멀티태스킹 도구를 제공했습니다[^Compared: iPadOS 16 Stage Manager vs. iPadOS 15 Split View multitasking]. 아이패드 해비 사용자가 오래 쌓아온 보조 앱 스택은 여기서 깨지기 시작합니다. 보조 앱은 ‘한 번 켜두면 계속 보조로 남아 있어야’ 흐름이 빠른데 스테이지 매니저에서는 보조 앱도 윈도우가 되고, 윈도우은 그룹과 포커스의 규칙에 묶입니다.​ 이 문제를 더 크게 만드는 요인은 작업 공간을 만들고 유지하는 일이 생각보다 번거롭다는 점입니다. 실제로 스테이지 매니저에서는 앱 그룹을 만드는 과정이 너무 많은 일처럼 느껴지고 만들어 둔 구성이 쉽게 흐트러져 다시 세팅해야 한다는 불만이 나옵니다[^Stage Manager – Productivity Boost – With Some Problems]. 보조 앱 워크플로 관점에서는 이게 치명적입니다. 보조 앱은 매번 세팅하고 싶지 않은 것이기 때문입니다. 계산기, 번역, 메신저 같은 앱은 한 번 손에 익으면, 마치 도구 주머니처럼 언제든 같은 방식으로 나와야 합니다. 그런데 그 도구 주머니를 매번 다시 접었다 펴야 한다면, 사용자는 결국 보조 앱을 덜 쓰게 되고, 그 결과 아이패드의 장점이었던 가볍게 끼워 넣는 멀티태스킹이 약해집니다.​ 여기에 입력 포커스 문제가 겹치면 사용자는 더 쉽게 지칩니다. 스테이지 매니저를 많이 쓸수록 키 입력이 갑자기 먹지 않거나, 포커스가 이상한 곳에 걸려 앱이 입력을 받지 않는 현상이 생긴다는 경험도 공유됩니다[^Focus issues with Stage Manager on iPad #2092]. 보조 앱 워크플로는 짧은 시간에 처리하고 바로 복귀해야 하는데, 왜 입력이 안 되지 같은 문제를 한 번만 겪어도 흐름이 완전히 끊깁니다. 아이패드 해비 사용자의 작업은 긴 시간의 집중을 쌓아서 성과를 내는 형태가 많기 때문에 이런 끊김은 체감 손해가 큽니다.​

그래서 스테이지 매니저 이후에는 스플릿 뷰/슬라이드 오버가 더 낫다는 평가가 반복해서 등장합니다. 스테이지 매니저가 문제를 해결하기보다 복잡도를 늘렸고 기존 방식이 더 유연하다고 느낀다는 의견이 강하게 나타납니다[^Split View/Slide Over > Stage Manager]. 이러한 의견의 핵심은 단순합니다. 아이패드에서 멀티태스킹은 더 많이 띄우는 것보다 본작업을 덜 방해하는 것이 더 중요하다는 경험 규칙입니다.​ 스테이지 매니저가 쓸모없다는 것이 아닙니다. 다만 아이패드 해비 사용자가 오랫동안 쌓아온 슬라이드 오버식 치고 빠지기는 스테이지 매니저의 윈도우 중심 모델과 잘 맞지 않는 부분이 분명히 있고, 그 충돌이 작업 파이프라인을 느리게 만들 수 있다는 점입니다. 이제 이런 충돌이 특히 강하게 드러나는 상황, 즉 키보드와 마우스가 없는 터치 중심 환경에서 어떤 마찰이 생기는지 이어서 설명드리겠습니다.

이번에는 같은 문제를 더 근본적으로 살펴보겠습니다. 아이패드 해비 사용자 중에는 키보드와 트랙패드를 항상 들고 다니지 않는 분이 많습니다. 집에서는 소파에서, 학교에서는 책상 없이, 현장에서는 서서, 이동 중에는 무릎 위에서 작업합니다. 아이패드의 본질적 장점은 이런 환경에서 손가락만으로도 작업을 계속할 수 있다는 점이었습니다. 그런데 스테이지 매니저는 이 터치만 가능한 환경에서 자주 마찰을 만들고 그 마찰이 누적되면 작업 자체를 느리게 만듭니다. 스테이지 매니저의 기본 동작은 윈도우입니다. 윈도우를 움직이고 크기를 바꾸고, 필요하면 전체 화면으로 키우고, 다시 줄이고, 앱 그룹을 만든 뒤 전환합니다[^iPad에서 스테이지 매니저로 윈도우 정리하기]. 문제는 이 윈도우 관리가 터치에는 생각보다 친절하지 않다는 점입니다. 윈도우 크기를 바꾸려면 모서리를 잡아 드래그해야 하고, 윈도우를 움직이려면 윈도우의 상단을 잡아 끌어야 합니다. 이 조작은 마우스로 하면 쉬운 일처럼 보이지만, 손가락으로 하면 실패가 잦습니다. 손가락은 정확히 모서리 한 점을 잡기 어렵고, 특히 화면이 작거나 손이 가리면 더 어렵습니다. 그래서 터치만 가능한 환경에서 작업하는 사람은 내가 지금 작업을 하고 있는지, 윈도우를 정리하고 있는지가 자주 헛갈리게 됩니다.​ 이 불편함이 커지는 지점이 하나 더 있습니다. 아이패드에서 작업을 하는 사용자들은 앱을 ‘열면 바로 그 앱이 화면을 차지한다’는 기대가 강합니다. 그런데 스테이지 매니저는 앱을 열었을 때 그 앱이 단독으로 뜨지 않고 과거에 묶어둔 작업 공간으로 되돌아가며 여러 앱이 같이 떠 있는 상황이 생길 수 있습니다. 이런 동작은 사용자가 내가 지금 무엇을 열었는지를 다시 확인하게 만들고, 그 순간 집중이 끊깁니다. 실제로 스테이지 매니저가 이런 방식으로 동작할 때 사용자가 혼란을 느낀다는 경험이 정리된 글도 있습니다[^I tried using Stage Manager on my iPad Pro, and I failed miserably]. 터치만 가능한 환경에서는 이런 혼란이 더 크게 느껴집니다. 화면이 가까이 있고 손이 화면을 가리고 작은 윈도우들이 겹치면 찾아 눌러야 하는 대상이 늘어나기 때문입니다.​

게다가 스테이지 매니저는 터치 조작에서 실수 비용이 큽니다. 스플릿 뷰는 화면이 두 칸으로 나뉘고, 분할선만 움직이면 되었습니다. 반면 스테이지 매니저에서는 윈도우가 겹칠 수 있고 윈도우가 겹치면 뒤에 있는 콘텐츠는 터치할 수 없습니다. 그러면 사용자는 앞의 윈도우를 옮겨야 하고 옮기다 보면 크기가 바뀌거나 위치가 흐트러집니다. 작은 실수가 연쇄적으로 화면 전체를 어지럽히는 형태가 됩니다. 이런 상황이 조금만 쓰다 보면 복잡해진다는 평가로 이어집니다. 특히 11인치 아이패드 프로에서 스테이지 매니저가 복잡해지고, 마우스가 없으면 시간 낭비가 된다는 의견이 꾸준히 나옵니다[^Thoughts on stage manager for iPad Pro 11 & productivity]. 터치 환경에서 더 치명적인 문제는 ‘작업 영역의 경쟁’입니다. 아이패드에서 손가락은 화면의 내용 자체를 직접 누르는 도구입니다. 그런데 스테이지 매니저에서는 화면 안에 윈도우의 테두리, 윈도우의 모서리, 윈도우의 상단 조작부 같은 메타 UI가 늘어납니다. 사용자는 콘텐츠를 누르려다가 테두리를 누르고, 스크롤하려다가 윈도우를 움직이고, 뒤로 가려다가 윈도우 크기를 건드릴 수 있습니다. 이런 충돌은 한 번 생기면 사용자는 다음부터 손가락을 더 조심스럽게 쓰게 되고, 조심스럽게 쓸수록 아이패드의 강점이었던 ‘빠른 손맛’이 사라집니다. 이런 흐름은 결과적으로 아이패드는 결국 마우스가 있어야 쓸 수 있는 기기라는 인상을 강화합니다. 실제로 스테이지 매니저는 마우스나 트랙패드가 있을 때는 꽤 괜찮지만, 터치만으로는 불편하다는 말이 반복됩니다[^The iPad Pro and Stage Manager is a productivity failure]. 이 인상은 단순한 취향 문제가 아닙니다. 아이패드 해비 사용자의 일부는 아이패드를 마우스 없는 컴퓨터가 아니라 키보드가 없어도 되는 작업 도구로 쓰기 때문입니다. 작업 도중에 키보드를 꺼내는 것 자체가 귀찮거나 물리적으로 불가능한 환경도 많습니다. 그럴 때 아이패드는 독보적이었습니다. 그런데 스테이지 매니저가 아이패드의 멀티태스킹을 포인터 친화적 구조로 끌고 가면 아이패드는 그 독보성을 잃고, 맥을 흉내 내는 대신 맥보다 불편한 기기가 되기 쉽습니다.​ 결국 터치기반 생산성의 붕괴는 스테이지 매니저가 윈도우를 쓸 수 있게 만들었다는 사실 자체보다, 윈도우를 쓰기 위해 사용자가 감당해야 하는 조작 부담과 실수 비용이 커졌다는 점에서 옵니다. 여기서 말한 불편은 다음 주제와 바로 연결됩니다. 이제 단순히 터치가 불편하다는 수준을 넘어 스테이지 매니저가 만들어낸 정보 밀도 역설, 즉 화면을 더 잘 쓰려고 도입한 기능이 오히려 화면을 덜 쓰게 만드는 상황을 단독 화면 기준으로 정리해 보겠습니다.

가장 자주 나오는 불만은 쓸 수 없는 공간이 너무 많다는 것입니다. 스테이지 매니저를 켜면 왼쪽에 최근 앱 목록이 나타나고, 윈도우 주변에는 여백이 생기며, 윈도우를 여러 개 띄우면 겹침과 빈 공간이 동시에 늘어납니다. 이런 상태를 보고 이게 스플릿 뷰보다 왜 나은지 모르겠다는 반응이 나옵니다. 실제로 iPadOS 17에서 스테이지 매니저를 쓰면 화면의 좌우나 하단에 큰 빈 공간이 생기고, 그 결과 유튜브 같은 앱 레이아웃이 더 불편해져서 다시 스플릿 뷰로 돌아갔다는 경험이 공유됩니다[^Why is there so much unusable space in Stage Manager in iPadOS 17?]. 이 역설이 생기는 첫 번째 원인은 스테이지 매니저가 윈도우의 자유를 주는 대신 윈도우의 안전을 확보하려 하기 때문입니다. 전통적인 데스크탑 윈도우 시스템은 사용자가 원하면 윈도우를 화면 밖으로 반쯤 내보내거나, 극단적으로 작은 크기로 줄이거나 윈도우를 겹쳐서 뒤에 있는 윈도우를 완전히 가릴 수도 있습니다. 아이패드에서 이런 자유를 그대로 주면 많은 사람이 윈도우를 잃어버리거나 무엇이 어디 있는지 헛갈릴 수 있습니다. 그래서 스테이지 매니저는 겉으로는 자유로운 윈도우처럼 보여도 실제로는 윈도우가 놓일 수 있는 위치와 크기에 보이지 않는 규칙이 있고, 마음대로 무한 리사이즈가 되지 않는다는 설명이 나오기도 합니다[^iPad iOS 16 Stage Manager doesn't remember size and position of windows]. 이 규칙은 안전을 주는 대신, 화면을 끝까지 꽉 쓰고 싶은 사용자에게는 왜 여기로 못 가?라는 답답함으로 돌아옵니다.​ 두 번째 원인은 윈도우가 늘면 정보가 늘어야 하는데 아이패드 앱은 그렇게 설계되지 않은 경우가 많다는 점입니다. 아이패드 앱의 상당수는 전체 화면이나 스플릿 뷰 환경에 맞춰 만들어졌고, 윈도우가 작아지면 정보가 줄어드는 대신 UI가 뭉개지거나 터치 타깃이 지나치게 좁아지거나, 스크롤이 늘어나는 식으로 불편이 커집니다. 이때 사용자는 ‘창을 더 띄워서 생산성을 올리겠다’는 목표로 스테이지 매니저를 켰는데 실제로는 각 윈도우의 정보 밀도가 낮아져 오히려 화면에서 얻는 정보가 줄어들 수 있습니다. 그 결과 스테이지 매니저는 윈도우가 많지만 쓸모는 줄어든 화면을 만들기 쉽습니다. 세 번째 원인은 스테이지 매니저의 화면 구성 요소가 항상 보이는 것을 전제로 한다는 점입니다. 왼쪽에 최근 앱이 쌓여 있는 구조는 작업 공간을 빠르게 바꾸게 해주는 장점이 있지만 단독 화면에서는 그만큼 콘텐츠 공간이 줄어듭니다. 실제로 스테이지 매니저가 화면 공간을 너무 많이 먹고 눈에 거슬린다는 평가도 나옵니다[^5 Reasons I Don't Use Stage Manager on iPad or Mac]. 이 불만은 특히 11인치 같은 작은 화면에서 더 크게 느껴집니다. 아이패드의 화면은 노트북보다 작고 손가락으로 눌러야 하니 UI는 더 커야 하며 그 결과 콘텐츠 영역이 줄어드는 비용이 더 크게 다가옵니다.​

이 역설을 더 분명하게 만드는 비교 대상은 스플릿 뷰입니다. 스플릿 뷰는 화면을 두 칸으로 딱 나누고, 각 칸은 끝까지 꽉 채워집니다. 여백을 남기지 않고, 겹쳐서 가리지 않고 무엇이 어디 있는지 한눈에 들어옵니다. 그래서 같은 두 앱을 놓더라도 스테이지 매니저보다 스플릿 뷰가 정보 밀도가 높게 느껴질 때가 많습니다. 실제로 스테이지 매니저가 작은 화면에서 공간을 낭비한다고 느껴 스플릿 뷰와 슬라이드 오버가 더 낫다고 말하는 반응이 반복됩니다[^Split View/Slide Over > Stage Manager]. 이 반응은 단순 취향이 아니라 아이패드에서의 작업이 윈도우 개수가 아니라 한눈에 보이는 정보로 결정되는 경우가 많다는 경험에서 나옵니다.​ 애플도 이 문제를 모르는 것 같지는 않습니다. iPadOS 17에서 스테이지 매니저의 윈도우 배치가 더 덜 강제적이 되었고, 윈도우를 옮겼을 때 예전처럼 중앙으로 튕기듯 돌아가는 일이 줄었다는 평가가 나왔습니다[^In iPadOS 17, Apple fixed the worst thing about Stage Manager]. 또한 윈도우가 완전히 가려져 사라지는 문제를 막기 위해 뒤에 있는 윈도우의 가장자리가 살짝 보이게 만드는 식의 해결도 소개됩니다[^iPadOS 17 Review: A fitting stage, at last]. 이런 개선은 분명히 ‘창 기반 모델’을 계속 밀어붙이겠다는 의지로 읽힙니다. 하지만 단독 화면에서의 역설은 여전히 남습니다. 안전을 위해 넣은 규칙과 UI가 결국 화면을 덜 쓰게 만들고 그 결과 많은 사용자는 차라리 예전 방식이 더 빠르다로 돌아가게 됩니다.​ 이러한 정보 밀도 역설은 다음 문제로 이어집니다. 화면에서 정보가 덜 보이면 사용자는 더 자주 윈도우를 정리하고 더 자주 전환하고 더 자주 화면을 만지게 됩니다. 즉 ‘본업’이 아니라 ‘정리’가 늘어납니다. 이어서 이 현상을 한 단계 더 확장해서, 스테이지 매니저 이후 아이패드에서 윈도우 관리 자체가 작업이 되는 메타 작업이 어떻게 늘어나는지 자세히 설명하겠습니다.

다음 단계에서 나타나는 현상은 더 직접적입니다. 사용자는 본업을 하는 시간이 아니라 윈도우를 정리하고 작업 공간을 유지하는 시간 즉 메타 작업을 늘리게 됩니다. 이 메타 작업은 눈에 잘 띄지 않지만, 아이패드를 핵심 도구로 쓰는 사람에게는 하루 전체 생산성을 갉아먹는 형태로 쌓입니다. 스테이지 매니저는 윈도우를 보기 좋게 정리해 준다는 약속을 갖고 등장했습니다. 실제로 애플은 스테이지 매니저가 윈도우를 앞으로 가져오고 나머지를 왼쪽에 최근 앱 목록으로 정리해 멀티태스킹을 쉽게 만든다고 설명합니다. 또한 특정 작업이나 프로젝트를 위해 윈도우를 그룹으로 묶어 둘 수 있다고도 안내합니다[^iPad에서 스테이지 매니저로 윈도우 정리하기]. 즉 정리를 덜 하게 해 주는 기능처럼 보입니다.​ 그런데 실제 사용에서는 정리 부담이 줄어들지 않고 성격이 바뀌는 경우가 많습니다. 예전에는 스플릿 뷰와 슬라이드 오버로 화면에 뜬 앱 조합이 곧 작업 상태였습니다. 화면이 나뉘면 그게 끝이었고, 사용자는 앱을 닫거나 전환하면 자연스럽게 다음 작업으로 넘어갈 수 있었습니다. 반면 스테이지 매니저에서는 작업 공간이 하나의 단위가 됩니다. 사용자는 윈도우를 묶어 작업 공간을 만들고 그 작업 공간을 유지하며 다시 불러오고 마음대로 꼬이지 않게 관리해야 합니다. 스테이지 매니저는 윈도우 관리 문제를 해결한 것이 아니라 윈도우 대신 작업 공간 목록을 관리하는 문제로 바꿨다는 비판이 나오는 이유가 여기에 있습니다[^Stage Manager in iPadOS 16: At the Intersection of Bugs, Missing Features, and Flawed Design].

메타 작업이 늘어나는 첫 번째 이유는 시스템이 윈도우를 알아서 움직인다는 점입니다. 스테이지 매니저는 사용자가 새 앱을 열거나 특정 윈도우를 앞으로 가져오거나 작업 공간을 바꾸는 과정에서 윈도우가 자동으로 재배치되는 경우가 있습니다. 이 자동 재배치는 사용자가 복잡한 배치를 고민하지 않게 하려는 목적으로 설계됐다고 설명됩니다[^Stage Manager in iPadOS 16: At the Intersection of Bugs, Missing Features, and Flawed Design]. 하지만 아이패드 해비 사용자의 관점에서는 이 자동이 종종 문제를 만듭니다. 한 번 손에 익은 배치가 작업의 일부가 되는데 그 배치가 사용자의 의도와 다르게 바뀌면 내 작업 환경이 망가졌다는 느낌이 강하게 듭니다. 그리고 그 순간부터 사용자는 본업 대신 복구 작업을 하게 됩니다. 윈도우를 다시 옮기고 크기를 다시 맞추고 가려진 윈도우를 찾아 앞으로 꺼내야 합니다.​ 두 번째 이유는 작업 공간의 내부를 한눈에 파악하기가 어렵다는 점입니다. 스테이지 매니저는 왼쪽에 최근 앱 목록을 보여주지만, 그 목록은 ‘지금 이 작업 공간에 무엇이 들어 있는지’를 명확하게 보여주지 못할 때가 있습니다. 겹치는 윈도우가 뒤에 숨어 있으면 더 그렇습니다. 이 문제는 지금 이 작업 공간에 어떤 윈도우가 들어 있는지 확인하려면 직접 하나씩 돌려봐야 한다는 불편으로 이어집니다. 이런 구조는 특히 네 개까지 윈도우를 띄울 수 있을 때 더 크게 느껴집니다. 스테이지 매니저는 최대 네 개 윈도우를 지원하지만 네 개를 제대로 그리드처럼 배치해 한눈에 보이게 만드는 것도 쉽지 않습니다[^Stage Manager in iPadOS 16: At the Intersection of Bugs, Missing Features, and Flawed Design].

세 번째 이유는 그룹 만들기 자체가 노동이 되기 쉽다는 점입니다. 애플은 스테이지 매니저에서 앱 그룹을 만들기 위해 최근 앱 목록에서 윈도우를 끌어오거나 독에서 앱을 끌어와 작업 공간에 추가하라고 안내합니다[^iPad에서 스테이지 매니저로 윈도우 정리하기]. 이 방식은 겉으로는 단순해 보이지만 실제로는 사용자가 원하는 조합을 만들기 위해 윈도우를 빼고 넣는 과정을 여러 번 반복하게 만들 수 있습니다. 특히 이 윈도우만 현재 작업 공간에 추가하고 싶다 같은 섬세한 의도는 매끄럽게 지원되지 않는다는 지적이 나옵니다. 이 때문에 작업 공간을 만드는 과정이 번거롭고, 결과적으로는 작업 공간을 만들기보다 그냥 앱 전환으로 버티게 되는 경우가 생깁다[^Stage Manager in iPadOS 16: At the Intersection of Bugs, Missing Features, and Flawed Design]. 네 번째 이유는 기억하지 못하는 UI입니다. 사용자는 윈도우의 크기와 위치를 한 번 맞춰두면 다음에도 그대로 나오길 기대합니다. 하지만 스테이지 매니저가 윈도우의 크기와 위치를 일관되게 기억하지 못해 계속 다시 맞춰야 한다는 경험이 실제로 보고됩니다[^iPad iOS 16 Stage Manager doesn't remember size and position of windows]. 이 문제는 단순히 ‘불편하다’ 정도로 끝나지 않습니다. 아이패드 해비 사용자는 작업 환경을 템플릿처럼 만들어 반복합니다. 예를 들어 왼쪽에 자료, 오른쪽에 편집, 아래쪽에 메신저 같은 배치가 손에 익으면 이 상태가 곧 속도가 됩니다. 그런데 그 배치가 매번 풀린다면 매번 처음부터 세팅해야 하고, 그 시간이 쌓이면 스테이지 매니저는 생산성 기능이 아니라 생산성 세금이 됩니다.​

이 메타 작업이 더 큰 문제로 번지는 이유는 아이패드 사용 환경과 연결됩니다. 맥은 책상 위에서 쓰는 시간이 길고 키보드 단축키와 마우스 정밀 조작으로 윈도우를 관리하는 비용이 상대적으로 낮습니다. 하지만 아이패드는 소파, 침대, 현장처럼 손가락으로 대충 처리하고 싶은 환경에서 강했던 기기입니다. 이런 환경에서 윈도우 관리가 늘어나면 기기의 강점이 약점으로 바뀝니다. 아이패드를 꺼냈는데 정리만 하다 끝났다는 느낌을 받기 쉽습니다. 스테이지 매니저는 본래 정리 부담을 줄이겠다는 의도로 설계된 흔적이 강하지만 실제로는 사용자에게 새로운 종류의 정리 부담을 맡기는 방식으로 작동할 수 있습니다. 그리고 그 부담은 특히 아이패드를 오래 쓰며 자기만의 흐름을 만든 해비 사용자에게 더 크게 느껴집니다. 이어서 이 메타 작업이 왜 더 강한 배신감으로 이어지는지 즉 맥처럼 보이는데 맥처럼 안 된다는 기대-현실의 충돌을 중심으로 설명드리겠습니다.

앞서 스테이지 매니저가 메타 작업을 늘려 정리 자체가 작업이 되는 현상을 만든다고 말씀드렸습니다. 이 현상은 단순한 귀찮음에서 끝나지 않습니다. 스테이지 매니저는 겉모습만 보면 맥과 매우 비슷한 방향의 경험을 아이패드에 가져옵니다. 윈도우가 겹치고, 윈도우 크기를 바꾸고, 작업 공간을 바꾸고 외부 모니터를 붙여 데스크탑 환경을 꾸밀 수 있다고 주장합니다[^iPadOS 16 takes the versatility of iPad even further with powerful new productivity and collaboration features]. 그래서 자연스럽게 이 정도면 맥처럼 돌아가겠지라는 기대를 갖습니다. 그런데 실제로 써 보면 그 기대가 맞지 않는 순간이 계속 생기고 그때의 실망감은 단순 불편보다 훨씬 크게 느껴집니다. ‘배신감’이라는 표현이 나오는 이유는 대개 이 기대-현실의 간격 때문입니다.​ 가장 대표적인 간격은 작업 공간을 저장하는 방식에서 드러납니다. 맥을 쓰는 사람은 윈도우 배치를 한 번 만들어두면, 다음에도 비슷한 상태로 돌아오길 기대합니다. 물론 맥도 완벽하지 않지만 최소한 윈도우를 자유롭게 배치하고 필요하면 단축키나 앱 기능으로 반복해서 재현할 수 있습니다. 아이패드의 스테이지 매니저는 ‘작업 공간’이라는 개념을 제시했지만 자주 쓰는 조합을 버튼 한 번으로 복원하는 프리셋 같은 기능이 부족합니다[^Not an iPad Pro Review: Why iPadOS Still Doesn’t Get the Basics Right]. 결국 사용자는 매번 윈도우를 열고 끌어다 놓고 크기를 맞추고 겹치지 않게 조절하는 과정을 반복하게 됩니다. 작업 공간이라는 말을 써 놓고도 작업 공간을 매번 수동으로 재건축해야 한다면 이 기능은 맥 같은 편안함을 주지 못합니다.​

두 번째 간격은 입력 포커스와 안정성에서 나타납니다. 맥에서는 키보드 입력이 어느 윈도우로 들어갈지 비교적 예측 가능하고, 전환도 안정적입니다. 반면 아이패드에서는 스테이지 매니저에서 엉뚱한 윈도우가 활성화돼 키 입력을 받는다 같은 문제가 지적됩니다[^Not an iPad Pro Review: Why iPadOS Still Doesn’t Get the Basics Right]. 이런 문제는 본업의 속도를 떨어뜨릴 뿐 아니라 이건 왜 이래?라는 불신을 만들고 불신이 생기면 더 자주 화면을 확인하며 작업을 멈추게 됩니다. 아이패드 해비 사용자에게 이 멈춤은 특히 치명적입니다. 아이패드는 원래 흐름이 빠른 기기였고 흐름이 빠르다는 믿음이 깨지면 기기의 가치가 크게 줄어듭니다.​ 세 번째 간격은 백그라운드 작업에 대한 기대에서 생깁니다. 맥에서는 대용량 파일 복사, 다운로드, 인코딩 같은 작업을 백그라운드로 돌려놓고 다른 일을 해도 되는 경우가 많습니다. 아이패드는 이 부분에서 여전히 제한이 강하고 작업이 백그라운드로 제대로 지속될 것이라는 신뢰가 약하다는 불만이 반복됩니다. iPadOS에서는 백그라운드에서 오래 걸리는 작업을 하는 앱 자체가 만들기 어렵다는 지적이 나오고 클립보드 매니저나 인코딩 유틸 같은 종류의 앱이 존재하기 힘듭니다[^Not an iPad Pro Review: Why iPadOS Still Doesn’t Get the Basics Right]. 스테이지 매니저가 윈도우를 ‘컴퓨터처럼’ 보이게 만들수록 사용자는 이제 컴퓨터처럼 오래 걸리는 작업도 맡길 수 있겠다고 기대하기 쉬운데 그 기대가 계속 깨지면 실망은 더 커집니다.​

네 번째 간격은 파일 앱이 파인더가 아니라는 사실에서 옵니다. iOS 11에서 파일 앱이 등장하며 아이패드는 파일을 사용자 앞에 꺼내기 시작했지만 파인더처럼 세밀한 관리와 자동화가 가능한 수준까지는 오지 못했습니다. 예를 들어 파일 전송 속도를 보여주지 않아서 큰 파일을 옮길 때 정말 옮겨지는지 불안해진다는 문제, 파인더의 스마트 폴더 같은 기능이 없다는 문제, 빠른 동작을 사용자 마음대로 확장하기 어렵다는 문제 등이 지적됩니다[^Not an iPad Pro Review: Why iPadOS Still Doesn’t Get the Basics Right]. 스테이지 매니저가 윈도우 경험을 강화하면 파일 작업도 자연스럽게 늘어납니다. 그런데 그 파일 작업에서 맥만큼의 신뢰와 도구성이 나오지 않으면 겉만 맥 같다는 인상이 강해집니다.​ 다섯 번째 간격은 외부 모니터 환경에서 더 노골적으로 드러납니다. 아이패드에 외부 모니터를 붙여 ‘책상용 컴퓨터’처럼 쓰려면, 사용자 입장에서는 아이패드를 덮고도 모니터만으로 작업이 이어지는 클램쉘 같은 사용을 기대하기 쉽습니다. 하지만 아이패드는 외부 모니터를 써도 기기 화면을 켜둬야 하고, 어떤 기능은 외부 모니터에서 바로 접근하기 어렵다는 불만이 나옵니다. 특히 제어 센터 같은 핵심 조작이 보조 모니터에서 완전히 자연스럽게 처리되지 않습니다. 이런 문제는 외부 모니터까지 붙였는데 여전히 아이패드를 옆에 켜 두고 만져야 한다는 결론으로 이어지고 결국 ‘책상 위 컴퓨터’ 역할을 기대했던 사람에게는 큰 실망이 됩니다.​

이 모든 간격을 한 문장으로 묶으면 이렇게 됩니다. 스테이지 매니저는 아이패드를 맥처럼 보이게 만들었지만 아이패드가 맥처럼 동작하도록 만드는 데 필요한 기반 즉 안정적 포커스, 반복 가능한 작업 공간, 충분한 백그라운드 작업, 성숙한 파일 관리, 외부 모니터 중심 사용성 같은 부분은 그대로 남겨두었습니다. 그래서 사용자는 맥 같은 UI를 쓸수록 맥의 결핍을 더 강하게 느끼는 이상한 상황에 들어갑니다. 그 결과 아이패드 해비 사용자 중 일부는 차라리 스테이지 매니저를 끄고 예전 방식으로 돌아가고 또 다른 일부는 그럴 바엔 맥북이 낫다로 결론을 내리게 됩니다. 이어서 이 기대-현실의 충돌을 단순한 실망이 아니라 실제 작업 방식의 변화로 연결해 보겠습니다. 스테이지 매니저와 맥OS식 경험 도입이 기존 아이패드 해비 사용자들에게 어떤 종류의 ‘업무 손상’을 만들었는지, 특히 ‘터치와 포인터’가 함께 존재하는 상태에서 어떤 충돌이 생기는지부터 이어서 설명드리겠습니다.

앞서 맥처럼 보이는데 맥처럼 안 된다는 기대-현실 충돌을 소개했습니다. 이번 장에서는 그 충돌이 왜 단순한 취향이 아니라 입력 방식의 물리적 차이에서 시작된 구조적 문제인지 설명하겠습니다. 터치는 화면을 직접 누르는 방식이라서 손가락이 UI 위를 가립니다[^Fitts's Law and Its Applications in UX]. 그래서 터치 인터페이스는 ‘정확히 누르기’보다 ‘대충 눌러도 맞게’ 설계하는 쪽이 안전합니다. 애플이 버튼과 컨트롤의 최소 터치 영역을 44x44pt로 권장하는 이유도 여기에 있습니다[^Buttons]. 이 기준은 단순한 디자인 취향이 아니라 손가락으로 눌렀을 때 실수를 줄이는 최소 크기라는 뜻입니다. 반대로 포인터는 손가락처럼 화면을 가리지 않고, 매우 작은 대상도 정밀하게 클릭할 수 있습니다[^Fitts's Law and Its Applications in UX]. 그래서 포인터 중심 UI는 작은 버튼, 얇은 스크롤바, 촘촘한 메뉴처럼 정보를 많이 담는 방식이 잘 맞습니다. 같은 화면이라도 포인터는 ‘정밀도’를 무기로 삼고, 터치는 ‘큰 타깃과 단순한 제스처’를 무기로 삼습니다. 문제는 아이패드가 이 두 방식을 동시에 만족시키려 하면서 생깁니다. iPadOS는 포인터를 단순한 마우스 커서로 두지 않고, 버튼에 달라붙고 형태가 변하는 방식으로 설계해 터치 UI에서도 포인터가 자연스럽게 느껴지게 만들었습니다[^Design for the iPadOS pointer]. 애플은 이를 위해 포인터의 보이는 위치와 실제 위치를 다르게 두고 버튼 가장자리에 걸리면 부드럽게 빨려 들어가듯 보이게 만드는 식의 설명까지 제공합니다. 또한 버튼 사이에 ‘빈틈’이 있으면 포인터가 다시 동그란 모양으로 변하는 등 불필요한 애니메이션이 생기니 히트 영역을 이어서 설계하라고 권합니다[^Revisit WWDC25]. 이 접근은 포인터 자체의 체감 품질을 높이는 데는 도움이 됩니다. 하지만 스테이지 매니저처럼 윈도우가 들어오면 상황이 달라집니다[^iPad에서 스테이지 매니저로 윈도우 정리하기]. 윈도우의 테두리, 모서리 리사이즈 핸들, 겹치는 레이어 같은 요소는 기본적으로 포인터 환경에서 더 자연스럽게 느껴지는 도구이기 때문입니다. 이때 UI가 포인터 친화적으로 작아지면 터치가 불편해지고, 터치 친화적으로 커지면 포인터 관점에서는 화면 공간을 낭비하게 됩니다[^Buttons].

특히 윈도우 크기 조절은 이 충돌이 가장 선명하게 드러나는 지점입니다. 스테이지 매니저는 윈도우를 옮기고 크기를 바꿀 수 있다고 안내하지만 그 조작의 기본은 윈도우를 잡고 드래그하는 방식입니다. 포인터로는 작은 모서리를 잡아도 되지만 손가락으로 모서리를 잡는 순간 손가락이 화면을 가리고, 목표 지점을 정확히 보기 어렵습니다. 그래서 터치 환경에서는 윈도우를 키우려다 윈도우를 옮기고 윈도우를 옮기려다 윈도우를 키우는 식의 실수 비용을 더 자주 내게 됩니다. 여기에 호버 중심 상호작용이 섞이면 혼란은 더 커집니다. 포인터 환경에서는 커서를 올렸을 때만 버튼이 강조되거나 추가 옵션이 나오는 패턴이 흔합니다[^Design for the iPadOS pointer]. 하지만 터치 환경에는 호버가 없어서 같은 UI를 두 입력 방식으로 모두 만족시키려면 터치 사용자에게는 다른 단서를 제공해야 합니다. 이 단서를 잘 못 맞추면 포인터 사용자에게는 기능이 숨겨져 답답하고 터치 사용자에게는 버튼이 늘어나 화면이 더 복잡해집니다. 결국 아이패드에서 터치와 포인터를 둘 다 지원한다는 말은, 단순히 입력 장치가 두 개라는 뜻이 아닙니다. 한 화면 안에서 ‘큰 타깃의 단순한 조작’과 ‘작은 타깃의 정밀한 조작’을 동시에 설계해야 한다는 뜻이고 이 균형이 깨질 때 사용자는 기능이 늘어도 편해지지 않는다고 느낍니다. 스테이지 매니저 이후 아이패드 해비 사용자가 느끼는 피로는 여기서 시작되는 경우가 많습니다. 이제 이 물리학적 충돌이 발견성 문제와 결합하면서 멀티태스킹이 점점 ‘배워야만 쓸 수 있는 기능’으로 변해간 과정을 이어서 설명드리겠습니다.

방금 터치와 포인터의 물리적 차이 때문에 한 화면에서 두 입력 방식을 모두 만족시키기 어렵다고 말씀드렸습니다. 이 문제는 스테이지 매니저 같은 윈도우 기반 멀티태스킹에서 더 커지는데 그 이유는 단순합니다. 윈도우 기반 멀티태스킹은 사용자가 알아야 할 규칙이 많기 때문입니다. 그리고 그 규칙은 자연스럽게 발견되기 어렵습니다. 아이패드의 멀티태스킹은 오랫동안 제스처 중심이었습니다. 스플릿 뷰와 슬라이드 오버가 강력했지만, 그 기능이 화면에 항상 보이는 버튼으로 안내되지는 않았습니다. 그 결과 많은 사용자는 멀티태스킹이 되는지조차 모른 채 아이패드를 쓰기도 했습니다. 제스처 기반 인터페이스는 발견성과 기억성에서 문제가 생기기 쉽다는 지적이 꾸준히 나옵니다[^iPadOS 15 Finally Makes Multitasking Discoverable]. 이 문제는 iPadOS가 독립하며 멀티태스킹을 더 밀어붙인 2019~2021 기간에 특히 커졌고 결국 iPadOS 15에서 애플은 점 세 개 버튼을 화면 상단에 넣어 멀티태스킹 메뉴를 노출하는 방식으로 방향을 바꿨습니다. 이 변화는 분명히 장점이 있습니다. 제스처는 모르고도 살 수 있지만, 알면 훨씬 편합니다. 그런데 제스처만으로 핵심 기능을 숨겨두면 모르는 사람은 영원히 모르게 됩니다. 점 세 개 버튼은 그 문제를 정면으로 해결합니다. 이제 사용자는 이 앱을 스플릿 뷰로 만들지, 슬라이드 오버로 만들지를 버튼에서 바로 고를 수 있습니다. 실제로 iPadOS 15의 변화는 제스처를 외우지 않아도 멀티태스킹을 시작할 수 있다는 점에서 큰 전환이었습니다.​ 하지만 여기서부터 새로운 비용이 생깁니다. 점 세 개 버튼은 발견성을 높이지만 그 버튼이 화면 상단 한가운데에 상시로 존재하면서 작업을 방해하는 상황이 생깁니다. 특히 애플펜슬을 많이 쓰는 사람은 화면 상단을 자주 건드리게 되고 그 과정에서 멀티태스킹 메뉴가 튀어나와 흐름이 끊깁니다[^iOS 15 three dots/multitasking]. 즉 보이게 만들었다는 해결이 어떤 사용자에게는 거슬리게 만들었다로 돌아옵니다. 이 시점부터 아이패드 멀티태스킹은 ‘초보자에게는 더 친절하지만 숙련 사용자에게는 더 성가신’ 성격을 갖기 시작합니다.​

스테이지 매니저는 이 문제를 더 복잡하게 만듭니다. 스테이지 매니저는 윈도우를 겹치게 놓고, 작업 공간을 만들고, 왼쪽에 최근 앱 목록을 두고 윈도우를 끌어 합쳐 그룹을 만들고 다시 떼어내고 외부 모니터까지 확장하는 방식입니다[^iPad에서 스테이지 매니저로 윈도우 정리하기]. 이는 단순히 기능이 증가한 것이 이상으로 사용자가 머릿속에 새로운 작업 모델을 만들어야 한다는 뜻입니다. 그런데 아이패드의 인터페이스는 오랫동안 눈에 보이는 모델이 아니라 손에 익는 모델로 발전해 왔습니다. 손가락 제스처는 일단 익히면 빠르고 익힌 뒤에는 머리로 생각하지 않고 몸으로 합니다. 반면 윈도우 기반 작업은 머리로 규칙을 이해하고, 상황마다 판단하는 시간이 늘어납니다.​ 이 때문에 발견성을 높이려면 UI가 더 많이 보이게 되고 UI가 더 많이 보이면 화면은 더 복잡해집니다. 반대로 UI를 숨기면 화면은 단순해지지만 기능은 다시 발견하기 어려워집니다. 아이패드는 원래 이 딜레마에서 기능을 숨기되 익히면 빠르게를 택해 왔습니다. 그런데 iPadOS 15의 점 세 개 버튼과 스테이지 매니저는 이 딜레마를 버튼과 모드로 해결하려고 합니다. 그 결과 아이패드는 제스처 숙련도에 더해, 버튼 조작과 모드 전환 숙련도까지 요구하는 방향으로 가게 됩니다. 이 과정에서 또 하나의 문제가 생깁니다. 조작이 섬세해질수록 약간의 차이가 큰 결과 차이를 만들기 시작합니다. 예를 들어 어떤 제스처는 손가락을 끌다가 잠깐 멈추느냐 끝까지 밀어버리느냐에 따라 결과가 달라지고 사용자는 정확한 타이밍을 몸으로 익혀야 합니다. 이런 문제는 발견했을 때는 좋지만 발견하기는 어렵고, 변형이 많아 헷갈린다는 식으로 지적됩니다. 숙련자가 되기까지 들어가는 비용이 계속 커지는 것입니다.​

여기에 스테이지 매니저의 작업 공간 개념이 더해지면 사용자는 이걸 켜야 하나 꺼야 하나부터 결정해야 합니다. 스플릿 뷰와 슬라이드 오버에 익숙한 사람은 기존 방식이 손에 붙어 있고 스테이지 매니저는 별도의 규칙을 다시 배워야 합니다. 이때 사용자는 하루 작업 중 일부를 학습과 적응에 쓰게 됩니다. 문제는 이 학습이 일회성으로 끝나지 않는다는 점입니다. iPadOS 버전이 바뀔 때마다 멀티태스킹 UI가 조금씩 바뀌고 어떤 요소는 위치가 바뀌거나 모양이 바뀌기도 합니다. 예를 들어 점 세 개 버튼이 어떤 버전에서는 보이지 않는다고 느끼는 사용자가 생기고, 버튼의 형태나 위치가 달라져 혼란이 생기기도 합니다[^Missing three dots for split-screen on iPad after software update]. 이런 변화는 한 번 배워서 평생 쓰는 숙련도를 어렵게 만듭니다.​ 결국 발견성을 높이기 위한 시도는 분명 필요했지만 그 결과 아이패드의 멀티태스킹은 단순한 제스처 숙련에서 모드, 버튼, 규칙, 예외까지 포함한 종합 숙련으로 변했습니다. 이 숙련도 비용은 특히 오랫동안 아이패드를 작업 도구로 써온 해비 사용자에게 크게 느껴집니다. 이들은 새로운 기능을 거부해서가 아니라 이미 완성해 둔 자기 흐름이 깨질 때 손해가 크기 때문입니다. 이제 이 숙련도 비용이 커지는 과정에서 왜 어떤 목소리는 과대 대표되고 어떤 목소리는 묻히는지 즉 커뮤니티 담론의 구조를 유튜브 중심의 맥OS화 요구라는 문제의식과 함께 이어서 설명하겠습니다.

앞서 멀티태스킹이 발견성을 얻는 대신 숙련도 비용을 키웠다고 말씀드렸습니다. 이 숙련도 비용이 커질수록 커뮤니티 안에서 어떤 요구가 더 크게 들리고 어떤 요구는 작게 들리는지도 달라집니다. 그리고 그 흐름이 아이패드를 맥처럼 만들어 달라는 요구를 점점 더 강하게 키워 왔다고 봅니다. 아이패드가 맥OS처럼 보이기를 바라는 목소리는 오래전부터 있었습니다. iOS 11이 독과 파일 앱과 드래그 앤 드롭을 가져오면서 아이패드가 본격적으로 작업 도구가 되자 이 정도면 맥OS만 얹으면 완성이라는 상상은 더 흔해졌습니다. 그 뒤 M1 아이패드 프로 같은 제품이 나오며 하드웨어가 맥북과 비슷해지자 이 상상은 단순한 바람이 아니라 당연한 요구처럼 굳어지기 시작했습니다. 아이패드가 노트북급 칩을 넣고도 노트북처럼 못 쓰는 모습은 ‘소프트웨어가 발목을 잡는다’는 이야기로 쉽게 정리되기 때문입니다. 아이패드 프로가 노트북을 대체할 수 있는 컴퓨터가 되려 하지만, 하드웨어와 소프트웨어의 조합이 여전히 그것을 막는다는 지적은 iOS 11 시기에도 이미 등장했습니다[^iOS 11 on an iPad Pro still won’t replace your laptop]. 문제는 이 요구가 커지는 과정이 꼭 아이패드 해비 사용자의 집단적 합의로만 설명되지 않는다는 점입니다. 유튜브 중심의 테크 담론은 메시지를 단순하게 만들수록 확산되기 쉽습니다. 아이패드의 복잡한 정체성 논쟁은 아이패드에 맥OS를 줘라 같은 한 문장으로 압축되기 좋고 반대로 아이패드는 아이패드답게 터치 우선의 즉시성을 지키면서도 작업성을 올려야 한다는 주장은 길고 조건이 많아 영상 제목으로 만들기 어렵습니다. 실제로 아이패드는 맥OS를 돌려야 하느냐라는 질문 자체가 테크 콘텐츠에서 반복적으로 소비되는 주제라는 점은 확인할 수 있습니다[^Should iPads run macOS?]. 이 과정에서 빅 마우스의 영향력이 과대해지는 이유도 생깁니다. 유튜브에서 영향력 있는 테크 유튜버는 대개 특정한 사용자상에 맞춰 콘텐츠를 만들기 쉽습니다. 카메라, 영상 편집, 썸네일 제작, 메일, 문서, 브라우저 탭, 파일 정리, 외부 모니터 연결 같은 데스크탑형 작업을 더 자주 보여줄수록 아이패드는 자연스럽게 책상 위에서 맥북처럼 써야 하는 물건이 됩니다. 그러면 아이패드의 장점이었던 어디서든 손으로 빠르게 끝내는 작업은 화면에서 점점 사라집니다. 그 결과 아이패드의 평가 기준도 바뀝니다. 예전에는 아이패드로 이 일을 얼마나 편하게 할 수 있나가 기준이었다면 이제는 아이패드가 맥처럼 이 일을 할 수 있나가 기준이 됩니다.

이 기준 변화가 아이패드 해비 사용자에게 불리한 이유는 간단합니다. 아이패드 해비 사용자의 상당수는 아이패드를 ‘맥을 대신하는 기기’가 아니라 ‘맥으로 하기 귀찮거나 느린 일을 더 빠르게 하는 기기’로 써 왔기 때문입니다. 예를 들어 필기, PDF 주석, 자료 읽기, 강의 보며 정리, 현장 체크리스트, 연구 중 빠른 스크랩과 요약 같은 일은 윈도우를 예쁘게 배치해서 동시에 네 개를 띄우는 것보다 한 화면에서 바로 집중하고 바로 끝내는 것이 더 중요합니다. 그런데 담론이 맥 기준으로 바뀌면, 이런 작업은 ‘주된 평가 항목’에서 빠지기 쉽습니다. 그러면 제품 방향도 자연스럽게 책상 위 맥 흉내 쪽으로 힘이 실립니다. 이 현상을 아이패드 커뮤니티 내부에서도 비판적으로 보는 시각이 나옵니다. 아이패드가 터치스크린 맥북처럼 바뀌면서, 원래 iPadOS가 갖고 있던 강점인 한 번의 스와이프로 화면을 나란히 붙이거나 위에 띄워 쓰는 방식이 약해졌고 그 결과 계산하며 필기하거나 문서를 대조하는 같은 작업이 더 번거로워졌다는 식의 문제 제기가 있습니다[^How Tech Influencers Are Ruining the iPad Experience for Actual Users]. 이 문제 제기는 콘텐츠가 원하는 아이패드와 현장에서 쓰는 아이패드가 다른데도 전자가 후자를 밀어내고 있다는 경고로 읽는 편이 더 타당하다고 봅니다.​ 또 한 가지 중요한 배경은, 아이패드의 구조적 한계가 시간이 지나도 쉽게 사라지지 않는다는 인식이 커졌다는 점입니다. 아이패드는 이미 15년 가까운 시간 동안 특정한 보안 모델과 앱 배포 방식 위에서 발전해 왔고 그 구조 자체가 데스크탑 운영체제와 다른 선택을 강제합니다. 이 구조 때문에 데스크탑 앱을 그대로 가져오기 어렵고, iPadOS용으로 다시 만들어야 하며 그 과정에서 기능 격차가 생긴다는 설명이 반복됩니다[^The iPad's software problem is permanent]. 이런 인식이 퍼질수록 사람들은 중간 해법을 포기하고 그럼 그냥 맥OS를 줘라 같은 극단적으로 단순한 결론으로 더 쉽게 이동합니다.​

하지만 여기서 다시 질문이 필요합니다. 아이패드를 맥처럼이라는 요구가 커졌다고 해서 그것이 아이패드 해비 사용자의 대표 의견이었다고 단정할 수 있을까요. 저는 오히려 반대로 봅니다. 아이패드 해비 사용자의 불만은 ‘맥이 아니어서’라기보다 ‘아이패드답게 빠른 흐름이 깨져서’인 경우가 많습니다. 즉 이들은 맥OS 자체를 달라는 사람이 아니라 아이패드의 즉시성과 터치 우선 UX를 지키면서도 파일, 백그라운드, 멀티태스킹 신뢰성을 올려 달라는 사람에 더 가깝습니다. 그런데 이 요구는 영상 한 편으로 설득하기가 어렵고 숫자나 자극적인 대비로 표현하기도 어렵습니다. 그래서 담론에서 소외되기 쉽습니다. 아이패드를 맥처럼 만들어 달라는 요구는 분명 실재하고 어떤 사용자에게는 정당합니다. 하지만 그 요구가 커졌다는 사실만으로 아이패드가 맥OS식 경험을 더 많이 가져오는 결정이 충분히 숙고된 것이라고 보기도 어렵습니다. 담론이 단순할수록 제품 방향이 단순한 지표로 정렬되기 쉽고 그 과정에서 아이패드로 오래 일해 온 사람의 촘촘한 불편이 손쉽게 무시될 수 있기 때문입니다. 이어서 이 문제를 기술이나 담론이 아니라, 설계 원칙의 문제로 옮겨서 정리해 보겠습니다. 즉 아이패드와 맥이 서로 다른 목적을 갖는다는 전제 아래, 아이패드는 어떤 방향으로 멀티태스킹과 인터페이스를 설계해야 하는지부터 이어서 말씀드리겠습니다.

앞서 아이패드를 맥처럼 만들어 달라는 요구가 커진 배경을 이야기했고 그 요구가 항상 아이패드 해비 사용자 전체의 대표 의견이라고 보긴 어렵다고 말씀드렸습니다. 이제는 요구를 따지기보다, 아이패드와 맥의 목적 차이를 전제로 어떤 인터페이스가 더 자연스러운지 정리해 보겠습니다. 아이패드는 기본적으로 화면을 직접 만지는 기기이고, 이 전제가 무너지면 전체 사용 경험이 무너진다는 말이 공식 인터뷰에서 분명히 나왔습니다. 화면을 터치해서 무언가를 움직이기 시작했을 때 즉시 반응해야 하고 그렇지 않으면 기기와 사용자의 약속이 깨진다는 설명입니다[^Apple’s Craig Federighi on the long road to the iPad’s Mac-like multitasking]. 이 말은 아이패드는 맥처럼 만들 수 없다가 아니라, 아이패드는 맥처럼 만들기 전에 지켜야 할 선이 있다는 뜻으로 읽어야 합니다. 이 관점에서 보면 아이패드의 생산성은 맥의 생산성을 따라가며 완성되는 게 아닙니다. 아이패드의 생산성은 ‘직접 조작’과 ‘즉시성’을 바탕으로 짧은 시간을 여러 번 이어 붙여 성과를 만드는 방식에 더 가깝습니다. 사람은 터치스크린에서 제스처를 하며 콘텐츠와 가까운 연결감을 느끼고 표준 제스처가 시스템 전반에서 일관되게 동작하기를 기대한다는 설명은 오래된 인터페이스 가이드에서도 확인됩니다[^Gestures]. 즉 아이패드에서 중요한 것은 여러 개를 띄울 수 있음 자체가 아니라, 화면을 만지는 순간 내가 의도한 일이 바로 일어남이라는 신뢰입니다.

반대로 맥은 기본적으로 키보드와 마우스(혹은 트랙패드) 중심의 기기입니다. 이 환경에서 사용자는 윈도우를 여러 개 띄우고 윈도우의 겹침을 스스로 관리하며 파일과 폴더를 자유롭게 움직이고 백그라운드 작업을 믿고 맡기는 방식으로 생산성을 만듭니다. 그래서 맥의 멀티태스킹은 많이 띄우는 것이 아니라 장시간 유지되는 상태를 신뢰하는 것에 가깝습니다. 이 신뢰는 단축키, 메뉴바, 윈도우 시스템, 백그라운드 처리 같은 기반 위에서 만들어집니다[^Apple’s Craig Federighi on the long road to the iPad’s Mac-like multitasking]. 아이패드와 맥의 목적을 이렇게 나누면, 스테이지 매니저 논쟁이 조금 더 명확해집니다. 스테이지 매니저는 아이패드에 윈도우를 들여왔지만 윈도우 기반 모델이 자연스럽게 동작하려면 맥의 기반도 일부 필요합니다. 그런데 아이패드는 여전히 터치 우선의 단순함과 상호작용을 최우선으로 두는 쪽이 비타협에 가깝다는 설명이 공식적으로도 언급됩니다. 결국 아이패드는 맥을 닮는 순간에 생기는 기대치를 감당해야 하는데 동시에 아이패드가 아이패드로서 지켜야 할 핵심도 포기할 수 없는 구조에 놓입니다. 그래서 개인적으로 아이패드의 최적해가 맥이 되는 것이 아니라 태블릿의 생산성을 더 단단하게 만드는 것이라고 봅니다. 여기서 말하는 태블릿의 생산성은 스플릿 뷰와 슬라이드 오버처럼 화면을 단순한 규칙으로 나누고 보조 작업은 빠르게 끼워 넣고 제스처로 즉시 복귀하는 방식입니다. 또한 애플펜슬 같은 직접 입력이 작업 흐름을 끊지 않게 하는 설계도 여기에 포함됩니다. 이 방향에서는 윈도우를 겹치게 늘리는 것보다 내가 하려던 일이 방해받지 않는가가 더 중요한 평가 기준이 됩니다.

지금까지 아이패드 논쟁은 너무 자주 아이패드가 맥처럼 보이느냐에 초점이 맞춰져 왔습니다. 하지만 아이패드 해비 사용자가 진짜로 체감하는 생산성은 외형이 아니라 속도 즉 작업이 얼마나 덜 끊기고 얼마나 덜 생각해도 되느냐로 결정됩니다. 사용성 설계에서 중요한 개념 중 하나가 인지 부하입니다. 화면에 요소가 많아지고 선택지가 늘어날수록 더 많은 정신적 에너지를 써야 하고 그만큼 실수와 포기가 늘어납니다. 시각적 잡음을 줄이고, 기존의 정신 모델에 맞춰 설계하면 사용이 쉬워진다는 설명은 사용성 원칙에서 반복됩니다[^Minimize Cognitive Load to Maximize Usability]. 애플의 휴먼 인터페이스 가이드라인도 결국 같은 방향을 말합니다. 인터페이스가 어떤 화면 크기와 디스플레이에서도 일관되게 적응하고, 플랫폼 관습을 따르며 사용자가 예측 가능한 방식으로 쓸 수 있게 만들라고 강조합니다[^Human Interface Guidelines]. 즉 아이패드의 목표는 새 기능을 보여주는 것보다 머리를 덜 쓰게 만드는 것이어야 합니다.​ 이 관점에서 보면 스테이지 매니저의 문제는 기능 자체가 아니라 그 기능이 요구하는 인지 부하가 크다는 점입니다. 윈도우를 겹치게 놓는 순간 사용자는 ‘앞뒤’, ‘가림’, ‘포커스’, ‘작업 공간’ 같은 개념을 계속 추적해야 합니다. 앞 장에서 말했듯 이 추적은 메타 작업을 낳고 메타 작업은 체감 속도를 갉아먹습니다. 그 결과 스테이지 매니저는 있으면 좋아야 하는 기능인데도 실제 채택률이 낮게 나오는 상황이 생깁니다. iPad 사용자 응답 기준으로 스테이지 매니저를 사용한다는 비율이 8%로 집계된 설문이 있었고 가장 흔한 반응이 애플이 무엇을 하려는지 잘 모르겠다는 당혹감입니다[^Do You Use It? Stage Manager Sees Weak Adoption]. 이 결과를 스테이지 매니저의 실패로 단정하기보다 아이패드의 기본 목표와 평가 기준이 무엇이어야 하는지를 다시 묻게 만드는 신호로 봅니다.​

따라서 아이패드 작업을 빠르게 만든다를 목표로 삼으면, 측정해야 할 것도 달라집니다. 첫째, 작업 전환에 걸리는 단계 수가 줄어야 합니다. 슬라이드 오버는 보조 앱을 꺼내고 넣는 단계가 매우 짧았고 그래서 워크플로가 빨랐습니다. 둘째, 같은 작업을 반복할 때 매번 재구성하는 시간이 줄어야 합니다. 스테이지 매니저가 작업 공간을 제공한다면, 반복 작업은 더 빨라져야 정상입니다. 그런데 반복할수록 윈도우를 다시 정리하게 된다면 그건 기능이 목표를 달성하지 못한 것입니다. 셋째, 실수 비용이 줄어야 합니다. 터치 환경에서 실수로 윈도우 크기가 바뀌거나 가려지는 일이 잦다면 그 순간부터 사용자는 더 조심스럽게 손을 움직이고 속도가 떨어집니다. 이 지표를 기준으로 보면 아이패드에서 중요한 것은 윈도우가 자유로운가가 아니라 윈도우를 건드릴 일이 없는가에 더 가깝습니다. 다시 말해 아이패드식 생산성은 관리할 것을 늘리는 방향이 아니라 관리할 것을 줄이는 방향에서 나옵니다. 그래서 스테이지 매니저 같은 기능을 도입할 때 ‘프로 기능의 추가’라는 명분만으로 정당화하면 안됩니다. 기본 사용 경험이 느려지면 그 기능은 아무리 멋져 보여도 결과적으로 아이패드 전체 가치를 낮추게 됩니다.

최근 iPadOS 26 멀티태스킹 변화에 대한 반발이 나온 것도 이 관점에서 이해할 수 있습니다. 사용자들은 단순히 새 멀티태스킹이 싫다가 아니라, 예전에 단순했던 분할 화면이 더 많은 단계와 더 많은 규칙을 요구하게 됐다는 불만을 냈습니다. 두 앱을 동시에 쓰는 단순한 작업이 더 번거로워졌다는 경험이 구체적으로 공유됩니다[^Visual of why iPadOS 26 multitasking is a step backwards in usability]. 이 반발은 기능이 줄었다보다 속도가 줄었다는 불만에 가깝습니다. 아이패드 해비 사용자에게는 이 차이가 결정적입니다.​ 결국 아이패드가 맥OS의 사용 경험을 일부 도입할 수는 있지만 그 도입의 성공 여부는 맥처럼 보이는가가 아니라 아이패드에서 작업이 더 빨라졌는가로 판단해야 합니다. 그리고 그 빠름은 인지 부하, 단계 수, 실수 비용, 반복 작업 복원성 같은 요소로 측정할 수 있습니다. 애플이 이 지표를 우선순위로 삼지 않으면 아이패드는 앞으로도 새로운 기능을 추가할수록 일부 사용자에게는 더 불편해질 가능성이 큽니다. 이제 이 글의 마지막 부분으로 넘어가 아이패드는 누구의 목소리를 들어야 하는가를 정리하겠습니다. 특히 ‘데모에 좋은 기능’과 ‘현장에서 오래 쓰는 기능’이 충돌할 때 어떤 원칙으로 선택해야 하는지 그리고 아이패드 해비 사용자의 의견이 왜 쉽게 누락되는지까지 이어서 마무리하겠습니다.

아이패드의 방향을 정할 때 가장 먼저 들어야 할 목소리는 기능을 가장 크게 요구하는 사람이 아니라 매일 오래 쓰는 사람이라고 생각합니다[^Essential Design Principles]. 제품 발표 무대에서 잘 보이는 기능은 대개 데모에 강하지만 실제 업무에서는 작은 마찰이 더 큰 손해로 쌓이기 때문입니다. 스테이지 매니저 이후의 혼란은 결국 ‘창이 있느냐 없느냐’가 아니라, 아이패드가 어떤 계약을 사용자와 맺고 있었는지에서 시작됩니다. 아이패드는 터치로 직접 만지는 순간 즉시 반응해야 하고 그 반응성이 무너지면 기기와의 약속이 깨진다는 설명이 공식 인터뷰에서 분명히 언급된 바 있습니다[^Apple Explains Why iPad Multitasking Took So Long to Arrive]. 이 약속 위에서 자란 워크플로가 바로 스플릿 뷰와 슬라이드 오버 같은 빠르고 단순한 멀티태스킹이었고 앞에서 다룬 해비 사용자의 장점도 거기서 나왔습니다[^Split views]. 그런데 최근 논쟁의 프레임은 자주 아이패드는 왜 맥OS가 아니냐로 흘러갑니다. 이 프레임은 메시지가 단순해서 확산되기 쉽지만 단순한 만큼 아이패드의 본래 장점과 현장 사용을 잘 설명하지 못합니다. 스푼도 좋고 포크도 좋으니 합치자는 발상은 결국 둘 다 망친다는 ‘스포크’ 비유가 인터뷰에서 나온 이유도, 서로 다른 기기의 목적을 한쪽의 기준으로 통합하면 실패할 수 있다는 경고로 읽힙니다[^Craig Federighi Explains Why Apple Won't Merge iPad and Mac: 'We Don't Want to Build Sporks']. 여기서 중요한 사실은, 애플조차 아이패드는 단순함과 터치 우선성을 지켜야 한다는 말을 공개적으로 반복하고 있다는 점입니다. 아이패드를 맥처럼 만들자는 요구가 계속 나오더라도 아이패드는 모든 사람에게 쉬운 기기여야 하고, 맥OS의 복잡함을 그대로 들여오는 것은 아이패드의 본질을 해칠 수 있다는 취지의 설명이 이어집니다[^Craig Federighi says macOS would ruin what makes the iPad special]. 이 말은 스테이지 매니저를 없애겠다가 아니라 아이패드의 기본값은 아이패드다워야 한다는 선언에 가깝습니다.

그래서 아이패드가 들어야 할 목소리는 두 갈래로 나뉘어야 합니다. 하나는 책상 위에서 키보드와 마우스, 외부 모니터로 ‘프로 윈도우 모드’를 쓰는 사람들의 목소리이고 다른 하나는 아이패드를 들고 다니며 터치 환경에서 빠르게 성과를 내는 사람들의 목소리입니다. 이 둘은 서로 적이 아니고, 요구가 다를 뿐입니다. 문제는 한쪽의 요구를 ‘아이패드 전체의 방향’으로 과대표현해 버릴 때 생깁니다. 그 순간부터 아이패드는 아이패드답게 빠른 도구가 아니라 맥OS를 닮았지만 맥OS만큼 완성되지 않은 도구가 되기 쉽습니다. 해비 사용자의 의견이 쉽게 누락되는 이유도 구조적으로 설명할 수 있습니다. 해비 사용자의 불편은 대개 아주 작고 구체적이라서 발표 무대의 한 문장으로 요약하기 어렵습니다. 보조 앱을 10초만 쓰고 바로 돌아오고 싶다, 윈도우를 다시 정렬하는 시간이 하루에 누적된다, 손가락으로는 리사이즈가 자꾸 미끄러진다 같은 문제는 클릭을 끌기 좋은 한 줄 구호가 되기 힘듭니다. 반대로 아이패드에 맥OS를 올려라는 주장은 단순하고 강해서 영상 제목과 댓글에서 더 멀리 갑니다[^Should iPads run macOS?]. 하지만 제품 설계는 구호가 아니라 누적 시간으로 평가받습니다. 그래서 제안한 것처럼 아이패드는 ‘기능 추가’가 아니라 ‘기본값 보호’라는 원칙으로 다시 설계되어야 한다고 생각합니다. 스테이지 매니저 같은 기능을 넣더라도 스플릿 뷰와 슬라이드 오버로 굳어진 빠른 흐름을 기본으로 지키고, 프로 윈도우 모드는 상황(외부 모니터, 키보드·트랙패드 연결)에서만 자연스럽게 켜지는 형태가 더 올바릅니다.

마지막으로 아이패드와 맥의 관계는 누가 누구를 대체하느냐가 아니라 서로 무엇을 더 잘하게 만들 것이냐로 다시 정리되어야 합니다. 아이패드는 더 단순하고 더 직접적인 조작을 맥은 더 깊고 더 신뢰 가능한 백그라운드와 파일 작업을 맡는 것이 자연스럽습니다[^Apple’s Craig Federighi on the long road to the iPad’s Mac-like multitasking]. 이 균형을 존중할 때만 아이패드는 맥을 흉내 내다 정체성을 잃는 길이 아니라 아이패드만의 생산성을 더 단단하게 만드는 길로 갈 수 있습니다[^Craig Federighi Explains Why Apple Won't Merge iPad and Mac: 'We Don't Want to Build Sporks'].