← Docs hub

Speaker Identity Service Planning

이 문서는 Voice ID를 제품 서비스 identity 체계 안에서 어떻게 정의할지 정리한다.

현재 제품에는 최소 세 종류의 사용자 식별 단서가 존재한다.

• 컨트롤 앱 계정: 앱 로그인 계정이며, 계정에 사용자 이름이 붙어 있다.
• 바이탈 사인 얼굴 사용자 ID: 얼굴 인식 기반 건강 상태 체크 이력의 기준 ID다.
• 화자 인식 Voice ID: 음성 임베딩 기반으로 “누가 말했는지”를 추정하는 ID다.

핵심 결론은 Voice ID를 계정 또는 얼굴 ID와 무조건 1:1 대응시키면 안 된다는 것이다. 제품 구조상 계정, 얼굴, 목소리는 각각 다른 인증 강도와 생성 시점, 실패 모드, 개인정보 리스크를 가진다. 따라서 중간에 Person Profile 또는 Identity Link 계층을 두고 느슨하게 연결해야 한다.

1. 왜 1:1 대응이 위험한가

따라서 아래처럼 강제하면 위험하다.

voice_id == face_id == account_user_name

권장 구조는 다음이다.

Control App Account
  -> Person Profile
      -> linked_voice_ids[]
      -> linked_vital_face_ids[]
      -> display_name
      -> consent_state
      -> authority_level
      -> personalization_profile

즉 Voice ID는 “계정”도 아니고 “얼굴 ID”도 아니다. Voice ID는 현재 발화의 주체를 추정하는 context key이고, 서비스가 개인화/건강 이력/권한을 쓰려면 Person Profile에 연결되어야 한다.

2. 권장 Identity 모델

2.1 계층 구조

권장 관계:

account_id 1 --- N person_id
person_id 1 --- N voice_id
person_id 1 --- N vital_face_id
person_id 1 --- N external_identity

이 구조를 쓰는 이유:

• 가족 공용 계정에서 여러 사람을 지원할 수 있다.
• 한 사람이 여러 voice sample 또는 여러 기기에서 등록한 voice_id를 가질 수 있다.
• 얼굴 인식과 화자 인식이 서로 실패해도 전체 identity가 무너지지 않는다.
• Google 계정 연동 같은 외부 identity를 나중에 추가해도 구조가 유지된다.

2.2 연결 상태

3. 바이탈 사인 연동 서비스 확장

화자 인식이 Person Profile에 연결되면 다음 서비스가 가능해진다.

예시 발화:

내 최근 바이탈 상태 어때?
지난주보다 스트레스가 높아졌어?
요즘 심박 상태를 설명해줘.
내 건강 체크 이력 요약해줘.

서비스 흐름:

1. 사용자가 발화한다.
2. 온디바이스가 voice_id를 추정한다.
3. voice_id가 person_id에 linked/verified 상태인지 확인한다.
4. person_id와 연결된 vital_face_id를 조회한다.
5. vital sign history를 가져온다.
6. Cloud LLM 또는 온디바이스 응답 계층이 안전한 요약을 생성한다.
7. 민감 정보이므로 신뢰도/권한/주변 사용자 상태에 따라 응답 범위를 제한한다.

정책:

주의:

• 바이탈 사인은 건강 정보 성격이 있으므로 일반 개인화보다 높은 동의/권한 기준이 필요하다.
• LLM은 진단을 해서는 안 되며, “기록 기반 요약/추세 설명/앱 확인 안내” 수준으로 제한해야 한다.
• 신뢰도 낮은 voice_id로 건강 이력을 읽어주는 것은 제품 리스크가 크다.

4. 컨트롤 앱 계정과의 관계

현재 조건:

• 컨트롤 앱에는 계정이 있다.
• 계정당 사용자 객체가 붙는 구조가 아니라, 계정에 사용자 이름이 붙는 형태로 이해된다.

이 상태에서 Voice ID를 앱 계정에 바로 붙이면 아래 문제가 생긴다.

권장:

• 앱 계정은 소유/관리/동의의 루트로 둔다.
• 실제 사용자는 Person Profile로 별도 관리한다.
• 계정 표시 이름은 person.display_name의 초기 후보로만 사용한다.
• voice_id, face_id, Google 계정은 Person Profile에 link되는 방식으로 관리한다.

5. Google 계정 연동 확장성

Google 계정 연동은 Voice ID 자체를 대체하지 않는다. Google 계정은 외부 인증/캘린더/개인 서비스 연결을 위한 identity provider다.

확장 예시:

권장 모델:

{
  "person_id": "person_001",
  "display_name": "용재",
  "linked_identities": {
    "voice_ids": ["voice_001"],
    "vital_face_ids": ["face_001"],
    "external_accounts": [
      {
        "provider": "google",
        "subject": "google_sub_hash",
        "scopes": ["calendar.readonly"],
        "linked_at": "2026-07-07T00:00:00Z"
      }
    ]
  },
  "consent_state": {
    "voice_personalization": true,
    "vital_history_summary": true,
    "external_calendar": false
  }
}

6. 개인화 서비스 기획 방향

6.1 Must

6.2 Should

6.3 Could

7. 성능/UX 리스크: 화자인식 지연

화자인식은 STT 이후 추가 처리로 들어가기 때문에 응답 지연이 생긴다.

현재 예상:

STT 완료 후 speaker identification 추가 지연: 약 0.5초 이내

리스크:

대응:

권장:

• 모든 발화에 speaker identification을 blocking으로 걸지 않는다.
• 건강/계정/개인 일정/개인 memory/권한이 필요한 기능에만 blocking gate를 적용한다.
• 이동/청정 같은 일반 명령은 정책에 따라 unknown에서도 확인 질문 또는 제한 실행이 가능해야 한다.

8. 의사결정이 필요한 질문

9. 다음 문서/구현 반영점

• Speaker Context Contract에 person_id, linked_identity_state, consent_scope 후보를 추가 검토한다.
• Speaker Memory Management는 speaker_id뿐 아니라 person_id 기준 memory scope를 함께 다뤄야 한다.
• TaskManager Integration은 side-effect gate 외에 personal data access gate를 추가해야 한다.
• Privacy And Safety은 voiceprint뿐 아니라 vital history, external account scope까지 포함해야 한다.
• Implementation Roadmap은 identity link 티켓을 별도 phase로 추가해야 한다.