Tune — 폰 기반 커뮤니티에서 AI 글래스 네이티브로

문제의식

기존 커뮤니티·만남 서비스는 화면 안에 갇혀 있다. 현실에서 매일 스치는, 관심사가 같은 사람과는 정작 연결되지 못한다. 폰 기반 플랫폼의 구조적 한계다.

컨셉 — 한 단계 진화

AI 글래스 전용 커뮤니티 플랫폼. 현실에서 관심사가 맞는 사람을 스칠 때 글래스가 조용한 신호를 주고, 불러세워 연결할 수 있다. 스치고, 부르고, 연결되는 그 흐름이 핵심 재미다. 우연한 마주침이 실제 관계가 되는 것. 물론 상호 동의와 신뢰 확인은 언제나 전제다.

인터랙션 플로우: 스침에서 호출, 연결까지

1. 1 · 스침 감지

   같은 관심사에 물리적 근접(동네·공간 단위, 정확한 위치는 서로 비공개)이 더해진다. 글래스는 조용한 큐나 사후 "오늘 3번 스쳤어요" 요약만 준다. 실시간 추적도, 노출도 없다.

2. 2 · 관심 표시 (비공개 opt-in)

   한쪽이 조용히 "관심 보내기"(시크릿 어드미어러식). 상대는 모름. 양쪽이 서로 관심을 보일 때만 다음 단계.

3. 3 · 신뢰 확인 (게이트)

   연결 전에 실존 인증 배지를 확인한다(얼굴 공개는 선택이고, 인증된 AI 아바타로도 된다). 미성년자, 미인증, 차단 이력이 있는 사람은 걸러진다.

4. 4 · 호출 / 연결

   양쪽이 동의할 때만 조용히 채널이 열린다. "불러세움"은 상대가 수락해야 성립하므로, 일방적 접근이나 스토킹은 불가능하다.

5. 5 · 점진적 개방

   텍스트로 시작해 음성, 원하면 영상, 그다음 대면으로 이어진다. 더 조심스러운 쪽이 속도와 공개 수위를 정하고, 만남은 공공장소로 유도한다.

프라이버시·안전 원칙 (전제)

정확한 위치는 절대 공개하지 않는다. 매칭은 동네·공간 단위로만 이뤄진다. 실시간 추적은 없고, 사후 요약이나 동의 기반의 순간적인 큐만 있다. 양쪽이 동의하지 않으면 식별도 접근도 불가능하다. 인증은 그 사람이 실존한다는 신뢰 신호일 뿐, 외모를 평가하는 게 아니다.

지원 기능 (본질 아님 — 수단)

신뢰를 위한 실존 인증 배지, 얼굴 공개 부담을 더는 선택형 AI 아바타, 분위기를 푸는 AI 호스트. 모두 진입장벽을 낮추고 신뢰를 쌓기 위한 수단이다. Tune의 본질은 아니다.

랜딩 비주얼 (직접 제작)

Tune 랜딩에 등장하는 인물은 모두 fal.ai로 직접 생성한 가상 얼굴이다. 실존 인물이 아니라서 저작권에서 자유롭다. 어떤 모델로 만들지를 따진 게 케이스 02 "사실적 AI 인물 만들기"의 20여 개 모델 비교다.

탐구·사고 / GM 연결

인터랙션 설계는 결국 몇 가지 질문으로 좁혀졌다. "스침"을 어떻게 감지하고 표현할지, 동의 기반 호출을 어떻게 안전하게 만들지, 위치 프라이버시(동네 단위)를 어떻게 지킬지. 그 과정에서 폰(PWA)의 백그라운드 위치 차단 한계에 부딪혔고, 패시브한 마주침은 결국 폰이 아니라 글래스 네이티브 앱이어야 한다고 판단했다. 프로토타입은 Android XR 에뮬레이터에서 만들었는데, 젠틀몬스터 글래스가 올라가는 바로 그 플랫폼이다. 매장이나 전시 공간에서 취향이 같은 방문자를 조용히 연결하는 일과도 맞닿아 있다.

AI 글래스 앱 프로토타이핑 (Android XR)

Tune은 글래스 위에서만 말이 되는 서비스라, 디자인에서 멈추지 않고 실제 앱을 Android XR에서 만들기 시작했다(젠틀몬스터는 삼성 Android XR 플랫폼 위에서 돈다). XR 시스템 이미지를 CLI로 설치하고 AVD를 조립해 에뮬레이터를 부팅한 뒤, Kotlin과 Jetpack Compose Glimmer로 얇은 글래스 클라이언트("EncounterCue")를 만들었다. 모든 결정을 관통한 원칙은 하나였다. 스침 감지는 근접·위치 매칭이지 카메라 얼굴인식이 아니라는 것. 앱은 위치를 동네 단위로만 요청하고 카메라는 아예 건드리지 않는다. 하드웨어는 2026년 가을 출시라, 지금은 에뮬레이터로 빌드하고 있다.

프로토타이핑 기록

Tune 스침 큐 앱을 직접 빌드해 Android XR 에뮬레이터에서 실행한 첫 장면이다. 프로덕션 글래스 UI는 Compose Glimmer로 만들지만, 이 데모 빌드는 안정 버전 Compose를 썼다. Glimmer alpha가 아직 미출시 preview SDK(API 37)를 요구하기 때문이다.

• 

  Tune 앱, Android XR 에뮬레이터에서 실행

  직접 빌드한 Tune 스침 큐(Kotlin/Compose)가 Android XR 에뮬레이터에 설치·실행되는 화면 — XR 홈 위에 앱 윈도우로.

• 

  Android XR 에뮬레이터 직접 실행

  Android XR SDK·시스템 이미지를 CLI로 설치하고 AVD를 조립해 에뮬레이터를 부팅(하드웨어 GPU). XR 홈 환경이 실제 구동되는 화면.

• 

  글래스 시야(FOV) 설계

  스침 감지 → 관심·신뢰 확인 → 통했어요. 익명 앰비언트 큐만, 누군지는 양방 동의 후에만.

• 

  Glimmer 글래스 클라이언트 (Kotlin)

  설계 원칙을 코드에 — 카메라 얼굴인식 안 함, 위치는 동네 단위, 글래스는 Tune 백엔드 위의 얇은 클라이언트.

실제 백엔드 연동 (Supabase)

UI를 넘어, 스침 플로우를 실제 Supabase 백엔드에 연결했다: interests(비공개 관심)·encounters(스침 큐)·그리고 관심이 양방이 되는 순간 DM 스레드를 만드는 Postgres 트리거 — 매칭이 클라이언트가 아니라 DB에서 일어난다. 프라이버시는 Row-Level Security로 강제된다: 내가 보낸 관심만 조회 가능하므로 "상대는 모른다"가 UI 문구가 아니라 DB 정책이다. 에뮬레이터에서 E2E 검증 — 앱의 탭이 실제 행을 쓰고, 트리거가 발동하고, 대화가 direct_messages에 저장된다.

데모 영상 — 실 백엔드 플로우

Android XR 에뮬레이터에서 원테이크로 녹화: 로그인 → 스침 큐 → 관심 보내기 → Postgres 트리거가 매칭 생성 → 실제 채팅. 모든 단계가 Supabase에 실제 행을 쓴다.

• 스침 → 관심 → 매칭(DB 트리거) → 대화 — 실 백엔드