플랫폼으로서의 접근성: Personal Voice, Live Speech, Eye Tracking, Music Haptics

Personal Voice (iOS 17), Live Speech (iOS 17), Eye Tracking (iOS 18), Music Haptics (iOS 18), Vocal Shortcuts (iOS 18). Apple의 최근 접근성 출시 흐름은 일관됩니다. 과거에는 서드파티 앱, 전용 하드웨어, 또는 특수 통합이 필요했던 기능들이 OS가 처리하는 플랫폼 기능으로 변모하고 있습니다. 그 결과 사용자는 설치할 앱이 줄어들고, 개발자는 다른 참여 모델을 갖게 됩니다. 즉, 기능을 직접 구축하는 대신 개발자는 시스템 표면에 옵트인하거나(Personal Voice 권한 요청), 모든 앱이 이미 충족해야 할 표준을 따릅니다(Eye Tracking을 위한 적절한 접근성 레이블과 히트 타깃).

이 글은 각 기능의 개발자 표면을 살펴봅니다. 프레임은 “이 기능을 어떻게 구현하는가”가 아니라 “내 앱이 참여하기 위해 무엇을 해야 하는가”입니다. Apple이 기능을 구축했고, 문제는 앱이 그것을 사용할 준비가 되었는지입니다.

TL;DR

• Personal Voice (iOS 17+)는 사용자가 15분 분량의 오디오를 녹음하여 AAC 및 보조 통신 앱을 위한 온디바이스 합성 음성을 만들 수 있도록 합니다. 앱은 AVSpeechSynthesizer.requestPersonalVoiceAuthorization()를 통해 통합하고 voiceTraits에서 .isPersonalVoice를 확인합니다¹.
• Live Speech (iOS 17+)는 시스템 기능입니다. 사용자가 텍스트를 입력하면 기기가 이를 음성으로 말합니다(선택적으로 자신의 Personal Voice 사용). 앱은 Live Speech를 직접 통합하지 않으며, 이 기능은 통화, FaceTime, 대면 의사소통 전반에서 OS 수준으로 작동합니다.
• Eye Tracking (iOS 18+)은 전면 카메라를 통한 시선 + Dwell Control로 기기를 제어합니다. 앱은 접근성 표준(적절한 접근성 레이블, 히트 타깃 크기, 포커스 순서)을 따름으로써 참여하며, 대부분의 앱에는 전용 API가 필요하지 않습니다².
• Music Haptics (iOS 18+)는 MediaAccessibility.framework의 MAMusicHapticsManager API를 통해 음악 재생을 오디오와 동기화된 Taptic Engine 진동으로 변환합니다. Info.plist에 MusicHapticsSupported를 설정하고, 활성 Now Playing 앱이 되며, ISRC를 제공함으로써 모든 음악 앱이 통합할 수 있습니다³.
• Vocal Shortcuts (iOS 18+)는 사용자가 사용자 정의 문구를 할당하여 서드파티 AppIntent 액션을 포함한 Siri Shortcuts을 트리거할 수 있도록 합니다. 이 기능은 App Intents 채택과 결합됩니다(App Intents Are Apple’s New API to Your App에서 다룸).

Personal Voice: 권한 패턴

Personal Voice는 가장 직접적인 개발자 표면을 가진 접근성 기능입니다¹. 사용자는 설정 > 손쉬운 사용 > Personal Voice를 통해 옵트인하고, 무작위 프롬프트를 읽으며 약 15분 분량의 오디오를 녹음하면, 기기는 온디바이스 머신러닝을 사용해 합성 음성을 로컬에서 생성합니다. 이 음성은 사용자에게 비공개이며, 사용자가 명시적으로 iCloud 페어링된 기기와 공유하지 않는 한 기기를 떠나지 않습니다.

앱이 AVSpeechSynthesizer에서 사용자의 Personal Voice를 사용하려면 다음을 수행해야 합니다.

1. AVSpeechSynthesizer.requestPersonalVoiceAuthorization(completionHandler:)를 통해 권한을 요청합니다.
2. 사용자가 시스템 프롬프트를 통해 권한을 부여할 때까지 기다립니다.
3. 승인되면 AVSpeechSynthesisVoice.speechVoices()를 쿼리하고 voiceTraits에 .isPersonalVoice가 포함된 음성을 필터링합니다.
4. 결과로 얻은 AVSpeechSynthesisVoice를 AVSpeechUtterance의 다른 음성과 동일하게 사용합니다.

import AVFoundation

AVSpeechSynthesizer.requestPersonalVoiceAuthorization { status in
    guard status == .authorized else { return }

    let personalVoices = AVSpeechSynthesisVoice.speechVoices().filter { voice in
        voice.voiceTraits.contains(.isPersonalVoice)
    }

    if let voice = personalVoices.first {
        let utterance = AVSpeechUtterance(string: "Hello.")
        utterance.voice = voice
        synthesizer.speak(utterance)
    }
}

이 권한은 민감합니다. Apple의 가이드는 Personal Voice가 주로 보완 대체 의사소통(AAC) 앱 및 유사한 보조 컨텍스트에 사용되어야 한다고 명시합니다. Personal Voice 권한을 요청하는 범용 음성 인식 앱은 사용자에 의해 거부될 가능성이 높고, App Store 심사에서 면밀한 검토를 받을 수 있습니다.

여기서 온디바이스 우선 아키텍처가 중요합니다. 사용자가 명시적으로 iCloud 공유를 옵트인하지 않는 한, 사용자의 음성 학습 데이터와 결과 음성 모델은 기기의 보안 영역을 결코 떠나지 않습니다. 합성이 로컬에서 발생하고 오디오 출력이 네트워크가 아닌 스피커로 가기 때문에, Personal Voice를 사용하는 앱의 App Store 개인정보 영양 라벨은 데이터 수집이 0으로 반영되어야 합니다.

Live Speech: 통합이 필요 없는 시스템 기능

Live Speech는 Personal Voice의 사용자 대면 짝입니다⁴. 사용자가 텍스트를 입력하면 기기가 이를 음성으로 말하며, 선택적으로 자신의 Personal Voice를 사용할 수 있습니다. Live Speech는 전화 통화, FaceTime 통화, Mac SharePlay, 그리고 기기 스피커를 통한 대면 대화 중에 작동합니다.

앱은 Live Speech를 직접 통합하지 않습니다. 이 기능은 OS 수준에서 작동하며, 시스템 Live Speech UI에서 입력된 텍스트를 가로채 오디오 스택을 통해 라우팅합니다. 앱의 관점에서 Live Speech는 보이지 않습니다. 통화를 통해 들어오는 오디오 스트림(또는 대면 사용을 위해 기기 스피커에서 재생되는 스트림)은 사용자처럼 들리지만, 앱 코드는 관여하지 않습니다.

앱 개발자에게 시사하는 바는 다음과 같습니다. 앱이 음성을 처리하는 경우(통화 앱, 화상 채팅 앱, 접근성 도우미), 앱의 오디오 파이프라인은 시스템 오디오 라우팅을 존중해야 Live Speech가 같은 채널을 통해 출력될 수 있습니다. 시스템 수준 오버레이 사운드를 고려하지 않고 독점 제어를 주장하며 오디오 세션과 충돌하는 앱은 Live Speech를 망가뜨립니다.

Eye Tracking: 표준을 따르는 기능

iOS 18에서 도입된 Eye Tracking은 사용자가 시선 방향과 Dwell Control을 통해 iPhone과 iPad를 제어할 수 있도록 합니다². 사용자가 몇 초 안에 전면 카메라를 보정한 후, 요소를 바라보며 UI를 탐색합니다. 구성된 Dwell 시간 동안 한 요소에 시선을 유지하면 해당 요소가 활성화됩니다(탭, 스와이프, 또는 기타 제스처, Switch Control에서 구성 가능).

구현은 온디바이스입니다. 전면 카메라는 온디바이스 머신러닝을 통해 시선 데이터를 처리하며, 데이터는 기기를 떠나지 않습니다. 추가 하드웨어는 필요하지 않습니다.

대부분의 앱에서 Eye Tracking을 지원하는 것은 전용 코드를 필요로 하지 않습니다. 이 기능은 표준 접근성 규약을 따르는 모든 UI에서 작동합니다.

• 적절한 히트 타깃. Apple Human Interface Guidelines는 탭 가능한 요소에 대해 최소 44pt × 44pt 히트 타깃을 명시합니다. Eye Tracking은 이를 준수합니다. 최소값보다 작은 버튼은 정확하게 dwell-target 하기 더 어렵습니다.
• 접근성 레이블. 모든 인터랙티브 요소에는 유용한 accessibilityLabel(SwiftUI) 또는 accessibilityLabel 속성(UIKit)이 있어야 합니다. Eye Tracking은 사용자가 요소 근처에 시선을 유지할 때 레이블을 툴팁에 해당하는 것으로 표시합니다.
• 논리적인 포커스 순서. Mac의 Tab 키와 tvOS의 포커스 엔진은 Eye Tracking이 요소 사이를 건너뛸 때 사용하는 동일한 포커스 순서를 표시합니다. SwiftUI의 표준 레이아웃 프리미티브를 사용하는 앱은 이를 무료로 얻습니다. 포커스 동작을 재정의하는 앱은 검증해야 합니다.
• Dwell 친화적 모달 패턴. 외부 탭 시 자동으로 닫히는 모달은 dwell 지점이 잠시 모달 영역을 벗어날 수 있는 Eye Tracking 사용자를 좌절시킬 수 있습니다. 모달 UI가 있는 앱은 명시적인 닫기 버튼을 제공해야 합니다.

특정 뷰(민감한 콘텐츠, 복잡한 제스처 기반 게임)에 대해 Eye Tracking을 옵트아웃하려는 앱은 Eye Tracking 전용으로 문서화된 옵트아웃 API가 없습니다. 이 기능은 보이는 모든 콘텐츠에서 작동하며, 앱의 책임은 표준 접근성 표면이 올바른지 확인하는 것입니다.

Three Surfaces of an iOS App 게시물은 더 넓은 패턴을 다룹니다. 보이는 UI는 한 표면이고, App Intents는 또 다른 표면이며, 접근성은 세 번째 표면입니다. Eye Tracking은 보이는 UI 표면에 참여합니다. 그 표면을 올바르게 만드는 것이 Eye Tracking, Switch Control, VoiceOver, Voice Control을 동시에 활성화합니다.

Music Haptics: 오디오-햅틱 브리지

Music Haptics는 음악 재생을 오디오와 동기화된 Taptic Engine 진동으로 변환합니다³. 이 기능은 사용자별로 옵트인이며(설정 > 손쉬운 사용 > Music Haptics), Apple Music뿐만 아니라 API를 올바르게 통합한 모든 음악 앱에서 작동합니다.

개발자 표면은 MediaAccessibility.framework의 MAMusicHapticsManager(iOS 18+)에 있습니다. 음악 앱은 세 단계를 통해 Music Haptics를 통합합니다.

1. Info.plist에서 지원을 선언합니다. 값이 YES인 MusicHapticsSupported 키를 추가합니다. 시스템은 이를 통해 앱이 Music Haptics 렌더링에 참여하는지 여부를 확인합니다.
2. 활성 Now Playing 앱이 됩니다. 앱은 MPNowPlayingInfoCenter.default().nowPlayingInfo를 통해 재생 메타데이터를 게시하고 현재 재생 중인 오디오 세션을 소유해야 합니다. 시스템은 햅틱 합성을 구동하기 위해 알려진 활성 Now Playing 소스가 필요합니다.
3. 재생 중인 트랙에 대한 ISRC를 제공합니다. MPNowPlayingInfoPropertyInternationalStandardRecordingCode 키(국제 표준 녹음 코드)는 시스템이 오디오와 짝을 이루는 햅틱 트랙을 조회할 수 있도록 합니다. Apple은 ISRC로 키된 햅틱 자산 라이브러리를 유지합니다. ISRC가 없는 트랙은 햅틱을 받지 못하지만, 나머지 now-playing 통합은 여전히 작동합니다.

import MediaPlayer
import MediaAccessibility

// Info.plist: MusicHapticsSupported = YES (boolean)

let info: [String: Any] = [
    MPMediaItemPropertyTitle: track.title,
    MPMediaItemPropertyArtist: track.artist,
    MPNowPlayingInfoPropertyInternationalStandardRecordingCode: track.isrc,
    // ... other now-playing properties
]
MPNowPlayingInfoCenter.default().nowPlayingInfo = info

이 통합은 모든 음악 앱에 적용됩니다. AVAudioEngine 기반의 스트리밍 클라이언트, 사용자 정의 디코더가 있는 DJ 앱, 샘플 재생이 있는 음악 학습 앱 등입니다. 제약은 ISRC와 활성 Now Playing 역할이며, 기본 오디오 API가 아닙니다. ISRC가 없는 앱(메타데이터가 없는 사용자 업로드 음악, 생성형 음악)은 햅틱을 받지 못할 뿐, 나머지 재생 통합은 영향을 받지 않습니다.

인접 영역의 앱(리듬 게임, 음악 시각화, 사운드 이펙트 엔진)의 경우, 오디오는 Music Haptics가 설계된 대상이 아닙니다. 그러한 앱들은 자신의 오디오 소스에 동기화된 수작업으로 작성된 햅틱 패턴을 위해 CHHapticEngine에 직접 도달합니다.

Vocal Shortcuts: 접근성과 App Intents가 만나는 곳

Vocal Shortcuts는 사용자가 서드파티 AppIntent 타입에 의해 뒷받침되는 것을 포함하여 사용자 정의 음성 문구를 Siri Shortcuts에 할당할 수 있도록 합니다⁵. 사용자는 할 일 앱에서 등록한 AddTodoIntent를 트리거하도록 “Marker”를 구성할 수 있습니다. 사용자가 어디에 있든 Siri의 깨우기 문구를 호출하지 않고 “Marker”를 말하면 인텐트가 트리거됩니다.

이 통합은 클러스터에서 광범위하게 다룬 App Intents 프레임워크를 사용하며, 놓치기 쉬운 한 가지 구조적 부분이 있습니다. 앱은 명시적인 phrases를 가진 AppShortcut 항목을 노출하는 AppShortcutsProvider를 선언해야 합니다. 단순한 AppIntent는 시스템에 존재하지만, 사용자가 수동으로 Shortcut을 조립하는 Shortcuts 편집기를 통해서만 호출 가능합니다. AppShortcutsProvider는 사용자가 즉시 Vocal Shortcut, Action Button, Siri 또는 Spotlight에 할당할 수 있는 시스템에 표시되는 단축키를 등록합니다.

struct TodoShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: AddTodoIntent(),
            phrases: [
                "Add a todo in \(.applicationName)",
                "\(.applicationName) marker"
            ],
            shortTitle: "Add Todo",
            systemImageName: "checkmark.circle"
        )
    }
}

phrases 배열은 시스템이 Siri와 Vocal Shortcuts에 표시하는 것입니다. 프로바이더가 자리를 잡으면, App Intent는 음성 활성화에 즉시 적합해집니다. 그것이 없으면 인텐트는 수동 Shortcuts 설정을 통해 작동하지만, 경로는 더 길고 많은 사용자들은 그것에 결코 도달하지 못합니다.

이 패턴은 App Intents 및 App Intents vs MCP Tools와 결합됩니다. 사용자가 어떻게 호출할지 선언하는 AppShortcutsProvider와 짝을 이루어 사용자의 Apple Intelligence 표면에서 자리를 얻는 App Intent는 Vocal Shortcut 대상으로서의 자리도 얻습니다. App Intents가 “앱이 할 수 있는 것”에 대한 시스템 간 계약이라는 클러스터의 주장이 여기에 적용됩니다. Vocal Shortcuts는 그 동일한 계약의 또 다른 소비자입니다.

교차하는 패턴: 표준이 곧 통합이다

위의 접근성 기능들은 구조적 속성을 공유합니다. 각 기능은 앱이 이미 충족해야 할 표준 위에 구축되며, 앱이 명시적으로 협력해야 하는 경우(Personal Voice 권한 요청, MPMusicPlayerController를 통한 Music Haptics)에 대한 작은 옵트인 API 표면을 가집니다.

개발 팀에 대한 함의는 이렇습니다. 접근성 작업은 앱이 출시된 후 수행되는 별도의 작업 흐름이 아닙니다. 앱의 접근성 레이블, 히트 타깃, 포커스 순서, 표준 시스템 API 사용이 Eye Tracking을 작동시키고, Live Speech를 올바르게 라우팅하며, Music Haptics를 활성화하고, Vocal Shortcuts가 올바른 인텐트를 표시하도록 만드는 것입니다. 사이클 끝의 체크박스로 접근성을 다루는 앱은 VoiceOver에서는 작동하지만 Eye Tracking에서는 작동하지 않거나, Live Speech가 따라갈 수 없는 방식으로 오디오를 라우팅하는 기능을 출시합니다.

클러스터의 What I Refuse to Write About 게시물은 거부를 포지셔닝 수단으로 주장합니다. 접근성 거부는 그 반대입니다. “이것을 추가하는 것을 거부한다”가 아니라, “모든 iOS 앱이 이미 충족해야 할 표준에 실패하는 것을 출시하는 것을 거부한다”입니다.

앱이 사용자 정의 접근성 코드가 필요한 경우

표준을 따르는 패턴이 모든 것을 커버하지 못하는 세 가지 경우가 있습니다.

사용자 정의 그리기 표면. 그림 그리기 앱, 차트, 사용자 정의 렌더링된 게임 UI는 SwiftUI/UIKit 접근성 트리를 우회합니다. 앱은 UIAccessibilityCustomAction, UIAccessibilityElement, 그리고 각 의미 있는 요소에 대한 명시적인 접근성 속성을 사용해 자체 접근성 트리를 구축해야 합니다. Eye Tracking, VoiceOver, Switch Control 모두 접근성 트리가 채워져 있는지에 의존합니다.

실시간 제스처 인터랙션. 연속 제스처 입력(그리기, 드래그-조준)이 있는 게임은 dwell 기반 또는 스위치 기반 입력에 자연스럽게 매핑되지 않습니다. 올바른 접근 방식은 접근성 시스템과 싸우는 대신 대체 제어 체계(옵션으로서의 버튼 기반 입력)를 제공하는 것입니다.

접근성 전용 기능. AAC 앱, 음성 증강 앱, 수화 통역 앱. 이러한 앱들은 그 자체로 접근성 제품이며, 시스템 프레임워크(Personal Voice, Speech 프레임워크, 수화 감지를 위한 Vision 프레임워크)와 깊이 통합됩니다. 통합 작업은 실제적이고 의도적입니다.

이 패턴이 iOS 26+ 앱에 의미하는 것

세 가지 시사점.

1. 접근성 참여는 대부분 표준을 따르는 것이지, 기능을 구축하는 것이 아닙니다. Apple은 접근성을 플랫폼 계층으로 옮겨왔습니다. 작업은 앱이 Eye Tracking, Switch Control, VoiceOver, Voice Control이 모두 의존하는 표준을 충족하는지 확인하는 것입니다. 적절한 레이블, 히트 타깃, 포커스 순서, 시스템 오디오 라우팅입니다.

2. Personal Voice 통합은 민감합니다. 앱에 실제 AAC 사용 사례가 있다면(보조 의사소통, 음성 증강, 접근성 도구), Personal Voice 권한 요청은 올바른 통합입니다. 범용 앱의 경우, Personal Voice 권한을 요청하는 것은 사용자에게 도움이 되기보다 혼란을 줄 가능성이 더 높습니다.

3. App Intents는 접근성 인프라입니다. 깔끔한 AppIntent는 자동으로 Vocal Shortcuts에 적합해지고, Shortcuts을 통해 접근 가능한 UI 표면을 얻으며, 시스템의 음성 기반 및 스위치 기반 제어 모드와 통합됩니다. App Intents 채택에 대한 클러스터의 주장은 접근성에도 적용됩니다.

전체 Apple 생태계 클러스터: 타입화된 App Intents; MCP 서버; 라우팅 질문; Foundation Models; 런타임 vs 도구 LLM 구분; 세 가지 표면; 단일 진실 소스 패턴; 두 개의 MCP 서버; Apple 개발을 위한 훅; Live Activities; watchOS 런타임; SwiftUI 내부; RealityKit의 공간 멘탈 모델; SwiftData 스키마 규율; Liquid Glass 패턴; 멀티 플랫폼 출시; 플랫폼 매트릭스; Vision 프레임워크; Symbol Effects; Core ML 추론; Writing Tools API; Swift Testing; Privacy Manifest; 내가 쓰지 않기를 거부하는 것. 허브는 Apple Ecosystem Series에 있습니다. 더 넓은 iOS와 AI 에이전트 컨텍스트에 대해서는 iOS Agent Development guide를 참조하세요.

FAQ

Eye Tracking을 지원하기 위해 코드를 작성해야 합니까?

대부분의 앱에서는 그렇지 않습니다. Eye Tracking은 표준 접근성 규약을 따르는 모든 UI와 자동으로 작동합니다. 적절한 히트 타깃(최소 44pt), 유용한 접근성 레이블, 논리적 포커스 순서, 표준 시스템 컨트롤입니다. 자체 UI를 그리는 앱(사용자 정의 뷰, 게임, 차트)은 UIAccessibilityElement 또는 SwiftUI의 접근성 수정자를 사용해 접근성 트리를 명시적으로 채워야 합니다. 그 작업은 또한 앱이 VoiceOver와 Switch Control에서 작동하도록 만드는 것이기도 합니다.

범용 음성 인식 앱에서 Personal Voice를 사용할 수 있습니까?

시스템은 AVSpeechSynthesizer.requestPersonalVoiceAuthorization()를 통해 이를 허용하지만, Apple의 가이드와 App Store 심사 프로세스는 보조 컨텍스트(AAC, 보완 대체 의사소통)를 위한 Personal Voice를 강조합니다. Personal Voice 권한을 요청하는 범용 음성 인식 앱은 두 가지 도전에 직면합니다. 사용자가 권한을 부여할 가능성이 낮고, 심사가 부적절한 사용으로 요청을 반려할 수 있습니다. 사용 사례가 진정으로 보조적이라면 통합이 옳습니다. 범용 내레이션이라면 시스템 음성이 올바른 도구입니다.

Live Speech와 Personal Voice의 차이점은 무엇입니까?

Personal Voice는 사용자처럼 들리는 온디바이스 합성 음성입니다. Live Speech는 사용자가 입력하면 기기가 말하도록 하는 시스템 기능입니다(시스템 음성 또는 자신의 Personal Voice 사용). 둘은 보완적입니다. Personal Voice는 음성을 제공하고, Live Speech는 입력-음성 UI를 제공합니다. 앱은 Speech Synthesizer API를 통해 Personal Voice를 통합합니다. Live Speech는 앱에 보이지 않으며 OS 수준에서 작동합니다.

AVAudioEngine을 사용하는 음악 앱에 Music Haptics를 어떻게 추가합니까?

가능합니다. Music Haptics는 특정 재생 API로 한정되지 않습니다. 통합은 다음과 같습니다. Info.plist에 MusicHapticsSupported = YES를 추가하고, MPNowPlayingInfoCenter.default().nowPlayingInfo를 통해 재생 중인 트랙의 메타데이터를 게시하며(시스템이 앱을 활성 Now Playing 소스로 인식하도록), 트랙의 ISRC와 함께 MPNowPlayingInfoPropertyInternationalStandardRecordingCode를 포함합니다. 시스템은 거기서부터 햅틱 합성을 처리합니다. ISRC가 없는 트랙은 햅틱을 받지 못하지만, 나머지 now-playing 통합은 정상적으로 작동합니다.

최고의 Vocal Shortcuts 경험을 제공하는 App Intent 디자인은 무엇입니까?

네 가지 원칙입니다. 첫째, 앱에 대한 AppShortcutsProvider를 선언하고 음성으로 접근 가능하기를 원하는 인텐트에 대해 AppShortcut 항목을 등록합니다. 프로바이더가 없으면 인텐트는 수동 Shortcuts 편집을 통해서만 Vocal Shortcuts에 도달합니다. 둘째, title과 shortTitle은 설명이 아닌 짧은 동사구(“Add Todo,” “Start Timer”)여야 합니다. 셋째, 매개변수는 선택 사항이거나 기본값이 있어야 사용자가 모든 필드를 지정하지 않고도 인텐트를 호출할 수 있습니다. 넷째, description은 인텐트의 효과를 설명하는 단일 명확한 문장이어야 합니다. 이는 사용자가 할당할 문구를 선택할 때 컨텍스트로 표시됩니다.

References