feat: 온디바이스 감정 분류 기능 추가 (KoELECTRA + LiteRT)

[soyeonLee126]

작업 개요

대화/일기 텍스트에서 대표 화자의 감정을 온디바이스로 분류하는 기능을 추가합니다.
KoELECTRA 6-감정 모델을 LiteRT(INT8)로 실행하고, WordPiece 토크나이징은 DJL을 사용합니다.
이 PR은 감정 분류(집계 개선 포함)만 다루며, 일기 요약(kobart ONNX)은 별도 PR로 분리합니다.

작업 유형

• feat: 새 기능
• fix: 버그 수정
• refactor: 리팩토링 (동작 변경 없음)
• build: 빌드/의존성 설정
• chore: 기타 (문서, 설정 등)
• test: 테스트 추가/수정

변경 사항

• :domain — 감정 분류 계약(EmotionClassifier), 대화 파서(Conversation), 유즈케이스(AnalyzeConversationEmotionUseCase) 추가
• :data — LiteRT/DJL 기반 온디바이스 분류기 구현 + Hilt 바인딩(EmotionModule)
• :feature:emotion — 감정 분석 화면(orbit MVI) 신규 모듈 추가
• :app — 네비게이션 연결(감정 탭) + 빌드 설정(arm64, noCompress tflite, androidTest)
• 버전 카탈로그 — LiteRT/DJL 의존성 추가
• 감정 집계: 발화별 분류 후 최고신뢰 발화 채택(동률 시 최근). 다수결은 저신뢰 잡담이 표를 갈라 배제. 도메인 단위 테스트 포함
• 분류 파이프라인: 대화/일기 → 파서(화자 없으면 일기 단문 처리) → 메인 화자 선별 → 발화별 분류 → 6감정(분노/불안/당황/기쁨/상처/슬픔) 중 대표 1개 + 신뢰도

관련 이슈

• Closes #

관련 작업 (Notion)

• GMSS-64

스크린샷 / 동작 화면

감정 분석 화면은 현재 검증/테스트 성격입니다. 실제 제품에서는 감정 라벨이 서버 대사 생성 입력으로 쓰일 파이프라인 부품이라 별도 UI 캡처는 첨부하지 않습니다.

체크리스트

• base 브랜치가 develop으로 설정되어 있다
• 로컬 빌드 및 실행을 확인했다 (assembleDebug / androidTest / detekt 통과, 실기기 60문장 평가 44/60 · 원본 모델 예측과 문장별 100% 일치)
• 커밋 메시지가 컨벤션(feat:, fix: 등)을 따른다
• 불필요한 로그/주석/디버그 코드를 제거했다
• 리뷰어가 이해할 수 있도록 설명을 작성했다

리뷰 요청 사항

• 모델(*.tflite)·네이티브(*.so)는 gitignore 처리됨 → 클린 체크아웃/CI 실행 시 별도 주입(LFS 또는 CI 다운로드 스텝)이 필요합니다. 이 전략에 대한 의견 부탁드립니다.
• arm64-v8a 전용 빌드(모델 + DJL 네이티브)가 defaultConfig에 있어 release 빌드에도 적용됩니다. 출시 시 기기 커버리지 관점에서 검토가 필요합니다.
• 감정 집계 전략(발화별 최고신뢰 vs 통째 결합)의 적절성.

[seunghee17]

검증 단계에서 글자 수 최다 화자를 메인 화자로 임시 지정해두신 것 같은데 맞을까요? 실 데이터 연동 시점엔 화자를 role(사용자/AI)로 명시적으로 구분해서 넘기는 방향으로 바뀌는 건지 확인하고 싶습니다!

[soyeonLee126]

넵 검증용 임시 방식이었고, 리팩토링해서 수 기반 mainSpeaker와 대화 파서는 제거되었습니당

[seunghee17]

모델과 직접 관리가 필요한 네이티브 파일은 Git LFS로 관리하는 방향이 적절해 보입니다. Git LFS를 통해 클린 체크아웃 시 파일을 내려받도록 하고 CI에서는 대역폭 사용을 줄이기 위해 모델이 필요한 빌드 잡에서만 LFS 다운로드를 활성화하면 좋을 것 같습니다! LFS 저장 공간과 월간 대역폭 사용량은 운영 중 지속적으로 확인해야할 것 같습니다!