Android XR 오디오 글래스 D-160, 안드 앱에 미리 박을 한 줄 자리 3개

 

Android XR 대비한다고 젯팩 XR SDK(Jetpack XR SDK) 파고드시는 분 많은데요, 가을 오디오 글래스엔 그거 한 줄도 안 들어갑니다. 진짜 무기는 TextToSpeech예요.

 

저도 6년차 안드러로 사이드 프로젝트 두 개 운영 중인데, 작년 12월부터 젯팩 XR Glimmer 샘플 뜯다가 한 달 늦게 알았습니다. 가을 출시되는 첫 모델은 화면 자체가 없는 폼팩터라서, Glimmer가 그릴 자리가 애초에 없다는 뜻입니다.

 

Android XR 오디오 글래스 D-160, 젯팩 XR SDK가 빗나가는 이유

오늘이 5월 25일, 가을 출시까지 D-160 안팎입니다. 삼성 하드웨어에 퀄컴 SoC, 디자인은 워비파커(Warby Parker)와 젠틀몬스터가 맡았다는 얘기입니다(9to5Google 보도 기준). 핵심은 오디오·마이크·카메라·터치 입력만 있고 디스플레이가 빠져 있다는 점입니다. iPhone 페어링까지 지원하는 폼팩터더라고요.

 

기존 모바일 앱이 기능 요구사항 충돌만 없으면 'Android XR compatible mobile app'으로 자동 인식되는데, 이건 주로 Galaxy XR 헤드셋의 2D 패널 투사 경로에 가까운 동작입니다. 가을 오디오 글래스 쪽은 Jetpack Projected(androidx.xr.projected) 경로로 분리돼 다뤄지는 흐름이라서, 같은 "신규 SDK 학습 없이 닿는다"는 표현이라도 두 경로를 분리해서 보셔야 합니다. 어쨌든 기존 앱이 글래스 사용자한테 닿을 자리는 이미 열려 있다는 뜻입니다. 디스플레이 탑재 버전은 2027년 출시 예정이고, 젯팩 컴포즈(Jetpack Compose) 기반 Glimmer는 그쪽에서나 쓸 물건으로 보입니다.

 

 

그래서 D-160 동안 챙겨야 할 건 딱 셋입니다. TextToSpeech, MediaSessionService, App Actions. 전부 안드로이드(Android)에 원래 있던 API라서, 새 SDK 의존성 추가 없이 한 줄 선언으로 자리 잡을 수 있어요.

 

TextToSpeech 한 줄로 글래스 알림 음성 출력 잡기

가장 ROI 높은 자리가 이겁니다. 앱이 띄우던 알림·요약 텍스트를 tts.speak(text, TextToSpeech.QUEUE_FLUSH, null, "notification_summary") 한 줄로 글래스에 흘려보낼 수 있어요. 글래스 전용 코드는 한 줄도 없습니다.

 

다만 안경 TTS는 제 앱 기준으론 평균 8~12초 안에 응답이 끝나야 자연스럽습니다. 8~12초가 어느 정도냐면, 짧은 알림 한 문장 읽어주는 분량이에요. 긴 알림은 중간에 잘리는 경우가 있어 그래서 알림 자체에 NotificationCompat.Builder 의 .setStyle(BigTextStyle().setSummaryText("요약 텍스트")) 한 줄을 추가해 해결합니다. 안경에선 요약만, 폰에선 원문 그대로 보여주니까 UX 회귀 없이 양립 가능합니다.

 

 

거기에 CATEGORY_REMINDER 같은 낮은 긴급도는 묶음 요약으로 끌려갈 수 있다고 제가 추정하고 있어요(공식 문서에 오디오 글래스 특화 동작으로 박혀 있진 않아서, 출시 후 실측이 필요한 자리입니다). 사용자가 진짜 들어야 하는 알림은 CATEGORY_EVENT 정도로 승격해 단독 호출되도록 분리해두는 게 안전할 것 같아 저는 그 가정으로 작업 중입니다. 참고로 저는 사이드 프로젝트 알림 30개 중 7개 정도를 이번 주에 승격 작업으로 옮겨뒀습니다.

 

오디오 앱이라면 MediaSessionService로 글래스 탭 입력 받기

오디오·팟캐스트·오디오북 앱이라면 이건 무조건입니다. MediaSessionService 를 상속한 서비스 하나 등록해두면, 글래스의 물리적 탭(재생/일시정지/다음)이 그대로 앱 제어권으로 넘어옵니다.

 

선언 자체는 매니페스트 한 줄과 서비스 클래스 한 개예요. 다만 실제 프로덕션에선 오디오 포커스 처리, MediaSession 콜백 분기, 백그라운드 종료 후 복귀 처리까지 들어가서 60~80줄 정도로 늘어나더라고요. "한 줄"은 선언만 그렇다는 얘기고, 운영 코드 분량은 정직하게 잡으셔야 합니다.

 

App Actions, shortcuts.xml은 여유 두고 일찍 등록

App Actions가 셋 중 가장 시간 압박이 큰 자리입니다. shortcuts.xml 에 <capability android:name="actions.intent.GET_THING"> 같은 capability를 선언해두면, "헤이 구글, 내 앱에서 X 실행" 같은 음성 명령이 어시스턴트/제미나이 라우팅을 거쳐 앱 액티비티로 들어오는 흐름입니다.

 

다만 지금은 Google Assistant → Gemini 전환이 진행 중인 시기라서(9to5Google, 2025-12 보도), 가을 출시 첫 주에 본인 앱이 라우팅 후보로 깔끔히 잡힌다는 시나리오는 솔직히 보장하기 어렵습니다. 그래도 미리 capability를 박아두는 가치는 충분합니다. 구글 측 기능 색인 자체에 리드타임이 있어 App Actions 공식 deployment 문서도 "여유를 두고 일찍 배포하라"는 톤이거든요. D-160이지만, 색인 리드타임까지 빼면 실질 작업 데드라인은 한 달 이상 앞당겨 잡는 게 안전합니다.

 

위치 기반 호출이라면 actions.intent.GET_LOCAL_BUSINESS 도 같이 끼워두시면 좋겠습니다. '근처 식당' 같은 질문이 들어왔을 때, 구글맵 대신 본인 앱의 '내가 평점 매긴 식당' DB가 우선 노출될 가능성이 있는 자리입니다(라우팅 후보에 잡힌다는 전제하에요). 단, ACCESS_FINE_LOCATION 권한 동의 플로우를 다시 한번 점검하셔야 합니다. 권한 없는 사용자한테 호출이 실패하면 라우팅 자체가 깎이는 경우가 있거든요.

 

 

응답은 다시 TextToSpeech로 받아 음성으로 돌려주는 흐름이고, 여기에 RECORD_AUDIO 권한·오디오 포커스·fallback 로직까지 붙으면 코드는 60~80줄로 또 늘어납니다. 선언 한 줄로 자리는 잡되, 운영 코드는 따로 예산을 잡아두시는 게 안전합니다.

 

가을 출시 후 회고용으로 미리 박아둘 측정 자리

지금 한 가지 더 깔아두시면 출시 후 한 달이 편해집니다. 호출 빈도 카운트 말고, '평균 음성 응답 길이'를 따로 적재하는 이벤트 한 줄이에요. 8초 넘어가는 응답이 몇 퍼센트인지 보이지 않으면, 출시 후 사용자 이탈 원인을 영영 못 잡습니다.

 

iPhone 페어링 사용자 비율도 같이 찍어두시면 좋습니다. 가을 모델은 iPhone 페어링까지 지원하는 자리니까, 안드로이드 앱이 iOS 사용자한테 음성 인터페이스로 닿는 첫 채널이 될 수 있어요. 이 비율이 의외로 높게 나오면, 2027년 디스플레이 글래스 버전 개발 우선순위가 통째로 바뀔 수 있는 지표예요.

 

 

저는 이번 주말에 사이드 프로젝트 두 개에 capability 6개, MediaSessionService 1개, TextToSpeech 알림 라우팅 12개를 박을 예정입니다. 6년차에 새 SDK 안 배우고 글래스 첫 주 라우팅에 자리 잡을 수 있는 D-160은, 솔직히 다시 안 옵니다.