← Docs hub

Speaker Identity Service Opportunity Backlog

이 문서는 화자 인식이 제품 서비스로 확장될 수 있는 가능성 영역을 정리한다.

여기 있는 항목은 모두 즉시 구현 확정 요구사항이 아니다. 목적은 화자 인식이 단순히 “누가 말했는지 맞추는 기능”에서 끝나지 않고, AI 로보틱스 서비스의 개인화, 안전, 건강, 가족 UX, 외부 계정 연동으로 확장될 수 있는 사고 포인트를 관리하는 것이다.

1. 확장 축 요약

2. Near-term 후보

2.1 화자별 대화 메모리

문제:

• 가족 공용 제품에서 대화 이력이 섞이면 개인화 품질이 떨어진다.

아이디어:

• speaker_id 또는 person_id 기준으로 short-term pair, session summary, preference candidate를 분리한다.
• unknown/multi-speaker 상태에서는 개인 메모리를 쓰지 않는다.

필요 조건:

• speaker_context contract
• speaker-scoped memory update
• 삭제/동의 정책

리스크:

• 화자 오인식 시 다른 사람의 memory가 섞일 수 있다.
• low confidence에서는 no-write가 기본이어야 한다.

2.2 사용자별 선호 공간/모드

예시:

내 방 청정해줘
내가 좋아하는 모드로 해줘
평소처럼 해줘

서비스 가치:

• 내 방, 평소처럼, 내 설정 같은 표현을 person profile의 preference로 해석할 수 있다.

필요 조건:

• person_id와 공간/모드 preference 연결
• 모호한 경우 확인 질문
• 계정/가족 공용 상황에서 권한 정책

2.3 민감 기능 실행 전 사용자 확인

예시:

보안 모드 켜줘
내 건강 이력 알려줘
내 일정 알려줘

서비스 가치:

• 기능별로 필요한 identity assurance를 다르게 설정할 수 있다.

정책 예:

3. Mid-term 후보

3.1 Voice ID와 Vital Sign Face ID 연결

아이디어:

• Voice ID로 Person Profile을 찾고, 연결된 Vital Face ID의 이력을 가져와 요약한다.

예시:

요즘 내 스트레스 어때?
최근 바이탈 체크 결과 설명해줘.
지난번보다 심박이 괜찮아졌어?

서비스 가치:

• 나무X가 단순 청정/이동 로봇을 넘어 개인 웰니스 companion으로 확장된다.

필요 조건:

• Person Profile
• Voice ID -> Person ID link
• Person ID -> Vital Face ID link
• health data consent
• 민감정보 응답 정책

리스크:

• 건강 정보는 진단으로 오해될 수 있다.
• 주변 사람이 듣는 상황에서 민감 정보 노출 가능성이 있다.
• voice confidence가 낮으면 절대 상세 이력을 말하면 안 된다.

3.2 Google 계정/캘린더 연동

아이디어:

• Person Profile에 Google 계정을 연결해 개인 일정, 루틴, 리마인더, 이동/청정 스케줄을 개인화한다.

예시:

내일 일정에 맞춰 아침에 공기질 체크해줘.
회의 전에 거실 공기 상태 알려줘.
내 캘린더 보고 오늘 루틴 추천해줘.

서비스 가치:

• 외부 계정 기반의 생활 맥락을 로봇 행동 계획에 연결할 수 있다.

필요 조건:

• provider account link
• scope consent
• token lifecycle
• Cloud A2A planner에 external context summary 제공

리스크:

• OAuth/token 보안
• 일정 정보 개인정보 노출
• 외부 서비스 장애 시 fallback

3.3 가족 구성원 권한 모델

아이디어:

• 가족 구성원별로 실행 가능한 기능을 다르게 둔다.

예시:

아이 음성: 보안 모드 꺼줘 -> 차단
관리자 음성: 보안 모드 꺼줘 -> 허용
게스트 음성: 내 건강 이력 알려줘 -> 차단

서비스 가치:

• 가정 내 공유 로봇에서 안전한 사용자별 권한 제어가 가능하다.

필요 조건:

• authority_level
• guardian/admin role
• guest policy
• 앱 설정 UI

4. Exploratory 후보

4.1 감정/긴급도 기반 응답 전략

아이디어:

• 음성 에너지, 속도, 억양, 반복 호출 패턴을 사용해 긴급도나 감정 상태를 보조적으로 추정한다.

서비스 가치:

• 같은 명령이라도 사용자의 긴급도에 따라 응답 톤과 우선순위를 바꿀 수 있다.

예시:

사용자 음성이 급박함 -> 짧고 즉시성 높은 응답
사용자 음성이 피곤함 -> 조용한 모드/웰니스 제안

주의:

• 감정 추정은 오판 가능성이 크다.
• 확정 진단이 아니라 보조 signal로만 사용해야 한다.

4.2 다중 화자 conflict resolution

아이디어:

• 여러 사람이 동시에 서로 다른 명령을 내릴 때 우선순위를 정한다.

예시:

A: 거실로 와
B: 아니 주방으로 가

정책 후보:

• 최근 workflow owner 우선
• 관리자 권한 우선
• 더 높은 confidence 우선
• 충돌 시 확인 질문

4.3 Proactive Wellness Care

아이디어:

• 바이탈 이력, 공기질, 생활 루틴, 음성 context를 바탕으로 사용자가 묻기 전에 케어 제안을 한다.

예시:

최근 스트레스 수치가 높고 실내 공기질이 나빠졌어요. 조용한 모드로 공기 관리를 시작할까요?

필요 조건:

• proactive trigger policy
• 개인 건강 정보 동의
• 과도한 알림 방지
• 민감정보 노출 방지

5. 우선순위 판단 기준

6. 추천 로드맵

7. 기획상 주의할 점

• Voice ID는 인증 수단이 아니라 context evidence로 시작해야 한다.
• 건강/일정/계정 정보는 linked/verified 상태와 consent가 없으면 말하지 않는다.
• 화자 인식 latency는 모든 기능에 blocking으로 적용하지 않는다.
• 개인화는 “더 많이 기억”이 아니라 “틀렸을 때 피해가 적은 것부터” 시작한다.
• 앱은 단순 설정 화면이 아니라 identity link, consent, delete, authority를 관리하는 control plane이 되어야 한다.