제스처 내비게이션 — 작동 방식, 유형 및 구현

제스처 내비게이션이란

제스처 내비게이션은 터치 스크린이 인식하는 터치, 움직임, 누름의 시퀀스를 통해 사용자가 모바일 기기와 상호작용하는 방법입니다. 기존 버튼과 달리 제스처는 화면에 고정된 위치가 없으며 움직임 패턴으로 인식됩니다: 가장자리에서 스와이프, 두 손가락 핀치, 롱 프레스.

제스처 내비게이션으로의 전환은 iPhone X에서 시작되었습니다 (2017). Apple은 홈 버튼을 완전히 제거하고 하단 가장자리에서 스와이프로 대체했습니다. Google은 Android 10 (2020)에서 이 트렌드를 따라 사용자에게 세 가지 선택지를 제공했습니다: 세 버튼 내비게이션, 두 버튼 내비게이션, 완전한 제스처 내비게이션. StatCounter (2025)에 따르면, Android 기기의 75% 이상과 iOS 기기의 95%가 제스처 내비게이션을 사용합니다.

아키텍처적으로, 제스처 인식은 세 단계로 구성됩니다: 캡처 (터치 이벤트 포착), 인식 (움직임 패턴 식별), 실행 (할당된 작업 수행). 시스템 수준에서 Android와 iOS는 기본 내비게이션 제스처(뒤로 스와이프, 홈 화면으로 이동, 앱 전환기 열기)를 위한 내장 핸들러를 가지고 있습니다. 개발자는 자신의 제스처를 이 시스템에 올바르게 통합하기만 하면 됩니다.

모바일 내비게이션의 제스처 유형

모든 터치 제스처는 목적과 실행 방법에 따라 세 가지 범주로 나눌 수 있습니다. 각 유형에는 고유한 처리 규칙과 인터페이스 사용에 대한 권장 사항이 있습니다.

내비게이션 제스처

내비게이션 제스처는 화면 간 이동을 제어합니다: 뒤로 가기를 위한 왼쪽 가장자리에서 스와이프 (iOS), 앱 전환기를 열기 위한 위로 스와이프, 홈 화면으로 돌아가기 위한 하단 가장자리에서 스와이프. 이러한 제스처는 창 수준에서 시스템에 의해 처리되며 앱 내 사용자 정의 제스처와 충돌하지 않아야 합니다.

조작 제스처

조작 제스처는 화면에서 객체의 위치, 크기 또는 방향을 변경합니다. 핀치 (두 손가락 줌), 회전, 팬 (드래그), 스와이프 (빠른 스와이프) — 이러한 모든 제스처는 View 또는 Composable 수준에서 처리되며 시스템 내비게이션에 영향을 미치지 않습니다.

상황별 제스처

상황별 제스처는 다른 화면으로 이동하지 않고 추가 기능을 활성화합니다. 롱 프레스 (컨텍스트 메뉴용), 더블 탭 (좋아요 또는 줌용), 엣지 스와이프 (Drawer 열기용). 이러한 제스처는 시스템 내비게이션 제스처와 겹칠 수 있으므로 가장 신중한 구현이 필요합니다.

Android의 제스처 내비게이션: GestureDetector 및 MotionEvent

Android SDK는 저수준 MotionEvent부터 고수준 GestureDetector 및 GestureOverlayView까지 다계층 제스처 처리 시스템을 제공합니다. 올바른 수준을 선택하는 것은 제스처의 복잡성과 성능 요구 사항에 따라 달라집니다.

GestureDetector — 기본 클래스

GestureDetector는 MotionEvent 시퀀스를 특정 제스처(onDown, onShowPress, onSingleTapUp, onScroll, onLongPress, onFling)로 변환하는 고수준 클래스입니다. 개발자는 GestureDetector.SimpleOnGestureListener의 필요한 메서드를 재정의하고 인식된 이벤트를 받습니다. GestureDetector는 크기 조정을 제외한 모든 표준 제스처에 권장됩니다 — 크기 조정에는 ScaleGestureDetector가 있습니다.

val gestureDetector = GestureDetector(this, object : GestureDetector.SimpleOnGestureListener() {
    override fun onFling(
        e1: MotionEvent?, e2: MotionEvent,
        velocityX: Float, velocityY: Float
    ): Boolean {
        val deltaX = e2.x - (e1?.x ?: 0f)
        return if (Math.abs(deltaX) > Math.abs(e2.y - (e1?.y ?: 0f))) {
            if (deltaX > 0) onSwipeRight() else onSwipeLeft()
            true
        } else false
    }
})

view.setOnTouchListener { _, event -> gestureDetector.onTouchEvent(event) }

사용자 정의 대상을 위한 TouchDelegate

TouchDelegate는 View의 터치 영역을 확장하는 메커니즘입니다. 대상 요소가 최소 터치 크기 48dp보다 작을 때 사용됩니다. 예를 들어, 화면 모서리에 있는 작은 "닫기" 버튼은 표시 크기를 변경하지 않고 히트 영역을 확장하는 TouchDelegate를 받습니다. Google은 48x48dp보다 작은 모든 대화형 요소에 TouchDelegate를 권장합니다.

Jetpack Compose의 제스처

Compose는 제스처 처리를 위한 수정자를 제공합니다: clickable, draggable, swipeable, combinedClickable (더블 탭 및 롱 프레스용). 내부적으로 Compose는 저수준 처리를 위해 PointerInputScope를 사용하지만, 대부분의 개발자에게는 고수준 수정자로 충분합니다. 사용자 정의 제스처의 경우 awaitPointerEvent와 함께 pointerInput을 사용하세요.

iOS의 제스처 내비게이션: UIGestureRecognizer 및 SwiftUI

iOS SDK는 UIGestureRecognizer 아키텍처를 사용합니다 — UITouch 시퀀스를 분석하고 알려진 제스처와 일치하는지 결정하는 추상 기본 클래스입니다. Apple은 가능한 한 표준 인식기를 사용하고 고유한 제스처에 대해서만 사용자 정의 하위 클래스를 만들 것을 권장합니다.

UIKit의 UIGestureRecognizer

UIKit은 즉시 사용 가능한 인식기 세트를 제공합니다: UITapGestureRecognizer, UISwipeGestureRecognizer, UIPanGestureRecognizer, UIPinchGestureRecognizer, UIRotationGestureRecognizer, UILongPressGestureRecognizer. 각 인식기에는 상태(possible, began, changed, ended, cancelled, failed)가 있으며, 개발자는 상태를 추적하여 제스처의 여러 단계에서 반응합니다.

let swipeBack = UISwipeGestureRecognizer(
    target: self,
    action: #selector(handleSwipeBack)
)
swipeBack.direction = .right
view.addGestureRecognizer(swipeBack)

@objc func handleSwipeBack() {
    navigationController?.popViewController(animated: true)
}

SwiftUI의 제스처

SwiftUI는 Compose와 유사한 선언적 제스처 수정자를 사용합니다: onTapGesture, onLongPressGesture, MagnificationGesture, RotationGesture, DragGesture. SwiftUI는 simultaneousGesture, sequencedGesture, exclusiveGesture를 통해 제스처 간 충돌을 자동으로 처리합니다 — 동시에 트리거될 때 제스처 우선순위를 결정하는 수정자입니다.

Image("photo")
    .gesture(
        MagnificationGesture()
            .onChanged { scale in
                self.currentScale = scale
            }
            .sequenced(before: DragGesture())
    )

InteractivePopGestureRecognizer

InteractivePopGestureRecognizer는 UINavigationController에서 뒤로 스와이프 제스처를 제어하는 시스템 인식기입니다. 기본적으로 루트를 제외한 모든 화면에서 활성화됩니다. 앱이 사용자 정의 NavigationBar를 사용하는 경우 interactivePopGestureRecognizer가 작동을 멈출 수 있습니다 — navigationController.interactivePopGestureRecognizer?.delegate를 통해 프로그래밍 방식으로 활성화해야 합니다.

시스템 제스처와 사용자 정의 제스처의 충돌

제스처 충돌은 제스처 내비게이션에서 가장 어려운 문제 중 하나입니다. 사용자 정의 제스처(예: 왼쪽 가장자리에서 스와이프하여 Drawer 열기)가 시스템 제스처(iOS 또는 Android의 뒤로 스와이프)와 일치할 때 시스템은 어떤 제스처에 우선순위를 둘지 결정해야 합니다. 이 충돌을 올바르게 처리하는 것은 사용자 경험에 중요합니다.

Android의 해결책: Insets 및 SystemGestureExclusionRects

Android 10+에서는 앱이 WindowInsets을 통해 자체 제스처를 위한 화면 영역을 예약할 수 있습니다. ViewCompat.setSystemGestureExclusionRects를 사용하여 시스템 제스처가 트리거되지 않아야 하는 영역을 지정하세요. 예를 들어, 왼쪽 Drawer의 경우 왼쪽 화면 가장자리(최대 200dp 너비)를 시스템 뒤로 스와이프에서 제외할 수 있습니다. Google은 각 측면에서 최대 200dp까지 제외할 수 있는 제한을 설정했습니다.

val exclusionRect = Rect(0, 0, 200, height)
ViewCompat.setSystemGestureExclusionRects(
    drawerView,
    listOf(SystemGestureExclusionRect(exclusionRect))
)

iOS의 해결책: UIGestureRecognizerDelegate

iOS는 UIGestureRecognizerDelegate의 gestureRecognizerShouldBegin 메서드를 제공하여 사용자 정의 인식기가 인식을 시작할지 여부를 결정할 수 있도록 합니다. 왼쪽 가장자리에서 Drawer 스와이프의 경우 터치 위치를 확인할 수 있습니다: 사용자가 Drawer를 드래그하는 경우(거리가 임계값을 초과), 사용자 정의 제스처가 제어권을 가져옵니다. 제스처가 인식되지 않으면 시스템이 InteractivePopGestureRecognizer에 제어권을 반환합니다.

일반적인 실수와 모범 사례

제스처 내비게이션은 특히 시스템 제스처 내비게이션이 있는 기기에서 신중한 설계가 필요합니다. 일반적인 실수와 해결 방법을 살펴보겠습니다.

실수: 화면 가장자리의 충돌 영역 무시

가장 흔한 실수는 시스템 제스처 영역(왼쪽 및 오른쪽 가장자리, 하단 가장자리)에 대화형 요소를 배치하거나 사용자 정의 스와이프를 구현하는 것입니다. 사용자가 작업을 수행하려고 하지만 대신 시스템 내비게이션이 트리거됩니다. 항상 시스템 제스처를 위한 여백을 제공하고 exclusion rects를 통해 충돌을 처리하세요.

실수: Android와 iOS의 인식 속도 차이

제스처 매개변수(속도 임계값, 최소 거리)는 기본적으로 플랫폼마다 다릅니다. 앱이 크로스 플랫폼인 경우 한 플랫폼에서 다른 플랫폼으로 매개변수를 복사하지 마세요 — 각 제스처를 Android와 iOS에서 개별적으로 테스트하세요. Flutter와 React Native는 일부 매개변수를 자동으로 조정하지만 모두는 아닙니다.

모범 사례: 시각적 피드백

모든 제스처에는 시각적 피드백(색상 변경, 변환, 애니메이션)이 수반되어야 합니다. 사용자는 제스처가 인식되었고 작업이 실행되고 있음을 이해할 수 있어야 합니다. iOS에서는 시스템 인식기가 자동으로 촉각 피드백을 제공합니다. Android에서는 HapticFeedbackConstants를 통해 추가해야 합니다.

모범 사례: 제스처 접근성

모든 사용자가 제스처를 수행할 수 있는 것은 아닙니다 — 운동 능력이 제한된 사람들은 VoiceOver와 TalkBack을 사용하여 탐색합니다. 모든 제스처에는 버튼 대안이 있어야 합니다. Google과 Apple은 모든 제스처 동작이 접근 가능한 컨트롤로 복제되도록 요구합니다.